共計 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 行業資訊頻道了解更多相關知識。
