Re: [MMUSIC] [rtcweb] Plan A, respun

A couple of questions (and sorry for the rtcweb/webrtc centric 
perspective) for clarification:

* How would the info about PC-track and PC-stream id's be conveyed (I 
assume the msid draft)?

* What is your thinking regarding mapping between PC-tracks and m-lines? 
For example, if Alice's app initiates a session with two video 
PC-track's flowing to Bob's app, that would presumable create a session 
with two sendonly m-lines. If, at a later stage, Bob's app upgrades the 
session by sending three video PC-tracks to Alice's app. How would the 
Bob -> Alice video PC-tracks be allocated to the existing m-lines 
(becoming sendrecv), and how would pick which one to use a new m-line? 
E.g., would it be random, or should the app decide, and based on what in 
that case?

Stefan

On 2013-05-07 20:30, Adam Roach wrote:
> In order to facilitate discussion between the two SDP format
> alternatives we're considering, I've put together a document that more
> clearly spells out the Plan A approach as we originally envisioned it.
> Note that this is a slightly different approach than Cullen outlined in
> Orlando. I fear the Orlando approach may have suffered from its attempts
> to incorporate some elements of Plan B in an attempt to appease
> proponents of that approach; and, in doing so, lost some of its clean
> architecture.
>
> The cleaned up, new-and-improved description of the Plan A approach is
> available here:
>
> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt
>
> Note that we've omitted discussion of glare reduction from that
> document, as I believe that mid-session glare can be completely avoided
> by applications implementing a set of non-normative behaviors. These
> behaviors are described in the a separate companion document:
>
> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt
>
> Thanks.
>
> /a
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb