Unity 5.0 attempt transfer not ringing phones

Unanswered Question

I have Unified Communications Manager (Call Manager 6.0) and Unity 5.0 servers. I set up an auto attendant call hander with caller input option 1 to go to a directory handler and option 2 and 3 to go to call handlers. These last to call handlers are each assigned an extension linked to a hunt pilot. When I call these call handlers directly, the phones ring and if there is no answer Unity takes over and processes the call handler. If I call the auto attendant and choose option 2 or 3 it goes directly to the greeting for the call handler without ringing the phones in the associated hunt pilot. The convesation is set to attempt transfer not send to greeting. I have worked with TAC and they say it is properly configured but they can not determine a resolution. I saw a previous post in July regarding setting up a blank greeting and directing it to the same call handler. There was not enough details in the post for me to set this up. Any suggestions? Thanks

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)

I did work several more times with TAC and have somehow resolved the issue. The following is what they sent to me. When they were done with the configuration, nothing worked on my system. I actually undid all the alternate greetings and then everything worked properly. I think that the call control has been shifted to UC Manager rather than Unity and that may be what solved by issue. Mine is for a lab setup with only one Unity and one UC Manager server.

"First Available Extension (Simple Hunt Group Unity)

In some scenarios, it is handy to try a series of extensions until you find one that is not busy (for instance, a group of extensions for handling incoming sales or support calls). Normally, this is best done by the phone switch itself, which most often has more sophisticated and cost-effective methods of handling large numbers of calls waiting to find an open extension than Unity has at its disposal. However, when Unity runs behind a switch without such capabilities, or for small-scale needs in which the call does not end up parking on a port in Unity if a line is not available, it might make sense to have Unity do the hunting for you.

To do this in Unity, you take advantage of the blank greeting option, which is provided for fast call-routing scenarios just like this. Imagine that you want to have Unity try to find an open extension between 4001 and 4009 and, if none of the extensions is available, send the caller to an interview handler and collect the caller's information for later callback. To do that, follow these steps:

Step 1. First, create 10 call handlers. Configure their alternate transfer rules to be active, and have them configured to do a supervised transfer to extensions 4000 through 4009. You do not need to assign extensions to these call handlers if you do not want to; it is necessary only to configure the transfer rules properly to get Unity to try the phones that you want here. Depending on how you route callers to this hunt group, it is probably a good idea not to assign extensions to these handlers. Note that this scenario assumes that if an extension is not busy, someone is there to answer it. If you have agents in this group, have them be sure to take their extension out of service with a DND setting so that the switch returns busy when Unity tries the extension. If Unity spends time ringing the phone four times or more on these extensions, the caller could wait quite a while.

Step 2. Configure the alternate greetings for all 10 of the handlers to be active, and have the greeting source selected as blank. Using blank here instead of using a custom-recorded greeting that is blank means that Unity will take the after-greeting action instantaneously. Using a custom-recorded greeting that you simply leave empty results in a second or two of delay, even though there is no greeting recorded. This might not sound like much, but when strung over 10 or 20 call handlers, it makes a big difference. The blank option is there specifically for cases when you want to skip the greeting and move directly to the after-greeting action as quickly as possible.

Step 3. Configure the after-greeting action for each of the first nine call handlers to Attempt Transfer For the next call handler in the chain. Be sure not to use Send to Greeting For here because Unity does not actually try any of the extensions in the chain.

Step 4. On the last call handler (4009, in this case), you must decide what to do because this means that none of the extensions is open. In this example, you would have the after-greeting action set to go to an interview handler that is configured to take the caller's information and leave the message for a subscriber or public distribution list where someone can call them back when an agent frees up.

Additional notes from TAC:

"Of course, you have the last call handler play a greeting stating that no one is available now, followed by hold music that lasts 30 or 60 seconds, and then have an after-greeting action of sending the caller to the "attempt transfer" point on the first call handler at extension 4001. This queues calls until an extension becomes available.

Although this works, it also uses a port on your Unity system for each call holding in the queue. There is no easy way to limit how many calls Unity allows to pile up here, so with any kind of heavy call traffic, you run the risk of using all your ports with this application. In general, this is a bad idea unless you somehow have limited how many callers can reach this application. For instance, you can have calls that come in on particular ports on Unity go to the application, and provide no other mechanism for reaching the hunt group head. In this way, you can limit how many callers are in the queue at any given time. However, this is a pretty awkward mechanism; we definitely recommend using your switch to handle such queuing capabilities, to avoid problems with limited port resources on the Unity server.

You also can have the last call handler loop back to the first call handler and just keep trying until an extension opens up. Do not do this. Not only will you use port resources on the Unity server to do this, but in the case of a CallManager integration, you might overload the switch. Because the busy state comes back immediately in a CallManager integration, this would whip through all the handlers hundreds of times a second, which can overload the system. If you really want to queue the calls, be sure to have a 30- to 60-second greeting in the last handler before going back to the head of the hunt group.

One last note to keep in mind here: Different switches take different amounts of time to determine whether an extension is busy. As such, you might decide to include an actual recorded greeting that says, "Please stay on the line-your call is important to us," every three or four handlers in the chain. In the case of a CallManager integration, this is not necessary because the busy state is reported immediately. However, for analog switches, this can take a little while because the Dialogic card actually has to listen to the tone patterns being played back to determine whether it is a busy signal or a ring tone before reporting the state to Unity. This can take a couple of cycles, which can take a few seconds. Be sure to test how long of a delay callers will hear in your system for this scenario. Remember that they will not hear anything, in most cases. If callers hear more than 5 seconds or so of dead air, they might assume that the call has been dropped and hang up on you."

Are the call handlers with the associated hunt pilots homed on the same Unity 5 server as the AA call handler?

I am having an issue with a AA call handler on ServerA, trying to call over to subscribers homed on ServerB, a Unity 5.0(1) server. Everything looks good, but it goes to a "Operator not available" message. TAC says the config looks right but they cant figure it out.


Ginger Dillon Mon, 12/17/2007 - 16:37

Hi JC -

Check this information out to see if it applies to your situation:

Setting the Automated Attendant Search Scope

By default, callers who reach the opening greeting for your organization can be transferred only to subscribers who are associated with the local Cisco Unity server. If you want to set up the automated attendant so that callers can be transferred to subscribers who are associated with other Cisco Unity servers in the same dialing domain, change a registry setting as described in the following procedure.

The automated attendant search scope must be set to search the dialing domain in order for the following features to work:

•Identified subscriber messaging between Cisco Unity servers in the dialing domain

•Cross-server transfers from the automated attendant of one Cisco Unity server to another Cisco Unity server in the dialing domain

Note If the system is configured for failover, the registry changes must be made on both the primary and secondary Cisco Unity servers.

To Set the Automated Attendant Search Scope

Step 1 On the Cisco Unity server desktop, double-click the Cisco Unity Tools Depot icon.

Step 2 In the left pane, under Administrative Tools, double-click Advanced Settings Tool.

Step 3 In the Unity Settings pane, click Networking-Set Auto Attendant Search Scope.

Step 4 In the New Value list, click 1, and then click Set so that Cisco Unity searches for subscribers within the dialing domain.

Step 5 When prompted, click OK.

You do not need to restart Cisco Unity to enable the change.

Step 6 Click Exit.

Here is the full link - http://www.cisco.com/en/US/customer/docs/voice_ip_comm/unity/5x/networking/guide/ex/5xcunet020e.html#wp1050494

Regards, Ginger


This Discussion