BiTel

To: разработчики
Как в вашей концепции модуля Inet планируется делать связь между тарифными планами и предоставляемыми сервисами?
В примерах на wiki, насколько я понял, сервисы и как следствие их опции вешаются на договор в модуле Inet.
Допустим у нас есть сервисы: open garden, локальный трафик, внешний трафик + разные редирект сервисы, которые включаются вместо локального и внешнего, open garden - это доступ к порталу, биллингу и он есть всегда. Тарифные планы имеют разную скорость внешнего трафика. Т.е. для внешнего трафика создан набор сервисов, которые отличаются лишь скоростью.
Как связать ТП и сервисы? Чтобы при изменении ТП, деактивировался старый сервис и включался новый, соответствующий новому ТП.
Как связать разные наборы ограничений по времени с разными сервисами? Т.е. например днем один сервис с одной скоростью, ночью другой, с другой скоростью.
Как все это делается в модуле Dialup - понятно. Но в Inet вешать атрибуты в ТП, не изменяя набор сервисов в модуле инет, я думаю как-то криво наверное.

И с учетом таких сервисов, которые отличаются лишь скоростью тоже не все понятно. В ISGProtocolHandler есть такой код:

Т.е. новые атрибуты с трафиком состоят частично из имени сервиса. У сервисов, отличающихся скоростью разные имена, но суть одна - внешний трафик. И этот код тут совсем не в тему.
Перечислять в коде все имена сервисов внешнего трафика или их маску и мапить их в одни и те же атрибуты - как-то тоже не очень прямо, т.к. их может быть много и в коде такое держать не хорошо.

В wiki по сервисному аккаунтингу информация похоже устарела. Смотрите классы
ru.bitel.bgbilling.modules.inet.dyn.device.cisco.ISGProtocolHandler
ru.bitel.bgbilling.modules.inet.dyn.device.cisco.ISGServiceActivator
в папке dyn сервера.

Сервисы ISG привязываются к опциям модуля Inet. Т.е. по определенной опции назначается определенный сервис.
Таким образом сервис можно менять/переназначать не только в зависимости от тарифа, но и в зависимости от условий тарификации.

При изменении набора опций вызовется метод connectionModify в ISGServiceActivator, где вызовется
sendCommands( connection, optionsToServiceNames( removeOptions, null ), optionsToServiceNames( addOptions, null ) );

Сервисный аккаунтинг делится на типы трафика так:
http://bgbilling.ru/v5.2/doc/ch18s12s03 ... l#d0e17681

Т.е. ru.bitel.bgbilling.inet.dyn.device.isg.ISGProtocolHandler устарел?



Что-то я не совсем понял. Структура такая:


В этом случае на сессии будут активироваться только те сервисы, чьи опции определены в ТП?
А если опции сервиса нет в ТП, то он активироваться не будет?
Так?



Т.е. теперь перетаскивать байты в cisco-av-pair=prefix: не нужно и их можно сразу брать из стандартных атрибутов аккаунтинговых пакетов сервисов, если указать их в коде вендора и коде атрибута? Как быть с Acct-Input/Output-Gigawords? Они обработаются если указать там 42 и 43 атрибуты?

Да, обратите внимание на пометку @Deprecated перед определением класса - так в java помечаются устаревшие классы и методы, нежелательные для использования. При выборе классов в Типе устройства такие классы также помечены как (устаревший).
В управлении динамическим кодом также наверно сделаем пометку, чтобы сразу видно было.
Да, стандартные поля нужно указывать как -2 1 и -2 2, в этом случае Gigawords подхватываются автоматически:
http://bgbilling.ru/v5.2/doc/ch18s04.html (внизу)

Может быть вы путаете сервисы ISG и сервисы модуля Inet? Это разные сущности и напрямую они не связаны.
Сервис в модуле Inet - это как логин в модуле Dialup или диапазон в модуле Inet.
К сервису можно привязать опции модуля Inet - напрямую, либо в тарифе. При смене этих опций происходит вызов connectionModify, где в зависимости от набора опций можно открывать/закрывать сервисы ISG.

Т.е. например, так:

Для сессии выдаются опции из тарифа И опции сервиса.

А когда именно на сервис в договоре вешаются опции из тарифного плана? Т. е. какое событие должно произойти, чтобы при смене тарифного плана с установленными опциями поменялись активные опции сервиса и был вызван метод connectionModify?
Сейчас наблюдаю следующую картину: при изменении (добавление/удаление) тарифа с установленной опцией X никаких изменений в активных опциях сервиса не происходит судя по логам и статусной строке в свойствах сервиса. Но стоит нажать на Сохранить в окне редактирования сервиса, то в логах видно, что происходит изменение активных опций и, соответственно, вызывается метод connectionModify. При этом в статусной строке никаких изменений в активных опциях нет. Нажимаем ещё раз Сохранить, и видим, что повторно вызывается метод connectionModify (по логам) и активные статусы теперь соответствуют действительности.
Без кнопки Сохранить изменения тарифного плана никак не влияют на активные опции!
В общем, что-то где-то не доделано.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Сейчас должно быть - при аутентификации, при обсчете (т.е. как только появляется активная сессия и на протяжении ее действия), при сохранении сервиса.

Задержки в конфигурации Accounting устройства не большие? Оба тарифа правильные, т.е. не происходит вызова connectionClose (вместо connectionModify)?

А если сервис не предполагает никакого аккаунтинга? Нужно просто пнуть железку для изменения параметров.

Сегодня тестировал модуль Inet на вызов метода serviceModify и вот что выяснил:
1. При аутентификации (после получения Access-Accept) вызова метода не происходит. Возможно, есть опция, которая влияет на это, но где она, я пока не нашёл.
2. При удалении последнего тарифа из тарифных планов договора текущая сессия, такое чувство, не убивается. Это видно в отчёте договора. Также при этом не происходит вызова serviceModify, но вызывается connectionModify. В принципе, меня это устраивает, но выглядит странно. Такая подвисшая сессия завершается обычным стопом.
3. Так и не увидел в логах вызова метода onAccountingStart, зато увидел onAccountingStop - тоже довольно странное поведение.
4. Ну и на последок, прошу пояснить, почему сессии не сохраняются в истории при завершении текущей сессии. При этом в текущих сессиях она видна (если сессия активна), но при получении стопа она сразу исчезает?

Прошу прокомментировать описанные выше проблемы.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

В продолжение предыдущего сообщения:
5. Когда происходит вызов метода "destroy()". Вызов метода init() происходит при старте сервера BGInetAccess. Логично предположить, что метод destroy() должен вызываться при остановке этого сервера, но, судя по логам, этого не происходит.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Уважаемые разработчики, будут ли какие-нибудь комментарии?

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

На данный момент такой вариант не поддерживается, т.е. при смене тарифа без аккаунтинга ничего не произойдет. serviceModify вызывается один раз при обнаружении изменения набора опций модуля. connectionClose на прямую вызывается только при обнаружении, что количество текщих сессий на сервисе больше, чем максимальное. По умолчанию же вызывается connectionModify с e.newState==DISABLE, а там уже либо закрывается доступ (если схема работы без разрывов соединения), либо вызывается connectionClose. Можете посмотреть код ru.bitel.bgbilling.modules.inet.dyn.device.radius.CoAServiceActivator.connectionModify в динамических классах. В модуле inet текущие сессии и завершенные отображаются отдельно, кнопочки "Текущие" и "Завершенные" ("Логи" в мониторе). destroy вызывается когда нажимаете кнопку "Перечитать конфигурацию" - у старого обработчика вызывается destroy, у нового - соответственно, init. То, что не вызывается также при стопе - ошибка, в ближайших билдах выложим исправление.

Вы ранее писали, что активные опции сервиса обновляются при наличии изменений в том числе при аутентификации. В реальности этого не происходит. Т. е. я поменял тарифный план на тарифный план с другими опциями сервиса и отправляю Access-Request. После получения ответа активные опции не изменились! Только после отправки Accounting произошло обновление активных опций. Либо вы неправильно писали ранее, либо есть косяк в биллинге.


Ну а то я не догадался на кнопочки понажимать ...
В том то и дело, что при отправке Accounting пакетов во вкладке "Текущие" сессия появляется и висит там, пока не придёт Accounting Stop пакет. После отправки стопа, сессия из вкладки "Текущие" исчезает, а во вкладке "История" не появляется или появляется и тут же исчезает.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91

Таинственным образом сессии начали сохраняться в истории.

_________________

Клиент: вер. 6.2.873 / 04.12.2017 19:38:11
os: Windows 7; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_65
Сервер: вер. 6.2.1202 / 04.12.2017 19:39:21
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_91