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.