RFC 2327

SDP: Session Description Protocol

📅 published April 1998, from ietf

RFC 2327 💖 SDP: Session Description Protocol

okay bestie, this is RFC 2327 🎀, titled "SDP: Session Description Protocol." It's by M. Handley and V. Jacobson, both from ISI/LBNL 👑. It's a Standards Track doc, dated April 1998 📅. The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there ✨.

Status of this Memo ✨

This doc specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Copyright Notice 🎀

Abstract 🦋

SDP is the Session Description Protocol, and this doc defines it 💖. It's built for describing multimedia sessions so people can announce them, invite others to them, and start other kinds of multimedia sessions 🎬.

This doc is a product of the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force 🫶. Comments are wanted, and they should go to the working group's mailing list at confctrl@isi.edu and/or to the authors 📬.

1. Introduction ✨

okay so on the Internet multicast backbone (Mbone) 🌸, people use a session directory tool to advertise multimedia conferences. That tool also shares the conference addresses and the tool-specific info you need to join 🧚. This doc defines a session description protocol for exactly that job, and for real-time multimedia session descriptions in general 💜. It does not go into detail on multicast address allocation or on how SDP messages get distributed. Those are covered in accompanying memos 📎. And SDP is not for negotiating media encodings, so don't come here for that 🙈.

2. Background 🌈

The Mbone is the part of the internet that supports IP multicast, which makes efficient many-to-many communication possible 🔥. It gets used a LOT for multimedia conferencing 💅. These conferences usually don't need tight control over who's a member. To receive one, a user at an Mbone site just needs the conference's multicast group address and the UDP ports for its data streams ✨.

Session directories help advertise conference sessions and pass along the setup info prospective participants need 🦋. SDP is designed to carry that info to recipients 💖. SDP is purely a format for describing sessions. It doesn't include a transport protocol, and it's meant to work with different transport protocols depending on what fits, including the Session Announcement Protocol [4], the Session Initiation Protocol [11], the Real-Time Streaming Protocol [12], electronic mail using the MIME extensions, and the Hypertext Transport Protocol 🎀.

SDP is meant to be general purpose, so it can work in a wider range of network environments and applications than just multicast session directories 🌟. It's still not meant to negotiate session content or media encodings, since that's considered outside the scope of session description 🙅‍♀️.

3. Glossary of Terms 📖

These terms show up in this doc and have specific meanings inside it 💜.

Conference: A multimedia conference is a set of two or more communicating users, plus the software they're using to communicate 🎤.
Session: A multimedia session is a set of multimedia senders and receivers, along with the data streams flowing from senders to receivers 🌸. A multimedia conference is one example of a multimedia session ✨.
Session Advertisement: See session announcement 📣.
Session Announcement: A session announcement is a mechanism for conveying a session description to users proactively. In other words, the user never explicitly asked for that session description 💌.
Session Description: A well defined format for conveying enough information to discover and participate in a multimedia session 🦋.

3.1. Terminology 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 🔑.

4. SDP Usage 🎀

4.1. Multicast Announcements 📡

SDP is a session description protocol for multimedia sessions 🎬. A really common way to use it is for a client to announce a conference session. It does this by periodically multicasting an announcement packet to a well known multicast address and port, using the Session Announcement Protocol (SAP) 🧚.

SAP packets are UDP packets with the following format 💖:

         |--------------------|
         | SAP header         |
         |--------------------|
         | text payload       |
         |//////////

The header is the Session Announcement Protocol header 🫶. SAP gets described in more detail in a companion memo [4] 📚.

The text payload is an SDP session description, as described in this memo ✨. The text payload should be no greater than 1 Kbyte in length 🍓. If it's announced by SAP, only one session announcement is permitted in a single packet 🙈.

4.2. Email and WWW Announcements 💌

There are other ways to convey session descriptions too, like electronic mail and the World Wide Web 🌈. For both email and WWW distribution, the MIME content type "application/sdp" should be used 🎀. That's what lets the WWW client or mail reader automatically launch applications to join the session in a standard way ✨.

Heads up though: announcements of multicast sessions made only via email or the World Wide Web (WWW) don't guarantee the receiver can actually get the session 😭. That's because multicast sessions might be restricted in scope, while access to the WWW server or receiving email can happen outside that scope 🌍. SAP announcements don't have this mismatch 💜.

5. Requirements and Recommendations 👑

The whole point of SDP is to convey information about media streams in multimedia sessions 🦋. That way, the people receiving a session description can join the session 💖. SDP is mainly meant for use in an internetwork, but it's general enough to describe conferences in other network environments too 🌸.

For these purposes, a multimedia session is a set of media streams that exist for some length of time 🕰️. Media streams can be many-to-many 🔁. The times when the session is active don't have to be continuous ✨.

Multicast-based sessions on the Internet have been different from a lot of other conferencing, because anyone receiving the traffic can join the session (unless the session traffic is encrypted) 🔓. In that kind of environment, SDP has two main jobs 🎀. First, it communicates that a session exists. Second, it carries enough info to join and take part in the session 🧚. In a unicast environment, only the second job is likely to matter 💅.

So SDP includes:

Session name and purpose 🏷️
Time(s) the session is active ⏰
The media comprising the session 🎥
Information to receive those media (addresses, ports, formats and so on) 📦

Since resources needed to take part in a session may be limited, some extra info might also be useful 🌷:

Information about the bandwidth to be used by the conference 📶
Contact information for the person responsible for the session 💌

In general, SDP must convey enough info to join a session (with the possible exception of encryption keys) 🔐. It also has to announce the resources the session will use, for non-participants who might need to know 👀.

5.1. Media Information 🎥

SDP includes:

The type of media (video, audio, etc) 🎬
The transport protocol (RTP/UDP/IP, H.320, etc) 🚚
The format of the media (H.261 video, MPEG video, etc) 🎞️

For an IP multicast session, these are also conveyed:

Multicast address for media 📡
Transport Port for media 🔌

This address and port are the destination address and destination port of the multicast stream. That's true whether the stream is being sent, received, or both 🫶.

For an IP unicast session, these are conveyed instead:

Remote address for media 🏠
Transport port for contact address 📮

What this address and port mean depends on the media and transport protocol defined ✨. By default, it's the remote address and remote port the data gets sent to, plus the remote address and local port to receive data on 💖. Some media might instead use these to set up a control channel for the actual media flow 🎛️.

5.2. Timing Information ⏰

Sessions may be bounded or unbounded in time 🌙. Whether or not they're bounded, they may only be active at specific 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 the local time zone or daylight saving time 🌍✨.

5.3. Private Sessions 🕵️‍♀️

It's possible to create both public sessions and private sessions 🌸. Private sessions are typically conveyed by encrypting the session description before it's distributed 🔐. The details of how encryption works depend on the mechanism used to convey SDP. For how this is done with session announcements, see [4] 📚.

