Real-time media and communication discipline

Document: SPEC-004. Revision: 0.19. Date: 2026-11-07. Lifecycle: Partially approved under delegated decision D-024; V1 resolution sections are active, later scope remains Draft. Supersedes: none.

Approved video-delivery successor — D-167

D-167/SPEC-024 supersedes microphone-master screen timing: video and application sound share an independent presentation timeline; microphone alignment is best effort and cannot cause video pausing by itself. Standard RTP may use adaptive recovery/buffering for the managed presentation profile. The current microphone worklet, 200 ms microphone residence cap, PTT and moderator all-audio mute remain active. Presentation timing and native pre-SFU engineering bounds are owned by SPEC-024; legacy screen timing text below is superseded to that extent. See SPEC-024.

Confirmed outcomes are R-010, R-014–R-015, R-022–R-029, R-031–R-036. Mechanisms, limits, and precedence below are PROPOSED until accepted.

Direct voice and relay fan-out (D-086)

D-086 and SPEC-017 supersede the relay-only route and per-recipient media upload for the new profile. Public channels remain relayed in both encryption modes; private E2EE calls prefer direct paths per listener with one relay upload for remaining recipients. Private readable channels remain relayed. Opus, PTT, personal controls and the 200 ms residence bound remain. SPEC-017 owns the routing/health constants and direct-receiver authority clearing.

Conversation extension — 2026-10-19

D-069 adds isolated conversation voice calls under SPEC-013. Existing room UUID routing, one active call per account, encryption, moderation and fresh-press move fencing apply to each derived call. Thread calls are available for text conversations, including text-only parents, without enabling a parent channel call.

Independent media roles

Treat microphone voice, screen video, application/system audio, and webcam video as separate track roles. Authorise and negotiate them separately. Self microphone mute stops the user's microphone; CONFIRMED D-019 makes moderator “Mute for everyone” stop all audio from the target participant across their devices while leaving permitted video running. A separate stop-all-media action remains proposed and must not be labelled merely as mute.

No screen/system/application audio track may bypass a participant-wide moderator mute. A hostile client can disguise microphone content as application audio; reliable semantic detection is not assumed, especially with E2EE. Therefore the confirmed mute revokes every audio role rather than attempting to identify speech. A narrower microphone-only publication control must explicitly disclose that other audio can continue. PTT-required rooms still need an explicit auxiliary-audio policy; PTT cannot attest the content or physical input of a hostile publisher.

Prefer selective forwarding of separate participant streams, preserving local per-user controls and avoiding unnecessary decode/re-encode work. Opus voice and WebRTC media transport are candidates; mandatory codecs, negotiation, licences, and fallback behaviour require a separate accepted media profile.

Optional PTT and voice activation (D-105)

R-111 supersedes the V1 always-PTT restriction for servers advertising ptt-policy/1 and the earlier proposed ancestor-OR policy for this property. Server pttRequired is an owner-written boolean, default true; channel pttRequired is null/inherit by default or an explicit boolean, written under existing channel settings authority. An explicit channel false overrides the server's true. Reject invalid types, preserve omissions on update, and publish effective values. Organizational parent channels do not supply PTT policy. Thread calls inherit their conversation parent's effective policy; direct/group calls inherit their host. SPEC-012 owns wire/storage.

Effective client PTT is personal PTT enabled OR resolved channel PTT required. Optional policy allows speech activation but never disables the user's PTT binding. Unknown/legacy policy remains mandatory. New and legacy personal preferences remain PTT-enabled. A change to mandatory PTT or personal PTT closes voice activation immediately and requires fresh input; becoming optional never starts microphone publication automatically.

Voice activation is explicitly enabled by the participant for an authorized connected call after selecting it in user settings. Detect microphone energy locally after normal echo/noise processing, with no recorded look-behind or cloud detector. The engineering profile uses 20 ms RMS windows, at least 60 ms above the selected threshold to start, and 600 ms below a release threshold 6 dB quieter to stop (D-189 engineering profile, preserving quieter syllables and brief pauses); frame timestamps own detector timing. A talkspurt retains the effective maximum continuous transmit duration and existing codec frame bound; reaching it requires a quiet interval before the next spurt. There is no silent fallback from unavailable PTT to voice activation.

