Vous êtes sur la page 1sur 74

Cisco CME for SIPconnect Configuration Guide

Developed by: Cisco Systems, Inc. Cbeyond Network Engineering Date: June, 17 2008 Version 1.2

6/18/2008

Confidential and Proprietary

-i-

Table of Contents
1 Document Overview................................................................................................... 1
1.1 1.2 1.3 1.4 1.5 1.6 Introduction .................................................................................................................................... 1 Scope .............................................................................................................................................. 1 Revision Control............................................................................................................................. 2 Usage .............................................................................................................................................. 2 Questions ........................................................................................................................................ 2 Suggestions / Corrections ............................................................................................................... 2

CME for SIPconnect Overview................................................................................. 3


2.1 2.2 2.3 2.4 2.5 2.6 Product Description ........................................................................................................................ 3 CME/CUE SIPconnect Qualification and Templates ..................................................................... 3 Supported Line-side Protocols........................................................................................................ 4 CME and CUE Security ................................................................................................................. 4 Template LAN Topology for CME/CUE Installation .................................................................... 6 Alternate LAN Configurations ....................................................................................................... 9

Requirements............................................................................................................ 11
3.1 3.2 Hardware Requirements ............................................................................................................... 11 Software Requirements................................................................................................................. 11

CME Configuration ................................................................................................. 11


4.1 4.2 Initial Installation.......................................................................................................................... 11 CME Configuration Example ....................................................................................................... 14

4.3 Direct-Inward-Dial and Extension Number Configuration Details .............................................. 27 4.3.1 DID/Extension Mapping....................................................................................................... 27 4.3.2 Number Registrations to the Broadsoft................................................................................. 28 4.3.3 Mapping CME Extensions to DIDs ...................................................................................... 28 4.3.4 Translations-rules and Ephone-dns for Voicemail and AA Pilots ........................................ 29 4.4 Other CME Configuration Elements ............................................................................................ 31 4.4.1 Voice service configuration .................................................................................................. 31 4.4.2 Sip-ua Configuration ............................................................................................................ 31 4.4.3 Outbound Dial-peer Configuration....................................................................................... 32 4.4.4 Inbound Dial-peer configuration .......................................................................................... 35 4.4.5 Translation-profiles and Rules for Area Codes that do not begin with 9 .......................... 35 4.4.6 Translation-profiles and Rules for Area Codes Beginning with 9 .................................... 37 4.4.7 Telephony service configuration .......................................................................................... 38

5 6

CUE Configuration .................................................................................................. 40


5.1 CUE Configuration Example........................................................................................................ 40

Configuring CME and CUE with the Quick Configuration Tool ....................... 44
6.1 6.2 6.3 Begin by Installing QCT............................................................................................................... 44 Preparing the CME and CUE Platforms for QCT Configuration ................................................. 44 Launching and Using QCT for CME SIPconnect Configuration ................................................. 49

6/18/2008

Confidential and Proprietary

ii

Table of Figures
FIGURE 1, LAN TEMPLATE ............................................................................................................................. 7 FIGURE 2, IOS IN DEFAULT CONDITION ........................................................................................................ 47 FIGURE 3, CUE IN FACTORY DEFAULT CONDITION ...................................................................................... 48 FIGURE 4, QCT LICENSE AGREEMENT .......................................................................................................... 49 FIGURE 5, QCT WELCOME ............................................................................................................................ 50 FIGURE 6, INSTALLATION OPTION ................................................................................................................. 51 FIGURE 7, CUSTOM SETTINGS ....................................................................................................................... 52 FIGURE 8, BASIC SETUP................................................................................................................................. 53 FIGURE 9, BASIC SETUP, CONTINUED ............................................................................................................ 54 FIGURE 10, BASIC SETUP, CONTINUED .......................................................................................................... 55 FIGURE 11, INTERNAL NETWORK .................................................................................................................. 56 FIGURE 12, INTERNET ACCESS CONNECTION SETTING .................................................................................. 58 FIGURE 13, PHONE SYSTEM AND VOICEMAIL ................................................................................................ 59 FIGURE 14, PHONE SYSTEM FEATURES ......................................................................................................... 60 FIGURE 15, SIP TRUNK SERVICE ................................................................................................................... 61 FIGURE 16, SIP TRUNK SERVICE, CONTINUED .............................................................................................. 62 FIGURE 17, PHONES AND USERS .................................................................................................................... 63 FIGURE 18, PHONES AND USERS, CONTINUED ............................................................................................... 64 FIGURE 19, PHONES AND USERS, CONTINUED ............................................................................................... 65 FIGURE 20, PHONES AND USERS, CONTINUED ............................................................................................... 66 FIGURE 21, CONFIRMATION .......................................................................................................................... 67 FIGURE 22, PROGRESS SCREEN ..................................................................................................................... 69 FIGURE 23, SAVE CONFIGURATION ............................................................................................................... 71

6/18/2008

Confidential and Proprietary

iii

Document Overview

1.1 Introduction Cbeyond offers a service based on the SIPconnect Interface Specification, which allows Cbeyond to support customer IP PBXs over SIP trunks. SIPconnect builds on existing Internet Engineering Task Force (IETF) standards to define a model of interconnection between IP PBXs and VoIP service provider networks. SIPconnect was conceived and developed by Cbeyond Engineering. Vendors initially supporting the effort were Cisco Systems, Avaya, Mitel, Broadsoft, and Talkswitch. By August 2006, SIPconnect gained industry-wide support via work completed by the SIP Forum.1 In support of Cbeyonds SIPconnect service, Cisco Systems has worked with Cbeyond engineering to qualify Ciscos Unified CallManager Express (CME) and Cisco Unity Express (CUE) as a supported PBX/voicemail system under SIPconnect. This document details the topology and supporting configurations for Cbeyond VARs and customers who wish to install and operate CME/CUE with Cbeyonds service. 1.2 Scope This document is intended for systems integrators responsible for configuring and deploying CME and CUE for Cbeyonds SIPconnect customers. It is also intended for use by Cbeyond and Cisco personnel for troubleshooting issues associated with the integration of Cisco CME/CUE and Cbeyonds SIPconnect offering. It addresses both Quick Configuration Tool (QCT) and CLI configuration but does not speak to CME and CUE GUI usage. VARs and endusers with a configured system should be able to identify the GUI elements that would result in the corresponding CLI.

See http://www.sipforum.org/sipconnect

6/18/2008

Confidential and Proprietary

-1-

1.3

Revision Control This document is based upon an earlier document written by Cbeyond engineering that defines CME/CUE templates for use with SIPconnect.
Release 0.1 0.2 0.3 0.9 0.91 1.0 1.1 Release Date 12/2/2005 12/16/2005 1/16/2006 11/21/2006 1/9/2007 1/18/07 4/30/2007 Approval Michael Lunsford Michael Lunsford Michael Lunsford Jeff Pilgrim Vinay Pande Jeff Pilgrim Jeff Pilgrim Changes to this Version Initial release of CME/CUE template. Based on CME 3.2 document. Substantive changes for different models. Added tokenized template Initial draft of configuration guide Reviewed with feedback Incorporated feedback from Vinay Incorporated feedback from Greg Rothman and code versions

1.4

Usage This document details both Quick Configuration Tool (QCT) and CLI configuration of CME/CUE, which emphasis on explaining how CME/CUE works with SIPconnect regardless of the how the configuration is created. It is strongly suggested that CME and CUE be configured with the QCT initially. Managing an installation after the initial QCT configuration, however, requires some understanding of the individual configuration elements as shown in the device CLI and GUI. Questions For any sales related questions about Cbeyonds BeyondVoice with SIPconnect service, please contact a Cbeyond sales representative or send email to sales.engineers@cbeyond.net For technical support, please send an email to technical.support@cbeyond.net or call 1-866-424-5100. Suggestions / Corrections Please send any suggestions or error reports related to this document to jpilgrim@cisco.com and vipande@cisco.com

1.5

1.6

6/18/2008

Confidential and Proprietary

2
2.1

CME for SIPconnect Overview


Product Description Cisco Unified CallManager Express is a solution embedded in Cisco IOS Software that provides call processing for Cisco Unified IP phones. This solution enables the large portfolio of Cisco Integrated Services Routers (ISRs) to deliver a comprehensive set of features commonly used by business customers, facilitating the deployment of a cost-effective and highly reliable unified communications solution for the small office. Cisco Unified CallManager Express provides the following benefits: Cost-effective, converged data and voice solution inside Cisco Integrated Services Routers Key system/small PBX features plus innovative convergence applications for up to 240 users Intuitive graphical user interface for easy installation, adds, moves, and changes; internetworking with Cisco Unified CallManager Unmatched investment protection for future growth

Cisco Unity Express offers voice-mail and automated attendant capabilities for IP phone users connected to CallManager Express. The voice mail and automated attendant capabilities are fully integrated into the Cisco router using a Network Module (NM) or Advanced Integration Module (AIM). With this solution, the Cisco portfolio of access routers delivers features similar to those of a key system or hybrid private branch exchange (PBX) plus the rich data and routing capabilities expected on the new Cisco ISRs designed specifically for voice services, or on Cisco multi-service access routers which many organizations already have deployed in their networks. 2.2 CME/CUE SIPconnect Qualification and Templates Cbeyond and Cisco engineers worked together to qualify CME/CUE for SIPconnect. This included the design of a template topology, the creation of configuration templates for CME/CUE and the supporting SIPconnect service components, and addressing any software issues with respect to CMEs and CUEs support for a Cbeyonds network. The intent of the qualification process was to ensure both that CME/CUE would function correctly in a SIPconnect environment and that Cbeyond can support the platform if any issues arise after a customer installation. Cbeyonds demarcation point with a network customer is at the managed Cisco IAD that Cbeyond deploys, which provides network access services for IP voice and data traffic. Any equipment on the customer premise, including PBXs supported by the SIPconnect service, are the responsibility of Cbeyonds customer and a supporting VAR. With that in mind, it should be understood that

6/18/2008

Confidential and Proprietary

the main focus in developing CME/CUE configuration templates was to validate a configuration that works 100% and enables communication between the CPEbased equipment and Cbeyonds SIPconnect Broadsoft call agent. Basic voice features including on-net and off-net calling, call transfers and forwarding, voicemail access, and any other network-based voice services upon which a PBX/voicemail system depends, fall into the testing and qualification effort by Cbeyond and Cisco. More customer-specific features such as hunt-group definitions, paging groups, and the like, have been tested by Cisco but are left to VARs and customers to configure. The templates that resulted from the testing efforts, particularly with respect to LAN topology, are tested recommendations that are subject to VAR and endcustomer requirements. The only exceptions to this are required CME/CUE SIP connection parameters that must be configured for communication with Cbeyonds Broadsoft platforms. 2.3 Supported Line-side Protocols Although CME can also support SIP on the line side to SIP phones, this document does not address such configurations. Future versions of CME templates, based on the CME 4.x train, will be developed and documented in revisions to this guide. At present, CME acts as a protocol converter and SIP user-agent between the SIP trunk to Cbeyonds Broadsoft call agent and Cisco IP phones running SCCP (Skinny) images. In keeping with the SIPconnect specification, a single directory number, the designated main number, is configured on CME to register with the Broadsoft BroadWorks servers for authentication and AOR functionality. All other directory numbers are configured such that CME does not register them with BroadWorks. 2.4 CME and CUE Security - Please review June 08 Security Notice below Securing IP Telephony installations such as CME and CUE is a topic that is beyond the scope of this document and has not been directly addressed in the development of SIPconnect CME installation templates. Security is an area in which Cbeyonds VARs may provide additional value to SIPconnect customers, if executed properly. Ciscos IOS firewall, for example, can be configured coresident with CME and CUE and if the appropriate IOS image is present when a configuration is performed with QCT, the appropriate access-lists and other elements of the firewall will be enabled. IOS cryptographic images may also be configured to enable SSH and HTTPS (SSL) access to the CME CLI and GUI management interfaces. Administrative access to the CME/CUE management interfaces may also be configured through the use of local usernames and password, privilege levels, and the use of AAA servers such as Ciscos Access Control Server (ACS) which provides Radius and TACACS+ services. These configuration efforts must be performed by the VAR

