Native Live Stream STOP omits Jibri session_id in jitsi-meet-web 1.0.9365-1 and UI remains stuck on Stop Live Stream

What happened?

The native Jitsi Live Stream feature successfully starts a Jibri livestream, but initially fails to stop it correctly.

When the moderator clicks "Start Live Stream", Jibri starts successfully and the RTMP stream is delivered to MediaMTX. The Jitsi UI changes to "Stop Live Stream".

When "Stop Live Stream" is clicked, the browser initially sends a Jibri STOP request without the active Jibri session_id. Jicofo therefore rejects the request with "Unknown session".

Jicofo log:

BaseJibri.handleJibriRequest: Accepted ... action='stop' recording_mode='stream' BaseJibri.doHandleIQRequest: Rejecting STOP request for an unknown session.

The active Jibri session had previously been announced by Jicofo with a session ID.

After adding the active session_id to the STOP IQ in lib-jitsi-meet, Jicofo accepted the STOP request and Jibri stopped successfully.

However, a second issue remained: after Jicofo reported status='off', the browser-side Jibri session continued to report its local status as "on". As a result, the UI remained on "Stop Live Stream" and could attempt to send another STOP request for an already-terminated session.

We traced this to RecordingManager._handleFocusPresence() and JibriSession.getStatus() in the installed lib-jitsi-meet code.

Adding an explicit local status change when Jicofo reports status='off' corrected the UI state.

With both changes applied, the native workflow now works correctly:

Start Live Stream → Jibri starts → RTMP stream is delivered successfully → UI changes to Stop Live Stream → Stop Live Stream → Jibri stops → Jicofo reports status='off' → UI correctly returns to Start Live Stream

This was tested successfully end-to-end on a self-hosted Jitsi installation.

Platform

• Chrome (or Chromium based)
• Firefox
• Safari
• Other desktop browser
• Android browser
• iOS browser
• Electron app
• Android mobile app
• iOS mobile app
• Custom app using a mobile SDK

Browser / app / sdk version

Firefox 155.0 (64-bit)

Relevant log output

Initial STOP failure:

BaseJibri.handleJibriRequest: Accepted ... action='stop' recording_mode='stream'
BaseJibri.doHandleIQRequest: Rejecting STOP request for an unknown session.

The active Jibri session had previously been reported by Jicofo:

JibriRecorder.publishJibriRecordingStatus:
status='on' session_id='b8b90b35-c163-4ea0-9f4e-58fd6ae2a175'

After the client-side correction:

BaseJibri.handleJibriRequest:
Accepted ... action='stop' recording_mode='stream' session_id='b8b90b35-c163-4ea0-9f4e-58fd6ae2a175'

JibriSession.stop:
Sending stop IQ (fire-and-forget) ... session_id='b8b90b35-c163-4ea0-9f4e-58fd6ae2a175'

JibriRecorder.publishJibriRecordingStatus:
status='off' session_id='b8b90b35-c163-4ea0-9f4e-58fd6ae2a175'

Reproducibility

• The problem is reproducible on meet.jit.si

More details?

Self-hosted installation.

Jitsi components:

Ubuntu Server: 24.04.3 jitsi-meet-web: 1.0.9365-1 Jicofo: 1.0-1189 Jitsi Videobridge: 2.3-307-g4bb0aead1-1 Jibri: operational and connected to the Jibri brewery

The RTMP destination is a locally hosted MediaMTX server. The livestream itself is not the problem: Jibri successfully captures the Jitsi conference and MediaMTX receives H.264 video and MPEG-4/AAC audio.

The problem is specifically the browser-side STOP handling.

The installed /usr/share/jitsi-meet/libs/lib-jitsi-meet.min.js was inspected and the JibriSession/RecordingManager implementation was traced to identify the problem.

Interestingly, the Jitsi web release changelog contains fixes related to missing Jibri session IDs during recording STOP handling, including:

"fix(recording): On missing session id, send stop."

The installed package is 1.0.9365-1, which is newer than the version associated with that changelog entry, yet the missing-session-ID behavior was still present in the installed minified library.

A second issue was identified in the handling of the Jicofo status='off' presence notification, where the local Jibri session status could remain "on".

Both issues were corrected with small client-side changes to lib-jitsi-meet.min.js, and the native Jitsi Start Live Stream / Stop Live Stream workflow then worked correctly.

This may indicate a packaging/build discrepancy, regression, or mismatch between the published source and the generated lib-jitsi-meet.min.js included in the Debian package.