Cisco Cisco Unified Contact Center Enterprise 9.0(2) Design Guide

In particular, RSM interacts mainly with the following components in the environment:

The RSM server has two tie-ins with each Unified CM cluster in the environment that it is configured to 
use:

Simulated Phones: RSM's PhoneSim component requires that a Cisco Unified IP Phone 7941 device 
entry be created on the Unified CM cluster for each of the simulated phones (or "simphones") it is 
configured to manage. For instance, a RSM system that is configured to handle up to 100 dialed-in 
supervisors monitoring agents on a particular Unified CM cluster will need to have at least of these 100 
simphones. To the Unified CM cluster itself, these simphones appear as normal Cisco Unified IP 
Phone 7941 SIP phones; however, in reality they are homed to and controlled by PhoneSim instead of 
being an actual physical phone device.

When compared with the usage profile of a normal phone, the simphone usually puts a lighter load on 
the Unified CM cluster. This is because it exhibits only a small set of behaviors, consisting of:

Registering with the Unified CM cluster when PhoneSim is started.

Making a “monitoring call” to an agent's phone when a dialed-in supervisor requests to monitor that 
agent. The agent's phone then forks off a copy of the conversation the agent is having to the 
simphone.

JTAPI: When RSM is integrated into the environment, a JTAPI user is created and associated with each 
agent phone device that can be monitored, as well as with each simphone device that was created on the 
cluster. 

When an agent is to be monitored, a JTAPI monitor request call is made from the RSM server to the 
Unified CM cluster that manages that agent's phone. Also, while RSM is in use, a JTAPI CallObserver 
is kept attached to each simphone device. It is also attached to an agent phone device, but only while the 
JTAPI monitor request is being issued to that device.

JTAPI connections may optionally be encrypted. However, this will induce a slight performance penalty 
on the server itself when higher agent loads are utilized. For more information on enabling JTAPI 
connection security, refer to the Cisco Remote Silent Monitoring Installation and Administration Guide, 
available at 

.

AXL: AXL usage is relatively light; it is used by RSM only to resolve an agent DN to an associated 
device name whenever a caller requests to monitor to an agent. All AXL communications are encrypted 
(via being run over HTTPS).

RSM makes a persistent "monitor-mode" connection to each CTI OS server it is configured to use. 
Through this connection certain platform events such as call start, call end, agent on hold, and so forth, 
are streamed in real-time.

Besides this, RSM will make an additional, short-lived "agent-mode" connection to possibly each CTI 
OS server when a supervisor dials in and authenticates. The purpose of this connection is to validate the 
supervisor's entered credentials by performing a corresponding login into CTI OS. Note that, if the 
built-in authentication mechanisms of the RSM callflow (for example, the checkCredentials API call) 
are not used, this connection is not made. If the login is successful, that supervisor's team membership 
is requested by the RSM server. Once returned, a logout is called and the connection is terminated.

Note that the total supervisor count in Unified CCE must be spread across CTI OS desktop users and 
RSM. For example, in a 2000 agent configuration, up to 200 agents can be supervisors. This means that 
the total supervisor count between CTI OS and RSM must not exceed 200.