# Clustered Hospitality Conditions

## General

- Clustered Hospitality requires a fully-meshed cluster of MiVoice Business systems in which the telephone directories are maintained via RDN Synchronization.

- All elements in the cluster must be running 3300 ICP Release 8.0 or greater with SDS
  See System Data Synchronization. enabled and must be uniformly configured.

- The cluster elements must be interconnected by IP trunks.

- Only one Hospitality Gateway is allowed in the cluster.

- To ensure that hotel reports and GRS operations are fully distributed throughout the Hospitality cluster, the maximum number of ICPs allowed in a Hospitality cluster is 200.

- The cluster can contain elements not configured as part of the Hospitality cluster.

- The Property Management System and IP Console application( MiVoice Business Console) must be connected to the Hospitality Gateway. Consoles connected to other cluster elements will be denied access to the Guest Services application.

- The Guest Services Application on the 5540 IP Console is not supported in a Clustered Hospitality environment.

- Hospitality functionality does not support device resiliency. Devices can be programmed as resilient but the hospitality service will not be synchronized between primary and secondary ICPs (nor is hospitality service provided at the secondary).

- An external voice mail system, such as Mitel MiCollab Nupoint UM or NuPoint Unified Messaging (Standalone), must be used to provide voice mail service for the entire cluster.

- SX-2000 systems cannot be part of a Hospitality cluster.

- The Hospitality Gateway and the Hospitality ICPs must all be in the same time zone.

- Also refer to Hotel/Motel Conditions.

## Guest Services Operations

- Only one IP Console application( MiVoice Business Console) in the Hospitality cluster can modify guest room data at a time, with the exception of Wake-up calls. The first console to access the room can modify its data. All other consoles in the cluster have read-only access to the data.

- The Search function uses information cached at each Hospitality ICP to find rooms. The cache is updated automatically following changes to room occupancy or condition. Any communication delays or failures, which prevent timely updates to the cache, can cause false search results due to data mismatches between the cluster elements.

## PMS Operations

- PMS transactions attempted on devices at a Hospitality ICP that is down are acknowledged but not executed. Each attempt generates a hotel log at the Hospitality Gateway.

- When a PMS connection is attempted at an ICP that is not the Hospitality Gateway, the attempt is ignored and no response is provided to the PMS.

- Attempts by PMS to delete a telephone directory entry will result in the deletion of all but the last entry associated with the deleted directory number. The last entry will have its name blanked instead of deleted if "Default Checked Out Name" is enabled in the Hotel Options form. Also, if the Keep TELDIR upon checkout option is enabled, the Delete will have no effect. This is changed behavior from previous software releases when the last entry was deleted with no name added.

- If a Hospitality ICP is down during a GRS
  General Reset. A Property Management System (PMS) function that compares its check-in/check-out data with the MiVoice Business system to ensure that the data on both systems match. operation, the transition will be acknowledged but no data synchronization will occur at the ICP. The failure to sync will generate a hotel log on the Hospitality Gateway. If all Hospitality ICPs are not in communication, GRS is aborted.

- Room check-in/check-out operations attempted by PMS while the database on the hosting ICP is locked are not automatically retried.

- Any non-GRS database transaction from PMS— for example, setting a wake-up call— attempted during a GRS operation cancels the GRS operation. No database updates related to the GRS cycle are executed. This is changed behavior from previous software releases when the GRS operation terminated and the database was updated to reflect the GRS information received.

- Also refer to Error-handling PMS/system Transmissions.

## Suite Services Interactions

- Only the Hospitality Gateway can host Linked Suites. The suites can reside on any element in the cluster if the Linked Suite has Shared Telephone Service (STS) turned off. If STS is turned on, they must reside on the gateway.

- PMS attempts to add a suite with STS turned off to the Hospitality Gateway will have no effect (that is, the suite is not added to the linked suite members list) but the transaction will still be acknowledged at the PMS terminal. The same is true when attempting to add a remote suite with STS turned on to a linked suite. In both cases, a hotel log is generated at the Hospitality Gateway.

- The linked suite can only be called from the Hospitality Gateway. However, any calls made from a member of a linked suite will still have the linked suite in its SMDR record.

- Linked Suite formation and breakdown is supported by the System Administration Tool at the Hospitality Gateway and by the PMS.

- When a Callback message matures, all extensions in the Suite (with Call Delivery set to Immediate) will ring. This is a changed behavior from previous releases when only the extension that set the Callback message was rung.

## SMDR, Hotel Logs, and Hotel Reports

- The Hospitality Gateway controls when automatic Hotel Reports are generated for all Hospitality ICPs in the cluster.

- Room- and device-related hotel logs are generated on the hosting ICP. Logs pertaining to communication delays or failures are generated on the ICP that initiates the communication— for example, on the Hospitality Gateway for all GSA and PMS functions and on the Hospitality ICP for maid status and MWI changes.

- SMDR records are available at the cluster element generating them.

- The trunking gateway (if used) that SMDR records are collected from in a Hospitality cluster must be a member of the cluster to support the Suite Identifier introduced in 3300 ICP Release 8.0.

## Message Registration

- Although Message registration is supported in a Clustered Hospitality environment, SMDR is better for call accounting because it supports resiliency. If a resilient device fails over to its secondary ICP, SMDR— unlike Message Registration— will record any external calls made from the device while on the secondary. Note, however, that SMDR does not support Suite Identifier on the secondary.

## Wake-up Calls

- Wake-up calls are delivered by the ICP that is hosting the device that requested the call. If the hosting ICP is down, the wake-up call will not be delivered and a hotel log will be generated once the ICP returns to service. If the ICP is back in service within an hour of the wake-up call expiring, the call will be attempted; otherwise, the call will be deleted and logged as such.

- Attempts to set a wake-up call require a response from the ICP hosting the Guest Room, and a response from the Hospitality Gateway. Failure to set the wake-up call can result if excessive propagation delays occur between the requesting ICP and the Hospitality Gateway. Such failures generate logs at the ICP requesting the wake-up.

- The Wake-Up Call Expiration Routing Destination (as programmed in the Hotel Options form) should reside on a 3300 ICP running Release 8.0 or greater. This is to ensure proper wake-up call delivery.

- Wake-up calls are not resilient. A resilient device with a wake-up call pending will not receive the call while on its secondary ICP.

## Call Restrictions

- Outgoing calls from a linked suite follow the Class of Restriction (COR) of the individual suite, not the COR of the Linked Suite pilot number as in previous software releases.

Related Topics

- Clustered Hospitality Description

- Clustered Hospitality Programming