SIP-Native Bots or WebSocket Bots: How to Choose, and Why We Support Both

There are two ways to get a live phone call into a Voice AI agent, and teams usually pick one by accident — whichever their AI vendor’s quickstart happened to use.

It is worth a deliberate decision, because the two shapes put the work in different places. One puts your process in the media path. The other keeps you out of it entirely and asks you to speak telephony instead.

This post compares them on the criteria that actually decide it: latency, audio handling, operational burden, leanness, and compliance. On most of those the answer is “it depends on your team”. On one of them — the signal your model actually receives — there is a clear winner, and it is worth knowing which before you commit.

The two shapes

WebSocket (the AgentStream media path). We answer the phone call, then open a wss:// connection to an endpoint you run and stream audio as JSON events carrying base64-encoded PCM. Your process sits in the media path. Every frame passes through code you deploy.

SIP-native. Your AI platform is itself a SIP endpoint. We hand it the call over a SIP trunk and media flows as RTP. Your application never touches audio — it configures a trunk, then talks to its AI platform’s own API.

WebSocket:  PSTN → Exotel → wss:// → your process → your model
SIP-native: PSTN → Exotel → SIP/RTP → your AI platform (which owns media) → your model

The distinction is not really about protocols. It is about who owns the media stack. On the WebSocket path, you do. On the SIP path, someone else already did.

What each path actually asks of you

This is where the choice gets real, so here are the concrete requirements rather than a feature list.

	WebSocket bot	SIP-native bot
What you stand up	A `wss://` endpoint that accepts our connection	A SIP endpoint, or a platform that is one
Network	Outbound TLS. One port	SIP signalling on TCP 5070 (the India default) or TLS 443, plus RTP/SRTP on UDP 10000–40000 open to us
Codec	Not your problem — you request 8, 16 or 24 kHz and we convert	G.711 A-law (PCMA) is required in India. A mismatch is rejected with SIP 415
Authentication	IP allow-list, Basic auth, or both	IP allow-list at the edge, or credential-based SIP Digest with optional FQDN binding
Rate limiting you will meet	Account concurrency	CPS limit returns 429; channel limit returns 603
Failure vocabulary	WebSocket close codes plus stream outcome fields	SIP responses: 403 allow-list, 404 wrong URI or trunk, 415 codec, 429 CPS, 486 channel, 480 your endpoint unreachable, 503 our side
Where audio problems show up	Your process metrics and logs	Your platform’s session records and SIP signalling

The UDP range is the line item people underestimate. Opening 30,000 UDP ports to a third party is a conversation with a security team, and in some organisations that conversation takes longer than the entire bot build.

Latency

SIP-native does less work per packet, so it adds less. That is the honest shape of the answer.

On the WebSocket path, each frame is read from the phone side, optionally resampled, base64-encoded, wrapped in a JSON event and written to a socket — then the reverse on the way back, re-paced into 20 ms chunks. On the SIP path media stays RTP end to end. It passes through our media proxy, but it is never re-framed into a different transport, and there is no base64 step.

We publish a figure for the WebSocket frame path: audio moves in 320-byte chunks of 16-bit PCM at 8 kHz — exactly 20 ms per frame — in both directions, and our added handling on that path is under 20 ms one-way. We are not going to publish a competing number for SIP, because we have not measured the two under identical conditions in a way we would want quoted. What we will say is the direction: fewer transformations means less added time, and RTP is the transport real-time media was designed for.

But this is rarely the segment that decides how your bot feels. Two things usually dominate it:

Your model’s inference time, which is identical on both paths.
On the WebSocket path, your own process. Your event loop, your scheduling, your garbage-collection pauses. A GC pause in your worker is indistinguishable from network latency to the caller. On the SIP path that variable belongs to your AI platform, whose media stack is probably better tuned than a first-pass bot process — that is the strongest latency argument for going SIP-native, and note that it is an argument about your code rather than about the protocol.

If you want to compare the two, measure mouth-to-ear with your real model on both. Any other comparison is measuring the wrong thing.

Audio and media handling

This is the section where the two paths differ most, and where the SIP story is usually oversold — including by us, in an earlier draft of this post.

Sample rate: neither path is wideband on a PSTN call

Our SIP trunks require G.711 A-law, which is 8 kHz. The phone leg on the WebSocket path is 8 kHz too. If you ask us for a 16 or 24 kHz WebSocket stream we upsample from 8 kHz, which gives your model the input format it wants without adding acoustic detail the call never carried. Wideband codecs like Opus appear on IP-originated legs such as WhatsApp calling, where we transcode to and from the narrowband side — they are not available on a PSTN call.

Bit depth: the WebSocket path is better, and this part is real

Sample rate is not the only axis, and on the other one the paths are not equal.

WebSocket carries 16-bit linear PCM — the format RTP calls L16. Every sample is a plain signed 16-bit value.
SIP carries G.711 A-law: 8 bits per sample, logarithmically companded. A-law squeezes roughly 13 bits of dynamic range into 8 by spending resolution unevenly across the amplitude range, and that compression is lossy in a way that adds quantisation noise.

At the same 8 kHz sample rate, 16-bit linear is the better signal. So if you are running your own ASR or a speech-to-speech model and you care about the cleanest input you can get from a phone call, the WebSocket path hands it to you directly.

The honest caveat: the PSTN leg itself usually carries G.711, so the audio has often already been through companding before it reaches us. Delivering linear PCM avoids another lossy conversion and gives your model linear samples directly — it does not undo what the carrier already did. The gain is real but bounded, and you should expect it to matter more for marginal recognition cases than for clean speech.

Who has to build a media pipeline

This is the part that decides the section, and it is asymmetric.

Speech models do not consume A-law. ASR front-ends and speech-to-speech stacks want linear PCM at their own sample rate. So on the SIP path, something between the trunk and the model has to:

Terminate RTP, and SRTP if you are encrypting
Run a jitter buffer, and handle packet loss and reordering
Decode A-law to linear PCM
Resample 8 kHz up to whatever your model expects
Do the reverse for TTS output — resample down, encode to A-law, and re-pace into RTP at the right interval
Scale all of the above per concurrent call, and stay up

On the WebSocket path, steps 1 through 5 do not exist for you. You receive 16-bit linear PCM at the rate you asked for, base64-encoded in a JSON event, and you send audio back the same way.

Who owns those steps on the SIP path depends entirely on your AI platform, and this is the distinction an earlier version of this post glossed:

If your platform is genuinely SIP-native — LiveKit, ElevenLabs Agents and similar — it has already built all six. You inherit a solved media pipeline and write nothing.
If you would be building the SIP endpoint yourself, you own all six. That is strictly more media engineering than the WebSocket path asks of you, plus servers to run it on, plus the transcoding cost per concurrent call. Teams sometimes choose SIP believing it is the “lower level, therefore leaner” option and discover they have signed up to build a media server.

So on media handling specifically: WebSocket asks less of you and gives your model a better signal. SIP asks more, unless somebody else already did the work.

Failure character

	WebSocket	SIP-native
Format delivered	16-bit linear PCM at 8, 16 or 24 kHz, your choice	8-bit A-law at 8 kHz
Who decodes and resamples	We do	You, or your platform
Transformations per frame	Resample, base64, JSON framing, re-pacing	RTP through a media proxy; then A-law decode and resample on your side
Failure mode to design for	A resample can fail under CPU pressure and you receive the original 8 kHz	Codec mismatch is rejected outright with SIP 415 — it fails at setup, not mid-call

That last row is a real difference in character. SIP fails loudly at call setup; WebSocket degrades quietly mid-call. A codec mismatch never reaches production because nothing connects. A silent rate fallback under load does reach production, and shows up as a quality complaint three weeks later.

For interruption handling the WebSocket path gives you explicit primitives — barge-in, playback marks that tell you what the caller actually heard, and DTMF on the same session. On the SIP path those semantics belong to your AI platform, and how good they are is a question about that platform rather than about us.

Operational burden

Both paths carry real cost. The difference is when you pay it.

SIP-native is front-loaded — and larger than it looks if you are building the endpoint. Firewall rules, the UDP range, codec agreement, trunk authentication, IP allow-listing, and learning a SIP error vocabulary. That work is unfamiliar to most web teams and it is genuinely annoying. Then it is largely done: a trunk that works on Tuesday works on Friday, and your deploys do not touch it.

But if you are not sitting behind a platform that already terminates media, add the media pipeline from the section above — RTP and SRTP termination, jitter buffering, A-law decode, resampling both ways, and servers to run it on that scale with concurrency. That is not configuration. That is a service you now operate, with its own capacity planning and its own on-call.

WebSocket is continuous. No firewall project, and a first call inside an afternoon. But your process is now carrying live audio forever, which means:

Every deploy is an audio-quality decision. A rolling restart that drops sockets mid-call is a dropped conversation, not a retried request. You need connection draining, and you need to rehearse it.
Idle timeouts must exceed your maximum call length, or a quiet stretch mid-call looks idle to a load balancer and gets reaped.
The accept path must stay warm. We connect at call time, so cold-start latency lands in the caller’s first seconds.
The read loop must never block on a model call, or inference latency becomes missed interrupts.
Your runtime’s performance is now telephony performance. CPU saturation and GC pauses are audio artefacts.

Neither is lighter overall. One is a networking project you finish; the other is an operational discipline you keep.

Which is leaner?

The lean path is the one that matches the team you already have. There is no general answer, and anyone offering one is selling something.

SIP-native is leaner when — and only when — your AI platform already terminates media. LiveKit, ElevenLabs Agents and similar have built the RTP handling, the jitter buffer, the codec work and the resampling. You write no media code at all: you configure a trunk, point it at the platform, and your entire integration is configuration. For a small team shipping on a platform that has already solved media, this is the shortest path in this whole post.

