2. The MSID Mechanism

This document defines a new SDP [RFC4566] media-level "msid" attribute. This new attribute allows endpoints to associate RTP streams that are described in separate media descriptions with the right MediaStreams, as defined in [W3C-WebRTC]. It also allows endpoints to carry an identifier for each MediaStreamTrack in its "appdata" field.

The value of the "msid" attribute consists of an identifier and 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

An example "msid" value for a group with the identifier "examplefoo" and application data "examplebar" might look like this:

msid:examplefoo examplebar

The identifier is a string of ASCII characters that are legal in a "token", consisting of between 1 and 64 characters.

Application data (msid-appdata) is carried on the same line as the identifier, separated from the identifier 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. This represents the case where a single MediaStreamTrack is present in multiple MediaStreams; 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.

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 do not depend on the association of RTP streams with RTP transports. Therefore, their Mux Category (as defined in [RFC8859]) is NORMAL; the process of deciding on "msid" attributes doesn't have to take into consideration whether or not the RTP streams are bundled.