SIPConnect CME Configuration Guide Version 1.2

7/28/2019 SIPConnect CME Configuration Guide Version 1.2

1/74

6/18/2008 Confidential and Proprietary - i -

Cisco CME for SIPconnect

Configuration Guide

Developed by:

Cisco Systems, Inc.

Cbeyond Network Engineering

Date: June, 17 2008

Version 1.2


2/74

6/18/2008 Confidential and Proprietary ii

Table of Contents

1 Document Overview................................................................................................... 1

1.1 Introduction .................................................................................................................................... 1

1.2 Scope .............................................................................................................................................. 1

1.3 Revision Control............................................................................................................................. 2

1.4 Usage.............................................................................................................................................. 2

1.5 Questions........................................................................................................................................ 2

1.6 Suggestions / Corrections ............................................................................................................... 2

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

2.1 Product Description ........................................................................................................................ 3

2.2 CME/CUE SIPconnect Qualification and Templates ..................................................................... 3

2.3 Supported Line-side Protocols........................................................................................................ 4

2.4 CME and CUE Security ................................................................................................................. 4

2.5 Template LAN Topology for CME/CUE Installation .................................................................... 62.6 Alternate LAN Configurations ....................................................................................................... 9

3 Requirements............................................................................................................ 11

3.1 Hardware Requirements ............................................................................................................... 11

3.2 Software Requirements................................................................................................................. 11

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

4.1 Initial Installation.......................................................................................................................... 11

4.2 CME Configuration Example ....................................................................................................... 14

4.3 Direct-Inward-Dial and Extension Number Configuration Details ........... ........... .......... ........... ... 274.3.1 DID/Extension Mapping....................................................................................................... 274.3.2 Number Registrations to the Broadsoft.............. ........... .......... ........... ........... .......... ........... ... 284.3.3 Mapping CME Extensions to DIDs...................................................................................... 284.3.4 Translations-rules and Ephone-dns for Voicemail and AA Pilots .......... ........... .......... ......... 29

4.4 Other CME Configuration Elements ............................................................................................ 314.4.1 Voice service configuration.................................................................................................. 314.4.2 Sip-ua Configuration ............................................................................................................ 314.4.3 Outbound Dial-peer Configuration....................................................................................... 324.4.4 Inbound Dial-peer configuration .......................................................................................... 354.4.5 Translation-profiles and Rules for Area Codes that do not begin with 9.......... ........... ..... 354.4.6 Translation-profiles and Rules for Area Codes Beginning with 9 .......... .......... ........... ..... 374.4.7 Telephony service configuration .......................................................................................... 38

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

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

6 Configuring CME and CUE with the Quick Configuration Tool ....................... 44

6.1 Begin by Installing QCT............................................................................................................... 44

6.2 Preparing the CME and CUE Platforms for QCT Configuration .......... ........... ........... .......... ....... 44

6.3 Launching and Using QCT for CME SIPconnect Configuration ................................................. 49


3/74

6/18/2008 Confidential and Proprietary iii

Table of FiguresFIGURE 1,LANTEMPLATE ............................................................................................................................. 7FIGURE 2,IOS IN DEFAULT CONDITION ........................................................................................................ 47FIGURE 3,CUE IN FACTORY DEFAULT CONDITION ...................................................................................... 48FIGURE 4,QCTLICENSE AGREEMENT .......................................................................................................... 49FIGURE 5,QCTWELCOME............................................................................................................................ 50

FIGURE 6,INSTALLATION OPTION ................................................................................................................. 51FIGURE 7,CUSTOM SETTINGS ....................................................................................................................... 52FIGURE 8,BASIC SETUP................................................................................................................................. 53FIGURE 9,BASIC SETUP,CONTINUED............................................................................................................ 54FIGURE 10,BASIC SETUP,CONTINUED.......................................................................................................... 55FIGURE 11,INTERNAL NETWORK .................................................................................................................. 56FIGURE 12,INTERNET ACCESS CONNECTION SETTING.................................................................................. 58FIGURE 13,PHONE SYSTEM AND VOICEMAIL................................................................................................ 59FIGURE 14,PHONE SYSTEM FEATURES ......................................................................................................... 60FIGURE 15,SIPTRUNK SERVICE ................................................................................................................... 61FIGURE 16,SIPTRUNK SERVICE,CONTINUED .............................................................................................. 62FIGURE 17,PHONES AND USERS.................................................................................................................... 63FIGURE 18,PHONES AND USERS,CONTINUED............................................................................................... 64

FIGURE 19,PHONES AND USERS,CONTINUED............................................................................................... 65FIGURE 20,PHONES AND USERS,CONTINUED............................................................................................... 66FIGURE 21, CONFIRMATION.......................................................................................................................... 67FIGURE 22,PROGRESS SCREEN ..................................................................................................................... 69FIGURE 23,SAVE CONFIGURATION ............................................................................................................... 71


4/74

6/18/2008 Confidential and Proprietary - 1 -

1 Document Overview1.1 Introduction

Cbeyond offers a service based on the SIPconnect Interface Specification, which

allows Cbeyond to support customer IP PBXs over SIP trunks. SIPconnect buildson existing Internet Engineering Task Force (IETF) standards to define a model ofinterconnection between IP PBXs and VoIP service provider networks.SIPconnect was conceived and developed by Cbeyond Engineering. Vendorsinitially supporting the effort were Cisco Systems, Avaya, Mitel, Broadsoft, andTalkswitch. By August 2006, SIPconnect gained industry-wide support via workcompleted by the SIP Forum.