If a session announcement is private, you can use that private announcement to convey the encryption keys needed to decode each media in a conference 🗝️. It can also include enough info to know which encryption scheme is used for each media 💜.

5.4. Obtaining Further Information about a Session 🔍

A session description should convey enough info to decide whether or not to participate in a session 🤔. SDP may include extra pointers, in the form of Universal Resources Identifiers (URIs), for more info about the session 🔗.

5.5. Categorisation 🗂️

When lots of session descriptions are being distributed by SAP or any other advertisement mechanism, it may be useful to filter the announcements you're interested in from the ones you aren't 🧹. SDP supports a categorisation mechanism for sessions that can be automated 🤖✨.

5.6. Internationalization 🌏

The SDP specification recommends using the ISO 10646 character sets in the UTF-8 encoding (RFC 2044) so lots of different languages can be represented 🌈. To keep representations compact, SDP also allows other character sets, like ISO 8859-1, when you want them 🍓. Internationalization only applies to free-text fields (session name and background information), and not to SDP as a whole 💅.

6. SDP Specification ✨

okay bestie, this is where SDP gets into the nitty gritty 💅 SDP session descriptions are entirely textual, written in the ISO 10646 character set with UTF-8 encoding 🦋 Field names and attribute names only use the US-ASCII subset of UTF-8, but the textual fields and attribute values can use the full ISO 10646 character set ✨

why text and not binary like ASN/1 or XDR? because text is more portable 🌈 it lets SDP travel over different transports (like a session description inside a MIME email message) 💌 and it lets flexible text-based toolkits (e.g., Tcl/Tk ) generate and process session descriptions 🧚

BUT the total bandwidth for all SAP announcements is strictly limited, so the encoding is deliberately compact 🍓 announcements can also travel by super unreliable means (e.g., email) or get damaged by an intermediate caching server 💀 so the encoding has strict order and formatting rules. most errors end up as malformed announcements that are easy to spot and toss 🗑️ this also means encrypted announcements can be discarded quickly when the receiver doesn't have the correct key 🔐

An SDP session description is a bunch of lines of text in the form <type>=<value>. The <type> is always exactly one character and it's case-significant, so capital and lowercase letters are different things, bestie 🙈 The <value> is a structured text string whose format depends on the <type>. It's also case-significant unless a specific field says otherwise. Whitespace is not permitted on either side of the = sign. Generally <value> is either a number of fields separated by a single space, or a free format string 🎀

A session description has a session-level description (details that apply to the whole session and all of its media streams) and optionally several media-level descriptions (details that apply to a single media stream) 🫶

An announcement is a session-level section followed by zero or more media-level sections. The session-level part starts with a v= line and runs up to the first media-level section. A media description starts with an m= line and runs until the next media description or the end of the whole session description. Generally, session-level values are the defaults for all media unless a media-level value overrides them 👑

When SDP is conveyed by SAP, only one session description is allowed per packet. When SDP is conveyed by other means, many session descriptions can be concatenated together (the v= line marks the start of a session description and ends the previous one) ✨ Some lines are required and some are optional, but all of them must appear in exactly the order given here. that fixed order is honestly iconic because it boosts error detection and keeps the parser simple 💅 Optional items are marked with a *.

Here's the full lineup:

Session description
        v=  (protocol version)
        o=  (owner/creator 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)
        b=* (bandwidth information)
        One or more time descriptions (see below)
        z=* (time zone adjustments)
        k=* (encryption key)
        a=* (zero or more session attribute lines)
        Zero or more media descriptions (see below)

Time description
        t=  (time the session is active)
        r=* (zero or more repeat times)

Media description
        m=  (media name and transport address)
        i=* (media title)
        c=* (connection information - optional if included at session-level)
        b=* (bandwidth information)
        k=* (encryption key)
        a=* (zero or more media attribute lines)

The set of type' letters is deliberately small and not meant to be extensible, so SDP parsers must completely ignore any announcement that contains a type' letter they don't understand 🙅‍♀️ The attribute mechanism ("a=" described below) is the main way to extend SDP and tailor it to particular applications or media 🦋 Some attributes (the ones listed in this document) have a defined meaning, but others can be added on an application-, media- or session-specific basis. A session directory must ignore any attribute it doesn't understand 🧠

The connection (c=') and attribute (a=') information in the session-level section applies to all the media of that session, unless it's overridden by connection information or an attribute with the same name in the media description. For example, in the session below, each media behaves as if it were given a `recvonly' attribute 🌸

An example SDP description looks like this:

v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb
a=orient:portrait

Text records like the session name and information are byte strings that can contain any byte except 0x00 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a record, although parsers should be tolerant and also accept records terminated with a single newline character 🫧 By default these byte strings contain ISO-10646 characters in UTF-8 encoding, but that default can be changed using the `charset' attribute 🌈

Protocol Version

the v= field tells you the version of the Session Description Protocol 💖

v=0

There is no minor version number, so it's just the one number 🍓

Origin

the o= field is the originator of the session. it has their username, the address of their host, a session id and a session version number 🎀

o=<username> <session id> <version> <network type> <address type>
<address>

<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. <username> must not contain spaces 🙈 <session id> is a numeric string, and the tuple of <username>, <session id>, <network type>, <address type> and <address> forms a globally unique identifier for the session 🔑

The method for allocating <session id> is up to the creating tool, but it has been suggested that a Network Time Protocol (NTP) timestamp be used to ensure uniqueness [1] ⏰

<version> is a version number for this announcement. it's needed so proxy announcements can detect which of several announcements for the same session is the most recent 👀 Again, its usage is up to the creating tool, as long as <version> goes up whenever the session data is modified. Again, it is recommended (but not mandatory) that an NTP timestamp is used 🧁

<network type> is a text string giving the type of network. Initially "IN" is defined to mean "Internet" 🌐 <address type> is a text string giving the type of the address that follows. Initially "IP4" and "IP6" are defined 🦋

<address> is the globally unique address of the machine the session was created from. For an address type of IP4, this is either the fully-qualified domain name of the machine, or the dotted-decimal representation of its IP version 4 address. For an address type of IP6, this is either the fully-qualified domain name of the machine, or the compressed textual representation of its IP version 6 address. For both IP4 and IP6, the fully-qualified domain name is the form that SHOULD be given unless it's unavailable, in which case the globally unique address may be substituted 💅 A local IP address MUST NOT be used in any context where the SDP description might leave the scope in which the address is meaningful ⚠️

In general, the o= field works as a globally unique identifier for this version of this session description, and the subfields (excluding the version) together identify the session no matter what modifications are made to it 🫶

Session Name

s=<session name>

the s= field is the session name, and it's a main character moment 🎬 There must be one and only one s= field per session description, and it must contain ISO 10646 characters (but see also the `charset' attribute below) 👑

Session and Media Information

i=<session description>

