[asterisk-bugs] [Asterisk 0012963]: [patch] chan_iax2 will create multiple sessions when receiving retransmitted NEW

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12963 
====================================================================== 
Reported By:                jpgrayson
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12963
Category:                   Channels/chan_iax2
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.21 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             06-30-2008 18:48 CDT
Last Modified:              07-02-2008 16:56 CDT
====================================================================== 
Summary:                    [patch] chan_iax2 will create multiple sessions when
receiving retransmitted NEW
Description: 
When a client initiates a call with a NEW frame, frequently the client will
send a retransmitted NEW frame prior to receiving the ACCEPT frame from
asterisk. This may result in asterisk receiving duplicate NEW frames from
the same client in short succession.

As of at least 1.4.20, asterisk will ACCEPT and create new call sessions
for both of these NEW frames originating from the same client. This results
in much protocol confusion between asterisk and the client and ultimately
leads to asterisk and/or the client terminating the call.

The correct behavior would be for asterisk to recognize second (and third
and fourth) NEW frames from the same source (socket and callno) and ignore
them.

====================================================================== 

---------------------------------------------------------------------- 
 jpgrayson - 07-02-08 16:56  
---------------------------------------------------------------------- 
Perhaps the third time is the charm. I believe this latest patch to be
superior to the other two.

Things that are different:

* No more gratuitous whitespace changes.

* Changed where we decide to not match based on dcallno. We now simply
leave dcallno set to 0 when we encounter one of our exceptional cases (NEW,
PING, LAGRQ). I think this logic is simpler and more to-the-point than the
alternative where we checked it later on in socket_process().

* The new logic also accounts for the case where dcallno may be non-zero
for NEW, PING, and LAGRQ. We no longer match based on dcallno for NEW,
PING, or LAGRQ under any circumstances. This matches the previous semantic
for PING and LAGRQ and the semantic spelled out in the iax2 rfc section
6.2.2.

* Updated big comment to explain why we do not match dcallno for NEW
frames.

* Updated big comment to explain how we avoid matching by dcallno for NEW,
LAGRQ, and PING.

* Added test for IAX_COMMAND_NEW with the rest of the out of order packet
exceptions. This causes asterisk to _not_ send an ACK when it encounters a
duplicate/retransmitted NEW frame. (line 7290) I put a wimpy comment next
to this test that identifies what condition it is catching. Not sure if
this meets the commenting requirement.

> Upon closer reading of the section 6.2.2, it appears that asterisk must
> send an ACCEPT frame in response to this duplicate NEW frame. The patch
> as it stands does not yield this behavior. Asterisk will just ignore
the
> duplicate NEW frame. The spec seems correct in this case. When asterisk
> encounters a duplicate NEW frame, it cannot assume that the client
> received its first ACCEPT frame.

I'm going to waffle on this one. For any second, third, etc. NEW frame
that comes in, we will have already sent an ACCEPT frame. If the other end
fails to receive that ACCEPT frame, it will receive a retransmission of
that ACCEPT frame through the normal retry mechanism. There is no need to
send out another ACCEPT frame (with its own retry timer) in response to
this redundant NEW frame.

I have run this against the HEAD of the 1.4 branch successfully. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-02-08 16:56  jpgrayson      Note Added: 0089627                          
======================================================================