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

From: Harald Alvestrand <[email-masked]>
Date: Sun, 13 Sep 2015 16:06:27 -0700

On 07/14/2015 10:43 AM, Magnus Westerlund wrote:
> 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)."

Not so fast..... there's a difference betweeen having one source feeding
multiple tracks, resulting in mulitple packet streams, and the case of
one MediaStreamTrack being present in multiple MediaStreams.

When we redesigned the API to use AddTrack rather than AddStream, we let
the list of associated streams for a track be a list rather than a
single value for that precise reason.

So I'd say the semantics of multiple MSIDs is well defined - it signals
a single MediaStreamTrack (with a single set of constraints) that is
present in multiple MediaStreams.

I'll try to make that clear.

>
> 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.

The API design currently allows for having a track be on multiple
streams. So I think that needs to be permitted.

>
> 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.

If there are multiple media sections used to describe redundancy
features, I'm happy to see MSIDs used only to identify the base layer.
I'll make the identical values "not permitted".

>
> 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
>>
>
>

-- 
Surveillance is pervasive. Go Dark.

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 13 Sep 2015 16:18:10 -0700

This got lost in the post-IETF shuffle - thanks for the reminder that it
was outstanding!

On 07/19/2015 02:05 PM, Flemming Andreasen wrote:
> 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.
Gone, thanks!
>
> - 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.

I deleted the parenthetical remark altogether. It adds no value.
The important thing the paragraph says is "this does not close the
MediaStreamTrack".

>
> - 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).

MediaStreamTracks are unidirectional. I added this to the introduction
(1.3), where they are first described.

>
>
>
>
> Editorial/nits comments
> ===============
> - Section 1.3, 3rd paragraph:
> OLD: "and that the BUNDLE"
> NEW: "and the BUNDLE"
Done.
>
> - Section 3.1, first bullet
> Please add a reference after "use the mid RTP attribute"

Reference to BUNDLE added.
> Thanks

My pleasure!

>
> -- Flemming (as individual)
>
>
> On 6/25/15 5:52 PM, Flemming Andreasen wrote:
>> Greetings MMUSIC
>>
>> 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
>>