Guía de configuración de TLS y SRTP en el SBC: protección de la señalización SIP y los medios de voz

La señalización SIP viaja en texto plano de forma predeterminada. Lo mismo ocurre con el audio. Sin cifrado, cualquier persona con acceso a la ruta de red entre dos endpoints puede capturar mensajes SIP, extraer metadatos de llamadas y reconstruir conversaciones de voz completas a partir de paquetes RTP capturados.
Transport Layer Security (TLS) y Secure Real-time Transport Protocol (SRTP) resuelven estos problemas, pero protegen aspectos diferentes. TLS cifra el canal de señalización (los mensajes SIP que establecen, modifican y finalizan las llamadas). SRTP cifra el canal de medios (los paquetes de voz en sí). Un Session Border Controller (SBC) es el elemento de red que aplica ambos protocolos en el borde de la red de voz.
Esta guía cubre los pasos prácticos para configurar TLS y SRTP en un SBC: cómo dependen el uno del otro, dónde deben ubicarse los límites de cifrado en la arquitectura de red, cómo manejar entornos mixtos con equipos heredados, y cómo solucionar los problemas de implementación más comunes.

Por qué SRTP debe implementarse junto con TLS

Es tentador tratar TLS y SRTP como simplemente complementarios. No lo son. La seguridad de uno depende del otro, y desplegar SRTP sin TLS crea una falsa sensación de seguridad.
He aquí el motivo. El mecanismo de intercambio de claves SRTP más común, SDP Security Descriptions (SDES, definido en RFC 4568), embebe las claves de cifrado directamente en el cuerpo SDP de los mensajes SIP. Cuando un endpoint envía un SIP INVITE para establecer una sesión de medios cifrada, la oferta SDP incluye un atributo crypto que contiene la clave SRTP en codificación base64.
Si ese SIP INVITE viaja sobre UDP o TCP sin cifrar, las claves SRTP son visibles para cualquier persona que pueda capturar el tráfico de señalización. Un atacante que intercepte el intercambio SIP puede extraer las claves y usarlas para descifrar todos los paquetes de medios SRTP de la sesión. El cifrado de voz se vuelve inútil.
TLS evita esto cifrando el mensaje SIP completo, incluido el cuerpo SDP y sus atributos crypto. Con TLS activo, un atacante que capture tráfico en la ruta de señalización solo verá la sesión TLS cifrada, sin el contenido SIP ni las claves SRTP que contiene.
La regla de implementación es simple: nunca despliegue SRTP sobre señalización SIP sin cifrar en un entorno de producción. El SBC es el lugar adecuado para aplicar esta regla, ya que termina y reorigina tanto la señalización como los medios en el borde de la red.

Arquitectura: dónde vive el cifrado en su red

Un ProSBC que opera como Back-to-Back User Agent (B2BUA) termina sesiones SIP en cada lado de forma independiente. Esta arquitectura es fundamental para el cifrado porque significa que el SBC gestiona dos contextos de seguridad completamente separados: uno para cada tramo de la llamada.
En el tramo externo (hacia un proveedor de SIP trunk o un operador), el SBC puede aplicar TLS y SRTP. En el tramo interno (hacia su IP-PBX, contact center o endpoint), el SBC puede usar el transporte que admita el equipo interno. Los dos tramos son independientes, cada uno con su propia política de cifrado.
Esto crea tres patrones de implementación prácticos.

Patrón 1: cifrado de extremo a extremo

Ambos lados del SBC soportan TLS y SRTP. El SBC puede operar en modo SRTP relay, transmitiendo los medios cifrados sin descifrarlos. Esto preserva el cifrado de extremo a extremo y reduce la carga de procesamiento del SBC. La señalización en ambos tramos corre sobre TLS.
Este patrón es ideal cuando tanto su infraestructura interna como sus peers externos soportan cifrado moderno. Proporciona la postura de seguridad más sólida.

Patrón 2: puente de cifrado

Un lado soporta TLS y SRTP. El otro no. Este es el escenario de implementación más común en el mundo real, donde el ProSBC asegura el sistema de telefonía existente.
Su proveedor de SIP trunk o Microsoft Teams requiere TLS y SRTP. Su IP-PBX heredado solo soporta UDP y RTP. El SBC se ubica entre ellos, aceptando SIP/RTP sin cifrar del PBX y convirtiéndolo a TLS/SRTP hacia el peer externo. No se requiere una actualización completa del PBX.
El SBC realiza la conversión RTP a SRTP en la ruta de medios y la terminación/originación TLS en la ruta de señalización. La red interna permanece sin cifrar (y debe protegerse mediante otros controles de seguridad de red), mientras que todo el tráfico que cruza la internet pública está completamente cifrado.

Patrón 3: políticas de cifrado por trunk

Las redes reales no son uniformes. Es posible que tenga algunas conexiones con operadores que requieren TLS y SRTP, otras que solo soportan TLS sin SRTP, y trunks internos donde el cifrado es innecesario.
Un SBC correctamente configurado le permite establecer la política de cifrado por trunk group (denominado Network Access Point, o NAP, en la terminología de ProSBC). Cada trunk especifica de forma independiente si TLS es obligatorio, preferido o desactivado, y si SRTP es obligatorio, preferido o desactivado.
Esta granularidad es fundamental. Una política de cifrado global lo obliga a cifrar todo (lo que rompe las conexiones heredadas) o a no cifrar nada (lo que deja las conexiones externas expuestas). Las políticas por trunk le permiten aplicar el cifrado exactamente donde se necesita.

Configuración de TLS: protección de la señalización SIP

La configuración de TLS en un SBC implica cuatro pasos: gestión de certificados, configuración del listener, asignación de políticas por trunk y, opcionalmente, TLS mutuo.

Paso 1: gestión de certificados

Toda conexión TLS requiere que el SBC presente un certificado X.509 válido a sus peers. ProSBC establece una configuración predeterminada para este parámetro. El certificado debe cumplir los siguientes requisitos:
El Common Name (CN) o Subject Alternative Name (SAN) del certificado debe coincidir con el Fully Qualified Domain Name (FQDN) que los peers externos usan para alcanzar el SBC. Si la dirección de señalización del SBC es sbc.example.com, el certificado debe estar emitido para ese dominio.
El certificado debe estar emitido por una Certificate Authority (CA) de confianza para sus peers. Para el SIP trunking general, funcionan certificados de CAs públicas como DigiCert, Sectigo o Let’s Encrypt. Sin embargo, algunos proveedores de servicios pueden tener requisitos más estrictos; por ejemplo, para Microsoft Teams Direct Routing, el certificado debe estar emitido por una de las CAs en la lista de raíces de confianza publicada por Microsoft.
Instale tanto el certificado público del SBC y su clave privada (como certificado local) como la cadena completa de la CA (como certificados de confianza) en el SBC. Consulte las suites de cifrado TLS y SRTP compatibles en la documentación de ProSBC. Los certificados intermedios faltantes en las cadenas de certificados son una de las causas más comunes de fallos en el handshake TLS.
Configure un proceso de “auditoría de certificados”. Un certificado TLS que venza sin renovarse causará fallos inmediatos en todas las llamadas de los trunks que lo utilicen. Realice auditorías y monitoreo regulares para asegurarse de que ningún certificado esté vencido.

Paso 2: habilitar la escucha TLS

Configure el SBC para escuchar conexiones TLS en su interfaz de señalización. Los parámetros clave incluyen:
Puerto de escucha. El puerto TLS predeterminado para SIP es 5061, pero es completamente configurable. Si necesita usar un puerto diferente por razones operativas o de seguridad, configúrelo según corresponda. Lo importante es que sus peers sepan a qué puerto conectarse.
Versión mínima de TLS. Si su SBC soporta versiones anteriores de TLS, deshabilite TLS 1.0 y TLS 1.1, que tienen vulnerabilidades conocidas. Establezca TLS 1.2 como mínimo. TLS 1.3 es preferible cuando ambas partes lo soportan, ya que proporciona mayor seguridad y un handshake más rápido (un round trip en lugar de dos). ProSBC solo permite TLS 1.2 cuando TLS 1.3 no se utiliza.

Paso 3: establecer políticas TLS

