Design Guide for Cisco Unity Release 5.x
Integrating Cisco Unity with the Phone System
Downloads: This chapterpdf (PDF - 411.0KB) The complete bookPDF (PDF - 2.4MB) | Feedback

Integrating Cisco Unity with the Phone System

Table Of Contents

Integrating Cisco Unity with the Phone System

Overview

How an Integration Works

Lines and Cables to Make Physical Connections

Integration with Cisco Unified Communications Manager

Digital Integration with Digital PIMG Units

DTMF Integration with Analog PIMG Units

Serial (SMDI, MCI, or MD-110) Integration with Analog PIMG Units

TIMG Integration

DTMF Integration with Voice Cards

Serial Integration with Voice Cards

Settings in the Phone System and in Cisco Unity

Call Information Exchanged by the Phone System and Cisco Unity

Call Control

Sample Path for a Call from the Phone System to a Subscriber

General Integration Issues

Integrating with Cisco Unified Communications Manager (by Using SCCP or SIP)

Integrating Cisco Unity with Multiple Versions of Cisco Unified Communications Manager

Integrating Cisco Unity with Multiple Cisco Unified Communications Manager Clusters

Cisco Unified Communications Manager Authentication and Encryption for Cisco Unity Voice Messaging Ports (SCCP Integrations Only)

Cisco Unified Communications Manager Security Features

When Data Is Encrypted

Cisco Unified Communications Manager Cluster Security Mode Settings in Cisco Unity

Disabling and Re-Enabling Security

Multiple Integrations Can Have Different Security Mode Settings

Settings for Individual Voice Messaging Ports

Packetization (SCCP Integrations Only)

Integrating with Cisco Unified Communications Manager Express (by Using SCCP or SIP)

Multiple Cisco Unified Communications Manager Express Version Support

Multiple Cisco Unified Communications Manager Express Routers Integrating with a Single Cisco Unity Server

Integrating Cisco Unity with Cisco Survivable Remote Site Telephony (Cisco SRST)

Impact of Non-Delivery of RDNIS on Voice Mail Calls Routed via AAR

Integrating Cisco Unity with Cisco Unified Communications Manager Express in SRST Mode

Integrating by Using SIP

Supported SIP Integrations

Cisco Unity Failover with SIP Trunks

SIP Compliance

Integrating with Circuit-Switched Phone Systems by Using PIMG or TIMG Units

Description of PIMG Integrations

Digital Integration with Digital PIMG Units

DTMF Integration with Analog PIMG Units

Serial (SMDI, MCI, or MD-110) Integration with Analog PIMG Units

Description of TIMG Integrations

Setup and Configuration

Firmware Updates

Serial Integrations

Increasing Port Capacity

Cisco Unity Failover

Cisco Unity Failback

Multiple Integration Support/Branch Office Consolidation

Integrating with Multiple Phone Systems

Requirements for Integrations with Multiple Phone Systems

Using SCCP Phone Systems with Other Integrations

Notes for PIMG Integrations

Optional Integration Features

Alternate Extensions

Reasons to Use Alternate Extensions

How Alternate Extensions Work

Alternate MWIs

Setting Up Alternate MWIs for Extensions on the Same Phone System

MWIs for Extensions on a Non-Integrated Phone System

Centralized Voice Messaging


Integrating Cisco Unity with the Phone System


See the following sections:

Overview

How an Integration Works

Sample Path for a Call from the Phone System to a Subscriber

General Integration Issues

Integrating with Cisco Unified Communications Manager (by Using SCCP or SIP)

Integrating with Cisco Unified Communications Manager Express (by Using SCCP or SIP)

Integrating by Using SIP

Integrating with Circuit-Switched Phone Systems by Using PIMG or TIMG Units

Integrating with Multiple Phone Systems

Optional Integration Features

Centralized Voice Messaging

Overview

An integration enables communication between Cisco Unity and a phone system, providing subscribers with features that typically include the following:

Calls to a subscriber extension that does not answer or is busy are forwarded to the subscriber personal greeting.

Messages left for a subscriber activate the message waiting indicator (MWI) on the extension.

A subscriber has easy access to messages by pressing a button on the phone and entering a password.

Depending on the phone system and the integration, other integration features may be available, including caller ID, call forward to the subscriber busy greeting, and identified subscriber messaging.

For a list of supported phone systems, see Supported Hardware and Software, and Support Policies for Cisco Unity Release 5.0 at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_installation_guides_list.html.

Cisco Unity can integrate with one or more phone systems at the same time. For details, see the Multiple Phone System Integration Guide for Cisco Unity 5.0 at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

Circuit-switched phone systems can integrate with Cisco Unity by using one of the following integration methods:

PIMG/TIMG integrations

PIMG or TIMG units are media gateways between circuit-switched phone systems and IP networks. On the circuit-switched phone system side, there are digital (feature-set), analog, and T1-CAS interfaces. On the IP side, there is a SIP interface, which is how Cisco Unity communicates with the PIMG unit.

PIMG/TIMG units are the preferred method for integrating with circuit-switched phone systems.

Voice card integrations

Voice cards connect circuit-switched phone systems and Cisco Unity through analog lines. Voice cards must be installed in the Cisco Unity server or in an expansion chassis that is connected to the Cisco Unity server.

Support for voice cards is slowly being phased out, and voice cards are now only supported when Windows 2000 Server is installed on the Cisco Unity server. For information on the voice cards supported for use with Cisco Unity, see Supported Hardware and Software, and Support Policies for Cisco Unity Release 5.x at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_installation_guides_list.html.


For detailed information on integrating Cisco Unity with a specific phone system, see the applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

How an Integration Works

An integration depends on the following components to be successful:

Lines and cables necessary to make physical connections (in circuit-switched phone systems) or a network connection (in Cisco Unified Communications Manager (CM) (formerly known as Cisco Unified CallManager) and SIP proxy servers). For more information, see the "Lines and Cables to Make Physical Connections" section.

Settings in the phone system and in Cisco Unity. For more information, see the "Settings in the Phone System and in Cisco Unity" section.

Call information exchanged by the phone system and Cisco Unity. For more information, see the "Call Information Exchanged by the Phone System and Cisco Unity" section.

Call control (signals used to set up, monitor, and tear down a call) to determine and control the status of the call. For more information, see the "Call Control" section.

Lines and Cables to Make Physical Connections

Depending on the type of integration, different combinations of lines and cables are used to connect the phone system and Cisco Unity.

Integration with Cisco Unified Communications Manager

Cisco Unified Communications Manager (CM) (formerly known as Cisco Unified CallManager) and SIP proxy servers use network connections that carry all communication to and from Cisco Unity. Figure 6-1 shows the network connections used in an integration with Cisco Unified CM.

Figure 6-1 Connections for an Integration with Cisco Unified Communications Manager

Digital Integration with Digital PIMG Units

The phone system sends call information, MWI requests, and voice connections through the digital lines, which connect the phone system to the PIMG units. The PIMG units communicate with the Cisco Unity server through the LAN or WAN by using Session Initiation Protocol (SIP). Figure 6-2 shows the connections used in a digital integration by using digital PIMG units.

Figure 6-2 Connections for a Digital Integration by Using Digital PIMG Units

DTMF Integration with Analog PIMG Units

The phone system sends call information, MWI requests, and voice connections through the analog lines, which connect the phone system to the PIMG units. The PIMG units communicate with the Cisco Unity server through the LAN or WAN by using Session Initiation Protocol (SIP). Figure 6-3 shows the connections for a DTMF integration by using analog PIMG units.

Figure 6-3 Connections for a DTMF Integration by Using Analog PIMG Units

Serial (SMDI, MCI, or MD-110) Integration with Analog PIMG Units

The phone system sends call information and MWI requests through the data link, which is an RS-232 serial cable that connects the phone system and the master PIMG unit. Voice connections are sent through the analog lines between the phone system and the PIMG units. The PIMG units communicate with the Cisco Unity server through the LAN or WAN by using Session Initialization Protocol (SIP). Figure 6-4 shows the connections for a serial integration by using analog PIMG units.

Figure 6-4 Connections for a Serial (SMDI, MCI, or MD-110) Integration by Using Analog PIMG Units

TIMG Integration

The phone system sends call information and MWI requests through the data link, which is an RS-232 serial cable that connects the phone system and the master TIMG unit. Voice connections are sent through the T1 digital lines between the phone system and the TIMG units. The TIMG units communicate with the Cisco Unity server through the LAN or WAN by using Session Initialization Protocol (SIP). Figure 6-5 shows the connections.

Figure 6-5 Connections for an Integration by Using TIMG Units

DTMF Integration with Voice Cards

The circuit-switched phone systems use analog lines to carry voice connections, call information, and MWI activation requests. The lines connect the ports on the phone system to the voice messaging ports on voice cards installed on the Cisco Unity server. Signaling carried across the analog lines is achieved through DTMF digits being sent to and from the phone system and Cisco Unity. For example, in order for Cisco Unity to turn on or off the MWI lamp, DTMF digits (including #, *, and the digits 0-9) are sent from Cisco Unity to the phone system. Figure 6-6 shows the connections used in a DTMF integration.

Figure 6-6 Connections for a DTMF Integration by Using Voice Cards

Serial Integration with Voice Cards

In serial integrations (also called SMDI or MCI integrations for NEC phone systems), circuit-switched phone systems use an RS-232 serial cable to carry call information and MWI activation requests. The serial cable connects the serial port on the phone system to the serial port on the Cisco Unity server. (Some phone systems require hardware such as a modem or PBXLink box to connect to the serial cable.) Figure 6-7 shows the connections.

Figure 6-7 Connections for a Serial Integration by Using Voice Cards

Settings in the Phone System and in Cisco Unity

For an integration to be successful, Cisco Unity and the phone system must know the connections to use (for example, cables, IP addresses, and channels) and the expected method of communication (for example, IP packets, serial packets, or DTMF tones). Certain integrations require specific codes or extensions for turning MWIs on and off.

There are required settings for Cisco Unity, and programming for the phone system, that must be made in order to enable the integration. For information on these settings, see the applicable integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

Call Information Exchanged by the Phone System and Cisco Unity

The phone system and Cisco Unity exchange call information to manage calls and to make the integration features possible. With each call, the following call information is typically passed between the phone system and Cisco Unity:

The extension of the called party.

The extension of the calling party (for internal calls) or the phone number of the calling party (if it is an external call and the phone system supports caller ID).

The reason for the forward (the extension is busy, does not answer, or is set to forward all calls). There is also a reason code for Direct Calls.

Cisco Unified Communications Manager SCCP and SIP trunk integrations can also provide the following call information (the choice of first and last redirecting number is set in the Advanced Settings Tool, which is available in Tools Depot):

Called number

First redirecting number

Last redirecting number


Note Cisco Unity can use either the first redirecting number or last redirecting number, depending on the setting in the Advanced Settings Tool, which is available in Tools Depot.


If the phone system sends the necessary information and if Cisco Unity is configured correctly, an integration can provide the following integration functionality:

Call forward to personal greeting

Call forward to busy greeting

Caller ID

Easy message access (a subscriber can retrieve messages without entering an ID because Cisco Unity identifies the subscriber based on the extension from which the call originated; a password may be required)

Identified subscriber messaging (Cisco Unity identifies the subscriber who leaves a message during a forwarded internal call, based on the extension from which the call originated)

Message waiting indication (MWI)

Call Control

The phone system uses a set of signals to set up, monitor, and release connections for a call. Cisco Unity monitors call control signals to determine the state of the call, and uses these signals to respond appropriately to phone system actions and to communicate with the phone system. For example, a caller who is recording a message might hang up, so Cisco Unity detects that the call has ended and stops recording.

Depending on the phone system, the following types of call control signals are used:

Cisco Unified Communications Manager

For Skinny Call Control Protocol (SCCP) integrations, Cisco Unified Communications Manager generates SCCP messages, which are translated by the Cisco Unity-CM TSP into TAPI that Cisco Unity uses. Cisco Unity actions—such as hook flash for transferring calls—are translated by the Cisco Unity-CM TSP into the SCCP messages that Cisco Unified CM uses.

For SIP trunk integrations, Cisco Unified CM sends SIP messages, and Cisco Unity sends SIP responses when a call is set up or terminated.

Circuit-switched phone system

For PIMG/TIMG integrations, the phone system sends messages to the PIMG or TIMG units, which send the applicable SIP messages to Cisco Unity. Cisco Unity sends SIP responses when a call is set up or terminated, and the PIMG or TIMG units communicate with the phone system.

For voice card integrations, the phone system generates and responds to in-band signaling (for example, busy, disconnect, DTMF, and hook flash). The signaling tones are translated by the Dialogic TSP into TAPI events that Cisco Unity can use. Cisco Unity makes a telephony request such as "transfer," which is translated by the Dialogic TSP into the signal (hook flash) that the phone system can use.


Sample Path for a Call from the Phone System to a Subscriber

The following steps give an overview of a sample path that an external call can take when traveling from the phone system to a subscriber.

1. For Cisco Unified Communications Manager, when an external call arrives, the gateway sends the call over the LAN or WAN to Cisco Unified CM.

The corresponding step for circuit-switched phone systems, when an external call arrives via the PSTN, TI/PRI, DID or LS/GS analog trunks, is for the call to be routed through the phone system to the Cisco Unity voice mail pilot number.

2. The phone system routes the call to an available Cisco Unity extension (a voice messaging port).

3. Cisco Unity answers the call and plays the opening greeting.

4. During the opening greeting, the caller enters an extension. For example, the caller enters 1234 to reach a person with that extension.

5. Cisco Unity notifies the phone system that there is a call for extension 1234.

6. Depending on whether Cisco Unity is set up to perform a supervised transfer or a release transfer, the following occurs:

Supervised transfer

While Cisco Unity holds the call, the phone system attempts to establish a connection with extension 1234.

If the line is available, the phone system connects the call from Cisco Unity to extension 1234. The phone system and Cisco Unity drop out of the loop, and the call is connected directly from the original caller to extension 1234.

If the line is busy or unanswered, the phone system gives that information to Cisco Unity, and Cisco Unity performs the operation the subscriber has specified. For example, Cisco Unity takes a message.

Release transfer (blind transfer)

Cisco Unity passes the call to the phone system, and the phone system sends the call to extension 1234 without waiting to determine whether the line is available. Then the phone system and Cisco Unity drop out of the loop. In this configuration, if the customer wants Cisco Unity to take a message when a line is busy or unanswered, each phone must be configured to forward calls to Cisco Unity when the line is busy or unanswered.


General Integration Issues

For a detailed list of the requirements for a specific integration, see the applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

If Cisco Unity is configured for failover, line connections between the phone system and the Cisco Unity servers are described in the following documents:

The applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

The Failover Configuration and Administration Guide for Cisco Unity at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_feature_guides_list.html.

In addition, consider the following list of integration issues:

Cisco Unified Communications Manager integrates with Cisco Unity only through a network connection.

Circuit-switched phone systems that connect to PIMG or TIMG units integrate with Cisco Unity only through a network.

Circuit-switched phone systems that connect to voice cards and that use an RS-232 serial cable for the integration must be within 50 feet of the Cisco Unity server. For serial cable specifications, see the applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

Voice card integrations are supported only when Windows 2000 Server is installed on the Cisco Unity server. For a list of supported voice cards, see Supported Hardware and Software, and Support Policies for Cisco Unity Release 5.x at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_installation_guides_list.html.

The license file for Cisco Unity may enable more voice messaging ports than the customer needs. Install only the number of ports that are needed, so that system resources are not allocated to unused ports, and do not exceed the port limitations set for the platform. For more information, see the Cisco Unity Supported Platform List at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_data_sheets_list.html). For additional information about configuring voice messaging ports, see the "Planning How the Voice Messaging Ports Will Be Used in Cisco Unity" section in the applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

Integrating with Cisco Unified Communications Manager (by Using SCCP or SIP)

Cisco Unity supports Cisco Unified Communications Manager (CM) (formerly known as Cisco Unified CallManager) integrations through both SCCP and SIP interfaces. Table 6-1 shows the major differences in these integration methods.

Table 6-1 Differences Between SCCP and SIP Integration Methods 

Feature
SCCP
SIP

Communication method

Cisco Unity-CM TSP

SIP trunk

Failover

Supported

Not supported

Use of SCCP and SIP phones

Supported

Some SCCP phones may require use of a media termination point (MTP)

Support for Cisco Unified CM versions

All versions

Versions 5.x and later

Cisco Unified CM versions 5.x and later

Supported

Supported

Cisco Unified CM authentication and encryption

Supported

Not supported

First/last redirecting number

Supported

Supported

QOS

Supported

Supported


For information on the compatibility of Cisco Unity and Cisco Unified CM versions with the Cisco Unity-CM TSP and the SIP trunk, see the following documents at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_device_support_tables_list.html:

SCCP Compatibility Matrix: Cisco Unity, the Cisco Unity-CM TSP, Cisco Unified Communications Manager, and Cisco Unified Communications Manager Express

SIP Trunk Compatibility Matrix: Cisco Unity and Cisco Unified Communications Manager

For information on how to integrate Cisco Unity with Cisco Unified CM, see the applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

For more information on using the SIP protocol to integrate Cisco Unity with Cisco Unified CM, see the "Integrating by Using SIP" section.


Note When the G.729a codec is used, Cisco Unity cannot perform silence detection. Using this codec may result in messages that have long trailing silence or that are entirely silent.


Integrating Cisco Unity with Multiple Versions of Cisco Unified Communications Manager

A single Cisco Unity server can support multiple versions of Cisco Unified CM. The version of the Cisco Unity-CM TSP or SIP trunk being used must support all versions of Cisco Unified CM integrated with Cisco Unity. See the following documents at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_device_support_tables_list.html:

SCCP Compatibility Matrix: Cisco Unity, the Cisco Unity-CM TSP, Cisco Unified Communications Manager, and Cisco Unified Communications Manager Express

SIP Trunk Compatibility Matrix: Cisco Unity and Cisco Unified Communications Manager

Integrating Cisco Unity with Multiple Cisco Unified Communications Manager Clusters

To integrate Cisco Unity with more than one Cisco Unified CM cluster, you can just re-run the Cisco Unity Telephony Integration Manager, or UTIM. Note the options and considerations detailed in Table 6-2.

Table 6-2 Options and Considerations for Integrating with Multiple Cisco Unified Communications Manager Clusters 

Option
Considerations

Create a new Cisco Unified CM integration for each new Cisco Unified CM cluster

This is the recommended method.

Each Cisco Unified CM integration handles the MWIs for the cluster. Dedicated MWI ports for each Cisco Unified CM cluster is necessary only if the Cisco Unified CM integration has multiple clusters in UTIM.

Cisco Unity sends each MWI request directly to the Cisco Unified CM cluster on which the subscribers is homed.

Multiple Cisco Unified CM integrations can be used with multiple UTIM clusters on a Cisco Unity server.

Add a cluster in UTIM to an existing Cisco Unified CM integration for each new Cisco Unified CM cluster

You must assign at least one MWI port dedicated to each Cisco Unified CM cluster that you add.

The first cluster in UTIM will handle all calls and direct them to the Cisco Unified CM cluster on which the subscriber is homed.

You can create an unlimited number of clusters in UTIM to a Cisco Unified CM integration.

Multiple UTIM clusters can be used with multiple Cisco Unified CM integrations on the Cisco Unity server.


Within a cluster, it is important to identify the backup (secondary) Cisco Unified CM servers so that Cisco Unity can connect to it if the primary Cisco Unified CM server becomes unavailable.

Cisco Unified Communications Manager Authentication and Encryption for Cisco Unity Voice Messaging Ports (SCCP Integrations Only)

A potential point of vulnerability for a Cisco Unity system is the connection between Cisco Unity and Cisco Unified Communications Manager. Possible threats include:

Man-in-the-middle attacks, in which an attacker intercepts and changes the data flowing between Cisco Unified CM and Cisco Unity voice messaging ports.

Network traffic sniffing, in which an attacker captures phone conversations and signaling information that flow between Cisco Unified CM, the Cisco Unity voice messaging ports, and IP phones that are managed by Cisco Unified CM).

Changing the call signaling between the Cisco Unity voice messaging ports and Cisco Unified CM.

Changing the media stream between Cisco Unity voice messaging ports and endpoints, for example, phones or gateways.

Identity theft of the Cisco Unity voice messaging port, in which a non-Cisco Unity device presents itself to Cisco Unified CM as a Cisco Unity voice messaging port.

Identity theft of the Cisco Unified CM server, in which a non-Cisco Unified CM server presents itself to Cisco Unity voice messaging ports as a Cisco Unified CM server.


Note SIP integrations do not support Cisco Unified CM authentication or encryption.


See the following sections for additional details:

Cisco Unified Communications Manager Security Features

When Data Is Encrypted

Cisco Unified Communications Manager Cluster Security Mode Settings in Cisco Unity

Disabling and Re-Enabling Security

Multiple Integrations Can Have Different Security Mode Settings

Settings for Individual Voice Messaging Ports

Cisco Unified Communications Manager Security Features

Cisco Unified CM 4.1(3) or later can secure the connection with Cisco Unity against these threats. The Cisco Unified CM security features that Cisco Unity can take advantage of are described in Table 6-3.

Table 6-3 Cisco Unified Communications Manager Security Features That Are Used by Cisco Unity 

Security Feature
Description

Signaling authentication

Uses the Transport Layer Security (TLS) protocol to validate that no tampering has occurred to signaling packets during transmission. Signaling authentication relies on the creation of the Cisco Certificate Trust List (CTL) file.

This feature protects against:

Man-in-the-middle attacks that modify the information flow between Cisco Unified CM and the Cisco Unity voice messaging ports.

Modification of the call signaling.

Identity theft of the Cisco Unity voice messaging port.

Identity theft of the Cisco Unified CM server.

Device authentication

Validates the identity of the device. This process occurs between Cisco Unified CM and Cisco Unity voice messaging ports when each device accepts the certificate of the other device. When the certificates are accepted, a secure connection between the devices is established. Device authentication relies on the creation of the Cisco Certificate Trust List (CTL) file.

This feature protects against:

Man-in-the-middle attacks that modify the information flow between Cisco Unified CM and the Cisco Unity voice messaging ports.

Modification of the media stream.

Identity theft of the Cisco Unity voice messaging port.

Identity theft of the Cisco Unified CM server.

Signaling encryption

Uses cryptographic methods to protect (through encryption) the confidentiality of all SCCP signaling messages that are sent between the Cisco Unity voice messaging ports and Cisco Unified CM. Signaling encryption ensures that the information that pertains to the parties, DTMF digits that are entered by the parties, call status, media encryption keys, and so on are protected against unintended or unauthorized access.

This feature protects against:

Man-in-the-middle attacks that observe the information flow between Cisco Unified CM and the Cisco Unity voice messaging ports.

Network traffic sniffing that observes the signaling information flow between Cisco Unified CM and the Cisco Unity voice messaging ports.

Media encryption

Uses Secure Real Time Protocol (SRTP) as defined in IETF RFC 3711 to ensure that only the intended recipient can interpret the media streams between Cisco Unity voice messaging ports and endpoints, for example, phones or gateways. Only audio streams are encrypted. Media encryption creates a media master key pair for the devices, delivers the keys to Cisco Unity and the endpoint, and secures the delivery of the keys while the keys are in transport. Cisco Unity and the endpoint use the keys to encrypt and decrypt the media stream.

This feature protects against:

Man-in-the-middle attacks that listen to the media stream between Cisco Unified CM and the Cisco Unity voice messaging ports.

Network traffic sniffing that eavesdrops on phone conversations that flow between Cisco Unified CM, the Cisco Unity voice messaging ports, and IP phones that are managed by Cisco Unified CM.

Authentication and signaling encryption are required for media encryption; that is, if the devices do not support authentication and signaling encryption, media encryption cannot occur.


