What Is Packetization Interval in VoIP?
When you make a VoIP call, your voice isn’t sent as one continuous stream. It’s chopped up into tiny chunks-packets-and sent over the internet. The time length of each chunk is called the packetization interval. It’s measured in milliseconds (ms), and the three most common settings are 10ms, 20ms, and 30ms. This number doesn’t just affect how your voice sounds-it changes how much bandwidth you use, how fast your call responds, and even how stable it is on bad networks.
Think of it like sending a letter. A 30ms interval is like mailing a full page at once. A 10ms interval is like sending three postcards, each with a third of the message. More packets mean more envelopes, more stamps, more overhead. But if one postcard gets lost, you only lose a small piece. With one big letter, if it vanishes, you lose everything.
How Packetization Affects Bandwidth
Every VoIP packet has two parts: the actual voice data (payload) and the digital envelope (headers). Headers don’t carry sound-they carry instructions like where the packet came from and where it’s going. These headers are always the same size, no matter how much voice is inside.
Here’s the math:
- 10ms interval = 100 packets per second
- 20ms interval = 50 packets per second
- 30ms interval = 33.3 packets per second
For a G.711 codec (common in business VoIP), each 20ms packet carries 160 bytes of audio. That’s 64 Kbps of voice data. But add the IP, UDP, and RTP headers (54 bytes), and you’re looking at 87.2 Kbps per call. Now do the same for 10ms: you’re sending twice as many packets, so you’re doubling the header overhead. Total bandwidth jumps to about 129 Kbps. That’s a 48% increase just to cut delay in half.
At 30ms, you’re sending 33% fewer packets. For G.729 (a compressed codec), bandwidth drops from 33.8 Kbps at 10ms to 26.4 Kbps at 30ms. That’s a 22% saving. For companies with hundreds of concurrent calls, that adds up to megabits-and real money on bandwidth bills.
Latency: Why Timing Matters
Latency isn’t just about lag. It’s about how natural a conversation feels. If there’s more than 150ms of total delay-packets traveling, being buffered, processed-you start to talk over each other. People pause awkwardly. It feels like a satellite call from the 90s.
Each packetization interval adds its own algorithmic delay:
- 10ms = 10ms delay
- 20ms = 20ms delay
- 30ms = 30ms delay
But that’s not all. Networks use jitter buffers to smooth out packet delays. These buffers wait a few milliseconds to collect packets before playing them. If you pick 30ms packetization, and your jitter buffer adds another 40ms, you’re already at 70ms before the network even kicks in. Add 80ms of network lag, and you’re at 150ms-right at the edge of what’s tolerable.
10ms intervals keep total delay under 100ms even on busy networks. That’s why trading firms and live interpreters use them. A 10ms delay means your reply feels immediate. In a high-stakes call, that matters.
Audio Quality: More Packets, More Risk
It’s counterintuitive, but smaller intervals don’t always mean better sound. In fact, they make your call more fragile.
Every packet is a chance for loss. If one 10ms packet gets dropped, you lose 10ms of audio-barely noticeable. But if you’re using a codec like iLBC, which was designed for packet loss resilience, you still get glitches. One user on the Asterisk mailing list reported ‘clipped words’ with 10ms iLBC because packet loss caused the decoder to skip ahead, cutting off syllables.
With 30ms, you lose more audio per packet-but you lose fewer packets. The codec can sometimes reconstruct missing chunks using neighboring data. G.729 with Forward Error Correction (FEC) can mask losses at 30ms better than at 10ms, because there’s more audio context to work with.
But here’s the catch: if the total delay from 30ms packetization pushes you over 150ms, the delay itself becomes the biggest quality killer. Research from ICN 2002 showed that even with perfect audio, users rated calls with 180ms delay as ‘unusable’ because the conversation felt broken.
Real-World Trade-offs: What Companies Actually Do
Most businesses don’t pick based on theory. They pick based on pain.
A contact center with 500 agents switched from 30ms to 20ms. Bandwidth went up by 33%. But voice quality complaints dropped from 12% to 3%. Why? Because agents were constantly missing the start of customer sentences. At 30ms, the delay made it feel like the customer was talking into a tunnel.
Another company, a financial services firm, went all-in on 10ms. Their traders needed crystal-clear communication during market events. Mishearing ‘sell’ for ‘buy’ could cost thousands. They spent 48% more on bandwidth-but cut miscommunication errors by 15%. The cost was justified.
Meanwhile, small businesses with slow internet often stick with 30ms and G.729. They can’t afford to burn bandwidth. They accept the lag because their calls are mostly transactional: ‘Yes, I got your invoice,’ ‘I’ll send the file.’ No one’s giving a live presentation or negotiating a deal over the phone.
What’s the Best Choice?
There’s no universal winner. But here’s how to decide:
- Use 10ms if you need ultra-low latency: live interpretation, trading floors, music collaboration, or any scenario where timing is critical. You’ll need strong, reliable internet-fiber or enterprise-grade 5G.
- Use 20ms if you’re running a business with 10+ concurrent calls and care about both quality and cost. This is the sweet spot for 90% of companies. Cisco, Avaya, and most enterprise systems default to this. It balances bandwidth, delay, and resilience.
- Use 30ms if bandwidth is tight: rural offices, remote workers on mobile networks, or legacy systems with G.729. Only choose this if you’ve tested the delay and users aren’t complaining about lag.
And here’s a pro tip: don’t just pick one and forget it. Test. Use Wireshark to monitor packet loss. Ask your users: ‘Do you ever feel like you’re talking over each other?’ If yes, reduce the interval. If your bandwidth is maxed out, try 30ms with VAD (Voice Activity Detection) turned on. It cuts bandwidth by half during silence.
The Future: Adaptive Packetization
The industry is moving away from fixed intervals. Cisco’s latest IOS updates (17.9.2) now adjust packetization on the fly-switching from 10ms to 30ms if the network gets congested, then back up when it clears. Google’s Project Starline uses 10ms with AI-powered error correction to make video calls feel face-to-face.
By 2026, Gartner predicts 70% of enterprise VoIP systems will use adaptive packetization. That means your phone will auto-optimize based on signal strength, network load, and even the type of call you’re on.
Until then, stick with 20ms. It’s the default for a reason. It works. It’s reliable. And unless you’re in a high-stakes environment, you won’t notice the difference between 20ms and 10ms-but you’ll definitely notice the bill when you switch to 10ms without upgrading your internet.
Quick Summary
- 10ms = lowest delay, highest bandwidth, best for real-time interaction
- 20ms = industry standard, best balance of quality, cost, and reliability
- 30ms = lowest bandwidth, highest delay, best for weak networks
- Always test with real users before changing settings
- Adaptive packetization is coming-start planning for it
What’s the difference between 10ms, 20ms, and 30ms packetization in VoIP?
Packetization interval is how long each audio chunk lasts before being sent as a packet. 10ms means 100 packets per second, 20ms means 50, and 30ms means 33.3. Smaller intervals reduce delay but increase bandwidth use because of more headers. Larger intervals save bandwidth but add delay, which can make conversations feel unnatural.
Why does 10ms packetization use more bandwidth than 30ms?
Every VoIP packet has a fixed-size header (IP, UDP, RTP-about 54 bytes). With 10ms, you send twice as many packets as 20ms, and three times as many as 30ms. Even though each packet carries less audio, the headers add up. For G.711, 10ms uses nearly 50% more bandwidth than 30ms because of this overhead.
Is 30ms packetization bad for call quality?
Not inherently. But when combined with network jitter buffers and transmission delays, 30ms can push total call delay past 150ms-the point where conversations start to feel broken. Users report lag, talking over each other, and unnatural pauses. If your network is stable and bandwidth is limited, 30ms can work fine. But for interactive calls, it’s risky.
Which codec works best with 30ms packetization?
G.729 is commonly used with 30ms because it’s a low-bitrate codec (8 Kbps) and was designed for bandwidth-constrained networks. iLBC also supports 30ms and handles packet loss well. But neither is ideal for real-time interaction due to the added delay. G.711 with 30ms saves bandwidth but requires strong network conditions to avoid lag.
Should I use 10ms packetization for my small business?
Only if you have high-speed, reliable internet and need ultra-low latency-for example, if you’re doing live translation, remote surgery coordination, or high-frequency trading. For most small businesses, 10ms wastes bandwidth and increases costs without noticeable benefits. Stick with 20ms unless you have a specific need for speed.
How do I test which packetization interval works best?
Use a tool like Wireshark to monitor packet loss and jitter. Make test calls with your team using each setting (10ms, 20ms, 30ms). Ask: Do you hear clipped words? Do you talk over each other? Is the audio choppy? Track how often you need to say ‘Can you repeat that?’ Then check your bandwidth usage. The best setting is the one that minimizes complaints without overloading your network.