Symmetric NAT Traversal

Latest revision as of 17:13, 27 February 2020

Applies to version(s): v3.0

SBC/Tmedia supports NAT (Network Address Translation) Traversal.

Symmetric NAT Traversal

A Network Address Translation (NAT) has many functions such as: firewall, and hiding the client IP. Usually, a NAT limits the number of "opened" IPs/Ports that are allowed to communicate with the internal network and ignores all messages sent to the "closed" IPs/Ports. A correct configuration of TSB/Tmedia allows the messages to reach a client behind a NAT, also known as NAT Traversal. There are two cases of NAT traversal: "Active NAT Traversal" where TSB/Tmedia is behind a NAT and "Passive NAT Traversal" where the client is behind a NAT.

A Symmetric NAT Traversal is the process that sends the replied message back to the same public IP/Port where the message came from.

TelcoBridges and Active NAT Traversal

Active NAT traversal means the SBC/Tmedia endpoint is behind a NAT. The SBC/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.

TelcoBridges and Passive NAT Traversal

SBC/Tmedia supports passive NAT Traversal, which 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 SBC/Tmedia VoIP port has a public IP address. For the passive mode, SBC/Tmedia detects the received RTP packet's source IP address and port. In response, SBC/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.

Typical Use-Case

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 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 only be used in the internal network. When SBC/Tmedia needs to send the Alice's messages to Bob, the message cannot be dispatched directly to the internal IP of Bob or any other IP closed by the NAT. Usually, a replied message is transmitted to the same IP/Port of the NAT from where the previous message originated. In this case, SBC/Tmedia sends Alice's messages to the public IP of the NAT and the NAT maps back the message to Bob's internal IP. This is called a symmetric response.

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 is shown 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
  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.

Message 2:

  INVITE sip:alice@172.16.1.4 SIP/2.0
  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   
  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

External Sources

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