Archive for the ‘Features’ Category

I was looking into this customer issue where they upgraded from Call manager 4.x to 7.x and almost all users on 7912 phone lost their speed dials.

I checked the phones and CCMUSER page and found that the dials where there but they are not able to access it.

Created a new Softkey template including “AbbrDial” at “off Hook” mode. Reset the phones and asked them to check.

Customer came back saying they cannot see “AbbrDial” Softkey. All settings in Call manager were fine but for some reason they were not able to see the Abbreviated Dial Softkey.

I checked the firmware for 7912 and it was CP7912080003SCCP070409A.

I decided to upgrade the firmware for 7912 to the latest one CP7912080004SCCP080108A. I loaded the new firmware, restarted TFTP, reset the phones and it all started working fine.

Later I came to know that it’s a kind of a bug that if you upgrade from CCM 4.x to 7.x then your 7912 phones will have issues in AbbrDial Softkey. If you come across this issue, upgrade the firmware and you will be good.

CME Paging

Posted: May 14, 2012 in CallManager Express (CME), Features

A paging number can be defined to relay audio pages to a group of designated phones. When a caller dials the paging number (ephone-dn), each idle IP phone that has been configured with the paging number automatically answers using its speakerphone mode. Displays on the phones that answer the page show the caller ID that has been set using the name command under the paging ephone-dn. When the caller finishes speaking the message and hangs up, the phones are returned to their idle states.


Ephone-dn 22  will be paging DN – the number you dial to broadcast – in this case dial “5001” and it will ring all ephones part of this paging group and they will go on speakerphone.

ephone-dn 22
name Paging Shipping
number 5001
paging ip port 2000

These are paging group members, so dialling 5001 will ring these four numbers:

ephone 4
mac-address 0030.94c3.1111
button 1:1 2:2
paging-dn 22 multicast

ephone 8
mac-address 0030.94c3.0bcf
button 1:2
paging-dn 22 multicast

ephone 12
mac-address 0030.94c3.8567
button 1:3
paging-dn 22 multicast

ephone 13
mac-address 0030.94c3.8724
button 1:4
paging-dn 22 multicast

You can also use groups for Paging:

ephone-dn 9
number 7001
name Sales
paging ip port 2000
ephone-dn 11
number 7002
name Accounts
paging ip port 2000
ephone-dn 17
number 7010
name Sales&Acccounts
paging ip port 2000
paging group 9,11

These are the steps involved (considering Call manager Linux versions):

1 – Configure extension mobility service by going into Device > Device settings > Phone Services

The service URL is : http://call-manager-IP:8080/emapp/EMAppServlet?device=#DEVICENAME#

If you want to set it up as an Enterprise service then check that box “Enterprise Subscription” otherwise leave it. If you check that box, extension mobility service will appear globally for all phones and you won’t be able to find this service under phone Subscribe services in Step 2. If you don’t check that box then move to step 2

2 – Under phone, susbcribe this service as follows by dropping down the menu at top right corner and then going into “Subscribe/Unsubscribe Service”

3- Staying on the same phone page, scroll down and check the extension mobility check box otherwise no one will be able to login:

4 – Create a User device profile Device > Device Settings > Device profile. Any higher generation phone profile will work on lower one but that’s not true the other way around. So a Cisco 7960 device profile can be used to login oo a 7912 phone but a Cisco 7912 UDP won’t login on a Cisco 7960 phone.

5 – After creating UDP, the most important and sometimes missed step is to subscribe the Extension mobility service again like step 2 at UDP level

6 – Go into user from from User management > End user and add that device profile to it. Also select the primary extension at that user page.

Login and you should be good to go. Any issues, it would either be related to service not subscribed at UDP level or a UDP not associated with a user.

Web Link for EM:

There can be a situation where your Pub is down or inaccessible and users wants to login or logout. As EM service is dependent on Publisher they won’t be able to login/logout and will get “host not found”.

There is a workaround where users can login to their phones through a web link.

To login using URL:

http://<CUCM-SUB IP Address>/emapp/EMAppServlet?device=MACADDR&userid=USERID&seq=XXXXX



To logout the user:

http://&lt; CUCM-SUB IP Address>/emapp/EMAppServlet?device=SEP001646D97913&doLogout=true

I had an interesting case where SIP calls over a SIP trunk were dropping after like 75 minutes. The duration was not confirmed as sometimes it use to drop even before 75 minutes.

I looked into few CCSIP debugs (debug ccsip messages) and found that the ‘BYE’ message was actually coming from our end (Call manager/Gateway).

Platform information:

CCM: System version:

CUBE-10#sh ver

Cisco IOS Software, 3800 Software (C3825-ADVIPSERVICESK9-M), Version 12.4(24)T4, RELEASE SOFTWARE (fc2)

Technical Support:
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Fri 03-Sep-10 09:15 by prod_rel_team

ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)

CUBE-10 uptime is 27 weeks, 3 days, 44 minutes

voice-card 0
voice call send-alert
voice rtp send-recv
voice service voip
allow-connections sip to sip
fax protocol cisco
options-ping 180
voice class codec 1
codec preference 1 g729r8
codec preference 2 g711alaw


voice class sip-profiles 1
request INVITE sip-header Allow-Header modify “, UPDATE” “”


dial-peer voice 10 voip
description *** Outbound to GXXX – SIP Provider ***
translation-profile outgoing OUTBOUND
destination-pattern 9T
voice-class codec 1
voice-class sip early-offer forced
voice-class sip profiles 1
session protocol sipv2
session target ipv4:
dtmf-relay rtp-nte
fax-relay sg3-to-g3
no vad


timer receive-rtp 1200

retry invite 1
retry response 2
retry bye 2
retry cancel 1
retry options 1
timers trying 200



Debug Output:

Jul 11 12:17:54.579 BST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:


BYE sip:079XXXXXXX@ SIP/2.0

Via: SIP/2.0/UDP;branch=z9hG4bK100B17D
From: “anonymous” <sip:anonymous@>;tag=B891B2E8-282
To: <sip:079XXXXXXX@>;tag=3519367399-656588
Date: Mon, 11 Jul 2011 11:15:27 GMT
Call-ID: D687F817-AADB11E0-A725957A-CA524E0B@
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1310383074
CSeq: 128 BYE
Reason: Q.850;cause=16
Content-Length: 0

Jul 11 12:17:54.591 BST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

SIP/2.0 200 OK

Via: SIP/2.0/UDP;branch=z9hG4bK100B17D
To: <sip:079XXXXXXX@>;tag=3519367399-656588
From: “anonymous” <sip:anonymous@>;tag=B891B2E8-282
Call-ID: D687F817-AADB11E0-A725957A-CA524E0B@
CSeq: 128 BYE


Contact: <sip:079XXXXXXX@>


= = = =

This is what I have done to fix the problem:

I added these commands under sip-profile:

voice class sip-profiles 1
request INVITE sip-header Allow-Header modify “UPDATE,” “”      < < <  This was already there
request REINVITE sip-header Allow-Header modify ” UPDATE,” “”
response 200 sip-header Allow-Header modify “UPDATE,” “”
response 180 sip-header Allow-Header modify “UPDATE,” “”

The next step was to increase the Service Parameter “SIP Session Expire Timer” which you can find under Service Parameters > Call manager:

That was it, it fixed the issue and customer confirmed having a call for more than 3 hours.

An intercom line is one of those ‘must-have’ functions that must be available on every PBX. Fortunately, CUCM does have this function, but on the other hand, the documentation explaining how the feature works and its related configuration is not so accurate. Anyway, here’s my attempt at configuring this simple, but very handy feature in CUCM 6.x – 8.x:

Before I begin, I want to mention that an intercom line is represented by a Directory Number (DN) as is the case with any dial-able entity. Now that we have that out of the way, the first thing one needs to understand is how an intercom line works. Simply put, a user (generally a manager) presses an intercom line button on their phone and it dials the intercom line on other user’s (generally an assistant) phone and the call is auto-answered at this user’s end. However, the second user can only listen to the first user’s voice, but their own phone is muted by default. The general idea behind the intercom line is for a manager to speed-dial into a second user’s phone and have it auto-answer at the receiving end in muted mode. This allows the manager to deliver a quick, one-way audio message to the assistant. If the assistant wishes to respond back to the manager, they can hit the intercom line button on their phone and initiate a two-way conversation;  just like a normal phone call.

The intercom line is an additional line on an IP phone that is configured to reach another intercom line on another IP phone. Intercom lines are configured with “Intercom Partitions” and “Intercom Calling Search Spaces” and therefore only intercom lines can reach other intercom lines. When a user presses the intercom line on their IP phone, they can manually (or configure it to automatically) dial the corresponding intercom line on the other IP phone. Generally, a Manager will have an intercom line to their Assistant’s phone, which will be the scenario for our example.

