[asterisk-bugs] [JIRA] (ASTERISK-23484) Incorrect HANGUPCAUSE value when use_q850_reason is set

[Nick Adams (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-23484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=216822#comment-216822 ] 

Nick Adams commented on ASTERISK-23484:
---------------------------------------

Firstly - I'm not a C coder so please forgive me if this is vague or misleading.

I've just conducted some regression testing and found that the value of HANGUPCAUSE in this particular situation (SIP 404 & "Reason: Q.850;cause=3") returns HANGUPCAUSE=34 in 10.5.2 and changes to HANGUPCAUSE=1 starting with 10.6 and every version thereafter. This suggests that the patch from ASTERISK-19914 is indeed overwriting the "use_q850_reason" directive.

This still seems like a herring as I don't believe that HANGUPCAUSE=34 is correct as "use_q850_reason" implies that the Reason header should be used to set HANGUPCAUSE and therefore be equal to "3" in my example. Line 23760 of chan_sip.c correctly sets the HANGUPCAUSE from the q850 code but then, and this is where I'm not sure, chan_sip.c:24071 seems to overwrite this based on the hangup_sip2cause/SIP 404 translation. 

The patch from ASTERISK-19914 should only "ast_queue_hangup_with_cause" if the cause hasn't already been set. Am I on the right track here?

> Incorrect HANGUPCAUSE value when use_q850_reason is set
> -------------------------------------------------------
>
>                 Key: ASTERISK-23484
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23484
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_local, Channels/chan_sip/General
>    Affects Versions: 11.8.1
>         Environment: Ubuntu 13.04; x86_64; Kernal 3.8.0-27-generic
>            Reporter: Nick Adams
>            Assignee: Nick Adams
>            Severity: Minor
>         Attachments: myDebugLog
>
>
> My provider returns SIP 404 response for a Q.850 code of 3 ("No route to destination"). I want Asterisk to prioritise the Q.850 Reason code instead of using the SIP 404 when populating the HANGUPCAUSE variable as the Q.850 code gives me more detail and greater control in my dialplan.
> I've set "use_q850_reason=yes" in sip.conf and Asterisk correctly identifies the Reason header:
> {quote}
> SIP/2.0 404 Not Found
> Via: SIP/2.0/UDP 172.X.X.X:5060;branch=z9hG4bK728b99fd;rport=5060
> Max-Forwards: 68
> From: "Anonymous" <sip:anonymous at anonymous.invalid>;tag=as31832f10
> To: <sip:614XXXXXXXX at 172.X.X.X:5060>;tag=Ztm3ZB2Xr0jgp
> Call-ID: 59a1c91a4be33a1b2fc4a90f5c5e8224 at 172.X.X.X:5060
> CSeq: 102 INVITE
> User-Agent: FreeSWITCH-mod_sofia/1.2.10+git~20130624T144607Z~998ae35dbf
> Accept: application/sdp
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, NOTIFY
> Supported: timer, precondition, path, replaces
> Allow-Events: talk, hold, conference, refer
> Reason: Q.850;cause=3;text="NO_ROUTE_DESTINATION"
> Content-Length: 0
> <------------->
> --- (14 headers 0 lines) ---
> Using Reason header for cause code: 3
> {quote}
> I use the below dialplan to originate the call into:
> {quote}
> exten => s,1,Dial(SIP/MyProvider/614xxxxxxxx,30,g)
> exten => s,n,NoOp(DEBUG1:HANGUPCAUSE=$\{HANGUPCAUSE\} DIALSTATUS=$\{DIALSTATUS\})
> exten => s,n,Hangup
> exten => t,1,Hangup
> exten => h,1,NoOp(DEBUG2: HANGUPCAUSE=$\{HANGUPCAUSE\} DIALSTATUS=$\{DIALSTATUS\})
> {quote}
> Despite Asterisk correctly extracting the Reason code ("3"), the HANGUPCAUSE returns "1":
> {quote}
> Executing [614XXXXXX at CallSpooler:2] NoOp("Local/614XXXXXX at CallSpooler-00000001;2", "DEBUG1:  HANGUPCAUSE=1 DIALSTATUS=CHANUNAVAIL") in new stack
> -- Executing [h at CallSpooler:1] NoOp("Local/614XXXXXX at CallSpooler-00000000;2", "DEBUG2: HANGUPCAUSE=1 DIALSTATUS=CHANUNAVAIL") in new stack
> {quote}
> The expectation is that the HANGUPCAUSE variable should be set to "3" however it seems to be set to "1". I'm not sure if there is a conflict between the HANGUPCAUSE of the Local channel as opposed to the SIP channel however the Q.850 reason seems to be clobbered.



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