Round Trip Time
Network round-trip time measured via RTCP — the latency between sending a packet and receiving the response, directly impacting conversation quality.
Round Trip Time
| Property | Value |
|---|---|
| Key | rtt_ms |
| Unit | Milliseconds (ms) |
| Type | Gauge |
| Direction | Send and Receive |
| RFC | RFC 3550 Section 6.4.1 |
What It Measures
Round-trip time (RTT) measures how long it takes for a signal to travel from one endpoint to the remote endpoint and back. It is the most fundamental measure of network latency between two points in a VoIP call.
In everyday terms, RTT is the "ping time" of your voice call. If RTT is 200ms, there is at minimum a 100ms one-way delay before the other party hears what you say.
CallMeter measures RTT using RTCP Sender Reports and Receiver Reports as defined in RFC 3550. When endpoint A sends an RTCP Sender Report, it includes a timestamp. When endpoint B responds with a Receiver Report, it echoes that timestamp and notes how long it held the packet. Endpoint A can then compute the round trip: total time elapsed minus the processing delay at B.
Why It Matters
Latency is the enemy of natural conversation. Human communication relies on rapid turn-taking, and even small delays disrupt this:
| RTT | One-Way Delay | User Experience |
|---|---|---|
| Below 100ms | Below 50ms | Natural conversation. No perceptible delay. |
| 100 - 200ms | 50 - 100ms | Slight delay. Acceptable for most calls. |
| 200 - 400ms | 100 - 200ms | Noticeable delay. Talk-over begins. |
| Above 400ms | Above 200ms | Satellite-like delay. Conversation is difficult. |
ITU-T G.114 recommends a maximum one-way delay of 150ms for acceptable quality. Above this threshold, users begin to talk over each other, leading to frustration and repeated phrases.
How CallMeter Measures It
CallMeter measures RTT through the standard RTCP SR/RR exchange defined in RFC 3550. This happens automatically as part of the RTCP protocol — no additional probes or ICMP pings are needed. The measurement captures the true media-path latency, which may differ from ICMP ping latency if media and signaling take different network routes.
RTT is updated every RTCP reporting interval (typically every few seconds) and interpolated for per-second reporting.
Thresholds
| Level | Value | Meaning |
|---|---|---|
| Good | 100ms or below | No conversational impact |
| Warning | 100ms - 400ms | Monitor for talk-over complaints |
| Critical | Above 400ms | Conversation quality severely impacted |
What Causes High RTT
- Geographic distance — Light in fiber travels at roughly 200km/ms. A 10,000km path adds 100ms of irreducible propagation delay (round trip).
- Network congestion — Queuing at saturated links adds variable delay on top of propagation delay.
- Suboptimal routing — Traffic routed through distant exchanges when a shorter path exists. Check traceroute for unnecessary hops.
- SIP proxy or B2BUA overhead — Media anchoring through a Session Border Controller or B2BUA adds processing delay at each hop.
- VPN or tunnel encapsulation — Encrypted tunnels add encapsulation overhead and may route traffic through central gateways.
How to Fix It
- Place workers near your SIP infrastructure. If testing a server in Frankfurt, use a European worker region rather than one in North America.
- Check routing. Use traceroute to verify the media path is direct. Look for traffic tromboning through distant points.
- Evaluate media anchoring. If an SBC or B2BUA is anchoring media, measure RTT with and without it to quantify its overhead.
- Reduce VPN hops. If media must traverse a VPN, ensure the tunnel endpoint is geographically close to both parties.
- Monitor over time. RTT that suddenly increases may indicate a routing change. Use CallMeter's timeline to pinpoint when the shift occurred.