1

In support of Cbeyonds SIPconnect service, Cisco Systems has worked withCbeyond engineering to qualify Ciscos Unified CallManager Express (CME) andCisco Unity Express (CUE) as a supported PBX/voicemail system underSIPconnect. This document details the topology and supporting configurationsfor Cbeyond VARs and customers who wish to install and operate CME/CUEwith Cbeyonds service.

1.2 ScopeThis document is intended for systems integrators responsible for configuring anddeploying CME and CUE for Cbeyonds SIPconnect customers. It is alsointended for use by Cbeyond and Cisco personnel for troubleshooting issuesassociated with the integration of Cisco CME/CUE and Cbeyonds SIPconnectoffering. It addresses both Quick Configuration Tool (QCT) and CLIconfiguration but does not speak to CME and CUE GUI usage. VARs and end-

users with a configured system should be able to identify the GUI elements thatwould result in the corresponding CLI.

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


5/74

6/18/2008 Confidential and Proprietary 2

1.3 Revision ControlThis document is based upon an earlier document written by Cbeyondengineering that defines CME/CUE templates for use with SIPconnect.

Release Release Date Approval Changes to this Version

0.1 12/2/2005 Michael Lunsford Initial release of CME/CUE template.Based on CME 3.2 document.

0.2 12/16/2005 Michael Lunsford Substantive changes for differentmodels.

0.3 1/16/2006 Michael Lunsford Added tokenized template

0.9 11/21/2006 Jeff Pilgrim Initial draft of configuration guide

0.91 1/9/2007 Vinay Pande Reviewed with feedback

1.0 1/18/07 Jeff Pilgrim Incorporated feedback from Vinay

1.1 4/30/2007 Jeff Pilgrim Incorporated feedback from GregRothman and code versions

1.4 UsageThis document details both Quick Configuration Tool (QCT) and CLIconfiguration of CME/CUE, which emphasis on explaining how CME/CUEworks with SIPconnect regardless of the how the configuration is created. It isstrongly suggested that CME and CUE be configured with the QCT initially.

Managing an installation after the initial QCT configuration, however, requiressome understanding of the individual configuration elements as shown in thedevice CLI and GUI.

1.5 QuestionsFor any sales related questions about Cbeyonds BeyondVoice with SIPconnectservice, please contact a Cbeyond sales representative or send email [email protected] For technical support, please send an email [email protected] or call 1-866-424-5100.

1.6 Suggestions / CorrectionsPlease send any suggestions or error reports related to this document [email protected] [email protected]


6/74


2 CME for SIPconnect Overview2.1 Product Description

Cisco Unified CallManager Express is a solution embedded in Cisco IOS

Software that provides call processing for Cisco Unified IP phones. This solutionenables the large portfolio of Cisco Integrated Services Routers (ISRs) to deliver acomprehensive set of features commonly used by business customers, facilitatingthe deployment of a cost-effective and highly reliable unified communicationssolution for the small office.

Cisco Unified CallManager Express provides the following benefits:

Cost-effective, converged data and voice solution inside Cisco IntegratedServices Routers

Key system/small PBX features plus innovative convergence applicationsfor up to 240 users

Intuitive graphical user interface for easy installation, adds, moves, andchanges; internetworking with Cisco Unified CallManager

Unmatched investment protection for future growth

Cisco Unity Express offers voice-mail and automated attendant capabilities for IPphone users connected to CallManager Express. The voice mail and automatedattendant capabilities are fully integrated into the Cisco router using a NetworkModule (NM) or Advanced Integration Module (AIM). With this solution, theCisco portfolio of access routers delivers features similar to those of a key systemor hybrid private branch exchange (PBX) plus the rich data and routing

capabilities expected on the new Cisco ISRs designed specifically for voiceservices, or on Cisco multi-service access routers which many organizationsalready have deployed in their networks.

2.2 CME/CUE SIPconnect Qualification and TemplatesCbeyond and Cisco engineers worked together to qualify CME/CUE forSIPconnect. This included the design of a template topology, the creation ofconfiguration templates for CME/CUE and the supporting SIPconnect servicecomponents, and addressing any software issues with respect to CMEs andCUEs support for a Cbeyonds network. The intent of the qualification processwas 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 acustomer installation.

Cbeyonds demarcation point with a network customer is at the managed CiscoIAD that Cbeyond deploys, which provides network access services for IP voiceand data traffic. Any equipment on the customer premise, including PBXssupported by the SIPconnect service, are the responsibility of Cbeyondscustomer and a supporting VAR. With that in mind, it should be understood that


7/74


the main focus in developing CME/CUE configuration templates was to validate aconfiguration that works 100% and enables communication between the CPE-based equipment and Cbeyonds SIPconnect Broadsoft call agent. Basic voicefeatures 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 byCbeyond and Cisco. More customer-specific features such as hunt-groupdefinitions, paging groups, and the like, have been tested by Cisco but are left toVARs and customers to configure.

The templates that resulted from the testing efforts, particularly with respect toLAN topology, are tested recommendations that are subject to VAR and end-customer requirements. The only exceptions to this are required CME/CUE SIPconnection parameters that must be configured for communication withCbeyonds Broadsoft platforms.

2.3 Supported Line-side ProtocolsAlthough CME can also support SIP on the line side to SIP phones, this documentdoes not address such configurations. Future versions of CME templates, basedon the CME 4.x train, will be developed and documented in revisions to thisguide.

At present, CME acts as a protocol converter and SIP user-agent between the SIPtrunk to Cbeyonds Broadsoft call agent and Cisco IP phones running SCCP(Skinny) images. In keeping with the SIPconnect specification, a singledirectory number, the designated main number, is configured on CME toregister with the Broadsoft BroadWorks servers for authentication and AORfunctionality. 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 belowSecuring IP Telephony installations such as CME and CUE is a topic that isbeyond the scope of this document and has not been directly addressed in thedevelopment of SIPconnect CME installation templates. Security is an area inwhich Cbeyonds VARs may provide additional value to SIPconnect customers, ifexecuted properly. Ciscos IOS firewall, for example, can be configured co-resident with CME and CUE and if the appropriate IOS image is present when aconfiguration is performed with QCT, the appropriate access-lists and otherelements 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. Administrativeaccess to the CME/CUE management interfaces may also be configured throughthe use of local usernames and password, privilege levels, and the use of AAAservers such as Ciscos Access Control Server (ACS) which provides Radius andTACACS+ services. These configuration efforts must be performed by the VAR


8/74


or end-customer manually, after the installation of CME/CUE with QCT iscomplete.

QCT also configures Class of Restriction (COR) to enable access control fordifferent classes of users. International number dialing, for example, may berestricted to specific phones.

Care should be taken by the VAR or customer to avoid disabling CME, CUE, andphone features when enabling security features manually. As an example, manysecurity administrators will limit access to the HTTP server in CME through theuse of access control lists (ACLs). If those ACLs, however, inadvertently preventIP phones from reaching the HTTP server for CME then features such as userdirectories 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 fromusing 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. Theresult of this is that it can be used by outside parties to send unauthorized calls. Toprevent this requires adding a command to the SIP Incoming Trunk configurationon the incoming SIP trunk Dial Peer , which is numbered 100 in the configurationexample later in this document. This configuration addition is listed below.Alternatively protecting the SIP trunk by allowing only port 5060 traffic to andfrom Cbeyonds SIP Servers with an ACL or Firewall configuration wouldprevent 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 itemto look for is that this trunk would be one with incoming called-number .%configured on it.

cme# config terminalcme(config)# dial-peer voice 100 voipcme#(config-dial-peer)# permission termcme#(config-dial-peer)# endcme# write memory

Upon completion the dial-peer should look like the example below.

cme#show run | section dial-peer voice 100 voipdial-peer voice 100 voippermission termdescription ** Incoming call from SIP trunk **


9/74


voice-class codec 1voice-class sip dtmf-relay force rtp-ntesession protocol sipv2session target sip-serverincoming called-number .%

dtmf-relay rtp-nteip qos dscp cs5 mediaip qos dscp cs4 signalingno vad

2.5 Template LAN Topology for CME/CUE InstallationThere are several ways in which a CME/CUE system can be integrated into acustomers local area network in the context of SIPconnect. The key factor toconsider in the implementation, however, is that the managed Cisco IADs whichCbeyond customers enjoy as managed access routers are generally not modifiedaccording to various CPE scenarios. The IAD provides a SIP ALG and NAT

router for local private network addressing, but does not participate in localrouting decisions for subnets and VLANs defined by the end-customer or VAR.This enables Cbeyond to provide reliable, consistent, and supportable IADconfigurations across a wide customer base.

With this consideration in mind, Figure 1 depicts the LAN topology that was usedto develop to CME/CUE templates with SIPconnect.


10/74


Figure 1, LAN Template

10.0.1.0/24

VLAN 1

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

VVLAN 100 10.1.10.0/24

VLAN 200 192.168.10.0/24

CME/CUE

Switch w/802.1q

Inline Power

IP Phones

PCs

Cbeyond

Managed IAD

Cbeyonds

Network

FA0/0 10.0.1.1

FA0/0 1.254

In this topology, CUE/CME is essentially placed inline between the managedIAD and any CPE devices including IP phones and personal computers.CME/CUE becomes the default gateway and DHCP server for the phones andPCs. Requirements for this configuration include:

A layer 2 Ethernet switch that supports 802.1q VLANs, such as a CiscoCatalyst 3560

Voice VLAN support on the Ethernet switch

A CME platform with two FastEthernet interfaces

A CME platform with a Cisco Unity Express module


11/74


This template for a LAN topology also supports running the IOS firewall featureset on the CME platform, although a firewall configuration is not presented in thisdocument.

Considerations for this topology include:

The VLAN 1 segment between the Cbeyond IAD and the CME can alsosupport other data devices, such as personal computers, just as ifCME/CUE were not present. This is the default LAN supported byCbeyond IADs, is DHCP enabled by default, and by default falls into the10.0.1.0/24 subnet. Both DHCP support and the subnet can be modifiedby the VAR or end-customer so long as the subnet changes are addressedin the CME outside interface and NAT configuration.

CUE is not required for CME with SIPconnect. Cbeyond offers network-based voicemail that has been tested and deployed in conjunction withCME.

VLAN 200, Voice VLAN 100, and the subnets depicted can bemodified by the VAR or end-customer to suite customer requirements.

PCs may or may not be attached through Cisco IP phones according tocustomer preference.

Inline power support in the Ethernet switch is recommended but notrequired.

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 dataVLAN 200. The result is that data traffic from VLAN 200 is NATedtwice: Once by the CME router and once by the Cbeyond IAD. Without

