Cisco Cisco MediaSense Release 9.1(1) Guia Do Desenho

If either the Primary or Secondary does fail, then the surviving server remains available for use. Once the failed server returns to service, the
data replication mechanism automatically begins its catch-up operation without any user intervention required.  (If the failure lasts for an
extended period of time, the system will actually raise an alarm, and disable replication completely and reestablish it when the failed server
recovers.)

Depending on the duration of the outage and the amount of churn which occurred during the outage, the catch-up operation could take some
time.  The actual duration depends on many factors, but in tests, it has taken close to an hour to transfer 150,000 recording sessions. 

During the recovery period, some irregularities and inconsistencies between the two servers may be noticed.  It is therefore not advisable to
rely on the recovering server for API operations until the catch-up operation has completed, a state which can be determined manually via CLI
commands.

An event is generated by one database server as a result of an action which took place on that server. It is not generated by both database
servers. For example, if a recording server begins a recording, it initiates a session record in 

 of the database servers. Though the

database update is replicated to its peer, only that one database server generates the event. This holds true for all types of events, from
recording session events to disk storage threshold events.

A client cannot know ahead of time which server will generate the events it is interested in. Each client must therefore subscribe to both
database servers in order to be sure it receives all events (the two subscriptions may designate the same target URI, however, which does
simplify things somewhat).

As a convenience, Cisco MediaSense provides the ability for each database server to itself subscribe to events which are generated by the
other, and forward them to subscribers almost as if they had been generated locally (a flag is included in the event body which identifies such
forwarded events). This capability can be enabled in the Cisco MediaSense Administration facility. If enabled, a client need only subscribe to
one database server or the other. That said, doing so may sacrifice reliability. If the client's chosen database server goes down, the client must
quickly subscribe to the alternate server in order to avoid any missed events. The risk here should not be underestimated, especially
considering that there is no reliable way for the client to detect such a loss without periodically issuing subscription verification requests.

When an event client receives an event, there is an implicit guarantee that the database update associated with that event has already been
committed to the database 

 server 

.  Clients that need to execute immediate API queries should check the

event forwarding flag to ensure that they are addressing their queries to the database server on which the update was generated.

The load balancing and redundancy mechanism which is used to distribute incoming recording calls is very similar to that used to distribute
incoming video playback calls.  The call arrives at a 

 node, and then is immediately redirected to a 

 node which may be more suited

to handling the operation.  Cisco MediaSense is able to play an uploaded video as long as at least one of its nodes is able to play it. 

Typically, all nodes in a cluster are equally able to handle such a request, because uploaded videos are always distributed to all nodes. 
However, it is possible for a node to encounter some sort of error during the distribution or processing phases, or even for one node to simply
be slower than the others in performing these duties.  An incoming media playback call therefore gets automatically redirected to a node which
is in service, has available capacity, and is ready to play the specific video selected by the appropriate incoming call handling rule.

Throttling of requests for video playback is also similar to that of requests for recording audio.  Like an audio recording attempt, the person
interested in playing a video while in queue or on hold is not at liberty to simply try again later if the system is busy.  Therefore, Cisco
MediaSense treats incoming video playback requests together with recording requests at a higher priority than RTSP play and monitoring
requests.  In other words, RTSP play and monitoring requests are subjected to a lower capacity throttling threshold than recording and video
playback requests, making it possible for a given node to still accept the latter even while the former are being redirected to other nodes.

If Unified CM fails while Cisco MediaSense is playing back uploaded videos, the media stream remains active but SIP signaling is no longer
available.  With no SIP signaling, there is no way for Cisco MediaSense to be informed when the endpoint device hangs up.  Therefore, the
video simply continues to play until it comes to an end, at which time it terminates and all resources are released cleanly.  However, in the
case of videos configured to playback repetitively (see "Incoming Call Handling Rules"), the playback may never terminate.  For those cases,
Unified CM sends Cisco MediaSense a session keepalive message twice every 30 minutes by default.  If Cisco MediaSense does not receive
two of these timers in succession, it assumes that Unified CM has crashed, and it terminates the playback, releasing resources cleanly.

As a result, repetitive video playbacks can remain active for up to 30 minutes following a Unified CM crash.  While they are in progress, Cisco
MediaSense considers those media streaming resources to be in use for the purposes of determining whether new incoming calls and
streaming requests can be accepted.

The 30 minute figure is a Unified CM Service Parameter which can be modified if desired.