[Asterisk-doc] (Fwd) [Asterisk-Users] *** Asterisk Sunday News: The SIP NAT S

[Philipp von Klitzing]

Hi there,

this very well written little piece of Olle really deserves a places in 
the book, I'd say!

Cheers, Philipp

------- Forwarded message follows -------
Date sent:      	Sun, 06 Jun 2004 12:42:03 +0200
From:           	"Olle E. Johansson" <oej@edvina.net>
Subject:        	[Asterisk-Users] *** Asterisk Sunday News: The SIP NAT Special
To:             	Users Asterisk <asterisk-users@lists.digium.com>
Send reply to:  	asterisk-users@lists.digium.com
Organization:   	Edvina AB


* Theme: SIP and NAT - what is the problem, really?
   -------------------------------------------------
** One way audio? Why?
** The phone can call Asterisk, but I get no incoming calls?
** What can STUN do for me?
** Asterisk on the INSIDE of a NAT device
** Outbound SIP proxy - what is that?


*** SIP and NAT - what is the problem, really?
----------------------------------------------
Every day, there's a question related to SIP and NAT on the asterisk-users
mailing list. That's no wonder, SIP and NAT is tricky. And Asterisk, SIP and
NAT have many different configurations that could lead to problems.

A SIP call involves both SIP signalling and RTP audio streams with the
RTCP control streams as a hang-around. Let's look at it from above:

	SIP CLIENT			SIP SERVER
	(phone)				(phone)
	
		--------------------->	SIP
	SIP	<---------------------	
		--------------------->	RTP
	RTP	<---------------------	
		--------------------->	RTCP
	RTCP	<---------------------

This means that we have six different UDP streams for one call. Each one
have a sender's address (IP) and a sender's port (UDP) and a recepients
address and port. In most cases, the RTP ports are dynamic,
to enable multiple calls at a time. If you place a firewall in between
the phone, you can imagine that there's a lot of ports to open and close
for a call.

*** One way audio? Why?

If both client and server are located on the same network, which was the
assumption of the SIP architects, this is rather elegant. It get's messy
if they are on two different networks with a NAT (Network Address Translator)
device between them. Let me explain.

	SIP PHONE (A)------------NAT--------------SIP PHONE (B)
	Local network				INTERNET

Now, the SIP phone A tries to call SIP phone B. The NAT device let's
the SIP message go out to SIP phone B, and "remembers" that A is talking
UDP to B. When B answers, the NAT device looks the address up in memory,
figuring out that B was contacted by A and sends the packet to A.
In the SIP answer from B, B told a that "I listen for your audio
on this RTP port". In the original message from A to B, A told B
that "I listen for incoming audio on this IP and this port".

Here's where the problematic area begins.

Phone A is able to send audio to phone B. But the message from A
to B included a non-existing IP address (Internal RFC1918 IP address)
so there's no way B can send audio to A.

This is the reason for a lot of messages on the list saying
  -"I only get audio in one direction in my SIP call".
There's no way B can send audio to A. Period. We need to change
the behaviour of A and B to get calling out to work.

* Solution: The Asterisk NAT fix

Imagine that Phone B is your Asterisk server. In the Asterisk SIP channel,
there's a peer setting called "nat=yes". This changes the behaviour of
phone B, i.e. Asterisk.

When phone A sends an invitation to a call, it includes the IP address
and port where it listens for audio from phone B, your Asterisk server.
If "nat=yes" is set, Asterisk says "fine, dude" and totally ignores
this data. Instead, it checks the IP address the message was sent from,
i.e. your NAT device. This IP address is used instead of the local
private address (RFC1918) and audio is sent to that address instead.
With most NAT devices, the audio is then forwarded to the client and
we have two way audio.

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.

*** The phone can call Asterisk, but I get no incoming calls?

The NAT device is like an old relative, it has got a very short memory.
So after a while, the relationship between phone A and phone B is
totally forgotten. Beacuse of this, when phone B wants to place a call
to phone A, the NAT device looks at the IP sender's address and can't
relate it to any device on the inside. It drops the packet and forgets
all about it ever having been sent there in the first place.

This is how NAT devices work. If communication starts from the inside,
going out, answers are handed back to the inside. If someone on the
outside wants to communicate to someone on the inside, that will not
work.

* Solution: Keep the gates open - NAT-keep-alives

A SIP phone usually registers with a SIP proxy. This message comes
from the inside of the NAT to the server on the outside. Now, there's
an open connection in the NAT device. As soon as there's no more packets
on that connection, the NAT device cancels the connection and forgets
all about it. The trick is to keep the packets flowing, forcing the
NAT device to keep the connection open.

