Пример разработки шаблонов для сети с коммутатором 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 в унифицированную табличную форму.
При этом, мы старались использовать наиболее общие шаблоны, которые будут действовать в подавляющем большинстве случаев для нашей сети.