| 00:34.28 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 00:43.52 | tm1000 | jrose_atDigium: You around? |
| 01:29.11 | *** join/#asterisk-dev spditner (~simon@206-248-133-124.dsl.teksavvy.com) |
| 04:40.08 | *** join/#asterisk-dev jagruti_ (~root@122.170.48.139) |
| 04:40.25 | *** part/#asterisk-dev jagruti_ (~root@122.170.48.139) |
| 05:06.38 | *** join/#asterisk-dev jagruti_ (~root@122.179.148.47) |
| 05:06.55 | *** part/#asterisk-dev jagruti_ (~root@122.179.148.47) |
| 05:47.03 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 05:47.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:47.38 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:47.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:56.41 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:7d7b:7c97:bda7:b053) |
| 08:05.37 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 08:05.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:14.41 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 08:32.10 | *** join/#asterisk-dev jagruti_ (~root@122.179.145.59) |
| 08:32.18 | *** part/#asterisk-dev jagruti_ (~root@122.179.145.59) |
| 08:36.13 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 08:36.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:20.42 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 09:20.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:22.48 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 09:24.56 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:24.57 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:25.41 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-yplusedzheruootq) |
| 12:25.41 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 12:31.13 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 13:18.11 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187.76.181.102) |
| 13:24.40 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 13:32.38 | *** join/#asterisk-dev jagruti_ (~root@122.179.141.242) |
| 13:32.44 | *** part/#asterisk-dev jagruti_ (~root@122.179.141.242) |
| 13:35.46 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 13:35.47 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 13:41.45 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:02.34 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mpzcqdgstbupjhnr) |
| 14:02.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:07.54 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:07.54 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:21.03 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-jcaylpqexwluzjag) |
| 14:29.47 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-255-171-52.mci.googlefiber.net) |
| 14:41.08 | *** join/#asterisk-dev jagruti_ (~root@122.169.6.164) |
| 14:41.12 | *** part/#asterisk-dev jagruti_ (~root@122.169.6.164) |
| 14:44.44 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-esuporrhuomjkamo) |
| 15:18.42 | jrose_atDigium | tm1000: Am now. |
| 15:22.50 | pabelanger | Question about ARI. Is there any channel locking when POST something via HTTP (ari) into asterisk? I assume yes? Reason being, I ran into an issue where I get a ChannelStateChange event, so I extract the channel ID, send answer over ARI. But, before the HTTP request can finish, my channel hangs up and ARI raises a http 500 internal error message |
| 15:25.52 | sgriepentrog | pabelanger: what was the request that you got the 500 response from? |
| 15:26.11 | pabelanger | sgriepentrog, channels/:id/answer |
| 15:27.02 | pabelanger | it is reproducible with, just need to generate some fast calls with SIPp |
| 15:27.28 | sgriepentrog | Strange. If the channel had hung up after origination, but before you got the answer processed, I would have expected you to get a 404. Is the ChannelStateChange event coming in before or after a StasisStart? |
| 15:27.56 | pabelanger | I am sorry |
| 15:28.03 | pabelanger | not the CHannelStateChange event |
| 15:28.06 | pabelanger | StasisStart event |
| 15:28.31 | sgriepentrog | Ah. Okay. Yeah, that's curious. Can you send me the sequence? I should be able to reproduce easily. |
| 15:28.52 | pabelanger | Sure |
| 15:29.00 | sgriepentrog | pastebin or email is cool |
| 15:29.09 | pabelanger | Ya, will pb for now |
| 15:29.17 | pabelanger | will get both ARI app side and debug log |
| 15:34.03 | tm1000 | jrose_atDigium: I was looking at a conversation you had in here a few days about about parking which is exactly what I wanted to ask you about. |
| 15:34.10 | tm1000 | it was about bridging and MOH |
| 15:34.16 | jrose_atDigium | alrighty |
| 15:34.21 | tm1000 | and the restarting of the MOH, if you dont remember I can pull up the logs |
| 15:34.48 | jrose_atDigium | Nah, I still have it. |
| 15:34.52 | tm1000 | if phone1 does an attended transfer of phone2 into a parking lot and then phone1 hangs up the MOH for phone2 restarts, |
| 15:35.03 | pabelanger | sgriepentrog, ARI application: http://pastebin.com/a172yzUn |
| 15:35.18 | tm1000 | is it a bug or is that intended. because its really awkward when you have the MOH restart and it choses a different random playback |
| 15:35.37 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:35.39 | pabelanger | sgriepentrog, asterisk debug log: http://pastebin.com/CFMcg94R |
| 15:35.41 | tm1000 | also for a brief moment it actually plays MOH twice. |
| 15:35.51 | tm1000 | jrose_atDigium: ^ |
| 15:35.53 | jrose_atDigium | that right there should be impossible. |
| 15:36.04 | pabelanger | the channel hangup before the http request can be processed |
| 15:36.22 | jrose_atDigium | The code playing MOH to the channel shouldn't be able to play two sets of MOH to the channel at once. |
| 15:36.35 | tm1000 | jrose_atDigium: even crazier when I listen to the recording I can hear the phone1 when it hangs up |
| 15:36.55 | jrose_atDigium | As for restarting MOH, it isn't necessarily a bug, but that doesn't really mean it's intentional either. |
| 15:37.08 | tm1000 | jrose_atDigium: should I report the MOH restarting? |
| 15:37.10 | jrose_atDigium | It's just a quirk of entering the holding bridge for parking. |
| 15:37.13 | tm1000 | for your to track? |
| 15:37.43 | file | pabelanger, entirely possible to occur. |
| 15:37.45 | tm1000 | jrose_atDigium: But it hasnt been like this until recently right? or have I just not been following? |
| 15:38.00 | pabelanger | in fact ChannelStateChange up is sent, but I didn't see it on the events, likely my app stopped listening |
| 15:38.06 | jrose_atDigium | The bridging framework is guaranteed to change some behaviors. |
| 15:38.34 | tm1000 | jrose_atDigium: ah so it’s a 12 only issue then. Well…is there something I can do about it? File bug? or? |
| 15:38.53 | jrose_atDigium | Filing a report for the double MOH issue seems appropriate. |
| 15:39.06 | file | pabelanger, it's because of the answer code waiting for audio to flow for a minimum amount of time - the hangup occurs when it is doing that |
| 15:39.29 | file | we could change it to not do that |
| 15:39.47 | pabelanger | okay, so I should expect 500 internal server on my app side and handle it? |
| 15:39.57 | jrose_atDigium | I'm a little less sure on the simple fact that MOH is restarting. |
| 15:40.00 | sgriepentrog | So the 500 is just an artifact of how early in the sequence - as in it was a valid channel id when requested, but then it died. |
| 15:40.08 | tm1000 | jrose_atDigium: ok thanks. I will do that and I’ll mkae sure the other things I talked about as well apply too (double MOH) as the “double moh” might just be a result of the bridging problem |
| 15:40.28 | jrose_atDigium | Yeah, since it's all related they might both get fixed at once. |
| 15:40.33 | tm1000 | jrose_atDigium: well I do know it’s definately bridging because it says “restarting simple bridging” <— something like that. Will get the proper logs for you of course |
| 15:40.38 | tm1000 | jrose_atDigium: exactly |
| 15:40.45 | *** join/#asterisk-dev coreyf1513 (~cfarrell@71-80-124-168.dhcp.wlmn.ct.charter.com) |
| 15:40.48 | pabelanger | Hmm... |
| 15:40.48 | sgriepentrog | Just as an fyi, a 500 is the default "i'm not sure what happened but something went wrong" response. It can happen on any reqeust. |
| 15:40.56 | tm1000 | jrose_atDigium: I’ll open a ticket later today |
| 15:40.59 | jrose_atDigium | Alrighty, good deal. |
| 15:41.10 | tm1000 | is glad pabelanger is sussing out all the ARI bugs for us ;-) |
| 15:44.03 | pabelanger | so, what about 410 Gone when we try to answer a channel, but it leaves before the request finishes. |
| 15:44.29 | pabelanger | Since the channel was valid |
| 15:44.32 | pabelanger | and we did answer |
| 15:44.33 | file | if the code is changed not to wait for media then the 500 wouldn't happen |
| 15:44.42 | pabelanger | or that |
| 15:44.47 | sgriepentrog | That is an ideal suggestion that should be filed. |
| 15:45.00 | file | all dependssss |
| 15:45.25 | file | (doing the 410 Gone thing would actually require a core change to answer) |
| 15:46.04 | pabelanger | file, what are the downside for not waiting for media? |
| 15:46.05 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 15:46.30 | file | you may do something before media is fully flowing? |
| 15:47.06 | file | in practice I think it rarely happens/that helps |
| 15:48.46 | pabelanger | file, okay, so if I create an issue what is the technical explanation that is happening? On answer, asterisk waits for media, during that time a channel can be hung up? |
| 15:48.51 | pabelanger | raising 500 internal error |
| 15:48.57 | file | yes. |
| 15:55.39 | pabelanger | thanks, issue created |
| 16:16.03 | pabelanger | okay, so here is the bad thing |
| 16:16.12 | pabelanger | HTTP answer to ARI returns 500 |
| 16:16.44 | pabelanger | but an ChannelStateChange UP is received over the WS |
| 16:17.07 | pabelanger | then, eventually a StasisEnd |
| 16:56.34 | mjordan | pabelanger: I'd look to see in your Asterisk log what actually Answered the channel. If the Answer occurred due to the HTTP request, then yes, there's something wrong there. |
| 16:56.50 | mjordan | If the Answer occurred due to something else, then there's not much wrong there. |
| 16:58.36 | file | mjordan, it answered because of his request |
| 16:58.38 | pabelanger | mjordan, what else are you thinking could answer, like dialplan application? Or another ARI request? |
| 16:58.43 | pabelanger | but yes, what file said |
| 16:59.11 | mjordan | k, that's odd then |
| 16:59.17 | mjordan | or at least, that's my initial impression :-) |
| 16:59.19 | file | not REALLY |
| 16:59.32 | file | ast_answer actually answers AND waits up to 500ms for a media frame to flow |
| 16:59.55 | mjordan | ah... I missed that part. |
| 17:00.03 | mjordan | scrolls back up |
| 17:00.20 | file | so in that 500ms it gets hung up, so the channel is both answered and hung up |
| 17:01.27 | mjordan | in the case of ARI, that does feel like an implementation decision leaking through |
| 17:01.43 | file | yeah |
| 17:02.02 | file | s/ast_answer/ast_raw_answer/ |
| 17:02.05 | file | problem solved! |
| 17:02.45 | mjordan | pabelanger: you should write that patch! :-) |
| 17:03.10 | pabelanger | mjordan, too busy writing apps for ARI |
| 17:03.13 | pabelanger | :) |
| 17:04.14 | pabelanger | so, the fix would be to remove ast_answer() and do a new funtion that just answers, regardless of media frames that follow? |
| 17:04.36 | file | no, that function already exists - it's called ast_raw_answer |
| 17:04.46 | pabelanger | Oh, in that case |
| 17:04.59 | pabelanger | let me see if I can find where it lives |
| 17:08.26 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-255-171-52.mci.googlefiber.net) |
| 17:10.29 | pabelanger | hey, I fixed it |
| 17:10.33 | pabelanger | one liner :) |
| 17:11.38 | pabelanger | now my bridge command fails, but that is fine, since that channel actually hung up |
| 17:11.53 | pabelanger | get that file a beer |
| 17:12.00 | mjordan | or a martini |
| 17:13.04 | pabelanger | okay, so what is the proper explanation for the commit message. Replace __ast_answer with ast_raw_answer because we don't want media detection? |
| 17:14.11 | mjordan | pabelanger: probably that media detection just isn't necessary in this case. |
| 17:14.24 | mjordan | looks closer |
| 17:15.06 | mjordan | yeah, that feels adequate |
| 17:15.27 | pabelanger | okay, thanks |
| 17:15.30 | pabelanger | posting patch |
| 17:15.57 | mjordan | file: off the cuff, why does the answer routine wait for audio to flow? |
| 17:21.04 | pabelanger | https://reviewboard.asterisk.org/r/3549/ |
| 17:23.43 | file | mjordan, to reduce the potential for cut-off audio elsewhere? |
| 17:23.47 | file | kpfleming added it long ago |
| 17:23.49 | mjordan | works for me |
| 17:29.17 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 17:39.11 | *** join/#asterisk-dev danjenkins (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 17:54.52 | newtonr | Anyone know if "Brett Sutton" is on IRC ? |
| 19:51.13 | JunK-Y | newtonr: not that I know. |
| 20:04.01 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 20:04.01 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 12.0.0 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 20:11.59 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 20:27.30 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 20:27.30 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:10.35 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 23:10.52 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 23:10.54 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:14.54 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-jcaylpqexwluzjag) |