A scalable SIP stack for outbound AMD

High-throughput outbound calling is not one scaling problem. SIP signaling, media processing and answering-machine detection put different demands on a system. Put them in one tightly coupled service and a surge in one workload can complicate operations across the rest.

A practical design separates those jobs: Kamailio handles SIP routing and load distribution; a pool of FreeSWITCH servers handles call media; and AMDY.IO classifies answer audio through its WebSocket API. This is a stack pattern, not a turnkey integration. The API supports custom predictive dialer integrations, so the connector between FreeSWITCH media and the API—and the logic that acts on a result—needs to be implemented and tested for the deployment.

Keep signaling and media distinct

In this layout, the outbound dialer sends SIP calls through Kamailio. Kamailio directs new call attempts to an available FreeSWITCH node. FreeSWITCH establishes and handles the media session. The dialer or an integration service also needs to associate each call with its audio classification request, then use the resulting classification in its call flow.

That separation matters. Kamailio balances SIP signaling; it should not be treated as the component that analyzes the audio. FreeSWITCH is the media-handling layer; it does not need to own the predictive dialer’s business rules. AMDY.IO provides AI answering machine detection for FreeSWITCH and a WebSocket API for custom dialers. Its audio fingerprint analysis starts within 1/8 of a second, but that figure is not an end-to-end guarantee for a complete call flow. Network transit, media capture, integration code and dialer action all affect the time an agent waits.

For background on the media-side trade-offs, see the comparison of native FreeSWITCH detection and streamed audio detection. The important engineering question is not just how quickly a classifier returns a result. It is whether the whole path delivers the result in time for the dialer to act usefully.

Build the call path in stages

1. Place Kamailio in front of the media pool. Route new outbound SIP attempts to FreeSWITCH nodes according to the capacity and health signals available in your environment. Preserve consistent routing for in-progress dialogs; rebalancing an active call as if it were a new attempt can break the session. Define what the system does when a destination is unavailable rather than assuming every retry is safe.
2. Keep media ownership clear. FreeSWITCH handles the call audio. Decide where audio will be captured and how it will be sent to the AMDY.IO WebSocket API. The connector must follow the API’s documented audio and session requirements; do not assume a particular codec, framing method or FreeSWITCH module without verifying it.
3. Correlate calls and classification requests. Give each call and its detection request a reliable association in the integration. Set an operational timeout and decide what the dialer should do if a result is delayed, missing or unusable. That fallback is a policy choice, not something to leave implicit in the connector.
4. Map results to dialer actions. Use the classification outcome to apply the campaign’s human, machine and uncertain-call handling. Keep those actions in the dialer or orchestration layer where agent availability and campaign rules are known. Test each branch with representative calls before allowing it to affect live routing.
5. Handle false answer supervision separately. AMDY.IO flags carrier false answers in the SIP path. Track that signal as distinct from an audio-based human-or-machine classification: a carrier can report an answer without a person or recording at the called end. Define how the dialer records and handles that condition, and confirm the signal’s integration semantics before relying on it operationally.

Scale by measuring each layer

Do not size this stack from a single calls-per-second target. Measure SIP attempts and failures at the routing layer, concurrent media sessions and resource use on each FreeSWITCH node, and the number and duration of active classification requests. Load-test the complete call path, including bursts and slow or unavailable dependencies. Capacity needs depend on the dial pattern, media configuration, hardware and integration behavior; there is no universal node count.

More nodes can add headroom, but they also add coordination work. Teams must maintain compatible configuration, monitor several queues and logs, and decide how calls behave when the API, a media node or the routing layer is impaired. A timeout policy that protects agent availability may classify fewer calls; waiting longer may delay an agent handoff. Measure that trade-off against the dialer’s pacing behavior. The effect of AMD latency on agent wait times is relevant when setting those limits.

Roll out without hiding failures

Start with a limited call volume and compare detection outcomes, response time and call handling against the existing process. Log call identifiers across Kamailio, FreeSWITCH, the integration and the dialer so an operator can trace a delayed or misrouted call. Include carrier false-answer events in that review rather than counting them as ordinary AMD decisions.

The payoff of this architecture is control over independent scaling boundaries, not automatic simplicity. Kamailio can distribute signaling, FreeSWITCH can provide a media tier, and AMDY.IO can classify audio through its WebSocket API. The hard work is stitching those layers together with clear ownership, measured limits and deliberate failure behavior.