Cisco Unity Connection Call Handlers

Admin

Cisco Unity Connection Call Handlers

Call Handlers are a very good way to implement simple call flows. For more complex call flows and IVR’s;
CUC is definitely not the place. CUC is the place to set up call flows for extension that require an automated
open/closed greeting for instance for reception numbers. This is exactly what I will elaborate on in this post.

There are a few steps that will need to be taken in order to have a functional open/closed call handler:

Set up a holiday schedule

Set up a schedule for the business hours

Set up a call handler

set up a CTI Route point to direct CUCM to CUC

Set up a direct routing rule.

Back to my example, I want to set up a call handler with extension 100 that will do an open and closed, as well
as holiday check and if open will send the call to (in this case) an attendant console Q.

1.Set up a holiday schedule

This schedule will be checked by the call handler to see if the holiday greeting needs to be played to the caller.

As you can see the holiday schedule is comprised of different elements, each representing a holiday. The
schedule can span multiple years, its a bit tedious to put them in, but I suggest you populate a couple of years,
so you’re done with it.

2.Set up a Time of day schedule

As you can see below, I have set the business hours to be mon-sat 8am to 6 pm.

This schedule represents the times when the handler should invoke the “open” action, i.e. forward the
incoming call to the attendant console Q.

After these two schedules have been defined, when an incoming call hits the x100 call handler and if it is
outside of the holiday schedule and outside of the business hours, the closed greeting will be played.

3. Set up a call handler

After all the prep work of steps 1 and 2, you can now start configuring the call handler; a system call handler
to be more exact. You will see a bunch of other pre-populated system call handlers as well, dont worry about
those. Also I have created a greeting administrator call handler, more about this in my next post.

OK, so now I will drill into this call handler with extension 100 (not depicted above). Below is a screen shot of
the x100 call handler that I will use for this example.
As you can see the extension for this call handler is set to 100. The active schedule is set to the one reflected in
step 2.

Now go into the greetings section of the particular call handler (see below)

As you can see, this shows the various greetings applicable to the call handler and their action in the case
where they are triggered.

The closed, holiday and standard greeting should all be enabled. The alternate greeting overwrites all of these
in case it gets enabled (for instance through the greeting administrator). This alternate greeting could be
particularly handy in cases were for instance the building is evacuated, or the reception is unavailable for
other reasons.

Now, the standard greeting is the one that is invoked when the Time of Day schedule is open, because on
those times the receptionist is available.

The way this is done is by transferring the call after the greeting to another call handler. As you can see the
call handler that I have filled in here, is the same as the one in which we already are, and you would think that
I have just created a loop and it would never arrive at the attendant console Q this way. However, I have also
put in a Transfer rule in this call handler

As you can see, once the standard greeting get hit in our x100 call handler, it will transfer the call to extension
105, which is the reception Q on the attendant console for this particular branch.

It would make much sense to do anything else but transfer the call to another extension during business
hours, but then again there are many different scenarios and requirements possible. This I guess is the most
obvious one

4. Set up a CTI route point to connect CUCM to CUC

Up to this point you still will not be able to dial into your call handler to test it from any phone on your
cluster.

I will not spent much time on this but, you can use a CTI Routepoint that has the extension of your call
handler and point it to your CTI ports that are used for your voice mail system (do a forward all to VM on the
CTI RP)

You can also configure a hunt pilot and let it hunt the voice mail ports (the way I always do it,so you can
incorporate so mechanism of fail over in case your CUC server falls over)

5. Set up a direct routing rule

and still at this point you will not be able to dial into your handler. This because by now the call will land on
CUC, but it has no idea what to do with the call and what call handler to invoke. A direct routing rule fixes
this. As can be seen from the screenshot below, there is a direct routing rule for dialed number 100.

If we drill into the particular routing rule for dialed number 100, we can see the following:

This sends an incoming call to the appropriate call handler (the one that I have discussed previously), and
choose “Go directly to greetings”

the condition to do this is as follows:

with this, you should now be able to test your call handler