I have the Opening Greeting Call Handler Caller input options key 0 set to "attempt transfer to Operator"<br>The Operator Call Handler has "0" as the extension.<br>The standard transfer rule is set to "yes , ring subscriber at this number "0", release to switch. (I can dial 0 on a Call Manager Ext and it rings the Operator) Why does it not ring through? "Sorry, the operator is not available"<br>thanks<br><br>
Check to see if the alternate transfer rule is enabled for the Operator Call Handler. If enabled, check to see what the transfer is set to for the alternate transfer rule.
Is this a dual switch integration or CCM only?
Does the calling search space for the Uone ports allow a route to extension zero?
If you change the number in the Operator Handler from zero to a working subscriber's extension, does it ring the phone?
It is not a dual integration. Any extension number that I enter in that field will NOT transfer.
I verified that there are no calling search space conflicts. Is this a bug?
What happens if you remove the Caller Input binding for zero on the Opening Box, or dial 0 from somewhere else in the system, like a subscriber mailbox? Dialing 0 should always map to the operator handler if it's profiled for x0, unless there is a Caller Input bound to 0.
Which transfer options are enabled in the Operator box, and what are they set to?
When you dial 0, does Unity say, "please wait while I transfer your call", or does it go straight to the operator greeting?
reading through this thread there are a couple of things that come to mind.
There was a problem where the standard transfer rule (the Backstop transfer rule that should never be disabled) was getting disabled and the calls would fall all the way through without triggering a transfer event. This SHOULD result in an error in the event log. If you have the alternate transfer rule enabled, that would rule that possibility out. I cant tell if youve done that or not, its mentioned that all the rules are set to 0 but its not stated that the alternate transfer rule is enabled or not. Worth doing regardless, it only takes a minute to try. This is the only bug I know of on our side that might have anything at all to do with this. Running dbWalker off my web page will fix this automatically since it detects any standard greetings or standard transfer rules that are disabled and enables them automatically. Try the Alternate greeting route first, though, to verify if thats the issue or not.
The other thing Ive seen here is a transfer issue between our TSP and CM. The transfer does take place but the call ends up getting tossed right back at us on another port from that number (some sort of releasing timing issue). You can verify this by running StatusMonitor.exe in the commserver\techtools directory, monitoring all the ports and doing a test call. If you see the call bounce back to us on another port, this is the issue. I know Steve had some work arounds to this with a registry setting, but Im not sure what those are. If you verify this is whats happening we can run that down.
Unity Product Architect/Answer Monkey
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)
I have the same problem with one of our customers and I have a case open with Cisco. I personally suspect it is a bug with the Operator call handler, but I'll let you know.
A workaround is to set caller input for 0 to "send caller to subscriber", then select the unity subscriber which has 0 assigned as the extension and then select "attempt transfer for". This works for me - V2.4.6 Unity, V3.0.11 Call Manager.