Кратко

  • В URI параметр comp=sigcomp относился к запросу на следующий узел, в верхнем Via — к ответу, а в Contact и Record-Route — к будущему трафику.
  • Метка сообщала о поддержке и текущей готовности принимать сжатые сообщения. Она не доказывала фактическое сжатие, разбор SIP, доставку, аутентификацию или установление сеанса.

В RFC 3486 власть над сжатием постоянно переходила из одного поля в другое. Для запроса решающим был URI следующего узла. Для ответа — верхний Via. Для последующих запросов в диалоге значение приобретали Contact и Record-Route. Поэтому один флаг на весь разговор был бы не упрощением, а потерей смысла.

Такой механизм возник из проблемы комбинаций. SIP уже применял NAPTR и SRV для выбора UDP, TCP или SCTP. Если бы DNS перечисляла еще и каждое сочетание транспорта, TLS и SigComp, число записей быстро росло бы. RFC 3486 перенесла сигнал на прикладной уровень. Обычные и сжатые сообщения могли приходить на один порт, а начальные cookie-биты позволяли различить SigComp.

Запись comp=sigcomp выглядела одинаково в разных местах. В SIP- или SIPS-URI она предлагала сжать запрос к указанному следующему узлу. В верхнем Via она предлагала сжать ответ на обратном участке. Без поля и направления сама строка была неполным доказательством.

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

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

До появления диалога еще не было набора маршрутов. Клиент мог узнать подходящий URI из ручной настройки или отправить несжатый OPTIONS исходящему прокси. Прокси мог вернуть в Contact альтернативный URI с параметром. Это было предложение для будущего трафика, но не запись о том, какие байты действительно ушли позже.

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

Пример RFC показывает четыре SIP-элемента, но сжаты только сообщения 1, 6 и 7. Первый прокси получает сжатый INVITE и пересылает обычный. Ответ идет по одному участку без сжатия, а по следующему — со сжатием. ACK снова меняет рисунок. Поддержка несколькими узлами не создавала однородного канала.

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

Ошибка оставляла особенно неоднозначный след. Сервер без SigComp мог не разобрать сжатый запрос даже до Via и потому не знать, куда отправить SIP-ошибку. После тайм-аута транзакции клиенту следовало повторить тот же запрос без сжатия. Молчание давало основание для такого шага, но не устанавливало причину.

При TCP требовалось закрыть прежнее соединение и открыть новое. Иначе несовместимый сервер мог не найти начало обычного SIP-сообщения в потоке, начавшемся сжатым. Первая попытка, тайм-аут, новая форма и новое соединение были четырьмя наблюдаемыми событиями.

Метка не удостоверяла того, кто ее вставил. Злоумышленник мог добавить comp=sigcomp и направить сжатые данные к узлу без поддержки, поэтому RFC требовала подходящей защиты целостности. Декомпрессия также стоила больше вычислений и немного усиливала риск отказа в обслуживании.

Реестр IANA закрепил словарь, но не практику эксплуатации. RFC 3320 определила SigComp, RFC 3485 — статический словарь SIP/SDP. RFC 5049 позднее обновила применение к SIP, добавив минимальные ресурсы, compartments и управление состоянием. RFC 4077, RFC 4896, RFC 5112 и RFC 5626 уточнили другие аспекты. Публикация стандарта не была переписью внедрений.

Для расследования нужны точные URI, Via, Contact, Route и Record-Route, направление, целостность, байты на линии, транспорт и соединение. OPTIONS и последующее применение фиксируются отдельно. При молчании сохраняются тайм-аут, несжатый повтор и новое TCP-соединение. Лишь затем связываются декомпрессия, разбор SIP, аутентификация и итог диалога.

Историческая точность RFC 3486 состояла в отказе от сквозной иллюзии. Она решила проблему разрастания DNS, но ограничила каждую команду ближайшим получателем. Метка путешествовала по сообщению; ее полномочия дальше следующего участка не распространялись.

Источники