Using event sinks to monitor conference and participant status
Information about the current status of any conferences that are in progress can normally be obtained using the Management status API. However, in deployments with high levels of live system monitoring activity, such as those managed by service providers, frequent polling of the Management Node via the API can cause performance issues.
To avoid this you can configure the system to automatically send details of every participant and conference management event to an external service known as an event sink. When an event occurs, the Conferencing Node sends this information using a simple POST of JSON data to the nominated event sink server.
In particularly busy deployments, you can enable Bulk support. This groups and sends events together at a set interval, reducing the number of POSTs and therefore limiting the size of any queue that may result. Note that enabling bulk support will delay the receipt of events by up to the time specified by the Bulk message timeout interval (which is 0.1 seconds by default).
What information is sent?
To view which events are sent to an event sink, go to and from the bottom right of the page, select . The same information can be downloaded as a Swagger or OpenAPI JSON document by selecting or .
You can also use a test site such as https://webhook.site to view live event data being sent.
Note that:
- Conference start and end event times are from the Conferencing Node's perspective and not the Management Node's perspective.
- You cannot control which events are sent to an event sink.
For a complete description of the information that is sent, including examples, see Event sink API.
Configuring event sinks
Each system location can be configured with one or more event sinks. The same event sink can be used for more than one system location.
Note that conference and participant events are not sent from locations that contain Proxying Edge Nodes — the events for proxied calls are sent from the nodes/locations that perform the transcoding (providing those locations are configured with an event sink).
To add, edit or delete an event sink, go to . The available options for each event sink are:
| Option | Description |
|---|---|
| Name | The name of this event sink. Each event sink must have a unique name. |
| Description | An optional description of this event sink. |
| Version |
Select which version of the API to use:
Version 2 contains additional participant_media_stream_window and participant_media_streams_destroyed participant events. Default: Version 2 |
| Enable bulk support |
When enabled, at the end of each interval specified by the Bulk message timeout, all events received during the interval are batched together and sent as a single POST. When this option is enabled:
|
| URL | The URL of the external server to which events are sent. |
|
Username Password |
The username and password used to authenticate to the external server when sending events. The username is case-sensitive. If authentication is not required, leave these fields blank. |
| Verify TLS | Whether to enable TLS verification when sending events. Only valid if the URL is HTTPS. |
| Location | The system location(s) in which to use this event sink. |
| Last attempted restart | This read-only field indicates if and when the event sink was last restarted. |
Advanced configuration options
You can configure a range of advanced options that control connectivity and failure retry limits. These settings apply globally across all event sinks and are configured via :
| Option | Description |
|---|---|
| Event sink HTTP POST timeout |
Maximum number of seconds allowed to connect, send, and wait for a response. Default: 7 seconds |
| Event sink maximum retry backoff |
Maximum number of seconds allowed for the retry backoff before raising a "Eventsink Reached Maximum Backoff" alarm and stopping the event publisher. Default: 1800 seconds |
| Initial retry backoff |
Initial time, in seconds, for the first retry attempt when a POST cannot be delivered. Default: 1 second |
| Internal cache expiration |
Internal cache expiration time in seconds. Used to briefly store "participant_disconnected" events in order to gather end-of-call media statistics. Default: 2 seconds |
| Time to wait for media streams message |
Maximum time, in seconds, to wait for an end-of-call media stream message. Default: 1 second |
| Time between metrics updates |
Time between event sink metrics updates. You can specify 0 to disable event sink metrics. Default: 60 seconds |
| Number of HTTP worker threads | The number of HTTP POST worker threads to start. |
| Bulk message timeout |
When Enable bulk support is enabled, the interval (in seconds) during which events are received, batched, and sent to the event sink in a single POST. Default: 0.1 seconds |
Troubleshooting event sink failures
If a POST cannot be delivered to an event sink, the node will try again after 1 second. If it fails again it tries again after 2 seconds, then 4, 8, 16 seconds and so on — it keeps doubling the timeout. In this case, the events may not necessarily be sent in sequence number (seq field) order.
If the timeout exceeds 30 minutes it will instead raise an "Eventsink Reached Maximum Backoff" alarm and stop the event sink publisher for that particular event sink.
The retry/timeout parameters are configurable via as described above.
To resolve event sink related alarms:
- Check support.events logs for the reason for the event sink failures.
- Take the appropriate action to resolve the failures.
-
Restart the event sink process:
- Go to and select the event sink you want to restart.
- Select .
The event sink will restart within approximately 1-2 minutes (after the next Conferencing Node synchronization), and any backlogged events are sent.