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

Defining the Voice-Mail System Architecture

Figure 7-1 shows the proposed voice-mail architecture for XYZ. The Cisco Unity system that is deployed in Unified Messaging mode replaces the Octel voice-mail system in Sydney. In the San Jose location, the Octel voice-mail system will remain. The Seattle and Dallas sites use the existing Octel voice-mail system in San Jose.

Integration between the CallManager cluster in San Jose and the Octel voice-mail system in San Jose is done by using a Cisco Digital Port Adapter (DPA - 7630). The Cisco DPA-7630 communicates with the Octel voice mail system using 24 digital phone lines. DPA-7630 uses the Skinny Client Control Protocol (SCCP) to communicate with CallManager. Because XYZ uses the voice-mail system as a networking service (meaning all employees can network messages to each other via direct addressing or by using voice-mail distribution lists) integration and interoperability between the Octel network and the Cisco Unity environment needs to be maintained. Therefore, use of the Cisco Unity Bridge is necessary in this setup. The communication between the Cisco Unity server in Sydney and the Unity Bridge in San Jose uses a Simple Mail Transfer Protocol (SMTP) connection, and the communication between the Unity Bridge and the Octel system in San Jose is via an analog connection.

The call flow for messages addressed from a Unity-user in Sydney to an Octel-user San Jose is as follows: The voice mail message addressed in the Unity system in Sydney to an Octel subscriber in San Jose, travels via the internal IP network over an SMTP connection and reaches the Unity Bridge in San Jose. The Unity Bridge will then package this voice mail message as an Analog OctelNet message and place a call, via the VG248, to the Octel system in San Jose. This call will go through the DPA (which is the interface between the CallManager and the Octel system) to reach the Octel System and complete the analog networking call.

The call flow for the opposite is similar. When a voice mail message is addressed from an Octel user in San Jose to a Unity-user in Sydney, the Octel System places a call to the Unity Bridge. The call goes from the Octel system ports that are connected to the DPA and reaches the VG248 which houses the analog extensions for the Unity Bridge. The Unity Bridge then repackages the OctelNet messages to an SMTP message and sends it over the internal network to the Unity server in Sydney.

Unity subscribers in the Sydney, Melbourne, and Brisbane sites can access voice-mail messages via their IP Phones, cell phones, or any other external phone. In addition, Unity will activate the message waiting indicator (MWI) on the phone of the related subscriber and process the Outcall notifications to a pager, cell phone, or home phone, whichever is configured by the subscriber. Subscribers can also access voice-mail messages via a web browser and can customize their mailbox settings, such as greetings, Outcall notifications, and so on.

In the Unified Messaging environment, the voice-mail message is delivered to the subscriber in their common (e-mail and voice-mail) inbox.

Microsoft Active Directory and Exchange

Unity integrates with AD and heavily relies on the messaging infrastructure. Unity supports Microsoft Exchange 2000 or 2003 and IBM Lotus Notes as the message store. Therefore, understanding the messaging architecture is important when you are designing the Unity system.

A prerequisite for deploying Unity in a Unified Messaging mode is that the AD domain and Exchange 2000/2003 or IBM Lotus Notes environment is set up and working properly. Exchange 5.5 support is not an option with Unity versions 4.0 and above.

Unity can answer calls and take voice-mail messages just like the Octel voice-mail systems that are partially replaced in this case study. The subscriber can retrieve their messages through any of the following choices:

By using the phone

By using Microsoft Outlook

By accessing the Cisco Unity Inbox via the web interface

Note

Because XYZ uses Microsoft Exchange as a message store, use of IBM Lotus Notes is not applicable for this case study.

Unity requires extensions to the AD schema. Unity uses AD to service subscribers whose mailboxes reside on Exchange 2000. Unity does this by extending the schema with the addition of the Unity attributes for the following objects:

User

Group

Contact

Unity Location (newly created object)

Unity Location is a special object that allows Unity servers to identify themselves to other Unity servers in the enterprise. It is used only by Unity servers.

To view the list of attributes added for each object, their values, and the impact on the size of the AD database, use the following URL:

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps2237/prod_technical_reference09186a00800e4535l

To see the changes made to the AD schema, browse to the directory Schema\LdifScripts on Cisco Unity CD 1, and view the file Avdirmonex2k.ldf. If the extension of the AD schema is not acceptable, deploy a new AD and Exchange environment and deploy Unity as a voice-mail-only solution. After the IT team or the enterprise messaging/directory team is comfortable in extending the schema, it is possible to migrate to Unified Messaging and use the corporate messaging infrastructure.

Active Directory Architecture

A key requirement before you design a Unity system and deploy it into a network is to understand the existing AD and messaging architecture (Microsoft Exchange/Lotus Domino). Figure 7-2 shows the AD architecture for XYZ. You can see that XYZ has a single AD forest for the entire organization. From the AD point of view, there are two sitesSan Jose and Sydneyeach of which has a domain controller (DC) and a Global Catalog (GC) server, as shown previously in Figure 7-1.

Exchange 2000 Messaging Architecture

As Figure 7-3 shows, the Exchange 2000 messaging architecture for the XYZ San Jose and Sydney sites has Exchange 2000 servers. The San Jose site has three Exchange servers, and the Sydney site has two Exchange servers.

XYZ defined routing groups on a per-site basis, one for San Jose and one for Sydney. Groups of servers running Exchange 2000 form routing groups. Typically, permanent high-speed links connect the servers within the same routing group. A routing group connector connects two different routing groups. Microsoft Exchange uses routing group connectors and Bridgehead servers to route the messages between different routing groups. Bridgehead servers run Exchange 2000 and host routing group connectors.

In the XYZ environment, a message from a user in San Jose to a user in Sydney travels via the routing group connector. Messages between the servers within the same routing group are sent directly from the source server to the destination server using SMTP.

Unity Deployment Model

After you understand the AD and messaging architecture deployed at XYZ, the next step is to choose the Unity deployment model. Three types of deployment models are available when deploying Unity:

Centralized Unity servers are collocated with the message store servers and the phone system.

Distributed Unity servers are not collocated with the message store servers and the phone system.

Hybrid This is a mix of the centralized and distributed models. Unity servers can be deployed at a central location and at remote sites that have numerous users.

When choosing the deployment model consider the following factors:

Unity integration with the phone system If the integration is analog, such as SMDI, cable length requirements might force you to have Cisco Unity servers collocated with the phone system.

Location of the message store If the message store is centralized, place the Unity servers with the message store servers at the same location. To deploy Unity servers in a different location from the message store servers, ensure that there is a LAN connection that connects the locations and that is highly reliable, has less round-trip delay time, and has high bandwidth to avoid synchronization issues.

For XYZ, because the message store servers and CallManager system are in Sydney, deploying Unity servers in Sydney is ideal. A centralized Unity deployment model suits this location because the remote sites in Melbourne and Brisbane have fewer users and do not have significant bandwidth implications. The users at Sydney, Melbourne, and Brisbane access the Unity system in Sydney for their voice mails.

Physical Placement of Unity Servers

The best practice is to deploy the Unity and Exchange servers on the same subnet in a LAN environment, for the following reasons:

Unity uses Mail Application Programming Interface (MAPI) to communicate with Exchange.

MAPI uses remote-procedure call (RPC) as a transport protocol.

RPC is a chatty protocol, so it can introduce delays over slow-speed links and cause problems while passing through firewalls.

XYZ has an already operational Exchange 2000 environment in its regional hub of Sydney. Therefore, the Sydney data center is the ideal place to deploy the Unity server.

High Availability

Many organizations rely on networked voice mail as an essential business tool to enable a caller to leave a message if the employee whom they are calling is unavailable to pick up the phone or to send messages directly to another employee's mailbox. Therefore, the high availability of the voice-mail system is critical.

Clustering is not currently available on the Unity servers. To achieve high availability, deploy Unity servers in active/standby pair, whereby one server is sitting idle until the active one fails.

For XYZ to achieve high availability, it will deploy two Unity servers in Sydney.

Securing Unity Servers

As discussed in Chapter 6, "Design of Call-Processing Infrastructure and Applications," XYZ has good practices in place for securing the CallManager servers. To protect the Unity servers similarly, XYZ plans to do the following:

Install the virus-scanning software and the Cisco Secure Agent (CSA) for intrusion detection on the Unity and Unity Bridge servers.

Apply all Cisco-recommended settings, security patches and operating system service packs to the servers from the moment they become available.

Implement the physical security for the computer room in Sydney where Unity servers are placed.

Backup of Unity Servers

The procedure to back up the AD forest and the Exchange 2000 environment is already in place in the XYZ network. Add the Unity servers to the list of servers and perform the regular backups. Unlike CallManager software, which bundles the backup utility, Unity does not include a backup utility. Cisco recommends using VERITAS NetBackup software (http://www.veritas.com/).

After every major configuration change to a Unity system, use Disaster Recovery Tool (DiRT), part of the Cisco Unity tools depot, to backup the Unity server database and store the backup data on central file server in Sydney.

Voice-Mail Access Options

The users of XYZ in Australia will be able to access their voice mail via the following methods (see Figure 7-4):

Telephone User Interface (TUI)

IP Phone or PBX extension

User's cell (mobile) phone

Graphical user interface (GUI)

Cisco Unity Inbox (a web interface that is part of Cisco Personal Communications Assistant [PCA])

Microsoft Outlook e-mail application

Outlook Web Access (OWA)

Telephone User Interface

Accessing voice mail using the TUI is the same as accessing voice mail on the Octel system.

Accessing Voice Mail from IP Phone or PBX Extension

By dialing into the Unity server, users can access their voice-mail messages via the IP Phone or via a PBX extension, if Cisco Unity integrates with the PBX. Via this method, users can listen to their voice-mail messages, to the headers of e-mail messages, and to the body of e-mail messages. This method embodies the definition of Unified Messaging.

The default order in which Unity plays the messages to the user is as follows: urgent voice mails, normal-priority voice mails, urgent e-mails, and normal-priority e-mails. This order of access can be changed by the Australian employees of XYZ in Cisco PCA. When a user dials in from their car in the morning, they might want to hear urgent e-mails, before urgent voice mails. This characteristic depends on how the mails are handled in the XYZ environment and what privileges are given to users, based on their role and position in the company.

Listening to e-mails when calling the voice mailbox over the TUI requires the license for text-to-speech (TTS) sessions on the Unity servers.

Accessing Voice Mail from a User's Mobile Phone

All users from XYZ will also have their mobile phone numbers configured in Unity as an alternate extension (as discussed later, in the "Customizing the Cisco Unity System" section). As a result, it will be easy for them to call their inbox when they are not at their desk phone in the office. The system will recognize the calling line ID (CLID) from the mobile phone and immediately prompt the user for their personal identification number (PIN) rather than his mailbox number.

Graphical User Interface

Cisco Unity also provides a GUI so that you can access voice-mail messages from your desktop/PC by using Cisco Personal Communications Assistant.

Cisco Unity Inbox

The Australian users will also be able to access their messages via the Cisco Unity Inbox, a web application that is part of Cisco PCA. The Cisco Unity Inbox allows users to browse to a web page and retrieve their messages, greetings, and so on. Users can also use this web page to change their alternate greetings.

Cisco PCA enables Unity subscribers to access the following two applications in Unity:

Cisco Unity Assistant (also called Active Assistant [AA]), which lets subscribers do the following:

Customize how they and callers to their mailbox interact with Unity by phone

Personalize Unity settings, including their recorded greetings and message-delivery options

Set up message-notification devices and create private lists

Cisco Unity Inbox (formerly known as Visual Messaging Interface [VMI]), which allows subscribers to listen to, compose, reply to, forward, and delete voice-mail messages. Cisco Unity Inbox is a licensed feature.

To access Cisco PCA, subscribers use the following URL from the Internet Explorer web browser:

http://

IP_Addr_Unity /ciscopca

Figure 7-5 shows the Cisco PCA application.

Microsoft Outlook E-Mail Application

It is also possible to use Microsoft Outlook to read e-mails, receive voice mails as a WAV attachment, and retrieve voice mails by using View Mail for Outlook (VMO). VMO is a plug-in application, added to the user's PC, that enables the user to retrieve voice mails from their laptop or desktop.

With this VMO component added to Outlook, it is possible to receive a voice mail from a peer and reply as a voice mail to the originating party. Without VMO, this reply is always sent as a WAV file attachment in an e-mail. Also, the originating party who receives the reply will not be able to handle this message as a voice mail (in Unity) without VMO.

The advantages of VMO are seen only when both the sender and receiver of the voice mail use Unity system. For XYZ, because in US location, users have Octel system and Australian users have Unity system, whenever a user from Australia sends a voice mail to a user in San Jose using VMO, San Jose user will always receive the voice mail as an e-mail with a WAV attachment.

Outlook Web Access

Another method of accessing the voice messages is through OWA. To access the messages, type the following URL from your Internet Explorer:

http://

IP_Addr_of_Exchange_Server /exchange

When you use OWA, voice mails are shown as e-mails, with the actual voice message as a WAV attachment.