RFC 8830

WebRTC MediaStream Identification in the Session Description Protocol

📅 published January 2021, from ietf

RFC 8830 💖 WebRTC MediaStream Identification in the Session Description Protocol

okay bestie, this is RFC 8830 🎀, and the title block has all the tea. It's a Standards Track document from the Internet Engineering Task Force (IETF) 🌈. The author is H. Alvestrand at Google ✨. It's dated January 2021, and its ISSN is 2070-1721 💅. The title block doesn't list any RFCs that it obsoletes or updates, so it's a fresh start 🫶.

Abstract ✨

okay so the big idea is that this doc specifies a grouping mechanism for the Session Description Protocol (SDP) 📋. It's for RTP media streams, and it lets you spell out how different streams are related to each other 🔗.

It's used to signal the link between the SDP idea of a "media description" and the Web Real-Time Communication (WebRTC) idea of a MediaStream/MediaStreamTrack, all through SDP signaling 🎤. Main character energy.

Status of This Memo 📜

this is an Internet Standards Track document 💅.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more info on Internet Standards, check Section 2 of RFC 7841 📚.

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8830 🔗.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date 📝. Please actually read these, because they explain your rights and restrictions for this document 🙈. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as the Simplified BSD License describes 💀.

Table of Contents 🗂️

   1.  Introduction
     1.1.  Terminology
     1.2.  Structure of This Document
     1.3.  Why a New Mechanism Is Needed
     1.4.  The WebRTC MediaStream
   2.  The MSID Mechanism
   3.  Procedures
     3.1.  Handling of Nonsignaled Tracks
     3.2.  Detailed Offer/Answer Procedures
       3.2.1.  Generating the Initial Offer
       3.2.2.  Answerer Processing of the Offer
       3.2.3.  Generating the Answer
       3.2.4.  Offerer Processing of the Answer
       3.2.5.  Modifying the Session
     3.3.  Example SDP Description
   4.  IANA Considerations
     4.1.  Attribute Registration in Existing Registries
   5.  Security Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Appendix A.  Design Considerations, Rejected Alternatives
   Acknowledgements
   Author's Address

1. Introduction 🌸

1.1. Terminology 📖

okay so this doc borrows its vocab from [RFC8825]. On top of that, these terms get a specific meaning:

  • RTP stream: A stream of RTP packets containing media data [RFC7656].
  • MediaStream: An assembly of MediaStreamTracks [W3C.CR-mediacapture-streams]. One MediaStream can hold multiple MediaStreamTracks, of the same or different types.
  • MediaStreamTrack: Defined in [W3C.CR-mediacapture-streams] as a unidirectional flow of media data (either audio or video, but not both). It corresponds to the [RFC7656] term "source stream". One MediaStreamTrack can be in zero, one, or multiple MediaStreams.
  • Media description: Defined in [RFC4566] as a set of fields that starts with an "m=" field and ends at either the next "m=" field or the end of the session description.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🧠

1.2. Structure of This Document 🗺️

ok so this doc adds a new Session Description Protocol (SDP) [RFC4566] mechanism. It lets you attach identifiers to the RTP streams, and also to the groupings they form 🏷️. It's designed for use with WebRTC [RFC8825] 💻.

  • Section 1.3 gives the background on why a new mechanism is needed 🕰️.
  • Section 2 gives the definition of the new mechanism ✍️.
  • Section 3 gives the semantic info and procedures for using the "msid" attribute to signal how MediaStreamTracks are associated with MediaStreams, in support of the WebRTC API [W3C-WebRTC] 🎀.

1.3. Why a New Mechanism Is Needed 🤔

so when media travels over RTP [RFC3550], each RTP stream is told apart inside an RTP session by its Synchronization Source (SSRC) 🔍. Each RTP session is told apart from every other RTP session by running on a different transport association. Strictly speaking, that's two transport associations: one for RTP and one for the RTP Control Protocol (RTCP), unless RTP/RTCP multiplexing [RFC5761] is used 🔀.

