# Reclaim\_session\_timeout issue

**URL:** <https://janus.discourse.group/t/reclaim-session-timeout-issue/1788>\
**Category:** General\
**Created:** [May 9, 2026, 9:20pm UTC](https://janus.discourse.group/t/reclaim-session-timeout-issue/1788 "2026-05-09T21:20:57Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![oleksandr.mihal](https://avatars.discourse-cdn.com/v4/letter/o/e79b87/32.png) [@oleksandr.mihal](https://janus.discourse.group/u/oleksandr.mihal)\
**Post date:** [May 9, 2026, 9:20pm UTC](https://janus.discourse.group/t/reclaim-session-timeout-issue/1788/1 "2026-05-09T21:20:57Z")

</div>

Hi everyone,

Per doc, **reclaim\_session\_timeout** is ‘how long (in seconds) we should wait for a  
janus session to be reclaimed after the transport is gone’.

In real, this timeout is counted from session last activity (like session\_timeout).

janus.c

```auto
if((timeout > 0 && (now - session->last_activity >= timeout * G_USEC_PER_SEC)) || ((g_atomic_int_get(&session->transport_gone) && now - session->last_activity >= (gint64)reclaim_session_timeout * G_USEC_PER_SEC))) {...}

```

In some configurations, this leads to a premature session closure.

Example:  
Proxy - nginx, transport - websocket.  
session\_timeout = 90;  
reclaim\_session\_timeout = 30;

Nginx closes websocket connection 60s after session last activity (default behavior).  
Session\_timeout (90) not reached yet.  
Janus immediately closes session because (now - last\_activity) \> reclaim\_session\_timeout (30).  
Remote device is trying to restore the connection but can’t reclaim session.  
As result, the call is terminated.

---

<div class="post-metadata">

**Author:** ![lorenzo](https://yyz2.discourse-cdn.com/free1/user_avatar/janus.discourse.group/lorenzo/32/425_2.png) [@lorenzo](https://janus.discourse.group/u/lorenzo)\
**Post date:** [May 11, 2026, 8:23am UTC](https://janus.discourse.group/t/reclaim-session-timeout-issue/1788/2 "2026-05-11T08:23:21Z")

</div>

> [@oleksandr.mihal](#):
>
> Session\_timeout (90) not reached yet.

The session timeout is not considered anymore once the session is gone. If reclaim timeout isn’t configured, for instance, a WebSocket connection going down will close all sessions immediately, independently of whether or not a session timeout was reached, as we know that user is no longer there. So the 90 is irrelevant in this example. But I do get your point on last activity being incorrect as a starting point for reclaims, as in that case the “transport gone time” should be the starting point instead. I’ll see if this can be fixed easily or not.

---

<div class="post-metadata">

**Author:** ![oleksandr.mihal](https://avatars.discourse-cdn.com/v4/letter/o/e79b87/32.png) [@oleksandr.mihal](https://janus.discourse.group/u/oleksandr.mihal)\
**Post date:** [May 11, 2026, 8:41am UTC](https://janus.discourse.group/t/reclaim-session-timeout-issue/1788/3 "2026-05-11T08:41:19Z")

</div>

Thank you for your quick response.

---

<div class="post-metadata">

**Author:** ![lorenzo](https://yyz2.discourse-cdn.com/free1/user_avatar/janus.discourse.group/lorenzo/32/425_2.png) [@lorenzo](https://janus.discourse.group/u/lorenzo)\
**Post date:** [May 12, 2026, 7:44am UTC](https://janus.discourse.group/t/reclaim-session-timeout-issue/1788/4 "2026-05-12T07:44:56Z")

</div>

@oleksandr.mihal I just created a PR that should address the issue. I haven’t tested it yet, though. Please make a few tests and let me know if it is indeed fixing the issue for you. For any feedback please add textto the PR and not here, so that we can track the progression on Github.

> <https://github.com/meetecho/janus-gateway/pull/3643>
>
> This PR is an attempt to address the issue reported on the \[group\](https://janus….discourse.group/t/reclaim-session-timeout-issue/1788), about a broken behaviour of our reclaim session functionality. As per the documentation, if a reclaim session timeout is configured, when a transport goes away you have X seconds to try and restore it from a different transport: the code was using the last activity as a start for the timeout, though, which was incorrect, since the last activity may precede the time we detect a transport to be gone, in some cases preventing any chance to reclaim due to early cleanups. This PR introduces a new timer that we track when the transport actually is detected as gone, and that we use in the related check.
> 
> Not tested yet, so please provide feedback on whether this works correctly and/or if it causes regressions.