Difference between revisions of "Network Configuration for VoIP Providers"

Revision as of 16:08, 5 March 2010

Introduction

The problem with NAT

SIP & SDP

Internet telephony uses the Session Initiation Protocol (SIP) to establish phone calls (or other multimedia sessions). SIP messages can contain a body with data of the Session Description Protocol (SDP), that contain at least one IP address and port that is used for sending and receiving the audio (voice) data (RTP). Furthermore some important SIP headers contain the local socket address (IP+port).

Network address translation (NAT)

Figure 1: Typical Internet access with NAT

This is a problem if a NAT router is present between the two telephony endpoints. The NAT router changes private IP addresses to the public one (e.g. ADSL endpoint address). In the example network in Figure 1, the router translates the private network 192.168.1.0/24 to one single IP address 149.246.229.150. In addition, the port is changed in many cases. This is sometimes named “Network address port translation” (NAPT). In this document, the term NAT always may also mean NAPT.

Figure 1: TCP/IP Layer Model (Source: Wikipedia )

The address change is made in IP/UDP header only – the data (SIP+SDP) is left unchanged.

Binding life-time

Practically all NAT implementations need to store some information about its state to recognize response packets and change them accordingly. This state information is called binding.

These bindings have a time-to-live (TTL) that is implementation-specific and may also depend on the used port number and the count of transmitted packets (e.g. DNS responses have a shorter lifetime than other packets). Also stateful firewalls that do not perform NAT store a “binding” that has a specific time-to-live. That means that if there is no response (or new request) on a open binding, the binding is closed after some time and responses or new requests no longer can traverse the router or firewall.

It also means that an incoming packet can received only after a binding was opened earlier.

Problems resulting from router behavior

Payload establishment

The private IP address used in the SDP c-line and port(s) used in the m-line(s) are not changed by the NAT, because they are belonging to the UDP data.

This private IP is received by the other telephony endpoint (peer). The peer is not able to use this address as destination address for its payload.

Furthermore even if the address was correct, an open binding may be needed to pass a firewall.

Routing of responses and new requests within the dialog

Also the SIP signaling is affected. The SIP RFC states that responses must to be sent back to the port used in the topmost Via-Header (or to the default port 5060 if no port is present).

So if the NAT router changes the port, the response cannot be sent back to the client. The same applies for new requests within the dialog (e.g. a BYE send by the called party).

If the ITSP works in proxy mode and does not add the “Record-Route” header, there is another problem for these requests:

The called party sends new requests within the dialog directly to the peer (the caller), e.g. a BYE request to release the call.

In most configurations, the NAT router or firewall then has no open binding and cannot forward the request to the telephony system.

Registration

For incoming call the telephony system has to register itself at the ITSP. The address where incoming calls should be routed to is written to the Contact-Header of the SIP REGISTER request. If a private IP address is used that cannot be used by the ITSP, so no incoming calls are possible.

Possible Solutions

Application Layer Gateways

There are devices with Application layer gateway (ALG) functionality, that also inspect the UDP data for IP addresses and thus change SIP and SDP data. Experience shows that those devices are unreliable very often, so it is best to switch off any ALG functionality.

STUN (RFC 3489, RFC 5389)

One solution to solve this problem is that the endpoint finds out how the private transport address is changed by the NAT router. Therefore, the STUN protocol exists. A public STUN server responds to requests with an answer that contains the public address it has seen in the IP/UDP header of the request. Other protocols that query the NAT router for the public address directly are not used widespread due to security considerations (UPnP) or are still in draft state (Midcom).

Remote (provider-side) solutions: SBC, symmetric response routing

Another solution is to ignore the addresses in SIP and SDP data and just route responses and payload back to the originating address seen in the IP/UDP header. Obviously, this only works if at least one endpoint uses a public IP address and only one side uses this mechanism and the other starts with sending payload. Many ITSPs use media gateways (sometimes also called Session Border Controllers - SBC) that implement this (far-end NAT support or symmetric response routing).

To address all the problems mentioned in section 1.4, the ITSP has to support symmetric response routing for media, SIP responses (see also rport, section 2.4), SIP Requests (add Record-Route if working in proxy mode) and SIP Registration (store received IP and UDP source address as contact instead of the contact-header).

rport (RFC 3581)

The rport mechanism changes the SIP routing behavior, so that responses can be received through a NAT even if private addresses are used in the SIP headers. It does not offer a solution for SIP registration and RTP establishment.

For those interested, some more details: The SIP RFC specifies that responses to requests are sent back to the IP address seen in the IP header, but to the port seen in the SIP Via: - header. To achieve this in a multi-proxy environment, every proxy adds a received-parameter containing the source IP address of the received packet to the Via-Header of a SIP message it forwards.

When the rport-Parameter is added by the client to an outgoing SIP request, the receiving proxy also fills this parameter with the source port it sees in the received UDP header and uses it to route back the responses.

Offered solutions by the HiPath / OpenScape telephony systems

Our telephony systems support STUN and can trigger payload establishment with a provider-side media gateway. (This is needed if the ITSP wants to send payload before we start sending, e.g. if the provider wants to play back an announcement like “number not available” before the local phone starts sending payload.) Furthermore, the rport mechanism is always used (if not deactivated in the ITSP profile), because it does no harm and can help in diagnostics. To keep NAT/firewall bindings open, empty UDP packets are sent to any SIP proxy and registration gateway of all registered ITSP.

STUN (RFC 3489 and RFC 5389)

NAT type detection

The STUN protocol allows the detection of the way how the router performs NAT. This NAT type detection works with most, but not all routers that are available.

Different NAT types were defined in the original STUN RFC 3489. Experience showed that these are ambiguous sometimes and the detection method specified in RFC 3489 is unreliable for some routers. For these reasons RFC 4787 introduced new terms and now distinguishes between NAT behavior and filter behavior. The new STUN RFC 5389 makes use of the new terms.

Tabelle 1: Comparison of old and new NAT type definitions Red STUN does not help in NAT traversal Green STUN can be used for NAT traversal Gray No NAT traversal necessary

The filter behavior is of no interest to the HiPath / OpenScape telephony system: It always assumes that it needs to open a binding to the IP address and port of its peers and thus send empty UDP packets to open connections (RTP) or keeping bindings alive (SIP registration).

Example SIP packets

Outgoing INVITE without STUN

INVITE sip:089700732559@sip2.fsys.co.uk:5060 SIP/2.0
Accept: application/sdp
Via: SIP/2.0/UDP 192.168.138.70:5060;rport;branch=z9hG4bKf08fd3da8b8f1cab9
Max-Forwards: 70
From: <sip:84415955@fsys.co.uk>;tag=5509ef8b35
To: <sip:089700732559@sip2.fsys.co.uk>
Call-ID: 5675ca5b59b3a97e
CSeq: 1076853466 INVITE
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, INFO
Contact: <sip:192.168.138.70:5060>
Supported: 100rel
User-Agent: HiPath OpenOffice V3 M5T SIP Stack/4.0.26.26
X-Siemens-Call-Type: ST-insecure
Content-Type: application/sdp
Content-Length: 355

v=0
o=MxSIP 0 1965008630 IN IP4 192.168.138.70
s=SIP Call
c=IN IP4 192.168.138.70
t=0 0
m=audio 30520 RTP/AVP 9 8 0 18 96 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:96 AMR/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=sendrecv

Figure 2 Outgoing INVITE without usage of STUN

As you can see, the own IP address is used for both SIP signaling (Contact and Via header) and payload negotiation (c and m line). The o-line also contains a private IP address, but this is not critical for payload establishment. A NAT router does not look into the packets, but changes the IP address and may change UDP port, so the addresses in SIP header and SDP body are no longer valid.

Outgoing INVITE with STUN

INVITE sip:089700732559@sip2.fsys.co.uk:5060 SIP/2.0
Accept: application/sdp
Via: SIP/2.0/UDP 80.144.207.205:62600;rport;branch=z9hG4bKf0791ba4f4197c0dd
Max-Forwards: 70
From: <sip:84415955@fsys.co.uk>;tag=c404812abd
To: <sip:089700732559@sip2.fsys.co.uk>
Call-ID: b0f373a4d6609fa9
CSeq: 1151429907 INVITE
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, INFO
Contact: <sip:80.144.207.205:62600>
Supported: 100rel
User-Agent: HiPath OpenOffice V3 M5T SIP Stack/4.0.26.26
X-Siemens-Call-Type: ST-insecure
Content-Type: application/sdp
Content-Length: 354

v=0
o=MxSIP 0 857906743 IN IP4 80.144.207.205
s=SIP Call
c=IN IP4 80.144.207.205
t=0 0
m=audio 30520 RTP/AVP 9 8 0 18 96 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:96 AMR/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=sendrecv

Figure 3 Outgoing INVITE without usage of STUN

With STUN the public IP and port can be learned with a STUN Binding Request. These addresses are then inserted in SIP header and SDP body.

Behavior of the HiPath / Openscape system

Overview of the different STUN modes

Auto

The STUN component does a NAT type detection and if the result shows that STUN can be used and needs to be used it is switched on, otherwise off. In Tabelle 1 the green modes use STUN. For the red mode (symmetric UDP) STUN cannot be used, the grey modes do not need STUN, so STUN is switched off for these NAT types in AUTO mode.

Always

The NAT type detection is done, but STUN is switched on regardless of the result. The result is shown in WBM and log files, so it can be used for diagnostics.

Off

STUN is switched off completely.

Port preserving router

