Live API outbound SIP calling: dialing real phone numbers with GPT-Live

Until now the Live API's SIP story concentrated on inbound calls: your provider hands a call to OpenAI and you accept or reject it. The official changelog entry dated 2026-11-02 turned the direction around — outbound SIP calling became available to all organizations through the Live API. Your server names a phone number, your own SIP provider carries the phone-network connection, and GPT-Live handles the conversation. Fact sources for this article are the official changelog, the Telephony and SIP guide (fetched as .md full-text variants on 2026-11-09), and the tag sources of both official SDKs; the code samples are reproduced from the official guide (documentation-checked, not executed in a live environment on our side).

1. The announcement and its boundaries

The changelog entry for 2026-11-02 (Feature, labeled Model gpt-live-1 and API v1/live/sessions) reads:

Outbound SIP calling is now available to all organizations through the Live API. Connect GPT-Live to a phone number through your SIP provider.

Two boundaries are worth pinning down first. First, outbound calls are offered only through the Live API — the guide's Place an outbound call section states "Outbound SIP calling is available to all organizations through the Live API, not the Realtime API call-creation endpoint," so the Realtime API call-creation endpoint is not part of this outbound path. Second, pricing: the official pricing page (fetched 2026-11-09) lists gpt-live-1 voice sessions at $0.05 per minute, billed per second without rounding up to a whole minute, with backend model and tool usage charged separately.

Status anchor: as of the fetch on 2026-11-09, the newest entry in the official changelog was still the Nov 5 GPT-6 Cyber item — no newer API-layer entry existed in November.

2. The full life cycle of an outbound call

An outbound call has four segments: create the session, attach the sideband, watch the call-progress events, then drive the call (optional), keeping the sideband open until session.closed delivers final usage. Unlike inbound, an outbound call needs no incoming-call webhook and no accept request — creating the session is the dial action.

Session creation uses the guide's own curl and jq example (the example selects client delegation, so your backend must handle delegated work; replace the provider endpoint and phone numbers with your own):

jq -n \
  --arg username "$SIP_USERNAME" \
  --arg password "$SIP_PASSWORD" \
  '{
    "session": {
      "model": "gpt-live-1",
      "instructions": "Help the user schedule an appointment.",
      "audio": { "output": { "voice": "marin" } },
      "delegation": { "type": "client" }
    },
    "transport": {
      "type": "sip",
      "destination": "+14155550123",
      "trunk": {
        "provider_url": "sips:sip.example.com:5061",
        "auth": {
          "type": "digest",
          "username": $username,
          "password": $password
        },
        "caller_number": "+14155550100"
      }
    }
  }' | curl https://api.openai.com/v1/live/sessions \
    -H "Authorization: Bearer $OPENAI_API_KEY" \
    -H "Content-Type: application/json" \
    --data-binary @-

A successful request returns 200 with a minimal body:

{
  "session": { "id": "live_123" },
  "transport": { "type": "sip" }
}

The guide emphasizes three things about this response: it does not mean the call has been answered; it contains no SDP and no trunk credentials; and the session.id must be preserved unchanged, since the sideband connection and call controls both depend on it. Also omit audio.format when creating an outbound session — the audio format is negotiated by SIP.

3. Trunk configuration fields and provider requirements

The trunk configuration is supplied with each request; the fields below all come from the official guide:

Provider-side hard requirements: the trunk must support TLS signaling and SDES-SRTP media, with SRTP enabled in your provider's settings before placing a call. provider_url must use the sips: form (TLS signaling); the URL must not include credentials, paths, URI headers, or other URI parameters; local hostnames and literal private or local IP addresses are rejected. Keep your OpenAI API key and SIP credentials on your own server. There is also a network allowlist: SIP signaling uses the GeoIP-routed endpoints sip.api.openai.com and sip-eu.api.openai.com (allow outbound TCP/TLS on port 5061 to the addresses DNS returns), and SRTP media needs bidirectional UDP to the address and port the negotiated SDP specifies — the guide lists four /28 CIDRs for it.

