Проблемы с поиском записей разговоров
Добавлено: 07 ноя 2013, 12:51
Добрый день уважаемые форумчане.
В процессе внедрения и активного изучения и использования 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 и имена записанных файлов. Заранее благодарю за ответы и пинания в нужном направлении)
В процессе внедрения и активного изучения и использования 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 и имена записанных файлов. Заранее благодарю за ответы и пинания в нужном направлении)