6/18/2008

Confidential and Proprietary

or end-customer manually, after the installation of CME/CUE with QCT is complete. QCT also configures Class of Restriction (COR) to enable access control for different classes of users. International number dialing, for example, may be restricted to specific phones. Care should be taken by the VAR or customer to avoid disabling CME, CUE, and phone features when enabling security features manually. As an example, many security administrators will limit access to the HTTP server in CME through the use of access control lists (ACLs). If those ACLs, however, inadvertently prevent IP phones from reaching the HTTP server for CME then features such as user directories and IP phone services will be disabled.

June 2008 Security Notice for Preventing Toll Fraud


If a security configuration is not already in place to prevent outside callers from using a CME for fraudulent calls, then steps are required to prevent this. Not securing the SIP trunk on the CME will allow anonymous SIP connections. The result of this is that it can be used by outside parties to send unauthorized calls. To prevent this requires adding a command to the SIP Incoming Trunk configuration on the incoming SIP trunk Dial Peer , which is numbered 100 in the configuration example later in this document. This configuration addition is listed below. Alternatively protecting the SIP trunk by allowing only port 5060 traffic to and from Cbeyonds SIP Servers with an ACL or Firewall configuration would prevent the dial peer from being used for anonymous connections. Method: Add permission term to the incoming SIP trunk dial peer Telnet to the UC500 and enter configure mode. Look for the dial-peer labeled ** Incoming call from SIP Trunk ** this should be dial-peer 100. Another item to look for is that this trunk would be one with incoming called-number .% configured on it. cme# config terminal cme(config)# dial-peer voice 100 voip cme#(config-dial-peer)# permission term cme#(config-dial-peer)# end cme# write memory Upon completion the dial-peer should look like the example below. cme#show run | section dial-peer voice 100 voip dial-peer voice 100 voip permission term description ** Incoming call from SIP trunk **

6/18/2008

Confidential and Proprietary

voice-class codec 1 voice-class sip dtmf-relay force rtp-nte session protocol sipv2 session target sip-server incoming called-number .% dtmf-relay rtp-nte ip qos dscp cs5 media ip qos dscp cs4 signaling no vad 2.5 Template LAN Topology for CME/CUE Installation There are several ways in which a CME/CUE system can be integrated into a customers local area network in the context of SIPconnect. The key factor to consider in the implementation, however, is that the managed Cisco IADs which Cbeyond customers enjoy as managed access routers are generally not modified according to various CPE scenarios. The IAD provides a SIP ALG and NAT router for local private network addressing, but does not participate in local routing decisions for subnets and VLANs defined by the end-customer or VAR. This enables Cbeyond to provide reliable, consistent, and supportable IAD configurations across a wide customer base. With this consideration in mind, Figure 1 depicts the LAN topology that was used to develop to CME/CUE templates with SIPconnect.

6/18/2008

Confidential and Proprietary

Figure 1, LAN Template

Cbeyonds Network

Cbeyond Managed IAD


FA0/0 10.0.1.1 10.0.1.0/24 VLAN 1

Switch w/ 802.1q Inline Power

FA0/0 1.254 10.0.1.0/24 VLAN 1 Trunk: Int fa0/1.1 100 10.1.10.1/24 Int fa0/1.2 192.168.10.1/24

VLAN 200 192.168.10.0/24

CME/CUE
VVLAN 100 10.1.10.0/24

IP Phones

VLAN 200 192.168.10.0/24

PCs

In this topology, CUE/CME is essentially placed inline between the managed IAD and any CPE devices including IP phones and personal computers. CME/CUE becomes the default gateway and DHCP server for the phones and PCs. Requirements for this configuration include: A layer 2 Ethernet switch that supports 802.1q VLANs, such as a Cisco Catalyst 3560 Voice VLAN support on the Ethernet switch A CME platform with two FastEthernet interfaces A CME platform with a Cisco Unity Express module

6/18/2008

Confidential and Proprietary

This template for a LAN topology also supports running the IOS firewall feature set on the CME platform, although a firewall configuration is not presented in this document. Considerations for this topology include: The VLAN 1 segment between the Cbeyond IAD and the CME can also support other data devices, such as personal computers, just as if CME/CUE were not present. This is the default LAN supported by Cbeyond IADs, is DHCP enabled by default, and by default falls into the 10.0.1.0/24 subnet. Both DHCP support and the subnet can be modified by the VAR or end-customer so long as the subnet changes are addressed in the CME outside interface and NAT configuration. CUE is not required for CME with SIPconnect. Cbeyond offers networkbased voicemail that has been tested and deployed in conjunction with CME. VLAN 200, Voice VLAN 100, and the subnets depicted can be modified by the VAR or end-customer to suite customer requirements. PCs may or may not be attached through Cisco IP phones according to customer preference. Inline power support in the Ethernet switch is recommended but not required. The CME/CUE provides routing for all devices in VLANs 100 and 200, and also NATs the template 192.168.10.0/24 address space for the data VLAN 200. The result is that data traffic from VLAN 200 is NATed twice: Once by the CME router and once by the Cbeyond IAD. Without this NATing on the CME router, the managed IAD has no destination for inbound traffic. Testing by Cbeyond and Cisco has not revealed any particular difficulty with this practice. Some customers may prefer to obtain a publicly routable address for CME rather than use a private 10.x address behind the Cbeyond IAD. Cbeyond provides this as an option for an additional cost and also configures the IAD to route inside for a block of public IP addresses. This has the benefit of avoiding double-NATing and can simplify remote access to the CME, whether or not VPN access is configured on the CME platform. If remote access to the CME is desired Cisco recommends the use of a cryptographic IOS image that support SSH connections rather than the use of telnet.

6/18/2008

Confidential and Proprietary

2.6

Alternate LAN Configurations A viable alternative to the topology show in Figure 1 is shown below in Figure 2. The only real difference here is that the CME platform router contains an Etherswitch module and no local Ethernet switch is required, assuming that enough switched ports are available to support the customers needs. Considerations for this alternative configuration, aside from those noted above that still apply, include: The number of available switch ports is limited to what is available in an Etherswitch module. Inline power is an optional, but recommended, option for an Etherswitch module. The CME and IAD may be connected with an Ethernet cross-over cable or through a LAN switch. Configuration with an Etherswitch module is simpler than with an external switch and requires less data closet space.

6/18/2008

Confidential and Proprietary

Cbeyonds Network

Cbeyond Managed IAD


FA0/0 10.0.1.1 Crossover Cable FA0/0 10.0.1.2

CME/CUE with Etherswitch Module


Interface VLAN 100 10.1.10.1 Interface VLAN 200 192.168.10.1

FA0/1/1 10.0.1.2

FA0/1/2 10.0.1.2

VVLAN 100 10.1.10.0/24

IP Phones

VLAN 200 192.168.10.0/24

PCs

6/18/2008

Confidential and Proprietary

10

3
3.1

Requirements
Hardware Requirements Any Cisco access router that supports CME at the appropriate sizing level may be employed as a CME platform. The addition of CUE requires a 2800 or 3800 Integrated Services Router (ISR) as a platform, which is also the recommended CME platform for small and medium businesses. Please refer to http://www.cisco.com/en/US/products/sw/voicesw/index.html for additional information about CME and CUE hardware requirements. Both the CUE Advanced Integration Modules (AIM-CUE) and Network Modules (NM-CUE) are supported with SIPconnect CME, bearing in mind the difference in CUE features that are provided by the two types of modules.

3.2

Software Requirements Cbeyond and Cisco have qualified the following software versions for SIPconnect and CME/CUE. No other versions of IOS and CME are currently supported:
Component IOS Release CME Release CUE Release QCT Release Supported 12.4(11)XJ 4.1 2.3.4 3.0.2

CME Configuration
Cbeyond and Cisco engineering have developed configurations for CME and CUE that are shown in sections 4.1 and 5.1 of this document, respectively. These are the basis for the templates that are incorporated into QCT. There are several possible ways to accomplish certain configuration requirements within CME/CUE but note that straying outside the tested configurations shown in this document may result in unintended consequences due to the detailed nature of the SIPconnect configuration, in which some elements are dependent upon others. It is strongly suggested that VARs and end-customers consult with their Cisco representatives when making significant changes to these configurations. Mandatory configuration elements will be noted and should not be changed without guidance or at least some level of experience in working with CME/SIPconnect installations.

4.1

Initial Installation The initial installation of CME and CUE software on an appropriate platform is a fairly straightforward operation for anyone familiar with how IOS file systems are managed. There are a few ways to get software onto the flash: file system for IOS

6/18/2008

Confidential and Proprietary

11

and CME, and the procedures for upgrading CUE, if required, are well documented. The traditional method for installing IOS and other files utilizes a TFTP server as follows. This procedure assumes that there is nothing of value in the flash: disk of the router and that it may be safely erased. If that is not the case then skip step 4, below: 1. Connect and power up the router with the existing IOS version, providing only the minimal information required to make the device IP addressable. 2. Download the required IOS image from Cisco.com at http://www.cisco.com/cgi-bin/Software/Iosplanner/Plannertool/iosplanner.cgi?majorRel=12.4 and place this in the root of a TFTP server. It is strongly recommended that this server be located on the LAN to which the CME router is attached. 3. Ensure that the CME router has an IP address assigned to the interface to the TFTP server. 4. Remove all files from the flash: of the router with the command delete flash:* and then confirm the removal of all files. This will provide a blank slate with which to continue. 5. Copy the new IOS image to flash with the copy tftp flash: command, following the prompts. 6. Download CME 4.1 from Cisco.com at http://www.cisco.com/cgibin/tablebuild.pl/ip-key. Using Individual Cisco CallManager Express files in .tar format from http://www.cisco.com/cgi-bin/tablebuild.pl/ipiostsp is strongly recommended. Specifically, for use with 12.4(11)XJ, download: a. cme-gui-124-11XJ.tar b. CME41-DST-phoneload822SR1.zip 7. Additionally, download the full CME 4.1 distribution as a .zip file from http://www.cisco.com/cgi-bin/tablebuild.pl/ip-key. This contains optional files, many in .tar format, that are not available as individual downloads. Extract this .zip to a convenient folder on a TFTP server. Extract CME41DST-phoneload822SR1.zip to this location. Copy the cme-gui-12411XJ.tar to this same TFTP server folder. 8. Extract the cme-gui, relavent phone image files, and any optional files such as ringtone.tar to the flash of the router with the command archive tar /xtract tftp://[tftp server address]/[filename.tar] flash:. This places the required files on the flash of the CME router without the overhead of the .tar files themselves. Copy any additional uncompressed files to the routers flash as required. 9. If QCT will be used to configure CME and CUE, configure the minimum required to access the CUE module by pasting in the following configuration:

6/18/2008

Confidential and Proprietary

12

interface Loopback0 description ** tied to CUE module ** ip address 10.1.10.2 255.255.255.0 ! interface Service-Engine[Interface number, e.g. 1/0] description ** CUE module for Voice-Mail ** ip unnumbered Loopback0 service-module ip address 10.1.10.1 255.255.255.0 service-module ip default-gateway 10.1.10.2 no shutdown ip route 10.1.10.1 255.255.255.255 Service-Engine[Interface number, e.g. 1/0]

Wait for the service-engine to come up then execute: Service-engine service-module[Interface number, e.g. 1/0] session Verify that CUE is in the factory default state, waiting to execute setup. 10. Exit back to CME by pressing Ctrl-Shift-6, X. 11. Erase the CME configuration and reload the router. An alternative to using a TFTP server is to employ a flash card reader on a PC which opens the flash file system to reading and writing. Ensure that the flash card has been formatted by the IOS router, which writes a special hidden file to the beginning of the file system, and then extract all the files mentioned above to the flash card. This has the benefit of being much quicker than using TFTP services. Upgrading CUE and adding custom scripts to CUE requires an appropriate interface and routing configuration in the router platform that is hosting the CUE AIM or NM. The process for upgrading CUE to 2.3.4 is well-documented on Cisco.com at http://www.cisco.com/univercd/cc/td/doc/product/voice/unityexp/rel2_3/cue_inst/ index.htm. The upgrade to CUE 2.3.4 can be performed after CME and CUE are configured so that temporary bootstrap configurations can be avoided. Please note that this document references a CUE script called directxfer.aef that provides a facility in CUE for users to transfer a call directly to a CUE mailbox. This script file may eventually become available on Cisco.com for download but at present it must be obtained by request. Please contact Jeff Pilgrim (jpilgrim@cisco.com) or Vinay Pande (vipande@cisco.com) to obtain this script. With that script available, it should be uploaded to CUE per the documentation located at http://www.cisco.com/univercd/cc/td/doc/product/voice/unityexp/rel2_3/index.ht m.

6/18/2008

Confidential and Proprietary

13

4.2

CME Configuration Example The following annotated configuration is a parameterized example of a CME configuration. Comments have been added to annotate the more critical elements of the configuration. Detailed explanation of the configuration elements follows this section. Note: Generating a configuration with QCT, as described in section 0 is much quicker than attempting to copy, modify, and paste, the following example and is much less subject to manual errors.

Current configuration : 16533 bytes ! ! Last configuration change at 15:22:32 EST Mon Nov 13 2006 by jeffp ! NVRAM config last updated at 15:23:28 EST Mon Nov 13 2006 by jeffp ! version 12.4 ! IOS services are defined globally and will change if IOS FW ! is enabled. The following services were configured during testing. ! service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname <CME hostname> ! ! It is recommended that the IOS be specified statically ! boot-start-marker boot system flash <IOS image name> boot-end-marker ! ! If using a local password then enable secret is strongly ! recommended. ! enable secret 5 <encrypted secret password> ! logging buffered 4096 ! ! no aaa new-model ! resource policy ! ! Setting the timezone and DST is required for config generation ! and CDRs. QCT configures GMT with an offset. ! clock timezone GMT <offset> ! ! New DST start/end times in the US require the following. clock summer-time GMT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00 ! ! Subnet-zero support should be enabled. ! ip subnet-zero

6/18/2008

Confidential and Proprietary

14

! ! ip cef should be enabled ! ip cef ! ! Note that DHCP configuration is optional if the customer has ! existing DHCP service enabled to support the phones. ! Use of data and voice VLANs is strongly recommended and ! pools should be configured for each. This section is not ! parameterized for the sake of readability and represents the ! default QCT configuration. ! ip dhcp excluded-address 10.10.10.1 10.10.10.10 ip dhcp excluded-address 192.168.10.1 192.168.10.10 ! ip dhcp pool phone network 10.10.10.0 255.255.255.0 default-router 10.10.10.1 option 150 ip 10.10.10.1 ! ip dhcp pool data network 192.168.10.0 255.255.255.0 default-router 192.168.10.1 dns-server 205.152.0.20 ! ! Enabling DNS services on CME is mandatory for the SIPconnect ! configuration. The domain name is typically provided by Cbeyond ! and will typically be in the form sipconnect.[market]0.cbeyond.net ! ip domain name <domain name provided by Cbeyond> ip name-server <name server provided by Cbeyond> ! ! Defining DSP farms for conference bridging has not been addressed ! in the SIPconnect testing with CME so far. ! voice-card 0 no dspfarm ! voice-card 1 no dspfarm ! ! The voice service voip configuration is mandatory and should not be ! modified without guidance from Cisco. ! voice service voip allow-connections sip to sip no supplementary-service sip refer ! Fax configuration is really optional. Note that the fax configuration ! has only been tested with the nse force option, which requires a ! Cisco voice gateway in the SP, as with Cbeyond. fax protocol t38 nse force ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw sip registrar server expires max 3600 min 3600 localhost dns:<Broadsoft host FQDN provided by Cbeyond>

6/18/2008

Confidential and Proprietary

15

! ! Cbeyond only supports g711ulaw ! voice class codec 1 codec preference 1 g711ulaw ! ! ! ! ! ! ! The following voice translations rules and profiles are mandatory.2 ! This example assumes a CUE with a voicemail pilot of 600, and ! auto-attendant pilot of 601. This section has not been ! parameterized for the sake of readability and will be expanded ! upon in detail later in this document ! voice translation-rule 1 ! CUE Voicemail Pilot access number rule 1 /6783979188/ /600/ ! CUE Auto-attendant access number rule 2 /6783979303/ /601/ ! voice translation-rule 9 rule 1 /^911$/ /911/ rule 2 /^9\(.*\)/ /\1/ ! ! The following rule 10 is a temporary, but mandatory, configuration ! for an existing limit in Broadsofts SIP trunking services. Cbeyond ! is in the process of updating their solution to remove the need for ! this rule, which translates the caller-id of all outbound calls to ! a number on the CME that is known to the Broadsoft. In this example ! that number is the auto-attendants DID, which is typically the main ! number for a system. This workaround covers a call-flow wherein an ! offnet caller utilizes the CUEs AA to an extension that is ! transferring calls to a PSTN number. Caller-ID is preserved by CME ! which means the Broadsoft application server sees a call originating ! from somewhere other than the CME, through this trunk and fails the ! call. The requirement for this configuration should be removed in ! the first half of calendar year 2007. voice rule ! voice rule rule rule rule rule ! ! voice
2

translation-rule 10 1 /^.*/ /6783979303/ translation-rule 410 1 /^9\(.......\)$/ /678\1/ 2 /600/ /6783979188/ 3 /601/ /6783979303/ 4 /^2\(..\)$/ /67839791\1/ 5 /^9\(.*\)/ /\1/

translation-profile CUE_Incoming

Please note a caveat about these translations rules that is detailed in section 4.3.4 for working in US area codes that begin with 9, such as 949 in the Los Angeles area. The translation-rules change in such area codes.

6/18/2008

Confidential and Proprietary

16

translate called 1 ! voice translation-profile PSTN_CallForwarding translate redirect-target 410 translate redirect-called 410 ! voice translation-profile PSTN_Outgoing translate called 9 translate calling 10 translate redirect-target 410 translate redirect-called 410 ! ! T1 controllers are generally not required with SIPconnect ! controller T1 1/0/0 framing esf linecode b8zs ! controller T1 1/0/1 framing esf linecode b8zs ! ! ! Use of a Loopback interface is recommended for CUE configuration ! The Loopback0 shown here is the default configured by QCT. ! Warning: ! The use of physical interfaces is NOT recommended and will not be ! supported. In particular, intermittent issues were seen when a CME ! subinterface was assigned to CUE Service Engine using "ip unnumbered" ! UDP Socket errors were seen. Cisco strongly recommends using a ! Loopback and assigning it to the CUE Service Engine module. . ! interface Loopback0 description ** tied to CUE module ** ip address 10.1.10.2 255.255.255.0 ! ! The IP addresses and interface configuration are really dependent ! upon customer requirements and the availability of switching in ! the LAN to which CME is connected. This example uses an Etherswitch ! module installed in a 2821 router supporting CME/CUE. ! ! The Fa0/0 interface IP address (in this example) should be in the same ! subnet as the inside interface of the Cbeyond IAD2431. That is ! typically the 10.0.1.0 subnet, the default Cbeyond configuration. ! Please refer to the previous section 2.5 for discussion about ! LAN topologies and IP addressing. ! interface FastEthernet0/0 description ** Interface to Cbeyond ** ip address <available address in 10.0.1.0> ! ! This example employs NAT, which may or may not be desirable and ! depends on the customer configuration. ! ip nat outside

6/18/2008

Confidential and Proprietary

17

duplex auto speed auto ! interface Service-Engine0/0 description ** CUE module for Voice-Mail ** ip unnumbered Loopback0 service-module ip address 10.1.10.1 255.255.255.0 service-module ip default-gateway 10.1.10.2 ! interface FastEthernet0/1 no ip address shutdown duplex auto speed auto ! interface FastEthernet0/1/0 switchport trunk native vlan 200 switchport mode trunk switchport voice vlan 100 spanning-tree portfast ! interface FastEthernet0/1/1 switchport trunk native vlan 200 switchport mode trunk switchport voice vlan 100 spanning-tree portfast ! interface FastEthernet0/1/2 switchport trunk native vlan 200 switchport mode trunk switchport voice vlan 100 spanning-tree portfast ! interface FastEthernet0/1/3 switchport trunk native vlan 200 switchport mode trunk switchport voice vlan 100 spanning-tree portfast ! interface Serial0/0/0 no ip address shutdown no fair-queue clock rate 2000000 ! interface Serial0/0/1 no ip address shutdown clock rate 2000000 ! interface Vlan1 no ip address ! interface Vlan100 description ** Voice VLAN ** ip address 10.10.10.1 255.255.255.0 ip nat inside

6/18/2008

Confidential and Proprietary

18

! interface Vlan200 description ** Data VLAN ** ip address 192.168.10.1 255.255.255.0 ip nat inside ! ip classless ! ! Defining a route to CUEs subnet is mandatory ! ip route 10.1.10.1 255.255.255.255 Service-Engine0/0 ! ! The following HTTP directives are required for the CME GUI ! ip http server ip http authentication local no ip http secure-server ip http path flash: ! ! NAT requirements must be evaluated by the VAR on install ! ip nat inside source list 1 interface FastEthernet0/0 overload ! access-list 1 permit 192.168.10.0 0.0.0.255 access-list 1 permit 10.10.10.0 0.0.0.255 ! ! This is a simple example of how CME makes phone images available ! through TFTP. ! tftp-server flash:P00307020200.sbn tftp-server flash:P00307020200.bin ! control-plane ! ! Class of Service configuration ! dial-peer cor custom name internal name local name domestic name international name 900 name 976 ! ! COR list ! dial-peer cor list call-internal member internal ! dial-peer cor list call-local member local ! dial-peer cor list call-domestic member domestic ! dial-peer cor list call-international member international

6/18/2008

Confidential and Proprietary

19

! dial-peer cor list call-900 member 900 ! dial-peer cor list call-976 member 976 ! ! COR list for user with permission=internal ! dial-peer cor list user-internal member internal ! ! COR list for user with permission=local ! dial-peer cor list user-local member local member internal ! ! COR list for user with permission=domestic ! dial-peer cor list user-domestic member domestic member local member internal ! ! COR list for user with permission=international ! dial-peer cor list user-international member international member domestic member local member internal ! ! COR list for user with permission=internal/900/976 ! dial-peer cor list user900-internal member 900 member 976 member internal ! ! COR list for user with permission=local/900/976 ! dial-peer cor list user900-local member 900 member 976 member local member internal ! ! COR list for user with permission=domestic/900/976 ! dial-peer cor list user900-domestic member 900 member 976 member domestic member local member internal !

6/18/2008

Confidential and Proprietary

20

! COR list for user with permission=international/900/976 ! dial-peer cor list user900-international member 900 member 976 member international member domestic member local member internal ! ! ! Dial-peers are explained in more detail later in this document. ! These examples assume the IP addressing show above. ! Please do not add or delete any voip dial-peers without ! consulting Cisco/VAR ! ! permission term added to dial-peer 100 to help reduce toll ! fraud in unsecured configurations. ! dial-peer voice 100 voip permission term description ** Incoming call from SIP trunk ** translation-profile incoming CUE_Incoming voice-class codec 1 voice-class sip dtmf-relay force rtp-nte session protocol sipv2 session target sip-server incoming called-number .% dtmf-relay rtp-nte ip qos dscp cs5 media ip qos dscp cs4 signaling no vad ! dial-peer voice 101 voip corlist outgoing call-local description ** Outgoinging call to SIP trunk ** translation-profile outgoing PSTN_Outgoing destination-pattern 9[2-9]..[2-9]...... voice-class codec 1 voice-class sip dtmf-relay force rtp-nte session protocol sipv2 session target sip-server dtmf-relay rtp-nte ip qos dscp cs5 media ip qos dscp cs4 signaling no vad ! dial-peer voice 102 voip corlist outgoing call-domestic description ** Outgoinging call to SIP trunk ** translation-profile outgoing PSTN_Outgoing destination-pattern 9[0-1][2-9]..[2-9]...... voice-class codec 1 voice-class sip dtmf-relay force rtp-nte session protocol sipv2 session target sip-server

6/18/2008

Confidential and Proprietary

21

dtmf-relay rtp-nte ip qos dscp cs5 media ip qos dscp cs4 signaling no vad ! dial-peer voice 103 voip corlist outgoing call-local description ** 911 outgoinging call to SIP trunk ** translation-profile outgoing PSTN_Outgoing destination-pattern 911 voice-class codec 1 voice-class sip dtmf-relay force rtp-nte session protocol sipv2 session target sip-server dtmf-relay rtp-nte ip qos dscp cs5 media ip qos dscp cs4 signaling no vad ! dial-peer voice 104 voip corlist outgoing call-local description ** emergency outgoinging call to SIP trunk ** translation-profile outgoing PSTN_Outgoing destination-pattern 9911 voice-class codec 1 voice-class sip dtmf-relay force rtp-nte session protocol sipv2 session target sip-server dtmf-relay rtp-nte ip qos dscp cs5 media ip qos dscp cs4 signaling no vad ! dial-peer voice 105 voip corlist outgoing call-local description ** 911/411 outgoinging call to SIP trunk ** translation-profile outgoing PSTN_Outgoing destination-pattern 9[2-9]11 voice-class codec 1 voice-class sip dtmf-relay force rtp-nte session protocol sipv2 session target sip-server dtmf-relay rtp-nte ip qos dscp cs5 media ip qos dscp cs4 signaling no vad ! dial-peer voice 106 voip corlist outgoing call-international description ** International outgoinging call to SIP trunk ** translation-profile outgoing PSTN_Outgoing destination-pattern 9011T voice-class codec 1 voice-class sip dtmf-relay force rtp-nte session protocol sipv2 session target sip-server dtmf-relay rtp-nte

6/18/2008

Confidential and Proprietary

22

ip qos dscp cs5 media ip qos dscp cs4 signaling no vad ! dial-peer voice 107 voip corlist outgoing call-local description ** star code to SIP trunk ** destination-pattern *.. voice-class codec 1 voice-class sip dtmf-relay force rtp-nte session protocol sipv2 session target sip-server dtmf-relay rtp-nte ip qos dscp cs5 media ip qos dscp cs4 signaling no vad ! dial-peer voice 25 voip description ** cue voicemail pilot number ** translation-profile outgoing PSTN_CallForwarding destination-pattern 600 b2bua session protocol sipv2 session target ipv4:10.1.10.1 dtmf-relay sip-notify codec g711ulaw no vad ! dial-peer voice 26 voip description ** cue auto attendant number ** translation-profile outgoing PSTN_CallForwarding destination-pattern 601 b2bua session protocol sipv2 session target ipv4:10.1.10.1 dtmf-relay sip-notify codec g711ulaw no vad ! dial-peer voice 27 voip description ** cue prompt management ** translation-profile outgoing PSTN_CallForwarding destination-pattern 602 b2bua session protocol sipv2 session target ipv4:10.1.10.1 dtmf-relay sip-notify codec g711ulaw no vad ! ! Dial-peer 28 for the directxfer to voicemail script must ! be added manually since it is not bundled with CME/CUE and is ! not yet supported by QCT. dial-peer voice 28 voip description ** cue direct transfer to voicemail script ** translation-profile outgoing PSTN_CallForwarding

6/18/2008

Confidential and Proprietary

23

destination-pattern 603 b2bua session protocol sipv2 session target ipv4:10.1.10.1 dtmf-relay sip-notify codec g711ulaw no vad ! ! QCT will configure SIP-UA appropriately and this should not ! be changed except with guidance from Cisco ! sip-ua authentication username <main phone number> password <main phone number> no remote-party-id retry invite 2 retry register 10 timers connect 100 registrar dns:<Broadsoft host FQDN provided by Cbeyond> expires 3600 sip-server dns:<Broadsoft host FQDN provided by Cbeyond> host-registrar ! ! Telephony-service parameters are described in detail below ! Note that the ip source-address should also be configured ! as the SIP gateway address in CUE configuration, as shown ! in a later section of this document. ! telephony-service load 7960-7940 P00307020300 max-ephones 36 max-dn 108 ip source-address 10.10.10.1 port 2000 calling-number initiator service phone videoCapability 1 system message Cisco Systems url services http://10.1.10.1/voiceview/common/login.do url authentication http://10.1.10.1/voiceview/authentication/authenticate.do time-zone 12 create cnf-files version-stamp 7960 Aug 14 2006 13:16:59 dialplan-pattern 1 67839791.. extension-length 3 extension-pattern 2.. no-reg voicemail 600 max-conferences 8 gain -6 call-forward pattern .T call-forward system redirecting-expanded moh music-on-hold.au web admin system name cisco secret 5 $1$PBPE$49id50FpYN.cwZwZZUeFj1 dn-webedit time-webedit transfer-system full-consult dss transfer-pattern 9.T ! The following 6 transfer pattern is for the direct transfer to ! voicemail script. This must be added manually since it is not ! yet a standard part of CME/CUE or QCT. transfer-pattern 6

6/18/2008

Confidential and Proprietary

24

secondary-dialtone 9 ! ! The key thing to note with ephone-dn definition is the use ! of primary numbers (extensions) and secondary numbers (DIDs) ! in any case where a mapping between DIDs and extensions is required. ! ! In the following, for example, paging numbers do not require DIDs. ! ! Whether or not DIDs are assigned, all DNs must be configured with ! no-reg, except for the main number. If secondary numbers are ! used then either no-reg primary or no-reg both should be ! specified. ! ephone-dn 1 number 101 no-reg both name IP-Paging1 paging ip 239.1.1.1 port 2000 ! ! ephone-dn 2 number B1 no-reg both intercom B2 label "intercom Aaron Pilgrim" ! ! ephone-dn 3 number B2 no-reg both intercom B1 label "intercom Jeff Pilgrim" ! ! ephone-dn 4 dual-line ! This ephone-dn has been defined as the main number ! and must register with Cbeyonds Broadsoft servers. ! The designation of a primary number is arbitrary but ! should be the same number configured in SIP-UA for ! authentication. number 286 secondary 6783979186 no-reg primary label 286 description Jeff Pilgrim name Jeff Pilgrim call-forward busy 600 call-forward noan 600 timeout 15 corlist incoming user900-international ! ! ephone-dn 5 dual-line number 287 secondary 6783979187 no-reg both label 287 description Aaron Pilgrim name Aaron Pilgrim call-forward busy 600 call-forward noan 600 timeout 15 corlist incoming user900-domestic ! ! Creating an ephone-dn for the voicemail pilot DID is required ! ephone-dn 6 description Voicemail pilot DID

6/18/2008

Confidential and Proprietary

25

number 6783979188 no-reg primary ! ! ! Creating an ephone-dn for the AA pilot DID is required ! This number is often also the main number in which case ! no-reg would be omitted. ! ephone-dn 7 description AA pilot DID number 6783979303 no-reg primary ! ! ephone-dn 8 description CUE MWI number 800... no-reg both mwi on ! ! ephone-dn 9 description CUE MWI number 801... no-reg both mwi off ! ephone-dn 10 number 701 no-reg park-slot ! ephone-dn 11 number 702 no-reg park-slot ! ephone 1 username "jpilgrim" password 123 mac-address 0013.6087.3248 paging-dn 1 type 7960 button 1:4 2:2 ! ! ephone 2 username "apilgrim" password 123 mac-address 0013.6086.255E paging-dn 1 type 7960 button 1:5 2:3 ! ! Note that with no-reg is configured differently for ephone-hunt ! groups than with ephone-dns: ! ephone-hunt 1 sequential pilot 501 secondary 6783979305 list 286, 287 final 600 timeout 8 no-reg both statistics collect !

6/18/2008

Confidential and Proprietary

26

! alias exec cue service-module service-engine 0/0 session ! line con 0 line aux 0 line 194 no activation-character no exec transport preferred none transport input all transport output pad telnet rlogin lapb-ta mop udptn v120 ssh line vty 0 4 password cisco login ! scheduler allocate 20000 1000 ! ! Defining an NTP server is strongly recommended for any ! CME installation. ! ntp clock-period 17180084 ntp server 132.163.4.101 ntp server 129.6.15.28 ! end

4.3
4.3.1

Direct-Inward-Dial and Extension Number Configuration Details


DID/Extension Mapping

One of the primary tasks of CME configuration with respect to addressing the phones is to map Direct-Inward-Dial (DID) numbers allocated by Cbeyond to extensions in CME. Any calls that need to be routed by BroadWorks to a CME extension must have a mechanism in CME whereby full 10-digit DIDs can be translated to local extensions that may be 2, 3, or 4 digits in length. Likewise, outbound calls from CME be they direct, call-forwards, or transfers, must present a number known to the BroadWorks servers or they will be rejected. A primary part of the CME/CUE configuration development was to insure that this DID/extension is complete and covers all call flow. This mapping is simple enough if the DID and extension ranges are contiguous. It is more difficult if ported and discontiguous ranges must be accommodated. In those cases where there are fewer DIDs than configured extensions, the CUE Auto-Attendant (AA) may be employed for outside callers to reach the CME subscribers. Outbound caller-id from extensions for which there are not DIDs must be translated to a DID known to the Cbeyonds Broadsoft server. This translation is accommodated in the default configuration, as shown in the sample in section 4.2, by voice translation-rule 10, which presents the main CME number as the caller-id number to all off-net callers.

6/18/2008

Confidential and Proprietary

27

Mapping DIDs to the AA and CUE voicemail pilot is required if either will be used.
4.3.2 Number Registrations to the Broadsoft

One of the benefits of the SIPconnect model to Cbeyond is a reduction of network traffic and management overhead by having a single device with an assigned DID register to the Broadsoft servers. To this end, SIPconnect specifies that a parent telephone number is to be used to represent all other numbers on a PBX for purposes of defining an Address of Record (AOR). Typically this is a DID defined as a main number for a SIPconnect customer. Configuring CME appropriately in this context requires that all ephone-dns, dialplan-patterns, and hunt group pilots be configured with no-reg or no-reg both to disable the otherwise automatic registration of extensions with the Broadsoft server. Failure to configure this will not break CME, but will result in Cbeyond following up with the end customer, asking for proper configuration. This is a mandatory part of the SIPconnect CME configuration.
4.3.3 Mapping CME Extensions to DIDs

The task of mapping extensions on the CME to DIDs is accomplished with pattern matching and digit replacement. Three elements are involved in this: 1) Using voice-translation rules, 2) Using the dialplan-pattern command under telephony services configuration, and 3) Applying both extensions and DIDs to ephone-dns under telephony services configuration. For example, CME may have extensions configured as 301 through 319 using DIDs 6785554201-6785554219. Though the first digit of the extension does not coincide with the DID, the last two digits are the same in both the extension and the DID. To accomplish the appropriate mapping with this example, the CME is configured with a dialplan-pattern to translate between the extensions and DIDs, and primary and secondary DNs in ephone-dn configuration. Dialplan-patterns under telephony services are a means to translate extensions to DIDs on a range basis for inbound calls. The configuration for two phones related to above example would be:
telephony-services dialplan-pattern 1 67855542.. extension-length 3 extension-pattern 3.. no-reg ! ephone-dn 1 dual number 301 secondary 6785554201 no-reg primary ! ephone-dn 2 dual number 302 secondary 6785554202 no-reg both

This example highlights both the extension mapping and the appropriate use of no-reg, where 678-555-4201 is defined as the main number for this customer.

6/18/2008

Confidential and Proprietary

28

4.3.4

Translations-rules and Ephone-dns for Voicemail and AA Pilots

In addition to configuring the dialplan-patterns and ephone-dns, translation-rules much be added to handle inbound and outbound translations of specific DNs for CUE voicemail and AA pilot numbers. This is required because routing calls to the CUE service module involves targeting the CUEs IP address with dial-peers, which is outside the scope of CMEs telephony services. The configured translation rules must obviously then be applied to dial-peers for the corresponding services. As an example, if the CUE voicemail pilot extension is 6000 and the AA pilot number is 6001 the appropriate translations and dial-peers for translating between DIDs and the extensions, inbound and outbound, might be:
voice translation-rule 1 rule 1 /6785554188/ /6000/ rule 2 /6785554189/ /6001/ ! voice translation-profile CUE_Incoming translate called 1 ! voice translation-rule 410 rule 1 /6000/ /6785554188/ rule 2 /6001/ /6785554189/ ! voice translation-profile PSTN_CallForwarding translate redirect-called 410 translate redirect-target 410 dial-peer voice 25 voip description ** cue voicemail pilot number ** translation-profile outgoing PSTN_CallForwarding destination-pattern 6000 b2bua session protocol sipv2 session target ipv4:10.1.10.1 dtmf-relay sip-notify codec g711ulaw no vad ! dial-peer voice 26 voip description ** cue auto attendant number ** translation-profile outgoing PSTN_CallForwarding destination-pattern 6001 b2bua session protocol sipv2 session target ipv4:10.1.10.1 dtmf-relay sip-notify codec g711ulaw no vad dial-peer voice 27 voip description ** cue prompt management ** translation-profile outgoing PSTN_CallForwarding destination-pattern 6002

6/18/2008

Confidential and Proprietary

29

b2bua session protocol sipv2 session target ipv4:10.1.10.1 dtmf-relay sip-notify codec g711ulaw no vad dial-peer voice 28 voip description ** cue direct transfer to voicemail ** translation-profile outgoing PSTN_CallForwarding destination-pattern 6003 b2bua session protocol sipv2 session target ipv4:10.1.10.1 dtmf-relay sip-notify codec g711ulaw no vad

dial-peer voice 100 voip description ** Incoming call from SIP trunk ** translation-profile incoming CUE_Incoming session protocol sipv2 session target sip-server incoming called-number .% voice-class codec 1 voice-class sip dtmf-relay force rtp-nte dtmf-relay rtp-nte ip qos dscp cs5 media ip qos dscp cs4 signaling no vad

Please note that the example above only addresses the translations for the voicemail and AA pilot numbers. Additional translation rules are described later in this document. Note also in the above examples that dial-peers 27 and 28, for CUE prompt management and direct transfer to voicemail, respectively, do not require translations rules for DID since these applications are typically only used internally. One other requirement, which is slightly unusual, for CME/CUE configs when working with the Voicemail and AA pilots for SIPconnect, is to allow CME to register the DIDs for purpose of authentication and communication with BroadWorks using these numbers. Using the same DIDs applied to 6000 and 6001 in the examples above, respectively, this is a matter of configuring ephonedns:
ephone-dn 6 description ** DID number for CUE Voicemail Pilot ** number 6785554188 no-reg primary ! ephone-dn 7 description ** DID number for CUE AA ** number 6785554189 no-reg primary

6/18/2008

Confidential and Proprietary

30

4.4

Other CME Configuration Elements Other CME configuration elements include global setting for the SIP stacks of CME and CUE, dial-plan elements for routing calls, and specific telephonyservices configuration in CME.
Voice service configuration

4.4.1

The voice service configuration enables global configuration options for voice services. The following configuration is required and should not be changed:
voice service voip allow-connections sip to sip no supplementary-service sip refer sip registrar server expires max 3600 min 3600 localhost dns:<server>

Parameters in the voice service voip configuration include: Localhost dns:<server> where <server> is the FQDN of Cbeyonds BroadWorks server for a given market, for example, sipconnect.den0.cbeyond.net. The localhost directive essentially defines an outbound proxy and overwrites certain SIP headers in specific call flows, including call-forwarding. no supplementary-service sip refer is currently required to disable the use of SIP refer messages by CME, which can create issues with call diversions. This CLI is mandatory. allow-connections sip to sip, which enables CME to process SIP based call flows between devices and trunks. registrar server expires max 3600 min 3600, which enables CME to act as a registrar/proxy server for SIP devices. This allows CME to support SIP phones, a configuration that has NOT been qualified with SIPconnect as yet.
4.4.2 Sip-ua Configuration

The sip-ua configuration elements of CME define the parameters for communication with Cbeyonds SIP Proxy / Registrar server. The configuration elements configured under sip-ua are essential for proper registration and call completion with SIPconnect:
sip-ua authentication username <number> password <password> no remote-party-id retry invite 2 retry register 10 retry options 0 timers connect 100 registrar dns:<server> expires 3600 sip-server dns:<server>

6/18/2008

Confidential and Proprietary

31

host-registrar

Parameters of sip-ua configuration include: authentication, which configures the authentication username and password which will be used for authentication of all SIP messages to Cbeyonds server. The main DID should be configured for both <number> and <password> no remote-party-id, which is required for interoperability with Cbeyonds service. retry invite 2, which configures the CME to send only 2 INVITEs before failing over to the secondary server. This results in a 3.5 seconds delay if the primary server is unavailable (0.5 + 1 + 2 = 3.5 seconds). This is an ample number of retries for interconnecting to Cbeyonds network. registrar, which configures the CME to register ephone-dns which are not explicitly excluded from registration via the no-reg parameter. This will register the customers main number. All other numbers must be explicitly configured to not register. The fully qualified domain name which the customer wishes to use for sip-services must be configured here. There must be corresponding DNS SRV records for the FQDN. Cbeyond will either provide a FQDN to the customer or the customer may request the use of their own FQDN. If the FQDN is hosted by Cbeyond, regardless of whether it is Cbeyonds FQDN or the customers FQDN, Cbeyond will provide for the addition of the DNS SRV records. If the customer has their DNS services hosted elsewhere and wishes to use a FQDN of their own, the customer must coordinate with their DNS hosting provider to add the DNS records. Cbeyond will provide the necessary configuration required for entry.
4.4.3 Outbound Dial-peer Configuration

A dial-peer represents a remote peer to which the CME communicates. The dialpeer configuration specifies the parameters associated with that dial-peer. There will likely be several outbound dial-peers for a particular customers network to handle local dialing requirements such as 7- and 10-digit dialing, a requirement for particular leading digits such as 9 for off-net dialing, etc. A dial-peer is needed for each such destination, which is defined by a destination-pattern in a dial-peer. The configuration detailed in this document is a recommendation for a 10-digit dialing plan common in Cbeyonds markets. QCT is capable of generating the appropriate dial-peers for a 7-digit dial plan and installers should take note of the differences when referencing this reference guide. The specific destination-patterns that are required are customer dependent and may or may not involve dialing access codes for outside access, and no single template-based configuration can handle all the possibilities. The template created by Cbeyond engineering represents the most common scenarios in a 10digit dialing environment with no special class of restrictions (COR) imposed. The dial-peers in the template are simply provided as a baseline and suggestion.

6/18/2008

Confidential and Proprietary

32

A destination-pattern in a dial-peer configuration instructs CME to route a call to the dial-peer if the dialed digits match a digit string, which may be wild-carded. For example, a network designed to require an access code like 9 to reach an outside line for 10-digit dialing would need a dial-peer with a destination-pattern like 9[2-9]. This pattern would immediately stop collecting digits after 9, plus one of the digits 2 through 9, plus any 9 digits which are received, and then route them to this dial peer. Typically, dial-peers are needed for: Vertical service codes that begin with *, such as *69 Local 7- or 10-digit dialing with an outside line access code, such as 9. or 9.. Long-distance dialing that require special access codes such as 9 plus a 1, for example 91. where 9 is required for outside access. International calling with an access code plus a 011 and some undefined digit string. An example might be 9011T. Emergency and service number dialing for numbers such as 911, which also usually requires the ability to dial either 911 or 9911 where the leading 9 might be an access code. Other such numbers include 411 for directory assistance services.

An additional consideration that was taken into account in the Cbeyond template for CME was to avoid the use of un-delimited or variable-length destinationpatterns such as .T. These require the dialing party to either press # to terminate CME digit collection, or to wait the configured inter-digit timeout for CME to stop waiting for additional digits, which defaults to 10 seconds. Whatever patterns are used, the network administrator must ensure that there are no conflicts in the destination-pattern configuration that would result in a call using the wrong dial-peer, particularly if dial-peers go to different destinations. The administrator also needs to ensure that any access-code is stripped with the translate-outgoing called command before it is routed to Cbeyond, as detailed in the next section of this document. Please consult the Cisco IOS Voice Configuration Library at http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124tcg/vcl.htm for additional information on dial-peer configuration. Dial Peer Configuration on Voice Gateway Routers (http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax _c/int_c/dpeer_c/index.htm) in particular is a good reference guide. Installers of CME for SIPconnect are strongly advised to consult with Cisco before changing the template dial-peers created by QCT. An example configuration for a dial-peer for 10-digit local dialing when 9 is used to access an outside line might be:
dial-peer voice 101 voip

6/18/2008

Confidential and Proprietary

33

description ** Outgoing call to SIP trunk ** translation-profile outgoing PSTN_Outgoing destination-pattern 9[2-9]..[2-9]...... voice-class codec 1 voice-class sip dtmf-relay force rtp-nte session protocol sipv2 session target sip-server dtmf-relay rtp-nte ip qos dscp cs5 media ip qos dscp cs4 signaling no vad

Parameters in this example dial-peer include a: translation-profile, which is used in the CME SIPconnect configuration template to remove any access-codes and to ensure that only valid numbers are sent to the Broadsoft call agent for routing. Recommended and required translation-profiles and rules are discussed in the next section of this document. destination-pattern, which used to identify which dialing sequences will be routed to this dial-peer. voice-class codec, which defines the class of codecs to use for the call. The class is defined in the voice class codec global configuration. The class definition lists the acceptable codecs with their preference for use. Cbeyond currently supports only g711ulaw, as show in this class definition:
voice class codec 1 codec preference 1 g711ulaw

session protocol sipv2, which is required for interoperability. session target sip-server, which indicates the SIP proxy where messages matching this dial-peer are sent. Sip-server is and alias or shortcut of the FQDN of Cbeyonds BroadWorks server for a local market. This FQDN will be provided to the customer by Cbeyond and is aliased to sip-server in the sip-ua configuration previously described. dtmf-relay rtp-nte, which enables the use of RFC2833 for transmission of DTMF tones. This is required for interoperability with Cbeyonds network. voice-class sip dtmf-relay force rtp-nte, which causes CME to negotiate RFC2833 as a preferred method of transmitting DTMF tones, even when offered other methods. This is required for interoperability with Cbeyonds network. ip qos dscp cs5 media, which sets the qos class to priority 5 for all media destined to the dial-peer. The setting may be configured as deemed appropriate by the administrator to ensure traffic prioritization on the customers network. As it reaches Cbeyonds IAD, it will be prioritized again to ensure proper handling across the T1 and on Cbeyonds IP network. ip qos dscp cs5 signaling, which sets the qos class to priority 4 for all signaling traffic (SIP). The setting may be configured as deemed appropriate by the administrator to ensure traffic prioritization on the customers network. As it
6/18/2008 Confidential and Proprietary 34

reaches Cbeyonds IAD, it will be prioritized again to ensure proper handling across the T1 and on Cbeyonds IP network. no vad, which disables voice activity detection. VAD detects when there is no voice activity and inhibits the transmission of voice (via RTP) during this idle period. Instead of voice, the CME will instruct the other end to play comfort noise. Sometimes this functionality results in the front-end of speech being clipped and it is not recommended by Cbeyond. It is not, however, prohibited and may be used if acceptable to the customer.
4.4.4 Inbound Dial-peer configuration

An inbound dial-peer must be configured to associate the CME configuration with incoming calls. Incoming calls matching this dial-peer will then use the attributes defined for the call.
dial-peer voice 100 voip description ** Incoming call from SIP trunk ** translation-profile incoming CUE_Incoming voice-class codec 1 voice-class sip dtmf-relay force rtp-nte session protocol sipv2 session target sip-server incoming called-number .% dtmf-relay rtp-nte ip qos dscp cs5 media ip qos dscp cs4 signaling no vad

Parameters in the inbound dial-peer configuration, not already described, include: Incoming called-number, which specifies that any incoming call not already matching an incoming SCCP dial-peer of type pots will match this dial-peer for the incoming dial-peer. translation-profile incoming CUE_Incoming, is required for the tested CME/CUE SIPconnect configuration. This particular translation-profile enables DID mapping to the CUE voicemail and AA pilot extensions.
4.4.5 Translation-profiles and Rules for Area Codes that do not begin with 9

In addition to the translation-profiles and translation-rules described previously for the CUE voicemail and AA pilot numbers, additional rules must be configured to manipulate digits for inbound and outbound calls. The tested translationprofiles and rules include, as an example:
voice ! CUE rule ! CUE rule ! voice rule translation-rule 1 Voicemail Pilot access number 1 /6783979188/ /6000/ Auto-attendant access number 2 /6783979303/ /6001/ translation-rule 9 1 /^911$/ /911/

6/18/2008

Confidential and Proprietary

35

rule 2 /^9\(.*\)/ /\1/ ! voice translation-rule 10 rule 1 /^.*/ /6783979303/ ! voice translation-rule 410 rule 1 /^9\(.......\)$/ /678\1/ rule 2 /6000/ /6783979188/ rule 3 /6001/ /6783979303/ rule 4 /^2\(..\)$/ /67839791\1/ rule 5 /^9\(.*\)/ /\1/ ! ! voice translation-profile CUE_Incoming translate called 1 ! voice translation-profile PSTN_CallForwarding translate redirect-target 410 translate redirect-called 410 ! voice translation-profile PSTN_Outgoing translate called 9 translate calling 10 translate redirect-target 410 translate redirect-called 410

The example above supposes a DID range from Cbeyond of numbers that match the pattern 678-397-9, and extensions defined on the CME in the range 2, except for the voicemail and AA pilots which are 6000 and 6001, respectively. 9 is used to indicate offnet, outbound, calling. Components of this example include: voice translation-rule 1 and the corresponding voice translation-profile CUE_Incoming, which is applied to the inbound dial-peer previously described. The purpose of this translation rule is to allow callers to DIDs 678-397-9188, 678397-9303, and 678-397-9304 to reach extensions 6000, 6001, and 6002 respectively. voice translation-rule 9, which is applied to voice translation-profile PSTN_Outgoing. This translation-profile is applied to outbound dial-peers. Rule 9 accomplishes the task of stripping the leading digit 9 from calls that are sent to BroadWorks after a dial-peer has been selected. It preserves, however, the ability to dial 911 for emergency calls. voice translation-rule 410, which is applied to both voice translation-profile PSTN_Outgoing and voice translation-profile PSTN_CallForwarding. Rule 410 includes a number of digit-manipulation elements to handle instances of callforwarding and call transfers. PSTN_Outgoing is applied to outbound dial-peers. PSTN_CallForwarding is applied to CUE voicemail and AA dial-peers to accommodate transfers and call-forward into voicemail, and transfers from the AA:

6/18/2008

Confidential and Proprietary

36

rule 1 /^9\(.......\)$/ /678\1/ - Is an optional rule that enforces 10-digit dialing when calls are transfers or forwarded offnet with 7 digit numbers, assuming the local area code for the CME which is 678 in this example. rule 2 /6000/ /6783979188/ - Translates from the voicemail pilot 6000 to the DID 6783979188. This is required for CFB, CFNA, CFA, and transfers by internal phones to the voicemail extension, since the CME must signal back to the BroadWorks server with messaging for the remote party. BroadWorks would not recognize 6000 as a valid number with which to route calls. rule 3 /6001/ /6783979303/ - Translates from the AA pilot 6001 to the DID 6783979303. As with the voicemail pilot, this is required to enable the AA to transfer calls to local extensions, since the CME must signal back to the BroadWorks server with messaging for the remote party. BroadWorks would not recognize 6001 as a valid From number and would reject a call. rule 4 /^2\(..\)$/ /67839791\1/ - Translates from local 3-digit extensions of the form 2.. to DIDs of the form 67839791... This rule works because the local extensions are extracted from the DID range, so 234 would correspond to 6783979134, for example. This particular example shows 3-digit extensions beginning with 2 but that is not required for the pattern-matching to occur. Extensions may be 2, 3 or 4 digits in length and may begin with any arbitrary digit so long as there are not conflicts created with other dial plan elements. rule 5 /^9\(.*\)/ /\1/ - Is another instance of stripping 9 from outbound calls that is applied to transfers and call-forwards.

4.4.6

Translation-profiles and Rules for Area Codes Beginning with 9

Some area codes in the US dial-plan begin with the digit 9, such as 949. This creates issues for the configurations show in the previous examples since 9 is being used as the indicator for an outside line for an offnet call. For installations in areas with area codes beginning with 9 where 9 is also used to size an outside line, the following voice translation-rule 410 should be used, assuming 4-digit extensions: voice translation-rule 410 rule 1 /^9\(.......\)$/ /[3-digit area code]\1/ rule 2 /6000/ /[3-digit area code] [3-digit exchange code][VM DID 4-digit extension]/ rule 3 /6001/ /[3-digit area code] [3-digit exchange code][AA DID 4-digit extension]/ rule 4 /^[3-digit area code][3-digit exchange code]\(.*\)/ /[3-digit area code] [3digit exchange code]\1/ rule 5 /^9\(.*\)/ /\1/

6/18/2008

Confidential and Proprietary

37

where [3-digit area code]is an area code beginning with 9 such as 949 in Los Angeles, or 973 in Denver, and [3-digit exchange code] is the second set of three digits in a 10-digit number that refers to the local exchange, and the AA and VM 4-digit extensions are the last 4 digits in the DIDs assigned to the CUE and voicemail and AA pilot DIDs. The purpose of each rule is the same as described previously, modified so that 9 as an offnet dialing prefix does not result in inappropriate translations. For example: voice translation-rule 410 rule 1 /^9\(.......\)$/ /949\1/ rule 2 /6000/ /9492009189/ rule 3 /6001/ /9492009190/ rule 4 /^949200\(.*\)/ /949200\1/ rule 5 /^9\(.*\)/ /\1/
4.4.7 Telephony service configuration

The telephony services element contains configuration elements related to providing telephony services on CME. Much of the configuration will be dependent on the implementation such as the types of phones being used and their appropriate software release, the number of ephones and ephone-dns that are licensed, etc. Some of the elements of the telephony-service configuration a required for SIPconnect call flows, as noted below. Please note the line breaks in this example, which are an artifact of this document:
telephony-service load 7910 P00403020214 load 7960-7940 P00307020200 load 7970 TERM70.7-0-1-0s max-ephones 48 max-dn 100 ip source-address 192.168.0.1 port 2000 calling-number initiator system message Cisco CME url services http://192.168.0.2/voiceview/common/login.do url authentication http://192.168.0.2/voiceview/authentication/authenticate.do time-zone 7 dialplan-pattern 1 6785554... extension-length 4 extensionpattern 4... no-reg keepalive 10 voicemail 6000 max-conferences 8 gain -6 call-forward pattern .T call-forward system redirecting-expanded moh music-on-hold.au web admin system name WebAdmin secret 5 $1$BeGc$ZfRV8Qumg4R/Qyyx2wvVW. web admin customer name CME-User secret 5 $1$9HVW$QnEaFS2UwTbzZx6s7w2dJ/ dn-webedit time-webedit

6/18/2008

Confidential and Proprietary

38

transfer-system full-consult dss transfer-pattern 9.T secondary-dialtone 9 directory last-name-first create cnf-files version-stamp 7960 Nov 10 2006 15:36:34

Parameters in the telephony-service configuration include: load <phone type>, which specifies the software images located on the flash of the CME router that are appropriate for the phones supported by the CME. These entries will vary according to the types of phones deployed and are subject to change as new image versions become available. The specific image files must also be made available through tftp-server directives in the CME configuration. Load directives are mandatory parts of the configuration. max-ephones and max-dn, which limit in software the number of physical phones and configured extensions that may be configured, respectively. max-ephones should not exceed the licensed number of phones purchased or the maximum number of phones supported by the hardware platform for CME. These are flexible but mandatory configuration elements. ip source-address, which will configure the IP address and udp port number on which the CME will provide signaling SCCP packets to the phones. This will be the IP address of the CME on the routers inside interface to the phones, typically FastEthernet 0/0 or GigabitEthernet 0/0, depending on the platform. This is a mandatory configuration element. calling-number initiator, which required for a CME extension to transfer a call to another CME extension which then call-forwards off-net. It places the transferring extension in the SIP From header instead of the original calling party. This is required for Cbeyonds Broadsoft switch to authenticate the call. system message, which displays a character string on the LCD of Cisco IP phones. This is an arbitrary but required configuration element url services and url authentication are parameters which point Cisco IP phones to CUE services, in this example, to enable the services buttons on the phones and display a list of XML services available to users. This is a default configuration that could be changed to point the phones to an alternate server. These are optional configuration elements but are configured by default with QCT. dialplan-pattern, which is used to expand abbreviated extensions into DIDs. Multiple dialplan-patterns may be required if the DID and extension ranges are not contiguous; such a configuration should only be attempted with guidance from Cisco. The no-reg parameter must be used with this command. Dialplanpattern is a mandatory configuration element. keepalive, which defines a poling interval for CME to check on the availability of phones. This is a required element that defaults to 10.

6/18/2008

Confidential and Proprietary

39

voicemail, which defines the CUE voicemail pilot numbers extension for the IP phones messages buttons. This is an optional parameter but is configured with QCT. Failure to include this parameter disables the phones messages button. max-conferences, which limits the number of ad-hoc conferences available on the system. This should be adjusted according to the number of DSP resources available on the platform. This is a mandatory element that defaults to 8. call-forward pattern and call-forward system redirecting-expanded are required elements that enable CFB, CFNA, and CFA operations. The default QCT configuration should not be changed without guidance from Cisco. moh, which enables music on hold for PSTN callers from a file on the CME routers flash system. This is an optional configuration that is enabled by default with QCT. web admin system name and web admin customer name define administrative users for the CME GUI. dn-webedit and time-webedit are security parameters for GUI operations that enable editing configurations with the GUI, and changing the system time, respectively. These are all optional parameters if this GUI will not be employed. transfer-system and transfer-pattern 9.T define whether transfers will be attended or unattended. Transfer-system full-consult is the option verified by Cbeyond and Cisco. The dss option is required to allow the transfer of calls to a station using a monitor key for that line. secondary-dialtone, which enables CME to generate a secondary dialtone when 9 is dialed for offnet calling. directory, which specifies the order in which the CME presents the user directory on IP phones when the directories button is pressed. create cnf-files, which directs CME to generate configuration files for SCCP phones connected to the platform based upon ephone configurations. This is a mandatory command. The timestamps are created automatically by CME and may be used as a reference for determining when phone configurations were last updated in CME.

CUE Configuration
The configuration of CUE for CME with SIPconnect is relatively straightforward to anyone familiar with CUE.

5.1

CUE Configuration Example The following configuration example is matched with the CME template presented earlier in this document, and was created with QCT. A key configuration element in CUE is in ccn subsystem sip, where transfer-mode

6/18/2008

Confidential and Proprietary

40

blind bye-also must be configured. The remainder of the configuration is fairly standard CUE.
clock timezone Etc/GMT+5 hostname cue ip domain-name localdomain ntp server 10.1.10.2 ntp server 132.163.4.101 ntp server 129.6.15.28 software download server url "ftp://127.0.0.1/ftp" credentials hidden "6u/dKTN/hsEuSAEfw40XlF2eFHnZfyUTSd8ZZNgd+Y9J3xlk2B35j0nfGWTYHfmPSd8ZZNg d+Y9J3xlk2B35j0nfGWTYHfmPSd8ZZNgd+Y9J3xlk2B35j0nfGWTYHfmP" groupname Administrators create groupname Broadcasters create groupname IMAPgrp create username username username username username username username username groupname groupname groupname groupname groupname groupname groupname groupname groupname groupname groupname groupname groupname admin create cisco create jpilgrim create apilgrim create jpilgrim phonenumberE164 "6783979186" apilgrim phonenumberE164 "6783979187" jpilgrim phonenumber "286" apilgrim phonenumber "287" Administrators member admin Administrators member cisco IMAPgrp member jpilgrim IMAPgrp member apilgrim Administrators privilege superuser Administrators privilege ManagePrompts Administrators privilege broadcast Administrators privilege local-broadcast Administrators privilege ManagePublicList Administrators privilege ViewPrivateList Administrators privilege vm-imap Broadcasters privilege broadcast IMAPgrp privilege vm-imap

restriction msg-notification min-digits 1 restriction msg-notification max-digits 30 restriction msg-notification dial-string preference 1 pattern * allowed backup server url "ftp://127.0.0.1/ftp" credentials hidden "EWlTygcMhYmjazXhE/VNXHCkplVV4KjescbDaLa4fl4WLSPFvv1rWUnfGWTYHfmPSd8ZZNg d+Y9J3xlk2B35j0nfGWTYHfmPSd8ZZNgd+Y9J3xlk2B35j0nfGWTYHfmP" calendar biz-schedule systemschedule open day 1 from 00:00 to 24:00 open day 2 from 00:00 to 24:00

6/18/2008

Confidential and Proprietary

41

open day 3 from open day 4 from open day 5 from open day 6 from open day 7 from end schedule

00:00 00:00 00:00 00:00 00:00

to to to to to

24:00 24:00 24:00 24:00 24:00

! This is the default AA application. This is generally modified ! customizations after the installation ccn application autoattendant description "autoattendant" enabled maxsessions 6 script "aa.aef" parameter "busOpenPrompt" "AABusinessOpen.wav" parameter "operExtn" "0" parameter "welcomePrompt" "AAWelcome.wav" parameter "disconnectAfterMenu" "false" parameter "busClosedPrompt" "AABusinessClosed.wav" parameter "allowExternalTransfers" "false" parameter "holidayPrompt" "AAHolidayPrompt.wav" parameter "businessSchedule" "systemschedule" parameter "MaxRetry" "3" end application ccn application ciscomwiapplication description "ciscomwiapplication" enabled maxsessions 6 script "setmwi.aef" parameter "CallControlGroupID" "0" parameter "strMWI_OFF_DN" "801" parameter "strMWI_ON_DN" "800" end application ! Note that directxfer is a custom script that must be uploaded ! to CUE after the installation is complete. ccn application directxfer description "directxfer" enabled maxsessions 6 script "directxfer.aef" parameter "numDigitsToCollect" "5" end application ccn application msgnotification description "msgnotification" enabled maxsessions 6 script "msgnotify.aef" parameter "logoutUri" "http://localhost/voicemail/vxmlscripts/mbxLogout.jsp" parameter "DelayBeforeSendDTMF" "1" end application ! Promptmgmt is used to record custom AA prompts ! to CUE after the installation is complete.

6/18/2008

Confidential and Proprietary

42

ccn application promptmgmt description "promptmgmt" enabled maxsessions 1 script "promptmgmt.aef" end application ccn application voicemail description "voicemail" enabled maxsessions 6 script "voicebrowser.aef" parameter "uri" "http://localhost/voicemail/vxmlscripts/login.vxml" parameter "logoutUri" "http://localhost/voicemail/vxmlscripts/mbxLogout.jsp" end application ccn engine end engine ccn subsystem jtapi ccm-manager address 0.0.0.0 end subsystem ccn subsystem sip gateway address "10.10.10.1" dtmf-relay sip-notify transfer-mode blind bye-also end subsystem ccn trigger sip phonenumber 600 application "voicemail" enabled maxsessions 6 end trigger ccn trigger sip phonenumber 601 application "autoattendant" enabled maxsessions 6 end trigger ! Promptmgmt is used to record custom AA prompts ! to CUE after the installation is complete. ccn trigger sip phonenumber 602 application "promptmgmt" enabled maxsessions 1 end trigger ! Note that directxfer is a custom script that must be uploaded ! to CUE after the installation is complete. ccn trigger sip phonenumber 603 application "directxfer" enabled maxsessions 6 end trigger

Source address of telephony-service Do not use any other transfer-mode

6/18/2008

Confidential and Proprietary

43

voicemail callerid voicemail default mailboxsize 2964 voicemail broadcast recording time 300 voicemail mailbox owner "apilgrim" size 2964 end mailbox voicemail mailbox owner "jpilgrim" size 2964 end mailbox end

Ensure when configuring CUE subsystem sip configuration to specify a gateway address that matches the telephony-service source-address configuration in CME. Failure to make them the same will result in IP socket errors.

Configuring CME and CUE with the Quick Configuration Tool


Using the CME Quick Configuration Tool (QCT) is the recommended method for configuring CME and CUE for Cbeyonds SIPconnect service. QCT is available for download from the Cisco Connection Online at http://www.cisco.com/cgibin/tablebuild.pl/cme-qct. General documentation on the installation and use of QCT may be found at http://www.cisco.com/en/US/products/sw/voicesw/ps4625/prod_configuration_gu ide09186a0080759186.html. The following section of this document provides a reference for using QCT specifically with Cbeyonds SIPconnect service. QCT has been enhanced to simplify the configuration of both CME and CUE for SIP installations with template-based procedures for several SIP trunking service providers in addition to Cbeyond.

6.1

Begin by Installing QCT Please reference the installation guides referenced above for instructions on how to install and launch QCT. Briefly, QCT runs on a Windows platform such as a laptop and requires a serial connection to the console port of the router on which CME/CUE are installed. An optional facility in QCT is the ability to upload files such as IP phone images to the routers flash memory. Using this facility requires that QCT have Ethernet and IP connectivity to the router as well. Preparing the CME and CUE Platforms for QCT Configuration CallManager Express, including Cisco IOS, and Unity Express should be installed on the router prior to launching QCT. Guidance for CME and CUE installation may be found at

6.2

6/18/2008

Confidential and Proprietary

44

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_installation_ guide_book09186a00805267ac.html. The IOS for CME may be found at http://www.cisco.com/cgibin/Software/Iosplanner/Planner-tool/iosplanner.cgi?majorRel=12.4. Please consult a Cisco representative to identify the current and recommended IOS version for CME 4.1 on a particular platform. The installation files for CME may be found at http://www.cisco.com/cgibin/tablebuild.pl/ip-key. An additional link on this page, Download Individual Cisco CallManager Express files provides access to more specific bundles of files in a .tar format which is the recommended way to perform the installation. Both CME and CUE must be in their default factory, unconfigured, condition for QCT to work properly. If the router and CUE module have already been configured, perform a write erase in CME and a restore factory default in CUE. The latter requires that CUE be taken offline with the offline command first. The initial installation of CME and CUE software on an appropriate platform is a fairly straightforward operation for anyone familiar with how IOS file systems are managed. There are a few ways to get software onto the flash: file system for IOS and CME, and the procedures for upgrading CUE, if required, are well documented. The traditional method for installing IOS and other files utilizes a TFTP server as follows. This procedure assumes that there is nothing of value in the flash: disk of the router and that it may be safely erased. If that is not the case then skip step 4, below: 1. Connect and power up the router with the existing IOS version, providing only the minimal information required to make the device IP addressable. 2. Download the required IOS image from Cisco.com at http://www.cisco.com/cgi-bin/Software/Iosplanner/Plannertool/iosplanner.cgi?majorRel=12.4 and place this in the root of a TFTP server. It is strongly recommended that this server be located on the LAN to which the CME router is attached. 3. Ensure that the CME router has an IP address assigned to the interface to the TFTP server. 4. Remove all files from the flash: of the router with the command delete flash:* and then confirm the removal of all files. This will provide a blank slate with which to continue. 5. Copy the new IOS image to flash with the copy tftp flash: command, following the prompts. 6. Download CME 4.1 from Cisco.com at http://www.cisco.com/cgibin/tablebuild.pl/ip-key. Using Individual Cisco CallManager Express files in .tar format from http://www.cisco.com/cgi-bin/tablebuild.pl/ipiostsp is strongly recommended. Specifically, for use with 12.4(11)XJ, download:

6/18/2008

Confidential and Proprietary

45

a. cme-gui-124-11XJ.tar b. CME41-DST-phoneload822SR1.zip 7. Additionally, download the full CME 4.1 distribution as a .zip file from http://www.cisco.com/cgi-bin/tablebuild.pl/ip-key. This contains optional files, many in .tar format, that are not available as individual downloads. Extract this .zip to a convenient folder on a TFTP server. Extract CME41DST-phoneload822SR1.zip to this location. Copy the cme-gui-12411XJ.tar to this same TFTP server folder. 8. Extract the cme-gui, relavent phone image files, and any optional files such as ringtone.tar to the flash of the router with the command archive tar /xtract tftp://[tftp server address]/[filename.tar] flash:. This places the required files on the flash of the CME router without the overhead of the .tar files themselves. Copy any additional uncompressed files to the routers flash as required. 9. Since QCT will be used to configure CME and CUE, configure the minimum required to access the CUE module by pasting in the following configuration:
interface Loopback0 description ** tied to CUE module ** ip address 10.1.10.2 255.255.255.0 ! interface Service-Engine[Interface number, e.g. 1/0] description ** CUE module for Voice-Mail ** ip unnumbered Loopback0 service-module ip address 10.1.10.1 255.255.255.0 service-module ip default-gateway 10.1.10.2 no shutdown ip route 10.1.10.1 255.255.255.255 Service-Engine[Interface number, e.g. 1/0]

Wait for the service-engine to come up then execute: Service-engine service-module[Interface number, e.g. 1/0] session Verify that CUE is in the factory default state, waiting to execute setup. 10. Exit back to CME by pressing Ctrl-Shift-6, X. 11. Erase the CME configuration with write erase and reload the router.

6/18/2008

Confidential and Proprietary

46

The IOS console on the router should look like Figure 2, below, prior to launching QCT..
Figure 2, IOS in Default Condition

6/18/2008

Confidential and Proprietary

47

Likewise, CUE should appear like Figure 3, below.

Figure 3, CUE in Factory Default Condition

6/18/2008

Confidential and Proprietary

48

6.3

Launching and Using QCT for CME SIPconnect Configuration The following section of this document walks a QCT operator through configuring CME/CUE for SIPconnect and includes screenshots of an example configuration session. Launch QCT per the installation instructions. Note that QCT requires Internet Explorer and is designed for a PC screen resolution of 1280 x 1024 at a minimum. Lower resolutions will result in a fair amount of scrolling to locate items in the windows. The first time QCT is launched a license agreement will be displayed. Accept the agreement and press the button Launch Quick Config Wizard.

Figure 4, QCT License Agreement

6/18/2008

Confidential and Proprietary

49

The first screen of the configs wizard is an introductory and informational page. Press next at the bottom of the page to continue.

Figure 5, QCT Welcome

6/18/2008

Confidential and Proprietary

50

The next page of the wizard, Installation Option, begins collecting information from the operator on how the installation will be run, i.e. in a typical or custom manner, and asks the operator to confirm that the router is in a default condition. The distinction between typical and custom is whether or not fields will be unlocked in the following screens. Select custom for this installation. The option is also provided to Install Configuration from Template. If QCT has already been run for this router and a template was saved at the end of the process, that template may be loaded at this point to avoid re-entering all the information required for the configuration. Another option on this page is to Upload File to the Router. Assuming that the router and CME were installed as described previously, this option may be ignored. Press the next button at the bottom of the page to continue.

Figure 6, Installation Option

6/18/2008

Confidential and Proprietary

51

The Custom Settings page provides a couple of options for how much debugging information is collected and displayed during the installation of the configuration. Logging is enabled by default and should remain checked. The Enable Debug check box will result in a realtime status window opening during the configuration of the router, which provides useful information if unexpected events occur. Selecting this button is optional. Lockout User Changes on Auto-Detect is also an optional check box. Unchecking this box allows the operator to disable the use of hardware discovered by QCT during and automatic hardware detection phase. For example, an FXS or T1 port may be installed in the router for which the operator has no particular use with SIPconnect. Unchecking this box for the first configuration effort, to enable the ability to change later settings, is suggested. Press next to continue to the next screen.

Figure 7, Custom Settings

6/18/2008

Confidential and Proprietary

52

The Basic Setup screen is where the configs wizard identifies the CME/CUE router hardware automatically, or the operator informs QCT of what is available. It is strongly recommended that QCT be allowed to discover the hardware automatically. Select the appropriate serial port that can be used to communicate with the router and then press the Auto Detect Hardware button.
Figure 8, Basic Setup

Detection is relatively quick although how fast it actually starts is dependent on the state of the router. If the router is still booting when the Auto Detect Hardware button is pressed QCT will timeout and instruct the operator to try again in a few seconds.

6/18/2008

Confidential and Proprietary

53

When it is complete, the config wizard will display what was discovered, as shown in Figure 9, Basic Setup, Continued, below. The QCT operator should verify the discovery and deselect any hardware that should not be considered by QCT in the configuration process, assuming that Lockout User Changes on Auto-Detect was unchecked in the previous Custom Settings window. Discovered items may be deselected from QCT consideration by using the dropdown box to select EMPTY for the given item. Figure 10, Basic Setup, Continued shows the voice module that was discovered on this 2811 has been deselected.

Figure 9, Basic Setup, Continued

6/18/2008

Confidential and Proprietary

54

The operator should take care to enter the correct company name, hostname for CME, and an administrative username/password combination, at the bottom of the screen. The correct time zone should also be selected from the drop down box, as in Figure 10, Basic Setup, Continued, below. Click the next button to continue to the next screen.

Figure 10, Basic Setup, Continued

6/18/2008

Confidential and Proprietary

55

The Internal Network screen allows the QCT operator to define interface IP parameters and the NTP servers for CME. The typical configuration is strongly recommended unless other factors, such as an existing LAN addressing scheme, make it prohibitive. The addresses selected will be automatically configured by QCT for NATing to the outside interface that is defined in the next screen of the wizard. NTP server should also be defined for CME; Cbeyond will provide NTP server addresses as shown in the example in Figure 11, Internal Network, below. Click the next button to continue.

Figure 11, Internal Network

6/18/2008

Confidential and Proprietary

56

The Internet Access Connection Settings page defines the outside interface of the CME, whether or not to enable the IOS Firewall, if available, and DNS server IP addresses. The phrase Internet Access is a bit misleading in the context of CME configuration. This is simply the interface that is located on the same LAN segment as the inside interface of Cbeyonds IAD. Select the yes radio button, the correct outside interface for CME, which is usually FA0/0 or GE0/0, and select how the interface will receive its IP address. With SIPconnect this should generally be a static IP address in the 10.0.1.0/24 address space, with 10.0.1.1 as a default gateway. However, DHCP may be employed. If QCT automatically detected the hardware and IOS version and the correct feature set is available, the IOS Firewall radio buttons will also be enabled for selection. For the sake of simplicity in this example no was selected, as shown in Figure 13, below. Note, however, that if QCT hardware detection was not employed, these radio buttons will still be selectable. Selecting yes when the IOS firewall feature set is not available will result in errors later on in the configuration upload process. If hardware detection was employed and the firewall is not available, the buttons will be grayed out. The remaining fields on this page are for defining the IP addresses of DNS servers. DNS is required with CME/SIPconnect. Cbeyond will provide DNS server addresses to SIPconnect customers for no additional charge. Select next to continue to the next page.

6/18/2008

Confidential and Proprietary

57

Figure 12, Internet Access Connection Setting

6/18/2008

Confidential and Proprietary

58

The Phone System and Voicemail screen sets up the screen that follows it with scoping information about how ephone-dns will be configured in CME, which numbers will be configured for the voicemail and AA pilots, and the fundamental considerations for constructing outbound dial-peers. QCT defaults to configuring 3-digit extensions in CME. The example below shows a configuration for 4 phones with 4-digit extensions that begin with 2 (as in 2001). All the fields were adjusted to make 4-digit numbers for the voicemail and AA pilots. Note that although Enable IMAP Email Integration and Enable VoiceView Express Integration are grayed out in this example. AIM-CUE does not support IMAP or Voice View in 2.3.x although this is road mapped for a future version. Be aware that the AA and Voicemail pilot extension numbers will be matched to DIDs from Cbeyond as well as any phone extensions, per previous notes in this document. When specifying the number of phones to deploy be sure to add 2 to the number of physical phones to accommodate the VM and AA pilot extension. The MWI extensions defined in this screen are not mapped to DIDs. Complete the fields in this screen as appropriate and click next to continue.
Figure 13, Phone System and Voicemail

6/18/2008

Confidential and Proprietary

59

The Phone System Features screen enables additional CME features including intercom configuration, paging groups, group pickups, call park, hunt groups, and how Caller ID blocking is enabled with a Bell Star Code. Select the required features and either accept or change the extension numbers that are assigned by default. Note that in the example below 0s were added to make the extensions consistent with 4-digit phone extensions. Click next to continue to the next screen.

Figure 14, Phone System Features

6/18/2008

Confidential and Proprietary

60

The SIP Trunk Service screen is where the QCT operator select Cbeyond as the chosen SIP trunk provider, which selects the template that QCT will use to configure CME and CUE. This screen also allows the operator to manually enter the SIP trunk parameters required for connectivity to Cbeyonds Broadsoft servers, how phone number extensions are constructed, which is carried over from the Phone System and Voicemail screen, and which DIDs have been allocated by Cbeyond for this installation. The DIDs entered on this screen will be used in a following screen for ephone and ephone-dn definitions. Note that the capability has been developed to import these parameters from a .CSV file that will be made available by Cbeyond. This facility is still under development. Also under development by both Cisco and Cbeyond will be the ability to import these settings from a server provided by Cbeyond, assuming the Cbeyond T1 link is available. As shown in Figure 15, SIP Trunk Service, below, select Cbeyond Communications from the SIP Trunk Service Provider drop down box.

Figure 15, SIP Trunk Service

6/18/2008

Confidential and Proprietary

61

Continue in the SIP trunk service screen by entering the domain name, SIP registrar and proxy, and authentication parameters as illustrated below. With SIPconnect the domain name, registrar, and proxy (i.e., outbound proxy) are currently identical and this host name will be provided by Cbeyond. In the Atlanta market for Cbeyond, for example, this domain, registrar, and proxy name would be sipconnect.atl0.cbeyond.net. The digest authentication username and password are both typically the main number of the CME customer. The IP phone extension field should be pre-populated. Enter the SIP trunk DIDs in the appropriate fields. Although this example does not show it, a good practice is to add the voicemail and AA pilot numbers first, then the numbers that will be associated with phone extensions. That simply provides a contiguous block of DID assignments and makes management a little easier. Click next to continue.
Figure 16, SIP Trunk Service, Continued

6/18/2008

Confidential and Proprietary

62

The Phones and Users screen is where phones and users are added to the CME configuration, by MAC address and user name. This is one of the more complicated screens in QCT although it can be navigated relatively easily with a little practice. A good starting point on this screen is to select the + in the green title bar to expand and show all the possible fields for data entry.

Figure 17, Phones and Users

6/18/2008

Confidential and Proprietary

63

With all the rows in the screen displayed, the parameters for the phones, associated DIDs, extensions, and usernames may be entered. If a number of phones will be configured it may be convenient to use a bar code scanner to get the MAC addresses from labels on the phones or their boxes. For each phone enter the MAC address, select the phone type, enter the username and user ID with a password, then select the additional features as desired using the drop down boxes.
Figure 18, Phones and Users, Continued

6/18/2008

Confidential and Proprietary

64

This is also the screen where the voicemail, AA pilot numbers, and hunt-groups, are defined. To create these definitions, select an unconfigured row, move to the phone type field, and then select the appropriate pilot numbers name in the drop down box, as shown in Figure 19, Phones and Users, Continued, below.

Figure 19, Phones and Users, Continued

6/18/2008

Confidential and Proprietary

65

The completed screen should look something like Figure 20, Phones and Users, Continued, below. Note that it is possible to use a batch file to accomplish the tasks in this screen. Please consult the QCT user documentation for this facility. Click next to continue.

Figure 20, Phones and Users, Continued

6/18/2008

Confidential and Proprietary

66

The Confirmation screen allows the QCT operator to inspect the CLI generated by QCT based on the information provided in the previous screens. The back button allows for corrections to that information in previous screens. Note the check box at the bottom that confirms that the configuration should be written to NVRAM on the router. Click next to continue to the next screen.

Figure 21, Confirmation

6/18/2008

Confidential and Proprietary

67

The Please Check the Following Before You Proceed screen is simply a check that the QCT workstation is connected via a serial connection to the router and it also provides the option to skip the upload of the configuration to the router if the operator would prefer to wait for later. An option is presented in follow on screens that allows the opportunity to same the generated template and CLI to text files. To continue with configuring the CME at this point, check boxes 1) and 2) on the screen and then click Upload at the bottom of the screen. Note that the Upload button will NOT be selectable until both 1) and 2) are checked. If the Ethernet port is not connected the operator may check box 2) anyway without fear of errors so long as there is not desire to upload phone image files in a later screen. Click Upload to continue.

6/18/2008

Confidential and Proprietary

68

After Upload is clicked QCT will display a progress bar, as shown in figure 23.

Figure 22, Progress Screen

Be advised that the upload process may take anywhere from 5 minute to 15 depending on the platforms involved.

6/18/2008

Confidential and Proprietary

69

Once the configuration upload has complete QCT will prompt the operator for whether or not to attempt to load phones image files to the CME. If the files are present on the QCT workstation they can be FTPd to the CME through the Ethernet connection.

6/18/2008

Confidential and Proprietary

70

The final step in the process is to save the template used to create the configurations in QCT, and the created CLI, if desired. Enter a file names in the Local file: fields as appropriate and click Save Template and/or Save CLI, respectively. Saved template files may be used to shortcut the configuration process in the event that QCT configuration needs to be run again for the same, or a similar, CME installation. Note that the files are saved in the QCT root/templates and /configs folders, respectively.
Figure 23, Save Configuration

At this point the QCT configuration is complete and should be verified by visual inspection of the CME and CUE configurations, by placing test phone calls, etc.

6/18/2008

Confidential and Proprietary

71