[asterisk-bugs] [JIRA] (ASTERISK-19914) Incorrect SIP cause to Asterisk cause mapping in chan_sip

[Jeremy Lainé (JIRA)]

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

Jeremy Lainé commented on ASTERISK-19914:
-----------------------------------------

Thanks so much for investigating this, it has been plaguing me for a while!

I applied your patch and am now getting the proper hangup cause for unallocated numbers.
                
> Incorrect SIP cause to Asterisk cause mapping in chan_sip
> ---------------------------------------------------------
>
>                 Key: ASTERISK-19914
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19914
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>            Reporter: Pavel Troller
>         Attachments: chan_sip.diff
>
>
> Since certain time, chan_sip incorrectly maps the SIP three digit return codes to the Asterisk internal (ITU.T based) Clear Cause values. There is a mapping function hangup_sip2cause(), but it is not used in all the places, where it should be, and various hardcoded constants are used instead, which are sometimes way off the recommended values. For example, the 404 Not found now maps to AST_CAUSE_CONGESTION (Clear Cause 34), while it should be mapped to AST_CAUSE_UNALLOCATED (Clear Cause 1). It also influences the SIP <> SIP B2BUA functionality, where a totally different response codes are retransmitted (for example, 404 changes to 503).
> A remark, why I'm considering it a MAJOR bug: Clear causes are important values and there are advanced network routing mechanisms like crankback (sending a call to another destination when the first one refuses the call), which depend on them (crankback will not occur for CC=1, but will for CC-34). Reporting incorrect clear causes may thus have impact on the network traffic. Also, wrong CCs may fool various quality monitoring/ensuring systems used by telco operators and they may behave incorrectly (for example, they may stop routing to a destination which returns a lot of 34's, which would not happen if they would have been 1's). Because Asterisk popularity grows even in the professional telco sphere, it's necessary to avoid such bugs, which may seem unimportant to a person running Asterisk just for fun or as his/her family exchange :-).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira