Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Route Pattern goes fast busy but DNA Shows valid

Hello,

We're currently running CCM 4.2.3 and have a strange problem. When our system was first setup, there were no class of service partitions created so everyone was allowed to dial everywhere. I've been working on cleaning it up but have run into a problem. I copied all the route patterns out of our PSTN partition into the proper partition for that pattern... (IE: Local, long distance, international, etc.)

When I try to place a long distance call I get a fast busy as soon as I hit the last digit. If I change my Calling Search Space back to the origional one it works fine. I ran the dialed number analizer and it shows that the call should go through fine.

I don't understand why this isn't working. I did a debug isdn q931 on our gateway and I don't see the call come through so it it being blocked in CallManager for some reason.

Any thoughts?

5 REPLIES
Cisco Employee

Re: Route Pattern goes fast busy but DNA Shows valid

the routing table might be still on cache memory, a CUCM detailed trace can prove what CUCM thinks is the actual data.

DNA uses the info from the DB directly

try restarting the server if the config looks right, if still no avail a CUCM trace will tell where the error is

HTH

java

if this helps, please rate

HTH

java

if this helps, please rate

www.cisco.com/go/pdi
New Member

Re: Route Pattern goes fast busy but DNA Shows valid

Thanks for your help! I've had this problem before and a reboot seemed to fix it but I was wondering if there was a way to fix it without one.

I'll look through the traces.

New Member

Re: Route Pattern goes fast busy but DNA Shows valid

Here's what I found in the trace...

02/16/2009 10:58:02.497 CCM|Digit analysis: match(pi="1", fqcn="4194247376", cn="7376",plv="5", pss="Site-911:Site-CallPark:Site-Phones:Site2-Phones:Site:Site-IPCC:Site_Nortel-Trunk:Site-Intersite-Outbound:Site-Local:Site-LongDistance:Site-International:Site-Undefined-Ext", TodFilteredPss="Site-911:Site-CallPark:Site-Phones:Site2-Phones:Site:Site-IPCC:Site_Nortel-Trunk:Site-Intersite-Outbound:Site-Local:Site-LongDistance:Site-International:Site-Undefined-Ext", dd="918882378289",dac="0")|<:CCMSVR-CLUSTER><:1.1.1.1><:3><:1.2.1.2><:SEP00137FDB0D26>

02/16/2009 10:58:02.497 CCM|Digit analysis: analysis results|<:CCMSVR-CLUSTER><:1.1.1.1><:3><:1.2.1.2><:SEP00137FDB0D26>

02/16/2009 10:58:02.497 CCM||PretransformCallingPartyNumber=7376

|CallingPartyNumber=7376

|DialingPartition=Site-IPCC

|DialingPattern=9.@

|FullyQualifiedCalledPartyNumber=918882378289

|DialingRoutePatternRegularExpression=(9)(1)([2-9][02-9]X)([2-9]XX)(XXXX)

|DialingWhere=

|PatternType=National

|PotentialMatches=NoPotentialMatchesExist

|DialingSdlProcessId=(0,0,0)

|PretransformDigitString=918882378289

|PretransformTagsList=ACCESS-CODE:LONG-DISTANCE-DIRECT-DIAL:AREA-CODE:OFFICE-CODE:SUBSCRIBER

|PretransformPositionalMatchList=9:1:888:237:8289

|CollectedDigits=918882378289

|UnconsumedDigits=

|TagsList=ACCESS-CODE:LONG-DISTANCE-DIRECT-DIAL:AREA-CODE:OFFICE-CODE:SUBSCRIBER

|PositionalMatchList=9:1:888:237:8289

|VoiceMailbox=

|VoiceMailCallingSearchSpace=

{

3DF0D58A-C0BA-4378-8F6E-2BE1389D0109}

|VoiceMailCallingSearchSpace=Site-CallPark:Site:Site-Phones:Site2-Phones:Site-Intersite-Outbound:Site_Nortel-Trunk:Site_PSTN:Site-IPCCx_Lab:Site_VOIP_Lab:Site-Undefined-Ext

|VoiceMailPilotNumber=6600

|AlertingName=

|RouteBlockFlag=BlockThisPattern

|RouteBlockCause=21

|InterceptPartition=

|InterceptPattern=

|InterceptWhere=

|InterceptSdlProcessId=(0,0,0)

|InterceptSsType=0

|InterceptSsKey=0

|OverlapSendingFlagEnabled=0

|WithTags=

|WithValues=

|CallingPartyNumberPi=NotSelected

|ConnectedPartyNumberPi=NotSelected

|CallingPartyNamePi=NotSelected

|ConnectedPartyNamePi=NotSelected

|CallManagerDeviceType=NoDeviceType

|PatternPrecedenceLevel=Routine

|CallableEndPointName=[2C9E8B37-FCAA-4844-9A87-074C7B265456]

|PatternNodeId=[6C0EA481-FF57-46C0-B89B-819B98934E0C]

|AARNeighborhood=[]

|AARDestinationMask=[]

|AARKeepCallHistory=true

|AARVoiceMailEnabled=false

|NetworkLocation=OnNet

|ProvideOutsideDialtone=true

|AllowDeviceOverride=false

|AlternateMatches= Information Not Available

|TranslationPatternDetails= Information Not Available|<:CCMSVR-CLUSTER><:1.1.1.1><:3><:1.2.1.2><:SEP00137FDB0D26>

(I cleaned up the file to not show too much information.)

It looks like it is picking 9.@ route that we block calls with over the 9.1[2-9]xx[2-9]xxxxxx route that exists in the LongDistance Calling Search Space.

Is there anyway around that or is a reboot required?

Cisco Employee

Re: Route Pattern goes fast busy but DNA Shows valid

try restarting the CCM service

HTH

java

if this helps, please rate

HTH

java

if this helps, please rate

www.cisco.com/go/pdi
New Member

Re: Route Pattern goes fast busy but DNA Shows valid

I ended up deleting the 9.@ route pattern and everything started working without a reboot.

430
Views
4
Helpful
5
Replies
CreatePlease to create content