TURNS support for Native App

[ezraimanuel]

Hello,

Multiple browser based conference works and all traffic directed to TURN server that runs on TCP port 443 (thanks to turn_credentials). This is awesome. especially on environment behind firewall. (tested with multiple browser, multiple internet connections, and even Android Chrome, all video traffic are using TCP port 443)

But this can’t work with native Jitsi Meet app, it still needs to connect to UDP port 10000, which is the default. can you update the app to be able to use the TURN server like the browser?

thanks!

[Commifreak]

Cant confirm that. I blocked 10000/UDP for all devices - The native app works just fine!

[Echolon]

@ezraimanuel may you provide more detailed information?

[ezraimanuel]

Hello,

my apologies for late reply, many things going on lately.

Yes about this issue, I'll try to explain the situation:

Our environment:

1. Jitsi server is behind NAT and we have only 2 public IPs (1 already used for other services, and the other 1 for external STUN/TURN server)
2. There's a firewall blocking other ports except 80 and 443 so there is no way to connect to Videobridge directly.

Our implementation:

1. We setup external STUN/TURN server listening on TCP port 443 on 1 public IP, and it's working fine, we use this STUN/TURN server for other applications as well.
2. At his point, we rely heavily on turn_credentials module which expected to point clients to connect to said STUN/TURN server.

Implementation works fine. we tested using 3 different browsers (Chrome/Mozilla/Opera) on 2 laptops and 1 phone connecting to the conference. I see when they cannot connect to the Videobridge port, all clients are redirected to the external STUN/TURN server, I thinks this is how turn_credentials module expected to work. So no issue here.

The problem is, when the same phone using native app from Google Play, it won't connect to the TURN/STUN server (from traffic monitor the phone still trying to connect to Videobridge port), as if it's the turn_credentials doesn't work on it. if the phone using mobile browser it works just fine.

=== another issue
On this WFH situation people rely on video conferences, people at my office tried many video conference solutions out there, and with native client installed there's a peak of 30 users in the same room with no lags or high resource usage. We always encourage our guys to use Jitsi as primary since it's self-hosted in our environment, but users complained mostly about "high resource usage" on their devices, even laptops and PCs. Is there any solution for this matter? perhaps quality detection/bitrate auto reduce or any other maybe?

thank you, and i'm sorry my explanation is not clear enough.

[plokta]

Seems like the Android app uses a builtin list of root CAs for turns:// instead of using the system CAs. The list of used CAs seems to be hardcoded in the file sslroots.h (see jitsi mirror of the webrtc implementation).

The issue has been discussed over at the webRTC google group and @saghul has apparently been informed (?): https://groups.google.com/forum/#!topic/discuss-webrtc/4MmARU0XYqc

A possible solution could be to include Mozilla's list of trusted root CAs instead of using Google list, which for some reason does not include the DST X3 CA needed to verify LetsEncrypt certificates. Links to the Mozilla CA list can be found at https://wiki.mozilla.org/CA/Included_Certificates

As the WebRTC lib includes a script to build the sslroots.h file automatically, I'd recommend to automate this to renew the included certs at buildtime, if possible.

---

Issues with turns:// on Android have been frequently discussed in the jitsi community, e.g.,

• https://community.jitsi.org/t/turn-server-does-not-work-on-mobile-app/58789
• https://community.jitsi.org/t/android-app-rejecting-lets-encrypt-certificates-for-turns/29468
• https://community.jitsi.org/t/prosody-certificate-and-android-app-issues/28256/24

[faenil]

Hi there,

I revived the thread on the WebRTC Google Group as I thought it would be better than starting (yet) another one.
I was then waiting for @saghul 's reply before posting updates too, but thanks for taking the lead :)

I spent a few evenings investigating WebRTC's implementation and handling of TLS certificates verification, and my fear is that it might be too long before Jitsi gets to implement a similar system, given the limited resources of OSS.

As mentioned in the thread above, I am happy to contribute a patch to WebRTC to add DST X3 and any other needed root CAs to ssl_roots.h.

It'd be ideal if Jitsi could rely on the underlying OS' trust store or Mozilla NSS'.

