GPT-Live 外撥電話開放：語音代理主動撥號，打通不等於接聽

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

OpenAI 在 11 月 2 日的 API 變更紀錄寫下短短一條：外撥 SIP 通話（outbound SIP calling）現在透過 Live API 對所有組織開放，把 GPT-Live 接上電話號碼，線路走你自己的 SIP 中繼供應商。兩天後的台北時間 11 月 5 日清晨，OpenAI 的 Justin Uberti 在 X 上宣布這項能力正式上線，順手點出兩個亮點：HD Voice 高傳真語音，以及能收發電話按鍵訊號（DTMF）。

Pin

對照九月 GPT-Live-1 開放 API 時的定位，那波賣的是聽與說的語音工作階段，這次補上的是另一個方向：應用可以主動撥出，不必再等對方打進來。想讓語音代理做預約確認、到貨通知這類由 AI 先撥的流程，從此多了一條正規入口。

這次開放有三條邊界：入口是給開發者的 API，ChatGPT 訂閱沒有跟著多出撥號功能；撥出請求成功與對方接聽是兩個狀態；每分鐘 0.05 美元買到的只有語音工作階段，安靜等待的秒數照樣計費。這三條邊界，決定了串接工作各自落在誰身上。

開放的入口在 Live API，不在 ChatGPT 介面

變更紀錄把這次更新掛在 gpt-live-1 模型與 v1/live/sessions 端點下，適用對象寫的是所有組織。SIP 指南講得更直白：外撥走 Live API，明確不走 Realtime API 的舊呼叫建立端點。已經用 Realtime 的 SIP 接聽流程接了來電的團隊，兩套要分開對待：舊接聽設定不會自動變成外撥，直接改名換用途也不會動。

ChatGPT 消費端沒有跟著宣布對應功能。官方語音最近的兩步，是把任務掛進語音對話、以及換上一批新音色，但撥電話給外部號碼這件事，目前只存在於 API 層。把 API 開放讀成我的 ChatGPT 可以幫我打電話，會差一整層：線路、號碼、計費與法規責任，全部落在開發者這側。

時間軸上有個值得留意的細節：文件登錄與公開宣布差了兩天，變更紀錄日期是 11 月 2 日，Uberti 的宣布是 11 月 4 日。養成先查官方變更紀錄的習慣，這次比追推文早了兩天看到訊號。

一通外撥電話，三方各管一段

架構本質是分工買賣：SIP 中繼供應商賣你號碼與電話網路連接，Uberti 在推文裡點了 Telnyx 與 Twilio 當例子；OpenAI 賣 GPT-Live 這個能同時聽與說的語音模型；你的後端決定這通電話要做什麼，接事件、查資料、把結果寫回系統。三方缺一，電話都打不成。

外撥與接聽的流程差異，指南寫得很白：接聽要先設定來電 webhook，收到通知再送出 accept 請求；外撥不用等任何通知，直接 POST /v1/live/sessions 建立工作階段，語音代理就開始這通對話。主動權換了方向，整條流程也跟著換一套，把兩種流程混在一支程式裡，很容易寫出永遠在等通知的迴圈。

官方範例給的情境是排預約，指示欄位寫的是協助使用者安排預約，語音端問對方方便的時間，後端查可選時段再回報。這是文件裡的示例，不假裝成通話實測，但拿來當第一輪測試的用途很合適：結果好核對、對話短、成功與失敗都看得見。

查資料這一段有兩種接法，官方文件把它叫委派。用 Responses 委派，GPT-Live 自己去呼你指定的後端模型，把結果帶回對話；用 client 委派，你的程式自己準備上下文、跑自己的流程，查完再餵回去。官方給的選擇標準很實際：需要先檢查、過濾或合併後端結果才讓對方聽到，就選 client 委派；要自訂每個請求帶哪些歷史與狀態，也是 client 委派。模式在建立工作階段時就要選定，中途換模式等於另開一場。兩種模式開頭就寫了同一條鐵律：權限核可、確認動作、業務紀錄與任務狀態，全部歸你的應用管，語音模型不替你扛。

電話場景還有一個容易被忽略的行為：口頭打斷不會取消後端工作。對方改口說改成星期四，進行中的星期五查詢照樣跑完，官方的要求是把取消邏輯放在後端自己處理，確認取消成功之前，別讓語音端先說已經取消。這條對客服流程是硬要求，說出口的承諾跟系統狀態對不上，就是一張客訴單。

線路要先過的三關

供應商那側不是有帳號就行。指南要求中繼支援 TLS 訊號加密與 SDES-SRTP 媒體加密，供應商設定裡要先把 SRTP 開起來；請求裡的供應商位址必須 sips: 開頭、預設埠 5061，而且網址裡不能塞帳密、路徑或其他參數，本機主機名稱與私有 IP 位址會被直接拒絕。老線路只支援舊式傳輸的，先翻供應商後台確認有對應選項。

Pin

號碼有兩條規矩。目的地必須是 E.164 國際格式，就是帶國碼的完整號碼，SIP 位址當目的地不被接受，舊電話系統裡那種撥分機位址的寫法照搬會失敗。主叫號碼是另一個獨立欄位，交給供應商處理來電顯示；這兩個欄位一旦寫反，撥錯對象與顯示錯號碼會同時發生。

帳密歸帳密：SIP 的 digest 帳號密碼與 OpenAI API 金鑰都該只存在伺服器，瀏覽器與手機前端不該碰到任何一組。這條是老原則，但電話場景的放大效果不同：一組外洩的 SIP 憑證，等於別人用你的線路打國際電話。企業內部部署還有防火牆作業，訊號流量走 TCP/TLS 到 sip.api.openai.com 的 5061 埠（GeoIP 路由），媒體流量是 UDP 上的 SRTP，指南列了四段要放行的網段，這部分得交給網管照單開。有歐洲資料駐留需求的組織另有專用端點，但那是接聽流向把中繼指向 OpenAI 的設定，與外撥請求裡你自己供應商的位址是兩回事。

建立 200 OK 之後，通話才剛開始

POST /v1/live/sessions 回傳 200，只代表工作階段初始化完成。回應裡沒有 SDP、沒有中繼資訊，官方明寫這不代表電話已被接聽。把這個 200 記成已通話，客戶聯繫紀錄從一開始就是錯的。回應裡真正要接住的是工作階段識別碼，官方要求這個值原封不動用在後續的控制連線與每一個控制請求上，自行改寫或另起一個，後面全部接不上。

真正的進度要掛上 sideband 控制連線（attach 到同一個工作階段識別碼）收三種事件：transport.ringing 表示響鈴或早期媒體，transport.answered 表示已接聽且媒體建立，transport.failed 表示建立失敗並附錯誤代碼與訊息。每個事件都帶 event_id，指南提醒控制連線只回放前 3 秒的事件，太晚附接會錯過響鈴進度；重新連線後回放的事件保留原始 event_id，要自行去重，否則同一通電話會被當成兩通。

已經在用 SIP 接來電的團隊，對照著看更快：接聽流程是電話先打到你的中繼，OpenAI 送 live.transport.incoming 事件到你的 webhook，後端再決定收或不收，拒接可以帶 300 到 699 的 SIP 狀態碼，先下的決定生效，後到的會收到 decision_already_made 錯誤。外撥把這整套等待拿掉了，但事件去重的紀律兩邊共用。還在收舊事件名稱 live.call.incoming 的整合，指南提醒遷移期兩種名稱都要處理，而且同一通待決電話可能同時發出 Realtime 的 webhook，收或不收一樣只能有一個決策者。

有一條設計原則值得單獨抄下來：每個會改變結果的動作，只能有一個處理者。webhook 可能重送，多條連線可能同時看到同一個事件，如果兩處都執行確認預約，客戶就被預約了兩次。事件去重與動作唯一負責人，是同一道防護的兩面。

上限與錯誤位置也寫死了：響鈴最多 3 分鐘、通話最多 2 小時，這兩個數字無法在建立請求裡調整；傳輸建立失敗可能回 502、初始化逾時回 504，而初始化成功之後仍可能收到非同步的 transport.failed。收到 200 就停止監看，等於把最可能的失敗點留在沒人看的地方。

Pin

按鍵、轉接與結束，都在控制線上完成

對方按 1 轉人工、輸入查詢碼這類互動，靠 DTMF 事件：對方按鍵會收到 transport.dtmf.received，要主動送出按鍵則送 transport.dtmf.send，成功後有 transport.dtmf.sent 回報，失敗時錯誤事件會帶回你附上的 client_event_id，方便對帳是哪一次送鍵失敗。送鍵成功的回報講的是訊號已送出，選單那端接不接受、業務辦不辦得成，還是要從後續對話與結果確認。語音代理要跟傳統 IVR 選單一來一往，靠的就是這組介面。

要交給真人或另一個系統，用 refer 轉接：目標可以是 tel: 電話號碼，也可以是 sip: 位址，它會被放進 SIP 的 Refer-To 標頭，後續轉接流程由供應商完成。這裡有個容易混的地方：建立請求的目的地只收 E.164 號碼，轉接目標卻兩種都收，規則不同，不能照搬。結束通話用 hangup，沒有請求內容；控制連線要一路開到 session.closed，最終用量數字就掛在關閉事件裡。

每分鐘 0.05 美元，計的是整段活躍時間

截至 11 月 9 日，模型卡列價每分鐘 0.05 美元，按秒計費、不進位到整分。這個價格買的是語音工作階段這一層，後端模型與工具用量另計，供應商的線路費也另計。算一通電話的總成本要拆三層：語音秒數除以 60 乘上 0.05 美元，加後端用量，加中繼費用。

Pin

計費對活躍的定義比直覺寬：對方說話、模型說話、雙方安靜、後端正在跑，全部都在計。後端查詢慢一秒，語音帳就多一秒；指南甚至給了反向例子，換上更貴但更快的後端，總成本可能不升反降。比較後端方案時只看單價，會漏掉這一塊。

成本指南給了一個完整算例：90 秒的語音工作階段，語音費是 0.075 美元，後端工作量若合計 0.02 美元，這通對話總共 0.095 美元。例子用的是示意費率，但三層拆法就是實務的拆法。還有一條省錢線索值得記：空等的語音時間每分鐘同樣是 0.05 美元，需要長時間等待後端的流程，把工作階段先關掉、事情辦完再開一段新的，比讓對方聽著空白等待便宜，指南把這招明寫給常駐代理的情境。

用量回報是累積快照：session.usage.updated 事件給的是至今秒數，新快照直接取代舊快照，不能把每次收到的數字加總，否則帳會浮報好幾倍。正確做法是把連線開到 session.closed，記下最後一次的 usage 秒數，一次入帳。

容量則是另一種上限：同時工作階段數按方案分層，Build 50、Launch 300、Grow 500，Free 層不支援。這是同一時間並存通話的連線容量，不是每天能撥幾通的額度；通話愈長，占用的名額愈久，要排大量外呼時，等待時間、通話長度與完成率得一起算。

哪些號碼撥得通，答案在中繼供應商那邊

官方把所有組織可用寫在 API 這一層，但特定國碼、特殊號碼能不能撥，取決於供應商的服務條款與各地電信規則，這部分 OpenAI 管不到也不背書。導入前把目標號碼範圍交給供應商逐項確認，同時讓法務看過目標市場對自動外撥與錄音同意的規範，比上線後逐國試撥、逐國收投訴便宜得多。

HD Voice 同樣只有能力宣稱、沒有規格數字：Uberti 的推文點了名，官方文件裡沒有對應的音質規格或價差，先當賣點看，等實際線路驗證再說。還有兩個問題目前沒有答案：ChatGPT 消費端會不會跟著開放撥出，沒有時程；錄音同意、跨境電信責任怎麼分，文件未著墨，落地前要讓法務過目。

首輪測試的建議路徑：挑一種結果好核對的用途，官方範例的預約確認就是好起點，跑通建立、響鈴、接聽、按鍵或查詢、寫回、結束一整條，記下語音秒數與後端用量對帳，再談放量。SIP 這條電話路不只 OpenAI 在走，xAI 的 Grok Voice 3 同樣標了 SIP 電話整合，比較各家方案時，線路條件與計費口徑比模型名稱更值得先比。

這次更新的分量，在於把 AI 主動聯絡從各種繞路手法，變成有文件、有事件模型、有計費規則的正規入口。手上已經有 SIP 線路的團隊，先照前面三關清單核對加密與號碼格式，挑一種用途把事件鏈跑通再談放量；還沒有電話系統的團隊，先向供應商把線路與號碼租起來，模型在這盤生意裡只是一家供應商。入口開了，接下來的狀態機與帳，都要應用自己接穩。