Xfer from AA to DN with CFA goes straight to VM

matthubach · ‎09-23-2011

I have configured a call handler with an AA greeting. There are no DID's associated with this site.

Working Scenario: AA answers, caller dials extension, extention on phone rings, and works fine.

Not Working Scenrio: User configures phone to CFA. AA answers, caller dials extesion, and the call goes straight to VM.

The users UnityConnection account is configured to release to switch under the transfer rules.

Within the AA (call handler) config, the tranfer rule was configure to "Greeting" and the release to switch option is grayed out.

However, if you try to configure the AA for extension, the release to switch option is available, but requies an extension. The extension field does not allow variables (since caller could dial any of 100 numbers). I am not that sure this is the issue, since the call when not in a CFA config, does work.

All version 8.5 CUC and CUCM.

Any ideas out there?

Tommer Catlin · ‎09-23-2011

Can you describe your call flow better.

IE, Internal caller dial 3000

Hits the General CallHandler

The select option 1 which goes to CallHandler (AA) above.

Caller enters 3001, it transfer to the phones line, person answers.

3001 is configured to CallFoward ALL. CallFoward all to where? PSTN? Voicemail? Is the CSS correct for CFA?

cnuche · ‎09-24-2011

Hi,

I'm not sure I understand what the problem is, you say:

Working Scenario: AA answers, caller dials extension, extention on phone rings, and works fine.

Not Working Scenrio: User configures phone to CFA. AA answers, caller dials extesion, and the call goes straight to VM.

Well that actually sounds like working as design, if you setup CFA to VM it will go to VM, so no surprises here.

Can you please be specific on the call flow, the current behaviour and the expected behaviour.

Christian Nuche

PDI HD Team.

matthubach · ‎09-29-2011

More Details:

A user at x3300 configures his phone to CFA to a cell phone. The CFA is configured to dial 913035551234 (LD). The x3300 phone (and all phones within this site) can successfully dial this cell phone number with just a regular outbound call . Also, any IP phone that dials 3300 within the LAN/WAN, will get fw'd to the cell correctly. So, outbound dialing and the CSS for CFA are working. All oubound calls go out a PRI.

FYI-There are no DID's for this site.

The Problem:

An outside caller dials the main number at 8175556789. This calls comes in over FXO, and plar'd to an auto attendant (AA). The AA picks up and says you can dial the users extension at anytime...If the caller enters the extension x3300, the caller goes straight to VM. The IP Phone never rings. If you remove CFA on the IP Phone, and the caller dials x3300 from the AA, the IP Phone rings and x3300 is connected.

I messed around with a new COS and restriction tables. I've had no luck. Thoughts?

matthubach · ‎09-29-2011

FYI:

Unity Connection 8.5

CUCM 8.5

Bradford Magnani · ‎09-29-2011

Hi,

I tried this setup in the lab and mine worked. However, I don't have a PSTN # to transfer out to.

Call into Opening Greeting

Type 5001 which has Transfer setting configured to ring 7003:

In CUCM 7003 is configured CFA to an INTERNAL IP Phone (unlike your PSTN example, since I don't have that capability):

It rang my 9090 extension successfully.

It sounds like you've just got a misconfiguration somewhere. I would start with setting all of the Call Control traces on UC and reproduce the problem and pull Connection Conversation Manager traces and confirm that the transfer is actually being attempted by UC. The reason I say this is because if a transfer fails, by design it will roll to the greeting. If you confirm that it's leaving, or attempting to leave UC then you can move onto CUCM side and see what may be going on.

Hope that helps,

Brad

matthubach · ‎09-29-2011

Thanks Brad. Good test.

Our environment is using a 10 digit dial plan across the enterprise. Users can dial 4 digit extenions to DN's within their site.

So, I did what you did and set the CFA to an extension within the site entering in the 4 digit number (x3305) (xlate pattern converts 4 to 10 within that partition) and CFA worked. I set the CFA to the 10 digit extension (8175553305) of the same DN and it failed again and went straight to VM.

I'll look at the logs you suggested. If my scenario above shed any light let me know.

Bradford Magnani · ‎09-29-2011

That would indicate that UC is actually dialing out properly, I would start with CUCM detailed tracing first and see what you may find with a working vs. failing.

matthubach · ‎09-29-2011

I am going to retract my previous statement. CFA from x3300 to either the 4 digit OR 10 digit extension DOES work when the x3300 extension is dialed from the AA.

Back to CUC perhaps. What is making that call to the cell phone number? Is it the DN or the VM port?

I am using dialed number analyzer right now. When I set the DNA so the calling party is 5551112111 (the DN asociated to the VM port) and I configure it to dial the 913035551234 cell number, and set the CSS to system-voicemail, I looked at the DNA analysis, and it blocks the call. I expected that.

I changed the CSS on the DNA to Long-Distance-10

(CSS) Long-Distance-10

- PART1: Global-All-Lines

- PART2: Toll-Fraud

- PART3: Long-Distance-10 (does NOT block 91...)

- PART4: NA-PSTN-10dig-Local (this PART assigned to the allow Route Pattern)

I reviewed the DNA analysis and the call was routed.

I was thinking that might be the problem. So I added the partition (NA-PSTN-10dig-Local) to the System-Voicemail CSS. I went back to my DNA analysis and this time it routed properly again. BUT, however, the same issue exists. Dialing x3300 from the AA still puts me straight into VM.

I still havent collected the logs. Will do that shortly.

matthubach · ‎09-29-2011

FYI...

We are using Universal Route Lists and Local Route Groups in each Device Pool.

Bradford Magnani · ‎09-29-2011

I would go ahead and just get a case open with TAC since it's going to need some deeper investigation than its probably worth here.

matthubach · ‎10-07-2011

I had a TAC case open but we were unable to determine the problem.

However, we did find a solution. Not an ideal solution though.

Again, our dial pattern design uses local route groups. When a caller hits the AA and presses the extension of the person they are trying to reach, and that person they are trying to reach has a CFA destination configured, the call is trying to use the local route group configured in the voicemail device pool. We did not have a LRG in our VM device pool. Our solution was to assign a LRG to the voicemail device pool, but that has limitations. This means all calls will get forwarded to a single RG. It would be ideal to route this call out the GW assoicated with the site where CFA is configured. Any ideas how to accomplish this?

Tommer Catlin · ‎09-29-2011

I have had some quirky items going on with Local Route Groups in 8.5. I still have a TAC case open on how CUCM is supposed to handle Call Forward All and Call Forward no Answer destinations when Local Route Groups are defined. I have a Trunk that is not playing nice with this when a call come in from it to a device. If I take the local route group off the trunk, the call forward all works fine, but call forward no answer does not. If I put on a local route group, both will work, but routes the call out only the gateway that is defined in device pool local route group.. which is not correct.

matthubach · ‎10-07-2011

I'd be curious to know the outcome of your TAC re how CUCM handles your LRG issues.

Tommer Catlin · ‎10-12-2011

I have it re-queued over to APAC TAC right now. I did some retesting and saw that there is no way for me to have an ICT trunk without a Local Route Group on the Device Pool the trunk is in. But I find this to a design flaw in CUCM. The only work around (as of yet) is to create a separate ICT trunk from the gatekeeper for each site, then place the trunks in their respective device pools. This does not scale well. 30 sites, 30 trunks, 30 additional zones in GK just to make callfoward all or call forward ring no answer to work, when everything else does?! I also asked them about how this would effect Unity Connection SIP trunks on outbound calls it makes….. we will see what they say.