One Size Doesn't Fit All for Converged DeploymentsOne Size Doesn't Fit All for Converged Deployments
Over the years there have been many technologies come and go that promised to converge voice and data. Protocols such as ATM and ISDN would be the magical thing that would bring our voice and data networks together - and the technology allowed for it, but these were dismal failures. There was even talk about running voice through an IBM mainframe. ISDN wound up being used for frame-relay backup until lower cost DSL became available, ATM was used where frame-relay speeds topped out, and the mainframe idea was just silly (although it did work). So what's the difference this time with using IP instead of traditional voice networking?
January 29, 2008
Over the years there have been many technologies come and go that promised to converge voice and data. Protocols such as ATM and ISDN would be the magical thing that would bring our voice and data networks together - and the technology allowed for it, but these were dismal failures. There was even talk about running voice through an IBM mainframe. ISDN wound up being used for frame-relay backup until lower cost DSL became available, ATM was used where frame-relay speeds topped out, and the mainframe idea was just silly (although it did work). So what's the difference this time with using IP instead of traditional voice networking?
Over the years there have been many technologies come and go that promised to converge voice and data. Protocols such as ATM and ISDN would be the magical thing that would bring our voice and data networks together - and the technology allowed for it, but these were dismal failures. There was even talk about running voice through an IBM mainframe. ISDN wound up being used for frame-relay backup until lower cost DSL became available, ATM was used where frame-relay speeds topped out, and the mainframe idea was just silly (although it did work). So what's the difference this time with using IP instead of traditional voice networking?I've argued for many years that VoIP was never about converging networks, but it was "IP" that delivered the value over all of our traditional "convergence" methods. IP creates a level of flexibility for network and telecom managers that the other Layer 2 technologies did not. All of the other "converged" technologies were done at Layer 2, and that meant that, even though we could converge our networks, all of the other problems with voice remained. Node by node deployments, costly MACDs (moves, adds, changes and deletions) and inflexible deployments made traditional voice a pain to deal with. If a user moves, a whole bunch of work needs to be done to reconfigure the PBX to understand where the phone is and who the user is (it's actually not that much work).
Now, think of any IP based application, take email for example. At Yankee Group we use Lotus Notes. When I'm in the office, the email client knows where the mail server is and the application works. When I'm out of the office, the Lotus Notes application still knows where my mail server is without me having to reconfigure the application to tell it. That's how IP works. As long as the application is running at the IP layer, the client will always find the server (you may need VPN if it's on a private network). With Layer 2 applications, such as voice, the PBX needs to be programmed directly and then every time there's a different network configuration, needs to be reprogrammed.
This "application portability" for voice is one of the main reasons why I think voice done at the IP layer is better. It means companies deploying VoIP can place the call servers where ever they want - in a branch, data center, backup data center or even the telco cloud. So which type of solution is best? The answer is, for most companies, a combination of all of them. The key is to understand what combination works best for your organization, and that means tearing down many preconceived notions such as the following:
Contrary to many deployments I have seen, the best thing to do is not to just replace every PBX and key system with an IP PBX. It's best to treat it like any other IP based applications and locate the servers for optimum performance. For example, going back to email, most companies have a combination of local servers and regional hubs depending on how large the site is.
Network based voice is nothing like the crappy centrex offerings of old. Older centrex services lacked many features of traditional telephony and was very expensive, so no one (except the government) wanted to pay more money for less features. With hosted IP based services, its possible to have the same feature set in the telco cloud as in your data center. One of the reasons many buyers do not understand this is that network operators still use the term "centrex" to describe their offerings with names like "IP centrex", even though it's not centrex. If users don't like centrex, why tie a next generation service offering to something buyers don't like and then have to spend time explaining why its not like the thing you called it? Anyway, the point is that the hosted IP voice services that you can purchase today are far superior to the centrex offerings of old. Vonage is a good example of this (albeit consumer oriented) where you get more features for less money! I know hosted voice has its skeptics (and deservedly so) but I do think hosted voice should be a part of the voice strategy for most organizations.
Voice servers should not be located in the telco closet. PBX are typically located everywhere, including really small wiring closets with no AC or sufficient power. VoIP and UC are applications and should live on servers in your data center!
In many cases, these preconceived notions that exist from the traditional telephony days highly influence the way IP systems are deployed today, meaning much of the benefit you can get from VoIP isn't realized. Client server computing wasn't the same as mainframe computing and we eventually architected applications differently. Similarly, VoIP isn't traditional voice and network and telecom managers should understand the full range of what's available and deploy the various solutions to optimize performance and cost. Without architecting the solution differently, all you'll get is the same thing you have today at a higher cost.
Network based voice is nothing like the crappy centrex offerings of old. Older centrex services lacked many features of traditional telephony and was very expensive, so no one (except the government) wanted to pay more money for less features. With hosted IP based services, its possible to have the same feature set in the telco cloud as in your data center. One of the reasons many buyers do not understand this is that network operators still use the term "centrex" to describe their offerings with names like "IP centrex", even though it's not centrex. If users don't like centrex, why tie a next generation service offering to something buyers don't like and then have to spend time explaining why its not like the thing you called it? Anyway, the point is that the hosted IP voice services that you can purchase today are far superior to the centrex offerings of old. Vonage is a good example of this (albeit consumer oriented) where you get more features for less money! I know hosted voice has its skeptics (and deservedly so) but I do think hosted voice should be a part of the voice strategy for most organizations.
Voice servers should not be located in the telco closet. PBX are typically located everywhere, including really small wiring closets with no AC or sufficient power. VoIP and UC are applications and should live on servers in your data center!
In many cases, these preconceived notions that exist from the traditional telephony days highly influence the way IP systems are deployed today, meaning much of the benefit you can get from VoIP isn't realized. Client server computing wasn't the same as mainframe computing and we eventually architected applications differently. Similarly, VoIP isn't traditional voice and network and telecom managers should understand the full range of what's available and deploy the various solutions to optimize performance and cost. Without architecting the solution differently, all you'll get is the same thing you have today at a higher cost.
Voice servers should not be located in the telco closet. PBX are typically located everywhere, including really small wiring closets with no AC or sufficient power. VoIP and UC are applications and should live on servers in your data center!
In many cases, these preconceived notions that exist from the traditional telephony days highly influence the way IP systems are deployed today, meaning much of the benefit you can get from VoIP isn't realized. Client server computing wasn't the same as mainframe computing and we eventually architected applications differently. Similarly, VoIP isn't traditional voice and network and telecom managers should understand the full range of what's available and deploy the various solutions to optimize performance and cost. Without architecting the solution differently, all you'll get is the same thing you have today at a higher cost.
In many cases, these preconceived notions that exist from the traditional telephony days highly influence the way IP systems are deployed today, meaning much of the benefit you can get from VoIP isn't realized. Client server computing wasn't the same as mainframe computing and we eventually architected applications differently. Similarly, VoIP isn't traditional voice and network and telecom managers should understand the full range of what's available and deploy the various solutions to optimize performance and cost. Without architecting the solution differently, all you'll get is the same thing you have today at a higher cost.
