GPT-Live-1 Can Dial Out Now: What the SIP GA Actually Unlocks, and What It Still Won't Do

The most useful new thing an OpenAI voice agent can do is press 1. Since late on 4 November 2026, a GPT-Live-1 session can place an outbound call to a real telephone number over a SIP trunk, listen to the menu that answers, and send keypad tones back down the line. That last part — bidirectional DTMF — is the difference between a voice agent that talks and a voice agent that can get through a phone tree to the department it actually needs.

The model itself is not new. GPT-Live-1 has been in ChatGPT Voice since 8 July 2026 and in the API since 10 September 2026 at $0.05 a minute. What changed on 4 November is the transport. Justin Uberti of OpenAI announced that the outbound telephony API had been "just promoted … to GA", "allowing developers to make phone calls from their Live voice agent" through "any SIP trunk provider (e.g, Telnyx or Twilio)"; Greg Brockman amplified it the same night. The announcement adds that calls can use HD Voice and can send and receive keypad events.

So this is a capability story, not a model story, and the interesting material is in the documentation rather than the post. OpenAI's Telephony and SIP guide now states that outbound calling is "available to all organizations through the Live API, not the Realtime API call-creation endpoint" — two sentences that quietly rule out a large slice of the integrations people will try to reuse.

What "GA" changed, and what it did not

Before the promotion, outbound calling existed but was not generally available — that is what "promoted" means. The mechanism was already built, and the door opened. OpenAI's documentation now carries the matching sentence, that outbound SIP calling "is available to all organizations through the Live API", which is the closest thing to a GA statement on the page: the guide itself carries no beta, preview or alpha label anywhere.

What did not change is the voice model. The outbound example in OpenAI's own documentation still sets model: "gpt-live-1", and the partner checklist still tells integrators to look for "a package version that supports gpt-live-1". There is no outbound-specific model, no separate price, and no telephony tier. You are paying the same $0.05 a minute for the voice layer that you paid in September; you are simply now allowed to spend it on calls that leave your server.

One operational caveat hides in the guide rather than the announcement: OpenAI tells you to confirm that "GPT-Live SIP support is enabled for your project and that your provider's SIP trunk is routed to that project before using this flow." A GA label and an enabled project setting are not the same thing, and the first support ticket of the week will be someone who has one without the other.

The prerequisites that decide whether your trunk works at all

OpenAI did not adopt SIP in the general sense. It adopted a narrow, modern slice of it, and a trunk that fails any of the following will not connect no matter what the announcement promised about "any SIP trunk provider".

• Signaling — TLS is required, not optional. Plain SIP over UDP or TCP is out.

• Media — SDES-SRTP is required, and SRTP has to be switched on at the provider, not just supported by it.

• Provider URL — a sips: endpoint is expected, defaulting to port 5061, with no credentials, no path, and no URI parameters attached.

• Destination — an E.164 number such as +14155550123 and nothing else. SIP URIs are explicitly unsupported, so an internal extension scheme is not a shortcut.

• Authentication — digest, with a SIP username and password, plus a caller_number in E.164 that becomes the caller ID your callee sees.

• Network hygiene — local hostnames and literal private IP addresses are rejected, which rules out a test rig pointed at a lab box.

• Audio format — leave audio.format unset, because SIP negotiates it. Setting it is the kind of helpful-looking parameter that breaks the call.

Note what this means for the "any provider" claim. Any provider that speaks TLS signaling with SDES-SRTP media will work; a great many cheap SIP trunks still default to UDP and plain RTP, and they are not covered by that sentence. The wiring is a session creation rather than a webhook: you POST to /v1/live/sessions with transport.type set to sip, and the guide is explicit that "you don't need an incoming-call webhook or an accept request for an outbound call."

What you get back is a session.id and a transport type, and the documentation is unusually blunt about the gap between that and reality: "This response doesn't mean the call has been answered." Ringing, answering and failure arrive later as transport.ringing, transport.answered and transport.failed events on a sideband WebSocket at /v1/live/sessions/{session_id}/attach. Attach immediately — only the preceding three seconds of events are replayed — and deduplicate by event_id, because the guide warns that duplicate deliveries are normal.

The envelope: three minutes to ring, two hours to talk

Two hard numbers in the guide will decide which outbound use cases are viable, and neither appeared in the announcement.

• Ringing cap — three minutes. A call that has not been answered by then is over.

• Connected cap — two hours, after which the session ends regardless of what is happening.

• Control surface — transfer via /v1/live/sessions/{id}/refer, hang up via /v1/live/sessions/{id}/hangup, DTMF sent over the sideband with transport.dtmf.send.

• Failure modes — bad session configuration fails loudly at creation, transport setup can return 502, an initialization timeout returns 504, and anything later arrives asynchronously as transport.failed.

The three-minute ring is fine for consumer outbound and awkward for enterprise switchboards that park calls. The two-hour ceiling is generous until you point the agent at a support queue, where a long hold plus a long conversation can plausibly brush against it. Neither limit is a surprise in a real-time voice product; both are the sort of thing you want to know before you promise a customer a campaign SLA.

What a call costs, honestly

OpenAI's pricing page lists GPT-Live-1 voice sessions at $0.05 per minute, "billed per second, without rounding up to a whole minute." That is the whole of the published price, and it is only one of the two bills an outbound call generates. The carrier termination charge is the other, and it depends on destination, volume and which trunk provider you chose. OpenAI keeps audio processing and session logic; the provider owns the PSTN leg.

• A one-minute answered call — $0.050 from OpenAI, plus your carrier's per-minute rate.

