Сервер "присутствия" в среде мультимедиа на основе интернет-протокола

Сервер "присутствия" в среде мультимедиа на основе интернет-протокола

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Настоящее изобретение относится к системной архитектуре в среде с коммутацией пакетов и более конкретно к реализации в такой архитектуре средств для обеспечения информации о "присутствии" пользователя.

УРОВЕНЬ ТЕХНИКИ

В сетях подвижной связи третьего поколения (3П, 3G) услуги предоставляются через сети, использующие межсетевой протокол, или Интернет-протокол (ИП, IP), что приводит к интеграции приложений для передачи речи и данных. Одним из главных кандидатов на появление новых услуг, основанных на IP, является предоставление информации о "присутствии" пользователя. "Присутствие" определяют как подписку в состоянии связей пользователя и уведомление об изменениях в состоянии связей пользователя. Это состояние связей состоит из следующего: средства связи, адреса связи и статуса пользователя.

В сетях третьего поколения управление вызовом и среда создания услуг основаны на Протоколе инициации сеанса (ПИС, SIP), как описано в документе «Проект партнерства систем 3-го поколения, Группа по техническим спецификациям услуг и системных вопросов, Подсистема IP-мультимедиа - стадия 2, 3G TS 23.228 версия 1.7.0, Февраль 2001 г.».

Документ Комитета инженерной поддержки сети Интернет, Интернет-проект, draft-rosenberg-impp-presence-o1.txt, авторов Розенберг и др., опубликованный 2-го марта 2001 г., содержимое которого включено в состав настоящего документа путем ссылки на Приложение А, предлагает расширение к SIP для подписок и уведомлений "присутствия" пользователя. "Присутствие" пользователя определяют как готовность и способность пользователя взаимодействовать с другими пользователями по сети. Исторически "присутствие" было ограничено индикаторами "on-line" ("интерактивно") и "off-line" ("автономно"). Понятие "присутствия" согласно документу авторов Rosenberg и др. является более широким. Подписки и уведомления "присутствия" пользователя поддерживают с помощью определения пакета событий в рамках используемой SIP общей схемы уведомления о событиях. Этот протокол согласован также со схемой общего "присутствия" и обмена немедленными сообщениями (ОПОНС). Однако такое предложение не включает в себя какое-либо рассмотрение сред мультимедиа.

Расширение SIP, определенное в документе Rosenberg и др., основано на концепции агента "присутствия" (АП), который является новым логическим объектом, способным принять подписки (через сообщения SUBSCRIBE (Подписать)), сохранить состояние подписки и генерировать уведомления (через сообщения NOTIFY (Уведомить)) при наличии изменений в "присутствии" пользователя.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

Настоящее изобретение относится к стандартизации согласно версии 5/6 ПП3П (Проекта партнерства систем 3-го поколения).

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

Среда с коммутацией пакетов является предпочтительно средой мультимедиа, использующей Интернет-протокол, и предпочтительно подсистемой сети с передачей данных, полностью основанной на ИП (ОИП, all-IP).

В первом варианте осуществления функция управления состоянием вызова запроса (ФУСВ-З, I-CSCF) обновляет информацию о "присутствии" в сервере "присутствия" посредством разветвления входящего сообщения REGISTER.

Во втором варианте осуществления функция управления состоянием вызова обслуживания (ФУСВ-О, S-CSCF) действует в качестве агента "присутствия" и сервер "присутствия" обеспечивает задачу сохранения информации об абонентах.

В третьем варианте осуществления сервер "присутствия" в подсистеме мультимедиа, использующей Интернет-протокол (Интернет-мультимедиа, ИМ, IM), действует в качестве агента "присутствия" и функция управления состоянием вызова обслуживания (ФУСВ-О) использует отдельную транзакцию REGISTER для обновления информации о "присутствии" в сервере "присутствия".

Таким образом, изобретение решает задачу маршрутизации сообщений REGISTER (Регистрировать), SUBSCRIBE и NOTIFY в использующей Интернет-протокол подсистеме мультимедиа (ИМ).

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Изобретение далее будет описано посредством ссылки на прилагаемые чертежи, на которых:

Фиг.1 - архитектура по версии 5 ПП3П, в которой воплощено настоящее изобретение;

Фиг.2 - последовательность сообщений REGISTER в первом варианте осуществления настоящего изобретения;

Фиг.3 - последовательность сообщений SUBSCRIBE в первом варианте осуществления настоящего изобретения;

Фиг.4 - последовательность сообщений NOTIFY в первом варианте осуществления настоящего изобретения;

Фиг.5 - последовательность сообщений SUBSCRIBE во втором варианте осуществления настоящего изобретения;

Фиг.6 - последовательность сообщений NOTIFY во втором варианте осуществления настоящего изобретения;

Фиг.7 - последовательность сообщений REGISTER в третьем варианте осуществления настоящего изобретения;

Фиг.8 - последовательность сообщений SUBSCRIBE в третьем варианте осуществления настоящего изобретения; и

Фиг.9 - последовательность сообщений NOTIFY в третьем варианте осуществления настоящего изобретения.

ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

В настоящем изобретении сервер "присутствия" помещен в подсистему Интернет-мультимедиа архитектуры, предложенной ПП3П и соответствующей 5 версии, как часть "глобальной сети приложений и услуг". Подсистема мультимедиа, использующая Интернет-протокол, обращается ко множеству элементов базовой сети, которые используют услуги, обеспечиваемые доменом с коммутацией пакетов согласно архитектуре ПП3П, соответствующей 5 версии и предназначенной для предоставления мультимедийных услуг. Элементами подсистемы мультимедиа, использующей Интернет-протокол, являются функция управления состоянием вызова (ФУСВ CSCF), функция управления медиа-шлюзом (ФУМШ (MGCF), функция медиа-ресурсов (ФМР, MRF) и некоторые составляющие для адаптации. Представление расширенной архитектуры показано на Фиг.1.

Фиг.1 основана на базовой архитектуре ПП3П в соответствии с архитектурой, определенной в документе «Проект партнерства систем 3-го поколения, Группа по техническим спецификациям услуг и системных вопросов; Архитектура для сети с общим ИП; 3П (3G) TO (TR) 23.922 версия 1.0.0; Октябрь 1999», содержимое которого включено в состав настоящего документа путем ссылки в качестве Приложения В. Однако архитектура, раскрываемая в настоящем документе, изменена, как показано на Фиг.1, с тем, чтобы включить в ее состав сервер "присутствия" в соответствии с настоящим изобретением.

Конкретно настоящее изобретение касается последовательностей сообщений REGISTER, SUBSCRIBE и NOTIFY в сети ПП3П.

Настоящее изобретение далее будет описано с дополнительными подробностями со ссылками на три иллюстративных варианта осуществления последовательностей сообщений REGISTER, SUBSCRIBE и NOTIFY. Следует отметить, что только необходимые фрагменты сети и последовательностей сообщений, требуемые для пояснения принципа действия настоящего изобретения, описаны в последующих примерах.

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

Маршрутизация сообщений REGISTER/SUBSCRIBE/NOTIFY для первого варианта осуществления описана ниже в настоящем документе со ссылками на Фиг.2 - Фиг.4.

В первом варианте осуществления функция управления состоянием вызова запроса (ФУСВ-З) обновляет информацию о "присутствии" в сервере "присутствия" посредством разветвления входящего сообщения REGISTER.

Первая сеть соответствует визитной сети пользовательского агента "присутствия" (ПАП, PUA) и включает в себя пользовательское оборудование (ПО, UE) 200 и функцию (202) управления состоянием вызова посредника (ФУСВ-П). Первая сеть является также сетью агента "присутствия".

Вторая сеть соответствует домашней сети пользовательского агента "присутствия" (ПАП) и включают в себя функцию 204 управления состоянием вызова запроса (ФУСВ-З), домашний сервер 206 абонента (ов), (ДСА, HSS), функцию 208 управления состоянием вызова обслуживания (ФУСВ-О), и сервер 210 "присутствия" (СП).

Третья сеть соответствует домашней сети абонента и включают в себя ПО абонента 212, первую функцию 214 управления состоянием вызова посредника (ФУСВ№1-П), первую функцию 216 управления состоянием вызова обслуживания (ФУСВ№1-О), функцию 218 управления состоянием вызова запроса (ФУСВ-З), ДСА 220, вторую функцию 222 управления состоянием вызова обслуживания (ФУСВ№2-О) и вторую функцию 224 управления состоянием вызова посредника (ФУСВ№2-П).

На фиг.2 представлена расширенная последовательность сообщений регистрации, соответствующая первому варианту осуществления настоящего изобретения.

Как показано, посредством этапа 230 маршрутизация сообщения REGISTER, инициированного пользовательским оборудованием 200, имеет место между ПО 200, ФУСВ-П 202 первой сети и ФУСВ-З 204 второй сети. Имя сервера 210 "присутствия" является частью абонентского профиля и имя сервера извлекают из ДСА 206 посредством ФУСВ-З 204 на этапе 232. На этапе 234 ФУСВ-З 204 выбирает ФУСВ-О для инициации сеанса и такой функцией в приведенном примере является ФУСВ-О 208.

Как представлено сообщениями 236 и 238, ФУСВ-З 204 разветвляет входящее сообщение REGISTER таким образом, что в соответствии с настоящим изобретением его направляют как к ФУСВ-О 208, так и к СП 210. После этого передают сообщения "200 Успешно" обратно к ПО 300 по обратному маршруту.

На фиг.3 представлена маршрутизация последовательности сообщений SUBSCRIBE, соответствующая первому варианту осуществления настоящего изобретения.

Как представлено сообщениями 240, 242 и 244, сообщение SUBSCRIBE маршрутизируют к ФУСВ-З 204 от абонента 212 ПО через ФУСВ№1-П 214 и ФУСВ№1-О 216.

Как представлено сообщением 246, ФУСВ-З 204 маршрутизирует принятое сообщение SUBSCRIBE непосредственно к СП 210. После этого маршрутизируют сообщения "202 Принято" обратно к абоненту ПО по обратному маршруту.

На фиг.4 представлена маршрутизация последовательности сообщений NOTIFY от сервера 210 "присутствия", соответствующая первому варианту осуществления настоящего изобретения.

Как представлено сообщением 248, сервер 210 "присутствия" пересылает сообщение NOTIFY к ФУСВ-З 218. Следуя локальному запросу к ДСА 220 на этапе 249, ФУСВ-З, как это представлено сообщениями 250, 252 и 254, пересылает сообщение NOTIFY к абоненту 226 ПО через ФУСВ№2-О 222 и ФУСВ№2-П 224. Таким образом, СП 210 посылает сообщение NOTIFY непосредственно к ФУСВ-З 218 других сетей. Еще раз сообщения "200 Успешно" маршрутизируют обратно к СП 210 по обратному маршруту.

Таким образом, первый вариант осуществления устанавливает следующие новые требования к элементам сети, размещенным в архитектуре:

1. ФУСВ-З загружает (часть) пользовательского профиля из ДСА для того, чтобы найти абонентский сервер "присутствия".

2. ФУСВ-З разветвляет входящее сообщение REGISTER от ПАП к ФУСВ-О и к серверу "присутствия".

3. ФУСВ-З маршрутизирует входящие запросы REGISTER непосредственно к серверу "присутствия".

4. Сервер "присутствия" посылает исходящие сообщения NOTIFY непосредственно к ФУСВ-З других сетей.

Маршрутизация сообщений SUBSCRIBE/NOTIFY в соответствии со вторым вариантом осуществления настоящего изобретения описана ниже со ссылкой на Фиг.5 и 6.

Поскольку ФУСВ-З сохраняет абонентский профиль и информацию о контактах, поставляемую в сообщении REGISTER, то простым решением является действие ФУСВ-О в качестве агента "присутствия". Одной возможной проблемой при таком решении является то, что ФУСВ-О должна была бы хранить информацию о всех абонентах и генерировать сообщения NOTIFY ко всем из них.

Следовательно, во втором описываемом варианте осуществления задачу сохранения информации о каждом из абонентов обеспечивает вновь введенный сервер "присутствия". Для ФУСВ-О достаточно принимать только первое сообщение SUBSCRIBE для "представительности", поскольку оно будет генерировать сообщение NOTIFY для одной подписки, и это сообщение NOTIFY будет разветвлено к абонентам посредством прокси-сервера, который имеет информацию об абонентах.

Последовательность регистрации при таком решении соответствует нормальной регистрации, как это определено в документе 3G TS 23.228 версии 1.7.0 от Февраля 2001 года, обсуждаемого выше.

Маршрутизация сообщений SUBSCRIBE/NOTIFY, соответствующая второму варианту осуществления настоящего изобретения, описана ниже со ссылкой на Фиг.5 и 6. Элементы первой, второй и третьей сети, соответствующие элементам, показанным на Фиг.2 - Фиг.4, обозначены на Фиг. 5 и 6 с использованием одинаковых ссылочных позиций.

В дополнение к элементам, показанным на фиг.2-фиг.4, третья сеть, соответствующая домашней сети абонента, включает в себя двух абонентов пользовательского оборудования абон№1 302 ПО и абон№2 304 ПО. Более того, вторая сеть, соответствующая домашней сети ПАП, включает в себя вторую функцию ФУСВ№2-О 306 управления состоянием вызова обслуживания.

На фиг.5 представлена маршрутизация последовательности сообщений SUBSCRIBE, соответствующая варианту осуществления настоящего изобретения.

Сообщение SUBSCRIBE от первого абонента 302 пользовательского оборудования пересылают к ФУСВ№1-П 214, как показано сообщением 308а. Такое сообщение пересылают, в свою очередь, к ФУСВ№1-О 216 и ФУСВ-В 204, как показано сообщениями 310а и 312а. Следуя локальному запросу на этапе 313а, сообщение SUBSCRIBE пересылают к СП 210, как представлено сообщением 314а. Следуя за этим, сообщение SUBSCRIBE пересылают от СП 210 к ФУСВ№2-О 306, как представлено сообщением 316.

В ответ на сообщение 316 SUBSCRIBE от сервера 210 "присутствия", соответствующее первому абоненту 302 пользовательского оборудования, относящегося к третьей сети, ФУСВ№2-О возвращает сообщение подтверждения приема посредством сигнала о принятии, как представлено стрелкой 318.

Подобным образом сообщение SUBSCRIBE от второго абонента 304 пользовательского оборудования пересылают к ФУСВ№1-П 214, как проиллюстрировано сообщением 308b. Такое сообщение пересылают, в свою очередь, к ФУСВ№1-О 216 и к ФУСВ-В 204, как проиллюстрировано сообщениями 310b и 312b. Следуя локальному запросу на этапе 313b, сообщение SUBSCRIBE пересылают к СП 210, как представлено сообщением 314b.

Для сервера 210 "присутствия" нет необходимости пересылать какое-либо из последующих сообщений SUBSCRIBE от пользовательского оборудования третьей сети, поскольку ФУСВ№2-О уже поставила подтверждение об успешном приеме.

Сигналы о принятии для каждого из пользовательских абонентов возвращают соответствующим абонентам по обратным маршрутам в ответ на прием сообщения 318 и соответствующего сообщения 314 SUBSCRIBE.

На Фиг.6 представлена маршрутизация последовательности сообщений NOTIFY от сервера 210 "присутствия", соответствующая варианту осуществления настоящего изобретения.

Как представлено сообщением 320, одиночное сообщение NOTIFY пересылают от ФУСВ№1-О к серверу 210 "присутствия".

Как представлено сообщением 322а, сервер "присутствия" затем пересылает первое сообщение NOTIFY к ФУСВ-З 218. Следуя первому локальному запросу 324а, первое сообщение NOTIFY пересылают к первому абоненту 302 пользовательского оборудования, в свою очередь, через ФУСВ№2-О 222 и ФУСВ№2-П 224, как представлено сообщениями 326а, 328а и 330а.

Сервер "присутствия", как представлено сообщением 322b, также пересылает второе сообщение NOTIFY к ФУСВ-О 218. Следуя второму локальному запросу 324b, второе сообщение NOTIFY пересылают к первому абоненту 302 пользовательского оборудования, в свою очередь, через ФУСВ№2-О 222 и ФУСВ№2-П 224, как представлено сообщениями 326b, 328b и 330b.

Сообщения "200 Успешно" возвращают к серверу 210 "присутствия" по обратному маршруту, и одиночное сообщение "Успешно" пересылают к ФУСВ№1-О.

Маршрутизация сообщений REGISTER/SUBSCRIBE/NOTIFY, соответствующая третьему варианту осуществления настоящего изобретения, описана ниже со ссылкой на Фиг.7 - Фиг.9.

Решение, описанное в третьем варианте осуществления, может быть подытожено как следующее: сервер "присутствия" в подсистеме мультимедиа, использующей Интернет-протокол, действует как агент "присутствия", и ФУСВ-О использует отдельную транзакцию REGISTER для обновления информации о "присутствии" в сервере "присутствия".

Маршрутизация методов REGISTER/SUBSCRIBE/NOTIFY описана далее ниже со ссылкой на Фиг.7 - Фиг.9. Элементы первой, второй и третьей сети, соответствующие элементам, показанным на Фиг.2 - Фиг.6, обозначены на Фиг. 5 и 6 с использованием одинаковых ссылочных позиций.

На фиг.7 представлена расширенная последовательность сообщений регистрации, соответствующая третьему варианту осуществления настоящего изобретения.

Как представлено этапом 230, маршрутизация сообщения REGISTER имеет место между ПО 200, ФУСВ-П 202 первой сети и ФУСВ-З 204 второй сети.

После этого на этапе 702 ФУСВ-З 204 выбирает ФУСВ-О 208 для инициации сеанса и такой функцией в приведенном примере является ФУСВ-О 208.

Как представлено сообщением 704, сообщение REGISTER затем пересылают к ФУСВ-О 208.

Имя сервера 210 "присутствия" является частью абонентского профиля и имя сервера извлекают из ДСА 206 посредством ФУСВ-З 204 на этапе 708.

После успешной инициации с помощью ФУСВ-О 208 сообщение "200 Успешно" передают к ПО 200 по обратному маршруту. После этого, как представлено сообщением 710, сообщение REGISTER пересылают к серверу 210 "присутствия". Сообщение 710 образует отдельную транзакцию, с помощью которой ФУСВ-О обновляет в СП информацию о "присутствии".

Если обновление "присутствия" на сервере "присутствия" завершается неуспешно, то ФУСВ-О генерирует уведомление к ПО 200, указывающее событие неуспешного завершения обновления "присутствия". Для такого уведомления может быть использовано сообщение SIP NOTIFY, например, содержащее заголовок события с кодом причины неуспешного завершения для нового "присутствия". Такой пример, помеченный как 711, показан на Фиг.7. Затем NOTIFY подтверждают элементы от ПО 200 до ФУСВ-О 208, используя сообщение "200 Успешно".

На фиг.8 представлена маршрутизация последовательности сообщений SUBSCRIBE, соответствующая третьему варианту осуществления настоящего изобретения.

Сообщение SUBSCRIBE от абонента 212 пользовательского оборудования пересылают к ФУСВ№1-П 214, как проиллюстрировано сообщением 712. Такое сообщение пересылают, в свою очередь, к ФУСВ№1-О 216 и к ФУСВ-З 204, как проиллюстрировано сообщениями 714 и 716. Следуя локальному запросу на этапе 718, сообщение SUBSCRIBE пересылают к ФУСВ№2-О 306, как представлено сообщением 720. Следуя за этим, сообщение SUBSCRIBE пересылают от ФУСВ№2-О к СП 210, как представлено сообщением 720. После этого сообщение "200 Принято" посылают по обратному маршруту.

На фиг.9 представлена маршрутизация последовательности сообщений NOTIFY от сервера 210 "присутствия", соответствующая третьему варианту осуществления настоящего изобретения.

Как представлено сообщением 722, сообщение NOTIFY пересылают от сервера 210 "присутствия" к ФУСВ№1-О 306. Как представлено сообщением 724, затем ФУСВ№1-О 306 пересылает NOTIFY к ФУСВ-З 218. Следуя локальному запросу на этапе 726, сообщение NOTIFY пересылают к абоненту 226 пользовательского оборудования, в свою очередь, через ФУСВ№2-О 222 и ФУСВ№2-П 224, как представлено сообщениями 728, 730 и 732.

После этого сообщение "200 Успешно" посылают по обратному маршруту.

Новые требования к элементам сети, помещенным в архитектуру согласно третьему варианту осуществления настоящего изобретения, могут быть подытожены как нижеследующие:

1. ФУСВ-О обновляет информацию о "присутствии" в СП с помощью отдельной транзакции REGISTER.

2. Если обновление "присутствия" на СП завершается неуспешно, то ФУСВ-О генерирует к ПО сообщение уведомления (например, SIP NOTIFY, использующее заголовок события с кодом причины неуспешного завершения для нового "присутствия"), указывающее событие неуспешного завершения обновления "присутствия".

3. Сообщение SUBSCRIBE, генерируемое абонентом, должно быть маршрутизировано сетью так, как если бы было обычным сообщением INVITE («Пригласить к участию в сеансе»), только ФУСВ-О для ПАП маршрутизирует SUBSCRIBE к СП, ассоциированному с "представительностью".

4. Сообщение NOTIFY, генерируемое СП, должно быть маршрутизировано сетью так, как если бы было обычным сообщением INVITE.

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

Комитет инженерной поддержки сети Интернет	Обычная РГ
Интернет-проект	Rosenberg et al.
draft-rosenberg-jmpp-presence-01.txt	Various Places
Март, 2, 2001
Срок действия: Сентябрь 2001

Расширения SIP для «Присутствия»

СТАТУС ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ (МЕМОРАНДУМА)

Этот документ является Интернет-проектом и находится в полном соответствии со всеми положениями раздела 10 документа RFC2026.

Интернет-проекты являются рабочими документами Комитета инженерной поддержки сети Интернет (КИПСИ, IETF), его сфер и его рабочих групп. Отметим, что другие группы могут также распространять рабочие документы в качестве Интернет-проектов.

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

Перечень текущих Интернет-проектов может быть доступен в документе http://www.ietf.org/ietf/lid-abstracts.txt.

Перечень текущих дубликатов каталогов Интернет-проектов может быть доступен в документе http://www.ietf.org/shadow.html.

Реферат

В документе предложено расширение к SIP для абонентов и уведомлений о присутствии пользователя. Присутствие пользователя определено как готовность и возможность пользователя взаимодействовать с другими пользователями по сети. Исторически присутствие было ограничено индикаторами "on-line" ("интерактивно") и "off-line" ("автономно"); понятие присутствия является более широким. Подписки и уведомления для присутствия пользователя поддерживают посредством определения пакета событий в пределах общей схемы уведомления о событиях, используемой SIP. Этот протокол также согласован со схемой (ОПОНС, CPIM) Общего Присутствия и Обмена Немедленными Сообщениями.

1. Введение

Понятие присутствия (косвенно) определено в RFC2778[1] как подписка к изменениям и уведомление об изменениях в состоянии связей пользователя.

Это состояние связей состоит из множества средств связи, адресов связей и статуса пользователя. Протокол присутствия является протоколом для обеспечения подобной услуги через Интернет или любую сеть с межсетевым протоколом, или Интернет-протоколом (ИП, IP).

В настоящем документе предложено расширение к Протоколу инициации сеанса (ПИС, SIP) [2] для понятия присутствия, или «присутствия». Это расширение является конкретной интерпретацией общей схемы уведомления о событиях, определенной для SIP [3], и как таковое, задает использование методов SUBSCRIBE (Подписать) и NOTIFY (Уведомить), определенных в указанном документе. «Присутствие» пользователя особенно хорошо подходит для SIP. Службы регистрации запросов и местоположения уже содержат информацию о присутствии пользователя; ее загружают на эти устройства посредством сообщений REGISTER и используют для маршрутизации вызовов к этим пользователям. Более того, сети SIP уже маршрутизируют сообщения INVITE от любого пользователя в сети к посреднику, или прокси-серверу, который содержит состояние регистрации для пользователя. Поскольку это состояние является «присутствием» пользователя, то такие сети SIP могут также позволять маршрутизировать запросы SUBSCRIBE к одному и тому же прокси-серверу. Это означает, что сети SIP могут быть повторно используемы для установления глобальной связности подписок и уведомлений «присутствия».

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

Настоящее расширение согласовано также со схемой Общего Присутствия и Обмена Немедленными Сообщениями (ОПОНС, CPIM), которая была определена в [4]. Это позволяет протоколу SIP для «присутствия» легко взаимодействовать с другими системами «присутствия», согласованными со ОПОНС.

2. Определения

Настоящий документ использует термины так, как это определено в [1]. Дополнительно следующие термины определены и/или дополнительно пояснены:

«Пользовательский агент присутствия» (ПАП, PUA): Пользовательский агент присутствия управляет информацией о «присутствии» для «представительности». В терминах SIP это означает, что ПАП генерирует запросы REGISTER, передавая некоторый вид информации о «представительности». В явной форме допускают множество ПАП для «представительности». Это означает, что пользователь может иметь много устройств, таких как сотовый телефон или персональный цифровой ассистент (PDA), каждый из которых независимо генерирует компонент общей информации о «присутствии», предназначенной для «представительности». ПАП помещают данные в систему присутствия, но находятся вне системы, так что они не принимают сообщений SUBSCRIBE и не посылают сообщений NOTIFY.

«Агент присутствия» (АП, РА): Агент присутствия является пользовательским агентом SIP, который способен к приему запросов SUBSCRIBE, к ответу на них и к генерированию уведомлений об изменениях в состоянии «присутствия». Агент присутствия должен иметь полное знание о состоянии «присутствия» (для) «представительности». Обычно это достигают посредством совместного размещения АП с прокси-сервером/ сервером-регистратором запросов или с «пользовательским агентом присутствия» (для) «представительности». АП всегда адресуем с помощью URL (Унифицированный адрес ресурса, УАР, URL) SIP.

«Сервер присутствия»: Сервер присутствия является логическим объектом, который для запросов SUBSCRIBE может действовать и как агент присутствия, и как прокси-сервер. При действии в качестве АП сервер присутствия посредством некоторых средств протокола осведомлен об информации «присутствия» для «представительности». Эти средства протокола могут быть запросами SIP REGISTER, но позволены и другие средства реализации. При действии в качестве прокси-сервера запросы SUBSCRIBE передают к другому объекту, который может действовать как АП.

«Клиент присутствия»: клиент присутствия является агентом присутствия, который размещен совместно вместе с ПАП. Он осведомлен об информации «присутствия» «представительности», поскольку он размещен совместно с объектом, который управляет этой информацией о «присутствии».

3. Обзор принципа действия

В данном разделе представлен обзор принципа действия настоящего расширения.

Когда объект, абонент, желает узнать об информации «присутствия» от некоторого пользователя, он создает запрос SUBSCRIBE. Этот запрос идентифицирует требуемую «представительность» в URI (Унифицированный идентификатор ресурса, УИР, URI) запроса, используя или URL «присутствия», или URL SIP. Подписку переносима по прокси-серверам SIP, как любой другой INVITE. Она, возможно, прибывает на сервер присутствия, который может либо завершить подписку (в таком случае он действует как агент присутствия для «представительности»), либо передать ее к клиенту присутствия. Если клиент присутствия обрабатывает подписку, то он фактически действует как агент присутствия для «представительности». Решение о том, передать или завершить SUBSCRIBE, является предметом локального рассмотрения; однако будет описан один способ осуществления такой схемы с использованием REGISTER.

Агент присутствия (либо в сервере присутствия, либо в клиенте присутствия) сначала аутентифицирует подписку, затем авторизует ее. Средства для авторизации находятся вне рамок области действия настоящего протокола, и ожидают, что будут использованы многие средства и способы. Авторизовав подписку, агент присутствия посылает ответ «202 Принято» (Accepted). Он также посылает немедленное сообщение NOTIFY, содержащее состояние «представительности». Поскольку состояние «представительности» изменено, то АП генерирует сообщения NOTIFY для всех абонентов.

Сообщение SUBSCRIBE фактически образует сеанс вместе с агентом присутствия. В качестве результата, SUBSCRIBE может быть маршрутизирован по записям и правила для обработки меток полей и информации об «Адресах переназначения» (Contact) отображают подобные правила для INVITE. Подобным образом, сообщение NOTIFY обрабатывают во многом сходным образом с тем, как обрабатывают повторный INVITE внутри этапа вызова.

4. Наименование

«Представительность» идентифицируют наиболее общим образом через URI [4], который представлен в форме pres:@domain. Такие URI не зависят от протокола. Посредством разнообразных средств такие URI могут быть разрешены для определения конкретного протокола, который может быть использован для доступа к представительности. Если один раз такое разрешение имело место, то «представительность» может быть адресована с помощью URL протокола SIP в почти идентичной форме: SIP:user@domain. Протокольно независимую форму (представительность: URL) можно считать абстрактным именем, такого вида как URN, которое используют для идентификации элементов в системе «присутствия». Их разрешают к конкретным URL, которые могут быть использованы для непосредственного, или прямого, определения местоположения этих элементов в сети.

При подписке к «представительности» подписка может быть адресована с использованием протокольно независимой формы или формы URL SIP. В контексте SIP "адресована" означает URI запроса. Рекомендуют, что если объект, посылающий SUBSCRIBE, способен разрешить протокольно независимую форму к форме SIP, то такое разрешение делают перед посылкой запроса. Однако если объект не способен сделать такое преобразование, то протокольно независимую форму используют в URI запроса. Выполнение такого преобразования как можно ранее означает, что такие запросы могут быть маршрутизированы прокси-серверами SIP, которые не осведомлены о пространстве имен присутствия.

Результатом такой схемы именования является то, что запрос SUBSCRIBE адресуют к пользователю точно таким же образом, как был бы адресован INVITE. Это означает, что сеть SIP будет маршрутизировать эти сообщения по тому же маршруту, по которому будет путешествовать INVITE. Один из этих объектов по маршруту может действовать в качестве АП для подписки. Обычно это будет или сервер присутствия (который является прокси-сервером/сервером-регистратором запросов там, где регистрирован пользователь), или клиент присутствия (который является одним из пользовательских агентов, ассоциированных с данной «представительностью»).

Сообщения SUBSCRIBE также содержат логические идентификаторы, которые определяют отправителя и получателя подписки (поля заголовка То (Конечный получатель) и From (Отправитель)). Поскольку эти идентификаторы являются логическими, то рекомендуют, чтобы для них по возможности использовали протокольно независимую форму. Это также упрощает межсетевое взаимодействие с другими системами, которые распознают эти формы.

Поля Contact («Адреса переназначения»), Record-Route («URI запроса»), Route («Маршрут запроса») не являются логическими объектами, а скорее конкретизируют те, которые используют для передачи сообщений SIP. Являясь такими, они должны использовать формы URL SIP в сообщениях SUBSCRIBE и NOTIFY.

5. Пакет событий для присутствия

Используемая SIP схема [3] событий определяет абстрактное расширение SIP для подписки к событиям и приема уведомлений от событий. Схема оставляет определение многих дополнительных аспектов для событий, чтобы конкретизировать расширения, известные также как пакеты событий. Это расширение квалифицировано как пакет событий. Настоящий раздел пополняет информацию, требуемую для [3].

5.1. Имя пакета

Именем этого пакета является "presence" ("присутствие"). Это имя должно появиться внутри заголовка события в запросе SUBSCRIBE и в запросе NOTIFY. Настоящий раздел служит также в качестве регистрации НИНА (IANA, Назначаемые Интернет номера авторизации, НИНА) для пакета событий "presence".

Сделать: определить шаблон НИНА в подуведомлении и заполнить его.

Пример:

Event: presence

5.2. Тела SUBSCRIBE (подписок)

Тело запроса SUBSCRIBE может содержать тело (подписки). Назначение тела зависит от его типа. В общем случае, подписки обычно не будут содержать тел. URI запроса, который идентифицирует «представительность», объединенный с именем пакета событий, достаточен для пользовательского «присутствия».

Следует предупредить, что форматы документа могут быть определены как фильтры для подписок. Такие фильтры будут указывать некоторые события пользовательского «присутствия», которые будут генерировать уведомления, или сокращать совокупность данных, возвращаемых в запросах NOTIFY. Например, фильтр «присутствия» может указать, что уведомления следует генерировать, когда изменяется статус входного (почтового) ящика немедленных сообщений пользователей. Можно также сказать, что в состав содержимого этих уведомлений следует включать только относящуюся к НС информацию. (IM: «немедленное сообщение» - ближе по тексту, «интерактивный режим» - по стандартным сокращениям, Интернет-мультимедиа - по документу.)

5.3. Время завершения

Присутствие пользователя может быть изменено в результате событий, которые включают в себя:

включение и выключение сотового телефонного аппарата;

модификация регистрации с программофона;

изменение статуса инструментальных средств немедленных сообщений.

Эти события обычно срабатывают под воздействием пользователя и происходят с частотой, значение которой порядка минут или часов. Если так, то подпискам следует иметь время завершения, равное среднему для этого диапазона и которое приблизительно соответствует одному часу. Следовательно, время завершения по умолчанию для подписок является 3600 секунд. Согласно [3] абонент может указать другое время завершения. Что бы не было указано во времени завершения, сервер может уменьшить его, но не должен увеличить его.

5.4. Тела NOTIFY

Тело уведомления содержит документ «присутствия». Этот документ описывает «присутствие» пользователя для «представительности», к которой была осуществлена подписка. Все подписки должны поддерживать формат данных «присутствия», который описан в [заполнить с IMPP документом TBD], и должны перечислять свой тип МРПСИ (Многоцелевые расширения почтовой службы Интернет, стандарт MIME, МРПСИ), [заполнить с типом МРПСИ] в заголовке Accept, содержащемся в запросе SUBSCRIBE.

Другие форматы данных присутствия могут быть определены в будущем. В таком случае подписки могут указать поддержку для других форматов «присутствия». Однако они должны всегда поддерживать любой перечень МРПСИ [заполнить с типом МРПСИ документа «присутствия» IMPP] как допустимый формат.

Конечно, уведомления, генерируемые агентом присутствия, должны быть в одном из форматов, указанном а заголовке Accept в запросе SUBSCRIBE.

5.5. Обработка требований на АП

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

Агент "присутствия" должен аутентифицировать все запросы подписки. Такая аутентификация может быть сделана с использованием любых средств и с