Обработка SMDR от Mitel MiVoice Business в Tariscope
Обработка SMDR данных от Mitel MiVoice Business в системе учета телефонных вызовов Tariscope выполнена для следующих настроек параметров SMDR в АТС этого типа:
DASS II - Call Charge Information Provided: | No |
Extended Digit Length: | No |
MCD - Report Transfers: | No |
Network Format: | Yes |
Report Account Codes: | No |
Report Incoming Calls: | Yes |
Report Internal Calls: | Yes |
Report Meter Pulses: | No |
Report Outgoing Calls: | Yes |
SMDR Meter Unit Per Station: | Yes |
SMDR Record Transfer: | No |
System Identification: | |
Time Change Reporting: | No |
Twenty-four Hour Time Reporting: | No |
ANI/DNIS/ISDN/CLASS Number Delivery Reporting: | No |
SMDR Real Time Reporting: | No |
OLI Node ID Format for Incoming Trunk Calls: | No |
Extended Time To Answer: | Yes |
SMDR File Transfer: | Yes |
Standardized Network OLI: | No |
Standardized Call ID Format: | No |
Suite Services Reporting: | No |
Report Internal Unanswered Calls: | No |
SMDR Extended Reporting Level 1: | No |
Report Attendant Name: | No |
Account Code Reporting for Internal Calls: | No |
Tag Call Reporting: | No |
Tag Call Identifier: | |
Path Reporting for Internal ACD2 Calls: | No |
Number of destination address digits to mask: | 0 |
SMDR Extended Reporting Level 2: | No |
Two B-Channel Transfer Reporting: | No |
External Hot Desk User Reporting: | No |
Suppress Initial SMDR Record with Account Code Entered Timer | 5 |
Location Information Reporting: | No |
SMDR Port Enabled: | Yes |
Рекомендуем именно таким образом настраивать АТС Mitel MiVoice Business.
Mitel MiVoice Business (3300) использует передачу данных из IP порта 1752. Со стороны Tariscope для получения данных SMDR следует использовать Tariscope Observer, у которого в качестве источника данных используется TCP клиент.
Особенностью парсера Mitel 3300 (MiVoice Business) является то, что в поле Код проекта для вызовов с использованием трансфера заносится следующая информация: для первого этапа трансфера - номер, на который передан вызов, а для второго этапа трансфера - номер, с которого получен вызов. Пример этого можно увидеть на рисунке ниже.
На этом рисунке отображены этапы вызова с использованием трансфера. Если в представлении вызовов выбрать строку, где есть один из этапов выполнения трансфера и щелкнуть на панели инструментов по иконке Показать связанные записи, то представление отобразит все этапы этого вызова, как показано на рисунке выше.
Дополнительный автоматический анализ вызовов
В ряде случаев получения обработанной в 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 запрос, то в сообщении можно выводить информацию об абоненте, из номера которого выполнялся вызов, наименование населенного пункта, куда выполнялся вызов и другую информацию.
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.
Источники:
Настройки Observer-ов в Tariscope
Служба Tariscope Observer (или просто Observer) предназначена для автоматического получения информации о выполненных вызовах (CDR, SMDR, AMA и др.) от АТС или из находящихся в какой-то папке файлов, первичной обработки этих данных, а также для выполнения сценариев по отдельным событиям .
То есть Observer является звеном, сочетающим телефонную систему с системой Tariscope. Один Observer предназначен для взаимодействия с одной телефонной системой (АТС). Tariscope не имеет ограничений на количество Observerов, из которых он может получать информацию. Observer может быть сконфигурирован на получение CDR информации из различных типов источников данных, которые описываются ниже. Выбор типа источника данных сначала зависит от типа телефонной системы, из которой получаются CDR данные.
Observer могут находиться как на том же сервере, где находится система Tariscope, так и на удаленном компьютере (сервере), имеющем связь с сервером Tariscope через сеть IP. Любой, локальный или удаленный Observer должен иметь IP связь с сервером Tariscope (служба TS.MAIN) и Microsoft SQL Server (в дальнейшем "SQL сервер"), на котором установлена база данных Tariscope. При запуске Observer он связывается с сервером Tariscope, получает от него строку подключения к базе данных, после чего подключается к базе данных Tariscope. Если у вас используются межсетевой экран или другие системы безопасности, вы должны настроить их так, чтобы обеспечить IP доступ Observer к серверу Tariscope (IP порт: 8001) и SQL серверу (IP порт: 1433, 1434).
В качестве событий, на которые может реагировать Observer, выполнением конкретного сценария могут быть:
- Подключение источника данных.
- Отключение источника данных.
- Смена класса абонента. Это событие актуально, если лицензия Tariscope включает ограничение для абонентов.
- Смена класса групп. Это событие актуально, если лицензия Tariscope включает ограничение для групп или групп и абонентов.
- Периодическое событие.
- Новый вызов обработан. Сценарий по этому событию позволяет выполнить какую-либо дополнительную обработку данных по информации о полученном вызове. Например, можно проверить, не набран ли номер в какой-либо конкретной группе телефонных номеров.
- Ошибка подключения базы данных. Это событие может быть актуально, если Observer и Microsoft SQL Server находятся на разных серверах. При утере связи с базой данных можно отправлять сообщения администратору.
Независимо от того, вы настраиваете локальные Observer-ы или удаленные, нужно выполнить настройки в приложении Tariscope. Эти настройки одинаковы для обоих типов Observer-ов. В дальнейшем будут рассмотрены особенности донастройки удаленных Observer-ов.
В меню Tariscope выберите: Сбор данных/Observer → Управление сбором данных. Появится страница, пример которой приведен на рисунке 1.
Рисунок 1
Добавляем новый Observer. Щелкните по иконке Добавить на панели инструментов. Появится меню, в котором выберите Новый Observer. Появится окно, приведенное на рисунке 2.
Рисунок 2
В позиции Название введите название профайла Observer. Рекомендуем называть профайл именем телефонной системы, из которой этот Observer будет принимать данные. Например, нужно получать данные из CUCM (Cisco). В этом случае лучше и назвать профайл: CUCM. Название не должно содержать каких-либо символов, кроме букв и цифр. Щелкните Сохранить. В подтверждении создания профайла отобразится окно (Рисунок 3).
Рисунок 3
Нажмите кнопку Настройки. Появится окно Настройки Tariscope Observer (название профайла), пример которого показан на рисунке 4.
Рисунок 4
Щелкните по ссылке "тут" и выберите существующую в системе телефонную систему. Для нашего примера это должно быть именно CUCM.
В списке Источник данных выберите соответствующий источник. Для нашего примера если CUCM сконфигурирован как FTP клиент, то в качестве источника данных должен быть FTP сервер. Для других типов телефонных систем в качестве источника данных могут быть: FTP клиент, TCP клиент или сервер, локальная или удаленная папка и другие в зависимости от того, каким образом телефонная система отдает CDR данные. Для настройки параметров источника данных щелкните по кнопке справа от списка Источник данных и выполните настройки. Описание настройки конкретного источника данных см. в документации.
Позиция Хранилище обработанных CDR предназначено для выбора папки для хранения первичных CDR данных, получаемых из телефонной системы. Эти данные могут быть использованы при необходимости полной переработки данных о вызовах. По умолчанию они хранятся в папке C:\ProgramData\Tariscope. Журналы CDR имеют расширение CDR, а название файла включает название профиля Observer и дату.
В списке Период создания выберите период для создания журналов с первоначальными CDR данными. Период создания зависит от активности выполнения звонков. Чем она выше, тем лучше выбирать меньшее время. По умолчанию в качестве периода предлагается один месяц.
В списке Журналирование выберите уровень детализации журнала работы профиля Observer. Наименее подробный уровень – это Статус, наиболее подробный уровень – Настройка.
На этом насстройка локального Observer-а заканчивается. Если вы выполняете настройку удаленного Observer-а, то включите переключатель Удаленный сбор данных.
Щелкните по кнопке Сохранить. Страница Сбор данных/Observer примет вид, как показано на рисунке 5.
Рисунок 5
Если вы создали локальный Observer, его можно запустить, для чего щелкните по иконке Управление и выберите Запустить.
В том случае, когда вы настраивали профайл для удаленного Observer-а, выполните следующие действия.
Работа на удаленном сервере
Перед выполнением настроек на удаленном сервере вы должны:
- Выполнить настройки, указанные выше на сервере Tariscope;
- Если на сервере Tariscope работает файл, добавьте правила, которые обеспечат доступ к IP портам: 8001 (на нем работает сервер Tariscope), 1433, 1434 (порты SQL сервера).
- Убедитесь, что сервер, где установлен Tariscope, доступен по сети с удаленного сервера, где устанавливается удаленный Observer.
На удаленном сервере (компьютере) выполните инсталляцию Tariscope.
При установке на этапе Компоненты Tariscope (рисунок 1.1.5 в статье по приведенной выше ссылке) выберите Observer сервер. По умолчанию установка выполняется в папке: C:\Program Files (x86)\SoftPI\Tariscope
Для запуска удаленного Observer-а вы должны знать:
- IP адрес сервера, где установлен сервер Tariscope. Например, IP адрес сервера Tariscope: 10.10.0.148
- а также название профайла, который там был создан именно для этого Observer-а. В нашем примере это: CUCM
Откройте Командную строку с правами администратора Windows. Выполните там следующие команды:
1. Переход к папке с программным обеспечением. Если вы устанавливали в папку по умолчанию, то это будет команда:
cd C:\Program files (x86)\SoftPI\Tariscope\Microservices
2. Далее запустите удаленный Observer, в качестве параметров укажите название профайла (параметр name) и URL сервера Tariscope (параметр main). Пример такой программы приведен ниже:
.\Tariscope.Observer.exe /name=CUCM /main=”http://10.10.0.148:8001”
В этом примере название профайла CUCM, а URL сервера Tariscope: http://10.10.0.148:8001, где 10.10.0.148 – это IP адрес сервера, а 8001 – IP порт, на котором работает сервер.
Пример такого ввода данных показан на рисунке 6.
Рисунок 6
Если все настройки выполнены правильно и сеть обеспечивает доступ от удаленного Observer-а к серверу Tariscope, то будет выполнено подключение Observer-а к Tariscope и SQL Server-у.
Проверить результат подключения Observer можно в его журнале. Журналы работы Observer-ов, как локальных так и удаленных, ведутся в папке C:\ProgramData\Tariscope\Logs\Observer соответственно на сервере Tariscope или на удаленном сервере. Журнал называется [Название профайла].log. Для нашего примера это будет файл: CUCM.log
Этот журнал создается только после успешного подключения удаленного Observer к серверу Tariscope. Если журнал отсутствует, это означает, что соединение не произошло.
Пример журнала показан на рисунке 7.
Рисунок 7
Убедиться в подключении удаленного Observer-а к Tariscope можно также в Tariscope на странице Observer-ов (рисунок 8). Как видно из рисунка, в столбце Состояние сервиса отображается значение В сети.
Рисунок 8
Вы должны оставить открытым окно Командная строка с работающим удаленным Observer-ом. Закрытие Командной строки приведет к завершению работы Observer-а. И для повторного запуска нужно будет снова загрузить Командную строку и повторить указанные выше команды.
Для создания других удаленных Observerов нужно повторить все указанные выше действия: создать в Tariscope профайл, запустить удаленный Observer с соответствующим названием профайла.
Вы можете запустить удаленные Tariscope Observer-ы в качестве служб Windows. Для этого можно использовать, например, стороннюю программу nssm.
Для создания службы для удаленного Observer запустите программу nssm следующей командой:
nssm install TS.Observer,
где TS.Observer – название создаваемой службы. Если вы создаете несколько служб, то они должны иметь разные названия.
В результате выполнения команды появится окно, приведенное на рисунке 9.
Рисунок 9
В позиции Path введите путь к файлу Observer-а:
C:\Program files (x86)\SoftPI\Tariscope\Microservices\Tariscope.Observer.exe
В позиции Arguments введите параметры Observer: название профайла и URL сервера Tariscope. Для нашего примера это будет:
/name=CUCM /main=http://10.10.0.148:8001
Нажмите кнопку Install service. Создана соответствующая служба Windows, которую нужно запустить из Windows окна Службы (рисунок 10).
Рисунок 10
Работа со шлюзами 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. Руководство администратора.
Работа с новыми методами Tariscope АРI
Для тестирования функции Tariscope API может использоваться любая самостоятельно написанная программа или другие программы, предназначенные для этого. В этой статье использовалась программа Postman.
Для работы с Tariscope API в первую очередь следует создать соответствующего пользователя и предоставить ему права на все или отдельные методы API. Для создания API пользователя в меню Tariscope выберите Дополнительные настройки → Интеграция. Щелкните по кнопке Tariscope API. Появится соответствующая страница.
Щелкните Пользователи API. На панели инструментов щелкните значок Добавить.
Появится окно Новый API пользователь, где необходимо ввести необходимые параметры и щелкнуть Сохранить.
В списке пользователей API, выберите того, кого создали и щелкните по иконке права на методы. Появится страница Настройки прав пользователя, пример которой показан на рисунке 1.
Рисунок 1
На рисунке выделены методы, добавленные в версии Tariscope 4.6.4. Эти методы имеют следующее назначение:
- accounts.charges. Это GET метод, позволяющий получить все начисления конкретного абонента за указанный период.
- accounts.payment. Это POST метод, позволяющий занести в базу данных Tariscope информацию об оплате от абонента за предоставленные услуги связи.
- accounts.payments. Это GET метод, позволяющий получить информацию из базы данных Tariscope по оплате от конкретного абонента за заданный период.
- subscriber.create. Это POST метод, позволяющий создать нового абонента без перечня принадлежащих ему телефонных номеров. Для добавления телефонных номеров следует использовать следующий способ.
- subscriber.dnadd. Это POST метод, позволяющий добавить абоненту телефонный номер.
Работа с API Tariscope должна начинаться с авторизации АРИ пользователя в системе, которая выполняется с помощью метода api.auth.В результате выполнения этого метода вы должны получить токен, который следует применять при выполнении всех других API методов. Срок действия токена 6 часов. После чего следует получить новый токен.
1. Получение токена
Для выполнения каких-либо методов API необходимо авторизироваться в системе. Выполните метод /api/auth.
Как упоминалось выше, работа с Tariscope API методами будет показана с использованием программы Postman.
Выберите метод Post, и введите запрос для подключения к компьютеру, где установлен Tariscope (рисунок 2)
Рисунок 2
Пример запроса: http://localhost:7000/api/auth
localhost используется только в случае, когда приложение, из которого выполняется API запрос, находится на том же сервере, где находится ПО Tariscope. В других случаях используйте IP-адрес сервера Tariscope.
7000 в этом примере – это IP порт, на котором работает Tariscope. По умолчанию при установке Tariscope предлагается IP-порт 8085.
/api/auth – это метод для авторизации в системе.
Перед отправкой запроса в теле (Body) запроса следует выбрать row, задать JSON формат и ввести в этом формате имя пользователя API (username) и его пароль (password).
На вкладке Authorization вибрать Bearer token.
После этого нажать кнопку Send. Если все параметры заданы правильно, то вы получите ответ в формате JSON, откуда следует копировать токен.
Для выполнения других методов Tariscope API этот токен следует вставить на вкладке Authorization в позицию Token. Напомним еще раз, что токен действителен в течении 6 часов.
2. Получение начислений абонента
Получение начислений производится с помощью GET метода /api/accounts/charges
Параметры метода:
- id – идентификатор абонента в системе Tariscope
- fromdate – дата, начиная с которой следует получить начисление. Дата сдается в формате: гггг-мм-дд, например: 2023-05-01.
- todate – дата, заканчивая которой нужно получить начисление. Дата сдается в формате: гггг-мм-дд, например: 2023-05-31.
К примеру, нас интересуют начисления абонента с идентификатором 6169 за май 2023 года. То есть в этом случае имеем:
id = 6169, fromdate = 2023-05-01, todate = 2023-05-31. Соответственно задаем строку GET запроса: http://localhost:8085/api/accounts/charges/?id=6169&fromdate=2023-05-01&todate=2023-05-31
Пример такого запроса в Postman показан на рисунке 3. Следует не забывать, что как и в предыдущем запросе в его теле (Body) должно быть указано имя и пароль API пользователя.
Рисунок 3
Если все параметры указаны верно, Tariscope вернет информацию о начислении абонента. Список параметров по каждому начислению:
- id – идентификатор абонента в системе Tariscope;
- recdate –даты внесения начисления в Tariscope;
- fromdate – дата начала периода начисления услуги;
- todate – дата окончания периода начисления услуги;
- servicename – название услуги;
- charge – начисленная сумма;
- numberofservices – количество начисленных услуг. Для вызовов это количество секунд.
Пример ответа сервера показан на рисунке 4.
Рисунок 4
В случае, когда строка запроса указана неверно или неверно указаны параметры запроса, Tariscope выдает сообщение (message) об этом. Пример этого приведен на рисунке 5.
Рисунок 5
3. Занесение в Tariscope информации об оплате
Занесение информации об оплате от абонента производится POST запросом: /api/accounts/payment
Параметры POST запроса к системе Tariscope:
- id – идентификатор абонента в системе Tariscope;
- paymentday – дата выполнения оплаты в формате: гггг-мм-дд;
- payment – сумма платежа за услуги связи;
- paymenttype – тип платежа (не указано – 0, наличные – 1, по квитанции – 2, по счету – 3);
- bank – банк, через который производилась оплата..
Пример.
Абонент с идентификатором 6193 оплатил 17/05/2023 по счету через ПриватБанк услуги связи на сумму 370,00 грн. Это значит:
id=6193,
paymentday=2023-05-17,
payment=370.00,
paymenttype=3,
bank=ПриватБанк
То есть строка POST запроса будет следующей: http://localhost:8085/api/accounts/payment/?id=6193&paymentday=2023-05-17&payment=370.00&paymenttype=3&bank=ПриватБанк
Если параметры запроса верны, Tariscope вернет следующие данные:
- subscriberid – идентификатор абонента в системе Tariscope.
- paymentid – идентификатор записи по оплате.
- paymentday – дата выполнения оплаты в формате: гггг-мм-дд.
Пример ответа приведен на рисунке 6.
Рисунок 6
4. Получение информации об оплате от абонента за период
Получение такой информации выполняется GET запросом: /api/accounts/payments
Параметры этого запроса::
- id – идентификатор абонента в системе Tariscope.
- fromdate – дата, начиная с которой нужно получить платежи. Дата задается в формате: гггг-мм-дд, например: 2023-05-01.
- todate – дата, заканчивая которой нужно получить платежи. Дата задается в формате: гггг-мм-дд, например: 2023-05-31.
- paymentid – ідентифікатор запису по оплаті. Якщо цей ідентифікатор вказаний у запиті, то дати ігноруються, а перевіряється наявність такого запису в БД Tariscope. Якщо цей ідентифікатор = 0, то АРІ повинне повернути всі платежі за вказаний період.
Пример.
Получить информацию об оплате от абонента с идентификатором 6169 за период с 01.04.2023 по 31.05.2023. Это означает, что нужно задать следующие параметры: id=6169, fromdate=2023-04-01, todate=2023-05-31, paymenеtid=0
То есть весь GET запрос будет следующим: http://localhost:8085/api/accounts/payments/?id=6169&fromdate=2023-04-01&todate=2023-05-31&paymenеtid=0
Если все параметры указаны верно, Tariscope вернет следующие данные:
- subscriberid – идентификатор абонента в системе Tariscope.
- paymentid – идентификатор записи по оплате.
- paymentday – дата выполнения оплаты в формате: гггг-мм-дд.
- payment – сумма оплаты.
Пример результата выполнения такого запроса показан на рисунке 7.
Рисунок 7
5. Создание нового абонента
Создание нового абонента выполняется с помощью запроса POST: /api/subscriber/create
Этот запрос содержит следующие параметры:
- fullname – полное имя юридического, физического лица или сотрудника оператора связи.
- departmentid – іидентификатор группы, к которой принадлежит абонент. Если абоненты не делятся на группы, то они относятся к корневой группе, которая называется как узел связи.
- subscribertype – тип абонента: 0 -физическое лицо, 1 – юридическое лицо, 2 – служебное, 3 – бюджетное, 4 – льготное.
- connectiondate - дата, с которой абонент считается подключенным в формате: гггг-мм-дд.
- contactnumber – номер контракта с абонентом.
- contractdate - дата контракта в формате: гггг-мм-дд.
- accountnumber - номер личного счета абонента, если он создается не автоматически в Tariscope.
- personalcode – индивидуальный налоговый номер для физических лиц.
- edrpou – код ЕГРПОУ для юридических лиц.
- taxcode – налоговый код для плательщиков НДС.
- bankcode – код банка для юридических лиц..
- bankname – название банка.
- bankaccount – номер банковского счёта.
- rateplanid – идентификатор тарифного плана, назначенный абоненту.
Пример.
Создать абонента юридическое лицо с именем JSC ABC, ЕГРПОУ 55667788, ИНН 123456789 с датой подключения с 02.06.2023, с которым заключен контракт на предоставление услуг связи по номеру 247-23 от 02.06.
Эта компания обслуживается в Кредобанке, код банка 325365, счет в банке UA125438790123456. Этот абонент будет обслуживаться по тарифному плану 'Базовый', имеющему идентификатор 43 в Tariscope. Абонента включить в группу абонентов с идентификатором 419.
Абоненту назначить лицевой счет 8640-fo.
Для этих параметров необходимо выполнить следующий POST запрос:
http://localhost:8085/api/subscriber/create/?fullname=JSC
ABC&departmentid=419&subscribertype=1&connectiondate=2023-06-02&contractnumber=247-23&contractdate=2023-06-01&accountnumber=8640-fo&personalcode=&edrpou=55667788&taxcode=&bankcode=361234&bankname=Кредобанк&bankaccount=UA125438790123456&rateplanid=43
При правильно заданных параметрах Tariscope возвращает следующую информацию:
- id – идентификатор абонента в системе.
- accountnumber - номер личного счета абонента. Если он создается автоматически в Tariscope, он будет совпадать с ID.
- fullname – полное имя юридического, физического лица или сотрудника оператора связи.
Пример полученной от Tariscope информации по этому запросу, приведенный на рисунке 8.
Рисунок 8
6. Добавление абоненту телефонного номера
Для добавления абоненту телефонного номера необходимо выполнить POST запрос: /api/subscriber/dnadd
Этот запрос содержит следующие параметры::
- SubscriberId. Идентификатор абонента, которому прилагается телефонный номер.
- DN. Телефонный номер, назначаемый абоненту.
- description. Описание телефонного номера. Необязательный параметр.
- fromdate. Дата, с которой этот номер принадлежит абоненту.
- pbxid. Идентификатор АТС, в которую входит телефонный номер.
Пример.
Абоненту с идентификатором 7334 следует назначить телефонный номер 2001 с 02.06.2023. Номер принадлежит АТС с идентификатором 292.
Для этих параметров необходимо создать следующий POST запрос: http://localhost:8085/api/subscriber/dnadd/?SubscriberId=7334&DN=2001&description=&fromdate=2023-06-02&pbxid=292
Якщо параметри запиту буди вказані вірно, то Tariscope поЕсли параметры запроса будут указаны верно, то Tariscope по xid=292 вернет следующую информацию:
- id. Идентификатор телефонного номера Tariscope.
- subscriberid. Идентификатор абонента, которому прилагается телефонный номер.
- pbxid. Идентификатор АТС, в которую входит телефонный номер.
- dn. Телефонный номер.
Пример получения информации о добавлении номера показан на рисунке 9.
Рисунок 9
Подкатегории
User's guide
The category contains articles of the document "Tariscope 4.x. User's guide".
How to configure
Эта категория содержит статьи, описывающие особенности настройки и работы с Tariscope.
Telecom services
Эта категория содержит статьи, связанные с настройкой, начислением и анализом телекоммуникационных усгул связи.
User's guide_4.5.х
The category contains articles of the document "Tariscope 4.5.x. User's guide".