В процессе обслуживания вызова участвуют все компоненты системы. Основными компонентами являются Adapter и Core, которые непосредственно работают с сигнализацией и отслеживают фазы вызова.
Обмен сообщениями осуществляется через интеграционную шину, которую обеспечивает кластер BUS. Кластера Adapter и Core обмениваются сообщениями внутреннего протокола ACP (Adapter Core Protocol). Этот протокол является модификацией протокола DSS и основан на примитивах обмена, описанных в стандарте ITU-T Q.1238 для интеллектуальных сетей.

В протоколе ACP выделяют следующие типы сообщений:

Setup — сообщение для установления соединения (запрос, подтверждение, ответ);
SubsequentAddress — сообщение с информацией о дополнительных цифрах;
AddressEnd — сообщение с информацией о завершении набора номера и набранными цифрами;
ServiceFeature — сообщение с индикацией об активации сервисной логики;
CallProgress — сообщение для передачи информации без смены фазы обслуживания вызова
Release — сообщения о разъединении вызова.

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

Различают следующие модификаторы:

Ind — индикация события;
Req — запрос;
Resp — ответ;
Conf — подтверждение;
Ack — подтверждение в приеме сообщения.

Полный набор сообщений, которые присутствуют в протоколе ACP с учетом модификаторов, имеет вид:

SetupInd — сообщение передается, когда адаптер определил факт входящего занятия;
SetupIndAck — сообщение передается на адаптер как подтверждение начала обработки SetupInd;
SetupReq — сообщение передается на адаптер, когда ядро инициирует исходящее занятие;
SetupReqAck — сообщение передается на ядро как подтверждение начала обработки SetupReq
SetupConf — сообщение передается на ядро, когда адаптер получил индикацию об ответе (подтверждение об установлении соединения);
SetupResp — сообщение передается на адаптер, когда ядро подтверждает установление соединения (ответ);
SubsequentAddressInd — сообщение передается на ядро, когда адаптер получил донабор от абонента (ситуация dig-by-dig набора);
AddressEndInd — сообщение передается, когда определено завершение набора номера;
CallProgressInd — сообщение передается, когда адаптер информирует ядро о событии;
CallProgressReq — сообщение передается, когда ядро отправляет на адаптер запрос на передачу сообщения;
ServiceFeatureInd — сообщение передается на ядро, когда адаптер определил событие активации сервисной логики;
ReleaseInd — сообщение передается на ядро, когда адаптер определил факт разъединения;
ReleaseReq — сообщение передается на адаптер, когда ядро отправляет запрос на разъединение.

Основные параметры сигнальных сообщений:

SetupInd/Req

CallRef — идентификатор вызова;
CallingPartyNumber — номер вызывающего абонента (номер А);
CalledPartyNumber — номер вызываемого абонента (номер Б);
CallingPartysCategory — категория вызывающего абонента;
CalledPartysCategory — категория вызываемого абонента;
CallingPartyInfo — параметры вызывающего абонента (домен, интерфейс, информация о подключенных услугах);
CalledPartyInfo — параметры вызываемого абонента (домен, интерфейс, информация о подключенных услугах);
TrunkGroupId — идентификатор входящей транковой группы для вызова, пришедшего с транка;
sdp — информация о медиапотоке.

SetupResp/Conf

CallRef — идентификатор вызова;
ConnectedNumber — номер вызываемого абонента, ответившего на вызов (если он отличается от изначально набранного номера);
sdp — информация о медиапотоке.

SubsequentAddressInd

CallRef — идентификатор вызова;
Digits — цифры номера.

AddressEndInd

CallRef — идентификатор вызова;
Digits — цифры номера.

CallProgressInd/Req

CallRef — идентификатор вызова;
Cause — внутренний индикатор причины отправки сообщения;
CauseInitiator — инициатор события (система, пользователь или событие обнаружено на сети);
CauseIsup — индикатор причины в формате ISUP;
EventInformation — описание события;
gNotification — информационные флаги;
sdp — информация о медиапотоке;
TrunkGroupId — идентификатор исходящей транковой группы для исходящего вызова.

ReleaseInd/Req

CallRef — идентификатор вызова;
Cause — внутренний индикатор причины разъединения;
CauseInitiator — инициатор события (система или события обнаружено на сети);
CauseIsup — индикатор причины разъединения в формате ISUP;
TrunkGroupId — идентификатор исходящей транковой группы для исходящего вызова.

Далее будут рассмотрены процессы обслуживания вызова на sequence-диаграммах, из которых будет виден процесс обмена сообщениями.

Рисунок 13 — Базовый вызов по протоколу SIP в режиме "enblock", упрощенный вид

Рисунок 14 — Разъединение вызова по инициативе абонента А, упрощенный вид

Рисунок 15 — Разъединение вызова по инициативе абонента Б, упрощенный вид

Примеры неуспешных вызовов

Рисунок 16 — Неуспешный вызов по причине того, что номер Б не существует

Рисунок 17 — Неуспешный вызов по причине того, что номер Б не существует

Рисунок 18 — Неуспешный вызов по причине того, что интерфейс абонента Б не активен

Процесс обслуживания вызовов. Схема обмена данными

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

Adapter A

Рисунок 19 — Диаграмма работы originating кластера Adapter (Adapter A)

Описание действий, выполняемых в функциональных блоках на диаграмме работы originating кластера Adapter (Adapter A):

Обработка 1 — входящий вызов по протоколу сигнализации поступает в ноду originating кластера Adapter (Adapter A), в которой:

производится декодирование информационного пакета декодером соответствующего протокола;
осуществляется проверка корректности и целостности полученного сигнального сообщения;
анализируются параметры полученного сигнального сообщения и определяются идентификаторы отправителя и получателя;
определяется, должен ли сигнальный пакет обрабатываться системой;
на основании параметров сообщения определяется, к какому originating интерфейсу (интерфейс А) оно относится;
выполняется запрос в кластер Storage о конфигурационных данных для интерфейса А;
формируется и подготавливается к отправке в кластер Core сообщение "SetupInd" в кластер Core;
процесс обслуживания вызова переводится в логическое состояние ожидания подтверждения начала обработки от кластера Core (State1);
формируется и отправляется в кластер Mediator пакет статистической информации о поступлении занятия по интерфейсу А.

Обработка 2 — от ядра получено сообщение о выдаче абоненту Б сигнала "Посылка вызова", выполняются следующие действия:

анализ корректности и целостности полученного сообщения;
процесс обслуживания вызова переводится в логическое состояние Alerting (State3);
срабатывают триггерные точки для состояния Alerting, приводящие к выполнению логики активированных сервисов;
формируется и подготавливается к отправке абоненту А сообщение "Progress" с индикатором "Alerting" целевого протокола адаптера;
обновляется информация, накапливаемая модулем СОРМ и модулем тарификации.

Обработка 3 — от ядра получено промежуточное сообщение о статусе процесса установления соединения, выполняются следующие действия:

анализ корректности и целостности полученного сообщения;
процесса обслуживания вызова остается в том же логическом состоянии ожидания ответного сообщения от абонента Б (State2);
формируется и подготавливается к отправке абоненту А сообщение "Progress" с индикаторами, построенными на базе исходного сообщения по правилам целевого протокола адаптера.

Обработка 4 — от ядра получено сообщение об ответе абонента Б (SetupConf), выполняются следующие действия:

анализ корректности и целостности полученного сообщения;
процесс обслуживания вызова переводится в логическое состояние "Conversation" (State4);
срабатывают триггерные точки для состояния "Converstaion", приводящие к выполнению логики активированных сервисов;
формируется и подготавливается к отправке абоненту А сообщение "Answer" целевого протокола адаптера;
обновляется информация, накапливаемая модулем СОРМ и модулем тарификации.

Core

Рисунок 20 — Диаграмма работы кластера Core

Описание действий, выполняемых в функциональных блоках на диаграмме работы кластера Core:

Обработка 1

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

анализируются параметры сообщения "SetupInd", проверяется их полнота и целостность;
извлекается и сохраняется информация, необходимая для выполнения функций СОРМ и тарификации;
подготавливается к отправке в Adapter A сообщение "SetupIndAck", подтверждающее начало обработки вызова кластером Core;
выполняется запрос в кластер Storage на выполнение телефонной маршрутизации, целью которой является поиск "terminating" интерфейса (интерфейса Б), а также применение различного вида модификаций номеров А и Б;
анализируются результаты маршрутизации, и в зависимости от результатов маршрутизации различается поведение.

В результате маршрутизации был успешно найден интерфейс локального абонента Б:

в случае успешного нахождения маршрута с кластера Storage будут получены:
- номер абонента А (возможно модифицированный);
- абонентские параметры абонента А;
- идентификатор интерфейса Б и его параметры;
- номер абонента Б (возможно модифицированный);
- абонентские параметры абонента Б.
запускаются функции обработки услуг, активированных у абонента А и абонента Б;
дополняются данные, собираемые модулем СОРМ и модулем тарификации;
формируется и подготавливается к отправке в "terminating" кластер Adapter (Adapter Б) сообщение "SetupReq" для абонентского интерфейса Б.

В результате маршрутизации был успешно найден интерфейс/интерфейсы исходящего транка абонента Б:

в случае успешного нахождения маршрута с кластера Storage будут получены:
- номер абонента А (возможно модифицированный);
- абонентские параметры абонента А;
- идентификатор интерфейса Б и его параметры;
- номер абонента Б (возможно модифицированный);
- абонентские параметры транкового интерфейса абонента Б.
запускаются функции обработки услуг, активированных у абонента А;
дополняются данные, собираемые модулем СОРМ и модулем тарификации;
формируется и подготавливается к отправке в "terminating" кластер Adapter (Adapter Б) сообщение "SetupReq" для транкового интерфейса Б.

В результате маршрутизации был определен неполный номер:

Неполный номер может быть определен только, если поддерживается передача номера в режиме overlap. В случае использования протокола SIP номер, как правило, передается методом enblock, а метод overlap обычно не используется.

в случае неполного номера в результате маршрутизации с кластера Storage будут получены:
- код ошибки "неполный номер";
процесс обработки вызова, переход в фазу ожидания последующих цифр номера (STATE2);
запуск таймера ожидания следующей цифры номера.

В результате маршрутизации была возвращена ошибка:
Обслуживание вызова продолжается по процедуре "Обработка 3".

Обработка 2

Получили одну или несколько цифр номера в случае посимвольного набора, выполняется следующая обработка:

выполняется запрос в кластер Storage для запуска процесса маршрутизации с использованием всех накопленных цифр номера Б;
анализируются результаты маршрутизации, и в зависимости от результатов маршрутизации различается поведение.

Дальнейшие действия по обработке вызова аналогичны действиям из процедуры "Обработка 1" после получения результатов маршрутизации.

Обработка 3

Производятся действия по обработке ошибки, которая была выявлена в процессе обслуживания вызова:

В результате маршрутизации был определен неактивный интерфейс абонента Б:

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

в случае неактивного интерфейса в результате маршрутизации с кластера Storage будут получены: ** код ошибки "неактивный интерфейс";
если в системе активирован механизм CFC (Call Forwarding by Cause), который обеспечивает фразы автоинформатора для определенных типов ошибок, то он запускается на выполнение по логике для ошибки "неактивный интерфейс";
после проигрывания фразы на Adapter A подготавливается к отправке запрос на разъединение "ReleaseReq" с соответствующей причиной;
обновляется информация для модулей СОРМ и тарификации, итоговый информационный пакет отправляется в кластер CORE.

В результате маршрутизации было определено, что у абонента А закрыт доступ к номеру абонента Б:

Запрет доступа абонента А к номеру абонента Б может быть введен на уровне групп доступа или режима обслуживания, и служит для ограничения видов доступа в зависимости от соглашении об уровне сервиса между абонентом и оператором (например использование междугородней связи запрещено или действует временное ограничение исходящей связи по причине неоплаты услуг связи).

в случае запрета доступа на номер Б в результате маршрутизации с кластера Storage будут получены: ** код ошибки "запрет доступа";
если в системе активирован механизм CFC (Call Forwarding by Cause), который обеспечивает фразы автоинформатора для определенных типов ошибок, то он запускается на выполнение по логике для ошибки "запрет доступа";
после проигрывания фразы на Adapter A подготавливается к отправке запрос на разъединение "ReleaseReq" с соответствующей причиной;
обновляется информация для модулей СОРМ и тарификации, итоговый информационный пакет отправляется в кластер CORE.

В результате маршрутизации был определен несуществующий номер:

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

в случае несуществующего номера в результате маршрутизации с кластера Storage будут получены: ** код ошибки "номер не существует";
если в системе активирован механизм CFC (Call Forwarding by Cause), который обеспечивает фразы автоинформатора для определенных типов ошибок, то он запускается на выполнение по логике для ошибки "номер не существует";
после проигрывания фразы на Adapter A подготавливается к отправке запрос на разъединение "ReleaseReq" с соответствующей причиной;
обновляется информация для модулей СОРМ и тарификации, итоговый информационный пакет отправляется в кластер CORE.

В результате маршрутизации был определен неправильный номер:

Неправильный номер — это когда формат номера не соответствует форматам, заданным планом нумерации.

