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 密钥即刻获取。添加付款方式并验证发送者身份后,即可解锁生产环境。

你的下一个创意。 随时连接。