In the other corner with decades of international experience and engineering and a strong alliance with IBM/Microsoft is Nortel/PingTel.
Last week we saw comments from Nortel on why they acquired PingTel and why this solution is better than the "old Asterisk".
One would imagine this comment was the straw that broke the camel's back:
Today, Digium's Bill Miller responds...
Blog Response for The Hyperconnected Enterprise Post
Presented with the disruptive threat of open source Asterisk, and the recent momentum seen in commercial channels and the enterprise, Nortel acquired sipXecs. Can you buy your way into open source credibility? Nortel's not the first old-line company to try. Is open source a marketing bullet point for Nortel ? Its certainly not inherent behavior that's woven into the fabric of the company!
Hey, I can't blame them -- if you were Nortel, and saw Digium and Asterisk on one side and Microsoft on the other, threatening to eat into your core business, what would you do?
So: Bravo, Nortel! Welcome to the next generation of telephony. But you'll need to learn the strengths and limitations of what you just bought. As we have learned from our commercial customers as well as the countless numbers of Open Source Asterisk installations, SIP is not the entirety of UC. True, Asterisk isn't a SIP proxy -- because a SIP proxy alone cannot provide services the world has come to expect from phones.
To pick a specific example of the rather misleading comments in your article: It's incorrect when you claim that all Asterisk calls go through a centralized system. We assume you've just been misinformed, but your claim that Asterisk is designed to always handle media streams is just incorrect. You should recognize that the Asterisk rhetoric from the sipXecs and FreeSwitch teams refers to Asterisk over 4 years and several versions ago when they last looked at the feature set. In some cases, the Pingtel/sipXecs team in particular likes to compare against specific SMB packaged systems and not native Asterisk, which would provide a more "same page" comparison. The SCS500 scales to 500 users. It certainly does not need the power already in Asterisk today.
Let's talk real numbers. Asterisk community members have quickly created testbed platforms which process 300 SIP calls per second capacity. When RTP is managed by an Asterisk instance, we have demonstrated as many as 1900 concurrent G.711 channels on inexpensive off-the-shelf hardware. The open source versions of Asterisk were designed to handle hundreds of thousands (yes, hundreds of thousands) of end users in different circumstances, spread across multiple machines with functional role distribution in a way completely unlike a PBX. Of course, smaller SMB solutions are selling well for our Switchvox line as well as a dozen or more other companies who repackage Asterisk with limited hardware or license caps - that is their business. But please be a bit more forthcoming in your comparisons - Asterisk is being run in systems spanning huge user PBX and service delivery populations.
For sipXecs to compare themselves against the pre-packaged SMB offerings of Asterisk in different flavors is misleading. That's like saying the Apache web server on my embedded-processor webcam can only handle 2 simultaneous streams, therefore Apache doesn't scale on any platform. So while Asterisk can serve as a PBX, it can (and for countless customers and projects already does) also serve as an incredibly flexible service-delivery platform for UC services, custom application development, or carrier VoIP integration. It can be used on even the smallest embedded platforms (Linksys WRT54G, AA50) or on the largest voice server farms such as Integrics' Enswitch which directly supports over 100,000 end points and over 6,000 concurrent calls just for one of their 40+ customers and integrates easily through Asterisk APIs to multiple billing solutions.
As the "wildcard" name suggests, Asterisk works with numerous protocols and codecs. When required for communication between disparate endpoints, Asterisk will intelligently negotiate and transcode between them. If the two are compatible, Asterisk will hand off the call and get out of the way. Asterisk has the flexibility of handling media if desired, but RTP between endpoints is the preferred design for larger systems, including video, which Asterisk has handled for several years now.
In contrast, the sipXecs architecture enforces the requirement that all endpoints be uniform, which pulls along all sorts of ugly forklift-upgrade requirements for businesses looking to grow into the future, or uses expensive media gateways to do what Asterisk can do in software. We can confidently say that Asterisk does UC and that sipXecs is simply a SIP platform that requires lots of other moving parts to get the job done. Don't take our word for it--read their comparison posts, which say sipXecs needs other components to complete their system. Asterisk handles the "U" in UC (as well as the "C") and has for some time now.
The only claim that seems to be correct in Tony Rybczynski's post is that for large Asterisk installations, there is no comprehensive management interface for all possible aspects of the system. There are multiple web-based interfaces available for small/medium enterprise PBX-style installations - FreePBX is the most popular open source tool, and Digium's Switchvox being an excellent representative of a commercial packaging. Both of these examples include automatic phone configuration and provisioning. However, Digium has found that large enterprise developers who wish to harness the true power of the system typically want to have call control at a much more fundamental level than what a GUI typically offers or what a vendor might consider "simplified." Therefore, Asterisk is available as a telephony toolkit - a suite of programs and fundamental tools that allows a developer to quickly deploy new voice apps or extend existing legacy platforms if they so choose - it is as flexible as the circumstances require.
One final observation counterpoint to a comment you made: As the progenitors of the venerable DMS-100, Nortel should know by now that the age of code -- or lines of source -- mean nothing when compared against other software. Do more lines of code indicate more features or quality? Do fewer lines evidence efficient, bug-free code? Lines of code are typically irrelevant in doing anything other than measuring platforms against themselves over time or measuring individual coding productivity.
It's going to take more than this acquisition to, as Tony says, solidify Nortel's "leadership in the global open source ecosystem." We hope that this purchase creates a more viable and useful application that can be used by the open source community - we hope this isn't a repeat of the Vovida(Vocal)/Cisco purchase and subsequent smothering. But for the sake of the open source telephony movement that Digium started, Nortel, we welcome you to the open source revolution.