Sekiur on Security

Getting SIP to work across a NAT or several of them from point to point can be very painful…. a sniffer and logs will help you greatly, if you can understand what is going on……

A SIP call involves both SIP signaling and RTP audio streams with the RTCP control streams as a hang-around.

MORE…

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 recipient’s address and port. In most cases, the RTP ports are dynamically assigned, 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.ave 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 gets 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 lets the SIP message go out to SIP phone B, and “remembers” that A is talking UDP to B.
When B answers the call, 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 behaviur 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 Intertex 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:

Voip-info.org: NAT and VOIP
Voip-info.org: Asterisk, SIP and NAT
Voip-info.org: Asterisk NAT=yes documentation (sip.conf)

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 communication. 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.