4. Call-progress events, limits, and errors

Once the sideband is attached, call progress arrives as three events (the guide's event table):

Every event carries event_id and session_id. Attachment timing is a hard constraint: the sideband only replays events from the preceding 3 seconds, so a later attachment misses earlier call progress; replayed events keep their original event IDs, and deduplicating by event_id is enough.

Limits and errors are the guide's own numbers and codes: ringing is limited to 3 minutes, a connected call to 2 hours, and neither is configurable in the creation request; invalid session configuration is returned on the creation request; transport setup failures can return 502 and initialization timeouts 504; async setup failures after a successful creation surface through transport.failed.

5. In-call controls: DTMF, transfer, and hang up

The guide states these controls apply to both inbound and outbound calls. Keypad tones use three sideband events: when the other side presses a key you receive transport.dtmf.received; to send a tone to the trunk you send a transport.dtmf.send client event and receive transport.dtmf.sent once it is delivered; if you supply an event_id it comes back as client_event_id, and failures return an error event with error.client_event_id.

Transfer and hang-up are two ordinary HTTP endpoints. The transfer (refer) body has a single field:

{ "target_uri": "sip:agent@example.com" }

The target becomes the SIP Refer-To header and can be a telephone URI such as tel:+14155550123 or a SIP URI such as sip:agent@example.com; your provider handles the remaining transfer flow. Hang-up sends POST /v1/live/sessions/{session_id}/hangup with no request body. Both endpoints return 200 with an empty body on success. Closing rule: keep the sideband open until session.closed arrives — final usage is supplied with it.

6. SDK type-layer status: nothing beyond webrtc yet

Our same-day check (2026-11-09) of both official SDK tag sources: SIP outbound calling has not reached the type layers.

• openai-python v3.47.0: in src/openai/types/live/live_create_params.py the Transport type field is Required[Literal["webrtc"]] with only sdp alongside — the sip type and the destination and trunk fields are absent; src/openai/resources/live/sessions.py lists accept, download_recording, fork, hangup, refer, and reject (sync and async each), with no create.
• openai-node v7.53.0: LiveCreateParams.Transport in src/resources/live/live.ts likewise only defines type 'webrtc' plus sdp.

The event side is one step ahead: the ServerEvent union in openai-node v7.53.0 already includes TransportRinging, TransportAnswered, TransportFailed, and the three DTMF events (transport.dtmf.received / send / sent), matching the guide's progress events one to one. In other words, the event types are in place while the create-session SIP transport is not — until the type layers catch up, place outbound calls over raw HTTP per the official guide and move back to typed calls once the SDKs update.

7. Common errors and troubleshooting

• The creation request fails outright: invalid session configuration is returned on the creation request — check the trunk fields one by one (sips: form, digest auth, E.164 numbers) and the omitted audio.format.
• You get a 502: transport setup failed; one of the status codes the guide names — before retrying, confirm SRTP is enabled on the provider side.
• You get a 504: initialization timed out.
• Creation succeeded but the phone never rang: the 200 response does not mean the dial succeeded; attach the sideband and watch transport.failed, then inspect error.code and error.message.
• You missed the ringing event: you attached later than the replay window (only the preceding 3 seconds); next time attach immediately after the creation response and deduplicate replayed versus live events by event_id.
• A DTMF send failed: look for error.client_event_id in the error event to identify which send failed.

8. Next steps

• The inbound accept / reject / hang up / refer controls and the Live API resource surface: The Live API lands in the OpenAI SDK: gpt-live-1, dual WebRTC/WebSocket channels, and SIP call control.
• Where SIP DTMF first landed in the SDK (the transport.dtmf.send client command): openai-python 3.42.0 and openai-node 7.46/7.47: agent compaction and review settings, external keys, SIP DTMF.
• The WebRTC and WebSocket big picture of realtime voice: Realtime Voice guide: gpt-realtime and Voice Mode.
• The continuously updated release timeline: OpenAI Models Release Notes (2026, Living Document).