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

[Harald Alvestrand <[e-mail]>]

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.

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

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

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

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.

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.

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

>
> * Appendices: I'm ignoring them.
>
>     Thanks,
>     Paul
>
> On 12/17/13 7:24 AM, Ari Keränen wrote:
>> On 12/16/13 4:42 PM, Harald Alvestrand wrote:
>>> On 12/16/2013 03:37 PM, Ari Keränen wrote:
>>>> Hi Roni and Paul,
>>>>
>>>> At the Vancouver meeting we discussed that the MSID draft would need
>>>> more review and input, also regarding it's relationship with the
>>>> app-token draft. You guys volunteered to have a look at the new
>>>> version Harald submitted during the meeting:
>>>> http://tools.ietf.org/html/draft-ietf-mmusic-msid-02
>>>>
>>>> When you have a chance, would be great if you can check out the draft
>>>> and post your comments on the list.
>>>>
>>>>
>>>> Thanks,
>>>> Ari
>>> There was also significant input on the document in the WEBRTC WG
>>> meeting in Shenzhen - especially around the subject of non-signalled
>>> SSRCs.
>>>
>>> I'll issue an updated version based on that; if you can get feedback in
>>> soon I can incorporate that too.
>>>
>>
>> Thanks for the update Harald! Could you summarize that input to the
>> mailing list so that the WG is up to speed with the discussion?
>>
>>
>> Cheers,
>> Ari
>>
>


-- 
Surveillance is pervasive. Go Dark.