How WebSocket streaming works
A WebSocket connection starts as a normal HTTP request that is upgraded to a persistent, full-duplex channel. Once open, both client and server can send messages at any time without the overhead of new requests, headers, or handshakes. The protocol is standardized, widely supported in browsers and server runtimes, and passes through most firewalls because it begins life as HTTP.
For meeting media, the server pushes a continuous sequence of audio or video frames, often as binary messages with timestamps and participant identifiers, and the client can send control messages back over the same connection.
Why WebSockets suit live meeting media
Meeting audio is a constant flow, not a series of discrete events. Request-response APIs and webhooks both fit poorly: polling adds latency and waste, and webhooks are built for occasional notifications, not thousands of frames per minute. A persistent socket delivers frames as they are produced, preserves ordering, and holds end-to-end latency low enough, typically well under a second, for transcription, translation, and voice agents to respond while people are still speaking.
What you can build on live streams
Sub-second delivery unlocks applications that after-the-fact recordings cannot serve:
- Real-time transcription and live captions
- Voice agents that listen and respond inside meetings
- Live coaching, alerting, and compliance monitoring
- Streaming meeting audio into custom ML pipelines
- Low-latency dashboards showing who is speaking now
Design considerations
Plan for the realities of long-lived connections: reconnection with backoff when networks drop, buffering so brief gaps do not lose audio, and backpressure handling when your consumer falls behind the stream. Also confirm the stream's structure, whether audio arrives as one mixed feed or as separate streams per participant, because separated streams remove the need for diarization downstream. Most providers document message schemas for frames and events; validate them early, since audio format mismatches are the most common integration bug.
WebSocket streaming in practice
MeetStream streams live meeting audio and video over WebSocket at roughly 200ms latency, with separate streams per participant, from bots on Zoom, Google Meet, and Microsoft Teams. That combination lets real-time agents know both what was said and exactly who said it. Connection details are in the MeetStream docs. See the meeting bot API page to go deeper.
Frequently asked questions
How is WebSocket streaming different from webhooks?
Webhooks deliver individual event notifications as separate HTTP requests. WebSockets keep one connection open and push continuous data through it. Use webhooks for lifecycle events and WebSockets for media and anything high-frequency.
What latency should I expect from WebSocket media streaming?
Well-built pipelines deliver meeting audio in the low hundreds of milliseconds from utterance to your application. Total experienced latency also includes whatever processing you run afterward, such as speech recognition or an LLM response.
Can WebSockets carry video as well as audio?
Yes. Video frames are just larger binary payloads, so bandwidth and decoding become the practical constraints. Meeting APIs that stream per-participant video let applications process each attendee's feed independently.
Put the vocabulary to work
One API to join, record, stream, and transcribe meetings on Zoom, Google Meet, and Microsoft Teams.