[asterisk-users] NAT solutions

[Brad Templeton]

Some NAT problems you can solve, some you never will.

Many modern phones have NAT support in them, via STUN, or a static external IP
address.  Most NATs also offer port forwarding, so you can open a hole for the
SIP port in the NAT so all outside can reach it.

(With port forwarding, you need a constant address for each SIP phone, so that
means either static IP for the phone, or a DHCP server with the ability to
always bind a device to the same address - the latter is preferable because
you can move your phone to other networks more easily.)

Many devices also feature NAT keep alive on the SIP port.  That is a must
if you can't open ports, but it sure generates a lot of annoying debug output
when you turn on sip debug.  Nothing beats a permanent NAT entry point though.

Some devices, notably Ciscos, just don't support NAT as well.  They
don't have STUN, and while they may have a static external IP mapping,
that's no good if your NAT itself has a dynamic address, as most home
broadband NATs do.

Asterisk, if you set nat=yes (or often even without that) will take incoming
packets from a natted phone, and look at the incoming address, and send back
to it regardless of what the phone says in its SIP headers.  That's handy,
but unfortunately it does not do the same thing for the SDP, so if the
phone hands out an SDP with an unreachable address, Asterisk handles it
badly.   Some SIP gateways are smarter, and if they see an unreachable
address in the SDP, ignore it and send to whatever address they get
incoming RTP from.   You'll have better luck connecting to such endpoints.

Many termination providers do this, so you may find your phones can
talk to the term provider, but not to other phones on the same
* box.

Many consumer nats will not hairpin audio.  That means if you do all
this work to rewrite the addresses in your SIP headers/SDP via STUN
so you look like an externally routable device, and Asterisk hooks
you up with another device behind your same NAT, you will get one
way audio.   I get this problem -- I have a * box at one location,
with most of the phones (no problem for those) and some other phones
at another location behind NAT.   These phones can talk to the
main location, but not to one another, due to the hairpin.

What fun.

A new method, called ICE, was drafted a while ago but is getting
slow adoption.  In ICE, devices are given a list of possible ways
they could reach one another (directly, through nats, via RTP forwarders etc.)
They try them all and pick the best.   In the end it will always work
through the RTP forwarders, but that costs bandwidth and latency.

So far, however, support is limited.