Other: tracking objects to improve failover
Currently, failover could be done using different consecutive serial routes.
For instance, the first one to SIP1 and the second one to SIP2.
This method uses SIP or application timers to move forward to second route. Furthermore, the check must be done for every calls that use the router.
To improve this mechanism, you could introduce the tracking object concept.
In a different dedicated menu, an administrator could be configure objects to monitor, like APPS platform, third party HTTP server, GWs, SIPs, etc.
E.g. Tracking object
track1 - APP platform - ip address x.x.x.x - track monitor (HTTP or PING)
track2 - SIP - ip address x.x.x.x - track monitor (PING or SIP OPTIONS)
...
Track threshold:
If the check fails for more of 3 consecutive times, track1 variable must set to 1, so "target down".
If the check return ok, wait 60 secondd before change the variable state to 0, so "target up".
Using this method, you could offer a special "disable flag" inside the route. The disable status could be conditioning by a track object:
In this case the route 1 from GW1 to SIP1 is valid only if track1 is 0, so target UP. If the track1 change its status to 1, so target down, every further calls will use the SIP2 interface.
Of course a NOT condition could be used also:
Hope this could be interesting for you.
Regards.
For instance, the first one to SIP1 and the second one to SIP2.
route 1 GW1 --> SIP1 - disable condition track1
--> SIP2
This method uses SIP or application timers to move forward to second route. Furthermore, the check must be done for every calls that use the router.
To improve this mechanism, you could introduce the tracking object concept.
In a different dedicated menu, an administrator could be configure objects to monitor, like APPS platform, third party HTTP server, GWs, SIPs, etc.
E.g. Tracking object
track1 - APP platform - ip address x.x.x.x - track monitor (HTTP or PING)
track2 - SIP - ip address x.x.x.x - track monitor (PING or SIP OPTIONS)
...
Track threshold:
If the check fails for more of 3 consecutive times, track1 variable must set to 1, so "target down".
If the check return ok, wait 60 secondd before change the variable state to 0, so "target up".
Using this method, you could offer a special "disable flag" inside the route. The disable status could be conditioning by a track object:
route 1 GW1 --> SIP1 - disable condition track1
--> SIP2
In this case the route 1 from GW1 to SIP1 is valid only if track1 is 0, so target UP. If the track1 change its status to 1, so target down, every further calls will use the SIP2 interface.
Of course a NOT condition could be used also:
route 1 GW1 --> SIP1 - disable condition NOT track1
--> SIP2
Hope this could be interesting for you.
Regards.