Screensharing doesn't work properly: Nextcloud Talk & Turnserver

nc15
talk
turn
#1

Screensharing doesn’t work properly: Nextcloud Talk & Turnserver

Hello,
I’m fighting with some serious problem with Talk video calls based on my ignorance, natural perversity of inanimate objects or whatever it is ;). I tried to configure Nextcloud Talk (15.0.7) and Coturn turnserver (v4.5.0.7) to working appropriate together but it’s remains unbeatable. Both servers running on different VPS with public static IP on 443/80 port. I also followed every instructions and hints included on that very good howto tutorial and tried to duplicate every step properly.
Basically, using screen sharing during video calls with users not behind firewall makes video and audio stream freeze (but chat seems to be working fine) generates turnserver’s authorization errors described below. It unlocks when users close screenshare stream.
Test was realized with Firefox browser (v66.0.3). Usage of Chrome browser (v70.0) didn’t change anything.

My configuration of turnserver.conf based on howto tutorial:

listening-port=80
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=13d5d...
realm=turn.example.com
total-quota=100
bps-capacity=0
stale-nonce
cipher-list="ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5"
no-loopback-peers
no-multicast-peers
log-file=/var/log/coturn.log
syslog

Note: domain and secret values are just examples

Nextcloud Talk configuration:

STUN server: stun.nextcloud.com:443
TURN server: turn.example.com:80
TURN secret: 13d5d…

Errors i get from syslog:

Apr 24 09:33:38 pmuszynskilg turnserver: 65616: session 000000000000002494: realm <test.codeslav.pl> user <>: incoming packet message processed, error 401: Unauthorized
Apr 24 09:33:39 pmuszynskilg turnserver: 65617: session 000000000000002497: realm <test.codeslav.pl> user <>: incoming packet message processed, error 401: Unauthorized

That errors continues while users trying to screenshare any window during other participants sharing his cam and/or mic. Visually it makes video freeze or dissapearing for others who are sharing screen (nor for .

Of course all ports needs to be open are open (in my case port 80) on server and client sites.
Could it be something wrong with turnserver version? I’m losing hope on this.

Thanks in advance for any hints or solutions!

P.S i hope my poor English will allow you to understand my problem.

1 Like
#2

I just wanted to open almost the same thread, but maybe I have the same issue.

Connections via Talk with Chat between local and remote users are always working. Usually users can see my video, sometimes I can see their video but it often freezes, but screen sharing is the biggest problem. Today for example the remote user could see my webcam and my even my screensharing, but he could not share his screen. Last time my colleague used talk, he could’nt share his screen to the remote users.
My only idea was the turn server too, especially because I’m getting the same error as @Przemek_Muszynski

870151: session 003000000000000431: realm <nextcloud.example.com> user <>: incoming packet message processed, error 401: Unauthorized

That’s our setup:

Nextcloud 15.0.7 on local Debian 9.8
PHP 7.2.17
Apache 2.4.25
Talk 5.0.3

Coturn 4.5.0.5 behind Router with Firewall (Fritzbox) on the same machine as nextcloud
STUN-Server: stun.nextcloud.com:443
TURN-Server: nextcloud.example.com:5349

In the router Ports 80,443,5349 are forwarded to the server. 5349 TCP and UDP.

Note: nextcloud.example.com is just an example about the real domain.
Our IP is a dynamic one provided by our ISP, but with a working DynDNS-Service

turnserver.conf is little bit different than above, including SSL:

tls-listening-port=5349
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=a98aa...                                                        
realm=nextcloud.example.com
total-quota=100
bps-capacity=0
cert=/etc/letsencrypt/live/nextcloud.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/nextcloud.example.com/privkey.pem
cipher-list="ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA38$
no-tlsv1
no-tlsv1_1

Help is very appreciated too!

#3

This is an expected error, as far as I remember. The first request is done without credentials, so the error is reported, the client then sends the second request with credentials which then succeeds. If video generally works, then this should be a prove that the TURN server works as expected.

Did you (two) monitor CPU and RAM usage when entering screen sharing? I did not test this yet, will do later.

#4

I’m gonna check this next week. Do you mean on the server or (both) clients?

#5

I mean on the server.

#6

Hi, 401 is not a fatal error it is part of the auth process.
It is only problem if the client does not answers for the second time with the right credential.
See: slide 4-5