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

[Paul Kyzivat <[e-mail]>]

I went through this version, with an eye to alignment with the Unified 
Plan. I have a number of comments, some nits, some not:

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

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.

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.

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

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

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?

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.

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

	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
>