Symmetric NAT Traversal

Revision as of 15:58, 26 March 2018

Tmedia supports NAT (Network Address Translation) Traversal.

Typical Use-Case

A Network Address Translation (NAT) has many functions such as: firewall, hiding the client IP. Usually, a NAT limits the number of "opened" IPs/Ports allowed to communicate with the internal network and ignores all messages addressed to the "closed" IPs/Ports. A typical call can be described as follow:

1. When a client (Bob) calls someone (Alice) located outside of the internal network, the messages need to get through the NAT which sends the messages to SBC/Tmedia.
2. After their reception, SBC/Tmedia processes and forwards the messages to Alice.
3. When SBC/Tmedia gets a reply from the Alice, it sends the answer back to the NAT.
4. The NAT checks if the received messages from SBC/Tmedia are allowed to be forwarded to Bob.

Bob's IP can be addressed only in the internal network. When SBC/Tmedia needs to send the Alice's messages to Bob, it cannot use the internal IP of Bob or any other IP closed by the NAT. Usually, a replied message is addressed to the same IP/Port of the NAT where the previous message came from. In this case, SBC/Tmedia sends Alice's messages to the public IP of the NAT. Then, the NAT maps back the message to Bob's internal IP. This is called a symmetric response.

TelcoBridges and Passive NAT Traversal

Tmedia supports passive NAT Traversal that addresses the need of peer VoIP endpoint having a private network address. This endpoint device is situated behind a NAT device, e.g. Firewall, while the Tmedia VoIP port has a public IP address. For the passive mode, TMG detects the received RTP packet's source IP address and port. In response, Tmedia uses this source IP address and port as the packet destination for RTP.

This is also called Remote NAT traversal or far-end NAT traversal.

TelcoBridges and Active NAT Traversal

Active NAT traversal means the TMG endpoint is behind a NAT. The Tmedia unit can advertise a public IP so that the remote device will know where to send the RTP traffic. It can also send the 'a=direction:active' in SIP SDP attribute so that the remote device puts itself in passive mode.

This is also called Local NAT traversal or near-end NAT traversal.

SIP Call Flow Over UDP

A typical call is made of a flow of messages and is composed of two parts: Session Initiation Protocol (SIP) and Real-Time Transport Protocol (RTP). The SIP part allows:

• the different connection points (Bob's device, NAT, SBC/Tmedia, Alice's device) to identify themselves;
• to negotiate the parameters (message format) the connection points will use;
• the initiation of call states (phone ringing, phone picked up, closing the call).
  
  

A call always begins and ends with a SIP traversal (before and after the media transmission). The media is transmitted through RTP.

In a User Datagram Protocol (UDP), a SIP traversal through the NAT can be resumed as follows:


The initiating client Bob generates an INVITE request that is to be sent through the NAT to SBC/Tmedia. The INVITE message is represented in Figure 2 by (1) and is as follows:

Message 1:

  INVITE sip:alice@a.example SIP/2.0
  Via: SIP/2.0/UDP 192.168.1.5;rport;branch=z9hG4bKnashds7
  Max-Forwards: 70
  From: Bob <sip:bob@example.com>;tag=ldw22z
  To: Alice <sip:alice@a.example>
  Call-ID: 95KGsk2V/Eis9LcpBYy3
  CSeq: 1 INVITE
  Supported: outbound
  Route: <sip:ep1.example.com;lr>
  Contact: <sip:bob@192.168.1.5;ob>
  Content-Type: application/sdp
  Content-Length: ...
[Session Description Protocol not shown]

Here are a number of points to note with this message:

1. Responses to this request will not automatically pass back through a NAT, so the SIP 'Via' header 'rport' is included in the "Symmetric Responses";
2. the 'ob' parameter is added to the 'Contact' header to ensure that all subsequent requests are sent to the same flow.

The response will be sent to the address appearing in the 'received' parameter of the SIP 'Via' header (address 11.23.45.68). The response will not be sent to the port deduced from the SIP 'Via' header, as per standard SIP operation but will be sent to the value that has been stamped in the 'rport' parameter of the SIP 'Via' header (port 8050).

In Figure 2 (4), the 'rport' parameter port number is added in the 'Via' header and the 'received' parameter in the previous 'Via' header. The 'Route' header is removed , and instead, a Record-Route with a token is inserted.

Message 2:

  INVITE sip:alice@172.16.1.4 SIP/2.0
  Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4bKnuiqisi
  Via: SIP/2.0/UDP 192.168.1.5;rport=8050;branch=z9hG4bKnashds7;received=11.23.45.68
  Max-Forwards: 69
  From: Bob <sip:bob@example.com>;tag=ldw22z
  To: Alice <sip:alice@a.example>
  Call-ID: 95KGsk2V/Eis9LcpBYy3
  CSeq: 1 INVITE
  Supported: outbound
  Record-Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
  Contact: <sip:bob@192.168.1.5;ob>
  Content-Type: application/sdp
  Content-Length: ...
[Session Description Protocol not shown]

Important Reminders

• All devices in the path must support symmetric RTP/RTCP: RFC 4961

Configuration

• Configure NAT Traversal for version 3.0
• Configure NAT Traversal for version 2.10
• Configure NAT Traversal for version 2.9
• Configure NAT Traversal for version 2.8
• Toolpack v2.7: SIP Advance Features
• Toolpack v2.6: SIP Advance Features

External Sources

• RFC 4961 Symmetric RTP / RTP Control Protocol (RTCP)