深入理解 WebRTC 後，你會欣賞那些最初讓你沮喪的設計。——Sean DuBois

Pion 作為 WebRTC 開源領域的新興力量，憑藉其 Go 語言實現、高性能和可擴展性，迅速獲得廣泛關注，併成為眾多第三方項目的基礎架構。開發者可以利用 Pion 輕鬆構建高效且可定製的 WebRTC 解決方案，滿足從數據通道通信、音視頻流媒體到複雜應用場景的需求。

Pion 的創建者 Sean DuBois 在 Go 語言和 WebRTC 領域貢獻卓越，同時為 PHP 和 GStreamer 提供了重要支持。他不僅是 WebRTC 權威指南 《WebRTC For The Curious》的作者，還建立了一個充滿活力的 Pion 社區。

2024 年 9 月，Sean DuBois 加入 OpenAI 團隊，繼續在音視頻通信領域深耕，主要負責 Realtime API 相關的工作。

近期，Sean DuBois 在一期播客中探討了 WebRTC、WebSockets、SIP 等技術的應用與未來發展趨勢，涵蓋了從底層協議到實際應用場景的方方面面。他們不僅分享了各自對技術細節的獨到見解，還展望了 AI 時代音視頻通信的新可能性。

我們摘錄了部分精彩內容，希望能給大家提供一些新視野。Enjoy\~

核心要點

Sean DuBois

Pion 開源 WebRTC 項目創始人

目前在 OpenAI 工作

• WebRTC 的吸引力： WebRTC 的魔力在於它只需要少量代碼即可「連接世界」，簡化了實時通信的複雜性。
• WebRTC vs. WebSockets 的權衡： WebRTC 包含了回聲消除、編解碼器管理和碼率控制等關鍵組件，而 WebSockets 需要開發者自己構建這些，WebRTC 適用於複雜的、面向終端用户的應用。
• WHIP 協議的簡化： WHIP 通過 HTTP 協議簡化 WebRTC，便於集成到 FFmpeg 和 OBS 等工具中，支持嵌入式設備和更廣泛的互操作性。
• WebRTC 的延遲挑戰： WebRTC 的主要貢獻者對延遲需求不同的邊緣用例關注不足，延遲控制是一個挑戰。
• QUIC 作為 WebRTC 的潛在競爭者： QUIC 和 Media over QUIC 被視為超越 WebRTC、支持更多用例和提高靈活性的潛在方法，尤其是在語音 AI 領域。
• WebRTC 的隱藏用例： 除了會議，WebRTC 還有許多被低估的用例，例如遠程監考和在線拍賣，這些用例對延遲有極高的要求。
• SIP 在 AI 時代的復興： 電話技術，尤其是 SIP，在垂直領域 AI 應用中看到了新的增長，因為它無需應用安裝，方便用户使用。

WebRTC and AI in 2025

嘉賓：Sean DuBois，Pion 開源 WebRTC 項目創始人兼《WebRTC For The Curious》作者，目前在 OpenAI 工作

注：為便於閲讀，本文內容已作精簡，並非完整對話。你可以訪問原文收聽完整版播客。

「在各種與 WebRTC 相關的項目中轉悠，我很喜歡」

主持人： 你是 WebRTC 社區的堅定支持者，一位傑出的程序員。你編寫了很多代碼，很多人都在使用，包括所有使用 OpenAI 產品的人。先向大家介紹一下你自己吧。

Sean： 好的。我最初接觸的是 WebRTC 和電話技術，比如 Asterisk 之類的。後來，我想做更多服務器端的東西，所以做了 Pion，它是 WebRTC 的 Go 語言實現。我希望它更靈活，可以用一些奇特的方式工作。

之後，我一直在不同的 WebRTC 公司工作，包括為 AWS 做 C 語言嵌入式開發，還參與了 WebRTC FaceTime 和 Twitch 的廣播相關工作。

現在我在 OpenAI 做 Realtime API 相關的工作，包括 1-800-CHAT-GPT 和嵌入式應用。總之，一直在各種與 WebRTC 相關的項目中轉悠，我很喜歡。

WebRTC 的魔力：只需少量代碼即可連接世界

主持人： 我們是否應該簡單介紹一下 WebSockets、WebRTC 和 SIP？SIP 對很多應用場景來説非常重要，因為它是底層電話通信的粘合劑。我經常告訴別人，WebRTC 擅長某些方面，WebSockets 擅長某些方面，你需要對 SIP 有一些瞭解。我們都不太喜歡給別人建議，更傾向於提供一些技術定義。你很早就開始接觸 WebRTC，是什麼吸引了你？

Sean： 是的，我之前在 Etsy 工作，當時我們為各種視頻產品支付了大量費用，僅僅是為了在電腦上與他人進行電話會議。當 WebRTC 出現時，它簡直太神奇了，用很少的代碼就可以連接兩個端點。我當時寫了一個小機器人，通過 IRC 發送 Offer 和 Answer。那一刻，我愛上了它。我已經做了很多年 RTP 和相關的東西，所以用起來很舒服。但 WebRTC 在瀏覽器中就能運行，無需插件，而且效果很好，這讓我徹底着迷。從那時起，我就被它迷住了。

當你深入理解 WebRTC 後，你會逐漸欣賞那些最初讓你感到沮喪的設計

主持人： WebRTC 是一種內置於瀏覽器中的協議，現在在所有平台上都可用。它從一開始就被設計用於做極低延遲的音頻和視頻通信。OpenAI 最初發布了一個 API，就像很多人做的那樣，用於實時的語音 AI，但只支持 WebSocket。現在你添加了 WebRTC，或者説已經添加了。你對這方面的工程規劃是怎麼考慮的？

Sean： 對我來説，WebRTC 的吸引力在於兩點。最明顯的一點是它非常容易使用。你不需要了解音頻採樣率或編碼器，帶寬估計也是自動的，你只需要生成 Offer 和 Answer，然後就可以開始使用了。我認為這是最令人興奮的部分。就像你從你的客户那裏看到的那樣，即使是不懂技術的人，也可以用它來構建非常酷的東西。這是我喜歡 WebRTC 的第一個原因。

主持人： 但向人們解釋清楚 WebRTC 還是有點複雜的，至少對我來説是這樣。

如果你是一名程序員，並且編寫了很多代碼，那麼你幾乎肯定使用過 WebSockets。如果你想在服務器和應用之間建立一個長期的雙向通信通道，你可能會默認選擇 WebSockets。WebSockets 的 API 相當簡單易用，而且支持廣泛。

但是，如果你最初選擇了 WebSockets，你最終需要自己構建所有的組件，比如回聲消除、編解碼器管理、碼率控制等等。而且，你沒有足夠的控制旋鈕，無法構建一個在各種真實用户和網絡條件下都能穩定運行的產品。

另一方面，WebRTC 理解起來要複雜一些，有很多移動部件，API 也沒那麼簡單。雖然你在新的 OpenAI 產品中做得很棒，提供了非常清晰的 API，但總的來説，如果我向人們推薦 WebRTC，他們會感到有點不知所措。

但是，正如你剛才所説，所有你難以自己構建的東西都已經包含在 WebRTC 中了。所以我通常告訴別人，如果你只是在做實驗，為自己構建一些東西，或者做服務器到服務器的應用，那麼 WebSockets 就足夠了。但是，如果你真的想構建一個通過互聯網連接瀏覽器或移動應用的東西，考慮到終端用户互聯網連接的各種不可預測性，那麼你絕對應該花時間瞭解 WebRTC，並使用它。 否則，你最終會痛苦地發現你必須遷移到 WebRTC。

