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

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

On 5/11/13 6:24 PM, Paul Kyzivat wrote:
> On 5/11/13 7:50 AM, Stefan Håkansson LK wrote:
>> On 5/10/13 11:20 PM, Paul Kyzivat wrote:
>
>>> 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.
>
> Are you thinking that there will be an SDP change every time the speaker
> changes???
>
> Or do you mean changes when participants join and leave a conference?

I meant the former (at speaker change).

I guess that different designs can be chosen for media from central node 
to end-user clients, and some of them (as Bernard pointed out) would not 
require any signaling. Still, there might be cases where signaling is 
needed.

But leaving that aside, we still have the case of the media end-user 
client -> central node. If you're serious about not wasting bandwidth 
(and with my radio/mobile background I am sort of obsessed :-) ) all 
end-user clients which do not end up as main video anywhere should only 
transmit a low resolution video. So at every speaker change there would 
be at least one client that is asked to stop sending high resolution and 
only transmit low resolution, and one client that is asked to start 
transmitting high resolution video.

I think that this would best be done using some RTCP signaling scheme, 
but I also think there was an agreement a long time ago that SDP O/A 
should be used. In this case either to transmit a new imageattr value 
requesting another resolution, or to pause/resume - using recv on/off in 
Plan B or the direction attribute in Plan A - the low and high 
resolution simulcast streams accordingly (or I assume to pause/resume 
the enhancement layers if a scalable codec is used).

>
> I would hope there will normally not be SDP changes for either of those
> events.

I would like to avoid them too, but I'm not sure how.

>
>> 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.
>
> I'm sure it will happen. The question is whether it happens often enough
> to do more than count on the normal glare recovery procedures.
>
> 	Thanks,
> 	Paul
>
>