在我的应用程序中，一个对等方 （A） 有一个媒体流，另一方 （B） 有两个媒体流。我不明白为什么从 B 到 A 提供更多的 m= 线：
1） A至B的报价如下：
v=0
o=- 298896314257884346 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS BVmismsFWNYofSpFcVAnbDtyGxd1hzVGcOXe
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
...
a=mid:0
...
a=sendrecv
a=msid:BVmismsFWNYofSpFcVAnbDtyGxd1hzVGcOXe 982eedc1-919b-450f-80e3-2fb173cbc5ae'
...
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 123 127 122 125 107 108 109 124
c=IN IP4 0.0.0.0
...
a=mid:1
...
a=sendrecv
a=msid:BVmismsFWNYofSpFcVAnbDtyGxd1hzVGcOXe 4112fe2c-24b3-4135-9ad6-7e2f38a6692f
2） B向A的报价如下：
v=0
o=- 6641223000983904101 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1 2 3 4
a=msid-semantic: WMS
m=audio 54011 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
a=mid:0
...
a=sendrecv
a=msid:- 4fb1ecb1-86e7-4529-a5b6-1dddd6f77ce0
...
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 123 127 122 125 107 108 109 124
...
a=mid:1
...
a=sendrecv
a=msid:- b3b97f66-8a7a-4aaf-857b-e011648a4a64
...
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...
a=mid:2
...
a=sendrecv
a=msid:LukrKSP3g6xYlKFbI9DhHXmE22ZEwNz3Shpo 06363625-089b-49f8-ab23-ec04ac0499c0
...
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 123 127 122 125 107 108 109 124
...
a=mid:3
...
a=sendrecv
a=msid:LukrKSP3g6xYlKFbI9DhHXmE22ZEwNz3Shpo 108478fa-20a9-4393-aaf2-3d27ac641258
...
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 123 127 122 125 107 108 109 124
...
a=mid:4
...
a=sendrecv
a=msid:zCWSiL1IMAhK6skk975lr4IIPf4LBoh2chQI 4600414c-8faf-451c-b6d4-7d8310ab63f8
在第两种情况下，m= 行为 5，位于 （BUNDLE 0 1 2 3 4）为什么只有两个视频流时有 5 行？
会话描述包括有关要发送的媒体类型、格式、使用的传输协议、端点的 IP 地址和端口以及描述媒体传输端点所需的其他信息的信息。
由于 B 有两个媒体流，SDP 将包含 4 m 行（每个流 2 个）。
在统一计划中，每个媒体轨道都分配给单独的"m="部分。如果使用多个媒体轨道，则会创建多个"m="部分。
Chrome 正在从 Plan B 迁移到统一方案
如果您想了解有关统一计划的更多详细信息，可以查看此博客 - https://www.callstats.io/blog/what-is-unified-plan-and-how-will-it-affect-your-webrtc-development