Export (0) Print
Expand All

Troubleshooting XMPP TCP Dialback Issues with the Communications Server XMPP Gateway

Communications Server 2007 R2

Troubleshooting XMPP TCP dialback is a bit different than typical server-to-server communication in Communications Server 2007 R2. This article tries to help you troubleshoot XMPP TCP dialback issues if federation with Google Talk or other XMPP domains doesn’t work as expected by using tools such as Communications Server 2007 R2 Logging Tool, Network Monitor, and other methods.

Author: Rob Pittfield

Publication date: February 2010

Product version: Communications Server 2007 R2 XMPP Gateway

In this article we try to give you enough information to troubleshoot XMPP TCP dialback issues if federation with Google Talk or other XMPP domains doesn’t work as expected.

Google and Jabber XCP 5.4 support federation with other XMPP servers by using TCP dialback. To troubleshoot connectivity issues with these servers, an understanding of the connection process is helpful.

For details about how the connection process works at a protocol level, see section 8 of RFC 3920 at http://www.ietf.org/rfc/rfc3920.txt

There are four tasks to ensure that the XMPP Gateway to other XMPP server connections functions correctly (gmail.com is used as an example below):

  • The XMPP Gateway must be able to resolve the DNS SRV record, _xmpp-server._tcp.gmail.com, to an A record (for example, server.gmail.com).

  • The TCP connection and initial negotiation to Gmail.com must be successful.

  • The SRV record, _xmpp-server._tcp.<sip-domain>, must be configured to resolve to an A record that matches the FQDN of your XMPP Gateway.

  • The TCP port 5269 on your external firewalls must be opened to allow inbound connections from the Gmail.com servers to connect to the XMPP Gateway in your perimeter network.

The four tasks just listed will help ensure that dialback connectivity from Gmail.com to your XMPP Gateway on TCP port 5269 is successful. However, if problems occur when trying to establish a connection to Gmail.com, the following three tools are useful to help you troubleshoot the problem.

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 http://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.

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 http://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 http://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 http://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 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 http://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

    f1ba1e37-7d83-454a-9148-e35acf56d992
  • 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

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.

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

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

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft