GPT-Live-1 現在可以撥出電話了：SIP GA 究竟真正解鎖了什麼，以及它仍做不到什麼

OpenAI 語音代理最實用的新能力，就是按下 1。GPT-Live-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」，「讓開發者能從其 Live 語音代理撥打電話」，並可透過「任何 SIP 中繼供應商（例如 Telnyx 或 Twilio）」；Greg Brockman 當晚也轉發宣傳。公告補充，通話可使用 HD Voice，並且能傳送和接收按鍵事件。

所以，這是能力層面的故事，不是模型層面的故事，而有趣的素材在說明文件裡，不在文章本身。OpenAI 的 Telephony 與 SIP 指南現在寫道，外撥通話「所有組織皆可透過 Live API 使用，而非透過 Realtime API 的呼叫建立端點」——這兩句話悄然排除了人們會試圖重用的一大塊整合方案。

「GA」改變了什麼，以及它沒有改變什麼

在正式推出之前，外撥通話功能已經存在，但並未普遍可用——這就是「promoted」的意思。機制早已建置完成，只是大門如今才敞開。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 中一個狹窄且現代化的部分，而任何未符合以下任一項條件的中繼線都無法連線，無論公告對「任何 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：你向/v1/live/sessions發出 POST，並將transport.type設為sip，而指南明確指出：「外撥通話不需要來電 webhook 或接受請求。」

你會取回的是一個 session.id和一項傳輸類型，而文件對於這與現實之間的落差異常直白：「這個回應並不代表通話已經被接聽。」響鈴、接聽與失敗會稍後以 transport.ringing、transport.answered 與 transport.failed 事件的形式，透過位於 /v1/live/sessions/{session_id}/attach 的 sideband 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 美元，「按秒計費，不會進位成整分鐘」。這就是公布價格的全部內容，而它只是外撥電話所產生的兩筆帳單之一。另一筆是電信業者的落地費（termination charge），取決於目的地、用量，以及你選擇哪一家主幹（trunk）供應商。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 至今仍未發布gpt-live-1.1 的模型 ID 供 API 呼叫者使用。電話語音指南中的每一個外撥範例，使用的都是 gpt-live-1。如果有同事告訴你，外撥代理執行的是 1.1，理由是 ChatGPT 用的就是這個版本，那麼他們描述的是消費端產品，而非你的工作階段設定。

實務上：在你的計畫中引用 gpt-live-1，並將任何 1.1 API 的可用性視為獨立事件，在其當天另行驗證。

思考在哪裡發生，以及為何它是你能掌控的槓桿

GPT-Live 被一分為二。其文件本身的摘要指出，它「將推理與工具使用委派給後端，同時由它管理口語對話」。語音層負責處理時序、打斷與韻律；另一個獨立模型負責思考並呼叫工具。該後端會依工作階段在 delegation 下設定，模式為兩種之一。

• Responses 委派 — delegation.type: "responses"，需指定後端 模型，以及指示、工具、工具選擇、token 限制與服務層級。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 的中繼線，以及一個 sideband WebSocket 來監看響鈴、應答與 DTMF。請為中繼線預留一天，而不是為代理程式預留。

如果你使用的是 Realtime，請不要基於「這是組態變更」的假設來安排遷移。請先閱讀委派與工作階段章節，判斷你的後端應採用 OpenAI 的還是你自己的，然後再選擇合作夥伴——因為你目前用於傳入的合作夥伴，未必就是具有已記載傳出路徑的那一個。

如果你還在決定外撥語音到底值不值得打造，真正關鍵的數字是每接通一小時 $3.00（不含電信業者費用），對比兩小時硬性上限與三分鐘響鈴。這便宜到足以測試，也貴到讓等候時間成為一項設計決策，而非意外。GA 移除了門檻，但沒有移除這筆算術。