Why These Three Numbers Define VoIP Quality

When your agents complain about choppy calls, delayed responses, or audio that cuts out mid-sentence, the root cause is almost always one of three transport-layer pathologies: jitter, latency, or packet loss. Conflating them leads to wrong fixes. A team that adds buffer to solve latency will make jitter worse. A team that buys more bandwidth to fix packet loss often changes nothing if the loss is caused by a misconfigured queue.

Understanding each metric independently is the prerequisite to fixing call quality on any outbound SIP trunk — including UnlimCall's flat-rate network.

Latency: One-Way Delay and Its Sources

Latency in VoIP is the time from when audio is captured at the sender's microphone to when it is played out at the receiver's speaker. ITU G.114 recommends a maximum one-way delay of 150 ms for conversational quality. Beyond 150 ms, the far end begins to feel the lag. Beyond 250 ms, both parties start talking over each other.

Sources of one-way delay in a typical outbound call:

UnlimCall's edge contributes under 50 ms from the point where audio enters our PoP to the point it reaches the PSTN gateway. The agent-side network is the variable you control. Measuring one-way delay accurately requires synchronized clocks (NTP or PTP) at both endpoints, or RTCP-XR reports from your SBC.

Jitter: Variance Is the Enemy

Jitter is not average delay — it is the variation in delay between successive RTP packets. If packets consistently arrive 80 ms after they were sent, that is high latency but zero jitter, and a playout buffer of 80 ms resolves it transparently. If packets arrive at intervals varying between 20 ms and 140 ms with an average of 80 ms, that is 60 ms of jitter — and it will audibly clip audio even if average latency is within tolerance.

A jitter buffer absorbs timing variance by holding packets briefly before playing them out, creating a fixed playout delay. Adaptive jitter buffers adjust depth dynamically (common in softphones). Static buffers set a fixed depth at call setup (common in hardware phones and some SBCs).

Acceptable jitter: under 20 ms peak-to-peak on the WAN path. Jitter above 30 ms starts producing audible artifacts with a 40 ms static buffer. Jitter above 50 ms will defeat most adaptive buffers and produce clipping.

Measure jitter using iperf3 -u -b 1M --jitter-mode or pull RTCP Receiver Reports from your SBC. Both report inter-arrival jitter in milliseconds.

Common jitter sources:

• Shared internet links with uncontrolled bulk transfers
• Wi-Fi interference causing retransmission delays
• Overloaded switches dropping to CPU-based forwarding
• CPU contention on software-based SBCs (Asterisk/FreeSWITCH on busy hosts)

The fix is almost always QoS policy enforcement plus dedicated bandwidth, not increasing the jitter buffer depth.

Packet Loss: When Frames Never Arrive

Packet loss is the percentage of RTP packets that are sent but never received. Unlike TCP, UDP (which carries RTP) has no retransmission mechanism. A lost packet produces a short gap in audio — a "click" if isolated, an audible dropout if sustained.

Perceptible call quality degradation by loss rate:

• 0–0.5%: transparent, no audible impact with concealment enabled
• 0.5–1%: slight artifacts, acceptable for most outbound use cases
• 1–3%: noticeable clipping, agent and contact both experience degradation
• Above 3%: calls are effectively unusable; contacts will hang up

Loss has two varieties: random (individual scattered packets) and burst (sequential losses affecting multiple packets). Burst loss is significantly more damaging to perceived quality — a 10-packet burst is worse than ten isolated single-packet losses, because packet loss concealment (PLC) only masks 1–2 sequential missing frames.

Common causes: network congestion (queue tail-drop), physical layer errors (bad cable, SFP, or Wi-Fi), routing loops producing TTL expiry, and firewall stateful table overflow. Check ifconfig output for RX errors and TX errors on every interface in the audio path. A single bad patch cable can produce 2–5% packet loss with no visible alarm.

How to Measure All Three Together

Use a continuous SIP call probe or a dedicated VoIP monitoring tool (VQManager, PRTG with VoIP sensor, or SIPp with RTCP collection) to capture metrics on live calls. Pull RTCP Receiver Reports from your SBC — they report jitter and loss per RTP stream per call. Most SBCs expose these via SNMP, REST API, or syslog.

For a quick field test before going live with a new SIP trunk configuration:

```bash

Send 1000 UDP packets at 50 pps to simulate one G.711 RTP stream

hping3 -2 -p 5060 -i u20000 --count 1000 <unlimcall_sip_ip> ```

Note the loss% and jitter fields in the output. These are approximate but sufficient for a pre-flight check.