<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">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.<div><div><br></div><div>Adrian</div><div><br><div><div>On 12 Oct 2014, at 11:14, Satish Patel <<a href="mailto:satish.txt@gmail.com">satish.txt@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">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. <div><br></div><div>I have following question:</div><div><br></div><div>Postpaid:</div><div><br></div><div>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? </div><div><br></div><div><br></div><div>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? </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 12, 2014 at 9:38 AM, Adrian Georgescu <span dir="ltr"><<a href="mailto:ag@ag-projects.com" target="_blank">ag@ag-projects.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><div>On 12 Oct 2014, at 09:48, Satish Patel <<a href="mailto:satish.txt@gmail.com" target="_blank">satish.txt@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">I have run sipp test and it only able to handle 30 calls and later all call failed, </div></blockquote><div><br></div></span><div>Can you explain what exactly failed?</div><span class=""><div><br></div><blockquote type="cite"><div dir="ltr">I heard from other user post, CDRTool prepaid can't handle many simultaneous running calls. </div></blockquote><div><br></div></span>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.</div><div><span class=""><br><blockquote type="cite"><div dir="ltr">In our case single account will make many simultaneous calls and we need to handle them via prepaid.. </div></blockquote><div><br></div></span>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.</div><div><br></div><div>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.</div><div><span class=""><br><blockquote type="cite"><div dir="ltr">Some one suggested don't use prepaid because of limitation and performance, and suggested use Postpaid or Quota system.. is that true? </div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Adrian</div><span class=""><div><br></div><blockquote type="cite"><div class="gmail_extra">On Thu, Oct 9, 2014 at 3:46 PM, <span dir="ltr"><<a href="mailto:ag@ag-projects.com" target="_blank">ag@ag-projects.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, it is capable.<br>
<span><br>
On 08 Oct 2014, at 15:42, Satish Patel <<a href="mailto:satish.txt@gmail.com" target="_blank">satish.txt@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> 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?<br>
</span>> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div><br></div>
_______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br><a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br></blockquote></span></div><br><div>
<div style="font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;">--<br>Adrian<br><br><br></div>
</div>
<br></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>http://lists.opensips.org/cgi-bin/mailman/listinfo/users<br></blockquote></div><br><div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">--<br>Adrian<br><br><br></div>
</div>
<br></div></div></body></html>