Re: [rtcweb] Plan A, respun

[Stefan Håkansson LK <[e-mail]>]

On 2013-05-08 17:43, Martin Thomson wrote:
> 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).

Right, just wanted it clarified.

>
>> * 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).

OK. So if Alice's app used OfferToReceiveVideo=0, then both m-lines 
would be sendonly, 1 would give one sendrecv and one sendonly and so on.

So, if OfferToReceiveVideo=0 was used (or was even the default), we 
would in the case of a symmetric service (Alices's and Bob's apps 
intending to send the same amount of audio and video tracks, and doing 
it from the start of the session) actually end up with the same 3-way 
handshake as in Plan B (since sendonly/recvonly can't be upgraded to 
sendrecv without a new offer)?

(I have no problem with that behavior, I just want to understand)

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

...because new m-lines are required.

>