ISO/IEC 18051:2000

INTERNATIONAL ISO/IEC
STANDARD 18051
First edition
2000-07-15
Information technology —
Telecommunications and information
exchange between systems — Services
for Computer Supported
Telecommunications Applications (CSTA)
Phase III
Technologies de l'information — Télécommunications et échange
d'information entre systèmes — Services pour applications en
télécommunications supportées par ordinateur (CSTA) en phase III
Reference number
©
ISO/IEC 2000
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2000
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 2000 – All rights reserved

Contents
Foreword xiii
Introduction xiv
1 Scope 1
2 Normative References 1
3 Conformance 2
3.1 Switching Function  2
3.1.1 Conformant Services 2
3.1.2 Conformant Events 3
3.1.3 CSTA Profiles 3
3.1.4 Support of Service Requests And Manual Mode 3
3.2 Special Resource Function Conformance  3
3.2.1 Conformant Services 3
3.2.2 Conformant Events 4
3.2.3 Support of Service Requests And Manual Mode 4
3.3 Computing Function Conformance  4
4 Definitions and Abbreviations 5
5 Functional Architecture 5
6 CSTA Operational Model 5
6.1 Switching Sub-Domain Model  6
6.1.1 Switching Sub-Domain Name 6
6.1.2 Application Working Domain 6
6.1.3 Device 6
6.1.4 Call 27
6.1.5 Connection 33
6.1.6 Call State Definitions 37
6.1.7 Referencing Devices, Elements, Appearances and Device Configurations 38
6.1.8 Management of Dynamically-Assigned Identifiers 40
6.2 Special Resource Functions  40
6.2.1 Voice Unit 40
6.3 I/O Services  42
6.3.1 Data Path Definition 42
6.3.2 I/O Registration Services 43
6.3.3 Data Path States and Operational Model 43
6.3.4 I/O Services Example 44
6.4 Call Detail Record (CDR) Services  44
6.4.1 CDR Services Examples 44
6.5 Capabilities Exchange  46
© ISO/IEC 2000 - All rights reserved iii

6.5.1 Switching Function Capabilities 46
6.5.2 Device Capabilities 47
6.5.3 Dynamic Feature Availability 47
6.6 Switching Function Information Synchronization  47
6.6.1 Switching Function Level Information 48
6.6.2 Device Level Information 48
6.6.3 Call Level Information 48
6.7 Status Reporting Services  48
6.7.1 System Status 48
6.7.2 Monitoring 50
6.7.3 Snapshot Services 53
6.8 Additional Services, Features & Behaviour  53
6.8.1 Forwarding 53
6.8.2 Connection Failure 55
6.8.3 Recall 57
6.8.4 Call Back 57
6.8.5 External Calls 58
6.8.6 Tracking a Diverted Call 59
6.8.7 Media Stream Access 59
6.8.8 Routeing Services 62
6.8.9 Device Maintenance 67
6.8.10 Prompting 67
6.8.11 Telephony Tones Features 67
6.8.12 DTMF and Rotary Pulse Digits Features 67
6.8.13 Data Collection Services 68
7 Association Establishment 68
7.1 Implicit Association  68
7.2 Explicit Association  69
8 Security Service 70
9 Generic Service Requirements 70
9.1 Service Request  70
9.2 Service Response (Acknowledgements)  71
9.2.1 Positive Acknowledgement Models 71
9.2.2 Negative Acknowledgement 72
9.3 Diagnostic Error Definitions  72
9.3.1 Error Categories 72
9.3.2 Error Values 72
9.4 Vendor Specific Extensions  73
9.4.1 Private Data 73
9.4.2 Escape Services and Private Event 74
9.5 General Services and Event Functional Requirements  75
iv © ISO/IEC 2000 - All rights reserved

9.5.1 Services 75
9.5.2 Events 76
10 CSTA Device Identifier Formats 77
10.1 Device Identifier Formats  77
10.1.1 Diallable Digits 77
10.1.2 Switching Function Representation 78
10.1.3 Device Number 80
10.2 Functional Requirements  80
11 Template Descriptions 80
11.1 Service Template  80
11.1.1 Service Description 80
11.1.2 Service Request 81
11.1.3 Service Response 81
11.1.4 Operational Model 82
11.2 Event Template  82
11.2.1 Event Description 82
11.2.2 Event Parameters 82
11.2.3 Event Causes 82
11.2.4 Functional Requirements 83
11.3 Parameter Type Template  83
11.3.1 Parameter Type Description 83
11.3.2 Format 83
11.3.3 Functional Requirements 83
12 Parameter Types 84
12.1 Definitions  84
12.2 Defined Parameter Types 85
12.2.1 AccountInfo 86
12.2.2 AgentPassword 86
12.2.3 AuthCode 86
12.2.4 CallCharacteristics 86
12.2.5 CallLinkageData 87
12.2.6 CallQualifyingData 88
12.2.7 ChargingInfo 89
12.2.8 ConnectionInformation 89
12.2.9 ConnectionList 90
12.2.10 CorrelatorData 90
12.2.11 CSTAPrivateData 91
12.2.12 CSTASecurityData 91
12.2.13 ErrorValue 92
12.2.14 EventCause 102
12.2.15 LocalConnectionState 104
12.2.16 MediaCallCharacteristics 105
12.2.17 MediaServiceType 106
12.2.18 MonitorFilter 107
12.2.19 ServicesPermitted 107
© ISO/IEC 2000 - All rights reserved v

