asterisk users - Mar 2005 - Asterisk + SIP + NAT - seriously, what's the secret?

I'm at my wit's end!

I've spent 2 days now trying to get what I thought was a very simply SIP
+ NAT arrangement working. I've trawled the web and picked brains, but
nothing anyone suggests work.

My setup is very simple. I have a * server in a datacentre, with a
public IP address. There is no firewall in place, it's completely open
(at least, as far as I'm concerned). I then have, in my office on the
end of an ADSL line, a Linux server running NAT using iptables, and
behind that I have a Grandstream 101 SIP phone.

For the purposes of testing, I have another Grandstream 101 on another
public network (between the Linux box and the ADSL router) with a public
IP address. When I call the phone on the NAT network, the NAT phone
cannot hear anything, although the public phone can, the classic
one-way-audio problem.

Many, many sources state that this is one of the simplest NAT problems,
and go on to say that simply putting "nat=yes" in the section for the
NAT phone in the sip.conf file will solve it. For example, I quote from:

http://lists.digium.com/pipermail/asterisk-users/2004-June/049538.html

"Conclusion: If Asterisk is on a public address (on the Internet) and
your phone is behind a NAT (from the server's point of view),
setting nat=yes fixes your audio problem."

Another example:

http://www.voip-info.org/wiki-Asterisk+SIP+NAT+solutions

"8 - Asterisk as a SIP server outside nat, clients on the inside
connecting to Asterisk [...] #8 is solved with nat=yes and qualify=xxx
in sip.conf for the client in most cases. Some clients (X-lite) assist
themselves by using STUN and sending UDP keep-alive packets. Qualify
sends keep-alive packets from Asterisk to the client on the inside."

It does not work, plain and simple, yet for many people this appears to
be all the magic required.

I've tried a STUN server, this has no discernable effect. I've tried
adjusting settings on the Grandstream relating to NAT traversal and
keep-alives; I've tried using the "qualify" directive, which only
served
to make things worse from what I could tell.

I'm not trying anything fancy like putting my * server behind another
NAT box and trying to NAT into that from my first NAT box or anything
like that. There are no firewalls in place that would affect traffic
(apart from the NAT box, obviously).

Seriously, this has to be the simplest NAT problem there is with
Asterisk. What's the secret? How do I learn the dark art? What am I
missing?

Your help would be met with endless appreciation.

Stuart Ford

Stuart Ford wrote:
> I'm at my wit's end!
> 
> I've spent 2 days now trying to get what I thought was a very simply
SIP
> + NAT arrangement working. I've trawled the web and picked brains, but
> nothing anyone suggests work.
> 
> My setup is very simple. I have a * server in a datacentre, with a
> public IP address. There is no firewall in place, it's completely open
> (at least, as far as I'm concerned). I then have, in my office on the
> end of an ADSL line, a Linux server running NAT using iptables, and
> behind that I have a Grandstream 101 SIP phone.
> 
> For the purposes of testing, I have another Grandstream 101 on another
> public network (between the Linux box and the ADSL router) with a public
> IP address. When I call the phone on the NAT network, the NAT phone
> cannot hear anything, although the public phone can, the classic
> one-way-audio problem.
> 
> Many, many sources state that this is one of the simplest NAT problems,
> and go on to say that simply putting "nat=yes" in the section for
the
> NAT phone in the sip.conf file will solve it. For example, I quote from:
> 
> http://lists.digium.com/pipermail/asterisk-users/2004-June/049538.html
> 
> "Conclusion: If Asterisk is on a public address (on the Internet) and
> your phone is behind a NAT (from the server's point of view),
> setting nat=yes fixes your audio problem."
> 
> Another example:
> 
> http://www.voip-info.org/wiki-Asterisk+SIP+NAT+solutions
> 
> "8 - Asterisk as a SIP server outside nat, clients on the inside
> connecting to Asterisk [...] #8 is solved with nat=yes and qualify=xxx
> in sip.conf for the client in most cases. Some clients (X-lite) assist
> themselves by using STUN and sending UDP keep-alive packets. Qualify
> sends keep-alive packets from Asterisk to the client on the inside."
> 
> It does not work, plain and simple, yet for many people this appears to
> be all the magic required.
> 
> I've tried a STUN server, this has no discernable effect. I've
tried
> adjusting settings on the Grandstream relating to NAT traversal and
> keep-alives; I've tried using the "qualify" directive, which
only served
> to make things worse from what I could tell.
> 
> I'm not trying anything fancy like putting my * server behind another
> NAT box and trying to NAT into that from my first NAT box or anything
> like that. There are no firewalls in place that would affect traffic
> (apart from the NAT box, obviously).
> 
> Seriously, this has to be the simplest NAT problem there is with
> Asterisk. What's the secret? How do I learn the dark art? What am I
> missing?
> 
> Your help would be met with endless appreciation.
> 
> Stuart Ford
> 
> 
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
> 
> 
It sounds like your linux box is blocking the rtp packets. Run tcpdump on the 
interface connected to the sip phone behind your linux system and see if rtp 
packets are getting thru. Better yet use tethereal it identifies the packets
better.

HTH,
Steve

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Stuart Ford wrote:
>Seriously, this has to be the simplest NAT problem there is with
>Asterisk. What's the secret? How do I learn the dark art? What am I
>missing?
>  
>
I'm guessing here, but the NAT'd grandstream does not have the correct 
external IP configured.

The phones are trying to establish a direct SIP to SIP connection, after 
SIP to SIP call is established asterisk tries to get out of the middle 
of the conversation.  This decreases latency and save processing on the 
asterisk box.  "canreinvite=no" sometimes helps this problem when 
asterisk is a sip client... don't know if it will have an effect here.

The thing to do is setup an extension with the Echo Application.  Call 
that from each phone and see what happens.  If it works for both phones 
you know the problem is a reinvite issue, if one phone or the other 
doesn't work it is a network or Nat config issue.  No sense flailing 
about, try to reduce the problem space.

If your familiar with ethereal it can be used to snoop on the SIP 
connection.. SIP is human readable, so you might be able to learn 
something interesting.

But I really know almost nothing about this.

Mark Farver