Dialogic Blog

Solving WebRTC’s Media Server and NAT Traversal Problems in One Shot

by Chad Hart

Nov 19, 2014 7:41:32 AM

gorpy_stuff

Our own John Hermanski and Hanzhong Gu recently wrote a tech note showing how the widely used rfc5766-turn-server can run on the same server with PowerMedia XMS.  If you are not a hardcore WebRTC implementer you probably have no idea what I am talking about, so let me explain rfc5766-turn-server is and why is this important.

The Firewall & NAT Problem

Getting VoIP traffic through Network Address Translators (NAT) and firewalls is tough. These devices change and restrict the IP address information. This is not a problem for website traffic because the underlying routing architecture is consistently implemented, usually left open, and transparent to the application. That is not the case for VoIP which has IP address and port information embedded inside its protocol layers, out of the reach of firewall and NAT devices.

These problems are in the realm of SBCs with their NAT traversal techniques. The people standardizing WebRTC wanted to traffic to be able to travel in a peer-to-peer fashion without mandating the use of SBCs. WebRTC leverages 3 standardized technologies that have been around for a while, but not widely used:

WebRTC endpoints need to support one or more variations of ICE. WebRTC providers should at a minimum offer a STUN server. STUN is a lightweight function that is inexpensive to operate.

TURN servers are not always needed, but they are needed often enough that any serious WebRTC provider should also include that too. TURN servers needs to terminate and reorginate media streams, consuming a lot of bandwidth, so operating one is a lot more expensive.

 

So what is RFC5766?

RFC5766 is an Internet Engineering Task Force (IETF) standard that defines TURN.

rfc5766-turn-server is a fully functional open source project that includes STUN and TURN capabilities lead by Oleg Moskalenko. This project has become very popular and is even used as part of Amazon’s Mayday service. John Hermanski was one of the first users of this project and wrote a great setup guide for it.

 

So what does this mean for PowerMedia XMS?

TURN servers relay media. Media servers by their nature manipulate and relay media. Relaying twice adds latency that hurts quality. Wouldn’t it be easier if these two elements could be one and the same? That effectively what happens when you run rfc5766-turn-server on PowerMedia XMS. Putting rfc5766-turn-server on the same instance also gives XMS considerably more flexibility for dealing with network and addressing intricacies. Having a single device instead of two also simplifies network management.

Check out John’s tech note for more details.

 

Topics: WebRTC