[asterisk-commits] oej: branch oej/darjeeling-prack-1.8 r369546 - in /team/oej/darjeeling-prack-...

SVN commits to the Asterisk project asterisk-commits at lists.digium.com
Tue Jul 3 03:05:29 CDT 2012


Author: oej
Date: Tue Jul  3 03:05:27 2012
New Revision: 369546

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=369546
Log:
It's all about timing, she said.

Modified:
    team/oej/darjeeling-prack-1.8/   (props changed)
    team/oej/darjeeling-prack-1.8/channels/chan_sip.c

Propchange: team/oej/darjeeling-prack-1.8/
------------------------------------------------------------------------------
--- automerge (original)
+++ automerge Tue Jul  3 03:05:27 2012
@@ -1,1 +1,1 @@
-*
+Is-there-life-off-net?

Modified: team/oej/darjeeling-prack-1.8/channels/chan_sip.c
URL: http://svnview.digium.com/svn/asterisk/team/oej/darjeeling-prack-1.8/channels/chan_sip.c?view=diff&rev=369546&r1=369545&r2=369546
==============================================================================
--- team/oej/darjeeling-prack-1.8/channels/chan_sip.c (original)
+++ team/oej/darjeeling-prack-1.8/channels/chan_sip.c Tue Jul  3 03:05:27 2012
@@ -21253,6 +21253,63 @@
 			owner->hangupcause = hangup_sip2cause(resp);
 	}
 
+	if (p->socket.type == SIP_TRANSPORT_UDP) {
+		int ack_res = FALSE;
+
+		/* Acknowledge whatever it is destined for */
+		if ((resp >= 100) && (resp <= 199)) {
+			/* NON-INVITE messages do not ack a 1XX response. RFC 3261 section 17.1.2.2 */
+			if (sipmethod == SIP_INVITE) {
+				ack_res = __sip_semi_ack(p, seqno, 0, sipmethod);
+			}
+		} else {
+			ack_res = __sip_ack(p, seqno, 0, sipmethod, 0);
+		}
+
+		if (ack_res == FALSE) {
+			/* RFC 3261 13.2.2.4 and 17.1.1.2 - We must re-send ACKs to re-transmitted final responses */
+			if (sipmethod == SIP_INVITE && resp >= 200) {
+				transmit_request(p, SIP_ACK, seqno, XMIT_UNRELIABLE, resp < 300 ? TRUE: FALSE);
+			}
+
+			append_history(p, "Ignore", "Ignoring this retransmit\n");
+			return;
+		}
+	}
+
+	/* If this is a NOTIFY for a subscription clear the flag that indicates that we have a NOTIFY pending */
+	if (!p->owner && sipmethod == SIP_NOTIFY && p->pendinginvite) {
+		p->pendinginvite = 0;
+	}
+
+	/* Get their tag if we haven't already */
+	if (ast_strlen_zero(p->theirtag) || (resp >= 200)) {
+		char tag[128];
+
+		gettag(req, "To", tag, sizeof(tag));
+		ast_string_field_set(p, theirtag, tag);
+	}
+
+	/* This needs to be configurable on a channel/peer level,
+	   not mandatory for all communication. Sadly enough, NAT implementations
+	   are not so stable so we can always rely on these headers.
+		Temporarily disabled, while waiting for fix.
+	   Fix assigned to Rizzo :-)
+	*/
+	/* check_via_response(p, req); */
+
+	/* RFC 3261 Section 15 specifies that if we receive a 408 or 481
+	 * in response to a BYE, then we should end the current dialog
+	 * and session.  It is known that at least one phone manufacturer
+	 * potentially will send a 404 in response to a BYE, so we'll be
+	 * liberal in what we accept and end the dialog and session if we
+	 * receive any of those responses to a BYE.
+	 */
+	if ((resp == 404 || resp == 408 || resp == 481) && sipmethod == SIP_BYE) {
+		pvt_set_needdestroy(p, "received 4XX response to a BYE");
+		return;
+	}
+	
 	/* If we have a required header in the response, the other side have activated an extension
 	   we said that we do support */
 	if (!ast_strlen_zero(required)) {
@@ -21287,63 +21344,6 @@
 			ast_debug(3, "!=!=!=!=!=! The other side activated Session timers! \n");
 		}
 	}
-
-	if (p->socket.type == SIP_TRANSPORT_UDP) {
-		int ack_res = FALSE;
-
-		/* Acknowledge whatever it is destined for */
-		if ((resp >= 100) && (resp <= 199)) {
-			/* NON-INVITE messages do not ack a 1XX response. RFC 3261 section 17.1.2.2 */
-			if (sipmethod == SIP_INVITE) {
-				ack_res = __sip_semi_ack(p, seqno, 0, sipmethod);
-			}
-		} else {
-			ack_res = __sip_ack(p, seqno, 0, sipmethod, 0);
-		}
-
-		if (ack_res == FALSE) {
-			/* RFC 3261 13.2.2.4 and 17.1.1.2 - We must re-send ACKs to re-transmitted final responses */
-			if (sipmethod == SIP_INVITE && resp >= 200) {
-				transmit_request(p, SIP_ACK, seqno, XMIT_UNRELIABLE, resp < 300 ? TRUE: FALSE);
-			}
-
-			append_history(p, "Ignore", "Ignoring this retransmit\n");
-			return;
-		}
-	}
-
-	/* If this is a NOTIFY for a subscription clear the flag that indicates that we have a NOTIFY pending */
-	if (!p->owner && sipmethod == SIP_NOTIFY && p->pendinginvite) {
-		p->pendinginvite = 0;
-	}
-
-	/* Get their tag if we haven't already */
-	if (ast_strlen_zero(p->theirtag) || (resp >= 200)) {
-		char tag[128];
-
-		gettag(req, "To", tag, sizeof(tag));
-		ast_string_field_set(p, theirtag, tag);
-	}
-	/* This needs to be configurable on a channel/peer level,
-	   not mandatory for all communication. Sadly enough, NAT implementations
-	   are not so stable so we can always rely on these headers.
-		Temporarily disabled, while waiting for fix.
-	   Fix assigned to Rizzo :-)
-	*/
-	/* check_via_response(p, req); */
-
-	/* RFC 3261 Section 15 specifies that if we receive a 408 or 481
-	 * in response to a BYE, then we should end the current dialog
-	 * and session.  It is known that at least one phone manufacturer
-	 * potentially will send a 404 in response to a BYE, so we'll be
-	 * liberal in what we accept and end the dialog and session if we
-	 * receive any of those responses to a BYE.
-	 */
-	if ((resp == 404 || resp == 408 || resp == 481) && sipmethod == SIP_BYE) {
-		pvt_set_needdestroy(p, "received 4XX response to a BYE");
-		return;
-	}
-	
 
 	if (p->relatedpeer && sipmethod == SIP_OPTIONS) {
 		/* We don't really care what the response is, just that it replied back.




More information about the asterisk-commits mailing list