Archive for the ‘Call Manager – CUCM’ Category

If you want to check what has been configured on a Jabber-config.xml then you need to go to CLI of CUCM and execute this command to display its contents:

admin:file view tftp jabber-config.xml

<?xml version=”1.0″ encoding=”utf-8″?>
<config version=”1.0″>

end of the file reached
options: q=quit, n=next, p=prev, b=begin, e=end (lines 1 – 14 of 14) :


You can see the file by using this URL:



You can also find a local copy on user PC at:

%USERPROFILE%\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Config

Remmeber EDI is used for authentication from LDAP directory server (default)

UDS is used for CUCM authentication (need to configure the UDS service and Proile)

CUCM 8.6 and above support UDS.


Since Cisco Unified Attendant Console has reached its end of life, clients are offered several alternatives from Cisco Solution Partners. This article will help you to make the rights choice.

Directory and Basic Call Control Features

If a Cisco IP phone is one of your main business tools you need the most convenient interface to:

  • quickly find any person and call him,
  • see who’s calling you,
  • perform the basic call control actions – call forward, conference, parking etc.

So, when selecting the attendant console for Cisco UCM pay attention directory and call control features. Make sure that the solution supports:

  • several directories – employees, clients, personal contacts etc,
  • customizable structure for each directory – for example, first/last name and position for employee, company name and city for clients and so on,
  • presence status for internal contacts,
  • convenient search and filter tools,
  • easy to use call control features – put the call on hold, forward the call (blind and consultative), organize an ad-hoc conference.

Then, depending on who is going to use the console software, pay attention to special features.

  1. Features for Managers

If the console app is going to be used by sales people or top managers, the key feature is the intuitive user interface which doesn’t require much training. Employees photo, large buttons, drag-and-drop features would be nice. And, of course, the call history panel.

  1. Features for Assistants

If you need a solution for top manager assistants, pay attention to some special features, like:

  • phone lines monitoring – to know who the manager is talking to and who’s calling him,
  • call interception – to intercept and answer the incoming call when the manager is away,
  • “whisper” feature – to notify manager about important call while he is on the phone,
  • conference control features – to create audio-meetings for manager and control the conference even without being its participant.
  1. Features for Receptionists and Contact Center Agents

Lastly, when it comes to reception or contact center personnel, whose main task is to answer incoming calls, make sure the attendant console provides superior call routing and distribution tools:

  • queue support (both UCCX and CUCM native queuing) with the ability to see who’s on queue and choose the call to answer,
  • intelligent call routing assistant, which shows a list of employees to whom calls from the current calling party were routed most often,
  • hot keys support to process the incoming calls as fast as possible,
  • dynamic search, fast enough even when searching tens of thousands of contacts,
  • comments to calls, visible for other operators.

The article is provided by Aurus, the official Cisco Solution Partner. Aurus PhoneUP is the application suite for Cisco Unified Communications Manager Enterprise and BE 6000/7000 which includes both Enterprise Directory and Attendant Console for CUCM modules.

I was working on this customer issue last week where they added a new 7841 phone but it was not registering properly or should I say it was registering briefly before unregistering.

Call Manager was which does not support 78XX phones so customer actually applied the device pack cmterm-devicepack9.1.2.12039-1.cop  so that they can add 78XX phones.

Looking at the logs I found that it is registering with Pub and not Sub even though Sub was the Primary CCM in Call Manager group. At Pub I can see something like this:


Via: SIP/2.0/TCP;branch=z9hG4bK739dd207
From: <sip:49715220XXXXX@>;tag=544a003629fd000a741be677-22e1dea8
To: <sip:49715220XXXXX@>
Call-ID: 544a0036-29fd0008-13a9ded8-614a41b9@
Max-Forwards: 70
Date: Tue, 17 Jun 2014 06:32:10 GMT
User-Agent: Cisco-CP7841/10.1.1
Contact: <sip:61131fd1-5eb6-b49e-5d2f-9f9aee1b125c@;transport=tcp>;+sip.instance=”<urn:uuid:00000000-0000-0000-0000-544a003629fd>”;+u.sip!”SEP544A003629FD”;+u.sip!”622″

[Registration Accepted by Publisher]
SIP/2.0 202 Accepted
Via: SIP/2.0/TCP;branch=z9hG4bK6c29941b
From: <sip:544a003629fd@>;tag=544a003629fd000c3890afb1-54d723a2
To: <sip:>;tag=875713562
Date: Tue, 17 Jun 2014 06:32:10 GMT
Call-ID: 544a0036-29fd0006-22434855-1719a3c1@
CSeq: 1000 REFER
Contact: <sip:;transport=tcp>
Content-Length: 0




But then I noticed this further down:

08:32:16.866 |AppInfo  |SIPStationD(607) – setUaTypeAndCepn: uaType is CISCO_ENHANCED_PHONE

08:32:16.866 |AppInfo  |SIPStationD(607) – Received REGISTER from 4971522036708@

08:32:16.866 |AppInfo  |SIPStationD(607) – verifyAddressAndPort — Endpoint unregistered (expires=0), old ip:, new ip:


08:32:16.866 |AppInfo  |SIPStationD(607) – parseLoad: InactiveLoad= name is: [sip78xx.10-1-1-9.loads]

08:32:16.866 |AppInfo  |SIPStationD(607) – processReasonCode:  Processing phone provided reason code=[105]

08:32:16.866 |AppInfo  |SIPStationD(607) – DevStat-NewState : line 4971522036708: Registered ==> Unregistered


While on Subscriber this is what I saw:



[Registration Request]

Via: SIP/2.0/TCP;branch=z9hG4bK5fead06f
From: <sip:49715220XXXXX@>;tag=544a003629fd00020eea65f9-659c5963
To: <sip:49715220XXXXX@>
Call-ID: 544a0036-29fd0003-4c3d829b-12a9daae@
Max-Forwards: 70
Date: Wed, 11 Apr 2012 08:28:24 GMT
User-Agent: Cisco-CP7841/10.1.1
Contact: <sip:61131fd1-5eb6-b49e-5d2f-9f9aee1b125c@;transport=tcp>;+sip.instance=”<urn:uuid:00000000-0000-0000-0000-544a003629fd>”;+u.sip!”SEP544A003629FD”;+u.sip!”622″
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-6.0.2,X-cisco-xsi-8.5.1
Reason: SIP;cause=200;text=”cisco-alarm:25 Name=SEP544A003629FD ActiveLoad=sip78xx.10-1-1SR1-4.loads InactiveLoad=sip78xx.10-1-1-9.loads Last=initialized”
Expires: 3600
Content-Type: multipart/mixed; boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 1203


08:31:40.497 |AppInfo  |SIPStationD(684) – setUaTypeAndCepn: uaType is CISCO_ENHANCED_PHONE

08:31:40.497 |AppInfo  |CcmdbStationRegistrationProfileBuilder::init – No typemodel table-entry for device SEP544A003629FD.

08:31:40.497 |AppInfo  |CcmdbStationRegistrationProfileBuilder::getBasicRegistrationProfile::init() – failed rc(1)

08:31:40.497 |AppInfo  |SIPStationD(684) – Registration profile error: Database error, sending registration reject and closing station

08:31:40.497 |AppInfo  |SIPStationD(684) – sendRegisterResp: non-200 response code 404, ccbId 336776, expires 4294967295, warning Database error

08:31:40.497 |AlarmErr |AlarmClass: CallManager, AlarmName: EndPointTransientConnection




So what does it tells us?

Subscriber is not accepting the registration from this 7841 as it does not see that phone type as a legitimate phone.

But hang on did the customer not applied the device pack? yes they did.

A quick phone call with customer revelaed some secrets… Yes they did applied the device pack but rebooted only the Publisher. He questioned me in amazement  “Do we need to reboot Subscribers as well?”


Anyways, issue was resolved after rebooting the Sub as well. The device pack although applies would not take affect until you reboot it. So remember that if you are going to apply a device pack then:

  1. Apply on all nodes
  2. Reboot all nodes in cluster starting from Publisher





One of our customer reported an issue with ring back tone when calling their Contact center.

I made a test call and observed that as a caller when you call their main Contact center number all you hear is dead silence and then when agent picks up the phone you could hear them talk. There was no ring back tone and no automated messages before an agent picks up the call.

The call flow was something like this:

PSTN > ISDN30 > H323 Dial-peer > SIP Trunk > 3rd-party Contact Center Equipment

First I thought it could be the third-party equipment which was not sending back the ring back tone so I asked them to confirm this. They came back saying they are definitely sending ring back and there was no issue with their equipment.

Looking at Q931 debugs I could see ALERTING message with payload but wasn’t sure why there was no ring back.

The dial-peers were looking ok as well:


dial-peer voice 8500 voip
corlist outgoing CCM
description DC1CCM01
preference 1
destination-pattern 361[01].
progress_ind setup enable 3
progress_ind alert enable 8
session target ipv4:
dtmf-relay h245-signal h245-alphanumeric
no vad


dial-peer voice 8501 voip
corlist outgoing CCM
description DC1CCM02 Cycos Ansage
preference 2
destination-pattern 361[01].
progress_ind setup enable 3
progress_ind alert enable 8
session target ipv4:
dtmf-relay h245-signal h245-alphanumeric
no vad
I then decided to run some debugs to get a complete picture as to what is going wrong. These were the debugs I opened on the gateway:

debug voip ccapi inout
debug cch323 all
debug h225 asn1
debug h245 asn1
debug ip tcp trans
debug ccsip all

Collected debugs in the following manner:

Router(config)# service sequence
Router(config)# service timestamps debug datetime localtime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog

Note: Please be very careful when you run the above debugs as these are processor intensive and make sure you are not logging monitor and console.

The debugs were massive but this is what I observed:

From Gateway traces I can see RINGBACK has definitely been sent to Gateway –

005302: *Aug 25 23:44:07.256: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type ALERTIND_CHOSEN
005303: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/alert_ind: ====== PI = 0
005304: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/alert_ind: alert ind ie_bit_mask 0x1260, displayInfo
005305: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/alert_ind: delay H245 address in alert
005306: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/alert_ind: Call Manager detected
005307: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/cch323_h225_receiver: ALERTIND_CHOSEN: src address =; dest address =
005308: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/run_h225_sm: Received event H225_EV_ALERT_IND while at state H225_REQ_FS_CALLPROC
005309: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/cch323_get_embedded_obj_from_ccb: ccb=0x4715D7A0, tag=18, size=83
005310: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/cch323_get_embedded_obj_from_ccb: Extraction FAILED
005311: *Aug 25 23:44:07.256: //3610/D48C17148501/CCAPI/cc_api_set_called_ccm_detected:
CallInfo(called ccm detected=TRUE ccmVersion 3)
005312: *Aug 25 23:44:07.256: //3610/D48C17148501/CCAPI/cc_api_set_delay_xport:
CallInfo(delay xport=TRUE)
005313: *Aug 25 23:44:07.256: //3610/D48C17148501/CCAPI/cc_api_call_alert:
Interface=0x46B2BAA8, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
005314: *Aug 25 23:44:07.256: //3610/D48C17148501/CCAPI/cc_api_call_alert:
Call Entry(Retry Count=0, Responsed=TRUE)
005315: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/cch323_h225_set_new_state: Changing from H225_REQ_FS_CALLPROC state to H225_REQ_FS_ALERT state
005316: *Aug 25 23:44:07.260: //3609/D48C17148501/CCAPI/ccCallAlert:
Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)

Then ALERTING Signal shown in ISDN Q931 debug:

005331: *Aug 25 23:44:07.264: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x803A

But then Observed this:

005332: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/h323_open_rtp_stream: Media In-active notification object not attached to ccb
005333: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/cch323_set_dtmf_iw_enabled: negotiated dtmf relay: 0, dtmf_iw_enabled: 0, dtmf_sccp_enabled: 0
005334: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/cch323_caps_ind: gw_id=1
005335: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/cch323_peer_caps_ind_common: Load DSP with Preferred codec(16) g729r8, Bytes=20
005336: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/cch323_peer_caps_ind_common: Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE
005337: *Aug 25 23:44:07.396: TCP0: ACK timeout timer expired
005338: *Aug 25 23:44:07.448: //-1/xxxxxxxxxxxx/H323/cch323_ct_main: SOCK 2 Event 0x1
005339: *Aug 25 23:44:07.448: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: owner_data=0x46DA9F30, len=53, msgPtr=0x475C62BC
005340: *Aug 25 23:44:07.448: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: Received msg for H.225

I was a bit surprised as to why G729 codec was negotiated when the whole path is G711. Even the SIP trunk was in all-G711 region.

Looking closely at dial-peers I found what was missing!! The VOIP dial-peers were missing the “Voice class codec 1” command which had G711 as priority 1 codec. As the command was not there, the call was matching dial-peer 0 and hence negotiating G729 codec. I added the command and the problem was solved. I can now hear ring back tone as well as all automated messages.

This is how it looks after I made the changes:

005935: *Aug 26 00:15:26.432: //3620/349708E58506/H323/h323_open_rtp_stream: Media In-active notification object not attached to ccb
005936: *Aug 26 00:15:26.432: //3620/349708E58506/H323/cch323_set_dtmf_iw_enabled: negotiated dtmf relay: 0, dtmf_iw_enabled: 0, dtmf_sccp_enabled: 0
005937: *Aug 26 00:15:26.432: //3620/349708E58506/H323/cch323_caps_ind: gw_id=1
005938: *Aug 26 00:15:26.432: //3620/349708E58506/H323/cch323_peer_caps_ind_common: Load DSP with Preferred codec(5) g711ulaw, Bytes=160
005939: *Aug 26 00:15:26.432: //3620/349708E58506/H323/cch323_peer_caps_ind_common: Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE
005940: *Aug 26 00:15:26.568: TCP0: ACK timeout timer expired
005941: *Aug 26 00:15:26.620: //-1/xxxxxxxxxxxx/H323/cch323_ct_main: SOCK 2 Event 0x1
005942: *Aug 26 00:15:26.620: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: owner_data=0x46DAB900, len=53, msgPtr=0x475C5200
005943: *Aug 26 00:15:26.620: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: Received msg for H.225
005944: *Aug 26 00:15:26.620: H225.0 INCOMING ENCODE BUFFER::= 28501900060008914A0005003497A50DEE3911E19D37B87571A7872310800100
005945: *Aug 26 00:15:26.620:
005946: *Aug 26 00:15:26.620: H225.0 INCOMING PDU ::=

Most of the time problems like these are Codec or MRG related so it’s always a good idea to start checking your codecs first.

Customer reported a problem about their UCCX version for CAD Agents.

This is what they say about the problem:

We have a UCCX Agent with a 9951 Cisco Phone with 2 Lines.
First line is the private Line
Second Line is the agent Line.
Agent is logged into CAD with his agent extension.

Contact Center gets a customer call for the agent and the agent accepts the call on Agent Line.
Then the agent wants to ask a colleague or wants to transfer the call and presses the call transfer key (on CAD)
The transferred Call is answered by the colleague and they start talking.
The customer hears Music on hold.
So far everything is normal.

Now a new call comes in on the private Line and hits the CFNA to voicemail, or the caller hangs up.

The issue is that at that point with no interaction of the agent or his colleague the transferred Call from the agent to the colleague gets disconnected.

After the issue occurs the call from the private line is on the voicemail.
And the first call (Contact center) still hears music on hold.

This is the fact on all of our phones when an agent is logged in with CAD.

= = =

Later we found there was a bug CSCts44173 hitting this UCCX Version so we asked customer to upgrade to a fixed Version. Customer upgraded the UCCX to but the issue was there for external calls. Calling internally fixed the issue.

After going through the logs we found that the person who was testing had a “Remote destination” setup for his mobile number and this is why they were facing the issue.

So, when customer is facing this very issue make sure they are not using “remote destination” setup.

You may have come across this that though you are logged into your profile through Extension mobility but when you try to access your “Personal Directory” you will be prompted for a userid and pin. Unfortunately, this is by design and cannot be changed. There is a workaround to escape entering userid and pin which I found after getting several requests from customers. If you are among one of those who is annoyed with this then following is the procedure to get rid of it. You will need Admin rights on Call manager to make these changes.

  1. Create a new phone service for Personal directory named PAB
  2. Use this URL http://server-name-or-ipaddr:8080/ccmpd/​pab​
  3. Add the Parameters “name” “pin” and “userid” with no default value (Case sensitive)
  4. Now go to the phone and Subscribe to “PAB”
  5. In the name field enter Phone MAC address with SEP like SEPAABBCCDD9876
  6. In the pin field enter user pin
  7. In the user id enter user id of that user
  8. Click Subscribe and save
  9. Reset the phone

This will now add a  new service called “PAB” under services so you can go in Service and select “PAB” to go directly into Personal directory and the system will not ask you userid and pin.

You may also add this service to a button on the phone. Just add a Service URL type on your phone from “button template” and then you can access PD from that button.

You may also ask users to subscribe to this service by logging into CCMUSER and then adding this service from Device > Services.

The same procedure applies for FASTDIALS except the following changes:

  1. Name the new Service FastDials
  2. The URL is http://server-name-or-ipaddr:8080/ccmpd/​fd
  3. Add only “pin” and “userid” in Parameters
  4. Subscriber Phone or user to this service

Here are screenshots from my Communicator as how this service will appear:

I was looking into a case for one of very high profile customer where their CIMC (Cisco Integrated Management Controller) was showing PS Redundancy status as ‘lost’. However, both PSU were up and Normal. Have a look at the screenshot below:

By searching through Bug Tool kit I found two bugs for this particular issue – CSCtx66554 & CSCtt03265 which is affecting C200/210 series and there is no fix as of yet.

Have a look at the workaround and it may fix the issue but if not then you can Order a replacement from Cisco.


Had a bizarre issue with one of the customer where they were trying to dial an internal extension and it was going to a mobile phone. There were no CFA/CFNA/CFB set on the extension itself but for some reason it was following this path. The Call manager version was 6.x.

The call routing was designed in a way that when they dial any 7614XXXX extension, it hits a TP (7614XXXX )and gets translated to 60447614XXXX. For testing we dialed several 7614XXXX numbers and they all went fine to corresponding 60447614XXXX except when they dialed 76146920. As soon as they dial that number you will see on the display that it’s going to an outside mobile number.

I had to dig into traces where I found for some reason it is not even hitting the Translation pattern at all and was getting intercepted by a pattern 76146920 with a Time of Day routing on it which had that mobile number setup during a certain period of time. But when I checked, there was no such TOD routing setup on this extension,  moreover there was no such extension 76146920 which exist in the system. I ran some CLI commands to find if there are any database entries for this extension and found none. Customer told me that they use to have extensions like 7614XXXX before they migrated all extensions to 60447614XXXX which means may be previously someone did setup a CFA on this extension which is still stuck in it’s database.

|RouteBlockFlag=BlockThisPattern <———block

cfa     = 755XXXXXX <———– Mobile number


This is what I did to resolve the issue:

  • Created an internal extension 76146920 and put it in Internal Partition
  • Assigned the extension to a dummy phone
  • Put a Call Forward ALL on the extension to some internal number
  • Made a test call which now hits this newly created DN and goes to that CFA internal extension
  • Removed CFA and saved
  • Deleted the DN 76146920
  • Made a test call and this time it was ringing the phone 604476146920


This was just a one off issue and Cisco TAC later confirmed that old versions of CCM may come across these kind of issues. This is rare but I thought to share it for the benefit of everyone.


A customer reported an issue with their 7941 phone. The issue was they plugged in a new 7941 all configured at Call manager and it was showing “Error pass Limit” as follows:

This sort of error normally comes when you have one of the following conditions:

  • Too many unassigned directory numbers in Call manager i.e. not assigned to any phone or any extension mobility profile
  • No Extension assigned to the phone
  • The Busy Trigger and maximum calls on the line are not correct (normally you configure max calls: 4 and busy trigger: 2)

For this particular issue I found no extension was assigned to it so I assigned an unassigned DN and the issue was resolved.

With the missed call logging for shared lines feature, the administrator can configure Cisco Unified Communications Manager Administration, or the phone user can configure Cisco Unified CM User Options, so Cisco Unified Communications Manager logs missed calls in the call history to a specified shared line appearance on a phone.

This will only work if users who are sharing the number are logged in using Extension mobility.

You can configure it here under extension number by going into each phone:

If the box is checked, missed calls will be logged and if it is not checked then missed calls won’t be logged.