Understanding WebRTC Media Connections — ICE, STUN, and TURN

In my previous blog article, An Introduction to WebRTC Signaling, I presented the basic flow of two web browsers exchanging SDP through a signaling server. I left out quite a few of the details, but for the most part, those refinements were very geeky and unnecessary to the points I wanted to express. However, there is one important aspect that cannot be ignored.

How do you deal with the fact that most endpoints have been assigned a private IP address behind some form of firewall?

Before I answer that question, allow me to define a few terms. This will be pretty basic stuff for you networking types, but I want to make sure that we are all on the same page.

It would be easy to get far more complicated than what I am about to present, but the point of this article is not to turn everyone into network architects (which I am not). You are welcome to look elsewhere for that.

A Public IP Address is an IP address that is globally unique across the Internet. Only one device may be in possession of a public IP address.

A Private IP Address is an IP address that is not globally unique and may exist simultaneously on many different devices.   A private IP address is never directly connected to the Internet. Devices that possesses a private IP address will be in their own unique IP space (e.g. different companies or domains). The chances are extremely high that the device you are using to read this blog article has acquired a private IP address.

Network Address Translation (NAT) gives private IP addresses access to the Internet. NAT allows a single devices, such as a router, to act as an agent between the Internet (populated with public IP addresses) and a private network (populated with private IP addresses). A NAT device can use a single public IP address to represent many private IP addresses.

A Symmetric NAT not only translates the IP address from private to public (and vice versa), it also translates ports. There are various rules as to how that translation and mapping occurs, but it’s safe to say that with symmetric NAT, you should never expect that the IP address/port of the source is what the destination will see.

Okay, now that we got that out of the way, let’s return to our problem. How do two WebRTC clients communicate with each other when there is a good chance that neither one of them has an IP address and port that the other can send directly to?

This is where Interactive Connectivity Establishment (ICE) comes in. ICE is a framework that allows WebRTC to overcome the complexities of real-world networking. It’s ICE’s job to find the best path to connect peers. It may be able to do that with a direct connection between the clients, but it also works for clients where a direct connection is not possible (i.e. behind NATs).

In the case of asymmetric NAT, ICE will use a STUN (Session Traversal Utilities for NAT) server. A STUN server allows clients to discover their public IP address and the type of NAT they are behind. This information is used to establish the media connection. The STUN protocol is defined in RFC 3489.

In most cases, a STUN server is only used during the connection setup and once that session has been established, media will flow directly between clients.

STUN

If a STUN server cannot establish the connection, ICE can turn to TURN (pardon the pun). Traversal Using Relay NAT (TURN) is an extension to STUN that allows media traversal over a NAT that does not do the “consistent hole punch” required by STUN traffic. TURN servers are often used in the case of a symmetric NAT.

Unlike STUN, a TURN server remains in the media path after the connection has been established. That is why the term “relay” is used to define TURN. A TURN server literally relays the media between the WebRTC peers.

Clearly, not having to use TURN is desirable, but not always possible.  Every WebRTC solution must be prepared to support both service types and engineered to handle the processing requirements placed upon the TURN server.

TURN1

You will have to tell your WebRTC application where to find the STUN and TURN servers.  You do this with the RTCPeerConnection object I mentioned in my WebRTC signaling article.  The JavaScript code to designate two servers will look similar to the following:

var pc_config = {“iceServers”:

    [{url:’stun:stun.1.google.com:19302′}

     {url:’turn:numb.viagenie.ca’,credential: ‘muazkh’, username: ‘webrtc@live.com’}]};

pc = new RTCPeerConnection(pc_config, pc_constraints);

Where do you find these servers? A quick Internet search came up with several public servers (notice the use of public servers in my example).  These public servers  might be useful for prototyping or non-mission critical applications.  They may also work just fine in  production if you are willing to give up some control over your solution.

Note that TURN servers support authentication parameters while STUN servers do not.  Also, I don’t trust that the TURN servers listed below will always be available (assuming that they still are today).  TURN uses a lot of processing power and I cannot imagine that people will be willing to give that away forever.

