As we noted for both IP telephony and IP-based video-conferencing, creating an
AVVID-enabled network requires a great deal of new equipment. Depending on
the needs of the network in question you will most likely be adding devices such
as CallManager servers, IP telephones,WebAttendant consoles, video gateways,
gatekeepers, MCUs,VTAs, and endpoints. All of these devices (and more) are very
necessary to make AVVID a reality for your network. In fact, they require even
more additions. Several enhancements also need to be made to your existing
infrastructure, such as specialized router interfaces and specialized switch cards. As
we discussed before, we must blur the line between our voice and data networks.
Here at Layer 2 (the access layer) of the Open Systems Interconnection (OSI)
model and Layer 3 (the network layer), where data has always reigned as the
proverbial king, we must now make our infrastructure voice and data friendly—a
shared kingdom of sorts. Previously, we’ve focused on the upper layers; now we’ll
discuss the Layer 2 and Layer 3 devices that will make our new type of network
a reality.
Using Routers for a Converged Network
As we all know, a router is a Layer 3 device, the primary purpose of which is
path determination and packet switching based on IP or other Layer 3 addresses.
When we introduce a converged network, routers are going to have to be one of
the first places we begin to make enhancements. Cisco has developed several
routers that allow a network to make the change to a converged network. Several
new types of interfaces have emerged, utilizing the modular chassis capabilities of
Cisco’s newer routers. Now both voice and video interfaces are available for these
routers. In the sections that follow, we will discuss these interfaces and the routers
that support them.
Analog Voice Interfaces
Cisco routers utilize analog voice interfaces to interface either directly with telephone
handsets, or to connect to legacy PBX or the PSTN. Because analog technology
is considered a much older and more stable technology, these interfaces
are standardized.There are currently three types of analog interfaces supported by
Cisco routers: Foreign Exchange Station (FXS), Foreign Exchange Office (FXO),
and ear-and-mouth, sometimes known as earth and magneto (E&M). Let’s discuss
these interfaces in more detail.
Foreign Exchange Station
Foreign Exchange Station (FXS) ports use a standard RJ-11 telephone jack to
connect to telephone handsets, modems, or fax machines.This is the common
type of interface found in homes. Cisco routers would most likely use this interface
for phone-to-phone connectivity.
Foreign Exchange Office
Foreign Exchange Office (FXO) ports also utilize a standard RJ-11 telephone
jack. FXS ports are commonly used by businesses to connect their legacy PBX
systems to the service provider’s telephone network. Cisco routers can use an
FXO port to connect to a legacy PBX device or to directly connect to the
PSTN.
Ear-and-Mouth
Ear-and-mouth (E&M) offers a more advanced solution than either the FXO or
FXS ports, as well as several features that the other two do not, such as trunking
and either analog or digital transmission. E&M utilizes an RJ-48 port as opposed
to the RJ-11 used by the others. Cisco routers would most likely use an E&M
port for connection to PBX or PSTN, as well as a connection requiring
trunking.
Digital Voice Interfaces
Digital voice interfaces are provided to Cisco routers by use of digital voice
trunking cards and Digital Voice Processor (DVP) voice compression modules
(VCMs). Digital voice trunking cards interface most commonly with ISDN BRI
and PRI lines. By utilizing the individual channels on each line, it allows for a
single line to support two voice lines using BRI and up to 23 lines using PRI in
the U.S., and up to 30 in Europe. Digital voice processor VCMs allow a router to
take a voice conversation and compress it down to as small as 5.3 Kbps,
depending on the method utilized, as opposed to a 56 Kbps channel.This allows
for a much greater utilization of available bandwidth.
MC 3810 Router
The Multi-Service Access Concentrator 3810 (MC 3810) represents the first
router of its type, offering the full capabilities of a router as well as Voice over
Frame Relay,ATM, and leased lines. It was designed to be an all-inclusive solution
for branch-office deployments. A major disadvantage of the MC 3810 is that
it is expensive and the network modules used in it are not interchangeable with
any other platforms.This is no longer a very popular platform due to the VoIP
capabilities of routers such as the 2600 and 3600.
1750 Multi-Service Series Routers
The 1700 Series of routers provide a small office solution for organizations. As a
member of the 1700 Series family, the 1750 multiservice router series also offers
an IP telephony solution, two analog voice channels, a DSP, and three network
interface module slots for additional voice/data support.The 1750 can share the
same WAN and voice interface cards as the 2600 Series.This router would most
likely serve the small and home office market, due to its small capacity and limited
features—it would not be adequate in the larger branch office role.
2600 Series Routers
The 2600 Series of Cisco’s routers has become one of the most popular connectivity
solutions for branch office connectivity. It offers a modular design, sharing
network modules with the 1600, 1700, and 3600 Series of routers, providing two
WAN interface card (WIC) connections as well as one network module slot.The
2600 router supports 10 Mbps and 100 Mbps Ethernet interfaces as well as token
ring.The 2600 supports VoIP applications and support for up to 48 digital voice
lines (60 in Europe).Voice interface cards (VICs) allow the 2600 Series to support
analog voice interfaces. By using two VIC cards in the WIC card slots, the 2600
can support up to four analog lines.
3600 Series Routers
The 3600 Series bears many resemblances to the 2600 Series, but the 3600 Series is
quite a bit more powerful, offering a great deal more scalability and processing
functions.There are three classes in the 3600 Series: the 3620, 3640, and 3660.The
3620 provides two expansion module slots, the 3640 offers four, and the 3660
offers six.Whereas the 2600 supports the use of WICs, the 3600 Series supports the
use of carrier cards that provide service for WAN, LAN, and voice interfaces; these
cards are interchangeable with the 2600 and 1750 Series routers. LAN support for
the 3600 supports 10 and 100 Mbps Ethernet, as well as token ring.
7200 Series Routers
The 7200 Series is Cisco’s first-level enterprise router. It offers a four- or six-slot
configuration with interfaces including ATM, Synchronous Optical Network
Technologies (SONET), ISDN BRI, ISDN PRI,T1, E1,T3, and E3. It also supports
AVVID applications through use of the multiservice interchange (MIX)
functionality.The MIX allows the 7200 to support digital voice as well as
gateway functionality through the use of two different trunk interfaces, the highcapacity
and medium-capacity T1/E1 trunk interface cards.The primary difference
between the two cards is that the high-capacity card includes an on-board
DSP card for compression.The 7200 Series can support up to 120 voice calls
depending on the module configuration used.This router also supports analog
voice applications through the use of voice interface cards (VICs).
Cisco Switches
Cisco’s Catalyst switch line is a highly-advanced line of switching solutions that
scale to meet various business needs, from small organizations to multinational
corporations. Catalyst switches operate at Layer 2, but Layer 3 switching is also
possible with a Route Switch Module (RSM). All of the switches in the Catalyst
line support AVVID networks, including IP phones, but specific switches within
the product line are designed specifically to meet the needs of IP telephony,
specifically inline power, which we will discuss in the next section, and gateway
functionality.We will discuss three lines that meet this challenge: the 3500, 4000,
and 6000 Series.
3500 Series Switches
The 3500 Series is a scalable, entry-level solution for small- to mid-sized networks.
It is a wholly Cisco-developed switch, which runs a router-like IOS.The
3500 Series of switches are fixed configuration switches, all offering 10/100
Ethernet ports and Gigabit Interface Converter (GBIC) ports.The difference
comes in the number of ports offered and the forwarding rate at which the
switch can process packets. Currently the 3524XL-PWR is the only switch in
the 3500 Series that supports inline power, although other models within the
35xx product line will, in the future, most likely offer inline power as well.The
3524XL-PWR offers 24 10/100 Ethernet ports, 2 GBIC ports, and a packetforwarding
rate of 6.5 million packets per second.
4000 Series Switches
The 4000 Series is a step up from the 3500, offering a modular configuration in
four different switches: the 4003, 4006, 4840G, and 4908G.The 4000 Series also
offers supervisor engine functionality, similar to that of the 5500 Series.Within
the 4000 Series, the 4006 is currently the only switch to offer inline power; by
use of the Catalyst 4000 inline power 10/100BaseT switching module or the use
of an auxiliary power shelf, the 4006 supports up to 240 10/100 ports.The 4003
is also an Ethernet switch, very similar to the 4006, but unfortunately the 4003
cannot offer inline power functionality.The 4840G and 4908G are both gigabit
Ethernet switches.The 4000 Series also offers voice-gateway functionality
through the use of the Series 4000 WS-X4604-GWY module, which provides
support for both H.323 and SSP (in the future it will support MGCP).
6000 Series Switches
The 6000 Series is a highly scalable, enterprise class series of switches.The 6000
Series offers a completely modular design, utilizing supervisor modules, with the
capability for redundant supervisor modules, if necessary.There are five switches
in the 6000 Series family: the 6006, 6009, 6506, 6509, and 6513.The 6006 and
6506 offer six slots while the 6009 and 6509 offer nine slots.The 6513 is the
largest form-factor in the product line, offering 13 slots.The 6000 Series provides
inline power directly through the use of specialized 48-port switching blades.The
6006 and 6506 can support up to 240 10/100 ports, while the 6009 and 6509
can support up to 384 10/100 ports, and the 6513 can support up to 576 10/100
ports. Gateway functionality is provided via the WS-X6608-x1 module.This
module supports SSP and will in the future support MGCP.The 6000 Series also
offers an eight-port voice T1/E1 and services module to provide connectivity to
legacy PSTN or PBX systems, as well as a 24-port FXS module for analog telephone
connectivity.
Exploring Inline Power Options
During our discussion earlier in this chapter concerning IP telephones, we discussed
how second-generation phones were superior to their first-generation
counterparts because they offered support for inline power. First-generation telephones
were limited in that they required an external power source in order to
function. Inline power allows second-generation phones to avoid this pitfall.
There are two ways in which inline power can be offered to second-generation
telephones, either by way of a power patch panel, or through the use of inline
power modules installed directly in the switch. Let’s discuss these different power
options as well as their advantages and disadvantages.
Inline Power Modules
Inline power is currently available for three switches in the Catalyst product line:
the 3524XL-PWR, the 4000 Series, and the 6000 Series.The 3524XL-PWR is a
fixed-configuration 24-port switch. It provides out-of-the-box inline power support.
An important note to make is that the 3524XL-PWR switch offers no
inline power redundancy.
The 4000 Series provides inline power through use of the Catalyst 4000
Inline power 10/100BaseT Switching module and the Power Entry Module
(PEM). Redundancy is provided to the 4006 by use of the WS-P4603 auxiliary
DC power shelf.This allows for an N+1 protection scheme protecting against a
single power supply failure. An important note to make is that the 4003 cannot
interface with the power entry module and therefore cannot utilize inline power
directly from the switch. In order for the 4003 to provide inline power, you must
use the Catalyst inline power patch panel.
The 6000 Series provides inline power by use of a 48-port switching blade.
Inline power is provided to the switch via 2500-watt power supply.Two power
supplies can be used for redundancy. Inline power modules offer a great solution
in environments where space is at a premium.
Because all of the functions are collapsed into one piece of equipment,
administration is simplified. On the down side, this solution may require a forklift
upgrade, as inline power modules are only available for the 3500, 4000, and 6000
Series, which could introduce a great deal of added expense. Even though powerredundancy
is available for these switches, you are still relying on a single point of
failure should the entire switch fail.
Power Patch Panel
The Catalyst inline power patch panel offers an alternative to the forklift upgrade
that might be necessary in order to accommodate inline power.This solution
allows you to utilize your existing switching infrastructure, such as 2900 and 5000
Series Catalyst switches, by providing inline power external to the switch.The
Catalyst inline power patch panel offers 96 ports, for support of up to 48 stations
per panel, one port for the IP telephone and one port for the switch.The major
advantage to this solution is that it helps to protect your existing investment in
switches and helps to keep your options open to future product offerings.The
major disadvantage is that you now have an additional piece of equipment in
order to administer.
Power Cube
Power cubes are an external power supply, used as a sole means of power for the
first-generation telephone offerings. Power cubes can be used by second-generation
telephones as a sole means of power, or more commonly, can be used as a
backup power supply to the inline power patch panel and the inline power modules.
The advantage to this solution is that, when used with inline power, it provides
a redundant power supply for your IP telephone.When used solely as a
means of power, its advantage is that you can deploy IP telephones and not have
to replace your switches or install inline power patch panels for power.The major
disadvantage is that you must provide a power outlet for each cube, and it adds to
the mass of cables around a user’s desk.
Different Queuing for Video/Voice
Queuing is an important design and performance issue that must also be examined
when discussing IP telephony. Queuing has traditionally been a Layer 3
function for WAN connections, but when discussing a converged network, specifically
that dealing with voice or video traffic, attention must also be given to the
LAN. Layer 2 traffic can be classified by type of service using the 802.1Q protocol.
It is recommended that when using this protocol you separate voice and
video traffic from regular data traffic and place this traffic in a higher-priority
queue. 802.1Q specifies seven classes of service (COS), 0 being lowest priority
and 7 being of the highest priority. It is recommended that COS 4–7 be used for
voice and video, and that 0–3 be used for normal data operations. An important
note to make regarding Layer 2 queuing is that once the packet encounters a
router, the Layer 2 information is lost—in other words, 802.1Q is only a LAN
solution. For traffic crossing WAN links, Layer 3 queuing must be incorporated.
Thursday, December 13, 2007
Cisco IP Phones
Cisco IP telephones provide the end-user with an interface into the IP telephony
architecture.There have been two generations of IP telephones produced by
Cisco: first-generation and second-generation.
Cisco’s first-generation IP telephones came with the acquisition of Selsius
Technologies.These telephones are now discontinued.There were two models of
the first-generation telephones: the 30 VIP/SP+IP telephones and the 12-Series
IP telephones, the latter being the most popular.These telephones had a very
limited, button-based feature set, while the network interface was a 10 Mbps hub,
with an extra interface for a PC or printer. Also, these phones require an external
power source, whereas second-generation phones can utilize inline power. Both
the 30 VIP/SP+IP telephones and the 12-Series support either G.711 or G.723.1
coder-decoders (CODEC), support Microsoft NetMeeting, H.323 support, and
DHCP/Boot P support.
While sharing many similarities with their predecessors, such as support for
open standards and the ability to interact with Microsoft NetMeeting, secondgeneration
phones represent a vast improvement over the first-generation phones.
Certain second-generation phones interface with the network via a 10/100 Mbps
switched connection, also providing an extra port for a PC or other peripheral
device, as well as an RS-232 port for additional capabilities. Second-generation
phones such as the 7940 and 7960 offer an LCD screen used for a menu-based
feature set as opposed to the button-based feature set of their predecessors.The
most impressive feature of the second-generation phones is the ability to utilize
inline power. Now instead of using an external power supply, these phones,
through the use of a specialized inline-power patch panel or specialized modules
for the Catalyst switch line, can be powered directly through their category-5
cable.We will discuss inline power options in the infrastructure section later in
this chapter.
There are currently four phones in Cisco’s second-generation phone offering:
The 7910/7910+SW phone
The 7940 phone
The 7960 phone
The 7935 phone
Cisco also offers a completely software-based logical IP telephone called the
IP SoftPhone.The SoftPhone provides an alternative to the hardware-based second
generation IP telephones. It offers a PC-based software application that interfaces
directly with the CallManager server to provide IP telephony.
The 7910/7910+SW, 7940, and 7960 are all end-user phones, the only difference
really being the features supported, such as menu options, speaker phone,
display, and number of lines each phone supports.
The 7960 stands out among its peers as being the only second-generation
telephone to offer support for the Station Initiation Protocol (SIP). SIP allows
the 7960 to operate without a CallManager on the local LAN. Instead, it communicates
directly with the gateway.The 7960 can be expanded further by use of
the 7914 expansion module.
The 7914 provides an additional 14 lines to your 7960 telephone, plus two
7914 units can be daisy chained together to provide an additional 28 lines of support.
This serves as a great solution for receptionist telephone stations.The 7935
is the speakerphone offering in the second-generation product line. Once again,
you should consult the Cisco Web site for the latest product offerings in this line.
Table 2.1 discusses the different features of the second-generation IP telephones.
Cisco Gateways
Gateways are devices used to connect your IP telephony infrastructure to the
Public Switched Telephone Network (PSTN) or to legacy PBX systems. Cisco’s
product line currently includes over 20 different gateway products, each supporting
the various types of gateway protocols. Currently there are three different
types of gateways supported by the Cisco IP telephony solution:
Skinny Gateway Protocol
H.323
MGCP
The Skinny Gateway Protocol is based on the industry standard SGCP protocol;
however it is only used on the Cisco Gateway product line. In other words,
while SGCP is an open standard, the Skinny Gateway Protocol is a proprietary
standard used by Cisco only. (This reminds one of the Cisco implementation of
High-Level Data Link Control (HDLC)—while HDLC is an industry standard,
Cisco has written extensions into it making its implementation inoperable with
other vendor’s equipment.) Devices that support the Skinny Gateway Protocol
include the DT-24+ and DE-30+ gateways, the Catalyst 4000 WS-X4604-GWY
module, and the Catalyst 6000 WS-X6608-x1 module.
H.323 is an open industry-wide standard. H.323 gateways are most commonly
found in integrated router gateway devices and in communication to
Cisco CallManager. Devices that support H.323 include:VG200, the 1750 router,
the 3810 router, the 2600 router, the 3600 router, the 7200 router, the 5300
access server, and the Catalyst 4000 WS-X4604-GWY module.
Media Gateway Control Protocol is the most recent of the gateway platforms.
MGCP is a Cisco-supported standard and is currently only used in communications
between Cisco CallManager and the VG200 standalone gateway, although
several members of the Cisco product line will support it in the future.This
group includes the MCS 3810, the 2600 Series routers, the 3600 Series routers,
the Catalyst 4000 WS-X4604-GWY module, and the Catalyst 6000 WS-X6608-
x1 module. As always, consult the Cisco Web site for information regarding new
product support.
Unity Voice-Mail/Unified Messaging Solutions
Unified messaging refers to several products in the Cisco product line that allow
end users and administrators to manage all communication from a single point of
administration.This product line has undergone several changes within its lifetime,
the latest of which came with the Cisco acquisition of the Active Voice
Corporation in 2000.With this acquisition, Cisco is offering the Unity product
suite as its unified messaging solution.The previous unified messaging solution
was a product line known as uOne, which has been discontinued.
The Unity product line is a powerful collection of tools that allows a user
to retrieve e-mail, voice-mail, and faxes all from one location—a truly converged
solution. Like the rest of Cisco’s IP telephony product offering, the Unity
product suite is continually being revised.We will discuss some of the features
available as of this writing, but bear in mind that new features are most likely to
appear in the near future.
Unity integrates with Microsoft Exchange server and the Outlook Mail client
to provide a centralized application where a user can retrieve e-mail, voice mail,
and faxes.This solution allows users to send, receive, and manage voice messages
directly from the Outlook client. Unity also gives users the ability to send and
receive faxes directly from the user’s Outlook mail client. A user can either fax
directly or send e-mail that will be received in the form of a fax. Prior to the
acquisition by Cisco, the Unity product line offered an integrated fax solution
known as Active Fax.This product is no longer in production. In order to utilize
a fax solution with the Unity product suite, a third-party fax server such as that
from RightFax or Omtool must also be purchased. Consult the Cisco Web site
for the most current listing of approved fax server software.
A personal Web assistant is also included with the Unity suite, allowing users
to manage their voice-messaging options directly from a Web page. Users have
the ability to change passwords, greetings, mailbox options, and so on, taking the
burden off the system administrators and providing users the ability to make
changes to their systems as they see fit.
This type of solution provides users with a great deal of flexibility and
mobility.A company executive called away on urgent business at the last minute
could use her laptop to check her voice-mail and fax, and she could use the personal
Web assistant to update her greeting, letting everyone know she is not in
the office.
Exploring IP Telephony Applications
Legacy PBX and similar systems have set a very high benchmark for reliability, scalability,
and service. In order for IP telephony to become a viable solution and to
either eliminate and/or compete with these systems, the same levels of service and
available features must be achieved. Cisco and other vendors, such as Interactive
Intelligence, Latitude Communications, and Intelligent Telemanagement Solutions,
are developing a number of applications to meet this challenge.The sections that
follow discuss a number of these applications and their features and benefits.
Introducing Cisco’s IP Telephony Applications
Cisco and other vendors have developed software solutions to further enhance
their IP telephony solutions. Along with the opportunities they are fostering, of
course, come new and difficult challenges.When we think about Cisco Systems,
the first thing that comes to mind is probably not the role of a software vendor,
but the world leader in networking hardware. IP telephony applications allow
Cisco to augment their IP telephony hardware with features and services to make
IP telephony an even more viable solution for Cisco’s customers. In the following
sections, we’ll describe Cisco’s WebAttendant, IP SoftPhone, Internet
Communications Software (ICS), Interactive Voice Response (IVR), and
AutoAttendant services.
Cisco Web Attendant
Cisco WebAttendant is designed to replace traditional manual attendant consoles.
It is a Web-based Graphical User Interface (GUI) that allows the user to receive
and dispatch calls from any IP phone within the network.WebAttendant works
on a client server architecture that allows the IP phone in use to interface directly
with the CallManager to direct calls and to monitor the status of lines, much like
a traditional receptionist console.
Another added benefit of WebAttendant is the ability it provides system
administrators to perform system maintenance from that same easy-to-use Webbased
GUI as opposed to the interface of the legacy PBX systems.WebAttendant
offers many of the same features offered by traditional PBX systems such as hunt
groups and multiple attendant consoles.
WebAttendant is included as part of the basic package when purchasing
CallManager 3.x. It has the ability to scale to meet the size of almost any IP telephony
infrastructure. A single WebAttendant console can monitor up to 26 calls
at a time.A single CallManager cluster utilizing WebAttendant can support up 32
hunt groups with 16 members per hunt group. Also, a cluster can support up to
96 WebAttendant consoles.That means up to 512 (96 consoles x 26 calls) calls at
one time.
When designing your infrastructure to include WebAttendant, make sure to
take into consideration all the design limitations discussed in the previous paragraph,
such as number of hunt groups (32), number of members within those
hunt groups (16), as well as the maximum number of simultaneous conversations
possible (512).Your design should never reach the limitations of the
WebAttendant system—if you are approaching these design limits you should
consider utilizing multiple CallManager clusters.
Cisco IP SoftPhone
Cisco IP SoftPhone is a client-based application that integrates seamlessly with
Cisco CallManager, and is designed to allow users to utilize IP telephony from
any network-attached PC. All the client requires is a microphone and speaker,
and they now have a fully functional IP telephone handset. A GUI on the user’s
PC provides a dial-pad and other functions present on a standard IP telephony
handset.This application provides a great solution for traveling users who need
the benefits and features of IP telephony, but are unable to take a regular IP telephony
handset with them. An important note to make regarding IP SoftPhone is
that it consumes 20 device units on a CallManager server, as opposed to the one
used by a standard IP telephone handset. Another note to make regarding IP
SoftPhone is that it must be installed with Microsoft NetMeeting—SoftPhone
will not work without it. If you are planning to deploy IP SoftPhone on more
than a limited basis, ensure that your infrastructure is equipped adequately for the
load it will face.
Internet Communications Software
Internet Communications Software (ICS) is a suite of five tools designed for service
and application providers to further grasp the benefits of IP telephony.These
components are:
Automatic Call Distribution (ACD)
Cisco IP Contact Center (IPCC)
Intelligent Contact Management (ICM)
Customer Interaction Suite
Network Applications Manager (NAM)
Automatic Call Distribution
Automatic Call Distribution (ACD) is a tool used to reroute calls to different
customers serviced via the same central office.ACD is provided as part of the
Network Applications Manager (NAM), which will be discussed later in this
section.
Cisco IP Contact Center
Cisco IP Contact Center (IPCC) is an IP telephony solution that allows call centers
using IP telephony to receive regular POTS calls as well as IP telephony
calls. IPCC can provide the following features: intelligent call routing, computer
telephony integration, integration with legacy ACD, and integration with legacy
as well as IP-IVR.
Intelligent Contact Management
Intelligent Contact Management (ICM) is due to be released in the first part of
2002. It is a software solution used for direction and relay of customer contact
information between resources.This system will utilize a set of user-defined roles
in order to route voice,World Wide Web (WWW), and e-mail correspondence to
the appropriate system or resource.
Customer Interaction Suite
Customer Interaction Suite is an IP telephony solution that allows corporations
and service providers the ability to interact with their customers on the Internet
or network in a real-time manner.There are four components to the Customer
Interaction Suite: Cisco Media Manager, Cisco Media Blender, Cisco E-Mail
Manager, and Cisco Collaboration Server:
Cisco Media Manager works with Cisco Collaboration Server to
direct a customer to the resource that will best serve their needs or
requests.
Cisco Media Blender does just what its name implies; it blends the
different types of media into one format.Voice, text, and WWW traffic
can all be combined into one medium, offering a significant cost savings
over the traditional model of separate dissimilar systems used to manage
customer data and communications.
Cisco E-Mail Manager is used to direct received e-mail to the appropriate
party or resource.This allows an organization to cut down on lag
time from the moment when e-mail is sent to the organization and
when the organization is able to respond to the e-mail.
Network Applications Manager
Network Applications Manager (NAM) is the software solution that gives organizations
the ability to utilize all the other ICS components we have just discussed.
It provides a hierarchical structure providing a range of services from very simple
to very complex. NAM has a long list of benefits and features, including ACD,
CTI, IVR, customer relationship management (CRM),Web collaboration, e-mail
response management, and call management. Consult Cisco’s Web site for the
most current information on NAM as well as other IP telephony applications.
Interactive Voice Response
Interactive voice response (IVR) is a voice application designed to handle calls on
systems serving as voice-gateways.This system is available in two packages, either
as a router equipped with VoIP interfaces and feature sets, or as a server-based
Java solution running on Windows NT/2000 servers.The server-based solution is
the newest and most feature-rich offering for IVR within the industry.This
system offers a Web-enabled GUI management interface, with an open programming
customizable model. IVR is used to provide information in the form of
voice in response to a user-initiated string of information such as spoken word,
key-tones, or telephone line signaling. A very practical application of this solution
would be a prepaid calling card system. In such a system, a user would enter a
calling-card number and personal identification number (PIN). IVR could be
used to allow/disallow the call, report to the user the number of minutes left on
the card, and so on. For more information on IVR and its uses/capabilities, refer
to the Cisco Web site.
AutoAttendant
AutoAttendant is a Cisco application that works with IVR and CallManager software
to provide call routing services. It allows CallManager to receive calls on
specific extensions and then forward that call based on caller input.This type of
system could be found in organizations that utilize menu-based systems offering
caller options such as dialing a user’s extension and/or dial-by-name systems.
Third-Party IP Telephony Applications
As we discussed earlier, Cisco is a networking hardware designer and manufacturer,
not a software company. Its primary focus is, and should be, the hardware
aspect of IP telephony. Because Cisco’s AVVID architecture is built on open standards,
it has opened the door for numerous vendors to either write new software
to become interoperable with Cisco’s solutions and/or to make their existing
software interoperable. It seems to have worked. Although IP telephony is a still a
relatively new technology, companies are already seeing its potential and have
started to develop applications designed to work alongside Cisco’s IP telephony
architecture.This can only continue to make IP telephony a more accepted alternative
to the traditional systems.This section will introduce three vendors who
have designed software to work with the IP telephony solution: Interactive
Intelligence, Latitude, and ISI. Chapter 7 will discuss these as well as other applications,
and how to choose the appropriate applications for your needs.
Interactive Intelligence’s Solutions
Interactive Intelligence (www.inin.com) has an Original Equipment
Manufacturer (OEM) agreement with Cisco, in which Interactive Intelligence’s
Interaction Center platform will be included on the Cisco ICS 7750 platform.
The Interaction Center platform of software provides a single platform to integrate
voice, fax, e-mail, Internet text-chats,WWW requests, and VoIP calls.
Interaction Center was designed to run on top of Windows 2000 and includes
several different software components. As with most similar software solutions,
Interaction Center runs on a client/server architecture, with software installed on
both a central processing server and on each Interaction Center client. Interactive
Intelligence has also created three specialized versions of the Interaction Center
platform: Customer Interaction Center (CIC), Enterprise Interaction Center
(EIC), and Service Interaction Center (SIC).
Latitude Communication’s Solutions
Latitude Communications (www.latitude.com) has developed a specialized
e-conferencing platform that integrates with Cisco CallManager.Their product
is known as MeetingPlace IP. MeetingPlace IP is a client/server based videoconferencing
application for mid- to large-sized enterprise environments.
MeetingPlace IP offers real-time collaboration applications used for videoconferencing,
training, and project management.
Intelligent Telemanagement Solutions
Intelligent Telemanagement Solutions (ISI, at www.isi-info.com) is the first company
to introduce an IP telephony accounting application.This is a function that
legacy PBX systems and similar devices have been performing for several years,
which IP telephony is still far behind on.The ISI system allows administrators to
further utilize the benefits of IP telephony toll-bypass, by allowing an administrator
to analyze traffic patterns and optimize their infrastructure based on their
findings.The ISI system works with the CallManager system, utilizing the CDR
for each IP telephony call.
Introduction to Video
Traditional old world video transmissions typically consist of one to several ISDN
basic rate interface (BRI) lines connecting proprietary video-conferencing endstations.
These ISDN lines typically operate in a point-to-point infrastructure utilizing
the H.320 specification. Usually the bandwidth used is anywhere from 128
Kbps to 384 Kbps, and is kept completely separate from the existing data and voice
infrastructures, which results in a large under-utilization of available resources.
Although some advanced PBX systems can terminate the BRI lines for the video
conferencing systems, the BRI lines and voice lines are kept completely separate
from one another. As the technology has improved over the last several years, this
type of system has gained a great deal of popularity and it is not uncommon to
find some form of this system in most mid- to large-sized organizations.
New world IP-based video conferencing systems allow you to utilize your
existing data networking infrastructure as opposed to working with a separate
infrastructure, resulting in much better utilization of your network resources.
IP-based video conferencing, on the other hand, utilizes the H.323 specification
(discussed earlier in this chapter), allowing you to utilize video conferencing over
a variety of mediums including shared and switched media such as Ethernet,
leased lines, and nonbroadcast multiaccess networks such as Frame Relay and
Asynchronous Transfer Mode (ATM).
As part of the AVVID line of solutions, Cisco offers several solutions to enable
video-conferencing to meet the varying needs of organizations of a range of sizes.
In the following section we will discuss IP-based video conferencing in greater
detail, as well as some of the components used for IP-based video conferencing.
Understanding Video Components
As we discussed in the Introduction to IP Telephony section,VoIP is very intolerant
to delay and dropped packets.The statement is even more true when we
discuss IP-based video-conferencing or video over IP. Just imagine if you were
watching a video conference that was not received in real-time, perhaps a sales
presentation or some type of training, and the information was received out of
sequence—you could be looking at a chart that you heard about five minutes
ago. IP-based video transmissions as well as IP telephony are very similar in
nature.Voice, or in this case, video data is encapsulated into IP packets and transported
to the end destinations. In the following sections we will discuss some of
the components needed to facilitate IP-based video conferencing, such as gateways,
gatekeepers, multi-point control units (MCU), video terminal adapters
(VTA), and endpoints.We will also briefly discuss the IP/TV product line and
the services it provides. As with the rest of the AVVID product offerings, it is
highly recommended you consult Cisco’s Web site for the most up-to-date information
on the products and solutions that we will discuss in this section.
Gateways
Gateways are used to provide you with IP-based video conferencing network
access outside of your network.They provide protocol translation, such as H.323
to H.320, and translation to ISDN from other network mediums. For a gateway
solution, Cisco offers the IPVC product family. Currently Cisco is offering the
IPVC 3520, 3525, and 3540 platforms.These are modular platforms offering
LAN, ISDN BRI, ISDN Primary Rate Interface (PRI), and V.35 connection
options. As this line is growing rapidly, I would expect that more product offerings
are just around the corner for the IPVC 35xx product family.
Gatekeepers
A Gatekeeper is a device used to permit or deny requests for video-conferences;
they are an integral part of the IP-based video conferencing solution. It is responsible
for deciding if enough resources are available for the video conference to
occur, and if the device requesting the conference can gain access to the
requested resources. Currently, there are two solutions in the Cisco product line
that offer Gatekeeper functionality, the IPVC 3510, and the Multimedia
Convergence Manager (MCM) IOS feature set available for the 2500, 2600,
3600, 7200, and MC3810 platforms.
Multi-Point Control Units
A Multi-Point Control Unit (MCU) serves as a center for video-conferencing
communications and infrastructure. It serves as a single point of control governing
the establishment, joining, and termination of video transmissions.An
MCU is needed whenever three or more participants need access to the same
real-time video conference.A single MCU can also control several different video
conferences simultaneously.
Currently, Cisco offers the IPVC 3510 MCU and IPVC 3540 Multipoint
Conference Unit (MCU module) platforms to fill this role.The 3510 can support
up to 15 participants in either a single conference or multiple conferences,
whereas the 3540 can support up to 100 users in either a single conference or
multiple conferences.
Video Terminal Adapter
The Video Terminal Adapter’s (VTA) role in video conferencing is to provide an
interface to legacy video-conferencing systems.This is accomplished by providing
a protocol translation between the legacy H.320 specification for video-conferencing
over ISDN and the IP telephony H.323 protocol.As we discussed in the
Introduction to Video-Conferencing, many mid- to large-sized organizations have
already invested in video-conferencing technology. Utilizing VTAs, these organizations
can protect their investment in legacy equipment while still enjoying the
benefits of the new IP-based video-conferencing solutions. Currently, Cisco
offers the IPVC 3530 platform for VTA functionality.
Endpoint Devices
Endpoints are the end-user devices that subscribe to and receive services from
video-conferencing. Cisco does not manufacture an endpoint series of devices;
however, their video-conferencing solutions do support many of the industry
standard endpoint devices that support the H.323 specification.This list currently
includes Microsoft, PictureTel, Polycom, Sony, TANDBERG,VCON, VTEL, and
Zydacron.While systems vary from manufacturer to manufacturer, you will typically
find the same components, usually a video camera, video screen, and audio
components. Usually manufacturers differentiate themselves by offering better
resolution or screen refresh time, while the core functionality for each unit is
generally the same.The list of supported vendors is growing almost daily. Consult
Cisco’s Web site as well as your chosen vendor’s Web site to ensure endpoint
compatibility.
Cisco IP/TV
The Cisco IP/TV product line is a hardware and software solution designed to
provide real-time one-way video broadcasting services to desktop computers.
There are two components to this product offering, the IP/TV series of servers
and the IP/TV desktop software.The system differs from typical video-conferencing
systems in that it utilizes multicast traffic to allow several subscribers to
view the same presentation from a single source.This system is often utilized for
employee training or company-wide conferences in which only a few parties
speak.
The IP/TV server family includes five servers. All are preloaded Windows
2000 servers: the 3411, 3422, 3423, 3431, and 3415.The 3411 serves as a management
and broadcast control server. It is responsible for scheduling, server access,
balancing of network resources, and control of video services.The 3422 and 3423
servers are responsible for the actual capture, storing, and transmission of live or
archived video broadcasts.These servers receive their direction and control from
the 3411 server.The 3431 server is an archive server. It is responsible for the
storing and cataloging of prerecorded video-transmissions such as training material.
This material can then, at any time, be retransmitted by the 3411 and
3422/3423 servers.The 3415 server is the video starter system. It provides an allin-
one IP/TV solution for small organizations that are just getting started with
IP/TV. It offers control, broadcast, and storage facilities.While offering an all-inone
solution, it is not intended to replace, nor can it offer the same functionality
of the 3411, 3422/3423, and 3431 servers. Rather, it is intended to be a steppingstone
into the larger environment.
The client side of the IP/TV system is a software application known as the
IP/TV viewer.This software communicates directly with the 3411 control server
to attain information regarding available broadcasts and program listings.Whenthe appropriate program is selected, the IP/TV viewer allows the user to view
the broadcast.
architecture.There have been two generations of IP telephones produced by
Cisco: first-generation and second-generation.
Cisco’s first-generation IP telephones came with the acquisition of Selsius
Technologies.These telephones are now discontinued.There were two models of
the first-generation telephones: the 30 VIP/SP+IP telephones and the 12-Series
IP telephones, the latter being the most popular.These telephones had a very
limited, button-based feature set, while the network interface was a 10 Mbps hub,
with an extra interface for a PC or printer. Also, these phones require an external
power source, whereas second-generation phones can utilize inline power. Both
the 30 VIP/SP+IP telephones and the 12-Series support either G.711 or G.723.1
coder-decoders (CODEC), support Microsoft NetMeeting, H.323 support, and
DHCP/Boot P support.
While sharing many similarities with their predecessors, such as support for
open standards and the ability to interact with Microsoft NetMeeting, secondgeneration
phones represent a vast improvement over the first-generation phones.
Certain second-generation phones interface with the network via a 10/100 Mbps
switched connection, also providing an extra port for a PC or other peripheral
device, as well as an RS-232 port for additional capabilities. Second-generation
phones such as the 7940 and 7960 offer an LCD screen used for a menu-based
feature set as opposed to the button-based feature set of their predecessors.The
most impressive feature of the second-generation phones is the ability to utilize
inline power. Now instead of using an external power supply, these phones,
through the use of a specialized inline-power patch panel or specialized modules
for the Catalyst switch line, can be powered directly through their category-5
cable.We will discuss inline power options in the infrastructure section later in
this chapter.
There are currently four phones in Cisco’s second-generation phone offering:
The 7910/7910+SW phone
The 7940 phone
The 7960 phone
The 7935 phone
Cisco also offers a completely software-based logical IP telephone called the
IP SoftPhone.The SoftPhone provides an alternative to the hardware-based second
generation IP telephones. It offers a PC-based software application that interfaces
directly with the CallManager server to provide IP telephony.
The 7910/7910+SW, 7940, and 7960 are all end-user phones, the only difference
really being the features supported, such as menu options, speaker phone,
display, and number of lines each phone supports.
The 7960 stands out among its peers as being the only second-generation
telephone to offer support for the Station Initiation Protocol (SIP). SIP allows
the 7960 to operate without a CallManager on the local LAN. Instead, it communicates
directly with the gateway.The 7960 can be expanded further by use of
the 7914 expansion module.
The 7914 provides an additional 14 lines to your 7960 telephone, plus two
7914 units can be daisy chained together to provide an additional 28 lines of support.
This serves as a great solution for receptionist telephone stations.The 7935
is the speakerphone offering in the second-generation product line. Once again,
you should consult the Cisco Web site for the latest product offerings in this line.
Table 2.1 discusses the different features of the second-generation IP telephones.
Cisco Gateways
Gateways are devices used to connect your IP telephony infrastructure to the
Public Switched Telephone Network (PSTN) or to legacy PBX systems. Cisco’s
product line currently includes over 20 different gateway products, each supporting
the various types of gateway protocols. Currently there are three different
types of gateways supported by the Cisco IP telephony solution:
Skinny Gateway Protocol
H.323
MGCP
The Skinny Gateway Protocol is based on the industry standard SGCP protocol;
however it is only used on the Cisco Gateway product line. In other words,
while SGCP is an open standard, the Skinny Gateway Protocol is a proprietary
standard used by Cisco only. (This reminds one of the Cisco implementation of
High-Level Data Link Control (HDLC)—while HDLC is an industry standard,
Cisco has written extensions into it making its implementation inoperable with
other vendor’s equipment.) Devices that support the Skinny Gateway Protocol
include the DT-24+ and DE-30+ gateways, the Catalyst 4000 WS-X4604-GWY
module, and the Catalyst 6000 WS-X6608-x1 module.
H.323 is an open industry-wide standard. H.323 gateways are most commonly
found in integrated router gateway devices and in communication to
Cisco CallManager. Devices that support H.323 include:VG200, the 1750 router,
the 3810 router, the 2600 router, the 3600 router, the 7200 router, the 5300
access server, and the Catalyst 4000 WS-X4604-GWY module.
Media Gateway Control Protocol is the most recent of the gateway platforms.
MGCP is a Cisco-supported standard and is currently only used in communications
between Cisco CallManager and the VG200 standalone gateway, although
several members of the Cisco product line will support it in the future.This
group includes the MCS 3810, the 2600 Series routers, the 3600 Series routers,
the Catalyst 4000 WS-X4604-GWY module, and the Catalyst 6000 WS-X6608-
x1 module. As always, consult the Cisco Web site for information regarding new
product support.
Unity Voice-Mail/Unified Messaging Solutions
Unified messaging refers to several products in the Cisco product line that allow
end users and administrators to manage all communication from a single point of
administration.This product line has undergone several changes within its lifetime,
the latest of which came with the Cisco acquisition of the Active Voice
Corporation in 2000.With this acquisition, Cisco is offering the Unity product
suite as its unified messaging solution.The previous unified messaging solution
was a product line known as uOne, which has been discontinued.
The Unity product line is a powerful collection of tools that allows a user
to retrieve e-mail, voice-mail, and faxes all from one location—a truly converged
solution. Like the rest of Cisco’s IP telephony product offering, the Unity
product suite is continually being revised.We will discuss some of the features
available as of this writing, but bear in mind that new features are most likely to
appear in the near future.
Unity integrates with Microsoft Exchange server and the Outlook Mail client
to provide a centralized application where a user can retrieve e-mail, voice mail,
and faxes.This solution allows users to send, receive, and manage voice messages
directly from the Outlook client. Unity also gives users the ability to send and
receive faxes directly from the user’s Outlook mail client. A user can either fax
directly or send e-mail that will be received in the form of a fax. Prior to the
acquisition by Cisco, the Unity product line offered an integrated fax solution
known as Active Fax.This product is no longer in production. In order to utilize
a fax solution with the Unity product suite, a third-party fax server such as that
from RightFax or Omtool must also be purchased. Consult the Cisco Web site
for the most current listing of approved fax server software.
A personal Web assistant is also included with the Unity suite, allowing users
to manage their voice-messaging options directly from a Web page. Users have
the ability to change passwords, greetings, mailbox options, and so on, taking the
burden off the system administrators and providing users the ability to make
changes to their systems as they see fit.
This type of solution provides users with a great deal of flexibility and
mobility.A company executive called away on urgent business at the last minute
could use her laptop to check her voice-mail and fax, and she could use the personal
Web assistant to update her greeting, letting everyone know she is not in
the office.
Exploring IP Telephony Applications
Legacy PBX and similar systems have set a very high benchmark for reliability, scalability,
and service. In order for IP telephony to become a viable solution and to
either eliminate and/or compete with these systems, the same levels of service and
available features must be achieved. Cisco and other vendors, such as Interactive
Intelligence, Latitude Communications, and Intelligent Telemanagement Solutions,
are developing a number of applications to meet this challenge.The sections that
follow discuss a number of these applications and their features and benefits.
Introducing Cisco’s IP Telephony Applications
Cisco and other vendors have developed software solutions to further enhance
their IP telephony solutions. Along with the opportunities they are fostering, of
course, come new and difficult challenges.When we think about Cisco Systems,
the first thing that comes to mind is probably not the role of a software vendor,
but the world leader in networking hardware. IP telephony applications allow
Cisco to augment their IP telephony hardware with features and services to make
IP telephony an even more viable solution for Cisco’s customers. In the following
sections, we’ll describe Cisco’s WebAttendant, IP SoftPhone, Internet
Communications Software (ICS), Interactive Voice Response (IVR), and
AutoAttendant services.
Cisco Web Attendant
Cisco WebAttendant is designed to replace traditional manual attendant consoles.
It is a Web-based Graphical User Interface (GUI) that allows the user to receive
and dispatch calls from any IP phone within the network.WebAttendant works
on a client server architecture that allows the IP phone in use to interface directly
with the CallManager to direct calls and to monitor the status of lines, much like
a traditional receptionist console.
Another added benefit of WebAttendant is the ability it provides system
administrators to perform system maintenance from that same easy-to-use Webbased
GUI as opposed to the interface of the legacy PBX systems.WebAttendant
offers many of the same features offered by traditional PBX systems such as hunt
groups and multiple attendant consoles.
WebAttendant is included as part of the basic package when purchasing
CallManager 3.x. It has the ability to scale to meet the size of almost any IP telephony
infrastructure. A single WebAttendant console can monitor up to 26 calls
at a time.A single CallManager cluster utilizing WebAttendant can support up 32
hunt groups with 16 members per hunt group. Also, a cluster can support up to
96 WebAttendant consoles.That means up to 512 (96 consoles x 26 calls) calls at
one time.
When designing your infrastructure to include WebAttendant, make sure to
take into consideration all the design limitations discussed in the previous paragraph,
such as number of hunt groups (32), number of members within those
hunt groups (16), as well as the maximum number of simultaneous conversations
possible (512).Your design should never reach the limitations of the
WebAttendant system—if you are approaching these design limits you should
consider utilizing multiple CallManager clusters.
Cisco IP SoftPhone
Cisco IP SoftPhone is a client-based application that integrates seamlessly with
Cisco CallManager, and is designed to allow users to utilize IP telephony from
any network-attached PC. All the client requires is a microphone and speaker,
and they now have a fully functional IP telephone handset. A GUI on the user’s
PC provides a dial-pad and other functions present on a standard IP telephony
handset.This application provides a great solution for traveling users who need
the benefits and features of IP telephony, but are unable to take a regular IP telephony
handset with them. An important note to make regarding IP SoftPhone is
that it consumes 20 device units on a CallManager server, as opposed to the one
used by a standard IP telephone handset. Another note to make regarding IP
SoftPhone is that it must be installed with Microsoft NetMeeting—SoftPhone
will not work without it. If you are planning to deploy IP SoftPhone on more
than a limited basis, ensure that your infrastructure is equipped adequately for the
load it will face.
Internet Communications Software
Internet Communications Software (ICS) is a suite of five tools designed for service
and application providers to further grasp the benefits of IP telephony.These
components are:
Automatic Call Distribution (ACD)
Cisco IP Contact Center (IPCC)
Intelligent Contact Management (ICM)
Customer Interaction Suite
Network Applications Manager (NAM)
Automatic Call Distribution
Automatic Call Distribution (ACD) is a tool used to reroute calls to different
customers serviced via the same central office.ACD is provided as part of the
Network Applications Manager (NAM), which will be discussed later in this
section.
Cisco IP Contact Center
Cisco IP Contact Center (IPCC) is an IP telephony solution that allows call centers
using IP telephony to receive regular POTS calls as well as IP telephony
calls. IPCC can provide the following features: intelligent call routing, computer
telephony integration, integration with legacy ACD, and integration with legacy
as well as IP-IVR.
Intelligent Contact Management
Intelligent Contact Management (ICM) is due to be released in the first part of
2002. It is a software solution used for direction and relay of customer contact
information between resources.This system will utilize a set of user-defined roles
in order to route voice,World Wide Web (WWW), and e-mail correspondence to
the appropriate system or resource.
Customer Interaction Suite
Customer Interaction Suite is an IP telephony solution that allows corporations
and service providers the ability to interact with their customers on the Internet
or network in a real-time manner.There are four components to the Customer
Interaction Suite: Cisco Media Manager, Cisco Media Blender, Cisco E-Mail
Manager, and Cisco Collaboration Server:
Cisco Media Manager works with Cisco Collaboration Server to
direct a customer to the resource that will best serve their needs or
requests.
Cisco Media Blender does just what its name implies; it blends the
different types of media into one format.Voice, text, and WWW traffic
can all be combined into one medium, offering a significant cost savings
over the traditional model of separate dissimilar systems used to manage
customer data and communications.
Cisco E-Mail Manager is used to direct received e-mail to the appropriate
party or resource.This allows an organization to cut down on lag
time from the moment when e-mail is sent to the organization and
when the organization is able to respond to the e-mail.
Network Applications Manager
Network Applications Manager (NAM) is the software solution that gives organizations
the ability to utilize all the other ICS components we have just discussed.
It provides a hierarchical structure providing a range of services from very simple
to very complex. NAM has a long list of benefits and features, including ACD,
CTI, IVR, customer relationship management (CRM),Web collaboration, e-mail
response management, and call management. Consult Cisco’s Web site for the
most current information on NAM as well as other IP telephony applications.
Interactive Voice Response
Interactive voice response (IVR) is a voice application designed to handle calls on
systems serving as voice-gateways.This system is available in two packages, either
as a router equipped with VoIP interfaces and feature sets, or as a server-based
Java solution running on Windows NT/2000 servers.The server-based solution is
the newest and most feature-rich offering for IVR within the industry.This
system offers a Web-enabled GUI management interface, with an open programming
customizable model. IVR is used to provide information in the form of
voice in response to a user-initiated string of information such as spoken word,
key-tones, or telephone line signaling. A very practical application of this solution
would be a prepaid calling card system. In such a system, a user would enter a
calling-card number and personal identification number (PIN). IVR could be
used to allow/disallow the call, report to the user the number of minutes left on
the card, and so on. For more information on IVR and its uses/capabilities, refer
to the Cisco Web site.
AutoAttendant
AutoAttendant is a Cisco application that works with IVR and CallManager software
to provide call routing services. It allows CallManager to receive calls on
specific extensions and then forward that call based on caller input.This type of
system could be found in organizations that utilize menu-based systems offering
caller options such as dialing a user’s extension and/or dial-by-name systems.
Third-Party IP Telephony Applications
As we discussed earlier, Cisco is a networking hardware designer and manufacturer,
not a software company. Its primary focus is, and should be, the hardware
aspect of IP telephony. Because Cisco’s AVVID architecture is built on open standards,
it has opened the door for numerous vendors to either write new software
to become interoperable with Cisco’s solutions and/or to make their existing
software interoperable. It seems to have worked. Although IP telephony is a still a
relatively new technology, companies are already seeing its potential and have
started to develop applications designed to work alongside Cisco’s IP telephony
architecture.This can only continue to make IP telephony a more accepted alternative
to the traditional systems.This section will introduce three vendors who
have designed software to work with the IP telephony solution: Interactive
Intelligence, Latitude, and ISI. Chapter 7 will discuss these as well as other applications,
and how to choose the appropriate applications for your needs.
Interactive Intelligence’s Solutions
Interactive Intelligence (www.inin.com) has an Original Equipment
Manufacturer (OEM) agreement with Cisco, in which Interactive Intelligence’s
Interaction Center platform will be included on the Cisco ICS 7750 platform.
The Interaction Center platform of software provides a single platform to integrate
voice, fax, e-mail, Internet text-chats,WWW requests, and VoIP calls.
Interaction Center was designed to run on top of Windows 2000 and includes
several different software components. As with most similar software solutions,
Interaction Center runs on a client/server architecture, with software installed on
both a central processing server and on each Interaction Center client. Interactive
Intelligence has also created three specialized versions of the Interaction Center
platform: Customer Interaction Center (CIC), Enterprise Interaction Center
(EIC), and Service Interaction Center (SIC).
Latitude Communication’s Solutions
Latitude Communications (www.latitude.com) has developed a specialized
e-conferencing platform that integrates with Cisco CallManager.Their product
is known as MeetingPlace IP. MeetingPlace IP is a client/server based videoconferencing
application for mid- to large-sized enterprise environments.
MeetingPlace IP offers real-time collaboration applications used for videoconferencing,
training, and project management.
Intelligent Telemanagement Solutions
Intelligent Telemanagement Solutions (ISI, at www.isi-info.com) is the first company
to introduce an IP telephony accounting application.This is a function that
legacy PBX systems and similar devices have been performing for several years,
which IP telephony is still far behind on.The ISI system allows administrators to
further utilize the benefits of IP telephony toll-bypass, by allowing an administrator
to analyze traffic patterns and optimize their infrastructure based on their
findings.The ISI system works with the CallManager system, utilizing the CDR
for each IP telephony call.
Introduction to Video
Traditional old world video transmissions typically consist of one to several ISDN
basic rate interface (BRI) lines connecting proprietary video-conferencing endstations.
These ISDN lines typically operate in a point-to-point infrastructure utilizing
the H.320 specification. Usually the bandwidth used is anywhere from 128
Kbps to 384 Kbps, and is kept completely separate from the existing data and voice
infrastructures, which results in a large under-utilization of available resources.
Although some advanced PBX systems can terminate the BRI lines for the video
conferencing systems, the BRI lines and voice lines are kept completely separate
from one another. As the technology has improved over the last several years, this
type of system has gained a great deal of popularity and it is not uncommon to
find some form of this system in most mid- to large-sized organizations.
New world IP-based video conferencing systems allow you to utilize your
existing data networking infrastructure as opposed to working with a separate
infrastructure, resulting in much better utilization of your network resources.
IP-based video conferencing, on the other hand, utilizes the H.323 specification
(discussed earlier in this chapter), allowing you to utilize video conferencing over
a variety of mediums including shared and switched media such as Ethernet,
leased lines, and nonbroadcast multiaccess networks such as Frame Relay and
Asynchronous Transfer Mode (ATM).
As part of the AVVID line of solutions, Cisco offers several solutions to enable
video-conferencing to meet the varying needs of organizations of a range of sizes.
In the following section we will discuss IP-based video conferencing in greater
detail, as well as some of the components used for IP-based video conferencing.
Understanding Video Components
As we discussed in the Introduction to IP Telephony section,VoIP is very intolerant
to delay and dropped packets.The statement is even more true when we
discuss IP-based video-conferencing or video over IP. Just imagine if you were
watching a video conference that was not received in real-time, perhaps a sales
presentation or some type of training, and the information was received out of
sequence—you could be looking at a chart that you heard about five minutes
ago. IP-based video transmissions as well as IP telephony are very similar in
nature.Voice, or in this case, video data is encapsulated into IP packets and transported
to the end destinations. In the following sections we will discuss some of
the components needed to facilitate IP-based video conferencing, such as gateways,
gatekeepers, multi-point control units (MCU), video terminal adapters
(VTA), and endpoints.We will also briefly discuss the IP/TV product line and
the services it provides. As with the rest of the AVVID product offerings, it is
highly recommended you consult Cisco’s Web site for the most up-to-date information
on the products and solutions that we will discuss in this section.
Gateways
Gateways are used to provide you with IP-based video conferencing network
access outside of your network.They provide protocol translation, such as H.323
to H.320, and translation to ISDN from other network mediums. For a gateway
solution, Cisco offers the IPVC product family. Currently Cisco is offering the
IPVC 3520, 3525, and 3540 platforms.These are modular platforms offering
LAN, ISDN BRI, ISDN Primary Rate Interface (PRI), and V.35 connection
options. As this line is growing rapidly, I would expect that more product offerings
are just around the corner for the IPVC 35xx product family.
Gatekeepers
A Gatekeeper is a device used to permit or deny requests for video-conferences;
they are an integral part of the IP-based video conferencing solution. It is responsible
for deciding if enough resources are available for the video conference to
occur, and if the device requesting the conference can gain access to the
requested resources. Currently, there are two solutions in the Cisco product line
that offer Gatekeeper functionality, the IPVC 3510, and the Multimedia
Convergence Manager (MCM) IOS feature set available for the 2500, 2600,
3600, 7200, and MC3810 platforms.
Multi-Point Control Units
A Multi-Point Control Unit (MCU) serves as a center for video-conferencing
communications and infrastructure. It serves as a single point of control governing
the establishment, joining, and termination of video transmissions.An
MCU is needed whenever three or more participants need access to the same
real-time video conference.A single MCU can also control several different video
conferences simultaneously.
Currently, Cisco offers the IPVC 3510 MCU and IPVC 3540 Multipoint
Conference Unit (MCU module) platforms to fill this role.The 3510 can support
up to 15 participants in either a single conference or multiple conferences,
whereas the 3540 can support up to 100 users in either a single conference or
multiple conferences.
Video Terminal Adapter
The Video Terminal Adapter’s (VTA) role in video conferencing is to provide an
interface to legacy video-conferencing systems.This is accomplished by providing
a protocol translation between the legacy H.320 specification for video-conferencing
over ISDN and the IP telephony H.323 protocol.As we discussed in the
Introduction to Video-Conferencing, many mid- to large-sized organizations have
already invested in video-conferencing technology. Utilizing VTAs, these organizations
can protect their investment in legacy equipment while still enjoying the
benefits of the new IP-based video-conferencing solutions. Currently, Cisco
offers the IPVC 3530 platform for VTA functionality.
Endpoint Devices
Endpoints are the end-user devices that subscribe to and receive services from
video-conferencing. Cisco does not manufacture an endpoint series of devices;
however, their video-conferencing solutions do support many of the industry
standard endpoint devices that support the H.323 specification.This list currently
includes Microsoft, PictureTel, Polycom, Sony, TANDBERG,VCON, VTEL, and
Zydacron.While systems vary from manufacturer to manufacturer, you will typically
find the same components, usually a video camera, video screen, and audio
components. Usually manufacturers differentiate themselves by offering better
resolution or screen refresh time, while the core functionality for each unit is
generally the same.The list of supported vendors is growing almost daily. Consult
Cisco’s Web site as well as your chosen vendor’s Web site to ensure endpoint
compatibility.
Cisco IP/TV
The Cisco IP/TV product line is a hardware and software solution designed to
provide real-time one-way video broadcasting services to desktop computers.
There are two components to this product offering, the IP/TV series of servers
and the IP/TV desktop software.The system differs from typical video-conferencing
systems in that it utilizes multicast traffic to allow several subscribers to
view the same presentation from a single source.This system is often utilized for
employee training or company-wide conferences in which only a few parties
speak.
The IP/TV server family includes five servers. All are preloaded Windows
2000 servers: the 3411, 3422, 3423, 3431, and 3415.The 3411 serves as a management
and broadcast control server. It is responsible for scheduling, server access,
balancing of network resources, and control of video services.The 3422 and 3423
servers are responsible for the actual capture, storing, and transmission of live or
archived video broadcasts.These servers receive their direction and control from
the 3411 server.The 3431 server is an archive server. It is responsible for the
storing and cataloging of prerecorded video-transmissions such as training material.
This material can then, at any time, be retransmitted by the 3411 and
3422/3423 servers.The 3415 server is the video starter system. It provides an allin-
one IP/TV solution for small organizations that are just getting started with
IP/TV. It offers control, broadcast, and storage facilities.While offering an all-inone
solution, it is not intended to replace, nor can it offer the same functionality
of the 3411, 3422/3423, and 3431 servers. Rather, it is intended to be a steppingstone
into the larger environment.
The client side of the IP/TV system is a software application known as the
IP/TV viewer.This software communicates directly with the 3411 control server
to attain information regarding available broadcasts and program listings.Whenthe appropriate program is selected, the IP/TV viewer allows the user to view
the broadcast.
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.
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.
Interpreting PBX Terminology
The world of telecommunications and PBX systems includes a vocabulary unique
unto itself.You may find that many of the words and acronyms are familiar and
common if your background is based in the data world. Nevertheless, there are a
number of new terms and concepts that need to be understood before tackling the
integration of voice and data systems. In addition, some acronyms have multiple
meanings depending on whether you’re discussing voice or data. For example, the
acronym CDP, to a Cisco router guru, likely means Cisco Discovery Protocol. In the
voice world this term refers to Coordinated Dial Plan.
So, what are the common PBX terms you may encounter? Well, the first
is a T-1.A T-1 circuit is capable of carrying up to 24 voice channels (DS-0),
depending on provisioning.The total available bandwidth is 1.544 Mbps, although
the Integrated Services Digital Network (ISDN) Primary Rate Interface (PRI),
which uses T-1 framing, takes one DS-0 for upper layer signaling.The European
standard is called E-1. It provides, however, 2.048 Mbps of bandwidth, or 32 channels.
An E-1-based PRI, on the other hand, uses two of these channels for signaling
and framing, and thus, allows for 30 user-based voice channels. In addition
to the T-1 ISDN PRI , the circuit may also be configured as channel associated
signaling (CAS) or ear-and-mouth (E&M).
It is warranted to expand on ear-and-mouth technology slightly in this
forum, as E&M ports are found on the Cisco hardware platforms and many
interconnections will make use of this specification. E&M can also stand for earth
and magneto, amongst other variations, and is simply another signaling methodology.
E&M, like FXO and FXS, is an analog specification, unlike ISDN, which is
digital. In addition, FXO is available for PSTN or PBX connections, whereas
E&M is for trunk or tie lines between switches—they are network-to-network
links. As such, some Cisco installations use the VIC-2E/M interface for connections
to voice mail or legacy PBX systems. Please note that this module supports
both the two and four wire specifications of E&M for types I, II, III, and V.
These links may also be loop start, in which removing the receiver from the
hook closes a circuit and creates a loop, allowing connections. Or they may be
ground start, where an earth ground is needed to complete the loop and allow
connectivity.The term central office is a legacy description of the local telephone company’s
termination point for all numbers in a given area, and commonly connects to
PBXs via T-1s. Historically these were centrally located and copper was run from
each building in the town to the central office.Today, a wide variety of devices
are deployed to convert copper local loops into fiber and the central office terminates
a small number of fiber pairs that service hundreds of lines.The central
office would also provide a Direct Inward Dial (DID), although such connections
are typically bi-directional today. In order to directly connect from the public
phone system to a PBX, the caller must either be manually routed to the extension
or a relationship between the extension and a public number must be established.
DID provides the latter service—a block of numbers can be assigned to a
trunk line from the telephone provider to the PBX, and the PBX administrator
can route those numbers to related extensions. Figure 1.2 illustrates the logical
configuration of number 415-555-1234 to extension 51234. Please note that it is
quite common to create five-digit extensions in North America that relate to the
assigned DID numbers.To understand the routing in the phone network, one needs to understand
Coordinated Dial Plans (CDP). (As we mentioned earlier in this section, if you
are entering the world of telephony from the Cisco router, you are no doubt
thinking Cisco Discovery Protocol for CDP.The acronym CDP stands for both
actually, depending on your perspective.) A coordinated dial plan is analogous to
addressing in IP routing—the dial plan defines what numbers exist on your network
and how callers will reach phones outside your company. (For example, acoordinated dial plan may require a nine to be dialed before an external number.)
The term call routing has two meanings, however, that overlap slightly.The first
context is the physical act of routing a call through the network. For example,
calls to 312 are destined for Chicago, which is a long-distance call requiring a
service provider beyond the PBX.The second meaning involves the act of processing
that call—there may be three alternate paths to Chicago, and, based on
availability, price, and preference, an administrator can route the call along any of
those paths.In the voice world, telecommunications services are billed at various amounts
based on the tariff involved. A flat rate structure removes per-minute charges
from the billing calculation. Other tariffs can remove distance or other parameters
from the calculation.
It is also important to consider the historical import of which end is which in
the voice world. For example, you may hear the term tip-and-ring in single pair
copper connections, which relates to which end supplies the voltage on the wire.
In the same manner, there are also foreign exchanges, which have slightly different
meanings depending on your background.For our purposes, we will describe a Foreign Exchange Station (FXS) as a link
between the switch and an extension.This term is sometimes used to describe a
connection that services an analog device within the company attached to the
PBX, such as a fax machine or modem. If you’ve worked within the phone company,
this term may be defined differently; however, this definition is best in the
context of AVVID. In contrast, a Foreign Exchange Office (FXO) link is betweenthe PBX and the central office. It is a DS-0 and analog, and it is tariffed at a flatrate.
There may be instances when local services are desired, but ISDN or T-1
bandwidths are not needed. FXO connections can be used to service these situations,
and can also be used to provide local 911 service in the event all other calls
traverse the private network to a main site in another location.
Working with Analog Systems
Analog waves, unlike digital signaling, have a range of values that represent transmitted
information.These signals are susceptible to many forms of interference,
and, visually represented, they appear as a continuous wave. Figure 1.3 illustrates a
common analog waveform.As shown, there is no absolute value within the wave—it varies as the
strength of the signal increases or decreases.This introduces one of the primary
problems with analog systems, because one must consider the introduction of
static and amplification in the waveform.To illustrate this, consider Figure 1.4.
Note that the waveform is now comprised of higher highs and lower lows,
and spikes of noise have slightly altered the waveform.The receiver will perceive
this as a change in pitch, volume, and tone, and, should this degradation continue
through multiple amplifiers and noise-prone circuits, the original waveform may
be so disrupted that communications is impossible.The phone system was originally designed to make use of limited frequencies
to transmit voice signals. As human speech consumed a very small spectrum, the
analog telephone equipment could perform the relatively simple mechanical to
electrical conversion necessary to propagate a voice over long distances.
As with record players and compact disc/DVD players, it is likely that both
analog systems and their digital counterparts will remain for some time. As such,
it is important to consider how analog systems integrate into digital environments
such as VoIP or AVVID. Simply put, such installations will require conversions
from analog to digital, and, as with old 45s, the quality and performance of the
older systems may be limited. Of course, it will also be familiar and, at a political
level, you may find reluctance in getting users off their non-VoIP systems.
In the next section we will present digital systems. It needs to be noted here,
however, that there is a way to convert from analog to digital—a conversion
addressed by a coder-decoder (CODEC).The actual conversion is effectively a
sampling of the analog stream and a digital representation of that stream. Of
course, the conversion can take the digital data and interpolate an analog waveform.
The conversion is not without potential loss, unfortunately, and it is best to
limit the number of conversions within a data flow. Recall that FXO, FXS, and
E&M are all analog connection methods.
Benefiting from Digital Systems
Digital signals are binary in nature, and are either on or off.These states are very
precise, and unlike the continuous waveform that exists in analog systems, the
signal can be regenerated with accuracy regardless of noise and interference.This
is not to infer that digital signals are impervious to noise and static, but, rather,
these problems are easily detected in a digital system and can be compensated for.
This is made possible by the absolute values transmitted on the wire. Figure 1.5
illustrates a digital waveform.Digital systems in telephony can take advantage of this binary state and augment
communications with additional features that are not available in analog
systems, including compression.This allows speech to be sent in fewer bits than in
analog format, and, in the migration to AVVID, the data stream can actually be
stopped when a party stops speaking.This can greatly increase the volume of
connections that can concurrently occur in the network. ISDN PRI is one of the
most popular digital connections.
Providing Video Services
It is atypical to include the PBX as part of a video solution; however, some
advanced PBX systems do provide video services.These connections can either
be provided over broadband technologies or by way of Ethernet, but it is more
common in many systems to use the PBX as a termination point for multiple
ISDN Basic Rate Interface (BRI) channels.The BRI can transfer 128 Kbps of
user data, and these connections can be combined, or multiplexed, to provide
higher levels of bandwidth. Many video conferencing systems work well with
384 Kbps.
In later chapters, we will discuss the technical specifics of the various protocols
in use for these connections, including the H.320 specifications, which
govern the basic concepts regarding video transmission, including audio and
video processing, and are focused on lower-bandwidth media—ISDN and 56
Kbps specifically.This protocol supports point-to-point and multipoint sessions,
and provisioning for multicast or multipoint connections is an important consideration
in the video environment.
One of the first reactions many users have to compressed video is that it isn’t
like a television picture.The image is smaller and rougher, and, while it does not
have to be so degraded, most vendors haven’t forced the additional bandwidth or
processing requirements on end users. Adaptation, it is hoped, is to be driven by
function, which, in turn, may lead to faster networks and components.This will
likely be a slow process, as evidenced by the migration to high definition television
(HDTV).
In the United States, the analog video standard is called NTSC, or National
Television System Committee. Some in the industry claim that the acronym
should stand for Never Twice Same Color, being that, compared to the European
and Asian standards, the color information is poorly interpreted from set to set.
The NTSC standard specifies a frame rate, or screen refresh rate, of 30 framesper-
second (29.97). Users of these sets are quite accustomed to the grainy picture
provided and poor color resolution, and, while HDTV has been available in various
forms for years, the FCC and other authorities are already concerned in later
2001 that their 2006 mandate for HDTV conversion will fail.Video conferencing
may fail to generate sufficient drivers to make users upgrade their systems, and
may exist in degraded form for some time. Or it may also become the next
killer-application.This conundrum is a common theme in AVVID, and will be
interesting to watch as the old world meets the new.
Audio and video systems require common protocols to define the communications
stream, and these standards can be referred to as the H.300s, G.700s, and
the T.120s, in homage to the base numbering associated with each standard.This
is in addition to the transport protocols of ISDN, Digital Subscriber Line (DSL),Plain Old Telephone System (POTS), and others.The H, G, and T standards are
administered by the International Telecommunications Union (ITU).
The most universal of these video protocols is H.320, which defines a
number of parameters including picture size and bandwidth requirements, and
will operate within point-to-point and multipoint applications.
It would be unfair to only note H.320 in a discussion of video conferencing
protocols, however. H.261, for example, specifies the compression of real-time
audio and video data, and defines a screen size of 176 x 144 pixels (Quarter
Common Intermediate Format [QCIF]) to 352 x 288 (CIF). Most of these will
fit into the bandwidth availed by ISDN. H323 is most often referred to today, and
is commonly found in many applications, including the conferencing software
provided with Microsoft Windows.
The technicalities of all of these protocols is not important at this point in a
discussion of AVVID, and subsequent chapters will elaborate on the standards
used by Cisco’s CallManager and other resources, such as the IP phones.You will
find that many of the protocols used in AVVID telephony are the same as those
used in traditional video conferencing, and, because of this, there is integration
between the voice applications of the IP phone and the more traditional video
conferencing systems such as Microsoft’s NetMeeting. For example, one can call a
NetMeeting user from a Cisco IP phone.
unto itself.You may find that many of the words and acronyms are familiar and
common if your background is based in the data world. Nevertheless, there are a
number of new terms and concepts that need to be understood before tackling the
integration of voice and data systems. In addition, some acronyms have multiple
meanings depending on whether you’re discussing voice or data. For example, the
acronym CDP, to a Cisco router guru, likely means Cisco Discovery Protocol. In the
voice world this term refers to Coordinated Dial Plan.
So, what are the common PBX terms you may encounter? Well, the first
is a T-1.A T-1 circuit is capable of carrying up to 24 voice channels (DS-0),
depending on provisioning.The total available bandwidth is 1.544 Mbps, although
the Integrated Services Digital Network (ISDN) Primary Rate Interface (PRI),
which uses T-1 framing, takes one DS-0 for upper layer signaling.The European
standard is called E-1. It provides, however, 2.048 Mbps of bandwidth, or 32 channels.
An E-1-based PRI, on the other hand, uses two of these channels for signaling
and framing, and thus, allows for 30 user-based voice channels. In addition
to the T-1 ISDN PRI , the circuit may also be configured as channel associated
signaling (CAS) or ear-and-mouth (E&M).
It is warranted to expand on ear-and-mouth technology slightly in this
forum, as E&M ports are found on the Cisco hardware platforms and many
interconnections will make use of this specification. E&M can also stand for earth
and magneto, amongst other variations, and is simply another signaling methodology.
E&M, like FXO and FXS, is an analog specification, unlike ISDN, which is
digital. In addition, FXO is available for PSTN or PBX connections, whereas
E&M is for trunk or tie lines between switches—they are network-to-network
links. As such, some Cisco installations use the VIC-2E/M interface for connections
to voice mail or legacy PBX systems. Please note that this module supports
both the two and four wire specifications of E&M for types I, II, III, and V.
These links may also be loop start, in which removing the receiver from the
hook closes a circuit and creates a loop, allowing connections. Or they may be
ground start, where an earth ground is needed to complete the loop and allow
connectivity.The term central office is a legacy description of the local telephone company’s
termination point for all numbers in a given area, and commonly connects to
PBXs via T-1s. Historically these were centrally located and copper was run from
each building in the town to the central office.Today, a wide variety of devices
are deployed to convert copper local loops into fiber and the central office terminates
a small number of fiber pairs that service hundreds of lines.The central
office would also provide a Direct Inward Dial (DID), although such connections
are typically bi-directional today. In order to directly connect from the public
phone system to a PBX, the caller must either be manually routed to the extension
or a relationship between the extension and a public number must be established.
DID provides the latter service—a block of numbers can be assigned to a
trunk line from the telephone provider to the PBX, and the PBX administrator
can route those numbers to related extensions. Figure 1.2 illustrates the logical
configuration of number 415-555-1234 to extension 51234. Please note that it is
quite common to create five-digit extensions in North America that relate to the
assigned DID numbers.To understand the routing in the phone network, one needs to understand
Coordinated Dial Plans (CDP). (As we mentioned earlier in this section, if you
are entering the world of telephony from the Cisco router, you are no doubt
thinking Cisco Discovery Protocol for CDP.The acronym CDP stands for both
actually, depending on your perspective.) A coordinated dial plan is analogous to
addressing in IP routing—the dial plan defines what numbers exist on your network
and how callers will reach phones outside your company. (For example, acoordinated dial plan may require a nine to be dialed before an external number.)
The term call routing has two meanings, however, that overlap slightly.The first
context is the physical act of routing a call through the network. For example,
calls to 312 are destined for Chicago, which is a long-distance call requiring a
service provider beyond the PBX.The second meaning involves the act of processing
that call—there may be three alternate paths to Chicago, and, based on
availability, price, and preference, an administrator can route the call along any of
those paths.In the voice world, telecommunications services are billed at various amounts
based on the tariff involved. A flat rate structure removes per-minute charges
from the billing calculation. Other tariffs can remove distance or other parameters
from the calculation.
It is also important to consider the historical import of which end is which in
the voice world. For example, you may hear the term tip-and-ring in single pair
copper connections, which relates to which end supplies the voltage on the wire.
In the same manner, there are also foreign exchanges, which have slightly different
meanings depending on your background.For our purposes, we will describe a Foreign Exchange Station (FXS) as a link
between the switch and an extension.This term is sometimes used to describe a
connection that services an analog device within the company attached to the
PBX, such as a fax machine or modem. If you’ve worked within the phone company,
this term may be defined differently; however, this definition is best in the
context of AVVID. In contrast, a Foreign Exchange Office (FXO) link is betweenthe PBX and the central office. It is a DS-0 and analog, and it is tariffed at a flatrate.
There may be instances when local services are desired, but ISDN or T-1
bandwidths are not needed. FXO connections can be used to service these situations,
and can also be used to provide local 911 service in the event all other calls
traverse the private network to a main site in another location.
Working with Analog Systems
Analog waves, unlike digital signaling, have a range of values that represent transmitted
information.These signals are susceptible to many forms of interference,
and, visually represented, they appear as a continuous wave. Figure 1.3 illustrates a
common analog waveform.As shown, there is no absolute value within the wave—it varies as the
strength of the signal increases or decreases.This introduces one of the primary
problems with analog systems, because one must consider the introduction of
static and amplification in the waveform.To illustrate this, consider Figure 1.4.
Note that the waveform is now comprised of higher highs and lower lows,
and spikes of noise have slightly altered the waveform.The receiver will perceive
this as a change in pitch, volume, and tone, and, should this degradation continue
through multiple amplifiers and noise-prone circuits, the original waveform may
be so disrupted that communications is impossible.The phone system was originally designed to make use of limited frequencies
to transmit voice signals. As human speech consumed a very small spectrum, the
analog telephone equipment could perform the relatively simple mechanical to
electrical conversion necessary to propagate a voice over long distances.
As with record players and compact disc/DVD players, it is likely that both
analog systems and their digital counterparts will remain for some time. As such,
it is important to consider how analog systems integrate into digital environments
such as VoIP or AVVID. Simply put, such installations will require conversions
from analog to digital, and, as with old 45s, the quality and performance of the
older systems may be limited. Of course, it will also be familiar and, at a political
level, you may find reluctance in getting users off their non-VoIP systems.
In the next section we will present digital systems. It needs to be noted here,
however, that there is a way to convert from analog to digital—a conversion
addressed by a coder-decoder (CODEC).The actual conversion is effectively a
sampling of the analog stream and a digital representation of that stream. Of
course, the conversion can take the digital data and interpolate an analog waveform.
The conversion is not without potential loss, unfortunately, and it is best to
limit the number of conversions within a data flow. Recall that FXO, FXS, and
E&M are all analog connection methods.
Benefiting from Digital Systems
Digital signals are binary in nature, and are either on or off.These states are very
precise, and unlike the continuous waveform that exists in analog systems, the
signal can be regenerated with accuracy regardless of noise and interference.This
is not to infer that digital signals are impervious to noise and static, but, rather,
these problems are easily detected in a digital system and can be compensated for.
This is made possible by the absolute values transmitted on the wire. Figure 1.5
illustrates a digital waveform.Digital systems in telephony can take advantage of this binary state and augment
communications with additional features that are not available in analog
systems, including compression.This allows speech to be sent in fewer bits than in
analog format, and, in the migration to AVVID, the data stream can actually be
stopped when a party stops speaking.This can greatly increase the volume of
connections that can concurrently occur in the network. ISDN PRI is one of the
most popular digital connections.
Providing Video Services
It is atypical to include the PBX as part of a video solution; however, some
advanced PBX systems do provide video services.These connections can either
be provided over broadband technologies or by way of Ethernet, but it is more
common in many systems to use the PBX as a termination point for multiple
ISDN Basic Rate Interface (BRI) channels.The BRI can transfer 128 Kbps of
user data, and these connections can be combined, or multiplexed, to provide
higher levels of bandwidth. Many video conferencing systems work well with
384 Kbps.
In later chapters, we will discuss the technical specifics of the various protocols
in use for these connections, including the H.320 specifications, which
govern the basic concepts regarding video transmission, including audio and
video processing, and are focused on lower-bandwidth media—ISDN and 56
Kbps specifically.This protocol supports point-to-point and multipoint sessions,
and provisioning for multicast or multipoint connections is an important consideration
in the video environment.
One of the first reactions many users have to compressed video is that it isn’t
like a television picture.The image is smaller and rougher, and, while it does not
have to be so degraded, most vendors haven’t forced the additional bandwidth or
processing requirements on end users. Adaptation, it is hoped, is to be driven by
function, which, in turn, may lead to faster networks and components.This will
likely be a slow process, as evidenced by the migration to high definition television
(HDTV).
In the United States, the analog video standard is called NTSC, or National
Television System Committee. Some in the industry claim that the acronym
should stand for Never Twice Same Color, being that, compared to the European
and Asian standards, the color information is poorly interpreted from set to set.
The NTSC standard specifies a frame rate, or screen refresh rate, of 30 framesper-
second (29.97). Users of these sets are quite accustomed to the grainy picture
provided and poor color resolution, and, while HDTV has been available in various
forms for years, the FCC and other authorities are already concerned in later
2001 that their 2006 mandate for HDTV conversion will fail.Video conferencing
may fail to generate sufficient drivers to make users upgrade their systems, and
may exist in degraded form for some time. Or it may also become the next
killer-application.This conundrum is a common theme in AVVID, and will be
interesting to watch as the old world meets the new.
Audio and video systems require common protocols to define the communications
stream, and these standards can be referred to as the H.300s, G.700s, and
the T.120s, in homage to the base numbering associated with each standard.This
is in addition to the transport protocols of ISDN, Digital Subscriber Line (DSL),Plain Old Telephone System (POTS), and others.The H, G, and T standards are
administered by the International Telecommunications Union (ITU).
The most universal of these video protocols is H.320, which defines a
number of parameters including picture size and bandwidth requirements, and
will operate within point-to-point and multipoint applications.
It would be unfair to only note H.320 in a discussion of video conferencing
protocols, however. H.261, for example, specifies the compression of real-time
audio and video data, and defines a screen size of 176 x 144 pixels (Quarter
Common Intermediate Format [QCIF]) to 352 x 288 (CIF). Most of these will
fit into the bandwidth availed by ISDN. H323 is most often referred to today, and
is commonly found in many applications, including the conferencing software
provided with Microsoft Windows.
The technicalities of all of these protocols is not important at this point in a
discussion of AVVID, and subsequent chapters will elaborate on the standards
used by Cisco’s CallManager and other resources, such as the IP phones.You will
find that many of the protocols used in AVVID telephony are the same as those
used in traditional video conferencing, and, because of this, there is integration
between the voice applications of the IP phone and the more traditional video
conferencing systems such as Microsoft’s NetMeeting. For example, one can call a
NetMeeting user from a Cisco IP phone.
Introduction to PBXs
The evolution of phone systems starts with the early experiments of Alexander
Graham Bell. In 1875, communication over long distances was handled by the
telegraph, a simple device that would transmit electrical pulses across a wire.
Though there is some dispute regarding Mr. Bell’s status as the inventor of the
basic telephone, he and his estate have successfully defended the original patent
on the invention. For our purposes, the transmission of sound over electricity is
what’s significant.
Early telephones were little more than extensions of this original discovery,
and party lines and local phone companies were quite common.The party line
placed a multipoint drop from the phone company to a number of homes, and
the operator would signal an incoming call by altering the ring frequency to a
custom signal (for example, one long and three short rings).These systems were
prone to the same issues as broadcast media today, especially eavesdropping.
By 1950, a human operator was needed in a more centralized fashion to service
the hundreds of phones that were installed. Human operators manually connected
calls at the physical layer by using huge switchboards, and call setup times
were very long.This system was a solid first-generation effort to link party lines
and private lines into a national network. However, many of today’s advanced
features, including conferencing, alternate billing, and voice mail were inconceivable
then.
In the last half of the twentieth century, phone technology made huge strides,
including analog switching, digital switching, trunking, and the first versions of
the modern PBX.The human operator was replaced with automated switches
that processed calls automatically, and corporations were able to provide privately
administered services that rivaled the phone company.You may recall that the
original public phone systems were virtually always installed and owned by the
government or by single corporations—a far cry from the divergent world of
today in many countries.
While the PBX remains an entrenched fixture in many organizations, like the
mainframe computer, it also gave life to the next generation of successors and
augmenters. In the mainframe world this is the personal computer, and in the
voice and PBX world this is the IP telephone. Many in the AVVID arena consider
the IP telephone a cornerstone, because it is the simplest of devices for the
end user to operate and because it integrates so well with the additional services
promised by the technology.Voice over IP (VoIP) is the common term used for
these systems. For completeness, and to simplify installation, IP was selected, as it
is the most common protocol in the current networking world.
Designing with Legacy Systems in Mind
Before you tackle the converged world of Cisco’s AVVID—even if you configure
PBX systems daily—it may be a good idea to read this chapter to renew your
understanding of what a PBX is and how it works.
However, before we enter the world of the PBX, there is a legacy system that
needs introduction.This is the key system.A key system is a multiline phone historically
found in offices with up to ten users. It is best thought of as those old,
clicking phones with the large, lit buttons.
It is possible to find such systems servicing up to 100 users, however, modern
economics and the lack of advanced features makes these installations less
common, and well-suited for replacement.
As contrasted with the PBX, these systems function by placing a single line
on more than one physical phone and, typically, a one-for-one relationship is
maintained between the number of phones and the number of outside lines. As
such, unlike the PBX, these systems do not scale to hundreds of users, nor do
they save circuit charges.
So, why do we introduce the key system before the PBX? Well, the key
system is to the PBX what, presumably, the PBX is to VoIP and AVVID.The services
provided by the key system were invaluable to companies of the mid-twentieth
century, as calls needed to be routed from one resource to another. In
addition, many PBXs today emulate the key system’s multiline presence, and this
service is available with the current offering of AVVID. As you read about the
internal functions of the PBX, consider the legacy of phone and key systems previously
described, and consider those services in the VoIP environment.
Looking Inside the PBX
A PBX consists of hardware and software designed to emulate the public telephone
system within a company, and provide paths into the Public Switched
Telephone Network (PSTN).These systems can be categorized into four primary
areas, with each area containing one or more functions:
Extension termination
Trunk termination
System logic and call processing
Switching
These functions are illustrated in Figure 1.1 and described in greater detail in
the next sections.
Implementing Extension Termination
Each resource on the private side of the PBX is commonly called an extension.
These devices have a direct, one-for-one connection to a port on the PBX.These
connections are typically digital, however, analog extensions for modems and
other services are available, and you will find that the term Foreign Exchange
Station (FXS) is commonly used for analog stations such as fax machines and
modems attached to the PBX (although this is an erroneous term). In addition,
there is a large population of PBXs attached, via analog links, to the extensions,
and while the current connections from many vendors are digital, there is
nothing wrong with the analog connections apart from the limitations of the
transport.Wiring for these connections is voice grade. However, it may include
Category-3 or Category-5, and two- or four-wire (single pair or two pair) installations
are common.The PBX must also provide these extensions with dial tone
generation, just as the public phone switch provides this service for non-PBX
attached phones.These interfaces also pass the Dual Tone Multi-Frequency
(DTMF) tones to the call processing engine that will be described shortly.
Implementing Trunk Termination
While not required, most PBX systems are connected to at least one T-1 circuit
for connectivity to either the PSTN or another PBX within the company.A
trunk is a T-1 or other type of circuit, which can carry multiple channels, or time
division multiplexed (TDM) data streams. Recall that these connections can carry
up to 24 voice connections depending on their framing and signaling. Please note
that trunks can also use the E-1 standard, which allows for 30 user channels.
Call Processing and System Logic
In addition to the user interface found on most PBX systems, there is also logic
that controls the flow of calls.The basic process is based on dialing plans, which
compare the DTMF tones to the route plans and paths configured on the PBX.
These tones represent the numeric values of the buttons, in addition to the
asterisk (*) and pound (#) keys. Using the phone number or extension dialed,
the PBX routes the call either to the external trunk (the link to the public network),
to another PBX within the company (which is carried on an internal
trunk), or to another extension within the PBX.This addressing is signaled using
the DTMF tones.
The PBX can also make decisions based on its static tables in a dynamic
fashion.You’re probably thinking this doesn’t make sense, but it does. Recall that
a PBX route plan specifies the path an outbound call should take.What would
happen if that path failed? Simply, the administrator would specify an alternate
path—analogous to a floating static route in Cisco routing.These less-preferred
routes could be configured for call overflow (where insufficient capacity exists on
the primary link) or trunk failure (where the link must completely fail before
taking an alternate path).This decision adds a dynamic to the typically static limitations
of the PBX forwarding system.
As a designer, you may specify that long-distance calls (indicated with a 9, followed
by a ten-digit number, for example) should use a trunk to long-distance
provider A, which also provides the lowest cost per minute to the company.The
alternate path, configured for overflow calls, might go to long-distance company
B, which may also charge more per call. A backup path, using the local exchange
carrier, may be configured in the event the first two paths are unusable.
The system logic and call processing functions typically include collections of
billing information and other call accounting data that can be used for capacity
planning and charge-back services.These functions are independent of the final
PBX functional area: switching.
Switching
In order to better understand the diversity of the call routing and circuit
switching processes, each is presented as a distinct element in this section. In
practice, you will likely find that the two are so inter-related as to be one. In
many systems, however, there is a difference.
Switching in the PBX system is the mapping of a channel on one interface to
another channel on another interface. For example, this may involve linking a
DS-0 to a DS-1 (T-1), or an FXS port to a T-1 trunk on another PBX.The logic
that decides which path to be taken is part of the call processing function. Once
established, however, the switching of these TDM packets is transparent to the
processor until the call is torn down.This is a significant difference between IP
networking and voice traffic, as a routing process typically takes place for each
packet—in voice, the call setup only requires processing before the call begins.
It is significant to note that, as with data networking switches, the technology
can be blocking or nonblocking and this, coupled with other factors, can greatly
impact total capacity. For example, Siemens’ blocking architecture can switch up
to 5,760 ports, while the nonblocking Intecom can switch up to 60,000 ports.
Establishing Links Outside the PBX
The systems outside the PBX are actually pretty simple once you understand the
internal systems.The voice world is made up of trunks, which interconnect public
or private switches.The basic functionality of these devices is no different for our
purposes.
However, there are a few things you should consider when thinking of
external PBX resources.These include the wide variety of phone numbers in the
international phone network, and the signaling protocol between switches in the
public network.
As you may know, calling internationally from your respective country can be
either a simple or difficult process.The administration of all the possible numbers is
also a daunting task. In either the legacy or AVVID environment, you’ll need to
work with these external-dialing plans to allow users to connect to other systems.
Consider your home telephone for a moment. In the United States, a call to
Israel would require calling 011 (the international escape code), 972 (the international
country code for Israel), 3 (the city code, similar to an area code), and the
local number, which may be six or seven digits. However, note that in some
countries, the city code may appear as 03. A call to Belarus would use a country
code of 375, and the city code and number may only contain five digits. A call
from another country to the US would require a three-digit area code and a
seven-digit number.As a PBX programmer, the system must be capable of handling
all the digits provided and routing the call to the correct destination.
Now, with the home phone, the routing of the call is simple—the phone
company takes care of it! But, when we enter the PBX, we may have multiple
paths to consider.Though this can become very complex, the basics might
involve the use of private links between systems (tie lines). Consider the United
States to Israel example again. It may be cheaper to route calls from Denver to Tel
Aviv through the private tie line terminating in Jerusalem rather than the public
network, and, although unlikely, it may be cheaper still to route calls for Mozyr,
Belarus, from Denver to Tel Aviv to Mozyr.This dialing plan addresses two factors:
call routing and call tariffing.
However, let’s presume our call to Mozyr is cheaper using the public network
and employing a link between New York and London. How does the network
understand our call and establish a path between Denver and Mozyr?
Well, this is the second point of external systems.The switches in the network
need to signal each other using a common protocol. In many networks, this protocol
is called Signaling System 7 (SS7).
Data network designers are probably used to in-band signaling, where the IP
address is part of each packet. No such mechanism exists in voice networks.
Rather, the signaling is out-of-band, or independent of the actual data. SS7 is
used between the switches to provide this dialog, and, in our call to Mozyr, the
Denver phone company switch might use SS7 to signal a path from Denver to
Chicago, and another link from Chicago to New York. Once the path is built
using SS7, a voice link is established and the call commences. Please note that this
does not occur with the PBX private connection to Jerusalem, as this is in-network,
and SS7 is typically not used in private switch-to-switch communications.
Graham Bell. In 1875, communication over long distances was handled by the
telegraph, a simple device that would transmit electrical pulses across a wire.
Though there is some dispute regarding Mr. Bell’s status as the inventor of the
basic telephone, he and his estate have successfully defended the original patent
on the invention. For our purposes, the transmission of sound over electricity is
what’s significant.
Early telephones were little more than extensions of this original discovery,
and party lines and local phone companies were quite common.The party line
placed a multipoint drop from the phone company to a number of homes, and
the operator would signal an incoming call by altering the ring frequency to a
custom signal (for example, one long and three short rings).These systems were
prone to the same issues as broadcast media today, especially eavesdropping.
By 1950, a human operator was needed in a more centralized fashion to service
the hundreds of phones that were installed. Human operators manually connected
calls at the physical layer by using huge switchboards, and call setup times
were very long.This system was a solid first-generation effort to link party lines
and private lines into a national network. However, many of today’s advanced
features, including conferencing, alternate billing, and voice mail were inconceivable
then.
In the last half of the twentieth century, phone technology made huge strides,
including analog switching, digital switching, trunking, and the first versions of
the modern PBX.The human operator was replaced with automated switches
that processed calls automatically, and corporations were able to provide privately
administered services that rivaled the phone company.You may recall that the
original public phone systems were virtually always installed and owned by the
government or by single corporations—a far cry from the divergent world of
today in many countries.
While the PBX remains an entrenched fixture in many organizations, like the
mainframe computer, it also gave life to the next generation of successors and
augmenters. In the mainframe world this is the personal computer, and in the
voice and PBX world this is the IP telephone. Many in the AVVID arena consider
the IP telephone a cornerstone, because it is the simplest of devices for the
end user to operate and because it integrates so well with the additional services
promised by the technology.Voice over IP (VoIP) is the common term used for
these systems. For completeness, and to simplify installation, IP was selected, as it
is the most common protocol in the current networking world.
Designing with Legacy Systems in Mind
Before you tackle the converged world of Cisco’s AVVID—even if you configure
PBX systems daily—it may be a good idea to read this chapter to renew your
understanding of what a PBX is and how it works.
However, before we enter the world of the PBX, there is a legacy system that
needs introduction.This is the key system.A key system is a multiline phone historically
found in offices with up to ten users. It is best thought of as those old,
clicking phones with the large, lit buttons.
It is possible to find such systems servicing up to 100 users, however, modern
economics and the lack of advanced features makes these installations less
common, and well-suited for replacement.
As contrasted with the PBX, these systems function by placing a single line
on more than one physical phone and, typically, a one-for-one relationship is
maintained between the number of phones and the number of outside lines. As
such, unlike the PBX, these systems do not scale to hundreds of users, nor do
they save circuit charges.
So, why do we introduce the key system before the PBX? Well, the key
system is to the PBX what, presumably, the PBX is to VoIP and AVVID.The services
provided by the key system were invaluable to companies of the mid-twentieth
century, as calls needed to be routed from one resource to another. In
addition, many PBXs today emulate the key system’s multiline presence, and this
service is available with the current offering of AVVID. As you read about the
internal functions of the PBX, consider the legacy of phone and key systems previously
described, and consider those services in the VoIP environment.
Looking Inside the PBX
A PBX consists of hardware and software designed to emulate the public telephone
system within a company, and provide paths into the Public Switched
Telephone Network (PSTN).These systems can be categorized into four primary
areas, with each area containing one or more functions:
Extension termination
Trunk termination
System logic and call processing
Switching
These functions are illustrated in Figure 1.1 and described in greater detail in
the next sections.
Implementing Extension Termination
Each resource on the private side of the PBX is commonly called an extension.
These devices have a direct, one-for-one connection to a port on the PBX.These
connections are typically digital, however, analog extensions for modems and
other services are available, and you will find that the term Foreign Exchange
Station (FXS) is commonly used for analog stations such as fax machines and
modems attached to the PBX (although this is an erroneous term). In addition,
there is a large population of PBXs attached, via analog links, to the extensions,
and while the current connections from many vendors are digital, there is
nothing wrong with the analog connections apart from the limitations of the
transport.Wiring for these connections is voice grade. However, it may include
Category-3 or Category-5, and two- or four-wire (single pair or two pair) installations
are common.The PBX must also provide these extensions with dial tone
generation, just as the public phone switch provides this service for non-PBX
attached phones.These interfaces also pass the Dual Tone Multi-Frequency
(DTMF) tones to the call processing engine that will be described shortly.
Implementing Trunk Termination
While not required, most PBX systems are connected to at least one T-1 circuit
for connectivity to either the PSTN or another PBX within the company.A
trunk is a T-1 or other type of circuit, which can carry multiple channels, or time
division multiplexed (TDM) data streams. Recall that these connections can carry
up to 24 voice connections depending on their framing and signaling. Please note
that trunks can also use the E-1 standard, which allows for 30 user channels.
Call Processing and System Logic
In addition to the user interface found on most PBX systems, there is also logic
that controls the flow of calls.The basic process is based on dialing plans, which
compare the DTMF tones to the route plans and paths configured on the PBX.
These tones represent the numeric values of the buttons, in addition to the
asterisk (*) and pound (#) keys. Using the phone number or extension dialed,
the PBX routes the call either to the external trunk (the link to the public network),
to another PBX within the company (which is carried on an internal
trunk), or to another extension within the PBX.This addressing is signaled using
the DTMF tones.
The PBX can also make decisions based on its static tables in a dynamic
fashion.You’re probably thinking this doesn’t make sense, but it does. Recall that
a PBX route plan specifies the path an outbound call should take.What would
happen if that path failed? Simply, the administrator would specify an alternate
path—analogous to a floating static route in Cisco routing.These less-preferred
routes could be configured for call overflow (where insufficient capacity exists on
the primary link) or trunk failure (where the link must completely fail before
taking an alternate path).This decision adds a dynamic to the typically static limitations
of the PBX forwarding system.
As a designer, you may specify that long-distance calls (indicated with a 9, followed
by a ten-digit number, for example) should use a trunk to long-distance
provider A, which also provides the lowest cost per minute to the company.The
alternate path, configured for overflow calls, might go to long-distance company
B, which may also charge more per call. A backup path, using the local exchange
carrier, may be configured in the event the first two paths are unusable.
The system logic and call processing functions typically include collections of
billing information and other call accounting data that can be used for capacity
planning and charge-back services.These functions are independent of the final
PBX functional area: switching.
Switching
In order to better understand the diversity of the call routing and circuit
switching processes, each is presented as a distinct element in this section. In
practice, you will likely find that the two are so inter-related as to be one. In
many systems, however, there is a difference.
Switching in the PBX system is the mapping of a channel on one interface to
another channel on another interface. For example, this may involve linking a
DS-0 to a DS-1 (T-1), or an FXS port to a T-1 trunk on another PBX.The logic
that decides which path to be taken is part of the call processing function. Once
established, however, the switching of these TDM packets is transparent to the
processor until the call is torn down.This is a significant difference between IP
networking and voice traffic, as a routing process typically takes place for each
packet—in voice, the call setup only requires processing before the call begins.
It is significant to note that, as with data networking switches, the technology
can be blocking or nonblocking and this, coupled with other factors, can greatly
impact total capacity. For example, Siemens’ blocking architecture can switch up
to 5,760 ports, while the nonblocking Intecom can switch up to 60,000 ports.
Establishing Links Outside the PBX
The systems outside the PBX are actually pretty simple once you understand the
internal systems.The voice world is made up of trunks, which interconnect public
or private switches.The basic functionality of these devices is no different for our
purposes.
However, there are a few things you should consider when thinking of
external PBX resources.These include the wide variety of phone numbers in the
international phone network, and the signaling protocol between switches in the
public network.
As you may know, calling internationally from your respective country can be
either a simple or difficult process.The administration of all the possible numbers is
also a daunting task. In either the legacy or AVVID environment, you’ll need to
work with these external-dialing plans to allow users to connect to other systems.
Consider your home telephone for a moment. In the United States, a call to
Israel would require calling 011 (the international escape code), 972 (the international
country code for Israel), 3 (the city code, similar to an area code), and the
local number, which may be six or seven digits. However, note that in some
countries, the city code may appear as 03. A call to Belarus would use a country
code of 375, and the city code and number may only contain five digits. A call
from another country to the US would require a three-digit area code and a
seven-digit number.As a PBX programmer, the system must be capable of handling
all the digits provided and routing the call to the correct destination.
Now, with the home phone, the routing of the call is simple—the phone
company takes care of it! But, when we enter the PBX, we may have multiple
paths to consider.Though this can become very complex, the basics might
involve the use of private links between systems (tie lines). Consider the United
States to Israel example again. It may be cheaper to route calls from Denver to Tel
Aviv through the private tie line terminating in Jerusalem rather than the public
network, and, although unlikely, it may be cheaper still to route calls for Mozyr,
Belarus, from Denver to Tel Aviv to Mozyr.This dialing plan addresses two factors:
call routing and call tariffing.
However, let’s presume our call to Mozyr is cheaper using the public network
and employing a link between New York and London. How does the network
understand our call and establish a path between Denver and Mozyr?
Well, this is the second point of external systems.The switches in the network
need to signal each other using a common protocol. In many networks, this protocol
is called Signaling System 7 (SS7).
Data network designers are probably used to in-band signaling, where the IP
address is part of each packet. No such mechanism exists in voice networks.
Rather, the signaling is out-of-band, or independent of the actual data. SS7 is
used between the switches to provide this dialog, and, in our call to Mozyr, the
Denver phone company switch might use SS7 to signal a path from Denver to
Chicago, and another link from Chicago to New York. Once the path is built
using SS7, a voice link is established and the call commences. Please note that this
does not occur with the PBX private connection to Jerusalem, as this is in-network,
and SS7 is typically not used in private switch-to-switch communications.
Subscribe to:
Posts (Atom)