Результат интеллектуальной деятельности: ОБРАБОТКА СООБЩЕНИЙ ПРОТОКОЛА ИНИЦИИРОВАНИЯ СЕАНСОВ В ТЕЛЕКОММУНИКАЦИОННОМ УСТРОЙСТВЕ БЕСПРОВОДНОЙ СВЯЗИ

Область техники, к которой относится изобретение

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

Предшествующий уровень техники

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

Одно из приложений, использующее SIP, является услугой мультимедийной подсистемы Интернет-протокола (IMS). IMS представляет собой архитектурную основу для предоставления мультимедийных услуг Интернет-протокола (IP), и он использует протокол, например протокол SIP.

Основные части мобильного телефона, использующего SIP, состоят из подсистемы модема и модуля обработки приложений (APE). Во многих случаях услуги IMS развернуты как на подсистеме модема, так и в APE. Ориентированная на телефонную связь услуга IMS (например, услуга передачи голоса по стандарту "Долгосрочное развитие" (LTE) или IMS мультимедийной телефонной связи) естественным образом развернута на подсистеме модема как эквивалент услуги телефонной связи с коммутацией каналов. Разнообразные коммуникационные услуги IMS (например, присутствие комплекта разнообразных средств связи (RCS) и передача файлов) естественным образом развернуты в APE аналогично использованию электронной телефонной книги и файловой системы.

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

Как подсистема модема, так и APE могут иметь свой собственный SIP-стек так, чтобы услуги IMS отправляли свои регистрационные данные SIP на SIP-сервер-регистратор абсолютно независимо друг от друга. Проблема заключается в том, что поскольку каждая услуга IMS выполняет свою собственную регистрацию SIP, с мобильного телефона на SIP-сервер-регистратор отправляется множество сообщений с SIP-запросами. Это означает нерациональное использование как сетевых ресурсов, так и ресурсов для обработки и сохранения в SIP-сервере-регистраторе.

Один из способов избегать этого может заключаться в том, чтобы иметь только один общий SIP-стек, развернутый в подсистеме модема, и позволять всем услугам IMS использовать этот общий SIP-стек. Однако связанная с этим проблема состоит в том, что для общего SIP-стека, используемого как услугами IMS в APE, так и услугами IMS в подсистеме модема, требуются новые интерфейсы API между APE и подсистемой модема. Это невыгодно вследствие того, что APE и подсистема модема принадлежат различным административным доменам. Кроме того, для этой цели не существует никакого стандартизированного или фактического API.

В US 2009/0245233 показана система, в которой приложение использует агента пользователя протокола инициирования сеансов (SIP) и независимый SIP-стек для установления соединения и управления сеансами связи и состояниями вызова. SIP-агент пользователя содержит специализированный интерфейс приложений, необходимый для обеспечения возможности приложению взаимодействовать с независимым SIP-стеком, в то время как независимый SIP-стек разрешает SIP-агенту пользователя управлять услугами SIP, связанными с этим приложением и сеансом связи.

Сущность изобретения

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

В соответствии с вариантами осуществления изобретения эта цель достигается в способе обработки сообщений протокола инициирования сеансов в телекоммуникационном устройстве беспроводной связи, выполненном с возможностью использования протокола инициирования сеансов в установлении связи по меньшей мере с одним другим телекоммуникационным устройством, при этом устройство содержит подсистему модема, выполненную с возможностью развертывания услуг мультимедийной подсистемы Интернет-протокола с использованием протокола инициирования сеансов и содержащую стек протокола инициирования сеансов для обмена сообщениями протокола инициирования сеансов между услугами мультимедийной подсистемы Интернет-протокола на подсистеме модема и внешним прокси-сервером протокола инициирования сеансов; и модуль обработки приложений, выполненный с возможностью развертывания услуг мультимедийной подсистемы Интернет-протокола с использованием протокола инициирования сеансов и содержащий стек протокола инициирования сеансов для обмена сообщениями протокола инициирования сеансов между услугами мультимедийной подсистемы Интернет-протокола в модуле обработки приложений и внешним прокси-сервером протокола инициирования сеансов. Эта цель достигается, когда способ содержит этапы захвата сообщений протокола инициирования сеансов от услуг мультимедийной подсистемы Интернет-протокола для внешнего прокси-сервера протокола инициирования сеансов в логическом элементе, выполненном с возможностью функционирования в качестве Back-to-Back (сквозного) пользовательского агента протокола инициирования сеансов, со стеком протокола инициирования сеансов, соединенным со стеками протокола инициирования сеансов подсистемы модема и модуля обработки приложений и с внешним прокси-сервером протокола инициирования сеансов; и отправки от упомянутого логического элемента на внешний прокси-сервер протокола инициирования сеансов сообщений протокола инициирования сеансов на основании упомянутых захваченных сообщений протокола инициирования сеансов.