Some phones send NAT "keep-alive" packets by themselves. X-lite and Sipura
have this feature. If the phone can't do it, configure Asterisk to do it.
Setting "qualify=yes" in the [peer] section for this device, Asterisk starts
sending packets to the device, keeping the NAT connection open. You will also
be able to see some timing for packets between Asterisk and the phone when
you do "sip show peers" at the CLI.

Now, when Asterisk wants to place a call to the phone, the NAT welcomes
the packets and forwards them happily to your phone.

Conclusion: If Asterisk is on a public IP address and your phone is on the
inside of a NAT device, we need to keep the NAT connection open by frequently
sending dummy packets between the devices. This will keep the connection
open for incoming calls.

*** What can STUN do for me?
STUN, Simple Traversal of UDP over NAT devices, is a *discovery* protocol.
With STUN, the phone on the inside of the NAT device can send discovery
packets to a STUN server, trying to figure out how the NAT device works.
NAT devices can work in many ways, and there are evil ones that will not
let phone calls go through, regardless of what you do. STUN-enabled phones
will discover those.

STUN tells the phone, among other things, what IP address the NAT device
is using on the outside. When the phone then signals to the SIP proxy/server,
it sends the proper IP address, not the private IP address used on the
inside. With a proper implementation, you don't need nat=yes for STUN-
enabled phones. The data sent to Asterisk will be correct.

*** And UPNP, will that help?
UPNP, Universal Plug'n'play, is another solution. It's a protocol that
the phone can use to communicate with the NAT device, allocating ports
and getting a proper configuration. With UPNP enabled phones and
NAT devices, your Asterisk server doesn't need nat=yes.

*** Asterisk on the INSIDE of a NAT device
If you have Asterisk on the INSIDE of a NAT device, trying to
communicate with a SIP proxy (like Free World Dialup) on the outside
or having phones on the outside, you're in another ball game.

Check the sip.conf.sample in the Asterisk configs directory for
the externalip and localnet settings, that tells Asterisk what the
outside IP address is. And yes, we could use a STUN client in Asterisk so
that Asterisk could figure out what to do. Any coders? You're wanted.

If you have phones on the outside, port forwarding is your best
friend. As you can imagine, this is not an easy task. Check the
wiki for help.

*** Outbound SIP proxy - what is that?
An outbound SIP proxy is a SIP proxy in the same sense as you can configure
a web proxy on the edge of your LAN, handling all web traffic between
your LAN and the outside world. An outbound SIP proxy would take care
of all SIP messages between your LAN and the outside world, the Internet.
This proxy could also handle conversion of IP addresses, and assist the
firewall in opening and closing RTP/RTCP ports to let the call go through.

The Internet IX66 works like this, and there are ways to configure
the SIP Express Router to be part of the Firewall DMZ, handling
the SIP messaging and working with an RTP proxy to handle the audio.

Currently, there's no support in Asterisk for an outbound SIP proxy.
I am working on it, but need some help. Check chan_sip2 in the bug
tracker.

*** Summary: NAT - It's a big mess, and it ain't easy

SIP and NAT is not an easy topic, since there are so many different NAT
devices out there. It's getting easier with SIP devices detecting type
of NAT with STUN, delivering correct and useful data to the SIP proxy.

There's also a lot of topics I haven't covered in this short essay, like
handling the media path (canreinvite=no for devices on the inside of a NAT),
RTP proxies and Session Border Controllers. We'll come back to that later,
possibly when we document all of this in the Asterisk handbook.

Read more:
* http://www.voip-info.org/wiki-NAT+and+VOIP
* http://www.voip-info.org/wiki-Asterisk+SIP+NAT+solutions
* http://www.voip-info.org/wiki-Asterisk+sip+nat

*** What's the difference between SIP and IAX2?
-----------------------------------------------
While SIP is a protocol that is being developed, but not yet standardized,
in the IETF, IAX2 is more of a proprietary development that is created for
Asterisk to Asterisk communcation. Nowadays, there are many soft phones
created using the IAX2 protocol as well as ATA devices, like Digium's
IAXY.

IAX2 uses one port for signalling and audio. If the "client" is on the
inside of a NAT device, it registers and then keeps the connection open
with keep-alives. This way, calls can be placed in both directions.

IAX2 doesn't use dynamically allocated ports for audio like SIP, thus
making it much easier to traverse NAT devices and to configure
Firewalls to support IP telephony.