Организовать разрыв соединения по условию
|
Откуда: Уфа
Сообщений: 5856
|
Re: Организовать разрыв соединения по условию
dimas, все верно, только в своем примере от асинхронности ты никуда не денешься. В обоих случаях, если БД "подвисла" на 10 минут, то челы могут залезть в этот кредит легко, и никто не порвет коннект.
Альтернативой может стать расчет времени по кредиту перед каждым вызовом и ограничение времени разговора этим лимитом еще до звонка. Как время кончится - хангап его, выйти за пределы лимита ну никак не получиться! По затратам прощессора - возможно даже меньше чем парсить/селектить каждую минуту.
Имхо чуваку нужно было что-то попроще...
|
|
Сообщений: 866
|
Re: Организовать разрыв соединения по условию
dimas, все верно, только в своем примере от асинхронности ты никуда не денешься. В обоих случаях, если БД "подвисла" на 10 минут, то челы могут залезть в этот кредит легко, и никто не порвет коннект.
это безусловно так. Но в конечном итоге в базе будут записи по всем разговорам включая те что были в момент "зависона". Так что кредит учтен будет - он улетит в минус но будет учтен. Кредиты ушедшие в минус это то с чем должны разбираться инженеры поддержки - почему так произошло, что было с базой и т.п. А в подходе с декрементом при зависании на 10 минут это время навсегда выпадает из поля зрения системы.
по поводу предварительного рассчета времени тут есть две сложноести:
1. кредит невозможно увеличить если разговор уже начался
2. более одного параллельного разговора.
Если в его ссистеме это проблемами не является (например одновременно с одного пина только один разговор и кредит не пополняется) - то да, так ему будет проще.
|
|
Сообщений: 80
|
Re: Организовать разрыв соединения по условию
switch: dimas, все верно, только в своем примере от асинхронности ты никуда не денешься. В обоих случаях, если БД "подвисла" на 10 минут, то челы могут залезть в этот кредит легко, и никто не порвет коннект.
Альтернативой может стать расчет времени по кредиту перед каждым вызовом и ограничение времени разговора этим лимитом еще до звонка. Как время кончится - хангап его, выйти за пределы лимита ну никак не получиться! По затратам прощессора - возможно даже меньше чем парсить/селектить каждую минуту.
Имхо чуваку нужно было что-то попроще...
Этот метод работает для конечного пользователя, а представь ты крупный провайдер предоставляешь платформу для более мелких провайдеров. У этих мелких провайдеров пользователи, делаюшие одновременные звонки. То есть всем дать максимальную длительность нельзя. Это не из области фантастики, у нас заказ был для биллинга на такую платформу.
Вообше хорошо бы изменить функцию Dial, добавивь туда доп параметры - функцию и таймер. Пользовательская функция пусть скажем запускается каждые n секунд и возврашает правда/ложь. Если правда - то звонок прерывается.
|
|
Откуда: Уфа
Сообщений: 5856
|
Re: Организовать разрыв соединения по условию
1) да, согласен. но вероятность одновременного наступления событий увеличения кредита и разговора стремиться к нулю и в любой системе/архитектуре она не может быть равна нулю. Можно лишь уменьшить до величины, достаточной для практического применения.
2) если более одного одновременного разговора то можно перед вызовом не только извлекать временной лимит, но и делать декремент в бд на это значение. Новые звонки в минус сделать ни как не получиться... хотя старые в минус залезут легко (а если 100 разговоров, то ощутимо будет ;) короче, метод несовершенен, можно использовать разве что дополнительного уровня защиты
3) не понял, как кредит будет учтен, если база висит? или табличку current_calls нужно на другой машине размещать?
|
|
Сообщений: 866
|
Re: Организовать разрыв соединения по условию
не понял, как кредит будет учтен, если база висит? или табличку current_calls нужно на другой машине размещать?
не, у меня там п.8 еще есть - какраз про это :=)
Смысл в том что в системе есть как бы два дополняющих друг друга биллинга - один по записям CDR которые Астериск сам генерит по окончанию разговора. Он может работать и без реалтайм билинга, просто кредит уменьшается только по окончании разговора с какой-то задержкой. Второй - реалтайм биллинг он обновляет кредит кажлую минуту/секунду. Они по сути независимы - каждый из них может работать один без второго и в случае если ничего не отваливается - производят одни и те же данные. Ну и чтобы не было двойного биллинга то при импорте CDR игнорируются те звонки которые уже были проведены реалтайм частью.
Это все выглядит очень волосато, но на практике это три таблички в базе и два-три экрана кода на всю систему - и с реалтайм частью и с CDR частью.
|
|
Сообщений: 27
|
Re: Организовать разрыв соединения по условию
Да, ребят... Вы настоящие монстры IP-телефонии. Не думал что так серьезно разрастется тема. Пока я делаю простой варант, (декремент), посмотрим как будет работать. Как закончу с ним - примусь пробовать реалищзовать идею Димаса. Спасибо всем за мысли, очень интересно.
|
|
Сообщений: 1573
|
Re: Организовать разрыв соединения по условию
Если в вашей системе нет необходимости/возможности делать более чем один одновременный вызов через один акк. (карточный счет и т.д.), то можно упростить решение вашей задачи ...
Команда Dial с опциями S или L ограничивает время вызова аргументом, заданным в сек.
А как получить для вызывающего эти данные (вычислить этот аргумент в зависимости от направления и т.д.) думаю понятно ...
P.S. Все это можно решить командами одного только диалплана ...
|
|
Откуда: Москва
Сообщений: 3421
|
Re: Организовать разрыв соединения по условию
Однозначно снимать деньги со счета надо в конце звонка при помощи опции S.
Анализировать переменные ANSWEREDTIME, DIALEDTIME, DIALSTATUS.
Другое дело, что если пложиться только на S, есть шансы улететь в минус.
Пример. У эккаунта одновременно разрашено 10 звонков. Все 10 стартуют одновременно. Первый выговаривает весь баланс, и принудительно завершается флагом S. А другие 10 продолжают выговаривать уже выговоренные баланс :-)
Чтобы этого не было, используют 2 пути:
1) При расчете максимального времени разговора учитывают софт лимит на разговор. Например, максимум можно говорить 1 час. Значит, для второго разговора, денег должно хватить на 1 час, и тд. Тогда для многих разговоров клиент должен постоянно иметь большой баланс. Но это не всегда реально.
2) Скидывать звонки при достижении out of money. Перед началом Dial помещается информация о звонке в таблицу active_calls. Раз в икс секунд делается выборка экаунтов с нулевым балансом. По найденным вызывается SoftHangup через CLI. (запись о звонке все равно отработает штатной процедурой!).
ИМХО самая простая конструкция.
|
|
Сообщений: 1573
|
Re: Организовать разрыв соединения по условию
litnimax: Пример. У эккаунта одновременно разрашено 10 звонков. Все 10 стартуют одновременно. Первый выговаривает весь баланс, и принудительно завершается флагом S. А другие 10 продолжают выговаривать уже выговоренные баланс :-)
Именно это я и подчеркнул ) :
cron333: Если в вашей системе нет необходимости/возможности делать более чем один одновременный вызов через один акк. (карточный счет и т.д.)
Если это условие не выдерживается, то реализовывать это нужно как говорилось выше - AGI или внешними приложениями ...
Вот если бы в команду Dial добавили возможность выполнения произвольных команд в процессе вызова (например как в той же опции L, есть же возможность проигрывать периодически анонсы) то тогда "биллинг" можно было бы строить на одном диалплане ... )
P.S. Просто довольно часто даже требуется, что бы через один акк./карт.счет мог проходить только один вызов. Так зачем в такой системе делать доп.нагрузку (AGI или внешние приложения) и усложнять ее, если все есть под руками ... ) |
|
