CME Topics

CME-Topic 1: CME Overview

IntroductionCisco CME is a feature embedded into Cisco IOS which provides call processing for Cisco IP Phones. CME provides a cost-effective, highly reliable, IP communications solution for the small office, It provides solution which is easy to deploy, administer and maintain. It enables Cisco High End Multi Service Access routers to provides low end PBX features which are more cost effective, reliable and feature rich CME is an optional component added to Cisco IOS to provide IP Telephony services using the same hardware Cisco IPC Express system integrates data, voice, security, and routing into a single IP communications platform. No separate server or appliance is required for any of these network capabilities Cisco 2600XM, 2800, 3700, or 3800 ISRs can use these same platforms to deploy Cisco IPC Express Cisco IPC Express supports Hot Standby Router Protocol (HSRP) features and can be used with Survivable Remote Site Telephony (SRST) to deliver increased redundancy and availability for telephony features

Benefits of CMELower cost of ownership Reduce Equipment Costs Reduced Network Administration Costs Reduced Cost of Adds, move and Changes Productivity Enhancement Easily Replicate Telephony Configuration Simplify Network Management Using the GUI

Basic OperationThe CME system provides PBX-like features and functions for IP phones. These features are the result of a centralized point of control and intelligence. The CME router provides all of the call control and intelligence needed for IP Phones to place and receive calls. The IP Phones and the CME router use SCCP to communicate.

CME FeaturesCisco CME encompasses the following featuresBasic Automatic Call Distribution (B-ACD) Customer Contact Voice and Video Telephony Rich-Media Conferencing Third-Party Applications (TCL Scripts) Unified Communications (Voicemail, Presence etc)

CME System ComponentsCisco IPC Express includes the following featuresCall processing software (Cisco CME) IP Communications platform IP-based applications

IP-based endpoints IP Based ApplicationsSeveral applications can be deployed with Cisco IPC Express to round out its business communications feature set. These include AA and voice mail applications such as Cisco UE and Cisco Unity.

Cisco Unity ExpressCisco UE is a voice mail and AA application available in a network module or advanced integration module (AIM) form factor that fits into the Cisco communications platform. To deploy Cisco UE, you order the hardware and purchase a feature license for the appropriate number of mailboxes.

Cisco UnityCisco Unity is a full-featured Windows-based voice messaging, unified messaging, and AA application. Cisco Unity features include support for up to 250,000 users and 19 languages, networking capability with Cisco UE and other traditional voice mail systems, distribution list capability, and a unified communications engine that supports both Lotus Domino and various Microsoft Exchange environments.

Deciding Between Cisco CME and CUCMYou have to consider many factors when deciding between Cisco Call Manager Express and Cisco Call Manager for the IP telephony application for your office or network. First consider the WAN environment. If the WAN has not been upgraded to deliver QoS protection for voice, or if there is limited WAN bandwidth, or if a WAN does not exist, a locally delivered call processing service is best for remote offices. In this scenario, Cisco CME delivers a very cost-effective solution. Another factor to consider is the type of operating environment required. If you require local MOH and local AA, and the business conditions are such that calls are typically placed to the PSTN rather than among different sites or offices, Cisco CME may be the most appropriate solution. You should also consider the telephony feature set required by the employees. For example, Cisco IPC Express does not support sophisticated call center applications. Therefore, if these are essential features, you would select Cisco Call Manager rather than Cisco CME. Businesses that typically lack the time, financial, or technical resources to manage a sophisticated call processing system may also consider Cisco CME, because it is easy to install and is a single IP communications platform to manage.

CME-Topic 2: Installation CME LicensesIOS License Feature License Phone User License Getting Necessary Files

Basic FilesA tar archive contains the basic files you need for Cisco Unified CME. Be sure to download the correct version for the Cisco IOS software release that is running on your router. The basic tar archive generally also contains the phone firmware files that you require, although you may occasionally need to download individual phone firmware files.

GUI FilesA tar archive contains the files that you need to use the Cisco Unified CME graphical user interface (GUI), which provides a mouse-driven interface for provisioning phones after basic installation is complete. Cisco Unified CME GUI files are version-specific; GUI files for one version of Cisco Unified CME are not compatible with any other version of Cisco Unified CME. When downgrading or upgrading Cisco Unified CME, the GUI files for the old version must be overwritten with GUI files that match the Cisco Unified CME version that is being installed.

XML Template FilesThe file called xml.template can be copied and modified to allow or restrict specific GUI functions to customer administrators, a class of administrative users with limited capabilities in a Cisco Unified CME system.

MOH FilesAn audio file named music-on-hold.au provides music for external callers on hold when a live feed is not used.This file is included in the tar archive with basic files (cme-basic-…).

Script FilesArchives containing Tcl script files are listed individually on the Cisco Unified CME software download website. For example, the file named app-h450-transfer.2.0.0.9.zip.tar contains a script that adds H.450 transfer and forwarding support for analog FXS ports.

Misc. FilesThese Misc. files includes Phone Firmware, Bundle TSP Achieve etc

CME InstallationGet necessary files from the Cisco websitesPlace these files to TFTP server Copy these files to router flash memory using Copy command (takes longer) Archive command (quick) Step 1: Download source files from www.cisco.comStep 2: Copy these files to TFTP server root directoryStep 3: Use the following commands to copy source files to the router flash memoryIf the file is an individual file, use copy commandRouter#copy tftp://192.168.1.1/P00307020300.sbn flash:If the file is a tar file, use archive tar command to extract the file to flash memoryRouter#archive tar /xtract source-url flash:/file-urlRouter#archive tar /xtract tftp://192.168.245.1/cme-full-7.0.0.0.tar flash:/Step 4: Verify the installation using show flash: commandRouter# show flash: or dir flash:31 128996 Sep 19 2005 12:19:02 -07:00 P00307020300.bin 32 461 Sep 19 2005 12:19:02 -07:00 P00307020300.loads 33 681290 Sep 19 2005 12:19:04 -07:00 P00307020300.sb2 34 129400 Sep 19 2005 12:19:04 -07:00 P00307020300.sbn

CME-Topic 3: Basic Configuration Step 1: Configure Telephony Service ParametersTo enable the CME functionality of a Cisco router running a CME-installed image, use the telephony-service command in global configuration mode. This will bring you into the telephony service configuration prompt. Configure the maximum number of phones using the max-ephones number command and maximum number of directory numbers using max-dn number.The following are the basic configuration commands required in telephony-service modeMAX-DN MAX-EPHONES IP SOURCE-ADDRESS gw1(config)#telephony-servicegw1(config-telephony)#max-dn 32gw1(config-telephony)#max-ephones 10gw1(config-telephony)#ip source-address 10.110.5.94

Configure the phone keep alive timeout period to be 15 seconds by issuing the keep alive seconds command. This timer specifies how long CME will wait before considering an IP phone unreachable and taking action to deregister it. The default timeout is 30 seconds.gw1(config-telephony)#keepalive 15

Configure a system message which will appear on phones associated with the CME. If you will change the system message during operational mode then this will reflect immediatelygw1(config-telephony)#system message Cisco CME

Next, tell the router to generate the configuration files for phones that associate with the CME using the create cnf-files command. It may take a couple minutes for the configuration process to be enabled.gw1(config-telephony)#create cnf-files

Step 2: Create Directory NumbersWhen CME configuration references an “ephone,” it is referring to an Ethernet phone connected via an IP network. An ephone represents the physical phone, and can be associated with a phone MAC address and other physical properties. A phone will only have one globally-unique, hard-coded MAC address, so to uniquely identify an ephone on your network, refer to the MAC address.At the logical layer of the VoIP model, a directory number represents a logical phone with an associated phone number and name (label). A Cisco IP phone can be associated with more than one directory number at a time, effectively making it a multi-line device with each line possessing its own directory number. The soft buttons on an IP phone each represent a single line. To configure a directory number, use the global configuration ephone-dn tag command. Use a tag of 1 for the first phone.gw1(config)#ephone-dn 1

At the ephone-dn configuration prompt, use the number number command to configure a phone number of 5001. Assign a name of “Host A” with the name name command. This will be the directory number associated with host A’s phone, which we will configure shortly.gw1(config-ephone-dn)#number 5001gw1(config-ephone-dn)#name Phone1

Step 3: Create PhonesBefore configuring the phones on the router, you will need to find out the MAC addresses of the hosts. Associate the MAC address with this ephone using the mac-address address command. The address must be in the format HHHH.HHHH.HHHH.gw1(config)#ephone 1gw1(config-ephone)#mac-address 0002.B3CE.72A3

Use the type type command to configure the type of phone. Since you are configuring Cisco IP Communicator to simulate Ethernet phones, use cipc as the phone type.gw1(config-ephone)#type cipc

Assign the first button on the phone to directory number 1 using the button line command. The button command assigns buttons to phone lines, as well as determines the type of ringer assigned to that phone line. The format for the button command we will use is “1:1”. The first 1 indicates the first button. The colon indicates a normal ringer. The second 1 represents directory number 1, previously configured with the ephone-dn 1 command.gw1(config-ephone)#button 1:1

Step 4: Specifying the necessary load informationThis step only required in case of hard phone.CME extracts firmware “Load File” into flash for all supported devices Newer CME versions organize these into sub-directories Firmware must be specified using the “load” command under telephony-service mode.These files should also be made available via TFTP.The first step is to make firmware files available for phones via TFTP. CME router organize all files in directories which you can see using following commandsgw1#show flashgw1#dir flash:

To publish files via TFTP please use the following command for every file from the specific phone directorygw1(config)# tftp-server flash:/phone/7940-7960/P00308000500.bin alias P00308000500.bingw1(config)# tftp-server flash:/phone/7940-7960/P00308000500.loads alias P00308000500.loadsgw1(config)# tftp-server flash:/phone/7940-7960/P00308000500.sb2 alias P00308000500.sb2gw1(config)# tftp-server flash:/phone/7940-7960/P00308000500.sbn alias P00308000500.sbn

After that define load files for all phone models, you can check from Cisco website for the load files for each phone (Tip: search for “Cisco Unified CME supported firmware” in google to find link page for this information. Look for all files against all specific phone model and file with * will be load file for the phone). Use the following command to specify this filegw1(config-telephony)#load 7960-7940 P00308000500

The last command for this series will begw1(config-telephony)#create cnf-files

CME-Topic 4: Deployment Models Today is weekend and I have decided to study more topics to cover the gape due to office workload during the whole week. So let’s start with deployment models (some theory):Deployment ModelsPBX System Key System Hybrid Model

PBX SystemDigital PSTN trunk lines, with direct inward dial (DID) for direct access to individual phone extensions and one or more receptionists Each phone user has his or her own private extension number Each IP phone normally has only a single phone number associated with it but in some cases you have to assign two extension to a single phone

router#show running-configephone-dn 4 dual-linenumber 1001name Bossephone-dn 5 dual-linenumber 1002name Assistantephone 7mac-address 000d.aa45.3f6ebutton 1:4ephone 8mac-address 000d.bb46.2e5abutton 1:5 2:4In above example, ephone 7 is the executive’s phone, with extension 1001 on line button 1. Ephone 8 is the assistant’s phone, with the assistant’s personal extension 1002 on button 1 and the executive’s extension 1001 shared on button 2. When a call arrives for 1001, both phones ring, and either phone can answer the call. When a call arrives for 1002, only the assistant’s phone rings. When the executive is using extension 1001, the assistant’s phone is unable to access the line. However, the display on the IP phone indicates that that line is in use so that the assistant knows that the executive is busy with a call

http://www.voiptechblogs.com/wp-content/uploads/2011/01/cme-pbx.jpg

Key SwitchOne phone line and many phones Often there is no need for personal extension numbers Cannot afford to hire a dedicated telephone receptionist

router#show running-configephone-dn 1 number 4085550101 no huntstop preference 0ephone-dn 2 number 4085550101 preference 1ephone 1 mac-address 000d.aa45.3f6e button 1:1 2:2ephone 2 mac-address 000d.bb46.2e5a button 1:1 2:2 ephone 3 mac-address 000d.cc47.1d49 button 1:1 2:2ephone 4 mac-address 000d.dd48.0c38 button 1:1 2:2

Hybrid ModelThis model is combination of both above deployment models and mostly used model because in most of the deployments you require one-to-one and one-to-many mapping. PBX and keyswitch configurations can be mixed on the same IP phone and can include both unique per-phone extensions for PBX-style calling and shared lines for keyswitch-style call operations.

http://www.voiptechblogs.com/wp-content/uploads/2011/01/cme-keyswitch.jpg

router#show running-configephone-dn 1 number 4085550101 no huntstop preference 0 ephone-dn 2 number 4085550101 preference 1 ephone 1 mac-address 000d.aa45.3f6e button 1:1 2:2 ephone 2 mac-address 000d.bb46.2e5a button 1:1 2:2 ephone 3 mac-address 000d.cc47.1d49 button 1:1 2:2 ephone 4 mac-address 000d.dd48.0c38 button 1:1 2:2

CME-Topic 5: GUI Installation Here we go with one more topic for today. In this part of the series, I will detail how to enable the GUI as well as setting up authentication for the GUI interface. So just follow with me to get it working.

Configuration StepsEnable HTTP Server Specify Path for GUI files Enable Authentication Configure GUI access users

http://www.voiptechblogs.com/wp-content/uploads/2011/01/cme-hybrid.jpg

Allow edit access from GUI

Step 1: Enable HTTP ServerFor GUI to work we need web server running, so use the following command to enable HTTP serverCME(config)#ip http server

Step 2: Specify path for GUI filesAfter enabling HTTP server now we have to tell HTTP server where to look for GUI files. You can see the location of your GUI files in flash using the following command and look for directory “gui”CME#dir flash:Now use below command to configure pathCME(config)#ip http path flash:/gui/

Step 3: Enable AuthenticationNow let’s configure authentication method for user access. The following is quick review of available optionsaaa – Use aaa login service enable – Uses the enable password that is set on the router (This is the default authentication method) local – Uses a local username and password that is set on the router using the username command tacacs – Uses a TACACS server I am using “local” authentication method for simplicity

CME(config)#ip http authentication localStep 4: Configure GUI access usersAs i used “local” authentication method for user validation, so i have to configure users for admin and end users to access GUICME(config)#telephony-serviceCME(config-telephony)#web admin system name admin password adminCME(config-telephony)#web admin customer name user password user

Step 5: Allow edit access from GUIWe have to add capability to the GUI for users to edit phones and other settings using the following commandCME(config-telephony)#dn-webeditCME(config-telephony)#time-webedit

We have done with all required configuration and have to test whether its working or not. To check GUI use http://server-ip-address/telephony_service.html (or whatever directory name you have. If everything goes well, then it will ask you to enter

username and password which we have configure in Step 4. After successful login you will see the following screen.

Troubleshooting Commands:CME#show ip http server statusCME#show ip http client all

CME-Topic 6: Auto-Registration and Auto-Assignment By default, CME registers any ephone (you can disables this feature) Ephone registration are not saved Auto-assignment associates ephone-dns to new ephones Auto-registered phones need to be registered to auto-assign Normally when you configure basic telephony-service parameters, then phone can register with CME although no DN will be assigned to them. You can disable this by using the following commandCME(config-telephony)#no auto-reg-ephone

After this command the phone which will try to register will receive message “Registration Rejected: No configuration entry…..”. You can also see which phones attempted registration with CME using below commandCME#show ephone attempted-registration

With auto-registration enabled you can configure auto-assignment of ephone-dn to the phones when they try to register with CME for any type of phoneCME(config-telephony)#auto assign 1 to 6

CME-Topic 7: Configuring CME using setup wizard Hi everyone good day after weekend and welcome back to study. Today i have planned to cover a topic which is not well fit into this series of topics as we have already configured CME using manual method but at least it’s good to know about configuring CME using setup wizard with auto registration enabled. So let’s start with step by step configuration setup and verification. I assumed that you have already copied all necessary files using “CME-Topic 2: Installation”.To start the process, run below mentioned series of commandsCME(config)#telephony-service setup

http://www.voiptechblogs.com/?p=173

http://www.voiptechblogs.com/wp-content/uploads/2011/01/cme-gui.jpg

Note: If you have already configured any telephony-service parameter manually then you will get message to remove all configuration before proceeding with setup wizard.

Do you want to setup DHCP service for your IP Phones? [yes/no]: noIf you already have DHCP on you LAN then enter “no” for thisDo you want to start telephony-service setup? [yes/no]: yesConfiguring Cisco IOS Telephony Services :Enter the IP source address for Cisco IOS Telephony Services :192.168.245.2Enter the Skinny Port for Cisco IOS Telephony Services : [2000]:How many IP phones do you want to configure : [0]: 10Do you want dual-line extensions assigned to phones? [yes/no]: yesWhat Language do you want on IP phones : 0 English 1 French 2 German 3 Russian 4 Spanish 5 Italian 6 Dutch 7 Norwegian 8 Portuguese 9 Danish 10 Swedish 11 Japanese [0]: Which Call Progress tone set do you want on IP phones : 0 United States 1 France 2 Germany 3 Russia 4 Spain 5 Italy 6 Netherlands 7 Norway 8 Portugal 9 UK 10 Denmark 11 Switzerland 12 Sweden 13 Austria 14 Canada 15 Japan [0]:

What is the first extension number you want to configure : 2001

Do you have Direct-Inward-Dial service for all your phones? [yes/no]: yes Enter the full E.164 number for the first phone :4846782001

Do you want to forward calls to a voice message service? [yes/no]: yes Enter extension or pilot number of the voice message service:2222 Call forward No Answer Timeout : [18]: 10*Mar 1 00:48:57.123: %LINK-3-UPDOWN: Interface ephone_dsp DN 1.1, changed state to up*Mar 1 00:48:57.131: %LINK-3-UPDOWN: Interface ephone_dsp DN 1.2, changed state to up*Mar 1 00:48:57.135: %LINK-3-UPDOWN: Interface ephone_dsp DN 2.1, changed state to up*Mar 1 00:48:57.143: %LINK-3-UPDOWN: Interface ephone_dsp DN 2.2, changed state to up*Mar 1 00:48:57.151: %LINK-3-UPDOWN: Interface ephone_dsp DN 3.1, changed state to up*Mar 1 00:48:57.159: %LINK-3-UPDOWN: Interface ephone_dsp DN 3.2, changed state to up*Mar 1 00:48:57.163: %LINK-3-UPDOWN: Interface ephone_dsp DN 4.1, changed state to up*Mar 1 00:48:57.171: %LINK-3-UPDOWN: Interface ephone_dsp DN 4.2, changed state to up*Mar 1 00:48:57.175: %LINK-3-UPDOWN: Interface ephone_dsp DN 5.1, changed state to up*Mar 1 00:48:57.175: %LINK-3-UPDOWN: Interface ephone_dsp DN 5.2, changed state to up*Mar 1 00:48:57.175: %LINK-3-UPDOWN: Interface ephone_dsp DN 6.1, changed state to up*Mar 1 00:48:57.183: %LINK-3-UPDOWN: Interface ephone_dsp DN 6.2, changed state to up*Mar 1 00:48:57.183: %LINK-3-UPDOWN: Interface ephone_dsp DN 7.1, changed state to up*Mar 1 00:48:57.183: %LINK-3-UPDOWN: Interface ephone_dsp DN 7.2, changed state to up*Mar 1 00:48:57.183: %LINK-3-UPDOWN: Interface ephone_dsp DN 8.1, changed state to up*Mar 1 00:48:57.183: %LINK-3-UPDOWN: Interface ephone_dsp DN 8.2, changed state to up*Mar 1 00:48:57.183: %LINK-3-UPDOWN: Interface ephone_dsp DN 9.1, changed state to up*Mar 1 00:48:57.187: %LINK-3-UPDOWN: Interface ephone_dsp DN 9.2, changed state to up*Mar 1 00:48:57.187: %LINK-3-UPDOWN: Interface ephone_dsp DN 10.1, changed state to up

*Mar 1 00:48:57.187: %LINK-3-UPDOWN: Interface ephone_dsp DN 10.2, changed state to upCNF-FILES: Clock is not set or synchronized, retaining old versionStampsCNF files update complete (post init)VerificationAfter setup is completed, you can verify auto configuration usingCME#show runNow you can register you phone with CME and then can verify using below commandsCME#show ephone summary

CME-Topic 8: Configuring Redundancy By continuing from the last topic lets configure redundancy for CME. Before configuring this lets make sure both primary CME and secondary CME have same configurations like below

Configuration for Primarytelephony-service max-ephones 10 max-dn 10 ip source-address 192.168.245.2 port 2000 auto assign 1 to 10 system message CME Primary dialplan-pattern 1 4846782... extension-length 4 voicemail 2222 max-conferences 8 gain -6 web admin system name admin password realtime web admin customer name user password realtime dn-webedit time-webedit transfer-system full-consult create cnf-files version-stamp Jan 01 2002 00:00:00

Configuration for Secondary

telephony-service max-ephones 10 max-dn 10 ip source-address 192.168.245.3 port 2000 auto assign 1 to 10 system message CME Primary dialplan-pattern 1 4846782... extension-length 4 voicemail 2222 max-conferences 8 gain -6 web admin system name admin password realtime web admin customer name user password realtime dn-webedit


time-webedit transfer-system full-consult create cnf-files version-stamp Jan 01 2002 00:00:00

Now lets start the actual part of this topic. First modify parameters on Primary CME as shown below

CME1(config-telephony)#ip source-address 192.168.245.2 port 2000 secondary 192.168.245.3

On Secondary modify parameters using following command

CME2(config-telephony)#ip source-address 192.168.245.3 port 2000 secondary 192.168.245.2 rehome 5

We have to specify “rehome” option only on secondary, so that users will be moved back to Primary with 5 seconds as it’s online.

Verification

As we have auto-registration enabled on both CMEs, so let register CIPC with Primary and make sure that CIPC have both CMEs configured as TFTP server in preferences=>Network tab

After registration you can see CIPC screen for System Message which is show “CME Primary” as configure under telephony-service mode

http://www.voiptechblogs.com/wp-content/uploads/2011/01/CIPC-TFTP-Settings.jpg

Now simple shutdown interface on Primay CME and phone will be registered with Secondary CME after keepalive timer will expires and you will get message on CME1 that phone has been unregistered abnormally.

CME1(config-if)#shut*Mar 1 03:04:44.527: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down*Mar 1 03:04:45.527: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down*Mar 1 03:05:54.755: %IPPHONE-6-UNREGISTER_ABNORMAL: ephone-1:SEP002481417C73 IP:192.168.245.1 Socket:1 DeviceType:Phone has unregistered abnormally.

Now lets see CIPC screen status

At the same time if you see ephone status on CME1 you will get output like show below

CME1#do sh ephone sumhairpin_block:ephone-1 Mac:0024.8141.7C73 TCP socket:[-1] activeLine:0 DECEASED

http://www.voiptechblogs.com/wp-content/uploads/2011/01/CME-Primary.jpg

http://www.voiptechblogs.com/wp-content/uploads/2011/01/CME-Secondary.jpg

mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 debug:0 primary_dn: 1*IP:192.168.245.1 CIPC keepalive 41 1:1Max 10, Registered 0, Unregistered 0, Deceased 1, Sockets 0ephone_send_packet process switched 0

As you enable interface on CME1, the phone will register back to the Primary CME after keepalive time.

CME1(config-if)#no shutCME1(config-if)#*Mar 1 03:25:06.819: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up*Mar 1 03:25:07.819: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up*Mar 1 03:25:39.107: %IPPHONE-6-REGISTER: ephone-1:SEP002481417C73 IP:192.168.245.1 Socket:1 DeviceType:Phone has registered.*Mar 1 03:25:39.147: %IPPHONE-6-REG_ALARM: 18: Name=SEP002481417C73 Load= 7.0.2.0 Last=Failback

CME-Topic 9: Voice Dial Peer Hunting

January 26th, 2011 | Author: Shafqut Hamid

The dial peer hunting function comes into play when you create two or more dial peers that match the same telephone number but reference different destination devices. You can set many parameters to adjust the order in which matching dial peers are selected. The default behavior is called longest match. For longest match, the dial peer that most exactly matches the telephone number is preferred. A longest match selects the destination pattern that matches the desired number using the fewest “.” wildcard characters. The best kind of longest match is an exact match, where no wildcards are used and the destination pattern and telephone number match literally and exactly.

The preference command is used to define a specific preference order for selecting the dial peers. The call goes to the dial peer with the lowest preference value. The default preference value is 0.

dial-peer voice 101 pots destination-pattern 2001 preference 1 port 1/0/0dial-peer voice 102 pots destination-pattern 2001 preference 2 huntstop



port 1/0/1dial-peer voice 200 voip destination-pattern 20.. session target ipv4:10.0.4.2

The huntstop command option tells the dial peer hunting mechanism not to try to find any further dial peer matches. Instead, the dial peer hunting stops at the dial peer containing the huntstop command. If no available voice port is found, it returns a busy tone to the caller.

CME-Topic 10: ephone-dn Dial Peers and Voice Ports Concepts

January 26th, 2011 | Author: Shafqut Hamid

The Cisco CME CLI configuration of IP phones and IP phone lines does not directly include dial peers or (virtual) voice ports.

The dial peer and virtual voice port resources used by Cisco CME are hidden inside the ephone-dn command. This simplifies the configuration steps needed to create an IP phone line.

It avoids the manual process of creating POTS dial peers to bind phone numbers to virtual voice ports.

ephone-dn 4number 1001name John Smithpreference 1

This ephone-dn command generates the configuration sub-elements

dial-peer voice 20004 pots destination-pattern 1001 preference 1 huntstop port 50/0/4voice-port 50/0/4 station-id number 1001 station-id name John Smith

Virtual voice port numbering 50/0/4 convention varies by router type, but it’s typically slot/card/port. The value 50 was arbitrarily chosen as the virtual “slot” number for the virtual voice ports just to avoid contention with the routers’ physical network module slots. Currently, no routers (that support Cisco CME) have 50 physical slots, so there’s no confusion with physical hardware slot numbers. The middle card number value is always 0. The port number, 4 in this example, matches the ephone-dn tag value (as in ephone-dn 4). The dial peer tag numbering (20004) is not significant, but it usually has some correlation to the ephone-dn tag number, which is 4 in this example.

If you execute the IOS command show running-config, you see only the ephone-dn commands you have entered, not the dial peer and virtual voice port commands. This is because the ephone-dn command automatically manages these subcommands for you, and there is no need for these to take up space in the router configuration. However, you can see the ephone-dn generated dial peers and virtual voice ports using the Cisco IOS commands show dial-peer summary and show voice-port summary.

CME-Topic 11: Configuring Softkey Template

February 1st, 2011 | Author: Shafqut Hamid

Configuring softkey template is very easy in CME and its required to customize the layout for different users as per their requirements and business need. Its a two step process to configure

1. Configure softkey template 2. Assign softkey template to ephone

Lets first see the default softkey layout as show below

The following are the available options under softkey template section

alerting Softkey order for alerting (ring out) state o Acct Account Code o CallBack Call back o Endcall End call

connected Softkey order for connected state o Acct Account Code o ConfList List all participants in conference o Confrn Conference o Endcall End call

http://www.voiptechblogs.com/wp-content/uploads/2011/02/Softkey-Default-Layout.jpg

o Flash Hook Flash o HLog HLog o Hold Hold o Join Join established call to conference o Park Call Park o RmLstC Remove last conference participant o Select Select call to join in conference o Trnsfer Call Transfer

hold Softkey order for HOLD state o Join Join established call to conference o Newcall New call o Resume Resume o Select Select call to join in conference

idle Softkey order for IDLE state o Cfwdall = Call Forward All o ConfList = List all participants in conference o Dnd = Do not Disturb o Gpickup = Group Call Pick Up o Hlog = Used to login and logout from hunt groups o Join = Join established call to conference o Login = Login o Newcall = New call (if your are already in one) o Pickup = Call Pick Up o Redial = Redial last number o RmLstC = Remove last conference participant

ringing Softkey order for ringing state o Answer Answer o Dnd Do not Disturb o HLog HLog

seized Softkey order for seized state o CallBack Call back o Cfwdall Call forward all o Endcall End call o Gpickup Group Call Pick Up o HLog HLog o MeetMe MeetMe Conference o Pickup Call Pick Up o Redial Redial

Step 1: Configure Softkey Template

For the simplicity of this illustration we will configure template only for “idle” state

CME1#configure terminalCME1(config)#ephone-template 20CME1(config-ephone-template)#softkeys idle Cfwdall Gpickup Login Redial

Step 2: Assign Softkey Template to ephone

CME1#configure terminalCME1(config)#ephone 1CME1(config-ephone)#ephone-template 20CME1(config-ephone)#restart

After restart the phone should look like this

CME-Topic 12: Codec Configuration


Sometimes we need to define different CODECs for different endpoints according to their location. There are two ways to specify codec for end devices

1. Using ephone-template 2. Configuring codec under ephone configuration

Option 1: Using ephone-template

The main purpose of using ephone-template is to define some common parameters for ephones rather defining these each time

CME1#configure terminalCME1(config)#ephone-template 20CME1(config-ephone-template)#codec ? g711ulaw Use G.711 u Law 64000 bps voice codec (default) g729r8 Use G.729 8000 bps voice codec to save network bandwidthCME1(config-ephone-template)#codec g711ulaw

http://www.voiptechblogs.com/wp-content/uploads/2011/02/Softkey-Customized-Layout.jpg

After configuring ephone-template we have to apply it to each ephone

CME1#configure terminalCME1(config)#ephone 1CME1(config-ephone)#ephone-template 20CME1(config-ephone)#restart

Option 2: Configuring Codec under ephone configuration

This method is useful if you have small number of ephones, otherwise if you have to change codec in future then you have to do if for all ephones which is waste of time for large deployments.

CME1#configure terminalCME1(config)#ephone 1CME1(config-ephone)#codec g711ulawCME1(config-ephone)#restart

CME-Topic 13: ephone-dn Secondary Number


The ephone-dn secondary number allows you to associate a second phone number with the same IP phone line. You can use this to create a simple hunt-on-busy configuration. This allows you to use the dial peer hunt-on-busy mechanism to make a call roll over from one line to another, even when the lines have different primary phone numbers

ephone-dn 4 number 1001 secondary 1007 name John Smith preference 1 secondary 2

A more detail example

ephone-dn 4 number 1001 secondary 1007 name John Smith no huntstop preference 1 secondary 2ephone-dn 5 number 1007 secondary 1001 name Jane Smith preference 1 secondary 2 no huntstop



Note: The dial peer hunting mechanism works only for hunt on busy. It does not provide hunting on no-answer timeout and no huntstop is the default configuration for a dial peer.

CME-Topic 14: Shared Line Configuration

February 15th, 2011 | Author: Shafqut Hamid

Shared line and overlay configuration used to share single line with multiple phones but functionality is totally different. I will discuss different scenarios for line sharing to make good understanding.

Scenario 1: One ephone-dn for multiple phones

In this scenario we will assign single DN to multiple phones but downside of this configuration is that if line will be in use on one phone it can’t be used on other phone. Below are the configuration

First call to 1001: o Both ephone 1 and 2 will ring. o ephone 1 answers call o ephone 2 will show remote in use state

Second incoming call: o will go to ephone 1 second channel

3rd incoming call: o will busy out, the call will not roll over to ephone 2 o ephone 2 can’t use that line for outgoing call

Scenario 2: Using multiple DNs with same number

To route calls to other phone with same DN we have to configure multiple DNs with same number with preference. To avoid the loop we can use huntstop and huntstop channel.

huntstop: Will stop looking next DN with same pattern and give busy tone

hutstop channel: Will stop call routing to 2nd channel in case dual-line configuration and try other phone with same number. We must use no huntstop, otherwise 2nd call will receive busy tone rather routing to next phone.

The configuration should look like this

ephone-dn 1 dual-line number 1001 preference 0

huntstop channel no huntstopephone-dn 2 dual-line number 1001 preference 1 huntstop channelephone 1 button 1:1ephone 2 button 1:2

First incoming call: o Phone 1 will ring because it has preference 0 o Line on Phone 2 is available for use

Second incoming call: o Due to low preference call should go phone 1 but due to

because of huntstop channel and no huntstop commands call rollover to phone 2

o Phone 2 will ring, Third Call:

o Due to low preference call should go phone 1 but due to because of huntstop channel and no huntstop commands call rollover to phone 2

o As this is 2nd call for phone 2 and huntstop channel has been configured

o Call will receive busy tone due to default huntstop configuration

CME-Topic 15: Overlay DN


This feature provides a way to overcome physical button limits on your IP phones. Instead of using normal one-line-to-one-button mapping, you can map up to ten lines or ephone-dns to the same physical phone button, which allows you to use the same phone button to answer incoming calls on any of the up to ten ephone-dns associated with the button.

NOTE: Although you can map ten ephone-dns to the same button but you can work with and see only one ephone-dn at a time.

Overlay DN acts as a multiplexer and dynamically selects the most appropriate ephone-dn to present on an IP phone button from within the configured overlay-dn set. When you receive incoming calls, the first ringing ephone-dn in the overlay set is presented. When you



make an outgoing call, the first idle ephone-dn in the overlay set is selected.

Below is very basic configuration

ephone-dn 1 number 1001 name Phone 1ephone-dn 2 number 1002 name Phone 2ephone 1 button 1o1,2

In the above scenario

1. First Incoming Call: o Ring Phone 1 and Phone 2 o Phone 1 answers the call

2. Second Incoming Call: o Only Phone 2 will ring o No calls waiting on Phone 1 because we are using “o”

Below are the option with can use for button definition to achieve different functionality

o creates an overlay set without call waiting c creates an overlay set with call waiting x creates an overlay rollover / expansion button – for use when

a primary overy button is occupied with a call instead of using call waiting.

If we need calls waiting alert then we can do configuration as below

ephone-dn 1 number 1001 name Phone 1ephone-dn 2 number 1002 name Phone 2ephone 1 button 1c1,2

In this scenario

1. First Incoming Call: o Ring Phone 1 and Phone 2 o Phone 1 answers the call

2. Second Incoming Call: o Phone 2 will ring

o User on Phone 1 will hear call waiting beep

Called Name Display for Overlay Extensions

If you assign multiple unrelated extensions to the same phone button using an overlay, the phone user needs to know which extension is being called. Cisco CME 3.2 introduced the called-name dialed number identification service (DNIS) to address this problem. This uses the command service dnis overlay (set under telephony-service). If this command is active, an incoming call on the (hidden) second through last members of the overlay set displays the extension name that is being called on the bottom line of the Cisco IP phone display. This name is set using the name command in the ephone-dn extension configuration. This allows the phone user to see at a glance which extension is ringing and allows the phone user to answer the call with a greeting appropriate to the specific extension. When the first (primary) extension in the overlay set is called, no name display appears, because the identity of the first extension line is implicitly indicated by the extension number display next to the phone line button itself.

telephony-service service dnis overlay

CME-Topic 16: Hunt Group Configuration


The ephone-hunt Command

The ephone-hunt command gives you a simple way to configure a sequential call group based on a list of extension numbers. You can configure up to ten ephone-hunt groups in a Cisco CME system (as of CME 3.0). Each ephone-hunt group can contain a list of up to ten extension numbers.

You can choose from three ephone-hunt modes:

Sequential mode This gives a simple ordered list of extension numbers. Each extension number in the list is tried in turn, always starting from the beginning of the list. If the end of the list is reached without finding an available number, the call is forwarded to a number configured as a final destination.

Peer mode This gives a circular list of extension numbers. The starting point in the list for a new call is set by the last number tried for the preceding call. Because the list is circular, you have to set a parameter to limit how many times a call can be sequenced from one extension to the next. This value has to be



less than the global call forwarding hop count limit set for the entire Cisco CME system by the max-redirect command. You have to do this to avoid an infinite hunting loop. You control it by setting the maximum number of hops for the call in the ephone-hunt command’s subcommands. As soon as the maximum number of hops has been reached, the call is forwarded to the number defined as the final destination for the hunt group.

Longest idle This also gives a circular list of extension numbers. The starting point in the list for a new call is set by the number that has been on-hook for the longest period of time. Again, because the list is circular, you have to set a parameter to limit how many times a call can be sequenced from one extension to the next. As soon as the maximum number of hops has been reached, the call is forwarded to the number defined as the final destination for the hunt group. The longest idle option was introduced in Cisco CME 3.2.

ephone-hunt 1 sequential pilot 5001 list 1001, 1003, 1007, 1008 final 6001 preference 1 timeout 15 ephone-hunt 2 peer (or longest-idle) pilot 5002 list 1002, 1003, 1008, 1009 final 6002 hops 3 preference 1 timeout 15

When you use the ephone-hunt command and enter a list of numbers, here’s what happens:

The system searches for all ephone-dn entries that have primary numbers that match the ephone-hunt list.

For each ephone-dn that matches, the ephone-dn builds an additional dial peer. This dial peer has a number that’s derived from the ephone-hunt pilot number plus the relative position of the matched number in the ephone-hunt list. The dial peer also includes the virtual voice port number from the matching ephone-dn.

CME-Topic 17: Network Directory




User directory is very cool features which allow end users to search for extension for any specific user. When we are defining ephone-dn with name parameters it will automatically define directory for end users which they can view by pressing “Directories” button on the phone.

You can also define static entries for directory using directory command in telephony-service mode for any pattern.

telephony-service service dnis dir-lookup directory entry 1 5550500 name Shafqut Hamid directory entry 2 5550501 name Shamid

CME-Topic 18: Call Forwarding Configuration


You can use call forwarding to provide simple forms of call coverage. Cisco CME supports call forwarding for busy, no-answer, and unconditional (or call-forward all). When you use call forwarding to provide call coverage, the called number for the call changes. This can affect what is displayed on the IP phone receiving the forwarded call and entry into voice mail.

ephone-dn 4 dual-line number 1001 name Shafqut Hamid call-forward busy 1007 call-forward noan 1007 timeout 20 ephone-dn 5 dual-line number 1007



http://www.voiptechblogs.com/wp-content/uploads/2011/02/Network-Directory.jpg

name Shamid call-forward busy 1001 call-forward noan 1001 timeout 20

There’s an issue with this configuration, because it potentially creates an infinite forwarding loop. You can limit the number of times the call forwarding loop is traversed by setting the max-redirect command under telephony-services. The max-redirect command has a range of 5 to 20 and a default value of five. This is a global command and limits call forwarding system-wide.

The other thing which you should consider while allowing call forward, is to define call-forward pattern which will restrict the user to enable forwarding to certain numbers not any number. You can also use digit manipulation while forwarding calls

telephony-service max-redirect 5 call-forward pattern . . . .

The other way to restrict users to a specific length of call forwarding number from the phone is using call-forward max-length command under ephone-dn. If you will set this parameter to “0” then call forwarding feature will be disabled and soft key on the phone will be grayed out.

ephone-dn 5 dual-line number 1007 name Shafqut Hamid call-forward max-length 4 call-forward busy 1001 call-forward noan 1001 timeout 20

CME-Topic 19: Call Transfer


We have to look into call transfer in two prospective

User Prospective System Prospective

User can transfer call using soft key on the phone which can be consulted or blind transfer according to the system configuration. You can configure call transfer feature on the system which give you following options

full-blind: Perform call transfers without consultation using H.450.2 or SIP REFER standard methods

full-consult: Perform H.450.2/SIP call transfers with consultation using second phone line if available, fallback to full-blind if second line unavailable. This is the recommended mode for most systems. See also ‘supplementary-service’ commands under ‘voice service voip’ and dial-peer.

local-consult: Perform call transfers with local consultation using second phone line if available, fallback to blind for non-local consultation/transfer target. Uses Cisco proprietary method.

The following commands required to configure call transfer

telephony-service transfer-system {full-blind|full-consult|local-consult} transfer-pattern . . . .

Call transfer-pattern command will add some security against toll fraud.

CME-Topic 20: Call Park


Typically, when you place a call on hold, you can retrieve the call only from the original phone where you placed the call on hold. Although system let you to break this rule by using shared line which allow you to retrieve this call from any phone configured with the same extension.

Call park is enhanced feature which allow you to pick up call put on hold from any phone across the organization.

Call park “parks” the caller on hold at an extension rather than on a specific line.

Any IP phone that is able to dial the park extension number can retrieve the call.

The call park system works by finding free ephone-dns in the Cisco Unified CME configuration that you have not assigned to an IP phone and have specifically designated as a call park slot.

You can either allow CME to park calls randomly at the first available ephone-dn or allow users to choose the extension where the call is parked. Each of these scenarios fits different environments.

Calls being parked at random extensions might work well for a warehouse environment with a voice paging system. When an employee has a call, the receptionist could announce, “Larry, you have a call on 5913″ over the loudspeaker, at which point Larry could go to a phone and dial the extension to pick up the call on hold.

Choosing extensions would work well for an electronics superstore in which each department responded to a known

extension number. For example, software could be extension 301, cameras could be extension 302, and so on. The receptionist can then park multiple calls on a single call park number (this would require multiple ephone-dns assigned the same extension). As the specific department retrieves the calls, CME would distribute them in the order in which they were parked. The call parked longest would be answered first. You can configure call park simply by adding an ephone-dn designated for call park purposes.

This can be implemented in very simple way using command park-slot in ephone-dn configuration mode

ephone-dn 5 number 3001 park-slot

Park-slot has the following options

reserved-for <DN> timeout <seconds> limit <count> notify <dn> only recall transfer <dn> alternate <dn> retry <seconds>

CME(config)# ephone-dn 50CME(config-ephone-dn)# number 3001CME(config-ephone-dn)# name MaintenanceCME(config-ephone-dn)# park-slotCME(config-ephone-dn)# exitCME(config)# ephone-dn 51CME(config-ephone-dn)# number 3002CME(config-ephone-dn)# name SalesCME(config-ephone-dn)# park-slot ?

reserved-for reserves this park slot for the exclusive use of the phone with the extension indicated by the transfer target extension number and timeout set call park timeout.

CME(config-ephone-dn)# park-slot timeout ?

<0-65535> Specify the park timeout (seconds) before the call is returned to the number it was parked from.

CME(config-ephone-dn)# park-slot timeout 60 ?

Limit Set call park timeout count limit

CME(config-ephone-dn)# park-slot timeout 60 limit ?

<1-65535> Specify the number of park timeout cycles before the call is disconnected

CME(config-ephone-dn)# park-slot timeout 60 limit 10 ?notify Define additional extension number to notify for park timeoutrecall recall transfer back to originator phone after timeouttransfer Transfer to originator or specified destination after timeout limit exceeded

Notify Define additional extension number to notify for park timeout recall recall transfer back to originator phone after timeout transfer, transfer to originator or specified destination after timeout limit exceeded

CME(config-ephone-dn)# park-slot timeout 60 limit 10 recall ?alternate Transfer to alternate target if original target is busyretry Set recall/transfer retry interval if target is in use

Alternate transfer to alternate target if original target is busy retry Set recall/transfer retry interval if target is in use

CME(config-ephone-dn)# park-slot timeout 60 limit 10 recall alternate 1006 retry 10 limit 2

CME-Topic 21: Call Pickup


Answers another ringing phone Three types of call pickup

o Local Group Pickup: A user can pick up and answer a ringing phone by pressing the GPickup button and pressing an asterisk (*) on his local phone.

o Directed Group Pickup: A user can pick up another ringing phone directly by pressing the pickup key and dialing the DN of the ringing phone. This action allows CME to transfer the call to the local phone.

o Other Group Pickup: A user can pick up a ringing phone by pressing the GPickUp button and entering the other group number on his local phone.

Configuring Call Pickup is very simple, just divide phones into groups and then assign each ephone-dn to specific pickup group

CME(config)# ephone-dn 1CME(config-ephone-dn)# pickup-group 5509CME(config-ephone-dn)# ephone-dn 2CME(config-ephone-dn)# pickup-group 5509CME(config-ephone-dn)# ephone-dn 3CME(config-ephone-dn)# pickup-group 5509CME(config-ephone-dn)# ephone-dn 4CME(config-ephone-dn)# pickup-group 5510CME(config-ephone-dn)# ephone-dn 5CME(config-ephone-dn)# pickup-group 5510CME(config-ephone-dn)# ephone-dn 6CME(config-ephone-dn)# pickup-group 5510

If any extension in group is ringing then other can pick up that call by simply dialing pickup-group number after pressing GPickUp or PickUp. Some consideration

If multiple phones are ringing then CME will offer oldest call In case of single pickup group, user don’t have to dial pickup-

group number

CME-Topic 22: Intercom


Intercom configurations are common in traditional phone systems. This feature allows an administrative assistant and executive to work closely together by having a speakerphone between them technically, the way intercom deployments work is through a speed-dial and auto-answer speed-dial configuration. If the administrative assistant presses the button configured as an intercom, it speed dials the executive’s phone, which auto-answers the call on muted speakerphone. To establish two-way communication, the executive deactivates mute (by pressing the Mute button). Understanding this helps make the intercom configuration much clearer.

To configure intercom functionality, you must configure two new ephone-dns, one for each side of the intercom connection. These intercom lines should be assigned a number, just like any other ephone-dn. However, in order to prevent others from accidentally (or purposely) dialing the intercom and ending up on muted speakerphone for a random IP phone, the number should be something users cannot dial from other IP phones.

CME(config)# ephone-dn 11CME(config-ephone-dn)# number A100CME(config-ephone-dn)# intercom A101 label “Manager”



CME(config-ephone-dn)# exitCME(config)# ephone-dn 22CME(config-ephone-dn)# number A101CME(config-ephone-dn)# intercom A100 label “Assistant”CME(config-ephone-dn)# exitCME(config)# ephone 2CME(config-ephone)# button 2:11CME(config-ephone)# restartCME(config-ephone)# exitCME(config)# ephone 2CME(config-ephone)# button 2:22CME(config-ephone)# restart

Notice the number assigned to ephone-dn 11 is A100. You cannot dial this number from a Cisco IP phone keypad, but you can assign it to a speed-dial button. The intercom command acts like a speed-dial button on the ephone-dn. In the case of ephone-dn 11, the command intercom A101 dials the number A101, which is assigned to ephone-dn 22. Because ephone-dn 22 is also configured with the intercom command, it auto-answers the incoming call on muted speakerphone. The label syntax allows you to assign a logical name to the speed-dial; otherwise, the A101 or A100 label will show up next to the line button on the phone. There are three other arguments you can use with the intercom command to tune the functionality:

barge-in: Automatically places an existing call on hold and causes the intercom to immediately answer.

no-auto-answer: Causes the phone to ring rather than auto-answer on speakerphone

no-mute: Causes the intercom to answer with un-muted speakerphone rather than muted. While this is beneficial to allow immediate two-way conversation, you also run the risk of one side barging into existing conversations or background noise.

CME-Topic 23: Paging Configuration


Paging is a one-way, speakerphone based announcement Accomplished by creating a paging number and assigning

phones to the paging number Each IP phone can only be assigned one paging number Supports unicast (mean each phone will receive its own audio

stream) or multicast (all phones will listen to same single audio stream)

Support multiple paging groups which enables you to assign one phone to more than one paging group

CME(config)#ephone-dn 80CME(config-ephone-dn)#number 5555CME(config-ephone-dn)#pagingCME(config-ephone-dn)#exitCME(config)#ephone 1CME(config-ephone)#paging-dn 80CME(config-ephone)#exitCME(config)#ephone 2CME(config-ephone)#paging-dn 80CME(config-ephone)#exit

You can use nested configuration to use multiple paging group in a single group

CME(config)#ephone-dn 81CME(config-ephone-dn)#number 6666CME(config-ephone-dn)#pagingCME(config-ephone-dn)#paging group 80,81CME(config-ephone)#exitCME(config)#ephone 2CME(config-ephone)#paging-dn 80CME(config-ephone)#exit

For multicast paging use the following in paging group configuration mode

CME(config-ephone-dn)#paging ip A.B.C.D port 2000

CME-Topic 24: After Hours Call Blocking


After hours call blocking blocks specific number for a specific time period

Configured from telephony service mode Phones can be exampled (always or through pins) 24-7 block patterns can never be allowed

After-hours call blocking has three major steps of configuration:

1. Define days and/or hours of the day that your company considers off-hours.

2. Specify patterns that you would like to block during the times specified in Step 1.

3. Create exemptions to the policy, if needed.

CME(config-telephony)# after-hours date dec 25 00:00 00:00CME(config-telephony)# after-hours day fri 17:00 8:00

CME(config-telephony)# after-hours day thu 17:00 8:00CME(config-telephony)# after-hours day wed 17:00 8:00CME(config-telephony)# after-hours day tue 17:00 8:00CME(config-telephony)# after-hours day mon 17:00 8:00CME(config)# telephony-service

CME(config-telephony)# after-hours block pattern 1 91..........CME(config-telephony)# after-hours block pattern 2 9011TCME(config-telephony)# exit

CME(config)#ephone 1CME(config-ephone)# after-hours exempt

You can use alternate way to exempt phone by using PIN, because users have to give PIN to dial blocked patterns during after-hours. User can use Login (This SoftKey will be active after configure login under telephony-service) soft key with key configured to avail dialing facility during off-hours

CME(config-telephony)# login timeout 120 clear 23:00CME(config-telephony)# exit

CME(config)#ephone 2CME(config-ephone)# pin 1234CME(config-ephone)# restart

CME-Topic 25: Automatic Line Selection


This feature is very useful on multi-line IP phones where lifting the handset automatically selects the first ringing line on the phone or, if no line is ringing, selects the first available idle line for outgoing calls. This is the default behavior for all multi-line IP phones. But in some situations you require that a specific line button should be explicitly pressed to select an outgoing line or to answer an incoming call. In Cisco CME 3.0 and later, you have the flexibility to assign the type of line selection that each IP phone uses.

The Automatic Line Selection feature allows you to specify, on a per-phone basis, the line that is selected when you pick up a phone handset. Any of the following behaviors can be assigned on a per-phone basis:

Automatic line selection Picking up the handset answers the first ringing line or, if no line is ringing, selects the first idle line. Use the auto-line command with no keyword or argument. This is the default.

Manual line selection (no automatic line selection) Pressing the Answer soft key answers the first ringing line, and pressing a line button selects a line for an outgoing call. Picking up the handset does not answer calls or provide dial tone.

Use the no auto-line command. Automatic line selection for incoming calls only. Picking up the handset answers the first ringing line, but if no line is ringing, it does not select an idle line for an outgoing call. Pressing a line button selects a line for an outgoing call.

Use the auto-line incoming command. Automatic line selection for outgoing calls only. Picking up the handset for an outgoing call selects the line associated with the button-number argument. If a button number is specified and the line associated with that button is unavailable (because it is a shared line in use on another phone), no dial tone is heard when the handset is lifted. You must press an available line button to make an outgoing call. Incoming calls must be answered by pressing the Answer soft key or pressing a ringing line button.

Use the auto-line command with the button-number argument. Automatic line selection for incoming and outgoing calls. Pressing the Answer soft key or picking up the handset answers an incoming call on the line associated with the specified button. Picking up the handset for outgoing calls selects the line associated with the specified button.

Use the auto-line command with the button-number argument and answer-incoming keyword.

ephone 5 auto-line 5 answer-incoming

CME-Topic 26: MOH Configuration


MOH is an audio stream which can be played to PSTN and VoIP G.711 or G.729 callers who are placed on hold by phones in a Cisco Unified CME system. This audio stream is intended to reassure callers that they are still connected to their calls.

When the phone receiving MOH is part of a system that uses a G.729 codec, transcoding is required between G.711 and G.729. The G.711 MOH must be translated to G.729.

Note: Because of compression, MOH using G.729 is of significantly lower fidelity than MOH using G.711.

Below are some MOH resources

Flash Memory: MOH can be played from local stored files in flash memory without the requirement of external source

Live Feed: The multicast audio stream has minimal delay for local IP phones. The MOH stream for PSTN callers is delayed by a few seconds. If the live feed audio input fails, callers on hold hear silence.

Live Feed and Flash Memory: This is the preferred method if you want to use Live Feed, so that if Live Feed fails then users still have MOH from local flash memory

Below is very basic configuration for MOH

CME(config-telephony)# moh {filename.wav | filename.au}CME(config-telephony)# multicast moh 239.1.1.30 port 2000

Cisco Unified CME 8.0 MOH enhancement allows you to create MOH groups and assign ephone extension numbers to these MOH groups to receive different media streams. Callers to the extension numbers configured under the MOH groups can listen to different MOH media streams when they are placed on hold. Following precedence rules are applicable when an ephone caller is placed on hold:

MOH group defined for internal calls takes highest precedence MOH group defined in ephone-dn takes the second highest

precedence MOH group defined in ephone-dn-template takes precedence if

MOH group is not defined in ephone-dn or internal call. Extension numbers defined in a MOH-group has the least

precedence Phones not associated with any MOH groups default to the MOH

parameters defined in the moh command under telephony-service configuration mode.

router# show voice moh-grouptelephony-service moh alaska.wav Moh multicast 239.1.1.1 port 16384 route 10.1.4.31 10.1.1.2

voice moh-group 1 description this moh group is for sales moh flash:/hello.au multicast moh 239.1.1.1 port 16386 route 239.1.1.3 239.1.1.3 extension-range 1000 to 1999 extension-range 2000 to 2999 extension-range 3000 to 3999 extension-range A1000 to A1999

voice moh-group 2

description (not configured) moh flash1:/minuet.au multicast moh 239.23.4.10 port 2000 extension-range 7000 to 7999

ISDN Cause Codes January 21st, 2011 | Author: Shafqut Hamid Cause No. 0This is usually given by the router when none of the other codes apply. This cause usually occurs in the same type of situations as cause 1, cause 88, and cause 100.Cause No. l – Unallocated (unassigned) number.This cause indicates that the destination requested by the calling user cannot be reached because, although the number is in a valid format, it is not currently assigned (allocated).What it usually means:1. The SPIDS may be incorrectly entered in the router or the Telco switch, giving a SPID failure in the router logs.2. The ISDN phone number being dialed by the router is invalid and the telco switch cannot locate the number to complete the call, as it is invalid.3. On long distance calls, the call cannot be properly routed to its destination.Cause No. 2 – No route to specified transit network (national use).This cause indicates that the equipment sending this cause has received a request to route the call through a particular transit network which it does not recognize. The equipment sending this cause does not recognize the transit network either because the transit network does not exist or because that particular transit network not serve the equipment which is sending this cause.Cause No. 3 – No route to destination.This cause indicates that the called party cannot be reached because the network through which the call has been routed does not serve the destination desired. This cause is supported on a network dependent basis.Cause No. 4 – send special information tone.This cause indicates that the called party cannot be reached for reasons that are of a long term nature and that the special information tone should be returned to the calling party.Cause No. 5 – misdialed trunk prefix (national use).This cause indicates the erroneous inclusion of a trunk prefix in the called party number. This number is to sniped from the dialed number being sent to the network by the customer premises equipment.Cause No. 6 – channel unacceptable.This cause indicates that the channel most recently identified is not acceptable to the sending entity for use in this call.



Cause No. 7 – call awarded. being delivered in an established channel.This cause indicates that the user has been awarded the incoming call and that the incoming call is being connected to a channel already established to that user for similar calls (e.g. packet-mode x.25 virtual calls).Cause No. 8 – preemption.This cause indicates the call is being preempted.Cause No. 9 – preemption – circuit reserved for reuse.This cause indicates that the call is being preempted and the circuit is reserved for reuse by the preempting exchange.Cause No. 16 – normal call clearing.This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared.What it means:This could be almost anything; it is the vaguest of the cause codes. The call comes down normally, but the reasons for it could be:1. Bad username or password2. Router’s settings do not match what is expected by the remote end.3. Telephone line problems.4. Hung session on remote end.Cause No. 17 – user busy.This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determined user busy it is noted that the user equipment is compatible with the call.What is means:Calling end is busy.Cause No. 18 – no user responding.This cause is used when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated.What it means:The equipment on the other end does not answer the call. Usually this is a misconfiguration on the equipment being called.Cause No. 19 – no answer from user (user alerted).This cause is used when the called party has been alerted but does not respond with a connect indication within a prescribed period of time. Note – This cause is not necessarily generated by Q.931 procedures but may be generated by internal network timers.Cause No. 20 – subscriber absent.This cause value is used when a mobile station has logged off. Radio contact is not obtained with a mobile station or if a personal telecommunication user is temporarily not addressable at any user-network interface.Cause No. 21 – call rejected.This cause indicates that the equipment sending this cause does not wish to accept this call. although it could have accepted the call

because the equipment sending this cause is neither busy nor incompatible. This cause may also be generated by the network, indicating that the call was cleared due to a supplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection.What it means:This is usually a telco issue. The call never reaches the final destination, which can be caused by a bad switch translation, or a misconfiguration on the equipment being called.Cause No. 22 – number changed.This cause is returned to a calling party when the called party number indicated by the calling party is no longer assigned. The new called party number may optionally be included in the diagnostic field. If a network does not support this cause, cause no. 1, unallocated (unassigned) number shall be used.Cause No. 26 – non-selected user clearing.This cause indicates that the user has not been awarded the incoming call.Cause No. 27 – destination out of order.This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioning correctly. The term “not functioning correctly” indicates that a signal message was unable to be delivered to the remote party; e.g., a physical layer or data link layer failure at the remote party or user equipment off-line.Cause No. 28 – invalid number format (address incomplete).This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete.Cause No. 29 – facilities rejected.This cause is returned when a supplementary service requested by the user cannot be provide by the network.Cause No. 30 – response to STATUS INQUIRY.This cause is included in the STATUS message when the reason for generating the STATUS message was the prior receipt of a STATUS INQUIRY.Cause No. 31 – normal. unspecified.This cause is used to report a normal event only when no other cause in the normal class applies.Cause No. 34 – no circuit/channel available.This cause indicates that there is no appropriate circuit/channel presently available to handle the call.What it means:There is no place on the Public Telephone network to place the call; the call never gets to its destiation. This is usually a temporary problem.Cause No. 35 – Call Queued.Cause No. 38 – network out of order.This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time e.g., immediately re-attempting the call is not likely to be successful.

Cause No. 39 – permanent frame mode connection out-of-service.This cause is included in a STATUS message to indicate that a permanently established frame mode connection is out-of-service (e.g. due to equipment or section failure)Cause No. 40 – permanent frame mode connection operational.This cause is included in a STATUS message to indicate that a permanently established frame mode connection is operational and capable of carrying user information.Cause No. 41 – temporary failure.This cause indicates that the network is not functioning correctly and that the condition is no likely to last a long period of time; e.g., the user may wish to try another call attempt almost immediately.What it means:This means that there is a temporary failure at the physical layer on the ISDN network. If you remove the ISDN cable from the Netopia, you would see this. It’s usually temporary.Cause No. 42 – switching equipment congestion.This cause indicates that the switching equipment generating this cause is experiencing a period of high traffic.What it means:Just too much going on at this point on the ISDN network to get the call through to its destination.Cause No. 43 – access information discarded.This cause indicates that the network could not deliver access information to the remote user as requested. i.e., user-to-user information, low layer compatibility, high layer compatibility or sub-address as indicated in the diagnostic. It is noted that the particular type of access information discarded is optionally included in the diagnostic.Cause No. 44 – requested circuit/channel not available.This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other side of the interface.Cause No. 46 – precedence call blocked.This cause indicates that there are no predictable circuits or that the called user is busy with a call of equal or higher preventable level.Cause No. 47 – resource unavailable, unspecified.This cause is used to report a resource unavailable event only when no other cause in the resource unavailable class applies.Cause No. 49 – Quality of Service not available.This cause is used to report that the requested Quality of Service, as defined in Recommendation X.213. cannot be provided (e.g., throughput of transit delay cannot be supported).Cause No. 50 – requested facility not subscribed.This cause indicates that the user has requested a supplementary service which is implemented by the equipment which generated this cause but the user is not authorized to use.

What it means:The switch looks at the number being dialed and thinks it is for another service rather than ISDN. If the phone number is put in the correct format, the call should be placed properly. There are no standards for this, all Telcos have their own system for programming the number formats that the switches will recognize. Some systems want to see 7 digits, some 10, and others 11.Cause No. 52 – outgoing calls barred.Cause No. 53 – outgoing calls barred within CUG.This cause indicates that although the calling party is a member of the CUG for the outgoing CUG call. Outgoing calls are not allowed for this member of the CUG.Cause No. 54 – incoming calls barredCause No. 55 – incoming calls barred within CUG.This cause indicates that although the calling party is a member of the CUG for the incoming CUG call. Incoming calls are not allowed for this member of the CUG.Cause No. 57 – bearer capability not authorized.This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but the user is not authorized to use.Cause No. 58 – bearer capability not presently available.This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but which is not available at this time.Cause No. 62 – inconsistency in outgoing information element.This cause indicates an inconsistency in the designated outgoing access information and subscriber class.Cause No. 63 – service or option not available. unspecified.This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies.Cause No. 65 – bearer capability not implemented.This cause indicates that the equipment sending this cause does not support the bearer capability requested.What it means:1. In most cases, the number being called is not an ISDN number but an analog destination.2. The equipment is dialing at a faster rate than the circuitry allows, for example, dialing at 64K when only 56K is supported.Cause No. 66 – channel type not implemented.This cause indicates that the equipment sending this cause does not support the channel type requested.Cause No. 69 – requested facility not implemented.This cause indicates that the equipment sending this cause does not support the requested supplementary services.Cause No. 70 – only restricted digital information bearer capability is available.This cause indicates that the calling party has requested an

unrestricted bearer service but the equipment sending this cause only supports the restricted version of the requested bearer capability.Cause No. 79 – service or option not implemented unspecified.This cause is used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies.Cause No. 81 – invalid call reference value.This cause indicates that the equipment sending this cause has received a message with a call reference which is not currently in use on the user-network interface.Cause No. 82 – identified channel does not exist.This cause indicates that the equipment sending this cause has received a request to use a channel not activated on the interface for a call. For example, if a user has subscribed to those channels on a primary rate interface numbered from l to 12 and the user equipment or the network attempts to use channels 3 through 23, this cause is generated.Cause No. 83 – a suspended call exists, but this call identify does not. This cause indicates that a call resume has been attempted with a call identity which differs from that in use for any presently suspended call(s).Cause No. 84 – call identity in use.This cause indicates that the network has received a call suspended request containing a call identity (including the null call identity) which is already in use for a suspended call within the domain of interfaces over which the call might be resumed.Cause No. 85 – no call suspended.This cause indicates that the network has received a call resume request containing a call identity information element which presently does not indicate any suspended call within the domain of interfaces over which calls may be resumed.Cause No. 86 – call having the requested call identity has been cleared.This cause indicates that the network has received a call resume request containing a call identity information element indicating a suspended call that has in the meantime been cleared while suspended (either by network time-out or by the remote user).Cause No. 87 – user not a member of CUG.This cause indicates that the called user for the incoming CUG call is not a member of the specified CUG or that the calling user is an ordinary subscriber calling a CUG subscriber.Cause No. 88 – incompatible destination.This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility. high layer compatibility or other compatibility attributes (e.g., data rate) which cannot be accommodated.What it means:1. This usually means that the Number To Dial in the Connection Profile is in the wrong format. You may need to dial a 10 or 11 digit number, or dial a 9 in front of the number if it is a Centrex line.

2. This problem may also give a Cause 111.3. Dialing at the wrong line speed can also give this Cause.Cause No. 90 – non-existent CUG.This cause indicates that the specified CUG does not exist.Cause No. 91 – invalid transit network selection (national use).This cause indicates that a transit network identification was received which is of an incorrect format as defined in Annex C/Q.931Cause No. 95 – invalid message, unspecified.This cause is used to report an invalid message event only when no other cause in the invalid message class applies.Cause No. 96 – mandatory information element is missing.This cause indicates that the equipment sending this cause has received a message which is missing an information element which must be present in the message before that message can be processed.What it means:This is rarely seen in North America but usually means that the number that is being dialed is in the wrong format, (similar to cause 88). Some part of the format being used is not understood by either the remote side equipment or the switching equipment between the source and destination of the call.Cause No. 97 – message type non-existent or not implemented.This cause indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not defined of defined but not implemented by the equipment sending this cause.Cause No. 98 – message not compatible with call state or message type non-existent.This cause indicates that the equipment sending this cause has received a message such that the procedures do not indicate that this is a permissible message to receive while in the call state, or a STATUS message was received indicating an incompatible call state.Cause No. 99 – Information element / parameter non-existent or not implemented.This cause indicates that the equipment sending this cause has received a message which includes information element(s)/parameter(s) not recognized because the information element(s)/parameter name(s) are not defined or are defined but not implemented by the equipment sending the cause. This cause indicates that the information element(s)/parameter(s) were discarded. However, the information element is not required to be present in the message in order for the equipment sending the cause to process the message.Cause No. 100 – Invalid information element contents.This cause indicates that the equipment sending this cause has received and information element which it has implemented; however, one or more of the fields in the information element are

coded in such a way which has not been implemented by the equipment sending this cause.What it means:Like cause 1 and cause 88, this usually indicates that the ISDN number being dialed is in a format that is not understood by the equipment processing the call. SPIDs will sometimes fail to initialize with a Cause 100, or a call will fail with this cause.Cause No. 101 – message not compatible with call state.This cause indicates that a message has been received which is incompatible with the call state.Cause No. 102 – recovery on timer expiry.This cause indicates that a procedure has been initiated by the expiration of a timer in association with error handling procedures.What it means:This is seen in situations where ACO (Alternate Call Offering) is being used. With this type of call pre-emption, the Telco switch operates a timer. For example, when an analog call is placed to a Netopia router that has two B Data Channels in place, the router relinquishes the second channel, but if it doesn’t happen in the time allotted by the switch programming, the call will not ring through and will be discarded by the switch.Cause No. 103 – parameter non-existent or not implemented – passed on (national use).This cause indicates that the equipment sending this cause has received a message which includes parameters not recognized because the parameters are not defined or are defined but not implemented by the equipment sending this cause. The cause indicates that the parameter(s) were ignored. In addition, if the equipment sending this cause is an intermediate point, then this cause indicates that the parameter(s) were passed unchanged.Cause No. 110 – message with unrecognized parameter discarded.This cause indicates that the equipment sending this cause has discarded a received message which includes a parameter that is not recognized.Cause No. 111 – protocol error, unspecified.This cause is used to report a protocol error event only when no other cause in the protocol error class applies.Cause No. 127 – Intel-working, unspecified.This cause indicates that an interworking call (usually a call to 5W56 service) has ended.Notes about Cause Codes over 128Cause code values of 128 and higher aren’t sent over the network. A terminal displaying a value 128 or higher and claiming it is a cause code arguably has a bug or is implementing some proprietary diagnostic code (not necessarily bad). Some commendation has cause codes listed with numbers higher than 128, but at this time they are proprietary in nature.The PRI equipment vendors are the most likely to use these codes as they have been using proprietary messages in the facilities data link

for some time now (there is an as yet undefined area in the FDL which is big enough to carry small datagrams or messages). It is typically used to pass proprietary control or maintenance messages between multiplexers.

Documents

CME Topics