When you heard WebRTC Server – what does it really mean? There are 3 different types of WebRTC servers that you need to know about: signaling, NAT traversal and media server.
Note: Actually, there are the 4th type of server that always appears in any WebRTC project. It’s the application server. WebRTC application servers are like any other web application servers out there, it hosts the HTML, CSS and JS files, a few (or many) images and you can’t really have a service without it. But it is not directly related only to WebRTC so I will not clasify it as one.
Let’s dive in!
WebRTC signaling servers are in charge of connecting users to one another.
Signaling servers for WebRTC are sometimes embedded or collocated/co-hosted with the application servers, but more often than not they are built and managed separately from the application itself.
While WebRTC handles the media, it leaves the signaling to “someone else” to take care of. WebRTC will generate SDP – these are fragments of messages that the application needs to pass between the users. Passing these messages is the main concern of a signaling server.
A WebRTC signaling server passes signaling messages between the users to establish a session There are 4 main signaling protocols that are used today with WebRTC, each lending itself to different signaling servers that will be used in the application:
SIP, XMPP and MQTT all have existing servers that can be deployed with WebRTC.
The Custom option takes many shapes and sizes. Node.js is quite a common server alternative used for WebRTC signaling (just make sure not to pick an outdated alternative – that’s quite a common mistake in WebRTC).
NAT traversal is important to get more sessions connected properly in WebRTC.
To work well, WebRTC requires NAT traversal servers. These WebRTC servers are in charge of making sure you can send media stream from one browser to another.
There are two types of NAT servers needed: STUN and TURN. TURN servers always implement STUN as well, so in all likelihood you’re looking at a single server here.
STUN is used to answer the question “what is my public IP address?” and then share the answer with the other user in the session, so he can try and use that address to send media directly.
TURN is used to relay the media through it (so it costs more in bandwidth costs), and is used when you can’t really reach the other user directly.
A few quick thoughts here:
WebRTC media servers makes it possible to support more complex scenarios.
WebRTC media servers are servers that act as WebRTC clients but run on the server side. They are termination points for the media where we’d like to take action. Popular tasks done on WebRTC media servers include:
The adventurous and strong hearted will go and develop their own WebRTC media server. Most would pick a commercial service or an open source one. For the latter, check out these tips for choosing WebRTC open source media server framework.
In many cases, the thing developers are looking for is support for group calling, something that almost always requires a media server. In that case, you need to decide if you’d go with the classing (and now somewhat old) MCU mixing model or with the more accepted and modern SFU routing model. You will also need to think a lot about the sizing of your WebRTC media server.
For recording WebRTC sessions, you can either do that on the client side or the server side. In both cases you’ll be needing a server, but what that server is and how it works will be very different in each case.
If it is broadcasting you’re after, then you need to think about the broadcast size of your WebRTC session.
❓Can I run WebRTC without any server?
✅ No. This is one of the most common misconception in WebRTC world. You will need somehow to know who to communicate with and in many cases, you will need to somehow negotiate IP addresses and even route data through a server to connect your session properly.
❓ Will WebRTC servers spy on me and my data?
✅ That depends on the service you are using, as different implementations will put their focus on different features.
In general, signaling and NAT traversal servers in WebRTC don’t have access to the actual data. Media servers often have (and need) access to the actual data.
❓ Can I host WebRTC servers on AWS?
✅ Yes. You can host your WebRTC servers on AWS. Many popular WebRTC services are hosted today on AWS, Google Cloud, Microsoft Azure and Digital Ocean servers. I am sure other hosting providers and data center vendors work as well.
❓ Can I run WebRTC on my website?
✅ WebRTC can be added to any website. In such a case, your website server will serve as the application server (the 4th type I noted above) and you will need to add into the mix the other WebRTC servers: signaling server, NAT traversal server and sometimes media server.
No matter how or what it is you are developing with WebRTC, you should know what WebRTC servers are and what they are used for, so that you can build a solution that fits your need.
See you in future posts!