The MediaSense event mechanism provides
server-based clients with immediate notification when actions of
interest to them take place. The following types of events are
- Session events - when recording sessions are started, ended,
updated, deleted, or pruned.
- Tag events - when tags are attached to or removed from recorded
- 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. A client could then, for
example, 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
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 (note that HTTPS is not currently
supported for eventing).
When a client subscribes for event notifications, it provides a
URL to which MediaSense will address 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 (i.e., 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