А давайте сразу перечислим, что мы бы хотели видеть в новом модуле.


- Регулярно обновляемый стандартный справочник географических кодов (либо отдельным репозиторием, либо в составе биллинга)

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

Может быть сделать как в inet иерархию устройств и привязывать устройство к нижнему устройству.

У нас тут произошло слияние с компанией, у которой куча меди и АТС-ок и самописный биллинг на всё это (далее следует непереводимый итальянский фольклор).

Иерархия в виде дерева, как в Inet - неправильно. По факту АТС-ки - это облако. Один и тот же звонок проходит через несколько и попадает в несколько CDR. Связать их между собой явно обычно нельзя, т.к. нет сквозного id звонка. Есть самописные эвристические методы связки для дебага прохождения звонков, но это к биллингу не относится..
Есть 2 подхода:
1. Берём данные на входе, т.е. на той АТС, к которой подключен абонент (или заходит транк субоператора). Плюс - мы точно знаем, кого мы тарифицируем. Минус - мы точно не знаем, куда этот звонок уйдёт из облака, т.е. не можем надёжно определить цену (конечного оператора МГМН).
2. Берём данные на выходе из нашего облака. На выходе мы точно знаем, на какого вышестоящего оператора мы отправили звонок и можем точно определить цену. Но клиента, которому нужно этот звонок выставить, мы знаем только по номеру телефона. А этот номер может быть кривой, например. Но это уже будет проблема конфигурации сети - почему наши станции или абонентские АТС шлют плохие А-номера.

Очевидно, вариант 2 правильнее.
Отсюда следствие: транки субоператоров желательно присоединять к тому же узлу (транзитному), с которого они выходят вовне. Тогда можно идентифицировать их звонки просто по входящему/исходящему портам.
Но, во-первых, это не всегда физически возможно.
Во-вторых, в какой-то момент у вас рядом появляется, например, вторая транзитная Voip-АТС и вы часть трафика выводите через неё.
И опять приходится делать выбор, в какой точке снимать CDR.

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

По факту, у нас используется некая промежуточная база для сбора CDR:
- Импорт логов разных форматов в общую базу
- Аналитика и мониторинг по сырым данным станций
- Конфигурация сети (куда какие каналы ведут, присоединённые операторы)
- Отсев до тарификации (?)

Затем уже из этой базы генерируются готовые для тарификации CDR в едином формате.
Такие "подготовленные" CDR удобнее тем, что, например, port_to - это не канал на станции (на каждой - свой), а именно ID оператора (РТ, ТТК и т.п.). port_from можно аналогично использовать как ID "дочерних" операторов.

Было бы круто, если BGBilling имел готовый фреймворк для работы с сырыми данными, вёл топологию сети и т.п.

ps. Всё это со слов опытных товарищей. Вполне возможно, что у кого-то всё по другому.

У нас тут произошло слияние с компанией, у которой куча меди и АТС-ок и самописный биллинг на всё это (далее следует непереводимый итальянский фольклор).

Иерархия в виде дерева, как в Inet - неправильно. По факту АТС-ки - это облако. Один и тот же звонок проходит через несколько и попадает в несколько CDR. Связать их между собой явно обычно нельзя, т.к. нет сквозного id звонка. Есть самописные эвристические методы связки для дебага прохождения звонков, но это к биллингу не относится..

Можно, но мы достоверно не сможем сказать, на какого оператора межгорода ушел звонок в итоге.

Обсудили наше будущее с коллегами.
Что нам ещё нужно от Voice:
1. Производительность. Сейчас в Phone даже пустые файлы загружаются и обрабатываются довольно долго (по-моему, он для каждого файла CDR инициализирует некий контекст, даже если он пустой). Нет парллельной обработки, хотя бы как в IPN (process.thread.count=6).

Обсудили наше будущее с коллегами.
Что нам ещё нужно от Voice:
1. Производительность. Сейчас в Phone даже пустые файлы загружаются и обрабатываются довольно долго (по-моему, он для каждого файла CDR инициализирует некий контекст, даже если он пустой). Нет парллельной обработки, хотя бы как в IPN (process.thread.count=6).