Cisco.IP.Telephony.Planning.Design.Implementation.Operation.and.Optimization [Electronic resources] نسخه متنی

Integrating Voice Mail

XYZ requires voice-mail integration at two locations:

The CallManager in Sydney

The Octel system with CallManager in San Jose

Unity Integration with CallManager

Unity integrates seamlessly with CallManager by using SCCP. The next few sections discuss the configurations required to complete the Unity integration with CallManager.

Configuring partitions and CSS in CallManager

Changing service parameters in CallManager

Defining MWI on and off numbers in CallManager

Defining voice-mail ports in CallManager

Defining the voice-mail pilot number in CallManager

Defining the voice-mail profile in CallManager

Reserving ports for MWIs and outcall notifications in Unity

Making changes to the Octel access numbers

Configuring the AutoAttendant functionality in Unity

Configuring Partitions and CSS in CallManager

This section discusses the design of partitions and the calling search space (CSS) for voice-mail ports, MWI On/Off numbers, and voice-mail pilot numbers. Because voice-mail ports appear to CallManager as any other IP phone, the concept of partitions and CSS also applies to these ports. Unity uses voice-mail ports for two purposes:

To turn on and off MWI lamps on the phones

To send call notifications

Tables 7-2 and 7-3 list the partitions and CSS configurations, respectively, required on IP Phones, MWI On/Off numbers, and voice-mail ports in the Sydney CallManager cluster.

^[1] Directory Number

Changing Service Parameters in CallManager

By default, CallManager hops to a maximum of 12 voice-mail ports. Because the Unity system at XYZ has 32 ports, the following two service parameters for CallManager service have to be set on the Sydney CallManager cluster accordingly. To access the service parameters, from the CallManager Administration page, choose Service > Service Parameters > CallManager Service.

Set the Voice Mail Maximum Hop Count to 28 (because XYZ has a maximum of 32 ports, the last 4 of which are assigned to MWI and Outcall notifications).

Set the Advanced CallForward Hop Flag to True (to immediately jump to the first available port).

Both parameters are cluster-wide parameters.

Defining MWI On and Off Numbers in CallManager

An MWI lamp lighted on the IP Phone indicates to the user that new voice-mail messages are waiting in the mailbox. Before you define the MWI On/Off numbers, it is helpful to understand how Unity and CallManager turn on/off MWI lamps on the phones. To turn on the MWI for extension 6200, for example, Unity goes off hook on one of its ports and dials the MWI On number. However, Unity sets the calling party extension as 6200. CallManager looks at the calling party number and lights the lamp for extension 6200. Similarly, to turn MWI off, Unity dials the MWI Off number.

Hence, you need one MWI On and one MWI Off number per CallManager cluster. To define these numbers in the CallManager from the CallManager Administration page, choose Feature > Voice Mail > Message Waiting. On this page, you have an option to configure a partition and CSS for MWI On and Off numbers. Table 7-4 shows the configuration settings for the MWI On/Off numbers in the Sydney CallManager cluster.

The CSS on the MWI On/Off numbers helps CallManager to determine which phones' MWI to turn on and off. Assume that two phones with the same directory number 6200 exist, one in Partition_X and the other in Partition_Y. If the CSS for the MWI On/Off numbers contains Partition_X alone, it can turn on and off the MWI for the phone with extension 6200, which is in Partition_X. The opposite is true if the CSS includes only Partition_Y. If the CSS contains both partitions, the partition order that is defined in the CSS comes into effect, because there is a tie in the pattern, which in this case is 6200. Hence, the rule is that the CSS on the MWI On/Off numbers should include the partitions in which IP Phone directory numbers reside.

As mentioned earlier, Unity goes off hook on one of the voice-mail ports and dials the MWI On/Off number to turn on or off the MWI lamp. This means the following:

The CSS that is configured on the voice-mail ports should include the partition in which MWI On/Off numbers reside. Without this, Unity cannot set the MWI On/Off for the phones.

The CSS that is configured on the IP Phones should also include the partition in which MWI On/Off numbers reside.

Defining Voice-Mail Ports in CallManager

To configure the voice-mail ports in CallManager, you can use the Voice Mail Port Wizard that is available specifically for Unity. To access this wizard from the CallManager Administration page, choose Feature > Voice Mail > Cisco Voice Mail Port Wizard.

