Subject: [MMUSIC] MSID and mapping to tracks and streams

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Dec 2014 10:50:54 -0800

The value of the "identifier" field in the msid consists of the "id"
   attribute of a MediaStream, as defined in its WebIDL specification.

   The value of the "appdata" field in the msid consists of the "id"
   attribute of a MediaStreamTrack, as defined in its WebIDL
   specification.

I think that this is backwards. The media section (m=) corresponds to
a track, not a stream.  The MediaStream is the secondary identifier.

I'd have thought that this was merely personal bias, until I read this:

   The identifier is a string of ASCII characters that are legal in a
   "token", consisting of between 1 and 64 characters.  It MUST be
   unique among the identifier values used in the same SDP session.  It
   is RECOMMENDED that it is generated using a random-number generator.

This rule, as specified and in combination with the aforementioned,
would absolutely prevent the use of multiple tracks from the same
stream (i.e., the most common case in existence).

Also, this is mightly confusing to me:

   [...]  Once negotiation has completed on a
   session, there is no memory apart from the currently valid SDP
   descriptions; an msid "identifier" value that appears in a later
   negotiation will be taken to refer to a new MediaStream.

I have no idea what this might be saying.  I can imagine a whole lot
of things that might be said here: "a track (not stream) that is bound
to a given media section is unaffected by changes in the msid values
in that media section during renegotiation" or "a track on the sending
side that is bound to a media section, then subsequently swapped out
(see replaceTrack) for another, MAY cause the msid values to change in
subsequent renegotiations, but this does not result in action from the
receiving side".