However, if that change is (understandably, for one reason or another) going to take months/years, maybe it's better to add the CAs to ssl_roots.h and update its content every so often?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[faenil]

Ouch, we were late :)

[faenil]

For people ending up on this thread, this issue now also has a bug thread on Chromium bug-tracker, as that is where the source of the problem is (that is, if we don't change Jitsi Meet's dependencies):
when that is fixed, projects such as Jitsi Meet will only have to update their dependencies

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

[ahabiba]

Any luck with this issue?

[resoli]

I'm also affected. No LE certificates here, but a wildcard OV + chain from Actalis (italian CA). I checked inside the version of ssl_roots.h in webrtc v.94.0.0 and it seems very restrictive:

 Comodo_AAA_Services_root_certificate,
 GlobalSign_Root_CA___R6_certificate,
 DigiCert_Global_Root_CA_certificate,
 USERTrust_RSA_Certification_Authority_certificate,
 GlobalSign_Root_CA___R3_certificate,
 GlobalSign_Root_CA___R2_certificate,
 AffirmTrust_Premium_certificate,
 GTS_Root_R4_certificate,
 Baltimore_CyberTrust_Root_certificate,
 DigiCert_Assured_ID_Root_CA_certificate,
 Starfield_Root_Certificate_Authority___G2_certificate,
 AffirmTrust_Networking_certificate,
 GlobalSign_Root_CA_certificate,
 GTS_Root_R3_certificate,
 COMODO_RSA_Certification_Authority_certificate,
 GTS_Root_R2_certificate,
 Cybertrust_Global_Root_certificate,
 GTS_Root_R1_certificate,
 DigiCert_Global_Root_G3_certificate,
 DigiCert_Global_Root_G2_certificate,
 Starfield_Class_2_CA_certificate,
 COMODO_Certification_Authority_certificate,
 GlobalSign_ECC_Root_CA___R4_certificate,
 GlobalSign_ECC_Root_CA___R5_certificate,
 USERTrust_ECC_Certification_Authority_certificate,
 Entrust_net_Premium_2048_Secure_Server_CA_certificate,
 AffirmTrust_Premium_ECC_certificate,
 DigiCert_High_Assurance_EV_Root_CA_certificate,
 Entrust_Root_Certification_Authority___G2_certificate,
 Go_Daddy_Class_2_CA_certificate,
 AffirmTrust_Commercial_certificate,
 Entrust_Root_Certification_Authority_certificate,
 DigiCert_Assured_ID_Root_G2_certificate,
 DigiCert_Trusted_Root_G4_certificate,
 COMODO_ECC_Certification_Authority_certificate,
 Entrust_Root_Certification_Authority___EC1_certificate,
 GeoTrust_Global_CA_certificate,
 DigiCert_Assured_ID_Root_G3_certificate,
 Go_Daddy_Root_Certificate_Authority___G2_certificate,

[saghul]

Can you check 98? I thought they had fixed this.

[resoli]

v98.0.0 tarball (and zip) contains a Readme file only.

[saghul]

https://github.com/jitsi/webrtc/blob/M98/rtc_base/ssl_roots.h Looks like it got modified on 2020 so no dice. I'd say we take Mozilla's CA store and covert it to that format.

[resoli]

Yes, I guess it is the only viable option given the state of webrtc issue 11710.

[saghul]

I'll try to ge it done for the 98 release.

[saghul]

Update: I swapped the default ssl_roots.h in our M98 build with one generated from the Mozilla CA bundle: https://github.com/jitsi/webrtc/blob/a16f3fc17e43e4d32743da5a0f21517d8ff696ab/rtc_base/ssl_roots.h

I'm upstreaming the change in this CL: https://webrtc-review.googlesource.com/c/src/+/253220

[gpahlevanzadeh]

For supporting from out of your network set listening_ip=0.0.0.0 and external_ip=YOUR_PUBLIC‌_IP in /etc/turnserver.conf

[saghul]

Ugh I forgot to close this one :-) We now bundle the Mozilla CA root so TURNS works out of the box.