Cisco Unity Connection Notification Interface (CUNI) API -- CUNI FAQs
Links to Other API pages: Cisco_Unity_Connection_APIs
|CUNI Guide Contents|
|API Overview |
CUNI Event Schema
Subscribing to and Processing Notification Events
Where Can I Get the WSDL?
The WSDL can be found at: http://<connection-server>/messageeventservice/services/MessageEventService?wsdl
Note: the WSDL is the same across versions except that for 8.0 there was a keepAlive parameter added to the subscribe method.
What Happens to Subscriptions if the Cisco Unity Connection Server Is Restarted?
Subscriptions are stored in the database. When Cisco Unity Connection is restarted, the Notifier reads the existing subscriptions and begins sending out notifications.
What is authentication mechanism to register for CUNI events?
Basic AUTH/HTTPS – requires administrative credentials.
Can several listeners subscribe for the events for same mailbox specifying different callback urls?
Yes they can.
Does CUNI support HTTPS for subscribing for events as well can a callback url be https?
CUNI supports HTTPS for subscribing, but the callback url cannot be HTTPS.
What kind of event or alerting mechanism is used in case it cannot reach the callback url? Any SNMP alert?
No there are no SNMP alerts generated by the CUNI. There are traces that log information on the Unity Connection server.
What happens to events in case of server reboot? Are they queued up and sent to the listeners when it boots up?
No they are not queued up. They will be lost of a reboot.
Are subscriptions synchronized between sub and pub? What happens in case one goes down?
Yes they are synchronized so they pub can pick them and take them over.
Are There Any Unsupported Methods?
Yes. subscribeForAllResources is currently not supported, so users must be listed explicitly. Also there is no current support for SSL connections for callbacks.
Can Multiple Subscriptions Use the Same Callback URL?
Not exactly. If Cisco Unity Connection sees a repeat subscription for a callback URL, it will delete the previous subscription as a safeguard against ending up with unintentional subscriptions.
Is CUNI a replacement for COMET Notifications?
No. Comet notifications are primarily for sending notifications to browser clients, each representing a single user. CUNI is not a replacement for comet: it is for server-to-server notifications, whereas Comet is for server-to-client notifications.
What is the main use case that CUNI is intended for? What are the advantages over comet?
CUNI is meant for sending message events for multiple users over a single channel, such as in a server-to-server applications.
How does CUNI scale for about 20,000 users? Does it have any scale limitations in terms of number of subscriptions?
CUNI has been tested with several thousand users. Suggestion is for using one limiting per subscription to 500 user at maximum. Each subscription can register to receive events for multiple users.
How is the event notification made to the listener, are several events batched and sent at a set interval or are they sent as they occur?
Notifications are mainly sent as they occur. If a single user has a bunch in rapid succession, they will be batched.