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.
- 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
- Install the required dependencies:
pip install -r requirements.txt- Create a
.envfile 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
- Start the server:
gunicorn index:app --bind 0.0.0.0:3000- 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-
Configure your Zoom App's webhook URL to point to your exposed endpoint (e.g.,
https://your-ngrok-url/webhook) -
Start a Zoom meeting and enable RTMS. The server will receive and print the incoming audio data.
- The server listens for webhook events from Zoom
- When RTMS starts, it establishes WebSocket connections to Zoom's signaling and media servers
- Audio, Video and Transcript data is received through the media WebSocket connection
- The audio/video/transcript msg type is printed to the console
- 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
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_wssRun 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.