3300 ICP Release 7.0 or later software is required on both the primary and secondary controller. If a Release 7.0 SDS-enabled controller is communicating with a Release 6.x SDS-enabled controller, only the forms that are supported by the Release 6.x SDS will be shared. User and device resiliency data will not be shared to the Release 6.x controller.
To configure users or devices with resiliency, Remote Directory Number Synchronization must be supported in the network. After you have configured the users or devices, SDS keeps the resilient user and device data synchronized across the primary and secondary controllers.
Do not make changes to the entries in the Remote Directory Numbers form for user and device data.
You cannot restrict the sharing of record-level data for resilient users and devices (User Managed Data) in the SDS Form Sharing form.
Changes to user and device data that are made by resilient users while on their secondary controller are shared with the primary controller.
SDS does not share changes that are made to embedded voice mail user data through the telephone user interface (TUI).
SDS does not share data from the 5140 IP Appliances.
You configure SDS to distribute the data from the master (local) controller to the slave (remote) controller. The master can be either the primary or secondary controller. Thus, you can distribute data from the primary to the secondary, or from the secondary to the primary. For example, you can configure SDS to share
device data (obtained from the Multi-line IP Sets form, Single-Line IP Sets form, and Wireless IP Sets from), and
Telephone Directory updates
Telephone Directory entries in shared groups (for example, ACD Agent Groups)
CESIDs
MAC addresses
Device Types
Directory Numbers
SDS only distributes MAC address changes that have been made through the System Administration tool.
You must assign the same number to a user's extension and voice mailbox. SDS will be unable to distribute this data if you use different numbers. SDS distributes the data based on the entries in the Remote Directory Number table of the primary controller. If you use a different number for the voice mailbox, the voice mailbox number will not be entered in the Remote Directory Number table and will not be distributed by SDS.
If users make changes to user and device resilient data while they are on the secondary controller, SDS attempts to distribute the change(s) to the primary. The data distribution fails because the primary is out of service (transport error). These transport errors are queued on the secondary until the primary returns to service. After the primary returns to service, SDS automatically re-distributes the individual failed user and device resilient data updates from the secondary to the primary. However, if transport errors occur while the primary is updating the secondary with changes made on the primary, update will be retried after 30 minutes.
The amount of time it takes for a device in fail-over mode on its secondary to return to its primary can vary and depends on the Controller Registry form settings in the System Administration Tool. A device can return to service on its primary before, or after, SDS updates the primary with user and device resilient data changes that were made to that device while on its secondary. If the user makes additional changes after service returns to the primary, but before the SDS distribution has take place, there is a small possibility for conflicting changes. If a conflict occurs, SDS implements the last change that was made.
If end-users change user and device resiliency data during an SDS synchronization, SDS attempts to distribute the changes to the resilient peer. The changes are rejected by the controller that is being synchronized and the changes are placed in the SDS Shared Data Updates list on the controller that is performing the synchronization. In Release 6.x.x, you would manually retry the rejected updates through the Shared Data Updates SDS Application. In Release 7.0 the system automatically retries any failed data distributions that occur during a synchronization. Any detained user and device resiliency updates are automatically sent to the resilient peer, after the synchronization is complete.
To support ACD hot desk agents and ACD Resiliency, the gateway controllers, primary controllers, and secondary controllers require Release 7.0 or later software.
You must configure user and device resiliency as a prerequisite to ACD Resiliency. You must also configure SDS to share, at minimum, the following system data:
Class of Service
Class of Restriction
Feature Access Codes
Independent Account Codes
The primary and secondary controllers must be sharing data. When enabled, SDS shares the ACD Agent Skill Groups form and Agent Skill Group Members data at the "Resilient Pair" scope by default.
After you have configured the resilient agents and resilient agent skill groups, SDS will automatically keep the specified user and device data synchronized by sharing data updates between the primary and secondary controller. Refer the Resiliency guide on the Mitel Customer Documentation web site for instructions on how to configure ACD Resiliency.
Only voice hunt groups and voice mail hunt groups can be configured with resiliency. Currently only NuPoint Messenger IP Release 10.0 software and later supports voice mail port resiliency.
3300 ICP Release 7.0 or later software is required on both the primary and secondary controller.
SDS must be enabled on the primary and secondary controllers and the controllers must be sharing data with each other. By default, SDS shares the "Hunt Groups" info and "Hunt Group Members" data with the secondary controller at the "Resilient Pair" scope.
The Class of Service (COS) form must be shared at the network or cluster level.
The System Speed Calls form must be shared at the network or cluster level so that any hunt group members that are identified as speed call numbers will exist on both the primary and secondary controller.
SDS shares the following Hunt Group data between the resilient pair:
Hunt Group Number
Hunt Group Mode
Hunt Group Type
COS (Day, Night 1, and Night2)
RADs (First RAD, Secondary RAD, and Night Answer RAD)
Hunt group data that is not applicable to voice hunt groups or voice mail hunt groups, such as Hunt Group Priority, 1st Threshold, 2nd Threshold, Alert Device DN, and Phase Timer are not shared.
You must program the Recorded Announce Device (RAD) greetings for the hunt group on both the primary and secondary controllers. Refer to the System Tool online help for instructions on how to program RAD greetings. SDS does not share RAD programming between the primary and secondary controllers (although it does share the RADs that are selected for the hunt group).
Hunt group data cannot be shared between a controller that has Release 7.0 software and a controller that has Release 6.x.x software. If a Release 7.0 primary controller is configured to share Hunt Group data with a Release 6.x.x secondary controller, the data will not be replicated on the secondary. A distribution error will be generated on the primary controller.
SDS does not share the group and member information with all the cluster elements. SDS shares group and member information only to cluster elements that have at least one local member programmed in the pickup group.
You enable and disable clustered call pickup groups from the Pickup Groups form.
Call pickup group ID numbers must be unique within the cluster.
When you create a new group, you want to assign the next unused group ID that is available in the cluster. However, the System Administration Tool for an element does not display all the call pickup group IDs that are used within the cluster. To help remedy this problem, SDS shares the call pickup group IDs across all the cluster elements. When you create a new call pickup group, the system presents the next available group ID in the cluster.
In Release 7.0 and later, you can change the ID of a pickup group from the User and Device Attributes form and SDS will distribute the change to the remote elements.
If you delete a clustered call pickup group, SDS removes the call pickup group from the cluster.
If you delete a resilient member from a clustered call pickup group, SDS deletes the member from the resilient peer.
3300 ICP Release 8.0 or later software is required on all controllers in the hospitality cluster.
All elements in the cluster must have SDS enabled and must be uniformly configured.
The following forms must be configured as shared and in sync among the Cluster Elements.
Class of Restriction Groups
Class of Service Options
Cluster Elements – Cluster Definition
Cluster Elements – Cluster Members
Feature Access Codes
Hotel Options
Guest Rooms
Guest Rooms – Data
Interconnect Restriction
Intercept Handling
Linked Suites – Members
SMDR Options
System Speed Calls
SDS shares the following Hunt Group data between the resilient pair:
Ring group number
Ring Group members
COS (Day, Night1, and Night2)
Overflow point
Timer values (ring timer and queue timer).
The Class of Service (COS) form must be shared at the network or cluster level or the form must be identically programmed on the resilient pair.
Ring group data cannot be shared between a controller that has Release 8.0 software and a controller that has an earlier software release. A distribution error will be generated on the primary controller if the secondary does not have the required software.
All ring group provisioning may be done from either resilient pair controller, except selection of the secondary controller, which may be done from the primary only. Membership changes may be made from either the primary or secondary.
Note: The ring group name is not directly shared by SDS when the ring group form is distributed; however, the data is distributed in conjunction with other forms.
SDS shares the configuration data for bandwidth management across all 3300 ICPs in the network. The System Administrator can change the sharing scope.
The Network Zones form should be shared at the same scope as the Bandwidth Management forms. If this form is not shared, Bandwidth Management may not function properly if the user enters conflicting configuration information into the network elements.
Recommendations: Do not use zone IDs greater than 128 if sharing between Release 8.0 and older releases; however, in clusters where all elements are Release 8.0, zone IDs between 1-250 are allowed.
Pre-Release 8.0 to Release 8.0: The compression Zone ID will be between 2-128. This is within range for Release 8.0.
Release 8.0 to pre-Release 8.0: The Zone ID will be larger in range. Sharing continues to work, but the expanded values (Zone IDs greater than 128) will fail.
Sharing the Station Attributes form will only affect a resilient pair where one system is Release 7.0 and the other is Release 8.0. This is a normal situation where the user may choose to upgrade one system, and then the other and maintain service by leveraging the resilient failover feature.
Recommendations: Always use Manual for the Zone Assignment method if sharing this form with a Pre- 8.0 system.
Pre-Release 8.0 to Release 8.0: Prior to Release 8.0, the default zone was Zone 1. If an update is received from a pre-Release 8.0 ICP with compression Zone 1, the zone assignment policy will be set to Default. If another zone is received, the zone assignment policy will be set to Manual, and the Zone ID is updated.
Release 8.0 to pre-Release 8.0: The Zone Assignment Method field will be ignored in pre-Release 8.0. This creates two problems: A Release 8.0 system may not specify anything in the Zone ID field, or it may specify a value which is ignored because the zone assignment policy is set to Default.
This form is shared, but is ignored by pre-Release 8.0 since it new for Release 8.0. This form is shared by default at the "All Network Elements" scope when Release 8.0 is installed.
When the Bandwidth Management Configuration form is shared, the Zone Tree Assignment and Zone Access Point Assignment forms must be shared at the same sharing scope.
The Network Zone Topology form is shared, but is ignored by pre-Release 8.0 since it new for Release 8.0. This form is shared by default at the "All Network Elements" scope when Release 8.0 is installed.
When the Zone Tree Assignment form is shared, Bandwidth Management and Zone Access Point Assignment must be shared at the same sharing scope.
This form is shared, but is ignored by pre-Release 8.0 since it new for Release 8.0. This form is shared by default at the "All Network Elements" scope when Release 8.0 is installed.
When the Zone Access Point Assignment form is shared, Bandwidth Management and Network Zone Topology must be shared at the same sharing scope.
The Network Elements is shared. A Zone field has been added to this form in Release 8.0. If sharing with a pre-8.0 switch, the default Zone value of 1 cannot be changed for the pre-8.0 switch.
Any Network Element with a PBX Number/CEID and Zone assigned will also have an associated entry in the ICP/PBX Networking form.