If you would be writing the SIP endpoint yourself, SIP is not the lean option. It is more media engineering than the WebSocket path, not less. The word “native” makes it sound closer to the metal and therefore simpler; what it actually means is that more of the media stack is yours.

WebSocket is leaner when you already run a service and your team writes application code rather than telephony config. You need one TLS endpoint: no UDP range, no codec negotiation, no security review of a port range. If you are building a custom STT-to-LLM-to-TTS pipeline you were going to own the media loop regardless, and SIP would add a layer between you and audio you need to touch.

Put plainly: if someone else has already built your media stack, use SIP and inherit it. If you are building it anyway, use WebSocket and skip the middle layer.

Compliance

The honest answer is that the transport does not determine compliance, and claims otherwise deserve suspicion.

What is identical on both paths: the phone leg runs on our UL-VNO licence across 11 telecom circles, under TRAI and DoT obligations, with India-resident media for Indian workloads. Which calling-line series you may use — 140 for promotional, 1600 or 1601 for service and transactional — is a property of the call, not the transport.

What actually differs is where media terminates. Residency covers the telephony side and stops at the far end of your integration:

On the WebSocket path, that far end is your endpoint. You choose the region, so you control it.
On the SIP-native path, that far end is your AI platform. Many are multi-tenant SaaS hosted outside India, and a SIP trunk to a platform in another region carries Indian call audio across a border on every packet, however Indian the telephony underneath is.

That is the one compliance asymmetry worth planning around, and it favours WebSocket only because it puts the decision in your hands. A SIP-native platform with an Indian region is equally fine. A WebSocket bot you deployed in Virginia is equally not.

For encryption both support enterprise defaults — TLS and SRTP on the SIP side, TLS with authenticated WebSockets on the other. For audit both produce call and stream records you can correlate on the call identifier.

If your calls are regulated, the question to ask your AI vendor is not “do you support SIP or WebSocket” but “in which region does your inference run, and what is your retention default.” That answer matters more than the transport.

Choosing

If this is true of you	Choose
Your AI platform is already a SIP endpoint	SIP-native. Do not rebuild what it has
You are building a custom STT-to-LLM-to-TTS pipeline	WebSocket. You need frame-level access anyway, and you get linear PCM at your model’s rate without building a media pipeline
You would have to write the SIP endpoint yourself	WebSocket. Otherwise you are signing up to build and operate a media server
You care about the cleanest signal your model can get from a phone call	WebSocket. 16-bit linear PCM rather than 8-bit A-law
An existing PBX runs the floor	SIP, via StreamKit — the PBX stays and the bot becomes another SIP endpoint
You need per-call routing decided from call context	WebSocket. A per-call stream URL is part of that path; on SIP, routing is trunk configuration
Opening a 30,000-port UDP range means a six-week security review	WebSocket. Be realistic about this one
Your team knows telephony and not much about running services	SIP-native
Your team runs services and has never configured a trunk	WebSocket
You need fast transfer to a human agent with context	SIP, where transfer is native to the protocol and carries headers
Regulated calls, and your AI vendor has no Indian region	WebSocket, so you control where media lands
You want the shortest path to a first working call	WebSocket. An afternoon, versus a firewall ticket

Two things that are not good reasons to choose: the protocol your AI vendor’s tutorial used, and a latency number from a comparison table. Both lead teams to the wrong shape.

Why we support both

We could have picked one. Plenty of platforms did, and it makes the product simpler to explain.

We support both because the customers are genuinely different, and neither group is a subset of the other. One group owns its agent runtime and wants the audio frames — custom pipelines, multi-tenant Voice AI platforms, teams doing something specific with interruption handling. Telling them to go through SIP puts a layer between them and the thing they are building. The other group has an AI platform that already terminates media, or a contact centre that already runs on SIP, and asking them to write a WebSocket media bridge is asking them to rebuild solved infrastructure and then operate it.

Supporting one path would have meant telling half our customers that their existing architecture was wrong. The telephony underneath is the same either way — same licence, same numbers, same residency, same multi-operator failover — so the transport should be the customer’s decision rather than a constraint we impose.

It is also why the choice is reversible. Both paths sit on the same telephony, so moving between them is an integration change rather than a migration. If you pick wrong, you have not stranded anything.

In short

There is no better path. There is a path that matches your team and one that fights it.

SIP-native does less work per packet, fails loudly at setup, and is close to free if your AI platform already terminates media — at the cost of a networking project and less direct control. If it does not, SIP hands you a media server to build and operate, and it stops being the lean choice.

WebSocket gets you a working call this afternoon, hands you 16-bit linear PCM at your model’s rate with no pipeline of your own, and gives you frame-level control — at the cost of owning a real-time media process forever, including on deploy day.

Neither is wideband on an Indian PSTN call. On bit depth the WebSocket path is genuinely better, bounded by what the carrier already did to the signal. Neither is more compliant than the other; where your inference runs decides that. And both run on the same licensed telephony underneath, which is the point.

SIP-Native vs WebSocket Voice AI Bots | Exotel AgentStream