using SHARED asterisk

Использование функции SHARED не очень удобно. Т.к. она привязана к каналам.

Например, мы делаем вызов в queue, где агентами являются Local-каналы, т.е. по отношению к текущему это будут другие каналы. По идее можно было бы узнать имя родительского канала через наследуемую переменную, но как мы будет в него сохранять данные? У нас может быть переменное количество каналов, да и они могут вызываться в queue по нескольку раз. Т.е. пакетов данных по звонкам в сабканалы может быть много.

Альтернатива – использование внешнего хранилища, например, redis. На сабканале делать redis.lpush на uniqueid, а в основном канале сделать redis.lrange по uniqueid и получить массив данных одним хопом. Единственно, необходимо на ключи redis ставить TTL, иначе они будут накапливаться в памяти.

Начало здесь: https://asterisk-support-ru.slack.com/archives/asterisk/p1462528938000253

using SHARED asterisk

Конфигурация в tmpfs

По идее можно записи на астериске кешировать на tmpfs.

в asterisk.conf есть опции

cache_record_files = yes ; Cache recorded sound files to another
; directory during recording.
record_cache_dir = /tmp ; Specify cache directory (used in conjunction
; with cache_record_files).

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

Как это дело замутить с докером?

Конфигурация в tmpfs

md5 в asterisk

Полезная команда

echo -n “1234:asterisk:abcd” | md5sum    – md5-хеш от строки без символа новой строки

Несколько конструктивных заметок

  1. Указать realm в sip.conf [general]  – необходимо зафиксировать realm, чтобы в случае необходимости сменить или поправить. По дефолту ставим realm=asterisk, realm указать в каждом пире нельзя.
  2. md5secret = md5(username:realm:secret)

Ссылки:

http://www.voip-info.org/wiki/view/Asterisk+config+sip.conf

http://www.voip-info.org/wiki/view/Asterisk+sip+md5secret

БД update

http://marc.info/?l=asterisk-users&m=121736726209773

 

Есть еще тема про домены

http://superuser.com/questions/598797/realms-in-asterisk

http://kb.smartvox.co.uk/asterisk/how-it-works/configuring-sip-domains-asterisk/

md5 в asterisk

Виртуализация и контейнеризация #webdev

Вообще, сравнивать виртуалки и контейнеры – не комильфо. Суть виртуализации была разделить и сделать машины поверх железа. Виртуализация говорит: железо – отстой. Оно ломается, а виртуальная машина нет. Но ее лучше забекапить. Целиком. Все эти системные блоки умещались в один большой мощный сервак. Там у нас 1С на винде, а еще на фряхе там почтовик и прокси, чтобы смотреть кто по порнушным сайтам ходит. Сломалось железо? Заменили. Все виртуалки целые.

А у докера другая цель, которая становится очевидной когда научишься разделять а) приложение, б) его конфигурацию и в) данные приложения. Докер говорит: ваше приложение – ничто. Его надо заставлять работать. Оно иногда умирает? Я его заставлю работать снова. Ему надо отдельные пакеты-шмакеты, ОСы и т.п? – ок. Пусть думает, что оно одно и все для него. И работает. А если умрет, я его подниму и заставлю работать. А где будет работать приложение? На железе? В виртуалке? В виртуалке, которая запущена в виртуалке? Докеру все одно: запустить контейнер, чтобы приложение работало. Бекапить приложение? Очень смешно. Образ есть? Работаем. Нет? Сбилдим, и ок. Остается только забота о конфигурациях и данных. Ну и приложения иногда писать надо, не самому же работать в докере : )
А поскольку докер позволяет отделить мух от котлет, то появляются решения для управления всем этим колхозом. Поэтому контейнеры – это возможность эффективнее использовать ресурсы, контейнерам прямая дорога в ентерпрайз.

Вы же знаете эту тему: приходите к кому-нибудь, смотрите комп,а там на Винде вирусни.. В общем, самое быстрое и радикальное – переустановить. А он: а,мать моя, у меня там Герои 3 стоят, там уже много прошел и CS и все такое, а еще фотки там слиты где-то и документы, и диплом там же, наверное, хорошо если в Users. Приложения с конфигами и данными в перемешку. Переустанавливаешь. А он: шеф, все пропало! А если бы все данные на USB-винте были, а конфиги и настройки сети на флешке? Плюс скрипт, который знает какие игрухи поставить, да приложения скачать?

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

 

 

Виртуализация и контейнеризация #webdev

Открытый формат расположения банкоматов #opendata #bank

Однажды… однажды до банков дойдет, что необязательно информацию о своих банкоматах выводить только на своем сайте и в своем приложении. А можно предоставить ее в открытом виде.

Серьезно. Множество разработчиков могут сделать куда более функциональное и удобное приложение, где отобразить информацию о банкомате, собрать отзывы о его работе, своевременно сообщить о поломках и т.п. если им дать информацию о банкоматах и API для отправки информации о проблемах с банкоматами.

Надо всего: название, адрес, код, время работы, доступные операции, тип (свой или банк-партнер с комиссией/без комиссии).

 

Upd. https://www.openbankproject.com/

Открытый формат расположения банкоматов #opendata #bank

6 причин писать диалплан asterisk на lua

Синтаксически

  1. Переменные диалплана? Структуры lua: строки, таблицы.
  2. макросы, gosub’ы? нет, спасибо. Используем функции.
  3. GotoIf? Нормальные циклы и условия вместо скачков по приоритетам и контекстам.
  4. ODBC? Нет, спасибо, наелся. Используем прямое подключение к mysql, mongo, redis.
  5. Чего-то не хватает? Используем пакеты luarocks.
  6. Отладка, ошибки? Да, хоть в астериск, хоть в kibana-logstash-graylog и еще куда-то там.
  7. Бонус: тесты. Покрытие кода диалплана тестами.

Методологически

  1. Удобное написание – более красивое и качественное оформление кода.
  2. Более логичные блоки и более полная обработка различных вариантов.
  3. Большее количество вариантов обработки.
  4. Вся логика в одном месте: нет такого – запросы в одном месте, логика диалплана в другом.

 

Минусы

  1. мы в рамках астериска. lua – это более удобный обработчик звонка. Но не более.
  2. Нет взаимодействия между каналами. Требуется придумывать свои схемы для обмена данными.
  3. Нет удобного доступа к встроенной БД, нет удобного доступа к разделяемому пространству с разных каналов.

Вывод: все тоже самое. Мировая скорбь. Но чем больше проект, чем гибче функциональность требуется от астериска, от телефонной системы, тем более гибкий инструмент хочется использовать. И lua гибче раза в полтора стандартного диалплана.*

*по оценкам британских ученых-фундаменталистов

 

Что хочется?

Скрестить tarantool И asterisk. : )

6 причин писать диалплан asterisk на lua

Чего мне не хватает в #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?