Un browser e un telefono fisso possono essere le due estremità di una stessa chiamata anche se gestiscono il media in modo diverso.
Scegliere tra i due tratta funzionalità assegnate di proposito a un livello come se appartenessero all'altro.
Sono alternative?
No. Operano a livelli diversi e ciascuno lascia incompiuto il lavoro dell'altro.
SIP è segnalazione. Trova l'altro capo, negozia quale media verrà scambiato, fa squillare, connette e abbatte la chiamata. Non trasporta l'audio. RFC 3261 traccia il confine: "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 è lo stack media di un browser. Trasporta audio e video tra due endpoint. Attraversa la traduzione degli indirizzi di rete (NAT), che è ciò che rende difficile un percorso diretto tra browser. Cifra anche il media. La sua specifica, RFC 8825, un documento IETF Standards Track del gennaio 2021, indica RTP come formato media. Richiede SRTP: "Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations".
SIP organizza le chiamate senza trasportare media. WebRTC trasporta media senza organizzare le chiamate.
Cosa esclude WebRTC e perché?
WebRTC esclude la segnalazione, e lo fa di proposito: la specifica colloca la scelta del protocollo di segnalazione al di fuori del proprio ambito.
RFC 8825 descrive l'architettura come un trapezio. Il media viaggia direttamente tra i due browser. La segnalazione viaggia attraverso i server, che "can modify, translate, or manipulate the signals as needed". La specifica non sceglie un protocollo di segnalazione:
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.
Non si tratta di un'omissione in attesa di correzione. È ciò che permette a un'applicazione di chat di segnalare attraverso i propri messaggi WebSocket mentre una piattaforma di telefonia segnala tramite SIP, con lo stesso stack media sotto entrambe. Lo stesso documento indica direttamente l'opzione telefonica, descrivendo un deployment che usa "a standardized signaling mechanism (e.g., SIP over WebSockets)" tra il browser e il server.
SIP over WebSocket è specificato in RFC 7118, del gennaio 2014, che definisce "a WebSocket subprotocol as a reliable transport mechanism between SIP entities to enable use of SIP in web-oriented deployments". Cambia il modo in cui i messaggi SIP viaggiano, non il loro contenuto, ed è per questo che un browser e un telefono fisso possono essere le due estremità di una normale chiamata.
Come funziona su Bird?
Per connettere un browser tramite Bird, usa SIP su un WebSocket.
Il telefono della dashboard è l'esempio pratico. Il browser agisce come client SIP. La dashboard genera una credenziale di sessione a breve scadenza anziché inserire un segreto a lunga durata in una pagina. La API descrive il handshake_token della credenziale come "Short-lived token required when upgrading the WebSocket connection". "authorizes the connection only; each call still authenticates with password". Il token di handshake autorizza la connessione, mentre la password autentica ogni chiamata.
La compatibilità del browser dipende dagli algoritmi digest del trunk. I browser rispondono a una sfida digest SIP con MD5 e nient'altro. Un trunk accetta solo gli algoritmi che offre. Un trunk configurato per offrire solo SHA-256 rifiuta quindi ogni chiamata da browser, compreso il telefono della dashboard. Mantenere MD5 nell'offerta è ciò che rende un trunk raggiungibile da un browser, e SIP trunks copre l'impostazione.
La chiamata per il resto arriva sullo stesso trunk, verifica lo stesso caller ID verificato, rispetta le stesse destinazioni abilitate e produce lo stesso record di una chiamata da un PBX, il centralino aziendale che instrada le chiamate di un'azienda.
Quindi quale uso?
Scegli in base a dove gira il tuo endpoint, e aspettati di usare SIP in ogni caso.
WebRTC richiede media cifrato. Il trasporto TLS di un trunk SIP cifra la segnalazione in transito anziché l'audio. Una verifica della crittografia deve quindi coprire entrambi i percorsi.
- Un browser. Una pagina web usa lo stack WebRTC del browser per il media, quindi quella metà è risolta. Scegli tu come segnalare. SIP lo connette alla rete telefonica anziché solo ad altri browser.
- Un telefono fisso, un PBX o un session border controller (SBC), il dispositivo che controlla le chiamate al confine della rete. SIP semplice su UDP, TCP o TLS. WebRTC non ha nulla da offrire a dispositivi che parlano già RTP.
- Un agente vocale AI. Quello che il tuo runtime già implementa. Un agente in un browser o su un runtime costruito sulle API media del browser parlerà WebRTC e ha bisogno della segnalazione. Un agente costruito su uno stack di telefonia parla SIP e RTP direttamente. Cos'è un agente vocale AI copre il resto di quel percorso, inclusa la parte in cui l'agente deve terminare l'audio e non solo la segnalazione.
In breve
La domanda confronta due livelli diversi.
WebRTC è uno stack media per browser senza protocollo di segnalazione. SIP è un protocollo di segnalazione che non trasporta media. Nessuno dei due sostituisce l'altro.
WebRTC esclude la segnalazione di proposito.
La sua stessa panoramica colloca la scelta del protocollo di segnalazione al di fuori dell'ambito della specifica, e indica SIP over WebSockets come un modo standard per colmare il vuoto.
Una chiamata da browser su Bird è una chiamata SIP.
Il browser agisce come client SIP, la connessione viene aggiornata a un WebSocket con un token a breve scadenza, e ogni chiamata si autentica comunque con una password digest.
La crittografia si trova in punti diversi nei due.
WebRTC richiede SRTP per il media. Il trasporto TLS di un trunk SIP cifra la segnalazione, che è una cosa separata dall'audio.