Nextcloud version (eg, 10.0.2): 11
Operating system and version (eg, Ubuntu 16.04): 16.04
Apache or nginx version (eg, Apache 2.4.25): Apache 2.4.18
PHP version (eg, 5.6): 7.0.8
Is this the first time you’ve seen this error and can you replicate it?: No, seeing similar issues with Jitsi, though that’s because I don’t have a STUN server for it.
The issue you are facing:
So any person trying to join a video call from outside the LAN is greeted with a black screen and nothing more. I know this has been an issue with the old spreed.me server install method, though with the STUN settings being configured by default I assumed this would be solved for the video calls app.
Are there particular ports I need open for it to work, or must I spin up a TURN server?
At least this is the first thing I would try, if spreed inside LAN and nextcloud generally outside LAN works fine. For me it also works just with TURN server, and so far I did not yet understand in what cases STUN could already work and how one could achieve this for his own server.
Also only understood half at that time and still do . Maybe later I will use some time to check out these settings.
Also I am not sure if maybe the one or the other could be left out, didn’t try so far.
fingerprint Use fingerprints in the TURN messages. If an incoming request contains fingerprint, then TURN server will always add fingerprints to the messages in this session, regardless of the per-server setting. What is meant by “TURN messages”, all WebRTC traffic passing the TURN server, or just the initial one? And who/what checks the fingerprint and what would be the consequence if there is no match? €: After going forward through the options I guess it’s all about the authentication on the TURN server.
total-quota Total allocations quota: global limit on concurrent allocations. Seems to be the maximum number of connections and therefore parallel WebRTC users on your server. Sadly they don’t say something about the default value of this.
bps-capacity Maximum server capacity. Total bytes-per-second bandwidth the TURN server is allowed to allocate for the sessions, combined (input and output network streams are treated separately). Bandwidth for the TURN server and therefore WebTRC sessions. I guesss “0” means that there is no limitation.
In subsequent communications, the client may go with exactly the same sequence, but for optimization usually the client, having already information about realm and nonce, pre-calculates the integrity string for each request, so that the 401 error response becomes unnecessary. The TURN server may use “–stale-nonce” option for extra security: in some time, the nonce expires and the client will obtain 438 error response with the new nonce, and the client will have to start using the new nonce. I needed to read some more about what a nonce is:https://en.wikipedia.org/wiki/Cryptographic_nonce So it’s some security feature against reply attacks.
no-loopback-peers Disallow peers on the loopback addresses (127.x.x.x and ::1). no-multicast-peers Disallow peers on well-known broadcast addresses (22.214.171.124 and above, and FFXX:*). Seems to be reasonable to block there adresses, how ever a successful TURN request through these could happen:https://en.wikipedia.org/wiki/Multicast
At least I got an idea about what all this is about. I am missing default values there, especially as some of the options seem necessary or at least very reasonable I would expect them to be default.