Re: [rtcweb] Plan A, respun

[Martin Thomson <[e-mail]>]

On 9 May 2013 04:41, Stefan Håkansson LK
<[e-mail]> wrote:
>> 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)

I think that you have it understood.

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

Yep.