cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
400
Views
3
Helpful
3
Replies

CUCM 5.1.2 - Internal DN's 9XXX not routing

btmulgrew
Level 4
Level 4

Hi - Our customer has decided on a 9XXX internal DN plan. We have managed to workaround some difficulties but are experiencing some issues when dialling to anything other than 91XX internally (e.g. 9310). This will work fine when the partition to the "9.@ GBNP" route pattern is not included in the DN line CSS, but when we include this (for PSTN calls) there is a delay of approx 30 seconds before the called DN rings. Does anyone know why calling this range (e.g. 9310) trys to use the route pattern and introduces so much delay but 91XX doesnt,and is there a way round this? BTW all internal DNs are in the same partition.

1 Accepted Solution

Accepted Solutions

juscraig
Cisco Employee
Cisco Employee

First, it's a bad idea to have an internal range that starts with 9XXX, because of the fact 9 is your access code for outside calls. There is going to be overlap and thus create problems such that you are experiencing.

You are getting the delay because when you dial 9310, it's also matching your 9.@ macro and waiting for a best match.

Having said that, I don't know your entire dial plan, so it's hard to determine why you are getting delay on 9310 but not 91XX. It's all the beginning problem of using 9XXX as an internal dial plan. If you were to use 7XXX, and delete all the 9XXX extensions from the DB and route plan report, I think you would have much better results.

Further, you could ditch the @ macro and create a better match dialplan using wild cards. This could mitigate your issues, it's always best to provide best matches, rather than letting that 9.@ macro do antything.

View solution in original post

3 Replies 3

juscraig
Cisco Employee
Cisco Employee

First, it's a bad idea to have an internal range that starts with 9XXX, because of the fact 9 is your access code for outside calls. There is going to be overlap and thus create problems such that you are experiencing.

You are getting the delay because when you dial 9310, it's also matching your 9.@ macro and waiting for a best match.

Having said that, I don't know your entire dial plan, so it's hard to determine why you are getting delay on 9310 but not 91XX. It's all the beginning problem of using 9XXX as an internal dial plan. If you were to use 7XXX, and delete all the 9XXX extensions from the DB and route plan report, I think you would have much better results.

Further, you could ditch the @ macro and create a better match dialplan using wild cards. This could mitigate your issues, it's always best to provide best matches, rather than letting that 9.@ macro do antything.

Thanks juscraig - it looks like the local 7 digit area code is the cause of the overlap (e.g 9 310 XXXX). We have passed this info onto the customer who is to make a decision.

Thanks again

Great! Don't forget to rate posts that assist in resolving your problems.

Best wishes, let me know!

JC

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: