A Developer's Guide to WebRTC and VoIP Terminology

Real-time communication is full of acronyms that can be overwhelming for newcomers. This guide breaks down the essential terminology you’ll encounter when working with WebRTC and VoIP technologies.

Core WebRTC Concepts

Session Description Protocol (SDP)

The language of WebRTC negotiation. SDP is a text-based format used to describe multimedia communication sessions. It includes information about:

• Media types and codecs
• IP addresses and ports
• Bandwidth information for a media stream
• Security parameters for the media stream or session

SDP can be in a declarative mode or an offer/answer mode. In declarative mode, the SDP is used to describe the session, while in offer/answer mode, the SDP is used to negotiate the session. In declarative mode, the SDP is provided as-is and the receiver needs to agree, it is commonly used with streaming, wherein the publisher is telling the subscriber the formats and codecs it will used. In offer/answer mode, the SDP is used to figure out the best common settings between the two communicating peers (typically, a client and a server).

In webrtc, we use the offer/answer model for negotiation. However, we could have used the declarative model for negotiation because the service controls both the server and the clients and thus knows ahead of time what formats and codecs to use.

Interactive Connectivity Establishment (ICE)

The ICE protocol helps WebRTC peers find the best path to connect especially through NATs and Firewalls. It has several phases of operation:

• Candidate Gathering: Discovers all possible IP addresses associated with the peer. These are namely, host candidates (the local IP address), server-reflexive/peer-reflexive candidates (the public IP address as seen by the STUN server) and relay candidates (the public IP address as seen by the TURN server).
• SDP Exchange: Share the discovered routes with the remote peer. These can be shared as soon as they are discovered (trickle-ice) or once discovery is finished (with the final SDP). One the remote peer receives the SDP, it will sort and arrange its local candidate and remote candidate pairs to begin checks. The candidate pairs are listed in the order of priority, with the idea that the highest priority candidate pair is tested first and has the highest chance of success, thus selected as the default candidate pair.
• Connectivity Checks: When the adresses are received by the remote peer, the peers start to test the routes. This is done by sending STUN packets to the candidate addresses.
• Connection Establishment: media packets start flowing as soon as a pair found, however, this may not be the final candidate pair, as the peers continue to test and find the best route.

In summary, ICE negotiation is a process of discovering, testing, anmd selecting the best local and remote candidate pair. However, connections are rarely stable, users move in and out of coverage, sometimes the WiFi that you were using is out of range and the connection is lost. To handle this, ICE can re-negotiate via an ice restart, which provides a mechanism to re-negotiate the connection.

TURN (Traversal Using Relays around NAT)

We alluded to relay-candidates in the ICE section. These are proxy IP addresses at relay servers that are used to relay media between peers when direct peer-to-peer communication isn’t possible. Especially firewalls and NATs, such as full-cone NATs, that do not allow direct ingress connections without an egress connection first being established. In this case, the peer behind the NAT will establish a connection with the relay server, which will then allow the remote party to send media packets to the peer behind the NAT without requiring a connection to be first made between the eventual peers.

Session Initiation Protocol (SIP)

The protocol that handles call setup, modification, and teardown in VoIP systems. SIP is like a phone operator that:

• Establishes connections between parties
• Manages call features (hold, transfer, etc.)
• Handles presence information

Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP)

RTP is a transport protocol that is used to transmit audio and video data in real-time. It is the particularly preferred because the application can control the reliability and scalability of the media streams, i.e., implement retx, fec, etc. RTP is accompanied by RTCP, which is the monitoring and statistics protocol for RTP and provides the synchronisation, network and media metrics and Quality of Service (QoS) information for the media streams.

Codecs (Coder-Decoder)

Software that compresses and decompresses media:

• Opus: High-quality audio codec
• VP8/VP9: Video codecs from Google
• H.264/H.265: Industry-standard video codecs
• AV1/H.266: The new video codecs

DTLS (Datagram Transport Layer Security)

The security protocol that encrypts media in WebRTC, provides end-to-end encryption, authentication and integrity.

Quality Metrics

There are several first-order metrics that are used to measure the quality of media streams in WebRTC. These are:

• RTT (Round Trip Time): The time taken for a packet to travel from source to destination and back.
• Fraction Lost: The percentage of packets lost during a call.
• Jitter: The variation in packet arrival times. However, in RTP, it is long-term variation as the latest measurement only has a 1/16 (≈6.25%) impact on the overall jitter value.

These can be used to calculate several second-order metrics, such as MOS (Mean Opinion Score), which is a measure of perceived media quality on a scale of 1 to 5.

Putting It All Together

These components work together in a typical WebRTC call:

1. SIP or custom signaling establishes the connection
2. ICE finds the best path using STUN/TURN
3. DTLS secures the connection
4. RTP/RTCP handles media transmission and monitoring
5. Codecs compress/decompress the media

Understanding these terms is crucial for:

• Debugging connection issues
• Optimizing media quality
• Implementing new features
• Communicating with other developers

For more detailed information, refer to:

• WebRTC.org
• IETF RFCs for each protocol
• W3C WebRTC specifications

This guide will be updated as new standards and technologies emerge. Feel free to suggest additions or clarifications.