Steps to reproduce
- Talk Android 25.0.0 (Play Store), signed in to a Nextcloud with the standalone signaling server (HPB).
- Join a call from the app (mobile data or Wi-Fi, same result) and stay in it.
- Watch the conversation: the system messages show the user leaving and rejoining the call about once a minute.
Expected behaviour
One signaling websocket per session, kept open as long as the app is in the call (this is what 24.0.4 and the web client do on the same server).
Actual behaviour
The app opens 5-13 websocket connections to the signaling server at the same time. They all close after exactly 60 s (sometimes 30 s or 120 s). The signaling server logs Closing previous client from <ip> for session X five or six times within one second for each burst, and after a few bursts the app gives up resuming and registers a completely new session (Register user ... + Closing session X because same room session ...). The new session replaces the old one in the call, so every other participant sees the user leave and rejoin, the publisher is torn down (Publisher ...: associated room has been destroyed) and audio/video restart. In a one-hour meeting today this happened nine times in eight minutes; we had to move to another tool.
The same connection churn happens while the app is idle in the background, so it is not tied to the call UI - it only becomes visible in a call.
Evidence from the reverse proxy in front of the signaling server
Lifetimes of GET /spreed websocket connections per app version, one line per day (same phone, same user, same server; nothing on the server changed between the days):
| day |
app version |
sockets |
ended at exactly 60 s |
>10 min |
| 2026-09-03 .. 09-15 |
24.0.4 |
17-127 per day |
0 on every day |
0-1 |
| 2026-09-16 |
25.0.0 (updated that day) |
23 |
5 |
0 |
| 2026-09-17 |
25.0.0 |
251 |
99 |
0 |
Browser and iOS clients on the same entry point keep a single socket open for more than 10 minutes, so the proxy and the server are not cutting anything. A guest on iPhone Safari in the same call had one stable session for the whole meeting.
Signaling server log excerpt (session ids shortened):
14:28:19 room.go:899: Session cYJO... joined call kzvggzq5
14:28:44 hub.go:1396: Closing previous client from <ip> for session cYJO...
14:28:44 hub.go:1396: Closing previous client from <ip> for session cYJO...
14:28:45 hub.go:1396: Closing previous client from <ip> for session cYJO...
14:28:45 hub.go:1396: Closing previous client from <ip> for session cYJO...
14:28:45 hub.go:1396: Closing previous client from <ip> for session cYJO...
14:28:45 hub.go:1396: Closing previous client from <ip> for session cYJO...
14:29:02 hub.go:1064: Register user tv@... from <ip> (Mozilla/5.0 (Android) Nextcloud-Talk v25.0.0) m5_r...
14:29:03 hub.go:1710: Closing session cYJO... because same room session XFqF...
14:29:03 publisher.go:72: Publisher 3458365053605834: associated room has been destroyed, closing
14:29:03 room.go:899: Session m5_r... joined call kzvggzq5
Room system messages for the same minutes: call_started 14:28:18, call_left/call_ended (duration 62) 14:29:20, call_started 14:29:21, call_left/call_ended (duration 60) 14:30:21, and so on.
My guess is the new background preloading of conversations (25.0.0 changelog) creating extra signaling connections, but I have not verified that in the code.
Environment
- App: Nextcloud Talk Android 25.0.0 (Google Play). Not reproducible with 24.0.4 on the same phone.
- Phone: Honor Magic V5 (MBH-N49), MagicOS / Android 16
- Server: Nextcloud 34.0.4, Talk (spreed) 24.0.5, nextcloud-spreed-signaling (docker image strukturag/nextcloud-spreed-signaling:latest as of 2026-09-08), Janus 1.3.0, coturn.
- Network: mobile 5G and Wi-Fi behind a Traefik reverse proxy; websocket timeouts are not the cause (see the browser sessions above).
Happy to provide the full signaling log for the time window or run a debug build.
AI disclosure
This report was co-authored with Claude (Claude Fable 5.1, via Claude Code): it read the signaling and proxy logs and drafted the text; I reviewed it. The log lines and the numbers in the table are real output, not model claims.
Steps to reproduce
Expected behaviour
One signaling websocket per session, kept open as long as the app is in the call (this is what 24.0.4 and the web client do on the same server).
Actual behaviour
The app opens 5-13 websocket connections to the signaling server at the same time. They all close after exactly 60 s (sometimes 30 s or 120 s). The signaling server logs
Closing previous client from <ip> for session Xfive or six times within one second for each burst, and after a few bursts the app gives up resuming and registers a completely new session (Register user ...+Closing session X because same room session ...). The new session replaces the old one in the call, so every other participant sees the user leave and rejoin, the publisher is torn down (Publisher ...: associated room has been destroyed) and audio/video restart. In a one-hour meeting today this happened nine times in eight minutes; we had to move to another tool.The same connection churn happens while the app is idle in the background, so it is not tied to the call UI - it only becomes visible in a call.
Evidence from the reverse proxy in front of the signaling server
Lifetimes of
GET /spreedwebsocket connections per app version, one line per day (same phone, same user, same server; nothing on the server changed between the days):Browser and iOS clients on the same entry point keep a single socket open for more than 10 minutes, so the proxy and the server are not cutting anything. A guest on iPhone Safari in the same call had one stable session for the whole meeting.
Signaling server log excerpt (session ids shortened):
Room system messages for the same minutes: call_started 14:28:18, call_left/call_ended (duration 62) 14:29:20, call_started 14:29:21, call_left/call_ended (duration 60) 14:30:21, and so on.
My guess is the new background preloading of conversations (25.0.0 changelog) creating extra signaling connections, but I have not verified that in the code.
Environment
Happy to provide the full signaling log for the time window or run a debug build.
AI disclosure
This report was co-authored with Claude (Claude Fable 5.1, via Claude Code): it read the signaling and proxy logs and drafted the text; I reviewed it. The log lines and the numbers in the table are real output, not model claims.