STIR/SHAKEN y autenticación de llamadas

STIR/SHAKEN ya no es opcional para la mayoría de los proveedores de servicios de voz en Estados Unidos. El mandato de implementación de la FCC, fortalecido por la regla de certificado propio de septiembre de 2025, exige que cada proveedor originante cuente con infraestructura capaz de firmar llamadas con su propio certificado, asignar el nivel de atestación correcto por llamada y responder de forma controlada cuando el servicio de firma no está disponible.
El controlador de borde de sesión (SBC) es donde todo esto ocurre. Se ubica en el borde de origen de la red, el último punto de control antes de que una llamada salga de su dominio. Sin embargo, los SBC difieren significativamente en la forma en que manejan STIR/SHAKEN. Algunos ofrecen una integración estática y propietaria vinculada a un único socio de firma. Otros exponen un motor de enrutamiento configurable que otorga al proveedor control total sobre la lógica de atestación, la selección de socios y el comportamiento de respaldo.
Esta página explica qué sucede en la capa del SBC durante la firma y verificación de STIR/SHAKEN, por qué el enrutamiento configurable es importante para el cumplimiento normativo, y cómo la arquitectura abierta de ProSBC lo resuelve.

Cómo funciona STIR/SHAKEN en la capa del SBC

El marco STIR/SHAKEN asigna dos roles distintos a los proveedores de servicios: el proveedor originante firma la llamada y el proveedor de terminación verifica la firma. El SBC es el punto de aplicación para ambos.

Firma (lado de origen)

Cuando una llamada ingresa al SBC desde una troncal de cliente, el SBC recopila los datos de la llamada necesarios para el token PASSporT: el número originante (del encabezado P-Asserted-Identity o From), el número de destino (del encabezado To) y la marca de tiempo (del encabezado Date). Determina el nivel de atestación apropiado para la llamada y luego envía una solicitud de firma a un servicio externo STIR/SHAKEN Authentication Service (STI-AS). El STI-AS utiliza el certificado del proveedor para generar una firma criptográfica, la encapsula en un token PASSporT y devuelve un Identity header firmado. El SBC inyecta ese Identity header en el INVITE SIP saliente antes de reenviar la llamada.

Verificación (lado de terminación)

Cuando el SBC recibe una llamada entrante con un Identity header, reenvía ese encabezado a un servicio de verificación STIR/SHAKEN (STI-VS). El servicio de verificación valida la firma criptográfica contra el certificado del proveedor originante, comprueba que el token no haya expirado y confirma que los números de origen y destino coincidan con las declaraciones del PASSporT. El resultado regresa al SBC, que enruta la llamada en consecuencia.

Niveles de atestación

Cada llamada firmada lleva uno de tres niveles de atestación, determinado por el proveedor originante:

• A (atestación completa): El proveedor autentica a la parte llamante y confirma que está autorizada a usar el número de origen.
• B (atestación parcial): El proveedor puede autenticar el origen de la llamada, pero no puede verificar la autorización del llamante para usar el número específico.
• C (atestación de gateway): La llamada ingresó a la red desde una fuente externa que el proveedor no puede autenticar.

El nivel de atestación no es decorativo. Afecta directamente la forma en que los proveedores aguas abajo y las plataformas de análisis tratan la llamada. Las llamadas con nivel A pasan sin problemas, mientras que las de nivel C son marcadas o bloqueadas. Equivocarse tiene consecuencias reales en las tasas de finalización de llamadas.
Para un análisis detallado de cada nivel de atestación y cuándo utilizarlos, consulte nuestra guía sobre niveles de atestación STIR/SHAKEN explicados (próximamente).

Por qué el control de atestación pertenece a la capa de enrutamiento

La atestación es una decisión por llamada. Depende de lo que usted sabe sobre la fuente de la llamada, y ese conocimiento reside en su lógica de enrutamiento.
Considere un ISP que opera un único SBC y maneja tres tipos de tráfico: clientes de troncales SIP minoristas (usted emitió los números, usted autentica al suscriptor), tránsito mayorista de un operador regional (usted sabe de dónde proviene, pero no puede verificar al llamante) y tráfico de gateway de un socio internacional (fuente no confiable). El nivel de atestación correcto es A para el primero, B para el segundo y C para el tercero. Los tres pasan por el mismo SBC.
Un SBC que solo admite un nivel de atestación único por troncal lo obliga a elegir uno. Si asigna A a todo, estará haciendo declaraciones de atestación falsas, lo que viola las reglas de la FCC. Si asigna C a todo, las llamadas de sus clientes minoristas serán marcadas como no verificadas, dañando sus tasas de finalización.
Aquí es donde el enrutamiento configurable se convierte en un requisito de cumplimiento, no solo en una conveniencia. El motor de enrutamiento evalúa cada llamada contra su lógica de negocio y asigna el nivel de atestación de forma dinámica. ¿Cliente minorista en una troncal que usted aprovisiona? Nivel A. ¿Tránsito mayorista donde usted conoce al operador originante? Nivel B. ¿Tráfico de gateway de un par internacional no confiable? Nivel C.
La regla de certificado propio de la FCC, vigente desde el 18 de septiembre de 2025, refuerza esto. Su organización debe tomar las decisiones sobre el nivel de atestación. Un servicio de firma puede realizar el acto técnico de firmar, pero no puede asignar la atestación de forma independiente. (Para un desglose detallado de la regla de certificado propio y sus requisitos, consulte nuestra página sobre la regla de certificado propio STIR/SHAKEN de la FCC.)
Si su SBC trata la atestación como una configuración estática en lugar de una decisión de enrutamiento, le resultará difícil mantener el cumplimiento a medida que su mezcla de tráfico evolucione.
Para proveedores que necesitan pasar de atestación nivel C a nivel A con su propio certificado, consulte nuestra guía sobre autoatestación STIR/SHAKEN nivel A (próximamente).

Modelo abierto de socios vs. STIR/SHAKEN propietario

No todos los fabricantes de SBC manejan la integración STIR/SHAKEN de la misma manera. Algunos, incluyendo Ribbon y AudioCodes, ofrecen implementaciones STIR/SHAKEN propietarias que restringen el servicio de firma que usted puede utilizar. La integración está incorporada en el firmware del SBC, lo que simplifica la configuración inicial pero limita sus opciones si desea cambiar de socio de firma, agregar puntuación de fraude o integrar servicios de cumplimiento adicionales.
ProSBC adopta un enfoque diferente. Su motor de enrutamiento configurable se integra con cualquier servicio de firma basado en HTTP o SIP a través de módulos Ruby API. TransNexus ClearIP, Neustar o cualquier otro STI-AS que acepte solicitudes de firma HTTP o SIP INVITE estándar: la integración ocurre en la capa de enrutamiento, no embebida en el firmware.
Cómo funciona en la práctica: el módulo StirShakenapi envía una solicitud de firma HTTP o SIP INVITE al proveedor de servicio de firma configurado, con su token de autorización y los datos de la llamada (número de origen, destino, marca de tiempo, nivel de atestación). El servicio de firma devuelve un Identity header firmado, y el SBC lo inyecta en el INVITE saliente.
Tres ventajas arquitectónicas surgen de este enfoque:

Redundancia

ProSBC admite proveedores de servicio de firma primario y secundario. Si el primario es inalcanzable, la solicitud se redirige automáticamente al secundario mediante conmutación por error (failover). Si ambos están caídos, se agrega un encabezado P-Identity-Bypass a la llamada, indicando a los proveedores aguas abajo que la firma no estuvo disponible para esa llamada específica. La llamada se completa.

Flexibilidad de socios

Cambiar de servicio de firma significa actualizar un proveedor (SIP NAP en la configuración de ProSBC) y un token de autorización en la configuración de enrutamiento. Sin actualización de firmware, sin intervención del fabricante, sin ventana de servicio. Si TransNexus aumenta precios o Neustar agrega una función que usted necesita, la migración es un cambio de configuración.

Componibilidad

Dado que la solicitud de firma es una llamada HTTP o SIP dentro del script de enrutamiento, puede combinarla con otras integraciones API en el mismo flujo de llamada. TransNexus ClearIP, por ejemplo, admite LCR (Least Cost Routing), puntuación de fraude y firma STIR/SHAKEN en una sola consulta. El motor de enrutamiento de ProSBC puede evaluar la puntuación de fraude, tomar una decisión de enrutamiento y firmar la llamada en un solo paso.

Implementación de STIR/SHAKEN en ProSBC

ProSBC admite tres tipos de solicitud STIR/SHAKEN a través de sus módulos Ruby API:

Firma

El SBC envía una solicitud de FIRMA al STI-AS configurado. Completa las declaraciones del PASSporT a partir del mensaje SIP: orig del encabezado P-Asserted-Identity o From, dest del encabezado To, e iat del encabezado Date. El servicio de firma devuelve un Identity header firmado que contiene la firma digital y el nivel de atestación, y el SBC lo inyecta en el INVITE saliente.

Atestación

Para implementaciones que separan la decisión de atestación de la operación de firma, el SBC puede enviar una solicitud de ATESTACIÓN. Esto permite que la lógica de atestación del proveedor se ejecute de forma independiente del servicio de firma.

Verificación

En el lado de terminación, el SBC envía una solicitud de VERIFICACIÓN, pasando el Identity header entrante al STI-VS. El resultado de la verificación informa las decisiones de enrutamiento aguas abajo.
A continuación se presenta información adicional configurada por defecto en ProSBC:
Tiempo de espera configurable. Cada consulta HTTP o SIP al servicio de firma tiene un tiempo de espera configurable. La configuración predeterminada es de 10 segundos. Esto evita que la latencia de firma bloquee el establecimiento de la llamada cuando el servicio de firma es lento o no responde.
Proveedores primario y secundario (Network Access Points en ProSBC). Tanto los servicios de firma como los de verificación admiten proveedores duales para conmutación por error (failover) automática.
Respaldo P-Identity-Bypass. Si el servicio de firma es inalcanzable después de reintentos en ambos proveedores, el SBC agrega un encabezado P-Identity-Bypass en lugar de bloquear la llamada. La llamada se completa y el encabezado proporciona transparencia sobre la ausencia del Identity header.
Enrutamiento basado en dominio. Para redes que manejan tanto tráfico de origen móvil (MO) como de terminación móvil (MT), la implementación admite enrutamiento basado en dominio para aplicar un comportamiento STIR/SHAKEN diferente según la dirección de la llamada.
Integraciones validadas con socios. ProSBC cuenta con integraciones documentadas con TransNexus ClearIP (LCR combinado, puntuación de fraude y STIR/SHAKEN) y Neustar (autenticación, verificación y procesamiento de redireccionamiento 302). Estas son integraciones validadas y probadas en producción, no afirmaciones genéricas de API.

Cómo comenzar

Si está evaluando cómo su SBC maneja STIR/SHAKEN, o si está implementando STIR/SHAKEN por primera vez, comience con la guía de implementación STIR/SHAKEN para SBC para el recorrido completo de configuración paso a paso. ProSBC ofrece varias formas de comenzar.

ProSBC Lab

ProSBC Lab es una licencia gratuita y permanente de 3 sesiones para uso en laboratorio y pruebas. Es autoservicio y toma aproximadamente 20 minutos para configurar. Puede configurar la firma y verificación STIR/SHAKEN en un entorno de laboratorio antes de comprometerse con producción.

Prueba gratuita de 30 días

La prueba gratuita de 30 días de ProSBC le otorga 500 sesiones concurrentes para evaluación en producción. Si su implementación STIR/SHAKEN necesita pruebas a escala antes de entrar en producción, la prueba lo cubre.

Servicio administrado

El servicio administrado de ProSBC está disponible para proveedores que desean que TelcoBridges se encargue de la configuración, monitoreo y gestión continua de cumplimiento STIR/SHAKEN. El servicio administrado puede implementarse en su propia infraestructura (AWS, Azure, VMware, KVM, en sitio) o alojado por TelcoBridges. Su organización conserva acceso completo.
Para proveedores que ya operan un SBC con integración STIR/SHAKEN propietaria y buscan mayor flexibilidad, o para quienes implementan STIR/SHAKEN por primera vez bajo presión regulatoria, la combinación de control de atestación configurable, selección abierta de socios y redundancia integrada es lo que hace que este enfoque funcione.