[asterisk-bugs] [Asterisk 0018485]: [patch] IAX2 Retry Time Review

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18485 
====================================================================== 
Reported By:                netfuse
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18485
Category:                   Channels/chan_iax2
Reproducibility:            have not tried
Severity:                   tweak
Priority:                   normal
Status:                     ready for review
Asterisk Version:           SVN 
JIRA:                       SWP-2754 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-12-16 09:41 CST
Last Modified:              2011-05-09 03:56 CDT
====================================================================== 
Summary:                    [patch] IAX2 Retry Time Review
Description: 
Guys,

The IAX2 channel driver has a number of timeout settings for
communication. I have found that customers with network problems are not
particularly benefitted by these timeouts because they are so incredibly
high.

If you look at the maths, it will be at least 30 seconds with absolutely
no traffic before a DIAL on an IAX2 host fails. However, a SIP peer with
qualify=yes defaults to 2000ms. I recommend that the 2 seconds timeout
should be applied to dialling on IAX trunks also.

Patch attached for your consideration. I have tested this in production
use with good results.

Cheers
Leo
====================================================================== 

---------------------------------------------------------------------- 
 (0134639) netfuse (reporter) - 2011-05-09 03:56
 https://issues.asterisk.org/view.php?id=18485#c134639 
---------------------------------------------------------------------- 
Hi

Great, thanks for your feedback.

I feel we're close - here are some relevant elements from the chan_iax2.c
source:

 /* Don't retry more frequently than every 10 ms, or less frequently than
every 5 seconds */
 #define MIN_RETRY_TIME		100
 #define MAX_RETRY_TIME		10000

 /* Retry after 2x the ping time has passed */
  fr->retrytime = pvt->pingtime * 2;
  if (fr->retrytime < MIN_RETRY_TIME)
    fr->retrytime = MIN_RETRY_TIME;
  if (fr->retrytime > MAX_RETRY_TIME)
    fr->retrytime = MAX_RETRY_TIME;

So this happens as according to the RFC. The bit that doesn't, however, is
this:

  /* Attempt transmission */
  send_packet(f);
  f->retries++;
  /* Try again later after 10 times as long */
  f->retrytime *= 10;
  if (f->retrytime > MAX_RETRY_TIME)
    f->retrytime = MAX_RETRY_TIME;
    /* Transfer messages max out at one second */
    if (f->transfer && (f->retrytime > 1000))
        f->retrytime = 1000;

So there is this embedded counter which makes the retry time *10 times
longer* on each packet that's not received to a max of 10 seconds. The
default max qualify time is 2 seconds before the host is unreachable, and
there are up to 4 retries, which means the transmission fail time would be
be 4s + 40s + 400s + 4000s = 4444 seconds, but is instead limited by
MAX_RETRY_TIME to 4s + 10s + 10s +10s = 34 seconds.

Consider without the multiplier, the worst case would be 4s *4 = 16s for a
really lagged host, or, say, 200ms *
4 = 1s for a host which was previously only 100ms away.

Basically, there is no good reason for the retry time to be multiplied -
it works as hoped without this retry timer being multiplied. The multiplier
is not extracted as a constant and is not required from the RFC.

I have a dozen boxes in production with this patched, and they work as
expected. If an IAX trunk goes down, the call to be placed to it doesn't
hang for 30+ seconds!

Leo 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-05-09 03:56 netfuse        Note Added: 0134639                          
======================================================================