Partition ordering within a CSS - does search roll from top to bottom?

jeffrey.girard · ‎02-27-2008

I posted a previous topic about fast busy using CER. I found a cryptic solution buried on the CCO site. It works, but I am unsure of why it works. Within a CSS are multiple partitions lets say Partition A and Partition B. These paritions are ordered so that Partition A is first and Partition B is second. Phone places a 911 call that is correctly routed to the CER. The output of the CER action is a dial pattern with a match within Partition B. The result is a fast busy. If I move Partition B to the top of the CSS list, the call executes as it should.

I thought that CM would search the CSS from the top partition down until it found a match. In this case, it appears that if it does not find a match in the first partition, the calls fails to fast busy.

I can post more details of the exact CSS, partions, route points, CER handling, etc if needed.

Jeff

Rob Huffman · ‎02-28-2008

Hi Jeff,

I can't answer your question specifically, but I thought that I would include this info anyways that describes the relationship between CSS and Partitions in regards to the search method *** and why this is happening;

A partition comprises a logical grouping of directory numbers (DNs) and route patterns with similar reachability characteristics. Devices that are typically placed in partitions include DNs and route patterns. These entities associate with DNs that users dial. For simplicity, partition names usually reflect their characteristics, such as "NYLongDistancePT," "NY911PT," and so on.

A calling search space comprises an ordered list of partitions that users can look at before users are allowed to place a call. Calling search spaces determine the partitions that calling devices, including IP phones, soft phones, and gateways, can search when attempting to complete a call.

When a calling search space is assigned to a device, the list of partitions in the calling search space comprises only the partitions that the device is allowed to reach. All other DNs that are in partitions not in the device calling search space receive a busy signal.

Partitions and calling search spaces provide a way to segregate the global dialable address space. The global dialable address space comprises the complete set of dialing patterns to which the Cisco CallManager can respond.

Partitions do not significantly impact the performance of digit analysis, but every partition that is specified in a calling device search space does require that an additional analysis pass through the analysis data structures.

*** The digit analysis process looks through every partition in a calling search space for the best match.

*** The order of the partitions that are listed in the calling search space serves only to break ties when equally good matches occur in two different partitions. If no partition is specified for a pattern, the pattern goes in the null partition to resolve dialed digits. Digit analysis always looks through the null partition last.

Hope this helps!

Rob

jeffrey.girard · ‎02-28-2008

Rob,

Thanks for taking the time to respond, but as you said it does not answer my question.

In the CER Admin Guide 1.3(1) page 3-7 is the following text:

Note You must list the E911 partition before the Phones partition for the

following reason: When the user configures the translation pattern 911 or

9.911 (see the â€œCreating the Translation Patterns for 9.911â€ section on

page 3-18), the 911 Route Point will be in the E911 partition; phones

cannot look into the E911 Partition. The 911 Translation Pattern is in the

phones partition and gets the E911CSS. When the E911 partition is listed

first, it matches the 911 Route Point and the call goes to the Cisco ER

server as intended. If you make the error of listing the Phones partition

first, the Translation Pattern keeps searching, resulting in a fast busy

signal.

By rearranging the partitions within the CSS, this fixed my problem. However, I am still unsure as to why. Whether the match is in Partition A or Partition B, the match SHOULD be found.

Anyone have any insight?

Sascha Monteiro · ‎02-29-2008

quote from the srnd;

"the partition order in a calling search space is used exclusively as a tie-breaker in case of equal matches based on the closest-match logic"

jeffrey.girard · ‎02-29-2008

Yup, got it. Thats what I had always believed. But reality is indicating something different. I posted here hoping that someone could explain why the partition ordering has impacts other than as a tie breaker. Specifically, if I place the phones partition first in the list above the E911 partition, I get fast busy. If I place the E911 partition first, the calls complete as expected.