Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00

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

On 5/10/13 11:20 PM, Paul Kyzivat wrote:
> On 5/10/13 2:37 AM, Stefan Håkansson LK wrote:
> ...
>> But I can easily think of other situations that would lead to glare for
>> Plan A.
>>
>> Just as an example, think about a conference scenario with a centralized
>> node. Now, one of the participants wants to mute her/his audio, and as a
>> result the audio m-line would go from sendrecv to recvonly. At roughly
>> the same time the server wants to disable the high res video and enable
>> the low res video (because this user will be moved, based e.g. on the
>> recent audio activity, from being displayed in the main video window to
>> be in a thumbnail on the screen of the other participants in the
>> conference), so it wants to manipulate the direction attribute of other
>> m-lines.
>>
>> So there would be two offers sent at roughly the same time, which means
>> we would have glare.
>
> What do you mean by "roughly"?
>
> How long does it take to do an O/A exchange that doesn't require human
> input? Presumably less than a second, maybe considerably less. (Or will
> it be more with RTCWEB and web servers in the path?)

That sounds right to me.

>
> What is the probability that the other side, for independent reasons,
> decides to make a change within that interval? (And it isn't really the
> whole interval - it is only the first part of it.)

Given that in multiparty services the "main" video changes quite often, 
I'd not say this is extremely low. It will happen.

But, given that there is a way to roll-back in a predictable way I think 
glare resolution could be quick - nothing stops the web application from 
including a random number in every offer, and resolve glare based on 
that (one of the offers "win").

So I think glare will happen in practice (that is what I wanted to point 
out), but it is not a show-stopper provided there is a way to roll back.

>
> There may indeed be realistic cases for glare, but they will probably be
> because both changes are keyed to a common event.
>
> 	Thanks,
> 	Paul
>
>