Standard ECMA-179 June 1992
Standardizing Information and Communication Systems
Services for Computer Supported Telecommunications Applications (CSTA) Phase I
Ph 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 - UR L : h t t p : / / www. ec m a. c h - I n t e r n e t : h el p d es k @ ec m a. c h
.
Standard ECMA-179 June 1992
Standardizing Information and Communication Systems
Services for Computer Supported Telecommunications Applications (CSTA) Phase I
Ph 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 - UR L : h t t p : / / www. ec m a. c h - I n t e r n e t : h el p d es k @ ec m a. c h IW - Ecma-179.doc - 28.10.96 15:23
.
Brief History
This Standard defines Services for Computer-Supported Telecommunications Applications (CSTA) for OSI Layer 7 communication between a computing network and a telecommunications network. This Standard, plus its companion Standard ECMA-180 Protocol for Computer-Supported Telecommunications Applications, reflects agreements of ECMA member companies on the first phase of 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 its direction from Technical Report ECMA TR/52 Computer-Supported Telecommunications Applications.
Adopted as an ECMA Standard by the General Assembly of June 1992.
.
-i-
Table of contents Page 1
Scope and field of application
1
2
Conformance
1
3
References
1
4
Definitions and acronyms
2
4.1
CSTA specific definitions 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 4.1.7 4.1.8 4.1.9 4.1.10 4.1.11 4.1.12 4.1.13 4.1.14 4.1.15 4.1.16 4.1.17 4.1.18 4.1.19 4.1.20 4.1.21 4.1.22 4.1.23 4.1.24 4.1.25 4.1.26 4.1.27 4.1.28 4.1.29 4.1.30 4.1.31 4.1.32
4.2
Terms defined elsewhere 4.2.1 4.2.2
4.3
ACD Agent Active Call Agent Alerting Call Application Application Domain Basic Call Call Complex Call Computing Domain Computing Function Computing Sub-domain Connection Connection Identifier Device Directory Number Domain Event Event Report Held Call Interconnection Service Boundary Object Party Security Security Service Service Service Boundary State Switching Domain Switching Function Switching Sub-domain User
Acronyms
Terms defined in ECMA TR/46 Terms defined in ISO
2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 5
- ii -
5
Functional architecture 5.1 5.2 5.3 5.4
6
Distribution of Computing and Switching Functions CSTA Service Per-Service Client/Server Model Service and Objects
CSTA operational model 6.1
Switching sub-domain model 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5
6.2
5 5 6 7 8 8 8
Device Call Connection Call Event Reports Call states
9 11 11 13 14
Dynamic identifier management
15
7
Security Service
16
8
Generic Service requirements
16
8.1 8.2 8.3 8.4
Service Request Service Response Functional description Diagnostic error definitions 8.4.1 8.4.2 8.4.3 8.4.4 8.4.5 8.4.6 8.4.7 8.4.8
9
Operation errors Security errors State incompatibility errors System resource availability errors Subscribed resource availability errors Performance management errors Unspecified errors CSTA private data information errors
Switching Function Services 9.1
Alternate Call Service 9.1.1 9.1.2 9.1.3
9.2
Answer Call Service 9.2.1 9.2.2 9.2.3
9.3
Service Request Service Response Functional description
Service Request Service Response Functional description
Call Completion Service 9.3.1 9.3.2 9.3.3
Service Request Service Response Functional description
16 16 17 18 18 19 20 20 20 21 21 21 21 21 21 21 22 22 22 22 22 23 23 23 23
- iii -
9.4
Clear Call Service 9.4.1 9.4.2 9.4.3
9.5
Clear Connection Service 9.5.1 9.5.2 9.5.3
9.6
Service Request Service Response Functional description
Hold Call Service 9.9.1 9.9.2 9.9.3
9.10
Service Request Service Response Functional description
Divert Call Service 9.8.1 9.8.2 9.8.3
9.9
Service Request Service Response Functional description
Consultation Call Service 9.7.1 9.7.2 9.7.3
9.8
Service Request Service Response Functional description
Conference Call Service 9.6.1 9.6.2 9.6.3
9.7
Service Request Service Response Functional description
Service Request Service Response Functional description
Make Call Service 9.10.1 Service Request 9.10.2 Service Response 9.10.3 Functional description
9.11
Make Predictive Call Service 9.11.1 Service Request 9.11.2 Service Response 9.11.3 Functional description
9.12
Query Device Service 9.12.1 Service Request 9.12.2 Service Response
9.13
Reconnect Call Service 9.13.1 Service Request 9.13.2 Service Response 9.13.3 Functional description
9.14
Retrieve Call Service 9.14.1 Service Request
23 23 24 24 24 24 25 25 25 25 26 26 26 26 27 27 27 27 28 28 28 28 28 29 29 29 29 30 30 30 30 31 31 31 32 33 33 33 34 34 34
- iv -
9.14.2 Service Response 9.14.3 Functional description 9.15
Set Feature Service
35
9.15.1 Service Request 9.15.2 Service Response 9.16
Transfer Call Service
10 Status Reporting Services Change Monitor Filter Service
Event Report Service
37 37 38 38 38
10.2.1 Service Request 10.2.2 Agent State Event Reports 10.2.2.1 10.2.2.2 10.2.2.3 10.2.2.4 10.2.2.5 10.2.2.6
36 36 37 37
10.1.1 Service Request 10.1.2 Service Response 10.1.3 Functional description 10.2
35 36 36
9.16.1 Service Request 9.16.2 Service Response 9.16.3 Functional description
10.1
34 34
Logged On Logged Off Not Ready Ready Work Not Ready Work Ready
10.2.3 Call Event Reports 10.2.3.1 Call Cleared 10.2.3.2 Conferenced 10.2.3.3 Connection Cleared 10.2.3.4 Delivered 10.2.3.5 Diverted 10.2.3.6 Established 10.2.3.7 Failed 10.2.3.8 Held 10.2.3.9 Network Reached 10.2.3.10 Originated 10.2.3.11 Queued 10.2.3.12 Retrieved 10.2.3.13 Service Initiated 10.2.3.14 Transferred
38 39 39 39 40 40 40 40 41 41 41 42 43 44 45 45 46 47 47 48 49 49 50
10.2.4 Feature Event Reports
51
10.2.4.1 10.2.4.2 10.2.4.3 10.2.4.4
51 51 51 52
Call Information Do Not Disturb Forwarding Message Waiting
-v-
10.2.5 Maintenance Event Reports 10.2.5.1 10.2.5.2
Back In Service Out of Service
10.2.6 Service Response 10.2.7 Functional description 10.2.8 Cause codes 10.3
Monitor Start Service 10.3.1 Service Request 10.3.2 Service Response 10.3.3 Functional description
10.4
Monitor Stop Service 10.4.1 Service Request 10.4.2 Service Response 10.4.3 Functional description
10.5
Snapshot Call Service 10.5.1 Service Request 10.5.2 Service Response 10.5.3 Functional description
10.6
Snapshot Device Service 10.6.1 Service Request 10.6.2 Service Response 10.6.3 Functional description
11 Computing Function Services 11.1
Re-Route Service 11.1.1 Service Request 11.1.2 Service Response 11.1.3 Functional description
11.2
Route End Service 11.2.1 Service Request 11.2.2 Service Response 11.2.3 Functional description
11.3
Route Request Service 11.3.1 Service Request 11.3.2 Service Response 11.3.3 Functional description
11.4
Route Select Service 11.4.1 Service Request 11.4.2 Service Response 11.4.3 Functional description
52 52 53 53 53 53 57 57 58 58 58 59 59 59 59 59 59 60 60 60 60 61 61 61 61 61 61 62 62 62 62 62 62 63 63 63 63 63 64
- vi -
11.5
Route Used Service 11.5.1 Service Request 11.5.2 Service Response 11.5.3 Functional description
12 Bi-directional Services 12.1
Escape Service 12.1.1 Service Request 12.1.2 Service Response 12.1.3 Functional description
12.2
System Status Service 12.2.1 Service Request 12.2.2 Service Response 12.2.3 Functional description
64 64 64 64 64 64 65 65 65 65 65 66 66
1
Scope and field of application This Standard defines Services for the area of Computer-Supported Telecommunications Applications (CSTA). This Standard is focused on the provision of an application service interface between a Switching Function and a Computing Function. The CSTA application interface is intended to be disassociated from the various user-network interfaces or network-network interfaces CSTA applications may serve, observe or manipulate. Because CSTA operates with existing telecommunications interfaces indirectly, it can and does operate generically, so that the differences between various existing interfaces are hidden from CSTA applications. Support of user-to-network interfaces is outside the scope of CSTA. While it is possible for ISDN based networks, e.g. Private Telecommunications Networks (PTNs), to provide support for CSTA applications, there are limitations in both this Standard and current ISDN standards that limit the extent of this support. Enhancements to future PTN and CSTA standards to overcome these limitations are planned for further study. Thus, based upon current standards there can be limitations on the use of PTNs for CSTA users. This Standard covers the individual Services needed to support the CSTA applications described in Technical Report ECMA TR/52 Computer-Supported Telecommunications Applications. It provides an OSI Application Layer Protocol supporting a peer-to-peer relationship between computing and telecommunications networks. Each instance of any Service, and every instance of some types of Services are defined as client-server relationships. This Standard defines Services that allow functional integration between a computing network and a telecommunications network. Computing platforms that support these functionally integrated applications, or Application Programming Interfaces (APIs), are outside the scope of this Standard. Communication between the computing and switching networks may take place via intervening networks which range from a simple point-to-point connection to a local or wide area communications network.
2
Conformance A protocol standard is in conformance with this Standard if the protocol specified by that standard meets all mandatory requirements of clauses 4, 6, and 8, and meets all mandatory requirements of one or more of the following clauses / sections: 7, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9, 9.10, 9.11, 9.12, 9.13, 9.14, 9.15, 9.16, 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 11.1, 11.2, 11.3, 11.4, 11.5, 12.1, 12.2.
3
References ECMA-138
Security in Open Systems - Data Elements and Service Definitions (1989)
ECMA TR/46
Security in Open Systems - A Security Framework (1988)
ECMA TR/52
Computer-Supported Telecommunications Applications (1990)
IS 7498
Information processing Systems - Open Systems Interconnection - Basic Reference Model
IS 8649
Information Processing Systems - Open Systems Interconnection - Association Control Service Element
IS 8824
Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1) (corresponds to CCITT Rec. X.208)
IS 8825
Information Processing Systems - Open Systems Interconnection - Specification of Basic Encoding Rules for ASN.1 (corresponds to CCITT Rec. X.209)
- 2 -
4
IS 10031-1
Information Processing Systems - Textcommunications - Distributed Office Applications Model Part 1: General Model
DIS 9072/1
Information Processing Systems - Text Processing - Remote Operations Part 1: Model, Notation and Service Definition
DIS 9072/2
Information Processing Systems - Text Processing - Remote Operations Part 2: Protocol Specification
Definitions and acronyms For the purposes of this Standard the following definitions apply. 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 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 that is 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 co-operative process between a Switching Function as performed within a switching network and a Computing Function as 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 that relates exactly two associated devices.
4.1.8
Call A Switching Function communications relationship (generally) between two or more devices. During 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 that relates more than two associated devices.
4.1.10
Computing Domain The set of computers and their objects which may be reached directly or indirectly by a CSTA application from a switching domain.
4.1.11
Computing Function That part of the domain needed to support CSTA applications that is within a Computing Network or sub-domain.
- 3 -
4.1.12
Computing Sub-domain Any configuration of inter-connected computers which presents the external appearance and functionality of a single computer to the switching domain.
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 call, device, or a relationship between a call and a device. The CSTA Connection Identifier is comprised of a Call Identifier and a CSTA Device Identifier that uniquely describe a CSTA Object within the context of a CSTA Association.
4.1.15
Device A logical entity and CSTA Object which translates between the actions of a party and the (signalling) information transfer capabilities of the Switching Function. A device can encompass a single endpoint which provides this function, or it can encompass multiple endpoints that act in concert (forming a group) to provide this function.
4.1.16
Directory Number A logical concept that translates to a party or device. It is typically associated with a line circuit.
4.1.17
Domain The union of the switching domain and computing domain.
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 Held state.
4.1.21
Interconnection Service Boundary The abstract service boundary within a system supporting a CSTA Application, separating the communications component of the application from the networking support functions of the system.
4.1.22
Object An abstract entity assumed for modelling purposes to embody some aspect of the externally visible functional characteristics of a physical entity.
4.1.23
Party An entity outside the Switching Function which has the intelligence to use the Switching Function.
4.1.24
Security The characteristics of a system that give it resistance to accidents, failure and misuse, intentional or otherwise.
4.1.25
Security Service A set of operations designed to support some aspect of security in a system.
4.1.26
Service The benefit provided by one CSTA application process to another.
- 4 -
4.1.27
Service Boundary The boundary existing 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.28
State An indication of an object's current condition based on its past events, permitting a prediction of its future behaviour.
4.1.29
Switching Domain The set of switches and their objects which may be reached directly or indirectly by a CSTA application from a computing domain.
4.1.30
Switching Function That part of the domain needed to support CSTA applications implemented within a switching network or sub-domain.
4.1.31
Switching Sub-domain Any configuration of inter-connected switches which presents the external appearance and functionality of a single switch to the computing domain.
4.1.32
User A person, process or piece of equipment that receives direct benefit (e.g. added functionality, improved performance) from the Services provided by the CSTA application.
4.2
Terms defined elsewhere This Standard uses the following terms, defined in other ECMA and ISO publications.
4.2.1
Terms defined in ECMA TR/46 Security Object Security Subject Security Domain Security Policy
4.2.2
Terms defined in ISO IS 7498 Application Layer Application-Process Application-Entity Application-Entity-Title Application-Service-Element IS 8649 Application Context Association Association Control Service Element DIS 9072 Remote Operations IS 10031-1 Client Server
- 5 -
4.3
Acronyms ACD ACSE API ASE ASN BRI CSTA ID ISDN ODP OSI PAC PDU PTN ROSE SIT
5
Automatic Call Distribution Association Control Service Element Application Programming Interface Application Service Element Abstract Syntax Notation Basic Rate Interface Computer-Supported Telecommunications Applications Identifier Integrated Services Digital Network Open Distributed Processing Open Systems Interconnection Privilege Attribute Certificate Protocol Data Unit Private Telecommunications Network Remote Operation Service Element Special Information Tone
Functional architecture This clause summarizes the functional architecture described in TR/52. The objective of CSTA Architecture is to define the interworking mechanisms between Computing and Switching Functions in a way which is independent of their physical implementation. This clause introduces the concepts of distribution of Computing and Switching Functions, CSTA Service, client server model, and CSTA objects as abstracted at a CSTA Service boundary. The CSTA application is supported by a computing component (normally based in the computing network) and a switching component (normally based in the telecommunications network). The operation of these components is defined by one or more interactions between them. 5.1
Distribution of Computing and Switching Functions Typically, the Computing Functions are implemented by one or several computers in a computing network, and the Switching Functions are implemented by one or several switches in a telecommunications network. It is, however, possible for some Computing Functions to be performed within the Switching Function and some Switching Functions within the Computing Function. The CSTA application appears to the user (human or machine) as a single application on a single network, not as two separate functions on two 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 figure 1. From figure 1 it can be seen that the distributed application functions interact with their peers in accordance with a CSTA Service definition. In this Standard, the Service descriptions define these interactions and provide the service interface between the application functionality and the local CSTA Service via which the peer-to-peer service interaction is supported. The 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 of the protocol elements are optional and their use is implementation dependent.
- 6 -
In an OSI environment, the application functions together with the CSTA Service form an application process invocation. The necessary communications component would be provided by an application entity invocation considered to reside in the OSI application layer. The underlying networking support would typically be provided by OSI lower layers.
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 showing the relationship between CSTA Elements in an Open Distributed Processing (ODP) Environment 5.2
CSTA Service In the context of the OSI Reference Model and excluding the Application layer, the word 'service' is used to refer to the benefit provided by one layer to its adjacent higher layer. In the context of the CCITT 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. Figure 2, below, shows, in simplified form, how the OSI layer and CCITT network notions of 'service' relate to one another. OSI layer services have a vertical orientation. CCITT ISDN Basic and Teleservices, as the latter also embrace those of the Application layer, have a horizontal orientation. Unless otherwise qualified, this Standard uses the term 'Service' to refer to the benefit provided by one application layer process to its peer application layer process. CSTA Services have been designed with the intent of being decoupled from the actual Telecommunications Services provided to users by the Switching Function. This makes CSTA independent of the specific userto-network interface of the particular terminals for which CSTA is requesting services, resulting in making the Switching Function responsible for determining how to support a given CSTA request. 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 the existing Standard Telecommunications Service definitions when executing CSTA Services on terminals for which standards exist (e.g. when CSTA requests Hold Call Service for a PTN terminal, the Switching Function will execute that request according to the Supplementary Service Call Hold service description). CSTA has no knowledge of the specific details of how the Switching Function accomplishes requested CSTA Services. The Switching Function does provide an abstraction to the CSTA Service requestor of how the Service is realized.
- 7 -
CSTA Service Boundary
Application Layer Functionality
"Switch" Services
"Computer" Services
Application Layer Functionality
Application Layer
Lower Layer Interconnection System
Figure 2 - Illustrating the OSI and CCITT/CSTA Uses of the Term "Service." 5.3
Per-Service Client/Server Model The communications mechanism (as opposed to the processing) required to support the CSTA application can be modelled as a client/server relationship (such as described in IS 10031-1). A processing component (identified in IS 10031-1 as the User) requests a Service. Its local communications component, termed a 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 scope of CSTA architecture is to provide bi-directional capabilities, the client/server relationship is possible in both directions as depicted in figure 3.
Computing Function
Switching Function Switching Function Service Definition
client
server
CSTA Service Boundary
server
Computing Function Service Definition
client
Figure 3 - Bi-Directional Service Definitions Service definitions in which the Computing Function is the client and the Switching Function is the server are defined as Switching Function Service definitions. An example of a Switching Function Service is the Make Call Service.
- 8 -
Service definitions in which the Switching Function is the client and the Computing Function is the server are defined as Computing Function Service definitions. An example of a Computing Function Service is the Route Request Service. 5.4
Service and Objects The service provided by a server to a client consists of observing and acting upon objects which 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).
6
CSTA operational model This clause summarizes the operational model considered for CSTA. For the purposes of standardization, the definitions and procedures in this clause are normative. The call modelling aspects are informative. The set of accessible Computing and Switching Functions from which an application might receive service defines a CSTA domain. An example of a CSTA Domain is given by figure 4. The CSTA domain is divided into switching and computing domains, which are divided by the heavy line in the figure. Both the switching and computing domains consist of Computing and Switching Functions, which are labelled C1, C2, and C3 for the Computing Functions and S1, S2, and S3 for the Switching Functions. Each function can provide a CSTA application a view of the domain in which it resides. This application view defines a sub-domain. If one or more functions provide an identical view, then they are part of the same sub-domain. CSTA applications encompass at least one switching sub-domain and at least one computing sub-domain, and are represented in figure 4 by the application domains.
Computing Domain
Switching Domain Switching Sub-Domain
Computing Sub-Domain
S1 Application Domains
C1 S2 S3 C2 C3 Computing Sub-Domain
Switching Sub-Domain
Figure 4 - Domains and Sub-Domains 6.1
Switching sub-domain model The Switching sub-domain Model defines the tools needed to provide an abstract view of the Switching Function. This model allows application conceptualization of the Switching Function's operation. To provide this abstract view CSTA defines several CSTA Switching sub-domain Model Objects that can be
- 9 -
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. It does not, however, influence or provide unambiguous information about users of those devices. NOTE 1 This Standard alone cannot claim to support ISDN (or any other) devices because of the additional information required to support such devices in PTNs. For example, in such networks it is possible to have several devices sharing the same network access. Thus the network must be provided with additional information about the call in order to select the appropriate device for the call and allocate the appropriate network resources to the call. The version of CSTA specified in this Standard can not explicitly convey this additional information. Another example, that generally applies 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 only act as a called party -- as 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. The CSTA device can be used to refer to both physical devices (such as buttons, lines, trunks, and stations) and logical devices (such as groups of devices, pilot numbers, and automatic call distributors). Devices shall have a set of attributes, which allow CSTA to monitor and manipulate them. The CSTA attributes of a device shall be: 1.
Device Type
Different types of devices can be used for different purposes and can be manipulated and observed differently within CSTA. A CSTA Device shall be identified as being one of the following types: ACD - Automatic Call Distributor (ACD) is a mechanism that distributes calls within a Switching Function. As an ACD, (as opposed to ACD group) the device consists only of the distribution mechanism and not the devices to which the mechanism can distribute calls. ACD group - Automatic Call Distributor (ACD) group is the mechanism that 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 analog stations often have no physical buttons but behave as if they had one. Some advanced stations can emulate several analog stations, and often represent those stations by several buttons. In some situations it is desirable to identify a given button on a multi-button station. Note that a station with several buttons could have either the same telephone number or different telephone numbers assigned to different buttons. Button group - is two or more instances of a call manipulation point at an individual station. 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.
- 10 -
Operator - is a device that is used to interact with a party to assist in call setup or to provide other telecommunications service. This device is different from other devices in that it is often involved in setting up other calls, and is usually not part of the call after the call is connected. Operator group - two or more operator devices used interchangeably or addressed identically. Station - is the traditional telephone device, either simple or featured. A station is a physical unit of 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. Trunk group - often, many trunks provide connectivity to the same place. These trunks are often placed in groups and accessed using a single identifier. In such a configuration the individual trunks are used interchangeably. 2.
Device Class
Different classes of device can be observed and manipulated differently within CSTA. A CSTA Device shall belong to one and may belong to more than one of the following classes: Data - a device that is used to make digital data calls (both circuit switched and packet switched). This class includes computer interfaces and G4 facsimile machines. Image - a device that is used to make digital data calls involving imaging, or high speed circuit switched data in general. This class includes video telephones and CODECs. Voice - a device that is used to make audio calls. This class includes all normal telephones, as well as computer modems and G3 facsimile machines. Other - a type of device not covered by data, image, or voice. 3.
Device Identifier
Each device that can be observed and/or manipulated needs to be referenced across the CSTA Service boundary. To accomplish this, each requires a device identifier. Devices shall be identified using one or both of the following types of identifiers: CSTA Static Device Identifier - This identifier shall be stable over time. It remains constant and unique between calls, associations and even within the switching sub-domain. The CSTA Static Device Identifier is a form of identifier which is known a priori by both the Computing and Switching Functions. An example of a CSTA Static Device Identifier is an E.164 Directory Number. It is also useful for the Switching Function to convert this identifier to another static form for subsequent use in service interaction. An example of this would be the transformation of a Public Directory Number to 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 transformed number is known as a CSTA Short Form Static Device Identifier. CSTA Dynamic Device Identifier - Once a device has been included in a call, it can be desirable to continue to refer to the instance of the device associated with the call for manipulation or tracking. The CSTA Static Device Identifier may not always be sufficient for this purpose because it may not be available (there is no a priori identifier for the particular device), or because it is too long and cumbersome for efficient use. In these cases the
- 11 -
Switching Function assigns a Dynamic Device Identifier to be used as a reference or handle for the duration of the call. Management of the Dynamic Device Identifier is discussed in 6.2 below. 4.
Device State
The set of Connection states which are associated directly with a particular device. For information about Connection states see 6.1.3 below. 6.1.2
Call Call behaviour, including establishment and release, can be observed and manipulated across the CSTA boundary. During some phases of the call (e.g. establishment and release) the call is not completely formed and there may be only a single device involved (for example, the device that requested the call). 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. In these situations, a CSTA call is maintained as long as the telecommunications relationship remains across each operation. The CSTA call attributes are: 1.
Call Identifier
A Call Identifier shall be allocated to each call by the Switching Function when it 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 refer to all extremities or end points of the call. To allow reference to a nascent call, the call identifier shall be assigned before the 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. This call identifier shall not only reference the entire call within the sub-domain but shall also reference the entire call (all end points) outside the sub-domain that are made visible to CSTA. The CSTA call could 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 these Services the call identifier may change, but the call shall continue as a CSTA object. The management of the call identifier is described in 6.2 below. 2.
Call state
The set of Connection states for those Connections which comprise a call. Call state is returned by the Snapshot Device Service for devices that have calls. Common call states shall be encoded as a single typed value, whereas uncommon call states shall be encoded as a list. For more information on Connection states see 6.1.3 below. Call states are described in more detail in 6.1.5 below. 6.1.3
Connection The Connection is a relationship between a call and a device. Note that this is a different definition from those used by other standards. This relationship is both observed and manipulated. In fact, observation and manipulation of these relationships 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 subdomain and within a single association. If this requirement is maintained, then it is possible to use only a device identifier (or call identifier) to provide the Connection Identifier. Different associations may have different CSTA Connection Identifiers for the same Connection. The definition of this identifier and those it is based on (CSTA Call and Device Identifiers) restricts a CSTA application from fabricating a
- 12 -
Connection Identifier. It cannot use a Connection Identifier until it has received it from the Switching Function. However, by providing additional implementation rules it is possible to allow applications to fabricate unknown Connection Identifiers from known ones. NOTE 2 An example of one possible implementation rule allowing fabrication is: the CSTA Call Identifiers are globally unique within the sub-domain and the device identifiers are CSTA Static Device Identifiers. This rule would allow a CSTA application that was given a Connection Identifier within a monitor to fabricate valid Connection Identifiers for all parts of the call. 2.
Connection State
One of a set of 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. The Connection state refers to a single Call/Device relationship. A simplified Connection state model is given in figure 5.
Null Initiated
Alerting
Failed
Queued
Connected
Held
Figure 5 - Connection State Model In figure 5, the states (circles) presented are the CSTA set. The transitions between states, shown by arrows, show the typical states possible to enter from a given state and form the basis for providing Event Reports when they occur. These states are not equivalent to ISDN access states. They are a derivation of the state machine on one side of an ISDN access. The states are defined as follows: Null - the state where there is no relationship between the call and device. Initiated - the state where the device is requesting service. Usually this results in the creation of a call. Often this is the "dialling" state. Alerting - the state where a device is alerting (ringing). This indicates that a call wishes to become Connected to a device. Connected - the state where a device actively participates in a call. This state includes the notion of logical participation in a call as well as a physical participation in that call (i.e. Not Held).
- 13 -
Held - the state where a device inactively participates in a call. This state embodies the notion of logical participation in a call with suspended physical participation in that call. Queued - the state where normal state progression has been stalled. This state generally refers to two conditions but can apply to others as well. One condition is when a device is trying to establish a Connection with a call, and the process is stalled. The second condition is when a call tries to establish a Connection with a device and that process is stalled. Failed - the state where normal state progression has been aborted. This state generally refers to the condition when a device tries to become Connected to a call or a call tries to become Connected to a device and the attempt fails. Failed can result because of failure to connect the calling device and call, failure to connect the called device and call, failure to create the call, and other reasons. 6.1.4
Call Event Reports The purpose for the switching model just presented is to provide an abstract view of actual states and events that are communicated via underlying signalling systems. This abstract view is probably more detailed than required by CSTA applications, but is presented to introduce a more exact language for describing CSTA Event Reports, states, and Functional descriptions. Because of the topology of the Switching Function, the signals that report events and changes in states have definite sources. Providing a telecommunications object (the Connection) that can be associated with the source of these signals helps in describing the meaning of the 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 access state machine resides in the ISDN device. Another part resides on the other side of the ISDN access. There is another similar distributed access state machine which 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 example, this concept of communication between two state machines is demonstrated for the case of establishing a simple call. Additionally, on either side of the example the ISDN call states have been provided. Notice in figure 5 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 often these 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 perform changes to multiple Connections but all are represented by a single Event Report. Each CSTA Event Report defines which Connection state changes it indicates.
- 14 -
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
CSTA Connection States
CSTA Event Reports
CSTA Connection States
ISDN Call
State
State
Figure 6 - Relationship of CSTA Call Event Reports 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 exist with 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 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 3 Null can be a known Connection state, so 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 sequence of Connection states shall be provided as a call state. CSTA simplifies the call state by relating it (at times) to a particular device. This relationship is described by differentiating the Connection states of the call. The Connection state associated with a particular device is called the local Connection state. Other Connection states are not differentiated from one another. In other words, CSTA Call states can differ by the order as well as combination of their Connection states. Alerting-Connected is not equal to Connected-Alerting. The first is defined as Received and the second is defined as Delivered. For calls with two Connections, table 1 summarizes the CSTA Call state assigned to the combinations of Connection states. If there is no entry in table 1 for the combination of Connection states, then the list shall be provided.
- 15 -
Table 1 - Definition of CSTA Call states
6.2
Local Connection State
Other Connection State
CSTA Simple Call state
Alerting
Connected
Received
Alerting
Held
Received-On Hold
Connected
Alerting
Delivered
Connected
Connected
Established
Connected
Failed
Failed
Connected
Held
Established-On Hold
Connected
Null
Originated
Connected
Queued
Queued
Held
Alerting
Delivered-Held
Held
Connected
Established-Held
Held
Failed
Failed-Held
Held
Queued
Queued-Held
Initiated
Null
Pending
Null
Null
Null
Dynamic identifier management Management of Dynamic Device Identifiers and Call Identifiers is provided by management of Connection Identifiers. This ensures that an identifier that is dependent on another is provided in the proper context. 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 is provided as follows. Connection Identifiers are provided when either a new Call or Device Identifier is created. When a call is made a Connection Identifier is provided. It is also provided in Event Reports that pertain to the call. When a device becomes involved in a call the Connection Identifier is provided in the Event Reports that occur at that device. Identifiers are updated when needed. If a call changes its identifier when a Conference or Transfer occurs, Connection Identifiers are provided that link the old call identifier to the new identifier. Similarly, if a Dynamic Device Identifier is changed, new Connection Identifiers are provided for the devices in the call. Management of identifiers is provided via management parameters included in Service acknowledgements and Event Reports. Identifiers 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 dynamic device identifier shall become invalid. Many Event Reports and Services specify that a reported or provided Connection Identifier has lost or will lose its context.
- 16 -
Identifiers can be reused. Once an identifier has lost its context it may be re-used to identify another object. It is suggested that an implementation not reuse 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 the use of both the Call and Device Identifiers to uniquely refer to Connections in a call. 7
Security Service CSTA may provide 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 alternate security mechanisms, like Secure-ROSE. CSTA Security Service shall use one or more of the following parameters:
8
1.
Message Sequence Number - this parameter can be used to detect missing messages in a sequence and that their order has not been altered.
2.
Time Stamp - this parameter can provide an indication of the "freshness" of the 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 recycled.
3.
Privilege Attribute Certificate (PAC) - this parameter shall contain one mandatory attribute: the sender ID. The sender ID can be used to make the appropriate access control decisions or in general to execute the security policy in effect. This PAC is the mechanism defined in ECMA-138 to exchange 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 the input CSTA data. It shall bind together all the fields so that the receiver can detect any tampering.
Generic Service requirements In each of the following Service sections the first "sub"-section following a Service heading, or Service Definition sections, is provided as normative text for describing the operational requirements for each CSTA Service. These sections provide the definition of CSTA Services. These Services are defined for the CSTA Service boundary between a Computing Function and a Switching Function and the Services are defined in terms of what they accomplish, not how they should be implemented. 8.1
Service Request Service Request sections are provided as normative text for describing the parameters and the optionality of the parameters associated with each Service Request. Each parameter is described by a numbered paragraph, so individual parameters can be referenced by their numbers. If more than one parameter is of the same type, then it shall be possible to distinguish between the parameters. Each Service Request shall allow inclusion of Non-standardized, or Private Data, which shall be informational in nature. Private data shall include an object identifier (as defined in CCITT Rec. X.208) to identify the manufacturer together with the data.
8.2
Service Response Service Response sections are provided as normative text for describing the parameters and the optionality of the parameters associated with each Service Response. Again, each parameter is described by a
- 17 -
numbered paragraph, so individual parameters can be referenced by their numbers. If more than one parameter is of the same type, then it shall be possible to distinguish between the parameters. Each Service Response shall allow inclusion of Non-standardized, or Private Data, which shall be informational in nature. CSTA employs a generic mechanism which is, in principle, decoupled from the specifics of the switching activity. The following points describe the operation of the CSTA Service Response: 1.
Appropriate Services shall have an unconfirmed mode where responses to correct requests are not returned.
2.
The server shall check correctness of the request (e.g. syntactical checks) before issuing the response. Incorrect requests shall always result in an error response even in the unconfirmed mode.
3.
If a response is sent before the action requested by the Service is completed (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 at which the response is generated in relation to the switching activity is implementation and Service dependent. For example, for the Hold Call Service: -
Some implementations may generate the response after checking the correctness of the request and at the point that they initiate the request.
-
Other implementations may delay the response until the Hold has completed (or is guaranteed to complete). In this case, a failure of the switching request is reflected in the response.
-
Irrespective of implementation details, when an operation succeeds the same Event Reports are generated if the monitoring has been established. In particular, a Held event (if selected) is always reported in addition to the response to a successful request (even in those implementations that delay the response until the Hold operation was complete). In a given context, and with appropriate monitoring in place, an operation generates the same set of Event Reports whether it was invoked manually or with CSTA Service Requests from the Computing Function.
When the Service is rejected, the server shall send diagnostic information indicating the reason that the Service was rejected. In some cases only a general error indication is supplied. If the Service fails, the client cannot assume the pre-Service states of CSTA objects are maintained. 8.3
Functional description Functional description sections are provided as informative (not normative) text. It is possible that many unique but very similar services may meet the requirements to provide the Service. Also provided for many of the Services is a pictorial example of conditions before and after a successful Service Request. The Event Report Service shows Before and After pictures showing the change reported by the Event Report. These figures are examples intended to provide enlightenment, and not to constrain implementations. The following example and key should provide better understanding of the information intended to be conveyed by the figures.
D1
c
C1
* D2
Before
D1
h
C1
* D2
After
Figure 7 - Example Figure for Service and Event Report Descriptions
- 18 -
The figures show Before and After pictures of a successful Service or Event Report. In the example above (Hold Call Service), and in all 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 Connection state.
-
labels in boxes and circles represent call and device instances.
-
labels on lines represent a Connection state using the following key: a c f h i q a/h
*
8.4
= = = = = = = =
Alerting Connected Failed Held Initiated Queued Alerting or Held (other combinations work similarly) Undefined
-
greyed boxes represent devices in a call unaffected by the Service/Event Report
-
white boxes and circles represent devices and calls affected by the Service/Event Report
Diagnostic error definitions This section shall define the errors available to return to a Service Request. The definitions apply equally to both Services requested by a CSTA Computing Function and those requested by a CSTA Switching Function. An error value indicates the server's best evaluation of the condition that was encountered that caused the server to send a negative response to the Service Request. Error values shall have a mandatory indicator of the category, and an optional specific error value. This is achieved by organizing error values into categories. The specific error values are organized into 7 categories and defined in the following sections:
8.4.1
8.4.1
Operation errors
8.4.2
Security errors
8.4.3
State incompatibility errors
8.4.4
System resource availability errors
8.4.5
Subscribed resource availability errors
8.4.6
Performance management errors
8.4.7
Unspecified errors
8.4.8
CSTA private data information errors
Operation errors Error values in this category shall indicate that there is an error in the Service Request. This type shall include one of the following specific error values: 1.
Generic Operation Error. This error shall indicate that the server has detected an error in the operation class, but that it is not one of the defined errors, or the server cannot be any more specific.
- 19 -
8.4.2
2.
Request Incompatible With Object. The request is not compatible with the object.
3.
Value Out Of Range. The parameter has a value that is not in the range defined for the server.
4.
Object Not Known. The 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 request cannot be provided because the specified device is not authorized for the Service.
8.
Invalid Forwarding Destination. The request cannot be provided because the forwarding destination device is not valid.
9.
Privilege Violation On Called Device. The request cannot be provided because the called device is not authorized for the Service.
10.
Privilege Violation On Calling Device. The request cannot be provided because 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 CSTA 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 indicated an allocation condition that is not valid.
17.
Invalid Cross Reference Id. The Service Request specified a Cross Reference Id that is not in use at this 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 request violates a security requirement.
Security errors Error values in this category shall indicate that there is a security error. This type shall include one of the following specific error values: 1.
Generic Security Error. The server is unable to be any more specific.
2.
Sequence Number Error. This error shall indicate that the server has detected an error in the Sequence Number of the operation.
3.
Time Stamp Error. This error shall indicate that the server has detected an error in the Time Stamp of the operation.
4.
PAC Error. This error shall indicate that the server has detected an error in the PAC of the operation.
5.
Seal Error. This error shall indicate that the server has detected an error in the Seal of the operation.
- 20 -
8.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. This type shall include one of the following specific error values:
8.4.4
1.
Generic State Incompatibility. The server is unable to be any more specific.
2.
Incorrect Object State. The object is in the incorrect state for the Service. This general error value may be used when the server is not able to be any more specific.
3.
Invalid CSTA Connection Identifier For Active Call. The Connection Identifier specified in the Active Call parameter of the request is not in the correct state.
4.
No Active Call. The requested Service operates on an active call, but there is no active call.
5.
No Held Call. The requested Service operates on a held call, but the specified call is not in the Held state.
6.
No Call To Clear. There is no call associated with the CSTA Connection Identifier of the Clear Call request.
7.
No Connection To Clear. There is no Connection for the CSTA Connection Identifier specified as Connection To Be Cleared.
8.
No Call To Answer. There is no call active for the CSTA Connection Identifier specified as Call To Be Answered.
9.
No Call To Complete. There is no call active for the CSTA Connection Identifier specified as Call To Be Completed.
System resource availability errors Error values in this category shall indicate that the Service Request cannot be completed because of a lack of system resources within the serving sub-domain. This type shall include one of the following specific error values:
8.4.5
1.
Generic System Resource Availability Error. The server is unable to be any more specific.
2.
Service Busy. The Service is supported by the server, but is temporarily unavailable.
3.
Resource Busy. An internal resource is busy. There is high probability that the Service will succeed if retried.
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. This request would exceed the server's overall limit of monitors.
8.
Conference Member Limit Exceeded. This request would exceed the server's limit on the number of members of a conference.
Subscribed resource availability errors Error values in this category shall indicate that the Service Request cannot be completed because a required resource must be purchased or contracted by the client system. This type shall include one of the following specific error values:
- 21 -
8.4.6
1.
Generic Subscribed Resource Availability Error. The server is unable to be any more specific.
2.
Object Monitor Limit Exceeded. This request would exceed the server's limit of monitors for the specified object.
3.
External Trunk Limit Exceeded. The limit of external trunks would be exceeded by this request.
4.
Outstanding Requests Limit Exceeded. The limit of outstanding requests would be exceeded by this request.
Performance management errors Error values in this category shall indicate that an error has been returned as a performance management mechanism. This type shall include one of the following specific error values:
8.4.7
1.
Generic Performance Management Error. The server is unable to be any more specific.
2.
Performance Limit Exceeded. A performance limit is exceeded.
Unspecified errors Error values in this category shall indicate that an error has occurred that is not among the other error types. This type shall include the following specific error value: 1.
8.4.8
Unspecified Error.
CSTA private data information errors Error values in this category shall indicate that an error has occurred in the CSTA Private Data Information of the Service Request. The type of error is not part of the CSTA standard. This type shall include the following specific error value: 1.
9
CSTA Private Data Information Error. The Service Request contained an error in the CSTA Private Data Information parameter. This error value may result from any Service with CSTA Private Data Information attached.
Switching Function Services 9.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 connect an alerting call at the same device.
9.1.1
Service Request The request for the Alternate Call Service shall include at least one of the following parameters: 1.
CSTA Connection Identifier - specifies the "Connected" Connection to alternate.
2.
CSTA Connection Identifier - specifies the "Alerting" or "Held" Connection to alternate.
The request may also include the following parameter: 3. 9.1.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.1.2.1
Positive acknowledgement The positive acknowledgement may include the following parameter:
- 22 -
1. 9.1.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement may include one or more of the following parameters: 1.
9.1.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description An accepted request causes the specified device's held/delivered and active calls to be swapped. As shown in figure 8, the Alternate Call Service places the user's active call to device D2 on hold and, in a combined action, establishes or retrieves the call between device D1 and device D3 as the active call. Device D2 can be considered as being automatically placed on hold immediately prior to the retrieval/establishment of the held/active call to device D3. The operation of the Alternate Call Service is depicted in figure 8.
D1
c
C1
* D2
h/a
C2
* D3
D1
Before
h
C1
*
D2
c
C2
*
D3
After Figure 8 - Alternate Call
9.2
Answer Call Service The Answer Call Service shall connect an alerting call. The call must be associated with a device that can answer a call without physical manipulation.
9.2.1
Service Request The request for Answer Call Service shall include the following parameter: 1.
CSTA Connection Identifier - shall indicate the Connection to answer.
The request may also include the following parameter: 2. 9.2.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.2.2.1
Positive acknowledgement The positive acknowledgement may include the following parameter: 1.
9.2.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.2.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description The Answer Call Service works for an incoming call that is ringing a device. In figure 9, the call C1 is delivered to device D1. Answer Call is used, typically with telephones that have attached speakerphone units, to establish the call in a hands-free operation.
- 23 -
D1
a
C1
* D2
D1
Before
c
C1
* D2
After Figure 9 - Answer Call
9.3
Call Completion Service The Call Completion Service shall invoke features that complete a call which may otherwise fail.
9.3.1
Service Request The request for the Call Completion Service shall include the following parameters: 1.
Feature - shall identify the feature to invoke. The allowed features are: Camp On - queues the call until the device is available. Call Back - requests the called device to return the call when it returns to idle. Intrude - adds the caller to an existing active call at the called device.
2.
CSTA Connection Identifier - shall indicate the Connection Identifier of the caller.
The request may also include the following parameter: 3. 9.3.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.3.2.1
Positive acknowledgement The positive acknowledgement may include the following parameter: 1.
9.3.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.3.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description Generally this Service is invoked when a call is set up and encounters a busy far device or no answer. Camp On allows queuing for availability. Generally, Camp On makes the caller wait until the called party finishes the current call and any previously camped on calls. Call Back allows requesting the called device to return the call when it returns to idle. Call Back works much like Camp On, but the caller is allowed to hang up after invoking the service, and the CSTA Switching Function calls both parties when the called party becomes free. Intrude allows the caller to be added into an existing call at the called device.
9.4
Clear Call Service The Clear Call Service shall release all of the devices from the specified call, and shall eliminate the call itself. The call ceases to exist and the CSTA identifiers used for observation and manipulation are released.
9.4.1
Service Request The request for the Clear Call Service shall include the following parameter: 1.
CSTA Connection Identifier - shall indicate the call to clear.
- 24 -
The request may also include the following parameter: 2. 9.4.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.4.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 shall become invalid. The instances of identifiers shall not be used to request additional Services of the CSTA server. The positive acknowledgement may include the following parameter: 1.
9.4.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.4.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description Each device in the call is released and the CSTA Connection Identifiers (and their components) are freed. Figure 10 illustrates the results of a Clear Call (CSTA Connection Id = C1,D1), where call C1 connects devices D1, D2 and D3.
D1
C1
*
*
D2
*
D3
D1
Before
D2
D3 After
Figure 10 - Clear Call 9.5
Clear Connection Service The Clear Connection Service releases the specified device from the designated call. The Connection is left in the Null state. Additionally, the CSTA Connection Identifier provided in the Service Request is released.
9.5.1
Service Request The request for the Clear Connection Service shall include the following parameter: 1.
CSTA Connection Identifier - shall indicate the Connection to clear.
The request may also include the following parameter: 2.
CSTA Private Data Information.
- 25 -
9.5.2
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.5.2.1
Positive acknowledgement Positive Acknowledgement to the Service Request shall indicate that the instance of the CSTA Connection Identifier for the cleared Connection is released. The identifier shall not be used to request additional Services of the CSTA server. The positive acknowledgement may include the following parameter: 1.
9.5.2.2
CSTA Private Data Information - shall be informational type.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.5.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description This Service releases the specified Connection and CSTA Connection Identifier instance from the designated call. The result is as if the device had hung up on the call. It is interesting to note that the phone may not be physically returned to the switch hook, which may 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 Clear Call. Figure 11 is an example of the results of a Clear Connection (CSTA Connection Id = C1,D3), where call C1 connects devices D1, D2 and D3. Note that it is likely that the call is not cleared by this Service if it is some type of conference.
D1
*
C1
*
D2
*
D3
D1
*
Before
C1
* D2
D3 After
Figure 11 - Clear Connection 9.6
Conference Call Service This Service provides a conference of 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 associated with the conferencing device are released, and a new CSTA Connection Identifier for the resulting Connection is provided.
9.6.1
Service Request The request for the Conference Call Service 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 other call to be conferenced.
The request may also include the following parameter: 3.
CSTA Private Data Information.
- 26 -
9.6.2
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.6.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 may also provide one or more of the following two 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 Static Device Identifier - provides the static reference for the party in the conference. This parameter may have a value that indicates that the static identifier is not known.
The positive acknowledgement may also include the following parameter: 4. 9.6.2.2
CSTA Private Data Information - shall be informational type.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.6.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description The starting conditions are that the call C1 from D1 to D2 is in the held state, and a call C2 from D1 to D3 is in progress.
D1
h
C1
* D2
c
C2
* D3
D1
* D2 c
Before
C3
*
D3
After Figure 12 - Conference Call
D1, D2 and D3 are conferenced or joined together in 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 request (D1,C1 or D1,C2). 9.7
Consultation Call Service The Consultation Call Service shall provide the compound action of the Hold Call Service followed by Make Call Service. This Service places an existing active call at a device on hold and initiates a new call from the same device.
9.7.1
Service Request The request for the Consultation Call Service shall include the following parameters: 1.
CSTA Connection Identifier - shall indicate the existing Connected Connection to be held.
2.
CSTA Static Device Identifier - this shall indicate the device to be consulted.
- 27 -
The request may also include the following parameter: 3. 9.7.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.7.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 may also include the following parameter: 2. 9.7.2.2
CSTA Private Data Information - shall be informational type.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.7.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description
D1
c
C1
* D2
D1
h
C1
* D2
c
C2
D3
Before
After Figure 13 - Consultation Call
9.8
Divert Call Service The Divert Call Service shall move a call at one device to another device.
9.8.1
Service Request The request for Divert Call Service 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 - indicates that a Connection should be diverted away from a device to a destination that is inside or outside the switching sub-domain. Directed pickup - means that a Connection should be diverted to a new destination inside the switching sub-domain. Group pickup - indicates that a Connection should be diverted to a member of a pickup group.
2.
CSTA Static Device Identifier - shall indicate the device to which the Connection is to be diverted.
The request may also include one or more of the following parameters: 3.
CSTA Connection Identifier - shall indicate the Connection to divert.
4.
CSTA Private Data Information.
- 28 -
9.8.2
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.8.2.1
Positive acknowledgement The positive acknowledgement may include the following parameter: 1.
9.8.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.8.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description The Divert Call Service replaces the original called device, as specified in the CSTA Connection Identifier, with a different called device, as specified in the CSTA Static Device Identifier. The Divert Call Service supports at least three common call diversion services: – Deflection: Takes a ringing call at a device and sends it to a new destination. To use Divert Call to execute a deflection the CSTA Connection Identifier must be included. – Pickup: Takes a ringing call at another destination and brings it to a device. To use Divert Call to execute a pickup the CSTA Connection Identifier must be included. – Group Pickup: Takes a ringing call at one or more predetermined destination(s) and brings it to a device. To use Divert Call to execute a group pickup the CSTA Connection Identifier need not be included.
D1
?
C1
*
D2
D3
D1
D3 Before
C1
* D2
* After
Figure 14 - Divert Call 9.9
Hold Call Service The Hold Call Service shall place an existing Connection in the held state.
9.9.1
Service Request The request for Hold Call Service shall include the following parameter: 1.
CSTA Connection Identifier - shall indicate the Connection to hold.
The request may also include one or more of the following parameters:
9.9.2
2.
Connection Reservation - reserves 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.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
- 29 -
9.9.2.1
Positive acknowledgement The positive acknowledgement may include the following parameter: 1.
9.9.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.9.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description This Service interrupts communications for an existing call at a device. A call may be placed on hold at a user's interface by the user some time after completion of dialling. The associated connection is made available for other uses, depending on the reservation option. As shown in figure 15, if the Hold Call Service is invoked for device D1 in call C1, then call C1 is placed on hold at device D1. The hold relationship is affected at the holding device.
D1
c
C1
* D2
D1
Before
h
C1
* D2
After Figure 15 - Hold Call
Hold Call maintains a relationship between the holding device and the held call that lasts until the call is retrieved from the hold status, or the call is cleared. 9.10
Make Call Service The Make Call Service shall originate a CSTA call between two devices. The Service shall attempt to create a new call, and attempt to establish a connected Connection with the originating device. The Make Call Service also provides a CSTA Connection Identifier that shall indicate the Connection of the originating device.
9.10.1
Service Request The request for the Make Call Service shall include the following parameters: 1.
CSTA Static Device Identifier - shall indicate the device from which the call is originated.
2.
CSTA Static Device Identifier - shall indicate the device to which the call should be directed.
The request may also include the following parameter: 3. 9.10.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.10.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 may also include the following parameter: 2.
CSTA Private Data Information.
- 30 -
9.10.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.10.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description The Functional description is to originate a call between the designated devices. 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. The calling device must be in either idle state (on or off hook) or in pending state (off hook, but not yet dialling a number) for a particular call for the Service to be successful. Figure 16 illustrates the results of a Make Call (Calling device = D1, Called device = D2). A call is established as if D1 had called D2, and the client is returned the Connection id (C1,D1).
D1
D2
D1
Before
c
C1
D2
After Figure 16 - Make Call
The establishment of the call has just begun. Call progress Event Reports may be sent by the server application as the connection establishment progresses, as selected by the client application by way of the Monitor Start Service. The call is not guaranteed to succeed after acknowledgement has been received. 9.11
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 Connected Connection with the terminating (called) device. The Make Predictive Call Service also provides a CSTA Connection Identifier that shall indicate the Connection of the terminating (called) device.
9.11.1
Service Request The request for the Make Predictive Call Service shall include the following parameters: 1.
CSTA Static Device Identifier - shall indicate the device from which the call is originated.
2.
CSTA Static Device Identifier - shall indicate the device to which the call should be directed.
The request may also include one or more of the following parameters: 3.
Allocation - specifies the condition when the call attempts to connect to the caller. If absent, Call Delivered is the default. This may be one of the following values: Call Delivered: this value shall specify that the call attempt to connect to the caller if Alerting or Connected is determined at the called party. Call Established: this value shall specify that the call attempt to connect to the caller if Connected is determined at the called party.
4. 9.11.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
- 31 -
9.11.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameter: 1.
CSTA Connection Identifier - shall indicate the Connection between the terminator and the call.
The positive acknowledgement may also include the following parameter: 2. 9.11.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.11.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description This Service is often used to initiate a call from a group of devices (or a logical device). This Service allocates the call to a particular device 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 the 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) Connection state at the recipient. If the allocation parameter is set to Call Established, then the call is allocated upon detection of a Connected Connection state at the recipient. The typical use of this Service is to place a call out of a CSTA sub-domain. The CSTA Connection Identifier allocated by this Service may apply to an outbound trunk. Figure 17 illustrates the results of a Make Predictive Call (Calling device = group device D1, Called device = D2).
D1
D2
D1
Before
C1
a/c D2
After
Figure 17 - Make Predictive Call 9.12
Query Device Service The Query Device Service shall provide indication of the state of device features or the static attributes of a device.
9.12.1
Service Request The Service Request shall include the following parameters: 1.
CSTA Static Device Identifier - shall indicate the device to query.
2.
Feature - shall indicate the requested information and shall consist of one of the following: a)
Message Waiting: indicator of available messages.
b)
Do Not Disturb: indicator that the device is in the Do Not Disturb state.
c)
Forward: indicator whether the device is forwarding calls and if so, what type of forwarding is in place and the number forwarded to.
d)
Last Number: indicator of the last number dialled.
- 32 -
e)
Device Info: indicator of the class and type of device, and optionally a short form static identifier for the device.
f)
Agent State: indicator of ACD agent state.
The request may also include the following parameter: 3. 9.12.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.12.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameter: 1.
Feature: provides the requested information and shall consist of the same lettered item as was indicated by the service request: a)
On/Off: indicator of available messages.
b)
On/Off: indicator that the device is in the Do Not Disturb state.
c)
Type of Forwarding: shall return each of the following that are On, and may return others as well: Immediate - Forwarding all calls. If provided then the response shall also include: On/Off: indicator whether the device is forwarding calls. Static Device ID: shall indicate the device to which the calls are forwarded. Busy - Forwarding when busy. If provided then the response shall also include: On/Off: indicator whether the device is forwarding calls. Static Device ID: shall indicate the device to which the calls are forwarded. No Answer - Forwarding after no answer. If provided then the response shall also include: On/Off: indicator whether the device is forwarding calls. Static Device ID: shall indicate the device to which the calls are forwarded. Busy Internal - Forwarding when busy for an internal call. If provided then the response shall also include: On/Off: indicator whether the device is forwarding calls. Static Device ID: shall indicate the device to which the calls are forwarded. Busy External - Forwarding when busy for an external call. If provided then the response shall also include: On/Off: indicator whether the device is forwarding calls. Static Device ID: shall indicate the device to which the calls are forwarded. No Answer Internal - Forwarding after no answer for an internal call. If provided then the response shall also include: On/Off: indicator whether the device is forwarding calls. Static Device ID: shall indicate the device to which the calls are forwarded.
- 33 -
No Answer External - Forwarding after no answer for an external call. If provided then the response shall also include: On/Off: indicator whether the device is forwarding calls. Static Device ID: shall indicate the device to which the calls are forwarded. d)
Static Device ID: indicator of the last number dialled.
e)
Device Info: shall indicate the class and type of device. It may also indicate a Short Form Static Device Identifier for the device. The class shall include one or more of the following attributes: voice, data, image, other. The type shall include one or more of the following attributes: station, line, button, ACD, trunk, operator, other, station group, line group, button group, ACD group, trunk group, operator group, other group.
f)
Agent State: shall indicate ACD agent state. The state shall be one of the following values: Work/Not Ready. This state shall indicate that an agent is occupied with after call work. It also implies that the agent should not receive additional ACD calls. Work/Ready. This state shall indicate that an agent is occupied with after call work. It also implies that the agent may receive additional ACD calls. Ready. This state shall indicate that an agent is ready to accept calls. Null. This state shall indicate that an agent is logged out of the group or device that they serve. Not Ready. This state shall indicate that an agent is occupied with some task other than that of serving a call.
The positive acknowledgement may also include the following parameter: 2. 9.12.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.13
CSTA Error Value - taken from the error values provided in 8.4.
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.
9.13.1
Service Request The 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 may also include the following parameter: 3. 9.13.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
- 34 -
9.13.2.1
Positive acknowledgement The positive acknowledgement may include the following parameter: 1.
9.13.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.13.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description An accepted request causes an existing call to be dropped. Having dropped the call, the specified held call at the device is retrieved and becomes active. This Service is typically used to drop an active call and return to a held call; however, it can also be used to effect a cancel of a consultation call (because of no answer, called device busy, etc.) followed by returning to a held call.
D1
h
C1
* D2
c
C2
* D3
D1
Before
c
C1
*
D2
C2
* D3
After Figure 18 - Reconnect Call
9.14
Retrieve Call Service The Retrieve Call Service shall connect an existing Held Connection.
9.14.1
Service Request The request for Retrieve Call Service shall include the following parameter: 1.
CSTA Connection Identifier - shall indicate the Connection to be retrieved.
The request may also include the following parameter: 2. 9.14.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.14.2.1
Positive acknowledgement The positive acknowledgement may include the following parameter: 1.
9.14.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.14.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description The indicated Connection is restored to the Connected state. The call state may change due to actions by far end endpoints. If the Hold Call Service reserved the Held Connection and the Retrieve Call Service is requested for the same call, then the Retrieve Call Service should use the reserved Connection.
- 35 -
D1
h
C1
* D2
D1
c
Before
C1
* D2
After Figure 19 - Retrieve Call
9.15
Set Feature Service The Set Feature Service sets device user features. It does not set system features or allow administration.
9.15.1
Service Request The Service Request shall include the following parameters: 1.
Static Device ID - 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 - sets messages available. This feature shall include: 3.
b)
Do Not Disturb - sets Do Not Disturb. 4.
c)
On/Off - flag that shall indicate whether to turn on or off.
On/Off - flag that shall indicate whether to turn on or off.
Forwarding - sets forwarding calls. If this Parameter is chosen, the following parameter shall be included: 5.
Type of Forwarding - the value shall be one of the following: Immediate - Forwarding all calls, Busy - Forwarding when busy, No Answer - Forwarding after no answer, 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.
6.
On/Off - flag that shall indicate whether to turn on or off forwarding. If the flag is On then the following parameter may be included:
7. d)
Static Device ID - shall indicate the device to which the calls are forwarded
Agent State - sets ACD agent state. This state shall be one of the following values: Work/Not Ready. Work/Ready. Ready. Logged On. If this value is specified, then the request may also include one or more of the following parameters: 8.
String - specifies the logon password or authorization code.
9.
Agent ID - specifies the agent identifier.
- 36 -
10.
Static Device ID - the ACD pilot or group for which to log on.
Logged Off. If this value is specified, then the request may also include one or more of the following parameters: 11.
Agent ID - specifies the agent identifier.
12.
Static Device ID - the ACD pilot or group for which to log out.
Not Ready. The request may also include the following parameter: 13. 9.15.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.15.2.1
Positive acknowledgement The positive acknowledgement may include the following parameter: 1.
9.15.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.16
CSTA Error Value - taken from the error values provided in 8.4.
Transfer Call Service The Transfer Call Service shall provide the transfer of a held call with an active call at the same device. The Transfer Call Service shall merge two calls with Connections to a single common device. Also, both of the Connections to the common device become Null and their CSTA Connection Identifiers are released.
9.16.1
Service Request The request for the Transfer Call Service shall include at least one of the following parameters: 1.
CSTA Connection Identifier - specifies the Held Connection to transfer.
2.
CSTA Connection Identifier - shall indicate the Connected Connection to transfer the call to.
The request may also include the following parameter: 3. 9.16.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
9.16.2.1
Positive acknowledgement The positive acknowledgement may include the following two parameters for each party that is known to the CSTA sub-domain whose Connection Identifier changes as a result of the Transfer Call Service. 1.
CSTA Connection Identifier - shall indicate the party in the resulting call.
2.
CSTA Static Device Identifier - provides the static reference for the party in the resulting call. This parameter may indicate that the CSTA Static Device Identifier is not known.
The positive acknowledgement may also include the following parameters:
- 37 -
9.16.2.2
3.
CSTA Connection Identifier - shall indicate a resulting Connection in the remaining call.
4.
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
9.16.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description Referring to figure 20, the starting conditions are that the call C1 from D1 to D2 is in held state, and a call C2 from D1 to D3 is in progress. This Service transfers the existing (held) call between devices D1 and D2 into a call from device D2 to a device D3.
D1
h
C1
* D2
c
C2
* D3
D1
Before
* C3
D2
* D3
After Figure 20 - Transfer Call
The request is used in the situation where the call from D1 to D3 is established or if the call is in any state other than Failed or Null state. The Transfer Call Service successfully completes, and D1 is released from the call.
10
Status Reporting Services
10.1
Change Monitor Filter Service The Change Monitor Filter Service shall allow changing the filter of an existing monitor.
10.1.1
Service Request The request for Change Monitor Filter Service shall include the following parameters: 1.
CSTA Cross Reference Identifier - shall indicate the monitor for which to change the filter.
2.
Call Filter - specifies the Call Event Reports to be filtered by the server and, therefore, not sent to the client. It may be as little as a single Event Report, or as much as all available Event Reports.
3.
Feature Filter - specifies the Feature Event Reports to be filtered by the server and, therefore, not sent to the client. It may be as little as a single Event Report, or as much as all available Event Reports.
4.
Agent Filter - specifies the Agent Event Reports to be filtered by the server and, therefore, not sent to the client. It may be as little as a single Event Report, or as much as all available Event Reports.
5.
Maintenance Filter - specifies the Maintenance Event Reports to be filtered by the server and, therefore, not sent to the client. It may be as little as a single Event Report, or as much as all available Event Reports.
- 38 -
6.
Private Filter - specifies the filtering of private Event Reports. This filter shall filter all private Event Reports. If filtering of individual private Event Reports is desired, then the mechanism shall be part of CSTA Private Data Information.
The request may also include the following parameter: 7. 10.1.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This 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:
10.1.2.2
1.
Call Filter - shall indicate the call filter that is used for this request. This filter may differ from the filter provided in the request.
2.
Feature Filter - shall indicate the feature filter that is used for this request. This filter may differ from the filter provided in the request.
3.
Agent Filter - shall indicate the agent filter that is used for this request. This filter may differ from the filter provided in the request.
4.
Maintenance Filter - shall indicate the maintenance filter that is used for this request. This filter may differ from the filter provided in the request.
5.
Private Filter - shall indicate whether private Event Reports are filtered for this request. This filter may differ from the filter provided in the request.
6.
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
10.1.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description The Change Filter Service allows a client of a monitor service to request a change in the set of Event Reports that are provided using that monitor. The new set of excluded Event Reports may be listed in the Service acknowledgement.
10.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, those Event Reports are sent from the Switching Function to the Computing Function. To conform to the Event Report service, an implementation shall provide and conform to one or more of the Event Reports in 10.2.2, 10.2.3, 10.2.4 and/or 10.2.5.
10.2.1
Service Request Event Reports reflect changes in object state(s) and may be accessed via monitors of 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 being sent. This parameter shall allow differentiating similar Event Reports that result from multiple monitor requests. Many event reports include parameters that can indicate their value is not known or not required. Not known indicates that the parameter's value
- 39 -
is not known by the server. Not required indicates that the parameter's value is that of the monitored device, when device-type monitoring is provided. There shall be provision in every Event Report to include the informational type of CSTA Private Data Information, which can be used to add information not provisioned for in this Standard. CSTA Private Data Information that is of the type that changes the operation of the request shall not be provided in the Event Reports. CSTA Private Data shall not carry information that can be provided using standard parameters, fields, and/or identifiers. It shall be possible to augment the standard set of Event Reports in a way that allows an application to identify the message as an Event Report, even if the specific Event Report is not understood. Event Reports shall be generically identifiable as Event Reports. CSTA defines five categories of Switching Function Event Reports. These five types shall be identifiable as either: Agent State Event Report, Call Event Report, Feature Event Report, Maintenance Event Report, or Private Event Report. An instance of the Event Report Service Request may be referred to as an "Event Report." 10.2.2
Agent State Event Reports Each Agent State Event Report is a message that indicates a change in state of an agent in the CSTA network. Like Call Event Reports, each Agent State Event Report indicates the new state that the agent enters regardless of any previous state. Every Event Report shall include the identifier of the agent device that the Event Report applies to. Additionally, every Event Report may include CSTA Private Data Information.
10.2.2.1
Logged On This Event Report shall indicate that an agent has logged on and is ready to contribute to the activities of the group or device that the agent logged into. It does not necessarily indicate that the agent is ready to accept calls. The Event Report shall include the following parameter: 1.
CSTA Static Device Identifier - shall indicate the device which Logged On. If this device is not specified, then the parameter shall indicate that the device was not required.
The Event Report may also include one or more of the following parameters:
10.2.2.2
2.
CSTA Agent Identifier - shall indicate the agent identifier.
3.
CSTA Static Device Identifier - shall indicate the group or pilot that is being logged into.
4.
data - shall indicate the agent password for logging in.
Logged Off This Event Report shall indicate that an agent has logged out of the group or device that they were serving. It implies that the agent is not able to accept any additional calls on behalf of the group or device. The Event Report shall include the following parameter: 1.
CSTA Static Device Identifier - shall indicate the device which Logged Off. If this device is not specified, then the parameter shall indicate that the device was not required.
The Event Report may also include one or more of the following parameters: 2.
CSTA Agent Identifier - shall indicate the agent identifier.
- 40 -
3. 10.2.2.3
CSTA Static Device Identifier - shall indicate the group or pilot that is being logged out of.
Not Ready This Event Report shall indicate that an agent is occupied with some task other than that of serving a call. It implies that the agent should not receive additional calls. It may imply that the agent is taking a break. The Event Report shall include the following parameter: 1.
CSTA Static Device Identifier - shall indicate the device which invoked Not Ready. If this device is not specified, then the parameter shall indicate that the device was not required.
The Event Report may also include the following parameter: 2. 10.2.2.4
CSTA Agent Identifier - shall indicate the agent identifier.
Ready This Event Report shall indicate that an agent is ready to accept calls, although they may be busy with an ACD call. Call Event Reports can provide information on the involvement with calls. The Event Report shall include the following parameter: 1.
CSTA Static Device Identifier - shall indicate the device which invoked Ready. If this device is not specified, then the parameter shall indicate that the device was not required.
The Event Report may also include the following parameter: 2. 10.2.2.5
CSTA Agent Identifier - shall indicate the agent identifier.
Work Not Ready This Event Report shall indicate that an agent is occupied with the task of serving a call. It implies that the agent is no longer connected to the call, but is still occupied with work belonging to the last call. It also implies that the agent should not receive additional ACD calls. The Event Report shall include the following parameter: 1.
CSTA Static Device Identifier - shall indicate the device which invoked Work Not Ready. If this device is not specified, then the parameter shall indicate that the device was not required.
The Event Report may also include the following parameter: 2. 10.2.2.6
CSTA Agent Identifier - shall indicate the agent identifier.
Work Ready This Event Report shall indicate that an agent is occupied with the task of serving a call. It implies that the agent is no longer connected to the call, but is still occupied with work belonging to the last call. It also implies that the agent may receive additional ACD calls. The Event Report shall include the following parameter: 1.
CSTA Static Device Identifier - shall indicate the device which invoked Work Ready. If this device is not specified, then the parameter shall indicate that the device was not required.
The Event Report may also include the following parameter: 2.
CSTA Agent Identifier - shall indicate the agent identifier.
- 41 -
10.2.3
Call Event Reports Each Call Event Report is a message that shall indicate a change in state of one or more Connections in the switching sub-domain. Each Call Event Report may contain a parameter that summarizes the local Connection state as perceived from a device that is the monitored object. Every Call Event Report may contain one cause code or field that adds meaning or clarifies the basic meaning of the Event Report. Cause codes are defined in 10.2.8. The defined Call Event Reports may apply to a single Connection, multiple Connections within a single call, or multiple Connections within multiple calls. The following sections define the Event Reports and the information they provide. Each Event Report relates to the example figures in the following way: – The Event Report specifies that the resultant state has been achieved regardless of any previous state. – The initial state(s) is given purely for example to put the Event Report into normal telecommunications context.
10.2.3.1
Call Cleared This Event Report shall indicate that a call is torn down. Normally this occurs when the last remaining device disconnects from the call. It can also occur when a call is immediately dissolved as a conference call can be by the conference controller.
D1
*
C1
*
D2
*
D3
D1
Before
D2
D3 After
Figure 21 - Call Cleared This event 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 may also include one or more of the following parameters: 2.
Local Connection State - if the monitor request was for a device, this parameter shall indicate that the Connection state of the device for this call is null.
3.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Call Back, Call Cancelled, Call Not Answered, Incompatible Destination, Invalid Account Code, Key Operation, Maintenance, Overflow, Override, and Resources not Available. 10.2.3.2
Conferenced This Event Report shall indicate that two calls are merged into one, and no parties are removed from the resulting call in the process.
- 42 -
D1
h
C1
* D2
c
C2
* D3
D1
Before
* D2 c
C3
*
D3
After Figure 22 - Conferenced
This event applies to multiple Connections within multiple calls. The Event Report shall include the following parameters: 1.
CSTA Connection Identifier - shall indicate a primary known call that was conferenced.
2.
CSTA Static Device Identifier - shall indicate the device which conferenced the call. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
3.
CSTA Static Device Identifier - shall indicate the device added to the call. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
The Event Report shall include the following parameter if previous Event Reports have provided this pre-conference Connection Identifier. 4.
CSTA Connection Identifier - shall indicate a secondary call, if known, that was conferenced.
The Event Report may also include one or more of the following parameters: list – the following two parameters for one or more endpoints in the resultant call: 5.
CSTA Connection Identifier - the identifier for the endpoint in the resultant call.
6.
CSTA Static Device Identifier - optional static identifier for the endpoints.
7.
Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the device for this call.
8.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Active Monitor, Key Operation, New Call, Override, Recall, and Silent Monitor. 10.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.
- 43 -
D1
*
C1
*
D2
*
D3
D1
*
C1
* D2
D3
Before
After
Figure 23 - Connection Cleared This event applies to a single Connection. The Event Report shall include the following parameters: 1.
CSTA Connection Identifier - shall indicate the Connection that was dropped from the call.
2.
CSTA Static Device Identifier - shall indicate the device which dropped from the call. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
The Event Report may also include one or more of the following parameters: 3.
Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the device for this call.
4.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Call Back, Call Cancelled, Call Not Answered, Destination Not Obtainable, Do Not Disturb, Incompatible Destination, Key Operation, Overflow, Override, Park, and Resources Not Available. 10.2.3.4
Delivered This Event Report shall indicate that "alerting" (tone, ring, etc.) is applied to a device or when the server detects that "alerting" has been applied to a device.
D1
C1
* D2
D1
Before
a
C1
* D2
After Figure 24 - Delivered
This event 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 device might have a different connected CSTA Static Device Identifier than the called CSTA Static Device Identifier passed in the previous Call Delivered Event Report for that device. In addition, every time a Call Delivered Event Report for a device is followed by another Call Delivered Event Report for another device, it implies that the first device is no longer involved in the call and that the call has been redirected. The Event Report shall include the following parameters: 1.
CSTA Connection Identifier - shall indicate the Connection that is Alerting.
- 44 -
2.
CSTA Static Device Identifier - shall indicate the device which is Alerting. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
3.
CSTA Static Device Identifier - shall indicate the calling device. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
4.
CSTA Static Device Identifier - shall indicate the originally called device. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
5.
CSTA Static Device Identifier - shall indicate the previously alerted device. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
The Event Report may also include one or more of the following parameters: 6.
Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the device for this call.
7.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Call Back, Call Forward, Call Forward Immediate, Call Forward Busy, Call Forward No Answer, Camp On, Key Operation, New Call, No Available Agents, Overflow, Override, Recall, Redirected, and Transfer. 10.2.3.5
Diverted This Event Report shall indicate that a call has been deflected or diverted from a monitored device. It shall indicate that the call is no longer present at the device.
D1
a
C1
*
D2
D3
D1
D3 Before
C1
* D2
* After
Figure 25 - Diverted This event 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 previously Alerting.
The Event Report shall include the following parameters: 2.
CSTA Static Device Identifier - shall indicate the device from which the call was Diverted. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
3.
CSTA Static Device Identifier - shall indicate the device to which the call was diverted. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
- 45 -
The Event Report may also include one or more of the following parameters: 4.
Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the device for this call.
5.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Call Forward, Call Forward Immediate, Call Forward Busy, Call Forward No Answer, Call Not Answered, Call Pickup, Do Not Disturb, Incompatible Destination, Key Operation, No Available Agents, Overflow, Recall, Redirected, and Voice Unit Initiator. 10.2.3.6
Established This Event Report shall indicate that the server detects that a device answers or connects to a call.
D1
a
C1
* D2
D1
Before
c
C1
* D2
After Figure 26 - Established
This event applies to a single Connection. The Event Report shall include the following parameters: 1.
CSTA Connection Identifier - indicates the Connection that joined the call.
2.
CSTA Static Device Identifier - shall indicate the device which joined the call. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
3.
CSTA Static Device Identifier - shall indicate the calling device. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
4.
CSTA Static Device Identifier - shall indicate the originally called device. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
5.
CSTA Static Device Identifier - shall indicate the previously alerted device. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
The Event Report may also include one or more of the following parameters: 6.
Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the device for this call.
7.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Alternate, Call Pickup, Key Operation, New Call, Override, Recall, and Transfer. 10.2.3.7
Failed This Event Report shall indicate that a call cannot be completed.
- 46 -
D1
c
C1
D2
D1
c
Before
C1
f
D2
After Figure 27 - Failed
This event applies to a single Connection. The Event Report shall include the following parameters: 1.
CSTA Connection Identifier - shall indicate the Connection that failed.
2.
CSTA Static Device Identifier - shall indicate the device that failed. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
3.
CSTA Static Device Identifier - shall indicate the called device. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
The Event Report may also include one or more of the following parameters: 4.
Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the device for this call.
5.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Alternate, Busy, Call Cancelled, Call Forward, Call Forward Immediate, Call Forward Busy, Call Forward 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. 10.2.3.8
Held This Event Report shall indicate that the server detects that communication on an existing call has been temporarily interrupted at one of the devices in the call.
D1
c
C1
*
D2
D1
Before
h
C1
* D2
After Figure 28 - Held
This event applies to a single Connection. The Event Report shall include the following parameters: 1.
CSTA Connection Identifier - shall indicate the Connection where hold was activated.
2.
CSTA Static Device Identifier - shall indicate the device which activated hold. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
The Event Report may also include one or more of the following parameters: 3.
Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the device for this call.
- 47 -
4.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Alternate, Call Forward, Call Forward No Answer, Key Operation, Recall, and Transfer. 10.2.3.9
Network Reached This Event Report shall indicate that a call is cut through the CSTA switching sub-domain boundary to another network (sent to an outgoing trunk). This Event Report implies that there will be a reduced level of Event Reporting and possibly no additional device feedback, except disconnect/drop, provided for this party in the call. A Network Reached Event Report is never sent for calls made to devices connected directly to the CSTA switching sub-domain. Switching Sub-domain Boundary
D1
c
C1
D2
D1
c
C1
c
Trunk
Before
D2 Trunk
After Figure 29 - Network Reached
This event 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 Static Device Identifier - shall indicate the trunk that was selected. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
3.
CSTA Static Device Identifier - shall indicate the destination device. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
The Event Report may also include one or more of the following parameters: 4.
Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the device for this call.
5.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Call Forward, Call Forward Immediate, Call Forward Busy, Call Forward No Answer, Key Operation, Overflow, Redirected, Resources Not Available, and Transfer. 10.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.
- 48 -
D1
D2
D1
c
Before
C1
D2
After Figure 30 - Originated
This event applies to a single Connection. The Event Report shall include the following parameters: 1.
CSTA Connection Identifier - shall indicate the Connection where a call originated.
2.
CSTA Static Device Identifier - shall indicate the calling device. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
3.
CSTA Static Device Identifier - shall indicate the called device. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
The Event Report may also include one or more of the following parameters: 4.
Local Connection State - if the monitor request was for a device, this parameter shall indicate that the Connection state of the device for this call is Connect.
5.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Call Back, Key Operation, New Call, Override, and Silent Monitor. 10.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 may also occur during network routeing without an associated device.
D1
c
C1
D2
D1
Before
c
C1
q
D2
After Figure 31 - Queued
This event applies to a single Connection. The Event Report shall include the following parameters: 1.
CSTA Connection Identifier - shall indicate the Connection that queued.
2.
CSTA Static Device Identifier - shall indicate the queuing device (if queued at a device). If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
3.
CSTA Static Device Identifier - shall indicate the calling device. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
4.
CSTA Static Device Identifier - shall indicate the called device. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
- 49 -
5.
CSTA Static Device Identifier - shall indicate the redirecting device if that call was redirected. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
The Event Report may also include one or more of the following parameters: 6.
Number - shall indicate the number of calls in queue.
7.
Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the device for this call.
8.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Busy, Call Back, Call Forward, Call Forward Immediate, Call Forward Busy, Call Forward 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. 10.2.3.12
Retrieved This Event Report shall indicate that the server detects a previously held call that has been retrieved.
D1
h
C1
* D2
D1
Before
c
C1
* D2
After Figure 32 - Retrieved
This event applies to a single Connection. The Event Report shall include the following parameters: 1.
CSTA Connection Identifier - shall indicate the Connection where hold was de-activated.
2.
CSTA Static Device Identifier - shall indicate the device which de-activated hold. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
The Event Report may also include one or more of the following parameters: 3.
Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the device for this call.
4.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Alternate, Key Operation, Recall, and Transfer. 10.2.3.13
Service Initiated This Event Report shall indicate that telecommunications service is initiated at a monitored device. The server issues this Event Report when "dial-tone" is provided. This Event Report indicates that either a call may be originated or a feature may be invoked. NOTE 5 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, like CSTA calls initiated with Make Call Service.
- 50 -
D1
D1 Before
i
C1
After Figure 33 - Service Initiated
This event applies to a single Connection. The Event Report shall include the following parameter: 1.
CSTA Connection Identifier - shall indicate the Connection where service is established. This identifier shall continue to be used if the service becomes a call.
The Event Report may also include one or more of the following parameters: 2.
Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the device for this call is Initiated.
3.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Call Back, Call Cancelled, Key Operation, and Override. 10.2.3.14
Transferred This Event Report shall indicate that an existing call was transferred to another device and the device requesting the transfer has been dropped from the call. The transferring device does not appear in any future feedback for the call.
D1
h
C1
* D2
c
C2
* D3
D1
Before
* C3
D2
* D3
After Figure 34 - Transferred
This event applies to single Connections in multiple calls. The Event Report shall include the following parameters: 1.
CSTA Connection Identifier - shall indicate a primary known call that was transferred.
2.
CSTA Static Device Identifier - shall indicate the device which transferred the call. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
3.
CSTA Static Device Identifier - shall indicate the device to which the call was transferred. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
The Event Report shall include the following parameter if previous Event Reports have provided this pre-transfer Connection Identifier. 4.
CSTA Connection Identifier - shall indicate a secondary call, if known, that was transferred.
- 51 -
The Event Report may also include one or more of the following parameters: list - the following two parameters for every endpoint in the resultant call: 5.
CSTA Connection Identifier - the identifier for the endpoint in the resultant call.
6.
CSTA Static Device Identifier - optional static identifier for the endpoint.
7.
Local Connection State - if the monitor request was for a device, this parameter shall indicate the Connection state of the device for this call.
8.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Frequently used cause values are listed below (for a complete list see 10.2.8): Key Operation, New Call, Recall, Redirected, Transfer, and Voice Unit Initiator. 10.2.4
Feature Event Reports Each Feature Event Report is a message that indicates a change in Feature state of a call or device in the CSTA network. Like Call Event Reports, each Feature Event Report indicates the new state that the feature enters regardless of any previous state. Every Event Report shall include the identifier of the call or device that the event applies to.
10.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 - indicates the party that entered the account code.
2.
CSTA Static Device Identifier - indicates the device which entered the account code. If this device is not specified, then the parameter shall indicate that the device was not known or that it was not required.
The Event Report may also include one or more of the following parameters:
10.2.4.2
3.
data - the account code that was entered.
4.
data - the authorization code that was entered.
Do Not Disturb This Event Report shall indicate that the Do Not Disturb feature has been invoked for a device. The Event Report shall include the following parameters:
10.2.4.3
1.
CSTA Static Device Identifier - shall indicate the device which invoked Do Not Disturb. If this device is not specified, then the parameter shall indicate that the device was not required.
2.
flag - shall indicate whether the feature was turned on or off.
Forwarding This Event Report shall indicate that the Forwarding feature has been invoked for a device. The Event Report shall include the following parameter: 1.
CSTA Static Device Identifier - shall indicate the device which invoked Forwarding. If this device is not specified, then the parameter shall indicate that the device was not required.
2.
flag - shall indicate whether the feature was turned on or off.
- 52 -
3.
The type of forwarding that was invoked - this shall be one of the following values: Immediate - Forwarding all calls, Busy - Forwarding when busy, No Answer - Forwarding after no answer, 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, or No Answer External - Forwarding after no answer for an external call.
The Event Report may also include the following parameter: 4. 10.2.4.4
CSTA Static Device Identifier - shall indicate the device to which calls are forwarded.
Message Waiting This Event Report shall indicate that the Message Waiting feature has been invoked for a device. NOTE 6 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 Event Report shall include the following parameters:
10.2.5
1.
CSTA Static Device Identifier - shall indicate the device which invoked Message Waiting. If this device is not specified, then the parameter shall indicate that the device was not known or not required.
2.
CSTA Static Device Identifier - shall indicate the device where the message is waiting. If this device is not specified, then the parameter shall indicate that the device was not known or not required.
3.
flag - shall indicate whether the feature was turned on or off.
Maintenance Event Reports Each Maintenance Event Report is a message that indicates a change in maintenance state of a device in the CSTA network. Each Maintenance Event Report indicates the new state that the device enters regardless of any previous state. Every Event Report shall include the identifier of the device that the event applies to. Additionally, every Event Report may include a cause value or field that adds meaning or clarifies the basic meaning of the Event Report, and every Event Report may include CSTA Private Data Information.
10.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 Event Report shall include the following parameter: 1.
CSTA Static Device Identifier - shall indicate the device that is Back In Service. If this device is not specified, then the parameter shall indicate that the device was not required.
The Event Report may also include the following parameter: 2.
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
- 53 -
10.2.5.2
Out Of Service This Event Report shall indicate that the device has entered a maintenance state (has been taken Out Of Service) and can no longer accept calls, or be manipulated by CSTA. It may be possible to continue to Monitor such a device, or to take a Snapshot, but no direct Services, like Make Call or Request Feature, can be provided. The Event Report shall include the following parameter: 1.
CSTA Static Device Identifier - shall indicate the device that is taken Out Of Service. If this device is not specified, then the parameter shall indicate that the device was not required.
The Event Report may also include the following parameter: 2. 10.2.6
Cause - shall indicate a reason or explanation for the occurrence of the Event Report.
Service Response Event Reports shall not have a response.
10.2.7
Functional description The action of each Event Report has been described under the individual reports.
10.2.8
Cause codes Cause codes can be used to refine 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 provides information that shows how they modify the Event Reports they apply to. Following the list of definitions is a table that shows the cause codes compared to CSTA Call Event Reports where they were determined to be meaningful. Cause code:
Indicates that:
Active Monitor
An Active Monitor Feature has occurred. This feature typically allows intrusion by a supervisor into an agent call with the ability to speak and listen. The resultant call can be considered as a conference so this cause code may be supplied with the Conferenced Event Report.
Alternate
The call is in the process of being exchanged. This feature is typically found on single-line telephones, where the human interface puts one call on hold and retrieves a held call or answers a waiting call in an atomic action.
Busy
The call encountered a busy tone or device.
Call Back
Call Back is a feature invoked (by a user or via CSTA) in an attempt to complete a call that has encountered a busy or no answer condition. As a result of invoking the feature, the failed call is cleared and the call can be considered as queued. The switch may subsequently automatically retry the call (normally when the called party next becomes free). Consequently, this cause code may appear in Event Reports related to the feature invocation (Call Cleared, Connection Cleared and Queued) or related to the subsequent, retried call (Service Initiated, Originated, Delivered, and Established).
Call Cancelled
The user has terminated a call without going on-hook.
Call Forward
The call has been redirected via a Call Forwarding feature set for general, unknown, or multiple conditions.
- 54 -
Call Forward Immediate
The call has been redirected via a Call Forwarding feature set for all conditions.
Call Forward Busy
The call has been redirected via a Call Forwarding feature set for a busy endpoint.
Call Forward 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 has elapsed.
Call Pickup
The call has been redirected via a Call Pickup feature.
Camp On
A Camp On feature has been invoked or has matured.
Destination Not Obtainable The call could not obtain the destination. Do Not Disturb
The call encountered a Do Not Disturb condition.
Incompatible Destination
The call encountered an incompatible destination.
Invalid Account Code
The call has an invalid account code.
Key Operation
Indicates that the Event Report occurred at a bridged or twin device. NOTE 7 Telephone numbers associated primarily with one device often appear also on a second device. One example is a secretary who's phone has mirrored or bridged lines of a boss's phone.
Lockout
The call encountered inter-digit timeout while dialling.
Maintenance
The call encountered a facility or endpoint in a maintenance condition.
Net Congestion
The call encountered a congested network. In some circumstances this cause code indicates that the user is listening to a "No Circuit" Special Information Tone (SIT) from a network that is accompanied by a statement similar to "All circuits are busy...".
Net Not Obtainable
The call could not reach a destination network.
New Call
The call has not yet been redirected.
No Available Agents
The call could not access any agent.
Overflow
The call overflowed a queue, group, or target.
Override
The call resulted because of an Override feature.
Park
Indicates that the Event Report is associated with an action to place a call to or retrieve a call from a parked position. Placing a call in a park position releases the call from the parking device, but retains the call in the Switching Function so that it can be connected to another (or the same) device by invoking the un-parking feature there.
Recall
The call is alerting a device due to a time-out built into 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 reorder - a tone provided by a network to indicate that the request (call, feature, or supplementary service) was not
- 55 -
recognizable. This condition usually 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. In some circumstances this cause code indicates that the user is listening to a "Reorder" Special Information Tone (SIT) from a network that is accompanied by a statement similar to "The call did not go through as dialled...". 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 indicate that they are being monitored. This feature is not the same as a CSTA Monitor request. This cause shall not indicate that a CSTA Monitor has been initiated.
Transfer
A Transfer is in progress or has occurred.
Trunks Busy
The call encountered Trunks Busy.
Voice Unit Initiator
Indicates that the event was the result of action by automated equipment (voice mail device, voice response unit, announcement) rather than the result of action by a human user.
- 56 -
Lockout Maintenance Net Congestion Net Not Obtainable New Call No Available Agents Overflow Override Park Recall Redirected Reorder Tone Resrcs. not Available Silent Monitor Transfer Trunks Busy Voice Unit Initiator
Transferred
Service Initiated
Retrieved
y
Network Reached
Held
Established
Diverted
Delivered
y y
y y y y
y y
Call Forward Immediate Call Forward Busy Call Forward No Answer Call Not Answered Call Pickup Camp On Dest. not Obtainable Do Not Disturb Incpt. Destination Invalid Account Code Key Operation
Failed
Active Monitor Alternate Busy Call Back Call Cancelled Call Forward
Conferenced
Cause
Call Cleared
Table 2 - CSTA Event Report - Cause Relationships
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
- 57 -
10.3
Monitor Start Service The Monitor Start Service shall provide Event Reports for a call, device, or for one or more calls that involve a CSTA device. The Event Reports shall be provided for all endpoints within the CSTA subdomain and optionally for endpoints outside of the CSTA sub-domain that are involved in a monitored call. There are two types of Monitor Start Service: call-type and device-type. 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 are present in the call specified by the CSTA Connection Identifier in the Service Request; or all the Connection state changes present in any call that has involved the device specified by the CSTA Static Device Identifier in the Service Request. If a call is forwarded or transferred, devices may cease to participate in that call, but all subsequent Event Reports at the new devices are reported. It should also be noted that a call that is being monitored may have a new call identifier assigned to it after a conference or transfer, and that the Event Report assigns a new call identifier and monitoring continues 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. For the device-type Monitor Start Service, all Call Event Reports passed by the filter shall be sent for the Connection state changes in all the calls that are present at the device specified by the CSTA Static Device Identifier. Event Reports shall be provided for calls that arrive at the device after the monitor request is acknowledged and for calls that are at the device at the time of the acknowledgement. Events that occurred previous to the monitor request are not reported. If a call is dropped, forwarded, or transferred, the device ceases to participate in that call, and no further events are reported. Additionally, Agent, Feature, and Maintenance Event Reports passed by the filter shall be provided when they apply to the monitored device.
10.3.1
Service Request The object that is to be monitored shall be specified in the Service Request. The object shall be either a device or call. Additionally, the Service Request may indicate the type of monitoring requested for the object. The type may also be either device or call. The supplied filter requests that the specified Event Reports are filtered out by the server and not sent to the client. If the client does not supply a filter then it is implicitly requesting all Event Reports. Since support for the filter is optional in both the client and server, the client must still be prepared to receive Event Reports it had requested to be filtered. NOTE 8 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 Static Device Identifier - the CSTA device to be monitored.
2.
CSTA Connection Identifier - the CSTA call to be monitored.
The request may also include one or more of the following parameters: 3.
Monitor Type - shall specify the type of monitor requested. This parameter shall indicate either call or device. If this parameter is not provided then the type of monitoring is selected by the server. This Standard does not specify a default.
4.
Call Filter - specifies the Call Event Reports to be filtered by the server and, therefore, not sent to the client. It may be as little as a single Event Report, or as much as all available Event Reports.
- 58 -
10.3.2
5.
Feature Filter - specifies the Feature Event Reports to be filtered by the server and, therefore, not sent to the client. It may be as little as a single Event Report, or as much as all available Event Reports.
6.
Agent Filter - specifies the Agent Event Reports to be filtered by the server and, therefore, not sent to the client. It may be as little as a single Event Report, or as much as all available Event Reports.
7.
Maintenance Filter - specifies the Maintenance Event Reports to be filtered by the server and, therefore, not sent to the client. It may be as little as a single Event Report, or as much as all available Event Reports.
8.
Private Filter - specifies the filtering of private Event Reports. This filter shall filter all private Event Reports. If filtering of individual private Event Reports is desired, then the mechanism shall be part of CSTA Private Data Information.
9.
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
10.3.2.1
Positive acknowledgement The positive response shall contain the following parameter: 1.
Cross Reference - the cross reference shall be a value unique within the association for the duration of the monitor and able to correlate subsequent Event Reports to the monitor request that initiated them. It shall also allow the correlation of the Monitor Stop and subsequent Change Filter Requests to the original Monitor Start request on which they act.
The positive acknowledgement may also include one or more of the following parameters:
10.3.2.2
2.
Call Filter - shall indicate the call filter that is used for this request.
3.
Feature Filter - shall indicate the feature filter that is used for this request.
4.
Agent Filter - shall indicate the agent filter that is used for this request.
5.
Maintenance Filter - shall indicate the maintenance filter that is used for this request.
6.
Private Filter - shall indicate whether private Event Reports are filtered for this request.
7.
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
10.3.3
CSTA Error Value - taken from the error values provided in 8.4.
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 Monitor Start Service, which can occur via client request or via server action. The server should terminate the monitor if the object being monitored expires, which can happen for a call, or if the object leaves a CSTA sub-domain, which can happen for all objects.
10.4
Monitor Stop Service The Monitor Stop Service shall be used to cancel a subscription to a previously initiated Monitor Start Service. It is required that some form of Event Reporting be supported for the Monitor Stop Service to be
- 59 -
of use. The Monitor Stop Service can be requested by either the client or server to terminate/abort the Monitor Start Service. 10.4.1
Service Request The Service Request shall include the following parameter: 1.
Cross Reference - the reference provided by the original Monitor Start Service Request to correlate the request with Event Reports that follow and the request to stop the Service.
The request may also include the following parameter: 2. 10.4.2
CSTA Private Data Information.
Service Response The Monitor Stop server (which can be either the monitor server or monitor client) shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
10.4.2.1
Positive acknowledgement Positive acknowledgement to the Service Request shall indicate that the cross-reference identifier used by the Monitor Start Service shall become invalid. The positive acknowledgement may include the following parameter: 1.
10.4.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
10.4.3
CSTA Error Value - taken from the error values provided in 8.4.
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 shall cease to be sent to the client by the server on the association that requested the monitor. The server should 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.
10.5
Snapshot Call Service Snapshot Call Service shall provide information about the 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, which comprise an overall call state.
10.5.1
Service Request The request for Snapshot Call Service shall include the following parameter: 1.
CSTA Connection Identifier - shall indicate the call to snapshot.
The request may also include the following parameter: 2. 10.5.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
- 60 -
10.5.2.1
Positive acknowledgement The positive acknowledgement shall include the following CSTA Static Device Identifier and CSTA Connection Identifier parameters for every endpoint in the call. Additionally, it shall include the CSTA Connection state parameter for each endpoint within the CSTA switching sub-domain that is in the call. It may also include the following other parameters for one or more endpoints not in the switching sub-domain, but in the call. 1.
CSTA Static Device Identifier - shall indicate the CSTA Static identifier for the device. If the device is outside the switching sub-domain, then the parameter may indicate that the value is not known.
2.
CSTA Connection Identifier - shall indicate the CSTA Connection Identifier for the endpoint.
3.
CSTA Connection state - shall indicate the Connection state for the endpoint. This state shall be one of the following: Null, Initiated, Alerting, Connected, Held, Failed.
The positive acknowledgement may also include the following parameter: 4. 10.5.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
10.5.3
CSTA Error Value - taken from the error values provided in 8.4.
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 that provide synchronization may not occur for some time. To facilitate operations before an Event Report synchronizes the monitor, it is necessary to be able to query the current state of CSTA objects. Snapshot Call Service provides that function. The nature of Snapshot Call Service is to obtain status and return it in a response. This does not affect the states of any objects in the Switching Function.
10.6
Snapshot Device Service Snapshot Device Service shall provide information about calls associated with a given CSTA device. The information provided shall identify each call and indicate its state.
10.6.1
Service Request The request for Snapshot Device Service shall include the following parameter: 1.
CSTA Static Device Identifier - shall indicate the device to snapshot.
The request may also include the following parameter: 2. 10.6.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
10.6.2.1
Positive acknowledgement The positive acknowledgement shall include the following parameters for each call at the device: 1.
CSTA Connection Identifier - identifies the call and, for some implementations, the device's dynamic device identifier for the call.
- 61 -
2.
CSTA Connection States - 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 not as a sequence, but as a composite call state (see 6.1.5 on Call states).
The positive acknowledgement may also include the following parameter: 3. 10.6.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
10.6.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description The Snapshot Device Service is intended to provide information about devices that makes further monitoring more meaningful. For example, if a CSTA application were to start working with a device, the Event Reports that 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. The nature of Snapshot Device Service is to obtain status and return it in a response. This does not affect the states of any objects in the Switching Function.
11
Computing Function Services
11.1
Re-Route Service The Re-Route Service shall request an alternate destination to the one provided by a previous Route Select Service and based on previous information provided for the call.
11.1.1
Service Request The Re-Route Service Request shall include the following parameter: 1.
Cross Reference - differentiates the set of routeing Services that are used for a particular call.
The Re-Route Service Request may also include the following parameter: 2. 11.1.2
CSTA Private Data Information.
Service Response The server shall not give positive acknowledgement to the Service Request, however the server may negatively acknowledge the Service Request. The requested route shall be provided via a Route Select Service sent from the server to the client.
11.1.2.1
Positive acknowledgement This Service shall not have a positive acknowledgement.
11.1.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
11.1.3
CSTA Error Value - taken from the error values provided in 8.4.
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
- 62 -
Service. The client is expected to use the cross reference identifier generated by the initial Route Request Service that links this Service to the others that are used to provide a route. 11.2
Route End Service The Route End Service shall end a routeing dialogue. It may be invoked by the client or server.
11.2.1
Service Request The request for the Route End Service shall include the following parameter: 1.
Cross Reference - shall differentiate the set of routeing Services that are used for a particular call. This Cross Reference instance shall become invalid.
The request may also include one or more of the following parameters: 2.
CSTA Error Value - taken from the error values provided in 8.4.
3.
CSTA Private Data 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. 11.2.2
Service Response No acknowledgement is sent. This Service ends the routeing dialogue.
11.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.
11.3
Route Request Service The Route Request Service shall request a destination for a call. To aid in the selection of a destination it shall include the current destination and may include additional information.
11.3.1
Service Request The Route Request Service Request shall include the following parameters: 1.
Cross Reference - shall differentiate 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 may also include one or more of the following parameters: 3.
Calling Device - shall indicate the originator of the call.
4.
CSTA Connection Identifier - shall indicate the CSTA Call Identifier.
5.
Route Selection Algorithm - shall indicate the type of routeing algorithm requested. This parameter includes 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 normal or default route is requested.
- 63 -
User Defined - shall indicate one of many possible application-defined routeing algorithms.
11.3.2
6.
Priority - shall indicate the priority of the call, and may affect selection of alternative routes.
7.
Set-up - shall contain an ISDN call setup message if available.
8.
CSTA Private Data Information.
Service Response The server shall not give positive acknowledgement to the Service Request, however the server may negatively acknowledge the Service Request. The requested route shall be provided via a Route Select Service sent from the server to the client.
11.3.2.1
Positive acknowledgement This Service shall not have a positive acknowledgement.
11.3.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
11.3.3
CSTA Error Value - taken from the error values provided in 8.4.
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 that links this Service to the others that are used to provide a route.
11.4
Route Select Service The Route Select Service shall provide the client with a destination requested by a previous Route Request or Re-Route Service.
11.4.1
Service Request The request for the Route Select Service shall include the following parameters: 1.
Cross Reference - shall differentiate 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 may also include one or more of the following parameters:
11.4.2
3.
Set-up - shall provide the ISDN call setup message if available.
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 Private Data Information.
Service Response The server shall not give positive acknowledgement to the Service Request, however the server may negatively acknowledge the Service Request. The routeing service shall be completed via a Route End Service sent by either the server or client.
- 64 -
11.4.2.1
Positive acknowledgement This Service shall not have a positive acknowledgement.
11.4.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
11.4.3
CSTA Error Value - taken from the error values provided in 8.4.
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.
11.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.
11.5.1
Service Request The request for the Route Used Service shall include the following parameters: 1.
Cross Reference - differentiates 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 may also include one or more of the following parameters:
11.5.2
3.
Calling Device - shall indicate the originator of the call.
4.
Domain - shall indicate whether the endpoint resolved to a point within the CSTA Switching sub-domain or whether the call has been routed outside the CSTA Switching sub-domain.
5.
CSTA Private Data Information.
Service Response The server shall not give positive acknowledgement to the Service Request, however the server may negatively acknowledge the Service Request. The routeing service shall be completed via a Route End Service sent by either the server or client.
11.5.2.1
Positive acknowledgement This Service shall not have a positive acknowledgement.
11.5.2.2
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
11.5.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description The Route Used Service can inform the server of the route that the client resolved. 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.
12 12.1
Bi-directional Services Escape Service The Escape Service shall allow an implementation to provide services that are not defined by this Standard using CSTA protocol and along with other CSTA Services. The Escape Service shall use the concept of
- 65 -
Object Identifiers, as described in ASN.1 (see CCITT Recs. X.208/X.209, ISO International Standards 8824/8825). Object Identifiers shall be used to identify a given manufacturer's equipment and services. 12.1.1
Service Request The Escape Service Request shall contain the following parameter: 1.
12.1.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
12.1.2.1
Positive acknowledgement The positive acknowledgement may include the following parameter: 1.
12.1.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
12.1.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description While most of the common switching and computing Services required by CSTA are standardized, there is a requirement 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 required to give manufacturers an opportunity to experiment with new services which may, at a later date, be standardized. If the server is able to perform the service it does so, in its own way, using the Private Data provided.
12.2
System Status Service This Service shall report the status of the switching or computing system.
12.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 - existing Monitor Requests have been disabled. Other Requests and Responses may also be disabled, but reject responses should be provided.. Enabled - Requests and Responses are re-enabled, usually after a disruption or restart. This status indication shall be sent after an Initializing status indicator has been sent and may be sent under other conditions. This status indicates that there are no outstanding monitor requests. Initializing - the system is re-initializing or restarting. This status indicates 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 - Requests and/or Responses may have been lost, including Event Report. Normal - sent at any time to indicate that the status is normal. This status has no effect on other Services. Overload Imminent - Receiver is requested to take initiative to shed load.
- 66 -
Overload Reached - Requestor may take initiative to shed load. This cause may be followed by Stop Monitor requests sent to the client, and rejections to additional Service Requests. Overload Relieved - Overload condition has passed. The Service Request may also include the following parameter: 2. 12.2.2
CSTA Private Data Information.
Service Response The server shall provide an acknowledgement to the Service Request. This acknowledgement shall be either positive or negative.
12.2.2.1
Positive acknowledgement The positive acknowledgement may include the following parameter: 1.
12.2.2.2
CSTA Private Data Information.
Negative acknowledgement The negative acknowledgement shall include the following parameter: 1.
12.2.3
CSTA Error Value - taken from the error values provided in 8.4.
Functional description The System Status Service is informational in nature, and performs no action other than informing.
.
.
.
This Standard ECMA-179 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 files E179-DOC.EXE or E179-PSC.EXE from ECMANEWS