Webrtc Call gets connected even if I'm not adding ice candidate in peer candidate

Question

const pc1 = new RTCPeerConnection(null);
const pc2 = new RTCPeerConnection(null);
async function call(){
    const offer = await pc1.createOffer();
    pc1.setLocalDescription(offer);
    pc2.setRemoteDescription(offer);
    const answer = await pc2.createAnswer();
    pc2.setLocalDescription(answer);
    pc1.setRemoteDescription(pc2.localDescription);
}
async function showVideo(){
    const config={audio:true,video:true};
    stream = await navigator.mediaDevices.getUserMedia(config);
    pc1.addStream(stream);
}

This is simplified version of my code.

Now in this code I'm not adding icecandidate to the peer neither listening to onicecandidate. But if I invoke call() twice my connection gets established.

I used event handler for iceconnectionstate change and found that when I invoke call for first time it iceconnection state is in checking condition and when I invoke it for second time it gets called and state became completed.

So I'm wondering how does even without adding icecandidate to another peer how checking gets initiated and gets connected for the second time?

Answer 1

Four reasons: A bug in your code, a behavior of Chrome, no firewall, and something about how trickle ICE works.

1) A bug in your code

First things first: The following sets pc1.setRemoteDescription(null):

pc2.setLocalDescription(answer);
pc1.setRemoteDescription(pc2.localDescription); // pc2.localDescription == null here

...because setLocalDescription is an asynchronous method that doesn't complete immediately.

Now pc2.localDescription does eventually get set, so the second time you invoke call() it's there, and negotiation works.

To fix this you must wait on the promise using await or then:

await pc2.setLocalDescription(answer);
pc1.setRemoteDescription(pc2.localDescription); // pc2.localDescription is set!

2) No ICE server needed if there's no NAT.

The browser can communicate with other machines on the same LAN, or itself, using "host" candidates (your machine's IP). No ICE servers needed to discover those.

3) Trickle ICE is an optimization.

The signaling (trickling) of individual ice candidates using onicecandidate, is an optimization meant to speed up negotiation. Once setLocalDescription succeeds, the browser's internal ICE Agent starts, inserting ICE candidates, as they're discovered, into the localDescription itself. Wait a few seconds to negotiate, and trickling isn't necessary at all: all ICE candidates will be in the offer and answer transmitted.

4) An interesting behavior in Chrome.

I suspect a race where the second time you invoke call() Chrome's ICE agent remembers the host candidates it has collected from last time, and inserts them into the offer and localDescription immediately, before setLocalDescription's success callback has run to completion. This might be a bug, or it may be how the spec says it should work. In any case, the behavior seems to differ depending on browser atm, so I wouldn't rely on it today.

Steps to Reproduce / Proof of ICE in SDP

1. Run this fiddle in Chrome and Firefox.
2. Click The Call! button once, then once more.
3. Observe Firefox: you'll see 0 candidates (output twice); both times; no connection.
4. Observe Chrome: it connects with 3 candidates the second time, with candidates.
5. Now uncomment the line // await wait(2000);
6. Both browsers now connect, with 4 or 8 candidates after 2 seconds.

The actual number of candidates may vary on your system, but the behavior shouldn't.

When I run this in Firefox, It doesn't connect either time, unless I modify it to wait or trickle candidates).

Browser update: Both browsers have bugs: Firefox is too restrictive and Chrome is too lenient in recovering from ICE failure.