- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 10 Aug 2015 13:06:47 +0200
- To: public-webrtc@w3.org
Den 24. juli 2015 15:00, skrev Stefan Håkansson LK: > On 24/07/15 14:44, Peter Thatcher wrote: >> Following the PR from https://github.com/w3c/webrtc-pc/pull/228, I have >> changed RtpEncodingParameters.priority to an enum with very-low, low, >> medium, and high. >> >> This is kind of what we decided a long ago about priorities. But I >> forgot about it when I wrote the PR for RtpEncodingParameters.priority >> and made it a double. This is an update to that. >> >> >> Do we still have consensus for using an enum for priority? Look at the >> PR to see how it looks. > > Which PR is it? Priority seems to be part of #234 and #241. > > Anyway, I have concerns with the part > > <dt>double priority</dt> > + <dd> > + <p> > + Indicates the relative priority of this encoding, across > + all RtpSenders of a given PeerConnection. When there is > + limited bandwidth available to a PeerConnection, higher > + prioirty encodings will be sent with more bandwidth, and > + lower priority encodings will be sent with less > + bandwidth. > > in combination with the upcoming "min" and "max" bitrate attributes. How > should he UA act if they conflict (e.g. a very high "min" and a low > priority)? > > #228 only points at RTCWEB-TRANSPORT and I think that document only > talks about DSCP marking. Wearing my hat as editor of rtcweb-transport: Section 4 talks about prioritization. Section 4.1 talks about mapping priority to DSCP. This points to draft-ietf-dart-dscp-rtp for codepoint assignments. Section 4.2 talks about mapping piority to local prioritization. This talks about stuff that's congestion-controlled under a single congestion controller. Both chapters assume the 4-level classification of priority at the API - section 4 starts with: The WebRTC prioritization model is that the application tells the WebRTC implementation about the priority of media and data flows through an API. The priority associated with a media or data flow is classified as "normal", "below normal", "high" or "very high". There are only four priority levels at the API. The priority settings affect two pieces of behavior: Packet markings and packet send sequence decisions. Each is described in its own section below. Harald
Received on Monday, 10 August 2015 11:07:17 UTC