Re: [MMUSIC] Unified Plan for SDP Handling - msid attribute and media stream track

[Harald Alvestrand <[e-mail]>]

On 07/18/2013 03:06 PM, Belling, Thomas (NSN - DE/Munich) wrote:
> Dear Adam, all,
>
>
> good to see significant progress.
>
>
> One aspect I still struggle to understand is the need for the "msid" attribute.
>
>
>
> The draft says:
>
> 2.  Solution Overview
>
>     At a high level, the solution described in this document can be
>     summarized as follows:
>
>     1.  Each media stream track is represented by its own unique m-line.
>         This is a strict one-to-one mapping; a single media stream track
>         cannot be spread across several m-lines, nor may a single m-line
>         represent multiple media stream tracks. ...
>
>     3.  Each m-line contains an MSID value to correlate it with a Media
>         Stream ID and the Media Stream Track ID.
>
>
> 3.2.2.  Correlating Media Stream Tracks with m-lines
>
>     Media Stream Tracks IDs are correlated with M-Lines directly by
>     including an MSID in each m-line.  The MSID also provides the Media
>     Stream ID.  (Note the format of the MSID used here is slightly
>     different than what was proposed in the current MSID draft as that
>     draft assumed multiple tracks in a single m-line and this proposal
>     moves to a solution where there is a one to one relation between the
>     Track and MSID.  This work assumes the MSID draft will be updated to
>     match the syntax used user which simply provides the value of the
>     MediaStream ID and MediaStreamTrack ID on an "a=msid" line.  )
>
>
> The draft lacks a related references, but seems to refer to draft-ietf-mmusic-msid-00. However, it is assuming some not yet documented modifications of that draft, which does not simplify the understanding (hopefully only a problem for a short time). What you have in mind seems no longer an extension of the a=ssrc attribute but an own SDP attribute.

I'll fix the MSID draft once I-D submission reopens. Yes, when an MSID 
is to be assigned for a whole M-line, it needs to be its own attribute, 
not an a=ssrc attribute (and that is the only change that needs to be 
made, I think).
>
>
> Unfortunately there is no definition of media stream track.
>
> More fundamentally, do we require the term "media stream track" at all (rather than simply speaking about m-lines), if there is a one-to-one mapping to a unique m-line?

I think it would actually be better if this draft talked in terms of 
media sources (as defined in the taxonomy draft I noted in my review), 
and just mentioned that in the case of WebRTC, a media source 
corresponds to the JavaScript object called MediaStreamTrack.

> And do we require an extra identifier for it, in addition of the position (that could also be expressed by an ordinal number in some separate protocol or for cross-referencing within SDP) of the m-line in the SDP?
> I suspect the need for a new identifier of the m-line/media stream track has something to do with partial SDP offers? But could the identifier not still be the ordinal number with respect to the "full" SDP (or the next free number if an m-line is added), and be restricted to partial offers?
>
>
> The msid attribute also assings a "media stream ID", but your draft does not describe at all what that ID would be used for.

The ID of a WEBRTC MediaStream is defined in 
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#attributes
>
>
>
> Thomas
>
>
>
> ----------------------------------
> Dr. Thomas Belling
> 3GPP Standardisation
> Nokia Siemens Networks
>
>
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of ext Adam Roach
> Sent: Monday, July 15, 2013 9:05 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [MMUSIC] Unified Plan for SDP Handling
>
> [Cross-posting to RTCWEB; follow-ups to MMUSIC, please]
>
> After significant work, Justin, Martin and I have managed to produce a compromise plan that provides a high degree of interoperability with existing devices (and future non-WebRTC devices) while not being excessively onerous for WebRTC implementations or applications that use them. It's been a tricky balancing act, but I think we've found a good mix between the two that can form a solid basis for the working group to move forward.
>
> Rather than summarize the key points of the document in this email, I direct interested parties to section 2 of the document, which summarizes the key aspects of the plan in eight relatively concise bullet points.
>
> I apologize for the late publication date of this document -- there's actually been a lot more work put into coming up with a unified draft than I originally anticipated, and the production of this document took at least two weeks longer than I expected it to.
>
> Note that this document is intended to be a plan for the work to be done in this area, and not a specification in itself. The intention is that its contents are used as the basis for work in several other drafts -- some new, some not -- that form the corpus of work necessary for RTCWEB (and potentially CLUE) to move forward. Except in rare cases, the document does not attempt to explicitly call out venues or documents for such work, as we (or, at the very least, I) anticipate guidance from the various working group chairs to assist in such decisions.
>
> Comments prior to Berlin would be very helpful, although this will clearly be a point of significant discussion at the face-to-face meeting.
>
> Document link:
>
> http://www.ietf.org/id/draft-roach-mmusic-unified-plan-00.txt
>
> /a
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic