Totally wrong IP addresses in the ICE candidates

[DevelopDaily]

We sit at a Starbucks (with WiFi) and use a Windows laptop to call an Android over a WebRTC website. The IceConnectionStateChange will report "failed". We use chrome://webrtc-internals to debug the connection and observe an ICE candidate that has an IP address with udp. But, the IP address does not exist on the machines!! We use the ipconfig and cannot find that address.

Is the problem related to the Chrome Browser or the STUN/TURN servers?

Thanks.

[Harald Alvestrand]

The normal case is that this is the address of the outside of the Starbucks NAT, learned by stun.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/d5e782e1-6ade-4249-9bb2-66d6c9542429%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[DevelopDaily]

That was definitely not the Starbucks' public IP. When that happened, we did google "check my ip". That told us the public IP. So, the ICE candidate contains an address that is not in the ipconfig and not the public address. It looks something like "10.0.3.247". 

The problem is so intriguing. Any comments are appreciated.

[Taylor Brandstetter]

Is it a "host" or "srflx" candidate? It's a private IP so I'd expect it to be "host".

If so: Did you use "ipconfig /all"? There's really no explanation other than it coming from GetAdapterAddresses.

Even if we were generating a bogus candidate, that shouldn't cause ICE to fail. I imagine the issue is just Starbuck's firewall, and you need a TLS connection to a TURN server or something.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/85fac6e2-5978-4d16-9f71-913087277142%40googlegroups.com.

[shakeeb nazmus]

>>The problem is so intriguing. Any comments are appreciated.

You can provide WebRTC log of caller and callee  for details analysis. Please verify that your STUN and TURN servers are working properly.   

[DevelopDaily]

Thanks, Taylor.

It is "host". Alas...I forgot to use /all when I ran ipconfig. I assume the "missing" IP would have been covered by /all if I had done so. 

I think I am able to explain the problem now. Our app does not have a TURN configured, thus is forced to use the udp/tcp candidates within the Starbucks network. Somehow, the Starbucks perhaps does not allow udp, tcp or both on some ports. Then, the ICE has no choice but to fail.

I tried the WebRTC demo and it worked well. I observed the two devices on the same coffee table using the same Starbucks WiFi were forced to use relay with a "peerreflexive" type!!

[Harald Alvestrand]

Many competent "guest" networks disallow traffic from guest to guest, so that they don't allow guests to attack each other. This may be what you are seeing.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/3f2b9618-c8ab-4688-a505-1c5a391505e8%40googlegroups.com.