TI-M Calling: Endpunkt, Medienpfad und Contact-Center-Architektur

Geltungsbereich und zwei Einsatzprofile

Ein aktiver Call je lokalem Account-/Gerätekontext, zwei TI-M-Geräte und ein privater, verschlüsselter Raum mit zwei Benutzern. Mehrere Geräte eines Benutzers können ein Invite erhalten; erst die Auswahl des beantwortenden Geräts bestimmt den Medienpartner. Mehrparteienkonferenz, MCU/SFU, SIP/PSTN und Messenger-Bridging gehören nicht zu diesem Entwurf.

Nativer Host und Headless-Modul laufen im kontrollierten Prozess am Bedienarbeitsplatz. Headless hält PeerConnection, Matrix- und Medienschlüssel; der Host stellt Freigabe, Mikrofon/Kamera, Wiedergabe und sichtbare Bedienelemente. PCM-/Bilddaten passieren die lokale Funktionsgrenze. Der Host ist damit ein vertrauenswürdiger Klartextteilnehmer; E2EE schützt nicht vor ihm oder einer kompromittierten Plattform. Die externe Medienroute muss zusätzlich das unten festgelegte TURN/TLS-Profil erfüllen.

Host und Headless-Modul laufen zusammen auf dem zentralen Server. TI-M-E2EE endet dort. Ein authentisiertes Arbeitsgerät überträgt Audio über den eigenen WSS/TLS-1.3-Kanal des Hosts; erst dessen lokale Funktionen greifen auf Headless zu. Der Host darf die freigegebenen Audiodaten im vorgesehenen Versorgungsprozess verarbeiten. Der WSS-Abschnitt ist ein eigener Transport, keine Fortsetzung derselben TI-M-E2EE und keine Headless-Netzwerk-API. Video, Aufzeichnung und Transkription sind in diesem ersten zentralen Profil nicht aktiviert.

Verantwortung vom Raum bis zum Medienende

• Headless · Signalisierung — ITL-Entscheidung: Das Modul verarbeitet verschlüsselte m.call.*-Raum-Events, prüft ihren Ursprung und führt die Call-Zustandsmaschine. Matrix-Client-/Fachdienst-Verkehr verwendet den gebundenen TLS-Vertrag. Der Host sendet fachliche Befehle und erhält Zustandsmeldungen; er ersetzt keine SDP-Prüfung und keinen Matrix-Event-Validator.
• Headless · Medien und Schlüssel — ITL-Entscheidung: PeerConnection, ICE, Codec-/RTP-Verarbeitung, DTLS-Zertifikat, Schlüsselaushandlung und SRTP/SRTCP verbleiben im Modul. Schlüssel, exportierbare PeerConnection-Objekte und beliebig injizierbares SDP sind keine Host-API. Die Olm/Megolm-Audits aus A_25598/99 belegen nicht automatisch die Sicherheit der Medienbibliothek.
• Host · Bedienung und Klartext-I/O — ITL-Entscheidung: Der Host authentisiert den Bediener, prüft Zweck und Berechtigungen, vermittelt Gerätefreigaben und zeigt Rufzustand, Mikrofon/Kamera und Auflegen. Er empfängt oder liefert autorisierte Klartext-Medien. Raw-Audio im Host ist keine Schlüsselübergabe, erweitert aber die vertrauenswürdige Verarbeitung und muss im Datenschutz- und Betriebskonzept enthalten sein.
• Anbieter · Integration und Relay — ITL-Entscheidung: Der Anbieter verantwortet die koordinierte Integration, freigegebene Artefakte, das konkrete TURN-Profil sowie das GTI-Change-Verfahren vor Integration und bei wesentlichen Änderungen. Ein einzelner Host-Login oder eine gemeinsame Matrix-ID beweist keine individuelle Bedieneridentität; der Host bindet jede Handlung an seinen authentisierten Bediener.
• Laufzeit · kontrollierter Vertrauensbereich — ITL-Entscheidung: FFI ist keine Speicherisolation gegenüber beliebigem nativen Host-Code. Der Entwurf verlangt einen kontrollierten, signierten Gesamtprozess ohne unautorisierte native Erweiterungen, passende Prozess-/Zugriffsrechte und keine produktiven Dump- oder Debug-Schnittstellen. A_28703 schließt eine kompromittierte Plattform und privilegierte Administratoren aus seinem Schutzumfang aus.

Drei Datenflüsse mit getrennten Endpunkten

