Since its not a full Lync 2010 environment from end to end, I expected certain Lync 2010 features would simply not work. One of those long awaited features is the ability to transfer files between users who are on different firewalled networks.
In OCS 2007 R2 and older versions, people were often frustrated by the inability for Communicator to transfer files between users who were not on the same network. File transfers worked peer-to-peer, and if the clients couldn't reach each other directly via their local IP address, then the file transfer would fail with a message like this:
You cannot receive the file ChuckNorrisFacts.doc from Chuck Norris. This may be due to firewall restrictions or network problems. If you need further assistance, please contact your system administrator.In Lync 2010, file transfers between users on disparate networks will work, because Lync 2010 is a lot smarter about finding a routable network path to the other party. Lync will use ICE (Interactive Connectivity Establishment) and SDP (Session Description Protocol) to find a media path to send file data in much the same way that Communicator used ICE/SDP for voice/video traffic. For an excellent description on how Communicator uses ICE/SDP, read this post by the Communications Server team.
I had assumed you would need to use the Lync client in conjunction with a Lync edge server for file transfer to work properly. To my surprise, I found that a Lync edge server is NOT a required component. The Lync client does all the ICE/SDP work to find a routable media path. When either party is behind a firewall and can't be reached directly from the other user, Lync will use the existing OCS/Lync edge server to act as a proxy.
I confirmed this by reviewing the Lync client logs on my machine. By the way, its very handy to turn on logging in Lync. It can be very useful when troubleshooting, or in this case, just trying to figure out how things are working. Digging through the Communicator-uccaip-0.uccapilog file in my Tracing folder (they still haven't updated the names of the log files for Lync), I could see the following IP candidates offered by the other client just prior to the transfer:
a=candidate:1 1 TCP-PASS 2120613887 10.1.1.71 29884 typ hostI won't go into the details of each of these candidate lines because the Communications Server Team does such a great job explaining it, but the 10.1.1.71 address is the internal address of the other user, while the 18.104.22.168 address is the external AV edge IP address of my OCS 2007 R2 edge server. You can see that several of the candidates are offering to use the AV edge IP address to relay the file transfer data from the other user's internal IP address.
a=candidate:1 2 TCP-PASS 2120613374 10.1.1.71 29884 typ host
a=candidate:2 1 TCP-ACT 2121006591 10.1.1.71 19511 typ host
a=candidate:2 2 TCP-ACT 2121006078 10.1.1.71 19511 typ host
a=candidate:3 1 TCP-PASS 6556159 22.214.171.124 57733 typ relay raddr 10.1.1.71 rport 22533
a=candidate:3 2 TCP-PASS 6556158 126.96.36.199 57733 typ relay raddr 10.1.1.71 rport 22533
a=candidate:4 1 TCP-ACT 7076607 188.8.131.52 57733 typ relay raddr 10.1.1.71 rport 22533
a=candidate:4 2 TCP-ACT 7076094 184.108.40.206 57733 typ relay raddr 10.1.1.71 rport 22533
So, to make a long story short, it appears that you won't have to wait to have a fully deployed Lync Server 2010 infrastructure to start taking advantage of the vastly improved file-transfer abilities in the Lync client.