| 00:09.04 | coreyf1513 | snuff-work: I once had an issue with dtmf + reinvite causing the dtmf end to be lost, then one-way audio. ASTERISK-21522 - I don't think it was inband. |
| 00:09.40 | snuff-work | mm.. i'm tempted to PJSIP but i need bit of 'effort' to recode my DP for that |
| 00:09.52 | snuff-work | and some time to just get PJSIP working |
| 00:09.59 | snuff-work | within new * |
| 00:10.15 | coreyf1513 | are you having one-way audio after the reinvite? |
| 00:10.48 | snuff-work | yes.. well it appears that way.. since looking @ cap via wireshark |
| 00:11.58 | snuff-work | the other end (that i'm calling) still has sound.. but my sound stops straight after the reinvite |
| 00:12.22 | snuff-work | (my transmitting of rtp to remote) |
| 00:13.10 | coreyf1513 | sound stops or rtp stops? |
| 00:13.51 | snuff-work | well wireshark says that i stopped sending audio in recording |
| 00:14.00 | snuff-work | *on playback via wireshark |
| 00:14.09 | snuff-work | i can send u the cap if u like. |
| 00:14.18 | snuff-work | only like 600kb |
| 00:14.59 | coreyf1513 | sure |
| 00:15.29 | snuff-work | my * version is around svn 406000 |
| 00:16.00 | coreyf1513 | what branch? |
| 00:16.31 | snuff-work | trunk |
| 00:16.42 | snuff-work | r407169 |
| 00:16.48 | snuff-work | to be exact.. |
| 00:17.10 | snuff-work | i want to get around to trying the newer PJSIP implementation but 0 time atm.. |
| 00:17.26 | snuff-work | luckily this only affects 1 number |
| 00:17.44 | snuff-work | since its within the providers own network it jumps around |
| 00:17.56 | snuff-work | vs outside which holds a single session |
| 00:20.16 | coreyf1513 | did you try sending the cap? |
| 00:20.32 | coreyf1513 | ah just got it |
| 00:20.40 | snuff-work | only just sent |
| 00:26.20 | coreyf1513 | always awesome when you get a double reinvite |
| 00:27.51 | snuff-work | mm |
| 00:28.08 | coreyf1513 | do you know how to filter for the inband dtmf? |
| 00:30.21 | snuff-work | u cant.. u just have to listen to the rtp |
| 00:35.30 | coreyf1513 | the SDP in packet 1141 (INVITE from 210...) has media attribute sendonly |
| 00:36.01 | coreyf1513 | oh sorry I see the next sdp packet.. |
| 00:38.55 | snuff-work | ;) |
| 00:39.21 | coreyf1513 | in any case asterisk stops sending RTP after the reinvite |
| 00:39.42 | snuff-work | yer |
| 00:51.08 | coreyf1513 | other than asterisk not sending rtp past a certain point one thing I noticed was the first reinvite has "c=IN IP4 0.0.0.0" twice, but that shouldn't cause the problem. sorry I was hoping i'd be more helpful |
| 00:52.48 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 00:53.21 | snuff-work | no problem.. |
| 01:51.21 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 02:51.17 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 03:51.20 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 04:33.39 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 04:33.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 04:51.19 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 05:51.21 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 06:51.19 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 07:51.17 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 08:51.19 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 09:17.04 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:98dd:86d6:e9ee:ddc) |
| 09:51.18 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 10:51.19 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 11:16.31 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 11:51.19 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:08.11 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:15.33 | *** join/#asterisk-dev danjenkins (~dan@92.40.248.77.threembb.co.uk) |
| 12:23.06 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:159e:1c66:21a1:847f) |
| 12:24.53 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 12:24.53 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 12:49.55 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 12:49.55 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:51.19 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:56.14 | *** join/#asterisk-dev danjenkins (~dan@12.195.138.131) |
| 13:36.41 | *** join/#asterisk-dev danjenkins (~dan@nat/digium/x-zgharwrzeergdrkb) |
| 13:48.07 | file | today is Friday |
| 14:11.43 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-ynxjrluitjiwunsu) |
| 14:37.26 | jameswf | Gotta get down on Friday |
| 14:38.08 | file | getting down on Friday is NOT optional |
| 14:53.18 | Marquis42 | Hrm, so I'm pretty sure I've found an issue in app_stack where it fails to unlock a list. |
| 14:55.57 | Marquis42 | Corydon76-home: leifmadsen wanted me to ping you re: ^^^ |
| 14:56.00 | Marquis42 | Got a second? |
| 15:01.14 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-kdxmwipvtwqhnohe) |
| 15:06.00 | rustlebee | hey guys, you should get in on the "casual nick Friday" movement |
| 15:14.47 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-mohqekisdcuhsyvx) |
| 15:14.47 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:16.43 | opticron | rustlebee, my nick is always casual |
| 15:16.52 | rustlebee | true :) |
| 15:17.02 | rustlebee | it's mainly for people with non-casual normal nicks :) |
| 15:17.10 | opticron | and hopefully causal as well |
| 15:17.23 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:17.24 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:19.43 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:19.43 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:21.54 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 15:27.45 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-bywxqrqdsjwfxjcz) |
| 15:30.20 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:30.20 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:32.20 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:34.27 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:34.27 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:34.53 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-iarbzejbwdamorli) |
| 15:38.02 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 15:52.34 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-vxcnbhzvcgnquckd) |
| 15:58.44 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-pcqybytxxivockmx) |
| 16:11.17 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-qadjmeexkhhozfag) |
| 16:30.18 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-znoxobkfzpexqxhc) |
| 16:48.22 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-ihawactqvrivpdio) |
| 17:03.47 | Corydon76-home | Marquis42: pong |
| 17:06.24 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-nburlnffngfbefpe) |
| 17:24.28 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-jmkjwqtxmesavcey) |
| 17:30.48 | Marquis42 | Corydon76-home: back, you still around? |
| 17:32.24 | Corydon76-home | Yep |
| 17:32.55 | Marquis42 | Ah, ok. So, in stackpeek_read there's a code path where the 'oldlist' isn't unlocked. |
| 17:33.31 | Marquis42 | Latest 1.8 there's an if(!frame) at line 732 where it happens. |
| 17:34.19 | Corydon76-home | Yep, you're right |
| 17:34.45 | Marquis42 | OK, cool. That was it I think, just wanted a sanity check to make sure I wasn't missing something dumb. |
| 17:40.01 | Corydon76-home | It is one of those bugs that probably never manifested itself in bad behavior, except on BSD machines |
| 17:40.34 | Marquis42 | Well, it manifests itself in bad behavior if you run that code path a lot. :/ |
| 17:41.00 | Marquis42 | Possibly in conjunction with something else because the symptom is chan_sip stops responding entirely. |
| 17:42.28 | Corydon76-home | That's weird. The lock itself is recursive, so unless the thread was replaced for some reason, you shouldn't ever see that. |
| 17:42.40 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-ojhxlxzgtxylrjyb) |
| 17:42.51 | Corydon76-home | A reason like a transfer, for example. |
| 17:43.13 | Marquis42 | Hrm. Not sure, but I can easily make Asterisk hang with some load and some sample dialplan I have. And with the addition of the unlock, I can't replicate. |
| 17:43.16 | Marquis42 | No transfers. |
| 17:43.17 | Corydon76-home | Any channel masquerade changes the thread |
| 17:43.27 | Marquis42 | Right |
| 17:44.26 | Corydon76-home | It's the right fix; I'm just trying to figure out why it would result in bad behavior |
| 17:45.17 | Corydon76-home | BSD is obvious, because when you attempt to destroy a lock that is locked, BSD complains and refuses to dealloc the lock memory |
| 17:45.39 | Corydon76-home | whereas Linux happily lets you dump it and reinitialize the lock |
| 17:46.00 | Marquis42 | Yeah I couldn't figure that out either. We were having this hang issue, and eventually it was tracked down to some particular dialplan. So we ran it on a box with DEBUG_THREADS enabled and saw the error output that the lock was still held on hangup. That's how I figured out where that unlock should be. |
| 17:46.43 | Corydon76-home | Ah... |
| 17:47.44 | Corydon76-home | Are you using Local channels in your dialplan? |
| 17:48.01 | Marquis42 | Not in this particular dialplan, no. |
| 17:48.33 | Corydon76-home | Oh, well. It's a puzzle that doesn't need to be solved, just curious. |
| 17:48.51 | Marquis42 | Even stranger, the issue does *not* manifest itself unless the phone/UAC sends the BYE. If Asterisk does the hangup (sends the BYE) it doesn't hang. |
| 17:50.10 | Corydon76-home | Sounds like some other thread is doing the hangup, which includes the deallocation |
| 17:50.29 | Corydon76-home | in which case, that other thread wants to lock the list prior to deallocating frames |
| 17:50.46 | Marquis42 | Ah, yes, that would make some sense. |
| 17:52.11 | Corydon76-home | file would be one to ask about that code path. I'm usually given a lot more credit than I'm due when it comes to the core functionality like that. |
| 17:52.42 | Marquis42 | Heh... I can try to harass, no biggie. Thanks. But I know you did most/all of the app_stack stuff so figured I'd ping you about that at least. |
| 17:53.20 | Corydon76-home | Well, I came up with most, if not all of the concepts therein, so yes, it's my baby. |
| 17:53.28 | Marquis42 | Right, right. |
| 17:53.48 | Corydon76-home | Or one of my babies |
| 17:54.01 | Marquis42 | Indeed |
| 17:54.24 | file | what what? |
| 17:54.42 | Marquis42 | See backscroll for infos. :) |
| 17:54.48 | file | it is entirely possible for another thread to do that |
| 17:55.22 | Marquis42 | In terms of code path, is it entirely likely/definite that it would happen in particular when the phone sends the BYE vs. when Asterisk initiates the hangup? |
| 17:56.04 | file | yes, destruction can occur either in the channel thread or the thread handling traffic |
| 17:56.50 | file | I have a meeting, bbl |
| 17:57.06 | Marquis42 | np, I think you've dropped the appropriate knowledge. :) |
| 17:57.07 | Marquis42 | thanks |
| 17:58.54 | Corydon76-home | I love that you can mention file and he appears, like a genie. |
| 17:58.55 | file | chan_sip is a little weird because it can keep things around... until it finally gets destroyed |
| 17:59.37 | file | and ACTUALLY GONE |
| 18:00.03 | Marquis42 | Corydon76-home: lol, indeed |
| 18:00.47 | Corydon76-home | I'm sure he doesn't always appreciate being summoned, though. |
| 18:00.58 | Marquis42 | Genies rarely do. |
| 18:01.20 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-pkeudljeqstubjod) |
| 18:19.13 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-ckcdxpmerektjjjg) |
| 18:23.28 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 18:38.07 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-krbvrysmvurgypas) |
| 18:46.59 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.23.159.253) |
| 18:57.01 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-gbshlmnldqogbysd) |
| 19:10.13 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 19:14.52 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-cvujlohvnanflmdz) |
| 19:19.36 | hexanol | anyone has an idea on how hard it would be to implement the AMI command "Atxfer" without queueing DTMF for the "attended transfer" feature code, i.e. implementing it in a different way ? (I asked a similar question on #asterisk) |
| 19:20.03 | hexanol | my problem is, I want to use direct media with SIP and DTMF RFC2833 and be able to use the Atxfer AMI command |
| 19:20.38 | hexanol | and I have not been able to make these 3 things work at the same time |
| 19:32.53 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-lwknispnhzjqkfct) |
| 19:52.07 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-mkicdtxxzhjbyaon) |
| 20:06.21 | jql | hexanol: I don't have a solid answer, but you could try just removing AST_FEATURE_FLAG_NEEDSDTMF from the Atxfer feature in features.c |
| 20:06.43 | jql | hexanol: it's possible the "fake" queues DTMF would just work, even with direct media. *shrug* |
| 20:13.10 | hexanol | jql: that would be a hack over another hack :) I'll try it (but only monday, I must go soon) |
| 20:22.27 | *** join/#asterisk-dev danjenkins (~dan@nat/digium/x-iarkmkeqqruhpzee) |
| 20:22.41 | jql | I always make sure the lazy way won't work, first... :) |
| 20:37.37 | *** part/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 20:46.51 | *** join/#asterisk-dev danjenkins (~dan@nat/digium/x-inrirbrifcbqmayn) |
| 20:46.58 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.10.173) |
| 20:54.28 | *** join/#asterisk-dev danjenkins (~dan@nat/digium/x-ypfydagglzzhvxep) |
| 21:00.04 | jrose_atDigium | mjordan/newtonr: https://issues.asterisk.org/jira/browse/ASTERISK-23397 -- so with regards to this issue, referring to announcements in particular, a bit of history... |
| 21:00.13 | jrose_atDigium | prior to 2011, Park took two channel arguments |
| 21:00.31 | jrose_atDigium | One channel would be parked, one would be treated as the channel that parked it and would receive announcements and such. |
| 21:01.10 | jrose_atDigium | This proved problematic because there was no way to know if the channel treated as the parker could safely receive the announcements, so Richard Mudgett pulled the announcement part of that out entirely. |
| 21:01.51 | jrose_atDigium | My approach to reintroducing announcement capabilities has a bit of a different usage... |
| 21:02.09 | jrose_atDigium | Instead it works like ParkAndAnnounce. |
| 21:02.37 | jrose_atDigium | Optionally, two additional arguments may be supplied to the Park action, 'AnnounceDial' and 'AnnounceTemplate' |
| 21:03.31 | jrose_atDigium | AnnounceDial will make a call to do an announcement, AnnounceTemplate defines the way that announcement is formed (colon separated list of sound names as well as the predefied 'PARKED' which says the parking space used) |
| 21:03.37 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-pknuptoatmiqymvu) |
| 21:03.39 | jrose_atDigium | So I have one quick question... |
| 21:04.04 | jrose_atDigium | Well, two actually |
| 21:04.16 | jrose_atDigium | the first is whether or not this seems like an adequate fix for the problems described. |
| 21:04.55 | jrose_atDigium | The second is, since this is more or less a new feature, should I hold off on this for trunk? |
| 21:09.20 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 21:09.21 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:12.37 | *** join/#asterisk-dev danjenkins (~dan@nat/digium/x-slbvmrghbhqzjqgj) |
| 21:19.15 | newtonr | jrose_atDigium, that sounds a lot better than the current situation to me. Assuming the addition of those options, what would the behavior be if a user called Park with only the Channel specified and no other arguments? Or would they be able to call it that way after your modifications? |
| 21:19.41 | *** join/#asterisk-dev danjenkins (~dan@nat/digium/x-wltrikwhlkrtajqn) |
| 21:20.01 | jrose_atDigium | If Park is used with just the one channel argument, that's all that will happen. The call will be parked. No announcements will be made. When the call times out, it won't have anyone to go back to and the call will end. |
| 21:20.51 | jrose_atDigium | If a timeout dial string is specified, it will be applied as it currently is. No announcements will be made then either. |
| 21:21.15 | jrose_atDigium | Announcements are separate from everything in the actual parking logic in this case. |
| 21:21.26 | jrose_atDigium | It's basically just an extra thing that happens if both the announcement arguments are specified. |
| 21:22.15 | newtonr | That makes sense to me. So not setting a TimeoutChannel or Timeout will just assume a default timeout, rather than just parking the call indefinitely ? |
| 21:22.38 | jrose_atDigium | Well, Timeout is just an option to override the default parking lot timeout time. |
| 21:22.57 | jrose_atDigium | TimeoutChannel just specifies what the channel will try to dial if the parking lot does ComebackToOrigin. |
| 21:23.27 | jrose_atDigium | If Timeout isn't specified, the call will just be parked for however long the parking lot is set to park calls for. |
| 21:23.48 | newtonr | ahh, I see |
| 21:24.39 | jrose_atDigium | So since this seems like an adequate approach to dealing with the lack of announcements, that just leaves whether this change should go into 12.3 or if it should be a 13 feature. |
| 21:33.56 | newtonr | I'm not sure on that part. I kind of feel like it is broken without a way to direct the announcement to a specific channel, but on the other hand it does feel like a lot of change with the new options. mjordan isn't around right now, but it would be worth getting his input |
| 21:34.58 | newtonr | I think he already went home |
| 21:41.47 | *** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net) |
| 21:45.17 | *** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net) |
| 21:48.17 | *** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net) |
| 21:58.41 | *** join/#asterisk-dev calidosinho (~santiago@190.29.98.85) |
| 21:59.04 | *** join/#asterisk-dev danjenkins (~dan@nat/digium/x-nwtwdcacbbtpzaxd) |
| 22:12.28 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 22:12.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:22.12 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:22.21 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 22:22.21 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:30.30 | *** join/#asterisk-dev calidosinho (~santiago@190.29.98.85) |
| 22:41.27 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-pknuptoatmiqymvu) |
| 22:59.10 | *** join/#asterisk-dev danjenkins (~dan@12.195.138.131) |
| 23:15.15 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 23:45.44 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |