Отчеты об отправителях RTCP, дрожание и потеря пакетов: чтение состояния потока без просмотра видео

Когда инженеры ищут «дрожание RTSP», «потеря пакетов RTP» или «отчет отправителя RTCP», они обычно пытаются ответить на практический вопрос: "поток неработоспособен или игрок просто борется? Воспроизведение видео является поздним симптомом. Доказательства RTP и RTCP появляются раньше, и их легче защитить в обращении в службу поддержки." RTCP является дополнением управления RTP. Он может передавать отчеты отправителя, отчеты получателя, количество пакетов, информацию о времени и обратную связь о качестве. Не каждая камера обеспечивает богатое поведение RTCP, и не каждое развертывание передает его правильно, но когда RTCP присутствует, он дает важный контекст, которого нет при необработанном воспроизведении.

Почему RTCP имеет значение в диагностике камеры

RTP передает медиа-пакеты. RTCP помогает описать состояние сеанса мультимедиа. Для потока с камеры RTSP доказательства RTCP могут помочь ответить:

• жив ли отправитель после PLAY?
• сколько пакетов RTP сообщил отправитель?
• соответствуют ли временные метки RTP времени настенных часов?
• доставка пакетов стабильная или прерывистая?
• есть ли видимый джиттер?
• RTP продолжался, хотя декодирование видео не удалось?
• был ли путь мультимедиа вообще включен в RTCP?

Если управление RTSP выполнено успешно и RTP поступает, но видео зависает, RTCP может помочь отделить синхронизацию сети от готовности кодека.

Отчеты об отправителях являются доказательством времени

Отчет отправителя RTCP может связать временную метку RTP с абсолютным значением времени в стиле NTP. Эта связь помогает получателям синхронизировать потоки и анализировать поведение часов. В диагностике точная математика может быть менее важна, чем наличие и последовательность отчетов.

Полезные наблюдения:

• отчет об отправителе появляется после запуска мультимедиа
• увеличивается количество пакетов и октетов
• Сопоставление временных меток RTP согласовано
• интервал отчета является правдоподобным
• отчеты прекращаются, когда останавливается RTP
• отчеты продолжаются, даже если декодер выходит из строя

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

Джиттер — это не то же самое, что потеря пакетов

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

Порядковые номера RTP показывают недостающие пакеты. Временные метки RTP и время прибытия показывают изменение времени. Отчеты RTCP могут добавлять обратную связь на уровне сеанса. В правильном отчете не должно быть сказано только «плохая сеть». В нем должно быть указано, связана ли проблема с потерей, джиттером, пакетной доставкой, блокировкой RTCP или границей декодирования кодека.

В случае камер дрожание может возникать по следующим причинам:

• Вариант восходящего канала Wi-Fi
• перегруженный кодер камеры
• Задержка пересылки NVR
• перегруженный путь переключения
• Путь VPN или WAN
• поведение буферизации на стороне клиента

Потеря пакетов может произойти по следующим причинам:

• UDP-дропы
• поведение брандмауэра/NAT
• перегруженная сеть
• камера отправляет буферное давление
• ограничения точки захвата

Исправления разные.

Отсутствие RTCP также является доказательством

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

Если согласовано RTP через UDP, проверьте оба носителя и управляйте сопутствующим трафиком. Если используется чередование RTSP через TCP, проверьте метаданные чередующегося канала. Отчет, в котором указано «RTP виден, RTCP отсутствует», более полезен, чем пустое поле.

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

RTSP Inspector создан для доказательства протокола, а не для пассивного просмотра. RTCP относится к той же истории, что и методы RTSP, SDP, непрерывность последовательности RTP, тип полезной нагрузки, метаданные кодека и экспорт отчетов.

При поиске с большим количеством RTCP инспектор RTSP должен помочь ответить:

• RTP прибыл после «PLAY»?
• did RTCP sender reports appear?
• количество пакетов увеличилось?
• совпадали ли джиттер или разрывы последовательности с видимыми сбоями?
• не удалось ли подготовить кодек, несмотря на доставку мультимедиа?
• изменился ли вид транспорта на профиль здоровья?

Это дает поставщику камер, сетевому инженеру или разработчику VMS конкретную отправную точку. «Поток заикается» — это симптом. «Пробелы в последовательности RTP и джиттер увеличились после PLAY, в то время как управление RTSP оставалось активным» является свидетельством.