Кратко

  • В RFC 2543 параметр branch прежде всего различал копии запроса после разветвления на прокси. RFC 3261 сделал его обязательным и, кроме оговорённых случаев, уникальным во времени и пространстве.
  • z9hG4bK — не секрет и не доказательство полномочий. Этот префикс указывает на новое правило генерации и позволяет применить короткое сопоставление вместо многополевого старого алгоритма.
  • Повторная передача сохраняет branch, новый маршрутный заход получает новый. CANCEL и ACK после неуспешного финального ответа намеренно используют прежнее значение, чтобы попасть в нужное состояние.

Сначала branch различал копии, а не все транзакции

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

Параметр branch существовал уже в RFC 2543, но обещал немногое. Если прокси разветвлял запрос на несколько одинаковых копий, он должен был дать им разные значения в пределах этого разветвления. Прокси без fork мог параметр не добавлять.

Поэтому произвольный branch ещё не был единым именем транзакции. Для сопоставления использовались также To, From, Call-ID, CSeq и верхний Via. Механизм работал, однако сервер не мог по одному токену заключить, что тот создан по общей и долговременной норме уникальности.

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

RFC 3261 поместил смену правил внутрь значения

В 2002 году RFC 3261 изменил договор. Клиент пользовательского агента обязан был ставить Via в начало каждого запроса, а в Via обязательно присутствовал branch. За несколькими точно описанными исключениями значение должно было быть уникальным во времени и пространстве для всех запросов этого клиента.

Новый branch начинался с z9hG4bK. Семь символов выбрали потому, что реализация RFC 2543 едва ли породила бы их случайно. В префиксе нет даты, производителя, маршрута или пользовательской личности. Он лишь утверждает, что остальная часть значения сформирована по правилу RFC 3261.

Название «magic cookie» сегодня легко принять за cookie браузера, пароль или случайный криптографический вызов. Здесь это всего лишь свидетель версии. Оно находится прямо в поле, смысл которого поменялся, и позволяет получателю выбрать алгоритм локально, не обращаясь к реестру «современных» устройств.

Более сильное обещание позволило сократить проверку

Если cookie присутствует, серверная транзакция сопоставляет branch верхнего Via, его sent-by и метод. Для ACK есть узкое исключение: подтверждая финальный ответ не 2xx, он относится к искомой INVITE-транзакции. sent-by всё равно нужен, поскольку два клиента могут повторить один branch случайно или намеренно.

Если префикса нет, сервер не приписывает отправителю новое обещание задним числом. Он возвращается к совместимой с RFC 2543 процедуре и сравнивает Request-URI, теги, Call-ID, CSeq и верхний Via. Два множества совместимости сосуществуют, но не смешиваются без признака.

Для ответа важны branch верхнего Via и метод CSeq. Метод нельзя отбросить: CANCEL использует branch отменяемого запроса, оставаясь самостоятельной транзакцией. Токен сужает поиск, но не заменяет смысл соседних полей.

Сценарии RFC 3665 показывают область действия наглядно. Каждый прокси добавляет собственные Via и branch на прямом пути, а соответствующий слой снимается при возврате ответа. Это локальный идентификатор между соседними клиентской и серверной транзакциями, не глобальное имя звонка.

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

Прокси с состоянием создаёт новый branch для каждой исходящей попытки. Если первая цель недоступна и выбирается другой адрес, возникает другая клиентская транзакция. Если запрос вернулся к тому же прокси после изменения существенных входов обработки, это может быть допустимая спираль, а не петля; реализация с loop detection может включить такие входы в отделимую часть значения.

Повторная передача устроена наоборот. Это ещё одна копия той же попытки, поэтому branch должен совпасть. Тогда сервер найдёт сохранённое состояние и повторит уже подготовленный ответ вместо второго выполнения операции.

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

CANCEL делит путь идентичности, но не результат

CANCEL должен найти именно тот ожидающий запрос по тому же маршруту между узлами. Он копирует Request-URI, Call-ID, теги, номер CSeq, верхний Via и branch, меняя метод CSeq на CANCEL. Благодаря этому даже stateless-прокси способен повторить маршрутное решение.

Однако CANCEL образует собственную транзакцию. Сервер может ответить на неё 200, а исходный INVITE отдельно завершить ответом 487 или другим финальным статусом. Возможно, финальный ответ успел прийти до отмены. Успех CANCEL означает, что запрос отмены распознан и принят в обработку; он не переписывает задним числом исход INVITE.

RFC 3261 явно развёл эти жизненные циклы после более тесной модели RFC 2543. Общий branch даёт корреляцию с целью, но не общую судьбу.

Класс финального ответа разделил два вида ACK

ACK на финальный ответ не 2xx остаётся внутри INVITE-транзакции. Он повторяет верхний Via и branch, меняет метод и поглощается автоматом состояния. Та же цепочка прокси, которая провела неудачу, прекращает её повторы.

После 2xx граница проходит иначе. Разветвление может породить несколько принятых диалогов, и каждый успешный результат должен дойти до вызывающей стороны. Ядро пользовательского агента отправляет ACK из конца в конец по маршруту диалога и строит новый Via с новым branch. Такой ACK находится вне исходной поузловой INVITE-транзакции.

Разница не формальна. Старый branch позволяет существующему состоянию остановить повторы одной неудачи. Новый обмен для успеха не даёт промежуточной транзакции скрыть подтверждение другого принятого адресата.

Поздние исправления изменили срок жизни состояния, не его ключ

Хорошая идентичность не исправила все ошибки автоматов. RFC 4320 уточнил поведение ответов и таймеров для транзакций не INVITE. Позже RFC 6026 добавил состояние Accepted и Timer L, чтобы сервер сохранял достаточно состояния INVITE после отправки 2xx и поглощал повторы.

RFC 6026 также оставил специальную обработку старого ACK, в branch которого нет cookie RFC 3261. Это подтверждает долговечность маркера: время хранения можно исправить, но получатель всё равно должен знать, какие допущения об идентичности реально обеспечил отправитель. RFC 5359 показывает более поздние сервисные сценарии с той же конвенцией; это свидетельство специфицированной грамматики, а не перепись работающих продуктов.

Чего семь символов никогда не доказывали

Напечатать z9hG4bK способен любой отправитель. Строка не аутентифицирует пользователя, не разрешает звонок, не защищает целостность и не доказывает реальную уникальность суффикса. TLS может защитить один сетевой участок, digest authentication — подтвердить заявление об учётных данных, а локальная политика — принять или отклонить запрос. Branch не обладает этими полномочиями.

Транзакция также не равна диалогу. Call-ID и теги описывают отношения диалога, route set направляет последующие запросы, а согласование медиа и RTP хранят другое состояние. Правильное совпадение branch доказывает только принадлежность сообщения выбранной локальной транзакции.

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

Источники и пределы вывода

Закрытый набор источников включает RFC 2543, RFC 3261, RFC 3665, RFC 4320, RFC 5359 и RFC 6026. Они подтверждают историю норм, правила сопоставления, примеры и поздние исправления. Они не доказывают нынешнюю долю развёртываний, соответствие конкретных продуктов, качество связи или отсутствие коллизий на практике.