Een browser en een bureautelefoon kunnen de twee uiteinden van één oproep zijn, ook al gaan ze anders met media om.
Kiezen tussen de twee behandelt functies die bewust aan één laag zijn toegewezen alsof ze bij de andere horen.
Zijn het alternatieven?
Nee. Ze zitten op verschillende lagen en elk laat het werk van de ander ongedaan.
SIP is signalering. Het vindt het andere uiteinde, onderhandelt welke media worden uitgewisseld, laat overgaan, verbindt en breekt af. Het transporteert de audio niet. RFC 3261 trekt de grens: "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 is de mediastack die een browser heeft. Het transporteert audio en video tussen twee eindpunten. Het passeert netwerkadresvertaling, en dat is wat een direct browser-naar-browserpad moeilijk maakt. Het versleutelt ook de media. De eigen specificatie, RFC 8825, een IETF Standards Track-document uit januari 2021, zegt dat het mediaformaat RTP is. Het vereist SRTP: "Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations".
SIP regelt oproepen zonder media te transporteren. WebRTC transporteert media zonder oproepen te regelen.
Wat laat WebRTC weg, en waarom?
WebRTC laat de signalering weg, en doet dat bewust: de specificatie plaatst de keuze van het signaleringsprotocol buiten de eigen scope.
RFC 8825 beschrijft de opzet als een trapezium. De media reist rechtstreeks tussen de twee browsers. De signalering reist via servers, die "can modify, translate, or manipulate the signals as needed". De specificatie kiest geen signaleringsprotocol:
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.
Dat is geen omissie die gerepareerd moet worden. Het is wat een chatapplicatie via eigen WebSocket-berichten laat signaleren terwijl een telefonieplatform via SIP signaleert, met dezelfde mediastack eronder. Hetzelfde document noemt de telefonie-optie expliciet en beschrijft een deployment die "a standardized signaling mechanism (e.g., SIP over WebSockets)" gebruikt tussen de browser en de server.
SIP over WebSocket is gespecificeerd in RFC 7118, uit januari 2014, dat "a WebSocket subprotocol as a reliable transport mechanism between SIP entities to enable use of SIP in web-oriented deployments" definieert. Het verandert hoe SIP-berichten reizen, niet wat ze zeggen, en daarom kunnen een browser en een bureautelefoon de twee uiteinden van één gewone oproep zijn.
Hoe ziet dat eruit op Bird?
Om een browser via Bird te verbinden, gebruik je SIP over een WebSocket.
De eigen telefoon van het dashboard is het uitgewerkte voorbeeld. De browser fungeert als de SIP-client. Het dashboard maakt een kortlevende sessiereferentie aan in plaats van een langlevend geheim in een pagina te laden. De API beschrijft de handshake_token van de referentie als een "Short-lived token required when upgrading the WebSocket connection". Het "authorizes the connection only; each call still authenticates with password". Het handshake-token autoriseert de verbinding, terwijl het wachtwoord elke oproep authenticeert.
Browsercompatibiliteit hangt af van de digest-algoritmen van de trunk. Browsers beantwoorden een SIP-digest-challenge met MD5 en niets anders. Een trunk accepteert alleen de algoritmen die hij aanbiedt. Een trunk die uitsluitend SHA-256 aanbiedt, weigert daarom elke browseroproep, inclusief de telefoon van het dashboard. MD5 in het aanbod houden is wat een trunk vanuit een browser bereikbaar maakt, en SIP-trunks behandelt de instelling.
De oproep komt verder op dezelfde trunk binnen, controleert dezelfde geverifieerde beller-ID, volgt dezelfde ingeschakelde bestemmingen en levert hetzelfde record op als een oproep vanaf een PBX, het bedrijfstelefoonsysteem dat de oproepen van een bedrijf routeert.
Dus wat gebruik je?
Kies op basis van waar je eindpunt draait, en verwacht hoe dan ook SIP te gebruiken.
WebRTC vereist versleutelde media. Het TLS-transport van een SIP-trunk versleutelt de signalering tijdens transport in plaats van de audio. Een encryptiebeoordeling moet daarom beide paden bestrijken.
- Een browser. Een webpagina gebruikt de WebRTC-stack van de browser voor de media, dus die helft ligt vast. Je kiest hoe je signaleert. SIP verbindt de browser met het telefonienetwerk in plaats van alleen met andere browsers.
- Een bureautelefoon, een PBX of een session border controller (SBC), die oproepen op een netwerkgrens beheert. Gewoon SIP over UDP, TCP of TLS. WebRTC heeft niets te bieden aan apparatuur die al RTP spreekt.
- Een spraak-AI-agent. Wat je runtime al implementeert. Een agent in een browser of op een runtime die is gebouwd rond browser-media-API's spreekt WebRTC en heeft signalering nodig. Een agent op een telefoniestack spreekt SIP en RTP rechtstreeks. Wat is een spraak-AI-agent behandelt de rest van dat pad, inclusief het deel waar de agent de audio moet termineren en niet alleen de signalering.
Kort gezegd
De vraag vergelijkt twee verschillende lagen.
WebRTC is een mediastack voor browsers zonder signaleringsprotocol. SIP is een signaleringsprotocol dat geen media transporteert. Geen van beide vervangt de ander.
WebRTC laat signalering bewust weg.
Het eigen overzicht plaatst de keuze van het signaleringsprotocol buiten de scope van de specificatie, en noemt SIP over WebSockets als één standaardmanier om dat gat te vullen.
Een browseroproep op Bird is een SIP-oproep.
De browser fungeert als de SIP-client, de verbinding wordt geüpgraded naar een WebSocket met een kortlevend token, en elke oproep authenticeert zich nog steeds met een digest-wachtwoord.
Encryptie zit bij elk op een andere plek.
WebRTC vereist SRTP voor de media. Het TLS-transport van een SIP-trunk versleutelt de signalering, en dat is iets anders dan de audio.