从Mozilla网站：https://developer.mozilla.org/en-US/docs/Web/API/Media_Streams_API
“ MediaStream由零个或多个MediaStreamTrack对象组成，它们代表各种音频或视频轨道。每个MediaStreamTrack可以具有一个或多个通道。该通道代表媒体流的最小单位，例如与给定关联的音频信号扬声器，例如立体声音频轨道中的左或右。”
这说明了什么是频道。
最近有几个RFC（例如8108）表示需要在一个RTP会话中发送多个流。每个流在RTP级别上都有自己的SSRC。 同样在RFC for Unified Plan中，引用始终始终是最低级别的流（而不是轨道或通道）。在基本RTP RFC RFC 3550中，没有对通道的引用。
这些RFC中是否提到了RTP流，这建议该流是最低的媒体源，与WebRTC中使用的术语相同，并且如上所述。 在具有SSRC的轨道（WebRTC）和RTP流之间是否存在一对一的映射？
例如，网络摄像头生成一个媒体流，该媒体流可以具有音频媒体轨道和视频媒体轨道，每个轨道都使用单独的SSRC以RTP数据包的形式传输，从而产生两个SSRC。那是对的吗？现在，如果有立体声网络摄像头（或带有某些这样的设备，可以说两个麦克风-通道）？这会生成带有三个不同的唯一SSRC的三个RTP流吗？
在成功测试ICE候选人之后，是否为五元组连接建立了一个RTP会话？还是在同级之间的同一组端口-ip-UDP连接上存在多个RTP会话？
任何阐明这一点的文件将不胜感激。
答案 0 :(得分：4)
这说明了什么是频道。
不完全是。只有 音频 曲目具有频道。除非您使用web audio来将音频MediaStreamTrack split up进入各个通道，否则就同级连接而言，该音轨是最低级别的。 *
这是因为多个音频通道（类似于视频的多个帧）是有效载荷的一部分，可通过编解码器进行编码和解码。实际上，您可以在接收器的MedaiStreamTrack上使用Web音频分配器来分离音频通道，只要它们能幸免。
*）也有data channels，但是它们是不同的，并且与媒体流和音轨无关。
RTP流...是否与WebRTC中使用的术语相同，并且如上所述？
不。粗略地说，您可以说：
但这不是全部，因为sender.replaceTrack(withTrack)。简而言之，您可以在实时通话期间随时 将发送的轨道替换为其他轨道，而无需重新协商连接。重要的是，在这种情况下，另一端的receiver.track不会改变，只有其输出会改变。这样会将管道与通过管道的内容分开。
所以在发送方，说得更公平：
pc.getSenders()）...而在接收方，它更简单，并且总是这样：
有道理吗？
在modern WebRTC中，MediaStream是愚蠢的容器-您可以根据需要使用stream.addTrack(track)和stream.removeTrack(track)从其中添加或删除轨道，此外，{{1} }仅处理 曲目 。例如：
RTCPeerConnection轨道的
个通道与具有SSRC的RTP流之间是否存在一对一的映射？
是的，在for (const track of stream.getTracks()) {
pc.addTrack(track, stream);
}
和SSRC之间。
摄像头可以具有音频媒体轨道和视频媒体轨道，每个轨道都使用单独的SSRC以RTP数据包的形式传输，从而产生两个SSRC。正确吗？
在这种情况下是的，因为音频永远不会与视频捆绑在一起，反之亦然。
现在如果有立体声摄像头
没有区别。立体声音频轨道仍然是单个音频轨道（和单个RTP流）。
或者在对等体之间的同一组端口-ip-UDP连接上是否存在多个RTP会话？
不同时。但是，除非您使用非默认值，否则多个轨道可以共享同一会话：
MediaStreamTrack如果您不这样做，或者使用any other mode，则相同种类的曲目可能会捆绑到单个RTP会话中。