Кратко

  • RFC 3261 определил диалог сочетанием Call-ID, локального и удалённого тегов. У второго участника перспектива меняется: локальный тег одной стороны является удалённым для другой.
  • Один разветвлённый INVITE мог создать несколько ранних или подтверждённых диалогов. Они разделяли Call-ID и тег инициатора, а каждый ответивший добавлял отдельный To-tag.
  • Диалог переносил порядок, маршрут и цель в последующие транзакции. Его идентификатор связывал контекст, но не удостоверял человека и не доказывал доставку медиа.

Один адрес не означал одну связь

Слово «звонок» обещает единственное событие: выбрать адрес, дождаться ответа, поговорить с одним собеседником. Маршрутизация SIP допускала другое. Прокси мог направить один INVITE одновременно на настольный аппарат, программный клиент и шлюз. Звонили несколько устройств, и ответить могло больше одного.

Идентификатора первой транзакции для продолжения было мало. Транзакция сопоставляла запрос, его повторы и ответы в рамках одного обмена. Следующие ACK, пересогласование или BYE становились новыми транзакциями. Запрос мог инициировать любой участник; прокси могли потребовать сохранения маршрута; устройство — объявить новый контактный адрес.

SIP требовалось имя для сохраняемого контекста, а не только для одной работы с сообщениями.

В марте 1999 года RFC 2543 называл такую связь call leg и определял её сочетанием Call-ID, To и From. Проблема fork уже была понятна: если запрос мог попасть к нескольким UAS, каждый ответ получал To-tag, чтобы инициатор различил источники. Несколько ответов с разными тегами на один INVITE представляли отдельные ветви.

Однако модель всё ещё опиралась на адресные поля целиком. From-tag оставался необязательным, а построение Route и Record-Route было недостаточно полным. SIP 2.0 сохранил разветвление, но точнее очертил долговременное состояние.

Вызывающий задавал только половину имени

Опубликованный в июне 2002 года RFC 3261 заменил call leg на диалог: одноранговое отношение SIP между двумя пользовательскими агентами, сохраняющееся некоторое время. Оно предоставляет контекст для сообщений, упорядочивает оба направления и хранит сведения для дальнейшей маршрутизации.

У каждого UA dialog ID состоит из Call-ID, локального и удалённого тегов. Эти определения зависят от точки зрения. Локальный тег Alice является удалённым у Bob; локальный тег Bob — удалённым у Alice. Стороны разделяют два непрозрачных значения, но смотрят на них в противоположных направлениях.

Первый запрос содержит Call-ID и From-tag — половину идентификатора, как объясняет сам RFC. Способный создать диалог ответ добавляет To-tag. Для инициатора его From-tag становится локальным, полученный To-tag — удалённым; у ответившего ориентация обратная.

Такое распределение и решило fork. Все ветви наследовали Call-ID и тег инициатора, но каждый отвечающий терминал создавал свой To-tag. Вызывающий мог объединять родственную сигнализацию, не смешивая состояния разных участников.

Call-ID намеренно не был достаточен. Теги также не являлись именами или учётными данными. RFC 3261 потребовал глобальной уникальности и криптографической случайности не менее 32 бит. Это уменьшало неоднозначность контекста, но не удостоверяло Alice, не давало полномочий Bob и не подтверждало отображаемое имя.

Диалог появлялся ещё во время звонка

Для INVITE предварительный ответ 101–199 с To-tag создаёт early dialog. Инициатор уже может хранить состояние конкретного ответившего, хотя итог не решён. Ответ 2xx подтверждает соответствующий диалог. Ошибка или отсутствие успеха на ветви завершает раннее состояние по основным правилам.

При fork одновременно живут несколько early dialogs: одно устройство звонит, другое сообщает прогресс, третье отклоняет. Они делят вклад инициатора и различаются удалёнными тегами. Могут прийти несколько 2xx и создать несколько подтверждённых диалогов, которые приложение должно отдельно признать, а затем урегулировать.

PRACK решает соседнюю, но иную задачу. RSeq и RAck обеспечивают надёжность и порядок важных предварительных ответов; теги указывают, к какому peer-контексту они относятся. Надёжность действует внутри уже названного early dialog и не создаёт его имя.

Via branch также относится к другому слою. Он связывает транзакцию и её повторы. Тройка диалога сохраняется после завершения этой транзакции и входит в новые. Смешение либо слишком рано удалит связь, либо объединит разные запросы как один обмен.

За тройкой стояло исполняемое состояние

Диалог хранил не только три значения заголовков. RFC 3261 включил локальный и удалённый sequence number, URI сторон, remote target, secure flag и упорядоченный route set.

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

Route set хранит прокси, пожелавшие остаться на пути сигнализации. UAS берёт его из Record-Route запроса, UAC — из ответа в обратном порядке. Потоки RFC 3665 показывают тот же Call-ID и оба тега в ACK, BYE и ответах, тогда как Route удерживает выбранные прокси.

Remote target отвечает на другой вопрос: по какому Contact сейчас достижим участник? Он задаётся при создании диалога и может обновиться успешным target-refresh request. Для диалога INVITE RFC 3261 определил re-INVITE как основной механизм.

Новый Contact не меняет Call-ID с тегами и не переписывает route set. Тройка отвечает «какой контекст», маршрут — «через каких посредников», цель — «по какому текущему адресу». Разделение не позволило одному полю одновременно владеть корреляцией, политикой пути и мобильностью.

Сигнализация не была звуком

После установления любой участник может начать новую транзакцию. Отправитель становится для неё UAC, получатель UAS независимо от ролей в исходном INVITE. Долговременная связь симметричнее отдельного обмена клиент—сервер.

RFC 3264 передал согласование медиа модели SDP offer/answer. Предложения и ответы описывают потоки, кодеки, адреса и порты; контекст верхнего уровня вроде SIP связывает обмены. Последующие предложения могут добавлять, удалять и изменять медиа в том же диалоге.

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

RFC 4028 добавил согласуемые session timer и обновления re-INVITE либо UPDATE. Диалоги из одного INVITE могут иметь разные интервалы или не иметь таймера. Каждый refresh — новая транзакция в существующем контексте. Успех продлевает сеанс; отсутствие может привести к BYE. Тройка не даёт вечного права на состояние.

Один диалог мог нести несколько использований

Расширения опровергли и формулу «один диалог — один звонок». INVITE создаёт invite usage, а SUBSCRIBE или REFER внутри диалога способны добавить использования. RFC 5057 объясняет, что они делят Call-ID, теги, CSeq, route set, контакты, remote target и secure flag, сохраняя собственное состояние, например срок подписки.

Нормальное завершение одного использования не обязано стирать остальные. BYE может закончить invite usage, пока подписка на события продолжится; завершение подписки не всегда уничтожает приглашение. Диалог — общий контейнер сигнализации, а не единый срок жизни всех приложений.

RFC 6665 показывает границу на уведомлениях. SUBSCRIBE и NOTIFY используют состояние диалога, но Event участвует в сопоставлении конкретной подписки. Разветвлённый SUBSCRIBE может создать независимые диалоги с отдельным обновлением. Тройка находит общий контекст, но не служит полным ключом каждого использования.

Сила идентификатора заключалась в узости. Он называл peer-контекст, пока транзакции завершались, Contact перемещался, маршрут оставался, медиа менялись, а приложения добавляли состояние. Он не пытался идентифицировать всё это вместо собственных механизмов.