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

• Получение информации об исходящем вызове в режиме времени, приближенному к реальному. Эта информация необходима для функциональности узел верификации Антифрода (далее АФ) для реализации верификации исходящих вызовов.

• Контроль входящих вызовов с присоединенных операторов. Целью данной интеграции является осуществление верификации входящих вызовов.

Физически АФ располагается в контуре оператора связи, IP связанность оборудования оператора связи с АФ находится в зоне ответственности оператора. Обеспечение требований информационной безопасности, включая организацию защищенных соединений с помощью оборудования VipNet, находится в зоне ответственности оператора связи в соответствии с техническими требованиями на подключение операторов связи к ИС «Антифрод».

Для организации IP связанности для RADIUS сообщений для АФ оператором связи выделяется IP адрес. В случае резервирования соответственно необходимо два IP, один для основного АФ, второй для резервного.

Описание взаимодействия с ИС «Антифрод»

рис. 1   Схема взаимодействия с ИС «Антифрод»

на рис. 1 : АФ - Антифрод (узел верификации(УВр)), ОС - оператор связи, МО - мобильный оператор, CAP - CAMEL Application Part (сигнальный протокол сети IN), SSW - софтсвич ELTEX

Взаимодействие виртуальной АТС комплекса ECSS-10 с узлами верификации (далее - УВр) ИС «Антифрод» осуществляется по протоколу RADIUS. При реализации интерфейса взаимодействия с УВр решаются две основные задачи:

• Регистрация исходящих вызовов;

• Проверка валидности входящих вызовов;

Для настройки взаимодействия между комплексом ECSS-10 и Узлом верификации нужно:

Проверить наличие лицензии :

cluster/storage/ds1/licence/show-licence 2 
SSW ID                                                ECSS-TEST-3.14.15.4
Description                                           Лицензия для ECSS-TEST
Creation date                                         11.09.2024 12:29:00
Expiration date (UTC)                                 30.12.2024 23:59:59
. . . 
Support antifraud system                              custom
. . .

Так же можно проверить наличие лицензии antifraud через веб интерфейс:

при отсутствии лицензии - запросите его у Eltex , а затем  установите 

Декларирование RADIUS-сервера(узла верификации) через CoCon:

Путь команды:
/domain/<DOMAIN>/aaa/radius/declare

Синтаксис:
declare <NAME> <HOST> <PORT> <SECRET> [<OptionName> = <OptionValue>, ...]

Параметры:
<DOMAIN> - имя виртуальной АТС;
<NAME> - имя RADIUS-сервера;
<HOST> - IP-адрес или имя хоста RADIUS-сервера;
<PORT> - номер порта для RADIUS-сервера;
<SECRET> - пароль для авторизации на RADIUS-сервере;
<OptionName> - имя настраиваемого параметра: retry-count, retry-timeout, idle-timeout. Описание параметров приведено в таблице 1;
<OptionValue> - значение настраиваемого параметра.

Таблица 1 - Описание свойств RADIUS-сервера

Пример:

/domain/test_domain/aaa/radius/declare antifraud 10.0.20.35 1812 radius123               
Radius server "antifraud" successfully declared.

Декларирование RADIUS-сервера(узла верификации) через веб интерфейс.

Декларирование RADIUS-сервера через web-конфигуратор:

1. Выберите приложение "Домены" , требуемый домен (для примера test_domain);
2. Выберите Свойства Домена / RADIUS серверы;
3. Выберите Добавить RADIUS сервер;
4. Укажите -"Имя нового RADIUS сервера (для примера "antifraud")"/ Ip адрес хоста / Секретный ключ.
   Аналогично добавить сервер аккаунтинг;

В результате получим следующую конфигурацию:

Настройка подсистемы antifraud:

Команды выполняются администратором виртуальной АТС.

Путь команды:

/domain/<DOMAIN>/aaa/antifraud/set

Синтаксис:

set <Field> <Value>
В таблице 1 приведено описание свойств службы Antifraud.

Таблица 1 - Описание свойств службы RADIUS antifraud

• Активация подсистемы Antifraud:

/domain/<DOMAIN>/aaa/antifraud/set enable true

• Указание логина:

/domain/<DOMAIN>/aaa/antifraud/set login default | billing | cgpn | <LOGIN_TEMPLATE>

• Указание пароля:

/domain/<DOMAIN>/aaa/antifraud/set password <PASSWORD>

• Добавление идентификатора сервера верификации созданного в П.1:

/domain/<DOMAIN>/aaa/antifraud/set access_servers add <ACCESS_SERVRS>

• Указание идентификатора оператора (если требуется):

/domain/<DOMAIN>/aaa/antifraud/set operator-id <ID>

• Если какой-либо транк является в рамках Antifraud-системы локальным и не требуется отправлять идентификаторы вх/исх вызовов узлу верификации, необходимо установить флаг antifraud-local в свойствах транка:

/domain/<DOMAIN>/trunk/set <GROUP> <INTERFACE> antifraud-local true

• На SSW есть возможность модифицировать информацию, отправляемую в Antifraud-системы через адаптацию. Для этого нужно указать контекст адаптации в свойстве службы антифрод - «adaptation» :

/domain/<DOMAIN>/aaa/antifraud/set adaptation <context_adaptation>

• Поля «RedirectingNumber» в сообщениях save_call и check_call опциональны. По умолчанию они отключены. При необходимости их можно включить:

/domain/<DOMAIN>/aaa/antifraud/set enable_redirect_headers true

Настройка подсистемы antifraud через веб интерфейс:

1. Выберите приложение "Домены" ;
2. Выбрать требуемый домен из списка (для примера test_domain);
3. Выберите Свойства домена;
4. Выберите RADIUS серверы/RADIUS antifraud , отредактируйте параметры;

Формат запроса

Передача информации об исходящем вызове(исходящий вызов со станции) осуществляется отправкой с виртуальной АТС комплекса ECSS-10 RADIUS сообщения Access-Request - save_call с полями:

Обеспечение верификации вызова(входящий вызов на станцию) осуществляется отправкой с виртуальной АТС комплекса ECSS-10 RADIUS сообщения Access-Request - check_call с полями:

При активированных услугах переадресации без уведомления(cfnr_type2, cfu_type2), SSW будет отправлять запросы save_call и check_call без полей «RedirectingNumber»

Формат запроса

Передача информации об исходящем вызове осуществляется отправкой с узла связи RADIUS-сообщения Access-Request с полями:

Called-Station-Id(30): <$CdPN_IN>
Calling-Station-Id(31): <$CgPN_IN>
Acct-Session-Id(44): <$SESSION_ID>
Vendor-Specific(26): Cisco(9): Cisco-AVPair(1): xpgk-request-type=save_call
Vendor-Specific(26): Cisco(9): Cisco-AVPair(1): xpgk-termination-gateway-ip=$SSW_IP

Обеспечение верификации вызова осуществляется отправкой с узла связи RADIUS-сообщения Access-Request с полями:

Called-Station-Id(30): <$CdPN_IN>
Calling-Station-Id(31): <$CgPN_IN>
Acct-Session-Id(44): <$SESSION_ID>
Vendor-Specific(26): Cisco(9): Cisco-AVPair(1): xpgk-request-type=check_call
Vendor-Specific(26): Cisco(9): Cisco-AVPair(1): xpgk-termination-gateway-ip=$SSW_IP

Обеспечение контроля длительности вызовов и причины отбоя успешных/неуспешных вызовов осуществляется отправкой с узла связи RADIUS-сообщения Accounting-Request с полями:

Called-Station-Id(30): <$CdPN>
Calling-Station-Id(31): <$CgPN_IN>
Acct-Delay-Time(41): согласно RFC2866
Event-Timestamp(55): согласно RFC2869
Acct-Session-Id(44): <$SESSION_ID>
Acct-Session-Time(46): <$SESSION_TIME>
Vendor-Specific(26): Cisco(9): Cisco-AVPair(30): h323-disconnect-cause=<$DISCONNECT_CAUSE>
Vendor-Specific(26): Cisco(9): h323-setup-time(25): h323-setup-time=<$TIME_SETUP>
Vendor-Specific(26): Cisco(9): h323-connect-time(28): h323-connect-time=<$TIME_CONNECT
Vendor-Specific(26): Cisco(9): h323-disconnect-time(29): h323-disconnect-time=<$TIME_DISCONNECT>

Формат ответа

В качестве подтверждения получения переданной информации об исходящем вызове ожидается RADIUS сообщение Access-Accept.

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

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

При получении ответа Access-Accept вызов будет продолжен.

Также вызов будет продолжен по истечении таймаута ответа сервера и всех попыток, в случае если резервный RADIUS-сервер не был настроен либо недоступны все сервера в списке.

В случае неуспешной верификации вызова ожидается RADIUS сообщение Access-Reject, с дополнительными полями, однозначно идентифицирующими ошибку.

При получении Access-Reject вызов будет прерван.

В качестве подтверждения получения переданного пакета аккаунтинга ожидается RADIUS-сообщение Accounting-Response. При отсутствии ответа сервер будет помечен как недоступный.