CM4.0(1), hunt groups, and default to opening greeting?

[jhatfield]

We have a CM 4.0(1) SR1 cluster integrated into a Unity VM 4.0(3) server in our lab. TSP is 7.0(3)B. We are testing the line group / hunt group functionality in CM 4.0 and ran into something odd.

In our lab scenario, our route pattern is 6000, pointed to a Hunt List with a line group of IP phones at 6000, 6001, and 6002, then forwards to the Unity line group.

When the call forwards to Unity, Unity sees it as a direct call. Via call viewer we see the dialed and called number but no forwarded information. We hear the opening greeting every time when I would expect to hear the greeting for the 6000 vm box.

Any thoughts? Thanks in advance.

[eschulz]

I won’t venture any guesses on why the calls are showing as direct versus forwarded. Perhaps someone else can help you dig into the CCM config (or traces?) for that. However, I might be able to offer up a workaround in Unity.

You state the dialed number (6000) shows up fine in call viewer but the call reason is direct instead of forwarded. In this case, you could create a new Call Routing rule for Direct Calls. Set the “Send Call to:” field for this rule to Attempt Forward. With this, Unity 4.0(3) will take the dialed number on direct calls and try to match it to a call handler. As with Attempt Forward on forwarded calls, if a match is found the call will go to the handlers greeting. If no match is found then the call will move to the next rule (either Attempt Sign-In or Opening Greeting) and continue as normal.

[jhatfield]

I'll give this a shot and let you know what I find. Maybe there will be a new TSP released that addresses this without adding a routing rule?

[eschulz]

At this point, without further investigation, I'm not sure there is anything to be addressed by changes in the TSP. In general we've found forwarded calls in CM 4.0 are presented to Unity as forwarded calls. So the default routing rules work fine. The workaround I suggested was just something to try until the root cause of your issue can be determined.

[milucero]

Hi Guys,

We came across this just the other day..what the issue is, is how CM 4.0 handles the hunt groups now; the calls route throught the hunt group list, but if the redirect timer is triggered (ring no answer, busy etc on the pilot point) the pilot point will "redirect" the call to the line group, not forward, so the call will show up in Unity as a direct call and not a forwarded call. The work around for this is to have the pilot point to a dummy phone (for the ring no answer/busy) which is set to forward all to Unity, the dummy phone has to have the correct DN to match the appropriate call handler of course ;)

Mike

[jhatfield]

We had tried this same approach but found that we received re-order when we pointed to a phone w/ a dummy mac address. We'll have to re-visit that.

We were also told by the BU that the line group / hunt group ignored the forwarding characteristics of the phone. We did not test this to see if it was true. Our current config has a shorter RNA setting on the line group than the phone does. We'll try your solution and let you know how it goes. Thanks for the response.

[jel]

I was having the same issue when I set up a Call Handler for our main line. I set up the hunt pilot in CallManager to send calls for 5400 to the VM_Pilot.

This would cause Unity to accept the call as a direct call as apposed to forwarded.

The fix for me was to create a Call Routing rule in Unity called

Main-line

Where any Direct call destined for 5400 from any number would be sent to my Main-line call handler.

It worked great after that.

Hope it works for you,

John Larsen