Un navigateur et un téléphone de bureau peuvent être les deux extrémités d'un même appel même s'ils gèrent le média différemment.
Choisir entre les deux revient à traiter des fonctions volontairement assignées à une couche comme si elles appartenaient à l'autre.
Sont-ils des alternatives ?
Non. Ils se situent à des couches différentes et chacun laisse le travail de l'autre inachevé.
SIP est la signalisation. Il trouve l'extrémité distante, négocie le média à échanger, fait sonner, connecte et raccroche. Il ne transporte pas l'audio. La RFC 3261 trace la frontière : "SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture."
WebRTC est la pile média dont dispose un navigateur. Il transporte l'audio et la vidéo entre deux points. Il traverse la traduction d'adresses réseau, ce qui rend un chemin direct entre navigateurs difficile. Il chiffre également le média. Sa propre spécification, la RFC 8825, un document Standards Track de l'IETF de janvier 2021, indique que le format média est RTP. Il exige SRTP : "Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations".
SIP organise les appels sans transporter le média. WebRTC transporte le média sans organiser les appels.
Qu'est-ce que WebRTC laisse de côté, et pourquoi ?
WebRTC laisse de côté la signalisation, et il le fait volontairement : la spécification place le choix du protocole de signalisation hors de son propre périmètre.
La RFC 8825 décrit l'architecture comme un trapèze. Le média circule directement entre les deux navigateurs. La signalisation passe par des serveurs, qui "can modify, translate, or manipulate the signals as needed". La spécification ne choisit pas de protocole de signalisation :
The choice of protocols for client-server and inter-server signaling, and the definition of the translation between them, are outside the scope of the WebRTC protocol suite described in this document.
Ce n'est pas une omission en attente de correction. C'est ce qui permet à une application de chat de signaler via ses propres messages WebSocket tandis qu'une plateforme de téléphonie signale via SIP, avec la même pile média sous les deux. Le même document nomme directement l'option téléphonie, décrivant un déploiement qui utilise "a standardized signaling mechanism (e.g., SIP over WebSockets)" entre le navigateur et le serveur.
SIP sur WebSocket est spécifié dans la RFC 7118, de janvier 2014, qui définit "a WebSocket subprotocol as a reliable transport mechanism between SIP entities to enable use of SIP in web-oriented deployments". Cela change la façon dont les messages SIP circulent et non ce qu'ils disent, ce qui explique qu'un navigateur et un téléphone de bureau puissent être les deux extrémités d'un appel ordinaire.
À quoi cela ressemble-t-il sur Bird ?
Pour connecter un navigateur via Bird, utilisez SIP sur un WebSocket.
Le téléphone intégré au tableau de bord est l'exemple concret. Le navigateur agit comme client SIP. Le tableau de bord génère un identifiant de session à durée de vie courte plutôt que d'envoyer un secret permanent dans une page. La API décrit le handshake_token de l'identifiant comme un "Short-lived token required when upgrading the WebSocket connection". Il "authorizes the connection only; each call still authenticates with password". Le jeton de négociation autorise la connexion, tandis que le mot de passe authentifie chaque appel.
La compatibilité navigateur dépend des algorithmes digest du trunk. Les navigateurs répondent à un défi digest SIP avec MD5 et rien d'autre. Un trunk n'accepte que les algorithmes qu'il propose. Un trunk configuré pour proposer uniquement SHA-256 refuse donc tout appel navigateur, y compris le téléphone du tableau de bord. Garder MD5 dans l'offre est ce qui rend un trunk appelable depuis un navigateur, et SIP trunks couvre ce paramètre.
L'appel atterrit sinon sur le même trunk, vérifie le même identifiant d'appelant validé, respecte les mêmes destinations activées et produit le même enregistrement qu'un appel provenant d'un PBX, le système téléphonique d'entreprise qui achemine les appels d'une société.
Alors, lequel utiliser ?
Choisissez en fonction de l'endroit où tourne votre point de terminaison, et prévoyez d'utiliser SIP dans les deux cas.
WebRTC exige un média chiffré. Le transport TLS d'un trunk SIP chiffre la signalisation en transit plutôt que l'audio. Un audit de chiffrement doit donc couvrir les deux chemins.
- Un navigateur. Une page web utilise la pile WebRTC du navigateur pour le média, cette moitié est donc réglée. Vous choisissez comment signaler. SIP le connecte au réseau téléphonique plutôt qu'uniquement à d'autres navigateurs.
- Un téléphone de bureau, un PBX ou un contrôleur de session en bordure de réseau (SBC), qui gère les appels à la frontière d'un réseau. SIP classique sur UDP, TCP ou TLS. WebRTC n'a rien à offrir à un équipement qui parle déjà RTP.
- Un agent vocal IA. Celui que votre environnement d'exécution implémente déjà. Un agent dans un navigateur ou sur un runtime construit autour des API média du navigateur parlera WebRTC et a besoin d'une signalisation associée. Un agent construit sur une pile de téléphonie parle directement SIP et RTP. Qu'est-ce qu'un agent vocal IA couvre le reste de ce parcours, y compris la partie où l'agent doit terminer l'audio et pas seulement la signalisation.
En bref
La question compare deux couches différentes.
WebRTC est une pile média pour navigateurs sans protocole de signalisation. SIP est un protocole de signalisation qui ne transporte pas le média. Aucun des deux ne remplace l'autre.
WebRTC exclut volontairement la signalisation.
Sa propre vue d'ensemble place le choix du protocole de signalisation hors du périmètre de la spécification, et cite SIP sur WebSockets comme un moyen standard de combler le manque.
Un appel navigateur sur Bird est un appel SIP.
Le navigateur agit comme client SIP, la connexion est promue en WebSocket avec un jeton à durée de vie courte, et chaque appel s'authentifie toujours avec un mot de passe digest.
Le chiffrement se situe à des endroits différents dans chacun.
WebRTC exige SRTP pour le média. Le transport TLS d'un trunk SIP chiffre la signalisation, ce qui est distinct de l'audio.