WebRTC 与 SIP,浏览器或 AI 代理该用哪个?

WebRTC 承载浏览器媒体,SIP 处理呼叫信令,因此基于浏览器的 AI 代理两者都要用。

浏览器和桌面电话可以作为同一通话的两端,即使它们处理媒体的方式不同。

在两者之间做选择,等于把故意分配给某一层的功能当作属于另一层。

它们是替代关系吗?

不是。它们处于不同的层,各自留下了对方负责的工作。

SIP 是信令。 它查找对端、协商要交换的媒体类型、振铃、建立连接并拆除通话,但不承载音频。RFC 3261 划定了这个边界:"SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture."

WebRTC 是浏览器自带的媒体栈。 它在两个端点之间传输音频和视频,穿越网络地址转换(这正是浏览器之间直接通信困难的原因),并加密媒体。其规范 RFC 8825(2021 年 1 月发布的 IETF 标准跟踪文档)指定媒体格式为 RTP,并要求使用 SRTP:"Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations"。

SIP 安排通话但不承载媒体。WebRTC 承载媒体但不安排通话。

WebRTC 省略了什么?为什么?

WebRTC 省略了信令,而且是故意为之:规范将信令协议的选择置于自身范围之外。

RFC 8825 将这一架构描述为梯形。媒体直接在两个浏览器之间传输,信令则通过服务器传递,"can modify, translate, or manipulate the signals as needed"。规范没有指定信令协议:

The choice of protocols for client-server and inter-server signaling, and the definition of the translation between them, are outside the scope of the WebRTC protocol suite described in this document.

这不是等待修复的遗漏,而是一种有意的设计:聊天应用可以通过自己的 WebSocket 消息进行信令,电话平台可以通过 SIP 进行信令,底层使用的是同一个媒体栈。同一文档直接提到了电话方案,描述了在浏览器和服务器之间使用 "a standardized signaling mechanism (e.g., SIP over WebSockets)" 的部署方式。

基于 WebSocket 的 SIP 在 RFC 7118(2014 年 1 月发布)中定义,其中规定了 "a WebSocket subprotocol as a reliable transport mechanism between SIP entities to enable use of SIP in web-oriented deployments"。它改变的是 SIP 消息的传输方式而非内容,因此浏览器和桌面电话可以作为同一通普通通话的两端。

在 Bird 上是什么样的?

要通过 Bird 连接浏览器,使用基于 WebSocket 的 SIP。

控制面板自带的电话就是一个实际示例。浏览器充当 SIP 客户端。控制面板为其生成一个短期会话凭据,而不是将长期密钥暴露在页面中。API 将凭据的 handshake_token 描述为 "Short-lived token required when upgrading the WebSocket connection"。它 "authorizes the connection only; each call still authenticates with password"。握手令牌授权连接,密码则认证每次通话。

浏览器兼容性取决于中继的摘要算法。浏览器响应 SIP 摘要质询时只使用 MD5,不支持其他算法。中继仅接受自身提供的算法。如果中继配置为仅提供 SHA-256,则会拒绝所有浏览器通话,包括控制面板的电话。在提供列表中保留 MD5 才能让中继接受来自浏览器的通话,SIP 中继中介绍了该设置。

除此之外,该通话落在同一条中继上,检查同一个已验证的主叫号码,遵守同样的已启用目的地,并生成与来自 PBX(负责路由公司通话的企业电话系统)的通话相同的记录。

那我该用哪个?

根据端点运行位置来选择,无论哪种情况都要用到 SIP。

WebRTC 要求加密媒体。SIP 中继的 TLS 传输加密的是传输中的信令而非音频。因此加密审查需要覆盖两条路径。

  1. 浏览器。 网页使用浏览器的 WebRTC 栈处理媒体,这部分已确定。你需要选择信令方式。SIP 将其连接到电话网络,而不仅仅是连接到其他浏览器。
  2. 桌面电话、PBX(在网络边界路由公司通话的业务电话系统)或会话边界控制器(SBC,在网络边界控制通话的设备)。 通过 UDP、TCP 或 TLS 使用普通的 SIP。WebRTC 对已经支持 RTP 的设备没有意义。
  3. 语音 AI 代理。 取决于你的运行时已实现了什么。在浏览器中运行或基于浏览器媒体 API 构建的代理会使用 WebRTC,需要附加信令。基于电话栈构建的代理直接使用 SIP 和 RTP。什么是语音 AI 代理介绍了该路径的其余部分,包括代理需要终结音频而不仅仅是信令。

简而言之

  1. 这个问题比较的是两个不同的层。

    WebRTC 是浏览器的媒体栈,不包含信令协议。SIP 是信令协议,不承载媒体。两者互不替代。

  2. WebRTC 故意不包含信令。

    WebRTC 自身的概述将信令协议的选择置于规范范围之外,并将基于 WebSocket 的 SIP 列为填补这一空缺的标准方式之一。

  3. 通过 Bird 发起的浏览器通话就是一次 SIP 通话。

    浏览器充当 SIP 客户端,连接通过短期令牌升级为 WebSocket,每次通话仍使用摘要密码进行认证。

  4. 加密在两者中分处不同位置。

    WebRTC 要求使用 SRTP 加密媒体。SIP 中继的 TLS 传输加密的是信令,与音频是两回事。

付诸实践。

继续查看此主题的文档、指南和示例。

获取实施简报

基于同一网络构建。

测试 API 密钥即刻获取。添加付款方式并验证发送者身份后,即可解锁生产环境。

Start building with Bird in minutes.