SIP, RTP, WebRTC : brancher un callbot sans souffrir

SIP, RTP, SDP : le trio qui fait (presque) tout

Avant de parler IA, parlons plomberie. Parce que votre callbot peut être un génie… s’il n’entend personne, il est juste très silencieux.

SIP : la signalisation (le “qui / quand / comment”)

SIP (Session Initiation Protocol) gère l’établissement, la modification et la fin des sessions de communication : c’est le protocole qui dit “cet appel commence”, “on transfère”, “on raccroche”. La spécification de base est décrite dans RFC 3261.¹

RTP : le média (l’audio, en morceaux)

RTP (Real-time Transport Protocol) transporte l’audio (ou la vidéo) en temps réel sous forme de paquets. Il décrit notamment des mécanismes de timestamp, numérotation de séquence et gestion de jitter, essentiels pour reconstruire une voix fluide côté réception.²

SDP : la description (codecs, ports, directions)

SIP dit “on parle”, mais ne dit pas “avec quel codec” ni “sur quel port”.

C’est le rôle de SDP (Session Description Protocol). Historiquement décrit dans RFC 4566, puis obsolété par RFC 8866.³

En clair : SDP est la fiche technique de votre média.

WebRTC : quand la téléphonie rencontre le navigateur

WebRTC est souvent la voie royale quand l’audio vient du web (site, app) plutôt que du réseau téléphonique classique.

Ce qui change ?

• sécurité et chiffrement (DTLS-SRTP),
• NAT traversal (STUN/TURN),
• codecs typiques (Opus),
• intégration à des passerelles (Janus, mediasoup, etc.).

La sécurité WebRTC est décrite dans des RFCs dédiées, notamment l’architecture de sécurité (RFC 8827).⁴

Et si vous voulez un callbot “speech-to-speech” via WebRTC ou WebSocket, certaines stacks API proposent des connecteurs temps réel (ex. Realtime API).⁵

Trois patterns pour “attraper” l’audio d’un appel

Il existe 3 grands modèles d’intégration. Le bon choix dépend de votre contexte télécom, de vos volumes, et de votre appétit pour les ennuis (spoiler : tout le monde en a un, même quand il prétend le contraire).

Pattern 1 : SIP trunk (PSTN ↔ SIP) + SBC/PBX + callbot

Schéma mental :

PSTN → opérateur → SIP trunk → SBC/PBX → callbot (media) → IA (STT/LLM/TTS)

Ce pattern est classique en entreprise : vous avez déjà une infra SIP (ou vous la mettez), et vous connectez le callbot comme un “agent” dans votre plan de numérotation.

Outils courants :

• open source : Asterisk (chan_pjsip), FreeSWITCH, Kamailio (SIP routing), OpenSIPS,
• commerciaux : SBC (AudioCodes, Ribbon), opérateurs + trunks managés.

Pour Asterisk, la doc explique la logique du driver SIP moderne basé sur PJSIP (et ses implications).⁶

Pour Twilio (exemple cloud), Twilio documente son Elastic SIP Trunking et fournit des guides de configuration (dont Asterisk/FreePBX) pour l’interop, y compris des options de trunk sécurisé (SIP TLS + SRTP).⁷

Pattern 2 : “Media Streams” (audio via WebSocket) + serveur applicatif

Si votre objectif est d’envoyer l’audio vers un moteur STT en streaming, ce pattern est très pragmatique.

Twilio, par exemple, expose Media Streams pour streamer l’audio d’un appel vers votre serveur via WebSocket.⁸ Et la doc décrit les messages WebSocket échangés (format, événements, etc.).⁹

Avantages :

• intégration rapide,
• “point d’entrée” unique : votre serveur,
• facile de brancher STT + IA + analytics.

Inconvénients :

• vous devez être sérieux sur la latence (sinon l’expérience s’écroule),
• vous devez gérer la disponibilité de votre WebSocket infra,
• vous êtes responsable de la boucle temps réel.

Pattern 3 : WebRTC client (web/app) + gateway + callbot

Ici, l’utilisateur n’appelle pas un numéro. Il clique. (Parfois c’est un progrès.)

Vous utilisez WebRTC pour capter l’audio, puis :

• vous connectez directement à une API temps réel (si vous avez ce modèle),
• ou vous passez par une gateway WebRTC/SIP,
• ou vous branchez votre propre media server.

Les passerelles WebRTC (ex. Janus) documentent des plugins et intégrations, dont certains orientés SIP, afin de connecter deux mondes qui ne se comprennent pas toujours naturellement.¹⁰

Les “petites choses” qui cassent tout (et qui arrivent dès la première semaine)

NAT & firewall : le média n’arrive pas, mais SIP “a l’air OK”

Symptôme : l’appel se connecte, mais vous n’entendez rien.

Causes typiques :

• ports RTP bloqués,
• NAT mal géré,
• SDP incorrect (IP/port incohérents),
• SRTP/TLS négociation ratée.

Codecs : le callbot entend du bruit, ou parle comme un robot de 1997

Pour la téléphonie classique, G.711 est fréquent (8 kHz, simple). Pour WebRTC, Opus est central et standardisé (RFC 6716).¹¹

Ce que ça implique :

• STT doit être bon sur du 8 kHz (téléphonie),
• TTS doit être “coupable” : compréhensible, pas forcément hi-fi,
• la conversion (resampling) doit être maîtrisée (sinon latence + artefacts).

DTMF : “tapez 1” n’est pas mort (il est juste en embuscade)

Même avec un callbot, vous aurez des cas où DTMF est plus robuste :

• saisie de code,
• navigation fallback,
• IVR hybride.

Votre stack télécom doit gérer DTMF proprement, sinon vous perdez des appels en bout de chaîne.

Transfert et “warm handoff” : le callbot doit passer la main proprement

Le transfert est souvent l’instant de vérité.

Un transfert raté, c’est :

• un rappel (FCR en baisse),
• un agent qui redemande tout (AHT en hausse),
• un client qui vous déteste en silence (CSAT en chute libre).

La partie SIP gère des méthodes et mécanismes de transfert (ex. REFER, re-INVITE selon scénarios). Côté plateforme cloud, les docs décrivent souvent des primitives haut niveau pour transférer, enregistrer, ou manipuler l’appel (varie selon fournisseurs).⁷

Comment je recommande de concevoir l’intégration (simple et robuste)

1

Choisir un point d’entrée audio

SIP trunk (infra télécom), Media Streams (WebSocket), ou WebRTC (web/app). Le point d’entrée doit être stable et observable.

2

Définir vos contraintes de sécurité

TLS/SRTP (téléphonie), DTLS-SRTP (WebRTC), enregistrement et consentement. C’est ici que les choix d’architecture changent.

3

Standardiser l’audio en interne

Un format audio interne unique (échantillonnage, mono/stéréo, encoding) évite les conversions multiples et la latence cachée.

4

Mettre la logique callbot hors des scripts télécom

SIP/RTP doivent faire ce qu’ils font bien (connecter et transporter). La logique conversationnelle doit vivre dans votre orchestration callbot, pas dans un dialplan spaghetti.

5

Prévoir les transferts + le fallback dès le départ

Un callbot qui ne peut pas transférer est un IVR qui a appris à parler. Prévoyez “warm transfer” (résumé + contexte) et fallback DTMF.

Open source vs commercial : une comparaison honnête

Le glossaire de survie : SBC, proxy, B2BUA… et les pièges qui vont avec

Si vous avez déjà perdu 3 heures sur un “pas de son” (félicitations, vous êtes officiellement dans la téléphonie), vous avez compris une chose : les mots comptent.

Voici un glossaire court, utile, et orienté callbot.

SBC (Session Border Controller)

Un SBC, c’est le garde du corps entre votre réseau et l’extérieur :

• il contrôle qui peut entrer/sortir,
• il normalise des détails SIP/SDP,
• il aide sur NAT, sécurité, interop,
• et il peut protéger contre des comportements “créatifs” de certains équipements.

En callbot, c’est souvent une assurance-vie quand vous devez interfacer opérateurs, PBX, et services temps réel.

SIP proxy vs B2BUA (Back-to-Back User Agent)

Sans entrer dans un cours magistral :

• un proxy relaie et route des messages SIP,
• un B2BUA termine une session et en recrée une autre, ce qui donne plus de contrôle… et plus de responsabilités.

En callbot, beaucoup de plateformes “cloud voice” se comportent comme des B2BUA : elles contrôlent l’appel, le média, les transferts, l’enregistrement.

Registrar, location service, etc.

SIP n’est pas seulement “un appel”. C’est aussi un écosystème d’enregistrement et de routage (REGISTER, location). Les bases sont dans RFC 3261.¹

Pourquoi c’est utile ?

Parce qu’un callbot “interne” (agents, extensions, transferts) peut avoir besoin de jouer avec ces mécanismes pour être un citoyen SIP de première classe.

DTMF : le détail qui devient critique le jour où le STT décroche

DTMF n’a pas disparu. Il est juste moins glamour.

Et pourtant, c’est le meilleur fallback du monde quand :

• l’audio est mauvais,
• l’appelant est dans le métro,
• ou vous devez saisir des chiffres (code postal, référence).

Une manière standard de transporter DTMF dans RTP est décrite dans RFC 4733.¹²

SIP over WebSocket : utile quand SIP rencontre le navigateur

Dans certains designs, vous voulez faire du SIP depuis un contexte web.

Le transport SIP sur WebSocket est standardisé (RFC 7118).¹³

En pratique, ça se retrouve dans des stacks “WebRTC gateway” ou des architectures où le front parle WebSocket et une passerelle fait le reste.

DTLS-SRTP : le trio WebRTC pour ne pas envoyer votre audio en clair

Côté WebRTC, le modèle standard est DTLS pour établir des clés, puis SRTP pour chiffrer le média (DTLS-SRTP). RFC 5764 décrit le principe d’établissement de clés pour SRTP via DTLS.¹⁴

Si vous vous demandez “pourquoi c’est si compliqué”, rappelez-vous : la téléphonie classique a vécu longtemps sans chiffrement obligatoire. WebRTC est né dans un monde où le chiffrement est la norme.

Les codes SIP qui disent la vérité (quand tout le monde “pense”)

Quand un appel échoue, on a tendance à accuser :

• le STT,
• le LLM,
• le réseau,
• “Twilio” (si vous êtes cloud),
• “Asterisk” (si vous êtes on-prem),
• ou la phase de lune.

Avant de sortir les fourches, regardez les codes SIP.

Quelques repères utiles :

• 100 Trying : on a bien reçu la demande, on traite.
• 180 Ringing : ça sonne côté destination.
• 200 OK : accord, session établie (souvent accompagné du SDP final).
• 4xx : erreur côté client / requête (auth, droits, routage).
• 5xx : erreur serveur.
• 6xx : échec global (tout le monde refuse).

Ce qui aide en callbot :

• Si vous voyez un 401/407, ce n’est pas “l’IA” : c’est l’auth (trunk, proxy).
• Si vous voyez un 488 Not Acceptable Here, pensez codecs/SDP.
• Si vous voyez un 403, pensez routage/permissions.

Et rappelez-vous : on peut avoir un SIP “OK” et un RTP “mort”. D’où l’ordre de debug : signalisation d’abord, média ensuite.

Si vous ne gardez qu’une discipline : conservez des traces exploitables (SIP ladder, timestamps, PCAP si possible). En téléphonie, “je pense que” ne scale pas. Les paquets, eux, ne mentent pas.

Debug en 10 minutes (avant de tout réécrire)

Quand un callbot “ne marche pas”, posez-vous ces questions dans l’ordre :

1. SIP : est-ce que l’appel s’établit ? (codes, ACK, BYE, etc.)
2. SDP : est-ce que les IP/ports/codecs annoncés sont plausibles ?
3. RTP : est-ce que des paquets arrivent ? (capture réseau côté point de terminaison)
4. Codec : est-ce que le STT reçoit bien le format attendu ?
5. Sécurité : TLS/SRTP ou DTLS-SRTP négocient-ils correctement ?

Ce n’est pas glamour. Mais c’est exactement comme ça qu’on évite les semaines de “ça marche chez moi”.

FAQ

Questions frequentes

Puis-je faire un callbot sans SIP ?+

Oui si votre point d’entrée est WebRTC (web/app) ou une plateforme type Media Streams. Mais si vous devez recevoir des appels téléphoniques “classiques” (PSTN), vous aurez presque toujours un tronçon SIP quelque part.

Pourquoi je n’ai pas d’audio alors que l’appel est établi ?+

Très souvent : NAT/RTP/SDP. SIP établit la session, mais si les ports RTP sont bloqués ou si le SDP pointe vers une mauvaise IP/port, vous aurez un appel “connecté” mais muet.

Quel codec choisir ?+

En téléphonie, vous n’avez pas toujours le choix (G.711 est courant). En WebRTC, Opus est un standard (RFC 6716). L’objectif n’est pas la hi-fi : c’est la compréhension STT et la latence stable.

Twilio Media Streams : unidirectionnel ou bidirectionnel ?+

Unidirectionnel : vous recevez l’audio. Bidirectionnel : vous recevez et vous renvoyez de l’audio pour playback dans l’appel (utile pour certains designs). Twilio documente ces modes et les messages WebSocket associés.⁸⁹

Sources et references

1. [1]RFC Editor, “SIP: Session Initiation Protocol” (RFC 3261).
2. [2]RFC Editor, “RTP: A Transport Protocol for Real-Time Applications” (RFC 3550).
3. [3]RFC Editor, “SDP: Session Description Protocol” (RFC 8866, obsoletes RFC 4566).
4. [4]RFC Editor, “WebRTC Security Architecture” (RFC 8827).
5. [5]OpenAI, “Realtime API” (WebRTC/WebSocket connectors).
6. [6]Asterisk Documentation, “PJSIP-pjproject / chan_pjsip”.
7. [7]Twilio, “Elastic SIP Trunking” + guides de configuration (dont Asterisk).
8. [8]Twilio, “Media Streams overview”.
9. [9]Twilio, “Media Streams - WebSocket messages”.
10. [10]Janus WebRTC Gateway, documentation (dont plugin SIP).
11. [11]RFC Editor, “Definition of the Opus Audio Codec” (RFC 6716).
12. [12]RFC Editor, “RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals” (RFC 4733).
13. [13]RFC Editor, “The WebSocket Protocol as a Transport for SIP” (RFC 7118).
14. [14]RFC Editor, “DTLS Extension to Establish Keys for SRTP” (RFC 5764).