Carbon billing 5, обсуждение

[Saab95]

14 часов назад, De1m0s сказал:

Если делать услугу, которая активируется при определенных условиях и делает списание за абонентскую линию, то это тоже вызывает большие вопросы у абонентов, так как они видят ее в ЛК.

Можно через отчет в последний день месяца получить список абонентов, которые заблокированы. Через стороннее ПО через запросы REST API подключить всем абонентам услугу за абонентскую линию. Тип списания - за весь месяц, дополнительные опции - отключить через 1 активацию.

 

В этом случае у абонента произойдет списание за услугу и на конец месяца в акте у него будет это списание.

 

14 часов назад, De1m0s сказал:

Ну и для отчетов по связи не удобно оставлять должников в своих тарифах, а так все активные (платящие абоненты) в своих тарифах, не активные в должниках.

Должников можно исключить из отчетов и все.

 

Вообще есть срок 6 месяцев, в течении которого абонент должник является абонентом. И целесообразно его держать в своей папке и на своем тарифе. И уже после отключать (удалять) его и переносить в другие папки (корзину или тарифы для должников).

 

Кроме всего есть вариант уменьшить стоимость тарифов на 100р. и оставить услугу оплаты за абонентскую линию на постоянной основе. Тогда всегда будет списание за линию + стоимость тарифа сверху.

 

 

[De1m0s]

9 часов назад, Saab95 сказал:

Можно через отчет в последний день месяца

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

 

 

9 часов назад, Saab95 сказал:

Вообще есть срок 6 месяцев, в течении которого абонент должник является абонентом

так да не совсем так. п. 58 Правил оказания телематических услуг связи от 2021 года (старые уже не действуют):
"... Если абонент не устранит нарушение в течение 6 месяцев со дня получения им письменного уведомления оператора связи о намерении приостановить оказание телематических услуг связи, оператор связи вправе расторгнуть договор об оказании услуг связи в одностороннем порядке."

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

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

[Saab95]

13 часов назад, De1m0s сказал:

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

Тут вопрос - а какая нагрузка и на что? Например при 5000 абонентах на биллинге, отправка блокировок при смене месяца занимает около часа. Отправляются данные примерно по 1000 абонентам, которые уходят в минус.

 

Подключение к оборудованию по SSH - отправка одной команды - отключение. Блокировка это:

 

1. Удалить IP адрес абонента из списка должников (мало ли что он там по какой-то причине был).

2. Добавить IP адрес абонента в список должников.

3. Пауза 1 секунда.

 

То есть смена статуса одного абонента это отправка 2-х команд через 2 отдельных, следующих друг за другом, подключения по SSH.

 

Если предположить, что нужно отправить 5000 блокировок 1-го числа - это займет 5 часов. Происходит в ночное время и не создает нагрузку ни на что. Биллинг продолжает работать, нагрузка на жесткий диск небольшая, ЛК без проблем открывается. Роутер, на который льются команды - так же нормально себя чувствует.

 

На 27 тыс. абонентов отправка команд блокировок на 4 разных маршрутизатора для 4-8 тыс. абонентов занимает около 8 часов, как раз к началу рабочего дня все уже отправлено.

 

13 часов назад, De1m0s сказал:

Это хорошая идея, если стоит списание первого числа. У нас настроен сдвиг списания следовательно у каждого абонента должна быть своя дата активации услуги за пользование линии.

Вот корни проблемы растут от не верно выбранного способа списания - решили делать плавающий период, от этого проблемы. Решить их простыми способами нельзя - значит биллинг плохой 😃

 

Производная такой штуки это ежедневное списание, когда абонент может оплатить за 10 дней вперед и 10 дней отработать. Может оплатить за 2 дня и 2 дня работать. Биллинг, при этом, постоянно совершает финансовые операции, закрывает периоды и т.п.

 

13 часов назад, De1m0s сказал:

"... Если абонент не устранит нарушение в течение 6 месяцев со дня получения им письменного уведомления оператора связи о намерении приостановить оказание телематических услуг связи, оператор связи вправе расторгнуть договор об оказании услуг связи в одностороннем порядке."

 

Тут вопрос в ущемлении прав. Когда абонент подписывал договор, то в договоре указана ответственность сторон, в том числе и обязанность абонента своевременно оплачивать услуги, и там же в пункте о расторжении договора указано, что если абонент не пользуется более 6 месяцев и не оплачивает, то договор можно расторгнуть в одностороннем порядке.

 

