SIP et IA téléphonique
Entre le numéro appelé et le modèle vocal, la téléphonie doit établir la session, transporter l’audio et conserver assez d’état pour transférer ou terminer proprement l’appel.
1. Ce que SIP fait — et ne fait pas
SIP est un protocole de signalisation. Il sert à créer, modifier et terminer une session. Dans un appel classique, on retrouve un enchaînement comme INVITE → réponses provisoires → 200 OK → ACK, puis BYE à la fin de l’appel.
Le média audio n’est pas transporté par SIP lui-même. Il circule généralement via RTP ou via une couche média abstraite par le fournisseur téléphonique. Un appel peut donc être correctement établi côté SIP tout en ayant un problème audio à cause d’un NAT, d’un mauvais SDP ou d’un port RTP bloqué.
2. Numéro, opérateur et trunk
Trois montages sont fréquents : le prestataire fournit un numéro, l’entreprise porte son numéro vers le prestataire, ou elle conserve son opérateur et renvoie les appels vers la plateforme IA.
Avec un trunk SIP, l’opérateur livre les appels vers une URI SIP. Côté Twilio Elastic SIP Trunking par exemple, l’origination envoie les appels entrants du PSTN vers une URI SIP configurée ; la terminaison fait le chemin inverse pour appeler le réseau téléphonique.
Le design doit aussi prévoir l’authentification du trunk, les ACL IP, TLS pour la signalisation et éventuellement SRTP pour le média. Les problèmes de one-way audio sont souvent liés à des erreurs de NAT, de SDP ou de routage RTP.
3. Un flux d’appel concret
Exemple minimal : un client appelle le numéro → l’opérateur reçoit l’appel → le trunk envoie un INVITE vers la plateforme → la plateforme choisit l’agent vocal → l’audio est ouvert → l’agent dialogue → un outil métier peut être appelé → l’appel est transféré ou terminé.
À chaque étape, il faut conserver un identifiant de session. Sans corrélation stable entre l’appel téléphonique, la session IA et les événements métier, il devient difficile de reconstruire l’historique en cas d’incident.
Stack type : PSTN → opérateur/Twilio → SIP trunk → service d’orchestration Node/TypeScript → moteur temps réel vocal → CRM / agenda → logs et métriques.
4. Routage, transfert et résilience
Le routage peut dépendre du numéro appelé, de l’heure, du pays, d’une file métier ou d’un identifiant transmis dans les headers SIP. Un même trunk peut donc alimenter plusieurs agents ou scénarios.
La production doit gérer les appels simultanés, les timeouts, les réponses 4xx/5xx, les destinations de transfert indisponibles et le failover. Certains trunks permettent plusieurs URI d’origination avec priorité et poids pour répartir ou reprendre le trafic.
Un bon test SIP ne consiste pas seulement à vérifier qu’un appel décroche. Il faut aussi tester les pannes : destination SIP indisponible, appel interrompu, transfert refusé, RTP absent, caller ID mal formé ou trunk secondaire activé.