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
