Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

call transfer problem

I just upgraded my system to CallManager 3.0.9 and Unity 2.4.6. I found a weird problem.<br><br>If I call into Unity Auto Attendant from a Cisco IP phone, either internally or via PSTN, I can press the # key and then hear "hello, Unity messaging system. From a touch tone telephone you may dial an extension....", then I can enter an extension number and get transferred.<br><br>But if I call Unity Auto Attendant from a regular telephone or a cell phone out of the company and I press the # key, I got the voice prompt "please wait when I transfer your call" and the phone call is automatically transferred to the operator's extension - I can't not even enter the extension number.<br><br>Please help. Thanks.<br><br>

12 REPLIES
Anonymous
N/A

Re: call transfer problem

I suspect the issue isn't the phone you're using, but the fact that the IP phones are internal extensions vs. external numbers when you're using "Regular" phones.

What do you hear BEFORE you hit "#"? I'm guessing when you call in on an IP phone you hear the "please enter your ID" (i.e. you're in the subscriber sign in conversation since you're an internal caller). When you call in from a "normal" phone you're probably already at the opening greeting so hitting # will advance you to the after greeting action which is, interestingly enough, to send you to the operator.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous
N/A

Re: call transfer problem

I think it is Unity's default setting that makes the greeting different to internal and external phones. But I still wonder if there is a way to make the external callers get the same "Please enter your ID" prompt as the internal users do. If yes, this would add another layer of protection.

Thanks.

Anonymous
N/A

Re: call transfer problem

No, this is not the opening greeting behavior. This is routing rules. We will send internal callers from known extensions to the subscriber sign in conversation (since they're likely subscribers calling to check messages). Anyone else gets the opening greeting.

I don't think I'm understanding what you're asking. Why in the world would you want external callers to automatically be sent to the subscriber sign in conversation?! What if they're not subscribers? Extra layer of protection from what?

You can always get from the opening greeting to the sign in conversation by hitting "*", right? You can also setup a routing rule outside callers can use to access the system that will automatically route calls to the subscriber sign in conversation. As such users can access the system with, say, a special 800 number and the first thing they'd hear is "please enter your ID".

Maybe I'm not getting what you're trying to do here... I'm kinda baffled by what you expect to happen here.

Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous
N/A

Re: call transfer problem

We have two main phone numbers.

One is the main company number for everybody to call in and I set up a customized auto attendant for it.

Another number is for our users to call and get access to their voice mail. Because this is the number used only by Unity subscribers, I do not want the callers to get the default opening greeting with the transfer options and such right up front. That is why I want them to hear the Sign-in greeting right after they dial into the number. I also want to force the non-subscriber people to use the main company number only, not the second Unity voice number. That is what I meant "another layer of protection". (although I already have my restriction table configured, I still want people to use only our main company number to get transferred).

I know that I can set up another number for Unity voice mail, with new rules and call handlers so outside callers can get to the Sign-in greeting right after they call. But the problem is that the number for Unity is already well known by the company so I can't use another number. That is why I am thinking to change the default Unity rules - but apparently I can't.


Anonymous
N/A

Re: call transfer problem

The easiest way to do this is to have the call routing rule you setup for the voice mail access line (for subscribers only) to route directly to the Subscriber sign In rule. No call handler, no nothing... all calls that come in on this line will always go to the sign in conversation regardless of the source or originating point.

Is this how you have that routing rule setup or are you routing it to an internal call handler for processing?

It should be as simple as setting up a rule that says all direct calls that have a dialed number of X go to subscriber sign in. The rule should be at the top of the list such that it gets processed first and if it fails (i.e. the dialed number is something else) then it continues processing for normal access to auto attendant. anyone calling that number will always get asked for their ID no matter what.

Unless I'm still not grasping what you're trying to accomplish...


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous
N/A

Re: call transfer problem

Yes, that is exactly what I want to do.

One more thing: I added a new rule to Call Routing and I moved the new rule to to top of the list. But when I dial into Unity the new rule was not in use. I guess that I have to restart Unity after the rules in Call Routing are changed?

Thanks a lot for your help.



Anonymous
N/A

Re: call transfer problem

No, the rule should be active right away.

I suspect the rule criteria for firing is not being met (i.e. the dialed number value isn't being sent to Unity). Fire up the call viewer app in the Unity program group and watch what we get on a test call and compare it what what you have the rule setup for. All the values in the rules are shown in the call viewer so if someting doesn't show up, you need to look at the switch integration next.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous
N/A

Re: call transfer problem

I found that a rule moved does not become active right away. Actually, I am having a problem now.

In Call Routing, I changed the order of the rules - I moved the Attempt Sign-in to the top for Direct Calls. It became active in about an hour - the callers to an extension heard "please enter your password". Then I moved Live Record rule back to the top, but it is still not active. So now the callers to our company can not hear each subscriber's greeting but "please enter your password".

I have checked the Call Viewer. My CallManager is forwarded calls to Unity. I have tried to reset Unity's Telephony ports, restart Unity, but the Live Record rule is still not active.

Please help.

Anonymous
N/A

Re: call transfer problem

The live record rule has absolutely no effect on a Call Manager system (it will never send us a live record event). Where the live record rule is in the big scheme of things makes no difference whatsoever.

Moved rules are active right away (I've just tested this on my 2.4.6 system and it works like a champ).

It sounds to me like you've fouled up your routing rules... you should NOT have moved the attempt sign in rule anywhere... You should have created a NEW rule and had it go to "Subscriber Sign in" as I mentioned in a previous post. If you've managed to move the default rules around by going into Rule Editor (which you shouldn't be using unless you REALLY know what you're doing) you have very likely broken your call routing rules entirely.

At this point you probably need to recreate your default rules using the ConfigMgr tool and start over. I can't really help you here since I have no idea what you've actually done to your rules at this point.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous
N/A

Re: call transfer problem

Oppps.

Here is what I did:

I logged into Unity Admin page, went to Call Routing, and clicked on Change Rule Order. Then I moved Attempt Sign-in to the top so Live Record was the second. (The system allowed me to do that).

The top rule Attemp Sign-in became active in about an hour, without me doing anything. Then I moved the Live Record back to the top but it has been a while, and Live Record is still not active. (now Attempt Sign-in is still active).

Any idea is appreciated.

Anonymous
N/A

Re: call transfer problem

Again, the live record rule has NOTHING to do with anything... why are you assuming it's not active? You would never know because no call would ever fire on the live record rule. I have no idea why you're assuming that's the problem... it's not.

Presumably you had made the hack to get around the TSP issue where direct calls that hit ports 2 and higher are reported as forwarded calls. This is fixed in TSP 32. I'd strongly reccomend downloading that and resetting your routing rules to get back to a working state.

then add a new rule at the top that fires for all calls that come in on a specific port and have them go to Subscriber Sign In.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

Anonymous
N/A

Re: call transfer problem

All I did was to move the Record Live rule up and down(in Call Routing, Unity Admin. I did not play with the Rule Editor), and that caused my problem - a caller could not get the subscriber's greeting but the voice prompt "please enter your password".

I just ran configmgr.exe to reset the rules to default. It fixed the problem. I am going to schedule an off-hour time to upgrade my TSP to 1.0.0.0.32.

Thank you very much for your time. Your help and support are greatly appreciated.



173
Views
0
Helpful
12
Replies
CreatePlease to create content