[Home]

Summary:ASTERISK-07047: reduce IAX_DEFAULT_REG_EXPIRE slightly to improve NAT/PAT reliability
Reporter:mjc (mjc)Labels:
Date Opened:2006-05-29 07:23:09Date Closed:2006-05-29 10:46:44
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) iax2.h.patch
Description:I have been experiencing unreliable completion of incoming IAX calls (outgoing calls are fine). Initial portions of the IAX handshake do not seem to make it to my server, so the call fails. My Asterisk server is protected by a Sonicwall TZ170 with NAT/PAT. I have concluded that the TZ170 only keeps UDP ipaddr:port pairs in memory for 60 seconds! (It seems customary that NAT/PAT devices keep TCP ipaddr:port pairs in memory much longer than UDP ones).

IAX_DEFAULT_REG_EXPIRE is set to 60 seconds by default in 1.2.7.1, so I think I am experiencing "cliff edge" problems as the firewall sometimes forgets what port is being used for incoming calls. It is always racing against the firewall's 60 second timeout.

Reducing the IAX_DEFAULT_REG_EXPIRE value in channels/iax2.h from 60 seconds to 45 seconds is a minor tweak that would act as a "keep-alive" for NAT/PAT devices with very short ipaddr:port timeouts. I can't imagine any firewall using a timeout shorter than 60 seconds.

I hard-coded my refresh rate at 45 seconds as a test (overriding the IAX provider's requested value of 60 seconds), and that seems to fix the problem. Reducing IAX_DEFAULT_REG_EXPIRE would ensure that the provider requests a shorter value to begin with.

A patch to reduce IAX_DEFAULT_REG_EXPIRE from 60 seconds to 45 seconds is attached (disclaimer faxed in this morning).
Comments:By: mjc (mjc) 2006-05-29 10:24:30

Hmm, I still had a problem occur even with the refresh rate at 45 seconds. I'm trying 20 seconds now, and I am waiting to hear back from Sonicwall about their internal timeouts. Perhaps this is more of a Sonicwall problem.
By: Tilghman Lesher (tilghman) 2006-05-29 10:46:44

It is indeed a Sonicwall problem.  You can even reduce the timeout to 10 seconds and it won't make a difference.