A route can look healthy at 9:00 a.m. and become a revenue or quality problem by lunch. A rising failure count alone does not explain whether the issue is carrier availability, SIP signaling, a device state change, a destination pattern, or calls that technically answer but end immediately. ASR ACD call reporting gives operations teams the context to separate those conditions before they make a routing decision.
For VoIP providers, operators, and teams managing distributed mobile SIP gateways, ASR and ACD are basic KPIs. They are also easy to misread. The value comes from calculating them consistently, filtering them correctly, and placing them beside CDR disposition data, trunk status, device telemetry, and time-based trends.
What ASR and ACD measure
ASR, or Answer-Seizure Ratio, measures the percentage of call attempts that reach an answered state. In a common reporting model, it is calculated as answered calls divided by total attempted calls, multiplied by 100. If a route receives 1,000 attempts and 620 calls answer, the ASR is 62%.
ACD, or Average Call Duration, measures the average connected duration for answered calls. If those 620 answered calls produce 18,600 seconds of billable or connected talk time, the ACD is 30 seconds. The formula is total answered-call duration divided by the number of answered calls.
Neither metric is meaningful without a definition of the underlying events. An attempted call may mean a SIP INVITE sent to a trunk, a call offered to a mobile-connected gateway, or a record created after a route-selection decision. An answered call may be defined by a SIP 200 OK, a media-connected event, or a billing answer timestamp. Those are not always identical.
The reporting policy should state exactly which event starts the clock, which final dispositions count as answered, and whether zero-second connected calls are included. Without that discipline, two dashboards can show different ASR and ACD values for the same traffic and both appear correct.
Why ASR ACD call reporting needs CDR detail
A single ASR number is a signal, not a diagnosis. The same is true of ACD. A route with low ASR might be constrained by capacity, rejecting a specific destination range, or receiving malformed SIP requests. A route with high ASR and low ACD may be connecting calls successfully while delivering poor destination quality, incorrect routing policy, or calls that users abandon immediately.
This is why ASR ACD call reporting should be built from detailed CDRs rather than treated as a stand-alone scorecard. Each report needs enough dimensions to isolate where behavior changes. At minimum, teams should be able to segment results by time interval, SIP trunk, route, gateway or device group, carrier or operator profile where applicable, destination prefix, account or customer profile, and final call disposition.
The operational question is rarely, “What is our ASR?” More often it is, “Which route changed, when did it change, and what did the failed calls have in common?” CDR-level reporting provides that path from KPI to evidence.
Read failure causes before changing routes
A falling ASR should first be grouped by final SIP response and internal failure state. Busy responses, no-answer events, registration failures, canceled calls, rejected requests, and network errors point to different owners and different corrective actions.
For example, a concentration of temporary service failures on one trunk may justify a capacity or carrier review. A pattern of canceled calls may indicate upstream caller behavior, dial-plan logic, or timeout settings rather than a gateway fault. Calls that fail before route assignment should not be blended into route-performance calculations, because doing so unfairly lowers that route's ASR.
A clean report preserves both views: end-to-end attempt performance for business monitoring, and route-attributed performance for routing analysis.
Treat short calls as a separate operating condition
Low ACD deserves the same discipline. Short answered calls are not automatically bad, especially for notification workflows, support callbacks, or destination sets with naturally brief interactions. But a sudden ACD drop on a previously stable route is worth investigation.
Review the duration distribution, not just the average. A 35-second ACD could represent mostly normal calls, or a mix of very short calls and several long calls masking a large failure pattern. Buckets such as 0-5 seconds, 6-30 seconds, 31-60 seconds, and over 60 seconds make the shift visible.
Then compare those buckets with disconnect direction and cause. If many calls end within five seconds after the remote party answers, inspect media path conditions, codec policy, audio continuity, and destination-side behavior. If the caller disconnects before media is established, signaling latency or caller abandonment may be more relevant.
Build reports around operational decisions
A useful reporting page does not force a NOC engineer to export raw records every time a threshold moves. It presents the main metric, its denominator, the comparison period, and the drill-down path in the same workflow.
Start with a live or near-real-time route view showing attempts, answered calls, ASR, total duration, ACD, active calls, and dominant failure causes. Add a baseline comparison, such as the prior hour, prior day at the same time, or a rolling seven-day reference. The appropriate baseline depends on the traffic pattern. A wholesale route with predictable daily peaks benefits from time-of-day comparison, while a newly provisioned route may need a shorter observation window.
For distributed gateway operations, correlate route performance with availability data. A decline in attempts or ASR can align with a device going offline, weak mobile signal, loss of SIP registration, depleted prepaid balance, or an exhausted concurrency limit. Reporting must show the distinction between a route that received traffic and failed it versus a route that was unavailable to receive calls.
GSMCalls brings call records, routing controls, gateway status, device monitoring, and account-level operational data into one workspace, which reduces the delay between identifying a KPI movement and checking the infrastructure state behind it.
Set thresholds that reflect traffic volume
An ASR change from 80% to 70% sounds serious, but the sample size matters. Ten attempts versus one hundred attempts is not a reliable basis for the same response. Small, low-volume destination groups can swing dramatically from a few calls, while a one-point decline on a high-volume trunk can affect a substantial number of calls.
Use thresholds with a minimum attempt count. An alert might require both an ASR below the expected range and enough attempts to make the result operationally credible. Apply similar logic to ACD. A low ACD on three answered calls is an observation; the same behavior across several hundred calls is a trend.
Thresholds should also vary by route purpose. A premium route used for longer business conversations should have a different ACD expectation from a route carrying short transactional calls. One global target can create false alarms and cause teams to ignore alerts that matter.
Keep the math auditable
Reporting disputes usually come down to numerator and denominator rules. Ensure the report exposes the counts behind each percentage and documents its filters. If ASR excludes calls canceled before a defined stage, show how many were excluded. If ACD uses billable duration rather than connected duration, label it precisely.
Time zone handling deserves the same attention. A reporting window that crosses midnight, a daylight-saving transition, or multiple operating regions can create apparent changes that are only aggregation errors. Store timestamps consistently, display the selected time zone clearly, and make scheduled reports use an explicit reporting boundary.
Duplicate CDRs and delayed final records also need controls. A call may generate interim states before its final disposition is available. If real-time dashboards include provisional records, label them as provisional and reconcile them after the call closes. Historical reports should use finalized CDRs so the numbers remain stable when finance, operations, and engineering review the same period.
A practical review sequence for NOC teams
When ASR or ACD moves outside its expected range, begin with scope. Confirm whether the change affects one route, a destination prefix, a trunk, a location, or the entire traffic set. Next, inspect attempts and answered-call volume so percentage movement is put in context.
Then review the leading outcomes in the CDRs and compare them with gateway and trunk status. Check registration state, active-call capacity, device availability, signal-related conditions where available, and recent routing or profile changes. Finally, compare the affected window with a relevant baseline before rerouting or escalating.
This sequence prevents a common mistake: moving traffic away from a route that was not actually at fault. A routing change can hide the original condition while creating congestion or cost exposure somewhere else.
The useful outcome of reporting is not a prettier dashboard. It is a faster, defensible decision: leave the route in service, adjust capacity, isolate a destination pattern, investigate signaling, or escalate with CDR evidence. When every ASR and ACD movement can be traced to call-level facts, operations teams spend less time debating the metric and more time protecting service quality.