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

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

On 5/8/13 11:19 PM, Adam Roach wrote:
> On 5/8/13 15:07, Paul Kyzivat wrote:

>> I remain dubious that this glare situation is a problem that needs to
>> be fixed.
>
> So am I, but Justin seems to be obsessed with it. That's why I'm
> proposing a non-normative recipe that allows people who are
> unnecessarily preoccupied with the issue to indulge their peccadillos.
> The rest of us are free to ignore it.

I think that glare coming from simultaneous add or remove of media may 
not be that common.

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.

I think the result would be similar if the server would instead ask for 
another resolution using the imageattr.

You could argue that all control should be left to one end-point, but it 
is sort of clumsy.

Plan B, with the individual control of sources, seems better fitted to 
handle this kind of situations.

>
> /a