Кратко

  • URI в исходном списке — цель операции, выбранная создателем. Он не является удостоверением участника и не отменяет аутентификацию и правила допуска, которыми управляет focus.
  • Ответ 200 подтверждает создание конференции, участие отправившего UAC и понимание списка. Он не подтверждает исход приглашения, допуск, диалог или медиа ни для одной другой записи.
  • Расширение списка относится к первоначальному INVITE на URI фабрики. URI конференции из Contact — другой ресурс; список в re-INVITE не имеет определённой семантики и при Require получает 420.

Чужое имя не передаёт чужие полномочия

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

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

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

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

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

Такой подход не предполагает злоупотребление. Он просто не позволяет одной стороне расширить свою власть за пределы собственного действия.

Попытка вызова ещё не допуск

RFC 5366 ускоряет создание: клиент отправляет начальный набор вместе с первым INVITE, а сервер начинает добавление после появления конференции. Ускорение не делает операции атомарными.

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

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

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

Это особенно важно для обязательного участника. Если его адрес стоял в списке, а попытка не была создана, ответ фабрики не докажет, что ему предоставили возможность участвовать. Та же логика относится к кворуму, согласию и оплате.

У 200 ровно три утверждения

RFC прямо ограничивает ответ на исходный INVITE. Конференция создана успешно. UAC, отправивший INVITE, находится в ней. Сервер понял URI-список. Статус остальных пользователей этим кодом не сообщается.

«Понял» относится к формату и семантике входа сервиса. Это не гарантия, что каждая запись валидна, вся дополнительная структура сохранена или каждая операция завершена.

«Создана» относится к ресурсу конференции. Конференция с одним создателем всё равно существует. Последующий провал всех приглашений не меняет область первоначального ответа.

«UAC находится в конференции» относится к одному диалогу. Это не свойство списка. Интерфейс должен показывать отдельно conference_created, состояние создателя и счётчики по целям.

Иначе зелёная строка скрывает очередь. Быстрый 200 полезен, но только если асинхронные ветви остаются видимыми и связаны с исходной транзакцией.

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

Первоначальный INVITE может быть multipart и содержать SDP вместе со списком. SDP участвует в offer/answer между создателем и сервером. Список запускает приглашения другим пользователям.

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

Focus может допустить пользователя только с аудио. Сигнализация может завершиться, а RTP не пройти. Выбранные параметры не доказывают воспроизведение. Успешное видео создателя не характеризует остальных.

По каждому диалогу следует сохранять отпечатки SDP, результат offer/answer, контекст безопасности и наблюдение медиапути. Если система не видит клиентское воспроизведение, она не должна писать «услышал».

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

Фабрика и focus обслуживают разные ресурсы

Первый INVITE направляется на URI фабрики конференций. Ответ возвращает Contact с фактическим URI конференции и признаком focus. Дальнейший диалог адресуется новому ресурсу.

Фабрика поддерживает recipient-list-invite для операции создания. Нельзя переносить эту возможность на URI конференции только потому, что оба адреса обслуживаются одной системой.

Результат OPTIONS надо хранить вместе с точным URI, методом и временем. Флаг на уровне хоста создаёт ложную область поддержки.

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

Отказ URI конференции не опровергает поддержку стандарта фабрикой. Он может подтверждать правильную границу.

re-INVITE не повторяет создание

После установления диалога re-INVITE может изменять характеристики медиа между UAC и сервером. RFC 5366 не задаёт значения recipient-list в таком запросе и рекомендует клиенту не включать его.

Если клиент всё же требует recipient-list-invite, ресурс конференции отвечает 420 Bad Extension и перечисляет тег в Unsupported. Ответ говорит об операции на этом ресурсе. Он не сообщает об исчезновении конференции и не обязательно меняет существующие медиа.

Удалить Require и повторить недостаточно. Требование понимания исчезнет, но семантика добавления участников не появится. Отправка к фабрике может создать новую конференцию.

Восстановление начинается с выбора намерения. Для существующей конференции применяется определённый RFC 4579 механизм добавления. Для новой — новая фабричная операция. Для изменения медиа — re-INVITE без списка.

Журнал должен отражать изменение типа операции. Называть всё одним retry мешает доказать идемпотентность и обнаружить дубликаты конференций.

Состояние конференции — последующее наблюдение

Для статуса остальных пользователей RFC 5366 указывает на общие механизмы, включая event package RFC 4575. Уведомления описывают состояние, которое представляет focus после попыток и решений.

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

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

Полезно хранить три множества: запрошенные цели, операции и решения focus, наблюдаемое состояние. Различия объясняют нормализацию, отказ, политику и изменение во времени.

Запись в состоянии всё равно не доказывает внимание человека, полезные медиа или вклад в решение. Она подтверждает только представление focus в определённой версии.

Понятый список может быть упрощён

RFC 4826 допускает иерархию и относительные ссылки XCAP. Сервис RFC 5366 нуждается только в плоском списке. Клиенту рекомендуется не использовать лишние возможности, а фабрика может отбросить дополнительную информацию.

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

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

Граница исследования

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

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