Architecture d’une passerelle WebRTC vers SIP : composants, traduction et topologies de déploiement

Une passerelle WebRTC vers SIP est l’élément réseau qui permet à une application voix ou vidéo basée sur un navigateur d’atteindre le PSTN, un trunk SIP, un PBX ou tout autre pair SIP externe. Elle se situe à la frontière où deux piles de communication en temps réel, en désaccord sur la signalisation, le transport, le chiffrement, la traversée de NAT et l’identité, doivent partager un appel.

L’article complémentaire WebRTC vs SIP : différences et cas d’utilisation couvre ce qu’est chaque technologie et quand en choisir une. Le présent article suppose ces connaissances acquises et examine une couche plus en profondeur : les sous-systèmes qui composent une passerelle, comment chaque traduction fonctionne sur le réseau, et comment les composants s’assemblent dans un déploiement en production. Pour les mécanismes du protocole SIP que cet article suppose familiers, Les fondamentaux de la signalisation SIP et Le flux d’appel SIP expliqué étape par étape sont les références complémentaires.

Ce que la passerelle WebRTC vers SIP doit réellement faire

Une PeerConnection WebRTC et un dialogue SIP se ressemblent vus de très haut : tous deux négocient une session média entre deux terminaux, tous deux transportent du RTP chiffré, tous deux fonctionnent sur UDP. De près, ils se chevauchent à peine. Une passerelle doit résoudre cinq problèmes de traduction à la frontière, et chacun nécessite son propre sous-système.

Traduction de la signalisation met en correspondance la signalisation de l’application côté WebRTC (typiquement un WebSocket transportant du SIP-over-WebSocket ou un protocole JSON propriétaire) avec le SIP standard côté opérateur.

Terminaison de la traversée de NAT reçoit les candidats ICE côté navigateur, présente une adresse statique unique côté SIP, et exploite l’infrastructure STUN/TURN pour le côté WebRTC.

Traduction du chiffrement média termine le DTLS-SRTP vers le navigateur et renouvelle les clés média côté SIP en utilisant ce que le pair attend : SRTP via SDES, DTLS-SRTP à nouveau, ou RTP en clair.

Médiation de codecs gère l’écart entre Opus (le codec par défaut de WebRTC) et G.711 ou G.729 (les codecs par défaut de SIP), soit par négociation SDP, soit par transcodage actif.

Pontage d’identité affirme une identité sur le tronçon SIP sortant sur laquelle les systèmes en aval peuvent agir (identification de l’appelant, signature STIR/SHAKEN), car WebRTC n’a rien au niveau du protocole à transmettre.

La suite de cet article parcourt chacun de ces sous-systèmes, puis les réassemble dans les topologies de déploiement qui apparaissent effectivement en production.

Traduction de la signalisation

WebRTC n’a pas de protocole de signalisation défini. C’est l’application qui en choisit un. En pratique, deux modèles dominent.

SIP-over-WebSocket (RFC 7118)

Ce modèle fait transiter le protocole SIP lui-même à travers une connexion WebSocket entre le navigateur et la passerelle. Le navigateur utilise une bibliothèque SIP en JavaScript (JsSIP, SIP.js) ; la passerelle termine le WebSocket, analyse la pile SIP au-dessus, et réencode les mêmes messages sur un socket SIP normal en UDP, TCP ou TLS vers l’opérateur. La traduction est structurellement simple car les deux côtés parlent SIP ; seul le transport change. Kamailio (avec le module websocket), OpenSIPS et Janus en mode passerelle SIP implémentent tous ce modèle.

JSON propriétaire sur WebSocket

C’est ce que la plupart des SDK de couche applicative utilisent, y compris Twilio Programmable Voice, Vonage, Zoom Phone et les piles CPaaS personnalisées. Le navigateur envoie des messages comme {"type": "invite", "callee": "...", "sdp": "..."} et le backend applicatif les traduit en SIP en interne. La passerelle dans ce cas fait partie du backend lui-même, et la frontière SIP est interne à la plateforme.

Ce que la traduction de signalisation doit gérer et que SIP ne fait pas

Le SDP munging couvre les différences entre le SDP produit par un navigateur et le SDP attendu par un opérateur. L’offre du navigateur liste tous les candidats ICE qu’il a découverts, déclare le DTLS-SRTP comme obligatoire et annonce Opus. L’opérateur attend un SDP sans attributs ICE, avec des clés SDES (ou du RTP en clair), et une liste de codecs différente. La passerelle réécrit entièrement le SDP de chaque côté, présentant une forme au navigateur et une autre à l’opérateur.

Le Trickle ICE importe car WebRTC découvre les candidats ICE de manière asynchrone et les envoie au pair au fur et à mesure, après l’offre initiale. La passerelle doit accepter ces candidats transmis progressivement, mais SIP n’a pas de mécanisme équivalent, donc l’offre côté SIP attend soit que l’ICE soit complet (end-of-candidates), soit omet entièrement l’ICE et utilise une seule adresse statique.

La gestion des re-INVITE devient un problème de traduction car les modifications en cours d’appel (mise en attente, sourdine, changement de codec, transfert) arrivent sous forme de renégociation des deux côtés mais dans des formats différents. La passerelle doit faire la correspondance entre les deux sans couper l’appel. Voir Le flux d’appel SIP expliqué pour le fonctionnement du re-INVITE côté SIP.

Traversée de NAT et terminaison ICE

WebRTC suppose que les terminaux résoudront eux-mêmes le NAT. SIP suppose que l’opérateur réseau le fera. La passerelle doit concilier les deux philosophies, ce qu’elle fait en exécutant l’ICE complet d’un côté et aucun ICE de l’autre.

Côté navigateur, la passerelle exécute l’ICE complet. Elle annonce ses propres candidats ICE (hôte, réflexion serveur via STUN, relais via TURN), teste la connectivité avec les candidats du navigateur et sélectionne le meilleur chemin. Si les chemins directs échouent, le propre serveur TURN de la passerelle relaie le média. Cela signifie que l’opérateur doit déployer et dimensionner une infrastructure TURN proportionnelle au trafic WebRTC ; dans les déploiements où la plupart des navigateurs se trouvent derrière un NAT d’entreprise restrictif, TURN peut acheminer une part significative des octets média.

Côté SIP, la passerelle présente une adresse IP et un port statiques uniques à l’opérateur. Il n’y a pas d’ICE de ce côté ; l’opérateur attend un socket RTP fixe sur l’adresse publique de la passerelle. La passerelle est responsable de maintenir ce socket accessible à travers tout NAT ou pare-feu se trouvant devant elle, ce qui est le même problème que tout SBC résout avec la dissimulation de topologie et la gestion du NAT distant.

L’asymétrie est intentionnelle. ICE transfère la complexité aux terminaux lorsque les deux sont intelligents (deux navigateurs). À une frontière opérateur, où un côté est un commutateur matériel qui n’a pas changé depuis quinze ans, la passerelle absorbe la complexité à la place.

Chiffrement média : le transfert DTLS-SRTP

C’est la partie la plus intéressante de la passerelle sur le plan cryptographique. Les deux côtés utilisent des mécanismes d’échange de clés différents, et la passerelle est la frontière de confiance entre eux.

Côté navigateur, la passerelle agit comme répondeur DTLS. Après que l’ICE a sélectionné un chemin, le navigateur initie une poignée de main DTLS sur le même socket UDP que celui sur lequel le média transitera. La passerelle présente un certificat (auto-signé est acceptable ; l’empreinte transite dans le SDP), complète la poignée de main et dérive les clés maîtresses SRTP à partir des clés de session DTLS via l’API export_keying_material. Le média provenant du navigateur est chiffré avec ces clés.

Côté SIP, la passerelle négocie le SRTP différemment. Le modèle le plus courant est SDES, où la clé maîtresse est intégrée directement dans le corps SDP et le corps est protégé par TLS sur le canal de signalisation. Plus rarement, le pair SIP parle aussi DTLS-SRTP, auquel cas la passerelle exécute une seconde poignée de main DTLS en sortie. Le modèle le moins sécurisé est le RTP en clair, où aucun chiffrement n’est négocié ; la passerelle chiffre côté navigateur et déchiffre côté SIP.

Quelle que soit la combinaison applicable, la passerelle maintient deux contextes SRTP indépendants simultanément et rechiffre chaque paquet lorsqu’il traverse la frontière. Les paquets eux-mêmes changent : les valeurs SSRC sont réécrites, les numéros de séquence sont réinitialisés, et les clés sont complètement différentes de chaque côté. Il n’y a aucun partage de clés entre les côtés ; c’est précisément le but.

Médiation de codecs et placement du transcodage

Opus est le codec par défaut de WebRTC. G.711 (mu-law ou A-law) est le codec par défaut du PSTN. La passerelle dispose de trois options lorsqu’un appel traverse la frontière.

Négocier un codec commun. Si l’opérateur supporte Opus sur le trunk SIP (la plupart ne le font pas) et que le navigateur supporte G.711 (la plupart le font), la passerelle peut effectuer un transit sans transcodage. Certains déploiements MSP et CPaaS configurent cela pour éviter entièrement le coût du transcodage.

Transcoder. La passerelle décode le RTP entrant, réencode dans le codec sortant et transmet le nouveau flux. Opus vers G.711 est le cas courant. Pour une vue approfondie du fonctionnement du transcodage à la périphérie SBC, l’article Transcodage SBC AMR vers G.711 détaille la même boucle décodage/réencodage pour les codecs de réseaux mobiles.

Rejeter l’appel. Si aucun des deux côtés ne peut négocier quelque chose que l’autre accepte (rare mais possible avec des trunks G.729 exclusifs), la passerelle renvoie 488 Not Acceptable Here.

L’emplacement du transcodage dans l’architecture de la passerelle a des conséquences pratiques. Le transcodage logiciel sur des processeurs standard convient pour le G.711 vers G.711 (A-law vers mu-law est essentiellement gratuit) et pour une capacité Opus limitée. Le transcodage Opus vers G.711 à haute densité est dominé par l’arithmétique DSP, et la plupart des déploiements de classe opérateur déchargent ce travail sur du matériel dédié pour préserver la marge CPU disponible pour les autres responsabilités de la passerelle.

Pour un SBC situé sur le tronçon SIP d’un déploiement à deux niveaux, le bon placement consiste généralement à garder le transcodage G.711 en logiciel (A-law vers mu-law est nativement supporté dans ProSBC) et à décharger l’AMR et le G.729 sur une unité de transcodage matérielle telle que TSBC-HW-TRANS. C’est le codec sur le tronçon WebRTC entrant qui détermine le besoin en DSP, pas le codec côté SIP.

Pontage d’identité

WebRTC n’a pas d’identité au niveau du protocole. L’application affirme l’identité dans son propre backend, généralement avec un jeton de connexion lié à un compte utilisateur. Lorsque cet appel passe en SIP, l’opérateur a besoin de quelque chose de concret à placer dans l’en-tête From, l’en-tête P-Asserted-Identity et (aux États-Unis) l’en-tête STIR/SHAKEN Identity.

La passerelle résout cela en associant l’identité de l’utilisateur WebRTC à une identité SIP à la frontière. La passerelle est configurée avec une identité de trunk SIP (un numéro de service, une plage de DID ou une identité affirmée par B2BUA) et appose sur l’INVITE sortant cette identité, plus une attestation par appel que la passerelle a authentifié l’utilisateur en amont.

Pour STIR/SHAKEN, la passerelle ne peut signer au niveau d’attestation A que lorsqu’elle opère en tant qu’opérateur d’origine. Si la passerelle transfère à un opérateur qui signe, la passerelle fournit l’identité d’origine et le service de signature de l’opérateur produit l’en-tête Identity. ProSBC s’intègre avec TransNexus ClearIP et Neustar via SIP pour ce modèle exact : la passerelle route l’appel vers un NAP dont le service_type est AUTHENTICATION, ClearIP renvoie un 302 avec l’en-tête Identity attaché, et l’appel progresse vers l’opérateur. Les mécanismes de normalisation des en-têtes porteurs d’identité entre les dialectes SIP des différents fournisseurs sont couverts dans Manipulation des en-têtes SIP.

Ce qui ne peut pas être ponté : les jetons d’identité WebRTC (JWT, flux OAuth) ne survivent pas à la frontière SIP. Quelle que soit la confiance que le backend applicatif a établie, elle est échangée contre la propre relation de confiance de la passerelle avec l’opérateur.

Topologies de déploiement

Trois modèles dominent en production. Le choix dépend de l’échelle, de la nécessité ou non de conférence multi-participants, et de la préférence de l’opérateur pour un élément qui fait tout ou des éléments spécialisés qui font chacun une seule tâche.

Passerelle mono-niveau

Un seul équipement termine le côté WebRTC, effectue la traduction et présente une interface SIP à l’opérateur. Janus avec le plugin SIP, Kamailio avec les modules websocket et rtpengine, et plusieurs appliances de fournisseurs CPaaS suivent ce modèle. L’avantage est la simplicité opérationnelle : une seule machine à dimensionner et superviser. L’inconvénient est que la passerelle doit tout faire, y compris le transcodage gourmand en DSP et le travail SBC côté opérateur (manipulation d’en-têtes, protection contre la fraude, dissimulation de topologie, absorption de registrar). À petite échelle c’est acceptable ; à l’échelle opérateur, cela concentre trop de responsabilités dans un seul élément.

Deux niveaux : passerelle WebRTC devant un SBC

C’est le modèle de production le plus courant. Une passerelle WebRTC dédiée gère le tronçon côté navigateur : terminaison WebSocket, ICE, DTLS-SRTP, TURN, transmission progressive des candidats ICE et affirmation d’identité depuis le backend applicatif. La passerelle transfère ensuite une session SIP normalisée à un SBC qui gère le tronçon côté opérateur : SIP sur TLS, SRTP avec SDES, normalisation d’en-têtes, dissimulation de topologie, contrôle d’admission d’appels, scoring de fraude et intégration STIR/SHAKEN. La séparation permet à chaque élément de se spécialiser et de se dimensionner indépendamment de l’autre.

ProSBC s’inscrit dans ce modèle côté SIP. Ce n’est pas une passerelle côté WebRTC et il ne termine pas la signalisation WebSocket ; la passerelle WebRTC placée devant (Janus, Kamailio, OpenSIPS ou un serveur applicatif CPaaS) gère le côté navigateur. ProSBC prend en charge tout ce qui se trouve en aval : TLS pour la signalisation SIP, SRTP pour le média (relais ou conversion RTP vers SRTP), manipulation des en-têtes SIP par trunk, dissimulation de topologie entre la zone WebRTC et l’opérateur, et intégration avec la détection de fraude et les partenaires STIR/SHAKEN.

Topologie de déploiement à deux niveaux : une passerelle WebRTC gère le tronçon côté navigateur (signalisation WebSocket, ICE, DTLS-SRTP, TURN), puis transfère une session SIP normalisée à ProSBC, qui gère le tronçon côté opérateur (SIP/TLS, SRTP, manipulation d’en-têtes SIP, dissimulation de topologie, intégration fraude et STIR/SHAKEN). Cliquez pour agrandir.

Trois niveaux avec serveur média

Pour les déploiements nécessitant de la conférence multi-participants, un SFU (Selective Forwarding Unit) ou MCU (Multipoint Control Unit) se place entre le navigateur et la passerelle. Le SFU gère le traitement de la conférence (transmission des flux vidéo à tous les participants et mixage des flux audio entre participants), et la passerelle relie la sortie SIP du SFU à l’opérateur lorsque la conférence inclut un participant PSTN. C’est l’architecture derrière la conférence par accès téléphonique pour la plupart des grandes plateformes de réunion et des déploiements de centres de contact.

Le modèle à trois niveaux ajoute un SFU entre le groupe de navigateurs et la passerelle WebRTC, le reste du chemin SIP restant inchangé.

Dimensionnement : TURN, signalisation et média

Chaque sous-système se dimensionne sur un axe différent, et la planification de capacité pour l’un ne renseigne pas beaucoup sur la planification de capacité pour un autre.

La bande passante TURN est le poste le plus variable. Un chemin direct navigateur-passerelle n’utilise aucune bande passante TURN. Un navigateur derrière un NAT symétrique ou un pare-feu d’entreprise restrictif relaie via TURN pendant toute la durée de l’appel, et le serveur TURN paie pour les octets dans les deux sens. Dimensionnez la capacité TURN pour la fraction la plus défavorable d’utilisateurs qui ne peuvent pas trouver de chemin direct, pas pour la moyenne. Dans les déploiements avec un trafic d’entreprise significatif, cette fraction dépasse régulièrement 20 pour cent.

