Migrating to an IP Telephony Network

Network Models

PBX and Voice Messaging Interfaces and Protocols

Simple IP Network Migration Sequence

Reference Models for Migration Configurations

Detailed Discussion of Model A

Detailed Discussion of Model B

Detailed Discussion of Model C

Detailed Discussion of Model D

Migrating to an IP Telephony Network

This chapter explains how an enterprise can migrate from a conventional PBX and its adjunct systems, principally voice messaging, to an IP telephony network. Four migration models are presented, encompassing various feature sets, and the steps for achieving each are outlined.

This chapter contains the following major sections:

Network Models

Conventional voice networks to be migrated to IP networks contain, at a minimum, a single PBX and often a number of PBXs, which can be geographically dispersed. A network of PBXs can use a specialized, proprietary networking protocol to provide features across the different PBXs.

If voice messaging is a part of the voice network, the voice messaging systems are connected to the PBX using a protocol and hardware interface. If there are a number of voice messaging systems in the network, they might be networked to appear to the user as a single messaging system. Generally the protocols used to connect to and network between voice messaging systems are proprietary. See Figure 11-1.

Figure 11-1: Closed Versus Open Protocols in a Voice Network

PBX and Voice Messaging Interfaces and Protocols

When an IP network is introduced into this environment, the users on the IP network are generally able to use IP features when calling other IP network users. Similarly, PBX users can use the features provided by the PBX when calling other PBX users. However, calls between IP and PBX users can use only a subset of the features provided by each system, and that subset is defined by the level of complexity of the voice interface between the IP network and the PBX. Similarly, IP network users can access a voice messaging system behind the PBX, but usually with a reduced set of features. If IP messaging is used, you might be able to network it with the conventional voice messaging system to some degree. The level of feature support for all these functions is defined by the protocols and interfaces by which the IP network can connect to the conventional voice network.

Table 11-1 summarizes some of the more commonly used interfaces and protocols for PBX and voice mail system networking.

Table 11-1: Interfaces and Protocols for PBX and Voice Mail System Networking

Vendor PBX-PBX Protocols PBX-Voice Mail Interfaces Voice Mail-Voice Mail Networking

Cisco

PRI, QSID, CAS

SMDI, analog

AMIS-A¹

Lucent

PRI, DCS, DCS+, QSIG

Digital set emulation

Proprietary, X.25 based

Octelnet

Digitalnet

AMIS-A

Northern Telecom

PRI, MCDN, DPNSS, QSIG

Proprietary (IVMS)

Meridian Mail network

VPIM

AMIS-A

Siemens

PRI, Cornet, DPNSS, QSIG

BRI with proprietary extensions

PhoneMail networking

AMIS-A

Alcatel

PRI, ABC, QSIG

?

?

NEC

PRI, CCIS, QSIG

?

?

¹Cisco supports AMIS-A on uOne beginning with release 5.0E.

Vendor	PBX-PBX Protocols	PBX-Voice Mail Interfaces	Voice Mail-Voice Mail Networking
Cisco	PRI, QSID, CAS	SMDI, analog	AMIS-A¹
Lucent	PRI, DCS, DCS+, QSIG	Digital set emulation Proprietary, X.25 based	Octelnet Digitalnet AMIS-A
Northern Telecom	PRI, MCDN, DPNSS, QSIG	Proprietary (IVMS)	Meridian Mail network VPIM AMIS-A
Siemens	PRI, Cornet, DPNSS, QSIG	BRI with proprietary extensions	PhoneMail networking AMIS-A
Alcatel	PRI, ABC, QSIG	?	?
NEC	PRI, CCIS, QSIG	?	?

While conventional voice networks use proprietary, closed protocols internally, they can be connected to IP networks only through open protocols. This would also be the case when networking equipment from different vendors. PRI (or QSIG) between PBXs, analog Simplified Message Desk Interface (SMDI) between PBXs and voice mail systems, and Audio Messaging Interchange Specification (AMIS) between voice systems are the most powerful interfaces available.

Simple IP Network Migration Sequence

The following three figures illustrate the phases in migrating from a conventional voice network to an all-IP system. Figure 11-2 shows the initial conventional voice network.

