WebRTC SDP Offer and Answer Explained

This article provides a clear and concise explanation of Session Description Protocol (SDP) offers and answers within the context of WebRTC. It covers what these messages contain, how they are generated, and how they enable two browser peers to negotiate and establish a direct multimedia connection.

What is SDP in WebRTC?

Before understanding offers and answers, it is essential to understand SDP (Session Description Protocol). SDP is not a protocol used to transport media; instead, it is a standardized format (a plain text string of key-value pairs) used to describe the properties of a multimedia session.

In WebRTC, peers must agree on how to share data, video, and audio. SDP acts as the contract that defines these technical parameters. The negotiation of this contract follows the Offer/Answer model.

The SDP Offer

An SDP Offer is the initial proposal sent by the initiating peer (the “caller”) to start a WebRTC session. It details what the caller is capable of sending and receiving.

What an SDP Offer Contains:

• Media Types: Specifies whether the caller wants to send/receive audio, video, or data channels.
• Codecs: A prioritized list of audio and video compression formats (e.g., VP8, VP9, H.264 for video; Opus for audio) that the caller’s device supports.
• Network Parameters (ICE Candidates): Information regarding IP addresses, ports, and protocols (UDP/TCP) where the caller can receive media.
• Security Settings: Cryptographic fingerprints (DTLS/SRTP parameters) to ensure the media stream will be encrypted and secure.
• Directionality Attributes: Indicates how the caller wants to handle media, such as sendrecv (send and receive), sendonly, or recvonly.

The SDP Answer

An SDP Answer is the response generated by the receiving peer (the “callee”) after receiving and processing the SDP Offer. It completes the negotiation by agreeing to, rejecting, or modifying the parameters proposed in the offer.

What an SDP Answer Contains:

• Matched Codecs: The receiver looks at the caller’s codec list and selects the best mutually supported codecs. Any codecs the receiver does not support are stripped out.
• Selected Media Streams: A confirmation of which proposed media streams (audio, video, data) the receiver agrees to establish.
• Receiver’s Network Parameters: The receiver’s own IP addresses, ports, and ICE candidates so the caller knows where to send its media.
• Receiver’s Security Settings: Cryptographic fingerprints generated by the receiver to establish the secure DTLS association.
• Agreed Directionality: The final direction of the stream (e.g., if the caller offered sendonly, the receiver will answer with recvonly).

The Exchange Workflow (Signaling)

To establish a connection, the SDP offer and answer must be exchanged through an external mechanism called a signaling server (typically using WebSockets, HTTP, or MQTT). The browser APIs handle this exchange using the following steps:

1. Caller creates an offer by calling peerConnection.createOffer().
2. Caller sets this description as its local configuration using peerConnection.setLocalDescription(offer).
3. Caller sends the SDP Offer to the Callee via the signaling server.
4. Callee receives the offer and sets it as its remote configuration using peerConnection.setRemoteDescription(offer).
5. Callee creates an answer by calling peerConnection.createAnswer().
6. Callee sets this answer as its local configuration using peerConnection.setLocalDescription(answer).
7. Callee sends the SDP Answer back to the Caller via the signaling server.
8. Caller receives the answer and sets it as its remote configuration using peerConnection.setRemoteDescription(answer).

Once both peers have set their respective local and remote descriptions, the SDP negotiation is complete, and the peers can begin direct media transmission.