SDS Sharing Groups - Definition of Classifications

The following table outlines the data that is shared or synchronized for each of the form groups in the SDS Form Sharing form.

Group Classification

Purpose

General System

Shares the selected form data among the cluster elements at the specified scope. By sharing these forms, you can keep the data the same on all the cluster elements in the data sharing community. If an administrator makes a programming change to one of the shared forms on an element, SDS updates the databases of the other cluster elements that belong to that sharing community.

For Hunt Groups and Ring Groups, SDS shares the data in the respective Group Assignment form and the group membership data with the resilient peer. You can configure the system to support both hunt and ring group resiliency. Then, if the primary controller goes out of service, the resilient groups and resilient group members fail over to the secondary controller and are able to answer the incoming calls to the group pilot number. Refer to Resiliency Guidelines for hunt group and ring group resiliency configuration.

For Clustered Pickup Groups, SDS shares the call pickup group data and group membership data among all the cluster elements on which the group members reside. Therefore, if you add or delete a member from a clustered pickup group, SDS updates all the elements that host that pickup group with the change in membership.

Trunk - Links

ARS

Device Level Call Handling

System Level Call Handling

SNMP

User

ACD

Shares the data in the ACD Agent forms and the agent skill group membership data with the resilient peer.  You can configure the system to support ACD resiliency. Then, if the primary controller goes out of service, the resilient agents and resilient agent skill groups fail over to the secondary controller and are able to process the incoming ACD calls. Refer to Resiliency Guidelines for ACD resiliency configuration.

Service Hosting Data

 

Device Level Resiliency - Administrator Managed Data - Device and User Data

Shares the device and user data for resilient devices from the listed forms to the resilient peer controller. This group classification also shares the CESID assignment data and voice mailbox configuration data of resilient devices with the resilient peer controller.

For example, if you change the CESID data for a resilient device while on the primary controller, SDS updates the device's secondary controller with the CESID data. Then if the primary controller fails and the device homes to the secondary, the secondary controller will have the latest CESID data for the device.

For voice mailboxes, SDS shares the data from the VM Mailboxes or User and Device Configuration form (mailbox number, name, extension number, and mailbox type) for resilient devices with the resilient peer controller. SDS does not share voice mail box greetings. Users must program their greetings on both the primary and secondary controller. Also, if a user changes his or her passcode through the telephone user interface, SDS does not update the resilient peer with the new code.

Device Level Resiliency - Administrator Managed Data - User Managed Data

Allows you to share the data in the Multi-Level Auto Attendants form between resilient peers.

The lower portion of the Multiline Set Keys form lists the softkey programming for devices. SDS shares the feature key (softkey) assignment for resilient devices with the resilient peer.  For example, if a user programs a Redial feature key on a set, SDS distributes the key to the resilient peer. However, a number programmed for a resilient key is not shared. After a failover from the primary controller, the Redial key would appear on the secondary controller, but the last number dialed on the primary controller will not be available to the user on the secondary.  

User Call Handling Data

Allows you to share the Auto Answer, DND, and Make Busy status of resilient sets between their resilient peer controllers. Then, if the primary controller fails, the status of these features is maintained when the set fails over to the secondary. For example, if Do Not Disturb is activated on a resilient set and the set fails over to the secondary, the Do Not Disturb feature will be activated on the secondary controller.

High End Set Data

Allows you to share the phone configuration settings that are available under the Applications shutter of resilient 5235 IP Phones with the resilient peer controllers. If the user's resilient 5235 IP Phone fails over, the 5235 IP Phone applications will have the same settings on the secondary controller. Likewise, when a user's 5235 IP Phone fails back to the primary controller, SDS updates the database of the primary controller with any application configuration changes that the user made while on the secondary controller.

You cannot share all 5235 IP Phone programmable keys, such as the DND key, by sharing High End Set Data. To share all 5235 IP Phone programmable keys, you must also share the Multiline Set Keys form.

Hospitality

 

Shares the selected form data among the clustered hospitality elements at the specified scope. By sharing these forms, you can keep the data the same on all the cluster elements in the data sharing community. If an administrator makes a programming change to one of the shared forms on an element, SDS updates the databases of the other cluster elements that belong to that sharing community.

System Maintenance

Shares the external FTP server settings among the elements in an SDS Administrative Group.