[OpenSIPS-Users] CDRTool prepaid for big installation

Adrian Georgescu ag at ag-projects.com
Tue Oct 14 19:17:46 CEST 2014


On 14 Oct 2014, at 13:02, Satish Patel <satish.txt at gmail.com> wrote:

> 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? 


Check if the user belongs to that group and if yes don't let the call go through. It has nothing to do with call control, is just a database query.

Adrian



> 
> 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 <ag at ag-projects.com> 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 <satish.txt at gmail.com> 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 <ag at ag-projects.com> wrote:
>> 
>> On 12 Oct 2014, at 09:48, Satish Patel <satish.txt at gmail.com> 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, <ag at ag-projects.com> wrote:
>>> Yes, it is capable.
>>> 
>>> On 08 Oct 2014, at 15:42, Satish Patel <satish.txt at gmail.com> 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
>>> > Users at lists.opensips.org
>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> 
>>> 
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> 
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> --
>> Adrian
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> --
> Adrian
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

--
Adrian



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20141014/8b717114/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opensips.org/pipermail/users/attachments/20141014/8b717114/attachment.pgp>


More information about the Users mailing list