A recent post to the Megaconference mailing list raised an issue, which I have encountered numerous times throughout my years in the video-over-IP business:

“Does anyone know why a video conferencing endpoint has packet loss, and even connection break?  Are there any network parameters which can cause this?”

As this is  a frequently asked question, I decided to dedicate a post to this issue, so here’s another edition of “Ask the EXPERT“, featuring all you want to know about the reasons for packet loss.

In Short

When you are sending media – audio and/or video – over an IP network, what you are actually transmitting are packets. Sometimes, for various reasons, some of these packets are not received on the other side. This is known as packet loss.

Packet loss is a pain. Assuming the network is OK, packet loss can hint that there’s a configuration problem, either in the endpoint or in the network. Alternatively, there might be a chance that the network can’t support the overall use of video across the organization.

If packet loss is an issue, I would start with testing the usual suspects (see below). If this fails, I would check if the endpoint’s link has enough bandwidth, and if the network’s bandwidth is sufficient for the organization’s use.

And, yes – if all else fails, call someone from IT. Some problems are better off left to the experts.

The Long Answer

Packet loss is one of the fierce enemies of video conferencing. On top of the numerous visual artifacts it can introduce, packet loss may also result in connection break, especially if the packet loss rate is high (more than 5% in most cases).

Testing the network before connecting the endpoints, even before buying the endpoints, is highly recommended, as it can help in creating a great video conferencing experience. It can also point to causes of packet loss beforehand.

Assuming that the network is not suffering from severe packet loss, and there’s no network element which introduces it, packet loss can be caused by various factors:

• Faulty LAN cabling/connection
• Line bandwidth limit
• Overall bandwidth limit
• Hardware mis-configuration
• Packet size larger than MTU size
• Duplex mismatch
• QoS

The Usual Suspects

Faulty LAN Cabeling/Connection

This may be a blog that mainly deals with software, but every software guy knows that sometimes you have to blame the hardware. A faulty LAN cable or a faulty LAN connection may result in packet loss and connection break. It has happened to me more than once.

So, be sure to check for the usual suspect first.

Hardware Mis-Configuration

No one likes to read the “read me” document. No one opens the user guide. We all just want to plug and play. Well, sometimes ignorance is bliss, but in most cases, ignorance is just… plain ignorance.

An endpoint may seem rather simple, and should be simple to use, but still,  the initial configuration has to be made, and sometimes the default manufacturer’s settings are wrong for you. Hardware mis-configuration can result in many things – bad quality, disabling of features, and of course, packet loss.

So RTFM.

RTFM. (CC)

Line Bandwidth Limit

If the endpoint is connected to a line with a bandwidth limit, but the endpoint is not aware of that limit or doesn’t adapt its bit-rate accordingly, packet loss will occur. This is a common cause for packet loss when your endpoint is connected from home, over an ADSL connection.

Many endpoints offer the option of “automatic” bandwidth selection, so that the endpoint will estimate the available bandwidth and adapt to it. If some arbitrary bandwidth, one that is higher then what is available, is selected, packet loss will occur.  If this continues to occur, the connection will break.

Even when the endpoint is configured to “auto” bandwidth selection, it may not estimate the bandwidth accurately, and thus packet loss will occur.  If you have a bandwidth limit, better set your endpoints accordingly.

Overall Bandwidth Limit

Even if all endpoint bandwidths are configured properly, it may not be sufficient. If many endpoints are active throughout the organization, there might be a bottleneck somewhere along the company network, where the overall bandwidth is not sufficient for so many users.

This will usually occur when communication between remote locations is at a peak, as enterprises tend to purchase a set amount of bandwidth between branches.

If packet loss occurs only when many people are using the video conferencing infrastructure, this may be the case. In situations where participants are using a conferencing bridge (MCU), it will sometimes lower the bandwidth automatically. But in most cases, and to be safe, it is best to disconnect and re-connect again using a lower bandwidth.

Advanced Issues ( a.k.a Call Someone from IT)

Duplex Mismatch

Duplex mismatch may be the result from connecting an endpoint to a router using different duplex modes (one using half duplex, the other using full duplex). This will result in a network that works slower, using up the bandwidth, which may result in packet loss.

As duplex mismatch is a thing for the experts (IT people or VoIP experts), if you suspect there’s a problem concerning your configuration, call someone to check it out. Better  to be safe than sorry.

Packet Size Larger Than MTU Size

This may be part of the above “Hardware Mis-Configuration”, but as I have encountered this problem numerous times, and so, I will dedicate a separate paragraph to it.

The Maximum Transmission Unit (or MTU) size is the maximal size of packet that a given layer of communication can transmit. . While the default size for most Ethernet networks is 1500 bytes, some networks and their respective paths are limited.

If the endpoint, of the other party, be it another endpoint or a conferencing serveruses packets that are larger than the MTU size, packets will be dropped and packet loss will occur.

What’s Your QoS?!

QoS, or Quality of Service, is a “traffic contract” between application and networks or protocol. Most networks use a “best effort” scheme, which is the default QoS level. However, many networks now honor DiffServ levels.

If the network is configured to a certain QoS level, which is different than the one the endpoint was configured to, many things (bad things…) can happen, including packet drops.

Bottom Line

Test the hardware. Test the configurations. Check your bandwidth capabilities. And, yes – if all else fails, call someone from IT. As I already wrote, some problems are better off left to the experts.