BiTel

Хотелось бы узнать у общественности, насколько востребован функционал - смена типов правил (скорости) в тарифе ipn?
вижу следующие случаи. В большинстве случаев у нас типы правил задают скорость(либо номер acl, с которой связана скорость )
1.скорость зависит от тарифа, меняется тариф - меняется скорость .
2. скорость зависит от времени суток (фильтр по времени, период)
3. скорость зависит от наработки по конретной услуге .

Сейчас скорость меняется в задаче "Обсчет логов IPN", что не совсем корректно . в 5.0 возможно вынесем ее оттуда и сделаем отдельной задачей . С 1 и 2 случаем вроде пока все ясно. Вопрос нужен ли 3-тий случай ?

3 случай попадает под псевдобезлимиты.
Мы такое используем на Dialup, на высоких скоростях...

псевдобезлимит - это типа если накачал бошьше 10 гиг, то скорость уже будет не 10 мбит как обещано, а 128 кбит ?

Да Только порядок цифр больше
Канал 1500, при достижении 120 гигов, скорость режется вполовину
Естественно это указывается в условиях тарифного плана...

Первые два однозначно нужны.
Третий то же используем в модуле DialUP, конечно хотелось бы и в IPN, только чтоб это встроенный функционал, а не писание самим скриптов на яве, не все владеют...

по 3-му пункту. услуг может быть несколько . например входящий трафик, исходящий и локальный . Учитывать надо тольку одну из них ? или например, "если наработка по исходящему трафику > 200 ИЛИ наработка по входящему трафику > 1000 " то поставить скорость 128 кбит/с ?

Однозначно как во втором случае....

в dialup у вас этого нет..

Да нет. Но как хочется.. Это было в другом билинге, с которого мы ушли...

Если 3 случай будет учитывать сам факт существования услуги (есть услуга на договоре - одна скорость, нет услуги - другая) будет еще лучше.

Пытался реализовать смену правил при смене тарифа через BGBS, но не могу найти в доке к API как получить тип правила для текущего тарифа?

Можете подсказать? Спасибо

вот тут есть пример :
http://bgbilling.ru/forum/viewtopic.php ... highlight=

Хорошо, допустим мы как-то сделаем смену правил в тарифе . делать ли пункт 3 и как его делать это еще вопрос.

Есть еще один вопрос . Какие шлюзы должны поддерживать эту смену правил . Тут дело в проверке. Раньше проверялось просто открыт/закрыт клиент. А теперь надо проверять что сменилась скорость(тип правила).

1. Manad . вот тут сделали manad со сменой правил :
http://bgbilling.ru/forum/viewtopic.php ... highlight=
Мы можем сделать нечто похожее.

Далее это уже наверное интересно только автору. В том варианте проверка на существование клиента/правила сделана в самом манаде и не очень эффективна в общем случае . Т.е если есть несколько договоров на шлюзе, то для каждого будет вызываться эта проверка . Более правильно было бы встроить в команды test перадачу не просто cid-ов(договоров), а пар cid-код правила И проверять если правило сменилось , или вообще нет пары , то посылать команду на manad.

2. Mikrotik. тоже уже есть пример:
http://bgbilling.ru/forum/viewtopic.php ... highlight=

только в нем правило берется сразу из тарифа . Можем сделать нечто подобное. В коментариях комнад mikrotik кроме кода договора(CID) будет еще и номер правила. Будет проверяться наличие договора и номера правила. Скорее всего проверка это не подойдёт всем , поэтому она будет опционально отключаться.

3. Cisco

Нужна ли поддержка смены правил? как менять скорость в стандартном варианте? - сменой acl ?

у нас для работы с cisco есть 2 шлюза - cisco и cisco2 . Первый просто проверяет в наличие правил по определенно позиции а acl и по их наличиюб решает открыт клиент или нет . Cisco2 - сделан проще там нет проверок вообще никаких, т.к в общем случае они могут быть любыми и поэтому там реализация проверки сделана в конкретных скриптовых шлюзах .. Есть пример один с проверкой в wiki. А стандартный вариант cisco2 шлет комнады всегда и он правило сменит по любому ..

хотелось бы выяснить нужен ли какой-то общий механизм смены правил на cisco. Или не заморачиваться и оставить это все на откуп скриптовых шлюзов .

4. Дочерний шлюз zyxel также как и cisco2 не делает в стандартном варианте никаких проверок и тоже работает всегда, теоретически он тоже сменит правило. Есть пример один пример с проверкой в wiki. Поддержать какую-то одну схему проверки стандартную наверное нет смысла., т.к в общем случае это может быть любой коммутатор любой модели, например dlink.

По сабжу
Все 3 пункта востребованы, хотя 3й все же в меньшей степени

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