5 Sep
2008
5 Sep
'08
noon
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
5 Sep
5 Sep
12:05 p.m.
New subject: [Kamailio-Users] CDRTool and Prepaid
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(a)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
12:32 p.m.
New subject: [Kamailio-Users] CDRTool and Prepaid
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(a)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(a)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
12:40 p.m.
New subject: [Kamailio-Users] CDRTool and Prepaid
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))
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
3:41 p.m.
New subject: [Kamailio-Users] (no subject)
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
3:44 p.m.
New subject: [Kamailio-Users] (no subject)
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).
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
12:35 p.m.
New subject: [Kamailio-Users] CDRTool and Prepaid
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(a)evaristesys.com>wrote;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(a)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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
12:48 p.m.
New subject: [Kamailio-Users] CDRTool and Prepaid
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
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
3:57 p.m.
New subject: [Kamailio-Users] CDRTool and Prepaid
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
5926
days inactive
5926
days old
8 comments
7 participants
participants (7)
-
Adrian Georgescu -
Alex Balashov -
BERGANZ François -
DanB -
Iñaki Baz Castillo -
kokoska rokoska -
Raúl Alexis Betancor Santana