Unity connection Auto Attendant call transfer

[kpintens]

Hi

I was wondering if someone could help me guide where to start troubleshooting on the following:

In auto attendant I have setup a call handler that needs to transfer the call to an extension. The operator says it is transferring but the call does not come through.

I checked the CSS of the voice mail ports and that has the extension partition in, Unity is call forwarding rule is set to match all calls.  In the call handler the transfer rule is set up for transfer to alternate extension.

Any ideas where to look first

Thanks in advance

Koen

[kpintens]

forgot to mention, Unity Connection 8.0.2

[Rob Huffman]

Hi Koen,

If this extension does not have a configured mailbox on the

system you will need to check the Default System Transfer

restriction table in CUC admin to allow calls to this number

or range of numbers

Cheers!

Rob

[kpintens]

Hi Rob

Thanks for the answer I had a look the default system transfer

There is one that allows 9??????????*  So do I read this correct, starting nr 9 followed by 10 digits?

I have another forward to an extension (Hunt pilot actually) and that starts with 8 followed by 8 digits and that works ok

Koen

[Rob Huffman]

Hi Koen,

This rule;

9??????????*

is blocked on our system

But above it in the table is;

6???*

Which allows transfers to the 6xxx range of numbers even if they do not have a mailbox

on Unity Connection.

On the Call handler itself, are you using Caller Input, free dialing or after greeting action

to try and route the calls to the defined DN?

Cheers!

Rob

[kpintens]

Hi Rob

That is the only system rule enabled, others are blocked, the default transfer ones are all enabled

The call handler has a transfer rule to extension (not unity subscriber)

Tried different settings on the greetings [standard] (ignore caller input etc, different call actions) but no joy.  It does reach it because when I untick the play prompt (wait while transfer) it does not play it.

both DN's are in the same partition (VM ports and destination), I presume this rules out CSS mismatch??

Koen

[Rob Huffman]

H iKoen,

These are always tricky when first setting them up and wrapping your head around

how this all works together

A quick test for the CSS question is to set up a test phone with the same CSS

as the CUC ports and try calling the required DN.

Are you using release to switch?

Does CUC/Leslie come back with any response when trying to link through

the Call handler to the DN?

Have you tried setting a specific rule above the 9??????????* in the

restriction table like we did?

Cheers!

Rob

PS: just to clarify, the call routes through the AA before coming to the Call Handler?

[kpintens]

Hi Rob

It looks like it hits the menu structure in AA, have no greetings there yet but knowing the caller input I get to where I want to go.

At the final Call Handler Leslie states transferring but then 40 seconds later it drops the call (tested this by removing the prompt and then I heard nothing when arriving there)

yes, release to switch is selected

the setup for Default transfer (opposite system transfer) is allow all (nothing blocked)

The weird thing is that there are already AA's on there and they work, one has the extension being a subscriber on Unity Conn. but the other one isn't

Not sure if this is related but for this site on the Callmanager the hunt pilot is not working either.  This could influence the actual call handler destination but for testing puproses that call handler is now set to transfer to my extension

Koen

[Rob Huffman]

Hi Koen,

I've mocked this up to test our theories out here

New final DN is 6777 which has no mailbox on Unity Connection

New Call Handler is 6198

On the CH - 6198 - it doesn't show 6777 as the extension in this post but it's there.

Transfer Action

Transfer Calls To:	Greeting Extension
Transfer Type	Release to Switch Supervise Transfer
Rings to Wait For

I first call the main AA for our Campus and key in 6198. This then routes to 6777 as we expect.

This is without any settings on the restriction table for Default System Transfer (I removed 6???*) for

testing. So we have to assume (I know ) that the issue is not related to the settings

on the Call handler or restriction tables that you described as having configured.

Did you try to set up a test phone with the same CSS as the CUC ports and try calling the required DN?

Cheers!

Rob

[kpintens]

Hi Rob

I can't test it because I only have one IP phone.  I did use the dial plan analyzer and that stated routepattern (they are all in the same partition and the 2 CSS have that)

I see you don't have wait for x rings, will take that off here

Looking again at a working one without subscriber, well I thought, in the message setting of that call handler there is a message recipient defined.  I tried adding one in there but still the same dead air after the wait while I transfer message....

More info, I unblocked the * in the default system transfer restriction rule and it still doesn't forward the call to the DN

Koen

[Rob Huffman]

Hi Koen,

Just as an FYI, the number of rings is set to 4, it just didn't paste properly.

I just used the Remote Port Status Monitor Tool to capture a sucessful call with

the flow from our "mock-up" @ Call Handler 6198. Note that the call routes in via 8700 main AA;

06:53:05, New Call, CalledId=8700,  RedirectingId=8700,  Origin=16,  Reason=8,  CallGuid=CBCA9FA5BCE44237BFD5A55E05B03022,  CallerName=Rob Huffman,  LastRedirectingId=8700,  LastRedirectingReason=8,  PortDisplayName=CallManager-1-002,[Origin=Invalid],[Reason=Invalid]

06:53:05, AttemptForward

06:53:05, State - AttemptForward.cde!Dummy

06:53:05, Event is [NULL]

06:53:05, PHTransfer

06:53:05, State - PHTransfer.cde!LoadInfo

06:53:05, Event is [TrueEvent]

06:53:05, PHGreeting

06:53:05, State - PHGreeting.cde!PlayGreeting

06:53:05, Call answered if needed

06:53:05, Playing greeting for Call Handler:  Opening Greeting

06:53:14, DTMF received [6]

06:53:17, DTMF added [198]

06:53:17, Event is [NULL]

06:53:17, PHTransfer

06:53:17, State - PHTransfer.cde!LoadInfo

06:53:17, Answer Phone if needed

06:53:17, Event is [FalseEvent]

06:53:17, State - PHTransfer.cde!CheckPlayTransferIntro

06:53:17, Event is [FalseEvent]

06:53:17, State - PHTransfer.cde!XferCall

06:53:18, Event is [HangupEvent]

06:53:18, State - PHTransfer.cde!DoHangUp

06:53:18, Event is [HangupEvent]

06:53:18, Idle

You can see where CUC has transferred the call right here;

06:53:17, State - PHTransfer.cde!XferCall

Can you try to capture the same from your set up to see if they match up this way we can see if the call leaves

CUC and you can concentrate on the CUCM side of the house

Cheers!

Rob

[kpintens]

Hi Rob

Stupid question, how do I get to those trace output

on the port monitor I can see things

[Rob Huffman]

Hi Koen,

Not a stupid question at all my friend

These are actually 2 different tools;

This Tool is from the excellent suite of Unity Tools. It seems to be a little

more informative and easy to capture than the info from RTMT;

Port Status Remote Monitor for Connection (rPSM)

http://www.ciscounitytools.com/Applications/CxN/PortStatusMonitorCUC7x/PortStatusMonitorCUC7x.html

Cheers!

Rob

[kpintens]

Thanks Rob

Downloaded and will post test results soon

connection refused even when I put my IP-address in the list

Message was edited by: Koen Pintens

[Rob Huffman]

Hi Koen,

Did you check the listed checkbox as well as setting the IP address of your machine?

For Connection 7.0(1) and later you need to two do things in the “Conversation” section in the Advanced Settings in the administration interface before the rPSM will work properly.

1. Turn      on the remote port status monitor output.   This is a checkbox titled      “Enable Remote Port Status Monitor Output”

Cheers!

Rob