GPT-Live-1 现在可以外呼了：SIP GA 究竟解锁了什么，又仍有哪些做不到的事

OpenAI 语音智能体能做的最有用的新事情，就是按 1。自 2026 年 11 月 4 日晚些时候起，GPT-Live-1 会话可以通过 SIP 中继向真实电话号码发起外呼，听取接听方的菜单，并把按键音发送回线路。最后这一点——双向 DTMF——正是能说话的语音智能体与能穿过电话树、接通它真正所需部门的语音智能体之间的区别。

模型本身并不新。GPT-Live-1 自 2026 年 7 月 8 日起已在 ChatGPT Voice 中提供，自 2026 年 9 月 10 日起已在 API 中提供，价格为每分钟 0.05 美元。11 月 4 日发生变化的是传输层。OpenAI 的 Justin Uberti 宣布，外呼电话 API 已“刚刚被提升……至 GA”，“允许开发者通过‘任何 SIP 中继提供商（例如 Telnyx 或 Twilio）’从其 Live 语音智能体拨打电话”；Greg Brockman 当晚也转发了这一消息。公告还补充说，通话可以使用 HD Voice，并且可以发送和接收按键事件。

所以这是一个能力层面的故事，而不是模型层面的故事，真正有意思的材料在文档里，而不是在那篇帖子里。OpenAI 的 Telephony and SIP 指南现在指出，外呼“通过 Live API 向所有组织提供，而不是通过 Realtime API 的呼叫创建端点”——这两句话悄然排除了人们会试图复用的一大部分集成。

“GA”改变了什么，以及它没有改变什么

在晋升之前，外呼已经存在，但并未普遍可用——这就是“晋升”的含义。机制早已构建好，门也已经打开。OpenAI 的文档现在载有与之对应的句子：出站 SIP 呼叫“通过 Live API 向所有组织提供”，这是该页面上最接近 GA 声明的表述：指南本身通篇没有任何 beta、preview 或 alpha 标签。

没有改变的是语音模型。OpenAI 自己的文档中的出站示例仍然设置model: "gpt-live-1"，合作伙伴检查清单仍然告诉集成商要寻找“支持gpt-live-1的软件包版本”。没有专门用于出站的模型，没有单独定价，也没有电话层级。你为语音层支付的仍然是九月时相同的每分钟 $0.05；只是现在你可以把这笔钱花在离开你的服务器的通话上。

一条运营注意事项藏在指南里，而不是公告里：OpenAI 要求你确认“在使用此流程之前，GPT-Live SIP 支持已为你的项目启用，并且你的提供商的 SIP 中继已路由到该项目。”GA 标签和已启用的项目设置并不是一回事，而本周的第一张支持工单就会是某个只具备其中之一的人。

决定你的中继究竟能否工作的先决条件

OpenAI 并未在广义上采用 SIP。它采用的只是其中一小块狭义的现代子集；任何不满足以下任一条件的中继都无法连接，无论公告中关于“任何 SIP 中继提供商”承诺了什么。

• 信令——TLS 是必需的，而非可选的。通过 UDP 或 TCP 传输的明文 SIP 不再可用。

• 媒体 — 必须使用 SDES-SRTP，并且必须在提供商一侧开启 SRTP，而不能仅仅是得到其支持。

• 提供商 URL — 预期为 sips: 端点，默认端口为 5061，且不附带凭据、路径和 URI 参数。

• 目标 — 一个 E.164 号码，例如 +14155550123，不能是其他任何内容。明确不支持 SIP URI，因此内部的分机方案并不是捷径。

• 身份验证——摘要认证，需提供 SIP 用户名和密码，以及 caller_number（E.164 格式），该号码将成为被叫方看到的来电显示。

• 网络卫生 — 本地主机名和字面私有 IP 地址会被拒绝，这就排除了将测试装置指向实验室设备的可能。

• 音频格式——请勿设置 audio.format，因为 SIP 会协商它。设置它正是那种看似有用却会导致通话失败的参数。

请注意这对“任何提供商”这一说法意味着什么。任何支持 TLS 信令并使用 SDES-SRTP 媒体的提供商都可以工作；许多廉价的 SIP 中继仍然默认使用 UDP 和纯 RTP，因此它们不在这句话的涵盖范围内。这种对接方式是创建会话，而不是 webhook：你向以下地址发送 POST 请求：/v1/live/sessions，并将 transport.type 设置为 sip，指南明确指出“外呼不需要来电 webhook 或接受请求”。

你得到的是 session.id 和一种传输类型，而文档对于它和现实之间的差距异常直白：“此响应并不意味着通话已被接听。” 响铃、接听和失败稍后会作为 transport.ringing、transport.answered和transport.failed 事件，出现在位于 /v1/live/sessions/{session_id}/attach 的边带 WebSocket 上。立即 attach——只会重放之前三秒的事件——并按 event_id 去重，因为指南警告重复投递是正常的。

信封：响铃三分钟，通话两小时

指南中的两个硬性数字将决定哪些外呼用例可行，而这两个数字都没有出现在公告中。

• 响铃时限——三分钟。若届时无人接听，通话即结束。

• 连接上限 — 两小时，之后无论发生什么，会话都会结束。

• 控制面 — 通过 /v1/live/sessions/{id}/refer 进行转接，通过 /v1/live/sessions/{id}/hangup 挂断，DTMF 通过边带使用 transport.dtmf.send 发送。

• 故障模式——错误的会话配置会在创建时直接报错，传输设置可能返回 502，初始化超时返回 504，之后发生的任何情况都会以异步方式作为 transport.failed 到达。

三分钟的振铃时长对消费者外呼来说没问题，但对需要保留呼叫的企业总机来说就很别扭。两小时的上限本来很宽裕，直到你把坐席接入支持队列——长时间保持加上长时间通话，确实有可能逼近这个上限。这两个限制在实时语音产品里都不算意外；它们都属于你在向客户承诺外呼活动 SLA 之前就想知道的事情。

说实话，一通电话要花多少钱

OpenAI 的定价页面将 GPT-Live-1 语音会话列为每分钟 0.05 美元，“按秒计费，不向上取整到整分钟”。这就是公布价格的全部内容，而这只是外呼产生的两笔账单中的一笔。运营商落地费是另一笔，取决于目的地、通话量以及你选择的中继提供商。OpenAI 负责音频处理和会话逻辑；提供商负责 PSTN 链路。

• 一分钟已接通的通话——OpenAI 收取 $0.050，另加你的运营商每分钟费率。

• 一通四分钟的通话——OpenAI 收取 $0.200，另加运营商费用。

• 一千通四分钟的通话——共 4,000 分钟，所以 OpenAI 这边要 200 美元，再加上运营商费用。

• 一小时的联网对话——OpenAI 收取 3.00 美元，另加运营商费用。

关于这项计费有两个地方需要留意。第一，计费单位是会话分钟，而定价页面上没有任何说明区分说话与静音，因此你的智能体听候机音乐所花的秒数，与它说话所花的秒数按同样费率累计。第二，指南没有说明一通响铃三分钟却始终无人接听的电话是否算作可计费会话；这个问题值得在批量运行外呼系统之前先问客服，而不是之后才问。

后端模型和工具的使用单独计费，按你委托的那个模型来算。如果你把这一段通过 OrcaRouter 路由，那么 0% 加价和直通定价 就适用于那里，而不是语音分钟——因此，推理模型上供应商的降价当天就会体现在你的账单上，而 gpt-live-1 的降价则不会。

你的 Realtime 集成不会迁移过来

本周可能犯下的代价最高的单一错误，就是以为一个能用的 Realtime API 电话技术栈就是一个能用的 GPT-Live 技术栈。OpenAI 的合作伙伴页面说得很直白：“Realtime 集成并不自动兼容 GPT-Live。”端点不同，会话模型不同，委托是 Realtime 并不以相同形式具备的概念，而指南要求你按合作伙伴逐一检查的音频格式和打断语义也并未沿用过来。

合作伙伴列表也让公告的措辞变得更加复杂。OpenAI 在文档中将 LiveKit 列为用于语音智能体的方案；将 Twilio Agent Connect 列为用于“呼入和呼出电话”的方案；将 Telnyx 列为用于“呼出通话体验”的方案；将 Bandwidth 列为通过 SIP 处理“呼入电话”的方案；并将 Daily/Pipecat 列为一般用于 Live 服务的方案。换言之，Bandwidth 在文档中被列为入站集成，而 LiveKit 和 Pipecat 在文档中则完全没有标注通话方向。“任何 SIP 中继提供商”是关于协议兼容性的表述，而不是关于 OpenAI 的五家合作伙伴中哪一家已经提供了呼出支持的表述。

如果你使用的是 Twilio，那么目前已有文档记录的出站路径的迁移方案就是它。如果你使用 Bandwidth 处理入站，那么通过该集成进行出站目前还不是文档所承诺的内容。

没人问过的版本问题

这个名称中存在一个尚未澄清的歧义。GPT-Live-1.1 于 2026 年 10 月 15 日并入 ChatGPT Voice，新增了覆盖六种语言的新语音，而 OpenAI 仍未为 API 调用方发布 gpt-live-1.1 模型 ID。电话指南中的每个出站示例都使用 gpt-live-1。如果同事告诉你外呼代理运行的是 1.1，因为 ChatGPT 用的就是这个，那么他们描述的是消费级产品，而不是你的会话配置。

实际操作上：在计划中引用 gpt-live-1，并将任何 1.1 API 的可用性视为一个单独事件，需在其自身日期进行验证。

思考发生的地方，以及为什么它是你所掌控的杠杆

GPT-Live 一分为二。文档自身的总结是：它“将推理和工具使用委托给后端，同时负责管理语音对话”。语音层负责处理时序、打断和韵律；另一个独立模型负责思考并调用工具。该后端按会话在 delegation 下配置，采用两种模式之一。

• Responses 委托 — delegation.type: "responses"，并需要一个必需的后端 模型，还要提供指令、工具、工具选择、令牌限制和服务层级。OpenAI 的指南建议从 gpt-6-luna 开始，或者对于更困难的任务使用 gpt-6-sol，并指出“你可以独立于语音模型选择 Responses 模型。”

• 客户端委托 — delegation.type: "client"，即由你的应用自行运行后端。OpenAI 的表述是，这允许“你的应用所运行的任何模型、代理或服务”。

外呼智能体的成本与质量实际上就体现在这里，而这是页面上唯一真正由你掌控的架构选择。语音模型是固定的，而且恰好不在 OrcaRouter 的产品目录中——GPT-Live-1 是你从 OpenAI 购买的电话前端，再多的路由巧思也改变不了这一点。后端则另当别论。在客户端委托模式下，它只是你的代码发起的一次普通模型调用，这意味着一个 API 接入 200+ 模型，你评估的各个供应商共用一把密钥，若某家供应商在活动进行中降级则自动故障切换，并且可按呼叫类型选择模型：用便宜的模型导航 IVR 菜单，一旦人工接听就换成更强的模型。

在 Responses 委派模式下，OpenAI 会运行该环节，并按自己的费率计费。两者都合理；只是它们把决策放在了不同的位置。如果你希望后端成为一个路由决策，客户端委派就是能实现这一点的模式。

公告中遗漏了什么

对于一个 GA 发布公告来说，这份公告在那些真正决定部署的事项上着墨甚少。它完全没有提及区域可用性、延迟、并发限制或 SLA。它也没有提及录音、披露或同意方面的义务——而在本产品中，外呼恰恰是这些义务并非纸上谈兵的领域。在美国，未经同意向消费者拨打自动语音电话，首先是一个 TCPA 问题，其次才是工程问题；在欧盟，录音却不告知通话对方，本身就是另一个问题。API 只给你一个 caller_number和一个挂断端点。合规责任由你自负。

“HD Voice”也值得当作一种宣称、而非一项规范来对待。OpenAI 的文档只说明 SIP 会协商音频格式，并未列出任何编解码器，因此文中提到的宽带音频只是厂商的说法，从未在任何公开渠道给出量化数据。在把它写进演示文稿之前，请先拿你自己的运营商做实测验证。

这周拿这个怎么办

如果你已经在 WebRTC 上运行 GPT-Live 语音智能体，那么外呼路径就是第二种传输方式，而不是重写：使用 transport.type: "sip"创建新会话，并配置一个支持 TLS 和 SDES-SRTP 的中继，以及一个用于监听振铃、应答和 DTMF 的边带 WebSocket。把一天的时间留给中继，而不是智能体。

如果你正在使用 Realtime，不要以为这只是一次配置变更就安排迁移。请先阅读委派和会话这两部分，判断你的后端应该采用 OpenAI 的还是你自己的，然后再去选择合作伙伴——因为你目前用于入站的那家合作伙伴，未必就是拥有文档化出站路径的那一家。

如果你还在犹豫外呼语音到底值不值得做，那么真正关键的数字是：在运营商费用之前，每个接通小时 $3.00，对应的是两小时的硬性上限和三分钟的振铃。这个价格足够便宜，值得一试；也足够贵，以至于等待时长必须是一个有意的设计决策，而不是意外。GA 移除了门槛，却没有移除这道算术。