Предоставление услуг в системе связи

Предоставление услуг в системе связи

Иллюстрации

Показать все

Реферат

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

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

Уровень техники

Систему связи можно рассматривать как службу, которая обеспечивает связь между двумя или более сущностями, например пользовательским оборудованием, элементами сети связи и другими сущностями, связанными с системой связи. Система связи обычно действует в соответствии с данным стандартом или техническими условиями, который(ые) задает(ют), что разрешено делать различным сущностям, связанным с системой связи, и как этого добиться. Например, стандарт или технические условия может(могут) задавать, предоставляется ли пользователю или, точнее, пользовательскому оборудованию или терминалу услуга коммутации каналов и/или услуга коммутации пакетов. Также могут быть заданы протоколы и/или параметры связи, которые следует использовать для связи. Другими словами, для обеспечения связи посредством системы нужен определенный набор «правил», на которых может базироваться связь.

Системы связи, обеспечивающие беспроводную связь для пользовательского оборудования, известны. Примером беспроводных систем является сотовая сеть. В сотовых системах базовая приемопередающая станция (БППС) или аналогичная сущность доступа обслуживает мобильные станции (МС) или другое подобное пользовательское оборудование (ПО) через беспроводной интерфейс между этими сущностями. Связь между пользовательским оборудованием и элементами сети связи может быть основана на соответствующем протоколе связи. Работой аппаратуры базовой станции и другой аппаратуры, необходимой для связи, могут управлять одна или несколько управляющих сущностей. Различные управляющие сущности могут быть соединены между собой. Также могут быть обеспечены различные шлюзовые узлы для подключения сотовой сети к другим сетям, например к телефонной сети общего пользования (ТСОП) и/или другим сетям связи, например сетям на основе интернет-протокола (IP-сетям) и/или другим сетям с коммутацией пакетов.

Примером услуг, предоставляемых системами связи абонентам, являются так называемые мультимедийные услуги. Системы связи, способные предоставлять мультимедийные услуги, иногда называют мультимедийными IP-сетями. Функциональные возможности IP-мультимедиа (IM) могут обеспечиваться посредством подсистемы базовой сети (CN) IP-мультимедиа или, кратко, подсистемы IP-мультимедиа (IMS). IMS содержит различные сущности для предоставления мультимедийных услуг.

Системы связи развивались в направлении, в котором различные сетевые функции предоставления услуг находятся под управлением сетевых сущностей, именуемых серверами. Например, в современных архитектурах беспроводной мультимедийной сети третьего поколения (3G) предполагается, что несколько разных серверов используются для управления разными функциями. Эти функции включают в себя функции управления сеансом вызова (CSCF). Функции управления сеансом вызова можно разделить на несколько категорий, например посредническую функцию управления сеансом вызова (P-CSCF), опрашивающую функцию управления сеансом вызова (I-CSCF) и обслуживающую функцию управления сеансом вызова (S-CSCF). Очевидно, что иногда CSCF можно относить к функциям управления состоянием вызова или функциям управления сервером вызова.

Обслуживающая функция управления сеансом вызова образует сущность, на которой абоненту необходимо зарегистрироваться, чтобы иметь возможность запрашивать услугу у системы связи. Обслуживающую функцию управления сеансом вызова можно дополнительно подразделить на начинающую функцию управления сеансом вызова (O-CSCF) и оканчивающую функцию управления сеансом вызова (T-CSCF) на начинающем и оканчивающем концах сеанса. Помимо обслуживающей сущности управления, пользователю может потребоваться быть связанным с посреднической сущностью управления, например, P-CSCF. Посредническая сущность может быть назначена области, где обслуживается пользователь.

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

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

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

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

Например, стандарты для сетей IMS 3GPP (проект сотрудничества по третьему поколению) выпуск 5 (Rel-5) задают правила, как пользовательское оборудование (ПО) может начинать сеансы и единичные транзакции. Однако правила, приведенные в Rel-5, сосредоточены только на том, как применять так называемые критерии начинающей фильтрации. Выпуск 5 не позволяет третьей стороне начинать сеанс или транзакцию со стороны пользователя. Выпуск 6 стандартов 3GPP требует, чтобы сервер приложений (СП) имел возможность посылать запросы протокола инициирования сеанса (SIP) со стороны пользовательского оборудования через интерфейс ISC (Управление мультимедийными IP-услугами) на S-CSCF. Однако даже современный выпуск 6 стандартов 3GPP не обеспечивает никакого механизма для сервера приложений (СП), позволяющего серверу приложений это делать, иначе чем в исключительных случаях, когда запросы, исходящие от сервера приложений, непосредственно возбуждаются запросами, исходящими от пользовательского оборудования. Поэтому сервер приложений по-прежнему не способен выполнять услуги, которые генерируют запросы SIP или другой запрос со стороны пользователя.

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

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

Например, когда S-CSCF принимает сообщение, она должна иметь возможность принимать решение, как обрабатывать сообщение. В современных системах S-CSCF может применять к сообщению критерии фильтрации, именуемые «начинающая фильтрация» и «оканчивающая фильтрация». Термин «критерии фильтрации» (КФ) означает информацию, которая задает соответствующие триггеры точки обслуживания (SPT) для конкретного приложения услуги. В среде связи SIP критерии фильтрации задают подмножество запросов SIP, принимаемых S-CSCF, которые следует посылать или передавать через посредника на конкретное приложение услуги. S-CSCF может принимать критерии фильтрации от собственного сервера абонента (ССА) или сервера приложений (СП).

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

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

Раскрытие изобретения

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

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

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

сущность управления связью, способная обслуживать пользователя системы связи,

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

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

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

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

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

Первая сущность может генерировать начинающий запрос со стороны пользователя.

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

Первая сущность может выбрать порт, куда должен быть отправлен запрос.

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

Первая сущность может направить на сущность хранения запрос информации, относящейся к сущности управления связью, способной обслуживать пользователя.

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

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

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

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

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

фиг. 1 - система связи, в которой может быть реализовано изобретение;

фиг. 2 - вариант осуществления настоящего изобретения;

фиг. 3 и 4 - другие варианты осуществления;

фиг. 5 - логическая блок-схема предоставления услуги посредством вариантов осуществления.

Осуществление изобретения

Рассмотрим фиг. 1, где показана мультимедийная IP-сеть, в которой можно реализовать настоящее изобретение. IP-мультимедийные услуги могут предоставляться абонентам мультимедийной IP-сети. Функциональные возможности IP-мультимедиа (IM) могут обеспечиваться посредством подсистемы базовой сети (CN), содержащей различные сущности для предоставления услуги.

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

В показанной компоновке базовая станция 11 обеспечивает сущность доступа сети сотовой связи. Сетью 11 радиодоступа управляет соответствующий контроллер (для ясности не показан). Контроллер может быть обеспечен для каждой базовой станции, или контроллер может управлять совокупностью базовых станций. Известны также решения, в которых контроллеры обеспечены как на отдельных базовых станциях, так и на уровне сети радиодоступа для управления совокупностью базовых станций. Таким образом, очевидно, что название, местоположение и количество контроллеров сети доступа зависит от системы. Например, в наземной сети радиодоступа UMTS (UTRAN) может использоваться узел контроллера, именуемый контроллером радиосети (КРС). В GSM и CDMA2000 сущность, соответствующая контроллеру радиосети, называется контроллером базовой станции (КБС).

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

Базовая станция 11 предназначена для передачи сигналов на мобильное пользовательское оборудование 10 мобильного пользователя, т.е. абонента, и приема сигналов от него через беспроводной интерфейс. Соответственно, мобильное пользовательское оборудование 10 способно передавать сигналы на базовую станцию и принимать сигналы от нее через беспроводной интерфейс. Мобильный пользователь может использовать любое подходящее мобильное устройство, приспособленное для связи по интернет-протоколу (IP) для подключения к сети. Например, мобильный пользователь может осуществлять доступ к сотовой сети посредством персонального компьютера (ПК), карманного персонального компьютера (КПК), мобильной станции (МС) и т.д. Следующие примеры описаны применительно к мобильным станциям.

Специалисты в данной области знакомы с особенностями и принципами работы обычной мобильной станции. Таким образом, подробное описание не требуется. Достаточно заметить, что пользователь может использовать мобильную станцию 10 для таких задач, как делание и прием телефонных вызовов, для приема и передачи данных в и от сети и для воспроизведения, например, мультимедийного содержимого. Мобильная станция может содержать антенный элемент для беспроводного приема и передачи сигналов с и на базовые станции сети мобильной связи. Мобильная станция 10 также может быть снабжена дисплеем для отображения изображений и другой графической информации для пользователя мобильного пользовательского оборудования. Обычно также предусмотрено средство громкоговорителя. Работой мобильного пользовательского оборудования можно управлять посредством соответствующего пользовательского интерфейса, например кнопок управления, речевых команд и пр. Кроме того, мобильное пользовательское оборудование снабжено сущностью процессора и средством памяти. Очевидно, что, хотя на фиг.1 для ясности показана только одна мобильная станция, с каждой базовой станцией системы мобильной связи может одновременно находиться на связи несколько мобильных станций.

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

