Длительность разговора 0 при реально принятом звонке

[adgroup]

Следующая проблема в V12.5.44178 SP2 (существует давно, последних года 2 точно, но тяжело было найти куда "копать"). У ряда входящих звонков после того как звонок приняли в WebCallReporter и в файле calls.txt в папочке cdrsingle пишется длительность разговора 0, а длительность звонка при этом равна суммарному времени фактическому потраченному на звонок+разговор. Таким образом при обработке протоколов звонков нашей CRM системой получается что звонок пропущенный, так как длительность разговора 0. После последних тестов было выявлено что данная проблема наблюдается если согласно правилам входящий звонок попадает на автоответчик, далее через голосовое меню поступает уже на внутренний номер. Если же перенастроить правила и входящий звонок сразу принудительно направлять на какой либо из внутренних номеров то длительность звонка и длительность разговора фиксируется корректно. Вот кусочек протокола из файла calls.txt
Call 98339,00000BE670EE94FA_5,,180815095107,,8/18/2015 9:53:39 AM,10010,800,800,10010,0, 0,1,1,+380676573713,receiver,+380676573713,702,1,0,0,,,0
2
CallDetail 0,98339,-1,800,800,8/18/2015 9:51:07 AM,00:00:23.3300000,8/18/2015 9:51:07 AM,Completed,True,None,False
CallDetail 1,98339,0,702,702,8/18/2015 9:51:18 AM,00:02:20.7300000,,NotAnswered,True,None,False
Здесь видно, что автоответчик обработал, передал вызов на внутренний номер, а внутренний номер NotAnswered, хотя по суммарной длительности разговор был чуть более 2 минут. Кто-то сталкивался с такой проблемой?

 

[pojidaev]

По логам получается, что на входящий вызов никто кроме автосекретаря (800) не ответил (NotAnswered), хотя звонок поступал на номер 702 2мин и 20 сек. А раз не было ответа, то и время разговора получается нулевым. Вроде все логично....

 

[adgroup]

Логика заканчивается на том моменте что на 702 я лично принял этот звонок и проговорил по телефону те самые 2:20, а в файле NotAnswered

 

[igorsnezhko]

Насколько я знаю, 3CX учитывает в статистике только параметры первого ответа. Т.е. Длительность вызова и разговора считаются только для первого ответившего. В вашем случае это был автосекретарь. Остальные переходы этого вызова статистикой игнорируются.

 

[adgroup]

Если так, то это некорректно.

 

[igorsnezhko]

3CX говорит, что это сделано ради упрощения и уменьшения нагрузки на ядро системы.

 

[adgroup]

Это наверно не для данной темы ответ, а для темы про CDR, так как корректная фиксация пропущенных звонков (игнорирование автоответчиков, очередей вызова, ring group) врядли может нагрузить ядро системы.

 

[igorsnezhko]

В принципе, да, я хотел сказать, что 3cx не тратит ресурсы на отслеживание всего пути вызова, включая все переходы.

 

[adgroup]

Хорошо, поставим вопрос по другому, нам (думаю не только нам, и Вам тоже) важно чтоб ни один звонок от клиента не остался не отвеченным. Если утверждение верно, то как нам решить эту задачу если АТС которая занимается управлением звонками не в состоянии это сделать (по заявлениям разработчиков пропускать через себя пару сотен одновременных вызовов на типовой машине она в состоянии, а при принятии решения если звонок был принят "сервисным" номером а не реальным внутренним абонентом - нехватка ресурсов, не странно ли).

 

[igorsnezhko]

Мне сложно сказать, почему было принято такое решение. Может быть, нехватка возникает при 1024 звонках. А может быть, это просто некое упрощение, т.к. 3CX не позиционирует себя как колл-центр пока.

 

[adgroup]

И так не получается, еще раз перефразирую. Допустим система считает этот звонок отвеченным по своим соображениям, но если звонок отвеченный и допустим это "правильно" по соображениям системы, почему длительность разговора 0 секунд у отвеченного звонка (кусок лога я приложил)?

 

[igorsnezhko]

Попробуйте написать на английком на международном форуме, его просматривают разработчкики. https://www.3cx.com/forums/3cx-phone-system-general-f1.html?sid=28bbe29645e00c362beaa05190fc8c21

 

[adgroup]

Уже удалось читать протокол звонков напрямую из базы в 14 версии а также удалось обойти данную проблему с помощью ряда вспомогательных данных полученных из базы, также есть подозрение (пока не могу сказать точно), что данная проблема была решена в версии 14 (за неделю ее работы таких проблемных звонков не зафиксировано, ранее их было десяток каждый день). То есть такие проблемные звонки не наблюдаются пока в протоколе, который формировался в версии 14, но протокол велся не с нуля, а за несколько лет, он просто был преобразован автоматически при установке 14 версии. Также что-то намудрили разработчики с преобразованием, все данные о фиксации времени звонка (дата, время начала, конца, ответа ...) были повторно преобразованы из местного времени в UTC, то есть до этого версия 12.5 и так протокол вела в UTC, а теперь при обновлении на 14 прошло повторное преобразование в UTC и любой звонок, сформированный до 14 версии должен согласно моему часовому поясу (UTC+3) отставать от текущего времени на 3 часа, а теперь отстает на 6 часов. Но это для меня не критично, хотя неприятно. Можно написать запрос и вручную преобразовать в базе, но это на потом.