A bridge server is a small service you run between a meeting bot and your own AI session.
The bot sends it live meeting audio on one WebSocket and control commands on another.
The bridge decodes, resamples, filters and forwards that audio.
Your own voice stack can then take part in a real meeting without joining it.
Why two WebSockets
The two carry very different traffic, so MeetStream keeps them apart.
An interrupt lands the instant you send it, instead of queueing behind audio.
That is the difference between stopping on cue and talking over people.
The bridge server guide names each one.
What the bridge does
Four jobs, and the guide ships a working Python skeleton with all four.
You give each bot the two socket URLs at create time.
The rest is WebSocket streaming.
When you do not need one
For a managed version of the same loop, MIA runs it end to end inside MeetStream.
Teams who already own a voice stack keep the bridge and take only the in-meeting part.
Frequently asked questions
Do I need a bridge server for a voice agent?
A bridge is optional, because MIA runs the loop for you.
Teams who already own a voice stack use a bridge to take just the in-meeting part from MeetStream.
What audio format arrives?
48 kHz mono PCM16, little-endian. Every frame carries the speaker ID and name, each with a length prefix.
What sample rate should I send back?
48 kHz PCM16, base64 encoded, on the control socket. The guide shows a 24 kHz model rate being resampled up to it.
How does the bridge avoid hearing itself?
It keeps only the frames from human speakers, matching the bot by its display name.
You can extend the list of names it skips.
Put the vocabulary to work
One API to join, record, stream and transcribe meetings across Zoom, Google Meet and Microsoft Teams.