CAMEL and IVR

Читатели спрашивают (оставляйте вопросы по GSM здесь): как реализовать проигрывание голосового сообщения при звонке на CAMEL-абонента. Вызов при этом не должен быть полностью установлен (не должно быть тарификации А-абонента). После проигрывания сообщения вызов нужно прекратить.

Я вижу 3 варианта реализации. В любом из случаев предполагается, что в профиле абонента (T-CSI) указан "наш" SCP.
Вариант 1.
Ответить CAP RequestReportBCSM + Connect. Внутри Connect содержится номер IVR с которым надо установить соединение и не установлен параметр oCSIApplicable. Об этом IVR ниже.
Далее подождать некоторое время и отправить CAP releaseCall. Ожидается, что IVR не будет отвечать на вызов, поэтому никаких событий от SSP (MSC) не будет. Но на всякий случай лучше предусмотреть логику отправки releaseCall на события типа tAnswer.
Что касается IVR, то это должно быть устройство с голосовыми потоками и подключением по ISUP. Как только приходит ISUP IAM, логика IVR должна проверить А и Б номера и подготовить голосовой канал. Номер этого канала (CIC) приходит в сообщении IAM. Как только ISUP модуль отвечает ACM, можно начинать проигрывать запись в голосовом канале. Т.к. мы не будем отправлять ANM по ISUP, то и тарификации не будет.
Что касается диалога между SCP и SSP (MSC), то в RequestReportBCSM нужно активировать нотификацию на событие tNoAnswer и прерывание вызова (interrupted) для tAnswer. В случае получения ответа от нашего IVR вызов нужно завершить с помощью releaseCall.

Вариант 2.
На любой InitialDP отвечать releaseCall с release cause code, который точно на сети не используется. Далее, насколько мне известно, на MSC можно указать какой локальный автоответчик будет проигрываться при том или ином коде. Хотя согласно спецификации (для CAMELv2 - ETSI 03.78) коммутатор не должен ничего проигрывать, а только разорвать вызов и передать по ISUP на коммутатор абонента А сообщение REL с неким кодом (маппинг между кодами в CAMEL и ISUP не определён).
Только в этом варианте для всех абонентов получаем одинаковый автоинформатор (или очень ограниченное их число). Хочу сразу сказать, что я не сильно уверен в этом варианте - далёк от коммутаторов.

Вариант 3.
Использовать CAP "Connect to resource". Так делают Prepaid системы, когда перед вызовом необходимо проиграть системное сообщение типа "у Вас скоро закончатся все-все деньги". Callflow при этом такой:

-> IntialDP
<- RequestReportBCSMEvent + ConnectToResource + PlayAnnouncement
играет запись
-> Specialized Resource Report
<- DisconnectForwardConnection + ReleaseCall

Только для такого варианта нужен "умный" IVR, который будет выступать в роли Intelligent Peripheral.

Read More..

CAMEL trace

В комментарии к статье "Основы CAMEL" меня попросили добавить трейс. Трейс я добавил, однако хотел бы подробнее описать что там и к чему.

Для начала откройте трейс CAMEL с помощью Wireshark (если у Вас есть другая любимая программа - просьба сообщить в комментарии). Данный трейс взят с живой системы, но все важные адреса заменены на вымышленные. И кстати, при осуществлении этого вызова ни одно животное не пострадало.

Обмен сообщениями происходит между поинт кодом 1 и 2 (разверните поле MTP3 в Wireshark). На уровне SCCP диалог происходит между 111111111111 и 222222222222.

111111111111 это Global Title (GT) коммутатора, а точнее SSP (service switching point), который инициирует запрос в SCP (service control point) с GT=222222222222. Для этого создаётся TCAP транзакция с номером 11111111 (в HEX). Внутри этой транзакции находится т.н. application-context-name: 0.4.0.0.1.0.50.1 (CAP-v2-gsmSSF-to-gsmSCF-AC). Т.е. это CAMEL версии 2, диалог между SSF и SCF (Service Switching и Control Function, соответственно).

Если Wireshark не декодирует сообщение дальше SCCP, то надо ему явно указать что SSN=146 это протокол CAMEL.
Для этого в меню "Edit" выбрать "Preferences". Перейти к последнему пункту "Protocols", развернуть список и начать набирать CAMEL.
При этом отобразятся свойства протокола такого вида:

В поле TCAP SSNs надо через запятую указать значения 146 и 12. нажать ОК и теперь всё будет отображаться корректно.

Перейдём непосредственно в сам запрос. Первое, на что стоит обратить внимание, это opcode - InitialDP. Если Вы внимательно читали статью "Основы CAMEL", то должны знать что такой запрос посылается при срабатывании триггера. В данном случае это был триггер на "eventTypeBCSM: collectedInfo (2)" - исходящий вызов абонента. В отичии от Вас, SCP также "обратит" внимание на значение поля serviceKey, т.к. оно отвечает за выбор логики внутри SCP.

Теперь поля, которые имеют отношение непосредственно к вызову:

1. Calling Party Number: 38067220XXXX. Это вызывающий номер - т.н. А-номер.
2. Location number: 111111111111. Адрес коммутатора, с которого происходит вызов. Очень важное поле с точки зрения тарификации абонентов в роуминге.
3. vlr-number и mscAddress. Тут я думаю, что всё понятно.
4. calledPartyBCDNumber - а это номер вызываемого абонента, т.н. Б-номер. Новый Wireshark уже декодирует это поле из формата BCD в "человеческий", поэтому если Вы видите что-то отличное от номера 380674660466, то обновляйте Wireshark.

В ответ на InitialDP SCP отправляет сообщение applyCharging. Посмотрите сперва на TCAP часть. Это сообщение является продолжением уже начатой TCAP транзакции (11111111), со стороны SCP ей присваивается номер 22222222.

Механизм ApplyCharging/ApplyChargingReport (AC/ACR) используется как для тарификации, так и для ограничения длительности вызова. SCP, после получения InitialDP, может расчитать максимальную длительность вызова (на основании текущего балланса абонента и его местоположения) и тем самым указать коммутатору (SSP) разорвать вызов при достижении этого значения.

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

Таким образом существует 2 метода подсчёта длительности вызова - на основании AC/ACR и на основании CAMEL событий.

Следующее сообщение это RequestReportBCSM и Connect в одном TCAP-сообщении. С помощью RRB активируются триггеры, о срабатывании которых необходимо уведомить SCP. Сообщение Connect информирует коммутатор о том, что соединение необходимо установить на другой номер - 380674660467.

Как только вызов был установлен - SSP отправляет нотификацию об этом (eventTypeBCSM: oAnswer).

Через некоторое время (44 сек), вызов прекращается и SSP информирует об этом SCP (eventTypeBCSM: oDisconnect). Также передаётся сообщение ApplyChargingReport с длительностью вызова. В данном случае это был простой вызов - без переподключений к автоинформаторам и пр. Поэтому внутри ACR содержится параметр timeIfNoTariffSwitch с длительностью вызова (описание полей в 09.78). Я не нашёл описания в стандарте, но почему-то значение параметра timeIfNoTariffSwitch в 10 раз больше актуальной длительности вызова.

И последнее сообщение - TCAP End для транзакции 11111111. На этом всё - вызов успешно завершён и обслужен.

Если есть вопросы - задавайте.

Read More..

IN services

Для чего нужен IN

Эта статья в некоторой мере предисловие к моей предыдущей статье "Основы CAMEL". Здесь я попытаюсь обьяснить зачем нужен IN и что можно с его помощью реализовать.

Основная задача IN это перенос вопросов логики и принятия решений с коммутатора (Service Switching Point в терминологии CAMEL) на внешний узел - SCP (Service Control Point). Благодаря базовой модели вызова, основе CAMEL, есть возможность управлять вызовом на всех его стадиях - установлении, разговоре, разьединении. Т.е. разнообразность услуги и её функционал зависит только от фантазии разработчика.
Ниже я собираюсь описать что уже придумали разработчики и как это работает. Если у Вас есть ещё примеры CAMEL-сервисов - пишите их в поле для комментариев.

1. Prepaid-системы
Пожалуй, самый популярный IN-сервис. Идея состоит в том, что каждый исходящий и входящий вызов абонента должен быть "одобрен" SCP. Благодаря этому есть возможность online-тарификации и ограничения длительности вызова в соответствии с баллансом абонента. Всё это справедливо и для абонентов в роуминге, если гостевая сеть поддерживает CAMEL и обе сети "договорились" о CAMEL-роуминге своих абонентов.
Важное замечание. Наличие CAMEL-подписки ещё не означает, что этот абонент Prepaid. Некоторые операторы в целях борьбы с возможным мошенничеством "подписывают" своих Postpaid абонентов на CAMEL SCP. При этом абонент по-прежнему платит после того, как услуги были оказаны. Т.е. он остается Postpaid, но с технической точки зрения выглядит как Prepaid. Ещё один вариант - у оператора все абоненты с CAMEL-подпиской на тот же SCP. Но часть их них при этом Prepaid, а остальные - Postpaid.

2. RBT-системы. Мелодии вместо КПВ
Этот сервис, наверное, самый близкий к пользователю. Благодаря IN (INAP или CAMEL, не важно) стандартные гудки (КПВ) заменяются мелодией. Правда должен заметить, что есть варианты реализации этого сервиса и на ISUP.
Техническая реализация состоит в установлении временного соединения с IVR (который и проигрывает мелодию) до тех пор, пока не будет получено событие t_Answer (ответ от вызываемого абонента) или событие с ошибкой. В случае получения t_Answer, SCP указывает коммутатору продолжить изначальный вызов.

3. Virtual Private Networks
Услуга, позволяющая организовать аналог мини-АТС на основе сети GSM - со своим номерным планом, ограничениями на звонки, статистикой и прочим. Как пример, посмотрите здесь.

4. Short numbers
Эта услуга широко применяется для роуминг-абонентов. Мало кто из абонентов помнит полный номер, например, Customer Care. Хотя короткий номер помнят хорошо, а очень часто он ещё и занесён в память SIM-карты. Для реализации коротких номеров внутри своей сети можно обойтись и без IN - короткие номера придётся прописывать на всех коммутаторах. Но что делать, если абонент обслуживается коммутатором другой сети? В этом случае короткие номера либо перестают работать, либо соединяют абонента с совсем другими службами.
Для решения этой проблемы можно использовать CAMEL-подписку на SCP, который при получении IntialDP с коротким номером будет отвечать Connect с полным.
Второй вариант реализации услуги это использовать триггер на коммутаторе - все звонки на короткие номера от абонентов-роумеров (абонентов другой сети) отправлять на SCP. Благодаря наличию IMSI в IntialDP, есть возможность точно определить домашнюю сеть абонента (даже если та использует MNP - Mobile Number Portability) и исправить короткий номер на длинный. При этом для домашней сети изменения останутся невидимы - так, как быдто абонент изначально позвонил на полный номер. Естесвенно, что "втихаря" такие услуги не запускают, а координируют запуск услуги с домшней сетью.


5. Called number correction
Ещё одна услуга, которая широко используется при роуминге. Для примера, ещё недавно в Украине для выхода на международную связь использовалось 2 варианта набора номера - через 8-10 и через "+". Кроме того, для междугородней связи и звонков другим абонентам использовался префикс "80". Если абонент сохранял номера у себя в телефонной книге в таком формате, то в домашней сети всё работало. При выезде в другую страну подобные форматы набора номера уже не работали.
Сейчас Украина использует единую с Европой систему набора номеров. Однако, даже это не поможет если номер сохранён в т.н. национальном формате - без кода страны. Если же в гостевой сети присутствует услуга коррекции набранных номеров, то SCP проведёт анализ IMSI, правил набора в домашней сети абонента и, возможно, исправит номер.
Обычно, такая услуга конфигурируется на коммутаторе с помощью триггера EndOfSelection. Этот триггер позволяет задействовать SCP в случае если не подходит ни один из маршрутов в таблице анализа Б-номера.

6. Ещё много-много других сервисов.

Read More..

Основы CAMEL

CAMEL Application Part (CAP) это протокол, используемый для построения интеллектуальных сетей (IN) внутри сетей GSM. На этом месте должна была быть ссылка на Википедию с описанием принципа IN, чтобы не повторяться. Но так уж вышло что там есть только англоязычное описание, да и то несколько скудноватое. Придётся заполнять пробелы.

Intelligent Networks
Предоплаченная связь (Pay as You Go), мелодии вместо гудков (RBT), звонки за счёт вызываемого абонента, бесплатные номера (Toll Free Numbers), виртуальные УАТС – это далеко не полный перечень услуг, которые появились благодаря IN. Что же такое Интеллектуальные Сети и почему нельзя было обойтись без них?
Основная идея IN состоит в том, чтобы коммутатор (MSC) занимался исключительно коммутацией. А описанные выше услуги организуются с помощью сторонних платформ, которые по сети сигнализации «общаются» с коммутатором, указывая ему что делать с вызовом.
При этом вся логика реализуется на отдельном управляющем узле (SCP, Service Control Point), а на коммутаторе описываются только условия, при которых необходимо отправить запрос на адрес SCP – т.н. «триггер». Процесс добавления триггера довольно прост, а все изменения логики происходят вне коммутатора – теоретически на одном узле (практически же, SCP нередко дублируются). Это позволяет сократить время на развёртывание услуг и сделать их очень гибкими.
Итого, мы уже знаем 2 узла IN – SCP и SSP (Service Switching Point). Первый отвечает за логику, а второй за её выполнение. Ещё один достаточно «популярный» узел это IP (Intelligent Peripheral). Он отвечает за воспроизведение различных сервисных сообщений пользователю (например, «У Вас недостаточно средств для совершения звонка»).

Ближе к CAMEL

IN-архитектура изначально разрабатывалась для PSTN. Затем IN Application Part (INAP) плавно перекочевал в мобильную связь. Основной недостаток архитектуры – её закрытость и, как следствие, несовместимость решений разных производителей друг с другом. В итоге, INAP-сервисы могут быть предоставлены только внутри домашней сети. В роуминге абонент их теряет.
Для решения этой проблемы был разработан протокол CAMEL. Благодаря его открытости, оборудование разных производителей может работать между собой без проблем. Т.е. даже в роуминге, в сети другого оператора, есть возможность пользоваться своими «умными» сервисами.

Теория, теория, теория.
Я бы с удовольствием не расписывал всякие теоретические моменты, которые Вы можете прочесть ниже, но без них понимание CAMEL будет очень ограниченным. В своё время я без труда разбирал трейсы CAMEL-диалогов, не задумываясь почему возникает то или иное сообщение. Со временем захотелось большего. Ниже я постарался расписать минимум, который необходим для понимания что и почему происходит при вызове. Информация, в основном, взята из 23.078 и головы.
Если же Вам лень читать теорию, переходите сразу к практике.


Базовая модель состояния вызова (BCSM, Basic Call State Model)
Для эффективного управления, вызов разбивается на отдельные элементы (состояния):

DP (Detection Point) это своеобразный указатель на текущее состояние. Например, DP2 (Collected Info) указывает на то, что это исходящий вызов в самом начале его обработки. Point In Call - это действия, которые выполняются в этом месте вызова. DP бывают 3-х типов:

1. Trigger Detection Point - Request (TDP-R). Это как раз тот триггер, о котором я уже упоминал. Устанавливается статически (до того как начался вызов), создаёт CAMEL запрос на SCP и ждёт ответа. Обработка звонка при этом приостанавливается.
2. Event Detection Point - Request (EDP-R). Это динамический точка (устанавливается во время вызова по запросу от SCP). Обработка звонка приостанавливается и SSP ждёт инструкций от SCP.
3. Event Detection Point - Notification (EDP-N). Тоже динамическая точка. Отличие в том, что звонок не прерывается (хотя SCP информируется о достижении этой точки, как и в предыдущем случае).

CAMEL-подписки
Для того, чтобы абонент использовал CAMEL-услугу, его надо "подписать" на неё. Сделать это можно в двух местах - на HLR (в профиле абонента) и непосредственно на самом MSC. Второй вариант (Network Service CAMEL Subscription Information, N-CSI) я рассматривать не буду (в виду ограниченности статьи), хотя вещь безусловно интересная.
Что касается варианта размещения подписок в профиле абонента, то здесь остановлюсь на 2х типах:

1. Originating CAMEL Subscription Information (O-CSI)
2. Terminating CAMEL Subscription Information (T CSI)

Первый используется при исходящих звонках от абонента (а также в случае срабатывания переадрессации), второй - для входящих звонков.
Обе подписки содержат в себе такие данные:

1. TDP List - список Detection Point, в которых будет срабатывать триггер.
2. Адрес SCP (gsmSCF address) - фактически Global Title SCP. Пояснение, SCF - Service Control Function - так называется SCP на другом логическом уровне.
3. Service Key - номер, указывающий на определённую логику, которую должен применить SCP.
4. Default Call Handling - что делать со звонком в случае неответа SCP. Варианта два - продолжить или прекратить обработку.
5. DP criteria, CAMEL Capability Handling, CSI state, Notification flag - параметры, которые я не рассматриваю, хотя они и есть.

Модель исходящего вызова (Originating Basic Call State Model, O-BCSM)
Обработка исходящего вызова происходит на Vistor MSC, т.е. на коммутаторе в котором абонент зарегистрирован в данный момент. VLR этого MSC уже содержит копию профиля абонента, а значит и O-CSI (если таковой у абонента имеется). В CAMEL определена такая модель исходящего вызова:

Надеюсь, Вы не закрыли эту страницу и читаете дальше. Если так, то постараюсь обьяснить на пальцах что же такое изображено на рисунке.

1. Вызов начинается с "O_Null & Authorise_Origination_Attempt_Collect_Info". В этом месте (Point In Call) производится проверка запретов (пользовательских и со стороны оператора) на исходящие вызовы и анализ O-CSI.
2. В DP Collected Info у нас уже есть обработанная информация из O-CSI. Если в O-CSI, в поле TDP List содержится DP Collected Info (а для исходящих звонков там может быть только DP Collected_Info и DP Route_Select_Failure), то инициируется запрос в SCP.
3. Далее вызов переходит в состояние "Analyse_Information". На входе (в DP Collected Info) содержится обработанная информация из O-CSI, потом производится "разбор" вызываемого номера (например определяется его тип -международный/национальный/неопределённый).
4. Предположим, что разбор номера произошёл успешно и вызов переходит в точку DP Analysed_Information. На этом этапе тоже возможен запрос к SCP (хотя детали мне не известны).
5. Далее происходит переход в состояние "Routing & Alerting". Здесь нам доступна информация о вызываемом номере и его типе (Nature of address - национальный, международный, неопределённый). Происходит непосредственный вызов абонента Б, в телефоне звучит ответ от удалённого коммутатора (КПВ или мелодия сервиса RBT). Исключением является событие Route_Select_Failure с последующим вызовом DP4. Это происходит если на коммутаторе не нашлось подходящего маршрута для установления соединения (в результате т.н. B-number analysis).
6. Далее будет либо ответ вызываемой стороны (по ISUP мы получим ANM), а значит переход в DP7 O_Answer, либо вызов будет неуспешным по одной из причин - занято (DP5), отсутствие ответа в течении заданного времени (DP6, время задаётся параметром в сообщении Request Report BCSM, но об этом позже), прерывание вызова А-абонентом (DP10).
7. Если ответа не было, то через PIC O_Exception коммутатор освобождает все ресурсы и закрывает CAMEL диалоги. И мы возвращаемся в самое начало.
8. Если вызов успешный и у нас был ответ удалённой стороны, то рано или поздно вызов будет завершен (DP9) и мы снова вернёмся в начало.

Модель входящего вызова (Terminating Basic Call State Model, T-BCSM)
Перед тем, как начать рассматривать входящие вызовы, я напомню, что мы имеем дело с мобильной сетью. А значит местоположение Б-номера заранее неизвестно. Задача определения текущего MSC вызываемого абонента в классической GSM сети (без CAMEL) была возложена на GMSC домашней сети. С введением CAMEL, именно на GMSC возложили задачу обработки T-CSI (Примечание. Согласно стандарту возможен также CAMEL диалог между VMSC и SCP). Как происходит обработка вызова на GMSC показано на рисунке ниже:

1. Вызов начинается с точки T_Null. Входящий вызов поступает на GMSC для обработки (ISUP IAM). Поскольку GMSC ничего не знает о вызываемом абоненте и его местоположении, то он отправляет MAP SendRoutingInformation на HLR. В ответе на запрос содержится текущий MSC абонента, а также его профиль. Происходит проверка запретов на вызовы, а также анализ CAMEL подписки для входящих вызовов - T-CSI.
2. В DP12 Terminating_Attempt_Authorised у нас уже есть обработанная информация из T-CSI. Если в T-CSI, в поле TDP List содержится DP Terminating_Attempt_Authorised (а для входящих звонков там может быть только DP Terminating_Attempt_Authorised, DP T_Busy, и DP T_No_Answer), то инициируется запрос в SCP.
3. Вызов переходит в PIC "Terminating Call Handling". В этом PIC осуществляется маршрутизация вызова и информирование Б-номера о поступлении вызова.
4. Далее будет либо ответ вызываемой стороны (по ISUP мы получим ANM), а значит переход в DP15 T_Answer, либо вызов будет неуспешным по одной из причин - занято/абонент недоступен/ошибка установления соединения (DP13), отсутствие ответа в течении заданного времени (DP14), прерывание вызова А-абонентом (DP18).
5. Если ответа не было, то через PIC T_Exception коммутатор освобождает все ресурсы и закрывает CAMEL диалоги. И мы возвращаемся в самое начало.
6. Если вызов успешный и у нас был ответ удалённой стороны, то рано или поздно вызов будет завершен (DP17) и мы снова вернёмся в начало.

Ближе к практике, ближе к SS7

Теперь рассмотрим как вызов выглядит с точки зрения сети SS7. Начнём с исходящего вызова.

1. MSC при обработке исходящего вызова останавливается в DP2, потому что в профиле абонента "активирован" триггер для DP2.
2. SSP (MSC в терминологии CAMEL) инициирует CAMEL-запрос InitialDP на адрес SCP из профиля абонента с просьбой указать, что делать с этим вызовом.
3. SCP анализирует запрос, выполняет внутреннюю логику (например, определяет - есть ли деньги на счету абонента для выполнения вызова) и отвечает сообщением RequestReportBCSM (если есть необходимость "активировать" триггеры), за которым следует одно из сообщений: Continue (продолжить вызов с теми же параметрами), Continue_With_Argument (если несколько параметров в вызове надо изменить) или Connect (внутри этого сообщения содержится новый Б-номер с которым должен быть установлен вызов). Если же вызов не должен быть продолжен, то SCP отвечает сообщением Release.
4. SSP продолжает обработку вызова и если в профиле абонента или в RequestReportBCSM были активированы триггеры, то с помощью сообщения EventReportBCSM SCP информируется о срабатывании DP.

