It seems that you have some confusion about terminology, a SIP trunk is not the same as a PRI. A PRI is an ISDN type of circuit that carries TDM traffic, it does not carry SIP traffic. I’ll get back to you on your dial peers when I’m in front of a computer.
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
It would depend on your current configuration. I’ve previously suggested changes to your configuration, have you looked through these and incorporated any of them?
How hard can it be to revert back the configuration in the gateway? Off the top of my head I can come up multiple ways to do so. The advice given was based on errors/issues observed in the shared information. It’s up to you if you want to do it, no one forces you.
That’s what Route List and Route Group are for. CM will use this construct to send calls to the secondary option if it fails on the first one.
I assume that you by “transfer calls MGCP PRI” mean send calls via the MGCP PRI? Are there any differences between how you need to send called and calling numbers between the two call paths? If so have you made any changes to the number transformation at the RL/RG level? It’s very likely that there is a difference between the two call paths and that the call is failing to work via the second path because of this. My advice would be to look at what you have configured for each path for a working setup or if you don’t have a working setup to create one per call path. Once you have that you should be able to combine them and set the appropriate configuration parameters to get it to work for the switchover.
Please share screenshots of the route patters you reference and RL/RG level of these. Include the whole page for all of these.
