Пытаюсь написать утилиту, которая, используя *, соединялась бы по заданному каналу, проговаривала указанный gsm файл, а затем отправляла бы на факс указанный tiff. Поскольку необходим контроль состояния самого процесса передачи, приходится использовать ami, а не call файлы.
Я решил пока эту задачу с пом. originate с переходом в заранее приготовленный в extensions.conf контекст, где запускается playback, а затем sendfax.
Вопрос: возможно ли сделать то же самое с помощью одного только ami, не внося никаких изменений в extensions.conf? Т.е., скажем,
1. отослать пакет originate, в котором указывался бы файл для воспроизведения в качестве параметра A(...) для Dial, а также приложение sendfax с указанным файлом для передачи.
или
2. отослать такой originate, который запускал бы последовательно два приложения: playback и sendfax

Если у кого-нибудь есть опыт управления * через ami, подскажите пжлст.

без изменений не выйдет
если использовать hylafax то все будет проще, hylafax сам будет отправлять на почту оповещения.
Я таким образом настроил факс-прокси в одной конторе

Нет, такой вариант не подходит: мне нужно мониторить процесс передачи в режиме онлайн

и что вы мониторите? факт отправки сообщения? а факт доставки?

а вы и будете онлайн мониторить
хилыйфакс ведет логи, есть asterfax, в котором процесс тоже отображается.

Факт успешной отправки я приравниваю к факту успешной доставки (а разве не так?). Я получаю и анализирую ami events, всякие там FAXSTATUS, FAXERROR, FAXPAGES, FAXBITRATE, FAXRESOLUTION и другую требуху. Проблема лишь в том что, app_fax инициализирует их до начала передачи, и затем уже после, когда получает управление из spandsp. Мне говорят, что надо бы мониторить и сам процесс отправки, а именно какая страница сейчас отправляется, но здесь нужно уже править spandsp (о-о-очень не хочется, попробую отбиться).

switch:

а вы и будете онлайн мониторить
хилыйфакс ведет логи, есть asterfax, в котором процесс тоже отображается.

зачем я буду анализировать какие-то левые логи? Я получаю по каналу ami всю необходимую информацию в виде response-ов и event-ов.

Слава богу, править spandsp не пришлось: как выяснилось, там есть уже готовая функция t30_get_transfer_statistics, которая возвращает состояние передаваемого факса (текущее число переданных страниц, общее кол-во страниц, скорость, разрешение и т.д.). Так что просто вставил в app_fax.c в цикле отправки фреймов вызов t30_get_transfer_statistics и генерацию информационных ami events и теперь всё это сыпется на порт 5038. Теперь отправка факса идёт прямо на глазах: 1-я страница ушла, 2-я ...

круто, хорошая идея