Introducing Network Traversal Service

Introducing Network Traversal Service

Today, at WebRTC World in San Jose we’ll announce the launch of Twilio Network Traversal Service. Network Traversal Service (NTS) brings low latency, cost effective, reliable STUN and TURN capabilities to WebRTC and other communication platform developers, with service distributed across five continents.

Building global WebRTC solutions can be hard. Many developers choose Twilio Client to abstract the challenges of managing signaling, registration and media. However, some developers want to define their own signaling solution, without having to build out a global network traversal service for media relay. That’s where Network Traversal Service (NTS) comes in.

One of the routine challenges developers building their own solution need to tackle is how to get their media around firewalls and NATs. In general, you’ll want your media to go direct peer to peer as often as possible – in order to get lower cost, higher quality, lower latency, and potentially greater support for media types.

That is possible in most situations, but it requires some basic signaling assistance to help each endpoint learn what it looks like to the public internet. There are multiple ways in which that signaling assistance can be performed, but STUN is one of the most prevalent. STUN servers allow devices behind a firewall to discover what public IP and port the NAT is mapping to the device’s private IP and local port. Once the device knows this, it can signal this information to the other endpoint in the call, and media sent directly to that address should reach the device as required. In the majority of situations (typically about 85% depending on network configurations), this STUN lookup is all you need to achieve Peer to peer communications – and STUN lookups with Twilio’s Network Traversal Service are completely free.

For some firewall configurations though, STUN is not sufficient, this is particularly prevalent in enterprise and mobile networks when a firewall provides a unique mapping to a different public IP/port for every destination IP address, known as Symmetric NAT.

In a symmetric NAT, if a device contacts a STUN server to get it’s public IP/port, the IP/port that the STUN server returns will work for the STUN server to contact the device. But if Device A passes that IP/port to Device B, when Device B attempts to send media to that IP address the NAT will not translate that through to Device A. In these situations, there is no way for media to be sent directly peer to peer – it must be relayed via some kind of publicly addressable media relay point. This is the function that a TURN server provides.

In these scenarios, you’re looping the media back to wherever your media relay point is, inherently introducing additional latency. The longer the trip your media has to make, the more latency you’ll experience.  Now your media travels from Device A to your media relay point, and then to Device B. Twilio’s TURN service is deployed in seven different regions around the world, and we intelligently detect the geographically closest relay point to your users in order to minimize introduced latency.

We originally developed STUN and TURN as a component of Twilio Client, as part of our drive to make our Twilio Client product the best global WebRTC platform out there. Once we built it, we felt that developers building their own real-time communications service would benefit from this service so we wanted to ‘unbundle’ it and make it available as a standalone service.

Using Twilio’s Network Traversal Service, you can dramatically decrease your time to market, and ensure your media traversal is handled by a global, highly available platform so you can focus your development efforts on your core mission. Pricing is based on per gigabyte of relayed media, and you should find it much more cost effective than building a similar service yourself.

To learn more and get started, visit twilio.com/stun-turn