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

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.

From: Peter Thatcher [mailto:pthatcher@google.com]
Sent: Monday, November 28, 2016 3:13 PM
To: Randell Jesup <rjesup@mozilla.com>; public-webrtc@w3.org
Subject: Re: Are we missing an API for setting the QoS priority of data channels?

Perhaps now is later.

On Mon, Nov 28, 2016 at 3:05 PM Randell Jesup <rjesup@mozilla.com<mailto:rjesup@mozilla.com>> wrote:
On 11/28/2016 5:08 PM, Michael Tuexen wrote:

On 28 Nov 2016, at 22:50, Peter Thatcher <pthatcher@google.com><mailto:pthatcher@google.com> wrote:



Looking at draft-ietf-tsvwg-rtcweb-qos, it's clear we want to apply the very-low/low/medium/high priority to data channels.  But we don't have any way in the WebRTC API, as far as I can tell, to set that priority.



Is this just something we forgot to add?  If so, I propose that we add it as follows:



dictionary RTCDataChannelInit {

  ...

  RTCPriorityType priority;

}



And it's meaning is defined by draft-ietf-tsvwg-rtcweb-qos.







If not, can someone let me know where in the API this control is?

I thought is was there, but it seems to be missing. I agree, something like you suggest should be added.

Certainly we planned on priority on the IETF side.  I could have sworn we had placeholders for it, but perhaps someone thought "it's a dictionary, we can just add it later").

Sounds good to me


--
Randell Jesup, Mozilla