|
|
DSC Tech Library
CTI Computer Telephony Integration
CTI enable your existing applications by placing phone functions
and features within your existing desktop programs, whether they are designed for
the Web or Windows. Or simply use our stand-alone Softphone in conjunction with these
existing applications.
The Database Softphone connects to our PACER (digital) and WIZARD (analog) Series of phone systems. PLUS extensive reports, statistics, and graphs are included
with this Softphone to help you effectively manage the use of your phone system.
Our Universal Softphone functions on your Local Area Network (LAN) or over the Internet, enabling your employees to
work either in your corporate offices, satellite remote offices or from the convenience of home.
Robust features of our Universal Softphone
- Stand-alone User desktop Softphone
- Supports a number of PBX and PC based phone systems
- Full feature APIs integrated within your desktop Windows applications
- Same APIs can be linked into your Web based systems
- Add computer telephony integration software to Unix and Linux applications
- Complete CTI software control of your phone system including login and logout
- Ability to make and receive phone calls manually
- Standard features such as call on hold, transfer and redirect are available
- Direct link to individual Voice Mail
- Link your employee applications with predictive or progressive dialing campaigns
- Screen pops appear on the employee desktop when the Softphone is configured with an inbound call campaign
- Internet enabled, allowing employees to work from home
- Complete administrative control of each Softphone user
- System administration including reports, graphs, user grouping, and call campaign control
The Soft Phone Server (SPS) API set (SpsApi32) is provided to enable application developers to interface with a
feature-rich middleware package controlling and monitoring simultaneous inbound, outbound, predictive and forced
preview telephony activity. Currently implemented for use from Microsoft Windows platforms, support for unix, linux,
and other versions will become available.
Behind the SPS is a DialerInterface server that communicates with various phone switch drivers, creating a transpar-ency
of interface and a universality of monitoring and coordinating features. Using the SpsApi32 library of routines,
applications can interface with the SPS from anywhere, linked via standard IP network protocols.
The following is a brief overview of the Soft Phone Server.
The Soft Phone Server
The SPS is a CTI-enabling application that organizes and monitors the logins and activities of users in groups and
campaigns. In coordination with the Voice Message Server (VMS), it also manages voice mail message organization and
retrieval.
Upon invocation, SPS will login to a DialerInterface and (optionally) a Voice Message Server. It will then, as
appropriate, distribute client requests to one server or another.
Login Management
Administrators may include or exclude specifically authorized usernames, or open the SPS to logins from anyone.
User Features
Administrators assign users a default virtual extension, which is mapped internally to headset lines, seized remote
phone lines, and/or voice-to-IP technology. This may be designated as changeable user on a per-user basis.
Users may be authorized for full login, or be restricted to the DialerInterface or the VMS only.
Users may be designated a default group and campaign, and may or may not be restricted to that group and/or campaign,
depending on configuration. More on groups and campaigns will follow.
SPS will retain a list of speed dial numbers on a per user (and per campaign) basis, which can then be downloaded by
SPS application clients.
Groups
Groups are an arbitrary way to segregate users. These can be used for restricting access to messages, and also
by the application for its own purposes.
Campaigns
Campaigns are used by the SPS and DialerInterface in various ways, and they may also be used by the application
for its own purposes. A brief overview of campaign features follows.
Campaign Features
Predictive Dialing and Forced Preview Dialing operations depend upon a phone number list server (list manager). Each
campaign may independently link up to a separate instance of the list manager, each of which is individually
configured. The instance name of the list manager must match the campaign ID.
For predictive campaigns, a valid ACD Vector (configured in the dialer as a special kind of DNIS) must be indi-cated.
This permits separate, simultaneous pools of predictive users.
Forced preview, another feature of the list manager, differs from predictive in that the user is given a screen
pop for an upcoming outbound call. The responsibility for making the call is then up to the calling application
(not quite truly forced). Two timing fields are provided, one indicating how long, after the user makes himself
available, the dialer will wait before feeding a client pop to her. The other is the configured number of sec-onds
the user will have to review the client information before the outbound call is made. This value should be
requested by the calling client application, and used to start a timer until the dial is made.
All incoming call pops are accompanied with ANI (phone number) and DNIS. The DNIS tells the application which
DNIS group the call has been assigned by the dialer, and can be useful to the application for synchronizing
logic.
In addition, the campaign may be configured to send call, user, and client information on a screen pop, execute a
URL with cgi arguments consisting of such data, or to execute a standalone executable, also with arguments.
Client File
Each campaign may have a client file assigned to it, or they may share the same one(s). (Files in the SPS system
are Database Systems Corp. Fastplus files, based on ISAM technology). As many applications will probably have
their own client data files, these may be ignored, or be synchronized with existing databases. For simple CTI
implementations, however, the availability of these files can be valuable.
Speed Dials
As with users, campaigns may have a designated list of speed dial numbers. It is the responsibility of the ap-plication
to request these.
A Note On Communications
Applications logged into the SPS are actually logged into up to three different servers - the SPS itself, the
DialerInterface, and the Voice Message Server. Many of the requests made of the SPS by the client are passed to
these servers on behalf of the client, and the servers then respond directly to the client. For example, a
user logging in may receive up to three acknowledgement messages: SPS_RT_LOGIN (SPS), RSP_RT_LOGIN
(DialerInterface), and VMS_RT_LOGIN (Voice Message Server).
|
