<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Verdana; font-size: 10pt; color: #000000'>Hmmm, looks like what you said:<br><br><hr style="width: 100%; height: 2px;">03/25/2009 08:11:18.297 CCM|Digit analysis: match(pi="1", fqcn="5198244120", cn="56354",plv="5", pss="UoGSysDN_Def_PT:UoGSys_OffNet_Unlimited_PT:UoGBus_Def_PT:UoGRes_Def_PT:UoGSysDN_VMPilot_PT:UoGSysDN_G21_PT:UoGSysDN_G25_PT:UoGSysDN_G26_PT:UoGSysDN_G28_PT:UoGSysDN_G30_PT:UoGDev_Bus_NDP_PT:UoGDev_Def_PT:UoGSys_Dev_Def_PT", TodFilteredPss="UoGSysDN_Def_PT:UoGSys_OffNet_Unlimited_PT:UoGBus_Def_PT:UoGRes_Def_PT:UoGSysDN_VMPilot_PT:UoGSysDN_G21_PT:UoGSysDN_G25_PT:UoGSysDN_G26_PT:UoGSysDN_G28_PT:UoGSysDN_G30_PT:UoGDev_Bus_NDP_PT:UoGDev_Def_PT:UoGSys_Dev_Def_PT", dd="52000",dac="0")|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::9,100,119,1.286658910><IP::10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.297 CCM|Digit analysis: analysis results|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::9,100,119,1.286658910><IP::10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.297 CCM||PretransformCallingPartyNumber=56354<br>|CallingPartyNumber=56354<br>|DialingPartition=<br>|DialingPattern=<br>|FullyQualifiedCalledPartyNumber=<br>|DialingRoutePatternRegularExpression=<br>|DialingWhere=<br>|PatternType=Unknown<br>|PotentialMatches=NoPotentialMatchesExist<br>|DialingSdlProcessId=(0,0,0)<br>|PretransformDigitString=52000<br>|PretransformTagsList=<br>|PretransformPositionalMatchList=<br>|CollectedDigits=<br>|UnconsumedDigits=<br>|TagsList=<br>|PositionalMatchList=<br>|VoiceMailbox=<br>|VoiceMailCallingSearchSpace=<br>|VoiceMailCallingSearchSpace=<br>|VoiceMailPilotNumber=<br>|AlertingName=<br>|RouteBlockFlag=BlockThisPattern<br>|RouteBlockCause=1<br>|InterceptPartition=UoGBus_Def_PT<br>|InterceptPattern=52000<br>|InterceptWhere=<br>|InterceptSdlProcessId=(4,35,1)<br>|InterceptSsType=67108868<br>|InterceptSsKey=19847<br>|OverlapSendingFlagEnabled=Unknown<br>|WithTags=<br>|WithValues=<br>|CallingPartyNumberPi=NotSelected<br>|ConnectedPartyNumberPi=NotSelected<br>|CallingPartyNamePi=NotSelected<br>|ConnectedPartyNamePi=NotSelected<br>|CallManagerDeviceType=NoDeviceType<br>|PatternPrecedenceLevel=Routine<br>|CallableEndPointName=[]<br>|PatternNodeId=[]<br>|AARNeighborhood=[]<br>|AlternateMatches= Information Not Available<br>|TranslationPatternDetails= Information Not Available<br>|OffNetPattern=OnNet<br>|OutsideDialtone=<br>|DeviceOverride=|<CLID::UOGCCM105-Cluster><NID::10.104.96.104><CT::9,100,119,1.286658910><IP::10.104.25.38><DEV::SEP000DED24D5F0><br><br><hr style="width: 100%; height: 2px;">----- Original Message -----<br>From: "Ryan Ratliff" <rratliff@cisco.com><br>To: "Lelio Fulgenzi" <lelio@uoguelph.ca><br>Cc: "Wes Sisk" <wsisk@cisco.com>, "cisco-voip voyp list" <cisco-voip@puck.nether.net><br>Sent: Wednesday, March 25, 2009 12:05:10 PM GMT -05:00 US/Canada Eastern<br>Subject: Re: [cisco-voip] unassigned DN bug with 4.1(3)<br><br>That's not the best part of the trace to find out why reorder was <br>generated.<br><br>I think the CallStateChangeCause=27 means the disconnect cause was <br>27, which is "Destination out of order". That's not very specific <br>though.<br>DA for the call isn't happening on this node so we can't really see <br>what's going on. Is this a shared line? If so look at where the <br>other line instances are registered.<br><br>-Ryan<br><br>On Mar 25, 2009, at 11:47 AM, Lelio Fulgenzi wrote:<br><br>OK, I don't think that was it then. I don't usually ask people to <br>look at my traces, but since this is an emergency number for us, I <br>wouldn't mind the help.<br><br>The number I was dialing was 52000, I think the relevant lines are:<br><br>03/25/2009 08:11:18.314 CCM|StationD: (0000662) DialedNumber <br>dialedNumber=52000 lineInstance=1 callReference=68354820.| <br><CLID::UOGCCM105-Cluster><NID::10.104.20.101><CT:: <br>9,100,119,1.286658910><IP::10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.314 CCM|StationD: (0000662) CallState <br>callState=12 lineInstance=1 callReference=68354820|<CLID::UOGCCM105- <br>Cluster><NID::10.104.20.101><CT::9,100,119,1.286658910><IP:: <br>10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.314 CCM|StationD(662): StationCtiD - <br>StationOutputCallInfo|<CLID::UOGCCM105-Cluster><NID:: <br>10.104.20.101><CT::9,100,119,1.286658910><IP:: <br>10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.330 CCM|StationD: (0000662) (9,100,132,1602) <br>CallInfo callingPartyName='Lelio Fulgenzi' callingParty=56354 <br>cgpnVoiceMailbox= calledPartyName='' calledParty=52000 <br>cdpnVoiceMailbox= originalCalledPartyName='' <br>originalCalledParty=52000 originalCdpnVoiceMailbox= <br>originalCdpnRedirectReason=0 lastRedirectingPartyName='' <br>lastRedirectingParty=52000 lastRedirectingVoiceMailbox= <br>lastRedirectingReason=0 callType=2(OutBound) <br>lineInstance=1 callReference=68354820. version: 84000006| <br><CLID::UOGCCM105-Cluster><NID::10.104.20.101><CT:: <br>9,100,119,1.286658910><IP::10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.330 CCM|StationD: (0000662) DEBUG- <br>star_DSetCallState(5) State of cdpc(1321989) is 4.|<CLID::UOGCCM105- <br>Cluster><NID::10.104.20.101><CT::9,100,119,1.286658910><IP:: <br>10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.330 CCM|StationCdpc(1321989): StationCtiCdpc - <br>StationOutputStopTone to send ToneChangeNotify CH=4|68354820| <br><CLID::UOGCCM105-Cluster><NID::10.104.20.101><CT:: <br>9,100,119,1.286658910><IP::10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.330 CCM|StationCdpc(1321989): StationCtiCdpc - <br>StationOutputStopTone to send ToneChangeNotify CH=4|68354820| <br><CLID::UOGCCM105-Cluster><NID::10.104.20.101><CT:: <br>9,100,119,1.286658910><IP::10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.330 CCM|StationCdpc(1321989): StationCtiCdpc - <br>CcDisconnReq CH=4|68354820 CmSsFeature=4 ReasonForRedirection=0 <br>OnBehalfOf=Call Forward CallReason=1 CallState=14 <br>CallStateChangeCause=27|<CLID::UOGCCM105-Cluster><NID:: <br>10.104.20.101><CT::9,100,119,1.286658910><IP:: <br>10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.330 CCM|StationCdpc(1321989): StationCtiCdpc - <br>CcDisconnReq CH=4|68354820 CmSsFeature=4 ReasonForRedirection=0 <br>OnBehalfOf=Call Forward CallReason=1 CallState=14 <br>CallStateChangeCause=27|<CLID::UOGCCM105-Cluster><NID:: <br>10.104.20.101><CT::9,100,119,1.286658910><IP:: <br>10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.330 CCM|StationCdpc(1321989): StationCtiCdpc - <br>GenerateCallStateEvent CH=4|68354820 CallState=14 CmSsFeature=4 <br>CallReason=1 CallStateChangeCause=27 RIU=0 CallSelectStatus=0 <br>AuxiliaryData=0 Privacy=0 Feature=137 LRP= LRPName=|<CLID::UOGCCM105- <br>Cluster><NID::10.104.20.101><CT::9,100,119,1.286658910><IP:: <br>10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.330 CCM|StationCdpc(1321989): StationCtiCdpc - <br>GenerateCallStateEvent CH=4|68354820 CallState=14 CmSsFeature=4 <br>CallReason=1 CallStateChangeCause=27 RIU=0 CallSelectStatus=0 <br>AuxiliaryData=0 Privacy=0 Feature=137 LRP= LRPName=|<CLID::UOGCCM105- <br>Cluster><NID::10.104.20.101><CT::9,100,119,1.286658910><IP:: <br>10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.330 CCM|StationCtiCdpc : GenerateCallStateEvent - <br>CgPnPi=0 CgpnNamePi=1 CdpnPi=0 CdpnNamePi=0 OCdpnPi=0 OCdpnNamePi=0 <br>LRPPi=0 LRPName=0|<CLID::UOGCCM105-Cluster><NID::10.104.20.101><br>03/25/2009 08:11:18.330 CCM|StationCdpc(1321989): StationCtiCdpc - <br>StationOutputStartTone to send ToneChangeNotify CH=4|68354820 <br>CmSsFeature=1 ReasonForRedirection=0 OnBehalf=Device CallReason=1 <br>CallState=14|<CLID::UOGCCM105-Cluster><NID::10.104.20.101><CT:: <br>9,100,119,1.286658910><IP::10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.330 CCM|StationCdpc(1321989): StationCtiCdpc - <br>StationOutputStartTone to send ToneChangeNotify CH=4|68354820 <br>CmSsFeature=1 ReasonForRedirection=0 OnBehalf=Device CallReason=1 <br>CallState=14|<CLID::UOGCCM105-Cluster><NID::10.104.20.101><CT:: <br>9,100,119,1.286658910><IP::10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.330 CCM|StationD: (0000662) StopTone.| <br><CLID::UOGCCM105-Cluster><NID::10.104.20.101><CT:: <br>9,100,119,1.286658910><IP::10.104.25.38><DEV::SEP000DED24D5F0><br>03/25/2009 08:11:18.330 CCM|StationD: (0000662) StartTone tone=37 <br>(ReorderTone), direction=0.|<CLID::UOGCCM105-Cluster><NID:: <br>10.104.20.101><CT::9,100,119,1.286658910><IP:: <br>10.104.25.38><DEV::SEP000DED24D5F0><br><br>---<br>Lelio Fulgenzi, B.A.<br>Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1<br>(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)<br>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>"Bad grammar makes me [sic]" - Tshirt<br><br><br>----- Original Message -----<br>From: "Ryan Ratliff" <rratliff@cisco.com><br>To: "Lelio Fulgenzi" <lelio@uoguelph.ca><br>Cc: "Wes Sisk" <wsisk@cisco.com>, "cisco-voip voyp list" <cisco- <br>voip@puck.nether.net><br>Sent: Wednesday, March 25, 2009 10:39:25 AM GMT -05:00 US/Canada Eastern<br>Subject: Re: [cisco-voip] unassigned DN bug with 4.1(3)<br><br>Whichever his higher in the CSS of the calling device will be used.<br><br>The trick to that bug was that the intercept (forward) got left in <br>the old partition so even though the digit analysis would match the <br>correct dn/partition the intercept would be for the wrong partition, <br>and cause the call to fail.<br><br>If you know what to look for that bug is extremely easy to <br>diagnose. All you need is the CCM trace of the failing call.<br><br>Here is an example of me calling 4131004 from 4131001. 4131004 is in <br>PartitionA.<br><br>03/25/2009 10:32:02.816 CCM|Digit analysis: analysis results| <br><CLID::StandAloneCluster><NID::14.48.42.110><CT:: <br>1,100,119,1.513295><IP::14.48.42.14><DEV::SEP001646776451><br>03/25/2009 10:32:02.816 CCM||PretransformCallingPartyNumber=4131001<br>|CallingPartyNumber=4131001<br>|DialingPartition=PartitionA<br>|DialingPattern=4131004<br>|FullyQualifiedCalledPartyNumber=4131004<br>|DialingRoutePatternRegularExpression=(4131004)<br>|DialingWhere=<br>|PatternType=Enterprise<br>|PotentialMatches=NoPotentialMatchesExist<br>|DialingSdlProcessId=(0,0,0)<br>|PretransformDigitString=4131004<br>|PretransformTagsList=SUBSCRIBER<br>|PretransformPositionalMatchList=4131004<br>|CollectedDigits=4131004<br>|UnconsumedDigits=<br>|TagsList=SUBSCRIBER<br>|PositionalMatchList=4131004<br>|VoiceMailbox=<br>|VoiceMailCallingSearchSpace=<br>|VoiceMailCallingSearchSpace=<br>|VoiceMailPilotNumber=<br>|AlertingName=<br>|RouteBlockFlag=RouteThisPattern<br>|RouteBlockCause=0<br>|InterceptPartition=PartitionB<br>|InterceptPattern=4131004<br><br>Note the bold text, and the fact that the DialingPartition is not the <br>same as the InterceptPartition. There is no good reason for that to <br>ever happen and if it does, you've got a problem.<br><br>In your case it sounds like your unassigned DN got marked active.<br><br>-Ryan<br><br>On Mar 25, 2009, at 10:10 AM, Lelio Fulgenzi wrote:<br><br>Thanks. I'm wondering if this was it. We didn't have CFA set, and we <br>eventually deleted the DN from the unassigned DN report.<br><br>Question: If I have an exact match in the <None> partition, and <br>another exact match in another partition, which is used? I can't <br>recall the rule here.<br><br>----- Original Message -----<br>From: "Wes Sisk" <wsisk@cisco.com><br>To: "Lelio Fulgenzi" <lelio@uoguelph.ca><br>Cc: "cisco-voip voyp list" <cisco-voip@puck.nether.net><br>Sent: Wednesday, March 25, 2009 9:57:42 AM GMT -05:00 US/Canada Eastern<br>Subject: Re: [cisco-voip] unassigned DN bug with 4.1(3)<br><br>it's in the hot issues report:<br>http://newsroom.cisco.com/data/syndication/ext/tachi/ExternalCUCM.xml<br><br>CM 4.x - Inactive or Unassigned DN with CFA still forwards calls , <br>Fixed CSCsj30852<br><br>/wes<br><br>On Wednesday, March 25, 2009 9:35:39 AM, Lelio Fulgenzi <br><lelio@uoguelph.ca> wrote:<br>I recall there was a bug with unassigned DNs or forwarding or <br>something that caused havoc in 4.1(3). I can't seem to find anything <br>in the archives.<br><br>I think it had something to do with a DN that was set to forward, <br>then deleted.<br><br>We had a route pattern for 1[XXXX] that sent calls to our PBX. Worked <br>great.<br>Moved the 12345 DNs on the phone into a partition that everyone could <br>dial. Worked great.<br>Had to backout because of PBX issues.<br>Moved the 12345 DNs on the phone into a holding partition.<br>The 1[XXXX] route pattern would no longer send calls to 12345 on the <br>PBX.<br>We even deleted the 12345 from the holding partition and/or any <br>unassigned DNs. Still not working.<br><br>We ended up adding those DNs back to the phones to get it working. <br>But I'm stumped.<br><br>And I couldn't even find the dialed number in the traces. It's like <br>CallManager still thought that number existed on the phones and <br>wouldn't use the route pattern.<br><br>Then I created an exact match route pattern for 12345 hoping it would <br>work. Still wouldn't work. I even put it in the <none> partition for <br>it to have precedent.<br><br><br><br><br>---<br>Lelio Fulgenzi, B.A.<br>Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1<br>(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)<br>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>"Bad grammar makes me [sic]" - Tshirt<br><br>_______________________________________________ cisco-voip mailing <br>list cisco-voip@puck.nether.net https://puck.nether.net/mailman/ <br>listinfo/cisco-voip<br>_______________________________________________<br>cisco-voip mailing list<br>cisco-voip@puck.nether.net<br>https://puck.nether.net/mailman/listinfo/cisco-voip<br><br><br><br></div></body></html>