NC 11 spreed app no access outside LAN

ℹ️ Support
1

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?

2

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.

In case:

		apt-get install coturn
		openssl rand -hex 32
                        => XXX
		nano /etc/turnserver.conf
			listening-port=8443
			fingerprint
			lt-cred-mech
			use-auth-secret
			static-auth-secret=XXX
			realm=your.server.domain
			total-quota=100
			bps-capacity=0
			stale-nonce
			log-file=/var/log/turn.log
			no-loopback-peers
			no-multicast-peers
		nano /etc/default/coturn
			TURNSERVER_ENABLED=1
		service coturn restart

In nextcloud admin panel:

Spreed video calls

STUN server:                 your.server.domain:8443
TURN server:                 your.server.domain:8443
TURN server shared secret:   XXX
TURN server protocols:       udp and tcp
1 Like
3

That worked like a charm! Now hundreds of people get to see my ugly mug :smiley:

Can you break down the following options for me?

I understand the others, but not sure why these are uncommented, and why so many other options are also left uncommented?

4

I actually also only got it from the guide/discussion here: Complete NC installation on Debian with Spreed.me and TURN step by step

Also only understood half at that time and still do :joy: . 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.

€: https://github.com/coturn/coturn/wiki/turnserver
There they explain the options, but my knowledge is too low to understand all of them:

  • 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.
  • lt-cred-mech Use long-term credentials mechanism (this one you need for WebRTC usage).
    http://stackoverflow.com/questions/26110412/is-long-term-credentials-authentication-mechanism-required-for-webrtc-to-wor here some more information about this. Seems to be necessary to stay authenticated on the TURN server during WebRTC session.
  • 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 (224.0.0.0 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.

5

Thanks for this solution. This works for me :slight_smile: