[asterisk-dev] Wrong SIP to SIP SIP Cause mapping

[Pavel Troller]

> ----- Original Message -----
> > From: "Pavel Troller" <patrol at sinus.cz>
> > To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> > Sent: Friday, May 25, 2012 10:59:24 AM
> > Subject: Re: [asterisk-dev] Wrong SIP to SIP SIP Cause mapping
> > 
> > Hi!
> > 
> > Oh, Mamma mia, Alex is right!!!!
> >   I've just tested a void public number through PRI and I've got CC=1
> >   -
> > Unallocated number.
> >   Then I dialled the same number through SIP trunk and I've got
> >   CC=34,
> > but on the SIP the response code was really 404 Not Found, which is
> > equivalent to 1 - Unallocated number.
> >   Something is really broken here! Of course I'm paying attention to
> > $HANGUPCAUSE and I'm handling it in my own intercept scripts, and
> > they
> > are proved OK, so the problem must be in wrong $HANGUPCAUSE contents.
> >   It's 1.8 branch.
> >   I hope I will find the cause soon and I'll post it here.
> >     With regards, Pavel.
> > 
> 
> As has already been pointed out, Asterisk is a B2BUA, not a proxy.  There
> is no guarantee that a response from one UA will be 'passed through'
> Asterisk to another UA.  I won't weigh in on whether or not this qualifies
> as a bug or merely a change in behavior.  The fact that Asterisk is not a
> proxy gives weight to this being not a bug; that being said, there is a
> definite difference between a 4xx and a 5xx response, which would give some
> weight to this being a bug.
> 
> The change in behavior was mostly likely introduced by r351130.  This fixed
> some issues wherein, on a response to a 404, merely queueing a congestion
> control frame was not sufficient to tear down the channel.  The congestion
> control frame was replaced with an explicit channel hang up with a cause of
> AST_CAUSE_CONGESTION, which maps to a SIP response type of "503".
> 
> 
> 
> --
> Matthew Jordan
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
> 

Hi!
  There is a patch, which IMHO fixes the problem. It's for 1.8 trunk. It 
utilizes the hangup_sip2cause() function instead of the hardcoded cause
values.
  Does already exist an issue for this problem ? If yes, I would submit the
patch there. Otherwise, I can open the issue (and from my point of view,
its a really SERIOUS issue because clear causes are _very_ important values
in the telco business and giving totally incorrect ones can ruin your
network (no joking, think of crankback and other advanced routing techniques
based on the CC values) and thus even your business).
  With regards,
    Pavel

-------------- next part --------------
--- chan_sip.c.old	2012-05-25 18:44:25.898834370 +0200
+++ chan_sip.c	2012-05-25 18:45:28.405343312 +0200
@@ -20371,7 +20371,7 @@
 		ast_log(LOG_WARNING, "Received response: \"Forbidden\" from '%s'\n", get_header(&p->initreq, "From"));
 		if (!req->ignore && p->owner) {
 			ast_set_hangupsource(p->owner, p->owner->name, 0);
-			ast_queue_hangup_with_cause(p->owner, AST_CAUSE_CONGESTION);
+			ast_queue_hangup_with_cause(p->owner, hangup_sip2cause(resp));
 		}
 		break;
 
@@ -20379,7 +20379,7 @@
 		xmitres = transmit_request(p, SIP_ACK, seqno, XMIT_UNRELIABLE, FALSE);
 		if (p->owner && !req->ignore) {
 			ast_set_hangupsource(p->owner, p->owner->name, 0);
-			ast_queue_hangup_with_cause(p->owner, AST_CAUSE_CONGESTION);
+			ast_queue_hangup_with_cause(p->owner, hangup_sip2cause(resp));
 		}
 		break;
 
@@ -20389,7 +20389,7 @@
 		ast_log(LOG_WARNING, "Re-invite to non-existing call leg on other UA. SIP dialog '%s'. Giving up.\n", p->callid);
 		xmitres = transmit_request(p, SIP_ACK, seqno, XMIT_UNRELIABLE, FALSE);
 		if (p->owner) {
-			ast_queue_hangup_with_cause(p->owner, AST_CAUSE_CONGESTION);
+			ast_queue_hangup_with_cause(p->owner, hangup_sip2cause(resp));
 		}
 		break;
 
@@ -20404,7 +20404,7 @@
 		append_history(p, "Identity", "SIP identity is required. Not supported by Asterisk.");
 		ast_log(LOG_WARNING, "SIP identity required by proxy. SIP dialog '%s'. Giving up.\n", p->callid);
 		if (p->owner && !req->ignore) {
-			ast_queue_hangup_with_cause(p->owner, AST_CAUSE_CONGESTION);
+			ast_queue_hangup_with_cause(p->owner, hangup_sip2cause(resp));
 		}
 		break;
 
@@ -20437,7 +20437,7 @@
 		} else {
 			/* We can't set up this call, so give up */
 			if (p->owner && !req->ignore) {
-				ast_queue_hangup_with_cause(p->owner, AST_CAUSE_CONGESTION);
+				ast_queue_hangup_with_cause(p->owner, hangup_sip2cause(resp));
 			}
 		}
 		break;
@@ -20445,7 +20445,7 @@
 		xmitres = transmit_request(p, SIP_ACK, seqno, XMIT_UNRELIABLE, FALSE);
 		if (p->owner && !req->ignore) {
 			if (p->owner->_state != AST_STATE_UP) {
-				ast_queue_hangup_with_cause(p->owner, AST_CAUSE_CONGESTION);
+				ast_queue_hangup_with_cause(p->owner, hangup_sip2cause(resp));
 			} else {
 				/* This is a re-invite that failed. */
 				/* Reset the flag after a while
@@ -20469,7 +20469,7 @@
 	case 501: /* Not implemented */
 		xmitres = transmit_request(p, SIP_ACK, seqno, XMIT_UNRELIABLE, FALSE);
 		if (p->owner) {
-			ast_queue_hangup_with_cause(p->owner, AST_CAUSE_CONGESTION);
+			ast_queue_hangup_with_cause(p->owner, hangup_sip2cause(resp));
 		}
 		break;
 	}
@@ -21333,7 +21333,7 @@
 				default:
 					/* Send hangup */	
 					if (owner && sipmethod != SIP_BYE)
-						ast_queue_hangup_with_cause(p->owner, AST_CAUSE_PROTOCOL_ERROR);
+						ast_queue_hangup_with_cause(p->owner, hangup_sip2cause(resp));
 					break;
 				}
 				/* ACK on invite */