RTP: как по сети передаются аудио и видео в реальном времени

RTP, Real-time Transport Protocol, предназначен для передачи потоков, которым важно время: голоса в звонках, видео в конференциях, вещания. У такого трафика особые требования. Данные бесполезны, если опоздали: слово, пришедшее с задержкой в секунду, уже не нужно, поэтому ждать повтора потерянного пакета бессмысленно. Значит, надёжность TCP здесь вредна, и RTP обычно ходит поверх UDP.

Сам протокол не обеспечивает доставку и не управляет задержкой. Он добавляет к пакету служебные сведения, которые позволяют получателю разобраться с тем, что пришло, и восстановить правильный порядок и ритм воспроизведения.

В заголовок RTP входят несколько ключевых полей. Порядковый номер растёт с каждым пакетом, и по нему получатель замечает потери и перестановки. Временная метка отражает момент, когда был снят кадр или отсчёт звука, и по ней воспроизведение восстанавливает исходный ритм, а также синхронизирует звук с картинкой. Тип нагрузки сообщает, каким кодеком закодированы данные. Идентификатор источника, SSRC, различает отдельные потоки в одном сеансе.

Благодаря такой структуре разные потоки, например аудио и видео, идут отдельными последовательностями пакетов, а сопоставляются на приёмной стороне по временным меткам.

Примечательно и то, что порядковый номер не сообщает о времени: две последовательные метки могут отличаться не на фиксированный интервал, если звук временно не передавался, например во время пауз в разговоре. Поэтому для восстановления ритма используют именно временную метку, а порядковый номер нужен только для обнаружения потерь и перестановок.

Пакеты приходят неравномерно: одни быстрее, другие медленнее. Чтобы воспроизведение не дёргалось, получатель накапливает небольшой запас в джиттер-буфере, из которого читает пакеты по метке времени. Размер буфера — компромисс: больше буфер сглаживает больше, но добавляет задержку, а слишком маленький допускает потери звука.

Вместе с RTP работает управляющий протокол RTCP. Он не переносит данные, а передаёт отчёты: сколько пакетов получено, сколько потеряно, каков джиттер. Отправитель, узнав из отчётов, что сеть перегружена, может снизить битрейт или сменить кодек. Обычно RTCP использует соседний порт и занимает небольшую долю полосы.

Для RTP отводится диапазон динамических UDP-портов, который задаётся в настройках телефонов и серверов. Порты выбираются в момент установления сеанса и сообщаются собеседнику через сигнализацию, например SIP. На маршрутизаторах с трансляцией адресов такие потоки нередко вызывают проблемы: односторонний звук, тишина. Причины и лекарства описаны на страницах про SIP и NAT.

Сам RTP не шифрует данные. Для защиты применяют SRTP, вариант с шифрованием и проверкой целостности. В браузерных звонках WebRTC использование SRTP обязательно, ключи согласуются через DTLS. Поэтому голос в конференциях в браузере передаётся защищённым, даже если пользователь ничего не включал.

В конференциях с несколькими участниками применяют медиасерверы, которые принимают потоки RTP и перераспределяют их. Для экономии полосы сервер может отправлять получателям одновременно несколько версий видео разного качества и выбирать подходящую под канал каждого. Этот приём называют симулькастом, и он опирается именно на идентификаторы потоков в заголовке.

Первое: RTP сам обеспечивает качество связи. Он только помечает данные, а качество определяется каналом, кодеком и буфером. Второе: потерянный пакет всегда воспроизводится повторно. При работе поверх UDP повторов нет, вместо них применяют маскировку потерь и упреждающую коррекцию. Третье: RTP используется только в телефонии. Он же везёт видео в конференциях и ряд видов вещания.

Увидеть потоки можно в анализаторе пакетов Wireshark: у него есть отдельный раздел телефонии со списком потоков RTP, где отображаются потери и джиттер. В самом браузере статистику звонка WebRTC можно посмотреть на служебной странице chrome://webrtc-internals в браузерах на основе Chromium: там видны число потерянных пакетов и задержка.