cdr | База знаний |

Что такое cdr анализ в voip терминации?

Аббревиатура CDR расшифровывается как Call Detail Record или Сharging Data Records (запись деталей о вызове/запись данных о списании). Сервис широко применяется в телекоммуникационном бизнесе, в частности, в сфере VoIP терминации. Его главная функция — это журналирование работы VoIP оборудования.

CDR используют при расчете стоимости звонков, для оценки рациональности проведения трафика, а также диагностировании проблем в работе системы и выполнении определенных настроек оборудования. Как правило, CDR-сервис работает совместно с биллинговыми программами для терминации.

Сервис CDR, как правило, встроен в VoIP оборудование по умолчанию. Также он предусмотрен в Asterisk сервер voip. Программа создает записи по звонкам в __/var/log/asterisk/cdr-csv. Все записи доступны для чтения в файле Master.csv.

CDR обычно содержат следующую информацию о вызовах:

  • Инициация звонка;
  • Назначение звонка;
  • Время запуска вызова;
  • Время фактического подключения;
  • Время завершения звонка.

На основании данных из записей CDR подсчитываются такие показатели, как ACD и ASR, характеризующие среднюю продолжительность звонков и соотношение успешных/неуспешных вызовов. Они свидетельствуют о качестве VoIP связи. Также CDR, как правило, ведет журнал подсчета “нулевых звонков”.

Существует также сервис CMR (Call management records), обеспечивающий журналирование данных о качестве обслуживания VoIP (QoS) и диагностические сведения о вызове. Записи CMR содержат следующие данные по звонкам:

  • Значение джиттера (“дрожание цифрового сигнала”);
  • Количество принятых и переданных данных;
  • Задержки при доставке данных;
  • Процент потери пакетов трафика.

Анализируя эту статистику, вы сможете делать выводы об эффективности работы вашей VoIP системы и предпринимать соответствующие меры для повышения продуктивности GSM терминации.

Источник

Почему?

😪Мы тщательно прорабатываем каждый фидбек и отвечаем по итогам анализа. Напишите, пожалуйста, как мы сможем улучшить эту статью.

Cdr: описание полей

Поле Значение/Пример Описание
accountcode 54321 Код аккаунта присвоенный абоненту, для биллинга например. По умолчанию не задан.
src8129981138Идентификатор вызывающего абонента(Caller ID). Источник вызова, сохраняется автоматически. R/O
dst111Пункт назначения вызова.Вызываемое расширение диалплана.
dcontextfrom-internalКонтекст назначения обработки вызова. auto, R/O
clid“Olegus” <81239981138>Caller ID вызывающего абонента в полном формате – “name” <number>. auto, R/O
channelSIP/0004F2040808-a1bc23efКанал инициатор вызова. A-leg(side).auto, R/O
dstchannelSIP/0004F2046969-9786b0b0Канал назначения вызова. B-Leg(side).auto, R/O
lastappDialПриложение обработки вызова выполненное последним в канале. auto, R/O
lastdataSIP/0004F2046969,30,tTДанные (например ‘Dial(данные)’) приложения выполненного последним.auto, R/O
start2022-05-27 12:02:00Время поступления вызова вызова. auto, R/O
answer2022-05-27 12:02:15Время ответа на вызов абонентом или ответ приложения. auto, R/O
end2022-05-27 12:08:15Время окончания соединения.Hangup. auto, R/O
duration195Общая продолжительность вызова в секундах.auto, R/O
billsec180Продолжительность соединения в секундах с момента ответа(снятия трубки или выполнения команды Answer в диалплане).auto, R/O
dispositionANSWEREDСостояние обработки вызова. Может быть: NO ANSWER, FAILED, BUSY, ANSWERED или UNKNOWN.
amaflagsDOCUMENTATIONAutomatic Message Accounting (AMA) flag. значения: OMIT, BILLING, DOCUMENTATION или Unknown.
userfieldcustomПользовательское поле. Пусто по умолчанию, назначается в диалплане. set(CDR(userfield)=<value>). R/W
uniqueid1288332400.1Уникальный идентификатор канала. R/O

Call detail record

Call Detail Record (сокр. англ. CDR — Подробная Запись о Вызове (ПЗВ); возможна расшифровка Charging Data Records — записи данных о списаниях) в телекоммуникационной сфере — сервис, обеспечивающий журналирование работы телекоммуникационного оборудования.

Cdr. сохранить и приумножить

Очень часто, созданию базы данных CDR отводится мало места в описаниях настройки. Как правило, все сводится к цитате SQL команд и обещанию, что если кинуть ее в консоль то «все будет ОК».

К примеру, первая же ссылка в гугле рекомендует создать табличку таким образом:

Сразу можно обратить внимание, что как минимум два индекса в базе бесполезны. Это calldate и accountcode. Первый в силу того, что при ежесекундном добавлении записей, размер индекса будет равен количеству записей в самой базе. Да, этот индекс отсортирован, и можно применить некоторые способы к ускорению поиска, но будет ли он эффективен?

Почти 10 минут ожидания.

Другими словами, создание отчетов становится проблемой. Конечно, табличку можно ратировать, но зачем такие жертвы, если достаточно провести оптимизацию.

Внимание! Никогда не делай это в продакшене! Только на копии базы! База лочится на время от 1 часа до нескольких и возможны потери данных при аварийном завершении!

Итак, два шага к успеху эффективного хранения CDR:

  1. Разбить на партиции, чтобы ускорить выборку по периодам
  2. Эффективное индексирвоание

Шаг 0. Выбор движка хранения

Собственно есть два распространенных варианта — MyISAM и INNODB. Холиварить на эту тему можно бесконечно долго, но сравнение движков на реальной базе дало перевес в пользу MyISAM.

Причин тут несколько:

  • При чистой настройке сервера неопытным админом, именно MyISAM более корректно работает при индексации больших объемов. В то время, как INNODB требует тюнинга. В противном случае можно увидеть интересные ошибки о том, что индекс не может быть перестроен
  • MyISAM при включении опции FIXED ROW приобретает дополнительные свойства, а именно:
  1. Устойчивость к сбоям даже при падении сервера
  2. Возможность читать файл напрямую из внешнего приложения, минуя сервер MySQL, что бывает полезно
  3. Скорость обращения к рандомным строкам выше, за счет того, что все строки имеют одинаковую длину

Другими словами, для логирования лучше всего (ИМХО) подойдет MyISAM.

Остановимся на нем.

Cdr_adaptive_odbc

cdr_adaptive_odbc.conf

Как следует из названия, модуль cdr_adaptive_odbc сохраняет CDR в базу данных через ODBC. «adaptive» в данном случае означает, что она пытается приспособиться к структуре таблицы: нет статической структуры таблиц, которые должны быть использованы с этим модулем.

Когда модуль загружен (или при перезагрузке), он читает структуру таблицы. Он ищет имя столбца, которому соответствует переменная CDR. Это относится как к встроенным CDR переменным, так и к пользовательским переменным.

пример:

Cdr_csv

Модуль cdr_csv простейший бакенд, сохраняющий CDR данные в CSV файл, разделяя запятой. Конфигурация находится в файле cdr.conf


Для работы не требует конфигурации, тем не менее есть несколько параметров:

Порядок CDR переменных в CSV файле созданном модулем CDR_CSV:

Cdr_custom

Данный модуль используется для создания пользовательского (custom) CSV файла. Конфигурационный файл модуля cdr_custom.conf. Единственная секция [mappings] может быть использована в этом файле. Шаблон задается с помощью функций диалплана Asterisk.

В следующем примере cdr_custom создает файл /var/log/asterisk/cdr-custom/Master.csv. Шаблон использует функции function ‘CDR'() для извлечения значений и
function ‘CSV_QUOTE'() обеспечивающую правильное форматирование CSV файла (${CSV_QUOTE(${CDR(lastdata)})}).

Cdr_manager


Модуль cdr_manager интерпретирует данные CDR, как события Asterisk Manager Interface (AMI). Конфигурационный файл – cdr_manager.conf.

Первая секция [general] содержит единственную опцию enabled, по умолчанию = no.

[general]
enabled = yes

Следующая секция cdr_manager.conf это [mappings]. Здесь назначается пользовательская CDR переменная передаваемая менеджеру Asterisk.

пример:

 [mappings]
 rate => Rate
 carrier => Carrier


В данной конфигурации заданные переменные появятся как события в интерфейсе менеджера. Источником событий станет следующий диалплан:

 exten => 177,1,Answer()
     same => n,Set(CDR(rate)=0.03)
     same => n,Set(CDR(carrier)=BВ&С)
     same => n,Hangup()

Следующая команда инициирует вызов:

*CLI> console dial 177@test

asterisk:alsa.conf

В итоге, следующее событие отобразится в Asterisk Call ManagerFinally:

Cdr_mysql

Cdr_odbc

Файл конфигурации – cdr_odbc.confМодуль для сохранения CDR через ODBC драйвер. В новых системах рекомендуется, по возможности, использовать модуль cdr_adaptive_odbc.

Cdr_pgsql

Файл конфигурации – cdr_pgsql.confМодуль для сохранения CDR в базу данных PostgreSQL. В новых системах рекомендуется, по возможности, использовать модуль cdr_adaptive_odbc.

Cdr_radius

cdr_radius бакенд связывает CDR с Radius сервером. Используется конфигурационный файл cdr.conf в секции [radius].

Cdr_sqlite

Устарело. Используйте cdr_sqlite3_custom.

Cdr_sqlite3_custom

CDR бакенд для сохранения данных в SQLite БД версии 3. База данных создается модулем, как /var/log/asterisk/master.dbДанный модуль использует конфигурационный файл cdr_sqlite3_custom.conf.

[master]

table = cdr

;
; List the column names to use when inserting CDRs.
;
columns => calldate, clid, dcontext, channel, dstchannel, lastapp, lastdata,
    duration, billsec, disposition, amaflags, accountcode, uniqueid, userfield, 
    test


;
; Map CDR contents to the previously specified columns.
;
values => '${CDR(start)}','${CDR(clid)}','${CDR(dcontext)}','${CDR(channel)}',
    '${CDR(dstchannel)}','${CDR(lastapp)}','${CDR(lastdata)}','${CDR(duration)}',
    '${CDR(billsec)}','${CDR(disposition)}','${CDR(amaflags)}',
    '${CDR(accountcode)}','${CDR(uniqueid)}','${CDR(userfield)}','${CDR(test)}'
In the cdr_sqlite3_custom.conf file, the contents of the columns and values options must each be on a single line.

Cdr_syslog

Сохраняет CDR используя syslog linux. Чтобы включить данную возможность, сперва добавьте запись в конфиг syslog, /etc/syslog.conf. Например:

local.*      /var/log/asterisk/asterisk-cdr.log

Конфигурационный файл Asterisk – cdr_syslog.conf:

[cdr]

facility = local
priority = info
template = "Вызов от ${CDR(src)}"

пример записи syslog, для приведенной конфигурации:

 cat /var/log/asterisk/asterisk-cdr.log


Sep 17 18:15:57 pbx cdr: «Вызов от 8129981138»

Cdr_tds

Конфигурационный файл – cdr_tds.conf

cdr_tds модуль использует FreeTDS библиотеку для отправки CDR Microsoft SQL Server или Sybase БД. FreeTDS возможно использовать с unixODBC, так что конфигурация может быть сделана и в cdr_adaptive_odbc.

Файлы конфигурации Asterisk

Настройка Asterisk

Src,dst

Тут несколько меньше простора для оптимизаций. Точнее, один момент:

Если у вас не используется текстовых номеров, например в софтфонах, то данные поля можно преобразовать в BigInt, что тоже очень хорошо скажется на индексировании и выборке. Но если, Вы как и мы, используете текстовые номера, то данная оптимизация не для вас и придется смириться с более низкой производительностью.

В качестве вишенки на торте — подчищаем те поля, которые нас не интересуют и выставляем размер полей в ожидаемый для нашего случая. У меня получилось вот так:

Источник

База asteriskcdrdb и как с ней работать?

Разбираемся со статистикой

4 минуты чтения

Как и любая современная АТС, Asterisk имеет свою встроенную систему хранения истории звонков — CDR (Call Detail Record). Она используется для снятия статистики, ведения отчетности, прослушивания вызовов или подсчета биллинговых показателей.

Продвинутый курс по Asterisk

Пройди курс Asterisk Pro

Начать

В Asterisk для этого создана база данных asteriskcdrdb, в которой существует таблица cdr. Давайте рассмотрим как пользоваться данной таблицей и ее структуру.

После успешного подключения, необходимо выбрать для работы базу данных asteriskcdrdb:

Давайте убедимся, что у нас есть таблица cdr. Выполним это, как указано ниже:

На данном этапе мы убедились, что у нас есть база данных asteriskcdrdb, в которой находится таблица cdr. Давайте попробуем посмотреть входящие звонки из города за сегодня (дата написания статьи 18 марта 2022 года), в период с 12:00 до 12:10, т.е за 10 минут:

В вышеуказанном примере, в SQL запросе указано LENGTH( `src` ) >3. Столбец ‘src’ – показывает номер звонящего (source — источник). Это сделано для того, чтобы исключить внутренние звонки, так как у нас используется трехзначная нумерация. Тем самым, мы получаем в результате данные, с которыми затем можем работать. Например, отправить на почту в виде отчета. Ниже рассмотрена структура таблицы cdr в базе данных asteriskcdrdb:

СтолбецПример значенияОписание
calldate2022-03-18 12:00:36Дата и время звонка
clid«Oleg Ivanov»В данное поле попадает полное CallerID (CLID, CID), которое состоит из имени и номера звонящего. Это доступно только для считывания.
src84991111111Номер звонящего в конструкции CallerID (CNUM). Это доступно только для считывания.
dst113Номер назначения для звонка. Это доступно только для считывания.
dcontextCustomContext1Контекст для обработки. Это доступно только для считывания.
channelSIP/0002B2356854-a34bh3efКанал, через который поступил звонок
dstchannelSIP/0004F6675969-97836bb0Канал, через который ушел исходящий звонок
lastappDial, Busy, CongestionПриложение, которое последним отработало этот вызов перед попаданием в таблицу cdr
lastdataSIP/0004F6675969,30,tTАргумент, который был передан приложению, которое отработало вызов последним (lastapp)
duration75Количество секунд от начала (отметка start) до окончания вызова (отметка end)
billsec67Количество секунд от ответа (отметка answer) до окончания вызова (отметка end). Данное значение всегда меньше значения duration, и отражает длительность самого разговора, что важно для подсчета стоимости.
dispositionANSWERED, BUSY, NO ANSWER, FAILEDРезультат звонка
amaflagsOMIT, BILLING, DOCUMENTATION, UnknownМетка Automatic Message Accounting (AMA) – автоматический учет стоимости вызова.
accountcode23232Идентификатор аккаунта. Данное значение пустое по умолчанию, и определяется параметрами конкретного пользователя.
uniqueid1458291693.157169Уникальный идентификатор звонка
userfieldПользовательское поле. Здесь можно передавать что угодно, добавляя данные в этот столбец при работе с вызовом внутри контекста обработки.
did4996491913DID (Direct Inward Dialing). На основании DID вызова на Asterisk осуществляется его маршрутизация (это значение приходит от провайдера).
recordingfileexternal-113-84991111111-20220318-115933-1458291573.157155.wavИмя файла, содержащего запись разговора. В данном имени можно проследить путь к файлу в файловой структуре сервера.
cnum84991111111Номер звонящего в структуре CallerID.
cnamOleg IvanovИмя звонящего в структуре CallerID.

Теперь, когда вы понимаете принцип формирования запросов к базе данных и ее структуру, вы можете без труда формировать собственные отчеты. Например, ежедневный отчет о количестве входящих звонков за текущий день на почту. Это реализуется средствами php скрипта и добавления расписания через cron. Поговорим об этом в следующей статье

Источник

Виды cdr

Практически любая телефонная станция в том или ином виде предлагает тарификационный сервис, но разные производители могут использовать разные названия. Так, для оборудования Avaya, Nortel, Siemens, Cisco это — CDR-сервис, для Panasonic и LG-Nortel — SMDR-сервис (Station Messaging Detail Record), для Ericsson — CIL-сервис(Call Information Logging).

Если сервис включен, то пользователь может получить данные о каждом акте коммутации. Степень детализации и вид этой информации зависит от типа телекоммуникационного оборудования (Модели изделия, его прошивки) и от его настройки. Как правило, для каждого состоявшегося звонка cdr-информация содержит:

  • Номера вызывающего и вызываемого абонента
  • Время окончания разговора (время по часам АТС)
  • Длительность разговора
  • Другая сопроводительная информация (тип звонка (входящий, исходящий, перевод и т.п.), номер транка, номер группы, время начала разговора, длительность дозвона и т.п.)

Для передачи данных тарификационной программе используются разнообразные интерфейсы:

  • RS232 — АТС соединяется с приемником по COM-порту специальным кабелем (распайка кабеля для каждой АТС индивидуальна)
  • TCP/IP — АТС как сервер или как клиент выкладывает данные для внешней программы в локальной сети.
  • Share или FTP — АТС выкладывает данные в файлы, к которым внешние программы получают доступ через Share или FTP.

Возможности

Просмотр CDR, с фильтрацией по времени, номеру телефона, статусу(отвечен, не отвечен, занято)Встроенный HTML5/flash плеер для прослушивания записей звонков.

Все описанные действия в статье необходимо выполнять от имени суперпользователя (root). Установка и настройка производилась на предустановленной системе CentOS 6.8 Asterisk 11.23.1 FreePBX 13.

Выполнение cdr (посредничество)

В обыкновенных телефонных сетях системы, генерирующие CDRs (также называемые сетевыми элементами), и системы, обрабатывающие CDRs (также называемые системами поддержки операций, СПО) – отдельные объекты. По этой причине CDRs могут быть вначале собраны от сетевых элементов и переданы дальше к СПО, процессу, знающему коллекцию CDR или простую коллекцию вызова.

Когда CDRs собраны, они должны быть проконтролированы (проверены), переформатированы (нормализованы) и объединены для дальнейшего процесса.

Объединенный процесс собрания, проверки, нормализации и объединения также направляется на посредничество. Это может быть очень сложный процесс и нередко ТелКо теряют значимость, достигая прибыли через ошибки. В настоящее время число CDRs, которые обрабатываются в крупных телко, может быть абсолютно невероятно. (далее не переведено)

Отсюда важный урок: CDRs необычайно важны. Очень-очень заботьтесь о них!

В мире VOIP и программных коммутаторов, где CDR часто генерируются на той же самой системе, где они обрабатываются, последовательность посредничества значительно менее сложна. Даже с многократно географически разными CDR источниками, сети быстрых пакетных переключателей, повсеместное совместное использование линий связи и источников баз данных, посредничество и биллинг до сих пор менее сложная задача, чем в обычном телефонном мире.

Инструкция

1. Выполним подключение по SSH к роутеру для выполнения дальнейшей настройки. В зависимости от используемой системы(Windows, Linux, MacOS), подключение по SSH можно выполнить с использованием различного дополнительного программного обеспечения(Putty), либо системного терминала.

Внимание, при авторизации на сервере, пароль в консоли не отображается.

2. Проверим наличие и установленную версию Node JS:

#  node -v

Для корректной работы Ryo CDR требуется наличие установленной версии Node JS не ниже 8.0

3. После проверки наличия и установленной версии NodeJS, если версия ниже требуемой или NodeJS отсутствует, то переходим к следующему шагу установки, в случае наличия необходимой версии можено сразу перейти к пункту .

Интерфейс статистики merion metrics

Как видите, стандартный модуль CDR Report содержит очень много различных фильтров и параметров, которые, зачастую, просто не нужны рядовому пользователю. Именно поэтому, мы создали свой собственный интерфейс построения отчётов для Asterisk, интуитивно понятный и упрощенный.

Посмотрите видео о том, как много радости приносит наш интерфейс статистики для IP – АТС Asterisk:

Использование в исследованиях

CDR нашли различное применение в академических исследованиях, начиная от социальных сетей и кончая мобильностью людей.

Использует

Записи о звонках служат для множества функций. Для поставщиков телефонных услуг они имеют решающее значение для получения доходов, поскольку служат основой для выставления счетов за телефонные разговоры. Для правоохранительных органов подробные записи звонков предоставляют обширную информацию, которая может помочь идентифицировать подозреваемых, поскольку они могут раскрыть детали, касающиеся отношений человека с партнерами, моделей общения и поведения, и даже данные о местоположении, которые могут установить местонахождение человека. в течение всего разговора.

Для компаний, использующих телефонные системы PBX, записи сведений о вызовах предоставляют средства отслеживания междугороднего доступа, могут отслеживать использование телефона по отделам или офисам, а также могут создавать списки входящих и исходящих вызовов.

Ит база знаний

Курс по Asterisk

Конфиденциальность

Верховный суд США установил, что записи телефонных номеров не защищены Четвертой поправкой к Конституции США, поскольку звонивший «добровольно передал телефонной компании числовую информацию». Но есть ограниченная защита в соответствии с Законом о конфиденциальности электронных коммуникаций .

В июне 2022 года общественности стало известно о сверхсекретном постановлении Суда США по надзору за внешней разведкой . Этот порядок ссылался и определял записи сведений о вызовах следующим образом:

НАСТОЯЩИМ ПРИКАЗЫВАЕТСЯ, что Хранитель документации должен предоставить Агентству национальной безопасности (АНБ) после вручения настоящего Приказа и продолжать производство на постоянной ежедневной основе после этого в течение срока действия настоящего Приказа, если только Суд не распорядится о нем, электронная копия следующих материальных вещей: всех записей о звонках или «телефонных метаданных», созданных Verizon для связи (i) между Соединенными Штатами и за рубежом; или (ii) полностью внутри Соединенных Штатов, включая местные телефонные звонки …. «Метаданные телефонии включают в себя исчерпывающую информацию о маршрутизации связи, включая, помимо прочего, информацию об идентификации сеанса (например, исходящий и конечный телефонный номер, номер международного идентификатора мобильного абонента ( IMSI ), номер международного идентификатора оборудования мобильной станции ( IMEI ) и т. Д.), Соединительную линию идентификатор, номера телефонных карточек, время и продолжительность звонка. Метаданные телефонии не включают в себя основной контент любого сообщения, как определено в 18 USC  § 2510 (8) , или имя, адрес или финансовую информацию подписчика или клиента ».

Корпоративные сети

Протоколы и стандарты

Общее назначение

CDR используется для расчета стоимости телефонных разговоров, оценки рациональности использования трафика, а также для сервисных нужд при настройке оборудования. Для решения этих задач CDR-сервис, как правило, работает с тарификационной или биллинговой программой.

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Преимущества и недостатки cdr

Тарификационный сервис имеет одно неоспоримое преимущество — практически в любое телекоммуникационное оборудование этот сервис включен по умолчанию. Таким образом, для расчета стоимости звонков на базе данных CDR-сервиса необходима только тарификационная программа. Для большинства АТС существует большое количество платных и бесплатных тарификационных программ.

К недостаткам данной технологии можно отнести то, что:

  • данные о звонке приходят только после окончания звонка (впрочем некоторые АТС, например РТУ, могут сохранять CDR, не только по завершению, но и с заданной периодичностью, пока вызов актуален)
  • для многих АТС нельзя получить данные о несостоявшемся звонке
  • данная технология не позволяет управлять АТС (можно получить данные о звонке, но нельзя, например, скоммутировать абонентов или наоборот прервать разговор)

Для построения более развитых биллинговых систем используются другие технологии, например TAPI, которые лишены вышеперечисленных недостатков, но, как правило, не включены по умолчанию в оборудование. Далеко не все АТС обладают такими возможностями и для включения таких возможностей, как правило, необходимо докупать оборудование и лицензии.

Хорошим средством тарификации считается онлайн-учёт звонков (accounting) посредством протоколов RADIUS, DIAMETER и т.п.

Источник

Приложения и функции cdr

Команды и функции диалплана для работы с CDR.

Содержит общие (глобальные) параметры CDR и конфигурацию бакендов cdr_scv и cdr_radius. Файл конфигурации cdr.conf

OptionValue/ExampleNotes
enable yes Включить лог CDR. По умолчанию включено.
unanswered noСохранять или нет информацию о неотвеченных вызовах. Не касается внешних вызовов. О них сохраняется полная информация, независимо от значения данной опции.
endbeforehexten noЗакрыть и сохранить запись CDR до выполнения расширения ‘h’ (hangup). Если значение – ‘no’, закрытие CDR произойдет, только по завершению всех шагов диалплана. Если – ‘yes’, при завершении вызова, независимо от того продолжается выполнение диалплана в контексте или нет
initiatedseconds noПо умолчанию ‘billsec’ вычисляется, просто как разница ‘end’ минус ‘answer’ в секундах. Включение опции initiatedseconds=yes, укажет Asterisk использовать точные значения до микросекунд
batch noЗаписывать CDR группой, вместо записи каждого вызова отдельно. Снижает нагрузку на Asterisk. Зависит от перечисленных ниже опций.
size 100Кол-во строк CDR в буфере, при достижении которого, будет произведена запись.
time 300Предел времени хранения данных в буфере. Запись будет произведена, независимо от порога строк в буфере, заданного параметром size.
scheduleronly noSet whether CDR batch processing should be done by spawning a new thread, or within the context of the CDR batch scheduler. The default value is no, and we recommend not changing it.
safeshutdown yesБлокировать остановку Asterisk, пока буфер не очищен (данные сохранены).Предотвращает потерю данных, при корректном выключении Asterisk.

Применение cdr

Тарификационный сервис используется в первую очередь для формирования телефонных счетов. Существует огромное разнообразие программ для работы с тарификационными данными различных АТС, например, eSMDR, WinTariff, Phone Xpress, Барсум и т.п.

Кроме того, тарификационный сервис может использоваться для интеграции с различным телекоммуникационным оборудованием или программами. Так, например, в регистраторах телефонных переговоров cdr-информация может существенно дополнять информация о звонке.

Рейтинг и биллинг

CDRs были собраны, проверены, нормализованы и объединены, загрузка подсчитана для каждого вызова, идентифицированного деталями одного или более CDRs. Этот процесс известен как реитинг, и не удивительно, что он выполняет механизм ранжирования. Механизм рейтинга может быть частью системы биллинга или предшествующим процессом внешней системы биллинга.

Содержимое cdr

