Re: [MMUSIC] Some comments on draft-ietf-mmusic-msid-02

[Paul Kyzivat <[e-mail]>]

More comments inline. I'm not commenting on things were we are in full 
agreement.

*** Note to Roni and Jonathan: need input from you on this ***

On 1/6/14 1:30 PM, Harald Alvestrand wrote:
> Thanks for the review! I'm now trying to get the -03 version out (at
> long last).
>
> The comments have been incorporated. Hope they work out to your
> satisfaction!
>
> On 12/17/2013 11:01 PM, Paul Kyzivat wrote:
>> In Vancouver I volunteered to look at this version of the msid draft,
>> especially wrt its relationship to the app-token draft.
>>
>> After looking, IMO some things can be done to this draft that will not
>> effect its substance, but will more clearly separate its concerns from
>> those of app-token and unified-plan.
>>
>> The unified-plan has gotten us to a point where individual source
>> streams each have their own m-line.
>>
>> The app-token draft is defining a mechanism that will provide allow a
>> level of indirection to SSRCs. That hasn't matured to the point of
>> being picked up in unified-plan, but I hope it eventually will be.
>>
>> The problem I see now is that this msid draft is still filled with
>> lots of reference to SSRCs, even though the mechanism it specifies no
>> longer is at all dependent on SSRCs. The mechanism is solely for the
>> purpose of attaching related identifiers to m-lines and groups of
>> m-lines. How those m-lines are associated with SSRCs and/or appids is
>> better left to other documents.
>>
>> If it is so decoupled, then it will be easy to progress this one. Then
>> we can leave it to unified-plan and app-token to do their thing. And
>> in the future, if new mechanisms are defined to bind streams to
>> m-lines, then this document will remain valid.
>>
>> Some specifics:
>>
>> * Section 1.2:
>>
>>     The SDP grouping framework [RFC5888] can be used to group m-lines.
>>     However, there is sometimes the need for an application to specify
>>     some application-level information about the association between the
>>     SSRC and the group.  This is not possible using the SDP grouping
>>     framework.
>>
>> s/SSRC/m-line/
>
> Done.
>>
>> * Section 1.3:
>>
>>     In the RTP specification, media streams are identified using the SSRC
>>     field.  Streams are grouped into RTP Sessions, and also carry a
>>     CNAME.  Neither CNAME nor RTP session correspond to a MediaStream.
>>     Therefore, the association of an RTP media stream to MediaStreams
>>     need to be explicitly signaled.
>>
>> I think this entire paragraph can be dropped. The following paragraph
>> is sufficient.
>
> This is background indicating why CNAME is not an appropriate mechanism.
> While this debate seems to be long over, I'd like to keep the paragraph.

I can live with that.

>> * Section 2:
>>
>>     Endpoints can update the associations between SSRCs as expressed by
>>     msid attributes at any time; the semantics and restrictions of such
>>     grouping and ungrouping are application dependent.
>>
>> s/SSRCs/m-lines/
>
> In this context, I prefer to use "RTP media streams".

I think that still leaves things a bit confusing. There are two kinds of 
interesting changes possible:

1) the association between msid attributes and m-lines can be updated
2) the association between m-lines and RTP streams can be updated

Of these, (1) is directly relevant to this draft, and should be made clear.

Meanwhile, (2) is also important, and may also be worth pointing out in 
this draft. But the mechanics of doing so are in the scope of other drafts.

>> * Section 4:
>>
>>     This section creates a new semantic for use with the framework
>>     defined in Section 2, to be used for associating SSRCs representing
>>     MediaStreamTracks within MediaStreams as defined in
>>     [W3C.WD-webrtc-20120209].
>>
>> s/SSRCs/m-lines/
>
> Done.
>
>>
>>     In a WebRTC-compatible SDP description, all SSRCs intending to be
>>     sent from one peer will be identified in the SDP generated by that
>>     entity.
>>
>> I'm not sure about the above. It's true now based on unified-plan. It
>> might be altered by the use of app-token.
>
> If unified-plan is changed, this will have to be changed too. But it
> doesn't matter for this specification, actually, so I'm deleting this
> paragraph.

OK.

>>
>>     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).
>>
>> Another one I'm not sure about. If app-token is used to define
>> m-lines, then it ceases to be so clear when the track should close.
>> Maybe it should close if a BYE or timeout is received on the last SSRC
>> bound to the app-token. Or maybe not. This probably needs more work.
>> But is this the right draft to specify that?
>
> This is definitely not the right draft to describe the use of app-token.

Or the use of Unified!

> This text resulted from previous discussions, and was a question in an
> earlier version - I believe Colin Perkins suggested that the
> disappearance according to RTP rules should cause the ending of the
> track too.

I think this may now require further discussion.

> If one track is associated with multiple SSRCs, then it is logical that
> all the SSRCs have to disappear before it is ended; this is already in
> the text.
> No change.

The problem, if there is one, is what it means for SSRCs to be 
associated with an m-line. IIUC, with appid there is only one SSRC 
associated with the m-line at any one time, but which SSRC it is may change.

The problem would come if a BYE was received on the SSRC currently 
associated with the m-line based on appid, and then another packet came 
on a different SSRC and an appid token that ties it to this m-line. I 
don't know what should happen in this case. I'd like to hear from Roni 
and Jonathan about it.

Clearly what should happen in that case is not something for this draft 
to address. I just don't want this draft to constrain what should happen 
in that case.

>> * Section 5:
>>
>>     o  The attribute gives an association over a set of m-lines.  It can
>>        be used to signal the relationship between a WebRTC MediaStream
>>        and a set of SSRCs.
>>
>> s/SSRCs/m-lines/
>
> Done.

	Thanks,
	Paul