WebRTC Server Side Cheat Sheet
If you want to build a WebRTC product that works, you will need to first
understand what server side components are necessary. Only then will you be
able to pick out your technology stack and architecture to fit your needs.
WebRTC is a rather new technology that needs more than just a “regular” web server
and your good ol’ browser.
There are 3 additional server types you will need to deal with and deploy to get that
product of yours running well. In this brief cheat sheet, I want to share with you what
these servers are, their machine specification and what other developers are doing to
successfully build their WebRTC products.
- Tsahi Levent-Levi
There are 4 servers needed to run most WebRTC services:
#1 - Web Server
The server “behind” the URL users place in their browser. Built
from every-day web development technologies
Have one already? Great. See if you can merge it CPU
with the signaling server Memory
Need to decide? Start by picking a singling server Storage
and then decide on your web server technology Network
Like this? Learn more about WebRTC development:
http://bit.ly/webrtc-architecture
#2 – Signaling Server
The server handling calls, sessions and rooms. Used to send
SDP offer/answer messages between WebRTC devices
Go for an asynchronous language/framework, CPU
preferably based on Node.js Memory
Check github for existing solutions Storage
Explore the use of SaaS: Firebase, PubNub, Network
Pusher, …
#3 – STUN/TURN Server
Takes care of making sure media gets connected, even if there
are firewalls and NATs along the route
Don’t use public, freely available STUN servers in CPU
production Memory
Deploy COTURN or restund on your own Storage
Or use a managed service from XirSys, Twilio, Bit6, Network
#4 – Media Server
Optional, used when you need to process media in one way or
another on the server side
Most products end up needing media servers CPU
Their specification and technology stack depends Memory
on your exact needs… Storage
See below for a few examples Network
Like this? Learn more about WebRTC development:
http://bit.ly/webrtc-architecture
SFU – Routing Media
Group video calling where the server routes media between the participants
The popular choice for multiparty in WebRTC CPU
Look at Jitsi, Kurento, mediasoup, SwitchRTC and Memory
Intel CS for WebRTC Storage
Network
MCU – Mixing Media
Group video calling where the server mixes and combines media inputs into a single
stream sent to the participants
Usually adopted when connecting to external CPU
system such as telephony and video streaming Memory
Look at Kurento, Intel CS for WebRTC and Dialogic Storage
PowerMedia XMS Network
Recording Server
Optional, used when you need to process media in one way or another on the server
side
It depends on how you want to record – the streams CPU
?
received, or post processed for single file playback Memory
Look at your SFU and MCU solutions to see how Storage
recording fits into their architecture Network
Don’t forget CPaaS
Communications Platform as a Service – fully managed (and hopefully with the
features on you need)
Less development effort
Less ongoing maintenance
Lower risk
Like this? Learn more about WebRTC development:
http://bit.ly/webrtc-architecture
