SDP: Session Description Protocol
Extracted elements (30)
SDP uses a textual encoding (rather than binary formats such as ASN.1 or XDR) to enhance portability and enable use with a variety of transports and text-based toolkits. The encoding is deliberately compact because session descriptions may be size-limited, and the strict field ordering aids rapid error detection and discarding of malformed or undecryptable announcements.
The `k=` encryption key field is retained only for backward compatibility with older implementations. New applications SHOULD use dedicated key exchange mechanisms (e.g., those being standardised at the time of RFC 4566), because `k=` cannot negotiate key algorithms, carries only a single symmetric key, and provides no integrity protection.
The set of SDP type letters (`v=`, `o=`, etc.) is intentionally small and non-extensible; an unknown type letter causes the entire session description to be discarded. Extensibility is delegated entirely to the `a=` attribute mechanism to avoid fragmenting the core format.
SDP is purely a session description format and deliberately does not incorporate a transport protocol or support media negotiation. It is designed for use with SAP, SIP, RTSP, email (MIME), and HTTP, each of which supplies its own transport security and authentication properties that SDP itself cannot provide.
A session description MUST contain either at least one `c=` field in each media description or a single session-level `c=` field. Per-media `c=` fields override the session-level value for that media.
An SDP parser MUST completely ignore any session description that contains a type letter it does not understand. This ensures forward compatibility as new type letters are not added without discarding unknown ones.
An SDP parser MUST ignore any attribute (`a=` field) it does not understand. Attributes are the primary extensibility mechanism; unknown ones are silently discarded to ensure interoperability.
Attribute field names MUST be registered with IANA because conflicting attributes under the same name are a serious protocol fragmentation problem. New registrations require a specification meeting the "Specification Required" policy.
For RTP/AVP and RTP/SAVP media, the `<fmt>` sub-field MUST contain RTP payload type numbers. When a dynamic payload type is used, an `a=rtpmap:` attribute MUST be included to map the payload type number to a media encoding name.
Internationalised domain names (IDNs) used in SDP MUST be represented in ASCII Compatible Encoding (ACE) form and MUST NOT be directly represented in UTF-8 or any other encoding, for compatibility with RFC 2327 and other SDP-related standards.
Sessions using an IPv4 multicast connection address MUST include a TTL value (range 0–255) appended to the address. IPv6 multicast MUST NOT include a TTL; IPv6 scoped addresses are expected to limit conference scope instead.
Software parsing a session description MUST NOT be able to start software other than that specifically configured as appropriate for participating in multimedia sessions. A session arriving by announcement or invitation MUST NOT deliver the user into an interactive session without explicit prior consent.
The `k=` (encryption key) field MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure and trusted channel, such as SDP inside an S/MIME message or a TLS-protected HTTP session.
There MUST be exactly one `s=` field per session description and it MUST NOT be empty. If a session has no meaningful name, the value SHOULD be a single space (`s= `).
When non-contiguous RTP/RTCP ports are used or when ports do not follow the even-RTP/odd-RTCP parity rule, the `a=rtcp:` attribute MUST be used. Applications receiving RTP to an odd port with `a=rtcp:` present MUST NOT subtract 1 from the RTP port.
The `a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]` attribute maps dynamic RTP payload type numbers to encoding names, clock rates, and optional parameters (e.g., channel count for audio). At most one rtpmap may be defined per media format.
The attribute mechanism (`a=<attribute>` or `a=<attribute>:<value>`) is the primary means for extending SDP. Attributes may be property attributes (flags) or value attributes. Session-level attributes apply to all media unless overridden by a media-level attribute of the same name.
The bandwidth field (`b=<bwtype>:<bandwidth>`) specifies proposed bandwidth in kilobits per second. `CT` gives the conference total across all sites and sessions; `AS` gives application-specific bandwidth for a single media at a single site. The `X-` prefix is reserved for experimental use but NOT RECOMMENDED.
The directional attributes `a=sendrecv`, `a=sendonly`, `a=recvonly`, and `a=inactive` control media stream direction. If none is present, `sendrecv` is the default for non-broadcast/H332 sessions. RTP-based systems in recvonly or inactive mode SHOULD still send RTCP.
RFC 4566 registers or updates seven IANA namespaces for SDP: media types (`audio`, `video`, `text`, `application`, `message`), transport protocols (`RTP/AVP`, `RTP/SAVP`, `udp`), media formats (`fmt`), attribute names (`att-field`), bandwidth specifiers (`CT`, `AS`), network types (`IN`), and address types (`IP4`, `IP6`).
The `application/sdp` MIME type is registered. SDP files are primarily UTF-8 text; the `a=charset:` attribute may signal other character sets. The file extension `.sdp` is commonly used.
Entities receiving SDP SHOULD be aware that a session description cannot be trusted unless obtained via an authenticated transport from a known and trusted source. Untrusted SDP may specify wrong media destinations, incorrect parameters, or compromised media security; endpoints should exercise care and may need user confirmation.
Intermediary systems (e.g., firewalls, NAT boxes) that intercept and modify SDP are NOT RECOMMENDED unless they can establish the authenticity of the session description and the authority of its source. SDP alone does not carry sufficient information for these checks; the encapsulating protocol (SIP, RTSP) must provide them.
Use of the `k=` field poses a significant security risk since it conveys session encryption keys in the clear. It also provides no way to indicate key algorithms and supports only a single symmetric key (not separate confidentiality and integrity keys). Its use is NOT RECOMMENDED.
An SDP session description consists of an ordered session-level section (beginning with `v=`) followed by zero or more media-level sections (each beginning with `m=`). All lines MUST appear in exactly the prescribed order; this strict ordering enables simple parsers and easy error detection.
Each SDP line has the form `<type>=<value>` where `<type>` MUST be exactly one case-significant character and whitespace MUST NOT appear on either side of the `=` sign. Lines are terminated by CRLF, though parsers SHOULD also accept a single newline.
The connection field has the form `c=<nettype> <addrtype> <connection-address>`. For IPv4 multicast, TTL is appended with a slash (e.g., `c=IN IP4 224.2.36.42/127`); for layered multicast an address count may also be appended (e.g., `c=IN IP4 224.2.1.1/127/3`).
The media field has the form `m=<media> <port> <proto> <fmt> ...`. For hierarchically encoded streams, a port count may be given as `<port>/<number of ports>`. RTP sessions use even ports for data and the next odd port for RTCP.
The origin field has the form `o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>`. The tuple of username, sess-id, nettype, addrtype, and unicast-address forms a globally unique session identifier; sess-version MUST increase on each modification.
Timing fields use decimal NTP timestamps (seconds since 1900). The `t=<start-time> <stop-time>` field specifies session activity bounds; a stop-time of zero means unbounded. The `r=` field encodes repeat intervals using compact time units (d, h, m, s).