# RTMS video under Focus Mode: supported behavior and required support plan? **URL:** \ **Category:** Realtime Media Streams\ **Created:** [October 15, 2026, 2:19pm UTC](https://devforum.zoom.us/t/rtms-video-under-focus-mode-supported-behavior-and-required-support-plan/147187 "2026-10-15T14:19:15Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![FPC](https://avatars.discourse-cdn.com/v4/letter/f/f17d59/32.png) [@FPC](https://devforum.zoom.us/u/FPC)\ **Post date:** [October 15, 2026, 2:19pm UTC](https://devforum.zoom.us/t/rtms-video-under-focus-mode-supported-behavior-and-required-support-plan/147187/1 "2026-10-15T14:19:15Z")
In our controlled RTMS test, host video packets continued under Focus Mode, but packets from a camera-on ordinary attendee did not arrive. In the same connection, switching Focus Mode OFF restored attendee packets; switching it ON stopped them again. We checked packet source IDs, not decoded images, and have not yet completed a role-controlled comparison. Is this intended behavior? If ordinary-attendee video is supported, what host identity, scopes and settings are required? Is there an approved private-app route with the required consent and disclosures? Standard support referred us to this forum. Which Developer Support Plan covers investigation of this specific question? Is Silver sufficient for a live engineer consultation, what are the current price and minimum term, and is a one-off consultation available? We understand that buying support does not itself grant additional media permissions. ---
**Author:** ![chunsiong.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/chunsiong.zoom/32/35488_2.png) [@chunsiong.zoom](https://devforum.zoom.us/u/chunsiong.zoom)\ **Post date:** [October 21, 2026, 5:40am UTC](https://devforum.zoom.us/t/rtms-video-under-focus-mode-supported-behavior-and-required-support-plan/147187/2 "2026-10-21T05:40:33Z")
@FPC let me check and get back to you on this ---
**Author:** ![codenaut](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/codenaut/32/77441_2.png) [@codenaut](https://devforum.zoom.us/u/codenaut)\ **Post date:** [October 21, 2026, 12:19pm UTC](https://devforum.zoom.us/t/rtms-video-under-focus-mode-supported-behavior-and-required-support-plan/147187/3 "2026-10-21T12:19:12Z")
We are seeing a related pattern in a separate video-only RTMS application. Here are our additional observations and questions. We are investigating sparse individual-participant RTMS video delivery while Focus Mode must remain ON. Environment and roles - `@zoom/rtms` 1.1.0, macOS arm64, video-only. - Video parameters: contentType=3 (RAW\_VIDEO), codec=5 (JPG), resolution=1 (SD), dataOpt=4 (individual video), fps=2. - Only the video media callback is registered. - The app’s RTMS update is approved. The original Pro host account authenticated the start request. - The Zoom participant using our Telegram Mini App is also a host or co-host, confirmed from the actual participant row. - One individual video subscription is selected at a time. Only one native RTMS video client is active. Observations from 21 October 2026 - RTMS start returned HTTP 204; native SDK join succeeded. - Initial participant and camera ON/OFF events were received. - Successful video subscription acknowledgements were observed. - In the second round, 50 camera-ON participants were fixed as targets at the start. - Across that round, the SDK delivered 5 video callbacks and 3 fresh valid frames. Stale and invalid frame rejection counters were both 0. - One participant received a successful local face-existence result. We confirmed that this participant was a host or co-host. The callback counts are round aggregates; we do not claim that all 5 callbacks were attributed to that participant. - There were 39 recorded per-target latest-frame timeouts. Total acknowledgement count was 83, including subscribe and unsubscribe responses, so it must not be interpreted as 83 distinct successful targets. - The existing 15-minute reservation limit ended the connection before every target completed: completed-target counter 47/50; final outcomes were 1 face detected, 48 unknown, and 1 camera OFF. Unknown includes unfinished or otherwise inconclusive targets, not confirmed absence of a face or 48 proven subscription failures. - No installed SDK configuration-warning message was observed by a bounded observer. This does not independently prove that every native configuration step succeeded. - Callback counters are incremented before our local participant-ID and freshness filters. Zero-callback intervals cannot be explained by those later filters. The native wrapper may itself omit empty buffers or null metadata. - Zoom sharing was stopped afterward (HTTP 204); local video session and worker counts were verified as zero. Questions 1. Does Focus Mode affect individual RTMS video delivery according to the source participant’s role, the RTMS initiator’s role, or both? 2. Can subscribeVideo return a successful acknowledgement while no video frames are delivered because of Focus or meeting visibility rules? 3. Does RTMS inherit the host/co-host participant’s client-side video visibility? Is there a documented video-only configuration for receiving consenting ordinary participants while Focus remains ON? 4. Which service-side traces would distinguish a visibility policy from a native SDK or service delivery defect? If private trace identifiers are required, please advise a private submission channel. Our current run did not include a Focus OFF comparison because this meeting requires Focus to stay ON. We have not individually verified the roles of all inconclusive targets, so we do not claim a definitive role-based restriction. The application checks only whether a face is visible, not identity, attendance or liveness. Original frames are processed transiently in RAM, never recorded or uploaded. No meeting IDs, participant identities, credentials or raw frames are included here. Documentation consulted: Zoom’s “Stream a single participant’s video” guide and “Using focus mode” help article. Please confirm the supported behavior and any supported path that keeps Focus Mode ON without adding audio, transcript, chat or screen-sharing media.