12.2.20 SimpleCallState 108
12.2.21 SystemStatus 109
12.2.22 TimeInfo 109
12.2.23 UserData 109
12.3 Identifier Parameter Types 111
12.3.1 AgentID 112
12.3.2 AssociatedCalledDeviceID 112
12.3.3 AssociatedCallingDeviceID 112
12.3.4 AuditoryApparatusID 113
12.3.5 ButtonID 113
12.3.6 CalledDeviceID 113
12.3.7 CallingDeviceID 114
12.3.8 CDRCrossRefID 114
12.3.9 ConnectionID 114
12.3.10 DCollCrossRefID 116
12.3.11 DeviceID 116
12.3.12 DisplayID 116
12.3.13 EscapeRegisterID 116
12.3.14 HookswitchID 116
12.3.15 IOCrossRefID 116
12.3.16 IORegisterReqID 117
12.3.17 LampID 117
12.3.18 MediaServiceInstanceID 117
12.3.19 MediaStreamID 117
12.3.20 MessageID 117
12.3.21 MonitorCrossRefID 118
12.3.22 NetworkCalledDeviceID 118
12.3.23 NetworkCallingDeviceID 118
12.3.24 RedirectionDeviceID 119
12.3.25 RingerID 119
12.3.26 RouteingCrossRefID 120
12.3.27 RouteRegisterReqID 120
12.3.28 ServiceCrossRefID 120
12.3.29 SubjectDeviceID 120
12.3.30 SysStatRegisterID 121
13 Capability Exchange Services 122
13.1 Services  122
13.1.1 Get Logical Device Information 123
13.1.2 Get Physical Device Information 132
13.1.3 Get Switching Function Capabilities 136
13.1.4 Get Switching Function Devices 151
13.1.5 Switching Function Devices 153
14 System Services 156
14.1 Registration Services  156
14.1.1 Change System Status Filter 157
14.1.2 System Register 159
14.1.3 System Register Abort 162
14.1.4 System Register Cancel 163
14.2 Services 164
vi © ISO/IEC 2000 - All rights reserved

14.2.1 Request System Status 165
14.2.2 System Status 167
14.2.3 Switching Function Capabilities Changed 169
14.2.4 Switching Function Devices Changed 170
15 Monitoring Services 171
15.1 Services  171
15.1.1 Change Monitor Filter 172
15.1.2 Monitor Start 174
15.1.3 Monitor Stop 178
16 Snapshot Services 179
16.1 Services  179
16.1.1 Snapshot Call 180
16.1.2 Snapshot Device 183
16.1.3 Snapshot CallData 186
16.1.4 Snapshot DeviceData 188
17 Call Control Services & Events 190
17.1 Services  190
17.1.1 Accept Call 191
17.1.2 Alternate Call 193
17.1.3 Answer Call 196
17.1.4 Call Back Call-Related 198
17.1.5 Call Back Message Call-Related 201
17.1.6 Camp On Call 204
17.1.7 Clear Call 206
17.1.8 Clear Connection 209
17.1.9 Conference Call 213
17.1.10 Consultation Call 216
17.1.11 Deflect Call 222
17.1.12 Dial Digits 225
17.1.13 Directed Pickup Call 228
17.1.14 Group Pickup Call 231
17.1.15 Hold Call 234
17.1.16 Intrude Call 236
17.1.17 Join Call 240
17.1.18 Make Call 244
17.1.19 Make Predictive Call 250
17.1.20 Park Call 255
17.1.21 Reconnect Call 258
17.1.22 Retrieve Call 260
17.1.23 Single Step Conference Call 262
17.1.24 Single Step Transfer Call 266
17.1.25 Transfer Call 269
17.2 Events  272
17.2.1 Bridged 273
17.2.2 Call Cleared 275
17.2.3 Conferenced 278
17.2.4 Connection Cleared 284
17.2.5 Delivered 288
© ISO/IEC 2000 - All rights reserved vii

