Skip to content

Latest commit

 

History

History

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 

readme.md

Print Incoming Audio Video Transcript message type Example

This example demonstrates how to receive audio video and transcript from a Zoom meeting using the RTMS (Real-Time Media Streaming) service. It does not print out the data, but uses an if else statement to seperate audio, video and transcript via the msg_type parameter.

Prerequisites

  • Python 3.7 or higher
  • A Zoom account with RTMS enabled
  • Zoom App credentials (Client ID and Client Secret)
  • Zoom Secret Token for webhook validation

Setup

  1. Install the required dependencies:
pip install -r requirements.txt
  1. Create a .env file in the same directory with your Zoom credentials:
ZOOM_SECRET_TOKEN=your_secret_token
ZOOM_CLIENT_ID=your_client_id
ZOOM_CLIENT_SECRET=your_client_secret

Running the Example

  1. Start the server:
gunicorn index:app --bind 0.0.0.0:3000
  1. The server will start on port 3000. You'll need to expose this port to the internet using a tool like ngrok:
ngrok http 3000
  1. Configure your Zoom App's webhook URL to point to your exposed endpoint (e.g., https://your-ngrok-url/webhook)

  2. Start a Zoom meeting and enable RTMS. The server will receive and print the incoming audio data.

How it Works

  1. The server listens for webhook events from Zoom
  2. When RTMS starts, it establishes WebSocket connections to Zoom's signaling and media servers
  3. Audio, Video and Transcript data is received through the media WebSocket connection
  4. The audio/video/transcript msg type is printed to the console

Notes

  • This is a basic example that checks the msg type and prints the data type received. In a production environment, you would typically process or save this data.
  • The server handles both signaling and media WebSocket connections
  • Keep-alive messages are automatically responded to maintain the connection

Docker

The project runs the Python WebSocket-event RTMS boilerplate. Its multi-stage Dockerfile keeps build tooling out of the final runtime image and does not hard-code a CPU architecture.

Build and run it from the rtms-samples repository root:

docker build -f boilerplate/working_python_wss/Dockerfile -t rtms-boilerplate-working_python_wss .
docker run --rm --env-file boilerplate/working_python_wss/.env -p 3000:3000 rtms-boilerplate-working_python_wss

Run the build from the repository root because the Dockerfile uses repository-relative paths. Runtime secrets are supplied with --env-file and are excluded from the image build context.