RTCPeerConnection 配置详解之 bundlePolicy

aixfe
2,786 阅读4分钟

先上结论，在使用浏览器和 Janus 互动时，RTCPeerConnection.bundlePolicy 最终视频和音频的传输都是使用一个端口，不同的取值影响的注意是 ICE 协商阶段，建议使用 "max-bundle" 提高 ICE 协商速度。

官方定义

RTCPeerConnection.bundlePolicy 指定了当远程对等方不兼容标准 SDP BUNDLE 时如何处理候选项的协商，默认值为 "balanced"。

const pc = new RTCPeerConnection({ bundlePolicy: 'max-bundle' });

如果远程端点时 BUNDLE 感知的，则在协商完成时，所有媒体轨道和数据通道都被捆绑到一个单一的传输上，而不管使用的策略如何，并且最初创建的任何多余的传输都在此时关闭。

所有浏览器实现都是 BUNDLE 感知的。

枚举值说明

"balanced"（默认值）：ICE 代理为每种使用的媒体类型（视频、音频和数据）收集 ICE 选项。如果远程端点不支持捆绑，在单独的传输上仅协商一个音频和视频轨道。

"max-compat"：ICE 代理为每个轨道收集 ICE 选项。如果远程端点不支持捆绑，在单独的传输上协商所有的媒体轨道。

"max-bundle"：ICE 代理只收集一个轨道候选项。如果远程端点不支持捆绑，仅协商一个媒体轨道。

SDP BUNDLE

学些 RTP 的 rfc 文档时，2.2 节说明，如果会议中同时使用音频和视频媒体，则他们是使用单独的 RTP 会话传输 RTCP 数据包，每个媒体使用两个不同的 UDP 端口对或多播地址。

datatracker.ietf.org/doc/html/rf…

按照这种方式，如果是 5 个人同时开会的场景，每个浏览器上需要协商的端口有 2 个发布流的端口可以 4x2 个受流端口，一共需要协商 10 端口，在和后端沟通的时候收到的反馈是视频和音频传输用的是同一个端口，继续看 RFC 文档中的 5.2 节，专门有复用 RTP 会话的说明。

datatracker.ietf.org/doc/html/rf…

复用 RTP 会话的情况下，同样是 5 个开会的场景，每个浏览器需要协商的端口数量是 5 个，在 Janus 的实现中，可以通过信令通知 Janus 不要发送视频或者音频给客户端，也能实现只订阅视频或者音频的需求。

对各个取值的理解

使用 "max-bundle" 时只协商为一个轨道收集候选项，速度最快，兼容性最差，当远端不支持 SDP 捆绑是，只能传输一个视频轨或者音频轨。

使用 "max-compat" 时为每个轨道收集候选项，速度最慢，兼容性最差，当远端不支持时也能正常传输所有媒体数据。

使用过程中，Janus 和浏览器都是支持 SDP 捆绑的，所以最终的传输都是使用一个端口，不同的取值影响的注意是 ICE 协商阶段，使用过程中使用 "max-bundle" 。

实际环境进行验证

使用一台 Janus 服务器和一个电脑进行验证，查看信令数据中浏览器上报的 candidate 信息

信令及抓包文件备份位置

max-bundle

candidate:360945858 1 udp 2122260223 172.25.64.1 49885 typ host generation 0 ufrag LzwC network-id 1
candidate:6840418 1 udp 2122194687 192.168.0.23 49886 typ host generation 0 ufrag LzwC network-id 2

max-compat

candidate:360945858 1 udp 2122260223 172.25.64.1 53782 typ host generation 0 ufrag HtWM network-id 1
candidate:6840418 1 udp 2122194687 192.168.0.23 53783 typ host generation 0 ufrag HtWM network-id 2
candidate:360945858 1 udp 2122260223 172.25.64.1 53784 typ host generation 0 ufrag HtWM network-id 1
candidate:6840418 1 udp 2122194687 192.168.0.23 53785 typ host generation 0 ufrag HtWM network-id 2
candidate:1526752306 1 tcp 1518280447 172.25.64.1 9 typ host tcptype active generation 0 ufrag HtWM network-id 1
candidate:1324063890 1 tcp 1518214911 192.168.0.23 9 typ host tcptype active generation 0 ufrag HtWM network-id 2

抓包分析

根据浏览器上报的 candidate 信息可以知道使用 max-bundle 时，每个 IP 只协商了一个端口，使用 max-compat 时每个 IP 上协商了多个端口（第一次 3 个，第二次 2 个）。

使用 max-compat 进行互动并使用 Wireshark 进行抓包分析，浏览器上报的 candidate 信息中 192.168.0.23 一共协商了 53707 和 53709 两个端口，互动是只有 53707 在被使用，没有抓到 53709 端口的数据包。

结论

在使用浏览器和 Janus 互动时，RTCPeerConnection.bundlePolicy 最终视频和音频的传输都是使用一个端口，不同的取值影响的注意是 ICE 协商阶段，建议使用 "max-bundle" 提高 ICE 协商速度。

参考文档

avatar
文章
阅读
粉丝