freeswitchforum.com

Ребята привет.

Вот такая задачка у меня имеется.
Мне надо определить, закончился разговор на этом пользователе, или он перевел звонок другому абоненту. Т.е. у меня в статистике на звонок с одним переводом будет две записи. a->b и a->c. И надо пометить звонок a->b как звонок окончившейся переводом на другого абонента.

Сравнивал три вывода info:
1) a->b(hangup)(info)
2) a->b(transfer)(info)->c
3) a->b(transfer)->c(hangup)(info)

В варианте 2 и 3 присутствуют variable_transfer_history и variable_transfer_history. Причем они одинаковы. Т.е. по ним можно определить что перевод был, но нельзя определить завершился разговор или продолжается дальше, но с другим абонентом.

Думал оттолкнуться от переменной variable_originated_legs, но тогда как определить что пользователь C положил трубку, а не перевел звонок, так как у него присутствуют variable_transfer_history и variable_transfer_source. и они не отличаются.

Есть предположение использовать
Channel-State: [CS_EXECUTE]
Channel-Call-State: [ACTIVE]
Channel-State-Number: [2]

При звонке с трансфером код состояния равен 2, при обычном звонке(финальном) код состояния равен 4. Предполагаю что это [2] - CS_ROUTING и [4] - CS_EXECUTE
Придумано вот отсюда https://wiki.freeswitch.org/wiki/Channel_States, отсчет начал с 0.

Я придумал корректный способ определения состояния? Или есть более правильный и красивый?

_________________
Если бы я был админом одной организации, я бы сделал все по другому.....

смотрите cdr в режиме ab

_________________
ЛС: @rostel
Сообщество: @ru_freeswitch

Я так понимаю, что cdr в ab это не совсем то что надо
В спойлере звонок a->b->c


не совсем понятно как использовать данную информацию. И еще одно уточнение. У меня диалплан на питоне(интеграция с билингом, так сказать), и считывать статистику вне текущего скрипта не совсем хотелось бы, так как использую для статистики не cdr, а свой формат со своим велосипедом.

А почему не корректно использовать мой вариант с Channel-State-Number? Просто я инфы никакой не нашел, вот и спрашиваю у бывалых.

Спасибо.

_________________
Если бы я был админом одной организации, я бы сделал все по другому.....

cdr - это совсем то что нужно
смотреть надо в xml_cdr, долго сравнивать для поиска нужных переменных
потом пытаться отыскать их пока вызов ещё не завершен

_________________
ЛС: @rostel
Сообщество: @ru_freeswitch

а по поводу моего вопроса: вроде нашел параметр который мне подходит

Только мне надо ее прочитать в канале перед его завершением, а в этот момент значение переменной endpoint_disposition всегда равно ANSWER. получить нужное значение можно только если сделать hangup каналу(я так предполагаю), но в этом случае сбрасывается и звонок, который переадресовывается.

Т.е. получается что надо или использовать пост анализ CDR-ки или опираться на параметр Channel-State-Number, и смотреть когда у него значение равно 2

Или можно как то принудительно заставить cdr считать что данный канал завершен и надо сбросить статистику по каналу(предполагаю что и значение переменной endpoint_disposition тоже изменится)?

_________________
Если бы я был админом одной организации, я бы сделал все по другому.....

внимательно посмотрите на все поползновения по диалплану в момент трансфера
если нет однозначных штатных переменных, вставьте свои в нужное место

_________________
ЛС: @rostel
Сообщество: @ru_freeswitch

Просмотрел все вдоль и поперек. И наполовину решил задачку.
Объявил hangup_hook, и в нем передается статус hangup или transfer. Но как всегда есть одно НО!

Кейс 1:


Кейс 2:


Как в этом случае обойти не совсем понятно.
И еще, а как можно перехватить реакцию свитча на переключение в холд и получение refer пакетика? Что бы можно было что то выполнить в этот момент(к примеру выставить статус экстеншену)

_________________
Если бы я был админом одной организации, я бы сделал все по другому.....

а дальше полный фарш с их анализом

_________________
ЛС: @rostel
Сообщество: @ru_freeswitch

Ваш вариант хороший, я о нем думал после Вашего первого комментария насчет xml_cdr. Только вот я не понял как именно получить готовый набор cdr в текущем канале, а не после его завершения. Если рассматривать пост обновление данных с разбором файла(или получения данных по url), то этот вариант лучший. К тому же, полная картина будет созранена только после того, как будет завершен канал b
По крайней мере я по трем созданным файлам увидел такую картину.
Первый файл создался сразу после перевода a->c. В нем нет никакой информации по трансферу
Второй и третий файл создались после завершения каналов b и c. В с видно что на него перевели с a. В b видно полное движение всех переводов(referer, callflow и т.д.)


Но я вроде решил вопрос. Не факт что самым правильным способом, но по крайней мере попахивает логичным решением.
hangup_hook + variable_endpoint_disposition. В первом случае hangup_hook даст transfer а variable_endpoint_disposition ANSWER, во втором случае hangup_hook даст hangup а variable_endpoint_disposition BLIND_TRANSFER.

Т.е. так как хочется....

Спасибо за подсказки и участие.

_________________
Если бы я был админом одной организации, я бы сделал все по другому.....

первые три переменные доступны в канале

когда прилетает hangup зависит от того кто переводит

_________________
ЛС: @rostel
Сообщество: @ru_freeswitch