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

[Emil Ivov <[e-mail]>]

On Sun, May 12, 2013 at 8:18 PM, Stefan Håkansson LK
<[e-mail]> wrote:
> 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.

Right, however in cases where signalling is indeed needed, should it
really be defined by RTCWEB rather than the application developer?

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

RTCP is just one of the possibilities. This could also be implemented
in a number of other ways that would all be more efficient for the
specific application and all out-of-scope for rtcweb.

> but I also think there was an agreement a long time ago that SDP O/A
> should be used.

Well the way I remember it SDP O/A was chosen for session negotiation
and that other forms of signalling were explicitly left out of the
charter.

> In this case either to transmit a new imageattr value

imageattr is great as a declarative parameter indicating capabilities:
"I can't show more than 720p so there's no point to send me more than
that". Using it as a way to switch between thumbnail and HQ videos is
not entire impossible but is not particularly efficient either.

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

Well we can either figure that out (and it seems that we can't quite
agree on a solution) or make sure APIs have all it takes for the
matter to be resolved by app-to-app signalling.

Emil

--
https://jitsi.org