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

Interfacing between WebRTC spec and JSEP #337

Closed
dontcallmedom opened this Issue Oct 16, 2015 · 12 comments

Comments

Projects
None yet
7 participants
@dontcallmedom
Member

dontcallmedom commented Oct 16, 2015

When reading through the spec, there are a number of explicit and many more implicit references made to processes defined in JSEP, making it hard to read the doc from top to bottom, and making it hard to read e.g. with a view of creating test cases (I assume it also makes it harder to implement the spec).

That is even more so since JSEP has conformance requirements that overlap with ones set in the WebRTC spec.

I think a cleaner interfacing of the specs would be to set all the conformance requirements in the WebRTC 1.0 spec, and have JSEP define algorithms that the WebRTC spec can then reference explicitly. For instance, JSEP would define an algorithm with the name "apply an ICE candidate" (cf #336), would define an algorithm called "verify user-supplied SDP" which would be referenced from setLD/setRD, etc.

I realize that this is a potentially major set of editorial work across two specs and groups, so it may not be realistic to achieve it pre-CR, but it might be something achievable as part of the "rolling" CR process.

@stefhak

This comment has been minimized.

Contributor

stefhak commented Nov 25, 2015

At TPAC we decided that @dontcallmedom and @ekr would look into the cross ref to JSEP.

@dontcallmedom

This comment has been minimized.

Member

dontcallmedom commented Dec 7, 2015

Once #423 gets merged, at least the following references need to be made more specific:

  • If <var>description</var> is set as a remote description with new media descriptions [[!JSEP]], the User Agent MUST <a href="#dispatch-receiver">dispatch a receiver</a> for all new media descriptions.
  • <p>Doing so will cause future calls to <code>createOffer</code> and <code>createAnswer</code> to mark the corresponding <a>media description</a> as <code>sendrecv</code> or <code>sendonly</code>, as defined in [[!JSEP]].
  • <p>Stops sending media from <var>sender</var>. The <code><a>RTCRtpSender</a></code> will still appear in <code>getSenders</code>. Doing so will cause future calls to <code>createOffer</code> to mark the <a>media description</a> for the corresponding transceiver as <code>recvonly</code> or <code>inactive</code>, as defined in [[!JSEP]].
  • <p>Adding a transceiver will cause future calls to <code>createOffer</code> to add a <a>media description</a> for the corresponding transceiver, as defined in [[!JSEP]].
  • <p>If <code>init.sendEncodings</code> is set, then subsequent calls to <code>createOffer</code> will be configured to send with multiple RTP encodings as defined in [[!JSEP]]. When <code>setRemoteDescription</code> is called with a corresponding remote description that is able to receive multiple RTP encodings as defined in [[!JSEP]], the <code>RTCRtpSender</code> may send multiple RTP encodings and the parameters in <code>RTCRtpTransceiver.sender.getParameters()</code> will reflect the encodings negotiated.
  • <p>To <dfn id="dispatch-receiver">dispatch a receiver</dfn> for an incoming media description [[!JSEP]], the user agent MUST run the following steps:
  • <p> If set, this RTP encoding will be sent with the RID header extension as defined by [[!JSEP]].
@burnburn

This comment has been minimized.

Contributor

burnburn commented Mar 17, 2016

I have created PR #549 that contains all the references I thought reasonable to add at this time. The remaining ones (do "grep -n JSEP webrtc.html | grep -v data-jsep" to find them) are either mentions that don't require changes or places where there truly is no JSEP section written yet to use as a reference.
As I noted in the PR, I was often able to reference an existing section where the explanation likely will be one of these days even if the actual text is currently missing from that JSEP section.

@dontcallmedom

This comment has been minimized.

Member

dontcallmedom commented Mar 17, 2016

great, thanks!

I think it would be useful to create (when necessary) and document the JSEP issues that match the gaps we know of in the WebRTC API spec. That way, when these issues get closed, we know what part of our spec to update and we can more easily verify that the additions to JSEP match our approach in the API.

@dontcallmedom

This comment has been minimized.

Member

dontcallmedom commented Apr 20, 2016

Looking at the latest version of the spec, the following JSEP references are still non-specific:

  • When setRemoteDescription is called with a corresponding remote description that is able to receive multiple RTP encodings as defined in [[!JSEP]], the RTCRtpSender may send multiple RTP encodings and the parameters retrieved via the transceiver’s sender.getParameters() will reflect the encodings negotiated.
  • If set, this RTP encoding will be sent with the RID header extension as defined by [[!JSEP]]
  • The midattribute is the mid negotatiated and present in the local and remote descriptions as defined in [[!JSEP]]
  • The failed and completed states require an indication that there are no additional remote candidates. This can be indicated either by canTrickleIceCandidates being set to false, or the processing of an end-of-candidates indication as described in [[!JSEP]]

We should:

  • determine if the latest JSEP version has now text for these, and if so update the references
  • if not, create a webrtc-pc issue for each of these, and refer from it to the matching issue in rtcweb-jsep (creating it if there is none yet)
@elagerway

This comment has been minimized.

Contributor

elagerway commented Apr 28, 2016

Dan will perform necessary checks when time permits

@fluffy

This comment has been minimized.

Contributor

fluffy commented May 27, 2016

@burnburn - Do you need any more anchors in the JSEP spec?

@burnburn

This comment has been minimized.

Contributor

burnburn commented Jun 1, 2016

@fluffy Don't know yet. I'm just going through every reference individually and checking it. I'm working on it some more now. I'll know when I reach the end of the webrtc spec :)

@burnburn

This comment has been minimized.

Contributor

burnburn commented Jun 29, 2016

I have now reviewed every occurrence of 'JSEP' in the spec before the change log and filed an issue and/or PR for any that do not appear to have an accurate reference. We can either keep this issue open until the others are all closed or close this one assuming no new invalid or incomplete JSEP references will be added. Of course, the original suggestion by @dontcallmedom still exists and has not been done (officially, although we have informally moved in that direction).

@burnburn

This comment has been minimized.

Contributor

burnburn commented Aug 18, 2016

@alvestrand Since I have been through all references to JSEP in the doc I am okay with closing this one now unless you want to keep Dom's original request (regarding algorithm definitions in JSEP and conformance requirements in W3C spec) alive.

@dontcallmedom

This comment has been minimized.

Member

dontcallmedom commented Aug 18, 2016

Re algorithms in JSEP and conformance in W3C spec, the JSEP editors weren't interested, so unfortunately, I don't think that's going to happen; as a result, I wouldn't keep that issue open just for that.

@alvestrand

This comment has been minimized.

Contributor

alvestrand commented Sep 8, 2016

Closing as "not useful to track any more" - individual remaining issues have their own.

@alvestrand alvestrand closed this Sep 8, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment