Cisco UCCX Historical Reporting Issues

I found this great documentation which entails the discrepancies and differences in the UCCX reporting for similar constructs like Calls Handles, Abandoned, RNA etc.

Understanding Data Discrepancy between Different UCCX Reports

One classical case in point is when you run the Historical reports to get Abandoned Call data from CSQ Summary Report versus Application Summary reports. The Application Summary report will also reflect the calls which were transferred lets say top VM and set as Handled in the Script using SetContactInfo step. Hence you will see that Application Summary reports will generally show more Abandoned Calls than CSQ Summary reports. You will see the same anomaly in the Call Presented metric when you run these two reports.

HTH

Mann

BFCP: A good Introduction

I was working on implementing Jabber Video & Desktop Sharing when I learnt about the BFCP (Binary Floor Control Protocol). I found a good link in the IPJ which takes us through an introduction of the protocol:
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_15-3/153_binary.html

Collaboration and video are the modalities UC solutions will have to provide and BFCP is a Signaling Protocol agnostic development in this front. Interesting space to follow.

Good day.

At Last...CCIE # 37926

After almost two years of hard labor, I was able to gain my CCIE number on Jan 10th. I am now CCIE (Voice) # 37926.

I am working on Jabber & Meeting Place deployments for enterprise these days and hope to come back with meaningful posts shortly.

Manpreet Chaddha

Cisco SRST Configuration

SRST or Survivable remote site telephony is a High availability mechanism which provides Call Survivability to the phones & trunks at a remote office in an event of network isolation from their CUCM Subscribers/Call Agent Servers. Here are the steps that are required to configure SRST using call-manager-fallback method. We can also use CME as SRST which will see later. CME as SRST provides a much better feature functionality compared to call-manager-fallback.

Step 1: Configure SRST Reference on CUCM for the remote site.

Step 2: Assign the SRST Reference to the  Device Pool (DP) of the remote phones. You may also use the default gateway of the Voice VLAN. reset all the phones & verify that the phones show SRST router as their Call Agent after CUCM Servers under the Setting >> Device Configurations >> Unified CM Configurations.

Step 3:  Configure SRST call-manager-fallback on the Voice Router at the remote site. This will provide Call Agent functionality to the SCCP phones. You can configure SIP SRST too. This configuration is applicable only for SCCP Phones.

 call-manager-fallback

     ip source address 10.18.71.1             >> SRST Reference IP address
     max-ephones 40
     max-dn 100 octo-line
     system message primary FallBack Mode. CUCM Down.
     voicemail 4999
     call-forward busy 4999
     call-forward noan 4999 timeout 12
     time-zone 8
     time-format 24
     date-format mm-dd-yy

Step 4: [Optional] If you have the Gateways registered to CUCM using MGCP Protocol, then you must also configure MGCP fallback which basically provides the option to the gateway to use H323 or SIP in an event of network disconnection to the CUCM Subscribers.

ccm-manager fallback-mgcp <<< if its an MGCP Site.

Step 5: Configure your dial plan using Dial Peers to enable call routing. This may be minimal if you are using H323, but will require you to configure your all applicable routes in case you're using MGCP. Here is a sample minimal configuration.

dial-peer voice 1 pots
destination-pattern 9[2-9]......
port 2/0/0:23
forward-digits 7
!
dial-peer voice 2 pots
destination-pattern 91[2-9]..[2-9]......
port 2/0/0:23
forward-digits 11
!
dial-peer voice 3 pots
destination-pattern 9011T
port 2/0/0:23
prefix 011
!
dial-peer voice 10 pots
description Abbreviated Dialing to HQ Site
destination-pattern 4...
port 2/0/0:23
no digit-strip
prefix 1212902
!

Hope this helps. Good day.

"Unknown" Number type in Calling (ANI) Number

I wish all carriers mark their ISDN parameters properly so that it’s easier for us to globalize (read converting to e.164 form) the Incoming ANI (read my previous blog on Calling & Called Party Transformations in CUCM).  Indeed Cisco developers themselves missed this discrepancy on the carrier front when they didn’t include a CSS parameter in the Voice Gateways Incoming Calling Party Settings tab. But they did add this feature from CUCM Version 8 onwards.

Now let me walk you through the handiness of this simple parameter to the process of globalizing the incoming ANI. 

Here are 2 snippets of "deb isdn q931" from my T1 PRI:

National Call Type Example:

Calling Party Number i = 0x0080, '212XXXXXXX'

   Plan:Unknown, Type:Unknown

Called Party Number i = 0xA1, 'XXXXXXXXXX'

   Plan:ISDN, Type:National

International Call Type Example:

Calling Party Number i = 0x0080, '44120XXXXXXX’

                Plan:Unknown, Type:Unknown

Called Party Number i = 0xA1, ' XXXXXXXXXX '

                Plan:ISDN, Type:National

 

Now I am unable to employ the Subscriber, National or International Number Type ISDN Parameter to globalize this ANI. Also I cannot use the same digit manipulation like adding +1 to all these as you can see that the carrier is sending both an International & a National ANI with the unknown number type only. 

So I will simply give a CSS to this number type. Here is a screenshot for the same:

Now I will add multiple Calling Party transformations assigned to the Partition which will be part of the above assigned CSS.

 

Here are the digit manipulations being done for the respective transformations:

 

I hope this will help all of you who have been irritated with the “Unknown” number type set by the carriers. For Asian carriers this is the norm and hence you will have to get more creative in isolating different ANIs to convert them to E.164 form.

HTH & Good day.