WebRTC MediaStream Identification in the Session Description Protocol
Extracted elements (23)
A new SDP attribute was needed because the existing SDP Grouping Framework (RFC 5888) does not allow specifying application-level information about the association between media descriptions and groups, which is required to map SDP media descriptions to WebRTC MediaStreams and MediaStreamTracks.
An earlier proposal defined MSID as a generic mechanism with semantics specified via an 'a=wms-semantic' attribute. This was removed in April 2015 to simplify the mechanism and tie it directly to WebRTC MediaStream semantics.
CNAME was considered as an alternative to a new attribute but was rejected because CNAME identifies a synchronization context, and the desired mapping between tracks and MediaStreams does not align with synchronization contexts — tracks from the same SSRC context might be in different MediaStreams, or vice versa.
Placing the msid value in RTCP SR packets was rejected because it would not provide the ability to know that all tracks currently configured for a MediaStream have been seen.
Entities that do not implement the MSID mechanism will not send 'msid' attributes, resulting in incoming RTP packets with no associated MediaStream ID. Recipients must handle this by creating tracks with randomly generated IDs associated with a 'Non-WebRTC stream' MediaStream.
If an implementation buffers incoming RTP packets while waiting for the RTCSignalingState to reach 'stable' (as described in Section 3.1), it MUST signal to the user that media has been discarded if buffering limits are applied.
If the 'msid' attribute does not conform to the ABNF grammar defined in Section 2, it SHOULD be ignored.
When a single MediaStreamTrack is present in multiple MediaStreams, there may be multiple 'msid' attributes in a single media description. In this case, the value of 'msid-appdata' MUST be identical for all occurrences.
Careless generation of msid-id and msid-appdata identifiers can leak privacy-sensitive information. The W3C Media Capture and Streams specification recommends using UUID class 3 or 4 as a basis for identifiers to avoid such leakage.
A MediaStreamTrack is signaled as ended when its 'msid' attribute disappears from SDP, when all associated SSRCs have disappeared per RFC 3550 BYE or timeout rules, or when the media description is disabled by setting its port to zero. Changing media direction (sendonly/recvonly/inactive) does NOT end the track.
During offer generation, for each media description with an associated outgoing MediaStreamTrack, the offerer adds one 'a=msid' attribute per MediaStream the track belongs to. The msid-id is the WebIDL 'id' of the MediaStream; msid-appdata is the WebIDL 'id' of the MediaStreamTrack if the sender wishes to signal it.
On session modification, in addition to normal offer/answer processing, each previously created MediaStreamTrack not in the 'ended' state is checked for a matching 'a=msid' appdata value. If none is found, the track is stopped and set to the 'ended' state.
The answer is generated in exactly the same manner as the offer; 'a=msid' values in the offer do not influence the answer. Offerer processing of the answer follows the same procedure as answerer processing of the offer.
The answerer processes each 'a=msid' attribute in an offer by extracting appdata and identifier fields, creating MediaStreamTracks and MediaStreams as needed, associating tracks with streams, and signaling new tracks to the user.
The 'msid' attribute is a new SDP media-level attribute that associates RTP streams described in separate media descriptions with MediaStreams and MediaStreamTracks as defined in the WebRTC API. It consists of an 'msid-id' (the MediaStream id) and an optional 'msid-appdata' (the MediaStreamTrack id), each 1–64 token characters.
The Mux Category for the 'msid' attribute is NORMAL (per RFC 8859), meaning the process of deciding on 'msid' attributes does not need to consider whether RTP streams are bundled; it depends on the association of RTP streams with media descriptions, not with RTP transports.
The special msid-id value '-' indicates 'no MediaStream', allowing a MediaStreamTrack to be signaled as not belonging to any MediaStream.
When an SDP session description is updated, a specific msid-id continues to refer to the same MediaStream and msid-appdata to the same MediaStreamTrack. If an MSID identifier disappears and reappears in a later negotiation, it refers to a new MediaStream (no persistent memory beyond the current SDP).
IANA registered the 'msid' attribute in the 'att-field (media level only)' registry within the 'Session Description Protocol (SDP) Parameters' registry. The Mux Category is NORMAL as defined in RFC 8859.
An adversary with the ability to modify SDP descriptions can switch tracks between MediaStreams. Modification of SDP descriptions must be confined to trusted entities, which is the general SDP security requirement.
Implementations that buffer RTP packets while waiting for stable signaling state (Section 3.1) should limit buffering to avoid memory exhaustion attacks.
When unsignaled RTP packets arrive, the recipient creates a MediaStreamTrack and waits if the connection is not in RTCSignalingState 'stable'. Once 'stable' is reached, it assigns IDs from any 'msid' attribute, or generates a random ID and associates the track with a 'Non-WebRTC stream' MediaStream if no 'msid' is present.
The MSID attribute value follows the ABNF: msid-value = msid-id [ SP msid-appdata ]; msid-id = 1*64token-char; msid-appdata = 1*64token-char. Both fields are ASCII token strings of 1 to 64 characters each.