1792370 - ICE timeout when obfuscate_host_addresses is true

Status: RESOLVED DUPLICATE of bug 1691189

(Core :: WebRTC, defect)

Description

[volker.mische]

Attachment: ice-timeout-obfuscated.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0

Steps to reproduce:

I tried to accept a remote WebRTC SDP answer with a delay.

Steps to reproduce: open the attached ice-timeout-obfuscated.html and look at the console output in the devtools. The connection cannot be established.

If you comment out line 96 (removing the delay), then it works as expected. Another workaround is to leave the delay in and set media.peerconnection.ice.obfuscate_host_addresses to false. Hence I suspect that this option somehow changes the timeout on how long is waited to get the ICE candidates.

I also tried it on Debian on Firefox 101.0.1 and nightly 107.0a1, both show the same behaviour.

Actual results:

The WebRTC connection cannot be established, there's an error message like this:

WebRTC: ICE failed, add a STUN server and see about:webrtc for more details

on the devtools console.

Expected results:

The WebRTC connection should be established.

Comment 1

[volker.mische]

Some more details. The problem is the timing between setting the answer on the locally and remote. It doesn't matter in which order alice.setRemoteDescription(answer) and bob.setLocalDescription(answer) are called. If there is no delay it works, if there's a 10s delay then it fails.

Comment 2

[volker.mische]

In regards to media.peerconnection.ice.obfuscate_host_addresses. When I look at the details on about:webrtc, I can see that when obfuscate_host_addresses is set to false, then the ICE State is succeeded as soon as the answer is set as local description. When it is set to true it's not the case.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Thanks for the bug report!
I managed to reproduce this issue using the STR and html file from the reporter on:

• Windows 11;
• macOS 12;
• Ubuntu 22;

Tested on:

• Firefox 106.0b9;
• Firefox 105.0;
• Nightly 107.0a1;

Setting this bug as NEW so that the developers can have a look at it.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mjf, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Michael Froman [:mjf]]

Byron, would have a minute to take a peek at this?

Comment 7

[Byron Campen [:bwc]]

That code is causing a 10 second wait between setting the answer on the answerer, and setting the answer on the offerer. That's already going to make it incredibly likely that ICE will fail. However, I think the main problem here is bug 1691189.

Comment 8

[volker.mische]

Isn't this rather a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1698141?

If I understand https://bugzilla.mozilla.org/show_bug.cgi?id=1691189 it's about Firefox not responding correctly/in time. This is not the case here. Firefox is doing the right thing, it just seems to give up earlier when media.peerconnection.ice.obfuscate_host_addresses is set.