Establezca la política TLS para todos los trunk groups según los requisitos de los peers. Por ejemplo: TLS (1.3 de forma predeterminada, o 1.2), TCP o UDP.

Paso 4: TLS mutuo (mTLS)

TLS estándar es unidireccional: el SBC presenta su certificado al peer y el peer lo valida. El peer no prueba su identidad al SBC (nota: en este ejemplo, el SBC es el cliente y el peer es el servidor).
mTLS agrega un segundo paso de validación. El SBC también solicita y valida el certificado del peer. Esto evita que dispositivos no autorizados establezcan conexiones SIP con el SBC, incluso si conocen la dirección IP y el puerto correctos.
mTLS es obligatorio para Microsoft Teams Direct Routing y se recomienda para interconexiones con operadores y cualquier entorno con requisitos de cumplimiento normativo. Para configurar mTLS, instale los certificados de CA de confianza (o certificados de peers específicos) en el almacén de confianza del SBC y configure el trunk para requerir autenticación del peer.

Configuración de SRTP: cifrado de los medios de voz

Con TLS asegurando el canal de señalización, puede configurar SRTP de forma segura para el cifrado de medios. La configuración de SRTP implica tres decisiones: el método de intercambio de claves, la conversión RTP a SRTP y el comportamiento del SRTP relay.

Paso 1: método de intercambio de claves

En la práctica se utilizan dos mecanismos de intercambio de claves:
SDES (SDP Security Descriptions, RFC 4568) es el método más ampliamente compatible. Las claves SRTP se intercambian en el atributo crypto de la oferta o respuesta SDP dentro de la señalización SIP. SDES es sencillo de configurar y compatible con la mayoría de los endpoints SIP y proveedores de trunking. El requisito fundamental: la señalización SIP debe correr sobre TLS cuando se usa SDES, ya que las claves están embebidas en el cuerpo SDP en texto plano.
DTLS-SRTP intercambia claves a través de un handshake DTLS independiente en la ruta de medios, sin depender de la señalización SIP. Es obligatorio para aplicaciones WebRTC, más complejo de configurar y no depende de la señalización SIP para el intercambio de claves. DTLS-SRTP se usa principalmente para aplicaciones de voz y video basadas en navegador.
(Nota: existen técnicamente otros métodos de intercambio llamados ZRTP y MIKEY, pero no son de uso común en el campo).
Para la mayoría de las implementaciones de SBC que involucran SIP trunking, peering con operadores y plataformas de comunicaciones unificadas, SDES sobre señalización protegida con TLS es el enfoque estándar.

Paso 2: conversión RTP a SRTP

Esta es una de las capacidades más valiosas de un SBC en un entorno de cifrado mixto. Cuando un lado de una llamada soporta SRTP y el otro no, el SBC convierte entre los dos:
El SBC recibe medios RTP sin cifrar del endpoint heredado. Cifra los medios como SRTP y los reenvía al peer con capacidad de cifrado. En la dirección inversa, descifra el SRTP entrante y envía RTP al endpoint heredado.
Esta conversión ocurre de forma transparente. Ningún endpoint sabe que el otro lado usa un transporte de medios diferente. El SBC gestiona toda la administración de claves, el cifrado y el descifrado.
Los casos de uso más comunes para la conversión RTP a SRTP incluyen: conectar un IP-PBX heredado (solo RTP) a un proveedor de SIP trunk que requiere SRTP, conectar una plataforma de contact center más antigua a Microsoft Teams, y dar soporte a usuarios remotos en conexiones cifradas mientras el PBX de la sede central opera sin cifrado internamente.

Paso 3: SRTP relay

Cuando ambos endpoints soportan SRTP, el SBC puede operar en modo relay. Transmite los medios cifrados sin descifrarlos ni recifrarlos. Esto preserva el cifrado de medios de extremo a extremo y reduce la carga de procesamiento del SBC.
El SRTP relay es apropiado cuando ambos peers negocian métodos de intercambio de claves y suites de cifrado compatibles, y el SBC no necesita inspeccionar ni modificar los medios (no se requiere transcodificación, grabación ni manipulación de medios en esa llamada).

Escenarios de implementación

Microsoft Teams Direct Routing

Teams Direct Routing tiene requisitos de cifrado específicos. El SBC debe soportar TLS (TLS mutuo con las raíces de CA publicadas por Microsoft), y todos los medios deben usar SRTP. El SBC se ubica entre la infraestructura de Teams y su conectividad PSTN, gestionando TLS/SRTP hacia Teams y el transporte que soporte su proveedor de SIP trunk en el otro lado.
Puntos clave de configuración: instale un certificado de una CA aprobada por Microsoft, configure mTLS en el trunk hacia Teams, establezca SRTP como obligatorio y habilite la conversión RTP a SRTP si su proveedor de SIP trunk no soporta SRTP.

Peering con proveedores de SIP trunking

Los principales proveedores de SIP trunk (Bandwidth, Telnyx, Twilio y otros) ahora soportan TLS y SRTP. Habilite TLS en el trunk hacia el operador y establezca SRTP como obligatorio o preferido según la documentación del proveedor. Algunos proveedores soportan mTLS; consulte sus guías de configuración.

Integración con PBX heredado

Muchas organizaciones utilizan IP-PBXs que se desplegaron antes de que TLS y SRTP fueran estándar. Estos sistemas solo soportan UDP/TCP para señalización y RTP para medios. El SBC gestiona la conversión de cifrado sin requerir ningún cambio en el PBX.
Configure el trunk hacia el PBX con TLS desactivado y SRTP desactivado. Configure el trunk hacia el exterior con TLS obligatorio y SRTP obligatorio. El SBC hace de puente entre los dos dominios de cifrado.

Usuarios remotos y en home office

Los teléfonos SIP y softphones que se conectan a través de internet público siempre deben usar TLS y SRTP. Sin cifrado, un usuario en la red Wi-Fi de una cafetería está transmitiendo llamadas de voz en texto claro sobre una red compartida.
Configure el trunk del lado de acceso para requerir TLS y SRTP. Esto protege tanto los metadatos de señalización como el contenido de voz de las escuchas en redes no confiables.

Solución de problemas comunes de TLS y SRTP

Fallos en el handshake TLS

Certificado vencido es el problema TLS más común. El certificado del SBC ha vencido y los peers rechazan la conexión. Verifique las fechas de vencimiento de los certificados y renuévelos antes de que expiren.
CA no confiable ocurre cuando el peer no confía en la CA que emitió su certificado. Instale la cadena de certificados completa (incluidos los intermedios) y verifique que el almacén de confianza del peer incluya su CA. Para Teams Direct Routing, verifique que su CA esté en la lista aprobada de Microsoft.
Discrepancia de FQDN ocurre cuando el CN o SAN del certificado no coincide con el nombre de host que el peer usa para conectarse. El certificado debe coincidir con el FQDN en los encabezados SIP, no solo con la dirección IP.
Incompatibilidad de versión TLS ocurre cuando su SBC requiere TLS 1.2 pero el peer solo soporta TLS 1.0, o a la inversa. Verifique la configuración de versión mínima de TLS en ambos lados.

Fallos en la negociación SRTP

Incompatibilidad de suite de cifrado ocurre cuando el SBC ofrece un único método de intercambio de claves pero el peer solo soporta una suite diferente. Revise la configuración de suites crypto en ambos lados.
Atributo crypto faltante ocurre cuando el endpoint remoto no incluye un atributo crypto en su SDP. Es posible que no soporte SRTP, o que SRTP no esté habilitado en su lado. Si el trunk está configurado como SRTP obligatorio, la llamada fallará.
SRTP ofrecido pero rechazado ocurre cuando el peer incluye atributos crypto en la oferta pero la respuesta del SBC los elimina, o viceversa. Verifique que SRTP esté habilitado en el trunk correcto y que el modo de aplicación no esté configurado como desactivado.

Audio unidireccional al habilitar SRTP

Esto puede deberse a diversas causas: un problema de interoperabilidad con implementaciones de SRTP, un problema de negociación SRTP vía SIP/SDP, o simplemente un problema de red. Al habilitar SRTP, los medios pueden usar puertos diferentes o características de transporte distintas. Verifique que los firewalls entre el SBC y los endpoints permitan los puertos de medios SRTP. Confirme que la configuración de NAT no esté reescribiendo los encabezados de los paquetes SRTP. Use captura de paquetes para confirmar que los medios fluyen en ambas direcciones.

Interrupciones por renovación de certificados

Reemplazar un certificado en un SBC de producción puede causar breves interrupciones del servicio si no se maneja con cuidado. La mejor práctica: cargue el nuevo certificado junto al existente, verifique que los handshakes TLS tengan éxito con el nuevo certificado en un entorno de prueba y luego cambie el SBC de producción al nuevo certificado durante una ventana de mantenimiento.

Herramientas de diagnóstico

Las capturas de traza SIP (que muestran el contenido completo del mensaje SIP, incluidos los atributos crypto del SDP) y la captura de paquetes en vivo (equivalente a Wireshark en el propio SBC) son las herramientas principales. La documentación cubre la solución de problemas de TLS y audio paso a paso. Use trazas SIP para verificar que las sesiones TLS se establezcan, que el SDP incluya atributos crypto y que SRTP se negocie correctamente en la respuesta SDP.

Lista de verificación de mejores prácticas

Seguir estas prácticas le ayudará a garantizar que su implementación de TLS y SRTP sea segura, mantenible y resiliente.

1. Implemente TLS antes que SRTP.Asegure primero el canal de señalización para proteger el intercambio de claves SRTP.
2. Use TLS 1.2 o superior.Deshabilite TLS 1.0 y 1.1 en todos los trunks.
3. Aplique cifrado en todos los trunks externos.Todo el tráfico que cruce internet público debe usar TLS y SRTP.
4. Configure políticas por trunk.Diferentes trunks tienen diferentes requisitos.
5. Configure recordatorios para verificar el vencimiento de certificados.Alertas a los 30 días y a los 7 días.
6. Use mTLS para el peering con operadores.TLS unidireccional no es suficiente para conexiones de alta seguridad.
7. Habilite la conversión RTP a SRTP para integración con equipos heredados.No deje que los endpoints heredados sean una razón para omitir SRTP en los trunks externos.
8. Realice pruebas con capturas de paquetes.Después de habilitar el cifrado, verifique con una captura que la señalización esté cifrada con TLS y que las cargas útiles de medios aparezcan como SRTP cifrado.
9. Documente la política de cifrado por trunk.Mantenga una matriz que indique qué trunks usan TLS, SRTP, mTLS y qué método de intercambio de claves utilizan. Esta documentación es fundamental para las auditorías de cumplimiento.
10. Revise las suites de cifrado periódicamente.Los estándares criptográficos evolucionan. Asegúrese de actualizar su stack, leer las notas de versión y deprecar los algoritmos débiles a medida que cambian las recomendaciones.

Qué buscar en un SBC para cifrado

No todos los SBCs gestionan el cifrado de la misma manera. Si está evaluando un SBC para una implementación que requiere TLS y SRTP, busque estas capacidades:

Políticas de TLS y SRTP por trunk

El SBC debe permitirle configurar el cifrado de forma independiente en cada trunk group. Los ajustes globales únicamente no funcionan en redes reales con requisitos mixtos.

Conversión RTP a SRTP

Sin esta capacidad, no puede cifrar los medios para endpoints heredados. Esta única capacidad a menudo determina si una migración a voz cifrada es posible sin reemplazar la infraestructura existente.

SRTP relay

Para escenarios de cifrado de extremo a extremo, el SBC debe poder transmitir los medios cifrados sin descifrarlos.

Arquitectura B2BUA

La terminación y reoriginación SIP completa en cada tramo permite contextos de cifrado independientes. Los SBCs basados en proxy SIP no pueden proporcionar el mismo nivel de control de cifrado.

Configuración flexible de TLS

Los puertos, las suites de cifrado, las versiones de TLS y la gestión de certificados deben ser todos configurables, no fijos en el código.

Herramientas de diagnóstico integradas

Las capacidades de captura de paquetes en vivo y de traza SIP en el propio SBC son fundamentales para solucionar problemas de cifrado sin desplegar infraestructura de monitoreo externa.

Preguntas frecuentes