Unity transfer problem

[Leonlei]

We have a Unity server that is shard by two offices and each office has their own operator, ext 7777 and 5011.

"0" key is enabled on all subscribers to bounce caller back to the operator using two separater call handler, one is configured as transfer call to 7777, another one to 5011. Most of time, it works fine.

However intermittently caller will be end up to office A operator 7777 when he dial 0 in office B subscriber's mailbox. But we did not get any complaint about caller was transferred to another wrong extension, always to 7777.

I checked CCM trace file and found the call was transferred from Unity to CCM, but called party is 7777, it should be 5011. So I think the problem must be with Unity. It looks like Unity mixed up the two call handlers 7777 and 5011.

How can I further identify and fix the problem?

Thanks

[lindborg]

Unity isn't going to "mix up the call handlers" - it's much more likely that you have a 0 key mapped on a call handler or subscriber incorrectly or a caller is getting there by some other means (i.e. off a name lookup handler or some other exit destination).

[Leonlei]

Thanks. However if I mapped "0" on a incorrect call handler, why callers just are end up to wrong extension intermittently? Actually the call handler for office A is named "Operator" and call transfer set up as ring extension 7777, call handler for office B is named "OperatorMTL" and ring extension 5011. I am think if is there possible for Unity just match and invoke "Operator" when it should be invoke "OperatorMTL".

How I can verify this in Unity? Thanks,

[lindborg]

I'm sorry, but there's just no way Unity is just getting confused occasionally and calling the wrong call handler - humans may get confused between "Operator" and "OperatorMTL" but Unity will not - it's using the unique ObjectId (a GUID) to identify and call the call handlers you've assigned to functions - the closeness of their names is completely meaningless.

You've got a configuration issue somewhere in there but it's hard to speculate on what it would be given the sparse information you've provided here. It seems very likely to me that you have a 0 key mapped on some call handler users are going through incorrectly - I've seen this many, many times in multiple tenant scenarios. I have, on the other hand, _never_ seen Unity get confused and call the wrong call handler that's named something similiar.

You could also have one of your three transfer rules on one of your call handlers configured incorrectly to transfer to the wrong number - I've seen that on occasion as well.

without being able to get at your system or see a tree map of your layout or something, I can't really speculate beyond that. I can assure you with all the confidence in the world, however, that Unity is not randomly grabbing call handlers based on their names...

the best I can suggest right now is to review the "audiotext applications in Unity" paper on the documents page of www.CiscoUnityTools.com - I cover how calls flow through call handlers and some of the pitfalls of multiple tenant scenarios in there - it may be helpful to you in running down your problem.

[Leonlei]

Before I added the Call Handler for Office B, the previous solution for "0" out at office B is configure caller input key "0" as attempt to transfer caller to Operator B subscriber while caller was end up to office A Operator. So that's why I try to use call handler, although they might be same in Unity.

[Ginger Dillon]

Hi -

Since both Operator and OperatorMTL are on the same server, is it possible the caller pressed * instead of 0 and reached your directory listing? If the caller entered any portion of the name Operator, Unity would present the matching names to the caller. In this case two matching choices and the caller could have selected the wrong one. Just a thought.

Ginger

[fredhuynh]

Hi Jeff,

I read your audio text application document, you have mentioned that during sign in, when a caller press "#" key that caller will transfer to the open greeting call handler by default. How to you go about prevent any caller from hitting * then # to reach this call handler? We have a lot of callers that do that and they end up bouncing around inside unity and reach other offices that they are not support to reach.

Thanks,