It's the spring of 1998. I'm having lunch with two old friends, David Tucker and Richard Platt, at an Outback Steakhouse restaurant. We are discussing the company they have cofounded, Selsius Systems. They tell me that they have developed the perfect technology for the integration of voice, data, and video. Thinking back on that lunch meeting now, I remember stirring my iced tea with a sense of déjà vu. My mind immediately wanders back to 1986.
In 1986, while working for ROLM Corporation, I was part of a team that sold and installed a voice and data integration solution to a large university in Dallas, Texas. David Tucker was the sales manager leading the team. We installed over a thousand digital telephones with data connectivity to allow the connection of asynchronous devices to the ROLM CBX selected by the university.
One of the key criteria for the university was their desire for a more cost-effective means of connecting data devices to various data sources, both internal and external. They looked at the PBX as the logical staging point for integrating voice and data. They bought into the promise of easier administration, of single wiring to the desktop, of shared access to various data hosts—all in the name of saving dollars.
Years later, in 1994, David and I were together again, this time at Intecom, where we continued to blur the lines between voice and data with a product called InteLAN. InteLAN was a connectivity hub integrated into the Intecom PBX and was the brainchild of an engineering team headed by Richard Platt.
Fast forward to the Outback Steakhouse in 1998. I am listening to David and Richard excitedly discuss this new product and where it is going to take the industry. I remember the single, simple thought that jumped into my head at that moment:
"Haven't we been down this road before?"
I suspect that many people, when they first hear of IP telephony (IPT), react in much the same manner.
"Here we go again."
"Voice and Data Integration, Part 2."
I can't blame people for thinking this, because in many aspects, it is true. Integrating voice and data into a single platform is not a new idea. (Some might argue it is not even a good idea, but I'll cover that later.) The PBX manufacturers championed this concept back in the 1980s. The idea at that time was to use the PBX and voice infrastructure as the focal point for integrating the two technologies. In many respects, this made perfect sense, primarily because of the high reliability perceptions of the PBX and voice infrastructure.
This chapter explains why a PBX, despite its high reliability, is not a solution for convergence. It also examines what makes IPT different from earlier approaches to convergence, and discusses application development as the key to successful IPT deployment.
The PBX as a Convergence Platform
The PBX is arguably the most reliable technology mankind has created and so it seems a logical choice to use as the platform for integration. If you talk to most people, the perception they have is that although their mainframe might hiccup and their network might snooze every now and then, the telephone system is the one constant, the "old reliable." It doesn't break and it is always available. You pick up a phone, and you hear dial tone. It just works. So, with that in mind, in the 1980s, if you were going to bring voice and data together, the PBX, with its high reliability, was a natural starting point.
Figure 1-1 offers an accurate view of voice and data integration as it was implemented in 1986. For those users who chose this solution, a single drop of wiring to the desktop was sufficient to handle both voice and data sessions. Many manufacturers offered the capability to connect voice and data desktop devices to the PBX, and of course, Integrated Services Digital Network (ISDN) Basic Rate Interface (BRI)—the basic rate interface with two information channels and a signaling channel (2B+D)—gave the industry an attempt at a standards-based way of delivering voice and data services to the desktop.
)
Figure
1-1 PBX Voice/Data Integration in the Mid-1980s
In Figure 1-1, the PC attaches to the telephone by means of a data terminal interface. PBX manufacturers had different names for this device. It was often called a datacom module, or a voice-data integration module, among other things. Regardless of the terminology used, this unit had a single function: convert the asynchronous stream of data into a format suitable for transport within either a single or dual timeslot. This device was found on both the upstream and downstream links; that is, at the desktop and at the host or computer location. In this manner, data devices were connected to the PBX and used the PBX as a means of connecting to a host computer, and shared the same wire as the phone connected to the PBX, resulting in cost savings.
So, on the surface, it looks like there was a solution almost 20 years ago for the "voice and data" industry. The solution worked as advertised, in terms of functionality and ease of use. It certainly introduced new desktop devices to the industry—such as the Cypress voice/data workstation and Cedar voice/data PC offerings from ROLM—and in many cases, was a cost-effective alternative to hard-wired data devices. However, this approach did have some drawbacks:
It was contention-based.
It lacked industry standards.
PBX architecture provided insufficient connection rates.
Contention
The concept of pooling, or contention, was a key component of the PBX-based voice and data strategy. Contention-based connectivity was both a benefit and a detriment to the convergence strategy in the 1980s. A contention-based solution allowed companies to deploy fewer ports to the host computers than users. In other words, there could be potentially hundreds or thousands of users contending for a limited number of ports. If a port was not available, then users were not granted access to the host computer. This was often the case with PCs or asynchronous terminals running some type of 3270 emulation package for access to an IBM (or compatible) mainframe. It was not uncommon to see a protocol converter emulate an IBM 3270 cluster.
The protocol converter, as shown in Figure 1-2, while hard-wired to the host computer, allowed PBX-connected devices to "pool" or contend for incoming ports. When all ports were filled, the users either automatically rolled to ports associated with the next protocol converter defined to the PBX (if available) or received a busy tone.
)
Figure
1-2 A PBX Allowing Data Workstations to Contend for Limited Ports on a
Protocol Converter
In Figure 1-2, four asynchronous workstations (VT100, PCs in async mode) contend for two slots on a protocol converter. The protocol converter converts the asynchronous data stream into a suitable format, such as 3270 for IBM System 370 machines, for presentation to the host computer.
This approach had both benefits and drawbacks. The main benefit was that companies were able to deploy lower cost asynchronous terminals (typically VT-100 type) instead of the more expensive 3278/3279/3179 devices. For users with personal computers, using less expensive asynchronous emulation cards instead of expensive 3270 emulator cards helped lower the costs to the organization. Also, because contention did not provide dedicated ports for every user, fewer "cluster controllers" were needed (protocol converters in this case) for direct access to the host environment.
The drawbacks, however, outweighed the benefits for many organizations. Because the goal was cost savings, as previously noted, each user did not have a dedicated port. For those users who only occasionally needed access to the host computers, this was a fairly decent solution. Yet, for those users who were accustomed to having access whenever they needed it, getting a busy signal was totally unacceptable. Here was a case where the traditional telephony way of handling a scenario (giving a user a busy signal) was, for some data users, out of the question.
Lack of Industry Standards
Another problem data users encountered with the PBX was a lack of standards. In the data world, it was necessary to adhere to certain standards. When connecting to a host, the Information Systems (IS) staff had to decide what kind of terminal to emulate, or imitate. So it was common knowledge among IS and telecom people that they might have to emulate a 3270 environment, a 5250 environment, a VT-100 environment, or an HP or Data General or Wang environment, and there were packages that enabled each and any of these emulations.
Utilizing the PBX, however, consideration had to be given to the type of port connectivity for desktop and host devices. Because of the lack of standards, the devices manufactured by one company weren't necessarily the same as the devices manufactured by other companies. So the data terminal interfaces that each vendor used were different, and each data manufacturer had to test against each PBX manufacturer without the benefits of standards.
Insufficient Connection Rate
However, more than anything else, the real issue companies faced trying to satisfy their data users when integrating into the PBX was the connection rate (line speed). Users who previously were accustomed to host-connected, or channel speeds (often in the 1–2 Mbps range), were now throttled down between 64–128 kpbs, which was the maximum connection rate that a PBX allowed. The reason for this was that a PBX allocated bandwidth in the form of timeslots, and each timeslot was, by definition, 64 kbps. This was the standard connection for voice. By providing two timeslots, data users were allowed double that connectivity.
For the "casual user" (a term created by the industry), this was generally acceptable. However, many users resisted the term. "There's nothing casual about my work requirements," they reasoned, insisting that their connectivity, although not continuous, was just as important and urgent. In the end, the slower speeds (which meant users watching their screens get "painted" line by line) and the busy signals doomed this approach. Contention and low connect speeds doomed voice-data integration in the 1980s. IP telephony eliminates these obstacles to convergence. Certainly, if IPT is going to work, it has to address the issues that grounded the movement to a halt in the early 1980s.
The IPT Difference
During that fateful lunch with David and Richard, I kept wondering why IP telephony was so different. More than that, I wondered why two men that I knew and respected were so excited about it. The answer was brilliant in its simplicity. In their minds, the problem with the efforts to integrate voice and data in the 1980s and early 1990s was not technical, but a matter of focus. Instead of trying to squeeze bandwidth-intensive data into PBX timeslots, the better answer might be to place voice, which needs little bandwidth, into a data network where bandwidth is generally more accessible.
This change in focus provides the premise for the remainder of the issues discussed throughout this book: IP telephony, properly understood and deployed, can help organizations realize numerous benefits that they might not be considering today. At the center of these benefits are applications—new world applications—that transcend the traditional boundaries placed between voice and data environments.
Voice over IP
Voice over IP (VoIP) is exactly what it appears to be: deploying voice over an IP network. In its most basic form, VoIP means placing voice traffic onto the IP network for transport purposes only. Many people in the industry today who adopt this view of VoIP refer to the IP network as "plumbing"; i.e., the network is the plumbing (pipes) used to carry information (in this case, voice). Figure 1-3 shows an example of VoIP, according to this basic definition.
)
Figure
1-3 VoIP: Users from Two PBXs "Talk" Across the IP Network, Thus
Saving Long-Distance Charges
Figure 1-3 illustrates how an IP gateway (often referred to as an IP blade) that is added to the existing PBX gives those PBX users the ability to place calls over a company's IP network from location to location in order to reduce long-distance charges. Toll-bypass, as this is commonly referred to, is the most obvious benefit of this type of VoIP deployment.
In Figure 1-3, the IP gateway could easily be a single card that is installed/integrated into the PBX as are other cards on a PBX shelf. Furthermore, it could be a card within a data router that currently resides on a company's IP network. Either approach (integrated as a card in the PBX or a router) provides organizations with a cost-effective means for integrating gateways into their environments. For many companies, reducing long-distance charges has been the desired state, and upon accomplishing this task, they move on to other projects. In their minds, their VoIP project is completed.
The Telephone as Client
Many organizations, however, see VoIP as far more than this. More than simply using the network as transport (or plumbing), many organizations see value in not only placing voice "traffic" onto the IP network, but also in placing the actual voice "clients" (the telephones themselves) and new voice applications onto the IP network. This approach, although technically still VoIP, is commonly referred to as IP telephony; i.e., deploying a total telephony solution (including telephones, components, applications, and by extension, users) within the IP network.
In other words, IPT takes the premise of voice and data integration to its natural, albeit long-awaited conclusion: new voice clients (telephones, wireless devices, and desktop software) that, in their basic form, are designed to interface and interact with an IP network, obeying the rules of the IP network, utilizing its protocols, managed by its resources, and most importantly, accessing the myriad of applications that (can) exist on the network.
NOTE
Whereas VoIP places voice traffic on the IP network, IP telephony places voice clients, applications, and traffic on the IP network, thereby providing a different value proposition.
As shown in Figure 1-4, IP telephony allows phones to be directly connected to the IP network. A new type of phone, called an IP phone, is designed to interface directly to the Ethernet switch on the IP network, much like any other IP device, such as a PC, a laptop computer, or a network printer.
)
Figure
1-4 IP Phones Connect Directly to the IP Network
So, for the purpose of this book, VoIP is defined as technology that places voice traffic onto the IP network, whereas IP telephony is technology that places voice clients and voice applications as well as voice traffic onto the IP network. Each technology has a different goal, or desired state. The value proposition provided by IPT is very different than what was described previously for VoIP, primarily because the desired state for IP telephony is different.
The question most often asked by companies who investigate IP telephony is a simple one: Why should I put my telephones on the IP network? The simple answer is because managing one network instead of two (or more) is easier and more cost-effective, and that is where the majority of applications reside.
Unlike the traditional applications generally associated with voice, this new breed of applications is different. New applications are being developed quickly, with fewer resources, and at a lower cost. Instead of developing applications against a specific vendors' proprietary operating environment, IPT allows organizations to write applications using industry-standard (and widely used) data languages and protocols. In this new environment, just as data applications are written using Java, XML, HTML, Visual Basic or other similar tools, so too are new voice applications. Application development time is reduced from years and months to days and weeks. At Selsius Systems, we saw this trend develop in front of our eyes.
Application Development: The Real Potential of IPT
The greatest benefit to be realized from IPT is in product development. A complex voice-mail application can be written, tested, productized, and delivered to the market in a short time period because of the standards-based environment of IP telephony. The standards-based environment of IP provides protocols and programming languages that are known to a large body of developers, worldwide. This means expanding the pool of talent to create applications beyond the ranks of a manufacturer, and into the entire market of LAN and workstation developers. An example of this occurred at Selsius Systems in October of 1998.
This time, while in a meeting with David Tucker and Richard Platt, we were joined by Dave Corley, who headed up Product Management. The topic of discussion was voice mail; specifically, our own. Up to this point, Selsius Systems, as a wholly owned subsidiary of Intecom Systems, enjoyed a fairly positive relationship with its parent company. However, over time, many Intecom employees began viewing the upstart Selsius organization as competitors and as a drain on their own financial resources. The more than 60 Selsius employees had their own Selsius IP phones on their desktops, but still used the Digital Sound voice-mail system used by Intecom employees. So, in this meeting, we discussed the need to have our own voice-messaging solution to further reduce our dependence on Intecom telecommunications resources.
During this meeting, we discussed our specific voice-mail requirements with Paul Clark, one of the Selsius developers. We knew we wanted this to be a software solution, one that did not depend on hardware ports (channels), and we knew we wanted the solution to be linked to our Microsoft Exchange e-mail environment. Paul Clark was the lone engineer assigned to the project. Not only were we asking Paul to develop a messaging environment for the employees of Selsius Systems, but also a messaging environment for our group to bring to the emerging IPT market as well.
So, in October of 1998, Paul Clark walked out of the meeting with his assignment. Less than two months later, the application was up and running, providing the voice-mail features we required, and linking to our Outlook application so that we could access our voice messages within Outlook and directly from phones.
This was an important milestone for me, because a few years before, I had worked as a senior product marketing manager with VMX, the founding organization of voice mail. In that capacity, I had the opportunity to see many development projects in action. So the notion of putting requirements in the hands of a single development engineer and actually having a product, working and being delivered to clients less than eight weeks later was not lost on me.
Looking back, I can honestly say that was the defining moment for me. Watching a complex voice-mail application be written, tested, productized, and delivered to the market in such a short amount of time convinced me that IPT was going to open a new frontier of application development similar to what is now seen with data-based Internet environments. All of us knew, at that point, that the application potential for IPT could truly be realized.
Convergence: The Business Case for IPT
IP telephony is more than just reduced Moves, Adds, and Changes (MAC). It has become more than simplified or reduced cabling. It transcends reduced maintenance costs. All those are important, and they can help control costs. However, to truly appreciate the potential of IP telephony, telephones must be seen as new clients. Look past the handset and dialing pad, and envision a workstation running on the network and talking to applications—applications that are used to assist companies in running their day-to-day business operations. So the challenge facing businesses today as they look at IP telephony is to understand the technology in its capacity as a client. To do this, businesses need to ask key questions:
How will deploying IPT bring about change in the way I do business?
How will deploying IPT enable me to better control costs in my organization?
How will deploying IPT enable me to more easily achieve the business objectives and corporate initiatives my company has in place?
These three questions represent the fork in the road for companies investigating IP telephony. Asking these questions raises the stakes considerably by forcing businesses to consider the impact that IPT will have on the company's operations, and on its budgets.
The early attempts to integrate voice and data in the 1980s certainly provided productivity gains. They also provided cost savings through simplified wiring, sharing of resources, and a reduction in the cost of data workstations. Yet these integration attempts did so at a cost most organizations found too steep (in response time and availability of host resources, as previously noted.) The point of any technology, and IP telephony in particular, is to enable companies to achieve business results, to impact business processes. As Maurice Ficklin, IS Manager at the University of Arkansas Pine Bluff notes, technology should level the playing field between companies, regardless of size and/or scope.
In this respect, IP telephony fits the bill. From the small company to the large enterprise, IPT can truly positively impact business process—if that is the desired goal of the company. Companies are looking for new ways to generate revenue, to control costs, to satisfy their customers and employees, to drive productivity, and to competitively differentiate themselves.
How IP telephony impacts these key initiatives in your organization is up to you—and your vision of this technology. You will find that based on your paradigm (an often overused word, but applicable here), IPT is either a new telephone system, or a network-based business model designed to drive change and improvement in your business processes.
Throughout the remainder of this book, I will elaborate on this key point, as I discuss the benefits that entice companies to converge, as well as the potential obstacles to convergence.
Convergence as a Change Agent
Convergence will change many aspects of your organization. It will change how you deploy voice, data, and video solutions and also change how you view these technologies. Convergence will change how you manage these technologies in your environment, and how you organize yourself to take advantage of this new model. It will also change devices at the desktop, applications on the network, the expectations of reliability of the network, and the expectations that voice will have in your organization. In addition, it will facilitate change in the empowerment of desktop users when it comes to voice, and change how you cost-justify new technology solutions. Finally (and most importantly), convergence will bring about change in organizational responsibilities.
IP telephony might not be well received by the telecom engineer who sees the network engineer as somewhat of threat. Similarly, the network engineer might not be too enthusiastic about adapting to the different culture of supporting mission-critical voice communications. In the end, how comfortably your organization embraces change goes a long way in determining the success of an IPT deployment.
The best definition I have seen of convergence, as it relates to IP telephony, came from Cari c'deBaca, a product manager within the business unit at Cisco Systems responsible for their IPT solutions. "Convergence brings previously disparate networks together with the specific goal of impacting business in ways previously unimagined using applications previously not considered." Now, whereas this might sound like marketing fluff, in fact, it truly describes what I have witnessed in the past two years alone—new applications, developed by customers and third-party developers, that have redefined the role voice (and voice instruments) play in the enterprise.
Figure 1-5 is a screenshot of an actual application used at Cisco Systems in 2001. It was a Monday morning, just over a year after the Cisco Systems acquisition of Selsius Systems by which Cisco entered the IP telephony market. As employees of the business unit walked into their offices and cubes that morning, they saw this alert on their phones. This was an excellent way to let users know about the new voice-mail system, because it eliminated the need for lengthy print-out notices, e-mails, and training flyers—all which cost money. When users saw the notice, they were reminded of the new voice-mail system, and by depressing the "Details" soft button, they were given details on how to use the new system, thus eliminating expensive training program requirements. This is an example of new-world IPT applications in action, impacting business processes.
)
Figure
1-5 IP Telephony Application Reminds Users of a New Voice-Mail
System
NOTE
The true test of IP telephony is this: How has IP telephony changed the way your company conducts business?
The bottom line: Convergence is all about change, and your organization might put up a fight against convergence. There are factions within every organization that inherently fight against change.
The manager responsible for mission-critical operations has been known to resist IP telephony for fear of introducing the unknown into the equation. In reality, this person cannot be blamed for resisting change because he will be held responsible for up-time and ongoing availability. Asking him to embrace and implement a new technology, such as IP telephony, is somewhat far-fetched (especially considering the horror stories proliferated by many publications regarding IPT in recent years).
Equally, the telecom manager has been known to resist IP telephony for fear of the abrupt end to a career. After all, it will mean IP clients and IP applications running on an IP network, obeying the rules of the IP network, managed by IP management platforms. What is overlooked here is that although these are indeed IP clients and applications, they are also voice clients and applications. If nothing else, the last three to four years have shown that the role of the telecom department becomes even more critical with IP telephony. Yet, on the surface, it does not seem so.
The end users, who have seen the same telephone on their desktop for likely the last decade, may certainly resist a new instrument unless new capabilities are introduced at the same time. Asking employees to learn how to use a new phone, and potentially a new voice messaging solution, are not tasks that organizations take lightly.
Obstacles to Convergence
Additionally, technological obstacles might rear their heads against your convergence journey. I refer to these obstacles as "the usual suspects." They are predictable in nature and, with the proper planning, these issues can be anticipated and addressed easily:
How do you interface your new IP telephony deployment to your existing legacy PBX environment?
How do you retain full integration with voice mail, particularly message-waiting integration, if not all of your users migrate to IP telephony at the same time?
How do you ensure that your IP network has the capacity to handle new voice users and their applications?
When do you pilot the technology and, more importantly, what should be the purpose of a pilot?
Are your processes for supporting the IP network consistent with the level of support your users are accustomed to receiving with their PBX phones?
Have you identified all the features your users require?
Have you identified new business-changing applications? If so, who is going to create them?
Who supports the overall solution?
These are just a few of the questions that will be tackled in the following chapters. Rest assured, many of these issues are lurking in your organization. In fact, the one key that has been well proven in this industry is simply this: Don't rush into this technology without a plan. Develop a plan, execute the plan methodically, and avoid short-cuts. With proper planning and vision, the potential obstacles are easily overcome. Technology does not solve all problems. In fact, technology without a concrete blueprint for deployment can cause more problems than it solves.
Clearly, this sounds so obvious it almost should go without mention. Surprisingly, however, the majority of IP telephony installations that have had challenges were the results of poor planning rather than poor technology. Later chapters detail examples of this.
Issues to Ponder
If convergence is about change, how is an IP telephony deployment going to change the way you conduct business? Change is often viewed from a negative perspective, but what if IP telephony could introduce positive change into your organization? How can IPT change the profitability of a business unit? How can it enhance customer satisfaction? How can you open new models of revenue generation with this technology? Isn't it true that the reason organizations deploy new technologies is to drive new efficiencies, which lead to business impact in critical areas? More than anything else, that is the goal of IP telephony.
As an enabler to a change strategy in your organization, this technology can drive new business productivity, change your profitability model, enhance existing business processes_ or it can be a new telephone system. An organization's view of IPT will absolutely enhance, or limit, its impact on that organization.