SDP Offer/Answer Model Explained (With Examples)

The SDP Offer/Answer model is a fundamental mechanism in real-time communication protocols like SIP and WebRTC. It allows two endpoints to negotiate and agree upon the media streams (audio, video, data), codecs, and transport parameters they will use for a session. One party sends an "Offer" detailing its capabilities, and the other responds with an "Answer" accepting or modifying those terms.Imagine two people trying to talk on the phone, but one only speaks English and the other only Spanish. They need a way to find a common language. In the digital world, real-time communication systems face a similar challenge. Devices have varying capabilities: different audio codecs (G.711, Opus), video codecs (H.264, VP8), multiple video resolutions, or even the ability to share screens. Without a standardized negotiation process, establishing a connection would be a chaotic trial-and-error.The SDP Offer/Answer model solves this by providing a structured way for endpoints to declare what they can do (the Offer) and what they will do (the Answer). It eliminates the need for prior knowledge of each other's capabilities, ensuring that once a session is established, both sides are compatible and ready to exchange media. This dynamic negotiation is crucial for interoperability across diverse hardware and software.The SDP Offer/Answer model involves a sender proposing a set of desired media parameters, and a receiver responding with its accepted or modified parameters. This exchange typically occurs within signaling protocols like SIP or WebRTC's signaling channel.Step-by-Step Process:1. The Offer: The initiating endpoint (the "offerer") generates an SDP message that describes its preferred and supported media capabilities. This includes: * Session-level information: Originator, session ID, connection information (IP address). * Media-level information (m-lines): One or more m= lines, each describing a different media type (audio, video, application). For each m= line, it lists: * Port number (e.g., 5004) * Protocol (e.g., RTP/AVP) * Supported payload types (codecs) in order of preference (e.g., PCMU PCMA). * Other attributes (a= lines) like sendrecv, rtcp-mux, ice-ufrag, etc. The offerer might suggest multiple codecs for audio or video, indicating its flexibility. This Offer is then sent to the other endpoint (the "answerer"), typically embedded within a SIP INVITE message or a WebRTC setLocalDescription.2. The Answer: Upon receiving the Offer, the responding endpoint (the "answerer") processes the SDP message. It determines which of the offered capabilities it can support and wishes to use. * The answerer must respond to every m= line in the Offer. It can either accept a media stream, reject it (by setting the port to 0), or modify its parameters. * For accepted media streams, the answerer selects a common codec from the offerer's list (e.g., if the offer lists PCMU PCMA and the answerer supports PCMA G729, it might pick PCMA). The answerer must not introduce new codecs not present in the Offer. * It specifies its own connection information and desired attributes. This "Answer" SDP is then sent back to the offerer, commonly in a SIP 200 OK response or a WebRTC setRemoteDescription.Offer/Answer Rules and Renegotiation:* Codec Negotiation: Only codecs present in the Offer can be selected in the Answer. The answerer effectively prunes the list.* Media Stream Acceptance: An answerer can reject an m-line by setting its port to 0. It cannot introduce new m-lines not present in the Offer.* Attributes: Certain attributes are negotiated, while others are simply declared. For example, sendrecv determines the media direction. If an offer is sendrecv but the answer is recvonly, the session will be recvonly.* Renegotiation (Re-INVITE/UPDATE): Once a session is established, conditions might change. A user might want to add video, put a call on hold, or change codecs. This is handled by sending a new Offer, typically via a SIP re-INVITE or UPDATE message. The process repeats, with the receiving end sending a new Answer.* Hold/Resume: To put a call on hold, an endpoint sends a new Offer with the media direction attribute changed to sendonly (if it wants to send comfort noise but not receive) or inactive (to fully stop media). To resume, it sends another Offer, changing it back to sendrecv.* Early Media: In SIP, early media (e.g., ringback tones or announcements before a call is answered) can also involve SDP. A 183 Session Progress response might contain an SDP Offer, allowing media setup before the final 200 OK.Let's trace a simple audio-only call setup using SIP and SDP.Scenario: User A calls User B.mermaidsequenceDiagram participant User A participant Proxy Server participant User B User A->>Proxy Server: SIP INVITE (SDP Offer) Note over Proxy Server: Routes INVITE Proxy Server->>User B: SIP INVITE (SDP Offer) Note over User B: Processes Offer, selects codec User B->>Proxy Server: SIP 200 OK (SDP Answer) Note over Proxy Server: Routes 200 OK Proxy Server->>User A: SIP 200 OK (SDP Answer) User A->>User B: RTP Audio Stream User B->>User A: RTP Audio StreamExample
SDP Offer (from User A in a SIP INVITE):v =0o=Alice 2890844526 2890844526 IN IP4 192.168.1.100s=SIP Callc=IN IP4 192.168.1.100t=0 0m=audio 5004 RTP/AVP 0 8 101a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=sendrecvExplanation
of Offer:* v=0: SDP version.* o=Alice...: Originator (Alice), session ID, version, network type, address type, connection address.* s=SIP Call: Session name.* c=IN IP4 192.168.1.100: Connection information - media will come from 192.168.1.100.* t=0 0: Session active indefinitely.* m=audio 5004 RTP/AVP 0 8 101: Audio media stream. Port 5004 will be used. Protocols RTP/AVP. Codec preferences: 0 (PCMU), 8 (PCMA), 101 (DTMF events).* a=rtpmap:...: Maps payload types to codec names and clock rates.* a=sendrecv: User A wants to send and receive audio.Example SDP Answer (from User B in a SIP 200 OK):v =0o=Bob 2890844527 2890844527 IN IP4 192.168.1.101s=SIP Callc=IN IP4 192.168.1.101t=0 0m=audio 6000 RTP/AVP 8 101a=rtpmap:8 PCMA/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=sendrecvExplanation
of Answer:* User B provides its own o= and c= information (192.168.1.101).* m=audio 6000 RTP/AVP 8 101: User B has chosen port 6000 and selected PCMA (payload type 8) as the primary codec, also supporting DTMF events. It only lists codecs it supports from the offer (8 and 101 were in the offer).* a=sendrecv: User B also wants to send and receive.After this exchange, both parties know they will send/receive PCMA audio between 192.168.1.100:5004 and 192.168.1.101:6000.Negotiation failures in the SDP Offer/Answer model are common and can be tricky to debug. Here are some typical issues:* Mismatched Codecs: The most frequent problem. If the offerer only proposes G.711 PCMU and the answerer only supports G.729, no common codec can be found, leading to no media or a 488 Not Acceptable Here SIP error.* Incorrect IP Addresses in c= lines: Especially in NAT environments, if the c= line contains a private IP address that is not reachable by the other party, media will fail. STUN/TURN servers are crucial here for discovering public IPs.* Firewall Blocks: Even with correct SDP, firewalls blocking the RTP/RTCP ports (m= lines) can prevent media flow.* Invalid SDP Syntax: Malformed SDP messages can cause parsing errors, leading to negotiation failures.* Missing or Conflicting Attributes: Missing a=rtpmap for a listed payload type, or conflicting sendonly/recvonly declarations without proper renegotiation, can break media direction.* m-line Port 0 for an Accepted Stream: Sometimes an answerer sets a port to 0 unintentionally, effectively rejecting a media stream that should have been accepted.To deepen your understanding of these concepts, explore:* What is SDP? for a foundational overview of the Session Description Protocol.* SDP Lines Explained to dive into the meaning of each line in an SDP message.* SIP INVITE Explained to see how SDP fits into the broader SIP call flow.