Arquitectura de gateway WebRTC a SIP: componentes, traducción de protocolos y patrones de implementación

Un gateway WebRTC a SIP es el elemento de red que permite que una aplicación de voz o video basada en navegador alcance la PSTN, un troncal SIP, una PBX o cualquier par SIP externo. Se ubica en un límite donde dos pilas de comunicación en tiempo real que difieren en señalización, transporte, cifrado, travesía de NAT e identidad deben compartir una llamada.

El artículo complementario WebRTC vs SIP: diferencias y casos de uso cubre qué es cada tecnología y cuándo elegir una u otra. Este artículo asume ese contexto y profundiza un nivel más: los subsistemas con los que se construye un gateway, cómo funciona cada traducción en la red y cómo los componentes se integran en una implementación en producción. Para la mecánica del protocolo SIP que este artículo da por conocida, Fundamentos de señalización SIP y Flujo de llamada SIP explicado paso a paso son las referencias complementarias.

Qué tiene que hacer realmente el gateway WebRTC a SIP

Una PeerConnection WebRTC y un diálogo SIP se parecen vistos desde lejos: ambos negocian una sesión de medios entre dos terminales, ambos transportan RTP cifrado, ambos funcionan sobre UDP. De cerca, apenas se solapan. Un gateway tiene que resolver cinco problemas de traducción en el límite, y cada uno necesita su propio subsistema.

Traducción de señalización mapea la señalización de la aplicación en el lado WebRTC (típicamente WebSocket que transporta SIP sobre WebSocket o un protocolo JSON propietario) a SIP estándar en el lado del operador.

Terminación de travesía de NAT recibe candidatos ICE en el tramo del navegador, presenta una única dirección estática en el tramo SIP y ejecuta la infraestructura STUN/TURN para el lado WebRTC.

Traducción del cifrado de medios termina DTLS-SRTP hacia el navegador y regenera las claves de los medios en el tramo SIP usando lo que el par espere: SRTP vía SDES, DTLS-SRTP nuevamente o RTP sin cifrar.

Mediación de códec maneja la diferencia entre Opus (el códec predeterminado de WebRTC) y G.711 o G.729 (los predeterminados de SIP), ya sea mediante negociación SDP o transcodificación activa.

Puente de identidad asigna una identidad en el tramo SIP saliente sobre la cual los sistemas posteriores puedan actuar (identificador de llamante, firma STIR/SHAKEN), porque WebRTC no tiene nada a nivel de protocolo que pueda trasladarse.

El resto de este artículo recorre cada uno de estos subsistemas y luego los reúne en las topologías de implementación que realmente aparecen en producción.

Traducción de señalización

WebRTC no tiene un protocolo de señalización definido. La aplicación elige uno. En la práctica, dominan dos patrones.

SIP sobre WebSocket (RFC 7118)

Esta ruta ejecuta el protocolo SIP a través de una conexión WebSocket entre el navegador y el gateway. El navegador usa una biblioteca SIP en JavaScript (JsSIP, SIP.js); el gateway termina el WebSocket, analiza la pila SIP encima y recodifica los mismos mensajes en un socket SIP normal sobre UDP, TCP o TLS hacia el operador. La traducción es estructuralmente simple porque ambos lados hablan SIP; solo cambia el transporte. Kamailio (con el módulo websocket), OpenSIPS y Janus en modo gateway SIP implementan este patrón.

JSON propietario sobre WebSocket

Esto es lo que usan la mayoría de los SDK a nivel de aplicación, incluyendo Twilio Programmable Voice, Vonage, Zoom Phone y pilas CPaaS personalizadas. El navegador envía mensajes como {"type": "invite", "callee": "...", "sdp": "..."} y el backend de la aplicación los traduce internamente a SIP. En este caso, el gateway es parte del propio backend, y el límite SIP es interno a la plataforma.

Qué tiene que manejar la traducción de señalización que SIP no maneja

