02-13-2009 09:52 AM - edited 03-15-2019 04:12 PM
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?
02-13-2009 11:46 AM
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
02-16-2009 07:57 AM
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.
02-16-2009 10:29 AM
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?
02-16-2009 10:31 AM
try restarting the CCM service
HTH
java
if this helps, please rate
02-20-2009 01:40 PM
I ended up deleting the 9.@ route pattern and everything started working without a reboot.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: