Joining call fails with 404 after long inactivity (app & browser)

[hubfc]

Tip

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Steps to reproduce

1. Open Talk in browser, do NOT join a call
2. Wait 2+ minutes, sometimes one day, sometimes over the weekend
3. Click "Join Call"

Expected behaviour

Call joins successfully

Actual behaviour

Error dialog "Please reload the page" or silent failure with infinite loading spinner (more often than Please reload page)

Current fix

Reloading the page or the app (STRG+R or CMD+R) manually. This solves the problem 100%, but it's not a behaviour users expect these days.

Talk app

Talk app version: 23.0.10 (also reproduced in v24.0.4, main)

Custom Signaling server configured: yes, nextcloud-spreed-signaling v2.1.1

Custom TURN server configured: yes

Custom STUN server configured: yes

Browser

Microphone available: yes

Camera available: yes

Operating system: macOS/Windows (not tested on Linux)

Browser name: Chrome/Firefox/Brave

Browser version: Latest

Browser log

POST /ocs/v2.php/apps/spreed/api/v4/call/{token} 404 Not Found

Error while joining call: Error: Request failed with status code 404

Server configuration

Operating system: Linux (k3s cluster)

Web server: Traefik v3.6.12

Database: PostgreSQL

PHP version: 8.3

Nextcloud Version: 33.0.5

List of activated apps:

spreed (Talk 23.0.10)
user_oidc 8.11.0 --> Keycloak
notify_push
and others

Nextcloud configuration:

signaling_servers:
  - server: https://hpb.example.com
    secret: ***

turn_servers:
  - server: turn.example.com
  - server: turns.example.com

stun_servers:
  - stun.example.com

Server log (data/nextcloud.log)

Session expires after 60s inactivity. Room session not found on join attempt.
WebSocket timeout on pongWait=60s. Backend room session removed from state.

Additional Context

Root Cause:
WebSocket times out (pongWait=60s) → signaling session expires (30s resumption window) → backend room session expires → client calls joinCall() → no session exists → 404

Code Location:

• Issue: src/store/participantsStore.js line 779-785 (catch block with no 404 handler)
• Signaling timeout: nextcloud-spreed-signaling/client/client.go:52 (pongWait=60s)
• Session expiry: nextcloud-spreed-signaling/server/hub.go:119 (sessionExpireDuration=30s)

Proposed Fix:
Add automatic retry logic on 404 error (26-line fix in catch block). Wait 500ms, retry join. If succeeds: transparent recovery. If fails: show original error.

Testing:
✅ Unit tests: 4/4 scenarios pass
✅ Browser test: automatic recovery confirmed in console logs
✅ Versions affected: v23.0.10, v24.0.4, main

However, proper testing on NC side is still required.

Related Code Change:
File: src/store/participantsStore.js lines 779-810

} catch (e) {
    if (e?.response?.status === 404 && state.joiningCall[token]) {
        console.info('Room session expired after inactivity, attempting automatic recovery...', { token })
        await new Promise(resolve => setTimeout(resolve, 500))
        try {
            const actualFlags = await joinCall(token, flags, silent, recordingConsent, silentFor)
            const updatedData = { inCall: actualFlags }
            commit('updateParticipant', { token, attendeeId: attendee.attendeeId, updatedData })
            const callViewStore = useCallViewStore()
            callViewStore.handleJoinCall(getters.conversation(token))
            console.info('Automatic recovery succeeded')
            return
        } catch (retryError) {
            e = retryError
        }
    }
    finishConnecting()
    console.error('Error while joining call: ', e)
}

If this is an issue no one else has, I will resume finding the error in our configuration. But many hours of searching were not successful.

Best regards

PS: Nextcloud is a great app :)

[Antreesy]

Thanks for the report! Was recently debugging it as well.

We have three entities in place for bookkeeping the session:

• PHP session - lives on NC server, 24 hours by default (since the log in)
• Talk session - lives as long as you've joined any conversation (shows you as online in there)
• HPB session - lives as long as you've first connected to any room / join conversation (required for chats and calls)

We already have recovery mechanism in place (tested with short-time, needs a longer period):

• OS/network stack notices that connection died (e.g. for laptop sleep/wake or network drops);
• After 60 seconds of no pinging HPB session should close itself and notify server backend to delete Talk session;
• After waking up, client (browser, desktop app) understands that connection was killed/closed;
• Client might fire a real close/error event on the socket (e.g. code 1006);
• Existing onclose handler reconnects, falls back from resume to a fresh hello if the old session is gone, refreshes settings if the token expired, and rejoins the room if rejected (processErrorNoSuchRoom).

So last step should restore everything, and open new websocket - that you would see in Devtools > Network tab.

Please try to gather more data with inactivity, so we can better understand where it's failing. With available hardware+browser/client+server combination, I always hit correct recovery and thus can't reproduce it. But would be happy to!

Wait 2+ minutes, sometimes one day, sometimes over the weekend

