> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # ITG traceback workflow in the dashboard > View, acknowledge, and respond to Industry Traceback Group requests for your STIR/SHAKEN-signed originating numbers from the compliance console — before the response deadline closes. # ITG traceback workflow in the dashboard When a caller-ID complaint names one of your originating numbers, the Industry Traceback Group (ITG) can send you a **traceback request** — a formal ask to identify where the implicated call came from. The traceback console at **Settings → Compliance → ITG Traceback** is where you log those requests, acknowledge them, file your disposition, and watch the live response deadline for every open case. Every control here is **tenant-owned**: you log the request, you investigate, you choose the disposition, and you deliver your response to the ITG. Orbit tracks the case and its deadline — it never contacts the ITG or a customer on your behalf. For the raw endpoints this console sits on, see the [ITG Traceback API reference](/compliance/itg-traceback). ## 1. What a traceback request is — and what signing exposes you to Signing US outbound voice traffic with STIR/SHAKEN attestation makes your calls attributable: downstream carriers and the ITG can follow the signed chain back to you and ask where a flagged call originated. Every outbound call you place through Orbit attests at level A, B, or C at signing — see [STIR/SHAKEN attestation](/channels/voice/stir-shaken) for what the levels mean. Attribution is the point of the framework, and responding to traceback requests — typically within about 24 hours, one business day — is part of the robocall-mitigation obligation that comes with it. Two practical consequences: * **The implicated number is always one you attest.** The tighter your attestation — an org-owned Orbit-hosted number at A rather than a verified external caller ID capped at B, see [Manage outbound caller IDs](/guides/voice-caller-ids) — the cleaner the chain you will have to describe back to the ITG. * **Ignoring requests is itself a red flag.** Consistently unanswered traceback requests escalate to carrier de-peering and FCC enforcement. The SLA tracking below exists so a deadline never closes quietly. This page is not legal advice. Confirm your traceback obligations and deadlines with counsel. ## 2. View incoming requests Open **Settings → Compliance → ITG Traceback** (`/settings/compliance/traceback`). The case table lists every logged request — newest first — with its ITG reference, the implicated source number, the received timestamp, its state, and a live **Response SLA** verdict recomputed each time the page loads. Log a case the moment an ITG request arrives (**Log traceback case** on the table, or the matching action on the empty state): the console asks for the ITG's reference number, the implicated source number in E.164, optionally the campaign description, the attestation asserted on that traffic, notes, and a custom deadline when the ITG states one. Logging starts the clock — the default window is 24 hours from receipt, and a case can carry a per-case window (up to 720 hours) when the ITG's deadline differs. If your intake runs over the API instead, cases logged there appear in this same table — the surface is one store. ## 3. Acknowledge, then respond with call-detail evidence before the deadline Open a case from the table to work it. Two actions, both available on the case sheet: * **Acknowledge** confirms receipt back to the ITG. It is optional — you can respond directly from a newly-received case — but acknowledging early buys goodwill with the requester while your team investigates. * **Respond** files your disposition. Pick the disposition that answers "what did you do about this traffic?" — source identified, customer notified, customer terminated, number disabled, not originated here, or no action — and write the notes you will deliver to the ITG. Responding stops the clock; ticking **Close** in the same step moves the case to terminal state. The **Response SLA** column on the list, and the deadline readout on the case sheet, keep the same live verdict: | Verdict | Meaning | | ---------- | --------------------------------------------------------------- | | `On track` | Open, comfortably before the deadline. | | `Due soon` | Open, within the last 4 hours of the window. | | `Met` | Responded on or before the deadline. | | `Breached` | The deadline passed with no response, or the response was late. | Treat `Due soon` as your escalation threshold. Responding from a `Received` case is always allowed, so there is never a state blocking you from filing. Gather your evidence before you respond: pull the CDRs for the implicated number and time window from call analytics or recordings ([Recording lifecycle](/guides/recording-lifecycle-operations)), note the attestation level your signing placed on that traffic, and identify the upstream sub-account or customer. Filing `Not originated here` when the chain genuinely does not pass through your account is a complete answer — do not let it sit to a `Breached` verdict just because nobody picked the disposition. ## 4. Escalation and attachments When a disposition needs more than short notes — a sub-account's abuse history, a specific campaign, an internal ticket — assemble the evidence (CDR extracts, recordings, the action you took on the customer) and attach the substance in your own delivery to the ITG portal. The console files a disposition plus notes; those notes carry a pointer to the evidence, but the console itself only records the case — it never transmits to the ITG or the customer. Keep the working ticket for the response inside a `Note` on the case so the next teammate can pick it up without re-deriving your finding. For repeat implicated customers, pair traceback responses with the [SMS-pumping protection](/guides/sms-pumping-protection) scoring surfaces and your own send-time gates — a customer whose traffic keeps drawing traceback requests belongs behind a pre-send risk check, not just a post-incident disposition. A `Breached` verdict is also exactly what [Compliance Health Scores](/compliance/compliance-health) fold back into your posture risk. *** ## Deep dives * [ITG Traceback API reference](/compliance/itg-traceback) — the endpoint surface behind this console, case states, and the disposition values. * [STIR/SHAKEN attestation](/channels/voice/stir-shaken) — the signing that creates the traceback obligation. * [Manage outbound caller IDs](/guides/voice-caller-ids) — the numbers a traceback request can implicate, and how presentation resolves. * [SMS-pumping protection](/guides/sms-pumping-protection) — the pre-send risk scoring that shrinks the traffic traceback requests originate from. * [Recording lifecycle](/guides/recording-lifecycle-operations) — the call recordings you pull as response evidence.