[asterisk-bugs] [JIRA] (ASTERISK-23758) 500 internal server error when answering a channel with ARI

[Paul Belanger (JIRA)]

Paul Belanger created ASTERISK-23758:
----------------------------------------

             Summary: 500 internal server error when answering a channel with ARI
                 Key: ASTERISK-23758
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23758
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
            Reporter: Paul Belanger
         Attachments: debug.txt

If a channel hangs up before channels/:id/answer completes a 500 internal server error is generated.  See discussion before for is issue.

IRC discussion in asterisk-dev
--
<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
<sgriepentrog> pabelanger: what was the request that you got the 500 response from?
<pabelanger> sgriepentrog, channels/:id/answer
<pabelanger> it is reproducible with, just need to generate some fast calls with SIPp
<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?
<pabelanger> I am sorry
<pabelanger> not the CHannelStateChange event
<pabelanger> StasisStart event
<sgriepentrog> Ah.  Okay.  Yeah, that's curious.  Can you send me the sequence?  I should be able to reproduce easily.
<pabelanger> Sure
<sgriepentrog> pastebin or email is cool
<pabelanger> Ya, will pb for now
<pabelanger> will get both ARI app side and debug log
<pabelanger> sgriepentrog, ARI application: http://pastebin.com/a172yzUn
<pabelanger> sgriepentrog, asterisk debug log: http://pastebin.com/CFMcg94R
<pabelanger> the channel hangup before the http request can be processed
<file> pabelanger, entirely possible to occur.
<pabelanger> in fact ChannelStateChange up is sent, but I didn't see it on the events, likely my app stopped listening
<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
<file> we could change it to not do that
<pabelanger> okay, so I should expect 500 internal server on my app side and handle it?
<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.
<pabelanger> Hmm...
<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.
<pabelanger> so, what about 410 Gone when we try to answer a channel, but it leaves before the request finishes.
<pabelanger> Since the channel was valid
<pabelanger> and we did answer
<file> if the code is changed not to wait for media then the 500 wouldn't happen
<pabelanger> or that
<sgriepentrog> That is an ideal suggestion that should  be filed.
<file> all dependssss
<file> (doing the 410 Gone thing would actually require a core change to answer)
<pabelanger> file, what are the downside for not waiting for media?
<file> you may do something before media is fully flowing?
<file> in practice I think it rarely happens/that helps
<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?
<pabelanger> raising 500 internal error
<file> yes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)