|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:42||Date Closed:||2011-06-07 14:00:37|
|Environment:||Attachments:||( 0) controlflurry.txt|
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|
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 logger.c: Rx-Frame Retry[ No] -- OSeqno: 007 ISeqno: 004 Type: CONTROL Subclass: (255?)
> [Sep 29 09:41:47] VERBOSE logger.c: Timestamp: 13342ms SCall: 07755 DCall: 07941 [18.104.22.168: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.
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.
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
By: David Vossel (dvossel) 2010-07-29 15:45:18
By: David Vossel (dvossel) 2010-08-13 15:28:21
suspended due to inactivity