RTMS behavior differences between App Auto-Start vs manually starting RTMS via API

Realtime Media Streams
,
1

Issue: Manually starting RTMS only works when the Host is the first to join (an instance of) the Meeting. If a Participant (non-Host) joins the meeting first, RTMS doesn’t start.

Details:

  • We have a User Manged General App (RTMS app) set up to send Meeting and RTMS events to a webhook.
  • The webhook consumer can be configured to either manually start RTMS events or to wait for RTMS events.
  • RTMS is manually started through a Server-to-Server App (StoS app) that requests an Access Token and uses it to start RTMS (for the RTMS app) via API call.
  • The StoS app has no Events, and has the following Scopes:
    meeting:read:meeting:admin
    meeting:update:participant_rtms_app_status:admin
    Note: I couldn’t find the non-admin versions of these scopes

Auto-Start RTMS Test:

  • We add the Zoom User to the RTMS app.
  • We add the RTMS app to the Zoom Users auto-start list (Settings >> Zoom Apps >> Meetings >> Auto-start apps that access shared realtime meeting content).
  • We configure our webhook consumer to wait for RTMS events.
  • We schedule a meeting with the Zoom User as Host.
  • When anyone (Host or non-Zoom User) joins the meeting, our webhook consumer receives a meeting.started event, followed by a meeting.rtms_started event, and all is good.

Manual RTMS Test:

  • We add the Zoom User to the RTMS app.
  • We configure our webhook consumer to manually start RTMS.
  • We schedule a meeting with the Zoom User as Host.
  • When anyone joins the meeting, our webhook consumer receives a meeting.started event.
  • Our webhook consumer requests an Access Token, through the StoS app (Basic Authentication Header). POST https://zoom.us/oauth/token?grant_type=account_credentials&account_id=\*\*\*\*\*\*
  • Our webhook consumer uses the Bearer token to call the Zoom API v2 (action = “start” body…) PATCH https://api.zoom.us/v2/live_meetings/"+ meetingid + "/rtms_app/status
  • If the Host joins the meeting first, the webhook consumer recieves the meeting.rtms_started event.
  • If a Participant (!= Host, != Zoom User) joins first, RTMS doesn’t start.

Everything is working when we use auto-start, but I suspect that there may be a fix for our manual RTMS start issue.

I’d appreciate any thoughts you might be able to offer.

2

Follow-up:

The body of the API call to start RTMS is: var body = new { action = “start”, settings = new { participant_user_id = [payload.object.host_id from meeting.started Event], client_id = [RTMS app Client ID] } };

When making the call to manually start RTMS, the host_id value is the same (in meeting.started Event), regardless of who joins first, the Host or a Participant.

The API call successfully starts RTMS, when the Host joins first.

The API call silently fails to start RTMS, when a Participant joins first.

The token has this scope: “scope”:“meeting:read:meeting:admin meeting:update:participant_rtms_app_status:admin”

I’m noting that the token content lists “api_url”:“https://api-us.zoom.us”.

Should I be using that instead of https://api.zoom.us/v2/?

3

Hi @Bill3, This is usually a timing/consent issue: Zoom notes that “If there’s no one in the meeting to approve the app, the RTMS session cannot start”, so if your webhook fires and you call start before the host (or an authorized approver) is actually in the meeting, the request won’t result in meeting.rtms_started.

A practical fix is to delay or retry the PATCH until you see the host join (and treat early joins as “not ready”), using signals like the meeting.participant_jbh_waiting event (“Joined Before Host”) or meeting.participant_joined, and log the PATCH HTTP status/body so you can catch non-2xx responses you might be ignoring.

On the base URL changing it shouldn’t affect the host-first vs participant-first behavior.