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
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