Sean： 我覺得很遺憾，許多人創造了令人驚豔的技術成果，但在需要添加多個視頻軌道時，問題便接踵而至。他們最初可能依賴於簡單的 WebSocket 協議，僅支持單一視頻緩衝區，而現在卻不得不將其拆分，以支持多種語言、添加和刪除軌道等複雜功能。此時，WebRTC 的複雜性開始展現其價值。這正是我創作《WebRTC for the Curious》的原因。我發現很多人初次接觸 WebRTC 時備受挫折，因為它看似繁瑣且令人望而卻步。然而，當你深入理解它之後，你會逐漸欣賞那些最初讓你感到沮喪的設計。

WebRTC 堪稱一個偉大的折衷方案，它在滿足各方需求之間取得了平衡，從而使開發者能夠繼續創新。人們利用 WebRTC 構建 VPN、安全攝像頭和廣播系統，應用廣泛。儘管許多人對 WebRTC 略有不滿，因為它的功能過於強大，但對於某些公司而言，WebRTC 的某些特性卻是其生存的基石。

我個人認為我無法設計出一個比 WebRTC 更好的協議。它凝聚了多年實踐經驗的結晶，而非簡單的「委員會設計」。很多人看到 WebRTC 的複雜性，就認為它是 2010 年代的委員會設計出的糟糕 API。但實際上，WebRTC 是建立在 2000 年代乃至 90 年代的技術基礎之上的，它融合了長達 30 到 40 年的設計和考量。設計者們早已預見並解決了許多問題。我很難相信我能簡單地敲出一個基於 WebSocket 的解決方案，就能與 WebRTC 在所有權衡中相媲美。

主持人： 是的。你是想要 20 毫秒的開放幀時間，還是想要 40 毫秒的開放幀時間？諸如此類。

Sean： 沒錯，還有 H.264 配置文件。我們還沒有討論你需要哪些擴展頭來表示視頻方向。這些問題沒完沒了。這就是為什麼我喜歡待在這個領域裏。

WHIP 協議：簡化 WebRTC，擁抱嵌入式與互操作性

主持人：我對 OpenAI API 中新的 WebRTC 設計持有一些懷疑態度。它構建在 WebRTC 協議棧的一些較新的擴展之上。你想談談 WHIP 以及你是如何考慮它的嗎？

Sean： 在傳統的 WebRTC 架構中，Offer 和 Answer 作為信息塊存在，協議本身並不限定其傳輸方式。例如，可以通過 WebSocket、Protobuf 或基於 IP 的 Avro 協議來傳遞這些信息，只要能成功完成傳輸即可。而新的 WHIP 標準則強制規定 Offer 和 Answer 的交換必須通過 HTTP 協議進行，並採用特定的 URL 格式，同時需要發送帶有 Bearer 令牌的 HTTP 授權頭部。實際上，WHIP 嚴格限制了 Offer 和 Answer 的交換方式。

這種限制具有重要意義，因為對於像 FFmpeg 和 OBS 這樣的工具，用户無法自定義編寫代碼，只能提供 URL 和輸入字段。這正是 WHIP 誕生的原因。我觀察到兩點：首先，用户希望使用這些工具來訪問實時 API，以便發送廣播流和安全攝像頭數據，而這些工具不支持代碼編寫。另一方面，WHIP 的設計靈感也來自嵌入式系統。我曾經參與過一個嵌入式項目，該項目使用了一個 WebRTC 服務器，需要兩個對等連接和一個 WebSocket，這在微控制器上消耗了大量的資源。因此，在設計 OpenAI 的 API 時，我希望儘可能保持其簡單性，以便支持各種輕量級的客户端。如果像智能門鈴這樣的設備，成本僅為 25 美元，卻能夠發送音頻並連接到實時 API，我認為這將是非常有價值的。WHIP 的設計目標正是為了實現這兩點：支持現有的工具，並保持客户端的輕量級。

