Cisco Unified Communications Manager (CallManager)

Document ID: 13929

Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Configuration Overview
Network Diagram
Verify CMI is Installed
Install and Configure FXS Ports
Create the Route Group
Create the Route List
Create the Route Pattern
Configure the CMI
General Notes
Troubleshoot
Example of VG200 Configuration Details
Example of Catalyst 6000 24-Port FXS Gateway Configuration Details
SMDI Redundancy
Redundancy Issues
NetPro Discussion Forums - Featured Conversations
Related Information

Introduction

With Simplified Message Desk Interface (SMDI) Integration, call information is transmitted over an RS-232 serial link between Cisco CallManager and the voice mail system. Voice communications are provided via a separate path created by a hunt group that consists of analog stations (Foreign Exchange Station (FXS) ports derived from either the VG200 gateway(s) or Catalyst 6000 24-port FXS Gateway(s) WS-X6624) between Cisco CallManager and the voice mail system. When the hunt group receives an incoming call, it is accompanied by a digital message in standard SMDI format from Cisco CallManager. This digital message contains all necessary call information. The voice mail system then answers the call on the specified port and plays the appropriate greeting. The voice mail system sends a digital message over the RS-232 serial link to Cisco CallManager in order to set or cancel the message-waiting notification.

Prerequisites

Requirements

Ensure that you meet these requirements before you attempt this configuration:

• A basic understanding of administration and configuration on Cisco CallManager.

Components Used

The information in this document is based on this software version:

• Cisco CallManager 3.x

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

Configuration Overview

1. Verify Cisco Messaging Interface (CMI) is installed.

2. Install and configure FXS ports VG200(s) or Catalyst 6000 24-port Gateway(s).

3. Create the Route Group.

4. Create the Route List.

5. Create the Route Pattern.

6. Configure CMI.

Note: This configuration uses Cisco CallManager version 3.0. There can be some differences in the appearance of the configuration pages in other versions of Cisco CallManager. The basic configuration, however, remains the same.

Network Diagram

This document uses this network setup.

Verify CMI is Installed

SMDI is enabled through the CMI application. This application is not part of the default installation and must be manually selected under Optional Components if SMDI is required. Once installed, CMI is available from the Service pull-down menu.

CMI can function in a Cluster, but must only reside on a single server within a Cluster. For example, you cannot have two CMI applications connected to the same voice mail system that run at the same time.

Additional voice mail systems require additional CMI applications. For example, there can be a Cluster with four active Cisco CallManagers and each CallManager can have its own voice mail system attached and therefore needs its own CMI application to run.

Install and Configure FXS Ports

This procedure shows Cisco CallManager configuration details for the analog ports.

1. Start with the configuration of the MGCP or Skinny gateway. In this case a 4-port VG200 MGCP gateway.

   

2. Ensure that you select FXS.

   

   Note: Analog ports are always configured as FXS ports when connecting to voice mail systems.

   The gateway now has four ports and Endpoint Identifiers.

   

3. Configure each port as a plain old telephone service (POTS) line.

   

4. Select the appropriate Device Pool for your configuration. In this case, it is Default. The Device Pool provisions the Cisco CallManager Redundancy Group, Time Zone, and Region.

   

5. Now that one port is configured as POTS, configure the remaining three in a similar manner.

   

   Note: Add DN appears next to the first POTS line. This is not required, as the POTS lines later form a Route Pattern from which the DN is derived.

   All four ports are now configured as POTS lines.

   

Create the Route Group

Complete these steps in order to create the Route Group.

1. Select an appropriate name for your Route Group.

   

2. Under the Device Name pull-down menu, select the POTS lines that you plan to add to the Route Group.

   

3. Select 1 under Port.

   If you select All, you are not able to assign the correct Order to the ports. For example, the selection of All always sends a Logical Terminal Number (LTN) of 1 within the SMDI packet, regardless of which port is actually seized. This results in subsequent Integration failure.

   

4. Select the Order this port will have within the Route Group. Once your selections are made, click Insert in order to add the port to the Route Group.

   

   One port is now successfully added to the Route Group.

   

5. Repeat the process. This time add the second port under Device Name.

   

6. Select Port 1.

   

   You now have the option to specify the position of where this port appears within the Route Group.

7. Select 2 under Order.

   

   

   Our Route Group now consists of two ports.

   

   Here, the Route Group is now complete and consists of four ports arranged in sequential order.

   

Create the Route List

Complete these steps in order to create a Route List which references the Route Group you created earlier.

1. Add the Route Group to the Route List.

   

2. Insert the Route List.

   

   The Route List now appears similar to this:

   

Create the Route Pattern

Assign a DN for the Route Pattern. In this example, it is 4000.

Make sure the Provide Outside Dial Tone box is not checked. If left checked, subscribers receive secondary dial-tone as soon as the first digit is entered. Some subscribers can find this confusing.

Configure the CMI

Configure the CMI. Select the server that will run this application.

This is the screen that allows configuration of the VoiceMailDN, as well as BaudRate, SerialPort and other necessary parameters.

Configure these parameters within CMI:

• CallManagerName - If this parameter is left blank, CMI tries to connect to the local host.

• BackUpCallManager - In a clustered environment, it is recommended that CMI be given a primary (CallManagerName) and backup (BackUpCallManager). It does not cost anything, and it ensures that you get voice mail service in the event the primary is down.

• VoiceMailDn - You must configure this parameter as this is the parameter that triggers CMI into providing SMDI packets whenever a call is sent to the number specified.

• SerialPort - The default is COM1. The COM port MUST be dedicated to CMI.

• BaudRate - Select the appropriate value for the voice mail system you connect to. The default is 9600.

• Parity - Select the appropriate value for the voice mail system you connect to. The default is Even.

• DataBits - Select the appropriate value for the voice mail system you connect to. The default is 7.

• StopBits - Select the appropriate value for the voice mail system you connect to. The default is 1.

These parameters are optional and in the majority of cases do not require any modification:

• OutputDnFormat - The default is %010s. This parameter allows you to pad the output string with a specified digit. In this case the % character is a formatting command. The character string 010s tells CMI to format the SMDI message as a 10-digit string with leading 010s. For example, in order to have CMI output a 7-digit string, configure OutputDnFormat as %07s. The 's' tells CMI to output the result as a string.

• OutputExternalFormat - The default is %010s. This parameter has a number of different functions:

  • When a voice mail system expects a string length greater than the extension length on Cisco CallManager and you need to add a prefix, the configuration of OutputExternalFormat as 525%4s results in a string of 5251234 for extension 1234.

  • When you need to output a specific digit length, for example, %010s generates 0000001234, %020s generates 00000000000000001234, and 10s generates 1234.

• InputDnSignificantDigits - The default is 10. In the case of our voice mail system that sends a 7-digit string for message waiting indicator (MWI) commands to a Cisco CallManager system configured for 4-digit extensions, we configure InputDnSignificantDigits to 4. In other words, we are keeping the 4 least significant digits.

General Notes

• In order to configure the messages button of the subscriber, use the parameter VoiceMail. You can find this parameter in the pull-down menu located at Service > Service Parameters > Cisco CallManager. Restart Cisco CallManager in order to have this change take effect.

• SMDI link messages sent to the voice mail system by Cisco CallManager for forwarded calls always provide A as the forwarding reason-code. Forwarding reason-code A indicates forward all-calls. The correct forwarding reason-codes, N for no-answer and B for busy, are not supported at this time. Some voice mail systems, such as Octel products, can be configured to provide different greetings based on the forwarding reason-code received. This voice mail feature is not supported when used in conjunction with Cisco CallManager.

• Some voice mail systems can send a fake OP:MWI message which is used as an SMDI link "heart-beat" message (for example OP:MWI 5551212). The voice mail system expects a negative acknowledgment (NAK) response from the far end as a means to determine if the SMDI link functions correctly. The parameter KeepAliveDn should contain the agreed upon fake station number for this activity.

• If an MWI is lit for a given phone and the phone is then reset by either cycling power on the device, or by resetting the device within the Cisco CallManager menus, the MWI lights up once again after the phone re-registers with the Cisco CallManager. Also, if the CallManager is stopped and then restarted, MWIs that were on before system reset are turned back on.

• As each parameter within CMI is modified you must perform an Update, otherwise your modifications are not written to the database.

• Cisco CallManager does not currently support configurable Message Desk ID. The hard-coded ID is 001. This can present a problem if Cisco CallManager is integrated to a voice mail system that is already integrated to a switch and that switch uses the ID 001. If this is the case, then the switch has to be re-configured to another ID in order for the dual integration to function correctly.

• Cisco CallManager runs on a standard PC, which means it has 9 pins that are actually wired to the serial port. However, CMI only uses three of the RS-232 lines: TD, RD, and GND.

  There are two outbound control lines, Request To Send (RTS) and data terminal ready (DTR). These are both asserted when the port is opened, but CMI does not care if the lines are ignored or not.

  There are four incoming control lines: data carrier detect (DCD), Clear To Send (CTS), data set ready (DSR) and ring in (RI). All of these lines are ignored. It is considered good practice to connect valid handshaking lines to these lines. But the port is opened with hardware handshaking disabled, so the lines should be ignored.

Troubleshoot

The only real means to troubleshoot SMDI is to connect a PC with Hyper Terminal to the SMDI port and make test calls. Do not forget to use a null-modem adapter. This way you can see exactly what Cisco CallManager sends and can then work with the voice mail technician to resolve any issues.

