Accepted Solutions
if you can share the gateway configurations we can provide you exact configurations. I would prefer to go with the TrunkGroup. Here mentioned is a sample configurations. And i would strip the extra number from CUCM to make dial-peers simple.
trunk group VG-PRI-TRK
controller E1 0/1/0
framing no-crc4
clock source line secondary
pri-group timeslots 1-31
trunk-group VG-PRI-TRK timeslots 1-31
!
controller E1 0/1/1
framing no-crc4
clock source line primary
pri-group timeslots 1-31
trunk-group VG-PRI-TRK timeslots 1-31
dial-peer voice 20 pots
trunkgroup VG-PRI-TRK
description Local calls to PSTN
destination-pattern 92.......
forward-digits 8
!
dial-peer voice 21 pots
trunkgroup VG-PRI-TRK
description Mobile calls to PSTN
destination-pattern 9[789].......
forward-digits 8
!
dial-peer voice 22 pots
trunkgroup VG-PRI-TRK
description International calls to PSTN
destination-pattern 900T
prefix 00
Note:- instead of channel assigning to the Trunk group you can do the D channel using below command.
Interface S0/0/1:15
trunkgroup VG-PRI-TRK
As you’re using MGCP to control your ISDN circuits you’ll do what you ask for in CM. The dial peer configuration is not applicable to this.
Reading what you wrote once more I see that you're using two different route patterns, 90 that sends calls to the gateway and uses the SIP trunk to you service provider and *90 that uses the MGCP controlled PRIs. To get an automatic switch between these two you would configure this.
- RP that matches whatever you want it to match, for example 90!
- A RG that contains the SIP trunk towards the gateway
- Another RG that contains the MGCP controlled PRIs on the gateway
- Put these RGs into a RL
- Configure whatever number modification you need on the RL/RG level
That's all there is to this, assuming that your gateway configuration is correct.
On the dial peers I would based on the configuration you shared recommend that you do these changes.
no dial-peer voice 102 voip !not needed as dial peer 101 is identical
no dial-peer voice 202 voip !not needed as dial peer 201 is identical
!
dial-peer voice 101 voip
destination-pattern .T !Change this to something more specific than .T as that matches anything. I would put it as 90T if your using that as the common route string
!
dial-peer voice 201 voip
no destination-pattern +91.T !not needed on an inbound dial peer
no session target ipv4:xx.xx.xx.xx !not needed on an inbound dial peer
no session transport tcp !as the outbound dial peer does not have TCP set it is not very likely that the inbound would need this
!
dial-peer voice 400 voip
no session transport tcp
no incoming called-number .T
!Apart from the changes to the dial peers you also need to turn on the Cube functionallity in the gateway for it to act as an SBC. Do that with this and also turn back on the security feature in the gateway.
voice service voip
ip address trusted list
ipv4 ITSP IP 1
ipv4 ITSP IP 2
ipv4 CM IP 1
ipv4 CM IP 2
address-hiding
mode border-element license periodicity days 30
You have not provided the RL/RG details. Please open the route list details on each of the route groups that are included in the route lists and add that information to your document.
What is clear so far is this, on the route pattern used for sending calls to the PRI, ie *9.! you have a discard digit set to PreDot for the called number and your prefixing +226925 to the calling number. So this is what you need to put on the RL/RG level in the route list where you have the RG which holds your MGCP PRI as the second option so that your sending called and calling numbers in the format as your service provider expects it. Also on the other route pattern, the one used primarily for the SIP trunk, you are prefixing the calling number with +91224303. This as well needs to be put on the RL/RG level on the RG used for the SIP trunk as you cannot use the settings on the RP level if you want to achieve what you ask about.
On the MGCP PRI you’re using a CSS for called and calling number transformation named css-ISD. You need to look at what partition(s) that you have in that CSS and what transformation(s) that you have in these partition(s) as that would as well influence how you send these numbers to your service provider.
Glad to hear that! However what you’re describing doesn’t make any sense at all as if the problem was caused by missing partition(s) in a calling search space calls via the route pattern that goes via the SIP trunk, ie the first option in the route list, would not have worked either.
Another thing, although not directly related to the problem you’ve been working on, by what you shared in the documents you have a CSS set for calling/called/redirecting number transformation. As that CSS, named “css-ISD”, doesn’t include any partition(s) used for transformation there is no need to have that set for transformation CSS’s on the MGCP PRIs. Recommend you to clear those settings and reset the MGCP trunks.
Add on bonus information, you should never ever mix call routing with transformations as that will lead to undesirable results. Any partition(s) and CSS(s) used for transformation should not include any selected partition(s) that holds configuration elements used for call routing, such as translation pattern(s), route pattern(s) or directory number(s).
As the OP is using different call patterns for the two PRIs that would not work, at least not without additional configuration.
PRI 1: 90 + "mobile number"
PRI 2: *90 + "mobile number"
So second PRI has a star as the start.
There are different ways that this part can be understood. I read it as the OP wants to keep the current dial patterns, but have the calls be able to use either of the PRIs by automatically adjusting the called number.
There a multiple ways to achieve what you ask about. One way would be to use called party transformation on the RL/RG level to add the star to the path where the second PRI is present for when the caller called 90 "mobile number". Then on the RL/RG level used for the *90 RP do a discard digit on the path to the first PRI for when the caller called *90 "mobile number" to drop the star.
if you can share the gateway configurations we can provide you exact configurations. I would prefer to go with the TrunkGroup. Here mentioned is a sample configurations. And i would strip the extra number from CUCM to make dial-peers simple.
trunk group VG-PRI-TRK
controller E1 0/1/0
framing no-crc4
clock source line secondary
pri-group timeslots 1-31
trunk-group VG-PRI-TRK timeslots 1-31
!
controller E1 0/1/1
framing no-crc4
clock source line primary
pri-group timeslots 1-31
trunk-group VG-PRI-TRK timeslots 1-31
dial-peer voice 20 pots
trunkgroup VG-PRI-TRK
description Local calls to PSTN
destination-pattern 92.......
forward-digits 8
!
dial-peer voice 21 pots
trunkgroup VG-PRI-TRK
description Mobile calls to PSTN
destination-pattern 9[789].......
forward-digits 8
!
dial-peer voice 22 pots
trunkgroup VG-PRI-TRK
description International calls to PSTN
destination-pattern 900T
prefix 00
Note:- instead of channel assigning to the Trunk group you can do the D channel using below command.
Interface S0/0/1:15
trunkgroup VG-PRI-TRK
As you’re using MGCP to control your ISDN circuits you’ll do what you ask for in CM. The dial peer configuration is not applicable to this.
Not rocket science really. You just configure route pattern (RP) and point it to a route list (RL), that contains one or multiple route groups (RG) depending on your specific needs. The RG contains one or many MGCP controlled circuits. If you need to do modifications to either called or calling numbers based on the different circuits used you could do that on the RL/RG level, so then you'd use multiple RG that you put into a RL.
