Table Of Contents

Dial Plans and Routing Issues

Dial Plans

Symptom

Probable Cause

Corrective Action

Secure Dial Plan

Route Partitions and Calling Search Spaces

Dial Plans and Routing Issues

---

This chapter addresses the following common problems that you may experience with dial plans, route partitions, and calling search spaces.

•Dial Plans

•Route Partitions and Calling Search Spaces

Dial Plans

Symptom

Problems occur when a number is dialed.

Probable Cause

A Dial Plan is a list of numbers and groups of numbers that tells the Cisco CallManager what devices (such as phones and gateways) to send calls to when a certain string of digits is collected. It is analogous to a static routing table in a router. Please be certain your dial plan concepts, basic call routing, and planning have been carefully considered and properly configured before trying to troubleshoot a potential dial plan issue. Very often, the problem lies with planning and configuration. Refer to the route plan configuration chapters in the Cisco CallManager Administration Guide for more information.

Corrective Action

Procedure

---

Step 1 Identify the Directory Number (DN) that is originating the call.

Step 2 Identify the Calling Search Space for this DN.

Step 3 If applicable, identify which device the Calling Search Space is associated with this DN. Make sure that you identify the correct device; because multiple line appearances are supported, it is possible to have the same DN on multiple devices. Note the device's Calling Search Space.

If this is a Cisco IP Phone originating the call, remember that a particular line (DN) and the device that line is associated with have Calling Search Spaces. They will be combined when making a call. For example, if line instance 1000 has a Calling Search Space of AccessLevelX and the Cisco IP Phone that has extension 1000 configured on it has AccessLevelY as its Calling Search Space, then when making a call from that line appearance, Cisco CallManager will search through partitions contained in Calling Search Space AccessLevelX and AccessLevelY.

Step 4 Identify which Partitions are associated with the Calling Search Space(s).

Step 5 Identify to which Partition of the device the call should (or should not) go.

Step 6 Identify which number is being dialed. Note if and when the user is getting a secondary dial tone. Also note what they hear after all the digits have been entered (reorder, fast-busy). Does the user get the progress tones before expecting to hear anything? Make sure that callers wait at least 10 seconds after entering the last digit because they may have to wait for the interdigit timer to expire.

Step 7 Generate a Route Plan Report in Cisco CallManager Administration, and use it to examine all the route patterns for the partitions that are in the Calling Search Space for the problem call.

Step 8 If necessary, add or modify the Route Patterns or Route Filters.

Step 9 If you can find the Route Pattern to which the call is being sent, note the Route List or Gateway to which the pattern points.

Step 10 If it is a Route List, check which Route Groups are part of the list and which Gateway(s) is part of the Route Groups.

Step 11 Verify that the applicable devices are registered with Cisco CallManager.

Step 12 If a gateway has no access to Cisco CallManager exists, use the show tech command to capture and verify this information.

Step 13 Pay attention to the @ sign. This macro can expand to include many different things. It is often used in combination with filtering options.

Step 14 If a device is not part of a partition, it is said to be part of the Null or default partition. Every user should be able to call that device. The system always searches the Null partition last.

Step 15 If you dial an outside number that is matching a 9.@ pattern and it takes 10 seconds before the call goes through, check the filtering options. By default, with a 9.@ pattern, when a 7-digit number is dialed, the Cisco IP Phone will wait 10 seconds before placing the call. You need to apply a Route Filter to the pattern that displays LOCAL-AREA-CODE DOES-NOT- EXIST and END-OF-DIALING DOES-NOT-EXIST.

---

Secure Dial Plan

Use partitions and calling search spaces, in addition to more common filtering based on sections of the @ macro (which stands for the North American Numbering Plan) in a route pattern, to configure Cisco CallManager to create a secure dialing plan for users. Partitions and Calling Search Spaces provide an integral part of security and are especially useful for multitenant environments and for creating an individual user level. Filtering, a subset of the Calling Search Space/Partition concept, can add additional granularity to the security plan.

Be advised that usually the last thing you want to do when trying to fix a filtering problem is to run an SDI trace. There is simply not enough information, and the potential for causing more harm is too great.

Route Partitions and Calling Search Spaces

Route partitions inherit the error-handling capabilities for the Cisco CallManager software. That is, a console and SDI file trace are provided for logging information and error messages. These messages will be part of the digit analysis component of the traces. You must be sure that you know how the Partitions and Calling Search Spaces are configured and what devices are in each partition and its associated calling search space to determine the source of the problem. Refer to the route plan chapters in the Cisco CallManager Administration Guide and the Cisco CallManager System Guide for more information.

The following trace shows an example of a dialed number that is in the device Calling Search Space. For more detailed explanations about SDI traces, review the case studies in this document.

08:38:54.968 Cisco CallManager|StationInit - InboundStim - 
OffHookMessageID tcpHandle=0x6b88028

08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayText 
tcpHandle=0x6b88028, Display= 5000 

08:38:54.968 Cisco CallManager|StationD - stationOutputSetLamp stim: 
9=Line instance=1 lampMode=LampOn tcpHandle=0x6b88028

08:38:54.968 Cisco CallManager|StationD - stationOutputCallState 
tcpHandle=0x6b88028

08:38:54.968 Cisco CallManager|StationD - 
stationOutputDisplayPromptStatus tcpHandle=0x6b88028

08:38:54.968 Cisco CallManager|StationD - stationOutputSelectSoftKeys 
tcpHandle=0x6b88028

08:38:54.968 Cisco CallManager|StationD - 
stationOutputActivateCallPlane tcpHandle=0x6b88028

