а бриджинг происходит до или после того, как обе сессии в answered state?

Ток откуда оно вылезло - не очень понятно.. да и не суть на данный момент.

там чутка тайминг разъехался... ну нету 480 )

да, конечно

есть звонки где разговор состоялся, но записи нет.

вот это еще интереснее )

Походу разобрался...  Привет буфферу записи FS и идее определения окончания записи в файл по его timestamp, с последующей конвертацией )))

Пасибо что откликнулись )

т.е. он 30 секунд ничего не скидывал на диск... создал файл и все. Правда хз - потом скинул бы или нет... этого я уже не узнаю )

если честно, не понял

Есть 2 процесса: FS, который что то делает + конвертор. Они друг о друге ничего не знают (дадада.. есть ESL и т.д., но тут вот так :) )
У конвертора все просто: если файл записи некоторое время не изменяется (в моем случае 30 секунд) - то считаем что все, данных больше не будет. Берем файл, конвертим, сохраняем куда надо и удаляем исходник...
В данном случае - FS создавал файл для записи, но почему то 30 секунд ничего в него не складывал.. подобное поведение мы встречали на одном из проектов и разбирались с этим: там у него есть какой то буффер.. подробностей не помню.

Ну и конвертор благополучно, не видя изменений в файле - его забирал, видел что он 44 байта и мочил его.

Спасибо за интересный кейс, теперь я так точно никогда не буду делать :D

Т.е. моя паника, на тему "FS не пишет" - скорее всего - не корректна

я походу тоже ))))

Не хочет. Полный анализ у них только в rtpAgent коммерческом. Rtcp прекрасно разбирает, если включены генерация (фс генерит только по принятому) и сбор - в captagent помнится какая-то конфигурационная магия была нужна. Но то, что вижу у себя весьма прискорбно скудно.

Может использовать hep как переходный вариант, но у них и собственный протокол есть.

спасибо за ответ.

вот это интересно, где можно почитать что у него есть hep?