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: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Thu, 8 Dec 2016 04:33:49 +0000
To: Stefan Håkansson <stefan.lk.hakansson@ericsson.com>
CC: 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: <201FC33B-62DC-406A-B02C-ADD292BDE836@cisco.com>

> On Dec 7, 2016, at 12:00 PM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:
> 
> 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.
> 
> 

The short summary of previous discussion on this is roughly ... pretty much all modern OS that have not been obsoleted by their manufacture allow setting of DSCP given varying levels of programming effort but yes it is harder on XP than one might wish. However, assume that the OS did it perfectly, the first IP switch it reaches very well may change the DSCP to zero and in this case no error will be reported to the browser. So JS applications that use DSCP more or less need to view it as a hint and not a certainty that it will work. That lead us to put weak wording in the draft about what needs to happen that does allows not doing it on OS that don't support it and allows not reporting errors when it does not happen. 

I'll also note that more and more we are seeing networks both inside campuses and across SP cellular that can guarantee end to end DSCP handling across a defined set of networks.  





Received on Thursday, 8 December 2016 04:34:26 UTC

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