Уже некоторое время в недрах Digium идёт разработка нового механизма ведения детализации вызовов — CEL (Channel Event Logging). Он представляет из себя дополнительный способ узнать подробности о конкретном вызове, что скорее дополняет текущие возможности традиционных CDR, а не замещает их (не смотря на название ветви — newcdr). Во-многом необходимость в этой работе «выросла» из необходимости Switchvox в основанной на событиях манере ведения лога звонков (например вот этот скриншот).
Записывая вызовы таким образом мы преследуем две цели, которые часто сложно выполнимы с CDR. Во-первых, возможно точно перечислить всех участников конкретного вызова. К примеру, в Switchvox возможно найти все вызовы в которых учавствовал внутренний номер 800, даже ели это всего-лишь транзитный IVR. Во-вторых, становится возможным точно указать количество разговоров. Даже если в разговоре участвовало 4 сотрудника, использовались переводы вызова — это всего лишь один вызов.
Таким образом требования к CEL: система ведения протокола вызовов общего назначения, которая может обеспечить работу существующих функций Switchvox. Вот описание тех механизмов, которые реализуют механизм CEL:
Во-первых, CEL основан на новой системе событий. Каждый бэкэнд CEL подписывается на событие AST_EVENT_CEL и затем реагирует на них записью каждого события в базу данных или лог-файл. Эта подсистема Asterisk'а спроектирована для работы через сеть, так что будующее CEL — сбор таких событий с нескольких распределённых систем.
Каждое такое событие очень похоже на событие AMI. Если вы когда-либо писали программу для отслеживания вызова по событиям AMI, то вы знаете насколько сложно отслеживать изменения имени каналов или переводы вызовов . Чтобы упростить задачу, murf создал переменную linkedid, который равен самому старому uniqueid любого из каналов, вовлечённых в вызов. Отслеживая linkedid, очень просто понять какое событие какому логическому вызову принадлежит. Чтобы определить конец вызова, имеется событие CEL_LINKEDID_END которое отмечает окончание вызова с данным linkedid.
Так же расширено применение accountcode канала. Теперь переменная больше привязана к каналу, на котором оно определена, и добавлена переменная CHANNEL (peeraccount), которая содержит код аккаунта собеседника. Несмотря на то что это изменяет текущую роль accountcode, это изменение не должно затронуть работу реальных систем. Положительным моментом является то, что теперь гораздо легче определить, какой собеседник участвует в разговоре после серии переадресаций, удержаний вызова и парковок...
И, наконец, последним нововведением является переменная CHANNEL (hangupsource), которая позволяет asterisk'у отслеживать, какой канал или приложение вызвало завершение вызова. К примеру, если SIP вызов завершился устройством, CHANNEL (hangupsource) будет содержать имя канала, получившего SIP BYE. Если в диалплане выполнена функция Hangup (), CHANNEL (hangupsource) будет иметь значение «dialplan/app».
Если вышеописанное интересно вам, то все отзывы и пожелания будут очень интересны.
- Ветвь: SVN
- Оригинал: VentureVOIP
