Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve definition of required fields in RTCRtpParameters #1610

Closed
wants to merge 1 commit into from

Conversation

soareschen
Copy link
Contributor

Fixes #1493.

This PR attempts to clarify which fields are required in the RTCRtpParameters dictionary returned from getParameters(). I have also factor out the transactionId and degradationPreference fields to a new dictionary RTCRtpSenderParameters, since these two fields are required only for RTCRtpSender.

It would be great if someone with more experience on RTP parameters can verify whether some of the fields marked required make sense. Note that we'd also have to consider the case when no SDP has been set yet, e.g. pc.addTransceiver().sender.getParameters() before any offer is generated.

Copy link
Contributor

@taylor-b taylor-b left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think any of the changes in this PR really buy us anything. The issue this is trying to solve is:

when writing applications and tests we cannot make assumption of any of the field returned from getParameters() is defined.

But required doesn't help there. required only tells you what things the JS->IDL binding validates on input, not what fields are required of the implementation on output. Ultimately that must be described in prose. Remember this? whatwg/webidl#382

@@ -4524,7 +4524,7 @@ <h2 id="sec.cert-mgmt">Certificate Management</h2>
given as an argument is already being sent to avoid sending
the same <code>MediaStreamTrack</code> twice, the other ways
do not, allowing the same <code>MediaStreamTrack</code> (possibly
using different <code><a>RTCRtpParameters</a></code> with different
using different <code><a>RTCRtpSenderParameters</a></code> with different
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know that introducing the RTCRtpSenderParameters dictionary is really worth it. It's one more dictionary to keep track of and one more link to follow, vs. two fields that are described as "sender-only."

@@ -5972,8 +5981,8 @@ <h2 id="sec.cert-mgmt">Certificate Management</h2>
</div>
<div>
<pre class="idl">dictionary RTCRtcpParameters {
DOMString cname;
boolean reducedSize;
required DOMString cname;
Copy link
Contributor

@taylor-b taylor-b Sep 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need these to be marked required, or anything else in RtpParameters. The input validation is handled by comparing against [[LastReturnedParameters]].

@@ -5271,8 +5271,8 @@ <h2 id="sec.cert-mgmt">Certificate Management</h2>
readonly attribute RTCDtlsTransport? transport;
readonly attribute RTCDtlsTransport? rtcpTransport; // Feature at risk
static RTCRtpCapabilities getCapabilities (DOMString kind);
Promise&lt;void&gt; setParameters (optional RTCRtpParameters parameters);
RTCRtpParameters getParameters ();
Promise&lt;void&gt; setParameters (RTCRtpSenderParameters parameters);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be optional. It's a weird WebIDL thing. #419

@aboba
Copy link
Contributor

aboba commented Sep 28, 2017

As noted in the above WebIDL link, required is generally used for inputs to the browser, rather than outputs. If there is ambiguity, we should fix this in the specification text.

@aboba aboba closed this Sep 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants