I have a challenging issue I am working and its sure to scratch some heads.
iOS devices on T-Mobile cannot get connected to our hosted JVB using the example iOS app.
The following scenarios were tested:
||Wi-fi & Safari browser
||Wi-fi & example app
||T-Mobile & Safari browser
||T-Mobile & example app
||Others (AT&T, Verizon) & example app
Note: T-Mobile on Android works just fine
All of the above scenarios are using the exact same iOS device. The tests are conducted with the same meeting server. Most interesting is scenarios 3 and 4 - Using the same meeting safari works but the example app doesn’t.
Scenario #4 above is the obvious problem. When I say the scenario doesn’t work () I mean the user can join the meeting, see the thumbnails of others in the meeting and exchange chats. The xmpp session (TCP) is established and working. The issue is strictly related to the handshaking for audio/video media.
Diving into the details
On the client side
The example iOS app has no modification and I have tried multiple SDK versions (via PODs) including 5.0.1, 5.1.0, and 6.0.0.
Looking at the client and server logs together, I can tell the client is calling
sendIceCandidates with valid candidates.
The logs show that ice fails and then retries:
[modules/connectivity/IceFailedHandling.js] ICE failed, enableForcedReload: undefined, enableIceRestart: undefined, supports restart by terminate: true
On the server side
- I can see the video bridge receiving the sent candidates which includes the correct IP of the iOS device.
<candidate id='mxwjechjz5' foundation='4112442097' priority='2121801471' network='1' generation='0' ip='xxx.xxx.xxx.xxx' port='55202' type='host' protocol='udp' component='1'/>
- I can see the video bridge processing the pair(s)
Component.addUpdateRemoteCandidates#345: Update remote candidate for stream-72b4f85c.RTP: xxx.xxx.xxx.xxx:55202/udp
Component.updateRemoteCandidates#482: new Pair added: aaa.aaa.aaa.aaa:10000/udp/host -> xxx.xxx.xxx.xxx:55202/udp/host (stream-72b4f85c.RTP).
ConnectivityCheckClient.startCheckForPair#326: start check for aaa.aaa.aaa.aaa:10000/udp/host -> xxx.xxx.xxx.xxx:55202/udp/host (stream-72b4f85c.RTP)
StunClientTransaction.sendRequest: sending STUN tid 0xFCEAB0D68201C71E84056C94 from aaa.aaa.aaa.aaa:10000/udp to xxx.xxx.xxx.xxx:55202/udp
ConnectivityCheckClient.startCheckForPair#350: Could not start connectivity check: No socket found for aaa.aaa.aaa.aaa:10000/udp->xxx.xxx.xxx.xxx:55202/udp
Theories & Thoughts
I notice in the iOS app that its reporting it’s using
[JitsiMeetSDK] [modules/RTC/RTC.js] WebRTC application is running in plan-b mode
This is interesting to me and I thought this would cause a problem. However, I can conference on meet.jit.si with a mix of unified plan and plan-b participants
The fact that the same device on the same network can use Safari to connect to the same meeting leads me to believe there is a slight difference in the JitsiMeetSDK as it relates to handshaking.
So if you have read this far and understood the details above you understand the challenge we are facing.
I need the community’s help. I am looking for anything - - tips, places to look, things to try to help make progress. Steak dinner to the person that can help me get this working.
I haven’t read it in detail, but something I had experienced: I have seen T-mobile using ipv6 only connectivity which caused some problems. But I guess this is not the same … as you are seeing an IP address in bridge logs…
You have working turn server on that deployment, right?
No. We do not use STUN/TURN at all. For all intents and purposes, the clients are always on the same (private) LAN as the server. There always is an address pair that is directly reachable.
And yes, T-Mobile uses IPV6 on their mobile network. They have some translations happened for sure. But I can join using Safari - which proves that the communication is possible.
Maybe that’s why meet.jit.si is working for you … I would guess it maybe uses turn …
Yes. Thats my suspicion also.
Is there any problem in
P2P mode when both clients are “
T-Mobile & example app”
Good thought. I am not using any P2P because for security reasons, clients cannot “see” each other by design. All meetings utilize the JVB.
plan-b clients can communicate in
P2P mode (with audio/video) although their server doesn’t support it. You may try it temporary to clarify
Okay - I can confirm that
plan-b works in P2P mode between 2 iOS devices running the same example app. This eliminates
plan-b or a mix of that with unified plan. I used meet.jit.si for that test.
The only difference that I can think of is some shenanigans related to IPv6. That’s where a difference may lay. Safari may give you a NAT64 address and we might have botched the support for it. Working on meet.jit.si could be explained by the use of TURN.
In scenario 3 what type of IP do you see for that endpoint, from the prespective of other participants? (check in the GSM bars)
I have IPv6 completely disabled on this server (on the system and the various config settings). The JVB listens only on
10000 (as opposed to
I actually get both IPv6 and IPv6 addresses on all my devices (because its enabled on my router too). I see both (v4 and v6) sent to the server in
I suppose I could try to enable IPv6 on the server and see if that moves the needle.
@saghul Gets the steak dinner! His reply led me down the path of looking into IPv6 settings again.
After I fully enabled IPv6 on my server, everything magically started working perfectly in all configurations!
Thanks to all that replied!
Word on the street is that saghul is vegetarian, so I’ll relieve him of the guilt of the steak dinner. Thank you, very much!
This was a strange one. @damencho was also on the right track - Both he and @saghul got me focused in the right direction. Seems T-Mobile was taking IPv4 address (from ICE) and communicating it to the JVB using (translated) IPv6. Since the JVB was not listening on IPv6, those packets were being dropped.
netstat shows the T-Mobile user connected:
udp6 0 0 XXX.216.159.1:10000 :::* 37184/java
udp6 0 0 fe80::31da:3945:b:10000 :::* 37184/java <-- T-Mobile
Hum, that sounds like a bug though … Why ipv4 will be translated to ipv6 in the signalling…
T-Mobile is trying to run a full IPv6 only network on its mobile network. I think they have some IPv4 <–> IPv6 translations that happen automatically because the rest of the internet is not fully IPv6.
That’s NAT64 which Apple requires, that’s why we do it… But it’s a weird piece of code, I’d love to be able to drop it if we can.
Happy we found it @corby ! Now @Freddie amd I will fight over that steak