HowTo: Setup Nextcloud Talk with TURN server

You are awesome. Would you be open to turning this into a Markdown file and submit it as PR to the Talk Android repo?

2 Likes

Jep, I can do that. Just checked, where exactly to send PR to, just a raw TURN.md/COTURN.md file in root or as wiki page (somehow when I try to open the wiki, I get redirected to main page again)?

Create a folder “docs” in root and put a raw TURN.md there? :slight_smile:

Thanks to great guides here or the references made to them I’ve got TALK working with TLS and Nextcloud and TURN server behind the same NAT. Using default Nextcloud STUN server for now. Android Talk to Android Talk and Android Talk to browser and back goes fine. However it refuses to work for browser to browser communications when both PCs are behind different NATs. Unlikely DPI is blocking things as both testing instances are beyond common Western ISPs, and no symmetric firewalls or so.

Have ploughed through the logs but it is a lot to take on and I couldn’t do much else than a lot of trial and error of random things, but still unsuccessful. I noticed that you advise UDP and TCP to use with TURN server config in Nextcloud where others say it should be UDP only. Any comment on that? Will try anyway.

Anyone came across this use case and like to share how they managed to solve it?
E.g. does the TURN server need to be on public internet for this use case? It is just for testing with <10 users.

Bump

Anyone thoughts on UDP only vs TCP and UDP use?
With a working TALK, TURN and STUN server still wondering why I can’t get 2 different WebRTC PCs behind a different NAT via the open network to work. Hoping for any tips, consideration in this context. Thanks.

Ah yeah indeed there is still a gap with this protocol topic:

  • I remember Spreed.ME with spreed-webrtc-server used just UDP by default as protocol. Otherwise some guides around here suggested to add (UDP + TCP) as well.
  • Generally as far as I know (superficially) UDP has some performance benefits where TCP is better for stability. I remember back in that time, that just using TCP was a solution attempt for unstable connections: [Spreed.ME] Unreliable long distance connection buildup via TURN server
  • I am not sure, if both are given, how Talk decides which protocol to use, but yeah in case just try, if UDP or TCP only makes some difference for you.

Generally in my cases all kind of connections I can try here (also laptop -> laptop over www) work fine now, but as you can see I also had issues with Spreed.ME as well as spreed video calls later, which I was not able to solve :slightly_frowning_face:.

Now that I read this, I see that I forgot to add the hint, that of course the chosen TURN port needs to be forwarded from the router in case :wink:.

1 Like

Thanks for your reply. The turn server has been forwarded on the router, figured that one early on.
And after that about a week ago I read every post vaguely related to this topic including yours. It is good to hear that you can confirm getting it to work in general, so it should be able to work at least. Will keep on testing.

Just letting you all know, that adding UDP and TCP fixed the issue with the PC ot PC connections as reported above. Next mission is to get it to work behind corporate firewalls. Will report if nay success, not expecting for a while though.

@MichaIng Hey, can I do anything to help you with creating a PR? :slight_smile:

@mario
Sorry for it taking a while. Was too busy the last week :slightly_smiling_face:. PR is up: https://github.com/nextcloud/talk-android/pull/169

Thanks for this howto. After opening port 3479 it works for me.

2 Likes

Jep, I made it clearer in step 6 that you need to open the chosen port to the web, which means forwarding it, if the server is behind a NAT.

1 Like

Is it possible to add an notification when anyone join an public chat and the Android App is in the Background?

But why in the Talk App for Android repo instead of the Nextcloud Talk (still called “spreed”) repo? I think this belongs to the server app and not the client app where it is a bit confusing/difficult to find actually.

Jep indeed, this should be (as well) added to the server app repo.

I will add a PR to put this guide into their GitHub wiki and/or a related hint to the README.md.

On the other hand I am just thinking that, if the full text is added to forum, Android app and server app repo, perhaps docs.nextcloud.com any time later, it is a mess to keep it up-to-date. Better have it in one place, where all suggestions/corrections/updates are added and then just link to it?
@mario what you think?

Docs are the best place to have it.

I think it should stay with the repo of the Nextcloud app. Almost any other app has its further configuration information in its repository and referenced/included into the Readme. The information is pretty pointless in the Android app repo because it is required for the server part, not the client apps.

1 Like

Just a simple question, and do not take this as negative, I adore NextCloud and use it with pleasure on a hosted VM, works very well, also with my Windows clients
Now that I tried Talk to get privacy as opposed to Skype & Co I am wondering why the setup for out of local LAN comms is so difficult. I get it that a STUN server is needed for NAT situations (which at least in simple forms are basically everywhere).
Just if I compare the solutions I fail to understand why e.g. Skype can easily do things which Talk cannot. Both seem to establish a P2P connection as the first choice. In my scenario with a MAC at my son’s place in Germany and my Windows PC in France (both behind simple NAT boxes) I would assume that making Talk work should only be a matter of allowing the relevant processes access through the client based firewall and maybe forwarding some ports by the boxes. Could someone possibly shed light on this, or explain why Talk would definitively need a TURN server to work under my scenario.

Thanks in advance, looking forward to any helpful info…

I’ll let others respond, but Skype has two modes of operations, none of which is REALLY peer-to-peer.

In first mode of operation (more common in the earlier days) they used computers of other users (and their supernodes) in order to route your calls so they could evade NAT, Firewalls, and others.

In recent days, those “supernodes” are more often used compared to every other connection options available to them.

So to summarize - while TURN is quite easy to setup, Nextcloud Talk is a self-hosted solution so it’ll always be a bit harder to setup than other solutions. That however applies only to the admin - for me as a user, even now in its beginnings, Nextcloud Talk works better than say Skype.

1 Like

Thanks for your remarks, very informative. As said, I have a hosted NextCloud, so all calls between users are external to the NextCloud’s local network (at my provider). All my clients used so far are Win10. I have now my own TURN server (set up by my provider), which is in a different local network than my NextCloud.

I could meanwhile establish communication with video and sound using Opera, however I had to manully enable the "Use any suitable network interface " option in “Privacy/Security / WebRTC”, which was for some reason (I have no recollection of having changed it) set to “Disable Non-proxied UDP”. With Firefox still no luck, although WebRTC is enabled (I checked in about:config) and the H.264 add-on present and enabled.

Someone any hints for Firefox and other browsers, also Safari on the Mac?