The problem with concurrent prepaid calls and single balance is that you have to correlate between the call control and rating angine somehow so that all calls terminate when balnce becomes zero. The problem is a bit complex:
Example:
Balance = 10. A call starts to destination XXX, for the sake of example max session time = 2 minutes After one minute, you start second call to destination YYY which has a different price and your balance is not anymore 10 but depends on the duration of the first call which is in progress.
What is the maximum session time for it given that the first call is already in progress? What should happen with the first call?
I am looking for suggestions on implementing a proper algorithm to deal with this situation in the rating engine. If you have any I would be glad to hear it.
Adrian
In my experience dealing with it, it is precisely at the point where multiple calls are involved that using a proxy for rating and mediation purely becomes an impossible headache.
The conclusion I always came to in my implementations, which too always started out with the noble goal of dealing with it all in proxy, is that to properly handle this, I would need to extend the functionality to include a B2BUA through which the calls are run that can sit there and monitor them at a relatively low interval and record updates to their duration into the database.
The B2BUA would need some sort of call control API, like Asterisk's Manager API, or whatever Yate has, so that an outside process can sit there and do statekeeping on the calls. You could do this without handling media by using the B2BUA in a purely signaling capacity, which I think is how Yate functions by default, and how Asterisk can function with the "directrtpsetup" option in sip.conf.
It is then possible to know in reasonably real time the call duration without waiting for an accounting stop event and thus make the determination of whether another call should be allowed given the balance depletion.
-- Alex
Adrian Georgescu wrote:
The problem with concurrent prepaid calls and single balance is that you have to correlate between the call control and rating angine somehow so that all calls terminate when balnce becomes zero. The problem is a bit complex:
Example:
Balance = 10. A call starts to destination XXX, for the sake of example max session time = 2 minutes After one minute, you start second call to destination YYY which has a different price and your balance is not anymore 10 but depends on the duration of the first call which is in progress.
What is the maximum session time for it given that the first call is already in progress? What should happen with the first call?
I am looking for suggestions on implementing a proper algorithm to deal with this situation in the rating engine. If you have any I would be glad to hear it.
Adrian
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
It does not require a b2bua. It can be done in the proxy call control module that send out the BYEs and the rating engine. Just the algorithm need to be defined.
-- Adrian
On Sep 5, 2008, at 11:05, Alex Balashov abalashov@evaristesys.com wrote:
In my experience dealing with it, it is precisely at the point where multiple calls are involved that using a proxy for rating and mediation purely becomes an impossible headache.
The conclusion I always came to in my implementations, which too always started out with the noble goal of dealing with it all in proxy, is that to properly handle this, I would need to extend the functionality to include a B2BUA through which the calls are run that can sit there and monitor them at a relatively low interval and record updates to their duration into the database.
The B2BUA would need some sort of call control API, like Asterisk's Manager API, or whatever Yate has, so that an outside process can sit there and do statekeeping on the calls. You could do this without handling media by using the B2BUA in a purely signaling capacity, which I think is how Yate functions by default, and how Asterisk can function with the "directrtpsetup" option in sip.conf.
It is then possible to know in reasonably real time the call duration without waiting for an accounting stop event and thus make the determination of whether another call should be allowed given the balance depletion.
-- Alex
Adrian Georgescu wrote:
The problem with concurrent prepaid calls and single balance is that you have to correlate between the call control and rating angine somehow so that all calls terminate when balnce becomes zero. The problem is a bit complex: Example: Balance = 10. A call starts to destination XXX, for the sake of example max session time = 2 minutes After one minute, you start second call to destination YYY which has a different price and your balance is not anymore 10 but depends on the duration of the first call which is in progress. What is the maximum session time for it given that the first call is already in progress? What should happen with the first call? I am looking for suggestions on implementing a proper algorithm to deal with this situation in the rating engine. If you have any I would be glad to hear it. Adrian _______________________________________________ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
Adrian Georgescu wrote:
It does not require a b2bua. It can be done in the proxy call control module that send out the BYEs and the rating engine. Just the algorithm need to be defined.
I profess ignorance as to how the rating engine works, but I presume that it involves an outside process that updates the call duration frequently?
If so, I would say that the algorithm should check if there is enough credit available for at least a minute of call time at the new rate based on the last known temporal position of all existing calls. This threshold should, perhaps, be a configurable parameter.
It won't get it right every time; that depends on where the polling / update interval for call duration falls. If the update interval is known, perhaps the wisest thing to do is to build padding into the threshold that rounds up the time consumed by the existing tracked calls to what it would be when the next duration tracking interval comes, as a fraction of the per-minute rate.
For instance, if there are 3 existing calls open at 2.9c/min and the polling interval is 10 seconds, and the new call is 5c/min, then the available credit threshold required to complete the new call should be:
0.05 + (3 * (0.029 / 6))
Hello,
I have some problem with, openser & centile!
When do a call from centile to openser, the call don't do "ringing", just "trying" and after, centile say "BYE" Have you an idea?
Thank you
El Friday 05 September 2008 14:41:22 BERGANZ François escribió:
Hello,
I have some problem with, openser & centile!
When do a call from centile to openser, the call don't do "ringing", just "trying" and after, centile say "BYE" Have you an idea?
Please, don't break mail threads. Generate a *new* mail instead of replying to any other (it's not enough with replacing subject and body).
Adrian,
here is what came into my mind at a glance.
There should be a billing daemon monitoring the calls. Not sure how it should be done with the help of dialog of openser (hope that nobody here get's offended but maybe could use some ideas to implement the same mechanism in *SER dialog module). The module should be responsible of each single call passing through B2BUA. The max-duration should be shared between the calls belonging to the same account. There should be two different actions done: 1. On disconnect of each call, update the rating engine with the disconnect info, plus recalculate the maximum duration permitted on the account. 2. At regular intervals, update the max-duration of the calls belonging to the same account based on balance left. When balance 0, disconnect all the calls belonging to the same account.
Now, the entire scenario would be easier with the help of rating-engine.
Billing example:
1. Call starts: in auth phase rating_engine is queried. If balance is not 0, the call will be authorized. No need anymore of maximum duration or account locking, just balance left. 2. Billing Daemon of B2BUA will regularly update rating engine with the information about active calls, therefore rating-engine will need to recalculate the balance left and return it. 3. As soon as the rating engine will return balance 0, all the calls will be disconnected.
The whole scenario involves a minimum risk of negative balance but it will all depend on how often billing daemon updates call states into rating engine.
Cheers, DanB
On Fri, Sep 5, 2008 at 11:05 AM, Alex Balashov abalashov@evaristesys.comwrote:
In my experience dealing with it, it is precisely at the point where multiple calls are involved that using a proxy for rating and mediation purely becomes an impossible headache.
The conclusion I always came to in my implementations, which too always started out with the noble goal of dealing with it all in proxy, is that to properly handle this, I would need to extend the functionality to include a B2BUA through which the calls are run that can sit there and monitor them at a relatively low interval and record updates to their duration into the database.
The B2BUA would need some sort of call control API, like Asterisk's Manager API, or whatever Yate has, so that an outside process can sit there and do statekeeping on the calls. You could do this without handling media by using the B2BUA in a purely signaling capacity, which I think is how Yate functions by default, and how Asterisk can function with the "directrtpsetup" option in sip.conf.
It is then possible to know in reasonably real time the call duration without waiting for an accounting stop event and thus make the determination of whether another call should be allowed given the balance depletion.
-- Alex
Adrian Georgescu wrote:
The problem with concurrent prepaid calls and single balance is that you have to correlate between the call control and rating angine somehow so that all calls terminate when balnce becomes zero. The problem is a bit complex:
Example:
Balance = 10. A call starts to destination XXX, for the sake of example max session time = 2 minutes After one minute, you start second call to destination YYY which has a different price and your balance is not anymore 10 but depends on the duration of the first call which is in progress.
What is the maximum session time for it given that the first call is already in progress? What should happen with the first call?
I am looking for suggestions on implementing a proper algorithm to deal with this situation in the rating engine. If you have any I would be glad to hear it.
Adrian
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
El Friday 05 September 2008 10:00:04 Adrian Georgescu escribió:
The problem with concurrent prepaid calls and single balance is that you have to correlate between the call control and rating angine somehow so that all calls terminate when balnce becomes zero. The problem is a bit complex:
Example:
Balance = 10. A call starts to destination XXX, for the sake of example max session time = 2 minutes After one minute, you start second call to destination YYY which has a different price and your balance is not anymore 10 but depends on the duration of the first call which is in progress.
What is the maximum session time for it given that the first call is already in progress? What should happen with the first call?
I am looking for suggestions on implementing a proper algorithm to deal with this situation in the rating engine. If you have any I would be glad to hear it.
Adrian
Hi Adrian, A simple approach could be:
- New Call1 to Dest XXX - Get cost per sec to dest XXX - Get connection cost to dest XXX (if any) - Set customer.balance =- thisCallConnectionCost - Set global var customer.costPerSec to customercostPerSec =+ thisCallCostPerSec - Notify externalWatcher new customer.costPerSec
- BYE Call1 to Dest XXX - Get disconnection cost to dest XXX (if any) - Set customer.balance =- thisCallDisconnectionCost - Set global var customer.costPerSec to customercostPerSec =- thisCallCostPerSec - Notify externalWatchr new customer.costPerSec
Then on a separate thread or proc or "something" ... - Every timeslice - while activeCustomers.next() - activeCustomer.balance =- activeCustomer.costPerSec - If (activeCustomer.balance <= activeCustomer.lowBalanceAlarm) and !activeCustomer.allreadyNotified - Send lowBalance Notify to customer - If (activeCustomer.balance <= activeCustomer.minAllowedBalance) - while activeCustomer.activeCall.next() - activeCustomer.activeCall.finish() - activeCustomer.lockNewCalls()
I think it's a good approach
Adrian Georgescu napsal(a):
The problem with concurrent prepaid calls and single balance is that you have to correlate between the call control and rating angine somehow so that all calls terminate when balnce becomes zero. The problem is a bit complex:
Example:
Balance = 10. A call starts to destination XXX, for the sake of example max session time = 2 minutes After one minute, you start second call to destination YYY which has a different price and your balance is not anymore 10 but depends on the duration of the first call which is in progress.
What is the maximum session time for it given that the first call is already in progress? What should happen with the first call?
I am looking for suggestions on implementing a proper algorithm to deal with this situation in the rating engine. If you have any I would be glad to hear it.
I'm not sure if I can help, because I know nearly nothing about CDRTool, but I had to solve problem with multiply calls on prepaid accounts in the past. So let me describe it :-)
Requierements: 1. Prepaid accounts 2. Unlimited number of concurrent calls per user 3. OpenSER (without dialog module, becasuse it didn't exist yet)
Implementation: 1. We insert every call to the DB (MySQL, memory table) through the OpenSER script when call starts and remove it when finished 2. We wrote daemon which reads all tariff plans and find smallest tariffication time - 1 second in our case 3. This daemon every 1 second (see above) recount current price of all active calls based on user tariff scheme (it is a little bit complex task :-) 4. Than compare it with actual user acount balance 5. If balance <= current total, daemon kill all user calls (throught OpenSER fifo send BYEs to both "phones")
Works fine :-)
Hope this helps.
Best regards,
kokoska.rokoska
-
Adrian Georgescu -
Alex Balashov -
BERGANZ François -
DanB -
Iñaki Baz Castillo -
kokoska rokoska -
Raúl Alexis Betancor Santana