These changes are coming in the November release. They aren't available yet, so use this preview to plan your integration before the release.

RTMS V2 protocol#

The V2 protocol will add new features and some restrictions compared to V1.

• Protobuf wire format: A binary alternative to JSON with smaller payloads, faster serialization, and native binary data handling without Base64 encoding. JSON messages will be unchanged and work with both V1 and V2.
• SRT transport for data connections: A low-latency transport with selective packet loss recovery that performs better on unstable networks. Existing WSS data connections will remain supported. The signaling handshake response will include srt_passphrase and srt_pbkey_length.
• Event codes: V2 will use event_code, a globally unique identifier, in place of the legacy service-specific event_type. Zoom Meetings and Zoom Contact Center voice will keep V1 compatibility. Zoom Phone will use event_code only.
• Multiple individual video streams: Lets you open a separate video data connection for each participant you want to receive video from. You subscribe each connection to one participant over the signal connection, and each connection receives only that participant's video. Capacity depends on the requested resolution. By default, the service supports up to four concurrent 720p subscriptions per stream. The server-side multiple-video-subscription feature must be enabled.
• Video format: Standard definition video will be 640x360, and PNG will no longer be available for video or screen share.

Error responses#

RTMS will add a REQUEST_ERROR_RESP message type. It returns request_msg_type, status_code, reason, and timestamp for failed requests, and it adds more validation status codes.

Application-layer media payload encryption#

RTMS will support AEAD encryption of outbound media and text content. It adds a layer of security on top of the existing TLS and WebSocket transport encryption. The Zoom team must approve and enable it for each app. This feature will be available by request only.

Zoom Phone#

Zoom Phone developers will be able to use RTMS to retrieve audio or transcript data, consistent with the existing Zoom Meetings and Zoom Contact Center voice capabilities. The initial Zoom Phone events will use event codes 3000 to 3003 and will cover call information, hold, resume, and transfer completion.

Transcript rewind#

Transcript rewind will let RTMS clients receive corrections to transcript sentences that were already delivered, as the ASR refines its results. Rewind will be on by default when enable_lid is enabled, and it will be off when enable_lid is set to false.

Initial sentences will arrive as NEW events (attribute: 1). Revisions will arrive as UPDATE events (attribute: 2) with the same sentence_id and the complete replacement text. On an UPDATE, replace the existing sentence instead of adding a new one. With speaker diarization enabled, speaker-specific segments will keep the parent sentence_id and update attribute.

Participant and audio data#

• MEDIA_DATA_USER_INFO event: The MEDIA_DATA_USER_INFO event will identify participants whose audio, video, screen share, transcript, or chat data the service has observed. It will include user_id, user_name, and participant_uuid. The service will send it automatically in the EVENT_UPDATE message, so no subscription will be needed. Zoom Meetings only.
• Audio source: MEDIA_DATA_AUDIO will include a content.source field in JSON and protobuf. A value of 1 means microphone audio, and 2 means shared-content audio. Use it to tell screen-share audio apart from microphone input.
• Original audio parameters: Meeting audio will keep its 48 kHz sample rate and 16 kHz frequency range by default. Apps that need 48 or 32 kHz audio will keep the same frequency range. Apps that need 16 kHz audio will see no change. Telephony and special device audio will keep its native sample rate and frequency range.
• Audio message boundaries: For RTP and raw Opus, G711, or G722 content, each MEDIA_DATA_AUDIO message will contain one audio frame. For raw L16 content, messages will contain variable-length frames up to 128 KiB.

TLS version requirement#

Starting November 15, 2026, RTMS will require TLS 1.2 or TLS 1.3 on all connections. Connections that use an older TLS version will be rejected. Make sure your client connection requests use one of the supported versions. For the supported cipher suites, see Upcoming change: TLS version requirement.