/v3/webrtcsessions/list shows stale sessions for ~20 seconds after stream ends

[rpv88]

Question

When a WebRTC stream ends, I noticed that the /v3/webrtcsessions/list API continues to return the session for approximately 20 seconds before it disappears.

Is this delay intentional?
Is there a timeout or cleanup interval that controls this?
Could there be a way to mark the session as "closed" or "inactive" during this window?
Or alternatively, could this timeout be documented or configurable?

Ideally, I would like to trigger actions (e.g., cleanup or UI updates) immediately after a session ends, but this delay makes that tricky. Just wondering what the intended behavior is and if there’s a recommended way to handle this.

Thanks in advance!

[rpv88]

Additionally, I’ve observed that pressing Ctrl + R on the current tab during an active stream causes the WebRTC negotiation to close and the stream to stop immediately. In this case, the /v3/webrtcsessions/list endpoint immediately stops showing the session. In contrast, when closing the tab or clicking the browser’s X button, the endpoint continues to list the session as active for approximately 20 seconds before it's cleaned up.

[aler9]

Hello, in browsers, when a tab that contains a WebRTC sessions is closed, no message is sent to the server, which has timeouts as the only mean to detect terminated sessions, and that is why there's a 20 second delay.

However, i investigated and i found out that if WebRTC sessions are closed just before a tab is closed, they send a QUIT message to the server and can be detected as terminated. This is implemented in #4849, so the delay should be gone in most cases.