Страница 2 из 2

Re: dtmf в текст

Добавлено: 15 май 2012, 19:06
Sfinx
Это мне напоминает построение систем венды и мака - зачем обрабатывать ошибки в системе - пусть их пользователь сам ловит, снаружи. Как это по-нашему ;)

Re: dtmf в текст

Добавлено: 15 май 2012, 19:11
pan-user
хз как по вашему, но по нашему система должна делать только то что ей сказали. сказали позвонить - позвонила. Спросил статус звонка - сказала. Не понравился статус, сказали позвонить еще - позвонила, не сказали - не позвонила.

Что по вашему должно просходить в pbx_spool в случае неудачного звонка ? и где пример 'неущербного' способа ?

Re: dtmf в текст

Добавлено: 15 май 2012, 21:21
Sfinx
Так где же это волшебное место в 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 ...............................

Но зачем делать нормально, когда все уже давно привыкли через ж...

Re: dtmf в текст

Добавлено: 15 май 2012, 21:29
pan-user
еще раз, где пример не ущербного варианта ?


в чем принципиальная разница для пользователя выгребать 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 в текст

Добавлено: 15 май 2012, 23:56
Sfinx
Вы что-то снова путаете - у меня трудностей как раз и нет, так как используется свой вариант pbx_spool. Принципиальная разница в гибкости применения - можно синхронно обзванивать, можно асинхронно, можно под контролем простого демона, можно с наворотами через AMI. А главное - не надо корячить dialplan, чтобы выковырять reason да еще и парится, передавая его в модуль логики обзвона.