I'm trying to find a solution where we can have an outbound dial peer specific to calling number.
What's happening right now is that some of our sites needs to dial 1 to make it a long distance call even it is a local call and that is okay, we do not want the users to get confused, so what we did, we use a voice translation to add 1 and applied it to the outbound dial peer so that the user will just dial the phone number to make a call and the call gets through.
Here's is the scenario
We have a sip trunk in Data Centre A
In Data Centre A
- site 1 (outside the city where the Data Centre A is located)
- site 2 (Inside the city where the Data Centre A is located)
*When site 1 dials a local phone number (since it's outside the city area it is a long distance call). I applied the solution I mentioned above. I added 1 at the beginning of the dialed number so the user will just dial the phone number.
*When site 2 dials a local phone number (since the it's inside the city area it should be just a local call). The call can't get through because of the voice translation that I added on the outbound dial peer, the 1 at the beginning of the dialed number makes the call to be a long distance when the call is really not, so the call is rejected by the service provider.
I'd like to ask for your help on how would I do this. I'm not even sure if this is possible.
Can we have an Outgoing Dial-Peer matching specific to a site?
Is it a single cluster ? Is it a single gateway for both sites ? Both site A and Site b phones are in same partition ?
So if a user dial with 1 do you have RP to match it ? what are the RP's configured on CUCM?
Translation on dial-peer will make things complicated.
One option for this would be this. You match the calling number by using two different inbound dial peers and on these you modify the called number with a prefix so that you can use this on the outbound dial peers to differentiate between calls between the two sites. On the outbound dial peers you modify the called, and if needed calling, number to drop the prefix and anything else to fit your needs.
Thank you for replying guys.
I got it working using translation profile, I added the prefix 1. I know the answer-address only works on Inbound dial peer but I still tried to use it on Outbound dial peer, and it turns out that it really won't work, it ignores the answer-address I put there.
Hi Roger, could I ask for an example dial peers based on the option you suggested?
Your dial-peer should be with incoming called number and not answer-address. Use incoming called number to match the calling number and apply the prefix.
Go through the below document to understand the dial-peer match.
|incoming called-number DNIS_string||This dial peer command defines the called number destination or dialed number identification service (DNIS) string. When properly configured, this dial peer command uses the called number to match the incoming call leg to an inbound dial peer.||Called number (DNIS)|
Currently on vacation, with no access to gateways to pick out an example. So can not get you an actual real life example.
In general this would be the involved elements.
An option for step two and forward is to use dial peer groups (DPG). With this you define on the inbound dial peer what outbound dial peer(s) that should be used. You could see this as hard coding the path through the gateway without actual using the normal match criteria’s in the outbound direction. With this you can skip the whole prefix part.
For more details have a look at this excellent document. https://www.cisco.com/c/en/us/support/docs/voice/ip-telephony-voice-over-ip-voip/211306-In-Depth-Explanation-of-Cisco-IOS-and-IO.html
This is by far the best document available for how dial plan elements operate in IOS.
please keep in mind the scenario with external callers being forwarded to external again (Ext -> CUBE -> CUCM -> CUBE -> Ext).
In this scenario, the Calling number can be anything, so it won't match any of the 2 incoming dial-peers on CUBE and therefore won't work.
So, either you choose on of the dial-peers for this scenario, or choose a different solution for splitting the dial-plan based on calling number.
Personally, if I need such a "tenant"-like scenario, I don't do it with calling numbers.
I do it based on the SIP-source port used by CUCM to send the INVITE to CUBE.