microsoft-teams - 无法始终加入 Microsoft 团队中的会议“哦，天哪！您的电话已挂断。”

我的路由器（以及其他供应商的其他同事路由器）中有一个错误是双重映射端口。

解决方法是使用以下规则设置端口转发：

团队音频：UDP 50000-50019

团队视频：UDP 50020-50039

团队共享：UDP 50040-50059

以下是概述问题的详细说明：

• 从工作和非工作呼叫的媒体日志文件中，连接检查不会一直持续到完成。最初在工作和非工作情况下，客户端确实直接收到来自 MP（媒体处理器）ip 的响应，如下所示

tc::icemachine::IceMachineImpl:: ProcessReceive 13:41:20.835 18208 TL_INFO [19ABA2EF970]: ICEMCHN #0 ProcessReceive() PipeInfo{UDP, Local:10.10.10.0:50006, PalBasedPipe} PipeData{IceData, Encap: Turn, { IP：}，对等方：104.209.195.0: 50232，{010100342112a442b3...}}

非工作

tc::icemachine::IceMachineImpl:: ProcessReceive 13:40:59.885 18208 TL_INFO [19ABA832A20]: ICEMCHN #0 ProcessReceive() PipeInfo{UDP, Local:10.10.10.0:50002, PalBasedPipe} PipeData{IceData, Encap: None, { IP:}，对等体：104.209.192.0: 51402，{000100542112a4423f...}}

但是，在工作呼叫中主机 ip 没有提升，它通过 3480 上的中继 IP 工作

ICEMCHN 对转储：失败 IceCandidatePair{ P:0x7efffdfefdfffbfc L:IceCandidate{F:1 Rtp:{HostUDP, {IP:10.10.10.0:50006}, base:10.10.10.0:50006, rel:10.10.10.0:50006, bw: 0, p:0x7efffdfe, pipe:UDP}, Rtcp:{Mux}} R:IceCandidate{D, F:1 Rtp:{StunUDP, {IP:104.209.195.0:50232}, base:, rel:, bw:0 , p:0x7efffdfe, pipe:None}, Rtcp:{Mux}} DL:,}

ICEMCHN Pairs Dump: 成功 IceCandidatePair{ P:0x0afff5fefdfffbfc L:IceCandidate{D, F:5 Rtp:{TurnUDP, {IP:52.114.188.0:3480, ID:{864350ac4fd269e1}}, base:10.10.10.0:50006, rel: 108.168.97.0:50006, bw:0, p:0x0afff5fe, pipe:UDP}, Rtcp:{Mux}} R:IceCandidate{D, F:1 Rtp:{StunUDP, {IP:104.209.195.0:50232}, 基础:, rel:, bw:0, p:0x7efffdfe, pipe:None}, Rtcp:{Mux}} DL:52.114.188.0:3480,52.114.188.0:3480}

在非工作日志中，对主机对没有响应，并且在回退路径 TL_WARN [19ABA832A20] 上也失败 ：ICEMCHN #0，未找到回退路径

与产品组讨论后发现 1. 客户端向 MP 发送音频模式的连接检查包，源端口为 50006，dst 端口为 53176 MP 接收，映射的源端口为 1026 2. 客户端发送连接检查包to MP 为视频模式，源端口为 50032，dst 端口为 57270 MP 接收，映射的源端口为 1026 3. 客户端向 MP 发送连接检查包用于应用共享模式，源端口为 50052，dst 端口为 59746 MP收到它，映射的源端口是 1026

因此 NAT 对多个不同的源端口和目标端口使用相同的源端口。随着呼叫的进行，客户端向 MP 发送更多的连接检查数据包，并且没有收到音频和视频的响应；当音频模式失败时，这就是它放弃通话的原因。不过，从 MP 日志中，我可以看出 MP 实际上正在接收这些请求，并且正在响应它们。

从wireshark跟踪我可以看到从客户端IP发送到媒体处理器IP的请求如下6052 37.667639 10.10.10.110 137.116.60.197 STUN 150 Binding Request user:nz22:7IQN Internet Protocol Version 4, Src: 10.10.10.110, Dst ：137.116.60.197 用户数据报协议，Src 端口：50006，Dst 端口：53176

并且正在发送的响应由 NAT 转发到不同的 IP，如下所示

6065 37.733923 137.116.60.197 10.10.10.110 STUN 114 绑定成功响应XOR-MAPPED-ADDRESS：108.168.97.86:1026 Internet 协议版本 4，Src：137.116.60.197，Dst：10.10.10.1301 用户报文，Dstrc 协议端口数据：5107端口：50058 异或映射地址：108.168.97.86:1026

从上面的流量可以清楚地看出，从 MP 发送的流量被路由到 NAT(108.168.97.86:1026) 并修改了源端口。NAT 没有正确维护映射，并将端口 1026 上收到的所有数据包转发到相同的源端口，可能是 50052，这种方式有效。50052 可能正在接收到达 1026 的所有内容，这就是为什么我看到丢包跟踪的原因，因为它接收的数据包应该真正转到 50032 或 50006。

根据我们的研究和分析，它似乎是 NAT 映射。正如在 wireshark 跟踪中看到的那样，NAT 将端口 1026 上所有接收到的数据包转发到同一个源端口，可能是 50052 用于应用程序共享，在日志中我可以看到成功的应用程序共享模式。 问题是 NAT 没有保持路径分开。最终，来自所有 3 个服务器端口的流量最终都流向同一个专用端口，在本例中为 50052。

NAT 可以选择为这些私有端口提供单独的公共端口，或者它可以选择为这些私有端口提供相同的公共端口，就像它在这里所做的那样。任何一种方式都是有效的。问题是，如果您决定重用相同的公共端口，那么您知道哪个是正确的私有端口来转发流量的唯一方法是跟踪流量来自或发送到哪个目的地，哪个 NAT可能不在这里. 团队客户端从该源端口（即 50006）做的第一件事就是将分配流量发送到其中继。这是 NAT 将看到的第一个出口媒体数据包。通常，NAT 会尝试为该流量提供与专用端口相同的公共端口，事实上，该 NAT 似乎确实这样做了 - 中继在 NAT 上看到的端口与 50006 的专用端口相同（与视频和应用程序共享）。直到 NAT 看到来自同一个源端口的数据包发往不同的目的地——在这种情况下是 MP。因此，来自 50006 的第一个发往中继的数据包被 NAT 分配了公共端口 50006。但是，来自同一个专用端口的数据包发往 MP（与中继不同的 ip 和端口）获得了 1026 NAT 源端口。服务器实际上确实尝试将数据包直接发送到计算机的 IP，但该 IP 是私有 IP，因此该数据包永远不会靠近计算机。服务器还尝试将数据包发送到客户端在其报价中发送的公共 IP 地址。这通常发生在客户端准备好接收数据包之前，因此大多数 NAT 会丢弃这些数据包。

microsoft-teams - 无法始终加入 Microsoft 团队中的会议“哦，天哪！您的电话已挂断。”

问题描述

解决方案

推荐阅读