Unity Connection Attempt Forward

[hguillory1]

I am having a very weird problem when setting a phone in CCM 6.1.1 to forward noan to VM. The VM Pilot is 4245 which is a route pattern to a SIP trunk integration in Unity Connection 2.1.

Here's the problem:

If user A at extension 1008 calls user B at 1111 and vice versa and the call noan rule is invoked to send to VM, the Unity Opening Greeting picks up, not the personal greeting of the user. The Attempt Forward Rule in CUC has no effect. If I press the messages button on either phone, however, the call prompt for password on the VM box works just fine.

Any help would be appreciated.

Regards,

Hunter Guillory, CCVP

[kris.meier]

Hello Hunter,

I am having a similar problem. If any call hits the extension it goes to the opening greeting and not the user's personal greeting. If I dial the extension during the opening greeting it will direct the call to the personal greeting of the user.

My end goal is to have this extension be the voicemail end point in a hunt list for our main line.

I was just wondering if you made any headway with this problem?

Regards,

Kris

[Rob Huffman]

Hi Kris,

If I understand your issue here you want a caller that routes through a Hunt List and is not answered to end up in a specific users mailbox? If this is correct;

Lets say the Hunt Pilot number is 8000 and the Extension on the Line Group member phone is 2355 (this number, 2355 is where the Messages will land). Set the Hunt Pilot to Forward (CFNA) to the Unity Pilot # .

On the mailbox for 2355 add 8000 as an Alternate Extension. When the call routes through to Unity Connection via the Hunt Pilot No Answer, Unity Connection should see the CLID of 8000 which will then be connected to the Mailbox on 2355.

The only thing to verify is what CLID number is being passed to Unity. it should be 8000 in this example).

Alternate Extensions

On the Alternate Extensions page for a user account, you can enter phone numbers to set up alternate extensions in addition to the primary extension of the user. Alternate extensions can be used for various reasons, such as handling multiple line appearances on user phones. Alternate extensions can also make calling Cisco Unity Connection from an alternate device,such as a cell phone, a home phone, or a phone at another work site more convenient.

When you specify the phone number for an alternative extension, Connection handles all calls from that number in the same way that it handles calls from a primary extension (assuming that ANI or caller ID is passed along to Connection from the phone system). This means that Connection associates the alternate phone number with the user account, and when a call comes from that number, Connection will prompt the user to enter their password and log on.

From this doc;

http://www.cisco.com/en/US/products/ps6509/products_administration_guide_chapter09186a00805570b6.html#wp1040977

Hope this helps!

Rob

[kris.meier]

Rob,

You are pretty much right on the nose with your example. We are using 5000 as the pilot for our main line, which has DNs 5001-5004 in a broadcast line group. All of these DNs are setup on one 7970, while other phones are able to answer the main line via call pickup (thanks for the Cisco Support Use 1 code to enable this feature that you provided in another post, btw!). If the call is not answered, the call is sent to 5005 (via hunt pilot busy / no answer), which is CFA to voicemail. Since none of these extensions are users, I had to create a 5005 user and assign a device to it in order to import the mailbox in Unity Connection Administration. I was able to get around part of the issue by checking the default VM profile, which had a mask of 1XXX (which are our user extensions). Since the VM I'm trying to send to is 5005, the mask would change it to 1005, which I saw in the Dialed Number Analyzer. So I created another profile just for this extension and assigned it in the DN.

I'm still running into a problem with the hunt list forwarding the call to the opening greeting though. I tried your suggestion without any luck. I used the Port Status Monitor in Unity Connection to see what was being passed through from CM. It seems as though it's passing on the caller ID of the extension I'm calling from, not the hunt pilot. So I transformed the calling party to 5000 via the hunt pilot to make it show the caller ID as 5000, but no luck. Here is what the port sees without the mask:

33 PHGreeting Playing greeting for Call Handler: Opening Greeting Call answered if needed

33 PHGreeting Playing greeting for Call Handler: Opening Greeting Call answered if needed

33 PHGreeting Playing greeting for Call Handler: Opening Greeting Call answered if needed

33 PHGreeting Playing greeting for Call Handler: Opening Greeting Call answered if needed

33 PHGreeting Playing greeting for Call Handler: Opening Greeting Call answered if needed

33 AttemptForward Idle Idle

33 is the extension I'm calling the pilot (5000) from. Here is what happens with the mask:

5000 PHGreeting Playing greeting for Call Handler: Opening Greeting Call answered if needed

5000 PHGreeting Playing greeting for Call Handler: Opening Greeting Call answered if needed

5000 PHGreeting Playing greeting for Call Handler: Opening Greeting Call answered if needed

5000 PHGreeting Playing greeting for Call Handler: Opening Greeting Call answered if needed

5000 PHGreeting Playing greeting for Call Handler: Opening Greeting Call answered if needed

Any other suggestions?

Thanks for your help,

Kris

[kris.meier]

It seems as though the hunt pilot is sending calls that are CFA or CFB to Unity's default system call handler, which directs to the opening greeting message. It's done this for any of the voicemail redirections that we've setup, when directing from a hunt pilot. We're using 1XXX as our user extensions and 2XXX as a direct to voicemail extensions so that anyone answering the main line can put the call directly into a user's voicemail box without having to speak with the user. None of the 2XXX DNs will correctly forward to the users Unity greeting, just to the default opening greeting. If I edit the call handler's “After Greeting” section to point to “User with Voice Mailbox” 5005 and “Go Directly to Greetings”, instead of “Call Handler” Operator “Attempt to Transfer”, we can get around this particular issue. The problem with this is if we have another hunt pilot to setup that needs to end up in a different voicemail box, then it will be directed to 5005, not the new voicemail box.

One way that I can think to resolve this is if I could get CM to enter in additional digits after it attempts to forward to 5005. Since it's defaulting to the Opening greeting, is there a way to have it send to 5005, then wait for 1 - 2 seconds and dial 5005 again to transfer the call through the opening greeting to the correct mailbox? For the reasons stated above, I'm hesitant to change the Call Handler itself.

Thanks for any advice.

-Kris

[hguillory1]

Hi Everyone. Thank you for your responses. The method that Rob outlined above is the method that has been taken for the scenario. However, it still did not resolve the issue with CFNA or CFB into CUC. None-the-less I did finally find the underlying problem:

Remove your mask from your voicemail pilot and set multiple tenant policy to false under system parameters. For some reason CUC does not like the mask. You will not be able to transfer directly into VM, but it will fix the CFNA and CFB. I have a TAC case open for this.

Thanks,

Hunter

[satish rawat]

Hey Hunter..thanks for posting this solution..you saved me .i was about to give up on this simple issue i was struggling for last few days...

its rediculous that mask can create such a mess..anyway thanks for the posting.