Archive for the ‘Cisco CallManager’ Category

Wow, am I old or is Cisco moving at about 3 revisions a year? I think the first was correct.. Oh well. I have a huge 8.x project coming up for a client and so I have been installing a lab version to play around with. Last night I tried to MAP my lab UC appliance from a Windows machine, then I remember that this changed as of CCM 5.x….

So I’m sure you remember the “good old days” of CCM 4.x? You can do almost everything on the box. Because it’s in fact a Windows 2000 box. However, this brings security and supportability issues.

With the introduction of Linux-based Unified Communication appliance (CUCM 5.x – 8.x), Cisco locked down the box. You can only access the box via admin web page or a tailored command line.

One of the inconveniences is to review log files. On the old-school CCM 4.x, you may just view the logs in C:\Program Files\Cisco\Trace. On the new UC appliance, you’ll have to use RTMT (RealTime Monitoring Tool). This is especially annoying if you’re testing your system. For each test, you’ll have to download a new set of logs to your computer. (though you may use ‘Remote Browse’ in RTMT, its function is very limited)

What if we can go back to the “good old days” and view the file system just like a Windows drive? I think I discovered a way to do it on a forum site.

Take a look at the screenshot below. It’s a CUCM 6.1.4 mapped to my Windows XP laptop. You can read/write files on CUCM just like a local hard drive. For those people who are not a fan of VI, you may use your favorite editor (such as Notepad++/UltraEdit). And you may use any Windows tools, such as Windows search, WinGrep, WinZip, etc. How’s that? 🙂

To achieve this, you need two things: a root account on CUCM and a software who can map a SFTP server to a network drive (such as sFTPdrive).

 BAM issue solved. In closing I must admit, I was one of the Cisco CCVP’s at Cisco Live asking developers WHEN ARE YOU GOING TO STOP USING WINDOWS? – Soon my friend, soon.. So I would trade this inconvenience any day to keep from having to deal with Microsoft.

Modify Cisco License MAC

Posted: May 24, 2012 in Cisco CallManager, CUCM
Tags: , , ,

Cisco used to bind license file to physical MAC address.  Now, it moves to “License MAC”, which is a hash value of multiple system parameters such as NIC speed, NTP, DNS, hostname, etc.

To view the license MAC, you need to install the system first (CUCM, UCCX, CUPS, etc.).  Then use the “show status” command.

This is somehow inconvenient:

1) You cannot get the license file before finishing the installation.

I personally prefer to get everything ready before starting the installation, such as IP address, hostname, password, license file, installation media, etc.  You could run into lots of surprises when trying to get the license file.

2) When the system parameter was changed, the license file yield invalid.

For example, you add/change DNS server settings on the system, which is pretty common during system integration.

It would be better if you could dictate what license MAC the system use.  You may also use some schema like: AABBCCDDEEFF, where AA is the product code, BB is the site code, CC is the node number, DD is the version number, etc.

In the example above, the “License MAC” was changed to “abcdef123456”.

Since you can use whatever License MAC you like, you may:

  • Get the license file before the system was installed
  • Keep using the same license file after system parameters was changed (such as DNS)

To specify the license MAC, you need to have root access to the system.  Then you’ll modify the file /usr/local/bin/base_scripts/  To the bottom of the file, replace the line

FinalString=`expr substr “$SHA1sum” 1 12`



In newer versions, you might have to change the /etc/selinux/config file so that selinux runs in permissive mode.
Reminder: Don’t be evil.  😉 – and be sure to pay it forward!!!
(R) 2012

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.

I had an interesting scenario where customer logged a case with us regarding their RightFax server not working. Those of you who don’t know what is a RightFax server can read about it here. When you dial the fax number from outside, it reaches the gateway and you hear one ringback and then a fast busy. The call flow was something like this:

0XXXX23422 >>>> Birmingham GW  FXO >>> on CCM we have FXO port with number 3422 >> on CCM there was a RP 3422 with a RL pointing towards an Intercluster trunk to The was the Right Fax server.

I could ping which proved no issues between CCM and Right fax server.

I then opened debug voip ccapi inout and observed the Ringback and fast busy tone which was not very helpful. I then asked the customer if fax calls through any other gateway are working and luckily I found one gateway where they had successful fax calls. I compared the MGCP config on both gateways and found one line missing from this gateway which was not working.

The MGCP commands common to both:
ccm-manager fallback-mgcp
ccm-manager redundant-host BELL
ccm-manager mgcp
no ccm-manager fax protocol cisco
ccm-manager music-on-hold
ccm-manager config server
ccm-manager config


mgcp call-agent MICKEY 2427 service-type mgcp version 0.1
mgcp rtp unreachable timeout 1000 action notify
mgcp modem passthrough voip mode nse
mgcp package-capability rtp-package
mgcp package-capability sst-package
mgcp package-capability pre-package
no mgcp package-capability res-package
no mgcp timer receive-rtcp
mgcp sdp simple
mgcp fax t38 ecm
mgcp bind control source-interface FastEthernet0/0
mgcp bind media source-interface FastEthernet0/0

