Shulou(Shulou.com)05/31 Report--

Lync Alliance function can not be used properly how to solve this problem, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

Some time ago, I deployed a set of Lync Server 2013 environment for customers, and made an alliance, which held a meeting with alliance users. Desktop sharing, PPT, whiteboard could not be used all the time, which made me very depressed. After studying with customers for half a month, I finally found a relevant solution and shared it with you today.

Problem description

=

Customer Lync federation feature does not work properly

Background situation

=

The customer environment is lync 2013, and all functions are normal for internal use.

Problems (desktop sharing, ppt, whiteboard) occur only in federation.

Other functions, such as Amap V, are normal.

Solution method

Test federation users' desktop sharing still failed. From the uc log of the Lync client, it was caused by the ICEWarn= "0x4000220" error, as in the previous version of the analysis, this error was caused by the tcp media stream could not be established.

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 A federated call failed to establish due to amedia connectivity failure where both endpoints are internal"; LocalMR= "61.183.84.123"; RemoteSite= "192.168.3.57"; RemoteMR= "157.56.214.172"; PortRange= "1025"; LocalMRTCPPort= "55877"; RemoteMRTCPPort= "56193"; LocalLocation= "2"; RemoteLocation= "2"; FederationType= "0" NetworkName= "dfcv.co"; Interfaces= "0x2"; BaseInterface= "0x2"; BaseAddress= "172.17.27.50 BaseInterface= 5185x MrDnsU =" lyncedge.dfcv.co "; MrResU=" 0 "; LyncAppSharingDebug=" SharerChannel:0x0;Memory Usage: totalUsedVirtual=897, availableVirtual=1150;StartupTime:2015-02-11T08VV 5310.758Z; "

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

Network packet Analysis:

=

This time, we captured the network packet traffic of the servers of the two federation edge, and compared and analyzed:

First we select a test session (customer call federation user)

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

Judging from the sip negotiation between the two sides, the final conversation between the two edge external network cards will take place on 157.56.214.17256193 and 157.56.214.17256193:

Search for relevant high-order ports in the federated customer Edge Server packet:

It is found that the packet of the high port is dropped by reset after being sent out.

However, the request for this packet was not received on the customer's edge server, and only the request packet sent from the high port was also found on the other side's edge server, but it was also dropped by reset:

This shows that there is no communication between the customer and the alliance customer on the edge high port, and the middle network device blocks the establishment of the session.

Check the session in 443 TRUN mode:

Check on the customer Edge Server, 443 TRUN mode:

It was found that there was a large amount of data transmission on both 55877-443 and 56193-443, and everything seemed normal:

However, from the point of view of the federated customer edge server, the address after the NAT has become an unknown IP 61.183.84.66, resulting in the 443 TURN session cannot be established.

Conclusion:

From the above analysis, we can see:

The NAT configuration is abnormal. Lync requires that the NAT ip address for Lync cannot be changed, because the public network ip is already configured in the Lync server environment. However, judging from the results of grabbing the packet, the address sent to the other party after NAT is often changed.

The problem is resolved after the Lync NAT address is fixed on the NAT device.

This is the answer to how to solve the problem that the Lync Alliance function can not be used properly. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.