Thursday, December 13, 2007

Introduction to IP Telephony

IP telephony is a term used to describe a suite of products and solutions used to
transport voice traffic over a data network. Utilizing Internet Protocol (IP) as a
transport mechanism, IP telephony allows you to create a converged network in
which all communications (voice, video, or data) share the same infrastructure.There are numerous benefits to this type of infrastructure, including simplified
administration, cost savings on telecommunications fees, and unified messaging
services.
Simplifying Administration
Almost every mid- to large-sized corporation has a large data infrastructure and
along with it, they probably have a large infrastructure built for voice-based
traffic.These networks, while both crucial to the organization, share no common
thread. Although they may share the same cabling, and even in some cases the
same protocols (such as IP), they are still very different types of infrastructures.
Two different groups within the corporation administer them, they utilize the
equipment of different vendors, both require separate leased lines or plain old
telephone service (POTS) lines, and funding for both probably come from different
budgets.With the IP telephony solution, these two infrastructures are collapsed
into one IP-based network, allowing all communications to share the same
administration, ultimately saving time and money for the corporation.
As we discussed earlier, an organization typically has two groups, a voice group
and a network group. Under the old world telephony solutions, these two groups
perform very different functions, and in a figurative sense, almost speak different
languages.With the IP telephony solution, these groups are collapsed into a single
resource pool.Voice and data, while still very different types of traffic, are administered
by the same group. Customer service and satisfaction will also benefit
from this type of infrastructure. Instead of an end-user having to call the network
group for one problem and the voice group for another, the user has a single
point of contact for their communication needs.
Utilizing Toll Bypass
One of IP telephony’s key features is also one of its most enticing benefits, a feature
known as toll bypass.Toll bypass allows an organization to utilize its existing
data infrastructure to make calls within the organization. Imagine a multinational
organization with branch offices spread throughout the world. In the old-world
solution, any time one office placed a call to another, the telephone systems of
each office would employ the services of telecommunications service providers to
place a call within their own organization. If you have ever traveled, you may
have experienced the sting of how expensive international calls can be. I placed a
call on a business trip from a branch office in Moscow to their headquarters in
Cleveland; the call lasted around 40 minutes, and the bill turned out to be $300.00.So you can imagine how expensive international telecommunications must be for
the day-to-day operations of a multinational organization. Now imagine that
same scenario using IP telephony, placing that same call from the branch office in
Moscow to headquarters in Cleveland, this time utilizing the IP telephony solution.
Instead of utilizing the telephone company’s services and infrastructure, you
would employ the existing leased data lines between the two sites. Now the only
price you are incurring is the fixed price you pay each month for the leased line
that was already there. As I am sure you can see, IP telephony has the potential to
save an organization a great deal of money.
Linking Communications
with Unified Messaging
Unified messaging is both one of the goals and benefits of a truly converged network.
It links an end-user’s voice-mail, e-mail, and fax solutions so they are
essentially one entity.With IP telephony, a user could listen to his e-mail, review
his voice-mail via software on his PC, review e-mail or listen to voice messages
on an IP telephone. Cisco, as well as other vendors, have, and are, developing software
applications to utilize unified messaging.We will discuss some of these solutions
in the sections to come.
Choosing to Implement IP Telephony
IP telephony sounds great, right? Shouldn’t every organization have implemented
it by now? Well, first of all, you should keep in mind that voice traffic and regular
IP data traffic are two completely different solutions. Regular Transmission
Control Protocol/IP (TCP/IP) data traffic is very resilient. It can be forgiving of
slow wide area network (WAN) links, lost packets, and the reception of packets
out of sequence. In fact,TCP/IP operates in just that way, taking data and segmenting
it into several packets and transmitting the data via the best possible path.
It is not concerned with the order in which the data is received, or the path it
takes to get there, because the end device is responsible for the reassembly and
resegmentation of the data.Voice traffic, on the other hand, is not so forgiving, nor
as resilient. Even though the voice traffic is being converted to IP packets, it is still
voice traffic. IP telephony depends on packets being received in the same order in
which they were sent; if a packet is lost, then it should remain lost, as retransmitting
the packet would only confuse the person on the receiving end of the call. In
order to accomplish this, you must incorporate several new features on your
routers and switches, such as Queuing and Real-Time Transport Protocol (RTP).In fact, in order to make IP telephony a reality, your infrastructure is going to
need quite a few enhancements.There are several components that must be
added to your infrastructure.These components include, but are not limited to,
specialized router interfaces, specialized local area network (LAN) switch modules
and interfaces, IP telephone handsets, Cisco CallManager servers, and Cisco
Unity Mail, as well as other unified messaging solutions. In addition to the
required hardware, there are several applications that will also help you to realize
the benefits of IP telephony. Applications such as Cisco’s WebAttendant,
AutoAttendant, and Personal Assistant, as well as third-party software should also
be incorporated into your IP telephony solution.
IP Telephony Components
The components that must be added to your infrastructure in order to facilitate IP
telephony are what really blur the line between the traditional voice infrastructure
and your data infrastructure. Here we cross a line into a new realm of
devices—but are they voice or are they network? The answer, of course, is that
they are both. I think an important point to remember when considering a converged
infrastructure is that no matter what we are dealing with, voice, video, or
data, it is all communications.This is the information needed for the end-user to
effectively carry out his or her business. Perhaps we should begin to consider
ourselves communications engineers as opposed to using the traditional network
engineer or voice systems administrator titles that have helped to separate the different
disciplines for decades. In this section, we will discuss some of these components
and their features.
Cisco CallManager
Cisco CallManager provides the IP telephony solution with a software-based call
processing platform to fill the role of a traditional PBX. CallManager represents
one of the first large-scale enterprise solutions to answer the challenge of IP telephony.
As an aside, IP telephony is by no means a new idea. Several companies
have introduced VoIP solutions. For example, several Internet Chat programs such
as Microsoft NetMeeting,America Online (AOL) Instant Messenger, and Yahoo!
Messenger offer the ability to communicate via voice by utilizing the Internet or
other network as a medium.While fun to play with, however, it is difficult to
imagine an organization utilizing them for an enterprise-wide IP telephony solution,
because solutions such as these are essentially entertainment software, and
provide for no hierarchy or reliability.
Cisco’s CallManager offers a scalable, reliable, and manageable solution for an
organization of almost any size and demographic.While it may not be the ultimate
choice for IP telephony, it has set a standard of performance for IP telephony
call processing, and will probably continue to do so for the foreseeable
future. In this section, we will further discuss the CallManager platform, its architecture,
hardware, benefits, and limitations.
The CallManager Platform
CallManager is probably the most integral part of Cisco’s IP telephony solution.
It provides the rest of the IP telephony architecture with a central point for call
processing, connection services, signaling, and registration for IP telephone handsets,
analog and digital gateways, and legacy telephony devices such as PBX systems.
Communication with IP telephony devices is enabled by the use of several
IP telephony protocols such as Skinny Station Protocol (SSP), H.323, Media
Gateway Control Protocol (MGCP), and Simplified Message Desk Interface
(SMDI).These protocols will be discussed in more detail later in the chapter.
CallManager offers an open programming interface utilizing the Telephony
Application Programming Interface (TAPI) and the Java Telephony Application
Programming Interface (JTAPI). By utilizing industry standard protocols, Cisco
has opened the door for several other software vendors to further augment the IP
telephony product offering. Some of these applications will be discussed later in
this chapter as well as in Chapter 7.
Current releases of the CallManager platform allow a single CallManager
server to support up to 2500 IP telephone/5000 IP telephony devices per individual
server. An IP device can be any of the following:
 IP telephone
 Analog or digital gateway
 IP SoftPhone
 Digital signal processor (DSP)
CallManager has gone through two major revisions.The first revision of the
CallManager Platform was the 2.x release of the platform.This revision has been
discontinued, and CallManager 3.x is the current standard, which we will discuss
in the sections to follow.
IP Telephony Protocols
In the previous section, we introduced several protocols that CallManager uses to
communicate with IP telephony devices.As we discussed in the introduction to
this chapter, Cisco is attempting to create an open ecosystem of partners and solutions,
with the end goal being to let the organizations decide which product or service
best suits them. Supporting several different IP telephony protocols is an
important step in this process. It would have been much easier for the Cisco
product development team to only support one set of protocols when designing
their IP telephony solutions, but by supporting several, they have opened the door
to numerous vendors to work within the AVVID framework. Discussed in the next
sections, are some of the most common protocols that CallManager can use to
communicate.This is by no means a definitive list of all the protocols CallManager
will support.As new versions of CallManager become available, the number of supported
protocols will also grow.As always, it is a good idea to consult the Cisco
Web site for the most up-to-date information regarding this support.
Skinny Station Protocol
Skinny Station Protocol (SSP) is a Cisco communications protocol based on the
industry standard Simple Gateway Control Protocol (SGCP) protocol. SSP was
first introduced as a method of communication between first generation IP telephone
handsets/Gateways (DT-24+/DE-30+) and CallManager servers, and is
still widely used today for that same purpose. Products that support SSP include
the DT-24 and DE-30 gateways, the Catalyst 6000 8-Port T1/E1 voice service
modules, as well as the Catalyst 6000 24 port FXS module. SSP relies on the
CallManager server to relay configuration and control information. It is built on
TCP/IP and utilizes TCP ports 2000–2002.
H.323
H.323 is an industry-wide open standard for real-time audio, video, and data over
packet networks. H.323 is an International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) standard and is part of the
H.32x family of protocols. H.320, transmissions over Integrated Services Digital
Network (ISDN), were discussed in Chapter 1. H.323 was built upon this protocol,
allowing video and audio transmissions to be supported over packet-based
networks such as Ethernet. Cisco’s IP telephony architecture can use H.323 to
communicate with IP phones, gateways, and, because it is an open protocol, it
can be used to communicate with dissimilar systems such as PBXs and other
vendors’ equipment. H.323 gateways will be discussed later in this chapter.
Media Gateway Control Protocol
Media Gateway Control Protocol (MGCP) is another Cisco-supported protocol.
The CallManager server uses MGCP to communicate with the Cisco VG200
standalone gateway, although several other products in the Cisco product line,
including certain products in the Catalyst switching line, will support it soon.
MGCP is intended to serve as a faster protocol than H.323 and SSP, utilizing
User Datagram Protocol (UDP) as opposed to TCP for transmission. MGCP
gateways will be discussed later in this chapter.
Simplified Messaging Desk Interface
Simplified Messaging Desk Interface (SMDI) is the industry standard voice-mail
protocol for integrating voice-mail systems with legacy PBX systems and/or
other similar devices. CallManager and other unified messaging platforms can use
it to integrate with legacy voice-mail systems.
CallManager 3.x
CallManager is currently in release version 3.1.The CallManager 3.x release
introduces several enhancements over the previous 2.x version of the software.
Version 3.x is built on the Microsoft Windows 2000 Operating system, whereas
version 2.x was built on Windows NT 4.0.Version 3.x utilizes a Microsoft SQL
server database for data warehousing, while previous versions of CallManager utilized
a Microsoft Access database, which severely limited the scalability and reliability
of the platform.An important note to make, though, is that CallManager
still fails to support other database systems such as Oracle.
CallManager 3.x allows up to 2500 IP telephones to be supported by a single
CallManager server, up from CallManager 2.x’s limit of 200 IP telephones per
server. Another enhancement the 3.x version of CallManager offers is increased
reliability and scalability by use of a feature known as clustering. Clustering allows
multiple CallManager servers to be interconnected, in order to service more IP
telephony devices and to provide redundancy.
Clustering
Clustering will allow you to extend your support for IP devices from 2500 IP
telephones on an individual CallManager server, up to a potential 10,000 IP
telephones within a single cluster. Clustering, as its name implies, is the process of
combining two or more CallManager servers into a logical unit known as a
group.A group consists of CallManager servers and their associated devices such as
IP telephones, gateways, and logical devices such as SoftPhones, a software-based
version of the IP telephone handset. (IP SoftPhones will be discussed further in
the IP telephony applications section to follow.) When the group concept is utilized,
all the CallManager servers share the same configuration database, so if one
CallManager server fails, the others already have the database, thus no manual
reconfiguration is required.The idea behind clustering has to do with providing
enough servers so that if one of them should fail, the other servers within the
cluster can take on the load of the failed server without compromising the level
of service to the end systems.
Cisco has outlined four primary roles a server can take on in the cluster:
 Primary CallManager server
 Backup CallManager server
 Database publisher server
 Trivial File Transfer Protocol (TFTP) server
