Реализация задачи неухода "в минус" в A2B
Навеяло сегодня... Разговаривал со многими людьми на тему ухода в минус и сложилось впечатление что ни один биллинг на сегодня не даёт абсолютной гарантии не ухода в минус. Что есть не очень хорошо. Оссобенно если по одному эккаунту ведется сразу несколько разговоров (в этом случае шанс ухода в минус возрастает, с количеством растет и сам минус, например если 100 звонков с одного эккаунта то минус может быть потенциально ОЧЕНЬ БОЛЬШИМ).
Вобщем идея такая (очень простая): проверять раз в минуту по таймеру все эккаунты которые в данный момент разговаривают на предмет (уже) нуля на балансе (или установленный минимум, скажем +0.01, можно опцию добавить в настройки) и если это так то принудительно дропаем все разговоры с этого аккаунта. В этом случае мы никогда не уйдем в минус (ну или он будет ничтожно мал, чем можно пренебречь). Обработчик-таймер можно сделать на чем угодно, хоть на том же php, хоть на перле. уверен - ресурсов это много не сьест. Если еще учесть что на одной машине обычно больше ~300 одновременных физически не получится всеравно то и нагрузки большой не будет чтобы проверить 300 эккаунтов (или меньше - если по одному эккаунту говорят несколько) за раз. (это я на всякий случай если ктото захочет возразить мол а что если тысячи звонков)
upd:
обсудил с nixon, вот что он предложил
| Цитата: |
| если сто одновременных разговор начнутся на 10 баксах, а как только закончится скажем 5-й и станет баланс 0 или меньше, то остальные принудительно позавершать |
тоесть проверяем всех, если гдето 0 - завершаем все разговоры этого эккаунта.
далее появилось развитие этой идеи: добавить реалтайм в сам билинг! звучит сложно но на самом деле все просто - нужно просто добавить проверку в сам билинг (можно и отдельным модулем) - пусть раз в минуту апдейтит баланс! тоесть смотрит активные разговоры и раз в минуту отнимает от остатка на балансе цену направления. все очень просто. тогда точно не пропустим момент нуля (или заранее выставленного значения, если надо), не важно сколько линий используется этим эккаунтом.
Может ктонить захочет взяться за реализацию?
для тех кто не "в теме": a2b обновляет баланс только уже после завершения звонка. отсюда и проблема с уходом в минус. если баланс обновлять "в реалтайм" то решится сразу несколько проблем разом.
ps: с реалтаймом можно будет не просто тупо дропать разговоры а перед отключением вежливо проигрывать сообщение в канал о наличае нуля на балансе. можно влезть в канал через spychan например (или новый API 1.8.), как вариант. можно пойти дальше и добавив одну-две строчки кода, делать проверку если на балансе остается всего на минуту-две разговора то проигрываем сообщение об этом, напоминаю - это будет делать в реалтайм уже а не как счас в a2b сделано - по предварительно расчитанному времени, которое может меняться если одним эккаунтом пользуются несколько человек.
Тогда периодическая ф-ция должна в момент проверки определить сколько уже наговорено по всем разговорам вычесть из баланса по стоимости и определить вычерпано время или нет. Но...
1. Если не уменьшить баланс на уже выговоренную сумму - то инициация следующего разговора всеравно произойдет из расчета остатка, или надо в инициации прикрутить вычет уже наговоренного-незавершенного.
2. Если в момент проверки вычесть баланс - то в момент завершения надо знать сколько уже по этому разговору было наговорено чтобы повторно не вычесть.
3. по мере добавления количества звонков общая стоимость секунды возрастает, что повышает вероятность ухода в минус даже если периодически проверять остаток.
Очень мутная схема и пахнет огромной тучей багов в реальной эксплуатации.
Есть идея в момент инициации каждого следующего вызова пересчитывать таймауты уже запущенных вызовов, но тогда и в момент завершения вызова тоже надо пересчитывать таймауты всех оставшихся.
Здесь тоже есть камень - не известно как подменить таймаут команде Dial которая уже выполняется. Надо API астериска раскапывать и на ANSI C писать наверное.
_________________
.
..:
В крон каждую минуту скрипт, который проверяет текущие звонки, считает их стоимость исходя из направления и длительности. Суммирует их все и сверяет с балансом, если перерасход - завершаем их все.
Похожий скрипт можно добавить куском в AGI обработчик биллинга. Т.е. при запуске нового звонка идет подсчет стоимости текущих звонков и вычет их из баланса. Если перерасход - запрет текущего и завершение остальных, если нет, то в "уме" уменьшаем баланс на сумму текущих звонков и исходя из этого задаем максимальную длительность звонков.
Из преимущества - никакого мухлежа со счетом пользователя, его уменьшение по прежнему возложено на биллинг, скрипты лишь проверяют текущие звонки и завершают их в случае перерасхода.
Теоретически работать должно быстро и безглючно.
_________________
Gentoo Linux || Asterisk 13.1-cert2
Решения телефонии на базе Asterisk || http://it-need.ru
_________________
.
..:
_________________
Gentoo Linux || Asterisk 13.1-cert2
Решения телефонии на базе Asterisk || http://it-need.ru
В сеть инмарсат или иридиум там и поболее можно влететь.
Да и если демона писать, то можно уже и астериску костыль приделать с изменением таймаутов для выполняющихся команд Dial ))) IMHO дело вкуса.
_________________
.
..:
ps: ктоб еще это сделал теперь?
pps: если задача трудоемкая то можно оценить обьем работы и назначить цену. я лично бы не пожалел бы на такое дело.
другой вариант - сделать патч коммерческим и продавать по адекватной цене, скажем $100, те кто делает на a2b деньги - купят по любому. 10 человек купят - считай разработка окупилась.
_________________
Gentoo Linux || Asterisk 13.1-cert2
Решения телефонии на базе Asterisk || http://it-need.ru
_________________
.
..:
Возможно, скоро появится аналог а2биллинга для FreeSWITCH: http://forum.asterisk2billing.org/viewto ... amp;t=8865
| anest писал(а): |
| сделать патч коммерческим и продавать по адекватной цене, скажем $100, те кто делает на a2b деньги - купят по любому. 10 человек купят - считай разработка окупилась. |
А некоторые покупают другие биллинги, в которых уход в минус запрещён изначально..
_________________
Продам виртуальную АТС. Желающим 5% скидка...
_________________
«Choose a job you love, and you will never have to work a day in your life» — Confucius
_________________
Продам виртуальную АТС. Желающим 5% скидка...
В противном случае это попахивает рекламой кота в мешке, притом кота "непричесанного".
_________________
.
..:
Там свой модуль к астериску который и владеет всей информацией по текущим звонкам, соответсвенно может отключать в секунду окончания денег на балансе.
_________________
Gentoo Linux || Asterisk 13.1-cert2
Решения телефонии на базе Asterisk || http://it-need.ru
_________________
.
..:
Мне кажется это не исключает уход в минус. Минимизирует, но не исключает.
_________________
.
..:
Интернет провайдеры трафик тоже считают не до байтика.
Все что я видел на несколько рублей в минус уходят, но многие этого не показывают, пишут 0.
_________________
Gentoo Linux || Asterisk 13.1-cert2
Решения телефонии на базе Asterisk || http://it-need.ru
Господин bdmalex говорил о невозможности уйти в минус. Потому и придираюсь.
_________________
.
..:
_________________
Gentoo Linux || Asterisk 13.1-cert2
Решения телефонии на базе Asterisk || http://it-need.ru
_________________
.
..:
То Gear: "Недорогие", это сколько?
2.Гораздо проще будет в астере завести динамически меняемое аппроксимированное время до конца соединения звонков в общей группе. Чем переписывать а2б.
Я так понимаю Gear, делает первый взнос программисту
_________________
https://github.com/nixonch/a2billing
1. При инициации каждого следующего звонка можно считать сколько уже есть звонков и высчитывать таймаут соответсвенно. По окончанию разговора по таймауту завершать остальные звонки (как предложили до меня). Это снизит риск ухода в минус, но не исключит.
Неудобно то что если завершится не по таймауту последний (самый короткий по логике) звонок, то предыдущие даже не узнают о том что деньги уменьшились на балансе.
Писать такое вроде не долго, по крайней мере обозримо по объему.
2. есть функция TIMEOUT, если умудриться ее выполнять в контексте не текущего канала, то можно переопределять на старте и завершении звонков все остальные по одному клиенту. Это совсем снизит (почти к нулю) вероятность отрицательного остатка на счету.
Но пока не знаю как выполнить это дело в контексте другого звонка, что делает этот вариант пока не рабочим.
Писать такое тоже обозримое количество ночей )))
_________________
.
..:
Хотел бы поинтересоваться, сделал ли кто-то первые шаги в написании кода в этом направлении?
Мне так думается, чтобы нормально просчитывался баланс абонента (без ухода в минус), то нужно чтобы звонком управлял уже AGI скрипт. При этом AGI можно будет прикрутить к любой системе биллинга. AGI будет не завесим от используемого биллинга. Не завесим в том смысле, что в настройках указать подключение к базе и поля, которые нужно считывать и обновлять.
То есть я вижу такую логику:
Звонок пришел в контекст, далее отправился на AGI, далее скрипт проверил текущий баланс, если он положительный, то отправляем звонок в транк через себя, при этом, если с другой стороны ответили, то скрипт каждую секунду обновляет баланс в базе с учетом стоимости направления, потом считывает новые значение баланса и проверяет, если на балансе больше 0, то продолжать выполнять звонок/обновление баланса. При этом второй звонок с этого же аккаунта получит уже актуальный баланс и отсчет получится быстрее. При достижении 0 на балансе, скрипт, который получил 0 при проверке, автоматически останавливает все остальные подсчеты и разрывает все активные соединения аккаунта. При этом последующие звонки будут уже заблокированы, так как на балансе 0 (даже если за 1 сек. будет два вызова одновременно, в одну и ту же секунду, что практически невозможно)
Я в AGI не силен, поэтому не могу пока написать такой скрипт.