topic Re: Translation pattern not working as expected in IP Telephony and Phones

Translation pattern not working as expected

ichehouri — Sat, 16 Mar 2019 09:16:21 GMT

Hi,

I have CUCM 8.0(3) cluster with centralized call processing for 300 remote branches. the cluster is in main location and is having extensions 2XXX, 3XXX, 4XXX. the remote sites are having extensions 6<4 digit branch number>2XXX. the remote branches are having gateway running SRST and CUE (for AA and VM)

users in same branch call each other by 4 digit extension and calls other branches as 9 digit (extension full number). Users CSS is having TP partition (change 4 digit into 6<branch number>2XXX ) as the first partition in the CSS, then the Global partition for all phones then the external calls partitions.

i am having a plan to change the main site extension (2XXX, 3XXX and 4XXX) into 9 digits but this will require some time for approval

All my phones are in one Global partition

the issue iam having is that when user in branch number 1234 (user extension 612342500) calls a user in the same branch as 4 digits (extension 2501) then if a user exists in main site with 2501 as extension the call will ring in main site extension instead of translating into 9 digit extension for the local user. I did some troubleshooting where i removed the Global partition from the user CSS then the call worked as expected (translated into 9 digit and the local user get the call). But the disadvantage of this is that i can't call other branches.

I am wondering why the order of partition did not work as expected. is there any explanation for that (is this a Bug or what?)

i am thinking to have the extensions 2XXX in main site in separate partion (other than the Global one) since it is the only range with overlabing with other branches.

if there is a way to solve the above please advice.

regards,

Ibrahim

Re: Translation pattern not working as expected

Jaime Valencia — Sun, 05 Dec 2010 03:35:36 GMT

Unless the TP is EXACTLY the same as the DN in main site there is nothing wrong here.

CUCM uses the best match, I'm assuming you have a phone with DN 2501 and the TP looks something like 2XXX. If so, no bug, WAD.

ONLY if you had a 2501 DN and a 2501 TP and the TP partition was in a higher preference in the CSS it would do what you expect.

Ideally you should have at least 2 partitions, main site and remote sites. A better design would be to have more than 2 partitions to segregate this (without full details, 1 per branch.).

Unless you want to create a perfect match TP for the whole range you can only solve this by using partitions for the phones.

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

Re: Translation pattern not working as expected

ichehouri — Mon, 06 Dec 2010 07:58:13 GMT

Hi Java,

thanks for the reply. You are right in your assumption I have a phone with DN 2501 and the TP is 2XXX (preffix 60118). Since the partition order in the user CSS is having the TP partition as the first one then i should have this TP being hit before any other partition (in this case before the Global partion of the phones)

You are saying that CUCM uses the best match but as i know this case is applicable if iam dialing something and the destinations to match are in same partition while my case is different (TP is having a partition different than the global one and is the first in the CSS and it is logical to hit first)

i can't have different partitions for different branches since it is too late to change now after customer approval of the design.

any ideas please.

regards,

Ibrahim

Re: Translation pattern not working as expected

Jaime Valencia — Mon, 06 Dec 2010 14:30:14 GMT

"thanks for the reply. You are right in your assumption I have a phone with DN 2501 and the TP is 2XXX (preffix 60118). Since the partition order in the user CSS is having the TP partition as the first one then i should have this TP being hit before any other partition (in this case before the Global partion of the phones)

That is ABSOLUTELY WRONG.

CUCM ALWAYS uses the best match logic.

2501 = 1 match

2xxx = 1000 matches

For example, consider Figure 9-35, where route patterns 1XXX and 23XX are part of Partition_A and route patterns 12XX and 23XX are part of Partition_B. The calling search space of the calling device lists the partitions in the order Partition_A:Partition_B. If the user of this device dials 2345, Unified CM selects route pattern 23XX in Partition_A as the matching entry because it appears first in the calling device's calling search space. However, if the user dials 1234, Unified CM selects route pattern 12XX in Partition_B as the matching entry because it is a closer match than 1XXX in Partition_A. Remember that 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.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/dialplan.html

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

Re: Translation pattern not working as expected

ichehouri — Wed, 08 Dec 2010 08:52:39 GMT

You are right Java, i missed this concept. Now iam changing all the phones with 2xxx extension into 9 digit extension so that i will not have this issue.

thanks for the support.

regards,

Ibrahim

Re: Translation pattern not working as expected

jawadaliqamar — Tue, 13 Jun 2023 10:12:48 GMT

Hey Jaime,

Can you please explain which logs we can look at to troubleshoot/verify that translation pattern is working fine? My question is specifically related towards use of RTMT tool to find the logs showing the translated patterns successfully. OR if there is another way, please do mention.

Regards,

Jawad