The setup:

A manager would like to have an intercom line to their assistant such that they would simply need to press the line button and have the assistant’s phone auto-answer (in muted mode). The intercom should not work in reverse, that is, the assistant should not be able to speed-dial the manager’s intercom line.

The configuration:

– Create two ‘Intercom partitions’ for the Manager and the Assistant’s intercom DNs by navigating to Call Routing -> Intercom -> Intercom Route Partition. Title the partitions something along the lines of “PT-INTERCOM-MANAGER” and “PT-INTERCOM-ASSISTANT”.

– Create two ‘Intercom CSSs’ for the Manager and the Assistant’s intercom DNs by navigating to Call Routing -> Intercom -> Intercom Calling Search Space. Title the CSSs something along the lines of “CSS-INTERCOM-MANAGER” and “CSS-INTERCOM-ASSISTANT”. Configure the Manager CSS to contain the Assistant’s Intercom partition (PT-INTERCOM-ASSISTANT) so that the Manager’s Intercom CSS will having dialing access to the Assistant’s intercom DN. The Assistants Intercom CSS will also contain the Assistant’s intercom partition only because the CSS cannot be left empty.

You’re probably wondering why we need to set up a CSS for the assistant since they won’t need any dialing privileges on their intercom line, however, both intercom partition and intercom CSSs are mandatory configuration entities for any intercom line regardless of the requirement. Go figure!

– Create an ‘Intercom Directory Number’ for the manager’s phone by navigating to Call Routing -> Intercom -> Intercom Directory Number as show in Figure 1. We will configure 3000 as the Manager’s Intercom DN.

Figure 1 – Intercom Directory Number Configuration for Manager

– Create a second ‘Intercom Directory Number’ for the assistant’s phone as show in Figure 2. We will configure 3001 as the Manager’s Intercom DN.

Figure 2 – Intercom Directory Number Configuration for Assistant

– Add an intercom line to the Manager’s phone by navigating to Device ->Phone and then selecting the phone to which the intercom line will be added. Click on the “Modify Button Items” button as show in figure 3. A small window may pop-up that reads: “Unsaved Changes may be lost! Continue?”. Click on OK and the “Reorder Phone Button Configuration” window will pop-up.

Figure 3 – “Modify Button Items” under the Phone Configuration window

– Highlight the ‘Intercom [1] – Add a new intercom’ option under the “Unassigned Associated Items” box on the right side of the window and press the “<” button to move the intercom line into the left box (Associated Items). Rearrange this option and place it in the line position where it will appear on the phone as shown in Figures 4 and 5. Note: The number of options in the left box must correspond to the number of lines on the phone. Hence, one of the unused lines may have to be moved over into the right box before the intercom option can be moved here. If this hasn’t been done and the user attempts to add an intercom line to the left box, the following error will be received: “Must Remove An Item From Associated List Before This Operation is Allowed”.

Figure 4 – Reorder Phone Button Configuration window Step 1

Figure 5 – Reorder Phone Button Configuration window Step 2

– Click on “Save” and then “Close”.

– Under the second line (where the intercom was configured) will now read: “Intercom [1] – Add a new Intercom”. Click on this link and on the next page enter the DN (3000 in our example) in the ‘Intercom Directory Number’ field and hit “tab”. The remaining fields will be automatically pulled from the Intercom Directory Number settings configured earlier as illustrated in Figure 6.

– The following fields may be entered if desired (Shown in Figure 6):

Display (Internal Caller ID)

ASCII Display (Internal Caller ID)

Line Text Label

ASCII Line Text Label

Figure 6 – Intercom Directory Configuration Window

– The “Speed Dial” field will set the intercom to dial this number (3001 in our example) as soon as the Intercom line button on the IP phone is pressed. This is illustrated in Figures 7 and 8.

Figure 7 – Normal State

Figure 8 – After Pressing the “Intercom Line”

Please feel free to post any questions or comments. I hope this post was helpful!


One of the concepts that many junior voice engineers struggle with is the class of control features of Partitions and Calling Search Spaces. I remember feeling like I was banging my head against a wall repeatedly until I hit that Ah-hah moment and it all made sense.

Now there are many great explanations out there on the inter webs that are all technically correct and great. Some use the Lock + Key analogy like the CIPT1 Study guide and some use a White Pages/Directory Analogy. In my opinion these can leave people without a whole lot of voice experience more confused than when they started.

Purpose – What are Partitions and Calling Search Spaces used for anyway?

