Re: [MMUSIC] MSID draft -09 posted

[Harald Alvestrand <[e-mail]>]

I have now posted -10 with the changes to address Paul's review.
Thanks again!

Harald

Den 23. april 2015 14:49, skrev Harald Alvestrand:
> Den 21. april 2015 18:25, skrev Paul Kyzivat:
>> This draft is a lot simpler to review with its reduced scope!
> 
> 
> Thanks for the quick review!
>>
>> I have a few comments:
>>
>> * Section 2:
>>
>>    ... This new attribute allows endpoints to associate RTP
>>    media streams that are carried in *the same or* different media
>>    descriptions. ...
>>
>> How do you associate distinct MSIDs to media streams in *the same* media
>> description??? AFAIK that isn't possible - each media description is a
>> distinct media stream.
> 
> Yes, this is a leftover from "plan b". Deleting.
> Also, it should be "described", not "carried" - they're carried in RTP
> sessions, and described in media descriptions.
> 
>>
>> * Section 3:
>>
>>    The semantic token for this semantic is "WMS" (short for WebRTC Media
>>    Stream).
>>
>> The above seems to be a leftover that should be removed.
> 
> Yep.
> 
>>
>> IMO the following is very confusing in its use of "description". I've
>> highlighted the points at issue with *s:
> 
> This is a result of the wholesale replacement of "m-line" with "media
> description" - the meanings are unchanged, but it's a bit more obvious
> where the grammar is convoluted.
> 
>>
>>    The following are the rules for handling updates of the list of
>>    *media descriptions* and their msid values.
>>
>>    o  When a new msid "identifier" value occurs in *the* description the
>>       recipient can signal to its application that a new MediaStream has
>>       been added.
>>
>>    o  When *a description* is updated to have more media descriptions
>>       with the same msid "identifier" value, but different "appdata"
>>       values, the recipient can signal to its application that new
>>       MediaStreamTracks have been added to the MediaStream.
>>
>>    o  When *a description* is updated to no longer list any msid
>>       values, on a specific media description, the recipient can signal
>>       to its application that the corresponding MediaStreamTrack has
>>       ended.
>>
>> I *think* that in some cases you mean *session description* (the whole
>> SDP), and in other cases you mean *media description* (m-line and the
>> associated following non-m-lines.) Perhaps:
>>
>>    The following are the rules for handling updates of the list of media
>>    descriptions and their msid values.
>>
>>    o  When a new msid "identifier" value occurs in a media description,
>>       the recipient can signal to its application that a new
>>       MediaStream has been added.
>>
>>    o  When a session description is updated to have more media
>>       descriptions with the same msid "identifier" value, but different
>>       "appdata" values, the recipient can signal to its application
>>       that new MediaStreamTracks have been added to the MediaStream.
>>
>>    o  When a session description is updated to no longer list any msid
>>       attribute on a specific media description, the recipient can
>>       signal to its application that the corresponding MediaStreamTrack
>>       has ended.
> 
> Seems much better, I adapted some more - the use of standalone
> "description" was a bad idea, and I think I've fixed that.
> 
>>
>> * Section 3.2.2:
>>
>>    For each media description in the offer, and for each "a=msid"
>>    attribute in the media description where the "msid-id" is associated
>>    with the "WMS" semantic, the receiver of the offer will perform the
>>    following steps:
>>
>> In the above, there is still reference to WMS semantic that should be
>> removed.
> 
> Removed!
> 
>>
>> Also, this again implies that there might be multiple a=msid lines in a
>> single media description. How about:
>>
>>    For each media description in the offer that contains an "a=msid"
>>    attribute, the receiver of the offer will perform the following
>>    steps:
> 
> Actually this is intended to allow for one track being part of multiple
> MediaStreams. If we have:
> 
> m=video
> a=msid stream1 track1
> a=msid stream2 track1
> 
> this would say "track1 is only sent once, but it appears as part of two
> MediaStreams".
> 
> The API for PeerConnection still allows that. So I need to allow it here
> too.
> 
> I put up the changes I made here:
> 
> https://github.com/alvestrand/rtcweb-msid/pull/4
> 
> Will leave them up there for a day or two, and submit a -10 if there
> aren't further comments.
> 
> Thanks again!
> 
>    Harald
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>