Standard ECMA-217 De c ember 1994
Standardizing
Information
and
Communication
Systems
Services for Computer Supported Telecommunications Applications (CSTA) Phase II
P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h
Standard ECMA-217 De c ember 1994
Standardizing
Information
and
Communication
Systems
Services for Computer Supported Telecommunications Applications (CSTA) Phase II
P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h IW - ECMA-217.DOC - 16.11.95 17,08
Brief History
This Standard defines Phase II of Services for Computer Supported Telecommunications Applications (CSTA) for OSI Layer 7 communication between a computing network and a telecommunications network. This Standard and its companion Standard ECMA-218 Protocol for Computer Supported Telecommunications Applications (CSTA) Phase II reflect agreements of ECMA member companies on Phase II of the standards for CSTA. Additional phases are anticipated. This Standard is based on the practical experience of ECMA member companies and represents a pragmatic and widely-based consensus. This Standard takes direction from Technical Report ECMA TR/52 Computer Supported Telecommunications Applications. Phase II of CSTA extends the previous Phase I standard in major theme directions as well as numerous details. Major areas of advancement include: • the addition of explicit application context negotiation mechanisms; • the addition of I/O services; • the addition of Special Resource Functions and, particularly, Voice Unit services; • new and/or enhanced services and event reports for commonly used call control and monitoring applications; new services include Single Step Transfer, Single Step Conference, Call Park and Send DTMF Signals. The Phase II CSTA standards are not fully backwards compatible with the Phase I standards. Although backwards compatibility is an important consideration and has been maintained whenever possible, the addition of new parameters in certain services and events, as well as the deletion of unused Phase I services and the addition of entirely new Phase II services and events, did not allow complete backwards compatibility.
This Standard is dedicated to the memory of Terry Wuerfel.
This ECMA Standard has been adopted by the ECMA General Assembly of December 1994.
- i -
Table of contents
Page 1 Scope
1
1.1 Summary of changes from CSTA Phase I
1
2 Conformance
2
3 References
2
3.1 ECMA references
2
3.2 ISO references
2
4 Definitions and abbreviations
3
4.1 CSTA-specific definitions
3
4.2 Terms defined elsewhere
5
4.3 Acronyms
5
5 Functional architecture
7
5.1 Distribution of Computing and Switching Functions
7
5.2 CSTA Service
8
5.3 Per-Service Client/Server Model
8
5.4 Service and Objects
9
6 CSTA operational model
10
6.1 Switching sub-domain model
11
6.1.1 Device
11
6.1.2 Call
13
6.1.3 Connection
13
6.1.4 Call Event Reports
14
6.1.5 Call states
15
6.1.6 Agent
16
6.1.7 Management of dynamically-assigned Identifiers
17
6.2 Special Resource Functions
18
6.2.1 Voice Unit
18
7 Association Establishment
20
8 Security Service
21
9 Generic Service requirements
22
9.1 Service Request
22
9.2 Service Response
22
9.3 Functional description
22
9.4 Diagnostic error definitions
23
- ii -
9.4.1 Operation errors
23
9.4.2 Security errors
24
9.4.3 State incompatibility errors
25
9.4.4 System resource availability errors
25
9.4.5 Subscribed resource availability errors
25
9.4.6 Performance management errors
26
9.4.7 CSTA private data information errors
26
9.4.8 Unspecified errors
26
10 Switching Function Services
27
10.1 Alternate Call Service
27
10.2 Answer Call Service
28
10.3 Associate Data Service
29
10.4 Call Completion Service
30
10.5 Clear Call Service
32
10.6 Clear Connection Service
33
10.7 Conference Call Service
34
10.8 Consultation Call Service
36
10.9 Divert Call Service
37
10.10 Hold Call Service
39
10.11 Make Call Service
40
10.12 Make Predictive Call Service
42
10.13 Park Call Service
44
10.14 Query Device Service
45
10.15 Reconnect Call Service
48
10.16 Retrieve Call Service
49
10.17 Send DTMF Tones Service
50
10.18 Set Feature Service
51
10.19 Single Step Conference Service
53
10.20 Single Step Transfer Call Service
55
10.21 Transfer Call Service
57
11 Status Reporting Services
59
11.1 Change Monitor Filter Service
59
11.2 Event Report Service
61
11.2.1 Service Request
61
11.2.2 Agent State Event Reports
62
11.2.2.1 Agent Logged Off
63
11.2.2.2 Agent Logged On
64
11.2.2.3 Agent Not Ready
65
11.2.2.4 Agent Ready
66
11.2.2.5 Agent Working After Call
67
11.2.2.6 Agent Busy
68
11.2.3 Call Event Reports
69
- iii -
11.2.3.1 Call Cleared
70
11.2.3.2 Conferenced
71
11.2.3.3 Connection Cleared
72
11.2.3.4 Delivered
73
11.2.3.5 Diverted
74
11.2.3.6 Established
75
11.2.3.7 Failed
76
11.2.3.8 Held
77
11.2.3.9 Network Reached
78
11.2.3.10 Originated
79
11.2.3.11 Queued
80
11.2.3.12 Retrieved
81
11.2.3.13 Service Initiated
82
11.2.3.14 Transferred
83
11.2.4 Feature Event Reports
84
11.2.4.1 Call Information
84
11.2.4.2 Do Not Disturb
85
11.2.4.3 Forwarding
86
11.2.4.4 Message Waiting
87
11.2.4.5 Auto-Answer
88
11.2.4.6 Microphone Mute
89
11.2.4.7 Speaker Mute
90
11.2.4.8 Speaker Volume
91
11.2.5 Maintenance Event Reports
92
11.2.5.1 Back In Service
92
11.2.5.2 Out Of Service
93
11.2.6 Private Event Reports
94
11.2.7 Voice Unit Event Reports
95
11.2.7.1 Play
95
11.2.7.2 Record
96
11.2.7.3 Review
97
11.2.7.4 Stop
98
11.2.7.5 Suspend Play
99
11.2.7.6 Suspend Record
100
11.2.7.7 Voice Attributes Change Event
101
11.2.8 Service Response
101
11.2.9 Functional description
101
11.2.10 Cause codes
102
11.2.10.1 Agent Event Cause codes
102
11.2.10.2 Call Event Cause codes
102
11.2.10.3 Voice Unit Event Cause codes
106
11.2.10.4 I/O Service Cause codes
107
11.3 Monitor Start Service
108
11.4 Monitor Stop Service
111
- iv -
11.5 Snapshot Call Service
112
11.6 Snapshot Device Service
113
12 Computing Function Services
114
12.1 Re-Route Service
114
12.2 Route End Service
115
12.3 Route Request Service
116
12.4 Route Select Service
117
12.5 Route Used Service
118
13 Bi-directional Services
119
13.1 Escape Service
119
13.2 System Status Service
120
14 Input / Output (I/O) Services
121
14.1 Data Path Resumed
121
14.2 Data Path Suspended
122
14.3 FastData
124
14.4 Resume Data Path
125
14.5 Send-Broadcast-Data
126
14.6 Send Data
127
14.7 Send-Multicast-Data
128
14.8 Start Data Path
129
14.9 Stop Data Path
131
14.10 Suspend Data Path
132
15 Voice Unit Services
133
15.1 Concatenate Message
133
15.2 Delete Message
134
15.3 Play Message
135
15.4 Query Voice Attribute
136
15.5 Record Message
138
15.6 Reposition
139
15.7 Resume
140
15.8 Review
141
15.9 Set Voice Attribute
142
15.10 Stop
143
15.11 Suspend
144
15.12 Synthesize Message
145
1
Scope Services and Event Reports supported by Computer Supported Telecommunications Applications (CSTA) Phase II are defined in this Standard. This Standard is focused on providing an application service interface between a Switching Function and a Computing Function. The CSTA application interface is disassociated from the various user-network interfaces and networknetwork interfaces CSTA applications may serve, observe or manipulate. Because CSTA operates with existing telecommunications interfaces indirectly, it operates generically, so that differences among various existing interfaces are hidden from CSTA applications. Support of user-to-network interfaces is outside the scope of CSTA. Although most terminal equipment (TE) are suitable for use with CSTA there will be instances of TE that will not be suitable in certain circumstances. Examples are: • Fax terminals and modems that are unable to adjust their transmission modes to prevent carrier conflict when both parties are alerted via CSTA during call establishment, • Functional terminals that perform telecommunication functions outside the control of the Switching Function. The individual Services needed to support the CSTA applications described in ECMA TR/52 Computer Supported Telecommunications Applications are covered in this Standard. This Standard provides an OSI Application Layer Protocol that supports a peer-to-peer relationship between computing and telecommunications networks. Every instance of each CSTA Service is a client-server relationship. Services defined in this Standard allow functional integration between a computing network and a telecommunications network. Computing platforms (i.e. Application Programming Interfaces - APIs) that support such functionallyintegrated applications are outside the scope of this Standard. Communication between the computing and switching (i.e. telecommunications) networks may take place via intervening networks ranging from simple point-to-point connections to local- or wide-area telecommunications networks. A companion Technical Report ECMA TR/68 CSTA Scenarios illustrates practical applications of CSTA Services to implement common call handling and monitoring procedures. ECMA TR/68 is intended to serve as a guide to better understanding of CSTA and provides recommended (but not mandatory) examples of Service Requests with particular parameter values and Event Reports associated with typical CSTA-based procedures.
1.1
Summary of changes from CSTA Phase I CSTA Phase II extends CSTA Phase I capabilities in several theme areas. Key additions and changes from CSTA Phase I include the following: • Input/Output (I/O) Services have been added. These allow establishment, utilization and control of data paths for the transfer of audio, video, textual and other data-media between CSTA objects. New I/O Services include Start Data Path, Stop Data Path, several types of send data Services and other Services as well. These services provide a mechanism for collection of DTMF-encoded signals entered by humans or automatic devices. • Special Resource Functions (in addition to Switching and Computing Functions available in CSTA Phase I) have been added to the CSTA model. This Function subsumes devices offering specialized capabilities such as speech recording and playback. Voice Units, now supported in CSTA Phase II, represent a particular embodiment of such devices. • Voice Unit Services have been added. These allow control of basic voice unit functions including message recording and playback, text-to-speech synthesis, message saving and concatenation. Events and cause codes to support these have been added. • Several new, independent (i.e. do not fall into I/O or Voice Unit Services groups) services. These Services include Associate Data, Send DTMF Tones, Single Step Transfer and Call Park. These additions reflect response to emerging technologies and practical experience gained with CSTA Phase I. • Enhancements have been made to Agent State and Call State models as well as underlying CSTA Models. These changes ensure compatibility with new CSTA Services (e.g. I/O Services) and with other evolving international standards. A Voice Unit state model has been added to complement the new Voice Unit Services and Event Reports.
- 2 -
• For existing (CSTA Phase I) Services and Event Reports, new parameters have been added, some parameters have been deleted and the definitions of others have been enhanced and/or clarified. These changes also reflect practical experience, accommodation of the new models. • Version and capability negotiation functionality have been included in CSTA Phase II via the ASCE mechanism. • Increased support for ISDN has been added. Enhancements include recognition and use of Device Profiles, Device Classes and sub-addressing in appropriate Service and Event parameters. Although a goal in developing CSTA Phase II has been backwards compatibility with CSTA Phase I, this has not been achieved completely. Incompatibility has resulted from addition of parameters to support new capabilities in existing Services, changes in the optionality of certain parameters to reflect the needs of newer technologies that require these parameters for their effective utilization, and clarification of the operation of certain Services, particularly in respect to new Call State and Agent State models.
2
Conformance A protocol is in conformance with this Standard if that protocol meets all mandatory requirements of clauses 4, 6, 7 and 9, and meets all mandatory requirements of one or more of the following clauses / sub-clauses: 8, 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.15, 10.16, 10,17, 10.18, 10.19, 10.20, 10.21, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 12.1, 12.2, 12.3, 12.4, 12.5, 13.1, 13.2, 14.1, 14.2, 14.3, 14.4, 14.5, 14.6, 14.7, 14.8, 14.9, 14.10, 15.1, 15.2, 15.3, 15.4, 15.5, 15.6, 15.7, 15.8, 15.9, 15.10, 15.11, 15.12.
3 3.1
3.2
References ECMA references ECMA-138
Security in Open Systems - Data Elements and Service Definitions (1989)
ECMA-218
Protocol for Computer Supported Telecommunications Applications (CSTA) Phase II (1994)
ECMA TR/46
Security in Open Systems - A Security Framework (1988)
ECMA TR/52
Computer Supported Telecommunications Applications (CSTA) (1990)
ECMA TR/68
Scenarios for Computer Supported Telecommunications Applications (CSTA) Phase II (1994)
ISO references ISO 7498:1984
Information processing systems - Open Systems Interconnection - Basic reference model
ISO 8649:1988
Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element (this corresponds to CCITT Rec. X.217)
ISO/IEC 8824:1990
Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1) (this corresponds to CCITT Rec. X.208)
ISO/IEC 8825:1990
Information technology - Open Systems Interconnection - Specification of basic encoding rules for Abstract Syntax Notation One (ASN.1) (this corresponds to CCITT Rec. X.209)
ISO/IEC 9072-1:1989
Information processing systems - Text communication - Remote operations - Part 1: Model, notation and service definition (this corresponds to CCITT Rec. X.219)
ISO/IEC 9072-2:1989
Information processing systems - Text communication - Remote operations - Part 2: Protocol specification (this corresponds to CCITT Rec. X.229)
ISO/IEC 10031-1:1991 Information technology - Text and office systems - Distributed-office-applications model Part 1: General model ISO/IEC 11572:1994
Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Circuit mode bearer services - Inter-exchange signalling procedures and protocol
- 3 -
4
Definitions and abbreviations The following definitions apply in this Standard.
4.1
CSTA-specific definitions The prefix CSTA applies to all terms included in the following list:
4.1.1
ACD Agent A CSTA user that is a member of an inbound or outbound ACD group. ACD Agents are distinguished from other CSTA users by their ability to sign-on (Login) to systems that coordinate and distribute calls.
4.1.2
Active Call A CSTA call for which the local (or subject) Connection is in the Connected State.
4.1.3
Agent A CSTA user authorized to act on behalf of the provider of the CSTA application.
4.1.4
Alerting Call A CSTA call for which the local (or subject) Connection is in the Alerting State.
4.1.5
Application A cooperative process between a Switching Function performed within a switching network and a Computing Function performed within a computing network.
4.1.6
Application Domain The union of one switching sub-domain and one computing sub-domain.
4.1.7
Basic Call A call involving exactly two associated devices.
4.1.8
Call A Switching Function communications relationship generally between two or more devices. In some circumstances, including set-up and release, there may be only one device. A call is a CSTA Object.
4.1.9
Complex Call A call involving more than two devices.
4.1.10
Computing Domain The set of computers and their objects that can be reached by a CSTA application from a switching domain.
4.1.11
Computing Function The part of the domain needed to support CSTA applications that is also within a Computing or Special Resource sub-domain.
4.1.12
Computing Sub-domain Any configuration of inter-connected computers that presents the appearance and functionality of a single computer to the switching and special resource domains.
4.1.13
Connection An object defined by CSTA to represent the relationship between a call and a device.
4.1.14
Connection Identifier An identifier used in CSTA to identify a relationship between a specific call and a specific device. The CSTA Connection Identifier comprises a Call Identifier and a CSTA Device Identifier. Together, these identifiers specify a unique CSTA Object in the context of a CSTA Association.
4.1.15
Device A logical entity and CSTA Object that serves as an endpoint for a call and accepts signalling information from, and provides such information to, the Switching Function. A device can encompass multiple endpoints that act together (forming a group) to provide this function.
- 4 -
4.1.16
Directory Number A logical representation of a party or device. It is typically associated with a line (extension) circuit.
4.1.17
Domain The union of the switching, computing and special resource domains.
4.1.18
Event A stimulus that causes a change in the state of a CSTA object.
4.1.19
Event Report A message that indicates a change in the state of a CSTA object.
4.1.20
Held Call A CSTA call for which the local (or subject) Connection is in the Hold state.
4.1.21
Interconnection Service Boundary The abstract Service Boundary within a system supporting a CSTA Application that separates the communications component of the application from the networking support functions of the system.
4.1.22
Object An abstract entity that embodies some aspect of the externally-visible and/or functional characteristics of a physical entity.
4.1.23
Party An entity outside the Switching Function that has the ability to use the Switching Function.
4.1.24
Security The characteristics of a system that give it resistance to misuse and unauthorized access.
4.1.25
Security Domain A bounded set of security entities that is subject to a single security policy and a single security administration.
4.1.26
Security Object A passive entity to which a security policy applies.
4.1.27
Security Policy A set of rules that specify the procedures and mechanisms required to maintain the security of a system.
4.1.28
Security Service A set of operations designed to support some aspect of security in a system.
4.1.29
Security Subject An active entity to which a security policy applies.
4.1.30
Service A benefit provided by one CSTA application process to another.
4.1.31
Service Boundary The functional boundary between a CSTA Computing Function and a CSTA Switching Function as it is established via their Interconnection Service Boundaries over some underlying interconnection medium.
4.1.32
Special Resource Domain The set of special resources and their objects that may be reached directly or indirectly by a CSTA application from a computing or switching domain.
4.1.33
Special Resource Function That part of the domain needed to support CSTA applications implemented within a special resource network or sub-domain.
- 5 -
4.1.34
Special Resource Sub-domain Any configuration of inter-connected special resources that presents the external appearance and functionality of a single special resource to the computing or switching domain.
4.1.35
State An indication of an object’s current condition that permits prediction of the object’s future behaviour.
4.1.36
Switching Domain The set of switches and their objects that may be reached by a CSTA application from a computing or special resource sub-domain.
4.1.37
Switching Function The part of the domain needed to support CSTA applications that is implemented within a switching sub-domain.
4.1.38
Switching Sub-domain Any configuration of inter-connected switches that presents the functionality of a single switch to the computing or special resource domain.
4.1.39
User A person, process or piece of equipment that receives direct benefit (e.g. added functionality, improved performance) from services provided by a CSTA application.
4.2
Terms defined elsewhere The following terms, defined in other publications, are used in this Standard: ISO 7498
Application-Entity Application-Entity-Title Application Layer Application-Process Application-Service-Element
ISO 8649
Application Association Application Context Association Control Service Element
ISO/IEC 9072
Remote Operations
ISO/IEC 10031-1 Client Server ISO/IEC 11572
4.3
Bearer Capability High Layer Compatibility Information Element Low Layer Compatibility SetUp Subaddress
Acronyms ACD ACSE API ASE ASN BRI CODEC CSTA DTMF ID ISDN ISO ITU-T
Automatic Call Distributor Association Control Service Element Application Programming Interface Application Service Element Abstract Syntax Notation Basic Rate Interface COder/DECoder Computer Supported Telecommunications Applications Dual Tone Multi-Frequency Identifier Integrated Services Digital Network International Standards Organization International Telecommunications Union - Telecommunications (formerly CCITT)
- 6 -
ODP OSI PAC PDU PTN ROSE SIT SRF TE
Open Distributed Processing Open System Interconnection Privilege Attribute Certificate Protocol Data Unit Private Telecommunications Network Remote Operation Service Element Special Information Tone Special Resource Function Terminal Equipment
- 7 -
5
Functional architecture The functional architecture described in ECMA TR/52 is summarized in this sub-clause. The objective of CSTA Architecture is to define the inter-working mechanisms among Computing, Switching and Special Resource Functions independently from their physical implementations. The concepts of distribution of Computing, Switching and Special Resource Functions, CSTA Service, client server model, and CSTA objects as abstracted at a CSTA Service Boundary, will now be introduced. A CSTA application is supported by two or more of the following: • a computing component (normally based in the computing network), • a switching component (normally based in the telecommunications network), • a special resource component (normally associated with either the computer or telecommunications network). The operation of these components involves one or more interactions among them.
5.1
Distribution of Computing and Switching Functions Typically, the Computing Functions are implemented by one or more computers in a computing network, the Switching Functions are implemented by one or more switches in a telecommunications network and the Special Resource Functions are implemented by one or more physical devices co-resident with either the Computing or Switching Function. It is possible, however, for some Computing Functions to be performed within the Switching Function and some Switching Functions within the Computing Function. Similarly, Special Resource Functions might be performed within either the Computing or Switching Functions. The CSTA application appears to the user (human or machine) as a single application on a single network, not as two or more separate functions on two or more separate networks (as it is, in fact, implemented). Since the functions of the CSTA applications are (in most situations) distributed, some form of communications support is required. This can be shown by expanding each of the distributed functions into a processing component – or application functionality (to support the defined interactions), a communications component – or CSTA Services (to support the necessary exchange of messages), and networking support – or a lower-layer interconnection service provider. The relationship is shown in the following figure.
Processing Component
CSTA Service Definitions
Processing Component
Local Representation of CSTA Service Definitions Comm's Component
CSTA Protocol
Comm's Component
Local Representation of CSTA Protocol
Networking Support Figure 1 - Functional Diagram of the relationship between CSTA Elements in an Open Distributed Processing (ODP) Environment It can be seen in figure 1 that the distributed application functions interact with their peers in accordance with CSTA Service definitions. In this Standard, Service Descriptions define these interactions and the service interface between the application functionality and the local CSTA Service by which the peer-to-peer service interaction is supported. A CSTA Service communicates with its peer using CSTA protocol (i.e. the set of messages and associated sequencing rules etc. defined in this Standard). Note, however, that the CSTA protocol is designed to support various approaches and, as a consequence, some protocol elements are optional and their use is implementation-dependent.
- 8 -
In an OSI environment the application functions and CSTA Service form an application process invocation. The necessary communications component is provided by an application entity invocation considered to reside in the OSI application layer. The underlying networking support is typically provided by OSI lower layers.
5.2
CSTA Service In the context of the OSI Reference Model and excluding the Application layer, the word “service” refers to the benefit provided by one layer to its adjacent, higher layer. In the context of the ITU-T definition of the services provided by a real network, e.g. an ISDN, the term “service” applies to that which is offered by the network to a user at a given reference point, e.g. the S reference point. How the OSI layer and ITU-T network notions of “service” relate to one another is shown, in simplified form, in the following figure. OSI layer services have a vertical orientation - i.e. each layer provides an OSI service to the layer above it. ITU-T ISDN Basic and Teleservices, as the latter also embrace those of the Application layer, have a horizontal orientation - i.e. service is provided between peers in the same OSI level. In the following figure, “OSI Services” are provided by the Lower Layer Interconnection System to the Application Layer, while “ITU-T/CSTA Services” are provided between the Switch Services and Computer Services Application Layer Functions.
CSTA Service Boundary
Application "Switch" Layer Services Functionality
"Computer" Services
Application Layer Functionality
Application Layer
Lower Layer Interconnection System Figure 2 - OSI and ITU-T/CSTA uses of the term “Service” Unless otherwise qualified, in this Standard the term “Service” means the benefit provided by one application layer process to its peer application layer process(es). CSTA Services have been designed to allow decoupling from the actual Telecommunications Services provided to users by the Switching Function. This makes CSTA independent of the specific user-to-network interface of the particular terminals for which CSTA is requesting services. The Switching Function is therefore responsible for determining how to support a given CSTA request. The relationship between CSTA Services and services provided to users by computers and Special Resources is similarly de-coupled: computers and Special Resources (such as voice synthesizers, recorders, etc.) may provide CSTA Services in any way that is convenient and/or appropriate. CSTA imposes no implementation constraints on the internal functioning of computer applications, Special Resources or their connections to the Switching Function. For example, CSTA does not specify how to provide the Make Call Service on terminal types such as analog, ISDN, etc. It is expected that the Switching Function will use existing telecommunications services when providing CSTA Services on terminals for which standards exist (e.g. when CSTA requests Hold Call Service for a PTN terminal, the Switching Function will respond to that request according to the Supplementary Service Call Hold [SS-HOLD] Service definition). CSTA has no knowledge of how the Switching Function accomplishes requested CSTA Services. The Switching Function provides only an abstraction to the CSTA Service Request or of how the Service is realized.
5.3
Per-Service Client/Server Model The communications (as opposed to the processing) mechanism required to support the CSTA application can be modelled as a client/server relationship (such as described in ISO/IEC 10031-1). A processing component (identified in ISO/IEC 10031-1 as the User) requests a Service. Its local communications component, termed a
- 9 -
client, invokes that particular service by communication with its peer, termed a server. The client/server relationship models application level communication and hence can be considered as belonging to the OSI application layer. Because the CSTA architecture provides bi-directional capabilities among the Switching, Computing and Special Resource Functions, the client/server relationship is possible in both directions between any pair of functions as depicted (for the Computing and Switching Functions) in the following figure. Similar representations could also be drawn relating the Special Resource Function to the Computing and Switching Functions. Note that in this figure, the arrows show the direction of service provision - not the direction of request for service.
Computing Function
Switching Function Switching Function Service Definition
client
server
CSTA Service Boundary
server
Computing Function Service Definition
client
Figure 3 - Bi-directional Services Illustration Services in which the Computing Function is the client and the Switching Function is the server are defined as Switching Function Services. An example of a Switching Function Service is the Make Call Service. Services in which the Switching Function is the client and the Computing Function is the server are defined as Computing Function Services. An example of a Computing Function Service is the Route Request Service. Service definitions in which the Special Resource Function is the server and the Computing or Switching Function is the client are defined as Special Resource Function Service definitions. An example of a Special Resource Function Service is the Play Message Service.
5.4
Service and Objects Services provided by a server to a client consist of observing and/or acting upon objects that can be accessed by the server on behalf of the client. The objects and their behaviour, as perceived over the client/server interface, are defined in implementation-independent terms in the CSTA operational model (see clause 6, CSTA operational model).
- 10 -
6
CSTA operational model The operational model considered for CSTA is summarized in this clause. For the purposes of standardization, all definitions and procedures specified in this clause are normative (mandatory). The modelling aspects are informative. The set of accessible Computing, Switching and Special Resource Functions from which an application might receive service defines a CSTA domain. An example of a CSTA domain is shown in the next figure. The CSTA domain contains switching, computing and special resource domains that are divided in the figure by the heavy lines. The special resource, switching and computing domains comprise Computing Functions (C1, C2 and C3), Switching Functions (S1, S2 and S3), and Special Resource Functions (SR1, SR2 and SR3). Each function can provide to a CSTA application, a view of the domain in which the function resides. Each such view defines a sub-domain. If one or more functions provide an identical view, then these functions are part of the same sub-domain. CSTA applications encompass at least two different sub-domains, and are represented in the next figure as application domains.
Computing Domain
Switching Domain Switching Sub-domain
Computing Sub-domain S1
Application Domains C1
Application Domain S2 Computing Sub-domain
S3
Switching Sub-domain
C2 C3 SR3 SR1 Special Resource Sub-domain
SR2 Special Resource Sub-domain
Special Resource Domain Figure 4 - Domains and Sub-Domains Note that a function may provide a view to an application that includes not only the objects within its sub-domain, but also the objects it can view in another (presumably related) sub-domain. For example (in figure 4), a computing subdomain {C1} may receive a view of a switching sub-domain from a switching sub-domain {S2+S3}. That switching sub-domain may receive a view of a special resource sub-domain from a special resource sub-domain {SR1}, and relay that view, in addition to the view of its sub-domain, to the Computing Function. This relay may preserve two views of separate switching and special resource sub-domains, or it may provide a combined view of a switching/specialresource sub-domain. As shown in the figure, {C1} also may have its own, direct view of a special resource subdomain {SR2+SR3}. Finally, {C2+C3} represent a computing sub-domain that is potentially, but not yet, involved in CSTA transactions with other sub-domains because an association has not yet been established between any other subdomain and {C2+C3}.
- 11 -
6.1
Switching sub-domain model The tools needed to provide an abstract view of the Switching Function are defined by the switching sub-domain model. This model allows an application to conceptualize the Switching Function’s operation. To provide this abstract view, CSTA defines several CSTA switching sub-domain model Objects that can be observed and acted upon by the Switching Function on behalf of the Computing Function. Those objects include Device, Call, and Connection.
6.1.1
Device CSTA enables manipulation and observation of devices that allow users to access telecommunications services. NOTE 1 It is not claimed that this Standard alone supports ISDN (or any other) devices because, for example, of the additional information required to support such devices in PTNs. CSTA only provides some information allowing selection among ISDN devices sharing the same directory number (bearer capability, subaddress, etc.). Another example, that applies generally to telecommunications networks (including ISDN and OSI), is specifying the originator for a call that is established via CSTA. With the current signalling support, each party in a call can act only as a called party because the “network” is acting to originate the call. This situation has implications for both the network-to-terminal signalling and any application-level signalling that is significant to the calling party (e.g. issuing A_Associate). Devices that are visible or controllable via CSTA are known as CSTA Devices. CSTA devices can be either physical devices (such as buttons, lines, trunks, and stations) or logical devices (such as groups of devices, pilot numbers, and automatic call distribution groups). Devices have attributes that allow CSTA to monitor and manipulate them. The CSTA attributes of any CSTA device shall be: 1. Device Type - differing types of device can be used for various purposes and can be manipulated and observed differently within CSTA. A CSTA Device shall be one of the following types: ACD - Automatic Call Distributor (ACD) is a mechanism that queues and distributes calls within a Switching Function. An ACD device (as opposed to ACD-group device) comprises only the distribution mechanism and not devices to which the mechanism can distribute calls. ACD group - Automatic Call Distributor (ACD) group is the mechanism that queues and distributes calls within a Switching Function as well as the devices to which that mechanism distributes calls. As an ACD group (as opposed to ACD), the device consists both of the distribution mechanism and the devices to which the mechanism can distribute calls. Button - is one instance of a call manipulation point at an individual station. Simple analogue stations often have no physical buttons but behave as if they had (at least) one. Some advanced stations can emulate several analogue stations and often represent those stations by buttons. In some situations it is desirable to identify a specific button on a multi-button station. Note that a station with several buttons could have (but need not have) the same telephone number assigned to multiple buttons. Button group - is two or more instances of a call manipulation point at an individual station. Conference Bridge - is a device that automatically provides a conferencing function among the calls present at the device. Line - is a communications interface to one or more stations. In some situations it may be impossible to identify individual stations that share a line and a single directory number. Line group - is a set of communications interfaces to one or more stations. Operator - is a device that is used to interact with a party to assist in call setup or to provide certain other telecommunications services. This device differs from other devices in that it is often involved in setting up other calls and is not usually part of the call after the call is connected. Operator group - two or more operators used interchangeably or addressed identically. Park - is a device that is used solely for parking calls. Note that calls also may be parked at other types of devices.
- 12 -
Station - is the traditional telephone device, either simple or “featured”. A featured station is a physical unit with one or more buttons and one or more lines. Station group - is two or more stations used interchangeably or addressed identically. Trunk - a device used to access other switching sub-domains. In order to manipulate and view calls that cross a CSTA switching sub-domain it may be desirable to address the point at which the call crosses the boundary. This point is generally a trunk or trunk group. A trunk is an individual circuit. Trunk group - a set of independent trunks. Often, many trunks provide connectivity to the same place. These trunks are frequently grouped together and are all accessed using the same identifier. In such a configuration the individual trunks are used interchangeably. Note that the set may consist of only a single member trunk. 2. Device Profile - differing types of device can be observed and manipulated differently within CSTA. These types have distinct Device Profiles corresponding to their capabilities and characteristics. CSTA represents these types by Device Class augmented with ISDN Setup information where appropriate. Device Class - a CSTA Device shall belong to at least one, and may belong to more than one, of the following classes: Data - devices in this class are used to make digital data calls (both circuit-switched and packet-switched). This class includes digital computer interfaces and G4 facsimile machines. Image - devices in this class are used to make digital data calls involving imaging, or high-speed, circuitswitched data in general. This class includes digital video telephones and CODECs. Other - a class comprising devices not in the Data, Image, Audio or Voice classes. Voice - devices in this class are used to make speech calls. This class includes standard telephones. Audio - 3.1 KHz audio. Devices in this class are used to make audio calls excluding speech calls. It includes G3 fax and facsimile machines. Additional ISDN type information such as the following also may be included to help distinguish devices: • Bearer Capability, • Subaddress (for both calling and called devices), • High Layer compatibility, • Low Layer compatibility. These information elements are defined in ISO/IEC 11572: 1993. 3. Device Identifier - each device that can be observed and/or manipulated must be referenced across the CSTA Service Boundary. To accomplish this, each CSTA device shall be identified using a CSTA Device Identifier. Device Identifiers may be static or dynamically-assigned. A static Device Identifier shall be stable over time. It shall remain constant and unique between calls, associations and within both the switching and computing sub-domains. An example of a static CSTA Device Identifier is an E.164 Directory Number. It may be useful for the Switching Function to convert a Device Identifier to another static form for use in service interactions. An example, it might be useful to transform a Public Directory Number into a Private Directory Number. This transformation allows service interactions to be independent of the identification mechanism and allows reduction in the amount of data exchanged. This shortened form of Device Identifier is known as a CSTA Short Form Device Identifier. A static CSTA Device Identifier may be used in conjunction with the CSTA Device Profile in order to distinguish among devices that share a Device Identifier. A dynamically-assigned Device Identifier is temporary (lasting for the duration of a call) and may be created at any appropriate time. Once a CSTA device has been included in a call, it may be desirable to continue to refer to the particular instance of the device associated with this call for manipulation or tracking. A static Device Identifier may not always be sufficient because it may not be available or because it is too long and cumbersome for efficient use. In these cases the Switching Function can dynamically assign a Device
- 13 -
Identifier as a device reference or handle for the duration of the call. Management of the dynamicallyassigned Device Identifier is discussed in 6.1.7, Management of dynamically-assigned Identifiers. 4. Device State - the set of Connection states that are associated directly with a particular device. Connection states are discussed further in 6.1.3, Connection. 6.1.2
Call Call behaviour, including establishment and release, can be observed and manipulated across the CSTA boundary. During some call phases (e.g. establishment and release) the call is not completely formed and there may be only a single device involved (for example, the device on whose behalf the call was initiated). In many operations, such as conference and transfer, one device in a call is replaced with another device or two calls are merged into a single call. The CSTA call attributes shall be: 1. Call Identifier - a Call Identifier is a handle or reference associated with a CSTA call whereby that call can be known to, and identified by, CSTA Switching, Computing and Special Resource Functions through the call’s life. A Call Identifier shall be allocated to each call by the Switching Function when the call first becomes visible across the CSTA Service Boundary. It may or may not be globally unique among all calls within a switching sub-domain, but it shall always be globally unique within the call and shall include all endpoints of the call. A Call Identifier can be assigned to a call before that call is fully established. For example, an incoming call may be assigned a Call Identifier when the called device is Alerting and before the call has been answered. A Call Identifier shall not only reference the entire call within the sub-domain but shall also reference the entire call outside the sub-domain (including all end points that are visible to CSTA.) A CSTA call can pass through various stages involving many and different devices before it finally terminates. Examples of CSTA Services that cause this are Transfer and Conference. During the operation of CSTA Services, or as a result of manual intervention, the Call Identifier may change, but the call shall continue as a CSTA object. Management of Call Identifiers is described in 6.1.7, Management of dynamically-assigned Identifiers. 2. Call state - the set of Connection states for those Connections comprising a call. Call state is returned by the Snapshot Device Service for devices that have calls. Connection states are further described in 6.1.3, Connection. Call states are described in more detail in 6.1.5, Call states. 3. CSTA Application Correlator - data provided by the Computing Function and associated with the call for its entire duration or until overwritten with new data. This data survives Conference and Transfer and can be provided on various events. An application may remove the Application Correlator Data by overwriting existing data with null data. If an existing call that has Application Correlator Data is Conferenced or Transferred with a consulting call that also contains Application Correlator Data, then the data from the consultation call shall be retained and overwrite the other data.
6.1.3
Connection A Connection is a relationship between a call and a CSTA device. Note that this definition of “Connection” differs from those used in other standards. This Connection relationship can be both observed and manipulated. In fact, observation and manipulation of these Connections make up many CSTA Services (e.g. Hold Call Service, Reconnect Call Service, and Clear Call Service). Connections are CSTA Objects that have the following attributes: 1. Connection Identifier – a tuple of the CSTA Call Identifier and CSTA Device Identifier. For a call, there are as many Connection Identifiers as there are associated devices, and for a device there are as many Connection Identifiers as there are associated calls. The CSTA Connection Identifier shall be unique within a sub-domain and within a single association. As provided by the Switching Function, the Connection Identifier includes both a Device Identifier and a Call Identifier. The Device Identifier within a Connection Identifier may be dynamically-assigned. As provided by the Computing Function to the Switching Function, a Connection Identifier shall include at least a Device Identifier. It may be rejected by the Switching Function if a Call Identifier is missing. If a Connection Identifier sent by the Computing Function includes only a Device Identifier, then that Device Identifier shall not be dynamically-assigned. These conditions ensure that it is possible to use only a Device Identifier (without a Call Identifier) to provide a Connection Identifier. Different associations may have distinct CSTA Connection Identifiers for the same Connection. The definitions of a Connection Identifier and those identifiers that it comprises (CSTA Call and Device Identifiers) restrict CSTA Computing Functions from fabricating Connection Identifier. The Computing
- 14 -
Function cannot use a Call Identifier until a Connection Identifier containing that Call Identifier has been received from the Switching Function. 2. Connection state - one of the CSTA states a Connection may have. Connection states may be reported by Snapshots on either calls or devices, and changes in Connection states may be reported as Event Reports by Monitors. A Connection state shall involve a single Call/Device relationship. A simplified Connection state model is shown in the following figure.
Null Initiated
Alerting
Queued
Failed
Connected
Hold
Figure 5 - Connection State Model The states (represented by circles) presented in figure 5 comprise the set of CSTA Connection states. State transition possibilities, represented by arrows, form the basis for providing Event Reports when such transitions occur. CSTA Connection states are not equivalent to ISDN access states. CSTA Connection states are derived from the state machine on only one side of an ISDN access. CSTA Connection states are defined as follows: Null - A state in which there is no relationship between a call and device. Initiated - A state in which a device is requesting service. Often this is referred to as the “dialling” state. Alerting - A state in which a device is alerting (e.g. ringing). This indicates an attempt to connect a call to a device. Connected - A state in which a device is actively participating in a call. This state includes logical participation in a call as well as physical participation (i.e. a Connected device cannot be on Hold). Hold - A state in which a device is inactively participating in a call. This state includes logical participation in a call while physical participation is suspended. Queued - A state in which call progression has been stalled. This state generally refers to two conditions but can refer to others. One condition is when a device is trying to establish a Connection with a call and this process stalls. The second condition is when a call tries to establish a Connection with a device and that process stalls. Failed - A state in which call progression has been aborted. This state generally results when a device tries to become Connected to a call or a call tries to become Connected to a device and the attempt fails. The Failed state can result from failure to connect the calling device and call, failure to connect the called device and call, failure to create the call, failure when the call ends, and other reasons. 6.1.4
Call Event Reports The reason for the Connection state model is to provide an abstract view of actual states and events that are communicated via underlying signalling systems. This abstract view is introduced to provide a language for describing CSTA Event Reports, states and Functional descriptions. Because of the topology of the Switching Function, the signals that report events and state changes have definite sources. Providing a telecommunications
- 15 -
object (the Connection) that can be associated with the source of these signals helps when explaining the meaning of events and the operation of CSTA (and other) telecommunications services. On a typical ISDN access to a network there exists a distributed state machine. One part of this distributed state machine resides in the ISDN device. Another part resides on the other side of the ISDN access. There is another similar distributed-state access machine that resides across the ISDN network at a similar device. Using this concept, a call can be modelled as a collection of Connection state machines communicating with one another using signalling. When this communication occurs, a CSTA Event Report can be generated. In the following figure, this concept of communication between two state machines is illustrated for the case of establishing a simple call. Additionally, on each side of the figure the ISDN call states are indicated. Time
Device D1
Call C1
Device D2
T1
Null
Null
No Event Report
Null
Null
T2
Setup
Initiated
Service Initiated
Null
Null
T3
Proceeding
Connected
Originated
Null
Null
T4
Delivered
Connected
Delivered
Alerting
Receive
T5
Connected
Connected
Established
Connected
Connected
ISDN Call State
CSTA Event CSTA Reports Connection States Figure 6 - Relationship of CSTA Call Event Reports
ISDN Call CSTA Connection State States
Notice in figure 6 that the CSTA Event Reports are based on signalling interactions of the Switching Function. Many Connection events are of interest to CSTA applications. Typically, however, a CSTA application is interested in atomic telecommunications activities and these often involve many simultaneous Connection events. Generally, telecommunications operations embody changes to many Connections. These events can be summarized in a single Event Report. For instance, the Transfer, Conference and Clear Call Services all make changes to multiple Connections but are each represented by single Event Reports. The Connection state changes associated with each CSTA Event Report are defined in this Standard. 6.1.5
Call states The state of a CSTA Call can be precisely expressed as the list of Connection states of all the devices involved in the call. This list is called the Compound Call State. The technique of listing the Connection states to describe the Call state can describe any call state that is possible in CSTA. However, most calls involve a small number of widely-recognized states. CSTA defines those states in terms of their set of Connection states, but communicates them as atomic Call states - not as a list. These widely-recognized states are called the Simple Call States. For calls with one known Connection state, the single Connection state shall be provided as a Call state. NOTE 2 Since Null can be a known Connection state, for a nascent call it is possible to have a CSTA Call state with only one non-Null Connection (see table 1). For calls with more than two non-Null Connection states, the list of Connection states is provided as the call’s state. CSTA simplifies Call states by relating them (at times) to particular devices. These relationships are described by differentiating the call’s Connection states. The Connection state associated with a particular device is called the local Connection state (for that device). Other Connection states are not differentiated from one another. Thus, CSTA Call state is defined for a device by the combination of Connection states as well as the order in which the
- 16 -
Connection states are combined. For example, the Alerting-Connected Call state is not the same as ConnectedAlerting. The first is defined as Received and the second is defined as Delivered. For calls with exactly two Connections, the CSTA Call state assigned to the combinations of Connection states are summarized in the following table. If there is no Simple Call state for a particular combination of Connection states, then a Compound state shall be provided as the Call state. For Compound Call states, the first Connection state in the list shall be the local Connection state. Table 1 - Definition of CSTA Simple Call states Local Other CSTA Simple Call Connection Connection state State State Alerting
Connected
Received
Alerting
Hold
Received-On Hold
Connected
Alerting
Delivered
Connected
Connected
Established
Connected
Failed
Failed
Connected
Hold
Established-On Hold
Connected
Null
Originated / Terminated
Connected
Queued
Queued
Failed
Null
Blocked
Hold
Alerting
Delivered-Held
Hold
Connected
Established-Held
Hold
Failed
Failed-Held
Hold
Queued
Queued-Held
Initiated
Null
Pending
Null
Null
Null
NOTE 3 The Originated / Terminated state may occur both during call set-up and when the call ends. When a far-end party drops from a two-party call and the near-end end-point is not returned immediately to idle, then the Originated / Terminated state is entered for call tear-down. It is also possible to enter a blocked state when a call ends. 6.1.6
Agent An Agent is a CSTA object that relates the activity of an ACD agent to an ACD device. CSTA Agents and their activities can be identified, observed and controlled using CSTA Services and Event Reports. CSTA Agent attributes shall be: 1. Agent Identifier - an Agent Identifier shall be allocated to each Agent by the Switching Function when each Agent first becomes visible across the CSTA Service Boundary. It may or may not be identical to the Device Identifier of the device used by the Agent. 2. Agent Password - an Agent password may be allocated to each Agent. The password authenticates the Agent to the CSTA Application and/or one or more of its component functions. Additional information on authentication is provided in clause 8, Security. 3. Agent state - a state that an Agent may take in relation to an ACD. An Agent state relates that Agent to its task of serving the queuing mechanism of a particular ACD. It is possible that an Agent has several states with
- 17 -
respect to different ACD devices. Alternatively, an Agent may use a single state to describe its relationship to all ACD devices. Agent states are reported in Agent Event Reports. A typical transition model for Agent states is presented in the following figure.
Agent Null
Agent Working After Call
Agent Not Ready
Agent Ready
Agent Busy
Figure 7 - Agent State Model In figure 7, the Agent states (circles) presented comprise the CSTA Agent state set. The transitions between states, represented by arrows, show typical states that may be entered from a given state. These transitions, when they occur, form the basis for providing Agent Event Reports. Agent Null - the state where an Agent is not logged-on to the ACD. Logging-on and Logging-off from an ACD shall cause the transitions to and from this state. Agent Not Ready - the state where an ACD Agent is logged-on to an ACD, but is not prepared to handle calls that the ACD distributes. While in this state an Agent may receive calls that are not handled by the ACD. Agent Ready - the state where an ACD Agent is logged-on to an ACD and is prepared and waiting to handle calls that the ACD distributes. Agent Busy - the state where a device, on behalf of an Agent, is involved with an existing ACD call at that device, even if that call is on hold at that device. Calls between agents, calls between supervisors and agents and private calls may not cause this transition. Agent Working After Call - the state where a device, on behalf of an Agent, is no longer involved with an ACD call. While in this state an Agent cannot receive further calls from the ACD but may be performing administrative duties (e.g. updating a business order form) for a previous call. 6.1.7
Management of dynamically-assigned Identifiers Management of dynamically-assigned Device Identifiers and Call Identifiers is provided through management of Connection Identifiers. This ensures that an identifier whose meaning is dependent on another identifier is always provided in the proper context (i.e. with the other identifier needed to resolve its meaning.) For example if a Call Identifier is given relative to a device, then giving the Connection identifier ensures that the Call Identifier is provided with its reference - the Device Identifier. Management of CSTA Connection Identifiers shall be provided as follows. Connection Identifiers shall be provided when either a new Call is created or a new device becomes involved in a call. When a call is made a Connection Identifier shall be provided. A Connection Identifier shall be provided in Event Reports that pertain to a call. When a device becomes involved in a call, the Connection Identifier shall be provided in the Event Reports that occur at that device.
- 18 -
If a call changes its Call Identifier when a Conference or Transfer occurs, Connection Identifiers shall be provided to link the old Call Identifier to the new Call Identifier. Similarly, if a Device Identifier is changed, new Connection Identifiers shall be provided for the devices in the call. Management of identifiers shall be provided via parameters included in Service acknowledgements and Event Reports. Identifiers shall cease to be valid when their context vanishes. If a call ends, its Call Identifier is no longer valid to refer to that call. Similarly, if a device is removed from service or from a call, its dynamically-assigned Device Identifier shall become invalid. Identifiers can be reused. Once an identifier has lost its context it may be re-used to identify another object. It is recommended that implementations not re-use identifiers immediately. Individual Call and Device Identifiers are not guaranteed to be globally unique. CSTA requires that the combination of Call and Device Identifier be globally unique within a CSTA switching sub-domain. To accomplish this, either the Call Identifier, or the Device Identifier (or both) shall be globally unique. In many cases the Connection Identifier requires both the Call and Device Identifiers to uniquely refer to Connections in a call.
6.2
Special Resource Functions Special Resource Functions (SRFs) are functions that are typically “added-on” to a Switching or Computing Function. They can be modelled as part of either one of the two other Functions or as something totally independent. Special Resource Functions may include various subclasses that are defined independently but share a similar relationship to the Switching and Computing Functions in the Functional Architecture and Operational Modelling. Typical SRF subclasses include Voice Units, some Conference Bridge Units, Facsimile Units and Video Units. The Voice Unit subclass is defined in this Standard.
6.2.1
Voice Unit A Voice Unit is a CSTA SRF and object that supports the transformation of voice between real-time and static representations (i.e. between calls and messages). Voice Units and their activities can be identified, observed and controlled using CSTA services and a state model. An example of a Voice Unit device is a Voice Mail system. CSTA Voice Unit attributes are: 1. Call - A Connection Identifier shall be used to indicate the call that the Voice Unit relates to a message. Typically the Voice Unit will record some portion of the call or play a message as some portion of a call. There are some Voice Unit Services (e.g. Delete message and Concatenate message) that deal with the control of messages and do not require an interaction with a call. 2. Message - a Message Identifier shall be used to allow manipulation of messages, many of which survive the life of multiple calls. 3. Voice Unit state - A state that a Voice Unit may take in relating a call with a message. A Voice Unit state relates a call to its message in terms of playing, recording, pausing, suspending, changing playback speed, etc. Voice Units may have several states concurrently with respect to different calls and messages. Voice Unit states shall be reported by Voice Unit Event Reports. A typical transition model for Voice Unit states is shown in the following figure.
- 19 -
Speed Volume
next message
Volume Level Speed
Level
Volume Level Speed
Stop
Record
Play Position
Set Speed
Speed Level Volume Suspend Play
Suspend Record Position
Set Speed
Position
Speed Level Volume Review depicts an event representing a characteristic change
Set Speed
Position
Speed Level Volume
Figure 8 - Voice Unit Operational Model In figure 8, the states (circles) presented comprise the CSTA Voice Unit state set. Arrows represent transitions between states and show the typical states that may be entered from a given state. These transitions form the basis for providing Voice Unit Event Reports when they occur. The circular transitions show the effects of the Reposition and Set Speed Services. The following states are defined: Stop - the state where a call and a message are not currently interacting. Play - the state where a message delivers its information to a call. Suspend Play - the state where a message that was in the Play state is temporarily suspended in its delivery. This state (rather than Stop) is entered when it is expected that the message will re-enter the Play state. Record - the state where a message is created from the information in a call. Suspend Record - the state where a message that was in the Record state is temporarily suspended from recording. This state (rather than Stop) is entered when it is expected that the message will re-enter the Record state. Review - the state where a message that was in the Suspend Record state delivers recorded information back to the call. This allows the information provider to examine information recorded so far.
- 20 -
7
Association Establishment This Standard is based upon the assumption that the Services defined here, and a protocol that supports these Services, operate within an application association as provided by ISO 8649 (ACSE). CSTA shall make use of a single application context name for all versions and variations of implementation of CSTA Services and protocol. To facilitate the exchange of version and implementation information, CSTA specifies that the following information shall be exchanged in the ACSE Association Information field at association time. CSTA Association Information shall provide the following parameter: 1. CSTA Version - shall indicate the versions that the implementation can support. If two interacting systems support more than one version, then the highest CSTA Version they both support shall be used for the association. CSTA Association Information also may provide the following parameters: 2. Functionality Required - shall indicate the CSTA Services and Event Reports that are required by the application providing this information. 3. Functionality Offered - shall indicate the CSTA Services and Event Reports that are offered by the application providing this information for its highest-supported CSTA Version.
- 21 -
8
Security Service A customized set of security services can be built to counter the threats identified in any particular environment. Particular CSTA environments may require special services to provide appropriate security. CSTA supports security mechanisms including access control and authentication. This mechanism defines parameters that may be used in providing security. NOTE 4 By providing a separate mechanism for security, CSTA allows the use of other security mechanisms, like SecureROSE. CSTA Security Service shall use one or more of the following parameters: 1. Message Sequence Number - shall be a sequential number that can be used to detect missing messages in a sequence and verify that their order has not been altered. 2. Time Stamp - shall be a Universal Time Coordinated value that can provide an indication of the “freshness” of a message. It can indicate that the received message is not a replay of another message from a previous association or from the current association after the sequence numbers have re-cycled. 3. Privilege Attribute Certificate (PAC) - this parameter shall contain one mandatory attribute: the Sender Identifier. The Sender Identifier can be used to make appropriate access control decisions or to carry out the current security policy. This PAC is the mechanism defined in ECMA-138 for exchanging security information among applications. 4. Seal - this parameter shall be computed (by a mechanism not defined in this Standard) using all other fields present as well as any other entered CSTA data provided in this message. It shall bind together all the fields so that the receiver can detect any tampering.
- 22 -
9
Generic Service requirements In each of the following Service clauses the first sub-clause following a Service heading, or Service Definition clause, is normative text describing the operational requirements for each CSTA Service. These clauses contain the definitions of CSTA Services. Services are defined for the CSTA Service Boundaries between the Computing Function, Switching Function and Special Resource Function. Services are defined in terms of what they accomplish (i.e. functionally), not how they should be implemented.
9.1
Service Request Service Request clauses are normative text describing the parameters and the optionality of the parameters associated with each Service Request. Each parameter is described in a numbered sub-clause, so individual parameters can be referenced by number. If more than one parameter is of the same type, then it shall be possible to distinguish among such parameters. Every Service Request shall allow inclusion of non-standardized, Private Data, that shall be informational in nature.
9.2
Service Response Service Response clauses are normative text for describing the parameters and the optionality of the parameters associated with each Service Response. Each parameter is described in a numbered sub-clause, so individual parameters can be referenced by number. If more than one parameter is of the same type, then it shall be possible to distinguish among such parameters. Every Service Response shall allow inclusion of non-standardized, or Private Data, that shall be informational in nature. CSTA employs a generic mechanism that is decoupled from the specifics of the switching activity. CSTA Service Response operations shall comply with the following points: 1. Appropriate Services shall provide an unconfirmed mode in which responses to correct requests are not returned. 2. Syntactical or other checks shall be performed by the server to validate the correctness of each Service Request before the server issues the response. Incorrect requests shall always result in an error response even in the unconfirmed mode. 3. If a response is sent before the requested Service action is complete (i.e. the response is a Service Request acknowledgement), Event Reporting may be used to keep track of the subsequent server activity. 4. The precise moment in relation to the switching activity at which a response is generated shall be implementation- and Service-dependent. For example, for the Hold Call Service: • Some implementations may generate the Service Response after validating the correctness of the request and when they initiate the requested Service. • Other implementations may delay the response until the Hold has completed (or is guaranteed to complete). In this case, a failure of the requested switching Service is reflected in the Service Response. • Regardless of implementation, when an operation succeeds, an Event Report, in addition to the Service Response, shall be generated if monitoring for this operation has been established. A Held Event Report (if selected) shall always be reported in addition to the successful Service Request response (even for implementations that delay the response until the Hold operation is complete). In a given context, and with appropriate monitoring in place, an operation shall generate the same Event Reports whether it was invoked manually or by CSTA Service Requests from the Computing Function. If a Service Request is rejected, the server shall send diagnostic information indicating the reason for the rejection. In some cases, only a general error indication is supplied. If the requested Service fails, the client cannot assume that the pre-request states of CSTA objects have been maintained.
9.3
Functional description Functional description sub-clauses are informative (not normative) text. It is possible that many unique but similar operations meet the requirements to provide a particular CSTA Service. For many Services covered in the following sub-clauses, a pictorial example of conditions before and after a successful Service Request is provided. Event Report Service pictorials illustrate conditions before and after the change reported by the Event Report. All these figures illustrate only examples and are intended for clarification, and not to constrain implementations. The intent and use of these pictorials may be better understood with reference to the following example and keys:
- 23 -
D1
c
C1
* D2
D1
h
Before
C1
* D2
After
Figure 9 - Example illustration for Service and Event Report descriptions The figures illustrate conditions Before and After a successful Service or Event Report. In all such figures: • boxes represent devices • circles represent calls • lines represent CSTA Connections between a call and a device • absence of a line is equivalent to a CSTA Connection in the Null state • labels in boxes and circles denote device and call instances, respectively • labels on lines denote Connection states according to the following key: a c f h i q a/h
*
= = = = = = = =
Alerting Connected Failed Hold Initiated Queued Alerting or Hold (other combinations work similarly) undefined
• grey boxes denote devices or calls that are unaffected by the Service/Event Report • white boxes and circles denote devices and calls that are affected by the Service/Event Report
9.4
Diagnostic error definitions Error values available to return in response to a Service Request shall be those defined in this sub-clause. The definitions apply equally to Services requested by a CSTA Computing Function and to those requested by a CSTA Switching Function. An error value indicates the server’s best evaluation of the condition that caused the server to send a negative response to the Service Request. Each Error value shall comprise a mandatory error category indicator and an optional, specific error value. Errors are grouped into the following categories: 1. Operation Errors 2. Security Errors 3. State Incompatibility Errors 4. System Resource Availability Errors 5. Subscribed Resource Availability Errors 6. Performance Management Errors 7. Private Data Information Errors 8. Unspecified Errors
9.4.1
Operation errors Error values in this category shall indicate an error in the Service Request. Each error value shall have the meaning ascribed to it in the following list. This category shall include at least one of the following specific error values: 1. Generic Operation Error. The server has detected an error in the operation class, but it is not one of the defined errors, or the server cannot be any more specific. 2. Request Incompatible With Object. The Request is not compatible with the object.
- 24 -
3. Value Out Of Range. A parameter has a value that is not in the range defined for the server. 4. Object Not Known. A parameter has a value that is not known to the server. 5. Invalid Calling Device. The calling device is not valid. 6. Invalid Called Device. The called device is not valid. 7. Privilege Violation on Specified Device. The specified device is not authorized for the requested Service. 8. Invalid Forwarding Destination. The forwarding destination device is not valid. 9. Privilege Violation On Called Device. The called device is not authorized for the Service. 10. Privilege Violation On Calling Device. The calling device is not authorized for the Service. 11. Invalid CSTA Call Identifier. The Call Identifier is not valid. 12. Invalid CSTA Device Identifier. The Device Identifier is not valid. 13. Invalid CSTA Connection Identifier. The Connection Identifier is not valid. 14. Invalid Destination. The Service Request specified a destination that is not valid. 15. Invalid Feature. The Service Request specified a feature that is not valid. 16. Invalid Allocation State. The Service Request specified an allocation condition that was not valid. 17. Invalid CSTA Cross Reference Identifier. The Service Request specified a Cross Reference Identifier that is not in use at the time. 18. Invalid Object Type. The Service Request specified an object type that is outside the range of valid object types for the Service. 19. Security Violation. The requested Service would violate a security requirement. 20. Invalid CSTA Application Correlator Data. The Application Correlator Data parameter is not valid. 21. Invalid Account Code. The account code parameter is not valid. 22. Invalid Authorization Code. The authorization code parameter is not valid. 23. Request Incompatible with Calling Device. The requested Service is not compatible with the calling device. 24. Request Incompatible with Called Device. The requested Service is not compatible with the called device. 25. Invalid Message Identifier. There is no message with the specified Message Identifier. 26. Message Identifier Required. The request requires a Message Identifier. 27. Media Incompatible. The media type associated with the message is incompatible with the associated device. 28. File Not Found. The specified file is not accessible. 9.4.2
Security errors Error values in this category shall indicate a security error. Each error value shall have the meaning ascribed to it in the following list. This category shall include at least one of the following specific error values: 1. Generic Security Error. This is a general-purpose value that can be used when the server is unable to be any more specific about the cause of the error. 2. Sequence Number Error. Indicates that the server has detected an error in the operation’s Sequence Number. 3. Time Stamp Error. Indicates that the server has detected an error in the operation’s Time Stamp. 4. PAC Error. Indicates that the server has detected an error in the operation’s PAC. 5. Seal Error. Indicates that the server has detected an error in the operation’s Seal.
- 25 -
9.4.3
State incompatibility errors Error values in this category shall indicate that the Service Request was not compatible with the condition of a related CSTA object. Each error value shall have the meaning ascribed to it in the following list. This category shall include at least one of the following specific error values: 1. Generic State Incompatibility Error. This is a general-purpose value that can be used when the server is unable to be any more specific about the cause of the error. 2. Incorrect Object State. The object is in the incorrect state for the Service. This error value may be used when the server cannot be any more specific. 3. Invalid CSTA Connection Identifier For Active Call. The Connection Identifier specified in the Active Call parameter of the request was not in the correct state. 4. No Active Call. The requested Service operates on an active call, but there was no active call. 5. No Held Call. The requested Service operates on a held call, but the specified call was not in the Hold state. 6. No Call To Clear. There was no call associated with the Connection Identifier of the Clear Call request. 7. No Connection To Clear. There was no Connection for the Connection Identifier specified as Connection To Be Cleared. 8. No Call To Answer. There was no call active for the Connection Identifier specified as Call To Be Answered. 9. No Call To Complete. There was no call active for the Connection Identifier specified as Call To Be Completed. 10. Not Able to Play. The specified message exists, but cannot be played. 11. Not Able to Resume. The specified message cannot be resumed. 12. End of Message. The message pointer is at the end of the message. 13. Beginning of Message. The message pointer is at the beginning of the message. 14. Message Suspended. The specified message is already suspended on the same Connection.
9.4.4
System resource availability errors Error values in this category shall indicate that the Service Request could not be fulfilled because of a lack of system resources within the serving sub-domain. Each error value shall have the meaning ascribed to it in the following list. This category shall include at least one of the following specific error values: 1. Generic System Resource Availability Error. This is a general-purpose value that can be used when the server is unable to be any more specific about the cause of the error. 2. Service Busy. The Service is supported by the server, but was temporarily unavailable. 3. Resource Busy. An internal resource is busy and temporarily unavailable. 4. Resource Out Of Service. The Service requires a resource that is Out Of Service. A Service Request that encounters this condition could initiate system problem determination actions (e.g. notification of the network administrator). 5. Network Busy. The server sub-domain is busy. 6. Network Out Of Service. The server sub-domain is Out Of Service. 7. Overall Monitor Limit Exceeded. The requested Service would exceed the server’s overall limit of monitors. 8. Conference Member Limit Exceeded. The requested Service would exceed the server’s limit on the number of members of a conference.
9.4.5
Subscribed resource availability errors Error values in this category shall indicate that the Service Request could not be fulfilled because a required resource must be purchased or contracted by the client system. Each error value shall have the meaning ascribed to it in the following list. This category shall include at least one of the following specific error values:
- 26 -
1. Generic Subscribed Resource Availability Error. This is a general-purpose value to be used when the server is unable to be any more specific about the cause of the error. 2. Object Monitor Limit Exceeded. The requested Service would exceed the server’s limit of monitors for the specified object. 3. Trunk Limit Exceeded. The requested Service would exceed the server’s limit of trunks. 4. Outstanding Requests Limit Exceeded. The limit of outstanding requests would be exceeded by this request. 9.4.6
Performance management errors Error values in this category shall indicate that an error has been returned as a performance management mechanism. Each error value shall have the meaning ascribed to it in the following list. This category shall include at least one of the following specific error values: 1. Generic Performance Management Error. This is a general-purpose value to be used when the server is unable to be any more specific about the cause of the error. 2. Performance Limit Exceeded. A performance limit has been exceeded.
9.4.7
CSTA private data information errors Error values in this category shall indicate an error in the CSTA Private Data Information of the Service Request. The reason(s) why the Private Data Information is incorrect is not relevant to this Standard. This category shall include the following specific error value: 1. CSTA Private Data Information Error.
9.4.8
Unspecified errors Error values in this category shall indicate that the error did not belong to any of the other error value categories. This category shall include the following error value: 1. Unspecified Error.
- 27 -
10
Switching Function Services
10.1
Alternate Call Service The Alternate Call Service shall provide the compound action of the Hold Call Service followed by Retrieve Call Service. It shall place an existing active call on hold and then retrieve a previously held call or connects an alerting call at the same device.
10.1.1
Service Request The Alternate Call Service Request shall include at least one of the following parameters and each parameter shall have the indicated meaning: 1. CSTA Connection Identifier - shall indicate the Connected or Alerting Connection to alternate. 2. CSTA Connection Identifier - shall indicate the Hold Connection to alternate. The request also may include one or more of the following parameters: 3. CSTA Private Data Information. 4. CSTA Security Service Information.
10.1.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.1.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.1.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.1.3
Functional description This Service causes the specified device’s held and active calls to be swapped. As shown in the figure below, the Alternate Call Service places the user’s active call to device D2 on hold and establishes or retrieves the call between device D1 and device D3 as the active call. Device D2 may be considered to be placed automatically on hold immediately prior to the retrieval/establishment of the held/active call to device D3. Operation of the Alternate Call Service is illustrated in the next figure.
c
D1
h
C1
* D2
C2
* D3
D1
Before
h
C1
* D2
c
C2
* D3
After Figure 10 - Alternate Call
- 28 -
10.2
Answer Call Service The Answer Call Service shall connect an alerting or queued call. The call must be associated with a device that can answer a call without physical manipulation by a user.
10.2.1
Service Request The Answer Call Service Request shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection to answer. The request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
10.2.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.2.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.2.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.2.3
Functional description The Answer Call Service operates on an incoming call that is alerting or queued at a device. In the following figure, the call, C1 is delivered to device D1. Answer Call is used, typically with telephones that have attached speakerphone units, to establish the call via hands-free operation.
D1
a
C1
* D2
D1
Before
c
C1 After
Figure 11 - Answer Call
* D2
- 29 -
10.3
Associate Data Service The Associate Data Service shall associate CSTA Application Correlator Data, Account Code and/or Authorization Code information with a specified call.
10.3.1
Service Request The Associate Data Service Request shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the call with which the data is to be associated. The request shall also include at least one of the following parameters: 2. Account Code Data - shall indicate the account code to associate with the call. 3. Authorization Code Data - shall indicate the authorization code to allow the call. 4. CSTA Application Correlator Data - shall contain information supplied by the Computing Function application. The request also may include one or more of the following parameters: 5. CSTA Private Data Information. 6. CSTA Security Service Information.
10.3.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.3.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.3.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.3.3
Functional description The Associate Data Service allows the Computing Function to associate call-specific data with a call. It does not affect the state or progress of the call for which it is invoked.
- 30 -
10.4
Call Completion Service The Call Completion Service shall invoke features that complete a call that may otherwise fail or terminate before being answered.
10.4.1
Service Request The Call Completion Service Request shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection Identifier of the caller. 2. Feature - shall identify the feature to invoke. Allowed features shall be: Camp On - shall queue the call for a device until that device is available. Call Back - shall request the called device to return the call when the device returns to idle. Intrude - shall add the call to an existing, active call at the called device. Call Back Message - shall leave a message for the called user to return the call. The request also may include one or more of the following parameters: 3. CSTA Private Data Information. 4. CSTA Security Service Information.
10.4.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.4.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.4.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.4.3
Functional description Generally, this Service is invoked when a call is set up and encounters a busy called device or no answer. Camp On allows queuing for availability. Usually, Camp On makes the call wait until the called party finishes a current call and any previously camped on calls. Call Back requests the called device to return the call when the called device returns to idle. Call Back is similar to Camp On, but with Call Back the call may be hung-up after the Service is invoked. The CSTA Switching Function calls both parties when the called device becomes free. Intrude allows a call to be added into an existing call at the called device. Call Back Message leaves a message for the called user to return the call to the caller when the called user is able to do so. Generic Call Completion Service operation is illustrated in the next figure. In this example, a call, C1, is initiated from device D1 calling device D2, which is busy. The attempt to connect to D2 therefore fails. Callback Call Completion Service (for instance) is then invoked on behalf of D1. When D2 later becomes idle, both D1 and D2 are alerted and when both are answered, a new call, C3, is established between D1 and D2.
- 31 -
D1
c
f
C1 Before
D2
D1
c
C3
c
D2
After
Figure 12 - Generic Call Completion Note that the configuration represented in the “After” diagram above represents the situation after the callback call has been successfully made and answered. Several intermediate, implementation-dependent conditions may exist before the “After” configuration is achieved.
- 32 -
10.5
Clear Call Service The Clear Call Service shall release all devices from a specified call and shall eliminate the call itself. The call shall cease to exist and all CSTA identifiers used for observation and manipulation of that call shall be released.
10.5.1
Service Request The Clear Call Service Request shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the call to clear. The request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
10.5.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.5.2.1
Positive acknowledgement Positive Acknowledgement to the Service Request shall indicate that all instances of the CSTA Connection Identifiers for all the endpoints in the call and in the current association have become invalid. The Connection Identifiers and their components associated with the just-cleared call can be reused for Services pertaining to other calls. However, these identifiers can not be used to request Services related to the just-cleared call. The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.5.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.5.3
Functional description Each device in the call is released and the CSTA Connection Identifiers (and their components) are freed. Operation of the Clear Call Service (CSTA Connection Identifier = C1,D1), where call C1 connects devices D1, D2 and D3, is illustrated in the next figure:
D1
*
C1
*
D2
*
D3
D1
Before
D2
D3 After
Figure 13 - Clear Call
- 33 -
10.6
Clear Connection Service The Clear Connection Service shall release a specified device from a designated call. The Connection shall be left in the Null state. Additionally, the CSTA Connection Identifier provided in the Service Request shall be released.
10.6.1
Service Request The Clear Connection Service Request shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection to clear. The request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
10.6.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.6.2.1
Positive acknowledgement Positive Acknowledgement of the Service Request shall indicate that the CSTA Connection Identifier for the cleared Connection has been released. The Connection Identifier shall not be used to request additional Services from the CSTA server until/unless it is re-allocated by the server. The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.6.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.6.3
Functional description This Service releases the specified Connection and CSTA Connection Identifier from the designated call. The result is as if the device had hung up on the call. Note that the phone might not be physically returned to on-hook and this might result in silence, dial tone, or some other condition. Generally, if only two Connections are in the call, the effect of Clear Connection is the same as that of Clear Call. The following figure illustrates the operation of Clear Connection (CSTA Connection Identifier = C1,D3), where call C1 connects devices D1, D2 and D3. Note that the entire call may not be cleared by this Service if it is some type of conference.
D1
*
C1
* D2
*
D1
*
C1
D3
Before
D3 After
Figure 14 - Clear Connection
* D2
- 34 -
10.7
Conference Call Service The Conference Call Service shall create a conference between an existing held call and another active call at a conferencing device. The two calls shall be merged into a single call and the two Connections at the conferencing device shall be resolved into a single Connection in the Connected state. The CSTA Connection Identifiers formerly associated with the conferenced Connections shall be released, and a new CSTA Connection Identifier for the resulting Connection shall be created.
10.7.1
Service Request The Conference Call Service Request shall include at least one of the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection of the held call to be conferenced. 2. CSTA Connection Identifier - shall indicate the Connection of the active call to be conferenced. The request also may include one or more of the following parameters: 3. CSTA Private Data Information. 4. CSTA Security Service Information.
10.7.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.7.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the resulting connection at the conferencing device. The positive acknowledgement also may provide one or more of the following three parameters for each party that is known to the CSTA sub-domain whose Connection Identifier changes as a result of the Conference Service: 2. CSTA Connection Identifier - shall indicate the party in the conference. 3. CSTA Device Identifier - shall provide the Device Identifier for this party in the conference, if that identifier is known. 4. CSTA Connection Identifier - shall indicate the previous Connection Identifier for this party in its original call. The positive acknowledgement also may include one or more of the following parameters: 5. CSTA Private Data Information. 6. CSTA Security Service Information.
10.7.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.7.3
Functional description The operation of Conference Service is illustrated in the next figure. The starting conditions are that a call C1 from D1 to D2 is in the Hold state and a call C2 from D1 to D3 is in progress.
- 35 -
D1
h
C1
* D2
c
C2
* D3
D1
Before
* D2 c
C3
* D3
After Figure 15 - Conference Call
D1, D2 and D3 are then conferenced together into a single call, C3. The value of the Connection Identifier (D1,C3) may be that of one of the CSTA Connection Identifiers provided in the Conference Service Request (D1,C1 or D1,C2). The Conference Service can be repeated to make n-party conference calls.
- 36 -
10.8
Consultation Call Service Consultation Call Service shall provide the compound action of the Hold Call Service followed by Make Call Service. This Service shall place an existing active call at a device on hold and initiate a new call from the same device.
10.8.1
Service Request The Consultation Call Service Request shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the existing Connected Connection to be held. 2. CSTA Device Identifier - shall indicate the device to be consulted. The request also may include one or more of the following parameters: 3. Device Profile - shall indicate the Device Profile associated with the device to be consulted. 4. Account Code Data - shall indicate the account code to associate with the call. 5. Authorization Code Data - shall indicate the authorization code to allow the call. 6. CSTA Application Correlator Data - shall contain information supplied by the Computing Function application. 7. CSTA Private Data Information. 8. CSTA Security Service Information.
10.8.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.8.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the initial Connection to the new call. The positive acknowledgement also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
10.8.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.8.3
Functional description Operation of Consultation Call Service is illustrated in the following figure:
D1
c
C1
*
D2
D1
h
C1
* D2
c
C2
* D3
Before
After Figure 16 - Consultation Call
- 37 -
10.9
Divert Call Service The Divert Call Service shall move a call from one device to another device.
10.9.1
Service Request The Divert Call Service Request shall include the following parameter: 1. Diversion type - shall indicate the type of diversion requested. This parameter shall have one of the following values: Deflection - shall mean that a Connection shall be diverted away from a device to a destination that is inside or outside the switching sub-domain. Directed pickup - shall mean that a Connection shall be diverted to a new destination that is inside the switching sub-domain. Group pickup - shall mean that a Connection should be diverted to a member of a pickup group. If the Diversion type parameter specifies Deflection or Directed pickup, then the Service Request shall include the following parameter (CSTA Connection Identifier). If the Diversion type parameter specifies Group pickup, then the Service Request shall not include the following CSTA Connection Identifier parameter: 2. CSTA Connection Identifier - shall indicate the call to divert. 3. CSTA Device Identifier - shall indicate the device to which the call is to be diverted. The request also may include one or more of the following parameters: 4. Device Profile - shall specify the Device Profile of the device to which the call is to be diverted. 5. CSTA Application Correlator Data - shall contain information supplied by the Computing Function application. 6. CSTA Private Data Information. 7. CSTA Security Service Information.
10.9.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.9.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.9.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
- 38 -
10.9.3
Functional description The Divert Call Service replaces the originally called device, specified in the CSTA Connection Identifier, with a different called device, specified by a CSTA Device Identifier. The Divert Call Service supports at least three common call diversion functions: • Deflection - Takes a call (typically alerting or queued) at a device and sends it to a new destination. When using Divert Call to perform a deflection, the CSTA Connection Identifier must be included. • Pickup - Takes a call (typically alerting or queued) at another destination and brings it to a device. When using Divert Call to perform a pickup, the CSTA Connection Identifier must be included. • Group Pickup - Takes a call (typically alerting or queued) at one or more predetermined destinations and brings it to a device. When using Divert Call to perform a group pickup, the CSTA Connection Identifier is not included.
D1
*
C1
D3
* D2
D1
D3 Before
C1
* After
Figure 17 - Divert Call
* D2
- 39 -
10.10
Hold Call Service The Hold Call Service shall place an existing Connection into the Hold state.
10.10.1
Service Request The Hold Call Service Request shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection to hold. The request also may include one or more of the following parameters: 2. Connection Reservation - shall reserve the facility for reuse by the held call. This option is not appropriate for most non-ISDN telephones. The default shall be no connection reservation. 3. CSTA Private Data Information. 4. CSTA Security Service Information.
10.10.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.10.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.10.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.10.3
Functional description This Service interrupts communications for an existing call at a device and places that call on hold. The associated connection is made available for other uses, depending on the reservation option. Hold Call Service is illustrated in the following figure. Hold Call Service is invoked for device D1 in call C1. Call C1 is then placed on hold. Hold Call maintains the relationship between the holding device and the held call until the call is retrieved from the Hold state or the call is cleared.
D1
c
C1
* D2
D1
Before
h
C1 After
Figure 18 - Hold Call
* D2
- 40 -
10.11
Make Call Service The Make Call Service shall originate a CSTA call between two devices. The Service shall create a new call and establish a Connected Connection with the originating device. The Make Call Service also shall provide a CSTA Connection Identifier that indicates the Connection of the originating device.
10.11.1
Service Request The Make Call Service Request shall include the following parameters: 1. CSTA Device Identifier - shall indicate the device from which the call originates. 2. CSTA Device Identifier - shall indicate the device to which the call should be directed. The request also may include one or more of the following parameters: 3. Device Profile - shall indicate the Device Profile associated with the call. 4. Account Code Data - shall indicate the account code to associate with the call. 5. Authorization Code Data - shall indicate the authorization code to allow the call. 6. CSTA Application Correlator Data - shall contain information supplied by the Computing Function application. 7. CSTA Private Data Information. 8. CSTA Security Service Information.
10.11.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.11.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection between the originator and the call. The positive acknowledgement also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
10.11.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
- 41 -
10.11.3
Functional description This Service originates a new call from one CSTA device to another. When the Service is initiated the calling device is prompted (if necessary) and when that device acknowledges, a call to the called device is originated. Make Call operation (Calling device = D1, Called device = D2) is illustrated in the next figure. A call is established as if D1 had called D2 manually. A Connection Identifier for the new Connection (C1,D1) is returned to the client when the allocation condition specified in the Service Request has been satisfied.
D1
* C1 * D2 Before
D1
c
C1
* D2
After
Figure 19 - Make Call After call origination has started, call progress Event Reports selected by the client via the Monitor Start Service may be sent by the server application as connection establishment progresses. The call is not guaranteed to succeed after acknowledgement has been received. For example, there is no assurance that D2 will be answered after it has begun to be alerted or that D2 will not be busy with another call and able to accept the call from D1.
- 42 -
10.12
Make Predictive Call Service The Make Predictive Call Service shall originate a CSTA call between two devices. The Service shall create a new call and establish a Connection with the called device. The Make Predictive Call Service also shall provide a CSTA Connection Identifier that indicates the Connection of the called device.
10.12.1
Service Request The Make Predictive Call Service Request shall include the following parameters: 1. CSTA Device Identifier - shall indicate the device on behalf of which the call is originated. 2. CSTA Device Identifier - shall indicate the device to which the call should be directed. The request also may include one or more of the following parameters: 3. Allocation - shall specify the condition(s) in which the call attempts to connect to the calling device. If absent, Call Delivered shall be the default. This parameter shall have one of the following values: Call Delivered - shall specify that the call will attempt to connect to the calling device if Alerting or Connected is determined at the called device. Call Established - shall specify that the call will attempt to connect to the calling device only if Connected is determined at the called device. 4. Device Profile - shall indicate the Device Profile associated with the call. 5. Account Code Data - shall indicate the account code to associate with the call. 6. Authorization Code Data - shall indicate the authorization code to allow the call. 7. CSTA Application Correlator Data - shall contain information supplied by the Computing Function application. 8. CSTA Private Data Information. 9. CSTA Security Service Information.
10.12.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.12.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection between the called device and the call. The positive acknowledgement also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
10.12.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.12.3
Functional description This Service is often used when calls are made from a group of devices (or a logical device). This Service allocates calls to particular devices within that group at some time during the progress of the call. The Service first initiates a call to the called device. Depending on the call’s progress, the call may be connected with an “originating” device during the progress of the call. The point at which the call attempts to connect to the originating device is determined by the allocation parameter. If the allocation parameter is set to Call Delivered, then the call is allocated upon detection of an Alerting or Connected state at the called device. If the allocation parameter is set to Call Established, the call is allocated upon detection of a Connected state at the called device.
- 43 -
The typical use of this Service is to place calls out of a CSTA sub-domain. The CSTA Connection Identifier provided by this Service may apply to an outbound trunk (rather than the terminating, called device). The result of Make Predictive Call (Calling device = group device D1, Called device = D2) is illustrated in the following figure:
D1
D2
D1
Before
C1 a/c D2 After
Figure 20 - Make Predictive Call
- 44 -
10.13
Park Call Service The Park Call Service shall move a Connected call at one device to another (parked-to) device. The device on whose behalf Park Call was invoked (the Parking device) is no longer associated with the call.
10.13.1
Service Request The Park Call Service Request shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the existing Connected Connection of the Parking device. 2. CSTA Device Identifier - shall indicate the device (i.e. the Parked-to device) at which the call should be parked. The request also may include one or more of the following parameters: 3. Device Profile - specifies the Device Profile for the "Parked-to" device. 4. CSTA Application Correlator Data - shall contain information supplied by the Computing Function application. 5. CSTA Private Data Information. 6. CSTA Security Service Information.
10.13.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.13.2.1
Positive acknowledgement The positive acknowledgement also may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.13.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.13.3
Functional description As shown in the following figure, when Park Call Service is invoked for device D1 in call C1, the call C1 becomes queued at device D3. Device D1 is no longer associated with call C1.
D1
c
C1 c
D3
D2
D1
D3 Before
C1
q After
Figure 21 - Park Call
c
D2
- 45 -
10.14
Query Device Service The Query Device Service shall provide indication of the state of device features or static attributes.
10.14.1
Service Request The Query Device Service Request shall include the following parameters: 1. CSTA Device Identifier - shall indicate the device to query. 2. Feature - shall indicate the requested information and shall consist of exactly one of the following: a. Message Waiting - shall indicate available waiting messages. b. Do Not Disturb - shall indicate whether the device is in the Do Not Disturb state. c. Forward - shall indicate whether the device is forwarding calls and, if so, what type of forwarding is in place and the number forwarded to. d. Device Information - shall indicate the class and type of device and, optionally, a Short Form Device Identifier for the device. e. Agent State - shall indicate ACD agent state. f. Routing Enabled - shall indicate that the device may make route requests of the Computing Function. g. Auto Answer - shall indicate the auto-answer status of the device. h. Microphone Mute - shall indicate whether the device’s microphone is Off (i.e. muted) or On. i. Speaker Mute - shall indicate whether the device’s speaker is Off (i.e. muted) or On. j. Speaker Volume - shall indicate the current volume setting of the device. The request also may include one or more of the following parameters: 3. CSTA Private Data Information. 4. CSTA Security Service Information.
10.14.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.14.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameter: 1. Feature - shall provide the requested information and shall consist of the same lettered item as was indicated in the Service Request: a. On/Off - shall indicate available waiting messages. b. On/Off - shall indicate whether the device is in the Do Not Disturb state. c. Type of Forwarding - shall indicate each of the following that are on, and may return others of these that are off as well: Immediate - Forwarding all calls. If provided then the response shall also include: On/Off - shall indicate whether the device is forwarding calls. Device Identifier - shall indicate the device to which calls are forwarded. Busy - Forwarding when busy. If provided then the response shall also include: On/Off - shall indicate whether the device is forwarding calls. Device Identifier - shall indicate the device to which calls are forwarded. No Answer - Forwarding after no answer. If provided then the response shall also include: On/Off - shall indicate whether the device is forwarding calls.
- 46 -
Device Identifier - shall indicate the device to which calls are forwarded. Immediate Internal - Forwarding all internal calls. If provided then the response shall also include: On/Off - shall indicate whether the device is forwarding calls. Device Identifier - shall indicate the device to which calls are forwarded. Immediate External - Forwarding all external calls. If provided then the response shall also include: On/Off - shall indicate whether the device is forwarding calls. Device Identifier - shall indicate the device to which calls are forwarded. Busy Internal - Forwarding when busy for an internal call. If provided then the response shall also include: On/Off - shall indicate whether the device is forwarding calls. Device Identifier - shall indicate the device to which calls are forwarded. Busy External - Forwarding when busy for an external call. If provided then the response shall also include: On/Off - shall indicate whether the device is forwarding calls. Device Identifier - shall indicate the device to which calls are forwarded. No Answer Internal - Forwarding after no answer for an internal call. If provided then the response shall also include: On/Off - shall indicate whether the device is forwarding calls. Device Identifier - shall indicate the device to which calls are forwarded. No Answer External - Forwarding after no answer for an external call. If provided then the response shall also include: On/Off - shall indicate whether the device is forwarding calls. Device Identifier - shall indicate the device to which calls are forwarded. d. Device Information - shall indicate device class and type. It also may indicate a Short Form Device Identifier for the device. The class specification information shall include one or more of the following attributes: Voice, Data, Image, Audio, Other. The type specification information shall include one or more of the following: station, line, button, ACD, trunk, operator, other, station group, line group, button group, ACD group, trunk group, operator group, other group, conference bridge, park device. e. Agent State - shall indicate ACD agent state. The state shall be one of the following values (which have been previously defined in conjunction with the Agent State model in 6.1.6, Agent): Agent Null Agent Not Ready Agent Ready Agent Busy Agent Working After Call f. Routing Enabled - shall indicate whether the device may make route requests of the Computing Function. g. On/Off - shall indicate whether Auto-answer is On or Off. h. On/Off - shall indicate whether the device’s microphone is On or Off (i.e. muted). i. On/Off - shall indicate whether the device’s speaker is On or Off (i.e. muted).
- 47 -
j. Speaker Volume - shall indicate the current volume setting of the device. The value shall be an integer in the range 0 to 100. The positive acknowledgement also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information. 10.14.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
- 48 -
10.15
Reconnect Call Service The Reconnect Call Service shall provide the compound action of the Clear Connection Service followed by the Retrieve Call Service. It shall clear an existing Connection and then retrieve a previously held Connection at the same device.
10.15.1
Service Request The Reconnect Call Service Request shall include at least one of the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection to be cleared. 2. CSTA Connection Identifier - shall indicate the Connection to be retrieved. The Service Request also may include one or more of the following parameters: 3. CSTA Private Data Information. 4. CSTA Security Service Information.
10.15.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.15.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.15.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.15.3
Functional description Reconnect Call Service causes an existing, Connected Connection to be dropped. Having dropped the call, the specified held call is retrieved and becomes active. This Service is commonly used to drop an active call and return to a held call. However, it can also be used to cancel a consultation call (because of no answer, called device busy, etc.) and then return to a held call.
D1
h
C1
* D2
c
C2
* D3
D1
Before
c
C1
*
C2
* D3
After Figure 22 - Reconnect Call
D2
- 49 -
10.16
Retrieve Call Service The Retrieve Call Service shall connect an existing Hold Connection.
10.16.1
Service Request The Retrieve Call Service Request shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection to be retrieved. The request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
10.16.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.16.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.16.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.16.3
Functional description The indicated Connection is restored to the Connected state. The call’s state may change due to actions by farend endpoints. If the Hold Call Service reserved the Hold Connection and the Retrieve Call Service is requested for the same call, then the Retrieve Call Service uses the reserved Connection.
D1
h
C1
* D2
D1
Before
c
C1 After
Figure 23 - Retrieve Call
* D2
- 50 -
10.17
Send DTMF Tones Service The Send DTMF Tones Service shall place DTMF Tones on behalf of a Connection in a call.
10.17.1
Service Request The request for Send DTMF Tones Service shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection on which the DTMF signals are to be sent. 2. Character String to Send - shall indicate a string of characters to be sent, encoded in DTMF format, by the Switching Function on a specified connection. All characters from the set {1234567890#*} shall be encoded as DTMF tones. Additionally, characters from the set {ABCD} may be encoded as DTMF tones, and the request string may contain other additional characters as well. Handling of any of the additional characters is Switching Function dependent. The request also may include one or more of the following parameters: 3. Tone Duration - shall indicate the duration, in milliseconds, of the tones to be provided. 4. Pause Duration - shall indicate the duration, in milliseconds, of the silences between tones to be provided. 5. CSTA Private Data Information. 6. CSTA Security Service Information.
10.17.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.17.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.17.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
10.17.3
Functional description This Service causes a series of DTMF tones, corresponding to (certain) IA5 characters in a specified string, to be sent by the switch on a specified call. Only characters that can be encoded as DTMF tones can be sent as DTMF tones by the Switching Function. However, other valid characters contained in the Characters to Send parameter are either ignored or may be used by the Switching Function to control the sending of DTMF tones. For example, a “,” character may cause the Switching Function to insert a pre-defined pause between successive DTMF tones. However, any such significance attached to characters in the supplementary set of characters is entirely switchdependent and not covered by this Service definition. This Service definition also supports optional parameters to control tone cadence. If these are not present or cannot be met, the switch may use its default cadences associated with each device over which the tones are sent.
- 51 -
10.18
Set Feature Service The Set Feature Service shall set features at a device. It does not set system features or allow administration.
10.18.1
Service Request The Set Feature Service Request shall include the following parameters: 1. Device Identifier - shall indicate the device on which to set the feature. 2. Feature - shall indicate the requested feature to set. This parameter shall have one of the following values: a. Message Waiting - shall set messages available. If this parameter is chosen, the following additional parameter shall be included: 3. On/Off - shall indicate whether to turn on or off. b. Do Not Disturb - shall set Do Not Disturb. If this parameter is chosen, the following additional parameter shall be included: 4. On/Off - shall indicate whether to turn on or off. c. Forward - sets forwarding calls. If this parameter is chosen, the following additional parameters (5. and 6.) shall be included: 5. Type of Forwarding - the value shall be one of the following with meaning as indicated: Immediate - Forwarding all calls, Busy - Forwarding when busy, No Answer - Forwarding after no answer, Immediate Internal - Forwarding all internal calls, Immediate External - Forwarding all external calls, Busy Internal - Forwarding when busy for an internal call, Busy External - Forwarding when busy for an external call, No Answer Internal - Forwarding after no answer for an internal call, No Answer External - Forwarding after no answer for an external call. For each forwarding type, the value shall indicate whether to turn forwarding “on” or “off”. If ”on” then the following parameter may be included: 6. Device Identifier - shall indicate the device to which calls are forwarded. d. Agent Parameter - the ACD Agent State shall result from this parameter. This parameter shall have one of the following values: Agent Working After Call. Agent Ready. Agent Logged On. If this value is specified, then the request also may include one or more of the following parameters: 7. String - shall specify a password or authorization code. 8. Agent Identifier - shall specify the Agent Identifier. 9. Device Identifier - shall specify the ACD pilot or group into which the agent is logging on. Agent Logged Off. If this value is specified, then the request also may include one or more of the following parameters: 10. String - shall specify a password or authorization code. 11. Agent Identifier - shall specify the Agent Identifier. 12. Device Identifier - shall specify the ACD pilot or group from which the agent is logging out.
- 52 -
Agent Not Ready. e. Enable Routing - shall indicate whether route requests should be made from the device. If this value is chosen, then the following additional parameter shall be included: 13. This parameter shall indicate routeing enabled or disabled. NOTE 5 Route requests may be made by the Switching Function without the involvement of a particular device. Additionally, the device may request routes with a call in any state - including Null. f. Auto Answer - shall set whether a call arriving at a device should be answered automatically. If this value parameter is chosen, then the following additional parameter shall be included: 14. This parameter shall indicate enabled or disabled. g. Microphone Mute - shall set the device’s microphone to Off (i.e. muted) or On. If this parameter is chosen, the following additional parameter shall be included: 15. On/Off - shall indicate whether to set the microphone on or off. h. Speaker Mute - shall set the device’s speaker to Off (i.e. muted) or On. If this parameter is chosen, the following additional parameter shall be included: 16. On/Off - shall indicate whether to set the speaker on or off. i. Speaker Volume - shall set the device’s volume level. 17. Speaker Volume - shall indicate the volume level to set. Values may range from 0 to 100, with a value of 0 indicating silence and 100 indicating maximum volume. The granularity and accoustic loudness effect of this parameter shall be switch- and device-specific. The request also may include one or more of the following parameters: 18. Device Profile - shall indicate the Device Profile associated device / feature to set. 19. CSTA Private Data Information. 20. CSTA Security Service Information. 10.18.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.18.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
10.18.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
- 53 -
10.19
Single Step Conference Service The Single Step Conference Service shall join a device into an existing call. This Service shall create a Connected Connection between an existing call and a device.
10.19.1
Service Request The Single Step Conference Service Request shall include the following parameters: 1. CSTA Connection Identifier - shall indicate an existing Connection in the call into which a new device will be added. 2. CSTA Device Identifier - shall indicate the device to be added into the call. The Service Request also may include one or more of the following parameters: 3. Type of Operation - shall indicate Silent or Active participation of the conferenced device. 4. Device Profile - shall indicate the Device Profile associated with the added device. 5. Account Code Data - shall indicate the account code to associate with the resulting call. 6. Authorization Code Data - shall indicate the authorization code to allow the call. 7. CSTA Application Correlator Data - shall contain information supplied by the Computing Function application. 8. CSTA Private Data Information. 9. CSTA Security Service Information.
10.19.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.19.2.1
Positive acknowledgement The positive acknowledgement includes the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection of the device that was added to the call. The positive acknowledgement also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
10.19.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
- 54 -
10.19.3
Functional description Operation of the Single Step Conference Service is illustrated in the following figure. Devices D1 and D2 are both involved (in any state except NULL) with call C1. When Single Step Conference is invoked, device D3 is conferenced into call C1. Call C1 retains its identity in that a new Call Identifier is not created. However, a new Connection Identifier (D3,C1) is created. This operation differs from that of Conference Service in that call C1 need not be on hold at either D1 or D2 (although it is allowed to be on hold at either or both) before the conferencing action takes place. The Single Step Conference Service can be repeated to make n-party conference calls.
D1
* C1 * D2
D1
*
*
C1
D3 Before Figure 24 - Single Step Conference
c After
D2
D3
- 55 -
10.20
Single Step Transfer Call Service The Single Step Transfer Call Service shall replace a device with a Connected Connection with a new device that is not currently participating in the call. The device that has been replaced shall no longer be involved with the call.
10.20.1
Service Request The Single Step Transfer Call Service Request shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the existing Connected Connection to be replaced. 2. CSTA Device Identifier - shall indicate the new called (transferred-to) device. The request also may include one or more of the following parameters: 3. Device Profile - shall indicate the Device Profile associated with the new called (transferred-to) device. 4. Account Code Data - shall indicate the account code to associate with the call. 5. Authorization Code Data - shall indicate the authorization code to allow the call. 6. CSTA Application Correlator Data - shall contain information supplied by the Computing Function application. 7. CSTA Private Data Information. 8. CSTA Security Service Information.
10.20.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.20.2.1
Positive acknowledgement The positive acknowledgement may include the following parameter: 1. CSTA Connection Identifier - shall indicate a resulting Connection in the remaining call. The positive acknowledgement also may include one or more of the following three parameters for each party that is known to the CSTA sub-domain whose Connection Identifier changes as a result of the Single Step Transfer Call Service: 2. CSTA Connection Identifier - shall indicate the party in the resulting call. 3. CSTA Device Identifier - shall provide, if known, the static reference for the party in the resulting call. 4. CSTA Connection Identifier - shall indicate the previous identifier for the party in its original call. The positive acknowledgement also may include one or more of the following parameters: 5. CSTA Private Data Information. 6. CSTA Security Service Information.
10.20.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
- 56 -
10.20.3
Functional description Operation of the Single Step Transfer Call Service is illustrated in the next figure. The starting conditions are: a call C1 between D1 and D2 is in the Established state. This Service, if issued on behalf of D1, transfers the existing call, C1, to create a new call from device D2 to device D3. Device D1 is released from the call. Single Step Transfer differs from Transfer in that Transfer requires that a call explicitly be placed on hold at a device before it is transferred from that device.
D1
c
* D2
C1
D3 Before
D1
* C3 After
Figure 25 - Single Step Transfer Call
D2
* D3
- 57 -
10.21
Transfer Call Service The Transfer Call Service shall transfer a call held at a device to an active call at the same device. The held and active calls at a common device shall be merged into a new call. Also, the Connections of the held and active calls at the common device shall become Null and their CSTA Connections Identifiers shall be released.
10.21.1
Service Request The Transfer Call Service Request shall include at least one of the following parameters: 1. CSTA Connection Identifier - shall indicate the Hold Connection to transfer. 2. CSTA Connection Identifier - shall indicate the Connected Connection to which the held call should be transferred. The request also may include one or more of the following parameters: 3. CSTA Private Data Information. 4. CSTA Security Service Information.
10.21.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
10.21.2.1
Positive acknowledgement The positive acknowledgement may include the following parameter: 1. CSTA Connection Identifier - shall indicate a resulting Connection in the remaining call. The positive acknowledgement may include one or more of the following three parameters for each party that is known to the CSTA sub-domain whose Connection Identifier changes as a result of the Transfer Call Service: 2. CSTA Connection Identifier - shall indicate the party in the resulting call. 3. CSTA Device Identifier - shall provide, if known, the static reference for the party in the resulting call. 4. CSTA Connection Identifier - shall indicate the previous Connection Identifier for the party in its original call. The positive acknowledgement also may include one or more of the following parameters: 5. CSTA Private Data Information. 6. CSTA Security Service Information.
10.21.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
- 58 -
10.21.3
Functional description Operation of the Transfer Call Service is illustrated in the next figure. The starting conditions are: a call, C1, from D1 to D2 is in held state. A call, C2, from D1 to D3 is in progress. This Service transfers the held call, C1, between devices D1 and D2 into a call from device D2 to device D3.
D1
h
C1
* D2
c
C2
* D3
D1
Before
* D2 C3
* D3
After Figure 26 - Transfer Call
The Transfer Call Service is used when a call, C2, from D1 to D3, is in any state other than the Failed or Null state. When Transfer Call Service successfully completes, D1 is released from the call.
- 59 -
11
Status Reporting Services
11.1
Change Monitor Filter Service The Change Monitor Filter Service shall allow changing the filter of an existing monitor.
11.1.1
Service Request The Change Monitor Filter Service Request shall include the following parameters: 1. CSTA Cross Reference Identifier - shall indicate the monitor for which to change the filter. 2. Call Filter - shall indicate Call Event Reports to be filtered by the server and, therefore, not sent to the client. From one to all available Event Reports may be specified. 3. Feature Filter - shall indicate Feature Event Reports to be filtered by the server and, therefore, not sent to the client. From one to all available Event Reports may be specified. 4. Agent Filter - shall indicate Agent Event Reports to be filtered by the server and, therefore, not sent to the client. From one to all available Event Reports may be specified. 5. Maintenance Filter - shall indicate Maintenance Event Reports to be filtered by the server and, therefore, not sent to the client. From one to all available Event Reports may be specified. 6. Voice Unit Filter - shall indicate the Voice Unit Event Reports to be filtered by the server and, therefore, not sent to the client. From one to all available Event Reports may be specified. 7. Private Filter - shall indicate filtering of all Private Event Reports. If filtering of specific, individual Private Event Reports is desired, then the mechanism shall be part of CSTA Private Data Information. The request also may include one or more of the following parameters: 8. CSTA Private Data Information. 9. CSTA Security Service Information.
11.1.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
11.1.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. Call Filter - shall indicate the call filter used by the server to implement the request. This filter may differ from the filter specified by the client in the request. 2. Feature Filter - shall indicate the feature filter used by the server to implement the request. This filter may differ from the filter specified by the client in the request. 3. Agent Filter - shall indicate the agent filter used by the server to implement the request. This filter may differ from the filter specified by the client in the request. 4. Maintenance Filter - shall indicate the maintenance filter used by the server to implement the request. This filter may differ from the filter specified by the client in the request. 5. Voice Unit Filter - shall indicate the Voice Unit filter used for this request. This filter may differ from the filter specified by the client in the request. 6. Private Filter - shall indicate whether Private Event Reports are filtered for this request. This filter may differ from the filter specified by the client in the request. 7. CSTA Private Data Information. 8. CSTA Security Service Information.
11.1.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
- 60 -
11.1.3
Functional description The Change Monitor Filter Service allows a monitor Service client to change the set of Event Reports that are provided by that monitor. The new set of excluded Event Reports may be listed in the Service acknowledgement. A CSTA implementation that does not support all Event Reports, or that does not support filtering, will nevertheless accept Monitor and Change Monitor Filter requests even if the requested filter cannot be provided. In this case, the Service Response indicates the actual set of events that will be provided. For example, an implementation that does not support event filtering responds to Monitor Start and Change Monitor Filter requests with a filter that shows provided events as unfiltered and unimplemented events as filtered. Similarly, an implementation that does not support, for example, Delivered events, must always respond with a filter indicating that Delivered events will not be reported.
- 61 -
11.2
Event Report Service Event Report messages shall be sent from server to client when a monitor request has been positively acknowledged and a CSTA-reportable event has occurred. For monitors on the Switching Function, Event Reports shall be sent from the Switching Function to the Computing Function. To conform to the Event Report Service, implementations shall provide and conform to one or more of the Event Reports as specified in 11.2.2, 11.2.3, 11.2.4, 11.2.5, 11.2.6, 11.2.7.
11.2.1
Service Request Event Reports reflect changes in object state(s) and may be accessed via monitors on devices or calls. The subject of the Event Report shall be specified in the Service Request. Each Event Report shall contain a Cross Reference Identifier parameter, that shall uniquely identify the monitor request that resulted in the Event Report. This parameter shall allow differentiating Event Reports resulting from multiple monitors. Event Reports include parameters that can have unknown or not required values. “Unknown” shall mean that the parameter’s value is not known by the server. “Not required” shall mean that the parameter’s value is that of the monitored device, when device-type monitoring is provided. In these cases, the parameter’s value can be unambiguously determined from the identity of the monitored device. The Last Redirecting Device parameter is a special case. If this parameter has the value “Not Required” then there shall have been no redirection. Every Event Report may include the CSTA Private Data Information that can be used to convey information not defined in this Standard. CSTA Private Data Information that changes the operation of the Service Request shall not be provided in Event Reports. The CSTA Private Data parameter in Event Reports shall never contain information that can be provided using other parameters, fields, and/or identifiers. It shall be possible to augment the standard set of Event Reports to allow applications to identify a message as an Event Report even if the specific Event Report is not understood. Event Reports shall be generically identifiable as Event Reports. Five categories of Switching Function Event Reports and an additional set of Event Reports that apply to Voice Units are defined in CSTA. These are: Agent State Event Report, Call Event Report, Feature Event Report, Maintenance Event Report, Voice Unit Event Report and Private Event Report. The category to which an Event Report belongs shall be always identifiable from the Event Report itself. An instance of an Event Report Service Request may be referred to as an “Event Report”.
- 62 -
11.2.2
Agent State Event Reports An Agent State Event Report is a message that shall indicate a change in state of an agent in the CSTA network. Agent State Event Reports shall always indicate the new state an agent enters independent of any previous state. An Agent State Event Report shall include the Device Identifier of the agent device to which it applies. Every Agent State Event Report also may include CSTA Private Data Information. Transitions between Agent States give rise to Agent Events that can be reported in Agent Event Reports. The following table indicates how particular Agent Event Reports might arise from these transitions, based on the Agent State model given here. Where a cell contains two events, this means that both events will be generated by the indicated state transition. A Switching Function with a different underlying Agent State model might produce a different pattern of Agent Event Reports. In the following table, row headings represent initial Agent States and column headings represent the state into which the agent enters. Cell entries indicate the Agent Event Report that would arise. The Agent Event Reports are more fully defined in the subsequent Agent Event Report sub-clauses. Table 2 - Agent State transitions and resulting Agent Events AGENT NULL AGENT NULL AGENT NOT READY AGENT READY AGENT BUSY AGENT WORKING AFTER CALL
AGENT NOT READY
AGENT READY
Agent_logged_on Agent_not_ready
Agent_logged_on Agent_ready
Agent_logged_off Agent_logged_off
Agent_logged_off
AGENT BUSY
AGENT WORKING AFTER CALL
Agent_ready Agent_not_ready
Agent_busy
Agent_not_ready
Agent_ready
Agent_not_ready
Agent_ready
Agent_working_ after_call
- 63 -
11.2.2.1
Agent Logged Off This Event Report shall indicate that an agent has logged off from a group or device. It implies that the agent cannot accept any additional ACD calls to the group or device. This Event Report shall include the following parameter: 1. CSTA Device Identifier - shall indicate the device from which the agent logged off. If a device is not specified then this parameter shall indicate “Not Required”. The Event Report also may include one or more of the following parameters: 2. CSTA Agent Identifier - shall indicate the Agent Identifier. 3. CSTA Device Identifier - shall indicate the group or pilot from which the agent is logging out. 4. Password Data - shall indicate the agent password for logging off. 5. Cause - shall indicate a reason for the Event Report. 6. CSTA Private Data Information. 7. CSTA Security Service Information.
- 64 -
11.2.2.2
Agent Logged On This Agent State Event Report shall indicate that an agent has logged on and is ready to contribute to the activities of the group or device to which the agent has logged in. It does not indicate that the agent is ready to accept ACD calls. This Event Report shall include the following parameter: 1. CSTA Device Identifier - shall indicate the device from which the agent logged on. If a device is not specified then this parameter shall indicate “Not Required”. The Event Report also may include one or more of the following parameters: 2. CSTA Agent Identifier - shall indicate the Agent Identifier. 3. CSTA Device Identifier - shall indicate the group or pilot to which the agent is logging in. 4. Password Data - shall indicate the agent password for logging in. 5. Cause - shall indicate a reason for the Event Report. 6. CSTA Private Data Information. 7. CSTA Security Service Information.
- 65 -
11.2.2.3
Agent Not Ready This Event Report shall indicate that an agent is occupied with some task other than serving an ACD call. It implies that the agent cannot accept additional ACD calls but may receive non-ACD calls. This Event Report shall include the following parameter: 1. CSTA Device Identifier - shall indicate the device at which Not Ready was invoked. If a device is not specified then the parameter shall indicate “Not Required”. The Event Report also may include one or more of the following parameters: 2. CSTA Agent Identifier - shall indicate the Agent Identifier. 3. Cause - shall indicate a reason for the Event Report. 4. CSTA Private Data Information. 5. CSTA Security Service Information.
- 66 -
11.2.2.4
Agent Ready This Event Report shall indicate that an agent is ready to accept ACD calls even though they may be busy with a non-ACD call. Call Event Reports can provide information on involvement with both ACD and non-ACD calls. The Event Report shall include the following parameter: 1. CSTA Device Identifier - shall indicate the device at which Agent Ready was invoked. If a device is not specified then the parameter shall indicate “Not Required”. The Event Report also may include one or more of the following parameters: 2. CSTA Agent Identifier - shall indicate the Agent Identifier. 3. Cause - shall indicate a reason for the Event Report. 4. CSTA Private Data Information. 5. CSTA Security Service Information.
- 67 -
11.2.2.5
Agent Working After Call This Event Report shall indicate that an agent is occupied with serving an ACD call. It implies that the agent is no longer connected to the call but is still occupied with work related to that call. It also implies that the agent is not able to accept additional ACD calls but may receive non-ACD calls. The Event Report shall include the following parameter: 1. CSTA Device Identifier - shall indicate the device at which Agent Working After Call was invoked. If a device is not specified then the parameter shall indicate “Not Required”. The Event Report also may include one or more of the following parameters: 2. CSTA Agent Identifier - shall indicate the Agent Identifier. 3. Cause - shall indicate a reason for the Event Report. 4. Group - shall indicate the group for which the agent is performing after call work. 5. CSTA Private Data Information. 6. CSTA Security Service Information.
- 68 -
11.2.2.6
Agent Busy This Event Report shall indicate that an agent is occupied with serving an ACD call. It implies that the agent is connected to the ACD call and is occupied with work belonging to that ACD call. It also implies that the agent may be able to accept non-ACD calls. The Event Report shall include the following parameter: 1. CSTA Device Identifier - shall indicate the device at which Agent Busy was invoked. If a device is not specified then the parameter shall indicate “Not Required”. The Event Report also may include one or more of the following parameters: 2. CSTA Agent Identifier - shall indicate the Agent Identifier. 3. Cause - shall indicate a reason for the Event Report. 4. Group - shall indicate the group in which the agent is busy. 5. CSTA Private Data Information. 6. CSTA Security Service Information.
- 69 -
11.2.3
Call Event Reports Call Event Reports are messages that indicate a change in state of one or more Connections in the switching sub-domain. One exception to the rule that Call Event Reports reflect state changes arises with regard to queuing. It is possible for a connection to queue successively without leaving the Queued state, generating a Call Event Report each time it is enqueued. Each Call Event Report may contain a parameter that summarizes the local Connection state from the perspective of a device that is a monitored object. Every Call Event Report may contain one cause code to clarify the basic meaning of the Event Report. Call Event Report cause codes are defined in 11.2.10, Cause codes. Call Event Reports may apply to a single Connection, multiple Connections within a single call, or multiple Connections within multiple calls. The following sub-clauses define the Call Event Reports and the information they provide. For each Call Event Report definition, the following two considerations apply: • A Call Event Report shall indicate that the resultant state has been achieved independent of any previous state. • Initial states are given purely for example to put the Call Event Report into a common telecommunications context.
- 70 -
11.2.3.1
Call Cleared This Event Report shall indicate that a call has been cleared. Normally this occurs when the last remaining device disconnects from the call. It can also occur when a call is immediately dissolved - for example when a conference call is dissolved by the conference controller.
D1
*
C1
*
D2
*
D3
D1
Before
D2
D3 After
Figure 27 - Call Cleared The Call Cleared Event Report applies to all Connections within a call. The Event Report shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the call that was cleared. The Event Report also may include one or more of the following parameters: 2. Local Connection State - if this Event Report was generated from a device monitor then this parameter shall indicate that the Connection state for this call at the monitored device is Null. 3. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 4. Cause - shall indicate a reason for the Event Report. 5. CSTA Private Data Information. 6. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Call Back, Call Cancelled, Call Not Answered, Incompatible Destination, Invalid Account Code, Key Operation, Maintenance, Overflow, Override, and Resources not Available.
- 71 -
11.2.3.2
Conferenced This Event Report shall indicate that two calls have been merged into one with no parties removed from the resulting call in the process.
D1
h
C1
* D2
c
C2
* D3
D1
Before
* D2 c
C3
* D3
After Figure 28 - Conferenced
This Conferenced Event Report applies to multiple Connections within multiple calls. This Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate a primary known call that was conferenced. 2. CSTA Device Identifier - shall indicate the device that conferenced the call. If a device is not specified, then this parameter shall indicate “Unknown” or “Not Required”. 3. CSTA Device Identifier - shall indicate the device last added to the call. If a device is not specified, then this parameter shall indicate “Unknown” or “Not Required”. The last added device is the last device to have been called or answered by a device forming or enlarging a conference. The use of Hold or Retrieve Services during call set-up does not alter the designation of the last added device. The Event Report shall include the following parameter if previous Event Reports have provided this preconference Connection Identifier: 4. CSTA Connection Identifier - shall indicate a secondary call, if known, that was conferenced. The Event Report also may include one or more of the following parameters: list the following three parameters for one or more endpoints in the resultant call: 5. CSTA Connection Identifier - shall indicate the Connection Identifier for the endpoint in the resultant call. 6. CSTA Device Identifier - optional. If provided, it shall be the Device Identifier for the endpoint. 7. CSTA Connection Identifier - shall indicate the previous Connection Identifier for the party in its original call. 8. Local Connection State - if this Event Report was generated from a device monitor then this parameter shall indicate the Connection state for this call at the monitored device. 9. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 10. Cause - shall indicate a reason for the Event Report. 11. CSTA Private Data Information. 12. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Active Monitor, Single Step Conference, Key Operation, New Call, Override, Recall, and Silent Monitor.
- 72 -
11.2.3.3
Connection Cleared This Event Report shall indicate that a device in a call disconnects or is dropped from the call. This Event Report, however, shall not indicate that a transferring device has left a call in the act of transferring that call.
D1
*
C1
* D2
*
D1
*
C1
D3
Before
* D2
D3 After
Figure 29 - Connection Cleared The Connection Cleared Event Report applies to a single Connection. This Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection that was dropped from the call. 2. CSTA Device Identifier - shall indicate the device that dropped from the call. If a device is not specified then the parameter shall indicate “Unknown” or “Not Required”. The Event Report also may include one or more of the following parameters: 3. Local Connection State - if this Event Report was generated from a device monitor then this parameter shall indicate the Connection state for this call at the monitored device. 4. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 5. Cause - shall indicate a reason for the Event Report. 6. CSTA Private Data Information. 7. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Call Back, Call Cancelled, Call Not Answered, Destination Not Obtainable, Do Not Disturb, Incompatible Destination, Key Operation, Overflow, Override, Park, and Resources Not Available.
- 73 -
11.2.3.4
Delivered This Event Report shall indicate that “alerting” (tone, ring, etc.) is being applied to a device or that the server has detected that alerting has been applied to a device.
D1
C1
* D2
D1
Before
a
C1
* D2
After Figure 30 - Delivered
This Event Report applies to a single Connection. CSTA servers may allow multiple devices to be alerted at the same time. When this happens, a follow-on Call Established Event Report for the call might have a different Connected CSTA Device Identifier than the Called CSTA Device Identifier passed in the previous Delivered Event Report for that call. In addition, every time a Delivered Event Report for a call is followed by another Delivered Event Report for that call at another device, it may imply that the first device is no longer involved in the call and that the call may have been redirected. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection that is Alerting. 2. CSTA Device Identifier - shall indicate the device that is Alerting. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 3. CSTA Device Identifier - shall indicate the calling device. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 4. CSTA Device Identifier - shall indicate the originally called device. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 5. CSTA Device Identifier - shall indicate the previously alerted device. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. The Event Report also may include one or more of the following parameters: 6. CSTA Connection Identifier - shall indicate the Connection of the originating device. For an incoming, external call, the originating device (e.g. trunk) identifies the device whereby the call entered the switching sub-domain. For an outgoing, external call, the originating device represents the device whereby a call exits the switching sub-domain. 7. Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the monitored device for this call. 8. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 9. Cause - shall indicate a reason for the Event Report. 10. CSTA Private Data Information. 11. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Call Back, Call Forward, Call Fd.-Immediate, Call Fd.-Busy, Call Fd.-No Answer, Camp On, Key Operation, New Call, No Available Agents, Overflow, Override, Recall, Redirected, Entering Distribution, Distributed, Transfer, and Single Step Transfer.
- 74 -
11.2.3.5
Diverted This Event Report shall indicate that a call has been diverted from a monitored device and that the call is no longer present at the device. This Event Report shall be provided only from monitors active on the device from which the call is diverted.
D1
* C1 * D2
D3
D1
D3 Before
C1
* D2
* After
Figure 31 - Diverted This Event Report applies to a single Connection. If the call alerted the device, then the Event Report shall include the following parameter. If the call did not alert the device, then the Event Report may include the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection that was alerting or that was diverted from the monitored device. The Event Report shall include the following parameters: 2. CSTA Device Identifier - shall indicate the device from which the call was Diverted. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 3. CSTA Device Identifier - shall indicate the device to which the call was diverted. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. The Event Report also may include one or more of the following parameters: 4. Local Connection State - if the Event Report was from a device monitor, this parameter shall indicate the Connection state of this call at the monitored device. 5. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 6. Cause - shall indicate a reason for the Event Report. 7. CSTA Private Data Information. 8. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Call Forward, Call Fd.-Immediate, Call Fd.-Busy, Call Fd.-No Answer, Call Not Answered, Call Pickup, Do Not Disturb, Incompatible Destination, Key Operation, No Available Agents, Overflow, Recall, Redirected, and Voice Unit Initiator.
- 75 -
11.2.3.6
Established This Event Report shall indicate that the server has detected that a device has answered or connected to a call.
D1
a
C1
* D2
D1
Before
c
C1
* D2
After Figure 32 - Established
This Event Report applies to a single Connection. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection that joined the call. 2. CSTA Device Identifier - shall indicate the device that joined the call. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 3. CSTA Device Identifier - shall indicate the calling device. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 4. CSTA Device Identifier - shall indicate the originally called device. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 5. CSTA Device Identifier - shall indicate the previously alerted device. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. The Event Report also may include one or more of the following parameters: 6. CSTA Connection Identifier - shall indicate the Connection of the originating device. For an incoming, external call, the originating device (e.g. trunk) identifies the device whereby the call entered the switching sub-domain. For an outgoing, external call, the originating device represents the device whereby a call exits the switching domain. 7. Local Connection State - if the Event Report was generated from a device monitor, this parameter shall indicate the Connection state of the call at the monitored device. 8. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 9. Cause - shall indicate a reason for the Event Report. 10. CSTA Private Data Information. 11. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Alternate, Call Pickup, Single Step Conference, Key Operation, New Call, Override, Recall, and Transfer.
- 76 -
11.2.3.7
Failed This Event Report shall indicate that a call cannot be completed or when a Connection enters the Failed state for other reasons.
D1
c
C1
D2
D1
c
Before
C1
f
D2
After Figure 33 - Failed
The Failed Event Report applies to a single Connection. The Failed Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection that failed. 2. CSTA Device Identifier - shall indicate the device that failed. If a device is not specified then the parameter shall indicate “Unknown” or “Not Required”. 3. CSTA Device Identifier - shall indicate the called device. If a device is not specified then the parameter shall indicate “Unknown” or “Not Required”. The Event Report also may include one or more of the following parameters: 4. Local Connection State - if the Event Report was generated from a device then this parameter shall indicate the Connection state of this call at the monitored device. 5. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 6. Cause - shall indicate a reason for the Event Report. 7. CSTA Private Data Information. 8. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Alternate, Busy, Call Cancelled, Call Forward, Call Fd.-Immediate, Call Fd.-Busy, Call Fd.-No Answer, Call Not Answered, Camp On, Destination Not Obtainable, Do Not Disturb, Incompatible Destination, Invalid Account Code, Key Operation, Lockout, Maintenance, Network Congestion, Network Not Obtainable, No Available Agents, Overflow, Override, Recall, Redirected, Reorder Tone, Resources Not Available, Transfer, and Trunks Busy.
- 77 -
11.2.3.8
Held This Event Report shall indicate that the server detected that communication on an existing call has been temporarily interrupted at one of the devices on the call.
D1
c
C1
* D2
D1
Before
h
C1
* D2
After Figure 34 - Held
The Held Event Report applies to a single Connection. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection at which hold was activated. 2. CSTA Device Identifier - indicates the device at which hold was activated. If a device is not specified then the parameter shall indicate “Unknown” or “Not Required”. The Event Report also may include one or more of the following parameters: 3. Local Connection State - if the Event Report was generated from a device monitor then this parameter shall indicate the Connection state of this call at the monitored device. 4. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 5. Cause - shall indicate a reason for the Event Report. 6. CSTA Private Data Information. 7. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Alternate, Call Forward, Call Fd.-No Answer, Key Operation, Recall, and Transfer.
- 78 -
11.2.3.9
Network Reached This Event Report shall indicate that a call has cut through the CSTA switching sub-domain boundary to another network (e.g. has reached an outgoing trunk). This Event Report implies that there may be a reduced level of Event Reporting and possibly no additional device feedback, except disconnect/drop, provided for this party in the call. Additionally, the CSTA application should assume that it cannot directly manipulate the farend device represented by the trunk. A Network Reached Event Report shall never be sent for calls made to devices connected directly to the CSTA switching sub-domain. This event shall indicate that a Connection with a trunk has reached the Connected state, and that further events for that Connection refer to the state of the endpoint to which the trunk is a gateway.
Switching Sub-domain Boundary
D1
c
C1
D2
D1
c
C1
c
Trunk
Before
D2 Trunk
After Figure 35 - Network Reached
This Network Reached Event Report applies to a single Connection. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the outbound Connection (of the trunk) to another network. 2. CSTA Device Identifier - shall indicate the trunk that was selected. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 3. CSTA Device Identifier - shall indicate the destination device. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. The Event Report also may include one or more of the following parameters: 4. Local Connection State - if the Event Report was generated from a device monitor then this parameter shall indicate the Connection state for the call at the monitored device. 5. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 6. Cause - shall indicate a reason for the Event Report. 7. CSTA Private Data Information. 8. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Call Forward, Call Fd.-Immediate, Call Fd.-Busy, Call Fd.-No Answer, Key Operation, Overflow, Redirected, Resources Not Available, and Transfer.
- 79 -
11.2.3.10
Originated This Event Report shall indicate that the server is attempting to make a call. It implies that input activity is complete and that a call (rather than feature) has been requested.
D1
D2
D1
Before
c
C1
D2
After Figure 36 - Originated
This Originate Event Report applies to a single Connection. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection at which the call originated. 2. CSTA Device Identifier - shall indicate the calling device. For an incoming call, the calling device identifies the party outside the switching sub-domain that placed the call. For an outgoing call, the calling device represents the party on behalf of whom the call is originated. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 3. CSTA Device Identifier - shall indicate the called device. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. The Event Report also may include one or more of the following parameters: 4. CSTA Device Identifier - shall indicate the originating device. For an incoming call, the originating device (e.g. trunk) identifies the device whereby the call entered the switching sub-domain. For an outgoing call, the originating device represents the device whereby a call exits the switching domain. This parameter is only given if the call crosses the switching sub-domain boundary. 5. Local Connection State - if the Event Report was generated from a device monitor then this parameter shall indicate that the Connection state for this call at the monitored device is Connect. 6. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 7. Cause - shall indicate a reason for the Event Report. 8. CSTA Private Data Information. 9. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Call Back, Key Operation, New Call, Override, Make Call, and Silent Monitor.
- 80 -
11.2.3.11
Queued This Event Report shall indicate that a call queued. Queuing may occur, for example, at an ACD, hunt group, or other device. Queuing also may occur during network routeing without an associated device.
D1
c
C1
D2
D1
Before
c
C1
q
D2
After Figure 37 - Queued
The Queued Event Report applies to a single Connection. This Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection that queued. 2. CSTA Device Identifier - shall indicate the queuing device (if queued at a device). If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 3. CSTA Device Identifier - shall indicate the calling device. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 4. CSTA Device Identifier - shall indicate the called device. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 5. CSTA Device Identifier - shall indicate the redirecting device if the call was redirected. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. The Event Report also may include one or more of the following parameters: 6. Number - shall indicate the total number of calls in queue, including this call. 7. Number - shall indicate the number of calls ahead of the call when it was enqueued (the enqueued call is not counted in this number). 8. Local Connection State - if the Event Report was generated from a device monitor then this parameter shall indicate the Connection state of this call at the monitored device. 9. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 10. Cause - shall indicate a reason for the Event Report. 11. CSTA Private Data Information. 12. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Busy, Call Back, Call Forward, Call Fd.-Immediate, Call Fd.-Busy, Call Fd.-No Answer, Camp On, Destination Not Obtainable, Do Not Disturb, Key Operation, Network Congestion, Network Not Obtainable, No Available Agents, Overflow, Park, Recall, Redirected, Resources Not Available, Transfer, and Trunks Busy.
- 81 -
11.2.3.12
Retrieved This Event Report shall indicate that the server detected that a previously held call has been retrieved.
D1
h
C1
* D2
D1
Before
c
C1
* D2
After Figure 38 - Retrieved
The Retrieved Event Report applies to a single Connection. This Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection on which hold was de-activated. 2. CSTA Device Identifier - shall indicate the device at which hold was de-activated. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. The Event Report also may include one or more of the following parameters: 3. Local Connection State - if the Event Report was generated from a device monitor then this parameter shall indicate the Connection state of this call at the monitored device. 4. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 5. Cause - shall indicate a reason for the Event Report. 6. CSTA Private Data Information. 7. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Alternate, Key Operation, Recall, and Transfer.
- 82 -
11.2.3.13
Service Initiated This Event Report shall indicate that telecommunications service has been initiated at a monitored device. The server typically issues this Event Report when “dial tone” is provided. This Event Report shall indicate that either a call may be originated or a feature may be invoked. This event also may indicate that a device is prompting a user to start a call. NOTE 6 The Make Call Service will often prompt a user to take a phone off-hook if that phone is not able to do so without manual intervention. In this case the Service Initiated event may be used to indicate that the phone is prompting the user to go off-hook. In this case the Make Call or Call Back cause code shall be used. NOTE 7 This Event Report may not be sent for functional (en-bloc BRI) terminals and may not be sent for calls that are set up without receiving dial tone or other prompting, like CSTA calls initiated with Make Call Service from a hands-free telephone.
D1
i
D1 Before
C1
After Figure 39 - Service Initiated
The Service Initiated Event Report applies to a single Connection. The Event Report shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection at which service has been established. This Connection Identifier shall continue to be used if the initiated service becomes a Call. The Event Report also may include one or more of the following parameters: 2. Local Connection State - if the Event Report was generated from a device monitor then this parameter shall indicate the Connection state for this call at the monitored device Initiated. 3. Cause - shall indicate a reason for the Event Report. 4. CSTA Private Data Information. 5. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Call Back, Call Cancelled, Key Operation, Make Call, Recall, and Override.
- 83 -
11.2.3.14
Transferred This Event Report shall indicate that an existing call was transferred to another device and that the device requesting the transfer has been dropped from the call. The transferring device does not appear in any future Event Reports for the call.
D1
h
C1
* D2
c
C2
* D3
D1
Before
* D2 C3
* D3
After Figure 40 - Transferred
The Transferred Event Report applies to single Connections in multiple calls. This Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate a primary known call that was transferred. 2. CSTA Device Identifier - shall indicate the device that transferred the call (D1 in the preceding figure). If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 3. CSTA Device Identifier - shall indicate the device (D3 in the preceding figure) to which the call (C1 in the preceding figure) was transferred. If a device is not specified then the parameter shall indicate “Unknown” or “Not Required”. This Event Report shall include the following parameter if previous Event Reports have provided this pretransfer Connection Identifier: 4. CSTA Connection Identifier - shall indicate a secondary call, if known, that was transferred. The Event Report also may include any one or more of the following parameters: list the following three parameters for every endpoint in the resultant call: 5. CSTA Connection Identifier - shall indicate the Connection Identifier for the endpoint in the resultant call. 6. CSTA Device Identifier - if provided, this parameter shall indicate the Device Identifier for the endpoint. 7. CSTA Connection Identifier - shall indicate the previous Connection Identifier for the endpoint in its original call. 8. Local Connection State - if the Event Report was generated from a device monitor then this parameter shall indicate the Connection state of this call at the monitored device. 9. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 10. Cause - shall indicate a reason for the Event Report. 11. CSTA Private Data Information. 12. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Key Operation, New Call, Recall, Redirected, Transfer, and Voice Unit Initiator.
- 84 -
11.2.4
Feature Event Reports Each Feature Event Report is a message that shall indicate a change in Feature state of a call or device in the CSTA network. Like Call Event Reports, each Feature Event Report shall indicate the new state that the feature enters independent of any previous state. Every Event Report shall include the identifier of the call or device to which the event applies.
11.2.4.1
Call Information This Event Report shall indicate that an account code feature has collected data for a party on a call. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the party that entered the account code and the call for which it was entered. 2. CSTA Device Identifier - shall indicate the device at which the account code was entered. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. The Event Report also may include one or more of the following parameters: 3. Account Code Data - shall indicate the account code to associate with the call. 4. Authorization Code Data - shall indicate the authorization code to allow the call. 5. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 6. CSTA Private Data Information. 7. CSTA Security Service Information.
- 85 -
11.2.4.2
Do Not Disturb This Event Report shall indicate that the Do Not Disturb feature has been invoked for a device. The Do Not Disturb Event Report shall include the following parameters: 1. CSTA Device Identifier - shall indicate the device at which Do Not Disturb was invoked. If a device is not specified then this parameter shall indicate “Not Required”. 2. Flag - shall indicate whether the feature was turned on or off. This Event Report also may include one or more of the following parameters: 3. CSTA Private Data Information. 4. CSTA Security Service Information.
- 86 -
11.2.4.3
Forwarding This Event Report shall indicate that the Forwarding feature has been invoked for a device. The Forwarding Event Report shall include the following parameters: 1. CSTA Device Identifier - shall indicate the device at which Forwarding was invoked. If a device is not specified then this parameter shall indicate “Not Required”. 2. Type of forwarding that was invoked - shall be one of the following types. For each type the values "on" and "off" shall be allowed: Immediate - Forwarding all calls, Busy - Forwarding when busy, No Answer - Forwarding after no answer, Immediate Internal - Forwarding all internal calls, Immediate External - Forwarding all external calls, Busy Internal - Forwarding when busy for an internal call, Busy External - Forwarding when busy for an external call, No Answer Internal - Forwarding after no answer for an internal call, No Answer External- Forwarding after no answer for an external call. The Event Report also may include one or more of the following parameters: 3. CSTA Device Identifier - shall indicate the device to which calls are forwarded. 4. CSTA Private Data Information. 5. CSTA Security Service Information.
- 87 -
11.2.4.4
Message Waiting This Event Report shall indicate that the Message Waiting feature has been invoked for a device. NOTE 8 This Event Report can be provided to both monitors providing Event Reports for the call and monitors for the device to which the Message Waiting is directed. Specifically, it can be provided to both the subject and object devices of the feature. The Message Waiting Event Report shall include the following parameters: 1. CSTA Device Identifier - shall indicate the device at which Message Waiting was invoked. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 2. CSTA Device Identifier - shall indicate the device where the message is waiting. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 3. Flag - shall indicate whether the feature was turned on or off. This Event Report also may include one or more of the following parameters: 4. CSTA Private Data Information. 5. CSTA Security Service Information.
- 88 -
11.2.4.5
Auto-Answer This Event Report shall indicate that the Auto-Answer feature has been changed for a device. This Event Report shall include the following parameters: 1. CSTA Device Identifier - shall indicate the device at which Auto-Answer was invoked. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 2. Flag - shall indicate whether the feature was turned on or off. This Event Report also may include one or more of the following parameters: 3. CSTA Private Data Information. 4. CSTA Security Service Information.
- 89 -
11.2.4.6
Microphone Mute This Event Report shall indicate that the Microphone Mute feature has been changed for a device. This Event Report shall include the following parameters: 1. CSTA Device Identifier - shall indicate the device for which Microphone Mute was invoked. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 2. Flag - shall indicate whether the microphone was turned on or off. This Event Report also may include one or more of the following parameters: 3. CSTA Private Data Information. 4. CSTA Security Service Information.
- 90 -
11.2.4.7
Speaker Mute This Event Report shall indicate that the Speaker Mute feature has been changed for a device. This Event Report shall include the following parameters: 1. CSTA Device Identifier - shall indicate the device for which Speaker Mute was invoked. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 2. Flag - shall indicate whether the speaker was turned on or off. This Event Report also may include one or more of the following parameters: 3. CSTA Private Data Information. 4. CSTA Security Service Information.
- 91 -
11.2.4.8
Speaker Volume This Event Report shall indicate that the Speaker Volume has been changed for a device. This Event Report shall include the following parameters: 1. CSTA Device Identifier - shall indicate the device at which speaker volume was changed. If a device is not specified then this parameter shall indicate “Unknown” or “Not Required”. 2. Speaker Volume - shall indicate the volume that has been set. The value shall be an integer from 0 (silent) to 100 (maximum volume). This Event Report also may include one or more of the following parameters: 3. CSTA Private Data Information. 4. CSTA Security Service Information.
- 92 -
11.2.5
Maintenance Event Reports Each Maintenance Event Report is a message that shall indicate a change in the maintenance state of a device in the CSTA network. Each Maintenance Event Report shall indicate the new state that the device enters, independent of any previous state. Every Event Report shall include the identifier of the device to which the event applies. Additionally, every Event Report may include a cause value or field that clarifies the basic meaning of the Event Report. Every Event Report also may include CSTA Private Data Information.
11.2.5.1
Back In Service This Event Report shall indicate that the device has returned into service and once again operates normally in the CSTA domain. The Back In Service Event Report shall include the following parameter: 1. CSTA Device Identifier - shall indicate the device that is Back In Service. If a device is not specified then this parameter shall indicate “Not Required”. The Event Report also may include one or more of the following parameters: 2. Cause - shall indicate a reason for the Event Report. 3. CSTA Private Data Information. 4. CSTA Security Service Information.
- 93 -
11.2.5.2
Out Of Service This Event Report shall indicate that the device has entered a maintenance state (i.e. has been taken Out Of Service) and can no longer accept calls or be manipulated via CSTA. It may be possible to continue to Monitor or take a Snapshot of such a device, but no direct Services (such as Make Call or Request Feature) can be provided. The Out Of Service Event Report shall include the following parameter: 1. CSTA Device Identifier - shall indicate the device that is taken Out Of Service. If a device is not specified then this parameter shall indicate “Not Required”. The Event Report also may include one or more of the following parameters: 2. Cause - shall indicate a reason for the Event Report. 3. CSTA Private Data Information. 4. CSTA Security Service Information.
- 94 -
11.2.6
Private Event Reports Private Event Reports may be used to convey proprietary event information to an application that cannot be reported within any of the defined Event Reports.
- 95 -
11.2.7
Voice Unit Event Reports Each Voice Unit Event Report is a message that shall indicate a change in state of a message in a Voice Unit in the CSTA network. Voice Unit Event Reports shall indicate the new state that the message enters regardless of any previous state. Every Event Report shall include both the identifier of the message and that of the connection to the Voice Unit that is being monitored. Additionally, Event Reports may include the message length, the current position in the message, a cause for the event, and CSTA Private Data Information. The model represented in figure 8 illustrates the relationships among the following events.
11.2.7.1
Play This Event Report shall indicate that a message is being played. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the connection for the voice path to the Voice Unit for the affected message. 2. Message Identifier - shall indicate the message that changed state. The Event Report also may include one or more of the following parameters: 3. Message Length - shall indicate the length of the message in milliseconds. 4. Current Position in Message - shall indicate the number of milliseconds from the start of the message. 5. Speed - shall indicate playing speed as percentage of nominal (normal) speed. 6. Cause - shall indicate a reason for the occurrence of the Event Report. 7. CSTA Private Data Information. 8. CSTA Security Service Information.
- 96 -
11.2.7.2
Record This Event Report shall indicate that a message is being recorded. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the connection for the voice path to the Voice Unit for the affected message. 2. Message Identifier - shall indicate the message that changed state. The Event Report also may include one or more of the following parameters: 3. Message Length - shall indicate the length of the message in milliseconds. 4. Current Position in Message - shall indicate the number of milliseconds from the start of the message. 5. Cause - shall indicate a reason for the occurrence of the Event Report. 6. CSTA Private Data Information. 7. CSTA Security Service Information.
- 97 -
11.2.7.3
Review This Event Report shall indicate that a recording message is being reviewed. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the connection for the voice path to the Voice Unit for the affected message. 2. Message Identifier - shall indicate the message that changed state. The Event Report also may include one or more of the following parameters: 3. Message Length - shall indicate the length of the message in milliseconds. 4. Current Position in Message - shall indicate the number of milliseconds from the start of the message. 5. Cause - shall indicate a reason for the occurrence of the Event Report. 6. CSTA Private Data Information. 7. CSTA Security Service Information.
- 98 -
11.2.7.4
Stop This Event Report shall indicate that a message is not being used for play or record. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the connection for the voice path to the Voice Unit for the affected message. 2. Message Identifier - shall indicate the message that changed state. The Event Report also may include one or more of the following parameters: 3. Message Length - shall indicate the length of the message in milliseconds. 4. Current Position in Message - shall indicate the number of milliseconds from the start of the message. 5. Cause - shall indicate a reason for the occurrence of the Event Report. 6. CSTA Private Data Information. 7. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. End of Message Detected, Message Length Exceeded, and No Speech Detected.
- 99 -
11.2.7.5
Suspend Play This Event Report shall indicate that a message is suspended in play. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the connection for the voice path to the Voice Unit for the affected message. 2. Message Identifier - shall indicate the message that changed state. The Event Report also may include one or more of the following parameters: 3. Message Length - shall indicate the length of the message in milliseconds. 4. Current Position in Message - shall indicate the number of milliseconds from the start of the message. 5. Cause - shall indicate a reason for the occurrence of the Event Report. 6. CSTA Private Data Information. 7. CSTA Security Service Information.
- 100 -
11.2.7.6
Suspend Record This Event Report shall indicate that a message is suspended during recording. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the connection for the voice path to the Voice Unit for the affected message. 2. Message Identifier - shall indicate the message that changed state. The Event Report also may include one or more of the following parameters: 3. Message Length - shall indicate the length of the message in milliseconds. 4. Current Position in Message - shall indicate the number of milliseconds from the start of the message. 5. Cause - shall indicate a reason for the occurrence of the Event Report. 6. CSTA Private Data Information. 7. CSTA Security Service Information. Frequently used cause codes are listed below. For the complete list see 11.2.10, Cause codes. Message Length Exceeded, and No Speech Detected.
- 101 -
11.2.7.7
Voice Attributes Change Event This Event Report shall indicate that one or more attributes of a message has changed. The Event Report shall include the following parameters: 1. CSTA Connection Identifier - shall indicate the connection for the voice path to the Voice Unit for the affected message. 2. Message Identifier - shall indicate the message for which one or more attributes changed. The Event Report also may include one or more of the following parameters: 3. Volume - shall indicate the current volume on the specified connection. A value of 100 shall indicate maximum volume and 0 shall indicate minimum volume. 4. Level - shall indicate the current recording level on the specified connection. A value of 100 shall indicate maximum recording level and 0 shall indicate minimum level. 5. Speed - shall indicate current speed of the specified message. A value of 100% shall indicate normal speed. The slowest speed shall be 1%. 6. Current Position in Message - shall indicate the number of milliseconds from the start of the specified message. 7. Cause - shall indicate a reason for the occurrence of the Event Report. 8. CSTA Private Data Information. 9. CSTA Security Service Information.
11.2.8
Service Response Event Reports shall not have responses.
11.2.9
Functional description The action of each Event Report is described in the individual report sub-clauses.
- 102 -
11.2.10
Cause codes Cause codes can be used to clarify other information provided in both CSTA Event Reports and responses to Service Requests. Cause codes may appear in any call Event Report where they make sense. The following list of cause codes definitions shows how cause codes modify the Event Reports to which they apply. Following the list of cause codes is a table showing the cause codes that are meaningful for each CSTA Event Report.
11.2.10.1
Agent Event Cause codes Cause code
shall indicate that:
Forced Pause
The agent entered a periodic non-working condition. This usually occurs because of regulations that require agents to have a certain amount of time between handling successive ACD calls. Table 3 - CSTA Agent Event Report - Cause Relationships
Cause
Agent Agent Agent Logged Logged Ready On Off
Forced Pause 11.2.10.2
Agent Not Ready
Agent Busy
Agent Working After Call
y
Call Event Cause codes Cause code
shall indicate that:
Active Monitor
An Active Monitor Feature has been invoked. This feature is typically used to allow intrusion with the ability to speak and listen by a supervisor into an agent call. The resultant call may be considered to be a conference. Therefore, cause code may be supplied with the Conferenced Event Report.
Alternate
The call is in the process of being interchanged with another call. This feature is typically used with single-line telephones where the human interface involves placing one call on hold and retrieving a held call or answers a waiting call with a single action.
Blocked
One party has disconnected from a call leaving one other party remaining with a local connection.
Busy
The call encountered a busy or unavailable device.
Call Back
Call Back has been invoked to complete a call that encountered busy or a no answer condition. This cause may occur in a Service Initiated Event Report to indicate that the caller is being prompted.
Call Cancelled
The call has been terminated before the associated device has gone on-hook.
Call Forward
The call has been redirected for any reason via a Call Forwarding feature.
Call Fd. - Immediate
The call has been redirected via a Call Forwarding feature set for all conditions.
Call Fd. - Busy
The call has been redirected via a Call Forwarding feature set for a busy endpoint.
Call Fd. - No Answer
The call has been redirected via a Call Forwarding feature set for an endpoint that does not answer.
Call Not Answered
The call was not answered because a timer elapsed.
Call Pickup
The call was redirected via a Call Pickup feature.
Camp On
A Camp On feature was invoked or has matured.
- 103 -
Consultation
A Consultation has been undertaken and/or is in progress.
Dest. Not Obtainable
The call could not reach the destination.
Distributed
The call was distributed by an ACD or hunt group.
Do Not Disturb
The call encountered a Do Not Disturb condition.
Entering Distribution
The call was delivered to a distribution mechanism (ACD).
Incompatible Destination
The call encountered an incompatible destination.
Invalid Account Code
The call has an invalid account code.
Key Operation
The reported Event occurred at a bridged or twin device.
NOTE 9 Telephone numbers associated primarily with one device often appear also on a second device. One example is a secretary whose phone has mirrored or bridged lines of a boss’s phone. Lockout
The call encountered inter-digit time-out while dialling.
Maintenance
The call encountered a facility or endpoint in a maintenance condition.
Make Call
The event was provided as the result of a CSTA Make Call Service This cause may occur in a Service Initiated Event Report to indicate that the caller is being prompted.
Network Congestion
The call encountered a congested network. In some circumstances this cause code indicates that the user is listening to a special signal tone from a network. The tone may be accompanied by a voiced statement similar to “All circuits are busy...”.
Network Not Obtainable
The call could not reach a destination network.
Network Signal
The event was provided as result of a network (trunk supervision / call progress) signal.
New Call
The call has not yet been redirected.
No Available Agents
The call could not access any agent.
Normal Clearing
The call or connection cleared in a normal way.
Number Changed
The called number has been changed to a new number.
Overflow
The call overflowed a queue, group, or target.
Override
The call resulted from use of an Override feature.
Park
The Event Report is associated with an action to park a call or retrieve a call from park.
Recall
The call is alerting due to a time-out associated with a feature that failed to complete or that anticipated further action from the user.
Redirected
The call has been redirected.
Reorder Tone
The call encountered a reorder condition. When this occurs, the network usually provides Reorder Tone to indicate that a request (call, feature, or supplementary service) was not recognizable. This condition typically results when a user dials a number that is not valid or attempts to obtain a service that is not enabled for that user or device.
Resources not Available
Resources were not available.
Silent Monitor
The event was caused by the invocation of a feature that allows a third party, such as an ACD agent supervisor, to join the call. The joining party can hear the entire conversation, but cannot be heard by either original party. The feature, sometimes called silent intrusion, may provide a tone to one or both parties to
- 104 -
indicate that they are being monitored. This feature is not the same as a CSTA Monitor request. This cause code is not used to indicate that a CSTA Monitor has been initiated. Single Step Conference
The event occurred through the use of Single Step Conference Call Service.
Single Step Transfer
The Transfer occurred in a single step.
Time-out
The reported event was generated because a trunk timer expired.
Transfer
A Transfer is in progress or has occurred.
Trunks Busy
The call encountered Trunks Busy.
Voice Unit Initiator
The reported event resulted from action by automated equipment (voice mail device, voice response unit, announcement) rather than from action by a human user.
- 105 -
Table 4 - CSTA Call Event Report - Cause Relationships
Cause Active Monitor Alternate Blocked Busy Call Back Call Cancelled Call Forward Call Fd. - Immediate Call Fd. - Busy Call Fd. - No Answer Call Not Answered Call Pickup Camp On Consultation Dest. not Obtainable Distributed Do Not Disturb Entering Distribution Incpt. Destination Invalid Account Code Key Operation Lockout Maintenance Make Call Net Congestion Net Not Obtainable Network Signal New Call No Available Agents Normal Clearing Number Changed Overflow Override Park Recall Redirected Reorder Tone Resrcs. not Available Silent Monitor Single Step Conference Single Step Transfer Timeout Transfer Trunks Busy Voice Unit Initiator
Call Clr.
Conf Con. Deli Clr. v y
y y
y y
Fail
y
y y y
Held Net. Orig Q-ed Retr. Svc. Init. Rch. . y
y
y y y y y y y
y y y y y y
y
y
Tran
y
y y y y y
y
Divr Est. t
y y y y
y y
y y
y y y y
y
y
y
y y
y y
y y
y y
y y y y
y
y
y y y
y
y
y y y y y
y
y y y
y
y
y y
y y y y
y
y
y
y
y
y
y
y
y
y
y y
y
y
y
y y
y y y
y y
y
y y y
y y y y
y
y y
y
y
y y y
y y
y
y y y
y
y y y y
y
y y y y
y y
y
y
y
y
y
y
y y
y y y y
y y y
y
y y
y y
y y y y
y y
y y
y
y
y y
y
y y
- 106 -
11.2.10.3
Voice Unit Event Cause codes Cause code
shall indicate that:
End of Data Detected
The end of data was detected during a Play or Review message operation. Indicating end-of-data, as opposed to end-of-message, allows the possibility of playing multiple messages.
Msg. Size Exceeded
The maximum permitted size of the message was detected during a Record message operation.
No Speech Detected
A period of silence was detected during a Record message operation (no speech).
DTMF Tone Detected
A DTMF tone was detected during message playback or recording.
Duration Exceeded
The maximum time duration for playback or recording of a message was exceeded.
Speech Detected
Speech (or non-silence) was detected during message playback.
Next Message
Shall indicate the start of play of the next message within a sequence of messages.
Table 5 - CSTA Voice Unit Event Report - Cause Relationships Cause \ Event
Stop
End of Data Detected Message Size Exceeded No Speech Detected DTMF Tone Detected Duration Exceeded Speech Detected Next Message
y
Play
Suspend/ Record Play
y
y
y
y
y
y
y
y
y
y y
y
y
y y
Suspend/ Review Record
y
y
- 107 -
11.2.10.4
I/O Service Cause codes Although there are no Event Reports associated with I/O Services, the Send Data Service allows cause codes as an optional parameter. These cause codes shall be as follows: Cause code
shall indicate that:
Termination char. recv'd
The specified termination character was received.
Character count reached
Specified number of characters were entered.
Timeout
Timeout occurred.
Switch-terminated
The switch encountered.
terminated
collection
before
other
termination
condition
Table 6 - CSTA I/O Services Event Report - Cause Relationships Cause
Termination char. rcv'd Character count reached Timeout Switchterminated
Send Data y y y y
Stop Data
Send Broadcast Data
Send multicast Data
Suspend Data Path
Data Path Resume Suspended Data Path
FastData
- 108 -
11.3
Monitor Start Service The Monitor Start Service shall provide Event Reports for a call, device or for one or more calls involving a CSTA device. Event Reports shall be provided for all endpoints within the CSTA sub-domain and optionally for endpoints outside of the CSTA sub-domain that are involved in a monitored call. There shall be two types of Monitor Start Service: call-type and device-type. Call-type Monitor Start Service: For the call-type Monitor Start Service, all Call Event Reports passed by the filter shall be sent for either: • all the Connection state changes that occur in the call specified by the CSTA Connection Identifier in the Service Request, or • all the Connection state changes that occur in any call involving the device specified by the CSTA Device Identifier in the Service Request. If a call is forwarded or transferred devices may cease to participate in that call. However, all subsequent Events at the new devices shall be reported. Also, a call that is being monitored may have a new Call Identifier assigned to it after a conference or transfer. The Event Report shall provide a new Call Identifier and monitoring shall continue for that call. Additionally, Agent, Feature, and Maintenance Event Reports passed by the filter shall be provided when they apply to the monitored call or device. Voice Unit Event Reports passed by the filter shall be provided for call-type monitors started on the Voice Unit device. Device-type Monitor Start Service: For the device-type Monitor Start Service, all Call Event Reports passed by the filter shall be sent for either: • all the Connection state changes that occur in the call that is present at the device specified by the CSTA Connection Identifier in the Service Request, or • all the Connection state changes that occur in any call that is present at the device specified by the CSTA Device Identifier in the Service Request. Event Reports shall be provided for calls that arrive at the device after the monitor request has been acknowledged and also for calls that are already at the device at the time of the acknowledgement. Events that occurred prior to the monitor request acknowledgement shall not be reported. If a call is dropped, forwarded, or transferred, the device ceases to participate in that call, and no further events shall be reported. Additionally, Agent, Feature, Maintenance, and Voice Unit Event Reports passed by the filter shall be provided when they apply to the monitored device.
11.3.1
Service Request The object to be monitored shall be specified in the Service Request. The object may be either a device or call. Additionally, the Service Request may indicate the type of monitoring requested for the object. The Monitor Start type may be either device-type or call-type. The filter specified in the Service Request shall indicate Event Reports that are to be filtered out by the server and not sent to the client. If the client does not specify a filter in the Service Request then it implicitly requests that all Event Reports be sent to it (i.e. that no Event Reports are filtered out). Since support for the filter is optional in both the client and server, the client must be prepared to receive Event Reports it had requested to be filtered out. NOTE 10 This approach facilitates client/server interworking when different filtering implementation options have been chosen. The request shall include one and only one of the following two parameters: 1. CSTA Device Identifier - shall indicate the CSTA Device to be monitored. 2. CSTA Connection Identifier - shall indicate the CSTA call to be monitored. The request also may include one or more of the following parameters: 3. Monitor Type - shall indicate the type of monitor requested. The value shall indicate either call or device. If this parameter is not provided then the type of monitoring shall be selected by the server. This Standard does not specify a default.
- 109 -
4. Call Filter - shall indicate the Call Event Reports to be filtered out by the server and, therefore, not sent to the client. From one to all available Event Reports may be specified. 5. Feature Filter - shall indicate the Feature Event Reports to be filtered out by the server and, therefore, not sent to the client. From one to all available Event Reports may be specified. 6. Agent Filter - shall indicate the Agent Event Reports to be filtered out by the server and, therefore, not sent to the client. From one to all available Event Reports may be specified. 7. Maintenance Filter - shall indicate the Maintenance Event Reports to be filtered out by the server and, therefore, not sent to the client. From one to all available Event Reports may be specified. 8. Voice Unit Filter - shall indicate the Voice Unit Event Reports to be filtered by the server and, therefore, not sent to the client. From one to all available Event Reports may be specified. 9. Private Filter - when present, this parameter shall indicate that all Private Event Reports should be filtered out and, therefore, not be sent to the client. If filtering of individual Private Event Reports is desired, then the mechanism for doing this shall be part of CSTA Private Data Information. 10. CSTA Private Data Information. 11. CSTA Security Service Information. 11.3.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
11.3.2.1
Positive acknowledgement The positive acknowledgement shall contain the following parameter: 1. Cross Reference Identifier - shall indicate a value that is unique within the association for the duration of the monitor and that can be used to relate subsequent Event Reports to the monitor request that initiated them. It shall also allow correlating Monitor Stop and subsequent Change Filter Requests with the original Monitor Start request on which they act. The positive acknowledgement also may include one or more of the following parameters: 2. Call Filter - shall indicate the call filter actually used by the server to satisfy this request. This filter may differ from the requested filter specified by the client. 3. Feature Filter - shall indicate the feature filter actually used by the server to satisfy this request. This filter may differ from the requested filter specified by the client. 4. Agent Filter - shall indicate the agent filter actually used by the server to satisfy this request. This filter may differ from the requested filter specified by the client. 5. Maintenance Filter - shall indicate the maintenance filter actually used by the server to satisfy this request. This filter may differ from the requested filter specified by the client. 6. Voice Unit Filter - shall indicate the Voice Unit filter that is used for this request. This filter may differ from the requested filter specified by the client. 7. Private Filter - shall indicate whether Private Event Reports will be filtered out for this request. This filter may differ from the requested filter specified by the client. 8. CSTA Private Data Information. 9. CSTA Security Service Information.
11.3.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
11.3.3
Functional description Once a request has been acknowledged, a set of reports describing the events that occur are sent to the client by the server on the association that requested the monitor. These reports cease after the server terminates the
- 110 -
Monitor Start Service. Service termination can result from a client’s request or from server-initiated action. The server will terminate the monitor if the object being monitored ceases to exist or if the monitored object leaves a CSTA sub-domain. A CSTA implementation that does not support all Event Reports, or that does not support filtering, may accept Monitor and Change Filter requests even if the requested filter cannot be provided. In this case, the response shall indicate the actual set of events that will be provided. For example, an implementation that does not support event filtering shall respond to Monitor Start and Change Filter requests with a filter that shows provided events as unfiltered and unimplemented events as filtered. Similarly, an implementation that does not support, for example, Delivered events, must always respond with a filter indicating that Delivered events will not be reported.
- 111 -
11.4
Monitor Stop Service The Monitor Stop Service shall be used to cancel a previously initiated Monitor Start Service. The Monitor Stop Service can be requested by either the client or server to terminate/abort the Monitor Start Service.
11.4.1
Service Request The Monitor Stop Service Request shall include the following parameter: 1. CSTA Cross Reference Identifier - shall indicate the Cross Reference Identifier provided in the original Monitor Start Service Request to correlate the request with Event Reports that follow and the request to stop the Service. The request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
11.4.2
Service Response The Monitor Stop server (which can be either the monitor server or monitor client) shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
11.4.2.1
Positive acknowledgement Positive Acknowledgement to the Service Request shall indicate that the Cross Reference Identifier used by the Monitor Start Service has become invalid. The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
11.4.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
11.4.3
Functional description The Computing Function may request the Monitor Stop Service when it no longer has an interest in continuing a monitor, and the Switching Function may request a Monitor Stop Service when it can no longer provide information. The latter case is likely to occur often for monitors on calls that have ended, but may occur for load management reasons as well. Once a request has been acknowledged, a set of reports describing the events that occur cease to be sent to the client by the server on the association that requested the monitor. The server will abort the monitor if the object being monitored is destroyed, which can happen for a call, or if the object leaves the CSTA domain, which can happen for all objects.
- 112 -
11.5
Snapshot Call Service Snapshot Call Service shall provide information about a specified CSTA call. The information provided shall include the identities of the devices and their Connections in the call as well as the states of those Connections that comprise an overall Call state.
11.5.1
Service Request The Snapshot Call Service Request shall include the following parameter: 1. CSTA Connection Identifier - shall indicate the call to be snapshot. The request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
11.5.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
11.5.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameters for every endpoint in the call: 1. CSTA Device Identifier - shall indicate the CSTA Device Identifier for the device. If the device is outside the switching sub-domain, then the parameter may indicate “Unknown”. 2. CSTA Connection Identifier - shall indicate the CSTA Connection Identifier for the endpoint. The positive acknowledgement also shall include the following parameter for each endpoint within the CSTA switching sub-domain that is in the call: 3. CSTA Connection state - shall indicate the Connection state for the endpoint. This state shall be one of the following: Null, Initiated, Alerting, Connected, Hold, Failed, Queued. The positive acknowledgement also may include the following parameter for one or more endpoints in the call: 4. Device Profile - shall indicate the Device Profile associated with the device. The positive acknowledgement also may include one or more of the following parameters: 5. CSTA Private Data Information. 6. CSTA Security Service Information.
11.5.2.2
Negative acknowledgement The negative acknowledgment shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
11.5.3
Functional description The Snapshot Call Service is intended to provide information about calls that makes further monitoring more meaningful. For example, if a CSTA application were to start working with a call, the Event Reports needed to provide synchronization may not occur for some time. To facilitate operations before an Event Report is available to synchronize the monitor, it is necessary to be able to query the current state of CSTA objects. Snapshot Call Service provides that function. Snapshot Call Service obtains current call status and returns it in a response. This does not affect the states of any objects in the Switching Function.
- 113 -
11.6
Snapshot Device Service Snapshot Device Service shall provide information about calls associated with a given CSTA device. The information provided shall be sufficient to identify each call and indicate each call’s local connection state.
11.6.1
Service Request The Snapshot Device Service Request shall include the following parameter: 1. CSTA Device Identifier - shall indicate the device to be snapshot. The request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
11.6.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
11.6.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameters for each call at the device and also may include the Device Profile parameter for each call at the device: 1. CSTA Connection Identifier - shall indicate the call and, for some implementations, the device’s dynamically-assigned Device Identifier for the call. 2. CSTA Connection States - shall be a list of the states of the Connections of the call identified in parameter 1 and the snapshot device. This list shall provide either the local Connection state or an overall call state. The call state may be provided as a sequence of Connection states unless that sequence is the equivalent of a CSTA defined call state. If the call state is one of the CSTA defined states, then the entire state shall be provided as a composite call state rather than a sequence of individual states. Sub-clause 6.1.5, Call states, contains additional information on Call states. 3. Device Profile - shall indicate the Device Profile associated with the call. The positive acknowledgement also may include one or more of the following parameters: 4. CSTA Private Data Information. 5. CSTA Security Service Information.
11.6.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
11.6.3
Functional description The Snapshot Device Service is intended to provide information about devices to make further monitoring more meaningful. For example, when a CSTA application starts working with a device, the Event Reports needed to provide synchronization may not occur for some time. To facilitate operations before Event Reports synchronize the monitor, it is necessary to be able to query the current state of CSTA objects. Snapshot Device Service provides that function. Snapshot Device Service obtains current device status and returns it in a response. This does not affect the states of any objects in the Switching Function.
- 114 -
12
Computing Function Services
12.1
Re-Route Service The Re-Route Service shall request an alternate destination from the one provided by a previous Route Select Service and based on previous information provided for the call.
12.1.1
Service Request The Re-Route Service Request shall include the following parameter: 1. CSTA Cross Reference Identifier - shall indicate the set of routeing Services that are used for a particular call. The Re-Route Service Request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
12.1.2
Service Response The server shall not give positive acknowledgement to the Re-Route Service Request. However, the server may provide a negative acknowledgement of the Service Request. The requested route shall be provided via a Route Select Service message sent from the server to the client.
12.1.2.1
Positive acknowledgement This Service shall not have a positive acknowledgement.
12.1.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
12.1.3
Functional description The requested route is sent from the Computing Function to the Switching Function by the Route Select Service. The client is expected to use the Cross Reference Identifier generated by the initial Route Request Service to link this Service to the others that are used to provide a route.
- 115 -
12.2
Route End Service The Route End Service shall end a routeing dialogue. It may be invoked by the client or server.
12.2.1
Service Request The Route End Service Request shall include the following parameter: 1. CSTA Cross Reference Identifier - shall indicate the set of routeing Services that are used for a particular call. This CSTA Cross Reference Identifier instance shall become invalid. The request also may include one or more of the following parameters: 2. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions. 3. CSTA Private Data Information. 4. CSTA Security Service Information. The server verifies that the Service Request is correct and may notify the client application in order to acknowledge or reject the Service Request.
12.2.2
Service Response The server shall not give positive acknowledgement to the Route End Service Request. However, the server may provide negative acknowledgement of the Service Request.
12.2.2.1
Positive acknowledgement This Service shall not provide a positive acknowledgement.
12.2.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
12.2.3
Functional description The Route End Service may be invoked by the Switching Function when a call has been successfully routed, cleared, or when the Computing Function has failed to provide a route within a time limit. It can also be provided by the Computing Function to indicate that no (more) routes are (currently) available for the requested destination.
- 116 -
12.3
Route Request Service The Route Request Service shall request a destination for a call. To aid in the selection of a destination, the Service Request shall include the current destination and may include additional information.
12.3.1
Service Request The Route Request Service Request shall include the following parameters: 1. CSTA Cross Reference Identifier - shall indicate the set of routeing Services that are used for a particular call. 2. Current Route - shall indicate the current destination of the call for which a route is requested. The Route Request Service Request also may include one or more of the following parameters: 3. Calling Device - shall indicate the originator of the call. 4. Routing Device - shall indicate the device which initiated the Route Request Service. NOTE 11 Route requests may be made by the Switching Function without the involvement of a particular device. Additionally, the device may request routes with a call in any state - including Null. 5. CSTA Connection Identifier - shall indicate the CSTA Call Identifier. 6. Route Selection Algorithm - shall indicate the type of routeing algorithm requested. This parameter may have the following values: ACD - shall indicate that the route should be selected using an algorithm that distributes calls to multiple devices. Emergency - shall indicate that the call is emergency and a suitable route should be selected. Least Cost - shall indicate that a route costing the least among the available routes should be provided. Normal - shall indicate that a default route is requested. User Defined - shall indicate an application-defined routeing algorithm. 7. Priority - shall indicate the call’s priority. This may affect selection of alternative routes. 8. Device Profile - shall contain an ISDN Device Profile for the calling device. 9. CSTA Application Correlator Data - shall provide application-specific data associated with the call. 10. CSTA Private Data Information. 11. CSTA Security Service Information.
12.3.2
Service Response The server shall not give positive acknowledgement to the Service Request. However, the server may provide a negative acknowledgement of the Service Request. The requested route shall be provided via a Route Select Service sent from the server to the client.
12.3.2.1
Positive acknowledgement This Service shall not provide a positive acknowledgement.
12.3.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
12.3.3
Functional description If the information in the request is invalid, the Service Request may be negatively acknowledged. The requested route is sent from the Computing Function to the Switching Function by the Route Select Service. The client is expected to generate the Cross Reference Identifier to link this Service to the others that are used to provide a route.
- 117 -
12.4
Route Select Service The Route Select Service shall provide the client with a destination requested by a previous Route Request or ReRoute Service.
12.4.1
Service Request The Route Select Service Request shall include the following parameters: 1. CSTA Cross Reference Identifier - shall indicate the set of routeing Services that are used for a particular call. 2. Route Selected - shall indicate the selected destination of the call for which a route was requested. The request for the Route Select Service also may include one or more of the following parameters: 3. Device Profile - shall indicate the Device Profile of the called destination. 4. Remaining Retries - shall indicate the number of alternative routes remaining. This element may have a special value that shall indicate that the server does not keep count, or that there is no fixed list. 5. Route Used Request - shall indicate a request to receive a Route Used Service after providing the route. 6. CSTA Application Correlator Data - shall contain information supplied by the application. 7. CSTA Private Data Information. 8. CSTA Security Service Information.
12.4.2
Service Response The server shall not provide positive acknowledgement of the Service Request. However, the server may provide a negative acknowledgement. The Route Select Service shall be completed via a Route End Service initiated by either the server or client.
12.4.2.1
Positive acknowledgement This Service shall not provide a positive acknowledgement.
12.4.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
12.4.3
Functional description The requested destination is provided by the Route Select Service. The client is expected to use the Cross Reference Identifier generated by the original Route Request Service to link this Service to the others that are used to provide a route.
- 118 -
12.5
Route Used Service The Route Used Service shall provide the actual destination for a call that has been routed using the Route Select Service with its optional parameter that requests the route that was used.
12.5.1
Service Request The Route Used Service Request shall include the following parameters: 1. CSTA Cross Reference Identifier - shall indicate the set of routeing Services that are used for a particular call. 2. Route Used - shall indicate the selected destination of the call for which a route was requested. The request also may include one or more of the following parameters: 3. Calling Device - shall indicate the originator of the call. 4. Domain - shall indicate whether the resolved endpoint is within the CSTA switching sub-domain or whether the call has been routed outside the CSTA switching sub-domain. 5. CSTA Application Correlator Data - shall contain information previously supplied by the application. 6. CSTA Private Data Information. 7. CSTA Security Service Information.
12.5.2
Service Response The server shall not provide positive acknowledgement of the Service Request. However, the server may provide a negative acknowledgement. The Route Used Service shall be completed via a Route End Service sent by either the server or client.
12.5.2.1
Positive acknowledgement This Service shall not provide a positive acknowledgement.
12.5.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
12.5.3
Functional description The Route Used Service can be used to inform the server of the route that the client selected. Often the route returned by the server is altered by Forwarding or Do Not Disturb features, or is resolved by an ACD from the pilot to a particular agent.
- 119 -
13
Bi-directional Services
13.1
Escape Service The Escape Service shall allow an implementation, using CSTA protocol and defined CSTA Services, to provide services that are not defined by this Standard. The Escape Service shall use Object Identifiers, as described in ASN.1 (see CCITT Recommendations X.208/X.209, ISO International Standards ISO/IEC 8824 / ISO/IEC 8825).
13.1.1
Service Request The Escape Service Request shall contain the following parameter: 1. CSTA Private Data Information. The Service Request also may include the following parameter: 2. CSTA Security Service Information.
13.1.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
13.1.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
13.1.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
13.1.3
Functional description While most common switching and computing Services required by CSTA are standardized, there is a need to be able to “escape” from standard operations in order to exploit some special feature of a manufacturer’s switch or computer. A mechanism is also needed to allow manufacturers to experiment with new services that may, at a later date, become standardized. If the server can perform the requested service it will do so using the Private Data provided.
- 120 -
13.2
System Status Service The System Status Service shall report the status of the switching or computing system.
13.2.1
Service Request The System Status Service Request shall contain the following parameter: 1. Cause - shall indicate the reason for the System Status Service request. The cause shall be one or more of the following: Disabled - shall indicate that existing Monitor Requests have been disabled. Other Requests and Responses also may be disabled, but reject responses shall always be provided. Enabled - shall indicate that Requests and Responses have been enabled. This usually occurs after a disruption or restart. This status cause shall always be sent after an Initializing cause has been sent and may be sent under other conditions. This status shall indicate that there are no outstanding monitor requests. Initializing - shall indicate that the system is initializing or restarting. This status shall indicate that a system is temporarily unable to respond to any requests. If provided, this status message shall be followed by an Enable status message to indicate that the Init process has completed. Messages Lost - shall indicate that Requests and/or Responses, including Event Reports, may have been lost. Normal - may be sent at any time and shall indicate that the status is normal. This status has no effect on other Services. Overload Imminent - shall indicate that the receiver is requested to take initiative to shed load. Overload Reached - shall indicate that the requester may take initiative to shed load. This cause may be followed by Stop Monitor requests sent to the client and by rejections to additional Service Requests. Overload Relieved - shall indicate that the overload condition has passed. The Service Request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
13.2.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
13.2.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
13.2.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
13.2.3
Functional description The System Status Service performs no action other than informing.
- 121 -
14
Input / Output (I/O) Services Input/Output Services allow computer applications to provide users with enhanced capabilities by exploiting the characteristics of telephony devices. Input/Output Services provide this by interacting with Data Paths that are associated with telephony devices and that allow input to be received from these devices and output to be sent to the devices.
14.1
Data Path Resumed The Data Path Resumed Service shall provide information that a previously suspended Data Path has been resumed.
14.1.1
Service Request The Service Request shall include the following parameter: 1. CSTA Cross Reference Identifier - shall indicate the set of I/O Services that are used for a particular Data Path, and whether the Computing Function or Switching Function started the Data Path. The Service Request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
14.1.2
Service Response The server may provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
14.1.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
14.1.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
14.1.3
Functional description This Service allows the Switching Function to inform the Computing Function that the Switching Function has resumed a previously suspended Data Path.
- 122 -
14.2
Data Path Suspended The Data Path Suspended Service shall provide information that a Data Path has been suspended.
14.2.1
Service Request The Service Request shall include the following parameters: 1. CSTA Cross Reference Identifier - shall indicate the set of I/O Services that are used for a particular Data Path, and whether the Computing Function or Switching Function started the Data Path. The Service Request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
14.2.2
Service Response The server may provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
14.2.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
14.2.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
14.2.3
Functional description This Service allows the Switching Function to inform the Computing Function that the Switching Function has suspended the Data Path. Resume Data Path may then be used to resume the flow of data on the Data Path. The following figure is provided to help explain concepts associated with CSTA Data Paths and I/O Services. The figure illustrates a possible CSTA configuration involving a Data Path from/to a CSTA object through the Switching Function. The Data Path is established via a Start Data Path Service Request issued (commonly) by the Computing Function. If the Switching Function temporarily stops the data flow (without eliminating the Data Path on which the data was flowing), it can inform the Computing Function via the Data Path Suspended Service. The Switching Function might invoke this Service when it has honoured a Suspend Data Path request issued by the Computing Function. The Switching Function might also issue the Data Path Suspended Service without any prior Suspend Data Path request from the Computing Function.
- 123 -
data path
text data
Switch
data path
Send data voice data
Suspend or
Data path suspended
Resume data path
resumed
or
Computer
Figure 41 - I/O Services Illustration
- 124 -
14.3
FastData The FastData Service shall start a Data Path for only the duration of sending one data message. It is functionally similar to the sequence of Service Requests: “Start Data Path, Send Data, Stop Data Path”. To send objectdependent data (e.g. to present information on a device’s display) via the FastData Service, CSTA applications must know the characteristics of the target object. The FastData Service shall be bi-directional so FastData messages may be initiated by the Switching Function or by the Computing Function.
14.3.1
Service Request The FastData Service Request shall include the following parameter: 1. Object-Identifier - shall indicate the object to which a Data Path should be initiated. Possible objects are: CSTA Device - shall identify, using the CSTA Device Identifier, the device upon which the Data Path is to be started. On a multi-line voice-terminal this shall be the Device Identifier of the voice-terminal. CSTA Call - shall identify, using the CSTA Connection Identifier, the call upon which the Data Path is to be started. 2. Data - shall provide the data to be sent. The Service Request also may include one or more of the following parameters: 3. Data Path type - shall identify the data-type of the Data Path. It may be: • text - a digitally encoded text stream, or • voice - a digitally encoded voice stream. 4. CSTA Private Data Information. 5. CSTA Security Service Information.
14.3.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
14.3.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
14.3.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
14.3.3
Functional description This Service transfers data between the client and the server.
- 125 -
14.4
Resume Data Path This Service shall request the switch to resume a currently-suspended Data Path.
14.4.1
Service Request The Resume Data Path Service Request shall include the following parameters: 1. CSTA Cross Reference Identifier - shall indicate the set of I/O Services that are used for a particular Data Path, and whether the Computing Function or Switching Function started the Data Path. The Service Request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
14.4.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
14.4.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
14.4.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
14.4.3
Functional description The computer may use this Service to request that the switch resume a suspended Data Path.
- 126 -
14.5
Send-Broadcast-Data The Send-Broadcast-Data Service shall write to all open Data Paths for a given application association and Data Path type.
14.5.1
Service Request The Send-Broadcast-Data Service Request shall include the following parameter: 1. Data - shall provide the data to be sent. The Service Request also may include one or more of the following parameters: 2. Data Path type - shall specify the Data Path type of the Data Paths on which data should be sent. 3. CSTA Private Data Information. 4. CSTA Security Service Information.
14.5.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
14.5.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
14.5.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
14.5.3
Functional description This Service transfers data from the computer to all CSTA objects for which an appropriate Data Path exists. The response to this Service Request only indicates that the Request was received correctly, that none of the enumerated error conditions has been encountered and that processing of the data is proceeding on the assumption that the data is otherwise correct. To send object-dependent data (e.g. to present information on a device’s display) via the Send-Broadcast-Data Service, CSTA applications must know the characteristics of the target object. This service may be used, for example, to send information to all video displays and audio channels.
- 127 -
14.6
Send Data The Send Data Service shall write data to a specified Data Path. It shall be a bi-directional Service.
14.6.1
Service Request The Send Data Service Request shall include the following parameters: 1. CSTA Cross Reference Identifier - shall indicate the set of I/O Services that are used for a particular Data Path, and whether the Computing Function or Switching Function started the Data Path. 2. Data - shall provide the data to be sent. The Service Request also may include one or more of the following parameters: 3. CSTA Cause - shall specify the reason why data has been sent. It shall be one of the cause codes specified in 11.2.10, Cause codes. 4. CSTA Private Data Information. 5. CSTA Security Service Information.
14.6.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
14.6.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
14.6.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
14.6.3
Functional description This Service transfers data between the client and the server. The response to this Service Request only indicates that the Request was received correctly, that none of the enumerated error conditions have been encountered and that processing of the data is proceeding on the assumption that the data is otherwise correct. To send object-dependent data (e.g. to present information on a device’s display) via the Send Data Service, CSTA applications must know the characteristics of the target object. This Service may, for example, be used to send information to a display or an audio channel.
- 128 -
14.7
Send-Multicast-Data The Send-Multicast-Data Service shall write to multiple Data Paths.
14.7.1
Service Request The Send-Multicast-Data Service Request shall include the following parameters: 1. CSTA Cross Reference Identifier - shall indicate the set of I/O Services that are used for a particular Data Path, and whether the Computing Function or Switching Function started the Data Path. This parameter is repeated for each Data Path that should receive the data. 2. Data - shall provide the data to be sent. The Service Request also may include one or more of the following parameters: 3. CSTA Private Data Information. 4. CSTA Security Service Information.
14.7.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
14.7.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
14.7.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
14.7.3
Functional description This Service transfers data from a Computing Function to one or more CSTA objects. The response to this Service Request only indicates that the Request was received correctly, that none of the enumerated error conditions has been encountered and that processing of the data is proceeding on the assumption that the data is otherwise correct. To send object-dependent data (e.g. to present information on a device’s display) via the Send-Multicast-Data Service, CSTA applications must know the characteristics of the target objects. This Service may be used, for example, to send information to multiple displays and audio channels.
- 129 -
14.8
Start Data Path The Start Data Path Service shall start a Data Path on the specified object. It shall be a bi-directional Service.
14.8.1
Service Request The Start Data Path Service Request shall include the following parameter: 1. Object-Identifier - shall indicate the object to which a Data Path should be initiated. Possible objects are: CSTA Device - shall identify, using the CSTA Device Identifier, the device upon which the Data Path is to be started. On a multi-line voice-terminal this must be the device identifier of the voice-terminal. CSTA Call - shall identify, using the CSTA Connection Identifier, the call upon which the Data Path is to be started. The Service Request also may include one or more of the following parameters: 2. Data Path direction - shall identify that the Data Path to be started is: • from the Computing Function to the identified object, or • from the identified object to the Computing Function, or • bi-directional between the Computing Function and the identified object. 3. Data Path type - shall identify the data-type of the Data Path. It may be: • text - a digitally encoded text stream (including, for example, characters collected as part of DTMF data collection), or • voice - a digitally encoded voice stream. Data Collection parameters: 4. Number of characters to collect - shall specify the number of characters to collect before sending collected characters on the Data Path. 5. Termination character - shall specify a character that, if received, will cause the switch to send collected characters on the Data Path. 6. Timeout - shall specify a duration in seconds such that characters will be sent on the Data Path. 7. CSTA Private Data Information. 8. CSTA Security Service Information.
14.8.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
14.8.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameter: 1. CSTA Cross Reference Identifier - shall indicate a value that is unique within the association for the duration of the Data Path. It may be used to correlate subsequent operations (e.g. Resume Data Path, Stop Data Path) for this Data Path. It shall also indicate whether the Computing Function or Switching Function started the Data Path. The positive acknowledgement may include one or more of the following parameters: Data Collection Parameters: 2. Number of characters to collect - shall specify the number of characters to collect before sending collected characters on the Data Path. 3. Termination character - shall specify a character that, if received, will cause the switch to send collected characters on the Data Path. 4. Timeout - shall specify a duration in seconds such that characters will be sent on the Data Path.
- 130 -
5. CSTA Private Data Information. 6. CSTA Security Service Information. 14.8.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
14.8.3
Functional description Starting a device’s Data Path means that the computer has requested control of the device either on its own initiative or at the request of a device user. When an Input/Output application that has a Data Path association with a device is invoked, a Data Path may be started by the switch prior to informing the computer of an invocation request. Whether or not this “automatic starting” of a Data Path occurs depends upon switch application administration programming. If the switch can provide the requested Data Path, the Start Data Path Service causes the Data Path to be both started and immediately resumed. If another application is using the voice-terminal the request may be denied. If a termination condition, as specified in the Data Collection Parameters, is encountered, then data is returned to the requesting client and data collection continues until the termination condition is encountered again or the Data Path is explicitly stopped.
- 131 -
14.9
Stop Data Path The Stop Data Path Service shall terminate a Data Path. It is not necessary for a Data Path to be resumed for this Service to be carried out. It shall be a bi-directional Service.
14.9.1
Service Request The Stop Data Path Service Request shall include the following parameter: 1. CSTA Cross Reference Identifier - shall indicate the set of I/O Services that are used for a particular Data Path, and whether the Computing Function or Switching Function started the Data Path. The Service Request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
14.9.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
14.9.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
14.9.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
14.9.3
Functional description The Stop Data Path Service terminates a Data Path session.
- 132 -
14.10
Suspend Data Path The Suspend Data Path Service shall suspend a specified Data Path but shall not destroy the Data Path. The Suspend Data Path Service Request may be sent by either user of a Data Path.
14.10.1
Service Request The Suspend Data Path Service Request shall include the following parameter: 1. CSTA Cross Reference Identifier - shall indicate the set of I/O Services that are used for a particular Data Path, and whether the Computing Function or Switching Function started the Data Path. The Service Request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
14.10.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
14.10.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
14.10.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
14.10.3
Functional description The sender informs its peer that the Data Path should be suspended, but not destroyed. Resume Data Path may then be used to resume the flow of data on the Data Path. This Service allows the consumer of the Data Path to start and stop the flow of data. It is expected that no flow control of the data that has been suspended will occur. That is, if a Data Path is suspended the consumer is not provided with the data between the time the Data Path was suspended and the time it was resumed.
- 133 -
15
Voice Unit Services The Voice Unit is an example (subclass) of a Special Resource Function (SRF) introduced in the modelling clauses of this Standard. These Services have been developed specifically for voice, but it is recognized that they could be used for other media, such as fax or video. The model represented in figure 8 illustrates the relationships among the following Services. The interface to the Voice Unit provides the following Services to manipulate voice messages stored in the Voice Unit.
15.1
Concatenate Message Concatenate Message shall combine multiple messages, in the sequence provided, into a single resulting message. The messages that form the concatenated message shall not be deleted or otherwise changed. This Service shall provide a unique Message Identifier for the concatenated message that shall remain valid until the concatenated message is deleted.
15.1.1
Service Request The Concatenate Message Service Request shall contain two or more instances of the following parameter: 1. Message Identifier - shall indicate message to be concatenated. The Service Request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
15.1.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
15.1.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameter: 1. Message Identifier - shall indicate the resulting concatenated message. The positive acknowledgement may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
15.1.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
15.1.3
Functional description The Concatenate Message Service causes the Voice Unit to concatenate specified messages into a single new message, the Message Identifier of which is returned in the Service Response. The original messages are preserved by this function. If it is not desired to retain the messages that are used to create the new message, the Delete Message Service can be used. The Message Identifier returned by this Service is valid until the new message formed by the concatenation is deleted.
- 134 -
15.2
Delete Message Delete message shall delete a specified voice message.
15.2.1
Service Request The Delete Message Service Request shall contain the following parameter: 1. Message Identifier - shall indicate the message to be deleted. The Service Request also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
15.2.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
15.2.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
15.2.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
15.2.3
Functional description The Delete Message Service causes the Voice Unit to delete a specified message.
- 135 -
15.3
Play Message The Play Message Service shall cause the Voice Unit to start playing a voice message on a particular Connection. Play Message may play a second message on a Connection that has a currently-suspended message. However, it shall not play the same message over the same Connection. If the Duration parameter is set to zero, then the message will go immediately to the Suspend Play State.
15.3.1
Service Request The Play Message Service Request shall contain the following parameters: 1. Message Identifier - shall indicate the message to be played. 2. CSTA Connection Identifier - shall indicate the Connection on which the message is to be played. The Service Request also may include one or more of the following parameters: 3. Duration - time of message to play in milliseconds. 4. Termination Conditions - mask of actions that will cause playback to terminate. 5. CSTA Private Data Information. 6. CSTA Security Service Information.
15.3.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
15.3.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
15.3.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
15.3.3
Functional description The Play Message Service causes the Voice Unit to start playing a designated message until the reception of a valid Stop Service Request or Suspend Service Request or until the end of the message is detected. Not allowing the same Message Identifier twice ensures that the Message Identifier remains unique for all messages associated with a particular voice path / Connection Identifier. Note that media conversion may be provided in this Service.
- 136 -
15.4
Query Voice Attribute The Query Voice Attribute Service shall access and report current value of a specified voice attribute for a specified Message.
15.4.1
Service Request The Query Voice Attribute Service Request shall contain the following parameters: 1. Message Identifier - shall indicate the message whose attribute should be queried. 2. Attribute - shall indicate the attribute to be queried. This parameter shall have one of the following values if parameter 3 (Connection Identifier) is not provided: Encoding algorithm - shall request the encoding algorithm used for the specified message. Sampling Rate - shall request the sampling rate used for the specified message. Duration - shall request the duration of the specified message. File Name - shall request the file name of the specified message. If parameter 3 (Connection Identifier) is provided, then parameter 2 (Attribute) shall have any one of the four above-listed values or any one of the following five values: Current Position - shall request the current position in the message. If requested, this attribute will be reported in milliseconds from the beginning of the specified message. Current Speed - shall request the current playing speed of the specified message. If requested, this reported value shall represent percentage of normal speed, with 100% being normal speed and the slowest reportable speed being 1%. Current Volume - shall request the current playing volume of the specified message. If requested, the reported value shall be an integer from 0 to 100, with 100 indicating maximum volume and 0 indicating minimum volume. Current Level - shall request the current recording level of the specified message. If requested, the reported value shall be an integer from 0 to 100, with 100 indicating maximum level and 0 indicating minimum level. Current State - shall request the current state of the specified message. The reported value shall indicate one of the following states: Stop Play Record Suspend Play Suspend Record Review The Service Request also may include one or more of the following parameters: 3. CSTA Connection Identifier - shall indicate the Connection of the message whose attribute is being queried. 4. CSTA Private Data Information. 5. CSTA Security Service Information.
15.4.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
15.4.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameter: 1. Attribute - shall indicate the value of the requested attribute.
- 137 -
The positive acknowledgement also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information. 15.4.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
15.4.3
Functional description The Query Voice Attribute Service gets the value of a specified voice attribute of the current message.
- 138 -
15.5
Record Message The Record Message Service shall start recording a voice message from a specified Connection.
15.5.1
Service Request The Record Message Service Request shall contain the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection from which the message is to be recorded. The Service Request also may include one or more of the following parameters: 2. Sampling Rate - shall specify the sampling rate to be used when recording. 3. Encoding Algorithm - shall specify the encoding algorithm to be used during recording. 4. Maximum Duration - shall specify, in milliseconds, the maximum message time to record. 5. Termination Conditions - shall specify, via a mask, the actions that will cause recording to terminate. 6. CSTA Private Data Information. 7. CSTA Security Service Information.
15.5.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
15.5.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameter: 1. Message Identifier - shall indicate the message to be recorded. The positive acknowledgement also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
15.5.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
15.5.3
Functional description The Record Message Service provides a Message Identifier in the positive acknowledgement and causes the Voice Unit to begin recording from a specified Connection. If the sampling rate or encoding algorithm are not specified or cannot be provided, then the Voice Unit may use its default sampling rate and/or encoding algorithm.
- 139 -
15.6
Reposition The Reposition Service shall move the current position pointer forward or backward a specified number of milliseconds in a message. It shall also allow setting the position pointer to the start or to the end of the message.
15.6.1
Service Request The Service Request shall contain the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection on which the message is present. 2. Period - shall indicate the number of milliseconds to move forward or backward. A positive period moves forward (toward the end of the message); a negative period moves backward. It also may have a value indicating "Beginning of Message" and a value indicating "End of Message". The Service Request also may include one or more of the following parameters: 3. Message Identifier - shall indicate the message to reposition. 4. CSTA Private Data Information. 5. CSTA Security Service Information.
15.6.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
15.6.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
15.6.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
15.6.3
Functional description The Reposition Service shall cause the Voice Unit to reposition the message pointer according to the number of milliseconds indicated in the period of the request. Moving forward and backward within the indicated message on the indicated Connection is accomplished by using, respectively, positive or negative values for the period.
- 140 -
15.7
Resume The Resume Service shall restart the playing or recording of a previously suspended message at the current position.
15.7.1
Service Request The Resume Service Request shall contain the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection from which the message is to be resumed. The Service Request also may include one or more of the following parameters: 2. Message Identifier - shall indicate the message to be resumed. 3. Duration - shall indicate the maximum duration of playback or recording. 4. CSTA Private Data Information. 5. CSTA Security Service Information.
15.7.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
15.7.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
15.7.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
15.7.3
Functional description The Resume Service causes the Voice Unit to resume playing or recording a previously suspended message at the current position. The current position in the message may have been changed by using the Reposition Service.
- 141 -
15.8
Review The Review Service shall play a portion of a voice message during a recording session. When this Service completes, the Voice Unit shall return the message to the Suspend/Record state in its recording process. This shall not affect the current position unless a Suspend occurs before the review completes.
15.8.1
Service Request The Service Request shall contain the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection on which the message is present. 2. Period - shall indicate the number of milliseconds to move backward and start reviewing. It also may have a value indicating "Beginning of Message". The Service Request also may include one or more of the following parameters: 3. Message Identifier - shall indicate the message to review. If not provided, then the current message shall be used. 4. CSTA Private Data Information. 5. CSTA Security Service Information.
15.8.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
15.8.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
15.8.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
15.8.3
Functional description The Review Service will cause the Voice Unit to play the specified number of milliseconds before the current position in the currently-suspended, recorded message. When playback stops, the message will be at the same point it was when recording stopped. This allows recording to continue from the point at which it was interrupted.
- 142 -
15.9
Set Voice Attribute The Set Voice Attribute Service shall set a voice attribute for a specified Connection and message.
15.9.1
Service Request The Set Voice Attribute Service Request shall contain the following parameters: 1. CSTA Connection Identifier - shall indicate the Connection on which the voice attribute should be set. 2. Attribute - shall indicate the attribute to be set. This parameter shall have one of the following values: Speed - shall set the playing speed. If requested, this reported value shall represent percentage of normal speed, with 100% indicating normal speed and the slowest reportable speed being 1%. Volume - shall set the playing volume. The value shall be an integer from 0 to 100, with 100 indicating maximum volume and 0 indicating minimum volume. Level - shall set the recording level. The value shall be an integer from 0 to 100, with 100 indicating maximum level and 0 indicating minimum level. The Service Request shall include the following parameter if there is more than one active message on the specified Connection. If there is only one active message on this Connection, then the following parameter may be sent. 3. Message Identifier - shall indicate the message whose attribute is being set. If this parameter is not provided, then the attribute of the currently-active message on the specified Connection shall be set. The Service Request also may include one or more of the following parameters: 4. CSTA Private Data Information. 5. CSTA Security Service Information.
15.9.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
15.9.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
15.9.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
15.9.3
Functional description The Set Voice Attribute Service sets a voice attribute of a specified message.
- 143 -
15.10
Stop The Stop Service shall stop the playing or recording of a message and shall reset the position pointer to the beginning of the message.
15.10.1
Service Request The Stop Service Request shall contain the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection to be handled. The Service Request also may include one or more of the following parameters: 2. Message Identifier - shall indicate the message to be stopped. 3. CSTA Private Data Information. 4. CSTA Security Service Information.
15.10.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
15.10.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
15.10.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
15.10.3
Functional description The Stop Service causes the Voice Unit to stop playing or recording a message and will set the position pointer to the beginning of the message.
- 144 -
15.11
Suspend The Suspend Service shall temporarily stop the playing or recording of the current message and shall set a pointer to the current position in the message for later use.
15.11.1
Service Request The Suspend Service Request shall contain the following parameter: 1. CSTA Connection Identifier - shall indicate the Connection on which to suspend playing or recording a message. The Service Request also may include one or more of the following parameters: 2. Message Identifier - shall indicate the message to be suspended. 3. CSTA Private Data Information. 4. CSTA Security Service Information.
15.11.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
15.11.2.1
Positive acknowledgement The positive acknowledgement may include one or more of the following parameters: 1. CSTA Private Data Information. 2. CSTA Security Service Information.
15.11.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
15.11.3
Functional description The Suspend Service causes the Voice Unit to suspend playing or recording a message. While the message is suspended, the current position in the message can be changed by using the Reposition Service. The Voice Unit will continue to play or record the message at its current position in the message upon receiving the Resume Service Request.
- 145 -
15.12
Synthesize Message The Synthesize Message Service shall construct a voice message from a text message and shall return the Message Identifier of the constructed message.
15.12.1
Service Request The Synthesize Message Service Request shall contain the following parameter: 1. Text - shall provide the text to be spoken. The Service Request also may include one or more of the following parameters: 2. Control Information - shall provide the parameters to control the speech synthesis. 3. CSTA Private Data Information. 4. CSTA Security Service Information.
15.12.2
Service Response The server shall provide an acknowledgement of the Service Request. The acknowledgement shall be either positive or negative.
15.12.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameter: 1. Message Identifier - shall indicate the message that was synthesized. The positive acknowledgement also may include one or more of the following parameters: 2. CSTA Private Data Information. 3. CSTA Security Service Information.
15.12.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1. CSTA Error Value - shall be one of the error values provided in 9.4, Diagnostic error definitions.
15.12.3
Functional description This is a “text to speech” function. If the Service Request is accepted, the Voice Unit constructs a voice message respecting the control parameters and returns its Message Identifier.
This Standard ECMA-217 is available free of charge from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Internet:
+41 22 849.60.01 [email protected]
This Standard can also be downloaded as file E217-DOC.EXE or file E217-PSC.EXE from ECMANEWS