{url:’stun:stun01.sipphone.com’},

{url:’stun:stun.ekiga.net’},

{url:’stun:stun.fwdnet.net’},

{url:’stun:stun.ideasip.com’},

{url:’stun:stun.iptel.org’},

{url:’stun:stun.rixtelecom.se’},

{url:’stun:stun.schlund.de’},

{url:’stun:stun.l.google.com:19302′},

{url:’stun:stun1.l.google.com:19302′},

{url:’stun:stun2.l.google.com:19302′},

{url:’stun:stun3.l.google.com:19302′},

{url:’stun:stun4.l.google.com:19302′},

{url:’stun:stunserver.org’},

{url:’stun:stun.softjoys.com’},

{url:’stun:stun.voiparound.com’},

{url:’stun:stun.voipbuster.com’},

{url:’stun:stun.voipstunt.com’},

{url:’stun:stun.voxgratia.org’},

{url:’stun:stun.xten.com’},

{

                    url: ‘turn:numb.viagenie.ca’,

                    credential: ‘muazkh’,

                    username: ‘webrtc@live.com’

},

{

                    url: ‘turn:192.158.29.39:3478?transport=udp’,

                    credential: ‘JZEOEt2V3Qb0y27GRntt2u2PAYA=’,

                    username: ‘28224511:1379330808’

},

{

                    url: ‘turn:192.158.29.39:3478?transport=tcp’,

                    credential: ‘JZEOEt2V3Qb0y27GRntt2u2PAYA=’,

                    username: ‘28224511:1379330808’

}

If you would rather own the servers, there are a number of different options. Again, a quick Internet search found a variety that you can buy or acquire as open source.

I work a lot with Avaya technology and I recently learned that the next version of their SBC will contain both STUN and TURN functionality. This makes it a great companion device to the Collaboration Environment WebRTC Snap-in.

Mischief Managed

That’s about all I want to say about this subject today. As I stated earlier, I watered down the networking aspects a bit, but not so much that what I presented wasn’t accurate and hopefully useful. This should be more than enough to make you dangerous and that’s what this blog is all about.

Advertisement

11 comments

  1. SBoobathy · · Reply

    Can we use only TURN server without STUN server????

    Under what circumstance STUN server cannot establish the connection???

  2. nice explanation

  3. Ravi Ranjan · · Reply

    Thanks @Andrew Prokop,
    I have lots of confusion about STUN & TURN server but through this article I’m satisfied .

    Again
    Thank you
    bye … t&c

  4. Neena K Bastin · · Reply

    This is a good article for a starter to webrtc. Thank you

  5. […] Understanding WebRTC Media Connections — ICE, STUN, and TURN […]

  6. So where do the candidate IP’s come from? You can’t just set up a server and have it magically dish out free IP’s…Do you have to buy a block of IP’s for the ICE Candidates to be chosen from? The list of TURN servers you have here.. do they own those blocks of IP’s that they offer as candidates?

    1. They do. That’s one of the reasons they aren’t free. As for the servers I listed, this is an old article. They may not exist anymore.

      1. Thanks! I wasn’t even expecting a reply… ONE more question though… So if the TURN servers are using public IP’s..that the person who owns the server has to buy… then how can you run your own TURN server? if Youre a develop of an app that is going to use WebRTC and you want to supply your own TURN server how would you? Are they only IPv6 addresses?

      2. IP4 is fine. It’s easy to buy/rent a public IP address. You can also rent a virtual server from someplace like GoDaddy. They come with public IPs. That’s what I do for my server applications.

      3. Thanks again. I’ve been following your blog for years and follow you on LinkedIn. You’ve been sort of a silent hero of mine. I work at Nokia and your blog has really given me inspiration to do my own blogging at work. If you don’t mind me asking..how do you deal with keeping a blog about Avaya but also so that they don’t come after you saying that you’re devulging company, proprietary information? I would love to start a public blog like you have here… but I fear that I’d be violating company information…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: