Voice packets are carried by the Real-Time Protocol (RTP), which is carried by the User Datagram Protocol (UDP), which is carried by IP. Because in the IP network all information is carried in-band (on the same media as the transport), each protocol we use has a header associated with it. The bytes can start to add up. Let's run the numbers for a typical VoIP call stream.
G.711 samples the analog voice at an 8 KHz rate, creating 8-bits of information every 125 microseconds. Typically these bytes are packaged up and sent every 20 milliseconds, so the package size is 160 bytes. To every packet with 160 bytes of voice data the network adds a 12-byte RTP header, then an 8-byte UDP header, then a 20-byte IP header. That's 40 bytes of header on top of the 160 bytes of data or 25% overhead. So the original (8-bits x 8 KHz =) 64-Kbps voice stream becomes 80 Kbps at the IP level, and a bit more when we add on the Layer 2 overhead (Ethernet or PPP), usually about 85 Kbps.
Most folks use G.729 for voice across the WAN because it uses less bandwidth. The same calculations for G.729 shows that the initial bandwidth is 8 Kbps (20 bytes every 20 ms) and when we add the overhead it becomes 24 Kbps (60 bytes every 20 ms). The amount of data being sent is much lower, but the RTP/UDP/IP overhead is still the same, so the overhead percentage is now 200%.
What we know about voice is that it is a stream of data that will continue for the duration of the phone call. This is a long time on the timescales of packets and router decisions. Almost all the information in the RTP/UDP/IP headers will be exactly the same for every single packet sent for this voice flow for the duration of the flow. When header compression is enabled, the two routers on either end of a WAN link agree on a short code for each voice flow. The sending end then removes the RTP, UDP and IP headers and just sends the agreed upon code. The receiving end then removes that code and reproduces the RTP, UDP and IP headers and forwards the packet along exactly as it started. But across the critical WAN link the bandwidth was saved.
As we saw by running the numbers above, header compression is going to make a much bigger difference to the bandwidth consumed by G.729 then it does to the bandwidth consumed by G.711, because the overhead is a much larger percentage of the overall packet. If we apply header compression to video conferencing streams we will see very little reduction in the bandwidth because the packet sizes are much larger. Some gain is still possible, but it will not be as dramatic as the bandwidth reduction experienced with voice.
So is this a component of QoS? Not in a direct way, because it is not about identifying high priority streams and giving them preferential treatment at router output queues. But managing the bandwidth is also a part of QoS, and if we can reduce the bandwidth impact of voice on the WAN we can leave more overhead for the bursty data applications, or we can support more simultaneous voice streams on the WAN. So header compression is definitely a part of the larger conversation about managing both bandwidth and application performance across the enterprise network.
