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

Networking Octel and Unity

As previously discussed in the "Bridge Networking" section, Cisco Unity Bridge acts as a networking gateway between Cisco Unity and an Octel system on an Octel analog network. This case study addresses the use of the Unity Bridge as a means to allow users to move to a Unity system without having to lose their voice-mail networking capabilities. This section discusses the following topics:

Deployment architecture with Unity Bridge

Unity Bridge software

Unity Bridge hardware

Configuring Unity Bridge

Unity Internet Voice Connector

Deployment Architecture with Unity Bridge

Figure 7-11 depicts the logical deployment architecture with the Unity Bridge for XYZ. The Unity Bridge will allow messaging between the Unity server in Sydney and the Octel system in San Jose via the analog OctelNet protocol. The Unity Bridge acts as a networking gateway between Unity and the Octel system, and it allows the systems to exchange voice messages. Messaging between the Unity server in Sydney and the Unity Bridge in San Jose is carried over the internal network using a digital networking protocol, which is based on the VPIM protocol, with proprietary extensions.

Messaging between the Octel system and the Unity Bridge in San Jose happens using the analog OctelNet protocol. It does not matter whether the Octel system is an Aria platform or a Serenade platform, because the analog OctelNet protocol is the same for both product lines.

Because the communication between the Unity Bridge and the Octel server is analog (in other words, phone calls with DTMF signaling), it is recommended that you keep the connection between them as short as possible. Because the Unity Bridge talks to the Unity server via TCP/IP, distance is not a concern between San Jose and Sydney. In addition, you can administer the Unity system from a web browser via HTTP. Therefore, to avoid possible problems such as DTMF distortion because of a transatlantic analog connection, it is better to place the Unity Bridge in San Jose than in Sydney.

The analog OctelNet protocol works comparably to the AMIS-a standard. An analog phone call is placed to transfer the messages between the servers. Upon answering the incoming call, DTMF handshaking occurs while determining the call is an analog OctelNet call.

The major element in this handshaking is the serial number of the system. When the serial number of the destination system does not match the serial number in the database of the originating server, the call is disconnected. That is why it is important to collect the serial number of the Octel voice-mail system in Sydney and assign the same serial number to the Unity Bridge. Reprogramming of this parameter is not needed in the Octel system in San Jose.

After this verification, both systems start the signaling for the message exchange. Both systems send, receive, and confirm the existence of certain mailboxes on their respective systems. The message is played back from the originating server to the destination server.

Because XYZ has only a single Unity Bridge in San Jose, using a Unity Bridgehead server as a central management entity is not an advantage. If XYZ had to administer a whole range of Bridges, the use of the Bridgehead could simplify the design.

Note

Unity and Exchange both use the term

Bridgehead server. An Exchange Bridgehead is a route point for routing messages between route groups within an Exchange organization. Typically, this is between different sites of an organization. A Unity Bridgehead is a single place to maintain bridge locations, bridge subscribers, and distribution lists.

Unity Bridge Software and Hardware

Unity Bridge software runs on a separate and dedicated platform. For the list of supported hardware platforms for Unity and Unity Bridge, refer to the following URL on Cisco.com:

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

As shown in Figure 7-11, the communication between the Unity Bridge and the Octel system in San Jose happens via an analog connection. On the Unity Bridge server, these analog ports are provided by the Brooktrout cards, which you need to order specifically. Refer to the following URL for ordering information on these cards:

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

The ports on the Brooktrout cards work the same as analog phones. That is why you need a VG248 or an FXS card (for example, WS-X-6624) controlled by CallManager to establish the connection between the Unity Bridge in San Jose and the Octel system. This effectively makes it possible to establish communication between the analog extension and the Octel voice-mail system. XYZ decided to deploy the VG248 to provide the analog ports to the Unity Bridge (refer to figure 7-1). Because the Brooktrout card that will be installed on the Unity Bridge server only has 4 analog ports, the remaining 44 ports on the VG248 can be used for other analog extensions such as faxes and POTS-phones in San Jose.

The Unity Bridge software should be licensed for at least four ports per server. This means that one four-port Brooktrout card in the server can do the conversions from analog to digital signals. This also means that there can be a maximum of four simultaneous calls between the Bridge and the Octel system in San Jose. Therefore, a maximum of four messages can be delivered simultaneously from one system to the other.

Based on traffic reports from the Octel systems (from the voice-mail networking, confirmed by traffic-flow analysis on the TCP/IP network), the majority of the messages is exchanged in the local hubs in San Jose and Sydney. There is far less traffic flow between San Jose and Sydney; therefore, having the capacity to handle four parallel calls between these systems is sufficient. It is always possible, through future expansions, to add additional Brooktrout cards in the server and increase the capacity.

The Unity Bridge hardware selected for XYZ consists of the following components:

IBM MCS-7845I-2.4-ECS2 server, with IBM RSA-II adapter which provides the remote management to the Unity Bridge server.

Four-port voice/fax ports (UNITY-TR114U-US).

The Bridge, regardless of the power supply configuration, requires two power connections. The power connections should be on isolated, redundant circuits and rated to handle a minimum of 350W. Also, the Bridge requires a minimum of two 10/100/1000 copper Ethernet connections. Three connections are preferred:

One connection for the RSA-II adapter (assigned in DNS as using the format hostname-r).

Two connections for the built-in Ethernet ports. The network connections must be rated at 100-Mbps full duplex as a minimum.

If you are deploying Unity Bridge in the network, you need to extend the AD schema for Unity Bridge (refer to Figure 7-6). The next steps are to install the Cisco Unity IVC on the Exchange server and configure the Cisco Unity server for Bridge networking before configuring the Unity Bridge.

Configuring Unity Bridge

Most of the pages available from Cisco Unity Bridge Administration have default settings. This section describes the steps to follow to configure the Unity Bridge and customize the default settings. To access the Bridge Administration page on the browser, type the following URL:

http://

Bridge_server_IP_ADDR /Bridge

Figure 7-12 shows the Unity Bridge Administration page and the various configuration options that are available. The following sections describe the first four configuration options in the list on the left side of the Bridge Administration page.

System Settings

To access the System Settings page, click

System Settings on the Bridge Administration page. The System Settings page allows you to configure how the Unity Bridge server handles retries when a call delivers a failure message. There are separate settings for busy, no answer, and failed call conditions.

Table 7-8 lists the various fields on the System Settings page and the appropriate values for XYZ.

The following list describes the preceding fields and values in more detail:

Attempts and Interval fields Describe the number of analog call attempts and the interval of each analog call attempt between the Octel server and the Unity Bridge. The unit used for an interval is minutes, and the default of 1 minute is used. If the systems are busy in an extensive meshed voice-mail network, it is better to increase the interval, to avoid excessive call charges over the PSTN.

Name Aging Set to 0 to avoid name aging. Setting this field to zero retains the spoken name that is used for confirmation of the destination.

Name Retrieval Retries Indicates for how many days the Unity Bridge will try to obtain the spoken names at a specific time (midnight) from the Octel system in San Jose and store them in AD for use by the Australian users. Once done successfully, the users who have a mailbox in Sydney can address a message to a user in San Jose and hear the user's spoken name confirmation.

Name Retry Interval The Retry Interval is expressed in days. It is used to launch a call every day until all names are retrieved or until the maximum retrieval retries are used. These calls are made at no cost, because the Bridge and Octel server are located in the same room and are connected via a direct analog connection.

Queued Call Threshold Indicates the number of messages that must be waiting in the queue before another port initiate's a call from the Unity Bridge to the Octel server located in San Jose via the analog connection. Note that XYZ has only two destinations, and the value will be lowered to 2 automatically. Based on availability, this will always open an additional channel when messages are queued. This implementation has no cost implications because the Bridge is located in San Jose next to the Octel server.

Max. Ports per Node Indicates how many ports can be used in parallel between the Unity Bridge and the Octel server located in San Jose. Because XYZ has only two voice-mail systems, it can allocate the maximum number of ports. If you have a mesh of voice-mail systems, it is important not to assign too many ports for communication between any two nodes. Take into account that the maximum number of ports in use between any two nodes can be doubled when urgent messages need to be transferred. The maximum number of ports is determined by the licenses purchased from Cisco. In this example, the number of ports purchased in the maximum capacity is 48.

Call Log Retention Indicates the number of days that call logs are retained. The default is 7, which XYZ will use.

Call Tracing Level The choices are None, Basic, or Verbose. XYZ chose Verbose to facilitate initial troubleshooting after the setup. Afterward, you can set it to Basic to limit the impact on the Bridge server. Choosing None is not recommended. Doing so makes obtaining any information that is related to a problem difficult, resulting in a lack of troubleshooting capabilities.

Digital Networking

The Digital Networking page provides settings that allow you to record error and status messages in a log file and allow you to view outbound messages that are retained in SMTP format. To access the Digital Networking page, choose

Digital Networking on the Bridge Administration page.

Table 7-9 lists fields on the Digital Networking page and the values used for XYZ.

The following list explains a few of the Digital Networking page fields and values in more depth:

ESMTP Server exchange@XYZ.com is a fully qualified domain name (FQDN) of the Exchange server. If your Exchange organization relies on a relay server for the routing of messages (ESMTP e-mail host), specify that server here. Contact your Exchange 2000 administrator for confirmation.

Tracing Level Choosing Flow enables you to see detailed information flows and examine all the parameters before you declare that everything is working fine. After you make sure that everything is working fine, you can change this parameter to Error, which will show only the errors and prevent the hard disk from storing unrelated information.

Retention Days for Temporary SMTP Messages Helps you to keep track of all incoming and outgoing messages. After a first week of problem-free production, you can set this value to 0. However, if enough disk capacity is available and the traffic is not high, leave this parameter on 2 for troubleshooting purposes.

Unity Nodes

Transcoding' section of Chapter 6, DSP farms deployed in Catalyst WS-X6608-E1 card are used to convert the G.729a codec streams to G.711. Hence both Unity and Unity Bridge will be configured to send and receive all the traffic in G.711.

Note that you can click the Directory button to see a list of subscribers associated with this Unity node.

Octel Nodes

Each Octel server represents a node in the Octel analog network. In Octel analog networking, each node is assigned a unique serial number that identifies the node. The Bridge and Cisco Unity Bridgehead servers must be configured with information about the Octel nodes on the network. The Octel Nodes page displays information about the Octel nodes. You create and configure an Octel node through the Bridge Administrator. To access the Octel Nodes page, choose

Octel Nodes on the Bridge Administration page.

Tables 7-11 and 7-12 show the Octel Nodes page fields and the settings for the XYZ network in Unity Bridge.

The following list explains various Octel Nodes page fields:

Serial Number The serial number of the Octel system in San Jose.

Name Included to make the window easier to read.

Phone Number The number to be dialed by the Bridge in San Jose to reach the Octel server in San Jose, which is why it is a local San Jose number.

Note that the CallManager in San Jose is providing analog lines via a module in the Catalyst 6000. This allows the transformation of this number to the internal four-digit number according to the dial-plan standard of XYZ.

Extension Stays blank because the Octel server in San Jose is equipped with DID lines.

Dial Sequence The dial sequence for the United States is 9 (access code) followed by the number defined in the Phone Number field. The CallManager dial plan for XYZ has to consider # as the end of the dialing string. In addition, it is best to start the dial sequence with a pause (P).

Message Delivery Windows Specify begin and end times and the interval, in minutes, for normal, urgent, and administrative calls. As indicated in Table 7-12, normal calls go through 24 hours a day with short time intervals; this allows the fastest delivery of messages and the highest degree of service to users of XYZ. As mentioned earlier, the communication between the Unity Bridge in San Jose and the Octel server does not traverse the PSTN, so XYZ does not incur telephone charges for these calls. If the calls are going over PSTN, you can change these times and intervals to be more conservative.

We will not add names to the Octel directory on the Bridge. Instead, because of the addressing of messages and the involved automatic NameNet feature, this directory will be populated over time. This will require proper user communication to set the right user expectations. NameNet update is used when one node in an OctelNet network makes a call to another node in the OctelNet network (which can be a Unity Bridge) to retrieve the spoken name of one or more subscribers on that system. Such communication is referred to as an administrative call. This mechanism to retrieve the spoken names is to offer name confirmation to the users when they address messages to users on another system in the network. NameNet updates can also be part of a "regular" OctelNet communication or can be launched separately, depending on the configuration of the Bridge (time window and intervals).

By clicking the Directory button in this menu, you can see a list of mailboxes that exchanged messages with the Bridge. This information is retrieved via OctelNet NameNet.

This is also true in the opposite direction. The Octel system in San Jose will lose the spoken names (NameNet information) for Sydney users after Sydney migrates to Unity. This information will be propagated, as messages are exchanged or forced, as configured in the Bridge. An alternativewhich is not recommended from a cost perspective and is not done for XYZis for the Octel system administrator in San Jose to populate the NameNet information in the San Jose system manually.

None of the other voice-mail functionalities and habits will change for the users who are located on the Octel server in San Jose. They will not notice a difference in the way they interact with users from Australia.

Unity Internet Voice Connector

The purpose of the Internet Voice Connector (IVC) is to preserve key properties as messages are routed between Unity and third-party messaging systems. IVC interacts with other Microsoft Exchange components to send and receive messages for Unity subscribers from third-party messaging systems and vice versa.

For the Unity server to communicate with the Unity Bridge, you need to install one instance of IVC on the Exchange server in each routing group. IVC stores its data in the Windows registry of the Exchange server. With Unity 4.x and above, it is not possible to integrate with Exchange 5.5, so you must use the correct version of IVC.

As shown in Figure 7-3, one routing group and one Bridgehead server are located in the Sydney site. The Sydney Bridgehead Exchange server will have the Unity IVC.

To see the call-flow and message-routing steps that occur when a subscriber on a Unity server leaves a voice mail for a subscriber on an Octel server, suppose that there is a message flowing from Octel subscriber 1000 in San Jose to subscriber 2000 in Sydney.

Via the analog OctelNet protocol, the message is delivered to the Unity Bridge. From the Unity Bridge server, the message is sent to the IVC in the following format:

FROM: 1000 @ 24555 (Mailbox 1000 Serial Number 24555)

TO: 2000 @ 27975 (Mailbox 2000 Serial Number 27975)

The IVC has to translate the address in the TO field to a format that can be understood by Exchange and Unity. IVC queries AD with parameters of Mailbox 2000 and Serial Number 27975. The return is the Exchange alias that Exchange and Unity understand. Therefore, the message addressing looks as follows:

FROM: 1000 @ 24555

TO: Alias_For_Mailbox_2000

The next task is to do something useful with the FROM address so that it can be understood by Exchange. Therefore, the IVC is going to query AD again with a parameter, the Serial Number 24555 (as remoteNodeId). It finds the corresponding DTMF-Id (being 152, San Jose), after which the addresses are changed as follows:

FROM: OMNI:152_1000 (LocationDialId_Extension)

TO: Alias_For_Mailbox_2000

This processing does not resolve the FROM address, but it does put the addresses in a format that Exchange can understand. Identifying and resolving the sender of this message is the next step.

The IVC will query the AD again with the DTMF-Id and try to find a match. If the IVC finds a match, the alias is returned and it replaces the 152_1000. Now, the addresses look as follows:

FROM: Alias_For_Mailbox_1000

TO: Alias_For_Mailbox_2000

The recipient now hears the name confirmation of the sender in the TUI and sees in the GUI the display name.

If AD cannot respond to the IVC query, the TUI and GUI indicate that this message came from an unidentified caller, without name confirmation in the TUI or display information in the GUI.