A practical multi-carrier stack for FAS detection and trunk isolation

A carrier can send a SIP 200 OK before the called party answers. The dialer sees a connected call; the customer may hear dead air, an intercept tone or nothing at all. That is the practical problem behind false answer supervision (FAS), and a SIP trace by itself cannot establish what happened on the audio path.

A useful multi-carrier outbound stack separates three jobs: the SIP proxy selects a carrier, a media-capable call handler makes audio available for analysis, and a routing policy decides what to do with repeated evidence. AMDY.IO can contribute the audio-classification signal. It provides answering machine detection for Asterisk and FreeSWITCH, and says its machine-learning audio fingerprint analysis and Call Progress Detection can flag carrier false-answers. Its WebSocket API is an integration option for dialers; do not assume it is a generic webhook endpoint for a SIP proxy.

Put each component where it can do its job

Use Kamailio or OpenSIPS as the SIP routing layer in a multi-carrier outbound stack. The proxy chooses an egress trunk and records which carrier handled each attempt. Keep Asterisk or FreeSWITCH in the call path when audio analysis is required. A signaling proxy can observe SIP messages, but it cannot classify call audio that never reaches a media-handling component.

Connect AMDY.IO through a supported path for the call handler or dialer in use: the product lists native integration for Asterisk and FreeSWITCH, as well as a WebSocket API for other dialers. Its site says detection starts in one-eighth of a second and claims 99% AMD accuracy. Treat those as vendor claims, not a guarantee that every carrier or every FAS pattern will be classified correctly. Confirm the integration’s event format, identifiers and timing in the current documentation before designing automation around it.

For background on why audio and signaling can tell different stories, see the distinctions between dead air, fake ringback and early media. They are useful diagnostic clues, not interchangeable proof of carrier fault.

Build a cautious event-to-route loop

1. Assign a stable call identifier. Carry the identifier, selected trunk, destination, timestamp and call outcome through the proxy, call handler and detection adapter. If those records cannot be joined reliably, pause before automating route changes.
2. Receive and normalize the detection result. Have an adapter consume the supported AMDY.IO integration output and map it to an internal event. Verify which results indicate a carrier false-answer, and distinguish them from human, machine and uncertain audio classifications. Do not invent a webhook contract where the integration is WebSocket-based.
3. Compare independent evidence. Keep the SIP response and timing alongside the audio result. A premature answer signal plus an audio pattern consistent with a false answer is stronger evidence than either alone. Preserve uncertain cases for review rather than counting them as confirmed FAS.
4. Apply a threshold per trunk. Track rates over a defined call count or time window, segmented by carrier and, where useful, destination class. Set a threshold with your own traffic and tolerance for false alarms. A single bad call should raise a record, not take a trunk out of service.
5. Change routes for future attempts. When the policy confirms a pattern, mark that trunk as degraded or remove it from new-call selection through the proxy’s routing controls. Keep an alternate carrier available and log the decision. Do not treat a detected FAS call as a transparent mid-call reroute: after answer supervision, ending and retrying can create a second attempt, duplicate contact or billing and compliance risk.
6. Review and restore deliberately. Alert an operator, retain the evidence and define how the trunk returns to service. A short test window or manual approval can prevent a temporary carrier fault—or a classifier mistake—from causing routing flaps.

Where the trade-offs show up

This design adds an adapter, correlation logic and a policy layer. It also depends on media access: if calls bypass Asterisk or FreeSWITCH and flow directly between endpoints, the analysis path may not see what it needs. Check the call topology before blaming the detector.

There is also a boundary between detection and routing. AMDY.IO’s known integration options do not establish a direct Kamailio or OpenSIPS control integration. The proxy’s route updates and the adapter’s event handling are implementation work for your team. Keep them loosely coupled: the adapter publishes normalized evidence, while a separate policy decides whether a trunk should be isolated.

Start in observation mode. Compare proxy records, call-handler audio outcomes and carrier reports before enabling automated quarantine. Then enable a conservative threshold for one trunk group and watch both the suspect rate and the share of calls routed elsewhere. The point of kamailio FAS detection or OpenSIPS FAS rerouting is not to make every odd answer disappear. It is to identify a repeatable carrier-specific failure, contain its impact on new calls and leave a clear trail for verification.