GPT-Live 外撥電話正式開放：SIP 接通、按鍵互動與通話成本怎麼看？
GPT-Live 外撥電話透過 SIP 供應商正式開放，解析建立成功與接聽的差別、後端控制、電話按鍵、轉接及每分鐘五美分以外的成本，幫企業確認串接條件。
AI 已經能在通話裡回答問題，企業若想讓它主動聯絡對方，還需要把模型接到真正的電話線路。
GPT-Live 外撥電話的變化，是開發者可以透過自己的 SIP 中繼供應商建立通話，讓語音代理開始這段對話。
SIP 是網路電話協定，負責建立與管理通話。供應商再把網路語音連到電話網路，模型則處理對話。
OpenAI 的變更紀錄將這項開放列於 11 月 2 日，即時 AI 負責人 Justin Uberti 在 11 月 4 日 UTC 宣布正式供應，並提到高清語音與按鍵事件。
但建立成功與對方接聽仍是兩個狀態，電話打通之後的查詢、轉接與費用，也需要由應用接起來。
我會先讓已有電話系統的團隊評估一種明確用途，例如確認預約，從一段能辨認結果的對話開始，再決定如何擴大。
先分清電話線路、語音模型與企業系統各自的工作，才能看懂新增的入口省掉什麼。
GPT-Live 外撥電話開放了哪一段能力？
這次開放的是由 Live API 主動建立通話，電話網路仍由 SIP 供應商連接。
OpenAI 的官方變更紀錄在 2026 年 11 月 2 日列出，所有組織皆可透過 Live API 使用外撥 SIP。這個日期與負責人的社群宣布時間不同，兩者都指向同一項能力。
API 是讓程式呼叫服務的介面。因此，新增入口主要給開發團隊使用，需要把自己的系統、語音代理與中繼線路接起來，並沒有同時宣布每位 ChatGPT 訂閱者都能在聊天視窗直接撥號。
電話供應商與模型各負責什麼？
電話供應商提供號碼與電話網路連接，OpenAI 提供能進行語音對話的模型。企業自己的後端則決定這通電話要做什麼，以及模型需要查詢哪些資料。
GPT-Live 可以同時聽與說，這種全雙工互動讓對話不必像對講機一樣輪流按鍵。它還能把需要推理與工具操作的工作交給後端，讓講話與查資料分工。
例如確認預約的應用，語音端可以詢問對方是否方便，後端則查詢可選時段。這是依官方架構設計的情境，並非本文完成過的電話測試。
相較於只接聽來電，主動撥出讓應用可以決定何時開始聯繫。但聯絡對象、目的與接通後的處理，仍由企業自己的產品流程安排。
正式供應也只描述 API 的開放階段。特定號碼或目的地能否撥通，還受中繼供應商的服務條件影響，不能從「所有組織」直接推成全球每個電話號碼都可用。
分工確定後，第一個實際條件是中繼線路能不能承接這通電話。
既有電話線路要準備什麼？
供應商需要支援加密的訊號與聲音傳輸，請求還要帶入正確號碼與登入資料。
官方 SIP 指南要求 TLS 訊號傳輸與 SDES-SRTP 聲音傳輸。前者保護建立通話的訊息，後者保護通話音訊，因此只確認有網路電話帳戶還不夠。
供應商的服務位址要使用加密的 sips: 格式，預設連接埠為 5061。原本只有較舊傳輸設定的線路，需要先核對供應商是否提供對應選項，模型本身不會替它補上。
撥給誰與顯示誰，是兩個欄位
目的地要使用 E.164 國際電話號碼格式，也就是帶國碼的號碼。這個外撥入口不接受把 SIP 網址直接填成目的地，不能照搬所有舊電話系統的呼叫方式。
請求也會另外提供主叫號碼，交給供應商處理。它與被叫號碼各有用途，若兩者在應用裡混用，便可能把本來的聯絡對象與來電顯示設定弄反。
中繼帳號、密碼與 OpenAI API 金鑰應由伺服器保管。瀏覽器或手機前端只需要取得自己操作畫面所需的資訊，沒有必要接觸完整線路憑證。
同一個請求還會設定語音、模型與工作委派方式。因為聲音格式由 SIP 協商，官方示例沒有要求開發者另外指定一套音訊格式，避免把其他連線方式的設定原樣混進來。
這些條件把一次撥號縮成可檢查的輸入。團隊先核對線路與號碼，再接上模型與應用，比在通話失敗後同時懷疑所有環節，更容易找到問題。
資料備齊後可以送出建立請求，但接下來必須確認它走到哪個通話階段。
API 成功之後，怎麼知道電話真的接通？
建立回應只確認工作階段完成初始化，接聽要看後續通話事件。
外撥使用 POST /v1/live/sessions，回應包含工作階段識別碼。官方明寫，收到成功回應不代表對方已經接聽，因此不能立即把客戶聯繫紀錄改成「已通話」。
響鈴、接聽與失敗需要分開記錄
後端連上這個工作階段之後，可以收到響鈴、接聽與建立失敗事件。響鈴也可能包含接通前的提示音，接聽事件才表示通話已應答並建立媒體傳輸。
這讓產品畫面可以跟著真實進度變化。例如先顯示撥號中，再顯示已接聽，若出現建立失敗則保留錯誤原因。每個狀態都對應不同事件，避免只用一個成功標記涵蓋整通電話。
外撥不需要等待來電通知，也不需要再送接受來電的請求。這是它與接聽流程的差別，若把兩套流程混在一起，程式可能一直等一個外撥本來就不會使用的通知。
監看連線太晚，可能錯過早期進度
指南建議建立完成後立即附接後端，因為事件只回放之前三秒的內容。若應用隔很久才開始監看，早期響鈴等進度可能已經不在回放範圍。
回放保留原事件識別碼，因此後端也要去除重複事件。這項處理讓重新連接後的同一筆進度，不會被當成另一通新電話或再次觸發相同工作。
時間上，響鈴最多三分鐘，已接通通話最多兩小時，建立請求無法自行調整這兩項上限。這些是服務限制，不能拿來當成所有情境都會自動完成的建議對話長度。
錯誤也可能出現在不同時間。傳輸建立與初始化逾時會有各自的錯誤回應，初始化成功後仍可能再收到非同步失敗，所以應用需要持續監看，而非收到成功就結束追蹤。
接通狀態有了明確依據，企業系統才知道何時開始處理對話要求。
對話、工具與電話按鍵怎麼協調？
電話聲音沿 SIP 傳送，企業後端則透過另一條連線接收事件、執行工具與控制通話。
這條稱為 sideband 的旁路連線，可以理解成與通話並行的控制通道。它連到原來的工作階段，因此附接時沿用同一個識別碼，不重新建立另一段對話。
聽到要求之後，還需要執行與回傳
例如對方要求更改預約，語音模型可以交辦後端查詢，再根據實際結果回應。工具請求與資料更新仍需要由應用處理，聲音回答流暢不代表訂位系統已完成修改。
官方特別提醒，每個會改變結果的動作應有一個明確處理者。若通知或多條連線同時看見相同事件，程式仍只能執行一次，否則一次確認可能變成兩次修改。
這與前面去除重複事件的目的相接。事件紀錄讓系統知道已經看過什麼，動作的負責者則決定誰能真正執行，兩者合起來才不會只因多次收到通知就重複處理。
電話按鍵與轉接也能進入流程
DTMF 是電話數字鍵所送出的按鍵訊號。這項介面可以接收對方按鍵，也能由後端送出按鍵，讓語音代理與原本的語音選單互動。
成功送出按鍵會有相應通知，若發送失敗，也能把錯誤對回原請求。但「按鍵已送出」仍只描述這個動作，後續選單是否接受、業務是否完成，要沿實際結果繼續確認。
當需要交給其他人或系統，可以呼叫轉接介面。官方支援電話或 SIP 轉接目的地，接下來的轉接流程由電話供應商完成，因此建立請求時的目的地限制與轉接目的地不能混為一談。
通話結束也有自己的介面，後端還應接收最後的關閉與用量資訊。這樣一來，對話結果與服務消耗才能一起交回原本的系統。
這些工作會消耗不同服務，所以估算費用也要沿著相同分工拆開。
延伸閱讀：OpenAI Decisions API 正式開放：400 題、JSON 與 GPT-Live 如何改變即時分流？
每分鐘五美分，為什麼不是整通電話的總價？
GPT-Live 的語音時間、後端運算與電話供應商費用，是不同成本。
截至 2026 年 11 月 9 日，官方模型卡列價每分鐘 0.05 美元，按秒計費，不向上取整到整分鐘。這是語音工作階段的價格，後端模型與工具另計。
例如語音工作階段持續兩分鐘，這一部分是 0.10 美元。它沒有包含供應商的電話線路費，也沒有包含後端為完成工作所呼叫的模型，因此不能直接當成一次確認預約的總價。
等待後端時，語音時間也在增加
成本文件說明，活躍工作階段包含雙方說話、靜默，以及後端工作的時間。只統計實際播出的聲音，會漏掉對話仍在等待的部分。
這讓後端速度與通話成本產生關聯。查詢很慢，對方可能需要等待更久，語音工作階段也持續存在。因此比較便宜的後端模型時，還要看它是否讓整項工作變得更慢。
應用可以分開記錄語音時間與後端用量，再依實際方案估算。官方用量事件回傳的是累積秒數，新的快照會取代舊快照，不能把每次收到的數字全部相加。
結束時保留連線直到收到最終關閉事件，再記錄最後用量，有助避免少算尾端時間。成本文件另有 WebRTC 初始化範例，但它屬於另一種連線情境，本文不替 SIP 推定相同額外費用。
同時可接多少通，與一天能打幾通不同
模型卡依 Build、Launch、Grow 列出五十、三百、五百個同時工作階段，免費用量層級不支援。這些是同時存在的連線容量，並非每天可撥出的電話總數。
通話愈長，同一段時間占用的容量也愈久。因此安排大量聯繫時，團隊要同時觀察等待、通話長度與完成率，不能只拿一通短電話估算所有工作。
成本拆清楚後，第一輪測試才有辦法同時看完成結果與等待時間。
已有電話系統的團隊，先驗證一種用途
先完成一通結果清楚的測試對話，比只確認 API 回應成功更有用。
以確認預約的假設流程來看，可以先讓應用建立通話，辨認響鈴與接聽，再請語音端取得對方的選擇，最後由後端寫回結果。每一段都對應可以核對的事件或資料。
若對方需要人工協助，就測轉接是否能完成。若沒有接聽或建立失敗，則應讓原本的聯繫紀錄保留正確狀態，後續安排再由產品規則決定。
已有 SIP 供應商的團隊，可以先核對加密、號碼與目的地條件，再評估這個新增入口。尚無電話系統的人則需要先處理線路與後端，單靠選定模型不會自動取得完整外呼服務。
等一條流程能交回可核對的結果，再判斷是否增加通話數或擴大服務。
GPT-Live 外撥電話常見問題
ChatGPT 訂閱已經包含這個功能嗎？
公告開放的是開發者 Live API，仍需要電話供應商與自己的應用串接。它沒有宣布所有 ChatGPT 訂閱者都能直接在聊天介面使用同一套外撥功能。
可以沿用 Realtime 的舊建立入口嗎？
官方明寫，本次外撥使用 Live API。既有 Realtime 接聽流程與新外撥的建立方式不同，應核對對應文件再整合。
收到成功回應，就能記成已接聽嗎？
建立成功只代表工作階段初始化完成。應等後續接聽事件，再依對話與工具的實際結果記錄業務進度。
先把一通電話的結果接回系統
對已經經營電話服務的團隊，這項更新提供了讓語音代理主動開始聯繫的入口。我會先選一種明確用途，核對線路、通話事件、工具結果與費用，讓一條完整流程成立。
接著追蹤這條流程的完成時間與成本，再決定擴大多少聯繫。這比只看模型能否流暢說話，更接近企業實際需要交付的結果。
延伸閱讀：GPT-Live 是什麼？ChatGPT 新語音模式功能、用量與限制完整解析
