> For a complete page index, fetch https://docs.synthflow.ai/llms.txt. For full documentation content, fetch https://docs.synthflow.ai/llms-full.txt. # Call Quality > Telephony call quality metrics (round-trip time, latency, jitter, packet loss, and MOS), Synthflow's targets, how to measure them on your network, and how to request a regional deployment. 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](/logs) and read the quality metrics on its [SIP Call Ladder](/sip-call-ladder#call-quality). To baseline your network or compare two setups, follow the [methodology](#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. | Metric | What it measures | Target | | --------------------- | ---------------------------------------------------------------------------------- | --------------------- | | Round-trip time (RTT) | How long audio takes to reach the far end and come back. | Under 100 ms | | One-way latency | The 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 loss | The share of audio packets that never arrive. | Minimal at p95 | | MOS | A score from 1 to 5 estimating how the call sounds overall. | Above 4.2 | | Call setup time | The time from the SIP `100 Trying` to the `200 OK`. | Monitor for increases | | Error rate | SIP `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 ` to see UDP loss and jitter along the path, and `ping -c 200 ` 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 ` 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](/deploy-in-latam-regions), 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](#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. > The metrics that decide how a call sounds, the targets we aim for, and how to measure them on your network.