Simply put the SIP trunk into a Route Group and then put the RG into a Route List where you repeat the same for another egress point via something else than the SIP trunk, it could be a SIP trunk at another location or any other type of connection with a service provider. Set the order of the entities in the RL with the primary egress point as ordered first in the list and put the routing algorithm to top down. Then change your RP to point to this RL instead of direct to the SIP trunk.
With this routing functionality in CM will send the call via the primary link as long as it’s operational and send calls via the secondary link if the primary is down.
That does not work as there is no such option. Line Group is an internal routing concept and it cannot be used together with route pattern(s) as these are an external routing concept.
I don’t see that a CTI RP would be an option, apart from this remote destination is not related to CTI RT, that’s a thing for Mobile Connect, aka Remote Destination Profile or TCT/BOT devices.
If you do the secondary call routing in your SBC gateway you would not need to have a second option in your route list. You’ll do the entire call routing modification in the SBC gateway.
If you share your SBC configuration and a little bit of more details around the number that you would want calls to redirect to when your egress path is unavailable we can likely give you a hand with the configuration.
What you could do is configure alternate dial peer call routing in the SBC where you have the SIP trunk demarcation from your service provider. With this you should be able to send calls to an alternate destination if the primary dial peer option is down based on no response from your provider on SIP option ping.
To make it easier and more specific to help you out would it be possible for you to share at least the current dial peer configuration? You can redact any sensitive information from it, as long as the overall use of each dial peer is kept visible.
I'm sorry but that output does not seem to be coming from a gateway that acts as an SBC, ie a router that is running the Cube functionality to act as a Session Border Controller to terminate a SIP connection with a service provider.
How are you're SIP trunk setup, is it directly in CM to the SP or are it in a gateway (SBC) to the SP? IE either of these two options.
- CM -> SIP trunk -> SP
- CM -> SIP trunk -> SBC -> SIP trunk -> SP
You technically could do the reroute on whatever, but it would be quite unclean so my recommendation would be to do it on the SBC. If the connection to the SP is down it would have no load at all, so that should not really be an issue that you need to worry about. Apart from this doing this on a MGCP gateway is a quite terrible idea as that would not have any idea on how to do this reroute. You'll need to do this on a SIP, or if your old school H.323, gateway as they have the control of the call natively in IOS, whereas with MGCP it's actually CM that has the control of the call routing by the back-haul channel.
This would likely involve EEM scripting that triggers on SIP option ping for the SP connection being down and then doing the re-route via a dial peer that the script brings up by a no shut.
The use of the EEM script would be to not have call loop occur on the occasion that the call fails to the service provider when the link would still be operational, ie meaning that there is some issue with the call routing because of wrongly formatted called number, or calling for that matter.