В современных архитектурах беспроводной мультимедийной IP-сети третьего поколения (3G) предполагается, что несколько разных серверов используются для управления разными функциями. Эти функции включают в себя функции управления сеансом вызова (CSCF). Функции управления сеансом вызова можно разделить на несколько категорий, например посредническую функцию 12 управления сеансом вызова (P-CSCF), опрашивающую функцию 24 управления сеансом вызова (I-CSCF) и обслуживающую функцию 14 управления сеансом вызова (S-CSCF).

Обслуживающая функция 14 управления сеансом вызова образует сущность, на которой регистрируется абонент 10. Регистрация необходима, чтобы иметь возможность запрашивать услугу у системы связи. Пользователь может регистрироваться через сущность доступа системы связи, например базовую станцию 11. Обслуживающую функцию 14 управления сеансом вызова можно рассматривать как обеспечивающую начинающие функции управления сеансом вызова (O-CSCF) и оканчивающие функции управления сеансом вызова (T-CSCF) на начинающем и оканчивающем концах сеанса или транзакции.

Пользователь может одновременно быть зарегистрированным в более чем одной функции управления сеансом вызова. Помимо обслуживающей сущности 14 управления пользователю может понадобиться быть связанным с посреднической сущностью управления, например P-CSCF 12, показанной на фиг.1. Посредническая сущность 12 может быть назначена области, в которой пользователь осуществляет роуминг. Таким образом, когда пользователь осуществляет доступ к сети через сеть доступа произвольного типа, сеть доступа может назначить посредническую сущность управления для управления услугами, доступными из этой точки зрения сети, например, для управления пропускной способностью. Возможно также, что пользователь может искать и находить надлежащую P-CSCF с помощью своего пользовательского оборудования, без помощи сети доступа.

Собственный сервер абонента (ССА) 20 также известен. Как объяснено выше, собственный сервер абонента (ССА) 20 предназначен для хранения информации абонента, т.е. относящейся к пользователю. Собственный сервер абонента (ССА) могут запрашивать другие функциональные сущности по соответствующим интерфейсам, например, в ходе процедур установления вызова.

Сервер 22 приложений, взаимодействующий с собственным сервером 20 абонента (ССА) и обслуживающей функцией 14 управления сеансом вызова (S-CSCF), также известен. В общем случае, сервер приложений можно рассматривать как сущность, которая вмещает в себя услугу(и), доступную(ые) в сеансах/транзакциях в соответствии с подпиской пользователя. Маршрутизация на сервер приложений может осуществляться в результате оценивания критерия фильтрации, который связан с подпиской пользователя.

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

Когда сервер 22 приложений начинает сеанс или транзакцию, посылая сообщение на S-CSCF 14, S-CSCF 14 должна принять решение, в какой роли действовать. Если S-CSCF 14 выбирает действовать в начинающей роли, то S-CSCF применяет критерии начинающей фильтрации ко входящему сообщению. В оканчивающей роли S-CSCF оценивает критерии оканчивающей фильтрации. Ниже будут рассмотрены различные способы реализации выбора. В зависимости от роли S-CSCF может затем построить адрес услуги, который она возвращает на P-CSCF в ответ на сообщение регистрации. Затем P-CSCF должна использовать этот адрес при пересылке сообщений на S-CSCF.

Предпочтительно, чтобы S-CSCF 14 передавала в ходе регистрации на ССА 20 адрес, который должен использоваться при окончании сеансов или транзакций. Согласно предпочтительному варианту осуществления, показанному на фиг.2, сервер 14 приложений принимает от ССА 20 информацию адреса, относящуюся к S-CSCF 14, на которой регистрируется пользовательское оборудование 10. Информация адреса может предоставляться по запросу, например по интерфейсу Sh между сущностями, см. этап 1 фиг.2. Информация адреса может иметь вид любой подходящей информации, например имени S-CSCF или URI (универсального идентификатора ресурсов) S-CSCF.

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

На фиг.2 сервер 20 приложений обозначен номером этапа 2 как ответственный за конфигурацию информации адреса. В частности, сервер 22 приложений может изменять информацию адреса, чтобы абоненту предоставлялся соответствующий тип услуги. Например, сервер 20 приложений может изменить имя услуги, чтобы построить правильный адрес для нужной услуги. Имя S-CSCF можно изменить, например, добавив параметры указателя "term" или "orig" в качестве префикса к имени, принятого от ССА. Например, адрес

