Re: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-msid-01.txt

[Harald Alvestrand <[e-mail]>]

On 08/15/2013 07:15 PM, Paul Kyzivat wrote:
> I went through this version, with an eye to alignment with the Unified 
> Plan. I have a number of comments, some nits, some not:

Thanks for doing this quickly!

I've incorporated these changes (with some rewording, as always). I'll 
give this a few more days to stew, and then emit a new version.

>
> General:
>
> The Unified Plan says a single m-line describes one media source. It 
> allows this source to consist of multiple RTP Streams (identified by 
> SSRC). And it allows associating RTP Streams with m-lines multiple 
> ways, not just by SSRC.
>
> This msid draft hasn't fully incorporated those concepts. It still 
> seems to assume that a media source corresponds to a single SSRC. It 
> would be helpful to have a section discussion the process of 
> associating SSRCs to MedisStreamTracks. (And I think this needs to 
> include the possibility that an SSRC might be moved from one 
> MediaStreamTrack to another.)

I tried replacing every occurence of SSRC with m-line, except where that 
didn't make sense (and in Appendix B, of course). Please point at the 
text where I missed, if it's not covered below!

>
> Section 2:
>
>    The identifier is a string of ASCII characters chosen from 0-9, a-z,
>    A-Z and - (hyphen), consisting of between 1 and 64 characters. It
>    MUST be unique among the identifier values used in the same SDP
>    session.  It is RECOMMENDED that is generated using a random-number
>    generator.
> ...
>    There may be multiple msid attributes on a single m-line. There may
>    also be multiple m-lines that have the same value for identifier and
>    application data.
>
> What does uniqueness mean in this context, since it can be used 
> multiple times, with the same or different m-lines? I *think* you mean 
> that a given identifier value is associated with a single MediaStream 
> for the duration of the SDP session.

Yes, but I can't write that in section 2, since MediaStreams aren't 
introduced until section 4. The meaning of "uniqueness" has to be 
defined by the msid-semantic, I think - should I add a sentence saying 
that this is so?

(It's tempting to declare that msid is useless for anything except 
WebRTC. But the Paris (?) IETF meeting told me to write a generic 
mechanism with a WebRTC specialization, so that's how it's written.)


>
> Also, msid attributes aren't "on" an m-line. I think it would be 
> clearer to say "Multiple msid attributes may be associated with a 
> single m-line." But with the Unified Plan this isn't true.

Sorry?

I think it's legal to say

m=video
a=msid: 1234 567
a=msid: ABCD EFG

This would mean (for the WMS context) that the same media content is 
present in both MediaStream 1234 and MediaStream ABCD, with 
MediaStreamTrack ids 567 and EFG, respectively.
>
> Also, I find the use of "identifier" and "token" very confusing. It is 
> hard to keep track of the semantics intended for those things. It 
> would be easier to follow if some more specific terms were used. For 
> example, "mediastream-id" instead of "identifier" in the msid and 
> msid-semantics attributes, and "semantics" instead of "token" in 
> msid-semantics attribute. ("semantics" is what is used in 3388 and 5576.)

You're talking about the ABNF in sections 2 and 3 now, right?
We could use more meaningful names for the tokens, but it's just another 
level of indirection - generally, I don't find that specs become much 
more readable by repeated productions of the form

    name1 = name2

unless we have to refer to the tokens by name from surrounding text.
But your mileage may vary.
>
> Section 4:
>
>    o  When a description is updated to have more SSRCs with the same
>       msid value, but different appdata values, the recipient can signal
>       to its application that new MediaStreamTracks have been added to
>       the media stream.
>
> Is SSRC relevant any longer? s/SSRCs/m-lines/ ???

Yep, I missed that (multiple misses in that section). Will update.

>
> Also in Section 4:
>
>    In addition to signaling that the track is closed when it disappears
>    from the SDP, the track will also be signaled as being closed when
>    all associated SSRCs have disappeared by the rules of [RFC3550]
>    section 6.3.4 (BYE packet received) and 6.3.5 (timeout).
>
> Here we can't avoid talking about SSRCs. But maybe more is needed 
> about what SSRCs are associated with a particular m-line & msid value?

Since this is in section 4 (WebRTC), I can happily point that problem 
off to unified-plan or its successors.
>
> Section 4.1:
>
>    Pre-WebRTC entities will not send msid.  This means that there will
>    be some incoming RTP packets with SSRCs where the recipient does not
>    know about a corresponding MediaStream id.
>
> In the context of the Unified Plan I think this could be stated better:
>
>    There may be some incoming RTP packets that the recipient cannot
>    associate with a MediaStreamTrack.

Rephrased, not quite like this.

>
> Also:
>
>    o  An msid-semantic:WMS attribute is present.  In this case, the
>       session is WebRTC compatible, and the newly arrived SSRCs are
>       either caused by a bug or by timing skew between the arrival of
>       ...
>
> I suggest:
>
>    o  An msid-semantic:WMS attribute is present.  In this case, the
>       session is WebRTC compatible, and the unassociated packets are
>       either caused by a bug or by timing skew between the arrival of

Done.

> ...
>
>     Thanks,
>     Paul
>
>
> On 8/13/13 2:24 PM, Harald Alvestrand wrote:
>> The auto-poster doesn't seem to want to tell mmusic about this....
>>
>> this is updated according to Unified-plan. Since it was only 1 day
>> before the old version had expired, the proofreading might be a little
>> light - please point out places where I had missed changing "SSRC" to
>> "m-line"!
>>
>> I retained some description of the old mechanism (using a=ssrc) in an
>> appendix. Please state opinions on whether this should be retained as
>> informative, promoted to normative, or removed entirely in the next 
>> version.
>>
>> Hope this informs!
>>
>>         Harald
>>
>>
>> -------- Original Message --------
>> Subject:     New Version Notification for draft-ietf-mmusic-msid-01.txt
>> Date:     Tue, 13 Aug 2013 05:13:42 -0700
>> From:     [e-mail]
>> To:     Harald T. Alvestrand <[e-mail]>, Harald Alvestrand
>> <[e-mail]>
>>
>>
>>
>> A new version of I-D, draft-ietf-mmusic-msid-01.txt
>> has been successfully submitted by Harald Alvestrand and posted to the
>> IETF repository.
>>
>> Filename:     draft-ietf-mmusic-msid
>> Revision:     01
>> Title:         Cross Session Stream Identification in the Session 
>> Description Protocol
>> Creation date:     2013-08-13
>> Group:         mmusic
>> Number of pages: 14
>> URL:http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-01.txt
>> Status:http://datatracker.ietf.org/doc/draft-ietf-mmusic-msid
>> Htmlized:http://tools.ietf.org/html/draft-ietf-mmusic-msid-01
>> Diff:http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-01
>>
>> Abstract:
>>     This document specifies a grouping mechanism for RTP media streams
>>     that can be used to specify relations between media streams.
>>
>>     This mechanism is used to signal the association between the SDP
>>     concept of "m-line" and the WebRTC concept of "MediaStream" /
>>     "MediaStreamTrack" using SDP signaling.
>>
>>     This document is a work item of the MMUSIC WG, whose discussion list
>>     [e-mail].
>>
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic