Взаємодія Tariscope з 3CX v20

Ця стаття призначена для користувачів ліцензій на системи Tariscope Enterprise або Tariscope Provider, з функцією обмеження, яка використовується для керування IP АТС 3CX v20.

Починаючи з версії Tariscope 4.6.7, був розроблений новий сценарій для додатку Tariscope Observer, який передає команди на обмеження абонентів або зняття цих обмежень окремому додатку TSconnector. Цей додаток встановлюється на сервері з 3CX v20, і вже він безпосередньо відправляє команди на цю АТС. Є окремі додатки для Windows і Linux, в залежності від того, на якій операційній системі працює 3CX. Схема взаємодії білінгової системи (системи обліку викликів) Tariscope з 3CX показана на малюнку 1.

 Малюнок 1

Всі налаштування системи обмеження в Tariscope виконуються, як і раніше, за виключенням вибору сценарію і встановлення додатку TSconnector.

Завантажте з сайту Tariscope відповідний додаток:

для Windows (tsconnector.zip) або Linux (tsconnector.tar.gz), в залежності від того на якій операційній системи у вас встановлений 3CX.

Для роботи додатку TSconnector потрібен конфігураційний файл від 3CX: 3CXPhoneSystem.ini

В Windows цей файл повинен знаходитися в теці: C:\ProgramData\3CX\Bin

В Linux цей файл повинен знаходитися в каталозі: /var/lib/3cxpbx/Bin/ 

Також треба надати доступ з інших комп’ютерів до серверу PostgreSQL, на якому встановлена база даних 3CX. Tariscope і TSconnector не працюють з базою даних 3CX, а використовують свою базу даних.

Для цього слід внести зміни в файл pg_hba.conf.

В Windows цей файл повинен знаходитися в теці: C:\ProgramData\3CX\Data\DB

В Linux цей файл повинен знаходитися в каталозі: var/lib/postgresql/<версія>/main/

Додайте нові рядки, щоб дозволити доступ з інших IP-адрес. 

Наприклад, для дозволу з'єднань з будь-якої IP-адреси:

host all all 0.0.0.0/0 password

Для дозволу з конкретної IP адреси, наприклад, 192.168.1.100, де встановлений Tariscope:

host all all 192.168.1.100/32 password

 Встановлення додатку під Windows

Розпакуйте архів tsconnector.zip в якусь теку, наприклад, в теку: C:\TSconnector

Копіюйте в цю теку файл 3CXPhoneSystem.ini

TSconnector виконує дії із встановлення або зняття обмежень, в залежності від того, які команди від Tariscope він отримає, з періодом, який задається в файлі config.json в секундах. За замовчуванням цей період становить 30 секунд. За необхідністю відкрийте цей файл і змініть період.

Відкрийте в Windows Командний рядок з правами адміністратора.

Створіть службу Windows наступною командою:

sc create TSconnector binpath= [шлях до файлу tsconnector.exe]

Наприклад, якщо ви розпакували архів до теки C:\TSconnector, то ця команда повинна виглядати наступним чином:

sc create TSconnector binpath= C:\TSconnector\ tsconnector.exe

Запустіть цю службу наступною командою:

sc start TSconnector

У випадку вдалого запуску служби в цій теці буде створений файл журналу роботи додатку TS_restrictions.log. Перевірте його вміст, що він не містить помилок.

Встановлення додатку під Linux

Розпакуйте архів tsconnector.tar.gz у якомусь каталозі, наприклад: /home/softpi/TSconnector (softpi тут ім'я користувача, з яким логінилися до системи).

Скопіюйте у цей каталог файл 3CXPhoneSystem.ini

Створіть файл unit для служби Linux, наприклад, з ім'ям ts-connector.service

Цей файл повинен містити наступні рядки:

[Unit]
Description=Tariscope restrictions

[Service]
Type=notify
ExecStart=/home/softpi/TSconnector/TSconnector

[Install]
WantedBy=multi-user.target

Коментарі до вмісту файлу:

Description – може бути довільним.

ExecStart - шлях до файлу TSconnector з архіву.

Скопіюйте цей файл у каталог /etc/system/system

sudo cp /home/softpi/TSconnector/ts-connector.service /etc/system/system

Перезавантажте служби Linux. Слід враховувати, що перевантажуватимуться всі служби, у тому числі й служби 3CX. Тому виберіть потрібний для цього час.

sudo systemctl daemon-reload

Перевірте стан демона ts-connector (якщо ви створите unit файл для служби з іншим ім'ям, використовуйте це ім'я і в наступній команді):

sudo systemctl status ts-connector

Якщо служба неактивна, запустіть її.

sudo systemctl start ts-connector

Якщо все виконано правильно, то має бути статус "active". У цьому випадку буде створено журнал роботи служби. Журнал роботи служби TS_restrictions.log перебуватиме в каталозі, де розпакували архів.

Налаштування сценарію Tariscope

В Tariscope виберіть Збір даних/Observer -> Керування збором даних.

На сторінці Збір даних/Observer виберіть рядок з Observer, який працює з 3CX v20.

На панелі інструментів клацніть по іконці Змінити і виберіть Сценарії Observer.

В переліку Подія виберіть необхідну, наприклад, Зміна класу абонента, яка відповідає умовам ліцензії на Tariscope.

В списку Сценарій виберіть: setcos-subscriber-3cx-v20.cs

Клацніть по іконці Змінити. З’явиться вікно Редагування, де буде відображений текст сценарію.

Знайдіть там наступні рядки і внесіть в них відповідні зміни:

const string DBHost = "127.0.0.1";   //IP address of PostgreSQL server
const string DBPort = "5432";        //IP port of PostgreSQL server
const string MasterDBUser = "phonesystem";   //Database username
const string MasterDBPassword = "pLvjPg8IKUo";   //Database username password

Для константи DBhost вкажіть IP адресу, де встановлений 3CX.

Для наступних 3-х констант сценарію треба замінити значення а ті, що використовуються у файлі 3CXPhoneSystem.ini в розділі CfgServerProfile.

Збережіть зміни в сценарії.

Після цього, якщо всі інші налаштування системи обмеження в Tariscope зроблені, можна запускати Observer.

Додатковий автоматичний аналіз викликів

У ряді випадків отримання обробленої в Tariscope інформації про виклики недостатньо і потрібен додатковий аналіз даних, який хотілося б, щоб Tariscope виконував автоматично. Наприклад, служба безпеки компанії хотіла б оперативно знати про всі виклики, які виконані співробітниками з телефонів відомчої АТС до пожежної охорони, поліції або швидкої допомоги. Інший приклад, коли бажано знати про всі вихідних дзвінків, вартість яких вище певної величини, або про дзвінки на (з) телефони із «чорного списку». Можна придумати ще цілий ряд випадків, коли необхідно оперативно отримувати повідомлення про певні виклики.

Звичайно, буде не кращим рішенням подібних завдань посадити за монітор з Tariscope співробітника, який би відстежував такі виклики. Але цього робити і не треба, якщо використовувати всі можливості Tariscope. Tariscope можна налаштувати так, що він буде після закінчення кожного виклику автоматично виконувати додатковий аналіз даних виклику на предмет відповідності попередньо заданим умовам, наприклад, як ми згадували раніше, виконання будь-яким співробітником компанії виклику на якісь конкретні телефонні номери.

Особливий випадок, який вимагає оперативного відстеження, це виявлення телефонного фрода. Під телефонним фродом мається на увазі певний тип шахрайства, коли різними засобами виконуються несанкціоновані виклики, як правило, міжнародні, за рахунок компанії. У 2023 році за даними міжнародної асоціації CFCA (Communications Fraud Control Association) втрати від телефонного фрода становлять десь 38,95 млрд. доларів США [1].

Виявлення фрода істотно складніше, ніж виявлення, наприклад, викликів на конкретні телефонні номери, так як заздалегідь невідомо, на які номери виконуються виклики, коли, якої тривалості. Для виявлення фрода, як правило, рекомендується використовувати спеціальні системи, в більшості випадків робота яких заснована на порівнянні конкретного виклику з моделлю поведінки конкретного абонента, групи абонентів і в цілому компанії. Tariscope має таку підсистему виявлення фрода, але ця підсистема не входить до базової ліцензії на Tariscope і повинна купуватися додатково до базової ліцензії.

В той же час, навіть не купивши таку підсистему, Tariscope дає можливість виявляти підозрілі виклики, які можуть бути фродом. В цій статті ми як раз і розглянемо, як це зробити.

По-перше, будемо розглядати тільки вихідні міжнародні дзвінки вартістю понад заданої величини, так як фрод значно рідше використовується для міжміських і тим більше міських викликів.

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

По-третє, можна оцінювати країни, куди виконувався виклик. Вважається, що найбільше дзвінків, які є фродом, виконується в країни Карибського басейну, а також Азії і Африки.

І, нарешті, можна оцінювати виклики на належність до фроду від абонентів, дані по яких відсутні в базі даних системи Tariscope.

Тепер розглянемо, яким чином пошук викликів із частиною зазначених вище ознак можна реалізувати в системі Tariscope.

У налаштуваннях служби Tariscope Observer є можливість виконувати сценарії при настанні певних подій. Для цього в гілці меню Збір даних/Observer системи Tariscope слід вибрати пункт меню Керування збором даних. Відкриється сторінка налаштування Збір даних/Observer, приклад якої наведений на малюнку 1.

Малюнок 1

Виберіть рядок з необхідних Observer-ом, якщо у вас їх декілька, і клацніть на панелі інструментів по іконці Змінити. В меню, що з’явиться, виберіть пункт Сценарії Observer. В наслідок чого відкриється сторінка Сценарії Observer, приклад якої показаний на малюнку 2.

Малюнок 2

Це вікно містить перелік подій, при настанні яких Tariscope може запустити пов'язаний з цією подією сценарій.

Можлива реакція на такі події:

• Підключення джерела даних.
• Відключення джерела даних.
• Зміна класу абонента.
• Зміна класу групи.
• Періодична дія.
• Новий виклик опрацьовано.
• Помилка підключення бази даних.

Для аналізу викликів на предмет належності їх до фроду в переліку Подія, слід вибрати подію Новий виклик опрацьовано, а в переліку Сценарії вибрати файл, який містить сценарій з аналізу фрода. Сценарії, що поставляються з Tariscope, за замовчуванням встановлюються в папку C:\ProgramData\Tariscope\ObserverScripts

Після вибору необхідного сценарію, збережіть налаштування (малюнок 2).

Сценарії повинні бути написані на мові C#. Серед сценаріїв, що постачаються з Tariscope є файл fraud.cs. Він дозволяє відправляти повідомлення або на задану в сценарії електронну адресу або на електронну адресу, задану в налаштуваннях Tariscope, про вихідні міжнародні дзвінки тривалістю понад 150 секунд, які виконані в проміжок часу: з 19:00 до 08:00. Ці параметри користувач Tariscope може змінити, видалити або додати інші.

Для написання нових сценаріїв або редагування існуючих бажано мати уявлення про програмування на мові C#, а також про створення SQL запитів.

Якщо ви не впевнені в своїх силах, зверніться в службу технічної підтримки компанії SoftPI, так як неправильно написаний сценарій може завдати шкоди системі Tariscope.

Написання сценаріїв силами компанії SoftPI не входить в послуги гарантійної або післягарантійних підтримок і виконується за окрему оплату.

Структура всіх сценаріїв, що використовуються в Tariscope, однакова. Кожен сценарій реалізує інтерфейс IScript.

У цьому інтерфейсі є два методи:

1. Метод Init. Цей метод викликається один раз під час запуску сценарію, коли служба Tariscope Observer компілює і ініціалізує цей сценарій.

2. Метод Main. У ньому виконуються операції, пов'язані з конкретною подією. У метод Main передається об'єкт Parameters.

3. При ініціалізації сценарію в нього передається інтерфейс IScriptHost, який дозволяє сценарію виконувати деякі операції. Наприклад, відправити повідомлення по електронній пошті.

Лістинг сценарію fraud.cs наведено нижче:

using Microsoft.Data.SqlClient;
using SoftPI.Tariscope.WebAdministration.Observer.Scripting.Interfaces;
using SoftPI.Tariscope.WebAdministration.Observer.Scripting.Models;
using System;
using SoftPi.Tariscope.DAL;

public class FraudScanner : IScript
{

    private IScriptHost Host;
    private bool NeedFinish = false;

  //     
                                                                                                                                                //
********************************************************************************************

  //

  private int MAX_CALL_DURATION_S = 150;
  private int CALLTYPE_INTERNATIONAL = 5;
  private TimeSpan BEGINNING_OF_WORK = TimeSpan.Parse("08:00:00");
  private TimeSpan END_OF_WORK = TimeSpan.Parse("19:00:00");
//     
                                                                                                                                                //
*********************************************************************************************

// 
  public void Init(IScriptHost host)
   {
     this.Host = host;
     host.Close += OnClose;
     NeedFinish = false;
   }

  private void OnClose(ref bool Cancel)
  {
    return;
  }

  public void Main(object Parameters)
  {
     NewCallActionParameters actionParameters = (NewCallActionParameters)Parameters;

try
  {
     this.Host.AddEvent("New call processing, ID= " + actionParameters.Id);

     using (SqlConnection cn = new SqlConnection(this.Host.DatabaseConnectionString))
  {

       cn.Open();
       CallItems CallItems = CallItems.Instance(cn);
       SqlCommand cmd = CallItems.GetCommand("SELECT ID, Originator, Dialnumber,
                                                    CallDateTime, CallSeconds, CallType FROM viCalls WHERE ID=@callid");
cmd.Parameters.AddWithValue("@callid", actionParameters.Id);
       using (SqlDataReader rs = cmd.ExecuteReader())
        {
           if (rs.Read())
           {
              if (rs.GetInt16(5) == CALLTYPE_INTERNATIONAL &&
                  rs.GetInt32(4) > MAX_CALL_DURATION_S &&
                 (((rs.GetDateTime(3).TimeOfDay > END_OF_WORK ||
                    rs.GetDateTime(3).TimeOfDay < BEGINNING_OF_WORK)) ||
                    (rs.GetDateTime(3).DayOfWeek == DayOfWeek.Sunday ||
                    rs.GetDateTime(3).DayOfWeek == DayOfWeek.Saturday)))
             this.Host.SendMail("", "Fraud Detection system", "Suspicious call detected. ID=" + actionParameters.Id + " CallDateTime=" + rs.GetDateTime(3) + " Call duration=" + rs.GetInt32(4));
                       }
                     }
                 }
               }
               catch (Exception ex)
               {
                  this.Host.AddEvent("Error running script: " + ex.ToString());
               }
           }
       }

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

Розглянемо перші чотири виділені рядки:

  private int MAX_CALL_DURATION_S = 150;
  private int CALLTYPE_INTERNATIONAL = 5;
  private TimeSpan BEGINNING_OF_WORK = TimeSpan.Parse("08:00:00");
  private TimeSpan END_OF_WORK = TimeSpan.Parse("19:00:00");

Ці рядки оголошують чотири змінні:

• MAX_CALL_DURATION_S – це тривалість розмови, яка дорівнює 150 секунд, тобто 2 хвилини 30 секунд. Ви можете змінити це значення на будь-яке ціле позитивне число або 0.
• CALLTYPE_INTERNATIONAL – це тип виклику для міжнародних розмов, який застосовується в Tariscope. Його значення дорівнює 5. Якщо ви збираєтеся розглядати тільки міжнародні виклики, то не змінюйте це значення. Якщо вас цікавлять інші виклики, то визначити їх значення ви можете з документу Tariscope 4.6. Каталог бази даних.
• BEGINNING_OF_WORK – це час початку роботого дня, який тут дорівнює 8 годині ранку. Ви можете змінити це значення на будь-яке інше реальне значення часу початку робочого дня.
• END_OF_WORK – це час закінчення робочого дня, який тут дорівнює 7 годині вечора. Ви можете змінити це значення на будь-яке інше реальне значення часу закінчення робочого дня.

Наступний виділений рядок:

SELECT ID, Originator, Dialnumber, CallDateTime, CallSeconds, CallType FROM viCalls WHERE ID=@callid

Це SQL запит до подання viCalls на отримання з нього для поточного виклику, що задається умовою ID=@callid , де @callid є параметром, який містить ідентифікатор останнього виклику, що був оброблений в Observer. Цей SQL запит дозволяє отримати наступні поля:

• ID. Ідентифікатор запису.
• Originator. Телефонний номер, з якого був виконаний виклик.
• Dialnumber. Телефонний номер, на який був виконаний виклик.
• CallDateTime. Дата і час виконання виклику.
• CallSeconds. Тривалість виклику в секундах.
• CallType. Тип виклику.

За необхідності можливо отримати і інші параметри виклику з переліку полів подання viCall.

Наступна виділена частина сценарію виконує аналіз даних на відповідність заданим умовам:

 (rs.GetInt16(5) == CALLTYPE_INTERNATIONAL &&
 rs.GetInt32(4) > MAX_CALL_DURATION_S &&
(((rs.GetDateTime(3).TimeOfDay > END_OF_WORK ||
rs.GetDateTime(3).TimeOfDay < BEGINNING_OF_WORK)) ||
(rs.GetDateTime(3).DayOfWeek == DayOfWeek.Sunday ||
rs.GetDateTime(3).DayOfWeek == DayOfWeek.Saturday)))

Цей код використовується в операторі if як умова відповідності даних. Він складається з наступних умов:

rs.GetInt16(5) = CALLTYPE_INTERNATIONAL
Береться значення 5-го поля запиту (поле CallType в SQL запиті). Відлік полів починається з 0. Значення поля порівнюється зі значенням змінної CALLTYPE_INTERNATIONAL. Тобто ця умова дозволяє виявити чи є цей виклик міжнародним.

rs.GetInt32(4) > MAX_CALL_DURATION_S
Береться значення 4-го поля SQL запиту (поле CallSeconds). Відлік значень починається з 0. Значення поля порівнюється зі значенням змінної MAX_CALL_DURATION_S.

(rs.GetDateTime(3).TimeOfDay > END_OF_WORK ||
rs.GetDateTime(3).TimeOfDay < BEGINNING_OF_WORK))

В цій умові використовується значення 3-го поля запиту, тобто поля CallDateTime. Перевіряється, чи припадає час виклику на проміжок часу між закінченням робочого дня і початком наступного робочого дня.

(rs.GetDateTime(3).DayOfWeek == DayOfWeek.Sunday ||
rs.GetDateTime(3).DayOfWeek == DayOfWeek.Saturday)

Це є альтернативна умова часу виклику, якій повинні відповідати всі міжнародні виклики тривалістю більше 150 секунд, що виконані в суботу або неділю.

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

Якщо результат перевірки є істина, то виконується команда з відправки електронною поштою повідомлення про цей виклик.

this.Host.SendMail("", "Fraud Detection system", "Suspicious call detected. ID=" + actionParameters.Id + " CallDateTime=" + rs.GetDateTime(3) + " Call duration=" + rs.GetInt32(4));

this.Host.SendMail() – це функція, за допомогою якої виконується відправка повідомлення електронною поштою. Ця функція має три параметри, які знаходяться всередині дужок і розділяються комами:

• Перший параметр задає електронну адресу, куди виконується відправка повідомлення. Якщо цей параметр порожній (""), як зазначено в наведеному вище виразі, то використовується електронна адреса, вказана в налаштуванні Tariscope Повідомлення та пошта. Якщо ви бажаєте відправляти повідомлення на якусь іншу адресу, ніж зазначену на цій сторінці налаштування або ви не налаштовували цей параметр в Tariscope, то в лапках слід задати цю адресу, наприклад, "Ця електронна адреса захищена від спам-ботів. Вам потрібно увімкнути JavaScript, щоб побачити її.".
• Другим параметром є тема електронного листа. У цьому сценарії таким параметром є "Fraud Detection system". При бажанні можно замінити цей параметр, наприклад, на "Отримано виклик з ознаками фрода" або якийсь інший.
• Третій параметр - це вміст тексту повідомлення. В даному сценарії це:
  
  "Suspicious call detected. ID=" + actionParameters.Id + " CallDateTime=" + rs.GetDateTime(3) + " Call duration=" + rs.GetInt32(4) .

Розглянемо більш докладно цей рядок.

Частину рядка "Suspicious call detected. ID=" можна замінити, наприклад, на наступне:
“Виявлений підозрілий виклик з ідентифікатором =” . Значення цього ідентифікатора знаходиться в параметрі actionParameters.ID.

Наступна частина рядка " CallDateTime=" + rs.GetDateTime(3) буде відображати дату і час цього виклику. Можливо, буде краще, якщо цю частину рядка замінити на наступну:
“ Дата і час виклику: “ & rs.GetDateTime(3)

І, наостанок, вираз + " Call duration=" + rs.GetInt32(4) буде містити тривалість виклику. Також, для зручності сприйняття інформації, можна замінити цю частину рядка на:
“ Тривалість виклику:” & rs.GetInt32(4)

У рядку SQL запиту, який розглядався вище, міститься запит ще двох параметрів: Originator і Dialnumber. Відповідно, їх значення також можливо виводити в тілі електронного листа. Для цього слід додати наступний рядок:

“ Виклик виконувався з номера ” & rs.GetInt32(1) “ на номер “ & rs.GetImt32(2)

Якщо модифікувати SQL запит, то в повідомленні можливо виводити інформацію про абонента, з номера якого виконувався виклик, найменування населеного пункту, куди виконувався виклик та іншу інформацію.

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

Private decimal MAX_CALL_COST = 10.0

Тепер необхідно додати в SQL запит отримання інформації про вартість виклику. Для цього слід скористатися описом подання viCalls в документі "Каталог баз даних Tariscope 4.x", щоб знайти необхідне поле. Це поле Cost. Тоді запит повинен виглядати наступним чином:

SELECT ID, Originator, Dialnumber, CallDateTime, CallSeconds, CallType, Cost FROM viCalls WHERE ID=@callid

Якщо нас не цікавить тривалість виклику, то із запиту можна виключити поле CallSeconds. І тепер, отримавши за допомогою цього SQL запиту дані за викликом, слід їх проаналізувати на відповідність умов, які нас цікавлять: міжнародний виклик з вартістю понад 10 гривень. Для цього рядок, де проводиться аналіз, потрібно записати наступним чином:

(rs.GetInt16(5) = CALLTYPE_INTERNATIONAL &&
rs.GetInt32(4)> MAX_CALL_DURATION_S &&

rs.GetDecimal(6) > 10.0) &&
(((rs.GetDateTime(3).TimeOfDay > END_OF_WORK ||
rs.GetDateTime(3).TimeOfDay < BEGINNING_OF_WORK)) ||
(rs.GetDateTime(3).DayOfWeek == DayOfWeek.Sunday ||
rs.GetDateTime(3).DayOfWeek == DayOfWeek.Saturday))

Цей рядок передбачає, що запит поля CallSeconds залишився. У разі, якщо його видалили, у рядку аналізу даних зміниться значення в дужках, які вказують на номер поля в запиті, починаючи з 0.

Аналогічним чином можна і далі ускладнювати умови для виявлення викликів з ознаками фрода.

При використанні сценаріїв для додаткової обробки даних викликів слід завжди пам'ятати, що це використання підвищує навантаження на сервер і може привести до уповільнення обробки.

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

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

Посилання

1. https://cfca.org/telecommunications-fraud-increased-12-in-2023-equating-to-an-estimated-38-95-billion-lost-to-fraud/

Обробка SMDR від Mitel MiVoice Business в Tariscope

Обробка SMDR даних від Mitel MiVoice Business в системі обліку телефонних викликів Tariscope виконана для наступних налаштувань SMDR параметрів в АТС цього типу:

Рекомендуємо саме таким чином налаштовувати АТС Mitel MiVoice Business.

Mitel MiVoice Business (3300) використовує передачу даних з IP порту 1752. З боку Tariscope для отримання SMDR даних слід використовувати Tariscope Observer, у якого в якості джерела даних використовується TCP клієнт.

Особливістю парсеру Mitel 3300 (MiVoice Business) є те, що в поле Код проєкту для викликів з використанням трансферу заноситься наступна інформація: для першого етапу трансферу - про номер, на який переданий виклик, а для другого етапу трансферу – про номер, з якого отриманий виклик. Приклад цього можна побачити на малюнку нижче.

На цьому малюнку відображені етапи виклику з використанням трансферу. Якщо в поданні для викликів вибрати рядок, де є один із етапів виконання трансферу і клацнути на панелі інструментів по іконці Показати пов’язані записи, то подання відобразить всі етапи цього виклику, як показано на малюнку вище.

Робота із шлюзами SBC 1000 та SBC 2000 в Tariscope

До білінгової системи Tariscope додана можливість збору і обробки CDR інформації від шлюзів SBC 1000 та SBC 2000 від компанії Ribbon Communications.

Ці шлюзи передають CDR дані тільки на Radius accounting сервер. Тому в служби Tariscope Observer було додане нове джерело даних - Radius accounting сервер. Пакети даних, що передаються на Radius accounting сервер бувають двох типів: Стартові (Start) та Стопові (Stop). Узагальнена інформація про виконаний виклик міститься тільки в Стопових пакетах, тому в Tariscope виконується тільки їх обробка. Як Стартові, так і Стопові пакети, в SBC формуються для кожного учаснику виклику. Обробляється тільки один Стоповий пакет, щоб уникнути дублювання даних в системі Tariscope.

Далі ми наведемо особливості налаштування Tariscope, які пов’язані саме шлюзами SBC 1000 та SBC 2000.

В першу чергу треба створити відповідну телефонну систему в Tariscope. Для цього в меню виберіть: Вузли зв’язку → ваш вузол → Пристрої → Управління пристроями.

З'явиться сторінка Пристрої, приклад якої наведений на малюнку 1.

Малюнок 1

Клацніть по іконці Додати на панелі інструментів. У вікні Новий пристрій, що з’явиться введіть будь-яку назву. Рекомендуємо вводити таку назву, яка відповідає телефонній системі, наприклад, SBC 1000. Клацніть Зберегти. З’явиться сторінка Редагування, що показана на малюнку 2.

Малюнок 2

І нарешті треба створити службу Tariscope Observer, яка буде отримувати CDR дані від SBC шлюзів і виконувати обробку цих даних.

Виберіть в меню Збір даних/Observer → Керування збором даних. Відобразиться відповідна сторінка, де на панелі інструментів клацніть Додати → Новий Observer. З’явиться відповідне вікно, де введіть назву профілю Observer-а. Наприклад, це може бути: SBC 1000. Натисніть Зберегти. З’явиться вікно, що підтверджує створення нового профілю Observer-а, де клацніть по кнопці Налаштування. Відобразиться сторінка Налаштування Tariscope Observer, приклад якої показаний на малюнку 3.

Малюнок 3

В позиції Пристрій вказано «не обрано», що означає, що ви повинні вказати телефонну систему із раніше створених, для якої призначений цей Observer. Клацніть по посиланню «тут» і виберіть потрібний вузол зв’язку та телефонну систему.

В переліку Джерело даних виберіть значення Radius accounting server. Натисніть на кнопку Налаштування джерела даних, що знаходиться праворуч від переліку Джерело даних. З’явиться вікно Налаштування джерела даних, приклад якого наведений на малюнку 4.

Малюнок 4

В позиції Порт вкажіть номер IP порту, на якому буде працювати Radius accounting сервер. За замовчування стандартним портом для цього серверу вважається 1813. Якщо ви маєте декілька телефонних систем, які повинні передавати CDR дані в Tariscope через Radius accounting сервер, то для першого Radius accounting сервера використовуйте порт 1813, а для інших Radius серверів – інші IP порти, які вільні в вашій системі.

В позиції Спільний секрет введіть значення спільно секрету. Таке саме значення повинно бути і в налаштуваннях телефонної системи, яка буде передавати CDR дані.

Натисніть Готово.

На цьому налаштування, які є особливими для шлюзів SBC 1000 та 2000 закінчені. Всі інші налаштування в Tariscope виконуйте згідно рекомендація наведеним в документі Tariscope 4.6. Керівництво адміністратора.