# HST COURTESY_HANDOFF

## Qualifiers:

None

## Purpose:

Use this command to transfer IP resilient sets to the secondary controller when the primary controller needs to be rebooted.

1. Enter this command on the primary controller.

2. The primary controller waits until each IP resilient set is IDLE before it passes control over to the secondary controller. To avoid overloading the secondary controller, the IP sets are transferred in batches of five IP sets. The batches are sent over to the secondary controller at intervals of 0.5 seconds.

3. Enter the HST STATUS_HANDOFF command to check the transfer status of the IP resilient sets.

## Details:

- You must enter this command on the primary controller.

- You will see an error message if you enter this command on the secondary controller.

- If the Secondary ICP is unreachable, the IP resilient sets will remain on the Primary ICP until system reboot or until the Secondary ICP is in service again.

- You can cancel a HST COURTESY_HANDOFF that is in progress by entering the HST CANCEL_HANDOFF command.

- If an IP resilient set has already failed over to the secondary controller, it will remain there until the Courtesy Handoff is cancelled or until the primary controller is rebooted. After the cancel or reboot, the IP resilient sets will fail back normally.

NOTES

- The HST COURTESY_HANDOFF command will have no effect on non-resilient sets. They will be out of service during ICP upgrades, reboots or failures.

- The HST COURTESY_HANDOFF command will not fail over groups such as Personal Ring Groups, Ring Groups, Resilient ACD, or Resilient Hunt Groups.

## Example:

### Entry: HST COURTESY_HANDOFF

### System Response:

Sending COURTESY_HANDOFF Msg...

For the status type HST STATUS_HANDOFF

If you enter the Courtesy Handoff command twice, the system response is

COURTESY_HANDOFF already called

Related Topics

- HST CANCEL_HANDOFF

- HST STATUS_HANDOFF