Тема: Есть ли в природе полноценный биллинговый софт?

Все PBX софтины которые я нарыл в Сети позволяют лишь собирать статистику и красиво или не очень формировать отчеты по звонкам.
Некоторые позволяют так же проводить тарификацию по предварительно вбитым тарифам (обычно не совсем бъется со счетами операторов связи из за специфики учета времени звонка на мини АТС)

Однако у меня задача стоит не совсем такая: Нужно организовать автоматическую обратную связь с мини АТС.
Т.е. на основе собираемой статистики и базы квот организовывать автоматическое управление маршрутами доступа к CO!!!

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

Если говорить проще, то, скажем, для внутреннего номера 123 есть месячная квота 1 час исходящего межгорода и 1 час исходящих GSM (через GSM Gateway).

Как только с внутреннего номера 123 съедается та или иная квота то, сразу или в течение 15 мин, часа, конца дня и т.п. соответствующий маршрут автоматически отрубается и автоматически поднимается в начале следующего месяца. (Или подъем маршрута осуществляется вручную, если есть спецразрешение за подписью Генерального директора.)

Т. е. речь идет о системе учета и тарификации с модулем управления мини АТС!!!

Есть ли вообще в природе такой софт? Если да, то линку pls!!!

Крайне желательно, чтобы хотя бы коллектор и собственно управляющий модуль были бы портированы под *NIX. А разные красивости и отчеты, т.е. администраторско-клиентский модуль, фиг бы с ними, может быть и под M$ Windows. Хотя, IMHO, и нормально продуманного WEB интерфейса вполне бы хватило...

Теоретически, я конечно представляю, как это должно работать. Если по аналогии, то что-то типа систем учета трафа прикурученных к SQUID-у и SQL. Но практически я даже не знаю где хотя бы взять список управляющих кодов, которые можно загнать в мини-АТС через RS232 8(
(интересуют управляющие коды для Panasonic KX-TDA)

Есть такие софты. 😊 Правда они под юниксы не заточены, но под W2K+MSSQL шуршат исправно. В основном такие решения используют наши клиенты на станциях от 300 и более абонентов. У нас такая технология реализуется связкой Логгер + Тарификатор + модуль “Бюджетирование” + модуль “Управление оборудованием”. Все включается автоматически и выключается тоже. Скажу сразу - демки пока нет, посмотреть никак. Сертификат МинСвязи имеется. С маленькими станциями (до 100 абонентов) не работаем. По крайней мере пока. Ибо не выгодно финансово.

Создано PValera
Есть такие софты. 😊 Правда они под юниксы не заточены, но под W2K+MSSQL шуршат исправно. В основном такие решения используют наши клиенты на станциях от 300 и более абонентов. У нас такая технология реализуется связкой Логгер + Тарификатор + модуль “Бюджетирование” + модуль “Управление оборудованием”. Все включается автоматически и выключается тоже. Скажу сразу - демки пока нет, посмотреть никак. Сертификат МинСвязи имеется. С маленькими станциями (до 100 абонентов) не работаем. По крайней мере пока. Ибо не выгодно финансово.

А почитать где? Я не скажу, что мне очень уж это нужно, но знать хотелось бы - вдруг кто захочет.

W2K+MSSQL

Это мягко говоря не радует, гораздо приятней FreeBSD+MySQL или Postgree SQL+Apache+WEB Interface, но все таки как зовут софтину.

К тому же речь не идет об оказании услуг связи. Как следствие, ее сертифицированность в МинСвязи мне глубоко по барабану. Мне нужно биллить лишь внутри предприятия...
Если софтина под MustDie, то какова, хотя бы орентировочно, цена вопроса (+- 0.1 килобакс)?
Умеет ли софтина управлять МиниАТС Panasonic серии KX-TDA?

Создано nikol

А почитать где?

Скоро будет доступно на www.tarificator.ru . Пока там только информация о старой версии 2.1 Я говорю о 4.0

Создано MJ Scorpio
Это мягко говоря не радует, гораздо приятней FreeBSD+MySQL или Postgree SQL+Apache+WEB Interface…

На вкус и цвет... 😊

Создано MJ Scorpio
но все таки как зовут софтину.

Софтину зовут Коммуникационный Аудитор

Создано MJ Scorpio
какова, хотя бы орентировочно, цена вопроса?

Цена вопроса зависит от потребностей. Стоимость модуля тарификации  - зависит от количества учетных портов, а доп. функциональность от количества модулей расширения.

На сегодняшний день, тарификация на 1000 портов (минимальная лицензия) - 1500 USD Модуль управления станцией - 500 USD

Создано MJ Scorpio
Умеет ли софтина управлять МиниАТС Panasonic серии KX-TDA?

Заказчиков, которым нужно было сделать управление именно на эти станции, у нас пока небыло. Были только на тарификацию. Вероятно для владельцев Panasonic наша цена слишком высока. Этот сегмент рынка привык к WinTariff, поэтому и спрос определенный. (Про WinTariff ничего плохого в виду не имелось. Решение нормальное). Если появится заказчик в этом сегменте - прикрутим и к панасу, если у него это технически реализуемо...

Создано PValera

Скоро будет доступно на www.tarificator.ru
На сегодняшний день, тарификация на 1000 портов (минимальная лицензия) - 1500 USD Модуль управления станцией - 500 USD

2 Килобакса - крутовато.

Да и 1000 портов на фиг не нужно.

У нас то всего 16 внешних и 128 внутренних.

Вот если бы речь шла о сумме не превышающей 0.7 килобакса, да еще при наличии коллектора, завязанного, ну хотя бы на MySQL и управлялки АТС-кой точенными под FreeBSD, то это был бы разговор...

А то, если я правильно понимаю придется еще M$ SQL покупать и 2k3 сервант... А это еще не менее 1.5 килобакса...
... Как то неуютно получается... 8(
Общей сложностью почти 4 килобакса за 200 портов, без учета , как я понимаю, достаточно нехилого железа - это грустно 8(

Прогулялся по лике http://www.tarificator.ru/

ни чего не понял 8(

Какие-то скриншоты какого-то убогого интерфейса писанного то ли на старой делфе (~v3), то ли чуть ли не на кларионе...

А где же прорекламированная крутая PBX софтина c модулем управления мини АТС?

По теме есть свежая и вкусная инфа!!!
Цитата из ответа на письмо отправленное вчера

“...Мы разрабатываем новую систему на базе “PBX Call Tarificator Pro” и интерфейса TAPI, которая будет вести учет стоимости разговоров в реальном времени и ограничивать абонентов путем переключения класса сервиса (COS). Мы ориентируемся на мини-АТС Panasonic KX-TDA и KX-TD.

Ориентировочное время выхода первой версии - середина 2006 г....”

Цитата из другого письма ответ пришел сегодня к обеду:
“...Для мини-атс KX-TD/KX-TDA функционал “изменения класса обслуживания абонентов при превышении лимита” находится в состоянии бета-тестирования. Мы можем предоставить соответствующий скрипт и набор библиотек для этого.
Основным требованием к АТС от Panasonic является поддержка интерфейса TAPI, только в этом случае это будет работать...”
“...Вероятнее всего, если вдруг не возникнут неожиданные сложности, то в следующем месяце все будет готово (или даже в этом)...”

Здесь уже речь о софтине TariScope!!!

Так что НАРОД!!! жизнь налаживается!!!

Создано MJ Scorpio

2 Килобакса - крутовато. У нас то всего 16 внешних и 128 внутренних.

Вот именно об этом я и говорил в своем предыдущем посте. Вы - немножко не наш клиент. Наш клиент от 500 портов...

Создано MJ Scorpio
А то, если я правильно понимаю придется еще M$ SQL покупать и 2k3 сервант...

Тут вы очень сильно ошибаетесь, уважаемый. Можно использовать MSDE - он бесплатный. Для наших задач его хватит за глаза.

Опять же если Вы _ВНИМАТЕЛЬНО_ прочитаете мои посты, вы заметите, что :
1. Я говорил о W2K, а 2k3 сервант... не более чем Ваши фантазии.
2. Я говорил Скоро будет доступно на www.tarificator.ru . Пока там только информация о старой версии 2.1 Я говорю о 4.0 а вы упорно ищете там что - то уже сейчас.

Внимательнее читайте посты собеседников, уважаемый MJ Scorpio, будет меньше недопонимания.

Искренне надеюсь, что мой пост Вас не обидел.

Создано PValera
Искренне надеюсь, что мой пост Вас не обидел.

Абсолютно без обид... 8)
К тому же я уже почти нашел то, что мне нужно...

Но если говорить о софтине, предложеннной Вами, уважаемый  PValera, хотя бы теоретически, то я с уверенностью могу утверждать следующее:
Сегодня достаточно проблемно приобрести W2K, а уж тем более NT4.
К тому же у меня в локалке поднят домен на 2k3, сеть гибридная гетерогенная, как по топологии, так и по используемым осям. Как следствие, чтобы был доступ по сети к биллинговой машине с произвольного разрешенного компа произвольному разрешенному юзверю, нужно иметь либо биллинговый WEB интерфейс, либо джойнить биллинговую машину к домену. С W2K это уже не совсем хорошо, а с NT4, как минимум, придется перестраивать контороллер домена на не совсем стандартный режим.

Для моего случая подходят такие варианты:
1)Биллинговый софт под произвольную ось, но в наличии WEB интерфейс. Доступ к интерфейсу определяется WEB сервером.
2) Биллинговый софт под *NIX + NTLM аутентификация на базе winbind от Samba 3 + Heimdal Kerberos. (проверено, уверенно работает с 2k3 SP1)
3) Биллинговый софт под *NIX, доступ к биллинговому интерфейсу по XDMCP c поизвольной *NIX машины.
4) Биллинговый софт под *NIX, доступ к биллинговому интерфейсу по VNC c машины под произвольной осью.
5) Биллинговый софт под MustDie. Ось не ниже XP Pro.
6) Тоже самое, что и 5), но доступ к биллинговому интерфейсу в терминальной сессии по RDP5

Предлагаемый Вами софт подходит, как я понимаю, под п.п. 5) и 6)

Но тут вылез еще один момент после общения с руководством. Биллинговый софт должен управлять COS миниАТС еще на уровне смарткатр.

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

Я пока слабо себе представляю как, но предположительно у внутренних телефонов, для которых теоретически разрешен межгород, будут стоять некие считыватели смарткарт, которые должны каким то образом аутентифицировать звонящего и предоставлять или не предоставлять доступ к межгороду. Т.е. нужно отказаться от PIN-кодов доступа к межгороду в явном виде, но так же производить учет и квотирование и по ним

Есть мысли по этой теме?

Создано MJ Scorpio
Есть мысли по этой теме?

Да, есть.
Вы, часом, не в ЦРУ работаете?

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

P.S. Для доступа к MSDE, запущенному на компе с биллингом, нет необходимости в тех манипуляциях, которые Вы описали. Аутентификация может вестись самим SQL сервером и это работает достаточно надежно. Его даже в домен можно не прописывать... Так что не ищите сложностей, особенно там, где их нет, и жизнь окажется намного приятнее. 😊

Пользуясь случаем, поздравляю всех с 23 февраля!
Всем удачи, здоровья и мудрости 😊

Создано PValera

Да, есть.

Где посмотреть?
Какая хардварная часть?
До $150 за аналоговый телефон с ридером смарткарт в принципе подъемно.

Вы, часом, не в ЦРУ работаете?

К счастью нет!
По этому сетевая безопасность не такая дырявая, как у них, а вполне на параноидальном уровне, включая блокировку ICMP и прогон основной части конторского внешнего I-Net трафа через некоторое количество анонимайзеров 8)))

Руководство ставит задачи, а я пытаюсь их решать, как умею, т.е. сильно сдобрено паранойей и манией преследования... 8)))

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

Предложение, конечно, замечательное, но абсолютно нереализуемое по двум причинам:
1) Монстрячить такие конструкции придется вручную, по причине отсутствия такого готового железа в продаже - а мне самому это делать просто лениво.
2) На сегодняшний день еще нет софта работающего с биометрическими параметрами с вероятностью верной идентификации хотя бы 99.9999. То о чем я слышал, видел, щупал существует где то на уровне 80-95%, т.е. не более, чем интересная игрушка и сыро для пром.эксплуатации.

К тому же нечего прикалываться. Если единая СКД, заточенная под смарткарты, на перприятии и так строится, то почему бы не использовать элементы СКД для телефонии?

Пользуясь случаем, поздравляю всех с 23 февраля!
Всем удачи, здоровья и мудрости 😊

Присоединяюсь к поздравлениям!!!

Не Вам ля я писал на форуме MXM:

Я внимательно все почитал и вот что я думаю по данному поводу.

1. Под данную задачу полностью подойдет наш Blitz TAPI SMDR, но только 2-й версии. Подойдет ли
Wintariff не знаю, возможно, его придется дорабатывать, а возможно кто-то из производителей биллинговых программ быстрее согласится на доработку своей под данную задачу.

Я могу выслать описание интерфейса взаимодействия Blitz TAPI SMDR и внешней программы для изменения COS внутренним абонентам и пример его реализации в Wintariff .

2. Реализация мне видится таким образом :

а) для каждой карты доступа СКУД выделяется свой “Номер аккаунт” и
COS2.(Этот номер аккаунт не имеет ничего общего с аккаунт кодом мини атс) и сумму аванса на которую ей разрешено делать исходящие звонки;

б) каждый EXT телефон имеет свой индивидуальный, привязанный к нему,
считыватель и по умолчанию COS1, равный для всех ЕХТ и не позволяющий делать исходящие внешние звонки. При вставлении в считыватель карты доступа СКУД, контроллер определяет ее “Номер аккаунт” и дает команду Blitz TAPI SMDR поменять COS связанному со считывателем ЕХТ на COS2 для этой карты доступа
СКУД.

в) при удалении карты из считывателя, контроллер опять дает команду Blitz TAPI SMDR поменять COS связанному со считывателем ЕХТ на COS1.

г) при превышении аванса карты доступа СКУД на внешнии звонки, контроллер меняет ей COS2 на равный COS1, до пополнения аванса, а EXT , в считаватель которого она вставлена, также на COS1.

д) при каждом звонке с ЕХТ нужно, чтобы Blitz TAPI SMDR писал в Call.dbf
“Номер аккаунт”карты доступа СКУД в колонку Account code, а биллинговая
программа (тот же Wintariff) должна тарифицировать по полученному Account
code. Вот здесь может потребоваться доработка Blitz TAPI SMDR.

и еще писал:

3. Кстати можно еще решить задачу без всяких считывателей карт возле каждого
ЕХТ. Через функцию 2.6.2-65 Dial Information (CTI) для TDA/

Выглядеть это будет следующим образом:

а) для каждой карты доступа СКУД выделяется свой “Номер аккаунт” и
COS2.(Повторяю этот номер аккаунт не имеет ничего общего с аккаунт кодом мини атс) и сумму аванса , на которую ей разрешено делать исходящие звонки; Каждому работнику и посетителю выдается своя карта доступа СКУД с индивидуальным COS2,”Номером карты” и “Номер аккаунт” .

б) каждый EXT телефон имеет по умолчанию COS1, равный для всех ЕХТ и не позволяющий делать
исходящие внешние звонки.

в) При вставлении в считыватель карты доступа СКУД на входе (рецепшен, входе
в помещение), контроллер определяет ее “Номер аккаунт” и дает возможность Пользователю карточки зарегистрироваться на любом ЕХТ со своим “Номером аккаунт”.

г) Регистрация происходит следующим образом . Владелец карточки подходит к
желаемому ЕХТ. Поднимает трубку и набирает номер абонентской функции Dial Information (CTI) (необходимо запрограммировать в Numbering plan) +14+”Номер карточки”+*”Номер аккаунт”+ # ( по аналогии с KX-A296/297)

Blitz TAPI SMDR определяет с какого внутреннего была произведена
регистрация ( Blitz TAPI SMDR требует доработки) и передает ее параметры
контроллеру. Если параметры правильны, то контроллер дает команду Blitz TAPI SMDR поменять COS ЕХТ на COS2 для этой карты доступа СКУД (можно и имя ЕХТ).

в) Обратный процесс. Владелец карточки поднимает трубку на ЕХТ на котором он зарегистрировался, набирает номер абонентской функции Dial Information (CTI)
+15+”Номер карточки”+*”Номер аккаунт”+ # .

Blitz TAPI SMDR определяет, с какого внутреннего была закончена регистрация
и передает ее параметры контроллеру. Если параметры правильны, то контроллер дает команду Blitz TAPI SMDR поменять COS ЕХТ на COS1(можно и имя ЕХТ на пустое).
Если владелец карточки забыл это сделать с телефона, то при выходе из здания и вставлении в считыватель карточки доступа СКУД для регистрации конца рабочего дня, это должно делаться автоматически.

г) при превышении аванса карты доступа СКУД на внешние звонки, биллинговая система меняет ей COS2 на равный COS1, до пополнения аванса, а EXT , на котором регистрировался владелец карточки доступа СКУД , также на COS1.

д) при каждом звонке с ЕХТ нужно, чтобы Blitz TAPI SMDR писал в Call.dbf
“Номер карты” (не номер аккаунт) карты доступа СКУД в колонку Account code, а биллинговая программа (тот же Wintariff) должна тарифицировать по
полученному Account code. Вот здесь также может потребоваться доработка
Blitz TAPI SMDR.

Выложили BLITZ TAPI SMDR PRO, который имеет открытый интерфейс по изменению COS Panasonic KX-TD/KX-TDA, описание интерфейса и пример реализации для Wintariff (с картинками 😊 на http://www.bkd.dp.ua/soft/cti/TapiSMDR.php.

В принципе задача реализуема, как писалось мною выше.
Уважаемый MJ Scorpio, ответьте, если Вам не трудно, хоть в этом форуме, подходит ли Вам мое решение на данном CTI? Жалко просто своего и не своего времени. Я тут так старался , описывал, голову ломал, плюс о Вас беспокоились инженеры Panasonic и МХМ, а от Вас не ответа не привета.
С уважением.

А не появилось ли в природе-матушке софта, изменяющего COS абонента на основании данных SMDR для станций LDK?