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

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?

edited Nov 21 '18 at 11:08

asked Nov 21 '18 at 10:39

ChandraKumar

2917

This title will probably not catch the attention of those who can help you.

– Dirk Horsten
Nov 21 '18 at 10:59

Thanks, I'm new here. Can you help me out figuring out a catch title?

– ChandraKumar
Nov 21 '18 at 11:04

add a comment |

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.

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

edited Nov 21 '18 at 11:08

asked Nov 21 '18 at 10:39

ChandraKumar

2917

This title will probably not catch the attention of those who can help you.

– Dirk Horsten
Nov 21 '18 at 10:59

Thanks, I'm new here. Can you help me out figuring out a catch title?

– ChandraKumar
Nov 21 '18 at 11:04

add a comment |

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.

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

edited Nov 21 '18 at 11:08

asked Nov 21 '18 at 10:39

ChandraKumar

2917

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.

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

javascript webrtc

edited Nov 21 '18 at 11:08

asked Nov 21 '18 at 10:39

ChandraKumar

2917

edited Nov 21 '18 at 11:08

asked Nov 21 '18 at 10:39

ChandraKumar

2917

edited Nov 21 '18 at 11:08

asked Nov 21 '18 at 10:39

ChandraKumar

2917

asked Nov 21 '18 at 10:39

ChandraKumar

2917

asked Nov 21 '18 at 10:39

ChandraKumar

2917

This title will probably not catch the attention of those who can help you.

– Dirk Horsten
Nov 21 '18 at 10:59

Thanks, I'm new here. Can you help me out figuring out a catch title?

– ChandraKumar
Nov 21 '18 at 11:04

add a comment |

This title will probably not catch the attention of those who can help you.

– Dirk Horsten
Nov 21 '18 at 10:59

Thanks, I'm new here. Can you help me out figuring out a catch title?

– ChandraKumar
Nov 21 '18 at 11:04

This title will probably not catch the attention of those who can help you.

– Dirk Horsten
Nov 21 '18 at 10:59

Thanks, I'm new here. Can you help me out figuring out a catch title?

– ChandraKumar
Nov 21 '18 at 11:04

add a comment |

1 Answer
1

active

oldest

votes

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

Run this fiddle in Chrome and Firefox.

Click The Call! button once, then once more.

Observe Firefox: you'll see 0 candidates (output twice); both times; no connection.

Observe Chrome: it connects with 3 candidates the second time, with candidates.

Now uncomment the line // await wait(2000);

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.

edited Nov 26 '18 at 22:24

answered Nov 22 '18 at 2:01

jib

20.9k64490

1

I've a doubt with your 3rd point. "Agent starts, inserting ICE candidates, as they're discovered, into the localDescription itself." Digging deeper into the RTCPeerConnectionIceEvent object contains sdp information; but the SDP doesn't not contains icecandidate. But you are telling that sdp contains information about ice-candidate. So can you share any resources where it was mentioned or any ways to check it locally?

– ChandraKumar
Nov 22 '18 at 9:31

1

I've added a fiddle that should show it above. You can also check out an older answer of mine.

– jib
Nov 22 '18 at 14:00

1

There's some question of which browser is correct. I'll come back and update once that's resolved! In any case, I hope the information is helpful.

– jib
Nov 22 '18 at 14:20

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53410263%2fwebrtc-call-gets-connected-even-if-im-not-adding-ice-candidate-in-peer-candidat%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

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.

4) An interesting behavior in Chrome.

Steps to Reproduce / Proof of ICE in SDP

Run this fiddle in Chrome and Firefox.

Click The Call! button once, then once more.

Observe Firefox: you'll see 0 candidates (output twice); both times; no connection.

Observe Chrome: it connects with 3 candidates the second time, with candidates.

Now uncomment the line // await wait(2000);

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.

edited Nov 26 '18 at 22:24

answered Nov 22 '18 at 2:01

jib

20.9k64490

1

I've a doubt with your 3rd point. "Agent starts, inserting ICE candidates, as they're discovered, into the localDescription itself." Digging deeper into the RTCPeerConnectionIceEvent object contains sdp information; but the SDP doesn't not contains icecandidate. But you are telling that sdp contains information about ice-candidate. So can you share any resources where it was mentioned or any ways to check it locally?

– ChandraKumar
Nov 22 '18 at 9:31

1

I've added a fiddle that should show it above. You can also check out an older answer of mine.

– jib
Nov 22 '18 at 14:00

1

There's some question of which browser is correct. I'll come back and update once that's resolved! In any case, I hope the information is helpful.

– jib
Nov 22 '18 at 14:20

add a comment |

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.

4) An interesting behavior in Chrome.

Steps to Reproduce / Proof of ICE in SDP

Run this fiddle in Chrome and Firefox.

Click The Call! button once, then once more.

Observe Firefox: you'll see 0 candidates (output twice); both times; no connection.

Observe Chrome: it connects with 3 candidates the second time, with candidates.

Now uncomment the line // await wait(2000);

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.

edited Nov 26 '18 at 22:24

answered Nov 22 '18 at 2:01

jib

20.9k64490

1

I've a doubt with your 3rd point. "Agent starts, inserting ICE candidates, as they're discovered, into the localDescription itself." Digging deeper into the RTCPeerConnectionIceEvent object contains sdp information; but the SDP doesn't not contains icecandidate. But you are telling that sdp contains information about ice-candidate. So can you share any resources where it was mentioned or any ways to check it locally?

– ChandraKumar
Nov 22 '18 at 9:31

1

I've added a fiddle that should show it above. You can also check out an older answer of mine.

– jib
Nov 22 '18 at 14:00

1

There's some question of which browser is correct. I'll come back and update once that's resolved! In any case, I hope the information is helpful.

– jib
Nov 22 '18 at 14:20

add a comment |

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.

4) An interesting behavior in Chrome.

Steps to Reproduce / Proof of ICE in SDP

Run this fiddle in Chrome and Firefox.

Click The Call! button once, then once more.

Observe Firefox: you'll see 0 candidates (output twice); both times; no connection.

Observe Chrome: it connects with 3 candidates the second time, with candidates.

Now uncomment the line // await wait(2000);

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.

edited Nov 26 '18 at 22:24

answered Nov 22 '18 at 2:01

jib

20.9k64490

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.

4) An interesting behavior in Chrome.

Steps to Reproduce / Proof of ICE in SDP

Run this fiddle in Chrome and Firefox.

Click The Call! button once, then once more.

Observe Firefox: you'll see 0 candidates (output twice); both times; no connection.

Observe Chrome: it connects with 3 candidates the second time, with candidates.

Now uncomment the line // await wait(2000);

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.

edited Nov 26 '18 at 22:24

answered Nov 22 '18 at 2:01

jib

20.9k64490

edited Nov 26 '18 at 22:24

answered Nov 22 '18 at 2:01

jib

20.9k64490

answered Nov 22 '18 at 2:01

jib

20.9k64490

answered Nov 22 '18 at 2:01

jib

20.9k64490

1

I've a doubt with your 3rd point. "Agent starts, inserting ICE candidates, as they're discovered, into the localDescription itself." Digging deeper into the RTCPeerConnectionIceEvent object contains sdp information; but the SDP doesn't not contains icecandidate. But you are telling that sdp contains information about ice-candidate. So can you share any resources where it was mentioned or any ways to check it locally?

– ChandraKumar
Nov 22 '18 at 9:31

1

I've added a fiddle that should show it above. You can also check out an older answer of mine.

– jib
Nov 22 '18 at 14:00

1

There's some question of which browser is correct. I'll come back and update once that's resolved! In any case, I hope the information is helpful.

– jib
Nov 22 '18 at 14:20

add a comment |

1

I've a doubt with your 3rd point. "Agent starts, inserting ICE candidates, as they're discovered, into the localDescription itself." Digging deeper into the RTCPeerConnectionIceEvent object contains sdp information; but the SDP doesn't not contains icecandidate. But you are telling that sdp contains information about ice-candidate. So can you share any resources where it was mentioned or any ways to check it locally?

– ChandraKumar
Nov 22 '18 at 9:31

1

I've added a fiddle that should show it above. You can also check out an older answer of mine.

– jib
Nov 22 '18 at 14:00

1

There's some question of which browser is correct. I'll come back and update once that's resolved! In any case, I hope the information is helpful.

– jib
Nov 22 '18 at 14:20

I've a doubt with your 3rd point. "Agent starts, inserting ICE candidates, as they're discovered, into the localDescription itself." Digging deeper into the RTCPeerConnectionIceEvent object contains sdp information; but the SDP doesn't not contains icecandidate. But you are telling that sdp contains information about ice-candidate. So can you share any resources where it was mentioned or any ways to check it locally?

– ChandraKumar
Nov 22 '18 at 9:31

I've added a fiddle that should show it above. You can also check out an older answer of mine.

– jib
Nov 22 '18 at 14:00

There's some question of which browser is correct. I'll come back and update once that's resolved! In any case, I hope the information is helpful.

– jib
Nov 22 '18 at 14:20

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu