Элтекс

снимая трассировку через telnet, получается весьма не удобная каша.
посетила мысль написать свой велосипед.
Но, насколько я могу судить, звонки в трейсе вообще никак не помечаются... например в SI2000 трейс такой, что там звонок получает свой ID и он присутствует в каждой строчке, благодаря чему парсер легко может сформировать каждый вызов в отдельности...

так вот может я чего то не вижу и всё таки можно принадлежность строчки отнести к остальным от какого конкретного звонка?

И это реально большая проблема в диагностике. ладно если бы вызовов было 10-20 одновременно... максимум, до чего я могу сузить захват трейса на некоторых абонентах, это SS7 стык с 240 ТС и 12 DSS... одновременно занято от 150 ТС (сейчас, не говоря про час-пик утром и после обеда). И в терминал реально попадает всё такими кусками, что порой дисконекты и релизы идут подряд не понятно от каких звонков, начатых гораздо выше...



и пожалуй отследить можно только по PRI или ОКС7 адресу интерфейса, который занимается при отправках Сетапов... есть что то получше ?

---------------------------------

это является разделителем сообщений для разных вызовов?

По метке CR в Q.931 можно ориентироваться и определять что просматриваемый блок относится к тому или иному вызову?
у вас в трейсе он записывается так:

10:58:56.503556 [INFO] Q931. Line 02/01. Call 3299. Timer 'T301' (180 sec) start

Call 3299, а точнее 3299 и является CR...

для сообщений окс можно орентирвоаться по линксету+CIC для одного вызова. Для PRI - CallRef. Это параметр Call в приведенной вами строчке + в парсинге сообщения 0xYYYY

"---------" помечается конец сообщения PRI.

Так же вы можете использовать порты. В каждой строчке подписывается какому порту соответствует вывод
протокол:слот/поток:канальный_интервал

что бы по порту ориентироваться - придётся сначала лишние концы строк сначала убивать. а сообщение ISUP всё равно вместе с PRI идут в одном блоке. Поэтому наверное можно просто парсить от -{34} до следующей последовательности -{34}, выдирать оттуда CR из строчек с Q931 и добавить к предыдущему куску с таким же CR, ну или создать новый. А если найдётся два CR в блоке - это будет установка соединения в направление исходящей связи и искать дальше надо уже новый, вплоть до
UPD:

Call XXXX. State 'Null'

это просто рассуждения ) поговорить на эту тему больше не с кем)

я значит решил, что я пока бессилен. алгоритм сбора вызова не помещается в голову. всё таки в блоки между кучей "-----" могут попадать строчки с другого вызова...


можно искать MSG=SETUP или IAM, определить что он первый, а не часть транзитного выхода, цепляться за несколько сущностей (Порт, CIC, CR (который меняется с прохождением вызова, + в setup он в одном виде, далее почему то к нему прибавляется 9000 в 16-ти ричном виде (точно не помню, могу попутать, неделю назад разбирался). потом по строчно следить где будет релиз....

1) пробегать файл с сотнями тысяч строчек надо будет много раз, потому что вызовы могут быть с двумя сетапами, с двумя IAM, или и с тем и другим...
2) надо придумать что делать и как детектить вызовы, которые закончились внутренними ошибками станции (например нет ТГ на порту или что то с это роде, когда даже релиз комплит не отсылается)
3) весь файл распарсить не получится, потому что в трейс одного вызова может вклиниться строчка без порта и других отличительных признаков... дампы - самое популярное из таких случаев.


Неужели разработчики не задумывались о написание парсера трейсов? Ведь для этого достаточно как то упорядочить вывод трейса или снабдить каждую строчку ID вызова?