Appearently weird behavior with translation patterns on CUCM 15

[mm322]

Hello everyone,

sharing the below experience so that someone might provide an explanation to an appearently mysterious behavior on the CUCM 15 of a customer.

Two translation patterns configured for calls incoming from the PSTN:

1) 08888.2XXX in Partition A (Called Party Transform Mask = 5432)
2) 088882XXX in Partition A (Called Party Transform Mask = XXXX)

Right after replacement of the PSTN SIP trunk gateways, all calls entering into the CUCM with the number 088882XXX would match the translation pattern (1) and go to 5432.

As the expected match was on 088882XXX and since I could not figure out why now 08888.2XXX was matched, I deleted the latter 08888.2XXX.

Obviously this forced all calls matching 088882XXX and this was ok.

I then re-created the translation 08888.2XXX just as it was before the deletion, but this time 088882XXX was still matched.

So the question is: why 08888.2XXX was first match before being deleted, and became second match after being deleted and re-created?

Not very clear to me.

Any tips on this?

Thanks in advance.

MM

[Maren Mahoney · Accepted solution]

First let me say that I'm surprised CUCM allowed you to make those two translation patterns in the same partition. Really surprised. Really, really surprised.

But as that they are functionally equivalent and in the same partition, my guess (given what I know of CUCM) is that it came down to the order in which they appear in the table in the database as the final tie-breaker. So, the 'first' one created in relation to the other would win. I've seen other 'first in table' tie-breakers in other contexts (not CUCM), so the behavior is not unknown.

If I may ask: Do you plan to leave the two translation patterns in the system? I am curious about what behavior you are looking to achieve.

Maren

[mm322]

Thanks Maren for your feedback, let me first say that your final question is my question.

Not sure that the customer knows the response as I feel that it was a test or old configuration made by some former IT partner which was forgotten there.

Although I am still confused and amazed by such finding your explanation seems the only one making sense.

Thank you, I will accept it as the solution.

[mm322]

PS attaching a screenshot of the two "twin" translation patterns.

[Roger Kallberg]

Not to be picky, but you originally wrote that it was translation patterns, not route patters as you have in your screenshot.

[mm322]

You are right I mistakenly attached a wrong screenshot (which was just a test to confirm that the same happens with other kinds of dial plan patterns).

I have now uploaded the intended screenshot. Thanks for mentioning this.