Subject: [MMUSIC] Remove msid-semantic

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Mar 2015 11:45:46 -0500

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.

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?

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 29 Mar 2015 09:33:56 +0200

On 03/27/2015 05:45 PM, Martin Thomson wrote:
> 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.
>

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.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 12:43:13 -0500

> intends to send msid-semantic or not.

This.

The only WebRTC case I can think of in which you have media arriving
without announcement is when you have an SDP from a peer that has
established a data channel AND you have an outstanding offer to
receive new media that is bundled with the data channels.  I think
that we can safely assume that a peer like that understands msid,
though your draft definitely should state that assumption.

In all the other WebRTC cases, you will have media-related signaling,
because you can't form inbound media into tracks until you have an
a=fingerprint line from the peer.

Outside of WebRTC, there are potentially uses of bundle and
m=not-media that trigger this crazy setup.  Simply state that the
offerer is required to either make temporary tracks (for which the
identifiers and groupings might need to be retrofitted when the
signaling arrives), or discard the media until signaling arrives.

Note that I didn't mention synchronization; that's something we should
be signaling explicitly with LS groups.  Though if we decide that I'm
wrong there, that just means that tracks are unsynchronized prior to
getting signaling...which is how it goes with LS groups, so it's hard
to see where we are making things worse.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 Mar 2015 11:07:30 +0200

> signaling arrives), or discard the media until signaling arrives.

Yes, I also don't see a need for the MSID semantics.

To my understanding, a WebRTC endpoint will include the MSID attribute.
A WebRTC compatible will usually not, and end up with default MS if no
a=msid attributes are present. If the SDP answer hasn't arrived yet,
then it ends up in the same case, you don't know what to bind to anyway.
So you either buffer or discard these. When you have the answer you will
know which MS and MST the streams belong to.

And as Martin says the uncertainty if one will receive MSID or not
occurs only when one upgrade from no media streams to include media
streams.

> to see where we are making things worse.

Just to be clear here and ensure that I haven't missed anything. RTP
usage requires all WebRTC endpoint to provide synchronization
information when sending. However, it is up to the receiver to decide if
they want to synchronize the playout. Thus this LS group would only be
there to indicate a strong preference by the sender that the receiver
should/shall playout in synchronization?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Mar 2015 09:32:54 -0700

> should/shall playout in synchronization?

Correct, the information in RTP will make it possible to synchronize
tracks, but whether that is acted upon will ultimately depend on
whether the tracks are rendered in the same stream.  I think that the
intent with the LS groups is to make this clear, not just to a WebRTC
receiver, but to legacy receivers as well.