Re: [MMUSIC] Remove msid-semantic

[Harald Alvestrand <[e-mail]>]

On 03/27/2015 05:45 PM, Martin Thomson wrote:
>
> As we discussed in the meeting, I propose that we remove msid-semantic
> entirely. In a brief discussion after the meeting we couldn't identify
> a single case where it is needed.
>
> Apparently, it serves to indicate the potential for use of msid prior
> to having media to send.
>

As I said at the mike, the case where it's needed is described in
section 5.1 of the draft.
It's not very long, so I'll reproduce it below. (I got the section
number wrong at the mike...)


> Obviously, that isn't a good substitute for careful analysis, but
> unless someone wants to restore this rather vaguely specified
> capability, I'd rather have a simpler spec and implementation now and
> remove it.
>
> Can anyone actually make a case for keeping it?
>

5.1.  Handling of non-signalled tracks

   Entities that do not use the WMS semantic will not send "msid-
   semantic:WMS".  This means that there will be some incoming RTP
   packets that the recipient has no predefined MediaStream id value
   for.

   Note that this handling is triggered by incoming RTP packets, not by
   SDP negotiation.

   Handling will depend on whether or not the msid-semantic:WMS
   attribute is present.  There are two cases:

   o  No "msid-semantic:WMS" attribute is present.  The SDP session is
      assumed to be a backwards-compatible session.  All incoming media,
      on all m-lines that are part of the SDP session, are assumed to
      belong to tracks of the same media stream (the "default media
      stream").  The identifier of this media stream and of the media
      stream track is a randomly generated string; the WebIDL "label"
      attribute of this media stream will be set to "Non-WMS stream".

   o  An "msid-semantic:WMS" attribute is present.  In this case, the
      sender implements the WMS semantic, and the packets are either
      caused by a bug or by timing skew between the arrival of the media
      packets and the SDP description.  These packets MAY be discarded,
      or they MAY be buffered for a while in order to allow immediate
      startup of the media stream when the SDP description is updated.
      The arrival of media packets MUST NOT cause a new MediaStreamTrack
      to be signaled.

   If an entity wishing to use the WMS semantic sends a description, it
   MUST include the msid-semantic:WMS attribute, even if no media
   streams are sent.  This allows us to distinguish between the case of
   no media streams at the moment and the case of SDP generated by an
   entity that wishes to use the backwards-compatible mechanism.

I see three possible outcomes of the discussion:

- We don't need this ability; we can rewrite the cases above in a way
that is deterministic without being able to tell whether the sender
intends to send msid-semantic or not.

- We need this ability, but can do it without msid-semantic:

- We need this ability, and should keep msid-semantic.

Please discuss.