Re: [rtcweb] Plan A, respun

[Martin Thomson <[e-mail]>]

On 8 May 2013 05:38, Stefan Håkansson LK
<[e-mail]> wrote:
> 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)?

Yes, that's a solved problem. No sense reiterating it in the draft
(it's orthogonal to what the draft actually addresses).

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

Alice's offer would contain at least two m-lines.  Those would not
necessarily be sendonly.  If she was capable of receiving more than 2
inbound, the offer could contain recvonly lines too (I believe that
this fits with the OfferToReceiveVideo=n constraint).  Of course, if
those lines were not compatible with what Bob wanted to send (too
much, different codecs, different constraints, etc...), then Bob is
required to send another offer to get his media out.