Комментарии 18
mixmonitor и curl? решит все ваши проблемы
Да MixMonitor, а почему бы и нет? Что Вас смущает?
скрипт хороший. Но зачем отдавать все во внешнюю обработку, если можно сделать штатными средствами asterisk.
{CURL(https://dsgf.ru/api/RingStat/?status=1&input=${CALLERID(dnid)}&phone=${CI}&client=${HASH(abon,clientid)})&dom=${HASH(abon,domid)}});
здесь я передаю например кучу внешних параметров на сторонний сайт
{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(при необходимости добавочные поля ложить туда же) и делать все что вам надо внешним скриптом.
Говорю по своему опыту, опыта работы с астериском 15+ лет.
Правильное решение — читать информацию из таблички cdr(при необходимости добавочные поля ложить туда же) и делать все что вам надо внешним скриптом.
Говорю по своему опыту, опыта работы с астериском 15+ лет.
Как раз для этого все потенциально опасные операции вынесены в отдельный поток и никак не повлияют на работу asterisk:
Единственное узкое место может быть в доступности самого FastAGI сервера. Вполне возможно, что на очень нагруженных asterisk серверах использовать FastAGI вызовет проблемы, но для небольшой организации, которая совершает 200-300 звонков в день, работает без сбоев.
thread = Thread(target=sendCallInfo, args=(caller_id, duration, wav_file, status))
thread.start()
Единственное узкое место может быть в доступности самого FastAGI сервера. Вполне возможно, что на очень нагруженных asterisk серверах использовать FastAGI вызовет проблемы, но для небольшой организации, которая совершает 200-300 звонков в день, работает без сбоев.
Может и так, но вы сделали много избыточного кода. По сути справляется простой bash скрипт в один поток. Просматриваете cdr старше последнего обработаного, обрабатываете, перемещаете указатель.
Кстати, такие непрофильные сервисы на сервере телефонии надо запускать через nice. Иначе может получится затык в звуке в момент старта конвертации.
Кстати, такие непрофильные сервисы на сервере телефонии надо запускать через nice. Иначе может получится затык в звуке в момент старта конвертации.
Мне не очень нравится идея постоянно опрашивать базу на наличие новой записи, можно кончено триггер повесить на изменение таблицы, но насколько я знаю во встроенной базой asterisk триггер не установить(могу ошибаться), из-за этого пришлось бы складывать cdr в sql базу и пришлось бы обеспечивать бесперебойную работу этой базы. При недоступности sql базы asterisk вообще не сможет работать, а при недоступности fastAGI сервера у нас будут только ошибки сыпаться в лог, а звонки будут работать.
Что касаемо конвертирования в mp3, то лучше её делать вообще на другой машине :) благо fastAGI для этого и делали.
Что касаемо конвертирования в mp3, то лучше её делать вообще на другой машине :) благо fastAGI для этого и делали.
а повесить на базу процедуры при добавлении новой записи? при недоступности базы куда складываются cdr астериск тупо сыпить ошибки и успешно работает
Кто вам такую ерунду сказал? Ядро астериска вообще не зависит от модуля cdr. Если у вас упадет mysql(что ОЧЕНЬ маловероятно), астериск даже не почешется.
В my.cnf добавляете query cache 10M, и вот у вас уже этот скрипт вообще не трогает диск до тех пор, пока не появится новая запись.
Можно и без базы — через tail /var/log/asterisk/cdr-csv/Master.csv |yourscript
В my.cnf добавляете query cache 10M, и вот у вас уже этот скрипт вообще не трогает диск до тех пор, пока не появится новая запись.
Можно и без базы — через tail /var/log/asterisk/cdr-csv/Master.csv |yourscript
солидарен с вами полностью.
у меня есть в обслуживании сервера у которых одновременно столько разговоров идет(200-400), так там такая вещь вероятнее всего его положит. не позволяем такой роскоши…
Не понял, а чем этот «велосипед» лучше, чем, например, штатный модуль CDR Reports у FreePBX и т.д.?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Запись входящих звонков