Partager via

A deep dive into the Office Communicator 2007 R2 file transfer process

  • Article

I had an opportunity recently to dig into the file transfer mechanism in Microsoft Office Communicator 2007 R2 (MOC).  As you may already know, although a server from the OCS Pool is used to route setup information for the file transfer session between the participating clients, the file transfer itself occurs peer-to-peer directly between the participating clients.  Depending on the configuration of the network, either a two-way or a three-way handshake transaction will be performed to set up the file transfer session, immediately followed by the file transfer itself using TFTP over a randomly chosen TCP port from the range of 6891 – 6900. 

 

How file transfers between Office Communicator 2007 R2 clients typically work

 

When an Office Communicator client prepares to transfer a file, the client will check whether the file transfer is allowed by policy and whether the file contains an extension that is not blocked by the Intelligent IM Filter (IIMF).  The sending client will then prepare an INVITE MESSAGE request and send it to the receiving client via the OCS Pool.  This MESSAGE request will contain several critical pieces of information for the receiving client to process, including:

Content-Type: text/x-msmsgsinvite (specifies that this is a transfer type request)
Application-Name: File Transfer (specifies that this is a file transfer)
Invitation-Command: INVITE (specifies that this is the initial handshake transaction)
Invitation-Cookie: 513756658 (used to identify / track requests and responses)
Application-File: Readme.txt (specifies the name of the file to be sent)
Application-FileSize: 4690 (specifies the size of the file to be sent)
Connectivity: N (if present, specifies that the client is using a NAT address)
Encryption: R (specifies whether encryption is ‘S’ supported or ‘R’ required)

Upon receiving the INVITE MESSAGE request, the receiving client will send 200 OK to update the sender that the packet has been accepted.  It will then construct and send its own ACCEPT MESSAGE request to the sending client via the OCS Pool.  This MESSAGE request will also contain several pieces of information for the sending client to process, including:

Content-Type: text/x-msmsgsinvite (specifies that this is a transfer type request)
Invitation-Command: ACCEPT (specifies whether receiver will accept or reject file transfer / second handshake transaction)
Invitation-Cookie: 513756658 (used to identify / track request and responses)
Request-Data: IP-Address: (not used)
Encryption-Key: qiQkTTcCtvxDgYOJllkVaB6mEyrez7ML (used to encrypt the data for the file transfer)
Hash-Key: 50raTj9w5BWC63JEVlAlgNT7oNAStr22 (used to decrypt the transferred data)
IP Address: 192.168.1.10 (specifies the advertised address used for the file transfer)
Port: 6891 (specifies the advertised port from 6891-6900 range for the file transfer)
PortX: 11178 (global constant set as default AI Port value / may not be used)
AuthCookie: 27079318 (used for identification for pending TFTP session)
Sender-Connect: True (if present, specifies that sending client must connect to receiving client to transfer file)

Likewise, upon receiving the ACCEPT MESSAGE request, the sending client will send 200 OK to update the receiver that the packet has been accepted.  Using the information contained within the MESSAGE request, the sending client will then open a TFTP file transfer session directly to the IP Address (192.168.1.10) and Port (6891) advertised by the receiving client to transfer the file.  The following transaction will then occur between the sending and receiving clients:

Sending client connects to Receiving client
Receiving client sends VER MSN_SECURE_FTP
Sending client sends VER MSN_SECURE_FTP
Receiving client sends USR receivinguser@contoso.com 27079318
Sending client sends FIL 4698
Receiving client sends TFR
Sending client transfers the encrypted file to specified IP address/Port
Receiving client sends BYE 16777989
Sending client sends MAC (signature using encrypted hash)
Sending client tears down the connection

As mentioned previously, this is how the file transfer process in Office Communicator 2007 R2 typically works – or at least, this is how it is typically documented (see the Office Communications Server 2007 R2 Resource Kit, pages 175–179).  However, there is much more to this process, as you will see…

 

How file transfers between Office Communicator 2007 R2 clients really work

The deep dive into the file transfer process actually begins with evaluating the network infrastructure used by the two participating Office Communicator 2007 R2 clients.  Whenever a user prepares to send a file using Office Communicator, both the sending client and the receiving client perform suitability testing to determine the appropriate network adapter to use for the file transfer attempt.  The individual results of this network suitability testing directly affects how the file transfer session is established between the two participating clients.  

Assuming that the file transfer is allowed by policy and that the file name to be sent does not have an extension value that is filtered by the Intelligent IM Filter (IIMF), the following steps describe the behavior of a file transfer attempt in much greater detail.

 

Step 1 – Sending client performs suitability testing to determine which network adapter should be used for the file transfer attempt. 

