WebRTC, технология голосовых и видеозвонков в браузерах (а еще realtime передачи произвольных данных, peer-to-peer пробивания NAT и захвата экрана) никогда не была простой. Долгая история, несовместимости между браузерами, запутанная документация, множество решаемых задач и используемых протоколов. Возможность позвонить и принять звонок из браузера всегда была одной из ключевых «фишек» нашей платформы Voximplant, и так как мы в этом неплохо разбираемся, то стараемся следить за интересными статьями и адаптировать их для аудитории Хабра. Под катом перевод свежей статьи от ребят из callstats.io — сервиса сбора статистики по качеству звонков для браузера. В небольшой статье они рассказывают о протоколе RTP с помощью которого, собственно, браузер и передает пакеты с голосом или видео.
WebRTC использует протокол SRTP (Secure Real-time Transport Protocol), чтобы обеспечить шифрование, аутентификацию и целостность сообщений, а также защитить RTP-данные от атак повторного воспроизведения. Это система безопасности, которая дает конфиденциальность за счет шифрования RTP-нагрузки и проверки подлинности. Эти фишки безопасности в WebRTC – ключевой момент надежности и основа для всего, что касается RTP (Real-time Transport Protocol). Но что такое RTP, как оно работает?
RTP это сетевой протокол, спроектированный для мультимедийных коммуникаций (VoIP, видеоконференции, телепрезентации), потоковой передачи мультимедиа (видео по запросу, прямые трансляции) и широковещательное медиа. Протокол был определен организацией IETF (Internet Engineering Task Force) в стандарте RFC1889. Изначально RTP создали для поддержки видеоконференций, в которых есть географически распределенные участники, разработку вела рабочая группа IETF по аудио- и видеотранспорту. На текущий момент, версия v2 из стандарта RFC3550 используется уже 15 лет!
В основе RTP лежат фундаментальные принципы формирования фреймов на уровне приложения и их обработки на уровне протокола. RTP описывает типы медиа данных и «полезной нагрузки» пакетов, механизм синхронизации медиапотоков, объясняет что делать с потерянными и перепутанными пакетами, как отслеживать состояние передаваемых медиаданных.
Для получения информации о качестве медиапотока внутри RTP используется «вложенный» протокол RTCP (RTP Control Protocol).
При использовании RTP отправляющая сторона упаковывает медиапоток в формат RTP пакетов и время от времени отсылает "RTCP Sender Report" для синхронизации медиапотоков между собой. Принимающая сторона организует "Jitter buffer" для сбор получаемых пакетов в правильном порядке и воспроизведения медиапотока в соответствии с информацией о таймингах, указанной в полученных пакетах. Если пакет теряется, то получающая сторона по возможности получает его еще раз или же “скрывает” проблему, интерполируя звук или разбивая видео на цветные квадратики. И, наконец, принимающая сторона передает в обратную сторону грубую или детальную статистику с помощью “RTCP Receiver Report”. Статистика позволяет отправителю выбирать битрейт, менять кодеки и выбирать объем коррекции ошибок.
Заголовок RTP пакета разделен на 4 части: источник синхронизации, метка времени, порядковый номер и тип полезной нагрузки.
1. Источник синхронизации. Позволяет определить, откуда идет медиапоток. Особенно полезно, когда источник отсылает несколько медиапотоков, которые надо синхронизировать.
2. RTP метка времени позволяет собирать из RTP пакетов медиа фреймы и воспроизводить медиапоток.
3. RTP порядковый номер: он и в африке порядковый номер, с его помощью находятся потерянные пакеты, а те что не потеряны — выстраиваются по порядку. UDP все-таки.
4. Тип полезной нагрузки определяет кодировку медиа данных в пакетах, его указывает кодек.
Известные в спецификации как «RTCP Reports», бывают трех типов: «Sender Reports» для отправителя, «Receiver Reports» для получателя и «Extended Reports» для всех участников процесса.
RTCP Sender Reports
Используются отправляющей стороной для синхронизации медиапотоков. Метки времени всех отправляемых потоков устанавливаются относительно часов этого компьютера, так что принимающая сторона понимает как потоки нужно воспроизводить друг относительно друга. В этом же отчете указывается количество отправляемых в секунду пакетов и байт.
RTCP Receiver Reports
Принимающая сторона осматривает получаемые потоки и отчитывается о происходящем с помощью пакетов «RTCP Receiver Report». В отчете указывается текущий уровень потерь пакетов, джиттер (буфер, в котором хранятся пакеты перед проигрыванием, чтобы подождать опоздавших и поменять местами запутавшихся), максимальный порядковый номер. Часть этих данных используется для расчета round trip time.
RTCP Extended Reports
Используются как отправляющей, так и принимающей стороной для передачи сложных метрик о происходящем между ними. К таким метрикам относится производительность самих компьютеров, состояние сети, джиттер буфера, вариации в задержках пакетов, просто информация о задержках, количество не обработанных пакетов, QoS и другие. Также в этот пакет можно добавлять собственные метрики, так что обе стороны могут отслеживать специфичные для приложения параметры.
«Формат полезной нагрузки», payload format, задается такой штукой, которая в спецификации называется «кодированием», encoding. Непереводимая на русский игра слов описыват три варианта. Это может быть кодек, например H.264, H.263, H.261, MPEG-2, JPEG, G.711, G.722 или AMR. Это может быть «полезная нагрузка общего назначения», такая как «Forward Error Correction» (FEC), NACK и другие страшные акронимы. И, наконец, это могут быть мультиплексированные медиапотоки (несколько медиапотоков в рамках одного).
Спецификация жестко задает формат для кодеков и определяет два правила: агрегации и фрагментации. Правила агрегации описывают, как RTP работает с кодеками, которые производят пакеты меньше MTU — например, звуковыми кодеками. Правила фрагментации, наоборот, описывают работу с кодеками, предпочитающими большие пакеты, например пакеты с I-фреймами видеокодирования. RTP задает собственное фрагментирование, потому что IP фрагментирование для UDP как правило не работает, и NAT'ы с Firewall'ами просто молча дропают такие пакеты.
«Расширения» заголовков пакетов используются для информации, не имеющей отношения к медиапотокам. Обычно это та информация, которую нужно передавать в реальном времени — чаще, чем отсылаются RTCP отчеты.
Например, для интерактивных медиапотоков (видеочат?) RTP пакеты отправляются каждые несколько десятков миллисекунд. Расширение к RTP заголовкам может использоваться для индикации потерянных и полученных пакетов — чтобы реагировать быстрее, чем это позволяют получаемые время от времени RTCP отчеты с NACK/ACK.
Расширение заголовков обратно совместимо: если один из участников передачи данных не понимает этот формат, то он будет просто игнорировать соответствующую часть заголовка пакета. Заголовки описаны в спецификации как штука «общего назначения» и их не нужно отдельно указывать для каждого используемого кодека.
Они часто используются для передачи состояния сети и таких специфичных для приложения штук как громкость звука для нескольких каналов в конференции.
Использование протокола RTP выглядит как замкнутый цикл: мы отправляем RTP пакеты и получаем RTCP пакеты с обратной связью. Почти как TCP с его ACK. Обычно отчетный интервал выбирается так, чтобы объем передаваемых пакетов RTCP был гораздо меньше, чем объем передаваемых медиаданных. Выбор происходит на основании количества потоков, которые нужно синхронизировать, и ширины канала.
Теоретически, ширина канала должна равномерно делиться по участникам (аудио или видео конференции). На практике приложения рассчитывают ширину исходя из предполагаемого количества одновременно активных участников. Например, для аудиоконференции это обычно один участник: если несколько людей начнут говорить одновременно, то никто ничего не поймет. А вот для видеоконференции все сложнее: показывать видео с нескольких участников это вполне популярный сценарий. В таких ситуациях отчетный интервал рассчитывается индивидуально для каждого участника.
5% ширины канала выделяется для RTCP пакетов.
Для сценариев с большим количеством принимающих устройств и малым количеством отправляющих устройств (вебинар, голосовая конференция) четверть канала для отчетов равномерно распределяется для передающих устройств, а оставшиеся три четверти для принимающих. Такое распределение позволяет новым подключившимся устройствам быстро получить CNAME и метки времени для синхронизации. А чтобы новые подключившиеся устройства могли быстро передать информацию о себе, интервал отправки RTCP пакетов для них выбирается в два раза меньше, чем для остальных участников.
Рекомендованный минимальный интервал отправки RTCP пакетов составляет 5 секунд.
Это значение может быть уменьшено до 360 / ширина канала (в секундах) для ситуаций, когда данные передаются в обе стороны и нужно быстро передавать дополнительную информацию для управления потерями пакетов.
Если клиент замечает потери пакетов или проблемы с сетью, то он не может сразу отослать RTCP пакет и должен подождать окончания интервала. А там, на секундочку, 5 секунд. Для решения вопроса в спецификации есть «Extended RTP Profile for RTCP-Based Feedback» — это расширение правил RTP о таймингах.
Если оба устройства поддерживают такой профиль, то они могут договориться отсылать RTCP пакеты чаще, чем положено по спецификации. До тех пор, пока средняя скорость отправки пакетов укладывается в специфицированный интервал. Это же расширение описывает несколько дополнительных сообщений, которые клиенты могут использовать для описания происходящего с медиаданными: Negative Acknowledgement (NACK), Picture Loss Indication (PLI), Slice Loss Indication (SLI) и Reference Picture Selection Indication (RPSI).
Комментариев нет:
Отправить комментарий