17.2.6 Digits Dialled 292
17.2.7 Diverted 295
17.2.8 Established 299
17.2.9 Failed 303
17.2.10 Held 308
17.2.11 Network Capabilities Changed 310
17.2.12 Network Reached 313
17.2.13 Offered 317
17.2.14 Originated 322
17.2.15 Queued 325
17.2.16 Retrieved 329
17.2.17 Service Initiated 331
17.2.18 Transferred 334
18 Call Associated Features 338
18.1 Services  338
18.1.1 Associate Data 339
18.1.2 Cancel Telephony Tones 341
18.1.3 Generate Digits 343
18.1.4 Generate Telephony Tones 345
18.1.5 Send User Information 348
18.2 Events 350
18.2.1 Call Information 351
18.2.2 Charging 353
18.2.3 Digits Generated 354
18.2.4 Telephony Tones Generated 355
18.2.5 Service Completion Failure 358
19 Media Attachment Services & Events 361
19.1 Services  361
19.1.1 Attach Media Service 362
19.1.2 Detach Media Service 366
19.2 Events 369
19.2.1 Media Attached 370
19.2.2 Media Detached 371
20 Routeing Services 373
20.1 Registration Services  373
20.1.1 Route Register 374
20.1.2 Route Register Abort 376
20.1.3 Route Register Cancel 377
20.2 Services 378
20.2.1 Re-Route 379
20.2.2 Route End 380
20.2.3 Route Reject 382
20.2.4 Route Request 384
20.2.5 Route Select 386
viii © ISO/IEC 2000 - All rights reserved

20.2.6 Route Used 388
21 Physical Device Features 390
21.1 Services  390
21.1.1 Button Press 391
21.1.2 Get Auditory Apparatus Information 392
21.1.3 Get Button Information 394
21.1.4 Get Display 396
21.1.5 Get Hookswitch Status 398
21.1.6 Get Lamp Information 399
21.1.7 Get Lamp Mode 401
21.1.8 Get Message Waiting Indicator 404
21.1.9 Get Microphone Gain 405
21.1.10 Get Microphone Mute 406
21.1.11 Get Ringer Status 407
21.1.12 Get Speaker Mute 409
21.1.13 Get Speaker Volume 410
21.1.14 Set Button Information 411
21.1.15 Set Display 412
21.1.16 Set Hookswitch Status 414
21.1.17 Set Lamp Mode 415
21.1.18 Set Message Waiting Indicator 417
21.1.19 Set Microphone Gain 418
21.1.20 Set Microphone Mute 420
21.1.21 Set Ringer Status 421
21.1.22 Set Speaker Mute 423
21.1.23 Set Speaker Volume 424
21.2 Events 426
21.2.1 Button Information 427
21.2.2 Button Press 428
21.2.3 Display Updated 429
21.2.4 Hookswitch 431
21.2.5 Lamp Mode 432
21.2.6 Message Waiting 433
21.2.7 Microphone Gain 434
21.2.8 Microphone Mute 435
21.2.9 Ringer Status 436
21.2.10 Speaker Mute 437
21.2.11 Speaker Volume 438
22 Logical Device Features 439
22.1 Services  439
22.1.1 Call Back Non-Call-Related 440
22.1.2 Call Back Message Non-Call-Related 441
22.1.3 Cancel Call Back 443
22.1.4 Cancel Call Back Message 444
22.1.5 Get Agent State 445
22.1.6 Get Auto Answer 447
22.1.7 Get Auto Work Mode 448
22.1.8 Get Caller ID Status 449
22.1.9 Get Do Not Disturb 450
22.1.10 Get Forwarding 452
© ISO/IEC 2000 - All rights reserved ix

22.1.11 Get Last Number Dialled 455
22.1.12 Get Routeing Mode 456
22.1.13 Set Agent State 457
22.1.14 Set Auto Answer 461
22.1.15 Set Auto Work Mode 463
22.1.16 Set Caller ID Status 465
22.1.17 Set Do Not Disturb 466
22.1.18 Set Forwarding 468
22.1.19 Set Routeing Mode 470
22.2 Events 471
22.2.1 Agent Busy 472
22.2.2 Agent Logged Off 473
22.2.3 Agent Logged On 474
22.2.4 Agent Not Ready 475
22.2.5 Agent Ready 477
22.2.6 Agent Working After Call 478
22.2.7 Auto Answer 480
22.2.8 Auto Work Mode 481
22.2.9 Call Back 482
22.2.10 Call Back Message 483
22.2.11 Caller ID Status 484
22.2.12 Do Not Disturb 485
22.2.13 Forwarding 486
22.2.14 Routeing Mode 488
23 Device Maintenance Events 489
23.1 Events  489
23.1.1 Back In Service 490
23.1.2 Device Capabilities Changed 491
23.1.3 Out Of Service 492
24 I/O Services 493
24.1 Registration Services  493
24.1.1 I/O Register 494
24.1.2 I/O Register Abort 496
24.1.3 I/O Register Cancel 497
24.2 I/O Services 498
24.2.1 Data Path Resumed 499
24.2.2 Data Path Suspended 500
24.2.3 Fast Data 501
24.2.4 Resume Data Path 503
24.2.5 Send Broadcast Data 504
24.2.6 Send Data 506
24.2.7 Send Multicast Data 508
24.2.8 Start Data Path 510
24.2.9 Stop Data Path 512
24.2.10 Suspend Data Path 513
25 Data Collection Services 514
25.1 Services  514
x © ISO/IEC 2000 - All rights reserved

25.1.1 Data Collected 515
25.1.2 Data Collection Resumed 518
25.1.3 Data Collection Suspended 519
25.1.4 Resume Data Collection 520
25.1.5 Start Data Collection 521
25.1.6 Stop Data Collection 523
25.1.7 Suspend Data Collection 524
26 Voice Unit Services & Events 525
26.1 Services  525
26.1.1 Concatenate Message 526
26.1.2 Delete Message 527
26.1.3 Play Message 528
26.1.4 Query Voice Attribute 530
26.1.5 Record Message 532
26.1.6 Reposition 534
26.1.7 Resume 536
26.1.8 Review 537
26.1.9 Set Voice Attribute 539
26.1.10 Stop 541
26.1.11 Suspend 542
26.1.12 Synthesize Message 544
26.2 Events 545
26.2.1 Play 546
26.2.2 Record 547
26.2.3 Review 548
26.2.4 Stop 549
26.2.5 Suspend Play 550
26.2.6 Suspend Record 551
26.2.7 Voice Attribute Changed 552
27 Call Detail Record (CDR) Services 553
27.1 Services  553
27.1.1 Call Detail Records Notification 554
27.1.2 Call Detail Records Report 555
27.1.3 Send Stored Call Detail Records 559
27.1.4 Start Call Detail Records Transmission 561
27.1.5 Stop Call Detail Records Transmission 563
28 Vendor Specific Extensions Services & Events 565
28.1 Registration Services  565
28.1.1 Escape Register 566
28.1.2 Escape Register Abort 567
28.1.3 Escape Register Cancel 568
28.2 Services 569
28.2.1 Escape 570
28.2.2 Private Data Version Selection 571
28.3 Events 572
© ISO/IEC 2000 - All rights reserved xi

28.3.1 Private Event 573
Annex A - Device Appearances 574
Annex B - ISDN User-User Information Element Encoding for CSTA 582
Annex C - Capability Bitmap Parameter Types 584
Annex D - Connection State Transition Examples 635
xii © ISO/IEC 2000 - All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
International Standard ISO/IEC 18051 was prepared by ECMA (as ECMA-269) and was adopted, under a special
"fast-track procedure", by Joint Technical Committee ISO/IEC JTC 1, Information technology, in parallel with its
approval by national bodies of ISO and IEC.
Annexes A, B, and C form a normative part of this International Standard. Annex D is for information only.
© ISO/IEC 2000 - All rights reserved xiii

Introduction
This International Standard defines Phase III of Services for Computer Supported Telecommunications
Applications (CSTA) for OSI Layer 7 communication between a computing network and a telecommunications
network. This International Standard is part of a Suite of Standards and Technical Reports for Phase III of CSTA.
All of the Standards and Technical Reports in the Suite are based on practical experience of ECMA member
companies and each one represents a pragmatic and widely-based consensus.
The evolution of this Suite began with CSTA Phase I, which included the CSTA Services and Protocol Standards
(ECMA-179 and ECMA-180). In Phase II, Technical Report ECMA TR/68 was added illustrating how CSTA
services and events may be used in typical call scenarios.
Phase III of CSTA extends the previous Phase II Standards (ECMA-217 and ECMA-218) in major theme directions
as well as numerous details. This incorporates technology based upon the versit CTI Encyclopedia (Version 1.0),
which was contributed to ECMA by versit. Major areas of advancement include:
 New categories of services and events such as capabilities exchange, charging, media attachment services, call
data recording (CDR), etc.
 Additional services and events for call and device control.
 Enhancement to existing services and events.
 Organization of services and events to reflect a grouping based on function (call control, device control, etc.).
 Use of a consistent template for services and events that includes initial/final connection state, connection state
transitions, event monitoring sequences, etc.
xiv © ISO/IEC 2000 - All rights reserved

INTERNATIONAL STANDARD
Information technology - Telecommunications and information exchange
between systems - Services for Computer Supported Telecommunications
Applications (CSTA) Phase III
1 Scope
This International Standard specifies the Services and Event Reports for Computer-Supported Telecommunications
Applications, Phase III (CSTA).
This International Standard is focused on providing application service interfaces to a Switching Function,
Computing Function and a Special Resource Function. A CSTA application interface is disassociated from the
various user-network interfaces and network-network interfaces CSTA applications may serve, observe or
manipulate. Because CSTA operates with existing telecommunications interfaces indirectly, it operates generically,
so that differences among various existing interfaces are hidden from CSTA applications. Support of user-to-
network interfaces is outside the scope of CSTA.
Although most terminal equipment (TE) are suitable for use with CSTA there will be instances of TE that will not
be suitable in certain circumstances. Examples are:
 FAX terminals and modems that are unable to adjust their transmission modes to prevent carrier conflict when
