T-Mobile IPv6-only on Android with IPv4-only TURN servers

[Pete Doyle]

Hi All, 

I'm new to WebRTC and this list. Sorry if this has been asked before-- couldn't find anything exact by searching.

I just joined a team that has the following setup:

- All calls are bridged using Freeswitch acting as a TURN server (no STUN)

- We connect to TURN using static IPv4 addresses. There are no DNS names, nor is there any IPv6 connectivity on the TURN servers.

When using T-Mobile LTE, we're seeing a failure to find any suitable ICE candidates (terminology may be off slightly-- none of the ICE candidates pass the necessary connectivity checks). 

tl;dr of what I'm seeing:

1. T-Mobile is giving us an "IPv6 only" connection, with IPv4 connectivity through 464XLAT. The local IPv4 address is 192.0.0.4 (RFC 7335, not RFC1918).

2. The local IPv6 interfaces are discarded, with the following adb log from the Android SDK: "Server and local address families are not compatible"

3. The local IPv4 interface is discarded, with the following adb log from the Android SDK: "Binding socket to network address 192.0.0.4 failed; result: -3" (after following the code with a colleague, I think -3 means "not found in the list of interfaces Android reports as having internet connectivity").

#2 makes sense since we can't talk to IPv4 from an IPv6 interface.

#3 makes less sense. After digging, the Android OS (via the ConnectivityManager class) is not returning the 192.0.0.4 interface when the Android SDK asks for interfaces that have internet connectivity. The only interfaces returned are IPv6.

What's interesting is that-- even though Android is not reporting the IPv4 interface (via ConnectivityManager, at least), pinging remote IPv4 addresses from adb shell works fine-- there is a default route that routes 0.0.0.0/32 through rmnet_data0 (464XLAT out through the IPv6 interface).

So my questions:

- Has this been seen here before?

- Are there any workarounds short of adding IPv6 connectivity to our TURN servers? (this seems ideal, but may not be quick)

- Would it make sense to refactor the SDK to not use ConnectivityManager? (since there's IPv4 connectivity, but that interface doesn't get reported via ConnectivityManager so it looks like there isn't.)

Overall, would love advice on best practices as well as easy workarounds that can be applied temporarily.

Happy to provide any more info!

Thanks!

Pete

[Pete Doyle]

Filed a bug with more details:

https://bugs.chromium.org/p/webrtc/issues/detail?id=9925