A.001 Application Interoperability Framework



A.001 Application Interoperability Framework

revision 1.0

Abstract

This Application Interoperability Framework is the ECTF's first publication addressing application interoperability. Application Interoperability is defined as the capability for multiple CT applications from potentially disparate vendors to cooperate in the sequential handling of a single telephone call, without interfering with each other.

In addition, application interoperability means that CT applications from multiple vendors that are involved in a call will allow for the exchange of data.

©1996, 1997 Enterprise Computer Telephony Forum

This document is copyrighted and all rights are reserved by the Enterprise Computer Telephony Forum (ECTF). “ECTF technical implementation agreements are considered public domain and may be copied, downloaded, stored on a server or otherwise re-distributed.”

DISCLAIMER

Interoperability Agreements are the result of a collaborative, volunteer effort of ECTF Members, their employees and others. ECTF shall at no time have any responsibility or liability whatsoever to ECTF Members or any other party for the accuracy, completeness, non-obsolescence or any other aspect of any Interoperability Agreement or any response by ECTF to any ECTF Member's or any other party's questions respecting any Interoperability Agreement.

All comments or questions relating to the ECTF or their specifications should be submitted to:

Enterprise Computer Telephony Forum (ECTF)

39355 California Street, Suite 307

Fremont, CA 94538

(510) 608-5915

(510) 608-5917 (Fax)

e-mail : ectf@

web site :

About ECTF

As Computer Telephony (CT) becomes an integral part of the entire communications network including the Internet, there are increasing challenges to making diverse communication products work together. The ECTF is focused on solving the technical challenges of interoperability for the benefit of users and developers alike.

Founded in 1995, the ECTF is a non-profit organization composed of Computer Telephony suppliers, developers, systems integrators, and users from the Americas, Europe, and Asia/Pacific. Together we discuss, develop, and test approaches to successful multilayer interoperation within the PSTN, IP, and enterprise information system environments. Successful multilayer interoperation enables application solutions that can exploit the full range of contemporary communications capabilities while lowering costs for both developers and users.

The ECTF Technical Committee has worldwide scope and addresses global technical needs for:

• Convergence of computing and telephony

• Interoperability of defacto and de jure computer telephony standards

• Consistency of computer telephony interfaces

• Availability of scalable, networked, extensible computer telephony platforms and applications

Its goals are as follows:

• Provide architectural frameworks for interoperability

• Foster efficient and effective development of computer telephony products and services

• Facilitate industry acceptance of interoperability through non-ambiguous common implementation agreements

• Promote industry cooperation and exchange

The Technical Committee has a number of working groups (WGs) and task groups that underscore the areas of ECTF interest, such as:

• Administrative Services

• Application Interoperability

• Architecture

• Call Control Interoperability

• Computer Telephony Services Platform

• Hardware Components Interoperability

If you are a developer or a user of Computer Telephony products and services, we invite you to join the ECTF and help influence the direction and growth of the Computer Telephony Industry.

Reference Information

The cited references contain provisions which, through reference in this specification, constitute provisions of this specification. At the time of publication, the indicated versions in the following references were valid.

• S.100 Media Services API Specification, revision 1.0, Enterprise Computer Telephony Forum, March 1996.

• Architecture Framework, revision 1.0, Enterprise Computer Telephony Forum, February 1997.

• C.001 Call Control Model, revision 1.0, Enterprise Computer Telephony Forum, July 1997.

• M.001 Administrative Services White Paper, revision 1.0, Enterprise Computer Telephony Forum, January 1997.

Contents

About ECTF

Reference Information

Contents

Section 1 : Executive Summary

Section 2 : Introduction

2.1 Mission Statement

2.2 Definitions

2.2.1 Computer Telephony (CT) Applications

2.2.2 Application Interoperability

2.3 Why?

2.4 What?

2.5 How?

2.6 Who?

Section 3 : Problem Statement

Section 4 : Goals and Objectives

4.1 Goals of this Workgroup

4.1.1 Universal Harmony

4.1.2 Multiple CT Environments

4.1.3 Continuing to Evolve Specifications

4.2 Goals of this Paper

4.3 Objectives of the Application Interoperability Workgroup (AIWG)

Section 5 : Scope

5.1 Current Topics

5.1.1 Call Center Reporting Task Group

5.1.2 Specifying CT Application Data

5.1.3 Defining Categories of CT Application Data

5.1.4 Applications Using this Data

5.2 Future Topics

5.2.1 Security

5.2.2 Information Technology Services

5.2.3 Resource Sharing

5.2.4 Other Areas

Section 6 : Working Group Deliverables

6.1 A.001—Application Interoperability Framework

6.2 Guidelines, Requirements, Specifications, and Compliance Documents

6.2.1 A.100—Application Interoperability Guidelines

6.2.2 A.110—Application Interoperability Data Sharing Requirements

6.2.3 A.120—Requirements and Methods for Routing Calls between Applications

6.2.4 A.130—Application Interoperability Shared Data Specification

6.2.5 A.200—Application Interoperability Compliance Specification

6.3 Timeframe

Glossary

Section 1 : Executive Summary

Applications are the vehicles to deliver computer telephony services. Due to vertical and incompatible implementations in the past, the cost of computer telephony integration is high. With the increase in complexity and the proliferation of computer telephony integration (CTI), the cost of ownership and operation must be driven down to offer growth potential for the industry in terms of fast development and the ability to leverage off of other existing services. Specifying an architecture that allows computer telephony applications to cooperate and interoperate, diminishes the cost and complexity to integrate CT applications, and provides unique services. This framework outlines the objectives and means to achieve low cost of ownership and makes leveraging possible by identifying the architecture and a set of interfaces to achieve these goals.

Section 2 : Introduction

Application interoperability is a popular topic of discussion among those interested in CTI. Indeed, individuals’ definition of “application interoperability” can vary as much as the backgrounds and interests of those individuals who work in the CTI industry. The ECTF is cognizant of this and presents this framework as its initial effort at addressing all of these varying opinions and needs.

This paper begins by presenting this Working Group’s Mission Statement along with essential definitions. This introduction continues by answering the questions of “why”, “what”, “how” and “who” of application interoperability.

Subsequent sections proceed with a discussion of the problem statement and enumerate the goals of this working group (WG). Finally, this paper describes deliverables and closes with a glossary of terms, a list of referenced documents and an elaboration of acronyms used in this paper.

2.1 Mission Statement

The Mission of the Computer Telephony Applications Interoperability Working Group (AIWG) is to define effective interoperation of computer telephony (CT) applications.

2.2 Definitions

For the ECTF, the following are its definitions of what a CT application is, and what it means for CT applications to interoperate. For the most part, these definitions specify the terms and help further understanding of the concepts. The ECTF is aware, that there exist many potentially complimentary as well as conflicting definitions of these terms. However, an effort must be made to find general consensus that will lead to progress in solving some of the problems described in this document. Part of this effort is represented by the definitions below.

2.2.1 Computer Telephony (CT) Applications

A CT application is a collection of one or more software programs that are responsible for the efficient exchange of information, via telephony technologies (i.e., switching and media resources). The CT application can facilitate the information exchange between an individual and a computer, or it can facilitate information exchange between individuals (either simultaneously or using store-and-forward technology).

CT applications exist to increase efficiency and to reduce cost-of-ownership of various facets of business communications (such as providing 24 hour a day access to customer services). CT applications accomplish these objectives by performing basic tasks that may not have been done at all or otherwise would have been done using traditional methods (such as having a person answer the phone and retrieve information from a physical file cabinet).

CT applications use telephony technologies such as speech recognition, text-to-speech (TTS), fax, voice record/play, DTMF recognition, and/or switching. They can be combined to form familiar applications such as:

• Voicemail

• Faxback

• VRUs

• ACDs

• Automated Conference Call bridges

• Predictive dialer applications

• Information conversion applications such as speaking (via TTS) or faxing email

2.2.2 Application Interoperability

Application Interoperability is defined as the capability for multiple CT applications from potentially disparate vendors to cooperate in the sequential handling of a single telephone call, without interfering with each other. In addition, application interoperability means that CT applications from multiple vendors that are involved in a call, will allow for the exchange of data.

2.3 Why?

The need for application interoperability has been around as long as there have been end users and computer telephony system engineers who have been trying get CT applications to work together in some form or fashion.

Note that through out this document, the term “computer telephony system engineer” (or simply “system engineer”) refers to any computer telephony engineer whose job is to work with CT applications in order to make them available for use. This includes engineers who integrate CT applications to be sold as a product or service (a “system integrator”) as well as engineers who must install, configure and maintain CT applications (a “system administrator”).

A primary reason for specifying mechanisms and interfaces to support application interoperability is to benefit the end users of CT. They will enjoy easier access to CT technologies along with enhanced CT functionality. Indeed, users will have access to the combined functionality of multiple applications without having to make multiple calls.

With applications interoperating, system engineers will have more flexibly providing functionality to end users. They will also enjoy reduced cost of ownership and will have more choices of CT applications. Board vendors and application developers will also benefit from the subsequent growth of the market place.

A precedent exists for such predictions. The windowing architecture that defined how applications were to interact (or interoperate) with the host operating system (initially for Macintosh and later for Microsoft Windows) resulted in the growth of the GUI based application market and the enormous increase of user-friendly applications. Indeed, the same is hoped for in the CT application arena. The section “Problem Statement” further describes these issues.

2.4 What?

This paper will detail what the ECTF will do to address the problems of getting applications to cooperate and to interoperate. The sections “Goals” and “Scope” will also discuss what this paper and this WG will not address at this time.

2.5 How?

The section “Working Group Deliverables” will present how the ECTF will propose to solve the problems surrounding the effort to make CT applications cooperate and interoperate.

2.6 Who?

The intended audience of this paper is professionals in the CT industry. This paper and the specifications, guidelines are intended for individuals who are interested in, or are currently developing CT applications. It is intended to aid these developers in implementing CT applications that will interoperate.

If a developer is not interested in having their CT application share data or a telephone call with other CT applications, they should look up these recommendations as guidelines to keep in mind for future development.

It is also assumed that the reader is familiar with the terms and technology of the CT industry and has a conversant understanding of the referenced ECTF published documents listed further in this paper.

Section 3 : Problem Statement

Today, a system engineer can obtain a wide variety of CT applications from many vendors in order to:

1. Lower the cost of managing the increasingly heavy telephone traffic in a business.

2. Increase efficiency of end-users

3. Provide enhanced telecommunication functionality

4. Provide flexibility and easier access to telecommunication functionality

Applications such as interactive voice response (IVR), automatic call distributors (ACD), voicemail, and faxback systems all provide powerful capabilities to make communications between an enterprise and its various customers and suppliers more efficient. However, these applications typically do not work well with each other. If a system engineer wants something as simple as to have a call passed from an IVR application to an ACD application with the Caller’s personal identification number (PIN) number handed to the ACD agent, no standard exists to allow IVR and ACD applications to interoperate and share data.

Giving a more complex example, assume that an enterprise has a voice response unit (VRU), an ACD, a voicemail system, and a faxback system. The system engineer wants to be able to route telephone calls between these CT applications. Certain types of calls (based on Dialed Number Identification Service or caller ID) are to be routed to the VRU where the caller is identified and the caller's account number is obtained. When the VRU has finished, the calls go to either the ACD, or to the voicemail system, depending on other results of the VRU session. The account number obtained in the VRU session is made available to the agent on the ACD if that is where the call is routed, or it is passed to the voicemail system. Depending on the outcome of the ACD or voicemail interaction, the system engineer wants the call to disconnect, or be connected to the faxback system. The system engineer wants another type of call (based on DNIS) to go to the ACD first, then the VRU, and then disconnect.

