Skip to main content

Resource — Integration

Routing Twilio calls to Vapi with a reliable, measurable transport path.

Twilio is one of the most common SIP carriers for AI voice deployments. Vapi is a widely used AI voice agent platform. Connecting the two through a clean, instrumented transport layer changes how you debug, scale, and optimize the integration.

The integration pattern

Twilio receives the inbound PSTN call and forwards via SIP trunk to Telepath. Telepath terminates SIP/RTP, transcodes to PCM16, and streams audio to Vapi over WebSocket. Agent audio returns the same path in reverse.

What breaks without a clean bridge

Direct Twilio-to-Vapi integrations using TwiML <Stream> introduce Twilio’s own media relay into the path. Latency variability is harder to attribute, and there is no per-call diagnostic layer separating Twilio-side from Vapi-side behavior.

What Telepath adds

A single, owned transport boundary with per-call SIP timing, RTP quality metrics, gateway processing latency, and Vapi-side TTFS attribution — all accessible from the same dashboard view.

Understanding the Twilio–Vapi call path

When a caller dials a Twilio number pointed at a Vapi AI agent, several distinct layers of infrastructure are handling the call. Understanding where each one sits helps you optimize and debug the right layer when something goes wrong.

Twilio’s media handling

Twilio operates PSTN origination, number management, and a SIP trunk layer. When using Twilio’s <Stream> TwiML verb to forward media to a WebSocket endpoint, Twilio introduces its own media relay servers. These servers are regionally distributed, but the routing of your specific call to a specific media server is not transparent. This means that when you observe latency variability on Twilio-to-Vapi calls, you cannot easily tell whether the variability is coming from Twilio’s media relay, the network between Twilio and Vapi, or Vapi’s own model inference. All of that delay appears in aggregate as TTFS.

Forwarding via SIP trunk instead

An alternative is to configure Twilio to forward calls via SIP trunk directly to Telepath’s SIP endpoint. Twilio sends a standard SIP INVITE with RTP media to Telepath, which terminates the call and bridges it to Vapi over WebSocket. This approach bypasses Twilio’s <Stream> relay entirely, and the transport boundary becomes explicit and measurable. You can see Twilio-side setup timing (SIP INVITE to 200 OK), Telepath gateway processing (~12ms), and Vapi-side TTFS as separate instrumented values rather than an opaque aggregate.

Common issues in Twilio-to-Vapi deployments

The most common production issues teams encounter are: (1) inconsistent first-response latency that is difficult to attribute to Twilio vs. Vapi vs. model; (2) audio quality degradation on calls from certain geographic regions, caused by a mismatch between where Twilio routes the call and where Vapi’s inference runs; (3) dropped calls during high-concurrency periods where Twilio SIP trunking concurrency limits are hit without warning; and (4) DTMF events not reaching the agent correctly because the Twilio <Stream> path does not forward RFC 2833 DTMF packets. Telepath handles DTMF forwarding correctly and surfaces concurrency metrics per call session.

Scaling considerations

At low call volumes, Twilio-to-Vapi integrations generally work. At higher concurrency — dozens to hundreds of simultaneous calls — the operational requirements change. You need to understand your concurrency headroom on both sides, monitor per-call quality at scale rather than sampling, and have carrier-level attribution when Twilio makes infrastructure changes that affect your call quality. Telepath provides aggregate analytics across carrier, gateway, and agent layers so you can monitor at scale rather than debugging individual complaints reactively.

Keep your Twilio numbers

No number porting required. Your Twilio DID inventory, account, and billing relationship stays intact. Telepath sits in the call path without requiring any Twilio account changes beyond a SIP trunk configuration.

Keep your Vapi agents

Vapi agents continue to receive audio over WebSocket exactly as before. No changes to your Vapi configuration, prompts, or model settings are required to use Telepath as the transport layer.

Gain attribution

Every call produces a structured record with Twilio-side SIP timing, Telepath gateway performance, and Vapi-side responsiveness. When a call sounds bad, you know which layer to look at first.

Connect your Twilio trunk to Vapi in minutes.

Telepath’s quickstart covers SIP trunk configuration, WebSocket endpoint setup, and per-call diagnostics. You can have a working Twilio–Telepath–Vapi path running before end of day.