Failover Groups

Last Updated : Dec 01, 2023 |

Failover Group consists of two active Session Manager instances that are interconnected to ensure high availability of Session Manager services.

During normal operations, one Session Manager instance in Failover Group is active and handles calls. The other Session Manager instance is active as a backup. In cases when the preferred Session Manager instance fails to handle a call or becomes unreachable to the peer SIP entities, the failover mechanism preserves the session information and switches the call control from the failed Session Manager to the backup Session Manager. The backup Session Manager then uses the preserved session information and resumes the call.

You can associate peer SIP entities with Failover Group. The peer SIP entities can detect a Session Manager failure and reroute the call to the backup Session Manager.

Each Failover Group has a Group Name and a unique Failover Group Domain Name (FGDN) for each Session Manager instance in the group. The peer SIP entities use the FGDN to resolve the preferred and the backup Session Manager instances at the time of network outage. Failover Group has the following two ordered resolution sets:

  • Session Manager 1 Preferred Domain Name resolves the preferred Session Manager as high priority and the backup Session Manager as secondary.

  • Session Manager 2 Preferred Domain Name resolves the backup Session Manager as high priority and the operational Session Manager as secondary

In some cases, the source and the destination entities in a call do not have the same Failover Group domain associations. To preserve a call in such cases, the Session Manager Failover Group provides a Two-Tier Routing mechanism known as route-through. The Two-Tier routing mechanism ensures that during a Session Manager outage, either entity can route responses or mid-dialog requests using alternate Session Manager instances of different Failover Groups.

When you add Failover Group, the system runs an entity link audit to verify that each Session Manager in Failover Group is connected to every other Session Manager in the group using a TCP and a TLS entity link and the administered failover ports of each Session Manager. The Entity Link audit process determines:

  • If one or more entity links have not yet been added.

  • If existing entity links do not use the correct listen ports or are not trusted.

For example:

  1. Session Manager1 and Session Manager 2 constitute one Failover Group.

  2. Session Manager 2 and Session Manager 3 constitute another Failover Group.

  3. Session Manager runs the audit.

  4. The audit generates the missing entity links automatically between Session Manager 1 and 2, Session Manager 2 and 3, and Session Manager 1 and 3 for the failover ports for each transport type. The link between Session Manager 1 and Session Manager 3 is a newly generated link.

For more information regarding system administration for different configurations, see Call Preservation Feature Description and Administration Guide on the Avaya support website.