PTV · Freigegeben29.09.2026
gemProdT_TI-M_Hl_Client_Pro_PTV_1.0.0-0_V1.0.0 ↗
Headless Clientmodul Pro: direkter normativer Vergleichs-Scope; R1001-internes 63/37/9-Evidence bleibt getrennt.
Architekturbezug: MEMM Headless / Host-Integrationsgrenze
TI-Messenger Headless Client
TI-Messenger Headless Client für PVS, KIS und Contact Center
TI-M-Kommunikation gehört in den bestehenden Ablauf von PVS und KIS – nicht in eine zusätzliche isolierte Oberfläche.
MEMM bringt Kommunikationsfunktionen als lokale, versionierbare Produktkomponente in PVS, KIS, OEM- und Contact-Center-Architekturen. Die Fachanwendung integriert gegen klar abgegrenzte Host-, API- und Native-Verträge, während der technische R1001-Nachweis separat und überprüfbar bleibt.
Ein Modul in Ihrem Host.
Ihre Host-AnwendungOberfläche und Fachlogik
Lokaler API-Aufruf
MEMM HeadlessTI-M-Client-Kontext
TI-M-Kommunikation
TI-M-FachdienstExterner Dienst
Der Host ruft das Modul lokal auf. Das Modul verbindet sich mit dem externen TI-M-Fachdienst; seine Host-API ist keine Netzwerk-API.
Produktgrenze ansehenExterne Spezifikationsreferenz: TI-Messenger_26_2 (29.09.2026) · Die öffentliche Architekturerklärung verwendet diese feste Quellenversion. Implementierungstests, Interoperabilität und Produktzulassung benötigen eigene Nachweise. Historische Entwicklungsbasis: Draft_TI-Messenger_26_2 (12.08.2026).
Normative Integrationsgrenze: Der TI-M Pro Headless Client stellt seine API als lokales Modul bereit. Eine Netzwerk-API ist auch auf localhost ausgeschlossen; Endanwender arbeiten in der Oberfläche des integrierenden Hosts. Rust, Flat C ABI und Sprachbindings sind unsere Architekturwahl innerhalb dieser Vorgaben. gemSpec_TI-M_Pro 1.2.0 · A_28650 / A_28651 / A_28653 ↗
Normative Reference · gematik
Headless: normativer Produkttyp
Externe gematik-Dokumente zur Architektureinordnung. Die Nennung macht ITL weder zum zugelassenen Hersteller noch zum Betreiber.
Zugehörige technische QuellengemSpec_TI-M_Basis 1.3.0 ↗gemSpec_TI-M_Pro 1.2.0 ↗gemSpec_TI-M_ePA 1.3.1 ↗
Die folgenden Anforderungserklärungen beziehen sich auf die geprüften Quellenversionen. Interne R1001-Zähler beschreiben einen eigenständigen Engineering-Scope.
Anforderungen im Zusammenhang
Was die Spezifikationen für diese Architektur bedeuten.
Ausgewählte Anforderungen mit fester Quellenversion. Ein Thema aufklappen, um Verantwortung, Schnittstelle oder Datengrenze nachzulesen.
Lokale Modul-API und Host-Netzwerk
Der TI-M Pro Headless Client muss eine Integrations-API anbieten und darf weder eine eigene Endanwender-GUI noch eine lokale oder öffentliche Netzwerk-API bereitstellen. Das gilt auch für localhost. Das integrierende System darf eigene Netzwerkschnittstellen besitzen und das Modul ausschließlich über die vorgesehenen lokalen Funktionen ansteuern; der Anbieter sichert die integrierenden Netzwerkverbindungen durch TLS. Rust, Flat C ABI und Sprachbindings sind die ITL-Architekturwahl innerhalb dieser Vorgabe.
Alleiniger E2EE-Endpunkt und auditierte Kryptografie
Der TI-M Pro Headless Client muss der alleinige kryptografische Endpunkt der Ende-zu-Ende-verschlüsselten Kommunikation sein. Schlüsselmaterial, interne E2EE-Zustände und rekonstruierbare Sicherheitsinformationen bleiben innerhalb seines geschützten Kontexts; Diagnose-Dumps dürfen sie nicht offenlegen. Für die Nachrichtenverschlüsselung verlangen TI-M Clients eine auditierte, als ausreichend sicher bewertete Olm/Megolm-Implementierung. Die Basis nennt Vodozemac und libolm; andere Implementierungen benötigen einen gleichwertigen Sicherheitsnachweis durch geeignete unabhängige Prüfer. Cross-Signing und Secure Secret Storage and Sharing (SSSS) zur Geräteverifikation sind ebenfalls zu unterstützen. Rust oder ein lokales ABI allein erfüllen diese Anforderungen nicht.
Geschützte Laufzeit, Artefaktprüfung und Audit-Ereignisse
Zum Headless-Betrieb gehören wirksame Prozess- und Zugriffskontrollen, freigegebene Software und der Ausschluss unautorisierter Manipulations- oder Debug-Mechanismen. Der Anbieter beschränkt den Einsatz auf signierte, geprüfte und freigegebene Versionen. Der Integrator prüft beim Laden die Signatur offline gegen einen lokalen Vertrauensanker, soweit technisch möglich, und verweigert die Ausführung bei einem Verifikationsfehler. Sicherheitsrelevante Ablehnungen, Zustandsänderungen und Missbrauchssituationen müssen unverändert und zeitlich korrekt protokolliert werden. Anbieterhinweise müssen klarstellen, dass externe Konfigurationen oder Komponenten diese Audit-Logs nicht unterdrücken oder manipulieren dürfen. A_28703 umfasst keinen Schutz gegen eine kompromittierte Plattform oder privilegierte Administratoren.
Calling: gewählter Headless-Medienendpunkt
TI-M Basis führt VoIP als KANN-Modul. Matrix 1.17 beschreibt Call-Signalisierung über Raum-Events und WebRTC mit zwei Geräten je Call. Der R24.23-Referenzentwurf legt Matrix-E2EE, PeerConnection und DTLS-SRTP-Schlüssel in das Headless-Modul; der Host übernimmt Bedienung und autorisierte lokale Medien-I/O. Das ordnet die Architektur dem alleinigen E2EE-Endpunkt und der Isolation nach A_28710/A_28715 zu. Lokal endet TI-M-E2EE am Arbeitsplatzmodul, zentral am Servermodul mit einem eigenen TLS-Audiokanal zum Bediener. Der Entwurf ist keine geprüfte Runtime oder gematik-Freigabe.
Calling: TLS ist nicht mit DTLS gleichzusetzen
A_25299 verlangt TLS zwischen TI-M-Komponenten über virtuelle/physische Maschinengrenzen; A_25573 bindet gemSpec_Krypt ein. Eine ausdrückliche VoIP-Ausnahme wurde in den geprüften Quellen nicht gefunden. Deshalb beschränkt ITL den Entwurf auf zwei TURN-Allocations über TLS/TCP an derselben kontrollierten Instanz/VM und ausschließlich lokale Relay-Weiterleitung. turns-URL und relay-Candidate allein belegen den Pfad nicht; bei fehlender beidseitiger Zusicherung bleibt Calling nicht verfügbar. Das ist eine enge technische Herleitung, keine offizielle Auslegung. Allgemeine TLS-1.2-Unterstützung bleibt erhalten; TLS 1.3 ist die Wahl dieses Medienprofils.
Calling: Session-Ursprung und Medienpartner prüfen
party_id identifiziert eine Call-Partei, muss aber nicht der Matrix-Geräte-ID entsprechen. Matrix 1.17 verbietet, äußere Megolm-Felder sender_key/device_id als Ursprungsnachweis oder Session-Index zu verwenden. Der Entwurf bindet den geprüften Benutzer und Geräte-Vertrauensnachweis über die validierte Session an Raum, call_id, party_id und SDP-Fingerprint. Erst ein passender DTLS-Handshake und der zulässige Relay-Pfad geben Medien frei. Explizit bestätigtes Gerätevertrauen vor Calling ist eine strengere ITL-Policy; TLS zum Homeserver allein authentisiert den Medienpartner nicht.
TI-M-Scope des Matrix-Integrationsmodells
Der Anbieter TI-M Pro darf den Headless Client weder unmittelbar noch mittelbar für Bridging in andere Messenger-Systeme verwenden. Zusätzlich verbietet die Basis-Spezifikation serverseitiges Bridging in andere Nachrichtenprotokolle. Ein interner R1001-Eintrag mit der Bezeichnung Bridge State ist deshalb keine freigegebene TI-M-Bridge-Funktion. Host-Prozessintegration und zulässige Automatisierung müssen diese Grenze einhalten.
Hersteller, Integrator und Anbieter
Der Modulhersteller verantwortet den Produkttyp; der Host-Hersteller integriert das Modul in sein System. Der Anbieter TI-M Pro übernimmt die betriebliche Verantwortung, wenn er das Headless-Produkt anbietet. Auch On-Premise-Betrieb ist mit ihm abzustimmen. Er benennt jedes integrierende System samt Hersteller und Architektur im Betriebshandbuch und prüft dessen Aktualität mindestens halbjährlich ab Zulassung. Vor Integration und bei wesentlichen Änderungen muss er die Freigabe des Gesamtverantwortlichen für die TI (GTI) im betrieblichen Change-Verfahren einholen.
Berechtigte Organisation und Versorgungszweck
Headless-Integration und Betrieb sind auf Systeme von Gesundheitsorganisationen beschränkt, die TI-M bestellen und nutzen dürfen. Die verarbeiteten medizinischen Daten dienen ausschließlich der Gesundheitsversorgung oder deren Organisation. Mehrzwecksysteme benötigen technische und organisatorische Maßnahmen gegen unbefugten Zugriff anderer Organisationseinheiten. Ein Contact Center kann im zentralen Host Chats im Versorgungsprozess zuordnen; daraus folgt keine Erlaubnis für fachfremde Datennutzung.
Protokollfehler bleiben auswertbar
Der Headless Client muss die Fehlercodes der Matrix Client-Server API und der TI-M-Spezifikation an das integrierende System weiterreichen. Ein typisierter ITL-Vertrag muss diese Codes semantisch erhalten. Diagnose- und Stack-Texte mit Geheimnissen können redigiert werden; ein allgemeines internes Fehler-Enum darf den erforderlichen Protokollcode nicht ersetzen. Sicherheitsvorfälle können zusätzlich eine begrenzte Außendiagnose und Schutzmaßnahmen erfordern.
FHIR-Nutzdaten innerhalb von Matrix-Events
FHIR-Ressourcen werden mit dem Event-Typ de.gematik.fhir und fhir.json übertragen: eingebettet oder als JSON-/XML-Datei, mit Metadaten zu StructureDefinition, Ressourcentyp und FHIR-Version. Auch fhir.json verlangt einen Plaintext-Fallback unter de.gematik.text. Plaintext bezeichnet hier die Textrepräsentation im Event und hebt dessen E2EE-Schutz nicht auf. Proprietäre Events verwenden structuredData.json und einen Plaintext-Fallback unter de.gematik.text; auch unbekannte Events müssen vorhandene Text- und Datei-Fallbacks zugänglich machen. Ein Fachverfahren wird mit type und version im Block de.gematik.fachverfahren identifiziert. FHIR-VZD-Suche, TI-Flow-Operationen und dieser Nachrichtenvertrag sind getrennte Schnittstellen.
Gerätefähigkeiten und Verarbeitungsstatus
Client Capabilities werden unter de.gematik.client_capability.${device_id} im Nutzerprofil veröffentlicht. Bei einem vorhandenen Dehydrated Device müssen nach Logout des letzten Geräts dort Capabilities hinterlegt werden. Der Verarbeitungsstatus nutzt eigene Anfrage- und Antwortstrukturen: from_device, optional to_device und lifetime sowie einen Bezug auf die ursprüngliche event_id. Eine gültige, an das Gerät gerichtete Anfrage muss beantwortet werden. Die Antwort verknüpft success oder error über m.reference mit dem ursprünglichen Event; dieser Verarbeitungsstatus ist von Zustellung oder Lesebestätigung zu unterscheiden.
Separater HTTP-Report für Fachverfahren
Der Client erfasst Metadaten gesendeter und empfangener Fachverfahren und übermittelt die Statistik per POST /report an den Fachdienst. Der Report beschreibt einen Messbeginn (start) und Zähler (Anzahl) je Fachverfahren und Version in den optionalen Listen sent und received. Das ist ein eigener Vertrag neben Matrix-Events und FHIR-VZD-Suche. Fehlgeschlagene Reports werden höchstens 14 Tage zwischengespeichert und nach konfigurierbarem Intervall oder bei der nächsten aktiven Verbindung erneut übertragen. Quellenhinweis: Die vollständige URL im Headless-PTV verweist auf Commit f8654d7…, während die Versionsspalte dcd2d280 nennt; der Link hier folgt ausdrücklich der vollständigen PTV-URL.
Berechtigungskonfiguration und Auskunft
permissionConfig_V1.json beschreibt die Pro-Berechtigungskonfiguration mit defaultSetting und Ausnahmen für Server, Nutzer oder Gruppen. TiMessengerInformation.yaml bietet eine gesonderte HTTP-Auskunft mit Matrix-OpenID-Token: findByIk löst eine IK-Nummer zu einem Servernamen auf; isInsurance prüft dessen Kennzeichnung als Versichertendomäne. Der Domainteil einer MXID dient damit der Gruppenzuordnung, nicht der Prüfung einer individuellen medizinischen Berechtigung. Beide Schnittstellen sind im Headless-PTV auf Commit a67678018fb06bff1c14e7a1347631587dc57db5 festgelegt. Ein allgemeiner ITL-Begriff wie Authorization ist auf diese konkreten Protokollverträge abzubilden.
Redaktioneller Quellenabgleich: 17. Oktober 2026. Die Zuordnung erklärt Anforderungen; Implementierungsprüfung und Produktzulassung benötigen eigene Nachweise.
gemSpec_TI-M_Pro 1.2.0
Anforderungen und verantwortliche Komponenten.
Diese Zuordnung erklärt den architektonischen Sinn ausgewählter Headless-Anforderungen.
Für alle Spalten auf schmalen Bildschirmen seitlich scrollen. →
| AFO | Rolle | Architektonische Bedeutung |
|---|---|---|
| A_28650 / A_28651 / A_28653 | Headless-Modul | API für lokale Integration; keine Endanwender-GUI und keine lokale oder öffentliche Netzwerk-API. |
| A_28704 / A_28734 | Host und Anbieter | Vorgesehene lokale Modulaufrufe; eigene Netzwerkschnittstellen des Hosts durch TLS absichern. |
| A_28854 | Headless-Modul | Matrix-/TI-M-Fehlercodes an das integrierende System weiterreichen. |
| A_28683 | Anbieter TI-M Pro | Headless weder unmittelbar noch mittelbar für Bridging in andere Messenger nutzen. |
| A_28679 / A_28681 / A_28682 | Anbieter TI-M Pro | Betrieb verantworten; jedes integrierende System dokumentieren und mindestens halbjährlich prüfen. |
| A_28849 / A_28850 | Anbieter TI-M Pro / GTI | Freigabe vor Integration und bei wesentlichen Änderungen im betrieblichen Change-Verfahren. |
| A_28725 / A_28733 | Anbieter TI-M Pro | Berechtigte Gesundheitsorganisation und ausschließlicher Versorgungszweck der medizinischen Daten. |
| A_28693 / A_28684 | Headless-Modul | Produkttyp/-version eindeutig ausweisen; Selbstauskunft einschließlich integrierendem System senden. |
Anbieterhandbuch und konkrete Integration bestimmen das Deployment. R1001-Zähler behalten ihre eigenständige interne Bedeutung.
Integrationsnutzen
Komplexität kontrollieren, statt sie in die Fachanwendung zu verschieben.
Der Nutzen liegt in expliziten, versionierbaren Produktgrenzen, gegen die Fachanwendungen ihre UI/UX- und Prozesslogik entwickeln können. Regulatorische und externe Betriebsverantwortung bleibt davon getrennt.
01Fachlogik entkoppeln
Ausgewählte Protokoll-, E2EE- und Integrationsdetails bleiben hinter einer benannten Headless-Grenze statt in jeder Fachanwendung neu zu entstehen.
02Integration planbar machen
Lifecycle, Fehler, Ownership und Releasewechsel werden als versionierbare Verträge behandelt.
03Wiederholung reduzieren
Der Rust-basierte Kern bündelt technische Verantwortungen, die Host-Systeme im vereinbarten Scope nicht erneut als eigene Runtime bauen müssen.
Zielbild: ein schnellerer Weg vom Architektur-Scope zur belastbaren Integration – ohne pauschale Time-to-Market-Zusage.
Einordnung Diese Aussagen beschreiben Architekturziele und mögliche Integrationsvorteile. Sie sind keine Garantie für Entwicklungsdauer, Compliance, Zulassung, vollständige regulatorische Entlastung oder ein bestimmtes Projektergebnis.
Produktoperations-Katalog
Sechs Host-/Native-Vertragsgruppen und eine eigene Calling-Grenze.
Die Produktarchitektur bündelt Lifecycle, Discovery, Messaging, Rooms, Media und Autorisierung hinter begrenzten Host-Verträgen. Calling besitzt eine gesonderte Signalisierungs-/Medienverantwortung; interne Operationszahlen stehen im technischen Anhang.
Produkt & Session
Produktinformation, Service-Account-Kontext, Login/Logout und ein ausdrücklich nicht-produktiver Cleanup-Pfad.
Directory & Discovery
FHIR-VZD-bezogene Sichtbarkeit, Authentisierung und MXID-Zuordnung sowie Practitioner- und Homeserver-Suche innerhalb des gebundenen Headless-Scope.
Messaging
Direkte und raumbezogene Nachrichten, Historie, Bearbeitung sowie kontrollierte Redaktions- und Ersetzungsvarianten.
Rooms
Raumlisten, Erstellung, Einstellungen, Mitgliedschaftsübergänge, Forget und State-Event-Abfragen.
Media
Upload und authentisierter Abruf als benannte Produktoperationen innerhalb derselben Host- und Ownership-Grenze.
Authorization
Expliziter Autorisierungsmodus sowie Allow-/Block-Listen als typisierte Headless-Produktgrenzen.
TI-M CallingHeadless / WebRTCReferenzarchitektur R24.23
Headless verantwortet Signalisierung, PeerConnection und Medienschlüssel.
Der ausgewählte ITL-Entwurf hält Matrix-E2EE, WebRTC und DTLS-SRTP im Headless-Modul. Der native Host bedient den Call und vermittelt autorisierte Medien-Ein- und -Ausgabe über lokale Funktionen. Für den Arbeitsplatz wird ein lokaler Audio-/Video-Endpunkt beschrieben; im zentralen Contact Center endet TI-M-E2EE am Servermodul, mit einem eigenen WSS/TLS-Audiokanal zum Bediener.
Host-UI / Medien-I/O↔lokale opaque Modul-API↔Headless: Matrix + WebRTC + Schlüssel
VoIP ist in TI-M Basis 1.3.0 ein KANN-Modul. A_28710 und A_28715 bestimmen die kryptografische Grenze; A_25299/A_25573 verlangen den getrennt belegten TLS-Pfad. Für diesen Entwurf werden beide Geräte über dieselbe kontrollierte TURN-Instanz per TLS geführt; bei fehlendem Nachweis gibt es keinen direkten UDP-Fallback. Profile, Zustände und Quellen ansehen →
Interne R1001-Provenienz der Call-Surface
Der historische Katalog benennt neun Call-Domänen und 16 begrenzte Messenger-Operationen: fünf Signalisierungs- sowie elf Media-/Session-Operationen. Diese Zähler belegen keine Umsetzung oder Abnahme der hier ausgewählten R24.23-Medienarchitektur.
Einordnung 37 Operationen sind der definierte aktuelle Headless-Produktoperationskatalog. Die zusätzliche Call-Surface nutzt die bestehende Messenger-Operation-Grenze und wird deshalb separat gezählt. Weder 37/37 noch die Calling-Surface sind ein Zähler für vollständige TI-M-Spezifikation, gematik-Zulassung, Produktionsfreigabe oder externe Provider-Interoperabilität.
ITL · ADR-001 · R24.23
Calling: ein Headless-Endpunkt, zwei klar benannte Einsatzprofile
ITL legt für diesen Referenzentwurf Matrix-Signalisierung, PeerConnection und DTLS-SRTP-Schlüssel in das Headless-Modul. Der Host übernimmt Bedienung sowie erlaubte Medien-Ein- und -Ausgabe über lokale Funktionsaufrufe. TI-M Basis 1.3.0 führt VoIP als KANN-Modul; die folgende konkrete Aufteilung ist eine ITL-Entscheidung. Sie beschreibt die ausgewählte Architektur und Abnahmekriterien, keine bereits ausgeführte Medienlaufzeit oder gematik-Freigabe.
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. [3] [5] [2]
A · Lokaler Arbeitsplatz · Audio und Video
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. [2] [9]
B · Zentrales Contact Center · zunächst Audio
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. [2] [9]
Calling · ausgewählter ITL-Referenzentwurf
Wo endet das verschlüsselte Gespräch?
Wählen Sie den Ort des Headless-Moduls. Er bestimmt, wo TI-M-Medien entschlüsselt werden und wie Mitarbeitende am Gespräch teilnehmen.
A · Audio und Video am Arbeitsplatz
Der TI-M-Endpunkt ist das Headless-Modul am Arbeitsplatz.
ArbeitsplatzHost + Headless
Oberfläche, Mikrofon und Lautsprecher
TI-M-E2EE-Endpunkt im lokalen ModulEnde-zu-Ende verschlüsseltAudio / Video
GesprächspartnerTI-M-Client
Gerät des anderen Teilnehmers
Der andere TI-M-E2EE-EndpunktDer vertrauenswürdige lokale Host verarbeitet die erlaubte Klartext-Ein- und -Ausgabe von Audio und Video. Medienschlüssel bleiben in Headless und der Gegenstelle.
B · Zentrales Audio mit eigenem Mitarbeiterkanal
Der TI-M-Endpunkt ist das Headless-Modul im Server. Mitarbeitende verbinden sich separat mit dessen Host.
MitarbeitergerätOberfläche + Audio
Authentifizierter Zugang zum Host
Eigener OperatorabschnittEigener TLS-KanalWSS / TLS 1.3
Contact-Center-ServerHost + Headless
Lokale Modulaufrufe im Prozess
TI-M E2EE endet in diesem ModulEnde-zu-Ende verschlüsseltAudio
GesprächspartnerTI-M-Client
Gerät des anderen Teilnehmers
Der andere TI-M-E2EE-EndpunktDer vertrauenswürdige Server-Host verarbeitet Klartext-Audio. Der Operatorabschnitt erhält eigenen TLS-Schutz; er liegt außerhalb der TI-M-E2EE-Sitzung zwischen Headless und Gegenstelle. Medienschlüssel werden nicht an den Operator exportiert.
Beide Modelle benötigen den vereinbarten Weg über eine kontrollierte TURN-Instanz in einer VM: beide Client-Allocations über TLS, Relay-Weiterleitung nur innerhalb dieser VM. Lässt sich dies nicht nachweisen, bleibt Calling nicht verfügbar.
Technische Diagramme: Medienschutz, TLS-Wege und Modulgrenzen
Türkis markiert den Ende-zu-Ende-Medienschutz; Blau markiert die einzelnen TLS-Transportabschnitte. Die Diagramme in voller Größe lassen sich horizontal verschieben. Der ausgewählte Referenzentwurf und seine Laufzeit-Abnahmekriterien stehen in ADR-001; die Laufzeit-Abnahme ist nicht ausgeführt.
Die TLS-Auslegung ist bewusst eng: In den geprüften Quellen wurde keine ausdrückliche VoIP-Ausnahme von A_25299/A_25573 gefunden. Das ausgewählte TURN-Profil ist eine technische Herleitung, keine offizielle Auslegung der gematik. Seine Realisierbarkeit, Gegenstellenkompatibilität und Freigabe müssen am konkreten Deployment nachgewiesen werden. Ohne belegten Pfad wird der Call nicht zugelassen. [3] [4] [10]
Verantwortung vom Raum bis zum Medienende
Auf schmalen Bildschirmen lässt sich diese Tabelle horizontal verschieben.
| Verantwortung / Regel | Festgelegter Vertrag |
|---|---|
| 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. [5] [2] [3] |
| 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. [2] [3] [9] [11] |
| 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. [2] [9] |
| 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. [2] |
| 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. [2] |
Drei Datenflüsse mit getrennten Endpunkten
Auf schmalen Bildschirmen lässt sich diese Tabelle horizontal verschieben.
| Verantwortung / Regel | Festgelegter Vertrag |
|---|---|
| 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. [5] [6] [3] |
| 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. [10] [11] [3] |
| 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. [2] |
Netzwerkprofil: TLS an jeder Maschinengrenze
Auf schmalen Bildschirmen lässt sich diese Tabelle horizontal verschieben.
| Verantwortung / Regel | Festgelegter Vertrag |
|---|---|
| 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. [3] [4] [1] [11] |
| 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. [10] [8] [4] |
| 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. [10] [3] |
| 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. [10] [3] [9] |
| 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. [5] [10] |
Bindung von Benutzer, Gerät, Call und Medien
Auf schmalen Bildschirmen lässt sich diese Tabelle horizontal verschieben.
| Verantwortung / Regel | Festgelegter Vertrag |
|---|---|
| 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. [6] [7] |
| 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. [7] [6] [3] |
| 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. [5] [6] [9] |
| 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. [9] [11] [5] |
Lokaler Modulvertrag und zentraler Audiokanal
Auf schmalen Bildschirmen lässt sich diese Tabelle horizontal verschieben.
| Verantwortung / Regel | Festgelegter Vertrag |
|---|---|
| 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. [2] |
| 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. [2] |
| 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. [2] |
Zustände, Kompatibilität und Fehler
Auf schmalen Bildschirmen lässt sich diese Tabelle horizontal verschieben.
| Verantwortung / Regel | Festgelegter Vertrag |
|---|---|
| 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. [5] |
| 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. [5] |
| 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. [5] |
| 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. [5] [2] |
| 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. [5] [2] [9] |
| 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. [5] [2] |
Verbindliche Ziele für die spätere Runtime-Abnahme
Alle folgenden Laufzeit-Abnahmen stehen auf „nicht ausgeführt“. Website- und Datenprüfungen belegen keine Medien-Interoperabilität, kryptografische Implementierung oder Betriebsfreigabe.
Auf schmalen Bildschirmen lässt sich diese Tabelle horizontal verschieben.
| Verantwortung / Regel | Festgelegter Vertrag |
|---|---|
| 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. [2] |
| 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. [6] [7] [9] |
| 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. [10] [3] |
| 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. [5] [9] |
| 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. [2] |
| 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. [2] [3] [8] |
Bewusst beibehaltene Deployment-Alternativen
Auf schmalen Bildschirmen lässt sich diese Tabelle horizontal verschieben.
| Verantwortung / Regel | Festgelegter Vertrag |
|---|---|
| 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. [2] [5] |
| 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. [3] [2] [10] |
Architekturvertrag R24.23 als JSON herunterladen ↓
Versionsgebundene Quellen und technische Referenzen
- gemAnbT_TI-M_Pro ATV 1.2.0-0 · V1.0.0 · Table 1: Krypt 2.50.0 / Basis 1.3.0 / Pro 1.2.0 ↗
- gemSpec_TI-M_Pro 1.2.0 · § 3.3 · A_28651, A_28703/04/10/15/34, A_28849/50 ↗
- gemSpec_TI-M_Basis 1.3.0 · A_25395-03, A_25299, A_25573, A_25598/99 ↗
- gemSpec_Krypt 2.50.0 · GS-A_4385, A_18467, A_18986 ↗
- Matrix Client-Server API 1.17 · Voice over IP ↗
- Matrix 1.17 · m.megolm.v1.aes-sha2 ↗
- Matrix 1.17 · Verification of the sending user for incoming events ↗
- W3C WebRTC 1.0 · Recommendation 2025-03-13 ↗
- RFC 8827 · WebRTC Security Architecture · §§ 4.3, 6.2, 6.4, 6.5 ↗
- RFC 8656 · TURN · §§ 3.1, 12.6, 21.1.6 ↗
- RFC 5764 · DTLS Extension to Establish Keys for SRTP ↗
Messenger Functional Breadth
Kommunikationsfunktionen und klar getrennte Verantwortungsbereiche.
Core Messaging, Account Safety, Rich Content, Calling und Integrationen werden hier als Architektur dargestellt. Interne R1001-Zähler dienen nur als optionale Provenienz und nicht als Produktnarrativ.
Interne R1001-Zähler und Reifeangaben (optionale technische Details)
Alle 63 Domänen sind im gebundenen R1001-Stand als executable_source mit Reifegrad 100 geführt.
Arithmetische Breadth über den festen 63-Domain-Denominator: 100,00%.
Die 26 Core-Foundation-Domänen liegen innerhalb ihres deklarierten Scope bei 100,00%.
R1001 bindet Verhalten an ausführbare Evidenz; reine Marker- oder Zahleneinträge reichen für den 100%-Status nicht aus.
Core Foundation
Lifecycle, Update Stream, Projektionen, Conversation/Timeline, Delivery, Security, Rooms, Realtime, Media, Search und E2EE-/Cache-Grundlagen.
Account & Room Safety
Profile/Safety, Pins, Bookmarks, Permalinks, Directory/Aliases, Preferences und Device Sessions.
Rich & Presentation
Polls, Location, Voice, Stickers sowie Accessibility, Locale, Theme, Composer-, Draft-, Preview- und Delivery-Darstellung.
Calls & Integrations
9 Call-Domänen: Availability, Invite, Ringing, Session, Participants, Media State, Permissions, Transport und Encryption. 4 interne Integrationsdomänen: Widgets, Bridge State, Bot Integrations und Integration Permissions.
TI-M-Scope: Bridge State ist eine interne Katalogbezeichnung. Der Anbieter darf den Headless Client weder direkt noch indirekt zum Bridging in andere Messenger-Systeme nutzen. A_28683 ↗
Einordnung 100% bezieht sich ausschließlich auf den festen, verantwortungsbegrenzten 63-Domain-Messenger-Denominator und dessen Core-Foundation-Teilmenge. Daraus werden weder vollständige TI-M-Spezifikationsabdeckung noch Produkt-Funktionsvollständigkeit, Release-Reife, gematik-Zulassung, Provider-Interoperabilität oder externe Konformität abgeleitet.
Technischer Produktpass
Versionsgebundener Headless-Stand – kompakt und nachvollziehbar.
Für bestehende Kunden und technische Evaluierungen trennt dieser Status den aktuell öffentlich belegbaren Headless-Scope von Release-, Provider- und Produktionsfreigaben.
Gebundene source-local Reviewbasis. Website-Beschreibung geprüft: 23.08.2026.
Fester verantwortungsbegrenzter Messenger-Denominator; Breadth und Core Foundation jeweils 100%.
Source-bound Produktoperationsparität bleibt über Rust, Flat C ABI, Java 21, Kotlin und Swift erhalten.
Exakte aktuelle Rust-Workspace-/Native-Sanitizer-, autorisierte Release- und externe Provider-/Konformitätsnachweise bleiben separate Gates.
Versionierter Produktpass
Technical Product Brief · R24.23
Aktualisierte Integrationsarchitektur mit lokalen Modulaufrufen, TI-M-Bridging-Grenze, Anbieterpflichten und direkten gematik-Quellen. Der interne R1001-Stand bleibt als eigene Provenienz gekennzeichnet.
Headless Website ChangelogStand 17.10.2026
Calling-Referenzarchitektur. Signalisierung, PeerConnection und Medienschlüssel sind im Entwurf dem Headless-Modul zugeordnet. Lokaler Arbeitsplatz, zentraler Audiokanal, enger TURN/TLS-Pfad und spätere Runtime-Abnahmen sind ausdrücklich beschrieben.
Product Passport UX Polish. PDF-Produktpass und Scope-Composer sind prominenter, der technische Stand wird als source-bound R1001 statt als Git-Freshness-Signal geführt; Capability- und Evidence-Claims bleiben unverändert.
R1001 Calling Surface. Historischer Website-Stand: neun Call-Domänen und eine hostseitig beschriebene Mediengrenze. R24.23 ersetzt diese Aufteilung für den ausgewählten TI-M-Entwurf durch die oben dokumentierte Headless-Medienverantwortung.
R1001 Messenger Breadth. Der feste 63-Domain-Messenger-Denominator wird mit 63/63, 100% Breadth und 100% Core Foundation öffentlich eingeordnet; die Aussage bleibt source-local und responsibility-bounded.
Product Passport & Conversion. Technischer Status, versioniertes PDF-Briefing, kontextuelle CTA und lokaler Scope-Composer auf Basis des damaligen R984-Headless-Standes.
R984 Headless Operations. Öffentliche Einordnung des 37-Operationen-Katalogs, der sechs Funktionscluster und der aktuellen nativen Integrationsgrenze.
Einordnung Der Status dokumentiert die öffentliche Integrations- und Reviewgrenze. Er ist kein Ersatz für projektspezifische Abnahme, Zulassung, Providerfreigabe, SLA oder Produktionsentscheidung.
TI 2.0 Einordnung
Headless Integration als Anwendungsgrenze – nicht als Ersatz des TI-Zugangs.
Der Wandel zu hardwareunabhängigem TI-Zugang und digitalen Identitäten erhöht die Bedeutung klarer Software- und Verantwortungsgrenzen. MEMM positioniert den Headless Client innerhalb der Fachanwendung; TI-Gateway und externe TI-Zugangsdienste bleiben außerhalb dieses Scopes.
Identity-Evidence als eigene Grenze
Der aktuelle versionsgebundene Entwicklungsstand umfasst eine separate Adaptergrenze für EUDI Wallet, Health ID und eID-LE. Identitätsverifikation erzeugt dabei nicht automatisch eine fachliche Autorisierung.
Keine implizite TI-2.0-Zusage
Headless, Identity/Policy und E2EE werden als Integrationsbausteine eingeordnet. Eine ZETA-, OIDC-, TI-Gateway-, PoPP-, VSDM-2.0-, ePA- oder E-Rezept-Implementierung wird daraus nicht abgeleitet.
Native Integrationsgrenzen
Ein klarer Host-Vertrag statt impliziter Laufzeitannahmen.
Die technische Konkretisierung bleibt bewusst auf der öffentlich relevanten Grenze: Host, Binding, Flat C ABI / FFI und Rust-basierter Kern. Packaging, Plattformfreigaben und Performance werden daraus nicht abgeleitet.
HostPVS / KIS / Contact Centerbestehende Fachanwendung
BindingsJava 21 · Kotlin · Swiftim aktuellen Prüfkontext gegen die ABI gebaut
ContractFlat C ABI / FFIlokale, explizite Host-Grenze
CoreRust-basierter Kernfachliche Ownership bleibt unterhalb der Binding-Grenze
Java 21 Panama, Kotlin und Swift wurden im verfügbaren Prüfkontext gegen die aktuelle ABI gebaut. Der exakte aktuelle Rust-Workspace-Run sowie autorisierte Release- und Provider-Nachweise bleiben separate Voraussetzungen.
Runtime-Invarianten
Headless-Betrieb ohne neue Pooling- oder Polling-Inseln.
Der aktuelle source-local Reviewstand hält die Integrationsarchitektur auf wenige benannte Ownership- und Update-Grenzen begrenzt.
01Keine Pooling-Insel
Die Native-Grenze führt keinen zweiten Datenbank-, Connection-, Worker- oder Async-Runtime-Owner ein.
02Keine Polling-Insel
Update- und Laufzeitpfade bleiben producer-notified oder ausdrücklich begrenzt statt einen unabhängigen Poller aufzubauen.
03Subscription-first
Fortlaufende Updates werden über die bestehende Subscription-/Host-Executor-Grenze eingeordnet statt über einen zweiten Hintergrundowner.
04Begrenzte Facades
Native Bindings sind in Capability-Objekte aufgeteilt; der Root-Client bleibt Owner/Factory statt zu einer monolithischen Weiterleitungsfassade zu wachsen.
Einordnung Diese Invarianten sind source-local/static geprüft. Sie ersetzen keinen exakten aktuellen Rust-Workspace-, Last-, Betriebssystem- oder Provider-Test.
Host Boundary
Was der Host sieht – und was keine Host-Oberfläche sein soll.
Für eine eingebettete Headless-Komponente ist die wichtigste Sicherheitsfrage nicht ein abstrakter Score, sondern die explizite Trennung von Produktdaten, Lifecycle, Diagnose und kryptographischem Zustand.
Öffentliche Integrationsgrenze
Host / Primärsystem
- versionierte Eingaben und Produktdaten
- typisierte Statuswerte mit erhaltenen Matrix-/TI-M-Fehlercodes
- Lifecycle- und Update-Verträge
- redigierte Diagnoseinformationen
MEMM BoundaryHeadless Runtimeproduktseitig kontrollierter E2EE-Kontext
Keine öffentliche Host-Oberfläche
Kryptographischer Zustand
- rohes Schlüssel- oder Sessionmaterial
- rekonstruierbarer Crypto-Runtime-Zustand
- interne Security-Authority-Mechanik
- Raw-Memory- oder Dump-Funktionen
Diese Darstellung beschreibt die aktuelle Architektur- und Reviewgrenze. Sie ist kein Nachweis vollständiger Isolation in jeder Zielumgebung und keine Produktionsfreigabe.
Kryptographische Zustandsgrenze
TI-M-Schutzanforderungen und ihre Zuordnung zur ITL-Architektur.
Die normativen Vorgaben benennen den Schutzkontext; die ITL-Architektur ordnet Laufzeit, Host-Daten und Diagnose diesem Kontext zu. Nachweise einer konkreten Implementierung bleiben releasebezogen.
01Produktseitiger E2EE-Endpunkt
A_28710 verlangt den alleinigen kryptografischen Endpunkt der E2EE-Kommunikation im Headless Client. Für die Nachrichtenverschlüsselung schreibt TI-M Basis eine auditierte Olm/Megolm-Implementierung vor (A_25598, A_25599); Rust und FFI sind dafür allein kein Nachweis.
02Begrenzte Secret Ownership
Für ausgewählte sensible Speicherinhalte sieht der aktuelle Entwicklungsstand begrenzte Ownership- und Zeroisierungsmechanismen vor. Daraus wird keine allgemeine Memory-Safety-Garantie abgeleitet.
03Fehlercodes & sichere Diagnose
Der Integrationsvertrag muss Matrix- und TI-M-Fehlercodes an den Host weiterreichen (A_28854). Typisierung erhält ihre Bedeutung; sensible Diagnose- und Stack-Texte werden redigiert. Ein allgemeines internes Fehler-Enum ersetzt den Protokollcode nicht.
04Transport & Host-Betrieb
Weiterleitung über Netzwerkschnittstellen des Hosts benötigt TLS. Prozess- und Zugriffskontrollen, freigegebene Artefakte und der Ausschluss unautorisierter Debug-Mechanismen gehören zum Headless-Betrieb (A_28703, A_28707). Die lokale API hebt diese Pflichten nicht auf.
Einordnung Quell-/Static-Review und lokal ausführbare Prüfungen sind nicht gleichbedeutend mit externer Produktionsvalidierung. Controlled OS dump/memory exercises, Live-Provider-Interoperabilität und autorisierte Release-Freigaben bleiben separate Nachweise.
Integrationsvertrag
FFI ist nicht das Produktversprechen. Der kontrollierte Vertrag ist es.
Enterprise-Integration wird durch Typ-, Lifecycle-, Fehler- und Ownership-Grenzen belastbar – nicht durch die bloße Existenz eines Bindings.
01API & ABI
Aufrufbare Oberfläche, Version und zulässige Übergabepunkte.
02Lifecycle & Ownership
Start, Shutdown, Zustandsübergaben und Host-Verantwortung.
03Fehler & Update
Fehlerklassen, Wiederanlauf und Releasewechsel als Teil des Vertrags.
No-UI / lokale Host-Grenze
Lokale Modulaufrufe und ein separat verantworteter Host.
A_28651 schließt eine Netzwerk-API des TI-M Pro Headless Clients auch lokal aus. A_28704 verlangt die vorgesehenen lokalen Funktionsaufrufe. Der Host kann eine eigene Benutzeroberfläche und TLS-gesicherte Netzwerkschnittstellen bereitstellen; der Headless Client muss nach A_28710 der alleinige kryptografische Endpunkt der Ende-zu-Ende-verschlüsselten Kommunikation sein.
Host-Perspektive
- lokale Modulaufrufe statt localhost REST/TCP/WebSocket
- Matrix-/TI-M-Fehlercodes und kontrollierte Zustandsübergabe
- benannte Lifecycle-, Update- und TLS-Verantwortung
Anbieter TI-M Pro
Der Anbieter verantwortet den Headless-Betrieb einschließlich abgestimmter On-Premise-Modelle. Er dokumentiert jede Integration und holt die GTI-Freigabe vor Integration sowie bei wesentlichen Änderungen ein (A_28679, A_28849, A_28850).
Lokale Headless-Architektur vertiefen →Technische Vertiefung
Headless Client, native Verträge und kryptographische Grenze.
Die Wissensseiten erklären Architekturprinzipien, ohne interne Implementierungsdetails, Runbooks oder Roh-Evidence offenzulegen.
Headless Client
TI-Messenger Headless Client
Technische Einordnung einer Headless-Client-Integration für PVS, KIS und Contact Center: lokale Produktgrenze, 63-Domain-Messenger-Denominator, Produktoperationskatalog, Native Bindings, Calls und Verantwortungen.
Wissen öffnen →
Technologiegrenze
Rust & native Integration
Technische Einordnung des Rust-basierten MEMM-Kerns und einer lokalen FFI-Grenze für native Fachanwendungen – ohne pauschale Plattform- oder Performancezusage.
Wissen öffnen →
Security Boundary
Kryptographische Isolation
Architekturprinzip für eine eingebettete Headless-Komponente: E2EE-Zustand, Host-Daten, secret-safe Diagnose, Zeroisierung und externe Transporte als getrennte Grenzen behandeln.
Wissen öffnen →
Sie evaluieren einen konkreten Headless-Scope?Ordnen Sie Zielsystem, Bindings und benötigte Produktoperationen ein, ohne einen generischen Demo-Prozess zu starten.
Eine Nachricht. Drei Zuständigkeiten.
Verfolgen Sie eine Nachricht von der Host-Oberfläche bis zur Client-Rückmeldung.
Beispiel H-104 · Rückrufwunsch
1 · Erfassen
HostBitte rufen Sie mich zurück.
NutzereingabeNachrichtenentwurf
Der Host verantwortet Oberfläche und erlaubte Eingabe. Ein Entwurf stellt noch keine TI-M-Sitzung her.
2 · Übergeben
HeadlessHost-Aktion → lokale Schnittstelle
Client-VerantwortungSitzung + Verschlüsselung
Das Modul übernimmt den TI-M-Client-Kontext. Der Host wird weder zum zweiten Matrix-Client noch zur Messenger-Bridge.
3 · Rückmelden
HostClient-Ereignis zu H-104
Anzeige im HostStatus mit Bedeutung
Der Host zeigt den gemeldeten Zustand. Die Annahme durch den Client ist keine Zustell- oder Lesebestätigung.
Eine Host-Aktion nachvollziehen
Der Host stellt die Oberfläche bereit; das Headless-Modul besitzt den TI-M-Client-Kontext. Das Beispiel verfolgt eine Nachricht und erklärt, warum ein gemeldeter Client-Zustand nicht automatisch eine Zustell- oder Lesebestätigung ist.
Einordnung:
Matrix, FHIR®, TI, TI-M, TI-Flow, ZETA, ePA und gematik bezeichnen externe Standards, Infrastrukturen oder Integrationskontexte. Keine Zertifizierung, Zulassung oder Beauftragung durch gematik oder eine andere Behörde wird behauptet. Unterstützte Profile, Versionen und Betriebsgrenzen werden vor einem Einsatz schriftlich bestätigt.
Nächster technischer Schritt
Nicht mit einer Demo beginnen. Mit dem Integrationsscope.
Ein erstes technisches Gespräch dient dem Abgleich Ihrer Zielarchitektur mit den aktuellen MEMM Produkt- und Integrationsgrenzen – ohne daraus Verfügbarkeit, Konformität oder Liefertermin abzuleiten.
Architektur-Check
PVS, KIS, AVS, OEM oder Contact Center: Wir ordnen Host-Grenze, native Integration und erforderliche Headless-Produktoperationen ein.
Spezifikations- & Architekturabgleich
Wir betrachten relevante externe Profile und Versionsstände im Kontext Ihres Zielsystems und benennen offene, externe oder projektspezifische Voraussetzungen ausdrücklich.
Scope vor Pilot
Frühe Scope-Klärung reduziert technische und organisatorische Unsicherheit: Fachanwendung, MEMM-Produktgrenze und externe TI-/Provider-Verantwortung werden vor Pilotannahmen getrennt.
Technischer Scope-Composer
Gespräch strukturiert vorbereiten.
Die Eingaben werden nicht an diese Website übertragen. Nach dem Klick öffnet sich Ihr lokales E-Mail-Programm mit einem vorbefüllten Scope. Bitte senden Sie keine Gesundheits- oder Patientendaten.
Wenn Ihr System keinen mailto:-Handler verwendet, können Sie die Kontaktadresse direkt über die allgemeine Kontaktseite öffnen.
Einordnung Architektur- und Spezifikationsabgleich sind technische Einordnung, keine Rechtsberatung, Zertifizierung, Zulassung, Verfügbarkeitszusage oder verbindliche Aufwandsschätzung.