RTP (Real-time Transport Protocol) это сетевой протокол, по которому идут звук и видео в реальном времени: звонки IP-телефонии, видеоконференции, звонки из браузера, картинка с IP-камер. Он описан в RFC 3550, обычно работает поверх UDP и делает три вещи: нумерует пакеты, ставит на них метки времени и сообщает, каким кодеком сжаты данные.
Доставку RTP не гарантирует, а постоянного порта у него нет: номер выбирают стороны при установке звонка. Где протокол стоит среди TCP, UDP, HTTP и остальных, разобрано в статье про сетевые протоколы простыми словами.
Сокращение RTP встречается и в других областях, здесь речь только о сетевом протоколе.
CheckroiПодборка курсов по сетевым технологиям29 курсов • 16 школСравните цены, школы, программу и найдите выгодные предложения по обучениюСравнить→
Что такое RTP простыми словами
Представьте разговор по рации, где каждую фразу режут на кусочки по 20 миллисекунд и отправляют отдельными конвертами. Конверты едут разными путями, приходят не по порядку, некоторые теряются. На каждом конверте RTP пишет номер, время записи и пометку «внутри голос в таком-то формате». Получатель раскладывает кусочки по порядку и проигрывает их ровно с тем темпом, с каким их записали.
Отправить потерянный кусочек ещё раз RTP не пытается. Для живого разговора опоздавший звук бесполезен: лучше короткий пропуск, чем пауза в полсекунды. Поэтому протокол обычно едет поверх UDP, а не TCP.
Где вы встречаете RTP, даже не зная о нём:
- IP-телефония: звонок договаривается по SIP, а голос идёт по RTP. Про сами сервисы рассказываем в обзоре облачной IP-телефонии для бизнеса;
- звонки в браузере (WebRTC): видеосвязь без установки программ;
- видеонаблюдение: камера отдаёт поток по RTSP, а сами кадры идут по RTP;
- IPTV в локальных сетях: один поток рассылается многим получателям (multicast).
Чего RTP не делает, записано в аннотации RFC 3550:
RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. (RFC 3550)
То есть полосу в сети RTP не бронирует и качество связи не обещает. Он даёт получателю данные, чтобы заметить потери и собрать поток обратно, а бороться с потерями приходится приложению и сети.
Как устроен RTP-пакет
У каждого пакета есть заголовок и полезная нагрузка, то есть кусок сжатого звука или видео. Первые 12 байт заголовка есть в любом RTP-пакете, это закреплено в разделе 5.1 RFC 3550.
| Поле | Размер | Что в нём |
|---|---|---|
| V (version) | 2 бита | версия протокола, сейчас 2 |
| P (padding) | 1 бит | есть ли в конце пакета байты-заполнители |
| X (extension) | 1 бит | есть ли расширение заголовка |
| CC (CSRC count) | 4 бита | сколько идентификаторов CSRC идёт после заголовка, от 0 до 15 |
| M (marker) | 1 бит | отметка важного события, например конца видеокадра |
| PT (payload type) | 7 бит | тип полезной нагрузки, по нему понятно, какой кодек внутри |
| Sequence number | 16 бит | порядковый номер пакета, растёт на 1 |
| Timestamp | 32 бита | метка времени первого отсчёта в пакете |
| SSRC | 32 бита | идентификатор источника потока |
| CSRC | по 32 бита | список источников, если поток собран микшером из нескольких голосов |
Номер и метка времени начинаются не с нуля. RFC 3550 рекомендует брать начальные значения случайными, чтобы шифрованный поток было труднее вскрыть по известному началу.
Разбор заголовка на Python
Проще всего понять заголовок, если собрать пакет самому и разобрать его обратно. Скрипт ниже на Python кладёт в пакет 20 мс звука в G.711 и читает 12 байт заголовка модулем struct:
import struct
def build_rtp(seq, ts, ssrc, pt=0, marker=0, payload=b""):
b0 = 2 << 6 # V=2, P=0, X=0, CC=0
b1 = (marker << 7) | pt
return struct.pack("!BBHII", b0, b1, seq, ts, ssrc) + payload
def parse_rtp(pkt):
b0, b1, seq, ts, ssrc = struct.unpack("!BBHII", pkt[:12])
return {
"version": b0 >> 6,
"padding": (b0 >> 5) & 1,
"extension": (b0 >> 4) & 1,
"csrc_count": b0 & 0x0F,
"marker": b1 >> 7,
"payload_type": b1 & 0x7F,
"seq": seq,
"timestamp": ts,
"ssrc": hex(ssrc),
"payload_bytes": len(pkt) - 12,
}
# 20 мс звука G.711 (PCMU): 8000 отсчётов в секунду × 0,02 с = 160 байт
pkt = build_rtp(seq=4711, ts=160000, ssrc=0x1A2B3C4D, pt=0, payload=bytes(160))
print(len(pkt), "байт в пакете")
print(parse_rtp(pkt))Вывод:
172 байт в пакете
{'version': 2, 'padding': 0, 'extension': 0, 'csrc_count': 0, 'marker': 0, 'payload_type': 0, 'seq': 4711, 'timestamp': 160000, 'ssrc': '0x1a2b3c4d', 'payload_bytes': 160}Из 172 байт звук занимает 160, остальное заголовок. Если пакеты разбирает своя программа, а не готовая библиотека, начинать стоит именно с такой проверки: версия 2, тип нагрузки ожидаемый, номер растёт.
Тип нагрузки и частота часов
Поле PT говорит, что лежит в пакете, а метка времени считается не в миллисекундах, а в тактах часов кодека. Часть номеров закреплена за кодеками в RFC 3551:
| PT | Кодек | Что передаёт | Часы RTP, Гц |
|---|---|---|---|
| 0 | PCMU (G.711, μ-закон) | звук | 8 000 |
| 8 | PCMA (G.711, A-закон) | звук | 8 000 |
| 9 | G722 | звук | 8 000 |
| 18 | G729 | звук | 8 000 |
| 26 | JPEG | видео | 90 000 |
| 34 | H263 | видео | 90 000 |
| 96–127 | назначаются при установке звонка | Opus, H.264 и другие | по описанию кодека |
У G722 есть ловушка. Звук в нём оцифрован с частотой 16 000 Гц, но в RFC 3551 прямо сказано, что часы RTP для этого формата идут на 8 000 Гц. Программа, которая считает метку по реальной частоте, разъедется с собеседником.
Номера 96–127 RFC 3551 оставляет под динамическое назначение: стороны договариваются о них в описании сессии (SDP). У Opus, например, часы RTP всегда 48 000 Гц, это записано в RFC 7587.
Канал основателя Checkroi Вани Буявца3 700 человек читают мой Телеграм-канал про нейросетиСобрал промпты для Claude Code и ChatGPT, разборы ИИ-инструментов и лайфхаки по продвижению бизнеса в одном местеПрисоединитьсяRTCP: зачем рядом второй протокол
RTP возит данные, а RTCP (RTP Control Protocol) рассказывает, как они доехали. Его описывает тот же RFC 3550. Участники звонка периодически шлют друг другу короткие отчёты:
- SR (sender report): сколько пакетов и байт отправлено;
- RR (receiver report): сколько потеряно и какой джиттер у получателя;
- SDES: описание источника, например имя участника;
- BYE: участник выходит из сессии;
- APP: данные конкретного приложения.
RFC 3550 рекомендует отводить на RTCP 5 % полосы сессии сверх самого потока, а минимальный интервал между отчётами рекомендует 5 секунд. Поэтому по RTCP видна общая картина звонка, но не каждый отдельный сбой.
Как считается джиттер
Джиттер показывает, насколько неравномерно приходят пакеты. Подробно само явление разобрано в статье что такое джиттер сети. В RTP его считают по формуле из раздела 6.4.1 RFC 3550: J = J + (|D| − J) / 16, где D показывает, насколько интервал между приходом двух пакетов отличается от интервала между их метками времени.
Посчитаем для пяти пакетов, один из которых пропал по дороге:
# Пакеты по 20 мс, часы RTP 8000 Гц: метка растёт на 160 за пакет.
# arrival — когда пакет пришёл, в миллисекундах; пакета seq=3 нет совсем.
packets = [ # (seq, rtp_timestamp, arrival_ms)
(1, 0, 100.0),
(2, 160, 121.0),
(4, 480, 163.0),
(5, 640, 178.0),
(6, 800, 205.0),
]
clock = 8000 # отсчётов в секунду
J = 0.0
prev = None
for seq, ts, arr in packets:
r = arr / 1000 * clock # время прихода в единицах часов RTP
if prev:
D = (r - prev[1]) - (ts - prev[0])
J += (abs(D) - J) / 16 # формула из RFC 3550, раздел 6.4.1
prev = (ts, r)
expected = packets[-1][0] - packets[0][0] + 1
lost = expected - len(packets)
print(f"ожидали {expected}, получили {len(packets)}, потеряно {lost}")
print(f"джиттер: {J:.1f} отсчёта = {J / clock * 1000:.2f} мс")ожидали 6, получили 5, потеряно 1
джиттер: 7.1 отсчёта = 0.89 мсПотерю видно по дырке в номерах, а джиттер копится медленно: делитель 16 сглаживает одиночные скачки. Потери и джиттер получатель передаёт собеседнику в блоке отчёта RR, поля для них описаны в том же разделе RFC 3550.
Какие порты использует RTP
Постоянного порта у RTP нет. Номер выбирается при установке звонка и передаётся в описании сессии: в SIP-телефонии внутри SDP, в видеонаблюдении через RTSP. То же сказано в вики Wireshark: общеизвестного UDP-порта у RTP нет, порты выделяются динамически. Что такое порт вообще и чем он отличается от разъёма, объясняет статья про порты компьютера.
Правила, на которые можно опереться при настройке:
- RFC 3550 рекомендует для RTP чётный порт, а для RTCP следующий нечётный. Если RTP идёт на 10000, RTCP ждите на 10001;
- порты RTP и RTCP по тому же RFC не должны совпадать, если их не объединили явно по RFC 5761 (режим rtcp-mux);
- за профилем RTP/AVP зарегистрирована пара 5004 и 5005. В RFC 3551 оговорено, что приложения могут брать её по умолчанию, но не обязаны.
На практике диапазон задаёт АТС или медиасервер:
| Программа | Где задаётся | Диапазон UDP |
|---|---|---|
| Asterisk | rtp.conf, параметры rtpstart и rtpend |
10000–20000 в образце конфигурации; если параметров нет, 5000–31000 |
| FreeSWITCH | switch.conf.xml, параметры rtp-start-port и rtp-end-port |
16384–32768 в закомментированных строках стандартного конфига |
Отсюда главный совет по межсетевому экрану: открывать нужно весь диапазон UDP из конфига вашей АТС, а не один порт. Найти, какие порты на самом деле слушает сервер, поможет сканирование портов в Nmap.
Сколько полосы занимает один звонок
Посчитаем звонок в G.711 при пакетах по 20 мс (такой интервал RFC 3551 рекомендует по умолчанию для звука):
- Звук: 160 байт на пакет.
- Заголовки: 12 байт RTP + 8 байт UDP + 20 байт IPv4 = 40 байт.
- Итого 200 байт, а пакетов 50 в секунду.
- 200 × 50 × 8 = 80 000 бит/с, то есть 80 кбит/с в одну сторону на уровне IP, без заголовков Ethernet и без RTCP.
Заголовки съедают пятую часть трафика. Если уложить в пакет 40 мс звука, их доля упадёт, зато каждая потеря будет слышна сильнее.
RTP, RTSP, SRTP и WebRTC: в чём разница
Эти сокращения часто встречаются рядом, но отвечают за разное.
| Протокол | Что делает | Как связан с RTP |
|---|---|---|
| RTP | везёт звук и видео | основа |
| RTCP | отчёты о качестве | работает в паре с RTP |
| SRTP | шифрует поток и проверяет его целостность | профиль RTP, RFC 3711 |
| RTSP | управляет показом: старт, пауза, выбор потока | сам данные не везёт, договаривается о доставке через RTP |
| SIP и SDP | устанавливают звонок и описывают кодеки и порты | сообщают, куда и в каком формате слать RTP |
| WebRTC | звонки и видео в браузере | медиа идёт только по SRTP |
Про RTSP в RFC 7826 сказано, что это протокол прикладного уровня для настройки и управления доставкой данных реального времени. Доставка при этом может быть построена на RTP. Камера с адресом вида rtsp:// как раз так и работает.
Обычный RTP ничего не шифрует. В WebRTC открытого RTP нет вовсе: RFC 8827 требует, чтобы все медиаканалы были защищены через SRTP.
Как увидеть RTP в Wireshark
Wireshark умеет разбирать RTP, но узнаёт поток не всегда сам. Пункты меню ниже названы так, как в английском интерфейсе программы и её руководстве.
- Запустите захват на нужном интерфейсе и сделайте тестовый звонок.
- Введите фильтр отображения
rtp. - Если пакетов нет, хотя UDP-трафик идёт, Wireshark не увидел начало звонка. По вики Wireshark разбор RTP вне известных разговоров (эвристика) по умолчанию выключен, включается в Analyze → Enabled Protocols, протокол
rtp_udp. - Откройте Telephony → RTP → RTP Streams: там список всех потоков в записи.
- Выделите поток и откройте Telephony → RTP → RTP Stream Analysis. Окно покажет число потерянных пакетов, максимальный и средний джиттер.
- Кнопка Play Streams открывает RTP Player, в котором звонок можно прослушать.
Если пакеты в записи есть, а звука нет, сравните поле PT с кодеком, о котором договорились в SDP.
Канал основателя Checkroi Вани БуявцаЗабирайте промпты и обучение по нейросетям в моём Телеграм-каналеБольше 3 700 человек уже применяют Claude Code, ChatGPT и другие нейросети в работе, учёбе, бизнесе и жизниПерейти в каналЧастые проблемы с RTP и что с ними делать
Разберём четыре симптома и что стоит за каждым.
Звонок соединяется, но слышно только одну сторону
Сигнализация SIP прошла, а голос нет. Чаще всего RTP упирается в NAT или межсетевой экран: диапазон UDP не открыт либо в SDP уехал внутренний адрес вида 192.168.x.x, до которого собеседник не достучится.
Решение: открыть диапазон RTP из конфига АТС и указать в настройках SIP-сервера внешний адрес. Как устроены уровни, через которые проходит пакет, наглядно разобрано в статье про модель OSI.
Звонок есть, звука нет ни у кого
Стороны не договорились о кодеке, или одна шлёт динамический тип нагрузки, которого другая не ждёт. Сверьте поле PT в пакетах с описанием сессии в SDP и списком кодеков на обоих концах.
Голос рвётся и булькает
Это потери и джиттер. Посмотрите на числа в RTP Stream Analysis: если потерь много, ищите перегруженный канал; если растёт джиттер, звуку не хватает приоритета в сети или буфера на приёме. Проверить задержку до сервера поможет тест пинга.
Wireshark не показывает RTP
Захват начат посреди звонка, и программа не видела, на какой порт договорились стороны. Включите эвристику rtp_udp или начните запись до звонка.
Где освоить сети и IP-телефонию системно
Чтобы разобрать один пакет, хватит этой статьи. Чтобы самому поднимать АТС, настраивать NAT и QoS под голос и разбирать сбои в Wireshark, нужна системная база по сетям. С неё начинают путь сетевого инженера, а курсы по ней собраны в каталоге «Сетевые технологии»:
| Курс | Школа | Стоимость со скидкой | В рассрочку | Длительность | Обзор курса от Checkroi |
|---|---|---|---|---|---|
| Профессия «Сетевой инженер» Перейти на сайт курса |  Нетология | 85 800 ₽ | 3575 ₽/мес. | 12 месяцев | Обзор курса |
| Сетевые технологии Перейти на сайт курса |  Merion | 21 840 ₽ | 1578 ₽/мес. | 2 месяца | Обзор курса |
| Сетевые технологии Huawei Перейти на сайт курса | Merion | 11 830 ₽ | 938 ₽/мес. | 2 месяца | Обзор курса |
| Управление и администрирование сетевых устройств информационно-коммуникационных систем Перейти на сайт курса |  Дипломикс | 10 900 ₽ | 818 ₽/мес. | Обзор курса | |
| Учебная программа “Кибербезопасность и Сетевые технологии” Перейти на сайт курса |  Академия ТОП | Бесплатно | - | 2 года | Обзор курса |
Больше программ — в полном каталоге курсов по сетевым технологиям
