cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1015
Views
0
Helpful
11
Replies

Company Main number hunt problem

kimberly
Level 1
Level 1

Dear Jeff,<br><br>I used to have: <br>CCM 3.0.(11) with Unity 2.4.6.102 & AV-CiscoTSP 1.0.0.28<br><br>but just upgraded to:<br>CCM 3.0.(11) with Unity 2.4.6.135 & AV-CiscoTSP 1.0.0.36<br><br>but the upgrade did not fix my problem...<br><br>Our Main number hunt is not working properly (I thought at one point I had it working properly). <br><br>I really need a blackboard for this but hopefully I can explain the problem...<br><br>Our customers dial our Main Number & first get Our Opening Greeting in Unity. <br><br>If the caller zeros out or remains on the line during this Opening Greeting, the Operator call handler then forwards the call to a Directory number (not a subscriber) on the Receptionist's phone called Main Line 1. <br><br>On a busy no answer the call is forwarded to Main line 2 (not a subscriber) on the Receptionist's phone (configured in Call Manager under Reception phone Directory number), which on another busy no answer could then forward to Main Line 3 which would then forward to the general voice mailbox extension (a subscriber) on a busy no answer which should route the caller to the greeting for the general voice mailbox on a busy no answer (If Receptionist does not pick up the general voicemail box extension ringing). Instead of getting the greeting for the general voicemail box, the caller gets the Opening Greeting!<br><br>Now, the Operator call handler IS doing a Release to Switch which explains why the caller never hears a general voice mailbox greeting & might explain why they hear the opening greeting instead. But when I do a Supervise Transfer, I loose the Main number hunt on the Reception phone - Only rings Main Line 1 (never goes to Main Line 2 & Main Line 3) & then rings general mailbox & then get general mailbox greeting. By the way, the Operator Call Handler's Transfer to extension does not work unless I set it to Alternate. I have had problems in the past with the transfer on the Operator call handler, I guess it is not working correctly again.<br><br>It is more important for a call the hunt through all three of our Main lines on a busy/no answer even if it returns to opening greeting afterwards (with release to switch) - as opposed to Ringing one Main Line 1 & then going straight to the general mailbox (with supervise transfer).<br><br>There is not way to hunt in Unity is there?? Our hunt was done with busy/no answer on a directory numbers (not subscribers) on a Cisco 30 VIP phone for the Receptionist.<br><br>I know I might be able to simplify my hunt if I had Cisco Web Attendant but we don't have that set up yet & I am not sure that would fix my problem.<br><br>Any help would be appreciated.<br><br>Thanks,<br><br>Kimberly<br><br><br>

11 Replies 11

Not applicable

When you are doing release transfer, and the call has rang at all the lines on the phone (all are no-answer), and it forwards back to Unity, what shows up for the forwarding ID? What is the reason for the call? Open CallViewer.exe to find out. Does the ID match the DTMF ID of the greeting you want this call to go to? Is the greeting in a CallHandler or Subscriber box?

Steve Olivier
Software Engineer
Cisco Systems

When I am doing a Release to Switch in the Operator call handler (standard ring subscriber extension doesn't work have to enable alternate ring) & the call has rang no answer to all the lines on the phone, & forwards back to Unity, it shows: Main Line 1's directory number (5000) as the forwarding ID. In call viewer the Dialed Number matches the forwarding ID. The General Voice mailbox (which I want calls to go to after trying all the lines) greeting is a subscriber mailbox (not a call handler).

On a Busy/NA the call path should be:

Main Line 1 (extensions exist only in Call Manager)
Main Line 2 (extensions not in Unity)
Main Line 3 (not in Unity)
Main Line 4 (not in Unity)
General Voicemailbox (Unity subscriber)

When I change it around like this it works:

Reception Desk Extension (Unity subscriber)
Main Line 1
Main Line 2
Main Line 3
Main Line 4
General Voicemailbox (Unity subscriber)

Is this because the original Extension is recognized as a Unity subscriber in Call Manager & routed appropriately in the 2nd scenario whereas the original Extension is not recognized by Unity in the 1st scenario & therefore plays the opening greeting when handed back to Unity?

Any explanation for this? I would like to do the first scenario rather than the second if I can get the first to work.

I tried to do a cascading hunt in Unity with call handlers but it didn't work for some reason. What make things more difficult to trouble shoot is the fact that some of my call handlers aren't ringing phone like they are supposed to.

Thanks,

Kimberly


Not applicable

"Is this because the original Extension is recognized as a Unity subscriber in Call Manager & routed appropriately in the 2nd scenario whereas the original Extension is not recognized by Unity in the 1st scenario & therefore plays the opening greeting when handed back to Unity?"

Yes. Whatever number is forwarded back to Unity (sounds like it was 5000 in one of your cases). Must match a DTMF ID inside Unity. Unity doesn't know what is going on with the call after it transfers (that's how release transfer works). When that call eventually forwards back to Unity, it has to provide a "valid" forwarding party. "Valid" would be defined as a DTMF id in Unity. If the forwarding party does not have a matching DTMF id in Unity, the call will get sent to opening greeting.

Steve Olivier
Software Engineer
Cisco Systems

How can I get scenerio 1 to work?

If I do a Supervised transfer it will not hunt to Main Lines 2 - 4 before going the the general voicemail box. If I do release to switch it will hunt but not go to general voice mail box.


Not applicable

Unity's supervised transfer is controlled by the number of rings you want it to wait before returning to the greeting. Whatever the number of rings to wait is set for the transfer actually equates to a time period (around 4 seconds for a ring cycle). You'd have to play around with the "Rings to wait for" on the transfer page to get closer to the correct timing to allow all members of the hunt to be reached. That'll be a bit kludgey. Depending upon the status of the members of the hunt, that time frame can vary greatly.

What if you have the last member of the hunt be either a phantom extension or CTI route point that call fowards all to Unity. What ever the DN of the phantom or the route point could match the DTMF id of a CallHandler. That CallHanlder should be able to get you to whatever greeting you want. Does that sound like it'll work?

Steve Olivier
Software Engineer
Cisco Systems

I have attempted to use a similar scenario to the one previously mentioned. Calls that come in are either sent to the opening greeting or disconnected completely.

Calls come into 3700 and ring into Unity voicemail port (which, by the way rings a different number of times each call before answering). If the caller presses "0", the call is transferred to 1830 (web attendant hunt group), the final number of which points to a CTI route point at extension 7501. This route point has a CFB and CFNA destination set for Unity (and a subscriber configured at ext 7501). When calls come in and noone is logged into web attendant, calls then ring 3 times and either disconnect completely or play the opening greeting.

This seems like a very cludgy way to accomplish this task. Do you have any better suggestions than this?

Matt Slaga
Dimension Data US
MCNE, MCSE2k, CCNP/DP Unity Systems Engineer

Not applicable

Anytime a voice mail system is doing supervise transfers to a hunt group things are going to be kludgey. It's generally not a good idea to do. This is especially the case when the timing of the final forwarding destination of the hunt group varies (depending upon if some one is logged into WebAttendant or not).

It sounds like you have encountered two problems with this configuration: 1)disconnects after transferring out to the hunt group and forwarding back in and 2) when it doesn't disconnect, it the call does not go to the appropriate greeting.

What transfer type is being used from Unity to reach the hunt group?

Steve Olivier
Software Engineer
Cisco Systems

I have done a release to switch transfer function. To my understanding, CallManager physically answers calls going into webattendant and searches for a destination. I have noted that even when supervise transfer option is selected, as soon as the transfer takes place, MoH plays which means that Call Manager is once again in charge of the call.

Matt Slaga
Dimension Data US
MCNE, MCSE2k, CCNP/DP Unity Systems Engineer

Not applicable

When you are doing a supervised transfer to a destination that eventually forwards off somewhere, BOTH the voice mail system and the phone system are trying to "control" the call. That's what makes it so kludgey. Such a case would not be kludgey if the phone system always waited a specific amount of rings before forwarding (and that number was higher than the amount of rings Unity was set to). But in this case, there is no guarantee: the number of rings the phone system will wait for is dependant upon having users logged on or off of WebAttendant. Because of this, I'd discourage using a supervise transfer out of Unity.

For the issue about getting the opening greeting after the call eventually forwards back to Unity, what shows in the CallVeiwer.exe for "fowarding party" and "reason"? What is the TSP version? We should be able to get this to go to the correct greeting as long as the appropriate information is sent to Unity in that forward.

Steve Olivier
Software Engineer
Cisco Systems

Apparantly this cannot be done using a CTI route point or a dummy phone. The CFNA and CFB information that is given to Unity from these devices is the originator of the call and not the last destination. I was able to get this to work using a real phone setup with a subscriber account and had exchange worry about getting the information out to a distribution list.

Matt Slaga
Dimension Data US
MCNE, MCSE2k, CCNP/DP Unity Systems Engineer

Not applicable

"The CFNA and CFB information that is given to Unity from these devices is the originator of the call and not the last destination"

So it's an issue of first-redirecting as opposed to last-redirecting in the forwarding information. That is what I was afraid of.

Steve Olivier
Software Engineer
Cisco Systems