• Signalisierung · beide Profile — ITL-Entscheidung: Host-Befehl → lokale Headless-Funktion → E2EE-geschütztes Matrix-Raum-Event über TLS zum TI-M-Fachdienst → Gegenstelle. Die Antwort wird erst nach Prüfung von Raum, Benutzer, Session-Ursprung, Call und ausgewählter Partei wirksam.
• TI-M-Medien · beide Profile — Technische Herleitung: Headless verschlüsselt Medien für das ausgewählte Gegengerät mit SRTP/SRTCP. Die Pakete reisen innerhalb einer TLS/TCP-Verbindung zur eigenen TURN-Allocation, werden innerhalb derselben kontrollierten VM zur Gegen-Allocation weitergereicht und reisen in deren TLS/TCP-Verbindung zum Gegengerät. Auch ICE-/DTLS-Pakete bleiben auf diesem Pfad; der TURN-Dienst erhält keine SRTP-Schlüssel.
• Bediener-Audio · nur Profil B — ITL-Entscheidung: Arbeitsplatz-Aufnahme → authentisierter WSS/TLS-Kanal → zentraler Host → lokale Medienfunktion → Headless. Empfang in Gegenrichtung: Headless entschlüsselt → lokale Medienfunktion → Host → WSS/TLS → Wiedergabe. Klartext entsteht im Servermodul, im autorisierten Host und am Arbeitsgerät. Das Host-WSS transportiert keine TI-M-DTLS-/SRTP-Schlüssel.

Netzwerkprofil: TLS an jeder Maschinengrenze

• TLS und DTLS bleiben verschiedene Protokolle — Quellenvorgabe: A_25299 verlangt TLS beim Überschreiten virtueller/physischer Maschinengrenzen zwischen TI-M-Komponenten; A_25573 bindet die kryptografischen Vorgaben ein. DTLS-SRTP allein wird hier nicht als Erfüllung dieser TLS-Regel bezeichnet. gemSpec_Krypt 2.50.0 verlangt TLS-1.2-Unterstützung und erlaubt TLS 1.3 unter Bedingungen; die allgemeine Produktunterstützung für TLS 1.2 bleibt erhalten.
• ITL-Profil · beide Geräte an derselben TURN-Instanz — Technische Herleitung: Für diesen Medienpfad werden TLS 1.3, turns:…?transport=tcp und iceTransportPolicy=relay gewählt. Beide Gegenstellen benötigen zulässige, authentisierte Allocations auf derselben dedizierten TURN-Instanz in derselben VM. Der Anbieter bindet Relay-Adresse, Allocation-Zulassung, Ablauf und Routing an dieses Deployment. Ein relay-Candidate kann dabei korrekt protocol=udp melden: geprüft wird TLS zwischen Client und TURN sowie der lokale Relay-Pfad, nicht eine erfundene TLS-Candidate-Art. DNS-Namen, Candidate-Typ oder turns:-Eintrag allein belegen weder gemeinsame Instanz noch TLS auf der Gegenseite.
• UDP darf die Relay-Maschine nicht verlassen — Technische Herleitung: TURN über TLS schützt nach RFC 8656 nur die Strecke Client–Relay; der normale Relay–Peer-Abschnitt verwendet UDP. Der ausgewählte Aufbau erlaubt diese Weiterleitung ausschließlich zwischen beiden lokalen Allocations auf derselben VM. Kein NAT-Hairpin über ein externes Gerät, zweiter Relay-Server, VM-Wechsel oder vorgeschalteter TLS-Terminator mit ungeschützter Backend-Strecke. Die Betriebsprüfung muss den tatsächlichen Paketpfad belegen.
• Unvereinbarer Pfad → Call nicht verfügbar — ITL-Entscheidung: Direkte Host-/Server-reflexive Candidates und andere Relay-Ziele werden in diesem Profil nicht verwendet. Remote-Candidates und ausgewähltes Candidate-Paar müssen zur freigegebenen Instanz passen; deren Allocation-Regeln erzwingen TLS/TCP für beide Profile-Teilnehmer und beschränken Peer-Ziele auf lokale Allocations. Fehlt diese beidseitige Zusicherung, scheitert die Zulassung. Kein Fallback auf UDP außerhalb der VM, unverschlüsseltes RTP oder einen beliebigen öffentlichen TURN.
• Enger Interoperabilitätsscope — ITL-Entscheidung: Die beiden Anbieter bzw. Endpunkte müssen das gemeinsame Relay-Profil koordinieren. Der standardisierte TURN-Abruf des Homeservers kann hierfür verwendet werden; er garantiert dieses Betriebsprofil jedoch nicht. TLS/TCP kann Head-of-Line-Verzögerungen verursachen. Verfügbarkeit, Latenz und Kapazität werden erst gemessen; allgemeine TI-M-Calling-Interoperabilität wird aus diesem Entwurf nicht abgeleitet.

Bindung von Benutzer, Gerät, Call und Medien

• Vertrauenswürdiger Session-Ursprung — Quellenvorgabe: Für Calling wird der erwartete Benutzer mit einer validierten Olm→Megolm-Session und ihrem Geräte-Vertrauensnachweis verbunden. Matrix 1.17 verbietet, die äußeren Megolm-Felder sender_key oder device_id als Ursprungsnachweis oder Session-Index zu verwenden. Raum, Event-Sender und session_id müssen zur vertrauenswürdigen Session passen; Replay-Prüfung und Schlüsselherkunft bleiben aktiv.
• ITL-Vertrauenspolicy vor Medienfreigabe — ITL-Entscheidung: Der Entwurf verlangt vor Medienfreigabe eine explizit bestätigte Cross-Signing-/Geräte-Vertrauenskette zur Gegenstelle; reines erstmaliges Vertrauen ohne Bestätigung genügt in diesem Profil nicht. Diese strengere Rufzulassung ist eine ITL-Policy. Ein neues oder ersetztes Gerät wird nicht stillschweigend freigegeben; verifizierte Weitergabe einer eigenen Session wird geprüft und ein Verlust ihrer Herkunft nicht als sicherer Ursprung behandelt.
• party_id ist kein Geräte-Zertifikat — ITL-Entscheidung: call_id und die Kombination aus Benutzer und party_id wählen den Teilnehmer; party_id muss nicht der Matrix-Geräte-ID entsprechen. Headless verbindet diese Werte intern mit dem geprüften Session-Ursprung und dem Fingerprint des angenommenen SDP. Der DTLS-Handshake muss zum erwarteten Fingerprint passen. TLS zum Homeserver oder ein lesbarer Anzeigename allein authentisieren den Medienpartner nicht.
• Kein kryptografischer Downgrade — ITL-Entscheidung: SRTP und SRTCP sind für den Medienpfad erforderlich. Unverschlüsseltes RTP/RTCP, NULL-Cipher, SDES-Schlüsselübergabe und abweichende Peer-Fingerprints werden abgelehnt. Je neuem Call wird ein frisches DTLS-Zertifikat mit zugehörigem privatem Schlüssel vorgesehen; keine Schlüssel-Ausgabe an den Host. SDP/ICE-Neuverhandlung bleibt von der in RFC 8827 ausgeschlossenen DTLS-Renegotiation getrennt.

Lokaler Modulvertrag und zentraler Audiokanal

• Opaque Handles und begrenzte Befehle — ITL-Entscheidung: Der lokale Vertrag bietet Call starten/annehmen/ablehnen/beenden, Mikrofon/Kamera-Zustand, Medien-I/O sowie abonnierte Zustandsmeldungen. Opaque Handles sind an Tenant, Account, Gerät, Call und Generation gebunden; ungültige oder wiederverwendete Handles werden abgelehnt. Der Host erhält keine Crypto-Objekte, Rohschlüssel, generischen Netzwerk-Proxy oder API zum Umgehen der Ereignisprüfung. Die C-ABI-Ausprägung ist ITL-Design.
• Profil B · versionierter WSS-Frame-Kanal — ITL-Entscheidung: ITL-Referenzprofil v1: mono PCM16LE mit 48 kHz in 20-ms-Blöcken (1.920 Audio-Bytes), Resampling im vertrauenswürdigen Audioadapter. Jeder Block trägt Kanal-ID, Lease-Generation, Richtung, Sequenz und Capture-Zeit; seine serverseitige Bindung umfasst Tenant, Bediener, Account, Gerät und Call. Nur die vereinbarte Länge und Folge sind zulässig. Zugangstoken stehen nicht in der WebSocket-URL; Frames enthalten keine TI-M-Schlüssel. Dies ist eine Vertragsdefinition, kein ausgelieferter Transport.
• Profil B · genau ein autorisierter Bediener — ITL-Entscheidung: Ein serverseitiger exklusiver Call-Lease verhindert die parallele Medienbedienung einer gemeinsamen Matrix-ID. Referenzwerte: authentisierter Heartbeat alle 5 Sekunden, Lease-Ablauf nach 15 Sekunden ohne gültige Erneuerung; Audio-Puffer höchstens 200 ms je Richtung, danach veraltete Frames verwerfen. WSS-Abbruch, Entzug der Berechtigung oder Lease-Verlust stoppen Medien und Call. Aufzeichnung, persistente Audio-Puffer und Transkription bleiben standardmäßig aus; eine Änderung benötigt einen eigenen Scope und Change.

Zustände, Kompatibilität und Fehler

• Idle → vorbereitet → klingelnd — ITL-Entscheidung: Vor Start oder Annahme werden Raum, Gegenstelle, Trust-Status, lokaler Kontext, Medienfreigabe und Relay-Profil geprüft. Erst nach vollständiger Sync-Verarbeitung einschließlich Entschlüsselungsversuchen darf ein noch gültiges Invite klingeln. Das Referenz-Invite lebt 90 Sekunden; age und lokal verstrichene Zeit begrenzen die Restlaufzeit. Ein fehlender Medienzugriff erzeugt den passenden Protokollfehler.
• Klingelnd → ausgewählt → verbunden — ITL-Entscheidung: Für Version 1 wird genau eine Antwortpartei ausgewählt; nicht ausgewählte Geräte beenden lokal, ohne den gewählten Call durch ein allgemeines Hangup zu zerstören. Der ITL-Entwurf gibt Medien erst nach gültiger Auswahl, Fingerprint- und Pfadprüfung frei. Eine zweite eingehende Einladung wird dem Bediener angeboten oder ignoriert; sie wird nicht allein wegen des lokalen Ein-Call-Limits automatisch mit user_busy abgewiesen.
• Matrix 0 und 1 sauber unterscheiden — ITL-Entscheidung: Gesendet wird version als String "1". Numerische 0 wird als Legacy-Version verarbeitet; andere Werte werden gemäß Matrix wie Version "1" behandelt. Für Version 0 gelten deren Ablauf und Hangup-Semantik, ohne künstlich select_answer oder negotiate vorauszusetzen. Protokollkompatibilität lockert weder Identitätsprüfung noch TLS-/SRTP-Policy; fehlende Sicherheit führt zu einem sicheren Abbruch, nicht zu einer erfundenen Versionsregel.
• Gleichzeitiger Ruf und Neuverhandlung — ITL-Entscheidung: Glare wird im selben Raum vor dem lokalen Busy-/Lease-Entscheid aufgelöst: Trifft das Gegen-Invite ein, bevor das eigene gesendet wurde, wird die eigene Vorbereitung zugunsten des eingehenden Calls beendet, bei unveränderten Zulassungsprüfungen. Sind beide Invites gesendet und noch unbeantwortet, gewinnt die lexikografisch kleinere call_id. Version-1-Neuverhandlung darf nur von der ausgewählten Gegenpartei kommen; abgelaufene SDP-Angebote und eigene Remote-Echos bleiben unwirksam. ICE-Neustart behält die gleiche Identitäts- und Relay-Policy. Kein Wechsel auf einen neuen Bediener oder Medienpfad durch Wiederverwendung eines alten Call-Handles.
• Beenden → Ressourcen freigeben → Idle — ITL-Entscheidung: Auflegen, Raum-Austritt der Gegenstelle, Logout, Entzug der Berechtigung, Host-Shutdown oder Lease-Verlust beendet Capture, Wiedergabe, Warteschlangen, PeerConnection und Call-Schlüssel. Eine bestmögliche Hangup-Nachricht blockiert die lokale Beendigung nicht. Call-Geheimnisse werden, soweit technisch möglich, gelöscht; langfristige Matrix-/Cross-Signing-Schlüssel werden nicht mit Call-Schlüsseln verwechselt. Kein automatisches Wiedergeben alter Audioblöcke in einen neuen Call.
• Fehler erhalten, Diagnose begrenzen — ITL-Entscheidung: Matrix-/TI-M-Codes und originale Hangup-Gründe bleiben am Host erhalten (A_28854): beispielsweise ice_failed vor erstem Medienpfad, ice_timeout nach zuvor erfolgreichem Pfad und user_media_failed. Lokale ITL-Ursachen wie „Call-Profil nicht verfügbar“ bleiben als lokale Ursachen erkennbar. Audit erfasst Ablehnung und Zustandswechsel, keine Rohmedien, TURN-Zugangsdaten, vollständigen SDP-/ICE-Inhalte oder rekonstruierbaren Crypto-Dumps.

Verbindliche Ziele für die spätere Runtime-Abnahme

• Modul- und Schlüsselgrenze — Abnahme: nicht ausgeführt: Am realen Artefakt prüfen: keine lokale/öffentliche Netzwerk-API zum Host, keine exportierten Matrix-/DTLS-/SRTP-Schlüssel oder PeerConnection-Objekte; ungültige Handles, Signaturen und Konfigurationen werden abgewiesen. Prozess-, Speicher-, Debug- und Dump-Kontrollen nach dem vereinbarten Bedrohungsmodell prüfen.
• Fremdes Gerät und verändertes SDP — Abnahme: nicht ausgeführt: Geänderte Event-Sender, room_id, Session-Herkunft, party_id und DTLS-Fingerprints sowie Replay, unbekannte Geräte und unzulässige Schlüsselweitergabe müssen an der richtigen Prüfstelle scheitern. Outer sender_key/device_id dürfen keine positive Trust-Entscheidung erzeugen. Authentisierte Gegenstellen müssen erfolgreich durch denselben Pfad kommen.
• Beide TURN-Strecken und tatsächliches Routing — Abnahme: nicht ausgeführt: Mit beiden realen Endpunkten und Paket-/Konfigurationsevidenz nachweisen: TLS auf beiden Allocation-Verbindungen, dieselbe VM, ausschließlich lokale Relay-Weiterleitung und keine externe UDP-Strecke. Zweiten Relay, NAT-Hairpin, nicht zugelassenen Candidate und TLS-Verlust gezielt auslösen; jeder Fall muss ohne direkten Fallback scheitern.
• Versionen, Glare und mehrere Geräte — Abnahme: nicht ausgeführt: Version 0/1, gleichzeitige Invites, mehrere Antwortgeräte, spätes Reject/Hangup, abgelaufene Invites, ICE-Neustart und Raum-Austritt prüfen. Besonders kontrollieren: nicht ausgewählte Geräte können den ausgewählten Call nicht beenden; falsche Peer-Fingerprints und unsichere Cipher werden nicht als Legacy-Kompatibilität akzeptiert.
• Profil B: Mandant, Bediener und Lease — Abnahme: nicht ausgeführt: Cross-Tenant-/Cross-Call-Frames, doppelte oder veraltete Sequenzen, veränderte Lease-Generationen, zwei Bediener, Rechteentzug und WSS-Abbruch prüfen. Kein Call darf nach Verlust seiner Zulassung weiter Audio verarbeiten. Puffergrenze, Resampling, Capture-Stopp und fehlende Aufzeichnung technisch prüfen; TLS-Terminierung und Backend-Hop müssen zur dokumentierten Grenze passen.
• Freigabe und gemessene Nutzbarkeit — Abnahme: nicht ausgeführt: Konkrete Bibliotheken/Versionen, Medien-Crypto-Sicherheitsnachweise, Codec-Kompatibilität, Audio/Video-Geräte und Last-/Latenzwerte dokumentieren. Olm/Megolm-Audit, R1001-Operationszähler oder Website-QA ersetzen diese Mediennachweise nicht. Anbieterhandbuch, Integrationsfreigabe und erforderlicher GTI-Change müssen das gewählte Profil einschließlich der TLS-Herleitung enthalten.

Bewusst beibehaltene Deployment-Alternativen

• Zentrale Fachprozesse, Calling lokal — ITL-Entscheidung: Wer am Contact Center Audio/Video und den TI-M-E2EE-Endpunkt am Bedienarbeitsplatz benötigt, nutzt dort Profil A. Chat-/Fachprozessführung kann zentral bleiben; Arbeitsplatz und Server werden als getrennte Geräte-/Account-Kontexte mit eigener Autorisierung dokumentiert. Die Endpunktwahl ist sichtbar und überträgt keine Server-Schlüssel an das Arbeitsgerät.
• Chat bleibt verfügbar, Calling wird nicht zugesagt — ITL-Entscheidung: Unterstützt eine Gegenstelle das gemeinsame TURN/TLS-Profil oder die Trust-Policy nicht, bleibt Calling für diese Paarung nicht verfügbar. Vorhandene zulässige Chat-Kommunikation wird dadurch nicht zu einem ungeprüften Medienpfad umfunktioniert. Direkte DTLS-SRTP-Routen oder Mehr-Relay-Modelle benötigen eine eigene begründete Architekturänderung und erneute Abnahme.