The system engineer bought all of the applications from different vendors, and does not want to have to modify any of the applications to achieve this cooperative call routing. Granted, the system engineer could have obtained all of these applications from an application vendor and specified the requirements above. However, this single point of purchase may not provide all the desired functionality and the system engineer may not be able to utilize best-of-breed applications. In addition, the concept of extensibility and the option to modularly upgrade the CT systems is left entirely up to the organization from which the engineer purchased the system.

The system engineer wants to be able to specify the cooperative interaction of the various applications independent of the applications themselves. In addition, the engineer would like to select best-of-breed applications (from potentially different application developers/venders). This is the essence of the “Application Interoperability” problem that the ECTF is planning to address.

The initial area of Application Interoperability that AIWG will work on is to help system engineers (such as the ones described above) solve problems trying to get their CT applications to share calls and to work together. The AIWG will describe how multiple CT applications from different application vendors can cooperate on calls within the ECTF architecture. This will not only include specifying data that can be exchanged, this WG will also work to enhance and elaborate existing ECTF specifications that will further facilitate application interoperability.

Section 4 : Goals and Objectives

The ECTF, as an organization, has a defined mission to bring together suppliers, developers, systems integrators, and users to discuss, develop and test interoperability techniques for dealing with the diverse technical approaches to computer telephony integration. The AIWG focus is at the application level and its goal is to provide specifications that allow CT applications to interoperate.

4.1 Goals of this Workgroup

Simply put, it is the goal of this workgroup (WG) is to define interoperability agreements that allow CT applications to interoperate.

4.1.1 Universal Harmony

Once these specifications are published, developers will be able to incorporate them into new applications (or retro-fit older applications). End users, system engineers will then be able to begin reaping the benefits from the specifications and recommendations of the WG.

End users will have access to applications that will provide a greater functionality and an ease of use. System engineers will find it easier to integrate CT applications as well as having access to a greater number and variety of CT applications.

The developers and board vendors will also benefit with the subsequent increase in the CT application market place.

4.1.2 Multiple CT Environments

The interoperability agreements will not be restricted to some narrow classification of CT applications but will be general enough so as to be applicable across a variety of CT operating environments, ranging from “back office” servers to large customer premise environments to central office switch environments.

The definition of CT operating environments also includes the application interfaces that provide access to CT services. The specifications will focus on providing CT application interoperability within the ECTF defined architecture.

Portions of the specifications and recommendations generated by this WG will be broad enough to encompass other CT organization’s work such as ECMA and Versit and will also cover call control interfaces such TAPI, TSAPI and CSTA. It is also hoped that these broad segments can be implemented by vendors to allow interoperability with their proprietary “black box” CT application and operating environments.

4.1.3 Continuing to Evolve Specifications

This WG will maintain ownership of these issues and will continue to evolve the specifications based upon input obtained from developers, system engineers and end-users.

4.2 Goals of this Paper

The first goal is to make the CT community aware of the problems of making CT applications interoperate. This paper presents the size of the problem and gives the reader an indication of the difficulty of solving them. By presenting the spectrum of CT applications involved, we can begin to describe the size of the problem. For example, application interoperability may be as simple as deciding the way applications are to format ANI/DNIS/CLID (and pass to another application), to more complex issues like making CT applications from different vendors (that offer the same services) inter-work in the same environment.

Additional goals are to make people aware that this WG has been formed to address these problems and this paper will provide a roadmap to describe a methodology for coming up with solutions to these problems. This will include a list of deliverables and a schedule outline.

This is not a specification, rather, it provides and overview to give the CT community an understanding of the problem domain, and it gives the CT community an indication of the direction of the ECTF. The WG will continue work to develop specifications and define solutions as described in the next section.

4.3 Objectives of the Application Interoperability Workgroup (AIWG)

The specific objectives of the AIWG are as follows:

1. Define standard classes of data and specific keys for universal applicable data types such customer name, PIN, and account numbers.

2. The specifications will provide a method for applications to define the final state of a specific application/call interaction (result codes) in a standard way, so that decisions on subsequent processing can be performed. This WG will also work with the CT Services WG to recommend enhancements the S.100 specifications that will guide the implementation of these methods.

3. The WG will recommend appropriate operating behavior for CT applications to facilitate interoperability with other applications. Installation and operation of well-behaved CT applications should not corrupt other CT application’s private or shared environments such as configurations, shared libraries, or other parameter control data, which would prevent other applications from running correctly.

4. The operation of a specific CT application should not prevent cooperation with, hand-off to, or call routing among subsequent CT applications in the framework. The specifications shall recommend mechanisms for a specific application to accept control of a call from previous applications, and pass control of a call to subsequent applications.

5. The recommendations will allow a system engineer to control the routing of calls to specific applications:

• When the call arrives.

• After each application completes its portion of the call (predicated on well-defined result codes in the current application).

6. The recommendations must not require the system engineer to have to modify the CT applications to define the cooperative call routing and data sharing. All routing and data sharing functionality should be confined in specific framework objects defined to specifically perform these functions.

7. The framework should allow the removal, modification, or upgrading, of individual applications without affecting any other cooperating application. Whether individual applications and/or an entire CT system must be shut down, prior to any reconfiguration, must also determined. This WG will seek input and guidance in this area from the Administrative Services WG.

Section 5 : Scope

As with any endeavor, it is wise to put bounds on the goals surrounding this WG. The term “scope” is used to refer to the range or the limits of any effort. The previous section on goals describes not only what the goals of this paper are, it also describes the goals of the Application Interoperability Working Group.

5.1 Current Topics

The following subsection describes the current focus of the working group’s efforts. Following this, is the subsection, titled: Future Topics. The list is not meant to be all-inclusive, but serves as a place-holder for this working group to start investigating when the current scope has reached its end.

At the end of the section Deliverables, is a timetable to complete the work to which this WG is committed. Once completed, the WG will turn its attention to future topics.

5.1.1 Call Center Reporting Task Group

The ECTF is already developing uniform definitions of terms and statistics that are used in the specific area of CT known as “call center applications”. The Call Center Reporting Task Group focus is to define terms that describe the activities of a given call to a call center for the duration of the call (or as the task group goal describes the duration as: “from cradle to grave”). Its goals are to define unambiguous terms and associated statistics that terms represent. The end result of this TG’s activity will be to allow system engineers of call centers to generate statistics from different call center applications and be able to make legitimate comparisons of the resulting reports. It is expected the results of the Call Center Reporting Task Group’s work will be referenced heavily in reports, recommendations and specifications the that AIWG will produce.

5.1.2 Specifying CT Application Data

The WG will recommend (or define) mechanisms that provide the means to pass calls between CT applications. The WG will also specify data (its types and format) that can be shared between CT applications. Indeed, this singular effort may be considered the central focus of this WG’s output.

5.1.3 Defining Categories of CT Application Data

The data that can be shared between applications will be divided up into general categories of use. The following categories will be considered:

1. Data that can be considered global or sharable data,

2. Application specific data

3. Application termination status

Coinciding with the specification of data, the WG will provide guidelines and constraints for using the data and will also define levels of compliance. Internationalization issues shall also be considered. At the very least, the use of Unicode is recommended (and SI units shall also be considered).

5.1.4 Applications Using this Data

All of these components of application interoperability are needed for other entities that will control the flow and access that a given telephone call has to any assortment of CT applications. In the ECTF framework, the S.100 specification defines the semantics for a system call router (SCR). This WG will use the SCR as the basis to implement the functionality of an “application router.” Working with the CT Services WG, the AIWG will recommend enhancements to existing mechanisms (such as the S.100 Application Profile) to provide the means for applications to specify such things as input and output keys (and data) and termination status keys. Working with the Administrative Services WG, the AIWG will develop new functional interfaces to provide the management and control of CT applications interoperating.

Using these enhanced and new mechanisms, system engineers will have the solutions to the problems described earlier in this paper’s Problem Statement.

5.2 Future Topics

This subsection presents various areas of application interoperability that will be investigated at some time in the future. The fact that these topics are not being investigated presently does not imply they are less important.

5.2.1 Security

