[asterisk-bugs] [JIRA] (ASTERISK-23484) Incorrect HANGUPCAUSE value when use_q850_reason is set
Rusty Newton (JIRA)
noreply at issues.asterisk.org
Fri Apr 4 18:21:18 CDT 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-23484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217041#comment-217041 ]
Rusty Newton edited comment on ASTERISK-23484 at 4/4/14 6:21 PM:
-----------------------------------------------------------------
bq. Firstly - I'm not a C coder so please forgive me if this is vague or misleading.
I'm not a C developer either, so I'm going to refrain from commenting on the code.
It is useful to note that from 10 to 11, I believe HANGUPCAUSE went from channel variable to function. I'm not going to address 10 in my testing or research since it is end of life and no longer supported.
I tested a few scenarios to help us all understand the current behavior of HANGUPCAUSE, as I rarely use it and it was a little confusing combined with the use_q850_reason option. I used a pre-dial handler to set a hangup handler on the created outbound channel, so that we could see the returned HANGUPCAUSE values on both the dialing (inbound) and outbound channels.
I then had Asterisk call SIPp, where SIPp returns a SIP 404 with a Reason header just like yours "Reason: Q.850;cause=3;text="NO_ROUTE_DESTINATION""
I verified that in test cases where I enabled use_q850_reason, that in the debug I saw "chan_sip.c: Using Reason header for cause code: 3" during the processing of the 404. I presume that in these cases I should see some effect on what HANGUPCAUSE returns based on the description of use_q850_reason in sip.conf.sample
In the below excerpts of my test output, first you see HANGUPCAUSE output from the created outbound channel hanging up, then below it you'll see output from the dialing channel hanging up. Also, excuse some of the wiki formatting. It doesn't like curly braces and parens.
With use_q850_reason *undefined* and calling HANGUPCAUSE with no arguments
{noformat}
-- Executing [s at hdlr1:1] Verbose("SIP/10.24.18.124:5061-00000002", "0,"HANGUP HANDLER - HANGUPCAUSE = 1 DIALSTATUS = "") in new stack
<snip>
-- Executing [888 at from-internal:2] Verbose("SIP/6001-00000001", "0,"HANGUPCAUSE = 1 DIALSTATUS = CHANUNAVAIL"") in new stack
{noformat}
With use_q850_reason=yes and calling HANGUPCAUSE with no arguments
{noformat}
-- Executing [s at hdlr1:1] Verbose("SIP/10.24.18.124:5061-00000001", "0,"HANGUP HANDLER - HANGUPCAUSE = 1 DIALSTATUS = "") in new stack
<snip>
-- Executing [888 at from-internal:2] Verbose("SIP/6001-00000000", "0,"HANGUPCAUSE = 1 DIALSTATUS = CHANUNAVAIL"") in new stack
{noformat}
With use_q850_reason *undefined* and calling HANGUPCAUSE(${CHANNEL},ast)
{noformat}
-- Executing [s at hdlr1:1] Verbose("SIP/10.24.18.124:5061-00000001", "0,"HANGUP HANDLER - HANGUPCAUSE = Unallocated (unassigned) number DIALSTATUS = "") in new stack
<snip>
[Apr 4 17:08:27] WARNING[16598][C-00000000]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel SIP/6001-00000000
-- Executing [888 at from-internal:2] Verbose("SIP/6001-00000000", "0,"HANGUPCAUSE = DIALSTATUS = CHANUNAVAIL"") in new stack
{noformat}
With use_q850_reason=yes and calling HANGUPCAUSE(${CHANNEL},ast)
{noformat}
-- Executing [s at hdlr1:1] Verbose("SIP/10.24.18.124:5061-00000001", "0,"HANGUP HANDLER - HANGUPCAUSE = Unallocated (unassigned) number DIALSTATUS = "") in new stack
<snip>
[Apr 4 17:01:39] WARNING[16438][C-00000000]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel SIP/6001-00000000
-- Executing [888 at from-internal:2] Verbose("SIP/6001-00000000", "0,"HANGUPCAUSE = DIALSTATUS = CHANUNAVAIL"") in new stack
{noformat}
With use_q850_reason *undefined* and calling HANGUPCAUSE(${CHANNEL},tech)
{noformat}
-- Executing [s at hdlr1:1] Verbose("SIP/10.24.18.124:5061-00000001", "0,"HANGUP HANDLER - HANGUPCAUSE = SIP 404 Not Found DIALSTATUS = "") in new stack
<snip>
[Apr 4 17:06:48] WARNING[16545][C-00000000]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel SIP/6001-00000000
-- Executing [888 at from-internal:2] Verbose("SIP/6001-00000000", "0,"HANGUPCAUSE = DIALSTATUS = CHANUNAVAIL"") in new stack
{noformat}
With use_q850_reason=yes and calling HANGUPCAUSE(${CHANNEL},tech)
{noformat}
-- Executing [s at hdlr1:1] Verbose("SIP/10.24.18.124:5061-00000001", "0,"HANGUP HANDLER - HANGUPCAUSE = SIP 404 Not Found DIALSTATUS = "") in new stack
<snip>
[Apr 4 17:03:59] WARNING[16491][C-00000000]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel SIP/6001-00000000
-- Executing [888 at from-internal:2] Verbose("SIP/6001-00000000", "0,"HANGUPCAUSE = DIALSTATUS = CHANUNAVAIL"") in new stack
{noformat}
A few observations, some of which may be undefined behavior or bugs.
# The [documentation|https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+Function_HANGUPCAUSE] doesn't specify what HANGUPCAUSE should return when called with no arguments. In your problem scenario, you are calling it with no arguments. I tested that in my first two examples. Calling HANGUPCAUSE with no arguments appears to be returning a Q.850 cause code of 1, with no description. This doesn't appear to be the "Asterisk translated cause code" or the "Channel technology specific" cause code described in the HANGUPCAUSE documentation.
# When calling HANGUPCAUSE, in the second argument field, you can pass two different values to specify that we want either Asterisk's translated cause codes, or Channel technology specific cause codes. I test these in the third through sixth examples.
## The Asterisk translated cause codes come out fine on the outbound channel and are unaffected by use_q850_reason
## The technology specific cause codes come out fine on the outbound channel and are unaffected by use_q850_reason
## Neither the the ast or tech options return any data for the dialing channel.
## I don't know if use_q850_reason is supposed to overwrite both the translated and channel tech cause information. It doesn't appear to overwrite either in my testing, for either channel, which I think represents your reported issue still.
I don't think the HANGUPCAUSE function is using the information from the Reason header at all when use_q850_reason is enabled. Also, I don't think use_q850_reason should overwrite the information HANGUPCAUSE provides when passed the ast or tech options. There should probably be a third option like "q850", but it seems that calling HANGUPCAUSE without arguments returns a q850 cause code with no description.... so, yeah someone should investigate and fix, then document this behavior. I'm not sure what the best solution is.
was (Author: rnewton):
bq. Firstly - I'm not a C coder so please forgive me if this is vague or misleading.
I'm not a C developer either, so I'm going to refrain from commenting on the code.
It is useful to note that from 10 to 11, I believe HANGUPCAUSE went from channel variable to function. I'm not going to address 10 in my testing or research since it is end of life and no longer supported.
I tested a few scenarios to help us all understand the current behavior of HANGUPCAUSE, as I rarely use it and it was a little confusing combined with the use_q850_reason option. I used a pre-dial handler to set a hangup handler on the created outbound channel, so that we could see the returned HANGUPCAUSE values on both the dialing (inbound) and outbound channels.
I then had Asterisk call SIPp, where SIPp returns a Reason header just like yours "Reason: Q.850;cause=3;text="NO_ROUTE_DESTINATION""
I verified that in test cases where I enabled use_q850_reason, that in the debug I saw "chan_sip.c: Using Reason header for cause code: 3" during the processing of the 404.
In the below examples, first you see HANGUPCAUSE output from the created outbound channel hanging up, then below it you'll see output from the dialing channel hanging up. Also, excuse some of the wiki formatting. It doesn't like curly braces and parens.
With use_q850_reason *undefined* and calling HANGUPCAUSE with no arguments
{noformat}
-- Executing [s at hdlr1:1] Verbose("SIP/10.24.18.124:5061-00000002", "0,"HANGUP HANDLER - HANGUPCAUSE = 1 DIALSTATUS = "") in new stack
<snip>
-- Executing [888 at from-internal:2] Verbose("SIP/6001-00000001", "0,"HANGUPCAUSE = 1 DIALSTATUS = CHANUNAVAIL"") in new stack
{noformat}
With use_q850_reason=yes and calling HANGUPCAUSE with no arguments
{noformat}
-- Executing [s at hdlr1:1] Verbose("SIP/10.24.18.124:5061-00000001", "0,"HANGUP HANDLER - HANGUPCAUSE = 1 DIALSTATUS = "") in new stack
<snip>
-- Executing [888 at from-internal:2] Verbose("SIP/6001-00000000", "0,"HANGUPCAUSE = 1 DIALSTATUS = CHANUNAVAIL"") in new stack
{noformat}
With use_q850_reason *undefined* and calling HANGUPCAUSE(${CHANNEL},ast)
{noformat}
-- Executing [s at hdlr1:1] Verbose("SIP/10.24.18.124:5061-00000001", "0,"HANGUP HANDLER - HANGUPCAUSE = Unallocated (unassigned) number DIALSTATUS = "") in new stack
<snip>
[Apr 4 17:08:27] WARNING[16598][C-00000000]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel SIP/6001-00000000
-- Executing [888 at from-internal:2] Verbose("SIP/6001-00000000", "0,"HANGUPCAUSE = DIALSTATUS = CHANUNAVAIL"") in new stack
{noformat}
With use_q850_reason=yes and calling HANGUPCAUSE(${CHANNEL},ast)
{noformat}
-- Executing [s at hdlr1:1] Verbose("SIP/10.24.18.124:5061-00000001", "0,"HANGUP HANDLER - HANGUPCAUSE = Unallocated (unassigned) number DIALSTATUS = "") in new stack
<snip>
[Apr 4 17:01:39] WARNING[16438][C-00000000]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel SIP/6001-00000000
-- Executing [888 at from-internal:2] Verbose("SIP/6001-00000000", "0,"HANGUPCAUSE = DIALSTATUS = CHANUNAVAIL"") in new stack
{noformat}
With use_q850_reason *undefined* and calling HANGUPCAUSE(${CHANNEL},tech)
{noformat}
-- Executing [s at hdlr1:1] Verbose("SIP/10.24.18.124:5061-00000001", "0,"HANGUP HANDLER - HANGUPCAUSE = SIP 404 Not Found DIALSTATUS = "") in new stack
<snip>
[Apr 4 17:06:48] WARNING[16545][C-00000000]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel SIP/6001-00000000
-- Executing [888 at from-internal:2] Verbose("SIP/6001-00000000", "0,"HANGUPCAUSE = DIALSTATUS = CHANUNAVAIL"") in new stack
{noformat}
With use_q850_reason=yes and calling HANGUPCAUSE(${CHANNEL},tech)
{noformat}
-- Executing [s at hdlr1:1] Verbose("SIP/10.24.18.124:5061-00000001", "0,"HANGUP HANDLER - HANGUPCAUSE = SIP 404 Not Found DIALSTATUS = "") in new stack
<snip>
[Apr 4 17:03:59] WARNING[16491][C-00000000]: func_hangupcause.c:140 hangupcause_read: Unable to find information for channel SIP/6001-00000000
-- Executing [888 at from-internal:2] Verbose("SIP/6001-00000000", "0,"HANGUPCAUSE = DIALSTATUS = CHANUNAVAIL"") in new stack
{noformat}
A few observations, some of which may be undefined behavior or bugs.
# The [documentation|https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+Function_HANGUPCAUSE] doesn't specify what HANGUPCAUSE should return when called with no arguments. In your problem scenario, you are calling it with no arguments. I tested that in my first two examples. Calling HANGUPCAUSE with no arguments appears to be returning a Q.850 cause code of 1, with no description. This doesn't appear to be the "Asterisk translated cause code" or the "Channel technology specific" cause code described in the HANGUPCAUSE documentation.
# When calling HANGUPCAUSE, in the second argument field, you can pass two different values to specify that we want either Asterisk's translated cause codes, or Channel technology specific cause codes. I test these in the third through sixth examples.
## The Asterisk translated cause codes come out fine on the outbound channel and are unaffected by use_q850_reason
## The technology specific cause codes come out fine on the outbound channel and are unaffected by use_q850_reason
## Neither the the ast or tech options return any data for the dialing channel.
## I don't know if use_q850_reason is supposed to overwrite both the translated and channel tech cause information. It doesn't appear to overwrite either in my testing, for either channel, which I think represents your reported issue still.
I don't think the HANGUPCAUSE function is using the information from the Reason header at all when use_q850_reason is enabled. Also, I don't think use_q850_reason should overwrite the information HANGUPCAUSE provides when passed the ast or tech options. There should probably be a third option like "q850", but it seems that calling HANGUPCAUSE without arguments returns a q850 cause code with no description.... so, yeah someone should investigate and fix, then document this behavior. I'm not sure what the best solution is.
> 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_sip/General, Channels/General, Functions/func_hangupcause
> Affects Versions: 11.8.1
> Environment: Ubuntu 13.04; x86_64; Kernal 3.8.0-27-generic
> Reporter: Nick Adams
> Assignee: Rusty Newton
> 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)
More information about the asterisk-bugs
mailing list