Asterisk ARI development: full control of calls, bridges and media

Asterisk ARI (Asterisk REST Interface) turns Asterisk into a programmable media engine. Instead of describing a call flow in the dialplan, you hand calls to your own application, which receives events in real time and decides what to do with every channel, bridge, playback and recording. Since its introduction in Asterisk 12, ARI has become our preferred interface for AI voicebots and any call logic that goes beyond a linear menu. Voxivra’s engineers have worked with Asterisk since its early versions and have built ARI applications in production for conversational agents, smart routing and custom contact center features.

How Asterisk ARI works

ARI combines three pieces:

• A WebSocket on which Asterisk pushes JSON events for your application: StasisStart, ChannelDtmfReceived, PlaybackFinished, ChannelHangupRequest, StasisEnd and many more.
• A REST API over HTTP to act on resources: answer or hang up channels, originate calls, create bridges, start playbacks and recordings, set variables, move channels between bridges.
• The Stasis() dialplan application, which hands a channel to a named application. Until the channel leaves Stasis, the dialplan does not touch it.

A minimal dialplan entry point looks like this:

[inbound-ai]
exten => _X.,1,NoOp(Handing call to ARI)
 same => n,Stasis(voice-agent,${EXTEN})
 same => n,Hangup()

The application connects to /ari/events?app=voice-agent over WebSocket (authenticated with an ARI user defined in ari.conf, over the HTTP server configured in http.conf). When the StasisStart event arrives, it answers the channel and takes over.

Because ARI is asynchronous and event-driven, one application can manage many calls at once, react to several events per call and coordinate multiple channels, which AGI’s blocking, one-script-per-call model does not allow.

Streaming audio to AI with ExternalMedia

For voicebots, the key ARI feature is ExternalMedia. It creates a special channel that sends the audio it receives to an external host, and plays back the audio that host sends in return. The usual pattern:

1. The caller’s channel enters the Stasis application.
2. The application creates a mixing bridge and an ExternalMedia channel pointing to a media gateway, for example with POST /ari/channels/externalMedia?app=voice-agent&external_host=10.0.20.5:40000&format=slin16.
3. Both channels are added to the bridge (POST /ari/bridges/{bridgeId}/addChannel).
4. The media gateway receives the caller’s audio as RTP, forwards it to a streaming speech-to-text engine, sends text to the dialogue layer (rules, NLU or an LLM) and streams synthesized speech back as RTP into the bridge.

The format parameter matters: telephony audio usually arrives as 8 kHz G.711, and choosing signed linear (slin or slin16) avoids extra decoding in the gateway. ExternalMedia with RTP over UDP is the most widely used option; depending on the Asterisk version, other encapsulations such as AudioSocket over TCP are also available. Our speech AI expertise covers what happens on the AI side.

Barge-in and turn-taking

Natural conversation requires the caller to interrupt the bot. With ARI, the application controls playbacks individually: when the speech engine detects that the caller has started talking, the application stops the current playback (DELETE /ari/playbacks/{playbackId}) or flushes the audio stream, then listens. Getting this right, without cutting off on background noise or echo, is one of the details that separates a usable voicebot from a frustrating one.

What we build with ARI

• AI voicebots and callbots with streaming STT, LLM or NLU dialogue and neural TTS, connected to your systems. See our AI voicebot service.
• Seamless human handoff: the bot hands over to an agent by moving the caller to a new bridge, with the context and transcript passed to the agent’s desktop.
• Custom queues and routing driven by your own data and rules, rather than the fixed behavior of the built-in queue application.
• Outbound campaigns and callbacks originated through the API, with answering machine handling and retry logic.
• Recording and real-time analytics using snoop channels and recordings for supervision or transcription.
• Orchestration layers that expose your telephony as clean APIs and webhooks for other teams, the core of our telephony orchestration work.

Production engineering for ARI

ARI gives you control, which also means your application is now responsible for every call. Our standard practices:

• Supervised services: the ARI application runs as a managed service that restarts automatically and reconnects its WebSocket. On reconnect, it reconciles state by listing channels and bridges still owned by the application.
• Fallbacks for orphan calls: timeouts in the application and dialplan, plus logic to continue channels back into the dialplan toward a queue or voicemail if the AI path fails.
• Separation of concerns: call control, media processing and business logic run as distinct components, so a slow STT provider does not block call control.
• Security: the ARI HTTP server listens only on private interfaces or behind TLS, with strong credentials and firewall rules. ARI is never exposed to the public internet. Our VoIP security practice covers the details.
• Load and soak testing with SIP traffic generators, and metrics on event latency, active channels and error rates.

When Voxivra recommends ARI

We recommend ARI when:

• you are building a conversational voicebot or any flow that needs real-time audio streaming;
• the application must manage several channels and bridges at once (transfers, conferences, supervised handoff);
• you want your telephony logic to live in a modern codebase, versioned and tested like the rest of your software;
• you need asynchronous behavior, such as reacting to external events during a call.

For simple data lookups inside an existing dialplan, Asterisk AGI is often faster to deliver and perfectly adequate. Our article Asterisk AGI vs ARI walks through the trade-offs with concrete examples. If you are weighing an ARI architecture for an AI project, tell us about your call flows and we will review the design with you.