[Home]

Summary:ASTERISK-00434: [patch] Wrong handling of 407 response retransmissions
Reporter:ginesgomez (ginesgomez)Labels:
Date Opened:2003-10-27 01:16:20.000-0600Date Closed:2004-09-25 02:49:15
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug437.patch
Description:I've found the following buggy behaviour regarding retransmission of 407 responses. When asterisk is acting like UA and calling outside trough a proxy, if the proxy retransmits 407 responses asterisk ack them (which is the proper behaviour) but also sends a new INVITE with the Digest information but the CSeq augmented by one (new transaction). The escenario is

Asterisk as UA  --->  Proxy : INVITE CSeq 102
Proxy ------> Asterisk as UA: 407 CSeq 102
Asterisk as UA  --->  Proxy : ACK CSeq 102
Asterisk as UA  --->  Proxy : INVITE (with Digest info) CSeq 103
Proxy ------> Asterisk as UA: 407 CSeq 102  (RETRANSMISSION)
Asterisk as UA  --->  Proxy : ACK CSeq 102
Asterisk as UA  --->  Proxy : INVITE (with Digest info) CSeq 104 (NEW TRANSACTION)
Proxy ------> Asterisk as UA: 481

As seen the transaction with CSeq 104 will cause a 481 error. As per the RFC, the retransmitted 407 should be ACK'ed but it should never originate a new transaction, not even a INVITE/Digest retransmission


****** ADDITIONAL INFORMATION ******


Going through the code I found that in the method handle_request this scenario is controlled, and if packets are retransmitted are marked as ignored. The ignore int acts as a boolean there. The problem is that ignore information is not passed to handle_response method.
Comments:By: ginesgomez (ginesgomez) 2003-10-27 01:23:06.000-0600

The patch below calls to handle response passing int ignored and checks in 407 handling code block if the response is retransmission or not. If so, it is ack'ed but a new transaction is not initiated

--- chan_sip.c  Sat Oct 25 22:05:17 2003
+++ chan_sip.c.orig     Sat Oct 25 22:05:53 2003
@@ -4673,12 +4673,9 @@
                               /* First we ACK */
                               transmit_request(p, "ACK", seqno, 0);
                               /* Then we AUTH */
-                               /* But only if the packet wasn't marked as ignore in handle_request */
-                               if(!ignore){
-                                 if ((p->authtries > 1) || do_proxy_auth(p, req, "INVITE", 1)) {
-                                   ast_log(LOG_NOTICE, "Failed to authenticate on INVITE to '%s'\n", get_header(&p->initreq, "From"));
-                                   p->needdestroy = 1;
-                                 }
+                               if ((p->authtries > 1) || do_proxy_auth(p, req, "INVITE", 1)) {
+                                       ast_log(LOG_NOTICE, "Failed to authenticate on INVITE to '%s'\n", get_header(&p->initreq, "From"));
+                                       p->needdestroy = 1;
                               }
                       } else if (!strcasecmp(msg, "BYE")) {
                               if (!strlen(p->peername))
@@ -5237,7 +5234,7 @@
               if (sscanf(e, "%i %n", &respid, &len) != 1) {
                       ast_log(LOG_WARNING, "Invalid response: '%s'\n", e);
               } else {
-                       handle_response(p, respid, e + len, req, ignore);
+                       handle_response(p, respid, e + len, req);
               }
       } else {
               transmit_response_with_allow(p, "405 Method Not Allowed", req);
By: Brian West (bkw918) 2003-11-26 11:31:35.000-0600

pelase attach the diff -u
By: Brian West (bkw918) 2003-12-02 20:48:05.000-0600

KNOCK KNOCK is this thing on?  Can you attach a diff -u please?
By: ginesgomez (ginesgomez) 2003-12-03 04:19:17.000-0600

Submitted path as attachement
By: Mark Spencer (markster) 2003-12-09 16:21:51.000-0600

Fixed in CVS
By: Brian West (bkw918) 2003-12-09 16:24:39.000-0600

Have you sent in a disclaimer yet?