[asterisk-bugs] [Asterisk 0013749]: IAX2 storm (type 4, subtype 20: AST_CONTROL_SRCUPDATE)

Thu Oct 23 16:08:04 CDT 2008

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13749 
====================================================================== 
Reported By:                adiemus
Assigned To:                blitzrage
====================================================================== 
Project:                    Asterisk
Issue ID:                   13749
Category:                   Channels/chan_iax2
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.22 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-10-20 17:46 CDT
Last Modified:              2008-10-23 16:08 CDT
====================================================================== 
Summary:                    IAX2 storm (type 4, subtype 20:
AST_CONTROL_SRCUPDATE)
Description: 
This is a rather odd issue to describe.

In simplest terms, I have a server connected via IAX2 to another server. 
The configuration had been working fine through at least 1.4.18.  However,
between then an 1.4.21.2, this issue began occuring for all calls from
server A to server B.  (But oddly, not for calls from B->A)  The issue
persists in 1.4.22.

When a call is placed through server A to server B via IAX2, server A
sends a torrent of retransmitted packets right after the initial call
setup.  This storm eats up more than 20 Mbit and is reproducible for every
call from server A to server B.  If I replicate the configuration of server
B onto server C, the behavior remains the same.  Calls from server A to
server C show the same "packet storm" bug.

I have complete pcap captures of both sides of the connection, if that's
useful.  However, the short overview from server A's perspective is:

A -> B NEW
B -> A AUTHREQ
A -> B AUTHREP
B -> A ACCEPT
A -> B ACK
B -> A ANSWER
A -> B ACK
A -> B CONTROL (subclass = 20, AST_CONTROL_SRCUPDATE)
A -> B CONTROL (subclass = 20, AST_CONTROL_SRCUPDATE) [retrans]
<storm of identical, retransmitted packets>

This is a serious issue for us as the storm is enough to saturate the
internet connections both of LAN A and LAN B.  (Packet rate is into the
tens or hundreds of thousands per second)

I'm happy to provide more information, but I don't know what else would be
useful.

The iax.conf entry for server B on server A looks like:
[serverB]
type=user
auth=md5
secret=redacted
transfer=no
context=from-serverB
jitterbuffer=no

[serverB]
type=peer
auth=md5
secret=redacted
username=serverA
transfer=no
host=dynamic
disallow=all
allow=gsm
jitterbuffer=no

The config for serverA on serverB:
register => serverB:redacted at serverA.fqdn

[serverA]
type=user
auth=md5
secret=redacted
transfer=no
context=from-serverA
jitterbuffer=yes

[serverA]
type=peer
auth=md5
secret=redacted
username=serverB
host=serverA.fqdn
jitterbuffer=yes
trunk=no
trunktimestamps=no
disallow=all
allow=gsm

In the interim, I'll see if I can do a binary search to find in what
version this behavior started.
====================================================================== 

---------------------------------------------------------------------- 
 (0094217) adiemus (reporter) - 2008-10-23 16:08
 http://bugs.digium.com/view.php?id=13749#c94217 
---------------------------------------------------------------------- 
Alright, a bit more info to add.  It took me a while to induce the behavior
again to get a better capture.  Interestingly, a call from a softphone
registered to serverA made to serverB was working fine.  However, a call
from a softphone registered to serverC, routed through serverA to get to
serverB showed the issue.  It also dumped a fair amount of warnings to the
asterisk console:

 [Oct 23 22:14:23] WARNING[22160]: chan_iax2.c:6927 socket_process:
Received trunked frame before first full voice frame
<quite a number of these, then>
 [Oct 23 22:14:47] NOTICE[22168]: chan_iax2.c:6701 socket_read: Out of
idle IAX2 threads for I/O, pausing!
[Oct 23 22:14:48] NOTICE[22168]: chan_iax2.c:6701 socket_read: Out of idle
IAX2 threads for I/O, pausing!
[Oct 23 22:14:51] WARNING[20520]: chan_iax2.c:2047 __attempt_transmit: Max
retries exceeded to host 127.0.0.1 on IAX2/om-enum-12 (type = 4, subclass =
20, ts=5818, seqno=20)
[Oct 23 22:14:51] WARNING[20566]: chan_iax2.c:2047 __attempt_transmit: Max
retries exceeded to host 150.101.175.216 on IAX2/doulos-13 (type = 4,
subclass = 20, ts=5673, seqno=25)
[Oct 23 22:14:51] WARNING[20553]: chan_iax2.c:2047 __attempt_transmit: Max
retries exceeded to host 150.101.175.216 on IAX2/doulos-13 (type = 4,
subclass = 20, ts=5526, seqno=31)
[Oct 23 22:14:51] WARNING[22164]: chan_iax2.c:2047 __attempt_transmit: Max
retries exceeded to host 127.0.0.1 on IAX2/om-enum-12 (type = 4, subclass =
20, ts=5785, seqno=9)
[Oct 23 22:14:51] WARNING[20567]: chan_iax2.c:2047 __attempt_transmit: Max
retries exceeded to host 127.0.0.1 on IAX2/om-enum-12 (type = 4, subclass =
20, ts=5791, seqno=11)

anonymized pcap dump of this behavior for this call path will follow. 
(For reference, IAX2/om-enum-12 is the first leg from serverC to serverA,
while IAX2/doulos-13 is the link from serverA to serverB) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-23 16:08 adiemus        Note Added: 0094217                          
======================================================================