Кратко

  • RFC 3326 позволил запросу SIP нести причину отправки: код состояния SIP или значение причины Q.850 при взаимодействии с телефонной сетью.
  • Заголовок не меняет обработку SIP. CANCEL по-прежнему отменяет вызов, а Reason может сообщить, что разговор уже состоялся в другой ветви.

Одна ветвь ответила — остальные всё равно нужно было остановить

Прокси направляет INVITE по нескольким ветвям. Один адресат отвечает 200 OK, но остальные телефоны могут продолжать звонить. Тогда прокси отправляет им CANCEL. Сигнализацию прекращает метод SIP CANCEL, а не заголовок с объяснением.

Опубликованный в декабре 2002 года RFC 3326 дал прокси способ приложить такую пояснительную информацию: Reason: SIP;cause=200;text="Call completed elsewhere". Получающий сервис может отличить ответ в другой ветви от вызова, оставленного до ответа. Это может изменить журнал пропущенных вызовов или интерфейс, хотя непосредственное протокольное действие не меняется.

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

Причина принадлежит пространству конкретного протокола

RFC 3326 определяет пространство значений через имя протокола. SIP означает, что параметр cause содержит код состояния SIP; Q.850 указывает на десятичное значение причины из телефонной сигнализации ITU-T. Так шлюз может перенести причину освобождения вызова из телефонной сети в сообщение SIP. Одного числа недостаточно: метка протокола указывает систему нумерации.

Параметр text удобен для людей, но не управляет обработкой. Причина берётся из словаря указанного протокола, тогда как метод, состояние и контекст транзакции задаются самим сообщением. Если прочитать cause=200 как ответ или значение Q.850 как статус SIP, две разные плоскости управления будут смешаны.

Понимание этого поля всеми реализациями также не гарантировано. RFC 3326 разрешает игнорировать неизвестные значения и прямо говорит, что Reason не влияет на протокольную обработку. Даже если конечная система отбросит объяснение, запрос всё равно обрабатывается по правилам SIP. Расширение помогает логике сервисов, но не становится скрытым условием базового состояния вызова.

Ответ, который может скрыть разветвление

Документ также связал Reason с проблемой неоднородных ответов об ошибках при разветвлении. Разные ветви INVITE могут вернуть разные окончательные ошибки. Прокси обычно ждёт результаты ветвей, прежде чем решить, что передать инициатору; пока другая ветвь остаётся незавершённой, полезная ошибка может быть скрыта. RFC 3326 указал возможное применение Reason — вложить окончательный статус в предварительный ответ.

Оговорка существенна: это предложенный механизм, а не гарантия видимости всех ошибок в каждом разветвлении и не свидетельство, что внедрённый сервис решил проблему. Заголовок даёт контейнер для причины; он не задаёт универсальный порядок приоритета ошибок и не заменяет обработку ответов SIP.

Последующие расширения сохранили границу

Позднее RFC 8606 добавил к причинам Q.850 параметр местоположения ISUP, позволяющий сохранить место освобождения вызова, если оно известно. RFC 9366 изменил прежнее правило «одно значение на протокол» лишь для зарегистрированных протоколов, которые определяют смысл нескольких значений. Оба расширения уточняют происхождение, но не превращают Reason в само действие.

Это полезно и для истории протоколов. RFC 3087 рассматривал Request-URI как локальный контекст выбора сервиса; RFC 3326 прикрепил причину к уже выбранному действию SIP. Первый задавал адрес назначения запроса, второй пояснял его отправку. Ни тот ни другой не доказывает аутентификацию, разрешение доступа, всю историю вызова или последующий результат.

Источники

  1. https://www.rfc-editor.org/rfc/rfc3326.html
  2. https://www.rfc-editor.org/info/rfc3326/
  3. https://www.rfc-editor.org/rfc/rfc3261.html
  4. https://www.rfc-editor.org/rfc/rfc9366.html
  5. https://www.rfc-editor.org/rfc/rfc8606.html
  6. https://www.rfc-editor.org/rfc/rfc5411.html
  7. https://www.rfc-editor.org/rfc/rfc4411.html