Have you ever wondered how a video call connects? How your phone and the person you’re calling instantly agree on the right settings to see and hear each other? Behind the seamless experience of modern real-time communication lies a quiet, foundational technology: the Session Description Protocol, or SDP.
While it’s called a “protocol,” SDP doesn’t actually transport any audio or video. Instead, its job is to describe the “what, where, and how” of a multimedia session. Think of it as a blueprint or a contract for communication, laying out all the necessary details for two devices to establish a connection.
What’s Inside an SDP “Blueprint”?
At its heart, an SDP message is a simple block of text. It’s made up of a series of lines in a <type>=<value> format, which makes it surprisingly human-readable and easy for developers to work with.
This blueprint is organized into a clear hierarchy:
- Session-Level Details: This first part of the message contains information that applies to the entire call. This includes a mandatory protocol version (
v=0) , information about who started the session (o=), a session name (s=), and the timing of the call (t=). - Media-Level Details: Each type of media in the call—like audio or video—gets its own section, starting with an
m=line. This line specifies the media type (e.g., audio), the network port to use, the transport protocol (like RTP), and a list of proposed codecs.
The real power of SDP comes from its attribute lines (a=). These optional lines extend SDP’s functionality to handle the complexities of modern communication. For example, the a=rtpmap attribute is essential, as it maps a numeric codec ID to its technical name, like linking payload “0” to the popular “PCMU/8000” audio codec. Other attributes define whether a stream is for sending, receiving, or both (a=sendrecv) , and others provide the critical information needed for security and network traversal in WebRTC.
The Negotiation: The Offer/Answer Model
So, how do two devices use this blueprint to agree on call settings? They use a simple but powerful handshake called the Offer/Answer model.
- The Offer: The person initiating the call (the “offerer”) sends an SDP message in a SIP INVITE. This “offer” lists all the possible settings the offerer can support—for instance, “I can handle audio codecs A, B, and C.”
- The Answer: The recipient (the “answerer”) looks at the offer and constructs an SDP “answer.” This answer contains a compatible subset of the offer’s parameters. For example, the answer might say, “Of the codecs you offered, I also support A and C. Let’s use A.” The answer also includes the recipient’s IP address and port for receiving media, completing the setup for a two-way conversation.
This simple exchange ensures both parties have a shared, agreed-upon “contract” for the session before any media starts flowing. If no common ground can be found (for example, no shared codecs), the session simply fails to connect.
Why SDP Still Matters: From VoIP to WebRTC
Originally designed for multicast session announcements, SDP’s flexibility has made it a cornerstone of modern communication technologies.
- VoIP and SIP: SDP is most famously used with the Session Initiation Protocol (SIP) to set up Voice over IP calls. The SDP offer and answer are carried directly within SIP messages to negotiate the call parameters.
- WebRTC: SDP is also at the heart of WebRTC, the technology that enables real-time audio and video communication directly in web browsers. While WebRTC doesn’t mandate a specific signaling protocol, it relies on SDP as the descriptive language for session negotiation. Modern SDP for WebRTC is packed with attributes that handle advanced features like NAT traversal (
a=ice-ufrag) and securing media streams (a=fingerprint).
A Quick Clarification: Not That SDP
It’s important not to confuse the Session Description Protocol with a newer technology that shares the same acronym: the Software-Defined Perimeter.
- Session Description Protocol is a format for setting up multimedia calls.
- Software-Defined Perimeter is a security architecture for controlling network access, based on a “Zero Trust” model.
The shared acronym is purely a coincidence.
An Enduring Legacy
The Session Description Protocol is a perfect example of a design philosophy that prioritizes simplicity and extensibility. By focusing strictly on describing session parameters and leaving the negotiation logic to other protocols, SDP has remained a versatile and indispensable tool. Its simple attribute system (a=) has allowed it to evolve, incorporating the needs of complex modern protocols like ICE and DTLS.
So, the next time you join a video meeting or make a VoIP call, remember the elegant, text-based contract being negotiated in the background. That’s SDP at work, the enduring and essential language of internet communication.