根据 RFC 4566 https://www.rfc-editor.org/rfc/rfc4566#page-22，sdp 中的 m= 行包含一个端口：
m=audio 49170 RTP/AVP 0
ICE候选港口不是已经确定了吗？这些还包含端口：
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
正如 RFC 5245 https://www.rfc-editor.org/rfc/rfc5245#page-9所述，
“ICE 是提供/应答模型的扩展，其工作原理是在 SDP 提供和应答中包含多个 IP 地址和端口，然后通过点对点连接检查来测试连接性。”
这是否意味着 m= 行中指定的端口已过时？
当使用 libjingle 创建新的 sdp Offer 时，它显示 IP 地址0.0.0.0以及端口 9（这是“丢弃”端口）。所以它显然没有看到 m= 行中的相关端口：
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 102 0 8 106 105 13 127 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
有人知道吗？
m= 行中的 IP 和候选者是前候选者时代的遗物，其中使用固定 IP 和端口进行通信。
至少对于 WebRTC，如第 33 页的https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-15中所指定，
“端口值设置为此 m= 部分的默认 ICE 候选端口，但鉴于尚未收集任何候选端口，必须使用“虚拟”端口值 9（丢弃），如 [ID 中所示.ietf-ice-trickle]，第 5.1 节。”，以及
“m= 行后面必须紧跟一个“c=”行，如 [RFC4566] 第 5.7 节中所指定。同样，由于尚未收集候选者，“c=”行必须包含“虚拟”值“IN IP4 0.0.0.0”，如 [ID.ietf-ice-trickle] 第 5.1 节中所定义。”，
简而言之，m=行包含一个虚拟IP和端口，只要没有收集候选者并且不需要媒体流，以及其后的默认候选者的IP和端口。
| 归档时间： |
|
| 查看次数： |
2192 次 |
| 最近记录： |