Cisco Cisco E-Mail Manager Unity Integration Option Dépliant
4-42
Cisco Unified Contact Center Enterprise 7.5 SRND
Chapter 4 Unified Contact Center Enterprise Desktop
Deployment Considerations
Host-Level Security
Incoming access to the RSM server can be restricted to only the necessary components via the host-based
Access Control List (ACL) functionality built into the Windows Server OS. In the most secure
configuration, incoming access to the RSM system is permitted from the VRU systems. Built-in
host-based access control can also be employed to allow limited access to other services if desired, such
as remote administration mechanisms such as Windows Remote Desktop and VNC.
Access Control List (ACL) functionality built into the Windows Server OS. In the most secure
configuration, incoming access to the RSM system is permitted from the VRU systems. Built-in
host-based access control can also be employed to allow limited access to other services if desired, such
as remote administration mechanisms such as Windows Remote Desktop and VNC.
Even though this is not required, a recommended ACL Configuration for a single-server RSM
configuration would be as follows:
configuration would be as follows:
Deny incoming access to all
Permit incoming TCP on port 8080 to each VRU node in the environment (VLEngine HTTP API
Access)
Access)
Permit incoming TCP on port 29001 to each VRU node in the environment (PhoneSim HTTP API
Access)
Access)
<Other rules for allowing remote administration (RDP/VNC) connectivity>
Cisco Security Agent
As part of the installation procedure, Cisco highly recommends that you install the Cisco Security Agent
(CSA) software on the RSM system. This topic is covered in the Security Settings chapter of the Cisco
Remote Silent Monitoring Installation and Administration Guide, available at
(CSA) software on the RSM system. This topic is covered in the Security Settings chapter of the Cisco
Remote Silent Monitoring Installation and Administration Guide, available at
.
Unified CCE fails
(CTI OS)
(CTI OS)
RSM will lose connectivity to the CTI OS server when the PG fails or is
cycled. If connectivity to both CTI servers on a cluster fails, RSM will keep
retrying both, connecting to the first server that is available. (The CIL's
failover code is used for all of this.) When connectivity comes back up to a
CTI server, the agent and call lists will be cleared and refreshed (to avoid
"stale" agents). During this time, no new call events will be received, and the
system will be working from an "out-of-date" agent and call list. Therefore
some monitoring requests will fail, saying the agent is not talking when he
or she is, and some monitoring requests will fail because the system would
think the agent is talking when he or she currently is not. This is believed to
be preferable to the scenario where all cached data is deleted when the server
goes down, in which case no monitoring would work.
cycled. If connectivity to both CTI servers on a cluster fails, RSM will keep
retrying both, connecting to the first server that is available. (The CIL's
failover code is used for all of this.) When connectivity comes back up to a
CTI server, the agent and call lists will be cleared and refreshed (to avoid
"stale" agents). During this time, no new call events will be received, and the
system will be working from an "out-of-date" agent and call list. Therefore
some monitoring requests will fail, saying the agent is not talking when he
or she is, and some monitoring requests will fail because the system would
think the agent is talking when he or she currently is not. This is believed to
be preferable to the scenario where all cached data is deleted when the server
goes down, in which case no monitoring would work.
Unified CM fails
(JTAPI / AXL)
(JTAPI / AXL)
Connectivity to one or more JTAPI providers will be lost. RSM can be
configured for connectivity to up to 2 JTAPI providers per-cluster. If this is
the case and connectivity to either of the providers is lost, VLEngine will
fail-over to the other provider if necessary, making it the active one and
making its requests through it. If connectivity to both providers is lost,
VLEngine will periodically retry both and re-establish the connectivity to
the first that comes up. Attempts to monitor agents (for example,
monitorAgent calls) made during this time will fail until the JTAPI
connection is re-established.
configured for connectivity to up to 2 JTAPI providers per-cluster. If this is
the case and connectivity to either of the providers is lost, VLEngine will
fail-over to the other provider if necessary, making it the active one and
making its requests through it. If connectivity to both providers is lost,
VLEngine will periodically retry both and re-establish the connectivity to
the first that comes up. Attempts to monitor agents (for example,
monitorAgent calls) made during this time will fail until the JTAPI
connection is re-established.
Table 4-5
Impact of Failures on a Supervisor Call (continued)
Component That Fails Worst Possible Impact