UCCX 10.6 Notes

Miscellaneous UCCX v10.6 notes: 

==========

Calling Search Space for Redirect on your triggers by default is set to Default.  This means that UCCX will route calls through the application and script called by the trigger with the caller's CSS, not the trigger's CSS.  If your caller is not capable of reaching the agents or other destinations defined in the application and script directly your call will be rejected.  This is typically not an issue but where you might have PLARs set up with very restricted CSSs, sending the PLAR to a UCCX trigger may fail.  This can be modified per trigger on at least UCCX 8.5 and beyond.  See bug CSCso91760 at  https://bst.cloudapps.cisco.com/bugsearch/bug/ 20CSCso91760 for more redirect information.  See http://webmaxtor.blogspot.com/2011/05/cucm-ring-down-phone.html regarding basic SCCP PLAR setup.

==========

Finesse log in usernames are still case sensitive at this time. If MS AD says your username is jAnE123, you need to log into Finesse as jAnE123.


==========

To enable support for the Finesse browser based client:
at CLI, run utils uccx finesse activate 
This needs to be run on both master and secondary HA nodes and both servers need to be rebooted

==========

To verify Finesse master node and health:
https://<IP of Master node>:8445/finesse/api/SystemInfo 

==========

To access Finesse client:
https://<IP of Master node>:8445/desktop/ 

==========

The default Finesse agent client on UCCX 10.6 includes an Agent CSQ Statistics Report and an Agent Team Summary Report.  If an agent is assigned to a team (could even be the default team) and there is no CSQ associated with the team, the user will see "Error processing report. Refresh page or contact administrator."  Add CSQs to your teams.  Here's a before and after screenshot:

Broken link to Agent CSQ Statistics Report:

Default Finesse agent page with working Agent CSQ Statistics Report

==========

The default Finesse agent client on UCCX 10.6 includes an Agent CSQ Statistics Report. Your resources / agents must on a team that is assigned a CSQ to see the CSQ statistics. An agent may have a skill that allows them to take a call for a CSQ but they may still not be able to see the CSQ statistics in the Agent CSQ Statistics Report. If an agent has a skill that allows them to take a call for a CSQ, but they are on a team that is not assigned that skill, the user will see "Error processing report.. Refresh page or contact administrator." Again, add CSQs to your teams.

==========
VOIP Monitor Subsystem in PARTIAL SERVICE
A search of Cisco documentation will point you here: http://docwiki.cisco.com/wiki/VOIP_Monitor_Subsystem_is_in_partial_service_or_OOS but the issue in my case was a bit more devious.  After removing a HA UCCX server from the cluster (long story...) the second server remained an option as a VoIP Monitor Service and Recording and Playback Service.

From UCCX Desktop Administrator you can choose "Remove VoIP/Recording and Playback" link, select the associated server and hit Remove.  I found at that point I still needed to restart the UCCX Engine to return it to FULL SERVICE.

==========

Cisco Tomcat has a maximum inactivity timeout ouf 14400 seconds.  If you are intending on using CUIC as a wallboard, note you will be required to restart the CUIC instance if there is no activity in your call center for 4 hours (i.e. overnight, closed hours, etc.).

You can find some background here:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCun28885
https://supportforums.cisco.com/discussion/12538621/uccx-cuic-dashboard-timeout
https://supportforums.cisco.com/discussion/12934891/uccx-tomcat-session-timeout-values-can-not-be-updated-cscun28885

You can find my dirty workaround here:
http://webmaxtor.blogspot.com/2016/03/using-cisco-uccx-cuic-as-wallboard-and.html

==========
If you are creating custom desktop layouts for teams in Finesse and your administrator account is also assigned to that team, that account will be locked out of the Finesse administrator.  Make sure you have an administrator account that is not assigned to a team before customizing Finesse layouts.

See bug CSCur71176.

It looks like this when you hit it:

Creepy!

==========

Finesse sample gadgets for older versions can be found at https://developer.cisco.com/site/finesse/archive/.  There are changes in both the XML and javascript unique to each version.  A nice write up on the same can be found here: https://communities.cisco.com/community/developer/finesse/blog/2016/03/16/how-to-convert-your-existing-1051-custom-gadget-to-work-with-1061-or-1101

==========

The initial Finesse gadget heights can be set using
==========

The tab name in the WorkFlowScreenPop sample gadget is defined by the Window Name in the Workflow action found in Finesse administration.  You won't find it as-is in the gadget code.

 ==========

 

QoS conversions and testing with extended ping commands - version 2

Years ago I posted a tip regarding using Cisco IOS devices' extended ping capabilities to emulate traffic with various QoS / quality of service markings.  You can find the original post here: http://webmaxtor.blogspot.com/2010/08/qos-conversions-for-extended-pings.html

Recently I happened upon a great post at http://www.netcontractor.pl/blog/ that provides a JPG with more complete examples of various DSCP, tos, IP precedence, etc. values.  The latest version current appears at http://www.netcontractor.pl/blog/?p=1161.  Thank you to Netcontractor.pl for putting that together.

Here is their current v3 chart:

Below is the body of my post showing how to use the Cisco IOS ping command to tag ICMP traffic with various markings.  Using the TOS values from the table above you should be able to emulate just about any traffic type for QoS class map testing:

QoS conversions for extended pings sample

To emulate DSCP tagged traffic:

ef = dscp 46 = 101110 = tos 0xb8 (184) = ip prec 5
af31 = dscp 26 = 011010 = tos 0x68 (104) = ip prec 3
af32 = dscp 28 = 011100 = tos 0x70 (112) = ip prec 3
cs3 = dscp 24 = 011000 = tos 0x60 (96) = ip prec 3

voice_gw#ping ip
Target IP address: 10.10.10.1
Repeat count [5]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 10.20.10.1
Type of service [0]: 184 --->dscp is ef
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.

A simple way to calculate is to put your binary representation of the value into your calculator and add two zeros to the end (i.e. 101110 becomes 10111000).

If you are looking to emulate IP Precedence values, use 224,192,160,128,96,64,32,0 for IPP 7 to 0

Cisco SNR / Mobility / Single Number Reach How To

Here's a little text file I've had on my desktop for awhile.  Just cleaning laptop house... 

SNR Notes:

1. Create / find an end user and associate his deskphone
1. user needs to control device on user page
2. device needs to be owned by user on device page
2. Configure Remote Destination Profile
1. Device->Device Settings-> Remote Destination Profile
2. Make sure your remote destination number (i.e. your Mobile number) matches a Route pattern going to your Gateway
3. Make sure the Re-routing CSS has the access to the Route pattern to successfully route the call to your mobile numbe
3. Associate the line number to your desk phone extension
4. Configure Remote Destination
1. Device->Remote Destination
2. Make sure you check Mobile phone and enable Mobile connect.
3. Associate it with the Remote Destination Profile
5. Add Mobility to softkey template

VMware Deploy OVF from datastore URL

VMware Deploy OVF from datastore URL

When building new servers on Cisco UCS BE6K / BE7K chassis, you likely have all the OVAs you need already on the datastore(s). My problem is I never remember the HTP URL syntax to use to point the "Deploy OVF Template" dialog back to the datastore.  I typically end up downloading the OVA to my loccal PC and then uploading it again via the dialog because you can simply browse file your file share for the file.  You can enter a URL instead to save the hassle but what is it?

I don't know.

Here's a nice VMware document on the syntax but in the time it takes to figure it out, you could have been down my silly upload / download way: https://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.wssdk.pg.doc%2FPG_Appx_Http_Access.21.3.html

Try this instead:

• Open a browser and navigate to http://your_ESXi_interface/folder. 
• You'll be challenged for a user that has access to the ESXi environment.
• Enter the credentials and you should be able to drill down to the file you are looking for, right in your browser.
• When you find the one you want, right click and Copy Link Location (in Firefox, or the equivalent in your browser).
• Return to the "Deploy OVF Template" dialog box and paste.

Yeah. Easy giant URL.

Basic Cisco 1252 AP WPA2 Personal AES CCMP Least Congested Channel Sample

After a lightning strike at the house, I've been running a SOHO Linksys WiFi router for some time.  I'm giving up on it and converting back to some more "enterprise-y" network hardware.  Here's a quick Cisco 1252 AP configuration. This is similar to a post of mine from a year or two ago, but now includes the option for the AP to pick the least congested channel from 1, 6 or 11.

ap#
ap#sh run
Building configuration...

Current configuration : 1318 bytes
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname ap
!
enable secret 5 $1$cHI9$4dS0I6b8A3Rp3ecMQ2H6i1
!
no aaa new-model
!
!
!
dot11 ssid LauraAndRay
   authentication open
   authentication key-management wpa version 2
   guest-mode
   mbssid guest-mode
   wpa-psk ascii 7 1403170F070B30222A3B383C73
!
power inline negotiation prestandard source
!
!
username Cisco password 7 062506324F41
!
bridge irb
!
!
interface Dot11Radio0
 no ip address
 no ip route-cache
 !
 encryption mode ciphers aes-ccm
 !
 ssid LauraAndRay
 !
 channel least-congested 2412 2437 2462
 station-role root
 bridge-group 1
 bridge-group 1 subscriber-loop-control
 bridge-group 1 block-unknown-source
 no bridge-group 1 source-learning
 no bridge-group 1 unicast-flooding
 bridge-group 1 spanning-disabled
!
interface GigabitEthernet0
 no ip address
 no ip route-cache
 duplex auto
 speed auto
 bridge-group 1
 no bridge-group 1 source-learning
 bridge-group 1 spanning-disabled
!
interface BVI1
 ip address 192.168.10.253 255.255.255.0
 no ip route-cache
!
ip http server
no ip http secure-server
ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag
bridge 1 route ip
!
!
!
line con 0
line vty 0 4
 login local
!
end

Excel functions for CUCM BAT

I'm just going to put MS Excel functions here that I use when creating CUCM and Unity Connection BAT files. Thanks for stopping by..


Show everything in A1 to the left of a space (or other delimiter)
=LEFT(A1,FIND(" ",A1)-1) 

Show everything in A1 to the right of a space (or other delimiter)
=MID(A1,FIND(" ",A1)+1,255) 
 

Cisco 8845 Intelligent Proximity Bluetooth Mobile Voice

An introduction to the intelligent proximity feature on the Cisco 8845 phone:

For reference, during this video I’m using a Cisco 8845 phone running firmware version 10-3-2-16, the latest available at this time.  The device is registered to a Cisco Unified Communications Manager running 10.5.2.10000-5.  There is a Cisco Expressway Edge and Core server between the phone and Communications Manager, a deployment model commonly referred to as Mobile Remote Access.  I’ll also be using an Apple iPhone 5S with no special apps or configuration.

From a Communications Manager administrative perspective, the setup is simple and the two required variables are normally already set by default. On the the 8845 device, first find the “Bluetooth” setting and confirm it’s enabled.  Then just a bit below that, verify “Allow Bluetooth Mobile Handsfree Mode” is enabled as well.

CUCM version 10.5.2.10000-5

CP-8845 firmware 10-3-2-16

CP-8845 Bluetooth settings

From a user perspective, you’ll be required to pair the iPhone with the Cisco 8845 phone. 

On the iPhone, select your settings app, then Bluetooth and if it’s not already on, turn it on now.

On the Cisco 8845 phone, select the application button, and scroll over or press the digit 3 to the select the Bluetooth menu.  First highlight “Bluetooth” and turn it on, then select “Hands-free 2-way Audio” and turn that on.  The pairing communication should begin at this time.  Finally, on the Cisco 8845, select “Add Bluetooth device”.  You should see a splash screen that says “Make sure your device is discoverable”.  Wait a few moments while the devices communicate.

Once communication is established between the Cisco 8845 and the cell phone, you will see the name of your mobile phone in the 8845 display. Select the “Pair” option. 

If successful, you’ll receive a toast message on the 8845 with a Bluetooth verification code.  You’ll also receive a “Bluetooth Pairing Request” message on the iPhone.  Press “Yes” on the 8845 and “Pair” on the iPhone.

CP-8845 with Bluetooth On and paired iPhone

Next, on the 8845 you will be given the option to save your mobile phone contacts on your deskphone.  Choosing “Yes” here imports the contacts from your iPhone for use on your 8845 desk phone.

When complete, press “Exit” on the 8845 until you are returned to the idle display.

On the Cisco phone, you should now see a new line label with the name of your iPhone. Selecting the new line changes your “External Phone Number Mask” to that of your iPhone number and provides the iPhone battery status and cell coverage as well. Note that this pairing and line appearance does not display on the Device in the Communications Manager administrative interface.

Making calls from your iPhone:

While your phones are paired, when calling from your cell phone, you will now be presented with the option to use the “CP-8845”, the “iPhone” or the “Speaker”.  The “iPhone” and “Speaker” options represent standard iPhone functions where you are selecting whether to send and receive audio through the standard iPhone ear and mouthpiece or via the iPhone speakerphone.  Choosing the “CP-8845” option though now allows you to place the call over the iPhone cellular network but use your CP-8845 phone as the audio device.  You can use the 8845 handset, a headset if equipped, or the built in speakerphone.

iPhone making call with audio over CP-8845 speakerphone

Making calls from your 8845 phone:

While your phones are paired, when calling from your desk phone, you now have the option to dial from the 8845 phone and use the handset, headset or speakerphone there, but to place the call over your iPhone and it’s cellular network.  Simply first select the new iPhone line on the 8845 and then dial your number as if you are dialing on your iPhone.

If the call was placed via the 8845 over the cellular network, once the call is in progress, pressing the “Move Audio” button changes the audio sending and receiving from the 8845 phone back to the iPhone handset.  Conversely, while the call is in progress on the iPhone, pressing “Move Audio” on the 8845 phone makes the 8845 handset, headset or speakerphone the active audio device.

CP-8845 call over iPhone with Move Audio button

Using the iPhone directory:

You can now scroll through and dial iPhone contacts form you 8845 phone. If during the pairing process you chose to save your mobile phone contacts on your deskphone, you will have a new directory option there.  On the 8845 phone, press the Directories button, scroll to and select the new directory with the name of your iPhone.  You will be presented with a list of your iPhone contacts, can scroll through and call any of them using the “Call” softkey.

CP-8845 with iPhone contacts directory

Receiving calls from your iPhone:

While your phones are paired, when receiving calls on your iPhone, your iPhone still rings and presents information like normal.  Now though, the incoming call information on your iPhone will be presented on your 8845 phone display as well, associated with the new iPhone line created during the pairing.  You can answer the incoming call to the iPhone on the 8845 using the normal Cisco “Answer” softkey, the 8845 speaker button or of course by lifting the handset.

Once the call is answered and in progress on the 8845 phone, pressing the “Move Audio” button changes the audio sending and receiving from the 8845 phone back to the iPhone handset.  Conversely, while the call is in progress on the iPhone, pressing “Move Audio” on the 8845 phone makes the 8845 handset, headset or speakerphone the active audio device.

Takeaways:

• System Administration requires two settings per device, likely already set by default.
• User administration requires pairing your iPhone or other device with the 8845.
• Incoming calls to your cell phone can now be answered on your 8845 phone.
• Outgoing calls on your 8845 phone can be sent over the iPhone cellular network if desired.
• Once calls are in progress over the cellular network, you can toggle which device to use for audio by pressing the “Move Audio” softkey.
• Your iPhone contacts can be accessed and dialed from your 8845 deskphone.

Additional references:

Cisco Intelligent Proximity
http://www.cisco.com/c/en/us/products/collaboration-endpoints/intelligent-proximity.html

Cisco IP Phone 8800 Series User Guide
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/8800-series/english/userguide/P881_BK_CC6C5F2C_00_cisco-ip-phone-8800_series.html

Cisco IP Phone 8800 Series Administration Guide
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/8800-series/english/adminguide/P881_BK_C136782F_00_cisco-ip-phone-8800_series.html

VG224 VG310 VG320 SCCP configuration

I've been asked a couple time lately about SCCP on analog gateways.

On the CUCM side:

First, add the gateway in CUCM and pick the SCCP protocol.  Then, much like the host name is critical in MGCP setups, you'll need to identify it with the last 10 digits of the gateways interface MAC address.  Then, still in CUCM, add however many sub-units are in your gateways so you have ports to configure.

On the gateway side:

After you get basic network connectivity and access, the basic critical SCCP related commands are:
!
!
stcapp ccm-group 1
stcapp
!
! loopbacks are generally preferred here, but the physical interfaces will work
sccp local GigabitEthernet0/0
! 7.0+ is basically standard now but check your version here against your CUCM
sccp ccm <ip address of a CUCM,  subscriber if you have one> identifier 10 priority 1 version 7.0+
!
sccp ccm <ip address of another CUCM subscriber, if you have another in a CUCM group> identifier 20 priority 2 version 7.0+
!
sccp
!
sccp ccm group 1
 ! again, loopbacks are generally preferred here
 ! keep it consistent
 bind interface GigabitEthernet0/0
 associate ccm 10 priority 1
 associate ccm 20 priority 2
!
dial-peer group 1 pots
 service stcapp
 port all
!
! check if it's working
!
show sccp
show stcapp device summary

CUCM using SIP phones as PLAR or ring down lines

Customer using Cisco 8841 and 8851 phones wanted to use a particular button on several phones as ring down or PLAR lines.  The basic idea is after accessing a DN, rather than being returned dial tone you automatically call another number.  This is common in elevators, emergency phones, common areas, etc.

The steps below are found in various CUCM documents, but step 5 needs a bit of clarification.  Since the phones I was testing with are SIP based running sip88xx.10-3-1-20, you do indeed need to apply SIP dial rules to the phone devices, but configuring the rule takes one more bit of information. See my italics and pictures.  This technique that includes defining the button used as the PLAR seems to be required for multiple button Cisco 7800 and 8800 series phones.

Note: if you are using Cisco 3905 phones as ring down / PLAR devices, you do not and should not define the button in the SIP dial pattern. 

I've modified some of the other steps to hopefully help avoid confusion as well.


How to Configure Cisco multiple line SIP phones as PLAR / ring down phones

Step 1:
Create  a partition, for example, P1, and a calling search space, for example  CSS1, so CSS1 contains P1. (In Cisco Unified Communications Manager  Administration, choose Call Routing > Class of Control > Partition or Calling Search Space.)

Step 2:
Create  a null (blank) translation pattern, for example, TP1, in partition P1. In this null (blank)  pattern, make sure that you enter the directory number for the PLAR destination in the Called Party Transformation Mask field and that the translation pattern uses a CSS that has access to that destination. (In Cisco  Unified Communications Manager Administration, choose Call Routing > Translation Pattern.)

Step 3:
Assign the calling search space, CSS1, to either a device or line on a phone that will be dialing automatically. (In Cisco Unified Communications Manager Administration, choose Device > Phone.) 

Step 4:
For phones that are running SIP, create a SIP dial rule. (In Cisco Unified Communications Manager Administration, choose Call Routing > Dial Rules > SIP Dial Rules. Choose 7940_7960_OTHER. Enter a name for the pattern; for example, PLAR1. Click Save; then, click Add Plar. Click Save.) 

Here's the missing piece:  after you click Add Plar you must define what button number on the phone has the DN that is acting as the PLAR.  Leaving the PLAR default will show you a line with a blank pattern.  While this seems correct as it is similar to the blank translation pattern you created earlier, it will not work.

Here's a working SIP Dial rule:

The device where this will be applied will automatically dial when the fourth DN / button is accessed.

In addition, if you mistakenly choose Add Pattern rather than Add PLAR and make it look just like the above rule, your PLAR will still not work.

Here's a great looking SIP Dial rule that doesn't work:

Looks good, works badly.

Step 5:
For  phones that are running SIP, assign the SIP dial rule configuration  that you created for PLAR to the phones (In Cisco Unified Communications Manager Administration, choose  Device > Phone. Choose the SIP dial rule configuration from the SIP Dial Rules drop-down list box.)

FYI... here's another post of mine from years a ago reiterating the first several steps suitable for SCCP devices http://webmaxtor.blogspot.com/2011/05/cucm-ring-down-phone.html

Cisco CUCM weak ephemeral Diffie-Hellman public key

At the time of this writing, due to one or more SSL vulnerabilities that were discovered in CUCM’s web server you may suddenly be prevented from accessing the administrative interface. This is the result of various Internet browser upgrades attempting to protect you from these vulnerabilities but in the process, preventing access to the CUCM web pages.  The good news is because your CUCM servers are typically not exposed to remote users, the only threat would be from malicious users inside your network, and then only malicious users extremely knowledgeable in these vulnerabilities and possible exploits, and then only those literate in Cisco CUCM or other UC applications.   While compromises to your CUCM server's security may be unlikely, keeping up to date with software patches / upgrades is prudent.

Your new browser looking out for your best interests.

For your reference, Cisco publishes information re: security advisories here: http://tools.cisco.com/security/center/publicationListing.x

Google has decided to be rather unforgiving (maybe call it condescending?) and not even provide an interactive way for a Chrome user to opt out of their security measures.

The real fix is to upgrade / patch your systems to versions that rectify the vulnerabilities.

In the interim, there are workarounds for most browsers if you care to suggest your users go that route.

For Firefox (the one I use):
Navigate to about:config in the address bar.
Choose “I’ll be careful”
Search for security.ssl3.dhe_rsa_aes
Double click security.ssl3.dhe_rsa_aes_128_sha  and security.ssl3.dhe_rsa_aes_256_sha to change them to false.
Restart Firefox.

For Chrome (I haven’t tried this personally but is the commonly referenced workaround):
In MS Windows, right click on desktop and choose New | Shortcut
In the location field, including the double quotation marks enter "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --cipher-suite-blacklist=0x0039,0x0033
Choose Next and enter a name like “CUCM Chrome” and Finish.
You should be able to use that shortcut to start a version of Chrome access the CUCM interface.

Cisco Quality Manager 10.5 upgrade issues

I'm sharing several important lessons learned during a Cisco Quality Manager upgrade from 9.0.1.57 to 10.5 SR6, given they are not well documented.  I hope it saves you some time.

Quality Manager administrator access

In environments where you are using MS Active Directory to associate users with recorded devices you may find your self unable to login to the QM administrator's application after the upgrade.  The normal Quality Manager local admin user and password doesn't seem to work, and neither do the AD accounts you've used for logging in as administrators previously. If you are really motivated and change the model to use QM Authentication, the local QM administrator works but now your administrative AD access is gone. 

What to do?

Note there is a new field buried in the Enterprise | Site Configuration | Enterprise Settings form.  You need to actually select and choose to edit one of your Active Directory entries to see it.  Of course you can't do any of this unless you run postinstall.exe because of course, your locked out.

When you choose to edit an Active Directory entry, you will find a field called Admin Group. Mine contained the value QMAdministrator.  I don't know where that value came from because the Admin Group is now actually enforced and represents a MS Active Directory group that contains users that may or may not be Quality Manager system administrators.

First, find or create a AD group that contains your potential QM admins.  Enter the display name of the group in the QM Admin Group field.

Then, when choosing OK you will be presented with a grid of users from that AD group.  Choose one or more to become system admins.  See below.

You're in.

CUCM Recording Server SIP Trunk

If you are using Cisco Built In Bridge recording / Calabrio network recording you will already have a SIP trunk configured in CUCM, pointing to your recording server.  This trunk carries information from CUCM to Quality Manager regarding the DNs that need to be recorded, and from Quality Manager regarding what recording server to use.  There's the rub.  Previously the CUCM pointed the trunk to the Quality Manager recording server and no one thought about it. Of course, you would point it to the recording server because of course that's where the recording are going to go. Right?

Calabrio has changed the basic architecture in 10.5.  You now point the SIP trunk in CUCM to the Quality Manager Base server, not the recording server.  Before you correct this, you might dig around in the QM logs and find references to your QM not receiving SIP invites on the base server and be confused. Why would you need them there? 

Reset your CUCM trunk, start WireSharking stuff, reread all the install and upgrade guides you can find from Cisco's site. Freak out a little.

Then just point the trunk to the Quality Manager base server, rather than the record server where it's been pointing forever. 

See below.

Quality Manager VoIP Devices and Recording Cluster and Signaling Group

New programmatic entities in Quality Manager probably make in more scalable and manageable. New information under Enterprise | Site Configuration | Telephony Groups allow you to parse up and group different recording resources and signalling types.  This is great, but after the upgrade you will need to verify those values have been associated with your VoIP devices correctly.  My experience was that none of my devices had been associated with a Recording Cluster or Signaling Group at all.  That won't work.

Luckily, given all my devices need to be associated with the same Recording Cluster and Signaling Group, it's an easy edit of the entire list.  If your environment has multiple recorders, this might be a more painful process.

Go to Enterprise | Record Server Configuration | VoIP Devices and clean up your mess.

See below.

Enjoy your recordings again.

Cisco PLM Prime License Manager login hangs

I've run into an issue twice now on CUCM 10.5.2 systems.  When attempting to log into Cisco Prime License Manager running co-resident with a CUCM server, after entering the correct credentials the login page never changes.  The small spinning status wheel below the credentials stops but the browser may look like it is still attempting access.  You can't access PLM.

You may likely be hitting  bug CSCur95552.

For some reason, Cisco TAC has not documented any work around or fixes at this time.

If running co-resident with CUCM, you need regenerate the IPSec certificate on the node where Prime License Manager is running. Then if this is your CUCM Publisher, restart the DRF Master and DRF Local services. If it's not the Publisher, just restart the DRF Local services.

You should then be able to login.

Regenerate Certificate:
Navigate to Cisco Unified OS Administration | Securtiy | Certificate Management and choose Find.
Scroll down to and choose the ipsec certificate associated with the server where PLM is running co-resident.

Choose Regenerate and wait a few moments until it indicates success.

Restart Services:
Navigate to Cisco Unified Serviceability | Tools | Control Center - Network Services.
Pick the server where PLM is running co-resident and choose Go.
Scroll to and choose Cisco DRF Master, click Restart, and wait until it has been restarted.
Scroll to and choose Cisco DRF Local, click Restart, and wait until it has been restarted.

You should now be able to log into PLM.

Restart Tomcat:
If you experience the same issue, restart Tomcat on the same server and repeat the above steps.
SSH to or open VMware console on server where PLM is co-resident.
Login as the platform administrator.
run "utils service restart Cisco Tomcat"

Cisco CUCM SIP URI Case Sensitive

Client indicated after starting to deploy B2B video, Jabber Guest, immersive telepresence endpoints, etc. that they were occasionally running into issues when dialing via SIP URI.  It was discovered that the entries in MS Active Directory may not have been consistently entered as lower case.  Some may have been entered using camel case, and I assume some may all be upper case as well.  When CUCM synchronized it's users with Active Directory, those cases were respected.

From the version 9 SRND, you will find:

Per RFC 3261 (section 19.1.4, URI Comparison) comparison of the userinfo of SIP URIs has to be case-sensitive. According to this standardized behaviors, Alice@cisco.com and alice@cisco.com are not to be considered equivalent. When routing directory URIs, Unified CM respects this standard and looks for a case-sensitive full match of the user portion and a case-insensitive match of the host portion. To avoid confusion, Cisco highly recommends provisioning only directory URIs with all lowercase userinfo so that all directory URIs can reliably be dialed by entering all lowercase information. Unified CM 9.1 and later releases can be configured to always use case-insensitive comparison of the user info portion of directory URIs. This can be achieved by configuring the enterprise parameter URI Lookup Policy accordingly. This setting applies to matching locally configured directory URIs and also to matching directory URIs for which an ILS lookup is done. The default setting of this enterprise parameter defines standard compliant case-sensitive matching of the user info portion of directory URIs.

Cisco is apparently doing the correct thing by considering Me@abc.com and me@abc.com two different things.  Unfortunately I can't imagine anyone in the wild assuming the same thing.  Regardless of whether an enterprise was lucky enough to develop and follow a procedure where all mail IDs or SIP URIs were entered with a consistent case, lower, upper or camel, they can not assume their users or clients will do the same.

With that, starting in version 9 there is an enterprise parameter that will toggle how lookups are done.

Navigate to System | Enterprise Parameters and in the Enterprise Parameters Configuration section, find URI Lookup Policy.

URI Lookup Policy

Change the value to Case Insensitive and the issue is resolved.  This is not business impacting and no resets are required.

From the help file:

This parameter specifies the way the match is done for the configured user part of the URIs in Cisco Unified Call Manager. If the parameter is set to Case Sensitive, we will match the exact case sensitive URI configured in Cisco Unified CM. If the parameter is set to Case Insensitive, then case insensitive lookup will be done.


 

Unity Connection Changing The From Name in Single Inbox / Unified Messaging

While performing a upgrade of CUCM 7 and Unity 7 to CUCM 10.5 and Unity Connection 10.5, the client pointed out an interesting difference in how voice mails were presented in the Outlook client.  When receiving a message from the old Unity system, Outlook showed the client's company name in the From: column when the caller was unidentified.  Unity provided variables to modify this field. When voice mails were received from the new Unity Connection system the From: column shows Cisco Unity Connection Messaging System.  No where in Unity Connection can this be obviously changed.

The name Cisco Unity Connection Messaging System is actually the display name for the user with the alias UnityConnection.  Unfortunately, it does not appear to be editable via the GUI.
 

If you are brave enough, it can be modified via CLI.  I do not know if it is officially supported, but it is technically.

From the CLI you can execute the following to see the user in question:
run cuc dbquery unitydirdb select displayname,objectid from tbl_user where displayname = 'Cisco Unity Connection Messaging System'

You should be returned something like:
displayname                              objectid
---------------------------------------  ------------------------------------ C
Cisco Unity Connection Messaging System  aeb80eab-1ec0-4add-8d4f-f29396639324

Then, cross your fingers and execute the following.  Here for example I am changing the name to The ABC Company:
run cuc dbquery unitydirdb update tbl_user set displayname = 'The ABC Company' where displayname = 'Cisco Unity Connection Messaging System'

In the GUI you will find the UnityConnection user's display name is now changed to the company name, here for example, The ABC Company.  Messages will still show From:Cisco Unity Connection Messaging System though.

I don't know what service(s) restart commits the change, but I had the luxury of rebooting the entire server.  After that, the From: address in UM does show the new name you defined.

Dial IP addresses from Cisco TelePresence endpoints registered to Cisco CUCM

HowTo: Support dialing IP addresses from Cisco TelePresence endpoints registered to CUCM to reach external H.323 video endpoints 

Information here is a compilation of that found in”Cisco Unified Communications Manager with Cisco VCS (SIP Trunk)Deployment Guide”, various http://supportforums.cisco.com discussions and a most excellent http://www.ucguerrilla.com post.  Note William Bell is the brain behind the ip@ prefix and what follows is my personal interpretation and experience in the wild.Screen shots are actual client configurations in production as of 4/2/2015.

Call flow was tested via a Cisco MX200 TelePresence endpoint registered to CUCM 9.1.2. Calls to external H.323 video endpoints dialed via IP address were sent from CUCM to Expressway 8.5.1 C and E, already providing B2B video calling via SIP URIs. External auto-answering H.323 and SIP video endpoints were called for testing purposes without permission and those IP addresses are not included here.

Background:

Video calling between endpoints registered to CUCM internally and B2B via Expressway was already in production.  Users were accustomed to dialing via SIP URI, like joe.smith@mycompany.net or john.smith@anothercompany.com.

Previously, B2B H.323 video calls were made from Polycom endpoints by dialing public IP addresses. As these older existing Polycom video endpoints were retired and replaced by Cisco video endpoints registered to CUCM, the ability to continue to dial external H.323 devices by IP address was required.

Issues:

 

Although the process of physically dialing IP addresses from Cisco TelePresence Touch (or other) interfaces is no more difficult than dialing SIP URIs, at this time CUCM does not support simply dialing IP addresses.

Cisco’s VCS deployment guide suggests the solution is to define a dialing access code specific to video calls, for example the digit 8. Then you are to instruct the users to dial 8 plus a string of twelve digits to represent the IP address they want to call, where leading zeros are to be added to each octet where necessary and the dots ignored.  For example, users accustomed to dialing 10.100.1.10 on a Polycom would now be required to convert the IP address and dial 8010100001010 from the new Cisco video endpoints.  This is not an acceptable solution.

Solution: 

Configure CUCM and Expressway C and E to support dialing IP addresses using the format ip@.  For clarity, where a user would previously dial 10.100.1.10 from a Polycom device, they would now dial ip@10.100.1.10 from the Cisco device.  The ip@ are literal characters to be dialed prefacing the IP address, but otherwise the IP address portion itself continues to look like and be dialed like an IP address.

