zoom-rtms
Reference skill for Zoom RTMS. Use after routing to a live-media workflow when processing real-time audio, video, chat, transcripts, screen share, or contact-center voice streams.
- License 许可
- Apache-2.0
- 最近更新
- 2026-11-14
- Stars
- ★ 3.6w
- Forks
- 3.9k
01 前言 Front Matter
- name
- zoom-rtms
- triggers
- [ "real-time media", "rtms", "live audio stream", "live video stream", "meeting transcription", "raw audio", "raw video", "websocket media", "live transcript", "streaming audio", "streaming video", "meeting bot media", "contact center voice media", "participant video on", "participant video off", "single individual video stream" ]
- description
- Reference skill for Zoom RTMS. Use after routing to a live-media workflow when processing real-time audio, video, chat, transcripts, screen share, or contact-center voice streams.
- user-invocable
- false
02 资源文件 14
- 参考文档concepts/connection-architecture.md9.1 KB
- 参考文档concepts/lifecycle-flow.md13.5 KB
- 参考文档examples/ai-integration.md11.4 KB
- 参考文档examples/manual-websocket.md16.9 KB
- 参考文档examples/rtms-bot.md26.3 KB
- 参考文档examples/sdk-quickstart.md9.3 KB
- 参考文档references/connection.md8.0 KB
- 参考文档references/data-types.md13.7 KB
- 参考文档references/environment-variables.md1.3 KB
- 参考文档references/media-types.md6.0 KB
- 参考文档references/quickstart.md6.6 KB
- 参考文档references/webhooks.md7.4 KB
- 参考文档RUNBOOK.md2.6 KB
- 参考文档troubleshooting/common-issues.md10.4 KB
03 SKILL.md 正文
Zoom Realtime Media Streams (RTMS)
Background reference for live Zoom media pipelines. Prefer build-zoom-bot first, then use this skill for stream types, capabilities, and RTMS-specific implementation constraints.
Zoom Realtime Media Streams (RTMS)
Expert guidance for accessing live audio, video, transcript, chat, and screen share data from Zoom meetings, webinars, Video SDK sessions, and Zoom Contact Center Voice in real-time. RTMS uses a WebSocket-based protocol with open standards and does not require a meeting bot to capture the media plane.
Read This First (Critical)
RTMS is primarily a backend media ingestion service.
- Your backend receives and processes live media: audio, video, screen share, chat, transcript.
- RTMS is not a frontend UI SDK by itself.
- Processing is event-triggered: backend waits for RTMS start webhook events before stream handling begins.
Optional architecture (common):
- Add a Zoom App SDK frontend for in-client UI/controls.
- Stream backend RTMS outputs to frontend via WebSocket (or SSE, gRPC, queue workers, etc.).
Use RTMS for media/data plane, and use frontend frameworks/Zoom Apps for presentation + user interactions.
Official Documentation: https://developers.zoom.us/docs/rtms/ SDK Reference (JS): https://zoom.github.io/rtms/js/ SDK Reference (Python): https://zoom.github.io/rtms/py/ Sample Repository: https://github.com/zoom/rtms-samples
Quick Links
New to RTMS? Follow this path:
- Connection Architecture - Two-phase WebSocket design
- SDK Quickstart - Fastest way to receive media (recommended)
- Manual WebSocket - Full protocol control without SDK
- Media Types - Audio, video, transcript, chat, screen share
Complete Implementation:
- RTMS Bot - End-to-end bot implementation guide
Reference:
- Lifecycle Flow - Complete webhook-to-streaming flow
- Data Types - All enums and constants
- Webhooks - Event subscription details
- Environment Variables - credential modes and runtime knobs
- Quickstart Notes - Secondary quickstart guide
- Integrated Index - see the section below in this file
Having issues?
- Connection fails -> Common Issues
- Duplicate connections -> Webhook Gotchas
- No audio/video -> Media Configuration
- Start with preflight checks -> 5-Minute Runbook
Supported Products
| Product | Webhook Event | Payload ID | App Type |
|---|---|---|---|
| Meetings | meeting.rtms_started / meeting.rtms_stopped |
meeting_uuid |
General App |
| Webinars | webinar.rtms_started / webinar.rtms_stopped |
meeting_uuid (same!) |
General App |
| Video SDK | session.rtms_started / session.rtms_stopped |
session_id |
Video SDK App |
| Zoom Contact Center Voice | Product-specific RTMS/ZCC Voice events | Product-specific stream/session identifiers | Contact Center / approved RTMS integration |
Once connected, the core signaling/media socket model is shared across products. Meetings, webinars, and Video SDK sessions use the familiar start/stop webhooks. Zoom Contact Center Voice adds its own RTMS/ZCC Voice event family and should be treated as the same transport model with product-specific event payloads.
RTMS Overview
RTMS is a data pipeline that gives your app access to live media from Zoom meetings, webinars, and Video SDK sessions without participant bots. Instead of having automated clients join meetings, use RTMS to collect media data directly from Zoom's infrastructure.
What RTMS Provides
| Media Type | Format | Use Cases |
|---|---|---|
| Audio | PCM (L16), G.711, G.722, Opus | Transcription, voice analysis, recording |
| Video | H.264, JPG, PNG | Recording, AI vision, thumbnails, active participant selection |
| Screen Share | H.264, JPG, PNG | Content capture, slide extraction |
| Transcript | JSON text | Meeting notes, search, compliance |
| Chat | JSON text | Archive, sentiment analysis |
March 2026 Protocol Changes
- Zoom Contact Center Voice support: RTMS now covers Contact Center Voice audio and transcript scenarios.
- Transcript Language Identification control: transcript media handshakes now support
src_languageandenable_lid. Default behavior is LID enabled. Setenable_lid: falseto force a fixed language. - Single individual video stream subscription: RTMS can now stream one participant's camera feed at a time when
data_optis set toVIDEO_SINGLE_INDIVIDUAL_STREAM. - Graceful client-initiated shutdown: backends can send
STREAM_CLOSE_REQover the signaling socket and wait forSTREAM_CLOSE_RESP. - Media keep-alive tolerance increased: media socket keep-alive timeout is now 65 seconds, not 35.
Two Approaches
| Approach | Best For | Complexity |
|---|---|---|
SDK (@zoom/rtms) |
Most use cases | Low - handles WebSocket complexity |
| Manual WebSocket | Custom protocols, other languages | High - full protocol implementation |
Prerequisites
- Node.js 20.3.0+ (24 LTS recommended) for JavaScript SDK
- Python 3.10+ for Python SDK
- Zoom General App (for meetings/webinars) or Video SDK App (for Video SDK) with RTMS feature enabled
- Webhook endpoint for RTMS events
- Server to receive WebSocket streams
Need RTMS access? Post in Zoom Developer Forum requesting RTMS access with your use case.
Quick Start (SDK - Recommended)
import rtms from "@zoom/rtms";
// All RTMS start/stop events across products
const RTMS_EVENTS = ["meeting.rtms_started", "webinar.rtms_started", "session.rtms_started"];
// Handle webhook events
rtms.onWebhookEvent(({ event, payload }) => {
if (!RTMS_EVENTS.includes(event)) return;
const client = new rtms.Client();
client.onAudioData((data, timestamp, metadata) => {
console.log(`Audio from ${metadata.userName}: ${data.length} bytes`);
});
client.onTranscriptData((data, timestamp, metadata) => {
const text = data.toString('utf8');
console.log(`${metadata.userName}: ${text}`);
});
client.onJoinConfirm((reason) => {
console.log(`Joined session: ${reason}`);
});
// SDK handles all WebSocket connections automatically
// Accepts both meeting_uuid and session_id transparently
client.join(payload);
});
Quick Start (Manual WebSocket)
For full control or non-SDK languages, implement the two-phase WebSocket protocol:
const WebSocket = require('ws');
const crypto = require('crypto');
const RTMS_EVENTS = ['meeting.rtms_started', 'webinar.rtms_started', 'session.rtms_started'];
// 1. Generate signature
// For meetings/webinars: uses meeting_uuid. For Video SDK: uses session_id.
function generateSignature(clientId, idValue, streamId, clientSecret) {
const message = `${clientId},${idValue},${streamId}`;
return crypto.createHmac('sha256', clientSecret).update(message).digest('hex');
}
// 2. Handle webhook
app.post('/webhook', (req, res) => {
res.status(200).send(); // CRITICAL: Respond immediately!
const { event, payload } = req.body;
if (RTMS_EVENTS.includes(event)) {
connectToRTMS(payload);
}
});
// 3. Connect to signaling WebSocket
function connectToRTMS(payload) {
const { server_urls, rtms_stream_id } = payload;
// meeting_uuid for meetings/webinars, session_id for Video SDK
const idValue = payload.meeting_uuid || payload.session_id;
const signature = generateSignature(CLIENT_ID, idValue, rtms_stream_id, CLIENT_SECRET);
const signalingWs = new WebSocket(server_urls);
signalingWs.on('open', () => {
signalingWs.send(JSON.stringify({
msg_type: 1, // Handshake request
protocol_version: 1,
meeting_uuid: idValue,
rtms_stream_id,
signature,
media_type: 9 // AUDIO(1) | TRANSCRIPT(8)
}));
});
// ... handle responses, connect to media WebSocket
}
See: Manual WebSocket Guide for complete implementation.
Media Type Bitmask
Combine types with bitwise OR:
| Type | Value | Description |
|---|---|---|
| Audio | 1 | PCM audio samples |
| Video | 2 | H.264/JPG video frames |
| Screen Share | 4 | Separate from video! |
| Transcript | 8 | Real-time speech-to-text |
| Chat | 16 | In-meeting chat messages |
| All | 32 | All media types |
Example: Audio + Transcript = 1 | 8 = 9
Critical Gotchas
| Issue | Solution |
|---|---|
| Only 1 connection allowed | New connections kick out existing ones. Track active sessions! |
| Respond 200 immediately | If webhook delays, Zoom retries creating duplicate connections |
| Heartbeat mandatory | Respond to msg_type 12 with msg_type 13, or connection dies |
| Reconnection is YOUR job | RTMS doesn't auto-reconnect. Media keep-alive tolerance is now about 65s; signaling remains around 60s |
| Transcript language drift | Use src_language plus enable_lid: false when you want fixed-language transcription instead of automatic language switching |
| Single participant video only | VIDEO_SINGLE_INDIVIDUAL_STREAM supports one participant at a time. A new VIDEO_SUBSCRIPTION_REQ overrides the previous selection |
| Graceful close is explicit now | Use STREAM_CLOSE_REQ / STREAM_CLOSE_RESP when your backend wants to terminate the stream cleanly |
Environment Variables
SDK Environment Variables
# Required - Authentication
ZM_RTMS_CLIENT=your_client_id # Zoom OAuth Client ID
ZM_RTMS_SECRET=your_client_secret # Zoom OAuth Client Secret
# Optional - Webhook server
ZM_RTMS_PORT=8080 # Default: 8080
ZM_RTMS_PATH=/webhook # Default: /
# Optional - Logging
ZM_RTMS_LOG_LEVEL=info # error, warn, info, debug, trace
ZM_RTMS_LOG_FORMAT=progressive # progressive or json
ZM_RTMS_LOG_ENABLED=true
Manual Implementation Variables
ZOOM_CLIENT_ID=your_client_id
ZOOM_CLIENT_SECRET=your_client_secret
ZOOM_SECRET_TOKEN=your_webhook_token # For webhook validation
Zoom App Setup
For Meetings and Webinars (General App)
- Go to marketplace.zoom.us -> Develop -> Build App
- Choose General App -> User-Managed
- Features -> Access -> Enable Event Subscription
- Add Events -> Search "rtms" -> Select:
meeting.rtms_startedmeeting.rtms_stoppedwebinar.rtms_started(if using webinars)webinar.rtms_stopped(if using webinars)
- Scopes -> Add Scopes -> Search "rtms" -> Add:
meeting:read:meeting_audiomeeting:read:meeting_videomeeting:read:meeting_transcriptmeeting:read:meeting_chatwebinar:read:webinar_audio(if using webinars)webinar:read:webinar_video(if using webinars)webinar:read:webinar_transcript(if using webinars)webinar:read:webinar_chat(if using webinars)
For Video SDK (Video SDK App)
- Go to marketplace.zoom.us -> Develop -> Build App
- Choose Video SDK App
- Use your SDK Key and SDK Secret (not OAuth Client ID/Secret)
- Add Events:
session.rtms_startedsession.rtms_stopped
Sample Repositories
Official Samples
| Repository | Description |
|---|---|
| rtms-samples | RTMSManager, boilerplates, AI samples |
| rtms-quickstart-js | JavaScript SDK quickstart |
| rtms-quickstart-py | Python SDK quickstart |
| rtms-sdk-cpp | C++ SDK |
| zoom-rtms | Main SDK repository |
AI Integration Samples
| Sample | Description |
|---|---|
| rtms-meeting-assistant-starter-kit | AI meeting assistant with summaries |
| arlo-meeting-assistant | Production meeting assistant with DB |
| videosdk-rtms-transcribe-audio | Whisper transcription |
Complete Documentation
Concepts
- Connection Architecture - Two-phase WebSocket design
- Lifecycle Flow - Webhook to streaming flow
Examples
- SDK Quickstart - Using @zoom/rtms SDK
- Manual WebSocket - Raw protocol implementation
- RTMS Bot - Complete bot implementation guide
- AI Integration - Transcription and analysis patterns
References
- Media Types - Audio, video, transcript, chat, screen share
- Data Types - All enums and constants
- Connection - WebSocket protocol details
- Webhooks - Event subscription
Troubleshooting
- Common Issues - FAQ and solutions
Resources
- Official docs: https://developers.zoom.us/docs/rtms/
- Data types: https://developers.zoom.us/docs/rtms/data-types/
- Media params: https://developers.zoom.us/docs/rtms/media-parameter-definition/
- Developer forum: https://devforum.zoom.us/
Need help? Start with Integrated Index section below for complete navigation.
Integrated Index
This section was migrated from SKILL.md.
RTMS provides real-time access to live audio, video, transcript, chat, and screen share from Zoom meetings, webinars, and Video SDK sessions.
Critical Positioning
Treat RTMS as a backend service for receiving and processing media streams.
- Backend role: ingest audio/video/share/chat/transcript, run AI/analytics, persist/forward data.
- Optional frontend role: Zoom App SDK or web dashboard that consumes processed stream data from backend transport (WebSocket/SSE/other).
- Kickoff model: backend waits for RTMS start webhook events, then starts stream processing.
Do not model RTMS as a frontend-only SDK.
Quick Start Path
If you're new to RTMS, follow this order:
-
Run preflight checks first -> RUNBOOK.md
-
Understand the architecture -> concepts/connection-architecture.md
- Two-phase WebSocket: Signaling + Media
- Why RTMS doesn't use bots
-
Choose your approach -> SDK or Manual
- SDK (recommended): examples/sdk-quickstart.md
- Manual WebSocket: examples/manual-websocket.md
-
Understand the lifecycle -> concepts/lifecycle-flow.md
- Webhook -> Signaling -> Media -> Streaming
-
Configure media types -> references/media-types.md
- Audio, video, transcript, chat, screen share
-
Troubleshoot issues -> troubleshooting/common-issues.md
- Connection problems, duplicate webhooks, missing data
Documentation Structure
rtms/
├── SKILL.md # Main skill overview
├── SKILL.md # This file - navigation guide
│
├── concepts/ # Core architectural patterns
│ ├── connection-architecture.md # Two-phase WebSocket design
│ └── lifecycle-flow.md # Webhook to streaming flow
│
├── examples/ # Complete working code
│ ├── sdk-quickstart.md # Using @zoom/rtms SDK
│ ├── manual-websocket.md # Raw protocol implementation
│ ├── rtms-bot.md # Complete RTMS bot implementation
│ └── ai-integration.md # Transcription and analysis
│
├── references/ # Reference documentation
│ ├── media-types.md # Audio, video, transcript, chat, share
│ ├── data-types.md # All enums and constants
│ ├── connection.md # WebSocket protocol details
│ └── webhooks.md # Event subscription
│
└── troubleshooting/ # Problem solving guides
└── common-issues.md # FAQ and solutions
By Use Case
I want to get meeting transcripts
- SDK Quickstart - Fastest approach
- Media Types - Transcript configuration
- AI Integration - Whisper, Deepgram, AssemblyAI
I want to record meetings
- Media Types - Audio + Video configuration
- SDK Quickstart - Receiving media
- AI Integration - Gap-filled recording
I want to build an AI meeting assistant
- AI Integration - Complete patterns
- SDK Quickstart - Media ingestion
- Lifecycle Flow - Event handling
I want to build a complete RTMS bot
- RTMS Bot - Complete implementation guide
- Lifecycle Flow - Webhook to streaming flow
- Connection Architecture - Two-phase design
I need full protocol control
- Manual WebSocket - START HERE
- Connection Architecture - Two-phase design
- Data Types - All message types and enums
- Connection - Protocol details
I'm getting connection errors
- Common Issues - Diagnostic checklist
- Connection Architecture - Verify flow
- Webhooks - Validation and timing
I want to understand the architecture
- Connection Architecture - Two-phase WebSocket
- Lifecycle Flow - Complete flow diagram
- Data Types - Protocol constants
By Product
I'm building for Zoom Meetings
- Standard RTMS setup. Webhook event:
meeting.rtms_started. Uses General App with OAuth. - Start with SDK Quickstart or Manual WebSocket.
I'm building for Zoom Webinars
- Same as meetings, but webhook event is
webinar.rtms_started. Payload still usesmeeting_uuid(NOTwebinar_uuid). - Add webinar scopes and event subscriptions. See Webhooks.
- Only panelist streams are confirmed available. Attendee streams may not be individual.
I'm building for Zoom Video SDK
- Webhook event:
session.rtms_started. Payload usessession_id(NOTmeeting_uuid). - Requires a Video SDK App with SDK Key/Secret (not OAuth Client ID/Secret).
- Once connected, the protocol is identical to meetings.
- See Webhooks for payload details.
Key Documents
1. Connection Architecture (CRITICAL)
concepts/connection-architecture.md
RTMS uses two separate WebSocket connections:
- Signaling WebSocket: Authentication, control, heartbeats
- Media WebSocket: Actual audio/video/transcript data
2. SDK vs Manual (DECISION POINT)
examples/sdk-quickstart.md vs examples/manual-websocket.md
| SDK | Manual |
|---|---|
| Handles WebSocket complexity | Full protocol control |
| Automatic reconnection | DIY reconnection |
| Less code | More code |
| Best for most use cases | Best for custom requirements |
3. Critical Gotchas (MOST COMMON ISSUES)
troubleshooting/common-issues.md
- Respond 200 immediately - Delayed webhook responses cause duplicates
- Only 1 connection per stream - New connections kick out existing
- Heartbeat required - Must respond to keep-alive or connection dies
- Track active sessions - Prevent duplicate join attempts
Key Learnings
Critical Discoveries:
-
Two-Phase WebSocket Design
- Signaling: Control plane (handshake, heartbeat, start/stop)
- Media: Data plane (audio, video, transcript, chat, share)
- See: Connection Architecture
-
Webhook Response Timing
- MUST respond 200 BEFORE any processing
- Delayed response -> Zoom retries -> duplicate connections
- See: Common Issues
-
Heartbeat is Mandatory
- Signaling: Receive msg_type 12, respond with msg_type 13
- Media: Same pattern
- Failure to respond = connection closed
- See: Connection
-
Signature Generation
- Format:
HMAC-SHA256(clientSecret, "clientId,meetingUuid,streamId") - For Video SDK, use
session_idin place ofmeetingUuid - Webinars still use
meeting_uuid(notwebinar_uuid) - Required for both signaling and media handshakes
- See: Manual WebSocket
- Format:
-
Media Types are Bitmasks
- Audio=1, Video=2, Share=4, Transcript=8, Chat=16, All=32
- Combine with OR: Audio+Transcript = 1|8 = 9
- See: Media Types
-
Screen Share is SEPARATE from Video
- Different msg_type (16 vs 15)
- Different media flag (4 vs 2)
- Must subscribe separately
- See: Media Types
Quick Reference
"Connection fails"
"Duplicate connections"
"No audio/video data"
-> Media Types - Check configuration
"How do I implement manually?"
"What message types exist?"
-> Data Types
"How do I integrate AI?"
Document Version
Based on Zoom RTMS SDK v1.x and official documentation as of 2026.
Happy coding!
Remember: Start with SDK Quickstart for the fastest path, or Manual WebSocket if you need full control.
04 同仓库更多 Skills
ticket-deflector
Reads a forwarded customer email or ticket, pulls order and refund status from a payments connector (PayPal, Square, or Stripe) or Shopify, account history from the CRM, and open tickets from a support desk (Zoho Desk), drafts a tone-matched reply in the owner's writing voice, and can issue a refund through the payments connector with explicit owner approval. With Shopify connected it also runs a proactive order-triage mode that surfaces orders needing attention — unfulfilled past the promised window, payment problems, pending refunds, stuck shipments — and drafts the next action for each before the customer has to ask. Use when the user says "draft a response," "answer this customer," "where's my order," "I want a refund," "check my orders," or "anything about to blow up."
tax-season-organizer
Prepares tax-season materials for the owner's accountant, not tax advice. US federal tax; a non-US business gets its closed-books packet instead. Two modes: (1) quarterly estimated tax from YTD net income in the ledger (MYOB, NetSuite, QuickBooks, Xero, or Zoho Books); (2) year-end 1099 prep, scanning the ledger, PayPal, and Stripe for contractors paid over USD 600 into a 1099-NEC list with missing W-9 flags. Any tax request routes first to /tax-prep, which confirms the books are closed and reconciled before running this skill. Use this skill directly only when the owner says the period's books are already closed: "books are closed, now do the 1099s," "run the quarterly estimate off the closed numbers," or "just the contractor W-9 list."
tax-prep
Prepares tax materials as a two-link chain — month-end-prep confirms the books are closed and reconciled first, then tax-season-organizer calculates the quarterly estimated payment or builds the year-end 1099-NEC list and accountant packet from those closed numbers. Requires a ledger (MYOB, NetSuite, QuickBooks, Xero, or Zoho Books); uses Gusto, PayPal, and Stripe when connected, else CSV upload. US federal tax math; a non-US business gets the closed-books packet. Prep material for a CPA, never tax advice, nothing filed. Trigger on "quarterly taxes," "estimated tax payment," "how much should I set aside," "1099s," "1099-NEC," "W-9s," "year-end tax prep," "get my books ready for my accountant," any phrasing that suggests a tax deadline is coming, or a question about net profit or YTD income that sounds like worry about a tax bill. An owner who says the period's books are already closed routes to tax-season-organizer directly.
speed-to-lead
Makes sure no inbound lead goes unanswered. Watches web forms, the shared inbox, and the CRM for new inquiries, qualifies each one against the owner's criteria, drafts a reply in the owner's voice with real meeting times for the owner to approve and send, routes anything hot to a human right away, and logs the whole thing to the CRM. Never sends on its own. Built to run on a schedule so overnight inquiries are drafted and sorted by morning, and works from forwarded or pasted inquiries when no connector is available. Use this whenever the owner is worried about inbound leads or response time — including phrasings like "leads are going cold," "did anyone answer that inquiry," "I keep missing form submissions," "nothing falls through the cracks," "handle my inbound," "respond to this lead," or "we lose people because nobody gets back fast enough." Reach for it for a single unanswered inquiry as readily as for a standing setup.
social-content-engine
Runs the owner's content operation as a standing thing rather than a one-off: keeps a rolling posting calendar, learns the owner's voice, generates on-brand Canva graphics, writes captions that sound like them, repurposes one asset into every channel format, and stages posts for approval instead of publishing on its own. Pulls product photos and prices from Shopify when connected; with no connectors, drafts the calendar and asset briefs for manual posting. Use this whenever the owner talks about posting, content, or social — including "I need to post more," "we've gone quiet on Instagram," "what should we post this month," "make the content," "give me a month of posts," "write this in my voice," "repurpose this," or "set up our content calendar." Reach for it for a single post as readily as for a full quarter. One handoff: a finished, approved campaign brief goes to canva-creator; this skill owns the standing operation.
smb-router
The front door to the Small Business plugin. Listens to what the owner needs right now — vague or specific — and routes them to the best skill or slash command for the moment. Also serves as a guide: explains what's available, suggests what to try next, and adapts recommendations based on stored business context. Trigger whenever the owner asks "what can you do," "help me with my business," "what should I focus on," "I don't know where to start," or any open-ended business request that doesn't clearly match a single skill.