TI-M Calling: endpoint, media path and contact-center architecture

Scope and the two profiles

One active call per local account/device context, two TI-M devices and a private encrypted room with two users. Several devices of one user may receive an invite; selection of the answering device determines the media peer. Multiparty conferencing, MCU/SFU, SIP/PSTN and messenger bridging are outside this design.

The native host and Headless module run in the controlled process at the operator workstation. Headless holds PeerConnection and Matrix/media keys; the host supplies consent, microphone/camera, playback and visible controls. PCM/image data passes through the local function boundary. The host is therefore a trusted plaintext participant; E2EE does not protect against it or a compromised platform. The external media route must also meet the TURN/TLS profile below.

The host and Headless module run together on the central server. TI-M E2EE ends there. An authenticated operator device carries audio over the host’s own WSS/TLS 1.3 channel; only the host’s local functions invoke Headless. The host may process the permitted audio in the defined healthcare workflow. The WSS leg is a separate transport, not continuation of the same TI-M E2EE and not a Headless network API. Video, recording and transcription are not enabled in this first central profile.

Ownership from room to media endpoint

• Headless · signalling — ITL decision: The module processes encrypted m.call.* room events, checks their origin and owns the call state machine. Matrix client/service traffic uses the bound TLS contract. The host sends application commands and receives state updates; it does not replace SDP validation or the Matrix event validator.
• Headless · media and keys — ITL decision: PeerConnection, ICE, codec/RTP processing, the DTLS certificate, key agreement and SRTP/SRTCP remain in the module. Keys, exportable PeerConnection objects and arbitrary SDP injection are not host API features. The Olm/Megolm audits in A_25598/99 do not automatically establish the security of the media library.
• Host · controls and plaintext I/O — ITL decision: The host authenticates the operator, checks purpose and permissions, obtains device consent and presents call, microphone/camera and hang-up controls. It receives or supplies authorized plaintext media. Raw audio in the host is not key export, but expands trusted processing and must be covered by the privacy and operating design.
• Provider · integration and relay — ITL decision: The provider owns the coordinated integration, released artifacts, the actual TURN profile and the GTI change process before integration and for material changes. One host login or a shared Matrix ID does not prove an individual operator identity; the host binds each action to its authenticated operator.
• Runtime · controlled trust boundary — ITL decision: FFI is not memory isolation against arbitrary native host code. The design requires a controlled signed process without unauthorized native extensions, appropriate process/access controls and no production dump/debug interfaces. A_28703 excludes a compromised platform and privileged administrators from its protection scope.

Three data flows with distinct endpoints

• Signalling · both profiles — ITL decision: Host command → local Headless function → E2EE-protected Matrix room event over TLS to the TI-M service → peer. An answer takes effect only after validation of room, user, session origin, call and selected party.
• TI-M media · both profiles — Engineering inference: Headless encrypts media for the selected peer device with SRTP/SRTCP. Packets travel inside TLS/TCP to its TURN allocation, pass to the peer allocation within the same controlled VM, and travel inside that allocation’s TLS/TCP connection to the peer device. ICE/DTLS packets use this same path; the TURN service receives no SRTP keys.
• Operator audio · profile B only — ITL decision: Workstation capture → authenticated WSS/TLS channel → central host → local media function → Headless. Reception reverses the path: Headless decrypts → local media function → host → WSS/TLS → playback. Plaintext exists in the server module, authorized host and operator device. Host WSS does not carry TI-M DTLS/SRTP keys.

Network profile: TLS at every machine boundary

