BiTel

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

NAS - MPD 5.2 на FreeBSD

bill вер. 4.5 сборка 160 от 04.02.2009 21:36:39
dialup вер. 4.5 сборка 112 от 04.02.2009 13:07:12

нарисовать скрипт на смену тарифа в котром и сбрасывать?

Можно немного подробнее? Что должно быть в скрипте (какая команда) и к какому событию он должен быть привязан?

Вообще это достаточно просто по snmp организовать только надо чтобы прислали нужые параметры в скрипт, ну и соответственно только на PC работать будет.

скрипт должен быть привязан к событию "смена тарифного плана по заданию пользователя", а вот как там сбросить ... надо почитать ман по API ... грубо говоря - в скрипте надо воспроизвести то что делает dialup модуль когда Вы нажимаете "сбросить"

UP
Аналогичная проблема. При смене тарифа через клиента все ок, сессия разрывается. А через веб, остается активной. В момент разрыва в радиус пакете нашел стандартные атрибуты апдейта, а затем вот это
Опишите, как решили? Желательно с кодом. Потому как текущее поведение системы абсолютно нелогично.

Так, с командами разобрался. Правильнее командовать NASом по телнету или SSH, тогда можно (да и правильнее) обойтись без разрыва сессии. А вот с логикой работы события, как писал не работает. Уважаемые разработчики, обратите внимание: вы предлагаете нам логику события "смена тарифного плана по заданию пользователя", а реализуете логику "Задание пользователя на смену тарифного плана", т.е. событие генерируется в момент нажатия кнопки пользователем, а не в момент смены тарифа. Пожалуста, поправьте положение, или предложите другое решение фиксации момента смены тарифа.

Обновление выложено. При смене тарифа через Web также должно рвать сессию.


Тариф меняется сразу будущим числом.

Что это значит?

Ну запись в базу о новом тарифе сразу производится. Но будущей датой. Непосредственно момент перехода на обсчет по новому тарифу событием не обозначен.

Обновил, начал пробовать....
добавил задание на смену тарифа с 21 числа для пробы, буду ждать границу суток, но.. какой практический смысл рвать сессию в момент создания задачи на смену тарифа будущим числом? Ведь абонент всё равно реконектится на старый тариф, т.к новый еще не вступил в действие.
Т.е. как это не обозначен?!!!Я конечно прошу прощения, но слова "момент" и "событие" в русском языке по смыслу если не тождественны, то очень близки. И посему я вправе расчитывать, что "событие" произойдет в обозначенный "момент". Потеряно слишком много времени, в расчете на заявленный функционал. Считаю, что с Вашей стороны не довести до ума имеющееся событие смены тарифа будет по меньшей мере невежливо. А разрыв сессии на границе тарифов реализовывать к примеру отключаемым. Кто сможет, напишет для своего наса скрипты и будет командовать по телнету, кто не сможет, будет рвать сессию.

Ну вот стоит у него план с 1 го числа и до бесконечности. В момент авторизации RADIUS считывает все тарифы которые будут действовать в будущем. Если тариф сменился с 21го числа, радиус об этом не узнает, будет считать по старому тарифу. Поэтому идет команда на сброс, после которой новая авторизация и радиус считает снова что до 21 старый тариф, а после 21 новый.



Хм, вы требуете от нас сделать что-то, апеллируя к русскому языку?

Отследить переход между тарифами впринципе можно, устанавив зоны в каждом из тарифов. См. доку. По зоне сделать событие прихода платежа, например. А по событию платежа этого типа менять что-то на NASе. Например, так.

Я пытаюсь изъясняться, надеюсь, на понятном Вам языке. if (Вы заинтересованы в диалоге), {можем перейти на другой};. else {дальше можно не читать}; Аргументы с очевидными вещами я привел выше. Да и потом, конкуренция сейчас смещается в плоскость user-friendly и его величество userу, глубоко "начхать и нас*ать" на адреса, протоколы, NASы, радиусы, биллинги и на то, как оператор, или тем более, разработчик хотят видеть ЕГО личный кабинет. Главное, чтоб с его точки зрения было комфортно, удобно, логично и понятно и самое главное "не было ни единого разрыва" . (за данной фразой все права сохраняются). Так что за наезд и лирическое отступление извиняйте, я просто передаю то, что хочет наш с Вами общий Друг, но наша задача ограничить его в рамках нашей рентабельности незаметно для него самого.
Буду тыкаться.

Вам всего лишь хотели сказать , что событие/или момент(что да вас одно и тоже) перехода на новый тариф в реальной жизни не обозначен СОБЫТИЕМ В BGBILLING, под событем в BGBilling понимается , некоторое специально иницированное биллингом событие , которое может быть обработано скриптами .. Русский язык тут не при чем .. оно, это событие биллингу не нужно просто .. в любом месте где нужен тариф , он просто берется на нужную дату и все .. чтобы получть ваше событие , надо соазвать какой-то процесс, который будет запускаться где-нибудь в конце дня (или в начале следующего) и проверять не изменился ли тариф на границе суток , и если да, то генерировать событие( с точки зрения биллинга опять же, а не просто событие с точки зрения русского языка).. можете сделать это скриптом по обработке события таймера

Спасибо за более понятный ответ.
правильно ли будет вести такую проверку?

В какой момент лучше запускать этот код? в 23.59 или в 0.01?

запускает лучше 0.10 .. и может во такой код сделать: