Re: Call Handler not going to right operator

Rob Pyke · ‎09-22-2010

We have two call handlers for two high phone traffic buildings (high schools). I created a call handler for each building and set up both to send the caller to the appropriate receptionist when "0" was pressed. On occasion we have callers getting routed to a completely different receptionist at our main admin building. I have gone over the settings on both call handlers several times and verified that "0" is sending (or supposed to) to the correct extension. I cannot find anything wrong. I have personally verified that it does happen and is not a case of caller error.

Any clues in the clue closet?

We are running

CUCM 7.0.2.20000-5

Cisco Unity Connections 7.0.2.10000-38

Brad Magnani · ‎09-22-2010

Hi,

Is it reproducible since you said that you're able to confirm the behavior? Have you tried launching either the Remote Port Status Monitor tool or RTMT Port Monitor to see where the call is actually going when this happens? The greeting that you receive, is it a known greeting of another call handler/subscriber? Knowing where you're arriving may help you determine what may be going on.

Brad

Rob Pyke · ‎09-22-2010

It is reproducable. In fact it happened to me when I called one of the buildings in question. The greeting that is received is the correct one for each of those call handlers. They are distinct and unique.

I've run the port status monitor. Nothing screams "PROBLEM" but I am far from an expert.

11:30:55, New Call, CalledId=6786, RedirectingId=6786, Origin=16, Reason=8, CallGuid=9600100FFB154453BD3E1F2F4D998083, CallerName=, LastRedirectingId=*6786, LastRedirectingReason=8, PortDisplayName=CCM-1-003,[Origin=Invalid],[Reason=Invalid]
11:30:55, AttemptForward
11:30:55, State - AttemptForward.cde!Dummy
11:30:55, Event is [NULL]
11:30:55, PHTransfer
11:30:55, State - PHTransfer.cde!LoadInfo
11:30:55, Event is [TrueEvent]
11:30:55, PHGreeting
11:30:55, State - PHGreeting.cde!PlayGreeting
11:30:55, Call answered if needed
11:30:55, Playing greeting for Call Handler: 6786|Chiawana Main Line
11:31:06, DTMF received [5]
11:31:11, DTMF added [695]
11:31:11, Event is [NULL]
11:31:11, PHTransfer
11:31:11, State - PHTransfer.cde!LoadInfo
11:31:11, Answer Phone if needed
11:31:11, Event is [FalseEvent]
11:31:11, State - PHTransfer.cde!CheckPlayTransferIntro
11:31:11, Event is [TrueEvent]
11:31:11, State - PHTransfer.cde!PlayTransferIntro
11:31:13, Event is [NULL]
11:31:13, State - PHTransfer.cde!XferCall
11:31:14, Event is [HangupEvent]
11:31:14, State - PHTransfer.cde!DoHangUp
11:31:14, Event is [HangupEvent]
11:31:14, Idle

And another

11:40:44, New Call, CalledId=6786, RedirectingId=6786, Origin=16, Reason=8, CallGuid=ABEFE356B98148A3BBE74B5B72B86EB4, CallerName=, LastRedirectingId=*6786, LastRedirectingReason=8, PortDisplayName=CCM-1-003,[Origin=Invalid],[Reason=Invalid]
11:40:44, AttemptForward
11:40:44, State - AttemptForward.cde!Dummy
11:40:44, Event is [NULL]
11:40:44, PHTransfer
11:40:44, State - PHTransfer.cde!LoadInfo
11:40:44, Event is [TrueEvent]
11:40:44, PHGreeting
11:40:44, State - PHGreeting.cde!PlayGreeting
11:40:45, Call answered if needed
11:40:45, Playing greeting for Call Handler: 6786|Chiawana Main Line
11:40:52, DTMF received [5]
11:40:54, DTMF added [739]
11:40:54, Event is [NULL]
11:40:54, PHTransfer
11:40:55, State - PHTransfer.cde!LoadInfo
11:40:55, Answer Phone if needed
11:40:55, Event is [FalseEvent]
11:40:55, State - PHTransfer.cde!CheckPlayTransferIntro
11:40:55, Event is [TrueEvent]
11:40:55, State - PHTransfer.cde!PlayTransferIntro
11:40:56, Event is [NULL]
11:40:57, State - PHTransfer.cde!XferCall
11:40:57, Event is [HangupEvent]
11:40:58, State - PHTransfer.cde!DoHangUp
11:40:58, Event is [HangupEvent]
11:40:58, Idle

Brad Magnani · ‎09-22-2010

I may not fully understand the call flow but from the output there, I don't see any 0 being pressed. The first call shows 6786|Chiawana Main Line being played, and then Unity received digits 5695 and transferred the call. For the second call digits 5739 were received by Unity and it proceeded to transfer the call as well. Did you hearing the greetings for both 5695 and 5739?

Rob Pyke · ‎09-22-2010

My apologies I was not interepeting the data correctly.

Here is one where the caller hit "0"

11:55:01, New Call, CalledId=6786, RedirectingId=6786, Origin=16, Reason=8, CallGuid=C7F35234FBEF418CB5A46332002D2C09, CallerName=, LastRedirectingId=*6786, LastRedirectingReason=8, PortDisplayName=CCM-1-003,[Origin=Invalid],[Reason=Invalid]
11:55:01, AttemptForward
11:55:01, State - AttemptForward.cde!Dummy
11:55:01, Event is [NULL]
11:55:01, PHTransfer
11:55:01, State - PHTransfer.cde!LoadInfo
11:55:01, Event is [TrueEvent]
11:55:01, PHGreeting
11:55:01, State - PHGreeting.cde!PlayGreeting
11:55:01, Call answered if needed
11:55:01, Playing greeting for Call Handler: 6786|Chiawana Main Line
11:55:18, DTMF received [0]
11:55:19, Event is [NULL]
11:55:19, PHTransfer
11:55:19, State - PHTransfer.cde!LoadInfo
11:55:19, Answer Phone if needed
11:55:19, Event is [FalseEvent]
11:55:19, State - PHTransfer.cde!CheckPlayTransferIntro
11:55:19, Event is [TrueEvent]
11:55:19, State - PHTransfer.cde!PlayTransferIntro
11:55:21, Event is [NULL]
11:55:21, State - PHTransfer.cde!XferCall
11:55:22, Event is [HangupEvent]
11:55:22, State - PHTransfer.cde!DoHangUp
11:55:22, Event is [HangupEvent]
11:55:22, Idle

Hitting "0" is supposed to send them to 5500

Here is the other call handler

12:38:17, New Call, CalledId=5581, RedirectingId=5581, Origin=16, Reason=8, CallGuid=55FAFD925E7B4825BFA9013B1DA09F67, CallerName=, LastRedirectingId=*5581, LastRedirectingReason=8, PortDisplayName=CCM-1-003,[Origin=Invalid],[Reason=Invalid]
12:38:17, AttemptForward
12:38:17, State - AttemptForward.cde!Dummy
12:38:17, Event is [NULL]
12:38:17, PHTransfer
12:38:17, State - PHTransfer.cde!LoadInfo
12:38:17, Event is [TrueEvent]
12:38:17, PHGreeting
12:38:17, State - PHGreeting.cde!PlayGreeting
12:38:17, Call answered if needed
12:38:17, Playing greeting for Call Handler: PHS Main
12:38:24, DTMF received [0]
12:38:26, Event is [AlternateContactNumber]
12:38:26, State - PHGreeting.cde!PlayTransferPrompt
12:38:28, Event is [NULL]
12:38:28, State - PHGreeting.cde!TransferToACN
12:38:29, Event is [HangupEvent]
12:38:29, State - PHGreeting.cde!DoHangup
12:38:29, Event is [HangupEvent]
12:38:29, Idle

Hitting "0" is supposed to go to 3800

Instead at random intervals hitting "0" on either goes to 6700.

Brad Magnani · ‎09-22-2010

When the issue happens, for both scenarios have you confirmed that 5500 and 3800 actually ring? Or are you hearing subscriber 6700's greeting every time? Is it possible that there may be something happening after their phone actually rings or they're configured to do something differently if there is no answer on those phones? Hence the call getting sent somewhere else. Have you checked their call forwarding configuration on the phone system to see if 6700 is configured on them anywhere? Is it possible that they're forwarding their phone to 6700 manually? Unity will not arbitrarily call different extensions which aren't configured. Either the call path is coming into Unity differently and utilizing a configuration that you're not aware of with working vs. non working (which doesn't seem to be the case based on what you've provided) or there is something happening after Unity extends the transfer that's altering the call path. There's also the possibility of a configuration that I've overlooked, having no knowledge of your environment.

One other thing you could check is depending on whether the phone just rings or if you're hearing the greeting, is the port monitor. If the situation is that its playing the greeting of 6700, the call should be viewable on another incoming port and you should see all of the calling information (where it was forwarded from, etc.) just like a new call.

Brad

Rob Pyke · ‎09-22-2010

First thing I checked was if their phones were forwarded. I checked the config on both phones and found nothing out of the ordinary. 3800 and 5500 both go to voice mail if there is no answer. I have caller input disabled on the voicemail for both except for "1" which skips the greeting. The secretaries both swear they are not manually forwarding their phones.

6700 is a DN not a handler. They secretary at that extension is ready to tar and feather me and I'm allergic to third degree burns and feathers.

Either the call path is coming into Unity differently and utilizing a 
configuration that you're not aware of with working vs. non working 
(which doesn't seem to be the case based on what you've provided) or 
there is something happening after Unity extends the transfer that's 
altering the call path.

Entirely possible. It *might* be a search scope issue. Had not thought of that.

pallavikahai · ‎10-12-2010

I have recently installed CUCMBE 8.5 and I have come across a similar issue where at random intervals the call gets transferred to another extension instead of the one configured. The auto-attendant is figured as follows:

Press 3 for High School and then Press 1 for the main office and transfered to extension 401

Press 2 for Middle Schhol and then Press 1 for the main office and then transfered to extension 451

I have noticed that intermittently instead of reaching High School at extension 401 the call gets transfered to 451. I have used Port Monitor to check for caller input and for 1 call out of 10 calls I have seen that insteda of being transferred to 401 I get transferred to 451.

The middle school secretary is getting 10 calls at an average that are meant for high school.

Please let me know if you were able to resolve this issue.

Thanks in advance.

Rob Pyke · ‎10-13-2010

Pallavi,

What I did which helped (not eliminated) the issue was I changed the call handler to transfer to the suscriber of the line (Caller with Mailbox option under the appropriate key in the caller input menu). Then I upped the shared line busy triggers for every phone that has that line.

It reduced the calls to the wrong operator by 90%.

Hope this helps. I feel your pain bud.