Change Notification Feature Overview

The VOSS-4-UC interaction with the UCM Change notification sync has two primary components:

  • Data Collector - collects the changes from the Cisco Unified CM and updates the VOSS cache on the configured frequency (defaults to every 300 seconds).  This collector must be enabled to collect the changes, otherwise the sync will not process any changes.
  • Change Notification Sync - this is a type of sync that processes the changes the collector puts into the VOSS cache.  A scheduled sync should be set up and enabled so that the changes are processed within a reasonable period.  The sync can also be run adhoc if required around the schedule.

The VOSS-4-UC data collector retrieves the change records from the Cisco Unified CM on the configured interval. For example, this could be every 300 seconds (5 minutes) which is the default. When a Change Notification Sync type is run, VOSS-4-UC processes the change records collected. VOSS-4-UC then processes the records accordingly:

  • Add - will do a GET API call to retrieve the full record and add it to VOSS-4-UC.
  • Update - will do a GET API call to retrieve the full record and update the record in VOSS-4-UC.
  • Del - will remove the record from VOSS-4-UC.

The efficiency on these Update syncs is because there is no need to do a GET API call for every single record in the system - only for those that changed. In large UC application installations, this can make a big difference in Update sync times.

For example, with a data collector polling period of 300 seconds and a CNF sync scheduled for every 24 hours, the process would work as follows:

  • Every 300 seconds (5 minutes) the polling collector would get all the current changes from Cisco Unified CM.
  • This polling would repeat every 5 minutes - updating the VOSS-4-UC cache.
  • After 24 hours, the CNF sync would run and process all the changes VOSS-4-UC stored over that 24hr period.  The duration of this sync will depend on the number of changes to process, since each requires an AXL GET API request.

This type of sync, especially for updates, is far more efficient, because a GET AXL request for every object in the system is not required - only for those that changed in the time between syncs.

On a system with 10000 users for example, if 100 of the users were changed, then only 100 GET AXL request are needed.  By contrast, a normal sync doing an update would require 10000 GET AXL requests to update the same 100 users.

The VOSS-4-UC data collection can store up to 200,000 changes from a single Cisco Unified CM Cluster. A warning is raised when 75% of the data collection storage capacity is reached. When the 200,000 changes capacity for a cluster is reached, a sync error occurs on the user interface (see Errors and Troubleshooting Change Notification Processes) To avoid the sync error, we recommend always having a scheduled CNF sync running on a regular basis based on your needs when Change Notification is enabled.