The sending client calls a function that returns a list of network adapters that are enabled on the local machine.  From the list of enabled adapters, it performs suitability testing to determine the most suitable IP address to use for the file transfer. 

- Prefer any adapter that has an internet IP address (any non-private, routable IP address), but only if it was used to log on to OCS Pool
- Prefer any adapter with an RFC1918 private IP address (10.X.X.X, 172.16.X.X, or 192.168.X.X), but only if it was used to log on to OCS Pool
- Reject any adapter that is considered as automatically assigned (169.X.X.X)
- Reject any adapter that is considered a loopback adapter (127.X.X.X)

Note: If the most suitable network adapter is assigned an RFC1918 private IP address, the Connectivity flag for the sender will be marked as N (NAT). 

 

Step 2 – Sending client constructs INVITE MESSAGE (initial handshake) and sends it to the receiving client via the OCS Pool.

Upon evaluating the network adapters from the local system and selecting the most suitable adapter for the file transfer, we can tell from the contents of the INVITE MESSAGE session description that this adapter is not using a NAT IP address.  Since the Connectivity flag is not present in the packet, the sending client will be responsible for sending an IP Address/Port to the receiving client.  This will result in a three-way handshake transaction between the participating clients. 

Content-Type: text/x-msmsgsinvite; charset=UTF-8
Content-Length: 224
Application-Name: File Transfer
Application-GUID: {5D3E02AB-6190-11d3-BBBB-00C04F795683}
Invitation-Command: INVITE
Invitation-Cookie: 513756658
Application-File: Readme.txt
Application-FileSize: 4690
Encryption: R

Had the most suitable network adapter been assigned an RFC1918 private IP Address, the Connectivity flag (Connectivity: N) would have appeared in the session description.  This means that the sending client would have been marked as not listening, or incapable of providing a valid IP Address/Port for establishing connectivity during the file transfer.  Instead, the burden of providing a valid IP Address/Port would have then fallen on the receiving client.

 

Step 3 – Receiving client responds with 200 OK and processes the INVITE MESSAGE from the sending client.

The receiving client examines the inbound file transfer request and performs the following checks based on the details contained in the MESSAGE session description:

