Re: [Suspected Junk Mail] New functionality in PR - priority

I think we are a long ways from agreeing on how simulcast and RtpEncodingParameters work and they are going to turn out to be complicated. I agree that we will want to be able to set the priority separately for different layers but it's not clear what objects will represent that. We can figure all of that out later but even then, we will want the simple case to be simple and for people that are not using layered codecs or other weird encodings, they are just going to want to set this at a RtpSender level. 

I'm not saying that we don't *also* need this at whatever the per layer object is - we do - and that will probably be RtpEncodingParameters but I still think that having this at the RtpSender is the right thing. So for the simple stuff I would like to add this spec now on RtPSender and when we figure out where else it is needed we can add that then. 


> On May 22, 2015, at 8:02 AM, Peter Thatcher <pthatcher@google.com> 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).  Did I simply miss the thread where we discusses this?
> 
> On Fri, May 22, 2015 at 5:52 AM, Harald Alvestrand <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).
> 
> Harald
> 
>

Received on Wednesday, 27 May 2015 21:52:17 UTC