Lync聯(lián)盟功能無法正常使用該怎么解決

Lync聯(lián)盟功能無法正常使用該怎么解決，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

    前段時間給客戶部署了一套Lync Server 2013的環(huán)境，并且做了聯(lián)盟，聯(lián)盟后跟聯(lián)盟用戶開會，桌面共享、PPT、白板一直不能使用，使我很是郁悶，跟客戶研究了小半個月終于找到了相關(guān)的解決方案，今天給大家分享下。

問題描述

=====

 客戶Lync 聯(lián)盟功能無法正常使用

背景情況

=====

客戶環(huán)境為lync 2013, 內(nèi)部使用所有功能都正常

只有在聯(lián)盟的時候會出現(xiàn)（桌面共享,ppt，白板）的問題。

A/V等其他功能正常

解決方法

測試聯(lián)盟用戶的桌面共享依然是失敗的,從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"

網(wǎng)絡(luò)數(shù)據(jù)包分析:

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

此次我們抓取了兩個聯(lián)盟edge的服務(wù)器網(wǎng)絡(luò)數(shù)據(jù)包流量,對比分析：

首先 我們選擇一個測試會話(客戶call 聯(lián)盟用戶)

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 協(xié)商看 ,最終兩個邊緣的外網(wǎng)卡的會話 會在157.56.214.17256193 and 157.56.214.172 56193 上進行:

在聯(lián)盟客戶邊緣服務(wù)器數(shù)據(jù)包中搜索相關(guān)高位端口:

發(fā)現(xiàn)高位端口的包發(fā)送出去后被reset 掉 。

但是在客戶的邊緣服務(wù)器上并未收到這個數(shù)據(jù)包請求,只有發(fā)出去的高位端口的請求包,同樣在對方邊緣服務(wù)器上查找此包,也未發(fā)現(xiàn),但是也被reset掉了:

由此說明, 客戶與聯(lián)盟客戶在邊緣高位端口上是不通的,中間的網(wǎng)絡(luò)設(shè)備阻斷了會話的建立.

檢查443 TRUN 模式下的會話:

在客戶邊緣服務(wù)器上檢查, 443 TRUN 模式:

發(fā)現(xiàn) 55877-443及 56193-443 上都有大量的數(shù)據(jù)傳輸,看上去一切都很正常:

但是從聯(lián)盟客戶邊緣服務(wù)器上看,NAT后的地址卻變成了一個未知的IP  61.183.84.66,從而導致443 TURN 會話無法建立。

結(jié)論：

從以上的分析我們可以看出:

1. NAT 配置異常,     Lync 要求 針對Lync 的NAT ip 地址不能改變,因為此公網(wǎng)ip 已經(jīng)配置在Lync      服務(wù)器環(huán)境中了。但是從抓包的結(jié)果看, NAT 后傳到對方的地址經(jīng)常變化

在NAT設(shè)備上 將 Lync NAT 地址固定后問題解決.

關(guān)于Lync聯(lián)盟功能無法正常使用該怎么解決問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識。