Взаимодействие сетевых элементов на уровне ядра подсистемы

5.3.1 Идентификация абонентов. IMPI – IP multimedia private identity является глобальным уникальным идентификатором, определяется оператором домашней сети. Он используется в домашней сети, чтобы однозначно определить тип подписки пользователей. Во время регистрации, IMPI используется для проверки подлинности [5].

IMPI имеет следующие особенности:

– одному IMPI соответствует один физический терминал, и соответствует контекст безопасности на стороне сети. Он похож на IMSI в GSM сетях;

– один IMPI связан с одним или более IMPU, но, так же может и не соответствовать IMPU;

– IMPI являются неотъемлемыми данными пользователей. Он хранится в HSS и терминале, а так же хранится в S-CSCF как динамические данные.

Например, IMPI: [e-mail].

1.5.2 IMPU – IP multimedia public identity идентифицирует абонента. Используется также для коммуникационных запросов с другими пользователями. Имя является глобально уникальным. Если абонент зарегистрирован, то это означает, что IMPU абонента зарегистрирован [5].

IMPU имеет следующие особенности:

– один или несколько IMPU могут быть связаны с одним профилем служб;

– IMPU могут быть зарегистрированы явно или неявно;

– IMPU могут быть общими:

– если один IMPU является общим, он связан со всеми IMPI в подписке IMS;

– если есть только один IMPI в подписке IMS, IMPU в подписке IMS не могут быть общими;

– IMPU является неотъемлемыми данными пользователей. Они хранится в HSS и в терминале, как и ISIM, и хранится в S-CSCF как динамические данные.

Терминал хранит по крайней мере один IMPU;

IMPU в формате SIP URI или TEL URI:

– формат SIP URI sip: [e-mail];

– формат URI TEL tel: [phone].

Профиль службы – это набор сервисных и абонентских данных. Он подразделяется на следующие виды:

– основной профиль IMS службы;

– добавочный профиль приложения – это профиль обслуживания абонентов.

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

 

 

Рисунок 5.7 – Соответствие между IMS подпиской и профилем службы

 

Основные зависимости:

– одна часть подписки IMS (SUBID) связана с одним или более IMPI;

– один IMPI связан с одним или более IMPU;

– один или несколько IMPU связаны с одним профилем службы.

Абонент получает IP-адрес после подключения к сети доступа IP. После получения IP-адреса, абонент получает IP-адрес P-CSCF. В этой точке абонент может быть зарегистрирован в сети IMS. Если сеть позволяет, IP-адреса терминалов и P-CSCF также могут быть настроены на терминалах как статические IP адреса.

P-CSCF является точкой входа в сеть IMS. Для взаимодействия с сетью IMS, оборудование пользователя (UE) должно знать IP-адрес, по крайней мере одного P-CSCF. Механизм, используемый UE для нахождения P-CSCF называется Р-CSCF discovery.

5.3.2 Назначение IP-адресов. Сетевым элементом, отвечающим за выделение IP-адресов, в платформе IMS, является NACF (Network Access Configuration Function) и CLF (Connectivity Session Location and Repository Function). NACF – производит назначение IP-адреса абонента, выдаёт настройки сети, и следит за сроком аренды адресов. CLF – устанавливает взаимосвязь между: IP-адресом, выделенным NACF, и идентификатором доступа; идентификатором доступа и информации о географическом местоположении абонента. Хранит идентификатор пользователя, который взаимосвязан с его IP-адресом; QoS конфигурацию; идентификатор доступа [6].

На рисунке 5.8 представлен процесс получения IP-адреса для г. Екатеринбурга, абонент имеет IMPU sip: [e-mail].

 

 

Рисунок 5.8 – Процесс получения IP-адреса

 

Первоначально абонент выполняет широковещательный запрос с целью обнаружить доступные DHCP-серверы. Он отправляет сообщение типа DHCPDISCOVER. В тело сообщения помещаются поля:

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

– Chaddr – помещается аппаратный адрес (MAC-адрес) абонента.

– Giaddr – IP-адрес агента ретрансляции, который участвовал в процессе доставки сообщения, в данном случае это IP-адрес P-CSCF01.

После получения запроса DHCP от оборудования пользователя (UE –User Equipment), NACF выбирает необходимый пул IP-адресов на основании параметра Giaddr, находящемся в запросе. Затем NACF выбирает доступный IP-адрес из пула адресов, собирает соответствующие параметры настройки сети из UAAF, а также определяет параметры аренды DHCP, и отправляет всю информацию UE в теле-сообщения DHCPOFFER, на его MAC адрес.

Приняв конфигурацию, абонент отправляет запрос DHCP (DHCPREQUEST). Он рассылается широковещательно; при этом к опциям, указанным абонентом в сообщении DHCPDISCOVER, добавляется специальная опция – идентификатор сервера – указывающая адрес DHCP-сервера, в данном случае это IP-адрес NACF01. Cервер подтверждает запрос и направляет это подтверждение (DHCPACK) абоненту. После этого абонент должен настроить свой сетевой интерфейс, используя предоставленные опции.

Через DHCP NACF реализует динамическое распределение IP-адресов оборудованию пользователей в сети IP. До истечения срока аренды, UE может продлить срок путём повторного DHCP запроса. Если истекает срок аренды, то есть, NACF не получает запрос DHCP от UE, выделенный IP-адрес возвращается в пул IP-адрес для переназначения.

При обработке запроса DHCP CLF получает и хранит информацию о местоположении пользователя, а именно: идентификатор доступа, включая номер шасси, номер слота, и типа порта, а так же информации о географическом местоположении абонента. CLF хранит информацию местоположения пользователя для будущих запросов от P-CSCF.

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

5.3.3 Принципы аутентификации. Сетевым элементом, отвечающим за авторизацию и аутентификацию, в платформе IMS, является HSS (Home Subscriber Server), который выполняет функции базы пользовательских данных.

Сервер HSS обеспечивает открытый доступ в режиме чтения/записи к индивидуальным данным пользователя, связанным с услугами. В HSS реализуется также функции SLF (Subscriber Locator Function), которая определяет положение конкретного абонента (сеть регистрации), в ответ на запрос от модуля I-CSCF или от сервера приложений [7].

Аутентификация абонента необходима для подтверждения подлинности абонента и обеспечения безопасности доступа. HSS поддерживает несколько схем аутентификации:

– IMS аутентификация с подтверждением ключа IMS AKA (Authentication and Key Agreement);

– HTTP Digest authentication (HDA), для SIP терминалов.

2.3.2 IMS AKA – это механизм, используемый для взаимной проверки подлинности между оборудованием пользователя и сетью IMS. Это обеспечивает конфиденциальность и целостность сети IMS.

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

IMS AKA следует принципу «запрос-ответ». Он поддерживает взаимную аутентификацию между UE и сетью IMS.

В подсистеме IMS, IMPI рассматривается как проверка подлинности идентификатора UE. Аутентификация реализуется через общий ключ, порядковый номер (SQN), и проверку подлинности между HSS и ISIM.

На рисунке 5.9 приведён пример процесса аутентификации IMS AKA. Абонент имеет IMPU sip:[e-mail].

 

 

Рисунок 5.9 – IMS AKA процесс аутентификации пользователя

услуг платформы IMS

 

UE отправляет запрос регистрации REGISTER на P-CSCF. В сообщении REGISTER включается его IMPI=:[e-mail], и его IMPU:

sip:[e-mail].

При получении данного сообщения, P-CSCF направляет запрос на I-CSCF.

I-CSCF направляет запрос в HSS, для определения обслуживающего этого абонента S-CSCF и определения типа аутентификации, после получения информации из базы данных, I-CSCF передаёт запрос S-CSCF.

После этого S-CSCF отправляет сообщение протокола DIAMETER – MAR (Multimedia Auth Request) в HSS для запроса вектора аутентификации (AVs).

HSS получает запрос и в ответ к S-CSCF отправляет значение вектора аутентификации в сообщении MAA (Multimedia Auth Answer).

S-CSCF выбирает вектора аутентификации и отправляет ответ 401 в I-CSCF. Этот ответ содержит пять переменных аутентификации, а именно: ожидаемый ответ (XRES), случайный отклик (RAND), знак аутентификации (AUTN), ключ целостности (IK) и ключа шифрования (СК). S-CSCF хранит XRES, чтобы проверить ответы от UE.

I-CSCF пересылает ответ 401 на P-CSCF.

После получения ответа 401, P-CSCF сохраняет параметры IK и CK, а RAND и AUTN пересылает в запросе UE.

UE рассчитывает сообщение RES, основываясь на полученных переменных RAND и AUTN.

UE проверяет AUTN на основе открытых ключей и SQN. Успешная проверка AUTN свидетельствует об успешной аутентификации сети. Это означает что аутентификационные данные пришли из домашней сети оператора.

UE рассчитывает RES на основе открытых ключей и полученного RAND.

UE рассчитывает IK, так что IK становится общим у P-CSCF и ОП.

UE отправляет второе сообщение REGISTER содержащее RES в P-CSCF.

P-CSCF перенаправляет запрос на I-CSCF.

I-CSCF направляет запрос в HSS, после получения информации из базы данных, I-CSCF передаёт запрос S-CSCF.

S-CSCF принимает RES и сравнивает его с XRES. Если RES совпал с XRES, ОП может пройти проверку подлинности.

S-CSCF отправляет сообщение SAR (Server-Assignment-Request) в HSS чтобы обновить флаг регистрации UE в HSS:

– если IMPU UE не зарегистрировано, S-CSCF изменяет статус IMPU на зарегистрированный;

– если IMPU UE зарегистрировано, S-CSCF сохраняет IMPU и обновляет таймер регистрации.

HSS отправляет сообщение SAA содержащее профиль пользователя в S-CSCF.

S-CSCF отправляет ответ 200 (OK) в I-CSCF. Ответ означает, успешную аутентификацию.

I-CSCF пересылает ответ 200 (OK) в P-CSCF.

P-CSCF пересылает ответ 200 (OK) в UE.

Процесс HTTP Digest применяется, когда фиксированный SIP терминал не имеет модуля идентификации абонента (SIM), UMTS Subscriber Identity Module (USIM), или ISIM, а так же не поддерживает аутентификацию IMS AKA.

HTTP Digest поддерживает только один путь аутентификации, т.е., только сеть может проводить аутентификацию терминала, при этом терминал не может проверить подлинности сети.

HTTP Digest является механизмом проверки подлинности на основе HTTP. Его параметры аутентификации – это имя пользователя и пароль. Подписчики получают доступ к сети IMS, введя имя пользователя и пароль на терминалах.

На рисунке 5.10 приведён пример процесса аутентификации HTTP Digest.

Абонент имеет IMPU sip: sip:[e-mail].

 

Рисунок 5.10 – HTTP Digest процесс аутентификации пользователя

услуг подсистемы IMS

 

UE отправляет запрос регистрации REGISTER на P-CSCF. В сообщении REGISTER включается его домен – 3gpp.ims.com, User name=abcdef и Password=123456.

При получении данного сообщения, P-CSCF направляет запрос на I-CSCF.

I-CSCF направляет запрос в HSS, для определения обслуживающего этого абонента S-CSCF и определения типа аутентификации, после получения информации из базы данных, I-CSCF передаёт запрос S-CSCF.

После этого S-CSCF отправляет MAR сообщение в HSS для запроса аутентификационной информации.

HSS получает MAR сообщение и определяет что это для HTTP Digest аутентификации. HSS рассчитывает HA1 на основе параметров Digest-Realm, User Name, и Password. Digest-Realm содержится в MAR сообщении. User Name и Password находятся в IMPU.

HSS отправляет MAA-сообщение, содержащее HA1 (шестнадцатеричная строка, содержащая информацию об аутентификации: имя пользователя, домен, пароль) в S-CSCF.

S-CSCF хранит HA1 и генерирует параметры для аутентификации вызова, такие как параметр nonce. Так же S-CSCF генерирует поле WWW-Authenticate заголовка на основе параметров, а затем отправляет ответ 401, содержащий поле заголовка, оборудованию пользователя.

I-CSCF пересылает ответ 401 на P-CSCF.

P-CSCF пересылает ответ 401 оборудованию пользователя.

UE вычисляет значение response с конкретным алгоритмом ключа основанным на User Name, Password, и nonce. После этого UE отправляет еще один запрос REGISTER и помещает значение ответа в поле заголовка авторизации.

После получения сообщения REGISTER S-CSCF вычисляет значение request-digest с помощью HA1. Тогда S-CSCF сравнивает результат со значением response в поле заголовка авторизации. Если два значения совпадают, проверка подлинности пройдена успешно.

S-CSCF отправляет сообщение SAR (Server-Assignment-Request) в HSS чтобы обновить флаг регистрации UE в HSS:

– если IMPU UE не зарегистрировано, S-CSCF изменяет статус IMPU на зарегистрированный. Если IMPU ОП зарегистрировано, S-CSCF сохраняет IMPU и обновляет таймер регистрации;

– если IMPU в IRS, то S-CSCF рассматривает все IMPU в IRS как зарегистрированные. S-CSCF запрашивает загрузку профиля пользователя из HSS.

HSS отправляет сообщение SAA содержащее профиль пользователя в S-CSCF;

S-CSCF отправляет ответ 200 (OK) в I-CSCF. Ответ означает, успешную аутентификацию.

I-CSCF направляет ответ 200 (OK) в P-CSCF.

P-CSCF направляет ответ 200 (OK) в UE.

5.3.4 Регистрация абонентов. Процесс регистрации в IMS – это процесс, при котором IMS абоненты запрашивают разрешение на использование IMS услуг.

IMS предоставляет услуги для трех типов абонентов.

Первый тип – IMS-абонент. IMS пользователи идентифицируются по IMPI и IMPU. IMS AKA аутентификация и Hypertext Transfer Protocol (HTTP) аутентификация, применимы к таким пользователям.

Второй тип – абоненты с коммутацией пакетов (PS) или коммутацией каналов (CS). PS или CS ядра используют международный идентификатор мобильного абонента (IMSI) или международный номер ISDN мобильной станции (MSISDN). IMS AKA аутентификация применима к таким пользователям.

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

Процесс регистрации. Регистрацию можно разделить на два типа: первичная регистрация (базовая) и перерегистрация.

Процесс базовой регистрации. Абонент IMS может инициировать регистрацию в любых условиях. После успешной регистрации, P-CSCF, HSS, и S-CSCF записывают регистрационную информацию об абоненте. После этого, абонент может участвовать в инициировании других сессий.

На рисунке 5.11 приведён пример процесса базовой регистрации, абонент имеет IMPU sip:[e-mail].

 

Рисунок 5.11 - Базовый процесс регистрации пользователя

услуг подсистемы IMS

UE посылает запрос REGISTER в P-CSCF для начала регистрации.

P-CSCF запрашивает DNS для получения IP-адреса I-CSCF основываясь на имени, домашней области, содержащимся в сообщении REGISTER. После этого, P-CSCF передает сообщение REGISTER в I-CSCF.

I-CSCF обрабатывает сообщение REGISTER и находит IP-адрес HSS. После этого, I-CSCF отправляет сообщение запроса авторизации пользователя UAR (User-Authorization-Request) в HSS, чтобы получить IP-адрес S-CSCF.

HSS обрабатывает сообщение UAR и определяет, может ли UE быть зарегистрировано. HSS отправляет сообщение ответ авторизации пользователя UAA (User-Authorization-Answer) в I-CSCF, в котором содержатся адреса доступных S-CSCF.

I-CSCF выбирает соответствующий S-CSCF и посылает сообщение REGISTER на S-CSCF.

S-CSCF посылает сообщение запроса мультимедийной авторизации MAR в HSS для извлечения данных аутентификации и информировании HSS.

HSS генерирует данные аутентификации на основе информации об абоненте в MAR-сообщении, а затем отправляет сообщение ответ мультимедиа авторизации MAA в S-CSCF.

S-CSCF может отправить ответ 401 на UE для инициализации вызова UE. UE рассчитывает на основе RES 401 ответ и генерирует сообщение REGISTER. Тогда ОП посылает сообщение REGISTER на S-CSCF, следуя пути, соответствующему первому отправленному сообщению REGISTER.

S-CSCF проверяет подлинность ответа RES от UE. Если ответ верен, аутентификация пройдена успешна.

S-CSCF посылает сообщение – запрос серверу назначения SAR в HSS для запроса обновленного статуса абонента.

HSS обновляет информацию об абоненте, основываясь на IP-адресе S-CSCF из сообщения РСА, а затем отправляет сообщение – ответ сервера назначения SAA в S-CSCF. SAA сообщение содержит профиль пользователя.

S-CSCF отправляет ответ 200 (OK) в I-CSCF. Ответ означает успешную аутентификацию.

I-CSCF передаёт ответ 200 (OK) на P-CSCF.

P-CSCF передаёт ответ 200 (OK) на ОП.

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

Процесс перерегистрации похож на основной процесс регистрации. Разница заключается в следующем: Во время перерегистрации, S-CSCF знает, что это перерегистрации, и серверу не нужно инициировать проверку.

На рисунке 5.12 приведён пример процесса перерегистрации для г. Екатеринбурга, абонент имеет IMPU sip:[e-mail].

UE посылает запрос REGISTER в P-CSCF для начала регистрации.

P-CSCF запрашивает DNS для получения IP-адреса I-CSCF основываясь на имени, домашней области, содержащимся в сообщении REGISTER. После этого, P-CSCF передает сообщение REGISTER в I-CSCF.

I-CSCF посылает сообщение UAR в HSS чтобы получить IP-адрес S-CSCF;

HSS определяет, будет ли пользователь зарегистрирован. HSS посылает сообщение UAA в I-CSCF, в котором содержатся адреса доступных S-CSCF.

I-CSCF выбирает соответствующий S-CSCF и посылает сообщение REGISTER на S-CSCF.

S-CSCF проверяет аутентификационную информацию, предоставленную ОП. Если проверка подлинности завершается успешно, S-CSCF обновляет таймер регистрации.

S-CSCF отправляет сообщение SAR в HSS для обновления записи об абоненте и запрашивает профиль пользователя.

HSS отправляет сообщение SAA содержащие профиль пользователя в S-CSCF.

S-CSCF отправляет ответ 200 (OK) на I-CSCF. Ответ означает – успешную аутентификацию.

I-CSCF передаёт ответ 200 (OK) на P-CSCF.

P-CSCF передаёт ответ 200 (OK) на ОП.

 

Рисунок 5.12 - Процесс перегистрации пользователя услуг

 

5.3.5 Базовые соединения. На рисунке 5.13 представлен процесс базового соединения абонента «А» сети IMS (sip:[e-mail] и «Б» сети ТфОП tel:[phone]).

SIP-терминал «А» передает в направлении прокси сервера P-CSCF сообщение INVITE с содержанием телефона абонента «Б» tel:[phone].

BRAS авторизует терминал пользователя sip:[e-mail] по команде сервера RDS (RADIUS/DIAMETER Server). Команда INVITE передается контроллеру сессий SBC (SE2600). Контроллер сессий осуществляет проверку безопасности протоколом IPSec, выполняет контроль SIP-сессий. В случае успешности проверок SBC передает команду INVITE прокси-серверу P-CSCF.

 

[phone]

Рисунок 5.13 – Процесс базового соединения абонентов IMS и ТфОП

Команда INVITE передается прокси-серверу P-CSCF. Прокси-сервер P-CSCF передает SIP-терминалу «А» сообщение TRYING (100) о том, что команда INVITE принята и находится на стадии обработки, выполняет проверку корректности идентификатора P-Preferred-Identity на основе данных регистрации REGISTER. В случае успешности проверок прокси-сервер P-CSCF перемещает идентификатор P-Preferred-Identity в поле P-Asserted-Identity, выбирает обслуживающий сервер S-CSCF, запрашивает у DNS-сервера IP-адрес выбранного S-CSCF по доменному имени <scscf01.3gpp.ims.com>. Далее указывает доменное имя <scscf01.3gpp.ims.com> в поле Record-Route. Поле Record-Route определяет SBC, через который будет передаваться ответное сообщение на команду INVITE.

Команда INVITE передается серверу S-CSCF. Сервер S-CSCF идентифицирует пользователя терминала <А> по заголовку P-Asserted-Identity. Команда INVITE передается серверу приложений AS (Application Server). Сервер S-CSCF передает прокси-серверу P-CSCF сообщение TRYING (100) о том, что команда INVITE принята и находится на стадии обработки.

Сервер приложений AS проверяет запросом SNR (Subscribe Notifications Request) наличие и параметры профиля вызывающего абонента в HSS и далее авторизует исходящий вызов командой CCR (Credit Control Request) INITIAL в биллинговой системе.

В случае успешной авторизации команда INVITE передается посредством CSCF контроллеру медиашлюзов MGCF. Контроллер медиашлюзов выполняет контроль исходящей сессии и посылает с помощью протоколов MTP1-3 сигнал ISUP IAM в направлении медиашлюза IM-MGW.

Шлюз сигнализации SG медиашлюза IM-MGW далее передает ISUP IAM по SIGTRAN (M2UA) в сеть ТфОП к АТС Б. После чего происходит вызов абонента Б.

Контроллер медиашлюзов подтверждает прием и обработку команды INVITE сообщением TRYING (100). Далее MGCF резервирует последовательно ресурсы медиашлюза UMG8900: TDM (порт, тайм-слот), RTP (порт, IP) для последующей передачи трафика абонентов сети ТФОП.

Контроллер медиашлюзов анализирует содержание полей SDP команды INVITE и определяет общий перечень аудио/видео кодеков, поддерживаемых медиашлюзом IM-MGW. Перечень кодеков добавляет с помощью протокола SDP в сообщение описания состояния процедуры установления сессии SESSION PROGRESS (183). Сообщение SESSION PROGRESS (183) терминалу абонента «А».

SIP-терминал «А», получив сообщение SESSION PROGRESS (183), определяет перечень кодеков, поддерживаемых обеими сторонами, выбирает один из кодеков перечня и передает свое решение контроллеру медиашлюзов командой PRACK. Маршрут передачи команды PRACK указан в заголовке Record-Route принятого сообщения SESSION PROGRESS (183).

Контроллер медиа шлюзов подтверждает выполнение команды PRACK сообщением 200 (OK). SIP-терминал «А» передает контроллеру медиа шлюзов команду модификации состояния сессии UPDATE, содержащую описание сеанса связи SDP с учетом выбранных кодеков и параметров качества передачи пакетов аудио/видео данных.

Контроллер медиашлюзов, получив сообщение UPDATE, применяет кодек, модифицирует зарезервированные ресурсы медиашлюза IM-MGW командой MOD.req. Подтверждает прием сообщения UPDATE передачей сообщения OK (200). В сообщении не указываются параметры QoS, так как на данной стадии не активирован PDP-контекст.

АТС Б посылает с помощью протокола SIGTRAN (M2UA) сигнал ISUP AСM (КПВ) в направлении медиашлюза IM-MGW. Шлюз сигнализации SG медиашлюза IM-MGW далее передает ISUP AСM по MTP1-3 к контроллеру медиашлюзов.

Контроллер медиашлюзов передает SIP-терминалу «А» сообщение уведомление о посылке вызова RINGING (180).

При ответе вызываемого абонента (Event – Answer) АТС Б, обнаруживая это с помощью протокола SIGTRAN отправляет сообщение ISUP ANM в направлении медиашлюза IM-MGW. Шлюз сигнализации SG далее передает ISUP ANM по MTP1-3 к контроллеру медиашлюзов. Контроллер медиашлюзов передает сообщение OK(200) к абоненту «А» через S-CSCF.

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

SIP-терминал «А» подтверждает установление вызова сообщением ACK, между терминалами «А» и медиа шлюзомом IM-MGW, а так же между медиа шлюзомом IM-MGW и АТС Б. Передача пакетов аудио/видео данных осуществляется с использованием протоколов RTP/RTCP.

Абонент «А» завершает вызов (Event – Disconnect). SIP-терминал «А» передает сообщение BYE.

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

Контроллер MGCF, получив сообщение BYE, освобождает ресурсы IM-MGW командой SUB.req последовательно для TDM и RTP каналов, а также передает в направлении АТС Б команду ISUP REL.

Абонент «Б» завершает вызов и АТС Б передает сообщение ISUP RLC контроллеру MGCF. Контроллер MGCF передает сообщение OK (200) в сторону абонента «А». Сервер приложений AS формирует тарификационную запись CDR на шлюзе CCF.

Вызов завершен.

На рисунке 5.14 представлен процесс базового соединения абонентов платформы IMS.

Абонент «А» sip:+ [e-mail] инициирует вызов абонента «Б» sip:[e-mail], идентифицируемого по SIP URI, TEL URI. SIP-терминал «А» включает в поле SDP перечень (List) поддерживаемых кодеков (audio/video).

+ 73431234568 @3gpp.ims.com

+ 73431234567 @3gpp.ims.com

Рисунок 5.14 – Процесс базового соединения абонентов платформы IMS

