Re: New functionality in PR - priority

On 5/22/15 10:02 AM, Peter Thatcher wrote:
> I think that per-RtpSender is the wrong level for priority.  I think 
> RtpEncodingParameters is the right level.  It's true we don't have a 
> PR for RtpEncodingParameters, but I can fix that very quickly.
>
> Along those lines, has there been consensus on the list for having 
> RtpSender.priority as an attribute?  I would be opposed to that for 
> the same reason I was opposed to making any of the similar settings 
> being attributes, as was proposed recently. Even if it's at the 
> RtpSender level, it should be part of RtpSender.setParameters, so that 
> many like changes can be made atomically (without relying on strange 
> Javascript idiosyncrasies).

What strange Javascript idiosyncrasies? That it's not multi-threaded or 
in need of locking?

>   Did I simply miss the thread where we discusses this?

I didn't see any discussion either, though an attribute seems natural to 
me. Can setting of priority fail?

.: Jan-Ivar :.

> On Fri, May 22, 2015 at 5:52 AM, Harald Alvestrand 
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>
>     Hi,
>
>     just a heads-up (or something like that):
>
>     There's a pull request in the queue for adding a "priority" field to
>     RTPSender and to DataChannels:
>
>     https://github.com/w3c/webrtc-pc/pull/228
>
>     This is to support the priority mechanism specified here:
>
>     draft-ietf-rtcweb-transport section 4
>     draft-ietf-rtcweb-rtp-usage section 12.1.3
>     draft-ietf-tsvwg-rtcweb-qos
>
>     I don't think there's anything controversial in it, but it's nice that
>     the WG is aware of what's happening when we add new functionality into
>     the spec (even when it's been talked about for a long time).
>
>     Haral 
>