Summary:	ASTERISK-09458: Can I have a variable available after Dial() for the SIP Response?
Reporter:	Robert Lister (rlister)	Labels:
Date Opened:	2007-05-16 21:06:44	Date Closed:	2007-05-17 07:42:02
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Ala ${SIP_HEADER(n)} Dial() seems to treat most call-setup problems as DIALSTATUS= CONGESTION, and some are NOANSWER, but I want to know the SIP response code, so I could return the right tones to the user, not just a congestion tone for every fault. Anyone know a way to find out that information, so for example I want the "604" out of this lot, in a variable, say, ${SIP_RESPONSE}    -- Called xxxxxxxxxxx@sipgw    -- Got SIP response 604 "Does Not Exist Anywhere" back from x.x.x.x  == No one is available to answer at this time (1:0/0/0)    -- Executing NoOp("SIP/42105-d313f470", "-- DIALSTATUS is: NOANSWER") in new stack    -- Executing Goto("SIP/42105-d313f470", "s-NOANSWER|1") in new stack    -- Executing PlayTones("SIP/42105-d313f470", "Unobtainable") in new stack    -- Executing Wait("SIP/42105-d313f470", "10") in new stack I need to know the actual cause of the call setup failure returned from my ISDN SIP gateway boxes, so that I can either return a meaningful tone (say, unobtainable rather than "congestion" tone) to the user, or do some other action for example failover to another gateway, if the SIP gateway actually returns a real Congestion state. If it's an asterisk fake congestion that means "you misdialled this number" then that's not *congestion* in the strictest sense, it's a call setup failure (number-unallocated from ISDN != congestion/network busy.) At the moment it's impossible for me to detect the difference between the two. Either that, or better define on DIALSTATE what is a call setup failure and what is CONGESTION (say, another DIALSTATE called FAILED?) Longer term, it might be better to have in the config a mapping table of SIP response codes <-> DIALSTATE so that I can customise what I want to happen with specific codes if the defaulty one doesn't do what I want. Although I appreciate that might not be an easy thing to do.
Comments:	By: Igor Goncharovsky (igorg) 2007-05-16 22:09:42 Hmm, I think there is no need to introduce new variable. There is variable HANGUPCAUSE, that have PRI hangup cause code. And there is mapping to SIP code table described in RFC3398 (http://www.ietf.org/rfc/rfc3398.txt). By: Olle Johansson (oej) 2007-05-17 01:41:04 This is an FAQ that you can find answers on either on the mailing list, by reading available documentation or googling the mailing list archives. Asterisk is a multiprotocol PBX. We can't handle individual protocol signalling error codes in the dialplan, since one dial can use multiple protocols. It wouldn't make any sense at all to return SIP codes alongside with IAX and ISDN error codes, so we translate and aggregate into one error code in HANGUPCAUSE, which is the most detailed error code you can get. Next time you have a question, please use the mailing lists. Feel free to report bugs and post patches here in the issue tracker! Cheers /O By: Robert Lister (rlister) 2007-05-17 04:49:20 Reading various docs, I am not sure if hangupcause is what I want, but I will try it and see what happens. I did try the list, and googling lots and that didn't seem to return anything. HANGUPCAUSE seems to apply only to Zap/ISDN channels if I read it correctly??? I understand the limitation on Dial within the asterisk design, but surely returning CONGESTION for almost every SIP call setup error is just not useful enough to make a sensible call routing decision. A new status perhaps for UNOBTAINABLE/FAIL ? Thanks, Rob By: Igor Goncharovsky (igorg) 2007-05-17 04:58:07 Please read docs and try, before post to tracker. HANGUPCAUSE set for IAX2, SIP and others. Try to do some Congestion calls and watch for HANGUPCAUSE variable. If  you see some diferent  from RFC3398, you can open a bug... By: Robert Lister (rlister) 2007-05-17 05:42:27 Hmm. Okay. Thanks for answering that. So what we're saying is: - We return from Dial(SIP/xxx) DIALSTATUS CONGESTION even when it isn't (broken behavior imho, because I cannot tell a genuine congestion from asterisk's "oh well, I don't know what happened, I'll return congestion." congestion. This means that DIALSTATUS = CONGESTION is completely meaningless since it can mean lots of things. - I can access virtually every SIP header via ${SIP_HEADER(foo)} even though strictly speaking I'm not supposed to. (I only use SIP and not any other protocols, so naturally I could not expect that to work for other protocols.) - I can even add new SIP headers and munge the caller id. - Yet I cannot see the simple response we got back anywhere (although annoyingly it is reported on the console, but we cannot see in the dialplan!) - My ISDN gateway (Patton SmartNode) carefully translates the ISDN cause code into a SIP error response, only for asterisk to completely ignore it and turn it into back into some psudeo ISDN cause code, nothing to do with asterisk's SIP session with the gateway. RFC 3398 was already taken care of by the Patton gateway, and it returned, say 404, only for asterisk to throw it away? This seems a bit over complicated, but I'll give it a shot. And I will update voip-info.org wiki page on both dialstatus and hangupcause documentation which does not mention any of these quirks at present. By: Olle Johansson (oej) 2007-05-17 07:42:02 Please don't re-open for discussion. We've stated that we translate from SIP to ISDN cause codes both ways, like your patton box. For discussions, please use the mailing list, web forums etc.