Voice Agents That Call the Phone Network: SIP and the Realtime API for Support Skills

Most of the excitement around OpenAI's July 2026 voice releases is about the app. GPT-Live became the default voice experience for ChatGPT on July 8, and it's a genuinely better conversation partner — full-duplex, interruptible, backchanneling. But the app is a walled garden: it talks to the person holding the phone.

The more consequential surface for builders is quieter and older. The Realtime API — where OpenAI shipped gpt-realtime-2.1 and -2.1-mini on July 6 — documents a SIP telephony connection path. SIP is the protocol the phone network runs on. A voice agent that can speak SIP is no longer confined to an app. It can answer a phone number and it can place a call.

That's a different class of skill. An in-app assistant waits to be opened. A telephony agent sits on a number, takes inbound calls, and — with the right authorization — dials out. For support, scheduling, and reminders, that's the whole ballgame. This piece covers the architecture, the use cases, and the parts that will bite you if you're careless.

Key Takeaways

• SIP is the bridge to the real phone network. The Realtime API documents SIP as a connection path, and phone calling was part of the original gpt-realtime GA (Aug–Sep 2025). Your voice skill can take and place actual calls.
• Full-duplex matters more on the phone, not less. Callers interrupt, talk over hold music, and expect backchannels. GPT-Live-style listen-and-speak behavior is what makes a phone agent tolerable.
• The latency budget is stricter over telephony. Phone audio adds its own delay; the 25% p95 latency cut in gpt-realtime-2.1 and cached-audio economics are load-bearing here.
• Tools and MCP are what make it useful. A support agent that can't look up an order is a voicemail. Function calling over live voice turns it into an actual agent.
• Outbound calling is where the cautions live. Consent, identification, and safety guardrails aren't optional — they're the difference between a support skill and a nuisance.

The architecture, end to end

A phone-answering voice skill on the Realtime API has four moving parts. Understanding the boundaries between them is most of the battle.

[ Phone network ]
       │  SIP trunk (from a telephony provider)
       ▼
[ Your media/session layer ]  ── connects the call's audio to the model
       │  Realtime API session (gpt-realtime-2.1)
       ▼
[ The voice model ]  ── full-duplex speech-to-speech, decides speak/listen/call-tool
       │  function calls / MCP
       ▼
[ Your backend + tools ]  ── order lookups, CRM, scheduling, knowledge base

1. The SIP trunk. A number and a route into the phone network, from a telephony provider. This is the part OpenAI doesn't give you — you bring a carrier. SIP is the documented path for connecting that trunk to a Realtime session.
2. The session layer. Bridges the call's audio stream to the Realtime API and holds session state — who's calling, why, where they are in the flow.
3. The voice model. gpt-realtime-2.1 (or the cheaper mini), running the full-duplex loop: deciding many times per second whether to speak, listen, pause, interrupt, or call a tool.
4. Your tools. Functions and MCP servers the agent calls to actually do things — the difference between a chatbot on a phone and a support agent.

The elegant part: layers 3 and 4 are the same components you'd use for an in-app voice skill. The phone is just a different pipe into the front. A support skill you built for the web can answer a phone number by swapping the media layer — the tools, the reasoning, the MCP servers all carry over.

Why full-duplex is the unlock for phone support

Phone calls are the most interruption-heavy medium there is. People talk over each other, jump in with account numbers before you finish asking, and correct you mid-sentence. The old turn-taking pipeline — transcribe, think, synthesize — was miserable on the phone precisely because it couldn't handle that. You'd finish your sentence, wait, and then the agent would start talking as you started talking, and both of you would stop.

GPT-Live's full-duplex behavior — listen and speak at once, backchannel on pauses, yield instantly to interruptions — is exactly the medicine for phone support. The same gpt-realtime primitives are available to build on. A phone agent that says "mhmm" while the caller reads out an order number, and stops the instant they cut in, feels like a competent human. One that plows ahead feels like the IVR everyone hates. The interruptions-and-backchannels UX patterns apply directly — arguably more urgently — to telephony.

Use cases that fit the phone

Not every voice skill belongs on a phone number. The ones that do share a trait: the phone is where the user already is, not an app you're asking them to install.

• Inbound support triage. The agent answers, identifies the caller's issue, looks up their account via a tool call, resolves the simple cases, and hands off the hard ones. Full-duplex means it can take an interruption ("no, the other order") without derailing.
• Outbound reminders and confirmations. Appointment confirmations, delivery windows, "your prescription is ready." Short, scripted, high-volume — and the place where consent rules matter most.
• After-hours coverage. A number that's always answered, that can handle the routine and escalate the rest, without a night shift.
• Callback handling. The agent places the return call, re-establishes context from the earlier session, and continues.

For each, the agent's value is the tool layer. A support call is only useful if the agent can look something up — which means function calling over live voice, covered in the function-calling deep dive, is non-negotiable.

The latency problem gets worse on the phone

Telephony adds delay the app doesn't have — the trunk, the codec, the carrier hops. That eats into whatever conversational latency budget you had. This is why the gpt-realtime-2.1 release matters here specifically: OpenAI reports a p95 voice latency cut of at least 25% from improved caching, and on a phone call, every one of those milliseconds is one the caller spends wondering if the line dropped.

Caching economics compound it. On the Realtime stack, cached audio input runs around $0.30 per 1M tokens versus roughly $10 per 1M for fresh — a ~30x difference. For a high-volume phone agent taking, say, hundreds of calls a day, whether your session reuses cached context or re-sends it fresh is both a latency decision and a cost decision. Design your session layer to keep the cache warm. The full latency budget breakdown is worth reading before you put a skill on a real number.

The cautions — read before you dial out

Inbound is relatively safe: someone called you. Outbound is where a support skill becomes a liability if you're sloppy. Some hard rules:

• Identify the agent as an agent. OpenAI's own voice safeguards block impersonation and cloning, and they use predefined voices only for a reason. Your phone agent should never pretend to be a specific human. Say it's an automated assistant.
• Get consent for outbound calls. Placing calls to people who didn't ask for them is a legal and reputational minefield that varies by jurisdiction. Consent and opt-out are your responsibility, not the model's.
• Build the escalation path first. A support agent that can't hand a distressed or stuck caller to a human is worse than no agent. Design the handoff before the happy path.
• Respect the safety guardrails end to end. Teen-appropriate responses and self-harm resources are built into the consumer stack; a phone agent handling the public needs the same care. The voice-safety and compliance checklist is the publishing gate.
• Log for accountability. Real calls to real people need a record — what was said, what tools were called, how it resolved.

None of these are model features you toggle on. They're your obligations as the builder, and they're the reason a telephony skill is a bigger commitment than an in-app one.

Where this goes next

SIP is not new — phone calling was in the original gpt-realtime GA back in 2025. What's new is that the model on the other end of the line is now full-duplex, low-latency, and tool-wielding. That combination is what finally makes an AI phone agent feel less like an IVR and more like a competent front desk.

If you're building support automation, the phone is the highest-leverage surface you can reach — it's where your users already are, no install required. Start with inbound triage where consent is a non-issue, wire in the tools that make it actually resolve calls, and treat the latency budget and the safety cautions as first-class design constraints, not afterthoughts. When it's ready, telephony support skills fit naturally in the agents and workflows channels, and the rest of the ChatGPT Voice series covers the pieces that plug into them.