Great! I figured out, it was group module. -- Sent from my iPhone
> On Oct 14, 2014, at 1:17 PM, Adrian Georgescu <[email protected]> wrote: > > >> 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 > > > > _______________________________________________ > 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
