08-24-2007 06:12 AM - edited 03-14-2019 11:13 PM
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.
Solved! Go to Solution.
08-24-2007 09:51 AM
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.
08-24-2007 09:51 AM
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.
08-28-2007 01:48 PM
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
08-28-2007 02:05 PM
Great! Don't forget to rate posts that assist in resolving your problems.
Best wishes, let me know!
JC
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide