Чего мне не хватает в #asterisk?

asterisk-software

Мониторинг

Вот, например, хочется мониторить астериск. Ставлю, например, zabbix. На машину с астериском ставлю zabbix агента.

А теперь хочу сливать данные о количестве зарегистрированных/отрегистрированных пиров, количестве занятых каналов, количестве состоявшихся разговоров. Традиционно делается это asterisk -rx “core show channels”, а оттуда grep’ом вытягивается значение параметра channels.

А хочется как? А как телеметрический поток снимать: подключился на сокет и регулярно через настраиваемый интервал получаешь пачку байтов о состоянии системы: загрузка, память, количество того-сего и пятого, и десятого, даже в бинарном формате пойдет. Прочитал и снова пачку байтов получил.

Никаких команд, чистый поток данных. Соединение пропало или через установленный интервал система данные не дала – мониторинг уж триггер запускает, техподдержку пробуждает. В общем, телеметрия + healthcheck в одном флаконе.

События

Или вот еще более локальный пример. Передача своих данных в event’ах. Т.е. например, происходит событие QueueCallerAbandon – товарищ не дождался своей очереди, прождал сколько-то минут и бросил таки трубку. И ведь, следуя тенденции повышения качества обслуживания, надо бы ему перезвонить, да желательно сразу как только освободится оператор.

И было бы очень удобно в данных евента указать номер звонящего и список операторов очереди, которую он покинул. На самом деле мне сейчас приходится перед каждым звонящим в очередь бросать дополнительный userEvent с необходимыми данными, и если вскоре приходит QueueCallerAbandon, то делать обратный вызов.

CDR & CEL

А еще read-only cdr. С одной стороны удобно, т.к. данные “не искажаются”. С другой стороны никто не может сделать более-менее читаемый журнал по звонкам, на основе типовых решений для просмотра cdr, который был бы удобен для использования руководителями для просмотра и анализа загрузки по телефонным звонкам своей компании.

Поясню мысль. Например, у нас номера от оператора приходят через peer MTS123489 с номерами звонящих в 10-значном формате, а с другого оператора с 8-кой (11-значном формате). В итоге в таблице БД разброс и шатание. Я не могу записать в peername, dst свои необходимые значения.

Чтобы показывать данные в каком-либо каноническом виде мы должны преобразовывать их: или создавая дополнительные поля в таблице cdr, складывая туда модифицированные в диалплане данные, или преобразуя данные “на лету”, т.е. во время отображения модифицировать полученные данные.

Продолжая тему cdr. С учетом опять же последних тенденций, складывать cdr в БД уже не модно. Безусловно, для хранения cdr в БД (как минимум в файл) ложить необходимо. Ибо это первичные данные, полученные непосредственно в месте возникновения идентифицируемых событий. Но их необходимо оперативно обработать. Например, для гибкости диалплана и большей упорядоченности мы используем канал Local, перенаправляя вызовы на нужные нам контексты и екстеншны.

Нередко в таких случаях возникает больше записей CDR, чем одна (можно использовать NoCDR, но тогда надо отслеживать откуда пришел вызов, есть ли для него CDR уже или нет). Или нередко важны вызовы, которые были сброшены или имели статус ошибки.

В таких случаях было бы удобно направить поток данных cdr в очередь для обработки. Это могли бы быть протоколы zmq, rabbitmq или на худой конец как и в случае телеметрии просто сокет, куда льются данные. После каждой записи worker очереди обрабатывает полученную порчию данных и принимает решение, что с ней делать.

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

Аналогичная ситуация с CEL. Благо CEL можно получать, подключившись к порту AMI, кто-то уже догадался прокинуть. Но хочется уже большего : ) Чтобы сразу в очередь. Или вот недавно встретил модуль, который скидывает CEL по http. Тоже вариант. За http поставить очередь, на которую повешать worker’ов.

В общем, статистику нормальную собрать и показать, и чтоб аналитика была ок – тут еще постараться надо.

Sip router

Простенький kamailio. Вот тут уже интереснее. Конечно, у нас есть опции alwaysauthreject=yes, allowguest=no, и замечательные инструкции по связке логов астериска с fail2ban. Но этого всего можно добиться, если бы можно было писать анализ пакетов.

По сути диалплан это уже обработка invite-пакетов, а в условиях пограничного контроля, где всем пирам требуются логины-пароли, авторизация-аутентификация, этого недостаточно, хочется и REGISTER, и SUBSCRIBE обрабатывать как-то по фигурнее. Для исходящих звонков уже можно делать AddHeader….

Queues

Содержание звонков в очередях на случай остановки астериска. Т.е. если происходит падение астериска, что более вероятно при больших нагрузках, при использовании очередей и наличии в них абонентах, ожидающих своей очереди.

То информацию о списке абонентов мы теряем. Хотелось бы как с realtime агентами, иметь эти данные, например, в БД. Т.е. при поступлении звонка данные об абоненте ложатся в БД, при соединении с оператором убираются оттуда. В случае падения мы хотя бы можем им перезвонить.

QUEUE_MEMBER_LIST – нельзя указать каких операторов я хочу получить, активных, на паузе, всех.

 

Чего мне не хватает в #asterisk?