Real phone calls, answered and placed by a conversational AI.
Bridge the two sockets and stay out of the way. Twilio opens a Media Streams connection carrying the caller's audio, the bridge authenticates a conversational AI session with a signed URL, and relays audio frames in both directions. Prompt, opening line and language are set per call.
Very little, deliberately. It accepts Twilio's media-stream socket, opens an authenticated session with the conversational AI, and passes audio frames between them in both directions.
Keeping it thin is the design. Every millisecond of processing inserted into a live call is a millisecond of awkward silence, and a phone conversation has a much lower tolerance for latency than a chat interface. The bridge relays; it does not think.
Because a socket endpoint that anyone can connect to is a bill waiting to happen, and a voice agent session costs real money per minute.
A signed URL scopes authorisation to one session, so a connection has to have been issued rather than merely discovered.
The caller talks over the agent, and the agent stops. That behaviour is what separates a conversation from a voicemail system, and people do it constantly without noticing.
Handling barge-in properly means tracking call state through its start, media and stop events so the bridge knows what is currently playing and can cut it.
Prompt, first message and language, plus dynamic variables passed in at session open. The same deployment can answer as a clinic in one call and a dealership in the next.
That is what makes the bridge reusable rather than a single-purpose bot. The behaviour lives in the session configuration, not in the code.
A campaign runner places the call through Twilio's REST API, and once it connects it becomes the same media stream the inbound path already handles.
Seven reference variants shipped with it, covering inbound answering, outbound campaigns and automation flows, so a new use case starts from a working example rather than from scratch.
A real-time telephony bridge shipped with seven reference variants covering inbound, outbound and automation flows.
| Telephony | Twilio voice webhooks and REST |
|---|---|
| Transport | Twilio Media Streams, bidirectional |
| AI session | ElevenLabs conversational AI over WebSocket |
| Authentication | Signed URL per session |
| Bridge role | Frame relay only, kept deliberately thin |
| Interruption | Barge-in handled via call state tracking |
| Per-call config | Prompt, first message, language, dynamic variables |
| Directions | Inbound answering and outbound campaigns |
| Shipped with | Seven reference flow variants |
Have TwiML open a Media Streams socket on the call, then run a bridge that authenticates a session with the AI provider and relays audio frames in both directions. The bridge should stay thin, because any processing added in the middle becomes audible latency in a live conversation.
Letting the caller interrupt and having the agent stop talking immediately. People do this constantly in real conversation without thinking about it, and an agent that talks over an interruption stops feeling like a conversation. It requires tracking call state so the bridge knows what is currently playing.
Yes, if the behaviour lives in the session rather than the code. Prompt, opening message, language and dynamic variables are all set per call here, so the same deployment can answer as one business on one call and another on the next.
Because an open socket endpoint is a cost exposure. Voice agent sessions bill per minute, so an endpoint anyone can connect to is a bill anyone can run up. A signed URL scopes authorisation to a single session that had to be issued rather than found.
Retrieval-augmented generation, built from the ground up.