the i= field is information about the session 🌸 There may be at most one session-level i= field per session description, and at most one i= field per media. Although it may be omitted, this is discouraged for session announcements, and user interfaces for composing sessions should require text to be entered 📝 If it's present, it must contain ISO 10646 characters (but see also the `charset' attribute below) 🌈

a single i= field can also be used for each media definition. In media definitions, i= fields are mainly meant for labeling media streams 🏷️ So they're most useful when one session has more than one distinct media stream of the same media type. For example, two different whiteboards, one for slides and one for feedback and questions 🧚

URI

u=<URI>

A URI is a Universal Resource Identifier as used by WWW clients 🌐
The URI should be a pointer to additional information about the conference ✨
This field is optional, but if it is present it should be specified before the first media field 💖
No more than one URI field is allowed per session description 🙅‍♀️

Email Address and Phone Number

e=<email address>
p=<phone number>

these fields give contact info for the person responsible for the conference 📞 It's not necessarily the same person who created the conference announcement, so don't mix them up, bestie 🫣

These specify contact information for the person responsible for the conference. This is not necessarily the same person that created the conference announcement 💌
Either an email field or a phone field must be specified. Additional email and phone fields are allowed 📱
If these are present, they should be specified before the first media field 🎀
More than one email or phone field can be given for a session description 🧁
Phone numbers should be given in the conventional international format, preceded by a "+" and the international country code. There must be a space or a hyphen ("-") between the country code and the rest of the phone number. Spaces and hyphens can be used to split up a phone field to aid readability if you want 🌍 For example:

p=+44-171-380-7777 or p=+1 617 253 6011

Both email addresses and phone numbers can have an optional free text string attached, normally giving the name of the person who may be contacted. This should be enclosed in parentheses if it's present 🫶 For example:

e=mjh@isi.edu (Mark Handley)

The alternative RFC822 name quoting convention is also allowed for both email addresses and phone numbers 💅 For example:

e=Mark Handley <mjh@isi.edu>

The free text string should be in the ISO-10646 character set with UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if the appropriate charset session-level attribute is set 🌈

Connection Data

c=<network type> <address type> <connection address>

the c= field contains connection data 🦋

okay so every session announcement needs a c= field in each media description, or a c= field at the session-level 🎀 it can also have a session-level one plus one extra per media, and when it does, the per-media values win for that media ✨

The first sub-field is the network type 🌐, a text string saying what kind of network we're talking about. For now "IN" is defined to mean "Internet" 💖

The second sub-field is the address type 🦋 This is what lets SDP work for sessions that aren't IP based. Only IP4 is defined so far.

The third sub-field is the connection address 🧚 Optional extra subfields can come after it, depending on what the address type is.

For IP4 addresses, the connection address works like this:

Typically the connection address is a class-D IP multicast group address 💜 If the session isn't multicast, the connection address holds the fully-qualified domain name or the unicast IP address of the expected data source, data relay, or data sink, as determined by the additional attribute fields. It's not expected that fully-qualified domain names or unicast addresses will show up in a session description sent over a multicast announcement, but that isn't prohibited 🙈 If a unicast data stream is going to pass through a network address translator, using a fully-qualified domain name instead of a unicast IP address is RECOMMENDED 🌸 In other cases, an IP address might be required to pick out a particular interface on a multi-homed host. So this spec leaves the choice up to each application, but all applications MUST be able to cope with receiving both formats 👑
Conferences using an IP 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 conference will be sent with. TTL values must be in the range 0-255 ✨

The TTL for the session gets appended to the address using a slash as a separator. An example is:

c=IN IP4 224.2.1.1/127

Hierarchical or layered encoding schemes are data streams where the encoding from a single media source is split into a number of layers. The receiver can pick the quality (and therefore the bandwidth) it wants by only subscribing to a subset of those layers. These layered encodings are normally sent over multiple multicast groups so that multicast pruning can happen 🦋 That keeps unwanted traffic away from sites that only need certain levels of the hierarchy. For applications that need multiple multicast groups, this 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 contiguously allocated above the base address, so for example:

c=IN IP4 224.2.1.1/127/3

would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to be used at a ttl of 127. This is semantically identical to including multiple "c=" lines in a media description:

c=IN IP4 224.2.1.1/127
c=IN IP4 224.2.1.2/127
c=IN IP4 224.2.1.3/127

Multiple addresses or "c=" lines can only be specified on a per-media basis, and not for a session-level "c=" field 🙅‍♀️

It is illegal for the slash notation described above to be used for IP unicast addresses 💀

Bandwidth

b=<modifier>:<bandwidth-value>

This specifies the proposed bandwidth to be used by the session or media, and it's optional 🍓
<bandwidth-value> is in kilobits per second
<modifier> is a single alphanumeric word that gives the meaning of the bandwidth figure.
Two modifiers are initially defined:
CT Conference Total: an implicit maximum bandwidth is associated with each TTL on the Mbone or within a particular multicast administrative scope region (the Mbone bandwidth vs. TTL limits are given in the MBone FAQ) 🌈 If the bandwidth of a session or media in a session is different from the bandwidth implicit from the scope, a b=CT:...' line should be supplied for the session giving the proposed upper limit to the bandwidth used. The main point is to get an approximate idea of whether two or more conferences can co-exist at the same time.
AS Application-Specific Maximum: the bandwidth is interpreted to be application-specific, i.e., it'll be the application's own concept of maximum bandwidth. Normally this lines up with whatever is set on the application's "maximum bandwidth" control, if there is one 🫶

Note that CT gives a total bandwidth figure for all the media at all sites. AS gives a bandwidth figure for a single media at a single site, although there may be many sites sending at the same time ⭐

Extension Mechanism: tool writers can define experimental bandwidth modifiers by prefixing their modifier with "X-". For example:

b=X-YZ:128

SDP parsers should ignore bandwidth fields with unknown modifiers 🙈 Modifiers should be alpha-numeric and, although no length limit is given, they are recommended to be short ✨

Times, Repeat Times and Time Zones

t=<start time>  <stop time>

"t=" fields specify the start and stop times for a conference session 🕰️ Multiple "t=" fields can be used if a session is active at multiple irregularly spaced times. Each additional "t=" field specifies one more period of time when the session will be active. If the session is active at regular times, an "r=" field (see below) should be used in addition to and following a "t=" field. In that case the "t=" field gives the start and stop times of the repeat sequence.
The first and second sub-fields give the start and stop times for the conference, respectively. These values are the decimal representation of Network Time Protocol (NTP) time values in seconds [1]. To convert them to UNIX time, subtract decimal 2208988800 🧚
If the stop-time is set to zero, the session is not bounded, though it won't become active until after the start-time. If the start-time is also zero, the session is regarded as permanent.

User interfaces should strongly discourage creating unbounded and permanent sessions 😭 They don't give any info about when the session is actually going to end, which makes scheduling a nightmare.

When displaying unbounded sessions that haven't timed out to the user, the general assumption may be made that an unbounded session will only be active until half an hour from the current time or the session start time, whichever is later. If some other behaviour is needed, an end-time should be given, and it should be modified as appropriate when new information comes in about when the session should really end.

Permanent sessions may be shown to the user as never being active, unless there are associated repeat times that state precisely when the session will be active. In general, permanent sessions should not be created for any session expected to last less than 2 months, and should be discouraged for sessions expected to last less than 6 months 💅

"r=" fields specify repeat times for a session. For example, if a session is active at 10am on Monday and 11am on Tuesday, for one hour each week for three months, then the <start time> in the corresponding "t=" field would be the NTP representation of 10am on the first Monday. The <repeat interval> would be 1 week, the <active duration> would be 1 hour, and the offsets would be zero and 25 hours. The corresponding "t=" field stop time would be the NTP representation of the end of the last session three months later. By default all fields are in seconds, so the "r=" and "t=" fields might look like:

t=3034423619 3042462419
 r=604800 3600 0 90000

To make announcements more compact, times can also be given in units of days, hours or minutes. The syntax is a number immediately followed by a single case-sensitive character. Fractional units are not allowed, so a smaller unit should be used instead 🍓 The following unit specification characters are allowed:

                     d - days (86400 seconds)
                    h - minutes (3600 seconds)
                     m - minutes (60 seconds)
     s - seconds (allowed for completeness but not recommended)

So the announcement above could also have been written:

r=7d 1h 0 25h

Monthly and yearly repeats can't currently be specified directly with a single SDP repeat time 🌸 Instead, separate "t" fields should be used to explicitly list the session times.

z=<adjustment time> <offset> <adjustment time> <offset> ....

To schedule a repeated session that spans a change from daylight-saving time to standard time (or the other way around), it's necessary to specify offsets from the base repeat times 🌙 This is needed because different time zones change time at different times of day, different countries switch to or from daylight time on different dates, and some countries don't have daylight saving time at all.

So to schedule a session that's at the same time in winter and summer, it has to be possible to say unambiguously whose time zone the session is scheduled by. To make this easier for receivers, the sender can specify the NTP time that a time zone adjustment happens, along with the offset from the time the session was first scheduled. The "z" field lets the sender list these adjustment times and offsets from the base time.

An example might be:

z=2882844526 -1h 2898848070 0

This specifies that at time 2882844526, the time base the session's repeat times are calculated from gets shifted back by 1 hour. At time 2898848070, the session's original time base is restored. Adjustments are always relative to the specified start time, and they are not cumulative 🦋

If a session is likely to last several years, it's expected that the session announcement will be modified periodically, rather than sending several years' worth of adjustments in one announcement 🧁

Encryption Keys

k=<method>
k=<method>:<encryption key>

The session description protocol may be used to convey encryption keys 🔐 A key field is permitted before the first media entry (in which case it applies to all media in the session), or for each media entry as required.
The format of keys and their usage is outside the scope of this document, but see [3] 🌈
The method indicates the mechanism to be used to obtain a usable key by external means, or from the encoded encryption key given.

The following methods are defined:

bestie, the k= lines are next and they're giving secret-key drama 🔐✨ The encryption key (see [3] for RTP media streams under the AV profile) can show up in a few different wrappers:

k=clear:<encryption key>

k=clear 🫶 is the straightforward one. The key goes in the field exactly as it is, no changes at all.

k=base64:<encoded encryption key>

k=base64 🧁 is the same key from [3] for RTP media streams under the AV profile, but base64 encoded. Why? Because the raw key has characters that SDP doesn't allow, so it gets encoded first so it can ride along safely 💅

k=uri:<URI to obtain key>

k=uri 🌐 is giving WWW vibes. The field holds a Universal Resource Identifier, the kind WWW clients already use. That URI points at the data containing the key, and getting the key might need extra authentication first 🔒 When you make a request to that URI, the MIME content-type of the reply tells you how the key is encoded. Also, the key shouldn't be fetched until the user actually wants to join the session. That keeps everyone from hammering the WWW server(s) with synchronised requests all at once. Be considerate, babes 🥹

k=prompt

k=prompt 🤫 means there is no key in the SDP description at all, but the session or media stream this field is attached to is encrypted. So the user should get prompted for the key when they try to join, and that user-supplied key then gets used to decrypt the media streams. Main character energy, the user is the one holding the keys 👑

Attributes

Attributes are the main way SDP gets extended, so they're honestly the MVP ✨ An attribute can be defined to work as a "session-level" attribute, a "media-level" attribute, or both 🦋

A media description can have any number of attributes (the "a=" fields) that are specific to that media. These are the "media-level" attributes, and they add information about that media stream 🎀 Attribute fields can also show up before the first media field. Those "session-level" attributes carry info that applies to the whole conference rather than to any one media. An example would be the conference's floor control policy 🌸

Attribute fields come in two forms:

Property attributes. A property attribute is just a=<flag>. These are binary, so if it's there, the attribute is a property of the session. An example is a=recvonly 🍓
Value attributes. A value attribute looks like a=<attribute>:<value>. For example, a whiteboard could have the value attribute a=orient:landscape 🖼️

How an attribute gets interpreted depends on the media tool being invoked, so receivers of session descriptions should be configurable in how they read announcements in general and attributes in particular. Tool-specific, iykyk 💀

Attribute names must be in the US-ASCII subset of ISO-10646/UTF-8.

Attribute values are byte strings, and MAY use any byte value except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are to be interpreted as in the ISO-10646 character set with UTF-8 encoding. Unlike other text fields, attribute values are NOT normally affected by the `charset' attribute, because that would make comparing against known values a mess 🙃 However, when an attribute is defined, it can be defined to be charset-dependent. In that case its value should be interpreted in the session charset rather than in ISO-10646 💅

Attributes that are going to be used a lot can be registered with IANA (see Appendix B). Unregistered attributes should begin with "X-" so they don't accidentally collide with registered ones 🫣 Either way, if an attribute gets received that isn't understood, it should simply be ignored by the receiver. No drama, just vibes 🌈

Media Announcements

A session description can contain a bunch of media descriptions ✨ Each one starts with an "m=" field and ends when either the next "m=" field shows up or the session description ends 🎬 A media field also has a few sub-fields:

m=<media> <port> <transport> <fmt list>

The first sub-field is the media type. Right now the defined media are "audio", "video", "application", "data" and "control", but the list can grow as new communication modalities show up (telepresence, anyone? 🤖). Quick tea: "application" is a media flow like whiteboard info, while "data" is bulk-data transfer, like multicasting program executables, which usually isn't shown to the user 🧃 And "control" is for an additional conference control channel for the session 🎛️
The second sub-field is the transport port that the media stream gets sent to. What the port actually means depends on the network in the relevant "c" field and on the transport protocol in the third sub-field 🛰️ Other ports the media application uses (like the RTCP port, see [2]) should be derived algorithmically from the base media port 🧮

Note: For transports based on UDP, the value should be in the range 1024 to 65535 inclusive. For RTP compliance it should be an even number. 🌸

For applications where hierarchically encoded streams are being sent to a unicast address, you might need multiple transport ports. That's done with a notation similar to the one used for IP multicast addresses in the "c=" field:

m=<media> <port>/<number of ports> <transport> <fmt list>

In that case, which ports get used depends on the transport protocol. For RTP, only the even ports carry data, and the corresponding one-higher odd port is used for RTCP 🎀 For example:

m=video 49170/2 RTP/AVP 31

This would specify that ports 49170 and 49171 form one RTP/RTCP pair, and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the transport protocol and 31 is the format (see below) 🦋

It is illegal for both multiple addresses to be specified in the "c=" field and for multiple ports to be specified in the "m=" field in the same session description. 🚫

The third sub-field is the transport protocol. The transport protocol values depend on the address-type field in the "c=" fields. So a "c=" field of IP4 means the transport protocol runs over IP4. For IP4, it's normally expected that most media traffic will be carried as RTP over UDP 📦 These transport protocols are preliminarily defined, but they can be extended by registering new protocols with IANA:
- RTP/AVP - the IETF's Realtime Transport Protocol using the Audio/Video profile carried over UDP.
- udp - User Datagram Protocol

If an application uses a single combined proprietary media format and transport protocol over UDP, then just specifying the transport protocol as udp and using the format field to tell the combined protocol apart is recommended 🧩 If a transport protocol is used over UDP to carry several distinct media types that a session directory needs to tell apart, then specifying the transport protocol and media format separately is necessary. RTP is an example of a transport protocol that carries multiple payload formats, which the session directory has to tell apart so it knows how to start the right tools, relays, mixers or recorders 🛠️

The main reason to specify the transport protocol as well as the media format is that the same standard media formats can be carried over different transport protocols even when the network protocol is the same. A historical example is vat PCM audio versus RTP PCM audio 🎙️ On top of that, relays and monitoring tools that are transport-protocol-specific but format-independent are possible too 🧠

For RTP media streams operating under the RTP Audio/Video Profile [3], the protocol field is RTP/AVP. If other RTP profiles get defined in the future, they'll be specified in the same way. For example, the protocol field RTP/XYZ would specify RTP operating under a profile whose short name is XYZ 💜

The fourth and subsequent sub-fields are media formats. For audio and video, these will normally be a media payload type as defined in the RTP Audio/Video Profile 🎵

When a list of payload formats is given, it implies that all of these formats may be used in the session, but the first one is the default format for the session 🥇

For media whose transport protocol is not RTP or UDP, the format field is protocol specific. Those formats should be defined in an additional specification document 📄

For media whose transport protocol is RTP, SDP can be used to provide a dynamic binding of media encoding to RTP payload type. The encoding names in the RTP AV Profile don't specify unique audio encodings (in terms of clock rate and number of audio channels), so they aren't used directly in SDP format fields 🙅‍♀️ Instead, the payload type number should be used to specify the format for static payload types, and the payload type number along with additional encoding information should be used for dynamically allocated payload types 🧚

An example of a static payload type is u-law PCM coded single channel audio sampled at 8KHz. This is completely defined in the RTP Audio/Video profile as payload type 0, so the media field for such a stream sent to UDP port 49232 is:

m=video 49232 RTP/AVP 0

An example of a dynamic payload type is 16 bit linear encoded stereo audio sampled at 16KHz. If we wish to use dynamic RTP/AVP payload type 98 for such a stream, additional information is required to decode it:

m=video 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2

The general form of an rtpmap attribute is:

a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]

For audio streams, <encoding parameters> may specify the number of audio channels. This parameter may be omitted if the number of channels is one, provided no additional parameters are needed. For video streams, no encoding parameters are currently specified 🎥

Additional parameters may be defined in the future, but codec-specific parameters should not be added. Parameters added to an rtpmap attribute should only be the ones a session directory needs to choose appropriate media to participate in a session. Codec-specific parameters should be added in other attributes 🧁

Up to one rtpmap attribute can be defined for each media format specified. So we might have:

m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2

RTP profiles that specify the use of dynamic payload types must define the set of valid encoding names and/or a means to register encoding names if that profile is to be used with SDP 📚

Experimental encoding formats can also be specified using rtpmap. RTP formats that aren't registered as standard format names must be preceded by "X-". So a new experimental redundant audio stream called GSMLPC using dynamic payload type 99 could be specified as:

m=video 49232 RTP/AVP 99
a=rtpmap:99 X-GSMLPC/8000

Such an experimental encoding requires that any site wishing to receive the media stream has relevant configured state in its session directory to know which tools are appropriate. 🧪💅

Okay so RTP audio formats usually don't tell you how many samples are in each packet, bestie 🎧✨ If you need a non-default packetisation (as defined in the RTP Audio/Video Profile), that's what the "ptime" attribute is for, and it's explained below. For more on RTP audio and video formats, see [3] 💜

o Formats for non-RTP media should be registered as MIME content types, as described in Appendix B 🦋 For example, the LBL whiteboard app could be registered as MIME content-type application/wb, with encoding considerations saying it runs over UDP and has no appropriate file format. In SDP you'd write that with the "media" field plus the "fmt" field, like this:

m=application 32416 udp wb

Suggested Attributes 💅

These attributes are suggested. Application writers can add new ones whenever they need them, so this list is not exhaustive 🌸

a=cat:<category> This gives the dot-separated hierarchical category of the session 🗂️ It lets a receiver filter out sessions it doesn't want, by category. It would probably have been a compulsory separate field, but since it's still experimental, it isn't yet. It's a session-level attribute, and it doesn't depend on charset.

a=keywds:<keywords> Same vibe as cat: it helps receivers find the sessions they actually want 🔍 A receiver can pick sessions by keywords describing what the session is for. It's a session-level attribute. It IS charset dependent, which means its value should be read in the charset specified for the session description if there is one, or by default in ISO 10646/UTF-8.

a=tool:<name and version of tool> This gives the name and version number of the tool used to create the session description 🛠️ It's a session-level attribute, and it doesn't depend on charset.

a=ptime:<packet time> This gives the length of time, in milliseconds, that the media in one packet represents ⏱️ It's probably only meaningful for audio data. You shouldn't need ptime to decode RTP or vat audio. It's just a recommendation for how audio gets encoded and packetised. It's a media attribute, and it doesn't depend on charset.

a=recvonly This says the tools should start in receive-only mode, where that makes sense 👂 It can be a session or media attribute, and it doesn't depend on charset.

a=sendrecv This says the tools should start in send and receive mode 🎤👂 That's needed for interactive conferences with tools like wb, which defaults to receive-only mode. It can be a session or media attribute, and it doesn't depend on charset.

a=sendonly This says the tools should start in send-only mode 📤 An example is when a different unicast address is used as the traffic destination than the one used as the traffic source. In that case you'd use two media descriptions, one sendonly and one recvonly. It can be a session or media attribute, but it would normally only be used as a media attribute, and it doesn't depend on charset.

a=orient:<whiteboard orientation> Normally this only shows up in a whiteboard media specification 🖍️ It says how the whiteboard is oriented on the screen. It's a media attribute. The permitted values are portrait, landscape and seascape (upside down landscape). It doesn't depend on charset.

a=type:<conference type> This says what type of conference it is 🎀 Suggested values are broadcast, meeting, moderated, test and H332. recvonly should be the default for type:broadcast sessions, type:meeting should imply sendrecv, and type:moderated should indicate the use of a floor control tool, with the media tools started so that they "mute" new sites joining the conference 🙊

Specifying the attribute type:H332 says this loosely coupled session is part of an H.332 session as defined in the ITU H.332 specification [10] 🌐 Media tools should be started recvonly.

Specifying the attribute type:test is suggested as a hint that, unless someone explicitly asks for otherwise, receivers can safely skip showing this session description to users 🧪

The type attribute is a session-level attribute, and it doesn't depend on charset.

a=charset:<character set> This specifies 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, other character sets can be used, such as ISO-8859-1 for Northern European languages 🇸🇪 Specifically, ISO 8859-1 is specified with this SDP attribute:

a=charset:ISO-8859-1

This is a session-level attribute. If it's present, it must come before the first media field. The charset specified MUST be one of those registered with IANA, such as ISO-8859-1. The character set identifier is a US-ASCII string and MUST be compared against the IANA identifiers using a case-insensitive comparison 🙏 If the identifier isn't recognised or isn't supported, all strings affected by it SHOULD be treated as byte strings 🫶

Heads up: a character set you specify MUST still prohibit the use of bytes 0x00 (Nul), 0x0A (LF) and 0x0d (CR). Character sets that need these characters MUST define a quoting mechanism that stops these bytes from showing up inside text fields 🚨

a=sdplang:<language tag> This can be a session-level or a media-level attribute 🌍 As a session-level attribute, it specifies the language for the session description. As a media-level attribute, it specifies the language for any media-level SDP information field tied to that media. You can give multiple sdplang attributes at session or media level if the session or media uses more than one language. In that case, the order of the attributes shows how important each language is, from most important to least important 📚

In general, sending session descriptions with multiple languages should be discouraged 🙅‍♀️ It's better to send multiple descriptions of the session, one in each language. But that isn't possible with every transport mechanism, so multiple sdplang attributes are allowed, even though they're not recommended.

The sdplang attribute value must be a single RFC 1766 language tag in US-ASCII 💕 It doesn't depend on the charset attribute. An sdplang attribute SHOULD be specified when a session is wide-reaching enough to cross geographic boundaries, where the recipients' language can't be assumed, or where the session is in a different language from the locally assumed norm 🌏

a=lang:<language tag> This can be a session-level or a media-level attribute 🗣️ As a session-level attribute, it specifies the default language for the session being described. As a media-level attribute, it specifies the language for that media, overriding any session-level language. You can give multiple lang attributes at session or media level if the session or media uses multiple languages, and again the order shows importance, from most important to least important 🥇

The lang attribute value must be a single RFC 1766 language tag in US-ASCII. It doesn't depend on the charset attribute. A lang attribute SHOULD be specified when a session is wide-reaching enough to cross geographic boundaries, where the recipients' language can't be assumed, or where the session is in a different language from the locally assumed norm 🌐

a=framerate:<frame rate> This gives the maximum video frame rate in frames/sec 🎞️ It's intended as a recommendation for encoding video data. Decimal fractions can be written with the notation <integer>.<fraction>. It's a media attribute, it's only defined for video media, and it doesn't depend on charset.

a=quality:<quality> This gives a suggestion for the quality of the encoding, as an integer value ✨

The point of the quality attribute for video is to ask for a different trade-off between frame rate and still-image quality than the default 🎚️ For video, the value is in the range 0 to 10, with these suggested meanings:

10: the best still-image quality the compression scheme can give 🌟
5: the default behaviour when there's no quality suggestion 😌
0: the worst still-image quality the codec designer thinks is still usable 🥲

It's a media attribute, and it doesn't depend on charset.

a=fmtp:<format> <format specific parameters> This lets you convey parameters that are specific to one format, in a way SDP doesn't have to understand them 🧩 The format must be one of the formats specified for the media. The format-specific parameters can be any set of parameters that need to be conveyed by SDP and passed unchanged to the media tool that will use that format 🎁

It's a media attribute, and it doesn't depend on charset.

6.1. Communicating Conference Control Policy 👑

There's some debate about how conference control policy should be communicated 🤔 In general, the authors believe that an implicit declarative style of specifying conference control is desirable wherever possible 💭

A simple declarative style uses a single conference attribute field before the first media field, possibly with properties like recvonly for some of the media tools 📝 This conference attribute carries the conference control policy. An example might be:

a=type:moderated

Sometimes, though, that might not be enough to describe an unusual conference control policy 🙃 If so, a conference attribute that specifies external control might be set, and then one or more "media" fields can describe the conference control tools and their configuration data. An example is an ITU H.332 session:

c=IN IP4 224.5.6.7
a=type:H332
m=audio 49230 RTP/AVP 0
m=video 49232 RTP/AVP 31
m=application 12349 udp wb
m=control 49234 H323 mc
c=IN IP4 134.134.157.81

In this example, a general conference attribute (type:H332) says conference control will be handled by an external H.332 tool 🛰️ It also gives a contact address for the H.323 session multipoint controller.

In this document, only the declarative style of conference control declaration is specified 🎀 Other forms of conference control should specify an appropriate type attribute, and should define the implications this has for control media 💖

7. Security Considerations 🔐

okay bestie, this part is SERIOUS 😭🔐 SDP describes multimedia sessions, and a session description should NOT be trusted unless it came through an authenticated transport protocol from a trusted source 🚫. Lots of transports can carry session descriptions, and how authentication works changes from one transport to the next 🫶.

One transport that gets used a LOT is the Session Announcement Protocol (SAP) 📣. SAP has encryption and authentication mechanisms built in, BUT announcements are kind of random, so there are tons of times where the originator can't be authenticated. Why? Because they're previously unknown to the receiver, and there's no common public key infrastructure available 💀.

When you get a session description over an unauthenticated transport, or from an untrusted party, the software parsing it should take a few precautions 🛡️. Session descriptions carry the info needed to start software on the receiver's system, so this is a real deal. Software that parses a session description MUST not be able to start other software, except software specifically configured as appropriate for taking part in multimedia sessions 🚧. It's normally considered INAPPROPRIATE for parsing software to start that kind of multimedia software on a user's system without the user being told first and giving consent 🙅‍♀️. So a session description that arrives by session announcement, email, session invitation, or a WWW page SHOULD not throw the user into an {it interactive} multimedia session without them knowing it's happening 😭. And since it isn't always easy to tell whether a session is interactive, apps that aren't sure should just assume the session IS interactive 🙈.

Now, in this spec there are no attributes that would tell a recipient to start multimedia tools in a mode that defaults to transmitting 🎙️. Under some circumstances it might make sense to define attributes like that later. If someone does, an application parsing a description with those attributes SHOULD either ignore them, or tell the user that joining the session will automatically transmit multimedia data 📢. The default behaviour for an unknown attribute is to ignore it 🙌.

Session descriptions might get parsed at intermediate systems like firewalls, so they can open a hole that lets people join multimedia sessions 🧱. It's considered INAPPROPRIATE for a firewall to open these holes for unicast data streams, unless the session description came in a request from inside the firewall 🔥.

For multicast sessions, local administrators will probably apply their own policies 🧑‍💻. Still, using only "local" or "site-local" administrative scope inside the firewall, and having the firewall refuse to open holes for those scopes, keeps global multicast sessions separate from local ones 🌍✨.

Appendix A: SDP Grammar 🎀

This appendix gives you an Augmented BNF grammar for SDP 🧁. ABNF is defined in RFC 2234 📖.

   announcement =        proto-version
                         origin-field
                         session-name-field
                         information-field
                         uri-field
                         email-fields
                         phone-fields
                         connection-field
                         bandwidth-fields
                         time-fields
                         key-field
                         attribute-fields
                         media-descriptions

   proto-version =       "v=" 1*DIGIT CRLF
                         ;this memo describes version 0

   origin-field =        "o=" username space
                         sess-id space sess-version space
                         nettype space addrtype space
                         addr CRLF

   session-name-field =  "s=" text CRLF

   information-field =   ["i=" text CRLF]

   uri-field =           ["u=" uri CRLF]

   email-fields =        *("e=" email-address CRLF)

   phone-fields =        *("p=" phone-number CRLF)


   connection-field =    ["c=" nettype space addrtype space
                         connection-address CRLF]
                         ;a connection field must be present
                         ;in every media description or at the
                         ;session-level


   bandwidth-fields =    *("b=" bwtype ":" bandwidth CRLF)
   time-fields =         1*( "t=" start-time space stop-time
                         *(CRLF repeat-fields) CRLF)
                         [zone-adjustments CRLF]


   repeat-fields =       "r=" repeat-interval space typed-time
                         1*(space typed-time)


   zone-adjustments =    time space ["-"] typed-time
                         *(space time space ["-"] typed-time)


   key-field =           ["k=" key-type CRLF]


   key-type =            "prompt" |
                         "clear:" key-data |
                         "base64:" key-data |
                         "uri:" uri


   key-data =            email-safe | "~" | "


   attribute-fields =    *("a=" attribute CRLF)


   media-descriptions =  *( media-field
                         information-field
                         *(connection-field)
                         bandwidth-fields
                         key-field
                         attribute-fields )


   media-field =         "m=" media space port ["/" integer]
                         space proto 1*(space fmt) CRLF


   media =               1*(alpha-numeric)
                         ;typically "audio", "video", "application"
                         ;or "data"

   fmt =                 1*(alpha-numeric)
                         ;typically an RTP payload type for audio
                         ;and video media

   proto =               1*(alpha-numeric)
                         ;typically "RTP/AVP" or "udp" for IP4


   port =                1*(DIGIT)
                         ;should in the range "1024" to "65535" inclusive
                         ;for UDP based media


   attribute =           (att-field ":" att-value) | att-field


   att-field =           1*(alpha-numeric)


   att-value =           byte-string


   sess-id =             1*(DIGIT)
                         ;should be unique for this originating username/host


   sess-version =        1*(DIGIT)
                         ;0 is a new session


   connection-address =  multicast-address
                         | addr


   multicast-address =   3*(decimal-uchar ".") decimal-uchar "/" ttl
                         [ "/" integer ]
                         ;multicast addresses may be in the range
                         ;224.0.0.0 to 239.255.255.255

   ttl =                 decimal-uchar

   start-time =          time | "0"

   stop-time =           time | "0"

   time =                POS-DIGIT 9*(DIGIT)
                         ;sufficient for 2 more centuries


   repeat-interval =     typed-time
   typed-time =          1*(DIGIT) [fixed-len-time-unit]


   fixed-len-time-unit = "d" | "h" | "m" | "s"


   bwtype =              1*(alpha-numeric)

   bandwidth =           1*(DIGIT)


   username =            safe
                         ;pretty wide definition, but doesn't include space


   email-address =       email | email "(" email-safe ")" |
                         email-safe "<" email ">"


   email =               ;defined in RFC822


   uri=                  ;defined in RFC1630


   phone-number =        phone | phone "(" email-safe ")" |
                         email-safe "<" phone ">"


   phone =               "+" POS-DIGIT 1*(space | "-" | DIGIT)
                         ;there must be a space or hyphen between the
                         ;international code and the rest of the number.


   nettype =             "IN"
                         ;list to be extended


   addrtype =            "IP4" | "IP6"
                         ;list to be extended


   addr =                FQDN | unicast-address


   FQDN =                4*(alpha-numeric|"-"|".")
                         ;fully qualified domain name as specified in RFC1035

   unicast-address =     IP4-address | IP6-address


   IP4-address =         b1 "." decimal-uchar "." decimal-uchar "." b4
   b1 =                  decimal-uchar
                         ;less than "224"; not "0" or "127"
   b4 =                  decimal-uchar
                         ;not "0"

   IP6-address =         ;to be defined


   text =                byte-string
                         ;default is to interpret this as IS0-10646 UTF8
                         ;ISO 8859-1 requires a "a=charset:ISO-8859-1"
                         ;session-level attribute to be used


   byte-string =         1*(0x01..0x09|0x0b|0x0c|0x0e..0xff)
                         ;any byte except NUL, CR or LF


   decimal-uchar =       DIGIT
                         | POS-DIGIT DIGIT
                         | ("1" 2*(DIGIT))
                         | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT)
                         | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5"))


   integer =             POS-DIGIT *(DIGIT)


   alpha-numeric =       ALPHA | DIGIT


   DIGIT =               "0" | POS-DIGIT


   POS-DIGIT =           "1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"


   ALPHA =               "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|
                         "l"|"m"|"n"|"o "|"p"|"q"|"r"|"s"|"t"|"u"|"v"|
                         "w"|"x"|"y"|"z"|"A"|"B"|"C "|"D"|"E"|"F"|"G"|
                         "H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|" Q"|"R"|
                         "S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"

   email-safe =          safe | space | tab


   safe =                alpha-numeric |
                         "'" | "'" | "-" | "." | "/" | ":" | "?" | """ |
                         "#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" |
                         "]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" |
                         "~" | "


   space =               %d32
   tab =                 %d9
   CRLF =                %d13.10

Appendix B: Guidelines for registering SDP names with IANA ✨

okay so there are seven field names that can get registered with IANA 💅 in SDP BNF terms they're media, proto, fmt, att-field, bwtype, nettype and addrtype. let's go through them one by one 🎀

`media` (eg, audio, video, application, data)

Packetized media types, like the ones RTP uses, share the namespace of the media types registry [RFC 2048] (aka "MIME types") 🦋 The list of valid media names is just the set of top-level MIME content types. This set is meant to stay small and only get extended in rare situations, so don't go adding new ones for fun 🙈 (The MIME subtype is what the fmt parameter below corresponds to.)

`proto`

In general this should be an IETF standards-track transport protocol identifier, like RTP/AVP (rfc 1889 under the rfc 1890 profile) 💜

BUT people will absolutely want to invent their own proprietary transport protocols 💀 Some of those should be registered as a fmt using udp as the protocol, and some of them probably can't be.

Where the protocol and the application are intimately linked, like the LBL whiteboard wb which used a proprietary, special-purpose protocol over UDP, the protocol name should be udp and the format name to register is wb 🍓 The rules for formats (see below) apply to these registrations.

Where the proprietary transport protocol really carries many different data formats, it's possible to register a new protocol name with IANA. In that case, an RFC MUST be produced describing the protocol and referenced in the registration. That RFC MAY be informational, although it's preferable if it's standards-track ✨

`fmt`

The format namespace depends on the context of the proto field, so you can't register a format without specifying one or more transport protocols that it applies to 🧚

Formats cover all the possible encodings that might want to be transported in a multimedia session 🌈

For RTP formats that have been assigned static payload types, the payload type number is used. For RTP formats using a dynamic payload type number, the dynamic payload type number is given as the format, and an additional rtpmap attribute specifies the format and parameters 🎀

For non-RTP formats, any unregistered format name may be registered through the MIME-type registration process [RFC 2048]. The type given here is the MIME subtype only (the top-level MIME content type is specified by the media parameter). The MIME type registration SHOULD reference a standards-track RFC which describes the transport protocol for this media type. If there's already a MIME type for this format, the MIME registration should be augmented to reference the transport specification for this media type. If there's no existing MIME type for this format, and there's no appropriate file format either, this should be noted in the encoding considerations as "no appropriate file format" 💅

`att-field` (Attribute names)

Attribute field names MAY be registered with IANA 🦋 but it's not compulsory, and unknown attributes are simply ignored, so no panic 💖

When an attribute is registered, it must be accompanied by a brief specification stating the following:

contact name, email address and telephone number
attribute-name (as it will appear in SDP)
long-form attribute name in English
type of attribute (session level, media level, or both)
whether the attribute value is subject to the charset attribute.
a one paragraph explanation of the purpose of the attribute.
a specification of appropriate attribute values for this attribute.

IANA won't sanity check these attribute registrations, except to make sure they don't clash with existing registrations 🙈

Even though the above is the minimum IANA will accept, if the attribute is expected to see widespread use and interoperability is an issue, authors are encouraged to produce a standards-track RFC that specifies the attribute more precisely 🔥

Submitters should make sure the spec is in the spirit of SDP attributes. Most notably, the attribute should be platform independent, meaning it makes no implicit assumptions about operating systems and doesn't name specific pieces of software in a way that might inhibit interoperability 🫶

`bwtype` (bandwidth specifiers)

A proliferation of bandwidth specifiers is strongly discouraged 😭 new ones may be registered with IANA, but the submission MUST reference a standards-track RFC that specifies the semantics of the bandwidth specifier precisely, indicates when it should be used, and explains why the existing registered bandwidth specifiers don't suffice 🙃

`nettype` (Network Type)

New network types may be registered with IANA if SDP needs to be used in non-internet environments 🌸 These aren't normally IANA's thing, but there may be times when an Internet application needs to interoperate with a non-internet application, like when gatewaying an internet telephony call into the PSTN 📞 The number of network types should be small and rarely extended.

A new network type can't be registered without registering at least one address type to be used with that network type 💀 A new network type registration MUST reference an RFC that gives details of the network type and address type and specifies how and when they would be used. Such an RFC MAY be Informational. ✨

`addrtype` (Address Type)

New address types may be registered with IANA 💜 An address type only means something in the context of a network type, so any registration of an address type MUST specify a registered network type, or be submitted along with a network type registration. A new address type registration MUST reference an RFC giving details of the syntax of the address type. Such an RFC MAY be Informational. Address types aren't expected to be registered frequently 🌈

Registration Procedure

To register a name, follow the guidelines above about the level of documentation required 📝 Send the registration itself to IANA. Attribute registrations should include the information given above. Other registrations should include the following additional information:

contact name, email address and telephone number
name being registered (as it will appear in SDP)
long-form name in English
type of name ("media", "proto", "fmt", "bwtype", "nettype", or "addrtype")
a one paragraph explanation of the purpose of the registered name.
a reference to the specification (eg RFC number) of the registered name.

IANA may refer any registration to the IESG or to any appropriate IETF working group for review, and may request revisions to be made before a registration will be made 👑

Appendix C: Authors' Addresses 🧚

Mark Handley
Information Sciences Institute
c/o MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139
United States
electronic mail: mjh@isi.edu

Van Jacobson
MS 46a-1121
Lawrence Berkeley Laboratory
Berkeley, CA 94720
United States
electronic mail: van@ee.lbl.gov

Acknowledgments 🫶

Many people in the IETF MMUSIC working group left comments and suggestions that helped shape this document 💖 In particular, a huge thank you to Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Rob Lanphier and Steve Hanna 👑

References 📚

[1] Mills, D., "Network Time Protocol (version 3) specification and implementation", RFC 1305, March 1992.

[2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.

[3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996

[4] Handley, M., "SAP - Session Announcement Protocol", Work in Progress.

[5] V. Jacobson, S. McCanne, "vat - X11-based audio teleconferencing tool" vat manual page, Lawrence Berkeley Laboratory, 1994.

[6] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996.

[7] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. Five amendments and a technical corrigendum have been published up to now. UTF-8 is described in Annex R, published as Amendment 2.

[8] Goldsmith, D., and M. Davis, "Using Unicode with MIME", RFC 1641, July 1994.

[9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.

[10] ITU-T Recommendation H.332 (1998): "Multimedia Terminal for Receiving Internet-based H.323 Conferences", ITU, Geneva.

[11] Handley, M., Schooler, E., and H. Schulzrinne, "Session Initiation Protocol (SIP)", Work in Progress.

[12] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.

Full Copyright Statement ⚖️

Okay, the legal bit, and it matters 🙏 This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with implementing it, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind. The one condition is that the above copyright notice and this paragraph are included on all such copies and derivative works 🎀

However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's needed to translate it into languages other than English 🌍

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns ✨

This document and the information contained herein is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💅

📦 where this page comes from

ietf: rfc2327 1998-04
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms