Generated by GPT-5-mini| Session Description Protocol | |
|---|---|
| Name | Session Description Protocol |
| Acronym | SDP |
| Developer | Internet Engineering Task Force |
| First pub | 1998 |
| Status | Internet Standard |
| Domain | Multimedia |
Session Description Protocol
Session Description Protocol is a format for describing multimedia communication sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. It specifies a textual representation of session metadata, media formats, transport addresses, and connection information used by signaling systems and media frameworks. SDP is commonly associated with real-time communication stacks and integrates with signaling protocols and codecs to enable interoperability among implementations.
SDP provides a standardized description language used by Internet Engineering Task Force, Internet Protocol, Real-time Transport Protocol, User Datagram Protocol, Transmission Control Protocol, Media Gateway Control Protocol, and Session Initiation Protocol-based systems to convey session parameters. It encodes session-level attributes such as version, origin, session name, timing, and connection information alongside media-level attributes like media type, port, protocol, and codec mappings. SDP itself is not a transport protocol; instead, it is carried by mechanisms including Session Initiation Protocol, Real Time Streaming Protocol, Hypertext Transfer Protocol, Email, and Session Announcement Protocol to negotiate media sessions between endpoints. Major standards bodies and implementations reference SDP in conjunction with codec specifications such as H.264, Opus, G.711, and VP8.
SDP originated from work within the Internet Engineering Task Force in the mid-1990s to address interoperability for multimedia conferencing and streaming. Early design and publication involved contributors associated with Carnegie Mellon University, Columbia University, and corporate laboratories of Bell Labs and Microsoft. The original specification was published as an informational RFC and subsequently updated through standards progression in response to evolving requirements from projects like SIP Forum, 3rd Generation Partnership Project, and the Internet Multimedia Subsystem. Over time, extensions and updates were driven by developments in codecs, NAT traversal efforts involving Network Address Translation vendors, and security concerns raised by organizations such as IETF Security Area working groups.
SDP messages are line-oriented, using single-character field identifiers followed by '=' and structured values, enabling parsers to extract session attributes such as version ("v="), origin ("o="), session name ("s="), connection ("c="), and media descriptions ("m="). Media descriptions include media type tokens referencing entities like RTP, payload type numbers that map to codecs specified in documents from International Telecommunication Union, and format parameters often described using attributes ("a="). Attributes can reference codec-specific parameters from standards bodies such as 3GPP, signaling frameworks like SIP, or codec registries maintained by IANA. SDP supports session timing lines referencing calendaring or scheduling use cases similar to mechanisms used by Simple Network Management Protocol agents for synchronization information. The syntax is deliberately extensible: new attribute names, direction indications, and grouping semantics allow integration with frameworks such as Interactive Connectivity Establishment and DTLS-based keying material.
SDP is used in a range of real-time applications, including conferencing systems by vendors like Cisco Systems, streaming platforms employed by Akamai Technologies, and telephony services provided by carriers adhering to 3GPP specifications. It appears in browser-based communication via WebRTC to negotiate media parameters between peers, and in enterprise unified communications that combine services from Avaya and Microsoft Teams. SDP also serves announcement roles in multicast deployments using infrastructure from Internet2 and in broadcast workflows involving Broadcast Television studios integrating with IP-based production systems. In addition, SDP is used for capability negotiation in Internet-of-Things deployments standardized by organizations such as OASIS when low-latency media exchange is required.
Because SDP often conveys IP addresses, port numbers, and codec capabilities, it can reveal network topology and media endpoint information to observers such as network operators, security researchers, or adversaries. Mitigations developed by working groups including IETF security subgroups and industry consortia recommend use of transport-layer protections like Transport Layer Security, media protection with SRTP and DTLS-SRTP, and middlebox-aware mechanisms from RFC 3261-related deployments. Privacy extensions and best practices include anonymization of origin fields, use of ICE relays via Traversal Using Relays around NAT services operated by providers including Twilio or Google, and token-based authorization models endorsed by OAuth adopters. Threat models considered by standards bodies address eavesdropping, endpoint impersonation, and denial-of-service mitigations tied to resource reservation in SIP proxies and media servers.
SDP is implemented in open-source projects such as Asterisk, FreeSWITCH, Jitsi, GStreamer, FFmpeg, and browser engines from Google and Mozilla Foundation for WebRTC support. Commercial implementations appear in products from Polycom, Cisco Systems, Avaya, and cloud offerings by Amazon Web Services and Microsoft Azure that expose media gateways and conferencing services. Interoperability testing is coordinated by industry groups like SIP Forum and events including plugfests organized by IETF and vendor ecosystems; these efforts address differences in codec negotiation, session timers, and handling of attributes defined by standards from ITU-T and 3GPP.
SDP has numerous extensions and companion protocols that expand capabilities: attribute frameworks for directional controls used by WebRTC; grouping semantics from RFC 5888 for simulcast and redundancy used in live-streaming scenarios; and integration with NAT traversal protocols such as Interactive Connectivity Establishment and TURN. Related protocols include Session Initiation Protocol for signaling, Real-time Transport Protocol for media transport, and RTSP for on-demand streaming. Work on successor approaches and adjunct formats has been pursued in venues such as IETF AVTCORE and IETF RTCWEB to address multiplexing, security, and multiplexing challenges encountered in modern multimedia ecosystems.
Category:Internet protocols