Mysql CDR asterisk – field only 2kb

С одной стороны наверное, это оправдано, что поле в cdr-запросе не должно быть больше какого-то лимита, т.к. cdr по идее предназначен для обсчета данных по звонку. И много там данных не надо: направление, длительность, статус. В cdr можно даже отключить все данные по неотвеченным или отклоненным звонкам.

Но.. хочется больше. Например, в lua диалплане я готовлю большой файл с данными по звонку, какой пользователь с какого телефонного аппарата звонил на какое-направление. Или поступил входящий номер, был ли он проверен по черному списку, прошел ли ivr, какую букву нажал в ivr, попал в очередь, сколько раз какой агент очереди вызывался. В итоге получается Json поболее 2кб.

Также есть ограничения и cdr_odbc, cdr_pgsql.

В общем, пока выход – использовать func_odbc. Или патчить астериск.

 

Advertisements
Mysql CDR asterisk – field only 2kb

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