[Asterisk-Dev] Behaviour on retransmission of SIP 407 responses

[John Todd]

>Hi all,
>
>     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
>
>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. 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
>
>
>Please let me know if you consider the solution good enough to 
>include in the cvs code. Please, feel free to do it
>
>Thanks for your time
>
>Gines
>Voz Telecom
[snip]

Gines
   This looks like a useful fix.  Can you please submit this as a 
bugfix through http://bugs.digium.com/ and sign a disclaimer and fax 
it back to Digium?  This would allow the changes to be added to 
Asterisk.

    As a side note, there is another bugfix for 407 replies in the 
system and waiting for some updates before addition, but in regards 
to a different problem: 
http://bugs.digium.com/bug_view_page.php?bug_id=0000260   I just 
thought you might want to know before you stumbled across that 
problem, too.  :-)

JT