Comments 18
скрипт хороший. Но зачем отдавать все во внешнюю обработку, если можно сделать штатными средствами asterisk.
{CURL(https://dsgf.ru/api/RingStat/?status=1&input=${CALLERID(dnid)}&phone=${CI}&client=${HASH(abon,clientid)})&dom=${HASH(abon,domid)}});

здесь я передаю например кучу внешних параметров на сторонний сайт
MYSQL(Query resultid ${connid} INSERT INTO `asterisk`.`message` (`num`, `listen`, `time`) VALUES (${CALLERID(num)}, '1', current_timestamp););

так например сразу можно положить и что угодно в базу.
К сожалению, нет. Из MixMonitor мы не получим продолжительность разговора, начала и конец.
мы его можем получить из CDR и потом положить куда угодно, я например ложу в базу и отправляю на сторонний сервис данные о CDR. CDR
это всего лишь поля куда и как вы их положите не имеет значение, может и в curl обернуть. Я лишь хочу сказать что есть и другие подходы, не используя внешние скрипты
Совсем без скриптов не обойтись, мне ведь необходимо было отправить данные через SOAP. А так не спорю, решение не единственное.
Не очень хорошее решение. В определенных условиях(медленный днс или проблемы коннекта к серверу) может положить сервер телефонии.
Правильное решение — читать информацию из таблички cdr(при необходимости добавочные поля ложить туда же) и делать все что вам надо внешним скриптом.
Говорю по своему опыту, опыта работы с астериском 15+ лет.
Как раз для этого все потенциально опасные операции вынесены в отдельный поток и никак не повлияют на работу asterisk:
        thread = Thread(target=sendCallInfo, args=(caller_id, duration, wav_file, status))
        thread.start()

Единственное узкое место может быть в доступности самого FastAGI сервера. Вполне возможно, что на очень нагруженных asterisk серверах использовать FastAGI вызовет проблемы, но для небольшой организации, которая совершает 200-300 звонков в день, работает без сбоев.
Может и так, но вы сделали много избыточного кода. По сути справляется простой bash скрипт в один поток. Просматриваете cdr старше последнего обработаного, обрабатываете, перемещаете указатель.
Кстати, такие непрофильные сервисы на сервере телефонии надо запускать через nice. Иначе может получится затык в звуке в момент старта конвертации.
Мне не очень нравится идея постоянно опрашивать базу на наличие новой записи, можно кончено триггер повесить на изменение таблицы, но насколько я знаю во встроенной базой asterisk триггер не установить(могу ошибаться), из-за этого пришлось бы складывать cdr в sql базу и пришлось бы обеспечивать бесперебойную работу этой базы. При недоступности sql базы asterisk вообще не сможет работать, а при недоступности fastAGI сервера у нас будут только ошибки сыпаться в лог, а звонки будут работать.
Что касаемо конвертирования в mp3, то лучше её делать вообще на другой машине :) благо fastAGI для этого и делали.
а повесить на базу процедуры при добавлении новой записи? при недоступности базы куда складываются cdr астериск тупо сыпить ошибки и успешно работает
Кто вам такую ерунду сказал? Ядро астериска вообще не зависит от модуля cdr. Если у вас упадет mysql(что ОЧЕНЬ маловероятно), астериск даже не почешется.
В my.cnf добавляете query cache 10M, и вот у вас уже этот скрипт вообще не трогает диск до тех пор, пока не появится новая запись.

Можно и без базы — через tail /var/log/asterisk/cdr-csv/Master.csv |yourscript
у меня есть в обслуживании сервера у которых одновременно столько разговоров идет(200-400), так там такая вещь вероятнее всего его положит. не позволяем такой роскоши…
Не понял, а чем этот «велосипед» лучше, чем, например, штатный модуль CDR Reports у FreePBX и т.д.?
Only those users with full accounts are able to leave comments. Log in, please.