Asterisk AGI ou ARI : quelle interface choisir pour votre application téléphonique ?

Asterisk AGI ou ARI : c’est souvent la première décision d’architecture d’un projet téléphonique sur Asterisk. Les deux interfaces permettent de piloter des appels depuis votre propre code, mais avec des modèles très différents. AGI (Asterisk Gateway Interface) exécute un script en série dans le dialplan. ARI (Asterisk REST Interface), introduite avec Asterisk 12, expose les canaux, les ponts et les médias comme des ressources que votre application contrôle de façon asynchrone.

Cet article compare les deux en profondeur et propose des critères concrets pour choisir.

AGI en bref

AGI est la plus ancienne des deux interfaces. Le dialplan appelle l’application AGI(), qui lance un script (ou se connecte à un serveur distant avec FastAGI). Le script dialogue avec Asterisk via des commandes texte sur l’entrée et la sortie standard (ou sur un socket TCP pour FastAGI) : ANSWER, STREAM FILE, GET DATA, SET VARIABLE, EXEC, etc.

Caractéristiques clés :

• Modèle séquentiel et synchrone : une commande, une réponse. Le script contrôle l’appel tant qu’il tourne, puis rend la main au dialplan.
• Un appel, un contexte : chaque exécution est liée à un canal.
• Intégration naturelle au dialplan : on garde la logique d’acheminement dans extensions.conf et on délègue des étapes précises au script (consultation de base de données, validation d’un numéro, routage dynamique).
• Variantes : FastAGI (script hébergé sur un serveur distant, évite de lancer un processus par appel), EAGI (accès à l’audio entrant), AsyncAGI (pilotage via AMI).

Pour plus de détails, voyez notre page d’expertise Asterisk AGI.

ARI en bref

ARI inverse le modèle. Le dialplan envoie l’appel dans l’application Stasis(), et à partir de là, c’est votre application qui décide de tout. Elle reçoit les événements en temps réel par WebSocket (canal entré, touche DTMF, lecture terminée, raccroché) et agit via une API REST : répondre, jouer un son, enregistrer, créer un pont, ajouter ou retirer des canaux, lancer un appel sortant.

Caractéristiques clés :

• Modèle asynchrone et événementiel : votre application réagit aux événements et peut gérer de nombreux appels simultanément.
• Primitives de bas niveau : canaux, ponts (bridges), lectures (playbacks), enregistrements, points de terminaison. Vous composez vous-même le comportement.
• Plusieurs canaux dans une même logique : conférences, transferts assistés, rappels, mise en relation de deux appels deviennent naturels.
• Médias externes : les versions récentes d’Asterisk permettent d’acheminer l’audio d’un canal vers un service externe, ce qui facilite le branchement de moteurs de reconnaissance vocale et de voicebots.

Notre page Asterisk ARI approfondit ces usages.

Tableau comparatif AGI vs ARI

Modèle d’exécution : la vraie différence

La différence fondamentale tient en une phrase : avec AGI, vous ajoutez du code au dialplan ; avec ARI, le dialplan passe la main à votre code.

Avec AGI, votre script s’exécute dans le fil de l’appel. Pendant qu’il attend une réponse d’une API, l’appel attend aussi. C’est simple à raisonner, mais il faut surveiller les temps de réponse et les délais d’expiration. Lancer un processus par appel (AGI classique) a un coût ; FastAGI règle ce problème en maintenant un serveur permanent.

Avec ARI, votre application est un service à part entière, souvent écrit en Node.js, Python, Go ou Java. Elle maintient l’état de chaque appel, réagit aux événements et peut agir à tout moment, par exemple interrompre une lecture dès qu’une touche est pressée ou qu’une parole est détectée. Cette liberté implique plus de responsabilités : gestion d’état, reprise après déconnexion du WebSocket, nettoyage des ressources.

Médias et IA vocale

Pour un voicebot, l’accès à l’audio est déterminant :

• AGI/EAGI donne accès au flux entrant, mais la gestion conversationnelle (écouter et parler en même temps, interruptions) devient vite acrobatique.
• ARI permet de construire des architectures plus propres : un canal de médias externes envoie l’audio vers votre pipeline STT, la réponse TTS est jouée sur le canal, et l’application gère le barge-in en arrêtant la lecture dès que l’appelant parle.

Si votre feuille de route inclut un voicebot ou de l’analyse en temps réel, ARI est généralement le bon socle. Notre article sur le fonctionnement d’un voicebot décrit ce pipeline en détail.

Montée en charge et haute disponibilité

• AGI : FastAGI se répartit facilement derrière plusieurs serveurs applicatifs. Le dialplan reste la source de vérité, ce qui simplifie la reprise en cas de panne d’un serveur applicatif (on peut prévoir un chemin de repli dans le dialplan).
• ARI : l’application doit être conçue pour la résilience. Si elle perd sa connexion, les appels en Stasis peuvent rester bloqués. Il faut prévoir la reconnexion, la supervision et une stratégie claire pour les appels orphelins. Plusieurs instances Asterisk peuvent être pilotées, mais la répartition et l’affinité doivent être pensées dès la conception.

Critères de choix

Choisissez AGI si :

• votre logique est essentiellement séquentielle (menu, saisie, consultation, routage) ;
• vous avez un dialplan existant riche que vous voulez conserver ;
• votre équipe est plus à l’aise avec des scripts qu’avec des services asynchrones ;
• vous ajoutez une fonction ponctuelle à un système stable.

Choisissez ARI si :

• vous construisez une application téléphonique complète (voicebot, centre de contact, conférence) ;
• vous devez coordonner plusieurs canaux ou ponts ;
• vous avez besoin d’un contrôle fin des médias et des interruptions ;
• vous voulez exposer la téléphonie comme un service piloté par API, dans une logique d’orchestration téléphonique.

Combinez les deux si :

• vous migrez progressivement un existant AGI vers ARI ;
• certaines fonctions simples restent en AGI, tandis que les nouveaux parcours sont construits en ARI.

Pièges fréquents

• AGI bloquant : un appel HTTP sans délai d’expiration peut figer l’appel. Toujours borner les temps d’attente.
• Processus par appel : en AGI classique, un pic d’appels peut saturer le serveur. Préférer FastAGI en production.
• Ressources ARI non libérées : ponts, enregistrements ou canaux oubliés s’accumulent. Prévoir un nettoyage systématique.
• État applicatif non persistant : en ARI, un redémarrage de l’application ne doit pas perdre le suivi des appels en cours.
• Sécurité : ARI et AMI ne doivent jamais être exposés sans authentification forte et filtrage réseau.

Migrer d’AGI vers ARI

Si vous exploitez déjà AGI en production, inutile de tout réécrire. Une démarche pragmatique :

1. Inventorier les scripts AGI et les contextes du dialplan qui les appellent.
2. Choisir un parcours autonome (demande de rappel, consultation puis routage) et le reconstruire en application ARI.
3. Acheminer un numéro de test vers Stasis() pour ce parcours, le reste demeurant en AGI.
4. Superviser l’application ARI : état de la connexion WebSocket, canaux actifs, taux d’erreur.
5. Étendre parcours par parcours, en conservant un repli dans le dialplan vers la version AGI jusqu’à ce que chaque nouveau parcours soit stable.

Conclusion

AGI et ARI ne sont pas concurrents mais complémentaires. AGI reste efficace pour enrichir un dialplan avec une logique séquentielle. ARI est l’outil de référence pour construire des applications vocales modernes, en particulier avec de l’IA en temps réel. Le bon choix dépend de votre existant, de votre feuille de route et des compétences de votre équipe.