Debugging ASR and ACD drops on VOS3000: a step-by-step guide

Every NOC engineer knows the feeling: the dashboard turns amber, the ASR on a busy destination has fallen from its usual level, ACD is sliding too, and customers are starting to open tickets. The pressure is to “just change the route”. Sometimes that is the right answer, but often the real cause sits somewhere else — in a customer’s traffic, a number-format change, a capacity limit or a vendor problem that will follow you to the next route as well. This guide sets out a structured way to debug ASR and ACD drops on a VOS3000 softswitch, so you fix the cause instead of the symptom.

A quick refresher on ASR and ACD

ASR (Answer-Seizure Ratio) is the share of call attempts that are answered. ACD (Average Call Duration) is the average length of answered calls. Together they describe whether calls connect and whether people stay on them.

ASR = answered calls ÷ total attempts × 100  ·  ACD = total billed minutes ÷ answered calls

Both depend heavily on the destination and the traffic type, so there is no universal “good” value. What matters is the change against each route’s own baseline. If you need the full definitions, along with NER, PDD and MOS, see Lesson 6: route quality KPIs or the shorter blog guide on how to check VoIP route quality.

Step 1: confirm the drop is real

Before changing anything, make sure the numbers mean what you think they mean:

• Sample size. An ASR calculated from 40 attempts can swing wildly. Look at a window with enough calls to be meaningful.
• Time of day. Compare with the same hour on previous days, not with the daily average. Night traffic often has lower ASR.
• Short calls and repeated attempts. If one customer redials failed numbers aggressively, attempts rise and ASR falls even though the route is unchanged.
• Reporting delays. Make sure CDRs for the window are complete before drawing conclusions.

If the drop survives these checks, move on to finding where it lives.

Step 2: slice the traffic

A drop in a total is almost always concentrated in one slice. In VOS3000, the CDR and report views let you filter and group traffic; work through the dimensions one at a time:

Write down what you find at each step. A ticket that says “ASR on Country Z mobile via Vendor X fell from its baseline at 14:20, all customers affected, 503 responses up sharply” gets resolved far faster than “ASR is bad”.

Step 3: read the failure codes

When attempts fail, the SIP response and Q.850 cause tell you why. Group failed calls by code for the affected slice and compare with a normal period:

• Rise in 503 / 502 / 500: the vendor or a downstream carrier is rejecting traffic — often capacity or an outage. Failover to the next routing gateway is usually right.
• Rise in 404 / 484 (not found / address incomplete): number format problems. Check prefixes, tech prefixes and normalisation rules; see Lesson 13 on E.164 and dial plans.
• Rise in 403 (forbidden): the vendor is refusing the traffic — IP not authorised, account suspended, balance exhausted or CLI rejected.
• Rise in 480 / 486 / 408 (unavailable / busy / timeout): often genuine user behaviour, but a sudden jump can mean a vendor is cutting calls early or that the traffic mix changed.
• Calls failing on your side before reaching a vendor: no available route, rate missing, customer limit reached or balance exhausted. These show in your own CDRs with internal causes.

The SIP response codes reference lesson has a full table, including which codes should trigger failover and which should stop routing.

Step 4: check the switch itself

Some drops are self-inflicted. Look at the switch before blaming vendors:

1. Recent changes. Check the change log for new rate groups, edited prefixes, routing order changes or gateway edits around the start time.
2. Capacity limits. Has a routing gateway hit its concurrent-call limit, sending overflow to a weaker backup route?
3. Routing order and prefixes. Confirm the expected vendor is actually being selected for the affected prefix. A more specific prefix added for another purpose can quietly steal traffic. The VOS3000 accounts and routing gateways lesson explains how prefix matching and priority interact.
4. Rate coverage. A rate deck update that removed a prefix can cause calls to fail with no route.
5. Server health. High CPU, a full disk or database slowness can increase PDD and cause timeouts. The VOS3000 architecture lesson explains which components affect call handling.

Step 5: understand ACD-only drops

If ASR is stable but ACD falls, the calls connect but end sooner. Typical causes:

• Audio problems. One-way audio or poor quality makes people hang up quickly. Check MOS, packet loss and jitter for the slice, and look for NAT or codec issues as described in Lesson 9: troubleshooting common VoIP issues.
• Calls cut at a fixed duration. If many calls end at the same length, something in the path has a timer: a session timer mismatch, a vendor duration limit or a re-INVITE that fails.
• Traffic mix change. A customer that starts sending short-duration traffic will lower ACD with nothing wrong on the route.
• Answer-supervision anomalies. If both ASR and ACD look unusually high after a vendor change, or many very short “answered” calls appear, consider False Answer Supervision.

Step 6: test, don’t guess

Once you have a hypothesis, test it directly:

• Place test calls to known handsets in the affected range through the suspected route and through an alternative.
• Capture SIP traces for a handful of failed calls; the ladder diagram usually shows exactly where the call failed.
• Compare the number you sent with what the vendor received, including any prefix your switch added.

Lesson 8: route testing methods explains when to use test calls, passive monitoring and recording review, and how to combine them.

Step 7: act, then verify

Choose the smallest change that addresses the cause:

• Vendor issue: lower the vendor’s priority or remove it for the affected prefix, raise a ticket with evidence, and keep an eye on the backup route’s capacity.
• Customer issue: contact the customer with specific examples (time, B-number range, codes). Do not reroute healthy traffic for one customer’s problem.
• Configuration issue: revert or correct the change, and note it in the change log.

Then watch the same slice for long enough to be sure ASR and ACD have returned to baseline. Close the ticket with a short note on cause and fix — it will save time the next time the pattern appears.

Worked example

At 14:20, ASR to a mobile range in “Country Z” drops sharply. Slicing shows the drop is limited to one routing gateway, “Vendor X” (signalling address 192.0.2.40), and affects all customers. Failure codes show a jump in 503 Service Unavailable. The switch change log is empty for the period and the gateway is not at its channel limit. Test calls through Vendor X fail with 503; through the backup vendor they connect.

The engineer moves Vendor X below the backup for that prefix, confirms the backup has enough capacity, opens a ticket with the vendor including timestamps and sample Call-IDs, and sets a reminder to re-test in an hour. ASR returns to baseline within fifteen minutes. The vendor later confirms a downstream outage.

In a different case, the same drop pattern is limited to one customer across all vendors, with a spike in 404. The cause turns out to be the customer sending numbers with an extra leading zero after a change on their side; a short message to them fixes it without touching routing at all.

Prevention: make the next drop easier

• Keep per-route baselines by hour of day, so alerts compare like with like.
• Alert on disconnect-code mix, not just ASR.
• Keep a change log for every routing, rate and gateway edit.
• Keep enough backup capacity on secondary vendors for your busiest prefixes.
• Build a routine: the daily NOC routine lesson gives a practical shift checklist.

How VoxComms can help

VoxInspector monitors ASR, ACD, PDD and MOS per vendor, customer and destination on VOS3000, highlights changes against baseline, and keeps SIP ladder traces for failed calls, so the slicing in this guide takes seconds instead of an hour. For routes, VoxComms provides wholesale termination with a NOC that tests before and after every change. Contact our sales team to discuss a destination.