La capacité de signalisation de la passerelle est limitée par la densité de connexions WebSocket, pas par le débit de messages. Chaque navigateur connecté maintient un WebSocket ouvert ; des dizaines de milliers de WebSockets inactifs sur un seul hôte sont plausibles si la mémoire est correctement provisionnée. La traduction de signalisation elle-même est peu coûteuse par message, mais ce sont les connexions persistantes qui dominent.

La capacité média se dimensionne avec la charge de transcodage sur une base par appel. Le relais pur (sans transcodage, les deux côtés sur le même codec) se dimensionne proche du débit réseau. Le transcodage Opus vers G.711 est contraint par les cycles DSP ou CPU ; la densité publiée pour les transcodeurs matériels atteint des milliers de sessions concurrentes par serveur de traitement média, tandis que le transcodage logiciel n’en représente typiquement qu’une fraction.

Côté SIP, ProSBC gère jusqu’à 60 000 sessions de signalisation concurrentes par serveur avec un transcodage logiciel pour le G.711 uniquement ; l’AMR et le G.729 nécessitent une unité de transcodage matérielle. La combinaison judicieuse des deux est ce qui permet à un déploiement à deux niveaux de dimensionner le plan média indépendamment du plan de signalisation : la passerelle WebRTC se dimensionne pour la densité WebSocket et le débit TURN, tandis que le SBC se dimensionne pour les sessions SIP et (le cas échéant) les unités de transcodage.

Haute disponibilité et observabilité

Une passerelle WebRTC vers SIP se situe dans le chemin vocal critique, ce qui signifie que chaque composant a besoin d’un pair redondant et que les modes de défaillance doivent être visibles des deux côtés.

Pour la haute disponibilité, la passerelle WebRTC peut fonctionner en actif-actif derrière un répartiteur de charge car les connexions WebSocket sont indépendantes et sans état du point de vue du cluster. Les serveurs TURN sont typiquement en actif-actif derrière de l’anycast ou du round-robin DNS. Le SBC côté SIP est plus souvent en actif-passif avec une IP virtuelle. ProSBC supporte la haute disponibilité 1+1 en actif-passif pour une disponibilité maximale, avec la réserve que le basculement n’est pas sans perte ; certains appels en cours sont interrompus pendant la bascule, et le déploiement doit être conçu pour les relancer rapidement plutôt que pour empêcher l’interruption.

Pour l’observabilité, la traçabilité à travers les tronçons est le problème difficile. Un appel qui échoue entre un navigateur et une destination PSTN touche le backend applicatif, la passerelle WebRTC, le SBC et l’opérateur ; chaque composant journalise dans son propre format, et la corrélation d’un seul appel à travers tous nécessite la propagation d’un identifiant d’appel à chaque saut. La pratique standard est d’injecter un identifiant unique comme en-tête SIP sur le tronçon SIP et un champ personnalisé dans la signalisation de l’application sur le tronçon WebRTC, puis de les exposer dans une journalisation centralisée.

ProSBC expose des métriques par NAP et par appel (CPS, ASR, ABR, PDD, gigue) via son API REST et peut les router vers la plateforme d’observabilité de choix du client. L’article Meilleures pratiques de supervision VoIP explique ce que signifient ces métriques et quels seuils comptent dans un déploiement voix en production.

Questions fréquemment posées

Conclusion

Une passerelle WebRTC vers SIP est l’élément frontière qui permet à deux piles temps réel de partager un appel sans que l’un des deux côtés ne connaisse les décisions protocolaires de l’autre. La passerelle est construite à partir de cinq sous-systèmes : traduction de signalisation, terminaison ICE, renouvellement de clés DTLS-SRTP, médiation de codecs et pontage d’identité. Chacun a son propre profil de dimensionnement, et le déploiement de production le plus courant les répartit sur deux niveaux : une passerelle WebRTC dédiée côté navigateur et un SBC côté opérateur, afin que chaque élément se spécialise dans le travail qu’il fait le mieux.

Lors de l’évaluation des composants de passerelle pour un déploiement en production, les questions à se poser sont : quel côté chaque élément termine-t-il, où se situe le transcodage (matériel ou logiciel), comment la capacité TURN et la capacité de signalisation sont-elles dimensionnées indépendamment, et comment l’identité est-elle transmise à travers la frontière vers la signature STIR/SHAKEN. Les réponses déterminent si le déploiement est une appliance mono-niveau, une séparation à deux niveaux ou une topologie de conférence à trois niveaux.