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 system.
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, AddItem["DialedNumber", "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.
Type in regedt32 and click OK.
The Microsoft Windows Registry Editor window appears.
Go to the following registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\CTI Desktop\Ctios
Select 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.
Click Add, then click OK. 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 Allow.
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 differences
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 call.
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.