Кратко

  • RFC 3487 требовала, чтобы указание приоритета SIP вызывало именованную политику, а не задавало очередь, вытеснение, долю ёмкости или длительность сеанса.
  • Одна метка могла вызвать разные действия у шлюза, телефонной сети, прокси и приёмника; поддержка, полномочие, допуск и успешная связь оставались разными фактами.

Слово «приоритет» звучит как готовая команда. Но во время бедствия дефицит возникает в разных местах и принадлежит разным администраторам. В 2003 году RFC 3487 не стала сразу определять новый заголовок SIP. Информационный документ сначала описал границу полномочий: отправитель мог назвать желаемую политику, но не должен был программировать чужой ресурс.

Авторы выделили пять поверхностей. У шлюза ограничено число транков в сеть с коммутацией каналов. Внутри этой сети есть собственные пути и режимы GETS или MLPP. В IP-сети сигнализация и медиапотоки подчиняются разным механизмам. Приёмная система способна вести лишь конечное число сеансов. SIP-прокси может исчерпать вычисления раньше полосы доступа. Единого механизма для всех пяти RFC не требовала.

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

Топология меняла и набор доступных решений. RFC рассмотрела IP между конечными точками, IP к телефонной сети, телефонную сеть к IP и мост CSN-IP-CSN. На мосту источник мог не знать протокол удалённой сети. Из-за разветвления SIP даже шлюз не всегда знал, окажется ли конечная точка в IP, в телефонной сети или сразу в обеих. Метка передавалась без полного знания пути.

IP-среды тоже были неодинаковы. В заранее подготовленной сети можно менять маршрутизаторы и резервирование. Прозрачная сеть лишь переносит допустимые пакеты. Сеть, прозрачная для SIP/RTP, может блокировать RSVP или DSCP. Ограниченная сеть SIP может запретить новые элементы протокола. Рабочее решение не могло предполагать одну архитектуру оператора.

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

Одна метка поэтому могла вытеснить сеанс в одном месте и лишь предотвратить отбрасывание в другом. Если приоритетных запросов мало, короткое ожидание может быть безопаснее разрыва связи. В иной системе потребуется вытеснение. Такое расхождение было не ошибкой, а способом оставить решение рядом с его последствиями.

Остальные требования делали тонкий сигнал переносимым. Пространства имён должны были охватить национальные и частные схемы. Указание не зависело от оператора, архитектуры или адреса. Оно передавалось как допустимый SIP и работало с разными методами. При одинаковой схеме на концах CSN-IP-CSN перевод должен сохранять данные; при разных схемах RFC честно допускала потери.

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

Личность также не была полномочием. Один человек совершал обычные и приоритетные вызовы, а уровень выбирался по ситуации и человеческому суждению. RFC связывала аутентифицированную личность, выбор пользователя и политику. Поле From не давало постоянной привилегии, выбранная метка не доказывала право.

Безопасность стала частью конструкции. Злоумышленник мог занять именно те ресурсы, которые берегли для спасателей. Ранняя аутентификация ограничивала пакеты, вычисления и каналы, расходуемые неуполномоченным запросом. Узлы должны были самостоятельно проверять разрешение, не полагаясь на транзитивное доверие. Повтор, склейка и понижение уровня рассматривались отдельно.

Конфиденциальность создавала ещё один конфликт. Сотрудник мог пользоваться чужим устройством и не должен был раскрывать ему повторно используемый секрет. Сам факт запроса приоритета мог выдать чувствительные обстоятельства. Данные для маршрутизации и данные, защищаемые из конца в конец, имели разные границы. Указание и механизм аутентификации требовалось разделять.

Позднее RFC 4412 определила Resource-Priority и Accept-Resource-Priority. Пространство и значение выражали желаемый приоритет, а OPTIONS мог перечислить принимаемые значения. Но принятие не означало достаточности ресурсов или успеха. RFC 5115, 5478, 6401, 6735 и 8443 дополнили маршрутизацию, регистрацию, допуск и подтверждение полномочий, не превратив метку в итоговую квитанцию.

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

Различие Хэн Лу между символом и исполняемым контролем точно описывает этот замысел. Метка стала общей потому, что оставалась тонкой. Она переносила вопрос, но не присваивала власть над чужим ресурсом. RFC 3487 стандартизировала язык запроса и сохранила ответственность за ответ на каждой границе.

Источники