The MediaSense
event feature provides server-based clients with immediate notification when
actions of interest to them take place. The following types of events are
supported:
-
Session events— When
recording sessions are started, ended, updated, deleted, or pruned.
-
Tag events— When tags are
attached to or removed from recorded sessions.
-
Storage threshold events—
When disk space occupancy rises above or falls below certain preconfigured
thresholds.
Session events
provide critical information about a session given its current state. For
example, client could then use the URIs provided in these events to offer real-
time monitoring and control buttons to an auditor or contact center supervisor.
A client might also implement a form of selective recording (as opposed to
compliance recording) by deleting (after the fact) sessions that it determines
do not need to be recorded.
Tag events are
used as a form of inter-client communication: when a session is tagged by one
client, all other subscribed clients are informed about it.
Storage threshold
events allow a server-based client application to manage disk usage. The client
would subscribe to these events and selectively delete older recordings (when
necessary) according to its own rules. For example, the client might tag
selected sessions for retention and then when a threshold event is received,
delete all sessions older than a certain date except those tagged for
retention.
Events are
populated with JSON-formatted payloads and delivered to clients using a
Symmetric Web Services protocol (SWS), which is essentially a predefined set of
HTTP requests sent from MediaSense to the client (HTTPS is not currently
supported for eventing).
When a client
subscribes for event notifications, it provides a URL to which MediaSense
addresses its events, as well as a list of event types or categories in which
it has an interest. Any number of clients may subscribe and clients may even
subscribe on behalf of other recipients (that is, the subscribing client may
specify a host other than itself as the event recipient). The only restriction
is that there cannot be more than one subscription to the same URL.
Events are always
generated by either the primary or the secondary server. When both are
deployed, each event is generated on one server or the other, but not both
(which has implications for high availability). Customers must choose one of
two modes of event delivery - one which favors reliability or one which favors
convenience.