Sometimes administrators have to block calls harassing, scam, or other undesirable calls. In newer versions of CUCM, this can be done in CUCM, or it can be done on an h.323 or SIP gateway.
Which should you use? There are good reasons to use both. Blocking on CUCM centralizes call routing, so you don’t need to touch gateways, and can be configured so that placing a number in once blocks it at all gateways. Blocking it at the gateway can be easier to implement, and stops the call at the ingress, so that no internal resources are ever used. Properly configured, blocking at the gateway will maintain protection in SRST, as well. So either way has benefits, use the one that fits into the existing environment best.
Blocking on the gateway uses translation profiles, which can be applied to the ingress port, and the inbound or outbound dial peers. Placing the blocking patterns on the port stops them right away, but may require placement on multiple ports. Continue reading
Have you ever wanted to do any of the following from a Contact Center application?
- Read a schedule from a local document, rather than having to use script editor to edit schedules
- Be able to load a schedule from a web server, so you didn’t even need to touch you CCX server
- Bring in external data without UCCX Premium
- Bring in external data from a database there isn’t a driver for
All these and more can be done by reading XML formatted data either stored in the local repository, or served from an external web server, and retrieved using the Create URL Document or Make REST Call steps. Since you are able to read from a web server, any web programing language, like PHP, ASP, or JSP, could be used to retrieve and format the data.
Once UCCX has the XML formatted data, the Get XML Document Data step uses the XPath syntax to get data out of the document. This is a powerful syntax for reading data from XML formatted documents, as we will explore here.
In this post, we will use the Make REST Call step to retrieve information from the REST interface on the UCCX server, which provides easy access to a remote source of XML formatted data. Continue reading
I recently had the opportunity to pick up a couple of 8861s for my lab/home phones, and thought I would do a writeup on my initial impressions. The 8800 series phones offer an updated look, and a number of new features.
The 8800 series also continues the move from soft keys to more hard keys, with hard Back, End Call, Hold, Transfer, and Conference keys added to the Voicemail, Settings (now combined with services), Directories, Headset, Speaker, and Mute buttons on the 7900 series. I don’t know how I feel about the move to more hard keys. Soft keys have the advantage that only the necessary ones are displayed, but sometimes important ones can get buried. Hard keys will also have an advantage when using apps like IP Phone Agent, since the call control soft keys are hidden by the application soft keys.
Also, in keeping with the new Cisco phone lines, they are SIP only, no option for SCCP.
Time of Day routing allows for calls to be treated differently based on the time of day and day of week. This allows for things like automatically rerouting calls to a different destination when the company is closed, not allowing PSTN calls after hours, or requiring a Forced Authorization Code outside of business hours. Another real-world example I have worked with is patient rooms in hospitals, which should not receive outside calls at night.
CUCM uses the standard Partitions and Calling Search Spaces, with the addition of a Time Schedule that specifies when the Partitions will be active, to perform time of day routing. Outside the time schedule, the partition is effectively invisible to call routing. Appropriate ordering of in a CSS allows the calls to be routed to an alternate number when the partition is not available.
An important consideration in designing the Partitions and CSSs is whether you want calls to be able to route to the phone off hours at all. For instance, with the patient room example, should internal numbers be able to call the rooms, and only outside calls be blocked? We will look at two examples, one that allows for some calls to go through, one that does not.
With the upgrade to Cisco UC 10, Enterprise License Manager (ELM) is “replaced” with Prime License Manager (PLM.) This is really just a rebranding of the existing ELM, although there are a few differences.
There is a standalone PLM OVA and ISO to install PLM. in 9.x, you installed a standalone ELM server from the UCM install media, and used the smallest OVA to create the virtual machine. PLM uses an even lighter footprint OVA, and has it’s own install media.
PLM is also installs co-resident with CUCM and Unity Connection. Unfortunately, it still installs automatically on every CUCM/UConn server you install. I would like to see an option so you can enable/disable PLM when you install the server, or at least only install on the publisher.
PLM 10 supports both version 9 and 10 licenses. To support version 10 licenses in ELM 9.x, you need to install a COP file (elm_LicenseDef_9_1_v1.cop.sgn) to allow ELM 9.x to recognize the version 10 licenses.
Here is more information on ELM.
Sometimes it is necessary to have a phone dial a preset destination any time it goes off hook. This is common in lobby phones, or the push button intercoms used on doors and gates. This configuration is called Private Line Automatic Ringdown, or PLAR. The way Cisco has handled this is to have you create a calling search space (CSS) that contains a single partition that contains an empty translation pattern with the called party mask set to the destination you want the phone to ring to. While this works fine, it can require a huge number of partitions and calling search spaces if you need to configure a lot of PLAR phones.
Starting with CUCM 8, there is is a feature that allows you to achieve this with only 2 partitions and Calling Search Spaces, plus translations, no matter how many source/destination sets you have. This significantly reduces complexity and the likelihood of error. A configuration example follows. Continue reading
In previous posts, we have looked at setting up the queues, skills, and agents for an ACD (Automatic Call Distribution) call center. In this post, we will take a look at setting up a very basic queuing script from a template, and creating an application to use it.
I recently ran into a situation where agents in a call center that had a Work timer and reason codes enabled where going into Not Ready with a system reason code: 32758 (Work Timer Expired).
The agents and queue were configured so that the agents would become available again after the work timer, and the majority of the time they were. What we discovered, with TACs help was that these were instances of a non-ACD call in or out to the agent phone being active when the work timer expires.
The agent states in a normal scenario would be as follows: The agent is in a Ready state, a call is presented, and they go into the Reserved state while the phone is ringing. Once the call is answered, they go into the Talking state, followed by the Work state when they hang up, and the 10 seconds later they go into the Ready state.
In the cases where we were seeing “Work Timer Expired,” the agent starts in a Ready state, goes through the reserved and talking states as above, and Work when they hang up. Then they either place an outbound call or receive a call directly to their extension, not through UCCX. Once the work timer expires, they are placed in the Not Ready (Work Timer Expired) state for the duration of the non-ACD call, and when that call is completed, they are returned to the Ready state.
In short, assuming the agent and queue are correctly configured with Auto Available, the 32758 (Work Timer Expired) reason code should be read as equivalent to the non-ACD Call reason code.
Check out my other UCCX posts.
Deploying Unified Communications Manager to geographically diverse sites adds a number of challenges not experienced in single-site deployments. The primary new challenges are:
- Bandwidth usage and call quality over WAN links
- Availability during WAN outages
- Call routing to the PSTN, especially for emergency numbers
- Potential for overlapping dial plans
After the cut, we will take a brief look at each of these issues, and some ways to to overcome them.
Local Route Groups were introduced in CUCM 7 as a cleaner way to configure PSTN routing for multiple sites. Prior to Local Route Groups, the only way to route calls out a local gateway was to configure a partition for each site, and configure the various PSTN patterns in each one. With local route groups, you can tie a route group to a device pool, and then send route patterns to a route list that includes the “Standard Local Route Group.” Calls matching that pattern will then use the local route group configured for their device pool.
Configuration example after the cut.