Accepted Solutions
Try with this.
voice service voip address-hiding mode border-element licence capacity 1 ! voice class uri CUCM sip host ipv4:xxx.xxx.xxx.xxx ;IP for CPE Publisher host ipv4:yyy.yyy.yyy.yyy ;IP for CPE Subscriber ! voice class uri PSTN sip host ipv4:siptrunkXXX ! voice class e164-pattern-map 1 description E164 Pattern Map for called number to CUCM e164 +49445566... ! voice class e164-pattern-map 2000 description E164 Pattern Map for called number to PSTN e164 0T ! voice class server-group 1 ipv4 yyy.yyy.yyy.yyy preference 1 ;IP for CPE Subscriber
ipv4 xxx.xxx.xxx.xxx preference 2 ;IP for CPE Publisher description CUCM server group ! voice class sip-options-keepalive 1 description Used for Server Group SIP OPTIONS PING ! voice translation-rule 1 no rule 5 rule 1 /^...$/ /445566\0/ ! voice translation-rule 2 rule 1 /^\+49445566\(...\)$/ /\1/ ! voice translation-rule 3 rule 1 /^0\(.*\)/ /\1/ ! voice translation-rule 5
rule 1 /^49\(.*\)/ /00\1/
rule 2 /^\+49\(.*\)/ /00\1/
rule 3 /^\+\(.*\)/ /000\1/ ! no voice translation-profile 1 ! no voice translation-profile ccm_incoming ! no voice translation-profile cube_to_ccm ! no voice translation-profile cube_to_provider ! no voice translation-profile provider_incoming ! voice translation-profile cube_to_ccm-out translate called 2 ! voice translation-profile cube_to_provider-out translate calling 1 translate called 3 ! voice translation-profile provider_incoming-in translate calling 5 ! dial-peer voice 1 voip description incoming from provider to cube translation-profile incoming provider_incoming-in voice-class codec 1 session protocol sipv2 no incoming called-number +49445566... incoming uri via PSTN dtmf-relay rtp-nte no vad ! dial-peer voice 9 voip description outgoing to provider from cube no translation-profile outgoing ccm_incoming translation-profile outgoing cube_to_provider-out no destination-pattern . destination e164-pattern-map 2000 voice-class codec 1 session protocol sipv2 session target dns:siptrunkXXX voice-class sip options-keepalive voice-class sip audio forced dtmf-relay rtp-nte no vad ! dial-peer voice 11 voip description outgoing from cube to CM translation-profile outgoing cube_to_ccm-out no destination-pattern 0445566.... destination e164-pattern-map 1 voice-class codec 1 session protocol sipv2 no session target ipv4:xxx.xxx.xxx.xxx session server-group 1 voice-class sip options-keepalive profile 1 dtmf-relay rtp-nte sip-kpml no vad ! no dial-peer voice 10 voip ! dial-peer voice 2 voip description incoming from cucm to cube voice-class codec 1 session protocol sipv2 incoming uri via CUCM dtmf-relay rtp-nte sip-kpml no vad !
This configuration assumes that you send the leading zero for outbound calls, ie you need to remove the discard digit instruction on your route patter(s) in CM so that it is kept when sent to the gateway. That zero will be removed by voice translation profile cube_to_provider-out in the outbound direction on dial peer 9.
Using this as the match statement for sending calls to your service provider is a very bad use.
destination-pattern .
This basically matches anything, so if there is an issue with your CM or as in your case your configuration is all bodged, it would send the call right back to the service provider.
Please describe in as much details as you can share with us on your setup. Including exactly number format you use in CM, how you dial out to the PSTN, how you send called and calling numbers to your SP, how your SP sends called and calling numbers to you and so on.
In general it is good practice to make sure that you do not ever get a match that can send the call back to the same way as it came from as that would create a routing loop. So having the match as just + towards the service provider is not very good as that would also match the numbers sent into CM if there for any reason would be an issue with call routing in the CM. What would happen then is that the second best match would be used and this results in the call being sent back to the service provider.
A few things to mention. You need to have dial peer(s) that has a match statement that match the format of the called number received in each direction. So whatever format of the called number you get from your service provider you’ll need to match that on the dial peers(s) towards CM. The same applies for the opposite direction, ie whatever format you send from your CM to the gateway for calls destined for your service provider you’ll need to match the called number on the dial peer(s) that sends calls to your service provider.
Then in CM you’ll need to have an inbound CSS set on the gateway/trunk that has visibility of the partition(s) where you have your directory numbers.
If you want or need to modify called and/or calling numbers in the gateway, so that it matches the format used in CM for example, you’ll do that with voice translation profiles that has voice translation rules set in them. In general it is good practice to use one rule per direction and not in multiple as it looks like you might be doing as that makes it harder to understand what it is used for.
Translation profiles in the gateway is applied in either the inbound or outbound direction. If you do modify the called number in the inbound direction you’ll need to account for this on the match statement on the dial peer(s) used to send the calls to the receiving end. Ie if you modify the called number inbound from your service provider you’ll need to match the format after the modifications on the match statement on the dial peer(s) towards CM.
If you need to modify the called number in CM you’ll do that with translation pattern(s) and if you need to modify the calling number you’ll do that with for example transformation pattern(s).
For each call that the gateway handles there are always two call legs, one inbound and one outbound, for each leg there is a dial peer used. It can be the same dial peer for both directions, but in general it is better to use separate as that makes it easier to follow and understand the flow of the calls through the gateway.
I would recommend you to read these two documents on how call routing in IOS/IOS-XE works and how voice translation works.
That’s basic stuff. If you read the documents that I shared you would have a good starting point to begin with.
As an example you could do something along with this. If your service provider sends called number as +49445566… to you, then set the same as the destination pattern for your outbound dial peer towards your CM. Next create a voice translation rule that matches +49445566… and copy the wild card digits over to the replacement side. Put this into a voice translation profile and set it to translate called number. Last step set that voice translation profile on the dial peer(s) towards CM in the outbound direction. This should make the call to match an outbound dial peer and also modify the called number to match your directory number format in CM.
