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 System > Event sinks and from the bottom right of the page, select View schema. The same information can be downloaded as a Swagger or OpenAPI JSON document by selecting Download Swagger schema or Download OpenAPI schema.

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 System > Event sinks. 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 1: Original
  • Version 2: Media streams

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 Platform > Global settings > Advanced event Sink Tuning:

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 Platform > Global settings > Advanced event Sink Tuning as described above.

To resolve event sink related alarms:

  1. Check support.events logs for the reason for the event sink failures.
  2. Take the appropriate action to resolve the failures.

  3. Restart the event sink process:

    1. Go to System > Event sinks and select the event sink you want to restart.
    2. Select Restart.

    The event sink will restart within approximately 1-2 minutes (after the next Conferencing Node synchronization), and any backlogged events are sent.