On 14 Oct 2014, at 13:02, Satish Patel <[email protected]> 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 <[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

--
Adrian



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to