The ECTF acknowledges the importance and the impact of security on applications. Here, we use the term “security” to refer to the following areas:

• Data security as it is shared amongst applications

• Preventing CT applications from improperly taking control of a call

• Preventing CT applications from improperly usurping telephony resources

Applications using different security measures will introduce increased levels of complexity for system engineers who are trying to get CT applications to interoperate. The ECTF will not address this concern until there is a better understanding of the problem domain with input from the user member community.

5.2.2 Information Technology Services

Information Technology Services includes making available to CT applications uniform means to access “Directory Services” databases as well as other telephony information services such as cellular telephone databases; Home Location Registry (HLR) and Visitor Location Registry (VLR).

5.2.3 Resource Sharing

Another topic that has been considered a part of “Application Interoperability” is that of resource sharing. ECTF’s CT Services Working Group has defined the S.100 specification that addresses the concept. The specification defines a model for CT servers that provide resource sharing among CT applications utilizing the server’s media resources. If needed, further elaboration of this model would take place in that WG’s domain.

5.2.4 Other Areas

This WG will also investigate areas such as:

• Media conversion between CT applications

• “user to application” interoperability issues (ergonomic issues)

• CT script APIs (i.e., specifying uniform output from application generators)

• non CT applications interoperating with CT applications.

Section 6 : Working Group Deliverables

The ECTF will publish various documents that address the industry’s need for CT applications to interoperate. This WG will also work with other groups to extend their implementation agreements to facilitate application interoperability.

This WG will work with the Call Center Reporting Task Group (CCRTG) as the AIWG and the CCRTG converge on developing the means to make information collected during the call accessible to other applications that are not directly involved with call processing.

This WG will work with the CT Services WG to make recommendations to either further define or elaborate areas with in the S.100 specification that are needed for application interoperability.

In addition, this WG will work with the Administrative Services WG to develop recommendations for the administration of cooperating CT applications. Administrating these cooperating CT applications is a very important component of application interoperability. The WGs will develop specifications that will include OA&M and provisioning services (specifically related to cooperating applications).

6.1 A.001—Application Interoperability Framework

This Application Interoperability Framework is the ECTF’s first publication addressing application interoperability. Its goal is to make the CT community aware of the problems of making CT applications interoperate and to describe the size of the problem and give an indication of the difficulty of solving it. This WG’s intention is to publish this document to address the various aspects of application interoperability. One of the goals of this publication is to generate interest within the CT industry. We are specifically targeting application developers and system engineers of CT systems. With this document circulating within the CT industry, it is hoped that individual companies and engineers will provide input and feedback into the subsequent specification-definition process.

6.2 Guidelines, Requirements, Specifications, and Compliance Documents

This WG is fully aware that whatever documents are generated, it is up to the CT industry to make the endeavors of this WG successful. This WG also knows that success is dependent upon industry participation to provide input and feedback into this process. In this case, success is defined by observing the CT industry’s adoption of the ideas presented by this WG and proliferation of applications that have implemented this WG’s specifications or have written applications as per the guidelines described in the documents to be published.

It is important for this WG to develop specifications that can be utilized by CT application developers. In order for this WG to succeed, it must focus its energies on providing the solutions to application interoperability in a well-known operating environment: the ECTF CT Server architecture.

Another critical reason why this WG will focus upon the ECTF CT Server solution (and the S.100 specification) is because it presents a model for CT applications to share resources in a CT application server environment. The AIWG will present an addition model in which CT applications can cooperate on calls as well as share data. This model will be included in the “Guidelines” document described below. The “Specification” documents (also described below) will present data details necessary for developer implementations.

Once these documents have been deployed, developers who choose to work outside the ECTF architecture can adopt and implement portions of the specifications that allow their CT applications (and the associated operating “system”) to interoperate with ECTF architectures (or other operating environments that provide access to specific types of functionality needed to allow access to data and/or telephone calls).

6.2.1 A.100—Application Interoperability Guidelines

As indicated by its title, this deliverable will contain guidelines for CT application developers to follow. Essentially, this document will present a model in which CT applications can cooperate. The following topics shall be discussed (as they relate to a CT Server that supports the S.100 specification):

