WebRTC vs SIP: diferencias y casos de uso

WebRTC y SIP transportan voz en tiempo real, pero fueron diseñados para mundos diferentes. SIP surgió del ecosistema de telefonía de operadores y empresas, donde la señalización estandarizada entre proveedores y la interconexión limpia con la PSTN son la razón de ser del protocolo. WebRTC surgió del navegador, donde el objetivo era permitir que dos páginas web intercambiaran medios entre sí sin que nadie instalara un complemento. El resultado son dos ecosistemas que se superponen en capacidades pero discrepan en casi todas las decisiones arquitectónicas subyacentes.

Esta guía es una comparación orientada a la toma de decisiones. Cubre qué es realmente cada tecnología, en qué difieren en la práctica (señalización, transporte, cifrado, identidad, recorrido de NAT), los casos de uso en los que cada una gana y qué cambia cuando deben comunicarse entre sí a través de un límite de red. Si desea conocer los mecanismos del protocolo SIP en sí, el artículo complementario Fundamentos de señalización SIP cubre los roles y la arquitectura del protocolo a un nivel más alto, y Flujo de llamada SIP explicado paso a paso recorre los mensajes en la red. Este artículo asume ese conocimiento previo y se centra en cómo se compara WebRTC.

Un tema que este artículo no cubre es la arquitectura completa de implementación de un gateway WebRTC-a-SIP. Ese tema merece un tratamiento propio, y un artículo dedicado a la arquitectura de gateway seguirá a continuación. Aquí mantenemos la discusión sobre gateways al nivel necesario para tomar decisiones, no para configurar un despliegue.

Qué es realmente WebRTC

WebRTC es un conjunto de APIs de navegador (y un conjunto correspondiente de protocolos de red) que permite a una aplicación web capturar un micrófono o cámara, cifrar el flujo y enviarlo a otro endpoint sin complementos ni cliente instalado. El modelo mental del lector debería ser: una API JavaScript en el navegador, una pila de medios fija por debajo y una pieza explícitamente ausente por encima.

La pila de medios fija es opinionada. El transporte es UDP. El cifrado de medios es SRTP, y es obligatorio; no existe un modo sin cifrar. El intercambio de claves utiliza DTLS-SRTP, realizado en la propia ruta de medios. El recorrido de NAT está integrado a través de ICE, STUN y TURN, que juntos permiten a dos navegadores detrás de NAT separados encontrar una ruta funcional o recurrir a un relay. Los códecs están limitados a un conjunto reducido, con Opus como valor predeterminado de audio y VP8/VP9/H.264/AV1 en el lado de video.

La pieza ausente es la señalización. WebRTC omite deliberadamente cómo dos endpoints se encuentran, intercambian descripciones de sesión o descubren los candidatos ICE del otro. Eso queda a cargo de la aplicación, que normalmente transporta los mensajes de señalización a través de WebSocket, un esquema HTTP personalizado o cualquier otro canal que el desarrollador elija. Esta es la diferencia arquitectónica más importante respecto a SIP. SIP es un protocolo de señalización; WebRTC no tiene ninguno.

La consecuencia práctica es que dos navegadores que ejecutan la misma aplicación web pueden comunicarse de extremo a extremo, pero dos navegadores que ejecutan aplicaciones diferentes no pueden. No existe un equivalente WebRTC de “marcar cualquier URI SIP”. La federación ocurre en la capa de aplicación, no en la capa de protocolo.

Las diferencias principales

La siguiente tabla resume las decisiones arquitectónicas que toma cada tecnología. La mayoría de las compensaciones en las secciones posteriores se remiten a una de estas filas.

Dónde difieren las arquitecturas en la práctica

La tabla es un resumen preciso, pero las consecuencias solo se hacen visibles cuando se analiza cómo cada decisión de diseño se manifiesta en un despliegue real.

WebRTC no tiene protocolo de señalización

Esta es la diferencia estructural de la que se derivan todas las demás. Una aplicación WebRTC elige su propio transporte de señalización (típicamente WebSocket con JSON), define sus propios formatos de mensaje y enruta los mensajes entre usuarios a través de su propio backend. Si la aplicación desaparece, la señalización desaparece con ella. SIP es lo contrario. La señalización es el estándar, y cualquier endpoint compatible puede comunicarse con cualquier otro endpoint compatible sin coordinarse previamente con la aplicación que lo construyó.

Esa propiedad es la razón por la que SIP es el protocolo de interconexión. Dos operadores, dos proveedores de PBX, o un PBX y una plataforma UCaaS alojada pueden intercambiar llamadas sin compartir código de aplicación. WebRTC no tiene equivalente.

SIP desacopla señalización y medios; WebRTC los une por diseño

En SIP, la ruta de señalización y la ruta de medios son independientes. SIP negocia la sesión (sobre UDP, TCP o TLS), y RTP o SRTP fluye directamente entre los endpoints en un conjunto diferente de puertos. Los medios pueden tomar una ruta completamente diferente a través de la red respecto a la señalización, y frecuentemente lo hacen.

En WebRTC, la ruta de medios está completamente especificada por la pila de protocolos: UDP, candidatos ICE negociados a través de la señalización, handshake DTLS en el socket de medios, claves SRTP derivadas de ese handshake. La señalización es independiente en el sentido de que la aplicación la controla, pero la ruta de medios está rígidamente definida y se asume de extremo a extremo entre los dos endpoints PeerConnection.

Cifrado obligatorio vs cifrado opcional

Los medios WebRTC siempre están cifrados. No hay forma de negociar RTP sin cifrar entre dos peers WebRTC. El intercambio de claves ocurre a través de DTLS-SRTP en el socket de medios, lo que elimina la dependencia de la seguridad en la capa de señalización para la confidencialidad de las claves.

SIP permite medios cifrados (SRTP, normalmente con claves intercambiadas mediante SDES dentro de un cuerpo SDP que viaja sobre señalización protegida con TLS) pero no lo requiere. Una cantidad considerable de tráfico de operadores y trunks todavía se mueve como RTP sin cifrar porque el operador considera la red como confiable. Para más información sobre cómo difiere el intercambio de claves SRTP entre SDES y DTLS-SRTP, consulte ¿Qué es SRTP?.

Identidad y confianza

SIP tiene mecanismos de identidad explícitos. El encabezado P-Asserted-Identity transporta una identidad de llamante asertada dentro de una red de confianza, el encabezado SIP Identity (utilizado por STIR/SHAKEN) certifica criptográficamente el número del llamante, y los operadores mantienen relaciones de confianza que dan significado a esos encabezados. WebRTC no tiene nada de eso a nivel de protocolo. La identidad en una aplicación WebRTC es lo que la aplicación decida imponer, normalmente un token de inicio de sesión vinculado a una cuenta de usuario en el mismo backend que maneja la señalización.

Esto importa cuando el tráfico WebRTC termina tocando la PSTN. Un framework de mitigación de llamadas no deseadas como STIR/SHAKEN tiene sentido dentro de SIP. No lo tiene para una llamada de navegador a navegador entre dos usuarios de la misma aplicación.

Filosofía de recorrido de NAT

SIP asume que el operador de red resolverá el NAT. La respuesta clásica es colocar un SBC en el borde para que los endpoints internos se registren con un elemento de cara pública que gestione los keepalives de NAT, la reescritura de direcciones y el recorrido de NAT en el extremo remoto. Los ALG de SIP en firewalls intentan hacer algo similar en despliegues más pequeños, frecuentemente con resultados mixtos.

WebRTC asume que los propios endpoints resolverán el NAT. ICE recorre cada par de direcciones candidatas (host, server-reflexive vía STUN, retransmitida vía TURN), las prueba y selecciona la mejor. Un servidor TURN es el respaldo cuando las rutas directas fallan, y en muchos despliegues grandes TURN termina transportando una fracción sustancial de los medios. El beneficio es que el protocolo funciona prácticamente en cualquier lugar; el costo es que los operadores deben ejecutar infraestructura STUN y TURN.

Casos de uso donde SIP gana

SIP es el protocolo al que se recurre siempre que una llamada necesita salir de una organización y llegar a otra, siempre que toca la PSTN, o siempre que un equipo espera interconectarse con algo diferente a una copia de sí mismo.

• La interconexión entre operadores y el acceso a la PSTN son los casos de uso originales. Cada operador Tier 1, cada ITSP y cada conmutador Class 4/5 en producción hoy habla SIP o su variante SIP-I.
• Microsoft Teams Direct Routing es una integración SIP. Teams Phone utiliza señalización SIP hacia el SBC y SRTP en la ruta de medios, con el SBC traduciendo entre el dialecto SIP de Teams y lo que el operador entrega. Los mecanismos completos se cubren en ¿Qué es Teams Direct Routing?.
• La telefonía empresarial multi-proveedor depende de SIP para que un IP-PBX de un fabricante, una plataforma de contact center de otro y un session border controller de un tercero puedan compartir trunks.
• Los despliegues de IP-PBX y SIP trunking asumen SIP de extremo a extremo. Incluso cuando los teléfonos de escritorio son softphones y el trunk se entrega por internet, la señalización bajo la aplicación es SIP.
• El trunking de contact center a escala, incluyendo BYOC hacia Genesys, Five9 o NICE, utiliza SIP porque el lado del operador no tiene otra forma de entregar las llamadas entrantes.

Donde hay un plan de numeración, un operador o un PBX, SIP es la respuesta.

Casos de uso donde WebRTC gana

La fortaleza de WebRTC es llegar al usuario sin pedirle que instale nada. En cualquier lugar donde el endpoint es un navegador, un dispositivo del cliente que el operador no controla, o una aplicación móvil que necesita una pila de medios pequeña y predecible, WebRTC tiende a ser la elección correcta.

• Los softphones basados en navegador para empleados internos o agentes remotos eliminan por completo el problema del cliente de escritorio. Una URL y un inicio de sesión son la única superficie de despliegue.
• Click-to-call desde una página de marketing conecta a un visitante del sitio web con una cola de ventas o soporte sin software de marcación en el lado del visitante.
• Los escritorios de agente de contact center en el navegador permiten a los agentes gestionar llamadas dentro de la misma pestaña de CRM en la que trabajan todo el día, eliminando un cliente de softphone independiente.
• El soporte de voz y video en vivo para clientes se integra directamente en aplicaciones móviles y flujos web; los usuarios no cambian de contexto para iniciar una llamada.
• Las aplicaciones de colaboración interna (la categoría amplia que incluye Google Meet, Discord, el cliente web de Zoom) utilizan WebRTC porque el costo de distribuir un cliente nativo a cada participante de una reunión es inaceptable.
• Los escenarios de incorporación con baja fricción como visitas de telemedicina, consultas de asesoría financiera o plataformas de entrevistas se benefician del acceso sin instalación para la parte orientada al cliente.

El patrón común es que un lado de la conversación es una persona en internet abierto a la que no se le debe pedir que instale software. WebRTC es el protocolo diseñado para ese lado.

Cuando deben comunicarse entre sí

La mayoría de los despliegues del mundo real son mixtos. Un softphone basado en navegador necesita llegar a la PSTN. Un cliente web de contact center necesita enrutar llamadas entrantes desde un trunk SIP. Un widget click-to-call necesita ingresar en una cola servida por un ACD tradicional. En esos puntos, los dos mundos deben encontrarse, y cuatro elementos deben traducirse en el límite.

La señalización es la primera traducción. El lado WebRTC habla lo que la aplicación eligió (comúnmente WebSocket transportando SIP-sobre-WebSocket según RFC 7118, o un protocolo JSON propietario). El lado SIP habla SIP estándar sobre UDP, TCP o TLS. Un gateway termina ambos y los mapea entre sí.

El cifrado de medios es la segunda. WebRTC requiere DTLS-SRTP. El lado SIP puede entregar SRTP con claves SDES, o RTP sin cifrar. El gateway termina el handshake DTLS hacia el navegador y reasigna las claves de medios en el otro tramo según lo que el peer SIP requiera.

El códec es la tercera. Los navegadores usan Opus por defecto; la PSTN y la mayoría de los trunks SIP usan G.711 por defecto. Si ambos lados soportan un códec común, la llamada pasa directamente; de lo contrario, el gateway realiza transcodificación o rechaza la llamada. La transcodificación de Opus a G.711 no es gratuita; requiere capacidad DSP de hardware en plataformas como ProSBC (el complemento TSBC-HW-TRANS).

El recorrido de NAT es la cuarta. El lado WebRTC ejecuta ICE contra la dirección alcanzable del gateway. El lado SIP no lo hace; el gateway termina ICE en el tramo del navegador y presenta un endpoint SIP/RTP estático al operador o PBX.

Un SBC de estilo B2BUA es el ajuste arquitectónico correcto para este límite porque termina completamente ambos tramos y otorga al operador control total sobre cada encabezado, códec y contexto criptográfico. Un proxy SIP no puede hacer este trabajo; los tramos son demasiado diferentes. Un artículo dedicado a la arquitectura de gateway cubrirá los detalles de implementación (traducción de señalización, terminación de ICE, ubicación de transcodificación, escalabilidad).

Dónde encaja ProSBC

ProSBC es un SBC B2BUA de software que termina el lado SIP de los despliegues donde el tráfico WebRTC llega desde aguas arriba. El rol típico es el tramo SIP-a-operador (o SIP-a-PBX): el gateway orientado a WebRTC entrega una sesión SIP normalizada a ProSBC, y ProSBC gestiona la interoperabilidad con el operador, la terminación de TLS y SRTP hacia el trunk, la normalización de encabezados SIP para el lado PSTN y la ocultación de topología entre la nube y el operador.

En ese tramo, ProSBC proporciona TLS 1.3 para la señalización SIP y SRTP (retransmisión o conversión de RTP a SRTP) para los medios, con configuración de transporte y criptografía por grupo de trunks. El motor de manipulación de encabezados SIP gestiona las diferencias entre lo que un CPaaS o gateway WebRTC produce y lo que un operador espera recibir.

ProSBC por sí mismo puede realizar transcodificación para los códecs G.711 A-law y mu-law. Para mayor soporte de códecs, ProSBC trabaja en conjunto con una unidad de hardware TSBC-HW-TRANS para garantizar que todos los sistemas logren una negociación y traducción de códecs en “tiempo real” para cada llamada individual.

ProSBC no incluye un registrador SIP integrado y no es el producto adecuado para el tramo orientado a WebRTC en sí. El gateway orientado al navegador (un servidor de aplicaciones o un gateway compatible con WebRTC como Janus o Kamailio con el módulo WebSocket) se ubica delante. ProSBC se ubica detrás, en el lado SIP.