<div dir="ltr">Adrian,<br><br>here is what came into my mind at a glance.<br><br>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).<br>
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.<br>There should be two different actions done:<br>1. On disconnect of each call, update the rating engine with the disconnect info, plus recalculate the maximum duration permitted on the account.<br>
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.<br><br>Now, the entire scenario would be easier with the help of rating-engine.<br>
<br>Billing example:<br><br>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.<br>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.<br>
3. As soon as the rating engine will return balance 0, all the calls will be disconnected.<br><br>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.<br>
<br>Cheers,<br>DanB<br><br><br><br><br><div class="gmail_quote">On Fri, Sep 5, 2008 at 11:05 AM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">In my experience dealing with it, it is precisely at the point where<br>
multiple calls are involved that using a proxy for rating and mediation<br>
purely becomes an impossible headache.<br>
<br>
The conclusion I always came to in my implementations, which too always<br>
started out with the noble goal of dealing with it all in proxy, is that<br>
to properly handle this, I would need to extend the functionality to<br>
include a B2BUA through which the calls are run that can sit there and<br>
monitor them at a relatively low interval and record updates to their<br>
duration into the database.<br>
<br>
The B2BUA would need some sort of call control API, like Asterisk's<br>
Manager API, or whatever Yate has, so that an outside process can sit<br>
there and do statekeeping on the calls. You could do this without<br>
handling media by using the B2BUA in a purely signaling capacity, which<br>
I think is how Yate functions by default, and how Asterisk can function<br>
with the "directrtpsetup" option in sip.conf.<br>
<br>
It is then possible to know in reasonably real time the call duration<br>
without waiting for an accounting stop event and thus make the<br>
determination of whether another call should be allowed given the<br>
balance depletion.<br>
<br>
-- Alex<br>
<div><div></div><div class="Wj3C7c"><br>
Adrian Georgescu wrote:<br>
<br>
> The problem with concurrent prepaid calls and single balance is that<br>
> you have to correlate between the call control and rating angine<br>
> somehow so that all calls terminate when balnce becomes zero. The<br>
> problem is a bit complex:<br>
><br>
> Example:<br>
><br>
> Balance = 10.<br>
> A call starts to destination XXX, for the sake of example max session<br>
> time = 2 minutes<br>
> After one minute, you start second call to destination YYY which has a<br>
> different price and your balance is not anymore 10 but depends on the<br>
> duration of the first call which is in progress.<br>
><br>
> What is the maximum session time for it given that the first call is<br>
> already in progress?<br>
> What should happen with the first call?<br>
><br>
> I am looking for suggestions on implementing a proper algorithm to<br>
> deal with this situation in the rating engine. If you have any I would<br>
> be glad to hear it.<br>
><br>
> Adrian<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.kamailio.org">Users@lists.kamailio.org</a><br>
> <a href="http://lists.kamailio.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.kamailio.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
<br>
</div></div><font color="#888888">--<br>
Alex Balashov<br>
Evariste Systems<br>
Web : <a href="http://www.evaristesys.com/" target="_blank">http://www.evaristesys.com/</a><br>
Tel : (+1) (678) 954-0670<br>
Direct : (+1) (678) 954-0671<br>
Mobile : (+1) (706) 338-8599<br>
</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.kamailio.org">Users@lists.kamailio.org</a><br>
<a href="http://lists.kamailio.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.kamailio.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div>