Skip to main content

​
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 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:
  • 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:

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

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

​
Dispositionen

Wählen Sie die Disposition, die beantwortet „was haben Sie über den implizierten Verkehr getan?”:

​
4. Fälle prüfen

Listen Sie jeden Fall mit seinem Live-SLA-Urteil, oder holen Sie einen Fall per id:
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-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-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