CME-Topic 1: CME Overview Introduction Cisco 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 an d 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 CME Lower 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 Operation The CME system provides PBX-like features and functions for IP phones. These features are the result of a cen tralized 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 Features Cisco CME encompasses the following features Basic 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 Components Cisco IPC Express includes the following features Call processing software (Cisco CME) IP Communications platform IP-based applications

IP-based endpoints IP Based Applications Several 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 Express Cisco 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 Unity Cisco 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 CUCM You 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 Licenses IOS License Feature License Phone User License Getting Necessary Files Basic Files A 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 Files A 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 Files The file called x ml.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 Files An 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 Files Archives containing Tcl script files are listed individually on the Cisco Unified CME software download website. For example, the file named app -h450transfer.2.0.0.9.zip.tar contains a script that adds H.450 transfer and forwarding support for analog FXS ports. Misc. Files These Misc. files includes Phone Firmware, Bundle TSP Achieve etc

CME Installation Get necessary files from the Cisco websites Place 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.com Step 2: Copy these files to TFTP server root directory Step 3: Use the following commands to copy source files to the router flash memory If the file is an individual file, use copy command Router#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 memory Router#archive tar /xtract source-url flash:/file-url Router#archive tar /xtract tftp://192.168.245.1/cme -full-7.0.0.0.tar flash:/ Step 4: Verify the installation using show flash: command Router# 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 P00307020 300.sb2 34 129400 Sep 19 2005 12:19:04 -07:00 P00307020300.sbn

CME-Topic 3: Basic Configuration Step 1: Configure Telephony Service Parameters To 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 mode MAX-DN MAX-EPHONES IP SOURCE-ADDRESS gw1(config)#telephony-service gw1(config-telephony)#max-dn 32 gw1(config-telephony)#max-ephones 10 gw1(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 immediately gw1(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 Numbers When 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-dntag command. Use a tag of 1 for the first phon e. 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 5001 gw1(config-ephone-dn)#name Phone1 Step 3: Create Phones Before configuring the phones on the router, you will ne ed 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 1 gw1(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 us ing 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 information This 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 commands gw1#show flash gw1#dir flash: To publish files via TFTP please use the following command for every file from the specific phone directory gw1(config)# tftp-server flash:/phone/79407960/P00308000500.bin alias P00308000500.bin gw1(config)# tftp-server flash:/phone/79407960/P00308000500.loads alias P00308000500.loads gw1(config)# tftp-server flash:/phone/79407960/P00308000500.sb2 alias P00308000500.sb2 gw1(config)# tftp-server flash:/phone/79407960/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 file gw1(config-telephony)#load 7960-7940 P00308000500 The last command for this series will be gw1(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 Models PBX System Key System Hybrid Model PBX System Digital 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-config ephone-dn 4 dual-line number 1001 name Boss ephone-dn 5 dual-line number 1002 name Assistant ephone 7 mac-address 000d.aa45.3f6e button 1:4 ephone 8 mac-address 000d.bb46.2e5a button 1:5 2:4 In 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 Key Switch One 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-config ephone-dn 1 number 4085550101 nohuntstop 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 Hybrid Model This 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-tomany mapping. PBX and keyswitch configurations can be mixed on the same IP phone and can include both uniqu e per-phone extensions for PBX-style calling and shared lines for keyswitch-style call operations.

router#show running-config ephone-dn 1 number 4085550101 nohuntstop 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 Steps Enable HTTP Server Specify Path for GUI files Enable Authentication Configure GUI access users Allow edit access from GUI Step 1: Enable HTTP Server For GUI to work we need web server running, so use the following command to enable HTTP server CME(config)#ip http server

Step 2: Specify path for GUI files After 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 path CME(config)#ip http path flash:/gui/ Step 3: Enable Authentication Now let s configure authentication method for user access. The following is quick review of available options aaa 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 local Step 4: Configure GUI access users As i used local authentication method for user validation, so i have to configure users for admin and end users to access GUI CME(config)#telephony-service CME(config-telephony)#web admin system name admin password admin CME(config-telephony)#web admin customer name user password user Step 5: Allow edit access from GUI We have to add capability to the GUI for users to edit phones and other settings using the following command CME(config-telephony)#dn-webedit CME(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 -ipaddress/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#showip http server status CME#showip 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 a uto-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 command CME(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 se e which phones attempted registration with CME using below command CME#showephone attempted-registration With auto-registration enabled you can configure auto -assignment of ephonedn to the phones when they try to register with CME for any type of phone CME(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 mentione d series of commands CME(config)#telephony-service setup 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]: no If you already have DHCP on you LAN then enter no for this Do you want to start telephony-service setup? [yes/no]: yes Configuring Cisco IOS Telephony Services : Enter the IP source address for Cisco IOS Telephony Services :192.168.245.2 Enter the Skinny Port for Cisco IOS Telephony Services : [2000]: How many IP phones do you want to configure : [0]: 10 Do you want dual-line extensions assigned to phones? [yes/n o]: yes What 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 se rvice: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 up CNF-FILES: Clock is not set or synchronized, retaining old versionStamps CNF files update complete (post init) Verification

After setup is completed, you can verify auto configuration using CME#show run Now you can register you phone with CME and then can verify using below commands CME#showephone 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 Primary telephony-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 createcnf-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 createcnf-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

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 shephone sum hairpin_block: ephone-1 Mac:0024.8141.7C73 TCP socket:[ -1] activeLine:0 DECEASED 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:1 Max 10, Registered 0, Unregistered 0, Deceased 1, Sockets 0 ephone_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 shut CME1(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 character s. 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/1 dial-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
y

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 4 number 1001 name John Smith preference 1 This ephone-dn command generates the configuration sub -elements dial-peer voice 20004 pots destination-pattern 1001 preference 1 huntstop port 50/0/4 voice-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 se e 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 options under softkey template section

y

following

are

the

available

alertingSoftkey order for alerting (ring out) state o Acct Account Code o CallBack Call back o Endcall End call connectedSoftkey order for connected state o Acct Account Code o ConfList List all participants in conference o Confrn Conference o Endcall End call o Flash Hook Flash o HLogHLog o HoldHold o JoinJoin established call to conference o Park Call Park o RmLstC Remove last conference participant o SelectSelect call to join in conference o Trnsfer Call Transfer holdSoftkey order for HOLD state o Join Join established call to conference o Newcall New call o ResumeResume o SelectSelect call to join in conference idleSoftkey order for IDLE state

Cfwdall = Call Forward All ConfList = List all participants in conference Dnd = Do not Disturb Gpickup = Group Call Pick Up Hlog = Used to login and logout from hunt groups Join = Join established call to conference Login = Login Newcall = New call (if your are already in one) Pickup = Call Pick Up Redial = Redial last number RmLstC = Remove last conference participant ringingSoftkey order for ringing state o AnswerAnswer o Dnd Do not Disturb o HLogHLog seizedSoftkey order for seized state o CallBack Call back o Cfwdall Call forward all o Endcall End call o GpickupGroup Call Pick Up o HLogHLog o MeetMeMeetMe Conference o Pickup Call Pick Up o RedialRedial
o o o o o o o o o o o

Step 1: Configure Softkey Template For the simplicity of this illustration we will configure template only for idle state CME1#configure terminal CME1(config)#ephone-template 20 CME1(config-ephone-template)#softkeys idle CfwdallGpickup Login Redial Step 2: Assign Softkey Template to ephone CME1#configure terminal CME1(config)#ephone 1 CME1(config-ephone)#ephone-template 20 CME1(config-ephone)#restart After restart the phone should look like this

CME-Topic 12: Codec Configuration February 1st, 2011 | Author: Shafqut Hamid 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 terminal CME1(config)#ephone-template 20 CME1(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 bandwidth CME1(config-ephone-template)#codec g711ulaw After configuring ephone -template we have to apply it to each ephone CME1#configure terminal CME1(config)#ephone 1 CME1(config-ephone)#ephone-template 20 CME1(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 terminal CME1(config)#ephone 1 CME1(config-ephone)#codec g711ulaw CME1(config-ephone)#restart

CME-Topic 13: ephone-dn Secondary Number February 1st, 2011 | Author: Shafqut Hamid 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 nohuntstop preference 1 secondary 2 ephone-dn 5 number 1007 secondary 1001 name Jane Smith preference 1 secondary 2 nohuntstop 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
y

y y

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 nohuntstop ephone-dn 2 dual-line number 1001 preference 1 huntstop channel ephone 1 button 1:1 ephone 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 huntstopconfiguration

CME-Topic 15: Overlay DN February 15th, 2011 | Author: Shafqut Hamid 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 1 ephone-dn 2 number 1002 name Phone 2 ephone 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
y y y

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 1 ephone-dn 2 number 1002 name Phone 2 ephone 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 di splay 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 servicednis overlay

CME-Topic 16: Hunt Group Configuration February 15th, 2011 | Author: Shafqut Hamid 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:
y

Sequential modeThis 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 modeThis 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 infinit e 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 idleThis 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:
y y

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 ephonehunt 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 February 16th, 2011 | Author: Shafqut Hamid 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 servicednisdir-lookup directory entry 1 5550500 name Shafqut Hamid directory entry 2 5550501 name Sh amid

CME-Topic 18: Call Forwarding Configuration February 16th, 2011 | Author: Shafqut Hamid 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 nameShafqut Hamid call-forward busy 1007 call-forwardnoan 1007 timeout 20 ephone-dn 5 dual-line number 1007 nameShamid call-forward busy 1001 call-forwardnoan 1001 timeout 20 There s an issue with this configuration, because it potentially creates an in finite 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 ephonedn. 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 nameShafqut Hamid call-forward max-length 4 call-forward busy 1001 call-forwardnoan 1001 timeout 20

CME-Topic 19: Call Transfer February 16th, 2011 | Author: Shafqut Hamid We have to look into call transfer in two prospective
y y

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

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 February 16th, 2011 | Author: Shafqut Hamid 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.
y y y y

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 p ark 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
y y y

reserved-for <DN> timeout <seconds> limit <count>

y y y y y y

notify <dn> only recall transfer <dn> alternate <dn> retry <seconds>

CME(config)# ephone-dn 50 CME(config-ephone-dn)# number 3001 CME(config-ephone-dn)# name Maintenance CME(config-ephone-dn)# park-slot CME(config-ephone-dn)# exit CME(config)# ephone-dn 51 CME(config-ephone-dn)# number 3002 CME(config-ephone-dn)# name Sales CME(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) befo re 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 th e call is disconnected CME(config-ephone-dn)# park-slot timeout 60 limit 10 ? notify Define additional extension number to notify for park timeout recallrecall transfer back to originator phone after timeout transfer 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 busy retry 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 February 16th, 2011 | Author: Shafqut Hamid
y y

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 1 CME(config-ephone-dn)# pickup-group CME(config-ephone-dn)# ephone-dn 2 CME(config-ephone-dn)# pickup-group CME(config-ephone-dn)# ephone-dn 3 CME(config-ephone-dn)# pickup-group CME(config-ephone-dn)# ephone-dn 4 CME(config-ephone-dn)# pickup-group CME(config-ephone-dn)# ephone-dn 5 CME(config-ephone-dn)# pickup-group CME(config-ephone-dn)# ephone-dn 6 CME(config-ephone-dn)# pickup-group

5509 5509 5509 5510 5510 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
y y

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 February 17th, 2011 | Author: Shafqut Hamid 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 pho nes. CME(config)# ephone-dn 11 CME(config-ephone-dn)# number A100 CME(config-ephone-dn)# intercom A101 label Manager CME(config-ephone-dn)# exit CME(config)# ephone-dn 22 CME(config-ephone-dn)# number A101 CME(config-ephone-dn)# intercom A100 label Assistant CME(config-ephone-dn)# exit CME(config)# ephone 2 CME(config-ephone)# button 2:11 CME(config-ephone)# restart CME(config-ephone)# exit CME(config)# ephone 2 CME(config-ephone)# button 2:22 CME(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 February 17th, 2011 | Author: Shafqut Hamid
y y y y y

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 80 CME(config-ephone-dn)#number 5555 CME(config-ephone-dn)#paging CME(config-ephone-dn)#exit CME(config)#ephone 1 CME(config-ephone)#paging-dn 80 CME(config-ephone)#exit CME(config)#ephone 2 CME(config-ephone)#paging-dn 80 CME(config-ephone)#exit You can use nested configuration to use multiple paging group in a single group CME(config)#ephone-dn 81 CME(config-ephone-dn)#number 6666 CME(config-ephone-dn)#paging CME(config-ephone-dn)#paging group 80,81 CME(config-ephone)#exit CME(config)#ephone 2 CME(config-ephone)#paging-dn 80 CME(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 February 17th, 2011 | Author: Shafqut Hamid
y y y y

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 CME(config-telephony)# after-hours CME(config-telephony)# after-hours CME(config-telephony)# after-hours CME(config-telephony)# after-hours CME(config-telephony)# after-hours CME(config)# telephony-service date dec 25 00:00 00:00 day fri 17:00 8:00 day thu 17:00 8:00 day wed 17:00 8:00 day tue 17:00 8:00 day mon 17:00 8:00

CME(config-telephony)# after-hours block pattern 1 91.......... CME(config-telephony)# after-hours block pattern 2 9011T CME(config-telephony)# exit CME(config)#ephone 1 CME(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:00 CME(config-telephony)# exit CME(config)#ephone 2 CME(config-ephone)# pin 1234 CME(config-ephone)# restart

CME-Topic 25: Automatic Line Selection February 17th, 2011 | Author: Shafqut Hamid 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:
y

Automatic line selectionPicking 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 February 17th, 2011 | Author: Shafqut Hamid 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 re assure 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
y y

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 m edia streams when they are placed on hold. Following precedence rules are applicable when an ephone caller is placed on hold:
y y y y y

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-group telephony-service moh alaska.wav Moh multicast 239.1.1.1 port 16384 route 10.1.4.31 10.1.1.2 voicemoh-group 1 description this moh group is for sales moh flash:/hello.au multicastmoh 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 voicemoh-group 2 description (not configured) moh flash1:/minuet.au multicastmoh 239.23.4.10 port 2000 extension-range 7000 to 7999

ISDN Cause Codes January 21st, 2011 | Author: Shafqut Hamid Cause No. 0 This 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 com plete 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 password 2. 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 th e 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 equ ipment 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 appropriat e 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 networ k 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 t he 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 h igh 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 di agnostic. 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 ot her 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 de lay 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 altho ugh 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 barred Cause 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 wh ich 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 th e 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 p arty 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 C UG 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.931 Cause 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 sen ding 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 elemen t(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 i nitiated 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 128 Cause 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 d iagnostic 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 .