> ## 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: Umgang mit Anfragen zu Ursprungsnummern > ITG-Traceback-Anfragen (Industry Traceback Group) zu Ihren Ursprungsnummern loggen, bestätigen und beantworten — der Fall-Lebenszyklus, die 24-Stunden-Response-SLA und die Dispositionen, die Sie einreichen. # ITG-Traceback-Fallbearbeitung Ihr ausgehender US-Sprachverkehr mit STIR/SHAKEN-Attestation zu signieren schafft eine downstream-Pflicht: wenn eine Ihrer Ursprungsnummern in einer Robocall-Beschwerde impliziert ist, kann die Industry Traceback Group (ITG) eine **Traceback-Anfrage** an Sie senden, die Sie bittet, die Quelle des Anrufs zu identifizieren; und eine Antwort wird erwartet, typischerweise innerhalb von etwa 24 Stunden (ein Werktag). Orbit stellt die Fallmanagement-Fläche für diese Pflicht bereit: einen Ort, jede eingehende ITG-Anfrage zu loggen, zu bestätigen, Ihre Disposition einzureichen und die Response-Deadline zu beobachten. Jede Kontrolle auf dieser Seite ist **mandanteneigene** — Sie loggen die Anfrage, Sie entscheiden die Disposition, Sie reichen sie bei der ITG ein. Alle Endpunkte unten sind ge-rooted auf `https://api.orbit.devotel.io/api/v1/compliance`. Traceback-Antwort ist Teil der FCC-Robocall-Mitigation unter dem TRACED Act (die ITG wird von USTelecom im Rahmen des FCC-Rahmens betrieben). Bestätigte Traceback-Anfragen konstant zu ignorieren ist an sich ein Compliance-Risiko-Faktor, der zu Enforcement und Carrier-De-Peering eskalieren kann. Diese Seite ist keine Rechtsberatung — bestätigen Sie Ihre Traceback-Pflichten und -Deadlines mit Rechtsbeistand. *** ## Warum Attestation diese Pflicht schafft STIR/SHAKEN ist das Caller-ID-Authentifizierungs-Rahmen, das der FCC für US-Sprachverkehr vorschreibt. Jeder ausgehende Anruf, den Sie über Orbit platzieren, wird bei der Signierung mit einem Attestierungs-Level (A, B oder C) beauflagt — siehe [STIR/SHAKEN-Attestation](/channels/voice/stir-shaken) für die Bedeutung der Levels und wie Orbit sie erreicht. Weil Ihr signierter Verkehr auf Sie zurückattributiert werden kann, können Downstream-Anbieter und die ITG (ATIS/FCC Traceback-Rahmen) Sie fragen, woher ein implizierter Anruf kam. Diese Anfragen prompt zu beantworten und ein Protokoll über das Gefundene zu halten ist Teil der Robocall-Mitigationspflichten, die mit dem Ursprung signierter Anrufe einhergehen. ## Fall-Lebenszyklus Jeder Traceback-Fall durchläuft vier Zustände: | Von \ Nach | `acknowledged` | `responded` | `closed` | | ------------------- | -------------- | ----------- | -------- | | `received` | Ja | Ja | Ja | | `acknowledged` | — | Ja | Ja | | `responded` | — | — | Ja | | `closed` (terminal) | — | — | — | * `received` — die ITG-Anfrage ist geloggt, noch nicht bearbeitet. * `acknowledged` — Sie haben den ITG-Eingang bestätigt. * `responded` — Sie haben Ihre Disposition bei der ITG eingereicht. * `closed` — der Fall ist abgeschlossen (terminal; keine weiteren Übergänge). Eine ungültige Übergangs (z. B. den Bestätigen eines `closed`-Falls oder ein zweites Respondieren) gibt `409` mit `TRACEBACK_INVALID_TRANSITION`. ## Response-Deadline-SLA Jeder Fall trägt eine Response-Deadline-Uhr. Das Standard-Fenster ist **24 Stunden** ab `received_at`, was die konservative Kodierung des ITG- One-Business-Day-Erwartens ist. Sie können ein engeres oder weiteres Fenster pro Fall mit `sla_hours` (bis 720) setzen, wenn die ITG eine andere Deadline angibt. Sie fragen den SLA-Zustand nie direkt ab — jeder `GET` auf der Traceback-Fläche annotiert jeden Fall mit einem **Live-Urteil** zum Lesezeitpunkt: ```json theme={null} { "sla": { "due_at": "2026-08-27T09:15:00.000Z", "status": "due_soon", "hours_remaining": 3, "breached": false, "reason": "The ITG response window closes soon; respond to avoid breaching the traceback SLA." } } ``` | `status` | Bedeutung | | ---------- | --------------------------------------------------------------------------------- | | `on_track` | Offen, bequem vor der Deadline. | | `due_soon` | Offen, innerhalb von 4 Stunden zur Deadline. | | `met` | Zur oder vor der Deadline geantwortet. | | `breached` | Deadline vergangen ohne Antwort, oder die Antwort war zu spät (`breached: true`). | | `unknown` | Der Received-at-Timestamp ist nicht parsebar, keine Deadline berechenbar. | ## Eine Traceback-Anfrage Schritt für Schritt behandeln Alle Writes unten brauchen die **Owner- oder Admin-Rollen-Rolle**; Reads sind für jedes authentifizierte Mitglied offen. ### 1. Die eingehende Anfrage loggen Wenn eine ITG-Traceback-Anfrage eintrifft, loggen Sie sie, um die Uhr zu starten. Geben Sie die ITG-Referenz, die implizierende Ursprungsnummer (E.164), und optional eine Beschreibung der implizierenden Kampagne, den Attestierungs-Level auf diesem Verkehr und eine benutzerdefinierte Deadline. ```bash theme={null} curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/traceback" \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "traceback_ref": "ITG-2026-11843", "source_number": "+14155550101", "campaign_description": "Outbound-Erneuerungs-Kampagne in einer Robocall-Beschwerde implant", "attestation": "A", "notes": "Erhalten über das ITG-Portal am 2026-08-26" }' ``` Der Fall wird im `received`-Zustand erstellt und die 24-Stunden-Deadline startet ab Log-Zeit. Halten Sie die `id`-Antwort für die nächsten Schritte. ### 2. Eingang bestätigen Zur ITG bestätigen, dass die Anfrage bearbeitet wird. Das bewegt den Fall zu `acknowledged` und ist optional — Sie können direkt vom `received` antworten. ```bash theme={null} curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/traceback/tb_a1b2c3d4/acknowledge" \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{"notes": "Der ITG unter ihrer Referenz ITG-2026-11843 bestätigt"}' ``` ### 3. Ihre Antwort einreichen Sobald Sie investigiert haben, zeichnen Sie die Disposition auf. Das stoppt die Response-Deadline-Uhr und schließt mit `"close": true` den Fall im selben Aufruf. ```bash theme={null} curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/traceback/tb_a1b2c3d4/respond" \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "disposition": "source_identified", "notes": "Verkehr auf Unter-Konto supplier-7 zurückverfolgt; Quellenidentifikation der ITG geliefert.", "close": true }' ``` ### Dispositionen Wählen Sie die Disposition, die beantwortet „was haben Sie über den implizierten Verkehr getan?": | Disposition | Bedeutung | | --------------------- | -------------------------------------------------------------------------- | | `source_identified` | Sie identifizierten die Upstream-/Kunden-Quelle und übergaben sie der ITG. | | `customer_notified` | Sie haben den implizierten Kunden informiert. | | `customer_terminated` | Sie haben den implizierten Kunden oder die Kampagne abgeschaltet. | | `number_disabled` | Sie haben die implizierte Ursprungsnummer deaktiviert. | | `not_originated_here` | Der Verkehr stammte nicht von Ihrem Konto. | | `no_action` | Sie haben geprüft und nichts unternommen (in `notes` erklären). | ### 4. Fälle prüfen Listen Sie jeden Fall mit seinem Live-SLA-Urteil, oder holen Sie einen Fall per id: ```bash theme={null} curl "https://api.orbit.devotel.io/api/v1/compliance/traceback" \ -H "Authorization: Bearer $ORBIT_API_KEY" ``` ```bash theme={null} curl "https://api.orbit.devotel.io/api/v1/compliance/traceback/tb_a1b2c3d4" \ -H "Authorization: Bearer $ORBIT_API_KEY" ``` Fälle listen neueste zuerst, sodass ein offener Fall, der seiner Deadline nähert, ab Seite eins sichtbar ist. *** ## Nur Protokollfläche Die Traceback-Fläche **erhält, verfolgt und zeichnet** — sonst nichts. Das Loggen eines Falls, das Bestätigen und das Einreichen einer Antwort persistiert Zustand; sie tätigen nie einen Anruf, senden nie eine Nachricht oder kontaktieren die ITG oder den implizierten Kunden in Ihrem Namen. Das Einreichen einer Antwort protokollieren die gewählte Disposition; das Liefern dieser Antwort der ITG (ihrem Portal oder Kanal) und jede Downstream-Kundenbenachrichtigung bleiben Ihre Handlungen, außerhalb dieser Fläche. Diese Grenze ist bewusst: Compliance-Case-Tracking darf nie ein Outbound-Pfad werden. ## Zugriffskontrolle, Audit und Speicherung * **Rollen.** Writes (`POST /traceback`, `/acknowledge`, `/respond`) brauchen die **Owner- oder Admin**-Rolle, spiegelnd dem Rest der Compliance-Schreibfläche. Reads sind für jedes authentifizierte Organisationsmitglied offen. * **Audit-Trail.** Jede Zustandsänderung schreibt einen dauerhaften [Audit-Log](/compliance/consent-management)-Eintrag — `compliance.traceback.received`, `compliance.traceback.acknowledged` und `compliance.traceback.responded` — mit dem agierenden Benutzer, der ITG-Referenz und (bei einer Antwort) der Disposition und ob die Deadline gehalten wurde. Die implizierte Nummer ist in Audit-Details maskiert. * **Speicherung.** Fälle sind auf den Einstellungen Ihrer Organisation als server-generierter, per-Fall-Key gespeichert, sodass zwei Teammitglieder verschiedene Fälle (oder andere Einstellungen) gegenseitig nie überschreiben. ## Die SLA beobachten Bauen Sie den Listen-Endpunkt in Ihren Ops-Loop, damit ein Bruch nie eine Überraschung ist: 1. Polling `GET /traceback` auf einer regelmäßigen Kadenz für ein Business-Day-Fenster reicht stündlich. 2. Alarmieren, wenn irgendein offener Fall `sla.status: "due_soon"` oder `sla.status: "breached"`, oder `sla.breached: true` meldet. 3. Rufen Sie die Compliance-Eignerin, wenn ein Bruch auftritt — ein overdue Traceback ist das Signal, das Carrier und der FCC am schwersten tragen. Dasselbe `GET`-Zeit-Urteil-Muster, das die [Compliance-Gesundheitswerte](/compliance/compliance-health)-Fläche antreibt, gilt hier: Scores warnen Sie vor Carrier-Throttling, und Traceback-Urteile warnen Sie vor einer Eskalation — behandeln Sie beide als Frühwarn-Feeds in Ihre Compliance-Posture. *** ## Verwandte Referenzen * [ITG-Traceback-Workflow im Dashboard](/guides/compliance-traceback-itg) — der Operator-Leitfaden für die Konsole unter **Einstellungen → Compliance → ITG Traceback**. * [STIR/SHAKEN-Attestation](/channels/voice/stir-shaken) — die Signierung, die die Traceback-Pflicht schafft, Attestierungs-Level und die Kontrollen, die Sie besitzen. * [Send Gates](/compliance/send-gates) — die Ruhezeiten-, DNC-, RND- und RMD-Prüfungen, die zum Sendezeitpunkt laufen. * [Compliance-Gesundheitswerte](/compliance/compliance-health) — die 0–100-Risikoscores für Ihre Organisation, Absender und Kampagnen. * [Compliance-Posture-Übersicht](/compliance/posture-overview) — wie die einzelnen Compliance-Flächen zusammenpassen. * [API-Referenz → Compliance](/api-reference/endpoints/compliance) — volle Request/Response-Schemas (aus der Live-API regeneriert).