I’m hitting the exact same issue: “Your App failed to Access meeting content”/“Connection failed” shown in the client’s “Apps that access meeting content” panel — even after fully following the reference implementation.
Setup:
General App, RTMS enabled, Developer Pack active
Scopes: meeting:read:meeting_video (confirmed working, see below); tried adding audio/transcript scopes too
Account ID: 7066479118
App ID: LXgJ4mUjSqKMS9sqboM00Q
Yes, using the sample code (zoom/rtms-samples, boilerplate/working_dotnetcore) as the reference for the signaling/media handshake implementation.
What’s actually happening, step by step:
meeting.rtms_started webhook received correctly, signature validates.
Media handshake (DATA_HAND_SHAKE_REQ → DATA_HAND_SHAKE_RESP), requesting media_type: 2 (Video only, matching this app’s actually-authorized scope): succeeds, status_code: 0.
Client sends msg_type: 7 (ready-to-receive) with rtms_stream_id, per the sample.
Zero MEDIA_DATA_VIDEO frames ever arrive. No errors, no further messages of any kind.
Connection times out after ~60 seconds: meeting.rtms_stopped, stop_reason: 11 (“connection timed out”).
Zoom’s own client simultaneously shows “Connection failed” in the “Apps that access meeting content” panel (screenshot attached).
Also tried, for completeness: requesting media_type: 11 (Audio | Video | Transcript, matching the sample’s default) — this gets an explicit hard rejection instead, status_code: 14 (“Media type invalid value”), which at least confirms the server does validate media_type against granted scopes rather than silently ignoring unauthorized bits. That makes the silent Video-only failure (a scope we do have) more puzzling, not less.
No host-approval popup ever appears during the session. This is fully reproducible, every single attempt, exact same behavior.
@Yek_Khai I’ll push a code update for this, thanks for highlighting.
In the latest version of RTMS, we split the media connection for each media. Audio, Video,Chat, Transcript and Sharescreen each have their own media socket connection.
In the “unified” model, where all media shares the same websocket connection, you can either have a combination of 2, or use 32 where it will subscribe to all media. It doesn’t work if you have a combination of 3 such as 1 + 2 + 8 ( audio video transcript ).
Thanks for the clarification! Tried both suggestions, neither resolves it:
media_type: 32 (All): handshake succeeds (status_code: 0), and interestingly the response now echoes back both audio and video media_params even though I only sent a video block — but still zero media frames of any kind, same stop_reason: 11 timeout at ~60s.
media_type: 3 (Audio | Video) : retested this cleanly per your “combination of 2” note, but it’s rejected identically to before: status_code: 14, “Media type invalid value”. This is the same result whether I’m requesting it alongside Transcript or alone, so it doesn’t look like a Transcript-specific problem.
For reference, the account’s “Apps that access meeting content” panel does list this app as having access to both Audio and Video: so if status_code: 14 for Audio | Video really is an authorization issue rather than a “combination of 3” issue, that’d be worth knowing, since it contradicts what that panel shows.
Current state across everything I’ve tried:
media_type: 2 (Video alone) → handshake OK, zero frames, timeout
media_type: 3 (Audio | Video) → hard rejected, status_code 14
media_type: 11 (Audio | Video | Transcript) → hard rejected, status_code 14
media_type: 32 (All) → handshake OK, zero frames, timeout
Every path that gets past the handshake ends the same way: no data, stop_reason: 11. Would it help to have you look at the raw session/rtms_stream_id from one of these attempts on your end? Happy to provide the exact IDs and timestamps.