Теперь подробно о каждом из сообщений.
Сообщение InitialDP содержит такие важные поля (подробное описание всех полей в 29.078):

• serviceKey - указатель на определённую логику в SCP. Например, SCP может предоставлять несколько разных услуг. Поле ServiceKey явно указывает какая именно CAMEL-услуга должна быть предоставлена для этого вызова.
• callingPartyNumber - номер вызывающего абонента (A-party number)
• locationNumber - номер MSC с которого происходит вызов
• eventTypeBCSM - описание триггера, который сработал. В нашем случае это DP2
• locationInformation - текущий VLR абонента и возраст этой информации
• calledPartyBCDNumber - вызываемый номер в BCD формате

Ответное сообщение RequestReportBCSM содержит список триггеров (bcsmEvents), которые необходимо установить в модели звонка. Для этого каждый триггер задаётся следующими параметрами:

• eventTypeBCSM - DP, в котором необходимо активировать триггер
• monitorMode - что делать SSP в случае срабатывания триггера. Варианты такие: interrupted (EDP-R, останов и ожидание инструкции от SCP); notifyAndContinue (EDP-N, просто информирование SCP о наступлении события); transparent (не сообщать о наступлении события).
• legID - указатель на "часть вызова" от которой ожидается получить нотификацию. Вызов условно разделяется на Исходящую (Originating, legID 1) и Входящую (Terminating, legID 2) части. В каждой из этих частей будет, например, своё событие Disconnect. Указатель legID позволяет понять от какой из частей вызова пришло извещение о событии.
• applicationTimer - параметр, который определяет значение таймера No_Answer для события No_Answer (DP6/DP14). Если вызываемый номер не ответил в течении заданного времени, то SSP должен сообщить об этом на SCP. Тут есть один ньюанс, который мне доводилось видеть на практике - значение этого таймера должно быть меньше чем соответствующий таймер неответа на MSC. Иначе вместо события No_Answer можно получить Busy.

Сообщение Continue особого интереса не представляет, поскольку не содержит никаких параметров - SCP просто указывает продолжить вызов.
Continue_With_Argument описано в спецификации, но в реальной жизни я этого сообщения никогда не видел. Поэтому писать о нём не рискну. Если у Вас имеется полезная информация об этом сообщении - милости прошу в комментарии.
CAMEL Connect. Самый главный параметр в этом сообщении это destinationRoutingAddress. Фактически, это новый номер на который должен пойти вызов. Пример, Вы пользователь услуги виртуальной АТС и позвонили на короткий номер Вашего босса - 777. SCP преобразует этот номер в "полный" MSISDN 380671234567 и отправит его в сообщении Connect.
Есть ещё сообщение ConnectToResource, которое очень похоже на Connect, только позволяет совершить соединение с новым номером до соединения с набранным номером. Обычно в качестве нового номера выступает Intelligent Peripheral. Таким образом, например, Вас могут предупредить о том, что средства на счету или срок их действия истекают. После предупреждения вызов будет продолжен.

Если в сообщении RequestReportBCSM были активированы триггеры, то SSP информирует об их срабатывнии с помощью сообщения EventReportBCSM. Это соощение будет содержать тип события (DP), которое произошло, и дополнительную информацию по этому событию. Например, в случае события Busy будет указано точная причина занятости (Subscriber absent, User busy).

Практически всё тоже самое происходит и при входящем вызове. Главным отличием, пожалуй, будет наличие поля calledPartyNumber в IntialDP.

Вот и всё. К сожалению кратко описать CAMEL так и не получилось, но я надеюсь что всё описано достаточно просто и понятно. Как обычно, если есть какие либо вопросы или замечания - используйте форму для комметариев.

Read More..