|
|
1 回复 | 直到 7 年前
|
1
0
我的路由器(以及其他供应商的同事路由器)中有一个双映射端口的错误。 解决方案是使用以下规则设置端口转发: 团队音频:UDP 50000-50019 团队视频:UDP 50020-50039 团队共享:UDP 50040-50059 以下是对所述问题的详细解释: 对于工作和非工作呼叫,媒体日志文件中的连接检查不会一直进行到完成。最初在工作和非工作情况下,客户机都会直接从MP(媒体处理器)IP收到响应,如下所示 工作 tc::icemachine::icemachineimpl:: 进程接收 13:41:20.835 18208 tl_info[19aba2ef970]:icemchn 0 processReceive()pipeinfo udp,local:10.10.0:50006,palbasedpipe pipedata icedata,encap:turn,ip:,peer: 104.209.195.0:50232 ,010100342112A442B3… 非工作的 tc::icemachine::icemachineimpl:: 进程接收 13:40:59.885 18208 tl_info[19aba832a20]:icemchn 0 processReceive()pipeinfo udp,local:10.10.0:50002,palbasedpipe pipedata icedata,encap:none,ip:,peer: 104.209.192.0:51402 ,000100542112A4423F… 但是,工作呼叫主机IP没有提升,它通过3480上的中继IP工作。 ICEMCHN Pairs Dump: Failed 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: Succeeded 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}, 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 三。客户端向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 用户数据报协议, SRC端口:50006 ,DST端口:53176 被发送的响应由nat转发到另一个IP,如下所示 6065 37.733923 137.116.60.197 10.10.10.110特技114绑定成功响应 XOR-映射地址:108.168.97.86:1026 Internet协议版本4,SRC:137.116.60.197,DST:10.10.10.110 用户数据报协议,SRC端口:53176,DST端口: 五万零五十八 XOR-映射地址:108.168.97.86:1026 从上面的流量中可以清楚地看到,从MP发送的流量被路由到NAT(108.168.97.86:1026)并修改源端口。 NAT没有正确地维护映射,并且正在将端口1026上的所有接收到的数据包转发到同一个源端口,可能是50052,这是一个有效的模式。50052可能正在接收所有到达1026的数据包,这就是为什么我看到数据包丢失跟踪,因为它的接收数据包应该真正到达50032或50006。 根据我们的研究和分析,它似乎是NAT映射。从“线鲨”的痕迹中可以看到, NAT正在将端口1026上所有接收到的数据包转发到同一个源端口 ,可能是50052,用于应用程序共享,在日志中,我可以看到成功的应用程序共享模式。 问题是nat没有将路径分开 . 最后,所有3个服务器端口的流量都流向同一个专用端口50052。 nat可以选择给这些私有端口单独的公共端口,也可以选择给这些私有端口相同的公共端口,就像它在这里所做的那样。任何一种方式都有效。 问题是,如果您决定重用同一个公共端口,那么您知道将流量转发到哪个专用端口的唯一方法是跟踪流量来自或发送到哪个目的地,而这可能不是NAT在这里做的。 .团队客户机从该源端口(即50006)执行的第一件事是将分配流量发送到其中继。这是NAT将看到的第一个出口媒体包。通常,nat会尝试给这个流量提供与私有端口相同的公共端口,事实上,这个nat似乎确实做到了这一点——nat上中继看到的端口与50006的私有端口相同(视频和应用程序共享也是如此)。1026直到NAT看到来自同一个源端口的数据包被绑定到不同的目的地才开始发挥作用——在本例中是MP。因此,从50006发送给中继的第一个数据包被NAT分配给公共端口50006。但是,来自同一个专用端口的数据包(与中继不同的IP和端口)得到了1026NAT源端口。 服务器确实尝试将数据包直接发送到计算机的IP,但该IP是专用IP,因此数据包永远不会靠近计算机。服务器还尝试将数据包发送到客户机在其报价中发送的公共IP地址。这通常发生在客户机准备好接收数据包之前,因此大多数NAT都会丢弃这些数据包。 |
推荐文章
|
|
Rajeesh Menoth · 如何在MS团队中禁用转盘卡分页 3 年前 |
|
|
chandra · 如何在团队中发送o365连接器卡的旋转木马 8 年前 |
|
|
Roledenez · 是否可以向MS team bot发送语音命令? 8 年前 |
|
|
bloC · 通过URL打开Microsoft Team客户端 8 年前 |
|
|
David · Microsoft Team bot-无法分析租户id 8 年前 |
|
Jetpac · 自动/机器人消息发布到Microsoft团队聊天室 8 年前 |