Figure 11-2: Initial Conventional Voice Network

Figure 11-3 shows the migration phase, with users moving in blocks from PBX to IP network.

Figure 11-3: Migration Phase

Figure 11-4 shows the network when migration is completed and the PBX is retired.

Figure 11-4: Migration Completed

Usually the transition from a conventional voice network to an IP network is made in stages, as follows:

Step 1 Pilot stage --- the IP network is introduced, and a very limited number of users are given IP service. In this initial deployment, which often will include the telecom or IT group, users sometimes retain their conventional phones side-by-side the with IP phones. Usually, however, they move immediately onto the new system. When the pilot trial is stable and satisfactory for a number of weeks, it can be expanded.

Step 2 User block migration --- a block of users is moved (usually over a weekend) from the conventional voice network to the IP network. The block can be chosen as a geographical group, a group sharing a block of directory numbers (DNs), or a community of interest, such as the purchasing department.

Step 3 Further user block migration --- the number of users moved in a block is determined by the maximum number of users the telecom staff can move over a weekend, and the number of weekends the telecom department is prepared to work. In general, migration should be completed as quickly as possible.

Of course there are many other considerations when planning a migration, such as whether users will keep their DNs or be assigned new ones, user training, billing systems, special features, fallback plans, and more.

Reference Models for Migration Configurations

This section considers four basic migration configurations. These models are depicted in Figure 11-5.

Figure 11-5: Migration Models

The models shown in Figure 11-5 have the following characteristics:

Model A is the simplest; it is concerned only with PBX services and does not address voice messaging.
Model B includes a voice messaging system behind the PBX and assumes that the voice mail system does not offer an open interface for connection to an IP network. Therefore, all voice mail traffic from the IP network must travel through the PBX.
Model C includes a voice messaging system that can connect to an IP network, providing a stronger feature set for IP users.
Model D introduces unified IP messaging at the same time as IP telephony, replacing a conventional PBX and voice mail combination.

Detailed Discussion of Model A

Figure 11-6 shows the topology for model A, which includes a PBX but no voice messaging.

Figure 11-6: Migration Model A --- PBX Only

Model A poses two main questions for consideration:

Should the trunk connections remain on the PBX until the end of the migration, or should some trunks be moved to the IP network along with users?
What type of connection should be used between the PBX and the IP network?

Table 11-2 shows the feature set supported by each type of connection.

Table 11-2: Connection Types and Feature Sets Supported

Connection Type Calling
Number Called Number Calling
Name Diversion
Reason MWI¹
On/Off Both-Ways
Origination Relative
Cost

FXO/FXS

N

Y

N

N

N

N

Tiny

E&M/R2

N

Y

N

N

N

Y

Small

BRI/PRI

Y

Y

Y

N

N

Y

Medium to Large

QSIG

Y

Y

Y

Y

Y

Y

Large

Digital set emulation

Y

Y

Y

Y

N

Y

Medium

PBX WAN protocol

Y

Y

Y

Y

Y

Y

Large

¹MWI = Message waiting indicator

Connection Type	Calling Number	Called Number	Calling Name	Diversion Reason	MWI¹ On/Off	Both-Ways Origination	Relative Cost
FXO/FXS	N	Y	N	N	N	N	Tiny
E&M/R2	N	Y	N	N	N	Y	Small
BRI/PRI	Y	Y	Y	N	N	Y	Medium to Large
QSIG	Y	Y	Y	Y	Y	Y	Large
Digital set emulation	Y	Y	Y	Y	N	Y	Medium
PBX WAN protocol	Y	Y	Y	Y	Y	Y	Large

The following points briefly explain the importance of the features in Table 11-2:

Calling number, in addition to being displayed on the called phone, can be used for billing and voice mail purposes.
Called number is important if the receiving switch is going to route the call directly to a phone, rather than terminating first at an attendant. The called number is also used for voice mail.
Calling name is displayed on the called phone.
Diversion reason (busy, ring-no-answer) can be used by voice mail systems to play different greetings.
MWI on/off can instruct the receiving switch to illuminate the message waiting indicator on a phone when the user has a new message. Without this capability on the link, MWI cannot be available on the switch remote from the voice messaging system.
Both-ways origination refers to the capability to initiate and answer a call on the same trunk. This would normally be desirable for traffic purposes to avoid the need for more trunk connections.