Когда сообщения протокола инициирования сеансов от услуг мультимедийной подсистемы Интернет-протокола для внешнего прокси-сервера протокола инициирования сеансов захватываются в логическом элементе, который выполнен с возможностью функционирования в качестве Back-to-Back пользовательского агента протокола инициирования сеансов, необходимость в специализированном интерфейсе прикладного программирования (API) между этими двумя подсистемами исключается, и больше не требуется отправлять множество сообщений с SIP-запросами с мобильного телефона на SIP-сервер-регистратор, потому что Back-to-Back пользовательский агент протокола инициирования сеансов теперь может объединять SIP-сообщения от услуг IMS этих двух подсистем.

В одном варианте осуществления способ дополнительно содержит этапы сохранения в упомянутом логическом элементе, когда принято исходящее сообщение запроса SIP REGISTER (регистрации SIP) от незарегистрированной услуги мультимедийной подсистемы Интернет-протокола, развернутой на подсистеме модема или модуле обработки приложений, параметров, специфичных для этой услуги мультимедийной подсистемы Интернет-протокола; объединения, если параметры для других ранее зарегистрированных услуг мультимедийной подсистемы Интернет-протокола уже сохранены, параметров для незарегистрированной услуги мультимедийной подсистемы Интернет-протокола с параметрами для ранее зарегистрированных услуг мультимедийной подсистемы Интернет-протокола; и отправки сообщения запроса SIP REGISTER с объединенными параметрами на внешний прокси-сервер протокола инициирования сеансов. Объединение параметров от нескольких услуг IMS значительно сокращает количество запросов на регистрацию и перерегистрацию SIP, отправляемых с этого устройства на внешний прокси-сервер.

В таком варианте осуществления способ дополнительно может содержать этап отправки, когда принято ответное сообщение SIP REGISTER от внешнего прокси-сервера протокола инициирования сеансов, ответного сообщения SIP REGISTER к незарегистрированной услуге мультимедийной подсистемы Интернет-протокола, от которой было принято исходящее сообщение запроса SIP REGISTER.

В некоторых вариантах осуществления способ дополнительно содержит этапы сохранения в упомянутом логическом элементе, когда принято первое исходящее сообщение запроса SIP SUBSCRIBE (подписки SIP) от услуги мультимедийной подсистемы Интернет-протокола, развернутой в подсистеме модема или модуле обработки приложений, услуги мультимедийной подсистемы Интернет-протокола как абонента; отправки сообщения запроса SIP SUBSCRIBE на внешний прокси-сервер протокола инициирования сеансов; и отправки, когда принято ответное сообщение SIP SUBSCRIBE от внешнего прокси-сервера протокола инициирования сеансов, ответного сообщения SIP SUBSCRIBE к этой услуге мультимедийной подсистемы Интернет-протокола.

В таких вариантах осуществления способ дополнительно может содержать этап сохранения, когда принято дополнительное исходящее сообщение запроса SIP SUBSCRIBE от услуги мультимедийной подсистемы Интернет-протокола, развернутой на подсистеме модема или модуле обработки приложений, услуги мультимедийной подсистемы Интернет-протокола как абонента; отправки ответного сообщения SIP SUBSCRIBE к этой услуге мультимедийной подсистемы Интернет-протокола; и отправки сообщения запроса SIP NOTIFY (уведомление SIP) к этой услуге мультимедийной подсистемы Интернет-протокола с информацией из сообщения запроса SIP NOTIFY, ранее полученного от внешнего прокси-сервера протокола инициирования сеансов. Таким образом, количество сообщений запроса SIP SUBSCRIBE также может быть значительно уменьшено.

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

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

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

Логический элемент дополнительно может быть выполнен с возможностью отправки, при приеме входящего сообщения запроса SIP OPTIONS (вариантов выбора SIP), сообщения запроса SIP OPTIONS ко всем зарегистрированным услугам мультимедийной подсистемы Интернет-протокола на подсистеме модема и модуле обработки приложений; сбора ответных сообщений SIP OPTIONS от зарегистрированных услуг мультимедийной подсистемы Интернет-протокола; объединения принятых ответных сообщений SIP OPTIONS в общее ответное сообщение SIP OPTIONS; и отправки объединенного ответного сообщения SIP OPTIONS обратно к отправителю входящего сообщения запроса SIP OPTIONS. Это обеспечивает общий ответ SIP OPTIONS для всех услуг мультимедийной подсистемы Интернет-протокола в устройстве.

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

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

Краткое описание чертежей

Теперь ниже будут описаны варианты осуществления настоящего изобретения более подробно со ссылкой на чертежи, на которых:

фиг. 1 показывает пример телекоммуникационного устройства, выполненного с возможностью использования протокола инициирования сеансов (SIP);

фиг. 2 показывает телекоммуникационное устройство SIP с двумя подсистемами, каждая из которых имеет свой собственный SIP-стек;

фиг. 3 показывает телекоммуникационное устройство SIP с двумя подсистемами, совместно использующими общий SIP-стек;

фиг. 4 показывает телекоммуникационное устройство SIP с двумя подсистемами и логический элемент, действующий в качестве B2BUA SIP, соединенный с этими двумя подсистемами;

фиг. 5 показывает более подробно получение SIP-сообщений от услуг IMS в логическом элементе;

фиг. 6 показывает графическую схему программы, иллюстрирующую получение SIP-сообщений от услуг IMS в логическом элементе;

фиг. 7 показывает, как логический элемент действует в качестве B2BUA SIP для связанных с регистрацией SIP транзакций;

фиг. 8 показывает графическую схему программы, иллюстрирующую выполнение транзакций SIP REGISTER;

фиг. 9 показывает графическую схему программы, иллюстрирующую выполнение транзакций SIP SUBSCRIBE и SIP NOTIFY для событий "reg"; и

фиг. 10 показывает графическую схему программы, иллюстрирующую выполнение входящих транзакций SIP OPTIONS.

Подробное описание

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

Телекоммуникационное устройство SIP, например SIP-телефон, представляет собой SIP-агента пользователя, который обеспечивает традиционные функции телефонных вызовов, такие как набор номера, ответ, отклонение, удержание/снятие с удержания и переадресация вызовов. SIP все в большей степени внедряется в качестве стандартной платформы телефонной связи. Эти функции реализуются в подсистеме 2 модема телекоммуникационного устройства 1.

Один тип приложения, использующего SIP, представляет собой услуги мультимедийной подсистемы Интернет-протокола (IMS). IMS является архитектурной основой для предоставления мультимедийных услуг Интернет-протокола (IP), которая использует протокол, например протокол SIP. Таким образом, множество ориентированных на телефонную связь услуг IMS, таких как передача голоса по стандарту "Долгосрочное развитие" (LTE) или мультимедийная услуга IMS телефонной связи, естественным образом развернуто в подсистеме 2 модема как эквивалент услуги телефонной связи с коммутацией каналов. Это иллюстрируется с помощью услуги 3 IMS на фиг. 1. Услуга 3 IMS имеет SIP-стек 4, используемый для связи с соответствующими SIP-стеками в других сетевых элементах SIP.

На фиг. 1 услуга 3 IMS взаимодействует с SIP-прокси-сервером 11 с SIP-стеком 12. SIP-прокси-сервер 11 может быть прокси-функцией управления сеансами вызовов (P-CSCF), которая является первой точкой контакта для терминала IMS, то есть телекоммуникационного устройства 1. Кроме того, SIP-прокси-сервер 11 взаимодействует с другим SIP-прокси-сервером 21 с SIP-стеком 22. SIP-прокси-сервер 21 может быть функцией управления сеансами вызовов предоставления услуг (S-CSCF), которая представляет собой центральный SIP-прокси-сервер в этой сети.

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

Как упомянуто выше, основные части мобильного телефона, использующего SIP, состоят из двух подсистем, то есть из подсистемы модема и модуля обработки приложений (APE), и во многих случаях услуги IMS развернуты как в подсистеме модема, так и в APE. В то время как ориентированная на телефонную связь услуга IMS (например, передача голоса по стандарту "Долгосрочное развитие" (LTE) или мультимедийная услуга IMS телефонной связи) естественным образом развернута на подсистеме модема, как эквивалент услуги телефонной связи с коммутацией каналов, разнообразные коммуникационные услуги IMS (например, присутствие комплекта разнообразных средств связи (RCS) и передача файлов) естественным образом развернуты в APE аналогично использованию электронной телефонной книги и файловой системы. Это иллюстрируется на фиг. 2 с помощью услуги 6 IMS, развернутой в APE 5. Услуга 6 IMS имеет SIP-стек 7, используемый для связи с соответствующими SIP-стеками в других сетевых SIP-элементах, таких как SIP-прокси-сервер 11.

APE и подсистема модема не могут взаимодействовать напрямую без использования между ними специализированного интерфейса прикладного программирования (API). Таким образом, на фиг. 2 и подсистема модема, и APE имеют свой собственный SIP-стек, то есть SIP-стек 4 в подсистеме 2 модема и SIP-стек 7 в APE 5, так что услуги IMS отправляют свои регистрационные данные SIP на SIP-сервер-регистратор (сервер, который принимает запросы SIP REGISTER от клиента SIP, например услуга IMS), абсолютно независимы друг от друга. Это означает, что поскольку каждая услуга IMS выполняет свою собственную регистрацию SIP, множество сообщений с SIP-запросами отправляются с мобильного телефона на SIP-сервер-регистратор. Это означает нерациональное использование и сетевых ресурсов, и ресурсов обработки и сохранения на SIP-сервере-регистраторе.

Как иллюстрируется на фиг. 3, этого можно избегать, имея только один общий SIP-стек 8, развернутый в подсистеме 2 модема, и позволяя всем услугам 3 и 6 IMS использовать этот общий SIP-стек 8. Однако связанная с этим проблема состоит в том, что общий SIP-стек 8, используемый и услугами 6 IMS в APE 5, и услугами 3 IMS в подсистеме 2 модема, как упомянуто выше, требует новых интерфейсов прикладного программирования между APE и подсистемой модема. Это невыгодно вследствие того, что APE и подсистема модема принадлежат различным административным доменам. Кроме того, для этой цели не существует ни стандартизированного, ни фактического интерфейса прикладного программирования.

На фиг. 4 новый объект или логический элемент 13 с его собственным SIP-стеком 14 расположен в подсистеме 2 модема. SIP-стек 14 соединен с SIP-стеками 4 и 7 подсистемы 2 модема и APE 5 соответственно, а также с SIP-стеком 12 внешнего SIP-прокси-сервера 11 P-CSCF. Логический элемент 13 в дальнейшем также называется SBP, потому что, как описано ниже, логический элемент выполнен с возможностью функционирования в качестве Back-to-Back пользовательского агента (B2BUA SIP) SIP и, возможно, также в качестве SIP-прокси-сервера.

Логический элемент SBP 13 получает все SIP-сообщения от услуг 3 и 6 IMS с пунктом назначения для исходящего SIP-прокси-сервера 11 (P-CSCF). Это описано более подробно на фиг. 5. Исходящие SIP-сообщения от услуги 3 IMS подсистемы 2 модема идут от SIP-стека 4 к SIP-стеку 14 в SBP 13 через IP-стек 15, как указано пунктирными линиями со стрелками на фиг. 5. В подсистеме модема устанавливается фильтр 17 пакетов с IP-адресом и номером порта P-CSCF, и все пакеты от услуг 6 IMS в APE 5, соответствующие фильтру, направляются в SBP через IP-стек 15, как указано точечными линиями со стрелками на фиг. 5. SIP-стек 7 в APE 5 не знает о SBP. SIP-стек 7 в APE 5 ведет себя так, как если бы он отправлял и принимал SIP-сообщения напрямую в P-CSCF и от нее. Затем на основании SIP-сообщений, полученных логическим элементом SBP 13, SIP-сообщения отправляются от SIP-стека 14 через IP-стек 15 и доступ 18 к сотовой связи в P-CSCF внешнего SIP-прокси-сервера, как указано сплошными линиями со стрелками на фиг. 5. Эти SIP-сообщения либо могут быть полученными SIP-сообщениями, без существенных изменений, либо они могут быть объединены с другими полученными SIP-сообщениями, в зависимости от типа полученных SIP-сообщений, как это будет описано более подробно ниже.

Это также иллюстрируется на блок-схеме 100, представленной на фиг. 6. Сначала на этапе 101 SIP-сообщения от услуг IMS в подсистеме 2 модема и/или APE 5 получаются в логическом элементе SBP 13. Затем на этапе 102 SIP-сообщения, основанные на полученных SIP-сообщениях, отправляются в P-CSCF внешнего SIP-прокси-сервера.

SBP 13 может действовать в качестве B2BUA SIP для связанных с регистрацией SIP транзакций. Связанные с регистрацией SIP транзакции являются транзакциями SIP REGISTER и транзакциями SIP SUBSCRIBE и SIP NOTIFY для событий "reg" (регистрации). SBP объединяет сообщения SIP REGISTER от всех функционирующих услуг IMS так, чтобы одно единственное сообщение SIP REGISTER переносило информацию обо всех функционирующих услугах IMS на SIP-сервер-регистратор. Это иллюстрируется на фиг. 7. Кроме того, SBP может обрабатывать аутентификацию и сопоставление безопасности (SA) для исходящего SIP-прокси-сервера (P-CSCF). Каждая из этих транзакций описывается более подробно ниже.

Для связанных с регистрацией SIP транзакций SBP 13 действует в качестве B2BUA SIP. Действуя в качестве B2BUA SIP, SBP имеет различное поведение по отношению к различным объектам. С точки зрения какой-либо услуги IMS (либо в подсистеме 2 модема, либо в APE 5), SBP 13 выполняет связанные с регистрацией SIP транзакции, как если бы услуга IMS была единственной услугой IMS, функционирующей на мобильном телефоне. С точки зрения P-CSCF и S-CFCF SBP 13 выполняет связанные с регистрацией SIP транзакции от имени всех услуг IMS, функционирующих на мобильном телефоне.

Выполнение транзакций SIP REGISTER иллюстрируется на блок-схеме 200, показанной на фиг. 8.

Когда SBP 13 на этапе 201 принимает первое исходящее сообщение запроса SIP REGISTER от какой-либо услуги IMS, SBP обрабатывает сообщение следующим образом. На этапе 202 все параметры в сообщении SIP REGISTER, которые являются специфичными для этой услуги IMS, например теги признаков объектов в заголовке Контакта, сохраняются. Если на этапе 203 обнаруживается, что принятое сообщение запроса SIP REGISTER является первым сообщением, на этапе 204 отправляется новое сообщение запроса SIP REGISTER в P-CSCF с параметрами, специфичными для этой услуги IMS. Когда на этапе 205 от P-CSCF принят ответ SIP REGISTER, на этапе 206 SBP будет отсылать ответ SIP REGISTER обратно к услуге IMS исходящей связи.

Когда на этапе 201 SBP принимает другое исходящее сообщение запроса SIP REGISTER от какой-либо другой услуги IMS, SBP обрабатывает сообщение следующим образом. На этапе 202 сохраняются все параметры в сообщении SIP REGISTER, которые являются специфичными для этой услуги IMS, например теги признаков объекта в заголовке Контакта. Если на этапе 203 обнаруживается, что принятое сообщение запроса SIP REGISTER не является первым сообщением, на этапе 207 все параметры, специфичные для этой услуги IMS, объединяются со всеми параметрами, специфичными для всех других зарегистрированных услуг IMS. Затем на этапе 208 сообщение запроса SIP RE-REGISTER (перерегистрации) отправляется в P-CSCF с объединенными параметрами для всех зарегистрированных услуг IMS. Когда на этапе 205 будет получен ответ SIP REGISTER от P-CSCF, SBP на этапе 206 будет отсылать ответ SIP REGISTER обратно к услуге IMS исходящей связи.

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

Выполнение транзакций SIP SUBSCRIBE и SIP NOTIFY для событий "reg" иллюстрируется на блок-схеме 300, показанной на фиг. 9.

Когда на этапе 301 SBP 13 принимает первое исходящее сообщение запроса SIP SUBSCRIBE для событий "reg" от какой-либо услуги IMS, SBP будет обрабатывать сообщение следующим образом. На этапе 302 эта услуга IMS сохраняется как абонент для событий "reg". Если на этапе 303 обнаруживается, что принятое сообщение запроса SIP SUBSCRIBE является первым сообщением, на этапе 304 в P-CSCF отправляется новое сообщение запроса SIP SUBSCRIBE для событий "reg". Когда на этапе 305 принят ответ SIP SUBSCRIBE от P-CSCF, SBP 13 на этапе 306 отправляет ответ SIP SUBSCRIBE обратно к услуге IMS исходящей связи.

Когда на этапе 301 SBP 13 принимает другое исходящее сообщение запроса SIP SUBSCRIBE для событий "reg" от какой-либо другой услуги IMS, SBP обрабатывает сообщение следующим образом. На этапе 302 эта услуга IMS сохраняется как абонент для событий "reg". Если на этапе 303 обнаруживается, что принятое сообщение запроса SIP SUBSCRIBE не является первым сообщением, на этапе 307 к услуге IMS исходящей связи отсылается обратно ответ SIP SUBSCRIBE, и на этапе 308 сообщение запроса SIP NOTIFY отправляется к услуге IMS исходящей связи с информацией из последнего принятого сообщения запроса SIP NOTIFY от P-CSCF.

Когда SBP 13 на этапе 309 принимает от P-CSCF запрос SIP NOTIFY для события "reg", SBP на этапе 310 отсылает запрос SIP NOTIFY ко всем услугам IMS, которые являются абонентами для событий "reg", и на этапе 311 отсылает ответ SIP NOTIFY обратно в P-CSCF.

Кроме того, SBP 13 выполняет аутентификацию и сопоставление безопасности (SA) для исходящего SIP-прокси-сервера (P-CSCF). Таким образом, SBP автономно будет обрабатывать ответные SIP-сообщения с кодом 401 и 407 ответа. Это означает, что между SBP и услугами IMS имеются доверительные отношения как в подсистеме модема, так и в APE.

Выполнение входящих транзакций SIP OPTIONS описывается ниже в отношении блок-схемы 400 на фиг. 10.

Когда мобильный телефон на этапе 401 принимает сообщение запроса SIP OPTIONS без каких-либо заголовков Accept-Contact (принять контакт) или Reject-Contact (отклонить контакт), предполагается, что при составлении ответного сообщения SIP OPTIONS будут приняты во внимание все услуги IMS на мобильном телефоне.

SBP может обрабатывать входящий запрос SIP OPTIONS как B2BUA следующим образом. На этапе 402 запрос SIP OPTIONS направляется далее ко всем зарегистрированным услугам IMS на мобильном телефоне. На этапе 403 собираются все ответы SIP OPTIONS от зарегистрированных услуг IMS, и все принятые ответы SIP OPTIONS на этапе 404 объединяются в один общий ответ SIP OPTIONS, представляющий все зарегистрированные услуги IMS. Наконец, на этапе 405 объединенный ответ SIP OPTIONS отсылается обратно к отправителю запроса SIP OPTIONS.

Другие транзакции SIP, то есть транзакции SIP помимо связанных с регистрацией SIP транзакций и входящих транзакций SIP OPTIONS, могут быть выполнены посредством SBP любым из следующих способов:

- SBP действует в качестве B2BUA SIP;

- SBP действует в качестве адресного SIP-прокси-сервера без сохранения адресов;

- SBP действует в качестве адресного SIP-прокси-сервера с хранением адресов.

Эти три способа имеют разный уровень сложности реализации и различные требования к памяти. B2BUA SIP является самым сложным способом и имеет самое высокое требование к памяти. Таким образом, SBP может быть выполнен с возможностью работы в качестве SIP-прокси-сервера вместо B2BUA SIP для других транзакций SIP.

С описанным выше решением нет ни нерационального использования сетевых ресурсов, ни нерационального использования ресурсов обработки и сохранения в SIP-сервере-регистраторе. Кроме того, нет никаких требований к новым интерфейсам прикладного программирования между APE и подсистемой модема. Наконец, между различными услугами IMS нет взаимозависимостей. Каждая услуга IMS разрабатывается так, как если бы это была единственная услуга IMS на мобильном телефоне. Это важно, поскольку услуги IMS могут разрабатываться разработчиками сторонних фирм.

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