I am reading this document to implement Quota http://cdrtool.ag-projects.com/projects/cdrtool/repository/entry/doc/QuotaSystem.txt
In number 3. Configure OpenSIPS to deny sessions initiated by subscribers belonging to the quota group. what that means? How do i configure opensips to deny session, is it part of callcontrol config? also it is saying belongs to the quota group, what is quota group? this is what i have in my subscriber table. Even after quota exceed it is not blocking call. +-----+----------+-------------------+----------+-----------------------+----------------------------------+----------------------------------+------+-------+ | id | username | domain | password | email_address | ha1 | ha1b | rpid | quota | +-----+----------+-------------------+----------+-----------------------+----------------------------------+----------------------------------+------+-------+ | 1 | 3003 | sip.example.com | 3003 | | 6fc4d74adfdedf25c72134154d3a9e1a | 3251dd8a5ef5a35d79a358bccb2c8179 | NULL | 1 | On Sun, Oct 12, 2014 at 7:30 PM, Adrian Georgescu <[email protected]> wrote: > Quota works very simple. It is a mere cronjob that compares the total > amount of costs made in the current calendar month with the maximum > allowed. If the costs are higher than the quota, then the SIP account is > blocked. This will not cut the calls in progress but it works well > statistically speaking for postpaid customers. The documentation explains > the modus operandi in more detail. > > Adrian > > On 12 Oct 2014, at 11:14, Satish Patel <[email protected]> wrote: > > Thanks!! I think you got my point, we have very high density call ratio > that is why prepaid not going to be a solution, I think postpaid or quota > would be right one. > > I have following question: > > Postpaid: > > Default it treat all calls as postpaid but in case i want to give number > of mins or time to my single customer then how do i achieve that Example: > 5000 mins or say $500 deposit in customer account then how i can do that > with postpaid? > > > Quota: I never explore this feature so i just want to know how quota > system work with CDRTool? could you give me short explanation? Most of our > customer would be call center or high density call customer, how i can use > quota in that scenario? > > On Sun, Oct 12, 2014 at 9:38 AM, Adrian Georgescu <[email protected]> > wrote: > >> >> On 12 Oct 2014, at 09:48, Satish Patel <[email protected]> wrote: >> >> I have run sipp test and it only able to handle 30 calls and later all >> call failed, >> >> >> Can you explain what exactly failed? >> >> I heard from other user post, CDRTool prepaid can't handle many >> simultaneous running calls. >> >> >> You heard wrong. It cannot handle high density call attempts like calls >> generated from call centers or transit peers like SIP trunks that push lot >> of calls. The number of simultaneous calls is irrelevant. You can have >> thousands of simultaneous calls with almost no performance penalty if the >> traffic is generated by regular SIP user devices. >> >> In our case single account will make many simultaneous calls and we need >> to handle them via prepaid.. >> >> >> It all depends on the meaning of many. Whenever a new call is attempted, >> the maximum remaining time of all ongoing calls of the same user must be >> recalculated so that the balance cannot be exceeded for any of them. This >> means that the more calls for the same user you have, the longer it takes >> to calculated everything over and over again. >> >> If you have many users with a few calls each like in a residential >> scenario where a user makes one or perhaps two parallel calls, this would >> have little impact as there is little to re-calculate. >> >> Some one suggested don't use prepaid because of limitation and >> performance, and suggested use Postpaid or Quota system.. is that true? >> >> >> It all depends on the traffic patterns. Concurrent or simultaneous calls >> is one thing, high density calls/per second attempts is another. There is >> no hard limitation but the number of database queries, distance to MySQL >> database will affect how many calls you can handle because as I explained >> before all concurrent calls must be rerated in real time again for each new >> call attempt. If one SIP account generates 10K parallel calls the load is >> infinite while if you have 10K users with one call each the load is almost >> zero. >> >> This is why a prepaid model is not practical for high density of calls >> and this has little to do with CDRTool, any other system would face the >> same problem, the load is compounded when adding more calls for same >> account. A quota based system is more appropriate for entities that >> generate large amount of calls as nothing has to be calculated on a per >> call basis. >> >> Adrian >> >> On Thu, Oct 9, 2014 at 3:46 PM, <[email protected]> wrote: >> >>> Yes, it is capable. >>> >>> On 08 Oct 2014, at 15:42, Satish Patel <[email protected]> wrote: >>> >>> > Hi, >>> > >>> > Just want to know does CDRTool prepaid capable of handling couple >>> hundreds of concurrent calls? I heard it can handle only 2/3 concurrent >>> calls per account? what is the solution if we want to host big prepaid >>> system with thousands of 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 >> >> >> -- >> Adrian >> >> >> >> >> _______________________________________________ >> 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 > > > -- > Adrian > > > > > _______________________________________________ > 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
