Guía de implementación de STIR/SHAKEN en SBC: cómo firmar, atestar y verificar llamadas

Si usted gestiona servicios de voz en los Estados Unidos, STIR/SHAKEN es un requisito básico para sus operaciones. La FCC ahora exige que la mayoría de los proveedores firmen las llamadas salientes con sus propios certificados, mantengan su registro actualizado en la Robocall Mitigation Database (RMD) y completen las recertificaciones anuales. Dado que los operadores intermedios cada vez más marcan o bloquean las llamadas sin firmar, implementar esto correctamente es la mejor forma de garantizar que las llamadas de sus clientes lleguen a su destino.

La buena noticia es que su Session Border Controller (SBC) es el aliado perfecto para esta tarea. Como se ubica justo en el borde de su red como un Back-to-Back User Agent (B2BUA), tiene la visibilidad de “primera fila” necesaria para gestionar cada sesión SIP. Esta arquitectura le permite recopilar fácilmente los encabezados SIP específicos (números de origen y destino, marcas de tiempo y niveles de atestación) necesarios para construir un token PASSporT válido.

Hemos diseñado esta guía para acompañarlo a través del proceso de implementación. Comenzaremos con los prerrequisitos de la FCC y la adquisición de certificados, luego pasaremos a la configuración del SBC, la integración con el servicio de firma y la lógica de atestación, para finalizar con la verificación y las pruebas en producción.

Cómo funciona STIR/SHAKEN a nivel de SBC

STIR (Secure Telephone Identity Revisited) define el protocolo criptográfico para firmar la identidad de las llamadas. SHAKEN (Signature-based Handling of Asserted information using toKENs) define el marco de la industria para la implementación de STIR por parte de los proveedores de servicios en redes de producción.

Lado de origen (firma)

Cuando su SBC recibe una llamada saliente, intercepta el SIP INVITE antes de reenviarlo al siguiente salto. El SBC extrae el número de origen (del encabezado P-Asserted-Identity o del encabezado From), el número de destino (del encabezado To) y la marca de tiempo (del encabezado Date). Empaqueta estos datos en una solicitud de firma y la envía a un servicio externo de firma, también llamado STI Authentication Service (STI-AS). Esa solicitud se entrega a través de SIP (TCP, puerto 5060), con el servicio de firma actuando como un servidor de redirección SIP. ProSBC también admite la firma basada en HTTPS para proveedores STI-AS que lo requieran. El servicio de firma crea un token PASSporT, lo firma con la clave privada de su certificado y devuelve un encabezado Identity completo. Su SBC inyecta este encabezado Identity en el SIP INVITE saliente.

Lado de terminación (verificación)

Cuando su SBC recibe una llamada entrante con un encabezado Identity, puede reenviar la llamada a un servicio de verificación (STI-VS) a través de SIP. El servicio de verificación valida la firma, comprueba la cadena de certificados, confirma que el token no ha expirado ni ha sido alterado, y devuelve un SIP 302 con un parámetro Verstat en el encabezado P-Asserted-Identity. ProSBC toma la cadena Verstat de ese 302 y la reenvía al siguiente destino. Con base en el resultado de la verificación, usted aplica la política: aceptar, marcar o rechazar.
El PASSporT (Personal Assertion Token) contiene cinco campos principales: orig (número telefónico de origen), dest (número de destino), iat (marca de tiempo de emisión), origid (identificador único de llamada) y attest (nivel de atestación).

Los tres niveles de atestación

La atestación comunica su relación con la llamada y con la parte que llama. No es una puntuación de confianza ni una calificación de spam. Para una referencia detallada sobre lo que significa cada nivel en la práctica, consulte Niveles de atestación STIR/SHAKEN explicados. Es una declaración del proveedor de servicios de origen sobre cuánto conoce acerca de la llamada.

A (atestación completa)

La atestación de nivel A se aplica cuando usted autenticó a la parte que llama, sabe quién es y está autorizada a usar el número de origen. Este es el nivel que asigna cuando el llamante es su suscriptor directo o un cliente cuya identidad ha verificado.

B (atestación parcial)