The voice mail system does not answer a call in the correct manner unless the SMDI packet from Cisco CallManager matches the port configuration of the voice mail that receives the incoming call. For example, Message Desk and Logical Terminal Number must match.

Example of VG200 Configuration Details

Current configuration:
!
mgcp

mgcp call-agent 10.1.1.2

!--- IP address of Cisco CallManager.

mgcp dtmf-relay codec all mode out-of-band
mgcpip-tos precedence 5

!--- Sets IP Precedence of RTP Stream to 5.

mgcp default-package hs-package
!
ccm-manager switchback immediate
ccm-manager redundant-host 10.1.1.253

!--- Backup CallManager if applicable.

ccm-manager mgcp
!
interface FastEthernet0/0
 ip address 10.1.1.3 255.255.255.0
 duplex auto
 speed auto
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.1.1?????????????????????????? 

!--- Default route.

no ip http server
!
voice-port 1/0/0
!
voice-port 1/0/1
!
voice-port 1/1/0
!
voice-port 1/1/1
!
dial-peer
voice 100 pots
 application MGCPAPP
port 1/0/0
!
dial-peer
voice 101 pots
application MGCPAPP
port 1/0/1
!
dial-peer
voice 102 pots
application MGCPAPP
port 1/1/0
!
dial-peer
voice 103 pots
application MGCPAPP
port 1/1/1
!
end

Example of Catalyst 6000 24-Port FXS Gateway Configuration Details

This procedure illustrates an example of a Catalyst 6000 24-port FXS Gateway configuration.

1. Select Cisco Catalyst 6000 24-port FXS Gateway from the Add a New Gateway screen.

   

2. Select Analog Access for the Device Protocol.

   

3. Enter the MAC address of the Gateway. For Device Pool select Default.

   In this screen shot, Port Selection was left as Top Down. The other option available is Bottom Up. Check which option is most suitable for the voice mail system.

   

   Note: The MAC address shown is a fake address. Obtain the MAC address from the Catalyst 6000 Command Line Interface (CLI).

   The gateway is now interted.

4. Select Add a New Port in order to add the FXS Ports.

   

5. A separate window pops-up with this display. Select POTS as the Port Type.

   

6. Select Port - 1. If you select All Ports, you are not able to assign the correct order to the ports. In other words, the selection of All has the effect of always sending an LTN of 1 within the SMDI packet, regardless of which port was actually seized. This results in subsequent integration failure.

   

   The screen now looks like this.

   

   The Gateway now has one FXS port configured.

   

7. Repeat the process. Select Port-2 in order to add a second port.

   

   In this screen shot, there are twelve FXS ports added to the Gateway.

   

8. Make sure the Call Restart Timer in the Port Configuration screen is set to 1234. This enables the FXS ports to provide dial-tone on disconnect, along with a 600 mS drop in loop-current, (as opposed to reorder-tone). Any other value in that parameter results in the port providing reorder-tone on disconnect.

9. Individually select each port and change its Call Restart Timer parameter in order to repeat this configuration change for all ports.

   Note: When finished, reset the Gateway in order to have the changes take effect.

   

SMDI Redundancy

CMI is a service that manages an SMDI interface between Cisco CallManager and any compliant voice mail machine. The SMDI standard defines an RS-232 message passing protocol used with voice mail systems to:

• Send information to the voice mail system related to the end points of an incoming call, as well as any reason for forwarding.

• Receive commands from the voice mail system to set the state of the MWI lamps on the telephones of a subscriber.

Redundancy Issues

Versions of CMI shipping with pre-Bravo CallManager have very few provisions for redundancy. The recommended configuration of CMI is a single copy of CMI that runs on a single server, with a single RS-232 cable that runs to a single voice mail system. The lone node to redundancy is the ability of CMI to connect to a backup Cisco CallManager in the event of failure of the primary Cisco CallManager services.

The standard CMI configuration has numerous failure scenarios, nearly all of which break SMDI connectivity. Essentially, the standard CMI configuration is able to work through the loss of a single Cisco CallManager due to software failure or server crash (provided the server crash doesn't affect the host server for CMI). This leaves CMI with some serious vulnerabilities:

• Crash of the server the CMI runs on.

• Crash/failure of the CMI service.

• Loss of network connectivity between CMI and Cisco CallManager.

This document provides a good solution for these three scenarios at nominal cost. There are still issues left unsolved by this document, some of which are intractable. However, it is believed this solution offers the greatest benefit at an attractively small cost.

NetPro Discussion Forums - Featured Conversations

Related Information

• Voice Technology Support
• Voice and IP Communications Product Support
• Recommended Reading: Troubleshooting Cisco IP Telephony
• Technical Support & Documentation - Cisco Systems