возврат каких ответов? что нажали кнопку? Этоже ЭЛЕМЕНТАРНО, Ватсон!
команда MYSQL, или System, да func_odbc наконец.

System (echo "${EXTEN} OK" >> log.txt)

Хорошо, пойдем длинным путем... У нас есть внешнее приложение, которое отвечает за выборку данных для инициации вызовов. Это приложение выбрало эти данные и начинает генерировать call-файлы. Пусть вызовы идут не через наш *, и мы можем только написать короткий контекст, который проигрывает приветствие и запрашивает подтверждение (к транку до прова мы доступа не имеем).
Какие возможны результаты работы колл-файла ИМХО:
- вызов успешно завершен. подтверждение получено.
- вызов успешно завершен. подтверждение не получено.
- абонент занят.
- в транке нет свободных каналов.
- абонент насвистел при регистрации и номер не существует.
- ошибка в канале.
Вот обработку этих ответов я и хотел бы видеть и контролировать в основном приложении (ибо оно все-таки основное), а не в диалплане, к которому нас могут потом и не пустить.

Вы просто хотите создать вообще отделное внешнее приложение, которое будет востребовано при условии - что нет доступа к диалплану (только как это?). И для этого из "тривиального" решения создать внешнее приложение ...

Alekz:

А без обратной связи, даже для контроля количества одновременных вызовов придется делать дополнительные телодвижения в диалплане, к которому, теоретически, эта система может и не иметь доступа.

В общем то это форум для тех, кто эти самые телодвижения и делает ... И опять о доступе, которого нет ... ;) (что же за заказчик такой)
Контроль количества одновременных вызовов (max) делается в самом скрипте (а так же в настройках транка если это IP и т.д. Это дополнение нужно, если в параметрах call-file задано более одного повтора набора. А так с эти справляется сам скрипт).
Все остальное делается средствами диал.плана (и если нужно - системы) ...

Вы просто не "любите" *nix и диал.план ... ;)

Я хочу, чтобы это решение могло бы быть встроено в существующую систему и при этом основная логика реализовывалась бы в нем. "Доступ к диалплану" имелось ввиду, что нам придется подстраиваться под существующую систему и транки перенастраивать никто не даст.
Если же говорить о том, что мы имеем полный доступ к *, то поставленная задача не стоит выделенного проекта, ИМХО.
cron333, а почему ты решил, что я не "любюлю" никс и диал.план? Почти все я решаю средствами диалплана в своих проектах. Про никс даже не знаю что ответить:)

у каждого свое imho. Для меня удобный автодайлер выглядит именно как отдельное приложение которое я могу запустить у себя на десктопе и в котором я управляю всем процессом начиная со списков обзвона и заканчивая статистикой. Плюс интеграция с CRM.

Воспользуйтесь бритвой Оккама, товарищи.
Вместо того, чтоб за 15 минут сделать приложение, вы полдня будете в муках рожать ваши десктопные заморочки. Доступа к серверу, говорите, нету? а звуковые файлы кто вам туда положит?

Я бы поступил так: скрипт на сервере просматривает таблицу в БД на наличие новых событий отзвона. В диалплан добавляется контекст, который этим отзвоном рулит. Если это freepbx то никаких транков и прочую муть менять не надо. В любое место добавил 30 строк и все. Скрипт формирует через AMI или Сall звонки, с помощью переменной передает имя файлов для воспроизведения. В диалплане функцией mysql или func_odbc в другую таблицу пишется результат. Внешняя программа взаимодействует с астериском только через БД. Такую интеграцию можно встроить практически в любое ПО, в отличии, к примеру, от AGI и AMI (попробуйте их прикрутить к 1С). Делал так неоднократно, работает железобетонно и работа между заказчиком и исполнителем делится примерно поровну (есть за что деньги взять), заказчику не требуется вникать в тонкости AMI и AGI, а заполнять только таблицу. А к этой таблице хоть вебморду, хоть десктопное приложение прикручивай.

Товарисчи, что мы все-таки с чем интегрируем: *+приложение интегрируем в ИС (читай БД) или все-таки приложение в существующую ИС с *?

я думаю делаем так чтоб работало

А если эту фразу формализовать?

я думаю делаем так чтоб работало хорошо.