Re[4]: [Serusers] SER + Prepaid with Radius AAA.

Hello Shafraz, I think you can get more than 200 concurent calls, but I doubt about asterisk stability itself. *B2BUA code is too dumb to have some problems. Wednesday, March 28, 2007 5:47:54 PM, you wrote: ST> Using Asterisk B2BUA, WITHOUT RTP Proxying, How many concurrent calls will I ST> be able to squeeze through without compromising on Stability? Advise much ST> appreciated. ST> Warm Regards, ST> Shafraz Thawfeek ST> -----Original Message----- ST> From: Mike Tkachuk [mailto:mike@yes.net.ua] ST> Sent: Tuesday, March 27, 2007 1:57 PM ST> To: Shafraz Thawfeek ST> Cc: serusers(a)lists.iptel.org ST> Subject: Re[2]: [Serusers] SER + Prepaid with Radius AAA. ST> Hello Shafraz, ST> I'm able to reach ~ 200 concurrent calls with RTP proxied on such hardware: ST> Dell 860, Xeon 3060, 2G RAM ST> Freebsd 6.2, Asterisk 1.4 ST> If you will use SER dispatcher module you can add virtually unlimited ST> amount of *B2BUA machines. ST> Tuesday, March 27, 2007 10:55:46 AM, you wrote: ST>> ST>> ST>> ST>> ST>> Hello All, ST>> ST>>   ST>> ST>> Thank you for the replies again. I would like to know, in case I ST>> decide to go with Asterisk B2BUA, how would the performance, ST>> stability be? and most importantly, how would the scalability be? ST>> I?m not planning to route media via the *box, in that case, how ST>> many simultaneous calls would I be able to get considering my hardware ST> is of high spec. ST>> ST>>   ST>> ST>> Also, I would like to know, has anyone tried using Yate for such ST>> a scenario? Perhaps as a B2BUA, or Standonle with or without SER to do ST> prepaid? ST>> ST>>   ST>> ST>> Regards ST>> ST>> ST>> Shaf. ST>> ST>> ST>> ST>> ST>> ST>> From: sip [mailto:sip@arcdiv.com] ST>> Sent: Wednesday, March 21, 2007 5:08 PM ST>> To: Shafraz Thawfeek; serusers(a)lists.iptel.org ST>> Cc: serusers(a)iptel.org ST>> Subject: Re: [Serusers] SER + Prepaid with Radius AAA. ST>> ST>> ST>> ST>>   ST>> ST>> You are correct. There are several workarounds for this, but for ST>> the most part, what you need is some sort of B2BUA functionality.  ST>> Essentially, the call needs to go through a UAS that DOES keep ST>> track.  The new SEMS is supposed to have some of this ST>> functionality, although I don't know much about it.  Some people ST>> use Asterisk (with Asterisk B2BUA).  We ended up writing our own ST>> Asterisk B2BUA as the Asterisk B2BUA code from sourceforge had ST>> things in it we neither wanted nor used and their patches never ST>> seem to be up to date on the later versions of Asterisk (current ST>> code out there works in a guaranteed way only for Asterisk 1.2.1, ST>> though it wasn't until after 1.2.9.1 that we had to seriously ST>> rewrite the patch). The sourceforge code works, though, for ST>> earlier versions of Asterisk, and is an excellent starting place ST>> if you've little desire to write the whole thing yourself. ST>> ST>> The concept of using Asterisk is pretty simple:  call gets ST>> forwarded from SER to an Asterisk AGI program (C, Perl, etc) that ST>> does all the magic.  The easiest way is to do a balance check when ST>> the call comes in to determine the cost of the outgoing call and ST>> check how much time a person has left on the call based on how ST>> much money is in their account. Then, just set up an Asterisk Dial ST>> command with the appropriate timeout and let the server take care ST>> of the rest.  There are tricks to this, of course. Unless you're ST>> somehow updating call credit and call timeout on the fly, you'll ST>> need to limit the incoming calls to one at a time for each ST>> account, or it's easy for someone to call with multiple phones and rob ST> you of cash. ST>> ST>> N. ST>> ST>> ST>> On Wed, 21 Mar 2007 12:27:27 +0530, Shafraz Thawfeek wrote ST> deploying a SER based solution for prepaid users. We're using a FreeRadius ST> based billing solution from a provider. If I'm not mistaken, SER is not ST> aware of the call state, what this means to me is, in case the user account ST> on the radius runs out of credit, SER will not know about it and will not be ST> able to disconnect the call. Am I correct on this? ST> this? I'm I am wrong, then I would like to know on how we could get the call ST> disconnection working? ST> as a Mirror Proxy for SER. The purpose of this is to overcome NAT traversal ST> issues and free SER from that. Nextone doesn?t understand or talk radius. ST> SER will be the registrar and handle AAA. The user call will be sent back ST> into the Nextone and then terminated from there. SER will not be handling ST> media. If to get my disconnect upon credit exhaust scenario working, what ST> changes should I introduce into my existing network model? ST>> ST>> ST>> ST>> ST>> ST> -- ST> Mike Tkachuk -- Mike Tkachuk