[Asterisk-Users] Fair comparison

[John Todd]

At 1:41 PM -0500 8/12/03, James Sizemore wrote:
>
>Big issues for sip:  (Please note I use both Asterisk and Vocal 
>between the two you can have a fairly scalable sip environment with 
>a fair amount of call features.)
>
>Pluses for Vocal:
>For sip switching Vocal is much more scalable, You can have a 
>cluster of UserAgents and Gateways. It never terminates rtp streams 
>so  Vocal can not easily be over run with
>calls. But vocal is mostly just a voip call switch. (Like SER)
>Negatives for Vocal:
>Has Zero usable call features, It can route sip calls all day no 
>problem, Don't even try to have it do call features everyone of them 
>has some problem or another.
>
>Asterisk pluses: It has call features, Not always implemented the 
>best way but has them in boat loads!  Asterisk is an ok switch for 
>sip calls, but you can never have more then one box doing the job. 
>Asterisk Negatives:  It crashes. (It is development code) It 
>terminates every sip call that goes through it so can only scale to 
>the point of the boxes ability to excepts the rtp streams. (You can 
>do some clustering of dial plans but this does not help with 
>incoming sip registration and call paths IE your call drops if your 
>box reboots)

This, supposedly, is not true.  Asterisk can be told to allow end SIP 
devices to talk directly to each other, and only in some 
circumstances should they push their audio through the server. 
However, there seem to be bugs with that code at the moment, and as 
recently as this morning I was discussing these problems with others 
on the IRC channel.

One of the nice features about Asterisk is that it can, with "smart" 
UA's, work through NAT, even those that utilize dynamic external 
address assignments.  The problem that I have found is that I cannot 
conceptually think of a way that Asterisk's NAT tricks can work 
without having the RTP audio go through the server as a proxy.  This 
is, I suppose, one of the understood shortfalls of having SIP clients 
behind NAT.

>You may also want to through SER in your list of systems to evaluate.

I agree.  SER is quite powerful, and has an (IMHO) 
easier-to-understand configuration "scripting" language for handling 
calls (easier than Vocal, that is.)   However, SER is a SIP proxy and 
not a "PBX replacement" like Asterisk.  A combination of SER and 
Asterisk or Vocal and Asterisk is a tough combination to beat if 
you're in a large environment.  Depending on your requirements and 
your realistic expectations of eventual size, it is even completely 
reasonable to implement Asterisk as a total solution.  There are 
plenty of methods that a halfway-decent sysadmin can implement to 
ensure redundancy and scalability of Asterisk that are not 
necessarily application-layer tricks.

As far as Asterisk's stability goes: new features tend to be less 
stable than older features, just like any software.  If your user 
base isn't requesting all the bells and whistles, then adequate 
testing will normally reveal problem spots before you stumble across 
them in production.  Despite what some others on the list may claim, 
running the absolute latest CVS on production systems without testing 
is probably unwise.  :)

JT

>Kim C. Callis wrote:
>
>>I was trying to do a little searching to see if there has even been a
>>comparison between Asterisk and VOCAL or any of the other OSS packages?
>>"Practical Voice Over IP using VOCAL" published by O'Reilly and
>>Associates, attempts to make a strong case about how scalable VOCAL. Of
>>course, considering that the book is written by the makers of VOCAL, it
>>tends to have a one sided slant.
>>
>>Maybe we should try to put together an unbiased comparison (read that as
>>pro/con). I was talking at a meeting about Asterisk, and someone
>>attempted to start flaming Asterisk, and swearing by VOCAL, while
>>another was babbling about the wonders of Bayonne. The only thing that
>>was successful in that meeting about VOIP solutions was tabling that
>>discussion until a future (as in way, way in the future) date.
>>
>>Just a thought!
>>
>>Kim C. Callis
>>