Cdr что это в телекоме

Cdr что это в телекоме

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

По умолчанию Asterisk записывает данные CDR в CSV-файлы [1] , находящиеся в каталоге /var/log/asterisk/cdr-csv. Для упрощения дальнейшей обработки данные можно экспортировать в СУБД, например, в MySQL.

Кроме CSV-файлов Asterisk записывает CDR-информацию ещё и в SQLite-файл /var/log/asterisk/cdr.db. Этот файл поддаётся анализу намного легче.

$ sqlite /var/log/asterisk/cdr.db sqlite> select accountcode, sum(billsec) from cdr group by accountcode;

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

[править] Формат CDR

1. accountcode — код учётной записи (20);
2. src — номер Caller-ID источника звонка (80);
3. dst — номер Caller-ID получателя звонка (80);
4. dcontext — контекст-получатель (80);
5. clid — Caller-ID, номер и текст (80);
6. channel — канал источника звонка (80);
7. dstchannel — канал получателя звонка (80);
8. lastapp — последнее приложение (80);
9. lastdata — аргументы последнего приложения (80);
10. start — время начала звонка;
11. answer — время когда была поднята трубка;
12. end — время окончания звонка;
13. duration — продолжительность звонка в секундах;
14. billsec — продолжительность собственно разговора (с момента подъёма трубки);
15. disposition — результат обработки звонка (ANSWERED, NO ANSWER, BUSY);
16. amaflags — AMA-флаг (Automated Message Accounting);
17. uniqueid — уникальный идентификатор канала;
18. user field — пользовательское поле.

Последние два поля можно включать/выключать в файле #cdr.conf#.

[править] Дополнительная информация

• CDR (англ.) на voip-info.org
• Asterisk call data records in comma-separated text files (англ.) — описание полей в CDR-записях астериск
• Asterisk CDR csv mysql import (англ.) — импорт CSV-файлов в MySQL

Программы для анализа CDR:

• Asterisk-Stat (англ.)
• Asterisk Queue/CDR Log Analyzer (англ.)

[править] Примечания

1. ↑ CSV, Comma Separated Values — формат файла, в котором записи представляются в виде строк, состоящих из полей, разделённых запятыми

Большие данные для телекома не только средство, но и товар

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

Технологии больших данных позволяют телеком-компаниям собирать большие профили на своих абонентов, находить взаимосвязи и даже выявлять психотипы. Если анализ геолокационных данных указывает на то, что абонент каждые выходные проводит в торговых центрах, то можно предположить, что он «шопоголик», а если он проводит большую часть жизни в Москва-Сити, то это очевидно «трудоголик».

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

В ходе конференции Teradata Universe, прошедшей весной этого года в Праге, сразу несколько сотовых операторов рассказали о своем опыте анализа больших данных. Вскапывают большие данные не только крупные телеком-компании развитых стран, но и сотовые операторы развивающегося мира.

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

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

Майкл Гёргл (Michal Girgle), менеджер по BI-инновациям Telefonica Czech Republic, рассказывает, что геопространственная аналитика может ответить на многие вопросы ритейлеров: откуда пришли их клиенты, когда и как часто они находятся вблизи торговой точки, сколько времени там проводят, кто они и чего хотят. Анализ местоположения пользователей может оказаться полезным не только для маркетинговых целей операторов и их партнеров, но и для планирования развития города.

«Мы можем, например, увидеть, что большинство потенциальных клиентов проходит мимо магазина через полчаса после закрытия. Это будет означать, что торговой точке следует изменить режим работы, – рассказывает Люк Маллинс (Luke Mullins), руководитель информационной стратегии и управления O2 . – Наша аналитика поможет магазинам понять, насколько оформление витрин соответствует проходящей аудитории». В числе дополнительных ценных для анализа источников данных помимо соцсетей эксперт также отмечает так называемые открытые данные. Это сведения, которые публикуются госорганами, в том числе в машиночитаемом виде. В последние годы российские федеральные и региональные правительства заметно активизировались в раскрытии наборов общественно-значимых данных.

Любая аналитика, позволяющая ритейлерам лучше узнать своего покупателя, банкам – обогатить профиль потенциального заемщика, рекламщикам – доставить персонифицированное сообщение, сегодня очень востребована рынком. «Для аналитиков рекламных компаний и агентств недвижимости критичными являются данные о потоках людей для рейтинга рекламных площадок и объектов недвижимости. Сейчас это реализуется на базе CDR-данных телеком-компаний, а если добавить к ним всю информацию о перемещении абонентов, что позволит более точно и детально сегментировать клиентскую базу, то получится очень интересный источник информации, за доступ к которому бизнес будет готов платить», – считает Сергей Кузнецов, директор по технологиям дивизиона бизнес-решений IBS.

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

Подобные сервисы уже пилотируются в России и в скором времени будут запущены в промышленную эксплуатацию. «Сегодня российские операторы готовы и морально, и технологически к предоставлению этих сервисов. Уверен, что и с правовой точки зрения предоставление неперсонифицированной информации о перемещении людей не может быть ограничено», – считает Сергей Кузнецов.

Вместе мы заработаем больше

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

Олег Тремзин, Softline: За этот год значительный рост и развитие показали направления, связанные с техподдержкой и аутсорсингом

Импортонезависимость

В 2013 г. «Мегафон» первым из «большой тройки» российских операторов представил сервис геопространственной аналитики и рассказал о пилотном проекте по анализу потоков населения московской агломерации. По словам представителей компании, у сервиса уже есть несколько активных заказчиков. Но эксперты сразу отметили ряд недостатков. В частности, по информации о местонахождении по большей части молодых абонентов «Мегафон» нельзя достоверно судить об утренних пробках в Москве – в них преимущественно стоят абоненты других операторов.

Интересен опыт Лондонских телеком-компаний. Три мобильных оператора Великобритании – EE, Telefonica UK (O2) и Vodafone UK – создали объединение, которое получило название Weve. В его рамках была построена система для сбора данных о местоположении пользователей мобильных устройств. В системе консолидируются данные о клиентах и звонках (CDR), логи посещений веб-сайтов, геолокационные сведения, информация о клиентах из третьих источников. Данные обновляются ежедневно, планируется переход к ежечасному обновлению. Каждый день анализируется около 20 млн клиентских записей. Персональные данные не хранятся на дисках в явном виде и защищены шестиуровневой системой защиты и шифрования.

Люк Маллинс, представляющий компанию-инициатора проекта Weve, говорит и об экономическом эффекте объединения. Готовить аналитику совместно оказалось выгодно.

В объединении данных нескольких операторов есть один нюанс: важно не посчитать одного человека с несколькими SIM-картами как разных людей. Как рассказал Илья Катчан, руководитель направления по работе с государственными компаниями в SAS Россия/СНГ, более 60% жителей Москвы имеют более двух SIM-карт. Инструменты анализа больших данных позволяют «увидеть» одинаковое перемещение абонентов разных операторов и рассматривать их как одного человека, а не несколько.

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

По мнению Сергея Кузнецова, к данным сотовых операторов можно было бы еще добавить и данные операторов фиксированной связи. «Это позволит сформировать картину общей инфраструктуры района, насыщенности и востребованности определенных услуг, что поможет бизнесу в принятии важных решений об открытии новых магазинов или приобретении рекламных площадок», – считает эксперт.

По отзывам экспертов, инвестиции в продукты геопространственной аналитики невелики, и соответственно их эффективность довольно высока. Ян Шимек (Jan Simek), вице-президент Teradata в Восточной Европе, видит в новых корпоративных сервисах, основанных на больших данных, хорошую возможность для сотовых компаний. Как он рассказал, новые технологические платформы могут быть не только источником дохода, но и предметом для сотрудничества и создания кобрендинговых продуктов, например, совместно с банками.

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

Эта тенденция подтверждается исследованием IDC, согласно которому количество устройств и предметов в мире, подключаемых к интернету, приближается к 200 млрд, из которых 14 млрд, или 7%, уже подключены и активно передают данные. На сегодняшний день данные интернета вещей составляют 2% от мирового объема информации. Согласно прогнозам IDC, к 2020 г. уже 32 млрд подключенных устройств будут генерировать 10% общего объема данных во всем мире. Так что время у телеком-компаний еще есть.

Александра Кирьянова

Cdr что это в телекоме

Сообщение pingwin177 » Чт 12 янв 2012, 12:08

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

anton Участник форума Сообщения: 90 Зарегистрирован: Пн 23 мар 2009, 10:00 Откуда: Санкт-Петербург

Re: CDR, такой CDR.

Сообщение anton » Чт 12 янв 2012, 12:53

А как прописан ваш system-parameters cdr?
pingwin177 Постоянный участник форума Сообщения: 167 Зарегистрирован: Вт 28 июл 2009, 17:41

Re: CDR, такой CDR.

Сообщение pingwin177 » Чт 12 янв 2012, 14:23

 CDR SYSTEM PARAMETERS Node Number (Local PBX ID): 1 CDR Date Format: month/day Primary Output Format: customized Primary Output Endpoint: DISK Use ISDN Layouts? n Enable CDR Storage on Disk? y Use Enhanced Formats? n Condition Code 'T' For Redirected Calls? n Use Legacy CDR Formats? y Remove # From Called Number? y Modified Circuit ID Display? n Intra-switch CDR? y Record Outgoing Calls Only? n Outg Trk Call Splitting? y Suppress CDR for Ineffective Call Attempts? y Outg Attd Call Record? y Disconnect Information in Place of FRL? n Interworking Feat-flag? y Force Entry of Acct Code for Calls Marked on Toll Analysis Form? n Calls to Hunt Group - Record: member-ext Record Called Vector Directory Number Instead of Group or Member? n Record Agent ID on Incoming? n Record Agent ID on Outgoing? y Inc Trk Call Splitting? y Inc Attd Call Record? n Record Non-Call-Assoc TSC? n Call Record Handling Option: warning Record Call-Assoc TSC? n Digits to Record for Outgoing Calls: dialed Privacy - Digits to Hide: 0 CDR Account Code Length: 4 CDR SYSTEM PARAMETERS Data Item - Length Data Item - Length Data Item - Length 1: time - 4 17: node-num - 2 33: - 2: sec-dur - 5 18: space - 2 34: - 3: cond-code - 1 19: date - 6 35: - 4: code-dial - 4 20: space - 7 36: - 5: code-used - 4 21: return - 1 37: - 6: dialed-num - 18 22: line-feed - 1 38: - 7: calling-num - 10 23: - 39: - 8: acct-code - 15 24: - 40: - 9: auth-code - 7 25: - 41: - 10: space - 1 26: - 42: - 11: frl - 1 27: - 43: - 12: in-crt-id - 3 28: - 44: - 13: out-crt-id - 3 29: - 45: - 14: feat-flag - 1 30: - 46: - 15: attd-console - 2 31: - 47: - 16: in-trk-code - 4 32: - 48: - 

anton Участник форума Сообщения: 90 Зарегистрирован: Пн 23 мар 2009, 10:00 Откуда: Санкт-Петербург

Re: CDR, такой CDR.

Сообщение anton » Чт 12 янв 2012, 14:34

Последний раз редактировалось anton Чт 12 янв 2012, 16:06, всего редактировалось 1 раз.
pingwin177 Постоянный участник форума Сообщения: 167 Зарегистрирован: Вт 28 июл 2009, 17:41

Re: CDR, такой CDR.

Сообщение pingwin177 » Чт 12 янв 2012, 14:53

Антон, а можно поконкретнее. Мне от CDR нужно ровно то, о чем я написал в теме и не больше и не меньше, остальное устраивает и так. Какой параметр в ваших настройках позволит мне получить то о чем собственно и был задан вопрос? Либо если при ваших настройках на выходе получается то что мне нужно, но вы не знаете почему, то так и скажите об этом прямо. Тогда есть хоть какой-то смысл игры в угадайку. В противном случае, извините, но ваше сообщение ни о чем.

Последний раз редактировалось pingwin177 Чт 12 янв 2012, 14:54, всего редактировалось 1 раз.
olle Постоянный участник форума Сообщения: 168 Зарегистрирован: Сб 26 дек 2009, 21:49

Re: CDR, такой CDR.

Сообщение olle » Чт 12 янв 2012, 14:54

в качестве оффтопа — интересно что будет если загонять входящие не в ars а конвертировать через cha inc — как в этом случае они будут падать на сборщик? (а на нем нельзя настроить конвертацию, обратную ars-овской?)

pingwin177 Постоянный участник форума Сообщения: 167 Зарегистрирован: Вт 28 июл 2009, 17:41

Re: CDR, такой CDR.

Сообщение pingwin177 » Чт 12 янв 2012, 14:56

olle писал(а): в качестве оффтопа — интересно что будет если загонять входящие не в ars а конвертировать через cha inc — как в этом случае они будут падать на сборщик? (а на нем нельзя настроить конвертацию, обратную ars-овской?)

Пробовал, не летает такой корабль. Это по поводу ch inc.
Ну а на сборщике то конечно все можно, только это равносильно удалению гланд через жопу.

vsorokin Постоянный участник форума Сообщения: 477 Зарегистрирован: Чт 17 сен 2009, 15:00 Откуда: Москва Контактная информация:

Re: CDR, такой CDR.

Сообщение vsorokin » Чт 12 янв 2012, 15:46

pingwin177 писал(а): Коллеги есть такой вопрос, может кто сталкивался. Можно ли станцию заставить каким-нибудь образом писать в CDR при входящем вызове B-номер в нормальном виде, а не то что из него получилось после ars конвертации?

