[asterisk-bugs] [Asterisk 0010289]: Old LAGRQ frames showing up in new IAX2 calls
noreply at bugs.digium.com
noreply at bugs.digium.com
Mon Jul 30 15:28:30 CDT 2007
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-30-2007 15:28 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-30-07 15:28
----------------------------------------------------------------------
Uploaded a patch that attempts to solve the problem. The patch changes the
following:
- adds code to network_thread() that cleans up frames that have retries ==
-1
- Comments out the code that cleans up frames in __attempt_transmit
- Adds a couple of checks to vnak_retransmit that prevents it from sending
out incorrect frames
In my tests this patch works fine as long as the multithreaded scheduler
is disabled. If enabled, I get random crashes.
Issue History
Date Modified Username Field Change
======================================================================
07-30-07 15:28 mihai Note Added: 0068090
======================================================================
More information about the asterisk-bugs
mailing list