[Serusers] SER + Prepaid with Radius AAA.

[Mike Tkachuk]

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 at yes.net.ua] 
ST> Sent: Tuesday, March 27, 2007 1:57 PM
ST> To: Shafraz Thawfeek
ST> Cc: serusers at 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 at arcdiv.com] 
ST>>  Sent: Wednesday, March 21, 2007 5:08 PM
ST>>  To: Shafraz Thawfeek; serusers at lists.iptel.org
ST>>  Cc: serusers at 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 
 >>> Hello All, 
 >>>   
 >>> Its really feels nice to have joined the list. I'm in the process of
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? 
 >>>   
 >>> If I am correct, I would like to know what would be the workaround for
ST> this? I'm I am wrong, then I would like to know on how we could get the call
ST> disconnection working? 
 >>>   
 >>> I have a Nextone which would be sitting in front of the SER and acting
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? 
 >>>   
 >>> Thank you. 
 >>> Shaf. 
 >>>   
 >>>   
ST>>  
ST>>  
ST>>   
ST>>   
ST>>     


ST> --
ST> Mike Tkachuk



--
Mike Tkachuk