I'm going to partially agree with the OP here.

Phones speak more than just SIP, ICMP and DHCP, at least intelligent phones do.

FYI- In many cases, particularly where external companies are implementing the system, the voice engineers don't have access to the network; we can only recommend solutions, it's not up to us to implement them.

When was the last time you deployed a 50,000 user telephony system? It's not always as simple as "following best practices", particularly when you begin integrating 3rd party solution, ranging from voice mail to ivr to any of the other numerous technologies you can add on.

Anything sufficiently complex enough will have problems somewhere along the line, that's the nature of things created by beings of our limited mental capacity.

Where did you learn to design enterprise telephony systems? You've got it half right.

Centralized deployment models have numerous advantages from cost to configuration, maintenance and It also reduces overall system complexity.

Best practice is a centralized deployment model with a local voice gateway connected to the PSTN per site (MGCP, H323, SIP, doesn't matter) configured for SRST (call-manager-fallback).

Simple.
Clean.
Survivable.

This is no different between installations of 10 sites or installations of 10,000 and is why it's so damn effective.

Decentralized deployments need to have strict justification, otherwise you're wasting your time and energy.

Precisely.

I couldn't find any mention to the specifics of the attack in the article, but if it is related to the services button, then i question how these attacks are being performed. The services button fetches a url on every press, unless I am missing something (and its quite possible I am), the only way to do anything malicious is to somehow hijack that request to a custom server informing the phone of some malicious service.

I suspect you and the OP have no actual experience with the system, so I'll say the following:

-No engineer I know enables more services than we need. Only inexperienced engineers who don't know what service does what activates them all.
-Troubleshooting isn't as difficult as you make it to be. CUCM includes very detailed logging facilities, the trick is knowing how to read them.
-VoIP security, specifically with CUCM, in my experience is rarely implemented. It's not as big of a problem as this article makes it seem. Furthermore, if the malicious person is on your network, you've got a general security problem. If the malicious person is physically connected to your network, you have other problems to worry about.
-Not all third party applications support SRTP and will break if implemented.
-Overall platform stability and security comes down to who deployed it.

As an design/implementation engineer, I can say we only harden systems when there is a specific requirement for it or by request. It is not general practice, nor should it be.

I suspect that last sentence will bring down the herd so I shall clarify:
Implementing security has a lot of implications, not only from a technology standpoint but from a political/office politics standpoint as well. Careful consideration is needed before deploying.

Out of the box nothing works. Services have to manually be activated and started.

The recommendation is to disable CDP on interfaces facing towards end user devices and neighbors you don't control, not disabling CDP entirely.

I agree. There is nothing new here and the reactions seen in the comments are precisely why I cannot frequent this site anymore.

I have a client still using first generation phones (bought new at the time) without issue. Sure, some fail over time, but hardware what doesn't?

Sounds to me you've not worked on UCM recently, if it all.

Call Forward No Coverage.

LCR (from the very beginning):
  1. Create a Route Group containing the gateway or trunk device for the site you are configuring LCR
  2. Create a Route List containing the previously created Route Group
  3. Create a Route Pattern for the LCR pointing to the Route List previously created

That's all.

Cisco's Unified Communications Manager platform is extraordinarily well built once you move past version 7.1.3 (6 was a solid, but 7 introduced logical routing and other important features). Yes it is expensive. But it is robust, stable and the pool of knowledgable engineers can't be denied; if you don't understand the immediate value of that I've wasted your time and mine. Lastly, before I end this rant, one word: support. Who do you call for support at 10pm for your Asterix box? Sure, some companies provide support, but not on the same level Cisco can provide.

I am now certain you either have no experience with Cisco's UC platform or simply live with your head in the sand. The technology is called Survivable Remote Site Telephony (SRST).

Comparing Asterix to Cisco's UCM is disingenuous as they have entirely different markets with different requirements.

The simple fact of the matter is you don't deploy Asterix if you can afford UCM (if you can afford it, you're likely large enough to benefit from it).

So, to recap:
-Enterprises need support. They need it yesterday when problems arise.
-Knowledgable engineers to support and maintain the solution.
-UCM was built to scale. I'm talking 300 sites, 150,000 end points, 12 call processing agents (termed Super Cluster when you have more than 8), numerous MoH/TFTP servers and the like. This is easily possible with CUCM, and it's extremely stable.
-The platform is easily extended to Presence, WebEx, Contact Centers, Attendant Consoles, and numerous 3rd party applications.
-Cisco has another advantage which no other company in the world can claim: They own the network. That means a fully integrated solution, from the switch to the handset, and the numerous benefits that entails.

An aside, of the clients I have personally migrated from Asterix (of which there are 4), none had more than 5,000 end points.

Please acquire some perspective before you go around baselessly besmirch the big bad corporation and their products, and please don't try to make an argument about the feature set differences. That's never the deciding factor with these two products.

P.S: the virtual person you describe is available as a 3rd party solution.

Well, that turned out longer than I intended; apologies, as I could keep going on and on about this subject.

I believe the parent is referring to the libraries and such. Installing anything requiring recent/new libraries on debian stable is a bitch because the libraries are so old, you go to do your ./configure script, and you're riddled with "version found x.x.x version expected > y.y.y" and such