SDP [RFC4566] has a format for describing an SDP session that can hold multiple media descriptions 📋. Following the model in [RFC8829], each media description describes exactly one media source 🎯. If multiple media sources are carried in one RTP session, that gets signaled using BUNDLE [RFC8843]. If BUNDLE isn't used, each media source gets its own RTP session 🫧.

The SDP Grouping Framework [RFC5888] can group media descriptions 🧩. BUT for WebRTC, an application needs to say some application-level stuff about how a media description is associated with the group, and the SDP Grouping Framework can't do that 😭.

1.4. The WebRTC MediaStream 🎬

the W3C WebRTC API specification [W3C-WebRTC] says that WebRTC entities talk to each other through MediaStreams, and MediaStreams hold MediaStreamTracks 🎥. A MediaStreamTrack is usually carried using a single SSRC in an RTP session, which forms an RTP stream. The terminology clash is unfortunate, honestly 🙃.

There might be extra SSRCs, possibly in extra RTP sessions, to support things like forward error correction or simulcast 🛡️. This specification doesn't affect those extra SSRCs at all 🙅‍♀️.

MediaStreamTracks are unidirectional, which means they carry media in one direction only ➡️.

In the RTP specification, RTP streams are identified using the SSRC field. Streams get grouped into RTP sessions and also carry a CNAME 🧾. Neither the CNAME nor the RTP session corresponds to a MediaStream. So the association between an RTP stream and MediaStreams has to be signaled explicitly 📣.

WebRTC defines a mapping, documented in [RFC8829], where one SDP media description describes each MediaStreamTrack. The BUNDLE mechanism [RFC8843] groups MediaStreamTracks into RTP sessions 🧺. So the thing we need to specify is the identifier (ID) of each MediaStreamTrack and of its associated MediaStream, for each media description. That can be done with a media-level SDP attribute 🏆.

This usage is described in Section 3 📚.

2. The MSID Mechanism 🆔

okay here's the core of it: this doc defines a new SDP [RFC4566] media-level "msid" attribute 💖. It lets endpoints connect RTP streams that are described in separate media descriptions with the right MediaStreams, as defined in [W3C-WebRTC] 🔗. It also lets endpoints carry an identifier for each MediaStreamTrack in its "appdata" field 🎁.

The value of the "msid" attribute is an identifier plus an optional "appdata" field 🧁.

The name of the attribute is "msid" 🏷️.

The value of the attribute is specified by the following ABNF [RFC5234] grammar:

msid-value = msid-id [ SP msid-appdata ]
msid-id = 1*64token-char ; see RFC 4566
msid-appdata = 1*64token-char  ; see RFC 4566

For example, an "msid" value for a group with the identifier "examplefoo" and application data "examplebar" looks like this:

msid:examplefoo examplebar

The identifier is a string of ASCII characters that are legal in a "token", and it's between 1 and 64 characters long 🔤.

Application data (msid-appdata) rides on the same line as the identifier, separated from it by a space 🛼.

The identifier ("msid-id") uniquely identifies a group within the scope of an SDP description 🪪.

There may be multiple "msid" attributes in a single media description 🌈. That covers the case where a single MediaStreamTrack is in multiple MediaStreams, and the value of "msid-appdata" MUST be identical for all occurrences 👯.

Multiple media descriptions with the same value for "msid-id" and "msid-appdata" are not permitted 🚫. Sorry bestie, no dupes allowed.

Endpoints can update the associations between RTP streams, as expressed by "msid" attributes, at any time 🔄.

The "msid" attributes depend on the association of RTP streams with media descriptions, but they don't depend on the association of RTP streams with RTP transports 🚛. So their Mux Category (as defined in [RFC8859]) is NORMAL. The process of deciding on "msid" attributes doesn't have to consider whether or not the RTP streams are bundled 💅.

3. Procedures ✨

okay so this section is the how-to 💅 It explains how you link the media descriptions for MediaStreamTracks to the MediaStreams they live in, following what [W3C-WebRTC] defines. 🎀

In that JavaScript API, every MediaStream and every MediaStreamTrack has an "id" attribute, and it's a DOMString 🫶

The msid-id field in the MSID is the MediaStream's "id" attribute, as defined in the MediaStream's WebIDL spec [WEBIDL]. The special value - just means "no MediaStream" 🙈

The msid-appdata field, if it's there, holds the MediaStreamTrack's "id" attribute, as defined in the MediaStreamTrack's WebIDL spec 💖

When an SDP session description gets updated, a specific msid-id still refers to the same MediaStream, and a specific msid-appdata still refers to the same MediaStreamTrack. But there's no memory beyond the SDP descriptions that are currently valid. So if an MSID "identifier" value disappears from the SDP and then pops back up in a later negotiation, it's treated as a brand-new MediaStream. no cap, fresh start 💀

If the "msid" attribute doesn't conform to the ABNF given here, it SHOULD be ignored. 🙅‍♀️

Here's the high-level rundown of how to handle SDP updates. The detailed procedures are in Section 3.2 🦋

  • When a new MSID "identifier" value shows up in a session description and it isn't -, the recipient can tell its app that a new MediaStream has been added. ✨
  • When a session description gets updated so that media descriptions have an MSID "identifier" value with one or more different "appdata" values, the recipient can tell its app that new MediaStreamTracks have been added and which MediaStream they went into. This happens for each different MSID "identifier" value, including the special value -, which means a MediaStreamTrack was added with no corresponding MediaStream. 🌈
  • If an MSID "identifier" value shows up with no "appdata" value, it means the sender didn't tell the recipient which identifier it wants for the MediaStreamTrack. So the recipient assigns the "id" value of the created MediaStreamTrack on its own. All MSIDs in a media section that don't have an "appdata" value are assumed to refer to the same MediaStreamTrack. 🧚
  • When a session description gets updated so that a specific media description no longer lists any "msid" attribute, the recipient can tell its app that the matching MediaStreamTrack has ended. 👑

Also, the track gets signaled as ended when its "msid" attribute disappears from the SDP. It also gets signaled as ended when all of its associated SSRCs have disappeared under the rules of [RFC3550], Sections 6.3.4 (BYE packet received) and 6.3.5 (timeout), or when the matching media description is disabled by setting the port number to zero. Changing the direction of the media description (by setting the sendonly, recvonly, or inactive attributes) will NOT end the MediaStreamTrack. Just a vibe check: flipping the direction doesn't kill the track 🙅‍♀️

The association between SSRCs and media descriptions is specified in [RFC8829] 🎀

3.1. Handling of Nonsignaled Tracks

Entities that don't use the mechanism in this document won't send the "msid" attribute, so they won't send anything that lets you map RTP packets to MediaStreams. Which means there will be some incoming RTP packets where the recipient has no predefined MediaStream ID value 🫠

Heads up: the handling described below is triggered by incoming RTP packets, NOT by SDP negotiation. 🚨

When you're talking to entities that use the MSID mechanism, the only time incoming RTP packets can arrive without an associated MediaStream ID value is when, after the initial negotiation, there's a renegotiation where the answerer adds a MediaStreamTrack to an already established connection and starts sending data before the answer gets received by the offerer. For the initial negotiation, packets won't flow until the Interactive Connectivity Establishment (ICE) candidates and fingerprints have been exchanged, so this isn't an issue 🙌

Here's what the recipient of those packets does:

  • When RTP packets are first received, it creates an appropriate MediaStreamTrack based on the type of the media (carried in PayloadType). It also uses the MID RTP header extension [RFC8843] (if present) to associate the RTP packets with a specific media section. 🦋
  • If the connection is not in the RTCSignalingState "stable", it waits at this point. ⏳
  • When the connection is in the RTCSignalingState "stable", it assigns ID values. ✨

To assign the ID values, the following steps happen:

  • If there is an "msid" attribute, it uses that attribute to populate the "id" field of the MediaStreamTrack and the associated MediaStreams, as described above. 💅
  • If there is no "msid" attribute, the identifier of the MediaStreamTrack is set to a randomly generated string, and it's signaled as being part of a MediaStream with the WebIDL "label" attribute set to "Non-WebRTC stream". 🎀
  • After deciding on the "id" field to apply to the MediaStreamTrack, the track is signaled to the user. 🫶

The process above can involve a lot of buffering before the "stable" state gets entered. If the implementation wants to limit this buffering, it MUST signal to the user that media has been discarded. ⚠️

Warning: if the implementation limits buffering this way, it MUST tell the user that media was discarded. No silent drops, bestie 🥺

It follows from all of the above that MediaStreamTracks in the "default" MediaStream can't be closed by removing the "msid" attribute. The application has to signal them as closed when the SSRC disappears, either under the rules of Sections 6.3.4 and 6.3.5 of [RFC3550] or by disabling the media description with its port set to zero 🙈

3.2. Detailed Offer/Answer Procedures

These procedures are given in terms of the sections recommended by [RFC3264]. They describe what to do in terms of MediaStreams and MediaStreamTracks. They do NOT include the event signaling inside the application, which is covered by the JavaScript Session Establishment Protocol (JSEP) [RFC8829] 🧠

3.2.1. Generating the Initial Offer

For each media description in the offer, if there's an associated outgoing MediaStreamTrack, the offerer adds one "a=msid" attribute to the section for each MediaStream that the MediaStreamTrack is associated with. The "identifier" field of the attribute is set to the WebIDL "id" attribute of the MediaStream. If the sender wants to signal identifiers for the MediaStreamTracks, the "appdata" field is set to the WebIDL "id" attribute of the MediaStreamTrack. Otherwise, it's omitted 🎀

3.2.2. Answerer Processing of the Offer

For each media description in the offer, and for each "a=msid" attribute in that media description, the receiver of the offer does the following steps 💖

  • Extract the "appdata" field of the "a=msid" attribute, if it's present. 🫶
  • If the "appdata" field exists: check whether a MediaStreamTrack with the same WebIDL "id" attribute as the "appdata" field already exists and is NOT in the "ended" state. If no such MediaStreamTrack is found, create it. ✨
  • If the "appdata" field does not exist, and no MediaStreamTrack is associated with this media section, create a MediaStreamTrack and associate it with this media section for future use. 🦋
  • Extract the "identifier" field of the "a=msid" attribute. 🧚
  • Check whether a MediaStream with the same WebIDL "id" attribute already exists. If it doesn't, create it. 🌸
  • Add the MediaStreamTrack to the MediaStream. 🔥
  • Signal to the user that a new MediaStreamTrack is available. 👑

3.2.3. Generating the Answer

The answer is generated in exactly the same manner as the offer. "a=msid" values in the offer do NOT influence the answer. 🙅‍♀️

3.2.4. Offerer Processing of the Answer

The answer is processed in exactly the same manner as the offer. Same energy, same steps 💅

3.2.5. Modifying the Session

On subsequent exchanges, exactly the same procedure as for the initial offer/answer is followed, with one extra step when parsing the offer and answer:

  • For each MediaStreamTrack that was created as a result of previous offer/answer exchanges, and that is NOT in the "ended" state, check whether there's still an "a=msid" attribute in the present SDP whose "appdata" field is the same as the WebIDL "id" attribute of the track. 🌈
  • If no such attribute is found, stop the MediaStreamTrack. This sets its state to "ended". 💀

3.3. Example SDP Description

Okay, example time 🍓 This SDP description shows a WebRTC PeerConnection with two MediaStreams, and each one has one audio track and one video track. Only the parts relevant to the MSID are shown.

Line wrapping, empty lines, and comments were added for clarity. They are NOT part of the SDP. 🙈

# First MediaStream - id is 4701...
m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:47017fee-b6c1-4162-929c-a25110252400
          f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9

m=video 56502 UDP/TLS/RTP/SAVPF 100 101
a=msid:47017fee-b6c1-4162-929c-a25110252400
          b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0

