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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Dec 2013 17:01:05 -0500

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/

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

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

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

    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.

    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?

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

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