Понимаю что мб странно, т.к. везде пишут о реализации диманических IVR только через базы, но не хочется пускать * к общей корпоративной БД, а заводить и сопровождать отдельную базу - сомнительное удовольствие.

Общая задача: реализовать генерацию индивидуального диал-плана (IVR) для юзера при его попадании на канал.

Варианты:
1.Через запись в базу - отбрасывается :( по вышеприведенным причинам.
2.Менять содержимое #inсlude file и перечитывать весь диалплан - накладно до крайности.
3.Вызывать AGI скрипт, в котором был бы реализован диалплан - накладно получается столько тех же Perl'ов держать уж очень :(. но пока выглядим самым реальным.

Прошу совета знатоков :)

П.С.планируемая нагрузка - в несколько сотен одновременных звонков.

я бы реализовал диалпланом + odbc + БД. в БД информация попадает из корпоративной системы. один раз так делал, получилось хорошо и "изящно".

спасибо,
но все-таки хотелось бы без обращения к базам такое сделать, исключительно на файлах/процессах.

хотя... а знаете, вполне подойдет вариант небольшой базы.
но вот что полегче и независимей взять?

нативную asteriskdb

Входящий звонок направляй сразу в свой AGI скрипт, в котором реализуй следующую "магию".
Главное меню - /var/lib/asterisk/menu.
В этой папке подпапки 1 2 3 и тд в зависимости от того, какие цифры задействованы.
Также в этой папке файлы 1.wav, 2.wav, и тд, которые подряд проигрываются. Можно положить туда файлик dial, в котором указать номер для набора. В общем, imagine some magic, а скриптом гулять по папкам-файлам очень просто. Один раз сделал, потом только программируешь IVR в mc :-)
Если решишь пойти по этому пути, пиши litnimax(at)asterisk-support.ru, сделаем вместе. Придумаем ТЗ, по которому ты все сделаешь. Результат красиво оформим на вики.

Я даже тикет создал - http://asteriskpbx.ru/ticket/54
:-)

спасибо за советы ^_^
насчет нативной бд - а как реалтайм на нее натравить напрямую? 0.о
или если положить экстеншн в эту бд, то оно сразу оказывается загружено/доступно? 0.о (ссори что спрашиваю, а не сам проверяю - перед выходными завал Х) )

litnimax, это будет означать висящий скрипт в системе. а если их штук 700 ? ;) Вообще давай спишемся - обсудим варианты, уже вторую неделю прикидываем с народом как лучше сделать решение под большую нагрузку :).

AGI - не промышленное решение, надо использовать FastAGI, и в идеале выносить FastAGI сервер на другую машину. Ну а если очень надо на одной, то тогда следует использовать асинхронный подход, где все задачи выполняются в рамках одного постоянно запущенного процесса (это чтобы не затрачивать ресурсы на форканье новых процессов).
Какие будут еще вопросы? :-)

FastAGI все равно означает несколько сотен процессов :) А хотелось бы их поменьше.
А асинхронность будет достигаться самим кодом же, а не какими-то фичами * ? Тогда это уже вопрос программирования и затрат времени. :(
Я лично даже не совсем понимаю как сделать такую работу асинхронной Х) Все равно threads будут сотнями, что хоть и не процессы, но все же.

Кстати, к теме удаленности - а базу для реалтайма можно удаленно держать?