снимая трассировку через telnet, получается весьма не удобная каша.
посетила мысль написать свой велосипед.
Но, насколько я могу судить, звонки в трейсе вообще никак не помечаются... например в SI2000 трейс такой, что там звонок получает свой ID и он присутствует в каждой строчке, благодаря чему парсер легко может сформировать каждый вызов в отдельности...
так вот может я чего то не вижу и всё таки можно принадлежность строчки отнести к остальным от какого конкретного звонка?
О деактивации форума Eltex
Уважаемые коллеги! В связи с потерей актуальности данного ресурса, нами было принято решение о частичной деактивации форума Eltex. Мы отключили функции регистрации и создания новых тем, а также возможность оставлять сообщения. Форум продолжит работу в "режиме чтения", так как за долгие годы работы здесь накопилось много полезной информации и ответов на часто встречающиеся вопросы.
Мы активно развиваем другие каналы коммуникаций, которые позволяют более оперативно и адресно консультировать наших клиентов. Если у вас возникли вопросы по работе оборудования, вы можете обратиться в техническую поддержку Eltex, воспользовавшись формой обращения на сайте компании или оставить заявку в системе Service Desk. По иным вопросам проконсультируют наши менеджеры коммерческого отдела: eltex@eltex-co.ru.
Уважаемые коллеги! В связи с потерей актуальности данного ресурса, нами было принято решение о частичной деактивации форума Eltex. Мы отключили функции регистрации и создания новых тем, а также возможность оставлять сообщения. Форум продолжит работу в "режиме чтения", так как за долгие годы работы здесь накопилось много полезной информации и ответов на часто встречающиеся вопросы.
Мы активно развиваем другие каналы коммуникаций, которые позволяют более оперативно и адресно консультировать наших клиентов. Если у вас возникли вопросы по работе оборудования, вы можете обратиться в техническую поддержку Eltex, воспользовавшись формой обращения на сайте компании или оставить заявку в системе Service Desk. По иным вопросам проконсультируют наши менеджеры коммерческого отдела: eltex@eltex-co.ru.
парсер трейса или как отследить вызов
Re: парсер трейса или как отследить вызов
И это реально большая проблема в диагностике. ладно если бы вызовов было 10-20 одновременно... максимум, до чего я могу сузить захват трейса на некоторых абонентах, это SS7 стык с 240 ТС и 12 DSS... одновременно занято от 150 ТС (сейчас, не говоря про час-пик утром и после обеда). И в терминал реально попадает всё такими кусками, что порой дисконекты и релизы идут подряд не понятно от каких звонков, начатых гораздо выше...
и пожалуй отследить можно только по PRI или ОКС7 адресу интерфейса, который занимается при отправках Сетапов... есть что то получше ?
и пожалуй отследить можно только по PRI или ОКС7 адресу интерфейса, который занимается при отправках Сетапов... есть что то получше ?
Re: парсер трейса или как отследить вызов
---------------------------------
это является разделителем сообщений для разных вызовов?
По метке CR в Q.931 можно ориентироваться и определять что просматриваемый блок относится к тому или иному вызову?
у вас в трейсе он записывается так:
10:58:56.503556 [INFO] Q931. Line 02/01. Call 3299. Timer 'T301' (180 sec) start
Call 3299, а точнее 3299 и является CR...
Re: парсер трейса или как отследить вызов
для сообщений окс можно орентирвоаться по линксету+CIC для одного вызова. Для PRI - CallRef. Это параметр Call в приведенной вами строчке + в парсинге сообщения 0xYYYY
"---------" помечается конец сообщения PRI.
Так же вы можете использовать порты. В каждой строчке подписывается какому порту соответствует вывод
протокол:слот/поток:канальный_интервал
"---------" помечается конец сообщения PRI.
Так же вы можете использовать порты. В каждой строчке подписывается какому порту соответствует вывод
протокол:слот/поток:канальный_интервал
Re: парсер трейса или как отследить вызов
что бы по порту ориентироваться - придётся сначала лишние концы строк сначала убивать. а сообщение ISUP всё равно вместе с PRI идут в одном блоке. Поэтому наверное можно просто парсить от -{34} до следующей последовательности -{34}, выдирать оттуда CR из строчек с Q931 и добавить к предыдущему куску с таким же CR, ну или создать новый. А если найдётся два CR в блоке - это будет установка соединения в направление исходящей связи и искать дальше надо уже новый, вплоть до
UPD:
это просто рассуждения ) поговорить на эту тему больше не с кем)
UPD:
Call XXXX. State 'Null'
это просто рассуждения ) поговорить на эту тему больше не с кем)
Re: парсер трейса или как отследить вызов
я значит решил, что я пока бессилен. алгоритм сбора вызова не помещается в голову. всё таки в блоки между кучей "-----" могут попадать строчки с другого вызова...
можно искать MSG=SETUP или IAM, определить что он первый, а не часть транзитного выхода, цепляться за несколько сущностей (Порт, CIC, CR (который меняется с прохождением вызова, + в setup он в одном виде, далее почему то к нему прибавляется 9000 в 16-ти ричном виде (точно не помню, могу попутать, неделю назад разбирался). потом по строчно следить где будет релиз....
1) пробегать файл с сотнями тысяч строчек надо будет много раз, потому что вызовы могут быть с двумя сетапами, с двумя IAM, или и с тем и другим...
2) надо придумать что делать и как детектить вызовы, которые закончились внутренними ошибками станции (например нет ТГ на порту или что то с это роде, когда даже релиз комплит не отсылается)
3) весь файл распарсить не получится, потому что в трейс одного вызова может вклиниться строчка без порта и других отличительных признаков... дампы - самое популярное из таких случаев.
Неужели разработчики не задумывались о написание парсера трейсов? Ведь для этого достаточно как то упорядочить вывод трейса или снабдить каждую строчку ID вызова?
можно искать MSG=SETUP или IAM, определить что он первый, а не часть транзитного выхода, цепляться за несколько сущностей (Порт, CIC, CR (который меняется с прохождением вызова, + в setup он в одном виде, далее почему то к нему прибавляется 9000 в 16-ти ричном виде (точно не помню, могу попутать, неделю назад разбирался). потом по строчно следить где будет релиз....
1) пробегать файл с сотнями тысяч строчек надо будет много раз, потому что вызовы могут быть с двумя сетапами, с двумя IAM, или и с тем и другим...
2) надо придумать что делать и как детектить вызовы, которые закончились внутренними ошибками станции (например нет ТГ на порту или что то с это роде, когда даже релиз комплит не отсылается)
3) весь файл распарсить не получится, потому что в трейс одного вызова может вклиниться строчка без порта и других отличительных признаков... дампы - самое популярное из таких случаев.
Неужели разработчики не задумывались о написание парсера трейсов? Ведь для этого достаточно как то упорядочить вывод трейса или снабдить каждую строчку ID вызова?
Вернуться в «АТС: городские, узловые, сельские»
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 21 гость