10-27-2010 12:33 PM - edited 03-16-2019 01:35 AM
Attempting to setup redundancy on the gateways, in case of a failure. The digit analysis shows the call being delivered to the failover gateway with the 9, however a debug isdn q931 shows the call being delivered without the 9. Why would the digit analysis show the 9 being delivered, when it is not?
The failover gateway needs the 9 to be sent, while the main gateway does not. Primary gateway is connected to the PSTN and the failover gateway is connected to a PBX.
Clayton_PSTN_RL is the primary
PBX Routes is the failover
Here is the digit analysis:
# Results Summary
* Calling Party Information
o Calling Party = 8750
o Partition = AllPhones
o Device CSS = Clayton_LD_CSS
o Line CSS =
o AAR Group Name =
o AAR CSS = Clayton_LD_CSS
* Dialed Digits = 94445555
* Match Result = RouteThisPattern
* Matched Pattern Information
o Pattern = 9.@
o Partition = Clay_Loc_PT
o Time Schedule =
* Called Party Number = 94445555
* Time Zone = Eastern Standard/Daylight Time
* End Device = Clayton_PSTN_RL
* Call Classification = OffNet
* InterDigit Timeout = NO
* Device Override = Disabled
* Outside Dial Tone = NO
# Call Flow
* TranslationPattern :Pattern=
o Positional Match List = 9:464:5555
o Calling Party Number = 8750
o PreTransform Calling Party Number =
o PreTransform Called Party Number =
o Calling Party Transformations
+ External Phone Number Mask = NO
+ Calling Party Mask =
+ Prefix =
+ CallingLineId Presentation =
+ CallingName Presentation =
+ Calling Party Number = 8750
o ConnectedParty Transformations
+ ConnectedLineId Presentation =
+ ConnectedName Presentation =
o Called Party Transformations
+ Called Party Mask =
+ Discard Digits Instruction =
+ Prefix =
+ Called Number =
* Route Pattern :Pattern= 9.@
o Positional Match List = 9:464:5555
o DialPlan = North American Numbering Plan
o Route Filter
+ Filter Name = Local7_RF
+ Filter Clause = (AREA-CODE DOES-NOT-EXIST AND INTERNATIONAL-ACCESS DOES-NOT-EXIST AND LOCAL-AREA-CODE DOES-NOT-EXIST AND LOCAL-DIRECT-DIAL DOES-NOT-EXIST)
o Require Forced Authorization Code = No
o Authorization Level = 0
o Require Client Matter Code = No
o Call Classification = OffNet
o PreTransform Calling Party Number = 8750
o PreTransform Called Party Number = 94445555
o Calling Party Transformations
+ External Phone Number Mask = YES
+ Calling Party Mask =
+ Prefix =
+ CallingLineId Presentation = Default
+ CallingName Presentation = Default
+ Calling Party Number = 8750
o ConnectedParty Transformations
+ ConnectedLineId Presentation = Default
+ ConnectedName Presentation = Default
o Called Party Transformations
+ Called Party Mask =
+ Discard Digits Instruction = None
+ Prefix =
+ Called Number = 94445555
* Route List :Route List Name= Clayton_PSTN_RL
o RouteGroup :RouteGroup Name= Clayton
+ PreTransform Calling Party Number = 8750
+ PreTransform Called Party Number = 94445555
+ Calling Party Transformations
# External Phone Number Mask = Default
# Calling Party Mask =
# Prefix =
# Calling Party Number = 8750
+ Called Party Transformations
# Called Party Mask =
# Discard Digits Instructions = PreAt
# Prefix =
# Called Number = 4445555
+ Device :Type= MGCPT1PRIPort
# End Device Name = S0/SU0/DS1-0@Clayton-2821
# PortNumber = 0
# Device Status = Registered
# AAR Group Name =
# AAR Calling Search Space =
# AAR Prefix Digits =
# Call Classification =
# Calling Party Selection =
# CallingLinePresentation =
# ConnectedLinePresentation =
# Number Of Strip Digits =
# CallerID DN =
+ Device :Type= MGCPT1PRIPort
# End Device Name = S0/SU0/DS1-0@Gateway_SM
# PortNumber = 0
# Device Status = Registered
# AAR Group Name =
# AAR Calling Search Space =
# AAR Prefix Digits =
# Call Classification =
# Calling Party Selection =
# CallingLinePresentation =
# ConnectedLinePresentation =
# Number Of Strip Digits =
# CallerID DN =
o RouteGroup :RouteGroup Name= PBX Routes
+ PreTransform Calling Party Number = 8750
+ PreTransform Called Party Number = 94445555
+ Calling Party Transformations
# External Phone Number Mask = Default
# Calling Party Mask =
# Prefix =
# Calling Party Number = 8750
+ Called Party Transformations
# Called Party Mask =
# Discard Digits Instructions =
# Prefix =
# Called Number = 94445555
+ Device :Type= MGCPT1PRIPort
# End Device Name = S0/SU0/DS1-0@Gateway_SM
# PortNumber = 0
# Device Status = Registered
# AAR Group Name =
# AAR Calling Search Space =
# AAR Prefix Digits =
# Call Classification =
# Calling Party Selection =
# CallingLinePresentation =
# ConnectedLinePresentation =
# Number Of Strip Digits =
# CallerID DN =
+ Device :Type= MGCPT1PRIPort
# End Device Name = S0/SU0/DS1-0@Clayton-2821
# PortNumber = 0
# Device Status = Registered
# AAR Group Name =
# AAR Calling Search Space =
# AAR Prefix Digits =
# Call Classification =
# Calling Party Selection =
# CallingLinePresentation =
# ConnectedLinePresentation =
# Number Of Strip Digits =
# CallerID DN =
# Alternate Matches
* Partition :Name= Clay_Loc_PT
o Pattern
+ Pattern = 9.@
+ WhereClause = (AREA-CODE DOES-NOT-EXIST AND INTERNATIONAL-ACCESS DOES-NOT-EXIST AND LOCAL-AREA-CODE DOES-NOT-EXIST AND LOCAL-DIRECT-DIAL DOES-NOT-EXIST)
+ Pattern = (9)([2-9][0-9][02-9])([0-9][0-9][0-9][0-9])
+ Tags List = ACCESS-CODE:OFFICE-CODE:SUBSCRIBER
+ Pattern Type = National
+ Call Classification = OffNet
+ CallManager Device Type = AccessDevice
+ PatternPrecedenceLevel = ExecutiveOverride
10-27-2010 01:40 PM
The DNA is not giving me a clear picture on what's going on.
- Set the 'Cisco CallManager' traces to detailed on ALL servers :
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080094e89.shtml#calm
- Make a test call and collect the 'Cisco CallManager' traces for ALL servers using RTMT
Please make a note of
- Calling party
- Called party
- Time stamp of the call
- Exact call flow
Upload the logs and I'll take a look.
- Sriram
10-28-2010 03:17 AM
Detailed trace was enabled on all nodes.
Ext 7756 called 94647103 at 5:50am.
Debug isdn q931 for failed call, which did not send the 9 is attached.
Detailed trace on all nodes is also attached.
The trace was a real time trace, which I hope is sufficient.
7756 called 94647103,
the call matched Clayton Local 7 Digit Dialing route pattern, which sends the call to the Clayton_PSTN_RL route list.
The Clayton route list includes Clayton and PBX route route groups.
the call is sent out the PBX route, since the Clayton gateway is down.
10-28-2010 07:15 AM
I see only SDL traces from one CallManager server. I would need the sdi and sdl traces from ALL CallManager servers. Can you please perform the test again and give me the relevant info ?
- Sriram
10-28-2010 08:36 AM
Can you remove the digit discard instruction on the Clayton Route group and test to see if the 9 is sent in the failover scenario?
If the 9 is sent, this would prove that CUCM is behaving incorrectly when handling the failover scenario.
Can you also provide the exact version of CUCM being used?
-Felipe
10-28-2010 09:22 AM
CCM 7.0.2.20000-5
I'll enable sdi and sdl traces on all servers.
I'll test the failover again in the morning.
Thanks.
10-29-2010 04:25 AM
The Clayton gateway and PBX gateway have discard digits set to none, while the Clayton Route List was set to discard digits at Preat. I assume this is why the 9 was being stripped when the call would go out either gateway, but why doesn't the DNA show the 9 being stripped?
****************The digits discard was changed to none on the Clayton Route List and this resolved my problem!***************
Clayton gateway is primary
PBX Routes is failover
Before my change the Clayton gateway was sending calls without the 9. After the change the Clayton gateway is sending the calls with the 9. Its working both ways, which is very surprising. I'm confident that this was not the case during the initial install.
I have also attached the trace files. If I'm not understanding something correctly, please correct me. It seems that I learn something new everyday!
Thanks for your help!
10-29-2010 06:17 AM
The xml files are just to notify what logs are collected. You should see a folder for each CallManager server that you have downloaded - please zip them up and attach it to the thread.
- Sriram
10-29-2010 02:35 PM
After changing the discard digits to none within the Clayton Route list, the failover calls worked fine, however some calls were rejected going out the Cytn gateway. Example is a call to 9553xxxx would be successfull, while a 9989xxxx number would fail. I have attached the trace files.
10-29-2010 02:37 PM
11-01-2010 06:31 AM
Problem has been resolved.
The Route List was configured to strip the first digit. I moved this responsibility to the gateway and it resolved my problem.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide