Recently we had a customer who asked if there is any way they can logout all users from extension mobility at the same time?

There is no straight forward answer if you google it so I thought to compile this post for a quick reference.

You can do this from Bulk Administration.

Just browse to Bulk Admin > Phones > Update Phones > Query and then if you want to search all of them just hit ‘Find’.

This will bring all the phones in the system.

Scroll down and hit Next you will see a screen similar to this:

Don’t change anything else and run the job. Click Submit.

There you go, it will log out all the extensions. You can check the status of it from Scheduler.

There are times when you would like to forward a call coming into your gateway out to PSTN before it goes to Call manager. Reason could be WAN outage to Call managers or Call manager down situation.

This is how you can route out an incoming call out of the gateway.

Let suppose the mainline number coming into the gateway is ’881456′. The following setup will route the call out of the gateway to PSTN.

voice translation-rule 10
rule 1 /881456/ /901139886666/
!
voice translation-profile RedirectPSTN
translate called 10
!
dial-peer voice 10 pots
description Incoming Dial Peer
translation-profile incoming RedirectPSTN
incoming called-number 881456
direct-inward-dial
port 0/0/0:15
!
dial-peer voice 20 pots
description Outbound Dial Peer
destination-pattern 9T
port 0/0/0:15
!

Call comes in and match incoming-called number dialpeer 10 and then it will match the incoming translation profile. The translation profile will translate the number to another PSTN number with prefix ’9′. This will match dialpeer 20 and will send the call out to PSTN.

I was looking at some alerts for a customer when I found this in RTMT:

At Thu Mar 01 04:42:41 CET 2012 on node 10.254.33.20, the following HardwareFailure events generated:
hwStringMatch : Mar  1 04:42:10 AKDEUC00 daemon 4 Director Agent: LSIESG_AlertIndication 500605B0024A5360 BBU disabled; changing WB virtual disks to WT Sev: 3.
AppID : Cisco Syslog Agent
ClusterID :
NodeID : AKDEUC00
TimeStamp : Thu Mar 01 04:42:10 CET 2012

If you are concerned about this error then don’t be. This is a cosmetic error and documented in Bug id CSCti17353 .

 Bug Details

“IBM Servers battery learn cycle negatively impacts CCM performance”

Symptom:

CCM Tracing stops for a period of time (over 4 seconds observed) leading dropped or reordered calls.
IO wait utilization of the CPU increases unexpectedly.  System Event Logs (messages) contains the following logs shortly after the unexpected IO event.

Aug 2 15:48:08 lg-sub-1 daemon 5 Director Agent: LSIESG_AlertIndication 500605B00177F4C0 Battery relearn started Sev: 2.
Aug 2 15:48:13 lg-sub-1 daemon 4 Director Agent: LSIESG_AlertIndication 500605B00177F4C0 BBU disabled; changing WB virtual disks to WT Sev: 3.

Conditions:

On MCS-78X5-I3 platforms with LSI Raid controllers the system will run a Battery Backup Unit learning cycle every 60 days. The system can experience sudden IO
performance drop at the beginning of this cycle and this could impact Callmanager’s call processing performance. During this cycle the Raid Controller’s Caching policy is changed from WriteBack to Write Through.

Workaround:

None to avoid the BBU learning cycle.

After this ddts is applied…

The event reported above is an informational (sev 4) event: daemon 4

Director Agent:
LSIESG_AlertIndication 500605B0027DA6E0 BBU disabled; changing WB virtual disks

The event will occur once a month (at 4:42am) during the battery recharging cycle. That cycle is a scheduled event to recharge the raid battery. During that time, raid cache write-back is disabled as part of normal course to ensure proper IO. This is not an issue.

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.

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.

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.

|VoiceMailPilotNumber=
|RouteBlockFlag=BlockThisPattern <———block
|RouteBlockCause=1
|AlertingName=
|UnicodeDisplayName=
|DisplayNameLocale=33
|InterceptPartition=Internal
|InterceptPattern=76146920

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.

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.

There is a Field replacement notice as well which you can find at http://www.cisco.com/en/US/ts/fn/634/fn63425.html

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/login.do?name=#DEVICENAME#&service=​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/login.do?name=#DEVICENAME#&service=​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:

Customer reported a problem about their UCCX version 8.5.1.11001-35 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 8.5.1.11003-32 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.

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:10.1.30.12
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:10.1.30.13
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 0×1260, 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 = 10.187.10.8; dest address = 10.1.30.12
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 0×1
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 0×1
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.

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 9.1.2.11900-12 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:

Pub:

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

.
.
[Registration Accepted by Publisher]
SIP/2.0 202 Accepted
Via: SIP/2.0/TCP 172.18.52.91:51736;branch=z9hG4bK6c29941b
From: <sip:544a003629fd@172.18.52.91>;tag=544a003629fd000c3890afb1-54d723a2
To: <sip:192.168.11.2>;tag=875713562
Date: Tue, 17 Jun 2014 06:32:10 GMT
Call-ID: 544a0036-29fd0006-22434855-1719a3c1@172.18.52.91
CSeq: 1000 REFER
Contact: <sip:192.168.11.2:5060;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@172.18.52.91:51736

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

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:

Sub:

[Registration Request]

REGISTER sip:192.168.11.3 SIP/2.0
Via: SIP/2.0/TCP 172.18.52.91:50358;branch=z9hG4bK5fead06f
From: <sip:49715220XXXXX@192.168.11.3>;tag=544a003629fd00020eea65f9-659c5963
To: <sip:49715220XXXXX@192.168.11.3>
Call-ID: 544a0036-29fd0003-4c3d829b-12a9daae@172.18.52.91
Max-Forwards: 70
Date: Wed, 11 Apr 2012 08:28:24 GMT
CSeq: 101 REGISTER
User-Agent: Cisco-CP7841/10.1.1
Contact: <sip:61131fd1-5eb6-b49e-5d2f-9f9aee1b125c@172.18.52.91:50358;transport=tcp>;+sip.instance=”<urn:uuid:00000000-0000-0000-0000-544a003629fd>”;+u.sip!devicename.ccm.cisco.com=”SEP544A003629FD”;+u.sip!model.ccm.cisco.com=”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

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.

2. 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.

3. 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.

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″>
<CUCM>
<PhoneService_UseCredentialsFrom>presence</PhoneService_UseCredentialsFrom>
</CUCM>
<Directory>
<BusinessPhone>ipPhone</BusinessPhone>
<OtherPhone>telephoneNumber</OtherPhone>
<BaseFilter>(&amp;(objectclass=user)(!(objectclass=Computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))</BaseFilter>
</Directory>
<Policies>
<File_Transfer_Enabled>false</File_Transfer_Enabled>
</Policies>
</config>

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

OR

You can see the file by using this URL:

http://X.X.X.X:6970/jabber-config.xml

XXXX = CUCM Pub

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.

The other day one of our key customer logged a priority incident with regards to a Toll Fraud. Their Carrier alerted them for possible malicious calls originating from their main ISDN number going to The Bahamas. At First I thought this has something to do with their Expressways so I checked Call logs and Events to find out if anything originated from Exp-E and then reached Gateway via CUCM. Customer did provide us the Called number so I went through the call history of Expressways but could not see any abnormal activity.

Customer was not provided the time the malicious activity started so it was left on us to track the activity and also find out the breach. I decided to jump onto RTMT and check call activity starting midnight from Real Time Data. It didn’t took me long to find a particular calling number appearing repeatedly in wee hours when people don’t call that often. I then traced back to the first call and found that the attacker actually called an Internal number and then the call was disconnected. Immediately after that the same calling number called that internal number but this time call was going out to a fraudulent number in The Bahamas 96492396493.

At this point I had an idea as to what went wrong!

The way this works is that a caller/hacker calls to a PSTN number of your organization. The call goes to the user and then on no response goes to voicemail (typical setup). While as a caller you are listening to voicemail, you can enter _ to get into set of options. Unity system then asks to enter your ID followed by #. This is normally used where a caller is calling his own mailbox from outside but can be used by a hacker. The hacker must know how your internal DN structure looks like and the voicemail pin. Once the hacker enters the DN and the pin correctly you are now in user mailbox and will be provided with a menu starting from changing pins and greetings to call forwarding. Hacker can easily enter a malicious number as a call forward and then when the user’s number will be called, the call will be forwarded to the fraudulent number and this is exactly what happened in our case.

The user pin was a trivial 12345 and the hacker either guessed the internal DN structure right or he had some idea of how it is all configured.

But as we all know Unity system do have a restriction table to avoid this kind of toll fraud so why it didn’t work in this case?

Well, this is because the rules which were setup did not stop a number starting with 9 and followed by 10 digits. There was a rule with 9 followed by 11 digits but not 9 and 10 digits which allows National calls. The other issue which the customer had in their configuration was that the voicemail CSS had access to National Route pattern 9.[2-9]XX[2-9]XXXXXX. The number went to gateway as 6492396493 and Carrier treated it as an International call because of 649 (Turks and Caicos Island).

Few important points to consider to avoid Unity toll Fraud:

• Do not allow Trivial pins
• Restriction tables must restrict all combinations
• Do not give Unity CSS access to outbound pattern unless necessary