Live API 外呼开放：GPT-Live 经 SIP 主动拨打电话与通话控制实战

Live API 此前的 SIP 能力集中在呼入侧：供应商把来电转给 OpenAI，你用 accept 或 reject 决定接不接。2026-11-02 的官方 changelog 条目把方向反过来——外呼（outbound SIP calling）经 Live API 对全部组织开放，你的服务器指定一个电话号码，由自己的 SIP 供应商完成电话网络侧的连接，GPT-Live 承担对话本身。本文事实来源为 2026-11-09 当日抓取的官方 changelog、Telephony and SIP 指南（.md 全文变体）与两包官方 SDK 的 tag 源码；文中代码为官方指南照录（文档核对版，本站未在真机环境执行外呼）。

1. 官方宣布与能力边界

官方 changelog 2026-11-02 条目（Feature，标注 Model 为 gpt-live-1、API 为 v1/live/sessions）原文：

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

两条边界值得先钉住。第一，外呼只经 Live API 提供——官方指南在 Place an outbound call 一节写明「Outbound SIP calling is available to all organizations through the Live API, not the Realtime API call-creation endpoint」，Realtime API 的呼叫创建端点不在此外呼通道内。第二，计费口径：官方定价页（2026-11-09 抓取）列 gpt-live-1 语音会话 $0.05 每分钟、按秒计费且不向上取整，后端模型与工具用量单独计费。

状态锚定：截至 2026-11-09 当日抓取，官方 changelog 最新条目仍为 11-05 的 GPT-6 Cyber，11 月侧再无更新的 API 层条目。

2. 一通外呼的完整链路

整个外呼分四段：创建会话 → 附着 sideband → 监听呼叫进度事件 → 通话中控制（可选），最后保持 sideband 直到收到 session.closed 拿最终用量。与呼入不同，外呼不需要来电 webhook，也不需要 accept 请求——创建会话本身就是拨号动作。

创建会话用官方指南照录的 curl 加 jq 示例（示例选择 client 委托，你的后端需要处理受托工作；供应商端点与电话号码请替换为你自己的值）：

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 @-

请求成功返回 200 与一个极简的响应体：

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

官方指南对这个响应有三个强调：它不代表电话已被接听；其中不含 SDP，也不含 trunk 凭据；session.id 要原样保留，后续的 sideband 连接与通话控制都靠它。另外创建外呼会话时省略 audio.format——音频格式由 SIP 协商。

3. trunk 配置字段与供应商要求

trunk 配置随每次请求一起提交，字段如下（全部出自官方指南）：

供应商侧的硬性要求：中继必须支持 TLS 信令与 SDES-SRTP 媒体，并且在拨号前先在供应商设置里启用 SRTP。provider_url 必须用 sips: 形式（TLS 信令），URL 里不能带凭据、路径、URI 头或其他 URI 参数；本地主机名与私有、本地 IP 字面量会被拒绝。OpenAI API key 与 SIP 凭据都留在你自己的服务器上。网络侧还有一组放行要求：SIP 信令走 GeoIP 路由端点 sip.api.openai.com 与 sip-eu.api.openai.com（对 DNS 解析出的地址放行 TCP/TLS 5061 端口的出站流量），SRTP 媒体按协商 SDP 给出的地址与端口放行双向 UDP——官方指南列出四个 /28 CIDR 段。

4. 通话进度事件、限额与错误

附着 sideband 后，呼叫进度经三个事件下发（官方指南的事件表）：

每个事件都带 event_id 与 session_id。附着时机是硬约束：sideband 只回放附着前 3 秒内的事件，附着晚了就会错过更早的呼叫进度；回放的事件保留原始 event_id，按 event_id 去重即可。

限额与错误都是指南明说的数字与状态码：振铃最长 3 分钟、接通后通话最长 2 小时，两者都不能在创建请求里配置；无效的会话配置在创建请求上直接返回；传输建立失败可返回 502，初始化超时返回 504；创建成功之后的异步建立失败，要靠监听 transport.failed 感知。

5. 通话中控制：DTMF、转接与挂断

官方指南写明这些控制对呼入呼出都适用。按键音走 sideband 的三个事件：对端按键时收到 transport.dtmf.received；向 trunk 发按键音则发 transport.dtmf.send 客户端事件，成功后收到 transport.dtmf.sent；如果你在发送时带了 event_id，回执里会以 client_event_id 回带，失败则收到带 error.client_event_id 的 error 事件。

转接与挂断是两个普通 HTTP 端点。转接（refer）的请求体只有 target_uri 一个字段：

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

target_uri 写入 SIP Refer-To 头，可以是 tel:+14155550123 这样的电话 URI，也可以是 sip:agent@example.com 这样的 SIP URI，剩余转接流程由你的供应商完成。挂断（hangup）向 POST /v1/live/sessions/{session_id}/hangup 发送且不带请求体。两个端点成功时都返回 200 与空响应体。收尾规则：保持 sideband 打开直到收到 session.closed，最终用量随该事件给出。

6. SDK 类型层现状：webrtc 之外尚无 sip

本站当日（2026-11-09）对两包官方 SDK 的 tag 源码核对结果：SIP 外呼还没有进入类型层。

• openai-python v3.47.0：src/openai/types/live/live_create_params.py 里 Transport 的 type 是 Required[Literal["webrtc"]]，字段只有 sdp——sip 类型、destination、trunk 等字段都不在类型里；src/openai/resources/live/sessions.py 的方法清单是 accept、download_recording、fork、hangup、refer、reject（同步与异步各一份），没有 create。
• openai-node v7.53.0：src/resources/live/live.ts 的 LiveCreateParams.Transport 同样只有 type: 'webrtc' 加 sdp。

事件侧倒是先走了一步：openai-node v7.53.0 的 ServerEvent 联合已包含 TransportRinging、TransportAnswered、TransportFailed 与 DTMF 三事件（transport.dtmf.received / send / sent），与指南的进度事件一一对应。也就是说，事件类型已经就位、创建会话的 SIP transport 还没就位——在两包类型层跟进之前，外呼按官方指南用原始 HTTP 调用，等 SDK 更新后再迁回类型化调用。

7. 常见错误与排查

• 创建请求直接报错：会话配置无效会在创建请求上返回——逐项检查 trunk 字段（sips: 形式、digest 认证、E.164 号码）与省略 audio.format。
• 返回 502：传输建立失败；官方指南原文给出的状态码之一，重试前先核对供应商端 SRTP 是否已启用。
• 返回 504：初始化超时。
• 创建成功但电话没响：创建响应的 200 不代表拨号成功；附着 sideband 监听 transport.failed，按 error.code 与 error.message 排查。
• 错过了 ringing 事件：附着晚于事件超过回放窗口（仅前 3 秒）；下次在创建返回后立即附着，并按 event_id 去重处理回放与实时事件的交叠。
• DTMF 发送失败：看 error 事件里的 error.client_event_id 定位是哪次发送失败。

8. 下一步

• 呼入侧的 accept / reject / hangup / refer 控制与 Live API 资源面总览，见《Live API 现身 OpenAI SDK：gpt-live-1、WebRTC/WebSocket 双通道与 SIP 通话控制解读》。
• SIP DTMF 的 SDK 侧首次落地（transport.dtmf.send 客户端命令），见《openai-python 3.42.0 与 openai-node 7.46/7.47 更新解读：Agent 压缩与审查设置、外部密钥管理与 SIP DTMF》。
• WebRTC 与 WebSocket 双通道的实时语音全景，见《Realtime Voice 完全指南：gpt-realtime 与 Voice Mode》。
• 发布时间线的持续汇总，见《OpenAI 模型更新日志（2026 持续更新）》。