OpenAI Realtime API: Native SIP vs WebSocket Bridge for Phone Systems

Quick Answer

OpenAI Realtime SIP support means a SIP trunk can now dial directly into an OpenAI-hosted endpoint — no intermediary telephony server required — at roughly 250–350ms latency. This is the fastest path to a working phone-based AI voice agent. CelloIP's existing FreeSWITCH + OpenAI Realtime WebSocket bridge remains the better choice whenever you need existing IVR integration, compliance-controlled recording, multi-vendor LLM routing, or CDR/billing tied into infrastructure you already run. The rest of this guide walks through both in enough depth to make that call for your own deployment, not just take our word for it.

Why This Decision Matters More Than It First Appears

It's tempting to treat "native SIP vs bridge" as purely a latency question, since that's the number most benchmarks lead with. In our experience building both for clients, latency is rarely the deciding factor — the two approaches perform similarly enough in practice that a 50–100ms difference gets lost in normal network jitter. The decision that actually matters is architectural lock-in: native SIP hands the entire call to OpenAI's platform, which is simple until you need something OpenAI's session configuration doesn't expose — a specific compliance workflow, a transfer to a legacy call center, a requirement to route certain calls to a different LLM vendor entirely. A self-hosted bridge costs more upfront in engineering time but keeps every one of those doors open, because the call never leaves infrastructure you control until you decide to send it to OpenAI. Choosing between them is really a choice about how much of your call-handling logic you're willing to hand to a third party permanently, not a choice about which one sounds slightly faster in a demo.

What Changed: Native SIP on the Realtime API

Until recently, connecting a phone call to OpenAI's Realtime API required a telephony server (Asterisk, FreeSWITCH, or Twilio) to terminate the SIP/PSTN call and relay audio to OpenAI over a WebSocket — the approach CelloIP documented in our FreeSWITCH + OpenAI Realtime contact center guide. OpenAI now accepts SIP connections directly, meaning a SIP trunk provider can route calls straight to an OpenAI-hosted SIP endpoint with no self-managed telephony layer in between.

Architecture Comparison

The diagram below makes the structural difference concrete: native SIP is a two-hop path (SIP trunk to OpenAI), while the self-hosted bridge is a three-hop path (SIP trunk to your telephony server to OpenAI) with your own infrastructure sitting in the middle. That extra hop is exactly what buys back dialplan control, compliance-grade recording, and multi-vendor routing — and exactly what adds an operational component you now own.

Setting Up Native SIP

Native SIP setup is deliberately minimal by design. You configure your SIP trunk provider (or existing SBC) to route a chosen DID directly to the SIP URI OpenAI provisions for your Realtime API project, authenticate using the credentials tied to your OpenAI account, and define the agent's behavior (system instructions, voice, tools) through the Realtime API's session configuration rather than through any telephony-side dialplan. There is no dialplan to write, no media server to size, and no TURN/STUN or RTP port range to open on a firewall — the entire call-handling surface lives on OpenAI's side of the connection. This is genuinely the fastest way to get a phone number answering with a working AI agent, often inside a single afternoon including SIP trunk provisioning.

The trade-off mirrors the simplicity: because OpenAI terminates the SIP leg directly, you lose the ability to inspect or modify the call before the AI agent takes it. Any pre-call logic — checking a caller ID against a blocklist, playing a compliance disclosure before the AI starts talking, routing VIP callers to a different agent configuration — has to be expressed through whatever OpenAI's Realtime API configuration surface supports, not through arbitrary dialplan logic the way it could on Asterisk or FreeSWITCH.

Setting Up the Self-Hosted Bridge

The self-hosted bridge path — documented in full in our FreeSWITCH + OpenAI Realtime contact center guide — puts a telephony server between the caller and OpenAI. The SIP trunk terminates on FreeSWITCH or Asterisk as it would for any normal call; the dialplan then invokes a WebSocket bridge (via mod_audio_fork on FreeSWITCH, or AudioSocket plus an external bridge process on Asterisk) that relays audio to and from the Realtime API's WebSocket endpoint. Everything that happens before that bridge invocation — IVR menus, caller ID lookups, business-hours routing, compliance announcements — runs in your own dialplan exactly as it does today, with the AI agent slotted in as one possible destination among others rather than owning the entire call.

[ai-agent-with-fallback]
exten => _X.,1,NoOp(Compliance disclosure, then route to AI)
 same => n,Answer()
 same => n,Playback(this-call-may-be-recorded)
 same => n,GotoIf($["${DB(blocklist/${CALLERID(num)})}" = "1"]?reject:continue)
 same => n(continue),Set(UUID=${SHELL(uuidgen)})
 same => n,AudioSocket(${UUID},127.0.0.1:9000)  ; bridges to OpenAI Realtime
 same => n,Hangup()
 same => n(reject),Playback(number-blocked)
 same => n,Hangup()

Security and Compliance Deep Dive

For unregulated consumer use cases, the compliance difference between the two approaches barely matters. It becomes the deciding factor the moment HIPAA, PCI-DSS, or financial-services call-recording obligations apply. With native SIP, call audio and any recording OpenAI performs are governed entirely by OpenAI's own data processing terms — you can review and sign a Business Associate Agreement if OpenAI offers one for your account tier, but you cannot dictate where recordings are stored, how long they're retained, or exactly which systems can access them beyond what OpenAI's platform controls expose. With a self-hosted bridge, call recording happens on infrastructure you operate (Asterisk MixMonitor or FreeSWITCH's record_session), meaning retention period, encryption at rest, and access control are entirely yours to configure and audit — the same posture you'd already have for any existing regulated telephony system.

A second, less obvious compliance dimension is model routing. Some regulated deployments are required to use a specific approved LLM vendor, or to fail over to a secondary vendor if the primary has an outage — a self-hosted bridge can implement that routing logic directly, since the bridge process decides which upstream API to call per session. Native SIP locks you to OpenAI as the sole model provider for that phone number, which is a real constraint if a future compliance or procurement requirement mandates multi-vendor redundancy. Procurement teams at larger enterprises increasingly ask this question during vendor review, well before an engineering team has considered it.

Real Cost Modeling

At 15,000 minutes/month — a realistic small contact-center workload — native SIP costs whatever OpenAI charges per Realtime API minute (check current published rates, since these are model-usage-based rather than a flat telephony fee) plus your SIP trunk provider's per-minute PSTN termination cost, with zero infrastructure spend beyond that. The self-hosted bridge adds a modest FreeSWITCH or Asterisk server (commonly $50–$150/month for this call volume) and the engineering time to build, test, and maintain the bridge process — real cost, but bounded and one-time-ish rather than scaling per minute. Where the self-hosted approach earns back that investment is anywhere the native SIP path would otherwise require an OpenAI feature or configuration option that doesn't exist yet, forcing a workaround or a wait — the bridge gives you an escape hatch native SIP doesn't.

Migration Considerations

Teams sometimes start on native SIP to validate a concept quickly, then need to move to a self-hosted bridge once a compliance or integration requirement surfaces. Plan for this as a real migration, not a configuration toggle: the two approaches have fundamentally different call-control models, so dialplan logic, session configuration, and any tool-calling integrations built against OpenAI's native SIP session format will need to be re-implemented against the bridge's WebSocket session format. Teams that anticipate needing dialplan integration eventually are almost always better served starting with the self-hosted bridge from day one, even though it's slower to stand up, rather than building on native SIP and re-platforming later under time pressure.

When to Use Which

Neither approach is universally correct — the right choice depends on what you already operate and what your compliance and integration requirements demand today, not just at launch. Read both lists below and count which side has more checkmarks for your specific situation; teams that pick based on which one "feels" simpler on day one often end up rebuilding within a year once a real requirement surfaces that their chosen approach can't accommodate.

A Hybrid Pattern: Bridge for Pre-Screening, Native SIP for the Conversation

A pattern we've started using for clients who want native SIP's simplicity but still need a compliance disclosure or basic pre-call routing: terminate the call on a lightweight Asterisk or FreeSWITCH instance just long enough to play a required announcement, check a blocklist, or route by business hours — then, once that pre-screening passes, transfer the call onward to OpenAI's native SIP endpoint for the actual AI conversation, rather than bridging audio through your own server for the entire call. This gets you the minimal compliance/routing control that pure native SIP can't provide, without taking on the full ongoing engineering burden of relaying every audio frame through your own infrastructure for the conversation's duration. It's a reasonable middle ground when your requirements are narrow (one disclosure, one blocklist check) rather than broad (full IVR, multi-vendor LLM routing, call recording under your own control).

Testing and Validating Call Quality

Whichever path you choose, validate it against real phone network conditions before trusting latency numbers from a controlled test. Test from an actual PSTN handset, not a softphone on the same network as your server — mobile carrier networks in particular introduce jitter and packet loss patterns that a wired office test environment won't reproduce. Measure time-to-first-response (from the caller finishing a sentence to the agent's audio starting) across at least a few dozen calls rather than a single sample, since both native SIP and self-hosted bridges show meaningful latency variance run to run — a single fast test call is not evidence of consistent production performance. For the self-hosted bridge specifically, also test what happens under simulated network interruption between your server and OpenAI's WebSocket endpoint, since that's a failure mode native SIP simply doesn't expose you to.

FAQ

The Short Version

If you're validating an idea with no existing telephony stack and no regulatory constraint yet, native SIP gets you to a working demo fastest. If you already run Asterisk or FreeSWITCH, operate in a regulated industry, or can already name an integration requirement native SIP doesn't cover, build the self-hosted bridge — the extra week of engineering is cheaper than a re-platform under deadline pressure six months in. When in doubt, talk through your specific requirements with an engineer who has built both before committing either way.