Re: [MMUSIC] Unified Plan for SDP Handling

On 7/15/13 9:06 PM, Adam Roach wrote:
> [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.

Thanks for doing this work, I hope that we now finally can get going on 
specifying this up (and I hope it won't take too long to do so!).

I think this looks like a really good start, and there is a lot I like 
(e.g. the independent signaling per MediaStreamTrack).

I have a couple of specific questions/comments, coming from a very 
WebRTC centric (sorry for that) perspective:

* Simulcast: In the current API model, MediaStreamTrack is about the 
lowest you can get to. And the same source (camera, microphone) can 
source several MediaStreamTrack - and each of those can use individual 
constraints for width, height, framerate, etc. So in a WebRTC context, 
there seem to me we would not need the simulcast solution you have 
included. The different resolutions can be sent as different 
MediaStreamTrack's - meaning they would be separate m-lines.

* Direction attribute: The current WebRTC API is "sender" oriented: the 
application can select MediaStream(Track)'s to send. Would it for WebRTC 
make sense to have all m-lines being unidirectional (send/recvonly)? (If 
they should be sendrecv we also need to specify when a return track 
should reuse an existing m-line, and when a new m-line should be created.)

Stefan

>
> 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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>