08:38:54.968 Cisco CallManager|Digit analysis: match(fqcn="5000", 
cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

In the Digit Analysis component of the previous trace, the pss (Partition Search Space, also known as Calling Search Space) gets listed for the device placing the call.

In the following trace, RTP_NC_Hardwood;RTP_NC_Woodland;Local_RTP represent the partitions that this device is allowed to call.

08:38:54.968 Cisco CallManager|Digit analysis: 
potentialMatches=PotentialMatchesExist

08:38:54.968 Cisco CallManager|StationD - stationOutputStartTone: 
33=InsideDialTone tcpHandle=0x6b88028

08:38:55.671 Cisco CallManager|StationInit - InboundStim - 
KeypadButtonMessageID kpButton: 5 tcpHandle=0x6b88028

08:38:55.671 Cisco CallManager|StationD - stationOutputStopTone 
tcpHandle=0x6b88028

08:38:55.671 Cisco CallManager|StationD - stationOutputSelectSoftKeys 
tcpHandle=0x6b88028

08:38:55.671 Cisco CallManager|Digit analysis: match(fqcn="5000", 
cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5")

08:38:55.671 Cisco CallManager|Digit analysis: 
potentialMatches=PotentialMatchesExist

08:38:56.015 Cisco CallManager|StationInit - InboundStim - 
KeypadButtonMessageID kpButton: 0 tcpHandle=0x6b88028

08:38:56.015 Cisco CallManager|Digit analysis: match(fqcn="5000", 
cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="50")

08:38:56.015 Cisco CallManager|Digit analysis: 
potentialMatches=PotentialMatchesExist

08:38:56.187 Cisco CallManager|StationInit - InboundStim - 
KeypadButtonMessageID kpButton: 0 tcpHandle=0x6b88028

08:38:56.187 Cisco CallManager|Digit analysis: match(fqcn="5000", 
cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="500")

08:38:56.187 Cisco CallManager|Digit analysis: 
potentialMatches=PotentialMatchesExist

08:38:56.515 Cisco CallManager|StationInit - InboundStim - 
KeypadButtonMessageID kpButton: 3 tcpHandle=0x6b88028

08:38:56.515 Cisco CallManager|Digit analysis: match(fqcn="5000", 
cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5003")

08:38:56.515 Cisco CallManager|Digit analysis: analysis results

08:38:56.515 Cisco CallManager||PretransformCallingPartyNumber=5000

The key thing to note is that PotentialMatchesExist is the result of Digit Analysis of the numbers that were dialed until the exact match is found and the call is routed accordingly.

The following trace describes what happens when the Cisco CallManager is attempting to dial the directory number 1001 and it is not in the Calling Search Space for that device. Again, the key thing to note is that the digit analysis routine had potential matches until only the first digit was dialed. The route pattern associated with the digit 1 is in a partition that is not in the device calling search space, RTP_NC_Hardwood;RTP_NC_Woodland;Local_RTP. Therefore, the phone received a reorder tone (busy signal).

08:38:58.734 Cisco CallManager|StationInit - InboundStim - 
OffHookMessageID tcpHandle=0x6b88028

08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayText 
tcpHandle=0x6b88028, Display= 5000 

08:38:58.734 Cisco CallManager|StationD - stationOutputSetLamp stim: 
9=Line instance=1 lampMode=LampOn tcpHandle=0x6b88028

08:38:58.734 Cisco CallManager|StationD - stationOutputCallState 
tcpHandle=0x6b88028

08:38:58.734 Cisco CallManager|StationD - 
stationOutputDisplayPromptStatus tcpHandle=0x6b88028

08:38:58.734 Cisco CallManager|StationD - stationOutputSelectSoftKeys 
tcpHandle=0x6b88028

08:38:58.734 Cisco CallManager|StationD - 
stationOutputActivateCallPlane tcpHandle=0x6b88028

08:38:58.734 Cisco CallManager|Digit analysis: match(fqcn="5000", 
cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

08:38:58.734 Cisco CallManager|Digit analysis: 
potentialMatches=PotentialMatchesExist

08:38:58.734 Cisco CallManager|StationD - stationOutputStartTone: 
33=InsideDialTone tcpHandle=0x6b88028

08:38:59.703 Cisco CallManager|StationInit - InboundStim - 
KeypadButtonMessageID kpButton: 1 tcpHandle=0x6b88028

08:38:59.703 Cisco CallManager|StationD - stationOutputStopTone 
tcpHandle=0x6b88028

08:38:59.703 Cisco CallManager|StationD - stationOutputSelectSoftKeys 
tcpHandle=0x6b88028

08:38:59.703 Cisco CallManager|Digit analysis: match(fqcn="5000", 
cn="5000", pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="1")

08:38:59.703 Cisco CallManager|Digit analysis: 
potentialMatches=NoPotentialMatchesExist

08:38:59.703 Cisco CallManager|StationD - stationOutputStartTone: 
37=ReorderTone tcpHandle=0x6b88028

Route partitions work by associating a partition name with every directory number in the system. The directory number can be called only if the calling device contains the partition within a list of partitions to which it is permitted to place calls—its partition search space. This provides for extremely powerful control over routing.

When a call is being placed, Digit Analysis attempts to resolve the dialed address only in those partitions that the partition search space specifies. Each partition name comprises a discrete subset of the global dialable address space. From each listed partition, Digit Analysis retrieves the pattern that best matches the sequence of dialed digits. Then, from among the matching patterns, Digit Analysis chooses the best match. If two patterns equally match the sequence of dialed digits, Digit Analysis breaks the tie by choosing the pattern associated with the partition listed first in the partition search space.