IMHO, проект заслуживает одобрения и поощрения ;) Только вот тестовая страница не авторизует :(

А как обстоят дела со сбором статистики с офисных IP АТС ? ...

Во-во, не авторизирует нифига

Это как разрабатывать свободную 1С.

Форматы CDR для АТС слишком разнятся друг от друга.

Юзал данную софтину.... вроде задумка неплохая, но много ошибок было в коде. да мне кажется что уже можно было бы и подумать про офисные IP АТС, потому как поддерживать только старные АТС ИМХО бесмыслено

Это не проблема. Код обработки вынесен в библиотеку, да и отличия, вобщем-то, за редким исключением (а-ля Меридиан) состоят в расположении параметров или формате даты :)

Авторизация fixed. Я забыл указать Read Only для таблиц пользователей и какой-то "добряк" зайдя через веб морду удалил пользователя "atslog". Скажем ему Большое Спасибо ;-)

Ошибки исправляем, будем рады багрепортам. Что качается IP атс - присылайте формат логов, добавим. Новая версия умеет подключатся к АТС по TCP/IP, причём в двух режимах - как клиент и как сервер. Что касается офисных НЕ ip АТС - я думаю, что они ещё не скоро отомрут.

Имеется АТС Panasonic. Программируется через RS232, логи сливаются оттуда же. Нельзя ли имея два порта на борту организовать прозрачный доступ в режим программирования? Ломает переключать кабель.

[Windows_ПК] --> [RS232 ATSLog RS232] --> [ATC]

А с Awaya'ей это чудо дружит?!

Два дня назад как раз думал о такой программе, буду иметь ввиду.

А Меридиан в качестве поддерживаемых ожидается?

Да, меридиан ожидается. У меня уже есть пример лога, но нужен бета тестер. Если у Вас есть доступ к меридиану - напишите на samm [at] os2.kiev.ua или на форум сайта.

> А с Awaya'ей это чудо дружит?!

Ещё нет. Присылайте формат логов.

А с Samsung NX820 работает?

IMHO, очень неплохо. Только сейчас IP-телефония рулит.
Этот бы проект лет 7 назад - было бы самое оно.

> А с Samsung NX820 работает?

Полный список поддерживаемого оборудования выложен на http://atslog.local/about/ . Если Вашей АТС`ки в нём нет - присылайте формат пример логов, и если вы готовы быть бета-тестером, добавим.

Там что насчёт поддержки подключения программаторов АТС через rs-232?

>http://atslog.local/about/

Ты с какого измерения?

>Только вот тестовая страница не авторизует :(

это квартира. Звони на АТС

> Там что насчёт поддержки подключения программаторов АТС через rs-232?

Я честно говоря не совсем понял, что именно Вы хотите. Вобщем-то в нормальных АТС для программирования идёт другой порт чем для снятия логов, что более чем логично. Кроме того, насколько я знаю, весь софт для работы АТС обычно всё равно под win32, так что не понимаю при чём тут atslog. Что касается использования порта удалённо (через TCP) - насколько я знаю, такие решения есть, гугл вам поможет.не факт, правда, что оно заработает. В любом случае, программирование АТС в задачи проекта точно не входит, даже в перпективе )

>>http://atslog.local/about/

>Ты с какого измерения?

copy & paste из броузера. http://atslog.dp.ua/about/ . Можно было и догадаться, правда?

В этом ничего страшного нет - достаточно сделать следующее: 1) делается универсальная структура БД со всеми необходимыми полями. 2) пишется читалка CDR с настраиваемым конфигом. Читалка - это в чистом виде парсер CDR, который парсит строки с помощью regexp'ов. К примеру, есть строка CDR, начинающаяся с даты звонка:

> 20.11.06

В читалке cdr regexp оформляется так:

> ([0-9]{2})\.([0-9]{2})\.([0-9]{2})

StartDay=0 StartMon=1 StartYear=2

Т.е. в скобки заключаем то, что надо выдрать и занести в базу. 0 - номер пары скобок с требуемым полем.

Читалка распарсит строки и запишет выдранные поля в базу.

Идея ясна? :)

* Экспорт данных в формат Excel

А что насчёт odc?

Нахнаген этот odc...

Во-во, код выделен и это хорошо. Еще бы доки на архитектуру обработчиков и люди потянутся...

Ибо модульность и документированность - это хорошо.

Еще бы не помешала возможность работы с АТС по COM-порту. Это ж несложно ;)

В смысле, чтоб она умела по COM-порту считывать CDR.

Читаем:

Кратко про возможности: * В качестве источинка данных можно использовать: последовательный порт, подключение по TCP/IP от АТС к ATSLog,

Это не оно?

> Вобщем-то в нормальных АТС для программирования идёт другой порт чем для снятия логов, что более чем логично.

В наличии имею TD1232 и кабель от неё, с него валятся логи и через него же она программируется. Делается это действительно с win32, но для этого я буду вынужден переключать кабель от ПК для сбора статистики к машине с win32-программатором.

Выше я рисовал:

[Windows_ПК] --> [ RS232(1) ATSLog RS232(2) ] --> [ATC]

Т.е. при попытке программирования АТС ATSLog должен перенаправлять операции с COM1 на COM2 и возвращать ответы. Замечено, что при этом АТС кэширует какое то время лог и потом "вываливает" его после завершения операции программирования.

Пардон, лоханулся.

>Т.е. при попытке программирования АТС ATSLog должен перенаправлять операции с COM1 на COM2 и возвращать ответы. Замечено, что при этом АТС кэширует какое то время лог и потом "вываливает" его после завершения операции программирования.

Я не думаю, что это 1) простая задача. 2) задача для ATSlog.

Честно говоря можно открыть 2 COM порта и виртуально соеденить их, но совсем не факт, что это нормально заработает. Потому как программа может выставлять параметры порта, flow control делать и т.п. Вобщем, я не думаю, что это будет реализовано в рамках ATSLog, тем более, что тестировать подобное мне негде. Впрочем, если кто-то захочет написать такую утилиту и интегрировать её с atslogmaster то почему бы и нет.

Все перечисленные решаемые задачи это хорошо. В нашей организации есть задача (решенная на Access) по распределению затрат по отделам. Но эта задача должна решаться не по логам от УАТС, а по данным ГТС. Как показала практика ГТС присылают данные которые УАТС не регистрирует :-(

>IMHO, очень неплохо. Только сейчас IP-телефония рулит.

Вот мужики то не знают, ставят MD110 и цифровой поток по оптике, при слове
IP-телефония готовы задушить кого угодно... IP-телефонию ставят там, где это выгодно, а где не выгодно, даже связываться не будут.

ats

> при попытке программирования АТС ATSLog
я сответую для KXTD-1232 поставить досовскую прогу для програмирования и запускать её через dosemu плюс cdr_read (http://www.gamma.ru/~avk/) - такое точно работало номрально и нормально разводилось

Жжошь!

McMCC, ip -- просто транспорт. закодировали голос и пустили его в канал. если ip идет по atm, то это хорошо, если идет по mpls, тоже не плохо. а вот если используется ethernet -- дело труба. именно это приводит мужиков в бешенство. :-)

я не пойму, а что такого сложного в логах атс, которые работают по ip? есть дата, время, кто звонил, куда звонил, сколько по времени звонил? так в чем проблема?

Хотелось бы видеть деление междугородных и международных звонков по направлениям и возможность конфигурирования тарифов для направлений, например, путём обработки номера регулярными выражениями, по одному для каждого направления. В итоговой строке должно быть не суммарное время, а сумма денег ;)
Также было бы не плохо иметь возможность запуска внешних программ в случае, когда в логе появляется сообщение об ошибке от АТС.
В данное время пользуемся платной (легально купленной) программой учёта, но она не позволяет определить реакцию на ошибки от АТС, а у нас ISDN PRI регулярно отваливается...
Также хотелось бы видеть возможность управления АТС, напримет в случае ошибки с потоком E1 - действия: перевести карту ISDN PRI в режим OUS и обратно в режим INS. Хотя возможно управление АТС слишком сложно для универсальной программы...

Че-то мне кажется, что программа сбора и анализа звонков не должна мониторить состояние плат цифровой телефонии. Для этого, по идее, нужен отдельный программно-аппаратный комплекс (софт-свитч, так сказать), с мониторингом через веб-интерфейс и т.п.

Либо - писать/заказывать спец. ПО для мониторинга/управления.

а у нас в Белоруссии IP телефония запрещена!!!!!!! даже иностранных студентов отслеживают по скайпу :) у нас монополисты государство и своего оно не упустит!!!!

так что обычные атс рулят!!!