Проблемы с поиском записей разговоров

[enot]

Добрый день уважаемые форумчане.
В процессе внедрения и активного изучения и использования Elastix столкнулся с небольшой проблемой,решить которую самостоятельно не получилось.
Настроена запись всех разговоров, как входящих так и исходящих. Она исправно работает, пишутся абсолютно все разговоры. Проблема возникает при поиске этих записей. Дело в том, что Elastix добавляет в таблицу CDR(а соответственно и во вкладке Monitor Эластикса) информацию о звонках немного некорректно, а именно иногда для двух звонков (конкретно в случае переключение вызова с одного ext.номера на другой без ожидания пока человек на которого переключили возьмет трубку, проставляются одинаковые uniqueid и userfield т.е. фактически создаются два файла записи:разговор "до переключения" и разговор "после переключения" вызова, но при этом в двух созданых записях в таблице CDR прописываются одинаковые uniqueid и userfield для обоих разговоров ). Приведу реальный пример и цепочку событий чтобы представить свои мысли более понятно.

1)Звонок с номера 354 на номер 312, номер 312 снимает трубку, идет разговор, номер 312 переключает звонящего на номер 353, для номера 354 идет статус hold,играет музыка ожидания, номер 312 дожидается первого гудка и кладет трубку, номер 353 снимает трубку говорит с 354 звонок заканчивается. В итого имеем следующее, две записи в таблице CDR:

время: 20:31:40 от кого: 354 кому:312 uniqueid:1383748300.161918 длительность 13 секунд
время: 20:31:53 от кого: 354 кому:353 uniqueid:1383748300.161918 длительность 9 секунд

При всем при этом создается еще один файл записи 1383748300.161920 в котором записана вторая часть звонка длительность которого 9 секунд но при этом он вообще никак не находит uniqueid=1383748300.161920 в базе asteriskcdrdb и не получается нормально без трудностей отыскать этот файл чтобы прослушать вторую часть разговора.

Если же переключающий дождется момента когда тот на кого он переключает снимет трубку и потом их соединит, то создаются две записи со своими uniqueid и они же корректно отображатся в журналах мониторинга и CDR. Кто-нибудь сталкивался с подобными ситуациями? Есть ли разумный выход кроме нудных поисков файлов через фтп клиенты, и совсем не хочется заставлять всех сотрудников(около 50 человек) в обязательном порядке дожидаться пока тот на кого они переключают снимет трубку, чтобы в мониторингах и журналах отображались корректные uniqueid и имена записанных файлов. Заранее благодарю за ответы и пинания в нужном направлении)

[awsswa]

В последнем FreePBX вроде решили эту проблему - там список открывается где видно путь звонка и все записи.
Но это с чужих слов, сам не проверял

[zzuz]

Ага. Мопед не мой , я просто объяву разместил))

[enot]

Смотрел новую версию FreePBX на одном из последних установленных, если честно также кривовато отображается менюшка прослушивания записей, либо совсем эти записи не дает послушать, либо ругается что слишком много файлов в директории... Просто интересно ведь неверные записи в таблицу CDR(userfield) делает сам asterisk, пихает в оба звонка ссылку на аудиозапись первой части разговора, не смотря на то что фактически записывает оба, проблема с дальнейшим поиском этих разговоров довольно не малая.

[awsswa]

обе ошибки говорят о том что php.ini настроен криво