Реализация задачи неухода "в минус" в A2B

Сообщение **anest** » 24 июн 2011, 23:16

Привет всем.
Навеяло сегодня... Разговаривал со многими людьми на тему ухода в минус и сложилось впечатление что ни один биллинг на сегодня не даёт абсолютной гарантии не ухода в минус. Что есть не очень хорошо. Оссобенно если по одному эккаунту ведется сразу несколько разговоров (в этом случае шанс ухода в минус возрастает, с количеством растет и сам минус, например если 100 звонков с одного эккаунта то минус может быть потенциально ОЧЕНЬ БОЛЬШИМ).
Вобщем идея такая (очень простая): проверять раз в минуту по таймеру все эккаунты которые в данный момент разговаривают на предмет (уже) нуля на балансе (или установленный минимум, скажем +0.01, можно опцию добавить в настройки) и если это так то принудительно дропаем все разговоры с этого аккаунта. В этом случае мы никогда не уйдем в минус (ну или он будет ничтожно мал, чем можно пренебречь). Обработчик-таймер можно сделать на чем угодно, хоть на том же php, хоть на перле. уверен - ресурсов это много не сьест. Если еще учесть что на одной машине обычно больше ~300 одновременных физически не получится всеравно то и нагрузки большой не будет чтобы проверить 300 эккаунтов (или меньше - если по одному эккаунту говорят несколько) за раз. (это я на всякий случай если ктото захочет возразить мол а что если тысячи звонков)

upd:
обсудил с nixon, вот что он предложил

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

тоесть проверяем всех, если гдето 0 - завершаем все разговоры этого эккаунта.

далее появилось развитие этой идеи: добавить реалтайм в сам билинг! звучит сложно но на самом деле все просто - нужно просто добавить проверку в сам билинг (можно и отдельным модулем) - пусть раз в минуту апдейтит баланс! тоесть смотрит активные разговоры и раз в минуту отнимает от остатка на балансе цену направления. все очень просто. тогда точно не пропустим момент нуля (или заранее выставленного значения, если надо), не важно сколько линий используется этим эккаунтом.

Может ктонить захочет взяться за реализацию?

для тех кто не "в теме": a2b обновляет баланс только уже после завершения звонка. отсюда и проблема с уходом в минус. если баланс обновлять "в реалтайм" то решится сразу несколько проблем разом.

ps: с реалтаймом можно будет не просто тупо дропать разговоры а перед отключением вежливо проигрывать сообщение в канал о наличае нуля на балансе. можно влезть в канал через spychan например (или новый API 1.8.), как вариант. можно пойти дальше и добавив одну-две строчки кода, делать проверку если на балансе остается всего на минуту-две разговора то проигрываем сообщение об этом, напоминаю - это будет делать в реалтайм уже а не как счас в a2b сделано - по предварительно расчитанному времени, которое может меняться если одним эккаунтом пользуются несколько человек.

Сообщение **anest** » 26 июн 2011, 12:24

Не поверю что ни у кого нет мыслей по этому поводу и совершенно нечего сказать...

busc · Сообщение **busc** » 26 июн 2011, 18:16

Предположим 100 звонков параллельно запущено.
Тогда периодическая ф-ция должна в момент проверки определить сколько уже наговорено по всем разговорам вычесть из баланса по стоимости и определить вычерпано время или нет. Но...
1. Если не уменьшить баланс на уже выговоренную сумму - то инициация следующего разговора всеравно произойдет из расчета остатка, или надо в инициации прикрутить вычет уже наговоренного-незавершенного.
2. Если в момент проверки вычесть баланс - то в момент завершения надо знать сколько уже по этому разговору было наговорено чтобы повторно не вычесть.
3. по мере добавления количества звонков общая стоимость секунды возрастает, что повышает вероятность ухода в минус даже если периодически проверять остаток.

Очень мутная схема и пахнет огромной тучей багов в реальной эксплуатации.
Есть идея в момент инициации каждого следующего вызова пересчитывать таймауты уже запущенных вызовов, но тогда и в момент завершения вызова тоже надо пересчитывать таймауты всех оставшихся.
Здесь тоже есть камень - не известно как подменить таймаут команде Dial которая уже выполняется. Надо API астериска раскапывать и на ANSI C писать наверное.