• Requirements during a call (don't hang up, etc.)

• Requirements & methods for passing control of a call

• How applications handoff control of a call

• So other cooperating applications will receive the call.

• So System administrator can control the route

• How applications accept control of a call

6.2.2 A.110—Application Interoperability Data Sharing Requirements

As indicated by its title, this deliverable will contain requirements for CT application developers to follow. The following topics shall be discussed (as they relate to a CT Server that supports the S.100 specification):

• Requirements for Shareable Data Functionality

• Making data accessible outside an S.100 group

6.2.3 A.120—Requirements and Methods for Routing Calls between Applications

As indicated by its title, this deliverable will contain requirements for CT application developers to follow. The following topics shall be discussed (as they relate to a CT Server that supports the S.100 specification):

• Using Call Termination Values

• Using other variables

• How System Administrators can change call routes among interoperating applications

This document will focus on S.100 components such as the System Call Router (SCR), Group Management APIs, and the Application Profile.

6.2.4 A.130—Application Interoperability Shared Data Specification

This document will further elaborate upon the ideas presented in this framework by presenting specific types of data that can be shared between cooperating CT applications (such customer name, PIN, and account numbers). This document will define Keys and Values that can be exchanged between cooperating CT applications. Along with application data, the specification will define termination status Keys along with associated data that accompanies the termination status.

This work is perhaps the most important with respect to non ECTF architecture, in that application developers and server vendors can “open up” their environments by supporting the means to exchange these defined keys and data.

6.2.5 A.200—Application Interoperability Compliance Specification

This WG recognizes the need to develop compliance documents that accompany the specification described above. In addition to guidelines, this WG shall specify the means to prove compliance and may also specify series of theoretical tests and/or test suites to accomplish these goals.

6.3 Timeframe

The AIWG shall begin the development of the A.1xx series of guidelines and specifications immediately upon publication of this framework document. The WG targets the completion of these deliverables within 12 months.

Development of the A.200 compliance specification will begin after such time that the A.1xx documents have had a chance to be utilized by the CT community at large.

Glossary

ACD

Automatic Call Distributors (ACD) are systems that route incoming calls to specific destinations based upon a variety of conditions.

Application generator

Sophisticated CT applications usually consist of small distinguishable components (such as “answer the phone”, play a voice file, collect DTMF digits). Application generators provide the means to create such applications by providing the ability to specify these small components and arrange them to satisfy a particular design.

AIWG

Application Interoperability Workgroup, a technical committee made of ECTF members.

Back office/small office

A term used originally to describe the location of a small office’s telecommunication equipment (such as a PBX). The term now quantifies the amount of telecommunication services required by small office environments.

Automatic Call Distributers

Refer to ACD.

Call Centers

Term used to collectively refer to people and telecommunication equipment organized to handle large volumes of in-bound or out-bound telephone calls.

Call Control Interface

In computer telephony, the application is exempted from the complexity of call processing. This model also provides an abstraction of the call so that the delivery of services to different types of call, such as ISDN, Internet or POTS, can be encapsulated. The call control interface is a set of operations that can be used on the call.

Caller ID (CLID)

The means to identify the calling party, available on residential telephone services. Acronym is CLID.

Central office

Term used to refer to telecommunication equipment used to connect public local phone service to long distance communication services. Acronym is CO.

CLID

Refer to Caller ID.

CT

Computer Telephony

Computer Telephony Integration (CTI)

The use of computer to provide the functions of a human operator and automates the execution of commands requested through a phone call activated whether by the voice or the key pad of the phone.

CPE

Customer premise equipment is telephony hardware located at the end user's location.

CTI

Refer to Computer Telephony Integration (CTI).

DTMF

Dual tone, multi-frequency. Also known by its AT&T trademark TouchTone™. These tones are generated by the keypad on telephones and interpreted (or detected) by telephony media resource’s known tone generators and can also be generated by the same type of resources.

DNIS

Dialed Number Identifier Sequences

ECMA

Previously, European Computer Manufacturers Association.

ECTF

Enterprise Computer Telephony Forum

Executing environment

Execution environment can refer to two areas. The first refers to the operating system, computing hardware and supporting utilities. The other refers to the facility and services provided by an application (execution) engine for the intermediate code from an application generator.

Fax

Image data processed in the form of facsimile (fax). International standards (ITU T.30 series of specifications) define the sending and receiving of images. Fax resources adhere to these standards and process and/or manipulate images.

Faxback

An application that provides a caller the ability receive a requested fax.

GUI

Graphical User Interface.

Hand-off/pass control

Each call has an owner but it can also allow others to access this call. The transfer of the ownership to another process is called the “hand-off” or “pass control” of that resource or call to other process.

HLR, VLR (wireless terms)

HLR is the Home Location Registry. VLR is the Visitor Location Registry. HLR contains the configuration and features subscribed by the subscriber. When the mobile unit moves from one cell to another, it transmits a message to the new cell to report its entrance. The local cell station will use the identification of the cellphone to get a copy of the configuration from the HLR and stores it in the local registry so that calls to and from the cellphone can be handled properly.

ISDN

Integrated Services Digital Network.

IVR

Interactive Voice Response applications generally plays voice files and solicits the caller to enter DTMF digits. IVR applications use the entered digits to determine the next course of action.

Media conversion

Media conversion refers to telephony technologies that converts one type of media to another, such as converting ASCII text file to either image data to be sent via fax (see) or converted to speech using a TTS resource (see).

Media Resources

Functionality to process incoming telephony information or to generate outgoing telephony information. Examples of media is voice record/play, fax send/receive, DTMF processing, text-to-speech and voice recognition (see).

OA&M

Operations, Maintenance and Administration.

PBX

Private Branch Exchange - Enterprise telephone system.

Predictive Dialer

A CT application that automatically dials phones numbers. These applications also usually are sophisticated enough to recognize busy signals, non-working numbers, answering machines or a person answering the phone.

PSTN

Public Switch Telephone Network.

Result code/termination status

When a request of service completes, it has a status associated with the request which can be as simple as success/failure or multiple states. This value is called the result code or the termination status. The initiator of the request can then act on this code/status.

Routing Mechanism

The means to route calls amongst CT applications.

SCR

System Call Router (S.100, S.300)

SI

French acronym for System International

Speech (voice) Recognition

Telephony media resource capable of analyzing telephony data to discern and identify spoken utterances

System engineer

Refers to any computer telephony engineer whose job is to work with CT applications in order to make them available for use by end users. This includes engineers who integrate CT applications to be sold as a single product or service (a “systems integrator”) as well as engineers who must install, configure and maintain CT applications at a user’s site (a “systems administrator”).

Switch technologies

The means to control and access a switched telephony network via a Private Branch Exchange (PBX) or via a Central Office’s (CO) access to the public switched telephone network (PSTN).

On a smaller scale, it refers to a CT application server’s ability to direct and control inbound telephone calls with media resources (see). For outbound calls, this includes the functionality to specify and dial phone numbers and then connect the call to media resources.

Systeme International

The French institute of standards. It also used to specify Metric System

TAPI

Telephony API (Microsoft)

TSAPI

Telephony Services API (Novell & AT&T)

TTS

Text-to-Speech telephony media resource capable of taking text data (usually an ASCII text file) and matching it with audio data representations of spoken words or phrases. It may also include the ability to utter phonemes to form words.

Unicode

A standard of 16 bit character encoding mechanism. Using this standard, multiple language can be differentiated from the code.

VLR

Visitor Location Registry. Also refer to HLR.

VRU

Voice Response Unit. See IVR.

Voicemail

Essentially the functionality of a mechanical answering machine that is implemented using computer technology to answer a phone line and record voice onto disk.

Voice record/play

Telephony media resource capable of processing voice. Incoming voice is stored (recorded) using various encoding schemes (in order to decrease the size of the data stored). This data can then be converted back to audio and played back to the caller.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download