What's the machince status? Is it asleep/hibernates? If you can test with short periods (for me 3-5 minutes of sleep on Windows was enough to kiil connections), and then try to join call -> 404, and extract browser console logs + HAR files [Sanitize both to not leak personal information / server credentials and domains], I'd like to see those and try to reproduce the logic

[hubfc]

Update after a day of testing. Short version: we can reproduce it, and we can now say what it is not.

Setup: Talk 23.0.10, Nextcloud 33.0.5, standalone signaling server (aio-talk image), Talk Desktop 2.2.4 on macOS / Apple Silicon.

What the failure actually looks like server-side

The client loops joining and leaving the call every ~16s, indefinitely:

clientsession.go:520  Session X joined room <token>
room.go:899           Session X joined call <token>
janus_videoroom.c     [ERR] No such feed (1)
subscriber.go:248     Publisher X not sending yet for video, wait and retry
hub.go:2990           Could not send MCU message {"type":"requestoffer",...}: context deadline exceeded
clientsession.go:534  Session X left call <token>
                      ~1.2s later: register -> join -> same again

~70 cycles over 19 minutes before we intervened. In the same window the Nextcloud access log shows 27x POST /call/{token} and 27x DELETE /call/{token}, all 200. So the join itself is fine — the outgoing media never starts, and everyone else in the room is stuck waiting for an offer that never comes.

The post-sleep error messages are a red herring

We spent hours chasing these:

Ignore unknown error: {"code":"no_such_session","message":"The session to resume does not exist."}
Could not connect to server using backend url .../signaling/backend
The signaling token is expired, need to update settings
net::ERR_UNEXPECTED   (on plain HTTP requests)

They also show up in runs that recover perfectly — 3 out of 3 short-sleep tests. They are normal post-sleep noise, not a failure indicator. The only reliable signature is Publisher ... not sending yet for video plus the join/leave loop.

Sleep duration matters — short sleep does not reproduce

macOS, lid closed, Talk Desktop left open:

sleep	dark wake cycles	result
3-5 min	-	recovers
10 min	-	recovers
58 min	3	recovers
70 min	5	recovers
~8 h (overnight)	32	fails
110 min idle, no sleep	-	recovers

pmset -g log shows the identical sleep state throughout (DarkWake from Deep Idle [CDNP], tcpkeepalive active) in both the 70-minute test and the overnight run — the machine never entered a deeper hibernation state. So it is not sleep depth. It is either duration or the number of failed reconnect cycles.

That may be why 3-5 minutes on Windows was not enough to reproduce it on your side.

Rejoin does not recover it, reload does

Controlled comparison, two clients in the same conversation, same LAN, same router/NAT, same TURN server, same minute:

• browser, reloaded -> 0x not sending yet in 4 min
• desktop, not reloaded -> 15x not sending yet in 4 min

Reloading the desktop window stopped the loop instantly: all server-side counters (not sending yet, No such feed, context deadline exceeded) went to 0 within 60s, and the client's request rate dropped from 32/min back to 3/min. The 16-second rejoin rebuilds the signaling session but not the renderer underneath, so it can never recover on its own.

Useful health metric: time from Joining call to localMediaStarted is 136 / 140 / 143 ms across all healthy runs, including the ones right after sleep.

Still open

What exactly dies in the client. We will continue narrowing it down. But so far without luck. Hope this helps a little.

[Antreesy]

So the join itself is fine

On a PHP side, as Talk session was recovered

the outgoing media never starts, and everyone else in the room is stuck waiting for an offer that never comes.

Does it by chance show you as alone in the call, with message "Waiting for others to join the call"?

I feel like this could be a symptom of duplicating a session. So people are in the same Talk room, but it's not the same room in HPB:
Session <session> joined room <token> with room session id <room_id>
janus.go:783: Created room <id> {janus.plugin.videoroom map[permanent:false room:<id> videoroom:created]}

Each publisher should have a Janus room, and reconnect might create a new on each time.
With access to logs, could you check if those ids make some meaningful pattern?

[hubfc]

Soo.. 90 min window, ~19 min of active loop.

Room ids: random 15-16 digit numbers, no numeric pattern. But the lifecycle has one — 33 rooms created, 31 destroyed. The two leaked rooms both belong to a publisher flagged as not sending almost immediately after creation:

09:18:57.449  janus.go:783:       Created room 3808134405392560
09:18:57.608  subscriber.go:248:  Publisher <A> not sending yet for video,
                                  wait and retry to join room 3808134405392560

159 ms. That room then survived the whole window and collected 45 subscriber attachments, one per rejoin cycle of the other participant. Second leaked room, identical signature.

Not a room duplication — all sessions were in the same Talk room:

joined room cetnfn7t   30
joined room g7cojtzh    1   (unrelated)

But the session churn looks off:

Register:                 30      (27 of them the same user, looping)
Unregister:                2
Closing expired session:   2
Removed room session:     29

Every one of those 29 cleanups returns:

