[product manager CB5]

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

Уже внедрили telegram, работает в экспериментальной версии, все супер. Можно ждать в обновлениях через пару мес. 

К сожалению, есть проблема с whatsup - у них нет API и использовать его таким образом легально нельзя. Мы взломали протокол и даже довели его до рабочего состояния в биллинге, но каждый раз при обновлении whatsup'а все ломается, а спрогнозировать это и оперативно отследить не получится. Чинить каждый раз в экстренном порядке нет желания - занимает минимум день, при этом его протокол обновился 2-3 раза за две недели. Поэтому whatsup видимо не появится, хотя самый популярный мессенджер.

 

[Kolunchik]

Спасибо большое.

А после вайбера и телеграма вы не подумаете в сторону https на админке?

[ima]

Есть желание посмотреть на Carbon provision и по тестировать его (с интеграцией с другой биллинговой системой).

[No_name]

В 17.11.2017 в 12:31, product manager CB5 сказал:

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

Уже внедрили telegram, работает в экспериментальной версии, все супер. Можно ждать в обновлениях через пару мес. 

К сожалению, есть проблема с whatsup - у них нет API и использовать его таким образом легально нельзя. Мы взломали протокол и даже довели его до рабочего состояния в биллинге, но каждый раз при обновлении whatsup'а все ломается, а спрогнозировать это и оперативно отследить не получится. Чинить каждый раз в экстренном порядке нет желания - занимает минимум день, при этом его протокол обновился 2-3 раза за две недели. Поэтому whatsup видимо не появится, хотя самый популярный мессенджер.

 

Да работа не малая проведена наверно.

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

А смс доступно всегда, если только телефон не выключен, и абонент всегда получит смс.

А насчет экономии, так это оператор будет экономить на смс, он же рассылает их, а не клиент, а для клиента они вообще "бесплатно" включены в абонентку.

imho

[product manager CB5]

В 19.11.2017 в 10:54, Kolunchik сказал:

Спасибо большое.

А после вайбера и телеграма вы не подумаете в сторону https на админке?

А зачем? админка отлично защищена. 

 

3 часа назад, ima сказал:

Есть желание посмотреть на Carbon provision и по тестировать его (с интеграцией с другой биллинговой системой).

Да, супер. Отправьте запрос на info@carbonsoft.ru c контактными данными, данными о биллинге и NAS-сервере. По времени пока не скажу, т.к. сейчас хотим протестировать с Carbon billing. 

 

13 минут назад, Brainiac сказал:

Да работа не малая проведена наверно.

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

А смс доступно всегда, если только телефон не выключен, и абонент всегда получит смс.

А насчет экономии, так это оператор будет экономить на смс, он же рассылает их, а не клиент, а для клиента они вообще "бесплатно" включены в абонентку.

imho

>>> А смс доступно всегда, если только телефон не выключен, и абонент всегда получит смс.

-- Так рассылайте смс, кто не дает-то =) Рассылка через мессенджеры это просто одна из многих фич, можно ей не пользоваться.

>>> А насчет экономии, так это оператор будет экономить на смс, он же рассылает их, а не клиент, а для клиента они вообще "бесплатно" включены в абонентку.

-- для компании Карбон Софт клиент = оператор. Для оператора клиент = абонент. Наши клиенты = наши операторы. Экономим деньги для операторов, чтобы больше выгод было при использовании биллинга, чтобы биллинг больше покупали =) Чтобы старые клиенты не сомневались в выборе =)

[Saab95]

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

Реальные улучшения это разработка системы управления под windows, где бы можно было перетаскивать абонентов из группы в группу мышкой, а не тыкать по десятку ссылок в веб интерфейсе.

[No_name]

9 часов назад, product manager CB5 сказал:

А зачем? админка отлично защищена.

Серьезно? А в админку доступ только с локалхоста что ли 0_0?

[Kolunchik]

Админка действительно защищена, я не спорю. Просто не совсем стандартными средствами.

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

Да и браузеры, возможно вы слышали, уже не очень любят формы по http.

[Kolunchik]

1 час назад, Brainiac сказал:

Серьезно? А в админку доступ только с локалхоста что ли 0_0?

Там на входе ipset стоит на пропуск авторизованных адресов к приватным портам.

И это иногда создаёт неудобства - когда 2 менеджера зашли с одного адреса и разлогин одного приводит к прекращению доступа другого.

Изменено 23 ноября, 2017 пользователем Kolunchik

[kamlyn]

В 11/24/2017 в 00:00, Kolunchik сказал:

Там на входе ipset стоит на пропуск авторизованных адресов к приватным портам.

И это иногда создаёт неудобства - когда 2 менеджера зашли с одного адреса и разлогин одного приводит к прекращению доступа другого.

Для решения этой задачи существует возможность открыть всю подсеть менеджеров/админов.

Настройки платформы - Основные настройки base - IP АДРЕСА/СЕТИ АДМИНИСТРАТОРА/ОПЕРАТОРОВ:

http://docs.carbonsoft.ru/pages/viewpage.action?pageId=48693373

Изменено 28 ноября, 2017 пользователем kamlyn

[product manager CB5]

В 23.11.2017 в 19:25, Saab95 сказал:

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

Реальные улучшения это разработка системы управления под windows, где бы можно было перетаскивать абонентов из группы в группу мышкой, а не тыкать по десятку ссылок в веб интерфейсе.

про десяток ссылок Вы загнули конечно - раз так в 10 преувеличили. 1 ссылка.

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

 

В 23.11.2017 в 23:10, Kolunchik сказал:

Админка действительно защищена, я не спорю. Просто не совсем стандартными средствами.

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

Да и браузеры, возможно вы слышали, уже не очень любят формы по http.

Да, внесем в список пожеланий. 

[Saab95]

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

[apelsin.ns]

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

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

Отключить автоматическое обновление, что делается снятием одной галочке в настройках.

[den441]

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

[rdmitrich]

10 минут назад, den441 сказал:

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

Зачем вам управлять DHCP на микротике ??? IP  адреса абонентам выдает биллинг при авторизации к примеру по radius, далее адрес заносится в адресный лист к тому кому можно в инет или нельзя + создается по адрес шейпер в простой очереди

[Saab95]

Схема с радиусом работает тогда, когда микротик не один, а два и более, и все они раздают адреса. Если микротик один и установка дополнительных пока не планируется, никакой радиус не нужен - делаете статическую привязку адресов по вланам/PPPoE, а в биллинг просто их заносите в настройки абонентских учеток. В этом случае микротик может работать независимо от биллинга (его можно выключать, перезагружать и т.п.)

[rdmitrich]

В 08.03.2018 в 13:54, Saab95 сказал:

Схема с радиусом работает тогда, когда микротик не один, а два и более, и все они раздают адреса. Если микротик один и установка дополнительных пока не планируется, никакой радиус не нужен - делаете статическую привязку адресов по вланам/PPPoE, а в биллинг просто их заносите в настройки абонентских учеток. В этом случае микротик может работать независимо от биллинга (его можно выключать, перезагружать и т.п.)

ну не знаю.... у нас несколько лет схема с одним МТ работает, там и радиус и пппое. Реализовано на 5 БС и в принципе все неплохо

[Saab95]

17 часов назад, rdmitrich сказал:

ну не знаю.... у нас несколько лет схема с одним МТ работает, там и радиус и пппое. Реализовано на 5 БС и в принципе все неплохо

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

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

[777BLOODER777]

@Saab95 Я как то поднимал этот вопрос по авторизации без биллинга и хотел как раз услышать ваше решение по данному вопросу а именно вашу схему и поподробнее, если конечно не жалко. У меня получилось реализовать скриптом или через нетвач. Единственное "но" и оно самое неприятное, моя схема опирается на пинг к серверу биллинга, а хотелось бы чтоб отрабатывалось именно по логам и самим микротиком. Если есть ребята которые готовы помочь в данном вопросе на этом форуме готов проставится))) 