aven · Сообщение **aven** » 26 июн 2011, 18:47

У меня идея проще.

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

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

busc · Сообщение **busc** » 27 июн 2011, 16:57

Запуск проверок в кроне не исключает ухода в минус, уменьшает вероятность - да, но не исключает.

aven · Сообщение **aven** » 27 июн 2011, 18:41

ну можно демона написать и запускать каждые 5 секунд, будет практически сразу отрубать при достижении нуля.

busc · Сообщение **busc** » 28 июн 2011, 21:50

Можно, но тоже костыль, хоть и привлекательный. Однако в минус не запретит уйти. Одновременно инициировать 3 звонка со стоимостью 1 цент секунда, и на 15 центов можно попасть. На 100 звонках в 5 долл.
В сеть инмарсат или иридиум там и поболее можно влететь.
Да и если демона писать, то можно уже и астериску костыль приделать с изменением таймаутов для выполняющихся команд Dial ))) IMHO дело вкуса.

Сообщение **anest** » 29 июн 2011, 01:56

каждые 5 сек я думаю это излишне уже, но вот раз в минуту - самое то будет. imho.
ps: ктоб еще это сделал теперь?

pps: если задача трудоемкая то можно оценить обьем работы и назначить цену. я лично бы не пожалел бы на такое дело.
другой вариант - сделать патч коммерческим и продавать по адекватной цене, скажем $100, те кто делает на a2b деньги - купят по любому. 10 человек купят - считай разработка окупилась.

aven · Сообщение **aven** » 29 июн 2011, 05:21

Думаю можно и написать, надо только a2b поставить

busc · Сообщение **busc** » 29 июн 2011, 07:43

Для раза в минуту пойдет обычный cronjob.

deviator · Сообщение **deviator** » 26 июл 2011, 12:44

Сделано уже всё давно, работает совместно с ланбиллингом.

latv · Сообщение **latv** » 27 июл 2011, 09:35

Не помешает глянуть в параллельный проект за идеями: http://wiki.freeswitch.org/wiki/Mod_nibblebill
Возможно, скоро появится аналог а2биллинга для FreeSWITCH: http://forum.asterisk2billing.org/viewt ... =18&t=8865

bdmalex · Сообщение **bdmalex** » 27 июл 2011, 13:47

anest писал(а):сделать патч коммерческим и продавать по адекватной цене, скажем $100, те кто делает на a2b деньги - купят по любому. 10 человек купят - считай разработка окупилась.

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

Сообщение **anest** » 28 июл 2011, 11:51

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

bdmalex · Сообщение **bdmalex** » 28 июл 2011, 16:57

В комерческом биллинге, которым я торгую такой проблемы нет, я к сожалению все технические тонкости не смогу вам объяснить..но по заверениям разработчиков "в минус уйти нельзя.."

Сообщение **anest** » 29 июл 2011, 11:28

тоесть фактически вы влезли в этот топик с одной лишь целью - прорекламироваться.

busc · Сообщение **busc** » 29 июл 2011, 13:11

может быть, чтобы поправить ситуацию, Вы узнаете у разработчиков рецепт безупречного препейда?
В противном случае это попахивает рекламой кота в мешке, притом кота "непричесанного".

aven · Сообщение **aven** » 29 июл 2011, 13:34

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

busc · Сообщение **busc** » 29 июл 2011, 14:17

интересно как? если 100 звонков параллельно он считает сколько там денег

latv · Сообщение **latv** » 01 авг 2011, 09:02

nibble_bill для фрисвича на который я ссылался, на каждом канале каждый хартбит вычитает с баланса ненежку, и при достижении нуля обрывает канал.

busc · Сообщение **busc** » 01 авг 2011, 10:13

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

aven · Сообщение **aven** » 01 авг 2011, 10:53

а что большой минус за 1 секунду будет?

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

busc · Сообщение **busc** » 01 авг 2011, 13:53

ну если 100 звонков, да по 15 долл. минута, то... хотя для кого что означает много.
Господин bdmalex говорил о невозможности уйти в минус. Потому и придираюсь.

Gear · Сообщение **Gear** » 01 авг 2011, 17:53

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

aven · Сообщение **aven** » 01 авг 2011, 19:01

Из коробки проблема решается только при 1 одновременном звонке.