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

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

On 2013-05-12 20:28, Emil Ivov wrote:
> 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.

I took the result of the discussion and poll at the IETF-84 
(http://tools.ietf.org/wg/rtcweb/minutes?item=minutes-84-rtcweb.html) as 
an indication of that SDP O/A should be used for this kind of in-session 
changes as well.

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

To me it looks like a solution that people might feel inclined towards 
using.

But there are others that want to use simulcast, and then pause/resume 
sending of high and low resolution streams, and that problem is more or 
less the same when it comes to signaling.

And even if we omitted the possibility for a receiver to indicate to the 
sender (via standardized signaling) that it should pause or resume 
sending, and instead left that up to an API (at sender side) and 
proprietary signaling, we still have to have some kind of signaling IMO: 
the sender can not just stop sending RTP packets, there need to be a 
signal to the receiver so it understands this (and does not think there 
are extreme packet losses or some other errors) and can indicate to the 
application at the receiving end (in WebRTC it should result in a "mute" 
event being fired on the PC-track in question).

I think the current assumption is SDP O/A for that kind of signaling.

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