Кратко
- RFC 3545 повторял изменённые значения контекста в N+1 последовательных пакетах, чтобы декомпрессор мог восстановить синхронизацию, если серия потерь оставалась в пределах принятого для канала допущения.
- Необязательная HDRCKSUM помогала проверять восстановленный заголовок при нулевой UDP-контрольной сумме IPv4, но не охватывала Identification; после потери более N соседних пакетов безопаснее было аннулировать контекст и запросить его состояние.
У проверки оставалось слепое пятно. RFC 3545 разрешал компрессору заменить нулевую UDP-контрольную сумму IPv4 16-битной контрольной суммой заголовка. Так декомпрессор мог проверить восстановление. Но IPv4 Identification не входил в список проверяемых полей. На канале с малыми потерями это исключение могло теряться на фоне более широкой схемы восстановления. После слишком многих соседних потерь оно меняло смысл слова «восстановлен».
CRTP, определённый RFC 2508, сжимает заголовки IP, UDP и RTP, сохраняя общий контекст на обоих концах. Полный заголовок устанавливает состояние; последующие пакеты могут нести изменения или разности. Если теряется пакет с обновлением, компрессор продвигается вперёд, а декомпрессор остаётся на прежнем состоянии. Расхождение может проявиться лишь при поступлении следующего сжатого пакета. На канале с большой задержкой запрос ремонта контекста занимает как минимум время кругового обмена; пока он идёт, могут быть отброшены новые пакеты.
RFC 3545 отвечает повторением обновлений и явной границей. Параметр N описывает характеристики потерь на канале: вероятность потери более чем N соседних пакетов должна быть небольшой. Если обновление включено в N+1 последовательных пакетов, хотя бы одна копия должна дойти, пока серия потерь не превышает N. Декомпрессор может применить алгоритм «twice» для восстановления ограниченного пропуска и проверить результат UDP-контрольной суммой или, если применимо, HDRCKSUM. Это повышает устойчивость, но не гарантирует, что каждый всплеск потерь укладывается в модель.
Номер последовательности канала состоит всего из четырёх бит и повторяется через каждые 16 пакетов. Поэтому по разнице значений не всегда можно понять, потеряно ли много пакетов или более поздний пакет пришёл раньше предыдущего из-за переупорядочивания. Если правдоподобно предположение о потере менее N+1 пакетов, декомпрессор может выполнить соответствующее восстановление и проверить его. Для IPv4 при возможной потере более N пакетов правило строже: не продолжать догадки с «twice», а аннулировать контекст и отправить CONTEXT_STATE, чтобы компрессор восстановил общее состояние.
Именно здесь важен охват контрольной суммы. HDRCKSUM можно использовать, если исходная UDP-контрольная сумма IPv4 равна нулю; компрессор добавляет её для проверки, после чего декомпрессор удаляет. Для IPv6 опция не применяется, поскольку нулевая UDP-контрольная сумма там недопустима. Но контрольная сумма заголовка всё равно не проверяет IPv4 Identification. После потери более N пакетов успешная проверка не закрывает этот пробел. RFC 3545 предписывает отбросить неопределённый IPv4-контекст. В IPv6 нет поля IPv4 ID, поэтому правило восстановления может отличаться.
У серии обновлений есть и собственная защита идентичности. Если постоянное поле контекста меняется во время передачи N+1 пакетов FULL_HEADER, компрессор начинает новую серию и изменяет номер поколения. Иначе декомпрессор может принять перекрывающиеся серии за больший допустимый уровень потерь и не заметить рассинхронизацию. Сообщения CONTEXT_STATE также рекомендуется повторять. Эти механизмы не доказывают, что конкретное устройство включило расширение или RTP-приложение воспроизвело полезную нагрузку.
Исторический вывод невелик, но важен для эксплуатации: контрольная сумма доказывает только проверяемые ею поля; ограниченное восстановление не равно доставке; ремонт контекста не подтверждает приём медиа. Локальная проверка может пройти, а IPv4 ID остаться непроверенным. Когда потери превышают принятое допущение, аннулирование контекста — не отказ от восстановления, а отказ выдавать неоднозначную последовательность за достоверность.
Источники
- RFC 3545 — Enhanced Compressed RTP
- RFC 3545 — запись RFC Editor и доступ к списку исправлений
- RFC 3545 — история Datatracker
- RFC 2508 — сжатие заголовков IP/UDP/RTP
- RFC 3544 — сжатие заголовков IP поверх PPP
- RFC 3095 — Robust Header Compression
- RFC 3550 — RTP: транспортный протокол для приложений реального времени
- RFC 3711 — Secure Real-time Transport Protocol
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
