WebSocket streaming sends data non-stop over one open connection between client and server, live audio and video included.
Either side can push data at any time, with no new HTTP requests.
That makes it the standard way to carry low latency, real-time meeting media.
How WebSocket streaming works
A WebSocket connection starts as a normal HTTP request. That request is then upgraded to a lasting, two-way channel.
Once it is open, client and server can both send messages at any time.
The protocol is a standard one, and browsers and servers support it widely.
It passes through most firewalls, because it starts as HTTP.
MeetStream connects out to you.
You host a secure socket endpoint, name it when you create the bot, and the bot opens the connection as it joins.
A second endpoint carries control commands back to the bot.
That is the pattern behind a bridge server and the voice agents built on it.
The byte layout is on the real-time audio page.
For meeting media, the server pushes a steady run of audio or video frames.
They often arrive as binary messages with timestamps and participant IDs. The client can send control messages back on the same connection.
Why WebSockets suit live media
Meeting audio is a constant flow, rather than a set of single events. A long-lived socket suits that flow best.
An open socket delivers frames as they are made, and keeps them in order.
End-to-end latency stays low, well under a second in most cases.
That is fast enough for transcription, translation and voice agents to respond while people are still speaking.
What you can build on live streams
Live delivery opens up features that run while the meeting is on:
- Real-time transcription and live captions
- Voice agents that listen and respond inside meetings
- Live coaching, alerts and compliance checks
- Sending meeting audio into your own ML pipelines
- Low-latency dashboards showing who is speaking now
What to plan for
Plan for what long-lived connections do in the real world. Reconnect with backoff when the network drops.
Buffer so short gaps do not lose audio. Handle backpressure when your consumer falls behind the stream.
Check the shape of the stream too. Does audio arrive as one mixed feed, or as a separate stream per participant?
Separate streams remove the need for diarization later. Most providers document the message schemas for frames and events. Validate them early.
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. Every frame carries the dominant speaker's ID and name.
After the call you also get separate per-participant audio files, from bots on Zoom, Google Meet, and Microsoft Teams.
That lets real-time agents know both what was said and 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 send each event notice as its own HTTP request.
WebSockets keep one connection open and push a steady flow of data through it. Use webhooks for lifecycle events.
Use WebSockets for media and anything fast-moving.
What latency should I expect from WebSocket media streaming?
A good setup delivers meeting audio in the low hundreds of milliseconds, from spoken word to your app.
Your total latency also includes the work you run after that, such as speech recognition or an LLM reply.
Can WebSockets carry video as well as audio?
Yes. Video frames are just bigger binary payloads, so bandwidth and decoding become the real limits.
Meeting APIs that stream per-participant video let your app handle each attendee's feed on its own.
Put the vocabulary to work
One API to join, record, stream, and transcribe meetings on Zoom, Google Meet, and Microsoft Teams.