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

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-23758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-23758:
-----------------------------------

    Target Release Version/s: 12.3.0

> 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
>      Target Release: 12.3.0
>
>         Attachments: ari.txt, 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)