A ViciDial stack for streaming AMD audio without crowding Asterisk

External audio streaming can give a ViciDial deployment another route to answering machine detection, but it adds a media path that has to work alongside call control and carrier trunks. The practical aim is not to move every dialer function out of Asterisk. It is to avoid making Asterisk do extra, unbounded media work for each live call.

AMDY.IO provides answering machine detection for outbound dialers, with native ViciDial and Asterisk integrations or a WebSocket API. It detects machines, live humans and carrier false answers, and starts detection in 1/8 of a second. Those facts do not specify a particular AudioServer, RTP relay, WebSocket message format or ViciDial configuration. Treat the external streaming design below as an integration pattern to validate against the components and documentation in your own environment.

Separate the jobs

Keep ViciDial responsible for campaign and dialer behavior, and keep Asterisk responsible for the calls and trunk connections it already handles. If you use an external AudioServer daemon, place it on the media path as a separate service rather than adding more processing to the core Asterisk path. The daemon’s job is to receive the relevant answered-call audio and forward it through the agreed WebSocket interface.

There is an important boundary here: RTP and WebSocket are different transports. A WebSocket endpoint does not, by itself, consume an RTP stream. The deployment needs a supported media bridge or relay that can receive the audio, prepare it in the format expected by the AMD integration and manage the connection. Confirm those requirements before writing dialplan logic or deploying daemons. Do not assume a particular codec, packet format or API message schema.

For background on starting analysis when an answered channel becomes available, see this paper’s guide to routing Asterisk audio for AMD at answer. The operational point is simple: establish the media path at the right call stage, then make the dialer’s handling of the resulting classification explicit.

A cautious setup sequence

1. Map the call path first. Record where each carrier trunk enters, which Asterisk system handles the call, and where the answered audio can be accessed. Identify whether the planned external feed is a copy or a redirected media path. The distinction matters: a relay failure should not silently disrupt the customer call unless that is an intentional design choice.
2. Check the interfaces. Confirm the media relay’s supported input and output, the WebSocket API’s expected audio and response handling, and how a verdict is returned to the dialer. AMDY.IO supports a WebSocket API, but the exact connection and payload details are implementation questions; use the current API documentation rather than inventing settings or framing.
3. Keep the daemon isolated. Run the AudioServer process separately from the core Asterisk service where the operating environment permits. Set resource limits and supervision using your normal production practices. Monitor the relay and Asterisk independently so a stalled stream or exhausted relay does not look like a carrier problem.
4. Start with a narrow traffic slice. Use a test campaign or a limited group of channels. Confirm that audio reaches the external service, that the classification returns to the correct call, and that the intended human, machine and carrier-false-answer outcomes produce the right dialer actions. Include calls from each trunk group; a successful test on one carrier is not proof that every trunk behaves the same way.
5. Increase concurrency in steps. Measure Asterisk load, relay CPU and memory, WebSocket connection stability, and the number of calls with missing or late results. Compare those results with the normal trunk and dialer load. If the relay becomes the bottleneck, adding channels will not fix the design. If Asterisk load rises sharply, check whether the media path is duplicating work or routing more audio than intended.

Trade-offs to keep visible

External streaming can isolate media analysis from core call handling, but it also adds a service, a network path and another failure mode. A relay outage, dropped WebSocket connection or mismatched call association can leave the dialer without a usable verdict. Decide in advance what the dialer should do when analysis is unavailable. Failing open and failing closed have different costs: one may send unanswered or recorded calls to agents, while the other may discard live responses.

There is also a reason not to build a custom path by default. AMDY.IO has native ViciDial and Asterisk integration, as well as compatibility with GoAutoDial, FreePBX, Issabel and 3CX. Start with a native integration when it fits the deployment. Use a custom external stream when the topology or control requirements justify the extra moving parts, not simply because WebSocket audio sounds more flexible.

Finally, judge the setup by measured calls rather than a single headline accuracy figure. Track human calls routed correctly, machines handled as intended, false-answer flags, missing verdicts and agent-facing delay. At high channel counts, a design is ready only when those outcomes remain stable under the real trunk mix and peak load.