​

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.

​

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 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 — 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.

​

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: 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), 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 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 fold back into your posture risk.

---

​

Deep dives

• ITG Traceback API reference — the endpoint surface behind this console, case states, and the disposition values.
• STIR/SHAKEN attestation — the signing that creates the traceback obligation.
• Manage outbound caller IDs — the numbers a traceback request can implicate, and how presentation resolves.
• SMS-pumping protection — the pre-send risk scoring that shrinks the traffic traceback requests originate from.
• Recording lifecycle — the call recordings you pull as response evidence.