Configuring RTC for Symmetric UDP for NAT Traversal

Other versions of this page are also available for the following:

• Windows Embedded CE 6.0 R3

8/27/2008

RTC supports the following features for NAT Traversal.

• The Port Manager APIs
• Symmetric UDP signaling for the SIP and Media stacks

For more information about using the Port Manager extensions with NAT Traversal, please see the IRTCPortManager3 interface as well as Using STUN with the RTC Client API.

For more information about NAT Traversal, please see NAT Traversal and VoIP.

Enable Symmetric UDP

RTC 1.5 defines two new initialization flags to enable Symmetric UDP signaling for SIP. Symmetric UDP for media is on by default.

• RTCIF_ENABLE_SYMMETRIC_UDP_SIGNALING - This enables symmetric UDP signaling. Therefore, if a profile is used and the protocol selected is UDP, then RTC will send and receive SIP packets using a single source port.
• RTCIF_PREFER_STATIC_PORT_FOR_SYMMETRIC_UDP - This flag tells RTC to use port 5060 for symmetric UDP signaling if it is available. This availability is not guaranteed. Another application may have already opened 5060 and it would no longer be available for use by RTC.

To use these flags you would do the following in your initialization sequence code for the RTC Client API.

IRTCClient2  *pIRTCClient2;
HRESULT hr;

//  CoCreate IRTCClient2 to pIRTCClient2.  
//  Initialize using InitializeEx rather than Initialize.

hr = piRTCClient2->InitializeEx(RTCIF_ENABLE_SYMMETRIC_UDP_SIGNALING | RTCIF_PREFER_STATIC_PORT_FOR_SYMMETRIC_UDP);

For more information, please see RTCIF_ as well as IRTCClient2::InitializeEx and IRTCClient2.

How Symmetric UDP and RTC work

VoIP devices behind a NAT have an internal, private IP address that is different than the required public address outside the NAT. Internal, private IP address and port combinations are not routable outside the internal, private network. In order for VoIP devices to make calls outside their private network, they need to have routable IP addresses and ports.

NATs provide a mapping from internal addresses and ports to external, routable addresses and ports. These mappings are typically dynamically created, so that the internal device does not know what mapping it has, nor even what its external IP address and port is. Also, a NAT will typically change these mappings over time, often for security reasons and even close down the mapping if it has not been used for some specified period of time.

Most VoIP devices use protocols that are UDP based. UDP is a protocol that is not connection oriented, meaning that two devices may not use the same ports to send and receive packets. In a sense, a device using UDP cannot count on a particular port for a particular type of media, either for itself or for any other device it is calling.

Symmetric UDP means that a device will use the same port for both sending and receiving information. A VoIP device in this case will use its source IP address and port for outgoing SIP packets and it will use the same address and port to listen for replies.

If the VoIP device is communicating with an outside server that knows it is using symmetric UDP, then that outside server can use the source IP address and port that is being used by the NAT to reply to the VoIP device inside the NAT. The server will not use the information in the SIP packet itself, since this information is the internal, private and therefore unroutable IP address and port. It will use the actual IP address and port that originated from the NAT. The server has no way of knowing how the VoIP device wants to receive data if it is different from symmetric UDP, since this information is also in the SIP but is also the erroneous internal, private address. By forcing UDP to be symmetrical, with the VoIP device fully aware of that requirement, the server messages back to the VoIP device can penetrate the NAT and will not be blocked since they contain a valid address.

A smart proxy server or Session Border Controller (SBC) does just this. It uses the information from the actual packet received, the information visible on the IP address header, which contains the NAT address and port external mapping, rather than the information in the SIP header, to reply back to the VoIP device. If the VoIP device or VoIP application is not using symmetric UDP and therefore not listening on the same port, then it will be listening on the wrong port and never receive the awaited signaling reply.

The same situation applies to the media transport, with the SBC fixing up the IP address and port correctly, using the NAT publicly mapped address rather than the private, unroutable one in the packet itself. The SBC will insert itself into the media stream and act as a relay for both the sender and the receiver. Since it is using Symmetric UDP, like the SIP messages, the correct address is being used and the media passes through the NAT unhindered. As long as the VoIP device knows that it must be using Symmetric UDP and both listen and send on the same port, this situation will work.

Keeping the Mapping Alive

Even though it is typically outside the control of the VoIP device, in order to keep the NAT mapping alive, the connection must remain a live connection. The device has no sure fire way of knowing what the required refresh rate is to keep the mapping alive. However, it can and should keep sending packets at regular intervals in order to keep the port mapping open or its SIP server should. As said before, the expiration rates of the mappings vary across NAT boxes but generally are on the order of a minute or more. As long as information flows regularly at less than one minute between packets, the connection and mapping should stay open.

RTC now allows a minimum refresh interval of 19 seconds. Anything less than 19 seconds will be rejected, but if the SIP server sets an expiration time to less than a minute in order to refresh the mapping, RTC will accept that and will refresh that frequently. It is up to the server to set the Expiry time to less than a minute. RTC will not set the refresh rate to under a minute on its own.

For "early media" scenarios, where a device starts getting media from the other side of a NAT before a mapping is in place, please see the subsection "Early UDP" Dealing with UDP blocking in "early media" scenarios in NAT Traversal and VoIP.

Or you can go directly to the information on the registry key, EnableEarlyUDPPackets, located in RTC Client API General Registry Settings.

See Also

Other Resources

Fundamental RTC Code Examples