另一個讓我感到興奮的點是不需要使用 SDK。根據我使用 Pion 的經驗，用户希望在各種不同的環境中使用 WebRTC。我非常喜歡看到人們使用 Elixir 和 GStreamer 來訪問實時 API。如果我要求用户下載包含 500 行專有代碼的 JS SDK，並將它移植到各種不同的平台，這無疑會帶來巨大的麻煩。但是，如果我們將 API 設計得儘可能簡單，用户就可以做更多有趣的事情。

最後，我非常期待供應商之間的互操作性。每個供應商都可以在某個特定領域發揮其優勢。例如，可以將視頻發送到某個特定供應商，然後供應商可以將視頻發送到其他地方。每個參與者都專注於自己擅長的領域。如果我們擁有這些簡單且標準化的協議，那麼對構建者、開發者和用户來説都將是更有利的，因為他們可以輕鬆地發送和接收 WebRTC 數據，而不必被限制在某個特定供應商的生態系統中。

主持人： 您提出的觀點都非常有道理，我十分贊同。尤其是在 WebRTC 發展初期，缺乏供應商之間的互操作性是一個顯著的問題。這主要是由於信令層協議的通用性不足，難以適應所有應用場景。 因此，WebRTC 標準並未對信令進行規定，導致每個開發者都需要從頭開始構建信令機制，從而阻礙了不同 WebRTC 平台和工具之間的真正互操作。WHIP 標準在很大程度上解決了這個問題。

但我必須承認，SDK 對於封裝複雜性至關重要。 例如，當 RTP 連接中斷時，應如何處理？如果將這個問題拋給應用程序員，他們可能會難以找到正確的解決方案。類似的問題還有很多。

構建一個相對完善的 SDK 是抽象出所有這些複雜問題的必要途徑。然而，大型 SDK 也存在明顯的缺點，例如無法在資源有限的嵌入式設備上運行。現在，您已經發布了嵌入式 C 代碼，我非常期待能夠讓我的小型機器人完全支持 WebRTC。

Sean： 是的，我認為這反映了我們解決問題思路上的差異。

您花了很多時間與那些不關心 WebRTC 細節的企業合作，當然這不是貶義。他們的目標是構建出色的產品，而沒有精力深入研究技術細節。因此，您對如何構建 SDK 以及如何解決相關問題有着深刻的理解。

然而，就我而言，無論是通過 WebRTC for the Curious 還是 Pion 項目，我與用户的交流方式更多的是鼓勵他們擁抱細節，並認為細節本身藴含着價值。我認為這是我思考方式上的一個固有特點，它有利有弊。我不太願意將細節從用户面前抽象出來，因為我相信每個人都具備理解這些細節的能力。我希望提供工具，但對於那些尋求「給我一個 SDK，因為我只想快速完成工作」的開發者，我很難完全理解他們的訴求。 我相信會有其他人構建出色的 SDK，並以合理的方式抽象出細節。您在 SDK 設計和相關思考方面比我更擅長。事實上，這多年來一直是我在設計產品時面臨的一個長期問題。

技術深度 vs.易用性，不同的設計哲學**

主持人： 哦，不，我認為這是一個很大的優勢。圍繞 Pion 構建的生態系統非常出色，正是因為您採取了這種方法，即 構建模塊的粒度 對於希望構建應用的人來説非常有意義，他們不需要從頭開始構建，而是可以採用一種合理的方式進行組裝。Pion 實現的各個組件非常清晰，沒有隱藏過多的細節，閲讀這些代碼是一種享受。這歸功於您，因為您貢獻了大量的代碼，並且構建了一個擁有活躍互動的健康社區。我認為每個人都應該閲讀《WebRTC for the Curious》。

有趣的是，根據我們的經驗，一些最糟糕的客户，從他們遇到困難、佔用大量支持時間以及難以擴展的角度來看，恰恰是那些決定調整所有可配置參數的工程團隊。這是因為存在一條這樣的曲線：你首先讓一些東西能夠正常工作，然後你就會想，我不喜歡 720p 視頻，我想要 1080p 視頻。我們現在有很多幫助文檔，其中明確指出：「好的，這是缺點。你可以使用 1080p，你可以使用 4K。但是，以下情況將會發生。」

