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

["Belling, Thomas (NSN - DE/Munich)" <[e-mail]>]

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. 


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



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