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: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 7 Dec 2016 18:50:37 +0100
To: 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: <7adbb564-f48f-9cf3-6541-24f1c0e133f8@alvestrand.no>
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.

Are you talking about DHCP codepoints?
What's worse, there's no way the sender can know that it's not being
bleached out on the first hop, so even if it *can* set the DHCP
codepoint, that doesn't mean it'll be honored.

Luckily(?), there are 2 points influenced by priority: DHCP and local
queueing. So it's not quite "set and pray".

(I'm hoping Windows eventually fixes its deficency....)
Received on Wednesday, 7 December 2016 17:51:13 UTC

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