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 中，参考总是作为最低级别的流（不是轨道或通道）。在 RFC 3550（基本 RTP RFC）中，没有提及通道。

RTP 流是否如这些 RFC 中提到的那样，建议流作为媒体的最低来源，与 WebRTC 中使用的该术语相同的通道，以及上面提到的？轨道通道 (WebRTC) 和带有 SSRC 的 RTP 流之间是否存在一对一映射？

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

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

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

Answer 1

这澄清了频道是什么。

不完全的。只有音频轨道有通道。除非你使用的网络音频来分割音频MediaStreamTrack到各个通道，轨道的最低水平关于对等连接。*

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

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

RTP 流...与 WebRTC 中使用的该术语以及上面提到的通道相同吗？

不。粗略地说，你可以说：

RTP 流 == MediaStreamTrack。

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

所以在发送方，更公平地说：

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

...而在接收方，它更简单，而且总是正确地说：

RTP流==receiver.track

说得通？

媒体流呢？

在现代 WebRTC 中，MediaStreams 是哑容器——您可以随意添加或删除它们的轨道，stream.addTrack(track)并且——stream.removeTrack(track)此外，RTCPeerConnection仅处理轨道。例如：

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

是否有间的一种一对一映射的信道 的轨道和RTP流与SSRC？

在 aMediaStreamTrack和 SSRC 之间，是的。

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

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

现在如果有立体网络摄像头怎么办

没有不同。立体声音轨仍然是单个音轨（和单个 RTP 流）。

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

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

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

如果您不这样做，或使用任何其他模式，则同类曲目可能会捆绑到单个 RTP 会话中。