clientsession.go:601: Removed room session <id>:
  {error:{code:no_such_room, message:"The user is not invited to this room."}}

The user is still invited — they rejoin successfully 1.2 s later.

Separate lead, unconfirmed: getTurnSettings() (lib/Config.php) issues TURN credentials with a 24h TTL and carries FIXME add the TTL to the response and properly reconnect then. Client side, _trigger('turnservers', ...) is never called anywhere in src/, and there is no on('settingsUpdated') listener — so peerConnectionConfig.iceServers is set once at WebRTC setup and never refreshed, although the client does re-fetch /signaling/settings. Fits the symptoms (ICE fails, TURN server healthy, reload fixes it, rejoin doesn't). We cannot prove it caused these incidents — our logs only reach 13h back and the client had loaded no bundles in that window, so we know the session was >13h old but not that it crossed 24h. Two test clients clients were reloaded today at 09:47 and 15:35; we'll report whether they fail ~24h later.

[Antreesy]

no_such_room - I can't confirm that it's related to joining issues. As posted in my first comment, Talk session is gone from DB table, Removed room session is likely trying to remove those based on what client remember from stale HPB sesion.

For TURN - that's a nice catch: webrtc indeed in only instantiated once per app load. Might also be the reason I can't reproduce it (without TURN server in local environment)
cc @danxuliu are you aware whether it was brought up before?

[danxuliu]

For TURN - that's a nice catch: webrtc indeed in only instantiated once per app load. Might also be the reason I can't reproduce it (without TURN server in local environment) cc @danxuliu are you aware whether it was brought up before?

Looks like #6323

[hubfc]

I think we found the root cause, and confirmed by a prediction made before it happened: TURN credentials expire after 24h and the client never refreshes them.

The 24h boundary, measured

One continuous console session, a single reload marker in the entire log. Session started 2026-09-01 09:47.

01-09 11:29 / 13:01 / 13:12 / 14:29 / 15:31   Connection established (own peer)   OK
02-09 09:04:07                                 Connection established (own peer)   OK   (23h17m)
─────────────────────── 09:47 = 24h after session start ───────────────────────
02-09 10:17:43                                 Disconnected (own peer)             FAIL (24h30m)
02-09 10:20:26                                 reload
02-09 10:20:32                                 Connection established (own peer)   OK   (+6s)

The only failure in a 24.5 hour session sits right after the 24h mark.

Side by side:

OK    09:04:07.182 Joining call
      09:04:07.348 localMediaStarted            (166 ms)
      09:04:07.407 Connecting own peer...
      09:04:07.482 Connection established (own peer)

FAIL  10:17:27.963 Joining call
      10:17:28.138 localMediaStarted            (175 ms - normal)
      10:17:28.187 Connecting own peer...
                   (no "Connection established")
      10:17:43.246 Disconnected (own peer)      15s later

localMediaStarted is normal in both, so local media capture is fine. ICE for the own peer never establishes.

Why

lib/Config.php, getTurnSettings():

// Credentials are valid for 24h
// FIXME add the TTL to the response and properly reconnect then
$timestamp = $this->timeFactory->getTime() + 86400;
$username = $timestamp . ':' . $rnd;

Client side, the credentials are written into peerConnectionConfig.iceServers exactly once — Signaling.Base.prototype.on() calls the turnservers handler immediately on registration. After that:

• _trigger('turnservers', ...) is never called anywhere in src/
• there is no on('settingsUpdated') listener anywhere in src/

So the config is frozen at WebRTC setup time. The client does re-fetch /signaling/settings (8x in 14h in our access log), but the fresh credentials never reach the peer connection. Only a page reload rebuilds the stack.

Consistent with this: we never saw the problem on setups without the HPB, where no TURN server is configured and therefore no credentials can expire.

Cascade after the ICE failure

10:17:43.407  Rejoining conversation with new session
10:17:44.744  The signaling token is expired, need to update settings
10:17:44.810  GET /signaling/settings  FAILED
10:17:44.810  Received updated settings null          <- null is stored
10:17:45.372  Deferring establishing signaling connection until settings are updated
10:18:10.135  Error while leaving call: TypeError: Cannot read properties of null (reading 'destroy')
10:18:38.605  InvalidAccessError: Failed to execute 'addTrack': A sender already exists...
10:18:38.611  Not joined room yet, not joining call

On another client the same starting point produced an endless leave/rejoin loop, ~16s per cycle, ~70 cycles over 19 minutes. It comes from the negotiationneeded handler (webrtc.js:910), whose guard excludes only 'new' and 'checking' — not 'failed' — so a permanently failed ICE state keeps calling forceReconnect(true), which does leaveCall() + rejoinConversation() with a fresh session. Server side, all POST/DELETE /call/{token} return 200 throughout.

What do you think about it?

[Antreesy]

Sounds legit. I linked the original issue, and will look into patching this. Thanks for the thorough investigation!

UPD: testing different patches, need to validate the logic still