Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-msid-10

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Jul 2015 19:43:33 +0200

Hi,

I have reviewed this document, although I am late I thought I would 
provide my comments.

1.

Section 2:

   "There may be multiple msid attributes in a single media description.
    There may also be multiple media descriptions that have the same
    value for identifier and application data."

Section 3:

   "If two different media descriptions have MSID attributes with the
    same values for "msid-id" and "msid-appdata", it means that these two
    media descriptions are both intended for the same MediaStreamTrack.

    So far, no semantic for such a mixture have been defined, but this
    specification does not forbid the practice."

So this text discusses two different cases. Lets take them one at a time.

A single media description (m=) with multiple MSID:

I think the semantics of what this means is quite clear as long as the 
media description carries source media rather than redundancy data. That 
would mean that a single media source is actually having multiple 
identities in W3C land. That, do make sense, but we have a decision that 
initially we would not allow this optimization and that is encoded in 
draft-ietf-rtcweb-rtp-usage in Section 11, and I quote:

   "It is important to note that the same media source can be feeding
    multiple MediaStreamTracks.  As different sets of constraints or
    other parameters can be applied to the MediaStreamTrack, each
    MediaStreamTrack instance added to a RTCPeerConnection SHALL result
    in an independent source packet stream, with its own set of
    associated packet streams, and thus different SSRC(s)."

So, this could be changed in the future. But we have no idea how we move 
from what we currently have to such a world. I frankly know if allowing 
this usage today is better than forbidding it. If we would change it we 
have the issue that you either fail silently when offering an old client 
the behaviour or getting a signalling failure. I think getting an error 
would be better as that enables one to correct it.

For the second case: Multiple media description (m=) with the same MSID:

This could come in two flavours from my perspective. The first one is 
that the MSID lines are only applied to media description that carries 
source streams. That would mean that one uses some type of scalability 
or other feature that have parts of the encoding sent in different RTP 
streams, and that these RTP streams are not part of the same RTP 
session, otherwise all the SSRCs would be in the same media description.

The second flavour would be to have also redundancy streams to have MSID 
attributes on the media descriptions that represent cases where they are 
send in other RTP sessions. I think this can be avoided as we already 
are using other grouping mechanism to group the encoded stream(s) with 
the redundancy streams.

I would note that assuming that there will be some mechanism that groups 
the related encoded streams, using MSID for that would be redundant. 
Thus, I don't currently see a need for this. However, in this case I 
can't see a negative issue with this case, other than bloating the SDP.

To conclude, I don't like it being allowed, but not specified. I think 
it might be better to indicate that this might be a future extension 
dimensions and make clear that if this occurs an implementation raises 
an error. With the one-way declarative nature of the information the 
attribute itself can't be used to signal the issue in an answer.

cheers

Magnus Westerlund

Flemming Andreasen skrev den 2015-06-25 23:52:
> Greetings MMUSIC
>
> This is to announce a 2 week WGLC on the msid-10 draft:
>
>      https://tools.ietf.org/html/draft-ietf-mmusic-msid-10
>
> as Proposed Standard. Please review and provide any comments you may
> have on the document by Thursday, July 9, 2015. Comments should be sent
> to the document authors and the MMUSIC WG list. If you review the
> document but do not have any comments, please send a note to that effect
> as well.
>
> Thanks
>
> -- Flemming (MMUSIC co-chair)
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 

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: Flemming Andreasen <[email-masked]>
Date: Sun, 19 Jul 2015 17:05:34 -0400

I'm a bit late with comments here as well, but here it goes:

Overall, the document looks good to me. The reduction in scope and 
resulting document updates has worked out quite well. A few comments 
below nevertheless.

General/Technical comments
==================
- Section 3, first paragraph:
The paragraph talks about the "msid-semantic" attribute, however that 
was gone now.

- Section 3, second last paragraph
<quote>
(This mechanism may be used to signal that a particular MediaStreamTrack 
should be put on temporary hold, but that usage is not specified in this 
memo.)
</quote
I'm a bit confused by this statement. Are you saying that msid does not 
follow the normal RFC 3264 rules for putting media streams on hold ? If 
so, that needs to be clarified (and maybe discussed further). If not, we 
should rephrase and just point to RFC 3264.

- Section 3.2.3
<quote>

    The answer is generated in exactly the same manner as the offer.
    "a=msid" values in the offer do not influence the answer.

</quote>
So to be clear, are MediaStreamTracks unidirectional or is just the 
identifiers that are unidirectional   (would be good to clarify 
explicitly).

Editorial/nits comments
===============
- Section 1.3, 3rd paragraph:
OLD: "and that the BUNDLE"
NEW: "and the BUNDLE"

- Section 3.1, first bullet
Please add a reference after "use the mid RTP attribute"

Thanks

-- Flemming (as individual)

On 6/25/15 5:52 PM, Flemming Andreasen wrote:
> have on the document by Thursday, July 9, 2015. Comments should be 
> sent to the document authors and the MMUSIC WG list. If you review the 
> document but do not have any comments, please send a note to that 
> effect as well.
>
> Thanks
>