<div dir="ltr">So I ran into this weird call park issue today I thought you all might find interesting.<div><br></div><div>We have a customer with CUCM 7.1.5 running the built-in attendant consoles.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I then started tailing the attendant console service logs:</div><div>file tail activelog cm/trace/ac/log4j/acserver.txt</div><div><br></div><div>And kept seeing this every time a new call came in:</div><div>ACPilotRP: 8000: CallID: 20717678 invalid number. redirect failed to 1002<br></div><div><br></div><div>Looking up extension 1002 in CallManager, I found this is the extension of one of the operators.</div><div><br></div><div>So off to the CTIManager/CallManager traces.  >From there, I saw the digit analysis for extension 1002 coming in fine.</div><div><br></div><div>Then I see instead of the call being sent to LineControl, it was being forwarded:</div><div><div>10/09/2014 14:39:02.752 CCM|Forwarding - logInterceptTableEntry</div><div>{</div><div><span class="" style="white-space:pre">      </span> callKey= 0x606CE, </div><div><span class="" style="white-space:pre">       </span> ssKey = 0, recordStatus 0,</div><div><span class="" style="white-space:pre">        </span> dnPattern =  1002, dnPartition = ecaabc2f-ab53-30bb-ec43-bd6671cd561d, dnPartitionSearchSpace = , </div><div><span class="" style="white-space:pre">      </span> cfa     = 8010, cfaToVM     = 0, cfaCss     = Censored_PT_List</div></div><div><br></div><div>So we can see here this operator has Call Forward All set to extension 8010.</div><div><br></div><div>So I looked that number up and sure enough, this is the first extension of their park number range.</div><div><br></div><div>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:</div><div>CallParkManager - ERROR  wait_SsInterceptInd - No Calls parked on ParkNumber=<br></div><div><br></div><div>As soon as we removed the forward all on that operator's extension, everything was resolved.</div><div><br></div><div>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.</div><div><br></div><div>Brian</div><div><br></div><div><br></div><div><br></div><div><br></div></div>