然而，有些工程師閲讀了我們發送給他們的所有信息，卻完全不相信這些警告。於是，他們為移動設備上的最終用户配置了 4K 視頻。你會覺得不可思議，我們已經明確告知過這種配置行不通。它可能在你的 iPhone Pro 上，在你的光纖連接上運行良好，但對於你的用户來説，這種配置是不可行的，這裏的「你的用户」是指超過 60% 的用户。當 40% 的用户遇到問題時，你就無法實現規模化擴展。所以，從我們所針對的不同人羣的角度來看，確實存在着不同的需求和緊張關係，這非常有趣。

Sean： 是的，我也很喜歡那些用户。我喜歡那些提出獨特需求的人。如果有人要投資我所做的任何項目，我都會過度關注那些看似無法產生收益的長尾需求，因為我喜歡那些對新奇事物和細節感興趣的人，這會讓我感到興奮。這非常有趣，我完全贊同。

不過，回到您之前提到的，我個人對 Pion 提供的基本構建塊感到非常滿意。然而，目前有很多服務器都是基於 Pion 構建的，我認為這在一定程度上表明，對於某些用户而言，Pion 仍然不夠完善。但我實際上很喜歡這種情況，因為我真正樂於與之交流的人恰恰是那些構建服務器的人。我非常享受這種過程，我喜歡就此進行深入的探討和交流。

我現在還在進行另一個名為 Broadcast Box 的項目，這是一個面向終端用户的服務器。每當有人來找我説，他們只是希望一切都能正常運行，甚至不理解背後的原理時，我都會感到有些失落。他們僅僅是希望屏幕上能夠顯示視頻，一旦視頻出現，他們就會立即離開。我認為，當大家共同參與構建某些事物時，會存在一種獨特的美感，但當目標僅僅是「我只想讓它工作」時，這種美感就會消失。但我想這只是一段無關緊要的題外話。總而言之，這就是我構建產品的方式，也導致了它們最終呈現出現在的形態。

Broadcast Box：低成本、高互動、更安全的 WebRTC 廣播的未來

主持人： 我認為人們會很想知道 BroadcastBox 的動機是什麼。

Sean：是的。Broadcast Box 實際上是用於將 WHIP 集成到 OBS 中的一個參考實現。WebRTC 廣播讓我感到興奮的原因是，我感覺廣播技術已經落後了大約 10 年，因為技術限制使得我們無法實現很多想法。

首先，運行廣播服務的成本非常高昂。因此，很少有人會嘗試這樣做。但是，藉助 WebRTC 和 Simulcast 技術，我們可以將編碼過程放在客户端，從而大幅降低成本。其次，WebRTC 的延遲非常低。這意味着當您向觀眾進行廣播時，能夠建立一種更親密的互動關係。您可以擁有一小羣朋友，他們觀看您的遊戲並與您進行交流，而不是向一萬名觀眾進行廣播，僅僅是被動地與他們互動。我認為這是一種更好的社交體驗。這正是讓我感到如此興奮的原因。

我也很喜歡 WebRTC 具備端到端加密的特性。我希望能夠先於某些公司解決一個潛在的問題：我預計將來可能會有一些公司想出辦法直接將廣告插入到視頻流中，從而實現廣告的完全無法屏蔽。我想在他們之前，利用 WebRTC 和端到端加密技術，讓內容創作者能夠掌握自己的密鑰，並將它們提供給觀眾，從而阻止中間人篡改視頻。 我認為這種方法非常酷。