Modificación de SDP cubre las diferencias entre el SDP que produce un navegador y el SDP que espera un operador. La oferta del navegador lista todos los candidatos ICE descubiertos, declara DTLS-SRTP como obligatorio y anuncia Opus. El operador espera un SDP sin atributos ICE, con claves SDES (o RTP sin cifrar) y una lista de códecs diferente. El gateway reescribe el SDP completamente en cada tramo, presentando una forma al navegador y otra al operador.

Trickle ICE es relevante porque WebRTC descubre candidatos ICE de forma asíncrona y los envía al par a medida que aparecen, después de la oferta inicial. El gateway tiene que aceptar estos candidatos enviados progresivamente, pero SIP no tiene un mecanismo equivalente, así que la oferta del lado SIP espera a que ICE se complete (end-of-candidates) u omite ICE por completo y usa una única dirección estática.

Manejo de re-INVITE se convierte en un problema de traducción porque los cambios a mitad de llamada (retención, silencio, cambio de códec, transferencia) llegan como renegociación en ambos lados pero con formas diferentes. El gateway tiene que mapear entre ellos sin cortar la llamada. Consulte Flujo de llamada SIP explicado para ver cómo funciona re-INVITE en el lado SIP.

Travesía de NAT y terminación de ICE

WebRTC asume que los terminales resolverán NAT por sí mismos. SIP asume que lo hará el operador de red. El gateway tiene que conciliar ambas filosofías, y lo hace ejecutando ICE completo en un tramo y ningún ICE en el otro.

En el tramo del navegador, el gateway ejecuta ICE completo. Anuncia sus propios candidatos ICE (host, server-reflexive vía STUN, retransmitidos vía TURN), prueba la conectividad contra los candidatos del navegador y selecciona la mejor ruta. Si las rutas directas fallan, el propio servidor TURN del gateway retransmite los medios. Esto significa que el operador debe implementar y escalar infraestructura TURN en proporción al tráfico WebRTC; en implementaciones donde la mayoría de los navegadores están detrás de NAT corporativo restrictivo, TURN puede transportar una parte significativa de los bytes de medios.

En el tramo SIP, el gateway presenta una única IP estática y un puerto al operador. No hay ICE en este tramo; el operador espera un socket RTP fijo en la dirección pública del gateway. El gateway es responsable de mantener ese socket accesible a través de cualquier NAT o firewall que tenga delante, que es el mismo problema que cualquier SBC resuelve con ocultación de topología y manejo de NAT del extremo remoto.

La asimetría es intencional. ICE traslada la complejidad a los terminales cuando ambos son inteligentes (dos navegadores). En un límite de operador, donde un lado es un conmutador de hardware que no ha cambiado en quince años, el gateway absorbe la complejidad en su lugar.

Cifrado de medios: la transferencia DTLS-SRTP

Esta es la parte más interesante del gateway desde el punto de vista criptográfico. Los dos tramos utilizan mecanismos de intercambio de claves diferentes, y el gateway es el límite de confianza entre ellos.

En el tramo del navegador, el gateway actúa como respondedor DTLS. Después de que ICE selecciona una ruta, el navegador inicia un handshake DTLS en el mismo socket UDP por el que viajarán los medios. El gateway presenta un certificado (autofirmado es aceptable; la huella digital viaja en el SDP), completa el handshake y deriva las claves maestras SRTP de las claves de sesión DTLS a través de la API export_keying_material. Los medios que fluyen desde el navegador se cifran con esas claves.

En el tramo SIP, el gateway negocia SRTP de manera diferente. El patrón más común es SDES, donde la clave maestra se incorpora directamente en el cuerpo SDP y el cuerpo está protegido por TLS en el canal de señalización. Con menor frecuencia, el par SIP también habla DTLS-SRTP, en cuyo caso el gateway ejecuta un segundo handshake DTLS saliente. El patrón menos seguro es RTP sin cifrar, donde no se negocia ningún cifrado; el gateway cifra el tramo del navegador y descifra en el tramo SIP.

Cualquiera que sea la combinación aplicable, el gateway mantiene dos contextos SRTP independientes al mismo tiempo y recifra cada paquete al cruzar el límite. Los propios paquetes cambian: los valores SSRC se reescriben, los números de secuencia se reinician y las claves son completamente diferentes en cada lado. No hay intercambio de claves entre los tramos; ese es precisamente el objetivo.

Mediación de códec y ubicación de la transcodificación

Opus es el códec predeterminado de WebRTC. G.711 (mu-law o A-law) es el predeterminado de la PSTN. El gateway tiene tres opciones cuando una llamada cruza el límite.

Negociar un códec común. Si el operador admite Opus en el troncal SIP (la mayoría no lo hace) y el navegador admite G.711 (la mayoría sí), el gateway puede pasar el audio sin transcodificación. Algunas implementaciones de MSP y CPaaS configuran esto para evitar el costo de transcodificación por completo.

Transcodificar. El gateway decodifica el RTP entrante, recodifica con el códec saliente y reenvía el nuevo flujo. Opus a G.711 es el caso común. Para una vista ampliada de cómo funciona la transcodificación en el borde del SBC, el artículo Transcodificación SBC de AMR a G.711 recorre el mismo ciclo de decodificación/recodificación para códecs de redes móviles.

Rechazar la llamada. Si ningún lado puede negociar algo que el otro acepte (raro pero posible con troncales que solo admiten G.729), el gateway devuelve 488 Not Acceptable Here.

La ubicación de la transcodificación dentro de la arquitectura del gateway tiene consecuencias prácticas. La transcodificación por software en CPU de propósito general es adecuada para G.711 a G.711 (A-law a mu-law es esencialmente gratuito) y para capacidad limitada de Opus. La transcodificación de alta densidad de Opus a G.711 está dominada por aritmética DSP, y la mayoría de las implementaciones de nivel operador descargan este trabajo a hardware dedicado para mantener margen de CPU disponible para las demás responsabilidades del gateway.

Para un SBC ubicado en el tramo SIP de una implementación de dos niveles, la ubicación correcta suele ser mantener la transcodificación G.711 en software (A-law a mu-law se admite de forma nativa en ProSBC) y descargar AMR y G.729 a una unidad de transcodificación por hardware como TSBC-HW-TRANS. El códec en el tramo entrante de WebRTC es el que determina el requisito de DSP, no el códec del lado SIP.

Puente de identidad

WebRTC no tiene identidad a nivel de protocolo. La aplicación asigna la identidad en su propio backend, generalmente con un token de inicio de sesión vinculado a una cuenta de usuario. Cuando esa llamada cruza a SIP, el operador necesita algo concreto para colocar en el encabezado From, el encabezado P-Asserted-Identity y (en Estados Unidos) el encabezado de identidad STIR/SHAKEN.

El gateway resuelve esto mapeando la identidad del usuario WebRTC a una identidad SIP en el límite. El gateway se configura con una identidad de troncal SIP (un número de servicio, un rango DID o una identidad asignada por el B2BUA) y estampa el INVITE saliente con esa identidad, más la certificación por llamada de que el gateway ha autenticado al usuario en la etapa previa.

Para STIR/SHAKEN, el gateway puede firmar con nivel de certificación A solo cuando opera como el operador de origen. Si el gateway entrega a un operador que firma, el gateway proporciona la identidad de origen y el servicio de firma del operador produce el encabezado Identity. ProSBC se integra con TransNexus ClearIP y Neustar sobre SIP para exactamente este patrón: el gateway enruta la llamada a un NAP cuyo service_type es AUTHENTICATION, ClearIP devuelve un 302 con el encabezado Identity adjunto y la llamada avanza hacia el operador. La mecánica de normalización de encabezados que transportan identidad entre dialectos SIP de distintos proveedores se cubre en Manipulación de encabezados SIP.

Lo que no se puede trasladar: los tokens de identidad WebRTC (JWT, flujos OAuth) no sobreviven al límite SIP. La confianza que el backend de la aplicación estableció se intercambia por la propia relación de confianza del gateway con el operador.

Topologías de implementación

Tres patrones dominan en producción. La elección depende de la escala, de si la implementación necesita conferencia multiparte y de si el operador quiere un solo elemento haciendo todo o elementos especializados haciendo una tarea cada uno.

Gateway de un solo nivel

Un único dispositivo termina el lado WebRTC, realiza la traducción y presenta una interfaz SIP al operador. Janus con el plugin SIP, Kamailio con los módulos websocket y rtpengine, y varios appliances de proveedores CPaaS siguen este patrón. La ventaja es la simplicidad operativa: una sola caja que escalar y monitorear. La desventaja es que el gateway tiene que hacer todo, incluida la transcodificación con uso intensivo de DSP y el trabajo de SBC en el lado del operador (manipulación de encabezados, protección contra fraude, ocultación de topología, absorción de registrar). A pequeña escala esto es aceptable; a escala de operador consolida demasiada responsabilidad en un solo elemento.

Dos niveles: gateway WebRTC delante de un SBC

Este es el patrón de producción más común. Un gateway WebRTC dedicado maneja el tramo orientado al navegador: terminación de WebSocket, ICE, DTLS-SRTP, TURN, envío progresivo de candidatos ICE y asignación de identidad desde el backend de la aplicación. El gateway luego entrega una sesión SIP normalizada a un SBC que maneja el tramo orientado al operador: SIP sobre TLS, SRTP con SDES, normalización de encabezados, ocultación de topología, control de admisión de llamadas, puntuación de fraude e integración STIR/SHAKEN. La separación permite que cada elemento se especialice y escale independientemente del otro.

ProSBC encaja en este patrón del lado SIP. No es un gateway orientado a WebRTC y no termina señalización WebSocket; el gateway WebRTC delante de él (Janus, Kamailio, OpenSIPS o un servidor de aplicaciones CPaaS) maneja el lado del navegador. ProSBC maneja todo lo que está detrás: TLS para señalización SIP, SRTP para medios (retransmisión o conversión de RTP a SRTP), manipulación de encabezados SIP por grupo de troncales para cumplir lo que cada operador espera, ocultación de topología entre la zona WebRTC y el operador, e integración con detección de fraude y socios STIR/SHAKEN.

Topología de implementación en dos niveles: un gateway WebRTC maneja el tramo orientado al navegador (señalización WebSocket, ICE, DTLS-SRTP, TURN) y luego entrega una sesión SIP normalizada a ProSBC, que maneja el tramo orientado al operador (SIP/TLS, SRTP, manipulación de encabezados SIP, ocultación de topología, integración de fraude y STIR/SHAKEN). Haga clic para ampliar.

Tres niveles con servidor de medios

Para implementaciones que necesitan conferencia multiparte, un SFU (Selective Forwarding Unit) o MCU (Multipoint Control Unit) se ubica entre el navegador y el gateway. El SFU maneja el procesamiento de la conferencia (reenvío de flujos de video a todos los participantes y mezcla de flujos de audio entre participantes), y el gateway conecta la salida SIP del SFU con el operador cuando la conferencia incluye un participante de la PSTN. Esta es la arquitectura detrás de la conferencia con acceso telefónico para la mayoría de las grandes plataformas de reuniones e implementaciones de centros de contacto.

El patrón de tres niveles agrega un SFU entre el clúster de navegadores y el gateway WebRTC, con el resto de la ruta SIP sin cambios.

Escalamiento: TURN, señalización y medios

Cada subsistema escala en un eje diferente, y la planificación de capacidad de uno no dice mucho sobre la planificación de capacidad de otro.

Ancho de banda de TURN es la partida más variable. Una ruta directa del navegador al gateway no usa ancho de banda TURN. Un navegador detrás de un NAT simétrico o un firewall corporativo restrictivo retransmite a través de TURN durante toda la duración de la llamada, y el servidor TURN asume los bytes en ambas direcciones. Planifique la capacidad de TURN para la fracción de usuarios del peor caso que no pueden encontrar una ruta directa, no para el promedio. En implementaciones con tráfico empresarial significativo, esa fracción supera regularmente el 20 por ciento.

Capacidad de señalización en el gateway está limitada por la densidad de conexiones WebSocket, no por el volumen de mensajes. Cada navegador conectado mantiene un WebSocket abierto; decenas de miles de WebSocket inactivos en un solo host son factibles si la memoria se provisiona correctamente. La traducción de señalización en sí es barata por mensaje, pero las conexiones de larga duración dominan.

Capacidad de medios escala con la carga de transcodificación por llamada. La retransmisión pura (sin transcodificación, ambos lados con el mismo códec) escala cerca de la tasa de línea de la red. La transcodificación de Opus a G.711 está limitada por ciclos DSP o CPU; la densidad publicada para transcodificadores de hardware alcanza miles de sesiones concurrentes por servidor de procesamiento de medios, mientras que la transcodificación por software es típicamente una fracción de eso.

Del lado SIP, ProSBC maneja hasta 60 000 sesiones de señalización concurrentes por servidor con transcodificación por software solo para G.711; AMR y G.729 requieren una unidad de transcodificación por hardware. Combinar ambos de forma limpia es lo que permite que una implementación de dos niveles escale el plano de medios independientemente del plano de señalización: el gateway WebRTC se dimensiona para densidad de WebSocket y throughput de TURN, mientras que el SBC se dimensiona para sesiones SIP y (cuando están presentes) unidades de transcodificación.

Alta disponibilidad y observabilidad

Un gateway WebRTC a SIP se ubica en la ruta crítica de voz, lo que significa que cada componente necesita un par redundante y los modos de falla deben ser visibles desde ambos lados.

Para alta disponibilidad, el gateway WebRTC puede funcionar en activo-activo detrás de un balanceador de carga porque las conexiones WebSocket son independientes y sin estado desde la perspectiva del clúster. Los servidores TURN típicamente están en activo-activo detrás de anycast o DNS round-robin. El SBC en el tramo SIP está más frecuentemente en activo-standby con una IP virtual. ProSBC soporta HA 1+1 en activo-standby para máximo tiempo de actividad, con la salvedad de que la conmutación por error no es sin pérdida; algunas llamadas en curso se interrumpen durante el cambio, y la implementación debe estar diseñada para reintentarlas rápidamente en lugar de prevenir la interrupción.

Para observabilidad, la trazabilidad a través de los tramos es el problema difícil. Una llamada que falla entre un navegador y un destino PSTN toca el backend de la aplicación, el gateway WebRTC, el SBC y el operador; cada componente registra en su propio formato, y correlacionar una sola llamada a través de todos ellos requiere propagar un identificador de llamada en cada salto. La práctica estándar es inyectar un identificador único como encabezado SIP en el tramo SIP y un campo personalizado en la señalización de la aplicación en el tramo WebRTC, y luego exponer ambos en registro centralizado.

ProSBC expone métricas por NAP y por llamada (CPS, ASR, ABR, PDD, jitter) a través de su REST API y puede dirigirlas a la plataforma de observabilidad que el cliente elija. Mejores prácticas de monitoreo VoIP cubre qué significan esas métricas y qué umbrales importan en una implementación de voz en producción.

Preguntas frecuentes

Conclusión

Un gateway WebRTC a SIP es el elemento de límite que permite que dos pilas en tiempo real compartan una llamada sin que ningún lado conozca las decisiones de protocolo del otro. El gateway se construye a partir de cinco subsistemas: traducción de señalización, terminación de ICE, regeneración de claves DTLS-SRTP, mediación de códec y puente de identidad. Cada uno tiene su propio perfil de escalamiento, y la implementación de producción más común los divide en dos niveles: un gateway WebRTC dedicado en el lado del navegador y un SBC en el lado del operador, para que cada elemento se especialice en el trabajo que mejor hace.

Al evaluar componentes de gateway para una implementación en producción, las preguntas que debe hacer son: qué lado termina cada elemento, dónde reside la transcodificación (hardware o software), cómo se dimensionan TURN y la capacidad de señalización de forma independiente, y cómo se traslada la identidad a través del límite hacia la firma STIR/SHAKEN. Las respuestas determinan si la implementación es un appliance de un solo nivel, una división de dos niveles o una topología de conferencia de tres niveles.