VoIP: relay candidates still don't show up from the mobile side

karolyi commented 3 years ago

Describe the bug Copying this over from https://github.com/vector-im/element-android/issues/2818#issuecomment-787783062 So with 1.1.0 out, according to my tests it still doesn't support TURN servers and WebRTC relay candidates.

I could only make calls with using STUN servers and UDP hole punching when behind NAT or firewalled IPv6 connections: tracked calls from mobile to browser and vice versa with about:webrtc in Firefox/Librewolf, no relay offers from the mobile side, while I had them on the browser side.

Is this intentional?

To Reproduce Steps to reproduce the behavior: Just start a voice call on mobile and see what candidates show up in WebRTC from the mobile client.

Expected behavior With a TURN server correctly set up with credentials (that works in element-web), relay candidates should show up from the mobile client as well.

Smartphone (please complete the following information):

Device: ASUS ZenFone 6, my brother's Poco F2, and another acquaintance's phone of which brand I don't know.
OS: Android 11, but IOS devices seem to have the same issue according to my tests.

Additional context

I have 1.1.0 from F-Droid, my brother has the same from the play store.
Homeserver: ksol.io

I use my own coturn server on FreeBSD in a separate jail, that has some issues unfortunately due to it not properly supporting it and/or being buggy, which I plan to fix by contributing to its codebase when I'll have the time for it. That said, as mentioned before, relayed calls with coturn work between two browsers (without a STUN server, and setting the two browsers to use use relay-only candidates). I would expect the same from the mobile clients.

Natureshadow commented 3 years ago

I can reproduce this – Element Android reproducibly cannot make calls behind NAT, if STUN is not explicitly added to turn_servers on the homeserver.

Ezwen commented 3 years ago

I can reproduce this – Element Android reproducibly cannot make calls behind NAT, if STUN is not explicitly added to turn_servers on the homeserver.

How can STUN be added to turn_servers? And is there a way to make sure that coturn does have STUN working correctly?

EDIT: I managed to get STUN working with coturn. I managed to have two element-android client connect through VOIP, but only if both phones are connected to WiFi. If at least one phone is on cellular internet access, then it does not work.

Natureshadow commented 2 years ago

Any idea when we will get TURN support on Android?

jpVm5jYYRE1VIKL commented 2 years ago

Look like android version turn implementation broken. On properly configured turn server in moment of issue android spam with :

Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 001000000000000016: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 001000000000000014: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 001000000000000040: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 001000000000000032: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 001000000000000023: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 001000000000000035: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 001000000000000022: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 001000000000000043: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 000000000000000021: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 000000000000000018: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 000000000000000030: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 001000000000000042: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 001000000000000034: realm <> user <>: incoming packet message processed, error 401: Unauthorized
Jul 09 18:22:59 stun turnserver[5192]: 1221: : session 001000000000000041: realm <> user <>: incoming packet message processed, error 401: Unauthorized

Look like android version ignore /_matrix/client/r0/voip/turnServer contens ie fait to read / ignore turn_shared_secret

jensbjorgensen commented 8 months ago

Not sure if this is related, but I had an issue with webrtc in android chrome browser where the browser would not negotiate a relay endoint if the TURN server supplied an empty realm attribute. It would silently discard/ignore the relay when this happened. All that's required is to set a non-empty realm to fix this for me. Again not sure if this applies here but maybe it would help.

element-hq / element-android

VoIP: relay candidates still don't show up from the mobile side #2939