No Video calls possible through Talk

Hi guys,

I’ve been running Nextcloud since a while and also using the Hub functionality.

Nextcloud version: 23.0.0
Operating system and version: Debian 10.11 managed through Plesk Obsidian Version 18.0.40 Update #1
Apache or nginx version: apache2 2.4.38-3+deb10u7
PHP version: 7.4.27

The issue you are facing:
I can’t do any Video calls any more through the Nextcloud Talk platform. The connection cannot be established. Internal network calls are working. We have set up a turn server and it seems to be running. Ports in the firewall are open. The Nextcloud Admin says it can’t get working ICE-candidates back (probably there is no connection at all).

We had it working after setting up the turn server for around 5 months. Then, the feature hasn’t been used for a while and now it stopped working.

My thoughts are that some configuration within Plesk are blocking the communication, but I’m not sure.

Is this the first time you’ve seen this error? : No

Steps to replicate it:

  1. Call some one
  2. Wait for them to join

The output of your Nextcloud log in Admin > Logging:

didn't find any relevant error messages in Nextcloud log

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'instanceid' => 'xx',
  'passwordsalt' => 'x',
  'secret' => 'x',
  'trusted_domains' => 
  array (
    0 => 'x',
  ),
  'datadirectory' => '/var/www/vhosts/x/x/data',
  'dbtype' => 'mysql',
  'version' => '23.0.0.10',
  'overwrite.cli.url' => 'x',
  'dbname' => 'x',
  'dbhost' => 'x',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'x',
  'dbpassword' => 'x',
  'installed' => true,
  'app.mail.verify-tls-peer' => false,
  'maintenance' => false,
  'loglevel' => 0,
  'twofactor_enforced' => 'false',
  'twofactor_enforced_groups' => 
  array (
    0 => 'Employees',
    1 => 'Management',
  ),
  'twofactor_enforced_excluded_groups' => 
  array (
    0 => 'admin',
  ),
  'theme' => '',
  'encryption.legacy_format_support' => true,
  'encryption.key_storage_migrated' => false,
  'app_install_overwrite' => 
  array (
    0 => 'calendar',
    1 => 'apporder',
  ),
  'ldapIgnoreNamingRules' => false,
  'ldapProviderFactory' => 'OCA\\User_LDAP\\LDAPProviderFactory',
  'mail_smtpmode' => 'smtp',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'x',
  'mail_domain' => 'xx',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'mail_smtphost' => 'x',
  'mail_smtpport' => '25',
  'mail_smtpname' => 'xx',
  'mail_smtppassword' => 'xx',
);

The output of your Apache/nginx/system log in /var/log/____:


didn't find any relevant error messages in Plesk log

Thanks for your help in advance!

This is the webRTC Logfile from about:webrtc.
Does this help?

https://pastebin.com/wyxg8biB

Just looked quickly, but noticed this


(stun/INFO) STUN-CLIENT(relay(IP4:192.168.0.29:0/TCP|IP4:0.0.0.0:3478/TCP)::TURN): Received response; processing
 
(stun/WARNING) STUN-CLIENT(relay(IP4:192.168.0.29:0/TCP|IP4:0.0.0.0:3478/TCP)::TURN): nr_stun_process_error_response failed
 
(stun/WARNING) STUN-CLIENT(relay(IP4:192.168.0.29:0/TCP|IP4:0.0.0.0:3478/TCP)::TURN): Error processing response: Retry may be possible, stun error code 401.
 
(stun/INFO) STUN-CLIENT(relay(IP4:192.168.0.29:0/TCP|IP4:0.0.0.0:3478/TCP)::TURN): Received response; processing
 
(stun/WARNING) STUN-CLIENT(relay(IP4:192.168.0.29:0/TCP|IP4:0.0.0.0:3478/TCP)::TURN): nr_stun_process_error_response failed
 
(stun/WARNING) STUN-CLIENT(relay(IP4:192.168.0.29:0/TCP|IP4:0.0.0.0:3478/TCP)::TURN): Error processing response: Retry may be possible, stun error code 401.

