Brain, Thanks for sharing! I’ve often found that an open mind, or willingness to be wrong, has to led to the most interesting investigations.
This is an interesting use case. It suggests another “best practice” for auditing configs. Is this another iteration of “call routing loops” because the css of ingress gateway includes a pattern that routes back to the same gateway? Is there ever a valid use case to forward a DN to a park number? -Wes On Oct 9, 2014, at 4:43 PM, Brian Meade <[email protected]> wrote: 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 _______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
