We have published a previous post about WebRTC and WebRTC servers without any technical details. Unlike the first post, in this second part of our WebRTC blog post series, We will answer the question of what is WebRTC, introduce its basics and technical terms: SDP, ICE, WebRTC STUN Server, WebRTC TURN Server, RTP, and WebRTC Signaling.
I want to explain the
Table of Contents
- What is WebRTC (Web Real-Time Communication)?
- SDP (Session Description Protocol)
- ICE (Interactivity Connection Establishment)
- WebRTC STUN Server (Session Traversal Utilities for NAT)
- WebRTC TURN Server (Traversal Using Relays around NAT)
- RTP (Real-Time Protocol)
- WebRTC Signaling Server
What is WebRTC (Web Real-Time Communication)?
What is Webrtc? This question has been asked a lot in recent years. WebRTC stands for web real-time communications. WebRTC is a very exciting, powerful, and highly disruptive cutting-edge technology and streaming protocol.
WebRTC is HTML5 compatible and you can use it to add real-time media communications directly between browser and devices. And you can do that without the need of any prerequisite of plugins to be installed in the browser. And Webrtc is progressively becoming supported by all major modern browser vendors including Safari, Google Chrome, Firefox, Opera and others.
Thanks to WebRTC technology, you can embed the real-time video directly into your browser-based solution to create an engaging and interactive streaming experience for your audience without worrying about the delay. WebRTC video streaming is just changing the way of engagement in the new normal.
Now that we have an answer to the question of what is WebRTC, let’s go into a little more detail.
In our example, WebRTC is the technology to establish communication between Client-A and Client-B.
SDP (Session Description Protocol)
SDP is a simple string-based protocol and it is to share supported codecs between browsers.
In our example,
- Client-A creates its SDP ( called offer) and saves as local SDP then shares it with Client-B.
- Client-B receives the SDP of Client-A and saves it as remote SDP.
- Client-B creates its SDP (called answer) and saves as local SDP then shares it with Client-A.
- Client-A receives the SDP of Client-B and saves it as remote SDP.
The signaling Server is responsible for these SDP transfer between peers.
Let assume Client-A may support H264, VP8, and VP9 codecs for video, Opus, and PCM codecs for audio. Client-B may support the
ICE (Interactivity Connection Establishment)
Interactive Connectivity Establishment (ICE) is used in problems where two nodes across the Internet must communicate as directly as possible, but the presence of NATs and Firewalls make it difficult for nodes to communicate with each other. It is a Networking technique that makes use of STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relays Around NAT) to establish a connection between two nodes that is as direct as possible.
WebRTC STUN Server (Session Traversal Utilities for NAT)
STUN Server is responsible to get all the addresses of a machine. For example, our computers generally have one local address in the 192.168.0.0 network and there is a second address we see when we connect to www.whatismyip.com, this IP address is actually the Public IP address of our Internet Gateway(modem, router, etc.) so let’s define STUN server; STUN servers let peers know theirs Public and Local IP addresses.
Google provides a free STUN server (stun.l.google.com:19302).
WebRTC TURN Server (Traversal Using Relays around NAT)
TURN (Traversal Using Relays around NAT) is a protocol that assists in the traversal of network address translators (NAT) or firewalls for WebRTC applications. TURN Server allows clients to send and receive data through an intermediary server. The TURN protocol is the extension to STUN. Sometimes, addresses got from STUN server cannot be used to establish for peer to peer connections between peers because of NAT/Firewall. In this case, data relays over TURN Server
Connection over TURN server between peers
In our example,
- Client-A finds out their local address and public Internet address by using STUN server and sends these address to Client-B through Signalling Server. Each address received from STUN server is an ICE candidate.
- Client-B does the same, gets local and public IP addresses from STUN server and sends these addresses to Client-A through Signalling Server.
- Client-A receives Client-B’s addresses and tries each IP addresses by sending special pings in order to create the connection with Client-B. If Client-A receives a response from any IP addresses, it puts that address in a list with its response time and other performance credentials. At last Client-A choose the best addresses according to its performance.
- Client-B does the same in order to connect to Client-A
RTP (Real Time Protocol)
RTP is a mature protocol for transmitting real-time data on top of UDP. Audio and Video are transmitted with RTP in WebRTC. There is a sister protocol of RTP which name is RTCP(Real-time Control Protocol) which provides QoS in RTP communication. RTSP(Real-time Streaming Protocol) uses RTP protocol as well in data communication.
WebRTC Signaling Server
The last part is the Signalling Server which is not defined in WebRTC. As mentioned above, Signaling Server is used to send SDP strings and ICE Candidates between Client-A and Client-B. The Signaling Server also decides which peers get connected to each other. WebSocket technology is the preferred way in Signalling Servers for communication.
Signaling message sequence
In this post, we have introduced the basic components and terms under WebRTC technology without coding details. We will continue to WebRTC blog post series with Peer-To-Peer connection establishment in detail.
In order to get more details about WebRTC, you can check this great post out as well.
You may also want to check WebRTC Load Testing in 5 Minutes and Troubleshooting Guide for WebRTC video freezing/blurring/pixelating issues blog posts.