Re: [MMUSIC] Updated MSID draft

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed this document, and have some feedback.

First of all I trying to understand any commonalities and differences
among the other proposals for relation signaling:

Application Token
draft-even-mmusic-application-token-01

And our SRCNAME
https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-srcname/
that relates to our Simulcast proposal
https://datatracker.ietf.org/doc/draft-westerlund-avtcore-rtp-simulcast/

I hope to have time to discuss this with people during the IETF meeting.
It is something we need to sort out.

Now comments directly related to the draft:

1. Section 2:

I don't think MSID should really be a media level attribute. It is
primarily a source level attribute. The discussion about its usage is
all around binding it to media streams, i.e. Packet Streams (SSRC)s.

There might be points of binding it to Media Descriptions, which under
unified plan would mean Media Sources, but outside of unified it then
binds to a RTP session or similar. Thus one needs to consider if the
media level application means that all SSRCs or other media streams that
originates from the context described by that Media Description have the
same MSID values apply.

Thus, I would suggest changing MSID to source level attribute, and then
add the meaning of applying it as media level when such done.

2. Section 3:
"In order to fully reproduce the semantics of the SDP and SSRC
   grouping frameworks, a session-level attribute is defined for
   signaling the semantics associated with an msid grouping."

I think this is a poor motivation. I think there are good reasons for
having a semantics identifier for the grouping identifier so that one
can have groupings for different purposes. Thus I think one rather
should explain the benefits of enabling such different semantics.

3. Section 4:

I don't know if this is the right place for it or where it should go.
But applying MSID to WebRTC one runs into the question of how one needs
to deal with none source packet streams, i.e. Packet Streams that do not
carry the primary source encoding. Such streams that are redundancy
streams, like RTP retransmission streams, FEC streams, as well as if one
would use scalable encoding and have packet streams that are dependent.

How should these be marked using MSID? As being part of the related
MediaStreamTrack? OR should we use something that isn't dependent on the
WMS semantics, SRCNAME, APPID or other?

4. Section 4.1
   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 independent media streams, each with one track.  The
      identifier of this media stream and of the media stream track is a
      randomly generated string; the label of this media stream will be
      set to "Non-WMS stream".

   NOTE IN DRAFT: Previous versions of this memo suggested adding all
   incoming SSRCs to a single MediaStream.  This is problematic because
   we do not know if the SSRCs are synchronized or not before we learn
   the CNAME of the SSRCs, which only happens when an RTCP packet
   arrives.  How to identify a non-WMS stream is still open for
   discussion - including whether it's necessary to do so.  Using the
   stream label seems like an easy thing to do for debuggability - it's
   not signalled, and is intended for human consumption anyway.


Can you clarify how synchronized playback of multiple different media
streams, that on RTP level shares CNAME can be achieved in the context
of WebRTC. If that is not an issue with separate MediaStreams then I am
fine with this. If the main way of achieving synchronized playback is to
put the MediaStreamTracks in the same MediaStream then we have an issue.

I see a point in that each endpoitn (CNAME) should have its SSRCs with
source packet streams result in MediaStreamTracks in the same
MediaStream. But, as you write that either introduces delay into adding
a MediaStreamTrack until RTCP info has been received or otherwise a lot
of change events as one makes one assumption and then have to correct it
as more data comes in.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------