[cisco-voip] Strange Call Park Issue

[Brian Meade]

So I ran into this weird call park issue today I thought you all might find
interesting.

We have a customer with CUCM 7.1.5 running the built-in attendant consoles.

Customer called in saying that when they parked a call via attendant
console, the next incoming call to the operators would connect to the
parked caller rather than going to an operator.

One of the strangest things I had heard of.  I called their main number and
sure enough I got connected to some poor customer that had been waiting on
one of the park slots.

I then started tailing the attendant console service logs:
file tail activelog cm/trace/ac/log4j/acserver.txt

And kept seeing this every time a new call came in:
ACPilotRP: 8000: CallID: 20717678 invalid number. redirect failed to 1002

Looking up extension 1002 in CallManager, I found this is the extension of
one of the operators.

So off to the CTIManager/CallManager traces.  From there, I saw the digit
analysis for extension 1002 coming in fine.

Then I see instead of the call being sent to LineControl, it was being
forwarded:
10/09/2014 14:39:02.752 CCM|Forwarding - logInterceptTableEntry
{
 callKey= 0x606CE,
 ssKey = 0, recordStatus 0,
 dnPattern =  1002, dnPartition = ecaabc2f-ab53-30bb-ec43-bd6671cd561d,
dnPartitionSearchSpace = ,
 cfa     = 8010, cfaToVM     = 0, cfaCss     = Censored_PT_List

So we can see here this operator has Call Forward All set to extension 8010.

So I looked that number up and sure enough, this is the first extension of
their park number range.

Because the operator at extension 1002 had been idle the longest, they were
getting every new incoming call.  This resulted in new callers being
connected to whoever was parked on their first park slot by the operators.
If no one was on park, it skipped that operator and went to the next one
due to the digit analysis error-ing out:
CallParkManager - ERROR  wait_SsInterceptInd - No Calls parked on
ParkNumber=

As soon as we removed the forward all on that operator's extension,
everything was resolved.

Hopefully this was as interesting to you all as it was to me and also a
reminder to never dismiss a user's problem description no matter how
impossible/crazy it seems.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141009/3a02fd2e/attachment.html>