Релиз ATSlog 2.0.0 - программы для сбора и анализа звонков через мини-АТС

Господа, забыл добавить URL, модераторы помогли, но, сожалению, добавили старый URL, он пока не работает. Используйте, пожалуйста, http://www.atslog.com

о! о! о!

как раз то что нужно! и вовремя :)

спасибо за новость

OK

прыгая от радости !!! тема!!!

то что надо!!!

прибольшое СПАСИБО!

ага и вовремя тоже, тока вот неделю назад думали покупать KX-TDA100 теперь походу будет сподручнее

ага а cisco linksys нет?

Господа, касательно поддержки АТС. На сайте есть полный список поддерживаемых на данный момент АТС. Если Вашей АТС в нём нет - не беда. Железка должна уметь отдавать текстовые логи по Serial порту и/или по tcp (клиентом или сервером). Снимаете логи и пишите в форум atslog.com. Также желательно поискать описание формата SMDR для вашей железки - это сократит время написания библиотеки и сделает её работу более стабильной (многие железки поддерживают несколько вариантов SMDR).

>ага и вовремя тоже, тока вот неделю назад думали покупать KX-TDA100 теперь походу будет сподручнее

KX-TDA200 на объект берём :)

Господа, может кто знает, чем можно программировать KX-TD1232 под Linux. Мелкомягкое+WINE не предлагать. Спасибо.

dosemu + родной софт от 1232, что под DOS. Замечательно работает. Уже лет 7 как :-).

Поделись, будь другом.

2 geek:

>KX-TDA200 на объект берём :)

А осилишь ? Это тебе не хигнутый гном...

УРА!

С одной стороны - похвально. С другой - метод добавления поддержки новых УАТС в корне неправильный.

К сожалению, там много всего изначально было (и есть) неправильно. Переделали, как смогли, до вменяемого вида. Сделать еще много нужно, идеи есть, людей и времени нет. Собственно, делали и переделывали её под себя, чтобы собирать и анализировать звонки, не больше, это не биллинг и не универсальная среда для управления АТС. Каждый, кто принимал участие в проекте, добавлял туда то, что было нужно ему, вот оно так и получилось :)

Ну понятно, что не биллинг :) Просто, на мой (и не только) взгляд, поддержку форматов CDR от разных УАТС имеет смысл сделать настраиваемой (т.е. под строки CDR делается regexp, и парсер на основе указанного regexp'а выдирает нужные поля; значащее поле regexp'а заключается в скобки, а порядковый номер пары скобок - это значение поля). Это крайне гибкая методика, хоть и требует некоторого труда со стороны конечного пользователя. Но зато - никаких проблем с поддержкой чуть ли не ВСЕХ станций. Исключение составят лишь те УАТС, которые выдают CDR в бинарном виде (такие как SI-2000 или Ericsson ANS).

Чем вас текущая схема не устраивает? Или "Пастернака не читал, но осуждаю"? :)

p.s. Кроме бинарного формата есть еще куча разных тонкостей у разных АТС (пример: добавление за день до релиза минимальной поддержки протокола telnet, чтобы можно было по TCP/IP снимать данные с LG [вроде бы], которые по serial она отдает нормально; хотелось найти аффтаров и придушить :)

> Чем вас текущая схема не устраивает?

Тем, что добавлением поддержки CDR от разных УАТС занимается девелопер. Низзя впихнуть невпихуемое - нюансов в форматах CDR все равно столько, что мама не горюй. А regexp-парсеры с этой задачей справятся на "отлично", и всегда можно подгонять под конкретные условия.

>Тем, что добавлением поддержки CDR от разных УАТС занимается девелопер.

Чукча точно не читатель.

Вот ответь мне на простой как 2+2 вопрос - ТЫ СМОТЕЛ СХЕМУ ДОБАВЛЕНИЯ НОВЫХ АТС?

Собственно, чтобы добавить новую АТС которая даёт логи в НЕ бинарном формате, надо взять любую либу (просто перл скрипт) скопировать её в название твоей модели (например, kx-300.lib) и поправить регексп, прописав либу в конфиге. Всё, что есть в либе - это regexp based парсер строки и запись в базу. При этом запись в базу везде одинаковая, в 2.1 я её нафиг из либы унесу. Ещё есть пару вспомогательных ф-ий для либ, вроде AmPm24h(). Т.е. всё и сделано НА регекспах. И как минимум 3 либы были присланны пользователями и позже включены в дистрибутив. Подгонять готовую либу для указанной модели "под конкретные условия" никому нафиг не надо. Всё доступно в SVN. Патчи в berlios.de обрабатываются. О какой такой схеме вы говорите? Единтсвенное что - при добавлении новой АТС я ОБЯЗАТЕЛЬНО добавляю пример её лога в textlogs - чтобы у разработчика всегда была возможность тестировать библиотеку и/или вдруг изменить её API. Кроме того некоторые АТС имеют множество вариантов SMDR.

Добавлением поддержки по присланным логам я занимаюсь лишь потому, что: a) не все знают регекспы и перл в должном объёме. б) мне интересно развитие atslog в) это занимает обычно минут 15-20 + тестирование (пользователем), т.е. не сильно много времени. Опять же я более спокоен за код.

Кроме того в некоторых АТС парсер более "продвинутый" чем просто построчный анализ, что связанно с "особенностями" реализации CDR в них.

Не ори, пейсатель...

> ТЫ СМОТЕЛ СХЕМУ ДОБАВЛЕНИЯ НОВЫХ АТС?

Смотрел... Схема хреноватая. Смысл того, что я означил выше, сохраняется, однако реализация "извращенная" - сделано сложнее, чем можно было бы сделать.

> Кроме того в некоторых АТС парсер более "продвинутый"

Меридиан со своими многострочными CDR, что ли? Тривиальщина.

Ясно - ты тролль. Бывает. Ну ниче - выпьешь яду и вылечишся :)

>пример: добавление за день до релиза минимальной поддержки протокола telnet, чтобы можно было по TCP/IP снимать данные с LG

Зачем telnet? Зачем serial? Это проблемы админов. "Снимайте" с STDIN, чё как дети малые-то.

С какого еще STDIN? :-/

>Смотрел... Схема хреноватая. Смысл того, что я означил выше, сохраняется, однако реализация "извращенная" - сделано сложнее, чем можно было бы сделать.

Интересно, а в каких OpenSource проектах Вы принимали участие? Или только в форуме LOR? И так, по пунктам.

1) Для начала Вы хотели парсер на регекспах. Вам 2 разработчика объяснили о том, что он де с самого начала на регекспах и был сделан. 2) Вы сказали, нахрена мол вообще нужны "либы" когда можно просто в конфиге наприсать регексп. Отвечаем - нельзя. Во первых, это сильно усложнит конфигурацию. Во вторых на одну станцию может быть несколько разных регекспов. В третьих информация от кучи АТС нуждается в пост-обработке, так как она категорически не готова для записи в базу. И это не только формат времени/даты, это и определение типа звонка, парсинг режимов, и т.п. Одна из либ даже исправляет глюк, допущенный авторами прошивки одной из АТС, проверяя корректность данных. 3) Просто регексп тем более не катит для АТС`ок где более 1 строки на событие. 4) Вы сказали, что АТС добавляет только "девелопер", что категорическое враньё. Добавление новой станции у человека со знанием regexp занимает ровно 15-30 минут и НЕ требует патчинга кода программы. Присланные пользователями либы - лучшее тому доказательство.

Единственная "кривость" которую я вижу на данный момент - это то, что в либе осуществляется и запись в SQL. Но чтобы вынести это из либ требуется примерно час работы + тестирования, так что проблема явно надуманна и будет решена в след. версии. Постарайтесь формулировать свои мысли яснее, так как пока у Вас явные проблемы с пониманием обсуждаемой темы.

Alex Samorukov

stdin это стандартный поток ввода.

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

Хотя лично я думаю, что для тех кто будет использовать (я о квалификации) эту пргу как раз лучше получить доступ к RS232 из коробки.

2Автором.
Безуслвоно похвально что пояляются GPL продукты подобного плана, но честно, задача решенная вами (судя по скриншотам) - решается 1 человеком за 2 недели вместе с тарфицикацией и отчетом который требуется для обработки. Вопрос добавления sqlite - вообще несколько часов. Все это пустой треп, я эту задачу решил еще лет 5 назад в похожие сроки, но коробочного варианта естествено нет.

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

>stdin это стандартный поток ввода. С таким подходом мы бы до сих пор жили с inetd based сервисами ) Речь о том, что atslogd в данный момент подходит для данной задачи лучше, чем встроенные в UNIX средства. По многим причинам. Это и одинаковое поведение в разных ОС, и автореконнект в TCP, и возможность снимать логи в трёх режимах, создание pid и, как следствие простота мониторинга.

>Вобщем то речь о том (хотя я не совсем с этим согласен) что не задача проги что то знать о портах. Лог должен вычитыватся с стандартного ввода, а как он туда попадет задача админа.

Ну да. И получаются system depended конструкции с stty, cu, telnet,nc, пайпами, кучей скриптов и т.п. Невероятно удобно как для того, кто устанавливает систему, так и для того, кто потом её обслуживает. Несомненно "хуже" демона на C, который работает одинакого в любой POSIX OS, имеет стандартный набор ключей, интегрирован в систему.

>Хотя лично я думаю, что для тех кто будет использовать (я о квалификации) эту пргу как раз лучше получить доступ к RS232 из коробки.

Вероятно моя квалификация - ниже плинтуса. Так как я предпочту atslogd вместо кучи утилит и скриптовой обвязки. Или вместо изобретания велосипеда на Perl или на C.

>2Автором. Безуслвоно похвально что пояляются GPL продукты подобного плана, но честно, задача решенная вами (судя по скриншотам) - решается 1 человеком за 2 недели вместе с тарфицикацией и отчетом который требуется для обработки. Вопрос добавления sqlite - вообще несколько часов. Все это пустой треп, я эту задачу решил еще лет 5 назад в похожие сроки, но коробочного варианта естествено нет.

Вы бы лучше орфографический словарь себе поставили, уж простите ) А то как-то "тарфикации" "естествено" "пргу" "2автором" режут глаз весьма. Кстати, не понимаю к чему вообще этот параграф. ATSlogd - это freetime проект, который писался в разное время разными людьми. Честно говоря - мне совершенно наплевать о том, за сколько вы способны или нет решить данную задачу. Способны за неделю или две - рад за вас. В данном случае - важен результат. Благодоря работе Дениса, Андрея и моему скромному участию - проект представляет из себя готовое и работоспособное решешение, не имеющее Open Source аналогов. Если вы хотите помочь проекту - присылайте патчи, благо - точек для приложения усилий не счесть. Это и улучшение документации, и реализация улучшенного fastwrite, рефакторинг веб интерфейса, создание дополнительных отчётов и графиков, proofreading текстов, создание пакаджей для разных ОС и т.д. и т.п. Проект открыт для новых разработчиков готовых реализовать свои идеи.

>К чему это я все. К тому, что возможностей вам наворачивать еще есть куда, и самое главное это евристический анализ ложных звонков а также максимальное схождение тарификайции с актуальным счетом телекома.

Евристический - это на предмет звонков в Израиль? :) На самом деле - идей вагон и тележка. В отличии от времени разработчиков. Хотите помочь - you are welcome. Хотите рассказать Миру о том, за сколько дней вы способны решать различные задачи - you are welcome ;-)

Best Regards, Alex Samorukov

Все как обычно.

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


ребят, если писать в ответ такие коменты, Вы зачем на ЛОР новость постите? в надежде что пионеры будут кричать "ура" и шапочки в небо кидать от того, что появился еще один проект?

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

>Скажишь пару слов, вобщем то весьма положительных (как показалось автору написанного) - получишь в ответ "сам дурак" и "поставь словарь".

Это про то, что вы могли сделать за две недели? А потом сделали, но этого "естественно" никто не видел? ;-) Дураком я Вас не называл, а словарь поставить стоит )

>ребят, если писать в ответ такие коменты, Вы зачем на ЛОР новость постите? в надежде что пионеры будут кричать "ура" и шапочки в небо кидать от того, что появился еще один проект?

Вам, вероятно, это покажется странным, но вовсе не для этого. Причин несколько и все, вобщем-то, очевидны. 1) Для того, сообщить сообществу, что есть такой проект и им можно пользоваться. 2) Для того, чтобы сообщить пользователям проекта о том, что вышла новая версия. 3) Для поиска людей, которые будут заинтересованы в помощи проекту и его развитии. Шапочки оставим красноглазым, несмотря на тёплую зиму.

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

Вы уже подсказали, спасибо ;-) Я уже отписал - на данном этапе идеи не сильно нужны, по крайней мере если они не оформлены в виде патчей или donations.

Alex Samorukov

Позвольте Вас поддержать, и посочувствовать тому, что аффтар предпочел Вас не понять. Ваш подход ближе к unix-way, IMHO. И уж подавно, в разрезе "поддержки _любой_ POSIX системы".

Я знаю, что такое stdin. Если вы предложите легкий способ получения в stdin процесса данных с АТС, переданных по tcp/ip или полученных из serial port, мы рассмотрим этот вариант и если он будет лучше и удобнее, то выкинем наши пионерские наработки :-) Только не забудьте:
1. У каждой АТС могут быть свои параметры serial port
2. Инициатором TCP/IP сессии может выступать как АТС, так и получающий данные процесс
3. Даже при удачном прокидывании TCP/IP сессии еще нужно сэмулировать протокол telnet для некоторых АТС, протокол получения данных бывает двунаправленным (сейчас у нас этого тоже нет, кстати), данные могут приходить в "бинарном" формате, символ переноса строки может отличаться от \n и \r и т.д.

Скорее всего это получится очередное непереносимое нагромождение скриптов и различных утилит, которое добавить еще десяток звеньев в цепочку получения данных от АТС. Про надежность такой конструкции вообще отдельный разговор :)

Теперь про быстрых и опытных программистов :) Вы где-то видели утверждение, что эта задача решается дольше? Как уже сказал Alex, это freetime продукт. Никто не занимался постановкой задачи, никто не предоставлял спецификации и оборудование для написания и тестирования, никто не оплачивал даже минимально работу, изначально это было сделано для своих нужд Денисом, потом оказалось, что это нужно еще кому-то и потихоньку стала расширяться функционалность, по мере необходимости. Дениса уже достаточно давно не видно на горизонте, у меня давно нет никаких АТС и занимаюсь я этим продуктом только из-за энтузиазма и когда кто-то что-то вменяемо просит сделать. Последние полтора года практически ничего сделано не было, в середине декабря появился Alex и за месяц сделал столько, сколько не было сделано за два года.
Поэтому предлагаю вам вместо рассказов про сферических коней в вакууме принести реальную пользу проекту, добавив свои наработки.
Своих идей у нас предостаточно, да и на поверхности все они. Делать только некому.