Simply:

1. CUCM will accept a call dialed with a SIP URI format like ip@10.100.1.10 and route it to Expressway C.
2. Expressway C will accept the call in the ip@10.100.1.10:5060 format (or ip@10.100.1.10:5061), strip the ip@ and :5060 portions of the number and pass the remaining portion of the address, now looking like an IP address, to Expressway E.
3. Expressway E will not attempt a DNS lookup on the address and will support SIP to H.323 conversions.

Configuration steps:

 

CUCM:

 

Navigate to Call Routing | SIP Route Pattern and add a route pattern that matches your destination video device IP address.  Verify the pattern is for IPAddress Routing and note the address can either be an exact match, or reflect a network address in the X.X.X.X/Y format.  The Sip Trunk / Route List should reflect a SIP trunk between CUCM and Expressway C.  

This is how calls placed from a CUCM registered endpoint to a SIP URI with an IP address rather than domain name (i.e. ip@10.100.1.10) are routed to Expressway C.

An example of a specific IP address being routed to a SIP trunk called ExpresswayCore-SIP-Trunk is below.  This was used for initial testing purposes. Do NOT use this IP address for your own tests.

Again, rather than creating a SIP Route Pattern for every public endpoint you need to contact, you can add addresses in the X.X.X.X/Y IP address and subnet mask format.  Unfortunately CUCM does not accept 0.0.0.0 as an IP address.  This means a single entry similar to an IP default route found in other Cisco IOS based devices doesn’t seem possible.  One work around is dividing the entire IPv4 space into two subnets, 1.0.0.0/1 and 128.0.0.1/1.  It is working successfully at this time.

Expressway C:

Navigate to Configuration | Dial Plan | Transforms and add a new transformation.  The type needs to be RegEx, the pattern string ip@(.*)(:506[01]) and the replace string \1.

Via the RegEx replacement, this transform is responsible for replacing the SIP URI presented by CUCM (i.e. ip@10.100.1.10:5060) with a string resembling simply an IP address (i.e. 10.100.1.10).

Below is the actual configured transform.  It is important to set the priority number so that it does not break any other calling.  Here the transform worked safely with the highest priority value (last to be matched).

Navigate to Configuration| Dial Plan | Search Rule, and add a rule with a Mode that matches Any IP Address.  The target should be a Traversal Zone that passes the call to Expressway E.  This how the string that now looks like an IP address (i.e. 10.100.1.10) gets routed to Expressway E.

Below is the actual search rule added, targeting a Traversal Zone called Traversal B2B that was already supporting B2B video calling vial SIP URIs.

Navigate to Configuration | Dial Plan | Configuration and verify Calls to unknown IP addresses are set to Indirect.  I don’t have a picture here, but it is the only option on the page and will likely not need to be changed. 

Expressway E:  

Navigate to Configuration | Dial Plan | Configuration and verify Calls to unknown IP addresses are set to Direct.

This routes calls to IP addresses directly to the destination on the Internet without attempting DNS lookups. 

Navigate to Configuration | Protocols and verify both SIP and H.323 protocols are enabled.  These are two basic settings required to support SIP calls from CUCM / Expressway C and H.323 calls to external endpoints.

Navigate to Configuration | Protocols | Interworking and enable SIP to H.323 internetworking. I don’t have a picture here but it is again the only option on the page and is likely default.  This provides support for your call being generated by a Cisco SIP based TelePresence endpoint to communicate with the target H.323 endpoint.

  

Notes 

• On Cisco Telepresence endpoints, users will need to be instructed to dial ip@ in front of the IP address the intend to call.
• The event logs in Expressway C and E are relatively easy to use and decipher. If B2B video calling is in production, once you add your CUCM SIP Route Pattern, look to the Expressway C and then E for troubleshooting.

Log Example 1: Here is Expressway C rejecting a call from a device at 7902@mycompany.net, my test MX200 registered to the CUCM at 10.181.1.8.  The destination IP address is 76.74.100.40.  The 404 response code was a result of the Expressway C missing the search rule designed to route IP addresses to Expressway E via the Traversal Zone.

Log Example 2: Here is Expressway C reporting a 480 response to an attempt to reach 66.135.98.168.  The lesson here is when making test calls to endpoints by IP address, first verify the IP address in question actually points to a working video endpoint. This one didn’t.

Log Example 3: Here is Expressway E reporting the destination 76.74.100.40 can’t be found.  This indicates the call has made it all the way from the CUCM endpoint, to CUCM, to Expressway C and to Expressway E and looks like an IP address.  We know this is a working endpoint though.  The issue was the Calls to unknown IP addresses value was not set to Direct.