this NATing on the CME router, the managed IAD has no destination forinbound traffic. Testing by Cbeyond and Cisco has not revealed anyparticular difficulty with this practice.

Some customers may prefer to obtain a publicly routable address for CMErather than use a private 10.x address behind the Cbeyond IAD.Cbeyond provides this as an option for an additional cost and alsoconfigures the IAD to route inside for a block of public IP addresses.This has the benefit of avoiding double-NATing and can simplifyremote access to the CME, whether or not VPN access is configured onthe 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 useof telnet.


12/74


2.6 Alternate LAN ConfigurationsA 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 thatenough switched ports are available to support the customers needs.

Considerations for this alternative configuration, aside from those noted abovethat still apply, include:

The number of available switch ports is limited to what is available in anEtherswitch module.

Inline power is an optional, but recommended, option for an Etherswitchmodule.

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 externalswitch and requires less data closet space.


13/74


Crossover

Cable

VLAN 200 192.168.10.0/24

VVLAN 100 10.1.10.0/24

CME/CUE withEtherswitch Module

IP Phones

PCs

Cbeyond

Managed IAD

Cbeyonds

Network

FA0/0 10.0.1.1

Interface VLAN 100 10.1.10.1

Interface VLAN 200 192.168.10.1

FA0/0 10.0.1.2

FA0/1/2 10.0.1.2FA0/1/1 10.0.1.2


14/74


3 Requirements3.1 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 3800Integrated Services Router (ISR) as a platform, which is also the recommendedCME platform for small and medium businesses. Please refer tohttp://www.cisco.com/en/US/products/sw/voicesw/index.html for additionalinformation 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 differencein CUE features that are provided by the two types of modules.

3.2 Software RequirementsCbeyond and Cisco have qualified the following software versions for SIPconnectand CME/CUE. No other versions of IOS and CME are currently supported:

Component Supported

IOS Release 12.4(11)XJ

CME Release 4.1

CUE Release 2.3.4

QCT Release 3.0.2

4

CME ConfigurationCbeyond and Cisco engineering have developed configurations for CME andCUE that are shown in sections 4.1 and 5.1 of this document, respectively. Theseare the basis for the templates that are incorporated into QCT.

There are several possible ways to accomplish certain configuration requirementswithin CME/CUE but note that straying outside the tested configurations shownin this document may result in unintended consequences due to the detailed natureof the SIPconnect configuration, in which some elements are dependent uponothers. It is strongly suggested that VARs and end-customers consult with theirCisco 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 withCME/SIPconnect installations.

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


15/74


and CME, and the procedures for upgrading CUE, if required, are welldocumented. The traditional method for installing IOS and other files utilizes aTFTP server as follows. This procedure assumes that there is nothing of value inthe flash: disk of the router and that it may be safely erased. If that is not the casethen skip step 4, below:

1. Connect and power up the router with the existing IOS version, providingonly the minimal information required to make the device IP addressable.

2. Download the required IOS image from Cisco.com athttp://www.cisco.com/cgi-bin/Software/Iosplanner/Planner-tool/iosplanner.cgi?majorRel=12.4 and place this in the root of a TFTPserver. It is strongly recommended that this server be located on the LANto which the CME router is attached.

3. Ensure that the CME router has an IP address assigned to the interface tothe TFTP server.

4. Remove all files from the flash: of the router with the command deleteflash:* and then confirm the removal of all files. This will provide ablank 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/cgi-bin/tablebuild.pl/ip-key. Using Individual Cisco CallManager Expressfiles in .tar format from http://www.cisco.com/cgi-bin/tablebuild.pl/ip-iostsp is strongly recommended. Specifically, for use with 12.4(11)XJ,download:

a. cme-gui-124-11XJ.tarb. CME41-DST-phoneload822SR1.zip

7. Additionally, download the full CME 4.1 distribution as a .zip file fromhttp://www.cisco.com/cgi-bin/tablebuild.pl/ip-key. This contains optionalfiles, many in .tar format, that are not available as individual downloads.Extract this .zip to a convenient folder on a TFTP server. Extract CME41-DST-phoneload822SR1.zip to this location. Copy the cme-gui-124-11XJ.tar to this same TFTP server folder.

8. Extract the cme-gui, relavent phone image files, and any optional filessuch as ringtone.tar to the flash of the router with the command archive

tar /xtract tftp://[tftp server address]/[filename.tar] flash:. This places therequired files on the flash of the CME router without the overhead of the.tar files themselves. Copy any additional uncompressed files to therouters flash as required.

9. If QCT will be used to configure CME and CUE, configure the minimumrequired to access the CUE module by pasting in the followingconfiguration:


16/74


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 PCwhich opens the flash file system to reading and writing. Ensure that the flashcard has been formatted by the IOS router, which writes a special hidden file tothe beginning of the file system, and then extract all the files mentioned above tothe flash card. This has the benefit of being much quicker than using TFTPservices.

Upgrading CUE and adding custom scripts to CUE requires an appropriateinterface 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 onCisco.com athttp://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 configuredso that temporary bootstrap configurations can be avoided.

Please note that this document references a CUE script called directxfer.aef thatprovides 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 butat present it must be obtained by request. Please contact Jeff Pilgrim

([email protected]) or Vinay Pande ([email protected]) to obtain this script.With that script available, it should be uploaded to CUE per the documentationlocated athttp://www.cisco.com/univercd/cc/td/doc/product/voice/unityexp/rel2_3/index.htm.


17/74


4.2 CME Configuration ExampleThe following annotated configuration is a parameterized example of a CMEconfiguration. Comments have been added to annotate the more critical elementsof the configuration. Detailed explanation of the configuration elements followsthis section.

Note: Generating a configuration with QCT, as described in section 0 is muchquicker than attempting to copy, modify, and paste, the following example and ismuch 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

!

! It is recommended that the IOS be specified statically

!

boot-start-marker

boot system flash

boot-end-marker

!

! If using a local password then enable secret is strongly

! recommended.

!

enable secret 5

!

logging buffered 4096

!

!

no aaa new-model

!

resource policy

!

! Setting the timezone and DST is required for config generation

! and CDRs. QCTconfigures GMT with an offset.!

clock timezone GMT

!

! 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


18/74


!

! 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 datanetwork 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

ip name-server

!

! 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:


19/74


!

! 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

! uponin detail later in this document

!

voice translation-rule 1

! CUE Voicemail Pilot access number

rule 1 /6783979188/ /600/

! CUE Auto-attendant access numberrule 2 /6783979303/ /601/

!


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.


rule 1 /^.*/ /6783979303/

!


rule 1 /^9$.......$$/ /678\1/

rule 2 /600/ /6783979188/

rule 3 /601/ /6783979303/rule 4 /^2$..$$/ /67839791\1/

rule 5 /^9$.*$/ /\1/

!

!

voice translation-profile CUE_Incoming

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


20/74


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



!

! 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

!

! This example employs NAT, which may or may not be desirable and

! depends on the customer configuration.

!

ip nat outside


21/74


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





!






!






!

interface Serial0/0/0

no ip address

shutdown

no fair-queue

clock rate 2000000

!

interface Serial0/0/1

no ip address

shutdownclock 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


22/74


!

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


23/74


!

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-domesticmember domestic

member local

member internal

!

! COR list for user with permission=international

!

dial-peer cor list user-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

!


24/74


! COR list for user with permission=international/900/976

!

dial-peer cor list user900-international

member 900

member 976


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 termadded to dial-peer 100 to help reduce toll

! fraud in unsecured configurations.

!

dial-peer voice 100 voippermission 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




dtmf-relay rtp-nte



no vad

!dial-peer voice 102 voip

corlist outgoing call-domestic

description ** Outgoinging call to SIP trunk **


destination-pattern 9[0-1][2-9]..[2-9]......

voice-class codec 1





25/74


dtmf-relay rtp-nte



no vad

!


corlist outgoing call-localdescription ** 911 outgoinging call to SIP trunk **


destination-pattern 911

voice-class codec 1




dtmf-relay rtp-nte



no vad

!


corlist outgoing call-localdescription ** emergency outgoinging call to SIP trunk **translation-profile outgoing PSTN_Outgoing


voice-class codec 1




dtmf-relay rtp-nte



no vad

!


corlist outgoing call-localdescription ** 911/411 outgoinging call to SIP trunk **


destination-pattern 9[2-9]11

voice-class codec 1




dtmf-relay rtp-nte



no vad

!

dial-peer voice 106 voipcorlist outgoing call-international

description ** International outgoinging call to SIP trunk **


destination-pattern 9011T

voice-class codec 1




dtmf-relay rtp-nte


26/74




no vad

!


corlist outgoing call-localdescription ** star code to SIP trunk **

destination-pattern *..

voice-class codec 1




dtmf-relay rtp-nte



no vad

!


description ** cue voicemail pilot number **

translation-profile outgoing PSTN_CallForwarding

destination-pattern 600b2bua


session target ipv4:10.1.10.1

dtmf-relay sip-notify

codec g711ulaw

no vad

!


description ** cue auto attendant number **



b2bua




codec g711ulaw

no vad

!


description ** cue prompt management **



b2bua




codec g711ulawno 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.


description ** cue direct transfer to voicemail script **



27/74



b2bua




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 password

no remote-party-id

retry invite 2

retry register 10

timers connect 100

registrar dns:expires 3600

sip-server dns: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.auweb 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


28/74


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 bothintercom 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 Pilgrimname 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


29/74


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 bothmwi 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

!


30/74


!

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 17180084ntp server 132.163.4.101

ntp server 129.6.15.28

!

end

4.3 Direct-Inward-Dial and Extension Number Configuration Details4.3.1 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 toextensions in CME. Any calls that need to be routed by BroadWorks to a CMEextension must have a mechanism in CME whereby full 10-digit DIDs can betranslated 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 presenta number known to the BroadWorks servers or they will be rejected. A primarypart of the CME/CUE configuration development was to insure that thisDID/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 CUEAuto-Attendant (AA) may be employed for outside callers to reach the CMEsubscribers. Outbound caller-id from extensions for which there are not DIDsmust be translated to a DID known to the Cbeyonds Broadsoft server. Thistranslation is accommodated in the default configuration, as shown in the samplein section 4.2, by voice translation-rule 10, which presents the main CMEnumber as the caller-id number to all off-net callers.


31/74


Mapping DIDs to the AA and CUE voicemail pilot is required if either will beused.

4.3.2 Number Registrations to the BroadsoftOne of the benefits of the SIPconnect model to Cbeyond is a reduction of

network traffic and management overhead by having a single device with anassigned DID register to the Broadsoft servers. To this end, SIPconnect specifiesthat a parent telephone number is to be used to represent all other numbers on aPBX for purposes of defining an Address of Record (AOR). Typically this is aDID 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-regboth to disable the otherwise automatic registration of extensions with theBroadsoft server. Failure to configure this will not break CME, but will result inCbeyond 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 DIDsThe task of mapping extensions on the CME to DIDs is accomplished withpattern matching and digit replacement. Three elements are involved in this: 1)Using voice-translation rules, 2) Using the dialplan-pattern command undertelephony services configuration, and 3) Applying both extensions and DIDs toephone-dns under telephony services configuration.

For example, CME may have extensions configured as 301 through 319 usingDIDs 6785554201-6785554219. Though the first digit of the extension does notcoincide with the DID, the last two digits are the same in both the extension andthe DID. To accomplish the appropriate mapping with this example, the CME isconfigured 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 toDIDs on a range basis for inbound calls.

The configuration for two phones related to above example would be:

telephony-servicesdialplan-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 ofno-reg, where 678-555-4201 is defined as the main number for this customer.


32/74


4.3.4 Translations-rules and Ephone-dns for Voicemail and AA PilotsIn addition to configuring the dialplan-patterns and ephone-dns, translation-rulesmuch be added to handle inbound and outbound translations of specific DNs forCUE voicemail and AA pilot numbers. This is required because routing calls tothe CUE service module involves targeting the CUEs IP address with dial-peers,

which is outside the scope of CMEs telephony services. The configuredtranslation rules must obviously then be applied to dial-peers for thecorresponding services.

As an example, if the CUE voicemail pilot extension is 6000 and the AA pilotnumber is 6001 the appropriate translations and dial-peers for translating betweenDIDs and the extensions, inbound and outbound, might be:


rule 1 /6785554188/ /6000/

rule 2 /6785554189/ /6001/

!


translate called 1

!


rule 1 /6000/ /6785554188/

rule 2 /6001/ /6785554189/

!





description ** cue voicemail pilot number **


destination-pattern 6000b2bua




codec g711ulaw

no vad

!


description ** cue auto attendant number **



b2bua




codec g711ulaw

no vad


description ** cue prompt management **




33/74


34/74


!

4.4 Other CME Configuration ElementsOther CME configuration elements include global setting for the SIP stacks ofCME and CUE, dial-plan elements for routing calls, and specific telephony-services configuration in CME.

4.4.1 Voice service configurationThe voice service configuration enables global configuration options for voiceservices. 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:

Parameters in the voice service voip configuration include:

Localhost dns: where is the FQDN of Cbeyonds BroadWorksserver for a given market, for example, sipconnect.den0.cbeyond.net. Thelocalhost directive essentially defines an outbound proxy and overwritescertain SIP headers in specific call flows, including call-forwarding.

no supplementary-service sip referis currently required to disable the use of SIPrefer messages by CME, which can create issues with call diversions. This CLI ismandatory.

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 aregistrar/proxy server for SIP devices. This allows CME to support SIP phones, aconfiguration that has NOT been qualified with SIPconnect as yet.

4.4.2 Sip-ua ConfigurationThe sip-ua configuration elements of CME define the parameters forcommunication with Cbeyonds SIP Proxy / Registrar server. The configurationelements configured under sip-ua are essential for proper registration and callcompletion with SIPconnect:

sip-uaauthentication username password

no remote-party-id

retry invite 2

retry register 10

retry options 0

timers connect 100

registrar dns: expires 3600

sip-server dns:


35/74


host-registrar

Parameters of sip-ua configuration include:

authentication, which configures the authentication username and passwordwhich will be used for authentication of all SIP messages to Cbeyonds server.The main DID should be configured for both and

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 failingover to the secondary server. This results in a 3.5 seconds delay if the primaryserver is unavailable (0.5 + 1 + 2 = 3.5 seconds). This is an ample number ofretries 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 willregister the customers main number. All other numbers must be explicitly

configured to not register. The fully qualified domain name which the customerwishes to use for sip-services must be configured here. There must becorresponding DNS SRV records for the FQDN. Cbeyond will either provide aFQDN 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 FQDNor the customers FQDN, Cbeyond will provide for the addition of the DNS SRVrecords. If the customer has their DNS services hosted elsewhere and wishes touse a FQDN of their own, the customer must coordinate with their DNS hostingprovider to add the DNS records. Cbeyond will provide the necessaryconfiguration required for entry.

4.4.3

Outbound Dial-peer ConfigurationA dial-peer represents a remote peer to which the CME communicates. The dial-peer configuration specifies the parameters associated with that dial-peer. Therewill likely be several outbound dial-peers for a particular customers network tohandle local dialing requirements such as 7- and 10-digit dialing, a requirementfor particular leading digits such as 9 for off-net dialing, etc. A dial-peer isneeded for each such destination, which is defined by a destination-pattern in adial-peer.

The configuration detailed in this document is a recommendation for a 10-digitdialing plan common in Cbeyonds markets. QCT is capable of generating theappropriate 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 andmay or may not involve dialing access codes for outside access, and no singletemplate-based configuration can handle all the possibilities. The templatecreated by Cbeyond engineering represents the most common scenarios in a 10-digit dialing environment with no special class of restrictions (COR) imposed.The dial-peers in the template are simply provided as a baseline and suggestion.


36/74


A destination-pattern in a dial-peer configuration instructs CME to route a call tothe 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 anoutside line for 10-digit dialing would need a dial-peer with a destination-patternlike 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, andthen 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 as9. or 9..

