Протоколы видеосвязи: архитектура и принципы работы
Видеосвязь — это не просто передача видео по сети, как при обычном стриминге. Это интерактивный процесс, требующий двустороннего обмена данными, согласования параметров между участниками и защиты канала связи. В отличие от односторонней трансляции, где достаточно отправить поток с камеры на сервер, видеосвязь предполагает, что оба участника могут видеть и слышать друг друга в реальном времени, управлять вызовом (например, завершить или поставить на удержание), а также адаптироваться к изменяющимся условиям сети.
Для обеспечения такой сложной функциональности невозможно обойтись одним протоколом. Вместо этого используется стек взаимодействующих протоколов, каждый из которых решает свою конкретную задачу. Ниже мы подробно разберём структуру этого стека, назначение каждого уровня и принципы их совместной работы.
Архитектура стека протоколов видеосвязи
Видеосвязь строится по слоистому принципу — каждый уровень отвечает за свою часть процесса. Ниже представлена полная структура стека, от базовой передачи данных до защиты и управления сессией.
+-------------------------+
| Сигналинг (SIP, |
| WebRTC, проприетарный) | ← Установление сессии, согласование параметров
+-------------------------+
| Описание сессии (SDP) | ← Что передаём: кодеки, порты, направления
+-------------------------+
| Медиатранспорт |
| (RTP, RTCP, SRTP) | ← Передача аудио/видео, контроль качества
+-------------------------+
| Вспомогательные протоколы|
| (STUN, TURN, ICE, TLS) | ← Обход NAT, шифрование, выбор маршрута
+-------------------------+
| Транспорт (UDP/TCP) | ← Передача пакетов
+-------------------------+
| Сетевой (IP) | ← Адресация и маршрутизация
+-------------------------+
Рассмотрим каждый уровень подробно.
Нижние уровни: IP, UDP и TCP
На самом низком уровне видеосвязь использует те же протоколы, что и любое сетевое взаимодействие:
- IP (Internet Protocol) — отвечает за адресацию и маршрутизацию пакетов. Каждое устройство в сети имеет IP-адрес, по которому его можно найти.
- UDP (User Datagram Protocol) — протокол передачи данных без установления соединения. Быстрый, но не гарантирует доставку. Используется для медиапотоков, где важна скорость, а потеря отдельных пакетов допустима.
- TCP (Transmission Control Protocol) — надёжный протокол с установлением соединения. Гарантирует доставку, но медленнее. Чаще используется для сигналинга, где важна целостность данных.
🔍 Почему UDP для медиа?
В видео- и аудиопотоках потеря одного кадра или фрейма аудио не критична — система может скомпенсировать это интерполяцией. Зато задержки из-за повторной передачи (как в TCP) недопустимы. Поэтому RTP-потоки почти всегда идут по UDP.
Уровень медиатранспорта: RTP, RTCP и SRTP
На этом уровне происходит передача самого аудио и видео.
RTP (Real-time Transport Protocol)
RTP — основной протокол для передачи медиаданных в реальном времени. Он добавляет к пакетам информацию, необходимую для правильного воспроизведения:
- Порядковый номер пакета — чтобы восстановить правильную последовательность.
- Метка времени — для синхронизации аудио и видео.
- Идентификатор потока (SSRC) — чтобы различать несколько источников в одной сессии.
🎥 Визуализация:
Представьте, что вы отправляете кадры видео по почте. RTP — это конверт, на котором указано:
- Номер кадра (1, 2, 3...)
- Время, когда он должен быть показан
- Кто его отправил (камера, микрофон)
Это позволяет получателю правильно собрать видео, даже если письма пришли не по порядку.
RTCP (RTP Control Protocol)
RTCP работает параллельно с RTP и отвечает за мониторинг качества соединения. Участники периодически обмениваются отчётами, содержащими:
- Количество потерянных пакетов
- Время задержки (jitter)
- Скорость приёма/передачи
Эти данные позволяют адаптировать качество видео (например, понизить битрейт при ухудшении сети).
SRTP (Secure Real-time Transport Protocol)
SRTP — защищённая версия RTP. Он шифрует полезную нагрузку (аудио и видео), чтобы никто посторонний не мог перехватить и прослушать разговор.
- Использует симметричное шифрование (например, AES).
- Ключи обмениваются безопасно на этапе установления сессии (через DTLS-SRTP в WebRTC или SDES в SIP).
- Шифруется не весь пакет, а только данные — заголовки остаются открытыми для маршрутизации.
🔐 Пример безопасности:
Даже если злоумышленник перехватит RTP-пакеты, при использовании SRTP он увидит только зашифрованные данные. Расшифровать их можно только при наличии ключа, который никогда не передаётся открыто.
Уровень сигналинга: установление сессии
Сигналинг — это «диалог» между участниками перед началом передачи медиа. Без него устройства не знают:
- Кто с кем хочет соединиться?
- Какие кодеки поддерживает каждый?
- По какому IP-адресу и порту принимать видео?
- В каком направлении идут потоки (только отправка, только приём, оба)?
Основные задачи сигналинга
- Поиск и идентификация участников — например, по SIP-адресу
alice@company.com. - Установление и завершение вызова — команды «позвонить», «сбросить», «удержание».
- Согласование параметров — выбор общих кодеков, разрешений, битрейтов.
- Передача сетевых параметров — IP-адреса, порты, транспорт (UDP/TCP).
- Управление сессией — добавление участников, перенаправление вызова.
Примеры реализаций сигналинга
- SIP (Session Initiation Protocol) — стандартный протокол, пришедший из VoIP-телефонии. Используется в корпоративных системах видеоконференцсвязи (Cisco, Avaya).
- WebRTC сигналинг — не стандартизирован; разработчик сам выбирает способ обмена данными (например, через WebSocket или HTTP).
- Проприетарные API — как в Skype, Zoom или Telegram.
⚠️ Важно:
Сигналинг не передаёт медиаданные. Он только договаривается о правилах их передачи. Само видео и аудио идут по RTP/RTCP.
Описание сессии: SDP (Session Description Protocol)
SDP — это текстовый формат описания параметров мультимедийной сессии. Он передаётся внутри сигналинговых сообщений (например, в теле SIP-INVITE или WebRTC-offer).
Пример SDP
v=0
o=- 1234567890 2 IN IP4 192.168.1.100
s=Video call
c=IN IP4 192.168.1.100
t=0 0
m=audio 5004 RTP/AVP 0 8 111
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 opus/48000/2
m=video 5006 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e01f
a=sendrecv
Расшифровка ключевых строк
| Строка | Значение |
|---|---|
v=0 | Версия протокола SDP |
o= | Идентификатор владельца сессии |
c= | IP-адрес для медиапотоков |
m=audio | Медиалиния: аудио на порту 5004 |
m=video | Медиалиния: видео на порту 5006 |
a=rtpmap | Сопоставление кодека с числовым идентификатором (PT) |
a=fmtp | Дополнительные параметры кодека (например, профиль H.264) |
a=sendrecv | Направление: и отправка, и приём |
🛠️ Для инженера:
SDP — это «паспорт вызова». Умение читать SDP позволяет быстро находить причины проблем: например, если один участник предлагает H.264, а другой — VP8, и общий кодек не найден, видео не будет работать.
Вспомогательные протоколы: обход NAT и выбор маршрута
В реальных сетях устройства часто находятся за NAT (маршрутизаторами), что мешает прямому P2P-соединению. Для решения этой проблемы используются специальные протоколы.
STUN (Session Traversal Utilities for NAT)
STUN помогает устройству узнать свой внешний IP-адрес и порт, за NAT.
- Клиент отправляет запрос на STUN-сервер в интернете.
- Сервер отвечает: «Вы видны снаружи как
203.0.113.45:54321». - Эта информация используется для установления прямого соединения.
🧭 Аналогия:
Как если бы вы находитесь в здании и не знаете, как вас видят снаружи. Вы звоните другу снаружи, и он говорит: «Ты входишь через дверь №3, слева от вывески».
TURN (Traversal Using Relays around NAT)
TURN используется, когда прямое соединение невозможно (например, при симметричном NAT). В этом случае трафик ретранслируется через сервер.
- Устройства обмениваются данными не напрямую, а через TURN-сервер.
- Это создаёт нагрузку на сервер и увеличивает задержку, но гарантирует соединение.
⚠️ Когда применяется:
TURN — «план Б». Он работает всегда, но менее эффективен. Используется, когда STUN не помог.
ICE (Interactive Connectivity Establishment)
ICE — это алгоритм выбора наилучшего пути связи. Он объединяет STUN и TURN:
- Устройство собирает все возможные адреса (локальный IP, внешний IP от STUN, TURN-реле).
- Эти адреса называются ICE-кандидатами.
- Устройства обмениваются кандидатами через сигналинг.
- ICE пробует соединиться по всем возможным парам кандидатов.
- Выбирается самый быстрый и стабильный путь.
🔄 Пример:
Устройство A собирает три кандидата:
192.168.1.10:5000(локальный)203.0.113.45:54321(через STUN)198.51.100.1:3478(через TURN)
То же делает устройство B.
ICE проверяет все комбинации (9 вариантов) и выбирает, например,STUN → STUN, если соединение работает.
Безопасность: шифрование сигналинга и медиа
Безопасность в видеосвязи обеспечивается на двух уровнях.
Шифрование сигналинга
- TLS (Transport Layer Security) — используется для шифрования сигналинговых сообщений (например, SIP over TLS).
- Предотвращает перехват данных о вызове: кто кому звонит, какие кодеки используются.
Шифрование медиаданных
- SRTP — как описано выше, шифрует аудио и видео.
- ZRTP — альтернатива SRTP, где ключи согласуются прямо в медиапотоке (используется в некоторых безопасных системах).
- В WebRTC используется DTLS-SRTP — ключи генерируются через DTLS-рукопожатие, а затем применяются к SRTP.
🔐 Уровни защиты:
- TLS защищает «диалог о звонке»
- SRTP защищает «сам разговор»
Вместе они обеспечивают сквозное шифрование.
Итог: видеосвязь как система взаимодействующих протоколов
Видеосвязь — это не отдельный протокол, а сложная система, где каждый компонент выполняет свою роль:
- IP/UDP/TCP — доставляют пакеты.
- RTP/RTCP — передают и контролируют качество аудио и видео.
- SRTP — шифрует медиапоток.
- Сигналинг (SIP/WebRTC) — устанавливает сессию и согласует параметры.
- SDP — описывает, что и как передаётся.
- STUN/TURN/ICE — решают проблему NAT и выбирают путь.
- TLS — шифрует сигналинг.
Совместная работа всех этих протоколов обеспечивает стабильный, безопасный и интерактивный видеозвонок.