In my opinion Partitions and Calling Search Spaces are primarily used as a way to find “things” in the phone system. They are used so endpoints (Phones, Gateways, Trunks) can dial resources (Directory Numbers, On-net Route Patterns, Off-net Route Patterns, Translation Patterns). From an end-users perspective these resources are generally represented by a number. Because you can use these Dial Plan constructs to limit what resources an endpoint can find, it allows you the ability to implement Class of Service.

Sure, you could just put everything in the none partition and be done with it all together but Tom Hollingsworth has already told us why this is a bad idea over at his blog

Yeah, Ok. But you still haven’t told me what Partitions and Calling Search Spaces do!

Hold your horses. This is the part you’ve all been waiting for….< Insert Drum Roll > Here it is:

  • Partitions contain “things”
  • Calling Search Spaces find “things”

That’s it. I really believe this is the simplest way to think of how these two constructs work and behave.


So we know that partitions can contain “things” but what exactly can they contain? A partition will only contain one or more of the following things:

  • Directory Numbers – These Directory Numbers represent other numbers in the Phone System that can be associated to Devices.
  • Route Patterns – Route Patterns represent off-net and on-net destinations and control how a call is routed to a destination. Route Patterns use Route Lists and Route Groups to send calls over a trunk or a gateway.
  • Translation Patterns –  I consider Translations Patterns an intermediate step to either matching a Directory Number or a Route Pattern. They are used to Transform the Calling or Called Party Information before using a Calling Search Space to find a suitable match. It is also worth noting that a Translation Patten can also be set to Block instead of route which can be useful when using the Line/Device Approach for implementing Class of Service
  • Transformation Patterns – Transformation Patterns are similar to Translation Patterns except they are not part of the CUCM’s routing construct. They are used for modifying Calling or Called Party Information for purposes of presentation but do not affect call routing. When you are using Transformation Patterns you should use dedicated Partitions and Calling Search Spaces for this function.

Calling Search Spaces

So if partitions contain “things” and Calling Search Spaces find “things”, what do they look in too find them? Well they look in partitions of course.

The following constructs use Calling Search Spaces to find things:

  • Devices – Phones use a CSS to find available patterns. This is generally referred to as the Device Calling Search Space
  • Directory Numbers – Directory Numbers also use a CSS to find available patterns. This is referred to as the Line Calling Search Space.
  • Trunks
  • Gateways
  •  Translation Patterns

This list was by no means exhaustive and there is a vast number of features that require Calling Search Spaces to be defined to control access to DN’s/Patterns for that feature. Things like Time of Day Routing, Presence, Call Forward Settings etc

When a Calling Search Space is looking through a series of ordered partitions it doesn’t work like an ACL in Cisco IOS that searches sequentially through the available partitions top-down until it finds a suitable match. No, It processes all listed partitions and matches on the best or longest match. The only time in which the order of the partitions matter is when you have equally specific patterns, in which the pattern in the partition closer to the top of the CSS list will win as a tie-breaker.

OK – So I think I get it, but I’ve noticed my Phone and my Directory Number both have a CSS. What’s up with that?

Well CUCM is flexible in that you could choose to set a CSS on just one of these elements and leave the other blank.  When you have both a Device and a Line CSS the CUCM combines the two into a single CSS with Line CSS above the Device CSS.

There is a good reason to use both. In order to effectively use features like extension mobility but enforce local dialling habits at remote offices it is recommended to set the Device CSS as too allow full access to the Dial Plan and then use the Line CSS to restrict unauthorised patterns from being dialled. The Partitions in your Line CSS should contain Translation Patterns that are set to block the restricted patterns and also have the “Urgent Priority” flag checked (It is on by default).


To setup attendant console

a. Create pilot point say ACPilot with number specified, Select algorithm as Longest idle or First available

b. Create hunt group with specified members (directory numbers).

c. Create ac user and associate pilot point with ac user. ac user default password is 12345. pin = 12345.
To change ac user password from default to cisco (say), use c:\dcdsvr\bin\Passwordutils.exe  cisco (Run the above command from that folder in command line. Copy the encrypted password text you get as output.

d.  Open c:\program files\Cisco\CallmanagerAttendant\bin\ file and change the following

# Propery file that server uses.

#Jtapi Username

#Jtapi Password

e. To change hunt mechanism to Circular,

In file, change the following.
# Specify comma seperated pilot point device names for which
# circular hunting algorithm is used. This will override
# what is configured in the admin pages.
e. Restart TCD service.