[webrtc-pc] Allow addIceCandidate(null) for backwards compatibility w/adapter (#2039)

jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== Allow addIceCandidate(null) for backwards compatibility w/adapter ==
This is instead of reopening https://github.com/w3c/webrtc-pc/issues/1773, because while no browser ever allowed `addIceCandidate(null)`, [adapter.js](https://github.com/webrtcHacks/adapter) did, and still does, causing some confusion among users. To reproduce:
 1. Open [this fiddle](https://jsfiddle.net/jib1/81o5sa2n/) and allow camera -> success.
 2. Remove `adapter-latest.js` under *Resources* on the left, and re-run it, and you get errors:

```
(index):51 Uncaught (in promise) TypeError: Failed to execute 'addIceCandidate' on 'RTCPeerConnection': Candidate missing values for both sdpMid and sdpMLineIndex
    at RTCPeerConnection.pc2.onicecandidate.e ((index):51)
(index):50 Uncaught (in promise) TypeError: Failed to execute 'addIceCandidate' on 'RTCPeerConnection': Candidate missing values for both sdpMid and sdpMLineIndex
    at RTCPeerConnection.pc1.onicecandidate.e ((index):50)
```
They come from the benign-looking:
```js
pc1.onicecandidate = e => pc2.addIceCandidate(e.candidate);
pc2.onicecandidate = e => pc1.addIceCandidate(e.candidate);
```

Without restating https://github.com/w3c/webrtc-pc/issues/1773, while redundant, it seems benign to support this for legacy reasons. [JSEP](https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-4.1.17) even supports it: *"In the case of an end-of-candidates indication, the absence of both the m= section index and MID fields is interpreted to mean that the indication applies to all m= sections in the specified ICE candidate generation"*. It also appears idempotent.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2039 using your GitHub account

Received on Monday, 10 December 2018 22:42:46 UTC