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.