Call Duration

Understand Call Duration measurement — how CallMeter tracks the connected time of a test call, and what duration reveals about test scenario execution and SLA compliance.

Call Duration measures the total time the call was in the connected state, from the moment it was answered (200 OK) to the moment it was terminated (BYE), in milliseconds. This is the period during which media was expected to flow and quality metrics were being collected.

Think of it as the length of the actual conversation — the time between picking up the phone and hanging up. Everything before the answer is call setup, and everything after hangup is cleanup.

One-shot metric

Call Duration is captured once per call. It appears in the Call Timing Overview cards on the endpoint detail page and in aggregate statistics on the test run summary.

How It Works

CallMeter records two timestamps:

Answer time — When the 200 OK response completes the SIP handshake
BYE time — When either side sends a SIP BYE to terminate the call

Call Duration = bye_at - answer_at

For test calls, the duration is typically determined by the test configuration — for example, "call for 60 seconds." For probe calls, the duration depends on the probe's configured call length. In either case, the actual measured duration should match the configured value within a small tolerance.

Why It Matters

Call Duration is primarily a test validation metric:

Test scenario verification — Confirms that calls ran for the configured duration. A call configured for 60 seconds that ended after 10 seconds indicates a problem.
Premature termination detection — Short durations relative to the configured length suggest something caused the call to end early: network failure, server error, or media timeout.
SLA compliance — Some enterprise SLAs define minimum call durations for monitoring probes. Duration validates compliance.
Quality context — All time-series quality metrics (MOS, jitter, packet loss) are collected during the connected period. Duration determines how much quality data is available for analysis.

Common Causes of Unexpected Call Duration

Cause	Explanation
Shorter than expected	Premature BYE from remote side, network failure, or media timeout
Much shorter than expected	Call immediately terminated after answer, possibly authentication or authorization failure
Longer than expected	BYE not processed, call stuck in connected state
Zero duration	Call answered and immediately terminated (auto-reject or error)
Varying durations	Inconsistent remote endpoint behavior across test calls

How to Fix It

Compare with configured duration — If the actual duration does not match the test configuration, investigate why the call ended early or ran long.
Check the Final Status Code — Review Final Status Code and Call Result for calls with unexpected durations.
Look for media timeouts — Some SIP servers terminate calls when no media flows for a period. Check Time to First Media and verify RTP is flowing.
Review BYE originator — Determine whether the test endpoint or the remote side initiated the hangup. Remote-initiated BYE on a test call indicates the remote side decided to end the call.
Check for session timer expiry — SIP session timers (RFC 4028) can terminate calls if refresh messages are not exchanged. Ensure session timers are properly handled.

Call Setup Time — Time before the call connected; setup + duration = total call time
Call Result — Outcome of the call; explains why short calls ended
Final Status Code — SIP response code for calls that failed
Time to First Media — Media startup delay within the connected period

RFC Reference

SIP call duration spans from the 200 OK response to the BYE transaction, both defined in RFC 3261 (SIP: Session Initiation Protocol). The 200 OK is described in Section 13.2.2.4, and BYE is described in Section 15. Session timers that can affect call duration are defined in RFC 4028 (Session Timers in the Session Initiation Protocol).