It does. We’ll support this in the future.
Yes, worked for me nice on three different phones with different ROMs. The only downside is/was to enable signature spoofing to allow microg fake Gapps signatures. Was only reliably possible by installing another framework again (xposed), which felt like an overhead, thou way less than Gapps . But there seem to be more alternatives now: https://github.com/microg/android_packages_apps_GmsCore/wiki/Signature-Spoofing
Going little bit off topic . Turning back: I was just reinstalling Talk on my Nextcloud to give it another try, after spreed didn’t want to work for me through outside local network, even than coturn was configured (Spreed.ME did well). There are still many working guides on how to install and configure coturn, bit I am missing a big hint/link/wiki from official side. A TURN server is still necessary for nearly everybody who wants to video chat though the internet, or am I wrong?
Awesome, thank you so much!
Yes, TURN is needed for quite a few people I guess. There’ll be some links or at least mentions that you need STUN & TURN and what they are eventually
Quick check reveals this might be good enough?
Ah thanks for linking that guide. I am thinking of enabling the STUN/TURN on my ejabberd XMPP server that links to Nextcloud user accounts anyways (through JSXC app). But I wonder… if I enable TURN will it be used all the time, or how likely is it that it will be used as a fallback? Is there some way to rate-limit the TURN proxying so that my server isn’t bogged down by multiple video streams proxied?
If you enable TURN, you’ll be able to talk when you otherwise wouldn’t be able to - firewalls, routers, stuff like that. So I’d say it’s either you want to talk or you don’t want to talk
Isn’t TURN a server side setting for the Talk app? So some users might require is, but other don’t…
You have to add the TURN server to the NC config, so you use it always.
Even my small Raspi can handle four simultanous calls without a problem, and cpu usage stays very low. (0.2% while idle, 2.1% with four audio/video calls)
If you check the config from Coturn, you will find several settings like max-bps or bps-capacity.
Just give it a try. It’s very easy to install, and if it dont fit your needs, also very easy to remove.
Hmm, but it will use quite a bit of server bandwidth… also additional potentially unnecessary meta data users might not want to be created on the server.
Would be indeed nice if it is used as a kind of fallback:
- Try direct P2P without TURN/STUN
- If it fails, try with just STUN
- If it still does not work, go with TURN.
But I don’t know how to reliable check if it fails due to missing STUN/TURN without waiting for long timeouts.
This is already how it works.
RTCPeerConnection tries to set up direct communication between peers over UDP. If that fails, RTCPeerConnection resorts to TCP. If that fails, TURN servers can be used as a fallback, relaying data between endpoints.
Nice, then, giving the hint that TURN could be necessary for non-local calls, including some link to/or maybe “official” guide on GitHub wiki, including necessary TURN server settings on example of coturn, would be everything helpful I can think of.
Thanks for all the great work !
let’s talk at FOSDEM
Integrating Zulip seems quite useless - not PHP and no federation so it actually can’t be integrated in Nextcloud and can’t chat between different servers. We plan to integrate with XMPP and Matrix as those are the most relevant, federated solutions.
Not necessarily. The end user’s web browser (i.e. Firefox, Chrome, Chromium etc.) features a technology called ICE which tries to pave a way between Ana and Bob (the call participant’s end points)
It always tries the direct way first - so if Ana and Bob are on the same LAN - the signal goes directly.
If that fails - and this will if for instance Ana or Bob or both are behind NAT routers - then it tries STUN: calling the STUN server to find out which IP public addresses are involved and then try to punch a whole into the NAT router (i.e. establish an incoming path at the far side router)
In most cases this will work. Modern routers include technologies such as UPnP to facilitate this.
But there are nasty cases - like “symmetric NAT”. In this case both routers refuse to establish an incoming route to the endpoint unless the request comes from the same IP address. Only in this case TURN comes into place to route the signal data via a public IP.
This is easy to find out: on the machine your TURN server is running, start a tcpdump -i eth0 (or whatever is the public interface) - then issue a call and observe the packets. You can even see where they come from and where the go to. Fun when you’re on mobile or a corporate / hotel / congress network - sometimes the routing goes criss cross. When you don’t have root access on yout TURN machine, try bwm or bwm-ng to see the bandwith used.
- both endpoints behind popular SOHO routers (Deutsche Telekom and Fritzbox) -> No turn
- one endpoint on mobile: (in this case O2 Germany - they all have carrier grade NAT) - may or may not need TURN
- both endpoints on mobile: definitely TURN
- I haven’t been able to test IPv6 (it simply doesn’t route ist via this protocol)
- neither could I test popular German cable providers which also come with carrier NAT - but offer a public IPv6 address
Perhaps someone else can test this - in other countries as well.
Yes, please include it the option to limit bandwidth. Otherwise you will burn your whole monthly limit with one video call.
So far I have not found a self hosted mobile friendly video call solution. So I was forced to continue using Skype.
Appear.in is great, but does not alöways work with all browsers, it is Webrtc as well (I think) and has the lowest bandwidth usage of all options I tested (down to 128kb/sec or so), I used it a few times while on a mobile network
So initially, the install of RC2 and the Talk app went smoothly. I have a very robust Coturn server (STUN and TURN) that works great. I tested two users on same LAN => worked great. I then tested two users, one local and one remote (through VPN) => worked great again. I then tested two users, one desktop, one mobile (on phone network) => perfect again! I then installed the Screen Share add-on (was skeptical as it hadn’t been updated since March 7, 2017), shared my desktop screen with the mobile user => still the webcam, no shared desktop from the desktop web client to the phone/mobile user. I then did a chat from the web user to the mobile user… no conversations show up, nor do I know where to start one from the mobile application.
Other than desktop screen sharing and chat integration, this app was extremely easy to install and use.
Thanks and keep up the great work Nextcloud.
Sounds like a feature request you should put into the corresponding Github issue tracker: