We're updating the issue view to help you get more done. 

Allow clients to influence their max unresponsiveness / timeout


TCP sessions can recover even after a long timeout. See https://mail.jabber.org/pipermail/standards/2020-November/037849.html

For these sessions, it can be desirable to be able to continue where they left off, rather than depending on Stream Management to resume a session, or worse, having to restart a completely new session.

The trade-off of extending time-outs (allowing sessions to recover 'late') is that other sessions appear lively for a long(er) time than desired. The impact of this can be partially mitigated by , but this requires client-sided support.

Being able to resume a session after a long timeout is likely to be applicable to a specific type of clients, or in an a particular context - something that the client that is affected is probably aware of: mobile clients, moving through an area with poor coverage, is likely to benefit more from this than clients installed on a desktop computer, operating under optimal network conditions.

Openfire should allow clients to somehow affect their time-out value. The mechanism here can be up for debate/configuration. A likely candidate here is service discovery (XEP-0030) or entity capabilities (XEP-0115).

  • Openfire could, for example:be configured to allow for longer timeouts for clients that identify themselves as being a handheld or phone client (see https://xmpp.org/registrar/disco-categories.html#client).

  • Another option would be to look for a certain client feature (eg: <feature var="ignite:openfire:long-tcp-recovery">.

  • The absence of Stream Management might be taken into account, to allow clients that do not support SM to benefit.



Acceptance Test - Entry



Guus der Kinderen


Guus der Kinderen



Expected Effort


Ignite Forum URL