A carrier-routing stack that treats FAS as evidence, not a verdict

A carrier sends an answer signal, the dialer treats the call as connected, and no person or voicemail is actually there. That is the operational problem behind false answer supervision (FAS): it can waste agent time and distort the apparent performance of an outbound route.

A practical response is to separate call routing from call classification. Use OpenSIPS to select among carrier routes, Asterisk to handle the call and media, and AMDY.IO to analyze answered audio and flag FAS. The important caveat: detection is not the same as carrier management. Do not assume AMDY.IO automatically changes OpenSIPS routing. Build an explicit policy layer that evaluates evidence and applies route changes.

Give each system one job

In this pattern, OpenSIPS sits in the outbound signaling path and chooses a carrier according to your routing policy. Asterisk handles call control and media. AMDY.IO provides answering machine detection for Asterisk and other dialers, integrating through a native installer or WebSocket API. It analyzes audio in real time to distinguish human responses from voicemail and flags carrier FAS.

Keep the boundaries clear. OpenSIPS makes the route decision; Asterisk provides the call context; AMDY.IO supplies classification evidence. A small controller or existing operations service can combine that evidence with call records and instruct your routing layer to quarantine a trunk. The exact integration and data flow depend on your deployment; confirm what identifiers and events are available before designing automation.

Build the evidence chain first

1. Assign a shared call identifier. Carry a stable identifier through the dialer, Asterisk records, AMDY.IO requests or results, and the OpenSIPS decision logs. If a shared ID is not practical, define a reliable matching key and document its limits.
2. Record the route actually used. Save the selected trunk, timestamps, SIP response details and call outcome. A route decision log is not proof the carrier delivered the call as intended, but it lets you compare the decision with what followed.
3. Collect AMDY.IO flags alongside outcomes. Use the supported integration path that fits your system. Do not assume a particular callback format or built-in connection to OpenSIPS; validate the interface and build any required adapter.
4. Review samples before automating. Compare flagged calls with SIP traces and call records. A single answer signal or an empty audio interval does not, by itself, establish carrier fault. The distinctions matter; the earlier guide on separating FAS flags from call-record and SIP-trace evidence is useful background.

Turn repeated evidence into a routing action

Start with a monitor-only period. Group calls by carrier trunk and look for a recurring pattern: AMDY.IO FAS flags, a corresponding answer in the signaling record, and no expected human or voicemail outcome. Review the pattern by destination and time window as well. A routing problem affecting one destination is not automatically a carrier-wide problem.

Then define a local threshold for action. There is no universal count or percentage that proves a trunk is faulty; the right threshold depends on traffic volume, the cost of a false alarm and how much redundancy you have. Require more than one signal, set a minimum sample size, and exclude incomplete or unmatched records. When the policy is met, have your controller mark the trunk unavailable in the routing policy OpenSIPS uses.

Make the change reversible. Use a hold-down period, alert the operations team, and test the route with a controlled sample before restoring normal traffic. Keep a manual override. If the controller cannot verify that a change was applied, it should raise an alert rather than silently reporting the trunk as quarantined.

Measure the trade-offs

Track FAS flags by trunk alongside answered-call outcomes, agent-connected calls and route volume. Also track how often the policy quarantines a carrier and how often a human review reverses that decision. Those measures expose both missed problems and overreaction. Review them separately from voicemail classification: a machine answer is not, on its own, evidence of FAS.

The benefit of this design is controlled routing based on call-level evidence, rather than blanket trust in an answer signal or a single noisy metric. The cost is engineering and operations work: identity matching, event handling, policy tuning and recovery procedures. AMDY.IO contributes real-time audio analysis and FAS flags; OpenSIPS and Asterisk remain separate components that your team must connect and operate.

For a first deployment, keep automatic quarantine disabled until the evidence chain survives real traffic and manual review. Then automate only the narrow action you can verify: removing a repeatedly suspect trunk from new routing decisions, with a clear path to investigate and restore it.