此外，移動性也是一個重要的優勢。WebRTC 的設計允許我在手機上進行廣播，並在蜂窩塔之間切換，以及在 Wi-Fi 和蜂窩網絡之間無縫切換。這讓我感到非常興奮，因為如果人們能夠獲得更好的 IRL（In Real Life，現實生活）直播體驗，那將會很棒。目前，要實現這一點非常困難。人們需要揹着揹包，使用故障轉移機制，將 RTMP 數據發送到服務器，然後服務器負責確保連接的穩定性。如果他們只是使用一種沒有硬連接的協議，所有這些問題都會迎刃而解。

因此，我總是鼓勵大家，如果有人問我對廣播的未來有什麼看法，我希望它能夠朝着這個方向發展。

WebRTC 的多重挑戰：延遲挑戰、Google 主導與開源抉擇

主持人： 關於這些協議的演變，您提出了一個非常有趣的觀點。RTMP 仍然是 Twitch 和 YouTube Live 的標準，但它確實是一個非常古老的協議。它最初是 Macromedia Flash 的視頻協議，然後在 JavaScript 出現之前，由於 Flash 曾經短暫地主宰了整個交互式網絡，它得到了某種程度的半標準化。但是，Flash 後來被 Adobe 收購，並被整合到那個大型公司實體中。Macromedia 在某種程度上被放棄了。然後，史蒂夫·喬布斯從 Safari 中砍掉了 Flash。因此，這個孤立的協議從未真正得到標準化，也沒有任何一方能夠真正掌控它。所以，沒有人能夠對其進行演變。但是，即便已經過去了 20 年，它仍然內置於 OBS 中，並且是所有這些平台的默認設置。雖然它能夠正常工作，但正如您所説，到了 2025 年，我們確實需要更好的替代方案。

WebRTC 正是其中的一部分。我們觀察到使用 WebRTC 進行廣播的客户所面臨的挑戰是，它的延遲太低了。 如果你使用 RTMP、HLS、DASH 或其他視頻流協議，那麼很難將延遲降低到 3 秒以下。如果你要做任何交互式的事情，這都顯得太長了。WebRTC 在某種程度上是因為標準本身，但在某種程度上也是因為所有實現的編寫方式，很難將延遲提高到 300 毫秒以上。這是一個巨大的差距：300 毫秒與 3 秒。

有時候，你真正需要的可能是 800 毫秒的延遲，因為你可以通過更大的緩衝區來調整視頻質量。如果你要做一些交互式的事情，但它實際上並不是實時的對話，那麼 800 毫秒的延遲可能就足夠了。但目前似乎並沒有一種方法能夠實現這個目標。您有沒有考慮過 我們如何找到一箇中間地帶 ？

Sean： 至少對於 OBS 來説，我儘量保持 3 秒的緩衝大小。因此，接收方可以積極地請求重傳這 3 秒的數據，並且服務器可以在這段時間內進行緩衝。但是，在瀏覽器中，沒有 API 可以實現這一點。我不知道。我認為這正是長期以來困擾 WebRTC 的一個問題。WebRTC 的主要貢獻者們主要通過會議協議來盈利。因此，如何説服他們去關注這些邊緣用例呢？

主持人： 我認為谷歌是 WebRTC 規範的主要仲裁者，這是一件好事，但有時也會令人沮喪。谷歌對 WebRTC 的這種仁慈的資助和控制是絕對關鍵的。我認為如果沒有谷歌，WebRTC 就不會成為一種普遍存在的標準。有時你提交 PR 或錯誤報告，但當谷歌團隊認為它們不夠重要或不夠有趣時，它們就永遠不會被採納。

Sean： 是的，我也不知道哪種方式更好。我經常在開源項目中看到這個問題：是憑藉企業贊助者的力量加速你的發展速度更好呢？還是獨自前行，做出對每個人都更好的東西更好呢？我不知道。我在編程語言中也看到了這一點。 Rust 和其他一些語言有贊助者，因此它們的發展速度更快，但社區本身卻不那麼令人愉快。這是一個非常哲學的問題。太有趣了。