The primary and backup CallManager servers are self-explanatory.The
database publisher server role is to maintain and distribute the master-configuration
database.A second but equally important task is the record warehousing of
call detail records (CDRs). A CDR is a record of the IP telephony call.This can
be used by other vendors’ software for traffic analysis and additional accounting
functions.The TFTP server role is used to provide the system image for devices
such as IP telephones and gateways.
How you structure your cluster is dependant on how many IP telephony
devices will be supported. Cisco has set the following design guidelines for
building your CallManager cluster. If you have fewer than 2500 IP telephones,
you will need two servers, one primary CallManager server, and one backup
CallManager/publisher/TFTP server. For 2500 IP phones, you will need three
servers, a primary CallManager server, a backup CallManager server, and a combined
Publisher/TFTP server. For 5000 IP phones, you will need four servers,
two primary CallManager servers, one backup CallManager server, and a combined
Publisher/TFTP server. For the maximum 10,000 IP telephones per
cluster, you will need four primary CallManager servers, two backup
CallManager servers, one database publisher server, and one TFTP server.
As we discussed in the introduction to this section, there are some limitations
you must take into consideration before implementing a cluster. An important
item to take into consideration is that a cluster cannot cross a WAN link. All
cluster servers must exist on the same LAN. Furthermore, the servers must be
interconnected at minimum by a 10 Mbps switched connection. Shared media is
not allowed in an AVVID cluster.This is to ensure the proper Quality of Service
(QoS) is maintained. Also, as stated earlier, a cluster is limited to 10,000 IP telephones.
A maximum of 100 clusters can be interconnected, allowing support for
up to 1,000,000 IP telephones within an organization. Figures 2.1 and 2.2
demonstrate clustering and failover protection.
As you can see, clustering gives you a great deal of scalability within your IP
telephony network. Making IP telephony a viable solution for organizations
ranging from the smallest companies to the largest multinational organizations.
Chapter 4 will cover this topic in more depth.
CallManager Hardware
Although CallManager is a software-based application, it must be purchased as
part of the Cisco Media Convergence Server (MCS).The MCS servers are
Compaq server-class systems.There are several different models of the servers; all
essentially perform the same functions—the only real differences are the hardware
features, such as hard drive space, processor speed, and memory capacity.As with
all other servers in your network, you should purchase the MCS that best fits
your organization’s needs. Consult the Cisco Web site (www.cisco.com) for the
most up-to-date MCS server information.There is, of course, an exception to the
rule of only being able to purchase CallManager preloaded on an MCS server
platform. If you have already purchased a Compaq DL320 or DL380 server,
meeting specific system requirements as outlined by Cisco, you can purchase a
software-only version of the CallManager Software.
Recently, Cisco announced that the MCS platform will be available on the
IBM xSeries of servers as well as Compaq servers.This series of servers will
follow the same rules that applied to the Compaq servers, in that the MCS must
be purchased pre-configured.The initial product offering of the MCS platform
on the IBM xSeries of servers will be on the xSeries 330 and 340 platforms. I
would expect that this group will grow to include other servers in both the IBM
and Compaq server lines.

No comments: