深入理解 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

编译：施苏娜、傅丰元