scscf12.operator.net имя

можно изменить на один из следующих в зависимости от того, является ли сеанс или транзакция, который(ую) начинает сервер приложений, начинающим(ей) или оканчивающим(ей) сеансом или транзакцией:

orig.scscf12.operator.net или

term.scscf12.operator.net

На этапе 3 происходит разрешение адреса с помощью DNS (системы доменных имен) 26 для получения IP-адреса соответствующей услуги.

В зависимости от изменения адрес направляет сообщения на начинающую или оканчивающую услугу. Таким образом, сервер 22 приложений снабжается средством, посредством которого он может маршрутизировать сообщение запроса услуги либо на начинающую услугу, либо на оканчивающую услугу на этапе 4. Как показано на фиг.1, это может происходить на интерфейсе ISC (управления мультимедийными IP-услугами).

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

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

Возможно также, что адрес изменяется только в случае оканчивающих услуг, и в случае начинающих услуг никакого изменения адресов не производится.

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

Нижеследующий пример более подробно иллюстрирует возможный порядок работы в соответствии с вышеописанными принципами. Предположим, что сервер приложений дает оканчивающий адрес от ССА. Пусть, например, адрес протокола инициирования сеанса (SIP) имеет вид (заметим, что пользовательская часть может быть опущена):

xx44@scscf7.operator.net

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

Если сервер 22 приложений намеревается начать начинающий/ую сеанс/транзакцию, то он изменяет адрес. Для этого можно добавить в адрес новый параметр «роль». Таким образом, измененный адрес, включающий в себя параметр роли role=orig, может, например, иметь вид

xx44@scscf7.operator.net;role=orig

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

Адрес S-CSCF можно конфигурировать на сервере 22 приложений, где требуется адрес. Альтернативно, адрес можно конфигурировать на всех серверах приложений. Последняя альтернатива может иметь преимущество, например, в случаях, когда не существует интерфейса Sh от сервера приложений 22 к собственному серверу абонента 20 или когда интерфейс временно недоступен.

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

Возможность для построения адреса состоит в том, что параметр хранится на ССА 20 совместно с адресом S-CSCF 14. Затем сервер 22 приложений может построить правильный адрес, используя информацию адреса и параметра из ССА в качестве входных данных процесса изменения.

Согласно возможности, показанной на фиг.3, сервер 22 приложений делает запрос DNS (системе доменных имен) на основании информации адреса, возвращенной от САА на этапе 1. Возвращенное имя S-CSCF можно использовать для запрашивания, например, записей ресурсов SRV для отыскания адреса и порта, где доступна нужная услуга (начинающая или оканчивающая). SRV - это записи ресурсов (RR) DNS для указания местонахождения услуг (DNS SRV). Использование записей ресурсов SRV позволяет запрашивать конкретную услугу и/или протокол для конкретного домена. Тогда ответ будет включать в себя имя любого доступного сервера, отвечающего критериям.

Например, можно сделать следующий запрос DNS из записей ресурсов SRV, когда следует оценивать критерии начинающей фильтрации. В записи ресурсов SRV обычно указаны протокол и услуга. Записи SRV можно запрашивать на этапе 2, например, используя в качестве аргумента следующий адрес:

_orig._sip.scscf12.operator.net

Ответом на этапе 2 может быть советом маршрутизировать по указанному адресу "orig.scscf12.operator.net" с использованием порта 5060:

_orig._sip.scscf12.operator.net SRV 0 0 5060 orig.scscf12.operator.net.

Альтернативно, ответом может быть маршрутизация на указанный порт 55334 с исходным адресом "scscf12.operator.net":

_orig._sip.scscf12.operator.net SRV 0 0 55334 scscf12.operator.net.

Следующий аргумент можно использовать в запросе DNS (SRV), когда следует оценивать критерии оканчивающей фильтрации:

_term._sip.scscf12.operator.net.

Ответом может быть совет маршрутизировать по указанному адресу "term.scscf12.operator.net" с использованием порта 5060:

_term._sip.scscf12.operator.net SRV 0 0 5060 term.scscf12.operator.net.

Или, как выше, ответом может быть, например, маршрутизация на указанный порт 55335 с исходным адресом "scscf12.operator.net":

_term._sip.scscf12.operator.net SRV 0 0 55335 scscf12.operator.net.

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

Затем сервер приложений может разрешить адрес с помощью DNS на этапе 3 и маршрутизировать на этапе 4 сообщения по указанному адресу и/или на указанный порт.