La atestación de nivel B cubre las llamadas en las que usted sabe de dónde provino la llamada (llegó desde una troncal o par conocido y autenticado), pero no puede verificar que el llamante específico esté autorizado a usar el número de origen. Esto es común para proveedores de tránsito y operadores mayoristas que pasan tráfico de socios upstream conocidos.

C (atestación de gateway)

La atestación de nivel C es el nivel para llamadas que ingresaron a su red desde una fuente no confiable o no verificable. Usted es el primer salto IP pero no puede confirmar nada sobre la identidad del llamante. Esto se aplica en gateways de PSTN a IP, interconexiones internacionales o cuando se recibe tráfico de proveedores que no autentican a sus usuarios.

Prerrequisitos antes de comenzar

Antes de modificar la configuración de su SBC, debe completar varios prerrequisitos administrativos y técnicos.

Requisitos administrativos de la FCC

• Obtenga un Operating Company Number (OCN). Su OCN es asignado por la National Exchange Carrier Association (NECA). Si ya presenta reportes como proveedor de servicios de voz, probablemente ya tiene uno.
• Presente un Form 499-A vigente. El FCC Telecommunications Reporting Worksheet debe estar vigente y archivado.
• Regístrese en la Robocall Mitigation Database (RMD). Debe certificar la implementación completa de STIR/SHAKEN o su programa de mitigación de llamadas automatizadas. Se requiere recertificación anual (la fecha límite más reciente fue el 1 de marzo de 2026). Para un desglose completo de las obligaciones de proveedores pequeños, consulte Cumplimiento de STIR/SHAKEN de la FCC para proveedores VoIP pequeños. La FCC ahora impone multas de $10,000 por información falsa o inexacta en la RMD y $1,000 por no actualizar la base de datos dentro de los 10 días hábiles posteriores a un cambio material.
• Obtenga su token SPC. Solicite un Service Provider Code (SPC) token al administrador de políticas de STIR/SHAKEN (actualmente iconectiv en EE. UU.). Este token acredita su identidad al solicitar un certificado.
• Adquiera su certificado STI. Presente su token SPC a una autoridad certificadora de STIR/SHAKEN (STI-CA) para obtener su certificado digital. Bajo la regla de certificado propio, todas las llamadas deben firmarse con su certificado, no el de un tercero. Puede contratar a un tercero para realizar la firma técnica, pero el certificado debe ser suyo y las decisiones de atestación deben ser suyas.

Prerrequisitos técnicos

• Elija un socio de servicio de firma. ProSBC no realiza la firma criptográfica por sí mismo. Se integra con un STI Authentication Service (STI-AS) externo. ProSBC envía un SIP INVITE, el servicio de firma devuelve un 302 con el encabezado Identity en el P-Asserted-Identity, y ProSBC avanza en la ruta hacia el siguiente destino con el encabezado Identity adjunto. ProSBC también admite proveedores STI-AS basados en HTTPS que prefieren un intercambio HTTP POST/JSON.
• Confirme la conectividad. Su SBC debe poder alcanzar el servicio de firma. Para proveedores STI-AS basados en SIP, esto significa SIP sobre TCP en el puerto 5060 hacia el FQDN del proveedor (por ejemplo, sip.clearip.com). Verifique la resolución DNS, la conectividad TCP y que cualquier firewall entre el SBC y el servicio de firma permita el tráfico SIP saliente. Para proveedores basados en HTTPS, permita el tráfico HTTPS saliente hacia el endpoint de firma configurado.
• Habilite el prerrequisito SIP. En ProSBC, habilite “Publish raw SIP to Routing Script” en SIP Stack > Quirks. Esta configuración es necesaria para que el parámetro iat (marca de tiempo de emisión) se complete correctamente a partir del encabezado SIP Date. Sin ella, la solicitud de firma carecerá de un campo requerido.

Configuración del SBC paso a paso para la firma STIR/SHAKEN

Esta sección utiliza el motor de enrutamiento configurable en Ruby de ProSBC como implementación de referencia. El patrón arquitectónico (el SBC consulta un servicio de firma externo a través de SIP e inyecta el encabezado Identity) se aplica a cualquier SBC, pero los pasos de configuración específicos son propios de ProSBC.

1. Configure los parámetros del servicio de firma

De su proveedor de servicio de firma necesita:

