An even easier approach is to run the script from the Nextcloud VM.
- Open port 5349 (or whichever you want)
- wget the RAW script and run it.
An even easier approach is to run the script from the Nextcloud VM.
IF you run the Nextcloud VM !
Otherwise it might partly work on other Debian-based distros/systems, but leaves the config left with some wrong estimated variables => coturn settings, based on environment expectations, SSL via LetsEncrypt and others.
Can the TURN server be on the same server as Nextcloud itself? If so, I imagine we cannot refer to the TURN server by the IP address (within Nextcloud configs) as 127.0.0.1.
Both can be on the same machine, but within Nextcloud settings, you still need to set the public/external IP. This is used by the end user WebRTC clients (browser, Android app), not by Nextcloud.
What if we installed our Nextcloud from a snap? That would introduce some complications, I think, to get coturn working on the same server as the snap. I made a post asking deeper questions about this here.
Your efforts on this matter are greatly appreciated! I just wanted to react to one of your quotes here as I think things have shifted in favor of your idea of bundling TURN together with TALK (and STUN).
Recently I have discovered and deployed Yunohost (self hosting solution which lets you install apps - such as NextCloud - in a GUI with the simple click of a button), and have installed NextCloud on it. Both Yunohost and Nextcloud share the mission of making self hosting (a cloud) accessible/maintainable for many many more people. The choice of only using GUIs and making installing apps easy by just clicking an install button are two ways in which this mission is accomplished.
Videocall use cases and low level of technical expertise
I am a user of NextCloud who - probably like most other users - has not deployed it for use by a huge company, but just for home use and perhaps a smaller company. In these use cases it does not make any sense to only use the TALK videocalls within the local network. As most homes or smaller companies just have a kitchen/meeting room and don’t need video calls inside the same building. Where NextCloud talk becomes interesting, is when videocalls work with people outside of the local network. Since I suspect that this is the goal of most people who install TALK on NextCloud, it is very inconvenient that they then land into having to do all kinds of expert level terminal work and understanding. Especially when these users are more and more almost non-experts being able to host themselves through the great efforts of projects like NextCloud and Yunohost.
Developer and user effort and losing (potential) users
In connection to the above, I would like to comment on what you said about a bundling solution: “On the other hand this means always additional effort for maintaining the fork or bundle (depending on how far the integration should go)”. I am not a developer - more of a designer/creative researcher - so I don’t know exactly how much time it would take a developer in this case. However, I do know that if these one or a few developers do not take a few hours to do this, then all thousand or more non-expert users have to spend an almost similar amount of time each reading up on the issues and instructions and installing; probably resulting in a much larger cumulative cost in time, a possible source of irritation and in many cases just a switch back to Skype or another platform than NextCloud (for example Google Drive/Talk). That would be ashame of such a good project such as NextCloud and TALK.
An ideal solution
I would really wish that the installation of TALK in NextCloud would enable videocalls outside the local network by default, and that there would be no - or only little GUI - configuration required.
(By the way, in the installation process then it would be helpful to also give instructions about port forwarding for both TCP and UDP, I ran into trouble only having TCP in place first)
How to get there
My question to you (and perhaps others on the forum) is if the above wish could be accomplished and how? (And if it is far too difficult, how could creating an easily configurable TURN server be made available for Yunohost for example?)
Thanks again for you efforts already! I look forward to your answer(s). From a designer and less-expert user perspective I might be helpful in fleshing out a solution.
Other potentially helpful sources
P.s. Some other interesting links about TURN in this context and could perhaps be used for working toward a GUI solution:
As long as the server is on Ubuntu 18.04 the scripts from the VM should work. All it does is checking open ports, installs the needed packages and then adds the needed configuration.
Give it a try. If it doesn’t work, please let me know.
Jep reasonable thoughts.
However, actually nowadays I think different about the idea to have TURN natively integrated into the Nextcloud Talk app, for the following reasons:
coturnis indeed THE standard TURN server on the open source market. At least I couldn’t find any other for Linux. But integrating it into the Talk app would weaken possible alternative/new solutions from the start, and, is a decision that can be hardly reverted afterwards, e.g. if a better/modern new TURN implementation arises with promising advantages. So it limits flexibility after all.
However this has nothing to do with 3rd party distros/solutions to have an integrated installer that does install and setup of Nextcloud + Talk app + TURN server all together.
Just a final history note about the Talk app:
About more details how to install and configure coturn with Nextcloud as automated script, I just link the current code we use in DietPi, for reference. In the Nextcloud VM this looks similar, but both depend moreless on the base system, which might be different on Yunohost:
coturnpackage (valid e.g. on Debian/Ubuntu based distros): https://github.com/Fourdee/DietPi/blob/d3919b8120899a848b20c33f0f2de40b806fb7ba/dietpi/dietpi-software#L3793-L3802
Thanks for describing the procedure. I have successfully followed it on a OpenSUSE host, using the the turnserver package by Bruno Friedmann found in OpenSUSE Buildservice
I have seen that the plain is also listening.
Is this worrying in terms of security that e.g. a video call is unencrypted to the turn server?
I will answer to the GitHub issue.
I found this link: https://www.netways.de/blog/2017/08/16/setting-up-a-turn-server-for-nextcloud-video-calls/ very useful. With that I managed to get a stable Talk experience.
Jep this pretty much matches this HowTo. Only thing is I removed
lt-cred-mech. See the changelog it OT.
does anyone have a working docker setup (docker run … or docker-compose file) for TURN server and nextcloud?
Hi everyone, I created a new topic for my configuration problem Talk - call and video-call does not work remains black screen
I searched a solutions in the forum but I didn’t find what I need, I ask you for help for any further configuration on my TURN server.
Great, many thanks for this great tutorial! Works like a charm!
I’ve installed the Talk application onto my nextCloud instance and bumped onto some issues, so came here with some troubleshooting questions…
First, a bit of context:
Results are not too bad:
Obviously read all thread you guys pointed at in this thread!
Now for the questions:
It’s not clear to me as I tested the default config with the Trickle ICE page and got positive results with turn:stun.mydomain.com:3478?transport=tcp. Is finally the TURN server (probably coturn) already installed on my machine? So why wouldn’t colleagues in HQ get any video stream?
Thanks in advance for any help!
That is it, and also to allow internal people call external ones. AFAIK the direction, which should be only signaling layer, does not play a role.
Nope, you can install it on the same machine where Nextcloud is installed on. A separate server makes sense only if you want to more strictly separate for permissions/security reasons or to devide load for performance reasons.
Another reason to have a separate coTURN server would be in large setups (large number of frequent users) where it is benefitial to have coTURN directly connected to the www and not behind a NAT, while for other reasons you might want to have Nextcloud behind the NAT.
This is the script used on Nextcloud VM, right? I would not use it, but only as an idea what steps are done. However it includes some special steps/paths that are valid for the Nextcloud VM setup only. Follow this HowTo instead, which is valid for all kind of systems.
Which script? The VM one? As said, go through the HowTo steps manually. However coTURN (or any provided steps) do not tangent the remaining server setup/config. It is a standalone program that has no special needs about the underlying system.
Not sure what/how Trickle ICE tests exactly, but I would check on the server itself if coTURN is installed and the related process running. Then run the TURN test on Nextcloud admin panel, as this is what finally needs to work. However the address you posted looks good, although I suggest you use UDP instead of TCP in most cases.
If you assurred coTURN is up and the TURN server test on Nextcloud admin panel succeeds (so is configures correctly as well), I would do some own test from outside the local server network. E.g. try video call from home to HQ (if the coTURN server is located there) and check the logs from coTURN if it actually receives and handles the requests, so that the local network part is assured to be setup correctly. There are cases where network firewalls only allow TLS requests to pass, so then you would need to enable TLS within the coTURN settings.
Reading your answer back from vacation and wanted to thank you for such detailed content!
I’l then try to install coturn on the server, following the HowTo steps and check from the nextCloud admin… Actually, the admin settings page displays the icon when checking the (default) turn.mydomain.com server, which probably indicates ther’s no TURN server at all.
Thanks again, back when done!
It just means that Nextcloud cannot access the entered coTURN, which can have different reasons. Check server state on the system, e.g. on Debian/Ubuntu
systemctl status coturn, and if it is up, assure that entered domain and port are correct + the port is open/forwarded through NAT.