Изменено 20 марта, 2018 пользователем 777BLOODER777

[rdmitrich]

1 час назад, Saab95 сказал:

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

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

У нас выделенный сервер под биллинг на датацентре в Нидерландах, он постоянно включен, канал 100 мбпс с защитой от ддос. 

Да, хотели переехать на другой, вмешался Денис Кучаев и вроде пока все норм.

[Saab95]

Авторизация без биллинга это просто - если PPPoE, то все учетки заводятся на микротике (указывается IP адрес так же руками), далее в биллинге заводите абонентов с этими же данными. Биллинг отправляет команды только на блокировку этого IP и изменяет скорость. Можно сделать вариант что бы вообще на микротик не заходить, а что бы при создании абонента в биллинге, сам биллинг отправлял команды на создание абонента. И при удалении абонента так же удалял его. В этом случае биллинг только стоит рядом и считает статистику, да отправляет команды на блокировку/разблокировку и изменение скорости. Никаких проверок пингами ничего не надо.

 

Если схема влан на абонента - то так же руками адреса вешаете и заводите в биллинг.

 

У нас именно так реализовано, при чем в биллинге заведено все, что бы в любой момент включить Radius, если это потребуется. Хотя на деле установлено много серверов доступа и биллинг отправляет команды сразу на все, не зависимо где в данный момент авторизован абонент. Аналогично и с кабельными - на все шейпера отправляется одинаковая информация.

 

4 часа назад, rdmitrich сказал:

У нас выделенный сервер под биллинг на датацентре в Нидерландах, он постоянно включен, канал 100 мбпс с защитой от ддос. 

Да, хотели переехать на другой, вмешался Денис Кучаев и вроде пока все норм.

Сервер должен стоять рядом с серверами доступа, а не где-то в интернете.

[rdmitrich]

3 минуты назад, Saab95 сказал:

Авторизация без биллинга это просто - если PPPoE, то все учетки заводятся на микротике (указывается IP адрес так же руками), далее в биллинге заводите абонентов с этими же данными. Биллинг отправляет команды только на блокировку этого IP и изменяет скорость. Можно сделать вариант что бы вообще на микротик не заходить, а что бы при создании абонента в биллинге, сам биллинг отправлял команды на создание абонента. И при удалении абонента так же удалял его. В этом случае биллинг только стоит рядом и считает статистику, да отправляет команды на блокировку/разблокировку и изменение скорости. Никаких проверок пингами ничего не надо.

 

Если схема влан на абонента - то так же руками адреса вешаете и заводите в биллинг.

 

У нас именно так реализовано, при чем в биллинге заведено все, что бы в любой момент включить Radius, если это потребуется. Хотя на деле установлено много серверов доступа и биллинг отправляет команды сразу на все, не зависимо где в данный момент авторизован абонент. Аналогично и с кабельными - на все шейпера отправляется одинаковая информация.

 

Сервер должен стоять рядом с серверами доступа, а не где-то в интернете.

Это еще почему ?? Сервер размещен в датацентре, электропитание резервировано, администрируется, ежедневные бэкапы, широкий канал... и стоит копейки. 

[Saab95]

Ваше оборудование, которое абонентам доступ предоставляет, там же установлено? Или где-то в другом месте?

 

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

 

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

 

В малых масштабах это не заметно, но когда будет 2-5-10 тысяч абонентов и что-то где-то начнет сбоить, особенно в конце или начале месяца, где надо блокировать/разблокировать абонентов, тогда и появятся мысли про резервирование всего и вся.

[777BLOODER777]

@rdmitrich  копейки эт сколько ??? и какова конфигурация ???

 

 

 

 

[rdmitrich]

2 минуты назад, 777BLOODER777 сказал:

@rdmitrich  копейки эт сколько ??? и какова конфигурация ???

 

 

 

 

https://well-web.net/dedicated