Why PBX Functions MatterWhy PBX Functions Matter

What's another word for "features," as in "PBX features" (the infamous list of 500-800)? Well, the word that one of the audience questioners used in my SIP session this morning was: Value. As in, "People I talk to are concerned about the danger of losing value in the system" if they migrate to a SIP-based system that provides fewer functions. Of course: "Functions" = "Value"

What's another word for "features," as in "PBX features" (the infamous list of 500-800)? Well, the word that one of the audience questioners used in my SIP session this morning was: Value. As in, "People I talk to are concerned about the danger of losing value in the system" if they migrate to a SIP-based system that provides fewer functions.

Of course: "Functions" = "Value"And mind you, that's what the vendors have spent the last couple of decades, as they accumulated that feature set, telling the customers that they were buying when they checked off the 500 features: They were getting something that added value to their communications systems.

What had happened in this session was, my vendor panelists talked about the PBX feature set the way vendors do these days: You've got 500 features, nobody uses them all; "standard SIP" gets you maybe a couple dozen of these features, but it also opens up a whole world of possible new features. So that, they said, is why SIP is important.

A different audience member quickly got to the salient point more concisely than I've been able to do in a couple of years' worth of writing: Why do I have to decide which couple dozen features are still going to be important to me? Why can't I have them all?

He was really making the same point as the questioner I wrote about at the top of this post: If you're telling me SIP doesn't support the same number of features as TDM PBXs, then what you're telling me is that a SIP PBX doesn't provide as much value as a TDM PBX (or an IP-PBX that uses proprietary protocols to achieve the same results as TDM has).

Now, to a certain degree I sympathize with the vendors in all of this. On the one hand, customers are saying they want interoperability. They think the vendors should be SIP-compliant. And yet they're also saying they want all the legacy capabilities as well--capabilities whose roots are in proprietary implementations, and which cannot all, in any practical way, be re-created via SIP as the standards and the process are currently established.

That means the vendors are sort of constrained in all of this. They're being asked to be proprietary over here, if that's what's required to deliver the features; and be open over there, if that's what will enable the future capabities that they've been talking about.

The thing is, enterprises are constrained too, in every way as constrained as the vendors. They want to move to the new world the vendors keep talking about, but they can't--they actually can't--give up the value that their current systems' functionality provides to their businesses.

That's why SIP is taking so long and is still falling short of what everybody's been predicting for it.