Loading documentation...
Preparing Ring content
Концепції, цінність і типові сценарії
Концепції, цінність і типові сценарії
Preparing Ring content
Preparing Ring content
Preparing Ring content
Використовуйте вкладки Founder / Developer на бічній панелі документації, щоб фільтрувати цю сторінку. Видимість у бічній панелі налаштовується в lib/docs/audience-curated-docs.ts.
Месенджер Ring може здійснювати аудіо- й відеодзвінки 1:1 усередині прямої розмови. Сигналізація проходить наявним каналом Tunnel conversation:{id}. Для медіа використовується браузерний RTCPeerConnection. Обхід NAT забезпечує STUNner (STUN/TURN) у кластері, а ICE-сервери надходять через автентифікований API — облікові дані ніколи не потрапляють у NEXT_PUBLIC_*.
| Рівень | Роль |
|---|---|
| UI | Phone / Video у заголовку розмови → повноекранний оверлей дзвінка |
| Сигналізація | Події Tunnel call:invite … call:hangup у conversation:{id} |
| ICE | GET /api/webrtc/ice-servers (потрібна сесія) |
| TURN | Шлюз STUNner TURN-UDP:3478 (наприклад, turn.ring-platform.org) |
Пов’язані матеріали: Месенджер · Ігри з друзями · Протокол Tunnel · Архітектура реального часу
Ігри з друзями використовують спільний м’ютекс дзвінка ↔ гри (features/peer-games/lib/peer-game-mutex.ts). MessagesShell публікує setPeerCallBusy із фази WebRTC, тому банер /games і віджети game_request відмовляються приймати запрошення, поки триває дзвінок. Синхронізація між вкладками проходить через BroadcastChannel (необов’язковий navigator.locks). Ігри з друзями також повторно використовують GET /api/webrtc/ice-servers для оптимістичних підказок ходів через DataChannel — Tunnel + DB залишаються SSOT дошки.
Учасники швидше укладають угоди, коли можуть розмовляти, не залишаючи ваш Ring. Дзвінки залишаються в тій самій розмові, яка вже містить контекст можливості, сутності або магазину.
Розмови, групи та живий чат Tunnel.
Канал реального часу, який дзвінки використовують для запрошення, прийняття та завершення.
Тут описано розміщення STUNner і налаштування env для клонів k8s.
stunner-system), а Gateway налаштовано в просторі імен .Залежить від: дзвінки починаються із заголовків прямих розмов у месенджері.
Той самий процес: спільний м’ютекс дзвінка/гри (BroadcastChannel); ICE route повторно використовується для оптимістичних підказок ходів через DataChannel.
Залежить від: call:invite … call:hangup проходять через conversation:{id}.
Той самий процес: офлайновий банер ОС CALL_INVITE (FCM лише з data, TTL 90 с, RFC no-op у Chrome).
Використовуйте вкладки Founder / Developer на бічній панелі документації, щоб фільтрувати цю сторінку. Видимість у бічній панелі налаштовується в lib/docs/audience-curated-docs.ts.
Месенджер Ring може здійснювати аудіо- й відеодзвінки 1:1 усередині прямої розмови. Сигналізація проходить наявним каналом Tunnel conversation:{id}. Для медіа використовується браузерний RTCPeerConnection. Обхід NAT забезпечує STUNner (STUN/TURN) у кластері, а ICE-сервери надходять через автентифікований API — облікові дані ніколи не потрапляють у NEXT_PUBLIC_*.
| Рівень | Роль |
|---|---|
| UI | Phone / Video у заголовку розмови → повноекранний оверлей дзвінка |
| Сигналізація | Події Tunnel call:invite … call:hangup у conversation:{id} |
| ICE | GET /api/webrtc/ice-servers (потрібна сесія) |
| TURN | Шлюз STUNner TURN-UDP:3478 (наприклад, turn.ring-platform.org) |
Пов’язані матеріали: Месенджер · Ігри з друзями · Протокол Tunnel · Архітектура реального часу
Ігри з друзями використовують спільний м’ютекс дзвінка ↔ гри (features/peer-games/lib/peer-game-mutex.ts). MessagesShell публікує setPeerCallBusy із фази WebRTC, тому банер /games і віджети game_request відмовляються приймати запрошення, поки триває дзвінок. Синхронізація між вкладками проходить через BroadcastChannel (необов’язковий navigator.locks). Ігри з друзями також повторно використовують GET /api/webrtc/ice-servers для оптимістичних підказок ходів через DataChannel — Tunnel + DB залишаються SSOT дошки.
Учасники швидше укладають угоди, коли можуть розмовляти, не залишаючи ваш Ring. Дзвінки залишаються в тій самій розмові, яка вже містить контекст можливості, сутності або магазину.
Розмови, групи та живий чат Tunnel.
Канал реального часу, який дзвінки використовують для запрошення, прийняття та завершення.
Тут описано розміщення STUNner і налаштування env для клонів k8s.
stunner-system), а Gateway налаштовано в просторі імен .Залежить від: дзвінки починаються із заголовків прямих розмов у месенджері.
Той самий процес: спільний м’ютекс дзвінка/гри (BroadcastChannel); ICE route повторно використовується для оптимістичних підказок ходів через DataChannel.
Залежить від: call:invite … call:hangup проходять через conversation:{id}.
Той самий процес: офлайновий банер ОС CALL_INVITE (FCM лише з data, TTL 90 с, RFC no-op у Chrome).
Використовуйте вкладки Founder / Developer на бічній панелі документації, щоб фільтрувати цю сторінку. Видимість у бічній панелі налаштовується в lib/docs/audience-curated-docs.ts.
Месенджер Ring може здійснювати аудіо- й відеодзвінки 1:1 усередині прямої розмови. Сигналізація проходить наявним каналом Tunnel conversation:{id}. Для медіа використовується браузерний RTCPeerConnection. Обхід NAT забезпечує STUNner (STUN/TURN) у кластері, а ICE-сервери надходять через автентифікований API — облікові дані ніколи не потрапляють у NEXT_PUBLIC_*.
| Рівень | Роль |
|---|---|
| UI | Phone / Video у заголовку розмови → повноекранний оверлей дзвінка |
| Сигналізація | Події Tunnel call:invite … call:hangup у conversation:{id} |
| ICE | GET /api/webrtc/ice-servers (потрібна сесія) |
| TURN | Шлюз STUNner TURN-UDP:3478 (наприклад, turn.ring-platform.org) |
Пов’язані матеріали: Месенджер · Ігри з друзями · Протокол Tunnel · Архітектура реального часу
Ігри з друзями використовують спільний м’ютекс дзвінка ↔ гри (features/peer-games/lib/peer-game-mutex.ts). MessagesShell публікує setPeerCallBusy із фази WebRTC, тому банер /games і віджети game_request відмовляються приймати запрошення, поки триває дзвінок. Синхронізація між вкладками проходить через BroadcastChannel (необов’язковий navigator.locks). Ігри з друзями також повторно використовують GET /api/webrtc/ice-servers для оптимістичних підказок ходів через DataChannel — Tunnel + DB залишаються SSOT дошки.
Учасники швидше укладають угоди, коли можуть розмовляти, не залишаючи ваш Ring. Дзвінки залишаються в тій самій розмові, яка вже містить контекст можливості, сутності або магазину.
Розмови, групи та живий чат Tunnel.
Канал реального часу, який дзвінки використовують для запрошення, прийняття та завершення.
Тут описано розміщення STUNner і налаштування env для клонів k8s.
stunner-system), а Gateway налаштовано в просторі імен .Залежить від: дзвінки починаються із заголовків прямих розмов у месенджері.
Той самий процес: спільний м’ютекс дзвінка/гри (BroadcastChannel); ICE route повторно використовується для оптимістичних підказок ходів через DataChannel.
Залежить від: call:invite … call:hangup проходять через conversation:{id}.
Той самий процес: офлайновий банер ОС CALL_INVITE (FCM лише з data, TTL 90 с, RFC no-op у Chrome).
stunnerturn.ring-platform.org A/AAAA → IP вузла LB).WEBRTC_STUN_URL, WEBRTC_TURN_URL, WEBRTC_TURN_USERNAME, WEBRTC_TURN_CREDENTIAL.Для дзвінків потрібна активна сесія Tunnel. Якщо зв’язок реального часу втрачено, UI відмовляється починати дзвінок — спочатку виправте Tunnel (Протокол Tunnel).
features/chat/components/conversation-header.tsx | Дії Phone / Video (лише для прямих розмов) |
features/messages/components/messages-shell.tsx | З’єднує hook + overlay |
infrastructure/k3s-or/stunner/ | GatewayClass, GatewayConfig, маніфести Gateway |
k8s/ENV-PROD-WIRING.md | Таблиця production-змінних для WEBRTC_* |
GET /api/webrtc/ice-servers — потрібна сесія Auth.js (401, якщо користувач анонімний).
Форма відповіді (перевірено):
STUN використовує stun:stun.l.google.com:19302 як резерв, якщо WEBRTC_STUN_URL не задано. TURN додається лише тоді, коли задано всі WEBRTC_TURN_URL, WEBRTC_TURN_USERNAME і WEBRTC_TURN_CREDENTIAL.
| Змінна | Де | Примітки |
|---|---|---|
WEBRTC_STUN_URL | ConfigMap | Необов’язкова; у route є стандартний Google STUN |
WEBRTC_TURN_URL | ConfigMap | Наприклад, turn:turn.ring-platform.org:3478?transport=udp |
WEBRTC_TURN_USERNAME | Secret ring-platform-org-secrets | Відповідає Secret автентифікації STUNner |
WEBRTC_TURN_CREDENTIAL | Secret | Ніколи не використовуйте NEXT_PUBLIC_* |
Приклади: k8s/secrets.example.yaml, нотатки з підключення: k8s/ENV-PROD-WIRING.md.
env.local.template поки не містить цих ключів — для відповідності local/prod використовуйте приклади k8s.
Публікуються в каналі conversation:{conversationId} (тому самому каналі, що й typing):
| Подія | Призначення |
|---|---|
call:invite | Вихідний дзвінок |
call:accept / call:reject | Рішення адресата |
call:offer / call:answer | SDP |
call:ice | Кандидати ICE |
call:hangup | Завершення |
Підписуйтеся через useTunnelChannel — не підписуйтеся напряму в effects (Протокол Tunnel).
Встановіть оператор (він підтягує Gateway API + CRD STUNner):
Створіть Secret автентифікації (type=static, username, password) і застосуйте infrastructure/k3s-or/stunner/gateway.yaml (GatewayClass + GatewayConfig + Gateway з протоколом TURN-UDP).
Підключіть app Secret/ConfigMap і переконайтеся, що в Deployment є env-посилання на WEBRTC_TURN_USERNAME / WEBRTC_TURN_CREDENTIAL (k8s/deployment.yaml). Перезапустіть Deployment застосунку.
Smoke-тест: зовнішня STUN Binding на :3478; автентифікований GET /api/webrtc/ice-servers; два браузери в одній прямій розмові.
Протокол listener має бути TURN-UDP, а не простий UDP. Realm у GatewayConfig містить літери, цифри та дефіс (наприклад, ring-platform-org). Порожні backendRefs UDPRoute недійсні — peer TURN не потребує UDPRoute, доки не з’явиться SFU (LiveKit).
Стек Connect Platform RTVS / FastTransponder не портовано — використано лише шаблони UX керування (вимкнення звуку / камера / завершення).
Додатково: HTTP-контракти розмов і typing.
{
"success": true,
"data": {
"iceServers": [
{ "urls": "stun:…" },
{ "urls": "turn:…", "username": "…", "credential": "…" }
],
"turnConfigured": true
}
}stunnerturn.ring-platform.org A/AAAA → IP вузла LB).WEBRTC_STUN_URL, WEBRTC_TURN_URL, WEBRTC_TURN_USERNAME, WEBRTC_TURN_CREDENTIAL.Для дзвінків потрібна активна сесія Tunnel. Якщо зв’язок реального часу втрачено, UI відмовляється починати дзвінок — спочатку виправте Tunnel (Протокол Tunnel).
features/chat/components/conversation-header.tsx | Дії Phone / Video (лише для прямих розмов) |
features/messages/components/messages-shell.tsx | З’єднує hook + overlay |
infrastructure/k3s-or/stunner/ | GatewayClass, GatewayConfig, маніфести Gateway |
k8s/ENV-PROD-WIRING.md | Таблиця production-змінних для WEBRTC_* |
GET /api/webrtc/ice-servers — потрібна сесія Auth.js (401, якщо користувач анонімний).
Форма відповіді (перевірено):
STUN використовує stun:stun.l.google.com:19302 як резерв, якщо WEBRTC_STUN_URL не задано. TURN додається лише тоді, коли задано всі WEBRTC_TURN_URL, WEBRTC_TURN_USERNAME і WEBRTC_TURN_CREDENTIAL.
| Змінна | Де | Примітки |
|---|---|---|
WEBRTC_STUN_URL | ConfigMap | Необов’язкова; у route є стандартний Google STUN |
WEBRTC_TURN_URL | ConfigMap | Наприклад, turn:turn.ring-platform.org:3478?transport=udp |
WEBRTC_TURN_USERNAME | Secret ring-platform-org-secrets | Відповідає Secret автентифікації STUNner |
WEBRTC_TURN_CREDENTIAL | Secret | Ніколи не використовуйте NEXT_PUBLIC_* |
Приклади: k8s/secrets.example.yaml, нотатки з підключення: k8s/ENV-PROD-WIRING.md.
env.local.template поки не містить цих ключів — для відповідності local/prod використовуйте приклади k8s.
Публікуються в каналі conversation:{conversationId} (тому самому каналі, що й typing):
| Подія | Призначення |
|---|---|
call:invite | Вихідний дзвінок |
call:accept / call:reject | Рішення адресата |
call:offer / call:answer | SDP |
call:ice | Кандидати ICE |
call:hangup | Завершення |
Підписуйтеся через useTunnelChannel — не підписуйтеся напряму в effects (Протокол Tunnel).
Встановіть оператор (він підтягує Gateway API + CRD STUNner):
Створіть Secret автентифікації (type=static, username, password) і застосуйте infrastructure/k3s-or/stunner/gateway.yaml (GatewayClass + GatewayConfig + Gateway з протоколом TURN-UDP).
Підключіть app Secret/ConfigMap і переконайтеся, що в Deployment є env-посилання на WEBRTC_TURN_USERNAME / WEBRTC_TURN_CREDENTIAL (k8s/deployment.yaml). Перезапустіть Deployment застосунку.
Smoke-тест: зовнішня STUN Binding на :3478; автентифікований GET /api/webrtc/ice-servers; два браузери в одній прямій розмові.
Протокол listener має бути TURN-UDP, а не простий UDP. Realm у GatewayConfig містить літери, цифри та дефіс (наприклад, ring-platform-org). Порожні backendRefs UDPRoute недійсні — peer TURN не потребує UDPRoute, доки не з’явиться SFU (LiveKit).
Стек Connect Platform RTVS / FastTransponder не портовано — використано лише шаблони UX керування (вимкнення звуку / камера / завершення).
Додатково: HTTP-контракти розмов і typing.
{
"success": true,
"data": {
"iceServers": [
{ "urls": "stun:…" },
{ "urls": "turn:…", "username": "…", "credential": "…" }
],
"turnConfigured": true
}
}stunnerturn.ring-platform.org A/AAAA → IP вузла LB).WEBRTC_STUN_URL, WEBRTC_TURN_URL, WEBRTC_TURN_USERNAME, WEBRTC_TURN_CREDENTIAL.Для дзвінків потрібна активна сесія Tunnel. Якщо зв’язок реального часу втрачено, UI відмовляється починати дзвінок — спочатку виправте Tunnel (Протокол Tunnel).
features/chat/components/conversation-header.tsx | Дії Phone / Video (лише для прямих розмов) |
features/messages/components/messages-shell.tsx | З’єднує hook + overlay |
infrastructure/k3s-or/stunner/ | GatewayClass, GatewayConfig, маніфести Gateway |
k8s/ENV-PROD-WIRING.md | Таблиця production-змінних для WEBRTC_* |
GET /api/webrtc/ice-servers — потрібна сесія Auth.js (401, якщо користувач анонімний).
Форма відповіді (перевірено):
STUN використовує stun:stun.l.google.com:19302 як резерв, якщо WEBRTC_STUN_URL не задано. TURN додається лише тоді, коли задано всі WEBRTC_TURN_URL, WEBRTC_TURN_USERNAME і WEBRTC_TURN_CREDENTIAL.
| Змінна | Де | Примітки |
|---|---|---|
WEBRTC_STUN_URL | ConfigMap | Необов’язкова; у route є стандартний Google STUN |
WEBRTC_TURN_URL | ConfigMap | Наприклад, turn:turn.ring-platform.org:3478?transport=udp |
WEBRTC_TURN_USERNAME | Secret ring-platform-org-secrets | Відповідає Secret автентифікації STUNner |
WEBRTC_TURN_CREDENTIAL | Secret | Ніколи не використовуйте NEXT_PUBLIC_* |
Приклади: k8s/secrets.example.yaml, нотатки з підключення: k8s/ENV-PROD-WIRING.md.
env.local.template поки не містить цих ключів — для відповідності local/prod використовуйте приклади k8s.
Публікуються в каналі conversation:{conversationId} (тому самому каналі, що й typing):
| Подія | Призначення |
|---|---|
call:invite | Вихідний дзвінок |
call:accept / call:reject | Рішення адресата |
call:offer / call:answer | SDP |
call:ice | Кандидати ICE |
call:hangup | Завершення |
Підписуйтеся через useTunnelChannel — не підписуйтеся напряму в effects (Протокол Tunnel).
Встановіть оператор (він підтягує Gateway API + CRD STUNner):
Створіть Secret автентифікації (type=static, username, password) і застосуйте infrastructure/k3s-or/stunner/gateway.yaml (GatewayClass + GatewayConfig + Gateway з протоколом TURN-UDP).
Підключіть app Secret/ConfigMap і переконайтеся, що в Deployment є env-посилання на WEBRTC_TURN_USERNAME / WEBRTC_TURN_CREDENTIAL (k8s/deployment.yaml). Перезапустіть Deployment застосунку.
Smoke-тест: зовнішня STUN Binding на :3478; автентифікований GET /api/webrtc/ice-servers; два браузери в одній прямій розмові.
Протокол listener має бути TURN-UDP, а не простий UDP. Realm у GatewayConfig містить літери, цифри та дефіс (наприклад, ring-platform-org). Порожні backendRefs UDPRoute недійсні — peer TURN не потребує UDPRoute, доки не з’явиться SFU (LiveKit).
Стек Connect Platform RTVS / FastTransponder не портовано — використано лише шаблони UX керування (вимкнення звуку / камера / завершення).
Додатково: HTTP-контракти розмов і typing.
{
"success": true,
"data": {
"iceServers": [
{ "urls": "stun:…" },
{ "urls": "turn:…", "username": "…", "credential": "…" }
],
"turnConfigured": true
}
}