Запись сведений о вызове содержит поля данных, которые описывают конкретный экземпляр транзакции электросвязи, но не включают содержимое этой транзакции. В качестве упрощенного примера запись сведений о вызове, описывающая конкретный телефонный вызов, может включать в себя номера телефонов как вызывающей, так и принимающей сторон, время начала и продолжительность этого вызова. В реальной современной практике записи сведений о вызовах гораздо более подробны и содержат такие атрибуты, как:

  • номер телефона абонента , исходящего вызова ( вызывающий абонент A-сторона)
  • номер телефона, на который поступает звонок ( вызываемый абонент , абонент B)
  • время начала звонка (дата и время)
  • продолжительность звонка
  • номер телефона для выставления счетов, на который взимается плата за звонок
  • идентификация телефонной станции или оборудования для записи записи
  • уникальный порядковый номер, идентифицирующий запись
  • дополнительные цифры вызываемого номера, используемые для маршрутизации или оплаты вызова
  • расположение или результаты вызова, указывающие, например, был ли вызов соединен
  • маршрут, по которому звонок поступил на АТС
  • маршрут, по которому звонок покинул АТС
  • тип звонка (голосовой, SMS и т. д.)
  • тип голосового вызова (установка вызова, продолжение вызова, операция вызова, завершение вызова, ожидание вызова, вызов занят, вызов вне обслуживания)
  • любое неисправное состояние встречается

Каждый производитель биржи решает, какая информация будет отображаться на билетах и ​​как она будет отформатирована. Примеры:

В некоторых системах корпоративных частных телефонных станций (PBX) подробные записи о вызовах называются подробными записями сообщений станции ( SMDR ).

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Форматы cdrs

Форматы, в которых CDRs предоставляются, изменяются и часто имеют перестраиваемую конфигурацию. Традиционно генерация и поведение CDRs известны в US как Automatic Message Accounting () или

, система, которая возвращается к 1940м. Сегодня телефонные станции для использования в Северной Америке генерируют CDRs в формате Bellcore AMA Format или BAF.

Сегодня PBX большей частью генерируют CDRs как в форматах с разделенной запятой, так и прямо пишут в базу данных.

Шаг 1. партиции.

В виду того, что мы либо дополняем базу, либо читаем из нее, эффективно раз и навсегда поделить базу на файлы, чтобы уменьшить возможное количество обращений, при чтении определенных временных промежутков. Естественно, разбивать базу нужно по какому-то ключу. Но по какому?

Вводим дополнительное поле date, и делаем очень простой триггер на табличку, before update cdr:

Таким образом, в это поле у нас попадет только дата. И сразу разбиваем табличку на партиции по годам:

Готово, теперь если мы будем выборку делать с указанием диапазона даты, то MySQL не придется лопатить всю базу за все года. Небольшой плюсик уже есть.

Шаг 2. индексируем базу.

Собственно, это самый важный шаг. Эксперименты показывают, что в 90% случаев возникает необходимость в индексах на 3 столбцах (по мере необходимости):

  1. date
  2. src
  3. dst

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

происходит FullScan. Исправить поведение скуля мы не можем, но можем сделать так, чтобы количество строк для сканирования было минимальным и дать движку выбор, какой индекс использовать. С одной стороны, нам необходима максимальная подробность индекса, с другой стороны нам нужно затратить как можно меньше операций, чтобы получить диапазон, который мы будем перебирать.

Есть еще один споcоб помочь базе — сделать так, чтобы она могла вычислить положение строки в файле еще ДО открытия файла. Именно для этого можно использовать FIXED ROW. Положение строки в файле будет вычисляться умножение номера строки на длину строки, а не перебором. Естественно, у того подхода есть жертвы — база будет занимать на диске значительно больше места. Вот к примеру:

Размер базы вырос с 18 Гб до 53,8 Гб. Делать или нет — выбор каждого админа, но если место на сервере позволяет, то это будет еще одним плюсиком.

Backends

Модули баз данных предоставляют различные бакенды для записи CDR. Все они требуют специфических настроек.

Проверка подключенных backends: CLI>cdr show status

Call Detail Record (CDR) settings
----------------------------------
  Logging:                    Enabled
  Mode:                       Simple
  Log unanswered calls:       No
  Log congestion:             No

* Registered Backends
  -------------------
    mysql
    Adaptive ODBC
    cdr-custom
Читайте про операторов:  Замена сим-карты Билайн,как поменять на нано сим

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *