This sections shows the basic operation of the auto fallback to primary for branch gateways feature. By default, this feature is disabled in the gateway or server.

If the gateway is initially registered with an older server, the gateway uses the version information exchange to prevent fallback to the primary automatically.

• By administering this feature on a server, this feature can be enabled for any or all gateways controlled by the server.

  The enable or disable administration on the server determines whether the server accepts or denies registration requests. The requests are sent with a parameter that service is being obtained from a survivable remote server. However, the gateway continuously attempts to register with the server, even if the server has been administered never to accept the registration request. When the auto fallback feature is disabled on the server, the server is administered to never accept registration requests. Then, a manual return of the gateway is required, which generates a different registration message that is accepted by the server.

  Note:

  The registration messages are still valuable when auto fallback is disabled on the server. Because registration messages function as keep-alive messages, these messages can be used to monitor the stability of the network over time.

• The permission-based rules that include time of day and context information are only available with the server.

  The survivable remote server does not require any of these translations.

• When associated with a primary controller running Communication Manager, the gateway attempts to register with the primary controller when connected to a survivable remote server.

  This registration attempt happens every 30 seconds after the gateway can communicate with the primary controller. The registration message contains an element that indicates that a survivable remote server is servicing the gateway. The message also contains the number of active user calls on that gateway.

• On the initial registration request, the primary controller starts the encrypted TCP link for H.248 messaging.

  The TCP link is started for H.248 messaging regardless of whether that initial registration is successful. The encryption is maintained throughout the period when the registration requests are valid. The encryption is also maintained after a registration is accepted by the primary controller. Encryption of the signaling link is performed at the outset during this automatic fallback process. The encryption ensures the security of the communication between the primary call controller and the gateway.

• The primary controller, based on the administered rules, can allow or deny a registration.

  If the primary controller gets a registration message without Service State information, then the primary honors those registration requests above all others immediately. Registration messages can originate without Service State information, for example, from an older gateway, or when a new gateway is without service.

• If registration is denied, the gateway continues to send the registration message every 30 seconds, which acts as a de facto keep-alive message.

• The gateway constantly monitors the call count on the platform and asynchronously sends a registration message when 0 context is achieved.

• After the registration message is accepted by the primary, the H.248 link to the survivable remote server is dropped.