dtmf в текст
Re: dtmf в текст
Это мне напоминает построение систем венды и мака - зачем обрабатывать ошибки в системе - пусть их пользователь сам ловит, снаружи. Как это по-нашему
Re: dtmf в текст
хз как по вашему, но по нашему система должна делать только то что ей сказали. сказали позвонить - позвонила. Спросил статус звонка - сказала. Не понравился статус, сказали позвонить еще - позвонила, не сказали - не позвонила.
Что по вашему должно просходить в pbx_spool в случае неудачного звонка ? и где пример 'неущербного' способа ?
Что по вашему должно просходить в pbx_spool в случае неудачного звонка ? и где пример 'неущербного' способа ?
Re: dtmf в текст
Так где же это волшебное место в call-файле ? Нормально спроектированная система должна выдавать результат своей деятельности, то бишь ошибки там или успех. Если уже пишем в call-file timestamp'ы и текущие счетчики, то где же reason от каждой попытки ? Навскидку неплохо бы иметь /etc/asterisk/pbx_spool.conf в котором бы могли задаваться параметры, весьма актуален, for ex. вид отчета об осуществленных звонках :
report_type = nothing ; default behaviour
report_type = file ; report to the same callfile
report_type = db ; report to the database
report_type = ami ; produce AMI event
.................. etc ...............................
Но зачем делать нормально, когда все уже давно привыкли через ж...
report_type = nothing ; default behaviour
report_type = file ; report to the same callfile
report_type = db ; report to the database
report_type = ami ; produce AMI event
.................. etc ...............................
Но зачем делать нормально, когда все уже давно привыкли через ж...
Re: dtmf в текст
еще раз, где пример не ущербного варианта ?
в чем принципиальная разница для пользователя выгребать reason из failed exten'a или из
report_type = nothing ; default behaviour
report_type = file ; report to the same callfile
report_type = db ; report to the database
report_type = ami ; produce AMI event
?
кому нафиг надо в call файле иметь все эти reason'ы ? результат выдается, если вы не знаете место где его забрать то это лично ваши трудности.
в чем принципиальная разница для пользователя выгребать reason из failed exten'a или из
report_type = nothing ; default behaviour
report_type = file ; report to the same callfile
report_type = db ; report to the database
report_type = ami ; produce AMI event
?
кому нафиг надо в call файле иметь все эти reason'ы ? результат выдается, если вы не знаете место где его забрать то это лично ваши трудности.
Re: dtmf в текст
Вы что-то снова путаете - у меня трудностей как раз и нет, так как используется свой вариант pbx_spool. Принципиальная разница в гибкости применения - можно синхронно обзванивать, можно асинхронно, можно под контролем простого демона, можно с наворотами через AMI. А главное - не надо корячить dialplan, чтобы выковырять reason да еще и парится, передавая его в модуль логики обзвона.