# Second MediaStream - id is 6131....
m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
          b94006c5-cade-4e0a-9ed9-d3e6747be7d9

m=video 56504 UDP/TLS/RTP/SAVPF 100 101
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
          f30bdb4a-1497-49b5-3198-e0c9a23172e0

4. IANA Considerations ✨

4.1. Attribute Registration in Existing Registries

IANA has registered the "msid" attribute in the "att-field" (media level only) registry, which lives inside the "Session Description Protocol (SDP) Parameters" registry. This was done according to the procedures of [RFC4566] 🎀

Here's the "msid" registration info:

Contact name, email:  IETF, contacted via mmusic@ietf.org, or a
   successor address designated by IESG

Attribute name:  msid

Attribute syntax:

   msid-value = msid-id [ SP msid-appdata ]
   msid-id = 1*64token-char ; see RFC 4566
   msid-appdata = 1*64token-char  ; see RFC 4566

Attribute semantics:  Described in RFC 8830

Attribute value:  msid-value

Long-form attribute name:  MediaStream Identifier

Usage level:  media

Subject to charset:  The attribute value contains only ASCII
   characters and is therefore not subject to the charset attribute.

Purpose:  The attribute can be used to signal the relationship
   between a WebRTC MediaStream and a set of media descriptions.

O/A Procedures:  Described in RFC 8830

Appropriate values:  The details of appropriate values are given in
   RFC 8830 (this document).

Mux Category:  NORMAL

The Mux Category is defined in [RFC8859] 🫶

5. Security Considerations ✨

okay bestie, this section is seriously important 🫶 someone who can change SDP descriptions can literally swap tracks around between MediaStreams 😭 that's a special case of the bigger rule that SDP changes have to stay locked to entities the application trusts 🔒

Only trusted entities should be able to touch SDP descriptions. If an attacker can edit them, they can rearrange your tracks, and that's a whole mess 💀

if you're doing the buffering from Section 3.1, the amount of buffering should be limited so nobody can blow up your memory with memory exhaustion attacks 🧠💥 keep it tight, periodt 💅

then there's privacy 🙈 careless identifier generation can leak privacy-sensitive information, which is so not it. [W3C.CR-mediacapture-streams] recommends that identifiers be built on a Universally Unique IDentifier (UUID) class 3 or 4 as a basis, and that's how you avoid the leak 🦋

and the tea ☕ no other attacks have been identified that depend on this mechanism. main character energy for the security section 👑

6. References

6.1. Normative References

6.2. Informative References

Appendix A. Design Considerations, Rejected Alternatives

ooh, the rejected ideas 🦋 this is the fun part where we see what almost happened ✨

one suggested mechanism was to use CNAME instead of a new attribute. it got abandoned 🙅‍♀️ because CNAME identifies a synchronization context, and you could totally imagine wanting tracks from the same sync context in multiple MediaStreams, plus tracks from multiple sync contexts inside one MediaStream. but that second one is impossible, since a MediaStream is defined to impose synchronization on its members 💀

another idea was to put the msid value inside an attribute of RTCP SR (sender report) packets 📦. this doesn't let you know that you've seen all the tracks currently configured for a MediaStream, so it's a no from us 🙅‍♀️

and then there was the suggestion that survived for a bunch of drafts 🥹. it was to define MSID as a generic mechanism, where the specific semantics of this usage would be set by an a=wms-semantic attribute. that got removed in April 2015 🫠 gone but not forgotten 🌸

Acknowledgements

this note is based on sketches from, among others, Justin Uberti and Cullen Jennings 🎀

special thanks to Flemming Andreasen, Ben Campbell, Miguel Garcia, Martin Thomson, Ted Hardie, Adam Roach, Magnus Westerlund, Alissa Cooper, Sue Hares, and Paul Kyzivat for reviewing this document and giving so many specific language suggestions 🫶💜

Author's Address

Harald Alvestrand Google Kungsbron 2 SE-11122 Stockholm Sweden

Email: harald@alvestrand.no 📬✨

📦 where this page comes from