Trickle ICE cannot work on chrome 77 under window 10

[deajosha]

When i upgraded chrome to 77.0.3865.90, pull newest code of webrtc/samples with gh-pages branches. when i run the Trickle ICE online demo, it occurs erorr:

The server stun:stun.l.google.com:19302 returned an error with code=701:
STUN host lookup received error.

if i use chrome version of 76, it works well. i don't konw what webrtc changes on newest chrome version of 77 ?

[abrel]

I have the same issue

[trappedion]

Same error happens with TURN servers.

[wyvern1019]

I have the same issue on android

[dcretin]

Same error with Chrome 78.0.3904.108

[DaGLiMiOuX]

Same error with Chrome 78.0.3904.108

With Chrome Canary Versión 81.0.3990.0 (Build oficial) canary (64 bits) it is still not working. I'm testing my own TURN server and Google's STUN server like this:

stun:stun.l.google.com:19302
turn:my_turn_domain_server.com:3478[username:password]

IceTransports all
ICE Candidate Pool 0


Time  | Component | Type  | Foundation | Protocol | Address             | Port  | Priority
0.011 |       rtp | host  | 1960016451 |      udp | <UUID>.local        | 56795 | 126|30|255
0.071 |       rtp | srflx | 842163049  |      udp | <LOCAL IP X.X.X.X>  | 20433 | 100|30|255
0.074 |       rtp | relay | 545643435  |      udp | <PUBLIC IP X.X.X.X> | 49887 |   2|30|255
0.084 |       rtp | srflx | 842163049  |      udp | <PUBLIC IP X.X.X.X> | 1850  | 100|30|255
0.111 |                                                                                 Done
0.113

Logs:
The server stun:stun.l.google.com:19302 returned an error with code=701:
STUN host lookup received error.
The server stun:my_turn_domain_server.com:3478 returned an error with code=701:
STUN host lookup received error.
The server turn:my_turn_domain_server.com:3478?transport=udp returned an error with code=701:
TURN host lookup received error.

This happens in both Google Chrome 78 and Canary 81. I already restarted browser configurations to default ones. Hope this helps a bit.

Best regards,
D.

[DaGLiMiOuX]

I can confirm that IN MY CASE this only happens with domain names in the example test. Probably there is something wrong in the JS for the test. Using IP address works perfectly after cleaning up all my browser configurations. I couldn't make it work with IP address before cleaning up. Maybe something got corrupted somewhere or there was a conflict with an addon, such AddBlocks or whatever I had installed.

In addition, I'm using my TURN server with domain name in url for ICE servers configurations in the JS of my project and is working perfectly.

Hope this helps.

Best regards,
D.

[visgotti]

happening on Version 79.0.3945.88 - is there a fix?

[sintanial]

Same problem...

[derwin12]

fyi.. Still working on my firefox in linux .

[cruizba]

I can confirm that IN MY CASE this only happens with domain names in the example test. Probably there is something wrong in the JS for the test. Using IP address works perfectly after cleaning up all my browser configurations. I couldn't make it work with IP address before cleaning up. Maybe something got corrupted somewhere or there was a conflict with an addon, such AddBlocks or whatever I had installed.

In addition, I'm using my TURN server with domain name in url for ICE servers configurations in the JS of my project and is working perfectly.

Hope this helps.

Best regards,
D.

I'm having the same problem with IP's in google chrome. It works on Firefox. Maybe @DaGLiMiOuX is right and the problem is related with JS or some extensions in Chrome. I'll try with a clean chrome and expose my results here.

Chrome 79.0.3945.117:

Mozilla Firefox 72.0.1:

[sad]

Is there any fix for this? Still happening for me on Chrome 80.0.3987.87. Working fine in Firefox.

[mrostamii]

Unfortunately, the same error with Chrome 80.0.3987.132 (Official Build) (64-bit) on Windows and Android.

[visgotti]

how has there been no official response to this yet... this seems pretty devastating..

[lgrahl]

Contact them on bugs.chromium.org and/or https://groups.google.com/forum/#!forum/discuss-webrtc

[rah-0]

Same problem here, using chrome Version 80.0.3987.149 (Official Build) (64-bit) with PION Turn server (https://github.com/pion/turn/tree/master/examples/turn-server/simple).

Same result, 701 error code on chrome but works on firefox.

[xkid1]

I have the same issue

[i2ezam]

Same problem

[jacklj]

Same on Chrome (version 81.0.4044.122, Official Build, 64-bit) on MacOS.

[JonathanNet]

Yeah I have the same problem with Chrome 83.0.4103.61 (Official Build) (64-bit), but not Firefox on Windows 10

[lcaresia]

some update ?

[aguang-xyz]

Any update? I have the same issue.

[rah-0]

I just gave up using this, every info I try to find on the matter is either outdated or not working. This API is garbage, worst I've ever seen.

[matextrem]

Any update on this ?

[visgotti]

It's hilarious every once in a while this shows up in my email and it's always someone asking if there's been any update on this.

it's even more hilarious there's no solution yet... i mean people are using webrtc in their applications still and all during this time.. I haven't worked on the part of my project that uses webrtc in months but I really assumed by the time I was going to rezoom there'd be more information about this fix. If the time comes i need to figure it out myself i promise i'll post it here.

but till then for real... ANYONE? ANYTHING? any volunteers to go post it on the google webrtc group? https://groups.google.com/g/discuss-webrtc?pli=1

[lgrahl]

Unfortunately, this samples project seems to be not well maintained and since I'm not a maintainer I can't lock or close the issue as invalid. The issues you're mentioning concern WebRTC but not the WebRTC examples, hence there is little to no reaction. What you should do is:

Contact them on bugs.chromium.org and/or https://groups.google.com/forum/#!forum/discuss-webrtc

[matextrem]

It's hilarious every once in a while this shows up in my email and it's always someone asking if there's been any update on this.

it's even more hilarious there's no solution yet... i mean people are using webrtc in their applications still and all during this time.. I haven't worked on the part of my project that uses webrtc in months but I really assumed by the time I was going to rezoom there'd be more information about this fix. If the time comes i need to figure it out myself i promise i'll post it here.

but till then for real... ANYONE? ANYTHING? any volunteers to go post it on the google webrtc group? https://groups.google.com/g/discuss-webrtc?pli=1

Maybe you wouldn't receive those messages if it was fixed once and for all 🤨

[wardhanster]

In my case, it appears that it is not working with twilio NAT services in "chrome"
it works on safari though

[wardhanster]

It seems like we need https in chrome for it to be fully functional.

[dils2k]

Does anyone know what's the problem? I am still getting this issue:

[Mindgamesnl]

Did anyone get a breaktrhough?

[dostiharise]

I have a very strange question to ask the people facing this issue.

"Do you by any chance have Docker installed on your machine?" 🙂

I was beating my head around this and shutting down Docker seemed to solve this issue, as the ICE Candidate gathering seems to be using Docker bridge IP address to evaluate connections.

This was adding a huge 30 sec delay to the connection.

Hope this helps.

One important question to ask is why it only effects Chrome and not Safari? 🤔

[tobias-tengler]

I was running into this today and figured out it was due to the domain of our TURN Server ending in local (turn.example.local).

Since these .local addresses are usually used by mDNS, Chrome tried to resolve them using mDNS and not our provisioned DNS Server. Other browsers resolved the Domain correctly using the DNS so we had this really weird issue, where the connection would work in any scenario, except when two Chrome browsers where attempting to call each other.
It also worked with Firefox <---> Chrome for example - I assume because Chrome used the candidate that was correctly resolved by Firefox.

Our fix was as simple as to change to a domain without .local at the end. Luckily we aren't in a heavily restricted environment! :)

We have a pretty specific use case so I doubt this will be the issue for most folks, but maybe it saves one person countless hours of debugging and monitoring network traffic!

[piranna]

Still happening in Chrome 88.0.4324.150 (Build oficial) (64 bits). Does has someone created an issue in Chrome bugtracker that I can follow? If not, I can create it myself.

[wardhanster]

In my case hosting it over a valid HTTPS enabled domain fixed the issue.

[juberti]

As noted in the latest version of the samples, DNS errors can be caused by a lookup on an interface that is not connected to the internet (e.g., the Docker bridge noted above), but these errors are not fatal.

The reason this started in Chrome 77 was that previously the onicecandidateerror event was not implemented.

[tejasvi]

https://groups.google.com/g/discuss-webrtc/c/kNKTllZcxOc/m/3ILy_Dt8CQAJ

M77 implements a callback for errors that occur while gathering. If you get a srflx candidate the server is up, in other cases the error helps figuring out what went wrong. Its probably still a bit overzealous and triggering the error callback for non-fatal errors such as dns resolution error.

[thusinh1969]

Firefox works for me, not Chrome :( ...

[regnaio]

Seeing the same issue on Chrome.. Works great in Firefox

[alvestrand]

Error code 701 is likely a network configuration error, and is unlikely to be a bug in the samples.
Please don't comment on closed bugs; open a new one if you think it's a bug in samples; otherwise, go to the browser's bug tracker.

[mghadam]

It works for me in Chrome when I check the " Acquire microphone/camera permissions" option and allow Trickle ICE to use Microphone/Camera. Without this option it returns 701 error.

[alvestrand]

@mghadam this is typical of errors where IP connectivity works but MDNS name resolution does not.
If you need to pursue this further, please open a new bug and describe your network setup.

[prakhar-shukla-in]

Turn needs realm for its authentication process.

I got the issue after fiddling with wireshark for a day.

For some reason firefox appends an empty realm if it can't find one but chrome and edge don't append any default realm. Since chrome and edge are not appending any realm your TURN server will not be able to authenticate. If you capture packets using wireshark you'll see that its flooded with "Authentication failed" for stun protocol.

The fix is to provide a realm in your TURN server configuration. Otherwise you'll see no relay candidates in chrome and edge as they failed to authenticate the TURN server as their is no realm to generate the nonce for authentication process.

If you are using coturn or any other TURN server then open its config and add a realm

realm = <any-string>