No NAT type detection is made. STUN gains the information of its public SIP signaling address, but does not start any request to lookup the address for payload. Instead of this, it assumes that the payload IP address is same as the SIP signaling IP address and the RTP port is not changed by the router. Practically this means that STUN monitors the public address of port 5060 by sending out a binding request frequently (every 15 seconds). No binding request is made for ITSP calls.

Static IP

This mode is similar to “Port preserving router”, but the IP address is not monitored at all. Instead of this, the address entered in WBM is used as SIP signaling address. For SDP body, the public IP is used and the port remains unchanged.

Binding opening / keep-alive

Media stream

As soon as the two endpoints of the media connection are known, the system sends out an empty UDP packet to the received media address (c and m-line in received SDP data) to open a NAT/firewall binding. This empty packet also triggers the ITSP’s media gateway to start sending payload (if in “symmetric response routing” mode).

Registration

The fully qualified domain name (FQDN) of any active ITSP that is successfully registered or needs no registration is added to a list.

Every 15 seconds for every list-entry a DNS query is made. This name resolving is done in the same way as it would be done for an outgoing call (SIP INVITE) for this ITSP, that means if the configured port is 0, DNSSRV is used for resolving.

Then an empty UDP packet is sent to every IP address returned by the DNS.

With that mechanism, a binding is opened to all possible proxy servers of the ITSP that may send us a INVITE for an incoming call.

Note that a multi-level cache makes sure that the impact of name resolving on system or network performance is as small as possible.

Interworking of STUN and NAT routers in practice

Port preserving routers

The biggest problems with STUN are some routers that behave non-deterministic. The NAT type detection detects a NAT that works fine, but under load the router changes it behavior.

For example, a lot of routers try to preserve the port if possible. NAT type detection then usually detects a Port restricted Cone NAT and uses STUN. Everything is fine, until it happens that the port needs to be changed, because it is already in use by another host or was used before by the same host and the binding has not timed out yet.

Some routers then fall back to a symmetric NAT, some keep their Cone NAT behavior. For the first it often helps to change the mode to port preserving router, for the latter the Auto (or Always) mode works better.

Application Layer Gateways (ALG)

Some routers offer more or less well implemented application layer gateways.

An ALG looks into the packet and changes the transported addresses in the same way as it does the NAT. A good ALG needs to know the protocol to do this correctly. SIP is supported by most ALG, but sometimes the implementation has significant problems (see below).

In general it is a bad idea to activate both STUN on the telephony system and ALG on the router at the same time, because they both try to do the same. While in theory a good ALG should cope with that, experience shows that this often results in really strange behavior (e.g. some ALG then leave outgoing packets unchangend, but change the public IP inserted by STUN back to the private IP on incoming packets).

Please be aware that if an ALG is used, it is the responsibility of the ALG to do the NAT traversal. Experience shows that some ALGs are badly implemented and for example cannot handle two simultaneous connections, because they mix up the used RTP ports.

Symmetric NAT

Symmetric NAT cannot be traversed by STUN, because the information gained with the help of the STUN server is not valid for packets that are sent to another server (SIP proxy).

A solution would be to send the STUN requests to the SIP proxy and payload partner directly (SIP Outbound / ICE). This is currently supported by neither our telephony systems nor any ITSP we know.

However, by enabling port forwarding on the router, a symmetric NAT router can be “changed” to a “port preserving router”.

Session border controller

The term session border controller (SBC) is not clearly defined. In general a SBC is a device that terminates (in the sense of “communication endpoint”) both SIP signaling and RTP media stream.

As such they have full control over signaling and voice payload and can and must perform NAT traversal on their own.

Sometimes devices or configurations used by ITSPs for far-end NAT traversal are also called “SBC”. For details about these, see section Far-end NAT traversal.

Some typical SBC features are also provided by the HiPath / Openscape telephony systems, so there is usually no need to install a SBC in the local network.

Far-end NAT traversal

Some ITSP use far-end NAT traversal mechanism like symmetric response routing.

There are differences in their implementations, so there is no general recommendation how to configure the HiPath / Openscape telephony system.

Some ITSP only activates their far-end NAT traversal support only, if they see known private IP address (e.g. 192.168.0.1 or any other RFC 1918) in SDP.

It may also make a difference if a call is made to (or coming from) another user of the ITSP or a different provider/phone company.

It is recommended to test incoming and outgoing calls to both external numbers (e.g. mobile phone) and another user account of the same ITSP (that has be be registered at a different telephone system using another public IP address (e.g. other DSL connection)) to make sure payload is fine for all calls.

Examples of misbehaving network devices

In this chapter some problems we had in the past are mentioned. This is neither a complete list nor a detailed analysis of the problem’s cause. It is meant to give a ‘feeling’ for the kind of problems that may occur when setting up an IP network.

NAT routers

TODO:

• port preserving with symmetric fallback
• load problems

ALG

TODO:

• Baudtec ALG