W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2014

Proposal for RtpSender.getParameters and .setParameters

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 03 Nov 2014 21:16:22 +0000
Message-ID: <CAJrXDUHYtXfXX+pe6DvL_Zru7ihXeAzfkkQJh6WnC5NGXBNZCg@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
At TPAC (2014), we reached consensus that we want some form or
RtpSender.getParameters and RtpSender.setParameters.  But we had three
issues to resolve:

1. What's the async pattern?
2. What's the current vs. proposed?  (punt;  when we deal with
3. What's the minimal set of controls?

For #1, I propose we return a Promise from setParameters(), like so:

partial interface RTCRtpSender {
  RTCRtpParameters getParameters();
  Promise setParameters(RTCRtpParameters parameters);

If setParameters fails, the returned Promise fires an error.  If
setParameters succeeds (and when onnegotiationneeded is fired for
parameters that require negotiation), then the returned Promise fires

.getParameters() always return the current parameters being used to send.

For #3, I propose the following as the absolute minimum:

dictionary RTCRtpParameters {
  sequence<RTCRtpEncodingParameters> encodings;

dictionary RTCRtpEncodingParameters {
   boolean active = true; // sending or "paused/onhold"

I think everyone agrees that we would want that in our minimal set.  And to
that minimal set, I also propose we also add maxBitrate:

dictionary RTCRtpEncodingParameters {
    boolean active = true; // sending or "paused/onhold"
    unsigned long maxBitrate = null;

But please propose your own additions to this minimal foundation.
Received on Monday, 3 November 2014 21:16:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:42 UTC