How to troubleshoot Talk video

Nextcloud version: 27.1.0
Talk Server version: 17.1.0
Custom Signaling server configured: no
Custom TURN server configured: no (had coturn but disabled to go back to basics)
Custom STUN server configured: no
Server OS: Debian 12
PHP version: 8.2 (fpm with apache as webserver)

In case the web version of Nextcloud Talk is involved:
Operating system: Ubuntu 23.04
Browser name and version: Firefox 117 (deb from ppa:mozillateam)

The issue you are facing:
Video calls don’t get established, both parties see themselves and a rotating circle on the other user that they are trying to connect.
At first I was trying this in combination with coturn and devices on different networks (cell hotspot + home network) and since that was not working I reverted to the base case that should work as far as I understand - two devices on the same network.

Is this the first time you’ve seen this error? Y (but it’s the first time I’m trying to use Talk)

Steps to replicate it:

  1. Start video call
  2. Join the call from another device on the same network

The output of your Nextcloud log in Admin > Logging or errors in nextcloud.log in /var/www/:
No spreed related log entries found

The output of your Apache/nginx/system log in /var/log/____:
Based on the apache log it looks like one of the clients is using IPv4 to connect while the other is using IPv6, maybe this is some edge case with dual stack networks, even with IPv6 if one client is coming from link-local (nextcloud is selfhosted on my home network) and the other from one of the other IPv6 blocks stuff is not working

I disabled IPv6 on both test systems and the problem persisted.

I have the same error scenario with Nextcloud 27.1.5 and Talk 17.1.4 using the latest signaling server. I have STUN and TURN Server configured and everything works fine without the signaling server.

Any hint would be greatly appreciated.

When it’s working fine without the signaling server, you need to take a look at the signaling server logs and the browsers console to figure out what’s going on.
Also make sure TURN works: Overview - Nextcloud Talk API documentation

Thank you, @SysKeeper !

TURN is working (checked with turnutils_uclient). But I have an error in the janus.log everytime I start a video call (using the same IP and port as in turnutils_uclient):

[WARN] Could not set TURN server, is the address correct? ([IP]:3478)

For the tests, I temporarily disabled the firewall to avoid issues.

How does your signaling config looks like? (Please remove an sensitive values before posting)


listen =

debug = false

hashkey = [hash]
blockkey = [hash]

backends = backend-1
allowall = true
timeout = 10
connectionsperhost = 20

url = https://sub.domain.tld
secret = [hash]

url = nats://localhost:4222

type = janus
url = ws://

apikey = [key]
secret = [hash]
servers = turn:signaling.domain.tld:5349?transport=udp,turn:signaling.domain.tld:5349?transport=tcp

Never set that to true, if you’re using it in production.

I would advice to disable TURN on the signaling for now and test again. Usually that is not needed.

Still no luck. I disabled turn in server.conf by commenting out the lines, added the configuration in the Nextcloud Talk configuration and tried a conf call with two different users/browsers.

The signaling log shows:

$ sudo journalctl -u signaling -xn --no-pager

Jan 16 22:41:08 xxxx signaling[1825018]: backend_client.go:167: Could not send request {“type”:“room”,“room”:{“version”:“1.0”,“roomid”:“qfmgbqe2”,“userid”:“xxx@xxx.xx”,“sessionid”:“xxxx”}} to https://sub.domain.tld/ocs/v2.php/apps/spreed/api/v3/signaling/backend: Post “https://sub.domain.tld/ocs/v2.php/apps/spreed/api/v3/signaling/backend”: context deadline exceeded

This sounds like your signaling server is not able to communicate with the instance. Maybe the IP of the signaling server was bruteforce throttled by Nextcloud? Does the secret really match?

I set up talk with a standalone signaing server on my server, calls connected some of the time, but often just wouldn’t. For this reason I abandoned Talk.

What does bruteforce throttled mean? How can I check this?
The secrets are matching, I think there would be an authentication error if not.

@SysKeeper I would appreciate if you can explain what is meant by “bruteforce throttled by Nextcloud”?

Hey, you can check via occ (see Using the occ command — Nextcloud latest Administration Manual latest documentation). With occ security:bruteforce:attempts and the IP of the signalingserver it should show if bruteforce protection comes into play here or not. If that is the case, you can issue occ security:bruteforce:reset to remove these attempts