如果我的生活就是 WebRTC 和 Go，那麼在某種意義上，我就擁有谷歌公司的一切。我編寫的協議和我編寫的語言都屬於谷歌。我真的應該站出來説幾句。谷歌願意花 3.6 億美元購買 GIF 是一筆瘋狂的金額。所以，總之，WebRTC 的存在是因為谷歌購買了軟件並將其開源。是的，我不知道。現在就是這樣了。

QUIC 與 Media over QUIC：WebRTC 的未來競爭者？

主持人： 你提出的觀點非常重要。在我們的這個視頻和網絡黑客的小世界裏，很多人都認為，超越 WebRTC、找到中間地帶、支持更多用例、提高靈活性和創造性的方法是 QUIC 和 Media over QUIC。

我經常與那些正在研究如何構建語音 AI 產品的人進行對話。有時他們已經做了一些研究，然後他們會説：「我只是在等待 QUIC。」 我也經常和他們説，現在我們看到的語音 AI 和對話式多模態 AI 用例與會議用例非常不同，而會議用例是 WebRTC 的核心和靈魂。WebRTC 在很大程度上滿足了這些用例的需求，但我一直在思考，我們可以重新構建哪些構建塊，以便更高效、更靈活、更易於破解，更適合語音 AI 用例。

然後，當你將其擴展到「這實際上可能是一個向 Media over QUIC 過渡的催化劑」時，我真的認為，在幾年內，我們可能會看到 QUIC 在這些新用例中的採用，而如果沒有這些新用例，我們就不會走出那個困境。

Sean： Media over QUIC 組織構成多元，包含諸多內容分發網絡（CDN）和視頻領域從業者。我很好奇最終會如何發展。借鑑以往經驗，IETF 工作組雖曾解決諸多重要問題，但最終可能因標準過於複雜而難以實際應用，希望 QUIC 不會重蹈覆轍。

具體而言，視頻內容若過度複雜化，或將導致用户出於效率或兼容性考慮，仍舊選擇 WebRTC 等現有方案。 QUIC 協議的核心機制雖具優勢，但與實時性需求存在一定差異。 因此，要實現真正可用的 Media over QUIC，仍需進行大量工作。我認為這是可能的。 我對標準委員會的部分工作表示讚賞，但也注意到其潛在的發展方向存在風險。CDN 服務商的需求合理且重要，但與實時應用的需求存在顯著差異。若 Media over QUIC 的發展方向過度迎合 YouTube 或 Twitch 等大型平台的需求，可能無法滿足新興的對話式人工智能等實時應用場景。 因此，我期望業界對新興對話式 AI 用例保持足夠的熱情，以平衡 CDN 需求對標準發展方向的影響。

進一步的問題在於，新的方案是否能夠滿足所有基於 WebRTC 的現有應用場景，例如安全攝像頭監控和遠程監考等。特別是遠程監考，我曾經在 AWS 工作時發現，這是一個規模龐大的業務。 很多人可能認為 WebRTC 主要用於會議，但遠程考試的使用頻率可能遠超會議，因為它幾乎時刻都在進行。遠程監考需要監考人員觀看考生的視頻，並且通常需要同時開啓多個攝像頭，例如拍攝手部和房間環境。 總之，WebRTC 的實際應用範圍可能遠超我們的想象，甚至最活躍或最流行的用例可能正是我們習以為常卻未曾注意到的領域。

意想不到的 WebRTC 用例：從遠程監考到在線拍賣**

主持人： 有趣的是，遠程監考是最早嘗試引入 AI 技術的領域之一。與當前流行的生成式 AI 對話技術不同，他們主要利用計算機視覺算法、語音匹配算法、面部檢測和視線跟蹤等技術，來檢測考生是否作弊。 遠程監考本身就是一場貓鼠遊戲，因為學生們會不斷尋找新的作弊方法。這些公司告訴我，僱傭一名人工監考人員的成本很高，而運行 AI 算法的成本相對較低。 這種成本對比凸顯了遠程監考領域中 AI 應用的獨特價值。

另一個令我印象深刻的用例是澳大利亞一家公司利用 WebRTC 進行牛的競拍。他們對延遲的要求極為苛刻，必須達到 7 毫秒，因為任何視頻流延遲都可能導致競拍失敗，從而造成損失。

主持人： 是的。我們也有一個這樣的客户。當時我就想，我不知道牛的拍賣風險這麼高。

Sean： 牛的拍賣風險很高，這取決於你競拍的是什麼。

SIP 在 AI 時代的復興

主持人： 這些應用場景非常有趣。我們應該簡單談論一下 SIP，因為我們觀察到越來越多的客户認為垂直領域 AI 是真實存在的，例如為醫療機構提供電話接聽服務。有很多客户正在從事這方面的工作，並且業務規模還在不斷擴大。

我過去從未想過大型語言模型可以通過電話與人進行對話，並且對各方都有顯著的價值。從傳輸方式的角度來看，我們目前看到電話技術比 WebRTC 有更多的增長。您是否也觀察到了同樣的趨勢？ 您之前做過一些與 SIP 相關的工作，它是如何融入到這些場景中的？這對於您來説，是否有點像一次懷舊之旅？

Sean： 是的，我之前為 1-800-CHAT-GPT 做過電話相關的工作。 這樣做的一個好處是隻需要維護一個代碼庫。因為它們都使用相同的底層協議，所以我能夠輕鬆地將代碼遷移到一個公共文件夾中，從而同時支持兩種技術。

我對未來發展方向非常感興趣。我們現在還在使用的電話技術，例如 SIP，最初是為了與傳統電話線路通信而設計的。 但現在一切都已經是數字化的了。所以我們實際上在進行數字信號到模擬信號，再到數字信號的轉換。 我認為這非常令人興奮，因為它為那些不習慣安裝應用程序的用户打開了所有這些 AI 體驗的大門。這甚至不僅僅是習慣問題，安裝和使用應用程序的成本也太高了。 尤其是在很多國家，用户需要為下載應用程序付費。期望用户支付幾美元來下載一個幾百兆字節的應用程序是不現實的。 直接撥打電話號碼就能正常工作，這簡直太棒了。

AI 電話助手：用 LLM 打造私人秘書

主持人： 我也很喜歡電話互聯。 我有一個待辦事項機器人，它每天會在固定的時間打電話給我，以確保我按計劃行事。它會詢問我今天的優先級是什麼，以及需要完成哪些任務。然後，我會告訴它我完成了什麼，它會檢查這些是否與我昨天告訴它的相符。 我喜歡自己構建這些工具，這樣才能真正理解它們。 我發現電話通話是一件非常有用的事情。 我可以以不同的方式實現提醒功能，例如發送短信鏈接，或者使用原生移動應用播放聲音併發出警報。但電話通話有着獨特的吸引力，即使對於這種簡單的使用場景也是如此。

主持人： 我喜歡 POTS 首字母縮略詞，它代表 Plain Old Telephone System。

Sean： 沒錯。

主持人： 這是一個很棒的經典縮略詞。如果你試圖弄清楚如何將 LLM 連接到電話，你還會經常聽到 PSTN（Public Switched Telephone Network）這個縮略詞。

現在越來越多的類似技術涌現出來。我現在的理解是，這有點像正則表達式剛出現的時候。早期，對於文本解析，人們總是爭論是否應該手寫解析器，還是應該編寫一個複雜的正則表達式。 兩種方式各有優缺點。

非常感謝你。和你聊天非常開心。

Sean： 我也很開心。

原播客：https://www.youtube.com/watch?v=l_rTdVuA4Lw

編譯：施蘇娜、傅豐元

閲讀更多 Voice Agent 學習筆記：瞭解最懂 AI 語音的頭腦都在思考什麼