我花了数周时间研究可以组建团队但不能参加会议的问题。我可以与其他团队成员进行临时呼叫，但会议将在5-10秒内中断，并显示错误消息“哦，亲爱的！您的呼叫已断开。请重试。”
答案 0 :(得分：0)
我的路由器（和其他供应商的其他同事的路由器）中有一个错误，该错误是端口双重映射。
解决方案是使用以下规则设置端口转发：
团队音频：UDP 50000-50019
团队视频：UDP 50020-50039
团队共享：UDP 50040-50059
以下是问题概述的全部详细信息：
•从用于工作和非工作呼叫的媒体日志文件中，连接检查不会一直持续到完成。最初，无论是在工作状态还是非工作状态下，客户端都会直接从MP（Media Processor）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：}，Peer： 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：无，{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对转储：成功的IceCandidatePair {P：0x0afff5fefdfffbfc L：IceCandidate {D，F：5 Rtp：{TurnUDP，{IP：52.114.188.0：3480，ID：{864350ac4fd269e1}}}，基数：10.10.10.0：5000 ，相对值：108.168.97.0：50006，bw：0，p：0x0afff5fe，管道：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：52.114.188.0：3480,52.114.188.0：3480}
在“非工作”日志中，没有对主机对的响应，并且在后备路径上也无法失败 TL_WARN [19ABA832A20]：ICEMCHN＃0，找不到后备路径
与产品小组讨论后，我们发现 1.客户端发送连通性检查数据包到MP为音频方式，源端口是50006，dst端口是53176 MP接收到它，映射的源端口是1026 2.客户端将连接检查数据包发送到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绑定请求用户：nz22：7IQN Internet协议版本4，Src：10.10.10.110，Dst：137.116.60.197 用户数据报协议，源端口：50006 ，目标端口：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.110 用户数据报协议，Src端口：53176，Dst端口： 50058 XOR-MAPPED-ADDRESS：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）后，1026才发挥作用。因此，来自50006的第一个数据包（目的地是中继）由NAT分配给公用端口50006。但是，从同一专用端口发往MP的数据包（与中继不同的ip和端口）获得了1026 NAT源端口。 服务器实际上确实尝试将数据包直接发送到计算机的IP，但是该IP是私有IP，因此该数据包永远不会到达计算机附近。服务器还尝试将数据包发送到客户端在其要约中发送的公共IP地址。不过，这通常是在客户端准备好接收数据包之前发生的，因此大多数NAT都会丢弃这些数据包。