• FQDN del servicio de firma: el destino SIP al que ProSBC enviará las solicitudes de firma. Para ClearIP es sip.clearip.com (o el FQDN regional que ClearIP proporcione). Creará uno o dos NAPs apuntando a este FQDN, dependiendo de si desea un solo NAP para todo el tráfico o NAPs separados para el entrante y el saliente.
• Credenciales de identificación de origen: ClearIP identifica su cuenta por los encabezados de origen que ProSBC envía en el INVITE. Estos se configuran en el script de enrutamiento ClearIP_Query y los proporciona el servicio de firma al aprovisionar su cuenta.
• Tiempo de espera de Route Retry: el temporizador SIP que controla cuánto tiempo espera ProSBC por una respuesta SIP del servicio de firma antes de avanzar en la ruta. El valor predeterminado es 10 segundos.

2. Configure el script de enrutamiento

Para implementaciones basadas en SIP con ClearIP, ProSBC se integra a través del script de enrutamiento ClearIP_Query (ClearIP_Query.rb), que se conecta a la cadena de filtros del script de enrutamiento. El módulo se incluye en su clase de enrutamiento principal y se registra como un before_filter, lo que significa que se ejecuta lo suficientemente temprano como para agregar encabezados de identificación de origen al INVITE que ProSBC enviará al NAP de ClearIP. Neustar utiliza un filtro dedicado equivalente; los proveedores STI-AS basados en HTTPS usan el módulo StirShakenSapi, registrado como un after_remap_filter.
Para ClearIP, la integración se configura a nivel del script de enrutamiento en lugar de mediante parámetros de URL de firma:

1. Importe ClearIP_Query.rb como un script de filtroCárguelo a través del panel de scripts de enrutamiento y marque “Load on startup”.
2. Requiera el módulo en su script de enrutamiento principalEn su script de enrutamiento principal (por defecto simple_routing_sbc.rb), agregue require 'ClearIP_Query' unless defined?(ClearIPQuery) al inicio.
3. Incluya el módulo en su clase de enrutamientoEn su clase de enrutamiento principal, agregue include ClearIPQuery.
4. Registre el before_filterEn la misma clase de enrutamiento, agregue before_filter :method => :ClearIP_query. Si ya usa label routing u otros before_filters, coloque ClearIP_query de último.

La atestación en el modelo SIP no es una configuración de URL separada. El NAP de ClearIP lleva el rol de atestación a través de la columna service_type (que se describe a continuación). Si necesita diferenciar autenticación y verificación, cree NAPs y rutas separados en lugar de endpoints de URL separados.

3. Configure las columnas de NAP

En ProSBC, el rol que cada NAP desempeña en el flujo STIR/SHAKEN se establece con una columna de NAP llamada service_type. Cree la columna una vez con los valores permitidos NORMAL | AUTHENTICATION | VERIFICATION y un valor predeterminado de NORMAL, luego asigne el valor apropiado a cada NAP:

4. Comprenda el flujo interno de firma

Cuando una llamada llega a una ruta que aterriza en un NAP con service_type=AUTHENTICATION, esto es lo que realmente sucede con ClearIP:

1. El before_filter inspecciona el INVITEEl before_filter de ClearIP_Query inspecciona el INVITE y agrega los encabezados de identificación de origen que ClearIP necesita para autenticar la solicitud.
2. ProSBC envía el SIP INVITE al NAP de ClearIPLa solicitud se envía a través de TCP/5060 al FQDN de ClearIP.
3. ClearIP devuelve una de cuatro respuestas SIP302 Moved Temporarily (éxito: encabezado Identity en PAI), 404 Not Found (no se detectó fraude y no se realizó firma), 503 Service Unavailable (mismo efecto que 404) o 603 Decline (fraude detectado: detener la llamada).
4. ProSBC avanza en la ruta según el Reason Cause MappingEl comportamiento de avance de ruta para cada una de estas respuestas se controla mediante el Reason Cause Mapping (configurado en el siguiente paso). La lista de rutas en sí es la cadena de failover en el modelo SIP.

Para la verificación (service_type=VERIFICATION), el flujo es idéntico excepto que ClearIP devuelve el parámetro Verstat en el PAI en lugar de un encabezado Identity.
Para proveedores STI-AS basados en HTTPS, el flujo equivalente es un HTTPS POST con un cuerpo de respuesta JSON que contiene los campos Identity_header, origination_id y attestation_info; los mecanismos de failover y política en esa ruta son diferentes y están fuera del alcance de esta guía.

5. Configure la Route Retry Action para los Reason Causes

Dado que el modelo SIP utiliza el avance de ruta como mecanismo de failover y política, debe configurar la Route Retry Action para cada código de Reason Cause que ClearIP puede devolver. En Profiles → Edit Reason Cause Mapping, configure:

Respuesta SIP	Route Retry Action	Valor predeterminado de ProSBC
302 Moved Temporarily	Process call routing	Ya es correcto
404 Not Found	Continue call	El valor predeterminado es “Stop call”; cámbielo
503 Service Unavailable	Continue call	Ya es correcto
603 Decline	Stop call	El valor predeterminado es “Continue call”; cámbielo

Implementación de la atestación

La distinción entre los tipos de solicitud SIGNING y ATTESTATION es importante para los proveedores que desempeñan diferentes roles en la ruta de la llamada.
Use SIGNING cuando usted es el proveedor de servicios de origen y necesita crear un nuevo encabezado Identity desde cero. El servicio de firma genera el PASSporT, lo firma con su certificado y devuelve el encabezado Identity completo.
Use ATTESTATION cuando una llamada llega con información de identidad existente (quizás un origination_id o attestation_info de un proveedor upstream) y necesita aplicar o modificar el nivel de atestación. El endpoint de atestación usa el nombre de método identity_attestation y envía los datos de identidad existentes junto con su decisión de atestación.

Tomar decisiones de atestación

Su nivel de atestación debe reflejar con precisión su relación con la llamada. La FCC responsabiliza al proveedor que firma por la exactitud de la atestación. A continuación se presenta un marco práctico:

• Asigne nivel A cuando el llamante es su suscriptor directo, usted ha verificado su identidad y está autorizado a usar el número de origen que presenta. Para un MSP, esto significa que la llamada se origina desde un cliente cuyas credenciales SIP usted gestiona y cuyas asignaciones de DID usted controla.
• Asigne nivel B cuando la llamada proviene de una troncal upstream autenticada (usted conoce al proveedor), pero no puede verificar de forma independiente el derecho del llamante a usar el número específico. Esto es típico para proveedores VoIP que reciben tráfico de socios mayoristas o revendedores.
• Asigne nivel C cuando la llamada ingresa a su red desde una fuente no verificable: un gateway PSTN, una interconexión internacional o un proveedor upstream que no autentica a sus usuarios.

El escenario de autoatestación

Algunos operadores upstream han reducido el nivel de atestación que proporcionan a los proveedores downstream. Por ejemplo, operadores que anteriormente ofrecían atestación de nivel A ahora solo proporcionan nivel C, obligando a los proveedores más pequeños a obtener sus propios certificados y autoatestarse. Si su operador upstream solo le otorga atestación de nivel C y usted puede verificar de forma independiente la identidad del llamante y la autorización del número, puede y debe firmar la llamada usted mismo al nivel superior apropiado usando su propio certificado. Consulte nuestra guía sobre cómo pasar de atestación de nivel C a autoatestación de nivel A para el marco operativo completo.

Verificación en el lado de terminación

En el lado de terminación, su SBC recibe llamadas entrantes que pueden o no incluir un encabezado Identity.
Cuando el NAP entrante enruta hacia un NAP con service_type=VERIFICATION, ProSBC reenvía la llamada (con su encabezado Identity) al servicio de verificación a través de SIP. El servicio de verificación comprueba la firma digital contra el certificado, valida la cadena de certificados, confirma que el token no ha expirado y devuelve el resultado como un SIP 302 con el parámetro Verstat en el encabezado P-Asserted-Identity (o 404/503 si no hay señal disponible). ProSBC toma la cadena Verstat y la reenvía al siguiente destino, donde la política downstream puede actuar sobre ella.
Con base en el resultado de la verificación, usted define la política en su lógica de enrutamiento:

• Verificado, atestación de nivel A: alta confianza. Enrute normalmente.
• Verificado, atestación de nivel B o C: menor confianza pero correctamente firmado. Enrute normalmente, aunque puede optar por marcar la llamada o aplicar filtrado de fraude adicional mediante integraciones como TransNexus ClearIP, SecureLogix o YouMail.
• Verificación fallida o sin encabezado Identity: la llamada no está firmada o la firma es inválida. Dependiendo de su tolerancia al riesgo, puede enrutar normalmente (muchas llamadas legítimas de proveedores más pequeños aún no están firmadas), marcar la llamada para monitoreo, aplicar filtrado adicional o rechazar la llamada.

ProSBC admite la integración con Neustar como ruta de verificación dedicada. Al usar Neustar, configure la columna de NAP service_type como VERIFICATION en el NAP entrante correspondiente, y el filtro nuestar_query maneja la solicitud de verificación automáticamente.

Arquitectura de redundancia y failover

La disponibilidad del servicio de firma impacta directamente la completación de llamadas si su implementación no contempla las fallas. El módulo STIR/SHAKEN de ProSBC incluye un diseño de failover de tres niveles expresado a través de la propia lista de rutas:

Nivel 1: NAP primario de ClearIP

Todas las solicitudes de firma para esa clase de tráfico van aquí primero. El Remapped NAP de primera prioridad de la ruta es el NAP primario.

Nivel 2: NAP secundario de ClearIP (o STI-AS alternativo)

Una segunda ruta con menor prioridad apunta a un NAP secundario: ya sea el FQDN redundante de ClearIP, una región diferente o un proveedor STI-AS completamente diferente. Si el primario devuelve un SIP 503 o se agota el tiempo de espera, ProSBC avanza en la ruta hacia el secundario según el Reason Cause Mapping configurado anteriormente.

Nivel 3: ruta de bypass

Una ruta final con la prioridad más baja envía la llamada a su destino sin pasar por ningún STI-AS. Si tanto el Nivel 1 como el Nivel 2 fallan, la llamada se completa de todas formas. Para implementaciones basadas en HTTPS, el equivalente final es el encabezado P-Identity-Bypass que el módulo StirShakenSapi agrega después de agotar ambas URLs; en el modelo SIP el mismo resultado se logra mediante el orden de las rutas.

Consideraciones de monitoreo

Monitoree estas métricas para asegurar que su implementación de STIR/SHAKEN se mantenga saludable:

• Tasa de éxito de firma es el porcentaje de llamadas firmadas exitosamente en comparación con las que pasaron al bypass. Un aumento repentino en los eventos de bypass indica un problema con el servicio de firma.
• Latencia de firma mide el tiempo desde la consulta HTTP o SIP hasta la respuesta. Una latencia creciente puede indicar degradación del servicio de firma antes de que se convierta en una interrupción.
• Distribución de atestación es el desglose de los niveles de atestación A, B y C en su tráfico. Cambios inesperados (por ejemplo, un aumento repentino en llamadas de nivel C) pueden indicar un cambio en los patrones de tráfico upstream.
• Tasa de falla de verificación en el lado de terminación es el porcentaje de llamadas donde la verificación falla. Tasas altas pueden indicar problemas de certificados, desincronización de reloj o tráfico falsificado.

La salida CDR, las traps SNMP y la capacidad de trazado de logs de ProSBC (configure el nivel de trazado 2 para eventos STIR/SHAKEN) proporcionan los datos necesarios para este monitoreo. Para proveedores que desean monitoreo sin intervención, TelcoBridges ofrece Monitoring as a Service (MaaS) como producto independiente.

Errores comunes de implementación

Estos son los errores que con mayor frecuencia retrasan o rompen las implementaciones de STIR/SHAKEN:

Pruebas de su implementación

Use un entorno de laboratorio primero

ProSBC Lab es una licencia gratuita y permanente de 3 sesiones diseñada exactamente para este tipo de pruebas. Puede desplegar una instancia de laboratorio en aproximadamente 20 minutos, configurar la firma STIR/SHAKEN contra el entorno de pruebas de su servicio de firma y validar el flujo completo antes de tocar producción.

Pasos de verificación

• Verifique la inyección del encabezado Identity. Use la captura en vivo de Wireshark de ProSBC o el trazado de llamadas para inspeccionar los SIP INVITEs salientes. El encabezado Identity debe estar presente en cada llamada firmada, conteniendo el PASSporT completo con la referencia a su certificado.
• Valide los niveles de atestación. Verifique que los niveles de atestación A, B y C se estén asignando correctamente según su configuración de rutas y el origen de la llamada. Su proveedor de servicio de firma puede ofrecer un panel de pruebas que muestre los desgloses de atestación.
• Pruebe el failover. Bloquee la conectividad SIP hacia el NAP primario de ClearIP (bloquee la IP de destino en el firewall o deshabilite el NAP en ProSBC) y confirme que ProSBC avanza en la ruta hacia el NAP secundario y que la llamada se completa con un encabezado Identity. Luego bloquee ambos NAPs y confirme que la llamada avanza hacia su ruta de bypass. Para implementaciones basadas en HTTPS, el estado final equivalente es el encabezado P-Identity-Bypass en el INVITE saliente.
• Prueba de extremo a extremo. Origine una llamada firmada desde su SBC y verifique en el extremo de terminación que el encabezado Identity está presente y la firma se valida. Si tiene un segundo SBC o una cuenta de prueba con un proveedor de terminación, puede verificar la cadena completa.
• Revise los logs. El módulo STIR/SHAKEN de ProSBC registra en el nivel de trazado 2. Las entradas clave de log a buscar son: “Send to first signing domain,” “HTTP server returned 200,” “Added Identity header,” y el cuerpo completo de la respuesta JSON. Si ve “This is the third iteration, send call anyway adding Bypass SIP header,” su servicio de firma está fallando.

Elegir una arquitectura de servicio de firma abierta vs. cerrada

No todos los SBCs implementan STIR/SHAKEN de la misma manera. La decisión arquitectónica que toma su proveedor de SBC determina su flexibilidad como proveedor. Para una visión más amplia de cómo se comparan los modelos de firma abiertos y propietarios, consulte STIR/SHAKEN y autenticación de llamadas.

Implementaciones propietarias

Las implementaciones propietarias (comunes con Ribbon y Oracle) acoplan estrechamente el SBC a un servicio de firma específico o requieren el propio servidor de políticas del fabricante como intermediario. Esto simplifica la implementación inicial pero lo ata al ecosistema del fabricante para servicios de firma, precios y disponibilidad de funciones.

Modelo de API abierta (ProSBC)

El modelo de API abierta trata al servicio de firma como un componente externo e intercambiable conectado a través de SIP o HTTPS, según prefiera el proveedor STI-AS. El motor de enrutamiento configurable de ProSBC se integra con TransNexus ClearIP y Neustar a través de SIP hoy, y admite HTTPS POST/JSON para proveedores STI-AS que lo requieran. Esto significa que puede elegir TransNexus, Neustar o cualquier otro proveedor STI-AS. Puede cambiar de proveedor sin modificar la configuración de su SBC más allá de actualizar URLs y credenciales. Incluso puede ejecutar diferentes servicios de firma para diferentes tipos de tráfico (por ejemplo, un proveedor para tráfico doméstico y otro para tráfico de gateway internacional).
Este modelo abierto de socios también prepara su implementación para el futuro. A medida que el ecosistema STIR/SHAKEN evolucione y surjan nuevas funciones de los servicios de firma (analíticas avanzadas de identificación de llamadas, integración de puntuación de fraude, datos de reputación en tiempo real), podrá adoptarlas eligiendo un proveedor que las ofrezca, en lugar de esperar a que su fabricante de SBC construya una integración propietaria.

Preguntas frecuentes

Conclusión

La implementación de STIR/SHAKEN a nivel de SBC es un ejercicio de configuración sencillo una vez que los prerrequisitos administrativos están en orden y ha elegido un socio de servicio de firma. Los pasos principales son: obtener su certificado, configurar los NAPs de firma primario y secundario, establecer su lógica de atestación, habilitar el módulo de enrutamiento y probar.
Las decisiones de implementación más importantes son las que refuerza la regla de certificado propio de la FCC: su certificado, su decisión de atestación, su responsabilidad. La firma técnica puede delegarse a un tercero, pero la señal de confianza que un operador downstream o un SBC de terminación ve en el encabezado Identity siempre se remonta al proveedor de origen.