25.0.0: app opens many parallel signaling websockets that die after exactly 60 s, call drops and rejoins every minute

Steps to reproduce

1. Talk Android 25.0.0 (Play Store), signed in to a Nextcloud with the standalone signaling server (HPB).
2. Join a call from the app (mobile data or Wi-Fi, same result) and stay in it.
3. 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):

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.

Start by comparing the 25.0.0 background conversation preloading behavior with 24.0.4 and trace where signaling websocket connections are created. Reproduce an active call and an idle background session while checking the proxy and signaling logs; done means one stable socket per session without minute-long leave/rejoin cycles.