Troubleshooting XMPP TCP Dialback Issues with the Communications Server XMPP Gateway

Communications Server 2007 R2 XMPP Gateway Validation

In Communications Server 2007 R2, in the MMC for the XMPP Gateway, you can use the Validate Connection tab to test the connectivity between the XMPP Gateway and the Edge Server as well as between the XMPP Gateway and Gmail. This should be your first tool to aid in validating the proper configuration of your XMPP Gateway. For more details about this tool, see the section "Validate Connection with XMPP Domain" in the document, Planning, Deploying and Administering XMPP Gateway that is part of the Microsoft Office Communications Server 2007 R2 XMPP Gateway download at https://www.microsoft.com/downloads/details.aspx?familyid=AA560BFE-9960-473A-BFB8-53BFF678CEC4&displaylang=en.

While running the validation, there are two types of logs to collect. OCSLogger.exe output can help you debug common certificate and configuration issues. Network traces can assist in finding DNS, firewall, or other network specific issues.

Communications Server 2007 R2 Logging Tool (OCSLogger.exe)

OCSLogger.exe provides Event Tracing for Windows (ETW) for the XMPP Gateway. For a basic description of the OCSLogger.exe tool and its functionality, see https://office.microsoft.com/en-us/help/HP102143791033.aspx.

To log the connection failure on your XMPP Gateway

1. Locate the tool in the %Program Files%\Microsoft Office Communications Server 2007 R2\XMPP Gateway\Tracing folder.

2. Double-click OCSLogger.exe to open the tool.

3. In the left pane, select XMPP Gateway.

4. Click Start Logging to enable tracing.

5. Reproduce the connection failure.

6. Click Stop Logging.

7. Click View Log Files.

8. Select XMPP Gateway.

9. Click Open to view the log in Notepad or your favorite editor.

Understanding the output of these logs can be challenging. The following are a few tips you can use to make sense of the logs:

• Search for TL_ERROR or TL_WARN. Lines in the log file that start with those two words are usually the most helpful way to narrow down an issue.

• If the information in the TL_ERROR or TL_WARN lines is not immediately helpful, and you see an error code in those lines that appears relevant, use lcserror.exe to look up the error code (for example, lcserror.exe 0x80092013). You can download the lcserror.exe tool as part of the Communications Server 2007 R2 Resource Kit at https://go.microsoft.com/fwlink/?LinkId=141224.

• If the lcserror.exe doesn’t give any helpful information, you can also try the err.exe tool. It uses the same syntax as the lcserror.exe tool. Sometimes the error is on the network or in a call to another Windows component. You can download the err.exe tool at https://www.microsoft.com/downloads/details.aspx?FamilyId=BE596899-7BB8-4208-B7FC-09E02A13696C&displaylang=en. The download link states it’s for Exchange; however, it works for most Windows error codes.

• If you’re still not sure you see anything that would help, go to the end of the log and slowly work your way up until you see something that could give you clues about what the gateway was doing. An example would be locating DNS records or establishing a TCP session to another XMPP Gateway. After you see something recognizeable,research that part of the log keeping in mind what order the process should work. This process takes patience and practice to get used to, so don’t be discouraged if you can’t immediately find what you’re hoping to in the log. The following is an example of a timeout error that might have useful information:

  TL_INFO(TF_COMPONENT) [0]0548.04D4::11/07/2009-07:53:10.550.000000ff (OCSXMPPGateway,SipStackInterface.BuildErrorResponse:18.idx(2151))( 00000000012BE968 )<-- Sending Error 408-Request Timeout, from=user1@sipdomain.com, to=user2@gmail.com

• Compare the log file to the log file of a connection that you know works. Note where the processes diverge. This helps you quickly understand where things went wrong.

If you’re unable to determine the cause of the issue from the information in the log, please contact Support.

Network Monitor

Network traces are used to see what is happening at the network level. You can use Network Monitor or WireShark to capture network traffic on the wire. You can download Network Monitor at https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f.

Get a network trace of the attempt to validate the connection. Install Network Monitor on the XMPP Gateway and start a network trace while running the Validation tool in the Office Communications Server 2007 R2 XMPP Gateway MMC.

What to look for in the network trace:

• Verify that the XMPP Gateway makes an SRV record request for _xmpp-server._tcp.gmail.com and that it gets the relevant A records back for this domain.

  1. Type dns in the Display Filter box and then click Apply. You should be able to see the DNS traffic.

  2. In this traffic you should see queries and results for the relevant SRV and A records similar to those shown in Figure 1.

  Figure 1. A record query for xmpp-server.l.google.com

  

• Check for outbound TCP sessions to the Gmail.com SRV records on TCP port 5269 and ensure that there is a successful TCP session.

  1. Type tcp.port==5269 in the Display Filter box and then click Apply. You should then see the XMPP related network traffic.

  2. An easy way to ensure that the TCP session was properly established is to look at the fourth frame in the network trace and look for data similar to the data shown in the following Hex Details of the packet (check the next few frames if it’s not in the fourth one):

     <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:server" xmlns:db="jabber:server:dialback" from="<sip-domain">"to="gmail.com" id="06b8500a" version="1.0" xml:lang="en-US">

  3. If there isn’t a fourth frame, there may be a connectivity problem or a firewall blocking outbound traffic to the Gmail.com XMPP gateways on TCP port 5269. You can try to test connectivity to the Gmail.com XMPP server IP address that was resolved by DNS by using the following command: telnet <gmail server IP Address> 5269.

• If Gmail.com can successfully resolve your domain name SRV record, _xmpp-server._tcp.<sip-domain>, as well as the associated A record for the FQDN of your XMPP Gateway, it will attempt to make an inbound TCP connection to your XMPP Gateway on TCP port 5269.

  You should be able to find this TCP connection by typing tcp.port==5269 && tcp.flags.syn && !tcp.flags.Ack into the Display Filter box and then clicking Apply.

  This will show you the SYN packets. (the SYN packet is the first packet in each TCP session established.) Look for a SYN packet from Gmail.com to your XMPP Gateway. You can tell which one is from Gmail in two ways:

  • The source IP address is from gmail.com.

  • The destination port is 5269 on the XMPP Server’s IP address.

  If you want to see the rest of this TCP session, filter the results by using the source port of this session in the Display Filter box (for example, tcp.port==39137).

  To view the XMPP data exchanged in the TCP dialback session, review the Hex Details of each packet looking for XML information. Again, Section 8 of RFC 3920 is a good reference for what traffic is expected in this exchange.

This completes the TCP dialback session and should allow communication between the two domains via XMPP. If this connection fails, ensure that your domain’s SRV record resolves properly and that any external firewalls are allowing inbound connectivity to your XMPP Gateway over TCP port 5269.

The Gmail.com servers then resolve your domain’s SRV record. This is a step that administrators could test manually by running nslookup as follows:

nslookup 
set type=srv
_xmpp-server._tcp.<sip-domain>
Server:  [ Your DNS Server IP address]
Address:  Your DNS Server IP address

Non-authoritative answer:
_xmpp-server._tcp.<sip-domain>     SRV service location:
          priority       = 20
          weight         = 0
          port           = 5269
          svr hostname   = xmpp-server.<sip-domain>

Next, ensure that the A record resolves to the external IP address on your firewall that’s publishing the XMPP Gateway. The following shows the nslookup command for this:

nslookup xmpp-server.<sip-domain>
Server:  [your DNS server  IP address]
Address:  your DNS serverIP address

Non-authoritative answer:
Name:    xmpp-server.<sip-domain>
Address:  10.1.1.10

Conclusion

XMPP TCP dialback is a bit different to troubleshoot than typical server to server communication in Communications Server 2007 R2. Hopefully this article helped clarify how it works and gave you an understanding of troubleshooting issues with it.

Additional Resources

To learn more, check out the following articles:

• Microsoft Office Communications Server 2007 R2 XMPP Gateway, https://www.microsoft.com/downloads/details.aspx?familyid=AA560BFE-9960-473A-BFB8-53BFF678CEC4&displaylang=en

• Office Communications Server 2007 Logging Tool, https://office.microsoft.com/en-us/help/HP102143791033.aspx

• Download the err.exe tool, https://www.microsoft.com/downloads/details.aspx?FamilyId=BE596899-7BB8-4208-B7FC-09E02A13696C&displaylang=en

• Configuring XMPP Connectivity to Gmail

• Configuring XMPP Connectivity to Jabber XCP 5.4

Communications Server Resources

• Visit the Communications Server main page at https://go.microsoft.com/fwlink/?LinkId=132607.

• View the complete Communications Server documentation library at https://go.microsoft.com/fwlink/?LinkId=132106.

• Follow tweets from the Communications Server team at https://go.microsoft.com/fwlink/?LinkId=167909.

• Download the Communications Server content as a Word document at https://go.microsoft.com/fwlink/?LinkId=133609.

• Download the Communications Server content as a compiled help file at https://go.microsoft.com/fwlink/?LinkId=160355. (Scroll down to the Additional Information section and download OCSDocumentation.chm.)

We Want to Hear from You

To give us feedback about this article, e-mail us at NextHop@microsoft.com.

You can also send us a tweet at https://www.twitter.com/DrRez.