For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
主要導覽

電話通訊與 SIP

選擇 SIP 連線或應用程式音訊橋接來處理電話通話。

選擇應用程式使用的 API。每個 API 都有各自的身分驗證、工作階段建立與事件規範。

選擇電話通訊連線方式

電話通話可以透過 SIP 中繼線,或透過轉送音訊的應用程式連接至 GPT-Live。請根據現有電話系統,以及應用程式需要在哪個環節處理音訊,選擇合適的方式。

連線音訊處理與應用程式職責
SIP 直連供應商與 OpenAI 交換通話音訊。應用程式則負責處理 webhook、工作階段組態、通話決策與業務邏輯。
伺服器音訊橋接應用程式透過 WebSocket 將供應商或房間的音訊轉送至 GPT-Live,並負責管理兩端的連線、事件轉換、播放與通話生命週期。

供應商與應用程式之間的連線,以及應用程式與 OpenAI 之間的連線,彼此獨立。例如,來電者可以透過 SIP 加入房間,而房間內的智慧體則透過 WebSocket 連接至 GPT-Live。

使用 Twilio、Telnyx、LiveKit 或 Daily/Pipecat?請參閱 GPT-Live 合作夥伴整合,查看各供應商的專屬指南。

SIP 直連

SIP 直連讓通話音訊沿著供應商與 OpenAI 之間的媒體路徑傳輸。SIP 信令使用 TLS,而 GPT-Live 要求通話音訊使用 SRTP。後端仍負責來電決策、工作階段組態、授權與業務邏輯。

當後端需要接收工作階段事件或傳送指令時,請使用側頻連線。它會附接至現有對話,而音訊仍由 SIP 傳輸。請為每個動作指定一個處理常式,以免 webhook 重複送達,或多個連線觀察到同一事件時,導致工具重複執行。

請將 SIP 路由與供應商組態,和使用這些設定的整合一併管理。Realtime webhook 事件、通話識別碼與接受來電的酬載屬於 Realtime API;Live 工作階段應使用 GPT-Live 規範。

處理通話生命週期

使用此流程前,請確認專案已啟用 GPT-Live SIP 支援,且供應商的 SIP 中繼線已路由至該專案。另一個分頁中的 Realtime webhook 與接受來電酬載遵循的是不同的 API 規範。

接收來電

為專案的webhook 端點設定 live.transport.incoming 事件。做出通話決策前,請驗證 webhook 簽章,並排除重複送達的事件。確認收到 webhook 並不代表接受來電。

Webhook 透過 data.type: "sip" 識別 SIP 通話,並提供 data.session_id。所有 Live 通話動作都必須原樣使用該工作階段 ID。請將 data.sip_headers 視為不受信任的來電者中繼資料,不可作為授權依據。

現有整合可能仍會收到已棄用的 live.call.incoming 事件,此事件不含 data.type。遷移期間,請同時處理兩個事件名稱,並保留舊訂閱,直到舊版事件的傳送與重試全部完成。同一通待處理來電也可能觸發 Realtime webhook;請指定單一處理常式負責接受或拒絕來電的決策,不要透過兩個 API 同時接受來電。

接受或拒絕來電

套用應用程式的授權與路由規則。若要接受來電,請傳送已通過身分驗證的 POST /v1/live/sessions/{session_id}/accept 請求,並包含最上層 session 物件:

{
  "session": {
    "type": "live",
    "model": "gpt-live-1",
    "instructions": "You are answering an inbound support call.",
    "audio": { "output": { "voice": "marin" } },
    "delegation": { "type": "client" }
  }
}

請從受信任的後端使用 Authorization: Bearer $OPENAI_API_KEY 傳送通話控制請求。接受來電時,請選擇語音與委派模式。音訊格式由 SIP 協商,因此請省略 audio.format。此範例選用用戶端委派,因此後端必須處理受委派的工作。如需用戶端與 Responses 組態,請參閱委派與工具

成功接受來電後,會在工作階段初始化完成時回傳 200 OK,回應本文為空。請先處理 HTTP 錯誤,再將來電視為已接受。

若要拒絕來電,請傳送 POST /v1/live/sessions/{session_id}/reject 並附上 SIP 狀態,例如以 { "status_code": 486 } 表示忙線。狀態必須是 300 至 699 之間的整數。最先做出的接受或拒絕決策會生效;之後競爭同一來電的決策會回傳 decision_already_made

附接後端

接受來電後,請透過 wss://api.openai.com/v1/live/sessions/{session_id}/attach 建立側頻 WebSocket 連線。使用已接受來電的工作階段 ID,以及相同的專案身分驗證與連線標頭。請勿再次傳送 session.start

SIP 負責傳輸通話音訊。側頻則用於逐字稿、委派、工具、指令與鏡射音訊。即使多個連線都觀察到同一事件,也請為每項副作用指定單一負責方。

觀察鍵盤事件

來電者按下按鍵時,側頻會收到 transport.dtmf.received;託管工具成功傳送按鍵音後,則會收到 transport.dtmf.send。事件的 event 欄位包含 09*#AD 其中一個值。

這些是提供給觀察端的通知,不是用戶端指令。請勿傳送 transport.dtmf.send 來要求傳送按鍵音,也不要假設瀏覽器資料通道會收到鍵盤事件。

轉接或結束通話

若要轉接通話,請傳送 POST /v1/live/sessions/{session_id}/refer,並以 { "target_uri": "sip:agent@example.com" } 指定目的地。若要掛斷通話,請傳送不含請求本文的 POST /v1/live/sessions/{session_id}/hangup。兩者成功時都會回傳 200 OK,回應本文為空。

釋放應用程式資源前,請保持側頻連線開啟,以接收最後的事件與用量資料。掛斷請求成功或連線意外中斷,都不能取代 session.closed。如需瞭解收尾處理與關閉原因,請參閱用量與正常關閉

此流程用於接受來電。不支援透過 POST /v1/live/sessions 建立撥出的 SIP 通話;若要由供應商負責撥出通話,請使用相關的合作夥伴整合

伺服器音訊橋接

當應用程式從電話服務供應商或智慧體框架接收音訊串流時,請使用 GPT-Live WebSocket 連線。應用程式負責兩端連線的身分驗證、轉換各自的事件封裝格式,並雙向轉送音訊。

GPT-Live 支援透過 WebSocket 傳輸 8 kHz 的原始 G.711 μ-law 與 A-law 音訊。當供應商串流使用相同的編解碼器、取樣率與聲道數時,應用程式可以直接轉送原始音訊位元組,無須轉換成 PCM。請維持音訊順序,並使用各連線要求的訊息格式。音訊格式相同並不代表兩種事件通訊協定可以互換。

橋接程式也負責管理其排入播放佇列的所有音訊。設計應用程式時,請納入供應商端的緩衝、插話中斷與結束通話的處理。如需瞭解 Live 工作階段生命週期,請參閱管理工作階段;如需瞭解發言輪替與播放控制的變更,請參閱遷移至 GPT-Live

請將供應商的通話或房間識別碼與 OpenAI 工作階段 ID 一併保留,以便跨兩個系統追蹤同一段對話。

GPT-Live 後續步驟