asterisk users - Apr 2007 - SER/OpenSER, I Finally Get It.............General Observation

Sorry if this hit the list twice, sent out yesterday, but didn't see it show
up.

Hi All,

Can Asterisk be used as a SIP proxy, blah, blah, blah???

I've glanced over questions like this through the years, with a good idea on
what a SIP proxy is and what Asterisk is and IS NOT.  I never really took
the time to lab-up SER and test drive it to see what advantages might be
gained from using it to front-end an Asterisk Cluster.  In fact, I pride
myself on using Asterisk (alone) to its fullest ability to accomplish my
clustering and scaling goals.  As an ITSP, adding customers, means racking
and stacking more Asterisk servers and gel them into the Cluster, no
problem.  Adding PSTN connectivity would mean the same for the most
part..............here lays the conundrum.

I didn't have a good way to load balance the PSTN connections, and as
embarrassing as it is, Cisco Call Manager connections as well.  So after
growing and scaling a bit, I realized I would need a load balancer for
non-asterisk SIP originating trunks coming into the Asterisk Cluster.  After
a few minutes of pondering, said to myself, I can really use a good SIP
proxy with a round-robin load balancing mechanism.  SER came to mind.

I always wanted to mock up SER and test it out, but never had a strong need
for it.  After reading the some documents and such 'Hello World',
literally
2 to 3 hours of researching and about an hour of lab server setup and SER
installation, I had phones registered and talking.  Once the foundation was
laid, I loaded the dispatcher module in SER and with a bit of trial and
error with the config file, had load balancing fired up across 4 Asterisk
servers.  Not exactly what I was looking for, SER has random load balancing,
so the distribution across the cluster varied widely.

I checked out OpenSER (a SER fork), which has a newer dispatcher module,
incorporating a round-robin load balancer and skip-to-the-next-server
fail-over mechanism.  This actually performed more to my liking.  A couple
of little bugs, the last entry in the dispatcher.list is skipped over for
some reason and the first entry in the dispatcher.list is called twice (can
someone tell me why this is or tell me how to fix it?).  Now for the test:

I created a call-loop, like a stress test, between an Asterisk server acting
as a PSTN Gateway device and 4 Asterisk servers in a Cluster arrangement
load balanced by OpenSER in between.  Since OpenSER is just a proxy, no
audio was used.  I initiated 80 calls to SER which proxy'ed the calls to the
4 Asterisk servers, in turn those 80 distributed calls initiated 80 more
calls which looped back to OpenSER, and back to the 4 Asterisk servers
generating 80 more calls and so on.  The calls continued till the Asterisk
servers pretty much cratered, couldn't open any more files, SIP resources
unavailable, 1300+ sip channels open, proc utilization 50%+............all
in a matter of a few second.

OpenSER took all that 5 Asterisk servers could handle and never winced,
didn't break a sweat, did not even breach 2% proc utilization.

I ran this test more than 10 times, each concluding with reloading all 5
Asterisk servers to re-gain control.  I did not reload Open SER once.

Two things come out of this testing, first and foremost, I am still and will
always be a true Astriholic; and second, I can't seem to break OpenSER and
if you can't break-em, join-em.

Can I use OpenSER as a voicemail server, blah, blah, blah???

JR

JR Richardson
Engineering for the Masses

JR Richardson wrote:
> Sorry if this hit the list twice, sent out yesterday, but didn't see 
> it show up.
>
> Hi All,
>
> Can Asterisk be used as a SIP proxy, blah, blah, blah???
>
> I've glanced over questions like this through the years, with a good 
> idea on
> what a SIP proxy is and what Asterisk is and IS NOT.  I never really took
> the time to lab-up SER and test drive it to see what advantages might be
> gained from using it to front-end an Asterisk Cluster.  In fact, I pride
> myself on using Asterisk (alone) to its fullest ability to accomplish my
> clustering and scaling goals.  As an ITSP, adding customers, means 
> racking
> and stacking more Asterisk servers and gel them into the Cluster, no
> problem.  Adding PSTN connectivity would mean the same for the most
> part..............here lays the conundrum.
>
> I didn't have a good way to load balance the PSTN connections, and as
> embarrassing as it is, Cisco Call Manager connections as well.  So after
> growing and scaling a bit, I realized I would need a load balancer for
> non-asterisk SIP originating trunks coming into the Asterisk Cluster.  
> After
> a few minutes of pondering, said to myself, I can really use a good SIP
> proxy with a round-robin load balancing mechanism.  SER came to mind.
>
> I always wanted to mock up SER and test it out, but never had a strong 
> need
> for it.  After reading the some documents and such 'Hello World', 
> literally
> 2 to 3 hours of researching and about an hour of lab server setup and SER
> installation, I had phones registered and talking.  Once the 
> foundation was
> laid, I loaded the dispatcher module in SER and with a bit of trial and
> error with the config file, had load balancing fired up across 4 Asterisk
> servers.  Not exactly what I was looking for, SER has random load 
> balancing,
> so the distribution across the cluster varied widely.
>
> I checked out OpenSER (a SER fork), which has a newer dispatcher module,
> incorporating a round-robin load balancer and skip-to-the-next-server
> fail-over mechanism.  This actually performed more to my liking.  A 
> couple
> of little bugs, the last entry in the dispatcher.list is skipped over for
> some reason and the first entry in the dispatcher.list is called twice 
> (can
> someone tell me why this is or tell me how to fix it?).  Now for the 
> test:
>
> I created a call-loop, like a stress test, between an Asterisk server 
> acting
> as a PSTN Gateway device and 4 Asterisk servers in a Cluster arrangement
> load balanced by OpenSER in between.  Since OpenSER is just a proxy, no
> audio was used.  I initiated 80 calls to SER which proxy'ed the calls 
> to the
> 4 Asterisk servers, in turn those 80 distributed calls initiated 80 more
> calls which looped back to OpenSER, and back to the 4 Asterisk servers
> generating 80 more calls and so on.  The calls continued till the 
> Asterisk
> servers pretty much cratered, couldn't open any more files, SIP
resources
> unavailable, 1300+ sip channels open, proc utilization 
> 50%+............all
> in a matter of a few second.
>
> OpenSER took all that 5 Asterisk servers could handle and never winced,
> didn't break a sweat, did not even breach 2% proc utilization.
>
> I ran this test more than 10 times, each concluding with reloading all 5
> Asterisk servers to re-gain control.  I did not reload Open SER once.
>
> Two things come out of this testing, first and foremost, I am still 
> and will
> always be a true Astriholic; and second, I can't seem to break OpenSER 
> and
> if you can't break-em, join-em.
>
> Can I use OpenSER as a voicemail server, blah, blah, blah???
>
They do indeed each have their strengths.

And technically yes, you can use OpenSER as a voicemail server when 
combined with something like the SEMS module, but it's not even a small 
percentage as feature-rich as using Asterisk as a voicemail server.  
Asterisk is PBX software. It's damned GOOD PBX software, and it has a 
lot of add ons that add additional bits here and there, but in the end, 
its focus is around that core of PBX telephony technology.  The SIP 
stack for Asterisk is one of those add ons. It's not as powerful for 
pure SIP communication as SER/OpenSER, but it makes up for it in that it 
meshed exceptionally well with the other aspects of Asterisk, creating a 
very powerful application as a whole.

Many SIP-based VoIP companies use SER/OpenSER for pure SIP 
communication, but use the strengths of Asterisk as an endpoint (and as 
a Back to Back UA), allowing Asterisk to really shine where it's best: 
voicemail, menuing/IVR technology, managing the call state, etc.
It makes an incredibly powerful combination where just one of the two 
wouldn't have quite the same capability.