Что имеется ввиду под «а не то что из него получилось после ars конвертации?»
Если можно — пример.
Дело в том, что я принимаю входящие с помощью ars dig conv. Но не провожу какой — либо конвертации АОНа. В параметре CDR clg-num/in-tac вывожу АОН. Все пишется, как присылается. Плюс — добавляется «9» (ее вставляю в транк-группе).

pingwin177 Постоянный участник форума Сообщения: 167 Зарегистрирован: Вт 28 июл 2009, 17:41

Re: CDR, такой CDR.

Сообщение pingwin177 » Чт 12 янв 2012, 17:05

Вы путаете номера А и В, посмотрите внимательно на свой CDR. С номером вызывающего абонента (А) действительно ничего не происходит, он прилетает как есть. В ars конвертации принимает участие номер вызываемого абонента (В). Вместо него avaya пишет в CDR в поле dialed-num внутренний ext (спорю на рубль что у вас тоже самое ).Именно этот номер я и хочу увидеть в нормальном формате, можно даже в любом другом поле отличном от dialed-num.

vsorokin Постоянный участник форума Сообщения: 477 Зарегистрирован: Чт 17 сен 2009, 15:00 Откуда: Москва Контактная информация:

Re: CDR, такой CDR.

Сообщение vsorokin » Чт 12 янв 2012, 19:59

Согласен. Перепутал А и В (сидели на трубе ).

По теме.
Для того, чтобы «не потерять» входящий номер в CDR, я его не изменяю в ars dig. Использую (указываю в поле NET что это такое), но не меняю . Только и всего.
Все «городские» номера, которые приземляю у себя на АТС, у меня расписаны либо как sta типа virtual (далее — map to аналоговый sta или с последующим cover на группы и другие sta), либо через vdn или hunt-group. И уже там делаю нужную конвертацию.

Транзит входящих на другую АТС проще всего делать с помощью пары ars -> aar (напрямую, без cover и change inc-call-handling-trmt trunk-group). Тогда в поле dialed-num будет первоначальный («городской») номер.

Поэтому в CDR я их вижу все. Некоторые напрямую (в поле dialed-num). Другие — в поле vdn.

напрямую через virtual sta 6859541 и в нем - map на аналоговый 3542 (его в CDR не видно): 281011 0937 00008 7010004 984999025000 6859541 G 0 281011 0937 00036 7010004 984999025000 6859541 9 1 через hunt-group 6859680 , где 3584 - член группы (не люблю я делать таким образом. ): 281011 1039 00041 7010003 989039606187 3584 G 0 281011 1044 00412 7010003 989039606187 6859680 9 1 через поле vdn (лучше всего, если надо увидеть, куда вызов пошел дальше): 30.10.2011 01:42:05 301011 0142 00004 7010024 989161039687 6859683 G 6859683 0 30.10.2011 01:42:18 301011 0142 00013 7010024 989161039687 3670 9 6859683 0 30.10.2011 01:42:42 301011 0142 00023 7010024 989161039687 3667 9 6859683 2 транзит входящего 6859632 с маршрута 7010 на другую АТС (маршрут 7004) на номер 5015 (его в CDR не видно) с помощью пары ars -> aar (напрямую, без cover и change inc-call-handling-trmt trunk-group): 13.01.2012 14:44:51 130112 1444 00004 7010015 7004056 989164497351 6859632 9 1 9 

Да и в list ars digit-conversion и в list extension-type (почти) их всех видно. Что также бывает удобно.

Да, чуть не забыл: 0,5 рубля с вас (поскольку, иногда все же пишется в поле dialed-num и внутренний номер)

pingwin177 Постоянный участник форума Сообщения: 167 Зарегистрирован: Вт 28 июл 2009, 17:41

Re: CDR, такой CDR.

Сообщение pingwin177 » Пн 16 янв 2012, 10:49

vsorokin, спасибо! Есть тема для подумать и покрутить, ща только текучку раскидаю. Уже морально готовлюсь бежать за коньяком
Если я все правильно понимаю, то основная идея это параметр Conv в ars digit-conversion ставим в n. В диалплане заводим диапазон 10 -значных номеров под входящий город. Прописываем их как station типа virtual и засовываем в ars digit-conversion. И все типа должно заработать как надо. Не совсем понятно пока с Hunt group, насколько я понял именно там и пишет иногда внутренний ext. Поправьте меня если что-то не так.
Ну и буду очень сильно благодарен если настройки CDR свои покажете, чтобы не гадать по приведенному логу где какой параметр, хотя основные то конечно видно и так.
Транзит кстати тупо рисуется через ars analisis — там все замечательно видно.

