Область техники, к которой относится изобретение
Изобретение относится к состоянию сигнальной линии связи для пользователей IP Мультимедийной Подсистемы (IMS). В частности, но не обязательно, оно относится к P-CSCF, обеспечивающей указание того, что линия связи, предварительно используемая для передачи SIP сигналов между пользователем и P-CSCF, была потеряна.
Уровень техники
IP Мультимедиа (IPMM) представляет собой пример услуги, которая обеспечивает динамическое объединение голоса, изображения, сообщения, данных и т.д. в одном и том же сеансе. Путем увеличения числа базовых приложений и среды, которые можно объединить, число услуг, предлагаемых пользователю, возрастет, и опыт межперсональной связи станет богаче. Это приведет к новому поколению персонализированных услуг связи с широкими мультимедийными возможностями, например мультимедийная одноранговая связь, IPTV и т.д.
Эти услуги могут быть основаны на архитектуре IP Мультимедийной Подсистемы (IMS), которая является технологией, определенной с помощью Проекта Сотрудничества Третьего Поколения (3GPP), чтобы обеспечить IP Мультимедийные услуги по сетям мобильной связи (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 и TS 29.329 версии 5-7).
IMS применяет Протокол Инициализации Сеанса (SIP), чтобы установить и управлять звонками или сеансами между пользовательскими терминалами (или пользовательскими терминалами и серверами приложений). Протокол Описания Сеанса (SDP), переносимый сигналами SIP, использован, чтобы описывать и согласовывать компоненты среды сеанса. Другие мультимедийные приложения, которые могут быть использованы для передачи среды и управления, включают в себя Транспортный Протокол Реального Времени и Транспортный Управляющий Протокол Реального Времени (RTP/RTCP), Протокол ретрансляции сообщений сеанса (MSRP) и Протокол Преобразования Гипертекста (HTTP).
Фиг. 1 иллюстрирует схематически, как IMS встраивается в архитектуру мобильной сети в случае 3GPP PS доступа сети.
Функции Управления Сеансом/Вызовом (CSCFs) работают как SIP посредники c IMS. Архитектура 3GPP определяет три типа CSCF: Посредническая CSCF (Р-CSCF), которая является первой точкой контакта внутри IMS для SIP терминала; Сервисная CSCF (S-CSCF), которая обеспечивает услуги пользователю, на которые пользователь подписан; и Запрашивающая CSCF (I-CSCF), чья роль заключается в указании правильной S-CSCF и в передаче ей S-CSCF запроса, принятого от SIP терминала через Р-CSCF.
Если пользователь хочет получить доступ к услугам, обеспечиваемым сетью IP Мультимедийной Подсистемы (IMS), то пользователь должен обычно зарегистрировать свою собственную домашнюю сеть (это может происходить при включении пользовательского устройства). IMS/SIP клиент в оборудовании пользователя инициализирует процесс регистрации путем отправки SIP REGISTER сообщения Сервисной Функции Управления Сеансом/Вызовом (S-CSCF), присвоенного пользователю в домашней сети. При приеме REGISTER сообщения пользователь домашней сети может разрешить или отказать в доступе к IMS сети. Устройство пользователя или Оборудование Пользователя (UE) соединяется через сеть доступа, и первая точка контакта для пользователя в IMS представляет собой Р-CSCF. Как часть процесса регистрации S-CSCF сохраняет адрес контакта Р-CSCF вместе с адресом UE.
Передача сигналов между терминалом и Р-CSCF выполняется с использованием сети доступа. Возможно, что линия связи для передачи сигналов информации в сети доступа потеряна. Это может случиться, например, когда сигнал «прямо через воздух» потерян (например, когда пользователь проезжает через туннель) или когда пользователь движется в зоне перегруженной соты. Происходит непрерывная работа в 3GPP R7, чтобы гарантировать, что Р-CSCF примет указание, что линия передачи сигналов была потеряна, например, через Rx интерфейс. Однако нет предложений, которые были бы сделаны относительно того, что Р-CSCF сделает с этим указанием, кроме простого формирования команды Р-CSCF отмены регистрации. Другими словами, Р-CSCF послала бы SIP REGISTER запрос S-CSCF для отмены регистрации терминала. Это не является достаточно характерным или универсальным, чтобы указать состояние сигнального соединения терминала. IMS в настоящий момент не содержит механизма для передачи указания потери сигнальной линии.
Сущность изобретения
В соответствии с первым аспектом настоящего изобретения предусмотрен способ передачи информации о состоянии сигнального соединения в IP Мультимедийной Подсистеме, причем информация о состоянии сигнального соединения идентифицирует состояние сигнального соединения между терминалом и узлом-посредником в телекоммуникационной сети, при этом способ содержит:
определение на узле-посреднике того, что состояние сигнального соединения изменилось на новое состояние; и
отправку SIP запроса от узла-посредника IMS узлу IP Мультимедийной Подсистемы, при этом SIP запрос указывает новое состояние.
SIP запрос, указывающий новое состояние соединения, может быть запросом REGISTER, в этом случае новый параметр заголовка, указывающий состояние соединения терминала, включается в запрос.
Вообще, терминал будет зарегистрирован на IMS узле, когда он первоначально подключается к сети. В одном осуществлении начальное состояние сигнального соединения может быть зарегистрировано узлом-посредником и IMS узлом в течение этой начальной регистрации. Новое состояние соединения (как определено при изменении состояния соединения) может быть затем переслано IMS узлу с использованием PUBLISH запроса.
В другом осуществлении узел-посредник поддерживает документ с информацией о контакте, содержащий состояние сигнального соединения. IMS узел может тогда подписать документ с информацией о контакте. Узел-посредник может послать NOTIFY запрос IMS узлу, указывающий начальное состояние сигнального соединения, когда IMS узел первым подписывает документ с информацией о контакте. Далее NOTIFY запрос затем может быть послан IMS узлу, когда состояние соединения изменяется.
Узел-посредник представляет собой предпочтительно Посредническую Функцию Управления Вызовом/Сеансом. IMS узел может быть Сервисной Функцией Управления Вызовом/Сеансом.
Состояние возможности сигнального соединения может быть определено как «соединено», «разъединено», «неясно» или «неизвестно», хотя будет понятно, что можно использовать любое подходящее состояние. В одном осуществлении этап определения на узле-посреднике того факта, что состояние сигнального соединения изменилось на новое состояние, содержит определение того факта, что связь между терминалом и узлом-посредником была потеряна.
IMS узел может отменить регистрацию терминала в ответ на уведомление о том, что сигнальное соединение между терминалом и узлом-посредником было потеряно. Альтернативно IMS узел может учесть состояние сигнального соединения между терминалом и узлом-посредником при направлении трафика к зарегистрированным терминалам пользователя.
В соответствии с другим аспектом настоящего изобретения предусмотрен способ регистрации терминала на IMS узле IP Мультимедийной Подсистемы, содержащий сохранение информации о регистрации на IMS узле, причем информация о регистрации включает в себя состояние сигнального соединения между терминалом и узлом-посредником.
В соответствии с еще одним следующим аспектом настоящего изобретения, предусмотрен способ регистрации терминала на IMS узле IP Мультимедийной Подсистемы, содержащий отправку SIP REGISTER запроса IMS узлу, причем SIP REGISTER запрос включает в себя параметр состояния соединения, указывающий состояние сигнального соединения между терминалом и узлом-посредником.
В соответствии с другим аспектом настоящего изобретения предусмотрен способ регистрации терминала на IMS узле IP Мультимедийной Подсистемы, содержащий включение параметра состояния соединения, который указывает состояние сигнального соединения между терминалом и узлом-посредником, в SIP пакет события регистрации.
В соответствии с другим последующим аспектом настоящего изобретения предусмотрен способ работы узла-посредника в IP Мультимедийной Подсистеме, содержащий создание пакета SIP информации о событии контакта, который отслеживает состояние сигнального соединения между терминалом и узлом-посредником.
В соответствии с другим аспектом настоящего изобретения предусмотрен способ работы узла IP Мультимедийной Подсистемы, содержащий подписывание пакета SIP информации о событии контакта на узле посреднике, причем пакет SIP информации о событии контакта включает в себя указание состояния сигнального соединения между узлом-посредником и терминалом.
В соответствии с другим аспектом настоящего изобретения предусмотрена Посредническая Функция Управления Сеансом/Вызовом для использования в IP Мультимедийной Подсистеме, содержащая:
средство ввода для приема информации, указывающей текущее состояние сигнального соединения терминала, пытающегося получить доступ к IP Мультимедийной Подсистеме; и
средство вывода для обеспечения текущего состояния сигнального соединения к узлу IP Мультимедийной Подсистемы.
В соответствии с последующим другим аспектом настоящего изобретения предусмотрена Посредническая Функция Управления Сеансом/Вызовом для использования в IP Мультимедийной Подсистеме, предназначенной, чтобы создавать пакет информации о событии контакта, который отслеживает состояние сигнального соединения между Посреднической Функцией Управления Сеансом/Вызовом и терминалом.
В соответствии с другим аспектом настоящего изобретения предусмотрена система для передачи информации о состоянии сигнального соединения в IP Мультимедийной Подсистеме, при этом информация о состоянии сигнального соединения указывает состояние сигнального соединения между терминалом и узлом-посредником в телекоммуникационной сети, причем система содержит:
средство ввода на узле-посреднике для определения того, что состояние сигнального соединения изменилось на новое состояние;
выходное средство на узле-посреднике для отправки SIP запроса, указывающего новое состояние; и
IMS узел IP Мультимедийной Подсистемы, предназначенный, чтобы принимать SIP запрос и предпринимать соответствующее действие.
Краткое описание чертежей
Фиг. 1 иллюстрирует схематично архитектуру IP Мультимедийной Подсистемы в системе мобильной связи третьего поколения;
фиг. 2 представляет собой схематичный вид сигнального пути между SIP UE и S-CSCF;
фиг. 3 иллюстрирует последовательность сигналов для гарантирования того, что S-CSCF информирована о потере сигнального однонаправленного канала;
фиг. 4 иллюстрирует альтернативную последовательность сигналов для гарантирования того, что S-CSCF информирована о потере сигнального однонаправленного канала;
фиг. 5 иллюстрирует последовательность сигналов для доставки информации о соединении S-CSCF; и
фиг. 6 иллюстрирует последовательность сигналов для уведомления S-CSCF о потере сигнального однонаправленного канала.
Подробное описание предпочтительного осуществления
Как описано выше, уже проделана большая работа, чтобы убедиться, что Р-CSCF принимает информацию по Rx интерфейсу о том, что терминал (UE) был отсоединен. Примеры, приведенные ниже, представляют механизмы, гарантирующие, что эта информация поступает к S-CSCF.
Фиг. 2 представляет собой схематическое представление сигнального пути 1 между UE 2 и S-CSCF 3 через Р-CSCF 4. Линия 5 связи обеспечивается сетью доступа (не показана) UE. Р-CSCF включает в себя механизм 6 мониторинга, который определяет, потерян ли сигнальный путь 1 от UE.
Фиг. 3 иллюстрирует последовательность сигналов между Р-CSCF и S-CSCF, которая позволяет данным о соединении UE быть записанными S-CSCF-ей. В данном примере это достигается введением нового параметра заголовка контакта, указывающего состояние соединения UE. Подходящие значения для информации о состоянии могут включать в себя: «соединенное», «разъединенное», «неясное» и «неизвестное». «Неясное» состояние может быть использовано, когда есть подозрение, что произошел отказ при соединении.
Последовательность сигналов указана далее:
Этап 1: UE регистрирует свой контакт с S-CSCF известным образом. UE и P-CSCF подписывают пакет события регистрации, чтобы получить уведомления об информации регистрации, поддерживаемой S-CSCF.
Этап 2: P-CSCF определяет потерю сигнальной линии связи между ней и UE. Этого можно достигнуть, например, с помощью P-CSCF, принимающей такое указание по Rx интерфейсу. P-CSCF посылает REGISTER запрос S-CSCF. REGISTER запрос включает в себя адрес контакта UE, совместно с новым параметром заголовка контакта. Новый параметр содержит детали состояния контакта соединения. В этом примере состояние имеет вид «разъеденное». P-CSCF вставляет свой SIP URI адрес в заголовок «От».
Этап 3: когда S-CSCF принимает REGISTER запрос, она устанавливает, что запрос был создан объектом, заслуживающим доверия. Один путь достижения этого заключается в сравнении адреса P-CSCF, принятого в запросе, с P-CSCF адресом, ранее сохраненным при процедуре регистрации на Этапе 1. Как только S-CSCF подтвердила, что P-CSCF авторизован, то тогда S-CSCF возвращает 200 OK ответ. Это подтверждает, что состояние «контакт разъединен», содержащееся в REGISTER запросе, было записано.
Этап 4: обладая принятой информацией о том, что зарегистрированный контакт разъединен, S-CSCF может выбрать отмену регистрации контакта или может выбрать сохранить эту информацию для дальнейшего использования, когда она принимает трафик, который должен быть направлен к контакту(ам) пользователя.
Другими словами, состояние сигнального соединения UE регистрируется в S-CSCF похожим образом для местоположения, когда пользователь первым осуществляет контакт, хотя будет понятно, что P-CSCF регистрирует состояние сигнального соединения, несмотря на то, что когда пользователь первый осуществляет контакт, то он представляет собой UE, который регистрирует свое местоположение.
Альтернативная последовательность сигналов для получения информации о соединении для S-CSCF показана на фиг.4. Эта альтернатива расширяет определение Пакета События Регистрации (RFC 3680) путем добавления необязательной информации о состоянии сигнального контакта к элементу информации о контакте документа с информацией о регистрации. Состояние соединения UE включается в начальную регистрацию в S-CSCF, в дополнение к местоположению и идентификации. Этого можно достигнуть с помощью S-CSCF, допуская, что начальное состояние сигнального соединения все еще имеет вид «соединено» (и если известно, что) начальная регистрация имеет место во всем сигнальном канале. Альтернативно P-CSCF может обеспечивать начальное сигнальное соединение с S-CSCF, используя SIP PUBLISH запрос. Если P-CSCF определяет, что состояние соединения изменилось, то эта информация поступает к S-CSCF, используя PUBLISH запрос. S-CSCF обновляет свою информацию о регистрации в ответ на информацию, включенную в PUBLISH запрос. Как и прежде, подходящие значения для информации о состоянии могут включать в себя: «соединенное», «разъединенное», «неясное» и «неизвестное». «Неясное» состояние может быть использовано, когда есть подозрение, что произошел отказ при соединении.
Последовательность сигналов указана далее:
Этап 1: UE регистрирует свой контакт с S-CSCF известным образом. S-CSCF изучает состояние сигнального соединения в процессе этой начальной регистрации.
Этап 2: P-CSCF определяет потерю сигнальной линии связи между ней и UE. Как и прежде, этого можно достигнуть, например, с помощью P-CSCF, принимающей такое указание по Rx интерфейсу.
P-CSCF посылает PUBLISH запрос S-CSCF. PUBLISH запрос включает в себя документ, содержащий информацию о новом состоянии соединения контакта. В этом примере состояние имеет вид «разъединено». P-CSCF вставляет свой SIP URI адрес в заголовок «От».
Этап 3: когда S-CSCF принимает PUBLISH запрос, то она устанавливает, что запрос был создан объектом, заслуживающим доверия. Один путь достижения этого заключается в сравнении адреса P-CSCF, принятого в запросе, с P-CSCF адресом, ранее сохраненным при процедуре регистрации на Этапе 1. Как только S-CSCF подтвердила, что P-CSCF авторизован, то тогда S-CSCF возвращает 200 OK ответ. Это подтверждает, что состояние «контакт разъединен», содержащееся в REGISTER запросе, было записано.
Этап 4: обладая принятой информацией о том, что регистрируемый контакт разъединен, S-CSCF может выбрать отмену регистрации UE или она может выбрать сохранить эту информацию для дальнейшего использования, когда она принимает трафик, который должен быть направлен к контакту(ам) пользователя.
Этот механизм является общим, так как он допускает объекты, другие, чем S-CSCF, чтобы получить информацию о соединении контакта с помощью подписки информации о регистрации, поддерживаемой S-CSCF, которая теперь включает в себя эту информацию.
В дальнейшем альтернативном варианте, определен новый пакет SIP события, который позволяет P-CSCF доставлять информацию о контакте соединения. Используется структура уведомления о SIP событии (PFC 3265). В этом альтернативном варианте P-CSCF поддерживает информацию о состоянии соединения контакта в Пакете SIP События с новым Документом с Информацией о Состоянии. Это позволяет другим объектам, таким как S-CSCF, подписывать эту информацию и получать уведомления об изменениях состояния.
Последовательность начальной установки показана на фиг.5 и представлена далее:
Этап 1: UE регистрирует свой контакт с S-CSCF. В процессе регистрации P-CSCF и S-CSCF сохраняют адрес друг друга. Они также сохраняют информацию, касающуюся начального контакта, и состояние начального контакта между UE и P-CSCF. UE и P-CSCF подписывают пакет события регистрации, чтобы получить уведомления об информации о регистрации, поддерживаемые S-CSCF. Они являются процедурами текущего стандарта 3GPP. Дополнительно P-CSCF создает Документ с Информацией о Контакте с информацией о состоянии соединения контакта и может предоставить S-CSCF SIP URI адрес созданного документа как часть процедуры регистрации. P-CSCF поддерживает этот документ так долго, как она поддерживает состояние регистрации контакта.
Этап 2: если контакт был зарегистрирован, S-CSCF подписывает состояние соединения контакта. Это достигается отправкой SIP SUBSCRIBE запроса P-CSCF, запрашивающего Документ с Информацией о Контакте зарегистрированного контакта.
Этап 3: когда P-CSCF принимает SUBSCRIBE запрос, то она устанавливает, что запрос был создан объектом, заслуживающим доверия. Один путь достижения этого заключается в сравнении адреса S-CSCF, принятого в запросе, с S-CSCF адресом, ранее сохраненным при процедуре регистрации на Этапе 1. P-CSCF сохраняет адрес S-CSCF, как подписчика на Информацию о Контакте. Обладая авторизованной S-CSCF в качестве доверенного подписчика, P-CSCF отвечает 200 OK на SUBSCRIBE запрос.
Этап 4: P-CSCF затем посылает SIP NOTIFY запрос новому подписчику (S-CSCF) с текущим Документом с Информацией о Контакте, в этом примере указывающим, что контакт соединен.
Этап 5: когда S-CSCF принимает NOTIFY запрос, то он сохраняет Информацию о Контакте для дальнейшего использования и отвечает 200 OK.
Следует заметить, что P-CSCF обеспечивает SIP URI Документа с Информацией о Контакте во время регистрации.
Если сигнальная линия связи потеряна, то это определяется, как и прежде, с помощью P-CSCF (например, с помощью приема указания по Rx интерфейсу). Последовательность сигналов для передачи этой информации иллюстрируется на фиг. 5 и выполняется, как указано далее:
Этап 6: если P-CSCF определяет потерю сигнальной линии связи между ней и UE, то P-CSCF посылает SIP NOTIFY запрос S-CSCF. NOTIFY запрос включает в себя измененный Документ с Информацией о Контакте с новой информацией о состоянии соединения контакта. В этом примере он указывает, что контакт сейчас разъединен.
Этап 7: если S-CSCF принимает NOTIFY запрос, то он обновляет информацию о состоянии соединения контакта и посылает 200 OK ответ.
Этап 8: обладая принятой информацией о том, что зарегистрированный контакт разъединен, S-CSCF может выбрать отменить регистрацию или она может сохранить эту информацию для дальнейшего использования, когда она принимает трафик, который должен быть направлен к контакту(ам) пользователя. Если контакт де-регистрирован, то подписка S-CSCF на событие состояния соединения завершается.
Этот механизм также позволяет объектам, другим, чем S-CSCF, получать информацию о соединении для контакта путем подписывания информации о контакте, поддерживаемой P-CSCF.
Будет понятно, что отклонения от выше описанных осуществлений могут все же выпадать из объема изобретения. Например, все осуществления описывают вышеуказанную ситуацию, когда ясное указание на потерю сигнальной связи принимается P-CSCF по Rx интерфейсу. Однако могут быть предусмотрены и другие механизмы, с помощью которых P-CSCF уведомляют о потере сигнального соединения. Например, может быть использовано отсутствие ответа от UE, после определенного периода времени. Альтернативно, сообщение Протокола Управляющих Сообщений Сети (ICMP) может быть принято от IP транспортной сети. Также могут быть использованы другие механизмы.
Также будет понятно, что все вышеописанные осуществления рассматривают главным образом в связи с потерей сигнального соединения между UE и P-CSCF. Замечено в каждом случае, что S-CSCF может обновить состояние соединения для дальнейшего использования. Если соединение заново установлено, то система в соответствии с настоящим изобретением может быть использована, чтобы направить эту информацию S-CSCF, так что она может опять обновить свое состояние. Изобретение не ограничивается отчетом о потере соединения между UE и P-CSCF: оно относится к отчету о состоянии связи.
Более того, все примеры описывают передачу информации о состоянии сигнального соединения от P-CSCF к S-CSCF. Будет понятно, что изобретение может быть использовано для передачи этой информации от P-CSCF другим узлам IMS центра. Чтобы предпринять соответствующее действие.
Изобретение относится к системам связи и, в частности, к мультимедийной подсистеме Интернет-протокола (IMS). Техническим результатом является обеспечение указания того, что линия связи, предварительно используемая для передачи сигналов протокола инициализации сеанса (SIP) между пользователем и модулем посреднической функции управления сеансом/вызовом (P-CSCF), была потеряна. Указанный технический результат достигается тем, что предложен способ передачи информации о состоянии сигнального соединения в IMS. Когда на P-CSCF определено, что состояние сигнального соединения изменилось на новое состояние, например сигнальное соединение между P-CSCF и терминалом, потеряно, то SIP запрос посылается от P-CSCF к модулю сервисной функции управления сеансом/вызовом (S-CSCF), указывая новое состояние. SIP запрос может быть REGISTER запросом. Альтернативно, пакет события регистрации терминала расширен, чтобы включать в себя состояние соединения. Изменение соединения может затем быть отправлено в PUBLISH запросе. В последующем альтернативном варианте новый пакет SIP события поддерживается P-CSCF, а S-CSCF подписывает этот пакет события и уведомляет с помощью P-CSCF при изменении состояния соединения. 9 н. и 11 з.п ф-лы, 6 ил.
1. Способ передачи информации о состоянии сигнального соединения в мультимедийной подсистеме Интернет-протокола (IP) (IMS), причем информация о состоянии сигнального соединения идентифицирует состояние сигнального соединения между терминалом и модулем посреднической функции управления сеансом/вызовом (P-CSCF) в телекоммуникационной сети, при этом способ содержит: определение в P-CSCF модуле того, что состояние сигнального соединения изменилось на новое состояние; и отправку запроса протокола инициализации сеанса (SIP) от P-CSCF модуля в модуль сервисной функции управления сеансом/вызовом (S-CSCF) IP мультимедийной подсистемы, причем SIP запрос указывает новое состояние.
2. Способ по п.1, в котором SIP запрос, указывающий новое состояние соединения, представляет собой REGISTER запрос.
3. Способ по п.2, в котором REGISTER запрос включает в себя параметр заголовка, указывающий состояние соединения терминала.
4. Способ по п.1, в котором SIP запрос, указывающий новое состояние соединения, представляет собой PUBLISH запрос.
5. Способ по п.4, в котором терминал регистрируют в S-CSCF модуле, и в котором начальное состояние сигнального соединения регистрируют посредством P-CSCF модуля и S-CSCF модуля, когда терминал зарегистрирован в S-CSCF модуле.
6. Способ по п.1, в котором P-CSCF модуль поддерживает документ с информацией о контакте, содержащем состояние сигнального соединения, и в котором S-CSCF модуль подписывается на документ с информацией о контакте.
7. Способ по п.6, в котором, когда S-CSCF модуль подписывается на документ с информацией о контакте, то P-CSCF модуль посылает SIP NOTIFY запрос в S-CSCF модуль, указывающий начальное состояние сигнального соединения.
8. Способ по п.6 или 7, в котором SIP запрос, указывающий новое состояние соединения представляет собой NOTIFY запрос.
9. Способ по п.1, в котором состояние сигнального соединения может быть установлено как одно из следующего перечня: соединенное, разъединенное, неясное и неизвестное.
10. Способ по п.1, в котором этап определения в P-CSCF модуле того, что состояние сигнального соединения изменилось на новое состояние, содержит определение того, что сигнальное соединение между терминалом и P-CSCF модулем было потеряно.
11. Способ по п.10, в котором S-CSCF модуль отменяет регистрацию терминала в ответ на уведомление о том, что сигнальное соединение между терминалом и P-CSCF модулем было потеряно.
12. Способ по п.1, в котором S-CSCF модуль учитывает состояние сигнального соединения между терминалом и P-CSCF модулем при направлении графика в терминал.
13. Способ регистрации терминала в модуле сервисной функции управления сеансом/вызовом (S-CSCF) IP мультимедийной подсистемы, содержащий сохранение информации о регистрации в S-CSCF модуле, причем информация о регистрации включает в себя состояние сигнального соединения между терминалом и модулем посреднической функции управления сеансом/вызовом (P-CSCF).
14. Способ регистрации терминала в модуле сервисной функции управления сеансом/вызовом (S-CSCF) IP мультимедийной подсистемы, содержащий отправку SIP REGISTER запроса в S-CSCF модуль, причем SIP REGISTER запрос включает в себя параметр состояния соединения, указывающий состояние сигнального соединения между терминалом и модулем посреднической функции управления сеансом/вызовом (P-CSCF).
15. Способ регистрации терминала в модуле сервисной функции управления сеансом/вызовом (S-CSCF) IP мультимедийной подсистемы, содержащий включение параметра состояния соединения, который указывает состояние сигнального соединения между терминалом и модулем посреднической функции управления сеансом/вызовом (P-CSCF), в пакет события SIP регистрации.
16. Способ работы модуля посреднической функции управления сеансом/вызовом (P-CSCF) в IP мультимедийной подсистеме, содержащий создание пакета события с информацией о SIP контакте, который отслеживает состояние сигнального соединения между P-CSCF модулем и терминалом.
17. Способ работы узла IP мультимедийной подсистемы, содержащий осуществление подписки на пакет события с информацией о SIP контакте в модуле посреднической функции управления сеансом/вызовом (P-CSCF), причем пакет события с информацией о SIP контакте включает в себя указание состояния сигнального соединения между P-CSCF модулем и терминалом.
18. Модуль посреднической функции управления сеансом/вызовом (Р-CSCF) для использования в IP мультимедийной подсистеме, содержащий: средство ввода для приема информации, идентифицирующей текущее состояние сигнального соединения терминала, пытающегося получить доступ к IP мультимедийной подсистеме; и средство вывода для передачи текущего состояния сигнального соединения в узел IP мультимедийной подсистемы.
19. Модуль посреднической функции управления сеансом/вызовом (P-CSCF) для использования в IP мультимедийной подсистеме, предназначенной, чтобы создавать пакет события с информацией о SIP контакте, который отслеживает состояние сигнального соединения между Р-CSCF модулем и терминалом.
20. Система для передачи информации о состоянии сигнального соединения в IP мультимедийной подсистеме, причем информация о состоянии сигнального соединения идентифицирует состояние сигнального соединения между терминалом и модулем посреднической функции управления сеансом/вызовом (P-CSCF) в телекоммуникационной сети, причем система содержит: средство ввода в P-CSCF модуле для определения того, что состояние сигнального соединения изменилось на новое состояние; средство вывода в Р-CSCF модуле для отправки SIP запроса, указывающего новое состояние; и модуль сервисной функции управления сеансом/вызовом (S-CSCF) IP мультимедийной подсистемы, предназначенный для того, чтобы принимать SIP запрос и предпринимать соответствующее действие.
| US 2004184452 A1, 23.09.2004 | |||
| WO 2006027375 A1, 16.03.2006 | |||
| WO 2005064896 A1, 14.07.2005 | |||
| RU 2005102823 A, 20.01.2006 | |||
| RU 2004125593 A, 27.01.2006 | |||
| Переносная печь для варки пищи и отопления в окопах, походных помещениях и т.п. | 1921 |
|
SU3A1 |
