WebRTC：通道、轨道和流与 RTP SSRC 和 RTP 会话之间的关系

Question

来自 Mozilla 网站：https://developer.mozilla.org/en-US/docs/Web/API/Media_Streams_API

“一个 MediaStream 由零个或多个 MediaStreamTrack 对象组成，代表各种音频或视频轨道。每个 MediaStreamTrack 可能有一个或多个通道。通道代表媒体流的最小单元，例如与给定关联的音频信号扬声器，例如立体声音轨中的左声道或右声道。”

这阐明了频道是什么。

最近的几个 RFC（例如 8108）提到需要在一个 RTP 会话中发送多个流。每个流在 RTP 级别都有自己的 SSRC。 在统一计划的 RFC 中，也始终引用作为最低级别的流（不是轨道或通道）。在基本 RTP RFC RFC 3550 中，没有对通道的引用。

这些 RFC 中提到的 RTP 流是否建议将流作为媒体的最低来源，是否与 WebRTC 中使用的频道相同，并且如上所述？ 轨道通道 (WebRTC) 和带有 SSRC 的 RTP 流之间是否存在一对一映射？

例如，一个网络摄像头生成一个媒体流，它可以有一个音频媒体轨道和一个视频媒体轨道，每个轨道使用单独的 SSRC 在 RTP 数据包中传输，从而产生两个 SSRC。那是对的吗？现在，如果有一个立体声网络摄像头（或者一些这样的设备，比如说两个麦克风 - 通道？）。这会生成三个具有三个不同唯一 SSRC 的 RTP 流吗？

在成功测试 ICE 候选人后，是否有用于建立五元组连接的单个 RTP 会话？还是可以在对等点之间的同一组 port-ip-UDP 连接上存在多个 RTP 会话？

任何澄清这一点的文件将不胜感激。

Answer 1

这阐明了频道是什么。

不完全是。只有 audio 曲目有频道。除非您将web audio 到split up 和音频MediaStreamTrack 用于各个通道，否则轨道是对等连接的最低级别。 *

这是因为多个音频通道（就像视频的多个帧一样）是由编解码器进行编码和解码的有效负载的一部分。实际上，您可以在接收器的 MedaiStreamTrack 上使用网络音频拆分器来拆分音频通道，前提是它们幸存下来。

*) 还有data channels，但它们是不同的，与媒体流和轨道无关。

RTP 流...是否与 WebRTC 中使用的频道相同，并且如上所述？

没有。粗略地说，你可以说：

RTP 流 == MediaStreamTrack。

但这并不是故事的全部，因为sender.replaceTrack(withTrack)。简而言之，您可以随时在实时通话期间将正在发送的曲目替换为不同的曲目，而无需重新协商您的连接。重要的是，在这种情况下，对方的receiver.track 不会改变，只有它的输出会改变。这将管道与通过它的内容分开。

所以在发送方，更公平的说法是：

RTP 流 == 当前输出一个发送者（来自pc.getSenders()）

...而在接收端，它更简单，而且总是这样说：

RTP 流 == receiver.track

有道理吗？

MediaStream 呢？

在modern WebRTC 中，MediaStreams 是哑容器——您可以使用stream.addTrack(track) 和stream.removeTrack(track) 随意添加或删除其中的曲目——此外，RTCPeerConnection 仅处理 曲目。例如：

for (const track of stream.getTracks()) {
  pc.addTrack(track, stream);
}

channels of track 和带有 SSRC 的 RTP 流之间是否存在一对一的映射关系？

在MediaStreamTrack 和 SSRC 之间，是的。

一个网络摄像头，[...] 可以有一个音频媒体轨道和一个视频媒体轨道，每个轨道使用单独的 SSRC 在 RTP 数据包中传输，从而产生两个 SSRC。对吗？

在这种情况下是的，因为音频永远不能捆绑与视频，反之亦然。

如果有立体声网络摄像头会怎样

没有区别。立体声音频轨道仍然是单个音频轨道（和单个 RTP 流）。

或者在对等点之间的同一组 port-ip-UDP 连接上是否可以有多个 RTP 会话？

不是同时。但是多个轨道可以共享同一个会话，除非您使用非默认：

new RTCPeerConnection({bundlePolicy: 'max-compat'});

如果您不这样做，或者使用any other mode，则可能会将同类曲目捆绑到单个 RTP 会话中。