KSMP Whisper / WhisperStreamVoice / Ревизия 2026-03-01 / v1.1

Профиль звонков KSMP Whisper и технология WhisperStreamVoice

Настоящая спецификация устанавливает звонковый профиль головного протокола KSMP Whisper и требования к технологии WhisperStreamVoice для качества медиапотока, включая E2E-инициализацию, шифрование, эволюцию ключей и транспортную согласованность.

1. Область применения

  • Документ определяет профиль голосовых и видеозвонков в составе головного протокола KSMP Whisper.
  • Технология WhisperStreamVoice используется для медиапути и качества передачи в звонке.
  • Криптографическая модель профиля является производной от Signal; полная совместимость форматов с внешними стеками не заявляется.

2. Установление звонка и E2E-инициализация

  • Инициатор ДОЛЖЕН запускать звонок с E2E-параметрами (`e2eVersion=1`, `callerPubKey`).
  • Принимающая сторона ДОЛЖНА отправить `calleePubKey` до перехода в активное медиасостояние.
  • Обе стороны ДОЛЖНЫ выводить секрет звонка на клиенте через ECDH + HKDF с привязкой к `callId`.
HKDF( input = X25519(callerPriv, calleePub), salt = UTF8(callId), info = "kasty.call.room-secret.v1", outLen = 32 )

Сервер НЕ ДОЛЖЕН выступать источником рабочего открытого секрета звонка.

3. Шифрование медиапотока

  • Голосовые и видеокадры ДОЛЖНЫ шифроваться на клиенте до передачи в ретрансляционный транспорт.
  • Используется AES-GCM; nonce строится из префикса отправителя и монотонного счетчика.
  • Клиент ДОЛЖЕН отклонять пакеты с невалидной аутентификацией и повторы вне допустимого окна.
  • Медиапоток звонка НЕ ДОЛЖЕН отправляться в открытом виде.

4. Эволюция ключей и PCS

  • Поддерживаются режимы `session` / `periodic` / `per-packet` по политике клиента.
  • Механизму PCS СЛЕДУЕТ периодически ротировать ключ отправки с подтверждением получения (ACK).
  • При фиксации новой эпохи счетчики nonce ДОЛЖНЫ сбрасываться в пределах новой эпохи.

5. Согласование транспорта

Порядок выбора (от приоритетного к резервному):

wsBinaryV1 -> callMediaV1 -> relay
  • При поддержке обеими сторонами в качестве основного пути ДОЛЖЕН использоваться `wsBinaryV1`.
  • При отсутствии `wsBinaryV1` СЛЕДУЕТ использовать `callMediaV1`.
  • При недоступности двух предыдущих вариантов МОЖЕТ использоваться `relay`.
  • После выбора `wsBinaryV1` в рамках текущего звонка переключение в середине звонка на медиаканал Socket.IO не выполняется.

6. Надежность и отказоустойчивость

  • При пропуске приглашения в окне `ONLINE_ONLY` инициатор выполняет ограниченную повторную отправку с нарастающей задержкой.
  • Сигналы готовности (`ready`) СЛЕДУЕТ повторять до фиксации состояния готовности второй стороны.
  • Для зависших сессий ДОЛЖЕН существовать механизм очистки по тайм-ауту.
  • При отключении или ошибке механизм переключения сокетного узла СЛЕДУЕТ переводить клиента на следующего кандидата.
  • При отказе выбранного пула механизм резервного токена ретрансляции МОЖЕТ переключать выбор на пул по умолчанию.

7. Нормативные требования

  • Клиент ДОЛЖЕН завершить согласование транспорта звонка до начала активной передачи медиапотока.
  • Клиент НЕ ДОЛЖЕН отправлять голосовые и видеокадры в открытом виде.
  • Клиент ДОЛЖЕН синхронизировать эпоху ключа на границах повторной выработки ключей (`rekey`).
  • Сервер и ретрансляционный узел ДОЛЖНЫ маршрутизировать шифротекст без доступа к открытому медиасодержимому.
Изменение приоритетов транспорта или семантики повторной выработки ключей (`rekey`) требует новой ревизии спецификации.
Предыдущий документ: KSMP Whisper Ultra OOB · Следующий документ: Транспорт и метаданные.
KSMP Whisper / WhisperStreamVoice / Revision 2026-03-01 / v1.1

KSMP Whisper Call Profile and WhisperStreamVoice Technology

This specification defines the call profile of the core KSMP Whisper protocol and requirements for WhisperStreamVoice media quality technology, including E2E setup, media encryption, key evolution, and transport consistency.

1. Scope

  • This document defines voice/video call profile inside the core KSMP Whisper protocol.
  • WhisperStreamVoice is used as media-path quality technology for calls.
  • Signal-derived key evolution is used; full wire compatibility with external stacks is not claimed.

2. Call setup and E2E bootstrap

  • Caller MUST initiate call with E2E parameters (`e2eVersion=1`, `callerPubKey`).
  • Callee MUST send `calleePubKey` before active media state.
  • Both sides MUST derive call secret client-side via ECDH + HKDF bound to `callId`.
HKDF( input = X25519(callerPriv, calleePub), salt = UTF8(callId), info = "kasty.call.room-secret.v1", outLen = 32 )

Server MUST NOT act as operational plaintext call-secret source.

3. Media encryption model

  • Voice/video frames MUST be encrypted on client side before relay transport.
  • AES-GCM is used; nonce is sender-prefix plus monotonic counter.
  • Client MUST reject invalid authentication and replay outside accepted window.
  • Call media MUST NOT be sent in plaintext.

4. Key evolution and PCS

  • `session` / `periodic` / `per-packet` modes are supported by client policy.
  • PCS SHOULD rotate send key periodically with ACK semantics.
  • On epoch commit, nonce counters MUST reset in new epoch context.

5. Transport negotiation

Selection order (preferred to fallback):

wsBinaryV1 -> callMediaV1 -> relay
  • When both sides support it, `wsBinaryV1` MUST be selected as primary path.
  • If `wsBinaryV1` is unavailable, `callMediaV1` SHOULD be selected.
  • If both are unavailable, `relay` MAY be selected.
  • After selecting `wsBinaryV1` for a call, mid-call fallback to Socket.IO media path is not performed.

6. Reliability and failover

  • On missed invite in ONLINE_ONLY window, caller performs bounded resend with backoff.
  • `ready` SHOULD be retried until peer-ready is observed.
  • Stuck sessions MUST have timeout cleanup.
  • On disconnect/error, socket endpoint failover SHOULD switch to next endpoint candidate.
  • On pool rejection, relay token fallback MAY switch to default pool.

7. Normative requirements

  • Client MUST complete call transport negotiation before active media transmission.
  • Client MUST NOT send voice/video frames in plaintext.
  • Client MUST synchronize key epoch at rekey boundaries.
  • Server and relay MUST route ciphertext without plaintext media access.
Any change in transport priority or rekey semantics requires a new spec revision.