Summary

  • César Díaz’s 26 August 2026 LACNIC blog article explains voice compression and explicitly acknowledges protocol overhead. It does not announce a new bandwidth rule.
  • In a stated model of continuous, one-way speech at 20 ms per packet, G.729’s 8 kbit/s payload becomes 24 kbit/s with basic IPv4/UDP/RTP headers, or 32 kbit/s with IPv6.
  • Compression can reduce bytes without reducing packets. Capacity decisions need the packet interval, encapsulation and measurement layer, not only the codec’s advertised rate.

The qualification worth calculating

The attractive number in a voice migration is the amount of audio that no longer needs to cross the network. The less conspicuous number is how often the remaining audio must be sent.

In LACNIC’s 26 August explanation, César Díaz describes the move from circuit-switched telephony to shared IP infrastructure. He contrasts G.711’s 64 kbit/s with lower-rate codecs and expressly says that headers and control data must be added. The qualification is correct. Giving it numbers shows why a compression ratio cannot be copied directly into a purchasing spreadsheet.

Consider G.729 at 8 kbit/s. RFC 3551 describes 10-byte frames representing 10 ms of speech, with two frames in the default 20-ms packet. That makes 20 audio bytes, dispatched 50 times a second. It is an illustrative configuration, not evidence of the codec or settings used by any LACNIC member.

The basic packet adds 12 bytes of RTP header, eight of UDP and a minimum 20 of IPv4. Twenty payload bytes therefore travel in a 60-byte IP packet. Multiply by 50 packets, eight bits per byte and one second: 24 kbit/s.

The audio did not become less compressed. The accounting boundary moved.

One stream, four numbers

The following calculation assumes continuous mono speech in one direction, uncompressed basic RTP/UDP/IP headers, and 20 ms per packet. It is not a traffic measurement or a complete call budget. The IPv6 base header contributes 40 bytes instead of IPv4’s minimum 20.

Codec Audio payload Packets per second Complete IPv4 packet bit rate Complete IPv6 packet bit rate
G.711 64 kbit/s 50 80 kbit/s 88 kbit/s
G.729 8 kbit/s 50 24 kbit/s 32 kbit/s

An eightfold reduction in encoded audio becomes roughly a 3.33-fold reduction in complete IPv4 packet bits under these assumptions. Both streams still ask the network to handle 50 packets a second. A smaller byte count does not by itself establish a proportional reduction in packet-processing work, nor does this table measure any device’s processing capacity.

The IPv6 difference is similarly bounded: an extra 20 header bytes, 50 times a second, adds 8 kbit/s. That is not a verdict on the economics or desirability of IPv6. It is one term in a deliberately simple calculation.

There are costs outside the table. It excludes signalling, RTCP reports, security additions, tunnels, link-layer framing, wireless contention, redundancy and provisioning headroom. Silence suppression would change the traffic pattern. A conversation has two directions whose activity and bottlenecks must be considered separately. A counter reporting audio bytes and an interface reporting complete packets can both be correct while showing different rates.

Fewer packets buy something and give something up

An operator can put more speech into each packet. In the same G.729/IPv4 model, 10-ms packets cost 40 kbit/s, 20-ms packets 24, and 40-ms packets 16. The codec remains at 8 kbit/s throughout. What falls is the frequency with which the header is paid.

This is not a free improvement. RFC 3551 explains that longer packetization reduces overhead but increases delay and makes a lost packet more noticeable. More audio must accumulate before dispatch, and more audio shares the fate of a single packet. The right interval depends on the application and path; the arithmetic cannot select it.

Nor can RTP certify the result. RFC 3550 distinguishes its sequencing and timing facilities from guarantees of delivery or timeliness. A clean calculation says what was counted. Only observations of the intended configuration can establish the resulting service.

LACNIC’s post is a useful opening for that work, not a claim that the work has already been done. The operational lesson is to carry its overhead qualification through to the capacity decision.