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

[Paul Kyzivat <[e-mail]>]

inline

On 8/19/13 10:57 AM, Harald Alvestrand wrote:
> 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!

I didn't have anything specific in mind other than what is below.
But I just got the feeling when reading it that it was still oriented 
towards the old model.

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

In part it is just nit picking by me.
It might be that you can just not say this at all, at least here.
In the context in which the statement is made it is hard to see what 
sort of uniqueness is being required.

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

IIUC, MediaStreamTrack ought to be synonymous with a CLUE 
capture-encoding. But I don't think we have anything in CLUE that 
corresponds to a MediaStream. I don't understand MediaStream very well, 
but perhaps it is indeed unique to WebRTC.

The taxonomy draft is perhaps the right reference here.

>> 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'm picking at the meaning of words. To me "on" an m-line means that it 
is present within the characters that comprise the m-line itself. No 
"attribute" works that way.

I presume you are using "on" as synonymous with "attached to", or 
"associated with". So I was simply suggesting being more explicit.

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

I wasn't talking about any of that.

Its a WebRTC issue whether the same logical stream of packets can be 
part of multiple MediaStreams or MediaStreamTracks. So I'll take your 
word for it.

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

Yes.

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

It words two ways:
- the text referring back to the elements from the ABNF
- when I look at the ABNF, understanding what concept in the text
   this element refers to.

When reading, I encountered both of those problems.
Eventually I can figure it out by going through an exercise of "what 
could this possibly mean". But it would be nice if it was clearer

	Thanks,
	Paul

> But your mileage may vary.

I realize this is to some extent a matter of taste.

Personally, I find that ABNF non-terminals are cheap, so I am happy to 
use more of them to increase clarity. In particular I'm inclined to 
ensure that there is a well-named non-terminal for every element that 
needs to be referenced from the text.

	Thanks,
	Paul

>> 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
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>