WebRTC vs SIP : différences et cas d’utilisation

WebRTC et SIP transportent tous deux la voix en temps réel, mais ils ont été conçus pour des univers différents. SIP est né de la téléphonie des opérateurs et des entreprises, où la signalisation normalisée entre fournisseurs et l’interconnexion propre avec le PSTN justifient l’existence du protocole. WebRTC est né du navigateur, avec pour objectif de permettre à deux pages web d’échanger des flux média sans qu’aucun plugin ne soit installé. Le résultat : deux écosystèmes qui se recoupent en fonctionnalités, mais divergent sur presque toutes les décisions architecturales sous-jacentes.

Ce guide est une comparaison orientée vers la décision. Il couvre ce que chaque technologie est réellement, les différences en pratique (signalisation, transport, chiffrement, identité, traversée de NAT), les cas d’utilisation où chacune l’emporte, et ce qui change lorsqu’elles doivent communiquer à travers une frontière. Pour les mécanismes du protocole SIP lui-même, l’article complémentaire Les fondamentaux de la signalisation SIP couvre les rôles protocolaires et l’architecture à un niveau plus élevé, et Flux d’appel SIP expliqué étape par étape détaille les messages sur le fil. Cet article suppose ces bases acquises et se concentre sur la comparaison avec WebRTC.

Cet article ne couvre pas l’architecture complète d’implémentation d’une passerelle WebRTC-to-SIP. Ce sujet mérite un traitement dédié, et un article d’architecture de passerelle suivra. Ici, la discussion sur la passerelle reste au niveau nécessaire pour prendre des décisions, pas pour configurer un déploiement.

Ce qu’est réellement WebRTC

WebRTC est un ensemble d’API de navigateur (et un jeu correspondant de protocoles réseau) qui permet à une application web de capturer un microphone ou une caméra, de chiffrer le flux et de l’envoyer à un autre terminal sans plugin ni client installé. Le modèle mental à retenir : une API JavaScript dans le navigateur, une pile média figée en dessous, et une pièce délibérément absente au-dessus.

La pile média figée est très prescriptive. Le transport est UDP. Le chiffrement des flux média est SRTP, et il est obligatoire ; il n’existe pas de mode non chiffré. L’échange de clés utilise DTLS-SRTP, effectué directement sur le chemin média. La traversée de NAT est intégrée via ICE, STUN et TURN, qui ensemble permettent à deux navigateurs derrière des NAT distincts de trouver un chemin fonctionnel ou de se replier sur un relais. Les codecs sont limités à un ensemble restreint, avec Opus par défaut pour l’audio et VP8/VP9/H.264/AV1 pour la vidéo.

La pièce manquante, c’est la signalisation. WebRTC omet délibérément la manière dont deux terminaux se trouvent, échangent des descriptions de session ou découvrent les candidats ICE de l’autre. Cela est laissé à l’application, qui transporte généralement les messages de signalisation via WebSocket, un schéma HTTP personnalisé, ou tout autre canal choisi par le développeur. C’est la différence architecturale la plus fondamentale avec SIP. SIP est un protocole de signalisation ; WebRTC n’en a pas.

La conséquence pratique : deux navigateurs exécutant la même application web peuvent communiquer de bout en bout, mais deux navigateurs exécutant des applications différentes ne le peuvent pas. Il n’existe pas d’équivalent WebRTC de « composer n’importe quelle URI SIP ». La fédération se produit au niveau applicatif, pas au niveau protocolaire.

Les différences clés

Le tableau suivant résume les décisions architecturales de chaque technologie. La plupart des compromis abordés dans les sections suivantes se rapportent à l’une de ces lignes.

Où les architectures divergent en pratique

Le tableau est un bon résumé, mais les conséquences ne deviennent visibles qu’en observant comment chaque choix de conception se traduit dans un déploiement réel.

WebRTC n’a pas de protocole de signalisation

C’est la différence structurelle dont découle tout le reste. Une application WebRTC choisit son propre transport de signalisation (généralement WebSocket transportant du JSON), définit ses propres formats de messages et route les messages entre utilisateurs via son propre backend. Si l’application disparaît, la signalisation disparaît avec elle. SIP est l’inverse. La signalisation est la norme, et tout terminal conforme peut communiquer avec tout autre terminal conforme sans coordination préalable avec l’application qui l’a créé.

C’est cette propriété qui fait de SIP le protocole d’interconnexion. Deux opérateurs, deux fournisseurs de PBX, ou un PBX et une plateforme UCaaS hébergée peuvent tous échanger des appels sans partager de code applicatif. WebRTC n’a pas d’équivalent.

SIP découple la signalisation du média ; WebRTC les lie par conception

Avec SIP, le chemin de signalisation et le chemin média sont indépendants. SIP négocie la session (sur UDP, TCP ou TLS), et RTP ou SRTP circule directement entre les terminaux sur un ensemble de ports différent. Le média peut emprunter un chemin complètement différent de celui de la signalisation, et c’est souvent le cas.

