911 call went out secondary MGCP gateway

[dbraggs107]

We had someone dial 911 and it went out a secondary MGCP gateway which caused the call to get routed to a incorrect PSAP. 

I've checked the logs on this gateway and the PRI never went down during the time of the call. I also tested the next day and the call went out the correct gateway multiple times without any changes on my end. 

The only thing I can think of is that this particular gateway lost it's MGCP registration during the time of the call and the 911 call got routed to the next available MGCP gateway. However, there is nothing in the logs that shows MGCP was down during the 911 call. 

I have CDR logs showing the 911 being routed to the other gateway, but it doesn't give a reason why it did so. 

Any thoughts on how I can track this call more in depth to figure out why it went out the secondary route group member / gateway?

[dbraggs107]

Also for this reason...see attached 

Looks like it should have hit RL_IA_Local

[Brian Meade · Accepted solution]

It hit your 9.@ Route Pattern in the BI_IA_Unrestricted partition:

05745660.001 |03:23:27.031 |AppInfo  |Digit Analysis: star_DaReq: daReq.partitionSearchSpace(:0820ca35-41ef-4b13-8d5e-bd76bb146425), filteredPartitionSearchSpaceString(BA_Internal:BA_IA_Speeddials:BA_Translation:BA_IA_Local:BA_IA_Unrestricted:BA_IA_Gateways), partitionSearchSpaceString(BA_Internal:BA_IA_Speeddials:BA_Translation:BA_IA_Local:BA_IA_Unrestricted:BA_IA_Gateways)
05745660.002 |03:23:27.031 |AppInfo  |Digit Analysis: star_DaReq: Matching Legacy Numeric, digits=9911
05745660.003 |03:23:27.032 |AppInfo  |Digit Analysis: getDaRes data: daRes.ssType=[0] Intercept DAMR.sstype=[0], TPcount=[0], DAMR.NotifyCount=[0], DaRes.NotifyCount=[0]
05745660.004 |03:23:27.032 |AppInfo  |DbMobility: getMatchedRemDest starts: cnumber = 911
05745660.005 |03:23:27.032 |AppInfo  |DbMobility: getMatchedRemDest: full match case
05745660.006 |03:23:27.032 |AppInfo  |DbMobility SelectByDestination: no matching RemDestDynamic record exists for remdest [911]
05745660.007 |03:23:27.032 |AppInfo  |DbMobility: can't find remdest 911 in map
05745660.008 |03:23:27.032 |AppInfo  |Digit analysis: match(pi="2", fqcn="5159564404", cn="4404",plv="5", pss="BA_Internal:BA_IA_Speeddials:BA_Translation:BA_IA_Local:BA_IA_Unrestricted:BA_IA_Gateways", TodFilteredPss="BA_Internal:BA_IA_Speeddials:BA_Translation:BA_IA_Local:BA_IA_Unrestricted:BA_IA_Gateways", dd="9911",dac="0")
05745660.009 |03:23:27.032 |AppInfo  |Digit analysis: analysis results
05745660.010 |03:23:27.032 |AppInfo  ||PretransformCallingPartyNumber=4404
|CallingPartyNumber=5159564404
|DialingPartition=BA_IA_Unrestricted
|DialingPattern=9.@
|FullyQualifiedCalledPartyNumber=9911
|DialingPatternRegularExpression=(9)(911)
|DialingWhere=(AREA-CODE == 800) OR (AREA-CODE == 888) OR (AREA-CODE == 866) OR (AREA-CODE == 877) OR (SERVICE == 911) OR (AREA-CODE == 855)
|PatternType=National
|PotentialMatches=ForegoPotentialMatches
|DialingSdlProcessId=(0,0,0)
|PretransformDigitString=9911
|PretransformTagsList=ACCESS-CODE:SERVICE
|PretransformPositionalMatchList=9:911
|CollectedDigits=911
|UnconsumedDigits=
|TagsList=SERVICE
|PositionalMatchList=911
|VoiceMailbox=9911
|VoiceMailCallingSearchSpace=BA_Internal
|VoiceMailPilotNumber=1900
|RouteBlockFlag=RouteThisPattern
|RouteBlockCause=0
|AlertingName=
|UnicodeDisplayName=
|DisplayNameLocale=1
|OverlapSendingFlagEnabled=0
|WithTags=
|WithValues=
|CallingPartyNumberPi=NotSelected
|ConnectedPartyNumberPi=NotSelected
|CallingPartyNamePi=NotSelected
|ConnectedPartyNamePi=NotSelected
|CallManagerDeviceType=NoDeviceType
|PatternPrecedenceLevel=Routine
|CallableEndPointName=[b3a0f041-f16b-45e9-90de-19bdf999dd59]
|PatternNodeId=[2fb5b40c-c243-485a-98cf-490507dd713d]
|AARNeighborhood=[]
|AARDestinationMask=[]
|AARKeepCallHistory=true
|AARVoiceMailEnabled=false
|NetworkLocation=OffNet
|Calling Party Number Type=Cisco Unified CallManager
|Calling Party Numbering Plan=Cisco Unified CallManager
|Called Party Number Type=Cisco Unified CallManager
|Called Party Numbering Plan=Cisco Unified CallManager
|ProvideOutsideDialtone=true
|AllowDeviceOverride=false
|AlternateMatches= Information Not Available
|TranslationPatternDetails= Information Not Available
|ResourcePriorityNamespace=
|PatternRouteClass=RouteClassDefault

