Несоответствующий транспорт RTSP в ответе сервера: отладка ответов SETUP камеры и несоответствие режима RTP

Некоторые сбои RTSP не возвращают чистое сообщение «461 Unsupported Transport». Вместо этого клиент сообщает «несоответствующий транспорт в ответе сервера», «неверный транспортный заголовок», «сервер ответил другим транспортом» или «несоответствие транспорта RTP». Это часто происходит, когда камера принимает SETUP, но отвечает заголовком Transport, который не соответствует тому, что запросил клиент или что клиент может проанализировать.

Пользователи ищут «Несовпадающий транспорт RTSP в ответе сервера», «Несовпадающий транспорт ffmpeg», «Несоответствие транспорта RTSP SETUP» и «Неверный заголовок транспорта камеры», поскольку поток может работать в одном проигрывателе и не работать в другом. Камера не просто недоступна. Согласование транспорта RTSP противоречиво.

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

Как выглядит соответствующий обмен SETUP

Клиентские запросы TCP чередуются:

Transport: RTP/AVP/TCP;unicast;interleaved=0-1

Server replies with compatible TCP interleaved transport:

Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=12345678

Клиент запрашивает UDP:

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

Server replies with UDP ports:

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

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

Распространенные случаи несоответствия

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

• Клиент запрашивает TCP, сервер отвечает UDP.
• Клиент запрашивает UDP, сервер отвечает TCP.
• Сервер опускает interleaved=.
• Сервер возвращает неправильные номера каналов.
• Сервер возвращает значения client_port, отличные от запроса.
• Сервер опускает server_port для UDP.
• Сервер возвращает многоадресную рассылку, когда клиент запросил одноадресную рассылку.
• Сервер возвращает несколько вариантов транспорта в неподдерживаемом формате.
• Прокси перезаписывает запрос, но не ответ.

Некоторые клиенты терпят эти странности. Другие отвергают их.

Почему один игрок работает, а другой терпит неудачу

Реализации RTSP различаются. Терпимый игрок может принять неверную или неожиданную реакцию транспорта и продолжить. Более строгий инструмент может потерпеть неудачу, потому что ответ нарушает его ожидания.

Это не означает автоматически, что строгий клиент ошибается. Это означает, что необходимо проверить поведение камеры или прокси-сервера.

Для профессиональной диагностики сохраните:

• Запрошенный транспортный заголовок.
• Ответ сервера Transport.
• Отслеживать URL-адрес.
• Идентификатор сеанса.
• Будут ли пакеты RTP приходить позже.

Переписывание прокси и реле

Ретрансляторы с поддержкой RTSP могут перезаписывать транспортные заголовки для соединения путей UDP и TCP. Если перезапись не завершена, нижестоящий клиент увидит ответ, не соответствующий его запросу.

Примеры:

• Клиент запрашивает TCP у ретранслятора.
• Реле запрашивает UDP от камеры.
• Реле случайно пересылает ответ UDP-транспорта камеры вниз по течению.

Клиент сообщает о несоответствующем транспорте, даже несмотря на то, что камера и ретранслятор выполнили частично допустимые действия.

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

Используйте этот процесс:

1. Захват запроса SETUP.
2. Запишите ответ SETUP.
3. Сравните транспортный протокол: UDP, TCP с чередованием, многоадресную рассылку.
4. Сравните одноадресную/многоадресную рассылку.
5. Сравните порты клиента, порты сервера и чередующиеся каналы.
6. Проверьте, находится ли в пути прокси/рестример.
7. Проверьте, соответствуют ли последующие пакеты RTP сопоставлению ответа.
8. Сравните толерантного игрока и строгого клиента, используя пакетные доказательства.
9. Если возможно, проверьте прямой URL-адрес камеры.
10. Сообщите поставщику точную транспортную пару.

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

«Несоответствующий транспорт в ответе сервера» означает, что в результате согласования SETUP был получен несовместимый или неверный транспортный ответ. Возможно, камера или реле меняет режим RTP, пропускают поля или возвращают значения, которые клиент не может безопасно использовать.

Инспектор RTSP помогает, делая видимой пару транспортного запроса/ответа, что является единственным надежным способом диагностики этого класса сбоев RTSP.