Call Result

Call Result provides a human-readable classification of how the call ended: answered, busy, failed, timeout, or cancelled. While Final Status Code gives you the precise SIP response code, Call Result translates that into a business outcome that is immediately understandable without SIP protocol knowledge.

Think of it as the plain-English summary of what happened. Instead of "486 Busy Here," you see "busy." Instead of "408 Request Timeout," you see "timeout." This makes it easy to scan test results and immediately understand call success or failure.

How It Works

CallMeter maps the SIP final status code to one of several call result categories:

Why It Matters

Call Result is the primary metric for determining test success at a glance:

• Test pass/fail — A test expecting all calls to be answered can quickly filter for non-answered results
• Dashboard overview — Call result distribution across a test run immediately shows the health of the infrastructure
• Trend analysis — Tracking call result distribution over repeated probe executions reveals degradation patterns
• Root cause triage — The result category points you to the right investigation path: timeout means reachability, busy means capacity, failed means configuration

For enterprise VoIP testing, Call Result is typically the first metric reviewed after a test completes. It answers the most fundamental question: "did the calls work?"

Common Call Results and What They Mean

answered

The call completed successfully. Media flowed for the configured duration. This is the expected result for passing tests. All quality metrics (MOS, jitter, packet loss) are available for analysis.

timeout

The remote side did not respond. This could mean the server is unreachable, overloaded, or the destination does not exist. Check network connectivity and server health.

busy

The destination is occupied. In load testing, increasing busy results indicate the remote system is reaching its call capacity. In monitoring probes, busy results may indicate legitimate traffic on the test line.

failed

A catch-all for SIP errors that do not fit the other categories. Check the Final Status Code for the specific error. Common causes include codec mismatch (488), authentication failure (401/407), or server errors (500/503).

cancelled

The call was cancelled before being answered. In testing, this typically means the test timed out waiting for an answer, or the test was manually stopped.

rejected

The remote side explicitly refused the call. This may indicate authorization issues, number blocking, or deliberate call rejection.

How to Fix It

1. Start with the result distribution — What percentage of calls achieved each result? For a healthy test, the vast majority should be "answered."
2. Investigate the dominant failure — If most failures are "timeout," focus on server reachability. If "failed," check the specific status codes. If "busy," assess remote capacity.
3. Check Final Status Code — For any non-answered result, the Final Status Code provides the specific SIP error for targeted debugging.
4. Compare across test runs — If a result type increases over time, the underlying cause is getting worse. If it appears suddenly, something changed.
5. Validate test configuration — Ensure the test target, credentials, and codec settings are correct. Many "failed" results in a new test indicate configuration problems.

Related Metrics

• Final Status Code — The precise SIP code behind each call result
• Call Setup Time — Only meaningful for "answered" results
• Call Duration — Duration of the connected period for "answered" calls
• Post-Dial Delay (PDD) — Setup timing context for all call results