Note that Cisco Unified CM authentication and encryption protects only calls to Cisco Unity. Messages recorded on the message store are not protected by Cisco Unified CM authentication and encryption but can be protected by the Cisco Unity secure messaging feature.


Note The secure messaging feature is available only when Exchange is the message store.


For more information on secure messaging, see the "Securing Subscriber Messages" chapter of the Security Guide for Cisco Unity Release 5.x (With Microsoft Exchange) at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_maintenance_guides_list.html.

Authentication and encryption between Cisco Unity and Cisco Unified CM require:

A Cisco Unified CM CTL file that lists all Cisco Unified CM servers that are entered in Cisco Unity Telephony Integration Manager (UTIM) for secure clusters.

A Cisco Unity server root certificate for each Cisco Unity that uses authentication and/or encryption. A root certificate is valid for 20 years from the time it was created.

Cisco Unity voice messaging port device certificates that are rooted in the Cisco Unity server root certificate and that the voice messaging ports present when registering with the Cisco Unified CM server.

The process of authentication and encryption of Cisco Unity voice messaging ports is as follows:

1. Each Cisco Unity voice messaging port connects to the TFTP server, downloads the CTL file, and extracts the certificates for all Cisco Unified CM servers.

2. Each Cisco Unity voice messaging port establishes a network connection to the Cisco Unified CM TLS port through Winsock. By default, the TLS port is 2443, though the port number is configurable.

3. Each Cisco Unity voice messaging port establishes a TLS connection to the Cisco Unified CM server, verifies the device certificate, and authenticates the voice messaging port.

4. Each Cisco Unity voice messaging port registers with the Cisco Unified CM server, specifying whether the voice messaging port will also use media encryption.

When Data Is Encrypted

When a call is made between Cisco Unity and Cisco Unified CM, the call-signaling messages and the media stream are handled in the following manner:

If both end points are set for encrypted mode, the call-signaling messages and the media stream are encrypted.

If one end point is set for authenticated mode and the other end point is set for encrypted mode, the call-signaling messages are authenticated, but neither the call-signaling messages nor the media stream are encrypted.

If one end point is set for non-secure mode and the other end point is set for encrypted mode, neither the call-signaling messages nor the media stream are encrypted.

Cisco Unified Communications Manager Cluster Security Mode Settings in Cisco Unity

The Cisco Unified CM cluster security mode settings in the Cisco Unity Telephony Integration Manager (UTIM) determine how the ports handle call-signaling messages and whether encryption of the media stream is possible. Table 6-4 describes the effect of the Cluster Security Mode settings in UTIM.

Table 6-4 Cisco Unified Communications Manager Cluster Security Mode Settings for Voice Messaging Ports 

Setting
Effect

Non-secure

The integrity and privacy of call-signaling messages will not be ensured because call-signaling messages will be sent as clear (unencrypted) text and will be connected to Cisco Unified CM through a non-authenticated port rather than an authenticated TLS port.

The media stream is not encrypted.

Authenticated

The integrity of call-signaling messages will be ensured because they will be connected to Cisco Unified CM through an authenticated TLS port. However, the privacy of call-signaling messages will not be ensured because they will be sent as clear (unencrypted) text.

The media stream is not encrypted.

Encrypted

The integrity and privacy of call-signaling messages will be ensured because they will be connected to Cisco Unified CM through an authenticated TLS port, and the call-signaling messages will be encrypted.

The media stream can be encrypted.


Caution Both end points must be registered in encrypted mode for the media stream to be encrypted. However, when one end point is set for non-secure or authenticated mode and the other end point is set for encrypted mode, the media stream will not be encrypted. Also, if an intervening device (such as a transcoder or gateway) is not enabled for encryption, the media stream will not be encrypted.

Disabling and Re-Enabling Security

The authentication and encryption features between Cisco Unity and Cisco Unified CM can be enabled and disabled by changing the Cisco Unified CM Cluster Security Mode for all Cisco Unified CM clusters to Non-Secure, and by changing the applicable settings in the Cisco Unified CM Administration.

Authentication and encryption can be re-enabled by changing the Cisco Unified CM Cluster Security Mode to Authenticated or Encrypted.

Note that after disabling or re-enabling authentication and encryption, it is not necessary to export the Cisco Unity server root certificate and copy it to all Cisco Unified CM server.

Multiple Integrations Can Have Different Security Mode Settings

When Cisco Unity is integrated with multiple Cisco Unified CM clusters, each cluster can have a different setting for Cisco Unified CM Cluster Security Mode. For example, Cluster 1 can be set to Encrypted, and Cluster 2 can be set to Non-Secure.

Settings for Individual Voice Messaging Ports

For troubleshooting purposes, authentication and encryption for Cisco Unity voice messaging ports can be individually enabled and disabled. At all other times, we recommend that the Security Mode setting for all voice messaging ports on the Ports tab be the same as the Cisco Unified CM Cluster Security Mode setting on the Servers tab.

Packetization (SCCP Integrations Only)

The Real-Time Transport Protocol (RTP) is used to send and receive audio packets over the IP network. Each discrete packet has a fixed-size header, but the packets themselves can vary in size, depending on the size of the audio stream to be transported (which varies by codec) and the packetization setting. This variable size function helps utilize network bandwidth more efficiently. Reducing the number of packets that are created per call sends fewer total bytes over the network.

Packetization is set in the Cisco Unified CM Service Parameters, in the Preferred G711 Millisecond PacketSize and Preferred G729 Millisecond PacketSize parameters. Cisco Unity supports any packet size up to 30ms for G.711 audio, and any packet size up to 60 ms for G.729a audio. The default setting is 20ms for both; there may be latency issues with lower settings.

DSCP is a priority setting on each packet. DSCP helps intermediary routers manage network congestion and lets them know which packets to prioritize ahead of others. Following Cisco AVVID standards, the Cisco Unity-CM TSP marks the SCCP packets (call control) with a default DSCP value of 26 (the TOS octet is 0x68), and the RTP packets (audio traffic) with a default DSCP value of 46 (the TOS octet is 0xB8). Thus, the RTP audio packets can be assigned priority over other packets by using the router settings. Note that even though Cisco Unified CM allows you set different DSCP values, when integrated with Cisco Unity, the DSCP values set by the Cisco Unity-CM TSP always take precedence.

With each new audio stream (once per call), Cisco Unified CM tells Cisco Unity which packet size to use, and the Cisco Unity-CM TSP sets the DSCP priority for the stream. The entire stream (call) stays at the specified packet size and priority. For example, an audio stream could be broken up into packets of 30ms each. A 30ms G.729a audio stream would be 30 bytes plus the header per packet, and a 30ms G.711 stream would be 240 bytes plus the header per packet. For information on setting Cisco Unified CM Service Parameters, see the Cisco Unified CM documentation at http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html.

Integrating with Cisco Unified Communications Manager Express (by Using SCCP or SIP)

Cisco Unity supports Cisco Unified Communications Manager (CM) Express (formerly known as Cisco Unified CallManager Express) integrations through both SCCP and SIP interfaces. Figure 6-8 shows the connections.

Figure 6-8 Cisco Unity SCCP and SIP Connections to Cisco Unified Communications Manager Express Over a LAN

See Table 6-5 for information on the differences in these integration methods.

Table 6-5 Differences Between SCCP and SIP Integration Methods 

Feature
SCCP
SIP

Communication method

Cisco Unity-CM TSP

SIP trunk

Failover

Supported

Not supported

Use of SCCP and SIP phones

Supported

Some SCCP phones may require use of a media termination point (MTP)

Support for Cisco Unified CM versions

All versions

Versions 5.x and later

Cisco Unified CM versions 5.x and later

Supported

Supported

Cisco Unified CM authentication and encryption

Supported

Not supported

First/last redirecting number

Supported

Supported

QOS

Supported

Supported


For information on the compatibility of Cisco Unity and Cisco Unified CM Express versions with the Cisco Unity-CM TSP and the SIP trunk, see the following documents at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_device_support_tables_list.html:

SCCP Compatibility Matrix: Cisco Unity, the Cisco Unity-CM TSP, Cisco Unified Communications Manager, and Cisco Unified Communications Manager Express

SIP Trunk Compatibility Matrix: Cisco Unity and Cisco Unified Communications Manager

For information on how to integrate Cisco Unity with Cisco Unified CM Express, see the applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

For more information on using the SIP protocol to integrate Cisco Unity with Cisco Unified CM Express, see the "Integrating by Using SIP" section.

Multiple Cisco Unified Communications Manager Express Version Support

A single Cisco Unity server can support multiple versions of Cisco Unified CM Express. The version of the Cisco Unity-CM TSP or SIP trunk being used must support all versions of Cisco Unified CM Express integrated with Cisco Unity. See the following documents at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_device_support_tables_list.html:

SCCP Compatibility Matrix: Cisco Unity, the Cisco Unity-CM TSP, Cisco Unified Communications Manager, and Cisco Unified Communications Manager Express

SIP Trunk Compatibility Matrix: Cisco Unity and Cisco Unified Communications Manager

Multiple Cisco Unified Communications Manager Express Routers Integrating with a Single Cisco Unity Server

A single, centralized Cisco Unity server can be used by multiple Cisco Unified CM Express routers. This configuration requires that one Cisco Unified CM Express router be on the same LAN or WAN as the Cisco Unity server, and that this Cisco Unified CM Express router register all Cisco Unity voice messaging ports. The Cisco Unified CM Express router (the SIP MWI server) is a proxy server that relays SIP MWI messages between the Cisco Unity and all other Cisco Unified CM Express routers (the SIP MWI clients). Note that Cisco Unity voice messaging ports register with only the SIP MWI server (the Cisco Unified CM Express router that is on the same LAN as the Cisco Unity server), not with the SIP MWI clients.

Figure 6-9 Connections Between Multiple Cisco Unified CM Express Routers and a Single Cisco Unity Server

For information on configuring Cisco Unity to support multiple Cisco Unified CM Express routers, see the applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

Integrating Cisco Unity with Cisco Survivable Remote Site Telephony (Cisco SRST)

Cisco Unified Survivable Remote Site Telephony (SRST) can send and receive voice messages from Cisco Unity during Cisco Unified CM fallback. When the WAN is down and Cisco Unity has Basic Rate Interface (BRI) or Primary Rate Interface (PRI) access to the Cisco SRST system, Cisco Unity uses ISDN signaling (see Figure 6-10).

Figure 6-10 Cisco Unified Communications Manager Fallback with BRI or PRI

When the WAN is down and Cisco Unity has foreign exchange office (FXO) or foreign exchange station (FXS) access connect to a public switched telephone network (PSTN), Cisco Unity uses in-band dual tone multifrequency (DTMF) signaling (see Figure 6-11).

Figure 6-11 Cisco Unified Communications Manager Fallback with PSTN

In both configurations, phone message buttons remain active and calls to busy or unanswered numbers are forwarded to Cisco Unity. The installer must configure access from the dial peers to the voice-mail system, and establish routing to Cisco Unity for busy and unanswered calls and for the message button.

If Cisco Unity is accessed over FXO or FXS, you must configure instructions (DTMF patterns) for Cisco Unity so it can access the correct voice-mail system mailbox.

When using Cisco Unified SRST with Cisco Unity, the integration has the following limitations during a WAN outage:

Call forward to busy greeting

When the Cisco Unified SRST router uses FXO/FXS connections to the PSTN and a call is forwarded from a branch office to Cisco Unity, the busy greeting cannot play.

Call forward to internal greeting

When the Cisco Unified SRST router uses FXO/FXS connections to the PSTN and a call is forwarded from a branch office to Cisco Unity, the internal greeting cannot play. Because the PSTN provides the calling number of the FXO line, the caller is not identified as a subscriber.

Call transfers

Because an access code is needed to reach the PSTN, call transfers from Cisco Unity to a branch office will fail.

Identified subscriber messaging

When the Cisco Unified SRST router uses FXO/FXS connections to the PSTN and a subscriber at a branch office leaves a message or forwards a call, the subscriber is not identified. The caller appears as an unidentified caller.

Message waiting indication

MWIs are not updated on branch office phones, so MWIs will not correctly reflect when new messages arrive or when all messages have been listened to. We recommend resynchronizing MWIs after the WAN link is reestablished.

Message notification

Because an access code is needed to reach the PSTN, message notifications from Cisco Unity to a branch office will fail.

Routing rules

When the Cisco Unified SRST router uses FXO/FXS connections to the PSTN and a call arrives from a branch office to Cisco Unity (either a direct or forwarded call), routing rules will fail.


When the Cisco Unified SRST router uses PRI or BRI connections, the caller ID for calls from a branch office to Cisco Unity may be the full number (exchange plus extension) provided by the PSTN and therefore may not match the extension of the Cisco Unity subscriber. In this case, you can let Cisco Unity recognize the caller ID by using alternate extensions or by using extension remapping. For information on extension remapping, see the "Remapping Extension Numbers" section of the "Managing System-Wide Settings" chapter in the applicable System Administration Guide for Cisco Unity Release 5.x, available at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_maintenance_guides_list.html.)

When using Cisco Unified SRST, Redirected Dialed Number Information Service (RDNIS) must be supported.

For information on setting up Cisco Unified SRST routers, see the "Integrating Voice Mail with Cisco Unified SRST" section of the Cisco Unified SRST System Administrator Guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_installation_and_configuration_guides_list.html.

Impact of Non-Delivery of RDNIS on Voice Mail Calls Routed via AAR

RDNIS needs to be supported when using Automated Alternate Routing (AAR).

AAR can route calls over the PSTN when the WAN is oversubscribed. However, when calls are rerouted over the PSTN, RDNIS can be affected. Incorrect RDNIS information can affect voice mail calls that are rerouted over the PSTN by AAR when Cisco Unity is remote from its messaging clients. If the RDNIS information is not correct, the caller will not reach the mailbox of the dialed user but will instead receive the automated attendant prompt, and the caller might be asked to reenter the extension number of the party they want to reach. This behavior is primarily an issue when the telephone carrier is unable to ensure RDNIS across the network. There are numerous reasons why the carrier might not be able to ensure that RDNIS is properly sent. Check with your carrier to determine whether it provides guaranteed RDNIS delivery end-to-end for your circuits. The alternative to using AAR for oversubscribed WANs is simply to let callers hear reorder tone in an oversubscribed condition.

Integrating Cisco Unity with Cisco Unified Communications Manager Express in SRST Mode

Cisco Unity supports a topology with centralized call processing and distributed messaging, in which your Cisco Unity server is located at a remote site or branch office and registered with the Cisco Unified CM at a central site.

When the WAN link fails, the phones fall back to the Cisco Unified CM Express-as-SRST device. Cisco Unity can also fall back to the Cisco Unified CM Express-as-SRST device, which lets users at the remote site access their voice messages and see message waiting indicators (MWIs) during a WAN outage. Note that MWIs must be resynchronized from the Cisco Unity server whenever a failover happens from Cisco Unified CM to Cisco Unified CM Express-as-SRST or vice versa.

For information on setting up this configuration, see the Integrating Cisco Unity with Cisco Unified CME-as-SRST application note at http://www.cisco.com/en/US/products/sw/voicesw/ps4625/prod_troubleshooting_guides_list.html.

Integrating by Using SIP

SIP (Session Initiation Protocol) is the Internet Engineering Task Force standard for multimedia calls over IP. SIP is a peer-to-peer, ASCII-based protocol that uses requests and responses to establish, maintain, and terminate calls (or sessions) between two or more end points. A SIP network uses the following components:

SIP proxy server

The proxy server is an intermediate device that receives SIP requests from a client and then forwards the requests on behalf of the client. Proxy servers receive SIP messages and forward them to the next SIP server in the network. Proxy servers can provide functions such as authentication, authorization, network access control, routing, reliable request retransmission, and security.

Redirect server

Provides information to the client about the next hop or hops that a message should take. The client then contacts the next hop server or user-agent server directly.

Registrar server

Processes requests from user agent clients for registration of their current location. Registrar servers are often installed on the redirect or proxy server.

Phones

Can act as either a server or client. Softphones (PCs that have phone capabilities installed) and Cisco SIP IP phones can initiate SIP requests and respond to requests.

Gateways

Provide call control. Gateways provide many services; the most common is a translation function between SIP call endpoints and other terminal types. This function includes translation between transmission formats and between communications procedures. In addition, the gateway translates between audio and video codecs, and performs call setup and clearing on both the LAN side and the switched-circuit network side.


Cisco Unity accepts calls from a proxy server. Cisco Unity relies on a proxy server or call agent to authenticate calls.

SIP uses a request/response method to establish communications between various components in the network and to ultimately establish a conference (call or session) between two or more endpoints. A single call may involve several clients and servers.

Users in a SIP network are identified by:

A unique phone or extension number.

A unique SIP address, which is similar to an e-mail address and uses the format sip:<userID>@<domain>. The user ID can be either a user name or an E.164 address.

When a user initiates a call, a SIP request typically goes to a SIP server (either a proxy server or a redirect server). The request includes the caller's address (From) and the address of the called party (To).

SIP messages are in text format using ISO 10646 in UTF-8 encoding (like HTML). In addition to the address information, a SIP message contains a start-line specifying the method and the protocol, a number of header fields specifying call properties and service information, and an optional message body which can contain a session description.

Supported SIP Integrations

Cisco Unity currently supports the following SIP integrations:

SIP trunks to selected versions of Cisco Unified Communications Manager and Cisco Unified Communications Manager Express. For a list of Cisco Unified CM and Cisco Unified CM Express versions supported as SIP trunks, see SIP Trunk Compatibility Matrix: Cisco Unity and Cisco Unified Communications Manager at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_device_support_tables_list.html.

Cisco SIP Proxy Server (CSPS). However, CSPS is being phased out, so using it for a SIP integration is not encouraged.

Third-party SIP trunks are currently not supported.

For more information on configuring SIP trunks between Cisco Unity and Cisco Unified CM or Cisco Unified CM Express, see the applicable SIP trunk integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

Cisco Unity Failover with SIP Trunks

Cisco Unity failover is not supported with either the Cisco Unified CM SIP trunk integration or the Cisco Unified CM Express SIP trunk integration. If Cisco Unity failover is a requirement, you must use the Skinny Call Control Protocol (SCCP) integration with Cisco Unified CM. A customer can continue to use SIP phones when integrating with Cisco Unified CM using the SCCP integration. Once a call is established between a SIP phone and Cisco Unity, which is using Skinny, the RTP session between the two endpoints will work properly.

Note that Cisco Unity failover is not supported for Cisco Unified CM Express using either the SIP trunk integration or SCCP integration.

SIP Compliance

For information on Cisco Unity compliance with the SIP standard, see SIP Compliance for Cisco Unity at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_white_papers_list.html.

Integrating with Circuit-Switched Phone Systems by Using PIMG or TIMG Units

Cisco Unity can integrate with circuit-switched phone systems by using the Dialogic Media Gateway (PIMG or TIMG units) between circuit-switched phone systems and IP networks.

For a list of circuit-switched phone systems currently supported with Cisco Unity using PIMG and TIMG integrations, see the "Supported Phone System Integrations" section of Supported Hardware and Software, and Support Policies for Cisco Unity Release 5.x. at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_installation_guides_list.html.

Description of PIMG Integrations

The PIMG integration uses one or more PIMG units between the circuit-switched phone systems and IP network. On the circuit-switched phone system side, there are both digital (feature-set) and analog interfaces; the interface used will depend on the phone system to which Cisco Unity is connected. On the IP side, there is a SIP interface, which is how Cisco Unity communicates with the PIMG gateway. To Cisco Unity, the integration is essentially a SIP integration. Cisco Unity communicates with the PIMG gateway over the IP network using SIP and RTP protocols. The PIMG gateway communicates with the circuit-switched phone system over the phone network using phone system-specific protocols (digital, analog, serial). Note that there are digital integrations for circuit-switched phone systems from several vendors, which are tighter integrations than the Cisco Unity analog integrations using voice cards.

Digital Integration with Digital PIMG Units

The phone system sends call information, MWI requests, and voice connections through the digital lines, which connect the phone system to the PIMG units. The PIMG units communicate with the Cisco Unity server through the LAN or WAN by using Session Initiation Protocol (SIP). Figure 6-12 shows the connections for a digital integration by using digital PIMG units.

Figure 6-12 Connections for a Digital Integration by Using Digital PIMG Units

DTMF Integration with Analog PIMG Units

The phone system sends call information, MWI requests, and voice connections through the analog lines, which connect the phone system to the PIMG units. The PIMG units communicate with the Cisco Unity server through the LAN or WAN by using Session Initiation Protocol (SIP). Figure 6-13 shows the connections for a DTMF integration by using analog PIMG units.

Figure 6-13 Connections for a DTMF Integration by Using Analog PIMG Units

Serial (SMDI, MCI, or MD-110) Integration with Analog PIMG Units

The phone system sends call information and MWI requests through the data link, which is an RS-232 serial cable that connects the phone system and the master PIMG unit. Voice connections are sent through the analog lines between the phone system and the PIMG units. The PIMG units communicate with the Cisco Unity server through the LAN or WAN by using Session Initialization Protocol (SIP). Figure 6-14 shows the connections for a serial integration by using analog PIMG units.

Figure 6-14 Connections for a Serial (SMDI, MCI, or MD-110) Integration by Using Analog PIMG Units


Note When you use multiple PIMG units, one PIMG unit must be designated the master PIMG unit, which will be connected to the serial cable. It is not possible to "daisy chain" the serial ports on the PIMG units.

You can add a secondary master PIMG unit to an integration. For details, see the PIMG Integration Guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.


Description of TIMG Integrations

The TIMG integration uses one or more TIMG units between circuit-switched phone systems and IP networks. On the circuit-switched phone system side, there is a T1-CAS interface. On the IP side, there is a SIP interface, which is how Cisco Unity communicates with the TIMG unit. To Cisco Unity, the integration is essentially a SIP integration. Cisco Unity communicates with the TIMG unit over the IP network using SIP and RTP protocols. The TIMG unit communicates with the circuit-switched phone system over the phone network using serial protocols (SMDI, MCI, or MD-110).

The phone system sends call information and MWI requests through the data link, which is an RS-232 serial cable that connects the phone system and the master TIMG unit. Voice connections are sent through the T1 digital lines between the phone system and the TIMG units. The TIMG units communicate with the Cisco Unity server through the LAN or WAN by using SIP. Figure 6-15 shows the connections.

Figure 6-15 Connections for an Integration by Using TIMG Units

Setup and Configuration

For PIMG/TIMG setup and configuration, the installer does the following steps as documented in the applicable integration guide:

1. Configure the phone system.

2. Configure the PIMG/TIMG units. PIMG/TIMG settings are somewhat phone system-specific, but less so than phone system configuration.

3. Configure Cisco Unity for the integration.

For information on configuring the phone system, PIMG/TIMG units, and Cisco Unity, see the applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

Firmware Updates

Note that when receiving shipment of PIMG or TIMG units, it may be necessary to update the firmware on the units. The PIMG/TIMG Admin interface provides a simple method to update the firmware files. Firmware updates are available on CCO (Cisco Connection Online). See the applicable integration guide or check for the latest firmware updates on the Cisco Unity PIMG page at http://www.cisco.com/cgi-bin/tablebuild.pl/unity-PIMG.

Serial Integrations

Cisco Unity supports the following serial protocols:

SMDI

MCI

MD-110

When older versions of Cisco Unity integrated with a circuit-switched phone system by using a serial integration, if the phone system did not use standard serial packets (such as SMDI or MCI), it was possible to adjust the serial packet definitions by using Cisco Unity .avd files. Unfortunately, PIMG/TIMG units do not allow customization of serial packet definitions, so only phone systems that comply with the standards will work.

The serial port on PIMG unit was originally designed as a management port rather than as a standard RS-232 serial port. Consequently, a custom serial cable (which is available from Cisco) is necessary for the datalink between the phone system and the master PIMG unit. The pinout of the custom serial cable is available in the PIMG Integration Guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

Increasing Port Capacity

PIMG units have eight ports. To increase system port capacity, multiple PIMG units can be stacked. For example, if 32 ports are needed, 4 PIMG units can be stacked. When stacking two or more PIMG units, each PIMG unit must communicate with Cisco Unity by using a different IP port. The first PIMG talks to Cisco Unity port 5060, and each successive unit uses the next higher port (5061, 5062, and so on).

TIMG units, which integrate with circuit-switched phone systems that support T1-CAS, have 24 T1 ports per span in a single rack-optimized unit. Single span and dual span TIMG units are available.

Cisco Unity Failover

PIMG/TIMG integrations support Cisco Unity failover. Configuration changes are required both for the PIMG/TIMG units and for the Cisco Unity servers, as described in the applicable integration guide. The IP addresses of both Cisco Unity servers must be entered in each PIMG/TIMG unit. The settings in UTIM (Cisco Unity Telephony Integration Manager) for the secondary Cisco Unity server must match those of the primary Cisco Unity server. This includes the integration number, which may vary.

Cisco Unity failover is different for PIMG/TIMG integrations in that a Cisco Unity server cannot explicitly tell a PIMG unit whether it is active and should receive calls. Rather, PIMG/TIMG units will infer the active server based upon which Cisco Unity server responds to incoming calls and upon keepalive messages received from the primary Cisco Unity server. When the primary Cisco Unity server is active, the PIMG/TIMG units will send calls to it. If the primary server does not answer or send keepalive messages, the PIMG/TIMG units will pull the call back and send it to the secondary Cisco Unity server. When the secondary Cisco Unity server answers, the PIMG/TIMG units will assume the secondary is the active server, and route all further calls to the secondary server. While the secondary Cisco Unity server is active, the PIMG/TIMG units will send periodic keepalive messages to the primary server. When the primary Cisco Unity server responds, the PIMG/TIMG units will route calls to the primary server.

The connections for a PIMG integration with Cisco Unity failover are shown in Figure 6-16.

Figure 6-16 Connections for a PIMG Integration with Cisco Unity Failover

Cisco Unity Failback

Before failing back from the secondary server to the primary server, you must first disable automatic failover. Otherwise, the PIMG/TIMG units will continue to send INVITE messages to the secondary server for new calls, which will cause failover to occur before failback has completed. Do the following procedure when initiating failback from the secondary Cisco Unity server to the primary server.

To Initiate Failback from a Secondary Cisco Unity Server to the Primary Server


Step 1 On the Windows Start menu, click Programs > Cisco Unity > Failover Monitor.

Step 2 Click Configure.

Step 3 Uncheck the Force Failover If Call Arrives on Inactive Secondary check box, and click OK.

Step 4 Initiate failback, and wait at least 10 seconds.

Step 5 Re-enable automatic failover.


Multiple Integration Support/Branch Office Consolidation

Cisco Unity does not limit the number of PIMG integrations. It is possible, though not practical, to create 144 separate phone system integrations with one port each for a total of 144 ports and 144 PIMG units.

PIMG unit can be placed across a WAN to support circuit-switched phone systems at remote branch office sites. Cisco Unity would be placed at a centralized headquarters, for example, and support circuit-switched phone systems both at headquarters and at branch office sites.

Assuming there are four phone systems from four different manufacturers (for example, Nortel, Avaya, NEC, and Siemens), four different integrations will be created on the Cisco Unity server to support the four phone systems. Across those four integrations, Cisco Unity can support 144 ports. For example:

At the Seattle site, 15 PIMG units can be stacked to support 122 ports.

At the New York site, two PIMG units can be stacked to support 16 ports.

At the Tokyo site, one PIMG unit can be used to support four ports.

At the Dallas site, one PIMG unit can be used to support two ports.

Even though the PIMG units come with eight ports, fewer than eight ports can be used on each unit.

If PIMG units will be placed across a WAN to support remote phone systems, proper codec selection, bandwidth capacity planning, and QOS planning are required. Both the G729a and G711 codec are supported by PIMG units and by Cisco Unity. Because PIMG units are Dialogic rather than Cisco devices, the use of location-based CAC is not applicable. The following network and bandwidth requirements are required when placing the PIMG across a WAN:

For G.729a codec formatting, a minimum of 32.76 Kbps (assumes Ethernet, payload of 20 bytes, 5 percent overhead) guaranteed bandwidth for each voice messaging port

For G.711 codec formatting, a minimum of 91.56 Kbps (assumes Ethernet, payload of 160 bytes, 5 percent overhead) guaranteed bandwidth for each voice messaging port

No network devices that implement network address translation (NAT)


Note When the G.729a codec is used, Cisco Unity cannot perform silence detection. Using this codec may result in messages that have long trailing silence or that are entirely silent.


When placing PIMG units across a WAN, prioritize your call control and media traffic via proper QOS traffic, marking for voice traffic originating on the PIMG units. Set the Call Control QOS Byte and RTP QOS Byte on PIMG units to the following values:

Call Control QOS Byte

PIMG units connect only to a LAN: 0 (CSCsb96387)

PIMG units connect to a WAN: 104

RTP QOS Byte

PIMG units connect only to a LAN: 0 (CSCsb96387)

PIMG units connect to a WAN: 184


Note that the Call Control and RTP QOS byte parameters on PIMG units define a decimal value that represents QOS bit flags. These values can be interpreted as either IPv4 TOS or Differentiated Services Codepoint (DSCP). For more details, see the applicable PIMG User Guide.

Support for integrations with multiple circuit-switched phone systems up to a maximum of 144 ports allows Cisco Unity to consolidate multiple branch office sites into one centralized Cisco Unity server. For more information, see the "Integrating with Multiple Phone Systems" section.

Integrating with Multiple Phone Systems

Beginning with Cisco Unity 5.0(1), Cisco Unity supports as many integrations as necessary up to 144 ports. For example, you can create 144 integrations, each with only one port, for a total of 144 ports.

Requirements for Integrations with Multiple Phone Systems

Cisco Unity has the following requirements for multiple phone system integrations:

All phone system and Cisco Unity server requirements have been met. See the applicable Cisco Unity integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

There must be an adequate number of voice messaging ports on the Cisco Unity server to connect to the phone systems. This number must not exceed the number of ports that are enabled by the Cisco Unity license files.

For a single Cisco Unity server (or a failover pair), all extensions must be unique. The dial plans for the phone systems must not overlap.

If overlapping dial plans cannot be avoided, you must install a Cisco Unity server for each phone system, digitally network the servers, and set up dialing domains to accommodate the overlapping dial plans. See the applicable Networking Guide for Cisco Unity Release 5.x at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_feature_guides_list.html.

For limitations on combinations for multiple phone system integrations, see the "Combination Limitations for Multiple Phone System Integrations" section in the Multiple Phone System Integration Guide for Cisco Unity 5.0 at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

Using SCCP Phone Systems with Other Integrations

The SCCP phone system type includes integrations through SCCP (Skinny Call Control Protocol) with Cisco Unified Communications Manager and with Cisco Unified Communications Manager Express.

For Cisco Unified CM phone systems, you can add Cisco Unified CM clusters in UTIM as separate phone system integrations or as new clusters to an existing Cisco Unified CM integration. For more information, see the "Creating an Integration with a Second Cluster of Cisco Unified Communications Manager" section in the applicable Cisco Unified CM integration guide at http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_installation_and_configuration_guides_list.html.

Cisco Unity can integrate with Cisco Unified CM Express in SRST mode. For details, see the Integrating Cisco Unity with Cisco Unified CME-as-SRST application note at http://www.cisco.com/en/US/products/sw/voicesw/ps4625/prod_troubleshooting_guides_list.html.

Notes for PIMG Integrations

There is no limit on the number of PIMG units that you can use. If you want to connect PIMG units to different phone systems, add the PIMG units that are connected to one phone system to one integration, and add the PIMG units that are connected to a different phone system to another integration.

Optional Integration Features

See the following sections:

Alternate Extensions

Alternate MWIs

Alternate Extensions

