BiTel

Не подскажите, в версии 4.4 хочу сделать самостоятельно определение цены на звонок. Все вроде нашел. Не могу найти привязку карты зоны map_id (таблица phone_zone_map_item_1) c клиентом или его тарифным планом?

Тариф привязан к договору, каждая ветка тарифа - отдельная запись. Конфигурация ветки - текстовое поле. Так что довольно сложно просто привязать.
Вам не для этого надо?
http://wiki.bgbilling.ru/index.php/Генерация_прайса_модуля_IP_телефонии_в_карточке_договора

Понятно. Спасибо за ответ.

Задача такая. Я реализую работу через Asterisk AGI для того, чтобы гибко настроить систему. То есть мне нужно динамическое определение стоимости звонка в билинге и далее передать на обработку системе.

А что, нельзя сделать привязку через табличные данные? Парсить по каждому поводу XML структуру - неблагодарное дело с точки зрения производительности. Наверно потому, обсчет муравьиными шагами происходит.

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

Понятно. Но для динамического расчета - это не то что нужно. У вас и IP телефония по такому принципу работает? Я просто не знаю.

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

да там и не xml по сути . Там можно все узлы достать одним sql-запросом .Просто каждый узел свои данные хранит по особому(там не xml, а скорее тектовый поле с разделитями, а ля csv) .можно было кончено зевести куча таблиц по одной на каждый тип узла , но так исторически сложилось что этого не сделали .Систем тарификации досточно сложная и сделана как иерархическая настройка над хранилещем и ей без разницы как храняться тарифы .

ИМХО надо заводить кучу таблиц.
Я в любом случае думаю, что в реляционной БД надо держать структурированные данные по таблицам, а ни в виде дерева даже того же csv в одной текстовой ячейке. Для того они и реляционные.

А может можно как то узнавать цену, запросом на ваше ядро?

А мы наоброт склонямся что весь тариф должен быть в xml а не гибридном виде как сейчас . так он будет более читаем и там нам его будет проще парсить. Это часть у нас это не реалиционная бд и нам так удобнее .

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

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

Мы сейчас делаем на базе FreeSwitch проверялку - есть ли доступ у абонента к IP телефонии. Не рискнули лазить для проверки по номеру звонящего в базу поинтов БГБ и делаем переодическую выгрузку в собственный postgres FreeSwitch'а.

Как в каменном веке.
Открою вам секрет. Это практически невозможно.