Latency is the enemy of interactive audio and video. Packets that take too long to get to their destination are as good as lost, and that lowers the quality of the audio or video connection. Fortunately, you can tune your network to remove or reduce latency.
You should aim to modify your transmission infrastructure so that during an audio or video call there is never more than 400 milliseconds (ms) end-to-end latency, and less than 100 ms jitter (a term used to denote variability in the delay). If end-to-end delays reach or exceed these parameters, your callers will see artifacts on their screens where data is missing or hear echo and pops in their audio.
Reducing network congestion is the key to managing latency on the LAN. One way to do this is by increasing bandwidth, but that's not the only option. A number of Quality of Service (QoS) schemes (such as packet prioritization using IP Precedence and DiffServ) can help ensure that audio and video packets are handled with the highest priority available. A single QoS mechanism implemented end to end should help lower latency on the LAN.
For now, we'll focus on more traditional ways of efficiently using bandwidth to address congestion. Most interactive video communications use 300 to 400 Kbps per stream, while voice-only sessions use 30 to 40 Kbps. Since in a conversation the streams are bidirectional, you would double those numbers to find the aggregate demand on network resources for each conversation. Actually, you'd need to double those numbers and add a bit more, thanks to the overhead imposed by packet headers. For example, a bidirectional 384 Kbps videoconference consumes approximately 425 Kbps in each direction.
To reduce congestion, make sure that you're using switched (not shared) 10- or 100-megabit Ethernet throughout the LAN. Your multimedia applications won't use all this bandwidth constantly, but switched Ethernet is faster than shared Ethernet and doesn't cost significantly more.
Make sure you employ nonblocking switches with output-buffered backplanes with a capacity of at least 1 Gbps. That should help you avoid a kind of congestion known as head-of-line blocking, which occurs when the traffic for the switch's ports exceeds their line rates.
The most common way to lower latency on IP LANs where data, audio, and video converge is to overprovision: you should provide enough bandwidth to meet the highest possible load at all times. At nonpeak times, the high capacity is wasted. Generally, this means buying more or faster switches; this approach is thus expensive, though frequently still cost-effective.
Whether or not you overprovision, your choice of network topology affects packet latency and the odds of packet collisions. Some network architects recommend that you build parallel networks for data and realtime traffic (for voice and video). Under such a design, you connect the data-only endpoints to one set of Ethernet switches, and aggregate video endpoints on their own Gigabit Ethernet switches. This eliminates the risk that video and data will battle for bandwidth. The two networks can still communicate, to provide data connectivity when users want to collaborate on applications, for example.
Other network engineers recommend mixing video and data-only endpoints on your switches to reduce the possibility of having too many simultaneous video sessions passing through and potentially overloading a single switch. The logic is that common applications, such as Internet browsers and email clients, produce only intermittent, "well-behaved" TCP/IP traffic that can mix with the continuous UDP traffic generated by video applications. When the network becomes congested, switches drop packets, and the data applications begin to resend them. As packet loss increases, TCP/IP applications increase the interval between packets, reducing their relative impact on UDP-based interactive video sessions in mixed networks.
The greatest risk involved in deploying endpoints this way is that, as traffic congestion at the switch increases, mission-critical TCP/IP applications back off so far that they time out and eventually terminate.
If your LAN already has abundant bandwidth, the "converged" network architecture is easier to manage. If, on the other hand, you're already running at capacity and your data applications are suffering from congestion, you need to consider what mix of traffic runs on the LAN. Network-intensive applications, such as those that manipulate large databases or graphics (for example, CAD/CAM drawings), use as much bandwidth as video traffic and should not run on the same segments as realtime multimedia. Streaming video servers are similar to two-way interactive video applications in that they use UDP for transmission. They also don't back off when congestion arises because they do not detect packet loss, so they tend to degrade interactive video application quality if both occur on the same network segments.
Once you've conquered the LAN, you need to examine your options for wide area traffic. For voice, your data network provider likely has services in place. For video, watch for emerging WAN services over the next four to six months.