In addition to the primary extension that you specify for each subscriber, you can assign a subscriber up to nine alternate extensions. (The primary extension is the one that you assign to each subscriber when you create his or her subscriber account; in the Cisco Unity Administrator, it is listed on the Subscribers > Subscribers > Profile page.)

Reasons to Use Alternate Extensions

There are several reasons that you may want to specify alternate extensions for subscribers. For example, if you have more than one Cisco Unity server that accesses a single, corporate-wide directory, you may want to use alternate extensions to simplify addressing messages to subscribers at the different locations. With alternate extensions, the number that a subscriber uses when addressing a message to someone at another location can be the same number that the subscriber dials when calling. You may also want to use alternate extensions to:

Handle multiple line appearances on subscriber phones.

Offer easy message access on direct calls from a cell phone, home phone, or phone at an alternate work site (assuming that the phone number is passed along to Cisco Unity from these other phone systems). In addition, when such phones are used as alternate extensions, and are set to forward to Cisco Unity, callers can listen to the subscriber greeting, and leave messages for the subscriber just as they would when dialing the primary extension for the subscriber.

Enable URL-based extensions in Cisco Unity for an integration with a SIP phone system.

To reduce the number of requests from subscribers who want alternate extensions set up for multiple cell phones, home phones, and other phones, give subscribers class of service (COS) rights to specify their own set of alternate extensions. (In the Cisco Unity Administrator, see the Subscribers > Class of Service > Profile page.) With proper COS rights, a subscriber can specify up to five alternate extensions in the Cisco Unity Assistant in addition to the nine that you can specify on the Subscribers > Alternate Extensions page in the Cisco Unity Administrator.

How Alternate Extensions Work

Before you set up alternate extensions, review the following list for information on how alternate extensions work:

Alternate extensions cannot exceed 30 characters in length. By default, each administrator-defined alternate extension must be at least 3 characters in length, while subscriber-defined alternate extensions must be at least 10 characters.

You can use the Advanced Settings tool in Tools Depot to specify:

A minimum extension length for the extensions entered in the Cisco Unity Administrator. See the Administration—Set the Minimum Length for Locations setting.

A minimum extension length for the extensions entered in the Cisco Unity Assistant. See the Administration—Set the Minimum Length for Subscriber-Defined Alternate Extensions setting.

See the Advanced Settings Tool Help for details on using the settings.

You can control whether subscribers can use the Cisco Unity Assistant to view the alternate extensions that you specify in the Cisco Unity Administrator. To do so, see the Subscribers > Class of Service > Profile page. The Subscriber-Defined Alternate Extension table displays the alternate extensions that the subscriber adds.

Neither the Cisco Unity Administrator nor the Cisco Unity Assistant will accept an extension that is already assigned to another subscriber (either as a primary or alternate extension), or to a public distribution list, call handler, directory handler, or interview handler. Cisco Unity verifies that each alternate extension is unique—up to the dialing domain level, if applicable—before allowing either an administrator or a subscriber to create it.

All alternate extensions use the same transfer settings as the primary extension.

In many cases, Cisco Unity can activate a message waiting indicator (MWI) for an alternate extension. However, depending on the phones and phone systems involved, some additional phone system programming may be required to set this up.

Alternate MWIs

You can set up Cisco Unity to activate alternate MWIs when you want a new message for a subscriber to activate the MWIs at up to 10 extensions. For example, a message left at extension 1001 can activate the MWIs on extensions 1001 and 1002.

Cisco Unity uses MWIs to alert the subscriber to new voice messages. MWIs are not used to indicate new e-mail, fax, or return receipt messages.

In Cisco Unified Communications Manager integrations, you can also use the alternate MWI feature to activate MWIs on a non-integrated phone system that can send and receive information from Cisco Unity over an RS-232 serial cable.

Setting Up Alternate MWIs for Extensions on the Same Phone System

Cisco Unity can activate alternate MWIs for extensions on the same phone system. Depending on the phones and phone systems, some additional phone system programming may be necessary. Refer to the documentation for the phone system.

MWIs for Extensions on a Non-Integrated Phone System

Cisco Unity can activate MWIs on a phone system that is not integrated with Cisco Unity and that is not part of a two phone system integration (referred to here as a non-integrated phone system). MWI activation requests are sent through an RS-232 serial cable. Calls to subscribers that come from the non-integrated phone system are routed through the gateway to Cisco Unified Communications Manager.

For this method, you must set up:

A trunk connection between Cisco Unified CM and the non-integrated phone system through a gateway.

The unique subscriber extensions on the non-integrated phone system to forward on no answer to the corresponding phantom extensions on Cisco Unified CM.

The Switch.ini file (phone system configuration file) to enable Cisco Unity access through the serial cable for turning alternate MWIs on and off.

An RS-232 serial cable between a Cisco Unity serial port and the non-integrated phone system serial port to send alternate MWI activation requests.

The Cisco Unity serial configuration file, if the non-integrated phone system uses a serial configuration different from the default serial configuration used by Cisco Unity.

Figure 6-17 shows the connections via a serial cable between a Cisco Unified CM integration and a non-integrated phone system.

Figure 6-17 Connection for Sending Alternate MWIs via a Serial Cable to a Non-Integrated Phone System from a Cisco Unified Communications Manager Integration

Centralized Voice Messaging

Revised <TBD>

Cisco Unity supports centralized voice messaging by supporting various inter-phone system networking protocols including, for example, proprietary protocols such as Avaya DCS, Nortel MCDN, or Siemens CorNet, and standards-based protocols such as QSIG or DPNSS.

When discussing phone systems involved in centralized voice messaging, there are essentially two types:

Message Center PINX

The phone system hosts the voice messaging system (the phone system is directly connected to the voice messaging system).

Subscriber PINX

The phone system is remote from the voice messaging system (the phone system is not directly connected to the voice messaging system).


Centralized voice messaging provides voice messaging services to all subscribers in a networked phone system environment. Cisco Unity can be hosted on a message center PINX and provide voice messaging services to all subscribers in an enterprise assuming the message center PINX and all subscriber PINX phone systems are properly networked.

For a centralized voice messaging configuration to exist, a suitable inter-phone system networking protocol must exist to deliver a minimum level of feature support, such as:

Message waiting indication (MWI).

Transfer, which ensures that the correct calling/called party ID is delivered to the voice messaging system.

Divert, which ensures that the correct calling/called party ID is delivered to the voice messaging system.

Other features may be required depending on how the voice messaging system is to be used (for example, if it is also serving as an automated attendant then Path-Replacement will be needed as this feature will prevent calls from hair-pinning).

Not all phone systems can serve as a message center PINX. In this case, customers may wish to consider relocating Cisco Unity to Cisco Unified Communications Manager and have Cisco Unified CM act as the message center PINX with the circuit-switched phone system now acting as the subscriber PINX.

For information on configuring Cisco Unity in a centralized voice messaging environment to be hosted on Cisco Unified CM serving as the message center PINX, see the following:

The application note Cisco CallManager 4.1-Voicemail Interoperability: Cisco Unity 4.0(4) with Cisco CallManager 4.1(2) Configured as Message Center PINX Using Cisco Catalyst 6608 T1 Q.SIG with MGCP at http://www.cisco.com/application/pdf/en/us/guest/products/ps5820/c1072/ccmigration_09186a00803cad8f.pdf.

The applicable application note for configuring QSIG trunks between Cisco Unified Communications Manager and various circuit-switched phone systems on the Cisco Interoperability Portal at http://www.cisco.com/en/US/netsol/ns728/networking_solutions_products_generic_content0900aecd805b561d.html.

Note that if customers are deploying centralized voice messaging with Cisco Unity and a circuit-switched phone system, it is up to the customer to determine whether the circuit-switched phone system can serve as a message center PINX on which Cisco Unity can be hosted. If so, the customer should also confirm support for the desired features, for example, MWIs, transfer, divert, and path-replacement.

Inter-cluster trunks between Cisco Unified CM clusters can be QSIG enabled by using the Annex M.1 feature, which allows Cisco Unity to integrate with a single Cisco Unified CM cluster. Ports in the cluster with which Cisco Unity is integrated can be dedicated to turning MWIs on and off for phones in other clusters.