Раньше мы имели дело только с классическим биллингом, где задача была считать трафик по байтам и минутам.
Подсчет трафика никто не отменял, но этого мало.

Надо вести учет других категорий, таких как:
- DID (номер какой-либо страны, который редиректится на IP телефон)

- CallerId with name - это когда за 2.95$ в месяц можно сделать так, что при звонке клиента на экране видно его имя, а не номер.

- 500 VoiceMail сообщений в месяц.

- Услуга записи разговоров.

- Услуга возможности редактировать свой dial plan.

- Услуга Ringtone - это когда в IP телефон можно закачать мелодию, и прописать на нее чей-то номер.

- Услуга постановки звонков в очередь.

- Авторизация и учет ииспользования других возможностей Asterisk, таких как конференции, text-2-speech и тд.

Как мы видим, в рамках понятий направление-стоимость это все не подсчитать. Поэтому надо наверное абстрагироваться от деталей реализации и ввести универсальное понятие service, и определить процессы получения доступа, потребления, учета сервиса. Таким образом, чтобы при любой реализации на макроуровне модель сохраняла свои свойства и связи.

Предлагаю начать обсуждение сабжа в отдельном разделе портала с построением модели в DbDesigner'e.

P.S. Если у кого есть ссылки на последние веяния и концепции написания биллинга для сетей NGN, просьба поделиться.

Интересно кому-то?

Ясно

довольно интересно:
http://mx.ru/Lists/CGatePro/Message/12476.html?Skin=Russian

И что там про биллинг? :)
То, о чем там идет речь, я решаю на астере вообще без вопросов.

концептуально все просто.
вводиться кроме понятие "стоимость за минуту" еще 2 концепии
1) фактический - оплата по факту действия- сюда войсмейл, редактирования конфигов, очереди
считаеться по факту за каждый раз. записываеться в биллинг как звонок на номер (0000123 например) с длительностью 10 сек - 10 центов за факт 20 сек - 20 центов за факт етс.
+ сюда же концепция "бесплатных минут" - это твои 500 бесплатных сообщений.
самый простой метод "бесплатного - отдельный счет". тогда звонок идет так - если на "бесплатном" счету есть деньги - снимаем стоимость и звоним как на номер 0000123. если нет - звоним с аккаунт-кодом основного счета как на номер 0000123"
в результате в биллинг попадают на основной счет только превышения.
историю не превышенных можно только на доп счете посмотреть. раз в месяц доп. счет ставиться "на 500 минут"
биллинг при лукапе на номер 0000123 выдает цену 1/60 цента за минуту и направление описывает как "доп. услуга входящих сообщений". тогда цена получаеться стоимость этой услуги

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

преимущества
редактирования биллинга при этом минимальны.

недостатки:
нагружает биллинг ненужными поисками по направлениям, лишними записями. лечиться заменой на вызовы сразу с "посчитанными" значениями(если ваш биллинг такое позволяет)
для категории 2) приходиться писать спец шедулер который переписывает дилпланы в зависимости от того оплачено/неоплачено. как минимум раз в месяц. для категории 1 - то же самое в начале месяца. как вариант можно делать это при первом звонке в месяце- не сильно меняет ситуацию.

что-то непонятно? ;)

Пора взглянуть на мир чистым взглядом, незамутненным категорями биллинга для терминации трафика :)
В атаче картинка. В ней реализована модель для учета:

1. Flat, per month package for one or multiple destinations, example:
50 USD for any +1 destination
Or combination, example:
30 USD for 2000 mins to +1 plus 0,02 per minute additional
mins
Or
30 USD for land +30 plus 0,18 per mins for +306
Or
50 USD for land +44 plus land +33 plus land +30 ...
2. DID/monthly for each DID, buy as many DID as he wants.
3. Caller ID with name/monthly
4. Masquerade Caller ID/Monthly (We will have and a calling card separate
service, I will explain about that). If the user has paid that service, a
caller ID field will be available and he may change it whenever he wants.
5. Conference/monthly

Сейчас работаем над интеграцией с authorize.net для оплаты услуг с карточки.

Оккама помнишь?
не размножайте сущности без необходимости.

имхо, черезчур сложная схема. и неуниверсальная...
и , кажись, под нее не пишуться "быстрые" sql.. впрочем если нагрузка будет не велика - вполне нормально.для 1-5 * пойдет - дальше будут проблемы.
зы я могу ошибаться.

Добавлю что в кач-ве backend'a используется MySQL 5.0.18 и используются хранимые процедуры.
Не понял, что Вы meral, сказали о 1-5. Звонков? Астерисков?
Не стоит задача биллить клиента за каждое дижение мышкой или звонок в конференцию или в voicemail. Повременная тарификация уходит в прошлое. Клиенту надо давать набор услуг за абон плату.
Допишу биллинг - покажу схему :)

имел в виду до 5 астерисков. т.е до 250 звонков(500 каналов).
просто я прикинул скоко по такой схеме надо сделать вызовов в БД. получилось многовато.
250 звонков с средней длительностью 2.5 минуты ~ 100 обработок в минуту.
теперь по вашей схеме просмотрите скоко вызовов надо на одну обработку. в том числе для определения к какой категории звонок принадлежит... впрочем я не проводил полный анализ... так просто проглядел.
к тому же, на своем опыте, на * картина не типичная - очень большое количество перезваниваний на занятые номера - номер быстро набираеться. в результате реально количество звонков в пике будет больше.
впрочем, я думаю, вы такой анализ провели перед проектированием. какой результат если не секрет?
впрочем здесь еще все зависит от диалплана...причем кажись больше чем от БД. надо поразмышлять. но в любом случае будет не меньше одного обращения к БД - надо как минимум определить к чему относиться звонок/услуга.