SIP-терминал «А» передает пользователю Б команду INVITE. Команда INVITE содержит информацию маршрутизации (Route). Информация маршрутизации получена ранее SIP-терминалом «А» в поле заголовка Service-Route сообщения «200 OK» об успешной регистрации терминала (REGISTER). Кроме указанных полей команда INVITE содержит также поля «To», «From».

BRAS авторизует терминал пользователя А по команде сервера RDS (RADIUS/DIAMETER Server). Команда INVITE передается контроллеру сессий SBC. Контроллер сессий осуществляет проверку безопасности, выполняет контроль SIP-сессий. В случае успешности проверок SBC передает команду INVITE прокси-серверу P-CSCF.

Сервер приложений AS идентифицирует вызываемого пользователя, запрашивает командой SNR (Subscribe Notifications Request) у базы данных HSS информацию о пользователе и его местоположении, об подключенных услугах, выполняет логику управления входящим (Terminated) вызовом и определяет обслуживающий term-S-CSCF, авторизует в биллинговой системе входящий вызов командой CCR (INITIAL).

В случае успешной авторизации исходящего и входящего вызовов команда SIP INVITE передается SIP-терминалу пользователя «Б» через S-CSCF, term-P-CSCF, SBC. Сервер S-CSCF определяет параметры SIP-терминала «Б» (IP:Port).

Получая команду SIP INVITE прокси-сервер term-P-CSCF передает сообщение TRYING (100). Далее анализирует идентификатор конфиденциальности Privacy команды INVITE. Если идентификатор Privacy указывает на конфиденциальность, то term-P-CSCF удаляет из команды идентификатор P-Asserted-Identity, чтобы вызываемая сторона не видела информацию о вызывающей стороне. Затем term-P-CSCF добавляет в команду INVITE идентификатор P-Media-Authorization, указывающий на требуемое качество передачи данных, добавляет свой собственный идентификатор SIP URI в заголовок Record-Route (таким образом, прокси-сервер term-P-CSCF остается на пути маршрута последующей сигнализации).

Сервер BRAS авторизует терминал пользователя «Б» по команде сервера RDS (RADIUS/DIAMETER Server) SIP-терминал «Б» анализирует содержание полей SDP команды INVITE и определяет перечень аудио/видео кодеков, поддерживаемых SIP-терминалом «А». Определяет перечень кодеков, поддерживаемых обоими SIP-терминалами и добавляет этот перечень кодеков с помощью протокола SDP в сообщение описания состояния процедуры установления сессии SESSION PROGRESS (183). Затем SIP-терминал «Б» распознает поле P-Asserted-Identity команды INVITE и определяет идентификатор вызывающей стороны.

Сообщение SESSION PROGRESS (183) передается SIP-терминалу «А». SIP-терминал «А», получив сообщение SESSION PROGRESS (183), определяет перечень кодеков, поддерживаемых обеими сторонами, выбирает один из кодеков перечня и передает свое решение мобильному терминалу UE2 командой PRACK. Маршрут передачи команды PRACK указан в заголовке Record-Route принятого сообщения SESSION PROGRESS (183).

SIP-терминал «Б» подтверждает выполнение команды PRACK сообщением 200 (OK). SIP-терминал «А» передает SIP-терминалу «Б» команду модификации состояния сессии UPDATE, содержащую описание сеанса связи SDP с учетом выбранных кодеков и параметров качества передачи пакетов аудио/видео данных.

SIP-терминал «Б» подтверждает прием сообщения UPDATE передачей сообщения OK (200). В сообщении мобильных пользователей не указываются параметры QoS, так как на данной стадии не активирован PDP-контекст вызываемым мобильным терминалом. SIP-терминал «Б» инициирует сигнал вызова абонента «Б» и передает SIP-терминалу «А» сообщение уведомление о посылке вызова RINGING (180).

При ответе вызываемого абонента (Event – Answer) SIP-терминал «Б» передает сообщение OK(200).

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

SIP-терминал «А» подтверждает установление вызова сообщением ACK, между терминалами «А» и «Б» устанавливается SIP-сессия.

Передача пакетов аудио/видео данных осуществляется с использованием протоколов RTP/RTCP. Абонент «А» завершает вызов (Event – Disconnect). SIP-терминал «А» передает сообщение BYE.

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

SIP-терминал «Б» подтверждает прием сообщения BYE передачей сообщения OK (200).

Сервер приложений AS формирует тарификационную запись CDR на шлюзе CCF.

Вызов завершен.