ncompresses the signal, converts it back to audio, and delivers it to the speaker. Each one of those steps adds latency. It all happens in "real time," but the latency is noticeable. Latency usually has two distinct causes: propagational delay or computational delay. If you're sending your VoIP packets from the eastern United States to the Philippines, you'll need to haul those packets halfway around the world. Realistically, you cannot improve upon the speed in which bits traverse these links, SO propagational delay is usually a fact of life, especially on undersea routes where there are few alternate paths. A land-based point-to-point link is often nothing of the sort at the phys- ical layer. A link between New York and California may have many smaller hops within in it to take advantage of available capacity on ex- listing intercity links. These added physical links are usually transparent to the subscriber, but can add latency in the form of added distance (and minor computational delay). I've seen examples where delay was cut almost in half after we convinced the provider to give us a more efficient route on the network. Computational delay is a factor every time packets traverse a device that alters the packet. Routers, DSPs, cell phones, and PBXs all contribute to computational delay. Converting from G.711 to G.729 adds compression, which introduces even more Chapter 30: VolP computational delay. The way to resolve computational delay is to remove hardware from the path, lower compression complexity, add faster hardware, and SO on. Latency presents itself as delayed audio or perceived echo. See Chapter 20 for more information on latency. Packet loss Packet loss in a VoIP call is bad news and must be resolved, or you'll be faced with a mob of angry users wielding torches and pitchforks. The main weapon in the battle against packet loss is QoS. If you're still losing packets with QoS properly configured and tuned, you need more bandwidth or you may have bad hardware. Remember, there is no QoS on the Internet