Automatic trunk fall-over on loss of trunk

[NoelB]

I have an obi202 set-up using sp1 and sp2 with different voip providers. Different DMs are set up to use least cost routing based on number dialled and works perfectly. On loss of sp1 I can enter **2 and dial the same number but it will go out via sp2 . Routing via {**2(Mall):sp2} where (Mall) is ((Msp1)|(Msp2)).
I would like to set up a TG that will do it automatically.
I have seen posts of using tg1 (sp1,sp2) and tg2(sp2,sp1) with trunk DM ((Msp1)|(Msp2)) but this only works if (Msp1) is the same as (Msp2).
Is there a way to set up so that a call normally routed via sp1 can be sent automatically ,on loss of sp1 ,via sp2 without being blocked by sp2 DM  (Msp2) using trunk groups?

[azrobert]

Here is a sample TG config and explanation. 11 digits routed to SP1. International routed to SP2. 11 digits failover to SP2.

Phone Primary Line: Trunk Group 1
Phone DigitMap last rule is "(Mpli)". This translates to "(Mtg1)" because the primary line is TG1
Phone Outbound Route last rule is "{(Mpli):pli}". This translates to "{(Mtg1):tg1}".
You don't need any changes to the default DigitMap or Outbound Route.

ITSP A DigitMap: (1xxxxxxxxxx)

ITSP B DigitMap: (011xx.|1xxxxxxxxxx)

Voice Services -> Gateways and TGs -> Trunk Group 1
Trunk List: sp1,sp2
DigitMap: ((Msp1)|(Msp2))

Voice Services -> SP1 Service: X_NoRegNoCall: Checked

Service Providers ITSP A -> SIP -> TimerB: 10000

1st the Phone DigitMap validates the dialed number. If the number matches a pattern, the Outbound Route gets control.
If the number matches (Mtg1) in the Outbound Route, the call is routed to TG1. This is the only (Mtg1) function. It is not used to route the call to a trunk.

The Trunk List will route the call. Each trunk in the trunk list uses its corresponding DigitMap. This can't be changed. This is different than the normal outbound route process where you can compare the dialed number to virtually anything to route the call to a trunk.

The Trunk List is processed left to right.
An 11 digit number is compared to (Msp1). It will get a match and be routed to SP1. If the call fails, the number will be compared to (Msp2). It will get a match and be routed to SP2.

An international number is compared to (Msp1). It will not get a match and SP1 will be bypassed. It then will be compared to (Msp2). It will get a match and be routed to SP2.

There will be a 32 second wait before the call failovers. When X_NoRegNoCall is enabled the call will immediately failover when the trunk is not registered to the provider.

It is my understanding that the OBi might think the trunk is still registered when the trunk is down. There is a registration period and the OBi might not know the trunk is down until the registration period expires and the OBi tries to re-register. In this case the OBi will wait 32 seconds (defined in TimerB) before it failovers. I changed TimerB to 10 seconds. You can probably make it less, but if you make it too low you will get a false failover.

I defined (Mtg1) as ((Msp1)|(Msp2)). The (Msp1) is redundant and not needed. (Msp2) has all the needed patterns defined. I thought it might be confusing if I only used (Msp2). You can't use a rule like "xx." in (Msp1). If you do, all calls will be routed to SP1.

[NoelB]

Here is a sample TG config and explanation. 11 digits routed to SP1. International routed to SP2. 11 digits failover to SP2.

Hi azrobert I was hoping you might chip in because I have read some of your posts on this topic when I was searching the forum. I have probably missed a heap too because the search feature is not the greatest.
I have taken a screen shot of this sample TG config so I can spend time to fully understand the logic as I implement it to my situation.
I will post back in due course and advise how I got on. Many thanks as I was beginning to think it could only be achieved if both sp1/2 DMs were the same.

[NoelB]

All understood and implemented. I never thought of using this ingenious method for  matching a call intended for sp1 with the sp2 DM and not upsetting the normal routing when both trunks are in service.
Simulating a failed trunk for testing is ok but I am hoping to be around when registration fails to try and understand how the obi actually decides that trunk registration has failed. Probably not very likely.
Anyway thanks again.