Note QSIG is not available in Cisco CallManager Release 3.0. PRI provides the best feature set currently available.

Table 11-2 indicates which elements are normally passed across the trunk interface. Different PBXs, however, might not use the information to implement all available features for a given trunk type. Table 11-3 provides an approximate guide to feature availability when using PRI.

Table 11-3: Feature Availability with PRI

Feature PBX-PBX IP-IP IP-PBX

Transfer

Y

Y

Y (on originator's system)

Conference

Y

Y

Y (on originator's system)

Calling number display

Y

Y

Y (can depend on PBX configuration)

Calling name display

Y

Y

Y

Called name display

Y

Y

N

Call pickup groups

Y

Y

N

Music on hold

Y

N

N (no music when Cisco AVVID puts the call on hold)

Camp-on features

Y

N

N

Operator services

Y

N

N (unless a separate Cisco AVVID attendant is configured)

Feature	PBX-PBX	IP-IP	IP-PBX
Transfer	Y	Y	Y (on originator's system)
Conference	Y	Y	Y (on originator's system)
Calling number display	Y	Y	Y (can depend on PBX configuration)
Calling name display	Y	Y	Y
Called name display	Y	Y	N
Call pickup groups	Y	Y	N
Music on hold	Y	N	N (no music when Cisco AVVID puts the call on hold)
Camp-on features	Y	N	N
Operator services	Y	N	N (unless a separate Cisco AVVID attendant is configured)

If calls originate on one system, are passed to the other and then forwarded back, two channels are used on the PRI and remain in use (tromboned) until the call is torn down. The implication for traffic engineering in a T1 environment is that only 11 such calls could use the entire PRI link.

If the trunks remain on the PBX so that billing can be done at one point, it can be difficult to identify IP-originated calls by calling number.

The following configuration steps are required for the type A system:

Step 1 Configure the PRI link.

a. Add PRI gateway in Cisco CallManager and configure.

b. Add PBX PRI card, cable to IP network, and configure PRI on PBX.

c. Add Cisco CallManager route group to steer outgoing calls to the PRI trunk.

Step 2 Migrate each user.

a. Delete phone in PBX.

b. Modify PBX trunk routes to steer user calls to the IP network.

c. Add user phones in Cisco CallManager.

Step 3 Move PSTN trunks from PBX to IP network.

a. Delete trunks and routes from the PBX database.

b. Add trunk groups on the PBX to steer outgoing calls the IP network.

c. Configure IP gateway hardware and software.

d. Move trunk connections to IP network.

e. Configure trunk groups and routes in Cisco CallManager.

f. Configure Call Detail Recording (CDR) for the IP network.

This configuration scenario assumes that users retain the same DNs after the migration and that trunks are moved after the users have migrated. Otherwise it would be possible to preconfigure the IP phones and to allow users to have two working phones on their desks throughout the migration period. However, most users with Direct Inward Dialing (DID) service want to keep their original DN.

The following list summarizes the cost of the type A system:

Hardware Software

PRI gateway for IP network.

PRI card on PBX.

Nothing extra on Cisco CallManager.

PRI software on PBX.

The following list summarizes the pros and cons of the type A system:

Pros Cons

Easy and inexpensive to implement.

Minimal reconfiguration of the PBX is needed.

Without QSIG, display set users in particular will notice a lack of feature support on IP-PBX calls.

Billing is difficult to reconcile across the two systems.

Detailed Discussion of Model B

Figure 11-7 shows the topology for model B, which includes both a PBX and voice messaging.

Figure 11-7: Migration Model B --- PBX with Voice Messaging

The considerations for telephony features in model B are the same as for model A, but the introduction of voice messaging brings a number of extra considerations. In general, voice messaging systems provide call answering and call retrieval services. They also command the PBX to switch message waiting indicators on and off, and can provide outcalling services where users can transfer themselves out of a voice mailbox to another phone. (This feature is also a function for automated attendant functions, which are often built into voice messaging systems.)

There are three important requirements for IP telephony applications in model B networks:

When a party calls an IP phone and the call is forwarded to voice mail, the caller should hear the IP user's greeting for call answering. This can be a problem, since if the PBX sees the call from the IP network as a trunk call, it might not preserve the original called number on the call. In this case the caller would hear the general greeting (for example, "Welcome to Cisco").
When IP users press their message key, they should be prompted for their password. That is, the voice messaging system should be passed the information to associate the call with a user's calling number to identify the right mailbox.
The MWI on the IP phone should be switched on and off to reflect the state of the user's voice mailbox.

In general, none of these three features can be achieved in a simple type B system, where the link between the IP network and the PBX is PRI, and the configuration sequence for a type A system is used. However, by using a more complex configuration change on the PBX, the first two features can be achieved.

This model B implementation essentially requires configuring a phantom telephone user on the PBX. For ease of maintenance, it is convenient to choose a block of DNs that relate to the IP user's DN. For example, for IP DNs 32XX, create equivalent PBX phantom users of 52XX. The phantom phone is permanently forwarded to voice messaging. On the IP network, the phone is configured to forward to the phantom DN for voice messaging, with a speed-dial key on the phone to dial the phantom DN. This key can be labeled for voice messaging (except on the Cisco IP Phone 7960). Now both call answering and message retrieval calls go straight to the user's voice mailbox.

There are drawbacks with this workaround. It requires extra administration and user effort, and the IP user's voice mailbox must have a different number from the DN of the phone. Also, on some PBXs, it is necessary to configure real line cards for the phantom phones. Perhaps it would be easier to administer if the user's PBX DN were retained on the PBX as the phantom DN during migration, and the user could be assigned a new DN on the IP network. The original DID (DDI) could be retained if the trunks are switched to the IP network and an incoming digit translation is used. However, this would perpetuate a situation in which the user's DN, DID (DDI), and voice mailbox number do not match.

It is not possible for the voice messaging system to select the proper greeting ("busy", "no answer," or "all calls") for IP users because that information is not sent across the PRI to the PBX.

It is also not possible for MWI information to traverse the PRI from the PBX to the IP network. The message indication feature would, therefore, not be available to IP users in a type B system.

The following configuration steps for the type B system include the workaround just described:

Step 1 Configure PRI link --- same as for type A system.

Step 2 Migrate each user --- same as for type A system.

Step 3 Configure the phantom DN on the PBX.

a. Add the phone to the PBX and forward to voice mail.

b. Configure speed-dial key on IP phone.

c. Modify the IP trunk routes to send forwarded calls to PBX.

Step 4 Move PSTN trunks from PBX to IP network --- same as for type A system.

The following list summarizes the cost of the type B system:

Hardware Software

PRI gateway for IP network.

PRI card on PBX.

Nothing extra on Cisco CallManager.

PRI software on PBX.

The following list summarizes the pros and cons of the type B system:

Pros Cons

IP users get access to voice messaging as they migrate from the PBX.

Relatively inexpensive to implement.

Same voice feature shortfall as type A systems.

No MWI support for IP users.

Workaround entails administration complexity and possibly PBX hardware.

Detailed Discussion of Model C

Figure 11-8 shows the topology for model C, which includes a PBX and voice messaging, with extra SMDI and analog links from the voice messaging system directly to the IP network.

Figure 11-8: Model C --- PBX and Voice Messaging System with Separate Links to the IP Network

The considerations for telephony features for model C are the same as for model A.

For voice messaging, model C fixes the drawbacks of model B. Because the voice messaging system deals with the PBX and the IP network as separate systems, calls that reach the IP network can be forwarded directly into voice messaging without being routed back through the PBX. This should allow all normal call answering and message retrieval functions. In addition, since the voice messaging system is connected to the IP network directly with SMDI, the voice messaging system can send MWI on or off messages to the IP network for appropriate control of the indicators on the IP phones.

For this model to work, the voice messaging system must meet two qualifications. First, it must be able to support two PBXs simultaneously in its database and associate each mailbox with the correct PBX so that it can send MWI information on the correct link. And second, it must be possible to connect the IP network physically to the voice messaging system while maintaining the existing link to the PBX. Not all voice messaging systems can support this type of integration.

The following configuration steps are required for the type C system:

Step 1 Configure PRI link --- same as for type A system.

Step 2 Migrate each user --- same as for type A system.

Step 3 Migrate each user in voice mail --- change the mailbox to reference the link to the IP network rather than the PBX.

Step 4 Move PSTN trunks from PBX to IP network --- same as for type A system.

Note Dual integration has currently been verified only on the Octel Aria 250 and 350 systems.

The following list summarizes the cost of the type C system:

Hardware Software

PRI gateway for IP network.

PRI card on PBX.

Analog gateways for IP network for voice messaging.

Analog cards on voice messaging system.

SMDI interface on voice messaging system.

Nothing extra on Cisco CallManager.

PRI software on PBX.

The following list summarizes the pros and cons of the type C system:

Pros Cons

IP users get access to voice messaging as they migrate from the PBX.

Relatively inexpensive to implement.

Same voice feature shortfall as type A systems.

More complex administration of voice messaging system than the type B system, but simpler administration of the PBX.

Ideally, DID (DDI) trunks would be moved from PBX to IP network to follow the users. Otherwise, some features might be lost.

Detailed Discussion of Model D

Figure 11-9 shows the topology for model D, which includes a PBX with voice messaging system that migrates to an IP network with uOne unified messaging. The discussion of this model considers only the voice messaging component of uOne.

Figure 11-9: Model D --- PBX with Voice Messaging and Migration to uOne Messaging

The considerations for telephony features for model D are the same as for model A.

For voice messaging, IP users are on the uOne system, while the PBX users remain on the voice messaging system. When a PBX user is moved to the IP network, the voice mailbox is deleted from the voice messaging system and a new one is added on uOne.

Since there is no linking between uOne and the voice messaging system, the two user groups are separate and cannot interact in voice messaging. For instance, if a voice messaging user has a distribution list, IP users cannot be included on it. Similarly, the "reply to sender" function does not work between the two groups, nor do a number of other features. If the voice messaging system is to be replaced by uOne, however, then this situation is only temporary.

Audio Messaging Interchange Specification Analog (AMIS-A) networking of voice messaging systems is planned for a future release of uOne. When it is available, if both uOne and the voice messaging system are configured for networking, then it will be possible to provide basic voice mail functionality across the systems (provided the voice messaging system supports AMIS-A).

The following configuration steps are required for the type D system:

Step 1 Configure PRI link --- same as for type A system.

Step 2 Migrate each user --- same as for type A system.

Step 3 Migrate each user in voice mail.

a. Delete mailbox on voice messaging system.

b. Add user in uOne.

Step 4 Move PSTN trunks from PBX to IP network --- same as for type A system.

The following list summarizes the cost of the type D system:

Hardware Software

PRI gateway for IP network.

PRI card on PBX.

Nothing extra on Cisco CallManager.

PRI software on PBX.

The following list summarizes the pros and cons of the type D system:

Pros Cons

IP users get access to voice messaging as they migrate from the PBX.

Relatively inexpensive to implement.

Same voice feature shortfall as type A systems.

No voice mail interaction between voice messaging and uOne.

Ideally, DID (DDI) trunks would be moved from PBX to IP network to follow the users. Otherwise, some features might be lost.

Hardware	Software
PRI gateway for IP network. PRI card on PBX.	Nothing extra on Cisco CallManager. PRI software on PBX.

Pros	Cons
Easy and inexpensive to implement. Minimal reconfiguration of the PBX is needed.	Without QSIG, display set users in particular will notice a lack of feature support on IP-PBX calls. Billing is difficult to reconcile across the two systems.

Pros	Cons
IP users get access to voice messaging as they migrate from the PBX. Relatively inexpensive to implement.	Same voice feature shortfall as type A systems. No MWI support for IP users. Workaround entails administration complexity and possibly PBX hardware.

Table of Contents

Migrating to an IP Telephony Network