Subject: Re: [MMUSIC] Updated MSID draft

From: Harald Alvestrand <[email-masked]>
Date: Fri, 01 Nov 2013 10:00:22 +0100

On 10/30/2013 03:38 PM, Paul Kyzivat wrote:
> A few comments about this version. Actually the comments aren't
> specific to this revision, but they relate to things I didn't notice
> earlier.
>
> Msid-Semantic syntax:
>
>      attribute =/ msid-semantic-attr
>      msid-semantic-attr = "msid-semantic:" token (" " identifier)*
>      token = <as defined in RFC 4566>
>
> The usage of "*" is backward. (Following regex syntax rather than abnf
> syntax). This ought to be:
>
>      attribute =/ msid-semantic-attr
>      msid-semantic-attr = "msid-semantic:" token *(" " identifier)
>      token = <as defined in RFC 4566>

Thanks!

>
> Just following that:
>
>    The semantic field may hold values from the IANA registries
>    "Semantics for the "ssrc-group" SDP Attribute" and "Semantics for the
>    "group" SDP Attribute".
>
> I have a couple of issues with this:
>
> Section 5 defines a new registry "Semantics for the msid-semantic SDP
> attribute", and defines a new semantic "WMS" in it. The text above
> doesn't even reference this registry.

Yep, that section needs to be re-thought. The SSRC-group registry is now
irrelevant, since we don't do things on SSRC any more.
>
> Because the two mentioned registries are independent, AFAIK there is
> no guarantee that they couldn't someday contain different definitions
> for the same "semantic" name. Then, if that name were used with msid
> the proper definition to use would be ambiguous. (I realize this is
> implausible, but nothing prevents it.) IMO the *right* answer would be
> to merge all these grouping semantics into a single table. But that is
> a hassle right now. Perhaps it would be sufficient to say that only
> semantics that are uniquely defined across all of these tables may be
> used with msid. E.g.,
>
>    The semantic field may hold any value that is uniquely defined
>    in one and only one of the IANA registries "Semantics for the
>    msid-semantic SDP attribute", "Semantics for the "ssrc-group"
>    SDP Attribute" and "Semantics for the "group" SDP Attribute".

That would work - it should then ask IANA to update the instructions for
those registries to disallow the registration of new values with
conflicts between them.

This effectively turns them into one registry...

>
>     Thanks,
>     Paul
>
> On 10/30/13 3:13 AM, Harald Alvestrand wrote:
>> Roni and Flemming pointed out that I hadn't managed to submit the fixes
>> I made to -msid after the reviews of -01 before the deadline, and had
>> even managed to forget to send it to the list.
>>
>> I had missed a number of occurences where "SSRC" needed to be changed to
>> "m-line" in the text (with some more adjustments to language around
>> that).
>>
>> Here it is. I'll submit it on Monday, when the I-D repository reopens.
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
Surveillance is pervasive. Go Dark.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 1 Nov 2013 14:29:25 +0100

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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 02 Nov 2013 18:31:50 +0100

Thanks for the review!

Not addressing the whole thing, but just one:

> WMS semantics, SRCNAME, APPID or other?
If I ignore your advice to move msid back from being a media-level
attribute to being a stream-level attribute, Unified Plan makes that simple:

All packet streams that form part of a MediaStreamTrack are signalled as
part of the same m-line, so the MSID applies to all of them. Marking for
simulcast is entirely independent of MSID; MSID just identifies the
MediaStreamTrack and MediaStream, it does not help in parsing the
components of a MediaStreamTrack.

The one case where this gets into trouble is a FEC stream that applies
to multiple SSRCs; this is the same case (and the same issue) as the one
where you might want to use the same a=ssrc attribute in multiple m-lines.

Either we can define how that is done, or we can define that this is
impossible in Unified Plan. Some issues may not be worth solving.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 02 Nov 2013 18:41:35 +0100

On 11/01/2013 02:29 PM, Magnus Westerlund wrote:
> of WebRTC.

In the context of the WebRTC API spec, there exist no guarantees about
synchronization between different MediaStreams. The UA is free to play
them out synchronized or unsynchronized; of course synchronized playback
is also in accordance with the specification.

>  If that is not an issue with separate MediaStreams then I am

I think I see what you mean now; this is an issue with compatibility
with non-WMS systems that rely on CNAME for signalling that
synchronization should occur.

I see two solutions for compatibility:

- Add all tracks with the same CNAME to the same MediaStream. Do not
signal the addstream or addtrack events until the CNAME is known. This
delays playout start, but is compatible with preexisting usage.

- Generate separate MediaStreams as in the current spec, but put in a
note that if these are played out locally, they SHOULD be synchronized.

In the latter case, Javascript will have no way of telling that the
tracks are in fact synchronized, but they will play out correctly.