ASR is the share of call attempts that get answered. ACD is the average duration of answered calls. PDD is the time from call setup to the far end ringing. Those are the three numbers every wholesale buyer watches.
The governing principle: none of them means anything alone, and none of them means anything without a baseline for the destination. A 35% ASR can be excellent on one destination and a route failure on another. A short ACD can be normal traffic or fraud. You read these metrics in pairs, against history, and against other routes to the same place. That’s the whole playbook. The rest is detail.
This is written for people running least-cost routing across several carriers. It assumes you have CDRs and a query tool.
Definitions you can compute
Get the definitions exact and consistent first. Half of all quality disputes between carriers turn out to be two teams computing ASR differently.
ASR (answer-seizure ratio): answered calls divided by attempts sent to the route. Define “attempt” explicitly. Include calls that failed on the route (4xx, 5xx, timeouts). Exclude calls your own switch rejected before routing. Count calls cancelled by the originator (487) as attempts; the route didn’t fail, but they’re part of the denominator the carrier sees.
ACD (average call duration): total billable seconds of answered calls divided by answered calls. Use the billable duration, from answer to disconnect.
PDD (post-dial delay): time from sending INVITE to receiving the first 180 or 183. Report median and a high percentile, not the mean. PDD distributions have long tails, and the mean hides them.
NER (network effectiveness ratio): the share of attempts that the network delivered to the called party’s side, whether the person answered, was busy, didn’t answer, or rejected the call. It strips out user behavior. If ASR is “did someone pick up,” NER is “did the network do its job.” This is the metric that separates route problems from destination behavior.
Computing them from CDRs
A minimal query, assuming a CDR table with setup, first-ring, answer and end timestamps plus the final SIP response code:
SELECT
route_id,
dest_prefix,
COUNT(*) AS attempts,
SUM(CASE WHEN answer_ts IS NOT NULL THEN 1 ELSE 0 END) AS answered,
1.0 * SUM(CASE WHEN answer_ts IS NOT NULL THEN 1 ELSE 0 END)
/ COUNT(*) AS asr,
SUM(CASE WHEN answer_ts IS NOT NULL
THEN EXTRACT(EPOCH FROM end_ts - answer_ts) END)
/ NULLIF(SUM(CASE WHEN answer_ts IS NOT NULL THEN 1 ELSE 0 END), 0)
AS acd_seconds,
PERCENTILE_CONT(0.5) WITHIN GROUP
(ORDER BY EXTRACT(EPOCH FROM ring_ts - setup_ts)) AS pdd_p50,
PERCENTILE_CONT(0.9) WITHIN GROUP
(ORDER BY EXTRACT(EPOCH FROM ring_ts - setup_ts)) AS pdd_p90,
1.0 * SUM(CASE WHEN answer_ts IS NOT NULL
OR final_code IN (486, 480, 603) THEN 1 ELSE 0 END)
/ COUNT(*) AS ner,
1.0 * SUM(CASE WHEN answer_ts IS NOT NULL
AND end_ts - answer_ts < INTERVAL '6 seconds'
THEN 1 ELSE 0 END)
/ NULLIF(SUM(CASE WHEN answer_ts IS NOT NULL THEN 1 ELSE 0 END), 0)
AS short_call_share
FROM cdr
WHERE setup_ts >= NOW() - INTERVAL '24 hours'
GROUP BY route_id, dest_prefix
HAVING COUNT(*) >= 300;Code language: PHP (php)Adjust the NER code set to your switch’s mapping; 480 (temporarily unavailable) is sometimes a network failure in disguise. The short-call share is not a standard metric. Add it anyway. It’s the cheapest fraud and audio detector you’ll ever build.
The HAVING clause matters. More on that below.
Read them in pairs
Single metrics generate false alarms. Pairs point at causes. This table covers the patterns that come up most:
| Pattern | Likely cause | First check |
|---|---|---|
| ASR down, NER stable | Recipients not answering: CLI, list quality, time of day | What number arrived on test calls |
| ASR down, NER down | Route or upstream failure | Spike in 5xx, 408, or 503 responses |
| ASR up sharply, ACD down, short-call share up | False answer supervision | Listen to short calls; check answer before ring |
| ASR stable, ACD down on one route only | Audio problems causing hang-ups: one-way audio, jitter, codec mismatch | RTP stats, test calls on that route |
| PDD up, ASR stable | Extra transit hops or upstream route change | Test CLI and audio on the route |
| 404 / 484 spike on one prefix | Numbering plan change or bad prefix mapping | Destination numbering updates |
| ASR down on all routes to a destination | Destination-side event: outage, holiday, regulation | Compare routes; check destination news |
The last row is the one that saves you from dropping good routes. If every route to a destination falls at once, the routes aren’t the problem.
False answer supervision deserves its own section
False answer supervision is the far end signaling “answered” when no human has answered. It shows up as an ASR that looks better than any competing route, with a cluster of calls lasting a few seconds, often answered faster than a phone could plausibly ring.
It’s costly in two ways. You pay for calls that never connected to a person. And coarse billing makes each one expensive; the billing increments breakdown shows how a 60/60 route turns a four-second fake answer into a billed minute.
Detection that works: flag routes where the gap between first ring and answer is often under a second or two, where answers arrive with no 180/183 at all, or where short-call share runs well above other routes to the same prefix. Then sample the audio. Ringback tones or silence after “answer” confirm it.
Sample size and time windows
Small samples lie. A route with 40 attempts in an hour can swing ten points of ASR on noise alone.
Set a minimum attempt count before any metric triggers an action. The 300 in the query above is arbitrary; pick a floor from your own volume and stick to it. For low-volume destinations, widen the window to a day or a week instead of alerting on hourly data.
Compare like with like on time. ASR on consumer mobile destinations has a strong daily shape: people answer differently at 10 a.m. and 9 p.m. local time. Compare a route’s evening performance with its own evenings, or with other routes over the same hours. Week-over-week is a better baseline than hour-over-hour.
Watch for mix shifts. If a customer moves a campaign onto a route, the route’s ASR changes because the traffic changed, not the route. Break metrics down by customer or traffic tag where you can.
Baselines per destination, not per network
There is no universal “good ASR.” Destinations differ in mobile share, calling culture, spam filtering and a dozen other things. Any benchmark number applied across destinations will be wrong for most of them.
Build a baseline per destination prefix from your own history across all routes. A reasonable approach: rolling 28-day median ASR, ACD and PDD per prefix, weighted by volume. Then evaluate each route relative to that baseline and relative to the best route on the same prefix.
At scale, this is the only method that holds up. Across a footprint like IDT Express’s 160+ termination countries, the destinations behave too differently for any global threshold to mean anything. Per-prefix baselines are what make the comparison fair.
Alerts that don’t page you for noise
An alert should fire on a pattern that implies a cause, not on a single metric crossing a line. Otherwise the NOC learns to ignore it.
Three rules keep alert volume sane. Alert on deviation from the prefix baseline, not on absolute values. Require the deviation to persist across two consecutive windows above the sample floor. And encode the pairs from the table above as the alert conditions themselves: “ASR down and NER down on one route while other routes hold” is a page; “ASR down on every route to a prefix” is a notification to check the destination, not a route incident.
Send FAS-pattern alerts to a different queue from quality alerts. They need a billing and commercial response, and whoever handles route quality usually isn’t the person who disputes invoices.
Review alert history monthly. Any alert that fired repeatedly without leading to an action should be retuned or deleted.
When to drop a route
Deciding to pull a route is a judgment call, but the judgment gets easier with rules.
A defensible sequence:
- Confirm it’s the route. Other routes to the same prefix are holding steady. If they aren’t, stop; it’s the destination.
- Confirm it’s not noise. The drop holds above your sample floor for at least two comparable windows.
- Classify the failure. Network (NER down), recipient (ASR down, NER steady), audio (ACD down), or fraud (FAS pattern). Each has a different response.
- Reduce weight before removing. Shift a share of traffic to alternates and watch whether the route’s metrics recover at lower load. Some routes degrade only under volume.
- Open a ticket with evidence. Call IDs, timestamps, SIP codes, test results. Carriers fix documented problems faster than complaints.
- Remove if it doesn’t recover within the window you’ve agreed internally. Put it back into testing, not production, when the carrier reports a fix.
For FAS, skip straight to removal and dispute. That’s not a quality issue. It’s billing for service not delivered.
Quality metrics are a routing input, not a report
The payoff for all of this is routing that responds to quality, not just price. Feed per-prefix quality scores into your LCR as a constraint: a route below baseline by some margin drops out of the eligible set regardless of cost. If you sell tiered products, this is how you keep premium traffic on routes that behave like premium; see our guide to reselling voice termination in tiers.
It’s also where CLI testing belongs. ASR and NER can tell you recipients aren’t answering. Only a test call tells you whether the number they saw was yours, which we cover in CLI versus non-CLI routes.
For destinations where metrics behave strangely for reasons nobody can see in CDRs, such as regulatory blocking of certain caller IDs, see our country playbook guide. And sudden traffic spikes to unusual prefixes paired with odd duration patterns can indicate fraud rather than quality problems; our SIP trunking security guide covers that side. Our guide to how voice termination works end to end connects the rest.
Frequently asked questions
What is ASR in voice termination?
ASR, or answer-seizure ratio, is the share of call attempts sent to a route that were answered. It reflects both network performance and recipient behavior, so it should be read alongside NER to tell the two apart.
What is the difference between ASR and NER?
ASR counts only answered calls as successes, while NER also counts calls where the network reached the recipient but they were busy, didn’t answer or rejected the call. A drop in ASR with stable NER usually means recipients aren’t answering, not that the route is failing.
How is ACD calculated?
ACD, or average call duration, is total billable seconds of answered calls divided by the number of answered calls. A sudden drop on one route can indicate audio problems or false answer supervision.
What is a good PDD for voice calls?
There’s no single good value, because PDD varies by destination and route type. Compare a route’s median and 90th-percentile PDD with other routes to the same destination and with its own history.
What is false answer supervision?
False answer supervision is when a route signals that a call was answered although no person picked up, which makes the call billable. It typically shows up as unusually high ASR, many calls lasting a few seconds and answers arriving faster than a phone could ring.
Request a rate deck
Evaluating routes for your LCR? Request an IDT Express rate deck for the destinations you’re benchmarking.