All existing lease, mute, trust, encryption, scope-change, recording, suspension and permission gates apply. A policy/membership change, disconnect, input suspension, lost capture authority or browser focus loss disarms activation; recovery requires explicit enable, preventing unintended resumed speech. Normal silence alone retains armed activation. D-189 supersedes settings/menu-wide suppression: ordinary settings, menus and text navigation preserve an authorized input mode and current phrase. Only recording a new binding suppresses capture; changing input mode still stops the previous mode. A sensitivity-only edit updates the threshold without disarming activation. Display Voice activation listening, You’re transmitting, or Microphone off separately from connection state. PTT start/stop cues apply only to actual local PTT, not every speech-detected phrase. No voice-activity level is stored or uploaded.

Push to talk

Global PTT means press and release are recognised while another application has focus, including supported full-screen game configurations. It does not mean a hotkey confined to the chat window.

D-012 explicitly scopes this global behaviour to desktop clients. The web client uses focus-only PTT and stops transmission on focus loss. This is an accepted capability distinction, not a fallback to voice activation.

Proposed requirements:

• Support press-and-hold PTT; both press and release matter. D-113 adds an explicit held on-screen input when the configured shortcut is unavailable, without re-enabling that shortcut or changing the saved mode. Its pointer/keyboard release, cancellation, focus loss, settings pause and existing authority/maximum-duration gates stop transmission; a fresh hold is required afterward. D-047 now requires user-recorded keyboard, mouse-button and joystick-button bindings; SPEC-005 owns their client contract. Toggle-to-talk, axes/gestures and additional accessibility modes remain separate scope decisions.
• Gate microphone media locally on PTT state. Maintain the authorised media path so each press does not wait for a new server round trip.
• Do not transmit audio captured before the press or after release. Encoder/network buffers may drain already authorised samples; test capture timestamps rather than requiring packets to disappear instantly.
• Keep a visible transmit indicator distinct from microphone permission, connection, and speaking detection. Optional audible cues must be configurable.
• Stop transmission on loss of the hotkey session, device removal, OS lock, suspend, permission loss, leaving/switching the active voice session, or disconnect. D-152 adds the SPEC-005 Android exception: an already-active foreground-service call may retain explicitly enabled, policy-permitted voice activation with the screen off/backgrounded; held PTT still stops. D-163 requests the equivalent already-active-call exception for iOS under SPEC-005, with native implementation and physical acceptance still outstanding. Require a fresh valid press after recovery. Navigating to another text view does not change the voice target or stop a valid desktop PTT press; browser focus loss still stops transmission.
• Handle missed release events with a bounded fail-safe policy. A maximum continuous transmission duration is configurable; its default remains open.
• Never fall back silently to voice activation when PTT is unavailable. Offer listen-only participation with a clear explanation where policy permits.
• On policy change to PTT-only, stop any incompatible transmission before resuming under the new mode.

Historical proposal, superseded for PTT by D-105: the hosting domain's constraints set the allowed transmission modes; its community and room policy may restrict them further. A child setting cannot relax an ancestor's PTT requirement. The participant's chosen mode must be within the resulting permitted set. A home domain's additional restrictions on a foreign participant are a separate OPEN contract under Q-38; home-domain roles never become host-room authority.

The server can enforce publishing permission, duration limits, and revocation; it cannot prove a physical key is pressed on an arbitrary client. Even a signed “PTT active” message can be fabricated by that client. PTT-only therefore combines official-client behaviour with server-enforced publication policy. Do not describe it as hardware attestation.

Administrative bots that intentionally publish audio require an explicit policy. Do not silently exempt them from PTT because they are automated; the protocol does not rely on a human/bot distinction.

Mute and gain semantics

Confirmed under D-009: shared gain establishes a baseline; personal gain and mute remain listener preferences; the relay enforces hard moderator mute. Proposed numerical implementation: with gains expressed in dB, add shared and personal gain, apply defined safety limits, and apply local mute as a final silence gate. No moderator gain or unmute overrides a user's local mute. Device output volume remains under the listener's control.

Define the gain range, maximum amplification, limiter, clipping behaviour, persistence, and whether gain is per-room or per-session before implementation. Gain metadata must be authoritative and versioned; clients must not accept arbitrary peer claims of moderator adjustments.

In an E2EE room, the relay cannot modify encrypted samples. Conforming recipients apply the shared gain after decryption. A modified recipient can ignore it or amplify recordings; this is not a cryptographic volume limit. Even server-side gain cannot stop a receiver amplifying delivered audio later.

Hard moderator mute blocks every audio path owned by the participant in that room, including existing subscriptions, and prevents new audio publication until permitted. It applies to every supported publishing device; V1 supports one active device per account under D-020. Suppressing the UI icon is insufficient. Lifting a moderator mute grants permission; it does not enable capture or override self-mute/PTT. Video permission is unchanged by this mute. SPEC-008 owns pending/effective/failed enforcement and action revisions; SPEC-003 owns active forwarding leases. Relay forwarding cessation and the draining of audio already buffered at a recipient are different measurement boundaries.

Proposed default persistence: local per-user volume and mute survive reconnect; moderator mute survives participant reconnect until removed or its specified expiry. Room/session gain persistence remains open. Audit actions affecting everyone, including actor, scope, target, prior state, new state, and result.

Latency and quality

The user's voice-latency priority and webcam lip-sync requirement can conflict under bad conditions. Proposed resolution: permit only bounded extra audio delay in meetings; reduce/drop late camera frames, then pause video if the bound cannot be met. The allowable delay and sync tolerance need approval. Screen presentation delay never dictates the microphone jitter buffer.

Admin settings expose named profiles plus supported bounds for bitrate, bandwidth caps, frame rate/resolution, participant limits, and latency/quality policy. Clients negotiate effective settings within server limits and hardware/network capabilities. Report requested and effective values when they differ. Unsupported values fail clearly rather than being silently ignored.

Screen sharing and meetings

R-117–R-121/D-128–D-133 request screen sharing from alpha.23. SPEC-023 owns the shared successor contract: combined all-screen/single-screen/window capture, content and quality/speed intent, route-aware presentation bitrate and server-admin exceptions, optional presentation audio, synchronization with responsive voice, and listener-configurable half-volume game-sound ducking during PTT/speech. D-134 approves its remaining profile and delegates documented technical completion. Local alpha.24 integrates the runtime; alpha.23 remains the deployed baseline without screen sharing. Physical and capacity acceptance remain separate.

D-130 resolves the auxiliary-audio/PTT question for presentation sound: PTT gates microphone voice only, while explicitly enabled presentation sound may continue. D-019 moderator mute still silences every audio role. SPEC-023 owns the selected ducking defaults and timing contract; it does not change microphone gain or the 200 ms voice residence bound. Its configured screen-policy inventory replaces the earlier unselected generic screen/audio policy rows for this new feature only. Camera/meeting policy remains separate.

Let the publisher choose a display or window through the appropriate OS capture flow. Show the chosen source, persistent sharing state, preview, and an immediate stop action. Do not silently switch to whole-screen capture if a selected window disappears. Multiple monitors and permission revocation need explicit handling.

Simultaneous-presenter limits, HDR, high-DPI behavior and presenter handoff remain open in SPEC-023/Q-24. Optional screen audio and a combined all-screen view are now required under D-129/D-130; exact supported platform paths remain to validate. Receiving a stream should not require enabling microphone transmission. Webcams are available only under meeting policy and start only with participant action.

ICE/STUN/TURN connectivity, relay-only privacy mode, corporate-network fallback, and media route selection need a documented profile. Peer-to-peer direct calls may reduce infrastructure use but can expose peers' IP addresses. Whether to allow them is Q-12. Encrypted direct calls must remain encrypted on every supported route.

Moving voice between linked clients (D-046/D-059; SPEC-011/012)

One active voice client per account is confirmed. Signing in elsewhere leaves the existing voice session in place. Provide a destination action labelled “Move voice here”, showing the current source. Preparation alone grants no live membership, media keys, playback or publication at the destination. This selects no simultaneous multi-client listening.

Validate the target room/device, durably stop source renewal and revoke its active authority. The initial profile waits the full hard lease cutoff before preparing/admitting the target with fresh authority. Serialize competing moves. Clear held PTT on both clients; the destination must be ready and observe release followed by a fresh local press. Moderator mute, room membership and permissions are rechecked throughout. Neither a held input nor an old grant follows the account to another client.

