Summary:	ASTERISK-19914: Incorrect SIP cause to Asterisk cause mapping in chan_sip
Reporter:	Pavel Troller (patrol-cz)	Labels:
Date Opened:	2012-05-25 14:08:20	Date Closed:	2012-06-04 17:00:20
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) chan_sip.diff
Description:	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 :-).
Comments:	By: Pavel Troller (patrol-cz) 2012-05-25 14:11:59.405-0500 A patch proposal. It passed a minimal set of tests and seems functional in the lab as well as real installation. By: Walter Doekes (wdoekes) 2012-05-29 01:45:00.609-0500 Thanks. Added test case here that confirms at least part of the expected behaviour of your patch: https://reviewboard.asterisk.org/r/1951/ By: Jeremy Lainé (sharky) 2013-05-31 08:16:30.280-0500 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.