CUCM 5.1.2 - Internal DN's 9XXX not routing

Answered Question
Aug 24th, 2007

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.

I have this problem too.
0 votes
Correct Answer by juscraig about 9 years 3 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
Correct Answer
juscraig Fri, 08/24/2007 - 09:51

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.

btmulgrew Tue, 08/28/2007 - 13:48

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

juscraig Tue, 08/28/2007 - 14:05

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

Best wishes, let me know!

JC

Actions

This Discussion