Lync Desktop sharing fails when one user is internal and one is external in your network
Had a customer recently report that they weren't able to perform desktop sharing with their clients outside of their corporate firewall.
Looking at the reports showed this error
ms-client-diagnostics: 24; reason= "Call failed to establish due to a media connectivity failure when both endpoints are remote" ;CallerMediaDebug="application-sharing:ICEWarn=0x320,LocalSite=xx.xx.xxx.x:xxx,LocalMR=xx.xx.xxx.xx:xx,RemoteSite=192.168.20.203:50045,PortRange=50040:50049,LocalMRTCPPort=57498,LocalLocation=1,RemoteLocation=1,FederationType=0"
This usually is down to port configuration settings on your network as instant messaging traffic (which works for you) uses UDP comms and application/desktop sharing will use TCP connectivity. There is something configured on your network that may be preventing the TCP traffic from being sent.
In the above trace, we see the ICEWarn error codes purport to: (information gained from Lync resource kit materials)
0x100 TCP NAT connectivity failed (This flag is expected. If local-to-local connectivity succeeded, the TCP NAT connectivity check may not have been tried. Or there is no direct TCP connection possible. TCP NAT connectivity failing may result in an ICE protocol failure).
0x200 TCP TURN server connectivity failed. (This flag is expected. If local-to-local connectivity succeeded, the TCP TURN connectivity check may not have been tried. Or one sided didn't have TURN server allocation. If connectivity checks were successful for the rest of the call, ignore this ICE protocol warning. Otherwise investigate why the TCP path was not possible.)
0x20 Local connectivity failed. (This flag can occur if the direct connection between clients isn't possible due to NAT/firewalls).
The above makes 0x320 if you didn't know.
We know that firewall software and hardware can attribute to this and its best to review the policies of your companies organization to determine if you might have anything enabled that would prevent traffic from negotiating with the lync servers. Often hardware firewalls have policies enabled to prevent this and might be worth testing them by switching them on/off (as they might be setup to be the default service) they are often used to prevent spam attcks or TCP attacks.
It's worth also review your anti virus software and it's exceptions which can often scan network traffic and thus cause traffic to fail or be blocked and therefore prevent any communications to/fro the lync client to by pass it.
In the above case, tweaking Kaspersky Anti virus to accept and handle this traffic resolved this customers problem.
The Lync resource kit is the place to go to review the ICEWarn errors - Chapter 9.
https://www.microsoft.com/en-in/download/details.aspx?id=21165
Comments
Anonymous
May 02, 2013
We are running into the same issue and are in fact running Kaspersky AV. Could you provide any details as to what tweaks you made to Kaspersky to get this working?Anonymous
October 28, 2013
You can use the following tool to decode ICE Warning messages. gallery.technet.microsoft.com/ICE-Warning-Flag-Decoder-97058ef3Anonymous
April 01, 2014
Good article. This is exactly what happened to us here at Unisys. We had a firewall that was configured to allow for 25,000 connections by default. When the 25,001th connection came along, and it did, it was dropped. The result were a ton of Monitor ID 22 and 23 errors as noted above. We saw application sharing failures all over the place. We still see some of these, trying to understand if it is local or server at this point.