Translation pattern not working as expected

[ichehouri]

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

[Jaime Valencia]

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

[ichehouri]

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

[Jaime Valencia · Accepted solution]

"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)"

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

[ichehouri]

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

[jawadaliqamar]

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