What happened
OpenAI’s API documentation for managing GPT-Live sessions lists “Telephony and SIP” among its connection guides. The same documentation directs developers to connection setup and audio-streaming material, as well as separate guides for delegation and backend work. This establishes SIP telephony as a documented connection route in the GPT-Live product surface.
OpenAI describes GPT-Live as full duplex: it can listen and speak at the same time. Its session guide tells builders to track transcript text, played audio, and backend task progress separately, so an interface can show both what the assistant is saying and what work remains in progress. That separation is particularly relevant when the user experience is a live conversation rather than a turn-by-turn chat interface.
The guide says that a team chooses the model, voice, delegation mode, instructions, and relevant prior history when it creates a session. Its examples use gpt-live-1; the default voice is marin. The documentation says model and voice changes require a new session, while a session can receive supported updates to Responses-delegation settings. Instructions can contain up to 16,384 tokens. Startup history accepts up to 128 messages and 8,192 combined tokens, and the guide advises keeping trusted application instructions separate from user messages and factual results.
OpenAI also documents three ways to add information while a conversation runs. session.instructions.append adds trusted application instructions that influence behavior and speech; session.thinking.append adds factual context without asking the model to say it immediately; and session.commentary.append supplies information the model may speak aloud. Each takes plain-string content of up to 500 tokens and a delegation ID. The documentation cautions that the model may respond before it has used all of an update, so an application should verify behavior when an action depends on a new instruction or fact.
For speech handling, OpenAI says transcript deltas include text fragments and approximate intervals on the session timeline. They do not identify a completed conversational turn, so the application determines how fragments are grouped for display. Because caller and assistant speech can overlap, captions should be updated independently. The guide further says that permissions and required confirmations should be enforced in application code, with credentials and secrets retained in the backend. SIP therefore expands the documented transport options; it does not turn the model into a complete, self-governing phone system.
What the archive adds
New Runtime’s earlier coverage on 2026-09-14 described GPT-Live as a duplex API that can listen and speak simultaneously. An earlier New Runtime note on 2026-11-03 covered ChatGPT Voice in Finances (earlier coverage). This is a new integration fact on that broader voice story: the documentation now places SIP telephony in the GPT-Live connection map.
Trend signal
This supports, but does not prove, the assumption that realtime voice models can combine speech, interruptions, tool calls, and session state within one application workflow. It fits generative media becomes application infrastructure: a SIP route makes voice more composable with existing communications systems, while the durable product remains the surrounding application logic.
Why it matters
A phone workflow exposes constraints that a voice demonstration can conceal. Callers interrupt. Transcript fragments may arrive unevenly. A backend lookup can outlast a spoken response. A consequential action may require a clear confirmation, yet a natural-language exchange alone is not a reliable authorization or completion record.
OpenAI’s documentation makes the architectural split explicit: speech, transcript display, and delegated work are distinct streams, and application code owns permissions and confirmations. For a team building with AI, that is the important consequence of telephony connectivity. SIP can widen the places where a GPT-Live agent operates, but it does not eliminate the need for state management, escalation paths, and verification outside the model.
The practical design question is not merely whether an agent can hold a fluent call. It is whether the product can reliably determine what was said, what work is still running, which action is permitted, and what the caller should hear while the system waits. A documented SIP route makes that product work more approachable, not automatic.
Limits and uncertainty
OpenAI’s documentation describes session and integration mechanics, not measured call quality, latency, task-completion rates, or behavior across carrier networks and languages. This Field Note does not independently test a production telephone deployment. A SIP connection alone also does not establish a solution for consent, caller identity, recording, escalation, accessibility, or jurisdiction-specific telephony obligations. Teams should treat the guide as a documented implementation path rather than evidence that a compliant, end-to-end phone agent can be deployed without further engineering and operational review.
Skill to build now
Prototype one narrow phone workflow this week. Connect a SIP call to a GPT-Live session, log caller and assistant transcript fragments separately from backend task state, and test an interruption while a lookup is running. Put an explicit application-side confirmation before any consequential action. This exercises the separation OpenAI documents between spoken output, transcript timing, delegated work, and authorization logic.
Reader takeaway
OpenAI now documents SIP as a connection route for GPT-Live voice applications. That is useful infrastructure for teams bringing realtime agents into phone workflows, but the quality and safety of the resulting product will depend on the application’s call control, task state, verification, and recovery design.