Ablage & Dateiformate
Call Recording legt je Aufzeichnung einen Dateisatz aus Audio-, Metadaten-, Transkriptions- und Signaturdateien an und überträgt ihn in die konfigurierten Speicherziele — OneDrive/SharePoint (Microsoft Graph), SFTP und SMB. Diese Seite dokumentiert das Verzeichnis- und Dateinamensschema, die Dateiformate sowie die kryptografischen Signaturen und deren Prüfung durch Dritte.
Diese Schnittstelle ist für die Nutzung durch Drittsysteme freigegeben. Änderungen und Erweiterungen werden je Version in den Release Notes dokumentiert.
Grundlagen
- Typ: Dateiablage. Drittsysteme konsumieren die Dateien direkt am Speicherziel; das Modul stellt keinen Abruf-Endpunkt bereit.
- Ablauf: Die Aufzeichnung entsteht als WAV-Datei im Arbeitsverzeichnis des Moduls
auf der Anlage (
/var/spool/asterisk/monitor/fp_monitor/<Instanz-UUID>/). Nach Gesprächsende verarbeitet das Modul den Dateisatz im 30-Sekunden-Takt: Kanalzusammenführung (bei Stereo-Aufzeichnung), Signierung, Transkription, anschließend der Upload — je Speicherziel ein unabhängiger Übertragungsauftrag. Erst wenn alle Aufträge einer Aufzeichnung erfolgreich abgeschlossen sind, werden die lokalen Dateien gelöscht; das Speicherziel hält danach die einzige Kopie. - Zuordnung: Jede Aufzeichnungseinstellung verweist unter Externe Speicherziele auf beliebig viele im Tab Speicherziele definierte Ziele (OneDrive/SharePoint, SFTP, SMB — auch gemischt).
- Reihenfolge: Die Transkription ist zum Uploadzeitpunkt bereits abgeschlossen — die Transkriptionsdatei wird mit übertragen. Die Dateien eines Satzes werden einzeln hochgeladen.
Dateisatz und Namensschema
Der Basisname jedes Dateisatzes folgt dem Schema:
<Startzeit in ms>_<Rufnummer des Anrufers>-<gerufene Nummer>
- Startzeit: Unix-Zeitstempel in Millisekunden (identisch mit
startTimeder Ereignisse und der Spaltetimeder Protokolltabelle). - Rufnummer des Anrufers: bei eingehenden Anrufen die signalisierte externe Rufnummer, bei ausgehenden die interne Rufnummer des Anrufers.
- Ein führendes
+wird durch00ersetzt.
Beispiel: 1739948363496_004970222797821-31 — eingehender Anruf von 004970222797821
auf die Durchwahl 31, gestartet am 19.02.2025 um 07:59:23 Uhr (MEZ).
Zum Dateisatz gehören, abhängig von der Konfiguration:
| Datei | Format | Vorhanden |
|---|---|---|
<Basisname>.wav | Audio (WAV); bei Beide (in eine Datei, stereo) zweikanalig — linker Kanal = -in-Strom (Anruferseite), rechter Kanal = -out-Strom | bei den Audiokanal-Modi Beide (in eine Datei, stereo/mono) |
<Basisname>-in.wav, <Basisname>-out.wav | Audio (WAV), je Richtung eine Datei | bei Beide (in separate Dateien); bei einseitiger Aufzeichnung (Anrufer/Angerufener) nur eine der beiden Dateien |
<Basisname>_info.txt | Metadaten, UTF-8-Text (siehe unten) | immer |
<Basisname>.json | Roh-Transkription — unveränderte Antwort des Transkriptionsproviders (providerabhängiges JSON) | wenn in der Aufzeichnungseinstellung ein Transkriptionsprofil gewählt ist |
<Basisname>_hash.txt | SHA-256-Prüfsummen des Dateisatzes | bei aktivierten Prüfsummensignaturen |
<Basisname>_hash.SHA256withRSA.sig | Base64-kodierte RSA-Signatur über _hash.txt | bei aktivierten Prüfsummensignaturen |
Metadatendatei _info.txt
Eine Textdatei (UTF-8) mit einem Wert je Zeile im Format Schlüssel: Wert:
| Zeile | Bedeutung |
|---|---|
CallId: | STARFACE-Call-UUID des Anrufs. |
Datetime: | Startzeitpunkt im Format TT.MM.JJJJ hh:mm:ss <Zeitzone> (Anlagenzeitzone). |
Caller: | Name und signalisierte Rufnummer des Anrufers, durch Leerzeichen getrennt. |
Callee: | Gerufene Nummer. |
Channel: | Asterisk-Kanalname der Aufzeichnung. |
Recorded by: | Name der Modulkonfiguration, in Klammern die Aufzeichnungseinstellung, dahinter STARFACE-Version und Server-Lizenzschlüssel. |
Blockchain-Reference: | Nur bei aktivierten Prüfsummensignaturen: Basisname und Base64-Signatur der vorangegangenen signierten Aufzeichnung, durch zwei Leerzeichen getrennt (siehe Signaturverkettung). Bei der ersten signierten Aufzeichnung einer Instanz: null. |
CallId: 5e8f0f5a-1d24-4f6b-9c3a-7b2f9d4e8a11
Datetime: 19.02.2025 07:59:23 MEZ
Caller: Max Mustermann 004970222797821
Callee: 31
Channel: SIP/2001-00000042
Recorded by: Call Recording (Zentrale eingehend) on STARFACE 10.0.0.15 (ABCD-EFGH-IJKL-MNOP)
Blockchain-Reference: 1739947211042_004972212345678-31 MEUCIQDl4v…hQ==
Upload-Ziele
Verzeichnis-Platzhalter
In den Verzeichnisfeldern aller drei Zieltypen stehen Platzhalter zur Verfügung, die beim Upload durch den Startzeitpunkt der Aufzeichnung (Anlagenzeitzone) ersetzt werden:
| Platzhalter | Wert | Hinweis |
|---|---|---|
$Y | Jahr, z. B. 2025 | |
$M | Monat 1–12 | ohne führende Null |
$D | Tag 1–31 | ohne führende Null |
$h | Stunde 0–23 | ohne führende Null |
$m | Minute 0–59 | ohne führende Null |
$s | Sekunde 0–59 | ohne führende Null |
Aus Aufzeichnung/$Y_$M_$D wird für das obige Beispiel Aufzeichnung/2025_2_19.
Verarbeitende Systeme müssen die fehlenden führenden Nullen berücksichtigen
(2025_2_19, nicht 2025_02_19).
OneDrive / SharePoint
- Übertragung: Microsoft Graph mit der zentralen Microsoft-Anmeldung des Moduls (Anwendungs- oder Benutzeranmeldung).
- Ziel: Standardmäßig die Standard-Dokumentbibliothek der SharePoint-Stammsite der Organisation. Mit der Option Persönliches OneDrive nutzen (nur bei Benutzeranmeldung) alternativ das OneDrive des angemeldeten Benutzers.
- Verzeichnis: Feld Unterverzeichnis, relativ zur Wurzel der Dokumentbibliothek;
Platzhalter zulässig. Ist das Feld leer, verwendet das Modul den Ordner
Call Recording - <Instanz-UUID>. - Übertragungsdetails: Upload-Sitzungen in 5-MiB-Blöcken, bis zu 3 Versuche je Datei; leere Dateien (0 Byte) werden übersprungen.
Aufzeichnung/2025_2_19/1739948363496_004970222797821-31.wav
Aufzeichnung/2025_2_19/1739948363496_004970222797821-31_info.txt
Aufzeichnung/2025_2_19/1739948363496_004970222797821-31.json
Aufzeichnung/2025_2_19/1739948363496_004970222797821-31_hash.txt
Aufzeichnung/2025_2_19/1739948363496_004970222797821-31_hash.SHA256withRSA.sig
SFTP
- Konfiguration: SFTP Server, SFTP Verzeichnis (Platzhalter zulässig), SFTP Benutzername, SFTP Kennwort.
- Verzeichnisanlage: Es wird höchstens das letzte Verzeichniselement dynamisch
erstellt; alle übergeordneten Verzeichnisse müssen bereits existieren. Bei
Platzhalter-Strukturen wie
archiv/$Y/$M/$Dmuss die Ebenearchiv/$Y/$Malso anderweitig angelegt sein, bevor ein neuer Tagesordner entstehen kann.
/upload/starface/2025_2_19/1739948363496_004970222797821-31-in.wav
/upload/starface/2025_2_19/1739948363496_004970222797821-31-out.wav
/upload/starface/2025_2_19/1739948363496_004970222797821-31_info.txt
SMB
- Konfiguration: SMB Server, SMB Freigabe, SMB Unterverzeichnis (Platzhalter
zulässig), SMB Benutzername, SMB Kennwort, SMB Workgroup/Domain sowie
SMB Sicherheit mit den Modi
ntlm,ntlmi,ntlmv2,ntlmv2i,ntlmssp(Standard),ntlmsspi,krb5,krb5i,none.
\\fileserver01\aufzeichnungen\2025_2_19\1739948363496_004970222797821-31.wav
Jedes Speicherziel bietet in der Moduloberfläche die Funktion Speicherziel testen; dabei
wird eine Datei nach dem Muster callrecording_testfile_***.tmp hochgeladen, die
anschließend gelöscht werden kann.
Signaturen und Prüfung durch Dritte
Mit der Option „Prüfsummensignaturen aktivieren" in der Aufzeichnungseinstellung erzeugt Call Recording vor dem Upload einen manipulationssicheren Integritätsnachweis je Aufzeichnung. Der Ablauf nach Gesprächsende:
- Die Zeile
Blockchain-Reference(Basisname + Signatur der vorherigen signierten Aufzeichnung) wird an die Metadatendatei angehängt. - Für jede vorhandene Datei des Satzes —
-in.wav,-out.wav,.wav,_info.txt— wird ein SHA-256-Hash berechnet und in_hash.txtgeschrieben. - Der gesamte Inhalt von
_hash.txtwird mit dem privaten RSA-Schlüssel des Moduls signiert (SHA256withRSA); die Base64-kodierte Signatur wird als_hash.SHA256withRSA.sigabgelegt. - Dieselbe Base64-Signatur wird in die Spalte
signatureder Protokolltabelle eingetragen.
Die Transkriptionsdatei .json entsteht erst nach der Signierung und ist von der
Signatur nicht abgedeckt.
Format der Prüfsummendatei
_hash.txt enthält je Datei eine Zeile im Format
<SHA-256 hexadezimal><zwei Leerzeichen><Dateiname> — kompatibel zu sha256sum -c
bzw. shasum -a 256 -c:
9f2d4c1a58e6b37a90c1de4f6a2b8c5d7e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b 1739948363496_004970222797821-31.wav
4b1e8f0c2d3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c 1739948363496_004970222797821-31_info.txt
Schlüsselmaterial und Prüf-Zertifikat
- Das Modul erzeugt je Installation ein RSA-2048-Schlüsselpaar mit selbstsigniertem
X.509-Zertifikat (
CN=Fluxpunkt Gespraechsaufzeichnung <Modul-ID>, Signaturalgorithmus SHA256withRSA, 100 Jahre gültig). Alle Modulkonfigurationen einer Anlage verwenden dasselbe Zertifikat. - Der private Schlüssel verbleibt kennwortgeschützt in einem Schlüsselspeicher auf der Anlage und wird nicht exportiert.
- Das Prüf-Zertifikat (öffentlicher Schlüssel, PEM-Format) wird im Tab Signierung angezeigt und kann dort heruntergeladen oder gedruckt werden. Hinterlegen Sie es bei der prüfenden Stelle — nach einem Zurücksetzen des Zertifikats lassen sich ältere Aufzeichnungen nur noch mit dem zuvor gesicherten Zertifikat prüfen.
Prüfung mit Standardwerkzeugen
Die Prüfung benötigt keine Fluxpunkt-Software — nur den Dateisatz, das Prüf-Zertifikat
(cert.pem) und OpenSSL bzw. sha256sum/shasum:
BASE="1739948363496_004970222797821-31"
# 1) Prüfsummen aller Dateien verifizieren
sha256sum -c "${BASE}_hash.txt" # macOS: shasum -a 256 -c …
# 2) Base64-Signatur dekodieren
openssl enc -d -A -base64 -in "${BASE}_hash.SHA256withRSA.sig" -out sig.bin
# 3) Öffentlichen Schlüssel aus dem Prüf-Zertifikat extrahieren
openssl x509 -pubkey -noout -in cert.pem > publickey.pem
# 4) Signatur über die Prüfsummendatei verifizieren
openssl dgst -sha256 -verify publickey.pem -signature sig.bin "${BASE}_hash.txt"
# Erwartete Ausgabe: Verified OK
Signaturverkettung
Da die Metadatendatei den Basisnamen und die Signatur der vorherigen Aufzeichnung
enthält und selbst gehasht und signiert wird, bilden alle signierten Aufzeichnungen einer
Instanz eine kryptografisch verkettete Chronologie: Das nachträgliche Verändern,
Entfernen oder Umsortieren einzelner Aufzeichnungen bricht die Kette und ist damit
nachweisbar. Zur Kettenprüfung wird je Aufzeichnung verifiziert, dass die
Blockchain-Reference der Folgeaufzeichnung exakt dem Basisnamen und dem Inhalt der
_hash.SHA256withRSA.sig des Vorgängers entspricht.
Ein Wirtschaftsprüfer erhält den Dateisatz eines strittigen Telefonats sowie das beim
Mandanten hinterlegte Prüf-Zertifikat. Mit den vier Kommandozeilen oben belegt er, dass
Audio und Metadaten seit der Aufzeichnung unverändert sind — und über die
Blockchain-Reference der Folgeaufzeichnung, dass keine Aufzeichnung aus der Reihe
entfernt wurde.
Fehler-/Sonderfälle
| Situation | Verhalten |
|---|---|
| Upload schlägt fehl (Ziel nicht erreichbar, Anmeldung abgelaufen) | Wiederholung im 30-Sekunden-Takt ohne Begrenzung der Versuche. Die lokalen Dateien bleiben erhalten, bis alle Ziele erfolgreich beliefert wurden; bereits übertragene Dateien desselben Ziels werden beim nächsten Versuch erneut übertragen. |
| Speicherziel-Konfiguration wurde gelöscht, während Aufträge offen sind | Der Auftrag schlägt dauerhaft fehl; die Administratoren der Anlage erhalten einmalig eine Warn-E-Mail. Die Dateien verbleiben auf der Anlage und müssen über die Moduloberfläche heruntergeladen und gelöscht werden. |
| Kein Speicherziel zugeordnet | Die Dateien verbleiben dauerhaft im Arbeitsverzeichnis der Anlage und müssen manuell verwaltet werden. |
| Temporärer Speicher (RAM-Disk) aktiv | Keine Uploads und keine Signierung; die Dateien werden nach der Verarbeitung (inklusive optionaler Transkription) gelöscht. |
| Datei mit 0 Byte | Wird beim OneDrive/SharePoint-Upload übersprungen und gilt als übertragen. |
| Manuell im Tab Aufzeichnungen ausgelöste Transkriptionen | Die erzeugten Transkriptionsdateien werden nicht in Speicherziele hochgeladen und nicht automatisch gelöscht. |
| Signierung nicht möglich (z. B. Schlüsselspeicher beschädigt) | Der Dateisatz wird ohne _hash.txt/.sig hochgeladen; die Protokolltabelle erhält den Signaturwert unavailable. |
Versionierung & Kompatibilität
Das Namensschema des Basisnamens, die Dateiendungen des Dateisatzes und die Formate von
Metadaten-, Prüfsummen- und Signaturdatei sind stabile Verträge; Erweiterungen
erfolgen additiv (zusätzliche Dateien oder Metadatenzeilen). Verarbeitende Systeme
sollten unbekannte Dateien und zusätzliche Zeilen in _info.txt tolerieren. Die Prüfung
der Signaturen bleibt mit Standardwerkzeugen (OpenSSL, sha256sum) möglich; Änderungen
dokumentieren die Release Notes der jeweiligen
Modulversion.