Skip to content

Out-of-order AdmissionWebhook events on OBS reconnect #1909

@hernanrz

Description

@hernanrz

Describe the bug
When a publisher (e.g. OBS) reconnects (such as after a network interruption), OvenMediaEngine sends AdmissionWebhook events out of order. Specifically, a "closing" webhook for the old connection is sent after a new "opening" webhook for the reconnected session. This causes our application to incorrectly mark the stream as offline, as we rely on the received webhooks to update a stream's status in our database, even though OBS and OME show the stream as live.

To Reproduce
Steps to reproduce the behavior:

  1. Configure OME with admissionwebhooks
  2. Use OBS (31.1.2) to publish a stream to OME.
  3. While streaming, disconnect the network (e.g., turn off WiFi). Wait for OBS to show "reconnecting", then restore the network.
  4. Observe the order of webhook events received by the control server.

Expected behavior
Webhook events should be sent in the correct order: each "opening" event should be followed by a corresponding "closing" event for the same connection. After a successful reconnect, the last webhook sent by OME should be a "status":"opening" webhook, but instead, the final webhook received after successful reconnection, is a "status":"closing" webhook

Logs

These are the logs produced by the webhook server, observe the final webhook is status:closing, at that point, OBS has successfully reconnected

Admission webhook server listening on :8080 (POST /admission)
2025-08-28T17:15:20Z - ⬇️ Starting stream
[AdmissionWebhook] Payload received:
{"client":{"address":"my ip","port":61014,"real_ip":"my ip"},"request":{"direction":"incoming","protocol":"RTMP","status":"opening","time":"2025-08-28T17:15:20.443+00:00","url":"rtmp://server:1935/live/1"}}

[ OBS STARTS ATTEMPTING RECONNECTION]

2025-08-28T17:16:20Z - ⬇️ Starting stream
[AdmissionWebhook] Payload received:
{"client":{"address":"my ip","port":61008,"real_ip":"my ip"},"request":{"direction":"incoming","protocol":"RTMP","status":"opening","time":"2025-08-28T17:16:20.824+00:00","url":"rtmp://server:1935/live/1"}}
2025-08-28T17:16:22Z - ⬆️ Closing stream
[AdmissionWebhook] Payload received:
{"client":{"address":"my ip","port":61008,"real_ip":"my ip"},"request":{"direction":"incoming","new_url":"rtmp://server:1935/live/1","protocol":"RTMP","status":"closing","time":"2025-08-28T17:16:22.642+00:00","url":"rtmp://server:1935/live/1"}}
2025-08-28T17:16:25Z - ⬇️ Starting stream
[AdmissionWebhook] Payload received:
{"client":{"address":"my ip","port":61008,"real_ip":"my ip"},"request":{"direction":"incoming","protocol":"RTMP","status":"opening","time":"2025-08-28T17:16:25.369+00:00","url":"rtmp://server:1935/live/1"}}
2025-08-28T17:16:27Z - ⬆️ Closing stream
[AdmissionWebhook] Payload received:
{"client":{"address":"my ip","port":61008,"real_ip":"my ip"},"request":{"direction":"incoming","new_url":"rtmp://server:1935/live/1","protocol":"RTMP","status":"closing","time":"2025-08-28T17:16:27.210+00:00","url":"rtmp://server:1935/live/1"}}
2025-08-28T17:16:30Z - ⬇️ Starting stream
[AdmissionWebhook] Payload received:
{"client":{"address":"my ip","port":61037,"real_ip":"my ip"},"request":{"direction":"incoming","protocol":"RTMP","status":"opening","time":"2025-08-28T17:16:30.189+00:00","url":"rtmp://server:1935/live/1"}}

[AT THIS POINT OBS SHOWS THE RECONNECT WAS SUCCESFUL]

2025-08-28T17:16:30Z - ⬆️ Closing stream
[AdmissionWebhook] Payload received:
{"client":{"address":"my ip","port":61014,"real_ip":"my ip"},"request":{"direction":"incoming","new_url":"rtmp://server:1935/live/1","protocol":"RTMP","status":"closing","time":"2025-08-28T17:16:30.288+00:00","url":"rtmp://server:1935/live/1"}}

Server (please complete the following information):

  • OME: latest docker image

Additional context
This bug causes our website to incorrectly mark streams as offline when they are actually live, due to the out-of-order webhook events. This can be reproduced reliably by interrupting and restoring the network connection during an active RTMP publish session.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions