| 01:14.32 | *** join/#asterisk-dev michael_work_ (~michael_w@bzq-82-168-31-134.red.bezeqint.net) |
| 02:25.16 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:25.16 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 03:21.41 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 04:40.31 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 04:40.31 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 05:52.41 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-btnvvfqmdmnhwvlk) |
| 06:34.11 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:34.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:08.02 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:08.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:04.50 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 08:14.17 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 08:14.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:15.05 | oej | Morning folks! |
| 08:15.29 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:15.29 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:28.27 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 11:55.48 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-imdiaxnnjssqjdpl) |
| 12:53.00 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 12:56.37 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-lkxbkvngjlifwxsr) |
| 13:08.03 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 13:08.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:13.12 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:20.27 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 13:20.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:04.08 | *** join/#asterisk-dev newtonr (~newtonr@173-21-90-203.client.mchsi.com) |
| 14:04.08 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:06.35 | *** join/#asterisk-dev skrusty (~skrusty@168.63.14.171) |
| 14:06.42 | skrusty | afternoon |
| 14:08.13 | file | good day |
| 14:09.00 | skrusty | good weekend? |
| 14:46.21 | *** join/#asterisk-dev linetrace (~linetrace@65.19.81.126) |
| 14:48.15 | file | 'twas acceptable |
| 14:48.18 | file | how was yours? |
| 14:51.30 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:51.30 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:53.13 | skrusty | was ill |
| 14:53.17 | skrusty | but feeling better now :) |
| 14:58.43 | file | UNCLEAN! UNCLEAN! |
| 14:58.46 | file | quarantines skrusty |
| 15:07.18 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-qpwxwggnllbyxcui) |
| 15:21.19 | skrusty | :) |
| 15:25.35 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-yoghistwfxlcmknn) |
| 15:25.35 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:58.52 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-shwmhywwhqlgvgsf) |
| 16:09.25 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 16:12.11 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 16:18.16 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-zeubnztxyjidocjg) |
| 16:18.16 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:18.55 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 16:18.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:33.28 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:33.28 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:18.02 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:38.12 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-olmsmjfzbyiksjdi) |
| 17:38.12 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:40.47 | *** join/#asterisk-dev Simon-- (~sim@2606:6a00:0:28:5604:a6ff:fe02:702b) |
| 17:44.50 | *** join/#asterisk-dev philippel (uid10480@gateway/web/irccloud.com/x-kzvwvxzlcaqigdqo) |
| 18:08.37 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:08.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:24.18 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:24.19 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:24.24 | pabelanger | so, this is confusing |
| 18:24.30 | pabelanger | If I use a local channel for my queue members |
| 18:24.52 | pabelanger | then, using features.conf, invoke an atxfer for the queue member |
| 18:24.58 | pabelanger | the local channel goes on hold |
| 18:25.05 | pabelanger | starts another local channel for the dial |
| 18:25.09 | pabelanger | if that dial answers |
| 18:25.23 | pabelanger | the dial channel will hear the MOH on the queue member local channel |
| 18:26.07 | file | it's best to specify what version you are talking about |
| 18:26.15 | pabelanger | this is 1.8 |
| 18:28.18 | pabelanger | I suspect the /n has something to do with it |
| 18:32.31 | pabelanger | nope |
| 18:32.42 | pabelanger | I think just the way my channels are getting setup |
| 18:33.02 | mjordan | pabelanger: who gets bridged with whom? |
| 18:33.11 | pabelanger | the fix, is not do to a straight Dial() from that local channel |
| 18:33.18 | pabelanger | but to start a new local channel with dial |
| 18:33.40 | pabelanger | mjordan, how should I explain, using A, B and C variables? |
| 18:34.12 | pabelanger | A (sip) calls into queue. B then rings and answers. B is a local channel. A and B are talking |
| 18:35.11 | pabelanger | B, inits a atfxer (features.conf) to C (sip channel). C rings and answers. B and C connected. However, C hears MOH from A. and talking from B. B hears nothing |
| 18:40.22 | pabelanger | Ya, creating a new local channel then dialing fixes it. |
| 19:22.16 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:22.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:24.33 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-zsmvfdhtgcotcywn) |
| 19:24.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 19:27.08 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:27.08 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:01.15 | *** join/#asterisk-dev fornax (~fornax@p5795AE5D.dip0.t-ipconnect.de) |
| 20:01.56 | gtjoseph | is in 'const' sorcery hell. |
| 20:21.50 | Qwell | gtjoseph: Just make it all const, and when you need to edit something, use pointer math. |
| 20:23.15 | gtjoseph | yeah but then file will yell at me for making his baby ugly |
| 20:23.26 | file | ... |
| 20:23.31 | file | stuff is const for a reason |
| 20:24.22 | gtjoseph | yeah but... there are places where sorcery is const which means I can't put a lock on it. |
| 20:24.34 | file | a lock on what? |
| 20:24.56 | file | oh |
| 20:24.57 | gtjoseph | instead of the vectors to hold observers, i'm using RWLIST. |
| 20:25.11 | gtjoseph | but I can'y lock it if sorcery was passed in as a const |
| 20:25.42 | gtjoseph | list ast_sorcery_load |
| 20:26.12 | gtjoseph | s/list/like/ |
| 20:37.58 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 20:37.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:49.47 | *** join/#asterisk-dev wedhorn (~wedhorn@110-175-181-222.static.tpgi.com.au) |
| 21:18.45 | kharwell | question regarding the one way audio issue with direct media on a private network (current patch up for review https://reviewboard.asterisk.org/r/4216/) |
| 21:18.56 | kharwell | based on some feedback proposed by file there are a couple of ways to improve the fix. |
| 21:19.10 | kharwell | 1. maintain the remote direct media address on the rtp instance (can then be retrieved for use in outgoing reinvite) |
| 21:19.30 | kharwell | 2. keep everything internal to res_rtp_asterisk, the remote address is never changed, but store the learned address to use with outgoing rtp packets |
| 21:19.52 | kharwell | I like #2, but a consequence is that Asterisk would be sending to an address that is not the currently specified remote address. |
| 21:20.13 | kharwell | So the question would be what are the implications of this? Thoughts on #2 being okay? |
| 21:21.21 | kharwell | mjordan/file ^^^ |
| 21:21.36 | file | what ways are the remote address exposed? |
| 21:21.59 | *** join/#asterisk-dev philippel_ (uid10480@gateway/web/irccloud.com/x-uyfzjcpivncmbtoa) |
| 21:23.08 | file | that would be my concern with #2 - that suddenly that information was exposed and now it's not |
| 21:23.31 | file | really, what is remote address supposed to convey? the address that we are sending media to or the address that we've been told to send media to? |
| 21:27.03 | kharwell | not sure. what makes more sense when say doing a channel read on pjsip and it retrieves the remote rtp address? which is that expected to be? |
| 21:28.48 | file | dunno - that's the question for all :D |
| 21:30.49 | *** join/#asterisk-dev leedm777 (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 21:35.49 | *** part/#asterisk-dev leedm777 (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 21:36.29 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-qlmobfkatubqyrtc) |
| 21:43.46 | kharwell | file: looks like rtp multicast uses the remote address to send stuff as well. without exposing it (address asterisk is sending to) I am not sure how that module would get the correct remote address. and if going to do that then mind as well do #1 option since it may have less possible side effects |
| 21:44.26 | kharwell | I'd say your question is still valid though |
| 21:44.32 | file | it sends to what it is told to send to |
| 21:44.34 | file | cause it's multicast |
| 21:46.32 | kharwell | if #2 was implemented I guess it would just send to the private ip address which it couldn't reach which I guess would be the same as asterisk sending to any other address that is dropping the packets |
| 21:46.42 | kharwell | so I guess it'd be fine too then |
| 21:49.19 | file | I don't know what you are saying. |
| 21:49.26 | file | That could just be the oil smell talking, though. |
| 21:52.58 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 21:54.31 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 21:57.31 | mjordan | are we thinking along the lines of chan_rtp_multicast and chan_pjsip being in a native RTP bridge together? |
| 21:58.40 | file | would that... happen... |
| 21:58.57 | mjordan | well, I'm trying to think through why RTP multicast matters in this situation |
| 21:59.13 | file | I don't think it does |
| 21:59.15 | mjordan | because even if you managed to do that (and I'm not sure how you could), it's not like you'd be going into a RTP remote bridge anyway |
| 21:59.18 | mjordan | right |
| 22:00.05 | mjordan | Even if you specify a chan_pjsip channel with res_rtp_multicast as the RTP implementation, I don't think you should be trying to go into a remote native bridge |
| 22:08.28 | kharwell | it probably doesn't matter. I was thinking along the lines of any place the remote address is getting used (various channel drivers and such). if some of those are expecting the learned address and not a possible private/device address or something. if that is even a possibility or problem |
| 22:11.33 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 22:30.21 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 22:30.51 | Kobaz | soooo. I'm having an issue when i get a 302 moved temporarily and then asterisk routes the call to Local/forwardedNumber@context |
| 22:31.05 | Kobaz | how can i expedite the local channel getting optimized out? |
| 22:33.33 | mjordan | answer it |
| 22:33.42 | mjordan | and get it bridged with something else |
| 22:33.57 | mjordan | It won't optimize until it detects that there is a channel on either end of the Local channel chain |
| 22:34.03 | mjordan | both of whom are answered |
| 22:34.34 | Kobaz | ah, answered |
| 22:35.16 | Kobaz | i was setting like LOCAL_NO_OPTIMIZATION flags |
| 22:35.20 | Kobaz | and that wasn't doing it |
| 22:35.48 | Kobaz | there's no easy way to optimize it out when it's an endpoint<->dialplan ? |
| 22:36.02 | Kobaz | at that point it's the same as a Redirect |
| 22:36.21 | Kobaz | but i have this extra local channel |
| 22:37.07 | Kobaz | that's pretty much what i need actually. make it a redirect instead of a local channel |
| 22:38.52 | *** join/#asterisk-dev snuff-work (~snuffy@203.87.61.22) |
| 22:38.52 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:39.10 | Kobaz | what damage would happen if i replaced the local channel redirection with ast_async_parseable_goto() in app_dial for handling a 302 ? |
| 22:39.36 | Kobaz | this would fix a boatload of issues for me |
| 22:41.51 | snuff-work | kobaz.. try n see how good or bad it fails =) |
| 22:43.06 | Kobaz | hah |
| 22:43.07 | Kobaz | yay |
| 22:43.48 | Kobaz | and then you can avoid the masqerade |
| 22:43.55 | Kobaz | and inheritance |
| 22:44.01 | Kobaz | you can simplify a whole bunch of stuff |
| 22:45.10 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 22:47.02 | mjordan | Kobaz: and introduce a ton more problems. |
| 22:47.08 | mjordan | But without looking at a patch, I can't guess what. |
| 22:47.12 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-zsmvfdhtgcotcywn) |
| 22:48.51 | coreyfarrell | yeah sounds like it changes a bunch of existing behaviors.. even if it's all improvements and no regressions I think it could not be considered for branches already released. |
| 22:49.43 | Kobaz | no, no existing branches of course |
| 23:00.02 | Simon-- | hmm. so I was trying to set up a test lab to reproduce an issue with debian wheezy asterisk (which worked), and so then tried to go to newest 1.8 release to see if it was debian-specific etc, and iax hangs instead of working at all. bisecting that down now to between 1.8.17 and 1.8.19, but wtf.. |
| 23:00.37 | Simon-- | anybody else seen chan_iax.so just not receive packets? netstat -unl shows recv-q building and everything else is idle |
| 23:01.02 | Simon-- | I can't imagine iax was broken for that long and nobody else noticed.. |
| 23:02.25 | WIMPy | I think I have seen that. But that was too long ago to remember. Like 1.8. |
| 23:02.27 | snuff-work | i think u'd be surprised.. most seem to have just 'moved on' from iax |
| 23:02.50 | Simon-- | iax2, I should say.. |
| 23:02.50 | snuff-work | last time i used iax.. was 2007 maybe |
| 23:03.08 | snuff-work | iax/iax2 same thing to me =) |
| 23:03.15 | Simon-- | what you using instead? |
| 23:03.33 | snuff-work | sip works for what i need.. |
| 23:03.45 | snuff-work | granted i dont have big trunks to worry about |
| 23:04.08 | snuff-work | even less at my current work with only 10 inbound lines =) |
| 23:04.13 | Simon-- | mm. yah. I think the userbase of chan_iax2.so on 1.8.something is > 0 ;) |
| 23:16.34 | Kobaz | okay so |
| 23:16.46 | Kobaz | i'm having problems with doing a straight redirect |
| 23:16.52 | Kobaz | i see why it's using a local channel |
| 23:17.16 | Kobaz | so back my original issue... the local channel not getting optimized out |
| 23:17.25 | Kobaz | <PROTECTED> |
| 23:17.31 | Kobaz | local channel still going... |
| 23:18.05 | Kobaz | i guess that's because my local channel is running dialplan? |
| 23:18.09 | Kobaz | and not bridged to something |
| 23:43.27 | *** join/#asterisk-dev leedm777 (~leedm777@ip-64-134-182-234.public.wayport.net) |
| 23:58.02 | gtjoseph | can someone try compiling 13 from svn? I'm getting multiple errors in test_statis.c |
| 23:58.18 | gtjoseph | s/statsis/stasis/ |
| 23:58.38 | gtjoseph | s/statis/stasis/ |