• A four-minute call — $0.200 from OpenAI, plus carrier.

• A thousand four-minute calls — 4,000 minutes, so $200 from OpenAI, plus carrier.

• An hour of connected conversation — $3.00 from OpenAI, plus carrier.

Two things about that meter deserve care. First, the billing unit is the session minute, and nothing on the pricing page distinguishes speech from silence, so the seconds your agent spends listening to hold music accrue at the same rate as the seconds it spends talking. Second, the guide does not say whether a call that rings for three minutes and is never answered is a billable session; that is a question worth asking support before you run a dialer at volume, not after.

Backend model and tool usage are billed separately, at whatever model you delegated to. If you route that leg through OrcaRouter, the 0% markup and pass-through pricing apply there rather than to the voice minute — so a provider price cut on the reasoning model shows up on your bill the same day, and a cut on gpt-live-1 does not.

Your Realtime integration will not port over

The single most expensive mistake available this week is assuming that a working Realtime API telephony stack is a working GPT-Live stack. OpenAI's partner page says it plainly: "A Realtime integration is not automatically compatible with GPT-Live." The endpoint is different, the session model is different, delegation is a concept Realtime does not have in the same form, and the audio formats and interruption semantics the guide asks you to check per partner are not carried across.

The partner list also complicates the announcement's phrasing. OpenAI documents LiveKit for voice agents; Twilio Agent Connect for "incoming and outgoing phone calls"; Telnyx for "outbound calling experiences"; Bandwidth for "incoming calls" over SIP; and Daily/Pipecat for the Live service generally. Bandwidth, in other words, is documented as an inbound integration, and LiveKit and Pipecat are documented without a call direction at all. "Any SIP trunk provider" is a statement about protocol compatibility, not a statement about which of OpenAI's five partners has shipped outbound support.

If you are on Twilio, the migration is the one with a documented outbound path today. If you are on Bandwidth for inbound, outbound over that integration is not something the documentation promises yet.

The version question nobody asked

There is a live ambiguity in the name. GPT-Live-1.1 rolled into ChatGPT Voice on 15 October 2026 with new voices across six languages, and OpenAI has still not published a gpt-live-1.1 model id for API callers. Every outbound example in the telephony guide uses gpt-live-1. If a colleague tells you the outbound agent is running 1.1 because that is what ChatGPT uses, they are describing the consumer product, not your session configuration.

Practically: quote gpt-live-1 in your plan, and treat any 1.1 API availability as a separate event to be verified on its own day.

Where the thinking happens, and why it is the lever you control

GPT-Live is split down the middle. The documentation's own summary is that it "delegates reasoning and tool use to a backend while it manages the spoken conversation." The voice layer handles timing, interruptions and prosody; a separate model does the thinking and calls the tools. That backend is configured per session under delegation, in one of two modes.

• Responses delegation — delegation.type: "responses" with a required backend model, plus instructions, tools, tool choice, token limits and service tier. OpenAI's guide recommends starting with gpt-6-luna, or gpt-6-sol for harder work, and notes that "you can choose the Responses model independently of the voice model."

• Client delegation — delegation.type: "client", where your application runs the backend itself. OpenAI's wording is that this permits "any model, agent, or service your application operates."

This is where an outbound agent's cost and quality actually live, and it is the only architectural choice on the page that is genuinely yours. The voice model is fixed and, as it happens, not on OrcaRouter's catalogue — GPT-Live-1 is a telephony front end you buy from OpenAI, and no amount of routing cleverness changes that. The backend is a different matter. Under client delegation it is an ordinary model call your code makes, which means one API for 200+ models, a single key across the vendors you evaluate, automatic failover if a provider degrades mid-campaign, and per-call-type model choice: a cheap model to walk an IVR menu, a stronger one once a human picks up.

Under Responses delegation, OpenAI runs that leg and bills it at its own rates. Both are legitimate; they just put the decision in different places. If you want the backend to be a routing decision, client delegation is the mode that gives it to you.

What the announcement left out

For a GA post, the announcement is thin on the things that decide deployments. It says nothing about regional availability, latency, concurrency limits, or an SLA. It says nothing about recording, disclosure or consent obligations — and outbound calling is the one place in this product where those obligations are not theoretical. In the United States, placing automated calls to consumers without consent is a TCPA problem before it is an engineering problem; in the EU, recording a call without telling the person on the other end is its own problem. The API gives you a caller_number and a hangup endpoint. Compliance is yours.

"HD Voice" is also worth treating as a claim rather than a specification. OpenAI's documentation says only that SIP negotiates the audio format and lists no codecs, so the wideband audio in the post is a vendor statement that has not been quantified anywhere public. Test it against your own carrier before you put it in a deck.

What to do with this, this week

If you already run a GPT-Live voice agent on WebRTC, the outbound path is a second transport rather than a rewrite: a new session created with transport.type: "sip", a trunk that speaks TLS and SDES-SRTP, and a sideband WebSocket to watch for ringing, answering and DTMF. Budget a day for the trunk, not for the agent.

If you are on Realtime, do not schedule the migration on the assumption that it is a configuration change. Read the delegation and session sections first, decide whether your backend should be OpenAI's or yours, and only then pick a partner — because the partner you already use for inbound may not be the one with a documented outbound path.

If you are still deciding whether outbound voice is worth building at all, the number that matters is $3.00 per connected hour before carrier charges, against a two-hour hard cap and a three-minute ring. That is cheap enough to test and expensive enough that hold time is a design decision, not an accident. The GA removed the gate. It did not remove the arithmetic.