Avec WebRTC, le chemin média est entièrement spécifié par la pile protocolaire : UDP, candidats ICE négociés via la signalisation, poignée de main DTLS sur le socket média, clés SRTP dérivées de cette poignée de main. La signalisation est indépendante au sens où l’application la contrôle, mais le chemin média est rigidement défini et supposé de bout en bout entre les deux terminaux PeerConnection.

Chiffrement obligatoire vs chiffrement optionnel

Les flux média WebRTC sont toujours chiffrés. Il n’existe aucun moyen de négocier du RTP non chiffré entre deux pairs WebRTC. L’échange de clés se fait via DTLS-SRTP sur le socket média, ce qui supprime la dépendance vis-à-vis de la sécurité de la couche de signalisation pour la confidentialité des clés.

SIP autorise le chiffrement des flux média (SRTP, généralement clé via SDES dans un corps SDP transporté sur une signalisation protégée par TLS) mais ne l’exige pas. Une grande partie du trafic opérateur et trunk circule encore en RTP non chiffré, car l’opérateur considère le réseau comme étant de confiance. Pour en savoir plus sur les différences d’échange de clés SRTP entre SDES et DTLS-SRTP, voir Qu’est-ce que SRTP ?.

Identité et confiance

SIP dispose de mécanismes d’identité explicites. L’en-tête P-Asserted-Identity transporte une identité d’appelant attestée au sein d’un réseau de confiance, l’en-tête SIP Identity (utilisé par STIR/SHAKEN) atteste cryptographiquement du numéro de l’appelant, et les opérateurs maintiennent des relations de confiance qui donnent leur signification à ces en-têtes. WebRTC ne dispose de rien de tout cela au niveau protocolaire. L’identité dans une application WebRTC est ce que l’application choisit d’appliquer, généralement un jeton de connexion lié à un compte utilisateur dans le même backend qui gère la signalisation.

Cela compte lorsque le trafic WebRTC entre en contact avec le PSTN. Un cadre de lutte contre les appels automatisés comme STIR/SHAKEN a du sens au sein de SIP. Il n’en a pas pour un appel de navigateur à navigateur entre deux utilisateurs de la même application.

Philosophie de traversée de NAT

SIP suppose que l’opérateur réseau résoudra le problème du NAT. La solution classique consiste à placer un SBC en bordure de sorte que les terminaux internes s’enregistrent auprès d’un élément accessible publiquement qui gère les keepalives NAT, la réécriture d’adresses et la traversée de NAT côté distant. Les ALG SIP sur les pare-feu tentent quelque chose de similaire dans les déploiements plus petits, souvent avec des résultats mitigés.

WebRTC suppose que les terminaux résoudront eux-mêmes le NAT. ICE parcourt chaque paire d’adresses candidates (hôte, server-reflexive via STUN, relayée via TURN), les teste et choisit la meilleure. Un serveur TURN est la solution de repli lorsque les chemins directs échouent, et dans de nombreux grands déploiements, TURN finit par acheminer une fraction significative du média. L’avantage : le protocole fonctionne presque partout. Le coût : les opérateurs doivent exploiter une infrastructure STUN et TURN.

Cas d’utilisation où SIP l’emporte

SIP est le protocole vers lequel on se tourne chaque fois qu’un appel doit quitter une organisation pour en atteindre une autre, chaque fois qu’il touche au PSTN, ou chaque fois qu’un équipement doit s’interconnecter avec autre chose qu’une copie de lui-même.

• L’interconnexion opérateur et l’accès au PSTN sont les cas d’utilisation originaux. Chaque opérateur Tier 1, chaque ITSP et chaque commutateur Class 4/5 en production parle SIP ou son cousin SIP-I.
• Le routage direct Microsoft Teams (Direct Routing) est une intégration SIP. Teams Phone utilise la signalisation SIP vers le SBC et SRTP sur le chemin média, le SBC assurant la traduction entre le dialecte SIP de Teams et ce que l’opérateur fournit. Les mécanismes complets sont couverts dans Qu’est-ce que le routage direct Teams ?.
• La téléphonie d’entreprise multi-fournisseurs repose sur SIP pour qu’un IP-PBX d’un fournisseur, une plateforme de centre de contact d’un autre et un SBC d’un troisième puissent tous partager les mêmes jonctions.
• Les déploiements IP-PBX et les jonctions SIP (SIP trunking) reposent sur SIP de bout en bout. Même lorsque les téléphones de bureau sont des softphones et que la jonction est fournie via internet, la signalisation sous l’application est SIP.
• Les jonctions pour centres de contact à grande échelle, y compris le BYOC vers Genesys, Five9 ou NICE, utilisent SIP car le côté opérateur n’a pas d’autre moyen de livrer les appels entrants.

Là où il y a un plan de numérotation, un opérateur ou un PBX, SIP est la réponse.

Cas d’utilisation où WebRTC l’emporte

La force de WebRTC est d’atteindre l’utilisateur sans lui demander d’installer quoi que ce soit. Partout où le terminal est un navigateur, un appareil client que l’opérateur ne contrôle pas, ou une application mobile nécessitant une pile média légère et prévisible, WebRTC tend à être le bon choix.

• Les softphones navigateur pour les employés internes ou les agents distants éliminent entièrement le problème du client de bureau. Une URL et un identifiant sont la seule surface de déploiement.
• Le click-to-call depuis une page marketing connecte un visiteur du site à une file d’attente commerciale ou support sans logiciel d’appel côté visiteur.
• Les postes agents de centre de contact dans le navigateur permettent aux agents de gérer les appels dans le même onglet CRM qu’ils utilisent toute la journée, éliminant un client softphone séparé.
• Le support voix et vidéo en direct côté client s’intègre directement dans les applications mobiles et les parcours web ; les utilisateurs ne changent pas de contexte pour lancer un appel.
• Les applications de collaboration interne (la large catégorie incluant Google Meet, Discord, le client web de Zoom) utilisent WebRTC parce que le coût de distribution d’un client natif à chaque participant d’une réunion est inacceptable.
• Les scénarios d’intégration à faible friction comme les consultations de télémédecine, les rendez-vous de conseil financier ou les plateformes d’entretien bénéficient d’un accès sans installation pour la partie côté client.

Le schéma commun : l’un des côtés de la conversation est une personne sur l’internet ouvert à qui on ne doit pas demander d’installer un logiciel. WebRTC est le protocole conçu pour ce côté.

Quand ils doivent communiquer entre eux

La plupart des déploiements en production sont mixtes. Un softphone navigateur doit atteindre le PSTN. Un client web de centre de contact doit router les appels entrants depuis une jonction SIP. Un widget click-to-call doit se connecter à une file d’attente servie par un ACD traditionnel. À ces points, les deux mondes doivent se rencontrer, et quatre éléments doivent être traduits à la frontière.

La signalisation est la première traduction. Le côté WebRTC parle le protocole choisi par l’application (généralement WebSocket transportant SIP-over-WebSocket selon RFC 7118, ou un protocole JSON propriétaire). Le côté SIP parle SIP standard sur UDP, TCP ou TLS. Une passerelle termine les deux et assure la correspondance.

Le chiffrement des flux média est la deuxième. WebRTC exige DTLS-SRTP. Le côté SIP peut fournir du SRTP clé par SDES, ou du RTP non chiffré. La passerelle termine la poignée de main DTLS vers le navigateur et reclé le média sur l’autre segment selon les exigences du pair SIP.

Le codec est la troisième. Les navigateurs utilisent Opus par défaut ; le PSTN et la plupart des jonctions SIP utilisent G.711. Si les deux côtés prennent en charge un codec commun, l’appel passe ; sinon, la passerelle transcode ou rejette l’appel. Le transcodage Opus vers G.711 n’est pas gratuit ; il nécessite une capacité DSP matérielle sur des plateformes comme ProSBC (le module TSBC-HW-TRANS).

La traversée de NAT est la quatrième. Le côté WebRTC exécute ICE vers l’adresse joignable de la passerelle. Le côté SIP ne le fait pas ; la passerelle termine ICE sur le segment navigateur et présente un terminal SIP/RTP statique à l’opérateur ou au PBX.

Un SBC de type B2BUA est le choix architectural adapté à cette frontière, car il termine entièrement les deux segments et donne à l’opérateur un contrôle total sur chaque en-tête, codec et contexte cryptographique. Un proxy SIP ne peut pas effectuer ce travail ; les segments sont trop différents. Un article dédié à l’architecture de passerelle couvrira les détails d’implémentation (traduction de signalisation, terminaison ICE, placement du transcodage, mise à l’échelle).

Où ProSBC intervient

ProSBC est un SBC logiciel de type B2BUA qui termine le côté SIP des déploiements où le trafic WebRTC arrive en amont. Le rôle typique est le segment SIP-vers-opérateur (ou SIP-vers-PBX) : la passerelle côté WebRTC transmet une session SIP normalisée à ProSBC, et ProSBC gère l’interopérabilité opérateur, la terminaison TLS et SRTP vers la jonction, la normalisation des en-têtes SIP côté PSTN et le masquage de topologie entre le cloud et l’opérateur.

Sur ce segment, ProSBC fournit TLS 1.3 pour la signalisation SIP et SRTP (relais ou conversion RTP vers SRTP) pour les flux média, avec une configuration de transport et de chiffrement par groupe de jonctions. Le moteur de manipulation d’en-têtes SIP gère les différences entre ce qu’une plateforme CPaaS ou une passerelle WebRTC produit et ce qu’un opérateur s’attend à recevoir.

ProSBC peut lui-même effectuer le transcodage pour les codecs G.711 A-law et mu-law. Pour une prise en charge de codecs plus large, ProSBC fonctionne en tandem avec une unité matérielle TSBC-HW-TRANS pour garantir une négociation et une traduction de codecs en temps réel pour chaque appel.

ProSBC n’inclut pas de registrar SIP intégré, et ce n’est pas le bon produit pour le segment côté WebRTC lui-même. La passerelle côté navigateur (un serveur d’application ou une passerelle compatible WebRTC comme Janus ou Kamailio avec le module WebSocket) se place en amont. ProSBC se place derrière elle, côté SIP.