Пример разработки шаблонов для сети с коммутатором AVAYA

 

Анализ телефонной сети и общие рекомендации

 

Во-первых. Ознакомьтесь с документацией на АТС в части сбора и обработки CDR.

Во-вторых, ознакомьтесь с документом «Комплекс программ  TarifSV» (раздел II.7). В нем содержится информация о таблицах, содержащих данные о шаблонах (правилах конвертации) используемых при работе TSVlog.exe.

Основы использования шаблонов изложены в документе «О программе TSVlog». Обязательно ознакомьтесь с указанным документом перед работой по созданию шаблонов для конкретной телефонной сети.

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

 

В качестве примера рассмотрим фрагмент реальной  корпоративной сети (сети оператора местной связи), построенной на коммутаторе AVAYA(рис. 6).

 

 

Фрагмент корпоративной телефонной сети (сети оператора местной связи).

 

Рис. 6.

 

Исследуемую сеть телефонной связи можно условно разделить на две части: внутреннюю и внешнюю (граница раздела показана штрих-пунктиром).

Все вызовы, пересекшие указанную границу, будем называть внешними (входящими, если они исходят от оператора связи, и  исходящими, в противном случае). Остальные вызовы относятся к внутренним.

 

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

 

Рассматриваемая сеть относительно простая.

В Компании 2 офиса. Основная внутренняя нумерация следующая:

 

·        в офисе 1 – 17ХХ, 18ХХ, 19ХХ.

·        в офисе 2 – 1ХХХ, 2ХХХХ, 3ХХХ, 5ХХХ.

 

Кроме этого, в каждом из офисов есть внешние номера (семи и/или десятизначные).

 

 

На них могут поступать как внешние, так и внутренние вызовы. Например, на номер 6462801 (в Офисе 2) могут позвонить как «из города» (от Оператора 2), так и любой внутренний абонент компании (без выхода на оператора связи).

 

В первом из них («Офис 1») установлен коммутатор типа AVAYA. Именно на нем предполагается организовать сбор и обработку тарификационных данных.

Этот коммутатор связан несколькими маршрутами (пучками соединительных линий - СЛ) с другими коммутаторами, расположенными в офисах 2 и 3, а также у операторов связи:

·        7004 – к оператору связи «Оператор 1» (входящие и исходящие внешние вызовы). Пучок равнозначных СЛ;

·        7007 – к подразделению компании «Офис 2» (входящие и исходящие внешние и внутренние вызовы) . Пучок равнозначных СЛ. При этом, внешними входящими считаются только те вызовы, которые приходят на семизначные номера Офиса 1.

Все исходящие внешние вызовы из Компании осуществляются посредством набора кода доступа выхода «на город» -  «9».


 

Порядок составления шаблонов поясним на примерах обработки CDR от АТС AVAYA.

 

Здесь, в примере,  используется формат CDR AVAYA TSV106, описанный в документе «AVAYA CDR SYSTEM PARAMETERS.doc».

 

Примечание. В настоящее время в TSVlog_25 допустимым является так же формат UNFORMATTED, являющийся одним из стандартных в AVAYA. Однако, имеющееся в нем ограничение по точности определения длительности вызовов (6 сек), а также отсутствие поля vdn могут, в отдельных случаях, существенно ухудшить качество идентификации некоторых входящих и транзитных вызовов. Поэтому, предпочтительнее для AVAYA / DEFINITY использовать формат CDR AVAYA TSV106.

В любом случае, общий алгоритм преобразований с помощью шаблонов не зависит от используемого формата CDR.

 

Поля формата TSV106 не вполне соответствуют полям, используемым в TarifSV (см. "О программе TSVlog"). Поэтому, первоначально программой TSVlog осуществляется приведение значений в этих полях к унифицированной форме. Алгоритм такого преобразования приведен в Приложении 1.

 

В комплексе TarifSV принято обозначать тип вызова в поле DIGITS1 (DIGITS2) выходных (итоговых) таблиц с помощью специальных символов - маркеров. Все вызовы (внутренние, внешние и транзитные) приводятся к 4 основным типам :

 

Значения маркеров  в поле DIGITS, используемых программой TSVlog, и соответствующие им типы вызовов

 

Маркер

Тип вызова

Значение поля DIGITS1 (DIGITS2)  в итоговой таблице

Примечание

+

Внешний входящий.

а)Идентификатор вызываемого ресурса

б)Вызываемый номер

в)АОН (CLID1) вызывающего абонента

а)Присваивается пользователем при модификации с помощью шаблонов поля DNIS (DIGITS1)

б)Может включать номер (код доступа) маршрута

-

Внешний исходящий.

Набранный номер

а)Присваивается пользователем при модификации с помощью шаблонов поля DIGITS2

б)Может включать номер (код доступа) маршрута

A

Внутренний исходящий.

Набранный номер (или идентификатор вызываемого ресурса)

Может включать номер (код доступа) маршрута.

Присваивается автоматически программой TSVlog

B

Внутренний входящий.

Идентификатор вызывающего ресурса

Может включать номер (код доступа) маршрута.

Присваивается автоматически программой TSVlog

 

Обращаю ваше внимание на то, что вызов автоматически считается внутренним (и программа сама проставит соответствующие маркеры «А» или «В»), если пользователь не определил иное (не пометил этот вызов с помощью шаблонов как внешний, -  входящий или исходящий).

 

Таким образом, применительно к нашему случаю (рис. 6), необходимо все вызовы, приходящие с маршрута 7004 пометить маркерами «+», а исходящие в него вызовы – маркером «-».

С маршрута (или в него) 7007 могут поступать как внутренние, так и внешние вызовы.

В таких случаях внутренними вызовами будем считать те из них, которые начались и закончились внутри Компании. Например, абонент 17ХХ инициировал вызов абоненту 5ХХХ.

В то же время, на абонента 17ХХ может придти внешний входящий вызов от Оператора 2 (через коммутатор в Офисе 2). Такой вызов необходимо будет идентифицировать именно как внешний входящий, соответственно пометив его маркером «+». Или, например, абонент 1700 может инициировать вызов, который будет перенаправлен Оператору 2 через Офис 2. Такой вызов следует идентифицировать в качестве внешнего исходящего с соответствующей маркировкой.

 

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

 

Итак, приступим к составлению (разработке шаблонов) с использованием программы TarifSV (пункт «Конвертация log-файла» основного меню TarifSV.exe).

Предварительно обязательно очистили все шаблоны (удалили все записи из всех таблиц).

 

Примеры внешних входящих вызовов.

 

Пример 1.  Входящий внешний вызов с маршрута 7007 (соединительная линия 001) с АОНом 989060585519 на номер 4019281. К этому вызову относятся  две записи (типы G и 9). Первым отбился абонент 4019281:

 

30.03.2012  11:50:38

300312 1150 00002 7007001            989060585519                 4019281 G         0                  

 

30.03.2012  11:52:27

300312 1152 00149 7007001            989060585519                 4019281 9         1                  

 

В ходе прогона программой TSVlog.exe осуществляется слияние (совместная обработка) CDR, относящихся к одному вызову. Сам алгоритм достаточно сложен и здесь не приводится. Хочу лишь отметить, что, при необходимости, можно детализировать выходную информацию, о чем будет сказано ниже.

После прогона файла с этими записями и пустыми шаблонами в итоговом файле получим следующие две записи под номером 183 (поле NUMB) , которым соответствуют записи №№ 367 и 375 в файле 20120330.LOG (поле STRNUMBER) :

 

NUMB

DT_START

DURWAIT

IDURATION

RESOURCE

DIGITS

RECTYPE

CLID

CODE

STRNUMBER

183

30.03.2012 11:50:36

2

109

T7007001

A4019281

G

989060585519

0

20120330.LOG |               367

183

30.03.2012 11:50:36

2

109

4019281

BT7007001

9

989060585519

1

20120330.LOG |               375

 

Здесь в поле DT_START указанно, что вызов начался  30.03.2012 в 11:50:36.

Началу разговора предшествовало 2 сек ожидание ответа абонента (поле DURWAIT). Сам разговор продолжался в течение 109 сек (поле IDURATION).

Вызов пришел с рерурса T7007001 (первая запись в поле RESOURCE) и завершился на ресурсе 4019281 (вторая запись).

В поле DIGITS в первой записи указанно, что это – исходящий внутренний вызов (маркер «А») на ресурс 4019281, а во второй – входящий внутренний вызов (маркер «В») с ресурса T7007001.

В обеих записях изменились поля DIGITS. Это связанно с применением  специальных правил (алгоритма) обработки внешних входящих вызовов.

 

 

 

Необходимое замечание по содержанию других полей (применительно к коммутаторам AVAYA CM  /  DEFINITY).

 

В поле RECTYPE выдается информация, соответствующая параметру "Код состояния" (cond-code) в CDR от DEFINITY (AVAYA):

 

Возможные коды состояния и их значения:

 

0           Внутрикоммутаторный вызов, т.е. вызов, инициатор и адресат которого находятся в пределах коммутатора.

7 (или А)        Исходящий вызов из коммутатора

9          Обозначает:

                     входящий вызов на  коммутатор;

                      транзитный вызов;

G         Входящий вызов с ожиданием ответа

C         Конференция

H         Неотвеченный вызов (не дождались ответа)

I          Вызов занятого адресата

E и F   Прочее неудачное соединение

4          Очень длинный (продолжительностью более 10 часов) вызов.

 

 

В поле CODE помещается информация о том, кто первым отбился (по чьей инициативе завершен вызов).

Для правильного отображения этой информации в поле “frl CDR, установите   на стр. 1 CDR SYSTEM PARAMETERS (команда change system-parameters cdr в AVAYA) параметр   Disconnect Information in Place of FRL? Y

Тогда возможные значения в поле CODE:

0 – отбой внутри коммутатора;

1 – отбой внешнего вызова со стороны коммутатора;

2 - отбой внешнего вызова с удаленной стороны.

 

 

Для того, чтобы указать программе, что это все-таки внешний вызов, мы должны внести изменения в соответствующие шаблоны. Учтем также то обстоятельство, что соединительные линии в маршрутах 7004 и 7007 равнозначны, и поэтому, с целью уменьшения объема базы данных телефонии, не будем учитывать номер СЛ в идентификаторе этих маршрутов.

 

На заметку. Если у вас маршрут из СО линий, то, как правило, каждой СЛ соответствует свой уникальный «городской» номер. Его-то и можно использовать в качестве идентификатора СЛ. Например, заменив для входящих и исходящих вызовов T7007001 на  Т4019281.

 

Запустим программу TarifSV_25  выберем пункт меню «Конвертация log-файла».

Затем «уберем» номера СЛ из полей ORIGID  и TERID с помощью соответствующих шаблонов:

 

шаблон 1.Замена ORIGID:

 

Модифицируем ORIGID

 

Исходное значение

Заменить на:

T7!!!%

T7!!!

 

Заодно изменим (для исходящих внешних вызовов в те же маршруты) и шаблон 6.Замена TERID:

 

Модифицируем TERID

 

Исходное значение

Заменить на:

T7!!!%

T7!!!

 

После этого, нам нужно определить, что все вызовы с маршрута T7004 являются внешними входящими. А с маршрута  T7007 внешними будут только те вызовы, которые в поле DIGITS1 будут иметь семь цифр. С этой целью изменяем шаблон 5. DIGITS1:

 

ORIGID

Поле DIGITS1

 

Детализация стороны "В":

 

Исходное значение

Заменить на:

 

T7004

%

+%

 

T7007

!!!!!!!

+!!!!!!!

 

 

Здесь мы указали, что для любого вызова с маршрута T7004 к значению в поле DIGITS1 добавляем маркер «+». То же самое делаем и для маршрута Т7007, однако, только для тех вызовов, у которых в поле DIGITS1 ровно 7 знаков. Остальные вызовы с этого маршрута будут считаться внутрисетевыми. Детализации вызова не требуется

 

Запустим снова TSVlog.exe и прогоним тот же файл. Получили модифицированные записи этого же вызова:

 

NUMB

DT_START

DURWAIT

IDURATION

RESOURCE

DIGITS

RECTYPE

CLID

CODE

STRNUMBER

183

30.03.2012 11:50:36

2

109

T7007

+4019281

G

989060585519

0

20120330.LOG |               367

183

30.03.2012 11:50:36

2

109

4019281

+4019281

9

989060585519

1

20120330.LOG |               375

 

Это уже значительно ближе к истине. 

Поскольку мы использовали достаточно общие маски при модификации шаблонов, то видим, что и другие вызовы с маршрутов T7004 и T7007 стали идентифицироваться как  внешние входящие, если они удовлетворяют соответствующим шаблонам.

 

Пример2.

 

Например, такой внешний входящий  вызов (три CDR) на номер 3803980:

 

30.03.2012  11:55:06

300312 1155 00001 7007001            984957218450                 3803980 G 3803980 0                  

30.03.2012  11:55:26

300312 1155 00020 7007001            984957218450                 3803980 9 3803980 0                  

30.03.2012  11:58:56

300312 1158 00330 7007001            984957218450                    1990 9 3803980 2                  

 

Здесь в 11:55:05 пришел вызов на номер 3803980. После секундного ожидания ответа он был переведен на автоматического оператора, после чего, через 20 секунд произошло соединение с абонентом 1990. Суммарная длительность вызова – 230 сек.

 

Он транслируется в две записи:

 

NUMB

DT_START

DURWAIT

IDURATION

RESOURCE

DIGITS

RECTYPE

CLID

CODE

STRNUMBER

190

30.03.2012 11:55:05

1

230

T7007

+3803980

G

984957218450

0

20120330.LOG |               381

190

30.03.2012 11:55:05

1

230

3803980

+3803980

9

984957218450

2

20120330.LOG |               385

 

 

 

Посмотрим, что изменилось в полях итоговых записей.

В первой записи изменилось значение в поле RESOURCE T7007001 на  T7007). Здесь «поработал» шаблон модификации ORIGID.

 

В обеих записях изменились поля DIGITS. Это связанно с применением  специальных правил (алгоритма) обработки внешних входящих вызовов.

 

 

Вернемся к шаблону 5. DIGITS1. А именно, рассмотрим, что дает постановка «галочки»  в поле «Детализация стороны “B».

Это значение устанавливается, как правило, в случае, если нам действительно нужна детализация внешних входящих вызовов на конкретный номер.

(В принципе, можно поставить эту «галочку» и для любого номера, приходящего с маршрута. Однако, это может привести к неоправданному увеличению размера выходных файлов).

Для примера, мы ставим этот признак для номера 3803980, на который приходят вызовы с маршрута Т7007:

 

шаблон 5. DIGITS1:

 

ORIGID

Поле DIGITS1

 

Детализация стороны "В":

 

Исходное значение

Заменить на:

 

T7004

%

+%

 

T7007

!!!!!!!

+!!!!!!!

 

T7007

3803980

+3803980

V

 

 

Еще раз прогоним исходный файл. Получим:

 

NUMB

DT_START

DURWAIT

IDURATION

RESOURCE

DIGITS

RECTYPE

CLID

CODE

STRNUMBER

190

30.03.2012 11:55:05

1

230

T7007

+3803980

G

984957218450

0

20120330.LOG |               381

190

30.03.2012 11:55:05

1

0

3803980

+3803980

G

984957218450

0

20120330.LOG |               381

190

30.03.2012 11:55:06

0

20

3803980

+3803980

9

984957218450

0

20120330.LOG |               383

190

30.03.2012 11:55:26

0

210

1990

+3803980

9

984957218450

2

20120330.LOG |               385

 

Теперь мы имеем четыре строки.

Первая осталась неизменной. . Эта строка в дальнейшем будет использована при тарификации вызовов от оператора связи.

Вторая разбилась на три.

Эти строки содержат детальную информацию о том, как распределялся этот входящий вызов внутри нашей сети.

Сначала следует запись о приходе внешнего входящего вызова (ожидание ответа в течение 1 сек) на ресурс 3803980 (набранный номер +3803980).

Потом идет информация о соединении вызова с ресурсом 3803980 на 20 сек.

Наконец, в четвертой записи  идет информация о соединении вызова с ресурсом 1990 (собственно разговор с абонентом в течение 210 сек).

 

В принципе, с входящими внешними вызовами мы разобрались.

Однако, осталась небольшая проблема: АОН (CLID1) включает в себя первую ненужную «9». Ее подставляет АТС (так запрограммировано в ней) с целью быстрого набора пользователем неотвеченного (пропущенного) вызова. Кроме того, нужно учесть, что в некоторых случаях внешний АОН может не определяться.

Устраним эту проблему с помощью:

 

шаблон 3. Замена CLID1:

 

Значение поля ORIGID

Поле CLID1

 

 

Исходное значение

Заменить на:

%

9

undefined

%

9!!!!!!!%

