SDP: Session Description Protocol
obsoleted by
- rfc-4566 — SDP: Session Description Protocol
updated by
- rfc-3266 — Support for IPv6 in Session Description Protocol (SDP)
Extracted elements (28)
SDP is explicitly not intended for negotiation of session content or media encodings; it is a description-only format. Negotiation is viewed as outside the scope of session description and is left to signalling protocols such as SIP that transport SDP.
SDP uses a fully textual format (ISO 10646 UTF-8) rather than a binary encoding such as ASN.1 or XDR to enhance portability, enable diverse transports (e.g., MIME email), and allow flexible text-based toolkits. The compact encoding and strict field ordering enable rapid detection and discarding of malformed or encrypted announcements.
The 'a=' attribute mechanism is the primary extension point for SDP rather than new type letters, because the type-letter namespace is deliberately small and non-extensible. An unknown type letter causes the entire announcement to be discarded, whereas unknown attributes are silently ignored, making attributes far safer for optional extensions.
Transport protocol is specified separately from media format because the same standard media formats may be carried over different protocols—a historical example is vat PCM audio versus RTP PCM audio. This separation also enables transport-protocol-specific but format-independent tools such as relays and monitoring tools.
For email and WWW distribution of SDP session descriptions, the MIME content type 'application/sdp' should be used to enable automatic launching of multimedia client applications. SAP announcements do not suffer the scoping mismatch that email/WWW announcements have for restricted-scope multicast sessions.
Session-level 'c=' and 'a=' values apply to all media streams unless overridden by per-media 'c=' fields or same-named attributes in the media description. Attribute values are NOT normally affected by the 'charset' attribute unless the attribute definition explicitly states it is charset-dependent.
When a list of payload formats is given in an 'm=' field, all formats may be used in the session but the first is the default format. For RTP, the encoding names in the Audio/Video Profile do not specify unique encodings (clock rate, channel count), so rtpmap attributes or static payload type numbers must be used instead.
A local IP address MUST NOT be used in any context where the SDP description might leave the scope in which the address is meaningful. The fully-qualified domain name SHOULD be used for the 'o=' address unless unavailable, in which case the globally unique address may be substituted.
A session description must contain either an email or phone field. A 'c=' (connection) field must be present in every media description or at session-level. There must be exactly one 's=' field per session description, and it must contain ISO 10646 characters.
All applications MUST be able to cope with receiving both FQDN and dotted-decimal IP address formats in connection fields. For unicast streams through a NAT, use of FQDN rather than a unicast IP address is RECOMMENDED. The slash notation for multiple addresses is illegal for IP unicast addresses.
Multicast TTL values in the connection field must be in the range 0-255. Multiple 'c=' lines or the slash notation for multiple addresses can only be specified on a per-media basis, not for a session-level 'c=' field. It is illegal to specify both multiple addresses in 'c=' and multiple ports in 'm=' within the same media description.
SDP parsers MUST completely ignore any announcement that contains a type letter they do not understand. Unrecognised attributes must also be ignored. This strict ignore-unknown policy enables forward compatibility without breaking deployed implementations.
The 'a=charset' value MUST be one of those registered with IANA and MUST be compared against IANA identifiers using case-insensitive comparison. Any character set used MUST still prohibit bytes 0x00, 0x0A, and 0x0D; character sets requiring these MUST define a quoting mechanism. If the identifier is unrecognised, affected strings SHOULD be treated as byte strings.
To register a new transport protocol name, an RFC MUST be produced describing the protocol. New bandwidth specifiers MUST reference a standards-track RFC explaining why existing specifiers do not suffice. New nettype registrations MUST reference an RFC giving network and address type details and MUST include at least one address type registration.
When SDP is conveyed by SAP, only one session description is allowed per packet. The SDP text payload should be no greater than 1 Kbyte in length. When conveyed by other means, multiple SDP session descriptions may be concatenated, with 'v=' indicating the start of each new description.
An SDP session description has a fixed field order: session-level (v, o, s, i, u, e, p, c, b, one-or-more t/r, z, k, a) followed by zero or more media-level sections (m, i, c, b, k, a). All fields must appear in exactly this order; optional items are marked with '*'. Session-level values are defaults for all media unless overridden.
The 'a=rtpmap:<payload-type> <encoding-name>/<clock-rate>[/<encoding-params>]' attribute dynamically binds RTP payload type numbers to media encodings, required for dynamic payload types. Up to one rtpmap attribute per format; audio channels may be given as encoding-params. Experimental encoding names must be prefixed with 'X-'.
The encryption key field 'k=' supports four methods: 'clear:<key>' (key in plaintext), 'base64:<key>' (base64-encoded key for characters prohibited in SDP), 'uri:<URI>' (key fetched from URI on demand to reduce server synchronisation), and 'prompt' (user prompted at join time). A 'k=' field may appear at session level or per media description.
Appendix B defines IANA registration procedures for seven SDP name spaces: 'media' (top-level MIME content types), 'proto' (transport protocols; new proprietary protocols require an RFC), 'fmt' (format names, context-dependent on proto), 'att-field' (attribute names; registration optional), 'bwtype' (bandwidth modifiers; requires standards-track RFC), 'nettype' (network types; requires RFC), and 'addrtype' (address types; requires RFC). Currently defined: nettype 'IN', addrtype 'IP4'/'IP6', proto 'RTP/AVP'/'udp', bwtype 'CT'/'AS'.
A session description should not be trusted unless obtained by an authenticated transport from a trusted source. SAP provides encryption and authentication, but anonymous originators are common in open multicast environments because no universal PKI exists for session announcement senders.
It is INAPPROPRIATE for a firewall to open holes for unicast data streams based on SDP descriptions unless the description comes from inside the firewall. For multicast, restricting 'local' or 'site-local' scope within the firewall and refusing to pass such scopes provides separation between global and local multicast sessions.
Software parsing an SDP description MUST NOT be able to start software other than what is specifically configured for multimedia session participation. A session description arriving by announcement, email, invitation, or WWW SHOULD NOT deliver the user into an interactive multimedia session without the user first being informed and giving consent.
Every SDP line has the form '<type>=<value>' where type is exactly one case-significant character and value is a structured text string. Whitespace is not permitted either side of '='. Records are terminated by CRLF (0x0d0a); parsers should also accept a single newline. Text byte strings may contain any byte except 0x00 (Nul), 0x0a (LF), and 0x0d (CR).
The bandwidth field 'b=<modifier>:<bandwidth-value>' expresses bandwidth in kilobits per second. Standard modifiers are CT (Conference Total, summed across all sites and media) and AS (Application-Specific Maximum, for a single media at a single site). Experimental modifiers use 'X-' prefix; parsers ignore unknown modifiers.
The connection field 'c=<nettype> <addrtype> <connection-address>' specifies the destination address. For IP4 multicast, a TTL value is appended with '/' (e.g., '224.2.1.1/127'). Layered encodings using multiple contiguous multicast groups extend this to '<base-address>/<ttl>/<number-of-addresses>' (e.g., '224.2.1.1/127/3').
The media field 'm=<media> <port> <transport> <fmt-list>' specifies media type ('audio', 'video', 'application', 'data', 'control'), transport port (1024-65535 for UDP; even for RTP compliance), transport protocol ('RTP/AVP', 'udp'), and one or more format tokens. Multiple ports for layered streams use 'm=<media> <port>/<num-ports> <transport> <fmt-list>'.
The origin field 'o=<username> <session-id> <version> <nettype> <addrtype> <address>' identifies the session originator. The tuple (username, session-id, nettype, addrtype, address) forms a globally unique session identifier; version must be increased on each modification. NTP timestamps are recommended for both session-id and version.
The time field 't=<start-time> <stop-time>' uses decimal NTP timestamp values in seconds (subtract 2208988800 for UNIX time). A stop-time of zero means unbounded; both zero means permanent. Repeat times use 'r=<interval> <duration> <offset-list>' with optional unit suffixes d/h/m/s. Time zone adjustments use 'z=<ntp-time> <offset> ...'.