You might want to take a look at that

Thanks for the hint. I reconfigured the coturn server from scratch and now also went with the 5349 port.
Now my webrtc log is a lot shorter and also in the browser I’m getting a different Error

Browser

WebRTC: Using more than two STUN/TURN servers slows down discovery 2 talk-main.js:1
WebRTC: Using five or more STUN/TURN servers causes problems talk-main.js:1
Uncaught 
Exception { name: "NS_ERROR_UNEXPECTED", message: "", result: 2147549183, filename: "https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9", lineNumber: 1, columnNumber: 0, data: null, stack: "l@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3558610\n52160/c.prototype.createPeer@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3578520\nu@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3481444\n97456/$/</N[o]<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3482124\nsetInterval handler*97456/$/<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3481978\n$@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3480873\nH@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3483261\n97456/q/<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3483875\n97456/h.Base.prototype._trigger@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3456178\n97456/h.Internal.prototype._startPullingMessages/</<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461679\n97456/h.Internal.prototype._startPullingMessages/<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461584\npromise callback*97456/h.Internal.prototype._startPullingMessages@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461425\n97456/h.Internal.prototype._startPullingMessages/<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461963\npromise callback*97456/h.Internal.prototype._startPullingMessages@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461425\n97456/h.Internal.prototype._startPullingMessages/<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461963\npromise callback*97456/h.Internal.prototype._startPullingMessages@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461425\n97456/h.Internal.prototype._startPullingMessages/<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461963\npromise callback*97456/h.Internal.prototype._startPullingMessages@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461425\n97456/h.Internal.prototype._startPullingMessages/<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461963\npromise callback*97456/h.Internal.prototype._startPullingMessages@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461425\n97456/h.Internal.prototype._startPullingMessages/<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461963\npromise callback*97456/h.Internal.prototype._startPullingMessages@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461425\n97456/h.Internal.prototype._startPullingMessages/<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461963\npromise callback*97456/h.Internal.prototype._startPullingMessages@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461425\n97456/h.Internal.prototype._startPullingMessages/<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461963\npromise callback*97456/h.Internal.prototype._startPullingMessages@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461425\n97456/h.Internal.prototype._startPullingMessages/<@https://Server_URL/apps/spreed/js/talk-main.js?v=64056a2d-9:1:3461963\n" }
talk-main.js:1
Remove disconnected peer X9HlvAB9eHuhrxVziAjF4peAWkBNou0rgx+VAF5uIXkf+9P1BoQRttm8rgdl/c9UE0x1xjCIhj8n9f1aQrqqiC1OvSP+25HRp8QjZCnp6dilXYUb4rP5ZYFVig9WtDAytpPikNR9NMSPqF/oGAa9MXyKU92uLltoMcV1eZxlkGLSuafafmnmmqC6LcqA4Lb+/3+qWv8Q2QAG3DwjtErwtli6VCzfRUy7TowaR/0HYsQ9YlYukSRSPMu6T3ui1Hy webrtc.js:411:2


I’ve only one STUN & TURN Server saved in the settings. Not sure were the warning comes from

WebRTC Connection Protcoll

+++++++ BEGIN (process id 17748) ++++++++

(registry/INFO) insert 'ice' (registry) succeeded: ice

(registry/INFO) insert 'ice.pref' (registry) succeeded: ice.pref

(registry/INFO) insert 'ice.pref.type' (registry) succeeded: ice.pref.type

(registry/INFO) insert 'ice.pref.type.srv_rflx' (UCHAR) succeeded: 0x64

(registry/INFO) insert 'ice.pref.type.peer_rflx' (UCHAR) succeeded: 0x6e

(registry/INFO) insert 'ice.pref.type.host' (UCHAR) succeeded: 0x7e

(registry/INFO) insert 'ice.pref.type.relayed' (UCHAR) succeeded: 0x05