в случае неправильного номера в результате маршрутизации с кластера Storage будут получены: ** код ошибки "неправильный номер";
если в системе активирован механизм CFC (Call Forwarding by Cause), который обеспечивает фразы автоинформатора для определенных типов ошибок, то он запускается на выполнение по логике для ошибки "неправильный номер";
после проигрывания фразы на Adapter A подготавливается к отправке запрос на разъединение ReleaseReq с соответствующей причиной;
обновляется информация для модулей СОРМ и тарификации, итоговый информационный пакет отправляется в кластер CORE.

Другие ошибки:

анализируется код ошибки обслуживания вызова и преобразуется в код ошибки целевого протокола Adapter A;
если в системе активирован механизм CFC (Call Forwarding by Cause), который обеспечивает фразы автоинформатора для определенных типов ошибок, то он запускается на выполнение по логике для ошибки "неправильный номер";
после проигрывания фразы на Adapter A подготавливается к отправке запрос на разъединение ReleaseReq с соответствующей причиной;
обновляется информация для модулей СОРМ и тарификации, итоговый информационный пакет отправляется в кластер CORE.

Обработка 4

Процедура выполняется при получении сообщения о разъединении "ReleaseInd" из кластера Adapter A до получения из кластера Adapter Б:

анализируются параметры сообщения "ReleaseInd", проверяется их полнота и целостность;
сообщение запоминается во внутреннем буфере процесса обработки вызова (Delayed ReleaseId);
извлекается и сохраняется информация, необходимая модулям СОРМ и тарификации;
процесс обработки вызова остается в состоянии ожидания подтверждения обработки от кластера Adapter Б (STATE1).

Обработка 5

Кластер Adapter Б подтвердил обработку вызова, получено сообщение "SetupReqInd", отложенных "ReleaseInd" в буфере процесса обработки вызова нет, идет нормальная обработка вызова:

транспортные параметры процесса обслуживания вызова в кластере Adapter Б извлекаются из сообщения и сохраняются в области данных процесса обработки вызова;
запускается таймер ожидания сообщения из кластера Adapter Б (TResponse);
процесс обработки вызова переходит в состояние ожидания ответного сообщения (STATE3).

Обработка 6

В состоянии ожидания ответного сообщения из кластера Adapter Б (STATE3) сработал таймер TResponse, что означает, что Adapter Б не прислал никаких сообщений за заданный интервал времени, ситуация аварийная для вызова:

активизируется процедура разъединения вызова;
если в системе активирован механизм CFC (Call Forwarding by Cause), который обеспечивает фразы автоинформатора для определенных типов ошибок, то он запускается на выполнение по логике для ошибки "номер временно недоступен";
формируется и подготавливаются к отправке в кластеры Adapter А и Adapter Б сообщения разъединения ReleaseReq;
обновляется информация для модулей СОРМ и тарификации, итоговый информационный пакет отправляется в кластер CORE.

Обработка 7

В состоянии ожидания ответного сообщения из кластера Adapter Б (STATE3) получено сообщение разъединения ReleaseInd от кластера Adapter A, что означает, что абонент А положил трубку:

анализируются параметры сообщения "ReleaseInd", проверяется их полнота и целостность;
формируется и подготавливается к отправке в кластер Adapter Б сообщение разъединения "ReleaseReq";
обновляется информация для модулей СОРМ и тарификации, итоговый информационный пакет отправляется в кластер CORE.

Обработка 8

В состоянии ожидания ответного сообщения из кластера Adapter Б (STATE3) получено сообщение "CallProgressInd" с индикатором выдачи абоненту Б сигнала "Посылка вызова" (BPtyAlerting):

анализируются параметры сообщения "CallProgressInd", проверяется их полнота и целостность;
формируется и подготавливается к отправке в кластер Adapter А сообщение "CallProgressReq" с индикатором "BPtyAlerting";
активируются триггеры и запускаются процессы обработки активных сервисов;
процесс обработки вызова переводится в логическое состояние ожидания ответа абонента Б (STATE4);
обновляется информация для модулей СОРМ и тарификации;
запускается таймер ожидания ответа абонента Б (TAnswer).

Обработка 9

В состоянии ожидания ответного сообщения из кластера Adapter Б (STATE3) получено сообщение "CallProgressInd" (промежуточное сообщение процесса установления соединения):

