Before Internet telephony broke out on its own, there was
Computer Telephony Integration (CTI). Without CTI, the Internet telephony industry would
still be just a dream. The long road from the earliest CTI links to mainframes to today's
current state of Internet telephony vendor interoperability was not an easy one. Nor have
we arrived at our destination yet. For those of you who are new to the Internet telephony
market, it is an interesting exercise to go over the evolution of an industry that
promises to change all facets of communications. LET US BEGIN AT THE BEGINNING
Telephony is defined as "communications at a distance." In a typical office,
telephony is transmitted over your business telephone system or PBX (Private Branch
eXchange). A related product is the ACD (Automatic Call Distributor). When you call a
large call center, the call hits the ACD and the ACD presents you with a list of questions
regarding your call. For example, you call a travel agency and have an option to press one
number for domestic travel and another for vacations and car rentals, etc. An ACD matches
your call with the representative most likely to have the experience to handle your call
by pre-assigning different skill sets to the various agents in the call center.
The First Links
Back in the early 1980s, Rockwell started to experiment with connecting the ACD to a
computer. At that time, large call centers typically had IBM mainframes and large ACDs.
The goal of connecting these two disparate systems was to enable the computer to examine
the telephone number of the caller when the call arrived. The number was looked up in a
database and a "screen pop" of customer information appeared on an agent's
screen as they took the call. The theory was that this would increase the productivity of
the agent and reduce 800 number call time, thus cutting costs. Staffing and telephone
costs are the biggest expenses in a call center. Thus was CTI born.
Several years later, IBM launched a product known as CallPath, to extend the
functionality of the CTI link. CallPath was designed to work with IBM's computers and
several large ACDs. At that time, the telephony industry did not really associate with the
computer industry. The fact that these two vastly different worlds could be bridged was
amazing. Technically, the challenge was minimal; psychologically, this was a new paradigm.
The down side was that once you had CTI links such as CallPath (or a competitive
product) configured in your call center, you were locked in to that vendor. If you
switched computer systems, you needed new CTI links. Your choice of PBX vendors was
limited to whichever vendors your CTI link supported. Furthermore, smaller call centers
were out of luck, as they could scarcely afford minicomputers, large PBX/ACDs, or the CTI
links.
TSAPI
In the early 1990s, AT&T (now Lucent) and Novell got together and developed TSAPI
(Telephony Services Application Programming Interface) allowing developers to write
programs for Novell NetWare servers to control PBX and ACD functions. This marked the
first time that CTI links could be implemented on a PC. The CTI barrier to entry dropped
from hundreds of thousand of dollars to tens of thousands of dollars. For the first time,
multiple computer makers could be chosen in a given CTI implementation.
Without Novell and AT&T's collaboration and the ensuing competition it set forth,
there might well be no CTI or Internet telephony market today. TSAPI allowed developers to
write programs on PC servers that used to require minis or mainframes. Furthermore, links
that were once limited to large and expensive PBXs could now be implemented on smaller
PBXs and even less expensive key systems from companies like Inter-Tel, Comdial, Tadiran,
and Panasonic. In theory, you could develop your product using TSAPI and your product
would supposedly work seamlessly with any other PBX that supported TSAPI.
Other APIs followed. Microsoft released TAPI (Telephony Services Application
Programming Interface) and Sun released its JTAPI (Java Telephony Services Application
Programming Interface).
As these telephony API links were becoming popular, small call centers began to harness
large call center features at a substantially reduced cost. For the first time, developers
had the tools to control multiple PBXs with a single computer program. Telephony APIs
allowed these developers to produce products that could run on a broader range of PBXs.
Costs dropped dramatically. Inexpensive CTI links also allowed developers to be more
creative.
As new products (e.g., unified messaging servers) were constantly being developed, the
CTI market grew from its call center roots to encompass any product that benefited from
the merging of the datacom and telecom realms.
In fact, over time, developers realized that they could do away with the external PBX
or ACD altogether. Loading a PC with computer telephony boards gave rise to a new animal -
the PC PBX. A PC PBX is inherently more flexible and easier to set up than a traditional
PBX. One reason is that vendors followed the traditional PC model, designing PBX
configuration screens and procedures to be more open, intuitive, and user friendly.
Internet Telephony Gateways
Most recently, the advent of the Internet telephony gateway has made it possible to
transmit voice and fax over IP (Internet Protocol) networks. These gateways allow service
providers and corporations to take advantage of the cost savings associated with Internet
telephony whether on a LAN, intranet, or extranet.
THE NEXT STAGE
We believe the future of all telephony is in Internet telephony - a term we use to
refer to telephony transmitted and received on a network adhering to the Internet Protocol
(IP). So, the next step is to combine the technology of the Internet telephony gateway
with the PC PBX and produce an Internet telephony-based PBX. Why stick with separate
telephone and data lines when voice can easily travel as data packets on your LAN/WAN?
It's high time for the single line to the desktop. It's also time for standards.
H.323
Many Internet telephony vendors have gotten behind H.323 as the standard to build gateways
and clients upon. It doesn't hurt that Intel and Microsoft are also behind this standard.
It is rare that an entire industry can agree on a common standard so quickly. So it seems
that from the start, vendors in the Internet telephony market decided that standards are
important to the success of the market as a whole. Many of these standards are still in
their embryonic stage, and so if you buy Internet telephony enabled telephones from one
vendor, they won't necessarily work with other vendors' Internet telephony based products.
Yet.
Furthermore, even if two Internet telephony clients support H.323, they won't
automatically work with each other. Let's face it, there are paper standards and there are
practical standards. Real standards usually gel when paper standards have been tested and
proven in the real world. Still, vendors should be commended for the work they are doing
to ensure the future of a standards-based industry. These vendors realize the important
role of standards in avoiding market fragmentation. Standards will allow all products to
share common low-level development tools, allowing rapid development of new applications.
Interoperability
The potential of gateway interoperability to open up a whole new area of the market is
great. In order for two disparate gateways to work together, they must communicate with
each other using some agreed upon standard (i.e., H.323). Often, the need for
interoperability is not dictated by corporate requirements, but by the needs of service
providers.
Service providers will often want to terminate calls outside their own network. If a
service provider wants to be successful in the long run, he can't limit his customers to
calling global areas where he happens to have a gateway. And, if a service provider
decides to terminate their calls on another service provider's network, they can't ask
that service provider to replace all of their gateways with ones from a common
manufacturer. In order for Internet telephony to be viable for service providers, they
must have full interoperability between these disparate gateways.
Garden State Get-Together
Recently, ITXC, an Internet telephony
exchange carrier, requested that two of their Internet telephony gateway suppliers --
VocalTec and Lucent -- collaborate to make sure that their two
gateways work together.
While CTI has helped open up the traditional telephony market, the thought of asking
two major PBX manufacturers to make phones or other lucrative components that interoperate
is at best a long shot. I don't want to seem too harsh on PBX manufacturers since they are
unanimously pledging open systems, but they still treasure their proprietary components,
and frankly, few have been very quick to open up these highly profitable parts of their
businesses.
Speaking With
I recently had a chance to speak with Lior Haramaty, Co-Founder and VP of Technical
Marketing at VocalTec, about the issue of interoperability and, more specifically, the
request from ITXC. Lior tells me that although many standards do exist (such as H.323),
getting them to work in the real world is often more complicated than conforming to a
written standard.
Unlike interoperability of client Internet telephony products where both the sender and
receiver must be able to encode and decode voice and video packets, gateway
interoperability is much more complicated. This is especially true in service provider
environments where a clearinghouse scheme needs to be implemented for accurate billing.
Gatekeepers
Gatekeepers are a key component in service provider environments, responsible for making
sure Internet telephony calls are handled correctly. VocalTec uses a combination of a
gatekeeper and Network Manager to achieve successful Internet telephony service provider
implementations.
Since the definition of a gatekeeper varies widely, I will use VocalTec's gatekeeper as
my example. Their gatekeeper directs traffic over hybrid traditional telephone networks
and IP telephony networks (both public and private) performing essential intelligent
routing, billing, and security functions. In a global Internet telephony network with
thousands of gateways and millions of users worldwide, VocalTec's gatekeeper could approve
a customer's account for calls from Paris to Los Angeles, ensure proper billing, and find
the least expensive route for the call, as well as an alternative path if that route was
unavailable.
The gatekeeper performs service authorization and subscriber authentication functions
and eliminates the possibility of a single point of failure within the network through
redundancy and scalability. VocalTec's gatekeeper is also the primary interface between
gateways and other IP telephony applications, including third-party credit and prepaid
calling card billing systems, accounting, and security solutions.
The gatekeeper handles many of the Intelligent Network (IN) functions of the
traditional telephony market. It can also handle complex decision schemes based on
numerous factors such as time of day and calling party information. Furthermore,
gatekeepers allow multipoint conferencing and collaborative computing. Finally, a
gatekeeper can allow multiple devices on the network to have the same address or
identification number and can coordinate between them all.
You can imagine what is involved in a project requiring two competitors to open up the
inner workings of their gateways and gatekeepers to each other. The gatekeepers, while
required to work together, have to be configured to provide limited information to
gatekeepers on other service provider networks. For example, if you tried to place a video
call to someone on another service provider's network, your gatekeeper would contact the
remote gatekeeper to make sure that the remote user was able to take a video call.
Furthermore, the remote gatekeeper has to pass back information relating to the called
party's ability to take a call at that moment.
Gatekeepers also have to limit how much information they pass back to the originating
gatekeeper. The reasoning here is that service providers consider information about users
on their network confidential, and would not be happy about sharing these intimate
customer details with other service providers.
CONCLUSION
I commend both Lucent and VocalTec for getting together and working on standards. The
maturity level demonstrated by these two companies working together is highly promising.
Two companies putting their own self interests aside to further the Internet telephony
industry is a very positive statement about this market. Beyond two industry leaders
demonstrating the importance of interoperability, ITXC's involvement signals a new type of
Internet telephony service provider - one that understands that the success of this
industry depends on standards-based vendor interoperability.
Just as CTI standards opened up the corporate communications market, Internet telephony
and its associated standards will open up telecommunications at all levels from the
service provider network to the enterprise to the SOHO environment.
|