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

From: Harald Alvestrand <[email-masked]>
Date: Mon, 06 Jan 2014 19:30:42 +0100

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jan 2014 14:53:09 -0500

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

> While this debate seems to be long over, I'd like to keep the paragraph.

I can live with that.

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

> doesn't matter for this specification, actually, so I'm deleting this

OK.

> This is definitely not the right draft to describe the use of app-token.

Or the use of Unified!

> disappearance according to RTP rules should cause the ending of the

I think this may now require further discussion.

> all the SSRCs have to disappear before it is ended; this is already in

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.

	Thanks,
	Paul