Hello Mike,
This is SER running on Separate server and Asterisk running on Separate
server, right?
If you're able to reach ~200 with RTP, should I be able to comfortably state
that I might be able to Achieve about ~1000 concurrent calls on a Single
*Server without RTP?
This is interesting. Asterisk doesn't look a bad option at all.
Can you please tell me, what advantages/disadvantages I might have by
proxying RTP / Not proxying RTP.
I will be having a Nextone MSX sitting in front of SER, and all users will
be registering to the SER via the Nextone. So I'm planning to let Nextone
handle all the RTP work.
Warm Regards,
Shafraz Thawfeek
-----Original Message-----
From: Mike Tkachuk [mailto:mike@yes.net.ua]
Sent: Tuesday, March 27, 2007 1:57 PM
To: Shafraz Thawfeek
Cc: serusers(a)lists.iptel.org
Subject: Re[2]: [Serusers] SER + Prepaid with Radius AAA.
Hello Shafraz,
I'm able to reach ~ 200 concurrent calls with RTP proxied on such hardware:
Dell 860, Xeon 3060, 2G RAM
Freebsd 6.2, Asterisk 1.4
If you will use SER dispatcher module you can add virtually unlimited
amount of *B2BUA machines.
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> Im 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
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
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
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
deploying a SER based solution for prepaid users. We're using a FreeRadius
based billing solution from a provider. If I'm not mistaken, SER is not
aware of the call state, what this means to me is, in case the user account
on the radius runs out of credit, SER will not know about it and will not be
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
this?
I'm I am wrong, then I would like to know on how we could get the call
disconnection working?
>
> I have a Nextone which would be sitting in front of the SER and acting
as a
Mirror Proxy for SER. The purpose of this is to overcome NAT traversal
issues and free SER from that. Nextone doesnt understand or talk radius.
SER will be the registrar and handle AAA. The user call will be sent back
into the Nextone and then terminated from there. SER will not be handling
media. If to get my disconnect upon credit exhaust scenario working, what
changes should I introduce into my existing network model?
>
> Thank you.
> Shaf.
>
>
ST>
ST>
ST>
ST>
ST>
--
Mike Tkachuk