Long-distance dialing that require special access codes such as 9 plus a1, 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, whichalso usually requires the ability to dial either 911 or 9911 where theleading 9 might be an access code. Other such numbers include 411 fordirectory assistance services.

An additional consideration that was taken into account in the Cbeyond templatefor CME was to avoid the use of un-delimited or variable-length destination-patterns such as .T. These require the dialing party to either press # toterminate CME digit collection, or to wait the configured inter-digit timeout forCME to stop waiting for additional digits, which defaults to 10 seconds.

Whatever patterns are used, the network administrator must ensure that there areno conflicts in the destination-pattern configuration that would result in a callusing 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 thetranslate-outgoing called command before it is routed to Cbeyond, as detailedin the next section of this document.

Please consult the Cisco IOS Voice Configuration Library athttp://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124tcg/vcl.htmfor additional information on dial-peer configuration. Dial Peer Configurationon 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 Ciscobefore changing the template dial-peers created by QCT.

An example configuration for a dial-peer for 10-digit local dialing when 9 is usedto access an outside line might be:



37/74


description ** Outgoing call to SIP trunk **


destination-pattern 9[2-9]..[2-9]......

voice-class codec 1




dtmf-relay rtp-nte



no vad

Parameters in this example dial-peer include a:

translation-profile, which is used in the CME SIPconnect configuration templateto remove any access-codes and to ensure that only valid numbers are sent to theBroadsoft call agent for routing. Recommended and required translation-profilesand rules are discussed in the next section of this document.

destination-pattern, which used to identify which dialing sequences will be routedto this dial-peer.

voice-class codec, which defines the class of codecs to use for the call. The classis defined in the voice class codec global configuration. The class definition liststhe acceptable codecs with their preference for use. Cbeyond currently supportsonly 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 messagesmatching this dial-peer are sent. Sip-serveris and alias or shortcut of theFQDN of Cbeyonds BroadWorks server for a local market. This FQDN will beprovided to the customer by Cbeyond and is aliased to sip-server in the sip-uaconfiguration previously described.

dtmf-relay rtp-nte, which enables the use of RFC2833 for transmission of DTMFtones. This is required for interoperability with Cbeyonds network.

voice-class sip dtmf-relay force rtp-nte, which causes CME to negotiate RFC2833as a preferred method of transmitting DTMF tones, even when offered othermethods. This is required for interoperability with Cbeyonds network.

ip qos dscp cs5 media, which sets the qos class to priority 5 for all media destinedto the dial-peer. The setting may be configured as deemed appropriate by theadministrator to ensure traffic prioritization on the customers network. As itreaches Cbeyonds IAD, it will be prioritized again to ensure proper handlingacross the T1 and on Cbeyonds IP network.

ip qos dscp cs5 signaling, which sets the qos class to priority 4 for all signalingtraffic (SIP). The setting may be configured as deemed appropriate by theadministrator to ensure traffic prioritization on the customers network. As it


38/74


39/74


rule 2 /^9$.*$/ /\1/

!


rule 1 /^.*/ /6783979303/

!


rule 1 /^9$.......$$/ /678\1/

rule 2 /6000/ /6783979188/

rule 3 /6001/ /6783979303/

rule 4 /^2$..$$/ /67839791\1/

rule 5 /^9$.*$/ /\1/

!

!


translate called 1

!




!

voice translation-profile PSTN_Outgoingtranslate called 9

translate calling 10



The example above supposes a DID range from Cbeyond of numbers that matchthe pattern 678-397-9, and extensions defined on the CME in the range2, 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-profileCUE_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, 678-397-9303, and 678-397-9304 to reach extensions 6000, 6001, and 6002respectively.

voice translation-rule 9, which is applied to voice translation-profilePSTN_Outgoing. This translation-profile is applied to outbound dial-peers. Rule9 accomplishes the task of stripping the leading digit 9 from calls that are sentto BroadWorks after a dial-peer has been selected. It preserves, however, theability to dial 911 for emergency calls.

voice translation-rule 410, which is applied to both voice translation-profilePSTN_Outgoing and voice translation-profile PSTN_CallForwarding. Rule 410includes a number of digit-manipulation elements to handle instances of call-forwarding and call transfers. PSTN_Outgoing is applied to outbound dial-peers.PSTN_CallForwarding is applied to CUE voicemail and AA dial-peers toaccommodate transfers and call-forward into voicemail, and transfers from theAA:


40/74


rule 1 /^9$.......$$/ /678\1/ - Is an optional rule that enforces 10-digitdialing 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 tothe DID 6783979188. This is required for CFB, CFNA, CFA, and

transfers by internal phones to the voicemail extension, since the CMEmust signal back to the BroadWorks server with messaging for the remoteparty. BroadWorks would not recognize 6000 as a valid number withwhich to route calls.

rule 3 /6001/ /6783979303/ - Translates from the AA pilot 6001 to theDID 6783979303. As with the voicemail pilot, this is required to enablethe AA to transfer calls to local extensions, since the CME must signalback to the BroadWorks server with messaging for the remote party.BroadWorks would not recognize 6001 as a valid From number andwould reject a call.

rule 4 /^2$..$$/ /67839791\1/ - Translates from local 3-digit extensions ofthe form 2.. to DIDs of the form 67839791... This rule works becausethe local extensions are extracted from the DID range, so 234 wouldcorrespond to 6783979134, for example. This particular example shows3-digit extensions beginning with 2 but that is not required for thepattern-matching to occur. Extensions may be 2, 3 or 4 digits in lengthand may begin with any arbitrary digit so long as there are not conflictscreated with other dial plan elements.

rule 5 /^9$.*$/ /\1/ - Is another instance of stripping 9 from outboundcalls that is applied to transfers and call-forwards.

4.4.6 Translation-profiles and Rules for Area Codes Beginning with 9Some area codes in the US dial-plan begin with the digit 9, such as 949. Thiscreates issues for the configurations show in the previous examples since 9 isbeing used as the indicator for an outside line for an offnet call. Forinstallations in areas with area codes beginning with 9 where 9 is also used tosize an outside line, the following voice translation-rule 410 should be used,assuming 4-digit extensions:

voice translation-rule 410rule 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-digitextension]/rule 4 /^[3-digit area code][3-digit exchange code]$.*$/ /[3-digit area code] [3-digit exchange code]\1/rule 5 /^9$.*$/ /\1/


41/74


where [3-digit area code]is an area code beginning with 9 such as 949 in LosAngeles, or 973 in Denver, and [3-digit exchange code] is the second set ofthree digits in a 10-digit number that refers to the local exchange, and the AA andVM 4-digit extensions are the last 4 digits in the DIDs assigned to the CUE andvoicemail and AA pilot DIDs.

The purpose of each rule is the same as described previously, modified so that 9as an offnet dialing prefix does not result in inappropriate translations.

For example:

voice translation-rule 410rule 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 configurationThe telephony services element contains configuration elements related toproviding telephony services on CME. Much of the configuration will bedependent on the implementation such as the types of phones being used and theirappropriate software release, the number of ephones and ephone-dns that arelicensed, etc. Some of the elements of the telephony-service configuration arequired for SIPconnect call flows, as noted below. Please note the line breaks inthis 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 extension-

pattern 4... no-reg

keepalive 10

voicemail 6000

max-conferences 8 gain -6call-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


42/74


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 , which specifies the software images located on the flash ofthe CME router that are appropriate for the phones supported by the CME. Theseentries will vary according to the types of phones deployed and are subject tochange as new image versions become available. The specific image files mustalso be made available through tftp-serverdirectives 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 phonesand configured extensions that may be configured, respectively. max-ephonesshould not exceed the licensed number of phones purchased or the maximumnumber of phones supported by the hardware platform for CME. These areflexible but mandatory configuration elements.

ip source-address, which will configure the IP address and udp port number onwhich the CME will provide signaling SCCP packets to the phones. This will bethe 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. Thisis a mandatory configuration element.

calling-number initiator, which required for a CME extension to transfer a call toanother CME extension which then call-forwards off-net. It places the transferringextension in the SIP From header instead of the original calling party. This isrequired 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 phonesto CUE services, in this example, to enable the services buttons on the phonesand display a list of XML services available to users. This is a defaultconfiguration that could be changed to point the phones to an alternate server.These are optional configuration elements but are configured by default withQCT.

dialplan-pattern, which is used to expand abbreviated extensions into DIDs.Multiple dialplan-patterns may be required if the DID and extension ranges arenot contiguous; such a configuration should only be attempted with guidancefrom Cisco. The no-reg parameter must be used with this command. Dialplan-pattern is a mandatory configuration element.

keepalive, which defines a poling interval for CME to check on the availability ofphones. This is a required element that defaults to 10.


43/74


voicemail, which defines the CUE voicemail pilot numbers extension for the IPphones messages buttons. This is an optional parameter but is configured withQCT. Failure to include this parameter disables the phones messages button.

max-conferences, which limits the number of ad-hoc conferences available on thesystem. 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-expandedare requiredelements that enable CFB, CFNA, and CFA operations. The default QCTconfiguration should not be changed without guidance from Cisco.

moh, which enables music on hold for PSTN callers from a file on the CMErouters flash system. This is an optional configuration that is enabled by defaultwith QCT.

web admin system name and web admin customer name define administrativeusers for the CME GUI. dn-webeditand time-webeditare security parameters forGUI operations that enable editing configurations with the GUI, and changing the

system time, respectively. These are all optional parameters if this GUI will notbe employed.

transfer-system and transfer-pattern 9.Tdefine whether transfers will be attendedor unattended. Transfer-system full-consult is the option verified by Cbeyond andCisco. The dss option is required to allow the transfer of calls to a station using amonitor key for that line.

secondary-dialtone, which enables CME to generate a secondary dialtone when9 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 SCCPphones connected to the platform based upon ephone configurations. This is amandatory command. The timestamps are created automatically by CME andmay be used as a reference for determining when phone configurations were lastupdated in CME.

5 CUE ConfigurationThe configuration of CUE for CME with SIPconnect is relatively straightforward

to anyone familiar with CUE.

5.1 CUE Configuration ExampleThe following configuration example is matched with the CME templatepresented earlier in this document, and was created with QCT. A keyconfiguration element in CUE is in ccn subsystem sip, where transfer-mode


44/74


blind bye-also must be configured. The remainder of the configuration is fairlystandard CUE.

clock timezone Etc/GMT+5

hostname cue

ip domain-name localdomain


ntp server 132.163.4.101


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 admin create

username cisco create

username jpilgrim create

username apilgrim create

username jpilgrim phonenumberE164 "6783979186"

username apilgrim phonenumberE164 "6783979187"

username jpilgrim phonenumber "286"

username apilgrim phonenumber "287"

groupname Administrators member admin

groupname Administrators

Documents

SIPConnect CME Configuration Guide Version 1.2