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

On Wed, May 27, 2015 at 2:51 PM, Cullen Jennings <fluffy@iii.ca> wrote:

>
> 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.
>


​As far as I understand, 1.0 will only have on
​e​
RtpEncodingParameters
​value ​
(no simulcast), in which case being at the encoding level is equivalent to
being at the RtpSender level.
​  In other words, for 1.0, there really isn't a distinction except to
allow it in the future to be at the encoding level rather than the
RtpSender level.

But even if at the RtpSender level and not the encoding level, it should be
part of RtpParameters and set via RtpSender.setParameters, not by a
separate attribute, so that all parameters, including priority, can be made
in one atomic change (or not, if rejected).
​

>
>
> > 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
> >
> >
>
>