Which goes to this Route List:

05745672.001 |03:23:27.032 |AppInfo  |RouteListControl::idle_CcSetupReq - RouteList(RL_IA_IL_Local), numberSetup=0 numberMember=13 vmEnabled=0

[dbraggs107]

I appreciate the help. Just wondering why it preferred 9.@ over 9.911 but I can look at that. 

9.911

BA_IA_Unrestricted

RL_IA_Local

9.@

BA_IA_Unrestricted

FLT_LD_International

RL_IA_LD

9.@

BA_IA_Unrestricted

FLT_IA_LCL

RL_IA_IL_Local

[Brian Meade]

What device did you run that DNA against?

4404 on SEP000AF4BB77D3?

[dbraggs107]

Tried it as you suggested with the phone here are the results. Looks likes he dialed 9911 instead of 911 

• Results Summary

• Calling Party Information
• Dialed Digits = 9911
• Match Result = RouteThisPattern
• Matched Pattern Information
  • Pattern = 9.@
  • Partition = BA_IA_Unrestricted
  • Time Schedule =
• Called Party Number = 911
• Time Zone = America/Chicago
• End Device = RL_IA_IL_Local
• Call Classification = OffNet
• InterDigit Timeout = NO
• Device Override = Disabled
• Outside Dial Tone = NO

• Call Flow

• TranslationPattern :Pattern=
• Route Pattern :Pattern= 9.@
• Route List :Route List Name= RL_IA_IL_Local
  • RouteGroup :RouteGroup Name= RG_IA_IL_Local
  • RouteGroup :RouteGroup Name= RG_IA_LD
  • RouteGroup :RouteGroup Name= RG_Local
  • RouteGroup :RouteGroup Name= RG_LongDistanceCalls
  • RouteGroup :RouteGroup Name= RG_NY_LOCAL
  • RouteGroup :RouteGroup Name= RG_NY_LD

[dbraggs107]

Edit: Figured out the trace (CUCM 9.1.2)

https://supportforums.cisco.com/document/126666/collecting-cucm-traces-cucm-862-tac-sr

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/9_1_1/admin/CUCM_BK_CE552AF7_00_cisco-unified-serviceability-administration-91/CUCM_BK_CE552AF7_00_cisco-unified-serviceability-administration-91_chapter_011.html