5-01 Типовая архитектура системы видеосвязи
В предыдущих лекциях мы изучили отдельные протоколы передачи мультимедиа: RTP, RTSP, WebRTC, SRT, HLS и другие. Теперь пришло время собрать эти элементы в единую систему — понять, как они работают вместе в реальных инфраструктурах видеосвязи. На этом слайде представлена типовая архитектура системы видеосвязи, которая объединяет разнородные устройства, протоколы и сервисы. Эта схема — не абстракция, а отражение реальных решений, используемых в корпоративных ВКС, телемедицине, онлайн-обучении и других сценариях.
Разберём её по частям: слева — клиентские устройства, в центре — серверная инфраструктура, справа — внешние системы. Каждый блок использует свой набор протоколов, и инженер должен уметь «читать» такую архитектуру, понимая, где и зачем применяется тот или иной протокол.
Клиентские устройства: начало и приём видеосвязи
Слева на схеме находятся клиентские устройства — точки, откуда пользователи инициируют или принимают видеозвонки. Они делятся на три основных типа:
- Аппаратные видеотерминалы — специализированные устройства (например, камеры с экраном от Cisco, Polycom, Huawei), устанавливаемые в переговорных.
- Софт-клиенты — программные приложения на компьютерах или мобильных устройствах (например, Zoom, Teams).
- Браузеры — веб-приложения, запускаемые прямо в браузере без установки дополнительного ПО (например, Google Meet, Jitsi).
Каждый тип использует разные протоколы, но все они решают одну задачу: установить двустороннюю видеосессию.
Протоколы для аппаратных терминалов и софт-клиентов: SIP, SDP, RTP
Аппаратные терминалы и софт-клиенты чаще всего работают в рамках SIP-архитектуры — стандарта, пришедшего из VoIP-телефонии и адаптированного для видеосвязи.
- SIP (Session Initiation Protocol) — протокол сигнализации. Он отвечает за установление, управление и завершение вызова.
- SDP (Session Description Protocol) — описывает параметры медиасессии: какие кодеки используются, на каких портах идёт аудио и видео, в каком направлении.
- RTP (Real-time Transport Protocol) — передаёт сами аудио- и видеоданные.
- RTCP (RTP Control Protocol) — сопровождает RTP, передавая статистику: потери пакетов, задержки, джиттер.
Эти протоколы работают в паре: SIP и SDP договариваются о сессии, а RTP/RTCP передают медиа.
Пример:
Когда вы нажимаете «Позвонить» в софт-клиенте, он отправляет SIP-запросINVITEс телом SDP, где указано: «Я могу принимать H.264 на порту 5004 по RTP». Ответная сторона отвечает200 OKсо своим SDP. После этого начинается обмен RTP-пакетами.
Браузеры не могут использовать SIP напрямую — они работают по другим правилам. Вместо этого применяется WebRTC.
Серверная инфраструктура: мозг системы видеосвязи
В центре архитектуры — серверы, управляющие сессиями и медиапотоками. Это «мозг» системы, без которого масштабная видеосвязь невозможна.
Сигналинговые серверы: управление вызовами
- SIP-сервер — принимает и маршрутизирует SIP-сообщения. Может быть частью IP-АТС (например, Asterisk, FreeSWITCH).
- WebRTC-сигналинговый сервер — не стандартизирован, но обычно реализуется на Node.js или Python с WebSocket. Передаёт SDP-описания и ICE-кандидаты между браузерами.
Медиасерверы: обработка и маршрутизация потоков
Медиасерверы работают с самими аудио- и видеопотоками. Два уже знакомых вам типа:
- MCU (Multipoint Control Unit), который принимает все входящие потоки, декодирует их, микширует (например, в сетку участников) и перекодирует в один выходной поток для каждого клиента.
- SFU (Selective Forwarding Unit), который не декодирует потоки, а пересылает RTP-пакеты от одних участников к другим.
Шлюзы: мосты между мирами
Шлюзы (gateways) преобразуют протоколы и форматы, чтобы разные системы могли взаимодействовать.
- SIP ↔ WebRTC-шлюз — позволяет браузеру участвовать в SIP-конференции.
- RTSP ↔ RTP-шлюз — принимает поток с IP-камеры и пересылает его в видеоконференцию.
- Транскодеры — меняют кодеки (например, H.264 ↔ VP8) или битрейт, чтобы обеспечить совместимость.
Пример:
IP-камера передаёт видео по RTSP/H.264. Через медиашлюз поток перепаковывается в SRTP и встраивается в WebRTC-сессию.
Внешние системы: стриминг и интеграция
Справа на схеме — внешние сервисы, с которыми система видеосвязи может взаимодействовать.
Стриминговые платформы: VK, CDN
Когда нужно не только провести конференцию, но и транслировать её в интернет. Для этого используются протоколы:
- RTMP (Real-Time Messaging Protocol) — старый, но надёжный стандарт для публикации стримов в YouTube, Twitch.
- SRT (Secure Reliable Transport) — современный, защищённый протокол для передачи по ненадёжным сетям (например, из поля).
- HLS (HTTP Live Streaming) — используется для доставки видео конечным зрителям через HTTP.
Как это работает:
Медиасервер (например, SFU) берёт один из входящих потоков, перекодирует его (если нужно) и отправляет на CDN через RTMP. Зрители смотрят через HLS.
IP-камеры: интеграция с видеонаблюдением
Системы видеосвязи часто интегрируются с IP-камерами, например, для трансляции с производственного участка или удалённого контроля.
- RTSP (Real-Time Streaming Protocol) — стандартный протокол для управления потоками с IP-камер (включить, остановить, выбрать поток).
- RTP — передаёт сам видеопоток после установки сессии.
Проблема:
IP-камеры не умеют WebRTC или SIP. Чтобы включить их в конференцию, нужен медиашлюз, который:
- Подключается к камере по RTSP.
- Принимает RTP-поток.
- Перепаковывает его в SRTP и отправляет в WebRTC-сессию.
Обобщённая таблица протоколов по зонам архитектуры
| Зона системы | Устройства/серверы | Основные протоколы | Назначение |
|---|---|---|---|
| Клиенты (аппаратные) | Видеотерминалы, софт-клиенты | SIP, SDP, RTP/RTCP | Установление вызова, передача медиа |
| Клиенты (браузеры) | Браузеры | WebRTC, SDP, ICE, STUN, TURN, SRTP, WebSocket | P2P-видеосвязь, обход NAT, шифрование |
| Сигналинг | SIP-сервер, WebRTC-сигналинг | SIP, WebSocket, HTTP | Управление сессией, обмен параметрами |
| Медиасерверы | MCU, SFU, шлюзы | RTP, SRTP, RTCP, транскодирование | Обработка, маршрутизация, микширование |
| Внешние стримы | CDN, YouTube, Twitch | RTMP, SRT, HLS | Публикация трансляций |
| IP-камеры | Камеры (ONVIF, RTSP) | RTSP, RTP | Приём видео с камер |
Зачем инженеру понимать такую архитектуру?
Потому что в реальной работе вы будете сталкиваться с гибридными системами, где:
- Браузерные пользователи звонят в SIP-конференцию.
- IP-камера транслируется в Zoom и одновременно в YouTube.
- Звук теряется, потому что кодеки не совпали.
- Видео не идёт, потому что NAT не пробит.
Чтобы диагностировать такие проблемы, нужно уметь:
- Читать архитектурные схемы — видеть, где какие протоколы используются.
- Понимать границы совместимости — например, что WebRTC не работает напрямую с RTSP.
- Выбирать правильные компоненты — нужен ли MCU или достаточно SFU, нужен ли шлюз.
- Анализировать логи и трафик — различать SIP-сообщения, SDP-описания, RTP-потоки.
Вывод
Типовая архитектура системы видеосвязи — это мозаика из протоколов и устройств, объединённых общей целью: обеспечить надёжную, интерактивную, безопасную передачу видео и звука. Каждый блок — от IP-камеры до CDN — использует свой набор технологий, и инженер должен уметь «читать» эту схему как карту. Понимание архитектуры — первый шаг к проектированию, интеграции и диагностике сложных видеосистем.