[Asterisk-Users] RTP Read error: Resource temporarily unavailable

Rich Adamson radamson at routers.com
Tue Mar 9 05:21:39 MST 2004


> I looked all over google and the mailing lists but I can't figure this out.
> I can call a non NAT to a non NAT without a problem with and without
> reinvite.  As soon as I try to have a call between a NAT and a non NAT I get
> this...  The phones can't hear each other.  The MikeNATSnom1 has nat=yes and
> is set to Automatic for NAT detection.  My test router (a Netgear FVS318)
> has uPnP enable too.  From what I understood Asterisk's is supposed to be
> able to deal with this.  Any thoughts?

Mike,

About the only realistic way to troubleshoot nat problems like this is to
use a packet sniffer to see what addresses, etc, are actually being used on
the wire. (Download ethereal if you don't already have one.)

Part of the problem is wide variations in how well various hard/soft phones
deal with nat'ing, wide variations in the various inexpensive firewalls on
how they deal with translations (both nat and pat), variations in 
translation table timeouts in firewalls, necessary parameters needed in
* definitions for specific implementations, whether * has one or more nic
cards, etc, etc.

With the appropriate packet traces, there is a very high probability one
can make 'almost' all installations function correctly. The root issue is
exactly how the two endpoints negotiate the rtp ports to be used for the
conversation, and a key element in that process is understanding exactly
how the nat box is impacting that rtp negotiation. You won't see enough
detail in the * sip logs (including sip debug) to ID the issue.

I think it's fair to say that in most cases involving nat, you'll end up
using "canreinvite=no" and force the rtp session through *.

After getting one phone to work from behind a nat box, there is also a
high probability placing a second call (simultaneously) from behind the
same nat box may become your next challenge. (The uPnP function adds
little if any value to the process.)

Rich





More information about the asterisk-users mailing list