(registry/INFO) insert 'ice.pref.type.srv_rflx_tcp' (UCHAR) succeeded: 0x63

(registry/INFO) insert 'ice.pref.type.peer_rflx_tcp' (UCHAR) succeeded: 0x6d

(registry/INFO) insert 'ice.pref.type.host_tcp' (UCHAR) succeeded: 0x7d

(registry/INFO) insert 'ice.pref.type.relayed_tcp' (UCHAR) succeeded: 0x00

(registry/INFO) insert 'stun' (registry) succeeded: stun

(registry/INFO) insert 'stun.client' (registry) succeeded: stun.client

(registry/INFO) insert 'stun.client.maximum_transmits' (UINT4) succeeded: 7

(registry/INFO) insert 'ice.trickle_grace_period' (UINT4) succeeded: 5000

(registry/INFO) insert 'ice.tcp' (registry) succeeded: ice.tcp

(registry/INFO) insert 'ice.tcp.so_sock_count' (INT4) succeeded: 0

(registry/INFO) insert 'ice.tcp.listen_backlog' (INT4) succeeded: 10

(registry/INFO) insert 'ice.tcp.disable' (char) succeeded: \000

(registry/INFO) insert 'ice.forced_interface_name' (string) succeeded:

(registry/INFO) insert 'ice.udp' (registry) succeeded: ice.udp

(registry/INFO) insert 'ice.udp.use_nr_resolver' (char) succeeded: \001

LOGGING SUSPENDED: a connection is active in a Private Window ***

LOGGING RESUMED: no connections are active in a Private Window ***

+++++++ END (process id 17748) ++++++++

+++++++ BEGIN (process id 8388) ++++++++

(registry/INFO) insert 'ice' (registry) succeeded: ice

(registry/INFO) insert 'ice.pref' (registry) succeeded: ice.pref

(registry/INFO) insert 'ice.pref.type' (registry) succeeded: ice.pref.type

(registry/INFO) insert 'ice.pref.type.srv_rflx' (UCHAR) succeeded: 0x64

(registry/INFO) insert 'ice.pref.type.peer_rflx' (UCHAR) succeeded: 0x6e

(registry/INFO) insert 'ice.pref.type.host' (UCHAR) succeeded: 0x7e

(registry/INFO) insert 'ice.pref.type.relayed' (UCHAR) succeeded: 0x05

(registry/INFO) insert 'ice.pref.type.srv_rflx_tcp' (UCHAR) succeeded: 0x63

(registry/INFO) insert 'ice.pref.type.peer_rflx_tcp' (UCHAR) succeeded: 0x6d

(registry/INFO) insert 'ice.pref.type.host_tcp' (UCHAR) succeeded: 0x7d

(registry/INFO) insert 'ice.pref.type.relayed_tcp' (UCHAR) succeeded: 0x00

(registry/INFO) insert 'stun' (registry) succeeded: stun

(registry/INFO) insert 'stun.client' (registry) succeeded: stun.client

(registry/INFO) insert 'stun.client.maximum_transmits' (UINT4) succeeded: 7

(registry/INFO) insert 'ice.trickle_grace_period' (UINT4) succeeded: 5000

(registry/INFO) insert 'ice.tcp' (registry) succeeded: ice.tcp

(registry/INFO) insert 'ice.tcp.so_sock_count' (INT4) succeeded: 0

(registry/INFO) insert 'ice.tcp.listen_backlog' (INT4) succeeded: 10

(registry/INFO) insert 'ice.tcp.disable' (char) succeeded: \000

(registry/INFO) insert 'ice.forced_interface_name' (string) succeeded:

(registry/INFO) insert 'ice.udp' (registry) succeeded: ice.udp

(registry/INFO) insert 'ice.udp.use_nr_resolver' (char) succeeded: \001

LOGGING SUSPENDED: a connection is active in a Private Window ***

LOGGING RESUMED: no connections are active in a Private Window ***

+++++++ END (process id 8388) ++++++++

Nextcloud Logs
Nothing regarding the call…

