Summary:	ASTERISK-23758: 500 internal server error when answering a channel with ARI
Reporter:	Paul Belanger (pabelanger)	Labels:
Date Opened:	2014-05-19 10:52:04	Date Closed:	2014-05-19 14:51:54
Priority:	Major	Regression?
Status:	Closed/Complete	Components:
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) ari.txt ( 1) debug.txt
Description:	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.
Comments:	By: Paul Belanger (pabelanger) 2014-05-19 10:55:33.417-0500 This is easily reproducable using stock SIPp and the uac scenario. ARI events are actually generated about the ChannelStateChange, but unsure if they are actually transmitted (don't believe so). By: Paul Belanger (pabelanger) 2014-05-19 11:23:52.100-0500 okay, just confirmed even though 500 internal server is returned from ARI, a ChannelStateChange event is received on the WS.  Which, because the state is up, the I process to bridge the channel.  Which then generates a 400 'Channel not found'.  So, more error handling on my side of the app needs to be done, but ideally if we generate an internal server, we should not send out stasis events indicating the channel is up.