Entwickler-Kochbuch

Compliance-Archiv-Kochbuch - Aufzeichnungen, Transkripte, CDR.

Drei mandantenbezogene Archiv-Endpunkte in signal.ashx: Anrufaufzeichnungen (WAV + JSON-Sidecar), KI-Transkripte (JSON mit _transcriptTurns), CDR (Call Detail Records, CSV oder JSON). Jeder Endpunkt ist Bearer-authentifiziert (ak_-API-Key oder Admin-OIDC), mandantenbezogen ueber den Request-Host und ehrlich im Kontext der NIS2- und DORA-Archivintegritaetspflichten eingeordnet. European Digital Identity Wallet-faehige Mandanten nutzen dieselbe Authentifizierung.

Aufgabe A - Anrufaufzeichnungen auflisten und abrufen

Endpunkte im Livecode verifiziert: GET /signal.ashx?recordings-list=1 gibt {ts, tenant, rootDisplay, rootExists, countAll, countReturned, totalBytes, items[]}, gefolgt von GET /signal.ashx?recording=<callId>&download=1 fuer den WAV-Bytestream. Auth: Authorization: Bearer ak_... oder Admin-OIDC-Bearer.

SpracheBibliothekRezeptSnippet
cURLplain shellOeffnenfetch-recordings-curl.sh
Node.jsaxios / wsOeffnenfetch-recordings-nodejs.js
Pythonrequests / websocketsOeffnenfetch-recordings-python.py
PHPcurlOeffnenfetch-recordings-php.php
.NETHttpClientOeffnenfetch-recordings-dotnet.cs

Recording-Abruf - cURL Rezept

Rohdatei laden: fetch-recordings-curl.sh

Recording-Abruf - Node.js Rezept

Rohdatei laden: fetch-recordings-nodejs.js

Recording-Abruf - Python Rezept

Rohdatei laden: fetch-recordings-python.py

Recording-Abruf - PHP Rezept

Rohdatei laden: fetch-recordings-php.php

Recording-Abruf - .NET Rezept

Rohdatei laden: fetch-recordings-dotnet.cs

Aufgabe B - KI-Transkripte auflisten und abrufen

Endpunkte im Livecode verifiziert: GET /signal.ashx?list-transcripts=1 liefert {count, errors, dirs[], items[]}, dann GET /signal.ashx?get-transcript=<basename>.json fuer die vollstaendige JSON-Datei mit dem Array _transcriptTurns (geschrieben von GeminiTranscriberTap). Auth-Modell: Bearer erforderlich (Admin-OIDC oder ak_-API-Key). Der HMAC-Header wird bei diesem Endpunkt heute nicht angenommen.

SpracheBibliothekRezeptSnippet
cURLplain shellOeffnenfetch-transcripts-curl.sh
Node.jsaxios / wsOeffnenfetch-transcripts-nodejs.js
Pythonrequests / websocketsOeffnenfetch-transcripts-python.py
PHPcurlOeffnenfetch-transcripts-php.php
.NETHttpClientOeffnenfetch-transcripts-dotnet.cs

Transkript-Abruf - cURL Rezept

Rohdatei laden: fetch-transcripts-curl.sh

Transkript-Abruf - Node.js Rezept

Rohdatei laden: fetch-transcripts-nodejs.js

Transkript-Abruf - Python Rezept

Rohdatei laden: fetch-transcripts-python.py

Transkript-Abruf - PHP Rezept

Rohdatei laden: fetch-transcripts-php.php

Transkript-Abruf - .NET Rezept

Rohdatei laden: fetch-transcripts-dotnet.cs

Aufgabe C - CDR (Call Detail Records) exportieren

Endpunkt im Livecode verifiziert: GET /signal.ashx?cdrlog=1 mit optionalen Filtern direction=in|out|transit, trunk=, date=YYYY-MM-DD, limit=N, q=. Antwort: JSON {events[], count, trunks[], dates[]}. Fuegen Sie format=csv hinzu, um dieselben Zeilen als CSV zu erhalten mit den Spalten recordedUtc, startUtc, endUtc, direction, trunk, callingNumber, calledNumber, durationSec, answered, outcome, releaseReason. Ideal fuer BI-Ingest.

SpracheBibliothekRezeptSnippet
cURLplain shellOeffnenexport-cdr-curl.sh
Node.jsaxios / wsOeffnenexport-cdr-nodejs.js
Pythonrequests / websocketsOeffnenexport-cdr-python.py
PHPcurlOeffnenexport-cdr-php.php
.NETHttpClientOeffnenexport-cdr-dotnet.cs

CDR-Export - cURL Rezept

Rohdatei laden: export-cdr-curl.sh

CDR-Export - Node.js Rezept

Rohdatei laden: export-cdr-nodejs.js

CDR-Export - Python Rezept

Rohdatei laden: export-cdr-python.py

CDR-Export - PHP Rezept

Rohdatei laden: export-cdr-php.php

CDR-Export - .NET Rezept

Rohdatei laden: export-cdr-dotnet.cs

Auth-Modell

Alle drei Endpunkte akzeptieren Authorization: Bearer <token>, wobei der Token entweder ein ak_-praefixierter API-Key ist (siehe M2M-Kochbuch) oder ein Admin-OIDC-Access-Token. Recordings und CDR akzeptieren zusaetzlich einen HMAC-Header X-CodeB-Admin-Signature fuer Legacy-Interne-Jobs. Der Transcripts-Endpunkt akzeptiert ausschliesslich Bearer.

Share-Link-Modell

Admins koennen einen anonymen, nur lesbaren, zeitlich begrenzten Share fuer eine einzelne Aufzeichnung (create-recording-share) oder ein einzelnes Transkript (create-transcript-share) erzeugen. Der zurueckgegebene token ergibt eine oeffentliche URL unter recording-shares.html bzw. transcript-shares.html. Der Share-Stream setzt Anti-Download-Header; das WAV wird inline abgespielt. Shares sind mit einem Klick widerrufbar.

Retention-Modell

Retention ist mandantenbezogen ueber Recording:RetentionDays in den Bridge-appsettings gesteuert. Bridge-Standard 90 Tage; einzelne Mandanten koennen den Zeitraum anpassen. Der Sweeper laeuft im Bridge-Prozess, nicht in signal.ashx.

Rechtlicher Rahmen - NIS2 / DORA / CRA

Aufzeichnungen, Transkripte und CDR unterstuetzen Pflichten aus NIS2 (sichere Protokoll-aufbewahrung), DORA (Vorfallnachweis im Finanzsektor) und dem EU Cyber Resilience Act (Produkt-Auditierbarkeit). Die Archiv-Schicht ist auf Mandantenisolation und Integritaet ausgelegt. Wir benennen die Grenzen offen:

RASP-Posture

Jeder Archiv-Endpunkt betreibt inline Anomalie-Erkennung + Integritaetspruefungen mit lauten [api-key-diag]-, [REC-*]-, [TRANSCRIBE-*]- und [cdr-*]-Diagnosen. Pro Request wird der Tenant-Host-Header gebunden; Sidecars mit abweichendem tenant-Feld werden uebersprungen und protokolliert. Dateinamen unterliegen einer strikten [A-Za-z0-9._-]-Allowlist gegen Path-Traversal.

FAQ

Strukturierte Antworten sind im Schema-Block oben eingebettet.