RFC 5576
Source-Specific Media Attributes in the Session Description Protocol (SDP)
RFC 5576: Source-Specific Media Attributes in SDP 🎀
okay bestie, so this is RFC 5576 ✨, a Standards Track doc from the Network Working Group, dated June 2009. It's called Source-Specific Media Attributes in the Session Description Protocol (SDP) and it was written by J. Lennox (Vidyo), J. Ott (Helsinki University of Technology), and T. Schierl (Fraunhofer HHI) 🫶. The header doesn't list anything it obsoletes or updates, so it's a fresh start 🌸.
Status of This Memo 📜
this one is a standards track protocol spec for the Internet community, and it's asking people to talk about it and suggest improvements 💬. If you want to know where this protocol stands in the official standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🧐. Distribution is unlimited, so share away 🦋.
Copyright Notice ©️
Copyright (c) 2009 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, as they stood on the date it was published (http://trustee.ietf.org/license-info). Please actually read those, bestie, because they spell out your rights and restrictions 📑.
It's also possible that this document includes material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. Some of the copyright holders for that older material may never have given the IETF Trust permission to let it be modified outside the IETF Standards Process 🙈. So unless you get a proper license from whoever controls that copyright, this document can't be modified outside the IETF Standards Process, and you can't make derivative works of it outside that process either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈.
Abstract 🔥
The Session Description Protocol (SDP) lets you describe the attributes of whole multimedia sessions and of individual media streams inside them, like Real-time Transport Protocol (RTP) sessions 🎬. What it can't do is describe the individual media sources within a media stream, and that's the gap we're fixing 💅. This document introduces a way to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers. It shows how to attach attributes to those sources in SDP and how to express relationships between them. It also defines several source-level attributes for describing the properties of media sources ✨.
Table of Contents 📚
here's the full table of contents, exactly as it appears in the original:
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview ........................................................3
4. Media Attributes ................................................4
4.1. The "ssrc" Media Attribute .................................5
4.2. The "ssrc-group" Media Attribute ...........................6
5. Usage of Identified Source Identifiers in RTP ...................7
6. Source Attributes ...............................................8
6.1. The "cname" Source Attribute ...............................8
6.2. The "previous-ssrc" Source Attribute .......................9
6.3. The "fmtp" Source Attribute ................................9
6.4. Other Source Attributes ...................................10
7. Examples .......................................................10
8. Usage With the Offer/Answer Model ..............................11
9. Backward Compatibility .........................................11
10. Formal Grammar ................................................12
11. Security Considerations .......................................13
12. IANA Considerations ...........................................14
12.1. New SDP Media-Level Attributes ...........................14
12.2. Registry for Source-Level Attributes .....................14
12.3. Registry for Source Grouping Semantics ...................15
13. References ....................................................16
13.1. Normative References .....................................16
13.2. Informative References ...................................161. Introduction 🌸
okay so SDP [RFC4566] is great at describing the attributes of multimedia sessions and of media streams (like RTP [RFC3550] sessions) inside them. But it has zero way to describe the individual media sources inside a media stream 😭.
Some newer protocols, especially RTP single-source multicast [EXT-SSM], really wanted to describe specific media sources in SDP messages 🧚. Single-source multicast in particular has to make sure receivers' RTP synchronization source (SSRC) identifiers don't collide with the ones used by media senders. That matters because the RTP specification [RFC3550] says sources that collide have to change their SSRC values once a collision is detected 💀. Earlier work handled this with mechanisms specific to each protocol, which is very much a mess 🙄.
Then there's the fact that RTP [RFC3550] allows multiple sources in one RTP session. Think of a user with more than one camera 📷. SDP has no existing way for an endpoint to say it's going to use multiple sources, or to describe each of them separately 🥺.
So this document fixes all of that. It defines a way to describe RTP sources, identified by their synchronization source (SSRC) identifier, in SDP. It lets you attach attributes to those sources and express relationships between individual sources 🔗. It also defines a bunch of new SDP attributes that apply to individual sources (the "source-level" attributes), explains how a number of existing media stream ("media-level") attributes can also be applied at the source level, and sets up IANA registries for source-level attributes and source grouping semantics 🗂️.
2. 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 [RFC2119]. They're how this doc signals requirement levels for compliant implementations 💅.
3. Overview 🦋
in RTP [RFC3550], a group of communicating participants is called an RTP Session 🫂. An RTP session is usually tied to a single transport address (for multicast) or a single communication flow (for unicast). RTP translators and single-source multicast [EXT-SSM] can make things messier 🌀. RTP topologies get a deeper dive in [RFC5117] 🗺️.
Inside an RTP session, the source of one stream of RTP packets is called a synchronization source (SSRC) 🎤. Every SSRC is identified by a 32-bit numeric identifier 🔢. Receivers are also a thing: they may never send any RTP packets, but they still have source identifiers, which are used for their RTP Control Protocol (RTCP) receiver reports and other feedback messages 💌.
Messages of the Session Description Protocol (SDP) [RFC4566] are called session descriptions, and they describe multimedia sessions 🎞️. A multimedia session is a set of multimedia senders and receivers plus the data streams flowing from senders to receivers 🌊. A multimedia session holds a number of media streams, which are the individual RTP sessions or other media paths that carry one type of multimedia data 🎶. Info that applies to the whole session is called session-level information, and info about one media stream is called media-level information 🧁. All the info describing one media stream is a media description. (Media descriptions are sometimes informally called SDP "m"-lines, after the SDP syntax that starts a media description 🙈.) Both levels have a set of standard info elements, and you can add extended info at either level using attributes 🧩.
(Quick side note: the term "media stream" isn't in the SDP spec itself. A bunch of SDP extensions use it anyway, like Interactive Connectivity Establishment (ICE) [ICE], to mean the thing described by an SDP media description. It's honestly confusing 😵💫. The RTP specification [RFC3550] uses "media stream" for a single media source or RTP packet stream, identified by an SSRC, while an SDP media stream covers an entire RTP session, which can hold any number of RTP sources. So in this document, "media stream" means an SDP media stream, the thing described by an SDP media description, and "media source" means a single source of media packets, which is an RTP media stream 🧠.)
The core SDP spec has no way to describe individual media sources, especially RTP synchronization sources, inside a media stream 😤. To fix that, this document adds a third level of info called source-level information ⭐. Syntactically, source-level info is described by a new SDP media-level attribute called ssrc. It identifies specific synchronization sources within an RTP session and acts as a meta-attribute that maps source-level attribute info onto those sources 🎯.
This document also defines an SDP media-level attribute called ssrc-group. It can represent relationships among media sources within an RTP session, kind of like how the "group" attribute [RFC3388] represents relationships among media streams within a multimedia session 👯.
4. Media Attributes 🎀
this section defines two media-level attributes, ssrc and ssrc-group 💖.
(Part 1 of 4. More to come, bestie, so stay tuned 🧚✨)
4.1. The "ssrc" Media Attribute 🎀
Okay so this is the ssrc attribute, and it's giving property drop 💅. Its syntax looks like this:
a=ssrc:<ssrc-id> <attribute>
a=ssrc:<ssrc-id> <attribute>:<value>It describes a property (a "source-level attribute") of one media source, which is an RTP stream inside an RTP session 🦋. The <ssrc-id> is the synchronization source (SSRC) ID of the source being described. It's a 32-bit unsigned integer in network byte order, written out in decimal. The <attribute> (or <attribute>:<value>) is the source-level attribute for that particular source. It follows the same syntax as an SDP a= line, so it's either a single attribute name (a flag) or a name plus a value, like cname:user@example.com 💖. No flag-style attributes are defined in this document, so for now every one you see will have a value.
Within one media stream, every ssrc line that uses the same <ssrc-id> is describing a different attribute of that same source 🧚. Across media streams, though, the <ssrc-id> values aren't connected to each other (unless media-stream grouping or some other mechanism says they are), so they MAY be repeated 🌸.
Each ssrc line gives you exactly one source-level attribute for its <ssrc-id>. Every source mentioned in SDP MUST come with the cname source-level attribute, which is defined in Section 6.1 🫶. You're free to add any number of other source-level attributes for that source too, because they MAY also be provided ✨.
The ssrc attribute MAY be used for any RTP-based media transport. It isn't defined for anything else 🙈.
If other SDP attributes also mention RTP SSRC values (Multimedia Internet KEYing (MIKEY) [RFC3830] [RFC4567] is one example), those values MUST be consistent with each other 💜. Those attributes MAY give extra info about a source that an ssrc attribute describes, or MAY describe extra sources entirely 🔥.
Source-level attributes follow the same syntax as session-level and media-level attributes, but they're defined separately, so don't mix them up 💅. Every source-level attribute MUST be registered with IANA, using the registry defined in Section 12.2 📚.
Figure 4 in Section 10 has the formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for ssrc, so go there if you want the full spec 🍓.
The ssrc media attribute doesn't depend on charset 🌈.
4.2. The "ssrc-group" Media Attribute 💖
a=ssrc-group:<semantics> <ssrc-id> ...This one is the ssrc-group attribute, and it shows how several sources in one RTP session are related to each other 👑. It's kind of like the session-level "group" attribute [RFC3388], which relates media streams inside an SDP multimedia session (in other words, related RTP sessions). Sources already have SSRC IDs, so there's no need for a "mid"-style attribute here. Groups of sources are identified straight from their SSRC IDs 🦋.
The <semantics> value comes from the "group" attribute's spec [RFC3388]. The first semantic values defined for ssrc-group are FID (Flow Identification) [RFC3388] and FEC (Forward Error Correction) [RFC4756]. In both cases, the relationship between the grouped sources is the same as the relationship between matching sources in media streams grouped with the SDP "group" attribute ✨.
ssrc-group semantic values use the same syntax as "group" semantic values, but they're defined separately. Every ssrc-group semantic value MUST be registered with IANA, using the registry defined in Section 12.3 🌸.
(Heads up: the other "group" semantics registered with IANA at the time of writing aren't much use for grouping sources 🙈. LS (Lip Synchronization) [RFC3388] is redundant for sources inside one media stream, since RTP sources with the same CNAME are already implicitly synchronized in RTP. SRF (Single Reservation Flow) [RFC3524] and ANAT (Alternative Network Address Types) [RFC4091] are about the media stream's transport characteristics. CS (Composite Session) [FLUTE] groups FLUTE sessions, so it doesn't apply to RTP at all 💀.)
The ssrc-group attribute lists the sources in a group by their <ssrc-id>s. It MUST list at least one <ssrc-id> for each group, and it MAY list as many more as it wants 🧚. Every <ssrc-id> listed in an ssrc-group attribute MUST be defined by a matching ssrc: line in that same media description 💜.
The ssrc-group media attribute doesn't depend on charset 🌈.
Figure 5 in Section 10 has the formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for ssrc-group 🍓.
5. Usage of Identified Source Identifiers in RTP ✨
Okay, this part is the drama 😭. The SSRC identifiers in an RTP session are picked randomly and independently by each endpoint, which means two endpoints can end up picking the same one 💀. The chance is low, but the RTP specification [RFC3550] says every RTP endpoint MUST be ready to detect and resolve collisions 🔥.
Because of that, every endpoint MUST be ready for the fact that the info about specific sources in a media stream might be outdated 🫶. The only thing that actually ties SSRCs to source CNAMEs is the source description (SDES) RTCP packets sent on the RTP session 🎀.
When endpoints choose their own local SSRC values for media streams that have source-level attributes, they MUST NOT use any SSRC IDs that are mentioned in media descriptions they've received for that media stream 🙅♀️.
That said, sources identified by SDP source-level attributes don't change anything about RTP transport logic 🦋. Sources that only show up in SDP, where no RTP or RTCP packets have arrived yet, MUST NOT be counted for RTP group size estimation, and report blocks MUST NOT be sent for them in SR or RR RTCP messages 💅.
Endpoints MUST NOT assume that only the sources in SDP will show up in an RTP session 🙈. New sources with SSRC IDs nobody mentioned can be added at any time, and endpoints MUST be ready to receive packets from them 🧚. (The spec doesn't say how endpoints should handle those packets. They SHOULD be handled the same way packets from extra sources would be if the endpoint had never received any a=ssrc: attributes at all 🌸.)
If an endpoint sees an SSRC collision between its explicitly signaled source and another entity that hasn't explicitly signaled an SSRC, it MAY hold off on RTP collision-resolution actions [RFC3550] for 5*1.5*Td. Td is the deterministic, calculated reporting interval for receivers defined in Section 6.3.1 of the RTP specification [RFC3550]. The point is to see whether the conflict is still there 👑. (This gives explicitly signaled sources the win and puts the collision-resolution work on the sources that never signaled 💖.) SSRC collisions between multiple explicitly signaled sources, though, MUST be acted on immediately 🔥.
If a source identified by source-level attributes gets forced to change its SSRC after RTP's collision-resolution procedures [RFC3550], the author of the SDP containing those source-level attributes SHOULD send out an updated SDP session description with the new SSRC, as long as the way SDP gets distributed for the multimedia session can distribute updated SDP 🦋. That updated SDP MUST include a "previous-ssrc" source-level attribute, which is described in Section 6.2, listing the source's previous SSRC ID ✨. (If only one source with a given CNAME collided, the other RTP session members can work out which old SSRC matches which new one without needing an updated session description 🧚. But if more than one source collides at once, or sources are leaving and rejoining, they can't work it out. So to avoid confusion, sending updated SDP messages is always RECOMMENDED 🌈.)
Endpoints MUST NOT reuse the same SSRC ID for identified sources with the same CNAME for at least the length of the RTP session's participant timeout interval (see Section 6.3.5 of [RFC3550]) 💅. They SHOULD NOT reuse any SSRC ID that was ever mentioned in SDP (whether they mentioned it themselves or another endpoint did) for the whole lifetime of the RTP session 🍓.
Endpoints MUST be ready for the chance that other parties in the session don't understand SDP source-level attributes, unless some higher-level mechanism normatively requires them to 🫶. Section 9 has more on this 💜.
6. Source Attributes 💖
This section covers the specific source attributes you can apply to RTP sources 🎀.
6.1. The "cname" Source Attribute 🦋
a=ssrc:<ssrc-id> cname:<cname>The cname source attribute ties a media source to its Canonical End-Point Identifier (CNAME) source description (SDES) item 👑. This MUST be the CNAME value the media sender will put in its RTCP SDES packets, so it MUST follow the CNAME syntax rules defined in the RTP specification [RFC3550] ✨. If a session participant gets an RTCP SDES packet that links this SSRC to a different CNAME, it SHOULD assume there's been an SSRC collision, and that the source description in the SDP doesn't apply to the actual source it's receiving 😭. This source attribute is REQUIRED to be present whenever any source attributes are present for a source 💅. The cname attribute MUST NOT show up more than once for the same ssrc-id within a given media stream 🙅♀️.
The cname source attribute doesn't depend on charset 🌈.
Figure 6 in Section 10 has the formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for cname 🍓.
6.2. The "previous-ssrc" Source Attribute 🌸
a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> ...The previous-ssrc source attribute links a media source to the source identifiers it used before 🧚. When an SSRC changes because of a collision involving a media source described in SDP, the updated session description for the source's new SSRC (see Section 5) MUST include a previous-ssrc attribute that links the new SSRC to the old one 💜. If more updated SDP descriptions get published for that media source, the previous-ssrc attribute SHOULD be included when the session description was generated before the old SSRC's participant timeout, and MAY be included after that point 🔥. If it's present, this attribute MUST list at least one previous SSRC, and MAY list as many more as needed if the source has collided more than once 🦋. This attribute MUST be present only once for each source 💅.
The previous-ssrc source attribute doesn't depend on charset 🌈.
Figure 7 in Section 10 has the formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for previous-ssrc 🍓.
6.3. The "fmtp" Source Attribute ✨
a=ssrc:<ssrc> fmtp:<format> <format specific parameters>The fmtp source attribute lets you send format-specific parameters about a given source 🎀. The <format> MUST be one of the media formats (in other words, RTP payload types) specified for the media stream 👑. What the <format specific parameters> mean is different for each media type 🌸. This parameter MUST only be used for media types where source-level format parameters have been explicitly specified 🫶. Media-level format parameters MUST NOT be carried over blindly 🙅♀️.
The fmtp source attribute doesn't depend on charset 🌈.
6.4. Other Source Attributes 🎀
okay so this doc only defines the source attributes that are necessary or useful for an endpoint to decode and render the sources in a media stream 🎬. it does not include any attributes that would affect whether an endpoint accepts or rejects a stream, like in an offer/answer exchange. those are for future consideration 🔮 (bestie, that's a whole other era)
7. Examples ✨
this section gives a bunch of examples of SDP descriptions of media sessions with source attributes 🧁. for brevity, only the media sections are shown, so no session-level stuff 💅
m=audio 49168 RTP/AVP 0
a=ssrc:314159 cname:user@example.comFigure 1: Example of a declaration of a single synchronization source
the example in Figure 1 is an audio stream advertising one single source 🎤
m=video 49170 RTP/AVP 96
a=rtpmap:96 H264/90000
a=ssrc:12345 cname:another-user@example.com
a=ssrc:67890 cname:another-user@example.comFigure 2: Example of a media stream containing several independent sources from a single session member
the example in Figure 2 is a video stream where ONE participant (identified by a single CNAME) has several cameras 📸 the main character is multitasking. the sources could be told apart further by RTCP Source Description (SDES) information 🧩
m=video 49174 RTP/AVPF 96 98
a=rtpmap:96 H.264/90000
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=96;rtx-time=3000
a=ssrc-group:FID 11111 22222
a=ssrc:11111 cname:user3@example.com
a=ssrc:22222 cname:user3@example.com
a=ssrc-group:FID 33333 44444
a=ssrc:33333 cname:user3@example.com
a=ssrc:44444 cname:user3@example.comFigure 3: Example of the relationships among several retransmission sources
the example in Figure 3 shows how the relationships between sources used for RTP retransmission [RFC4588] can be explicitly signaled 🔁 this avoids the mess of figuring out which original source goes with which retransmission source when SSRC multiplexing is used for RTP retransmission, as described in Section 5.3 of [RFC4588] 🙈
8. Usage With the Offer/Answer Model 💌
when you use this with the SDP Offer/Answer Model [RFC3264], the source-specific SDP attributes only describe the sources that each party is willing to send (whether that's RTP data or RTCP report blocks) 📨. there's no mechanism for an answer to accept or reject individual sources inside a media stream 🙅♀️. so if the set of sources in a media stream is unacceptable, the answerer's ONLY option is to reject the media stream or the whole multimedia session 💀
the SSRC IDs for sources described by an SDP answer MUST be distinct from the SSRC IDs for sources of that media stream in the offer. 🚫 similarly, new SSRC IDs in an updated offer MUST be distinct from the SSRC IDs for that media stream established in the most recent offer/answer exchange for the session, and SHOULD be distinct from any SSRC ID ever used by either party within the multimedia session (whether or not it's still in use) 🦋
9. Backward Compatibility 🔙
okay so according to the SDP definition, interpreters of SDP session descriptions ignore unknown attributes 🙃 which means endpoints MUST be prepared for the possibility that recipients of their RTP media session may not understand their explicit source descriptions, unless some external mechanism indicates that they were understood. in some cases (like RTP Retransmission [RFC4588]), this can constrain some choices about the bitstreams being transmitted 🧠
source descriptions are specified in this document so that RTP endpoints compliant with the RTP specification [RFC3550] can decode the media streams they describe whether or not they support explicit source descriptions ✨ the vibe is backwards compatibility, iconic however, some deployed RTP implementations may not actually support multiple media sources in a media stream 😬. so media senders MAY wish to stick to a single source at a time, unless they have some way of concluding that the receivers of the media stream support source multiplexing 🫶
10. Formal Grammar 📝
this section gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for each of the new media and source attributes defined in this document 🧚. grammars for existing session or media attributes that were extended to be source attributes are NOT included here, so don't go looking for them 🙈
Copyright (c) 2009 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
o Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.ssrc-attr = "ssrc:" ssrc-id SP attribute
; The base definition of "attribute" is in RFC 4566.
; (It is the content of "a=" lines.)
ssrc-id = integer ; 0 .. 2**32 - 1
attribute =/ ssrc-attrFigure 4: Syntax of the "ssrc" media attribute
ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)
semantics = "FEC" / "FID" / token
; Matches RFC 3388 definition and
; IANA registration rules in this doc.
token = <as defined in RFC 4566>
attribute =/ ssrc-group-attrFigure 5: Syntax of the "ssrc-group" media attribute
cname-attr = "cname:" cname
cname = byte-string
; Following the syntax conventions for CNAME as defined in RFC 3550.
; The definition of "byte-string" is in RFC 4566.
attribute =/ cname-attrFigure 6: Syntax of the "cname" source attribute
previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id)
attribute =/ previous-ssrc-attrFigure 7: Syntax of the "previous-ssrc" source attribute
11. Security Considerations 🚨
⚠️ this part is serious, bestie. all the security implications of RTP [RFC3550] and of SDP [RFC4566] apply here, full stop 🔒
explicitly describing the multiplexed sources of an RTP media stream does not appear to add any further security issues 🛡️
12. IANA Considerations 🗂️
12.1. New SDP Media-Level Attributes 🎶
this document defines two SDP media-level attributes: "ssrc" and "ssrc-group" 💖. IANA registered these under "Session Description Protocol (SDP) Parameters" under "att-field (media level only)".
the "ssrc" attribute identifies characteristics of media sources within a media stream 🎤. its format is defined in Section 4.1.
the "ssrc-group" attribute identifies relationships among media sources within a media stream 🔗. its format is defined in Section 4.2.
12.2. Registry for Source-Level Attributes 📋
this spec creates a new IANA registry named "att-field (source level)" inside the SDP parameters registry 🆕. source attributes MUST be registered with IANA and documented under the same rules as SDP session-level and media-level attributes, as specified in [RFC4566].
new attribute registrations are accepted under the "Specification Required" policy of [RFC5226], as long as the specification includes the following information 📝:
- contact name, email address, and telephone number
- attribute name (as it will appear in SDP)
- long-form attribute name in English
- 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
that's the minimum IANA will accept 🙏. the Expert Reviewer will decide whether the proposed attributes are expected to see widespread use and interoperability 👀. if so, the attributes MUST be specified in a Standards Track RFC 🏆.
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 could get in the way of interoperability 🧩
source-level attributes that are substantially similar in semantics to existing session-level or media-level attributes SHOULD reuse the same attribute name as those attributes 🪞. source-level attributes SHOULD NOT reuse attribute names of session-level or media-level attributes that are unrelated or substantially different 🙅♀️.
the initial set of source attribute names, with definitions in Section 6 of this document, is in Figure 8 🌸.
Type SDP Name Reference
---- ------------------ ---------
att-field (source level)
cname [RFC5576]
previous-ssrc [RFC5576]
fmtp [RFC5576]Figure 8: Initial contents of the IANA Source Attribute Registry
12.3. Registry for Source Grouping Semantics 🧁
this spec creates a new IANA registry named 'Semantics for the "ssrc-group" SDP Attribute' inside the SDP parameters registry 🆕. source group semantics MUST be defined in Standards Track RFCs, under the same rules as [RFC3388] 🏆.
the IANA Considerations section of the RFC MUST include the following information, which shows up in the IANA registry along with the RFC number of the publication 📚:
- a brief description of the semantics.
- token to be used within the group attribute. this token may be of any length, but SHOULD be no more than four characters long.
- reference to a Standards Track RFC.
source grouping semantic values that are substantially similar to existing media grouping semantic values SHOULD reuse the same semantics name as those media grouping semantics 🪞. source grouping semantics SHOULD NOT reuse source grouping semantic names that are unrelated or substantially different 🙅♀️.
the initial set of source grouping semantic values, for the semantics specified in Section 4.2 of this document, is in Figure 9 💅.
Semantics Token Reference
------------------- ----- ---------
Flow Identification FID [RFC5576]
Forward Error Correction FEC [RFC5576]Figure 9: Initial Contents of IANA Source Group Semantics Registry
13. References 📚
13.1. Normative References 🎀
okay so bestie, these are the docs this RFC leans on for its core rules 💅 we're talking the BCP 14 key words, the offer/answer model, grouping media lines, RTP, SDP itself, FEC grouping, IANA guidelines, and ABNF 🧠 literally the whole support squad 🫶
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔥[RFC3264]Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. 💖[RFC3388]Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002. 🦋[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 🌸[RFC4566]Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. ✨[RFC4756]Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006. 🧚[RFC5226]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 💜[RFC5234]Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 🍓
13.2. Informative References 🌈
these ones are the "good to know" crew 👑 not required reading, but they give you the full picture (and some of them are still works in progress, so the vibes are evolving 🙈)
[EXT-SSM]Schooler, E., Ott, J., and J. Chesterfield, "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Work in Progress, March 2009. 🦋[FLUTE]Mehta, H., "SDP Descriptors for FLUTE", Work in Progress, January 2006. 🎀[ICE]Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007. 💅[RFC3524]Camarillo, G. and A. Monrad, "Mapping of Media Streams to Resource Reservation Flows", RFC 3524, April 2003. 🌸[RFC3830]Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. 🔐[RFC4091]Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005. ✨[RFC4567]Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006. 🧚[RFC4588]Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. 💖[RFC5117]Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. 🍓
Authors' Addresses 💜
Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Sixth Floor Hackensack, NJ 07601 US
EMail: jonathan@vidyo.com
Joerg Ott Helsinki University of Technology (TKK) Department of Communications and Networking PO Box 3000 FIN-02015 TKK Finland
EMail: jo@acm.org
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany
Phone: +49-30-31002-227 EMail: ts@thomas-schierl.de
📦 where this page comes from
- ietf: rfc5576 2009-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms