Кратко

  • RFC 3326 позволил переносить протокольную причину запроса отдельно от самого действия, чтобы одинаковые CANCEL или BYE сохраняли различие между породившими их событиями.
  • Reason не менял обработку SIP и мог быть проигнорирован; его значения требовали явного пространства протокола, правил множественности, происхождения, преобразования и проверки целостности.

Несколько причин не образовывали обычный список

Reason был спроектирован как набор типизированных значений. Каждое начиналось с названия protocol, за которым могли идти числовой cause, человекочитаемый text и расширения. SIP-коды и причины Q.850 принадлежали разным системам. Число без названия протокола не сохраняло смысл.

Изначально сообщение могло нести несколько Reason только при разных protocol: например, один SIP и один Q.850. Это позволяло одновременно сохранить интерпретации двух систем, не делая вид, что их числа лежат в общей шкале.

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

Эта поправка раскрывает более широкую проблему доказательств. Формат способен перенести несколько утверждений, но синтаксис не говорит, как их объединить. Семантика приходит из реестра IANA и документа протокола. Архив должен сохранить не только список, но и правила, по которым его понимали в момент обработки.

Одинаковая отмена скрывала разные события

Исходный пример был бытовым. Прокси отправлял INVITE на несколько устройств. Одно отвечало 200 OK, после чего остальные ветви получали CANCEL. Если звонивший просто прекращал попытку до ответа, они также получали CANCEL. Телефон переставал звонить одинаково.

История вызовов должна была различаться. Ответ на другом устройстве не обязательно является пропущенным вызовом. Отказ до ответа может им быть. CANCEL сообщал действие, но не причину. Прокси мог добавить SIP cause 200 и смысл «вызов завершен в другом месте», сохранив основание для правильного интерфейса.

Reason разрешался в любом запросе внутри диалога, в любом CANCEL и в ответе, код которого явно допускал поле. Клиент мог получить неприемлемое предложение в успешном ответе, корректно отправить ACK, затем завершить BYE с причиной 488. Контроллер третьей стороны мог увидеть занятость B и закрыть диалог A с причиной 486. Шлюз мог породить SIP-действие после сообщения другого протокола.

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

Возможность игнорировать ограничивала силу утверждения

RFC 3326 прямо разрешал клиентам и серверам игнорировать Reason и утверждал, что поле не влияет на протокольную обработку. CANCEL оставался отменой без причины. BYE завершал диалог, даже если получатель не знал protocol.

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

Параметр text не исправляет ограничение. Он облегчает чтение, но может быть переведен, сокращен или ошибочно написан. Структурный смысл сохраняют protocol и cause. Надежная система хранит исходный текст отдельно и не делает его ключом агрегации.

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

Перевод из телефонной сети создавал новую версию факта

RFC 3398 описал отображение ISUP в SIP. Получив сообщение освобождения, шлюз мог создать CANCEL и включить принятую причину Q.850. SIP-сторона узнавала больше, чем сам факт остановки ветви.

RFC 6432 позволил переносить Q.850 в SIP-ответах, кроме 100 Trying. RFC 8606 добавил location, если место освобождения ISUP было доступно. Оно обозначает общий участок сети—локальный, транзитный или удаленный,—а не физическое место или личность участников.

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

History-Info из RFC 7044 и исторический Diversion из RFC 5806 описывают перенаправления. Reason отвечает, почему конкретный запрос или допустимый ответ появился. Маршрут и причина могут дополнять друг друга, но не заменяют: перечень целей не доказывает освобождение, а код освобождения не реконструирует маршрут.

Цепочка копий сохраняла и ошибку

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

Но последняя копия выглядит так же аккуратно, как первоначальное наблюдение. Узел мог просто пересказать соседа. Посредник мог заменить text, потерять расширение или неверно преобразовать cause. Журналам нужно различать наблюдение, создание, перевод и ретрансляцию.

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

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

RFC 3326 оставил исторически важную модель: действие, объяснение и доказательство—три разные вещи. SIP мог выполнить действие без объяснения. Reason мог сохранить объяснение без гарантии истины. А доказательство требовало дополнительной цепочки источников, преобразований и решений.

Источники