Cisco Cisco MediaSense Release 9.1(1) Guia Do Desenho
The connection between CUBE and Cisco MediaSense may also be routed over a WAN with the same warning: affected calls may
evidence additional clipping at the beginning of recordings due to the increased round trip delay.
The AXL connection between Unified CM and Cisco MediaSense may be routed over a WAN, but API and administrator sign-in times
may be delayed.
From a high availability standpoint, be aware that API sign-in has a dependency on the AXL link being functional. If that link traverses
a WAN which is unstable, clients may have trouble signing in to the API service, or performing media output requests such as live
monitoring, playback, and HTTP Download. This applies to SRE deployments as well as centralized deployments, and to CUBE
deployments as well as Unified CM deployments.
evidence additional clipping at the beginning of recordings due to the increased round trip delay.
The AXL connection between Unified CM and Cisco MediaSense may be routed over a WAN, but API and administrator sign-in times
may be delayed.
From a high availability standpoint, be aware that API sign-in has a dependency on the AXL link being functional. If that link traverses
a WAN which is unstable, clients may have trouble signing in to the API service, or performing media output requests such as live
monitoring, playback, and HTTP Download. This applies to SRE deployments as well as centralized deployments, and to CUBE
deployments as well as Unified CM deployments.
Solution Environment
Solution Overview and Call Flows
The following diagrams depict the Cisco MediaSense solution environment for Unified CM deployments and for CUBE deployments:
Though these diagrams each show only one Cisco MediaSense server and one Unified CM server or CUBE, each should be considered as a
cluster of such devices. That is, one cluster of Cisco MediaSense servers interacts with one cluster of Unified CM servers or with one or more
CUBE devices. For Unified CM deployments, there is no concept of a hierarchy of recording servers. SIP Trunks should be configured to point
to all Cisco MediaSense servers. For CUBE deployments, recording dial peers should be configured to point to one or two of the Cisco
MediaSense servers (preferably avoiding the Primary and Secondary). The High Availability section discusses this in more detail.
cluster of such devices. That is, one cluster of Cisco MediaSense servers interacts with one cluster of Unified CM servers or with one or more
CUBE devices. For Unified CM deployments, there is no concept of a hierarchy of recording servers. SIP Trunks should be configured to point
to all Cisco MediaSense servers. For CUBE deployments, recording dial peers should be configured to point to one or two of the Cisco
MediaSense servers (preferably avoiding the Primary and Secondary). The High Availability section discusses this in more detail.
SRE deployments are built with exactly the same topology. Physically, an SRE is a blade inserted into a router rather than a separate
rack-mounted server, but logically it functions no differently within the solution environment than does a rack-mounted server. An SRE-based
Cisco MediaSense cluster can even record calls which are forked from Unified CM phones.
rack-mounted server, but logically it functions no differently within the solution environment than does a rack-mounted server. An SRE-based
Cisco MediaSense cluster can even record calls which are forked from Unified CM phones.
Notice that the CUBE Solution Topology includes a Unified CM device. This is used only for authentication purposes, and has no role in call
flow.
flow.
General Flow - Unified CM Calls
For compliance recording applications, call recordings are initiated via a pair of SIP Invites from Unified CM to Cisco MediaSense, though only
after the initial call has been established between two parties. Unified CM is involved in the call setup, but media flows to Cisco MediaSense
from one of the phones, not from Unified CM. Inbound blog recordings are initiated in a similar way: a SIP Invite is sent from Unified CM to
Cisco MediaSense. Outbound blog recordings are initiated via an API request ("startRecording") to Cisco MediaSense, which triggers an
after the initial call has been established between two parties. Unified CM is involved in the call setup, but media flows to Cisco MediaSense
from one of the phones, not from Unified CM. Inbound blog recordings are initiated in a similar way: a SIP Invite is sent from Unified CM to
Cisco MediaSense. Outbound blog recordings are initiated via an API request ("startRecording") to Cisco MediaSense, which triggers an
SIP Invite from Cisco MediaSense to Unified CM. In all cases, the processing of the Invite results in one or more RTP media
outbound
streams being established between the phone being recorded and Cisco MediaSense. These call flows are depicted in the following figures
(Note: these figures are illustrative only and are not intended to show the detailed message flow.)
streams being established between the phone being recorded and Cisco MediaSense. These call flows are depicted in the following figures
(Note: these figures are illustrative only and are not intended to show the detailed message flow.)