• TLS and DTLS remain different protocols — Source requirement: A_25299 requires TLS across virtual/physical machine boundaries between TI-M components; A_25573 incorporates the cryptographic requirements. DTLS-SRTP alone is not described here as satisfying that TLS rule. gemSpec_Krypt 2.50.0 requires TLS 1.2 support and permits TLS 1.3 subject to conditions; general product support for TLS 1.2 is retained.
• ITL profile · both devices on one TURN instance — Engineering inference: This media path selects TLS 1.3, turns:…?transport=tcp and iceTransportPolicy=relay. Both peers require authorized, authenticated allocations on the same dedicated TURN instance in the same VM. The provider binds relay address, allocation admission, expiry and routing to this deployment. A relay candidate may correctly report protocol=udp: validation concerns TLS between client and TURN plus the local relay path, not an invented TLS candidate type. DNS names, candidate type or a turns: entry alone prove neither a shared instance nor TLS on the peer leg.
• UDP must not leave the relay machine — Engineering inference: Under RFC 8656, TURN over TLS protects the client–relay leg; the ordinary relay–peer leg uses UDP. The selected topology permits this forwarding only between the two local allocations on the same VM. No external NAT hairpin, second relay server, VM hop or upstream TLS terminator with an unprotected backend leg. Operating validation must establish the actual packet path.
• Incompatible path → call unavailable — ITL decision: This profile does not use direct host/server-reflexive candidates or other relay destinations. Remote candidates and the selected pair must match the released instance; its allocation policy enforces TLS/TCP for both profile participants and restricts peer destinations to local allocations. Without this assurance on both sides, admission fails. There is no fallback to UDP outside the VM, plaintext RTP or an arbitrary public TURN service.
• Narrow interoperability scope — ITL decision: Both providers or endpoints must coordinate the shared relay profile. The standardized homeserver TURN endpoint can supply it, but does not guarantee this operating profile. TLS/TCP can cause head-of-line delay. Availability, latency and capacity remain to be measured; this design does not establish general TI-M Calling interoperability.

Binding user, device, call and media

• Trusted session origin — Source requirement: Calling binds the expected user to a validated Olm→Megolm session and its device trust evidence. Matrix 1.17 prohibits using the outer Megolm sender_key or device_id fields to establish origin or index sessions. Room, event sender and session_id must match the trusted session; replay checks and key-origin validation remain active.
• ITL trust policy before media admission — ITL decision: Before releasing media, the design requires an explicitly confirmed cross-signing/device trust chain to the peer; unconfirmed trust on first use is insufficient for this profile. This stricter call admission is ITL policy. A new or replaced device is not silently admitted; verified transfer of an own-user session is checked, and lost provenance is not treated as a secure origin.
• party_id is not a device certificate — ITL decision: call_id and the user/party_id pair select the participant; party_id need not equal the Matrix device ID. Headless internally binds these values to the checked session origin and fingerprint in the accepted SDP. The DTLS handshake must match the expected fingerprint. TLS to the homeserver or a readable display name alone does not authenticate the media peer.
• No cryptographic downgrade — ITL decision: The media path requires SRTP and SRTCP. Plaintext RTP/RTCP, NULL ciphers, SDES key delivery and mismatched peer fingerprints are rejected. Each new call is assigned a fresh DTLS certificate and private key; keys are not exposed to the host. SDP/ICE renegotiation remains distinct from DTLS renegotiation prohibited by RFC 8827.

Local module contract and central audio channel

• Opaque handles and bounded commands — ITL decision: The local contract offers start/accept/reject/end, microphone/camera state, media I/O and subscribed status updates. Opaque handles are bound to tenant, account, device, call and generation; invalid or reused handles are rejected. The host receives no crypto objects, raw keys, generic network proxy or API to bypass event validation. The C ABI form is ITL design.
• Profile B · versioned WSS frame channel — ITL decision: ITL reference profile v1: mono PCM16LE at 48 kHz in 20 ms blocks (1,920 audio bytes), with resampling in the trusted audio adapter. Each block carries channel ID, lease generation, direction, sequence and capture time; its server-side binding covers tenant, operator, account, device and call. Only the agreed size and sequence are accepted. Access tokens do not appear in the WebSocket URL; frames contain no TI-M keys. This is a contract definition, not a shipped transport.
• Profile B · exactly one authorized operator — ITL decision: A server-side exclusive call lease prevents parallel media control of a shared Matrix ID. Reference values: authenticated heartbeat every 5 seconds, expiry after 15 seconds without valid renewal; audio buffering at most 200 ms per direction, then discard stale frames. WSS closure, revoked authorization or lease loss stops media and the call. Recording, persistent audio buffers and transcription are off by default; a change requires its own scope and change process.

States, compatibility and errors

• Idle → prepared → ringing — ITL decision: Before starting or accepting, validate the room, peer, trust status, local context, media permission and relay profile. A still-valid invite may ring only after full sync processing including decryption attempts. The reference invite lifetime is 90 seconds; age plus locally elapsed time bounds its remaining life. Missing media access produces the appropriate protocol error.
• Ringing → selected → connected — ITL decision: For version 1, exactly one answering party is selected; unselected devices stop locally without destroying the selected call with a general hangup. This ITL design releases media only after valid selection, fingerprint and path checks. A second incoming invite is offered to the operator or ignored; it is not automatically rejected with user_busy merely because of the local one-call limit.
• Distinguish Matrix 0 and 1 correctly — ITL decision: Send version as string "1". Numeric 0 is handled as the legacy version; other values are treated as version "1" as specified by Matrix. Version 0 uses its own flow and hangup semantics, without artificially requiring select_answer or negotiate. Protocol compatibility relaxes neither identity checks nor TLS/SRTP policy; missing security leads to safe termination, not an invented version rule.
• Simultaneous calls and renegotiation — ITL decision: Resolve same-room glare before the local busy/lease decision: if the peer invite arrives before the local invite was sent, end local preparation in favour of the incoming call, retaining admission checks. If both invites were sent and are awaiting an answer, the lexicographically smaller call_id wins. Version 1 renegotiation may come only from the selected peer; expired SDP offers and own remote echoes have no effect. ICE restart retains the same identity and relay policy. Reusing an old call handle cannot switch to a new operator or media path.
• Ending → release resources → idle — ITL decision: Hangup, peer room departure, logout, revoked authorization, host shutdown or lease loss ends capture, playback, queues, PeerConnection and call keys. Best-effort hangup signalling does not block local termination. Call secrets are erased where technically possible; long-lived Matrix/cross-signing keys are not confused with call keys. Old audio blocks are never automatically replayed into a new call.
• Preserve errors, bound diagnostics — ITL decision: The host retains Matrix/TI-M codes and original hangup reasons (A_28854): for example, ice_failed before an initial media path, ice_timeout after a previously successful path and user_media_failed. Local ITL causes such as “call profile unavailable” remain identifiable as local causes. Audit records rejection and state changes, not raw media, TURN credentials, complete SDP/ICE contents or reconstructable crypto dumps.

Required targets for later runtime acceptance

• Module and key boundary — Acceptance: not run: Check the actual artifact: no local/public network API to the host; no exported Matrix/DTLS/SRTP keys or PeerConnection objects; reject invalid handles, signatures and configurations. Exercise process, memory, debug and dump controls against the agreed threat model.
• Foreign device and modified SDP — Acceptance: not run: Modified event sender, room_id, session origin, party_id and DTLS fingerprints, as well as replay, unknown devices and unauthorized key forwarding, must fail at the correct validation step. Outer sender_key/device_id must not cause a positive trust decision. Authenticated peers must succeed through the same path.
• Both TURN legs and actual routing — Acceptance: not run: With both real endpoints and packet/configuration evidence, establish TLS on both allocation connections, the same VM, exclusively local relay forwarding and no external UDP leg. Exercise a second relay, external NAT hairpin, unauthorized candidate and TLS failure; each must fail without direct fallback.
• Versions, glare and multiple devices — Acceptance: not run: Exercise version 0/1, simultaneous invites, multiple answering devices, late reject/hangup, expired invites, ICE restart and room departure. In particular, unselected devices must not end the selected call; wrong peer fingerprints and unsafe ciphers must not be accepted as legacy compatibility.
• Profile B: tenant, operator and lease — Acceptance: not run: Exercise cross-tenant/cross-call frames, duplicate or stale sequences, changed lease generations, two operators, revoked access and WSS closure. A call must not continue processing audio after losing admission. Verify buffer limits, resampling, capture stop and absence of recording; TLS termination and any backend hop must match the documented boundary.
• Approval and measured usability — Acceptance: not run: Document actual library versions, media-crypto security evidence, codec compatibility, audio/video devices and load/latency measurements. Olm/Megolm audit, R1001 operation counts or website QA do not replace this media evidence. The provider handbook, integration approval and required GTI change must include the selected profile and its TLS rationale.

Retained deployment alternatives

• Central business processes, local Calling — ITL decision: A contact center needing audio/video and the TI-M E2EE endpoint at the operator workstation uses profile A there. Chat/business-process management may remain central; workstation and server are documented as separate device/account contexts with their own authorization. Endpoint selection is visible and does not transfer server keys to the operator device.
• Chat remains available; Calling is not promised — ITL decision: If a peer cannot support the shared TURN/TLS profile or trust policy, Calling remains unavailable for that pairing. Existing authorized chat is not repurposed into an unreviewed media path. Direct DTLS-SRTP routes or multiple-relay models require a separately justified architecture change and renewed acceptance.