Check RTP packetization when IllyVoIP audio breaks up

Packetization is how much encoded audio a sender places in each RTP packet. An unsuitable or inconsistent media configuration can complicate an audio problem, but packetization is not a universal explanation for choppy calls. Measure the stream before changing your phone or PBX.

1. Start with one affected call

1. Find the IllyVoIP call reference, time and timezone, and note who heard the problem.
2. Record the phone or PBX model, software version and active codec for that call.
3. Obtain an authorized capture or media statistics from equipment you control. Avoid capturing unrelated conversations.
4. Compare a good and affected call using the same equipment where possible.

A Portal call record does not contain a complete RTP capture. Encrypted media may limit what a network tool can interpret. Use the diagnostics your endpoint supports; do not disable encryption or retain unnecessary voice payloads just to obtain a graph.

2. Read the negotiated media information

Check the SDP offer and answer for the audio stream. The payload number must be interpreted using its negotiated mapping. Read any ptime and maxptime attributes, remembering that an advertised preference or limit is not proof of the packet spacing actually sent. Check both directions: the two endpoints need not send identical packet sizes.

3. Measure a continuous part of one RTP stream

Select packets from the same source stream and payload mapping. Avoid comparing packets across a codec change, a silence gap or another SSRC. RTP sequence numbers help identify missing or reordered packets; timestamps describe media sampling time, not the wall-clock arrival time shown by a capture tool.

Illustrative PCMU stream, RTP clock 8000 Hz:
Sequence    RTP timestamp    Audio payload
1000        80000            160 bytes
1001        80160            160 bytes
1002        80320            160 bytes

Timestamp step = 160
Audio duration = 160 / 8000 seconds = 20 ms

This example contains invented values to show the calculation. PCMU uses one byte per sample, so 160 audio bytes here represent 20 milliseconds. Do not include IP, UDP or RTP header bytes as audio payload. Do not apply that byte calculation to compressed codecs with different framing.

4. Use the correct RTP clock

Look up the negotiated payload’s RTP clock rather than assuming that every audio codec uses its acoustic sample rate. G.722 is a notable example: its RTP clock is 8000 Hz even though the audio sampling rate is 16000 Hz. A mistaken clock doubles or halves the duration you calculate.

If sequence numbers jump from 1000 to 1002 and the timestamp step doubles, you may be observing a missing packet, not a sender that changed packetization. Inspect a continuous run of adjacent packets and compare sender-side evidence if available. Timestamp wraparound also requires the appropriate unsigned arithmetic.

5. Separate packetization from network timing

1. Compare the timestamp steps with arrival spacing during steady speech.
2. Check sequence gaps, duplicates and reordering using the analysis tool.
3. Look for bursts or irregular arrival times even when timestamp steps are steady.
4. Compare the reverse direction and any available endpoint jitter-buffer statistics.

Jitter and loss describe transport behavior, while packetization describes how audio is grouped. Wi-Fi congestion, overloaded equipment or a media path problem can cause breakup even with consistent 20-millisecond packets. A capture taken at one point cannot prove where a missing packet was lost.

6. Make one supported change and retest

If the endpoint documentation and evidence justify a packetization adjustment, record the original value and change only the supported setting on equipment you manage. Do not assume IllyVoIP has a Portal packetization switch. Check the resulting SDP and actual RTP after the change, then compare an authorized test call in both directions. Restore the prior value if the evidence does not improve.

For Support, supply the call reference, codec and RTP clock, measured timestamp steps, sequence-loss observations and the capture location. Remove private payloads and credentials. Explain what you measured rather than reporting a packetization value inferred from a generic phone setting alone.

Related guides

• Diagnose choppy IllyVoIP calls: jitter, packet loss and network load
• Check RTP payload types against SDP when IllyVoIP audio fails

Reference

Current instructions and technical reference: RFC 3551: RTP audio profile, RFC 3550: RTP, RFC 8866: Session Description Protocol.

Reviewed 12 October 2026 against the current IllyVoIP controls, implementation and applicable references. Available options depend on account permissions and service state.