Что такое cdr в телефонии
Call Detail Record
Call Detail Record (сокр. англ. CDR — Подробная Запись о Вызове (ПЗВ); возможна расшифровка Charging Data Records — записи данных о списаниях) в телекоммуникационной сфере — сервис, обеспечивающий журналирование работы телекоммуникационного оборудования.
Содержание
Общее назначение
CDR используется для расчета стоимости телефонных разговоров, оценки рациональности использования трафика, а также для сервисных нужд при настройке оборудования. Для решения этих задач CDR-сервис, как правило, работает с тарификационной или биллинговой программой. Тарификационные и биллинговые программы на основе данных CDR формируют счета на оплату телефонных разговоров, рассчитывают статистику загруженности линий и операторов, статистику активности абонентов и т.п.
Виды CDR
Если сервис включен, то пользователь может получить данные о каждом акте коммутации. Степень детализации и вид этой информации зависит от типа телекоммуникационного оборудования (Модели изделия, его прошивки) и от его настройки. Как правило, для каждого состоявшегося звонка cdr-информация содержит:
Для передачи данных тарификационной программе используются разнообразные интерфейсы:
Применение CDR
Тарификационный сервис используется в первую очередь для формирования телефонных счетов. Существует огромное разнообразие программ для работы с тарификационными данными различных АТС, например, eSMDR, WinTariff, Phone Xpress, Барсум и т.п.
Кроме того, тарификационный сервис может использоваться для интеграции с различным телекоммуникационным оборудованием или программами. Так, например, в регистраторах телефонных переговоров cdr-информация может существенно дополнять информация о звонке.
Преимущества и недостатки CDR
К недостаткам данной технологии можно отнести то, что:
Для построения более развитых биллинговых систем используются другие технологии, например TAPI, которые лишены вышеперечисленных недостатков, но, как правило, не включены по умолчанию в оборудование. Далеко не все АТС обладают такими возможностями и для включения таких возможностей, как правило, необходимо докупать оборудование и лицензии.
Хорошим средством тарификации считается онлайн-учёт звонков (accounting) посредством протоколов RADIUS, DIAMETER и т.п.
Call Detail Record. Как полиция вычисляет преступников без сложной техники
Содержание статьи
Всевидящее око
Мы регулярно пишем об уязвимостях смартфонов, сетей передачи данных и о безопасности облачных сервисов. Мы настолько привыкли «думать сложно», что совсем забываем о существовании гораздо более простых и эффективных методов, доступных полиции разных стран.
Зачастую полиция не будет даже пытаться что-то взломать или перехватить, а просто сделает запрос к оператору сотовой связи, и последний отдаст не только историю звонков, но и массу другой интереснейшей информации. Как пример: статья об австралийском журналисте, в которой проанализирована информация, собранная о самом журналисте его сотовым оператором за последние два года (и только она).
По австралийским законам операторы сотовой связи обязаны в течение двух лет хранить определенную информацию о пользователях сети, базу Call detail record. Сюда входит информация о местоположении устройства в каждый момент времени (кстати, недавно в Швеции был создан прецедент: одной лишь этой информации недостаточно для вынесения приговора), журнал звонков, включая информацию о другом абоненте, и данные о сессиях выхода в интернет. Что касается SMS, то по австралийскому закону об охране частной жизни без предварительной санкции на прослушивание оператор имеет право (и обязан) сохранить лишь метаданные: время отправки, размер сообщения и адресата. Содержимое самих сообщений (а тем более голосовых звонков) не сохраняется.
Так выглядит информация, собранная о журналисте оператором.
Места, которые посетил журналист 1 апреля 2015 года.
Места, которые он чаще всего посещал во время заданного временного отрезка.
По ссылке доступны интерактивные версии этих данных.
Метаданные включают информацию о том, кому звонил и писал сообщения пользователь, о длительности звонков и о том, к каким базовым станциям в какой момент времени подключался телефон (такая информация позволяет достаточно точно установить местоположение устройства). В некоторых странах (не будем показывать пальцем, но это США) операторы не только выдают информацию о местоположении пользователя полиции, но и с удовольствием приторговывают такими данными.
Самое интересное, что операторам сотовой связи доступны (и выдаются полиции, а также продаются любому желающему) детали об использовании интернета, включая адреса сайтов и объем переданных данных. Это — совершенно отдельная тема для обсуждения; данные собирают, отслеживая запросы к DNS-серверам провайдера. Этими данными операторы также с радостью приторговывают; кормушка настолько привлекательна, что операторы даже пытались блокировать использование клиентами сторонних DNS-серверов.
К слову говоря, выданные (навязанные) стационарными интернет-провайдерами устройства (обычно — комбинированный кабельный или ADSL-модем + роутер) зачастую не позволяют сменить DNS-сервер на роутере. Если хочешь — меняй на компьютере, на каждом отдельном телефоне, умном телевизоре и колонке, но защитить свою частную жизнь полностью, просто задав настройки роутера, у пользователя не выйдет.
Мобильные операторы в США также обязаны хранить записи CDR. Кроме того, в Соединенных Штатах спецслужбами поддерживается единая база MAINWAY, записи в которой могут храниться гораздо дольше, чем разрешается по закону самим операторам мобильной связи.
В России же принят так называемый закон Яровой, который обязывает операторов сотовой связи в течение трех лет хранить метаданные (их список практически полностью совпадает с австралийским вариантом закона). Кроме того, с октября прошлого года операторы обязаны хранить в течение как минимум 30 суток (но не более шести месяцев) текстовые, голосовые, видео- и другие сообщения пользователей. Соответственно, в России любой звонок должен быть записан оператором и предоставлен полиции по законному требованию.
Не только CDR
В приведенном выше исследовании журналист Уилл Окенден пользовался iPhone. Правильно оформленный запрос в Apple (по терминологии компании — Device Request, то есть такой запрос, в котором у полиции нет ничего, кроме аппаратного идентификатора устройства — IMEI) позволит полиции получить и те данные, которые собирает о пользователе Apple, а туда входит почти все за редкими исключениями. Вот так, например, выглядит статистика запросов к Apple в России.
Для сравнения, в США за тот же год полиция запросила информацию о 19 318 устройствах (успешными оказались 81% запросов). Google предлагает интерактивный график, ознакомиться с которым можно по ссылке.
И если Apple не предоставит полиции такие данные, как пароли пользователя, статистика использования устройства, сообщения SMS/iMessage и данные «Здоровья» (история физической активности пользователя, включая число шагов и частоту сердцебиения в заданном временном промежутке, — полезнейшая вещь для ловли как преступников, так и неверных супругов), то Google отдаст все, в том числе пароли (чтобы быть полностью технически корректным, добавлю, что в Android 9 появилось шифрование резервных копий; соответственно, полиция не получит ни самих бэкапов, ни хранящихся в них SMS и журналов звонков).
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Олег Афонин
Эксперт по мобильной криминалистике компании «Элкомсофт»
Что такое CDR анализ в VoIP терминации?
CDR используют при расчете стоимости звонков, для оценки рациональности проведения трафика, а также диагностировании проблем в работе системы и выполнении определенных настроек оборудования. Как правило, CDR-сервис работает совместно с биллинговыми программами для терминации. В свою очередь, на основе данных из записей деталей о звонках, биллинг формирует счета за разговоры в сети VoIP, рассчитывает статистику по нагрузке на каналы, статистику абонентской активности и пр.
Сервис CDR, как правило, встроен в VoIP оборудование по умолчанию. Также он предусмотрен в Asterisk сервер voip. Программа создает записи по звонкам в __/var/log/asterisk/cdr-csv. Все записи доступны для чтения в файле Master.csv.
CDR обычно содержат следующую информацию о вызовах:
На основании данных из записей CDR подсчитываются такие показатели, как ACD и ASR, характеризующие среднюю продолжительность звонков и соотношение успешных/неуспешных вызовов. Они свидетельствуют о качестве VoIP связи. Также CDR, как правило, ведет журнал подсчета “нулевых звонков”. Это вызовы, которые не состоялись, поскольку не было установлено соединение, и вызовы с продолжительностью меньше 1 секунды, при которых абонент сам завершает разговор по причине плохой связи.
Существует также сервис CMR (Call management records), обеспечивающий журналирование данных о качестве обслуживания VoIP (QoS) и диагностические сведения о вызове. Записи CMR содержат следующие данные по звонкам:
Анализируя эту статистику, вы сможете делать выводы об эффективности работы вашей VoIP системы и предпринимать соответствующие меры для повышения продуктивности GSM терминации.
Анализ CDR Cisco и Asterisk телефонии с помощью Splunk
На сегодняшний день существует классическая, с точки зрения аналитики, задача — анализ CDR телефонии. В рамках данной статьи мы расскажем о том, как две разные компании решали две совершенно разные задачи. Компания X анализировала CDR Cisco телефонии, а компания Y — CDR Asterisk телефонии. Почему мы пишем об этом в одной статье? Потому что в качестве инструмента для анализа обе компании используют Splunk, о котором мы много писали ранее. 
Под катом вы найдете подробное описание задач и их решения с картинками и запросами.
Задачи
Компания X имеет порядка 30 департаментов, в которых порядка 400 внутренних номеров и около 100 000 звонков в месяц.
Решения задач
В данной статье мы не будем рассказывать о том как подключить данные Splunk и как сделать разбор полей (если интересно именно это, напишите нам — и мы сделаем отдельную статью об этом, но на самом деле никакого rocket science там нет). Мы покажем основные запросы, графики и дашборды.
Компания X
Аналитика по всей организации:
На данном дашборде собрана общая аналитика по всей компании в целом, с различными статистическими показателями. Дашборд живой, то есть имеет различные фильтры, а также может отправить пользователя на следующий уровень детализации. К примеру, при нажатии на определенный департамент или номер телефона, пользователь увидит аналитику в разрезе выбранного сегмента.
Аналитика в рамках отдельного департамента:
На этом дашборде пользователь видит детализацию по конкретному департаменту компании, и может сделать вывод как о статистике взаимодействия сотрудников данного отдела с другими внутренними департаментами, так и о внешних вызовах.
Аналитика по конкретному пользователю:
Это последний уровень детализации, где мы видим информацию, касающуюся определенного сотрудника организации, и можем судить о его активности.
На самом деле все эти графики построены на достаточно простых запросах, уровень сложности сравним с теми, что мы обсуждали в наших предыдущих статьях. Ниже один из наиболее сложных:
Здесь все намного проще, так как у колл-центра есть только один тип звонков, да и компанию в большей степени интересует только сводная информация. Однако, возможность дороботки и детализации не исключена, например по конкретному сотруднику. Ниже основной дашборд на основе CDR Asteriska:
Наиболее интересным является самый нижний график, где решается задача по вычислению конкурентных сессий.
Ниже один из наиболее сложных запросов, как раз про конкурентные сессии:
Заключение
Мы рады ответить на все ваши вопросы и комментарии по данной теме. Также, если вас интересует что-то конкретно в этой области, или в области анализа машинных данных в целом — мы готовы доработать существующие решения для вас, под вашу конкретную задачу. Для этого можете написать об этом в комментариях или просто отправить нам запрос через форму на нашем сайте.
Обзор возможностей файла cdr.conf
В данной статье проведём обзор возможностей файла cdr.conf Основная информация CDR или Call Detail Record — особая часть Asterisk, которая предоставляет возможность получать данные о статистике звонков в системе. Подробности о том, как получить данную статистику и о работе с ней можно найти в статье Статистика звонков CDR в FreePBX-13. cdr.conf — основной файл, который […]
В данной статье проведём обзор возможностей файла cdr.conf
Основная информация
CDR или Call Detail Record — особая часть Asterisk, которая предоставляет возможность получать данные о статистике звонков в системе. Подробности о том, как получить данную статистику и о работе с ней можно найти в статье Статистика звонков CDR в FreePBX-13.
cdr.conf — основной файл, который необходим для настройки CDR. В этой статье мы рассмотрим, какие параметры возможно настроить в данном файле.
Раздел [general]
Данный раздел, обычно, является первым в файле и отвечает за главные настройки. Начинается он с ключевой строки: [general].
Одним из ключевых настроек данного раздела является параметр enable.
enable = yes/no — определяет, будут ли вызовы записываться в CDR. Соответственно, если параметр выставлен в no, то вызовы записываться не будут и в статистику (к примеру, в CDR Reports) не попадут. Значение по умолчанию: Yes.
Подробнее об этой и других командах можно прочесть в статье Справочник команд.
unanswered = yes/no — определяет, будут ли записываться неотвеченные вызовы в CDR. Если параметр выставлен в no, то вызовы записаны не будут. Это т параметр не распространяется на внешние исходящие вызовы, совершенные через транки. Такие вызовы всё равно будут записаны. Значение по умолчанию: No.
congestion = yes/no — определяет, будут ли записываться вызовы в CDR, завершённые состоянием перегрузки каналов (congestion). По факту, возникновение такого состояния также может быть обусловлено техническими проблемами со стороны оператора. Поэтому, включение его может оказаться достаточно полезным для дебага. Значение по умолчанию: No.
batch = yes/no — включение данного параметра позволяет записывать данные о вызовах предварительно в буфер обмена. После заполнения буфера до определённого размера (смотреть параметр size) или при достижении заданного времени очищения буфера (смотреть параметр time), данные группой будут записаны в базу. Значение по умолчанию: No.
size = N — используется только при batch = yes. Определяет размер буфера обмена. В качестве N указывает количество записей CDR, хранимых в буфере до записи в базу. По умолчанию N = 100.
time = N — используется только при batch = yes. Определяет время, через которое данные из буфера обмена будут записаны в базу (даже если при этом количество записей не дошло до значения, указанного в параметре size). Время указывается в секундах. По умолчанию N = 300 (5 минут).
scheduleronly = yes/no — данный параметр отвечает за использование планировщика передачи пакетов, встроенного в Asterisk. Если установлен в значение «No», то передача пакетов производится внутри одного потока планировщика. Если установлен в значение «Yes», то каждая передача пакета производится в отдельном потоке. Рекомендуется установка в «Yes», при передаче множества маленьких пакетов (размер которых, к примеру, не превышает 10 записей). Значение по умолчанию: No.
endbeforehexten = yes/no. Обычно запись в CDR производится после выполнения всех расширений. В случае если этот параметр выставлен в «Yes» — запись в CDR производится перед выполнением обработчиков «h» и «hangup». При этом значения CDR, такие как «end» и «billsec» могут быть получены внутри данного расширения. Значение по умолчанию: No.
initiatedseconds = yes/no. По умолчанию, поле billsec вычисляется как разность между временем окончания разговора и временем ответа, в секундах (то есть разность считается по уже округлённым значениям до секунд). Внутри, в Asterisk, время хранится как в секундах, так и в микросекундах. Если выставить данный параметр в «yes», то Asterisk будет использовать более точные вычисления billsec: кроме обычной разности, если количество микросекунд на момент конца разговора (end) окажется больше, чем количество микросекунд в начале ответа (answer), то значение billsec увеличится на 1. При этом целая часть вычитается по общим правилам. Значение по умолчанию: No.
safeshutdown = yes/no — когда включён данный параметр, перед завершением работы Asterisk сперва будут выгружены все записи CDR, содержащиеся в буфере обмена. Значение по умолчанию: Yes.
CDR «BACKEND»
Также в файле cdr.conf описывается, так называемый бэкэнд — сохранение данных в других форматах. Список поддерживаемых бэкэндов достаточно широк: csv, custom, manager, odbc, pgsql, radius, sqlite, tds. Также поддерживается mysql, как Asterisk-дополнение. Существует возможность также создавать свой бэкэнд, путём создания нового модуля в директории cdr. Также отметим, что можно использовать более одного бэкэнда. В этом случае, для каждого бэкэнда будет сгенерировано своё событие.
Некоторые из бэкэндов не устанавливаются по умолчанию, при установке Asterisk. Поэтому, если видите, что чего-то не хватает — можно доставить его, выполнив команду make menuselect и выбрав необходимый.
Подробности о команде make menuselect, равно как и об установке Asterisk можно найти в статье: Установка Asterisk: пошаговая инструкция.
Чтобы узнать, какие сейчас бэкэнды установлены в Asterisk, следует в CLI выполнить команду:
Данная команда выведет также информацию о текущих настройках CDR, которые были сделаны в разделе general.
В приведённом примере из бэкэндов включён только Adaptive ODBC.