!!!!!!!%

 

 

В колонке «Значение поля ORIGID»  мы указали, для каких значений действуют правила, изложенные в колонках 2 и 3.

 

К сведению. Программой TSVlog все шаблоны просматриваются «слева-направо»  и «снизу – вверх».  Т.е., сначала «снизу-вверх» ищется совпадение по первой колонке, затем (в случае совпадения), осуществляется переход в этой же строке к следующей колонке. И т.д.. Если совпадения по какой-либо колонке нет, то осуществляется переход в строке, находящейся выше.  И процесс повторяется.

 

При составлении этих правил мы предполагали, что «из города» с любых маршрутов  могут приходить АОНы длиной не менее 7 символов. 

 

Поскольку в отношении АОНов для внешних входящих маршруты Т7004 и Т7007 идентичны, мы в первой колонке поставили «%». В противном случае пришлось бы аккуратно расписать каждый маршрут.

Нижняя строка в этом шаблоне позволяет преобразовать АОН, начинающийся на «9» и имеющий длину не менее 7 символов. Из таких АОНов мы убираем лидирующую «9».

Для отсутствующих АОНов ( т.е., если АОН = «9» и фактически  его нет), подставляем “undefined” (можете подставить любое свое значение).

 

Аналогичный шаблон подготовим и для  8. Замена CLID2.

 

Прогоним еще разок тот же файл:

 

NUMB

DT_START

DURWAIT

IDURATION

RESOURCE

DIGITS

RECTYPE

CLID

CODE

STRNUMBER

190

30.03.2012 11:55:05

1

230

T7007

+3803980

G

84957218450

0

20120330.LOG |               381

190

30.03.2012 11:55:05

1

0

3803980

+3803980

G

84957218450

0

20120330.LOG |               381

190

30.03.2012 11:55:06

0

20

3803980

+3803980

9

84957218450

0

20120330.LOG |               383

190

30.03.2012 11:55:26

0

210

1990

+3803980

9

84957218450

2

20120330.LOG |               385

 

Как видим, во всех строках  в поле CLID исчезла лидирующая «9».

 

А вот примерно так этот вызов будет отражен в итоговом выходном файле после его прогона с помощью TarifSV (фрагмент):

 

 

№ записи

Старт

Время ожидания, сек

Длит., сек

Ресурс

Номер

Тип записи

АОН (CLID)

Код завершения

Абонент

 

 

Тип вызова

Куда (откуда)

 

 

 

 

 

 

 

 

 

 

ID абонента

Договор

Тип абонента

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Назначение

Регион

190

30.03.2012 11:55:05

1

230

T7007

3803980

G

84957218450

0

   2/   2

 

Оператор связи

Местн(вх)

from: ГОРОД

МОСКВА

190

30.03.2012 11:55:05

1

0

3803980

3803980

G

84957218450

0

   1/   1

 

Офисный

Местн(вх)

from: ГОРОД

МОСКВА

190

30.03.2012 11:55:06

0

20

3803980

3803980

9

84957218450

0

   1/   1

 

Офисный

Местн(вх)

from: ГОРОД

МОСКВА

190

30.03.2012 11:55:26

0

210

1990

3803980

9

84957218450

2

   1/   1

 

Офисный

Местн(вх)

from: ГОРОД

МОСКВА

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Внешние исходящие вызовы.

 

Пример 3. Исходящий внешний вызов на номер 89166338859 от абонента с АОНом 1737 через маршрут 7007 (СЛ № 003):

 

 

30.03.2012  08:33:28

300312 0833 00026         7007003            1737            989166338859 7         2    9              

 

После прогона (с учетом ранее созданного шаблона 6.Замена TERID):

 

NUMB

DT_START

DURWAIT

IDURATION

RESOURCE

DIGITS

RECTYPE

CLID

CODE

STRNUMBER

7

30.03.2012 08:33:02

0

26

1737

A989166338859

7

1737

2

20120330.LOG |                15

7

30.03.2012 08:33:02

0

26

T7007

B1737

7

1737

2

20120330.LOG |                15

 

 

Видим, что вызов идентифицирован, как внутренний.

Чтобы показать, что он внешний, необходимо скорректировать поле DIGITS2.

Т.е. внешние исходящие вызовы пометить маркером «-».

Используем соответствующий шаблон.

 

шаблон 10. DIGITS2:

 

Значение поля TERID

Поле DIGITS2

 

 

Исходное значение

Заменить на:

T7004

%

-%

T7007

9%

-%

 

Поскольку маршрут Т7004 – выход на оператора связи, то все вызовы, направленные на него, считаем исходящими внешними. И в первой строке шаблона пишем: при условии, что поле TERID = Т7004, любая  последовательность символов в поле DIGITS2 («%») должна быть дополнена маркером «-» («-%»).

 

С маршрутом Т7007 не совсем так же, поскольку туда могут исходить и внутрисетевые вызовы, например – на номера 3ХХХ. Однако, из описания сети нам известно, что выход «в город» через Офис 2 посредством набора «9». Т.е., если в направлении TERID = Т7007 ушел номер с первой цифрой «9», то это – внешний исходящий вызов. Об этом и гласит вторая строка в шаблоне.

 

После прогона получаем:

 

NUMB

DT_START

DURWAIT

IDURATION

RESOURCE

DIGITS

RECTYPE

CLID

CODE

STRNUMBER

7

30.03.2012 08:33:02

0

26

1737

-89166338859

7

1737

2

20120330.LOG |                15

7

30.03.2012 08:33:02

0

26

T7007

-89166338859

7

1737

2

20120330.LOG |                15

 

 

Теперь все правильно:  вызов через маршрут T7007 идентифицирован, как внешний исходящий (маркер «-»).

 

А в итоговом файле такой вызов выглядит примерно так (фрагмент записи):

 

 

№ записи

Старт

Время ожидания, сек

Длит., сек

Ресурс

Номер

Тип записи

АОН (CLID)

Код завершения

Абонент

 

 

Тип вызова

Куда (откуда)

 

 

 

 

 

 

 

 

 

 

ID абонента

Договор

Тип абонента

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Назначение

Регион

7

30.03.2012 08:33:02

0

26

1737

89166338859

7

1737

2

   1/   1

 

Офисный

Вн.зон

МОСКВА (MOB) - МТС

МОСКОВСКИЕ МОБИЛЬНЫЕ СЕТИ

7

30.03.2012 08:33:02

0

26

T7007

89166338859

7

1737

2

   2/   2

 

Оператор связи

Вн.зон

МОСКВА (MOB) - МТС

МОСКОВСКИЕ МОБИЛЬНЫЕ СЕТИ

 

 

Т.о., с внешними вызовами, прошедшими через маршруты 7004 и 7007 разобрались.

 

В принципе, если бы у нас был только один Офис1, то можно было бы и закончить рассмотрение примеров составления шаблонов. Ведь все остальное (идентификация внутренних вызовов) TSVlog сделает автоматически.

 

Внутрисетевые вызовы.

Однако, у нас более сложный случай.

Маршрут 7007 связывает Офис 1 и Офис 2. Через него идут как внутрисетевые (с номеров 1ХХХ, 2ХХХХ, 3ХХХ, 5ХХХ), так и внешние вызовы транзитом с/на внешнего оператора связи Оператор 2.

И придется по АОНу и по набранному номеру определять, является входящий вызов внутренним или внешним.

 

В Офисе 2 основная нумерация, как мы помним, 1ХХХ, 2ХХХХ, 3ХХХ, 5ХХХ.

Т.о., для вызовов с/на  маршрута Т7007 будем считать:

- если вызов пришел с АОНом 1!!!, 2!!!!, 3!!! или 5!!!, то это – внутренний входящий вызов;

- если вызов исходит в маршрут Т7007 и набранный номер соответствует маскам 1!!!, 2!!!!, 3!!! или 5!!!, то это – внутрисетевой вызов.

 

Переходим к доработке шаблонов.

 

Сначала разберемся с внутренними входящими в Офис 1 вызовами из маршрута 7007 , для чего обратимся к  шаблону 4. Слияние CLID1 и ORIGID:

 

Значение поля ORIGID

Значение поля CLID1

Новое значение поля ORIGID

T7007

1!!!

1XXX

T7007

2!!!!

2XXXX

T7007

3!!!

3XXX

T7007

5!!!

5XXX

 

Здесь мы заменяем поле ORIGID со значением, соответствующем маске T7007, на значение, равное полю «Новое значение поля ORIGID» в случае, если значение CLID1 вызова соответствует маске из поля «Значение поля CLID1». Таким образом, например, мы ORIGID = T7007 заменим на 5ХХX, если CLID1 = 5001. Точно также поступим и в остальных случаях.

Что это нам дает?

Во-первых, теперь мы знаем, что, если после данного преобразования у нас появляется, например, ORIGID = T7007, то можно смело относить данный вызов к внешнему входящему с маршрута T7007 (или транзитному, если далее вызов пошел на внешнего оператора связи). Во-вторых, мы в поле ORIGID поместили идентификаторы, соответствующие внутренней номерной емкости.

 

Проделаем аналогичную операцию и с исходящими вызовами из Офиса 1 на внутренние номера в Офисе 2 с помощью шаблона 7. Префикс В:

 

Значение поля TERID

Префикс В (вызываемого абонента) в поле DIGITS2

Новое значение поля TERID

T7007

1!!!

1XXX

T7007

2!!!!

2XXXX

T7007

3!!!

3XXX

T7007

5!!!

5XXX

 

Здесь мы заменяем поле TERID со значением, соответствующем маске T7007, на значение, равное полю «Новое значение поля TERID» в случае, если значение DIGITS2 вызова соответствует маске из поля «Префикс В (вызываемого абонента) в поле DIGITS2». Таким образом, например, мы TERID = T7007 заменим на 5XXX, если DIGITS2 = 5001. Точно также поступим и в остальных случаях.

Что это нам дает?

Во-первых, теперь мы знаем, что, если после данного преобразования у нас появляется, например, TERID = T7007, то можно смело относить данный вызов к внешнему исходящему в маршрут T7007. Во-вторых, мы в поле TERID поместили идентификаторы, соответствующие внутренней номерной емкости.

 

Примечание. Если вы хотите иметь в единой БДТ всю нумерационную емкость сети, то в шаблонах 4 и 7 символ «Х» замените на «!».

 

Итак, с помощью всего лишь двух коротких шаблонов мы решили задачу по идентификации типа вызовов на маршруте 7007.

 

Проиллюстрируем это на нескольких вызовах.

 

Пример 4а. Внутренний вызов абонентом 1713 абонента 1133 через маршрут 7007:

 

30.03.2012  11:51:32

300312 1151 00250         7007026            1713                    1133 7         1                      

 

После преобразования в TSVlog, получим:

 

NUMB

DT_START

DURWAIT

IDURATION

RESOURCE

DIGITS

RECTYPE

CLID

CODE

STRNUMBER

185

30.03.2012 11:48:42

0

170

1713

A1133

7

1713

1

20120330.LOG |               371

185

30.03.2012 11:48:42

0

170

1XXX

B1713

7

1713

1

20120330.LOG |               371

 

А, после прогона с помощью TarifSV:

 

№ записи

Старт

Время ожидания, сек

Длит., сек

Ресурс

Номер

Тип записи

АОН (CLID)

Код завершения

Абонент

 

 

Тип вызова

Куда (откуда)

 

 

 

 

 

 

 

 

 

 

ID абонента

Договор

Тип абонента

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Назначение

Регион

185

30.03.2012 11:48:42

0

170

1713

1133

7

1713

1

   1/   1

 

Офисный

Внутр.

to: Офис 2

Компания

185

30.03.2012 11:48:42

0

170

1XXX

1713

7

1713

1

   1/   2

 

Офисный

Внутр.

from: Офис 1

Компания

 

 

Пример 4б. Внутрисетевой вызов с маршрута 7007 абонентом 3633 номера 1802, оставшийся без ответа (код завершения «Н»).

 

30.03.2012  12:19:26

300312 1219 00017 7007001                    3633                    1802 H         1                  

 

После преобразования в TSVlog, получим:

 

NUMB

DT_START

DURWAIT

IDURATION

RESOURCE

DIGITS

RECTYPE

CLID

CODE

STRNUMBER

209

30.03.2012 12:19:09

17

0

3XXX

A1802

H

3633

1

20120330.LOG |               419

209

30.03.2012 12:19:09

17

0

1802

B3XXX

H

3633

1

20120330.LOG |               419

 

После прогона с помощью TarifSV:

 

№ записи

Старт

Время ожидания, сек

Длит., сек

Ресурс

Номер

Тип записи

АОН (CLID)

Код завершения

Абонент

 

 

Тип вызова

Куда (откуда)

 

 

 

 

 

 

 

 

 

 

ID абонента

Договор

Тип абонента

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Назначение

Регион

209

30.03.2012 12:19:09

17

0

3XXX

1802

H

3633

1

   1/   2

 

Офисный

Внутр.

to: Офис 1

Компания

209

30.03.2012 12:19:09

17

0

1802

3XXX

H

3633

1

   1/   1

 

Офисный

Внутр.

from: Офис 2

Компания

 

 

 

Казалось бы, теперь все. Однако, это не совсем верно.

Дело в том, что абоненты Офиса 2 могут переадресовывать внешние входящие вызовы, которые поступили к ним, на абонентов Офиса 1. В этом случае АОН вызова не будет из диапазона 1ХХХ, 2ХХХХ, 3ХХХ, 5ХХХ. Да и вызов, фактически, является внешним входящим для абонента Офиса 1.

 

Пример 5. Внешний входящий вызов на номер 1804 с маршрута 7007. АОН = 984959255470:

 

30.03.2012  11:11:51

300312 1111 00001 7007002            984959255470                    1804 G         0

30.03.2012  11:13:29

300312 1113 00138 7007002            984959255470                    1804 9         1     

 

После преобразования в TSVlog, получим:

 

NUMB

DT_START

DURWAIT

IDURATION

RESOURCE

DIGITS

RECTYPE

CLID

CODE

STRNUMBER

154

30.03.2012 11:11:50

1

98

T7007

A1804

G

84959255470

0

20120330.LOG |               309

154

30.03.2012 11:11:50

1

98

1804

BT7007

9

84959255470

1

20120330.LOG |               315

 

Для того, чтобы правильно определить этот вызов, как внешний входящий, придется вернуться к шаблону 5. DIGITS1.

 

Здесь мы определили, что входящими вызовами с маршрута Т7007 могут быть вызовы только на семизначные номера:

 

ORIGID

Поле DIGITS1

 

Детализация стороны "В":

 

Исходное значение

Заменить на:

 

T7004

%

+%

 

T7007

!!!!!!!

+!!!!!!!

 

T7007

3803980

+3803980

V

 

Воспользуемся тем, что шаблон   4. Слияние CLID1 и ORIGID применяется до шаблона 5. DIGITS1. А с помощью последнего мы уже заменили, где надо, Т7007 на 1ХХХ, 2ХХХХ, 3ХХХ или 5ХХХ.

Теперь мы снимаем ограничение,  что входящими вызовами с маршрута Т7007 могут быть вызовы только на семизначные номера:

 

ORIGID

Поле DIGITS1

 

Детализация стороны "В":

 

Исходное значение

Заменить на:

 

T7004

%

+%

 

T7007

%

+%

 

T7007

3803980

+3803980

V

 

После преобразования в TSVlog, получим:

 

NUMB

DT_START

DURWAIT

IDURATION

RESOURCE

DIGITS

RECTYPE

CLID

CODE

STRNUMBER

154

30.03.2012 11:11:50

1

98

T7007

+1804

G

84959255470

0

20120330.LOG |               309

154

30.03.2012 11:11:50

1

98

1804

+1804

9

84959255470

1

20120330.LOG |               315

 

Видим, что этот (и подобные ему) вызов стал внешним входящим (маркер «+») .

 

После прогона с помощью TarifSV окончательно получим:

 

№ записи

Старт

Время ожидания, сек

Длит., сек

Ресурс

Номер

Тип записи

АОН (CLID)

Код завершения

Абонент

 

 

Тип вызова

Куда (откуда)

 

 

 

 

 

 

 

 

 

 

ID абонента

Договор

Тип абонента

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Назначение

Регион

154

30.03.2012 11:11:50

1

98

T7007

1804

G

84959255470

0

   2/   2

 

Оператор связи

Местн(вх)

from: ГОРОД

МОСКВА

154

30.03.2012 11:11:50

1

98

1804

1804

9

84959255470

1

   1/   1

 

Офисный

Местн(вх)

from: ГОРОД

МОСКВА

 

Вот теперь, пожалуй, всё.

 

Таким образом, программа TSVlog позволяет с помощью довольно простых шаблонов конвертировать информацию о вызовах из CDR в унифицированную табличную форму.

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