RTP (Real-time Transport Protocol, RFC 3550) несёт собственно голос или видео после того, как SIP согласует сессию, работая поверх UDP с компактным заголовком (порядковый номер, метка времени, SSRC). RTCP сообщает о качестве рядом с ним. SRTP (RFC 3711) добавляет к RTP шифрование и аутентификацию, с ключами через SDES в SDP или DTLS-SRTP.
RTP: перенос медиа
Как только SIP и SDP согласовали сессию, сами медиа текут поверх RTP — почти всегда поверх UDP, потому что аудио реального времени предпочитает своевременную доставку гарантированной. Каждый пакет RTP несёт фрагмент закодированного аудио (кадр кодека, такой как 20 мс G.711) за 12-байтовым заголовком. RTP — это поток, отдельный от сигнализации SIP, на портах, согласованных в SDP, и обычно течёт напрямую между конечными точками или через медиарелей, а не следует тракту сигнализации.
Заголовок RTP
12-байтовый заголовок RTP даёт получателю всё необходимое для восстановления потока реального времени. Порядковый номер обнаруживает потери и переупорядочивание. Метка времени отражает момент дискретизации, чтобы получатель мог воспроизводить аудио в правильном темпе и убирать джиттер буфером джиттера. SSRC уникально идентифицирует источник медиа в сессии. Тип полезной нагрузки повторяет кодек, согласованный в SDP. Бит-маркер отмечает события, такие как первый пакет после периода тишины.
| Поле | Размер | Назначение |
|---|---|---|
| V / P / X / CC | 1 байт | Флаги версии, заполнения, расширения, количества CSRC |
| M (маркер) + PT | 1 байт | Маркерный бит + тип полезной нагрузки (кодек из SDP) |
| Порядковый номер | 2 байта | Обнаружение потери и переупорядочивания пакетов |
| Временная метка | 4 байта | Момент выборки; управляет воспроизведением / джиттер-буфером |
| SSRC | 4 байта | Источник синхронизации — идентифицирует поток |
| CSRC (0–15) | 0–60 байт | Участвующие источники (от микшеров) |
RTCP: обратная связь о качестве
RTP путешествует с сопутствующим управляющим протоколом RTCP на смежном (нечётном) порту. RTCP не несёт медиа; вместо этого каждая сторона периодически отправляет Sender Report и Receiver Report, описывающие состояние потока — отправленные и потерянные пакеты, накопленные потери, джиттер прихода и время кругового обхода, выведенное из меток времени отчётов. Эти метрики — сырьё для оценок MOS и для диагностики одностороннего звука, джиттера и потерь в вызове VoIP. RTCP также несёт описание источника (CNAME) и BYE для завершения потока.
| Метрика | Что это вам говорит |
|---|---|
| Потеря пакетов (доля + суммарная) | Какая доля аудио теряется |
| Межпакетный джиттер | Разброс времени поступления пакетов — трудности воспроизведения |
| Время кругового пути | Задержка пути (на основе временных меток SR/RR) |
| Наивысшая полученная последовательность | Обнаружение хода передачи и потерь по каждому источнику |
SRTP: шифрование медиа
Обычный RTP не зашифрован, поэтому любой на пути может захватить и воспроизвести аудио. SRTP (RFC 3711) защищает его: он шифрует полезную нагрузку RTP (по умолчанию AES в режиме счётчика) и добавляет тег аутентификации (по умолчанию HMAC-SHA1), защищающий целостность и обеспечивающий защиту от повтора, оставляя заголовок RTP читаемым, чтобы маршрутизаторы и буферы джиттера по-прежнему работали. В SDP транспорт отображается как RTP/SAVP вместо RTP/AVP. SRTP защищает конфиденциальность и целостность, но полностью зависит от того, как обмениваются его ключами.
Ключи SRTP: SDES против DTLS-SRTP
SRTP нужен мастер-ключ на каждом конце, и два распространённых способа его доставки резко различаются по безопасности. SDES (RFC 4568) помещает ключ в строку a=crypto в SDP — просто, но лишь настолько безопасно, насколько защищена сигнализация SIP, поэтому её нужно нести поверх TLS, иначе ключ раскрыт. DTLS-SRTP (RFC 5763/5764) вместо этого выполняет рукопожатие DTLS в медиатракте для вывода ключей, поэтому ключ никогда не появляется в сигнализации; это модель, которую предписывает WebRTC. Выбирайте DTLS-SRTP там, где конечные точки его поддерживают, и всегда защищайте SDES с помощью SIP поверх TLS.
| Метод | RFC | Где хранится ключ | Примечание |
|---|---|---|---|
| SDES | RFC 4568 | a=crypto строка в SDP | Для обеспечения безопасности требуется SIP поверх TLS |
| DTLS-SRTP | RFC 5763/5764 | Выводится в ходе рукопожатия DTLS в медиатракте | Ключ никогда не передаётся в сигнализации; используется WebRTC |
| MIKEY | RFC 3830 | Полезная нагрузка для управления ключами | Используется в некоторых развертываниях IMS |
Часто задаваемые вопросы
В чём разница между SIP и RTP?
SIP — это сигнализация, устанавливающая, изменяющая и завершающая вызов; RTP — это транспорт медиа, несущий собственно голос или видео после установления вызова. Они работают как отдельные потоки на отдельных портах — SIP согласует сессию, RTP её доставляет.
Почему RTP работает поверх UDP, а не TCP?
Аудио реального времени ценит своевременность выше надёжности. Повторная передача и блокировка в начале очереди TCP добавили бы задержку и джиттер, вредящие живому вызову больше, чем случайный потерянный пакет. RTP поверх UDP позволяет получателю скрывать малые потери, сохраняя поток вовремя.
Что делает RTCP?
RTCP — это сопутствующий управляющий канал RTP. Он не несёт медиа; он периодически сообщает о качестве потока — потери пакетов, джиттер и время кругового обхода через Sender и Receiver Report — что используется для оценки качества вызова (MOS) и диагностики проблем вроде одностороннего звука.
Что такое SRTP?
SRTP (RFC 3711) — это защищённый профиль RTP. Он шифрует полезную нагрузку медиа (обычно AES в режиме счётчика) и аутентифицирует каждый пакет (обычно HMAC-SHA1) с защитой от повтора, сохраняя заголовок RTP в открытом виде. В SDP он появляется как транспорт RTP/SAVP.
В чём разница между SDES и DTLS-SRTP?
Оба задают ключи SRTP. SDES несёт ключ в строке a=crypto SDP, поэтому он безопасен, только если сама сигнализация SIP защищена TLS. DTLS-SRTP выводит ключи через рукопожатие DTLS в медиатракте, поэтому ключ никогда не касается сигнализации — подход, который требует WebRTC.
Технические характеристики источника
На этой странице представлены опубликованные стандарты, на которых они основаны. (Открывается в новой вкладке)