STIR/SHAKEN: autenticación de llamadas y resiliencia en entornos VoIP
En la red telefónica moderna —y especialmente en entornos VoIP—, la suplantación del identificador de llamada (caller ID spoofing) es una de las principales fuentes de fraude. Un atacante puede modificar el número mostrado como origen de la llamada y fingir ser otra persona o entidad: un banco, una administración pública o incluso un contacto de confianza.
El problema se agrava porque los sistemas de señalización tradicionales aceptan ese identificador sin validarlo. Entre operadores, el número viaja en el mensaje SIP y se asume que es legítimo. El resultado: millones de llamadas fraudulentas cada día, pérdida de confianza y tráfico legítimo bloqueado.
Para abordar esta amenaza, la industria ha desarrollado un conjunto de estándares que permiten verificar la identidad del origen de la llamada.
Ahí es donde entran en juego STIR y SHAKEN.
STIR y SHAKEN: autenticando la identidad del origen
Los protocolos STIR (Secure Telephone Identity Revisited) y SHAKEN (Signature-based Handling of Asserted information using toKENs) establecen un marco técnico y normativo para garantizar que una llamada proviene realmente de quien dice ser.
STIR define cómo se firma digitalmente una llamada SIP.
El operador genera un token (PASSporT) con datos como número de origen, destino y nivel de confianza.
Luego lo firma con su clave privada y lo inserta en el encabezadoIdentity:del mensaje INVITE.SHAKEN complementa a STIR con las políticas de validación y gestión de esas firmas, especificando cómo deben comportarse los operadores ante llamadas firmadas, inválidas o no firmadas.
De esta forma, cada llamada transporta una prueba criptográfica de autenticidad. El operador receptor puede verificarla mediante la clave pública asociada y determinar si el identificador de llamada es legítimo o debe marcarse como sospechoso.
Este enfoque refuerza la confianza en las comunicaciones de voz y limita el uso fraudulento de la red telefónica. En Estados Unidos, la FCC exige ya la adopción obligatoria de STIR/SHAKEN por parte de los principales proveedores de voz para combatir las robocalls y proteger a los usuarios.
Los niveles de atestación
Cada llamada firmada incluye un nivel de atestación que refleja la confianza del operador en el origen:
A (Full) – El operador certifica que conoce al cliente y que este está autorizado a usar el número.
B (Partial) – El operador conoce al cliente, pero no puede confirmar la titularidad exacta del número.
C (Gateway) – El operador solo sabe que la llamada proviene de una fuente conocida, pero sin relación directa con el número mostrado.
Este sistema de confianza progresiva no elimina por completo el fraude, pero reduce drásticamente su impacto. Además, ofrece una trazabilidad clara para identificar qué operador firmó cada llamada.
Aplicación práctica en un softswitch de clase 4
En un softswitch de clase 4, como M4, la implementación de STIR/SHAKEN permite firmar las patas salientes de las llamadas SIP y validar las entrantes.
El proceso, descrito en la documentación oficial de Kolmisoft, incluye:
Configurar Kamailio 5.7 o superior con soporte STIR/SHAKEN.
Definir la clave privada (.pem) y la URL del certificado público (x5u).
Activar la opción Add STIR/SHAKEN Identity en los puntos de origen o terminación.
Seleccionar el nivel de atestación (A, B o C) según la relación con el cliente.
Comprobar con herramientas como
sngrepque el encabezadoIdentity:se añade correctamente.
Cuando la llamada se origina, el softswitch genera y firma el token PASSporT. El operador receptor puede verificarlo con la clave pública publicada, garantizando la integridad del identificador de llamada.
Una configuración adecuada de STIR/SHAKEN reduce la probabilidad de que el tráfico sea marcado como spam, mejora la reputación del operador y evita bloqueos en carriers internacionales. Hay una guía detallada de implementación en introducción técnica a STIR/SHAKEN de TransNexus.
Redundancia geográfica: más allá de la autenticación
Garantizar la identidad de las llamadas es solo una parte del problema. La otra mitad es mantener el servicio disponible y operativo incluso en caso de fallo. La redundancia geográfica (geo-redundancy) permite lograrlo al distribuir la infraestructura entre varios centros de datos conectados entre sí.
En una arquitectura típica:
Cada data center aloja al menos dos servidores: uno para CORE/DB/GUI y otro para Proxy/B2BUA/Media
La base de datos (por ejemplo, MySQL) se replica entre los DCs
El tráfico SIP se distribuye mediante DNS SRV o balanceadores inteligentes
Si el servidor principal falla, el sistema de respaldo asume automáticamente la señalización y las nuevas llamadas
Este diseño permite que cada centro de datos opere activamente y pueda absorber la carga del otro en caso de incidente. En plataformas como M4, la implementación descrita permite manejar hasta 2.000 llamadas concurrentes por centro de datos, o 500 si se consolidan los servicios en un solo nodo.
El enlace Best Practices for VoIP Network Redundancy muestra otras estrategias de continuidad y detalla ejemplos de replicación y failover en sistemas SIP distribuidos.
Buenas prácticas y consideraciones
Mantener baja la latencia entre centros de datos para una replicación estable
Evitar trasladar el flujo de media (RTP) entre DCs salvo cuando sea imprescindible
Planificar actualizaciones en caliente aprovechando la redundancia
Supervisar la coherencia de base de datos para prevenir inconsistencias
Documentar los procedimientos de failover y failback para que sean verificables
Estas prácticas no solo aportan resiliencia técnica, sino también confianza operativa, una condición cada vez más valorada por clientes y reguladores.
En conclusión
La autenticación de llamadas mediante STIR/SHAKEN y la redundancia geográfica en la infraestructura no son iniciativas independientes: ambas buscan el mismo fin, reforzar la confianza en las comunicaciones de voz.
STIR/SHAKEN aporta transparencia y trazabilidad, asegurando que las llamadas provienen de fuentes verificadas.
La redundancia geográfica garantiza disponibilidad continua incluso ante fallos graves.
Adoptar ambos enfoques es una forma de modernizar la red sin perder control sobre la seguridad, la reputación y la continuidad del servicio.
Si quieres profundizar en los aspectos normativos y técnicos, te recomiendo revisar: