Audio Packetization Interval — VoIP Audio Metric
Audio ptime in milliseconds — the SIP packetization interval that determines the tradeoff between latency, bandwidth efficiency, and per-packet loss impact.
Audio Packetization Interval
| Property | Value |
|---|---|
| Key | audio_packetization_ms |
| Unit | ms |
| Type | Per-call value |
| Direction | Both |
What It Measures
Audio Packetization Interval — commonly called ptime — is the amount of audio encoded into each RTP packet, measured in milliseconds. A ptime of 20ms means each RTP packet contains 20 milliseconds of audio. This value is negotiated during SIP call setup via the a=ptime attribute in the SDP offer/answer exchange.
Ptime is a per-call constant for the duration of a session. CallMeter captures it from the SDP negotiation and reports it alongside runtime metrics so you can correlate packetization choices with observed quality outcomes.
Why It Matters
Ptime is one of the most consequential VoIP configuration decisions, and it is frequently misconfigured or mismatched between endpoints. The choice involves a direct tradeoff between three competing requirements:
Latency vs. Efficiency vs. Loss Resilience:
| Ptime | Packets/Second | IP Overhead | Latency Added | Loss Impact |
|---|---|---|---|---|
| 10ms | 100 pps | Highest | Minimal | Each lost packet = 10ms dropout |
| 20ms | 50 pps | Standard | Moderate | Each lost packet = 20ms dropout |
| 30ms | ~33 pps | Lower | Higher | Each lost packet = 30ms dropout |
| 60ms | ~17 pps | Lowest | Significant | Each lost packet = 60ms dropout |
The 20ms default exists because it balances all three concerns adequately for most use cases. However:
- Real-time trading floors, emergency dispatch, and low-latency applications use 10ms ptime to minimize the audio codec's contribution to end-to-end latency.
- Carrier trunks and high-volume platforms often use 30ms or 60ms to reduce packet rates and IP overhead — critical when handling thousands of concurrent calls.
- Mismatched ptime is a common source of audio quality issues. If the sender uses 20ms but the SBC transcodes to 60ms, the receiver experiences increased latency and a higher per-packet loss impact without any network change.
For IVR and DTMF-sensitive test scenarios, ptime matters: longer ptime intervals can cause DTMF digit recognition problems if the DTMF event spans a packet boundary inefficiently.
Thresholds
Ptime does not have "good/warning/critical" thresholds in the traditional sense. The correct value is use-case dependent. Flag these conditions:
| Condition | Concern |
|---|---|
| Mismatch between send and receive ptime | Transcoding overhead, potential SBC configuration error |
| 60ms ptime on low-loss-tolerance paths | High per-packet loss impact, review against actual loss rate |
| 10ms ptime on high-volume trunks | Excessive packet rate, may exceed SBC PPS capacity |
How to Fix It
- Verify ptime agreement. Compare the send and receive ptime values for each endpoint. A mismatch means an SBC or media gateway is repacketizing the stream — adding latency and CPU overhead.
- Match ptime to your use case. For latency-sensitive applications, use 10ms or 20ms. For bandwidth-constrained or high-volume deployments, evaluate 30ms. Never use 60ms without verifying your loss tolerance.
- Check SDP offers. If ptime is not what you configured, inspect the SDP offer/answer. A proxy or SBC may be overriding your endpoint's preference during signaling.
- Correlate with loss impact. With 60ms ptime and 1% packet loss, you lose 60ms of audio per dropped packet. Check Burst Duration — if bursts align with your ptime, the packetization choice is compounding the impact.
Related Metrics
- Packet Loss Rate — Loss impact scales directly with ptime
- Burst Duration — Burst length expressed in packets translates to milliseconds via ptime
- PLC Events — Each lost packet at the chosen ptime triggers one PLC event
- Post-Dial Delay — SDP negotiation during call setup is where ptime is established