Introduction to Change Notification Sync#
Overview#
VOSS Automate’s interaction with the Cisco Unified Communication Manager (CUCM) change notification (CNF) sync has two primary components:
Data Collector |
Collects changes from CUCM and updates the VOSS cache on the predefined frequency (defaults to every 300 seconds). This collector must be enabled to collect the changes, otherwise the sync won’t process any changes. |
Change Notification Sync |
A change notification (CNF) sync type that processes the changes the data collector places in the VOSS cache. A scheduled sync must be set up and enabled so that the changes are processed within a reasonable period. The CNF sync can also be run adhoc, if required, around the schedule. |
The VOSS Automate data collector retrieves change records from CUCM based according to the predefined interval. By default, this is every 300 seconds (3 minutes).
When running a CNF sync, VOSS Automate processes the change records that are collected, as follows:
Add |
Performs a GET API call to retrieve the full record, and adds it to VOSS Automate. |
Update |
Performs a GET API call to retrieve the full record, and updates the record in VOSS Automate. |
Del |
Removes the record from VOSS Automate. |
Update syncs perform GET API calls only for changed records, which reduces the time it takes to run the sync. This is particularly beneficial for large UC installations.
With a data collector polling period of 300 seconds and a CNF sync scheduled for every 24 hours, the process is as follows:
Every 300 seconds (5 minutes) the polling collector retrieves all current changes from CUCM.
The polling repeats every 5 minutes, and updates the VOSS Automate cache.
After 24 hours, the CNF sync runs, and processes all the changes that VOSS Automate stored over that 24hr period.
The sync duration depends on the number of changes to process, since each changed object requires an AXL GET API request. A GET AXL request is only required for objects changed in the time between syncs.
For example, on a system with 10 000 users, if 100 of these users are changed, then only 100 GET AXL request are required in a CNF sync. By contrast, a non-CNF sync would require 10 000 GET AXL requests to update these 100 users.
The VOSS Automate data collection can store up to 200,000 changes from a single CUCM cluster.
A system warning is triggered when the data collection storage reaches 75% of capacity
A sync error is triggered when the 200 000 changes capacity is reached - see Troubleshooting Change Notification (CNF)
To prevent the sync error, it is recommended that you have a regular, scheduled CNF sync running.
CUCM and Change Notification (CNF)#
The change notification (CNF) capability supports all the objects that are available via AXL. Typically, this means that everything VOSS Automate can manage in CUCM is available via change notification.
Data that VOSS Automate pulls from CUCM that is not via AXL, includes:
device/cucm/PhoneType
- this is a combination of thinAXL so would not auto-update. This includes when you add or update phone types in Cisco Unified CM with COP files or via Cisco Unified CM upgrades. So a non-CNF sync is still required for this model.Phone Status and IP Address - this is pulled into the system when the phones are viewed in VOSS Automate (list view or individual phone). This is not via AXL so would not be updated via change notification or even a normal sync at this point.
In CUCM, the change queue cache is stored in memory and is limited to 100,000 changes. The cache can fill quickly depending on the types of changes performed. For example, if an XSI (IP Phone) Service has been configured for 10,000 phones and the service is deleted, the cache will include one entry representing the deletion of the service plus 10,000 phone updates indicating the service was removed from each device. The polling period from the Cisco Unified CM is configurable and the timing should be considered based on how frequent configuration changes are being made in Cisco Unified CM. The default in VOSS Automate when polling is enabled is 300 seconds but it can be modified to be longer (up to 7200 seconds) as desired.
CUCM Setup to use CNF#
There are two settings in the Cisco Unified Communications Manager (CUCM) to check and update to ensure change notification (CNF) is enabled and set up for the right queue size (accessed via service parameters: - System > Service Parameters > Cisco Database Layer Monitor then click the Advanced button):
Service Parameter Name |
Setting |
---|---|
AXL Change Notification |
This should be set to “On” |
AXL Change Notification Queue Size |
This has a default of 20000. For a typical system, it is suggested this is changed to the maximum of 100000 to reduce the chance of changes being missed under heavy provisioning tasks. |