Анализ RTP: разрыв sequence number и скачок timestamp требуют разной проверки

Фотография конкретного исполнения не приложена.

Sequence number и timestamp решают разные задачи. Первый увеличивается для отправленных RTP-пакетов, второй отражает момент выборки полезного содержимого. Поэтому один пропуск числа нельзя автоматически трактовать как потерю заданного количества миллисекунд звука.

RFC 3550 задаёт 16-битный sequence number и 32-битный timestamp. Оборот счётчиков является нормальным поведением, а поток рассматривается в контексте SSRC. Объединение разных источников в один ряд создаёт фиктивные разрывы и неверные оценки потерь.

Пакеты могут приходить не по порядку или повторяться. Поздний пакет способен закрыть первоначально наблюдавшийся gap, но уже не успеть к сроку воспроизведения. Это различие между сетевым приёмом и полезным декодированием. Изменение packetization или подавление тишины также нельзя оценивать по одному ожидаемому шагу timestamp без знания формата.

В приёмке сохраняют порядок приёма, SSRC, sequence и временную базу payload. Проверяют reorder, дубликат и реальную потерю отдельно. Качество воспроизведения сопоставляют с поведением jitter buffer. Успешная доставка всех пакетов к концу захвата не доказывает, что каждый из них был своевременно использован аудиотрактом.

Основание — Numbered IETF voice and NAT-traversal RFCs with selected RFC8863 ICE update; protocol scopes identified per task, разделы RFC3550 5.1 RTP fixed header; SSRC; sequence number validation. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC о SIP, SDP, RTP и NAT traversal; рассматриваются конкретные границы поведения, а не полный современный профиль реализации или защиты. Реальные шлюзы, АТС, терминалы и медиапотоки не проверялись; вызовы и записи звука не выполнялись.

Запросить

Запросы отправляются на наш e-mail из вашей почтовой программы.