Over the past few weeks, I’ve been using Nextcloud Talk quite a bit. While I’m very happy with it in general, I have actually found two scenarios in which the standard setup is not able to establish a connection between the two (or more) parties of a call: In roaming scenarios with my mobile network operator of choice and when I use Nextcloud Talk in the web browser on the PC at work behind the firewall. But there is a fix, at least for one of them.
So What’s the Issue?
In the default setup, Nextcloud talk uses the WebRTC framework to establish direct IP connectivity between all parties in a call. As most devices today are behind NATs or firewalls, this requires NAT pin-holing and other techniques to get those packets flowing directly. If this fails, Nextcloud Talk will fail as it doesn’t have a server in the middle by default that could terminate the media path of each side.
The Mobile Scenario That Doesn’t Work
While using Nextcloud Talk on a mobile device and via tethering on my notebook worked well at home, I could not establish a connection when I was recently roaming abroad for a few days. I was a bit puzzled at first but found the issue pretty quickly: While at home, my mobile device is configured for IPv4/v6 dual-stack connectivity. When roaming abroad, however, connectivity is by default limited to IPv4 only. In my home network scenario, Nextcloud Talk worked because it used IPv6 for a direct connection. When abroad, it tried to do the same with IPv4. Unfortunately, the IPv4 NAT of my mobile network operator seems to be unpredictable and thus the direct connection to the other end could not be established.
The Fix…
The only way to get around unpredictable NATs is to use a man-in-the-middle server somewhere on the Internet that terminates each call leg. This way, no NAT pin-holing is required, and each end sends and receives its IP media packets to/from the server with a public IP address. It’s not ideal but still secure as WebRTC does end-to-end encryption of the media stream. The standard way of doing this is using a TURN (Traversal Using Relays around NAT) server for this. Fortunately, there are open source implementations of the standard that can be installed and configured quite easily. By using the instructions I found here, I was able to get things up and running in less than 30 minutes! A quick call over tethering before and after setting up the TURN server confirmed that this was indeed the fix for my mobile scenario. When tracing connectivity it is interesting to observe how the local WebRTC client tries many different things to get a direct or indirect connection to the other end simultaneously and uses the first connection that actually works.
The Company Firewall Scenario
Unfortunately, the TURN server did not help to also get the call working from the PC at work behind the company firewall. I had high hopes and even used port 80 and 443 for the TURN server but no luck there. A bit of a shame as products such as Webex and others can handle this scenario as well.
But still, my most important connectivity scenarios are covered now!
To get around company firewalls you may need to use port 443 and TLS (i.e. turns is it called AFAIK). Then the firewalls should not be able to notice the traffic is different. Unless they “open” (i.e. break) TLS connections.
It seems WebRTC doesn’t do that because my TURN server was running on port 443 for just that reason.