mgcp profile default!

The command which was missing was this:

mgcp rtp payload-type g726r16 static
I added that command and Fax started working.

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

QoS is very important for Voice traffic which is delay sensitive. I won’t go into details of QoS over here and will just explain the configuration we normally use on a Voice gateway for QoS.

class-map match-any Voice-RTP
match ip precedence 5
match ip dscp ef
match ip rtp 16384 16383
class-map match-any Voice-Cntl
match ip precedence 3
match ip dscp af31
match access-group name voice-signal
ip access-list extended voice-signal
permit tcp any any range 2000 2002
permit udp any any eq 2427
permit tcp any any eq 2428
permit tcp any any eq 1720
permit tcp any any range 11000 11999
policy-map QoS-LAN-Policy
class Voice-RTP
set dscp ef
priority 500
class Voice-Cntl
set dscp af31
bandwidth 30
class class-default

Apply it on Voice VLAN interface or towards the WAN interface if you are configuring it between sites:

interface FastEthernet0/1
ip address
ip rip advertise 2
ip virtual-reassembly
ip tcp adjust-mss 1360
duplex full
speed 100
service-policy output QoS-LAN-Policy


interface GigabitEthernet0/0.105
description *** Voice VLAN ***
encapsulation dot1Q 105
ip address 10.60.x.x
h323-gateway voip bind srcaddr 10.60.x.x
service-policy output QoS-LAN-Policy


Confirmation that the voice packets are hitting the service policy:

GW#sh policy-map int fa0/1

Service-policy output: QoS-LAN-Policy

Class-map: Voice-RTP (match-any)
55890 packets, 11178000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 5
55890 packets, 11178000 bytes
5 minute rate 0 bps
Match: ip dscp ef (46)
0 packets, 0 bytes
5 minute rate 0 bps
Match: ip rtp 16384 16383
0 packets, 0 bytes
5 minute rate 0 bps
QoS Set
dscp ef
Packets marked 55890
Strict Priority
Output Queue: Conversation 264
Bandwidth 500 (kbps) Burst 12500 (Bytes)
(pkts matched/bytes matched) 55890/11960460
(total drops/bytes drops) 0/0

Class-map: Voice-Cntl (match-any)
605 packets, 80661 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 3
605 packets, 80661 bytes
5 minute rate 0 bps
Match: ip dscp af31 (26)
0 packets, 0 bytes
5 minute rate 0 bps
Match: access-group name voice-signal
0 packets, 0 bytes
5 minute rate 0 bps
QoS Set
dscp af31
Packets marked 605
Output Queue: Conversation 265
Bandwidth 30 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 605/76019
(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)
1103573 packets, 80456575 bytes
5 minute offered rate 151000 bps, drop rate 0 bps
Match: any
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0

Came across an interesting issue where Customer was not able to access Disaster Recovery drop downs.

I tried it myself and I was getting as follows:

So it was Local agent not responding – I tried restarting the Cisco DRF Master and Local but that didn’t help.

This is what I did to resolve the issue:

  • Log into Cisco Unified Communications Manager OS Administration page.
  • Went into Security > Certificate Management.
  • Do Find all
  • At the bottom there was – I clicked that and regenerated the file
  • Found all ipsec-trust certificates and deleted them
  • Then went into tomcat.pem and regenerated it as well
  • Restarted the Cisco TOMCAT service (from CLI) and Cisco DRF Master / Local and TFTP from GUI

It was all working fine after that.

I had an interesting case last week where calls over ICT trunk would connect but then either party will not hear each other for 8-10 seconds.

The issue was first reported from US users trying to reach UK users over an Inter-cluster trunk (Non-GK). Both clusters had two call managers version 8.0.3. The whole issue started after US call managers were re-located and their IP addresses were changed. The ping response between two clusters was about 145ms which wasn’t too bad. I did a test call to a UK phone by connecting my IP communicator to US (due to time difference it was very difficult to get someone in US to make test calls). I did a CFA on UK phone to Voicemail and could see on my communicator that the call has connected but I didn’t hear the first 10 seconds of the voicemail.

I made a similar test by calling a UK phone but this time asked someone to answer it. The call was connected fine but we couldn’t hear each other for like 10 seconds. After 10 s it was all ok.

The issue was bit different when someone from UK to US would call. In that case call will connect 70% of the time with no issues but 30% of the time it will connect and drop.

I had to run through different CCM traces on both clusters to find below:

### Digit analysis for the call
04:42:47.464 |Digit analysis: match(pi=”2″, fqcn=”XXXXXX1409″, cn=”1409″,plv=”5″, pss=”PT_FRNA_INTERNAL:PT_FRNA_ROUTE”, TodFilteredPss=”PT_FRNA_INTERNAL:PT_FRNA_ROUTE”, dd=”303165″,dac=”0″)|2,100,49,1.20123926^^SEP002318D1DF43
04:42:47.464 |Digit analysis: analysis results|2,100,49,1.20123926^^SEP002318D1DF43
04:42:47.464 ||PretransformCallingPartyNumber=1409

04:42:47.464 |DeviceManager::star_DmPidReq – RequestedName=dec100fa-40c7-ac1a-9dcb-50a73af41700 LookupName=dec100fa-40c7-ac1a-9dcb-50a73af41700|2,100,49,1.20123926^^SEP002318D1DF43
04:42:47.464 |Digit analysis: wait_DmPidRes- Partition=[8a2bfaaa-13f0-4631-9c26-02a08a573cf7] Pattern=[21XXXX] Where=[],cmDeviceType=[AccessDevice], OutsideDialtone =[0], DeviceOverride=[0], PID=RouteListControl(2,100,73,10)|2,100,49,1.20123926^^SEP002318D1DF43

### H225 set-up sent via ICT:
04:42:47.616 |Out Message — H225SetupMsg — Protocol= H225Protocol|*^*^*
04:42:47.616 |Ie – H225BearerCapabilityIe IEData= 04 03 80 90 A2 |*^*^*
04:42:47.616 |Ie – Q931DisplayIe IEData= 28 0B 43 68 61 64 20 48 61 69 6E 65 73 |*^*^*
04:42:47.616 |Ie – H225CallingPartyIe IEData= 6C 08 00 81 32 30 31 34 30 39 |*^*^*
04:42:47.616 |Ie – Q931CalledPartyIe IEData= 70 05 80 33 30 36 33 |*^*^*

### Connect received (call answered)
04:42:49.461 |In  Message — H225ConnectMsg — Protocol= H225Protocol|*^*^*
04:42:49.461 |Ie – H225BearerCapabilityIe — IEData= 04 03 80 90 A2 |*^*^*
04:42:49.461 |Ie – Q931DisplayIe — IEData= 28 0C 53 74 65 76 65 20 47 61 72 6E 65 72 |*^*^*
04:42:49.461 |Ie – Q931ConnectedNumIe — IEData= 4C 06 00 81 33 30 36 33 |*^*^*

### outgoing TCS sent after about 8 seconds:
04:42:57.260 |TranslateAndTransport(21728)::waitForSdlRsp_H245TcpConnectionInfo – received H245TcpConnectionInfo from H245Handler|0,0,0,0.0^*^*
04:42:57.264 |
H245ASN – TtPid=(21728) -Outgoing #195026  -value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :

¬Also, the SDL logs indicate a significant delay in the TCS being sent out:
Line 135: 027643128| 2011/07/06 04:42:49.465| 002| SdlSig    | H245ConnectReq                        | wait                          | H245Handler(2,100,24,1)         | TranslateAndTransport(2,100,16,21728)| (2,100,23,21728).1-(*:*)                | [NP – PQ: 0]
Line 331: 027643324| 2011/07/06 04:42:57.259| 002| SdlSig    | H245TcpConnectionInfo                 | waitForSdlRsp                 | TranslateAndTransport(2,100,16,21728)| H245Handler(2,100,24,1)         | (0,0,0,0).0-(*:*)                       | [R:NP – HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]
Line 332: 027643325| 2011/07/06 04:42:57.259| 002| SdlSig    | TtControlChannelEstablished           | waitForTransportEstablishment | H245SessionManager(2,100,23,21728)| TranslateAndTransport(2,100,16,21728)| (0,0,0,0).0-(*:*)                       | [R:NP – HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]

This shows the H225 part of H323 is fine but H245 was taking time. I did reset of trunks, changed Call manager priorities etc but that didn’t help.

I then enabled ‘Outbound FastStart’ for all outbound calls from US to UK and enabled the same for inbound calls on UK trunk. This fixed the issue.

I had to provide a MTP resource under MRGL at US trunk as FastStart needs MTP.

US Cluster:

UK Cluster:

A little about how ‘Outbound FastStart’ works from Cisco:

Outbound Calls :

Enable Outbound FastStart   

Check this check box to enable the H.323 FastStart feature on outgoing calls.
By default, the check box remains unchecked for the H.323 gateway or trunk.
When you check the Enable Outbound FastStart check box, you must set the Media Termination Point Required, Media Resource Group Lists, and Codec for Outbound FastStart.

Inbound Calls:

Enable Outbound FastStart   

Check this check box to enable the H.323 FastStart call connections on incoming calls.
By default, the check box remains unchecked for the H.323 gateway.
For intercluster calls, you must check the Enable Inbound FastStart check box on Cisco CallManager servers in other clusters for the outbound FastStart feature to work.
If you updated Cisco CallManager 3.3(2) servers in other clusters with support patch B, do not enable inbound FastStart because 3.3(2)spB does not support the inbound FastStart feature over intercluster trunks

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.