Mastering WebRTC Media Negotiation: From SDP Basics to Front‑End Code

Media Negotiation

In audio‑video communication, both ends must inform each other about supported codecs, transport protocols, and bitrate, which can be visualized as exchanging parcels.

Key questions include who to communicate with, whether the remote side can use the media format, the remote network address, and the most efficient transmission route.

In practice, a signaling channel (commonly a WebSocket) is used to exchange SDP, while media data flows through

RTCPeerConnection

. SDP carries information such as codecs, transport protocol, IP ports, and bitrate.

What Is Media Negotiation?

Before a WebRTC connection can transmit data, peers must exchange SDP to agree on mutually supported media capabilities such as audio/video codecs, transport protocols, IP ports, and bitrate.

Media Negotiation Process

Assuming two browsers, a caller and a callee:

Both connect to a signaling channel and can exchange messages.

The caller creates an offer with

RTCPeerConnection.createOffer

, sets the local description, and sends the SDP.

The offer is delivered to the callee via the signaling server.

The callee receives the offer and sets it as the remote description.

The callee creates an answer with

RTCPeerConnection.createAnswer

, sets the local description, and sends the SDP back.

The caller receives the answer and sets it as the remote description.

This exchange results in both sides having created and exchanged offer/answer SDP and set local/remote descriptions to complete the negotiation.

Front‑End Code Implementation

Caller creates and sends an offer:

<code>//local
var pc_local = new RTCPeerConnection(otps1);
pc_local.createOffer((offer) => {
  pc_local.setLocalDescription(offer);
  singalChannel.send(offer);
}, handleError);</code>

Callee receives the offer:

<code>//remote
var pc_remote = new RTCPeerConnection(otps2);
signalChannel.on('message', (message) => {
  if (message.type === 'offer') {
    pc_remote.setRemoteDescription(new RTCSessionDescription(message));
  }
});</code>

Callee creates and sends an answer:

<code>//remote
pc_remote.createAnswer((answer) => {
  pc_remote.setLocalDescription(answer);
  singalChannel.send(answer);
}, handleError);</code>

Caller receives the answer:

<code>//local
signalChannel.on('message', (message) => {
  if (message.type === 'answer') {
    pc_local.setRemoteDescription(new RTCSessionDescription(message));
  }
});</code>

SDP

What Is SDP?

Session Description Protocol (SDP) is a textual format that describes a session’s media capabilities and network information.

SDP in WebRTC

In WebRTC, SDP conveys supported codecs, codec parameters, transport protocol, ICE candidates, and other session attributes.

Standard

SDP is defined by IETF RFC 4556.

SDP Format

SDP consists of lines of the form

<type>=<value>

. Example:

<code>v=0
o=-7017624586836067756 2 IN IP4 127.0.0.1
s=-
t=0 0..</code>

Key rules:

type is a single‑character key.

value is UTF‑8 text.

No spaces are allowed around the equals sign.

Session Description

Common session‑level attributes include:

v= protocol version

o= origin (username, session ID, version, network type, address type, address)

s= session name (may be “-” if not used)

t= start and stop times (NTP seconds, 0 means permanent)

c= connection information (network type, address type, connection address)

Media Description

After the session description, zero or more media sections appear, each starting with m= and optionally followed by attribute lines such as a=rtpmap and a=fmtp .

<code>m=&lt;media&gt; &lt;port&gt; &lt;transport&gt; &lt;fmt‑list&gt;</code>

<code>a=rtpmap:&lt;payload‑type&gt; &lt;encoding‑name&gt;/&lt;sample‑rate&gt;[/&lt;encoding‑parameters&gt;]</code>

<code>a=fmtp:&lt;payload‑type&gt; &lt;format‑parameters&gt;</code>

WebRTC SDP Summary

WebRTC splits SDP into five parts: session metadata, network description, media description, security description, and quality‑of‑service description. The first three correspond to standard SDP sections, while the last two add WebRTC‑specific attributes.