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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• В helpdesk по ссылке с участием uniqueid можно пройти на станцию и почитать, послушать все об этом звонке;

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

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

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

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

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

Вот только вопрос как его не потерять (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.

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

Спасибо!