Skip to main content

​
Gestión de casos de ITG Traceback

Firmar su tráfico de voz saliente de EE. UU. con attestación STIR/SHAKEN conlleva una obligación derivada: cuando uno de sus números de origen queda implicado en una reclamación por robocalls, el Industry Traceback Group (ITG) puede enviarle una solicitud de traceback pidiéndole que identifique el origen de la llamada, y se espera que usted responda, normalmente en unas 24 horas (un día laborable). Orbit proporciona la superficie de gestión de casos para esa obligación: un lugar para registrar cada solicitud ITG entrante, acusarla recibo, presentar su disposición y vigilar el plazo de respuesta. Cada control de esta página es propiedad del tenant — usted registra la solicitud, usted decide la disposición, usted la presenta al ITG. Todos los endpoints siguientes tienen la raíz https://api.orbit.devotel.io/api/v1/compliance.
La respuesta a traceback es parte de la mitigación de robocalls de la FCC bajo la Ley TRACED (el ITG es operado por USTelecom dentro del marco de la FCC). Ignorar de forma constante las solicitudes de traceback es por sí mismo una señal de alarma de cumplimiento que puede escalar a aplicación y desvinculación por los operadores. Esta página no es asesoramiento legal — confirme sus obligaciones y plazos de traceback con un abogado.

​
Por qué la attestación crea esta obligación

STIR/SHAKEN es el marco de autenticación de identificador de llamada que la FCC exige para el tráfico de voz de EE. UU. A cada llamada saliente que usted realiza a través de Orbit se le asigna un nivel de attestación (A, B o C) en la firma — consulte Attestación STIR/SHAKEN para el significado de los niveles y cómo Orbit los alcanza. Debido a que su tráfico firmado puede atribuirse a usted, los proveedores downstream y el ITG (marco de traceback ATIS/FCC) pueden preguntarle de dónde vino una llamada implicada. Responder a esas solicitudes con prontitud y conservar un registro de lo que encontró es parte de los deberes de mitigación de robocalls que vienen con originar tráfico firmado.

​
Ciclo de vida del caso

Cada caso de traceback atraviesa cuatro estados:
  • received — la solicitud ITG queda registrada, aún no trabajada.
  • acknowledged — usted confirmó la recepción ante el ITG.
  • responded — usted presentó su disposición ante el ITG.
  • closed — el caso está resuelto (terminal; sin más transiciones).
Una transición inválida (por ejemplo, acusar recibo de un caso closed, o responder dos veces) devuelve un 409 con TRACEBACK_INVALID_TRANSITION.

​
SLA de plazo de respuesta

Cada caso lleva un reloj de plazo de respuesta. La ventana predeterminada es de 24 horas desde received_at, que es la codificación conservadora de la expectativa ITG de un día laborable. Puede establecer una ventana más ajustada o más holgada por caso con sla_hours (hasta 720) cuando el ITG indica un plazo diferente. Nunca consulta el estado del SLA directamente — cada GET sobre la superficie de traceback anota cada caso con un veredicto en vivo calculado en el momento de la lectura:

​
Gestión de una solicitud de traceback, paso a paso

Todas las escrituras siguientes requieren el rol de owner o admin; las lecturas están abiertas a cualquier miembro autenticado.

​
1. Registre la solicitud entrante

Cuando llega una solicitud de traceback del ITG, regístrela para iniciar el reloj. Proporcione la referencia del ITG, el número de origen implicado (E.164) y, opcionalmente, una descripción de la campaña implicada, el nivel de attestación declarado en ese tráfico, y un plazo personalizado.
El caso se crea en estado received y el plazo de 24 horas comienza desde la hora del registro. Conserve el id de la respuesta para los pasos siguientes.

​
2. Acuse recibo

Confirme al ITG que la solicitud se está trabajando. Esto mueve el caso a acknowledged y es opcional — puede responder directamente desde received.

​
3. Presente su respuesta

Una vez investigado, registre la disposición. Esto detiene el reloj del plazo de respuesta y, con "close": true, cierra el caso en la misma llamada.

​
Disposiciones

Elija la disposición que responde a “¿qué hizo usted con el tráfico implicado?”:

​
4. Revise los casos

Liste todos los casos con su veredicto SLA en vivo, o recupere un caso por id:
Los casos se listan con la solicitud más reciente primero, por lo que cualquier caso abierto que se acerque a su plazo es visible desde la primera página.

​
Superficie de solo registro

La superficie de traceback recibe, rastrea y registra — nada más. Registrar un caso, acusarlo recibo y presentar una respuesta persisten estado; nunca realizan una llamada, envían un mensaje ni contactan al ITG o al cliente implicado en su nombre. Presentar una respuesta registra la disposición que usted eligió; entregar esa respuesta al ITG (su portal o canal) y cualquier notificación al cliente downstream siguen siendo acciones suyas, fuera de esta superficie. Este límite es deliberado: el seguimiento de casos de cumplimiento nunca debe convertirse en una ruta saliente.

​
Control de acceso, auditoría y almacenamiento

  • Roles. Las escrituras (POST /traceback, /acknowledge, /respond) requieren el rol de owner o admin, reflejando el resto de la superficie de escritura de cumplimiento. Las lecturas están disponibles para cualquier miembro autenticado de la organización.
  • Rastro de auditoría. Cada cambio de estado escribe una entrada durable en el log de auditoría — compliance.traceback.received, compliance.traceback.acknowledged y compliance.traceback.responded — con el usuario actuante, la referencia ITG y (en una respuesta) la disposición y si el plazo se cumplió. El número implicado se enmascara en los detalles de auditoría.
  • Almacenamiento. Los casos se almacenan en la configuración de su organización como claves generadas por el servidor, una por caso, para que dos compañeros trabajando casos diferentes (u otras configuraciones) concurrentemente nunca se sobrescriban entre sí.

​
Vigilar el SLA

Incorpore el endpoint de lista a su ciclo de operaciones para que una brecha nunca sea una sorpresa:
  1. Sondee GET /traceback en una cadencia regular (cada hora basta para una ventana de un día laborable).
  2. Alerte cuando cualquier caso abierto reporta sla.status: "due_soon" o sla.status: "breached", o sla.breached: true.
  3. Avise al propietario de cumplimiento cuando aparezca una brecha — un traceback vencido es la señal que los operadores y la FCC pesan más.
El mismo patrón de veredicto en el momento del GET que alimenta la superficie de puntuaciones de salud de cumplimiento se aplica aquí: las puntuaciones le avisan antes del throttling de los operadores, y los veredictos de traceback le avisan antes de una escalación — trate ambos como fuentes de alerta temprana hacia su postura de cumplimiento.

​
Referencias relacionadas