Lync联盟功能无法正常使用该怎么解决

51次阅读
没有评论

共计 3040 个字符,预计需要花费 8 分钟才能阅读完成。

Lync 联盟功能无法正常使用该怎么解决,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

    前段时间给客户部署了一套 Lync Server 2013 的环境,并且做了联盟,联盟后跟联盟用户开会,桌面共享、PPT、白板一直不能使用,使我很是郁闷,跟客户研究了小半个月终于找到了相关的解决方案,今天给大家分享下。

问题描述

=====

  客户 Lync 联盟功能无法正常使用

背景情况

=====

客户环境为 lync
2013, 内部使用所有功能都正常

只有在联盟的时候会出现(桌面共享,ppt,白板)的问题。

A/ V 等其他功能正常

解决方法

测试联盟用户的桌面共享依然是失败的, 从 Lync 客户端的 uc log 里看 是因为 ICEWarn= 0x4000220 错误导致的, 如上一版本的分析, 此错误为 tcp 媒体流无法建立导致的.

ms-client-diagnostics: 25; reason= A federated call failed to establish due to amedia connectivity failure where both endpoints are internal UserType= Callee MediaType= application-sharing ICEWarn= 0x4000220 LocalSite= 172.17.27.50:5578 LocalMR= 61.183.84.123:55877 RemoteSite= 192.168.3.57:21496 RemoteMR= 157.56.214.172:56193 PortRange= 1025:65000 LocalMRTCPPort= 55877 RemoteMRTCPPort= 56193 LocalLocation= 2 RemoteLocation= 2 FederationType= 0 NetworkName= dfcv.co Interfaces= 0x2 BaseInterface= 0x2 BaseAddress= 172.17.27.50:5185;MrDnsU= lyncedge.dfcv.co MrResU= 0 LyncAppSharingDebug= SharerChannel:0x0;Memory Usage: totalUsedVirtual=897, availableVirtual=1150;StartupTime:2015-02-11T08:53:10.758Z;

Proxy-Authorization: TLS-DSK qop= auth , realm= SIPCommunications Service , opaque= 0E7EC18B ,targetname= lyncfe.dfcv.co , crand= ed6c5417 ,cnum= 44 , response= 6acf3db7c50d9131072848a1ef9d59e8e81f30e9

网络数据包分析:

===============

此次我们抓取了两个联盟 edge 的服务器网络数据包流量, 对比分析:

首先 我们选择一个测试会话 (客户 call 联盟用户)

INVITE sip:tonychen@jackyfan.msftonlinerepro.com SIP/2.0

a=candidate:1 1 TCP-PASS 2120613887 172.17.27.50 28391 typ host

a=candidate:1 2 TCP-PASS 2120613374 172.17.27.50 28391 typ host

a=candidate:2 1 TCP-ACT 2121006591 172.17.27.50 5578 typ host

a=candidate:2 2 TCP-ACT 2121006078 172.17.27.50 5578 typ host

a=candidate:3 1 TCP-PASS 174455807 61.183.84.123 55877 typ relay raddr 172.17.27.50rport 5185

a=candidate:3 2 TCP-PASS 174455294 61.183.84.123 55877 typ relay raddr 172.17.27.50rport 5185

a=candidate:4 1 TCP-ACT 174848511 61.183.84.123 55877 typ relay raddr 172.17.27.50rport 5185

a=candidate:4 2 TCP-ACT 174847998 61.183.84.123 55877 typ relay raddr 172.17.27.50rport 5185

SIP/2.0 200 OK

a=candidate:1 1 TCP-PASS 2120613887 192.168.3.57 21496 typ host

a=candidate:1 2 TCP-PASS 2120613374 192.168.3.57 21496 typ host

a=candidate:2 1 TCP-ACT 2121006591 192.168.3.57 8224 typ host

a=candidate:2 2 TCP-ACT 2121006078 192.168.3.57 8224 typ host

a=candidate:3 1 TCP-PASS 174455807 157.56.214.172 56193 typ relay raddr 192.168.3.57rport 17495

a=candidate:3 2 TCP-PASS 174455294 157.56.214.172 56193 typ relay raddr 192.168.3.57rport 17495

a=candidate:4 1 TCP-ACT 174848511 157.56.214.172 56193 typ relay raddr 192.168.3.57rport 17495

a=candidate:4 2 TCP-ACT 174847998 157.56.214.172 56193 typ relay raddr 192.168.3.57rport 17495

从双方的 sip 协商看 , 最终两个边缘的外网卡的会话 会在 157.56.214.17256193 and 157.56.214.172 56193 上进行:

在联盟客户边缘服务器数据包中搜索相关高位端口:

发现高位端口的包发送出去后被 reset 掉。

但是在客户的边缘服务器上并未收到这个数据包请求, 只有发出去的高位端口的请求包, 同样在对方边缘服务器上查找此包, 也未发现, 但是也被 reset 掉了:

由此说明, 客户与联盟客户在边缘高位端口上是不通的, 中间的网络设备阻断了会话的建立.

检查 443 TRUN 模式下的会话:

在客户边缘服务器上检查, 443 TRUN 模式:

发现 55877-443 及 56193-443 上都有大量的数据传输, 看上去一切都很正常:

但是从联盟客户边缘服务器上看,NAT 后的地址却变成了一个未知的 IP  61.183.84.66, 从而导致 443 TURN 会话无法建立。

结论:

从以上的分析我们可以看出:

NAT 配置异常,     Lync 要求 针对 Lync 的 NAT ip 地址不能改变, 因为此公网 ip 已经配置在 Lync      服务器环境中了。但是从抓包的结果看, NAT 后传到对方的地址经常变化

在 NAT 设备上 将 Lync NAT 地址固定后问题解决.

关于 Lync 联盟功能无法正常使用该怎么解决问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注丸趣 TV 行业资讯频道了解更多相关知识。

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-16发表,共计3040字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)