RFC 8866
SDP: Session Description Protocol
SDP: Session Description Protocol 🎀
Okay bestie, this is RFC 8866, and it's the spec for SDP, the Session Description Protocol 💖. It's an IETF Standards Track document from January 2021, with ISSN 2070-1721. The authors are A. Begen (Networked Media), P. Kyzivat, C. Perkins (University of Glasgow), and M. Handley (UCL). It obsoletes RFC 4566 and doesn't update anything else 🦋.
Abstract ✨
Here's the vibe: this memo defines SDP 💅. It's made for describing multimedia sessions so you can announce them, invite people to them, and start them up in other ways too. This document obsoletes RFC 4566, so that older version is out now 🫶.
Status of This Memo 🌸
This is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF), so it has the IETF community's consensus behind it. It got public review and the Internet Engineering Steering Group (IESG) approved it for publication 👑. If you want more on Internet Standards, check out Section 2 of RFC 7841 🧚.
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8866 💜.
Copyright Notice 🌈
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved 🔒.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they stood on the publication date. Read those carefully, because they spell out your rights and restrictions for this document 📜. Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, also as described in the Simplified BSD License 🙈.
This document might include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 💀. Unless you get an adequate license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works of it can't be made outside that process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🍓.
Table of Contents 🧚
1. Introduction
2. Glossary of Terms
3. Examples of SDP Usage
3.1. Session Initiation
3.2. Streaming Media
3.3. Email and the World Wide Web
3.4. Multicast Session Announcement
4. Requirements and Recommendations
4.1. Media and Transport Information
4.2. Timing Information
4.3. Obtaining Further Information about a Session
4.4. Internationalization
5. SDP Specification
5.1. Protocol Version ("v=")
5.2. Origin ("o=")
5.3. Session Name ("s=")
5.4. Session Information ("i=")
5.5. URI ("u=")
5.6. Email Address and Phone Number ("e=" and "p=")
5.7. Connection Information ("c=")
5.8. Bandwidth Information ("b=")
5.9. Time Active ("t=")
5.10. Repeat Times ("r=")
5.11. Time Zone Adjustment ("z=")
5.12. Encryption Keys ("k=")
5.13. Attributes ("a=")
5.14. Media Descriptions ("m=")
6. SDP Attributes
6.1. cat (Category)
6.2. keywds (Keywords)
6.3. tool
6.4. ptime (Packet Time)
6.5. maxptime (Maximum Packet Time)
6.6. rtpmap
6.7. Media Direction Attributes
6.7.1. recvonly (Receive-Only)
6.7.2. sendrecv (Send-Receive)
6.7.3. sendonly (Send-Only)
6.7.4. inactive
6.8. orient (Orientation)
6.9. type (Conference Type)
6.10. charset (Character Set)
6.11. sdplang (SDP Language)
6.12. lang (Language)
6.13. framerate (Frame Rate)
6.14. quality
6.15. fmtp (Format Parameters)
7. Security Considerations
8. IANA Considerations
8.1. The "application/sdp" Media Type
8.2. Registration of SDP Parameters with IANA
8.2.1. Registration Procedure
8.2.2. Media Types (<media>)
8.2.3. Transport Protocols (<proto>)
8.2.4. Attribute Names (<attribute-name>)
8.2.5. Bandwidth Specifiers (<bwtype>)
8.2.6. Network Types (<nettype>)
8.2.7. Address Types (<addrtype>)
8.3. Encryption Key Access Methods (OBSOLETE)
9. SDP Grammar
10. Summary of Changes from RFC 4566
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🦋
Okay so, when you're setting up multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, you need to get media details, transport addresses, and other session metadata to everyone involved 💖.
SDP gives you one standard way to represent all that, no matter how the info gets transported 🫶. SDP is purely a format for session description. It doesn't include a transport protocol. It's meant to work with different transport protocols depending on what you need, like the Session Announcement Protocol (SAP) [RFC2974], the Session Initiation Protocol (SIP) [RFC3261], the Real-Time Streaming Protocol (RTSP) [RFC7826], electronic mail [RFC5322] using the MIME extensions [RFC2045], and the Hypertext Transport Protocol (HTTP) [RFC7230] ✨.
SDP is meant to be general purpose, so it fits all kinds of network environments and apps 🌸. But it's not meant to negotiate session content or media encodings. That's considered outside the scope of session description 🙈.
This memo obsoletes [RFC4566]. You can find the changes from [RFC4566] in Section 10 of this memo 💅.
2. Glossary of Terms 💜
The following terms are used in this document, and they have specific meanings inside it 📖.
Session Description: A well-defined format for conveying enough information to discover a multimedia session and take part in it 🎀.
Media Description: A Media Description has the information one party needs to set up an application-layer network protocol connection to another party. It starts with an "m=" line and ends at either the next "m=" line or the end of the session description 🦋.
Session-Level Section: This is the part that isn't a media description. The session description is the whole body, which includes the session-level section and the media description(s) 🌈.
The terms "multimedia conference" and "multimedia session" are used here as defined in [RFC7656]. "Session" and "multimedia session" are used interchangeably in this document ⭐.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 👑.
3. Examples of SDP Usage 🧚
3.1. Session Initiation 📞
The Session Initiation Protocol (SIP) [RFC3261] is an application-layer control protocol. It creates, modifies, and terminates sessions like Internet multimedia conferences, Internet telephone calls, and multimedia distribution 💖. SIP messages that create sessions carry session descriptions, which let participants agree on a set of compatible media types [RFC6838]. These session descriptions are usually formatted with SDP. When SIP is used, the offer/answer model [RFC3264] gives you a limited framework for negotiating with SDP 🫶.
3.2. Streaming Media 🎬
The Real-Time Streaming Protocol (RTSP) [RFC7826], is an application-level protocol for controlling the delivery of data that has real-time properties ✨. RTSP gives you an extensible framework for controlled, on-demand delivery of real-time data like audio and video 🌸. An RTSP client and server negotiate a suitable set of parameters for media delivery, and they partly use SDP syntax to describe those parameters 🔥.
3.3. Email and the World Wide Web 💌
There are other ways to convey session descriptions too, like electronic mail and the World Wide Web (WWW) 🌍. For both email and WWW distribution, the media type application/sdp is used. That lets the WWW client or mail reader automatically launch applications to join the session, in a standard way 🦋.
Heads up, though: just because you get a multicast session description through email or the WWW doesn't mean you can actually receive the session 🙈. Multicast sessions might be restricted in scope, and access to the WWW server or receiving email might be outside that scope 💀.
3.4. Multicast Session Announcement 📢
To help advertise multicast multimedia conferences and other multicast sessions, and to share the setup info with people who might want to join, you can use a distributed session directory 🍓. An instance of this directory keeps sending packets with a description of the session to a well-known multicast group. Other session directories pick up those announcements, so potential remote participants can use the session description to start the tools they need to join 🧚.
One protocol for building a distributed directory like this is SAP [RFC2974]. SDP gives you the session description format that's the go-to choice for these session announcements 👑✨
4. Requirements and Recommendations ✨
okay bestie, this section is the "why do we even have SDP" part and it is SO important 💖 SDP is mainly for Internet protocols, but it's general enough to describe multimedia conferences in other network environments too 🌈 Media streams can be many-to-many, and sessions don't have to be running all the time 🦋
So like, multicast sessions on the Internet have always been kinda different from other conferencing stuff, because anyone receiving the traffic can join (unless the traffic is encrypted) 👀 In that world SDP does two jobs 💅 First, it tells people that a session exists. Second, it gives them enough info to actually join and take part. In a unicast setup, only the second job really matters 🎀
An SDP description includes:
- Session name and purpose 🌸
- Time(s) the session is active ⏰
- The media in the session 🎬
- Info needed to receive that media (addresses, ports, formats, etc.) 📡
Resources can be limited, so some extra stuff is also nice to have 💜
- Info about the bandwidth the session will use 📶
- Contact info for the person in charge of the session 🫶
Generally, SDP MUST give apps enough info to join a session (the one maybe-exception is encryption keys 🔐) and to announce the resources being used to anyone who might need to know, even if they aren't participating. (This last bit is mostly useful when SDP is paired with a multicast session announcement protocol 📣)
4.1. Media and Transport Information 🎧
An SDP description includes this media info:
- The type of media (video, audio, etc.) 🎥
- The media transport protocol (RTP/UDP/IP, H.320, etc.) 🚚
- The format of the media (H.261 video, MPEG video, etc.) 🍓
Besides format and transport protocol, SDP also carries address and port details. For an IP multicast session, that's:
- The multicast group address for media 📍
- The transport port for media 🚪
This address and port are the destination address and destination port of the multicast stream, whether you're sending, receiving, or both 🙌
For unicast IP sessions, you get:
- The remote address for media 📍
- The remote transport port for media 🚪
What the address and port mean depends on context 🤔 Typically, this SHOULD be the remote address and remote port that media is sent to or received from. The details can shift based on network type, address type, protocol, and media, and on whether the SDP is being sent out as an advertisement or negotiated in an offer/answer [RFC3264] exchange. (Like, some address types or protocols don't even have a concept of port 💀) Going off the typical path should be done carefully, because it makes life harder for implementations, including middleboxes that have to parse the addresses to open Network Address Translation (NAT) or firewall pinholes 🙈
4.2. Timing Information ⏰
Sessions can be bounded or unbounded in time. Either way, they might only be active at certain times. SDP can convey:
- An arbitrary list of start and stop times bounding the session 🗓️
- For each bound, repeat times such as "every Wednesday at 10am for one hour" 🔁
This timing info is globally consistent, no matter your local time zone or daylight saving time (see Section 5.9) 🌍✨
4.3. Obtaining Further Information about a Session 🔎
A session description can give you enough info to decide whether to join a session 🤷♀️ SDP may include extra pointers in the form of Uniform Resource Identifiers (URIs) [RFC3986] for more info about the session. (Heads up: using URIs to point at remote resources is subject to the security considerations from [RFC3986] 🚨)
4.4. Internationalization 🌏
The SDP spec recommends using the ISO 10646 character set in UTF-8 encoding [RFC3629] so lots of languages can be represented 🗣️ For compact representations, SDP also allows other character sets such as [ISO.8859-1.1998] when you want them 🧩 Internationalization only applies to free-text subfields (session name and background information), not to SDP as a whole 💅
5. SDP Specification 📜
An SDP description is denoted by the media type "application/sdp" (See Section 8) 🏷️
An SDP description is entirely textual 📝 SDP field names and attribute names use only the US-ASCII subset of UTF-8 [RFC3629], but textual fields and attribute values MAY use the full ISO 10646 character set in UTF-8 encoding, or some other character set defined by the "a=charset:" attribute (Section 6.10) 🌸 Field and attribute values that use the full UTF-8 character set are never directly compared, so there's no requirement for UTF-8 normalization 🙅♀️ Text format was chosen over binary encodings like ASN.1 or XDR so it's portable, works with lots of transports, and plays nicely with flexible text-based toolkits 🧰 SDP can be used where the maximum size of a description is limited, so the encoding is deliberately compact 🤏 Also, descriptions might travel over very unreliable paths or get damaged by an intermediate caching server, so the encoding has strict order and formatting rules. That way most errors make a malformed description that's easy to spot and throw away 🗑️✨
An SDP description is a bunch of text lines that look like this:
<type>=<value>Here <type> is exactly one case-significant character and <value> is structured text whose format depends on <type>. In general, <value> is either a number of subfields separated by a single space character, or a free format string, and it's case-significant unless a specific field says otherwise 🔠 There's no whitespace on either side of the "=" sign. However, the value can have leading whitespace as part of its syntax, so that whitespace counts as part of the value 👀
An SDP description MUST conform to the syntax defined in Section 9. Here's the overview of the syntax 🗺️
An SDP description has a session-level section followed by zero or more media descriptions. The session-level section starts with a "v=" line and keeps going until the first media description (or the end of the whole description, whichever comes first). Each media description starts with an "m=" line and keeps going until the next media description or the end of the whole session description, whichever comes first. In general, session-level values are the default for all media unless a media-level value overrides them 🔄
Some lines are required and some are optional, but when they're present, they MUST appear in exactly the order given here. (The fixed order makes error detection way better and lets parsers be simple 🧠) In the overview below, optional items are marked with a "*" ⭐
Session description
v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in
all media descriptions)
b=* (zero or more bandwidth information lines)
One or more time descriptions:
("t=", "r=" and "z=" lines; see below)
k=* (obsolete)
a=* (zero or more session attribute lines)
Zero or more media descriptions
Time description
t= (time the session is active)
r=* (zero or more repeat times)
z=* (optional time zone offset line)
Media description, if present
m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at
session level)
b=* (zero or more bandwidth information lines)
k=* (obsolete)
a=* (zero or more media attribute lines)The set of type letters is deliberately small and isn't meant to be extensible. An SDP parser MUST completely ignore or reject any session description that has a type letter it doesn't understand 🚫 The attribute mechanism ("a=", described in Section 5.13) is the main way to extend SDP and tailor it to particular apps or media 🎀 Some attributes (the ones listed in Section 6) have a defined meaning, but others can be added on a media- or session-specific basis. (Attribute scopes beyond media-specific and session-specific may also be defined in extensions to this document, e.g., [RFC5576] and [RFC8864].) An SDP parser MUST ignore any attribute it doesn't understand 🙈
An SDP description may contain URIs that point at external content in the "u=", "k=", and "a=" lines. Sometimes those URIs get dereferenced, which makes the session description not self-contained 🔗
The connection ("c=") info in the session-level section applies to all the media descriptions of that session unless a media description overrides it with its own connection info 💫 For instance, in the example below, each audio media description acts as if it were given a "c=IN IP4 198.51.100.1" 🎶
An example SDP description is:
v=0
o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1
s=Call to John Smith
i=SDP Offer #1
u=http://www.jdoe.example.com/home.html
e=Jane Doe <jane@jdoe.example.com>
p=+1 617 555-6011
c=IN IP4 198.51.100.1
t=0 0
m=audio 49170 RTP/AVP 0
m=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99
c=IN IP6 2001:db8::2
a=rtpmap:99 h263-1998/90000Text-containing fields like the session-name-field and information-field are octet strings that can hold any octet except 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII carriage return) 🧵 The sequence CRLF (0x0d0a) ends a line, although parsers SHOULD be tolerant and also accept lines ending with a single newline character 🫶 If the "a=charset:" attribute isn't present, these octet strings MUST be interpreted as ISO-10646 characters in UTF-8 encoding. When "a=charset:" is present, the session-name-field, information-field, and some attribute fields are interpreted according to the chosen character set 🌈
A session description can contain domain names in the "o=", "u=", "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply with [RFC1034] and [RFC1035]. Internationalized domain names (IDNs) MUST be represented using the ASCII Compatible Encoding (ACE) form defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or any other encoding. (This requirement is for compatibility with [RFC2327] and other early SDP-related standards, which came before internationalized domain names existed 🕰️)
5.1. Protocol Version ("v=") 🔢
v=0The "v=" line (version-field) gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number 💖
5.2. Origin ("o=") 💌
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>Okay so the "o=" line is the session's birth certificate 🎀 It tells you who started the session (their username plus the address of their host), and it carries a session identifier and a version number. Here's the breakdown:
<username>is the user's login on the originating host, or it is-if the originating host doesn't support the concept of user IDs. The<username>MUST NOT contain spaces. No spaces, bestie 🙅♀️<sess-id>is a numeric string that, together with<username>,<nettype>,<addrtype>, and<unicast-address>, forms a globally unique identifier for the session. The creating tool decides how to allocate it, but a timestamp (in seconds since January 1, 1900 UTC) is recommended to keep things unique ✨<sess-version>is the version number for this session description. The creating tool gets to decide how it's used, as long as<sess-version>goes up whenever the session description is modified. Again, just like with<sess-id>, it is RECOMMENDED that a timestamp be used 🕰️<nettype>is a text string giving the type of network. Right now, "IN" is defined to mean "Internet", but other values MAY be registered in the future (see Section 8) 🌐<addrtype>is a text string giving the type of the address that follows. Currently "IP4" and "IP6" are defined, but other values MAY be registered in the future (see Section 8) 🧭<unicast-address>is an address of the machine the session was created from. For "IP4", this is either a fully qualified domain name for the machine or its dotted-decimal representation. For "IP6", it's either a fully qualified domain name or the machine's address written as specified in Section 4 of [RFC5952]. For both "IP4" and "IP6", the fully qualified domain name is the form that SHOULD be given unless it's unavailable, in which case a globally unique address MAY be substituted 💅
In general, the "o=" line works as a globally unique identifier for this version of the session description. The subfields other than the version, taken together, identify the session no matter what modifications happen 🦋
Now for privacy 🙈 Sometimes you don't want the world seeing the originator's username and IP address. If that's a concern, an arbitrary <username> and a private <unicast-address> MAY be chosen to fill the "o=" line, as long as they're picked in a way that doesn't break the global uniqueness of the field 🔒
5.3. Session Name ("s=") 🎬
s=<session name>The "s=" line (session-name-field) is the textual name of the session 🍓 There MUST be one and only one "s=" line per session description. The "s=" line MUST NOT be empty. If a session doesn't have a meaningful name, then s= or s=- (a single space or a dash as the session name) is RECOMMENDED 🫶 If a session-level "a=charset:" attribute is present, it specifies the character set used in the "s=" field. If it's not present, the "s=" field MUST contain ISO 10646 characters in UTF-8 encoding 🌈
5.4. Session Information ("i=") 📝
i=<session information>The "i=" line (information-field) gives textual info about the session ✨ There can be at most one session-level "i=" line per session description, and at most one "i=" line in each media description. Unless a media-level "i=" line is provided, the session-level "i=" line applies to that media description. If the "a=charset:" attribute is present, it specifies the character set used in the "i=" line. If it's not present, the "i=" line MUST contain ISO 10646 characters in UTF-8 encoding 💜
At most one "i=" line can be used for each media description. In media definitions, "i=" lines are mainly there for labelling media streams 🏷️ They're most likely to be useful when one session has more than one distinct media stream of the same media type. Think two different whiteboards, one for slides and one for feedback and questions. Iconic organisation, honestly 👑
The "i=" line is meant to be a free-form, human-readable description of the session or the purpose of a media stream. It is not suitable for parsing by automata 🤖 So don't you dare try to parse it, bestie 💀
5.5. URI ("u=") 🔗
u=<uri>The "u=" line (uri-field) gives a URI (Uniform Resource Identifier) [RFC3986]. The URI should point to more human-readable info about the session 📖 This line is OPTIONAL. No more than one "u=" line is allowed per session description 🌸
5.6. Email Address and Phone Number ("e=" and "p=") 📞
e=<email-address>
p=<phone-number>The "e=" line (email-field) and "p=" line (phone-field) give contact info for the person responsible for the session. That's not necessarily the same person who created the session description, so don't assume 🙃
Including an email address or phone number is OPTIONAL 💖
If an email address or phone number is present, it MUST be specified before the first media description. You can give more than one email or phone line for a session description, which is very main character of you 🎀
Phone numbers SHOULD be given in the form of an international public telecommunication number (see ITU-T Recommendation E.164 [E164]) preceded by a "+". Spaces and hyphens may be used to split up a phone-field to make it easier to read. For example:
p=+1 617 555-6011Both email addresses and phone numbers can have an OPTIONAL free text string attached, usually giving the name of the person you can contact ☎️ This MUST be enclosed in parentheses if it's present. For example:
e=j.doe@example.com (Jane Doe)The alternative [RFC5322] name quoting convention is also allowed for both email addresses and phone numbers. For example:
e=Jane Doe <j.doe@example.com>The free text string SHOULD be in the ISO-10646 character set with UTF-8 encoding. Alternatively, it can be in ISO-8859-1 or other encodings if the right session-level "a=charset:" attribute is set 🌍
5.7. Connection Information ("c=") 🛰️
c=<nettype> <addrtype> <connection-address>The "c=" line (connection-field) holds the info you need to set up a network connection. It's giving everything you need to get connected 🔌
A session description MUST contain either at least one "c=" line in each media description or a single "c=" line at the session level. It MAY contain a single session-level "c=" line plus additional media-level "c=" line(s) per media description. When it does, the media-level values override the session-level settings for that media. Very polite of them, honestly 🫶
The first subfield (<nettype>) is the network type, a text string giving the type of network. Right now, "IN" is defined to mean "Internet", but other values MAY be registered in the future (see Section 8) 🌐
The second subfield (<addrtype>) is the address type. This lets SDP work for sessions that aren't IP based. This memo only defines "IP4" and "IP6", but other values MAY be registered in the future (see Section 8) ✨
The third subfield (<connection-address>) is the connection address. Additional subfields MAY be added after the connection address, depending on the value of the <addrtype> subfield 🧩
When the <addrtype> is "IP4" or "IP6", the connection address works like this:
- If the session is multicast, the connection address will be an IP multicast group address. If the session is not multicast, then the connection address contains the unicast IP address of the expected data source, data relay, or data sink, as determined by additional attribute-fields (Section 5.13). It's not expected that unicast addresses will be given in a session description communicated by a multicast announcement, though this isn't prohibited 📡
- Sessions using an "IP4" multicast connection address MUST also have a time to live (TTL) value present, in addition to the multicast address. The TTL and the address together define the scope that multicast packets sent in this session will use. TTL values MUST be in the range 0-255. Although the TTL MUST be specified, using it to scope multicast traffic is deprecated. Applications SHOULD use an administratively scoped address instead 🙅♀️🧭
The TTL for the session is appended to the address with a slash as the separator. An example is:
c=IN IP4 233.252.0.1/127"IP6" multicast doesn't use TTL scoping, so the TTL value MUST NOT be present for "IP6" multicast. IPv6 scoped addresses are expected to be used to limit the scope of multimedia conferences instead 🦋
Now, hierarchical or layered encoding schemes 🍰 These are data streams where the encoding from a single media source is split into a number of layers. The receiver picks its desired quality (and therefore bandwidth) by only subscribing to a subset of those layers. Layered encodings are normally sent over multiple multicast groups so that multicast pruning can happen. This keeps unwanted traffic away from sites that only need certain levels of the hierarchy. For applications that need multiple multicast groups, the following notation can be used for the connection address:
<base multicast address>[/<ttl>]/<number of addresses>If the number of addresses isn't given, it's assumed to be one. Multicast addresses assigned this way are allocated contiguously above the base address. For example:
c=IN IP4 233.252.0.1/127/3That would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 are to be used with a TTL of 127. This is semantically identical to including multiple "c=" lines in a media description:
c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.2/127
c=IN IP4 233.252.0.3/127Similarly, an IPv6 example would be:
c=IN IP6 ff00::db8:0:101/3which is semantically equivalent to:
c=IN IP6 ff00::db8:0:101
c=IN IP6 ff00::db8:0:102
c=IN IP6 ff00::db8:0:103(Remember that the TTL subfield is not present in "IP6" multicast 💅)
Multiple addresses or "c=" lines MAY be specified on a per media description basis only if they provide multicast addresses for different layers in a hierarchical or layered encoding scheme. Multiple addresses or "c=" lines MUST NOT be specified at session level 🌸
The slash notation for multiple addresses described above MUST NOT be used for IP unicast addresses 🚫
5.8. Bandwidth Information ("b=") 💸
The OPTIONAL b= line (bandwidth-field) is how you tell everyone how much bandwidth the session or media description is hoping to use 🫶. It looks like this:
b=<bwtype>:<bandwidth>The <bwtype> is an alphanumeric modifier that tells you what the <bandwidth> number actually means. This spec defines two values, but other values MAY be registered in the future (see Section 8 and [RFC3556], [RFC3890]) 🌸
CT is the "conference total" one 📞. If a session's bandwidth is different from what the scope already implies, a b=CT: line SHOULD be supplied for the session with the proposed upper limit. Same deal for bundled media streams [RFC8843] in an m= line: if their bandwidth doesn't match the implicit value from the scope, a b=CT: line SHOULD be supplied at the media level too. The whole point is to get a rough idea of whether two or more sessions (or bundled media streams) can run at the same time 👀. Also, a b=CT: line is a total for all the media at all endpoints, so it's a big-picture number, not a per-person one. The Mux Category for b=CT: is NORMAL. More on that in [RFC8859] 💅
AS means the bandwidth is application specific, so it's whatever the app thinks its maximum bandwidth is 🧚. Usually that matches the app's "maximum bandwidth" setting, if it has one. For RTP-based apps, the b=AS: line gives the RTP "session bandwidth" from Section 6.2 of [RFC3550] ✨. Here's the tea: a b=AS: line is for one media at one endpoint, even though lots of endpoints might be sending at once 🙈. The Mux Category for b=AS: is SUM, which is covered in [RFC8859] 💖
Back in [RFC4566], there was an "X-" prefix for <bwtype> names. It was only meant for experiments, like this:
b=X-YZ:128Using the "X-" prefix is NOT RECOMMENDED 🙅. Instead, new <bwtype> names (without the "X-" prefix) SHOULD be defined, and then they MUST be registered with IANA in the standard namespace 📝. SDP parsers MUST ignore bandwidth-fields with unknown <bwtype> names 🫠. The <bwtype> names MUST be alphanumeric. There's no length limit, but it is recommended that they be short 🍓
The <bandwidth> is in kilobits per second by default, and that includes transport and network-layer overhead but NOT link-layer overhead 🔥. A new <bwtype> modifier MAY say the bandwidth is in some other unit instead (the "CT" and "AS" modifiers in this memo just use the default units) 🌈
5.9. Time Active ("t=") ⏰
t=<start-time> <stop-time>A t= line (time-field) starts a time description that says when a session begins and ends 🎀. You MAY use multiple time descriptions if a session is active at several irregularly spaced times. Each extra one adds another period when the session is on 💜. If the session repeats at regular intervals, you can put a repeat description after the time-field. That's an r= line (see Section 5.10) 🔁. When you do that, the time-field covers the start and stop of the whole repeat sequence.
Here's an example with two active intervals:
t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC
t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTCThe first and second subfields are the start and stop times for the session 🕰️. They're decimal numbers of seconds since January 1, 1900 UTC. To turn them into Unix time (UTC), subtract the decimal 2208988800 🧮
Some time representations wrap around in the year 2036. SDP doesn't have that problem, though, because it uses an arbitrary-length decimal representation 🙌. Still, SDP implementations need to be ready to handle those bigger values 💪
If the <stop-time> is zero, the session is unbounded. It won't become active until after the <start-time> though 🌙. If the <start-time> is also zero, the session is permanent 💎
User interfaces SHOULD strongly discourage making unbounded and permanent sessions 🙅♀️. They don't tell anyone when the session will end, which makes scheduling a nightmare 😭
When you're showing an unbounded session to a user that hasn't timed out, you can generally assume it will only be active until half an hour from now or from the session start time, whichever is later ⏳. If you need something different, a <stop-time> SHOULD be given, and it should be changed when better information comes in about when the session should actually end 🫡
Permanent sessions may be shown to the user as never being active, unless there are repeat times that say exactly when the session will be active 🦋
5.10. Repeat Times ("r=") 🔁
r=<repeat interval> <active duration> <offsets from start-time>An "r=" line (repeat-field) sets repeat times for a session 💅. If you need a complicated schedule, you can include multiple repeat-fields ✨. Here's an example: say a session is active at 10am on Monday and 11am on Tuesday, one hour each, every week for three months 🗓️. Then the <start-time> in the matching t= line is 10am on the first Monday, the <repeat interval> is 1 week, the <active duration> is 1 hour, and the offsets are zero and 25 hours. The t= line's stop time is the end of the last session, three months later 🎉. By default, every subfield is in seconds, so the r= and t= lines might look like this:
t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC
; Tues 20-Mar-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hoursTo keep things compact, you can also write times in days, hours, or minutes 🍰. The syntax is a number right next to a single case-sensitive character. Fractions aren't allowed, so just use a smaller unit instead 🙅. These unit characters are allowed:
+---+------------------------------------+
| d | days (86400 seconds) |
+---+------------------------------------+
| h | hours (3600 seconds) |
+---+------------------------------------+
| m | minutes (60 seconds) |
+---+------------------------------------+
| s | seconds (allowed for completeness) |
+---+------------------------------------+
Table 1: Time Unit Specification
CharactersSo that repeat-field from before could also be written like this 💖:
r=7d 1h 0 25hMonthly and yearly repeats can't be written directly with a single SDP repeat time 🥲. Instead, you should use separate time-descriptions to list out the session times explicitly 📅
5.11. Time Zone Adjustment ("z=") 🌍
z=<adjustment time> <offset> <adjustment time> <offset> ....A "z=" line (zone-field) is an optional modifier for the repeat-fields right before it 🎀. It doesn't apply to any other fields 🙅
Scheduling a repeated session that crosses a daylight saving change, in either direction, means you need offsets from the base time 🌞🌙. This matters because different time zones switch at different times of day, different countries switch on different dates, and some countries don't do daylight saving at all 😵💫
So if you want a session to land at the same time in winter and summer, receivers have to be able to tell unambiguously whose time zone it's scheduled by 🧐. To make that easier, the sender can give the time (in seconds since January 1, 1900 UTC) when a time zone adjustment happens, plus the offset from when the session was first scheduled 💜. The "z=" line lets the sender list these adjustment times and offsets from the base time ✨
Here's an example:
t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC
; Tues 18-Dec-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC,
; offset 1 hour,
; Sun 28-Oct-2018 2:00 UTC,
; no offsetThis says that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, when British Summer Time starts 🇬🇧☀️), the time base for the session's repeat times moves back by 1 hour. Then at time 3749680800 (Sun 28-Oct-2018 2:00 UTC, when British Summer Time ends 🍂), the original time base comes back. Adjustments are always relative to the specified start time, and they don't stack up 🙅♀️
If a session might last several years, the session description is expected to be updated periodically 🔄. You shouldn't send several years' worth of adjustments in one session description 😩
5.12. Encryption Keys ("k=") 🔐
k=<method>
k=<method>:<encryption key>The "k=" line (key-field) is obsolete and MUST NOT be used 🚫. It's only still in this document for legacy reasons 🦕. One MUST NOT include a "k=" line in an SDP, and if one shows up in a received SDP, you MUST discard it 🗑️
5.13. Attributes ("a=") ✨
a=<attribute-name>
a=<attribute-name>:<attribute-value>okay so attributes are the main way SDP gets extended, bestie 🧚 They can be session-level, media-level, or both. (Other attribute scopes can also be defined in extensions to this doc, like [RFC5576] and [RFC8864], so keep your eyes open 👀)
A media description can have any number of a= lines (attribute-fields) that belong to that specific media description. These are the media-level attributes, and they add info about that media 🎬 You can also drop attribute-fields before the first media description. Those are session-level attributes, and they describe the whole session instead of one media stream 💖
There are two flavours of attribute-field:
- A property attribute is just
a=<attribute-name>. It's binary, so if it's there, that means the session has that property. Example:a=recvonly🙌 - A value attribute is
a=<attribute-name>:<attribute-value>. For example, a whiteboard could carrya=orient:landscape🖼️
How an attribute gets interpreted depends on the media tool being invoked, so receivers should be configurable in how they read session descriptions in general and attributes in particular 🫶
Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. Obsessed with this rule, honestly 💅
Attribute values are octet strings and MAY use any octet value except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are read as the ISO-10646 character set with UTF-8 encoding. Unlike the other text fields, attribute values are NOT normally affected by the a=charset: attribute, because that would make comparing against known values messy 😭 That said, when an attribute is defined, it can be defined as charset dependent. In that case its value should be read in the session charset instead of ISO-10646 ✨
Attributes MUST be registered with IANA (see Section 8). If an attribute is received that isn't understood, it MUST be ignored by the receiver. No drama, just skip it 🍓
5.14. Media Descriptions ("m=") 🎀
m=<media> <port> <proto> <fmt> ...A session description can hold a bunch of media descriptions. Each one starts with an m= line (the media-field) and ends when the next m= line shows up or the session description ends 🌈 A media-field has a few subfields, let's go:
<media>is the media type. This doc definesaudio,video,text,application, andmessage. The list gets extended by other memos and may grow later when new memos register media types (see Section 8). For example, [RFC6466] defined theimagemedia type 🖼️<port>is the transport port the media stream gets sent to. What that port means depends on the network in use (from the relevantc=line) and on the transport protocol in the<proto>subfield 🚀 Other ports the media app uses, like the RTP Control Protocol (RTCP) port [RFC3550], MAY be derived algorithmically from the base media port, or MAY be specified in a separate attribute (like thea=rtcp:attribute defined in [RFC3605]).
If noncontiguous ports are used, or they don't follow the even RTP / odd RTCP parity rule, the a=rtcp: attribute MUST be used. Apps asked to send media to an odd <port> where a=rtcp: is present MUST NOT subtract 1 from the RTP port. So they MUST send the RTP to the port in <port> and send the RTCP to the port in the a=rtcp: attribute 🙅♀️
For hierarchically encoded streams going to a unicast address, you might need to specify multiple transport ports. This uses a notation similar to the one for IP multicast addresses in the c= line:
m=<media> <port>/<number of ports> <proto> <fmt> ...Which ports get used depends on the transport protocol. For RTP, the default is that only the even-numbered ports carry data, with the one-higher odd ports used for the RTCP of that RTP session, and <number of ports> counts the RTP sessions. For example:
m=video 49170/2 RTP/AVP 31This would say ports 49170 and 49171 form one RTP/RTCP pair, and 49172 and 49173 form the second pair. RTP/AVP is the transport protocol, and 31 is the format (see the <fmt> description below) 💜
This doc doesn't have a way to declare hierarchically encoded streams using noncontiguous ports. (No attribute is defined to do that yet, and the a=rtcp: attribute from [RFC3605] doesn't handle hierarchical encoding.) If someone needs to declare noncontiguous ports, a new attribute will have to be defined for it 🧩
If multiple addresses are in the c= line and multiple ports are in the m= line, there's an implied one-to-one mapping from port to its matching address. For example:
m=video 49170/2 RTP/AVP 31
c=IN IP4 233.252.0.1/127/2This would imply address 233.252.0.1 is used with ports 49170 and 49171, and address 233.252.0.2 is used with ports 49172 and 49173 🦋
The mapping works the same way when multiple addresses come in multiple c= lines:
m=video 49170/2 RTP/AVP 31
c=IN IP6 ff00::db8:0:101
c=IN IP6 ff00::db8:0:102This would imply address ff00::db8:0:101 is used with ports 49170 and 49171, and address ff00::db8:0:102 is used with ports 49172 and 49173 ✨
Giving the same media address to multiple media descriptions means nothing in this doc. It doesn't group those media descriptions in any way, sorry bestie 🙈 If you want to express grouping, use an explicit grouping framework instead (for example, [RFC5888]). For instance, see [RFC8843] 👑
<proto>is the transport protocol. What it means depends on the address type subfield in the relevantc=line. So ac=line with address typeIP4means the transport protocol runs over IPv4 🌐 These transport protocols are defined, but you can extend the list by registering new protocols with IANA (see Section 8):udp: the data is carried directly in UDP with no extra framing.RTP/AVP: RTP [RFC3550] used under the RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551], running over UDP.RTP/SAVP: the Secure Real-time Transport Protocol [RFC3711], running over UDP.RTP/SAVPF: SRTP with the Extended SRTP Profile for RTCP-Based Feedback [RFC5124], running over UDP.
Why bother specifying the transport protocol as well as the media format? Because the same standard media formats can ride over different transport protocols even on the same network protocol. A historical example is vat (the MBone's popular multimedia audio tool) Pulse Code Modulation (PCM) audio versus RTP PCM audio. Another could be TCP/RTP PCM audio. Relays and monitoring tools that are transport-protocol-specific but format-independent are also possible 🔥
<fmt>is a media format description. The fourth and any later subfields describe the media format, and how it's interpreted depends on the<proto>subfield 🎶
If <proto> is RTP/AVP or RTP/SAVP, the <fmt> subfields hold RTP payload type numbers. When there's a list of them, it means all of those payload formats MAY be used in the session. They're listed in order of preference, with the first one being most preferred. When multiple payload formats are listed, the first acceptable one from the start of the list SHOULD be used for the session. For dynamic payload type assignments, the a=rtpmap: attribute (see Section 6.6) SHOULD be used to map an RTP payload type number to a media encoding name that identifies the payload format. The a=fmtp: attribute MAY be used to specify format parameters (see Section 6.15) 💅
If <proto> is udp, the <fmt> subfields MUST reference a media type that describes the format under the audio, video, text, application, or message top-level media types. The media type registration SHOULD define the packet format for use with UDP transport 📦
For media using other transport protocols, the <fmt> subfield is protocol specific. Rules for interpreting <fmt> MUST be defined when registering new protocols (see Section 8.2.2) 🫶
Section 3 of [RFC4855] says payload format (encoding) names defined in the RTP profile are commonly shown in upper case, while media subtype names are commonly shown in lower case. It also says both of these names are case-insensitive in both places, similar to parameter names, which are case-insensitive both in media type strings and in the default mapping to the SDP a=fmtp: attribute 🌸
6. SDP Attributes 💜
The following attributes are defined. Application writers can add new attributes whenever they need them, so this list isn't exhaustive 🌈 Registration procedures for new attributes are in Section 8.2.4. Syntax is given using ABNF [RFC7405], with some of the rules defined further in Section 9 🧚
6.1. cat (Category) 🌸
Name: cat
Value: cat-value
Usage Level: session
Charset Dependent: no
Syntax:
cat-value = category
category = non-ws-string
Example:
a=cat:foo.barThis attribute gives the dot-separated hierarchical category of the session. It lets a receiver filter out sessions it doesn't want, by category 🗂️ There's no central registry of categories. This attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored if received 💀
6.2. keywds (Keywords) 🦋
Name: keywds
Value: keywds-value
Usage Level: session
Charset Dependent: yes
Syntax:
keywds-value = keywords
keywords = text
Example:
a=keywds:SDP session description protocolLike a=cat:, this was meant to help receivers find the sessions they want, and to let them pick interesting sessions based on keywords describing the purpose of the session. However, there's no central registry of keywords 🔑 Its value should be read in the charset specified for the session description if one is specified. Otherwise it defaults to ISO 10646/UTF-8. This attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored if received 🙅♀️
6.3. tool 🎀
Name: tool
Value: tool-value
Usage Level: session
Charset Dependent: no
Syntax:
tool-value = tool-name-and-version
tool-name-and-version = textExample:
a=tool:foobar V3.2okay so this one is the "who made this" attribute 💅 It tells you the name and version of the tool that built the session description. Think of it as the little credit line at the bottom of the file ✨
6.4. ptime (Packet Time) ⏱️
Name: ptime
Value: ptime-value
Usage Level: media
Charset Dependent: no
Syntax:
ptime-value = non-zero-int-or-realExample:
a=ptime:20This one gives the amount of time, in milliseconds, that the media inside a single packet represents. It's probably only meaningful for audio, but you can use it with other media types if it actually makes sense for them 🎧 You should not need a=ptime: to decode RTP or vat audio, bestie. It's more of a suggestion for how to encode and packetize audio than a must-have 🦋
6.5. maxptime (Maximum Packet Time) 🌸
Name: maxptime
Value: maxptime-value
Usage Level: media
Charset Dependent: no
Syntax:
maxptime-value = non-zero-int-or-realExample:
a=maxptime:20This is the biggest chunk of media that can get packed into one packet, measured in milliseconds 📦 The time SHALL be worked out by adding up the time that the media in the packet represents. For frame-based codecs, the time SHOULD be a whole-number multiple of the frame size. It's mostly a vibe for audio, but other media types can use it if it fits 🎶 Heads up, though: this attribute showed up after [RFC2327], so any implementation that hasn't been updated will just ignore it 🙈
6.6. rtpmap 🗺️
Name: rtpmap
Value: rtpmap-value
Usage Level: media
Charset Dependent: no
Syntax:
rtpmap-value = payload-type SP encoding-name
"/" clock-rate [ "/" encoding-params ]
payload-type = zero-based-integer
encoding-name = token
clock-rate = integer
encoding-params = channels
channels = integerokay, this is the map 🗺️ It links an RTP payload type number (the one you see in an m= line) to an encoding name, which is the payload format being used. It also tells you the clock rate and any encoding parameters. Quick note: the payload type number lives in a 7-bit field, so the only values allowed are 0 through 127, inclusive 💅
Some RTP profiles give payload type numbers fixed jobs, but it's way more common to assign them on the fly with a=rtpmap: lines. A classic static example is u-law PCM, single-channel audio sampled at 8 kHz. That's fully defined in the RTP audio/video profile as payload type 0, so you don't need an a=rtpmap: line at all. A stream like that, going to UDP port 49232, can be described like this:
m=audio 49232 RTP/AVP 0Now for a dynamic one: 16-bit linear stereo audio sampled at 16 kHz. If we want the dynamic RTP/AVP payload type 98 for it, we need more info to decode it:
m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2You can have up to one a=rtpmap: attribute for each media format listed. So something like this is totally valid 🌈
m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2RTP profiles that use dynamic payload types MUST define the set of valid encoding names, and/or a way to register encoding names, if they're going to be used with SDP 📋 The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes as encoding names, under the top-level media type from the m= line. So in the example above, the media types are "audio/L8" and "audio/L16" 🎧
For audio, encoding-params tells you how many audio channels there are. This parameter is OPTIONAL, and you can leave it out if there's only one channel and no other parameters are needed.
For video streams, no encoding parameters are currently specified 🎥
More encoding parameters MAY be defined in the future, but codec-specific parameters SHOULD NOT be added. Parameters in an a=rtpmap: attribute SHOULD only be the ones a session directory needs to pick the right media to join a session. Codec-specific parameters should go in other attributes instead (for example, a=fmtp:) 💜
Note: RTP audio formats usually don't include the number of samples per packet. If you need a non-default packetization (the default is defined in the RTP Audio/Video Profile [RFC3551]), use the a=ptime: attribute as described in Section 6.4 ⏰
6.7. Media Direction Attributes 🧭
At most one occurrence of a=recvonly, a=sendrecv, a=sendonly, or a=inactive MAY appear at session level, and at most one MAY appear in each media description.
If one of these shows up in a media description, it applies to that media description. If none shows up in a media description, then the session-level one applies to it, if there is one 🫶
If none of the media direction attributes is present at either session level or media level, a=sendrecv SHOULD be assumed as the default 💖
In this SDP example, a=sendrecv applies to the first audio media, and a=inactive applies to the others:
v=0
o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1
s=-
c=IN IP6 2001:db8::1
t=0 0
a=inactive
m=audio 49170 RTP/AVP 0
a=sendrecv
m=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/900006.7.1. recvonly (Receive-Only) 👂
Name: recvonly
Value: (none)
Usage Level: session, media
Charset Dependent: no
Example:
a=recvonlyThis tells the tools to start in receive-only mode, wherever that applies. Heads up that receive-only mode only covers the media, not any associated control protocol. An RTP-based system in receive-only mode MUST still send RTCP packets as described in [RFC3550], Section 6 📡
6.7.2. sendrecv (Send-Receive) 🔁
Name: sendrecv
Value: (none)
Usage Level: session, media
Charset Dependent: no
Example:
a=sendrecvThis tells the tools to start in send and receive mode. It's needed for interactive multimedia conferences with tools that default to receive-only mode 🎤
6.7.3. sendonly (Send-Only) 📤
Name: sendonly
Value: (none)
Usage Level: session, media
Charset Dependent: no
Example:
a=sendonlyThis tells the tools to start in send-only mode. One example is when the traffic destination should use a different unicast address than the traffic source. In that case you can use two media descriptions, one send-only and one receive-only (the original says "receive-vonly", which is a typo, so we're going with receive-only 🙃). Note that send-only mode only applies to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal 📊
6.7.4. inactive 😴
Name: inactive
Value: (none)
Usage Level: session, media
Charset Dependent: no
Example:
a=inactiveThis tells the tools to start in inactive mode. It's needed for interactive multimedia conferences where users can put each other on hold 📵 No media is sent over an inactive media stream. An RTP-based system MUST still send RTCP (if RTCP is used), even when it's started in inactive mode 💜
6.8. orient (Orientation) 📱
Name: orient
Value: orient-value
Usage Level: media
Charset Dependent: no
Syntax:
orient-value = portrait / landscape / seascape
portrait = %s"portrait"
landscape = %s"landscape"
seascape = %s"seascape"
; NOTE: These names are case-sensitive.Example:
a=orient:portraitUsually this is only for a whiteboard or presentation tool 🖼️ It sets the orientation of the workspace on the screen. The permitted values are "portrait", "landscape", and "seascape" (which is upside-down landscape) 🙃
6.9. type (Conference Type) 🎪
Name: type
Value: type-value
Usage Level: session
Charset Dependent: no
Syntax:
type-value = conference-type
conference-type = broadcast / meeting / moderated / test /
H332
broadcast = %s"broadcast"
meeting = %s"meeting"
moderated = %s"moderated"
test = %s"test"
H332 = %s"H332"
; NOTE: These names are case-sensitive.Example:
a=type:moderatedThis one specifies the type of multimedia conference. The allowed values are "broadcast", "meeting", "moderated", "test", and "H332". Each of these hints at other options that are probably a good fit 👑
- When
a=type:broadcastis specified,a=recvonlyis probably appropriate for those connecting. - When
a=type:meetingis specified,a=sendrecvis likely to be appropriate. a=type:moderatedsuggests using a floor control tool, and that the media tools get started so that new sites joining the conference are muted.- Specifying
a=type:H332means this loosely coupled session is part of an H.332 session, as defined in the ITU H.332 specification [ITU.H332.1998]. Media tools should be started usinga=recvonly. - Specifying
a=type:testis a hint that, unless someone explicitly asks for otherwise, receivers can safely skip showing this session description to users 🙈
6.10. charset (Character Set) 🔤
Name: charset
Value: charset-value
Usage Level: session
Charset Dependent: no
Syntax:
charset-value = <defined in [RFC2978]>This sets the character set used to display the session name and information data. By default, the ISO-10646 character set in UTF-8 encoding is used 🌍 If you need something more compact, you can use other character sets. For example, ISO 8859-1 is set with this SDP attribute:
a=charset:ISO-8859-1The charset specified MUST be one of the ones registered in the IANA Character Sets registry (http://www.iana.org/assignments/character-sets), such as ISO-8859-1 📚 The character set identifier is a string that MUST be compared against the "Name" or "Preferred MIME Name" fields of the registry, using a case-insensitive comparison. If the identifier isn't recognized or isn't supported, then all strings it affects SHOULD be treated as octet strings 🧩
Charset-dependent fields MUST contain only sequences of bytes that are valid under the definition of the selected character set. On top of that, charset-dependent fields MUST NOT contain the bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR) 🚫 Okay, that's the rules, babe. Hard stop on those three bytes!! 💀
6.11. sdplang (SDP Language) ✨
Name: sdplang
Value: sdplang-value
Usage Level: session, media
Charset Dependent: no
Syntax:
sdplang-value = Language-Tag
; Language-Tag defined in RFC 5646
Example:
a=sdplang:frokay bestie, sdplang is how you tag the language of the session description itself 🌸 and no, it's NOT the language of the media, so don't mix those up 🙈 the value is a Language-Tag from RFC 5646 [RFC5646], and the example is a=sdplang:fr 🇫🇷
you can drop multiple a=sdplang: attributes at session level or media level if the session description or the media is using more than one language 🌈
at session level, it tags the language for the session description, not the media 💅 at media level, it tags the language for any media-level SDP information-field linked to that media (again, not the media's language 😭), and it overrides any a=sdplang: attributes set at session level 👑
generally, sending a session description with multiple languages in it is kinda discouraged 🙃 the better move is that multiple session descriptions SHOULD be sent describing the session, one in each language 🎀 BUT not every transport mechanism can do that, so multiple a=sdplang: attributes are allowed, although NOT RECOMMENDED 💀
the a=sdplang: value must be a single language tag [RFC5646] 🦋 and an a=sdplang: attribute SHOULD be specified when a session is distributed far enough to cross geographic boundaries (where you can't assume the recipients' language 😩), or where the session is in a different language from the locally assumed norm 🌸
6.12. lang (Language)
Name: lang
Value: lang-value
Usage Level: session, media
Charset Dependent: no
Syntax:
lang-value = Language-Tag
; Language-Tag defined in RFC 5646
Example:
a=lang:dethis one is lang, and it's giving "here's the languages people can use here" 🧚 you can have multiple a=lang: attributes at session or media level if the session or media can handle more than one language 🌈 and the ORDER matters! the order tells you the preference, from most preferred to least preferred 👑
at session level, a=lang: says what language capability the session has 🎀 at media level, it says the language capability for that media and overrides any session-level language(s) 💅
the a=lang: value must be a single [RFC5646] language tag 🦋 and an a=lang: attribute SHOULD be specified when a session is big enough to cross geographic boundaries (where you can't assume participants speak the same language 😭), or when the session has capabilities in languages that are different from the locally assumed norm 🌸
ngl this part is so important: the a=lang: attribute is supposed to set the initial language(s) used in the session ✨ events during the session can change which languages get used, and participants are not strictly bound to only use the declared languages 🫶
most real-time use cases start with just one language 💖 but other cases involve a bunch of languages, like an interpreted or subtitled session 🌍 when there's more than one a=lang: attribute, the attribute itself doesn't tell you if multiple languages are meant to be used during the session, or if the goal is to pick just one of them 🤔 if you need that info, a new attribute can be defined and used to indicate that intention 🧩 without those semantics, it's assumed that for a negotiated session one of the declared languages will be selected and used 🍓
6.13. framerate (Frame Rate)
Name: framerate
Value: framerate-value
Usage Level: media
Charset Dependent: no
Syntax:
framerate-value = non-zero-int-or-real
Example:
a=framerate:60framerate is giving "how fast can the video go" 🎬 it gives the maximum video frame rate in frames/sec ⭐ it's intended as a recommendation for the encoding of video data 💜 decimal representations of fractional values are allowed ✨ and it's only defined for video media, so don't try it on audio bestie 🙅♀️
6.14. quality
Name: quality
Value: quality-value
Usage Level: media
Charset Dependent: no
Syntax:
quality-value = zero-based-integer
Example:
a=quality:10quality is a suggestion for the encoding quality, as an integer 💅 for video, the intention is to ask for a non-default trade-off between frame-rate and still-image quality 🎞️ the value goes from 0 to 10, and here's the vibe check 👇🔥
+----+----------------------------------------+
| 10 | the best still-image quality the |
| | compression scheme can give. |
+----+----------------------------------------+
| 5 | the default behavior given no quality |
| | suggestion. |
+----+----------------------------------------+
| 0 | the worst still-image quality the |
| | codec designer thinks is still usable. |
+----+----------------------------------------+
Table 2: Encoding Quality Valuesso 10 is the absolute best still image the compression scheme can give 🤩 5 is what you get by default when nobody suggests anything 🌸 and 0 is the worst still image the codec designer thinks is still usable 💀 choose wisely 🫶
6.15. fmtp (Format Parameters)
Name: fmtp
Value: fmtp-value
Usage Level: media
Charset Dependent: no
Syntax:
fmtp-value = fmt SP format-specific-params
format-specific-params = byte-string
; Notes:
; - The format parameters are media type parameters and
; need to reflect their syntax.
Example:
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600fmtp is the parameter-passing queen 👑 it lets you convey parameters that are specific to a particular format, in a way that SDP doesn't have to understand them 🧚 the format has to be one of the formats specified for the media 🎀 format-specific parameters are semicolon separated, and they can be any set of parameters that need to be conveyed by SDP and handed off unchanged to the media tool that'll use that format 🦋
there's at most one instance of this attribute allowed for each format 🙈 and the a=fmtp: attribute may be used to specify parameters for any protocol and format that defines use of such parameters 🌈
7. Security Considerations ✨
okay this section is SERIOUS bestie 😭🔥 but I'll keep it real
SDP is frequently used with the Session Initiation Protocol [RFC3261] 📞 using the offer/answer model [RFC3264] to agree on parameters for unicast sessions 🤝 when it's used this way, the security considerations of those protocols apply 🫶
SDP is a session description format that describes multimedia sessions 🎥 entities receiving and acting on an SDP message SHOULD be aware that a session description can't be trusted unless it was obtained by an authenticated and integrity-protected transport protocol from a known and trusted source 🚨 many different transport protocols may be used to distribute session descriptions, and the authentication and integrity protection will differ from transport to transport 🌪️ for some transports, security features are often not deployed 💀 so if a session description wasn't obtained in a trusted manner, the endpoint SHOULD exercise care, because among other attacks, the media sessions received may not be the intended ones 😱 the destination the media is sent to may not be the expected one 😱 any of the parameters of the session may be incorrect 😱 or the media security may be compromised 😱 it's up to the endpoint to make a sensible decision, taking into account the security risks of the application and the user preferences ✨ the endpoint may decide to ask the user whether or not to accept the session 🙋♀️
on receiving a session description over an unauthenticated transport mechanism, or from an untrusted party, software parsing the session description should take a few precautions 🛡️ similar concerns apply if integrity protection isn't in place 🙈 session descriptions contain information required to start software on the receiver's system 👀 so software that parses a session description MUST NOT be able to start other software except the software that's specifically configured as appropriate to participate in multimedia sessions 🚫 it's normally considered inappropriate for software parsing a session description to start, on a user's system, software that's appropriate for multimedia sessions, without the user first being informed that such software will be started and giving consent 🙅♀️ so a session description arriving by session announcement, email, session invitation, or WWW page MUST NOT drop the user into an interactive multimedia session unless the user has explicitly pre-authorized that action 💅 since it's not always simple to tell whether a session is interactive, applications that are unsure should assume sessions are interactive 🫣 and software processing URLs contained in session descriptions should also heed the security considerations identified in [RFC3986] 🔗
in this specification, there are NO attributes that would let the recipient of a session description be told to start multimedia tools in a mode where they default to transmitting 😳 under some circumstances it might be appropriate to define such attributes 🤷♀️ if that happens, an application parsing a session description containing such attributes SHOULD either ignore them or inform the user that joining this session will result in the automatic transmission of multimedia data 📢 and the default behavior for an unknown attribute is to ignore it 🧚
in certain environments, it's become common for intermediary systems to intercept and analyze session descriptions contained within other signaling protocols 👀 they do this for a range of purposes, including but not limited to opening holes in firewalls so media streams can pass, or to mark, prioritize, or block traffic selectively 🚦 in some cases, these intermediary systems may modify the session description, for example, so the contents match NAT bindings that were dynamically created 🌐 these behaviors are NOT RECOMMENDED unless the session description is conveyed in a way that lets the intermediary system run proper checks to establish the authenticity of the session description, and the authority of its source to set up those communication sessions 🔐 SDP by itself doesn't include enough information for those checks, so they depend on the encapsulating protocol (e.g., SIP or RTSP) 🍓 some procedures and SDP extensions, like Interactive Connectivity Establishment (ICE) [RFC8445] and ICE-SIP-SDP [RFC8839], may avoid the need for intermediaries to modify SDP ✨
SDP MUST NOT be used to convey keying material (e.g., using the "a=crypto:" attribute [RFC4568]) unless it can be guaranteed that the channel the SDP is delivered over is both private and authenticated 🔑🚫 no shortcuts, periodt 💜
8. IANA Considerations ✨
8.1. The "application/sdp" Media Type ✨
okay so this is the registration for the application/sdp media type, and bestie, it's giving main character energy 🎀. One media type registration from [RFC4566] has been updated, and here's exactly how it looks now 💅
- Type name:
application - Subtype name:
sdp - Required parameters: None.
- Optional parameters: None.
- Encoding considerations: 8-bit text. SDP files are mostly UTF-8 text 📝. The
a=charset:attribute can be used to signal other character sets in certain parts of an SDP file (see Section 6 of RFC 8866). Arbitrary binary content can't be represented directly in SDP 🙈. - Security considerations: See Section 7 of RFC 8866 🔒.
- Interoperability considerations: See RFC 8866.
- Published specification: See RFC 8866.
- Applications which use this media type: Voice over IP, video teleconferencing, streaming media, instant messaging, and more ☎️📺. See also Section 3 of RFC 8866.
- Fragment identifier considerations: None
- Additional information:
- Deprecated alias names for this type: N/A
- Magic number(s): None.
- File extension(s): The extension
.sdpis commonly used 🍓. - Macintosh File Type Code(s):
"sdp"
- Person & email address to contact for further information: IETF MMUSIC working group
<mmusic@ietf.org>💌 - Intended usage: COMMON
- Restrictions on usage: None
- Author/Change controller: Authors of RFC 8866, and the IETF MMUSIC working group, delegated from the IESG 👑
8.2. Registration of SDP Parameters with IANA
okay this section is where the IANA parameter registries live 🗂️✨. This document sets up registries for six named SDP subfields. Using the terminology from the SDP specification's Augmented Backus-Naur Form (ABNF), they are <media>, <proto>, <attribute-name>, <bwtype>, <nettype>, and <addrtype> 🦋.
This document also replaces and updates the definitions of all of those parameters that were previously defined by [RFC4566] 🔄.
IANA has changed every reference to RFC 4566 in these registries so that it points to this document instead 💜.
The contact name and email address for every parameter registered in this document is:
The IETF MMUSIC working group <mmusic@ietf.org> or its successor as designated by the IESG.
All of these registries share a common format, and it looks like this 🎀:
+======+==========+================+===========+
| Type | SDP Name | [other fields] | Reference |
+======+==========+================+===========+Table 3: Common Format for SDP Registries
8.2.1. Registration Procedure
okay so if you want to define values for the <media>, <proto>, <attribute-name>, <bwtype>, <nettype>, or <addrtype> parameters, your specification MUST include the following information 📋:
- Contact name
- Contact email address
- Name being defined (as it will appear in SDP)
- Type of name (
<media>,<proto>,<attribute-name>,<bwtype>,<nettype>, or<addrtype>) - A description of the purpose of the defined name
- A stable reference to the document that contains this information and the definition of the value. (This will typically be an RFC number 🌸.)
The subsections below spell out what other information (if any) has to be specified for particular parameters, plus any other fields that belong in the registry 🧚.
8.2.2. Media Types (<media>)
The set of media types is meant to stay small, so it SHOULD NOT be extended except in rare circumstances 🙅♀️. The same rules should apply to media names as to top-level media types, and wherever possible the same name should be registered for SDP as for MIME 💖. For media other than the existing top-level media types, a Standards Track RFC MUST be produced before a new top-level media type can be registered, and the registration MUST give good justification for why no existing media name is appropriate (this is the "Standards Action" policy of [RFC8126]) 🔥.
This memo registers the media types "audio", "video", "text", "application", and "message" 🎶📹📝📦💬.
Note: The media types "control" and "data" were listed as valid in an early version of this specification [RFC2327]. However, their semantics were never fully specified, and they aren't widely used 🥲. These media types have been removed in this specification, although they still count as valid media type capabilities for a SIP user agent, as defined in [RFC3840]. If these media types end up being useful in the future, a Standards Track RFC MUST be produced to document their use. Until that happens, applications SHOULD NOT use these types, and they SHOULD NOT declare support for them in SIP capabilities declarations (even though they exist in the registry created by [RFC3840]). Also note that [RFC6466] defined the "image" media type 🖼️.
8.2.3. Transport Protocols (<proto>)
The <proto> subfield describes the transport protocol being used 🚀. The registration procedure for this registry is "RFC Required" 📑.
This document registers two values 💅:
- "RTP/AVP" is a reference to [RFC3550] used under the RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551], running over UDP/IP 🎧.
- "udp" indicates direct use of UDP 📡.
New transport protocols MAY be defined, and they MUST be registered with IANA 🗳️. Registrations MUST reference an RFC that describes the protocol. That RFC MAY be Experimental or Informational, although it's preferable for it to be Standards Track ✨. The RFC that defines a new protocol MUST define the rules by which the <fmt> namespace (see below) is managed 🗝️.
Names in <proto> that start with "RTP/" MUST only be used for defining transport protocols that are profiles of RTP. For example, a profile whose short name is "XYZ" would be written as a <proto> subfield of "RTP/XYZ" 🌈.
Each transport protocol, as defined by the <proto> subfield, has an associated <fmt> namespace that describes the media formats that may be carried by that protocol. Formats cover all the possible encodings that could be transported in a multimedia session 🎬.
RTP payload formats under "RTP/AVP" and the other "RTP/*" profiles MUST use the payload type number as their <fmt> value. If the payload type number is dynamically assigned by this session description, an additional a=rtpmap: attribute MUST be included to specify the format name and parameters, as defined by the media type registration for the payload format 🧩. It is RECOMMENDED that other RTP profiles that are registered (in combination with RTP) as SDP transport protocols specify the same rules for the <fmt> namespace 💜.
For the "udp" protocol, the allowed <fmt> values are media subtypes from the IANA Media Types registry 📚. The media type and subtype combination <media>/<fmt> specifies the format of the body of UDP packets. Using an existing media subtype for the format is encouraged 🙌. If no suitable media subtype exists, it is RECOMMENDED that a new one be registered through the IETF process [RFC6838], by producing or referencing a Standards Track RFC that defines the format 🫶.
For other protocols, formats MAY be registered according to the rules of the associated <proto> specification 🎀.
Registrations of new formats MUST specify which transport protocols they apply to 📌.
8.2.4. Attribute Names (<attribute-name>)
Attribute-field names (<attribute-name>) MUST be registered with IANA and documented, so we don't get any issues from conflicting attribute definitions under the same name 🚫. (Unknown attributes in SDP are simply ignored, but conflicting ones that fragment the protocol are a serious problem 😱.)
The format of the <attribute-name> registry looks like this 📊:
+======+==========+=============+==============+===========+
| Type | SDP Name | Usage Level | Mux Category | Reference |
+======+==========+=============+==============+===========+Table 4: Format of the <attribute-name> Registry
Here's an example. The attribute "a=lang:", which is defined for both session and media level, gets listed in the new registry like this 👀:
+===========+==========+================+==============+===========+
| Type | SDP Name | Usage Level | Mux Category | Reference |
+===========+==========+================+==============+===========+
| attribute | lang | session, media | TRANSPORT | [RFC8866] |
| | | | | [RFC8859] |
+-----------+----------+----------------+--------------+-----------+Table 5: <attribute-name> Registry Example
This single <attribute-name> registry combines all of the earlier usage-level-specific "att-field" registries, including the updates made by [RFC8859]. It also renames the "att-field" registry to the "attribute-name (formerly "att-field")" registry 🪄. IANA has finished the necessary reformatting ✅.
Section 6 of this document replaces the initial set of attribute definitions made by [RFC4566]. IANA has updated the registry to match 💖.
Documents can define new attributes, and they can also extend the definitions of previously defined attributes 🌸.
8.2.4.1. New Attributes ✨
okay so new attribute registrations get accepted under the "Specification Required" policy of [RFC8126] 💅, as long as the spec includes all of this info:
- Contact name 🫶
- Contact email address 📧
- Attribute name: the name of the attribute that will appear in SDP. This MUST conform to the definition of
<attribute-name>. - Attribute syntax: for a value attribute (see Section 5.13), an ABNF definition of the attribute value
<attribute-value>syntax (see Section 9) MUST be provided. The syntax MUST follow the rule form per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define the allowable values that the attribute might take. It MAY also define an extension method for the addition of future values. For a property attribute, the ABNF definition is omitted as the property attribute takes no values. 🦋 - Attribute semantics: for a value attribute, a semantic description of the values that the attribute might take MUST be provided. The usage of a property attribute is described under Purpose below. 🌸
- Attribute value: the name of an ABNF syntax rule defining the syntax of the value. Absence of a rule name indicates that the attribute takes no values. Enclosing the rule name in "[" and "]" indicates that a value is optional. 🎀
- Usage level: the usage level(s) of the attribute. This MUST be one or more of the following:
session,media,source,dcsa, anddcsa(subprotocol). For a definition of source-level attributes, see [RFC5576]. For a definition of dcsa attributes see [RFC8864]. 🧚 - Charset dependent: this MUST be
"Yes"or"No"depending on whether the attribute value is subject to the "a=charset:" attribute. 💖 - Purpose: an explanation of the purpose and usage of the attribute. ⭐
- O/A procedures: offer/answer procedures as explained in [RFC3264]. 🍓
- Mux Category: this MUST indicate one of the following categories:
NORMAL,NOT RECOMMENDED,IDENTICAL,SUM,TRANSPORT,INHERIT,IDENTICAL-PER-PT,SPECIAL, orTBDas defined by [RFC8859]. 👑 - Reference: a reference to the specification defining the attribute. 🔥
The above is the minimum that IANA will accept. Attributes that are expected to see widespread use and interoperability SHOULD be documented with a Standards Track RFC that specifies the attribute more precisely. 🌈
Submitters of registrations should ensure that the specification is in the spirit of SDP attributes, most notably that the attribute is platform independent in the sense that it makes no implicit assumptions about operating systems and does not name specific pieces of software in a manner that might inhibit interoperability. 🫶
Submitters of registrations should also carefully choose the attribute usage level. They should not choose only "session" when the attribute can have different values when media is disaggregated, i.e., when each "m=" section has its own IP address on a different endpoint. In that case, the attribute type chosen should be "session, media" or "media" (depending on desired semantics). The default rule is that for all new SDP attributes that can occur both in session and media level, the media level overrides the session level. When this is not the case for a new SDP attribute, it MUST be explicitly stated. 💅
IANA has registered the initial set of attribute names (<attribute-name> values) with definitions as in Section 6 of this memo (these definitions replace those in [RFC4566]). ✨
8.2.4.2. Updates to Existing Attributes 🔄
Updated attribute registrations are accepted according to the "Specification Required" policy of [RFC8126].
The Designated Expert reviewing the update is requested to evaluate whether the update is compatible with the prior intent and use of the attribute, and whether the new document is of sufficient maturity and authority in relation to the prior document. 🧐
The specification updating the attribute (for example, by adding a new value) MUST update registration information items from Section 8.2.4.1 according to the following constraints:
- Contact name: a name for an entity responsible for the update MUST be provided.
- Contact email address: an email address for an entity responsible for the update MUST be provided.
- Attribute name: MUST be provided and MUST NOT be changed. Otherwise it is a new attribute. 🚫
- Attribute syntax: the existing rule syntax with the syntax extensions MUST be provided if there is a change to the syntax. A revision to an existing attribute usage MAY extend the syntax of an attribute, but MUST be backward compatible. 🌷
- Attribute semantics: a semantic description of new additional attribute values or a semantic extension of existing values. Existing attribute values semantics MUST only be extended in a backward compatible manner. 🍭
- Usage level: updates MAY only add additional levels. 🎈
- Charset dependent: MUST NOT be changed. 🙅♀️
- Purpose: MAY be extended according to the updated usage. 💜
- O/A procedures: MAY be updated in a backward compatible manner and/or it applies to a new usage level only. 🦋
- Mux Category: no change unless from "TBD" to another value (see [RFC8859]. It MAY also change if media level is being added to the definition of an attribute that previously did not include it. 🌸
- Reference: a new (additional or replacement) reference MUST be provided. 📚
Items SHOULD be omitted if there is no impact to them as a result of the attribute update. 🌟
8.2.5. Bandwidth Specifiers (<bwtype>) 📶
A proliferation of bandwidth specifiers is strongly discouraged. 🙈
New bandwidth specifiers (<bwtype> subfield values) MUST be registered with IANA. The submission MUST reference a Standards Track RFC specifying the semantics of the bandwidth specifier precisely, and indicating when it should be used, and why the existing registered bandwidth specifiers do not suffice. 💅
The RFC MUST specify the Mux Category for this value as defined by [RFC8859]. 🎀
The format of the <bwtype> registry is:
+======+==========+==============+===========+
| Type | SDP Name | Mux Category | Reference |
+======+==========+==============+===========+Table 6: Format of the <bwtype> Registry
IANA has updated the <bwtype> registry entries for the bandwidth specifiers "CT" and "AS" with the definitions in Section 5.8 of this memo (these definitions replace those in [RFC4566]). ✨
8.2.6. Network Types (<nettype>) 🌐
Network type "IN", representing the Internet, is defined in Section 5.2 and Section 5.7 of this memo (this definition replaces that in [RFC4566]). 🌍
To enable SDP to reference a new non-Internet environment, a new network type (<nettype> subfield value) MUST be registered with IANA. The registration is subject to the "RFC Required" policy of [RFC8126]. Although non-Internet environments are not normally the preserve of IANA, there may be circumstances when an Internet application needs to interoperate with a non-Internet application, such as when gatewaying an Internet telephone call into the Public Switched Telephone Network (PSTN). The number of network types should be small and should be rarely extended. A new network type registration MUST reference an RFC that gives details of the network type and the address type(s) that may be used with it. 📞
The format of the <nettype> registry is:
+======+==========+========================+===========+
| Type | SDP Name | Usable addrtype Values | Reference |
+======+==========+========================+===========+Table 7: Format of the <nettype> Registry
IANA has updated the <nettype> registry to this new format. The following is the updated content of the registry:
+=========+==========+========================+===========+
| Type | SDP Name | Usable addrtype Values | Reference |
+=========+==========+========================+===========+
| nettype | IN | IP4, IP6 | [RFC8866] |
+---------+----------+------------------------+-----------+
| nettype | TN | RFC2543 | [RFC2848] |
+---------+----------+------------------------+-----------+
| nettype | ATM | NSAP, GWID, E164 | [RFC3108] |
+---------+----------+------------------------+-----------+
| nettype | PSTN | E164 | [RFC7195] |
+---------+----------+------------------------+-----------+Table 8: Content of the <nettype> registry
Note that both [RFC7195] and [RFC3108] registered "E164" as an address type, although [RFC7195] mentions that the "E164" address type has a different context for ATM and PSTN networks. 🤔
8.2.7. Address Types (<addrtype>) 🏠
New address types (<addrtype>) MUST be registered with IANA. The registration is subject to the "RFC Required" policy of [RFC8126]. A new address type registration MUST reference an RFC, giving details of the syntax of the address type. Address types are not expected to be registered frequently. 🌙
Section 5.7 of this document gives new definitions of address types "IP4" and "IP6". 💫
8.3. Encryption Key Access Methods (OBSOLETE) 🗝️
The IANA previously maintained a table of SDP encryption key access method ("enckey") names. This table is obsolete, since the "k=" line is not extensible. New registrations MUST NOT be accepted. 🪦
9. SDP Grammar ✨
okay bestie, this is the part where SDP shows us the full blueprint 📐💅 It's written in Augmented BNF (ABNF), which is defined in [RFC5234] and [RFC7405]. Every line below is the exact grammar, so read it like a recipe and don't tweak a single character 🫶
; SDP Syntax
session-description = version-field
origin-field
session-name-field
[information-field]
[uri-field]
*email-field
*phone-field
[connection-field]
*bandwidth-field
1*time-description
[key-field]
*attribute-field
*media-description
version-field = %s"v" "=" 1*DIGIT CRLF
;this memo describes version 0
origin-field = %s"o" "=" username SP sess-id SP sess-version SP
nettype SP addrtype SP unicast-address CRLF
session-name-field = %s"s" "=" text CRLF
information-field = %s"i" "=" text CRLF
uri-field = %s"u" "=" uri CRLF
email-field = %s"e" "=" email-address CRLF
phone-field = %s"p" "=" phone-number CRLF
connection-field = %s"c" "=" nettype SP addrtype SP
connection-address CRLF
;a connection field must be present
;in every media description or at the
;session level
bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF
time-description = time-field
[repeat-description]
repeat-description = 1*repeat-field
[zone-field]
time-field = %s"t" "=" start-time SP stop-time CRLF
repeat-field = %s"r" "=" repeat-interval SP typed-time
1*(SP typed-time) CRLF
zone-field = %s"z" "=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time) CRLF
key-field = %s"k" "=" key-type CRLF
attribute-field = %s"a" "=" attribute CRLF
media-description = media-field
[information-field]
*connection-field
*bandwidth-field
[key-field]
*attribute-field
media-field = %s"m" "=" media SP port ["/" integer]
SP proto 1*(SP fmt) CRLF
; sub-rules of 'o='
username = non-ws-string
;pretty wide definition, but doesn't
;include space
sess-id = 1*DIGIT
;should be unique for this username/host
sess-version = 1*DIGIT
nettype = token
;typically "IN"
addrtype = token
;typically "IP4" or "IP6"
; sub-rules of 'u='
uri = URI-reference
; see RFC 3986
; sub-rules of 'e=', see RFC 5322 for definitions
email-address = address-and-comment / dispname-and-address
/ addr-spec
address-and-comment = addr-spec 1*SP "(" 1*email-safe ")"
dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">"
; sub-rules of 'p='
phone-number = phone *SP "(" 1*email-safe ")" /
1*email-safe "<" phone ">" /
phone
phone = ["+"] DIGIT 1*(SP / "-" / DIGIT)
; sub-rules of 'c='
connection-address = multicast-address / unicast-address
; sub-rules of 'b='
bwtype = token
bandwidth = 1*DIGIT
; sub-rules of 't='
start-time = time / "0"
stop-time = time / "0"
time = POS-DIGIT 9*DIGIT
; Decimal representation of time in
; seconds since January 1, 1900 UTC.
; The representation is an unbounded
; length field containing at least
; 10 digits. Unlike some representations
; used elsewhere, time in SDP does not
; wrap in the year 2036.
; sub-rules of 'r=' and 'z='
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
typed-time = 1*DIGIT [fixed-len-time-unit]
fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s"
; NOTE: These units are case-sensitive.
; sub-rules of 'k='
key-type = %s"prompt" /
%s"clear:" text /
%s"base64:" base64 /
%s"uri:" uri
; NOTE: These names are case-sensitive.
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = ALPHA / DIGIT / "+" / "/"
; sub-rules of 'a='
attribute = (attribute-name ":" attribute-value) /
attribute-name
attribute-name = token
attribute-value = byte-string
att-field = attribute-name ; for backward compatibility
; sub-rules of 'm='
media = token
;typically "audio", "video", "text", "image"
;or "application"
fmt = token
;typically an RTP payload type for audio
;and video media
proto = token *("/" token)
;typically "RTP/AVP", "RTP/SAVP", "udp",
;or "RTP/SAVPF"
port = 1*DIGIT
; generic sub-rules: addressing
unicast-address = IP4-address / IP6-address / FQDN / extn-addr
multicast-address = IP4-multicast / IP6-multicast / FQDN
/ extn-addr
IP4-multicast = m1 3( "." decimal-uchar )
"/" ttl [ "/" numaddr ]
; IP4 multicast addresses may be in the
; range 224.0.0.0 to 239.255.255.255
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
("23" DIGIT )
IP6-multicast = IP6-address [ "/" numaddr ]
; IP6 address starting with FF
numaddr = integer
ttl = (POS-DIGIT *2DIGIT) / "0"
FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)
IP4-address = b1 3("." decimal-uchar)
b1 = decimal-uchar
; less than "224"
IP6-address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IP4-address
; Generic for other address families
extn-addr = non-ws-string
; generic sub-rules: datatypes
text = byte-string
;default is to interpret this as UTF8 text.
;ISO 8859-1 requires "a=charset:ISO-8859-1"
;session-level attribute to be used
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;any byte except NUL, CR, or LF
non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters
token-char = ALPHA / DIGIT
/ "!" / "#" / "$" / "%" / "&"
/ "'" ; (single quote)
/ "*" / "+" / "-" / "." / "^" / "_"
/ "`" ; (Grave accent)
/ "{" / "|" / "}" / "~"
token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting
;characters ()<>
integer = POS-DIGIT *DIGIT
zero-based-integer = "0" / integer
non-zero-int-or-real = integer / non-zero-real
non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT
; generic sub-rules: primitives
alpha-numeric = ALPHA / DIGIT
POS-DIGIT = %x31-39 ; 1 - 9
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
; external references:
ALPHA = <ALPHA definition from RFC 5234>
DIGIT = <DIGIT definition from RFC 5234>
CRLF = <CRLF definition from RFC 5234>
HEXDIG = <HEXDIG definition from RFC 5234>
SP = <SP definition from RFC 5234>
VCHAR = <VCHAR definition from RFC 5234>
URI-reference = <URI-reference definition from RFC 3986>
addr-spec = <addr-spec definition from RFC 5322>⚠️ the grammar above is the spec itself, so if you're ever unsure, go back to these exact lines. no vibes-based parsing, bestie 🙈
10. Summary of Changes from RFC 4566 💅
Okay bestie, here's the full glow-up list from RFC 4566 🦋 Every single bullet is a real change, so don't skip any 🫶
- Terminology got a major tidy-up ✨ The text now lines up with the ABNF.
<attribute>,<att-field>, and "att-field" are now<attribute-name>.<value>and<att-value>are now<attribute-value>. "media" is now<media>💖 - Some items are now obsolete 🙈
a=cat:(Section 6.1),a=keywds:(Section 6.2), andk=(Section 5.12) are all retired. - The normative and informative references got updated, and some extra related RFCs were added 📚
- The SDP Attributes section (Section 6) got reformatted so it's easier to read 🎀 The syntax of attribute values is now written in ABNF, which is so clean 😭
- Sending RTCP with inactive media streams is now mandatory (Section 6.7.4) 🔥
- The "Private Sessions" section got removed 🌸 It dated back to when SDP was mostly used with SAP (Session Announcement Protocol), and SAP has basically fallen out of use. Now the vast majority of uses of SDP is for establishment of private sessions. The considerations for that live in Section 7 now 💜
- The
a=lang:(Section 6.12) anda=sdplang:(Section 6.11) attributes got expanded and clarified ✨ - Some SAP references were removed, since nobody's really using it widely anymore 🧚
- The way
<fmt>values for UDP transport get registered changed (Section 8.2.3) 🦋 - The mechanism and documentation needed to register new attributes changed (Section 8.2.4.1) 💅
- IANA registration procedures for extensions got tightened up 👑 Phone number and long-form name were removed (Section 8.2).
- The IANA
<nettype>registry now identifies valid<addrtype>subfields (Section 8.2.6) 🌈 - The several IANA "att-field" registries got reorganized into one single
<attribute-name>registry (Section 8.2.4) 🫶 - The ABNF syntax (Section 9) got revised for clarity and for alignment with the text 🎀 Backward compatibility is kept, with a few exceptions. The big ones:
- The syntax of time descriptions (
t=,r=,z=) got revised to remove ambiguities. It's now clarified thatz=only modifies the immediately precedingr=lines. Az=without a precedingr=is now a syntax error (Section 5.11). This is incompatible with certain aberrant usage 💀 - The
IP6-addressandIP6-multicastrules got updated to match the syntax in [RFC3986], mirroring a bug fix made to [RFC3261] by [RFC5954]. Rules that were unused after this change got removed ✨ - The
att-fieldrule got renamedattribute-name, because elsewhere "*-field" always refers to a complete line. The rulenameatt-fieldis still defined as a synonym for backward compatibility with references from other RFCs 🙈 - The
att-valuerule got renamedattribute-value💖
- The syntax of time descriptions (
- Normative statements that were redundant with the ABNF syntax got revised, which makes the text non-normative 📝
- The IPv4 unicast and multicast addresses in the example SDP descriptions were revised per [RFC5735] and [RFC5771] 🌸
- Some examples now use IPv6 addresses, and extra IPv6 examples got added 🧚
- The case-insensitivity rules from [RFC4855] got incorporated 💜
- Sections that incorrectly referenced NTP got revised (Section 5.2, Section 5.9, Section 5.10, and Section 5.11) ⭐
- The explanation of the impact and use of the
a=charset:attribute got clarified (Section 6.10) 🦋 - The description of the
a=type:attribute got revised to remove the implication that it sometimes changes the default media direction to something other thana=sendrecv(Section 6.9) 💅
11. References 📚
11.1. Normative References
- [E164] International Telecommunication Union, "E.164 : The international public telecommunication numbering plan", ITU Recommendation E.164, November 2010, <https://www.itu.int/rec/T-REC-E.164-201011-I/en>.
- [ISO.8859-1.1998] International Organization for Standardization, "Information technology - 8-bit single byte coded graphic - character sets - Part 1: Latin alphabet No. 1, JTC1/ SC2", ISO/IEC Standard 8859-1, 1998.
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
- [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
- [RFC2848] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, DOI 10.17487/RFC2848, June 2000, <https://www.rfc-editor.org/info/rfc2848>.
- [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <https://www.rfc-editor.org/info/rfc2978>.
- [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, DOI 10.17487/RFC3108, May 2001, <https://www.rfc-editor.org/info/rfc3108>.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
- [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
- [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
- [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <https://www.rfc-editor.org/info/rfc5576>.
- [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
- [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
- [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
- [RFC7195] Garcia-Martin, M. and S. Veikkolainen, "Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)", RFC 7195, DOI 10.17487/RFC7195, May 2014, <https://www.rfc-editor.org/info/rfc7195>.
- [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
- [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
- [RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021, <https://www.rfc-editor.org/info/rfc8859>.
- [RFC8864] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, Ed., "Negotiation Data Channels Using the Session Description Protocol (SDP)", RFC 8864, DOI 10.17487/RFC8864, January 2021, <https://www.rfc-editor.org/info/rfc8864>.
11.2. Informative References ✨
Okay, now the bonus round: the informative references! These aren't strictly required to implement SDP, but they're the babes that give the spec its backstory 💅
[ITU.H332.1998]International Telecommunication Union, "H.332 : H.323 extended for loosely coupled conferences", ITU Recommendation H.332, September 1998,<https://www.itu.int/rec/T-REC-H.332-199809-I/en>.[RFC2045]Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,<https://www.rfc-editor.org/info/rfc2045>.[RFC2327]Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998,<https://www.rfc-editor.org/info/rfc2327>.[RFC2974]Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000,<https://www.rfc-editor.org/info/rfc2974>.[RFC3261]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002,<https://www.rfc-editor.org/info/rfc3261>.[RFC3264]Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002,<https://www.rfc-editor.org/info/rfc3264>.[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003,<https://www.rfc-editor.org/info/rfc3550>.[RFC3551]Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003,<https://www.rfc-editor.org/info/rfc3551>.[RFC3556]Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003,<https://www.rfc-editor.org/info/rfc3556>.[RFC3605]Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003,<https://www.rfc-editor.org/info/rfc3605>.[RFC3711]Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004,<https://www.rfc-editor.org/info/rfc3711>.[RFC3840]Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004,<https://www.rfc-editor.org/info/rfc3840>.[RFC3890]Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, DOI 10.17487/RFC3890, September 2004,<https://www.rfc-editor.org/info/rfc3890>.[RFC4568]Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,<https://www.rfc-editor.org/info/rfc4568>.[RFC4855]Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,<https://www.rfc-editor.org/info/rfc4855>.[RFC5124]Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008,<https://www.rfc-editor.org/info/rfc5124>.[RFC5322]Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008,<https://www.rfc-editor.org/info/rfc5322>.[RFC5735]Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", RFC 5735, DOI 10.17487/RFC5735, January 2010,<https://www.rfc-editor.org/info/rfc5735>.[RFC5771]Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010,<https://www.rfc-editor.org/info/rfc5771>.[RFC5888]Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010,<https://www.rfc-editor.org/info/rfc5888>.[RFC5954]Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., "Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010,<https://www.rfc-editor.org/info/rfc5954>.[RFC6466]Salgueiro, G., "IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)", RFC 6466, DOI 10.17487/RFC6466, December 2011,<https://www.rfc-editor.org/info/rfc6466>.[RFC6838]Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013,<https://www.rfc-editor.org/info/rfc6838>.[RFC7230]Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014,<https://www.rfc-editor.org/info/rfc7230>.[RFC7405]Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014,<https://www.rfc-editor.org/info/rfc7405>.[RFC7656]Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015,<https://www.rfc-editor.org/info/rfc7656>.[RFC7826]Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016,<https://www.rfc-editor.org/info/rfc7826>.[RFC8445]Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018,<https://www.rfc-editor.org/info/rfc8445>.[RFC8839]Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, A., and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, January 2021,<https://www.rfc-editor.org/info/rfc8839>.[RFC8843]Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021,<https://www.rfc-editor.org/info/rfc8843>.
Acknowledgements 🙌
Huge thank-yous to everyone in the IETF Multiparty Multimedia Session Control (MMUSIC) working group! Loads of people sent comments and suggestions that helped shape this document, and the crew below deserves a standing ovation 👏🫶
Special shout-outs go to these legends, who helped create this document or one of its predecessors: Adam Roach, Allison Mankin, Bernie Hoeneisen, Bill Fenner, Carsten Bormann, Eve Schooler, Flemming Andreasen, Gonzalo Camarillo, Jörg Ott, John Elwell, Jon Peterson, Jonathan Lennox, Jonathan Rosenberg, Keith Drage, Peter Parnes, Rob Lanphier, Ross Finlayson, Sean Olson, Spencer Dawkins, Steve Casner, Steve Hanna, Van Jacobson. 💜
Authors' Addresses 🎀
Meet the authors! Here's how to reach each of them 💌
Ali Begen
Networked Media
Turkey
Email: ali.begen@networked.mediaPaul Kyzivat
United States of America
Email: pkyzivat@alum.mit.eduColin Perkins
University of Glasgow
School of Computing Science
Glasgow
G12 8QQ
United Kingdom
Email: csp@csperkins.orgMark Handley
University College London
Department of Computer Science
London
WC1E 6BT
United Kingdom
Email: M.Handley@cs.ucl.ac.uk📦 where this page comes from
- ietf: rfc8866 2021-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms