The intent of this feature is to return a fragmented network, where a number of branch gateways are being serviced by one or more Survivable Remote Servers, to the primary server in an automatic fashion. This feature is targeted towards all branch gateways. The main driving force for this feature is the fact that, when a gateway is receiving service from a Survivable Remote Servers, the notion of the big single distributed switch is no longer the case; therefore, resources are not being used efficiently. By migrating the gateways back to the primary automatically, the distributed telephony switch network can be made whole sooner without human intervention, which is required today.
This feature also only addresses when a gateway shall return to the primary controller, and does not explicitly address how call recovery is attempted during the return. Ideally, the fragmented network should be self-healing, and that process should be transparent to all users whether they are currently on a call or not (in other words, no phones resetting or calls being dropped).
The auto-fallback migration, in combination with the connection preservation feature for H.248 gateways is connection-preserving. Stable connections will be preserved; unstable connections (such as ringing calls) will not be. There still may be a very short interval without dialtone for new calls.
The feature is composed of client and server components, where the client side is the gateway and the server side is the Communication Manager server. The client actively attempts to register with the primary server while it maintains its H.248 link to the Survivable Remote Servers. This is being done, so that the server can permit a registration or deny it. When a gateway is being serviced by a Survivable Remote Servers, then the Primary Server has the option to deny a registration in cases where the server may be overwhelmed with call processing, or based upon system administration.
The gateway presents a new registration parameter in the Non-Standard Data that indicates that Service is being obtained from a Survivable Remote Servers, and indicates the number of calls currently active on the gateway platform (number of active user calls). The server administers each gateway to have its own set of rules for Time of Day migration, enable/disable, and the setting of context threshold rules for migration.
Using this feature, the administrator can define any of the following rules for migration:
The gateway should migrate to the primary automatically, or not.
The gateway should migrate immediately when possible, regardless of active call count.
The gateway should only migrate if the active call count is 0.
The gateway should only migrate within a window of opportunity, by providing day of the week and time intervals per day.
This option does not take call count into consideration.
The gateway should be migrated within a window of opportunity by providing day of the week and time of day, or immediately if the call count reaches 0.
Both rules are active at the same time.
The Minimum Time of Network Stability field is adjustable to fit the recovery strategy.
Internally, the primary call controller gives priority to registration requests from those gateways that are currently not being serviced by a Survivable Remote Servers. This priority is not administrable.
A more detailed discussion and administrative procedures for Auto Fallback to Primary are in Administering Network Connectivity on Avaya Aura® Communication Manager, Administering Network Connectivity on Avaya Aura® Communication Manager.
