LINUX.ORG.RU
ФорумAdmin

Привычно-понятное CDR

 , , cel


1

1

Поступает звонок, потом звонок маршрутизируется dialplan`ом или операторами, в итоге проходит звонок через многие exten.

CDR
В cdr это все отражается правильно, но с точки зрения человека, звонок-то один. Как весь этот путь собрать, ведь cdr uniqueid на пути звонка все время меняется?

CEL
В CEL ввели linkedid и да он один на все звонки.

Данные CDR или CEL брать за основу для анализа? Каков может быть алгоритм?

★★★★★

Последнее исправление: petav (всего исправлений: 3)

Ответ на: комментарий от kernelpanic

CDR признан разработчиками глюкавым и устаревшим. CEL пилится ему на замену.

К слову, да. CEL в коммерческом Switchvox направлении был зачат. На скриншоте видна его работа.

Вызов детализации делать из CDR, или напрямую CEL анализировать по совпадению uniqueid и linkedid, а CDR выкинуть. (т.е. если совпадают значит начало разговора.)?

По-моему в диалоге с Вами очевидное мне ранее решение подтвердил. Склоняюсь к анализу CEL.

petav ★★★★★
() автор топика
Последнее исправление: petav (всего исправлений: 1)
Ответ на: комментарий от petav

Я для своих нужд использую собственное логирование из диалплана по типу queue_log. А так да, стоит выбрать CEL. Я в свое время очень долго долбался с CDR в попытках заставить его правильно обрабатывать сложные ситуации (ну как сложные? на трансферах он валится).

kernelpanic ★★★★★
()
Ответ на: комментарий от zgen

объявляй uniqid в начале путешествия и присваивай его ко всем звонкам.

На вскидку, оно кажется read only, но в этом случае можно userfield приспособить, если решить CDR использовать.

petav ★★★★★
() автор топика
Ответ на: комментарий от kernelpanic

Я для своих нужд использую собственное логирование из диалплана по типу queue_log. А так да, стоит выбрать CEL.

Я и пытаюсь понять нужно это, или какие готовые механизмы удовлетворят моим требованиям.

petav ★★★★★
() автор топика
Ответ на: комментарий от petav

На вскидку, оно кажется read only

Безусловно, пихать его после наследования нужно куда-нибудь в иное место, вроде userfield или filename (если речь о записях разговоров).

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

zgen ★★★★★
()
Последнее исправление: zgen (всего исправлений: 1)
Ответ на: комментарий от petav

А ты добавь поле linkedid в таблицу cdr и посмотри, что будет)

kernelpanic ★★★★★
()
Ответ на: комментарий от petav

Я и пытаюсь понять нужно это, или какие готовые механизмы удовлетворят моим требованиям.

Требования перечислить можешь?

kernelpanic ★★★★★
()
Ответ на: комментарий от kernelpanic

Как таковая, задача привязывать к заявкам helpdesk телефонные звонки. Пока в голове это:

Оператор на телефоне

  • В веб-интерфейсе станции кнопка создать заявку по звонку;
  • После щелчка форма с uniqueid и другими поля для заполнения;
  • Потом это все submit в helpdesk;

Специалист поддержки

  • В helpdesk по ссылке с участием uniqueid можно пройти на станцию и почитать, послушать все об этом звонке;
petav ★★★★★
() автор топика
Последнее исправление: petav (всего исправлений: 1)
Ответ на: комментарий от petav

тут еще вопрос, когда оператор нажмет кнопку «зафиксировать звонок» для него в ami Action:Status будет uniqueid другой и следовательно в helpdesk попадет только часть пути звонка, но это легко отработать.

petav ★★★★★
() автор топика
Последнее исправление: petav (всего исправлений: 1)

Вообщем пришел к выводу

  • что разбирать cdr со «стандартным» набором полей достаточно заморочено;
  • разбирать cel тоже не фантан, я не смог по разным кускам cel тестовых звонков ответить на вопрос, кто же снял трубку. Но подробности подробные.

Думаю придется совмещать два способа. Использовать cdr и пользовательские поля в dialplan, а для подробностей анализировать лог cel.

Что приходит в голову это linkedid дописывать в cdr самому на всем пути звонка.
Вот только вопрос как его не потерять (linkedid) при переключении звонка с канала на канал?

petav ★★★★★
() автор топика
Ответ на: комментарий от petav

Вот только вопрос как его не потерять (linkedid) при переключении звонка с канала на канал?

Вроде документация обнадеживает:

This function can be used to set the value of channel variables or dialplan functions. When setting variables, if the variable name is prefixed with _, the variable will be inherited into channels created from the current channel. If the variable name is prefixed with __, the variable will be inherited into channels created from the current channel and all children channels.

petav ★★★★★
() автор топика
17 ноября 2014 г.
Ответ на: комментарий от petav

Безумно приятно возвращаться в темы по проблемным keywords :))

Спасибо!

zgen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.