RTMS Interrupts And Disconnects (stop_reason: 19)

Realtime Media Streams
1

Summary:

We are testing RTMS to join Zoom meetings, and from time to time (after 10-15min into the meeting) we are getting disconnects from Zoom. Tese are meeting.rtms_interrupted where our client will successfully reconnect, but after the reconnect we are getting meeting.rtms_stopped with stop_reason: 19

Details:
We did successfully receive a meeting.rtms_interrupted event in this session and reconnected correctly. However, shortly after reconnecting, we received meeting.rtms_stopped with stop_reason: 19. The meeting was still active at this point (it had not ended), so we expected at minimum a documented stop reason explaining why the stream was permanently terminated.

Questions

  • What does stop_reason: 19 indicate?
  • What specific platform condition triggers it?
  • Is there a recommended way to recover from this condition?
  • Should our application automatically attempt to reconnect the RTMS session, and if so, what is the recommended reconnection flow?

Here the logs fro two examples:

Example 1 (this was on our Staging env):
Full Event Timeline
[14:30:03 UTC] meeting.started
meeting_uuid: ZruXO4ZMS1OaTsvay2Af5A==
host: avaquero@xxx

[~14:30–14:44] Multiple meeting.participant_joined events received

[14:44:43 UTC] meeting.rtms_started
rtms_stream_id: 556c676c68ea49a3bb9e601aa9b2612c
server: wss://zoomsjc144-195-19-85zssgw.sjc.zoom.us:443

[~14:44–14:49] RTMS streaming running normally
Additional participant events received

[14:49:30 UTC] meeting.rtms_interrupted ← transient disruption
Same rtms_stream_id and server_urls

[~14:49] Reconnected successfully, streaming resumed

[14:53:17 UTC] meeting.rtms_stopped ← unexpected terminal stop
stop_reason: 19 (undocumented)
Meeting was still active at this time

Events:
{“event”:“meeting.started”,“payload”:{“account_id”:“p27RYjvyRdORRB7dhHn6oQ”,“object”:{“duration”:60,“start_time”:“2026-07-08T14:30:03Z”,“timezone”:“America/New_York”,“topic”:“Google Calendar Meeting (not synced)”,“id”:“99984599214”,“type”:2,“uuid”:“ZruXO4ZMS1OaTsvay2Af5A==”,“host_id”:“UVucMlfuSq2vHTCn1teMww”,“host_email”:"avaquero@pindrop.com"}},“event_ts”:1783521003528}

Multiple meeting.participant_joined events received:
{“event”:“meeting.rtms_started”,“event_ts”:1783521883942,“payload”:{“account_id”:“p27RYjvyRdORRB7dhHn6oQ”,“is_original_host”:true,“meeting_id”:99984599214,“meeting_uuid”:“ZruXO4ZMS1OaTsvay2Af5A==”,“operator_id”:“UVucMlfuSq2vHTCn1teMww”,“rtms_stream_id”:“556c676c68ea49a3bb9e601aa9b2612c”,“server_urls”:“wss://zoomsjc144-195-19-85zssgw.sjc.zoom.us:443”}}

RTMS streaming running normally:
{“event”:“meeting.rtms_interrupted”,“event_ts”:1783522970497,“payload”:{“meeting_uuid”:“ZruXO4ZMS1OaTsvay2Af5A==”,“rtms_stream_id”:“556c676c68ea49a3bb9e601aa9b2612c”,“server_urls”:“wss://zoomsjc144-195-19-85zssgw.sjc.zoom.us:443”}}

Reconnected successfully, streaming resumed

{“event”:“meeting.rtms_stopped”,“payload”:{“meeting_uuid”:“ZruXO4ZMS1OaTsvay2Af5A==”,“rtms_stream_id”:“556c676c68ea49a3bb9e601aa9b2612c”,“stop_reason”:19},“event_ts”:1783523197399}

Example 2 (this in our Production env):
{
“event”: “meeting.rtms_stopped”,
“event_ts”: 1783521392132,
“payload”: {
“meeting_uuid”: “ZruXO4ZMS1OaTsvay2Af5A==”,
“rtms_stream_id”: “abd6c6f432c04cc8b6a63ec6c88a5d9d”,
“stop_reason”: 19
}
}

2

stop_reason: 19 maps to STOP_BC_AWAIT_RECONNECTION_TIMEOUT. Zoom ended the stream because it was still waiting for reconnection when the allowed window expired, as defined in the RTMS stop-reason enum. Zoom allows approximately 60 seconds to restore a dropped signaling connection.

On meeting.rtms_interrupted, close both signaling and media sockets, then rebuild the complete connection using the webhook’s current server_urls and exponential backoff, following Zoom’s failover and reconnection flow. A WebSocket reopening isn’t enough. Confirm the new signaling handshake succeeds, reconnect media using the returned media URLs, complete each media handshake, and resume keep-alives. Your timeline suggests Zoom did not recognize the reconnection as fully completed.

Treat meeting.rtms_stopped as terminal for that rtms_stream_id. Don’t reconnect the stopped stream. If the meeting remains active and your app has the required scope and participant eligibility, send a fresh RTMS start request and wait for a new meeting.rtms_started event.

Recall.ai is a Zoom RTMS Preferred Partner, and you can get further RTMS implementation support through us.