RTMS starts then immediately stops with stop_reason 18 in developer account, but does not start at all in external free account

Realtime Media Streams
1

Hi Zoom team,

We are currently in a beta testing phase with our Zoom Production app and have received approval to share the authorization URL with external users. As part of this phase, we are testing integration of Real-Time Media Streams (RTMS). However, we are observing inconsistent RTMS behavior across different accounts and would appreciate clarification on the expected behavior and requirements.

Case 1 – Production App Installed in Developer Account

When the Production app is installed in the same Zoom account as the developer:

  1. meeting.rtms_started is received.

  2. We call client.join(payload) using the exact payload.

  3. onJoinConfirm fires successfully.

  4. Within ~1 second, we receive:

    • meeting.rtms_stopped

    • stop_reason: 18 (0x12)

Example log flow:

RTMS joined successfully (reason 960 / 0x3c0)
RTMS STOPPED webhook received (stop_reason: 18)

The RTMS session ends automatically.

Questions:

  • What specifically does stop_reason: 18 indicate?

  • Does it represent authentication failure between RTMS and the app credentials?

  • Could having both Development and Production versions of the app installed in the same account cause RTMS conflicts?

Case 2 – Production App Installed in External Free Account

When installing the same Production app in a separate external free account:

  • meeting.rtms_started is never received.

  • RTMS does not start.

Questions:

  • Are there plan-level requirements (e.g., Pro vs Free) for RTMS?

  • Does RTMS require specific admin-level account settings to be enabled?

  • Are there beta or entitlement limitations that would prevent RTMS from starting in certain accounts?

Additional Notes

  • We are not modifying the STARTED payload before calling client.join.

  • server_urls are present in the STARTED payload.

  • No network or TLS errors on our backend.

  • Webhooks are consistently received and verified.

We are trying to determine whether this is:

  • An authentication mismatch issue

  • An account-level entitlement/plan issue

  • A Development vs Production app interaction issue

  • Or something specific to RTMS during beta testing

Any guidance would be appreciated.

Thank you.

2

First, make sure both accounts are on a Pro (or higher) plan and that RTMS is enabled at the account and user level in Zoom settings. Then uninstall any duplicate Development/Production app versions, reinstall only the Production app, and create a fresh test meeting. If it still stops with reason 18, it’s most likely an entitlement or account-level restriction that Zoom needs to confirm.

3

@Thodoris let me try to replicate this issue, are you using the SDK?

4

Hi, yes — we are using the RTMS SDK (Node.js) on our backend.

Flow:

  1. We receive meeting.rtms_started

  2. We pass the payload directly into client.join(payload)

  3. onJoinConfirm fires successfully

  4. Within ~1 second we receive meeting.rtms_stopped with stop_reason: 18

This occurs when:

  • The Production app is installed in the developer (app owner) account.

In a separate external free account:

  • meeting.rtms_started is never triggered.

We are using the Production app credentials (RTMS client + secret) in our deployment.

Please let us know if you need:

  • SDK version

  • Full STARTED payload (sanitized)

  • Account type details

  • Confirmation whether both Development and Production versions being present in the same owner account could cause RTMS auth conflicts

Thank you.

5

Thank you for the guidance.

One clarification: we cannot remove the Development version from the developer account because it appears under Created Apps, and as the app owner it is not removable from that account. Only the Production version can be installed/uninstalled.

Also, regarding the external free account where meeting.rtms_started is never triggered — does this imply that RTMS only works on Pro (or higher) accounts?
Is RTMS unavailable or restricted on free plans?

6

@Thodoris are you using multiple server instances like docker containers?

7

Yes, we are deploying using Docker containers.

However, for this test scenario there is only one active backend instance handling RTMS joins. We are not running multiple replicas behind a load balancer for this environment.

8

From what I see on the backend, there are 4 concurrent instances trying to do the same thing at the same time @Thodoris