Cross-Firewall File Transfer in Lync

In my "lab" environment, I'm running Lync Server 2010 RC in an existing OCS 2007 R2 corporate environment.  Since I didn't want to do anything that would impact the existing user population, I didn't make any unnecessary changes to the existing edge server environment.  So, I'm using our existing OCS 2007 R2 edge server to communicate with my Lync 2010 front-end. 

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 host
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 209.2.2.23 57733 typ relay raddr 10.1.1.71 rport 22533
a=candidate:3 2 TCP-PASS 6556158 209.2.2.23 57733 typ relay raddr 10.1.1.71 rport 22533
a=candidate:4 1 TCP-ACT 7076607 209.2.2.23 57733 typ relay raddr 10.1.1.71 rport 22533
a=candidate:4 2 TCP-ACT 7076094 209.2.2.23 57733 typ relay raddr 10.1.1.71 rport 22533

I 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 209.2.2.23 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.

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.