C.001 Call Control Model
revision 1.0
Abstract
This document describes a model of call control services for the computer telephony integration (CTI) environment. The model describes services and interfaces that fit within the CTI architecture being documented by the Enterprise Computer Telephony Forum (ECTF), and which harmonize with computer telephony media services as described by the ECTF S.100 specification.
©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 :
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.
¥A.100 Architectural Framework, revision 1.0, Enterprise Computer Telephony Forum,1997. [A.100]
¥Addressing in Private Telecommunication Networks, ECMA Standard ECMA-155, June 1991. [ECMA-155]
¥Services for Computer Supported Telecommunications Applications (CSTA) Phase II, ECMA Standard 217, 1994. [ECMA-217]
¥Protocol for Computer Supported Telecommunications Applications (CSTA) Phase II, ECMA Standard 218, 1994. [ECMA-218]
¥Computer Supported Telecommunications Applications, ECMA Technical Report TR/52, 1990. [ECMA-TR52]
¥Scenarios for Computer Supported Telecommunications Applications (CSTA) Phase II, ECMA Technical Report TR/68, 1994. [ECMA-TR68]
¥ITU-T Recommendation E.131, Telephone Network and ISDN Operation Numbering, Routing and Mobile Service: Subscriber Control Procedures for Supplementary Telephone Services, 1993. [E.131]
¥ITU-T Recommendation E.160, Telephone Network and ISDN Operation Numbering, Routing and Mobile Service:Definitions Relating to National and International Numbering Plans, 1993. [E.160]
¥S.100 Media Services API Specification, revision 1.0, Enterprise Computer Telephony Forum,March 1996. [S100]
¥S.200 Media Services Protocol Specification, revision 0.2, Enterprise Computer Telephony Forum. [S200]
¥S.300 Draft Revision 0.01 Service Provider Interface (draft), Enterprise Computer Telephony Forum. [S300]
¥Stevens, W. Richard, UNIX Network Programming, PTR Prentice Hall, Englewood Cliffs, NJ, 1990. [STEVENS90]
¥Microsoft Windows Telephony ProgrammerÕs Guide (TAPI), Version 1.0, 1993. [TAPI1.0]
¥versitComputer Telephony Integration (CTI) Encyclopedia ,Volume 1: CTI Concepts and Terminology, revision 1.0, October 1996. [VOL1]
¥versitComputer Telephony Integration (CTI) Encyclopedia Volume 2: CTI Configurations and Landscapes, revision 1.0, October 1996. [VOL2]
¥versitComputer Telephony Integration (CTI) Encyclopedia Volume 3: Telephony Feature Set, revision 1.0, October 1996. [VOL3]
¥versitComputer Telephony Integration (CTI) Encyclopedia ,Volume 4: Call Flow Scenarios, revision 1.0, October 1996. [VOL4]
¥versitComputer Telephony Integration (CTI) Encyclopedia, Volume 5: CTI Protocols, revision 1.0, October 1996. [VOL5]
¥versitComputer Telephony Integration (CTI) Encyclopedia, Volume 6:versitTSAPI,
revision 1.0, October 1996. [VOL6]
¥ISO/IEC 8824:1990, Information Technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1). [X.208]
¥ISO/IEC 8825:1990, Information technology - Open Systems Interconnection - Specification of basic encoding rules for Abstract Syntax Notation One (ASN.1). [X.209]
¥ISO/IEC 9072-1:1989, Information processing systems - Text communication - Remote operations - Part 1: Model, notation and service definition. [X.219]
¥ISO/IEC 9072-2:1989, Information processing systems - Text communication - Remote operations - Part 2: Protocol specification. [X.229]
Contents
About ECTF
Reference Information
Contents
Section 1 : Introduction
1.1ECTF Call Model
1.2Relationship to APIs
Section 2 : Domains and Service Boundaries
Section 3 : Switching Devices
3.1Physical Elements
3.1.1Physical Element Components
3.1.2Physical Element Attributes
3.2Logical Elements
3.2.1Logical Element Attributes
3.2.2Appearances
3.3Device Configurations
3.3.1Logical Element Only
3.3.2Basic
3.3.3Multiple Logical Elements
3.3.4Standard Appearance
3.3.5Bridged/Logical Element Base Device
3.3.6Bridged/Physical Element Base Device
3.3.7Hybrid
3.4Device Identifiers
3.4.1Dialable Digits Format
3.4.2Switching Domain Format
3.4.3Device Number Format
3.4.4Canonical Phone Number Format
3.5Device Type
3.5.1Phone
3.5.2Network Interface Device
3.5.3ACD
3.5.4ACD Group
3.5.5Hunt Group
3.5.6Pick Group
3.5.7Park Device
Section 4 : Media Access
4.1Media Streams
4.2Media Access Devices
4.3Media Access via Call Associated Services
Section 5 : Agents
Section 6 : Connections
6.1Dynamic Feature Availability
Section 7 : Calls
7.1Call Types
7.1.1External Incoming Call
7.1.2External Outgoing Call
7.1.3Internal Call
7.2Call Identifier
7.3Call State
7.4Correlator Data
7.5User Data
7.6Miscellaneous Definitions Used with Calls
7.6.1Primary Call
7.6.2Secondary Call
7.6.3Primary Old Call
7.6.4Secondary Old Call
7.6.5Resulting Call
7.6.6Associated Called Device
7.6.7Associated Calling Device
7.6.8Called Device
7.6.9Calling Device
7.6.10Redirection Device
7.6.11Subject Device
7.6.12Transferring Device
7.6.13Transferred-to Device
Section 8 : Services
8.1Capabilities Exchange
8.2Status Reporting Services
8.2.1System Status Reporting Services
8.2.2Monitor Services
8.2.3Snapshot Services
8.3Call Control Services
8.4Call Associated Features Services
8.5Media Services
8.5.1Attach Media
8.5.2Detach Media
8.6Routing Services
8.7Physical Device Feature Services
8.8Logical Device Feature Services
8.9Vendor Specific Services
Section 9 : Events
9.1Call Control Events
9.1.1Bridged
9.1.2Call Cleared
9.1.3Conferenced
9.1.4Connection Cleared
9.1.5Delivered
9.1.6Digits Dialed
9.1.7Diverted
9.1.8Established
9.1.9Failed
9.1.10Held
9.1.11Network Capabilities Changed
9.1.12Network Reached
9.1.13Offered
9.1.14Originated
9.1.15Queued
9.1.16Retrieved
9.1.17Service Initiated
9.1.18Transferred
9.2Call Associated Feature Events
9.2.1Call Information
9.2.2DTMF Digits Detected
9.2.3Telephony Tones Detected
9.2.4Service Completion Failure
9.3Media Service Events
9.3.1Media Attached
9.3.2Media Detached
9.4Physical Device Feature Events
9.4.1Button Information
9.4.2Button Press
9.4.3Display Updated
9.4.4Hookswitch
9.4.5Lamp Mode
9.4.6Message Waiting
9.4.7Microphone Gain
9.4.8Microphone Mute
9.4.9Ringer Status
9.4.10Speaker Mute
9.4.11Speaker Volume
9.5Logical Device Feature Events
9.5.1Agent Busy
9.5.2Agent Logged Off
9.5.3Agent Logged On
9.5.4Agent Not Ready
9.5.5Agent Ready
9.5.6Agent Working After Call
9.5.7Auto Answer
9.5.8Call Back
9.5.9Call Back Message
9.5.10Caller ID Status
9.5.11Do Not Disturb
9.5.12Forwarding
9.6Device Maintenance Events
9.7Vendor Specific Events
Section 10 : Monitors
Section 11 : Flows
Section 12 : Features
12.1Forwarding
12.1.1Forwarding Trigger/Destination Specification
12.1.2Forwarding Event Sequences
12.2Connection Failure
12.3Recall
12.4Call Back
Section 1 : Introduction
The Call Control Interoperability Working Group (CCIWG) of the Enterprise Computer Telephony Forum (ECTF) wishes to increase the ability of computer telephony integration (CTI) hardware, system software, and application software to interoperate. In an environment in which a variety of interfaces (APIs and protocols) already have significant mindshare and market share, achieving interoperability by standardizing on an interface is proving to be difficult. However, the CCIWG observes that the underlying call control models (CCM) of existing CTI systems are substantially similar to each other; another pathway to interoperability is to specify a rich CCM that can satisfy the requirements of present and future CTI systems, and that can thus allow multiple interfaces to coexist without jeopardizing the basic interoperability of CTI systems.
1.1ECTF Call Model
This document describes a call control model (CCM), consisting of descriptions of call control services and their interfaces. It draws on a variety of previous call control works as listed in the references (primarily [ECMA-217] and [VOL3], and in fact often borrows specifications from these works or points to them for additional details).
The call model exists in the context of the ECTF Architectural Framework, defined in [A.100]. That framework contains components that provide call control services in alternate ways - the Òline cardÓ level as well as the server level are represented there, as well as protocols, service providers, and several different APIs. It also depicts a relationship between call control components and a media server. The goal of this present document is to document an abstract call control model that any of the architectural alternatives could provide, and which can interact effectively with a media server as described in [A.100].
The CCIWG expects that this model will be refined as a result of liaison relationships with ECMA TC32/TG11 (who are currently developing CSTA Phase III) and Javasoft (who have contributed the JTAPI specification for review and possible inclusion as an interoperability agreement).
This document will be revised as the various stakeholders in call control models interact. Each published revision of the call control model is issued in the hope/expectation that interested stakeholders can use the concepts documented therein to further their own work.
The following topics are covered:
¥Definitions of the telephony server environment, consisting of switching and computing domains, and the modes of interaction between objects in these domains (e.g., request/response/event).
¥A definition of switching domain objects (e.g., devices, agents, calls), along with their attributes and parameters.
¥A definition of calls, call states, and terminology to express the semantics of call control services more precisely.
¥A description of call control services.
¥A description of the flows associated with the services.
¥An abstraction of the so-called first- and third-party models into one consistent model.
¥Support for voice as well as data calls.
¥A description of conformance requirements to engender interoperability among implementations.
1.2Relationship to APIs
Computer Telephony environment consists of two major components; a switching domain and a computing domain. In general, the term computing domain describes the side of the boundary that communicates with the set of computing resources involved in a CT system while the term switching domain refers to the side of the boundary that communicates with the set of telephony resources. In the general case, a protocol interface is used to communicate between the two domains.
The Call Model principally defines the call control features, services and interfaces within the switching domain. An API provided within the computing domain is a mechanism to access the services and resources within the switching domain (and documented in the model), and are outside of the scope of this document. The ECTF call model is sufficiently rich to support the various APIs and protocols existing in the CTI environment today. It should be noted that the various Call Control APIs do provide mechanisms for interworking with the various Media Services APIs such as the S.100 defined by the ECTF CT Services working group. The reader is encouraged to refer to the ECTF Architecture Framework document to understand the relationship between Call Control and the ECTF S.100 Media Services on a CT server platform [A.100].
Section 2 : Domains and Service Boundaries[1]
A CTI system consists of a switching domain and a computing domain. A domain may be an active entity, itself capable of reporting and requesting status and operating on the objects within it. The computing domain consists of one or more programs, which may run independently of each other or which may interact with each other. The switching domain consists of hardware and software components that interact with each other so as to provide voice and data calls. There is an interface between the computing and switching domains, referred to as a service boundary. A computing domain component and a switching domain component interact with each other by sending switching and computing domain service requests (a message requesting that a particular action be performed), service responses (a message issued in response to a service request, describing its disposition), and events (a message other than a request or response, not itself requiring a response and typically providing information about a change of state of some component) to each other across the service boundary.
The call control model is expected to evolve over time. At any point in time, switching domains and computing domains are conformant with one or more versions of the call control model. The middleware that enables the two domains to interact with each other should provide a version negotiation mechanism to allow the two domains to agree on a common version of the model to use. The mechanism is provided via technology appropriate to the middleware. In CSTA, for example, this may be provided by a version negotiation protocol defined by ASN.1 and session protocols. In a CORBA or DCOM model, this may be provided by explicit identification of objects via their versions.
The switching domain in particular is an Òactive domainÓ. It is configured, initialized, and stopped by management services that are out of the scope of the CCM. Telephony services and events (e.g., calls between phones within the switching domains, inbound/outbound calls from/to external devices) may take place in the switching domain regardless of whether objects in the computing domain are interacting with it or not. Programs in the computing domain that request call control services do so in addition to the services that the switching domain performs autonomously or which are performed by the manual interaction of a user with a device.
A domain may allow objects in another domain to register to receive status information.
A domain has associated with it a status (or system status), which may be reported across a service boundary to another domain, and may be requested over the service boundary by another domain. The possible status values are:[2]
¥Initializing: The status indicates that the domain is re-initializing or restarting, and temporarily unable to respond to any service requests. If provided, this status message shall be followed by an Enable status message that indicates that the initialization process is completed.
¥Normal: This status indicates that the domain status is ÒnormalÓ.
¥Message Lost: This status indicates that a service request, response, or event report may have been lost.
¥Disabled: This status indicates that any monitors (see Section ) that may have been running have been disabled.
¥Overload Imminent: This status indicates that the domain is about to reach an overload condition. Domain objects on the other side of this domain's service boundary should attempt to take actions to avert overload.
¥Overload Reached: This status indicates that the domain has reached an overload condition and may take action to shed load.
¥Overload Relieved: This status indicates that the domain has determined that overload condition has passed and normal application operation may resume.
Section 3 : Switching Devices
A switching device (or, usually, just device) is Òan abstraction in the switching domain that represents various types of telephony endpoints and allows access to telephony servicesÓ[3]. A device can be a single endpoint (e.g., phone), a composition of more basic devices (e.g., a multi-line phone) or multiple endpoints that identify a single conceptual entity (e.g., ACD group). All devices in a switching domain are endpoints; they either interface to an off-net object, or are manipulated by a user.
A device is represented by its attributes (e.g., its identifier, type, profile, the physical and call states in which it might be set), the services which it provides, and the features which it provides or which modify its operation. Attributes can be observed and set (resulting in control of the device) by the computing domain. Services and features may be invoked from the computing domain, resulting in a call control operation taking place involving the device.
The attributes, services, and features of a device (which will here be termed its interfaces) can be put into categories called elements. A device may contain a physical element consisting of those interfaces presented to a user, and a logical element consisting of those presented to the switching domain (i.e., those used in call control operations). Every device contains either zero or one physical element and zero or one logical element.
A composite device, referred to as a device configuration, is formed by a collection of devices. Device configurations are discussed in more detail in Section .
In general, device elements (and, in turn, their constituent parts) may or may not be visible. Whether an element is visible is implementation-dependent. If an element (or sub-element) is visible, it has associated with it a device identifier by which it is identified in the service boundary interface. Device identifiers are described in Section .
3.1Physical Elements
A physical element is the set of device interfaces that provide an interface to a user. Its constituent parts, called components, are objects whose attributes correspond to a human observable object (e.g., a button on a telephone, or a Òsoft buttonÓ in an application program). A physical element's observable attributes correspond to observable quantities in a physical object, and its settable attributes correspond to controls in the physical object.
3.1.1Physical Element Components
Physical components have component identifiers that are specific to their component type and referenced with respect to their owning device element. For example, a lamp component of a phone has a lampID which is used in services that get or set the state of the phone; those services use both the device identifier and the lampID to reference the lamp.