Кратко

  • RFC 3322 получила 4 131 мс для цепочки SIP/SDP при 9,6 кбит/с и RTT 140 мс, одновременно назвав приближение грубым и исключив задержку возможных повторных передач.
  • Расчёт формировал требования к будущему SigComp, но не был полевым измерением, свидетельством внедрения или гарантией достигнутого выигрыша.

Граница до работающего кода

В январе 2003 года RFC 3322 вышла в категории Informational. Она не определяла стандарт Интернета и не сертифицировала готовый продукт. Документ собирал мотивацию, предположения и требования к схеме сжатия сигнальных сообщений, которую предстояло разработать.

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

Проблема была реальной. Текстовые SIP, SDP и RTSP обменивались несколькими запросами и ответами до полезного трафика. На радио с ограниченной ёмкостью размер сообщений влиял на время и число пользователей в соте. Коррекция ошибок, перемежение и повторная передача уменьшали потери ценой задержки.

Как возникли 4,131 секунды

Формула делила число бит в каждом сообщении на 9 600 бит/с и добавляла 70 мс — половину заданного RTT 140 мс. Для показанной последовательности INVITE, предварительных ответов, PRACK, 200 OK и ACK сумма составила 4 131 мс. Отдельно оценивались RSVP, управление сеансом и установление радиоканала.

RFC прямо называет приближение WCDMA «rather crude». Расчёт не учитывал возможные повторы из-за ошибок, предполагал один сотовый участок, упрощал промежуточную IP-сеть и использовал типичные размеры. Сравнение примерно 3,6 секунды для GSM и 7,9 секунды для SIP-сценария служило контекстом, а не телеметрией SigComp.

Точность арифметики не расширяет область доказательства. Число описывает сериализацию и половину RTT при данных условиях. Оно ничего не сообщает о конкретном пользователе и не измеряет улучшение после компрессии.

Почему выбрали сжатие

Увеличение скорости одного пользователя могло сократить ёмкость соты. Снижение RTT требовало системных изменений. Перестройка последовательности запросов меняла прикладные протоколы. Удаление полей уменьшало объём, но теряло прозрачность и нарушало принцип «конец-конец».

Сжатие сохраняло смысл: после распаковки требовалась битовая идентичность. Решение должно было сосуществовать с ROHC, поддерживать произвольные потоки, работать поверх UDP и TCP и не требовать обязательной обратной связи на однонаправленном пути. Переговоры об использовании сжатия оставались вне схемы и принадлежали протоколу, создающему сообщения.

Требования к производительности запрещали улучшать коэффициент за счёт очереди, заметной пользователю. Они требовали устойчивости к остаточным ошибкам, минимального распространения сбоя, продолжения после потери и умеренной перестановки. Это будущие тесты, а не результаты.

RFC 3320, RFC 3485, RFC 3486, RFC 4077 и RFC 5049 показывают, как архитектура, словарь и эксплуатационные рекомендации развивались дальше. Эта последовательность подтверждает работу над дизайном, но не частоту внедрения и не величину экономии. Для таких выводов нужны переговорные трассы, версии, условия радиосети и наблюдаемый контроль.

Исторический урок RFC 3322 состоит в сохранении цепочки происхождения. Модель объясняет, почему началась работа. Требования определяют, что проверять. Реализация показывает выбранный механизм. Измерение оценивает результат. Если пропустить звено, документ получает власть над фактами, которой никогда не требовал.

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

Sources