Apache & Ngninx logs
nothing…

I’m checking further what it could be. I could not really find any logfiles really for the coturn server. Maybe it’s written somewhere, where I don’t find it. Just to see if plesk kills the log file somehow i disabled the “syslog” variable in the log file temporarily, which didn’t lead anything else really.

I tried to connect to the stun server via https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/, but could not reach the server which led me to the question again, is the server even running? so i tried

systemctl status coturn

which brought me to the following output:

 coturn.service - coTURN STUN/TURN Server
   Loaded: loaded (/lib/systemd/system/coturn.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2022-01-13 19:22:19 CET; 5s ago
     Docs: man:coturn(1)
           man:turnadmin(1)
           man:turnserver(1)
  Process: 4087 ExecStart=/usr/bin/turnserver --daemon -c /etc/turnserver.conf --pidfile /run/turnserver/turnserver.p
  Process: 4089 ExecStartPost=/bin/sleep 2 (code=exited, status=0/SUCCESS)
 Main PID: 4088 (turnserver)
    Tasks: 15 (limit: 4915)
   Memory: 12.1M
   CGroup: /system.slice/coturn.service
           └─4088 /usr/bin/turnserver --daemon -c /etc/turnserver.conf --pidfile /run/turnserver/turnserver.pid

Jan 13 19:22:17 SERVERNAME turnserver[4088]: 0: IO method (general relay thread): epoll (with changelist)
Jan 13 19:22:17 SERVERNAME turnserver[4088]: 0: turn server id=7 created
Jan 13 19:22:17 SERVERNAME turnserver[4088]: 0: Total General servers: 8
Jan 13 19:22:17 SERVERNAME turnserver[4088]: 0: IO method (auth thread): epoll (with changelist)
Jan 13 19:22:17 SERVERNAME turnserver[4088]: 0: IO method (auth thread): epoll (with changelist)
Jan 13 19:22:17 SERVERNAME turnserver[4088]: 0: IO method (auth thread): epoll (with changelist)
Jan 13 19:22:17 SERVERNAME turnserver[4088]: 0: IO method (auth thread): epoll (with changelist)
Jan 13 19:22:17 SERVERNAME turnserver[4088]: 0: IO method (admin thread): epoll (with changelist)
Jan 13 19:22:17 SERVERNAME turnserver[4088]: 0: SQLite DB connection success: /var/lib/turn/turndb
Jan 13 19:22:19 SERVERNAME systemd[1]: Started coTURN STUN/TURN Server.
~

So I think, his should be okay?
Since the server seems not to be reachable, I double checked also the firewall settings from Plesk again:

Allow incoming from all on ports 3478/tcp, 3478/udp, 5349/tcp, 5349/udp

So, I think this should be also okay.

This is the /etc/turnserver.conf:

tls-listening-port=5349
listening-ip=ipv4
listening-ip=ipv6
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=SECRET
realm=serveraddress
total-quota=100
bps-capacity=0
stale-nonce=600
cert=path-to-chain
pkey=path-to-key
cipher-list="ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384"
dh-file=/etc/ssl/private/dhparam.pem
no-stdout-log
syslog
no-multicast-peers
no-tlsv1
no-tlsv1_1

As it confused me, that I cannot find any log i tried find / -iname "*turn*.log" which brought me to: /var/tmp/systemd-private-cc16b650894f4e5494e7df35f2498dea-coturn.service-Qx6tmy/tmp/turn_7320_2022-01-13.log:

Screenshot 2022-01-13 194823

Weirdly enough we got it working now. I am still not sure why it didn’t work through the unencrypted channel. The problem layed within the Let’s Encrypt / Plesk settings. I used the standard domain certificate for the turnserver, but because of the rights management the turnserver could not read the certificate and didn’t open the 5349 port. After solving this we could establish a video connection.

Learnings from it:

  • Double check your configurations
  • Argue a bit about missing bits in the Plesk documentation
  • Check your firewall settings
  • Check wether your ports are even listened to