If target validation fails before source revocation, leave the source session in place. After revocation starts, failure or an unknown outcome must not automatically resume either microphone or create overlapping attendance. Show the failed/pending move and reconcile the same operation; explicit rejoin is available after authority is known. SPEC-003's existing lease and hard revocation bounds remain unchanged. A move inside a Cloudflare generation preserves its original D-043 closing deadline; it cannot renew the shared 60-minute test session (D-054). SPEC-011/012 select the wire state and conservative four-second fence under Q-44.

Keyboard, mouse and joystick signals all feed the same capture gate. Recording/rebinding an input, device disconnection or loss of trustworthy release information closes that gate; recovery requires a fresh press. SPEC-005 owns capture UI and per-client binding persistence. Input type must not bypass account voice ownership, self-mute, moderator mute or lease validity.

Configuration

D-081/D-082: SPEC-016 owns temporary E2EE voice key lifetimes and replacement, including thread calls. Its profile supersedes static device-box encryption for updated calls. Successful periodic rotation does not clear a held PTT press; membership/policy changes and expiry/authority failure still do. Forwarding and playout bounds below are unchanged.

For D-055/D-058 room creation, D-095 replaces the fixed room default with a server pttMaxSeconds default of 600 seconds (integer range 10–600), as amended by D-222. Voice/combined rooms accept an optional pttMaxSeconds override in the same range; omission or null at creation inherits. Text-only creation rejects this field. The owner sets it at creation; authorised owner/moderator updates use the existing revision-checked room setting and clear held transmission. Multiple rooms retain the existing deployment-wide relay ceiling and shared bounded generation under SPEC-002; text navigation cannot move active voice or retarget a held press.

Property names and defaults are PROPOSED unless marked confirmed. These are logical properties for future code; they do not select codecs or a media library. Configuration validation must reject unknown values and publish effective inherited settings.

Hotkey/device bindings are owned by SPEC-005; provider selection by SPEC-002; grant lifetimes by SPEC-003. Desktop global PTT, web stop-on-focus-loss, shared-then-personal gain semantics, relay hard mute, and meeting-only webcams are fixed requirements rather than optional configuration flags.

Selected V1 media profile (D-024/D-027)

Superseded for updated calls by D-084 below: the following PCM/fixed-buffer paragraphs remain historical evidence for earlier alpha clients. They cannot override the Opus profile.

SPEC-009's relay profile and this section replace draft V1 codec, route, PTT, gain and lease choices. Use mono 16000 Hz signed 16-bit little-endian PCM, 320 samples per 20 ms frame, carried as recipient-encrypted messages on unordered WebRTC data channels with zero retransmissions. This requires more bandwidth than Opus; measure it for the 3–10-person fixture and make no production-capacity claim. There is no plaintext or reliable-WebSocket audio fallback. A runtime lacking the required capture/worklet/data-channel capabilities offers listen-only or explicit unavailability.

Historical V1 restriction, superseded for D-105 capable servers by the optional-PTT section above: hold-to-talk was the sole V1 transmit mode. It starts unbound. A fresh press is required after join, reconnect, permission change, device loss, lock/suspend, focus loss in web, or recipient revision change. Desktop window focus alone does not release global PTT. Capture samples outside the permitted press interval are discarded. No toggle, voice activation, auxiliary audio, screen or camera publication is enabled in V1. Unsupported modes fail rather than changing input discipline.

Receiver buffering is capped at 100 ms; queued old audio is dropped, never allowed to build an indefinite latency queue. Sequence/session replay checks precede playout. D-062 completes receiver scheduling: after the first authenticated frame, wait 60 ms before starting or restarting an empty stream. This is elapsed audio-clock time, not a requirement to receive three frames, so a short PTT press is still heard. Reorder authenticated frames by sequence until their playout deadline; reject duplicates and already played/discarded sequence numbers. Keep at most five frames including any frame currently playing. Discard only the oldest excess/stale frames, retaining the newest playable tail; a large sequence gap cannot generate unbounded silence. A frame must finish within 100 ms of its arrival at the worklet. Startup/rebuffering may add at most one render quantum of scheduling rounding to the target, while the hard cap remains enforced.

For a missing frame with later frames queued, preserve its 20 ms slot as silence with a 5 ms fade from the last sample; ramp back into received audio over 5 ms. When the queue empties, fade to silence and wait for a new frame before restarting the target delay; do not extrapolate sequence numbers across a PTT pause. Never repeat old speech to fill a prolonged outage. Session/revision clear removes all buffered audio and ramp state immediately; personal mute suppresses that speaker’s entire contribution, including queued audio and its ramp. These fixed client profile constants have no runtime/admin/user override or persistence. They do not change capture gates, forwarding leases or moderation deadlines. Each listener applies shared gain plus personal gain after decryption; D-187 supersedes the historical combined -48 through +6 dB cap with the bounded personal/shared composition below; mixed output remains hard-limited to +/-0.95 digital full scale, and local mute is the final silence gate. This is not a cryptographic amplification limit.

The table above lists the original V1 policies/preferences; D-105 adds the PTT mode settings in Configuration. Omission uses the listed defaults at creation; invalid types and out-of-range values fail; channel duration and D-105 mode overrides accept null as inheritance. D-095 adds server-to-channel duration inheritance; thread calls inherit the parent channel and direct/temporary calls inherit their hosting server. There is no additional community duration layer. Effective changes close capture and require a fresh press through the existing room revision mechanism. D-105 replaces the fixed host PTT requirement with channel override and personal-PTT precedence. Maximum room membership/attendance is ten as a V1 fixture safety limit, not a general production default. The 3000 ms forwarding lease and 4000 ms hard bound are owned by SPEC-003 and SPEC-007.

Personal playback expansion (D-187)

Personal playback gain is 0–4 times the moderator's shared baseline (0–400%; neutral 1/100%). Preserve existing encrypted device/account/qualified-participant gains records as dB values: legacy -24 through +6 dB retains its exact gain; 0 dB remains neutral. New percent selections convert with 20 * log10(percent / 100); percent zero stores finite -60 dB and means exact zero, never a logarithm of zero, JSON null or a tiny audible floor. The maximum is 20 * log10(4). Reading an invalid/nonfinite/out-of-range stored personal value falls back to neutral, without rewriting legacy records. The UI may round the displayed percent, without altering the stored value until edited.

Compute received gain as 10 ** (sharedGainDb / 20) * personalFactor, with authoritative shared -24 through +6 dB unchanged and personalFactor zero for the sentinel, otherwise 10 ** (localGainDb / 20). This replaces the old combined +6 dB ceiling so the personal 400% selection actually amplifies a neutral/shared-adjusted source by four. Maximum combined amplification is bounded by these two input limits. Preserve the existing final mixed-output limiter and local/moderator mute gates; amplification is local after decryption and grants no publication or administration authority.

Configuration: this expands the existing personal user preference, with unchanged scope, default, persistence and qualified-key fallback; no server override or wire/schema migration. Zero percent and the Mute for me boolean are independent silence controls. Unit tests cover exact zero, 100%, 400%, shared composition, invalid input, legacy dB preservation, reset and mute precedence. Rendered-audio coverage measures the gain ratio and exact silence without relying on human perceived loudness.

Acceptance criteria:

• A listener can silence a remote participant or apply four times their shared baseline; the old combined cap cannot defeat the requested boost.
• Stored legacy settings retain their gain, another listener is unaffected, and the existing limiter/mutes still apply.

Opus and adaptive playout (D-084)

D-084 replaces PCM and D-062's fixed receiver scheduling for updated calls. Keep unordered, zero-retransmission WebRTC data channels and the current relay/TURN route, placed under SPEC-002/D-216. Encode once per captured frame before recipient encryption/signing. The reviewed implementation uses libopus 1.6.1 through pinned libopus-wasm 0.4.1 in the AudioWorklet. Native RTP was evaluated: the browser exposes a preferred jitter target rather than a hard residence cap or a portable immediate decoded-buffer clear. Keeping worklet playout retains explicit capture gates, authority clearing and the human-selected hard bound. Moving to RTP/SFU is not claimed by this update.

These are fixed profile rules, with no runtime/operator/user override or persistence:

The wire representation and upgrade rejection are owned by SPEC-009; ephemeral key grants and overlap remain owned by SPEC-016. This update does not select a different hosting region or Cloudflare Realtime SFU.

Selected Cloudflare alpha behavior (D-043)

