Re: [webrtc-tests] Adding a basic no-media call that uses promises. (#1824)

> The API description guarantees that in the callback from createOffer, the (unmodified) offer will be useful: 

... by setLocalDescription, not signaling.

Also, does this mean setLocalDescription MUST NOT fail if the description is unmodified? As written, it seems to me it could still fail for other reasons.

In any case, I now better understand why older tests and examples didn't bother checking for setLocalDescription failing, [but we have stamped out this behavior](http://w3c.github.io/webrtc-pc/#examples-and-call-flows) because we agreed it's a bad template (as A. it precludes other failures, and B. if you start modifying the sdp for some reason then - oops! - you have no error checking).

I don't think official platform tests should be exempt from this best practice without good reason, as people copy JS more than they read specs.

> One of the ends of the connection will start firing candidates before the other is ready; the other one won't - one of the endpoints' first probe will be lost, and that is what we expect to happen. They will connect. That's why ICE is probed from both ends.

This sounds like a bug. No candidates should fail. Here's a [Firefox (specific) test](http://jsfiddle.net/aynr0k5q) that succeeds without any candidate failures.

About the timing issue, ICE gathering starts asynchronously inside setLocalDescription [here](http://w3c.github.io/webrtc-pc/#widl-RTCPeerConnection-setLocalDescription-Promise-void--RTCSessionDescription-description):
 > 5. If the local description was set, connection's ice gathering state is new, and the local description contains media, then set connection's ice gathering state to gathering.

JSEP effectively prohibits onicecandidate from being called prior to the setLocalDescription callback, because a [naive web application](http://w3c.github.io/webrtc-pc/#examples-and-call-flows) would otherwise send its candidates before it sends its offer, which [JSEP prohibits](https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-00#section-4.5).

Now, the test here is "cheating" by sending the offer before setLocalDescription, so it does not have this problem, whereas someone who would need to munge the SDP would not have this luxury. How relevant then is this test?

Imagine you need to munge the SDP, and move your gSecondConnection.setRemoteDescription() call to after setLocalDescription succeeds. Now put in a timing delay before right before it and watch what happens. You'll see candidates firing before the offer, and on gSecondConnection you'll see addIceCandidate happening before setRemoteDescription() which [should fail](https://code.google.com/p/webrtc/issues/detail?id=4409#c3).

View on GitHub: https://github.com/w3c/web-platform-tests/pull/1824#issuecomment-103554513

Received on Tuesday, 19 May 2015 15:33:15 UTC