Summary:	ASTERISK-21899: Q850 Reason not forwarded between call legs
Reporter:	Daren Pereira (darencrew)	Labels:
Date Opened:	2013-06-11 15:59:34	Date Closed:	2013-06-11 18:45:07
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:	1.8.22.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	debian squeeze / linux	Attachments:	( 0) Q850_Reason_bug.rtf
Description:	We all know that SIP is not as precise as ISUP with reason of the call failure. For example, there are no differences between UNALLOCATED 1 NO_ROUTE_DESTINATION 3 They are all treated as "404 Not Found", that might be a big problem when running with a gateway connected to SS7 and for the one you need precise "Release Cause". We normally can use Q850 with "use_q850_reason" in sip.conf but i discovered a problem in the forwarding of the Q850 value. The value is simply dropped and replaced by the "not enough precise" HANGUPCAUSE See the attached SIP/DIALPLAN debug. You'll see the : Using Reason header for cause code: 3 and on the other leg Reason: Q.850;cause=1 The problem is, except if i missed it in all researchs i've made, there is no way to recover the Q850 value in a DIALPLAN variables. There is the "storesipcause" but it stores the "SIP 404 Not Found" message, not the causecode. So this ticket is in a way an issue, in a way a improvement to make. To bypass the problem, i made a dirty patch to chan_sip.c Instead of doing a MASTER_CHANNEL(HASH(SIP_CAUSE,[chan_name])) when "storesipcause" is set, I define a Q850 variable containing the code. Thank you for your comments. Regards
Comments:	By: Daren Pereira (darencrew) 2013-06-11 16:02:22.938-0500 SIP/DIALPLAN DEBUG showing: - unavailability of Q850 Reason code in variables - Reason code 3 becoming 1 on second leg of the call By: Daren Pereira (darencrew) 2013-06-11 16:06:24.018-0500 Dirty patch to retrieve Reason code in a dialplan variable. Dirty because no ideas on how to define a variable directly in the code. Dirty because as storesipcause it should be resources hungry... By: Matt Jordan (mjordan) 2013-06-11 18:44:56.571-0500 This is not a bug. Asterisk is a Back-to-Back User Agent. It does not forward information from one SIP dialog to another, nor should it do so. Instead, you should manipulate the hangup cause directly in the dialplan. You can override the hangup cause on a channel by calling the [Hangup|https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+Application_Hangup] application with the desired cause code during either the {{h}} extension or a [hangup handler|https://wiki.asterisk.org/wiki/display/AST/Hangup+Handlers]. The available [cause codes are documented|https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause+Mappings] on the wiki (note: drop the {{AST_}} from the string when passing it to the Hangup application). There are a few other problems here as well. # Patches are only accepted once a valid License Contributor agreement has been signed. The 'dirty patch' attached to this issue was not attached and marked as a code contribution. As such, I've removed it from the issue. In the future, if you'd like to provide a patch, please sign a license contributor agreement and mark the patch as a code contribution. # Patches must be attached in unified diff format. Rich-text files and/or other forms or markup are not accepted. # "Dirty patches" will receive little attention. Patches that are thought out and well-tested are generally accepted as contributions; patches that require significant attention from the Asterisk developer community typically languish in Jira. For these reasons, I've gone ahead and closed out this issue as "Not a Bug". Because this is an improvement that I don't think should be made to Asterisk, and because there is not an acceptable patch for said improvement, I'm closing this issue out.