RTSP против UDP: почему RTSP подключается, но видео черное — RTP заблокирован брандмауэром, NAT и VPN

Одну из самых серьезных проблем RTSP описать просто: "камера подключается, но видео нет. Во многих случаях управление RTSP работает через TCP, но медиа-пакеты UDP RTP никогда не достигают клиента. Пользователь видит успешный вход в систему, SDP, возможно даже «PLAY 200 OK», а затем таймаут. Такие поисковые запросы, как «RTSP подключается, но нет видео», «RTP UDP заблокирован брандмауэром», «RTSP работает в локальной сети, а не через VPN», «RTSP NAT камеры без видео» и «Исправление чередования RTSP TCP» — все указывают на это разделение уровней." RTSP — это не один поток данных. Канал управления и медиаканал могут использовать разные транспортные пути. Если канал управления работает, а медиатракт выходит из строя, плеер может показывать тот же черный экран, что и сбой кодека. Доказательства пакета разные.

Инспектор RTSP полезен, поскольку он отделяет успех управления RTSP от доставки мультимедиа RTP.

Контроль работает, не значит, что СМИ работают

Обычный поток UDP RTP может выглядеть так:

1. Клиент открывает TCP-соединение RTSP с портом камеры 554.
2. Клиент отправляет DESCRIBE.
3. Камера возвращает SDP.
4. Клиент отправляет SETUP с клиентскими портами UDP.
5. Камера возвращает порты UDP-сервера.
6. Клиент отправляет PLAY.
7. Камера отправляет пакеты RTP на порты UDP клиента.

Если шаги 1–6 завершаются успешно, а шаг 7 завершается неудачей, поток не является проблемой входа в систему RTSP. Это проблема пути носителя.

Заголовок транспорта показывает план порта

Запрос SETUP может включать в себя:

Transport: RTP/AVP;unicast;client_port=50000-50001

The camera may answer:

Transport: RTP/AVP;unicast;client_port=50000-50001;server_port=6970-6971

Камера должна отправлять RTP/RTCP на UDP-порты клиента. Брандмауэры должны разрешать этот трафик. Устройства NAT должны правильно его отобразить. VPN должны это поддерживать. В противном случае управление RTSP может выглядеть работоспособным, пока медиа молчит.

Распространенные сбои брандмауэра и NAT

Общие причины включают в себя:

• Брандмауэр разрешает TCP 554, но блокирует диапазон портов UDP RTP.
• NAT перенаправляет порт RTSP, но не порты RTP.
• Камера отправляет RTP из неожиданных исходных портов.
• Клиент объявляет частные порты UDP, недоступные с камеры.
• VPN разрешает TCP, но отключает UDP.
• Корпоративный межсетевой экран блокирует высокие порты UDP.
• Камера находится за двойным NAT.
• Пакеты RTP возвращаются на неправильный интерфейс.

Видимым симптомом часто является «нет видео после PLAY».

Почему чередующийся TCP часто работает

RTSP через TCP с чередованием передает RTP и RTCP внутри TCP-соединения RTSP. Это позволяет избежать отдельных дыр в UDP.

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

Однако чередующийся TCP имеет свои собственные требования к синтаксическому анализу, включая сопоставление каналов. Это обходной путь для проблем с путями UDP, а не доказательство работоспособности каждого уровня.

RTCP может помочь доказать путь

Если RTP заблокирован, но приходит RTCP или наоборот, проверьте пары портов. Некоторые брандмауэры обрабатывают эти два направления по-разному. Отчеты получателей RTCP также могут показывать потерю пакетов и дрожание, если мультимедийные данные доставлены частично.

Записывать:

• Количество RTP-пакетов.
• Количество RTCP-пакетов.
• IP-адрес и порт источника RTP.
• IP-адрес и порт назначения RTP.
• Пробелы в порядковых номерах.
• Время от «PLAY» до первого пакета.

Контрольный список отладки

Используйте этот рабочий процесс:

1. Подтвердите успешность выполнения RTSP DESCRIBE, SETUP и PLAY.
2. Проверьте заголовок «Transport» и UDP-порты клиента/сервера.
3. Проверьте, приходят ли пакеты RTP после PLAY.
4. Проверьте, приходят ли RTCP-пакеты.
5. Сравните тест LAN и тест VPN/WAN.
6. Проверьте чередующийся транспорт TCP.
7. Проверьте правила брандмауэра для диапазона портов UDP RTP.
8. Проверьте переадресацию портов NAT и поведение исходного порта.
9. Проверьте объявленные клиентом доступные UDP-порты.
10. Не проводите отладку кодека до тех пор, пока не поступят полезные данные RTP.

Окончательный диагноз

Когда RTSP подключается, но UDP RTP блокируется, камера может быть полностью доступна, но носитель никогда не поступает. Исправление касается доступности порта UDP, поведения NAT, политики брандмауэра, правил VPN или переключения на чередующийся TCP.

Инспектор RTSP помогает, показывая вместе управляющую последовательность RTSP и данные пакета RTP, поэтому «отсутствие видео» становится конкретным диагнозом транспорта.