Clustered Hospitality requires a fully-meshed cluster of 3300 ICPs in which the telephone directories are
maintained via Remote Directory Number Synchronization.
All elements in the cluster must be running Release 8.0 with SDS 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 5550 IP Consoles must be connected to the Hospitality Gateway. Consoles connected to other cluster elements will be denied access to the Guest Services application.
5550 IP Consoles providing Guest Services Application support require version 3.2 software.
The Guest Services application on the SUPERCONSOLE 1000 and 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 NuPoint Unified Messaging, 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.
Only one 5550 IP 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 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 COS option "Keep TELDIR upon checkout" 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 3300 ICP 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
Also refer to Error-handling PMS/system Transmissions.
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 after RDN Synchronization. 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.
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
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 Release 8.0.
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
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.
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.
