09-26-2009 08:04 AM - edited 03-15-2019 07:52 PM
Hi,
This not a real world scenario.
I have a translation pattern 900.xxxxxxxxxx - predot with called party transform mask to direct calls to a range of DNs, for example, 9001617xxx1234. It goes via the standard local RG within the corporate network. This TP has urgent priority unchecked in call manager 7.
I then created a RP - 900.! predot with the intention to direct certain calls out of a pstn gateway. These numbers include the same area code numbers but a different range of subscriber code, say 617xxx7890 plus any other international numbers.
The TP always take precedence, as a result calls intended to go out the pstn gateway always use the TP which will end up as unreachable.
This is confirmed by a DNA. Checking urgent priority does not help.
I am not sure how to go about selecting certain calls to go out the pstn gateway.
I tried route filters but the route filter field in RP configuraion is grey out. I am not really sure how to use route filters for this purpose.
Any help appreciated.
Thanks,
Paul
09-26-2009 12:50 PM
usually 900 calls are blocked from office,
where you want to route calls,
I mean can I get a call flow for both situations
Thanks!
09-26-2009 01:00 PM
It is not blocked because I am not running NANP. The 00 is the international access code.
09-28-2009 11:59 PM
Hi Paul,
900.XXXX XXX XXX and 9.00! should set the Currentmatches falg set to TRUE and CUCM cannot attempt a closest match routing determination, leading to an interdigit timeout.
We may need Digit analysis forest and cucm detailed trace to see if 9.00! is in the forest.
1. You can make more specific the:
900.xxxxxxxxxx pattern
2. Use CSS an partition as an option
Let us know
Thanks
09-29-2009 01:29 AM
If I`m reading this correctly you have two patterns both with the same prefix 900.xxxxxxxxxx (TP) and 900! (PSTN) but you want the TP 900.xxxxx to be used for some calls and the 900! for others ?
What partitions are you using for the TP and PSTN RP to force the TP to be used or are they the same. Since both patterns are generic in that they the prefix are the same 900 then the TP will always be used first since it is more specific due to the x`s in the pattern.The only way you can force the different TP, RP`s to be used is to break out the numbers more 900.1617!, 900.1555! and then have a generic 900! for all others. Bear in mind some countries such as Italy, Germany , Austria and Luxembourg do not have fixed digit lenghts
09-30-2009 05:13 AM
hi
Thanks for the reply, sorry i could not respond to it earlier.
Ignore my earlier post.
Basically, I have a h323 gateway and the I have the following config:
I created the Route patterns first in call manager and then tweak the dial-peers to get it to work.
I don't think I fully understand it but it works.
dial-peer voice 1 pots
incoming called-number .
direct-inward-dial
forward-digits 0
!
dial-peer voice 901 pots
destination-pattern .T
port 0/2/0:15
forward-digits all
!
dial-peer voice 7 pots
destination-pattern 2404....
port 0/2/0:15
forward-digits all
!
dial-peer voice 900 pots
description need the 00 to match the RP 900.!
destination-pattern 1[2-9]..[2-9]......
no digit-strip
port 0/2/0:15
forward-digits all
prefix 00
!
dial-peer voice 4001 voip
destination-pattern 2404....
session target ipv4:x.x.x.x
I also have the following RP in cm7:
900.! , predot - 00 is a international access code < -match dial-peer 901
Q1. I am not sure why I can't use 900.T so i ended up using .T ?
I could not use 900.! for all international calls so I ended up using the following just for
calls to the US:
9.1[2-9]XX[2-9]XXXXXX, predot < - match dial-peer 900
Q2. Why can't I use 9.1[2-9]..[2-9]......, I had to leave out the 9 on the dial-peer 900 ?
Q3. On dial-peer 4001 , I have a 4 digit DN of 4001 with a external mask of 85224044xxx,
am i doing the right config here ?
Appreciate your explanation here.
Thanks and regards,
Paul
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: