Cisco Cisco IP Contact Center Release 4.6.1 Prospecto

Descargar
Página de 428
 
4-28
Cisco Unified Contact Center Enterprise 7.5 SRND
Chapter 4      Unified Contact Center Enterprise Desktop
Deployment Considerations
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).
CTI OS Server
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.
CTI OS connections may be optionally encrypted (via use of IP Sec configurations). However, this will 
induce a significant performance penalty on the server itself when higher agent loads are utilized. For 
more information on enabling CTI OS connection security, refer to the Cisco Remote Silent Monitoring 
Installation and Administration Guide
, available at 
VRU
The RSM platform does not directly media-terminate inbound calls. Instead, supervisors dial into a 
Unified CVP or IP IVR-based VRU system, which runs call flow script logic that interacts with services 
hosted on the RSM server via HTTP. Thus, if a given RSM installation is to support up to 40 dialed-in 
supervisors, there must be a VRU present (as well as the necessary PRI/network resources) that can offer 
this same level of support.