vsorokin Постоянный участник форума Сообщения: 477 Зарегистрирован: Чт 17 сен 2009, 15:00 Откуда: Москва Контактная информация:

Re: CDR, такой CDR.

Сообщение vsorokin » Пн 16 янв 2012, 14:01

pingwin177 писал(а): vsorokin, спасибо! . Уже морально готовлюсь бежать за коньяком

Если я все правильно понимаю, то основная идея это параметр Conv в ars digit-conversion ставим в n. В диалплане заводим диапазон 10 -значных номеров под входящий город. Прописываем их как station типа virtual и засовываем в ars digit-conversion. И все типа должно заработать как надо. Не совсем понятно пока с Hunt group, насколько я понял именно там и пишет иногда внутренний ext. Поправьте меня если что-то не так.

Ну и буду очень сильно благодарен если настройки CDR свои покажете, чтобы не гадать по приведенному логу где какой параметр, хотя основные то конечно видно и так.
Транзит кстати тупо рисуется через ars analisis — там все замечательно видно.

А я за стаканами

Основных идей две:
1) все входящие вызовы должны попадать в ars digit-conversion. А там в поле NET указываем, что это такое (aar,ars,ext), но ничего в них не преобразовываем.
Чтобы входящие попадали в ars digit-conversion, для соответствующей trunk-group ХХХХ с помощью change inc-call-handling-trmt trunk-group ХХХХ пишем одну строку с параметрами входящих вызовов, где в поле Insert вставляем fac доступа к ars (код выхода в «город»).

Кстати. Такое расписывание всех своих «городских» вызовов позволяет уменьшить расходы на связь (вы «заворачиваете» все исходящие вызовы на собственные номера внутри своей сети, без выхода на внешнего оператора связи).

2) По возможности, используем station типа virtual. Их возможное число довольно большое + не входит в общее допустимое количество extensions. Далее — map или cover.
Когда уж очень нужно смотреть, куда вызов распределялся (например — многоканальная диспетчерская служба или вызовы на общий номер организации с последующим донабором внутренних) — используем vdn.

Кстати, подобная схема распределения входящих обсуждалась тут: viewtopic.php?f=1&t=3052

По hunt-group: там чаще всего пишется как раз общий (в данном случае — «городской») номер группы. А с меня часто спрашивают проведение оценки загруженности номера (распределение нагрузки по внутренним абонентам — диспетчерам). При прямом направлении вызова на hunt-group не всегда такое удается получить. Приходится работать через vdn.

По формату CDR.
Выше приведены образцы CDR в формате TSV87/TSV106.
Ниже — ссылки на странички, где можно скачать разъяснение этого формата :
http://7548.ru/TSVreaderCDR.htm (в документации к программам) или здесь (там есть прямая ссылка на этот формат): TSVOffice

Тарификацию осуществляю с помощью TSVOffice. Ее текущая версия позволяет обрабатывать информацию от AVAYA / DEFINITY (для CDR в формате TSV87/TSV106 или в стандарте «UNFORMATTED») и IP Office (SMDR — формат).

Предбиллинг

Прежде чем тарифицировать услуги и выставлять счета абонентам, необходимо собрать первичные данные. В случае телефонии речь идёт о CDR-файлах, и это целая история. Дело в том, что не существует такой вещи, как единый формат CDR-файлов. Каждый производитель АТС предоставляет данные для тарификации звонков в своем формате. Даже в рамках одного производителя, формат CDR-файлов для АТС разных моделей может существенно различаться. Чтобы собрать данные об оказанных услугах приходится собирать и декодировать файлы сотен различных форматов, а ведь есть ещё роуминг, с его TAP и NRTRDE-файлами, которыми операторы обмениваются между собой.

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

Резюмируя, предбиллинг — крупный и очень важный модуль в работе любого оператора телефонии или Internet-провайдера. Предбиллинг не является составной частью биллинговой системы непосредственно, но поставляет первичные данные, без которых дальнейшее функционирование биллинговой системы невозможно. Система предбиллинга — это обработка огромных объёмов данных и, в некоторых случаях, обработка данных в реальном масштабе времени. Это сбор и декодирование CDR-файлов сотен различных форматов. Это ежедневный труд разработчиков и сотрудников технической поддержки.

Другие статьи

Внедрение биллинга в компании: выгоды, основные этапы и возможные сложности

Применение биллинга позволяет автоматизировать и оптимизировать многие бизнес-пр.