both parties are alerted via CSTA during call establishment;
 Functional terminals that perform telecommunication functions outside the control of the Switching Function.
Services defined in this International Standard allow functional integration between a computing network and a
telecommunications network. Computing platforms (i.e., Application Programming Interfaces - APIs) that support
such functionally-integrated applications are outside the scope of this International Standard.
Communication between the computing and switching (i.e., telecommunications) networks may take place via
intervening networks ranging from simple point-to-point connections to local- or wide-area telecommunications
networks.
This International Standard is part of a suite of CSTA Standards and Technical Reports that provide a
comprehensive description of the architectural and practical issues involved in applying, implementing, and
utilizing CSTA-based CTI applications.
2 Normative References
The following normative documents contain provisions which, through reference in this text, constitute provisions
of this International Standard. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this International Standard are encouraged to
investigate the possibility of applying the most recent editions of the normative documents indicated below. For
undated references, the latest edition of the normative document referred to applies. Members of IEC and ISO
maintain registers of currently valid International Standards.
ISO/IEC 8649:1996, Information technology - Open Systems Interconnection - Service definition for the
Association Control Service Element (this corresponds to ITU-T Rec. X.217 1995).
ISO/IEC 9545:1994, Information technology - Open Systems Interconnection - Application Layer
structure.
ISO/IEC 11571:1998, Information technology - Telecommunications and information exchange between
systems - Private Integrated Services Network - Addressing.
© ISO/IEC 2000 - All rights reserved 1

ISO/IEC 11572:2000, Information technology - Telecommunications and information exchange between
systems - Private Integrated Services Network - Circuit mode bearer services -
Inter-exchange signalling procedures and protocol.
ISO/IEC 13712-1:1995, Information technology - Remote Operations: Concepts, model, and notation (this
corresponds to ITU-T Rec. X.880, 1994).
ISO/IEC TR 18053:2000, Information technology - Telecommunications and information exchange between
systems - Glossary of definitions and terminology for Computer Supported
Telecommunications Applications (CSTA) Phase III.
ITU-T Rec. E.131:1988, Subscriber Control Procedures for Supplementary Telephone Services.
ITU-T Rec. E.161:1995, Arrangement of Digits, Letters and Symbols on Telephones and Other Devices that
can be used for Gaining Access to a Telephone Network.
ITU-T Rec. E.164:1997, The International Public Telecommunication Numbering Plan.
ITU-T Rec. H.225:1998, Call Signalling Protocols and Media Stream Packetization for Packet-based
Multimedia Communications Systems.
ITU-T Rec. Q.931:1998, ISDN User-Network Interface layer 3 Specification for Basic Call Control.
3 Conformance
This Clause specifies the conformance requirements for a Switching Function, Special Resource Function, and a
Computing Function.
Conformance requirements specify the parts of this International Standard that a CSTA conformant implementation
shall support.
This International Standard specifies an operational model (Clause 6, “CSTA Operational Model” and Clause 9,
“Generic Service Requirements”) that defines a collection of objects (e.g. domains and sub-domains, logical and
physical elements, calls) and the relationships between these objects.
The behaviours of CSTA-conformant services, features, and event reports are determined by this model.
3.1 Switching Function
In order to conform to this International Standard a switching function shall support the following as a minimum:
1. the requirements pertaining to CSTA features as specified in Clause 6, “CSTA Operational Model”.
2. the requirements as specified in Clause 9, “Generic Service Requirements”.
3. the Get Switching Function Capability service.
4. either the Implicit or Explicit Application Association Establishment sequence, including the mandatory
aspects in the sequence (such as the System Status service), as specified in Figure 7-1 and Figure 7-2.
5. at least one of the profiles as specified in 3.1.3, “CSTA Profiles”.
3.1.1 Conformant Services
In order to conform to a specific CSTA service an implementation shall support the following as a minimum:
1. the requirements of the service as specified by its service description, service request parameters, service
response parameters, and operational model including connection state transitions, monitoring event
sequences, and functional requirements.
2. the requirements associated with each parameter used in the service as specified by its parameter description,
format, and functional requirements in Clause 12, “Parameter Types”.
3. all of the events that are associated with its service completion criteria, as documented in its event monitoring
tables.
4. service requests that contain a device identifier parameter, an implementation shall support, at a minimum, the
Diallable Digits format as specified in 10.1.1, “Diallable Digits”.
2 © ISO/IEC 2000 - All rights reserved

3.1.2 Conformant Events
In order to conform to a specific CSTA event an implementation shall support the following as a minimum:
1. the requirements of the event as specified by its event description, event parameters, event causes, and
functional requirements.
2. the requirements associated with each parameter used in the event as specified by its parameter description,
format, and functional requirements in Clause 12, “Parameter Types”.
3. events that contain a device identifier parameter, an implementation shall support, at a minimum, the
Switching Function Representation format as specified in 10.1.2, “Switching Function Representation”.
3.1.3 CSTA Profiles
Some CSTA services and events are grouped together as profiles.
3.1.3.1 Basic Telephony Profile
This profile includes the following:
1. CSTA Services: Answer Call, Clear Connection, Make Call, Monitor Start (with the monitorType of device-
type), and Monitor Stop.
2. CSTA Events: Connection Cleared, Delivered, Established, Failed, Network Reached, Originated, and Service
Initiated.
Other CSTA services and events may be provided in any combination in addition to this set.
3.1.3.2 Routeing Profile
If the switching function supports Routeing Services as specified in Clause 20, “Routeing Services”, it shall support
a minimum set of Routeing Services that includes: Route Request, Route Select, and Route End (from the switching
function only).
Other Routeing services may be provided in any combination in addition to this set.
If a switching function supports the routeing for digital data calls, then the Route Register and CSTA Route
Register Cancel shall also be included in the minimum set.
3.1.4 Support of Service Requests And Manual Mode
A conformant switching function may support a given service defined in this International Standard through the
CSTA service boundary but is not required to support the equivalent service in a manual mode.
A conformant switching function may support a feature associated with an equivalent CSTA service defined in this
International Standard through manual mode but is not required to support the equivalent service through the
service boundary.
3.2 Special Resource Function Conformance
In order to conform to this International Standard a special resource function shall support the following as a
minimum:
1. the requirements pertaining to CSTA features as specified in Clause 6, “CSTA Operational Model”.
2. the requirements as specified in Clause 9, “Generic Service Requirements”.
3. for a supported service, the special resource function shall not reject as unsupported all of the events specified
in the monitoring event sequences associated with the service.
4. the atomic service request acknowledgment model as specified in 9.2, “Service Response
(Acknowledgements)”.
3.2.1 Conformant Services
In order to conform to a specific CSTA service an implementation shall support the following as a minimum:
1. the requirements of the service as specified by its service description, service request parameters, service
response parameters, and operational model including connection state transitions, monitoring event
sequences, and functional requirements.
© ISO/IEC 2000 - All rights reserved 3

2. the requirements associated with each parameter used in the service as specified by its parameter description,
format, and functional requirements in Clause 12, “Parameter Types”.
3. all of the events that are associated with its service completion criteria, as documented in its event monitoring
tables.
3.2.2 Conformant Events
In order to conform to a specific CSTA event an implementation shall support the following as a minimum:
1. the requirements of the event as specified by its event description, event parameters, event causes, and
functional requirements.
2. the requirements associated with each parameter used in the event as specified by its parameter description,
format, and functional requirements in Clause 12, “Parameter Types”.
3.2.3 Support of Service Requests And Manual Mode
A conformant special resource function may support a given service defined in this International Standard through
the CSTA service boundary but is not required to support the equivalent service in a manual mode.
A conformant special resource function may support a feature associated with an equivalent CSTA service defined
in this International Standard through manual mode but is not required to support the equivalent service through the
service boundary.
3.3 Computing Function Conformance
In order to conform to this International Standard a computing function shall support the following as a minimum:
1. the requirements pertaining to CSTA features as specified in Clause 6, “CSTA Operational Model”.
2. the requirements as specified in Clause 9, “Generic Service Requirements”.
3. for a supported service, the computing function shall not reject as unsupported all of the events specified in
the monitoring event sequences associated with the service.
4. the “Single Physical and Logical Element” and “Logical Element Only” device configurations as specified in
6.1.3.3, “Device Configurations”.
5. for service requests, the Diallable Digits format of Device Identifiers as specified in 10.1.1, “Diallable
Digits”.
6. for events, all formats of Device Identifiers as specified in 10.1, “Device Identifier Formats”.
7. the “No Appearance Addressability” and the “Individual Appearance Addressability” of referencing device
elements as specified in 6.1.7, “Referencing Devices, Elements, Appearances and Device Configurations”.
8. both types of service request acknowledgment models (e.g., Atomic and Multi-Step) as specified in 9.2,
“Service Response (Acknowledgements)”.
9. all failure models as specified in 6.8.2, “Connection Failure”.
10. both switching function options of handling unsupported parameters in service requests as specified in the
capability exchange services.
11. both the fixed and local view of the primaryOldCall and the secondaryOldCall parameters in the Conferenced
and the Transferred events.
12. all bi-directional services for which it registered, whether explicitly (i.e., via a service registration service such
as System Status Register) or implicitly (i.e., the switching function does not support registration but does
support (as indicated through the capabilities exchange services) a particular bi-directional service and
therefore may issue a service request to the computing function).
13. both the Implicit and Explicit Application Association Establishment sequences as specified in Clause 7,
“Association Establishment”.
4 © ISO/IEC 2000 - All rights reserved

4 Definitions and Abbreviations
The definitions and abbreviations used in this International Standard are defined in ISO/IEC TR 18053.
5 Functional Architecture
The objective of CSTA Architecture is to define the inter working mechanisms among Computing, Switching and
Special Resource Functions independently from their physical implementations.
The concepts of: distribution of Computing, Switching and Special Resource Functions, CSTA Service, client
server model, and CSTA objects as abstracted at a CSTA Service Boundary, are specified in another part of the
CSTA Phase III Suite.
6 CSTA Operational Model
The operational model considered for CSTA is summarized in this clause.
The set of accessible Computing, Switching and Special Resource Functions from which an application might
receive service defines a CSTA domain. An example of a CSTA domain is shown in the next figure. The CSTA
domain contains switching, computing and special resource domains that are divided in the figure by the heavy
lines. The special resource, switching and computing domains comprise Computing Functions (C1, C2 and C3),
Switching Functions (S1, S2 and S3), and Special Resource Functions (SR1, SR2 and SR3). Each function can
provide to a CSTA application, a view of the domain in which the function resides. Each such view defines a sub-
domain. If one or more functions provides an identical view, then these functions are part of the same sub-domain.
CSTA applications encompass at least two different sub-domains, and are represented in the next figure as
application domains.
Figure 6-1 Domains and Sub-Domains
Switching
Computing
Sub-domain
Sub-domain
S1
Application
Domains
C1
Application
Domain
S2
Switching
Computing
Sub-domain
S3
Sub-domain
C2
C3
SR3
SR1
SR2
Special Resource
Special Resource
Sub-domain
Sub-domain
Note that a function may provide a view to an application that includes not only the objects within its sub-domain,
but also the objects it can view in another (presumably related) sub-domain. For example (in Figure 6-1), a
computing domain {C1} may receive a view of a switching sub-domain from a switching domain {S2+S3}. That
© ISO/IEC 2000 - All rights reserved 5

switching sub-domain may receive a view of a special resource sub-domain from a special resource domain {SR1},
and relay that view, in addition to the view of its sub-domain, to the Computing Function. This relay may preserve
two views of separate switching and special resource sub-domains, or it may provide a combined view of a
switching/special-resource sub-domain. As shown in the figure, {C1} also may have its own, direct view of a
special resource sub-domain {SR2+SR3}. Finally, {C2+C3} represent a computing domain that is potentially, but
not yet, involved in CSTA transactions with other sub-domains because an association has not yet been established
between any other sub-domain and {C2+C3}.
6.1 Switching Sub-Domain Model
The tools needed to provide an abstract view of the Switching Function are defined by the switching sub-domain
model. This model allows an application to conceptualize the Switching Function’s operation. To provide this
abstract view, CSTA defines several CSTA switching sub-domain model Objects that can be observed and acted
upon by the Switching Function on behalf of the Computing Function. Those objects include CSTA Devices, Calls,
and Connections.
6.1.1 Switching Sub-Domain Name
The switching function is identified by a unique name within the switching domain known at association time. This
name may be used by the computing function to identify that different CSTA applications resulting from different
associations are operating in the same switching sub-domain.
6.1.2 Application Working Domain
The application working domain is the subset of devices (and the calls and connections associated with those
devices) inside a switching sub-domain that are controllable and/or monitorable over a CSTA Service Boundary.
This subset is known at association time. The scope of this working domain may result from considerations like the
application’s design, licensing policy, security constraints, etc., and is under administration of the switching sub-
domain. Different CSTA applications operating in the same switching sub-domain can have different working
domains or share totally or partially the same working domain.
6.1.3 Device
CSTA enables manipulation and observation of devices that allow users to access telecommunications services.
Note 1 - It is not claimed that this International Standard alone supports ISDN (or any other) devices because, for example, of the additional
information required to support such devices in PISNs. CSTA only provides a facility for passing ISDN (or other) specific information to allow,
for example, a selection among ISDN devices sharing the same directory number (bearer capability, subaddress, etc.). Another example, that
applies generally to telecommunications networks (including ISDN and OSI), is specifying the originator for a call that is established via CSTA.
With the current signalling support, each party in a call can act only as a called party because the “network” is acting to originate the call. This
situation has implications for both the network-to-terminal signalling and any application-level signalling that is significant to the calling party
(e.g., issuing A_Associate).
Devices that are visible or controllable via CSTA are known as CSTA Devices.
CSTA Devices can be either physical devices (such as buttons, lines, trunks, and stations) or logical devices (such
as groups of devices, pilot numbers, and automatic call distribution groups). CSTA Devices have attributes that
allow CSTA to monitor and manipulate them. The attributes of any CSTA Device shall be:
1. Device Type - differing types of CSTA Device can be used for various purposes and can be manipulated and
observed differently within CSTA. CSTA Device Types are listed and defined in 6.1.3.4, “Device Categories”.
2. Media Characteristics - CSTA devices have distinct capabilities and characteristics defined by their media
features. CSTA represents these characteristics by the following attributes.
 Media Class: A CSTA Device shall belong to at least one and may belong to more than one media class.
The Media Class can be used in Call Control services to help select a device for a call or it can be used in
call control events to report the media class associated with the call. The following media classes are
defined in CSTA:
 Audio - 3.1 KHz audio. Devices in this class are used to make audio calls excluding speech calls. It
includes G3 FAX and facsimile machines.
 Data - Devices in this class are used to make digital data calls (both circuit switched and packet
switched). This class includes digital computer interfaces and G4 facsimile machines.
6 © ISO/IEC 2000 - All rights reserved

 Image - Devices in this class are used to make digital data calls involving imaging, or high-speed,
circuit-switched data in general. This class includes digital video telephones and CODECs.
 Voice - Devices in this class are used to make speech calls. This class includes standard telephones.
 Other - A class comprising devices not in the Data, Image, Audio or Voice classes.
 Media Stream Information: The media stream associated with a CSTA Device has attributes such as
Connection Rate, Bit Rate, and Delay Tolerance. This information can be used in CSTA services to
help select the media stream information for a call or to report the media stream information associated
with an existing call.
 Protocol Specific Information: Many protocols provide additional information beyond what is
standardized in CSTA to help distinguish devices. CSTA provides a mechanism where protocol specific
information can be passed in CSTA messages to help select a specific device for a call or to provide
additional information about the protocol specific information associated with the call. This information
consists of:
 The type of call control information elements (ISDN, for example).
 A character string that contains the protocol specific information elements. For example, in ISDN,
the information may include Bearer Capability, Subaddress (for both calling and called devices),
High Layer compatibility, and Low Layer compatibility as defined in IS 11572: 1993.
Refer to 12.2.16, “MediaCallCharacteristics”, for a description of the Media Characteristics that are used in
Call Control services to select devices for a call and in Call Control events to report the media Characteristics
associated with the devices involved with the call.
3. CSTA Device Identifier - Each device that can be observed and/or manipulated shall be referenced across the
CSTA Service Boundary. To accomplish this, each device shall be identified using a Device Identifier.
 Throughout this standard, the term Device Identifier shall always mean CSTA Device Identifier.
 Device Identifiers may be static or, only when used in the context of a connection identifier, dynamically-
assigned.
 A static Device Identifier shall be stable over time. It shall remain constant and unique between calls,
associations and within both the switching and computing functions. An example of a static Device
Identifier is an ITU-T E.164 Directory Number.
 It may be useful for the Switching Function to convert a Device Identifier to another static form for use in
service interactions. An example, it might be useful to transform a Public Directory Number into a Private
Directory Number. This transformation allows service interactions to be independent of the identification
mechanism and allows reduction in the amount of data exchanged. This shortened form of Device
Identifier is known as a CSTA Short Form Device Identifier.
 A static Device Identifier may be used in conjunction with “MediaCallCharacteristics”, as specified in
12.2.16, “MediaCallCharacteristics”, on page 105, in order to distinguish among CSTA Devices that
share a Device Identifier.
 A dynamically-assigned Device Identifier is temporary (lasting for the duration of a call) and may be
created at any appropriate time. Once a CSTA Device has been included in a call, it may be desirable to
continue to refer to the particular instance of the CSTA Device associated with this call for manipulation
or tracking. A static Device Identifier may not always be sufficient because it may not be available or
because it is too long and cumbersome for efficient use. In these cases the Switching Function can
dynamically assign a Device Identifier as a device reference or handle for the duration of the call.
Management of the dynamically-assigned Device Identifier is discussed in 6.1.8.
The Device Identifier Status indicates if an actual Device Identifier is being provided in a parameter or
the reason why it is not being provided. The set of possible values for the Device Identifier Status is:
 Provided - A Device Identifier is present.
© ISO/IEC 2000 - All rights reserved 7

 Not Known - Indicates that the switching function cannot provide the Device Identifier but knows
that the device exists.
 Not Required - Indicates that the device is not relevant in this case.
 Not Specified - Indicates that the device cannot be specified.
 The parameter type associated with a particular Device Identifier determines how it is interpreted,
restrictions on its use, and the Device Identifier Statuses that are applicable. These parameter types
(AssociatedCalledDeviceID, AssociatedCallingDeviceID, CallingDeviceID, CalledDeviceID, DeviceID,
RedirectionDeviceID, and SubjectDeviceID) are specified in 12.3, “Identifier Parameter Types”, on page
111.
 The format of a Device Identifier is specified in Clause 10, “CSTA Device Identifier Formats”.
4. Device State - A CSTA Device itself does not have a state or status directly associated with it. The elements,
components and calls associated with the CSTA Device do have states and statuses associated with them. The
following is the list of these states and statuses associated with a CSTA Device:
 A connection state is the state of a CSTA Device’s logical element’s connection into a call. This state is
associated with Call Control features/services. For more information on connection states, refer to Clause
6.1.5, “Connection”, beg
...