анализируются параметры сообщения "CallProgressInd", проверяется их полнота и целостность;
формируется и подготавливается к отправке в кластер Adapter А сообщение "CallProgressReq";
процесс обработки вызова остается в том же состоянии (STATE3);
запускается таймер ожидания сообщения из кластера Adapter Б (TResponse).

Обработка 10

В состоянии ожидания ответа абонента Б (STATE3 или STATE4) получено сообщение об ответе абонента Б (SetupResp):

анализируются параметры сообщения "SetupResp", проверяется их полнота и целостность;
формируется и подготавливается к отправке в кластер Adapter А сообщение "SetupConf";
активируются триггеры и запускаются процессы обработки активных сервисов;
процесс обработки вызова переводится в логическое состояние разговора (STATE5);
обновляется информация для модулей СОРМ и тарификации;
запускается таймер ограничения максимальной длительности разговора (TConversation).

Adapter Б

Рисунок 21 — Диаграмма работы terminating кластера Adapter (Adapter Б)

Описание действий, выполняемых в функциональных блоках диаграммы:

Обработка 1

В кластере Adapter Б получено сообщение о инициации вызова SetupReq.Выполняются следующие операции:

анализ корректности и целостности полученного сообщения;
проверка того, существует или нет активный вызов для интерфейса абонента Б: ** если вызов существует, то проверяется наличие ограничений на количество одновременных вызовов и если количество одновременных вызовов достигло установленного максимального уровня, производится отказ в обслуживании вызова, формируется и подготавливается к отправке в кластер Core сообщение о разъединении "ReleaseInd", обслуживание вызова прекращается;
если ограничений на обработку вызова нет, то формируется и подготавливается к отправке в кластер Core сообщение "SetupReqAck";
согласно правил целевого протокола, на основании данных полученных в "SetupReq", формируется и отправляется абоненту Б сообщение "Seize";
процесс на ноде кластера Adapter Б переходит в состояние ожидания ответного сообщения от абонента/транка Б (STATE1);
активируется таймер ожидания ответного сообщения от абонента Б (TResponse).

Обработка 2

В состоянии ожидания ответного сообщения от абонента/транка Б получено промежуточное сообщение "Progress":

анализ корректности и целостности полученного сообщения, извлечение параметров;
формируется и подготавливается к отправке в кластер Core сообщение "CallProgressInd" с данными заполненными на базе сообщения "Progress";
активируется таймер ожидания ответного сообщения от абонента Б (TResponse);
процесс обработки вызова остается в том же логическом состоянии (STATE1).

Обработка 3

В состоянии ожидания ответного сообщения от абонента/транка Б получено промежуточное сообщение "Progress" с индикатором "Alerting".

анализ корректности и целостности полученного сообщения, извлечение параметров;
формируется и подготавливается к отправке в кластер Core сообщение "CallProgressInd" с данными заполненными на базе сообщения "Progress", устанавливается индикатор "BPtyAlerting";
активируется таймер ожидания ответа абонента Б (TAnswer);
процесс обработки вызова переводится в состояние ожидания ответа абонента Б (STATE2).

Обработка 4

В состоянии ожидания ответного сообщения от абонента/транка Б (STATE1) или в состоянии ожидания ответа абонента Б (STATE2) получено сообщение об ответе абонента Б (Answer).Выполняется:

анализ корректности и целостности полученного сообщения, извлечение параметров;
формируется и подготавливается к отправке в кластер Core сообщение "SetupResp" с данными, заполненными на базе сообщения "Answer";
активируется защитный таймер ограничения максимальной продолжительности разговора (TConverstaion);
процесс обработки вызова переводится в состояние активного вызова (STATE3).

Обработка 5

Получено сообщение о разъединении с кластера Adapter А:

анализ корректности и целостности полученного сообщения;
формируется и подготавливается к отправке абоненту/транк Б сообщение о разъединении (Release);
очищаются ресурсы, занятые процессом обработки вызова.

Обработка 6

Получено сообщение о разъединении от абонента/транка Б:

анализ корректности и целостности полученного сообщения;
формируется и подготавливается к отправке в кластер Core сообщение о разъединении (ReleaseInd);
очищаются ресурсы, занятые процессом обработки вызова.

Обработка 7

В состоянии ожидания ответа абонента Б получено промежуточное сообщение "Progress":

анализ корректности и целостности полученного сообщения, извлечение параметров;
формируется и подготавливается к отправке в кластер Core сообщение "CallProgressInd" с данными, заполненными на базе сообщения "Progress";
процесс обработки остается в логическом состоянии ожидания ответа абонента Б (STATE2).