asterisk users - May 2007 - Fwd: SER as a Session Border Controller

I am curious if it is advisable to use implement Asterisk as a Session
Border Controller for a VoIP reseller environment. Users will terminate
calls SIP to my server, which will authenticate them via RADIUS, perform a
LCR lookup, select an appropriate trunk (based on LCR), and terminate the
call (update RADIUS accounting at end of call). All while acting as a B2BUA
to prevent the users from seeing the private peers. I need to have
approximately one DS3 capacity (approx. 672 calls)... I've heard from some
that Asterisk is not mature enough / too bloated to accommodate this volume
of calls. I hope to run this all on a dual core xeon (2.4ghz) with 4gb of
ram. I was also looking into OpenSER, but I hear that this configuration
would be pretty difficult.

Thanks,

kn0x
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20070511/1059abf9/attachment.htm

Greetings,

   It is my impression that Asterisk cannot safely handle more than about 
100-200 calls in parallel, but it may be possible to increase the yield by
removing any transcoding and offloading some of the channel functionality
to hardware DSP boards.  I do not know much about this, and specifically do
not know how much help they would be if there is no transcoding to be
performed per se.

   Some of the stuff you're wanting to do - authenticating via RADIUS, 
perform an LCR lookup, select trunks - is best done by a proxy that sits
behind Asterisk.  OpenSER can certainly interface with this kind of call
logic, and what's more, it can act as a registrar.  It certainly does have
a bit of an abstruse learning curve, but I can say it's not impossible to
figure out by any stretch of the imagination, having been through that
multiple times for inbound call processing / distribution tasks.

   I am not sure that what you are attempting to describe really fits the 
definition of a session border controller, however.  An SBC really only
holds the SIP URI reachability information (contacts) for end-users and
not much else.  In most other respects it behaves rather like a proxy;
authentication is done by handoff to a backend registrar/proxy, any kind
of call routing is also typically farmed out to backend proxies.  The
SBC more or less does exactly what its name suggests;  it provides a 
"border," a logical horizon of call control.  Otherwise, it's a
pretty
dumb device, whereas what you appear to be alluding to sounds more like
a rather intelligent processing endpoint.

   Sometimes the SBC stays in the media path, and sometimes it doesn't.  It 
depends on the implementation.  And some SBCs can provide primitive native
registrars, but this isn't typically thought scalable or desirable from a
systems integration standpoint.

   So, in the grand scheme of things, the situation usually resembles:

                                              +----------+
                                              | Backend  |
     Client <--/- Internet -/----> SBC <----> | Platform |
                                              | -------- |
                                              +----------+

   A "backend platform" can be an array of specialised proxies and 
registrars, which may or may not be one and the same, that ultimately
direct the call to other endpoints within or outside of the service
provider's network.  Or it can be a softswitch that has a built-in
call agent / registrar / proxy / media gateway rolled in, or any number
of other curious configuration possibilities.

-- Alex


--
Alex Balashov   <sasha@presidium.org>