Files
SHiNE-server/DOC/Протокол звонков (MVP).md

76 lines
2.7 KiB
Markdown

# Протокол звонков (MVP)
Версия: browser-to-browser, runtime-only signaling.
## Цели
- Технические сообщения звонка не сохраняются в БД direct_messages.
- Первый INVITE рассылается всем активным сессиям получателя и дублируется web push.
- Последующие сигналы идут только в конкретную sessionId и не дублируются в push.
## Операции API
### 1) CallInviteBroadcast
Отправляет общий вызов пользователю.
Запрос payload:
- `toLogin: string`
- `callId: string`
- `type: 100` (INVITE)
Поведение сервера:
- Рассылает `IncomingCallInvite` во все активные WS-сессии `toLogin`.
- В payload события передаёт:
- `fromLogin`
- `fromSessionId` (session инициатора)
- `toLogin`
- `callId`
- `type=100`
- `timeMs`
- Отправляет web push уведомление о входящем вызове.
Ответ payload:
- `callId`
- `deliveredWsSessions`
- `deliveredFcmSessions`
### 2) CallSignalToSession
Отправляет технический сигнал в конкретную сессию.
Запрос payload:
- `toLogin: string`
- `targetSessionId: string`
- `callId: string`
- `type: int`
- `data: string` (для SDP/ICE/служебных строк)
Поведение сервера:
- Ищет только `targetSessionId`.
- Проверяет, что сессия принадлежит `toLogin`.
- Отправляет `IncomingCallSignal` только в эту сессию.
- В БД ничего не сохраняет.
- Push не отправляет.
Ответ payload:
- `delivered: boolean`
## Коды type
- `100` INVITE
- `110` RINGING
- `120` ACCEPT
- `130` DECLINE_BUSY
- `140` TIMEOUT
- `150` HANGUP
- `200` OFFER
- `210` ANSWER
- `220` ICE
## Правила UI/логики
- Если уже есть активный звонок и пришел новый INVITE -> автоответ `DECLINE_BUSY` без UI.
- После ACCEPT `callId` остаётся во всех OFFER/ANSWER/ICE сообщениях до конца звонка.
- При параллельных звонках A<->B допускается детерминированное правило, кто создаёт OFFER.
## Тайминги MVP
- Ожидание подтверждения/реакции после INVITE: до 5с (у инициатора).
- Ожидание принятия у входящего звонка: 20с.
- Общий лимит ожидания до соединения: 22с.