Многоадресная рассылка RTSP и потоки камер UDP: почему обнаружение работает, но медиа не доходит

В сетях камер часто сочетаются одноадресный RTSP, многоадресный RTP, обнаружение ONVIF, VLAN, коммутаторы PoE, межсетевые экраны и сетевые видеорегистраторы. Симптом может сбить с толку: "камера обнаружена, URL-адрес RTSP действителен, DESCRIBE возвращает SDP, но медиа-пакеты никогда не приходят." Это классическая граница протокола. Дискавери – это не СМИ. Управление RTSP не является доставкой RTP. Доступность многоадресной рассылки — это не то же самое, что доступность одноадресной рассылки.

Обнаружение ONVIF — это другой диалог UDP

Обнаружение ONVIF обычно использует многоадресную рассылку UDP по адресу и порту обнаружения. Если обнаружение завершается успешно, это доказывает, что по крайней мере один путь управления в стиле многоадресной рассылки сработал для обнаружения. Это не доказывает, что группы многоадресной рассылки RTP разрешены, объединены, маршрутизируются или пересылаются.

Распространенные ошибки:

• предполагая, что обнаружение ONVIF подтверждает путь мультимедиа RTP
• тестирование из другой VLAN, чем NVR
• разрешить TCP 554, но блокировать медиа-порты UDP
• блокировка группового трафика multicast на коммутаторе
• забывая об отслеживании IGMP или о поведении запросов
• проверка прямого URL-адреса камеры, в то время как NVR использует другой путь

В отчете должен быть указан тип трафика: обнаружение, управление RTSP, носитель RTP или обратная связь RTCP.

Многоадресная рассылка требует членства в группе

Для многоадресной RTP получатель должен присоединиться к группе многоадресной рассылки. Коммутаторам и маршрутизаторам может потребоваться поведение IGMP для правильной пересылки трафика. Если многоадресная рассылка отключена, отфильтрована или неправильно настроена, управление RTSP может продолжать работать, даже если носитель не поступает.

Полезные доказательства:

• SDP объявляет адрес многоадресной рассылки или одноадресный транспорт.
• Транспортный заголовок SETUP подтверждает запрошенный режим
• интерфейс приемника и VLAN
• адрес многоадресной группы
• достигают ли пакеты RTP точки захвата
• появляется ли RTCP
• ведет ли одноадресный режим по-другому

Если одноадресная передача RTP работает, а многоадресная — нет, возможно, проблема связана с конфигурацией многоадресной рассылки в сети, а не с H.264.

UDP-носитель может быть заблокирован, пока работает TCP-контроль

Брандмауэры часто разрешают TCP 554 или 8554, но блокируют порты UDP. NAT также может вывести из строя UDP-носитель. Это создает общий шаблон:

• TCP-соединение установлено успешно
• ОПИСАТЬ удалось
• НАСТРОЙКА выполнена успешно
• «ИГРАТЬ» удалось
• RTP не приходит

Переключение на чередующийся TCP — полезное сравнение. Если чередование TCP работает, сервер и кодек RTSP, скорее всего, работают. Медиа-тракт UDP требует внимания.

Что снимать

Для случаев многоадресной рассылки и UDP захватите:

• Заголовки запросов и ответов RTSP
• Медиа-адрес SDP и информация о треке
• транспортный заголовок из SETUP
• клиентские и серверные порты
• многоадресная группа
• Прибытие или отсутствие RTP-пакета
• Прибытие или отсутствие RTCP-пакета
• тот же тест через TCP с чередованием

Это свидетельство помогает сетевой команде исправить маршрутизацию, брандмауэр или многоадресную пересылку вместо того, чтобы просить поставщика камеры изменить настройки кодека.

Где подходит инспектор RTSP

RTSP Inspector создан для доказательства протокола, а не для визуального предположения. В случаях многоадресной рассылки и UDP его значение показывает, где остановился поток:

• обнаружение сработало, но RTSP не удалось
• RTSP работал, но RTP так и не пришел.
• Ошибка UDP, но чередование TCP работало
• группа многоадресной рассылки была объявлена, но пакеты не дошли до клиента
• RTP прибыл, но готовность кодека не удалась

Это разные неудачи. Окно проигрывателя не может достоверно отличить их друг от друга. Протокольный отчет может.