As stated in the "Sizing Unity Ports and Sessions" section earlier in this chapter, the Unity system at XYZ requires 32 ports. Hence, the number of ports that has to be configured on the CallManager is 64: 32 for the primary Unity server and 32 for the failover Unity server. Each set of ports matches to a voice-mail pilot number. The primary Unity server uses the same voice-mail pilot number as used in the past for the Octel system in Sydney, which is 5000.

Multiple Directory Handlers" section later in this chapter to play the opening greeting for the Sydney office.

The voice-mail pilot number on the primary server is in a different partition compared to the other voice-mail ports. The partition pt_vmpilot1 is not visible to any other device, which means that users cannot dial these ports directly from their phones. This gives the impression of a single voice-mail number to the whole system. The partition pt_vmpilot1 will only be part of the CSS that is configured on the CFB and CFNA on the voice-mail ports.

The CFB and CFNA on the last two voice-mail ports on the secondary server are set to forward to the operator (60002). In Table 7-5, Unity Ports 1 to 28 (thatr is. ports PriUM-VI1 through PriUM-VI28 on the primary server and ports SecUM-VI1 through SecUM-VI28 on the secondary server) are used for accessing the voice mail. The last four ports on each server are used for the MWI notifications.

When defining the Unity voice-mail ports in CallManager, you have an option to configure the CSS at the device level and at the voice-mail port directory-number level. At the directory-number level, you can configure the partition in which the directory number resides.

You must set the access restrictions on the voice-mail ports by assigning a restricted CSS in CallManager for voice-mail ports, to avoid the expensive telephone charges. The best practice in configuring the voice-mail ports is to limit the CSS of these ports to allow national calls but to block international dialing. This also avoids toll fraud via the voice-mail system that can occur due to message notifications (user configurable) being sent to international numbers.

It is better to keep the restrictions centralized on the CallManager. That way, you need to make sure only that they are really applied on the CallManager ports; otherwise, you are going to open a door for toll fraud. On the other hand, it is not a good design to build part of the restrictions into the Unity configuration and another part into the CallManager dial plan. To summarize, the following are the rules for the CSS and partitions for the voice-mail ports:

The CSS for the Unity voice-mail ports should contain the partition in which the MWI On/Off numbers reside.

If you would like Unity to notify external phone numbers, the partition to reach the external numbers should also be part of this CSS.

To enable users to call the voice mail directly to log in to their mailbox or press the * key to call another extension, the CSS on the line or the device should include the voice-mail ports.

Defining the Voice-Mail Pilot Number

The voice-mail pilot number is what the phone dials when the user presses the Messages button on the Cisco IP Phone or forwards the call to voice mail. CallManager uses the CSS that is defined for the voice-mail pilot numbers when the phone is forwarded to voice mail. If the CSS on the voice-mail pilot number is set to None and the voice-mail port directory numbers are configured to be in a partition, the forward operation will fail even if the line can call the voice-mail directory numbers.

To configure the voice-mail pilot from CallManager Administration, choose Feature > Voice Mail > Voice Mail Pilot. Table 7-6 shows the configuration settings for the voice-mail pilot number in the Sydney CallManager cluster.

Defining the Voice-Mail Profile

The last step is to configure a voice-mail profile. To access the configuration page, from CallManager Administration, choose Feature > Voice Mail > Voice Mail Profile. The voice-mail profile is the link between the phone configuration and the voice-mail pilot. Each voice-mail pilot is assigned to a voice-mail profile. The voice-mail profile is in turn assigned to each line or directory number on the phone. Table 7-7 shows the configuration settings for the voice-mail profile in the Sydney CallManager cluster.

Reserving Ports for MWIs and Outcall Notifications in Unity

Some ports on the Unity system must be configured exclusively for the MWIs. These ports will be able to send a message to CallManager indicating when to turn off or on the MWI lamp on the handset of IP Phones. In addition, these ports will allow for notifications when the users of XYZ receive new messages. Users can choose the time intervals and type of messages (normal, urgent, and so on) for which they want to be notified.

Making Changes to the Octel Access Numbers

Some changes are required in the Octel system with the introduction of the Unity server in Sydney and the Unity Bridge in San Jose. Before the introduction of Unity in the network, if a user in San Jose addressed a message to a user in Sydney, a digital (over TCP/IP) communication occurred between both Octel systems to get the messages across (using digital OctelNet). In addition, as a failover or backup, there was an analog communication whereby the Octel system in San Jose would call the Octel system in Sydney, and the messages would be delivered via the analog OctelNet protocol.

The phone numbers used for communicating the analog OctelNet messages from San Jose now have to be directed to the Unity Bridge in San Jose instead of the destination in Sydney. The reason for this redirection is that the analog OctelNet destination is now the Unity Bridge in San Jose instead of the Octel system in Sydney. As a result, the Octel voice-mail administrator has to change the voice-mail access number in the San Jose server. For the users, nothing changes; a translation pattern will be in place to translate the local Sydney number to the first Unity port.

Configuring the AutoAttendant functionality in Unity

Because the Octel system in Sydney offers integrated AutoAttendant (AA) functionality, you need to design the Unity system with similar functionality. The requirement for this feature to work properly is a uniform dial plan, which means that every user who has a mailbox on this Unity system must have a unique extension number within the dialing domain. The easiest way to think about this is to compare the Unity port with a regular IP Phone. As long as the extension number assigned in Unity to the subscriber redirects the call to the subscriber IP Phone, the AA feature will work fine.

Because XYZ has a unique four-digit extension number for every subscriber in Australia, this functionality will be available upon activation of the Unity server without additional programming. Also, because everybody who has a voice-mail account on the Sydney Unity server has a unique four-digit extension number, only one dialing domain will be configured on the Unity server.

XYZ will also verify that the Unity server is within the acceptable boundaries regarding jitter and delay in relation to all users and applications. If an end user picks up the phone and dials the Unity main number, they can listen to messages, record greetings, and perform other functions. The maximum delay between the user's IP Phone and the Unity system must be within the 150-ms boundary. Because both the Unity server and the CallManager cluster are based in Sydney, delay and jitter are not issues.

The built-in AutoAttendant and the stringent jitter and latency requirements offer an additional advantage. Because the Brisbane users for example, do not have DID number, they have to rely on an AA solution. In this directory, they only want to find the Brisbane users.

Therefore, a call to the AA number in Brisbane is forwarded to the Unity system in Sydney over the WAN link. Refer to the "Remote-Site WAN QoS Design" section in Chapter 5, "Design Phase: Network Infrastructure Design," to understand the necessary QoS configurations that have to be made for this forwarding to be successful and offer a good voice quality. The calling party connects to the AA in Sydney and Unity system guides the caller through the menu prompts. Based on the user input, Unity system will release the call to the corresponding called party in Brisbane. This avoids the need for a dedicated AA in the other Australian offices. You have to make sure that the necessary bandwidth and failover mechanism are in place via the PSTN.

Note

Another possibility for small remote offices is to use Cisco Unity Express (CUE) and the built in AA functionality. This is currently a standalone solution, which can be seen as a local answering machine. In combination with the Tool Command Language (Tcl) IVR on the Cisco IOS gateways, it is possible to offer local scripting if the WAN does not have enough capacity available.

Octel Integration with CallManager

The type of communication, analog or digital, determines the integration type used between the CallManager and the Octel system. In its San Jose location, XYZ plans to maintain its existing analog integration between the Lucent time-division multiplexing (TDM) PBX and the voice-mail system.

There are three different ways to integrate the CallManager with the Octel voice-mail system in an analog fashion:

Use SMDI between CallManager and the Octel voice-mail system

Use a VG248

Use digital integration with Digital Port Adapter (DPA)

SMDI Integration

SMDI integration is required if you want to continue to offer existing features and functionalities to the users when they migrate from the Lucent TDM PBX to the CallManager. In fact, this SMDI integration will make it possible for the users to see no change with regards to their voice mail when they move from a Lucent phone to a Cisco IP Phone. This is, of course, only the case when their mailbox stays on the TDM system and is not converted to a Unity mailbox.

When using SMDI integration, there is a serial cable between the CallManager and the serial port (RS-232) of the Octel system. The analog ports used to transfer the voice traffic between both systems can be provided by using a router that has analog ports. The disadvantage of this type of integration is the physical cable between the CallManager and the voice-mail system, as shown in Figure 7-7. If the CallManager at which this physical cable terminates experiences a problem, the voice-mail system will be disconnected from the CallManager. In addition, physical requirements (such as, the length of the serial cable) are related to this setup.

Integration Using VG248

VG248 communicates using SCCP with the CallManager cluster. VG248 offers failover and redundancy, like any other SCCP device. This method of integration does not require involvement from the Octel voice-mail system either. It is possible to simply unplug the cables from the voice-mail system and plug them into the VG248no recabling is required.

Figures 7-8 and 7-9 show how this integration looks and how to scale this integration further, respectively. Another possibility is to implement a hybrid solution whereby the CallManager and TDM PBX can coexist and use the same voice-mail system. However, XYZ has chosen to do a full transition to the IP-based PBX systems in San Jose.

Digital Integration Using DPA

There is also a digital integration method available between the CallManager and the Octel voice-mail system by using the Digital Port Adaptor 7630 (DPA-7630), as shown in Figure 7-10. The functionality of this device is comparable to the VG248, because it translates SCCP messages to DCP, the proprietary protocol used by the digital Lucent handsets. The digital integration method has the same advantages as the VG248 related to failover and physical requirements.

XYZ has chosen the digital integration method to integrate the Octel voice mail system in San Jose with the San Jose CallManager cluster because XYZ has the required hardware on the Octel voice mail system to support the integration with DPA-7630.

Designing the Cisco Unity Networking

The Networking feature in Cisco Unity is used to deliver the messages from a Unity server to a target voice-mail system and from the target voice mail system to Unity server. The target voice-mail system could be another Unity server or any other supported vendor's voice mail system. The following networking options are discussed in the next few sections:

Digital Networking

Bridge Networking

AMIS Networking

VPIM Networking

Digital Networking

Digital Networking allows messaging between two or more Unity servers provided they share the same global directory.

Because XYZ's setup has only one Unity server site (Sydney), it is not necessary to address specifically the Unity networking connections between different Unity servers. In brief, if in the future the San Jose site is also converted to Unity, the digital networking can be performed by the Exchange 2000 organization, by the message transport agent (MTA). This is true if both Unity servers are part of the same AD forest.

Bridge Networking

Bridge Networking allows messaging between the Unity server and Octel voice-mail system by using Cisco Unity Bridge. In the current case study, the Unity system in Sydney has to be able to communicate with the Octel system in the San Jose site. Unity Bridge will network the two systems.

AMIS Networking

Unity also supports the Audio Messaging Interchange Specificationanalog (AMIS-a) networking protocol, which can be made available on the Octel system depending on the options purchased for the Octel system. However, AMIS-a offers fewer features than the analog OctelNet protocol. In fact, the analog OctelNet protocol is an improved version of AMIS-a. Avaya (or better, the part of Avaya that used to be Octel before Avaya acquired them) originally developed the analog OctelNet protocol as a common denominator between the Aria and Serenade systems. It then made improvements based on the AMIS-a foundation. The Aria platform is a voice-mail product line from Avaya that is used mainly in the United States, whereas the Serenade product line is used mostly in Asia Pacific and Europe.

One example of this feature difference between AMIS-a and Analog OctelNet is the use of multiple/single-source delivery. When a message is sent using AMIS-a between two voice-mail systems and the message has to reach five different recipients at the destination site, the message is sent across (played back between both systems) five times. This is known as multiple source delivery. With the analog OctelNet protocol (also used by the Unity Bridge), single source delivery is usednamely, the message is sent over only once and is distributed accordingly in the destination voice-mail system. Signaling between both systems is carried as DTMF signals over analog phone lines.

VPIM Networking

Another possibility for voice-mail networking is the Voice Profile for Internet Messaging (VPIM) networking protocol. VPIM allows communication between voice-mail systems to exchange voice and fax messages over the Internet or any TCP/IP connection. VPIM is based on SMTP and the Multipurpose Internet Mail Extensions (MIME) protocol.

VPIM can be used under different circumstances. In certain voice-mail networks, an Intuity Interchange is present. This Interchange product was developed by Avaya and is in fact a protocol converter to link voice-mail systems from different vendors. As a result, these disperse systems can look as one voice-mail network with limited functionality. An example of this limited functionality is the forwarding of messages between two systems from different vendors. Both Unity and Intuity Interchange support VPIMv2.

Another use of VPIM is to integrate Unity and another vendor's voice-mail system that supports the same flavor of VPIM. This allows messages and some other advanced features to be exchanged between two systems.

VPIM can also be used between Unity systems that do not share the same AD and Exchange 2000 infrastructure. In this case, VPIM can be a solution to network these different systems together, which makes it look like one virtual voice-mail system to the users. The directory synchronization is still a manual process, but that is no different from directory synchronization in AMIS-a or Unity Bridge. In earlier releases of Unity, where VPIM was not available, SMTP could be used to bridge two Unity systems located in different AD forests and Exchange 2000 organizations. For every possible destination subscriber on the other system, an Internet subscriber account had to be defined in the local Unity server. Per definition, an Internet subscriber does not have a mailbox in the Exchange 2000 server of the organization that this Unity server integrates. The users do have an entry in the AD forest, which identifies them as Internet subscribers. This entry can hold information such as spoken name, greetings, and so on.