[asterisk-users] Large Asterisk installarions (~10, 000 extensions), preferably at universities

[Michael Collins]

> Date: Fri, 21 Nov 2008 16:20:28 -0600
> From: Terry Wilson <twilson at digium.com>
> Subject: Re: [asterisk-users] Large Asterisk installarions (~10,
000
> 	extensions), preferably at universities
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> 	<asterisk-users at lists.digium.com>
> Message-ID: <E03AA2A5-4850-4340-A50D-8DF93E1FBF91 at digium.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> 
> > Yehavi Bourvine wrote:
> >
> >> OK, but I still did not get a reply to my original question: Why
> >> using
> >> SIP registrar in front of Asterisk and not simply use bare
Astersik?
> >> can't it handle the load? (remember - in my case it doesn't handle
> >> the
> >> RTP, only signalling). Can't it handle so much registrations? (I am
> >> using realtime DB, it is has any relevance).
> >
> > My experience has shown that using a dedicated registrar for large
> > installs is more effective;  it doesn't tie up resources on the
> > Asterisk
> > box with all those registration refreshes, for one.  A product built
> > to
> > be a high-throughput standalone registrar will handle the
concurrency
> > requirements and perform better.
> 
> I've looked at doing various things to chan_sip to improve signaling
> performance (hash tables for call lookups, etc.)  I gave up when I
> realized that the overhead of handling the RTP was so far above the
> overhead of processing SIP signaling that it didn't really matter
> much.  The only reason I have ever had to use a SIP registrar (OpenSER
> in my case) was if I needed to load balance calls across multiple
> asterisk servers.  If most of the phones are not separated by a NAT
> from Asterisk (as would be the case in something like a University
> network), the registration timeout could be set to a relatively high
> value w/o causing any problems which would cut down on some of the SIP
> traffic from registrations.
> 
> In fact, I just ran some tests using SIPp and w/o any audio, using
> realtime w/ 10k accounts I can register 100/second while doing 10
> calls/second.  If you are looking just at registrations every 15
> minutes or so, that is 90k devices that could register to asterisk.
> This was using 1.6.0.1 on my little HP amd64 development box--not
> anything near the kind of machine that you would probably install in a
> large installation.  Asterisk just gets faster and faster.  Some of
> the "it isn't good at x" stuff comes from experiences with older
> releases.

In a HA and/or high volume scenario I worry about stuff like this that
has been in tree since 1.0 or earlier and is in 1.6, channel.c lines
3825~3828:

        /* XXX This is a seriously wacked out operation.  We're
essentially putting the guts of
           the clone channel into the original channel.  Start by
killing off the original
           channel's backend.   I'm not sure we're going to keep this
function, because
           while the features are nice, the cost is very high in terms
of pure nastiness. XXX */

That's not something I want in my high-end, high-capacity,
high-availability production system!

For smallish installations, this probably isn't a big deal given today's
hardware capabilities. Still, it makes me wonder what other gremlins are
out there that might bite me in a big-time install. 

At least with OSS I can see stuff like this. I shudder to think what
psycho spaghetti code is running on Cisco, Avaya, Nortel, NEC, Shoretel,
etc.

-MC

> 
> If you are lucky enough to have a situation where you can re-invite
> media and keep it off of the asterisk box, it can handle huge loads.
> 
> Terry