Это не работает на не бриджованных каналах. Я хотел до бриджа на легА поднять трубку, поигрывая файл перейти дальше в диаплплан. И только потом бридж.

а разве нельзя установить moh и сделать трансфер?

Да, только не moh, а ringback. звонок-то еще не отвечен

ну да, я это и имел ввиду

ну так это и работает. можно из диалплана вызвать api после answer()

Вообще, во фрисвиче возможности параллельного исполнения нескольких задач в одном звонке довольно ограничены. Если Вы предвидите такую необходимость выходящую за пределы "проиграть параллельно - записать параллельно - повесить луа/питон/etc-хук на событие", лучше сразу смотрите в сторону ESL + параллельный демон, исполняющий задачи управления бизнес-логикой.

Я думал обойтись малой кровью. Спасибо, посмотрю.

новый уровень демонстрации технологий

Классный формат, на конференциях о Камаилио тоже есть такой формат, тоже есть веселые моменты

Добрый день.
Подскажите, как выцепить текст Reason'а из сообщения BYE?
Интересует Text: Call completed elsewhere.
getHeader, наверное, а дальше?

Коллеги, возвращаясь к теме записи звонков.
Имеется система высокой доступности из двух FS - основной и резервный. При падении. основного резервный подхватывает активные звонки.
Есть ли какое-то решение, как при этом организовать запись - чтобы получить файл с звуковыми данными до и после падения?

у вас так часто падает fs?)
а он впринципе продолжает писать после переключение на другой?

Насколько помню sip_call_id будет совпадать. Можно найти по нему записи и смержить их в нужном порядке

Но это не единственный вариант, скорее самый простой

Чесно говоря, после переезда на амазон не падал ни разу, но хочется сделать таки законченное решение.
Когда-то давно такое делали - именно для этого писали в wav и потом большим и хитрым скриптом склеивали.
Помню, была куча трудностей, а сейчас опять надо - вот и думаю - вдруг кто-то тоже заморачивался.

Да-да, в этом направлении и копали.

Формально - нет. Поскольку при падении fs файл будет битый с вероятностью "наверняка" (данные сбрасываются на диск ОС через буферы, размер которых никогда не кратен размеру скидываемых с каждым пакетом данных + есть заголовки, которые так же будут хаотично сдвигать эти границы и это если вы используете формат с постоянной длинной фрейма при записи, что, например, уже не соответствует mp3), соответственно, продолжать писать в этот файл - получить нечитаемый мусор на выходе. Это что касается непосредственно сбрасывания данных. Если же Вы как-то решите эту проблему (например, Вы будете писать на удаленную FS, типа GFS и иже с ними), то время закрытия протухшего дескриптора доступа к файлу распределенной файловой системой по таймауту у вас будет БОЛЬШЕ времени переподнятия FS (если все организовано хорошо), в следствие чего FS скорее всего получит от файловой системы отлуп при попытке открыть этот же файл на запись. И это только то. что сразу приходит в голову. То есть, у Вас в любом случае будет ДВА файла, мердж которых не будет тривиальной автоматизируемой задачей.

Алексей задал очень хороший вопрос: какой надежности системы Вы пытаетесь добиться? Стандартные 99,999 достигаются и без таких извращений. Если у Вас фрисвич падает часто, то это повод пересмотреть способ его использования...

Проблема битого файла решается - если писать wav то битость не влияет - файл читается.
Я понимаю, что какая-то часть данных пропадет, но какая-то и останется.
Насчет надежности системы - тут вопрос не об этом и все методы убедить заказчика чт о ему это не нужно. исчерпаны.
Да я и сам считаю, что надо предпринять меры для восстановления звуковых данных, например, путем склеивания из обрезков, более того, несколько лет назад так делали.
Просто я думал что уже есть готовое решение.