BiTel

Вопрос такой. reject_to_accept попробовал, не совсем подходит, т.к. сессия при этом не отображается в мониторе.
Мне нужно чтобы модуль авторизовывал абонента несмотря на баланс, и корректно отображал сессию.
При этом лимит оставить нулевой. По сути нужно просто как-то выключить проверку баланса при авторизации.


Идея такая:

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

По сути проблема здесь в том, что у разных услуг на одном договоре общий баланс.
Я бы просто pppoe выносил на отдельный независимый субдоговор тогда. Правда счет по нему тоже будет отдельный, хм.

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

Общий баланс как раз не проблема, а задумка. Ппп и так является субдоговором, но с зависимым балансом. Получается чтобы купить тарифную опцию, сначала придется погасить долги.



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

По идее если бы было событие активации тарифной опции - можно было бы в нем проигнорировать лимит и не разрешать уходить в минус..

идея хорошая, но ... но реализация, IMHO, в корне не верная ... почему? потому что через СоА, ЕМНИМС, можно поменять все что угодно что касается сессии, кроме ее IP адреса

Мне кажется вы не совсем так поняли что я хочу.
Если кратко - использовать функционал схожий с учетными периодами, только с помощью тарифных опций.
Т.е. если опция неактивна - интернета нет вообще. Активировал на месяц - пользуешься месяц, как с учетным периодом.

А как включать/выключать доступ по сути не важно. Проблема пока только в том что нельзя авторизоваться при баланс<лимита.

понял я ... понял ... идея красивая, мне нравится!


эм ... читаем мануал

и как вариант проделываем следующий финт ушами - в скрипте предобработки проводим необходимые тесты (наличие опций и т.д. и т.п.) суть которых выявить главное - это 1-е подключение и у клиента ничего не подключено, после этого либо ложим ему на счет некую опред. сумму с опред. типом платежа a-la "фиктивный" (это предпочтительнее, т.к. позволит потом оный платеж удалить) или понижаем ему лимит (это менее предпочтительно, т.к. восстановление лимита может затронуть этот фиктивный лимит) для того чтобы обмануть БГБ и впустить клиента в систему (его пустит, т.к. у него положительный баланс ну или понижен лимит), после чего клиент ложит деньги и активирует опции включая себе доступ на опред. время ну а мы по событию прихода (факт поступления $ на счет) платежа удаляем фиктивный платеж или восстанавливаем лимит который был нужен только для того чтобы чтобы юзера впустило ... думаю что как то так ...

Прикольный замысел конечно .
Можно попробовать пойти дальше. Чтобы ВСЕГДА авторизовывало, может быть на этапе "скрипт предобработки" лимит понижать, а потом после успешной авторизации в "обработка события "RADIUS-аутентификация" лимит обнулять!! Вот костыль будет всем костылям! Проверю сегодня такой метод.

когда надо надурить систему приходится поизвращаться