D-043, amended by D-054, limits each initial Cloudflare relay generation to 60 minutes. All participants share its remaining lifetime; at five minutes remaining warn current participants and reject new admissions to that closing generation. At closure or unexpected process restart, stop audio, discard stale sessions and require explicit rejoin and a fresh PTT press. Uninterrupted credential renewal is not selected. This does not change the native direct-hosting profile or D-042's eventual regional design.

Testing

D-113 media-session unit coverage verifies independent held on-screen input with shortcut readiness false, no shortcut re-enabling, source-specific release, manual-readiness loss, no automatic resume, personal/moderator mute enforcement and continuous-duration expiry requiring a fresh hold. Browser integration verifies the rendered pointer/keyboard controls with actual audio capture gating.

D-105 unit coverage includes personal/server/channel truth tables; malformed/legacy fail-closed policy; nullable overrides and role/revision checks; threshold/attack/release/max-duration boundaries; silence, stale levels, policy changes, blur, mute and re-enable gates. Synthetic audio browser tests verify no unauthorized/pre-activation samples, speech starts/stops, forced PTT and preserved private/public routing. Physical microphone quality remains a separate human test.

D-095/D-222 units cover the 600-second default and exact cutoff, server/channel override resolution, reset to inheritance, invalid/unauthorized/stale changes, live revision propagation including child thread calls, unaffected explicit overrides, and schema-6 migration/restart preserving non-60-second limits before the D-222 upgrade. D-222 tests additionally cover raising all saved shorter durations once, preserving inheritance/unrelated data, atomic rollback and subsequent shorter settings surviving restart.

D-084 units use the real pinned codec and deterministic audio clocks: valid encode/decode, invalid/oversized/wrong-duration packets, FEC attempts versus PLC fallback, consecutive-loss cutoff, authenticated end/reordering/old-press rejection, bounded queue and residence, 0–96 ms jitter, isolated loss and bursts. Check rendered output and codec timing, not merely received packet energy. Exercise startup, short presses, rebuffer adaptation/reduction, mute/clear and capture boundaries. Local diagnostics must contain only bounded aggregates. Repeat actual-browser encrypted/readable two-party calls and key-expiry/rotation tests; human listening and geographic latency remain separate acceptance evidence.

D-062 receiver units use deterministic arrivals with 0–48 ms jitter and reordering over a fixed 120 ms transit delay, repeated short/long talkspurts and pauses, actual loss, duplicate/stale frames, bursts, long stalls, and stream replacement. Check rendered samples, bounded frame residence/queue size, absence of gaps in the loss-free fixture, timely short-press playback, and immediate clearing/mute. Do not substitute received-packet energy for rendered-output continuity.

Successor media units cover competing handovers, late callbacks, source/target revocation, mute during movement, failed preparation, unacknowledged revocation and grant expiry. Assert zero overlapping source/target forwarding authority and no automatic PTT resumption. Run the same capture-gate tests with keyboard, mouse and joystick adapters, including held inputs on reconnect and while recording a binding.

Unit tests for media state machines, policy resolution, and mixing should cover:

• PTT press, release, repeat events, lost shortcut session, suspend/lock, disconnect, active voice-session switch, and permission loss; only samples with permitted capture timestamps enter the encoder.
• Text navigation preserves the active voice target while switching/leaving that voice session clears held input; no sample is redirected to a newly selected text room.
• Browser focus/tab loss while pressed stops the gate, and return of focus never resumes transmission until a fresh press. Desktop application focus changes alone do not stop a valid global PTT press.
• Effective policy resolution at each scope, invalid modes, default application, and immediate shutdown of incompatible publication when PTT-only policy becomes active.
• Shared plus personal gain, neutral gain, configured bounds, NaN/infinite/invalid input, limiter behaviour, and local mute precedence. Use fixed sample buffers and the approved gain formula.
• Moderator actions require authority, target every publishing device in scope, invalidate re-publication, and leave local self-mute/PTT state unchanged when lifted.
• Participant-wide moderator mute blocks microphone and presentation audio but preserves video permission; narrower self-microphone and stop-all-media actions remain distinct. Test republishing under another audio role and all supported devices.
• Codec/profile negotiation rejects incompatibility and unsupported settings; bandwidth pressure reduces lower-priority media without silently enlarging the approved voice delay budget.
• Capture-source loss does not select a different window/display; reconnect does not restart sharing without the required participant action.
• Fake-clock tests exercise lease expiry, maximum transmit duration, jitter/sync boundaries, delayed camera frames, and the approved video degradation policy.