Абонент, в таком случае, должен обратиться в суд с исковым заявлением, оплатить гос.пошлину - оно ему надо? Проще придти к провайдеру и восстановить подключение, если снова потребовался интернет. Если кабель остался на месте - даже за повторное подключение оплачивать не придется.

 

Отсюда следует и вторая проблема - перемещение должников в тариф для должников. Достаточно его 6 месяцев держать в своих тарифах / папках, а по истечении 6-ти месяцев просто удалять и все. При этом удаленный абонент все равно остается в базе, у него достаточно удалить учетные записи. При этом в комментарии можно указать его старый IP адрес, еще какую-то техническую информацию, которая может потребоваться при восстановлении.

 

13 часов назад, De1m0s сказал:

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

В отчете по абонентам можно сделать все исключения, например дата блокировки менее 6 месяцев. Тогда в отчет должники более 6 месяцев не попадут.

[ugolnowww]

Добрый день можете помочь со старым дистрибутивом может у кого есть carbonbilling 4 softrouter готов материально заплатить!!!

[tkama]

15 hours ago, ugolnowww said:

Добрый день можете помочь со старым дистрибутивом может у кого есть carbonbilling 4 softrouter готов материально заплатить!!!

Есть Carbon_Billing_master_5341197 от 2014 года, Carbon_Billing4_master_452_168 от 2015г. и Carbon_Billing4_master_452_318 от 2018г. Вам какой?

[De1m0s]

В 06.02.2026 в 22:44, Saab95 сказал:

Тут вопрос - а какая нагрузка и на что?

На радиус. Или настакивание событий. Да мы используем радиус на биллинге и отказаться от этого уже не можем.

В 06.02.2026 в 22:44, Saab95 сказал:

значит биллинг плохой

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

 

В 06.02.2026 в 22:44, Saab95 сказал:

что если абонент не пользуется более 6 месяцев и не оплачивает, то договор можно расторгнуть в одностороннем порядке

Условия договора, которое прямо противоречит закону - ничтожно. То есть его недействительность даже не нужно доказывать. Если бы ПП РФ было бы положение вида "если  иное не предусмотрено договором", то можно было бы делать так.

 

 

В 06.02.2026 в 22:44, Saab95 сказал:

В отчете по абонентам можно сделать все исключения

или не делать отчеты в биллинге и  просто проссумировать абонов в папочках.

[Saab95]

13 часов назад, De1m0s сказал:

или не делать отчеты в биллинге и  просто проссумировать абонов в папочках.

В таком случае и биллинг не нужен, можно в табличке экселя учет вести.

 

13 часов назад, De1m0s сказал:

Условия договора, которое прямо противоречит закону - ничтожно. То есть его недействительность даже не нужно доказывать. Если бы ПП РФ было бы положение вида "если  иное не предусмотрено договором", то можно было бы делать так.

Если у сторон разные точки зрения - не нужно вступать в полемику. Напишу лишь что за более чем 20 лет работы никаких обращений и жалоб по поводу отключения через 6 месяцев при отсутствии оплаты не было.

 

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

 

13 часов назад, De1m0s сказал:

Или настакивание событий. Да мы используем радиус на биллинге и отказаться от этого уже не можем.

 

Еще раз напишу - биллинг это биллинг, он ведет учет абонентов. Если нужен радиус то он не должен работать в составе биллинга - для этого устанавливают отдельный сервер, который и авторизует по радиусу абонентов. Встроенный радиус нормально обрабатывает 500-1000 абонентов, не более. Больше уже нужно выносить.

 

Кроме всего очень сильно на производительность влияет сам сервер:

 

1. Процессор должен быть современный и быстрый, с высокой тактовой частотой, достаточно 4-6-8 ядер.

Решения на базе процессоров с кучей медленных ядер (ниже 3ггц) не подходят.

 

2. Оперативная память должна быть быстрая, современная. Большой объем памяти не нужен (регистровые, буферизованные модули снижают производительность).

 

3. Жесткие диски должны быть быстрые, 10-15 тысяч оборотов, или SSD. При этом нужно выносить БД биллинга на другой диск, что бы система работала на системном, база на другом диске.

 

4. Сетевой адаптер должен быть быстрый, интел, желательно 10Г подключение по оптике.

 

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

 

 

[tkama]

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

[Saab95]

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

 

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

[Saab95]

Если удалить пустую папку с абонентами, поместить в корзину, то в окне выбора папок для переноса абонентов эта папка, в корзине, продолжает отображаться и в нее можно переместить абонента.

 

Этот вопрос, в скором времени, будет решаться?

[product manager CB5]

В 08.04.2026 в 00:10, Saab95 сказал:

Если удалить пустую папку с абонентами, поместить в корзину, то в окне выбора папок для переноса абонентов эта папка, в корзине, продолжает отображаться и в нее можно переместить абонента.

 

Этот вопрос, в скором времени, будет решаться?

Добрый день, так папка пустая или с абонентами? Создайте тикет в Helpdesk по этому вопросу с подробным описанием шагов воспроизведения. Попробуем воспроизвести, и если что-то не так - исправим.

[De1m0s]

@product manager CB5
Добрый день. Заявку наверное делать смысла нет (но если Вы посчитаете, что нужно то я сформирую). Столкнулся с такой ситуацией: у нас в городе одновременно везде выключили электричество и потом одновременно включили. Все абонентские роутеры разом начали запрашивать IP у DHCP сервера биллинга, выдача адресов и соответственно восстановление трафика до уровня падения происходило примерно в течении 20-ти минут. Возможно ли оптимизировать/доработать DHCP сервер, чтобы это происходило быстрее?
Биллинг версии 5.84.07 build 1111 master. База данных FB5.  

[Saab95]

12 часов назад, De1m0s сказал:

Возможно ли оптимизировать/доработать DHCP сервер, чтобы это происходило быстрее?

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

 

Что бы все работало быстро биллинг тут не поможет - нужен промежуточный сервер, который будет по API получать данные абонентов и уже передавать их при запросе, а сам биллинг в эти моменты ничего делать не будет.

 

Либо сам промежуточный сервер будет через API передавать данные на биллинг. Ограничения скорости и разрешения на подключение можно синхронизировать раз в сутки, если IP адреса динамические - то когда промежуточный сервер выдаст IP абоненту, он так же может через API установить этот адрес абоненту в биллинге.

[De1m0s]

В 17.04.2026 в 21:58, Saab95 сказал:

нужен промежуточный сервер

Такой функционал есть в нашем BRAS (СКАТ), там есть и DHCP, и Radius и даже dual stack DHCP, но тут ньюанс, по отзывам людей, от версии к версии бывает что начинает работать не очень. Что-то самописное не пойдет юридически, так как у нас КИИ с категорией, поэтому и приходится использовать реестровые решения.  Переавторизация Radius, кстати, проходит быстро.

[product manager CB5]

В 17.04.2026 в 11:17, De1m0s сказал:

@product manager CB5
Добрый день. Заявку наверное делать смысла нет (но если Вы посчитаете, что нужно то я сформирую). Столкнулся с такой ситуацией: у нас в городе одновременно везде выключили электричество и потом одновременно включили. Все абонентские роутеры разом начали запрашивать IP у DHCP сервера биллинга, выдача адресов и соответственно восстановление трафика до уровня падения происходило примерно в течении 20-ти минут. Возможно ли оптимизировать/доработать DHCP сервер, чтобы это происходило быстрее?
Биллинг версии 5.84.07 build 1111 master. База данных FB5.  

Добрый день. 

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

[De1m0s]

22 часа назад, product manager CB5 сказал:

Добрый день. 

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

Насколько я понимаю (поправьте если ошибся). Конфиг генерируется один раз в 10 минут. На момент массового запроса роутерами IP адресов, свежий конфиг сгенерирован не был, проверить скорость генерации возможности не было, так как проблема застала меня дома и пока мой роутер не получил IP я проверить ничего не мог.

[bike]

В 20.04.2026 в 09:09, De1m0s сказал:

Такой функционал есть в нашем BRAS (СКАТ), там есть и DHCP, и Radius и даже dual stack DHCP, но тут ньюанс, по отзывам людей, от версии к версии бывает что начинает работать не очень. Что-то самописное не пойдет юридически, так как у нас КИИ с категорией, поэтому и приходится использовать реестровые решения.  Переавторизация Radius, кстати, проходит быстро.

Что люди только не делают, продолжая жевать кактус.

Интегрируйте СКАТ как полноценный BRAS со схемой подключения L2 DHCP Radius Proxy и забудьте о проблемах.