Zoom Realtime Media Streams (RTMS)

Documentation de référence pour les pipelines média Zoom en direct. Préférez build-zoom-bot d'abord, puis utilisez cette compétence pour les types de flux, les capacités et les contraintes d'implémentation spécifiques à RTMS.

Zoom Realtime Media Streams (RTMS)

Guidance expert pour accéder en temps réel aux données audio, vidéo, transcript, chat et partage d'écran depuis les réunions Zoom, webinaires, sessions Video SDK et Zoom Contact Center Voice. RTMS utilise un protocole basé sur WebSocket avec des standards ouverts et ne nécessite pas de bot de réunion pour capturer le plan média.

Lisez ceci en premier (Critique)

RTMS est principalement un service d'ingestion média backend.

• Votre backend reçoit et traite les médias en direct : audio, vidéo, partage d'écran, chat, transcript.
• RTMS n'est pas un SDK UI frontend en soi.
• Le traitement est déclenché par événements : le backend attend les événements webhook de démarrage RTMS avant de commencer la gestion du flux.

Architecture optionnelle (courante) :

• Ajoutez un frontend Zoom App SDK pour les contrôles et UI côté client.
• Streamez les sorties RTMS du backend vers le frontend via WebSocket (ou SSE, gRPC, workers de file d'attente, etc.).

Utilisez RTMS pour le plan média/données, et utilisez les frameworks frontend/Zoom Apps pour la présentation et les interactions utilisateur.

Documentation officielle : https://developers.zoom.us/docs/rtms/ Référence SDK (JS) : https://zoom.github.io/rtms/js/ Référence SDK (Python) : https://zoom.github.io/rtms/py/ Dépôt d'exemples : https://github.com/zoom/rtms-samples

Liens rapides

Nouveau sur RTMS ? Suivez ce chemin :

1. Architecture de connexion - Design WebSocket en deux phases
2. Démarrage rapide SDK - Moyen le plus rapide de recevoir des médias (recommandé)
3. WebSocket manuel - Contrôle complet du protocole sans SDK
4. Types de médias - Audio, vidéo, transcript, chat, partage d'écran

Implémentation complète :

• Bot RTMS - Guide de mise en œuvre de bot de bout en bout

Référence :

• Flux de cycle de vie - Flux complet webhook-to-streaming
• Types de données - Tous les énumérations et constantes
• Webhooks - Détails d'abonnement aux événements
• Variables d'environnement - Modes de credentials et paramètres runtime
• Notes de démarrage rapide - Guide de démarrage rapide secondaire
• Index intégré - voir la section ci-dessous dans ce fichier

Vous avez des problèmes ?

• Connexion échouée -> Problèmes courants
• Connexions dupliquées -> Pièges de webhooks
• Pas d'audio/vidéo -> Configuration des médias
• Commencez par les contrôles de préflight -> Manuel en 5 minutes

Produits supportés

Une fois connecté, le modèle de socket signaling/média principal est partagé entre les produits. Les réunions, webinaires et sessions Video SDK utilisent les webhooks start/stop familiers. Zoom Contact Center Voice ajoute sa propre famille d'événements RTMS/ZCC Voice et doit être traité comme le même modèle de transport avec des charges utiles d'événements spécifiques au produit.

Aperçu RTMS

RTMS est un pipeline de données qui donne à votre application un accès aux médias en direct depuis les réunions Zoom, webinaires et sessions Video SDK sans bots participants. Au lieu d'avoir des clients automatisés qui rejoignent les réunions, utilisez RTMS pour collecter les données de médias directement depuis l'infrastructure Zoom.

Ce que RTMS fournit

Changements de protocole mars 2026

• Support Zoom Contact Center Voice : RTMS couvre désormais les scénarios audio et transcript de Contact Center Voice.
• Contrôle d'identification de langue de transcript : les négociations de médias transcript supportent maintenant src_language et enable_lid. Le comportement par défaut est LID activé. Définissez enable_lid: false pour forcer une langue fixe.
• Abonnement à flux vidéo individuel unique : RTMS peut maintenant streamer le flux caméra d'un seul participant à la fois quand data_opt est défini à VIDEO_SINGLE_INDIVIDUAL_STREAM.
• Arrêt initié par le client gracieux : les backends peuvent envoyer STREAM_CLOSE_REQ sur le socket signaling et attendre STREAM_CLOSE_RESP.
• Tolérance de keep-alive média augmentée : le timeout de keep-alive du socket média est maintenant 65 secondes, non 35.

Deux approches

Prérequis

• Node.js 20.3.0+ (24 LTS recommandé) pour SDK JavaScript
• Python 3.10+ pour SDK Python
• App générale Zoom (pour réunions/webinaires) ou App Video SDK (pour Video SDK) avec la fonctionnalité RTMS activée
• Point de terminaison webhook pour les événements RTMS
• Serveur pour recevoir les flux WebSocket

Vous avez besoin d'un accès RTMS ? Postez dans le Forum des développeurs Zoom demandant l'accès RTMS avec votre cas d'usage.

Démarrage rapide (SDK - Recommandé)

import rtms from "@zoom/rtms";

// Tous les événements de démarrage/arrêt RTMS entre les produits
const RTMS_EVENTS = ["meeting.rtms_started", "webinar.rtms_started", "session.rtms_started"];

// Gérer les événements webhook
rtms.onWebhookEvent(({ event, payload }) => {
  if (!RTMS_EVENTS.includes(event)) return;

  const client = new rtms.Client();

  client.onAudioData((data, timestamp, metadata) => {
    console.log(`Audio de ${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(`Rejoint la session: ${reason}`);
  });

  // SDK gère automatiquement toutes les connexions WebSocket
  // Accepte à la fois meeting_uuid et session_id de manière transparente
  client.join(payload);
});

Démarrage rapide (WebSocket manuel)

Pour un contrôle complet ou des langages non-SDK, implémentez le protocole WebSocket en deux phases :

const WebSocket = require('ws');
const crypto = require('crypto');

const RTMS_EVENTS = ['meeting.rtms_started', 'webinar.rtms_started', 'session.rtms_started'];

// 1. Générer la signature
// Pour réunions/webinaires : utilise meeting_uuid. Pour Video SDK : utilise session_id.
function generateSignature(clientId, idValue, streamId, clientSecret) {
  const message = `${clientId},${idValue},${streamId}`;
  return crypto.createHmac('sha256', clientSecret).update(message).digest('hex');
}

// 2. Gérer le webhook
app.post('/webhook', (req, res) => {
  res.status(200).send();  // CRITIQUE : Répondez immédiatement !

  const { event, payload } = req.body;
  if (RTMS_EVENTS.includes(event)) {
    connectToRTMS(payload);
  }
});

// 3. Se connecter au WebSocket signaling
function connectToRTMS(payload) {
  const { server_urls, rtms_stream_id } = payload;
  // meeting_uuid pour réunions/webinaires, session_id pour 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,  // Demande de handshake
      protocol_version: 1,
      meeting_uuid: idValue,
      rtms_stream_id,
      signature,
      media_type: 9  // AUDIO(1) | TRANSCRIPT(8)
    }));
  });

  // ... gérer les réponses, se connecter au WebSocket média
}

Voir : Guide WebSocket manuel pour une implémentation complète.

Masque de type média

Combinez les types avec OR bit à bit :

Exemple : Audio + Transcript = 1 | 8 = 9

Pièges critiques

Variables d'environnement

Variables d'environnement SDK

# Requis - Authentification
ZM_RTMS_CLIENT=your_client_id          # ID Client OAuth Zoom
ZM_RTMS_SECRET=your_client_secret      # Secret Client OAuth Zoom

# Optionnel - Serveur webhook
ZM_RTMS_PORT=8080                      # Par défaut : 8080
ZM_RTMS_PATH=/webhook                  # Par défaut : /

# Optionnel - Logging
ZM_RTMS_LOG_LEVEL=info                 # error, warn, info, debug, trace
ZM_RTMS_LOG_FORMAT=progressive         # progressive ou json
ZM_RTMS_LOG_ENABLED=true

Variables implémentation manuelle

ZOOM_CLIENT_ID=your_client_id
ZOOM_CLIENT_SECRET=your_client_secret
ZOOM_SECRET_TOKEN=your_webhook_token   # Pour validation de webhook

Configuration de l'app Zoom

Pour réunions et webinaires (App générale)

1. Allez sur marketplace.zoom.us -> Develop -> Build App
2. Choisissez General App -> User-Managed
3. Features -> Access -> Enable Event Subscription
4. Add Events -> Recherchez "rtms" -> Sélectionnez :
   • meeting.rtms_started
   • meeting.rtms_stopped
   • webinar.rtms_started (si vous utilisez des webinaires)
   • webinar.rtms_stopped (si vous utilisez des webinaires)
5. Scopes -> Add Scopes -> Recherchez "rtms" -> Ajoutez :
   • meeting:read:meeting_audio
   • meeting:read:meeting_video
   • meeting:read:meeting_transcript
   • meeting:read:meeting_chat
   • webinar:read:webinar_audio (si vous utilisez des webinaires)
   • webinar:read:webinar_video (si vous utilisez des webinaires)
   • webinar:read:webinar_transcript (si vous utilisez des webinaires)
   • webinar:read:webinar_chat (si vous utilisez des webinaires)

Pour Video SDK (App Video SDK)

1. Allez sur marketplace.zoom.us -> Develop -> Build App
2. Choisissez Video SDK App
3. Utilisez votre SDK Key et SDK Secret (pas ID Client OAuth/Secret)
4. Add Events :
   • session.rtms_started
   • session.rtms_stopped

Dépôts d'exemples

Exemples officiels

Exemples d'intégration IA

Documentation complète

Concepts

• Architecture de connexion - Design WebSocket en deux phases
• Flux de cycle de vie - Flux webhook à streaming

Exemples

• Démarrage rapide SDK - Utilisation du SDK @zoom/rtms
• WebSocket manuel - Implémentation de protocole brut
• Bot RTMS - Guide de mise en œuvre de bot complète
• Intégration IA - Patterns de transcription et analyse

Références

• Types de médias - Audio, vidéo, transcript, chat, partage d'écran
• Types de données - Tous les énumérations et constantes
• Connexion - Détails du protocole WebSocket
• Webhooks - Abonnement aux événements

Dépannage

• Problèmes courants - FAQ et solutions

Ressources

• Docs officiels : https://developers.zoom.us/docs/rtms/
• Types de données : https://developers.zoom.us/docs/rtms/data-types/
• Paramètres média : https://developers.zoom.us/docs/rtms/media-parameter-definition/
• Forum développeur : https://devforum.zoom.us/

Besoin d'aide ? Commencez par la section Index intégré ci-dessous pour la navigation complète.

Index intégré

Cette section a été migrée depuis SKILL.md.

RTMS fournit un accès en temps réel aux médias en direct (audio, vidéo, transcript, chat et partage d'écran) depuis les réunions Zoom, webinaires et sessions Video SDK.

Positionnement critique

Traitez RTMS comme un service backend pour recevoir et traiter les flux média.

• Rôle backend : ingérer audio/vidéo/partage/chat/transcript, exécuter IA/analytique, persister/transférer les données.
• Rôle frontend optionnel : Zoom App SDK ou tableau de bord web qui consomme les données de flux traité depuis le transport backend (WebSocket/SSE/autre).
• Modèle de démarrage : le backend attend les événements webhook de démarrage RTMS, puis commence le traitement du flux.

Ne modélisez pas RTMS comme un SDK frontend uniquement.

Chemin de démarrage rapide

Si vous êtes nouveau sur RTMS, suivez cet ordre :

1. Exécutez d'abord les contrôles de préflight -> RUNBOOK.md

2. Comprenez l'architecture -> concepts/connection-architecture.md

   • WebSocket en deux phases : Signaling + Média
   • Pourquoi RTMS n'utilise pas de bots

3. Choisissez votre approche -> SDK ou Manuel

   • SDK (recommandé) : examples/sdk-quickstart.md
   • WebSocket manuel : examples/manual-websocket.md

4. Comprenez le cycle de vie -> concepts/lifecycle-flow.md

   • Webhook -> Signaling -> Média -> Streaming

5. Configurez les types de médias -> references/media-types.md

   • Audio, vidéo, transcript, chat, partage d'écran

6. Dépannez les problèmes -> troubleshooting/common-issues.md

   • Problèmes de connexion, webhooks dupliqués, données manquantes

Structure de la documentation

rtms/
├── SKILL.md                           # Aperçu principal de la compétence
├── SKILL.md                           # Ce fichier - guide de navigation
│
├── concepts/                          # Patterns architecturaux principaux
│   ├── connection-architecture.md     # Design WebSocket en deux phases
│   └── lifecycle-flow.md              # Flux webhook à streaming
│
├── examples/                          # Code de travail complète
│   ├── sdk-quickstart.md              # Utilisation du SDK @zoom/rtms
│   ├── manual-websocket.md            # Implémentation de protocole brut
│   ├── rtms-bot.md                    # Mise en œuvre complète du bot RTMS
│   └── ai-integration.md              # Transcription et analyse
│
├── references/                        # Documentation de référence
│   ├── media-types.md                 # Audio, vidéo, transcript, chat, partage
│   ├── data-types.md                  # Tous les énumérations et constantes
│   ├── connection.md                  # Détails du protocole WebSocket
│   └── webhooks.md                    # Abonnement aux événements
│
└── troubleshooting/                   # Guides de résolution de problèmes
    └── common-issues.md               # FAQ et solutions

Par cas d'usage

Je veux obtenir les transcripts de réunion

1. Démarrage rapide SDK - Approche la plus rapide
2. Types de médias - Configuration du transcript
3. Intégration IA - Whisper, Deepgram, AssemblyAI

Je veux enregistrer les réunions

1. Types de médias - Configuration audio + vidéo
2. Démarrage rapide SDK - Réception de médias
3. Intégration IA - Enregistrement avec comblage de lacunes

Je veux construire un assistant de réunion IA

1. Intégration IA - Patterns complets
2. Démarrage rapide SDK - Ingestion de médias
3. Flux de cycle de vie - Gestion des événements

Je veux construire un bot RTMS complète

1. Bot RTMS - Guide de mise en œuvre complète
2. Flux de cycle de vie - Flux webhook à streaming
3. Architecture de connexion - Design en deux phases

J'ai besoin du contrôle complet du protocole

1. WebSocket manuel - COMMENCEZ ICI
2. Architecture de connexion - Design en deux phases
3. Types de données - Tous les types de messages et énumérations
4. Connexion - Détails du protocole

J'obtiens des erreurs de connexion

1. Problèmes courants - Checklist de diagnostic
2. Architecture de connexion - Vérifiez le flux
3. Webhooks - Validation et timing

Je veux comprendre l'architecture

1. Architecture de connexion - WebSocket en deux phases
2. Flux de cycle de vie - Diagramme de flux complet
3. Types de données - Constantes de protocole

Par produit

Je construis pour Zoom Meetings

• Configuration RTMS standard. Événement webhook : meeting.rtms_started. Utilise une App générale avec OAuth.
• Commencez par Démarrage rapide SDK ou WebSocket manuel.

Je construis pour Zoom Webinars

• Identique aux réunions, mais l'événement webhook est webinar.rtms_started. La charge utile utilise toujours meeting_uuid (PAS webinar_uuid).
• Ajoutez les scopes webinaire et les abonnements aux événements. Voir Webhooks.
• Seuls les flux des panélistes sont confirmés disponibles. Les flux des assistants ne peuvent pas être individuels.

Je construis pour Zoom Video SDK

• Événement webhook : session.rtms_started. La charge utile utilise session_id (PAS meeting_uuid).
• Nécessite une App Video SDK avec SDK Key/Secret (pas ID Client OAuth/Secret).
• Une fois connecté, le protocole est identique aux réunions.
• Voir Webhooks pour les détails de charge utile.

Documents clés

1. Architecture de connexion (CRITIQUE)

concepts/connection-architecture.md

RTMS utilise deux connexions WebSocket séparées :

• WebSocket signaling : Authentification, contrôle, heartbeats
• WebSocket média : Données réelles audio/vidéo/transcript

2. SDK vs Manuel (POINT DE DÉCISION)

examples/sdk-quickstart.md vs examples/manual-websocket.md

3. Pièges critiques (PROBLÈMES LES PLUS COURANTS)

troubleshooting/common-issues.md

1. Répondre 200 immédiatement - Les réponses webhook retardées causent des dupliquées
2. Seulement 1 connexion par flux - Les nouvelles connexions éjectent les existantes
3. Heartbeat requis - Doit répondre pour garder la connexion vivante
4. Suivre les sessions actives - Empêcher les tentatives d'adhésion dupliquées

Apprentissages clés

Découvertes critiques :

1. Design WebSocket en deux phases

   • Signaling : Plan contrôle (handshake, heartbeat, start/stop)
   • Média : Plan données (audio, vidéo, transcript, chat, partage)
   • Voir : Architecture de connexion

2. Timing de la réponse webhook

   • DOIT répondre 200 AVANT tout traitement
   • Réponse retardée -> Zoom réessaye -> connexions dupliquées
   • Voir : Problèmes courants

3. Heartbeat obligatoire

   • Signaling : Reçevez msg_type 12, répondez avec msg_type 13
   • Média : Même pattern
   • Échec de réponse = connexion fermée
   • Voir : Connexion

4. Génération de signature

   • Format : HMAC-SHA256(clientSecret, "clientId,meetingUuid,streamId")
   • Pour Video SDK, utilisez session_id à la place de meetingUuid
   • Les webinaires utilisent toujours meeting_uuid (pas webinar_uuid)
   • Requis pour les handshakes signaling et média
   • Voir : WebSocket manuel

5. Les types de médias sont des masques de bits

   • Audio=1, Vidéo=2, Partage=4, Transcript=8, Chat=16, Tous=32
   • Combinez avec OR : Audio+Transcript = 1|8 = 9
   • Voir : Types de médias

6. Le partage d'écran est SÉPARÉ de la vidéo

   • Différent msg_type (16 vs 15)
   • Différent flag média (4 vs 2)
   • Doit s'abonner séparément
   • Voir : Types de médias

Référence rapide

"La connexion échoue"

-> Problèmes courants

"Connexions dupliquées"

-> Timing webhook

"Pas de données audio/vidéo"

-> Types de médias - Vérifiez la configuration

"Comment implémenter manuellement ?"

-> WebSocket manuel

"Quels types de messages existent ?"

-> Types de données

"Comment intégrer l'IA ?"

-> Intégration IA

Version du document

Basé sur Zoom RTMS SDK v1.x et documentation officielle à partir de 2026.

Bon codage !

Rappelez-vous : Commencez par Démarrage rapide SDK pour le chemin le plus rapide, ou WebSocket manuel si vous avez besoin du contrôle complet.