[asterisk-bugs] [Asterisk 0011474]: Asterisk hangup calls if two identical invites are received

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11474 
====================================================================== 
Reported By:                drencrom
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11474
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:            1.2.24  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             12-05-2007 08:06 CST
Last Modified:              12-18-2007 08:02 CST
====================================================================== 
Summary:                    Asterisk hangup calls if two identical invites are
received
Description: 
Context: 
Asterisk server receiving incoming SIP calls from a PortaSIP softswitch

Problem:
Sometimes the softswitch sends two identical INVITES in a row as if the
first OK from Asterisk was lost. When this happens Asterisk keeps resending
the 200 OK message although it in fact receives the PortaSIP ACKs and the
debug shows that it supposedly stopped retransmitting the 200 OK packet.
Then, after 6 retransmissions of the OK packet (all of them ACK'd by the
remote party) Asterisk hangs up a perfectly valid and working call.
The call works fine if there is no retransmission of the first INVITE
packet.

Debug:
I'll attach two log files with verbose and debug enabled. Also SIP debug
was active. One of them shows a valid call and the other shows the problem
I described above.
====================================================================== 

---------------------------------------------------------------------- 
 lvazquez - 12-18-07 08:02  
---------------------------------------------------------------------- 
Hi Tomba, I'm not sure if it's the same bug, but at least they seem to be
very similar and/or relatead to each other.
In respect to the reason for the problem I thought it was clear in my
previous message, but what is not clear is my very limited english skills
:( (sorry!)
The 2nd response IS NOT considered critical, BUT the problem is: 
if it's sent as reliable it will not cancel AND instead will overwrite the
reference (in the sip_pkt struct for the channel) to the retransmition
thread of the first CRITICAL response.
It's done here:
...
 pkt->retransid = ast_sched_add_variable(sched, siptimer_a, retrans_pkt,
pkt, 1);
...
That's the problem, and so is the 1st response's critical retransmission
that finally tears the call down.
It seems it's an implementation problem and not a logical one.
My attached patch seems to fix the problem (by not scheduling
retransmission on the second response), but may be the more correct
solution would be to cancel the first retransmission before scheduling the
second one.

I'm in a very busy time now, but as soon as possible I will arrange to
test if this situation arises in asterisk 1.4 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-18-07 08:02  lvazquez       Note Added: 0075637                          
======================================================================