Кратко

  • RFC 3485 позволила первой SigComp-команде ссылаться на общий материал SIP/SDP, потребовав один неизменяемый и побайтно точный статический объект во всех реализациях.
  • Читаемые списки приложений объясняли происхождение строк, но совместимость зависела от нормативного двоичного значения, идентификатора, длины и точных срезов.

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

Эта память должна была быть уникальной и постоянной. Каждая реализация SigComp для SIP/SDP обязана иметь словарь, который не меняется вместе с протоколами. Его определили один раз, устранив необходимость узнавать версию у удалённой стороны до начала обмена.

Стороны соглашались на точное состояние SigComp. Раздел 3 закреплял полный идентификатор, длину 0x12E4, минимальную длину доступа шесть октетов и все байты. STATE-ACCESS мог использовать шестибайтовый префикс по правилам поиска, но выбирал тот же полный объект.

Приложения A и B показывали строки SIP и SDP, приоритеты, смещения, длины и источники. Они были информационными. Нормативным оставалось двоичное представление. Совпадение слов при отличии одного байта не создавало общего состояния.

Значение соединяло область строк и таблицу. Строковая часть содержала материалы как подстроки. Таблица хранила однобайтовую длину и двухбайтовое смещение с добавленными 1024, что позволяло напрямую адресовать состояние в памяти UDVM по адресу 1024.

Общие фрагменты перекрывались. Один префикс обслуживал несколько заголовков, а код ответа имел запись отдельно и вместе с рекомендуемой фразой. Код был нормативен, фраза — нет. Разные логические записи могли разделять одни байты.

Формат входил в доказательство. Сравнение учитывало регистр; заголовки часто включали предыдущий CRLF, двоеточие и пробел. Синтаксически допустимое иное форматирование могло дать меньший эффект. Равный смысл не означал равные байты.

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

Приоритеты позволяли экономить память. RFC дала точные смещения и длины для уровня один, уровней один-два, один-три и один-четыре. Такой срез не был новой версией, а оставался диапазоном исходного неизменного состояния.

Поэтому отметки «словарь использован» недостаточно. Нужны частичный идентификатор, offset, длина, область и уровень. Даже они доказывают доступ, но не успешную распаковку.

Распаковка не доказывает корректность SIP/SDP, аутентификацию, доставку или сеанс. RFC 3320 владеет границей UDVM и авторизации состояния, RFC 3321 — жизнью динамического состояния, RFC 3322 — моделью производительности. RFC 3485 описывает только заранее установленную память.

RFC 3486 определила SIP-сигнализацию SigComp; RFC 4464 объяснила применение; RFC 4465 проверила доступ; RFC 4896 уточнила раскладку; RFC 5049 потребовала поддержку. RFC 5112 создала отдельный словарь presence, не меняя этот.

Раздел безопасности ссылался на RFC 3320 и не видел нового известного риска. Это не превращало сжатие в проверку личности. Идентификатор не подтверждает отправителя, полномочия, целостность или доставку.

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

По слоям реальности Heng Lu сначала проверяются хэш, идентификатор и длина полного состояния. Затем сохраняются префикс и операнды STATE-ACCESS, разрешается диапазон байтов и сверяется трасса распаковки. Валидность, аутентификация, транспорт и итог идут позже.

RFC 3485 дала первому сообщению заимствованное прошлое. Оно могло быть общим лишь потому, что было не редактируемым словарём, а запечатанным массивом байтов без второго издания.

Источники