Erratic Calls Through NAT-ed Server

Home » Asterisk Users » Erratic Calls Through NAT-ed Server
Asterisk Users 2 Comments

Morning,

We recently pushed our Asterisk video bridge into a DMZ and since then, local calls have been unreliable to say the least. While offsite calls work nicely, calls on our internal server usually fail to ring the far end. Two test calls that were made 4 minutes apart yielded different results: one rang the far end, the other kept trying to transmit the Invite. The configuration didn’t change at all between the two calls. I’ve been going over the debug logs, but haven’t noticed any possible reasons why one call failed. It’s the same all the way to the part where the far end is called.

The endpoints use different ports for UDP signaling and Asterisk is set to expect UDP packets from those ports. The RTP port range is the same between the ends (at least where it’s configurable), Asterisk and the firewall. All ports that we’re using have been opened in the firewall and incoming UDP traffic is routed to Asterisk. In Asterisk settings, localnet is defined as the LAN that both endpoints are on, externip is the public address of the server. Directrtpsetup and directmedia are both set to “no” and nat is set to “yes”.

So, what could be causing this issue?

Best wishes, Norman

2 thoughts on - Erratic Calls Through NAT-ed Server

  • If out of multiple calls, some work and some don’t – you either have found a bug or something is really changing between the calls. That is assuming the failing/working behavior does not fit an obvious pattern
    (e.g. unique to a particular dialed remote party).

    If you pastebin two Asterisk logs that show the working and failing calls then someone may be able to look through them and spot an issue.

    Be sure the Asterisk logs show VERBOSE and DEBUG channels at level 5
    or above. See: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

    You might also mention the exaction version of Asterisk you are using and which channel driver (though it sounds like chan_sip based on the options described).

  • Problem fixed. The issue was that the timeout for the Options packet was longer than our NAT timeout.

    Best wishes, Norman