[asterisk-bugs] [Asterisk 0015712]: IAX call received and dialled out to another IAX peer: 100s of CONTROL/ACK/NACK exchanged as call is answered

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15712 
====================================================================== 
Reported By:                stevedavies
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15712
Category:                   Channels/chan_iax2
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.26 
JIRA:                        
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 202671 
Request Review:              
====================================================================== 
Date Submitted:             2009-08-13 07:51 CDT
Last Modified:              2009-09-29 07:39 CDT
====================================================================== 
Summary:                    IAX call received and dialled out to another IAX
peer: 100s of CONTROL/ACK/NACK exchanged as call is answered
Description: 

An incoming call is accepted over an IAX link, then dialled back out via
another IAX link to a different server (which in turn calls a 4th IAX peer
which in turns calls a SIP termination provider)

As the call is answered, there is a lengthy flurry of CONTROL (255?) and
CONTROL(20?) frames, with ACKs and NAKs etc etc.

Not exactly a packet storm - it does stop after a while.  But definitely
many many frames.

Note that this branch-1.4 SVN checkout has the SRCUPDATE-storm fix in it.

I've attached a full log showing a call coming in and being forwarded out,
including IAX2 protocol debugging.  Some freepbx dialplan junk in there but
the essence is a call coming in on a IAX trunk from one server is Dial()ed
out to another.


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

---------------------------------------------------------------------- 
 (0111485) stevedavies (reporter) - 2009-09-29 07:39
 https://issues.asterisk.org/view.php?id=15712#c111485 
---------------------------------------------------------------------- 
Hi,

As an update - I think this issue has got to do with the fact that
chan_iax2 transmits CONTROL frames with a SUBTYPE of 255.

These arrive on the other side and cause the same problems that the
SRCUPDATE frames were creating.

These CONTROL/255 frames are generated when ast_indicate is called with a
"-1" condition.  (I believe that this means stop indicating?) 
iax2_indicate sends this to the other side.  Because the -1 gets packed
into a byte it ends up as 255.  (Though uncompress_subclass is supposed to
undo that??)

Then the CONTROL with 255 arrives, you see it logged:

 > [Sep 29 09:41:47] VERBOSE[12625] logger.c: Rx-Frame Retry[ No] --
OSeqno: 007 ISeqno: 004 Type: CONTROL Subclass: (255?)
 > [Sep 29 09:41:47] VERBOSE[12625] logger.c:    Timestamp: 13342ms 
SCall: 07755  DCall: 07941 [41.204.210.210:4569]

And you get the same storm that the SRCUPDATE used to trigger.

By comparison, I see that chan_sip.c's sip_indicate returns res=-1 when
asked to indicate -1, meaning "I handled it", but doesn't do anything
further.

chan_h323 will similarly return res=-1 without other action.

So I'm going to try the following fix:

1) change iax2_indicate to not transmit the CONTROL with -1 (ie 255)
2) in iax2_bridge check for subclass -1 (and 255?) alongside the srcupdate
check

My reasoning is that this will cause us not to provoke the problem on the
other side, and not to be provoked if the other side sends us a
CONTROL/255.

Steve 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-29 07:39 stevedavies    Note Added: 0111485                          
======================================================================