Согласно другой возможности база данных абонентов (например, ССА 20) возвращает на этапе 1 имя S-CSCF. Затем сервер приложений делает запрос DNS с помощью возвращенного имени S-CSCF на предмет записей ресурсов NAPTR (указателя службы присвоения имен) для отыскания доступных услуг (начинающих и/или оканчивающих). На основании ответа сервер приложений может маршрутизировать сообщение запроса по нужному адресу. Этот вариант осуществления позволяет использовать DNS для поиска услуг для широкого диапазона имен ресурсов, которые не соответствуют синтаксису имен домена. Возможные имена ресурсов включают в себя URI услуг.

Ниже приведен пример запроса NAPTR с помощью SRV. Запрос DNS можно делать, спрашивая записи ресурсов (RR) NAPTR с использованием доменной части адреса S-CSCF, например

scscf12.operator.net

В результате может получиться:

IN NAPTR 100 10 "S" "sip+orig" ""_orig._sip.scscf12.operator.net.

IN NAPTR 100 10 "S" "sip+term" "" _term._sip.scscf12.operator.net.

Поскольку поля порядка и предпочтения равны, можно выбрать любую из RR. Если необходим адрес для S-CSCF для начинающих сеансов/транзакций, можно выбрать первый адрес. Флаг "S" указывает, что следующий запрос DNS будет сделан на предмет RR SRV. Затем можно сделать запрос DNS на предмет RR SRV с помощью доменного имени, т.е. вышеупомянутого адреса

_orig._sip.scscf12.operator.net.

Результатом запроса DNS может быть IP-адрес или любая другая подходящая информация маршрутизации.

Возможно также реализовать NAPTR без запроса SRV. Как и выше, запрос DNS можно сделать на предмет RR NAPTR с использованием доменной части адреса S-CSCF, например

scscf12.operator.net

В результате может получиться

IN NAPTR 100 10 "A" "sip+orig" "" orig.scscf12.operator.net.

IN NAPTR 100 10 "A" "sip+term" "" term.scscf12.operator.net.

Поскольку поля порядка и предпочтения равны, можно выбрать любую из RR. Если необходим адрес для S-CSCF для начинающих сеансов/транзакций, можно выбрать первую. Флаг "A" указывает, что следующий запрос DNS делается на предмет записей ресурсов A, AAAA или A6 SRV. Затем можно сделать запрос DNS на предмет RR A, AAAA или A6 с доменным именем orig.scscf12.operator.net. В результате запроса будет получен IP-адрес.

Согласно первой альтернативе запрос DNS, сделанный на предмет RR NAPTR с использованием доменной части адреса S-CSCF (например, scscf12.operator.net), может дать следующий результат:

IN NAPTR 100 10 "U" "sip+orig" "!(^.$)!sip:orig.\1!".

IN NAPTR 100 10 "U" "sip+term" "!(^.$)!sip:term.\1!".

Преимущество этой альтернативы в том, что все S-CSCF обычно имеют общие записи ресурсов NAPTR. Поскольку поля порядка и предпочтения равны, можно выбрать любую из RR и таким образом можно выбрать первую для начинающего/ей сеанса/транзакции. Флаг "U" указывает, что результатом будет URI. Тогда результат может иметь вид

sip:orig.scscf 12.operator.net.

Доменная часть URI разрешается до IP-адреса посредством запроса DNS. Запрос DNS можно делать на предмет RR A, AAAA или A6 с помощью доменного имени, и результатом будет IP-адрес.

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

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

scscf12.operator.net,

добавив тег, символ, строку символов или строку битов в качестве пользовательской части, строя таким образом адрес для начинающей услуги (или наоборот):

orig@scscf12.operator.net

В вышеописанных вариантах осуществления в ССА хранится только один адрес S-CSCF. В примерах роли затем сигнализируются на S-CSCF посредством измененного адреса, который может состоять из измененной пользовательской части, измененного имени хоста или домена, измененного номера порта, параметра, добавленного к адресу или их комбинации. В предпочтительном режиме работы при наличии параметра или изменении адреса S-CSCF должна действовать в начинающей роли. Если нельзя найти добавленного параметра или адрес не изменился, то S-CSCF действует в оканчивающей роли.

Однако в ССА возможно хранить два адреса (т.е. адрес для начинающей и адрес для оканчивающей роли) S-CSCF. Таким образом, согласно другому варианту осуществления, показанному на фиг.4, в собственном сервере 20 абонента (ССА) хранятся более одного адреса для S-CSCF.

В частности, ССА 20 может хранить один адрес S-CSCF для запуска критериев начинающей фильтрации и другой для за