Use fake input, clocks, media adapters, and deterministic audio/video fixtures. Real OS hotkeys, capture APIs, audible delay, and relay enforcement require platform/integration tests.

Acceptance criteria

• D-105: personal enabled PTT cannot be disabled by any server/channel policy; voice activation is available only when both personal and effective channel requirements permit it, and policy changes stop incompatible transmission before fresh input.
• Voice activation starts only after explicit enabling and sustained above-threshold microphone input, stops after silence or any existing authority failure, and does not emit PTT sounds for each phrase.

• D-095 as amended by D-222 defaults to 600 seconds per held press, permits server and channel settings within 10–600 seconds, and resolves a configured channel override before the server value. Live effective changes require fresh PTT; D-222 upgrades all saved shorter limits to 600 seconds once, preserving null inheritance and allowing subsequent shorter settings.

• D-084: real-browser encrypted and server-readable calls negotiate Opus, render audible test output, reject incompatible clients and retain fresh-press and key expiry rules.
• D-084: deterministic jitter/loss tests show adaptive targets within the selected bounds, bounded PLC/FEC handling and no frame completing after 200 ms residence. Muting and authority clearing suppress all decoded/concealed samples immediately.
• D-084: measure encoded/wire sizes and rendered continuity against the recorded PCM fixture; do not equate automated energy checks with human perceived quality.

• Earlier PCM profile (D-062, superseded by D-084): the deterministic loss-free jitter fixture renders every frame in order without interior dropouts; startup and post-pause speech use the selected bounded buffer. Loss/stalls cannot replay old speech or grow the queue beyond its cap. Report human Canada/EU listening separately, including remaining startup choppiness.

• A-36 demonstrates explicit voice movement with no overlapping attendance/forwarding, fresh destination PTT and unchanged shared generation deadline. A-37 demonstrates identical hold/release and stop behavior for keyboard, mouse and joystick input without weakening A-07/A-24/A-29.

• On supported KDE Wayland and Windows test setups, hold and release PTT while a game has focus and verify remote audio contains only authorised capture intervals. Lock/suspend or lose the hotkey session and verify transmission stops. See A-07.
• In the web client, lose focus or switch tabs while holding PTT and verify remote microphone transmission stops; returning focus without a new press remains silent. See A-24.
• Resolve server policy and an explicit channel override, then apply personal PTT as an additional requirement. Official clients permit voice activation only when both personal and effective channel requirements are false; policy changes stop incompatible publication. See A-08/A-44.
• With three users, change local mute/gain and observe a change only for that listener; change shared gain and observe the baseline at every conforming listener while preserving personal controls. See A-09.
• Hard-mute a participant with existing listeners on every supported publishing device; all audio forwarding stops within the approved bound, video may continue, and audio re-publication is denied. Run the one-device case in V1; under D-046 test all signed-in devices, attempts to publish simultaneously and mute during handover while preserving one active voice client. A two-active-publisher fixture applies only if a later decision permits it. Exercise partial adapter failure and active-lease expiry under A-29; do not report pending enforcement as effective. See A-10.
• Hold desktop PTT while opening another room's text; the original voice session remains the sole target. Switch the active voice session while held and verify a fresh press is required before the new target receives audio. See A-07.
• Share an explicitly chosen window/display, then close/revoke it; viewers receive no substitute source. Repeat under presentation load while measuring the approved voice-latency target. See A-12/A-17.
• Attempt webcam publication outside a meeting and receive rejection; inside a meeting, measure the approved voice/camera sync and maximum-delay bounds under clean and impaired conditions. See A-14.
• Change supported media settings through an authorised client and verify validation, effective values, inherited constraints, and the specified live-session propagation behaviour. See A-11.

D-063 relay resource enforcement

The existing 4096-byte packet ceiling is also advertised/enforced at SCTP negotiation. All received binary packet attempts, including malformed or oversized packets, consume the existing 600 packets/second and 524288 bytes/second input quotas before parsing and signature work. Readable signature verification runs outside the shared relay lock, followed by a fresh complete authority check before forwarding. Pending ICE offers reserve slots under the existing ten-peer deployment cap; reservations are released on failure or committed atomically. No buffering, lease, media-format or placement default changes.