BiTel

На данный момент при превышении ограничения количества сессий для сервиса новые сессии подключаются с отключенным доступом. Возможна ли такая реализация, чтобы для новых сессий формировалась нормальная сессия, а самая старая сессия при этом закрывалась?
Приведу пример. У абонента стоит ограничение на 1 сессию, он подключил компьютер - доступ есть. Решил подключить вместо компьютера роутер, но доступа в Интернет нет. Абонент начинает нервничать, хорошо если позвонит в техподдержку, а ведь может и другому оператору позвонить.

_________________
Клиент: вер. 7.2.198 / 19.08.2019 19:30:12
Сервер: вер. 7.2.1061 / 19.08.2019 19:32:26
card: вер. 7.2.201 / 24.07.2019 03:56:11
dialup: вер. 7.2.303 / 04.07.2019 17:11:44
inet: вер. 7.2.639 / 19.08.2019 19:32:59
ipn: вер. 7.2.232 / 19.08.2019 19:32:53
mps: вер. 7.2.177 / 08.08.2019 16:32:31
npay: вер. 7.2.174 / 25.07.2019 19:48:57
phone: вер. 7.2.260 / 08.08.2019 16:32:32
reports: вер. 7.2.203 / 12.08.2019 21:56:13
trayinfo: вер. 7.2.160 / 25.06.2019 16:47:08
voice: вер. 7.2.63 / 19.08.2019 19:33:01
voiceip: вер. 7.2.176 / 25.06.2019 16:46:56

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

Вы не поняли логику, абонент компьютер отключил(соединение разорвалось, но определенное время сессия висит на сервере и в биллинге, в случае с DHCP это порядка 20-30 минут) и подключил вместо компьютера роутер или другой компьютер, на новом устройстве доступа не будет пока не закроется сессия в биллинге по таймауту, фактически в течение этого промежутка времени доступа к услуге у абонента нет. Т.е. логика такая - один провод, одно абонентское устройство, т.е. приоритет имеет последнее подключенное устройство, что вроде бы выглядит логичным. Если у абонента стоит свитч, то в этом случае будет глючить при любом варианте реализации ограничения количества сессий.

_________________
Клиент: вер. 7.2.198 / 19.08.2019 19:30:12
Сервер: вер. 7.2.1061 / 19.08.2019 19:32:26
card: вер. 7.2.201 / 24.07.2019 03:56:11
dialup: вер. 7.2.303 / 04.07.2019 17:11:44
inet: вер. 7.2.639 / 19.08.2019 19:32:59
ipn: вер. 7.2.232 / 19.08.2019 19:32:53
mps: вер. 7.2.177 / 08.08.2019 16:32:31
npay: вер. 7.2.174 / 25.07.2019 19:48:57
phone: вер. 7.2.260 / 08.08.2019 16:32:32
reports: вер. 7.2.203 / 12.08.2019 21:56:13
trayinfo: вер. 7.2.160 / 25.06.2019 16:47:08
voice: вер. 7.2.63 / 19.08.2019 19:33:01
voiceip: вер. 7.2.176 / 25.06.2019 16:46:56

Alex-XXI а суть то не меняется, то что описал Cromeshnic и в этой ситуации возможно

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Какая схема доступа?

CLIPS, авторизация по порту коммутатора

_________________
Клиент: вер. 7.2.198 / 19.08.2019 19:30:12
Сервер: вер. 7.2.1061 / 19.08.2019 19:32:26
card: вер. 7.2.201 / 24.07.2019 03:56:11
dialup: вер. 7.2.303 / 04.07.2019 17:11:44
inet: вер. 7.2.639 / 19.08.2019 19:32:59
ipn: вер. 7.2.232 / 19.08.2019 19:32:53
mps: вер. 7.2.177 / 08.08.2019 16:32:31
npay: вер. 7.2.174 / 25.07.2019 19:48:57
phone: вер. 7.2.260 / 08.08.2019 16:32:32
reports: вер. 7.2.203 / 12.08.2019 21:56:13
trayinfo: вер. 7.2.160 / 25.06.2019 16:47:08
voice: вер. 7.2.63 / 19.08.2019 19:33:01
voiceip: вер. 7.2.176 / 25.06.2019 16:46:56

http://bgbilling.ru/v6.0/doc/ch17s13s03s01.html
Посмотрите про radius.connection.checkDuplicate. Если один провод - одно устройство, вам должно подойти radius.connection.checkDuplicate=888.

"Один провод - одно устройство" - это частный случай, конечно может быть на одном проводе ограничение на несколько сессий.
Для 5.2 формат опции такой же? В доках на 5.2 этот раздел немного отличается.

_________________
Клиент: вер. 7.2.198 / 19.08.2019 19:30:12
Сервер: вер. 7.2.1061 / 19.08.2019 19:32:26
card: вер. 7.2.201 / 24.07.2019 03:56:11
dialup: вер. 7.2.303 / 04.07.2019 17:11:44
inet: вер. 7.2.639 / 19.08.2019 19:32:59
ipn: вер. 7.2.232 / 19.08.2019 19:32:53
mps: вер. 7.2.177 / 08.08.2019 16:32:31
npay: вер. 7.2.174 / 25.07.2019 19:48:57
phone: вер. 7.2.260 / 08.08.2019 16:32:32
reports: вер. 7.2.203 / 12.08.2019 21:56:13
trayinfo: вер. 7.2.160 / 25.06.2019 16:47:08
voice: вер. 7.2.63 / 19.08.2019 19:33:01
voiceip: вер. 7.2.176 / 25.06.2019 16:46:56

Да, в 5.2 должны поддерживаться параметры radius.connection.checkDuplicate, что есть в документации 6.0.