[asterisk-bugs] [Asterisk 0010289]: Old LAGRQ frames showing up in new IAX2 calls

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10289 
====================================================================== 
Reported By:                mihai
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   10289
Category:                   Channels/chan_iax2
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.8  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             07-24-2007 10:52 CDT
Last Modified:              07-31-2007 15:22 CDT
====================================================================== 
Summary:                    Old LAGRQ frames showing up in new IAX2 calls
Description: 
If there are two successive IAX2 calls having the same source and
destination call id, sometimes old LAGRQ frames belonging to the first call
are transmitted as part of a VNAK retransmission during the second call.
Since the old LAGRQ have wildly out of order sequence numbers, the other
endpoint will request retransmission, which can cause a VNAK storm.
I am able to reproduce this by stress testing chan_iax2 with an automated
script that generates about 3 calls per second, up to about 200
simultaneous calls.  This will pretty much guarantee that source ids will
be recycled on the server side, which can trigger this issue. 
====================================================================== 

---------------------------------------------------------------------- 
 mihai - 07-31-07 15:22  
---------------------------------------------------------------------- 
Uploaded yet another patch.  This time we check if the pointer provided to
__attempt_transmit is valid.  In order to do that, we scan the retransmit
queue, and try to find our frame in there. Once we get our frame, we know
we have a valid callno, so we can go ahead, lock our mutex and do our
thing.

This is not optimal, performance-wise.  Scanning the list is a O(n)
operation and we do it for each retransmit attempt. However, the retransmit
queue should not get too long, except for extreme conditions, so I believe
it's an acceptable tradeoff (until someone thinks of something better). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-31-07 15:22  mihai          Note Added: 0068161                          
======================================================================