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.
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 |
| URL | The URL of the external server to which events are sent. |
| Username and Password | The username and password used to authenticate to the external server when sending events. The username is case-sensitive. Leave these fields blank if authentication is not required. |
| Verify TLS | Whether to enable TLS verification when sending events. Only valid if the URL is HTTPS. |
| Location | The system locations 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 connection timeout |
Maximum number of seconds allowed to connect to an event sink. 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 an event 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 |
| Maximum number of background POSTs |
Maximum number of incomplete background POSTs requests before stopping the event publisher and raising an "Eventsink Reached Maximum Concurrent POSTs" alarm. Default: 1000 |
| Time between metrics updates |
Time between event sink metrics updates. You can specify 0 to disable event sink metrics. Default: 60 seconds |
Troubleshooting event sink failures
If an event 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.
Also, if more than 1000 events (configurable via Maximum number of background POSTs) are queued for an event sink but have not been sent then an "Eventsink Reached Maximum Concurrent POSTs" alarm is raised and the publisher for that event sink is stopped.
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.