01-03-2014 01:56 AM - edited 03-16-2019 09:05 PM
Hello,
i need configuration support for a voicegateway.
we have two mainnumbers, which are connected by a BRI-interface and a E1-interface.
When they call outside with accesscode = 0, they reache the phone provider and get connected,
But in my example, we have two matching destination-pattern = 0T and .T
When they forget to dial the accesscode, the BRI-Interface with destination-pattern .T is still working and the number manipulation is wrong.
We use H323 to CUCM. MGCP is currently not an option for us.
How can i prevent that on the voicegateway easily?
voice-port 0/0/0:15
description *** E1 ***
input gain 3
echo-cancel coverage 32
no comfort-noise
cptone DE
bearer-cap 3100Hz
!
voice-port 0/1/0
description *** BRI 1 ***
no vad
compand-type a-law
cptone DE
!
dial-peer voice 1 pots
description *** E1 ***
tone ringback alert-no-PI
progress_ind setup enable 3
destination-pattern 0T
direct-inward-dial
port 0/0/0:15
!
dial-peer voice 2 pots
description *** BRI 1 ***
destination-pattern .T
direct-inward-dial
port 0/1/0
01-03-2014 02:33 AM
Can you please paste here output of debug voip dialpeer inout
Rate it if you like the post
Sent from Cisco Technical Support iPad App
01-03-2014 03:45 AM
This is what is called an overlapping dial plan. Its not a good idea to have your dial-peers setup like this..There is not much you can do other than
1. Configure the bri dial-peer to be the same as pri dial-peer but with a lower preference
dial-peer voice 2 pots
destination-pattern 0T
preference 1
With this when the forget to add the access code, the call fails and they dial again with the correct access code
2. Tell them to use the access code..
Option 1 is the best..
Please rate all useful posts
"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
01-03-2014 05:32 AM
Hi Micheal.
First of all +5 to my friend Aok (as usual )
Please remove that direct-inward-dial from outbound dialpeers in order to avoid problems on receiving calls.
HTH
Regards
Carlo
Please rate all helpful posts
"The more you help the more you learn"
01-04-2014 05:20 AM
Hi,
Thank you for helping. I now that i hit here an overlapping pattern what gives me the configuration issue.
But technically asked, how can i have two mainnumbers and same accesscode, but have a routing depends on the mainnumber?
I would think on MGCP, because of directly handeling the interfaces, but this must be solvable by H323?!
I tried it with a prefix, but this is not helpfull. As soon as the setup from callmanager reaches the voicegateway, i only can use a matching destination pattern, what activates a translationrule. My thinking was to seperate both mainnumbers, but for incoming calls this is not a problem, only for outgoing.
Peer my understanding, the call is coming from callmanager. This is matching an incoming dialpeer, where i can use translationrules. The same behavior will apply for outgoing dialpeer to phoneprovider.
My thinking and still my hope, is to use a prefix for all incoming calls from callmanager, which matches the proper outgoing dialpeer.
I have to share my configuration, later.
Besides direct inward dialing is necessary, otherwise you have two stage dialing.
Sent from Cisco Technical Support iPad App
01-04-2014 06:20 AM
The question is how to do you want differentiate calls going to BRI and PRI interfaces...Are you users going to diall different prefix? For this to work calls coming into the gateway need to already have the prefix on them...So how do you want to add the prefix in CUCM?
Please rate all useful posts
"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
01-09-2014 07:05 AM
Hi,
i have attached my current idea with the prefix.
My thinking is that this is choosing the proper interface, but have to test it
Regards Michael
The config is not covering every single parameter, like the ports or destination
01-09-2014 08:45 AM
I tried it with a prefix, but this is not helpfull. As soon as the setup from callmanager reaches the voicegateway, i only can use a matching destination pattern, what activates a translationrule. My thinking was to seperate both mainnumbers, but for incoming calls this is not a problem, only for outgoing.
Peer my understanding, the call is coming from callmanager. This is matching an incoming dialpeer, where i can use translationrules. The same behavior will apply for outgoing dialpeer to phoneprovider.
My thinking and still my hope, is to use a prefix for all incoming calls from callmanager, which matches the proper outgoing dialpeer.
In your translation-profiles you can apply your translation-rules to either calling, called, or redirect called party numbers. You can do your digit manipulation at that point to remove your prefix.
It also sounds like you're dealing with hunting issues. In addition to the preference commands, you can also use the huntstop and even permission commands to limit hunting and add hard incoming/outgoing limitations to your dial-peers.
Although I may have completely misunderstood the issue in which case please ignore.
thanks,
will
01-15-2014 04:38 AM
Hello Will,
i have successfully tested it with prefixes for incoming calls from cucm
and cutting the prefix for outgoing to the provider :-)
It is not the easiest way, but a working one.
Best Regards
Michael
01-27-2014 05:36 AM
Michael,
"When they forget to dial the accesscode, the BRI-Interface with destination-pattern .T is still working "
Which means you must have a route pattern in CCM to forward the calls to GW, when they forget to dial the accesscode
Why dont you configure '0' as a prefix digit on the route pattern / route list ? Which will prefix a 0 even if the user forget to dial access code and will match with 0T dial-peer
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