I have a CSS which contains two partitions. One partition contains a translation pattern for 9.XXXXXX and the other a route pattern for 9.XXXXXX. If the translation pattern partition is above the route pattern partition in the CSS, I would expect the translation pattern partition to be matched first. However, the translation pattern appears to be ignored and the route pattern in the CSS is always matched.
I can workaround the problem, but is this behaviour by design?
The rule is closest match always wins, regardless of partition order. Partition order only comes into play if there are multiple identical patterns to match on. In this case, they are processed in
partition order. See Giralt, p 461.
If they are in different partitions, the partition of whichever route pattern appears first in the CSS will be the one chosen. If they are in the same partition, the result will be unpredictable, but I have found that whichever one was added first will be the one chosen (this is not always the case).
please rate posts
adignan - berbee
In this case, an identical pattern exists in P_TP and P_RP and P_TP is above P_RP in the CSS, so I would expect the P_TP pattern to be matched when there is a tie
I did wonder whether there is a subtle difference in how partitions containing route patterns and partions containing translation patterns are processed in a CSS.
Yes, you are right. It should match the P_TP first.
As you know, translation patterns are used for calling/called party digit manipulation. After a translation pattern is matched, Callmanager would do one more round of digit analysis to find out were to send the call and that is when it matches the route pattern.
I guess, you are not doing any called party transformation on the translation pattern and the CSS of the translation pattern includes the P_RP.
This is what could be happening.
1. User dials 9123456
2. First iteration: Match translation pattern 9.XXXXXX
3. Outcome of the translation pattern = 9.XXXXXX
4. Second iteration: Match route pattern 9.XXXXXX
5. Route the call
The CSS of the translation pattern doesn't contain P_RP. All the translation pattern is doing is setting the Calling Line ID presentation indicators to "Restricted"; it's not performing any called digit manipulation.
If instead, the translation pattern is set to something more specific, say 9.123456 (still with a route pattern of 9.XXXXXX in a different partition in the CSS), then the translation pattern is matched, but that should't be surprising as it's more specific. It's only when a identical translation pattern and route pattern exist in the same CSS (in different, but ordered partitions), does the translation pattern not get processed, even though it has a higher priority in the CSS.
I've used Dialed Number Analyzer and it's clear that the route pattern is matched in preference to the translation pattern when there is a tie. The translation pattern is listed, under "Alternate Patterns", but is isn't chosen, even though its partition is higher in the CSS.
I tested it in my lab system and it is matching the translation pattern. I am running CCM 4.1.3.
On the phones, do you have CSS set at both the line level and device level? If yes, are they different or the same?
None of the Route Patterns have "Urgent Priority" configured. I'm going to have to see whether I can recreate this in a test environment.
Interesting. I'm using 4.1(3)SR2 here. We have a CSS on the device too but just for emergency call handling; the CSS in question is on the line. I have removed the device CSS and it makes no difference.
Yes, I managed to get it working as expected on my lab system.
Some of the Route Patterns on the Production System were actually more specific than the general translation pattern, so the route pattern was being matched in those cases. What an idiot! :)
However, this can be worked around by moving the partitions containing the route patterns out of the CSS containing the translation pattern partition, and then use the CSS of the translation pattern to ultimately match the route patterns.
Interestingly, it does appear than I can use 9! in the translation pattern and it works without the interdigit timeout coming into play for variable length route patterns in its CSS.