The CTI OS is the next generation customer contact integration
platform from Cisco. CTI OS combines a powerful, feature-rich server and an
object-oriented software development toolkit to enable rapid development and
deployment of complex CTI applications. Together, the Cisco CTI Server
Interface, CTI OS Server, and CTI OS Client Interface Library (CIL) create a
high performance, scalable, fault-tolerant three-tiered CTI architecture, as
illustrated in following figure.
Figure 1. CTI OS three-tiered architecture topology
The CTI OS application architecture employs three tiers:
The CIL is the first tier, providing an application-level
interface to developers.
The CTI OS Server is the second tier, providing the bulk of the
event and request processing and enabling the object services of the CTI OS
The Cisco CTI Server is the third tier, providing the event source
and the back-end handling of telephony requests.
CTI OS brings several major advances to developing custom CTI
integration solutions. The CIL provides an object-oriented and event-driven
Application Programming Interface (API), while the CTI OS Server does the
heavy-lifting of the CTI integration: updating call context information,
determining which buttons to enable on softphones, providing easy access to
supervisor features, and automatically recovering from failover scenarios.
Rapid integration. Developing CTI applications with CTI OS
is significantly easier and faster than any previously available Cisco CTI
integration platform. The same object-oriented interface is used across
programming languages, enabling rapid integrations in C++, Visual Basic, .NET,
Java, or any Microsoft COM-compliant container environment.
The inclusion of the .NET toolkit allows for custom applications
to be written in C#, VB.NET, or any other CLR-compliant language. By starting
with the code for the .NET sample, the CTI Toolkit Combo Desktop developers can
quickly customize the code without having to start from scratch.
CTI OS enables developers to create a screen-pop application in as
little as five minutes. The only custom-development effort required is within
the homegrown application to which CTI is being added.
Fault tolerant. CTI OS is built upon the Unified ICM Node
Manager fault-tolerance platform, which automatically detects process failure
and restarts the process, enabling work to continue. Upon recovery from a
failure, CTI OS initiates a complete, system-wide snapshot of all agents,
calls, and supervisors and propagates updates to all client-side objects.
Key benefits of CTI OS for CTI application developers
The CTI OS CIL provides programmers with the tools required
to rapidly develop high-quality CTI-enabled applications, taking advantage of
the rich features of the CTI OS Server. Every feature of CTI OS was designed
with ease of integration in mind, to remove the traditional barriers to entry
for CTI integrations:
Object-oriented interactions. CTI OS provides an
object-oriented CTI interface by defining objects for all call center
interactions. Programmers interact directly with Session, Agent, SkillGroup,
and Call objects to perform all functions. CIL objects are thin proxies for the
server-side objects, where all the 'heavy-lifting' is done. The Session object
manages all objects within the CIL. A UniqueObjectID identifies each object.
Programmers can access an object by its UniqueObjectID or by iterating through
the object collections.
Connection and session management. The CTI OS CIL provides
out-of-the-box connection and session management with the CTI OS Server, hiding
all of the details of the TCP/IP sockets connection. The CIL also provides
out-of-the-box failover recovery. Upon recovery from a failure, the CIL
automatically reconnects to another CTI OS Server (or reconnects to the same
CTI OS Server after restart), reestablishes the session, and recovers all
objects for that session.
All parameters are key-value pairs. The CTI OS CIL provides
helper classes to treat all event and request parameters as simply a set of
key-value pairs. All properties on the CTI OS objects are accessible by name
via a simple Value = GetValue("key") mechanism. Client programmers can add
values of any type to the CTI OS Arguments structure using the enumerated CTI
OS keywords or their own string keywords (for example,
"1234"]). This provides for future enhancement of the
interface without requiring any changes to the method signatures.
Simple event subscription model. The CTI OS CIL implements
a publisher-subscriber design pattern to enable easy subscription to event
interfaces. Programmers can subscribe to the event interface that suits their
needs, or use the AllInOne interface to subscribe to all events. Subclassable
event adapter classes enable programmers to subscribe to event interfaces and
only add minimal custom code for the events they use, and no code at all for
events they do not use.
System manager responsibilities
The remainder of this document provides step-by-step
procedures for the tasks a system manager must perform to set up and configure
CTI OS. These tasks include:
On Windows 2000 and Windows XP systems, a user must be
defined as a Power User to have user privileges comparable to the default user
privileges of an NT user. Windows 2000 and Windows XP systems users must either
be members of the Power User group, or have their user privileges modified to
enable them to run legacy applications and have read/write access to the Cisco
registry keys that the desktop applications use. To set user privileges to
enable users to run CTI OS Agent Desktop and CTI OS Supervisor Desktop for
IPCC, an administrator must perform the following steps.
On the Microsoft Windows Start Menu, select
Start > Run.
regedt32 and click
The Microsoft Windows Registry Editor window appears.
Go to the following registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\CTI
Security > Permissions.
A Permissions dialog box appears.
If you are adding a new user, perform the following steps.
A Select Users dialog box appears.
Select the user to be added from the list in the top half of
the Select Users dialog box.
Add, then click
You return to the Permissions dialog box; the user you
just added is now on the list.
Click the user whose privileges you want to set.
Set the Full Control permissions for this user to
Exit Registry Editor.
Silent monitoring is a feature that allows a supervisor to eavesdrop on a conversation between an agent and a customer without allowing the agent to detect the monitoring session. Silent monitoring functionality can be provided by Cisco Unified Communications Manager (Unified CM) or CTI OS.
You can configure each CTI OS Server for either Unified CM-based or CTI OS-based silent monitoring.
Silent monitor differences between Unified CM and CTI OS
Besides the differences in implementation, CTI OS and Unified
CM also differ in when they can be invoked and when they end.
Table 1 Unified CM-based and CTI OS-based silent monitor
Unified CM-Based silent monitor
CTI OS-Based silent monitor
The supervisor can only silent monitor an agent who is
actively talking in a call.
The supervisor can silent monitor an agent in any state as
long as the agent is logged in.
Supervisor cannot silent monitor an agent on hold.
Supervisor can silent monitor an agent on hold.
When agent consults, supervisor must stop silent monitoring
held call and start silent monitoring conference.
When agent consults, supervisor automatically hears consult
Supervisor can only silent monitor in Not Ready state.
Supervisor can silent monitor in any state.
Supervisor must stop silent monitoring before barging in.
Supervisor can barge in while silent monitoring.
When the call that is being silent monitored ends, the silent
monitor call ends. The supervisor must restart silent monitor after the agent
answers another call.
When call ends, supervisor automatically silently monitors the
next call as long as the supervisor has not stopped silent monitoring.
Unified CM-based silent monitoring
Unified CM-based silent monitor allows a supervisor to listen
in on agent calls in IPCC call centers that use Unified CM Version 6.0 and
later. Supervisors can send silent monitor requests to monitor agents without
the agent being aware of any monitoring activity. When the Unified CM-based
approach is adopted for silent monitoring, the agent phone is used to mix the
media streams of the agent call. The mix is then sent to the supervisor phone.
Unified CM-based silent monitor provides the following advantages:
No NIC card restrictions.
Any 7.x or later version of any desktop (C++, Java, .Net, Siebel) can be silent monitored provided the agent is not a mobile agent.
Silent monitor is implemented via a call, therefore, the silent monitor call is carried on the voice LAN. With CTI OS silent monitor, the silent monitor stream is carried on the data LAN.
Silent monitor calls are reported as agent-to-agent calls for supervisors. With CTI OS silent monitor, the time the supervisor spends silent monitoring is not tracked.
Unified CM silent monitor limitations and restrictions
The following items prevent the use of Unified CM-based silent monitor:
Agents using phones other than 79x1 phones (7941, 7961, or 7971)
Agents using Cisco IP Communicator
Supervisors using 7.1(x) or earlier desktops
Unified CM 5.x and earlier
Silent monitoring SRTP streams is not supported
Mobile agents cannot be silent monitored
CTI OS-based silent monitoring
CTI OS-based silent monitor allows a supervisor to listen in
on agent calls in IPCC call centers that use CTI OS. Supervisors can send
silent monitor requests to agent desktops without the agent being aware of any
monitoring activity. Voice packets sent to and received by the monitored
agent's IP desk phone are captured from the network and sent to the supervisor
silent monitor service connected to the supervisor desktop. At the supervisor
silent monitor service, these voice packets are decoded and played on the
supervisor system sound card.
Figure 3. CTI OS-based silent monitor
Silent monitor does not capture and translate DTMF digits that are
selected on the CTI OS Agent Desktop or on agent desk phones.
For the agent using the 7941, 7961, 7970, and 7971 phones, you must configure these
devices on the Unified CM Administration web page with the
"Span to PC Port",
"PC Voice VLAN Access" and the
"PC Port" enabled. By default, the
"Span to PC Port" is disabled and the
"PC Voice VLAN Access" and the
"PC Port" are enabled.
Agents in this topology may have either an IP hardphone or
IP Communicator. (The supervisor in this topology must have an IP hardphone. IP
Communicator is not an option.) If the agent has an IP desk phone, it must have
an agent desktop PC connected to the second IP port. If the agent has IP
Communicator, you must install it on the same machine as the agent desktop.
You must install a CTI OS-based desktop application that implements the CTI
OS silent monitor feature on the agent desktop and supervisor
desktop PCs. In addition, the components needed for an agent to be silently
monitored are now automatically installed when the agent desktop is installed
and those needed for a supervisor to do the silent monitoring are automatically
installed when the IPCC Supervisor Desktop is installed.
You can monitor IPCC agents using Citrix clients by installing silent monitor services on the computers running the
agent and supervisor Citrix clients. You must deploy the agent Citrix client behind the agent IP phone. The supervisor Citrix client must have a sound card.
The necessary network topology is as follows.
You can also silently monitor mobile agents. To do this, you must manually deploy a
standalone silent monitor server. This silent monitor
server gains access to mobile agent voice traffic through a SPAN port that you configure to send all traffic to and from the agent gateway to the silent
monitor server. The silent monitor server then filters and forwards voice
traffic for the selected agent to the supervisor silent monitor server.
The necessary network topology is as follows.
Figure 7. Silent monitoring and mobile agent topology
Silent monitoring of an agent consumes almost the same
network bandwidth as an additional voice call. If a single agent requires
bandwidth for one voice call, then the same agent being silent monitored
requires bandwidth for two concurrent voice calls.
For example, assume the following:
You have 100 concurrent agents on your network.
Up to 20% of the agents are monitored at any given time.
In this case, plan for network capacity for 100 + (20% of
100) concurrent calls, or 120 concurrent calls.
To calculate the total network bandwidth required for your
call load, you would then multiply this number of calls by the per-call
bandwidth figure for your particular codec and network protocol.