[asterisk-commits] mjordan: tag 1.8.9.3 r356568 - in /tags/1.8.9.3: ./ channels/

SVN commits to the Asterisk project asterisk-commits at lists.digium.com
Thu Feb 23 17:30:51 CST 2012


Author: mjordan
Date: Thu Feb 23 17:30:47 2012
New Revision: 356568

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=356568
Log:
Merge 355732, 356475 for 1.8.9.3

Removed:
    tags/1.8.9.3/asterisk-1.8.9.2-summary.html
    tags/1.8.9.3/asterisk-1.8.9.2-summary.txt
Modified:
    tags/1.8.9.3/   (props changed)
    tags/1.8.9.3/.version
    tags/1.8.9.3/ChangeLog
    tags/1.8.9.3/channels/chan_sip.c

Propchange: tags/1.8.9.3/
------------------------------------------------------------------------------
--- svn:mergeinfo (original)
+++ svn:mergeinfo Thu Feb 23 17:30:47 2012
@@ -1,1 +1,1 @@
-/branches/1.8:349731,350552,351504,352014,352199,354495,354542,354547
+/branches/1.8:349731,350552,351504,352014,352199,354495,354542,354547,355732,356475

Modified: tags/1.8.9.3/.version
URL: http://svnview.digium.com/svn/asterisk/tags/1.8.9.3/.version?view=diff&rev=356568&r1=356567&r2=356568
==============================================================================
--- tags/1.8.9.3/.version (original)
+++ tags/1.8.9.3/.version Thu Feb 23 17:30:47 2012
@@ -1,1 +1,1 @@
-1.8.9.2
+1.8.9.3

Modified: tags/1.8.9.3/ChangeLog
URL: http://svnview.digium.com/svn/asterisk/tags/1.8.9.3/ChangeLog?view=diff&rev=356568&r1=356567&r2=356568
==============================================================================
--- tags/1.8.9.3/ChangeLog (original)
+++ tags/1.8.9.3/ChangeLog Thu Feb 23 17:30:47 2012
@@ -1,3 +1,55 @@
+2012-02-23  Asterisk Development Team <asteriskteam at digium.com>
+
+	* Asterisk 1.8.9.3 Released.
+
+	* channels/chan_sip.c: Fix ACK routing for non-2xx responses.
+
+	  When we send an ACK for a 2xx response to an INVITE, we are supposed
+	  to use the learned route set. However, when we receive a non-2xx
+	  final response to an INVITE, we are supposed to send the ACK to the
+	  same place we initially sent the INVITE.
+
+	  We had been doing this up until the changes went in that would build
+	  a route set from provisional responses. That introduced a regression
+	  where we would use the learned route set under all circumstances.
+
+	  With this change, we now will set the destination of our ACK based on
+	  the invitestate. If it is INV_COMPLETED then that means that we have
+	  received a non-2xx final response (INV_TERMINATED indicates a 2xx
+	  response was received).  If it is INV_CANCELLED, then that means the
+	  call is being canceled, which means that we should be ACKing a 487
+	  response.
+
+	  The other change introduced here is setting the invitestate to
+	  INV_CONFIRMED when we send an ACK *after* the reqprep instead of
+	  before. This way, we can tell in reqprep more easily what the
+	  invitestate is prior to sending the ACK.
+
+	  (closes issue ASTERISK-19389)
+ 	  reported by Karsten Wemheuer
+	  patches:
+	    ASTERISK-19389v2.patch uploaded by Mark Michelson (license #5049)
+
+	* channels/chan_sip.c: Fix regressions with regards to route-set
+	  creation on early dialogs.
+
+	  This fixes two main issues:
+	  1. Asterisk would send a CANCEL to the route created by the provisional
+	     response instead of using the same destination it did in the initial
+	     INVITE.
+	  2. If a new route set arrives in a 200 OK than was in the 1XX response
+	     (perfectly possible if our outbound INVITE gets forked), then the
+	     route set in the 200 OK needs to overwrite the route set in the 1XX
+	     response.
+	  (closes issue ASTERISK-19358)
+	  Reported by: Karsten Wemheuer
+	  Tested by: Karsten Wemheuer
+	  patches:
+	   ASTERISK-19358.patch uploaded by Mark Michelson (license 5049)
+	   ASTERISK-19358.patch uploaded by Stefan Schmidt (license 6034)
+
+ 	  Review: https://reviewboard.asterisk.org/r/1749
+
 2012-02-09  Asterisk Development Team <asteriskteam at digium.com>
 
 	* Asterisk 1.8.9.2 Released.

Modified: tags/1.8.9.3/channels/chan_sip.c
URL: http://svnview.digium.com/svn/asterisk/tags/1.8.9.3/channels/chan_sip.c?view=diff&rev=356568&r1=356567&r2=356568
==============================================================================
--- tags/1.8.9.3/channels/chan_sip.c (original)
+++ tags/1.8.9.3/channels/chan_sip.c Thu Feb 23 17:30:47 2012
@@ -1269,7 +1269,7 @@
 static struct sip_pvt *find_call(struct sip_request *req, struct ast_sockaddr *addr, const int intended_method);
 static void free_old_route(struct sip_route *route);
 static void list_route(struct sip_route *route);
-static void build_route(struct sip_pvt *p, struct sip_request *req, int backwards);
+static void build_route(struct sip_pvt *p, struct sip_request *req, int backwards, int resp);
 static enum check_auth_result register_verify(struct sip_pvt *p, struct ast_sockaddr *addr,
 					      struct sip_request *req, const char *uri);
 static struct sip_pvt *get_sip_pvt_byid_locked(const char *callid, const char *totag, const char *fromtag);
@@ -10254,7 +10254,15 @@
 	snprintf(tmp, sizeof(tmp), "%d %s", seqno, sip_methods[sipmethod].text);
 
 	add_header(req, "Via", p->via);
-	if (p->route) {
+	/*
+	 * Use the learned route set unless this is a CANCEL on an ACK for a non-2xx
+	 * final response. For a CANCEL or ACK, we have to send to the same destination
+	 * as the original INVITE.
+	 */
+	if (sipmethod == SIP_CANCEL ||
+			(sipmethod == SIP_ACK && (p->invitestate == INV_COMPLETED || p->invitestate == INV_CANCELLED))) {
+		set_destination(p, ast_strdupa(p->uri));
+	} else if (p->route) {
 		set_destination(p, p->route->hop);
 		add_route(req, is_strict ? p->route->next : p->route);
 	}
@@ -13393,13 +13401,13 @@
 {
 	struct sip_request resp;
 	
-	if (sipmethod == SIP_ACK) {
-		p->invitestate = INV_CONFIRMED;
-	}
-
 	reqprep(&resp, p, sipmethod, seqno, newbranch);
 	if (sipmethod == SIP_CANCEL && p->answered_elsewhere) {
 		add_header(&resp, "Reason", "SIP;cause=200;text=\"Call completed elsewhere\"");
+	}
+
+	if (sipmethod == SIP_ACK) {
+		p->invitestate = INV_CONFIRMED;
 	}
 
 	return send_request(p, &resp, reliable, seqno ? seqno : p->ocseq);
@@ -13966,8 +13974,9 @@
 	}
 }
 
-/*! \brief Build route list from Record-Route header */
-static void build_route(struct sip_pvt *p, struct sip_request *req, int backwards)
+/*! \brief Build route list from Record-Route header 
+    \param resp the SIP response code or 0 for a request */
+static void build_route(struct sip_pvt *p, struct sip_request *req, int backwards, int resp)
 {
 	struct sip_route *thishop, *head, *tail;
 	int start = 0;
@@ -13985,9 +13994,12 @@
 		p->route = NULL;
 	}
 
-	/* We only want to create the route set the first time this is called */
-	p->route_persistent = 1;
-	
+	/* We only want to create the route set the first time this is called except
+	   it is called from a provisional response.*/
+	if ((resp < 100) || (resp > 199)) {
+		p->route_persistent = 1;
+	}
+
 	/* Build a tailq, then assign it to p->route when done.
 	 * If backwards, we add entries from the head so they end up
 	 * in reverse order. However, we do need to maintain a correct
@@ -19782,7 +19794,7 @@
 		 * */
 		parse_ok_contact(p, req);
 		if (!reinvite) {
-			build_route(p, req, 1);
+			build_route(p, req, 1, resp);
 		}
 		if (!req->ignore && p->owner) {
 			if (get_rpid(p, req)) {
@@ -19832,7 +19844,7 @@
 		 * */
 		parse_ok_contact(p, req);
 		if (!reinvite) {
-			build_route(p, req, 1);
+			build_route(p, req, 1, resp);
 		}
 		if (!req->ignore && p->owner) {
 			struct ast_party_redirecting redirecting;
@@ -19858,7 +19870,7 @@
 		 * */
 		parse_ok_contact(p, req);
 		if (!reinvite) {
-			build_route(p, req, 1);
+			build_route(p, req, 1, resp);
 		}
 		if (!req->ignore && p->owner) {
 			if (get_rpid(p, req)) {
@@ -19958,7 +19970,7 @@
 			parse_ok_contact(p, req);
 			/* Save Record-Route for any later requests we make on this dialogue */
 			if (!reinvite)
-				build_route(p, req, 1);
+				build_route(p, req, 1, resp);
 
 			if(set_address_from_contact(p)) {
 				/* Bad contact - we don't know how to reach this device */
@@ -22488,7 +22500,7 @@
 			*recount = 1;
 
 			/* Save Record-Route for any later requests we make on this dialogue */
-			build_route(p, req, 0);
+			build_route(p, req, 0, 0);
 
 			if (c) {
 				ast_party_redirecting_init(&redirecting);
@@ -24370,7 +24382,7 @@
 		if (sipdebug)
 			ast_debug(4, "Initializing initreq for method %s - callid %s\n", sip_methods[req->method].text, p->callid);
 		check_via(p, req);
-		build_route(p, req, 0);
+		build_route(p, req, 0, 0);
 	} else if (req->debug && req->ignore)
 		ast_verbose("Ignoring this SUBSCRIBE request\n");
 




More information about the asterisk-commits mailing list