Voice Elements and Cisco CUCM 7

Had an interesting engagement trying to get a Voice Elements IVR platform to use a Cisco CUCM 7 server as the connection to the PSTN.

The plan was to accept incoming calls via PRI(s) registered to the Cisco CUCM server, and pass the caller to the Voice Element server to be answered by home grown IVRs.  The Voice Elements server will also be hosting applications that generate outbound campaigns, signalling CUCM to pass the call to the PSTN.

The Voice Elements set up is fairly basic, requiring defining the IP address and port on which the Voice Elements server software will listen for incoming SIP traffic, and the IP address and port that Voice Elements will use to send traffic to.

You can find the details here: http://support.voiceelements.com/index.php?title=How_do_I_connect_to_my_SIP_Carrier.

The only significant change to the CUCM server was a requirement to use UDP as the transport.  At least on CUCM version 7, it appears that the default is TCP.

You can modify that via System | Security Profile | SIP Trunk Security Profile.

I suggest making a copy of the default profile, modifying the Outgoing Transport Type, and applying it to the trunk.

Here's a screenshot of my working config.

If you need any additional details, let me know.

Cisco Unity 8 license inconsistency between servers

Customer running Cisco Unity 8 with servers in three locations using digital networking.  Found the license counts on each server were not the same and although licenses were available in the pool, subscribers could not be added at one site.

You may find errors re: "Stale license pool data" and / or communication failures with AD or global catalog servers.

See https://supportforums.cisco.com/docs/DOC-3967

The fix was running DOHPropTest and performing total resyncs.

1. Open DohPropTest.exe from \commserver\techtools\.  The tool is available from the Unity Tools Depot as well and appears to execute the same application.
2. Choose OK but do not enter the password.  This runs DOHPropTest in "read only" mode, which is rather comforting given what I've seen you can do if you actually provide a password.
3. Choose ignore to password check.
4. Choose AD Monitor, and choose TotalResync. Close the window.
5. Choose GC Monitor, and choose TotalResync. Close the window.

There are some links that indicate this can be business impacting and should be done in a maintenace window, however my experience indicates your results may vary.  It took only seconds to complete (can verify in MS Event Viewer) and there was no indication users were impacted (approximately 500 users accross three servers).

Cisco UCCX IPPA clients slow or unable to log in or go ready - requesting or XML Parse Error

After some power outages in a data center hosting a Cisco UC enviroment, users using Cisco IP Phone Agent (IPPA) indicated they recieved only a "requesting" message in the phone display when attempting to log in or go ready.  If a user was able to get to a state where they were taking calls, they also reported seeing XML (4) Parse Error intermittantly between calls.

The users were equipped with IPPA and "one button login" only, but some remote testing using the CAD fat client indicated users could log in immediately if not already logged in.

The short story fix was restarting some services on CUCM and UCCX.  I would suggest using stop and start commands rather than restart commands and do them in this order.

Stop CTI Manager on CUCM Pub
Stop CTI Manager on CUCM Sub
Start CTI Manager on CUCM Pub
Start CTI Manager on CUCM Sub
Stop Cisco Tomcat on CUCM Pub (via CLI only with utils service stop Cisco Tomcat)
Stop Cisco Tomcat on CUCM Sub
Start Cisco Tomcat on CUCM Pub (via CLI only with utils service start Cisco Tomcat)
Start Cisco Tomcat on CUCM Sub
Stop IPPA service on UCCX
Start IPPA service on UCCX


Note: there were only two CUCM servers and one UCCX server deployed.

Note:  This process will be business impacting in this scenario.  CUCM CTI Manager is responsible for applications using JTAPI (and TAPI) so UCCX will out of order at this point.  The UCCX IPPA service handles requests for agents using IPPA so you'll likely be logging agents out at this point.

Cisco CME CUCME "MAC address is already assigned with ephone" and DECEASED state

Customer complained that a Cisco 7941 on the CME would occasionally drop calls and reboot, also interupting pass-thru data connectivity.

After testing the physical layer between the phone and CME, we decided to replace the device with a spare as the original showed evidence of being treated with some disrespect.

It seems the method to do so would be to modify the MAC address in the ephone configuration, but of course that's more difficult than should be.

; let's get rid off the configuration related to the replacement phone
CME(config)#no ephone 24

; let's put the mac address of the replacement phone in the 
; ephone configuration of the faulty phone 
CME(config)#ephone  17 
CME(config-ephone)#mac-address 0011.2B2B.B9B9
;  be startled that you can't do this
MAC address is already assigned with ephone 24.
Can not assign same MAC address with mutilple ephone.

Ultimately what seemed to work was re-configuring ephone 24 with a dummy MAC, and then configuring ephone 17.

CME(config)#ephone  24 
CME(config-ephone)#mac-address aaaa.bbbb.cccc
CME(config)#ephone  17 
CME(config-ephone)#mac-address 0011.2B2B.B9B9

Now, to confuse the issue, the replacement device now registered as ephone 17 exhibits the same disconnect and reset symptom.  When running show ephone, the state of ephone-17 shows DECEASED.  That looks bad.

The official description of that state is:

The Cisco Unified IP phone is active and registered. Alternative states are UNREGISTERED (indicating that the connection to the Cisco Unified IP phone was closed in a normal manner) and DECEASED (indicating that the connection to the Cisco Unified IP phone was closed because of a keepalive timeout). 

With that, if the keepalive attempts are timing out it still seems there may be a network issue.  Given the cabling was tested, and the switch configuration simplicity and lack of errors, I doubt it, but we'll see.

As a test, I now removed any evidence of ephone 17 and ephone 24, created a new ephone 25 with the MAC address of the replacement phone, re-created the cnf files under telephony-services, and am monitoring the situation.