W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2016

Re: Are we missing error handling for the API setting the QoS priority of data channels?

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 7 Dec 2016 19:00:12 +0000
To: Harald Alvestrand <harald@alvestrand.no>, Bernard Aboba <Bernard.Aboba@microsoft.com>, Peter Thatcher <pthatcher@google.com>, Randell Jesup <rjesup@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <VI1PR0701MB2733D482FC30A15D2962D00EC9850@VI1PR0701MB2733.eurprd07.prod.outlook.com>
On 07/12/16 18:53, Harald Alvestrand wrote:
> Den 07. des. 2016 18:36, skrev Bernard Aboba:
>> The API changes have now been merged into Section 6.2:
>>
>> https://rawgit.com/w3c/webrtc-pc/master/webrtc.html
>>
>>
>>
>> One thing that wasn’t addressed in the merged PR is error handling.
>>
>>
>>
>> For example, on some operating systems (e.g. Windows) it isn’t possible
>> to mark flows differently on the same socket.
>>
>>
>>
>> So if you have audio and video RTP/RTCP and data channel all on the same
>> IceTransport and flowing over the same ICE candidate pair, they would
>> need to be marked at the same priority.
>>
>>
>>
>> If this is really a “do as I say” API, then a request that cannot be
>> fulfilled should result in an error.

Is this a bit similar to "mandatory" constraints and Mac built-in 
cameras? The UA can use specific settings but the OS won't tell if those 
can't be met and therefore the "overconstrained" event can't be fired 
(or the track muted) by the UA. At least this is what I have been told.
Received on Wednesday, 7 December 2016 19:00:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:49 UTC