OpenAI opens outbound SIP calling to all organizations for GPT-Live voice agents

What happened

Outbound SIP calling is now available to every organization using OpenAI's Live API, according to the company's developer documentation, a change that drew attention after the page reached the front page of Hacker News. The capability lets GPT-Live voice agents place calls to ordinary phone numbers through a standard SIP trunking provider — Twilio is the example OpenAI gives. The provider bridges the agent onto the public phone network, OpenAI exchanges the call audio, and the developer's backend handles session configuration, call control and business logic.

The documentation is explicit that outbound dialing lives in the Live API rather than the Realtime API call-creation endpoint, so integrations built on Realtime cannot simply redirect their existing call setup.

How outbound calls work

A call begins with a POST request to the session-creation endpoint carrying transport.type: "sip" and a trunk configuration. The destination must be an E.164-formatted phone number; SIP URI destinations are not supported. The trunk block specifies the provider endpoint, which must use the sips: scheme for TLS signaling (5061 is the default port), digest authentication credentials, and the caller number to present, also in E.164 format.

OpenAI sets several constraints. The trunk must support TLS signaling and SDES-SRTP media, with SRTP enabled in the provider's settings before the first call is placed. Provider endpoints using local hostnames or literal private IP addresses are rejected. API keys and SIP credentials are expected to remain on the server.

A 200 response only confirms the session initialized. OpenAI notes it does not indicate the call was answered and contains no SDP or trunk credentials. Unlike the inbound flow, outbound calls require no incoming-call webhook and no accept step.

Inbound calls and live call control

For inbound traffic, a project points its provider's trunk at OpenAI's SIP address, with a separate endpoint for European data residency. An incoming call triggers a live.transport.incoming webhook containing a session ID and SIP headers; the backend then decides whether to accept or reject. Acceptance is an authenticated request carrying the session configuration — model, voice and delegation mode — while rejection passes a SIP status code between 300 and 699, such as 486 for busy. The first decision wins, and a competing later decision returns an error.

Once a call is live, the backend attaches over a sideband WebSocket to receive transcripts, handle delegated work, send commands and read reflected audio, while SIP carries the conversation itself. Call controls support sending keypad tones, transferring the call and hanging up. OpenAI warns that older integrations may still receive the deprecated live.call.incoming event during migration, and advises handling both event names until legacy deliveries and retries drain.

Security posture

Signaling runs over TLS and call audio requires SRTP. Webhook deliveries include signature, timestamp and ID headers for verification and deduplication. OpenAI tells developers to treat SIP headers as untrusted caller metadata rather than authorization, and to assign exactly one handler to each action so duplicate webhook deliveries or events observed across multiple connections never execute a tool twice.

Why it matters

Until now, putting a voice agent on the telephone network usually meant assembling your own stack: a speech model, a WebRTC-to-telephony bridge, transcription and tool plumbing. By speaking SIP natively, the Live API plugs directly into infrastructure that contact centers and telecom teams already operate. Any organization with a compatible trunk can route calls to and from a GPT-Live agent while keeping sensitive logic and credentials in its own backend, and the outbound side opens use cases like scheduled reminders, callbacks and proactive outreach.

The same accessibility cuts both ways. Making automated outbound voice calls as simple as one API request will intensify existing concerns around consent, spam and caller-ID trust, and organizations adopting the feature will be operating under telecom regulations that predate AI callers. For developers, though, the practical takeaway is simpler: the phone network is now just another transport option for the Live API.