[Home]

Summary:ASTERISK-14649: IAX call received and dialled out to another IAX peer: 100s of CONTROL/ACK/NACK exchanged as call is answered
Reporter:Steve Davies . (stevedavies)Labels:
Date Opened:2009-08-13 07:51:42Date Closed:2011-06-07 14:00:37
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_iax2
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) controlflurry.txt
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.



****** ADDITIONAL INFORMATION ******

All Asterisk systems involved are running SVN-branch-1.4-r202671M, approximately 1.4.26-pre4.
Comments:By: Steve Davies . (stevedavies) 2009-09-29 07:39:11

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
By: David Vossel (dvossel) 2010-04-14 11:30:44

is there any update on this issue?
By: David Vossel (dvossel) 2010-04-14 17:22:36

After further investigation, i believe this issue may have been resolved in the latest release.  Please re-open this issue if you are still experiencing this problem after updating.
By: David Vossel (dvossel) 2010-04-14 17:34:13

It has actually been fixed since 1.4.27, r225243
By: Steve Davies . (stevedavies) 2010-04-15 00:00:21

I don't think that this issue is fixed, but I'll re-test with current 1.6.2 and see.

I made a fix in my source as indicated in my report which does stop the problem.
I was hoping that someone would look at the problem and follow my reasoning but I guess not.

I'll upload the patch.

Steve

By: David Vossel (dvossel) 2010-05-28 17:39:05

any update here?
By: David Vossel (dvossel) 2010-05-28 17:39:16

any update here?
By: Steve Davies . (stevedavies) 2010-05-29 01:24:49

Stand-by...
By: David Vossel (dvossel) 2010-07-29 15:45:18

update?
By: David Vossel (dvossel) 2010-08-13 15:28:21

suspended due to inactivity