Développement Asterisk ARI : le contrôle complet des appels, ponts et flux audio

Asterisk ARI (Asterisk REST Interface) fait d’Asterisk un moteur média programmable. Au lieu de décrire le parcours d’appel dans le dialplan, vous confiez les appels à votre propre application, qui reçoit les événements en temps réel et décide du sort de chaque canal, pont, diffusion et enregistrement. Depuis son introduction avec Asterisk 12, ARI est devenue notre interface de prédilection pour les voicebots IA et toute logique d’appel qui dépasse le simple menu linéaire. Les ingénieurs de Voxivra travaillent avec Asterisk depuis ses premières versions et ont mis en production des applications ARI pour des agents conversationnels, du routage intelligent et des fonctions de centre d’appels sur mesure.

Le fonctionnement d’Asterisk ARI

ARI repose sur trois éléments :

• Un WebSocket sur lequel Asterisk pousse des événements JSON vers votre application : StasisStart, ChannelDtmfReceived, PlaybackFinished, ChannelHangupRequest, StasisEnd et bien d’autres.
• Une API REST sur HTTP pour agir sur les ressources : répondre ou raccrocher, lancer des appels sortants, créer des ponts (bridges), démarrer diffusions et enregistrements, définir des variables, déplacer des canaux d’un pont à l’autre.
• L’application de dialplan Stasis(), qui confie un canal à une application nommée. Tant que le canal n’a pas quitté Stasis, le dialplan n’y touche plus.

Un point d’entrée minimal dans le dialplan ressemble à ceci :

[inbound-ai]
exten => _X.,1,NoOp(Transfert de l'appel vers ARI)
 same => n,Stasis(voice-agent,${EXTEN})
 same => n,Hangup()

L’application se connecte en WebSocket à /ari/events?app=voice-agent, avec un utilisateur ARI défini dans ari.conf, via le serveur HTTP configuré dans http.conf. À la réception de l’événement StasisStart, elle répond au canal et prend la main.

ARI étant asynchrone et événementielle, une seule application peut gérer de nombreux appels simultanés, réagir à plusieurs événements par appel et coordonner plusieurs canaux, ce que le modèle bloquant de l’AGI, un script par appel, ne permet pas.

Diffuser l’audio vers l’IA avec ExternalMedia

Pour les voicebots, la fonction clé d’ARI est ExternalMedia. Elle crée un canal spécial qui envoie l’audio reçu vers un hôte externe et diffuse dans l’appel l’audio que cet hôte renvoie. Le schéma habituel :

1. Le canal de l’appelant entre dans l’application Stasis.
2. L’application crée un pont de mixage et un canal ExternalMedia pointant vers une passerelle média, par exemple avec POST /ari/channels/externalMedia?app=voice-agent&external_host=10.0.20.5:40000&format=slin16.
3. Les deux canaux sont ajoutés au pont (POST /ari/bridges/{bridgeId}/addChannel).
4. La passerelle reçoit l’audio de l’appelant en RTP, le transmet à un moteur de reconnaissance vocale en continu, envoie le texte à la couche de dialogue (règles, NLU ou LLM) et renvoie la synthèse vocale en RTP dans le pont.

Le paramètre format compte : l’audio téléphonique arrive généralement en G.711 à 8 kHz, et choisir le linéaire signé (slin ou slin16) évite un décodage supplémentaire dans la passerelle. ExternalMedia en RTP sur UDP est l’option la plus répandue ; selon la version d’Asterisk, d’autres encapsulations comme AudioSocket sur TCP sont aussi disponibles. Notre expertise reconnaissance et synthèse vocales détaille la partie IA.

Interruption (barge-in) et prise de parole

Une conversation naturelle exige que l’appelant puisse interrompre le bot. Avec ARI, l’application contrôle chaque diffusion : dès que le moteur vocal détecte que l’appelant parle, elle arrête la diffusion en cours (DELETE /ari/playbacks/{playbackId}) ou vide le flux audio, puis écoute. Bien régler ce mécanisme, sans se déclencher sur un bruit de fond ou un écho, fait partie des détails qui distinguent un voicebot agréable d’un voicebot pénible.

Ce que nous réalisons avec ARI

• Voicebots et callbots IA avec reconnaissance vocale en continu, dialogue par LLM ou NLU et synthèse neuronale, reliés à vos systèmes. Voir notre service voicebot IA.
• Transfert fluide vers un humain : le bot passe la main à un agent en déplaçant l’appelant vers un nouveau pont, avec le contexte et la transcription affichés sur le poste de l’agent.
• Files d’attente et routage sur mesure pilotés par vos données et vos règles, plutôt que par le comportement figé de l’application Queue.
• Campagnes sortantes et rappels lancés par API, avec gestion des répondeurs et des nouvelles tentatives.
• Enregistrement et analyse en temps réel grâce aux canaux d’écoute (snoop) pour la supervision ou la transcription.
• Couches d’orchestration qui exposent votre téléphonie sous forme d’API et de webhooks propres, au cœur de notre travail d’orchestration téléphonique.

L’ingénierie de production pour ARI

ARI donne le contrôle, ce qui signifie aussi que votre application devient responsable de chaque appel. Nos pratiques standard :

• Services supervisés : l’application ARI tourne comme un service géré, redémarre automatiquement et rouvre son WebSocket. À la reconnexion, elle resynchronise son état en listant les canaux et ponts qui lui appartiennent encore.
• Replis pour les appels orphelins : délais d’expiration côté application et dialplan, et logique de retour (continue) vers le dialplan, une file d’attente ou une messagerie si le parcours IA échoue.
• Séparation des responsabilités : contrôle d’appel, traitement média et logique métier sont des composants distincts, pour qu’un fournisseur de reconnaissance vocale lent ne bloque pas le contrôle d’appel.
• Sécurité : le serveur HTTP d’ARI n’écoute que sur des interfaces privées ou derrière TLS, avec des identifiants robustes et des règles de pare-feu. ARI n’est jamais exposée sur Internet. Notre pratique en sécurité VoIP détaille ces mesures.
• Tests de charge et d’endurance avec des générateurs de trafic SIP, et métriques sur la latence des événements, les canaux actifs et les taux d’erreur.

Quand Voxivra recommande ARI

Nous recommandons ARI lorsque :

• vous construisez un voicebot conversationnel ou tout parcours qui exige un flux audio en temps réel ;
• l’application doit gérer plusieurs canaux et ponts à la fois (transferts, conférences, transfert supervisé) ;
• vous voulez que votre logique téléphonique vive dans un code moderne, versionné et testé comme le reste de vos logiciels ;
• vous avez besoin d’un comportement asynchrone, par exemple réagir à un événement externe pendant l’appel.

Pour de simples recherches de données dans un dialplan existant, Asterisk AGI est souvent plus rapide à livrer et tout à fait suffisante. Notre article Asterisk : AGI ou ARI ? détaille les compromis avec des exemples concrets. Si vous évaluez une architecture ARI pour un projet d’IA, décrivez-nous vos parcours d’appel et nous examinerons la conception avec vous.