- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Sat, 26 Apr 2014 18:19:31 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: "Suhas Nandakumar (snandaku)" <snandaku@cisco.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
> On Apr 21, 2014, at 11:49 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
>> On 20 April 2014 12:48, Suhas Nandakumar (snandaku) <snandaku@cisco.com> wrote:
>> interface MediaFlow implements Constrainable
>> {
>> attribute RTCIceConnection iceConnnectionState; // transport state
>> attribute RTCIceGatheringState iceGatheringState; // transport state
>> attribute DOMString CNAME;
>> ...
>> }
>
> 2. As a result of the above, this does a grand hand-wave over the
> details for layering and simulcast. No one has really sat down and
> carefully described what it means to "control" layering. Until I see
> that, I can't make any assessments about proposed APIs.
[BA] In simulcast/SVC systems the control is typically handled at the Scalable Forwarding Unit (SFU), not the browser. It is the SFU that will typically decide when to drop or add layers going to a particular browser endpoint. It may even decide when it no longer needs the browser to send a particular layer or simulcast stream to it (e.g. the pause/resume draft),
As I understand it, the goal of this API work is to support browser rather than SFU applications. As such, the focus needs to be on the controlled entity. There discovery of browser capabilities and configuration of settings is paramount, and surprisingly few bells and whistles may be required to build serviceable implementations.
Received on Saturday, 26 April 2014 18:20:00 UTC