Thank you for the feedback Adrian, I will certainly look into doing it that way instead.
Best Regards, Magnus 2010/6/21 Adrian Georgescu <[email protected]> > > On Jun 21, 2010, at 2:32 AM, Magnus Burman wrote: > > Hi Adrian, > > I struggle to figure out how the MaxSessionTime for new calls are > calculated. As a simple example, have a first session ask for 3600s. Then a > second session does the same directly thereafter, with the same rate (for > simplicity), but credit is low and only 2000s is allowed. How does call > control figure out that both calls should end after 2800 seconds? > > > This is done by recalculating based on the remaining balance a new max > session time for each individual session. The remaining balance is > redistributed in such way that all calls end up at the same time when the > balance reaches zero. So the Rating engine does not only return to the call > control the max session time for the current call but also for previous > calls if any are ongoing. > > Check Prepaid documentation from CDRTool where this is explained in detail. > > > Even more importantly to me is what happens when a third call is entered > into the mix. The credit is now at 0, is this call established? > > What I'm trying to achieve right here is handling multiple sessions without > blocking the credit. By having call control re-ask for MaxSessionTime after > a shorter time-period (60s), blocking will not occur to such a large degree. > > > Again you are trying to solve a problem that does not exist. > > > Is this a bad way of doing it? I'm actually trying to integrate this with a > 3rd party rating engine that supports this schema as I believe it's a good > way of handling multiple sessions. > > > Read the documentation, it contains pseudo code for how to do it in other > rating engine app. > > > Cheers, > Magnus > > 2010/6/18 Adrian Georgescu <[email protected]> > >> The call control engine + rating engine already supports multiple parallel >> prepaid sessions per user, all calls stop when the balance reaches zero. >> >> What do you try to achieve? >> >> Adrian >> >> >> On Jun 18, 2010, at 4:56 PM, Magnus Burman wrote: >> >> Hi guys, >> >> To get a more flexible credit control when running several concurrent >> calls on the same user I'm trying to add some functionality to the call >> control module. >> >> Basically what I'm trying to do is set a low time limit, such as 60 >> seconds, and when the timer runs out send a new getCallLimit, until the call >> ends either by a return of 0 or by hangup. >> >> I've been trying to do this by adding a new getCallLimit in the >> Call.__expire method in sip.py. >> >> def __expire(self): >> rating = RatingEngineConnections.getConnection(self) >> >> >> rating.getCallLimit(self).addCallbacks(callback=self._reinit_simple_calllimit, >> errback=self._start_error) >> """ >> self.expired = True >> self.application.clean_call(self.callid) >> self.end(reason='call control', sendbye=True) >> """ >> >> In _reinit_sample_calllimit I mimic _start_finish_calllimit in a lot of >> ways, trying different timer combinations. I've tried with cancel followed >> by a new setup, I've tried delay, I've tried reset, I've tried manually >> doing a new ReactorTimer and all of the above! >> >> I get the MaxSessionTime call to work, but I fail with the timer somehow. >> __expire is never called again after the first time, and the call is never >> interrupted. >> >> Anyone with tips? At this point I'm about to dive into the twisted >> framework and reactors, but any hints are much appreciated! >> >> Cheers, >> Magnus >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
