If you have been using XMPP for a long time, you may well have some friends in your buddy list who are using gmail.com addresses. In the beginning, Google largely supported XMPP (with some limitations to TLS support) and it was possible to add gmail.com users to the buddy list and communicate with them using IM, voice and video.

As of 2014, Google's XMPP support has become somewhat broken. The messages you send to gmail.com contacts using XMPP are never delivered and Google never gives any feedback to indicate there was a problem. You continue to see the contact's status changes in your buddy list, giving no clue that the Google service is broken.

Until the Google issues are resolved, suggest to your contacts that they revert their Google account to use Google Talk instead of Hangouts. Google provides a link for this: https://plus.google.com/downgrade/. The XMPP Foundation maintains a list of hosting companies who provide fully functional XMPP support.

If possible, try and start with audio alone and see if the issue persists. If the problem exists just using audio, then continue troubleshooting with audio only.

The RTCP protocol, closely related to RTP, provides real-time feedback between the endpoints in an RTP session. Many phones and softphones can provide visual feedback based on RTCP statistics. Look for these statistics and try to identify the rate of packet loss and the latency.

Identify which codecs are in use. If possible, change to a lower bitrate codec and observe if this makes any difference. Some codecs, such as Opus, have a variable bitrate and should adapt to network conditions.

If using a softphone, check the computer's metrics, in particular, check that the CPU is not overloaded by other running applications.

Identify the IP address where the RTP packets are being sent, you may be able to discover this from the RTP statistics in the phone or you may need to use a packet sniffer as described in the section called “Packet sniffers”.

Perform a traceroute to the remote IP address (see the section called “Operating system utilities”). This will frequently reveal the point where latency is occuring.

If using wifi and traceroute reveals latency or packet loss on the first hop, then it is a good idea to try using a cable connection to try and determine if the wifi is troublesome. Wifi can experience congestion if other wifi routers in your building use the same frequency. This can be dealt with by using a utility or smartphone app that analyzes the wifi frequencies in your building to help you find a quiet channel and then manually changing the router settings to use that channel.

If there is latency or packet loss on any hop that includes a cable connection, then you may want to consider replacing the ethernet cable. Sometimes a faulty cable will appear to work sufficiently for applications like email but it will have a horrible impact on real-time audio/video streams. If you have access, log in to the devices on each end of the cable and check the interface statistics, looking for any TX or RX errors. If any interface settings are in automatic mode, set them manually (e.g. set full duplex and set the speed to gigabit).

Another possible reason for latency or packet loss at an intermediate hop may be network congestion or high CPU load on one of the devices in the path. Check the charts for each device, they should be monitored as described in the section called “Monitoring tools”.