Un navegador y un teléfono de escritorio pueden ser los dos extremos de una misma llamada aunque manejen el medio de forma distinta.
Elegir entre ellos trata funciones asignadas deliberadamente a una capa como si pertenecieran a la otra.
¿Son alternativas?
No. Operan en capas distintas y cada uno deja sin hacer el trabajo del otro.
SIP es señalización. Encuentra el otro extremo, negocia qué medio se intercambiará, hace sonar, conecta y finaliza. No transporta el audio. RFC 3261 traza el límite: "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 es la pila de medios que tiene un navegador. Transporta audio y vídeo entre dos extremos. Atraviesa la traducción de direcciones de red, que es lo que dificulta un camino directo entre navegadores. También cifra el medio. Su propia especificación, RFC 8825, un documento del IETF Standards Track de enero de 2021, indica que el formato de medio es RTP. Requiere SRTP: "Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations".
SIP gestiona llamadas sin transportar medio. WebRTC transporta medio sin gestionar llamadas.
¿Qué deja fuera WebRTC y por qué?
WebRTC deja fuera la señalización, y lo hace deliberadamente: la especificación sitúa la elección de protocolo de señalización fuera de su propio alcance.
RFC 8825 describe la disposición como un trapezoide. El medio viaja directamente entre los dos navegadores. La señalización viaja a través de servidores, que "can modify, translate, or manipulate the signals as needed". La especificación no elige un protocolo de señalización:
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.
No se trata de una omisión pendiente de corregir. Es lo que permite que una aplicación de chat señalice a través de sus propios mensajes WebSocket mientras una plataforma de telefonía señaliza mediante SIP, con la misma pila de medios debajo de ambas. El mismo documento menciona la opción de telefonía directamente, describiendo un despliegue que usa "a standardized signaling mechanism (e.g., SIP over WebSockets)" entre el navegador y el servidor.
SIP sobre WebSocket se especifica en RFC 7118, de enero de 2014, que define "a WebSocket subprotocol as a reliable transport mechanism between SIP entities to enable use of SIP in web-oriented deployments". Cambia cómo viajan los mensajes SIP y no lo que dicen, por lo que un navegador y un teléfono de escritorio pueden ser los dos extremos de una llamada ordinaria.
¿Cómo se ve eso en Bird?
Para conectar un navegador a través de Bird, usa SIP sobre un WebSocket.
El teléfono del propio dashboard es el ejemplo práctico. El navegador actúa como cliente SIP. El dashboard genera una credencial de sesión de corta duración en lugar de enviar un secreto permanente a la página. La API describe el handshake_token de la credencial como un "Short-lived token required when upgrading the WebSocket connection". "authorizes the connection only; each call still authenticates with password". El token de handshake autoriza la conexión, mientras que la contraseña autentica cada llamada.
La compatibilidad con navegadores depende de los algoritmos digest del trunk. Los navegadores responden a un desafío digest SIP con MD5 y nada más. Un trunk solo acepta los algoritmos que ofrece. Un trunk configurado para ofrecer únicamente SHA-256 rechaza toda llamada desde navegador, incluido el teléfono del dashboard. Mantener MD5 en la oferta es lo que hace que un trunk sea accesible desde un navegador, y SIP trunks cubre la configuración.
La llamada, por lo demás, llega al mismo trunk, verifica el mismo identificador de llamante verificado, respeta los mismos destinos habilitados y genera el mismo registro que una llamada desde un PBX, el sistema telefónico empresarial que enruta las llamadas de una empresa.
Entonces, ¿cuál uso?
Elige según dónde se ejecuta tu endpoint, y espera usar SIP en cualquier caso.
WebRTC requiere medio cifrado. El transporte TLS de un trunk SIP cifra la señalización en tránsito en lugar del audio. Por lo tanto, una revisión de cifrado debe cubrir ambas rutas.
- Un navegador. Una página web usa la pila WebRTC del navegador para el medio, así que esa mitad ya está resuelta. Tú eliges cómo señalizarlo. SIP lo conecta a la red telefónica en lugar de solo a otros navegadores.
- Un teléfono de escritorio, un PBX o un controlador de borde de sesión (SBC), que controla las llamadas en un límite de red. SIP estándar sobre UDP, TCP o TLS. WebRTC no tiene nada que ofrecer a equipos que ya hablan RTP.
- Un agente de voz con IA. El que tu entorno de ejecución ya implemente. Un agente en un navegador o en un entorno construido sobre APIs de medios del navegador hablará WebRTC y necesita señalización añadida. Un agente construido sobre una pila de telefonía habla SIP y RTP directamente. Qué es un agente de voz con IA cubre el resto de ese camino, incluida la parte en la que el agente debe terminar el audio y no solo la señalización.
En resumen
La pregunta compara dos capas distintas.
WebRTC es una pila de medios para navegadores sin protocolo de señalización. SIP es un protocolo de señalización que no transporta medios. Ninguno reemplaza al otro.
WebRTC deja fuera la señalización deliberadamente.
Su propia descripción general sitúa la elección de protocolo de señalización fuera del alcance de la especificación, y menciona SIP sobre WebSockets como una forma estándar de cubrir ese vacío.
Una llamada desde navegador en Bird es una llamada SIP.
El navegador actúa como cliente SIP, la conexión se eleva a un WebSocket con un token de corta duración, y cada llamada se autentica con una contraseña digest.
El cifrado se sitúa en lugares distintos en cada uno.
WebRTC requiere SRTP para el medio. El transporte TLS de un trunk SIP cifra la señalización, que es algo independiente del audio.