Skip to navigation
LAUNCHTelephony

Call Quality

The metrics that decide how a call sounds, the targets we aim for, and how to measure them on your network.

Call quality depends on how quickly and how steadily audio packets travel between the caller, your network, and Synthflow. To check a single call, open it in Logs and read the quality metrics on its SIP Call Ladder. To baseline your network or compare two setups, follow the methodology below.

Metrics

For traffic that stays within a region, we target the values below under healthy network conditions. Results depend on your access network, peering, and carrier path.

MetricWhat it measuresTarget
Round-trip time (RTT)How long audio takes to reach the far end and come back.Under 100 ms
One-way latencyThe delay between one person speaking and the other hearing it. About half of RTT.Under 50 ms
Jitter (PDV)How much the delay varies from packet to packet.Low and stable at p95
Packet lossThe share of audio packets that never arrive.Minimal at p95
MOSA score from 1 to 5 estimating how the call sounds overall.Above 4.2
Call setup timeThe time from the SIP 100 Trying to the 200 OK.Monitor for increases
Error rateSIP 4xx and 5xx responses, and RTP late or empty-buffer events.Monitor for increases

Jitter and speech quality

RTP packets carry audio frames that expect to arrive at a near-constant pace. When arrival times vary, the jitter buffer on the receiving side has to compensate:

  • It stretches playback to avoid gaps, which sounds robotic or slow.
  • It drops packets that arrive too late, which sounds choppy.
  • It catches up when a burst of packets arrives, which causes a brief squeal or fast-forward effect.

Low, stable jitter avoids these effects and keeps speech at its natural pace.

Methodology

Use these steps to baseline your network, compare before and after a change, or investigate a quality complaint.

  1. Network path. Run mtr -u -c 200 <media-endpoint> to see UDP loss and jitter along the path, and ping -c 200 <media-endpoint> for a baseline RTT. Some networks filter ICMP, so ping can fail where mtr works.
  2. Synthetic calls. Place calls between your PBX and Synthflow, capture the RTP in Wireshark, and review the RTP Stream statistics for jitter, loss, and skew. To control load and log response times, place the calls with sipp.
  3. Jitter and loss under load. Outside business hours, run iperf3 -u -b 2M -t 60 -c <test-host> against a test server to measure UDP loss and jitter. Where the Synthflow backbone is available, compare it with the public internet path.
  4. MOS. Derive the R-Factor and MOS with an E-Model tool, from the measured one-way delay, jitter, and loss.
  5. Sampling. Collect at least 100 calls or 30 minutes per scenario, and record p50, p95, and p99 for each metric.

Jitter and loss come in bursts, so a single call tells you little. Sample during busy hours, such as 10:00 to 12:00 and 14:00 to 17:00 local time, and compare across weekdays.

Regional deployment

When your callers are far from the nearest Synthflow region, we can deploy a point of presence (PoP) closer to them and route traffic between regions over the Synthflow backbone instead of the public internet. In the LATAM case study, this cut round-trip time by 48%. We can also help you choose routing and codecs to meet your SLA.

  1. Map your call distribution and find your busiest geographies.
  2. Measure baseline metrics with the methodology above.
  3. Request a regional PoP near your callers.
  4. Route calls and media to the new PoP, and turn on backbone routing for segments that cross regions.
  5. Verify your codecs. Start with G.711.
  6. Tune the jitter buffer on your PBX or SBC, if it is configurable.
  7. Measure again and compare p50, p95, and p99 against the baseline.

After the move, watch for:

  • ISP changes and peering shifts that reintroduce jitter.
  • Packet bursts at hour boundaries, when dialers start, which cause short jitter spikes.
  • SBC and NAT keep-alive intervals.