Is the sending client using a NAT IP address (Connectivity: N)?
Does the sending client support or require encryption (Encryption: S or R)?
Does the file have a safe filename (reject filenames containing ( *?\”<>| )?

 

Step 4 – Receiving client performs suitability testing to determine which network adapter should be used for the file transfer attempt. 

 

The receiving client then calls the same function to return a list of network adapters from the operating system.  It also uses the same suitability testing to determine the most suitable IP address to use for the file transfer. 

- Prefer any adapter that has an internet IP address (any non-private, routable IP address), but only if it was used to log on to OCS Pool
- Prefer any adapter with an RFC1918 private IP address (10.X.X.X, 172.16.X.X, or 192.168.X.X), but only if it was used to log on to OCS Pool
- Reject any adapter that is considered as automatically assigned (169.X.X.X)
- Reject any adapter that is considered a loopback adapter (127.X.X.X)

 

Step 5 - The receiving client constructs ACCEPT MESSAGE (second handshake) and sends it to the sending client via the OCS Pool

 

After evaluating its own list of network adapters for suitability, the receiving client sends an ACCEPT MESSAGE (second handshake) response to the sending client.  The receiving client will construct its response based on the following logic:

Request - Sending client is using an adapter with an Internet IP Address and the INVITE MESSAGE does not contain a Connectivity flag value of N (NAT). 
Response - Regardless of local adapter settings, the ACCEPT MESSAGE sent by the receiving client will not contain any connectivity information. 

  • Content-Type: text/x-msmsgsinvite; charset=UTF-8
  • Content-Length: 181
  • Invitation-Command: ACCEPT
  • Invitation-Cookie: 249893901
  • Request-Data: IP-Address:
  • Encryption-Key: qiQkTTcCtvxDgYOJllkVaB6mEyrez7ML
  • Hash-Key: 50raTj9w5BWC63JEVlAlgNT7oNAStr22

Request - Sending client is using an adapter with an RFC1918 private IP Address and the INVITE MESSAGE contains a Connectivity flag value of N (NAT). 
Response - Receiving client is using an adapter with an Internet IP Address. ACCEPT MESSAGE sent by the receiving client will contain a valid IP Address/Port. 

  • Content-Type: text/x-msmsgsinvite; charset=UTF-8
  • Content-Length: 306
  • Invitation-Command: ACCEPT
  • Invitation-Cookie: 249893901
  • Request-Data: IP-Address:
  • Encryption-Key: qiQkTTcCtvxDgYOJllkVaB6mEyrez7ML
  • Hash-Key: 50raTj9w5BWC63JEVlAlgNT7oNAStr22
  • IP-Address: 207.46.193.254
  • Port: 6891
    PortX: 11178
  • Auth-Cookie: 2142425484
  • Sender-Connect: TRUE

Request - Sending client is using an adapter with an RFC1918 private IP Address and the INVITE MESSAGE contains a Connectivity flag value of N (NAT). 
Response - Receiving client is using an adapter with an RFC1918 private IP Address. ACCEPT MESSAGE sent by the receiving client will contain a NAT IP Address/Port. 

  • Content-Type: text/x-msmsgsinvite; charset=UTF-8
  • Content-Length: 181
  • Invitation-Command: ACCEPT
  • Invitation-Cookie: 249893901
  • Request-Data: IP-Address:
  • Encryption-Key: qiQkTTcCtvxDgYOJllkVaB6mEyrez7ML
  • Hash-Key: 50raTj9w5BWC63JEVlAlgNT7oNAStr22
  • IP-Address: 192.168.1.10
  • Port: 6891
  • PortX: 11178
  • Auth-Cookie: 2142425484
  • Sender-Connect: TRUE

Step 6 – Sending client responds with 200 OK and processes the ACCEPT MESSAGE from the receiving client.

The sending client examines the ACCEPT MESSAGE and performs the following checks based on the details contained in the session description:

Does the Encryption-Key provided by the receiving client meet the minimum security requirements (i.e. S-Supported / R-Required)?
Is the receiving client listening for inbound connections (i.e. is Sender-Connect set to TRUE)?

 

Step 7 – Network connectivity determines next action of sending client in response to the ACCEPT MESSAGE sent by the receiving client.

Upon receiving the ACCEPT MESSAGE, the sending client must determine how to establish connectivity to the receiving client to complete the file transfer.  The response of the sending client is determined by the presence of the Sender-Connect flag in the session description of the ACCEPT MESSAGE sent by the receiving client.

 

If the ACCEPT MESSAGE sent by the receiving client contains Sender-Connect: TRUE

The Sender-Connect flag instructs the sending Office Communicator client to connect to the receiving client on the IP Address/Port specified in the session description of the ACCEPT MESSAGE.  The mere presence of Sender-Connect within the body of the ACCEPT MESSAGE sent by the receiving client may indicate a diminished chance of success for the file transfer, for two reasons:

  1. Sender-Connect will only be set to TRUE if the sending client is determined to be using a NAT IP Address
  2. When Sender-Connect is set to TRUE, IP Address / Port offered by receiving client may be either an Internet IP Address or a NAT IP Address

If Sender-Connect is set to TRUE, the sending client will establish a connection to the IP Address/Port advertised by the receiving client.  The encrypted file will then be streamed to the receiving client using the same TFTP process described previously in this article. 

Connectivity between the sending client and the receiving client may fail if either client is logged on externally via the Access Edge role, or if a network route does not exist between two NAT IP addresses (i.e. 192.168.1.10 and 172.16.100.10).  File transfers may also fail if network traffic is filtered by a firewall device or by software such as Windows Firewall.

If the ACCEPT MESSAGE sent by the receiving client does not contain any connectivity information

If the ACCEPT MESSAGE sent by the receiving client does not contain either the Sender-Connect flag or any connectivity information, a third handshake is required to complete the file transfer request.  This behavior will only occur when the network adapter used by the sending client is determined to be an Internet IP Address.  The sending client will again examine its list of network adapters, and the most suitable adapter will be used to send another ACCEPT MESSAGE (third handshake) to the receiving client, this time containing connection information for the file transfer. 

  • Content-Type: text/x-msmsgsinvite; charset=UTF-8
    Content-Length: 162
    Invitation-Command: ACCEPT
    Invitation-Cookie: 513756658
    IP-Address: 207.46.192.254
    Port: 6891
    PortX: 11178
    AuthCookie: 514242609
    Request-Data: IP-Address:

 

Step 8 – Receiving client responds with 200 OK and processes the ACCEPT MESSAGE from the sending client.

The receiving client examines the inbound file transfer request and examines the content of the session description.  Here it finds the IP Address / Port information to use for the file transfer session.

 

Step 9 – Receiving client connects to the IP Address and Port provided by the sending client

The receiving client establishes a network connection to the IP Address and Port provided by the sending client.  The encrypted file will be streamed to the receiving client using the same TFTP process described previously in this article. 

 

 

As always, I hope this helps… :0)

 

-- Dave

Comments