ECMA-269 9th Edition / December 2011
Services for Computer Supported Telecommunications Applications (CSTA) Phase III
Reference number ECMA-123:2009
© Ecma International 2009
COPYRIGHT PROTECTED DOCUMENT
© Ecma International 2011
Brief History This Standard defines Phase III of Services for Computer Supported Telecommunications Applications (CSTA). This 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. Phase III of CSTA extends the previous Phase I and Phase II Standards 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. This 9th edition of ECMA-269 includes: •
new features to establish and control the presence state of logical devices
•
new call control features to detect call linkage information with service results
•
new cause values to indicate call interception
“COPYRIGHT NOTICE This document may be copied, published and distributed to others, and certain derivative works of it may be prepared, copied, published, and distributed, in whole or in part, provided that the above copyright notice and this Copyright Licence and Disclaimer are included on all such copies and derivative works. The only derivative works that are permissible under this Copyright License and Disclaimer are: (i) works which incorporate all or portion of this document for the purpose of providing commentary or explanation (such as an annotated version of the document), (ii) works which incorporate all or portion of this document for the purpose of incorporating features that provide accessibility, (iii) translations of this document into languages other than English and into different formats and (iv) works by making use of this specification in standard conformant products by implementing (e.g. by copy and paste wholly or partly) the functionality therein. However, the content of this document itself may not be modified in any way, including by removing the copyright notice or references to Ecma International, except as required to translate it into languages other than English or into a different format. The official version of an Ecma International document is the English language version on the Ecma International website. In the event of discrepancies between a translated version and the official version, the official version shall govern. The limited permissions granted above are perpetual and will not be revoked by Ecma International or its successors or assigns. This document and the information herein is provided on an “AS IS” basis and ECMA INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.” Adopted as 9th Edition of Standard ECMA-269 by the General Assembly of December 2011.
Table of Contents 1 Scope
1
2 Conformance
1
2.1
2.2
2.3
Switching Function
2
2.1.1
Conformant Services
2
2.1.2
Conformant Events
2
2.1.3
CSTA Profiles
2
2.1.4
Support of Service Requests And Manual Mode
5
Special Resource Function Conformance
5
2.2.1
Conformant Services
5
2.2.2
Conformant Events
5
2.2.3
Support of Service Requests And Manual Mode
5
Computing Function Conformance
6
3 References
6
4 Definitions and Abbreviations
7
5 Functional Architecture
7
6 CSTA Operational Model
7
6.1
6.2
6.3
Switching Sub-Domain Model Device
8
6.1.2
Call
41
6.1.3
Connection
49
6.1.4
Call State Definitions
53
6.1.5
Referencing Devices, Elements, Appearances and Device Configurations
54
6.1.6
Management of Dynamically-Assigned Identifiers
56
I/O Services
6.5
56
6.2.1
Data Path Definition
57
6.2.2
I/O Registration Services
58
6.2.3
Data Path States and Operational Model
58
6.2.4
I/O Services Example
58
Call Detail Record (CDR) Services 6.3.1
6.4
8
6.1.1
CDR Services Examples
Capabilities Exchange
59 59
61
6.4.1
Switching Function Capabilities
61
6.4.2
Device Capabilities
62
6.4.3
Dynamic Feature Availability
62
Switching Function Information Synchronization
63
6.5.1
Switching Function Level Information
63
6.5.2
Device Level Information
63
-i-
6.5.3
6.6
6.8
63
Status Reporting Services 6.6.1
6.7
Call Level Information
64
System Status
64
6.6.2
Monitoring
65
6.6.3
Snapshot Services
69
Additional Services, Features & Behaviour
69
6.7.1
Forwarding
69
6.7.2
Connection Failure
71
6.7.3
Recall
73
6.7.4
Call Back
73
6.7.5
External Calls
74
6.7.6
Tracking a Diverted Call
75
6.7.7
Media Stream Access
75
6.7.8
Routeing Services
79
6.7.9
Device Maintenance
84
6.7.10
Prompting
84
6.7.11
Telephony Tones Features
84
6.7.12
DTMF and Rotary Pulse Digits Features
84
6.7.13
Data Collection Services
85
Location Features
85
6.8.1
Location Information
85
6.8.2
Polling for Location Information
87
6.8.3
Location Information in Call Control Events
87
6.8.4
Location Tracking Session
87
6.8.5
Setting Location Information
90
7 Association Establishment
91
7.1
Implicit Association created using CSTA System Status service (initiated by Switching Function) 92
7.2
Implicit Association created using CSTA Request System Status service
92
7.3
Explicit Association created using ACSE
93
7.4
Explicit Association created using Ecma Application Session (ECMA-354) Services
94
8 Security Service
95
9 Generic Service Requirements
95
9.1
Service Request
95
9.2
Service Response (Acknowledgements)
96
9.3
9.2.1
Positive Acknowledgement Models
96
9.2.2
Negative Acknowledgement
97
Diagnostic Error Definitions
97
9.3.1
Error Categories
97
9.3.2
Error Values
98
- ii -
9.4
9.5
Vendor Specific Extensions
98
9.4.1
Private Data
99
9.4.2
Escape Services and Private Event
99
General Services and Event Functional Requirements
100
9.5.1
Services
100
9.5.2
Events
102
10 CSTA Device Identifier Formats
102
10.1
Device Identifier Formats
102
10.1.1
Diallable Digits
103
10.1.2
Switching Function Representation
104
10.1.3
Device Number
106
10.1.4
URI Representation
106
10.2
DeviceID Tags
106
10.3
Functional Requirements
107
11 Template Descriptions
107
11.1
11.2
11.3
Service Template
107
11.1.1
Service Description
107
11.1.2
Service Request
108
11.1.3
Service Response
109
11.1.4
Operational Model
109
Event Template
109
11.2.1
Event Description
109
11.2.2
Event Parameters
109
11.2.3
Event Causes
110
11.2.4
Functional Requirements
110
Parameter Type Template
110
11.3.1
Parameter Type Description
110
11.3.2
Format
110
11.3.3
Functional Requirements
110
12 Parameter Types
111
12.1
Definitions
111
12.2
Defined Parameter Types
112
12.2.1
AccountInfo
113
12.2.2
AgentPassword
113
12.2.3
AuthCode
113
12.2.4
CallCharacteristics
114
12.2.5
CallLinkageData
114
12.2.6
CallQualifyingData
116
12.2.7
ChargingInfo
116
12.2.8
ConnectionInformation
117
- iii -
12.3
12.2.9
ConnectionList
118
12.2.10
CorrelatorData
119
12.2.11
CSTAPrivateData
119
12.2.12
CSTASecurityData
120
12.2.13
DeviceHistory
120
12.2.14
ErrorValue
121
12.2.15
EventCause
132
12.2.16
LanguagePreferences
136
12.2.17
LocalConnectionState
136
12.2.18
LocationInfo
137
12.2.19
LocationInfoList
138
12.2.20
MediaCallCharacteristics
138
12.2.21
MediaServiceType
140
12.2.22
MessageInfo
141
12.2.23
MonitorFilter
141
12.2.24
PresenceState
142
12.2.25
ServicesPermitted
142
12.2.26
SimpleCallState
143
12.2.27
SubjectOfCall
144
12.2.28
SystemStatus
144
12.2.29
TimeInfo
144
12.2.30
UserData
145
Identifier Parameter Types
146
12.3.1
AgentID
147
12.3.2
AssociatedCalledDeviceID
147
12.3.3
AssociatedCallingDeviceID
147
12.3.4
AuditoryApparatusID
148
12.3.5
ButtonID
148
12.3.6
CalledDeviceID
148
12.3.7
CallingDeviceID
149
12.3.8
CDRCrossRefID
149
12.3.9
ConnectionID
149
12.3.10
DCollCrossRefID
151
12.3.11
DeviceID
151
12.3.12
DisplayID
152
12.3.13
EscapeRegisterID
152
12.3.14
HookswitchID
152
12.3.15
IOCrossRefID
152
12.3.16
IORegisterReqID
152
12.3.17
LampID
153
12.3.18
MediaServiceInstanceID
153
12.3.19
MediaStreamID
153
12.3.20
MessageID
153
12.3.21
MonitorCrossRefID
153
- iv -
12.3.22
NetworkCalledDeviceID
153
12.3.23
NetworkCallingDeviceID
154
12.3.24
RedirectionDeviceID
154
12.3.25
ResourceID
155
12.3.26
RingerID
155
12.3.27
RouteingCrossRefID
155
12.3.28
RouteRegisterReqID
156
12.3.29
ServiceCrossRefID
156
12.3.30
SubjectDeviceID
156
12.3.31
SysStatRegisterID
157
13 Capability Exchange Services 13.1
Services 13.1.1
158 Get CSTA Features
159
13.1.2
Get Logical Device Information
161
13.1.3
Get Physical Device Information
170
13.1.4
Get Switching Function Capabilities
174
13.1.5
Get Switching Function Devices
190
13.1.6
Switching Function Devices
192
14 System Services 14.1
14.2
196
Registration Services
196
14.1.1
Change System Status Filter
197
14.1.2
System Register
199
14.1.3
System Register Abort
202
14.1.4
System Register Cancel
203
Services
204
14.2.1
Request System Status
205
14.2.2
System Status
207
14.2.3
Switching Function Capabilities Changed
209
14.2.4
Switching Function Devices Changed
210
14.2.5
Get Registrations
211
14.2.6
Registration Info
214
15 Monitoring Services 15.1
158
216
Services
216
15.1.1
Change Monitor Filter
217
15.1.2
Monitor Start
219
15.1.3
Monitor Stop
223
15.1.4
Get Monitors
224
15.1.5
Monitor Info
226
16 Snapshot Services
228
16.1
Services
228 -v-
16.1.1
Snapshot Call
229
16.1.2
Snapshot Device
232
16.1.3
Snapshot CallData
235
16.1.4
Snapshot DeviceData
238
17 Call Control Services & Events 17.1
17.2
Services
241 241
17.1.1
Accept Call
243
17.1.2
Alternate Call
245
17.1.3
Answer Call
248
17.1.4
Call Back Call-Related
250
17.1.5
Call Back Message Call-Related
253
17.1.6
Camp On Call
256
17.1.7
Clear Call
258
17.1.8
Clear Connection
261
17.1.9
Conference Call
265
17.1.10
Consultation Call
269
17.1.11
Deflect Call
275
17.1.12
Dial Digits
281
17.1.13
Directed Pickup Call
284
17.1.14
Group Pickup Call
288
17.1.15
Hold Call
292
17.1.16
Intrude Call
294
17.1.17
Join Call
299
17.1.18
Make Call
304
17.1.19
Make Connection
310
17.1.20
Make Predictive Call
315
17.1.21
Park Call
321
17.1.22
Reconnect Call
324
17.1.23
Retrieve Call
326
17.1.24
Send Message
328
17.1.25
Single Step Conference Call
333
17.1.26
Single Step Transfer Call
338
17.1.27
Transfer Call
342
Events 17.2.1
345 Bridged
346
17.2.2
Call Cleared
348
17.2.3
Conferenced
351
17.2.4
Connection Cleared
357
17.2.5
Delivered
361
17.2.6
Digits Dialled
366
17.2.7
Diverted
369
17.2.8
Established
374
17.2.9
Failed
380
- vi -
17.2.10
Held
385
17.2.11
Network Capabilities Changed
387
17.2.12
Network Reached
390
17.2.13
Offered
394
17.2.14
Originated
399
17.2.15
Queued
402
17.2.16
Retrieved
406
17.2.17
Service Initiated
408
17.2.18
Transferred
412
18 Call Associated Features 18.1
18.2
Services
417
18.1.1
Associate Data
418
18.1.2
Cancel Telephony Tones
420
18.1.3
Change Connection Information
422
18.1.4
Generate Digits
425
18.1.5
Generate Telephony Tones
428
18.1.6
Send User Information
431
Events
433
18.2.1
Call Information
434
18.2.2
Charging
437
18.2.3
Digits Generated
438
18.2.4
Telephony Tones Generated
440
18.2.5
Service Completion Failure
443
19 Media Attachment Services & Events 19.1
19.2
Services
20.2
446 446
19.1.1
Attach Media Service
447
19.1.2
Detach Media Service
451
Events
454
19.2.1
Media Attached
455
19.2.2
Media Detached
456
20 Routeing Services 20.1
417
458
Registration Services
458
20.1.1
Route Register
459
20.1.2
Route Register Abort
462
20.1.3
Route Register Cancel
463
Services
464
20.2.1
Re-Route
465
20.2.2
Route End
467
20.2.3
Route Reject
469
20.2.4
Route Request
471
20.2.5
Route Select
474
- vii -
20.2.6
Route Used
476
21 Physical Device Features 21.1
21.2
478
Services
478
21.1.1
Button Press
479
21.1.2
Get Auditory Apparatus Information
480
21.1.3
Get Button Information
482
21.1.4
Get Display
484
21.1.5
Get Hookswitch Status
486
21.1.6
Get Lamp Information
487
21.1.7
Get Lamp Mode
489
21.1.8
Get Message Waiting Indicator
492
21.1.9
Get Microphone Gain
493
21.1.10
Get Microphone Mute
494
21.1.11
Get Ringer Status
495
21.1.12
Get Speaker Mute
497
21.1.13
Get Speaker Volume
498
21.1.14
Set Button Information
499
21.1.15
Set Display
500
21.1.16
Set Hookswitch Status
502
21.1.17
Set Lamp Mode
503
21.1.18
Set Message Waiting Indicator
505
21.1.19
Set Microphone Gain
506
21.1.20
Set Microphone Mute
508
21.1.21
Set Ringer Status
509
21.1.22
Set Speaker Mute
511
21.1.23
Set Speaker Volume
512
Events
514
21.2.1
Button Information
515
21.2.2
Button Press
516
21.2.3
Display Updated
517
21.2.4
Hookswitch
519
21.2.5
Lamp Mode
520
21.2.6
Message Waiting
521
21.2.7
Microphone Gain
522
21.2.8
Microphone Mute
523
21.2.9
Ringer Status
524
21.2.10
Speaker Mute
526
21.2.11
Speaker Volume
527
22 Logical Device Features 22.1
528
Services
528
22.1.1
Call Back Non-Call-Related
529
22.1.2
Call Back Message Non-Call-Related
530
- viii -
22.2
22.1.3
Cancel Call Back
532
22.1.4
Cancel Call Back Message
533
22.1.5
Get Agent State
534
22.1.6
Get Auto Answer
536
22.1.7
Get Auto Work Mode
538
22.1.8
Get CallBack
539
22.1.9
Get Caller ID Status
541
22.1.10
Get Do Not Disturb
542
22.1.11
Get Forwarding
544
22.1.12
Get Last Number Dialled
547
22.1.13
Get Presence State
548
22.1.14
Get Routeing Mode
549
22.1.15
Set Agent State
550
22.1.16
Set Auto Answer
554
22.1.17
Set Auto Work Mode
556
22.1.18
Set Caller ID Status
558
22.1.19
Set Do Not Disturb
559
22.1.20
Set Forwarding
561
22.1.21
Set Presence State
563
22.1.22
Set Routeing Mode
565
Events
567
22.2.1
Agent Busy
568
22.2.2
Agent Logged Off
569
22.2.3
Agent Logged On
570
22.2.4
Agent Not Ready
571
22.2.5
Agent Ready
573
22.2.6
Agent Working After Call
574
22.2.7
Auto Answer
576
22.2.8
Auto Work Mode
577
22.2.9
Call Back
578
22.2.10
Call Back Message
579
22.2.11
Caller ID Status
580
22.2.12
Do Not Disturb
581
22.2.13
Forwarding
582
22.2.14
Presence State
585
22.2.15
Routeing Mode
586
23 Device Maintenance Events 23.1
Events 23.1.1
587 587
Back In Service
588
23.1.2
Device Capabilities Changed
589
23.1.3
Out Of Service
590
23.1.4
Partially In Service
591
- ix -
24 I/O Services 24.1
24.2
593
Registration Services
593
24.1.1
I/O Register
594
24.1.2
I/O Register Abort
596
24.1.3
I/O Register Cancel
597
I/O Services
598
24.2.1
Data Path Resumed
599
24.2.2
Data Path Suspended
600
24.2.3
Fast Data
601
24.2.4
Resume Data Path
604
24.2.5
Send Broadcast Data
605
24.2.6
Send Data
607
24.2.7
Send Multicast Data
609
24.2.8
Start Data Path
611
24.2.9
Stop Data Path
613
24.2.10
Suspend Data Path
614
25 Data Collection Services
615
25.1
Services
615
25.1.1
Data Collected
616
25.1.2
Data Collection Resumed
619
25.1.3
Data Collection Suspended
620
25.1.4
Resume Data Collection
621
25.1.5
Start Data Collection
622
25.1.6
Stop Data Collection
624
25.1.7
Suspend Data Collection
625
26 Voice Services & Events 26.1
626
Services
626
26.1.1
Activate
627
26.1.2
Clear
628
26.1.3
Concatenate Message
630
26.1.4
Deactivate
631
26.1.5
Delete Message
632
26.1.6
Play Message
633
26.1.7
Query Voice Attribute
635
26.1.8
Queue
641
26.1.9
Record Message
643
26.1.10
Reposition
645
26.1.11
Resume
647
26.1.12
Review
649
26.1.13
Set Voice Attribute
651
26.1.14
Start
655
26.1.15
Stop
657
-x-
26.2
26.1.16
Suspend
660
26.1.17
Synthesize Message
662
Events
663
26.2.1
Bookmark Reached
664
26.2.2
Completed
665
26.2.3
DTMF Detected
666
26.2.4
Emptied
667
26.2.5
Interruption Detected
668
26.2.6
Not Recognized
669
26.2.7
Play
670
26.2.8
Recognized
671
26.2.9
Record
672
26.2.10
Review
673
26.2.11
Silence Timeout Expired
674
26.2.12
Speech Detected
675
26.2.13
Started
676
26.2.14
Stop
677
26.2.15
Suspend Play
678
26.2.16
Suspend Record
679
26.2.17
Voice Attribute Changed
680
26.2.18
Voice Error Occurred
682
27 Call Detail Record (CDR) Services 27.1
Services
684
27.1.1
Call Detail Records Notification
685
27.1.2
Call Detail Records Report
686
27.1.3
Send Stored Call Detail Records
691
27.1.4
Start Call Detail Records Transmission
693
27.1.5
Stop Call Detail Records Transmission
695
28 Location Services 28.1
684
697
Location Services
697
28.1.1
Get Location Information
698
28.1.2
Set Location Information
699
28.1.3
Location Tracking Session Resumed
701
28.1.4
Location Tracking Session Suspended
702
28.1.5
Resume Location Tracking Session
704
28.1.6
Location Information Report
705
28.1.7
Start Location Tracking Session
707
28.1.8
Stop Location Tracking Session
711
28.1.9
Suspend Location Tracking Session
712
28.1.10
Get Location Tracking Capabilities
713
28.1.11
Get Location Tracking Sessions
715
28.1.12
Location Session Info
717
- xi -
29 Vendor Specific Extensions Services & Events 29.1
29.2
29.3
719
Registration Services
719
29.1.1
Escape Register
720
29.1.2
Escape Register Abort
721
29.1.3
Escape Register Cancel
722
Services
723
29.2.1
Escape
724
29.2.2
Private Data Version Selection
725
Events 29.3.1
726 Private Event
727
Annex A (normative) Device Appearances
729
Annex B (normative) ISDN User-User Information Element Encoding for CSTA 739 Annex C (normative) Capability Bitmap Parameters Types
741
Annex D (informative) Connection State Transition Examples
805
Annex E (informative) Summary of changes in this edition
815
- xii -
1
Scope This Standard specifies the Services and Event Reports for Computer-Supported Telecommunications Applications, Phase III (CSTA). This 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 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 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 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
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 Standard that a CSTA conformant implementation shall support. This 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.
-1-
2.1
Switching Function In order to conform to this 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 for all CSTA profiles specified in 2.1.3, “CSTA Profiles” unless otherwise noted in the profile. 4. at least one of the Application Association Establishment sequences, including the mandatory services specified in the sequence, as specified in Clause 7, “Association Establishment”. 5. at least one of the profiles as specified in 2.1.3, “CSTA Profiles”.
2.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.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”.
2.1.3
CSTA Profiles
2.1.3.1
Some CSTA services and events are grouped together as profiles. 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.
2.1.3.2
Other CSTA services and events may be provided in any combination in addition to this set. 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). -2-
Other Routeing services may be provided in any combination in addition to this set.
2.1.3.3
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. Level 1a Voice Browser Profile This profile includes the following: 1. CSTA Services: Answer Call, Clear Connection, Single Step Transfer Call (of a connected call), Monitor Start (with the monitorType of device-type), and Monitor Stop. 2. CSTA Events: Connection Cleared, Delivered, Established, Failed, and Transferred. Note that the Get Switching Function Capability service is not a required service in this profile.
2.1.3.4
Other CSTA services and events may be provided in any combination in addition to this set. Level 1b Voice Browser Profile This profile includes the following: 1. CSTA Services: Answer Call, Clear Connection, Deflect Call (of a connected call), Monitor Start (with the monitorType of device-type), and Monitor Stop. 2. CSTA Events: Connection Cleared, Delivered, Diverted, Established, and Failed. Note that the Get Switching Function Capability service is not a required service in this profile.
2.1.3.5
Other CSTA services and events may be provided in any combination in addition to this set. Level 2 Voice Browser Profile This profile includes the following: All of the services and events in either the Level 1a Voice Browser Profile or the Level 1b Voice Browser Profile and the following: 1. additional CSTA Service: Make Call 2. additional CSTA Events: Network Reached, Originated.
2.1.3.6
Other CSTA services and events may be provided in any combination in addition to this set. Minimal uaCSTA Call Control Profile This profile includes the following: 1. CSTA Services: Answer Call, Clear Connection, Deflect Call, Hold Call, Make Call, Retrieve Call, and Single Step Transfer. 2. CSTA Events: There are no CSTA events specified as part of this profile. This profile assumes that an application uses mechanisms defined outside of this Standard (SIP Subscribe/Notify, for example) to obtain call/connection information that can be used in CSTA services rather than using CSTA events to obtain this information. Note that the Get Switching Function Capability service is not a required service in this profile.
2.1.3.7
Other CSTA services (and events) may be provided in any combination in addition to this set. Basic uaCSTA Call Control Profile This profile includes the following: 1. CSTA Services: Answer Call, Clear Connection, Deflect Call, Hold Call, Make Call, Retrieve Call, Single Step Transfer, Monitor Start (with a monitorType of device-type), and Monitor Stop. 2. CSTA Events: Connection Cleared, Delivered, Diverted, Established, Failed, Held, Network Reached, Retrieved, Service Initiated, and Transferred. Note that the Get Switching Function Capability service is not a required service in this profile. Other CSTA services and events may be provided in any combination in addition to this set. -3-
2.1.3.8
Advanced uaCSTA Call Control Profile This profile includes the following: 1. CSTA Services: Alternate Call, Answer Call, Clear Connection, Consultation Call, Deflect Call, Hold Call, Make Call, Reconnect Call, Retrieve Call, Single Step Transfer, Transfer Call, Monitor Start (with a monitorType of device-type), and Monitor Stop. 2. CSTA Events: Connection Cleared, Delivered, Diverted, Established, Failed, Held, Network Reached, Originated, Retrieved, Service Initiated, and Transferred.
2.1.3.9
Other CSTA services and events may be provided in any combination in addition to this set. Conferencing uaCSTA Call Control Profile This profile includes the following: 1. CSTA Services: The CSTA services in this profile must include all of the services in either the Basic or the Advanced uaCSTA Call Control Profile plus the Conference Call service and the Single Step Conference service. 2. CSTA Events: The CSTA events in this profile must include all of the events in either the Basic or the Advanced uaCSTA Call Control Profile plus the Conferenced event.
Other CSTA services and events may be provided in any combination in addition to this set. 2.1.3.10 Basic uaCSTA Device Feature Profile This profile includes the following: 1. CSTA Services: The CSTA services in this profile must include all of the services in either the Basic or the Advanced uaCSTA Call Control Profile plus the Set Do Not Disturb service and the Set Forwarding service. 2. CSTA Events: The CSTA events in this profile must include all of the events in either the Basic or the Advanced uaCSTA Call Control Profile plus the Do Not Disturb event and the Forwarding event. Other CSTA services and events may be provided in any combination in addition to this set. 2.1.3.11 Speaker uaCSTA Device Feature Profile This profile includes the following: 1. CSTA Services: The CSTA services in this profile must include all of the services in either the Basic or the Advanced uaCSTA Call Control Profile plus the Set Speaker Mute and Set Speaker Volume services. 2. CSTA Events: The CSTA events in this profile must include all of the events in either the Basic or the Advanced uaCSTA Call Control Profile plus the Speaker Mute and Speaker Volume events. Other CSTA services and events may be provided in any combination in addition to this set. 2.1.3.12 Basic Speech Service Profile The Basic Speech Service Profile involves primarily the Listener and Prompt resources and includes the following services and events: 1. Services and Events from one or more of the following profiles: a. Basic Telephony Profile b. Level 1a or 1b Voice Browser Profile c.
Level 2 Voice Browser Profile
d. Minimal uaCSTA Call Control Profile e. Basic uaCSTA Call Control Profile 2. CSTA Services: Clear, Monitor Start (device type monitoring), Monitor Stop, Query Voice Attribute, Set Voice Attribute, Start, Stop. -4-
3. CSTA Events: Bookmark Reached, Completed, Interruption Detected, Not Recognized, Recognized, Silence Timeout Expired, Speech Detected, Voice Error Occurred. Other CSTA services and events may be provided in any combination in addition to this set. 2.1.3.13 Advanced Speech Service Profile The Advanced Speech Service Profile includes all the resources, services and events in the Basic Speech Service Profile with additional Prompt Queue and DTMF resources and the following services and events: 1. CSTA Services: Activate, Deactivate, Queue, Reposition, Resume, Suspend. 2. CSTA Events: DTMF Detected, Emptied, Started, Voice Attribute Changed. 2.1.4
Other services and events may be provided in any combination in addition to this set. Support of Service Requests And Manual Mode A conformant switching function may support a given service defined in this 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 Standard through manual mode but is not required to support the equivalent service through the service boundary.
2.2
Special Resource Function Conformance In order to conform to this 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)”.
2.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. 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.
2.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”.
2.2.3
Support of Service Requests And Manual Mode A conformant special resource function may support a given service defined in this Standard through the CSTA service boundary but is not required to support the equivalent service in a manual mode. -5-
A conformant special resource function may support a feature associated with an equivalent CSTA service defined in this Standard through manual mode but is not required to support the equivalent service through the service boundary.
2.3
Computing Function Conformance In order to conform to this 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.1.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.5, “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.7.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. at least one of the Application Association Establishment sequences, including the mandatory services specified in the sequence, as specified in Clause 7, “Association Establishment”. Note that, in order to interwork with all Switching Functions, the Computing Function should support all of the Application Association Establishment sequences.
3
References ECMA-143
Private Integrated Services Network (PISN) - Circuit mode bearer services Inter-exchange signalling procedures and protocol (QSIG-BC), 4th edition (December 2001)
ECMA-155
Private Integrated Services Networks - Addressing, 2nd edition (June 1997)
ECMA-165
Private Integrated Services Network (PISN) - Generic functional protocol for the support of supplementary services - Inter-Exchange signalling procedures and protocol (QSIG-GF), 4th edition (June 2001)
ECMA-354
Application Session Services (June 2004)
ECMA TR/72
Glossary of definitions and terminology for Computer Supported Telecommunications Applications (CSTA) Phase III, 3rd edition (June 2000) -6-
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 8824-1:2002
Information technology - Abstract Specification of basic notation
ITU-T Rec. E.131:1988
Subscriber control procedures for supplementary telephone services
ITU-T Rec. E.164:1997
The international public telecommunication numbering plan
Syntax
Notation
One
(ASN.1):
ITU-T Rec. H.225.0:2000 Call signalling protocols and media stream packetization for packet-based multimedia communications systems
ITU-T Rec. Q.2931:1995 B-ISDN - Digital subscriber signalling system No. 2 (DSS 2) - User-network interface (UNI) layer 3 specification for basic call/connection control
4
ITU-T Rec. Q.931:1998
ISDN User-network interface layer 3 specification for basic call control
IETF RFC 3066
Tags for the Identification of Languages (January 2001)
IETF RFC 3261
SIP: Session Initiation Protocol (June 2002)
Definitions and Abbreviations The definitions and abbreviations used in this Standard are defined in ECMA TR/72.
5
Functional Architecture The objective of CSTA Architecture is to define the inter working mechanisms between the Computing, Special Resource, and the Switching Functions independently from their physical implementations.
6
CSTA Operational Model The CSTA domain contains Switching, Computing and Special Resource Domains separated by the CSTA Service Boundary. The CSTA domain concept is illustrated in Figure 6-1. It shows that the Switching and Computing Domains comprise Computing Functions (1, 2 and 3) and Switching Functions (1, 2 and 3) respectively. Each Function1 provides access to the objects in its sub-domain. An application acts upon the objects in the domain via the Functions over the CSTA Service Boundary. This Standard specifies the messages (Services and Event Reports), and their associated behaviour, over the CSTA Service Boundary. These messages originate and terminate at the Functions. CSTA applications operate in the context of a relationship between two or more Functions over the CSTA Service Boundary. In Figure 6-1, such relationships are shown as lines between Computing Functions and Switching Functions. Association establishment specified in Clause 7, “Association Establishment”, on page 91, explains the different ways to manage such relationships. A Sub-Domain may include objects such as CSTA calls, devices, connections and messages. A SubDomain may have one or more Functions. The Function provides an abstract view of the part of a Sub-Domain that an application can control and/or observe, called the Application Working Domain. One Function may provide different Application Working Domains based on considerations such as the application's design, licensing policy, security constraints, etc. These considerations and the associated administration are outside the scope of this Standard. 1.
Special Resource Functions (SRFs) are functions that are typically "added-on" to a Switching or Computing Function. They can be modeled as part of either one of the two other Functions or as something totally independent. -7-
Figure 6-1 CSTA Operational Model
6.1
Switching Sub-Domain Model The Switching Sub-Domain includes objects such as CSTA calls, devices and connections. A Switching Sub-Domain may have one or more Switching Functions. The Switching Function provides an abstract view of the part of a switching sub-domain that an application can control and/or observe, called the Application Working Domain.
6.1.1
One Switching Function may provide different Application Working Domains based on considerations such as the application's design, licensing policy, security constraints, etc., and is under administration of the Switching Sub-Domain. Device CSTA enables manipulation and observation of devices that allow users to access telecommunications services. NOTE It is not claimed that this Standard alone supports ISDN (or any other) devices because, for example, of the additional information required to support such devices in 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 -8-
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.1.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.
•
Image - Devices in this class are used to make digital data calls involving imaging, or highspeed, 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.
•
Chat - Devices in this class support calls involving text-based messages that are exchanged between other devices in the call.
•
Email - Devices in this class can support receiving calls associated with electronic mail systems (i.e. a CSTA Call that represents an Email).
•
Message - Devices in this class support receiving and displaying messages such as Instant Messages (IM), Short Message Service (SMS), and Multi-Media Service (MMS) messages. The specific type is not provided.
•
IM (Instant Message) - Devices in this class support calls involving a text message. This is a non-interactive call (i.e. only one device involved with the call at one time). This is a specific type of Message media class associated with Instant Messaging systems.
•
SMS (Short Message Service) - Devices in this class support calls involving a text message. This is a non-interactive call (i.e. only one device involved with the call at one time). This is a specific type of Message media class associated with Short Message Services systems.
•
MMS (Multi-Media Message Service) - Devices in this class support calls involving a multi media text message. This is a non-interactive call (i.e. only one device involved with the call
-9-
at one time). This is a specific type of Message media class associated with Multi-Media Message Services systems. •
Other - A class comprising devices not in one of the above 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 (e.g. ISDN, SIP).
•
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 ECMA143. In another example when SIP protocols are used, the information may include the SIP header information as defined in IETF RFC 3261.
Refer to 12.2.20, “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 Rec. 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.20, “MediaCallCharacteristics”, on page 138, 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
- 10 -
handle for the duration of the call. Management of the dynamically-assigned Device Identifier is discussed in 6.1.6. •
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.
•
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.
•
Restricted - Indicates that the device cannot be specified due to regulatory and/or privacy reasons.
•
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 146.
•
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.3, “Connection”, beginning on page 49.
•
The status of the physical components associated with a physical element of a CSTA Device. (e.g., the hookswitch status). For more information, refer to Clause 21, “Physical Device Features”, beginning on page 478.
•
The status of the logical device features/services associated with a logical element of a CSTA Device. (e.g., the forwarding and do not disturb status). For more information, refer to Clause 22, “Logical Device Features”, beginning on page 528.
5. Device Elements - A CSTA Device represents various types of telephony endpoints in a switching sub-domain and allows access to telephony services. A CSTA Device can range from a single endpoint (e.g., station) to a set of associated endpoints that form a group. Each CSTA Device is represented by its attributes (e.g., identifier, state(s), type) as well as its features/services. These attributes/features/services are grouped into two categories which are referred to as device elements. A device element encompasses the control and observation of a specific set of CSTA Device attributes/features/services. The device elements are: physical element and logical element. The logical element of a CSTA Device encompasses the set of attributes/features/services (e.g., Make Call, Set Forward) that have any association with the control and observation of a call at a CSTA Device (i.e., connection). The physical element of a CSTA Device encompasses the set of attributes/feature/services that have any association with physical components of the CSTA Device that would potentially make up the user interface of the device. All addressable (i.e., has a single identifier) CSTA Devices consist of one of the following device element combinations. - 11 -
Figure 6-2 Logical Element Only
L
A
c
Call 1
*
D
A
h
Call 2
*
D
Figure 6-3 Physical Element Only
Buttons Hookswitch
Display
Speaker
P Microphone
Ringer Lamps
Auditory Apparatus
Figure 6-4 A Logical and Physical Element Buttons Speaker
P Microphone
Hookswitch
Display
L
Ringer Lamps
A
c
Call 1
*
D
A
h
Call 2
*
D
Auditory Apparatus
D
represents another device
P
represents the identifiers for the physical elements
L
represents the identifiers for the logical elements
A
represents an appearance of a logical element
indicates that there is an interaction and/or association between the elements or components of an element. For example, a “plain old telephone set” (POTS) consists of a logical and physical element. A computing function learns about the devices, their elements, and their associated attributes\features\services in a switching sub-domain by using the capabilities exchange services (refer to 13.1 beginning on page 158). The following sections describes the device elements and the device attributes/features/services that are associated with the elements in detail. 6.1.1.1
Physical Element The physical element represents the attributes of the physical components and their associated features/ services that make up the user interface of a device (e.g., the components of a telephone set). A physical component at a CSTA Device can be a piece of hardware or a virtual (e.g., software) representation of a - 12 -
piece of hardware. For example, a set of buttons on a device (i.e., physical components of the device) could be comprised of a piece of hardware with 12 buttons and a switching function software representation of 12 more buttons. As a result, the device has a set of 24 buttons associated with its physical element. The combinations of physical components associated with the physical element are switching function specific. The following features/services are controlled and observed through the physical element: •
The Physical Device features/services, such as Button Press, Get/Set Hookswitch Status, and Get/ Set Speaker Volume.
•
The I/O Services such as Start Data Path and Send Data (when applied to the physical element of a device).
Note that these features/services also include the associated events and monitoring of these events. The physical element of a device is observed and/or controlled within the switching function through an assigned Device Identifier. Note that if the device is a combination of logical and physical elements, the assigned Device Identifier is the same for both elements. In order for the physical components to interact or be associated with calls at the device, the device shall have a logical device element (for more details, see 6.1.1.2, “Logical Element”) and/or some association(s) with a logical element(s) from another device(s) (for more details, see 6.1.1.3, “Device Configurations”). The physical components interact with calls through these logical device element(s) but it is device and switching function specific as to how these components actually interact and are associated with the calls. The following sections describe the physical components that can be associated with the physical element of the device. All physical components shall be controlled and observed in conjunction with the physical element (i.e., associated with the physical element’s Device Identifier). 6.1.1.1.1 Auditory Apparatus
An auditory apparatus is a component which is used to convert electronic signals into voice/speech (i.e., a speaker) and/or convert voice/speech into electronic signals (i.e., a microphone) but at a minimum shall have either a speaker or a microphone. A physical element can have several auditory apparatuses associated with it. Each auditory apparatus can be used independent of each other. An auditory apparatus has several attributes which can be controlled and observed by a computing function. The following are those attributes: 1. Auditory Apparatus type - There are several types of auditory apparatuses. Each type representing a different physical configuration and/or function. The following is the list of auditory apparatus types: a. Handset - An auditory apparatus that is held in a person’s hand and contains a microphone and speaker. b. Headset - An auditory apparatus that is worn on a person’s head and contains a microphone and speaker. c.
Speakerphone - An auditory apparatus that does not require a person’s body to come into contact with the apparatus and contains a microphone and speaker.
d. Speaker-only phone - A Speakerphone without a microphone. e. Microphone-only- A type that provides only a microphone. f.
Other - An auditory apparatus that is unique to the given switching function.
2. Auditory Apparatus Identifier - Each auditory apparatus that can be observed and/or controlled within the switching function is referenced using an assigned identifier. The auditory apparatus identifiers associated with a given physical element’s Device Identifier are unique.This identifier is used to - 13 -
control and observe all auditory apparatus attributes except the hookswitch which is associated with the apparatus. 3. Microphone - The auditory apparatus may or may not have a microphone. If a microphone is present at the auditory apparatus, then there are two features of the microphone that may or may not be controlled (i.e., settable) and observed (i.e., readable). a. Gain - This is the level at which the microphone is generating the electronic signal. For more details, refer to the definition of the microphoneGainValue parameter in associated services and events. b. Mute - This is the capability to temporarily disable the microphone. For more details, refer to the definition of the microphoneMute parameter in associated services and events. Both of these features are controlled and observed using the auditory apparatus identifier. 4. Speaker - The auditory apparatus may or may not have a speaker. If a speaker is present at the auditory apparatus, then there are two features of the speaker that may or may not be controlled (i.e., settable) and observed (i.e., readable). a. Volume - This is the level at which the speaker is boosting the electronic signal when generating the associated voice sound waves. For more details, refer to the definition of the speakerVolumeValue parameter in associated services and events. b. Mute - This is the capability to temporarily disable the speaker. For more details, refer to the definition of the speakerMute parameter in associated services and events. Both of these features are control and observed using the auditory apparatus identifier. 5. Hookswitch association - This identifies the particular hookswitch that is used to activate (i.e., put into use) and deactivate (i.e., remove from use) the auditory apparatus. It also indicates, if the particular hookswitch can be controlled (i.e., settable) and observed. For more details on hookswitches, refer to associated services and events. 6.1.1.1.2 Hookswitch
A hookswitch is a component which is used to activate (i.e., put into use or off-hook) or deactivate (i.e., remove from use or on-hook) an auditory apparatus(es). When a hookswitch is off-hook, it enables the auditory apparatus(es) to transmit and receive the electronic signals associated with sound, and when it is on-hook, this capability is disabled. A physical element can have several hookswitches associated with it. Each hookswitch can be used independently of each other. A hookswitch has one attribute which can be controlled and observed by a computing function. This attribute is the hookswitch identifier. This identifier is assigned by the switching function. The hookswitch identifiers associated with a given physical element’s Device Identifier are unique. This identifier is used to control and observe the status of the particular hookswitch (i.e., on-hook, off-hook). 6.1.1.1.3 Button
A button is a component which executes a specific feature/service that is assigned to it. The most common implementation of this component, is a piece of hardware that is pressed and released, thereby executing the feature/service assigned to it (e.g., each of the number buttons on a station). However, an implementation can use any component that can produce a similar behaviour. A button can also have the capability of toggling between two settings of a feature/service (e.g., enabling and disabling Do Not Disturb, that is you press the button once, it enables the Do Not Disturb feature/service, and press again, it disables the feature/service). The button can also have the capability of looping through a series of features/services. Almost any feature/service or set of features/services can be assigned to a button, but generally a switching function makes visible buttons only with features/services that are not available through the components/attributes/features/services defined in this Standard. A button can also be used to represent another physical component (e.g., a hookswitch). A physical element can have many buttons
- 14 -
associated with it. Each button can be used independently of each other. A button has the following attributes which can be controlled and observed by the computing function: 1. Button Identifier - Each button that can be observed and/or controlled within the switching function is referenced using an assigned identifier. The button identifiers associated with a given physical element’s Device Identifier are unique. This identifier is used to control and observe all other button attributes. 2. Button Label - This is a label by which people interacting with the physical device refer to a given button. This label is a character string which is retained by the switching function. This attribute can also be changed (if supported) by the computing function. The meaning of a Button Label is specific to the users of a particular device and changing it does not change the function of the button. 3. Button Function - This is a feature which can be assigned by the switching function to describe the function associated with a given button. The switching function may reassign the functionality of a button and change this attribute as required (in response to other button presses, for example) but it may not be changed directly by the computing function. 4. Button Associated Number - This is a diallable digits format Device Identifier which is associated with the feature/service assigned to the button. This Device Identifier is used by the feature/service when it is executed by the button being pressed. This attribute is optional and only applies to buttons that have some form of associated number. This Device Identifier is initially assigned by the switching function and can be changed (if supported) at any time by either the switching or computing function. 5. Button Press Indicator - This indicates if the button can be pressed via the Button Press service. 6.1.1.1.4 Lamp
A lamp is a component that represents (i.e., indicates), for example, the status of, for example, a feature/ service, physical component, logical device element or other CSTA device. The most common implementation of this component is a piece of hardware that emits light. However, an implementation can use any component that can produce a similar behaviour (e.g,. an icon presented on a display). A physical element can have many lamps associated with it. Each lamp can be used independently of each other. A lamp has several attributes which can be controlled and observed by the computing function. The following are those attributes: 1. Lamp Identifier - Each lamp that can be observed and/or controlled within the switching function is referenced using an assigned identifier. The lamp identifiers associated with a given physical element’s Device Identifier are unique.This identifier is used to control and observe all other lamp attributes. 2. Lamp Label - This is a character string which is assigned by the switching function to describe the feature or service’s status associated with this lamp. This attribute cannot be changed by the computing function.The meaning of the Lamp Label attribute is switching function specific. 3. Lamp Mode - This is the output of the lamp which is used to indicate the status of the (feature/ service) or physical component. The output values are represented by the various ways light can be produced from a lamp. This output can be changed at any time by either the switching or computing function. For more details, refer to definition of the lampMode parameter. 4. Lamp Brightness - This attribute indicates the visible brightness of the lamp when it is on. This attribute can be changed by the switching function or by the computing function. For more details, refer to the definition of the lampBrightness parameter. 5. Lamp Color - This attribute is an additional characteristic of the lamp which helps distinguish it from other lamps. This attribute can only be changed by the switching function. For more details, refer to the definition of the lampColor parameter.
- 15 -
6. Button Association - This identifies a button that is associated with the lamp. The lamp can be used to represent either the status of the feature/service associated with the button or to represent the status of the toggle sequence. 6.1.1.1.5 Ringer
A ringer is a component associated with the physical element that provides indication that a device is being rung. There may be one or more ringers associated with a device. A ringer has attributes that can be controlled and observed by a computing function. The following is a list of those attributes: 1. Ringer Identifier - Each ringer that can be observed and/or controlled within the switching function is referenced using an assigned identifier. The ringer identifiers associated with a given physical element’s Device Identifier are unique. This identifier is used to control and observe all ringer attributes associated with the device. 2. Ring Mode - This attribute describes if the ringer is engaged in a ringing cycle. It will remain ringing for the entire ringing cycle (e.g. across consecutive instances of a ringing pattern). Typically only one ringer on a physical element can be rung at one time. 3. Ring Count - This attribute describes the number of ring cycles (instances of ring pattern) that the ringer has completed. This attribute is set to 0 immediately before the first ring cycle starts. Note that this is used to query the most recent ring count even after ringing has ceased. 4. Ring Pattern - This attribute describes the type of Ring Pattern associated with a ringer. Each individual Ring Pattern cycle may consist of zero or more periods of audible ringing followed by a silent phase. The Ring pattern may be used to help audibly distinguish the types of calls at a device or to uniquely identify a ringer. The meaning of the Ring Pattern is switching function specific. 5. Ring Volume - This is the level at which the ringer is set to ring. This information is associated with the ringer until it is reset by the switching function or until it is changed via the Set Ringer Status service. 6.1.1.1.6 Display
A display is a component which presents a two dimensional array of characters associated with the physical element. A physical element can have several displays. A display may be real or virtual; that is it may or may not actually be present on the physical device itself. Displays have eight attributes as visualized in Figure 6-5, “Display Attributes”: 1. Display Identifier - To identify a specific display on a physical device. 2. Logical Rows - The number of rows on the logical display. 3. Logical Columns - The number of columns on the logical display. 4. Physical Rows - The number of rows on the physical display. This number is always smaller or equal to Logical Rows. 5. Physical Columns - The number of columns on the physical display. This number is always smaller or equal to Logical Columns. 6. Physical Base - The location of the first character of the physical display expressed as (LogicalRowNbr,LogicalColumnNbr) and identified in Figure 6-5 as (pbr,pbc). Note that the top-left most position in the logical display is defined as (0,0). 7. Character Set - ASCII (default), Unicode (UTF-8) or proprietary. 8. Contents - A character string which represents the contents of the logical display. Spaces are always present so the size of this string is always the product of the number of logical rows and logical columns. The contents can be observed and/or set (if supported) by the computing function. When
- 16 -
setting the value of the Contents, an offset (starting point in logical display) and a length field (number of characters to be set) shall be given). The following figure visualizes these attributes further: Figure 6-5 Display Attributes
L ogical C olum ns 0
pbc
pbr
PB
0
L ogical R ow s
Physical D isplay
L ogical D isplay
Physical C olum ns
Physical R ow s
= O rder in w hich characters from C ontents are located on the logical display PB
6.1.1.2
= Physical B ase L ocated on logical display at location (pbr,pbc)
Logical Element A logical element is the part of a device that is used to manage and interact with calls at a device. This element represents the isochronous media stream channels (e.g., ISDN bearer channels) and associated call handling facilities that are used by the device when involved in a call (i.e.,via a connection). If a device also has a physical element, the logical element may interact with the physical element’s components in order to convey call information (e.g., via lamps) to the user of the device, to provide/ manage the media stream data of the call (e.g., via an auditory apparatus) for the user of the device, and to allow the user of the device to manage the calls (e.g., via buttons). The implementation of this interaction is device and switching function specific. The following are the call and call-related features/ services that are controlled and observed through the logical element itself: •
Logical Device features/services which are used to indirectly control calls at the device such as Get/ Set Forwarding, Get/Set Do Not Disturb and Get/Set Auto Answer.
Note that these features/services also include the associated events and monitoring of these events. The logical element of a device is observed and/or controlled within the switching function through an assigned Device Identifier. - 17 -
Note that if the device is a combination of logical and physical elements, the assigned Device Identifier is the same for both elements. The following sections describe the attributes and components of the logical element. These attributes/ component shall be controlled and observed in conjunction with the logical element (i.e., associated with the logical element’s Device Identifier). 6.1.1.2.1 Appearance
An appearance is a receptor which is used to connect with at most a single call at the device. A logical element consists of one or more appearances. Appearances are also sometimes called call appearances. The number of appearances that a logical element can have is switching function and device specific. Changes in the number of addressable appearances for a logical element are reflected by the capabilities exchange services (13.1 beginning on page 158). Each appearance can be used independently. The following are the call and call-related features/services that are controlled and observed through an appearance for a particular call: •
Call Control features/services such as Make Call, Deflect Call, Answer Call.
•
Call Associated features/services such as Associate Data, Generate DTMF, Generate Telephony Tones.
•
Routeing Services such as Route Request, Route Select and Route End.
•
Media Stream Access such as Attach Media Service, and Detach Media Service.
•
I/O Services such as Start Data Path and Send Data (when applied to logical elements of a device.)
Note that these features/services also include the associated events and monitoring of these events. An appearance has several attributes. The following are those attributes: 1. Addressability - The addressability of an appearance refers to whether or not the switching function is explicitly representing the appearance to the computing function. a. Addressable - An appearance is addressable if it can be explicitly referenced by the computing function at any time with or without the involvement in a call, through a CSTA static device identifier. Refer to Clause 10, “CSTA Device Identifier Formats” for a description of how addressable appearances are referenced. b. Non-addressable - An appearance is non-addressable if it can only be referenced, when it is involved with a call, through a CSTA connection identifier. In this case, the logical element dynamically creates and destroys appearances based on the call activity, call capabilities, and features/services of the device. Once the appearance is created (i.e., associated with a call), the corresponding Connection Identifier shall be used to control and observe the appearance. For example, when a call is presented to the device, the logical element creates an appearance to handle the call. 2. Appearance Type - The type of appearance is based on its relationship with other devices. The type of appearance determines the functionality and behaviour associated with the logical element of the device. There are two types of appearances: Standard and Bridged Appearances. 6.1.1.3
Refer to Annex A for a complete description of the types of appearances and their associated behaviour. Device Configurations A device configuration describes the arrangement of the various elements and appearances that can be directly associated with a given device. Multiple device configurations may be formed from the possible combinations of physical elements, logical elements, and different appearance types. Device configurations are described in terms of a specific device configuration for a particular device: 1. Device’s element combination - This indicates whether the device has a physical element only, a logical element only or both a logical and physical element. - 18 -
2. Other devices using the physical element - This indicates the list of devices (i.e., their logical elements) that are using the physical element of the base device. 3. Other devices using the logical element - This indicates the list of devices (i.e., their physical elements) that are using the logical element of the base device. 4. The logical element’s appearance addressability - This is an attribute of the appearances of the logical element of the base device (if the logical element is present). 5. The logical element’s appearance type - This is an attribute of the appearances of the logical element of the base device (if the logical element is present). 6. The number of appearances associated with the logical element - This is an attribute of the logical element of the base device (if the logical element is present). As a set, these attributes describe the device configuration for a specific device. The following sections illustrate typical examples of device configurations that can exist in a switching sub-domain. Note that in the following examples, where physical and logical elements form part of the same device, the application of a suffix number to the identifying letter identifies that they are parts of the same device (e.g. L1, P1 are a single device; L1, P2 are elements from different devices). 6.1.1.3.1 Logical Element Only
This device configuration has only one logical element (e.g., some Park devices). The following identify the attributes of this device configuration: •
Device’s element combination - logical element only (L1)
•
Other devices using the physical element - None
•
Other devices using the logical element - None
•
The logical element’s appearance addressability - Non-addressable
•
The logical element’s appearance type - Selected-standard
•
The number of appearances associated with the logical element - unlimited (switching function based limits)
Figure 6-6 is a diagram of a logical element only device configuration. Figure 6-6 Logical Element Only Device Configuration
L1 a
6.1.1.3.2 Single Physical and Logical Element
A Single Physical and Logical Element device configuration consists of a single physical element of the device associated with a single logical element of the device that contains non-addressable standard appearances. This device configuration could be used to model a basic telephone station device (e.g., a Plain Old Telephone Service (POTS) telephone or a featured telephone). The following identify the attributes of this device configuration: •
Device’s element combination - both a logical and physical element (L1/P1)
•
Other devices using the physical element - None
•
Other devices using the logical element - None
- 19 -
•
The logical element’s appearance addressability - Non-addressable
•
The logical element’s appearance type - Selected-standard
•
The number of appearances associated with the logical element - unlimited (switching function based limits)
Figure 6-7 is a diagram of this device configuration. Figure 6-7 Single Physical and Logical Element Device Configuration (One Device)
P1 L1 a
In this figure, the labels “L” and “P” represent the logical and physical elements of the device respectively. Another variation of the single logical and physical element device configuration involves two different devices - one with a logical element only and one with a physical element only - that are associated with each other. From the perspective of the physical device element P1, the device configuration in this example can be represented as follows: •
Device’s element combination - physical element only (P1)
•
Other devices using the physical element - one device (L2)
•
Other devices using the logical element - None
•
The logical element’s appearance addressability - N/A
•
The logical element’s appearance type - N/A
•
The number of appearances associated with the logical element - N/A
Figure 6-8 is a diagram of this device configuration. Figure 6-8 Single Physical and Logical Device Configuration (two devices)
P1 L2 a
- 20 -
6.1.1.3.3 Multiple Logical Elements
A multiple logical elements device configuration consists of a single physical element associated with multiple logical elements containing standard appearances. A multi-line telephone station could be modeled using this device configuration. The following identify the attributes of this device configuration: •
Device’s element combination - physical and logical element combination (L1/P1)
•
Other devices using the physical element - two devices (L2,L3)
•
Other devices using the logical element - None
•
The logical element’s appearance addressability - non-addressable
•
The logical element’s appearance type - Selected-standard
•
The number of appearances associated with the logical element - unlimited (switching function based limits)
None of the logical elements in this device configuration need to be part of the same device as the physical element. Multiple logical elements device configuration represents a single physical element (a telephone set) in a telephone system that supports only one appearance per logical element but has access to multiple calls simultaneously. Figure 6-9 is a diagram of a multiple logical elements device configuration. Figure 6-9 Multiple Logical Elements Device Configuration
P1 L1
L2
L3
a
a
a
6.1.1.3.4 Multiple Appearance
A multiple appearance device configuration consists of single physical element and a single logical element containing two or more addressable appearances. Multiple appearance device configurations are another way to represent a single telephone set that has access to multiple calls simultaneously. This approach could be used in a telephone system that supports addressable standard appearances. This device configuration is sometimes called a call appearance station. The following identify the attributes of this device configuration: •
Device’s element combination - physical and logical element combination (L1/P1)
•
Other devices using the physical element - None
•
Other devices using the logical element - None
•
The logical element’s appearance addressability - addressable
•
The logical element’s appearance type - Selected-standard
•
The number of appearances associated with the logical element - 3 (A1, A2, A3) - 21 -
Figure 6-10 is a diagram of a Multiple Appearance Device Configuration. Figure 6-10 Multiple Appearance Device Configuration
P1 L1 A3
A2
A1
6.1.1.3.5 Bridged
A bridged device configuration involves bridged appearances. The characteristics of a bridged device configuration depends upon whether the device configuration is for a physical or logical element. In the example presented in Figure 6-11, the device configuration shown is for logical element L3 which has bridged appearances. The following identify the attributes of this device configuration: •
Device’s element combination - logical element only (L3)
•
Other devices using the physical element - None
•
Other devices using the logical element - two devices (P1,P2)
•
The logical element’s appearance addressability - addressable
•
The logical element’s appearance type - Independent-shared-bridged
•
The number of appearances associated with the logical element - 2 (A1 for P1 and A2 for P2)
Figure 6-11 is a diagram of a Bridged Device Configuration. Figure 6-11 Bridged Device Configuration
P1
P2
A1
A2
L3
The device configuration for the physical element P1 in this example, is shown in Figure 6-12. In P1’s device configuration there are only two device elements rather than three; one is the physical element (P1) and one is the logical element which has two addressable bridged appearances. The following identify the attributes of this device configuration: •
Device’s element combination - physical element only (P1) - 22 -
•
Other devices using the physical element - one device (L3 using appearance A1)
•
Other devices using the logical element - None
•
The logical element’s appearance addressability - N/A
•
The logical element’s appearance type - N/A
•
The number of appearances associated with the logical element - N/A
Figure 6-12 is a diagram of a Bridged Device Configuration. Figure 6-12 Bridged Device Configuration
P1 L3 A1
A2
6.1.1.3.6 Hybrid
A physical element associated with multiple logical elements that each have different types of appearances has a hybrid device configuration. An arbitrary example of a hybrid device configuration is shown in Figure 6-13. This example consists of one physical element and three logical elements. •
device 1 has both a physical element (P1) and a logical element (L1) containing two addressable standard appearances
•
device 2 has only a logical element (L2) with non-addressable standard appearances
•
device 3 has only a logical element (L3) with three addressable bridged appearances
The following identify the attributes of this device configuration: •
Device’s element combination - logical and physical element (L1/P1)
•
Other devices using the physical element - two devices (L2, L3 using appearances A1 andA2)
•
Other devices using the logical element - None
•
The logical element’s appearance addressability - addressable
•
The logical element’s appearance type - Selected-standard
•
The number of appearances associated with the logical element - 3 (A1, A2, A3)
Figure 6-13 is a diagram of a Hybrid Device Configuration.
- 23 -
Figure 6-13 Hybrid Device Configuration
P1 L2 L1
A1
A2
L3
A3
A1
A2
A3
a
6.1.1.4
Device Categories The device category of a particular device provides a generic indication of the device’s behaviour and configuration. The computing function should use the device category along with other information provided by the capabilities exchange services to model a given device.
6.1.1.4.1 Station Device Category
This category of device can range from a basic “Plain Old Telephone Set” (POTS) device to a very complex feature telephone device. Station devices can be represented by any single device configuration type, or more commonly, as a hybrid of two or more different device configuration types. The physical component, if present, may have any combination of components. The logical element(s) may have any number of appearances appropriate for the type of device configuration. 6.1.1.4.2 Network Interface Device Category
A Network Interface Device is a category of device which is within the switching sub-domain and is connected to another telephone network. A given switching sub-domain is connected to another telephone network(s) (which may or may not be thought of as other switching sub-domains) through one or more Network Interface Devices. To indicate when a given call involves a Network Interface Device and an external device, the switching function provides a Network Reached event to the computing function specifying what Network Interface device is being used (if known), and what subsequent call-related information is subject to the capabilities of the network being used. The following are examples which illustrate the use of Network Interface Devices. In Figure 6-14, the switching sub-domain is centered on a PBX. The Network Interface Devices are distinct devices and are commonly referred to as “trunks.”
- 24 -
Figure 6-14 Trunks As Network Interface Devices
SUB
In Figure 6-15, the switching sub-domain is an individual telephone station connected directly to the public telephone network. In this example, the two Network Interface Devices represent two Central Office lines. Figure 6-15 Central Office Lines As Network Interface Devices
SUB
6.1.1.4.3 ACD Device Category
An ACD (Automatic Call Distributor) is a device that distributes calls. An ACD device only consists of the distribution mechanism and may be associated with the devices to which the mechanism distributes calls. A dynamic process, Agent Log On allows an association between an ACD device and a distributed-to device to be created, removed and changed at anytime. Refer to 6.1.1.6, “Agent”, on page 38 for a description of Agent and the Agent Log On Process. An ACD device is represented as a logical element only device configuration. When a call is presented to an ACD device, a connection in the entering distribution mode of the alerting state is created. Calls that are presented to the ACD device may be queued before they are distributed. The conditions under which the call is queued are switching function specific. Many calls can be simultaneously enqueued, pending their distribution. The ACD device can, for example: •
distribute a call to an agent that had logged on to the ACD device
•
distribute a call to an agent that had logged on to an ACD Group
•
distribute a call to another ACD device (as well as any other type of internal or external device)
•
queue a call to an ACD Group, or to resources that provide message playing, message prompting, voice response interaction, etc.
There are two ACD device models - visible ACD-related devices and non-visible ACD-related devices (note that an ACD device can support one or both models): •
Visible ACD-Related Devices - In this model, the ACD device, and the devices (e.g., voice announcement units, devices the call may queue to, other ACD devices, ACD groups, etc.) that can interact with the ACD device while the call is being handled by the ACD device, can be monitored/ - 25 -
controlled and are represented uniquely by the switching function with their own connection when associated with a call. •
Non-Visible ACD-Related Devices - In this model, the ACD device, and the devices (e.g., voice announcement units, devices the call may queue to, other ACD devices, ACD groups) that can interact with the ACD device while the call is being handled by the ACD device, are represented by the switching function using a single connection at the ACD device. Neither these devices, which interact with the ACD device, nor their connections to calls queued at the ACD device can be monitored or controlled. Note that when a single connection is used in this manner, all relationships between the call and the ACD device are terminated when the call is no longer part of the ACD device (diverted from the device, for example).
6.1.1.4.4 Park Device Category
A park device category is a device that is exclusively used by the switching function to park calls on behalf of other devices in the switching sub-domain. These calls, once parked, may be retrieved by a device in the switching sub-domain. The number of calls that can be parked at one of these devices is switching function specific. These devices can be represented by either a single physical and logical elements device configuration or a logical element only device configuration. The visibility of these devices within the switching sub-domain is switching function specific. Note that calls may be parked at devices other than a Park device. 6.1.1.4.5 Group Device Category
A group device models a relationship between CSTA devices that is characterized by the fact that these devices share a common device identifier. This relationship can be permanent or temporary. The group model differs from the bridged appearances model in that the relationship is between devices’ logical elements while for bridged appearances the relationship is between a logical element and a physical element. The group device has a logical element that has relationships with the logical elements of the devices that are members of this group. The group device is referenced by the group device identifier. A group device may have a distribution mechanism. The distribution mechanism may support queuing. When a group device has a distribution mechanism, the group device identifier represents both the distribution mechanism and the member devices. Group Device Attributes The attributes of a group device are (a group device may have more than one of these attributes (e.g., a hunt and pick group device): •
Hunt - The hunt attribute characterizes a group device (also called hunt group) that has the capability to distribute calls to the member devices according to different selection modes (e.g., cyclical, sequential, longest idle time). The association between the group device and the member devices is always fixed by the switching function. A hunt group may have the capability to queue these calls before they are distributed.
•
Pick - The pick attribute characterizes a group device (also called pick group) that represents a collection of devices that can be used with the Group Pickup Call service. When a call is delivered to a device in the pick group, other devices in the group can be used to answer the particular call (i.e., picking the call). When the call is picked, it is diverted from the originally delivered device and connected to the device which picked the call. The details associated with the pick group feature are documented in the Group Pickup Call service. Only devices associated with the pick group device can pick a call from the given group unless the pick group device is addressable within the switching sub-domain and the pick group device is configured to allow devices outside the group to pick calls. The addressability of the pick device within the switching sub-domain is switching function specific. If the pick group device is addressable, its Device Identifier can only be used in conjunction with the - 26 -
Group Pickup Call service (i.e. the computing function has limited control and can not observe the pick group device). The number of devices that are associated with the pick group device is switching function and device specific. The association between the pick group device and the other devices is not visible within the switching sub-domain (i.e., does not have an explicit representation). The association between the pick group device and the other devices is fixed by the switching function. Changes in the number of devices associated with the pick group device are reflected by the capabilities exchange services. •
ACD - The ACD attribute characterizes a group device (also called an ACD group) that has a distribution mechanism similar to a hunt group. In addition, this group device represents an explicit association between the distribution mechanism (the ACD) and the distributed-to-devices. A dynamic process, Agent Log On allows an association between an ACD group and the distributed-to devices to be created, removed and changed at anytime. Refer to 6.1.1.6, “Agent”, on page 38 for a description of Agent and the Agent Log On Process.
•
User - The User attribute characterizes a group device whose member devices are associated with a user. The association between the group device and the member devices can be fixed (e.g., through provisioning) or can be dynamic (e.g. SIP registration procedures).
•
Agent - The Agent attribute characterizes a group device whose member devices are associated with a user via the log in procedures described in 6.1.1.6, “Agent”, on page 38.
•
Other - The Other attribute characterizes a group device whose characteristics are switching functiondependent.
Group Device and Monitoring Monitoring of a group device in which the group device includes a distribution mechanism may follow either the group inclusive or the group exclusive model. The switching function may support either model, or both models simultaneously (with individual group devices supporting either the inclusive or exclusive model). The model(s) supported by a switching function is indicated by the Get Switching Function Capabilities service. In the group inclusive model, the scope of a monitor on the group device includes the distribution mechanism and all member devices. In the group exclusive model, the scope of the monitor on the group device includes only the distribution mechanism. The events reported to the monitor of a group device are the same as those reported to monitors of the individual member devices, with the following exceptions: •
A single Monitor Start service request is set on the group device identifier.
•
The events for the member devices, if they are in the scope of the monitor, are reported with the cross reference identifier of the monitor set on the group device.
•
When an incoming call is received, the called device represents the group device and the subject device (e.g., alerting device) represents the member device.
In addition, if the group device supports a distribution mechanism, all events reported for the call when it is present at the distribution mechanism (e.g., queued), are reported with a connection identifier consisting of the call identifier and the group device identifier. When the call leaves the distribution mechanism to be delivered to a member device, a Diverted event is generated. Some services applied to the group device are applied to all member devices of the group device (e.g., Set Agent State). This capability is indicated by the capabilities exchange services.
- 27 -
Monitoring a User A user can be represented as a user group device. When a user group device is monitored all members of the user group device are included in the scope of the monitor (group inclusive model). A device can become a member of the user group device through provisioning or by dynamic association. For example a URI may be used to represent a user (in SIP this is called a user’s Address of Record (AOR)). CSTA can model this user as a user group device and represent the user’s AOR using the CSTA URI deviceID format. When a device registers with a user (using SIP registration procedures, for example), it becomes associated with the user through the user’s AOR. In CSTA, this device becomes a member of monitored user’s group device. When the user group device is monitored, call and/or device activity at the device (depending upon the parameters in the Monitor Start service request) are reported through the user group device monitor. Since there can be multiple (SIP) devices registered for the same user, the user group device can contain multiple members. The CSTA capability exchange services can be used to obtain the members of the user group device. 6.1.1.4.6 Routeing Device Category
A Routeing Device is a device that assists in the routeing of calls. Refer to 6.7.8, “Routeing Services” for a description of how a Routeing Device is used with CSTA Routeing services. 6.1.1.4.7 Voice Unit Device Category
A Voice Unit device allows messages consisting of voice stream data to be created, manipulated, played to a Connection, or recorded from a Connection. A Voice Unit device can be observed and controlled using the CSTA Voice services (Clause 26, “Voice Services & Events”, on page 626) and a state model as shown in Figure 6-16, “Voice Unit Operational Model”. A Voice Unit device could be used to implement a voice mail system. A Voice Unit device may be implemented either as a device as part of the Switching Sub-Domain or as a device as part of the Special Resource Sub-Domain. A Connection Identifier is used to indicate the call that the Voice Unit device relates to a message. Typically the Voice Unit device will record some portion of the call or play a message as some portion of a call. There are some Voice services (e.g., Delete Message and Concatenate Message) that deal with the control of messages and do not require an interaction with a call. A globally unique Message Identifier is used to allow manipulation of messages, many of which survive the life of multiple calls. A Voice Unit state is a state that a Voice Unit device may take in relating a call with a message. It relates a call to its message in terms of playing, recording, pausing, suspending, changing playback speed, etc. Voice Units may have several states concurrently with respect to different calls and messages. Voice Unit states shall be reported by Voice Event Reports. A typical transition model for Voice Unit states is shown in the following figure.
- 28 -
Figure 6-16 Voice Unit Operational Model
Speed Volume
next message
Volume Level Speed
Level
Volume Level Speed
Stop
Record
Play Position
Set Speed
Speed Level Volume Suspend Play
Suspend Record Position
Set Speed
Position
Speed Level Volume Review depicts an event representing a characteristic change
Set Speed
Position
Speed Level Volume
In Figure 6-16, “Voice Unit Operational Model”, the states (circles) presented comprise the CSTA Voice Unit state set. Arrows represent transitions between states and show the typical states that may be entered from a given state. These transitions form the basis for providing Voice Event Reports when they occur. The circular transitions show the effects of the Reposition and Set Speed Services. The following states are defined: Stop
the state where a call and a message are not currently interacting.
Play
the state where a message delivers its voice stream data to a call.
Suspend Play
the state where a message that was in the Play state is temporarily suspended in its delivery. This state (rather than Stop) is entered when it the message is intended to be continued from its current position.
Record
the state where a message is created from the voice stream data in a call.
Suspend Record
the state where a message that was in the record state is temporarily suspended from recording. This state (rather than Stop) is entered when recording is intended to be continued from its current position.
Review
The state where a message that was in the Suspend Record state delivers recorded voice stream data back to the call. This allows the party who is creating the message to examine the voice stream data recorded so far.
- 29 -
6.1.1.4.8 Generic Interactive Voice Device Category
Interactive Voice Devices (IVDs) model Speech/DTMF input and speech output processing in CSTA. A Connection identifier is used to indicate the call the IVD is interacting with. A Device Identifier is used to indicate an Interactive Voice device. Typically, an input IVD captures the voice and converts it into a textual description. The conversion is based on a collection of rules herein called the grammar. Similarly, an output IVD produces voice based on a textual description generated by the Computing Function. An IVD can coordinate the playback of multiple voice outputs. Interactive Voice Devices are call-wide in that the behaviour of an IVD can be affected by other IVDs connected to the same call. For example, the Computing Function can delegate an input IVD to automatically cut off speech output to facilitate the “barge-in” effect (Clause 6.1.1.4.11, “Prompt Interactive Voice Device Category”, on page 33), and one input IVD can reset or prevent timeout for other input IVDs (Clause 6.1.1.4.9, “Listener Interactive Voice Device Category”, on page 30 and Clause 6.1.1.4.10, “DTMF Interactive Voice Device Category”, on page 32). This Standard specifies the functional requirements of the call-wide behaviour for Interactive Voice Devices. Because of their interactive nature, interactive voice devices are typically monitored so that events can be delivered to Computing Function in a timely fashion. Interactive Voice Devices are controlled and observed using the services and events specified in Clause 26, “Voice Services & Events”, on page 626. A single Interactive Voice Device can contain multiple interactive voice resources that share a single connection. Each of these resources is individually addressable through a resource identifier. A Generic Interactive Voice Device (or Generic IVD) has one or more resources that are involved with Speech and/or DTMF processing. It may include functionality of a Listener, DTMF, Prompt, Prompt Queue, or a Message Interactive Voice Device. For example Listener and DTMF resources may be combined to form a type of “input” interactive voice device. A Generic IVD and all other types of IVDs may be implemented either as a device as part of the Switching Sub-Domain or as a device as part of the Special Resource Sub-Domain. The following sections describe specific types of Interactive Voice Devices specified in this Standard. 6.1.1.4.9 Listener Interactive Voice Device Category
A Listener Interactive Voice Device (or Listener IVD) that has one or more resources that are involved only with processing speech input. Tasks that can be performed by a Listener IVD include: •
speech recognition: converts speech into a textual transcription. The result is often accompanied by a confidence score that indicates how trustworthy the transcript is.
•
utterance verification: validates speech against a given transcription. In the case where the transcription is not provided a priori, a speech recognition stage usually precedes the verification process.
•
speaker recognition: identify the speech from a speaker database. As in the case of speech recognition, the result is often accompanied by a confidence score. The word sequence of the utterance spoken can be known or unknown to the Computing Function.
•
speaker verification: validates whether a speech waveform is indeed produced by a given target. The word sequence of the utterance spoken can be known or unknown.
•
speaker enrollment: allows speech recognition to adapt to a speaker's voice, or enroll a speaker's voice signature for verification.
A Listener IVD may perform one or more tasks listed above and may provide options to capture and return the audio alongside with the textual outcome.
- 30 -
Figure 6-17, “Listener Resource Operational Model” specifies the states and their transitions for a particular Listener resource. The following states are defined: Null
the state in which the call and the Listener resource are not interacting.
Started
the state in which the Listener resource is processing audio in the call.
Speech Detected
the state in which speech-like sound is detected in the call and the Listener resource has started the process of matching the audio to the grammar. Figure 6-17 Listener Resource Operational Model
Null Stop/Clear/Recognized/ Not Recognized/ Voice Error Occurred/Emptied
Stop/Clear/Voice Error Occurred/ Silence Timeout Expired/ Emptied
Start/Started
Started
Speech Detected
Recognized (multiple mode)
Speech Detected
Typically, a Listener resource is brought to a Started state by the Start service (Clause 26.1.14, “Start”, on page 655), after which state transitions may take place automatically. To report progress, each automatic state transition raises a corresponding Voice Event (Clause 26.2, “Events”, on page 663). A Listener resource can have one of the following three modes: •
automatic, in which a Listener resource will determine automatically whether the speech signal has ended in the call. Typically, the end of speech is characterized by an extended period of silence called End Silence.
•
single, in which the Computing Function must utilize Stop or Clear services (Clause 26.1, “Services”, on page 626) to end the audio collection process. This mode mandates the Listener resource to ignore extended silence amidst the audio and produce a single interpretation on the captured audio.
•
multiple, in which the Listener resource may loop around the Speech Detected state and therefore may produce multiple outcomes. An explicit Voice service request (either Stop or Clear, Clause 26.1, “Services”) must be used to stop or cancel further speech processing.
After leaving the Null state, a Listener resource can encounter one of the following timeout conditions and reset itself back to the Null State: •
Silence timeout: the maximum time allowed before entering the Speech Detected state.
•
Babble timeout: the maximum time allowed to stay in the Speech Detected state.
•
Maximum timeout: the maximum time allowed before returning to the Null state.
- 31 -
Multiple Listener IVDs can optionally be conferenced or joined to a single call where they process the same audio stream. One and only one Start service request (Clause 26.1.14, “Start”) directed at any of the Listener resources is needed to bring all of the Listener resources connected to the same call out of the Null State. Subsequent Start service requests issued against a non Null Listener resource has no effect. Once the Listener resource connected to the same call leaves the Null State, individual Listener resources proceed with their own state transitions and, if monitored, raise their own events. Listener resources performing the same task on the same call, however, do compete against one another: the first Listener resource matching the grammar to the utterance will cause all others connected to the same call to abandon their grammar matching processes and make corresponding state transitions based on their modes: while Listener resources of automatic or single modes return to the Null state, the multiple mode Listener resources returns to the Speech Detected state. When a Listener and a DTMF IVD are conferenced or joined to a single call, they also compete on the same audio. See Clause 6.1.1.4.10, “DTMF Interactive Voice Device Category” for the specification of the operational model. 6.1.1.4.10 DTMF Interactive Voice Device Category
A DTMF Interactive Voice device (or DTMF IVD) has one or more resources that are involved only with interpreting a sequence of DTMF characters based on the grammars. In contrast to the CSTA Data Collection Services, a DTMF resource utilizes grammars to parse the DTMF string rather than just reporting it. For example, a three consecutive DTMF strokes of key “8” may be interpreted as an area code of a telephone number, a transaction amount, or even as a way to enter the letter “V”. The Computing Function may utilize different grammars and cause the DTMF resource to report appropriate results. As specified in Figure 6-18, “DTMF Resource Operational Model”, a DTMF resource will be in one of the following states: Null
the state in which the call and the DTMF resource are not interacting.
Started
the state in which the DTMF resource starts processing the audio in the call.
DTMF Detected
the state in which a DTMF character is detected in the call. Figure 6-18 DTMF Resource Operational Model
Null
Stop/Voice Error Occurred/ Silence Timeout Expired
Start/Started
Started
Stop/Clear/ Recognized/ Not Recognized/ Voice Error Occurred/ Emptied
DTMF Detected DTMF Detected
- 32 -
DTMF Detected
Typically, a DTMF resource is brought to a Started state by the Start service (Clause 26.1.14, “Start”, on page 655), after which state transitions may take place automatically. To report progress, each automatic state transition raises a corresponding Voice Event (Clause 26.2, “Events”, on page 663). After leaving the Null state, a DTMF resource can encounter one of the following timeout conditions and reset itself back to the Null state while raising a corresponding timeout event: •
Silence timeout: the maximum time allowed before entering the DTMF Detected state.
•
Inter-digit timeout: the maximum time allowed before making a transition from the DTMF Detected state unless the last key completes a DTMF sequence that traverse a grammar rule in its entirety. For the latter case, the DTMF resource waits for a period of End Silence and transitions into the Null State if no successive DTMF is detected.
Multiple DTMF IVDs can optionally be conferenced or joined to a single call. At any given time, though, at most one of the resources can be in a non Null state. Any attempt to enter the Started state while another DTMF resource is not at the Null state will result in a Voice Error Occurred event (Clause 26.2.18, “Voice Error Occurred”, on page 682). Multiple DTMF and Listener IVDs can be conferenced or joined to the same call and enter their respective Started states. In such case, the two types of resources receive the same media stream from the call, and the first resource to leave the Started state will prevent the other from incurring a silence timeout and resetting back to the Null state. However, either type of resource that returns to the Null state will, after raising proper Voice events, cause the other to follow immediately back to its Null state as well. This, for instance, enables the use of DTMF to stop a Listener without Maximum or Babble Timeout. 6.1.1.4.11 Prompt Interactive Voice Device Category
An Prompt Interactive Voice device (or Prompt IVD) has one or more resources that are involved only with producing audio output from a text that describes the output generation process. The audio can be a combination of pre-recorded audio and text to speech synthesis. Prompt playback is facilitated through the Prompt Queue (Clause 6.1.1.4.12, “Prompt Queue Interactive Voice Device Category”, on page 33) IVD that manages the playback by storing copies of the voice generated by the Prompt and sends them to the media conduit at a proper time. The text input to the Prompt resource may contain bookmarks. When the playback reaches the position of a bookmark, the Bookmark Reached event is generated (Clause 26.2.1, “Bookmark Reached”, on page 664). The event can be used as a synchronisation cue to update other user interface related properties such as the cursor on a display, for instance. Each prompt can be set as auto-interruptible. A DTMF resource or a Listener resource can cause a prompt to be interrupted. When set as auto-interruptible, a caller's “barge-in” on the playback, either through DTMF or speech commands, will automatically cut off the speech output without the intervention of the Computing Function. Whether a prompt is set auto-interruptible or not, the Interruption Detected Event (Clause 26.2.5, “Interruption Detected”, on page 668) will always be reported should there be any input activity during playback and a monitor is placed on the call or the Prompt IVD. The attributes of a Prompt resource can be controlled by the Set Voice Attributes service (Clause 26.1.13, “Set Voice Attribute”, on page 651). A Prompt resource is not involved with a call and therefore does not have a state model. The CSTA Queue service is used to copy a prompt to a Prompt resource which is attached to a call. 6.1.1.4.12 Prompt Queue Interactive Voice Device Category
Prompt Queue Interactive Voice Device (or Prompt IVD) has one or more resources that are involved only with serializing audio being played back to the call. A Prompt Queue resource stores the concatenated voices generated by Prompt resources in the order of the Queue services made at individual Prompt resources. A Prompt Queue resource allows the - 33 -
Computing Function to construct phrases by concatenating voices from a collection of prompts. For example, a Computing Function may decide to confirm with the caller on a choice of a city with a sentence “I heard you said Seattle. Is this correct?” While “I heard you said…” and “Is this correct?” can be pre-recorded waveforms, the city name must be dynamically synthesized based on interaction context. Such an explicit confirmation can be achieved by three consecutive Queue Services directed at three Prompt resources: first on the pre-recorded “I heard you said…”, followed by the synthesized city name and the pre-recorded “Is this correct?”. A Prompt Queue resource conceptually holds one or more subqueues that are delimited by the Start service (Clause 26.1.14, “Start”, on page 655). Figure 6-19, “Operational Model of a subqueue in a Prompt Queue Resource” specifies the life cycle of a subqueue. The following states are specified: Formed
the state in which a subqueue is initiated by an incoming prompt either when the Prompt Queue resource is empty, or the last subqueue in the Prompt Queue resource has entered the Ready state. All subsequent incoming prompts are appended to this subqueue in the order of arrival.
Ready
the state in which a subqueue is scheduled to be played as soon as its preceding subqueue, if any, is depleted. Any subqueue must enter this state before its contents can be played out to the call.
Playing
the state in which a subqueue has reached to the front of the Prompt Queue resource and its constituent prompts are being played in sequence.
Null
an empty subqueue. Figure 6-19 Operational Model of a subqueue in a Prompt Queue Resource
Stop/Clear/Voice Error Occurred/ Emptied/ Bargein Detected
Null
Queue
Clear/ Voice Error Occurred/ Emptied
Clear/Voice Error Occurred/ Emptied Formed
Completed
Playing
Suspend/ “Suspend Play”
Ready
Reposition/ “Play Event” Resume/ (automatic)/ “Play Event”
Start/Started Note: Services/events for Prompt are in italic.
Figure 6-20, “A Relationship of prompts and Prompt Queue Resource” specifies the relationship between subqueues and the Prompt Queue resource in general. Many Voice services and events have the scope at the level of subqueues. Specifically, the Emptied event is generated when all the prompts in a subqueue has been played, even though there are still one or more subqueues stored in the Prompt Queue resource. When an individual prompt encounters errors or is interrupted during playback, the Prompt Queue resource flushes the remaining prompts to the subqueue boundary, not the entire queue. - 34 -
Since the rest of the subqueues are not affected, the audio playback may not be halted if the following subqueue is in the Ready state. The Clear, Query Voice Attribute, Set Voice Attribute, Suspend, and the Resume services, however, have the scope of the entire Prompt Queue resource. Figure 6-20 A Relationship of prompts and Prompt Queue Resource
(a) Queue: Prompt 1
Prompt 1
Back
Front
(b) Queue: Prompt 2 and 3
Prompt 3
Prompt 1
Prompt 2
Back
Front
(c) Start: Prompt Queue Playing Prompt 3
Prompt 1
Prompt 2
Back
Front subqueue boundary
(d) Queue: Prompt 4 and 5 Playing Prompt 5
Prompt 4
Prompt 3
Prompt 2
Back
Front subqueue boundary
(e) Start: Prompt 6 Playing
Ready Prompt 6
Prompt 5
Back
Prompt 4
Prompt 3 Front
subqueue boundary
Typically, a subqueue is the most natural unit to administer voice responses. The main purpose of a Prompt Queue resource, which hosts a queue of subqueues, is to insure a high quality of service in the prompt playback, especially for the cases where a real time concatenation and prompt synthesis is not achievable. For example, after obtaining a command from the caller, the Computing Function can queue up several “waiting” prompts into a Prompt Queue resource while the command is being processed. Commonly used waiting prompts include a musical segment intermixed with reassuring phrases such as “lease remain on the line as your call is important to us”. To insure the caller's audio channel is engaged, the Computing Function may need to insure that all the results are properly synthesized and entered into a subqueue to the Prompt Queue resource before stopping the waiting prompts. - 35 -
6.1.1.4.13 Message Interactive Voice Device Category
A Message Interactive Voice Device has one or more resources that are involved only with processing messages. Each resource follows the operational model of a Voice Unit as shown in 6.1.1.4.7, “Voice Unit Device Category”, on page 28. 6.1.1.4.14 Conference Device Category
A Conference Device facilitates the exchange of media (typically voice media) between devices (also known as conference participants) in a conference call. The participants may be both inside and outside of the switching function. A conference call (or conference) can be modeled as connections between a Conference Device and a CSTA call. Figure 6-21, “Conference Operational Model” shows the connection states at a Conferencing Device and CSTA events corresponding to the life cycle of a conference. Figure 6-21 Conference Operational Model
A conference involving a Conferencing Device may be created via the Make Connection service (17.1.19). The Make Connection service creates a conference call with one connection at the Conferencing Device. The autoOriginate parameter in the Make Connection service is used to create a conference that is either reserved (autoOriginate=Prompt) or enabled (autoOriginate=DoNotPrompt): •
A reserved conference refers to a call involving a Conferencing Device that allocates resources at a Conferencing Device for future use. A reserved conference may be modeled with a Conference Device connection in an initiated connection state.
•
An enabled conference refers to a call involving a Conferencing Device that is ready to process media between participants that will be added to the call or are already part of the call.
The Answer Call service may be used to enable a reserved conference by transiting the Conference Device connection state from initiated to connected (e.g. when a reserved conference is ready to start). Once the conference is enabled, participants may be added to the call via services like Conference Call (17.1.9) and Single Step Conference Call (17.1.25) services. The participants may be authenticated (via speech, DTMF, etc.) prior to being added to the conference. Participants may be removed from the call via the Clear Connection service (17.1.8). A conference may be suspended (e.g. no media exchanged between participants in the call) via the Park Call service (17.1.21) to place the connection at the Conferencing Device in the queued connection state. - 36 -
When a conference is suspended, resources at the Conferencing Device may be reused for other purposes. The Answer Call service may be used to resume the conference by transiting the connection state from queued to connected. A conference is released when all resources involving the conference are stopped. This is modeled with a Conference Device connection state of null. This may happen as a result of the Clear Connection service (17.1.8) applied to the Conference Device connection. Changes in the conference may also occur implicitly based upon switching function criteria. For example: •
•
a conference may be implicitly created and enabled whenever a conference participant becomes part of a call involving a Conferencing Device. For example: •
the first participant calls into a Conferencing Device
•
an outgoing call is created on behalf of the Conferencing Device (e.g. Make Call service with originatingDevice= Conferencing Device, calledDevice= conference participant)
a participant may be implicitly added to the conference when: •
a participant calls a Conferencing Device and the Conferencing Device adds the participant to the conference (no participant authentication is required).
•
the participant answers a call that was initiated on behalf of the Conferencing Device. Once the participant answers the participant is added to the conference.
•
a conference may be implicitly suspended when the last participant leaves the conference and the conference is maintained for future use.
•
a conference may be implicitly released when the last participant leaves the conference (and there is no need to maintain the conference) or after an amount of time when no participants are involved with the conference.
6.1.1.4.15 Other Device Category
6.1.1.5
A device in this category has characteristics (i.e., device configuration, capabilities, type of elements, element components) which are switching function specific. Named Device Types Switching Function implementations may indicate that a device is of a particular device type. The following device types may be used for this purpose but the interpretation of a given device type is implementation specific. •
ACD
•
ACD Group
•
Button
•
Button Group
•
Conference Bridge
•
Line
•
Line Group
•
Operator
•
Operator Group
•
Parking Device
•
Station
•
Station Group
•
Trunk - 37 -
6.1.1.6
•
Trunk Group
•
Other
•
Other Group
Agent An agent represents a device’s association and activities with one or more ACD devices or ACD groups. An agent becomes associated with a specific ACD device or ACD group by the process of logging on. There are two Agent Log On Models that may be supported by a switching function (as indicated by the capability exchange services). Note that multiple models may be supported by a switching function and by a single agent. •
Log On to an ACD device - In this model an agent logs on to ACD device and becomes associated with the activities of the ACD device. There is no association with any ACD group. This may be achieved by using the Set Agent State service (loggedOn) without providing the ACD group parameter. Note that this capability cannot be simultaneously supported with the Log On to an ACD Group (implicit/one step) described below.
•
Log On to an ACD Group - In this model an agent becomes associated with the activities of an ACD group. This may be accomplished by the following: •
explicit/one step - by using the Set Agent State (loggedOn) service and supplying the ACD group parameter
•
explicit/two step - by first logging on to an ACD device using the Set Agent State (loggedOn) service and omitting the ACD group parameter (described above). Once logged on to an ACD device, a log on to a specific group is achieved by using another Set Agent State (loggedOn) service with the ACD group parameter provided.
•
implicit/one step - by logging on to an ACD Group using the Set Agent State (loggedOn) service and omitting the ACD group parameter. If supported by the switching function, the agent is automatically logged on to an ACD group. Note that this capability cannot be simultaneously supported with the Log On to an ACD device.
An agent has several attributes that can be controlled and observed by the computing function, as described below. 6.1.1.6.1 Agent Identifier
Each agent that can be observed and/or controlled within the switching function is referenced using an assigned identifier. This identifier is associated with the logical element’s Device Identifier of the device. Certain switching functions may not assign an agent identifier to the agent. In these cases, the logical element’s Device Identifier is used to represent the agent associated with the device. The format of the agent identifier is switching function specific. There are two ways that an agent identifier may be provided: •
as a parameter in an event (via the agentID parameter in the Agent Logged Off event, for example) or
•
as a sub-string in the Switching Function Representation format of a logical element’s Device Identifier, thereby making a unique identifier for the logical element and the associated agent.
When an agent is associated with more than one ACD group and the switching function assigns a different agent identifier for each ACD group that the agent is associated with, then the following applies: •
The agent identifier shall be supplied (via the agentID parameter) on the agent state events associated with this agent (e.g., Agent Ready, Agent Not Ready).
•
This agent identifier may or may not be part of the Device Identifier parameters (i.e., the agent identifier sub-string in the Switching Function Representation format) in the call control events that are associated with the agent in an ACD call. Non-ACD calls are unaffected. - 38 -
•
This agent identifier shall be part of the Device Identifier parameter (i.e., the agent identifier sub-string in the Switching Function Representation format) on services when the computing function want to focus the service at a particular ACD call or group, otherwise if not supplied, the switching function will choose which ACD call or group the service is focused.
When an agent is associated with one ACD group, the switching function may or may not assign an agent identifier to the agent. If the agent identifier is not assigned, the logical element’s Device Identifier of the agent device is used to represent the agent in the ACD group. If the agent identifier is assigned, then either the logical element’s Device Identifier of the agent device or the agent identifier may be used to represent the agent in the ACD group. This also applies to the case where the switching function has only one agent identifier (either assigned or not) for an agent that is associated with multiple ACD groups. When only one agent identifier is assigned to an agent the following applies: •
The agent identifier may be supplied (via the agentID parameter) on the agent state events associated with this agent (e.g., Agent Ready, Agent Not Ready).
•
This agent identifier may be part of the Device Identifier parameters (i.e., the agent identifier substring in the Switching Function Representation format) in call control events that are associated with the agent in an ACD call. Non-ACD calls are unaffected.
•
This agent identifier may be supplied as part of the Device Identifier parameter (i.e., the agent identifier sub-string in the Switching Function Representation format) on services.
Note that when the agent identifier is supplied as part of the Device Identifier and the agent identifier is not associated with the device, the service request shall be rejected with a negative acknowledgement. 6.1.1.6.2 Agent Password
The agent password authenticates the agent’s association with a given device and ACD device or ACD group in the switching sub-domain. The agent password is used when the agent is associated with the device and made available to the ACD device or ACD group (i.e., log on) and when the agent is made unavailable to the ACD device or ACD group (i.e., log off). An agent password may be assigned to each agent. For more details, refer to the definition of the agentPassword parameter in associated services. 6.1.1.6.3 Agent Group Association
This identifies the ACD group that is associated with the agent. There can be zero or more ACD groups associated with the same agent. This is represented via the ACD group’s logical element’s Device Identifier. 6.1.1.6.4 Agent State
A state that an agent may take in relation to an ACD device or ACD group and the calls associated with the ACD device or ACD group. The computing function is informed of agent state changes through agent state event reporting. These event reports are sent to the computing function when a monitor is started on either the ACD device or ACD group (if supported by the switching function) or the device associated with the agent or agents. The following are the agent states with respect to an agent and a particular ACD device or ACD group: •
Agent Null - The state where an agent is not logged-on to (i.e., logged off from) the ACD device or ACD group at a particular device. Logging-on and logging-off from an ACD device or ACD group shall cause the transitions from and to this state. The event report that represents the entry to this state is the Agent Logged Off event. Note that the presence/absence of the ACD Group parameter in this event determines if the agent has logged off of an ACD device or an ACD group
•
Agent Logged On - The state where an agent is logged-on at a particular device to an ACD device or ACD group and is ready to contribute to the activities of the ACD device or ACD group. This state does not indicate that the agent is ready to accept ACD calls (refer to the Agent Ready event section). The event report that represents the entry to this state is the Agent Logged On event. Note that the presence/absence of the ACD Group parameter in this event determines if the agent has logged on to an ACD device or an ACD group. - 39 -
•
Agent Not Ready - The state where an agent is logged-on at a particular device to an ACD device or ACD group but is not prepared to handle calls that the ACD distributes. While in this state an agent may receive calls that are not ACD calls. The event report that represents the entry to this state is the Agent Not Ready event.
•
Agent Ready - The state where an agent is logged-on at a particular device to an ACD device or ACD group and is prepared to handle ACD calls even though it may be involved with non-ACD calls. The event report that represents the entry to this state is the Agent Ready event.
•
Agent Busy - The state where an agent is involved with an existing ACD call at the device, even if that call is on hold at that device. Calls between agents, calls between supervisors and agents and private calls may or may not cause this transition. The event report that represents the entry to this state is the Agent Busy event.
•
Agent Working After Call - The state where an agent is no longer connected to an ACD call but is still occupied with work related to a previous ACD call. In this state, an agent cannot receive ACD calls but may be able to receive non-ACD calls. The agent may be performing administrative duties (e.g., updating a business order form) for a previous call, or may be involved with a non-ACD call. The event report that represents the entry to this state is the Agent Working After Call event.
Note that this Standard does not impose or restrict the transition of an agent state to another agent state. Any implementation restrictions shall be reflected by a negative acknowledgement to the Set Agent State service request. 6.1.1.6.5 Agent State Models
It is possible that an agent may have several agent states with respect to the different associated ACD devices or ACD groups. Alternatively, an agent may have a single state to describe its relationship to all associated ACD devices or ACD groups (if the state is, in fact, the same for all of them). The following Multi-State Agent models that indicate how the switching function maintains the agent states for each ACD or ACD group that is associated with an agent. (The capability exchange services indicate which models are supported by a switching function.) The models are: Agent Multi-State Model (Independent Group Working) In this model, as illustrated in Table 6-1, the switching function maintains an independent agent state model for each ACD device or ACD group associated with an agent. All agent state transitions are totally independent. The cause code of Forced Transition does not appear since no state is forced. (Note that the numbers between parenthesis in the following figures represent the ACD group number). Table 6-1 Agent Multi-State Model (Independent Group Working) Illustration Step 1
Step 2
Step 3
Step 4
Step 5
ACD Group 1 State
Not Ready (1)
Not Ready (1)
Not Ready (1)
Not Ready (1)
Ready (1)
ACD Group 2 State
Not Ready (2)
Ready (2)
Busy (2)
Working After Call (2)
Ready (2)
ACD Group 3 State
Not Ready (3)
Ready (3)
Ready (3)
Ready (3)
Busy (3)
ACD Device State
Ready
Busy
Busy
Busy
Ready
Agent Multi-State Model (Semi-Independent Linked) In this model, as illustrated in Table 6-2, the switching function maintains an agent state model for each ACD device or ACD group associated with an agent. However the agent state models for each ACD - 40 -
device or ACD group are linked together. For example, if an agent is associated with two ACD groups (both states are Ready), and the agent connects to an ACD call for the first ACD group, the agent state for the first group transitions to Busy while the agent state for the second group goes to Not Ready (with a cause code of Forced Transition to indicate that the state transition was the result of another ACD device or ACD group activity).
Table 6-2 Agent Multi-State Model (Semi-Independent Linked) Illustration Step 1
Step 2
Step 3
Step 4
Step 5
ACD Group 1 State
Not Ready (1)
Not Ready (1)
Not Ready (1) Forced T. cause
Not Ready (1) Forced T. cause
Not Ready (1)
ACD Group 2 State
Not Ready (2)
Ready (2)
Busy (2)
Working After Call (2)
Ready (2)
ACD Group 3 State
Not Ready (3)
Ready (3)
Not Ready (3) Forced T. cause
Not Ready (3) Forced T. cause
Ready (3)
ACD Device State
Ready
Ready
Not Ready Forced T. cause
Not Ready Forced T. cause
Ready
Agent Orientated Model In this model, as illustrated in Table 6-3, the switching function maintains one state for the agent, no matter how many ACD devices or ACD groups the agent is associated with. When the ACD Group parameter is included in an agent event, it indicates the ACD group that has caused the agent state transition. When the ACD Group parameter is not included in an agent event, it indicates that non-ACD group activity has occurred. Table 6-3 Agent Orientated Model Illustration Step 1
6.1.2
Step 2
Step 3
Step 4
Step 5
ACD Group 1 State
Not Ready
Ready
Busy
Working After Call
Ready
ACD Group2 State
Not Ready
Ready
Busy
Working After Call
Ready
ACD Group 3 State
Not Ready
Ready
Busy
Working After Call
Ready
ACD Device State
Not Ready
Ready
Busy
Working After Call
Ready
Single Event
Not Ready (2)
Ready (2)
Busy(2)
Working After Call (2)
Ready (2)
Call Calls are communication relationships between one or more CSTA Devices. A call’s behaviour can be observed and manipulated across the CSTA service boundary (also called service boundary in this Standard). During some call phases (e.g., establishment and release) the call is not completely formed and there may be only a single CSTA Device involved (for example, the CSTA Device on whose behalf the call was initiated). In some call control operations, such as a conference and transfer, one CSTA Device in a call is replaced with another CSTA Device, or two calls are merged into a single call. The CSTA Call attributes, which are described in detail in the following sub-clauses, shall be: •
Call Identifier
•
Correlator Data - 41 -
6.1.2.1
•
User Data
•
Media Call Characteristics
•
Account Information
•
Authorisation Code
•
Charging Information
Call Identifier A CSTA Call Identifier (also called Call Identifier) is a reference associated with a call whereby the call is known to the switching, computing and special resource functions through the call’s life. A Call Identifier shall be allocated to each call by the Switching Function, at the latest, when the call first becomes visible across a CSTA Service Boundary. It shall be unique within a switching sub-domain and shall be the same for all CSTA Devices in the call. A Call Identifier can be assigned to a call before the call is fully established. For example, an incoming call may be assigned a Call Identifier when the called CSTA Device is alerting and before the call has been answered. A Call Identifier shall not only reference the entire call within the sub-domain but shall also infer a reference to that part of the call that is outside the sub-domain.
6.1.2.2
A call can pass through various stages involving many different CSTA Devices before it finally terminates. Some of these stages cause a call to change identifiers. Examples of services that cause this are Transfer and Conference. During the operation of these services, or as a result of manual intervention, the Call Identifier may change as a result of two calls being merged by the switching function but the call shall continue as a CSTA object. This merger results in the Call Identifiers for both old calls changing to a new identifier for the resulting calls in which the CSTA Devices are involved. The respective Conferenced or Transferred event specifies the transition from the old Call Identifiers to the new Call Identifiers indicating the old invalid Call Identifiers. Management of Call Identifiers is covered in section 6.1.6, “Management of Dynamically-Assigned Identifiers”. Call State
6.1.2.3
The term Call State means the collective set of Connection states for all the Connections comprising a call. Call state is returned only by the Snapshot Device Service for CSTA Devices that have calls. Connection states are further described in 6.1.3, “Connection”, on page 49. Call states are described in more detail in 6.1.4, “Call State Definitions”, on page 53. Correlator Data Correlator Data is computing function specific data which has been attached to a call that a computing function is controlling or observing. This information, for example, might be a key to a database entry, an application command sequence, file name, etc. Once Correlator Data is associated with a call, it remains with the call for its entire duration (at least one CSTA Device is actively involved in the call), or until the computing function overwrites the data with new data. In order to remove data, the computing function shall overwrite the existing data with null data. Correlator Data enters the switching sub-domain in two ways: 1. A computing function provides Correlator Data on a service request (e.g. Call Control and Call Associated services). 2. Correlator Data arrives from an external network connection with a call (for example, Correlator Data may be used as a key to pop a screen for the call). This Standard defines one possible mechanism for delivering Correlator Data through an external network. This mechanism is described in Annex B. Permitting a computing function to associate its own information with a call allows multiple computing functions to share data on calls which they are all controlling or observing. This feature is useful when calls are moving from one computing function to another in a distributed computer network or from one switching sub-domain to another. For more information on Correlator Data, refer to 12.2.10, “CorrelatorData”, on page 119. - 42 -
Correlator Data is provided by the Computing Function and associated with the call for its entire duration or until overwritten with new data. This data survives Conference and Transfer and can be provided on various events. An application may remove the Correlator Data by overwriting existing data with null data. When Correlator Data is associated with a call, call events that indicate that a CSTA Device has become part of a call (such as Delivered, Established and Queued events, for example) shall include the Correlator Data (if this parameter is supported in the event being reported). Subsequent call events also may contain the Correlator Data. Note that “null Correlator Data” means Correlator Data information with zero length. When a consultation call is transferred or conferenced and null or non-null Correlator Data is associated with the secondary call, the Correlator Data in the resulting call shall always be the same Correlator Data that was associated with the secondary call (even if only the primary call had non-null Correlator Data). In that case the Correlator Data (if any) associated with the primary call is discarded. If the secondary call contains no Correlator Data, the Correlator Data associated with the resulting call is that which was associated with the primary call. Table 6-4 Inheritance rules for Correlator Data in Conference and Transfer Secondary Call
No Correlator Data
6.1.2.4
Primary Call No Correlator Data
Null Correlator Data
Correlator Data 1
No Correlator Data
Null Correlator Data
Correlator Data 1
Null Correlator Data
Null Correlator Data
Null Correlator Data
Null Correlator Data
Correlator Data 2
Correlator Data 2
Correlator Data 2
Correlator Data 2
When Correlator Data is associated with a call via the Associate Data service, the Call Information event is provided by the switching function. If the data is changed by any other service, the switching function does not provide the Call Information event. User Data User Data is call-related computing function-to-computing function information that, unlike Correlator Data, is not associated with a call for the life of the call. The switching function receives User Data in two ways: •
A computing function sends User Data in a service request.
•
User Data arrives from an external network connection with a call (for example, User Data may be used as a key to pop a screen for the call).
Both a computing function and the network may send User Data in two ways: 1. With Call Control Activity - Call control service requests (and network signalling for call control) permit User Data as an optional parameter. The switching function reflects the delivery of User Data in the first call control event that results from the switching function or network carrying out the call control activity. When the computing function provides User Data in a Call Control service request, the User Data is delivered to other parties if and only if the call control service successfully completes. If the switching function does not generate the call control event that corresponds to the call control activity because the computing function has set an event filter that filters out the relevant event, then the User Data is not propagated to subsequent events and the User Data information will be lost. Refer to the description of the individual Call Control services for more details on the events that will contain User Data for those services. 2. Independent of Call Control Activity - The computing function may use the Send User Information service to pass User Data at any time. Some networks provide an independent signalling mechanism for sending User Data. The switching function generates a Call Information event with the userData parameter containing the received User Data to reflect the delivery of the User Data. - 43 -
Independent of call control activity, this event is generated for all computing functions monitoring the call and all computing functions monitoring any CSTA Devices that have a connection to that call. This Standard defines one possible mechanism for delivering User Data through an external network. This mechanism is described in Annex B. When a computing function uses a service to send User Data, the switching function sends that User Data only after the switching function sends a positive acknowledgement to the service request. 6.1.2.5
User Data is described further in 12.2.30, “UserData”, on page 145. Other Call Related Information There is additional information associated with calls such as:
6.1.2.6
•
Account Information - A computing function or business-specific piece of information that is assigned to a call for accounting purposes. For more information, see 12.2.1, “AccountInfo”, on page 113.
•
Authorisation Code - A code provided to the switching function that is used to check if a computing function user is authorised to perform a given service. For more information see 12.2.3, “AuthCode”, on page 113.
•
Charging Information - An amount charged to a device for a call in which the device was involved. For more information, see 12.2.7, “ChargingInfo”, on page 116.
Media Call Characteristics This Standard covers the control and observation of calls within either a voice or digital data switching sub-domain (e.g., network) or a switching sub-domain that is a combination of both (voice and digital data). Within the set of possible digital data switching sub-domains, this Standard is limited to a sub-set of these switching sub-domains with the following characteristics: •
connection-oriented
•
circuit or cell-based packet switching
•
point-to-point, and multi-point topology
•
A connection in a call may represent either zero, one, or many data channels within the switching sub-domain.
•
A CSTA Device can have multiple calls.
Examples of these digital data switching sub-domains that support these characteristics are; •
T1
•
ISO-Ethernet (TDM part of the protocol)
•
ISDN
•
Switched 56
•
RSVP
•
ATM (B-ISDN)
•
SIP
As a result, another attribute of a call is the Media Class (i.e., Voice or Data). Voice calls and the sub-set of digital data calls as described above use the same model for control and observation but with some additional unique characteristics for digital data. The following is the list of characteristics: 1. Media Class - Describes the type of call. It may consist of one or more of the following classes. •
Data - These types of calls involve digital data calls (both circuit switched and packet switched). Devices that may be involved with these types of calls are digital computer interfaces and G4 facsimile machines. - 44 -
•
Image - Digital data calls involving imaging, or high-speed, circuit-switched data in general. Devices that may be involved with these types of calls include digital video telephones and CODECs.
•
Voice - Devices in this class are used to make speech calls. This class includes standard telephones.
•
Audio - 3.1 KHz audio. Devices in this class are used to make audio calls excluding speech calls. It includes G3 fax and facsimile machines.
•
Chat - A type of Data class call that involves text-based messages that are exchanged between devices in the call using electronic media. A chat call is interactive since devices in the call can participate at the same time (i.e. originate and receive messages during the call.). The Data class must also be set for a Chat call.
•
Email - This class of calls involve a text-based message that is sent using electronic media. This is a non-interactive call (i.e. only one device involved with the call at one time). This is a specific type of mediaClass associated with electronic mail systems.
•
Message - This class of calls involve a text-based message that is sent using electronic media. This is a non-interactive call (i.e. only one device is involved with the call at one time). The message contents associated with these calls can usually be displayed on the called devices. Instant Messages (IM), Short Message Service (SMS) are examples of this mediaClass.
•
IM (Instant Message) - This class of calls involve a text-based message that is sent using electronic media. This is a non-interactive call (i.e. only one device involved with the call at one time). This is a specific type of Message media class associated with Instant Messaging systems.
•
SMS (Short Message Service) - This class of calls involve a text-based message that is sent using electronic media. This is a non-interactive call (i.e. only one device involved with the call at one time). This is a specific type of Message media class associated with Short Message Services systems.
•
MMS (Multi-Media Message Service) - This class of calls involve a text-based message that is sent using electronic media. This is a non-interactive call (i.e. only one device involved with the call at one time). This is a specific type of Message media class associated with Multi-Media Message Services systems.
•
Other - A class of call not involving one of the above classes.
2. Connection Rate - This characteristic reflects the amount of bandwidth which is needed or allocated for a digital data call. This characteristic is specified in kilobits per second. This characteristic also represents the amount of bandwidth for both directions of data flow. The computing function can learn about a switching function’s supported rates through the capability exchange services. 3. Bit Rate - This characteristic specifies if the bit rate is or needs to be a constant rate (i.e., dedicated bandwidth and constant rate of media stream delivery) or variable rate. A constant rate is used for media streams like audio or video. A variable rate is used for media stream like computer-generated data transfer. 4. Delay Tolerance - This characteristic specifies the maximum amount of media stream delivery delay that will be toleranced for the call. If the bit rate is constant, then this value will indicate the actual amount of media stream delivery delay for the life of the call. Where as if the bit rate is variable, it will be the maximum delay allowed during the life of the call. 5. Switching Function Call Control Information Elements - This characteristic provides a mechanism which enables the use of the switching function private call control information elements to be used during the life of a digital data call (e.g., elements used during call setup). The format, meaning and - 45 -
behaviour of these information elements are specific to the given switching function. This Standard allows the following types of switching function private call control information elements: •
ISDN - All information elements associated with call control from the ITU Q.931 standard.
•
ATM - All information elements associated with call control from the ITU B-ISDN Q.2931 standard.
•
RSVP - All information elements associated with the call control from the IETF RSVP functional specification.
•
ISO-Ethernet (TDM part of the protocol) - All information elements associated with call control from the 802.9 standard (a modified version of Q.933).
•
Private ISDN - All information elements associated with call control and supplementary service control from ECMA-143 and ECMA-165.
•
SIP - All information elements (SIP Headers) associated with call control and supplementary service control from IETF 3261 (and later versions).
•
Other - All information elements associated with call control from the particular switching function specification.
For details on the specific information elements of these types, see the appropriate standards or switching function specific documentation. If a given information element overlaps with an attributes or characteristic that is defined by this Standard, the information element should not be used and the attribute or characteristic in this Standard should be used. If both are supplied, then they shall contain the same value. In addition, any information element that deals with device addressing shall not be used (e.g., calling party number, calling party subaddress). The CSTA Device addressing in this Standard shall be used. Once these characteristics are established for a digital data call, they may, depending upon the protocol (e.g. SIP), be changed. These characteristics apply to all connections of the call.
6.1.2.7
The combination of these characteristics represents the quality of service associated with a given digital data call. The meaning of the quality of service which respect to characteristic combination is switching function specific. Call Linkage Although each CSTA call is independent of any other call (e.g., uniquely identified via its own call identifier), some CSTA calls can be related to other calls that exist in the same switching sub-domain or in different switching sub-domains.
6.1.2.7.1 Global Calls
Figure 6-22 shows how a call in one switching sub-domain is related to a call in another switching subdomain because both calls are part of the same “end-to-end” or “global” call. Even though there is a CSTA call in each switching sub-domain (C1 and C2), both calls are part of the same “end-to-end” or “global” call identified as G1 in the figure. The call linkage feature provides a reference (globalCallData) that can be used to represent the global call.
- 46 -
Figure 6-22 Illustration of a “global” or “end-to-end” call Switching Sub-Domain A
C1
D1
Switching Sub-Domain B
G1 D3
D2
C2
D4
legend: - Device D1 in sub-domain A called Device D4 in sub-domain B. - CSTA Call C1 represents a call in switching sub-domain A between calling device (D1) and an outgoing tr - CSTA Call C2 represents a call in switching sub-domain B between incoming trunk (D3) and a called devi - Global Call G1 represents the end-to-end view of the call. 6.1.2.7.2 Call Threads
Different calls (CSTA calls or global calls) can be associated because they are part of the same or part of a related telephony process or call thread. For example, as part of a CSTA Consultation Call service, a call that is placed on hold is associated or linked to the newly created consulted call. Figure 6-23 illustrates the relationship between three CSTA calls (C1, C2, C3), two global calls (G1 and G2), and one call thread (T1) as the result of when device D1 in switching sub-domain A consults with device D5 in switching sub-domain B. Figure 6-23 Illustration of a Call Thread
Switching Sub-Domain A T1
G1
G2 D1
C1
D2
C2
D3
Switching Sub-Domain B
D4
C3
D5
legend: - Device D1 has a call with device D2 and has consulted with device D5 in switching sub-domain B. - (D3 is an outgoing trunk and D4 is an incoming trunk). - There are two “end-to-end” or “global calls”: G1 involves devices D1 and D2. G2 involves devices D1, D3, D4, - There is one thread identified as T1. This thread involves calls C1, C2, and C3. The call linkage feature provides a reference (threadData) that can be used to associate different CSTA calls in a call thread. This information may be used by applications for correlating calls in multiple switching sub-domains, for correlating calls for charging/accounting purposes, or for call reporting purposes, etc. 6.1.2.7.3 Call Linkage Data
If the switching function supports the call linkage feature, it maintains call linkage data for every call and provides it on call control events (where specified) via the callLinkageData parameter (see 12.2.5, “CallLinkageData”, on page 114). Call linkage data can also be obtained via the Snapshot Call service.
- 47 -
The call linkage data consists of two components each representing a different relationship of the call to other calls. The globalCallData component is always provided if the switch supports the call linkage feature. The threadData component is only provided if the switching function also supports the thread linkage feature (as indicated by the capability exchange services). The two components are: 1. globalCallData - This component represents a “global” or “end-to-end” view of the call. The global call may involve one or more endpoints. The endpoints may reside in the same switching subdomain or in multiple sub-domains. If the call resides in multiple switching sub-domains, there may be multiple switching sub-domain (CSTA) calls involved in the global call, all referenced by the same globalCallData. When a new call is created, a switching function shall either: •
create new globalCallData for that call if the new call is not part of an existing global call
•
use the existing call’s globalCallData for the new call if the new call is part of an existing global call. This occurs when call arrives from another switching sub-domain and globalCallData is provided with the call.
2. threadData - This component represents a call thread - the set of calls that are associated because they are part of the same or a related telephony process. The call thread may involve multiple (CSTA and global) calls. When a new call is created, a switching function shall either: •
create new threadData for that call if there is no linkage to another call.
•
use existing threadData from a linked call for the new call (i.e., the call inherits the threadData from another call). The threadData can be inherited from a call from the same switching subdomain (as part of a CSTA Consultation Call service, for example) or can be inherited from a call from another switching sub-domain (if provided with the call).
•
When two calls are conferenced or transferred, the following inheritance rules apply: •
if only one of the calls was an incoming call (where an incoming call is defined as a call that was not originated at this device) at the conferencing/transferring device, the threadData for the resulting call shall be inherited from the incoming call. The threadData associated with the other call shall be discarded.
•
if both of the calls were incoming calls at the conferencing/transferring device, the threadData for the resulting call shall be inherited from the call that arrived first at the conferencing/transferring device. The threadData associated with the other call shall be discarded.
•
if both calls originated at the conferencing/transferring device, the threadData for the resulting call shall be inherited from the first call that originated at the conferencing/ transferring device. The threadData associated with the other call shall be discarded.
Refer to 12.2.5, “CallLinkageData”, on page 114 for more information on the CallLinkageData parameter type. 6.1.2.7.4 Synchronization of Call Linkage Data
When callLinkageData associated with a call is updated due to a telephony feature, callLinkageData shall be synchronized between calls in a switching sub-domain or between calls in different switching subdomains. For example, if a call is sent from an originating switching sub-domain to a terminating switching sub-domain, and then the callLinkageData is changed in the terminating switching sub-domain because of a conference, then the terminating switching sub-domain shall notify the originating switching sub-domain that its callLinkageData has changed so that the originating switching sub-domain can associate the updated callLinkageData with its call. (Annex B defines one possible mechanism that could be used for transporting the call linkage data through an external network.) The following CSTA events indicate when the callLinkageData associated with a call has been updated:
- 48 -
6.1.3
•
The CSTA Conferenced and Transferred events are used to indicate that the callLinkageData has changed as a result of a conference or transfer feature.
•
Otherwise, the CSTA Call Information event is used when the callLinkageData has been updated, in the same switching sub-domain that is reporting the Call Information event or in a different switching sub-domain. For example, for a call between two switching sub-domains, the Call Information event can be used to indicate that the callLinkageData has changed as a result of a feature in a different switching sub-domain (the mechanism described in Annex B is one way to transport the callLinkageData over the external network).
Connection A connection is a relationship in a switching sub-domain between a CSTA Device, and a call in which that CSTA Device is involved. This connection relationship can be both observed and manipulated. Figure 624 illustrates the relationship between calls, devices, and connections. Figure 6-24 Relationship between Calls, Devices, and Connections
Device
Connection
Call
Connection
Device
Observation and manipulation of these connections are the basis for call control services (such as Clear Connection, Answer Call, etc.). Connections are CSTA Objects that have the following attributes: 1. Connection Identifier - Each connection that can be observed and/or controlled shall be referenced across the service boundary. To accomplish this, each connection is assigned a unique identifier by the switching function. This identifier is comprised of a Device Identifier and a Call 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 Connection Identifier is unique within a sub-domain and over a single service boundary. It is provided by the switching function when either a new call is created or a new device becomes involved in a a call. A Connection Identifier can change as a result of some operations (e.g., a transfer or conference) and in these cases the switching function presents the computing function with the appropriate information to transit from the old identifiers to the new. The Device Identifier used in the Connection Identifier may be either static or dynamically-assigned by the switching function. As provided by the switching function to the computing function, a Connection Identifier will always include both a Device Identifier and a Call Identifier (unless otherwise noted in the specification of a particular CSTA event’s parameters). Computing functions wanting to correlate event reports which associate devices connected together in a call can use the Call Identifier to do this correlation. The definitions of a Connection Identifier and those identifiers that it comprises (Call and Device Identifiers) restrict computing functions from fabricating Connection Identifiers. As provided by the computing function to the switching function, a Connection Identifier shall be one which was originally provided by the switching function. An exception to this rule is where either a deviceID only or a callID only Connection Identifier is used in a specific service (as indicated by the capability exchange services). If a Connection Identifier, provided by the computing function, includes only a Device Identifier, then that Device Identifier shall be a static Device Identifier. These conditions ensure that it is possible to use only a Device Identifier (without a Call Identifier) or a Call Identifier (without a Device Identifier) to provide a Connection Identifier in certain specified circumstances. For additional details regarding Connection Identifiers, including Connection Identifier formats and specific functional requirements, see 12.3.9, “ConnectionID”, on page 149.
- 49 -
2. Media Stream Flow Direction - This attribute is the direction or directions in which the media stream can be transmitted on the given connection. The following are the types of directions that can be associated with a connection: •
Transmit - Media stream data can only be transmitted on the connection by the associated device.
•
Receive - Media stream data can only be received on the connection by the associated device.
•
Transmit and Receive -Media stream data can be transmitted and received on the connection by the associated device.
•
None - Media stream data cannot be transmitted or received on the connection by the associated device.
The media stream flow direction can be specified (via the participationType parameter or the connectionInformation parameters) on certain CSTA services and modified via the Change Connection Information service (see 18.1.3 on page 422). The media stream flow direction is indicated in events via the connectionInformation parameter and in the response to the Snapshot services. 3. Media Stream Channels - A channel is a path of communications between devices within a network. Channels are created to transmit/receive the media stream when the associated connection is created for the device in the call. The correlation of a channel to an actual media stream communications path/channel within the switching function is switching function specific. The switching function may represent a channel as a group of actual media stream communication paths. A device’s connection represents a channel or set of channels on which the media stream associated with the call is to be transmitted and received. The number of channels per connection is switching function and device specific (the capability exchange services may be used to determine the value). A digital data connection can use one or more channels. In addition, there can be multiple media stream types associated with a given connection as well as the associated channels. The attachment of media services is to a connection and its associated channels as a whole. The switching function is then responsible for attaching the Media services to the appropriate channels. 4. Media Session Information - Protocol specific information may be associated with the connection related to the media stream. This could be information derived from the Session Description Protocol (SDP), for example. The switching function may provide this information as media session information. The format, meaning and behaviour of the media session information is specific to the given switching function. 5. Connection State - A connection state involves a single call/device relationship. When a call is present at a device, the connection representing that call at that device will transit through various stages. State transitions are observed by the computing function through event reports. The transition from one state to the next is caused by either a manual user stimulus or a CSTA service initiated across the service boundary. Connection states may also be reported by Snapshots on either calls or devices.
- 50 -
Figure 6-25 Connection State Model
Null
Alerting
Initiated
Failed
Queued
Connected
Hold
The following are the connection state definitions: •
Alerting - A state in which an attempt is being made to connect a call to a device. There are three distinct modes where a connection may be in the alerting state: •
Offered - In this mode, the call is in a pre-delivery state at the target device. The opportunity exists for a computing function to issue one of a set of supported services (e.g., Accept Call, Clear Connection (“reject”), Deflect Call) or an ISDN device to accept or reject the call. From the calling side perspective, the call is not delivered at the called device. As a consequence, delivery information such as Ringback indication and/or Network signalling is not provided. For example, the device makes no ringing sounds while in the Offered mode of the Alerting state. The Offered mode is indicated by an Offered event.
•
Ringing - In this mode, the call is being presented for the purpose of having the device connect to the call and the user is made aware that the call is being delivered at the device. The Ringing mode is indicated by a Delivered event with a cause code other than “Entering Distribution”. The actual device activity to notify the user (e.g., ringing) is reported through the physical device feature events.
•
Entering Distribution - In this mode, a call is being delivered to a distribution device. The Entering Distribution mode is indicated by a Delivered event with a cause code of “Entering Distribution”.
•
Connected - A state in which a device is actively participating in a call. This state includes logical participation in a call as well as physical participation.
•
Failed - A state in which call progression has been aborted. This state generally results when a device tries to become Connected to a call or a call tries to become Connected to a device and the attempt fails. The Failed state can result from failure to connect the calling device and call, failure to - 51 -
connect the called device and call, failure to create the call, failure when the call ends and other reasons. Refer to 6.7.2, “Connection Failure”, on page 71 for more information.
6.1.3.1
•
Hold - A state in which a device is inactively participating in a call. This state includes logical participation in a call while physical participation is suspended.
•
Initiated - A state in which a device is requesting a service or in the process of dialling the necessary digit sequence to initiate a call to another device. The connection enters this state when the device goes off-hook (e.g., receiving dialtone) or the device is being prompted to go off-hook as a result of some service being initiated for the device.
•
Null - A state in which there is no relationship between a call and device.
•
Queued - A state in which call progression is suspended or made inactive while awaiting some form of action. Examples of situations in which a connection might transit to the Queued state include (among others) the following: •
A call is parked at a device.
•
A call is queued at a distribution mechanism, waiting for an agent to become available.
•
A call is camped on to a device.
•
An appearance of a shared bridged device configuration is inactive with respect to the call.
Table 1 on page 806 provides an example to illustrate each transition which is illustrated in Figure 6-25, “Connection State Model”.” 2. Call Event Reports The Connection state model provides an abstract view of actual states and events that are communicated via underlying signalling systems. This abstract view is introduced to provide a language for describing CSTA Event Reports, states and Functional descriptions. Because of the topology of the Switching Function, the signals that report events and state changes have definite sources. Providing a telecommunications object (the Connection) that can be associated with the source of these signals helps when explaining the meaning of events and the operation of CSTA (and other) telecommunications services. Note that on a typical ISDN access to a network there exists a distributed state machine. One part of this distributed state machine resides in the ISDN device. Another part resides on the other side of the ISDN access. There is another similar distributed-state access machine that resides across the ISDN network at a similar device. Using this concept, a call can be modeled as a collection of Connection state machines communicating with one another using signalling. When this communication occurs, a CSTA Event Report can be generated. In the following figure, this concept of communication between two state machines is illustrated for the case of establishing a simple call. Additionally, on each side of the figure the ISDN call states are indicated.
2. For an explanation of the Initial and Final State diagrams’ nomenclature used the Table 1, refer to Clause 11, “Template Descriptions”, beginning on page 107.
- 52 -
Figure 6-26 Relationship of CSTA Call Event Reports Time
Device D1
Call C1
Device D2
T1
Null
Null
No Event Report
Null
Null
T2
Setup
Initiated
Service Initiated
Null
Null
T3
Proceeding
Connected
Originated
Null
Null
T4
Delivered
Connected
Delivered
Alerting
Receive
T5
Connected
Connected
Established
Connected
Connected
ISDN Call State
CSTA Connection States
CSTA Event Reports
CSTA Connection States
ISDN Call State
Notice in Figure 6-26 that the CSTA Event Reports are based on signalling interactions of the Switching Function. Many Connection events are of interest to CSTA applications. Typically, however, a CSTA application is interested in atomic telecommunications activities and these often involve many simultaneous Connection events. Generally, telecommunications operations embody changes to many Connections. These events can be summarized in a single Event Report. For instance, the Transfer, Conference and Clear Call Services all make changes to multiple Connections but are each represented by single Event Reports. The Connection state changes associated with each CSTA Event Report are defined in this Standard. 6.1.4
Call State Definitions The state of a CSTA Call can be precisely expressed as the list of Connection states of all the devices involved in the call. This list is called the Compound Call State. The technique of listing the Connection states to describe the Call state can describe any call state that is possible in CSTA. However, most calls involve a small number of widely recognized states. CSTA defines those states in terms of their set of Connection states, but communicates them as atomic Call states - not as a list. These widely recognized states are called the Simple Call States. For calls with one known Connection state, the single Connection state shall be provided as a Call state. Note that since Null can be a known Connection state, for a nascent call it is possible to have a CSTA Call state with only one non-Null Connection (see Table 6-5). For calls with more than two non-Null Connection states, the list of Connection states is provided as the call’s state. CSTA simplifies Call states by relating them (at times) to particular devices. These relationships are described by differentiating the call’s Connection states. The Connection state associated with a particular device is called the local Connection state (for that device). Other Connection states are not differentiated from one another. Thus, CSTA Call state is defined for a device by the combination of Connection states as well as the order in which the Connection states are combined. For example, the Alerting-Connected Call state is not the same as Connected-Alerting. The first is defined as Received and the second is defined as Delivered. For calls with exactly two Connections, the CSTA Call state assigned to the combinations of Connection states are summarized in the following table. If there is no Simple Call state
- 53 -
for a particular combination of Connection states, then a Compound state shall be provided as the Call state. For Compound Call states, the first Connection state in the list shall be the local Connection state. Table 6-5 Definition of CSTA Simple Call States Local Connection State
Other Connection State
CSTA Simple Call State
Alerting
Connected
Received
Alerting
Hold
Received-On Hold
Connected
Alerting
Delivered
Connected
Connected
Established
Connected
Failed
Failed
Connected
Hold
Established-On Hold
Connected
Null
Originated/Terminated
Connected
Queued
Queued
Failed
Null
Blocked
Hold
Alerting
Delivered-Held
Hold
Connected
Established-Held
Hold
Failed
Failed-Held
Hold
Queued
Queued-Held
Initiated
Null
Pending
Null
Null
Null
NOTE
6.1.5
The Originated / Terminated state may occur both during call set-up and when the call ends. When a farend party drops from a two-party call and the near-end end-point is not returned immediately to idle, then the Originated / Terminated state is entered for call tear-down. It is also possible to enter a blocked state when a call ends. Referencing Devices, Elements, Appearances and Device Configurations In services and events, devices, elements, appearances and device configurations are referenced using Device Identifiers or Connection Identifiers when a call is present at the device, element, or appearance. Table 6-6 indicates how these Device Identifier references are interpreted. The Connection Identifier references are described in 6.1.3, “Connection”, and when a Connection Identifier is used it refers to the specific device, element or appearance associated with the given call. The following symbols are used in the table: Logical
This indicates that the Device Identifier passed will be interpreted as reference to a specific logical element.
Physical
This indicates that the Device Identifier passed will be interpreted as reference to a specific physical element.
Device
This indicates that the Device Identifier passed will be interpreted as reference to the entire device configuration.
Appearance This indicates that the Device Identifier passed will be interpreted as reference to a specific addressable appearance of a logical element. In order for computing function to determine what type of referencing is supported for a given logical element, it shall use the capability exchange services (13.1 beginning on page 158).
- 54 -
Refer to 10.1, “Device Identifier Formats”, for the format of Device Identifiers. Table 6-6 Device Identifier Interpretation Service/ Event Categories
Identifier Represents
Call Control, Call Associated, Media Service and Routeing Services
Device
The device (configuration) itself selects which appearance is to be used.
Appearance
The Device Identifier selects the specific appearance which is to be targeted by the service.
Call Control, Call Associated and Media Service Events, as well as switching function to computing function
Device
The Device Identifiers that are associated with an appearance identify only the associated device configuration rather than a specific appearance.
Logical Device Services
Logical
The Device Identifier refers to the particular logical element.
Logical Device Events
Logical
The content of the event parameters indicates the given logical element being used.
Physical Device Services
Physical
The Device Identifier shall refer to the particular physical element.
Physical Device Events
Physical
The content of the event parameters indicates the given physical element being used.
Device Maintenance Events
Device
The event parameter contains the Device Identifier of the device configuration.
Monitor Start Service (Call Control/ Associated, and Media Service events)
Device or Logical
The Device Identifier of the device configuration (Device) results in the observation of the entire configuration. The Device Identifier of the particular logical element (Logical) results in the observation of the entire logical element.
Monitor Start Service (Logical Device events)
Additional Information
Note that this information relates to the content of the event parameters, not what is supplied on the Monitor Start service. Appearance
The Device Identifier selects the specific appearances which are being reported in the event. Note that this information relates to the content of the event parameters, not what is supplied on the Monitor Start service
Not that this information relates to the content of the event parameters, not what is supplied on the Monitor Start service.
Note that this information relates to the content of the event parameters, not what is supplied on the Monitor Start service.
Note that the event filter determines the types (logical or device) of the events required. The Switching Function interprets the Device Identifier to meet the requirements of the filter. This may result in the same Device Identifier being interpreted as both Device and Logical for different event categories. Appearance
The use of the Device Identifier results in the observation of the specific appearance.
Logical
The use of the Device Identifier results in the observation of the particular logical element.
Logical = logical element’s Device Identifier Physical = physical element’s Device Identifier Appearance = addressable appearance (can be recognised from other forms of Device Identifiers by the suffix) Device=a Device Configuration formed by multiple devices, which is referenced by the Device Identifier
- 55 -
Table 6-6 Device Identifier Interpretation (concluded) Service/ Event Categories
Identifier Represents
Additional Information
Monitor Start Service (Physical Device events)
Physical
The use of the Device Identifier results in the observation of the particular physical element.
Monitor Start Service (Device Maintenance events)
Device
The use of the Device Identifier results in the observation of the device configuration.
Snapshot Services
Logical
The Device Identifier refers to the particular logical element.
Logical = logical element’s Device Identifier Physical = physical element’s Device Identifier Appearance = addressable appearance (can be recognised from other forms of Device Identifiers by the suffix) Device=a Device Configuration formed by multiple devices, which is referenced by the Device Identifier
6.1.6
Management of Dynamically-Assigned Identifiers Management of dynamically-assigned Device Identifiers and Call Identifiers is provided through management of Connection Identifiers. This ensures that an identifier whose meaning is dependent on another identifier is always provided in the proper context (i.e., with the other identifier needed to resolve its meaning). For example if a Call Identifier is given relative to a device, then giving the Connection Identifier ensures that the Call Identifier is provided with its reference - the Device Identifier. Management of Connection Identifiers shall be provided as follows. Connection Identifiers shall be provided when either a new call is created or a new device becomes involved in a call. When a call is made a Connection Identifier shall be provided. A Connection Identifier shall be provided in Event Reports that pertain to a call. When a device becomes involved in a call, the Connection Identifier shall be provided in the Event Reports that occur at that device. If a call changes its Call Identifier when a Conference or Transfer occurs, Connection Identifiers shall be provided to link the old Call Identifier to the new Call Identifier. Similarly, if a Device Identifier is changed, new Connection Identifiers shall be provided for the devices in the call. Management of identifiers shall be provided via parameters included in Service acknowledgements and Event Reports. Identifiers shall cease to be valid when their context vanishes. If a call ends, its Call Identifier is no longer valid to refer to that call. Similarly, if a device is removed from service or from a call, its dynamicallyassigned Device Identifier shall become invalid. Identifiers can be reused. Once an identifier has lost its context it may be re-used to identify another object. It is recommended that implementations not re-use identifiers immediately. Individual Call and Device Identifiers are not guaranteed to be globally unique. CSTA requires that the combination of Call and Device Identifier be unique within a CSTA switching sub-domain. To accomplish this, either the Call Identifier, or the Device Identifier (or both) shall be unique. In many cases the Connection Identifier requires both the Call and Device Identifiers to uniquely refer to Connections in a call.
6.2
I/O Services I/O-Services support the exchange of data between a computer application (a computing function component) and a telephony device (to send Data from the computer application to the display of a telephony device, or to send Data from the keypad of a telephony device to the computer application, etc.). - 56 -
NOTE Both the I/O Services and the Physical Device Features provide the capability to write to the display of a device and to detect keypad activity at a device. The primary difference between these two approaches is that the I/O services operate within the context of a data path, which is described below. The I/O-Services are defined as a distributed application between the switching function and the computing function. The special resource function is not involved. Figure 6-27 I/O Services Functional Architecture
Figure 6-27 shows that the exchange of data between a telephony device and a computer application consists of two parts: 1. the exchange between the switching function component and the computing function component, provided by the CSTA-Protocol. 2. the exchange between the telephony device and the switching function component, provided by a switch- specific protocol. 6.2.1
Data Path Definition To allow computer applications to cooperate with a switch-specific protocol (see Figure 6-27), a common view (the data path) is defined: •
The data path is an abstract model of a switch-specific protocol/mechanism.
•
The data path is a logical object in the switching function that allows the exchange of data between a telephony device and a switching function component for a given application association.
•
The computing function component is able to control the data path via the I/O-Services.
•
The computing function component is also informed via the I/O-Services when an entity in the switching function controls the data path.
•
The data path ends in the switching function component, it is not part of the CSTA-link between the switching function component and the computing function component.
•
The switching function component is a gateway between the data path and the CSTA link: •
It receives CSTA service requests from the computing function component to control the data path (via the Start Data Path, Suspend Data Path, Resume Data Path, and the Stop Data Path services) and activates the equivalent switch-specific protocol-mechanisms (and vice versa, including the Data Path Suspended/Resumed services).
•
It receives data (via the Send Data, Send Multicast-Data, Send Broadcast-Data, and the Fast Data services) from the computing function component and sends this data through the data - 57 -
path (via a switch-specific protocol) to the target device (and vice versa, but only via the Send Data and Fast Data services). 6.2.2
I/O Registration Services The I/O registration services registers the computing function as an I/O server for a specific device or for all devices within the switching sub-domain. If the switching function supports the I/O Registration services, then the computing function shall use the I/O Register service to register for I/O services before it can receive any I/O service requests over switching function requested data paths. Note that an I/O registration is not applicable when a data path is initiated by the computing function (i.e., a computing function can initiate a I/O data path after an I/O registration but the ioRegisterReqID parameter is not provided in the I/O services related to a data path that has been initiated by the computing function).
6.2.3
Data Path States and Operational Model The following data path states are defined in the I/O Services Operational Model: Null
No relation between a data path and a telephony device. No I/O Cross Reference Identifier is defined.
Open
The data path is able to transfer data (direction is defined in the Start Data Path service). An I/O Cross Reference Identifier is defined.
Suspended The data path is not able to transfer Data. The relation to a telephony device still exists, the I/O Cross Reference Identifier is still valid. Figure 6-28 Data Path State Model
Null
Start Data Path Stop Data Path Stop Data Path
Open
Suspend Data Path Data Path Suspended
Suspended
Resume Data Path Data Path Resumed
6.2.4
I/O Services Example The following figure illustrates a possible CSTA configuration involving a data path from/to a CSTA object through the switching function. The data path is established via the Start Data Path service issued, in this example, by the computing function. If the switching function temporarily stops (suspends) the data flow (without destroying the data path), it informs the computing function via the Data Path Suspended service. The switching function might have suspended the data path because it had received a Suspend Data Path service from the computing function or it may have suspended the data path without such a request from the computing function (because of an incoming call at the device, for example).
- 58 -
Figure 6-29 I/O Services Example
6.3
Call Detail Record (CDR) Services
6.3.1
Call Detail Record (CDR) Services allow access to information regarding call details that has been collected, processed and/or stored by the switching function. This information may include detailed call charges, destination, bill-to-account, authorization codes, etc. This information may be provided in realtime (i.e., immediately after the conclusion of a call) or in batch mode. CDR Services Examples Figure 6-30 illustrates the flow of CDR services when they are used to collect call detail information after every call. In this example, the computing function issues a Start Call Detail Report Transmission service and specifies that the switching function should send call detail information after every call by specifying the transferMode parameter as transferAtEndOfCall (line 1). The switching function responds with a positive acknowledgement (line 2) that includes a CDR cross reference identifier (with a value of 5) which will be present in subsequent CDR services. Line 3 shows a call, called c1, that was cleared. Since the switching function is sending call detail information after every call, the switching function sends the call detail information for call c1 using the Call Detail Record Report service (line 4), which is acknowledged by the computing function (line 5). Lines 6 through 8 show the same sequence for another call, called c2. When the computing function is no longer interested in CDR information, it stops the reporting by using the Stop Call Detail Report Transmission service, specifying the CDR cross reference identifier with a value of 5 (line 9).
- 59 -
Figure 6-30 CDR Services Example: Call Details “After Every Call”
Switching Function
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Computing Function
Start Call Detail Report Transmission (transferMode=transferAtEndOfCall) service (positive acknowledgement with cdrCrossRefID=5) (call c1 is cleared) Call Detail Record Report (call detail parameters for call c1, cdrCrossRefID=5) service (positive acknowledgement) (call c2 is cleared) , cdrCrossRefID=5) service Call Detail Record Report (call detail parameters for call c2) (positive acknowledgement) Stop Call Detail Report Transmission (cdrCrossRefID=5) service (positive acknowledgement)
Another example as shown in Figure 6-31 illustrates the flow of CDR services when they are used to collect call detail information and retrieved at the request of the computing function. In this example, the computing function issues a Start Call Detail Report Transmission service and specifies that the switching function should store call detail information (until explicitly requested by the computing function) by specifying the transferMode parameter as transferOnRequest (line 1). Lines 3 and 4 show two calls in the switching function that were cleared. Since the switching function is not sending call detail information after every call, the switching function stores the CDR information instead of sending it at this time. When the computing function wants the CDR information, it sends the Send Stored Call Detail Records service (line 5) that requests the switching function to start sending its stored CDR records. The switching function sends its two stored reports for calls c1 and c2 via a Call Detail Record Report service (line 7). Line 9 shows that the switching function has stored CDR information for a number of calls. Since the computing function has not requested CDR information to be sent during this period, the switching function has used the Call Detail Records Notification service to indicate that a threshold reached condition has occurred in the switching function (line 10). The computing function uses the Send Stored Call Detail Records service to start the transmission of CDR information from the switching function (line 12). The switching function sends a series of Call Detail Record Report services that provides the stored CDR information (lines 14 & 16).
- 60 -
Figure 6-31 CDR Services Example: Call Details “On Request”
Switching Function
1. 2.
6.4
Computing Function
Start Call Detail Report Transmission (transferMode=transferOnRequest) service (positive acknowledgement with cdrCrossRefID=6)
3.
(call c1 is cleared)
4.
(call c2 is cleared)
5.
Send Stored Call Detail Records (cdrCrossRefID=6)
6.
(positive acknowledgement)
7. 8.
Call Detail Record Report (cdrCrossRefID=6, calls c1, c2) (positive acknowledgement)
9.
(calls c3.....c9999 are cleared, CDR records stored)
10.
Call Detail Records Notification (cdrCrossRefID=6, cdrReason=threshold reached)
11.
(positive acknowledgement)
12.
Send Stored Call Detail Records (cdrCrossRefID=6)
13.
(positive acknowledgement)
14. 15.
Call Detail Record Report (cdrCrossRefID=6, calls c3 through c10)
16. 17.
Call Detail Record Report (cdrCrossRefID=6, calls cxx through c999) (positive acknowledgement)
(positive acknowledgement)
Capabilities Exchange The concept of capability exchange is one in which the switching function informs the computing function, through the service boundary, about the characteristics of its sub-domain in relationship to the operational model and feature definitions. This enables the computing function to use the services of the switching function based on its characteristics. This exchange shall be performed before the computing function can control and/or observe any device in the switching sub-domain but not before the switching function has reported its system status (i.e., the System Status service).
6.4.1
There are two levels of capability exchange available to the computing function: switching function and device specific capabilities. Switching Function Capabilities The first level is the capabilities for the switching function. These capabilities represent the set of all capabilities within the switching function. The Get Switching Function Capabilities can be used to obtain - 61 -
the entire set of all capabilities within the switching function. The Get CSTA Features service can be used if only the list of supported services and events are needed.
6.4.2
The list of devices that can be controlled and/or observed within the switching sub-domain can be obtained by using the Get Switching Function Devices service. This service causes the switching function to send one or more Switching Function Devices service(s) that contain the list of devices and optionally the device type, device name, and other information associated with each device. Device Capabilities Even though the Get Switching Function service gives the computing sub-domain most of the information to properly use the capabilities of the switching function, this information is sometimes not enough to totally understand the unique capabilities of a given device in relationship to the operational model or feature. Thus, another level of capability exchange exists which allows the computing function to obtain the specific capabilities associated with a given device or device configuration. This level of information is needed to better understand capabilities for an individual device. These specific device capabilities are obtained by using the following services (in any order):
6.4.2.1
•
Get Physical Device Information service
•
Get Logical Device Information service
The ability to use these services depends on whether or not the switching function actually supports these services. The computing function obtains this information from the Get Switching Function Capabilities service. Physical Device Capabilities This Get Physical Device Information service is used to obtain most of the capabilities and configuration information associated with the physical element of a device. To obtain the rest of the physical element characteristics, the computing function shall use the Get Button Information, Get Lamp Information, Get HookSwitch Status, Get Ringer Status, and Get Auditory Apparatus Information services to obtain all of the information associated with the device’s lamps and buttons. This information is used when controlling or observing the physical element of the device. If the service indicates that the device has logical characteristics, the Get Logical Device Information service may be used for all associated logical elements.
6.4.2.2
If the service is used on a device that does not have any physical characteristics the service shall be rejected. Logical Device Capabilities The Get Logical Device Information service is used to obtain the capabilities and configuration information associated with the logical element of a device. This information is used when controlling or observing the logical element of the device. If the service indicates that the device has physical characteristics, the Get Physical Device Information service may be used for all associated physical elements.
6.4.3
If the service is used on a device that does not have any logical characteristics the service shall be rejected. Dynamic Feature Availability A computing function can determine all possible CSTA services that can be applied to a connection given its state by using static information obtained through the Capability Exchange services. However, in certain implementations, there are situations where the set of services that can be applied to a connection varies depending upon how the connection got to a certain connection state and/or certain features active at a given device. In these cases, the static information provided in the Capability Exchange services may not reflect the actual set of services that are allowed.
- 62 -
If the Dynamic Feature Availability option is supported (as indicated through the Capability Exchange services), the actual set of CSTA services that can be applied to a connection at a given point is provided through the servicesPermitted parameter in every appropriate event. Refer to 12.2.25, “ServicesPermitted”, on page 142 for a description on the use and restrictions of this parameter.
6.5
Switching Function Information Synchronization
6.5.1
Since the information obtained through the capability exchange services and call events may change after the information has been obtained, this Standard defines mechanisms that may be used to notify and provide the computing function with the updated information. This allows synchronization to be maintained with switching function information. Switching Function Level Information The following list describes how the computing function is notified when switching function level information has been changed.
6.5.2
•
switching function capabilities - The Switching Function Capabilities Changed service is used to notify the computing function when information contained within the positive acknowledgement of the Get Switching Function Capabilities service has changed. The computing function shall issue the Get Switching Function Capabilities service to get the current information.
•
switching function devices - The Switching Function Devices Changed service is used to notify the computing function when information contained within the Switching Function Devices service has changed. The computing function shall issue the Get Switching Function Devices service to get the current information.
Device Level Information The following list describes how the computing function is notified when device level information has been changed. •
6.5.3
device capabilities - The Device Capabilities Changed event is used to notify the computing function when information contained within the positive acknowledgement of the Get Physical Device Information and/or Get Logical Device Information services has changed. The computing function shall then issue the appropriate Get Physical Device Information and/or Get Logical Device information services to get the current information.
Call Level Information The following list describes how the computing function is notified when call level information has been changed. •
account information and authorisation code - The accountInfo and the authorisationCode parameters in the Call Control events represents the current account information and authorization code. In the situation where this information has changed independently of call activity (manual entry or via the Associate Data service, for example), the Call Information event is used to notify the computing function of the updated value.
•
calling device - The callingDevice parameter in the Call Control events represents the calling device associated with the call. In the situation where this information was originally unknown and has now become available, the Call Information event is used to notify the computing function of the updated value.
•
dynamic feature availability - The servicesPermitted parameter in the Call Control events represents the set of services that can be applied to a connection. In the situation where the servicesPermitted parameter changes due to another call’s connection changing state, the Call Information event is used to notify the computing function of the updated capabilities for the connection that did not change state.
- 63 -
•
User Data and Correlator Data - The userData and the correlatorData parameters in the Call Control events represents the current values of User Data and Correlator Data. In the situation where this information has changed independently of call activity (Send User Information or Associate Data services, for example), the Call Information event is used to notify the computing function of the updated values.
6.6
Status Reporting Services
6.6.1
Note that this section describes the Status Reporting services between the Switching Function and the Computing Function. System Status
6.6.1.1
System Status services provide a way for the computing function and switching function to exchange information about the overall status of the system within each function. For each service boundary in a CSTA environment, the computing function and switching function on each side maintain a status attribute. System status services are bi-directional, enabling the computing function to report its status to the switching function, or to request the status of the switching function, and vice-versa. System Status Registration Before the computing function can receive any system status service requests, it may be required to register with the switching function for system status services using the System Status Register service. The positive acknowledgement to this service contains the system status register identifier (sysStatRegisterID) that the computing function uses to identify service requests that arrive for this registration. If the switching function supports the System Status Registration services, then the computing function shall use the System Status Register service to register for system status services before it can receive any system status service requests. The first (mandatory) System Status service request from the switching function issued during an initialization sequence is an exception to this rule, however. If the switching function does not support the System Status Registration services, then the computing function may receive system status service requests at any time. The capabilities exchange services can be used to determine if the switching function supports the System Status Registration services. The type of system status service requests that apply to the registration can be chosen by the computing function when it issues the System Status Register service request. A status filter can also be specified such that only the status’s of interest to the computing function will be reported by the switching function (i.e., if the bit for a status is set in the status filter, then that status is not reported). This filter can be changed using the Change System Status Filter at any time while the registration is active. A system status registration can be cancelled using the System Status Register Cancel service. Once the switching function sends a positive acknowledgement to this service, it will no longer send system status service requests to the computing function. Additionally, the switching function can cancel a system status registration at any time by sending the computing function a System Status Register Abort service request.
6.6.1.2
While the system status services themselves are bi-directional, the System Status Registration services are not. These services are only issued by the computing function. The switching function does not register with the computing function for system status services. The switching function is considered to be (implicitly) registered to receive system status service requests from the computing function at any time. System Status Services There are four System Status Services: System Status, Request System Status, Switching Function Capabilities Changed, and Switching Function Devices Changed. The first service is used by the requesting function to report its status to the function receiving the service request. The second service is used by the requesting function to request (i.e., query) the status of the responding function. The last two services are used to notify the computing function that switching function level information has changed (6.5.1, “Switching Function Level Information”, on page 63). - 64 -
The computing function can determine if the switching function uses the System Status service for periodic status reporting (i.e., heartbeats) using the capabilities exchange services. The Get Switching Function Capabilities service positive acknowledgement defines a parameter (systemStatusTimer) that is used to indicate whether periodic status reporting is used and if so, how often the computing function should expect the reports. The recovery action to be taken by the computing function in the event of a loss of heartbeats is implementation specific. All System Status services use the following values to indicate system status:
6.6.2
•
Initializing - The system is re-initializing or restarting. This status indicates that the system is temporarily unable to respond to any service requests. If provided, this status message shall be followed by an Enable status message that indicates that the initialization process is completed.
•
Enabled - Request and responses are 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.
•
Normal - This value can be sent at any time to indicate that the status is normal. This status has no effect on other services.
•
Messages Lost - This status indicates that a service request, response, or event report may have been lost.
•
Disabled - This cause value indicates that active Monitor Start monitor requests have been disabled. Other requests and responses may also be disabled, but, unlike monitors, reject responses are provided for those.
•
Partially Disabled - Some of the objects in the system can not be reached. Existing monitors on these objects will not provide events and computer requests targeting these objects will be rejected. This cause indicates to the receiving function that a degradation of service level may occur but not complete system disability. Automatic or manual actions may be taken to remedy the parts disabled.
•
Overload Imminent - The system is about to reach an overload condition. The client should shed load to remedy the situation.
•
Overload Reached - The system has reached an overload condition and may take action to shed load. The server may then take action to decrease message traffic. This may include stopping existing monitors or rejecting any new requests sent by the client.
•
Overload Relieved - The system has determined that the overload condition has passed and normal application operation may resume.
Each system status service request may contain a system status registration identifier (sysStatRegisterID) to identify the associated system status registration (when system status registration is supported by the switching function). A system status service request from the computing function should never contain a system status registration identifier. Monitoring To track call control and other activity, and to receive notification of all changes in the switching Function, the computing function uses a feature called monitoring. By starting a monitor, the computing function indicates that it wants to be notified of specific changes that occur in the objects (call and device) and device attributes of a switching function. Examples include: •
Notification that a call has arrived at a device.
•
Notification that a call has been answered.
•
Notification that a feature such as “Forwarding” or “Do Not Disturb” has changed at a device.
Once a monitor is established, the switching function notifies the computing function of relevant activity by sending messages called event reports, or simply events. - 65 -
For example, in the area of Call Control, events report the state transitions through which connections pass. In this way a computing function is able to determine what services are applicable to a given connection. For example, the Delivered event indicates when a connection state transits to the Alerting state. The event categories are as follows:
6.6.2.1
•
Call Control - These events report changes to information related to calls.
•
Call Associated - These events report changes to information related to calls.
•
Media Stream - These events report changes associated with attachment of a call to a media device.
•
Physical Device - These events report changes to the components of a device's physical element.
•
Logical Device - These events report changes to feature settings associated with a device's logical element(s).
•
Voice - These events report changes to Voice Unit messages and Interactive Voice devices.
•
Maintenance - These events report changes regarding maintenance.
•
Private - These events are switching function specific.
Starting and Stopping a Monitor The Monitor Start service is used to establish a monitor. The computing function indicates the monitor object that it is interested in observing, the type of monitoring, the type of calls to monitor, and the list of events that it is interested in. Once the Monitor Start service request has been validated by the switching function, the switching function provides a positive acknowledgement that includes a Monitor Cross Reference Identifier that uniquely identifies the monitor. The switching function also provides this identifier as a parameter in all events associated with this monitor. The computing function can use this identifier to correlate events to the particular Monitor Start service that established the monitor. (This identifier is also used in the Monitor Stop and Change Monitor Filter services.) The Monitor Stop service is used to stop an established monitor. When a Monitor Stop service has been sent by the computing function, the switching function stops the monitor, releases the Monitor Cross Reference Identifier, and no longer provides events to the computing function. The Monitor Stop service may also be sent from the switching function to the computing function when the switching function stops an existing monitor. This occurs when the monitor object is a call-object (Table 6-7), or when the switching function shall terminate a monitor due to load conditions, for example.
6.6.2.2
Refer to 15.1 beginning on page 216 for a complete description of the Monitor Start and Monitor Stop services. Monitor Objects The computing function indicates what it wants to monitor by specifying a monitor object parameter in the Monitor Start service request. There are two possible monitor objects: call-object and device-object. The following table describes the monitor objects. Table 6-7 Monitor Objects Monitor Object call-object
Description Place a monitor on an existing call/connection. Only the specific call is monitored. A Monitor Stop service is sent by the switching function to indicate when the existing call is no longer monitored.
device-object
Place a monitor at the specified device. The device may represent a single device (e.g. station) or may represent a group device (e.g. hunt group).
- 66 -
6.6.2.3
Monitor Types The computing function also indicates a monitor type when starting a monitor. There are two types of monitoring: call-type and device-type. The following table describes the possible monitor types and their meanings. Table 6-8 Monitor Types Monitor Type
Description
call-type
The call continues to be monitored as long as it remains in the switching sub-domain. For example, if a call that is being call-type monitored is transferred to another device in the switching sub-domain, the call will continue to be monitored. The computing function receives events for all devices in the call until the call ceases to exist or until it leaves the switching subdomain. The Diverted event is an exception. The switching function (as indicated through the capabilities exchange services) may or may not be providing Diverted events to all devices in a call. For call-type monitors:
device-type
6.6.2.4
•
When a device ceases to participate in a call, and the call is transferred or forwarded to another device, subsequent events at the new device are reported. The Monitor Cross Reference Identifier used in events at the new device will be the same one used before the call was forwarded or transferred.
•
If a call is being monitored using a call-type monitor and one of the devices consults to another device (i.e. a new call is created), then the computing function will not see events for the secondary call (new consultation call) until either the primary call is transferred to the consulted device, or until the two calls are conferenced together.
•
A call that is being monitored may have a new Call Identifier assigned to it after a conference or transfer. The switching function reports the new Call Identifier in a Conferenced or Transferred event.
The call does not continue to be monitored after the call leaves the device.
Relationship of Monitor Objects and Monitor Types Monitor objects and monitor types are independent. A monitor object describes what the monitor is being placed on, while the monitor type describes if a call continues to be monitored after it leaves a device. The following table describes the possible combinations of monitor objects and monitor types and what the resulting combinations represent. Table 6-9 Monitor Object/Monitor Type Combination Monitor Object
Monitor Type
call-object
call-type
Usage This combination is used to track an existing call, for as long as that call remains in the switching sub-domain. Monitor Stop service is sent by the switching function when the call ceases to exist in the switching sub-domain to indicate that the monitor is stopped and the associated Monitor Cross Reference Identifier is no longer valid.
call-object
device-type
This combination is used to track an existing call, while that call remains at the specified device. Monitor Stop service is sent by the switching function when the call leaves the device to indicate that the monitor is stopped and the associated Monitor Cross Reference Identifier is no longer valid.
- 67 -
Table 6-9 Monitor Object/Monitor Type Combination (concluded) Monitor Object
Monitor Type
device-object
call-type
Usage This combination is used to track all calls that arrive (or are present) at the device, for as long as the calls remain in the switching sub-domain. The specified device object can be thought of as a trigger device where all calls that become involved with this device become monitored as long as the call remains in the switching sub-domain. Monitor Stop service is not sent by the switching function when a call ceases to exist or moves away from the monitored device, since the monitor is still in place at the device.
device-object
device-type
This combination is used to track all calls that arrive (or are present) at the device, for as long as the calls remains at the device. Monitor Stop service is not sent by the switching function when a call ceases to exist or moves away from the monitored device, since the monitor is still in place at the device.
6.6.2.5
Monitoring in Relationship with Media Class The computing function can also indicate the media class (voice, digital data, etc.) of calls to be monitored when starting a monitor.
6.6.2.6
Refer to the media class component of 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete set of possible values. The media class is independent of the monitor object and monitor type. Reporting Connection State Changes Once a call is monitored (irrespective of monitor type or monitor object), all connection state changes that are known by the switching function for that call are reported to the computing function (subject to the Monitor Filter—refer to 6.6.2.7). For example, if device A is being monitored (with a device-type monitor) and a call is placed to device B (no monitor on B), then any connection state changes for either device A or B (such as when B answers the call) will be reported through device A’s monitor.
6.6.2.7
Monitoring is only guaranteed for devices in the switching sub-domain. Activity related to devices outside the switching sub-domain may be only partially available or completely unreported. Monitor Filtering The computing function can request that a set of events be filtered out (not sent) by the switching function. This information is specified in the monitorFilter parameter in the Monitor Start service request. The monitorFilter parameter contains a list of filters that are grouped together into the following categories: •
Call Control events
•
Call Associated events
•
Media Stream events
•
Physical Device Feature events
•
Logical Device Feature events
•
Maintenance events
•
Voice events
•
Private events
The switching function indicates the actual list of events that will be sent by returning the monitorFilter parameter in the positive acknowledgement to the Monitor Start and Change Monitor Filter services.
- 68 -
The computing function can request that the filtered list of events for an existing monitor be changed by issuing the Change Monitor Filter service.
6.6.3
Some categories of events are not provided for call-type monitors. The capability exchange services indicate the categories of events that are supported by the switching function for call-type monitors. Snapshot Services Snapshot services are used by the computing function to determine information about a call or a device. These services may be used at any time, independently of, or in combination with existing monitors. For example, a computing function may snapshot a device prior to starting a monitor on the device, in order to obtain information on existing calls at the device.
6.7
Additional Services, Features & Behaviour
6.7.1
This section specifies standardized switching function features affecting calls at a given device that do not have an explicit service request associated with the invocation of the feature. These features are usually configured within the switching function or have a service request which sets up certain conditions at a device that causes a particular behaviour with respect to calls at the device. As a result, these features are only reflected through an event sequence from the switching function. The following sections explain these features and the event sequences associated with them. Forwarding The forwarding feature is a trigger at a device that will redirect incoming calls to another device based on a specific condition. The following are the types of conditions that would trigger the redirection, or forwarding of the incoming call: 1. Immediate - This condition indicates that if a call arrives at a device, it is immediately redirected to another device. 2. Busy - This condition indicates that if a call arrives at a device, and the device is busy with another call, then the incoming call will be redirected to another device. 3. No Answer - This condition indicates that if a call arrives at a device, and the call is not answered within a certain number of rings or within a specific amount of time, then the incoming call will be redirected to another device. 4. Do Not Disturb (DND) - This condition indicates that if a call arrives at a device, and the device has the Do Not Disturb feature active at the device, then the incoming call will be redirected to another device. Note that the Do Not Disturb feature does not necessarily imply that incoming calls are forwarded. 5. Type of Call Origination - This condition indicates that if a call arrives at a device, and the originating device is a specific class (i.e., external, such as a device that is outside the switching sub-domain, or internal, such as a device that is within the switching sub-domain), then the incoming call will be redirected to another device. This condition can be used in combination with the others to create a compound condition. For example, if busy with another call and the calling device is outside the switching sub-domain, then redirect the call to another device. Switching functions may support one or both of the following levels of forwarding settings: •
switching function default settings
•
User specified settings
Switching function default settings are a single set of forwarding-type/forward-destination combinations that can be activated and deactivated as a set. The set includes all of the CSTA forwarding-types defined and the forward-destinations for each type. Activation, deactivation, or changes to the forwarddestinations are not normally possible by users.
- 69 -
User specified settings are individual forwarding-type/forward-destination combinations that can be activated or deactivated one at a time. User specified settings supersede switching function default settings during activation, deactivation, and when forwarding occurs. A switching function that supports switching function default settings may also support user specified settings. Switching function default settings are used for forwarding to a standard destination such as voice mail or an attendant. User specified settings may be used to override the default settings to forward calls temporarily to another office, for example. A user specified forwarding type supersedes the same switching function default forwarding type when forwarding occurs. For example, a user specified type of “No Answer” and its corresponding forward destination supersede a switching function default type of “No Answer”. Note that this rule may not apply to types that are not alike. For example, a user specified type of “No Answer” (a delayed type of forwarding) does not supersede a switching function default type of “Immediate”, although a user specified type of “Immediate” does supersede a switching function default type of “No Answer” (since “No Answer” is a delayed type of forwarding). The forwarding feature has service requests and events to control and observe the activation and deactivation of the forwarding triggers at the device (i.e., Get Forward, Set Forward, Forwarding). These service requests and events are documented in Clause 22, “Logical Device Features”, beginning on page 528, and do not actually forward the incoming call when it arrives at the device, but instead sets up the trigger to cause the switching function to perform the redirecting of the call. The computing function should use the capabilities exchange services to determine which of these services and events the switching function supports. The computing function should use the capabilities exchange services to determine which of the following levels of forwarding settings are supported by the switching function: •
Switching function default settings (set of forwarding types and forward destinations).
•
User specified settings. •
Default forwarding type.
•
Default forward destination.
Switching function default settings may be activated or deactivated manually at the device, or by providing neither the forwarding type nor forward destination (forward DN) in Set Forward service requests. User specified settings may be activated or deactivated manually at the device or by providing the forwarding type and/or the forward destination (forward DN) in the Set Forward service request. If the forwarding type is not specified and the forward destination is specified, the switching function uses a default forwarding type. Likewise, if the forwarding type is specified and the forward destination is not specified, the switching function uses a default forward destination. The computing function is informed that default settings are being activated in the Get Forward positive acknowledgement and the Forwarding event. When the call is immediately redirected as a result of the forwarding feature, there are two basic event sequence models to indicate that the call has been forwarded. The following are the event sequence model definitions (Note that the computing function should use the capabilities exchange services to determine which of model or models that the switching function supports.): 1. Forwarding Is Triggered before the Call Is Delivered to the Device - There is basically no event sequence associated with this condition. The only characteristic associated with this event sequence is: •
The first event associated with the delivery of the call to the new device will have an appropriate forwarding event cause. If the RedirectionDeviceID parameter is available in this event, it will be - 70 -
provided based upon the definition of the Call Control event and 12.3.24, “RedirectionDeviceID”, on page 154. Refer to 6.7.6, “Tracking a Diverted Call”, on page 75 for additional information on event sequences for forwarded calls. If the call is forwarded multiple times under the same condition (e.g., forwarded from device 1 to device 2 which is forwarded to device 3), then the information indicating that the call was forwarded will only be the information from the last device the call was forwarded from (e.g., device 2). As a result, the computing function will only see that the call has been forwarded one time. 2. Forwarding Is Triggered after the Call Is Delivered to the Device - The event sequence is a Diverted event followed by the first event associated with the delivery of the call to the new device. The characteristics associated with this event sequence are: •
Depending on the capabilities of the switching function, an Offered and/or Delivered event may or may not flow as a result of presenting the to-be-forwarded call to the device from which it will be diverted.
•
The Diverted event will have an appropriate forwarding event cause. (Note that he reporting of this event is dependent on the capabilities of the switching function.)
•
The first event associated with the delivery of the call to the new device will have an appropriate forwarding event cause. If the RedirectionDeviceID parameter is available in this event, it will be provided based upon the definition of the Call Control event and 12.3.24, “RedirectionDeviceID”, on page 154. Refer to 6.7.6, “Tracking a Diverted Call”, on page 75 for additional information on event sequences for forwarded calls.
If the call is forwarded multiple times under the same condition (e.g., forwarded from device 1 to device 2 which is forwarded to device 3), then the information indicating that the call was forwarded will be available each time the call is forwarded (e.g., device 1, device 2). This is possible because the call is actually delivered to the device before it is forward to another.
6.7.2
If the call is forwarded multiple times with a mixture of forwarding conditions (i.e., event sequence types), then the information indicating that the call was forwarded will be a mixture of the event sequences depending on the order of the forwarding conditions. Connection Failure The information indicating connection failure can be reported through several different event sequences. The computing function should use the capabilities exchange services to determine which of these services and events the switching function supports. The following are the possible event sequences associated with connection failure: 1. Negative Acknowledgement - When the switching function supports service requests that perform connection creation process and the switching function detects a failure, the negative acknowledgement can be used to indicate the failure to complete the connection. The following are the service requests associated with connection creation process: •
Consultation Call
•
Deflect Call
•
Dial Digits
•
Join Call
•
Make Call
•
Make Predictive Call
•
Pickup Call
•
Single Step Conference Call
- 71 -
•
Single Step Transfer Call
If the switching function uses the negative acknowledgement to indicate the connection failure, then the appropriate error code will be used to indicate the particular failure. 2. Support of the Failed Event with an Associated Failed Connection - When the switching function detects a connection failure, it places that connection into the failed state. This indicates that the call control services which can be performed with respect to the connection are limited. The following is the list of call control services that are applicable: •
Clear Call
•
Clear Connection
•
Call Back Call-Related
•
Call Back Message Call-Related
•
Camp On Call
•
Deflect Call
•
Intrude Call
When a connection enters the Failed state, the event sequence provided is a Failed event. The characteristics associated with this event sequence are: •
The Failed event will have an appropriate failure event cause.
•
The failedConnection parameter in the Failed event will contain a “complete” Connection Identifier (i.e., a Connection Identifier that has both a Device Identifier and Call Identifier)
•
The Failed event will be reported to all active device-type monitors associated with the call, as well as all call monitors associated with the call.
3. Support of the Failed Event without an Associated Failed Connection - This case is similar to the “Support of the Failed Event with an Associated Failed Connection” state (case 2). The difference is that when the switching function detects a connection failure, it does not create a connection for the failed device but instead indicates to the computing function that call control services, with respect to the connection, are limited. The following is the list of call control services that are applicable to the connection in the call under these conditions: •
Clear Call
•
Clear Connection
•
Call Back Call-Related
•
Call Back Message Call-Related
•
Camp On Call
•
Deflect Call
•
Intrude Call
When the failure is detected, the event sequence provided is a Failed event. The characteristics associated with this event sequence are: •
The Failed event will have an appropriate failure event cause.
•
The failedConnection parameter in the Failed event will contain a “Call ID only” Connection Identifier. This indicates that there is not a valid connection for the failed device in the call but that the appropriate call control service can be performed (i.e., Call Back Call-Related, Intrude Call, etc.). In the figures for the services and events, this “Call ID only” connection identifier is indicated via a dotted line (see Clause 11 for the template descriptions). - 72 -
•
The Failed event will only be reported to the active device and call monitors associated with the devices that where in the call prior to the failure (i.e., if a device-type monitor was on the failed device, then the event sequence is not reported).
If the Camp On Call or Intrude Call service request is performed, then the connection associated with the failed device will be created (i.e., a valid connection). 4. Support of the Failed Event with an Associated Failed Connection, not reported via monitors on the failing device - This case is similar to the “Support of the Failed Event with an Associated Failed Connection” state (case 2). The difference is for which monitors the Failed event is being sent: The Failed event will only be reported to the active device and call monitors associated with the devices that were in the call prior to the failure (i.e. if a device-type monitor was on the failed device, then the event sequence is not reported). Apart from this, all aspects from case 2 apply also to this case. 6.7.3
Recall The Recall feature is a trigger that is associated with a call after a specific call control feature has been executed. When this feature is executed, it redirects or presents the call either back to the device on who’s behalf the call control feature was executed or to a switching function administrated destination associated with the specific call control feature. There are several types of call control services which can have this feature associated with them. For example: •
Hold Call
•
Transfer Call
•
Single Step Transfer Call
•
Deflect Call
•
Park Call
The event sequence associated with this feature is the Diverted event (only if the device to whom the call is being redirected is not already in the call) and the first event associated with the delivery of the call to the new device or the device that performed the call control feature. The characteristics for this event sequence are:
6.7.4
•
The Diverted event will have an appropriate recall event cause. This event is only reported when the device to whom the call is being redirected is not already in the call (i.e., a recall to a connection that is already in the call). (Note that the reporting of this event is dependent on the capabilities of the switching function.)
•
The first event associated with the delivery of the call to the new device (i.e. Delivered), or the device that performed the call control feature will have an appropriate recall event cause (in either the Delivered, Held, Queued, etc.). If the lastRedirectionDevice parameter is available in this event, and the call was actually redirected to another device outside the current call, then it will be provided based upon the definition for this parameter. (Refer to the definition of the Call Control events and lastRedirectionDevice parameter for more details.) If the callingDevice parameter is available in this event, it may contain the same callingDevice information prior to the recall. This means that if the calling device is the Subject Device of the event, then the information in the callingDevice and corresponding SubjectDeviceID (e.g., Delivered event SubjectDeviceID = alertingDevice) parameters may be the same. If the switching function does not retain this information with the call, then the callingDevice parameter will contain a value of “Not Known”.
Call Back The Call Back feature is a trigger which is set up within the switching function. The trigger is used to initiate a call between a particular pair of devices. The pair of devices is comprised of a calling device (i.e., the device on who’s behalf the trigger is setup) and the called device (i.e., the device whom the calling device wants to initiate a call to when certain conditions associated with the called device are met). - 73 -
The type of conditions associated with the trigger is switching function specific. A common type of condition is the called device is no longer actively involved in a call(s). The trigger is activated for the calling device by either the Call Back Call-Related or Call Back Non-Call-Related services. The trigger is deactivated by one of the following: successful execution of the trigger, the Cancel Call Back service, or a switching function specific timeout period. Once the trigger is activated, the switching function waits for the particular condition associated with the Call Back feature to be met. Once met, the switching function initiates a call on behalf of the calling device to the called device. This is done by first prompting the calling device (if supported by the device) and then initiating the call to the called device.
6.7.5
The event sequence associated with execution of the Call Back trigger is the Service Initiated event (only if the calling device is prompted), Originated event and the events associated with the called device’s involvement in the call. The characteristic for this event sequence is that both the Service Initiated (if supported) and Originated events will have an event cause of Call Back. External Calls A call is considered to be external when there is at least one device in the call that is outside the switching sub-domain. For more details on how the switching function represents these devices within the switching sub-domain, refer to 6.1.1.4.2, “Network Interface Device Category”, on page 24. The activities associated with external calls are broken down into two categories: •
Incoming Calls - A call is being initiated from a device outside the switching sub-domain.
•
Outgoing Calls - A device inside the switching sub-domain is adding or initiating a call to a device outside the switching sub-domain.
These categories are represented by different event sequences. The characteristics associated with these event sequences are: •
•
Incoming Calls •
A Service Initiated event is generated for the network interface device when the network interface device is allocated (e.g., seized) for the external incoming call. The initiatingDevice parameter will contain the information on which network interface device is being used for the call. Note that this event is only generated if the network interface device is monitored.
•
The Digits Dialled event is generated for the network interface device when a portion of the dialling sequence has been received over the network interface device. Note that this event is only generated if the network interface device is monitored.
•
The Originated event is generated for the network interface device when the external incoming call has originated from the network interface device. The NIDDevice parameter will contain the information on which network interface device is being used for the call. Note that this event is only generated if the network interface device is monitored.
•
In all subsequent events (independent of whether or not the network interface device is observable), this incoming call is distinguished from an internal incoming call by the presences of the associatedCallingDevice (i.e., containing either a Device Identifier or a value of “Not Known”). The information in the associatedCallingDevice parameter is first associated with the call when it enters the switching sub-domain (i.e., Service Initiated or Originated events) and will be present until the calling device leaves the call.
Outgoing Calls •
When initiating a connection to a device outside the switching sub-domain and the switching function is associating the Network Interface Device with the outside device, a Network Reached event is reported. In addition, the Network Reached event is the first event that indicates the call is an external outgoing call. Subsequent events (if available) will contain the associatedCalledDevice parameter (i.e., the value from the networkInterfaceUsed parameter of
- 74 -
the Network Reached event) and will be present until the call is cleared. In addition, until the Network Reached event is generated, the call is consider to be an internal call. •
6.7.6
The event sequence after the Network Reached event that is associated with the device outside the switching sub-domain may be limited but the events that are reported will contain one of the event causes documented in the event definition. If the Network Reached event contained the networkCapability parameter, future Network Capabilities Changed events may be provided indicating a change in the signalling capability of the network and ultimately the types of events that can be provided.
Tracking a Diverted Call When observing a call or a device in a call, and the call diverts from a device in the call, the computing function shall use the Diverted event to track the progress of the call as a result of the redirection.
6.7.7
If the switching function does not provide the Diverted event for all devices in a call or for call-type monitors (as indicated through the capabilities exchange services), the computing function shall use parameters in the first event after the call has been diverted to properly track the progress of the call as a result of the redirection. The device identifiers are used to observe the movement of the call and the event cause is provided to indicate what caused the movement of the call. (Note that the call may have been diverted several times between the previous event (if one was generated) and the first event after the diversion. As a result, the computing function can only ascertain that either one or two redirections have occurred.) Media Stream Access The capability to control the information content within a call is called media stream access, or simply, media access. Media access is provided to a computing function through a media service. Common media service capabilities are play/record of voice and audio, automatic speech recognition, text to speech, fax, and data services.
6.7.7.1
Some of these capabilities can alternatively be provided as voice features defined in 6.1.1.4.7 through 6.1.1.4.13. Media Attachment Services
6.7.7.2
A computing function making use of both call control services and media services needs to establish sessions with both services, attach calls to the media service, and needs a way of associating the identifiers (e.g., Connection Identifiers, Media Stream Identifiers) used by the two services. This Standard defines a set of services, called media attachment services, that make these tasks significantly easier for the computing function. Media Service Type A particular media service, which is defined by its set of services and possibly its access methods (APIs, protocols, etc.) is identified for the purpose of the media attachment services by a unique media service type identifier. The mediaServiceType parameter is used to indicate which media service is to be (or has been) attached to or detached from a particular call or connection that the computing function is controlling and/or monitoring. In some instances, the media service version may also be provided, such that different versions of the media service can be identified by unique media service types. Table 6-10 identifies and describes the set of media service types defined by this Standard: Table 6-10 Media Service Types Media Service Type
Media Stream ID Representation
CSTA Voice Unit
Refers to the connection identifier in the sub-domain.
Data Modem
Refers to the address that is to be used to access the modem control and data stream.
Digital Data— Isochronous/IEEE 1394
Refers to the IEEE 1394 channel that is being used.
- 75 -
Table 6-10 Media Service Types (concluded) Media Service Type
Media Stream ID Representation
Digital Data—Isochronous/ GeoPort
Refers to the GeoPort stream that is being used.
Digital Data— Isochronous/ATM
Refers to the ATM virtual channel/path identifier that is being used.
Digital Data— Isochronous/ISDN
Refers to the ISDN bearer channel that is being used.
Digital Data—API
Refers to the particular API’s digital data stream reference ID (e.g., Microsoft’s Winsock is socket identifier) to indicate which digital data stream is to be used.
ECTF S.100 Media Services Default
Refers to the ECTF S.100 Media Services CCR Resource ID (CCR ECTF ResourceID) to indicate which media stream channel to be used.
ECTF S.100 Media Services Application Service
Refers to the ECTF S.100 Media Services Application Service.
IVRScript1 through IVRScript10
Not defined; the attachment of the media stream channel to the vendor media server instance is vendor-specific.
Live Sound Capture—Analog
Refers to the analog jack that is being used.
Live Sound Transmit—Analog
Refers to the analog jack that is being used.
Live Sound Capture—IEEE 1394
Refers to the IEEE 1394 channel that is being used.
Live Sound Transmit—IEEE 1394
Refers to the IEEE 1394 channel that is being used.
Live Sound Capture and Transmit—GeoPort:
Refers to the GeoPort stream that is being used.
Live Sound Capture and Transmit—ATM
Refers to the ATM virtual channel that is being used.
Live Sound Capture and Transmit—ISDN
Refers to the ISDN bearer channel that is being used.
Sound Capture and Transmit— API
Refers to the particular API’s sound stream reference ID (e.g., Microsoft’s MCI’s is MCI Device handle) to indicate which sound stream is to be used.
Sound Capture and Transmit— Rockwell ADPCM Packet
Refers to the address that is to be used to access the asynchronous stream.
Universal Serial Bus (USB)
Refers to the USB endpoint.
sfSpecific1 through sfSpecific10
Not defined; the attachment of the media stream channel to the vendor media server instance is vendor-specific.
6.7.7.3
Media Service Instance
6.7.7.4
A specific set of resources and/or functions that provide a particular media service (as identified by the media service type) are referred to as a media service instance. For example, a media service instance may be a specific media server, subsystem, or software that provides the given service. When the computing function attaches a call to a media service, it may request a particular instance of the service through the media service instance identifier. A media service instance may have associated with it zero or more media access devices that provide a means of physical connection between switching subdomain resources and media service resources. Media Access Device A media access device is a device within the switching sub-domain used in establishing and modeling the physical connection of the media stream between switching sub-domain resources (i.e., devices in a call) and media service resources (i.e., media processing resources such as tone generators/detectors, speech recognition devices, text-to-speech converters, modems, etc.). During media service instance attachment, a media access device may be conferenced into a call, or the call may be transferred to the media access device from another device. During media detachment, the media access device is cleared from the call.
- 76 -
6.7.7.5
Media Stream ID The media services that can be the target of the media attachment services are unlimited. That is, very little is assumed about the operational model of the media services themselves. The only requirement is that the media service defines some identifier, referred to here as the media stream identifier (i.e., mediaStreamID), that can be used by the computing function to reference the media stream associated with a connection. The mediaStreamID is returned, if supported, as a parameter in the Media Attached event. The capability exchange services are used to determine if the switching function supports returning the mediaStreamID.
6.7.7.6
The format and meaning of the mediaStreamID is media service and implementation dependent, and is not defined here. The switching function only guarantees the mediaStreamID to be valid while the media service instance remains bound to the call. Once the media service instance is detached from the call, the validity of the mediaStreamID is media service dependent. Service Operation The media attachment services defined in this Standard consist of two services: Attach Media Service and Detach Media Service, and two events: Media Service Attached and Media Service Detached. A description of these services and events and their usage follows. For more information see Clause 19, “Media Attachment Services & Events”, beginning on page 446. A typical media enabled computing function will establish or accept a call, perform some media access functions associated with the call, and then clear the call. The first and third steps clearly require the call control services only, while the second involves coordination of both call control and media services. This second step can be further sub-divided into the following tasks: 1. A particular instance of the media service (e.g., specific media server or media subsystem providing the desired services) shall be chosen, either by the computing function or by the switching function on behalf of the computing function. 2. The computing function shall establish a session with the selected media service instance. The method of the session establishment is media service dependent (e.g., initialize with the media service API, send a message to the media service, establish a CSTA association with a SRF). 3. If the switching function supports returning a mediaStreamID to the computing function, an association between the switching function and the media service instance must be established. The way this association is realized is implementation dependent. The switching function and the media service instance require a means to attach the media stream channel of a connection to a media stream channel of the media service instance. This is referred to as a connection mode. Connection modes are enumerated in the specification of Media Attachment services. They fall into two categories: a. Explicit representation by adding a media access device into the call via a call control service (e.g. Conference Call, Transfer Call, Deflect Call, Directed Pickup Call). The media service instance is bound to the new connection. In general, the media access device behaves the same as any other call control device, although the services that can be applied to the device or a connection associated with the device may be restricted by some implementations. Connection modes in this category best suit, but are not limited to, configurations where call control resources and media resources consist of distinct, non-integrated hardware components. An example of such a configuration is one in which the switching resources reside in a PBX and the media service resources reside in a VRU. b. Implicit representation by an existing connection in the call (referred to as the direct connectionMode). A media access device is not added to the call. Instead, the media access device is already attached to an existing connection in the call. Connection modes in this category best suit, but are not limited to, configurations where call control resources and media resources consist of common or tightly integrated hardware components. An example of such a - 77 -
configuration is one in which the switching and media service resources are provided by an integrated telephony and media processing board in a PC. Another example of such a configuration is one in which an external voice response unit makes an outbound call to a media access device in a switching sub-domain, thus attaching its media services to the device's connection. 4. The associated mediaStreamID assigned by the media service instance may be returned by the switching function to the computing function. 5. The computing function can access the media service instance using the supplied mediaStreamID. At this point, the computing function may mix the use of call control services and services provided by the media service instance as needed. 6. When the computing function has finished its use of the media services, it shall unbind the media service instance from the call. The unbinding of the media service instance consists of releasing the attachment established in step 3, and, if applicable, removing the associated media access device from the call. As far as the switching function is concerned, the returned mediaStreamID is also invalidated once the media service instance is detached from the call. 7. The computing function may or may not close its session with the media service instance. The switching function may or may not release its association with the media service instance. Several of these tasks are handled on behalf of the computing function through the use of the Media Attachment Services. Steps 1, 3, and 4 are provided by the Attach Media Service, and step 6 is provided by the Detach Media service. The Attach Media Service attaches an existing call to a media service instance. The Attach Media Service service request provides a mediaServiceInstanceID parameter that selects a particular media service instance associated with the switching function when multiple choices exist. If the switching function has multiple choices and the parameter is not supplied, then the switching function shall select which media service instance is to be used. The Attach Media Service, depending upon the connectionMode parameter supplied in the service request, initiates a connection to an available media access device associated with the service instance (for the explicit connection category). At the completion of a successful service invocation a Media Attached event is reported on monitors associated with the specified call or device in addition to any other events that flow as a result of making the media access device connection. The Media Attached event may contain the associated mediaStreamID for accessing the media service instance. The Attach Media Service service positive acknowledgement and Media Attached event may be correlated using the CSTA Connection and Device Identifiers associated with the chosen media access device or existing connection that was bound in the call. A Media Attached event may flow any time a connection is bound to a media service instance, even if the binding was not the result of an Attach Media Service service request. This provides for automatic attachment and media service type determination by the switching function (e.g., situation where calls are automatically directed to a media access device by the switching function or automatically bound to an existing connection when a call arrives). When the computing function receives this event, it may open a session with the associated media service instance and immediately begin accessing the media service instance using the mediaStreamID provided in the event. The session establishment with the media service and mediaStreamID usage are media service dependent and outside the scope of this Standard. The Detach Media Service service request undoes the actions of Attach Media Service service. It unbinds the media service instance from the specified call or connection and breaks the physical connection of the media stream between the switching sub-domain and media service instance. Any associated media access device involvement in the call is also cleared. The connection to the device is cleared and reported through normal call control events (i.e., Connection Cleared events). A Media Detached event report is used to indicate that media service instances have been detached from a call or connection. The - 78 -
6.7.7.7
switching function itself may initiate a media detachment. In this case, the detachment is reported using the same events as if the computing function had initiated the Detach Media Service service request (e.g., Media Detached and possibly Connection Cleared events). Related Services A number of other call control services return information related to the media access capability. The Snapshot Call service returns a list of media service types, media service versions, media service instance IDs, and media stream IDs associated with each connection in a call. The Get Switching Function Capabilities service returns, for the entire switching function, a list of supported media service types, media service versions, media service instance IDs, and whether or not the media stream ID is supported for this combination of media attributes, as well as the supported connection modes for each combination.
6.7.8
Finally, the Get Logical Device Information service returns, for a selected device, a list of supported media service types, media service versions, media service instance IDs, and whether or not the media stream ID is supported for this combination of media attributes, as well as the supported connection modes for each combination. Routeing Services A switching function uses Routeing services when it needs the computing function to supply call destinations. This may be on a call-by-call basis or it may be non-call related. The computing function can use internal databases together with call information to determine a destination, or route, for each call. For example, the computing function might use the caller's number and information in a database to route incoming calls. A switching function may support Routeing services for any type of call (e.g., external outgoing, external incoming, intra-switching sub-domain). Routeing services may require that the switching function be configured to direct calls to a device known as a routeing device. This device shall be addressable (i.e., visible within the switching sub-domain) with respect to Routeing services but may or may not be addressable with respect to other services (e.g., Call Control, Monitoring). The routeing device may be a virtual device used only for routeing and thus may not be monitorable. The way a particular virtual routeing type device is used by a switching sub-domain is specific to each implementation. Examples include: •
a routeing device could be used to route all outgoing external calls from all devices within a given switching sub-domain
•
a routeing device could be used to route all incoming external calls independent of the network interface device being used
•
a routeing device could be used to route all calls that are considered to be priority calls independent of their origin.
A switching function implementation will implement as many routeing devices as it requires in order to reflect the different routeing processes it supports.
- 79 -
Figure 6-32 Overview of a Routeing Dialogue
Routeing services are used within a sequential “routeing dialogue” such as that represented in Figure 632. (Note that none of the routeing services return positive acknowledgements. Negative acknowledgements, though provided by routeing services when applicable, are not shown in the figure.) A routeing dialogue is typically initiated by the switching function when a call is directed to a device and particular conditions are met for that call at that device. The conditions at a device under which the switching function may initiate a routeing dialogue are determined by its Route Mode and the Route Registration Service. Through these mechanisms the computing function may specify to the switching function that when calls encounter a particular device, the computing function should be consulted for a proposed route. Routeing services are linked within a routeing dialogue by the routeing cross reference identifier (routeingCrossRefID). A routeing cross reference identifier is provided by the Switching function as part of the Route Request Service used to initiate a routeing dialogue. This routeing cross reference identifier is quoted by each subsequent invocation of a routeing service in the routeing dialogue. 6.7.8.1
Route Requests generated by the switching function may be call-related or non-call related. Route Registration and Route Mode Table 6-11 below specifies the conditions that must be satisfied before a given switching function initiates a routeing dialogue for a given routeing device by generating a Route Request. The switching function’s behaviour is governed by its support for the routeing registration services and support for the Route Mode attribute. Registration has no affect on routeMode, and enabling/disabling routeMode has no affect on registration. In order to use routeing services for a given routeing device, a computing function must satisfy the conditions specified in Table 6-11 by invoking the appropriate services. Table 6-11 Routeing Behaviour Registration Not Supported Route Mode Supported
Registration Supported
• Registration not required
• Registration required
• RouteMode must be enabled
• RouteMode must be enabled
• Switching Function must initiate routeing dialogue if a call of any media class arrives
• Switching Function must initiate routeing dialogue if a call of any media class arrives that matches the media class requested
- 80 -
Table 6-11 Routeing Behaviour (concluded) Registration Not Supported Route Mode Not Supported
Registration Supported
• RouteMode implicitly enabled
• RouteMode implicitly enabled
• Registration not required
• Registration required (specific or all)
• Switching Function may initiate routeing dialogue at its discretion
• Switching Function must initiate routeing dialogue if a call arrives that matches the media class requested
The positive acknowledgement to the Route Register service contains the route register request identifier (routeRegisterReqID) that the computing function uses to identify service requests that arrive for this registration. If the switching function supports the Route Registration services, then the computing function shall use these services to register as a routeing server before it can route calls. If the switching function does not support the Route Registration services, then the computing function may receive route service requests for any routeing device at any time. The computing function may either register as the routeing server for a specific routeing device or, if supported by the switching function, as a routeing server for all routeing devices within the switching subdomain. A route registration can be cancelled using the Route Register Cancel service. Once this service is positively acknowledged, the switching function will no longer send route service requests to the computing function. Additionally, the switching function can cancel a route registration at any time by sending the computing function a Route Register Abort service request. Routeing services for a particular device may be suspended without cancelling route registration by disabling its Route Mode. This does not effect route registration and route requests for the given device will resume when its Route Mode is enabled.
6.7.8.2
The capabilities exchange services can be used to determine if the switching function supports the Route Registration services and if so, if the capability to register for all routeing devices is supported. The capabilities exchange services can also be used to determine if the switching function supports the Route Mode attribute. Call Routeing An example of a routeing process may involve the following sequence of steps: 1. The switching function receives a call at the routeing device. The routeing device may be any device within the switching sub-domain. 2. When the call arrives at the routeing device, the switching function creates a routeing dialogue for the call. The switching function allocates a routeing cross reference identifier (routeingCrossRefID) that references this routeing dialogue. 3. The switching function sends the Route Request service to the computing function (that registered as the routeing server) for the routeing device or as the routeing server for all routeing devices within the switching sub-domain. This service request contains the routeing cross reference identifier, the route registration request identifier (if supported), and call information such as the Connection Identifier for the call, and calling and called numbers. 4. The computing function decides whether to reject the Routeing service request for this call, provide a route for the call, or end the routeing dialogue. If the computing function decides to reject the call, it sends the switching function a Route Reject service request. If the computing function decides to provide a route for the call, it sends the switching function a Route Select service request containing the destination for the call. The computing function may include an optional flag in the Route Select service request (i.e., routeUsed) instructing the switching function to inform it of the call’s final destination. The final destination may be different than the computing function-provided destination - 81 -
when switching function features such as call forwarding redirect the call. If the computing function decides to end the routeing dialogue, it sends the switching function a Route End service request. In this case, the computing function does not provide a destination for the call and the switching function uses an alternate mechanism (not defined) to route the call. 5. If the switching function receives a Route Reject service request, then it returns the call to the network for alternate routeing, and sends the computing function a Route End service request to indicate that the routeing dialogue is ended. If the switching function receives a Route Select service request, it attempts to route the call to the computing function-provided destination. If the destination is valid, the switching function routes the call to that destination and sends the computing function a Route End service request to terminate the routeing dialogue. If the computing function-provided destination is not valid (e.g., invalid directory number, destination busy), then the switching function may send a Re-Route service request to the computing function to request a route to an alternate destination. If the switching function receives a Route End service request, it terminates the routeing dialogue. 6. If the computing function receives a Re-Route service request it can select a different destination for the call and send the switching function another Route Select service request. Depending on the switching function implementation, the re-routeing service request exchange can repeat until the computing function provides an acceptable route. The computing function will find out about a successful route when the switching function sends a Route End service request or if the computing function included the routeUsed flag in its last Route Select service request. Either the switching function or the computing function may send a Route End service request at any time to end the routeing process and terminate the routeing dialogue. This releases the routeing cross reference identifier for use in the future. This service request indicates, for example, that the computing function does not want to route the call, or the switching function (usually in the absence of a Route Select service request) routed the call using some default mechanism within the switching function. Note that a conflict may arise in this dialogue if the computing function invokes the Route End Service, for example to indicate that no more alternative routes are available, but still wants to receive a route used report via the Route Used Service invoked by the switching function. Avoidance or resolution of this conflict is the responsibility of the computing and/or switching function implementation(s). A call that is not successfully routed does not necessarily mean that the call is cleared or not answered. Most switching function implementations will have a default mechanism for handling a call at a routeing device when the computing function has failed to provide an acceptable destination for the call. The switching function shall send a Route End service request to the computing function when it terminates the routeing dialogue, unless the routeing dialogue was terminated by a Route End service request from the computing function first. The minimum set of services a switching function shall provide if it supports routeing are: Route Request, Route Select, and Route End (from the switching function). Other routeing services may be provided in any combination in addition to this minimum set. Figure 6-33 illustrates the typical Routeing procedure.
- 82 -
Figure 6-33 Routeing Procedure
Switching Domain
Computing Domain (Routing Server)
(1) A call arrives at the routing device Call related information is passed (routingCrossRefID is created) and a Route Request service request is (1) issued.
(2a)
(3a) If (2a) then the switching domain ends the routing dialogue and issues a Route End request. (3b) If (2b) and the destination is valid, then aRoute End service request is issued. (3c) If (2b) the destination is invalid, then aRe-Route request is issued. (3d) If (2c), the routing dialogue is ended and no more requests are sent for this routing dialogue.
or
(2b)
or (2c) (3a)
or (3b)
or (3c)
(5) The switching domain again attempts to route the call to the (newly) specified destination. (5a) If the destination is valid, then a Route Used service request and a Route End service request are issued. (5b) If the destination is invalid, then a Re-Route service request is issued.
6.7.8.3
(2) The computing domain chooses to reject the call, route the call, or end the routing dialogue: (2a) If the computing domain decides to reject the call, it issuesReject a Call service request. (2b) If the computing domain decides to route the call, it selects a destination for the call (based on the call and other Select information), and issues Route a service request. (2c) If the computing domain decides to end the routing dialogue, it issuesRoute a End service request.
(4b)
(4a) If (3a) or (3b) then the routingCrossRefID is released and call i rejected or route is completed using the destination provided in (2b). (4b) If (3c) then a secondRoute Select request with a different destination is issued (routeUsed = TRUE).
(5a)
or (5b)
(6a) If (5a) then routingCrossRefID is released and route is completed as specified in (4b). (6b) If (5b) then a third Route Select with a different destination is issued.
Route Register Request ID and the Routeing Cross Reference ID The routeing services use two identifiers to refer to different software objects in the switching sub-domain. The route register request identifier (routeRegisterReqID) identifies a routeing registration for which the computing function (acting as a routeing server) will receive Routeing service requests. This identifier may be associated with a particular routeing device within the switching sub-domain or it may indicate that the computing function is the routeing server for all routeing devices within the switching sub-domain. When the computing function uses the Route Register service to register for routeing services, it receives a routeRegisterReqID in the positive acknowledgement from the switching function. The routeRegisterReqID is only valid until the routeing registration is ended by the computing function or switching function. Within a routeing registration (routeRegisterReqID) the switching function may initiate many routeing dialogues (shown in Figure 6-33) to route multiple calls. A switching function uses a routeing cross reference identifier (routeingCrossRefID) to refer to each routeing dialogue. The computing function receives a routeingCrossRefID in each Route Request service request. The Route Request service initiates a routeing dialogue. The routeingCrossRefID is only valid for the duration of the routeing dialogue pertaining to a specific call. The routeing cross reference identifier (routeingCrossRefID) is unique within the routeing registration (routeRegisterReqID). Some switching functions may provide the additional benefit of a unique routeing cross reference identifier across the entire switching sub-domain. This is also the case if routeing registration is not supported by the switching function. Routeing registration identifiers (routeRegisterReqIDs) are unique across a given CSTA service boundary.
- 83 -
6.7.8.4
Monitoring of Routeing Device
6.7.8.5
Some switching function implementations may support monitoring of routeing devices. For those computing functions that have an active monitor on the routeing device, any activity at the device (for instance call control activity) shall generate the relevant event sequence as specified throughout this specification. Routeing Services with respect to Media Class A routeing device can support the routeing of calls of any combination of media class (i.e., voice or digital data or both). Refer to the media class component of 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete set of possible values.
6.7.9
Once the routeing dialogue is visible to the computing function through the Route Request service, the media characteristics of the call will be identified and associated with the routeing cross reference identifier. Device Maintenance
6.7.10
Device Maintenance events indicate changes in the maintenance state of a device. These events indicate if a device has been taken out of service (can no longer accept calls or be manipulated by the computing function), is partially in service, or if a device has been placed back in service. Prompting Some CSTA services (Make Call, Call Back, Pickup, Join Call, for example) may require to prompt the user of the targeted device in order to take that device off-hook. The implementation of a prompting mechanism is switching function specific (display flashing, ring pattern, lamp blinking, etc.). For CSTA services that specify prompting (except the Make Call service), the switching function shall support (as indicated by the capability exchange services) one of the two possible prompting modes:
6.7.11
•
prompting is a pre-condition to a service - in this mode prompting occurs before the execution of the CSTA service. The Service Initiated event that indicates prompting shall flow before any other service specific events and shall contain connection identifier that is not associated with the CSTA service. After the device goes offhook, a Connection Cleared event associated with the prompt is generated and the CSTA service that initiated the prompt is executed.
•
prompting is part of a service - in this mode, prompting is part of the execution of the service. The Service Initiated event that indicates prompting is part of the completion criteria for the service and the connection identifier used in the Service Initiated event is associated with the CSTA service.
For information on event sequences with respect to prompting in the context of specific services, refer to the Monitoring Event Sequences associated with a CSTA service. Telephony Tones Features There are several features that support the generation and detection of telephony tones. The Generate Telephony Tones service (18.1.5, “Generate Telephony Tones”, on page 428) generates a specified tone for a connection in a call. While a telephony tone is being generated, it may be canceled via the Cancel Telephony Tones service (18.1.2, “Cancel Telephony Tones”, on page 420). The Telephony Tones Generated event (18.2.4, “Telephony Tones Generated”, on page 440) is used to monitor for telephony tones that are generated by a device (e.g., via the Generate Telephony Tones service).
6.7.12
The Data Collection services (Clause 25, “Data Collection Services”) are used to report telephony tones that are received over a connection at a device. DTMF and Rotary Pulse Digits Features Several services such as Make Call and Consultation Call provide a parameter for addressing a device while a call is being created. Also, for calls that are already created, the Dial Digits service provides address information to select a destination device or to complete a multi-stage dialling sequence. Depending upon the switching function implementation and the type of network, these parameters may - 84 -
be translated into DTMF or rotary pulse digit information used by the network to select a destination device. This addressing information shall not be used for end-to-end purposes. Other services, as defined below, are used for generating and detecting end-to-end information that is to be sent to a device (i.e., not to address/select a device). The Generate Digits service (18.1.4, “Generate Digits”, on page 425) is used to generate DTMF or rotary pulse digit information for a connection in a call. The Digits Generated event (18.2.3, “Digits Generated”, on page 438) is used to monitor for DTMF or rotary pulse digits that are generated by a device, either manually or via the Generate Digits service.
6.7.13
The Data Collection services (Clause 25, “Data Collection Services”) are be used to report DTMF or rotary pulse digits that are received over a connection at a device. Data Collection Services The Data Collection services are used to collect information such as DTMF/rotary pulse digits and Telephony Tones that is received by a device over a connection. The Start Data Collection service is used by the computing function to initiate the data collection. The service specifies if data should be collected for a specific connection or for the next connection at a device. The Stop Data Collection service is used to stop the data collection. Data collection is also stopped if the connection over which data is being collected is cleared. Information that is collected as part of the data collection is reported to the computing function via the Data Collected service. The data collection may be suspended and resumed via the Suspend Data Collection and the Resume Data Collection services. The Data Collection Suspended and the Data Collection Resumed services notify the computing function if the data collection has been suspended or resumed. The Data Collection services are specified in Clause 25, “Data Collection Services”.
6.8
Location Features The CSTA Location features enable a computing function to determine the location and track the movement of location-enabled CSTA devices such as fixed/mobile phones, group devices, or users. A CSTA computing function utilizes the CSTA Location features and a CSTA switching function implements them. A computing function can set location information using CSTA services (see 6.8.5). The switching function can also use other mechanisms to derive location information via network/device signalling, embedded devices with location-enabled features, by inference based upon IP address, or by interfacing to dedicated Location Servers, etc. A computing function can also obtain location information using CSTA services by: 1. Polling the device for location information (see 6.8.2). 2. Monitoring a device and observe location information associated with calls at the monitored device (see 6.8.3). 3. Creating a location tracking session to observe the location information associated with the device (see 6.8.4)
6.8.1
Location Information Geographical location information describes a physical position in the world that corresponds to the location of an object such as a CSTA device.
- 85 -
A CSTA device (see 6.1.1.4 on page 24) can be used to represent devices that are associated with location information like a fixed-position device such as a wired phone, a mobile device such as a cell phone, a group device consisting of member devices, a user, etc.
6.8.1.1
A CSTA deviceID (see 10.1 on page 102) is used to represent a CSTA device in location services. Examples of a deviceID is a Directory Number or a URI. Formats of Location Information There are two formats of location information used in CSTA: 1. Civic Address - specifies location information in a format suitable for human use. This includes information such as country, street, building, floor, etc. 2. Geospatial Coordinates - specifies location information based upon a coordinate system. This includes information such as longitude, latitude, altitude, etc. The Civic Address format uses the Civic Address types defined in the Civic Address Types Registry defined in IETF RFC-4776 (http://www.iana.org/assignments/civic-address-types-registry).
6.8.1.2
The Geospatial Coordinate format uses the feature.xsd schema profile specified in Annex C of ISO19136:2007 Geographic Information - Geography Markup Language (GML) (http://www.iso.org/ittf/ ISO_19136_Schemas/feature.xsd). Structure of Location Information The CSTA LocationInfo parameter type contains a PIDF-LO (Presence Information Data Format Location Object) for carrying location information as defined in IETF RFC-4119 as updated by IETF RFC5139. Location information in a PIDF-LO is contained in a GEOPRIV element. The GEOPRIV element consists of the following elements: •
location-info - consisting of one or more chunks - each chunk can be either in GML format or civic address format as discussed in 6.8.1.1. Note that when two chunks are provided in a location-info element that corresponds to the same place, this is referred to as a compound location.
•
usage-rules - associated with the location info (retransmissions-allowed, retention-expires, rulesetreference)
•
method - how location info was derived or discovered (e.g. GPS)
•
provided-by - source of the location info to provide additional information to locate service providers in case of problems with the location info.
A GEOPRIV element can be associated with a person or a device (or a generic tuple) using the data model in RFC-4479. There can be multiple GEOPRIV elements in a single PIDF-LO. For example: •
For a CSTA user with 2 devices, location information in a single PIFDF-LO may be in three GEOPRIV elements: one contained in a person element, one contained in a device element (for a cell phone), and one contained in another device element (for an office phone).
•
For a CSTA device such as an office phone, location information may be in a single GEOPRIV element contained in device element. The GEOPRIV location-info element contains two chunks of location information - one that specifies a location using Geospatial format and one that contains an office number as a civic address type that augments the Geospatial information.
•
For a CSTA group-device consisting of 3 member devices, location information may be in three GEOPRIV elements each contained in separate device elements.
See 12.2.18, “LocationInfo”, on page 137 for a complete description of the CSTA LocationInfo parameter type. - 86 -
6.8.2
Polling for Location Information The computing function can obtain location information associated with a device via the “Get Location Information” service. This service can be used to obtain location information whether or not the device is involved with a call. The “Snapshot Call” service can also be used to obtain location information associated with devices in a call.
6.8.3
In order to reduce the need to continually poll for location information a location tracking session (see 6.8.4) can be used. Location Information in Call Control Events A switching function can provide location information associated with devices in a call. For example a CSTA Delivered event provides location information associated with a callingDevice.
6.8.4
Refer to the locationInfo parameter in Call Control events in Clause 17.2. Location Tracking Session A location tracking session can be used to facilitate the continuous reporting of location information. Location tracking session services operate within the context of a location tracking session. A location tracking session provides a context in which to control and report location information. The following is a list of the location tracking session services that are used to create and manage a location tracking session:
6.8.4.1
•
“Start Location Tracking Session” service creates a location tracking session
•
“Stop Location Tracking Session” service ends a location tracking session
•
“Suspend Location Tracking Session” service suspends a location tracking session
•
“Resume Location Tracking Session” service resumes a suspended location tracking session
•
“Location Tracking Session Suspended” service indicates when a location tracking session has been suspended
•
“Location Tracking Session Resumed” service indicates when a location tracking session has been resumed
The following sections provide an overview of the location tracking session services. The services are specified in Clause 28, “Location Services”. Starting a Location Tracking Session The Start Location Tracking Session service is used by the computing function to create a location tracking session. A parameter is returned by the switching function in the positive acknowledgement that is used to identify the location tracking session in subsequent services. The Start Location Tracking Session service specifies the following: 1. The criteria for collecting location information. In order to control the rate in which location information is collected, this service specifies a set of collection criteria that specifies how the switching function should collect location information. For example the Start Location Tracking Session service may specify that location information should be collected every minute. 2. The criteria for the reporting location information. In order to reduce the frequency of CSTA Location Information Report(s) services, this service specifies a set of reporting criteria that specifies how the switching function should buffer collected location information before sending it to the computing function. For example the Start Location Tracking Session service may specify that collected location information should be sent every 5 minutes. The following figure illustrates the services used to start and stop a location tracking session and how location information is provided in a location tracking session.
- 87 -
Figure 6-34 Starting and Stopping a Location Tracking Session
Switching Function
Computing Function
1.
Start Location Tracking Session (locdevice=D1, collectionType=updatesOnly, reportingType=immediate) (positive acknowledgement with locCrossRefID=5)
2. 3. 4. 5. 6. 7. 8.
Location Information Report (locCrossRefID=5, LocationInfo) (positive acknowledgement) Location Information Report (locCrossRefID=5, LocationInfo) (positive acknowledgement)
Stop Location Tracking Session (locCrossRefID=5) (positive acknowledgement)
Line 1 shows how a location tracking session is created by a Start Location Tracking Session service. In this example, the computing function specifies that it wants the switching function to collect location information associated with locDevice D1 whenever it is changed (collectionType=updatesOnly). In this example, the collectionFilter parameter is not provided so the switching function uses its default. The computing function also specifies that it wants to receive location information whenever it is collected by the switching function (reportingType=immediate).
6.8.4.2
The switching function responds with a positive acknowledgement that includes the locCrossRefID. This locCrossRefID is provided as a parameter on all subsequent services that pertain to a specific location tracking session. Reporting Location Information in a Location Tracking Session Once a location tracking session has been created, the Location Information Report service provides the location information associated with the device. Location Information Report(s) services continue to be generated (subject to collection and reporting criteria) as long as the location tracking session exists. Line 3 in Figure 6-34 shows the Location Information Report service sent by the switching function. The Location Information Report service includes the locCrossRefID parameter so that the computing function can correlate the location information to a specific location tracking session. The computing function responds with a positive acknowledgement as shown in line 4.
6.8.4.3
Some time later when the location information is updated, the switching function sends another Location Information Report service and the computing function responds as shown in lines 5 and 6 in Figure 6-34. Stopping a Location Tracking Session The Stop Location Tracking service is used to stop the location tracking. The Stop Location Tracking service is a bi-directional service; it can be issued by either the computing function or by the switching function.
6.8.4.4
Line 7 in Figure 6-34 shows the computing function sending a Stop Location Tracking service that includes the locCrossRefID. The computing function responds with a positive acknowledgement as shown in Line 8. Suspending and Resuming a Location Tracking Session There may be situations where a location tracking session needs to be temporarily interrupted. This could be due to a performance situation in the switching function where the switching function no longer has the ability or resources to track location information. Another reason that a switching function might need to - 88 -
interrupt the tracking of a device is when the device can no longer be contacted due to a loss of network connectivity. Location tracking may be suspended and resumed via the “Suspend Location Tracking Session” and the “Resume Location Tracking Session” services. These services are invoked by the CSTA computing function. Location information is not collected or reported when a location tracking session is suspended. The Location Tracking Session Suspended and the Location Tracking Session Resumed services notify the computing function when the tracking session has been suspended or resumed. This could occur due to an unsolicited situation in the switching function or due to a computing function service as described above. Figure 6-35 illustrates how the switching function suspends and later resumes a location tracking session. Figure 6-35 Switching Function Initiated Suspension of a Location Tracking Session
Switching Function
Computing Function
1.
Start Location Tracking Session (locDevice=D1, collectionType=updatesOnly, reportingType=immediate) (positive acknowledgement with locCrossRefID=6)
2. 3. 4. 5. 6. 7. 8.
Location Tracking Session Suspended (locCrossRefID=6, locReason=networkInterruption) (positive acknowledgement) Location Tracking Session Resumed (locCrossRefID=6, locReason=networkRestored) (positive acknowledgement) Location Information Report (locCrossRefID=6, LocationInfo) (positive acknowledgement)
In the above example the switching function suspends a location tracking session because a connection to the device which is being used to collect location information has been lost. This may be due to the device powering off or a temporary loss of network connectivity. As shown in Line 3 the switching function sends a Location Tracking Session Suspended service with a locReason of networkInterruption to notify the computing function that the location tracking session has been suspended so that the computing function knows why it does not receive further location information. The service includes the locCrossRefID parameter so that the service can be associated with the correct location tracking session. The computing function responds with a Positive Acknowledgement as shown in line 4. Some time later when the switching function is able to communicate with the device, the switching function sends a Location Tracking Session Resumed service with the locReason of networkRestored as shown in Line 5. The computing function responds with a positive acknowledgement. Line 7 shows the switching function sending location information after the location tracking session is resumed.
- 89 -
Figure 6-36 illustrates how the computing function suspends and later resumes a location tracking session using the Suspend and Resume Location Tracking services. Figure 6-36 Computing Function Initiated Suspension of Location Tracking Session
Switching Function
Computing Function
1.
Start Location Tracking Session (locDevice=D1, collectionType=updatesOnly, reportingType=immediate) (positive acknowledgement with locCrossRefID=7)
2. 3. 4. 5. 6. 7. 8.
Suspend Location Tracking Session (locCrossRefID=7) (positive acknowledgement) Location Tracking Session Suspended (locCrossRefID=7) (positive acknowledgement) Resume Location Tracking Session (locCrossRefID=7) (positive acknowledgement)
Location Tracking Session Resumed (locCrossRefID=7)
9. 10.
(positive acknowledgement)
As shown in line 3 of the above figure the computing function sends a Suspend Location Tracking Session service to the switching function to request that the location tracking session be suspended. The switching function responds with a positive acknowledgement. When the location tracking session is suspended the switching function sends a Location Tracking Session Suspended service to notify the computing function that the location tracking session is suspended. Some time later the computer function requests that the location tracking session be resumed as shown in line 7. As as result the switching function sends a Location Tracking Session Resumed service to notify the computing function that the location tracking session is suspended.
6.8.5
During the time that a location tracking session is suspended, the switching function shall not collect or report location information. Setting Location Information The computing function sets location information associated with a device via the “Set Location Information” service. This service can be used when the computing function has determined the location of the CSTA device and wants to provide the switching function with the location of the device. The mechanism that the computing function uses to determine the location information (manual entry by a user via an application interface, by interfacing directly with embedded location APIs, etc.) is not specified. The computing function specifies if the location-information shall replace or augment existing location information in the switching function. Once the switching function is informed of the location information, it shall report the location information to any computing functions (subject to collection and reporting criteria) that have active location tracking sessions for the associated device (see 6.8.4 on page 87). The switching function shall also provide this information via polling services (see 6.8.2 on page 87) or via call control events (see 6.8.3 on page 87). - 90 -
Figure 6-37 illustrates how the computing function specifies location information. Figure 6-37 Setting of Location Information
Switching Function
Computing Function
Set Location Information (device=D1, locationInfo=xxx)
1.
(positive acknowledgement)
2. 3. 4.
Start Location Tracking Session (locDevice=D1)
5. 6.
Set Location Information (device=D1, locationInfo=yyy)
(positive acknowledgement with locCrossRefID=8)
(positive acknowledgement)
Location Information Report (locCrossRefID=8, locationInfo=yyy)
7. 8.
(positive acknowledgement)
As shown in line 1 of the above figure the computing function sends a Set Location Information service to the switching function with location information to be associated with the device D1. In this example device D1 is coexists with an application that allows a user to enter the location of the device manually through an application interface (i.e. soft phone application). Since in this example there are no location tracking sessions for the device at this time no Location Information Report service is generated by the switching function as a result of Set Location Information service. After some time a location tracking session is established with the locDevice D1 as shown in line 3. (This may be started by the same application or by another application in the computing function.) Then line 5 in the figure shows the computing function issuing another Set Location Information service for device D1. This time since there is a location tracking session established with device D1, the switching function reports the location information via the Location Information Report service as shown in line 7.
7
Association Establishment This Standard is based upon the assumption that the services defined here, and a protocol that supports these services, operate within an application association (otherwise known as a CSTA association or association) as provided by IS 8649 (ACSE). This association can be either: •
an implicit association realized through the use of a switching function initiated CSTA System Status service
•
an implicit association realized through the use of a computing function initiated CSTA Request System Status service
•
an explicit association realized through the use of ACSE
•
an explicit association realized through the use of Ecma Application Session Services
The initialization sequence of CSTA messages for creating associations is described in the following sections. Once an association has been established, the switching function shall be prepared to receive CSTA services. - 91 -
7.1
Implicit Association created using CSTA System Status service (initiated by Switching Function) In the initialization sequence for an implicit association created using System Status, as shown in Figure 7-1, the switching function begins the sequence by sending a System Status service with a system status value of either Enabled or Normal. The computing function shall respond with a positive acknowledgement. An implicit association is established once the positive acknowledgement is received by the switching function. In Figure 7-1, the computing function uses the Get Switching Function Capabilities service to obtain the capabilities of the switching function after the association has been created. Figure 7-1 Implicit Association created via System Status - Initialization Sequence
Switching Function
Computing Function System Status service (value=Enabled or Normal) System Status pos. ack.
Association Created Get Switching Function Capabilities Get Switching Function Capabilities pos. ack.
Mandatory messages Optional messages
7.2
Implicit Association created using CSTA Request System Status service In an implicit association created using CSTA Request System Status, the computing function sends a CSTA Request System Status service request to establish an application association. The switching function shall respond with a positive acknowledgement that includes a System Status value. The mandatory part of the initialization sequence is completed once the positive acknowledgement is received by the computing function. The initialization sequence for an implicit association created using CSTA Request System Status is shown in Figure 7-2. In this figure, after the application association is created, the computing function uses the Get CSTA Features service to obtain the services and events supported by the switching function. Next the application uses the System Register service to register with the switching function to receive System Status services. Some time later the switching function sends a System Status request to the application to notify it of a change in system status.
- 92 -
Figure 7-2 Implicit Association created using CSTA Request System Status - Initialization Sequence
Switching Function
Computing Function Request System Status request Request System Status response
Association Created Get CSTA Features service request Get CSTA Features service response System Register request System Register response
System Status System Register response Mandatory messages Optional messages
7.3
Explicit Association created using ACSE In an explicit association created using ACSE, CSTA shall make use of a single application context name for all versions and variations of implementation of CSTA Services and Protocol. To facilitate the exchange of version and implementation information, CSTA specifies that the following information shall be exchanged in the ACSE Association Information field. 1. CSTA Association Information shall provide the following parameter: •
CSTA Version - shall indicate the versions of the CSTA protocol that the implementation can support. If two interacting systems support more than one version, then the highest CSTA Version they both support shall be used for the association. A CSTA protocol version refers to the implementation of a specific version of the CSTA Standard described in the corresponding CSTA Protocol Standard.
2. CSTA Association Information also may provide the following parameters: •
Functionality Required - shall indicate the CSTA Services and Event Reports that are required by the function providing this information.
•
Functionality Offered - shall indicate the CSTA Services and Event Reports that are offered by the function providing this information for its highest-supported CSTA Version.
•
Private Data Version - shall indicate the Private Data versions that are offered by the function providing this information.
The initialization sequence for an explicit association is shown in Figure 7-3. The computing function begins the sequence by sending an ACSE request with the appropriate CSTA Association Information as - 93 -
described above. The switching function responds with an ACSE response that also includes the appropriate CSTA Association Information. After the ACSE exchange, the switching function sends a System Status service with a system status value of either Enabled or Normal. The computing function shall respond with a positive acknowledgement. The mandatory part of the initialization sequence is completed once the positive acknowledgement is received by the switching function. In this figure, the computing function uses the Get Switching Function Capabilities service to obtain the capabilities of the switching function after the association has been established. Figure 7-3 Explicit Association Created using ACSE - Initialization Sequence
Switching Function
Computing Function ACSE Request (CSTA Association Info.) ACSE Response (CSTA Association Info.)
System Status service (value=Enabled or Normal) System Status pos. ack.
Association Created Get Switching Function Capabilities Get Switching Function Capabilities pos. ack.
Mandatory messages Optional messages
7.4
Explicit Association created using Ecma Application Session (ECMA-354) Services In an explicit association created using Ecma Application Session Services, the computing function sends a CSTA Start Application Session service request to establish an application association. The switching function shall respond with a positive acknowledgement. The initialization sequence for an explicit association created using Ecma Application Session services is shown in Figure 7-4. In this figure, after the application association is created, the computing function uses the Get CSTA Features service to obtain the supported services and events. Next the application uses the System Register service to register with the switching function to receive System Status services. Some time later the switching function sends a System Status request to the application to notify it of a change in system status.
- 94 -
Figure 7-4 Explicit Association Created Using Ecma Session Control Services
Switching Function
Computing Function Start Application Session service request Start Application Session service response
Association Created Get CSTA Features service request Get CSTA Features service response System Register request System Register response
System Status System Register response Mandatory messages Optional messages
8
Security Service All CSTA messages provide: •
Timestamp information. This can be used to determine the “freshness” of a message.
•
A Message Sequence Number. This provides a capability to number messages in a sequence so that the message receiver can detect that a message has been received out of sequence.
•
Security Information. Support the implementation of a security process. This can be used to provide security such as access control and authentication. The format of this information is implementation specific.
For more information, refer to 12.2.12, “CSTASecurityData”, on page 120.
9
Generic Service Requirements
9.1
Service Request This Standard defines a set of CSTA operations that can be used to control and observe objects within a switching and/or special resource function. The CSTA operations are defined as “Services” in which one function requests, across the service boundary, that the other function perform a given CSTA operation. Services are defined for the CSTA service boundaries between the computing function, switching function, and special resource function. Services are defined in terms of what they accomplish (i.e. functionality), not how they should be implemented. When one function sends a service request to the other function to perform a service with a given set of parameter values, it is called a service request. Each service defined in this Standard falls into one of following categories based upon the direction of the service request: - 95 -
•
Switching Function Service - Switching function services are services where the computing function is the client (i.e., service requestor) and the switching function is the server. An example of a switching function service is the Make Call service.
•
Computing Function Service - Computing function services are services where the switching function is the client (i.e., service requestor) and the computing function is the server. An example of a computing function service is the Route Request service.
•
Special Resource Function Service - Special Resource function services are services where the computing function is the client (i.e., service requestor) and the special resource function is the server. An example of a special resource function service is the Play Message service for a Voice Unit device when it is part of the Special Resource Sub-Domain.
•
Bi-directional Service - Bi-directional services are services where either the switching/special resource function or the computing function can be the client (i.e., service requestor). An example of a bi-directional service is the System Status service.
Some switching/special resource functions implementations support registration mechanisms that allow the computing function to indicate that it would like to receive service requests in a certain category (e.g., routeing, system status, escape) from the switching/special resource functions. (If the switching/special resource function indicates that it supports the computing function services in a particular category but does not support the registration mechanism, the computing function shall be prepared to handle the requests without previous registration.) If the server detects that a service request is invalid, a negative acknowledgement shall be generated. Every service request and service response defined in this Standard allows the inclusion of nonstandardized, private data, that shall be informational in nature. Refer to 9.4, “Vendor Specific Extensions”, on page 98, for more information.
9.2
Service Response (Acknowledgements) The other part of a service is the acknowledgement to the service request. This acknowledgement is used by the requesting function to verify that the other function has received the service request and that some level of processing has been performed with respect to the service. There are two types of acknowledgements: positive acknowledgements and negative acknowledgements, for a given service, as well as two types of positive acknowledgement models which a given service can adhere to. These definitions are documented in the following sections.
9.2.1
Note that there are some services defined in this Standard that do not provide a positive acknowledgement. For these services, if the service request is invalid, a negative acknowledgement shall be generated. Positive Acknowledgement Models
9.2.1.1
All acknowledgements to each service request defined in this Standard shall follow the principles outlined by one of two models defined below. The computing function learns which model a switching function supports for each service through the capability exchange services described in Clause 13, “Capability Exchange Services”, beginning on page 158. Atomic Model Switching functions that indicate support of the atomic acknowledgement model designate that the particular service request can be accomplished in a single logical step. This acknowledgement model reflects whether or not the service request has meet the completion conditions as documented by each individual service. An atomic positive acknowledgement indicates that not only were the parameters on the service request valid, but the switching function has successfully completed the service requested as defined in that service’s “Service Completion Conditions” section. The condition of the call(s) and/or connection states of
- 96 -
9.2.1.2
the device(s) associated with the service request have transitioned to that service’s Operational Model After state. Multi-Step Model Switching functions that indicate support of the multi-step acknowledgement model designate that the particular service request is accomplished as its name implies, in multiple logical steps. This acknowledgement model reflects whether or not the parameters passed on the service were valid but does not guarantee anything as far as the completion conditions is concerned for the service. A multi-step positive acknowledgement guarantees only that the parameters passed on the service request were accepted by the switching function to be valid. This positive acknowledgement does not determine if the service request’s completion criteria are met. (However, depending on the switching function, the positive acknowledgement may indicate, in certain situations, the service request’s completion conditions.) Therefore the computing function shall monitor for events associated with the particular service request, affected call(s) or device(s) to verify completion. A computing function shall also be prepared to handle the Service Completion Failure event and/or the Failed or Connection Cleared events after receiving the positive acknowledgement. The Service Completion Failure event will only be reported to the computing function which issues the service request and has a device-type monitor on the device which has or had connection(s) that were used in the particular request. Each of these events are provided by the switching function to indicate that the completion conditions for the service was not met.
9.2.2
If, through the event flow, a failure is detected, it is up to the computing function to apply the appropriate recovery to return the call(s) and/or device(s) back to the original conditions (if needed). Finally, a computing function should not issue subsequent service requests for a device until a previous multi-step service request’s completion conditions has been satisfied. Doing so may result in unpredictable results generated by the switching function. Negative Acknowledgement A negative acknowledgement indicates that the service request has failed and the condition of the call(s) and/or connection states of the device(s) associated with the service request have not changed as a result of the failure (i.e., they remain as they were in the service’s Operational Model Before state).
9.3
Diagnostic Error Definitions CSTA provides diagnostic error information in the negative acknowledgement to service requests. The diagnostic error information consists of an error category and a category specific error value.
9.3.1
The definitions associated with the error categories and the error codes apply equally to services requested by a computing function and to those requested by a switching function. An error value indicates the server’s best evaluation of the condition that caused the server to send a negative acknowledgement to the service request. Error Categories The error categories consist of the following: •
Operation Errors - Error values in this category shall indicate an error in the service request.
•
Security Errors - Error values in this category shall indicate a security error.
•
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.
•
System Resource Availability Errors - Error values in this category shall indicate that the service request could not be fulfilled because of a lack of system resources within the serving sub-domain.
•
Subscribed Resource Availability Errors - Error values in this category shall indicate that the service request could not be fulfilled because a required resource must be purchased or contracted by the client system.
•
Performance Management Errors - Error values in this category shall indicate that an error has been returned as a performance management mechanism. - 97 -
9.3.2
•
Private Data Information Errors - Error values in this category shall indicate an error in the CSTA Private Data of the service request. The reason(s) why the private data is incorrect is not relevant to this Standard.
•
Unspecified Errors - Error values in this category shall indicate that the error did not belong to any of the other error value categories.
Error Values The following definitions are used in all services to ensure a uniform meaning for error codes. •
Error codes reflect why the server could not carry out the service request on the specified call, device, or connection and do not reflect the status of any other call, device or connection.
•
Error codes reflect why the server could not perform the request at the time that it attempted to execute the request. Thus a switching function will return the same error code in the same circumstance regardless of the past history of any object involved in the request.
•
This Standard does not require that service parameters are validated in any order. Thus, when there are multiple errors in parameters (or when multiple errors apply to a single parameter), the computing function may receive any of the applicable errors.
•
There is a hierarchy of error return values. The errors range from one high level error that spans all errors (Generic Unspecified) to specific detailed errors. The diagram below shows the hierarchy. The errors become more detailed toward the bottom of the diagram. Figure 9-1 ErrorValue Hierarchy
Error Return Hierarchy Generic Unspecified Error
Generic System Resource Availability Error
...
Generic State Incompatibility Error
Generic Subscribed Resource Availability Error
Generic Operation Error
... Value Out of Range
...
... Request Incompatible with Object
Object Not Known
...
...
...
...
Generic Performance Management Error
Private Data Information Error
...
...
The specific error values are defined in 12.2.14, “ErrorValue”, on page 121.
9.4
Vendor Specific Extensions This Standard allows the provision of value added services and events that are beyond what is defined in this Standard. It is possible both to extend the existing services and events defined in this Standard as well as to create completely new services and events. A vendor may choose to support a vendor specific extension with the understanding that it may not interoperate with other CSTA (Phase III)-compliant products. - 98 -
9.4.1
Private Data Every service in this Standard allows for the inclusion of implementation-specific private data. This may be any supplemental information (not defined by this Standard) which provides access to vendor-specific extensions. The computing function and the switching function, by mutual agreement (e.g., using the private data negotiation mechanism described below), assume full responsibility for the structure, representation (including byte order) and interpretation of this data. It is recommended that vendors adopt a platform independent encoding scheme (e.g., ASN.1/BER) for their private data. If an implementation receives private data in a CSTA service or event that it does not recognize, it shall ignore the private data and process the rest of the CSTA service or event.
9.4.1.1
The size of private data is not limited by this Standard and is switching function and/or computing function specific. The capabilities exchange services can be used by the computing function to determine the maximum size used by the switching function implementation. Private Data Version Negotiation Private data version negotiation may be performed using the following process: 1. The switching function provides the computing function with its manufacturer name in the positive acknowledgement of the Get Switching Function Capabilities service. By associating the manufacturer name with information in the computing function, the computing function can determine if it supports the switching function’s private data and its associated private data version negotiation mechanism. The switching function may also provide its supported private data versions in the Get Switching Function Capabilities acknowledgement. 2. The computing function will send the version to be used in the Private Data Version service request. The computing function may change the negotiated version by sending Private Data Version service requests at any time.
9.4.1.2
Private Data on CSTA Services and Events For the services defined in this Standard, the use of private data allows vendor specific parameters to be added to each service. Private data should only be used to extend the existing definition of a service, and never to redefine the meaning of a service or any of its specified parameters. If a completely new vendor specific service is to be defined, the Escape service shall be used.
9.4.2
Private data can also be used to provide vendor specific parameters on events. As with services, private data should only be used to extend the existing definition of an event, and never to redefine the meaning of an event or any of its specified parameters. If a completely new event is to be defined, the Private event shall be used. Escape Services and Private Event
9.4.2.1
The Escape service and the Private event are unique in that they include only private data and no other service specific parameters. Furthermore, they do not have any defined intent or meaning other than to allow for vendor specific extensions. The Escape service and the Private event may be used to define completely new services and events (i.e., ones not defined in this Standard), respectively. Escape Registration Before the computing function can receive any Escape service requests, it may be required to register with the switching function for escape services using the Escape Register service. The positive acknowledgement to this service contains the escape register identifier (escapeRegisterID) that the computing function uses to identify service requests that arrive for this registration. If the switching function supports the Escape Registration services, then the computing function shall use the Escape Register services to register for escape services before it can receive any Escape service requests. If the switching function does not support the Escape Registration services, then the computing
- 99 -
function may receive Escape service requests at any time. The capabilities exchange services can be used to determine if the switching function supports the Escape Registration services. An escape registration can be cancelled using the Escape Register Cancel service. Once the switching function sends a positive acknowledgement to this, it will no longer send Escape service requests to the computing function. Additionally, the switching function can cancel an escape registration at any time by sending the computing function an Escape Register Abort service request.
9.4.2.2
While the Escape service itself is bi-directional, the Escape Registration services are not. These services are only issued by the computing function. The switching function does not register with the computing function for escape services. The switching function is considered to be (implicitly) registered to receive Escape service requests from the computing function at any time. The computing function never needs an escape registration to issue an Escape service request. Private Data Version Service
9.4.2.3
The Private Data Version service is used by the computing function to negotiate a private data version (or to negotiate no private data). The Private Data Version service can be used as needed to re-negotiate (i.e., change) the private data version being used by the computing and switching functions. Escape Service The Escape service is used to request completely new, vendor-specific services not defined by this Standard. This service is bi-directional (i.e., can be issued by either the switching function or computing function). The vendor specific parameters to the Escape service request are transported by the private data (privateData) parameter to the service request. It is the responsibility of the vendor to define any extended services and the contents of the private data for these services. The Escape service request may contain an escape registration identifier (escapeRegisterID) to identify the associated escape registration (when escape registration is supported by the switching function). An Escape service request from the computing function should never contain an escape registration identifier.
9.4.2.4
Escape service requests are always acknowledged by a positive or negative acknowledgement from the serving function (i.e., computing function or switching function processing the service request). Private Event The Private event is used to report completely new, vendor-specific events not defined by this Standard. As with other events, the computing function shall use the monitoring mechanism (i.e., Status Reporting services) in order to receive Private events. The type of monitors (i.e., call-type or device-type) on which a Private event is reported is switching function implementation specific. The monitor cross reference identifier (monitorCrossRefID) parameter associates the event with the monitor. There is no mechanism defined to allow the computing function to send Private events to the switching function. The vendor specific parameters associated with the Private event are transported by a private data (privateData) parameter. It is the responsibility of the vendor to define any extended events and the contents of the private data for these events.
9.5
General Services and Event Functional Requirements
9.5.1
The following sections discuss functional requirements that are applicable to the services and events specified in this Standard. Services 1. If a service is performed manually from a device, computing functions that have device-type or calltype (for device or call) monitors on this device receive the same event sequence as reported when performing the service through the service boundary (i.e., computing function-initiated). Refer to the appropriate service’s “Monitoring Event Sequence” sections for details. Depending on the particular switching function, additional events may also be reported as part of manual invocation services. For example: 3
- 100 -
•
A Held event, if the device already has an active call.
•
A Service Initiated (event cause of NewCall) event for the device because a new call is needed to execute the service manually. This is followed by a Connection Cleared (event cause of Normal Clearing) event for the device when the service has been executed.
•
Logical and Physical device events that are associated with the execution of the service. These events may appear any time during the execution of the service.
2. If a service request is invoked after a device has manually gone off-hook (Service Initiated event), an implementation may either accept the service or it may reject the service. If it accepts the service, (unless otherwise specified for a particular service or event), the connection that has gone off-hook will be cleared and the computing function will receive a Connection Cleared event, followed by service specific events. 3. Other than for calls in the Initiated state, a service only affects connections that are specified by its service description. If, prior to its completion, the execution of the requested service would cause the switching function to affect any other connections, then the service shall be rejected with a negative acknowledgement. 4. If the switching function permits the passing of Connection Identifiers without Call Identifiers, then the Device Identifiers they contain shall be within the switching sub-domain. In addition, if DeviceIDs only are passed in the Connection Identifiers, then: •
If only one call exists at the specified device and the service request supports a single ConnectionID, its connection shall be in one of the initial states specified by the service or the service will be rejected.
•
If more than one call is in an initial state defined by the service, the service request will be rejected.
•
If two calls exist at the specified device and the service request supports two ConnectionIDs in the service request, the DeviceIDs within the ConnectionIDs shall be identical or the service will be rejected.
•
If two calls exist at the specified device and the service request supports two ConnectionIDs in the service request, both calls shall be a valid combination of initial states specified for that service or the service will be rejected.
•
If more than two calls exist at the specified device, the service will be rejected unless full and valid ConnectionIDs are specified.
5. If the device that is the subject of a service request is not capable of performing the service, a negative acknowledgement with an appropriate error code will be provided. 6. For optional parameters in service requests the following requirements apply: a. If an optional parameter is supported by the switching function but is not supplied in a service request, the switching function uses the specified default value associated with that parameter unless otherwise specified. b. If an optional parameter is not supported by the switching function, the switching function uses its administered value unless otherwise specified. (In addition, if the non-supported parameter is passed in the service request, see Services Requirement #7). 7. The switching function may either reject service requests that contain optional parameters that it does not support, or, it may accept the service request and ignore the unsupported optional parameters. However, the switching function shall handle unsupported optional parameters the same 3. These events are only reported if the computing function has the appropriate monitors started for the device (i.e., correct filters and type of monitor) and those monitors are supported by the switching function.
- 101 -
way for all service requests. The switching function indicates how it handles unsupported optional parameters via the capabilities exchange services. 8. When setting a value for a Physical or Logical Device Feature (specifically the “Set” features described in Clause 21, “Physical Device Features”, on page 478 and Clause 22, “Logical Device Features”, on page 528), the switching function shall return a positive acknowledgement when the feature is already set to the requested value specified in the service request. (Since the service request, in this case, did not result in a change of feature status, a feature event will not be generated.) 9. It is the switching function’s responsibility to verify that connections in a call are in their proper initial states prior to accepting a service request. Acceptable states are documented in each service request’s description. 9.5.2
Events 1. For the same telephony situation, the event generated for a call-type monitor will be the same as the event generated for a device-type monitor, except that the localConnectionInfo and the servicesPermitted parameters described in the Call Control event descriptions are not provided for events generated for call-type monitors. 2. If the computing function has call-type monitoring in effect, the event seen for that monitor will be the same event as the one seen for the subject device from a device-type monitor. 3. If the Device Identifier portion of a Connection Identifier is a static Device Identifier, then that portion of the Connection Identifier and the Device Identifier parameters in an event will not necessarily be the same. For example, the switching function may have a static internal representation of a device which will be used in the Connection Identifier, but the actual diallable representation for the same device may be different and may be used in one of the Device Identifier parameters in the same event. This requirement is in addition to and does not supersede the definition for the Connection Identifier or Device Identifier parameters described in 12.3.9, “ConnectionID”, on page 149 and 12.3.11, “DeviceID”, on page 151. 4. The set of state transitions (refer to Figure 6-25, "Connection State Model" on page 51) supports the services and features documented in this Standard.
10
CSTA Device Identifier Formats This clause describes the formats that may be used for Device Identifiers, their usage, and examples.
10.1
Device Identifier Formats The possible types of Device Identifiers formats are: •
Diallable Digits - this format is a sequence of characters to be dialled to reach a device. The sequence of characters may contain diallable digits and/or special characters that specify to the switching function how digits should be dialled (“,” indicates that a pause should be inserted into the dialling sequence, for example). This format must be used when special dialling characters are required or when it is necessary to provide partial or incomplete dialling sequences.
•
Switching Function Representation - this format is a sequence of characters that is used to reference devices within a switching sub-domain. In addition to specifying the directory number of the device, it also provides the ability to specify call appearance, agent identifier, subaddress, name, etc.
•
Device Number - this format is an non-diallable, integer representation of a Device Identifier. This format of Device Identifier can be used to reference switching sub-domain devices that may not be typically associated with a diallable number such as trunks, line cards, etc.
- 102 -
•
10.1.1
URI Representation - this format is a sequence of characters that is used to reference a logical or physical resource (e.g. device, user) using a Uniform Resource Identifier (URI) according to the guidelines in IETF RFC 2396.
In this section, the following example will be reflected. The called number is a subscriber in the US (country code 1) in San Jose (area code 408). The local number is 996 1010. The extension is 321. The name of the subscriber is “John Smith”. Diallable Digits Generic Format: DD A first character of the Device Identifier string which is not “N” indicates that the Device Identifier uses the Diallable Digits format. This format may contain from 0 (a null formatted Device Identifier) to 64 characters. DD is a string of dialling commands/digits. The following is the list of the complete set of permitted dialling commands/digits and their definitions: 0-9
These characters represents the number digits on a telephone keypad.
*
This represents the “*” character, typically found on a telephone keypad.
#
This represents the “#” character, typically found on a telephone keypad.
A-D
These characters represent DTMF digits.
!
The exclamation mark indicates that a hookflash is to be inserted into the dial string.
P
The character P followed by a string of digits indicates that the string of digits is to be pulse dialled.
T
The character T followed by a string of digits indicates that the string of digits is to be tone dialled.
,
The comma character indicates that dialling is to be paused. The length of the pause is provided by the switching function through the capabilities exchange services. Multiple commas can be used to create a long pause.
W
The character W followed by a string of digits indicates that the string of digits is to be dialled only after dial tone has been detected by the switching function.
@
The “at” symbol indicates that the switching function shall wait for “Quiet Answer” before dialling the rest of the string. This means that the switching function shall wait for remote ringing indication, followed by 5 seconds of silence.
$
This dollar sign indicates that the switching function shall wait for the billing signal (i.e., credit card prompt tone) before continuing.
;
The semi-colon character indicates that the digit string is incomplete and more digits will be dialled using the Dial Digits service. This character may only be used in a Diallable String Device Identifier.
+
The plus sign indicates that this number is an international number format.
To aid in readability, the digit string may contain the following visual separators: “-”, “(“, and “)”. Examples: •
If the number is called from France (country prefix 004), the string is “00,14089961010W321”.
•
If the number is called from a switch in New York (dial 9 to get outside line), the string is “9,14089961010W321”.
4. The country prefix is the sequence of digits that needs to be dialled to make an international call (011 when calling from the US). It is always followed by the called country code.
- 103 -
•
If the number is called from San Jose, the string is “9961010W321”.
•
If the number is called from inside the subscriber’s PBX, the string is “321”.
•
+1(408)555-1212 indicates an international number that includes visual separators for readability.
Functional Requirements: 1. The switching function shall accept, as a minimum, digits 0-9 of this format when the computing function wants to make a call. 2. The diallable digits format shall be used to represent a device’s dialling sequence. A device’s dialling sequence is a string of outband digits used to initiate a call with another device. When placing a call from a device to another device, there are basically two ways a device’s dialling sequence can be used: a. The entire sequence of digits is dialled to reach the destination. This is the most common way to place a call. b. The dialling sequence is broken up into a number of stages in order to execute and complete the call. This is called “multi-stage” dialling in this Standard. This type of dialling is needed in cases where the switching function prompts the device for more digits (by sending dial tone again or some other tone). Note that switching functions support different combinations of dialling sequences. 10.1.2
Switching Function Representation Generic Format: N<DN!SA&CA/EXT%AID>NM (in this order) The syntax of the generic format is broken down as follows: N
The “N” character at the beginning of the Device Identifier string (which is 2 to 64 characters in length) indicates that the Device Identifier uses the Switching Function Representation format. At least one of the following components needs to be present in this format:
<>
The angled brackets characters encompass the string when a name (NM) string representing the person associated with the device is provided after the “>” character. If the character “<” is not the first character in the string after the N then the string will not have a name string associated with it.
DN
The first string of characters represents the Directory Number (DN) associated with the given device. The Directory Number shall contain characters selected from the following set: “0” through “9”, “*”, “#”, DTMF digits “A” through “D”. The “+” character as a prefix indicates that the number is an international number format. To aid in readability, the device identifier string may contain the following visual separators: “-”, “(“, and “)”. The Directory Number may use any of the following notations (refer to ECMA-155, ITU-T Rec. E.131): •
Implicit TON (Type Of Number), (example: “0014089961010”5)
•
PublicTON - unknown
•
PublicTON - international number, (example: “14089961010”)
•
PublicTON - national, (example: “4089961010”)
5. This example is a caller in France dialling the country prefix (00), the USA country code (1), the trunk code (408) and the subscriber number.
- 104 -
•
PublicTON - subscriber, (example: “9961010”)
•
PublicTON - abbreviated, (example: “17”)
•
PrivateTON - unknown
•
PrivateTON - level 3 regional, (example: “41396557321”)
•
PrivateTON - level 2 regional, (example: “96557321”)
•
PrivateTON - level 1 regional, (example: “557321”)
•
PrivateTON - local, (example: “321”)
•
PrivateTON - abbreviated, (example: “2”)
•
Other (other numbering plans)
•
Generic (the notation is unknown)
!
This exclamation mark character represents the start of a Sub-Address (SA) string. If the “!” character is not present, then there will be no sub-address associated with this Device Identifier string. The termination character for the sub-address string will be the next key character found in the string or null.
&
The ampersand symbol represents the start of a Call Appearance (CA) string. It is added to the logical element’s device identifier to uniquely identify an addressable standard appearance. The value of the string is switching function specific. The valid characters for the call appearance string are 0-9. The termination character for the call appearance string will be the next key character found in the string or null. Refer to 6.1.1.2.1, “Appearance”.
/
The slash symbol represents the start of a physical element extension (EXT) string. It is added to the logical element’s device identifier to uniquely identify a bridged appearance. Its value is the physical element’s device identifier that is associated with the appearance. The termination character for the physical element extension string will be the next key character found in the string or null. Refer to 6.1.1.2.1, “Appearance”.
%
The percent sign represents the start of an Agent ID (AID) string. This string represents an ACD agent identifier associated with a device. This string may be present when the computing function wants to focus a service at a specific agent identifier that is associated with a device or when the switching function generates an event that is associated with a particular device and agent. The valid characters for the agent identifier string are A-Z and 0-9. If the “%” character is not present then there will be no agent identifier associated with this Device Identifier string. The termination character for the agent identifier string will be the next key character found in the string or null.
~
The tilde sign represents the start of a resource ID (RID) string that indicates the resource identifier associated with a device. This string should be present either when the computing function wants to focus a service at, or when the switching function generates an event that is associated with a particular resource of the device. The format for a valid resource identifier string is specified in 12.3.25.
NM
The name string (NM) represents the person associated with the device. This string can be used for selecting a Device Identifier associated with a user or for logging and informational purposes. The name string may contain any character. This can be used to represent a SIP URI, for example.
- 105 -
Examples: •
If the Device Identifier is PublicTON International, then the string can be “N14089961010”.
•
If the Device Identifier is PublicTON Subscriber, then the string can be “N<9961010>John Smith”.
•
If the Device Identifier represents a SIP user, then the following strings can be used: •
SIP URI: “N<>sip:[email protected]”.
•
SIP URI and a display name: “N<>John Smith<sip:[email protected]>”
•
DN, SIP URI, and a display name: “N<9961010>John Smith<sip: [email protected]>”
Functional Requirements: 1. This format shall always contain at least a directory number string, an agent ID string, or a name string. 2. The interpretation of additional digits beyond those that are required to reach a destination are switching function specific. 3. When there is more than one bridged appearance associated with a single physical element (see 6.1.1.3.6, “Hybrid”, on page 23 for an example) there are two methods for representing these appearances: One is to have a unique call appearance (CA) and physical element extension (EXT) combination for each appearance where EXT is used to represent the given physical element and CA is used to represent multiple appearances associated with the same physical element. The other is to have a single EXT for each appearance, independently of their association with the physical element. In either case, the resulting Device Identifier is unique for the given appearance. 10.1.3
Device Number Generic Format:
10.1.4
The Device Number format represents a Device Identifier using an integer. URI Representation The URI Representation format represents a Device Identifier using a Uniform Resource Indicator (URI). Generic Format: <scheme>:<scheme-specific-part> A Device Identifier character string that contains the colon character “:” uses the URI Representation. The type of URI scheme defines the syntax of the scheme-specific-part. The types of schemes and the specification of the syntax for the scheme-specific-part are outside the scope of this Standard. Note that the Device Identifier string may contain additional information other than a URI. An example is a display name that is frequently used in SIP header fields along with a SIP URI. Examples: sip:[email protected] sip:[email protected]; user=phone tel:+14085551212 <user name> sip:[email protected]
10.2
DeviceID Tags The deviceID formats specified in 10.1 can also contain one or more of the following tags: - 106 -
10.3
privateNumber
The privateNumber tag indicates that the number provided with the deviceID is a private number and may be subject to privacy policies (e.g. presentation restriction). Note that the deviceID used in some parameters can also contain a value of Restricted which indicates that the number is restricted and is also not provided.
privateName
The privateName tag indicates that the name provided with the deviceID is a private name and may be subject to privacy policies (e.g. presentation restriction).
Functional Requirements 1. If the switching function detects a problem with a Device Identifier, the service will be rejected with a negative acknowledgement. 2. The switching function may use any format in service acknowledgements and events. 3. For Device Identifiers in service requests, the computing function should check the deviceIDFormat parameter in a capabilities exchange service to determine: •
Which formats are supported.
•
For the Switching Function Representation format, which notations are supported.
•
For the Diallable Digits format, which special characters are supported.
4. Using the Diallable Digits Format, a null formatted Device Identifier (i.e., a Device Identifier field with 0 characters) can be specified. Some implementations that include only one device in their CSTA Application Working Domain may allow this device to be referenced with a null formatted Device Identifier. For example: callingDevice in the Make Call service, snapshotObject in the Snapshot Device service, monitorObject in the Monitor Start service, physical and logical device features, etc. Unless otherwise noted in this Standard, the interpretation of a null formatted Device Identifier is switching function specific.
11
Template Descriptions This Clause explains the template formats used to describe the CSTA services, events, and parameter types defined in this Standard.
11.1
Service Template
11.1.1
The following sections describe the Services template components. Service Description This is textual description of the service that may be followed by a figure. The figure is included when a service affects a connections state(s). The figure defines the role of devices and connections from a before/after service execution perspective. Note that this figure indicates the successful completion of the service but does not indicate the service completion criteria (see the Monitoring Event Sequences for the service completion criteria). In order to describe the nomenclature used in the figures in the templates, the figure from the CSTA Answer Call service follows:
- 107 -
Figure 11-1 Example of a Figure in a CSTA Service (Answer Call) BEFORE SERVICE
D1 (alerting)
a, q
C1
AFTER SERVICE
D2 (calling)
*
DEVICES D1 : alerting device D2 : calling device
D1
c
C1
*
D2
AFFECTED CONNECTIONS D1C1 : callToBeAnswered connection
CALLS C1 : call that has been delivered to D1
CONNECTION STATES a : alerting state c : connected state q : queued state * : (unspecified/unaffected)
In the figures, small boxes (labeled Dx) are used to represent devices, lines represent connections, ovals (labeled Cx) represent calls, and dotted lines represent connections with partial (“Call ID only”) connection identifiers (see 6.7.2). The legend (large box) associates names with devices and calls. Names in italics refer to parameter names used in the service. The connections are labeled with the set of possible connection states. In some cases the following symbols are used in place of a specific connection state: “*” indicates that the connection state is not specified and it is not affected by the service “!” indicates that the connection state is unspecified but may be affected by the service “#” indicates that the connection state is not specified but the connection state is inherited from a connection that used to exist (for example, when a connection at a device changes its call identifier). 11.1.2
“@” indicates any non-Null connection state. Service Request This section contains a table with the possible parameters in the service request. Associated with each parameter are: •
Parameter Name (“Parameter Name”) - This is used to reference the parameter from other parts of the template and to distinguish the parameter from other parameters with the same parameter type. An example of a parameter name is connectionToBeCleared.
•
Parameter Type (“Type”)- This is the parameter type as defined in Clause 12, “Parameter Types”, on page 111. In most cases a parameter type references a parameter type defined in either 12.2, “Defined Parameter Types”, on page 112 (CorrelatorData, for example) or 12.3, “Identifier Parameter Types”, on page 146 (ConnectionID, for example). In other cases the parameter type may be a Boolean, Value, Enumerated, etc. Refer to 12.1, “Definitions”, on page 111 for more information.
•
Parameter Optionality (“M/O/C”) - Indicates whether the parameter must be included (M for mandatory), if the parameter is optional (O), or if the parameter is conditional (C). If a parameter is conditional, then there are specific requirements when the parameter must be supported. These requirements are described in the parameter description column.
•
Parameter Description (“Description”) - This is a brief description of the parameter in the context of the service. A description of the parameter in the context of its parameter type can be found with its parameter type description in Clause 12, “Parameter Types”, on page 111.
- 108 -
11.1.3
Service Response This section includes:
11.1.4
•
a description of the type of acknowledgement model that can be used with the service (see 9.2.1, “Positive Acknowledgement Models”, on page 96).
•
a table that contains all of the parameters in the positive acknowledgement. The format of the table is the same as in the service request (see 11.1.2).
•
a reference to the negative acknowledgement error codes.
Operational Model The operational model consists of: Connection State Transitions - This is a table with all possible connections affected by the service. Associated with each connection is the: •
Connection Name (“Connection”) - This is used to reference the connection from other parts of the template including the figure in the service description.
•
Initial State (“Initial State (Required)”) - This is the set of allowed initial states (connection states before the service is executed). An implementation shall support one or more of the specified initial states associated with a service (as indicated in the capability exchange services).
•
Final State (“Final State”) - This is the set of allowed final states (connection states after the service is executed). An implementation shall support one or more of these states. In many cases there are statements following the connection state transition table that further describe or clarify the information in the table.
Monitoring Event Sequences - For services that affect connections, this section includes tables that describes the event sequence generated for device-type and call-type monitors. Unless otherwise specified, the events (and associated causes) in this table are required as part of the service completion criteria. Each table contains: •
Monitored Device or Monitored Call (“Monitored Device” or “Monitored Call”) - For the device-type monitoring table, this indicates the monitored device. For the call-type monitoring table, this indicates the monitored call. The names can be used to reference back to the figure in the service description.
•
Connection Name (“Connection”) - This column indicates the connection that is the subject of the event.
•
Event (“Event”) - This is the name of the event generated as the result of the service.
•
Event Cause (“Event Cause”) - This is the set of possible cause codes associated with the event. In many cases there are statements following the connection state transition table that further describes or clarifies the information in the table.
Functional Requirements - The functional requirements contain additional requirements associated with the service.
11.2
Event Template
11.2.1
The following sections describe the Event Template components. Event Description
11.2.2
This is textual description of the event followed by an optional figure. The figure is included when an event indicates a change in one or more connections. The figure defines the role of devices and connections from a before/after perspective. The nomenclature used in the figures is described in 11.1.2, “Service Request”. Event Parameters This section consists of a table that contains all of the parameters in the event. The format of the table is the same as in the service request table described in 11.1.2, “Service Request”.
- 109 -
11.2.3
Event Causes This section consists of a table that contains all of the possible cause codes that can be included with the event. Associated with each cause code are:
11.2.4
•
Event Cause (“Event Cause”) - This is the event cause name.
•
Event Description (“Description”) - This is a description of the event cause in the context of the event.
•
Associated Features (“Associated Features”) - This is the complete set of possible features associated with the cause code. A feature may either correspond to a CSTA service or it may be associated with switch features specified in 6.7, “Additional Services, Features & Behaviour”, on page 69.
Functional Requirements Functional requirements contain additional requirements associated with the event.
11.3
Parameter Type Template
11.3.1
The following sections describe the Parameter Template components: Parameter Type Description
11.3.2
This contains a description of the parameter type. Format This section specifies the format of the parameter type. For example, it could list the possible values associated with a parameter type (enumerated list).
11.3.3
For parameter types that are a type of device identifier, the format contains the allowed statuses associated with the parameter type (e.g. “Not Known”). Functional Requirements Functional requirements contain additional requirements associated with the parameter type.
- 110 -
12
Parameter Types
12.1
Definitions This clause describes the parameter types for the parameters described in this Standard. There are five sets of parameter types: 1. Basic parameter types are simple types that are not necessarily specific to these specifications. The basic parameter types used in this Standard are: •
Boolean - Either TRUE or FALSE.
•
Value - Integer value with a length of 4 bytes always.
•
Characters - Character string of varying lengths, as specified in specific services or events.
2. Meta parameter types refer to constructions that combine one or more parameter types. The meta parameter types used in this Standard are: •
Bitmap - Multiple values may be set in a specified set.
•
Enumerated - One value only may be set in a specified set.
•
Structure - A combination of different types combined into one parameter type, as defined in a specific service or event. Multiple components may be present in the structure (each component in the structure is defined as mandatory, optional, or conditional).
•
Choice Structure - Like Structure, but one and only one component in the structure is present.
•
List - List of a single specified parameter type or structure
3. Defined parameter types are specific to this Standard. They are briefly defined in Table 12-1 on page 112, and further defined in the pages indicated. 4. Identifier parameter types are specific to this Standard. They are briefly defined in Table 12-2 on page 146, and further defined in the pages indicated. 5. Capability bitmap parameter types are bitmaps included in the Get Physical Device Information, Get Logical Device Information and Get Switching Function Capabilities services. They are defined in Annex C.
- 111 -
12.2
Defined Parameter Types Defined parameter types specific to these specifications are summarized in the following table. Table 12-1 Defined Parameter Types Summary Defined Parameter Type
Description
Pg.
12.2.1 AccountInfo
Contains computing sub-domain/business specific code that is to be applied or has been applied to a call for accounting purposes.
113
12.2.2 AgentPassword
Specifies the agent password.
113
12.2.3 AuthCode
Contains an authorization code that the switching function understands and will use to check to see if the user of the computing sub-domain is authorized to perform the given service.
113
12.2.4 CallCharacteristics
Specifies the high level characteristics of the call.
114
12.2.5 CallLinkageData
Specifies the globally unique information that is used to associate CSTA calls that are linked by a switching function because of the way the call was created or manipulated.
114
12.2.6 CallQualifyingData
Specifies information such as wrap codes, walk away codes, hold reasons, transfer reasons, etc. that describes or helps qualify how a call is being (or has been) handled by a user.
116
12.2.7 ChargingInfo
Specifies information that represents a cumulative value of charging or currency units charged to a device for a call in which the device was involved.
116
12.2.8 ConnectionInformation
Specifies the connection information associated with the subject connection.
117
12.2.9 ConnectionList
Specifies the list of devices/connections that are known to the switching function, and which remain in the call after a conference or transfer.
118
12.2.10 CorrelatorData
Contains computing sub-domain-specific data that has been or will be attached to a call that the computing sub-domain is controlling or monitoring.
119
12.2.11 CSTAPrivateData
Provides a mechanism for providing non-standard parameters in events.
119
12.2.12 CSTASecurityData
Specifies the security attributes associated with the message.
120
12.2.13 DeviceHistory
Specifies the list of devices that had been previously associated with the call.
120
12.2.14 ErrorValue
Contains hierarchical error codes.
121
12.2.15 EventCause
Provides additional information on why the event was generated.
132
12.2.16 LanguagePreferences
Specifies the preferred language(s) associated with the call.
136
12.2.17 LocalConnectionState
Describes the connection state of the device associated with the Monitor Cross Reference ID.
136
12.2.18 LocationInfo
Describes the location information associated with a device.
137
12.2.19 LocationInfoList
Describes the location information associated with a list of devices.
138
12.2.20 MediaCallCharacteristics
Specifies the media class (Voice, Digital Data, etc.) and media characteristics of the call.
138
12.2.21 MediaServiceType
Specifies which media service is to be (or has been) attached to or detached from a particular call or connection.
140
12.2.22 MessageInfo
Specifies the message information associated with a call.
141
12.2.23 MonitorFilter
Specifies the events are filtered for a Monitor Start service.
141
12.2.24 PresenceState
Specifies the presence state at a logical device.
142
12.2.25 ServicesPermitted
Specifies the set of services that the switching function permits to be applied to a connection.
142
12.2.26 SimpleCallState
Provides the simple call state.
143
12.2.27 SubjectOfCall
Indicates the subject or intent of the call.
144
- 112 -
Table 12-1 Defined Parameter Types Summary (concluded) Defined Parameter Type
12.2.1
Description
Pg.
12.2.28 SystemStatus
Indicates the reason for the System Status service request.
144
12.2.29 TimeInfo
Specifies the date and time.
144
12.2.30 UserData
Contains device-to-device or computing sub-domain-to-computing sub-domain data.
145
AccountInfo The AccountInfo parameter type contains a computing sub-domain/business specific code that is to be applied or has been applied to a call for accounting purposes. Format This parameter type is a character string. Functional Requirements 1. The management of the account code data is done by the switching function. To understand how the switching function maintains this information with the call, you need to consult the switching function specific documentation. 2. The computing sub-domain will only be notified that the account code data has been added or changed through the Call Information event. This event will be generated when the user enters the account code data manually or after a service has added or changed the data. 3. The way to clear the data on the call is to pass a null string of data on one of the above mentioned services. (The actual parameter is passed, but the content is a null string.) 4. The switching function may choose to filter this information by not providing it in events for security reasons. 5. When this information is being attached to a call through a service request, its association shall be completed prior to any state transitions resulting from the request. Thus any state transition events which contain this parameter shall contain the information passed on the request.
12.2.2
AgentPassword The AgentPassword parameter type specifies the password for an ACD agent. Format
12.2.3
This parameter is a character string. AuthCode The AuthCode parameter type contains an authorization code that the switching function understands and will use to check if the computing function is authorized to perform a given service. Format This parameter type is a character string. Functional Requirements 1. If the switching function requires this parameter, and either the authorization code supplied is not valid or the parameter type is not supplied, then the service will be rejected with a negative acknowledgement. 2. The switching function may choose to filter this information by not providing it in events for security reasons. - 113 -
3. When this information is being attached to a call through a service request, its association shall be completed prior to any state transitions resulting from the request. Thus any state transition events which contain this parameter shall contain the information passed on the request. 12.2.4
CallCharacteristics The CallCharacteristics parameter type describes, when included on an event, the high level characteristics associated with a call. When this parameter is included on a switching function service request, it indicates the requested set of high level characteristics that should be associated with the call. Format This parameter type is a bitmap. Multiple bits may be set. The complete set of possible values in the bitmap is: •
acdCall. This bit is set to indicate an ACD call. Once the call is no longer associated with the ACD, this bit is no longer set. See Functional Requirement #1.
•
lowPriorityCall - This bit is set to indicate that the priority level associated with the call is low.
•
priorityCall - This bit is set to indicate that the priority level associated with the call is normal.
•
highPriorityCall - This bit is set to indicate that the priority level associated with the call is high.
•
maintenanceCall - This bit is set to indicate a maintenance call.
•
directAgent - This bit is set to indicate a call placed directly to a device such as an ACD device or station. This may be used to indicate that e.g. ACD agent states, forwarding settings, or do not disturb settings should be or have been overridden.
•
assistCall - This bit is set to indicate a call whose purpose is to request assistance.
•
voiceUnitCall - This bit is set to indicate a call involving a Voice Unit (e.g., voice mail system) or Interactive Voice Device. Once the Voice Unit or Interactive Voice Device is no longer involved with the call, this bit is no longer set.
•
privateCall - This bit is set to indicate that the sensitivity of the call is private.
•
personalCall - This bit is set to indicate that the sensitivity of the call is personal.
•
sensitiveCall - This bit is set to indicate that the sensitivity of the call is normal.
•
confidentialCall - This bit is set to indicate that the sensitivity of the call is confidential.
•
encryptedCall - This bit indicates that the payload/media associated with the call is encrypted. It may also indicate that the signalling associated with the call is encrypted. The mechanism used for encryption (TLS, IPSEC, SRPT, etc.) is implementation specific.
Functional Requirements 1. There are many conditions when a switching function may classify a call as an ACD call and when an ACD call becomes a non-ACD call. The specific conditions are switching function dependent. 2. If multiple priority and/or security values are indicated, it is suggested (but not required) that the highest value should be used. The levels of sensitivity are (in increasing order): privateCall, personalCall, sensitiveCall, and confidentialCall. The levels of priority are (in increasing order): lowPriorityCall, priorityCall, and highPriorityCall. 12.2.5
CallLinkageData The CallLinkageData parameter type contains globally unique information that is used to associate CSTA calls that are linked by a switching function because of the way that a call was created or manipulated. - 114 -
For example, a call that is created as the result of the CSTA Consultation Call service (consulted call) may be linked to the call placed on hold at the consultation device by the CallLinkageData parameter type. The CallLinkageData parameter type can also be used to correlate calls in different switching subdomains with the same “end-to-end” or “global” call. See 6.1.2.7, “Call Linkage”, on page 46 for a description of the call linkage feature. Format This parameter type is comprised of a sequence of the following: •
globalCallData (M) Structure - this component contains information that pertains to an “end-to-end” or “global” call. It consists of the following: •
globalCallSwitchingSubDomainName (C) Characters - specifies the name of the switching subdomain that created the globalCallData. This component is required if the globalCallLinkageID component is not a globally unique value, otherwise it may be omitted. See Functional Requirement #2.
•
globalCallLinkageID (M) Choice - specifies the global call linkage identifier. This consists of one of the following choices:
• •
•
subDomainCallLinkageID Characters - specifies the switching function specific call linkage identifier. The maximum length supported by the switching function is provided via the capabilities exchange services.
•
globallyUniqueCallLinkageID Characters - specifies the globally unique call linkage identifier. See functional requirement #2b.
callLinkageIDTimestamp (O) Timeinfo - specifies the time that the globalCallData was created. The format is described in 12.2.29.
threadData (C) Structure - This information pertains to the entire call thread, i.e. all calls that are linked together as part of the same thread. This component shall only be provided if the switching function supports the thread linkage feature (as indicated by the capability exchange services). It consists of the following: •
threadSwitchingSubDomainName (C) Characters - specifies the name of the switching subdomain that created the threadData. This is required if the threadID is not a globally unique value, otherwise it may be omitted. See Functional Requirement #2.
•
threadLinkageID (M) Choice - specifies the thread linkage identifier. This consists of one of the following choices:
•
•
subDomainThreadID Characters - specifies the switching function specific thread linkage identifier. The maximum size supported by the switching function is provided via the capabilities exchange services.
•
globallyUniqueThreadID Characters - specifies the globally unique thread linkage identifier. See functional requirement #2b.
threadIDTimestamp (O) Timeinfo - specifies the time that the threadData was created. The format is described in 12.2.29.
Functional Requirements 1. The switching sub-domain names are used to distinguish one switching sub-domain from another. It is the responsibility of the switching function to provide a value that is unique within the switching domain.
- 115 -
2. The switching function that creates the callLinkageData ensures that it is globally unique by one of the following: a. providing the switching sub-domain name component along with a switching sub-domain unique identifier component. The combination of these two components provides call linkage data that is globally unique. b. providing a globally unique call linkage identifier component. The switching function that provides this choice of linkage identifier must generate the globallyUniqueCallLinkageID and/or the globallyUniqueThreadID via the algorithm used to create the globally unique ID as specified in ITU-T Rec. H.225. 3. Whenever the globalCallData or the threadData is updated, the corresponding timestamp information shall also be updated. 4. When the switching function provides the globallyUniqueCallLinkageID choice, it shall ensure that: a. if the switching function also provides the globalCallSwitchingSubDomainName, there should be a 1/1 correspondence between the node name field in the globallyUniqueCallLinkageID and the globalCallSwitchingSubDomainName. b. if the switching function also provides the callLinkageIDTimestamp, the timestamp field in the globallyUniqueCallLinkageID should be consistent with the callLinkageIDTimestamp. 5. When the switching function provides the globallyUniqueThreadID choice, it shall ensure that: a. if the switching function also provides the threadSwitchingSubDomainName, there should be a 1/ 1 correspondence between the node name field in the globallyUniqueThreadID and the threadSwitchingSubDomainName. b. if the switching function also provides the threadIDTimestamp, the timestamp field in the globallyUniqueThreadID should be consistent with the threadIDTimestamp. 12.2.6
CallQualifyingData The CallQualifyingData parameter type specifies information such as wrap codes, walk away codes, hold reasons, transfer reasons, etc. that describes or helps qualify how a call is being (or has been) handled by a user. Format This parameter type is a character string. The maximum size supported by the switching function is provided via the capabilities exchange services. Functional Requirements 1. The computing function will be notified that the call qualifying data has been added or changed through the Call Information event. This event will be generated when the user enters the call qualifying data manually or after a service (Associate Data) has added or changed the data.
12.2.7
ChargingInfo The ChargingInfo parameter type represents a cumulative value of charging or currency units charged to a device for a call in which the device was involved. This information can represent an intermediate (during the call) or final total (when the device leaves the call). Format This parameter consists of the following components: •
numberUnits (M) Choice Structure - This component consists of one of the following choices: - 116 -
•
•
•
12.2.8
numberOfChargingUnits (List Structure) - indicates a cumulative number of charging units. This component consists of a sequence that may be repeated to report different types of charging units. The sequence consists of: •
chargingUnits (M) Value - the number of charging units.
•
typeOfUnits (O) Character String - the type of units. This may be included to differentiate among these types. Its definition is network-dependent.
numberOfCurrencyUnits (List Structure) - indicates a cumulative value of currency units. This sequence consists of: •
currencyType (M) Character String - indicates the type of currency. A null string (size of 0) indicates the default currency. Its definition is network-dependent.
•
currencyAmount (M) Value - indicates the cumulative value of currency units.
•
currencyMultiplier (M) Enumerated - indicates the currency unit multiplier. The complete set of possible values is: .001, .01, .1, 1, 10, 100, 1000.
typeOfChargingInformation (M) Enumerated - This can have one of the following values: •
Sub-total - indicates that the information is an intermediate value.
•
Total - indicates that the charging information is complete.
ConnectionInformation The ConnectionInformation parameter type specifies the connection information associated with the subject connection (i.e., the connection that is the focus of the event or positive acknowledgement being reported). Format This parameter type is a comprised of the following parameters: 1. flowDirection (O) Enumerated - Specifics the direction of flow that is associated with the subject connection. If this parameter is not present, the connection’s flow direction is unknown. The complete set of possible values is: •
Transmit - Media stream data is only capable of being transmitted on the connection by the associated device.
•
Receive - Media stream data is only capable of being received on the connection by the associated device.
•
Transmit and Receive - Media stream data is capable of being transmitted and received on the connection by the associated device.
•
None - Media stream data is not capable of being transmitted or received on the connection by the associated device.
2. numberOfChannels (O) Value - Specifies the number of media stream channels that are associated with the subject connection. If this parameter is not present, the number of channels associated with the connection is one. 3. mediaSessionInfo (O) Characters - Specifies the protocol specific information associated with the connection related to the media stream. This could be information derived from the Session Description Protocol (SDP), for example. The format, meaning and behaviour of the media session information is specific to the given switching function.
- 117 -
Functional Requirements 1. The initial connectionInformation associated with a connection that is being created can be specified on certain CSTA services. 2. The ParticipationType parameter in certain CSTA Services (Intrude Call, Join Call, Single Step Conference, etc.) can also be used to specify the flowDirection when a device is becoming part of a call. 3. After a connection is created, the Change Connection Information service can be used to modify the connectionInformation associated with a connection. This can be used to change a connection that was created with a “Receive” flowDirection (initially set up as for “silent monitoring”) to “Transmit and Receive” (active participation), for example. 12.2.9
ConnectionList The ConnectionList parameter type provides the linkage mechanism between a device’s old connection ID and new connection ID resulting from the conference or transfer. Format This parameter includes the following components for every device or connection being reported: •
new ConnectionID (C) ConnectionID - The CallID portion of this ConnectionID refers to the resulting call. This component is optional for the transferringDevice in the Transferred event, otherwise it is mandatory.
•
old ConnectionID (C) ConnectionID - The CallID portion of this ConnectionID refers to the original call. This component is mandatory if the switching function previously reported the CallID, otherwise it is optional.
•
endPoint DeviceID (O) DeviceID - For internal calls, this is the representation of the device inside the switching sub-domain. For external calls (incoming or outgoing), this is the representation of the externally located device (if known by the switching function). This component is a character string. The maximum length supported by the switching function is provided via the capabilities exchange services. It may be:
•
•
•
of any device identifier format
•
of the following statuses: “Provided” “Not Known” “Restricted”
associatedNID (C) DeviceID - For external calls (incoming and/or outgoing), this component specifies the Network Interface Device (e.g., trunk, CO line) within the switching sub-domain that is associated with the externally located device. In that case the component endPoint DeviceID (if provided) shall represent the externally located device. The associatedNID component is mandatory in case of external calls and shall be omitted when the device is located inside the switching sub-domain. This component may be: •
of any device identifier format
•
of the following statuses: “Provided” or “Not Known”
resultingConnectionInformation (O) ConnectionInformation - This component contains the flow direction and channel characteristics associated with the resulting connection.
Functional Requirements 1. This list should be used by the computing function to associate devices which remain in a call, as a result of a Conference or Transfer, with the connection IDs that are used to manipulate them.
- 118 -
12.2.10 CorrelatorData The CorrelatorData parameter type contains computing sub-domain specific data that has been or will be attached to a call that the computing function is controlling or monitoring. This allows the computing function to associate its own information with a call and, as a result, share it with other computing functions. For example, this information might be a key to a database entry, a computing function command sequence, file name, etc. This feature is useful when calls are moving from one computing function to another in a distributed computer network or from one switching sub-domain to another. See 6.1.2.3, “Correlator Data”, on page 42 for specific rules on the use of Correlator Data. Annex B defines one possible mechanism for delivering correlator data through an external ISDN network. Format This parameter type is a string. The maximum length supported by the switching function is provided via the capabilities exchange services. Functional Requirements 1. The correlator data will stay with the call as long as the call exists. This means that the correlator data will be presented to the computing function on events that have this parameter and that the switching sub-domain supports. 2. The correlator data can be changed during the life of the call by any of the services that has the parameter or by using the Associate Data service. 3. The way to clear the data on the call is to pass a null string of data on one of the above mentioned services. (The actual parameter is passed but the content is a null string.) If correlator data is cleared, then the switching function notifies the computing function by sending a null string. 4. See 6.1.2.3, “Correlator Data”, on page 42 for a description of how Correlator Data is inherited by calls during a conference or transfer. 5. If the computing function issues the Consultation Call service without correlator data, initially the secondary call will not have correlator data associated with it, as it does not inherit any correlator data that may be associated with the primary call. If the computing function issues the Consultation Call service with correlator data, this data is for the secondary call only and does not affect any correlator data that may be currently associated with the primary call. 6. When correlator data is associated with a call, for all Call Control events listed in 17.2 on page 345 except for the Bridged, Call Cleared, Connection Cleared, Held, and the Retrieved events (i.e. call events that may indicate that a device becomes part of a call) shall include the correlator data (if supported). Correlator data can optionally be included with the four event exceptions listed above. 7. When this data is being attached to a call through a service request, its association shall be completed prior to any state transitions resulting from the request. Thus any state transition events which contain this parameter shall contain the information passed on the request. 8. If a computing function issues a Snapshot Call service after a service request has been issued with this information, but prior to the switching function making any state transitions, it is switching function specific as to what will be returned in the positive acknowledgement with regards to this parameter. 12.2.11 CSTAPrivateData The PrivateData parameter type provides a mechanism for providing non-standard parameters in messages.
- 119 -
Format This parameter type is a choice of one of the following: •
string of any length. The maximum length supported by the switching function is provided via the capabilities exchange services.
•
ASN.1 NULL type. If this choice is used, an implementation shall replace the ASN.1 NULL type with another valid ASN.1 type.
12.2.12 CSTASecurityData The CSTASecurityData parameter type provides information that can be used to determine if a message in a sequence has been lost, the time that a message was sent, and security information that can be used to provide security such as access control and authentication. Format The CSTASecurityData parameter type consists of the following components: •
messageSequenceNumber (Value) Optional. Shall be a sequential number that can be used to detect missing messages in a sequence and verify that their order has not been altered.
•
timestamp (Timeinfo) Optional. Shall be a generalized time value that can provide an indication of the “freshness” of a message. It can indicate that the received message is not a replay of another message from a previous association or from the current association after the sequence numbers have recycled.
•
securityInfo (Choice Structure) Optional - Shall indicate the security data that may be used to make appropriate access control decisions or to carry out the current security policy. This contents of this information is not defined by this Standard. This component is a choice of one of the following: •
string of any length. The maximum length supported by the switching function is provided via the capabilities exchange services.
•
ASN.1 NULL type. If this choice is used, an implementation shall replace the ASN.1 NULL type with another valid ASN.1 type.
12.2.13 DeviceHistory The DeviceHistory parameter type specifies a list of deviceIDs that were previously associated with the call. A device becomes associated with the call whenever there is a CSTA connection created at the device for the call. The association may also result from a relationship between a device and a call outside the CSTA switching function. A device becomes part of the DeviceHistory list when it is no longer associated with the call (for example: when a call is redirected from a device, when a call is transferred away from a device, and when a device clears from a call). Format The parameter type consists of a list of entries. Each entry contains information regarding a deviceID that had previously been associated with the call. The list is ordered from the first device that left the call to the device that most recently left the call (see Functional Requirement #2). Each entry consists of: •
oldDeviceID (M) DeviceID - the device that left the call. This information should be consistent with the subject device in the event that represented the device leaving the call. For example: the divertingDevice provided in the Diverted event for that redirection, the transferring device in the Transferred event for a transfer, or the clearing device in the Connection Cleared event. This device identifier type may be one of the following: •
of any device identifier format (see Clause 10, “CSTA Device Identifier Formats”, on page 102 for more information). - 120 -
•
“Not Known” - indicates that the device identifier associated with this entry in the DeviceHistory list cannot be provided.
•
“Restricted” - indicates that the device associated with this entry in the DeviceHistory list cannot be provided due to regulatory and/or privacy reasons.
•
“Not Required” - indicates that there are no devices that have left the call. If this value is provided, it shall be provided as the only entry in the list and the eventCause and oldConnectionID shall not be provided with this list entry.
•
“Not Specified” - indicates that the switching function cannot determine whether or not any devices have previously left the call. If this value is provided, it shall be provided as the only entry in the list and the eventCause and oldConnectionID shall not be provided with this list entry.
•
eventCause (O) EventCause - the reason the device left the call or was redirected. This information should be consistent with the eventCause provided in the event that represented the device leaving the call (for example, the cause code provided in the Diverted, Transferred, or Connection Cleared event).
•
oldConnectionID (O) ConnectionID - the CSTA connectionID that represents the last connectionID associated with the device that left the call. This information should be consistent with the subject connection in the event that represented the device leaving the call (for example, the connectionID provided in the Diverted, Transferred, or Connection Cleared event).
Functional Requirements 1. The last entry in the list represents the last device that left the call. 2. If a resulting call is being formed (due to a transfer or conference, for example) from one or more calls with different DeviceHistory parameters, the DeviceHistory for each of the old calls should be combined and associated with the resulting call. The ordering of the DeviceHistory for the "combined" call is switching function specific. 3. The switching function can indicate the maximum number of entries of the DeviceHistory parameter type in the response Get Switching Function Capability service. If the switching function supports this parameter and the length of the DeviceHistory is exceeded, it is switching function-dependent which entries are included in the parameter. 4. A device may be associated with a call outside the CSTA switching sub-domain. This may become known to the CSTA switching function through information provided by the external network (using protocol specific information elements). Such devices may be added to the DeviceHistory list if their association with the call is known to the switching function. 12.2.14 ErrorValue The ErrorValue parameter type defines error codes. Format This parameter contains the following: •
Error Category - Operation, Security, State Incompatibility, System Resource Availability, Subscribed Resource Availability, Performance Management, Private Data, Private Error Code, and Unspecified.
•
Error Value - A value describing the error. The following text describes the various categories and values within each category.
Note that the error code hierarchy described in Figure 9-1, “ErrorValue Hierarchy,” on page 98 is represented by indented bullet lists in the following sections, each indent representing an additional error code level. - 121 -
12.2.14.1 Operation Errors Error values in this category shall indicate an error in the Service Request. This category shall include one of the following specific error values: •
generic - The server has detected an operational error in the service request and the error is either not a specified Operation Class error or the switching function cannot be more specific. •
atLeastOneConditionalParameterNotProvided - The service definition specifies a set of conditional parameters, at least one of which shall be provided. No parameter from this set was present.
•
featureAlreadySet - The feature cannot be set because it is already set.
•
invalidMessageIdentifier - There is no message with the specified Message Identifier.
•
invalidParameterValue - A value for a parameter is invalid. A value is in the specified range but invalid in the circumstance where it is used. •
invalidAccountCode - The account code parameter is invalid.
•
invalidAgentGroup - An agent group is invalid.
•
invalidAgentIdentifier - An agent identifier is invalid.
•
invalidAgentPassward - An agent password is invalid.
•
invalidAgentState - An agent state setting is invalid.
•
invalidAlertTime - The alertTime parameter is invalid.
•
invalidAllocationState - The service request (MakePredictiveCall) specified an allocation state that is invalid in the present circumstance.
•
invalidAuthorizationCode - The authorization code is invalid.
•
invalidAutoAnswer - The autoanswer parameter is invalid.
•
invalidBitRate - The bitRate parameter is invalid.
•
invalidButtonIdentifier - A button identifier is invalid.
•
invalidButtonLabel - A button label is invalid.
•
invalidCallType - The callType parameter is invalid.
•
invalidConnectionRate - The connectionRate parameter is invalid.
•
invalidConsultPurpose - The consultPurpose parameter is not valid.
•
invalidCorrelatorData - The Correlator Data parameter is not valid.
•
invalidCrossReferenceIdentifier - The service request specified a Cross Reference Identifier that is not in use.
•
invalidDelayTolerance - The delayTolerance parameter is invalid.
•
invalidDestination - The service request contains a destination that is invalid. Note that for a forwarding destination, the switching function returns the invalidForwardingDestination error. This occurs when the calledDirectoryNumber, newDestination, or routeSelected parameter is invalid.
•
invalidDestinationDetect - the destinationDetect parameter is invalid.
•
invalidDoNotDisturb - The do not disturb setting is invalid.
•
invalidEscapeCrossReferenceIdentifier - The escape registration request identifier is invalid.
- 122 -
•
•
invalidFeature - The service request specified a feature that is invalid. Often, this is because the switching or computing function does not support the requested feature.
•
invalidFile - The specified file is not accessible.
•
invalidFlowDirection - The flowDirection parameter is invalid.
•
invalidForwardingDestination - The forwarding destination device is not valid.
•
invalidForwardingFlag - The forwarding flag is invalid.
•
invalidForwardingType - The forwarding type is invalid.
•
invalidHookswitchType - A hookswitch type is invalid.
•
invalidHookswitchComponent - A hookswitch component is invalid.
•
invalidLampIdentifier - A lamp identifier is invalid.
•
invalidLampMode - A lamp mode is invalid.
•
invalidMessageWaitingSetting - A message waiting setting is invalid. The switching function returns this error for the messageWaitingOn parameter.
•
invalidMicrophoneGain - A microphone gain setting is invalid.
•
invalidMicrophoneMute - A microphone mute setting is invalid.
•
invalidMonitorCrossReferenceIdentifier - The service request specified a monitor cross reference identifier that is not in use.
•
invalidMonitorFilter - The monitor filter is invalid.
•
invalidMonitorObject - The monitor object is invalid.
•
invalidMonitorType - The monitor type is invalid.
•
invalidNumberOfChannels - The numberOfChannels parameter is invalid.
•
invalidParticipationType - The participationType parameter is invalid.
•
invalidRemainRetry - The value of the remainRetry parameter is invalid.
•
invalidRingCount - The ring count setting is invalid.
•
invalidRingPattern - A ring pattern setting is invalid.
•
invalidRingVolume - A ring volume setting is invalid.
•
invalidRouteingAlgorithm - The computing function does not support the routeing algorithm.
•
invalidRouteingCrossReferenceIdentifier - The service request specified a routeing cross reference identifier that is not in use.
•
invalidRouteRegistrationCrossReferenceIdentifier - The route registration request identifier is invalid.
•
invalidSpeakerVolume - A speaker volume is invalid.
•
invalidSpeakerMute - A speaker mute setting is invalid.
•
invalidSwitchingSubdomainCharsType - The switchingSubDomainCCIEType parameter is invalid.
invalidObjectType - A parameter in the service request contains an object type that is not the defined object type for that parameter. •
invalidActiveCallObject - The value supplied for activeCall or one of its components is not of the proper type. - 123 -
•
invalidCalledDeviceObjectType - The value supplied for calledDevice is not of the proper type.
•
invalidCallingDeviceObjectType - The value supplied for callingDevice is not of the proper type.
•
invalidCallToBePickedUpObjectType - The value supplied for callToBePickedUp or one of its components is not of the proper type.
•
invalidCallToDivertObjectType - The value supplied for callToBeDiverted is not of the proper type.
•
invalidCallToParkObjectType - The value supplied for callToPark or one of its components is not of the proper type.
•
invalidDestinationDeviceObject - The value supplied for newDestination in a or one of its components is not of the proper type.
•
invalidHeldCallObject - The value supplied for heldCall or one of its components is not of the proper type.
•
invalidMonitorObjectType - The monitorObject type is invalid.
•
invalidParkToObjectType - The value supplied for r parkTo is not of the proper type.
•
messageIdentifierRequired - The request requires a Message Identifier.
•
notDifferentDevices - Multiple parameters in the service request that shall specify different devices do not specify different devices.
•
notSameDevice - Multiple parameters in the service request that shall specify the same device do not specify the same device.
•
objectNotKnown - An object parameter (connection, device, or call) has a value that is not known. •
•
•
invalidCallIdentifier - A call identifier parameter or a call identifier component of a connection identifier parameter is invalid or is not known to the switching function. •
invalidActiveCallIdentifier - The call identifier in the activeCall connection does not specify a valid call.
•
invalidHeldCallIdentifier - The call identifier in the heldCall connection does not specify a valid call.
invalidConnectionIdentifier - A connection identifier or some component of the connection identifier is invalid. •
invalidActiveConnectionIdentifier - The activeCall connection does not specify a valid call.
•
invalidHeldConnectionIdentifier - The heldCall connection does not specify a valid call.
invalidDeviceIdentifier - A device identifier parameter or a device identifier component of a connection identifier parameter is invalid or is not known to the switching function. •
invalidActiveDeviceIdentifier - The device identifier in the activeCall connection does not specify a valid device.
•
invalidCalledDeviceIdentifier - The called device parameter is invalid.
•
invalidCallingDeviceIdentifier - The calling device parameter is invalid.
- 124 -
•
•
invalidCallToParkDeviceIdentifier - The device identifier in the callToPark connection does not specify a valid device.
•
invalidDestinationDeviceIdentifier - The device identifier in the newDestination does not specify a valid device.
•
invalidDivertingDeviceIdentifier - The diverting device identifier is invalid.
•
invalidHeldDeviceIdentifier - The device identifier in the heldCall connection does not specify a valid device.
•
invalidParkToDeviceIdentifier - parkTo does not specify a valid device.
•
invalidPickUpDeviceIdentifier - The device identifier in the callToBePickedUp does not specify a valid device.
parameterNotSupported - The switching function does not support a parameter. •
accountCodeNotSupported - The accountCode parameter is not supported.
•
agentGroupNotSupported - The agent group parameter is not supported.
•
agentPasswordNotSupported - The agent password parameter is not supported.
•
agentStateNotSupported - The agent state is not supported.
•
alertTimeNotSupported - The alertTime parameter is not supported.
•
allocationNotSupported - The allocation parameter is not supported.
•
authorisationCodeNotSupported - The authorization code is not supported.
•
autoAnswerNotSupported - The autoAnswer parameter is not supported.
•
bitRateNotSupported - The bitRate parameter is not supported.
•
buttonNotSupported - The button parameter is not supported.
•
callTypeNotSupported - The callType parameter is not supported.
•
charactersToSendNotSupported - The charactersToSend parameter is not supported.
•
connectionRateNotSupported - The connectionRate parameter is not supported.
•
connectionReservationNotSupported. supported.
•
consultPurposeNotSupported - The consultPurpose parameter is not supported.
•
correlatorDataNotSupported - The correlator data parameter is not supported.
•
delayToleranceNotSupported - The delayTolerance parameter is not supported.
•
destinationDetectNotSupported - The destinationDetect parameter is not supported.
•
digitModeNotSupported - The digitMode parameter is not supported.
•
errorValueNotSupported - The errorValue parameter is not supported.
•
flowDirectionNotSupported - The flowDirection parameter is not supported.
•
forwardingDestinationNotSupported - The forwarding destination parameter is not supported.
•
lampNotSupported - The lamp parameter is not supported.
•
monitorTypeNotSupported - The monitor type is not supported.
•
numberOfChannelsNotSupported - The numberOfChannels parameter is not supported.
•
parameterTypeNotSupported - The participationType parameter is not supported. - 125 -
The
connectionReservation
parameter
is
not
•
•
priorityNotSupported - The priority parameter is not supported.
•
privateDataNotSupported - The privateData parameter is not supported.
•
pulseDurationNotSupported - The pulseDuration parameter is not supported.
•
pulseRateNotSupported - The pulseRate parameter is not supported.
•
remainRetryNotSupported - The remainRetry parameter is not supported.
•
ringCountNotSupported - The ringCount parameter is not supported.
•
routeUsedNotSupported - The routeUsed parameter is not supported.
•
securityNotSupported - The security parameter is not supported.
•
switchingSubDomainCCIETypeNotSupported parameter is not supported.
•
toneDurationNotSupported - The toneDuration parameter is not supported.
•
securityNotSupported - The security parameter is not supported.
•
sysStatRegIDNotSupported - The sysStatRegID parameter is not supported.
•
userDataNotSupported - The userData parameter is not supported.
-
The
switchingSubDomainCCIEType
privilegeViolationSpecifiedDevice - Performing the service request would result in a privilege violation. •
privilegeViolationActiveDevice - The request would violate a switching function restriction on the device activeCall that limits the device in some way.
•
privilegeViolationCalledDevice - Performing the service request would violate a switching function restriction that limits the called device in some way.
•
privilegeViolationCallingDevice - Performing the service request would violate a switching function restriction that limits the calling device in some way.
•
privilegeViolationCallToParkDevice - The service request would violate a switching function restriction on the device in callToPark connection that limits the device in some way.
•
privilegeViolationDestinationDevice - The request would violate a switching function restriction on the device newDestination that limits the device in some way.
•
privilegeViolationOnDivertingDevice - The service request would violate a switching function restriction on the diverting device in some way.
•
privilegeViolationHeldDevice - The request would violate a switching function restriction on the device in heldCall that limits the device in some way.
•
privilegeViolationOnParkToDevice - The service request would violate a switching function restriction on the device parkTo that limits the device in some way.
•
privilegeViolationPickupDevice - The request would violate a switching function restriction on the device in callToBePickedUp that limits the device in some way.
•
routeingTimerExpired - The routeing timer or delayed ringback timer expired for a routeing request.
•
requestIncompatibleWithObject - The service request is not compatible with the corresponding object specified in the service request. This error shall not reflect state incompatibility errors of an object. •
requestIncompatibleWithConnection - The service request is not compatible with a connection specified in the service definition. - 126 -
•
•
requestIncompatibleWithActiveConnection - The request is incompatible with the activeCall connection.
•
requestIncompatibleWithHeldConnection - The request is incompatible with the heldCall connection.
requestIncompatibleWithDevice - The service request is not compatible with a device specified in the service request. •
requestIncompatibleWithCalledDevice - The service request is not compatible with the called device.
•
requestIncompatibleWithCallingDevice - The service request is not compatible with the calling device.
•
requestIncompatibleWithSubjectDevice - The service request is not compatible with the subject device (not a called or calling device). •
requestIncompatibleWithActiveDevice - The service request is incompatible with the device in the activeCall connection.
•
requestIncompatibleWithCallToParkDevice - The service request is not compatible with the device in callToPark connection.
•
requestIncompatibleWithDestinationDevice - The service request is incompatible with the device in the newDestination connection.
•
requestIncompatibleWithDivertingDevice - The service request is incompatible with the device in the callToBeDiverted connection.
•
requestIncompatibleWithHeldDevice - The service request is incompatible with the device in the heldCall connection.
•
requestIncompatibleWithMedia - The media type associated with the message is incompatible with the associated device.
•
requestIncompatibleWithParkToDevice - The service request is not compatible with parkTo.
•
requestIncompatibleWithPickupDevice - The service request is incompatible with the device in the callToBePickedUp connection.
•
serviceNotSupported - The service is not supported.
•
securityViolation - The service request violates security.
•
valueOutOfRange - A parameter (other than a CSTA object) has a value that is not in the enumeration or range specified for that parameter. •
agentStateOutOfRange - An agent state is not one of the defined values.
•
alertTimeOutOfRange - The alertTime parameter has a value that is out of its permitted range.
•
allocationOutOfRange - The allocation parameter has a value that is out of its permitted range.
•
autoAnswerOutOfRange - The autoAnswer parameter has a value that is out of range.
•
bitRateOutOfRange - The bitRate parameter value is out of the defined range.
•
callTypeOutOfRange - The callType parameter value is out of the defined range.
•
connectionRateOutOfRange - The connectionRate parameter value is out of the defined range. - 127 -
•
connectionReservationOutOfRange - The connectionReservation parameter has a value that is out of range.
•
consultPurposeOutOfRange - The consultPurpose parameter has a value that is out of its permitted range.
•
correlatorDataOutOfRange - The length of the correlator data exceeds the maximum length that the switching function supports.
•
delayToleranceOutOfRange - The delayTolerance parameter is out of the defined range.
•
destinationDetectOutOfRange - The destinationDetect parameter has a value that is out of its permitted range.
•
digitModeOutOfRange - The digitMode parameter value is out of the defined range.
•
doNotDisturbOutOfRange- The do not disturb setting in the doNotDisturb parameter is out of range.
•
flowDirectionOutOfRange - The flowDirection parameter is out of the defined range.
•
forwardingFlagOutOfRange - The forwarding flag is out of range.
•
forwardingTypeOutOfRange - The forwardingType parameter is not one of the defined values.
•
hookswitchComponentOutOfRange - A hookswitch component is not one of the defined components.
•
hookSwithTypeOutOfRange - A hookswitch type is out of range.
•
lampModeOutOfRange - A lamp mode setting is out of range.
•
messageWaitingSettingOutOfRange - A message waiting setting is out of range. The switching function returns this error for the messageWaitingOn parameter.
•
micGainOutOfRange - A microphone gain setting is out of range.
•
micMuteOutOfRange - A microphone mute setting is out of range.
•
monitorTypeOutOfRange - The monitor type is not a defined value.
•
numberOfChannelsOutOfRange - The numberOfChannels parameter is out of the defined range.
•
participationTypeOutOfRange - the participationType parameter has a value that is out of range.
•
pulseDurationOutOfRange- The pulseDuration parameter value is out of range.
•
pulseRateOutOfRange - The pulseRate parameter value is out of range.
•
ringCountOutOfRange - The ring count is out of range.
•
ringPatternOutOfRange - A ring patterns setting is out of range.
•
ringVolumnOutOfRange - A ring volume is out of range.
•
routingAlgorithmOutOfRange - The routeSelAlgorithm is not one of the defined values.
•
speakerMuteOutOfRange - A speaker mute setting is out of range.
•
speakerVolumeOutOfRange - A speaker volume is out of range.
•
switchingCcittType - The switchingSubDomainCCIEType parameter is out of the defined range.
•
systemStatusOutOfRange - The system status is not one of the defined values. - 128 -
•
toneCharacterOutOfRange - One of more characters in the charctersToSend parameter is not in the permitted set.
•
toneDurationOutOfRange - The toneDuration parameter value is out of range.
12.2.14.2 Security Errors Error values in this category shall indicate a security error. This category shall include one of the following specific error values: •
generic - This is a general purpose value that can be used when the server is unable to be any more specific about the cause of the error. •
sequenceNumberViolated - Indicates that the server has detected an error in the operation’s message sequence number.
•
timeStampViolated - Indicates that the server has detected an error in the operation’s time stamp.
•
securityInfoViolated - Indicates that the server has detected an error in the operation’s security data.
12.2.14.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 category shall include one of the following specific error values: •
generic - This is a general purpose value that can be used when the server is unable to be any more specific about the cause of the error. •
invalidObjectState - An object (device, connection, call, message) is in an incorrect state for the service. This error value may be used when the server cannot be any more specific. •
•
invalidDeviceState - A device object is in an incorrect state for the service request. •
connectedCallExists - A physical element is already associated with another connection in the connected state.
•
invalidActiveDeviceState - The device in activeCall or callToBePickedUp connection is not in the correct state.
•
invalidCalledDeviceState - The device in the calledDevice connection is not in the correct state.
•
invalidCallingDeviceState - The device in the callingDevice connection is not in the correct state.
•
invalidCallToParkDeviceState - The device in the callToPark connection is not in the correct state.
•
invalidDestinationDeviceState - The newDestination device is not in the correct state.
•
invalidDivertingDeviceState - The diverting device is not in a correct state.
•
invalidHeldDeviceState - The device in heldCall connection is not in the correct state.
•
invalidParkToDeviceState - The parkTo device is not in the correct state.
invalidConnectionState - A connection object is in an incorrect state for the service request. •
invalidActiveConnectionState - The activeCall connection is not in the correct state.
•
invalidConnectionIdentifierForActiveCall - A Connection Identifier specified as the activeCall in the service request is not in the correct state.
•
invalidHeldConnectionState - The heldCall connection is not in the correct state.
- 129 -
•
•
noActiveCall - The service request operates on an active call, but there was no active call.
•
noCallToAnswer - There is no call active for the connection identifier specified as the callToBeAnswered.
•
noCallToClear - There is no call associated with the connection identifier of the Clear Call request.
•
noCallToComplete - There is no call active for the connection Identifier specified as the callToBeCompleted.
•
noConnectionToClear - There is no connection for the connection identifier specified as the connectionToBeCleared.
•
noHeldCall - The service request operates on a held call, but the specified call was not in the Hold state.
incorrectMessageState - A message object is in an incorrect state for the service. •
beginningOfMessage - The message pointer is at the beginning of the message.
•
endOfMessage - The message pointer is at the end of the message.
•
messageSuspended - The specified message is already suspended on the same Connection.
•
notAbleToPlay - The specified message exists, but cannot be played.
•
notAbleToResume - The specified message cannot be resumed.
12.2.14.4 System Resource Availability Errors Error values in this category shall indicate that the service request could not be fulfilled because of a lack of system resources within the serving sub-domain. This category shall include one of the following specific error values: •
generic - This is a general purpose value that can be used when the server is unable to be any more specific about the cause of the error. •
resourceBusy - The service is supported by the server, but is unavailable due to a resource that is busy. •
• •
internalResourceBusy - An internal resource is in use. •
classifierBusy - All available classifiers are in use.
•
noMediaChannelsAvailable - There are no available media stream channels to complete the request. •
channelsInUseForBridgedDevices - All applicable media stream channels are in use by other devices associated in a bridged device configuration.
•
channelsInUseForData - All applicable media stream channels are in use for digital data connections.
•
toneDetectorBusy - All available tone detectors are in use.
•
toneGeneratorBusy - All available tone generators are in use.
networkBusy - The server sub-domain is busy.
resourceOutOfService - The service is supported by the server, but is unavailable due to a resource that is out of service. •
deviceOutOfService - A device that is needed to carry out the service is out of service.
- 130 -
•
•
activeDeviceOutOfService - The device specified in activeCall connection is out of service.
•
calledDeviceOutOfService - The device specified in the calledDevice connection is out of service.
•
callingDeviceOutOfService - The device specified in the callingDevice connection is out of service.
•
callToParkDeviceOutOfService - The device specified in callToPark connection is out of service.
•
destinationDeviceOutOfService - The newDestination device is out of service.
•
divertingDeviceOutOfService - The device specified as the diverting device is out of service.
•
heldDeviceOutOfService- The device specified in heldCall connection is out of service.
•
parkToDeviceOutOfService - The device specified in parkTo is out of service.
•
pickupDeviceOutOfService - The device in callToBePickedUp is out of service.
•
divertingDeviceOutOfService - The device specified as the diverting device is out of service.
•
networkOutOfService - The server sub-domain is Out Of Service.
•
otherResourceOutOfService - Some resource needed to carry out the service other than the above is out of service.
resourceLimitExceeded - The service is supported by the server, but is unavailable because it would exceed the internal usage limit of the resource. •
overallMonitorLimitExceeded - The service request would exceed a switching function limit on the number of monitors (either an overall limit on the aggregate number of monitors or a limit on the number of monitors of different types (device-type, call-type) or some combination of the two).
•
conferenceMemberLimitExceeded - The requested service would exceed the server’s limit on the number of members of a conference.
•
registrationLimitExceeded - This service would exceed the switching function’s maximum number of registrations.
•
conferenceResourceCannotBeSatisfied - The requested service includes a parameter that cannot be satisfied. •
maxDevicesExceeded - The maxDevices parameter is too large.
•
startTimeOutOfRange- The startTime parameter is out of range (i.e. too far in the future).
•
durationExceeded - The duration parameter is too large.
12.2.14.5 Subscribed Resource Availability Errors Error values in this category shall indicate that the service request could not be fulfilled because a required resource must be purchased or contracted by the client system. This category shall include one of the following specific error values: •
generic - This is a general purpose value to be used when the server is unable to be any more specific about the cause of the error.
- 131 -
•
objectMonitorLimitExceeded - The service request would exceed the server’s limit of monitors for the specified object.
•
trunkLimitExceeded - The service request would exceed the server’s limit of trunks.
•
outstandingRequestsLimitExceeded - The service request would exceed the servers’s limit on the number of outstanding service requests.
•
objectRegistrationLimitExceeded - This service request would exceed the switching function’s limit on the number of registrations for this device.
12.2.14.6 Performance Management Errors Error values in this category shall indicate that an error has been returned as a performance management mechanism. This category shall include one of the following specific error values: •
generic - This is a general purpose value to be used when the server is unable to be any more specific about the cause of the error. •
performanceLimitExceeded - A performance limit has been exceeded.
12.2.14.7 Private Data Information Errors Error values in this category shall indicate an error in the CSTA Private Data Information. The reason(s) why the Private Data Information is incorrect is not relevant to this Standard. This category shall include the following specific error value: •
cSTAPrivateDataInfoError - An error occurred in the privateData parameter. The reason for this error is implementation specific.
12.2.14.8 Private Error Code Error values in this category shall indicate a vendor specific error. This category shall include a vendor specific character string indicating a vendor specific error. 12.2.14.9 Unspecified Errors Error values in this category shall indicate that the error did not belong to any of the other error value categories. This category shall include the following error value: •
unspecifiedError - Some error other than those covered by the error categories has occurred or server cannot determine the category of the error.
12.2.15 EventCause The EventCause parameter type provides additional information on why an event was generated. Format Event causes are defined within the context of an event. For a description of an event cause refer to the event cause description associated with a specific event. This parameter type contains one of the following event causes: •
ACD Busy
•
ACD Forward
•
ACD Saturated
•
Activation
•
Active Participation
•
Alert Time Expired
•
Alternate
•
Auto Work - 132 -
•
Babble
•
Bad Attribute
•
Bad Grammar
•
Bad Voice
•
Bad URI
•
Blocked
•
Busy
•
Busy Overflow
•
Calendar Overflow
•
Call Back
•
Call Cancelled
•
Call Forward
•
Call Forward - Busy
•
Call Forward - Immediate
•
Call Forward - No Answer
•
Call Interception
•
Call Interception - Busy
•
Call Interception - Forwarded
•
Call Interception - No Answer
•
Call Interception - Resources Not Available
•
Call Not Answered
•
Call Pickup
•
Camp On
•
Camp On Trunks
•
Capacity Overflow
•
Character Count Reached
•
Conference
•
Consultation
•
Destination Detected
•
Destination Not Obtainable
•
Destination Out of Order
•
Distributed
•
Distribution Delay
•
Do Not Disturb
•
DTMF Digit Detected
•
Duplicate DTMF
•
Duration Exceeded - 133 -
•
Early Stop
•
Empty Queue
•
End of Message Detected
•
Entering Distribution
•
Forced Pause
•
Forced Transition
•
Incompatible Destination
•
inter-digit Timeout
•
Intrude
•
Invalid Account Code
•
Invalid Connection
•
Invalid Connection State
•
Invalid Number Format
•
Join Call
•
Key Operation
•
Key Operation In Use
•
Lawful Interception
•
Lockout
•
Maintenance
•
Make Call
•
Make Connection
•
Make Predictive Call
•
Max Timeout
•
Message Duration Exceeded
•
Message Size Exceeded
•
Multiple Alerting
•
Multiple Queuing
•
Network Congestion
•
Network Dialling
•
Network Not Obtainable
•
Network Out of Order
•
Network Signal
•
New Call
•
Next Message
•
No Audio Saved
•
No Available Agents
•
No Queue - 134 -
•
Normal
•
Normal Clearing
•
No Rule
•
No Speech Detected
•
Not Available Bearer Service
•
Not Supported Bearer Service
•
Number Changed
•
Number Unallocated
•
Out Of Grammar
•
Overflow
•
Override
•
Park
•
Path Replacement
•
Queue Cleared
•
Queue Time Overflow
•
Recall
•
Recall - Busy
•
Recall - Forwarded
•
Recall - No Answer
•
Recall - Resources Not Available
•
Redirected
•
Remains in Queue
•
Reorder Tone
•
Reserved
•
Resources Not Available
•
Selected Trunk Busy
•
Silent Participation
•
Single Step Conference
•
Single Step Transfer
•
Speech Detected
•
Suspend
•
Switching Function Terminated
•
Termination Character Received
•
Timeout
•
Transfer
•
Trunks Busy
•
Unauthorized Bearer Service - 135 -
•
Unknown Overflow
Functional Requirements 1. Event causes are only present in events that result from the feature/situation associated with the meaning of the cause. Once that feature or situation ceases to be active, then the event cause is no longer present in the events. 12.2.16 LanguagePreferences The LanguagePreferences parameter type describes one or more preferred languages associated with the call. Format The parameter type is a character string. The string consists of one or more language tags that indicate the preferred languages associated with the call. The syntax of the language tag is specified in IETF RFC 3066. Each language tag is space separated.
Examples: •
“en” indicates that English is the preferred language.
•
“en de nl” indicates that the preference for the following languages, in priority order: English, German, and Dutch.
Functional Requirements 1. The language preference may become associated with a call in a number of ways. For example: •
it can be provided via the underlying call control protocol signalling.
•
it can be specified on the CSTA service that creates a call (e.g. Make Call service).
•
it can be associated with a call when a CSTA feature is applied to a call (e.g. Single Step Transfer Call).
•
it can be associated with an existing call via the Associate Data service.
2. The language preference can be changed (or cleared by providing a null string) during the life of the call by any of the services that includes the parameter including the Associate Data service. The language preference can also be changed by the underlying call control protocol specific signaling. 3. If a resulting call is being formed (due to a transfer or conference, for example) from one or more calls with different language preferences, the language preferences for each of the old calls shall be combined and associated with the resulting call. The ordering of the language tags for the "combined" call is switching function specific. 12.2.17 LocalConnectionState The LocalConnectionState parameter type describes the connection state of the device associated with the Monitor Cross Reference ID. This parameter type is only applicable for events generated by device-type monitors. Format This parameter type shall contain one of the following connection states: •
Alerting
•
Connected - 136 -
•
Fail
•
Hold
•
Initiated
•
Null
•
Queued
Refer to 6.1.3, “Connection”, for detailed descriptions of the connection states. Example The following is a scenario that illustrates the usage of this parameter. Consider the case of a two device call where device one has called device two, and device two is ringing. If both devices are monitored, then the switching function generates two separate (Delivered) events to indicate that the call has been delivered. While the subject device is identical for both Delivered events, the localConnectionInfo parameters are different. •
Both events contain the same subject device, device two in this case, since that is the device in the call being alerted.
•
The connection state for device one is connected (most likely listening to ringback). This is reported in the localConnectionInfo parameter of the Delivered event for device one.
•
The connection state for device two is alerting. This is reported in the localConnectionInfo parameter of the Delivered event for device two.
12.2.18 LocationInfo The CSTA LocationInfo parameter type contains a PIDF-LO (Presence Information Data Format Location Object) for carrying location information as defined in IETF RFC-4119 as updated by IETF RFC5139. Location information in a PIDF-LO is contained in a GEOPRIV element. The GEOPRIV element consists of the following elements: •
location-info - consisting of one or more chunks - each chunk can be either in GML format or civic address format as discussed in 6.8.1.1. Note that when two chunks are provided in a location-info element that corresponds to the same place, this is referred to as a compound location.
•
usage-rules - associated with the location info (retransmissions-allowed, retention-expires, rulesetreference)
•
method - how location info was derived or discovered (e.g. GPS)
•
provided-by - source of the location info to provide additional information to locate service providers in case of problems with the location info.
A GEOPRIV element can be associated with a person or a device (or a generic tuple) using the data model in RFC-4479. There can be multiple GEOPRIV elements in a single PIDF-LO. For example: •
For a CSTA user with 2 devices, location information in a single PIFDF-LO may be in three GEOPRIV elements: one contained in a person element, one contained in a device element (for a cell phone), and one contained in another device element (for an office phone).
•
For a CSTA device such as an office phone, location information may be in a single GEOPRIV element contained in device element. The GEOPRIV location-info element contains two chunks of location information - one that specifies a location using Geospatial format and one that contains an office number as a civic address type that augments the Geospatial information. - 137 -
•
For a CSTA group-device consisting of 3 member devices, location information may be in three GEOPRIV elements each contained in separate device elements.
Format The data in a PIDF-LO is specified by the schemas published in RFC-4119 and RFC-4479. Functional Requirements: 1. RFC-4119 (or its replacement RFC) shall be used to specify the usage and interpretation of the information in this parameter type. 2. Location Information should be secured. The mechanism to secure this information (XML element level encryption, digital signature properties, etc.) is outside the scope of CSTA. 3. In order to remove some of the ambiguity interpreting data in an PIDF-LO and to improve interoperability there are two CSTA PIDF-LO Profile options to interpret the data in a PIDF-LO. a. PIDF Profile Option 1 - the rules and guidelines as specified in IETF RFC-5491 shall be followed. This includes applying the rules 1, 3, 5, and 7 as normative rules and 2, 4, 6, 8, and 9 as informative guidelines. b. PIDF Profile Option 2 - in order to reduce ambiguity even further, the rules and guidelines 1-9 as specified in RFC-5491 shall be applied as normative rules. The Start Location Tracking Service response provides a parameter that indicates which PIDF-LO Profile option is supported by the switching function for the specific location tracking session. 12.2.19 LocationInfoList The LocationInfoList parameter type provides a sequence of one or more Presence Information Data Format - Location Objects (PIDF-LO) as defined in 12.2.18, “LocationInfo”. This parameter type is used when multiple PIDF-LO are provided in a CSTA parameter. For example in call control events when location information is provided for multiple devices in a call. 12.2.20 MediaCallCharacteristics The MediaCallCharacteristics parameter type specifies the media (voice, digital data, etc.) characteristics of the call. Format This parameter type is comprised of the following: 1. mediaClass (M) Bitmap - Specifies the media class (voice, digital data, etc.). A CSTA call shall belong to at least one and may belong to more than one of the following classes: •
Audio - 3.1 KHz audio. Calls in this class involve devices that are used to make audio calls excluding speech calls. This includes calls involving devices such as G3 FAX and facsimile machines.
•
Chat - A type of Data class call that involves text-based messages that are exchanged between devices in the call using electronic media. A chat call is interactive since devices in the call can participate at the same time (i.e. originate and receive messages during the call.) The Data class bit must also be set for a Chat call.
•
Data - This class of calls involve digital data calls (both circuit switched and packet switched). Calls in this class include devices such as digital computer interfaces and G4 facsimile machines.
- 138 -
•
Email - This class of calls involve a text-based message that is sent using electronic media. This is a non-interactive call (i.e. only one device involved with the call at one time). This is a specific type of mediaClass associated with electronic mail systems.
•
Image - Digital data calls involving imaging, or high-speed, circuit-switched data in general. This includes calls involving devices such as digital video telephones and CODECs.
•
IM (Instant Message) - This class of calls involve a text-based message that is sent using electronic media. This is a non-interactive call (i.e. only one device is involved with the call at one time). The message contents associated with these calls can usually be displayed on the called devices. This is a specific type of Message media class associate with Instant Messaging systems.
•
Message - This class of calls involve a text-based message that is sent using electronic media. This is a non-interactive call (i.e. only one device is involved with the call at one time). The message contents associated with these calls can usually be displayed on the called devices. Instant Messages (IM), Short Message Service (SMS) are examples of this mediaClass.
•
MMS (Multi-media Message Service) - This class of calls involve a text-based message that is sent using electronic media. This is a non-interactive call (i.e. only one device is involved with the call at one time). The message contents associated with these calls can usually be displayed on the called devices. This is a specific type of Message media class associated with MultiMedia Message Service systems.
•
SMS (Short Message Service) - This class of calls involve a text-based message that is sent using electronic media. This is a non-interactive call (i.e. only one device is involved with the call at one time). The message contents associated with these calls can usually be displayed on the called devices. This is a specific type of Message media class associate with Short Message Service systems.
•
Voice - Speech calls. This class of calls involves devices such as standard telephones.
•
Not Known - The media class is not known.
•
Other - A class of call not belonging to one of the specified mediaClass.
2. connectionRate (O) Value - The digital data connection rate of the call. The contents of this parameter is switching function specific (the capability exchange services may be used to obtain the list of possible values that are supported by the switching function). A value of zero (0) indicates that the type of media stream associated with the connection is digital data but the connection rate is unknown. 3. bitRate (O) Enumerated - The digital data bit rate of the call. If this parameter is not present, the bit rate of the call is a constant bit. The following is the complete set of possible values: •
Constant (Default) - A bit rate which ensures a dedicated bandwidth and a constant rate of media stream delivery.
•
Variable - A bit rate which may variable during the life of the call.
4. delayTolerance (O) Value - The digital data delay tolerance of the call. This parameter specifies the maximum amount of media stream delivery delay that will be toleranced for the call. If the bit rate is constant, then this value will indicate the actual amount of media stream delivery delay for the life of the call. Where as if the bit rate is variable, it will be the maximum delay allowed during the life of the call. The contents of this parameter is switching function specific, use the capability exchange services to obtain the list of possible values that are supported by the switching function. If this parameter is not present, the delay tolerance of the call is not known. 5. switchingSubDomainCCIEType (O) Enumerated - The type of switching sub-domain private call control information elements that are present in the switchingSubDomainInformationElements - 139 -
parameter. If this parameter is not present, there are no information elements associated with the call and the switchingSubDomainInformationElements parameter should be ignored. The following is the complete set of possible values: •
ISDN
•
ATM (B-ISDN)
•
ISO-Ethernet (TDM part only)
•
RSVP
•
SIP
•
Other (switching sub-domain specific)
6. switchingSubDomainInformationElements (C) Characters - These parameters contain the private information elements that are available from the switching sub-domain (as specified by switchingSubDomainCCIEType) which represents a specific set of information elements. The format, meaning and behaviour of these information elements are specific to the given switching function. This parameter is only present and mandatory when the switchingSubDomainCCIEType parameter is present. 12.2.21 MediaServiceType The mediaServiceType parameter type is used to indicate which media service is to be (or has been) attached to or detached from a particular call or connection that the computing function is controlling and/ or monitoring. Format This parameter type shall contain one of the following values: •
cstaVoiceUnit
•
dataModem
•
digitalDataIsochronousIeee1394
•
digitalDataIsochronousGeoport
•
digitalDataIsochronousIeeeAtm
•
digitalDataIsochronousIeeeIsdn
•
digitalDataAPI
•
ectfS100MediaServicesDefault
•
ectfS100MediaServicesASI
•
ivrScript1
•
ivrScript2
•
ivrScript3
•
ivrScript4
•
ivrScript5
•
ivrScript6
•
ivrScript7
•
ivrScript8
•
ivrScript9 - 140 -
•
ivrScript10
•
liveSoundCaptureAnalog
•
liveSoundTransmitAnalog
•
liveSoundCaptureIeee1394
•
liveSoundTransmitIeee1394
•
liveSoundCaptureTransmitGeoport
•
liveSoundCaptureTransmitAtm
•
liveSoundCaptureTransmitISDN
•
soundCaptureTransmitADPCM
•
soundCaptureTransmitApi
•
usb
•
sfSpecific1
•
sfSpecific2
•
sfSpecific3
•
sfSpecific4
•
sfSpecific5
•
sfSpecific6
•
sfSpecific7
•
sfSpecific8
•
sfSpecific9
•
sfSpecific10
Refer to Table 6-10 on page 75 for a description of these service types. 12.2.22 MessageInfo The MessageInfo parameter type specifies the message information associated with a call. The message information could consist of text to be displayed on a device (for an Instant Message) or the body and attachment parts associated with Email. Format The parameter type consists of a sequence of parts. Each part consists of the following: •
contentTypeAndSubtype (O) Characters. A character string indicating the IANA assigned media content type and subtype. If this component is omitted the default is “text/plain”.
•
contents (M) Characters. A sequence of characters representing the contents of the message part. A null-formatted contents parameter (the parameter is provided but is empty) in a CSTA event indicates that there is contents associated with this part but the contents is not being provided in this message. The CSTA Snapshot Call service can be used to obtain the specific message contents when it is needed.
•
contentsLength (O) Value. The length of the contents associated with this part (number of bytes).
12.2.23 MonitorFilter The MonitorFilter parameter type specifies the list of events that are filtered (not sent) for a specific monitor. - 141 -
Format The parameter type consists of a list of bitmaps, each entry corresponding to a category of events, each bit in each category corresponding to a CSTA event. If the bit is TRUE, then the event corresponding to the bit is filtered (not sent) for the monitor. The list of bitmaps include: •
call control events - bitmap of the call control events as specified in Table 17-150 on page 345.
•
call associated events - bitmap of the call associated events as specified in Table 18-26 on page 433.
•
media attachment events - bit map of the media attachment events as specified in Table 19-14 on page 454.
•
physical device events - bitmap of the physical device events as specified in Table 21-59 on page 514.
•
logical device events - bitmap of the logical device events as specified in Table 22-61 on page 567.
•
maintenance events - bit map of the maintenance events as specified in Table 23-1 on page 587.
•
voice events - bit map of the voice events as specified in Table 26-58 on page 663.
•
vendor specific (private) events - bit map of the vendor specific events as specified in Table 29-12 on page 726.
12.2.24 PresenceState The PresenceState parameter type indicates the presence state for the presence state services and events. Format The set of possible values is: •
available - the user is available
•
away - the user is temporarily away
•
busy - the user is busy
•
calling - occupied with a call
•
dnd - the user does not want to be disturbed (dnd = „Do Not Disturb“)
•
meeting - the user is in a meeting
•
offline - the user is offline
•
unknown (default)
•
vacation - the user is on leave
•
applicationSpecified0 through applicationSpecified10 - reserved for application specific presence state
Functional Requirements 1. The optional parameters place, mood and namedPresenceState are used with the PresenceState parameter and contain a detailed description in natural language. 12.2.25 ServicesPermitted The ServicesPermitted parameter type specifies the set of services that the switching function permits to be applied to a connection.
- 142 -
The servicesPermitted parameter (when provided in a call event) is similar to the localConnectionInfo parameter in that it applies to the services permitted for the connection at the monitored device. This parameter type is only applicable for events generated by device-type monitors. Format This parameter type is a list of bitmaps where each bit represents a service that can be applied to a connection. When a bit is set, the corresponding service is permitted. The following is the list of bitmaps (multiple bits may be set in this parameter): •
call control services - the call control services as specified in Table 17-1 on page 241.
•
call associated services - the call associated services as specified in Table 18-1 on page 417.
•
media attachment services - the media attachment services as specified in Table 19-1 on page 446.
•
routeing services - the routeing services as specified in Table 20-7 on page 464.
•
voice services - the voice services as specified in Table 26-1 on page 626.
Functional Requirements 1. This parameter indicates which of a subset of CSTA services are permitted. 2. When the servicesPermitted parameter is provided in an event, it applies to the connection at the monitored device. This may or may not be the same as the subject device. 3. If there are multiple connections at a device, the information reported in the servicesPermitted parameter may not accurately reflect all possible service restrictions and interactions between multiple connections at a device. 4. There may be situations in a switching function that cause a service to fail after being presented as permitted in the servicesPermitted parameter. This may be due to dynamic system and/or resource conditions that may cause service availability restrictions. The switching function shall provide the appropriate error code in the negative acknowledgement to the failed service request. 12.2.26 SimpleCallState The SimpleCallState parameter type indicates the main call states in simplified encoding. The semantics are identical to the sequence of connection states but they are represented by an item from the list below. Format This parameter type may contain one of the following: •
callNull
•
callPending
•
callOriginated
•
callDelivered
•
callDeliveredHeld
•
callReceived
•
callEstablished
•
callEstablishedHeld
•
callReceivedOnHold
•
callEstablishedOnHold
•
callQueued
- 143 -
•
callQueuedHeld
•
callFailed
•
callFailedHeld
•
callBlocked
12.2.27 SubjectOfCall The SubjectOfCall parameter type indicates the subject or intent of the call. For example, this could represent the contents of an Email subject line (for an Email call) or could represent the reason for a voice call, for example. Format This parameter type is a character string. The maximum length supported by the switching function is provided by the capability exchange services. 12.2.28 SystemStatus The SystemStatus parameter type indicates the reason for the System Status service request. Format The complete set of possible values are: •
Disabled - Existing Monitor Requests have been disabled. Other requests and acknowledgements also may be disabled, but negative acknowledgements should always be provided.
•
Partially Disabled - Some of the objects in the system can not be reached. Existing monitors on these objects will not provide events and computer requests targeting these objects will be rejected. This cause indicates to the receiving function that a degradation of service level may occur but not complete system disability. Automatic or manual actions may be taken to remedy the parts disabled.
•
Enabled - Requests and acknowledgements have been enabled. This usually occurs after a disruption or restart. This status cause is always sent after an Initializing cause has been sent and may be sent under other conditions. This status indicates that there are no outstanding monitors (existing monitors and their associated monitor cross reference identifiers are no longer valid).
•
Initializing - The system is initializing or restarting. This status indicates that a system is temporarily unable to respond to any requests. If provided, this status message is followed by an Enabled status message to indicate that the initialization process has completed.
•
Messages Lost - Requests and/or acknowledgements, including event reports, may have been lost.
•
Normal - May be sent at any time and indicates that the status is normal. This status has no effect on other Services.
•
Overload Imminent - The receiver is requested to take initiative to shed load.
•
Overload Reached - The requester may take initiative to shed load. This cause may be followed by Stop Monitor requests sent to the client and by rejections to additional service requests.
•
Overload Relieved - The overload condition has passed.
12.2.29 TimeInfo The TimeInfo parameter type provides the calendar date and the time of day. There are three possible value representations: as local time, coordinated universal time, or as local time with a time differential factor. All representations use a four character representation of the year.
- 144 -
Format This parameter type is based upon the GeneralizedTime as defined in ISO/IEC 8824. 12.2.30 UserData The UserData parameter type contains computing sub-domain to computing sub-domain data. Note that the capabilities exchange services return the maximum length of the user data for a switching function. User Data is described further in 6.1.2.4, “User Data”, on page 43. Also, refer to 12.2.10, “CorrelatorData”, on page 119. Annex B defines one possible mechanism for delivering user data through an external ISDN network. Format This parameter type is a sequence of characters. The maximum length supported by the switching function is provided via the capabilities exchange services. Functional Requirements 1. The ability to send User Data, the timing of when user data can be sent, and the size of user data, is dependent upon the switching function’s capabilities and the underlying network (such as ISDN). 2. Unlike correlator data, User Data is not attached to a call for the life of the call. User Data that has been associated with a primary or secondary call does not get retained with a resulting conference or transferred call. 3. The switching function reflects the delivery of User Data in the call control events that result from the switching function or network carrying out the call control activity with which the User Data was associated. When the switching function receives user data independent of call activity (i.e., Send User Information service), the User Data is provided in the Call Information event. 4. User data addresses a specific user in a call (e.g. the initially called device). The delivery and propagation of the user data to other devices inside the switching sub-domain in regards to features that apply to the call (e.g. forwarding, do not disturb) is switching function dependent. 5. When this data is being attached to a call through a service request, its association shall be completed prior to any state transitions resulting from the request. Thus any state transition events which contain this parameter shall contain the information passed on the request. 6. If a computing function issues a Snapshot Call service after a service request has been issued with this information, but prior to the switching function making any state transitions, it is switching function specific as to what will be returned in the positive acknowledgement with regards to this parameter.
- 145 -
12.3
Identifier Parameter Types Identifier parameter types specific to these specifications are summarized in the following table. Table 12-2 Identifier Parameter Types Summary Defined Parameter Type
Description
Pg.
12.3.1 AgentID
Identifies an ACD agent.
147
12.3.2 AssociatedCalledDeviceID
Describes the switching function’s internal representation of the originally called device in a call.
147
12.3.3 AssociatedCallingDeviceID
Describes the switching function’s internal representation of the calling device in the call when the calling device is outside the switching sub-domain (i.e., trunk number).
147
12.3.4 AuditoryApparatusID
Indicates the auditory apparatus containing the speaker whose volume has changed.
148
12.3.5 ButtonID
Specifies the button identifier on a device.
148
12.3.6 CalledDeviceID
Specifies the device to be called via a service. This parameter describes the originally called device associated with a call.
148
12.3.7 CallingDeviceID
Describes the calling device associated with the call.
149
12.3.8 CDRCrossRefID
Specifies the CDR services cross reference identifier.
149
12.3.9 ConnectionID
Describes a device’s connection in a given call.
149
12.3.10 DCollCrossRefID
Used to identify a specific data collection.
151
12.3.11 DeviceID
Identifies or represents a device in the switching function.
151
12.3.12 DisplayID
Specifies the display identifier on a device.
152
12.3.13 EscapeRegisterID
Used to identify an escape services registration.
152
12.3.14 HookswitchID
Used to specify the hookswitch to query at a specified device.
152
12.3.15 IOCrossRefID
Specifies the I/O services cross reference identifier.
152
12.3.16 IORegisterReqID
Used to identify an I/O services registration.
152
12.3.17 LampID
Specifies the lamp identifier.
153
12.3.18 MediaServiceInstanceID
Identifies a particular media access service instance (e.g., specific media access server or subsystem)
153
12.3.19 MediaStreamID
Specifies a media stream identifier that can be used to access an attached media service.
153
12.3.20 MessageID
Specifies a particular Voice Unit message.
153
12.3.21 MonitorCrossRefID
Specifies an identifier that is used to correlate an event to an established monitor.
153
12.3.22 NetworkCalledDeviceID
Specifies the called device information provided by the network for external incoming calls.
153
12.3.23 NetworkCallingDeviceID
Specifies the calling device information provided by the network for external incoming calls.
154
12.3.24 RedirectionDeviceID
Describes the last device known by the switching function from which the current call was routed.
154
12.3.25 ResourceID
Specifies a particular voice resource.
155
12.3.26 RingerID
Specifies the ringer identifier associated with a physical device
155
12.3.27 RouteingCrossRefID
References the routeing dialogues initiated by the switching function within a routeing registration.
155
12.3.28 RouteRegisterReqID
Identifies a routeing registration for which the computing function (acting as a routeing server) will receive routeing requests.
156
12.3.29 ServiceCrossRefID
Specifies an identifier that is used to correlate one service request to another service request.
156
12.3.30 SubjectDeviceID
Describes the device where a telephony event occurred or was invoked.
156
- 146 -
Table 12-2 Identifier Parameter Types Summary (concluded) Defined Parameter Type 12.3.31 SysStatRegisterID
12.3.1
Description Used to identify system status registration.
Pg. 157
AgentID The AgentID parameter type identifies an ACD agent. Format
12.3.2
This parameter type is a character string. The maximum length supported by the switching function is provided via the capabilities exchange services. AssociatedCalledDeviceID For outgoing external calls, the AssociatedCalledDeviceID parameter type specifies the Network Interface Device (e.g., trunk, CO Line) within the switching sub-domain that is associated with the called device. This parameter in mandatory on all events dealing with external outgoing calls. For incoming external calls, this parameter specifies a device within the switching sub-domain that is associated with the originally called device (such as a switching function internal representation of DNIS, for example). This parameter is optional on all events dealing with incoming external calls. Format and Status This device identifier type may be one of the following (see Clause 10, “CSTA Device Identifier Formats”, on page 102 for more information): •
a character string when using the Diallable Digits and the Switching Function Representation formats.
•
an integer value when using the Device Number format.
•
a value of “Not Known”.
Functional Requirements 1. A device identifier of this type will only be present when the switching sub-domain is using a network interface device for an external call; that is, the call is an External Outgoing or External Incoming call. 2. A device identifier of this type is not used to provide DNIS (Dialed Number Identification Service) or DID (Direct Inward Dialing) digit information or a string of digits that represents the called device. (This information is provided in the corresponding CalledDeviceID parameter.) 3. A device identifier of this type is set to “Not Known” when the switching function does not know the Network Interface Device associated with the called device. 4. A device identifier of this type will never contain the value “Not Required” or “Not Specified”. 12.3.3
AssociatedCallingDeviceID The AssociatedCallingDeviceID parameter type specifies the Network Interface Device (e.g., trunk, CO line) within the switching sub-domain that is associated with the calling device in the call if the call is an external incoming call. This parameter shall be included on all external incoming calls. Format and Status This device identifier type may be one of the following (see Clause 10, “CSTA Device Identifier Formats”, on page 102 for more information): •
a character string when using the Diallable Digits and the Switching Function Representation formats.
•
an integer value when using the Device Number format. - 147 -
•
a value of “Not Known”.
Functional Requirements 1. A device identifier of this type will only be present when the switching function is using a network interface device for an inbound call; that is, the call is an external incoming call. 2. A device identifier of this type is not used to provide ANI (Automatic Number Identification), CLID (CallerID) or SID (Station Identification) digit information or a string of digits that represents the calling device. (This information is provided in the corresponding CallingDeviceID parameter.) 3. A device identifier of this type will never contain the value “Not Required” or “Not Specified”. 4. If a call is created that contains multiple AssociatedCallingDeviceIDs (i.e., a conference call calling back to a device), the AssociatedCallingDeviceID status shall be “Not Known”. 12.3.4
AuditoryApparatusID The AuditoryApparatusID parameter type specifies a particular auditory apparatus associated with the device. Format
12.3.5
This parameter type is a sequence of characters. ButtonID The ButtonID parameter type specifies the button identifier on a device. Format This parameter type is a sequence of characters. Table 12-3 Reserved Button ID Assignments Button ID
12.3.6
Button Label
0-9
Keypad Digits: “0” through “9”
10
Keypad Symbol: “*”
11
Keypad Symbol: “#”
CalledDeviceID A device identifier of the CalledDeviceID type describes the originally called device associated with a call. Format and Status This device identifier type may be one of the following (see Clause 10, “CSTA Device Identifier Formats”, on page 102 for more information): •
a character string when using the Diallable Digits and the Switching Function Representation formats.
•
an integer value when using the Device Number format.
•
a value of “Not Known”.
Functional Requirements 1. A device identifier of this type contains the originally called device in the call. For External Incoming calls, a device identifier of this type will contain DNIS (Dialed Number Identification Service) or DID (Direct Inward Dialing). 2. This parameter will never contain the value “Not Required” or “Not Specified”. - 148 -
3. When two calls are being joined through a conference or transfer, the CalledDeviceID information for the resulting call shall be taken from the secondary call. 4. This parameter type is different from the NetworkCalledDeviceID parameter type in that the CalledDeviceID information may change if the call is transferred and/or conferenced whereby the NetworkCalledDeviceID information does not change as long as the NID associated with the original calling device remains in the call. Also, the NetworkCalledDeviceID is limited to information passed over a Network Interface Device. 12.3.7
CallingDeviceID The CallingDeviceID parameter type specifies the calling device associated with the call. Format and Status This device identifier type may be one of the following (see Clause 10, “CSTA Device Identifier Formats”, on page 102 for more information): •
a character string when using the Diallable Digits and the Switching Function Representation formats.
•
an integer value when using the Device Number format.
•
a value of “Not Known”.
•
a value of “Restricted” - provided when the callingDeviceID cannot be provided due to regulatory and/ or privacy reasons.
Functional Requirements 1. A device identifier of this type contains the calling device in the call. For External Incoming calls, a device identifier of this type will contain ANI (Automatic Number Identification), CLID (CallerID) or SID (Station Identification) digit information or a string of digits that represents the calling device. 2. This parameter will never contain the value “Not Required” or “Not Specified”. 3. If more than one device is the calling device in a call (i.e., a conference call calling back to a device), the CallingDeviceID status will be “Not Known”. 4. This parameter type is different from the NetworkCallingDeviceID parameter type in that the CallingDeviceID information may change if the call is transferred and/or conferenced whereby the NetworkCallingDeviceID information does not change as long as the NID associated with the original calling device remains in the call. Also, the NetworkCallingDeviceID is limited to information passed over a Network Interface Device. 12.3.8
CDRCrossRefID The CDRCrossRefID is used to correlate subsequent CDR services to the Start Call Detail Records Transmission service. Format
12.3.9
This parameter type is a sequence of characters. ConnectionID The ConnectionID parameter type describes a device’s connection in a given call. (Connection Identifiers are also discussed in 6.1.3, “Connection”, on page 49.)
- 149 -
Format The ConnectionID is always comprised of the following parameters (except in special cases which are described below): 1. callID (M) Character String - An identifier used by the switching function to represent a valid call. The maximum length supported by the switching function is provided via the capabilities exchange services. These IDs are created by the switching function and are globally unique among all calls within the switching sub-domain. 2. deviceID (M) DeviceID - An identifier which is used to represent a device in the switching subdomain. This identifier can be either one of the two following values: •
Static - This type of identifier is defined in 6.1.1, “Device”, on page 8.
•
Dynamic - This type of identifier is one that is created by the switching function for a device when it enters into a call and shall remain constant for the life of the device’s participation in the call (i.e., the creation of a connection identifier for the device). As soon as the device leaves the call, the identifier becomes invalid. The use of a dynamic identifier by a switching function is determined when the switching function does not have a static identifier for the device or the identifier can not uniquely identify the device in a call. This type of identifier is sequence of characters. It is never a dialable number and can never be used outside the context of the connection identifier. This type of identifier is not directly related to a device element but is strictly used to make the connection identifier unique. Refer to 6.1.6, “Management of Dynamically-Assigned Identifiers”, on page 56, for more information.
Functional Requirements 1. The computing function shall not fabricate its own Connection IDs. This will lead to unpredictable results. 2. The Connection IDs in events and service acknowledgements are always allocated by the switching function. 3. Computing functions can extract Device IDs from Connection IDs and use them on services that have Device ID parameters only if the Device ID extracted is a static Device ID that the switching function accepts. Otherwise, the Device ID cannot be used. 4. Computing functions shall extract Call IDs from Connection IDs, provided by the switching function, to correlate event reports associated with devices that are connected together in a call. 5. The computing function will always receive an event to indicate the termination of a Connection ID if the appropriate monitor is started. Refer to the individual services and events to better understand the meaning of individual events with respect to connection states. 6. If the computing function issues a service with a Connection ID that cannot be controlled by the switching function, the service will be rejected with a negative acknowledgement. 7. Connection IDs used as parameters can only have three formats: a. A complete Connection ID (i.e., call ID and device ID). This extracted from either events received by the computing function or positive acknowledgements received as a result of services issued. When supplied as a parameter, the Connection ID will be validated by the switching function with respect to the service being issued. If this Connection ID is not valid, the service request will be rejected with a negative acknowledgement. b. A DeviceID only Connection ID. If a service has more than one Connection ID parameter, the switching function supports this type of Connection ID, and the computing function wants to use this type of Connection ID, then all Connection ID parameters in the service shall be of this type. - 150 -
If this type of Connection ID is used as the Connection ID parameter for a service, then rules documented in the services sections will determine whether it is accepted or not by the switching function. If this type of Connection ID is not accepted, then the service will be rejected with a negative acknowledgement. c.
A Call ID only Connection ID. In events, this format can only be used for the Call Cleared and Failed event. If this format is used for any service other than Clear Call, Monitor Start, or Snapshot Call, it will be rejected with a negative acknowledgement.
8. If a call changes its Call ID when a Conference or Transfer occurs, Connection IDs shall be provided to link the old Call IDs to the new Call IDs. When this occurs, the event will contain a list of originally known Connection IDs of devices that are still in the call along with the new replacement Connection IDs. When the new Connection IDs are created in such cases, new dynamic Device IDs may also be used to create the Connection IDs. 9. Connection IDs that come from the switching function (events and positive acknowledgements to services) will always contain both the Call ID and Device ID portions (see item 7a above) except for the Call Cleared and Failed events that may also contain only a valid call ID in the connection ID (see item 7c above). 10. The computing function should never assume the reuse of callIDs, although some switching functions may reuse one or the other. 12.3.10 DCollCrossRefID The DCollCrossRefID parameter type identifies a specific data collection that was initiated via the Start Data Collection service. The DCollCrossRefID is valid only for the duration of the data collection. Format This parameter type is a sequence of characters. 12.3.11 DeviceID The DeviceID parameter type identifies or represents a device. Format This DeviceID parameter type consists of two components: •
•
Device Identifier - A mandatory component that specifies the device identifier as described in Clause 10, “CSTA Device Identifier Formats”, on page 102. This may include one of the following: •
a character string when using the Diallable Digits and the Switching Function Representation formats.
•
an integer value when using the Device Number format.
Media Call Characteristics - An optional component that specifies the media (voice, digital data, etc.) characteristics of the device. This may be used for selecting a device based upon a particular media capability, for example. Refer to 12.2.15, “MediaCallCharacteristics”, on page 113 for the complete set of possible values.
The maximum length of the Device Identifier component that is supported by the switching function is provided via the capabilities exchange services. Functional Requirements 1. For more details on DeviceID parameter types, refer to 6.1.1, “Device”. 2. For information on DeviceID in Connection Identifiers, refer to 12.3.9, “ConnectionID”, on page 149 and 6.1.3, “Connection”, on page 49. - 151 -
12.3.12 DisplayID The DisplayID parameter type specifies a particular display associated with the device. Format This parameter type is a sequence of characters. 12.3.13 EscapeRegisterID The EscapeRegisterID parameter type is used to identify an escape service registration. Format This parameter type is a sequence of characters. 12.3.14 HookswitchID The HookswitchID parameter type is used to specify the hookswitch to query at a specified device. If not provided, the default is to get the status of each hookswitch at the specified device. Format This parameter type is a sequence of characters. 12.3.15 IOCrossRefID The IOCrossRefID parameter type identifies each I/O data path. The computing function receives a IOCrossRefID in each I/O service request. The Start Data Path service initiates an I/O data path. The IOCrossRefID is only valid for the duration of the data path. The IOCrossRefID is unique within the I/O registration (IORegisterReqID). Some switching functions may provide the additional benefit of a unique IOCrossRefID across the entire switching sub-domain. This is also the case if I/O registration is not supported by the switching function. The parameter type also specifies if the switching function or the computing function started the data path. Format This parameter type shall be one of the following: •
switchProvided (sequence of characters) - indicates that the switching function has started the data path.
•
computerProvided (sequence of characters) - indicates that the computing function has started the data path.
12.3.16 IORegisterReqID The IORegisterReqID parameter type identifies a I/O registration for which the computing function (acting as an I/O server) will receive I/O service requests. This identifier may be associated with a particular device within the switching sub-domain or it may indicate that the computing sub-domain is the I/O server for all devices within the switching sub-domain. When the computing function uses the I/O Register service to register for I/O services, it receives a IORegisterReqID in the positive acknowledgement sent by the switching function. The IORegisterReqID is only valid until the I/O registration is ended by the computing function or switching function. IORegisterReqID parameters are unique across a given CSTA service boundary. Format This parameter type is sequence of characters.
- 152 -
12.3.17 LampID The LampID parameter type specifies the lamp identifier. Format This parameter type is a sequence of characters. 12.3.18 MediaServiceInstanceID The MediaServiceInstanceID parameter type identifies a particular media access service instance (e.g., specific media access server or subsystem). Format This parameter type is a sequence of characters. 12.3.19 MediaStreamID The MediaStreamID parameter type specifies a media stream identifier that can be used to access an attached media service. The usage of the mediaStreamID is defined by a particular media service. Format This parameter type is a sequence of characters. The maximum length supported by the switching function is provided via the capabilities exchange services. 12.3.20 MessageID The MessageID parameter type specifies a particular Voice Unit message. Format This parameter type is character string. The maximum length supported by the switching function is provided via the capabilities exchange services. 12.3.21 MonitorCrossRefID The MonitorCrossRefID parameter type specifies an identifier that is used to correlate an event to an established monitor. When a monitor is established using the Monitor Start service, a monitorCrossReferenceID parameter is returned as part of the positive acknowledgement message. This monitorCrossReferenceID parameter is included in every event for that specific monitor. Format This parameter type is a sequence of characters. The maximum length supported by the switching function is provided via the capabilities exchange services. Functional Requirements 1. This parameter is allocated by the switching function. 2. The switching function is responsible for providing unique monitorCrossReferenceID parameters over a specific service boundary. 12.3.22 NetworkCalledDeviceID For external incoming calls, this parameter specifies the called device information that was provided by the Network over a Network Interface Device. For example, this may contain DNIS (Dialed Number Identification Service) or DID (Direct Inward Dialing) digit information or a string of digits that represents the called device. This information is established when the call is first created and stays with the call as long as the Network Interface Device (NID) associated with the original calling device remains in the call, even if the call is transferred from the original called device, for example. - 153 -
Format and Status This device identifier type may be one of the following (see Clause 10, “CSTA Device Identifier Formats”, on page 102 for more information): •
a character string when using the Diallable Digits and the Switching Function Representation formats.
•
an integer value when using the Device Number format.
•
a value of “Not Known”.
Functional Requirements 1. This parameter will never contain the value “Not Required” or “Not Specified”. 2. This parameter type is different from the CalledDeviceID parameter type in that the CalledDeviceID information may change if the call is transferred and/or conferenced whereby the NetworkCalledDeviceID information does not change as long as the NID associated with the original calling device remains in the call. Also, the NetworkCalledDeviceID is limited to information passed over a Network Interface Device. 12.3.23 NetworkCallingDeviceID For external incoming calls, this parameter specifies the calling device information that was provided by the Network over a Network Interface Device. For example, this may contain ANI (Automatic Number Identification), CLID (CallerID) or SID (Station Identification) digit information or a string of digits that represents the calling device. This information is established when the call is first created and stays with the call as long as the Network Interface Device (NID) associated with the original calling device remains in the call, even if the call is transferred from the original called device, for example. Format and Status This device identifier type may be one of the following (see Clause 10, “CSTA Device Identifier Formats”, on page 102 for more information): •
a character string when using the Diallable Digits and the Switching Function Representation formats.
•
an integer value when using the Device Number format.
•
a value of “Not Known”.
•
a value of “Restricted” - provided when the callingDeviceID cannot be provided due to regulatory and/ or privacy reasons.
Functional Requirements 1. This parameter will never contain the value “Not Required” or “Not Specified”. 2. This parameter type is different from the CallingDeviceID parameter type in that the CallingDeviceID information may change if the call is transferred and/or conferenced whereby the NetworkCallingDeviceID information does not change as long as the NID associated with the original calling device remains in the call. Also, the NetworkCallingDeviceID is limited to information passed over a Network Interface Device. 12.3.24 RedirectionDeviceID The RedirectionDeviceID parameter type describes the last device known by the switching function from which the current call was routed. “Routed” includes forwarded from, diverted from, or redirected from.
- 154 -
Format and Status This device identifier type may be one of the following (see Clause 10, “CSTA Device Identifier Formats”, on page 102 for more information): •
a character string when using the Diallable Digits and the Switching Function Representation formats.
•
an integer value when using the Device Number format.
•
“Provided” - indicates that the DeviceID of the last redirection device is provided.
•
“Not Known” - indicates that the call has been redirected but the switching function cannot provide the DeviceID.
•
“Not Required” - indicates that the current call has never been redirected during the existence of the call.
•
“Not Specified” - indicates that the switching function cannot determine whether or not the call has ever been redirected.
•
“Restricted” - provided when the device cannot be provided due to regulatory and/or privacy reasons.
Functional Requirements 1. The information in a device identifier of this type will stay with the call until the call is established. If the call is routed multiple time before it is established, then the information in this parameter will be updated to the last known device from which the call was routed. If the call was redirected from a device, but the device identifier is unknown, “Not Known” shall be used. Depending on the capabilities of the switching function, the last known device for the call might be reflected by only one device identifier and in actuality the call might have been routed several times before arriving at the final destination. Note that in the case of Immediate Forwarding, where forwarding is triggered before the call is delivered to a device, the lastRedirectionDevice in the event associated with the delivery of the call to a new device (after it was immediately forwarded) shall contain “Not Known”. Refer to 6.7.1, “Forwarding”, on page 69 for more information. 12.3.25 ResourceID The ResourceID parameter type specifies a particular Voice device resource. Format This parameter type is character string. 12.3.26 RingerID Specifies the ringer identifier associated with a physical element. A device can be associated with one or more ringers. Format This parameter type is sequence of characters. 12.3.27 RouteingCrossRefID The routeingCrossRefID parameter type identifies each routeing dialogue. The computing function receives a routeingCrossRefID in each Route Request service request. The Route Request service initiates a routeing dialogue. The routeingCrossRefID is only valid for the duration of the routeing dialogue pertaining to a specific call. The routeingCrossRefID is unique within the routeing registration (routeRegisterReqID). Some switching functions may provide the additional benefit of a unique routeing cross reference identifier across the - 155 -
entire switching sub-domain. This is also the case if routeing registration is not supported by the switching function. Format This parameter type is a sequence of characters. 12.3.28 RouteRegisterReqID The RouteRegisterReqID parameter type identifies a routeing registration for which the computing function (acting as a routeing server) will receive routeing requests. This identifier may be associated with a particular routeing device within the switching sub-domain or it may indicate that the computing subdomain is the routeing server for all routeing devices within the switching sub-domain. When the computing function uses the Route Register service to register for routeing services, it receives a routeRegisterReqID in the positive acknowledgement sent by the switching function. The routeRegisterReqID is only valid until the routeing registration is ended by the computing function or switching function. routeRegisterReqID parameters are unique across a given CSTA service boundary. Format This parameter type is a sequence of characters. 12.3.29 ServiceCrossRefID The ServiceCrossRefID parameter type specifies an identifier that is used to correlate one service request to another service request. For example, a service may be specified to request information from a switching function using an asynchronous mechanism. In this case there would be a service request from the computing function requesting information. The switching function would return a ServiceCrossRefID in the positive acknowledgement to this request. The switching function would subsequently send messages in the form of Service Requests to the computing function that would contain the same ServiceCrossRefID that could be used to correlate the service request with the original service request. Format This parameter type is sequence of characters. Functional Requirements 1. This parameter is allocated by the switching function. 2. The switching function is responsible for providing unique ServiceCrossRefIDs over a specific CSTA service boundary. 12.3.30 SubjectDeviceID The SubjectDeviceID parameter type represents a device which is the focus of the action associated with the event being reported. Format and Status This device identifier type may be one of the following (see Clause 10, “CSTA Device Identifier Formats”, on page 102 for more information): •
a character string when using the Diallable Digits and the Switching Function Representation formats.
•
an integer value when using the Device Number format.
•
a value of “Not Known”. - 156 -
12.3.31 SysStatRegisterID The SysStatRegisterID parameter type is used to identify system status registration. Format and Status This parameter type is a sequence of characters.
- 157 -
13
Capability Exchange Services This clause describes the Capability Exchange Services.
13.1
Services Table 13-1 Capability Exchange Services Summary Capability Exchange Service
Description
Pg.
13.1.1 Get CSTA Features
Obtains the list of supported CSTA services and events.
159
13.1.2 Get Logical Device Information
Obtains the current set of logical device information for a given device identifier.
161
13.1.3 Get Physical Device Information
Obtains the current set of physical device information for a given device identifier.
170
13.1.4 Get Switching Function Capabilities
Obtains the current set of capabilities for the entire switching function.
174
13.1.5 Get Switching Function Devices
Obtains the devices in the application working domain (i.e. devices that can be controlled and/or observed).
190
13.1.6 Switching Function Devices
Provides the actual list of devices in the application working domain (i.e. devices that can be controlled and/or observed).
192
- 158 -
13.1.1
Get CSTA Features
C
S
The Get CSTA Features service obtains the list of CSTA services and events supported by the switching function. 13.1.1.1 Service Request Table 13-2 Get CSTA Features—Service Request Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
13.1.1.2 Service Response This service follows the atomic acknowledgement model for this request. 13.1.1.2.1 Positive Acknowledgement Table 13-3 Get CSTA Features—Positive Acknowledgement Parameter Name supportedServices
Type Bitmap
M/ O/C M
Description Specifies the list of CSTA services supported by the switching function. Each entry in the lists represents a supported service. Services are organized into the following categories: • capExchangeServList (O) CapExchangeServList • systemStatServList (O) SystemStatServList • monitoringServList (O) monitoringServList • snapshotServList (O) snapshotServList • callControlServList (O) CallControlServList • callAssociatedServList (O) CallAssociatedServList • mediaServList (O) MediaServList • routeingServList (O) routeingServList • physDevServList (O) physDevServList • logicalServList (O) LogicalServList • ioServicesServList (O) IOServicesServList • dataCollectionServList (O) DataCollectionServList • voiceServList (O) VoiceServList • cDRServList (O) CDRServList • vendorSpecificServList (O) VendorSpecificServList • locServicesServList (O) LocServicesServList If a service’s bitmap entry is not included in the list, then the service is not supported by any device in the switching function.
- 159 -
Table 13-3 Get CSTA Features—Positive Acknowledgement (concluded) Parameter Name supportedEvents
Type
M/ O/C
Bitmap
M
Description Specifies the list of CSTA events supported by the switching function. Each entry in the lists represents a supported event. Events are organized into the following categories: • callControlEvtsList (O) CallControlEvtsList • callAssociatedEvtsList (O) CallAssociatedEvtsList • mediaEvtsList (O) MediaEvtsList • physDevEvtsList (O) physDevEvtsList • logicalEvtsList (O) LogicalEvtsList • deviceMaintEvtsList (O) DeviceMaintEvtsList • voiceEvtsList (O) VoiceEvtsList • vendorSpecificEvtsList (O) VendorSpecificEvtsList If an event’s bitmap entry is not included in the list, then the event is not supported by any device in the switching function.
security
CSTASecurityDat a
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
13.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 13.1.1.3 Operational Model 13.1.1.3.1 Connection State Transitions
There are no connection state changes as the result of this service. 13.1.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 13.1.1.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 13.1.1.3.4 Functional Requirements
1. The services provided in the positive response reflect the list of services supported by some or all of the devices in the switching function. Some services may not be supported for a particular device in the switching function. An application can determine if a service is supported by a particular device by one of the following mechanisms: a. Use the Get Logical Device Information service or the Get Physical Device Information service to determine the CSTA services supported by a specific device. b. Use the servicesPermitted parameter (12.2.25, “ServicesPermitted”, on page 142) to determine the services that can be applied to a connection. 2. The events provided in the positive response reflect the list of events supported by some or all of the devices in the switching function for all of the possible types of monitors. Some events may not be supported for a particular device in the switching function or when a specific monitor type is used. An application can determine if an event is supported by a particular device by: a. Use the Get Logical Device Information service or the Get Physical Device Information service to determine the CSTA events supported by a specific device for a specific type of monitor.
- 160 -
13.1.2
Get Logical Device Information
C
S
The Get Logical Device Information service is used to obtain the current set of characteristics/capabilities associated with the logical element of a given device. 13.1.2.1 Service Request Table 13-4 Get Logical Device Information—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device being queried.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
13.1.2.2 Service Response This service follows the atomic acknowledgement model for this request. 13.1.2.2.1 Positive Acknowledgement Table 13-5 Get Logical Device Information—Positive Acknowledgement Parameter Name deviceCategory
Type
M/ O/C
Description
Enumerated
M
Specifies the device category (station, ACD device, etc.) of the device in the service request. The complete set of possible values is: • ACD • Group • Network Interface (e.g., trunk, CO line) • Park • Routeing Device • Station (default) • Voice Unit • Generic Interactive Voice • Listener Interactive Voice • DTMF Interactive Voice • Prompt Interactive Voice • Prompt Queue Interactive Voice • Message Interactive Voice • Conference • Other
groupDeviceAttributes
Bitmap
C
Specifies the group device attributes of the device being queried. If a bit is TRUE then the specified attribute is present. The following is the list of bits (multiple bits may be set): • ACD • Hunt • Pick • User • Agent • Other This parameter shall be provided if the deviceCategory is Group, otherwise it shall not be provided.
- 161 -
Table 13-5 Get Logical Device Information—Positive Acknowledgement (continued) Parameter Name namedDeviceTypes
Type
M/ O/C
Description
Enumerated
O
If assigned by the switching function, this parameter indicates the named device type associated with the device in the service request. The complete set of possible values are: • ACD • ACD Group • Button • Button Group • Conference Bridge • Line • Line Group • Operator • Operator Group • Parking Device • Station • Station Group • Trunk • Trunk Group • Other • Other Group
shortFormDeviceID
DeviceID
O
Specifies an alternative (a shorter length, for example) device identifier that the switching function may use to reference the device in the service request.
hasPhysicalElement
Boolean
M
Specifies if the device has a physical element associated with this device identifier. The complete set of possible values is: • FALSE - The device does not have a physical element. • TRUE - The device does have a physical element. The device identifier in the service request should be used with the Get Physical Device Information service to obtain the physical element’s characteristics for this device.
acdModels
Bitmap
M
Specifies the type of ACD Model(s) that are present at this device. If a bit is TRUE, then the specified model is supported. The following is the list of bits (multiple bits may be set): • Visible ACD-related Devices • Non-Visible ACD-related Devices Note that these bits are valid when the device is an ACD device.
- 162 -
Table 13-5 Get Logical Device Information—Positive Acknowledgement (continued) Parameter Name agentLogOnModels
Type Bitmap
M/ O/C
Description
C
Specifies the types of agent log on models that are supported by the device. If a bit is TRUE, then the specified agent log on model is supported. The following is the list of bits (multiple bits may be set): • Log On to an ACD device • Log On to an ACD Group (explicit/one step) • Log On to an ACD Group (explicit/two steps) • Log On to an ACD Group (implicit/one step) Note that Log On to an ACD Group (implicit/one step) model cannot be simultaneously supported with the Log On to an ACD device model. The switching function shall provide this parameter if the agent log on model is configured by the switching function at the logical device element level (agent, ACD device, or ACD group), otherwise the parameter may or may not be provided.
appearanceAddressable
Boolean
M
Specifies whether the appearances of the logical element are addressable (via the Call Appearance “CA” string or the physical element extension “EXT” string in the Switching Function Representation Device Identifier format). The complete set of possible values is: • FALSE - The appearances are not addressable. • TRUE - The appearances are addressable
appearanceType
Enumerated
M
Specifies the type of appearances associated with the logical element. The complete set of possible values is: • Selected-Standard • Basic-Standard • Basic-Bridged • Exclusive-Bridged • Independent-Shared-Bridged • Interdependent-Shared-Bridged
appearanceList
List of Characters
- 163 -
C
Specifies the list of device identifier suffices for each of the appearances that are available at the logical element. This parameter is mandatory if the appearances are addressable and if it is a Selected-Standard or a BasicStandard type. This list will only contain appearance suffices that can be observed and/or controlled within the switching sub-domain (via the Call Appearance string in the Switching Function Representation Device Identifier format).
Table 13-5 Get Logical Device Information—Positive Acknowledgement (continued) Parameter Name otherPhysicalDeviceList
Type
M/ O/C
Description
List of DeviceIDs
C
Specifies the list of device identifiers for other devices with physical elements that are associated with the logical element appearance. This parameter is mandatory if the appearances are addressable and any type of bridged appearance. The Get Physical Device Information service should be used to obtain the physical element characteristics associated with these other devices. This list will only contain devices that can be either observed and/or controlled within the switching sub-domain. Note that, for a Hybrid configuration, the order of device identifiers in this list is the same as the order of devices in the appearanceList parameter. See Functional Requirement #3 in 10.1.2 for additional information.
miscMonitorCaps
Bitmap
O
Specifies the special types of monitoring considerations for this device. If a bit is TRUE then the monitoring consideration is associated with the device. The following is the list of bits (Multiple bits may be set): • Group Inclusive Model - the scope of the monitor on the group device includes the distribution mechanism and all member devices. This bit is only valid for group devices that include a distribution mechanism (e.g. Hunt and ACD groups). This bit shall not be set if the Group Exclusive Model bit is set. • Group Exclusive Model - the scope of the monitor on the group device includes only the distribution mechanism. This bit is only valid for group devices that include a distribution mechanism (e.g. Hunt and ACD groups). This bit shall not be set if the Group Inclusive Model bit is set • Monitor the physical element to report call control events for all appearances associated with a device. (Only a valid bit if the appearanceType is any form of bridge appearance.) (i.e. use the device identifiers from the otherPhysicalDeviceList). • ACD Device Inclusive - the scope of the monitor on an ACD device includes both the ACD device and the distributed-to devices (including ACD groups). (This capability is valid only for ACD devices). This bit shall not be set if the ACD Device Exclusive bit is set • ACD Device Exclusive - the scope of the monitor on an ACD device only the ACD device. (This capability is valid only for ACD devices). This bit shall not be set if the ACD Device Inclusive bit is set Note that if this parameter is not present, then the monitoring considerations are not known.
- 164 -
Table 13-5 Get Logical Device Information—Positive Acknowledgement (continued) Parameter Name associatedGroupList
Type
M/ O/C
Description
List of DeviceIDs
C
Specifies the list of device identifiers for all the other devices which are members of this group device. Use the appropriate capabilities exchange services to obtain the characteristics of these devices. This list shall only contain devices that can be either observed and/or controlled within the switching sub-domain. This parameter shall be provided when the device is a Group device. It may or may not be provided if the device is a member of a group and shall not be provided if the device is neither a Group device nor is a member of a group.
maxCallbacks
Value
O
Specifies the maximum number of concurrent call back requests that can be outstanding for this device. If this parameter is not present, then the maximum number of concurrent callback requests is not known for the device.
maxAutoAnswerRings
Value
O
Specifies the maximum number of rings before a call is auto-answered at this device. If this parameter is not present, then the maximum number of Auto Answer rings is not known for the device.
maxActiveCalls
Value
O
Specifies the maximum number of concurrent calls that can be active at any one time for this device. If this parameter is not present, then the maximum number of active calls is not known for the device.
maxHeldCalls
Value
O
Specifies the maximum number of concurrent calls that can be held at any one time for this device. If this parameter is not present, then the maximum number of held calls is not known for the device.
maxFwdSettings
Value
O
Specifies the maximum number of user-specified settings (forwarding-type/forward-destination combinations) that can be activated at any one time for this device. If this parameter is not present, then the maximum number of activated user-specified settings is not known for the device.
maxDevicesInConf
Value
O
Specifies the maximum number of devices both within and outside the switching function that this device can conference into a call. If this parameter is not present, then the maximum number of devices in a conference is not known for the device. The minimum value that can be supplied for this value is 3.
transAndConfSetup
Bitmap
O
Specifies the different ways that this device can set up for a conference and/or transfer. (Note that if this parameter is not present, then the device can only set up transfers and conferences through the Consultation Call service.) If the bit is TRUE, then the specified way to setup a conference or transfer is supported by the switching function. The following is the list is of bits (multiple bits may be set): • Consultation Call • Hold Call - Make Call • Alternate Call • two calls in the initial state of Hold • two calls in the initial state of Connected
- 165 -
Table 13-5 Get Logical Device Information—Positive Acknowledgement (continued) Parameter Name deviceOnDeviceMonitorFilter
Type
M/ O/C
Description
MonitorFilter
C
Specifies the complete monitorFilter parameter that this device supports with respect to device-type monitoring. This parameter shall be provided if this form of device-type monitoring is supported, otherwise the parameter shall not be provided. The information in the monitor filter parameters used in the Get Logical Device Information and the Get Physical Device Information services should be the same when the same device identifier is used (assuming that the device identifier has a logical and a physical element).
deviceOnConnectionMonitorFilter
MonitorFilter
C
Specifies the complete monitorFilter parameter that connections at this device supports with respect to devicetype monitoring. This parameter shall be provided if this form of device-type monitoring is supported, otherwise the parameter shall not be provided.
callOnDeviceMonitorFilter
MonitorFilter
C
Specifies the complete monitorFilter parameter that this device supports with respect to call-type monitoring on a device. This parameter shall be provided if this form of calltype monitoring is supported, otherwise the parameter shall not be provided.
callOnConnectionMonitorFilter
MonitorFilter
C
Specifies the complete monitorFilter parameter that this device supports with respect to call-type monitoring for a connection at this device. This parameter shall be provided if this form of call-type monitoring is supported, otherwise the parameter shall not be provided.
mediaClassSupport
Bitmap
O
Specifies the media class of calls that the device can support. If a bit is TRUE then the specified type of call can be present at the device. The following is the list of bits (multiple bits may be set): • Audio • Data • Image • Voice • Other • Chat • Email • Message • IM • SMS • MMS
- 166 -
Table 13-5 Get Logical Device Information—Positive Acknowledgement (continued) Parameter Name mediaServiceCapsList
Type
M/ O/C
Description
List of Structures
C
Specifies a list of structures of the media service types, version, media service instances, connection modes supported. This parameter is a list, each element of which contains the following: • mediaServiceType (M) MediaServiceType - A media service type used to identify the media service. • mediaSeviceVersion (O) Value - The version of the media service. • mediaServiceInstance (O) MediaServiceInstanceID - A media service instance associated with the media service. • connectionModeBMap (O) Bitmap - The media service connection modes supported for the media service type, version and instance. The following is the list of bits (multiple bits may be set): •
consultationConference
•
consultationConferenceHold
•
deflect
•
directedPickup
•
join
•
singleStepConference
•
singleStepConferenceHold
•
singleStepTransfer
•
transfer
•
direct
• mediaStreamIDSupported (M) Boolean - Specifies if the mediaStreamID is supported for the combination of media service type, version, and instance. The complete set of values is: •
TRUE - indicates that the switching function shall provide the conditional mediaStreamID parameter where specified.
•
FALSE - indicates that the conditional mediaStreamID is not provided.
This parameter shall be provided if the device is capable of media access and shall not be provided otherwise. connectionRateList
List of Values
O
Specifies the list of connection rates that are supported for this device.
delayToleranceList
List of Values
O
Specifies the list of delay Tolerances that are supported for this device.
numberOfChannels
Value
O
Specifies the number of available channels at this device. If the parameter is not present, the number of channels at the device is not known but it is one or greater.
maxChannelBind
Value
O
Specifies the maximum number of channels that can be associated with a given connection at a device. If the parameter is not present, the maximum number of channels per connection is one.
- 167 -
Table 13-5 Get Logical Device Information—Positive Acknowledgement (continued) Parameter Name routeingServList
Type
M/ O/C
Description
RouteingServList
C
Specifies a list of bitmaps. Each bitmap entry represents a Routeing service that is supported by the device (both service requests to and from the switching function, when the service is bi-directional). This includes the following categories of services: • Routing Services This parameter shall be provided if the switching function supports any of these categories of services for this device. If a Routeing service’s bitmap entry is not included in the list, then the service is not supported by the switching function. Note that the Routeing Mode feature is grouped with Logical Device features.
logDevServList
Structure
C
Specifies a list of capability bitmap parameter types corresponding to categories of services. Each bitmap entry in the lists represents a service that applies to a logical device that is supported by the device. This includes the following categories of services: • callControlServList (O) CallControlServList - specifies the list of call control services supported. • callAssociatedServList (O) CallAssociatedServList specifies the list of call associated services supported. • logicalServList (O) LogicalServList - specifies the list of logical device feature services supported. • mediaServList (O) MediaServList - specifies the list of media services supported. • ioServicesServList (O) IOServicesServList - specifies the list of I/O services supported. • dataCollectionServList (O) DataCollectionServList specifies the list of data collection services supported. • voiceServList (O) VoiceServList - specifies the list of voice services supported. • locServicesServList (O) LocServicesServList - specifies the list of location services supported. This parameter shall be provided if the switching function supports at least one of these categories of services for this device. If a logical device service’s bitmap entry is not included in the list, then the service is not supported by the device.
- 168 -
Table 13-5 Get Logical Device Information—Positive Acknowledgement (concluded) Parameter Name logDevEvtsList
Type Structure
M/ O/C
Description
C
Specifies a list of capability bitmap parameter types corresponding to categories of events. Each bitmap entry in the lists represents an event that applies to a logical device that is supported by the device. This includes the following categories of events: • callControlEvtsList (O) CallControlEvtsList - specifies the list of call control events supported. • callAssociatedEvtsList (O) CallAssociatedEvtsList specifies the list of call associated events supported. • logicalEvtsList (O) LogicalEvtsList - specifies the list of logical device feature events supported. • mediaEvtsList (O) MediaEvtsList - specifies the list of media events supported. • voiceEvtsList (O) VoiceEvtsList - specifies the list of voice events supported. This parameter shall be provided if the switching function supports any of these categories of events for this device. If a logical device event’s bitmap entry is not included in the list, then the event is not supported by the device.
deviceMaintEvtsList
DeviceMaintEvts List
C
Specifies a list of bitmaps. Each bitmap entry represents a device maintenance event that is supported by the device. This includes the following categories of services: • Device Maintenance events This parameter shall be provided if the switching function supports any of these categories of events for this device. If a device maintenance’s bitmap entry is not included in the list, then the event is not supported by the switching function.
security
CSTASecurityDat a
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
13.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 13.1.2.3 Operational Model 13.1.2.3.1 Connection State Transitions
There are no connection state changes as the result of this service. 13.1.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 13.1.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 13.1.2.3.4 Functional Requirements
1. This service shall be rejected with a negative acknowledgement (i.e., Error Value of Object Not Known), if the device does not contain a logical element.
- 169 -
13.1.3
Get Physical Device Information
C
S
The Get Physical Device Information service is used to obtain the current set of characteristics/ capabilities associated with the physical element of a given device. 13.1.3.1 Service Request Table 13-6 Get Physical Device Information—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device being queried.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
13.1.3.2 Service Response This service follows the atomic acknowledgement model for this service request. 13.1.3.2.1 Positive Acknowledgement Table 13-7 Get Physical Device Information—Positive Acknowledgement
Parameter Name deviceCategory
Type
M/ O/C
Description
Enumerated
M
Specifies the device category (station, ACD device, etc.) of the device being queried. The complete set of possible values is: • ACD • Group • Network Interface (i.e., trunk) • Park • Routeing • Station (default) • Voice Unit • Generic Interactive Voice • Listener Interactive Voice • DTMF Interactive Voice • Prompt Interactive Voice • Prompt Queue Interactive Voice • Message Interactive Voice • Conference • Other
- 170 -
Table 13-7 Get Physical Device Information—Positive Acknowledgement (continued) Parameter Name groupDeviceAttributes
Type Bitmap
M/ O/C
Description
C
Specifies the group device attributes of the device being queried. If a bit is TRUE then the specified attribute is present. The following is the list of bits (multiple bits may be set): • ACD • Hunt • Pick • User • Agent • Other This parameter shall be provided if the deviceCategory is Group, otherwise it shall not be provided.
namedDeviceTypes
Enumerated
O
If assigned by the switching function, this parameter indicates the named device type associated with the device being queried. The complete set of possible values are: • ACD • ACD Group • Button • Button Group • Conference Bridge • Line • Line Group • Operator • Operator Group • Parking Device • Station • Station Group • Trunk • Trunk Group • Other • Other Group
hasLogicalElement
Boolean
M
Specifies if the device has a logical element associated with this device identifier. The complete set of possible values is: • FALSE - The device does not have a logical element. • TRUE - The device does have a logical element. The device identifier in the service request should be used with the Get Logical Device Information service to obtain the logical element’s characteristics for this device.
otherLogicalDeviceList
List of Device IDs
- 171 -
O
Specifies the list of device identifiers for other devices with logical elements that are associated with this device. The Get Logical Device Information service should be used to obtain the logical element characteristics associated with these other devices. This list will only contain devices that can be either observed and/or controlled within the switching function.
Table 13-7 Get Physical Device Information—Positive Acknowledgement (continued) Parameter Name
Type
M/ O/C
Description
deviceModelName
Characters
O
Specifies the switching function specific model name of the device. If this parameter is not present, then the model name is not known.
deviceOnDeviceMonitorFilter
MonitorFilter
C
Specifies the complete monitorFilter parameter that the device supports with respect to device-type monitoring. This parameter shall be provided if this form of devicetype monitoring is supported, otherwise the parameter shall not be provided. The information in the monitor filter parameters used in the Get Logical Device Information and the Get Physical Device Information services should be the same when the same device identifier is used (assuming that the device identifier has a logical and a physical element).
deviceOnConnectionMonitorFilter
MonitorFilter
C
Specifies the complete monitorFilter parameter that a connection at the device supports with respect to devicetype monitoring. This parameter shall be provided if this form of device-type monitoring is supported, otherwise the parameter shall not be provided.
callOnDeviceMonitorFilter
MonitorFilter
C
Specifies the complete monitorFilter parameter that the device supports with respect to call-type monitoring on a device. This parameter shall be provided if this form of call-type monitoring is supported, otherwise the parameter shall not be provided.
callOnConnectionMonitorFilter
MonitorFilter
C
Specifies the complete monitorFilter parameter that the device supports with respect to call-type monitoring on a connection at the device. This parameter shall be provided if this form of call-type monitoring is supported, otherwise the parameter shall not be provided.
maxDisplays
Value
O
Specifies the maximum number of displays associated with the device being queried. If this parameter is not present, then the device either does not have any displays or the maximum number of displays at this device is not known.
maxButtons
Value
O
Specifies the maximum number of buttons associated with the device being queried. If this parameter is not present, then the device either does not have any buttons or the maximum number of buttons at this device is not known.
maxLamps
Value
O
Specifies the maximum number of lamps associated with the device being queried. If this parameter is not present, then the device either does not have any lamps or the maximum number of lamps at this device is not known.
maxRingPatterns
Value
O
Specifies the maximum number of ring patterns that the ringer has for the device being queried. If this parameter is not present, then the device either does not have a ringer or the maximum number of ring patterns at this device is not known.
- 172 -
Table 13-7 Get Physical Device Information—Positive Acknowledgement (concluded) Parameter Name physDevServList
Type
M/ O/C
Description
PhysDevServList
C
Specifies a list of bitmaps. Each bitmap entry represents a Physical Device service that is supported by the specified device. This includes the following categories of services: • Physical Device Feature services This parameter shall be provided if the switching function supports any of these categories of services for this device. If a physical device service’s bitmap entry is not included in the list, then the service is not supported by the specified device.
physDevEvtsList
PhysDevEvtsList
C
Specifies a list of bitmaps. Each bitmap entry represents a Physical Device Event that is supported by the specified device. This includes the following categories of events: • Physical Device Feature events This parameter shall be provided if the switching function supports any of these categories of events for this device. If a physical device event’s bitmap entry is not included in the list, then the event is not supported by the specified device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
13.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 13.1.3.3 Operational Model 13.1.3.3.1 Connection State Transitions
There are no connection state changes as the result of this service. 13.1.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 13.1.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 13.1.3.3.4 Functional Requirements
1. This service shall be rejected with a negative acknowledgement (i.e., Error Value of Object Not Known), if the device does not have a physical element. 2. In order to obtain the entire set of physical device capabilities and characteristics, the computing function shall also use the Get Button Information, Get Lamp Information, and Get Display services to collect the detailed information on the device’s buttons, lamps, and displays.
- 173 -
13.1.4
Get Switching Function Capabilities
C
S
The Get Switching Function Capabilities service is used by the computing function to obtain the current set of capabilities for the entire switching function. 13.1.4.1 Service Request Table 13-8 Get Switching Function Capabilities—Service Request Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
13.1.4.2 Service Response This service follows the atomic acknowledgement model for this service request. 13.1.4.2.1 Positive Acknowledgement Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement
Parameter Name
Type
M/ O/C
Description
switchingSubDomainName
Character (64)
M
Specifies the name of switching sub-domain which distinguishes it from other switching subdomains.
manufacturerName
Characters (64)
M
Specifies the name of the manufacturer of the switching sub-domain.
profiles
Bitmap
M
Specifies the CSTA Profiles supported by the switching function. The following is the list of the possible profiles (multiple bits may be set): • Basic Telephony Profile • Routing Profile • Level 1a Voice Browser Profile • Level 1b Voice browser Profile • Level 2 Voice Browser Profile • Minimal Endpoint Call Control Profile • Basic Endpoint Call Control Profile • Advanced Endpoint Call Control Profile • Conferencing Endpoint Call Control Profile • Basic Endpoint Device Feature Profile • Advanced Endpoint Device Feature Profile • Basic Speech Service Profile • Advanced Speech Service Profile Note that at least one profile shall be supported by the switching function.
- 174 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name deviceIDFormat
Type Bitmap
M/ O/C
Description
M
Specifies the types of device ID formats supported by the switching function in service requests. If a bit is TRUE, then the specified format is used by the switching function. The following is the list of the possible formats (multiple bits may be set): • Diallable Digits format - “*” • Diallable Digits format - “#” • Diallable Digits format - “A-D” • Diallable Digits format - “!” • Diallable Digits format - “P” • Diallable Digits format - “T” • Diallable Digits format - “,” • Diallable Digits format - “W” • Diallable Digits format - “@” • Diallable Digits format - “$” • Diallable Digits format - “;” • SF Representation format - “!” • SF Representation format - “&” • SF Representation format - “/” • SF Representation format - “%” • SF Representation format - “NM” • SF Representation format - Generic • SF Representation format - ImplicitTON • SF Representation format - PublicTON unknown • SF Representation format - PublicTON international number • SF Representation format - PublicTON national • SF Representation format - PublicTON subscriber • SF Representation format - Public TON abbreviated • SF Representation format - PrivateTON unknown • SF Representation format - PrivateTON level 3 regional • SF Representation format - PrivateTON level 2 regional • SF Representation format - PrivateTON level 1 regional • SF Representation format - PrivateTON local • SF Representation format - PrivateTON abbreviated • SF Representation format - Other
- 175 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name
Type
M/ O/C
deviceIDFormat (continued)
Description • Device Number format • SF Representation format - “~” • DeviceID Tag - privateNumber • DeviceID Tag - privateName Note that the Diallable Digits format with the 0-9 characters shall be supported by the switching function.
swDomainFeatures
Bitmap
M
Specifies which features are supported by the switching function. If a bit is TRUE, then the specified feature is supported. The following is the list of possible features (multiple bits can be set): Forwarding Call Associated models: • Is (Immediate) Forwarding triggered before the call is logically delivered to the device? • Is (Immediate) Forwarding triggered after the call is logically delivered to the device? Level of Forwarding Default Settings: • Switching function default setting - allows activation/deactivation of a single switching function forwarding type/forwarding destination combination. • User specified settings - allows the setting of individual forwarding types and forwarding destinations. • User specified setting (default forwarding type) - If this is TRUE, when the forwarding type is omitted in the Set Forward service, the switching function applies a default value, otherwise there is no default value applied. • User specified setting (default forward destination) - If this is TRUE, when the forward destination is omitted in the Set Forward service, the switching function applies a default value, otherwise there is no default value applied. Connection Failure: • Negative Acknowledgement • Support of Failed event with an associated failed connection • Support of Failed event without an associated failed connection • Support of Failed event with an associated failed connection, not reported via monitors on the failing device Other: • Recall • Call Back • External Calls—Incoming Calls • External Calls—Outgoing Calls • Prompting
- 176 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name swAppearanceAddressability
Type Bitmap
M/ O/C
Description
M
Specifies what types of appearance addressability is available within the switching sub-domain. The following is the list of bits (multiple bits can be set): • addressable • non-addressable
swAppearanceTypes
Bitmap
M
Specifies what types of appearances are available within the switching sub-domain The following is the list of bits (multiple bits can be set): • Selected-Standard • Basic-Standard • Basic-Bridged • Exclusive-Bridged • Independent-Shared-Bridged • Interdependent-Shared-Bridged
ignoreUnsupportedParameters
Enumerated
M
Specifies how the switching function handles unsupported optional parameters in service requests. The complete set of possible values is: • Ignore parameters - This indicates that the switching function treats unsupported optional parameters as if they were not present. • Reject Request - This indicates that the switching function returns a negative acknowledgement in response to any requests that contain unsupported optional parameters.
callCharacteristicsSupported
Bitmap
C
Specifies the characteristics that the switching function reports via the callCharacteristics parameter. If a bit is TRUE then the specified characteristic is reported. The following is the list of bits (multiple bits may be set): • acdCall • priorityCall • maintenanceCall • directAgent • assistCall • voiceUnitCall • privateCall • personalCall • sensitiveCall • confidentialCall • encryptedCall This parameter shall be provided if the switching function characterizes calls via the callCharacteristics parameter.
- 177 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name mediaClassSupport
Type Bitmap
M/ O/C
Description
O
Specifies the media class of calls the switching sub-domain can support. If a bit is TRUE then the specified type of call can be present within the switching function. The following is the list of bits (multiple bits may be set): • Audio • Data • Image • Voice • Other • Chat • Email • Message • IM • SMS • MMS If this parameter is not present, then the switching function only supports voice calls.
numberOfChannels
Value
O
Specifies the highest number of available channels at a given device within the switching sub-domain. If the parameter is not present, the number of channels at a device is not known but is one or greater.
maxChannelBind
Value
O
Specifies the highest maximum number of channels that can be associated with a given connection at a device within the switching subdomain. If the parameter is not present, the maximum number of channels per connection is one.
miscMediaCallCharacteristics
Bitmap
O
Specifies the media call characteristics supported. If a bit is TRUE then the specified feature is present within the switching function. The following is the list of bits (multiple bits can be set) • Does the switching function support the adjustment of the media characteristics when a call is being made?
connectionRateList
List of Values
O
Specifies the list of connection rates that are supported for the given switching function.
delayToleranceRateList
List of Values
O
Specifies the list of delay tolerances that are supported for the given switching function.
pauseTime
Value (1..2000)
O
Specifies the amount time that a pause (as specified by the comma “,” character in the Diallable Digits Device Identifier format) within a dialling sequence will last for in the switching function. This time is specified in milliseconds. If this parameter is not present, then the pause time is not known for the switching function.
currentTime
TimeInfo
O
Specifies the current date and time of the switching function.
- 178 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name messageSeqNumbers
Type Bitmap
M/ O/C
Description
C
Specifies if the switching function supports message sequence numbers (via the security parameter) on services and events. If a bit is TRUE, then it is supported. The following is the list of bits (multiple bits may be set): • allEvents - message sequence number is provided on all events from the switching function. • allAcks - message sequence number is provided on all (positive and negative) acknowledgements from the switching function. • allServReqs - message sequence number is provided on all service requests from the switching function. This parameter shall be provided if the switching function provides message sequence number information.
timeStampMode
Bitmap
C
Specifies when the switching function provides timestamp information (via the security parameter). If a bit is TRUE, then the mode is supported. The following is the list of bits (multiple bits may be set): • allEvents - timestamp parameter is provided on all events from the switching function. • allAcks - timestamp parameter is provided on all (positive and negative) acknowledgements from the switching function. • allServReqs - timestamp parameter is provided on all service requests from the switching function. This parameter shall be provided if the switching function provides timestamp information.
securityMode
Enumerated
C
Specifies when the switching function provides securityInfo (via the security parameter). The following is the list of bits (multiple bits may be set): • allEvents - securityInfo is provided on all events from the switching function. • allAcks - securityInfo is provided on all (positive and negative) acknowledgements from the switching function. • allServReqs - securityInfo is provided on all service requests from the switching function. This parameter shall be provided if the switching function provides securityInfo via the security parameter.
- 179 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name securityFormat
Type Bitmap
M/ O/C
Description
C
Specifies the format(s) of the securityInfo information (in the security parameter) supported by the switching function. The following is the list of bits (multiple bits may be set): • octetStringFromSF - the switching function provides securityData in the octetString format • otherTypeFromSF - the switching function provides securityData in another format. • octetStringToSF - the switching function supports receiving securityData in the octetString format • otherTypeToSF - the switching function supports receiving securityData in another format. This parameter shall be provided if the switching function supports sending or receiving securityInfo in the security parameter.
privateDataFormat
Bitmap
C
Specifies the format(s) of the privateData information supported by the switching function. The following is the list of bits (multiple bits may be set): • octetStringFromSF - the switching function provides privateData in the octetString format • otherTypeFromSF - the switching function provides privateData in another format. • octetStringToSF - the switching function supports receiving privateData in the octetString format • otherTypeToSF - the switching function supports receiving privateData in another format. This parameter shall be provided if the switching function supports sending or receiving privateData.
transAndConfSetup
Bitmap
O
Specifies the different ways that the switching function can set up for a conference and/or transfer. (Note that if this parameter is not present, then the switching function can only set up transfers and conferences through the Consultation Call service.) If the bit is TRUE, then the specified way to setup a conference or transfer is supported by at least one device in the switching sub-domain. The following is the list is of bits (multiple bits may be set): • Consultation Call • Hold Call - Make Call • Alternate Call • two calls in the initial state of Hold • two calls in the initial state of Connected
- 180 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name deviceOnDeviceMonitorFilter
Type MonitorFilter
M/ O/C
Description
C
Specifies the complete monitorFilter parameter that is supported by the switching function when the monitorObject is a device and the monitorType is a device. Each bitmap entry represents an event that is supported by at least one of the devices in the switching function. This parameter shall be provided if this form of device-type monitoring is supported by at least one of the devices in the switching function, otherwise it shall not be provided.
deviceOnConnectionMonitorFilter
MonitorFilter
C
Specifies the complete monitorFilter parameter that is supported by the switching function when the monitorObject is a connection and the monitorType is a device. Each bitmap entry represents an event that is supported by at least one of the devices in the switching function. This parameter shall be provided if this form of device-type monitoring is supported by at least one of the devices in the switching function, otherwise it shall not be provided.
callOnDeviceMonitorFilter
MonitorFilter
C
Specifies the complete monitorFilter parameter that is supported by the switching function when the monitorObject is a device and the monitorType is a call. Each bitmap entry represents an event that is supported by at least one of the devices in the switching function. This parameter shall be provided if this form of call-type monitoring is supported by at least one of the devices in the switching function, otherwise it shall not be provided.
callOnConnectionMonitorFilter
MonitorFilter
C
Specifies the complete monitorFilter parameter that is supported by the switching function when the monitorObject is a connection and the monitorType is a call. Each bitmap entry represents an event that is supported by at least one of the devices in the switching function. This parameter shall be provided if this form of call-type monitoring is supported in the switching function, otherwise it shall not be provided.
- 181 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name miscMonitorCaps
Type Bitmap
M/ O/C
Description
O
Specifies the special types of monitoring capabilities that are present within the switching sub-domain. If a bit is TRUE then the monitoring capability is present within the switching subdomain. The following is the list of bits (multiple bits may be set): • Group Inclusive Model - the scope of the monitor on a group device includes the distribution mechanism and all member devices. This bit applies to group devices that include a distribution mechanism (e.g. Hunt and ACD groups). • Group Exclusive Model - the scope of the monitor on the group device includes only the distribution mechanism. This bit applies to group devices that include a distribution mechanism (e.g. Hunt and ACD groups). • Monitor the physical element to report call control events for all appearances associated with a device. (This capability is valid only if an appearanceType of any form of a bridge appearance is supported.) • ACD Device Inclusive - the scope of the monitor on an ACD device includes both the ACD device and the distributed-to devices (including ACD groups). (This capability is valid only for ACD devices). • ACD Device Exclusive - the scope of the monitor on an ACD device only the ACD device. (This capability is valid only for ACD devices). If this parameter is not present, then the monitoring considerations are not known.
correlatorDataSupported
Boolean
O
Specifies if the switching function supports the correlatorData parameter on service requests and events. The complete set of possible values is: • TRUE - Option supported. • FALSE - Option is not supported. Refer to “Correlator Data” on page 42 for the required events that shall support correlator data if this option is supported.
dynamicFeatureSupported
Enumerated
O
Specifies how the switching function provides the servicesPermitted parameter on events. The complete set of possible values is: • none - servicesPermitted not provided on any events • all - servicesPermitted provided on all events where it is specified • some - servicesPermitted provided on some events. Refer to the logDevEvtsList parameter for the events that support the parameter.
- 182 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name callLinkageOptions
Type Bitmap
M/ O/C
Description
O
Specifies if the switching function supports the call linkage and thread linkage features. The complete set of possible values is: • callLinkageFeatureSupported - the switching function supports the call linkage feature. This feature shall be supported if the thread linkage feature is supported. • threadLinkageFeatureSupported - the switching function supports the thread linkage feature. Refer to 6.1.2.7, “Call Linkage”, on page 46.
acdModels
Bitmap
O
Specifies the types of ACD models that are supported by the switching function. If a bit is TRUE, then the specified ACD model is supported by the switching function. The following is the list of bits (multiple bits may be set): • Visible ACD-Related Devices • Non-Visible ACD-Related Devices Note that if more than one type of ACD model is present in the switching function, then the Get Logical Device Information service shall be used to determine the particular ACD models supported by for each ACD device or ACD group by the switching function.
agentLogOnModels
Bitmap
O
Specifies the types of agent log on models that are supported by the switching function. If a bit is TRUE, then the specified agent log on model is supported by the switching function. The following is the list of bits (multiple bits may be set): • Log On to an ACD device • Log On to an ACD Group (explicit/one step) • Log On to an ACD Group (explicit/two steps) • Log On to an ACD Group (implicit/one step) Note that if more than one type of model is present in the switching function, then the Get Logical Device Information service shall be used to determine the particular Log On models supported for each device which is or can be associated with an agent.
- 183 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name agentStateModels
Type Bitmap
M/ O/C
Description
O
Specifies the types of agent models that are supported by the switching function. If a bit is TRUE, then the specified agent model is supported by the switching function. The following is the list of bits (multiple bits may be set): • Agent Multi-State Model • Agent Multi-State Model (Semi-Independent Linked) • Agent Oriented Model Note that if more than one type of model is present in the switching function, then the Get Logical Device Information service shall be used to determine the particular Agent models supported for each ACD device or ACD group by the switching function.
connectionView
Enumerated
M
Specifies the meaning of the primary and secondary old call parameters in the Conferenced and Transferred events. The complete set of possible values is: • fixed view - the contents of the primary and secondary old call parameters are independent of the monitoring type and the role of the device in the conference or transfer. • local view - the contents of the primary and secondary old call parameters are dependent upon which device is being monitored. Refer to the descriptions of the Conferenced and the Transferred events for more information.
- 184 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name maxLengthParameters
Type List of Values
M/ O/C
Description
M
Each value is the switching function’s maximum length (in characters) for the corresponding parameters and parameter types. The computing function should not send larger data or the service request will be rejected. The following list provides the different parameters and parameter types for which a maximum value is provided. The number in parenthesis, where included, specifies the maximum possible length. • AccountInfo parameter type • AuthCode parameter type • AgentID parameter type • AgentPassword parameter type: • callID in the ConnectionID parameter type • CorrelatorData parameter type • CSTAPrivateData parameter type • Device Identifiers parameter types • UserData parameter type • buttonLabel parameters: • lampLabel parameters: • charactersToSend parameter: (64) If any of the above values is zero, then the parameter or parameter type is not supported.
maxLengthParametersContinued
List of Values
O
Each value is the switching function’s maximum length (in characters) for the corresponding parameters and parameter types. The computing function should not send larger data or the service request will be rejected. The following list provides the different parameters and parameter types for which a maximum value is provided. • MonitorCrossRefID parameter type • CallQualifyingData parameter type • subDomainCallLinkageID from CallLinkageData • subDomainThreadID from CallLinkageData • ioData parameters • MessageInfo parameter type If any of the above values is zero, then the parameter or parameter type is not supported.
- 185 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name servEvtsList
Type List
M/ O/C
Description
C
Specifies a list of capability bitmap parameter types corresponding to categories of services. Each bitmap entry in the lists represents a service or event that is supported by the switching function. This includes the following categories of services/events: • capExchangeServList (O) CapExchangeServList • systemStatusServList (O) SystemStatusServList • monitoringServList (O) MonitoringServList • snapshotServList (O) SnapshotServList • callControlServList (O) CallControlServList • callControlEvtsList (O) CallControlEvtsList • callAssociatedServList (O) CallAssociatedServList • callAssociatedEvtsList (O) CallAssociatedEvtsList • mediaServList (O) MediaServList • mediaEvtsList (O) MediaEvtsList • routeingServList (O) RouteingServList • physServList (O) PhysServList • physEvtsList (O) PhysEvtsList • logicalServList (O) LogicalServList • logicalEvtsList (O) LogicalEvtsList • deviceMaintEvtsList (O) DeviceMaintEvtsLis • ioServicesServList (O) IOServicesServList • dataCollectionServList (O) DataCollectionServList • voiceServList (O) VoiceServList • voiceEvtsList (O) VoiceEvtsList • cdrServList (O) CDRServList • vendorSpecificServList (O) VendorSpecificServList • vendorSpecificEvtsList (O) VendorSpecificEvtsList • statusReportingServList (O) StatusReportingServList • locServicesServList (O) LocServicesServList This parameter shall be provided if the switching function supports any of these categories of services/events. If a list entry is not included in the list, then the corresponding category of services/events is not supported by the switching function. The bitmap parameter types are described in Annex .
- 186 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name
Type
M/ O/C
Description
privateDataVersionList
List of Values
O
If the switching function supports the private data mechanism, this parameter provides the list of supported private data versions associated with the switching function manufacturer (manufacturerName).
systemStatusTimer
Value
C
Specifies a timer value indicating how often the switching function sends periodic system status requests to the computing function (i.e. heartbeats). This parameter has a value between 0 and 180 seconds. 0 means that the switching function does not send periodic System Status service requests. This parameter shall be provided if the switching function supports the heartbeat timer via the System Status service.
simpleThreshold
Value
O
Specifies the number of unacknowledged service requests that are allowed at any time for the switching function. 0 means there is no limit. If this parameter is not provided, the simpleThreshold is unknown.
filterThreshold
List of Values
O
Specifies a list of values representing the number of outstanding service requests, for every service defined in this specification, that are allowed at any time for each service. 0 means there is no limit. If this parameter is not provided, the filterThreshold is unknown.
- 187 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (continued) Parameter Name mediaServiceCapsList
Type
M/ O/C
Description
List of Structures
C
Specifies a list of structures of the media service types, version, media service instances, connection modes supported across the entire switching function. This parameter is a list, each element of which contains the following: • mediaServiceType (M) MediaServiceType A media service type used to identify the media service. • mediaSeviceVersion (O) Value - The version of the media service. • mediaServiceInstance (O) MediaServiceInstanceID - A media service instance associated with the media service. • connectionModeBMap (O) Bitmap - The media service connection modes supported for the media service type, version and instance. The following is the list of bits (multiple bits may be set): •
consultationConference
•
consultationConferenceHold
•
deflect
•
directedPickup
•
join
•
singleStepConference
•
singleStepConferenceHold
•
singleStepTransfer
•
transfer
•
direct
• mediaStreamIDSupported (M) Boolean Specifies if the mediaStreamID is supported for the combination of media service type, version, and instance. The complete set of values is: •
TRUE - indicates that the switching function shall provide the conditional mediaStreamID parameter where specified.
•
FALSE - indicates that the conditional mediaStreamID is not provided.
This parameter shall be provided if media access is supported by at least one of the devices in the switching function, otherwise it shall not be provided. maxDeviceHistoryEntries
Value
O
Specifies maximum number of entries supported by the switching function in the DeviceHistory parameter.
maxDestinationDevicesForDeflect
Value
O
Specifies the maximum number of new Destination devices supported by the switching function in the Deflect Call service request.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
- 188 -
Table 13-9 Get Switching Function Capabilities—Positive Acknowledgement (concluded) Parameter Name privateData
Type CSTAPrivateData
M/ O/C O
Description Specifies non-standardized information.
13.1.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 13.1.4.3 Operational Model 13.1.4.3.1 Connection State Transitions
There are no connection state changes as the result of this service. 13.1.4.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 13.1.4.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 189 -
13.1.5
Get Switching Function Devices
C
S
The Get Switching Function Devices service is used by the computing function to obtain the current set of devices in the application working domain along with their associated device categories and associated device names. 13.1.5.1 Service Request Table 13-10 Get Switching Function Devices—Service Request Parameter Name
Type
M/ O/C
Description
requestedDeviceID
DeviceID
O
Specifies the device identifier of the device being queried. If this parameter is not present, the switching function returns a list of all devices (of the requestedDeviceCategory, if that parameter is provided) in the switching sub-domain.
requestedDeviceCategory
Enumerated
O
Specifies that only devices of the requested category be provided. If this parameter is not present, the switching function will return a list of all devices (or just the requested device) in the switching function. The complete set of possible values is: • ACD • Group (ACD) • Group (Hunt) • Group (Pick) • Group (User) • Group (Agent) • Group (Other) • Network Interface • Park • Routeing Device • Station • Voice Unit • Generic Interactive Voice • Listener Interactive Voice • DTMF Interactive Voice • Prompt Interactive Voice • Prompt Queue Interactive Voice • Message Interactive Voice • Conference • Other
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
13.1.5.2 Service Response This service follows the multi-step acknowledgement model for this service request. 13.1.5.2.1 Positive Acknowledgement
The positive acknowledgement for the Get Switching Function Devices service indicates that one or more Switching Function Devices services will subsequently be generated by the switching function.
- 190 -
The computing function shall associate subsequent Switching Function Devices services to the original Get Switching Function Devices service by means of the serviceCrossRefID parameter. Table 13-11 Get Switching Function Devices—Positive Acknowledgement
Parameter Name
Type
M/ O/C
Description
serviceCrossRefID
ServiceCrossRefID
M
Specifies the correlator used to associate subsequent Switching Function Devices services to this service request.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
13.1.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 13.1.5.3 Operational Model 13.1.5.3.1 Connection State Transitions
There are no connection state changes as the result of this service. 13.1.5.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 13.1.5.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 13.1.5.3.4 Functional Requirements
1. Due to the nature of the switching function configuration, there may be a significant time interval between the generation of the positive acknowledgement for this service and the generation of the first Switching Function Devices service (or between a sequence of Switching Function Device services). 2. If there are no devices that meet the conditions in the service request, the switching function provides a Positive Acknowledgement to the Get Switching Function Devices service request followed by a Switching Function Devices service that includes the deviceList parameter with no devices. 3. The Switching Function Devices service returns all device identifiers that refer to all devices in the application working domain (i.e devices that can be controlled and/or observed).
- 191 -
13.1.6
Switching Function Devices
S C The Switching Function Devices service is used by the switching function to provide a list of devices in the application working domain. This service is generated as a result of the Get Switching Function Devices service.
The switching function may generate a sequence of Switching Function Devices services, individually referred to as segments, in response to a single Get Switching Function Devices service request. 13.1.6.1 Service Request Table 13-12 Switching Function Devices—Service Request Parameter Name
Type
M/ O/C
Description
serviceCrossRefID
ServiceCrossRefID
M
Specifies the cross reference used to associate the Switching Function Devices service request to the Get Switching Function Devices service request.
segmentID
Value
O
Specifies the segment number of this message. Each successive segment number in the sequence increments the segmentID by one.
lastSegment
Boolean
M
Specifies if this segment is the last one associated with the serviceCrossRefID. The complete set of possible values is: • TRUE - Indicates that this is the last segment. • FALSE - Indicates that this is not the last segment in the sequence.
- 192 -
Table 13-12 Switching Function Devices—Service Request (continued) Parameter Name deviceList
Type
M/ O/C
Description
List of Structures
M
Specifies the list of device Identifiers representing the devices that can be controlled and/or observed. It includes the following components for each device in the list: • deviceID (M) DeviceID - Specifies a Device Identifier associated with the entry in the list. • deviceCategory (O) Enumerated - Specifies the device category associated with the entry in the list. The complete set of possible values is: •
ACD
•
Group
•
Network Interface (e.g. trunk, CO Line)
•
Park
•
Routeing
•
Station (default)
•
Voice Unit
•
Generic Interactive Voice
•
Listener Interactive Voice
•
DTMF Interactive Voice
•
Prompt Interactive Voice
•
Prompt Queue Interactive Voice
•
Message Interactive Voice
•
Conference
•
Other
• namedDeviceTypes (O) Enumerated - indicates the named device type associated with the device in the service request. The complete set of possible values is:
- 193 -
•
ACD
•
ACD Group
•
Button
•
Button Group
•
Conference Bridge
•
Line
•
Line Group
•
Operator
•
Operator Group
•
Parking Device
•
Station
•
Station Group
•
Trunk
•
Trunk Group
•
Other
•
Other Group
Table 13-12 Switching Function Devices—Service Request (concluded) Parameter Name (continued)
Type
M/ O/C
(continued)
Description • deviceAttributes (O) Bitmap - Specifies additional attributes of the device associated with the entry in the list. This is a bit list of the following set of possible values (multiple bits may be set): •
mediaAccessDevice - indicates that the device is also a media access device
•
routeingDevice - indicates that the device is also a routeing device
•
Group (ACD) - indicates that the Group device has an ACD attribute (e.g. is an ACD Group)
•
Group (Hunt) - indicates that the Group device has a Hunt attribute
•
Group (Pick) - indicates that the Group device has a Pick attribute
•
Group (User) - indicates that the Group device has a User attribute
•
Group (Agent) - Indicates that the Group device has an Agent attribute
• deviceModelName (O) Characters - Specifies the switching function specific model name associated with the entry in the list. • nidGroup (O) DeviceID - Specifies the NID Group (trunk group, for example) that is associated with the NID. This component may only be provided when the deviceCategory is Network Interface. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
13.1.6.2 Service Response There are no service request completion conditions associated with this service. 13.1.6.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service request. 13.1.6.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 13.1.6.3 Operational Model 13.1.6.3.1 Connection State Transitions
There are no connection state changes as the result of this service. 13.1.6.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 13.1.6.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 13.1.6.3.4 Functional Requirements
1. Due to the nature of the switching function configuration, the switching function may buffer the Switching Function Devices messages to the computing function. The time between these messages may vary significantly between various implementations. 2. The deviceList parameter may be provided without any devices in the list by providing a single entry in deviceList with a null formatted deviceID (a deviceID with 0 characters). This could occur when there are no devices that meet the conditions provided in the Get Switching Function Devices service request.
- 194 -
3. The Switching Function Devices service returns all device identifiers that refer to all devices in the application working domain (i.e. devices that can be controlled and/or observed).
- 195 -
14
System Services This clause consists of: •
System Registration services
•
System services
NOTE This clause describes System Services between the Switching Function and the Computing Function.
14.1
Registration Services Table 14-1 System Registration Services Summary System Registration Service
Description
Pg.
14.1.1 Change System Status Filter
Changes the system status filter options for a current system registration.
197
14.1.2 System Register
Registers the computing function for system services with the switching function.
199
14.1.3 System Register Abort
Indicates that the switching function has terminated a system registration.
202
14.1.4 System Register Cancel
Unregisters the computing function for system services with the switching function.
203
14.2.5 Get Registrations
Obtains information about existing registrations.
211
14.2.6 Registration Info
Provides registration information in segmented messages.
214
- 196 -
14.1.1
Change System Status Filter
C
S
The Change System Status Filter service is used by the computing function to change the filter options for a current system registration. 14.1.1.1 Service Request Table 14-2 Change System Filter—Service Request Parameter Name
Type
M/ O/C
Description
sysStatRegisterID
SysStatRegisterID
M
Specifies the system registration identifier for which the status filter should be changed.
requestedStatusFilter
Bitmap
M
Specifies the requested System Status Types to be filtered (not sent) by the switching function. This parameter is a bitmap of the following values: • Initializing • Enabled • Normal • Messages Lost • Disabled • Partially Disabled • Overload Imminent • Overload Reached • Overload Relieved Multiple bits may be set.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.1.1.2 Service Response This service follows the atomic acknowledgement model for this service request. 14.1.1.2.1 Positive Acknowledgement Table 14-3 Change System Status Filter—Positive Acknowledgement Parameter Name actualStatusFilter
Type Bitmap
M/ O/C
Description
M
Specifies the actual set of System Status Types that will be filtered (not sent) by the switching function. This parameter is a bitmap with the same set of possible values as in the service request. The actualStatusFilter may differ from the requestedStatusFilter parameter in the service request (See Functional Requirement #2).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 14.1.1.3 Operational Model 14.1.1.3.1 Connection State Transitions
There are no connection state changes due to this service.
- 197 -
14.1.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.1.1.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.1.1.3.4 Functional Requirements
1. The requestedStatusFilter parameter allows the computing function to choose the System Status Types for which no System Status service requests should be issued by the switching function. This parameter only applies to the System Status service. If the System Status service has not been requested for this system registration, then the switching function shall send a negative acknowledgement to the Change System Status Filter service request. 2. An implementation that does not support all System Status Types will nevertheless accept the Change System Status Filter service even if the requested filter cannot be provided. The service acknowledgement indicates the actual set of System Status Types that will be filtered. This means that the actual set of filtered types returned in the positive acknowledgement may include additional types to be filtered (or fewer types generated by the switching function) than those requested in the service request.
- 198 -
14.1.2
System Register
C
S
The System Register service is used by the computing function to register to receive system services from the switching function. The computing function may be required to register for system services before it can receive any system service requests from the switching function. 14.1.2.1 Service Request Table 14-4 System Register—Service Request Parameter Name requestTypes
Type Bitmap
M/ O/C
Description
M
Specifies the system services that are being registered. This parameter is a bitmap of the following values: • System Status • Request System Status • Switching Function Capabilities Changed • Switching Function Devices Changed Multiple bits may be set.
requestedStatusFilter
Bitmap
C
Specifies the requested set of System Status Types to be filtered (not sent) by the switching function. This parameter is a bitmap of the following values: • Initializing • Enabled • Normal • Messages Lost • Disabled • Partially Disabled • Overload Imminent • Overload Reached • Overload Relieved Multiple bits may be set. This parameter is mandatory if the requestTypes parameter includes System Status, otherwise it shall not be provided.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.1.2.2 Service Response This service follows the atomic acknowledgement model for this service request.
- 199 -
14.1.2.2.1 Positive Acknowledgement Table 14-5 System Register—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
sysStatRegisterID
SysStatRegisterID
M
Specifies the system registration identifier for this registration.
actualStatusFilter
Bitmap
C
Specifies the actual set of System Status Types that will be filtered (not sent) by the switching function. This parameter is a bitmap with the same set of possible values as in the service request. The actual types filtered may differ from what was requested in the service request (See Functional Requirement #5). If the requestType parameter in the service request includes System Status, then this parameter is mandatory, otherwise it shall not be provided.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 14.1.2.3 Operational Model 14.1.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 14.1.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.1.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.1.2.3.4 Functional Requirements
1. The sysStatRegisterID parameter returned in the positive acknowledgement is used to identify the registration over which system services will be sent. The sysStatRegisterID is also used when cancelling the system registration. 2. The number of simultaneous system registrations allowed is switching function dependent. When the limit is reached, subsequent System Register service requests shall result in negative acknowledgements from the switching function. 3. The requestTypes parameter specifies which system services are to be issued by the switching function to the registering computing function. 4. The requestedStatusFilter parameter allows the computing function to choose the System Status Types for which no System Status service requests should be issued by the switching function. If the System Status service is not being requested (i.e., in the requestTypes parameter), then the actualStatusFilter parameter does not apply and shall not be provided. The actual system status filter is provided in the actualStatusFilter parameter in the positive acknowledgement. 5. An implementation that does not support all System Status Types will nevertheless accept the System Register service even if the requestedStatusFilter cannot be provided. The service acknowledgement indicates the actual set of System Status Types that will be filtered. This means that the actual set of filtered types returned in the positive acknowledgement may include additional types to be filtered (or fewer types generated by the switching function) than what was requested in the service request. - 200 -
6. If explicit registration is not supported, all system services (e.g., System Status, Request System Status) and System Status Types (e.g., Initializing, Enabled) supported by the switching function shall be provided to the computing functions. Note that the computing function shall be prepared to respond to a System Status service request from the switching function in such cases (because it has no way of specifying that it should not receive such requests). 7. Note that if a computing function registers for system services it shall support the ability to respond to any switching function System Status service requests it may receive. In particular, for implicit registrations, a CSTA-conformant computing function shall always be able to support such requests from the switching function.
- 201 -
14.1.3
System Register Abort
S
C
The System Register Abort service is used by the switching function to asynchronously cancel an active system registration. This service invalidates a current systems status registration. There is no positive acknowledgement defined for this service. 14.1.3.1 Service Request Table 14-6 System Register Abort—Service Request Parameter Name
Type
M/ O/C
Description
sysStatRegisterID
SysStatRegisterID
M
Specifies the system registration identifier for the system registration that was aborted.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.1.3.2 Service Response There are no service completion conditions for this service. 14.1.3.2.1 Positive Acknowledgement
There is no positive acknowledgement defined for this service. 14.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 14.1.3.3 Operational Model 14.1.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 14.1.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.1.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.1.3.3.4 Functional Requirements
1. The switching function may issue this service at any time when it can no longer maintain the system registration. 2. The computing function may send a negative acknowledgement to this service request, but no positive acknowledgement is defined.
- 202 -
14.1.4
System Register Cancel
C
S
The System Register Cancel service is used to cancel a previous system registration. This request terminates the system registration and the computing function receives no further system service requests for that system registration once it receives the positive acknowledgement to the System Register Cancel request. 14.1.4.1 Service Request Table 14-7 System Register Cancel—Service Request Parameter Name
Type
M/ O/C
Description
sysStatRegisterID
SysStatRegisterID
M
Specifies the system registration identifier for which the system registration is to be cancelled.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.1.4.2 Service Response This service follows the atomic acknowledgement model for this service request. 14.1.4.2.1 Positive Acknowledgement Table 14-8 System Register Cancel—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.1.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 14.1.4.3 Operational Model 14.1.4.3.1 Connection State Transitions
There are no connection state changes due to this service. 14.1.4.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.1.4.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.1.4.3.4 Functional Requirements
1. The computing function shall continue to process outstanding system requests from the switching function until it receives a positive acknowledgement for the System Register Cancel service request. The switching function shall not send any further system requests for a registration once it has sent the positive acknowledgement.
- 203 -
14.2
Services Table 14-9 System Services Summary System Service
Description
Pg.
14.2.1 Request System Status
Request to query the system status of the function receiving the request (bidirectional).
205
14.2.2 System Status
Request that reports the status of the function issuing the request to the function receiving the request (bi-directional). The indicated status may or may not have changed since the last System Status request was issued.
207
14.2.3 Switching Function Capabilities Changed
Request that reports that switching function level capability information (available via the Get Switching Function Capability service) has changed.
209
14.2.4 Switching Function Devices Changed
Request that reports that information associated with the current set of devices that can be controlled and observed in the switching sub-domain (available via the Get Switching Domain Devices service) has changed.
210
- 204 -
14.2.1
Request System Status
C
S
The Request System Status service is used by the computing function or switching function to obtain (i.e., query) the system status of its peer function. 14.2.1.1 Service Request Table 14-10 Request System Status—Service Request Parameter Name sysStatRegisterID
Type SysStatRegisterID
M/ O/C
Description
C
Specifies the system registration identifier associated with the system registration for this request. This parameter is mandatory if the switching function is issuing the request and supports system registration, and shall not be provided otherwise.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.2.1.2 Service Response This service follows the atomic acknowledgement model for this service request. 14.2.1.2.1 Positive Acknowledgement Table 14-11 Request System Status—Positive Acknowledgement Parameter Name systemStatus
Type Enumerated
M/ O/C
Description
M
Specifies the system status returned by the entity being queried. The complete set of possible values is: • Initializing • Enabled • Normal • Messages Lost • Disabled • Partially Disabled • Overload Imminent • Overload Reached • Overload Relieved See 12.2.28, “SystemStatus”, on page 144 for a description of these values.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.2.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 14.2.1.3 Operational Model 14.2.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 14.2.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.2.1.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 205 -
14.2.1.3.4 Functional Requirements
1. The systemStatus parameter in the positive acknowledgement provides the requesting function with information regarding the state of the overall system of the responding function. This information is important for proper system operation and should be processed accordingly. If the responding function has informed the requesting function that an overload condition is imminent then the requesting function should attempt to decrease the overall traffic to the responding function.
- 206 -
14.2.2
System Status
C
S
The System Status service is used by the computing function or switching function to report its system status to its peer function. The indicated status may or may not have changed since the last System Status request was issued. This service can also be used to implement a heartbeat mechanism between the two functions. 14.2.2.1 Service Request Table 14-12 System Status—Service Request Parameter Name sysStatRegisterID
Type SysStatRegisterID
M/ O/C
Description
C
Specifies the system registration identifier associated with the system registration for this request. This parameter is mandatory if the switching function is issuing the request and supports system registration, and shall not be provided otherwise.
systemStatus
Enumerated
M
Specifies the status of the function issuing the service request. The complete set of possible values is: • Initializing • Enabled • Normal • Messages Lost • Disabled • Partially Disabled • Overload Imminent • Overload Reached • Overload Relieved See 12.2.28, “SystemStatus”, on page 144 for a description of these values.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.2.2.2 Service Response This service follows the atomic acknowledgement model for this service request. 14.2.2.2.1 Positive Acknowledgement Table 14-13 System Status—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.2.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 14.2.2.3 Operational Model 14.2.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 14.2.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 207 -
14.2.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.2.2.3.4 Functional Requirements
1. The systemStatus parameter in the request provides the responding function with information regarding the state of the overall system of the requesting function. This information is important for proper system operation and should be processed accordingly. If the requesting function has informed the other function that an overload condition is imminent then the responding function should attempt to decrease the overall traffic to the requesting function. 2. The computing function can determine if the switching function uses the System Status service for periodic status reporting (i.e., heartbeats) using the capabilities exchange services. The Get Switching Function Capabilities service positive acknowledgement defines a parameter (systemStatusTimer) that is used to indicate whether periodic status reporting is used and if so, how often the computing function should expect the reports. The recovery action to be taken by the computing function in the event of a loss of heartbeats is implementation specific.
- 208 -
14.2.3
Switching Function Capabilities Changed
S
C
The Switching Function Capabilities Changed service is used to indicate that switching function level capability information available via the Get Switching Function Capability service has changed. The Get Switching Function Capability service may be used to obtain the revised information. 14.2.3.1 Service Request Table 14-14 Switching Function Capabilities Changed—Service Request Parameter Name sysStatRegisterID
Type SysStatRegisterID
M/ O/C
Description
C
Specifies the system registration identifier associated with the system registration for this request. This parameter is mandatory if the switching function supports system registration and shall not be provided otherwise.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.2.3.2 Service Response This service follows the atomic acknowledgement model for this service request. 14.2.3.2.1 Positive Acknowledgement Table 14-15 Switching Function Capabilities Changed—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.2.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 14.2.3.3 Operational Model 14.2.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 14.2.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.2.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.2.3.3.4 Functional Requirements
1. If supported by the switching function, the Switching Function Capabilities Changed service shall be sent whenever switching function level capability information has changed, whether or not the Get Switching Function Capabilities service has been previously issued.
- 209 -
14.2.4
Switching Function Devices Changed
S
C
The Switching Function Devices Changed service is used to indicate that information associated with the current set of devices that can be controlled and observed in the switching sub-domain has changed. The Get Switching Function Devices service may be used to obtain the revised information. 14.2.4.1 Service Request Table 14-16 Switching Function Devices Changed—Service Request Parameter Name sysStatRegisterID
Type SysStatRegisterID
M/ O/C
Description
C
Specifies the system registration identifier associated with the system registration for this request. This parameter is mandatory if the switching function supports system registration and shall not be provided otherwise.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.2.4.2 Service Response This service follows the atomic acknowledgement model for this service request. 14.2.4.2.1 Positive Acknowledgement Table 14-17 Switching Function Devices Changed—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.2.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 14.2.4.3 Operational Model 14.2.4.3.1 Connection State Transitions
There are no connection state changes due to this service. 14.2.4.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.2.4.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.2.4.3.4 Functional Requirements
1. If supported by the switching function, the Switching Function Devices Changed service shall be sent whenever switching function device information has changed, whether or not the Get Switching Function Devices service has been previously issued.
- 210 -
14.2.5
Get Registrations
C
S
The Get Registrations service is used to obtain information about switching function registrations for the CSTA application association. The registration information includes the registration type (System, Routeing, I/O, and Escape), the value of the registrationID associated with the registration, and the registration object (if it was specified when the registration was created). Registration information shall be provided using one of two possible mechanisms (as indicated by the capability exchange services): either in the Get Registrations positive acknowledgement or in one or more messages using the Registration Info Service. Note that both mechanisms cannot be used at the same time. 14.2.5.1 Service Request Table 14-18 Get Registrations—Service Request Parameter Name requestedRegTypes
Type
M/ O/C
List of RegistrationType
O
Description Specifies the requested types of registrations. This parameter consists of one or more of the following registration types: •
EscapeRegister - registrations for Escape services (see 29.1.1)
•
IORegister- registrations for I/O services (see 24.1.1)
•
RouteRegister - registration for Routeing services (see 20.1.1)
•
SysStatRegister - registration for System services (see 14.1.2)
If this parameter is omitted than information about all types of registration supported by the switching function are requested. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.2.5.2 Service Response This service follows the atomic acknowledgement model for this service request.
- 211 -
14.2.5.2.1 Positive Acknowledgement Table 14-19 Get Registrations—Positive Acknowledgement Parameter Name serviceCrossRefID
Type
M/ O/C
ServiceCrossRefID
C
Description Specifies the reference used to associate subsequent Registration Info services to this service request. This parameter is mandatory if the switching function is providing registration information in the Registration Info service, otherwise it shall not be provided.
registrationList
Structure
C
This parameter contains zero or more entries. Each entry contains information about an existing switching function registration that includes: •
registrationType (M) Enumeration - the type of registration: •
EscapeRegister - registration for Escape services (see 29.1.1)
•
IORegister- registration for I/O services (see 24.1.1)
•
RouteRegister- registration for Routeing services (see 20.1.1)
•
SysStatRegister - registration for System services (see 14.1.2)
•
registrationID (M) Characters - the value of the registrationID associated with the registration that was provided when the registration was created.
•
registrationObject (C) DeviceID - the object associated with the registration when the registration was created. The registrationObject is provided if the registration was created for a specific object otherwise it shall not be provided.
This parameter is mandatory if the switching function is providing all of the response information in this message. This parameter shall not be provided if the switching function is providing the response information using the Registration Info Service. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.2.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 14.2.5.3 Operational Model 14.2.5.3.1 Connection State Transitions
There are no connection state changes due to this service. 14.2.5.3.2 Monitoring Requirements
This service does not affect existing monitors. 14.2.5.3.3 Functional Requirements
1. This service can be used by the computing function to synchronize its view of registrations with existing registrations in the switching function e.g. after a System Status (Messages Lost) is received. a. If the computing function detects a registration that it no longer wants, it may use an appropriate service (e.g. Route Register Cancel) to cancel the registration.
- 212 -
b. If the computing function detects that a specific registration it expected is no longer present, it may create the registration via the appropriate service. 2. If the switching function is providing the registration information in multiple messages, it shall support the Registration Info service. In this case, the computing function can associate subsequent Registration Info services to the original Get Registrations service by means of the serviceCrossRefID parameter.
- 213 -
14.2.6
Registration Info
S
C
This service provides information about existing registrations in the switching function for the CSTA application association. This service is generated as a result of the Get Registrations service. It is used when the switching function is providing registration information in multiple messages (otherwise the switching function provides the registration information in the Get Registrations positive acknowledgement). The switching function may generate a sequence of Registration Info services, individually referred to as segments, in response to a single Get Registrations service request. 14.2.6.1 Service Request Table 14-20 Registration Info—Service Request Parameter Name
Type
M/ O/C
Description
serviceCrossRefID
ServiceCrossRefID
M
Specifies the reference used to associate the Registration Info service messages to the Get Registrations service request.
segmentID
Value
O
Specifies the segment number of this message. Each successive segment number in the sequence increments the segmentID by one.
lastSegment
Boolean
M
Specifies if this segment is the last one associated with the serviceCrossRefID. The complete set of possible values is: • TRUE - Indicates that this is the last segment. • FALSE - Indicates that this is not the last segment in the sequence.
registrationList
Structure
M
This parameter contains zero or more entries. Each entry contains information about an existing switching function registration that includes: •
registrationType (M) Enumeration - the type of registration: •
EscapeRegister - registration for Escape services (see 29.1.1)
•
IORegister- registration for I/O services (see 24.1.1)
•
RouteRegister- registration for Routeing services (see 20.1.1)
•
SysStatRegister - registration for System services (see 14.1.2)
•
registrationID (M) Characters - the value of the registrationID associated with the registration that was provided when the registration was created.
•
registrationObject (C) DeviceID - the object associated with the registration when the registration was created. The registrationObject is provided if the registration was created for a specific object otherwise it shall not be provided.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
14.2.6.2 Service Response There are no service request completion conditions associated with this service.
- 214 -
14.2.6.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service request. 14.2.6.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 14.2.6.3 Operational Model 14.2.6.3.1 Connection State Transitions
There are no connection state changes due to this service. 14.2.6.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.2.6.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 14.2.6.3.4 Functional Requirements
1. Due to the nature of the switching function configuration, the switching function may buffer the Registration Info messages to the computing function. The time between these messages may vary significantly between various implementations. 2. The information reported in the sequence of segments generated from the Get Registrations service request represents the state of the registrations at the time the Get Registrations service is positively acknowledged.
- 215 -
15
Monitoring Services NOTE This clause describes Monitoring Services between the Switching Function and the Computing Function.
15.1
Services Table 15-1 Monitoring Services Summary Monitoring Service
Description
Pg.
15.1.1 Change Monitor Filter
Modifies the event filter for an existing monitor.
217
15.1.2 Monitor Start
Initiates an event monitor on a specified device or call.
219
15.1.3 Monitor Stop
Terminates an existing monitor.
223
15.1.4 Get Monitors
Obtains a list of existing monitors.
224
15.1.5 Monitor Info
Provides Get Monitors response information in segmented messages
226
- 216 -
15.1.1
Change Monitor Filter
C
S
The Change Monitor Filter service is used to modify the set of event reports that are filtered out (not sent) over an existing monitor. The new set of filtered out (not sent) event reports may be listed in the service acknowledgement. 15.1.1.1 Service Request Table 15-2 Change Monitor Filter—Service Request Parameter Name
Type
M/ O/C
Description
crossRefIdentifier
MonitorCrossRefID
M
This indicates the monitor for which to change the filter.
requestedFilterList
MonitorFilter
M
This parameter specifies the requested set of events to be filtered out (not sent) by the server. It is a bitmap of all events defined in this Standard.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
15.1.1.2 Service Response This service follows the atomic acknowledgement model for this service request. 15.1.1.2.1 Positive Acknowledgement Table 15-3 Change Monitor Filter—Positive Acknowledgement Parameter Name actualFilterList
Type MonitorFilter
M/ O/C
Description
C
This parameter specifies the actual set of events that will be filtered out (not sent) by the server. It is a bitmap of all events defined in this Standard. The actual events filtered may differ from the requestedFilterList parameter on the service request (See Functional Requirement #1). This parameter is optional if the actualFilterList is the same as the requestedFilterList parameter on the service request, otherwise it is mandatory.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
15.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 15.1.1.3 Operational Model 15.1.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 15.1.1.3.2 Monitoring Requirements
1. Once a request has been acknowledged, a new set of events will be filtered out (not sent) by the server. 15.1.1.3.3 Functional Requirements
1. An implementation that does not support all event reports, or that does not support filtering will nevertheless accept the Change Monitor Filter service even if the requested filter cannot be provided. In this case, the service acknowledgement indicates the actual set of events that will be filtered out (not sent). This means that the actual set of filtered events returned in the positive acknowledgement may include additional events to be filtered out (or fewer monitored events supported for the monitor) than those requested in the service request. For example, an - 217 -
implementation that does not support event filtering responds to the Change Monitor Filter service with a filter that shows provided events as unfiltered and unimplemented events as filtered out. Similarly, an implementation that does not support, for example, Delivered events, shall always respond with a filter indicating that Delivered events will not be reported.
- 218 -
15.1.2
Monitor Start
C
S
The Monitor Start service initiates event reports (otherwise known as events) for a call, device, or for one or more calls involving a device. The server starts a monitor, allocates a Monitor Cross Reference Identifier that uniquely identifies the monitor, and then positively acknowledges the request. All activities satisfying the filter provided (for example: call, feature, agent, private) trigger events which are delivered as a stream of event reports to the server. Each event contains the Monitor Cross Reference Identifier that correlates the event back to the Monitor Start service that established the monitor. These event reports cease after the switching function terminates the monitor. Service termination can result from a client request (15.1.3, “Monitor Stop”, on page 223) or it can be initiated by the server. The switching function shall terminate the monitor if the monitorObject ceases to exist, or if the monitorObject leaves the switching sub-domain. There may be other conditions that cause the server to terminate the monitor. Once the monitor is terminated, the monitor cross reference ID is no longer valid. Please refer to 6.6.2, “Monitoring”, on page 65 for an overview of monitoring and related concepts such as monitor objects, monitor types, monitor call types, and monitor filters. 15.1.2.1 Service Request Table 15-4 Monitor Start—Service Request Parameter Name monitorObject
Type
M/ O/C
Description
Choice Structure
M
Specifies the monitor object of a call or device to be monitored. This shall be one of the following choices: • call (ConnectionID) - Specifies a call (connection) object. • device (DeviceID) - Specifies a device object. See Functional Requirement #5.
requestedMonitorFilter
MonitorFilter
O
This parameter specifies the requested set of events to be filtered out (not sent) by the switching function. It is a bitmap of all events defined in this Standard. If this parameter is not provided (or if the parameter is not supported by the switching function), then it shall mean that no filtering of events is requested (all events are requested).
monitorType
Enumerated
O
Specifies the type of monitor requested. The complete set of possible values is: • call-type • device-type If this parameter is not provided (or if the parameter is not supported by the switching function), then the monitor type shall be selected by the switching function (as indicated by the capabilities exchange services).
- 219 -
Table 15-4 Monitor Start—Service Request (concluded) Parameter Name
Type
M/ O/C
Description
O
Specifies the media classes (voice, digital data, Email, message, etc.) of calls that are being requested to be monitored for the monitorObject.
Bitmap
requestedMonitorMediaClass
Refer to the mediaClass component in 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete set of possible values. Note that multiple bits may be set. If this parameter is not provided (or if the parameter is not supported by the switching function), it is switching function dependent which media classes of calls are monitored. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
15.1.2.2 Service Response This service follows the atomic acknowledgement model for this service request. 15.1.2.2.1 Positive Acknowledgement Table 15-5 Monitor Start—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
crossRefIdentifier
MonitorCrossRefID
M
This indicates a value that is unique within the association for the duration of the monitor and that can be used to relate subsequent events to the monitor request that initiated them. It shall also allow correlating Monitor Stop and subsequent Change Monitor Filter services with the original Monitor Start service on which they act.
actualMonitorFilter
MonitorFilter
C
This parameter specifies the actual set of events that will be filtered (not sent) by the switching function. It is a bitmap of all events defined in this Standard. The actual events filtered out may differ from the filterList parameter on the service request (See Functional Requirement #1). If this parameter is supported by the switching function, it may be omitted if the requested and actual monitor filters are the same, otherwise it shall be provided. If the parameter is not supported by the switching function, then the switching function does not filter events and all events supported (as indicated by the capability exchange services) shall be sent for this monitor.
- 220 -
Table 15-5 Monitor Start—Positive Acknowledgement (concluded) Parameter Name actualMonitorMediaClass
Type Bitmap
M/ O/C
Description
C
This parameter specifies the actual media classes of calls that are monitored by the switching function for this monitor. The actual media classes of calls monitored may be the same or a subset of what was requested on the service request. If this parameter is supported by the switching function, it may be omitted if the requested and actual monitor media class parameters are the same otherwise it shall be provided. If the parameter is not supported by the switching function, then the switching function does not filter call types for specific monitors. The capability exchange services indicates the media classes of calls that can be monitored.
monitorExistingCalls
Boolean
O
Indicates whether or not the computing function will receive event reports regarding calls that are currently existing at the device at which the monitor was started. The complete set of possible values is: • TRUE - Indicates event reports will be provided for calls that are at the device at the time of the acknowledgement [Default]. • FALSE - Indicates event reports will not be provided for calls that are at the device at the time of the acknowledgement. This parameter is applicable to monitors that have devices as their object. For such monitors, if this parameter is not present (or the parameter is not supported), it means that the switching function always provides event reports for calls that are currently present at the device when the monitor was started.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
15.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 15.1.2.3 Operational Model 15.1.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 15.1.2.3.2 Monitoring Requirements
1. For call related events, events are provided for all devices associated with the call or device being monitored. For non-call related events, events are provided for the monitored device. 2. Once a call is monitored (irrespective of the monitor type or monitor object), all connection state changes that are known by the switching function are reported (subject to the Monitor Filter). •
For example, if device A is being monitored (with a device-type monitor) and a call is placed to device B (no monitor on B), then any connection state changes for either device A or B (such as when B receives the Delivered event and answers the call) will be reported through device A’s monitor.
- 221 -
•
Monitoring is only guaranteed for devices in the switching sub-domain. Activity related to devices outside the switching sub-domain may be only partially available or completely unreported.
3. Since some devices do not support all events, when a device enters a call that is being monitored with a call-type monitor, there may be a reduced set of event reporting associated with that monitor. 15.1.2.3.3 Functional Requirements
1. An implementation that does not support all event reports, or that does not support filtering will nevertheless accept the Monitor Start service even if the requested filter cannot be provided. In this case (if the actualMonitorFilter parameter is supported), the service acknowledgement indicates the actual set of events that will be filtered out. This means that the actual set of filtered events returned in the positive acknowledgement may include additional events to be filtered out (or less monitored events supported for the monitor) than those requested in the service request. For example, an implementation that does not support event filtering responds to the Monitor Start service with a filter that shows provided events as unfiltered and unimplemented events as filtered out. Similarly, an implementation that does not support, for example, Delivered events, shall respond with a filter indicating that Delivered events will not be reported. 2. If the switching function does not support the requestedMonitorFilter parameter (and the switching function is ignoring unsupported parameters, as defined by the capability exchange services), the computing function may receive events that it had requested to be filtered out. 3. When monitoring device configurations, refer to 6.1.5, “Referencing Devices, Elements, Appearances and Device Configurations”. 4. Events that occurred prior to the Monitor Start positive acknowledgement are not reported. 5. When a call-type monitor is requested and a connection identifier is being provided, the connection identifier may consist of only the callID. This is an exception to the general rule that deviceIDs are always provided in connectionIDs (refer to section 12.3.9, “ConnectionID”). 6. The Service Completion Failure event is only reported to device-type monitors on the device which has or had connection(s) that were used in the particular service request which is associated with this event (i.e., this event is not reported to any call-type monitors or device-type monitors for other devices in the call(s) associated with the service request). 7. If a computing function starts a monitor on a device, then issues another Monitor Start on the same device, the switching function will start a new monitor and will create a new Monitor Cross Reference Identifier. The new Monitor Start service request can be the same as the original or it may include a different Monitor Type or a different Monitor Filter. 8. The event reporting of the Failed event may vary depending on the given switching function. For the conditions under which the event reporting is limited, see section 6.7, “Additional Services, Features & Behaviour” and the Failed event section. 9. If filtering of the individual Private Events is desired, then the CSTA Private Data Information (privateData parameter) shall be used.
- 222 -
15.1.3
Monitor Stop
C
S
The Monitor Stop service is used to cancel a previously initiated Monitor Start service. The Monitor Stop service can be issued by a function to terminate or signal the termination of a corresponding Monitor Start service. A positive acknowledgement to the service request indicates that the Cross Reference ID used by the Monitor Start service has become invalid. 15.1.3.1 Service Request Table 15-6 Monitor Stop—Service Request Parameter Name
Type
M/ O/C
Description
crossRefIdentifier
MonitorCrossRefID
M
This indicates the Cross Reference Identifier provided in the original Monitor Start service positive acknowledgement.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
15.1.3.2 Service Response This service follows the atomic acknowledgement model for this service request. 15.1.3.2.1 Positive Acknowledgement Table 15-7 Monitor Stop—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
15.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 15.1.3.3 Operational Model 15.1.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 15.1.3.3.2 Monitoring Requirements
1. Once a request has been acknowledged, event reports are no longer sent. 15.1.3.3.3 Functional Requirements
1. This service can be sent to the function that requested a monitor to report that the monitor has been terminated. 2. The switching function may issue a Monitor Stop service when it can no longer provide information. Examples of when this may occur are: •
For monitors on calls that have ended (call monitoring).
•
For load management reasons.
•
If the monitor object leaves the switching sub-domain (via configuration, for example).
- 223 -
15.1.4
Get Monitors
C
S
The Get Monitors service is used to obtain information about switching function monitors for the CSTA application association. The monitor information includes the value of the monitor cross referenceID and the monitor object. Information shall be provided using one of two possible mechanisms (as indicated by the capability exchange services): either in the Get Monitors positive acknowledgement or in one or more messages using the Monitor Info Service. Note that both mechanisms cannot be used at the same time. 15.1.4.1 Service Request Table 15-8 Get Monitors—Service Request Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
15.1.4.2 Service Response This service follows the atomic acknowledgement model for this service request. 15.1.4.2.1 Positive Acknowledgement Table 15-9 Get Monitors—Positive Acknowledgement Parameter Name serviceCrossRefID
Type
M/ O/C
ServiceCrossRefID
C
Description Specifies the reference used to associate subsequent Monitor Info services to this service request. This parameter is mandatory if the switching function is providing the existing monitor information using the Monitor Info service, otherwise it shall not be provided.
monitorList
Structure
C
This parameter contains zero or more entries. Each entry contains information about an existing switching function monitor that includes: •
monitorCrossRefID (M) MonitorCrossRefID - the monitor cross referenceID that was provided when the monitor was created
•
monitorObject (M) DeviceID - the monitor object associated with the monitorCrossRefID
This parameter is mandatory if the switching function is providing all of the response information in this message. This parameter shall not be provided if the switching function is providing the response information using the Monitor Info Service. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
15.1.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 15.1.4.3 Operational Model 15.1.4.3.1 Connection State Transitions
There are no connection state changes due to this service. 15.1.4.3.2 Monitoring Requirements
This service does not affect existing monitors. - 224 -
15.1.4.3.3 Functional Requirements
1. This service can be used by the computing function to synchronize its view of monitors with existing monitors in the Switching Function e.g. after a System Status (Messages Lost) is received. a. If the computing function detects a monitor that it no longer wants, it may use the Monitor Stop service to stop the monitor. b. If the computing function detects that a specific monitor it expected is no longer present, it may create the monitor via the Monitor Start service. 2. If the switching function is providing the monitor information in multiple messages, it shall support the Monitor Info service. In this case, the computing function can associate subsequent Monitor Info services to the original Get Monitors service by means of the serviceCrossRefID parameter.
- 225 -
15.1.5
Monitor Info
S
C
The service provides information about existing monitors in the switching function for the CSTA application association. This service is generated as a result of the Get Monitors service. It is used when the switching function is providing monitor information in multiple messages (otherwise the switching function provides the monitor information in the Get Monitors positive acknowledgement). The switching function may generate a sequence of Monitor Info services, individually referred to as segments, in response to a single Get Monitors service request. 15.1.5.1 Service Request Table 15-10 Monitor Info—Service Request Parameter Name
Type
M/ O/C
Description
serviceCrossRefID
ServiceCrossRefID
M
Specifies the reference used to associate the Monitor Info service messages to the Get Monitors service request.
segmentID
Value
O
Specifies the segment number of this message. Each successive segment number in the sequence increments the segmentID by one.
lastSegment
Boolean
M
Specifies if this segment is the last one associated with the serviceCrossRefID. The complete set of possible values is: • TRUE - Indicates that this is the last segment. • FALSE - Indicates that this is not the last segment in the sequence.
monitorList
Structure
M
This parameter contains zero or more entries. Each entry contains information about an existing switching function monitor that includes: •
monitorCrossRefID (M) MonitorCrossRefID - the monitor cross referenceID that was provided when the monitor was created
•
monitorObject (M) DeviceID - the monitor object associated with the monitorCrossRefID
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
15.1.5.2 Service Response There are no service request completion conditions associated with this service. 15.1.5.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service request. 15.1.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 15.1.5.3 Operational Model 15.1.5.3.1 Connection State Transitions
There are no connection state changes due to this service. 15.1.5.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 15.1.5.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 226 -
15.1.5.3.4 Functional Requirements
1. Due to the nature of the switching function configuration, the switching function may buffer the Monitor Info messages to the computing function. The time between these messages may vary significantly between various implementations. 2. The information reported in the sequence of segments generated from the Get Monitors service request represents the state of the monitors at the time the Get Monitors service is positively acknowledged.
- 227 -
16
Snapshot Services NOTE This clause describes Snapshot Services between the Switching Function and the Computing Function.
16.1
Services Table 16-1 Snapshot Services Summary Snapshot Service
Description
Pg.
16.1.1 Snapshot Call
Provides information about the devices participating in a specified call.
229
16.1.2 Snapshot Device
Provides information on the status of calls at a specific device.
232
16.1.3 Snapshot CallData
Provides Snapshot Call Information in segmented messages.
235
16.1.4 Snapshot DeviceData
Provides Snapshot Device Information in segmented messages.
238
- 228 -
16.1.1
Snapshot Call
C
S
The Snapshot Call service provides information about the devices participating in a specified call. The information provided includes device identifiers, their connections in the call, and local connection states of the devices in the call as well as call related information. Information that applies to the entire call shall be provided in the Snapshot Call positive response. Information that is specific to each endpoint in the call (snapshotData parameter) shall be provided using one of two possible mechanisms (as indicated by the capability exchange services): either in the Snapshot Call positive acknowledgement or in one or more messages using the Snapshot CallData Service. Note that both mechanisms cannot be used at the same time. If the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), then for each connection in the call, this service provides the list of permitted call control services. 16.1.1.1 Service Request Table 16-2 Snapshot Call—Service Request Parameter Name
Type
M/ O/C
Description
snapshotObject
ConnectionID
M
This indicates the connectionID of the call to be snapshot. See Functional Requirement #2.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
16.1.1.2 Service Response This service follows the atomic acknowledgement model for this service request. 16.1.1.2.1 Positive Acknowledgement Table 16-3 Snapshot Call—Positive Acknowledgement Parameter Name serviceCrossRefID
Type ServiceCrossRefID
M/ O/C C
Description Specifies the reference used to associate subsequent Snapshot CallData services to this service request. This parameter is mandatory if the switching function is providing the snapshot information using the Snapshot CallData service, otherwise it shall not be provided.
- 229 -
Table 16-3 Snapshot Call—Positive Acknowledgement (continued) Parameter Name snapshotData
Type
M/ O/C
List of Structures
C
Description Specifies information for each endpoint in a call. This parameter is mandatory if the switching function is providing all of the response information in this message. This parameter shall not be provided if the switching function is providing the snapshot information using the Snapshot CallData Service. The complete set of possible information is: • deviceOnCall (M) DeviceID - Of a device involved with the endpoint. • connectionIdentifier (C) ConnectionID - For the endpoint. This is mandatory if the endpoint is in the switching sub-domain, otherwise it is optional. • localConnectionState (O) LocalConnectionState - For the endpoint. • servicesPermitted (C) ServicesPermitted - This is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange service). • mediaServiceInformationList (O) List of Structure Specifies information about the media services that are attached (bound to) the connection in the call. The complete set of possible information is: •
mediaServiceType (M) MediaServiceType - A media service type that has been bound to the connection.
•
mediaServiceVersion (O) Value. The version of the media services.
•
mediaServiceInstance (O) MediaServiceInstanceID - A media service instance associated with the media service bound to the connection.
•
mediaStreamID (C) MediaStreamID - The media stream identifier for the media service binding. This shall be provided if the switching function supports providing the mediaStreamID as indicated by the capability exchange services.
•
connectionInformation (O) ConnectionInformation - The connection information associated with the callIdentifier connection.
• locationInfo (O) LocationInfo - Specifies location information for the endpoint. mediaCallCharacteristics
MediaCallCharacteristics
O
This specifies the media class and data characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the list of possible values.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
callingDevice
CallingDeviceID
O
Specifies the calling device.
calledDevice
CalledDeviceID
O
Specifies the called device.
associatedCallingDevice
AssociatedCallingDeviceID
C
Specifies the Network Interface Device associated with the calling device if the call is an external incoming call. This parameter is mandatory for all external incoming calls and shall not be provided otherwise.
- 230 -
Table 16-3 Snapshot Call—Positive Acknowledgement (concluded) Parameter Name
Type
M/ O/C
Description
associatedCalledDevice
AssociatedCalledDeviceID
C
For outgoing external calls, this parameter specifies the Network Interface Device associated with the originally called device. For incoming external calls, this parameter specifies a device within the switching sub-domain associated with the originally called device. This parameter is mandatory for all external outgoing calls and it is optional for external incoming calls.
correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call.
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call. This could represent the subject header of an Email (text call) or intent for a voice call, for example.
messageInfo
MessageInfo
O
Specifies the contents of message information associated with a call. The message information consists of one of more items.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
deviceHistory
DeviceHistory
O
Specifies the list of devices which were previously associated with the call (e.g. redirecting, transferring, clearing devices).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
16.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 16.1.1.2.3 Operational Model 16.1.1.2.4 Connection State Transitions
There are no connection state changes due to this service. 16.1.1.2.5 Monitoring Requirements
This service does not affect existing monitors. 16.1.1.2.6 Functional Requirements
1. The Snapshot Call service is intended to provide information about devices in calls that makes further monitoring more meaningful. For example, if the computing function started working with a call, the event reports needed to provide synchronization may not occur for some time. To facilitate operations before an event report is available to synchronize the monitor, it is necessary to be able to query the current state of devices. Snapshot Call service provides this function. 2. The connection ID provided in the service may consist of only a callID portion. This is an exception to the rule of always providing deviceIDs in connectionIDs of service requests as described in 12.3.9, “ConnectionID”, on page 149. 3. If the switching function is providing the snapshot response information in multiple messages, it shall support the Snapshot CallData service. In this case, the computing function can associate subsequent Snapshot CallData services to the original Snapshot Call service by means of the serviceCrossRefID parameter.
- 231 -
16.1.2
Snapshot Device
C
S
The Snapshot Device service provides information about calls associated with a given device. The information provided identifies each call the device is participating in and the local connection state of the device in that call. The switching function shall provide the response information using one of two possible mechanisms (as indicated by the capability exchange services): either in the Snapshot Device positive acknowledgement or in one or more messages using the Snapshot DeviceData Service. Note that both mechanisms cannot be used at the same time. If the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), then for each connection at the device, this service provides the list of permitted call control services. 16.1.2.1 Service Request Table 16-4 Snapshot Device—Service Request Parameter Name
Type
M/ O/C
Description
snapshotObject
DeviceID
M
This indicates the deviceID of the device to be snapshot.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
16.1.2.2 Service Response This service follows the atomic acknowledgement model for this service request. 16.1.2.2.1 Positive Acknowledgement Table 16-5 Snapshot Device—Positive Acknowledgement Parameter Name serviceCrossRefID
Type
M/ O/C
ServiceCrossRefID
C
Description Specifies the reference used to associate subsequent Snapshot DeviceData services to this service request. This parameter is mandatory if the switching function is providing the snapshot device information using the Snapshot DeviceData service, otherwise it shall not be provided.
- 232 -
Table 16-5 Snapshot Device—Positive Acknowledgement (concluded) Parameter Name snapshotData
Type
M/ O/C
List of Structures
C
Description Specifies information for each call at a device. This parameter is mandatory if the switching function is providing all of the response information in this message. This parameter shall not be provided if the switching function is providing the response information using the Snapshot DeviceData Service. This complete set of information is: • connectionIdentifier (M) ConnectionID • endpointDevice (O) DeviceID - specifies the deviceID of the endpoint associated with the connectionIdentifier (see Functional Requirement #3). • localCallState (M) Choice Structure - This shall be one of the following choices: •
compoundCallState (List of LocalConnectionStates) - This consists of a sequence of local connection states.
•
simpleCallState (SimpleCallState) - the simple call state.
•
unknown
• servicesPermitted (C) ServicesPermitted - This is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services). • mediaServiceInformationList (O) List of Structures Specifies information about the media services that are attached (bound to) the connection in the call. The complete set of possible components is: •
mediaStreamID (C) MediaStreamID - The media stream identifier for the media service binding. This shall be provided if the switching function supports providing the mediaStreamID as indicated by the capability exchange services.
•
connectionInformation (O) ConnectionInformation - The connection information associated with the callIdentifier connection.
• mediaCallCharacteristics (O) MediaCallCharacteristics - specifies the media class and data characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the list of possible values. • callLinkageData (O) CallLinkageData - specifies the global call data and thread data associated with the call. security
CSTASecurityData
O
Specifies the timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
16.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 16.1.2.3 Operational Model 16.1.2.3.1 Connection State Transitions
There are no connection state changes due to this service.
- 233 -
16.1.2.3.2 Monitoring Requirements
This service does not affect existing monitors. 16.1.2.3.3 Functional Requirements
1. The Snapshot Device service is intended to provide information about devices to make further monitoring more meaningful. For example, when a computing function starts working with a device, the event reports needed to provide synchronization may not occur for some time. To facilitate operations before event reports synchronize the monitor, it is necessary to be able to query the current state of devices. Snapshot Device service provides that function. 2. If the switching function is providing the snapshot device response information in multiple messages, it shall support the Snapshot DeviceData service. In this case, the computing function can associate subsequent Snapshot DeviceData services to the original Snapshot Device service by means of the serviceCrossRefID parameter. 3. If the snapshotObject in the Snapshot Device service request is a group device, the endpointDevice in the snapshotData parameter indicates the device in the group associated with the connection.
- 234 -
16.1.3
Snapshot CallData
S
C
This service is generated as a result of the Snapshot Call service. It is used when the switching function is providing snapshot call information in multiple messages (otherwise the switching function provides the snapshot call information in the Snapshot Call positive acknowledgement). The information provided includes information about the endpoints in the call (information about the entire call is provided in the Snapshot Call positive response). The switching function may generate a sequence of Snapshot CallData services, individually referred to as segments, in response to a single Snapshot Call service request. 16.1.3.1 Service Request Table 16-6 Snapshot CallData—Service Request Parameter Name
Type
M/ O/C
Description
serviceCrossRefID
ServiceCrossRefID
M
Specifies the reference used to associate the Snapshot CallData service messages to the Snapshot Call service request.
segmentID
Value
O
Specifies the segment number of this message. Each successive segment number in the sequence increments the segmentID by one.
lastSegment
Boolean
M
Specifies if this segment is the last one associated with the serviceCrossRefID. The complete set of possible values is: • TRUE - Indicates that this is the last segment. • FALSE - Indicates that this is not the last segment in the sequence.
- 235 -
Table 16-6 Snapshot CallData—Service Request (concluded) Parameter Name snapshotData
Type
M/ O/C
List of Structures
M
Description Specifies information for each endpoint in a call. The complete set of possible information is: • deviceOnCall (M) DeviceID - Of a device involved with the endpoint. • connectionIdentifier (C) ConnectionID - For the endpoint. This is mandatory if the endpoint is in the switching sub-domain, otherwise it is optional. • localConnectionState (O) LocalConnectionState - For the endpoint. • servicesPermitted (C) ServicesPermitted - This is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange service). • mediaServiceInformationList (O) List of Structures Specifies information about the media services that are attached (bound to) the connection in the call. The complete set of components is: •
mediaServiceType (M) MediaServiceType - A media service type that has been bound to the connection.
•
mediaServiceVersion (O) Value. The version of the media services.
•
mediaServiceInstance (O) MediaServiceInstanceID - A media service instance associated with the media service bound to the connection.
•
mediaStreamID (C) MediaStreamID - The media stream identifier for the media service binding. This shall be provided if the switching function supports providing the mediaStreamID as indicated by the capability exchange services.
•
connectionInformation (O) ConnectionInformation - The connection information associated with the callIdentifier connection.
• locationInfo (O) LocationInfo - Specifies location information for the endpoint. • callLinkageData (O) CallLinkageData - specifies the global call data and thread data associated with the call. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
16.1.3.2 Service Response There are no service request completion conditions associated with this service. 16.1.3.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service request. 16.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 16.1.3.3 Operational Model 16.1.3.3.1 Connection State Transitions
There are no connection state changes due to this service.
- 236 -
16.1.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 16.1.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 16.1.3.3.4 Functional Requirements
1. Due to the nature of the switching function configuration, the switching function may buffer the Snapshot CallData messages to the computing function. The time between these messages may vary significantly between various implementations. 2. The switching function may include information for one or more endpoints in each segment. 3. The information reported in the sequence of segments generated from the Snapshot Call service request represents the state of the call at the time the Snapshot Call service is positively acknowledged.
- 237 -
16.1.4
Snapshot DeviceData
S
C
This service is generated as a result of the Snapshot Device service. It is used when the switching function is providing snapshot device response information in multiple messages (otherwise the switching function provides the snapshot device response in the Snapshot Device positive acknowledgement). This includes information about calls associated with a given device. The information provided identifies each call the device is participating in and the local connection state of the device in that call. The switching function may generate a sequence of Snapshot DeviceData services, individually referred to as segments, in response to a single Snapshot Device service request. 16.1.4.1 Service Request Table 16-7 Snapshot DeviceData—Service Request Parameter Name
Type
M/ O/C
Description
serviceCrossRefID
ServiceCrossRefID
M
Specifies the reference used to associate the Snapshot DeviceData service messages to the Snapshot Device service request.
segmentID
Value
O
Specifies the segment number of this message. Each successive segment number in the sequence increments the segmentID by one.
lastSegment
Boolean
M
Specifies if this segment is the last one associated with the serviceCrossRefID. The complete set of possible values is: • TRUE - Indicates that this is the last segment. • FALSE - Indicates that this is not the last segment in the sequence.
- 238 -
Table 16-7 Snapshot DeviceData—Service Request (concluded) Parameter Name snapshotData
Type
M/ O/C
List of Structures
M
Description Specifies information for each call at a device. This complete set of information is: • connectionIdentifier (M) ConnectionID • endpointDevice (O) DeviceID - specifies the deviceID of the endpoint associated with the connectionIdentifier (see Functional Requirement #4). • localCallState (M) Choice Structure - This shall be one of the following choices: •
compoundCallState (List of LocalConnectionStates) - This consists of a sequence of local connection states.
•
simpleCallState (SimpleCallState) - The simple call state.
•
unknown
• servicesPermitted (C) ServicesPermitted - This is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services). • mediaServiceInformationList (O) List of Structures Specifies information about the media services that are attached (bound to) the connection in the call. The complete set of possible components include: •
mediaStreamID (C) MediaStreamID - The media stream identifier for the media service binding. This shall be provided if the switching function supports providing the mediaStreamID as indicated by the capability exchange services.
•
connectionInformation (O) ConnectionInformation - The connection information associated with the callIdentifier connection
• MediaCallCharacteristics (O) MediaCallCharacteristics - specifies the media class and data characteristics of the call. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
16.1.4.2 Service Response There are no service request completion conditions associated with this service. 16.1.4.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service request. 16.1.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 16.1.4.3 Operational Model 16.1.4.3.1 Connection State Transitions
There are no connection state changes due to this service. 16.1.4.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 16.1.4.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 239 -
16.1.4.3.4 Functional Requirements
1. Due to the nature of the switching function configuration, the switching function may buffer the Snapshot DeviceData messages to the computing function. The time between these messages may vary significantly between various implementations. 2. The switching function may include information for one or more connections in each segment. 3. The information reported in the sequence of segments generated from the Snapshot Device service request represents the state of the device at the time the Snapshot Device service is positively acknowledged. 4. If the snapshotObject in the Snapshot Device service request is a group device, the endpointDevice in the snapshotData parameter indicates the device in the group associated with the connection.
- 240 -
17
Call Control Services & Events This clause describes the Call Control features of this Standard. It includes: •
Call Control services
•
Call Control events
For a description of fundamental concepts, such as connection states, please refer to 6.1.3 beginning on page 49.
17.1
Services Table 17-1 Call Control Services Summary Call Control Service
Description
Pg.
17.1.1 Accept Call
Causes an offered call to transition to the Ringing or Entering Distribution mode of the alerting state.
243
17.1.2 Alternate Call
Places an existing call on hold and then retrieves a previously held or alerting call at the same device.
245
17.1.3 Answer Call
Answers a call that is ringing, queued, or being offered to a device.
248
17.1.4 Call Back Call-Related
Allows a computing function to request that an originally called device return a call to the original calling device.
250
17.1.5 Call Back Message Call-Related
Allows a computing function to instruct the switching function to leave a pre-defined message requesting that the called device call the calling device.
253
17.1.6 Camp On Call
Queues a call at a busy device until the device becomes available.
256
17.1.7 Clear Call
Releases all of the devices associated with the specified call.
258
17.1.8 Clear Connection
Releases a specific device from a call.
261
17.1.9 Conference Call
Provides a conference of an existing held call and another active call at a conferencing device. The two calls are merged into a single call at the conferencing device.
265
17.1.10 Consultation Call
Places an existing active call at a device on hold and initiates a new call from the same device.
269
17.1.11 Deflect Call
Deflects a call to another device.
275
17.1.12 Dial Digits
Dials a digit sequence for a call that has already been initiated.
281
17.1.13 Directed Pickup Call
Picks a specified call. (Moves and connects a specified alerting or queued call.)
284
17.1.14 Group Pickup Call
Picks a call from a specified pick group. (Moves and connects any alerting call in a pick group to another device.)
288
17.1.15 Hold Call
Places a specific connection on hold.
292
17.1.16 Intrude Call
Allows a computing function to add the calling device to a call at a busy called device.
294
17.1.17 Join Call
Allows a computing function to request, on behalf of a device, that the device be joined into an existing call.
299
17.1.18 Make Call
Establishes a call between two devices.
304
17.1.19 Make Connection
Establishes a call with one device.
310
17.1.20 Make Predictive Call
Establishes a call between two devices. The calling device is presented with the call only after the called device is alerted or has answered the call.
315
17.1.21 Park Call
Parks a call at a specified device. (Moves and queues a connected call to another device).
321
17.1.22 Reconnect Call
Clears an existing connection and then connects a previously held connection at the same device.
324
17.1.23 Retrieve Call
Connects to a call that had previously been placed on hold.
326
17.1.24 Send Message
Sends a message to one or more devices.
328
- 241 -
Table 17-1 Call Control Services Summary (concluded) Call Control Service
Description
Pg.
17.1.25 Single Step Conference Call
Adds a device to an existing call.
333
17.1.26 Single Step Transfer Call
Replaces a device in an existing call with another device.
338
17.1.27 Transfer Call
Transfers a held call to the consulted party.
342
- 242 -
17.1.1
C
Accept Call
S
The Accept Call service causes an offered call to transit from the offered mode to the Ringing or Entering Distribution mode of the alerting state. Figure 17-1 Accept Call Service BEFORE SERVICE
D1 (alerting)
a
C1
AFTER SERVICE
D2 (calling)
*
D1
DEVICES D1 : alerting device D2 : calling device
a
C1
*
D2
AFFECTED CONNECTIONS D1C1 : callToBeAccepted connection CONNECTION STATES a : alerting state * : (unspecified/unaffected)
CALLS C1 : call that has been offered to D1
17.1.1.1 Service Request Table 17-2 Accept Call—Service Request Parameter Name callToBeAccepted
Type ConnectionID
M/ O/C M
Description Specifies the connection to be accepted.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.1.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.1.2.1 Positive Acknowledgement Table 17-3 Accept Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121.
- 243 -
17.1.1.3 Operational Model 17.1.1.3.1 Connection State Transitions Table 17-4 Accept Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (callToBeAccepted)
Alerting (Offered mode only)
Alerting (Ringing or Entering Distribution mode)
other connections (i.e., D2C1)
(Unspecified)
(Unaffected; no transition due to this service).
17.1.1.3.2 Device-Type Monitoring Event Sequences Table 17-5 Accept Call—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
Event Cause
D1 (Alerting device)
D1C1 (callToBeAccepted)
Delivered
Normal, Entering Distribution
D2 (Calling device or any other devices in call C1)
D1C1 (callToBeAccepted)
Delivered
Normal, Entering Distribution
17.1.1.3.3 Call-Type Monitoring Event Sequences Table 17-6 Accept Call—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1 (callToBeAccepted)
Event Delivered
Event Cause Normal, Entering Distribution
17.1.1.3.4 Functional Requirements
1. If the computing function wants to clear an active call prior to accepting an alerting call for a device, it shall first issue a Clear Connection service for the active call and then issue the Accept Call service for the alerting call.
- 244 -
17.1.2
C
Alternate Call
S
The Alternate Call service places an existing active call on hold and then retrieves a previously held call. This service is also used to place an active call on hold and then connect to an alerting or queued call at the same device (i.e., to answer a call-waiting call). Figure 17-2 Alternate Call Service BEFORE SERVICE
D1 (alternating)
AFTER SERVICE
c
C1
*
D2
a, h, q
C2
*
D3
D1
DEVICES D1 : alternating device D2 : device in call C1 with device D1 D3 : device in call C2 with device D1
h
C1
*
D2
c
C2
*
D3
AFFECTED CONNECTIONS D1C1 : activeCall connection D1C2 : heldCall connection CONNECTION STATES a : alerting state c : connected state h : hold state q : queued state * : (unspecified/unaffected)
CALLS C1 : originally active call C2 : originally held, alerting, or queued call
17.1.2.1 Service Request Table 17-7 Alternate Call—Service Request Parameter Name
Type
M/ O/C
Description
heldCall
ConnectionID
M
Specifies the held connection for the alternating device.
activeCall
ConnectionID
M
Specifies the active connection for the alternating device.
connectionReservation
Boolean
O
Specifies that the media stream channel(s) associated with the call being placed on hold be reserved for reuse at a later time. The complete set of possible values is: • True - channel(s) is to be reserved. • False - channel(s) is not to be reserved (default).
- 245 -
Table 17-7 Alternate Call—Service Request (concluded) Parameter Name
Type
consultOptions
Enumerated
M/ O/C
Description
O
This parameter indicates the potential actions following the Alternate Call so that certain facilities can be allocated prior to a Transfer or Conference. The complete set of possible values is: • Consult Only • Transfer Only • Conference Only • Unrestricted (default) If the switching function supports this parameter, the computing function shall supply one of the values supported. If the switching function does not support this parameter, the implicit value is Unrestricted. This parameter does not indicate a restriction or otherwise affect the switching function’s capabilities in any way with respect to services other than Transfer or Conference.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information.
17.1.2.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.2.2.1 Positive Acknowledgement Table 17-8 Alternate Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.2.3 Operational Model 17.1.2.3.1 Connection State Transitions Table 17-9 Alternate Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (activeCall)
Connected
Hold
D1C2 (heldCall)
Hold, Alerting, or Queued
Connected
other connections (i.e., D2C1, D3C2)
(Unspecified)
(Unaffected; no transition due to this service).
17.1.2.3.2 Device-Type Monitoring Event Sequences
Sequence of events using call-type monitoring is defined in Table 17-10 for the following cases: •
Case A: Call C2 is on Hold at device D1 (Alternating Device)
- 246 -
•
Case B: Call C2 is Alerting or Queued at device D1 (Alternating Device) Table 17-10 Alternate Call—Device-Type Monitoring Event Sequences (Case A and B) Monitored Device D1 (Alternating device)
Connection D1C1 (activeCall) D1C2 (heldCall)
Event Held
Transfer, Conference, Alternate, or Normal
Retrieved (Case A)
Transfer, Conference, Alternate, or Normal
Established (Case B) D2 (or any other devices in conference with D2)
D1C1 (activeCall)
D3 (or any other devices in conference with D3)
D1C2 (heldCall)
Event Cause
Held
Transfer, Conference, Alternate, or Normal
Retrieved (Case A)
Transfer, Conference, Alternate, or Normal
Established (Case B)
17.1.2.3.3 Call-Type Monitoring Event Sequences
Sequence of events using call-type monitoring is defined in Table 17-11 for the following cases: •
Case A: Call C2 is on Hold at device D1 (Alternating Device)
•
Case B: Call C2 is Alerting or Queued at device D1 (Alternating Device) Table 17-11 Alternate Call—Call-Type Monitoring Event Sequences (Case A and B) Monitored Call
Connection
C1 (originally active call)
D1C1 (activeCall)
C2 (originally held, alerting, or queued call)
D1C2 (heldCall)
Event
Event Cause
Held
Transfer, Conference, Alternate, or Normal
Retrieved (Case A)
Transfer, Conference, Alternate, or Normal
Established (Case B)
17.1.2.3.4 Functional Requirements
1. The Alternate Call service shall not be used to put an alerting call on hold and re-connect to another call that is on hold. 2. This service is a multiple step service that is equivalent to the computing function issuing the Hold Call service for the activeCall ConnectionID and then issuing one of the following services: a. a Retrieve Call service for the heldCall ConnectionID. b. an Answer Call service for the heldCall ConnectionID. c.
an Accept Call service for the heldCall ConnectionID.
3. The consultOptions parameter indicates the potential action following the Alternate Call service so that certain facilities can be allocated if a transfer or conference is desired. If the switching function supports the consultOptions parameter, the computing function shall provide one of the supported values of this parameter obtained through the capability exchange services. If the switching function requires preallocation of resources to support transfer or conference but is unable to allocate the resources required to support the indicated usage at this time, it shall reject the Alternate Call service request. This parameter does not indicate a restriction or otherwise affect the switching function’s capabilities in any way with respect to services other than Transfer or Conference. 4. If all appearances of a shared bridged device configuration are in the hold state and the heldCall parameter contains an appearance’s connection ID in the call, then the other appearances in the device configuration will return to the inactive mode (Queued state, Bridged Events).
- 247 -
17.1.3
C
Answer Call
S
The Answer Call service connects an alerting, queued, or initiated call. This service is typically associated with devices that have attached speakerphone units and headset telephones to connect to a call via hands-free operation. For example, when the call is answered, one of the following actions may occur: •
If the specified device has a speaker and a microphone, the speaker and microphone are turned on.
•
If the specified device only has a speaker, the speaker is turned on. The handset shall be picked up in order to have a two way conversation.
•
If there is no speaker, then the handset shall be picked up in order to have a two-way conversation.
•
If the specified device has a headset, the headset is turned on. Figure 17-3 Answer Call Service BEFORE SERVICE
D1 (alerting)
a, q, i
C1
*
AFTER SERVICE
D2 (calling)
DEVICES D1 : alerting device D2 : calling device
c
D1
C1
*
D2
AFFECTED CONNECTIONS D1C1 : callToBeAnswered connection CONNECTION STATES a : alerting state c : connected state i : initiated state q : queued state * : (unspecified/unaffected)
CALLS C1 : call that has been delivered to D1
Note that D1 may also be the calling device (e.g. Make Predictive Call). 17.1.3.1 Service Request Table 17-12 Answer Call—Service Request Parameter Name
Type
M/ O/C
Description
callToBeAnswered
ConnectionID
M
Specifies the connection to be answered.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.3.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 248 -
17.1.3.2.1 Positive Acknowledgement Table 17-13 Answer Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.3.3 Operational Model 17.1.3.3.1 Connection State Transitions Table 17-14 Answer Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (callToBeAnswered)
Alerting, Initiated, or Queued
Connected
other connections (i.e., D2C1)
(Unspecified)
(Unaffected; no transition due to this service).
17.1.3.3.2 Device-Type Monitoring Event Sequences Table 17-15 Answer Call—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
Event Cause
D1 (Alerting device)
D1C1 (callToBeAnswered)
Established
Normal
D2 (Calling device or any other devices in conference with D2)
D1C1 (callToBeAnswered)
Established
Normal
17.1.3.3.3 Call-Type Monitoring Event Sequences Table 17-16 Answer Call—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1 (callToBeAnswered)
Event Established
Event Cause Normal
17.1.3.3.4 Functional Requirements
1. If the computing function wants to clear an active call prior to answering an alerting or queued call for a device, it shall first issue a Clear Connection service for the active call and then issue the Answer Call service for the alerting or queued call.
- 249 -
17.1.4
C
Call Back Call-Related
S
The Call Back Call-Related service allows a computing function to request that the calling device retry the call to the called device when the called device is in an appropriate state to accept the call. As an example, the service might be used when a called device was busy so that the call is reattempted when the device becomes free. Figure 17-4 Call Back Call-Related Service BEFORE SERVICE
D1 (calling)
c
AFTER SERVICE
D2 (target)
a, f q, n
C1
D1
D2
f DEVICES
AFFECTED CONNECTIONS D1C1 : callbackConnection D2C1 : target connection “Call ID only” connectionID is provided.
D1 : calling device D2 : targetDevice CALLS C1 : original call
CONNECTION STATES a : alerting state c : connected state f : fail state q : queued state n : null state
Refer to 6.7.2, “Connection Failure”, on page 71 for a complete description of “Call ID only” connection IDs. 17.1.4.1 Service Request Table 17-17 Call Back Call-Related —Service Request Parameter Name
Type
M/ O/C
Description
callbackConnection
ConnectionID
M
Specifies the call back connection at the calling device.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (Priority call, for example) to be associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values. If the supported characteristics cannot be honoured, the switching function shall reject the service request.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences to be associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.4.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 250 -
17.1.4.2.1 Positive Acknowledgement Table 17-18 Call Back Call-Related—Positive Acknowledgement Parameter Name
Type
M/O/ C
Description
targetDevice
DeviceID
C
Specifies the deviceID of the device that the call back was initiated for. This parameter is mandatory if the switching function supports the Cancel Call Back service, otherwise it is optional.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.4.3 Operational Model 17.1.4.3.1 Connection State Transitions Table 17-19 Call Back Call-Related —Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (callback)
Connected
Null, Fail (see item #1)
D2C1 (called)
Fail, Alerting, Queued, or Null (e.g., null if call was forwarded or deflected from D2)
Null
1. A device may transition to the Fail state prior to Null if the device stays off-hook and receives busy or blocked tone. 2. In the case where a call is forwarded from a called device (busy forwarding, for example), it is switching function dependent if the call back request is placed on the called device or the device that the call was forwarded to.
- 251 -
17.1.4.3.2 Device-Type Monitoring Event Sequences Table 17-20 Call Back Call-Related—Device-Type Monitoring Event Sequences Monitored Device D1 (calling device)
Connection
Event
Event Cause
D2C1 (called)
Connection Cleared (See items #2 and #3)
Call Back or Normal Clearing
D1C1 (callback)
Connection Cleared (see items #1 and #2)
Call Back or Normal Clearing
D2C1 (called)
Connection Cleared (See items #2 and #3)
Call Back D2 (called device)
Call Back or Normal Clearing
17.1.4.3.3 Call-Type Monitoring Event Sequences Table 17-21 Call Back Call-Related—Call-Type Monitoring Event Sequences Monitored Call C1
Connection
Event
Event Cause
D2C1 (called)
Connection Cleared (see items #2 and #3)
Call Back or Normal Clearing
D1C1 (callback)
Connection Cleared (see items #1 and #2)
Call Back or Normal Clearing
(D1C1)
Call Cleared
Call Back or Normal Clearing
1. If a device stays off-hook and receives busy or blocked tone, the switching function sends the Failed event (event cause of Blocked or Busy) to indicate the status of the device, followed by a Connection Cleared event. 2. The exact sequence of the Connection Cleared events for this service is not specified. This is due to the fact that when multiple devices are removed from a call as a result of the service, each switching function may process the clearing of the devices in a different order. 3. This event is sent only if the connection associated with the called device was created. 4. The event sequence if the call is forwarded or deflected from D2 is not shown. 17.1.4.3.4 Functional Requirements
1. Call Back Call-Related is similar to the Camp On Call service. However for the Call Back CallRelated service the original call is cleared, but for the Camp On Call service, the call is queued. 2. Only one Call Back service request (Call-Related or Non-Call-Related) can be outstanding for any calling and called device pair. It is a switching function option (as indicated by the capability exchange services) if additional Call Back service requests (Call-Related or Non-Call-Related) for that pair result in a positive or negative acknowledgement from the switching function. 3. To cancel a Call Back (Call-Related or Non-Call-Related), the computing function shall issue the Cancel Call Back service, alternatively the Call Back should be manually canceled.
- 252 -
17.1.5
C
Call Back Message Call-Related
S
The Call Back Message Call-Related service allows a computing function to request that the switching function leave a pre-defined message requesting that the called device call the calling device. For example, the called device may have been busy when called. Figure 17-5 Call Back Message Call-Related Service BEFORE SERVICE
D1 (calling)
c
a, f q, n
C1
AFTER SERVICE
D2 (target)
D2
D1
f DEVICES
AFFECTED CONNECTIONS D1C1 : callbackMessageConnection D2C1 : target connection “Call ID only” connection ID is provided. CONNECTION STATES a : alerting state c : connected state f : fail state q : queued state n : null state
D1 : calling device D2 : targetDevice CALLS C1 : original call
Refer to 6.7.2, “Connection Failure”, on page 71 for a complete description of “Call ID only” connection IDs. 17.1.5.1 Service Request Table 17-22 Call Back Message Call-Related—Service Request Parameter Name
Type
M/ O/C
Description
callbackMessageConnection
ConnectionID
M
Specifies the call back message connection at the calling device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.5.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.5.2.1 Positive Acknowledgement Table 17-23 Call Back Message Call-Related—Positive Acknowledgement Parameter Name
Type
M/O/ C
Description
targetDevice
deviceID
C
Specifies the deviceID of the device that the call back message was left for. This parameter is mandatory if the switching function supports the Cancel Call Back Message service, otherwise it is optional.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 253 -
17.1.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.5.3 Operational Model 17.1.5.3.1 Connection State Transitions Table 17-24 Call Back Message Call-Related—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (callbackMessage)
Connected
Null, Fail (see item #1)
D2C1 (called)
Fail, Alerting, Queued, or Null (e.g., null if call was forwarded, deflected from D2)
Null
1. A device may transition to the Fail state prior to Null if the device stays offhook and receives busy or blocked tone. 2. In the case where a call is forwarded from a called device (busy forwarding, for example), it is switching function dependent if the call back request is placed on the called device or the device that the call was forwarded to. 17.1.5.3.2 Device-Type Monitoring Event Sequences Table 17-25 Call Back Message Call-Related—Device-Type Monitoring Event Sequences Monitored Device D1 (calling device)
Connection
Event
Event Cause
D2C1 (called)
Connection Cleared (see items #3 and #4)
Call Back or Normal Clearing
D1C1 (calling)
Connection Cleared (see items #2 and #4)
Call Back or Normal Clearing
D2C1 (called)
Connection Cleared (see items #3 and #4)
Call Back Message D2 (called device)
Call Back or Normal Clearing
17.1.5.3.3 Call-Type Monitoring Event Sequences Table 17-26 Call Back Message Call-Related—Call-Type Monitoring Event Sequences Monitored Call C1
Connection
Event
Event Cause
D2C1 (called)
Connection Cleared (see items #3 and #4)
Call Back or Normal Clearing
D1C1 (calling)
Connection Cleared (see items #2 and #4)
Call Back or Normal Clearing
(D1C1)
Call Cleared
Call Back or Normal Clearing
1. The event sequence if the call is forwarded or deflected from D2 is not shown. 2. If a device stays off-hook and receives busy or blocked tone, the switching function sends the Failed event (event cause of Blocked or Busy) to indicate the status of the device, followed by a Connection Cleared event. 3. This event is sent only if the connection associated with the called device was created. 4. The exact sequence of the Connection Cleared events for this service is not specified. This is due to the fact that when multiple devices are removed from a call as a result of the service, each switching function may process the clearing of the devices in a different order.
- 254 -
17.1.5.3.4 Functional Requirements
1. Only one Call Back Message service request (Call-Related or Non-Call-Related) can be outstanding for any calling and called device pair. It is a switching function option (as indicated by the capability exchange services) if additional Call Back Message service requests (Call-Related or Non-CallRelated) for that pair result in a positive or negative acknowledgement from the switching function. 2. To cancel a Call Back Message (Call-Related or Non-Call-Related), the computing function shall issue the Cancel Call Back Message service, alternatively the Call Back Message should be manually canceled. 3. The Call Back Message service (Call-Related or Non-Call-Related) differs from the Call Back service in that with the Call Back Message service, the calling device will not call back the called device. Instead, this service leaves a message at the called device. 4. The switching function defines the message left at the called device. A computing function cannot use the service to specify the message content or how the switching function will notify the user (e.g., text message, voice message, indicator only).
- 255 -
17.1.6
C
Camp On Call
S
The Camp On Call service allows the computing function to queue a call for a device (that typically is busy) until that device becomes available (after finishing a current call or any previously queued calls, for example). Figure 17-6 Camp On Call Service BEFORE SERVICE
D1 (calling)
c
f
C1
AFTER SERVICE
D2 (called)
D1
c
C1
q
D2
f
DEVICES D1 : calling device D2 : called device CALLS C1 : call attempting to connect to device D2
AFFECTED CONNECTIONS D1C1 : campon connection D2C1 : called connection “Call ID only” connectionID is provided. . CONNECTION STATES c : connected state f : fail state q : queued state
Refer to 6.7.2, “Connection Failure”, on page 71 for a complete description of “Call ID only” connection IDs. 17.1.6.1 Service Request Table 17-27 Camp On Call—Service Request Parameter Name
Type
M/ O/C
Description
camponConnection
ConnectionID
M
Specifies the connection of the calling device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.6.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.6.2.1 Positive Acknowledgement Table 17-28 Camp On Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.6.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121.
- 256 -
17.1.6.3 Operational Model 17.1.6.3.1 Connection State Transitions Table 17-29 Camp On Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (campon)
Connected
Connected
D2C1 (called)
Fail
Queued
17.1.6.3.2 Device-Type Monitoring Event Sequences Table 17-30 Camp On Call—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
Event Cause
D1 (Calling device)
D2C1 (campon)
Queued
Camp On or Camp On Trunks
D2 (Called device)
D2C1 (called)
Queued
Camp On or Camp On Trunks
17.1.6.3.3 Call-Type Monitoring Event Sequences Table 17-31 Camp On Call—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D2C1 (called)
Event Queued
Event Cause Camp On or Camp On Trunks
17.1.6.3.4 Functional Requirements
1. Only one Camp On Call feature can be active for any calling and called device pair. It is a switching function option (as indicated by the capability exchange services) if additional Camp On Call service requests for that pair result in a positive or negative acknowledgement from the switching function. 2. To cancel a Camp On Call service, the computing function can either: •
Issue the Clear Connection service or Clear Call service with the campon connection.
•
Have the calling device go on-hook.
Note that if the Camp On Call service is successfully cancelled, normal call progress messages of Connection Cleared (with an event cause of Normal Clearing) will be generated.
- 257 -
17.1.7
C
Clear Call
S
The Clear Call service releases all devices from an existing call. In the case of a conference call, this results in all devices in the conference call being released from the call. Figure 17-7 Clear Call Service BEFORE SERVICE
@
D1
C1
AFTER SERVICE
@
D2
@
D3
D1
D2
D3
DEVICES D1 : device in conference with D2 & D3 D2 : device in conference with D1 & D3 D3 : device in conference with D1 & D2 CALLS C1 : call to clear
AFFECTED CONNECTIONS D1C1 : D1’s connection with call C1 D2C1 : D2’s connection with call C1 D3C1 : D3’s connection with call C1 CONNECTION STATES @ : (non-null)
The callToBeCleared connection may be any connection in the call (i.e., D1C1, D2C1, D3C1). Note that some connections in the call may transit to the Failed state prior to the Null state. See “Connection State Transitions” on page 259. 17.1.7.1 Service Request Table 17-32 Clear Call—Service Request Parameter Name
Type
M/ O/C
Description
callToBeCleared 1
ConnectionID
M
Specifies the connection to be cleared.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
reason
EventCause
O
Specifies the reason the call is being cleared. See 12.2.15, “EventCause”, on page 132 for a list of possible values.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
1. The deviceID in the callToBeCleared ConnectionID may be omitted for this service.
17.1.7.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 258 -
17.1.7.2.1 Positive Acknowledgement Table 17-33 Clear Call— Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.7.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.7.3 Operational Model 17.1.7.3.1 Connection State Transitions Table 17-34 Clear Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1
(Any non-Null state)
Null, Failed (see item # 1)
D2C1
(Any non-Null state)
Null, Failed (see item # 1)
D3C1
(Any non-Null state)
Null, Failed (see item # 1)
1. A connection may transition to the Failed state prior to Null if the device stays off-hook and receives busy or blocked tone. The time between the state transition of Failed --> Null is device and switching function specific and the time may be substantial. Note that the service is completed when all connections transit to either the Null or the Failed state. 17.1.7.3.2 Device-Type Monitoring Event Sequences Table 17-35 Clear Call—Device-Type Monitoring Event Sequences Monitored Device D1
D2
D3 (and any other devices in call C1)
Connection D1C1
D2C1
D3C1
- 259 -
Event
Event Cause
Failed (Optional) (see item #3)
Blocked, or Normal or Busy
Connection Cleared (see items #1 and #2)
Normal Clearing
Failed (Optional) (see item #3)
Blocked, or Normal or Busy
Connection Cleared (see items #1 and #2)
Normal Clearing
Failed (Optional) (see item #3)
Blocked, or Normal or Busy
Connection Cleared (see items #1 and #2)
Normal Clearing
17.1.7.3.3 Call-Type Monitoring Event Sequences Table 17-36 Clear Call—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1
D2C1
D3C1
(D3C1)
Event
Event Cause
Failed (Optional) (see item #3)
Blocked, or Normal, or Busy
Connection Cleared (see item #2)
Normal Clearing
Failed (Optional) (see item #3)
Blocked, or Normal, or Busy
Connection Cleared (see item #2)
Normal Clearing
Failed (Optional) (see item #3)
Blocked, or Normal, or Busy
Connection Cleared (see item #2)
Normal Clearing
Call Cleared, once the last device has left the call. (Note that this event is only sent for call-type monitors.)
Normal Clearing
1. For device-type monitors, it is always guaranteed that the Connection Cleared event associated with the monitored device is provided, and that this is the last Connection Cleared event for the cleared call over the monitor. Depending on how the switching function processes the service request, Connection Cleared events for the other devices in the call may precede this last Connection Cleared event. 2. The exact sequence of the Connection Cleared events for this service is not specified. This is due to the fact that when multiple devices are removed from a call as a result of the service, each switching function may process the clearing of those devices in a different order. 3. If a device stays off-hook and receives busy or blocked tone, the switching function sends the Failed event (event cause of Blocked or Busy) to indicate the status of the device, followed by a Connection Cleared event. The time between the generation of the Failed event and the Connection Cleared event is device and switching function specific and the time may be substantial. As for generation of the Failed event for a given monitor and device in the call, it follows the same conditions as the Connection Cleared events (if the event is supported by the switching function): No events reporting connection transitions for other devices in the call will be sent. However, the Connection Cleared event for the given monitor will be sent (and will be the last event associated with the cleared call sent over that monitor) when the connection transits to Null. 17.1.7.3.4 Functional Requirements
1. The Clear Call service shall only affect the callToBeCleared ConnectionID’s call. Other calls that exist at the callToBeCleared ConnectionID’s device remain unaffected. 2. The connection ID provided in the request may consist of only a callID portion. This is an exception to the rule of not providing deviceIDs in connectionIDs of service requests (see 6.1.3, “Connection”, on page 49).
- 260 -
17.1.8
C
Clear Connection
S
The Clear Connection service releases a specific device from a call. In the case of a two-party call, this may result in the call being torn down. In the case of a conference call, this results in the specific party being removed from the conference. This service can also be used to inactivate a bridged appearance. The Connection ID provided in the request is released. Figure 17-8 Clear Connection Service BEFORE SERVICE
D1
*
AFTER SERVICE
*
D2
@
D3 (Clearing)
C1
D1
DEVICES D1 : device in conference with D2 & D3 D2 : device in conference with D1 & D3 D3 : clearing device CALLS C1 : existing call
*
*
D2
h, q, n
D3
C1
AFFECTED CONNECTIONS D3C1 : connectionToBeCleared CONNECTION STATES h : held state n : null state q : queued state @ : (non-null) * : (unspecified/unaffected)
17.1.8.1 Service Request Table 17-37 Clear Connection—Service Request Parameter Name
Type
M/ O/C
Description
connectionToBeCleared
ConnectionID
M
Specifies the connection to be cleared.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
reason
EventCause
O
Specifies the reason the connection is being cleared (busy, for example). See 12.2.15, “EventCause”, on page 132 for a list of possible values.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.8.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 261 -
17.1.8.2.1 Positive Acknowledgement Table 17-38 Clear Connection—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.8.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.8.3 Operational Model 17.1.8.3.1 Connection State Transitions Table 17-39 Clear Connection—Connection State Transitions Connection
Initial State (Required)
Final State
D3C1 (connectionToBe-Cleared)
(Any non-Null state)
Failed (See item #1), Held (See item #4), Null, Queued (See item #5)
other Connections in call C1 (i.e., D1C1, D2C1)
(Unspecified)
Null, Failed (See item #3).
1. A connection may transition to the Failed state prior to Null if the device stays off-hook and receives busy or blocked tone. The time between the state transition of Failed -> Null is device and switching function specific and the time may be substantial. 2. The Clear Connection service is completed when the connectionToBeCleared connection transits to either the Null, Failed, Held, or Queued state. 3. If the call involves only two connections or the call has parties outside the switching sub-domain, the other connection(s) may transition to Null or Failed. If the call involves more than two connections, the other connections remain unaffected. 4. The Held state is valid when a call is “suspended” for a time period prior to going to Null. 5. The Queued state is only valid for a shared bridged device configuration when there are other appearances connected into the call. 17.1.8.3.2 Device-Type Monitoring Event Sequences Table 17-40 Clear Connection—Device-Type Monitoring Event Sequences (Generic Case) Monitored Device
Connection
Event
Event Cause
D3 (clearingdevice)
D3C1 (connectionToBeCleared)
Failed (see item #2) Connection Cleared
Normal Clearing
D1
D3C1 (connectionToBeCleared)
Failed (see item #2)
Blocked, or Normal, or Busy
Connection Cleared
Normal Clearing
D3C1 (connectionToBeCleared)
Failed (see item #2)
Blocked, or Normal, or Busy
Connection Cleared
Normal Clearing
D2 and any other devices in call C1
- 262 -
Blocked, or Normal, or Busy
Table 17-41 Clear Connection—Device-Type Monitoring Event Sequences Associated with Shared Bridged Configurations 1 Monitored Device
Connection
Event
Event Cause
D3 (clearingdevice)
D3C1 (connectionToBeCleared)
Bridged
Normal
D1
D3C1 (connectionToBeCleared)
Bridged
Normal
D2 and any other devices in call C1
D3C1 (connectionToBeCleared)
Bridged
Normal
1. This event sequence only occurs when an appearance in the device configuration remains connected in the call after the service request.
Table 17-42 Clear Connection—Device-Type Monitoring Event Sequences Associated with Suspend Monitored Device D3 (clearingdevice)
Connection
Event
Event Cause
D3C1 (connectionToBeCleared)
Held
Suspend
Connection Cleared
Normal
D1
D3C1 (connectionToBeCleared)
Held
Suspend
Connection Cleared
Normal
D2 and any other devices in call C1
D3C1 (connectionToBeCleared)
Held
Suspend
Connection Cleared
Normal
17.1.8.3.3 Call-Type Monitoring Event Sequences Table 17-43 Clear Connection—Call-Type Monitoring Event Sequences (Generic Case) Monitored Call C1
Connection D3C1 (callToBeCleared)
Event
Event Cause
Failed (see item #2)
Blocked, or Normal, or Busy
Connection Cleared
Normal Clearing
Call Cleared (see item #1)
Table 17-44 Clear Connection—Call-Type Monitoring Event Sequences Associated with Shared Bridged Configurations Monitored Call C1
Connection D3C1 (callToBeCleared)
Event Bridged
Event Cause Normal
Note that the above sequence only occurs when an appearance in the device configuration remains connected in the call after the service request.
- 263 -
Table 17-45 Clear Connection—Call-Type Monitoring Event Sequences with Suspend Monitored Call C1
Connection D3C1(callToBeCleared)
Event
Event Cause
Held (see item #3)
Suspend
Connection Cleared
Normal Clearing
Call Cleared (see item #1)
Normal
1. For call-type monitors, if the connection being cleared is the last connection in the call then the Call Cleared event will be reported. 2. If a device stays off-hook and receives busy or blocked tone, the switching function sends the Failed event (event cause of Blocked or Busy) to indicate the status of the device, followed by a Connection Cleared event. The time between the generation of the Failed event and the Connection Cleared event is device and switching function specific and the time may be substantial. 3. Prior to going to Null, a switching function may “suspend” a cleared connection (and transition the connection to the Held state) for a time period. The time between the generation of the Held event and the Connection Cleared event is device and switching function specific and the time may be substantial. 17.1.8.3.4 Functional Requirements
1. If the call associated with Clear Connection service has multiple devices that are outside the switching sub-domain, they may remain connected after this service is complete. 2. When the last connected appearance in a shared bridged device configurations is cleared using the Clear Connection service, all other device configurations appearances are also cleared from the call (i.e., Connection Cleared events). 3. The switching function should only accept the Clear Call service request and not the Clear Connection service request if clearing a connection that is involved in a conference call causes the entire conference call to be terminated. However, some switching functions accept a Clear Connection service when it results in an entire conference call to be terminated. The capability exchange services indicate if the switching functions protects or allows a conference call from being torn down via the Clear Connection service. 4. The reason parameter in the service request indicates why a connection is being cleared. This information can be used by the switching function to provide more detailed information why a connection is being cleared via underlying call signalling protocols. For example: •
When an incoming call arrives at a device (i.e. an Offered event) and the application wants to reject the call because the device is busy, it can provide the reason of “busy”. This allows the underlying signalling protocol (to the external switching sub-domain, for example) to indicate to the calling device that the intended destination is busy. With this information, the calling device might provide a busy indication to its user.
- 264 -
17.1.9
C
Conference Call
S
The Conference Call service provides a conference of an existing held call and another active call at a conferencing device. The two calls are merged into a single call and the two connections at the conferencing device are resolved into a single connection. The Connection IDs formerly associated with the conferenced connections are released and a new Connection ID for the resulting connection is created. The existing held call may consist of one or more devices. Figure 17-9 Conference Call Service BEFORE SERVICE
D1 (conferencing)
AFTER SERVICE
c, h
C1
#
D2 (held)
c, h
C2
#
D3 (active)
DEVICES D1 : conferencing device D2 : held device D3 : active device CALLS C1 : held call C2 : active call C3 : resulting conference call
D1
c
C3
#
D2
#
D3
AFFECTED CONNECTIONS D1C1 : heldCall connection1 D1C2 : activeCall connection1 D1C3 : conferenceCall connection CONNECTION STATES c : connect state h : hold state # : (unspecified/inherited)
1. See the Connection State Transitions for the appropriate initial states for these connections.
17.1.9.1 Service Request Table 17-46 Conference Call—Service Request Parameter Name
Type
M/ O/C
Description
heldCall
ConnectionID
M
Specifies the held connection.
activeCall
ConnectionID
M
Specifies the active connection.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
In the case where both connections are in the Held or Connected state, one connection shall be the heldCall connection and the other connection shall be the activeCall connection. 17.1.9.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 265 -
17.1.9.2.1 Positive Acknowledgement Table 17-47 Conference Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
conferenceCall
ConnectionID
M
Specifies the resulting connection to the new call. The ConnectionID shall have the CallID of the resulting conference call and the DeviceID of the conferencing device.
connections
ConnectionList
O
Specifies information on each endpoint/ConnectionID that has changed as a result of the service.
conferenceCallInfo
ConnectionInformation
O
Specifies the connection information associated with the conferenceCall connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageDataList
List
O
Specifies the global call data and thread data associated with the call. The parameter consists of the following components: • newCallLinkageData (M) CallLinkageData - specifies the call linkage data associated with the resulting call. • oldCallLinkageData (M) CallLinkageData - specifies the call linkage data that was discarded as the result of the conference.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.9.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.9.3 Operational Model 17.1.9.3.1 Connection State Transitions Table 17-48 Conference Call—Connection State Transitions Connection D1C1 (heldCall)
Initial State (Required) Hold
Final State Null
Connected, only if activeCall connectionID is in the Connected state. D1C2 (activeCall)
Connected
Null
Hold, only if heldCall connectionID is in the Hold state. See item #2. D2C1 and other connections in call C1
(unspecified)
Null
D1C3
Null
Connected
D3C2
(unspecified)
Null
other connections in call C3
Null
(Inherited from the corresponding connections in C1 and C2)
1. New ConnectionIDs will be assigned to all devices that remain in the call due to the Conference. The final connection states of the new ConnectionIDs will be inherited from the states of the corresponding original calls, except for the conferencing device. 2. D1C2 can be in the Hold state, if D1C1 is also in the Hold state. This allows the conferencing of two held calls. - 266 -
3. D1C1 can be in the Connected state, if D1C2 is also in the Connected state (e.g. if D1 is a conference resource). This allows the conferencing of two connected calls. 17.1.9.3.2 Device-Type Monitoring Event Sequences Table 17-49 Conference Call—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
Event Cause
D1 (Conferencing device)
(see item #2)
Conferenced
Normal
D2 and any other devices in call C1 (held call)
(see item #2)
Conferenced
Normal
D3 and any other devices in call C2 (active call
(see item #2)
Conferenced
Normal
17.1.9.3.3 Call-Type Monitoring Event Sequences Table 17-50 Conference Call—Call-Type Monitoring Event Sequences Monitored Call
Connection
Event
Event Cause
C1
(see item #2)
Conferenced
Normal
C2
(see item #2)
Conferenced
Normal
1. For Device-Type Monitoring, a Connection Cleared event will not be seen for the activeCall or heldCall ConnectionIDs. The Conferenced event implies that the connections for these calls at this device are cleared. 2. There are multiple connections affected by this service. 17.1.9.3.4 Functional Requirements
1. The Conference service only affects the two calls specified on the service. If other calls exist at the conferencing device, they remain unaffected. 2. To get the connections for each of the devices to their initial states, the computing function can: •
Use the Consultation Call service to place a call on hold and place a new call.
•
Use the Alternate Call service to place a call on hold and answer an alerting call.
In either of these cases, if the switching function supports the consultOptions parameter in these services, the computing function shall provide this parameter with a value of either “Conference Only” or “Unrestricted”. Some switching function support a third approach for preparing for the Conference Call service involving the use of a hold service followed by a Make Call. The fourth approach supported by some switching functions involves two held calls at the same device. Certain switching functions also support a fifth approach involving two active calls at the same device. The computing function should use the capabilities exchange services to determine which of these approaches is supported by the switching function. 3. If the computing function uses the Consultation Call service to specify the consultOptions parameter with a value of Transfer, and then attempts to complete the consultation call with a Conference Call service, it will be rejected with a negative acknowledgement. 4. The appearances in a shared bridged device configuration are unaffected by this service. 5. The maximum number of devices in a conference is subject to switching function limits.
- 267 -
6. The computing function should never assume the reuse of callIDs, although some switching functions may reuse one or the other.
- 268 -
C
17.1.10 Consultation Call
S
The Consultation Call service places an existing active call at a device on hold and initiates a new call from the same device. The existing active call may include two or more devices. Figure 17-10 Consultation Call Service—Case A: Complete Dialling Sequence Provided BEFORE SERVICE
D1 (consulting)
c
*
C1
AFTER SERVICE
D2 (other)
D1
D3 (consulted device)
h
C1
*
c
C2
a, c, f, q, n
D2
D3
f DEVICES D1 : consulting device D2 : other device D3 : consulted device CALLS C1 : existing call C2 : initiated call
AFFECTED CONNECTIONS D1C1 : existingCall connection D1C2 : initiatedCall connection D3C2 : consultedCall connection - - - - - - “Call ID only” connectionID is provided CONNECTION STATES a : alerting state c : connected state f : failed state h : hold state q : queued state n : null state * : (unspecified/unaffected)
Figure 17-11 Consultation Call Service—Case B: Partial Dialling Sequence Provided
BEFORE SERVICE
D1 (consulting)
c
C1
AFTER SERVICE
*
D2 (other)
D3 (consulted device)
D1
h
C1
*
D2
i
C2
c, f, n
D3
f
DEVICES D1 : consulting device D2 : other device D3 : consulted device
AFFECTED CONNECTIONS D1C1 : existingCall connection D1C2 : initiatedCall connection - - - - - - “Call ID only” connectionID is provided CONNECTION STATES i : initiated state c : connected state h : hold state n : null state f : failed state * : (unspecified/unaffected)
CALLS C1 : existing call C2 : initiated call
Note that connected state (D3C2) exists when D3 is a NID.
- 269 -
Refer to 6.7.2, “Connection Failure”, on page 71 for a complete description of “Call ID only” connection IDs. 17.1.10.1 Service Request
Table 17-51 Consultation Call—Service Request Parameter Name
Type
M/ O/C
Description
existingCall
ConnectionID
M
Specifies the active connection.
consultedDevice
DeviceID
M
Specifies the device to be consulted.
connectionReservation
Boolean
O
Specifies that the media stream channel(s) associated with the call being placed on hold be reserved for reuse at a later time. The complete set of possible values is: • True - channel(s) is to be reserved. • False - channel(s) is not to be reserved (default).
accountCode
AccountInfo
O
Specifies the account code to associate with the consulted call.
authCode
AuthCode
O
Specifies the authorization code to allow the call.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (Priority call, for example) to be associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values. If the supported characteristics cannot be honoured, the switching function shall reject the service request.
mediaCallCharacteristics
MediaCallCharacteristics
O
This specifies the media characteristics to be associated with the call being made for the consultation. If this parameter is not present then the media class is Voice.
callingConnectionInfo
ConnectionInformation
O
This specifies the connection information needed for the creation of the new connection at the consulting device. If this parameter is not present then the connection information is switching function specific.
consultOptions
Enumerated
O
This parameter indicates the potential actions following the Consultation Call so that certain facilities can be allocated prior to a Transfer or Conference. The complete set of possible values is: • Consult Only • Transfer Only • Conference Only • Unrestricted (default) If the switching function supports this parameter, the computing function shall supply one of the values supported. If the switching function does not support this parameter, the implicit value is “Unrestricted”. This parameter does not indicate a restriction or otherwise affect the switching function’s capabilities in any way with respect to services other than Transfer or Conference.
subjectOfCall
SubjectOfCall
O
- 270 -
Specifies the subject/intent of the call.
Table 17-51 Consultation Call—Service Request (concluded) Parameter Name
Type
M/ O/C
Description
languagePreferences
LanguagePreferences
O
Specifies the language preferences to be associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.10.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.10.2.1Positive Acknowledgement Table 17-52 Consultation Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
initiatedCall
ConnectionID
M
Specifies the initial connection to the new call. The ConnectionID shall have the CallID of the resulting new call and the DeviceID of the consulting device.
mediaCallCharacteristics
MediaCallCharacteristics
C
This specifies the adjusted media characteristics for the call being made for the consultation. This parameter shall be provided if the media characteristics have been adjusted, otherwise the parameter is optional.
initiatedCallInfo
ConnectionInformation
O
This specifies the adjusted connection information used during the creation of the initiatedCall for the consulting device. If this parameter is not present then the connection information is switching function specific.
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.10.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.10.3 Operational Model 17.1.10.3.1Connection State Transitions Table 17-53 Consultation Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (existingCall)
Connected
Hold
D1C2 (initiatedCall)
Null
Initiated, Connected
D3C2 (consulted device)
Null
Alerting, Connected, Queued, Fail, or Null (Null if call moves away from the D3 (i.e., forwarded)).
Other connections in call C1 (existingCall) (i.e., D2C1)
(Unspecified)
(Unaffected; no transition due to this service).
1. When providing a partial dialling sequence (Case B), the connected state, for Device D3, only applies to external outbound calls. It indicates that enough of the dial string has been communicated for the switching function to connect the call to the network interface device that will be associated with the called device in the external network. - 271 -
17.1.10.3.2Device-Type Monitoring Event Sequences
There are two types of Device-Type Monitoring Event sequences depending on the dialling sequence used for the called device. •
Case A: The dialling sequence for the called device is the complete sequence for the device. Table 17-54 Consultation Call—Device-Type Monitoring Event Sequences (Case A) Monitored Device D1 (consulting device)
Connection
Event
Event Cause
D1C1
Held
Normal or Consultation or Conference or Transfer 1
D1C2
Service Initiated (optional)
Consultation or Conference or Transfer 1
D1C2
Originated
Consultation or Conference or Transfer 1
D3C2
Events depend on the type of consulted device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). 2
D2 and any other devices in C1 (original call)
D1C1
Held
D3 (consulted device)
D3C2
Events depend on the type of consulted device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). 2
Normal or Consultation or Conference or Transfer 1
1. The Conference event cause will only be present when the consultOptions parameter is set to “Conference Only.” The Transfer event cause will only be present when the consultOptions parameter is set to “Transfer Only.” 2. Providing of these events by the switching function does not affect the service completion conditions (i.e., a service is considered complete without these events being provided).
•
Case B: The dialling sequence for the called device is a partial sequence for the device. Table 17-55 Consultation Call—Device-Type Monitoring Event Sequences (Case B) Monitored Device D1 (consulting device)
Connection
Event
Event Cause
D1C1
Held
Normal or Consultation or Conference or Transfer 1
D1C2
Service Initiated (optional)
Consultation or Conference or Transfer 1
D1C2
Digits Dialled
Consultation or Conference or Transfer 1
D3C2
Events depend on the type of consulted device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). 2
D2 and any other devices in C1 (original call)
D1C1
Held
D3 (consulted device)
D3C2
Events depend on the type of consulted device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). 2
Normal or Consultation or Conference or Transfer 1
1. The Conference event cause will only be present when the consultOptions parameter is set to “Conference Only.” The Transfer event cause will only be present when the consultOptions parameter is set to “Transfer Only.” 2. Providing of these events by the switching function does not affect the service completion conditions (i.e., a service is considered complete without these events being provided).
- 272 -
17.1.10.3.3Call-Type Monitoring Event Sequences
There are two types of Device-Type Monitoring Event sequences depending on the dialling sequence used for the called device. •
Case A: The dialling sequence for the called device is the complete sequence for the device. Table 17-56 Consultation Call—Call-Type Monitoring Event Sequences (Case A) Monitored Call
Connection
Event
Event Cause
C1 (original call)
D1C1
Held
Normal or Consultation or Conference or Transfer 1
C2 (initiated call)
D1C2
Service Initiated (optional)
Consultation or Conference or Transfer 1
D1C2
Originated
Consultation or Conference or Transfer 1
D3C2
Events depend on the type of consulted device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). 2
1. The Conference event cause will only be present when the consultOptions parameter is set to “Conference Only.” The Transfer event cause will only be present when the consultOptions parameter is set to “Transfer Only.” 2. Providing of these events by the switching function does not affect the service completion conditions (i.e., a service is considered complete without these events being provided).
•
Case B: The dialling sequence for the called device is a partial sequence for the device. Table 17-57 Consultation Call—Call-Type Monitoring Event Sequences (Case B) Monitored Call
Connection
Event
Event Cause
C1 (original call)
D1C1
Held
Normal or Consultation or Conference or Transfer 1
C2 (initiated call)
D1C2
Service Initiated (optional)
Consultation or Conference or Transfer 1
D1C2
Digits Dialled
Consultation or Conference or Transfer 1
D3C2
Events depend on the type of consulted device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). 2
1. The Conference event cause will only be present when the consultOptions parameter is set to “Conference Only.” The Transfer event cause will only be present when the consultOptions parameter is set to “Transfer Only.” 2. Providing of these events by the switching function does not affect the service completion conditions (i.e., a service is considered complete without these events being provided).
17.1.10.3.4Functional Requirements
1. For the consultedDevice, all active features for this device will be honoured while the call is being made to it. 2. The consultOptions parameter indicates the potential action following the Consultation Call service so that certain facilities can be allocated if a transfer or conference is desired. If the switching function supports the consultOptions parameter, the computing function shall provide one of the supported values of this parameter obtained through the capability exchange services. If the switching function is unable to allocate the facilities for the requested Transfer or Conference, it will reject the Consultation Call service request. This parameter does not indicate a restriction or - 273 -
otherwise affect the switching function’s capabilities in any way with respect to services other than Transfer or Conference. 3. It is switching function specific whether a switching function may still accept a request for a Conference or Transfer if the consultOptions of Conference or Transfer was not requested as part of the Consultation Call service. 4. If the computing function specifies the consultOptions parameter with a value of Conference, then the computing function can not complete the consultation with a Transfer Call service or transfer feature. 5. If the computing function specifies the consultOptions parameter with a value of Transfer, then the computing function can not complete the consultation with a Conference Call service or conference feature. 6. The consultedDevice parameter may contain a device identifier of null or contain a Diallable Digits format (DD) device identifier that has a partial dialling sequence character (i.e., the “;” character) at the end of it. When this parameter is used in this manner, the computing function is indicating that it wishes to stage the dialling sequence. The completion of the dialling sequence can be accomplished either by entering the rest of the sequence manually at the actual device or the computing function can use the Dial Digits service to complete the sequence. As for the other types of consultedDevice parameter, they shall contain a complete dialling sequence. The switching function may have a timeout period for multi-stage dialling. If the dialling sequence does not complete prior to this timeout, it may either abort the call or attempt to use the digits already dialled and signal that dialling is complete with an originated event. 7. If the Consultation Call service is used to initiate a multistage dialling sequence, the computing function is signalled to continue the dialling sequence via either the Service Initiated event (i.e., the consultedDevice is Null) or the Digits Dialled event (i.e., the consultedDevice has a partial dialling sequence character). 8. A feature of initiating a digital data call as a result of this service (i.e., initiatedCall) is that the switching function may or may not adjust the digital data characteristics (e.g., connection rate) and connection information (e.g., number of channels) that were supplied on the Consultation Call service request (Use the capabilities exchange services to determine which feature the switching function supports). If the switching function does not support the adjusting of the characteristics/ connection information, the service request will be rejected with an appropriate error code in the negative acknowledgement. If the switching function does support the adjusting of the characteristics/connection information, the positive acknowledgement will contain the adjusted value or values. If the computing function determines that the adjusted values are not adequate, it can terminate the digital data call (e.g., Clear Call). 9. If the computing function makes a digital data call using this service and wants to also bind a particular Media Service to the call, then the computing function shall use the Media Attach service.
- 274 -
17.1.11
C
Deflect Call
S
The Deflect Call service allows the computing function to divert a call to one or more destinations that may be inside or outside the switching sub-domain. Deflecting a call to multiple devices may result in multiple devices being involved in the call (e.g. simultaneously alerted). Once a call is answered at any one of these destination devices all other destination devices are cleared from the call. Figure 17-12 Deflect Call Service - Case A Deflect to a Single Destination BEFORE SERVICE
D1 (called)
a, c f, h, q
C1
*
D3 (newDestination)
AFTER SERVICE
D2 (calling)
D1
C1
D2
a, c f, q, n
D3
DEVICES D1 : called device D2 : calling device D3 : newDestination device CALLS C1 : call to be diverted
*
AFFECTED CONNECTIONS D1C1 : callToBeDiverted connection D3C1 : newDestination connection CONNECTION STATES a : alerting state c : connected state h : held state q : queued state f : failed state n : null : (unspecified/unaffected)
*
Note that D1 may also be the calling device. Note that (Case A) the call is diverted to a single destination that is provided in the service request. The single destination may represent a group-type device such as a Hunt group (see Clause 6.1.1.4.5, “Group Device Category”, on page 26).
- 275 -
Figure 17-13 Deflect Call Service-Case B: Deflect to Multiple Destinations BEFORE SERVICE
D1 (called)
a, c f, h, q
C1
AFTER SERVICE (Multiple Destination Devices in Call)
*
D3 (newDestination)
D2 (calling)
D1
D4
D3
(newDestination)
C1
*
a, f, q, n
a, f q, n
D2
D4
After Call Reverts to a Single Destination Device Call
D1
C1
c, n f, a, q
D3
DEVICES D1 : called device D2 : calling device D3 : newDestination device D4 : newDestination device CALLS C1 : call to be diverted
*
D2
D4
AFFECTED CONNECTIONS D1C1 : callToBeDiverted connection D3C1 : newDestination connection D4C1 : newDestination connection CONNECTION STATES a : alerting state c : connected state h : held state q : queued state f : failed state n : null * : unspecified/unaffected
Note that (Case B) the call is diverted to multiple destinations that are provided in the service request. The figure shows multiple devices involved with the call at the same time. After certain conditions (see Functional Requirement #9) the call reverts to a single destination device call and the other devices are cleared from the call. 17.1.11.1 Service Request Table 17-58 Deflect Call—Service Request Parameter Name
Type
M/ O/C
Description
callToBeDiverted
ConnectionID
M
Specifies the connection to be diverted.
newDestination
List of DeviceIDs
M
Specifies one or more devices to which the call is to be diverted (newDestination device).
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
- 276 -
Table 17-58 Deflect Call—Service Request (concluded) Parameter Name callCharacteristics
Type CallCharacteristics
M/ O/C
Description
O
Specifies the high level characteristics (Priority call, for example) to be associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values. If the supported characteristics cannot be honoured, the switching function shall reject the service request.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences to be associated with the call.
reason
EventCause
O
Specifies the reason the connection is being diverted. See 12.2.15, “EventCause”, on page 132 for a list of possible values.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.11.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.11.2.1Positive Acknowledgement Table 17-59 Deflect Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.11.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.11.3 Operational Model 17.1.11.3.1Connection State Transitions Table 17-60 Deflect Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (callToBeDiverted)
Alerting, Connected, Failed, Held, Queued
Null
D2C1 (calling device)
(Unspecified)
Unaffected; no transition due to this service.
D3C1 (newDestination) and all other destination devices (in the case of deflect to multiple destinations)
Null
Alerting, Connected, Queued, Failed, or Null (Null if call moves away from D3 (i.e., forwarded)).
17.1.11.3.2Device-Type Monitoring Event Sequences Table 17-61 Deflect Call—Device-Type Monitoring Event Sequences Case A - Deflect to a Single Device Monitored Device D1 (called device)
Connection D1C1 (callToBeDiverted)
- 277 -
Event Diverted (see item #3)
Event Cause Redirected or Normal
Table 17-61 Deflect Call—Device-Type Monitoring Event Sequences Case A - Deflect to a Single Device (concluded) Monitored Device D2 (calling device)
D3 (newDestination device)
Connection
Event
Event Cause
D1C1
Diverted (optional) (see items #2 and #3)
Redirected or Normal
D3C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #4)
D3C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #4)
Table 17-62 Deflect Call—Device-Type Monitoring Event Sequences Case B - Deflect to Multiple Devices Monitored Device
Connection
Event
Event Cause
D1 (called device)
D1C1 (callToBeDiverted)
Diverted (see item #3)
Redirected or Normal
D2 (calling device)
D1C1
Diverted (optional) (see items #2 and #3)
Redirected or Normal
D3C1, D4C1(and all other destination devices)
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #4)
D3C1 (and any other destination devices that are cleared when there is still a destination device involved with a call)
Connection Cleared (see item #4)
D4C1
Established (after the call is answered)
Multiple Alerting
(see Item #4) D4 (newDestination device)
D3 (newDestination device) and all other destination devices
D4C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #4)
D4C1
Established (after the call is answered) (see item #4)
D3C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #4)
D3C1 (and any other destination devices that are cleared when there is still a destination device involved with a call)
Connection Cleared (see item #4)
- 278 -
Multiple Alerting
17.1.11.3.3Call-Type Monitoring Event Sequences Table 17-63 Deflect Call—Call-Type Monitoring Event Sequences - Case A - Deflect to a Single Device Monitored Call C1
Connection
Event
Event Cause
D1C1
Diverted (optional) (see items #1 and #3)
Redirected or Normal
D3C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #4)
Table 17-64 Deflect Call—Call-Type Monitoring Event Sequences - Case B - Deflect to Multiple Devices Monitored Call C1
Connection
Event
Event Cause
D1C1
Diverted (optional) (see items #1 and #3)
Redirected or Normal
D3C1, D4C1(and all other destination devices)
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #4)
D3C1 (and any other destination devices that are cleared when there is still a destination device involved with a call)
Connection Cleared (see item #4)
D4C1
Established (after the call is answered)
Multiple Alerting
(see Item #4)
1. The switching function provides the Diverted event for C1 only if it is providing Diverted events for call-type monitors. This is indicated through the capabilities exchange services. 2. The switching function provides the Diverted event for D2 only if it is providing Diverted events for all devices in the call. This is indicated through the capabilities exchange services. 3. A Connection Cleared Event will not be provided for D1 (called device). The Diverted event implies the ConnectionID has gone to Null. 4. Providing of these events by the switching function does not affect the service completion conditions (i.e., a service is considered complete without these events being provided). 17.1.11.3.4Functional Requirements
1. The Deflect Call service differs from the (Directed and Group) Pickup services in that the Pickup services redirects a call from a device and connects it to a specified device. 2. The Deflect Call service only affects the callToBeDiverted ConnectionID’s call. If other calls exist at the callToBeDiverted ConnectionID’s device, they remain unaffected. 3. For the newDestination, all active features for this device (or devices for Case B) will be honoured while the call is being deflected to it. For example, due to active features at the called device, the call may or may not be deflected to the new destination device. 4. As a result of the Deflect Call service, the call ID associated with this call remains unchanged. 5. If the callToBeDiverted connection identifier is associated with a shared bridged device configuration appearance in the queued state (i.e., inactive mode), then the service request will be rejected with a negative acknowledgement. - 279 -
6. This service request does not support the use of a null device identifier or a Diallable Digits format (DD) device identifier that has a partial dialling sequence character (i.e., the “;” character) in it for the newDestination parameter. A complete and valid device identifier shall be provided, otherwise the switching function will reject the service request with a negative acknowledgement. 7. If this service is used to deflect a digital data call, the connection for the newDestination will inherit the characteristics of the call. 8. When a Switching Function provides a positive acknowledgement to the service request that contains multiple destination devices (Case B), the Switching Function shall provide call control events (e.g. Delivered, Failed, Queued, Diverted) for all of the destination device connections based upon the features and state of the individual destination devices. If the Switching Function cannot provide events for all of the destination devices it shall provide a negative acknowledgement to the service request. 9. When a call is deflected to multiple destinations (Case B), multiple destination devices may be part of the call at the same time (e.g. multiple alerting feature). The Switching Function shall revert a multiple destination devices call to a single destination call: a. After one of the destination devices answers the call, then the Switching Function shall clear the remaining destination devices from the call. b. After a Switching Function timeout, a multiple destination devices call may revert to a single destination call. c.
When a computing function attempts to deflect one of the connections already involved in a multiple destination call via the Deflect Call service, the Switching Function shall first revert the call to a single destination call by clearing all of the other destination devices from the call except for the callToBeDiverted connection. After the call has been reverted to a single destination call, the Switching Function shall process the new Deflect Call service.
10. When a destination device is cleared from a call involving multiple destinations (Case B) and at least one destination is still involved with the call, the Switching Function shall indicate this by sending a Connection Cleared event with an event cause of Multiple Alerting.
- 280 -
C
17.1.12 Dial Digits
S
The Dial Digits service allows the computing function to perform a dialling sequence that is associated with a call that has already been initiated (i.e., has manually gone off-hook or has been initiated via a Make Call or Consultation Call service). This service is also used to perform the dialling sequences associated with completing a multi-stage dialled call. Figure 17-14 Dial Digits Service BEFORE SERVICE
D1 (dialling)
i
C1
c, n
AFTER SERVICE
D2 (called)
D1
c, i
C1
a, c, f, n, q
D2
f DEVICES D1 : dialling device D2 : called device CALLS C1 : existing call
AFFECTED CONNECTIONS D1C1 : diallingConnection D2C1 : called connection ------- “Call ID only” connectionID is provided. CONNECTION STATES a : alerting state c : connected state f : failed state i : initiated state n : null state
Note that the initial state of connected for connection D2C1 exists when D2 is a NID. Refer to 6.7.2, “Connection Failure”, on page 71 for a complete description of “Call ID only” connection IDs. 17.1.12.1 Service Request Table 17-65 Dial Digits—Service Request Parameter Name
Type
M/ O/C
Description
diallingConnection
ConnectionID
M
Specifies the connection which is dialling the digits.
diallingSequence
DeviceID
M
Specifies the actual string of digits to be dialled. To specify a partial dialling sequence, the Diallable Digits format (DD) of the DeviceID with the “;” character as the last digit in the string shall be used.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.12.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 281 -
17.1.12.2.1Positive Acknowledgement Table 17-66 Dial Digits—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.12.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.12.3 Operational Model 17.1.12.3.1Connection State Transitions Table 17-67 Dial Digits—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (dialling)
Initiated
Initiated, Connected
D2C1 (called)
Null, Connected (The connected state only applies to external outbound calls. It indicates that enough of the dial string has been communicated for the switching function to connect the call to the network interface device that will be associated with the called device in the external network.)
Alerting, Connected, Failed, Queued, or Null (Null if call moves away from D3 (i.e., forwarded).
17.1.12.3.2Device-Type Monitoring Event Sequences Table 17-68 Dial Digits—Device-Type Monitoring Event Sequences Monitored Device D1 (dialling device)
D2 (called device)
Connection
Event
Cause Code
D1C1
Digits Dialled (see item #1)
Normal or Network Dialling
D1C1
Originated (when the dialling sequence is complete and the D1C1 connection is connected into the call (i.e., D1C1 final state = connected)).
Normal or Network Dialling
D2C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #2)
D2C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #2)
- 282 -
17.1.12.3.3Call-Type Monitoring Event Sequences Table 17-69 Dial Digits—Call-Type Monitoring Event Sequences Monitored Call C1
Connection
Event
Cause Code
D1C1
Digits Dialled (see item #1)
Normal or Network Dialling
D1C1
Originated (when the dialling sequence is complete and the D1C1 connection is connected into the call (i.e., D1C1 final state = connected))
Normal or Network Dialling
D2C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #2)
1. This event will be provided for each diallable digits segment received by the switching function. 2. Providing of these events by the switching function does not affect the service completion conditions (i.e., a service is considered complete without these events being provided). 17.1.12.3.4Functional Requirements
1. The Dial Digits service only effects the diallingConnection call. If other calls exist at the diallingConnection Connection ID’s device, they remain unaffected. 2. This service can not be used to generate DTMF tones on an existing connected call. The Generate Digits service is used for this. This service is only used to perform the dialling sequences for placing a call (i.e., outbound dialling). 3. If no digits have been dialled for the diallingConnection through the original Make Call service or a previous Dial Digits service, the diallingSequence parameter can be any format of device identifier. Otherwise the diallingSequence parameter shall be in Diallable Digits format. 4. If the diallingSequence parameter is intended to provide just a portion of a longer dialling sequence to follow, then it shall be in Diallable Digits format with the last character of the sequence being “;”. Otherwise the diallingSequence parameter will be interpreted as the last in the dialling sequence for the diallingConnection. 5. The premature termination of a dialling sequence can be done by either using the Clear Connection service, Clear Call service, or having the dialling connection manually cleared. 6. The switching function may have a time-out period for multi-stage dialling. If the dialling sequence does not complete prior to this timeout, it may either abort the call or attempt to use the digits already dialled and signal that dialling is complete with an originated event. 7. If the switching function determines that dialling is complete even if a “;”was supplied, it will originate the call and ignore any subsequent digits.
- 283 -
C
17.1.13 Directed Pickup Call
S
The Directed Pickup Call service moves a specified call and connects it at a new specified destination. This results in the connection being diverted to a new destination inside the switching sub-domain. Figure 17-15 Directed Pickup Call Service BEFORE SERVICE
D1 (called)
a, c, h, q
C1
AFTER SERVICE
D2 (calling)
*
D3
D1
D3
(newDestination)
DEVICES D1 : called device D2 : calling device D3 : requestingDevice CALLS C1 : callToBePickedUp
C1
*
D2
c
AFFECTED CONNECTIONS D1C1 : callToBePickedUp connection D3C1 : newDestination connection CONNECTION STATES a : alerting state c : connected state h : hold state q : queued state * : (unspecified/unaffected)
Note that D1 could also be the calling device. 17.1.13.1 Service Request Table 17-70 Directed Pickup Call—Service Request Parameter Name
Type
M/ O/C
Description
callToBePickedUp
ConnectionID
M
Specifies the connection to be picked up.
requestingDevice
DeviceID
M
Specifies the device which is picking up the call.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.13.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 284 -
17.1.13.2.1Positive Acknowledgement Table 17-71 Directed Pickup Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
pickedCall
ConnectionID
O
Specifies the connectionID for the device which is picking up the call.
pickedCallInfo
ConnectionInformation
O
Specifies the connection information associated with the pickedCall connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.13.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.13.3 Operational Model 17.1.13.3.1Connection State Transitions Table 17-72 Directed Pickup Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (callToBePickedUp)
Alerting, Connect, Hold, or Queued
Null
D2C1 (calling device)
(Unspecified)
(Unaffected; no transition due to this service.)
D3C1 (requestingDevice)
Null
Connected
17.1.13.3.2Device-Type Monitoring Event Sequences Table 17-73 Directed Pickup Call—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
Event Cause
D1 (called device)
D1C1 (callToBepickedUp)
Diverted (see item #2)
Call Pickup
D2 (calling device)
D1C1
Diverted (optional) (see items #1 and #2)
Call Pickup
D3C1 (see item #5)
Service Initiated (optional) (see item #5)
Call Pickup (prompting)
D3C1
Established
Call Pickup
D3C1
Service Initiated (optional) (see item #5)
Call Pickup (prompting)
D3C1
Established
Call Pickup
D3 (requestingDevice)
- 285 -
17.1.13.3.3Call-Type Monitoring Event Sequences Table 17-74 Directed Pickup Call—Call-Type Monitoring Event Sequences Monitored Call C1
Connection
Event
Event Cause
D1C1
Diverted (optional) (see Items #2 and #4)
Call Pickup
D3C1 (item #5)
Service Initiated (optional) (item #5)
Call Pickup (prompting)
D3C1
Established
Call Pickup
1. The switching function provides the Diverted event for D2 only if it is providing Diverted events for all devices in the call. This is indicated through the capabilities exchange services. 2. A Connection Cleared event will not be provided. The Diverted event implies the ConnectionID (for D1C1) has gone to Null. 3. If there is already a connection in the initiated state at the requestingDevice device, the computing function may receive a Connection Cleared event for that connection and an Established event for the connection involving the picked call. 4. The switching function provides the Diverted event for C1 only if it is providing Diverted events for call-type monitors. This is indicated through the capabilities exchange services. 5. The Service Initiated event is dependent upon the prompting mode (as described in 6.7.10, “Prompting”, on page 84). •
For the “prompting is a pre-condition of the service” mode, the Service Initiated is generated before any service specific events and is not part of the service completion criteria. The connectionID associated with the Service Initiated event is not associated with the Directed Pickup service.
•
For the “prompting is part of the service” mode, the Service Initiated event is part of the service completion criteria, and is generated after the Diverted event and contains the same connectionID as the Diverted and Established events.
6. If a Bridged event is generated for an Independent Shared Bridged device configuration (see Functional Requirement #4), it is not part of the service completion criteria. 17.1.13.3.4Functional Requirements
1. This service differs from the Deflect Call service in that the Deflect Call service redirects a call to another destination (in which the resulting state of the new destination depends on the destination’s type and active features). The Directed Pickup Call service redirects a call to another destination which is immediately connected to the call. 2. For the newDestination, all features such as Forwarding and Do Not Disturb for this device will be ignored while the call is being redirected to it. 3. As a result of the Directed Pickup service, the call ID associated with this call remains unchanged. 4. For Shared Bridged device configurations, when a call is picked from an appearance (callToBePickedUp) all appearances will be cleared from the call (i.e., Connection Cleared events with a cause of Normal), except when the call that is being picked is part of an Independent Shared Bridged device configuration and the appearance from which the call is being picked is not the last appearance connected into the call. In this case the appearance from which the call is being picked will return to the inactive mode (i.e., Bridged event with a cause of Normal) and the other appearances are unaffected. For more information, refer to Annex A.2.3, “Shared-Bridged”. 5. This service request does not support the use of a null device identifier or a Diallable Digits format (DD) device identifier that has a partial dialling sequence character (i.e., the “;” character) in it for the - 286 -
newDestination parameter. A complete and valid device identifier shall be provided, otherwise the switching function will reject the service request with a negative acknowledgement. 6. This service is used when the device associated with the callToBePickedUp connection ID is different from the newDestination device. If the devices are the same, then the service is rejected. The Answer Call and the Retrieve Call services should be used instead.
- 287 -
C
17.1.14 Group Pickup Call
S
The Group Pickup Call service moves a call that is a member of a specified or default pickup group to a new specified destination. This results in a connection in a pickup group to be connected to a new specified destination inside the switching sub-domain. Note that the difference between this service and the Directed Pickup Call service is that Directed Pickup Call service specifies the actual connection to be picked up whereby the Group Pickup Call service does not. Figure 17-16 Group Pickup Call Service
BEFORE SERVICE
D1 (called)
a, c, h, q
C1
AFTER SERVICE
D2 (calling)
*
D3
D1
D3
(newDestination)
DEVICES D1 : called device D2 : calling device D3 : newDestination device CALLS C1 : call to be picked up
C1
*
D2
c
AFFECTED CONNECTIONS D1C1 : call to be picked up connection D3C1 : pickedCall connection CONNECTION STATES a : alerting state h : hold state q : queued state c : connected state * : (unspecified/unaffected)
Note that D1 may also be the calling device. 17.1.14.1 Service Request Table 17-75 Group Pickup Call—Service Request Parameter Name
Type
M/ O/C
Description
newDestination
DeviceID
M
Specifies the device which is picking up the call.
pickGroup
DeviceID
O
Specifies the pick group. If this parameter is not provided, the switching function may use a pick group associated with the newDestination device.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.14.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 288 -
17.1.14.2.1Positive Acknowledgement Table 17-76 Group Pickup Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
pickedCall
ConnectionID
O
Specifies the connection ID of call C1 at device D3.
pickedCallInfo
ConnectionInformation
O
Specifies the connection information associated with the pickedCall connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.14.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.14.3 Operational Model 17.1.14.3.1Connection State Transitions Table 17-77 Group Pickup Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (call to be picked up)
Alerting, Connected, Hold, or Queued
Null
D2C1 (calling device)
(Unspecified)
(Unaffected; no transition due to this service.)
D3C1 (pickedCall)
Null
Connected
17.1.14.3.2Device-Type Monitoring Event Sequences Table 17-78 Group Pickup Call—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
Event Cause
D1 (called device)
D1C1 (callToBepickedUp)
Diverted (see item #1)
Call Pickup
D2 (calling device)
D1C1
Diverted (optional) (see item #1 and #2)
Call Pickup
D3C1 (see item 2)
Service Initiated (optional) (see item #5)
Call Pickup (prompting)
D3C1
Established
Call Pickup
D3C1
Service Initiated (optional)
Call Pickup (prompting)
D3C1
Established
Call Pickup
D3 (newDestination device)
- 289 -
17.1.14.3.3Call-Type Monitoring Event Sequences Table 17-79 Group Pickup Call—Call-Type Monitoring Event Sequences Monitored Call C1
Connection
Event
Event Cause
D1C1
Diverted (optional) (see item #1 and #3)
Call Pickup
D3C1 (see item 2
Service Initiated (optional) (see item 5)
Call Pickup (prompting)
D3C1
Established
Call Pickup
1. A Connection Cleared event will not be provided. The Diverted event implies the ConnectionID (for D1C1) has gone to Null. 2. The switching function provides the Diverted event for D2 only if it is providing Diverted events for all devices in the call. This is indicated through the capabilities exchange services. 3. The switching function provides the Diverted event for C1 only if it is providing Diverted events for call-type monitors. This is indicated through the capabilities exchange services. 4. If there is already a connection in the initiated state at the newDestination device, the computing function may receive a Connection Cleared event for that connection and an Established event for the connection involving the picked call. 5. The Service Initiated event is dependent upon the prompting mode (as described in 6.7.10, “Prompting”, on page 84). •
For the “prompting is a pre-condition of the service” mode, the Service Initiated is generated before any service specific events and is not part of the service completion criteria. The connectionID associated with the Service Initiated event is not associated with the Group Pickup service.
•
For the “prompting is part of the service” mode”, the Service Initiated event is part of the service completion criteria, and is generated after the Diverted event and contains the same connectionID as the Diverted and Established events.
6. If a Bridged event is generated for an Independent Shared Bridged device configuration (see Functional Requirement #6), it is not part of the service completion criteria. 17.1.14.3.4Functional Requirements
1. This service differs from the Deflect Call service in that the Deflect Call service redirects a call to another destination (in which the resulting state of the new destination depends on the destination’s type and active features). The Group Pickup Call service redirects a call to another destination which is immediately connected to the call. 2. The Group Pickup service is administered by the switching function. The switching function determines which call the newDestination connects to by first determining which group the newDestination belongs to (either as specified by the pickGroup parameter or by a switching function administered group associated with the newDestination device) and then connecting it to the appropriate call. 3. For the newDestination, all features such as Forwarding and Do Not Disturb for this device will be ignored while the call is being redirected to it. 4. As a result of the Group Pickup service, the call ID associated with this call remains unchanged. 5. This service request does not support the use of a null device identifier or a Diallable Digits format (DD) device identifier that has a partial dialling sequence character (i.e., the “;” character) in it for the newDestination or pickGroup parameters. A complete and valid device identifier shall be provided, otherwise the switching function will reject the service request with a negative acknowledgement. - 290 -
6. For Shared Bridged device configurations, when a call is picked from an appearance all appearances will be cleared from the call (i.e., Connection Cleared events with a cause of Normal), except when the call that is being picked is part of an Independent Shared Bridged device configuration and the appearance from which the call is being picked is not the last appearance connected into the call. In this case the appearance from which the call is being picked will return to the inactive mode (i.e., Bridged event with a cause of Normal) and the other appearances are unaffected. For more information, refer to Annex A.2.3, “Shared-Bridged”.
- 291 -
C
17.1.15 Hold Call
S
The Hold Call service places a connected connection on hold at the same device. This service interrupts communication for an existing call at a device. Figure 17-17 Hold Call Service BEFORE SERVICE
D1 (holding)
c
C1
*
AFTER SERVICE
D2 (device to be held)
DEVICES D1 : holding device D2 : device to be held CALLS C1 : existing call
D1
h
C1
*
D2
AFFECTED CONNECTIONS D1C1 : callToBeHeld connection CONNECTION STATES c : connected state h : hold state * : (unspecified/unaffected)
17.1.15.1 Service Request Table 17-80 Hold Call—Service Request Parameter Name
Type
M/ O/C
Description
callToBeHeld
ConnectionID
M
Specifies the active connection to be held.
connectionReservation
Boolean
O
Specifies that the media stream channel(s) associated with the call being placed on hold be reserved for reuse at a later time. The complete set of possible values is: • True - channel(s) is to be reserved. • False - channel(s) is not to be reserved (default).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information.
17.1.15.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.15.2.1Positive Acknowledgement Table 17-81 Hold Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information.
17.1.15.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121.
- 292 -
17.1.15.3 Operational Model 17.1.15.3.1Connection State Transitions Table 17-82 Hold Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (callToBeHeld)
Connected
Hold
other connections in the call (i.e., D2C1)
(Unspecified)
(Unaffected; no transition due to this service).
17.1.15.3.2Device-Type Monitoring Event Sequences Table 17-83 Hold Call—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
Event Cause
D1 (Holding device)
D1C1 (callToBeHeld)
Held
Normal
D2 (device to be held and any other connections in call C1)
D1C1 (callToBeHeld)
Held
Normal
17.1.15.3.3Call-Type Monitoring Event Sequences Table 17-84 Hold Call—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1(callToBe-Held)
Event Held
Event Cause Normal
1. If a Bridged event is generated for an Independent Shared Bridged device configuration (see Functional Requirement #2), it is not part of the service completion criteria. 17.1.15.3.4Functional Requirements
1. The switching function may have a time-out period for the call once it is held. If the call is not retrieved before the time-out period ends, then the held call may ringback either the holding device or a device predefined by the switching function (such as an attendant console, for example). 2. For Shared Bridged device configurations, when a call is held by an appearance (callToBeHeld) all appearances will transition to the hold state (i.e., Held events with a cause of Normal), except when the call that is being held is part of an Independent Shared Bridged device configuration and the appearance that is holding the call is not the last appearance connected into the call. In this case only the appearance holding the call will transition to the hold state and the other appearances are unaffected. For more information, refer to Annex A.2.3, “Shared-Bridged”. 3. As a result of placing a connection associated with a digital data call (if supported by the switching function) on hold, the other calls at the device or device configuration are unrelated with this call.
- 293 -
C
17.1.16 Intrude Call
S
The Intrude Call service adds the calling device to a call at a busy called device. Depending upon the switching function, the result will be that the calling device is either actively or silently participating in the called device’s existing call or consulting with the called device with a new call. There are two cases specified for the Intrude Call service: •
Case A: In this case, the calling device (D1) joins call C2 with devices D2 and D3.
•
Case B: In this case, the called device (D2) places its existing active call on hold first and then connects to the new calling device (D1). Figure 17-18 Intrude Call Service (Case A) BEFORE SERVICE
AFTER SERVICE D3
D3
# C2
# D1
c
# D1 (calling)
c
C1
#
D2 (called)
f
C3
D2
f DEVICES D1 : calling device D2 : called device D3 : device in call C2 with device D2 CALLS C1 : call that is attempting to connect to D2 C2 : existing call involving D2 & D3 C3 : resulting call involving D1, D2 & D3
- 294 -
AFFECTED CONNECTIONS D1C1 : intrude connection D2C1 : called connection D2C2 : connection D3C2 : connection complete connectionID is not provided CONNECTION STATES c : connected state f : fail state # : (unspecified/inherited)
Figure 17-19 Intrude Call Service (Case B) BEFORE SERVICE
f
C1
D3 *
c
D3 *
D1 (calling)
AFTER SERVICE
C2
C2
c
h
D2 (called)
c
D1
C1
c
D2
f
DEVICES D1 : calling device D2 : called device D3 : device in call C2 with device D2 CALLS C1 : call that is attempting to connect to D2 C2 : existing call involving D2 and D3
AFFECTED CONNECTIONS D1C1 : intrude connection D2C1 : called connection complete connectionID is not provided CONNECTION STATES c : connected state f : fail state h : hold state : (unspecified/unaffected)
*
Refer to section 6.7.2, “Connection Failure”, on page 71 for a complete description of “Call ID only” connection IDs. 17.1.16.1 Service Request Table 17-85 Intrude Call—Service Request Parameter Name
Type
M/ O/C
Description
intrude
ConnectionID
M
Specifies the connection of the calling device.
participationType
Enumerated
O
Specifies the type of participation the added device has in the resulting call. The complete set of possible values is: • active (default) - The added device actively participates in the resulting conference call. • silent - The added device can listen but cannot actively participate in the resulting conference call. • none - The added device cannot actively participate in the resulting conference call. As a result, the flow direction of the added devices’s connection will be None. If the switching function only supports “Case B” of the service and the participationType parameter is supplied, then the service will be rejected by the switching function.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.16.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 295 -
17.1.16.2.1Positive Acknowledgement Table 17-86 Intrude Call—Positive Acknowledgement Parameter Name conferencedCall
Type
M/ O/C
Description
ConnectionID
C
ConnectionID includes the CallID of the resulting call and the DeviceID of the calling device. Mandatory, if the Intrude Call service creates a new ConnectionID for the calling device as in Case A; otherwise, the parameter is not provided.
conferencedCallInfo
ConnectionInformation
O
Specifies the connection information associated with the conferencedCall connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageDataList
List
O
Specifies the global call data and thread data associated with the call. The parameter consists of the following components: • newCallLinkageData (M) CallLinkageData - specifies the call linkage data associated with the resulting call. • oldCallLinkageData (M) CallLinkageData - specifies the call linkage data that was discarded as the result of the intrusion. Only if the Intrude Call service creates a new ConnectionID for the calling device as in Case A; otherwise, the parameter is not provided.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information.
17.1.16.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.16.3 Operational Model
- 296 -
17.1.16.3.1Connection State Transitions Table 17-87 Intrude Call—Connection State Transitions Connection
Initial State (Required)
Final State Case A
Case B
D2C1 (called device)
Fail
Null
Connected
D1C1 (intrude)
Connected
Null
Connected
D1C3
Null
Connected
N/A
D2C2
Case A: (Unspecified)
Null
Hold
Case B: Connected D3C2
(Unspecified)
Null
(Unaffected)
D2C3 and all connections in call C3 that had corresponding connections in call C2.
Null
(Inherited from corresponding connections in call C2)
N/A
17.1.16.3.2Device-Type Monitoring Event Sequences
•
Case A: D1, the calling device, joins call C3 with devices D2 and D3. Table 17-88 Intrude Call—Device-Type Monitoring Event Sequences (Case A) Monitored Device
•
Connection
Event
Event Cause
D1 (calling device)
D1C3
Conferenced
Override, Silent Participation, or Active Participation
D2 (called device)
D2C3
Conferenced
Override, Silent Participation, or Active Participation
other devices in original call C2 (i.e., D3)
D3C3
Conferenced
Override, Silent Participation, or Active Participation
Case B: The called device places its existing active call on hold first and then connects to the new calling device (D1). Table 17-89 Intrude Call—Device-Type Monitoring Event Sequences (Case B) Monitored Device
Connection
Event
Event Cause
D1 (calling device)
D2C1 (called)
Established
Intrude
D2 (called device)
D2C2
Held
Normal or Intrude
D2C1 (called)
Established
Intrude
D2C2
Held
Normal or Intrude
Other devices in original call C2 (i.e., D3)
17.1.16.3.3Call-Type Monitoring Event Sequences
•
Case A: D1, the calling device, joins call C3 with devices D2 and D3. Table 17-90 Intrude Call—Call-Type Monitoring Event Sequences (Case A) Monitored Call C1 (call attempting to connect to device D2)
Connection D1C3
Event Conferenced
- 297 -
Event Cause Override, Silent Participation, or Active Participation
Table 17-90 Intrude Call—Call-Type Monitoring Event Sequences (Case A) (concluded) Monitored Call C2 (resulting conference call)
•
Connection D1C3
Event Conferenced
Event Cause Override, Silent Participation, or Active Participation
Case B: The called device places its existing active call on hold first and then connects to the new calling device (D1). Table 17-91 Intrude Call—Call-Type Monitoring Event Sequences (Case B) Monitored Call
Connection
Event
Event Cause
C2 (original call)
D2C2
Held
Intrude or Normal
C1 (call attempting to connect to device D2)
D2C1 (called)
Established
Intrude
1. The event cause is based on the value of the participationType parameter: •
If the parameter was set to active, then the event cause will be Active Participation.
•
If the parameter was set to silent or none, then the event cause will be Silent Participation.
•
If the switching function cannot determine the type used, then the event cause will be Override.
17.1.16.3.4Functional Requirements
1. To cancel an Intrude Call service, the computing function can either: •
Issue the Clear Connection or Clear Call service with the ConnectionID of either the calling (cases A or B) or called (case B) device.
•
Have the calling device go on-hook.
If the above is successfully executed, normal call progress messages of Connection Cleared (with an event cause of Normal Clearing) will be generated. 2. The computing function should never assume the reuse of callIDs, although some switching functions may reuse one or the other. 3. If the called device has more than one call during the execution of this service, the switching function will choose which call to intrude upon.
- 298 -
C
17.1.17 Join Call
S
The Join Call service allows a computing function to request, on behalf of a device, that the device be joined into an existing call. In the process of establishing a connection with the joiningDevice, the joiningDevice may be prompted to go off-hook (if necessary) and when that device does so, it is added into the call. This service is different from the Single Step Conference service in that the request is made on behalf of the joiningDevice (originating device). This service is different from the Intrude Call service in that there is no prior failed call at the intrudedupon connection. Figure 17-20 Join Call Service BEFORE SERVICE
D1
*
AFTER SERVICE
*
C1
D2
D1
*
D3 (joiningDevice)
DEVICES D1 : device in call C1 with device D2 D2 : device in call C1 with device D1 D3 : joiningDevice CALLS C1 : existing call
*
C1
c
D2
D3
AFFECTED CONNECTIONS D1C1 : active call connection for device D1 D2C1 : active call connection for device D2 D3C1 : conferencedCall connection CONNECTION STATES c : connected state * : (unspecified/unaffected)
17.1.17.1 Service Request Table 17-92 Join Call—Service Request Parameter Name
Type
M/ O/C
Description
activeCall
connectionID
M
Specifies an existing connection in an active call to which the new device is to be added (or joined)
joiningDevice
DeviceID
M
Specifies the device that is to be added to (join) the existing call
autoOriginate
Enumerated
O
Specifies if the joining device is to be prompted or not (hands-free mode). The complete set of possible values is: • Prompt (default) • Do Not Prompt (auto originate)
- 299 -
Table 17-92 Join Call—Service Request (concluded) Parameter Name participationType
Type Enumerated
M/ O/C
Description
O
Specifies the type of participation the joining device has in the resulting call. This is one of the following: • active (default) - the joining device actively participates in the resulting conference call. As a result, the flow direction of the joiningDevice’s connection (i.e., conferencedCall) will be Transmit and Receive. • silent - the joining device can listen but cannot actively participate in the resulting conference call. As a result, the flow direction of the joiningDevice’s connection (i.e., conferencedCall) will be Receive. • none - the joining device cannot actively participate in the resulting conference call. As a result, the flow direction of the joiningDevice’s connection (i.e., conferencedCall) will be None.
accountCode
AccountInfo
O
Specifies the account code to associate with the call.
authCode
AuthCode
O
Specifies the authorization code to allow the call.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.17.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.17.2.1Positive Acknowledgement Table 17-93 Join Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
conferencedCall
ConnectionID
M
Specifies the callID of the existing active call and the DeviceID of the joining device.
conferencedCallInfo
ConnectionInformation
O
Specifies the connection information associated with the conferencedCall connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageDataList
List
O
Specifies the global call data and thread data associated with the call. The parameter consists of the following components: • newCallLinkageData (M) CallLinkageData - specifies the call linkage data associated with the resulting call. • oldCallLinkageData (M) CallLinkageData - specifies the call linkage data that was discarded as the result of the joining.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.17.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121.
- 300 -
17.1.17.3 Operational Model 17.1.17.3.1Connection State Transitions Table 17-94 Join Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1
(Unspecified)
(Unaffected; no transition due to this service)
D2C1
(Unspecified)
(Unaffected; no transition due to this service)
D3C1 (conferencedCall)
Null
Connected
- 301 -
17.1.17.3.2Device-Type Monitoring Event Sequences Table 17-95 Join Call—Device-Type Monitoring Event Sequences Monitored Device D1
D2
D3 (joiningDevice)
Connection
Event
Event Cause
D3C1 (conferencedCall)
Conferenced
Join Call, ActiveParticipation, Silent Participation
D3C1 (conferencedCall) (see item 2)
Service Initiated (optional) (see item 2)
Join Call (prompting)
D3C1 (conferenced Call)
Established
Join Call, ActiveParticipation, Silent Participation
D3C1 (conferencedCall)
Conferenced
Join Call, ActiveParticipation, Silent Participation
D3C1 (conferencedCall) (see item 2)
Service Initiated (optional) (see item 2)
Join Call (prompting)
D3C1 (conferencedCall)
Established
Join Call, ActiveParticipation, Silent Participation
D3C1 (conferencedCall)
Conferenced
Join Call, ActiveParticipation, Silent Participation
D3C1 (conferencedCall) (see item 2)
Service Initiated (optional) (see item 2)
Join Call (prompting)
D3C1 (conferencedCall)
Established
Join Call, ActiveParticipation, Silent Participation
17.1.17.3.3Call-Type Monitoring Event Sequences Table 17-96 Join Call—Call-Type Monitoring Event Sequences Monitored Device C1
Connection
Event
Event Cause
D3C1
Conferenced
Join Call, ActiveParticipation, Silent Participation
D3C1 (see item 2)
Service Initiated (optional) (see item 2)
Join Call (prompting)
D3C1
Established
Normal
1. For the Conferenced event, the event cause is based upon the value of the participationType parameter: •
If it was set to active, then the event cause is Active Participation.
•
If it was set to silent or none, then the event cause is Silent Participation.
•
If the switching function cannot determine the type used, then the event cause is Join Call.
2. The Service Initiated event is dependent upon the prompting mode (as described in 6.7.10, “Prompting”, on page 84). •
For the “prompting is a pre-condition of the service” mode, the Service Initiated is generated before any service specific events and is not part of the service completion criteria. The connectionID associated with the Service Initiated event is not associated with the Join Call service. - 302 -
•
For the “prompting is part of the service” mode, the Service Initiated event is part of the service completion criteria, and is generated after the Conferenced event and contains the same connectionID as the Conferenced and Established events.
17.1.17.3.4Functional Requirements
1. The appearances in a shared bridged device configuration are unaffected by this service. 2. This service request does not support the use of a null device identifier or a Diallable Digits format (DD) device identifier that has a partial dialling sequence character (i.e., the “;” character) in it for the joiningDevice parameter. A complete and valid device identifier shall be provided, otherwise the switching function will reject the service request with a negative acknowledgement. 3. Prompting of the joining device during the processing of the Join Call service is switching function specific (display flashing, ring pattern, lamp blinking, etc.). 4. If the autoOriginate parameter has a value of “Do Not Prompt”, then the device should be a speakerphone, hands-free telephone, or other device that can be automatically answered. If the device is not of this type, then the processing of this parameter is switching function specific. For example, the switching function may choose to accept this service and ignore this parameter, or it may reject the Join Call service with negative acknowledgement. 5. Call Forwarding and Do Not Disturb features for the joining device are not honoured. If a switching function supports prompting of the joining device and detects that a feature was activated while processing the Join Call service and this feature cannot be overridden, then the switching function will return a negative acknowledgement. 6. The call ID in the ConnectionIDs for the resulting conference call is inherited from the original active call. 7. When prompting a device which has a call appearance, bridged, or hybrid device configuration, only one of the appearances will be delivered the call. 8. If this service is used to join a device into a digital data call, the connection for the joiningDevice (i.e., conferencedCall) will inherit the characteristics of the call with the exception of connection flow direction and the number of channels used. In these cases, the connection flow direction is dependent on the value of participationType and the number of channels is based on what the switching function will use to allow the joiningDevice to effectively participate in the call.
- 303 -
C
17.1.18 Make Call
S
The Make Call service allows the computing function to set up a call between a calling device and a called device. The service creates a new call and establishes an initiated or connected connection with the calling device. The Make Call service assigns a ConnectionID to the calling device and returns it in the positive acknowledgement. In the process of establishing the connection with the calling device, the calling device may be prompted to go off-hook (if necessary) and when that device does so, a call to the called device is originated or the calling device is still in the process of dialling the called device. Figure 17-21 Make Call Service—Case A: Complete Dialling Sequence Provided BEFORE SERVICE
D1 (calling)
n, i
C1
AFTER SERVICE
D2 (called)
D1
c
C1
D2
a, c f, q, n f
DEVICES D1 : callingDevice D2 : called device CALLS C1 : initiated call
AFFECTED CONNECTIONS D1C1 : callingDevice connection D2C1 : called connection ------- complete connectionID is not provided CONNECTION STATES a : alerting state c : connected state i : initiated state f : failed state n : null state q : queued state
Note that (Case A) the Initiated state (D1C1) is used for Offhook Dialling (see Functional Requirement #6). Figure 17-22 Make Call Service—Case B: Partial Dialling Sequence Provided BEFORE SERVICE
D1 (calling)
n, i
C1
AFTER SERVICE
D2 (called)
DEVICES D1 : callingDevice D2 : called device CALLS C1 : initiated call
D1
i
C1
c, n
D2
AFFECTED CONNECTIONS D1C1 : callingDevice connection ------ “Call ID only” connectionID is provided. CONNECTION STATES i : initiated state c : connected state
Refer to 6.7.2, “Connection Failure”, on page 71 for a complete description of “Call ID only” connection IDs. Note that (Case B) the connected state (D2C1) exists when D2 is a NID.
- 304 -
17.1.18.1 Service Request Table 17-97 Make Call—Service Request Parameter Name callingDevice
Type DeviceID
M/ O/C M
Description Specifies the calling/originating device. Note that this device may be a device that represents a group of devices. In this case the callingDevice in the service request is different from the actual calling device.
calledDirectoryNumber
DeviceID
M
Specifies the called device.
accountCode
AccountInfo
O
Specifies the account code to associate with the new call.
authCode
AuthCode
O
Specifies the authorization code to allow the call.
autoOriginate
Enumerated
O
Specifies if the calling device’s connection is automatically answered (hands-free mode). The complete set of possible values is: • Prompt (default) • Do Not Prompt (auto originate)
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (Priority call, for example) to be associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values. If the supported characteristics cannot be honoured, the switching function shall reject the service request.
mediaCallCharacteristics
MediaCallCharacteristics
O
This specifies the media characteristics to be associated with the call being made. If this parameter is not present then the media class is Voice.
callingConnectionInfo
ConnectionInformation
O
This specifies the connection information needed for the creation of a connection at the callingDevice. If this parameter is not present then the connection information is switching function specific.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences to be associated with the call.
reason
EventCause
O
Specifies the reason the call is being made. See 12.2.15, “EventCause”, on page 132 for a list of possible values.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information.
17.1.18.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 305 -
17.1.18.2.1Positive Acknowledgement Table 17-98 Make Call—Positive Acknowledgement Parameter Name callingDevice
Type
M/ O/C
ConnectionID
M
Description Specifies the initial connection to the new call. The ConnectionID shall have the CallID of the resulting new call and the DeviceID of the calling device. Note that the calling device parameter in the service request may be different from the deviceID in the connectionID of callingDevice in the positive acknowledgement (when the callingDevice in the service request represents a group of stations, for example).
mediaCallCharacteristics
MediaCallCharacteristics
C
This specifies the adjusted media characteristics for the call being made. This parameter shall be provided if the call characteristics have been adjusted, otherwise it is optional.
initiatedCallInfo
ConnectionInformation
O
This specifies the adjusted connection information used during the creation of the initiatedCall for the callingDevice. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.18.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.18.3 Operational Model 17.1.18.3.1Connection State Transitions Table 17-99 Make Call—Connection State Transitions (Case A: Complete Dialling Sequence) Connection
Initial State (Required)
Final State
D1C1 (callingDevice)
Null, Initiated (see item #17.1.18.3.1)
Initiated, Connected
D2C1 (called)
Null
Alerting, Connected, Queued, Fail, or Null (Null if call moves away from the originally called device [i.e., forwarded]).
Table 17-100 Make Call—Connection State Transitions (Case B: Partial Dialling Sequence) Connection
Initial State (Required)
Final State
D1C1 (callingDevice)
Null, Initiated (see item #17.1.18.3.1)
Initiated
D2C1 (called)
Null
Connected (see item #1), Null
1. When providing a partial dialling sequence (Case B) the connected state for D2C1 only applies to external outbound calls. It indicates that enough of the dial string has been communicated for the switching function to connect the call to the Network Interface Device that will be associated with the called device in the external network. 2. The initial state of Initiated for D1C1 is used when D1 is “offhook” prior to the Make Call service request. The callID used for the Make Call shall be the same as the callID used for the initiated call.
- 306 -
17.1.18.3.2Device-Type Monitoring Event Sequences
There are two types of Device-Type Monitoring Event sequences depending on the dialling sequence used for the called device. •
Case A: The dialling sequence for the called device is complete. Table 17-101 Make Call—Device-Type Monitoring Event Sequences (Case A) Monitored Device D1 (calling device)
Connection D1C1
Event
Event Cause
Service Initiated (optional)
Make Call, if calling device is prompted by the switching function. New Call, if the Make Call is done manually.
D2 (called device)
•
D1C1
Originated
D2C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (i.e., Forward, Do Not Disturb, etc.).(see item #1)
Normal
D2C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (i.e., Forward, Do Not Disturb, etc.). (see item #1)
Case B: The dialling sequence for the called device is incomplete. Table 17-102 Make Call—Device-Type Monitoring Event Sequences (Case B) Monitored Device D1 (calling device)
Connection D1C1
Event
Event Cause
Service Initiated (optional)
Make Call, if calling device is prompted by the switching function. New Call, if the Make Call is done manually.
D2 (called device)
D1C1
Digits Dialled
D2C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (i.e., Forward, Do Not Disturb, etc.). (see item #1)
D2C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (i.e., Forward, Do Not Disturb, etc.). (see item #1)
- 307 -
Normal
17.1.18.3.3Call-Type Monitoring Event Sequences
•
Case A: The dialling sequence for the called device is complete. Table 17-103 Make Call—Call-Type Monitoring Event Sequences (Case A) Monitored Call C1
Connection D1C1
Event
Event Cause
Service Initiated (optional)
Make Call, if calling device is prompted by the switching function. New Call, if the Make Call is done manually.
•
D1C1
Originated
Normal
D2C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (i.e., Forward, Do Not Disturb, etc.). (see item #1)
Case B: The dialling sequence for the called device is an incomplete sequence. Table 17-104 Make Call—Call-Type Monitoring Event Sequences (Case B) Monitored Call C1
Connection D1C1
Event
Event Cause
Service Initiated (optional)
Make Call, if calling device is prompted by the switching function. New Call, if the Make Call is done manually.
D1C1
Digits Dialled
Normal
D2C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (i.e., Forward, Do Not Disturb, etc.).(see item #1)
1. Providing of these events by the switching function does not affect the service completion conditions (i.e., a service is considered complete without these events being provided). 17.1.18.3.4Functional Requirements
1. Prompting of the calling device during the processing of the Make Call service is switching function specific (display flashing, ring pattern, lamp blinking, etc.). 2. If the validation of the Make Call service fails for any reason, the computing function receives a negative acknowledgement, and no valid ConnectionIDs will have been created. 3. If the autoOriginate parameter is supported by the switching function and has a value of “Do Not Prompt”, and if the calling device is not capable of automatically answering the device, then the processing of this parameter is switching function dependent. 4. Call Forwarding and Do Not Disturb features for the calling device are not honoured for the call being made. If a switching function supports prompting of the calling device and detects that a feature was activated while processing the Make Call service and this feature cannot be overridden, then the switching function will return a negative acknowledgement. 5. All active features are honoured for the called device. 6. If a Make Call service is issued for a calling device that has a connection in the Initiated state (i.e., the computing function got a Service Initiated event for a phone manually going off-hook), and the switching function can support the issuing of the Make Call service under this condition, then the - 308 -
Connection ID in the positive acknowledgement of the Make Call service will contain the same Connection ID received on the Service Initiated event. If the switching function does not support the Make Call service under this condition, then the service will be rejected with a negative acknowledgement. (This note is an exception to requirement #2 in 9.5.1 on page 100.) 7. The calledDirectoryNumber parameter may contain a device identifier of null (a null formatted device identifier) or contain a Diallable Digits format (DD) device identifier that has a partial dialling sequence character (i.e., the “;” character) at the end of it. When this parameter is used in this manner, the computing function is indicating that it wishes to stage the dialling sequence. The completion of the dialling sequence can be accomplished either by entering the rest of the sequence manually at the actual device or the computing function can use the Dial Digits service to complete the sequence. The other types of calledDirectoryNumber parameter shall contain a complete dialling sequence. The switching function may have a timeout period for multi-stage dialling. If the dialling sequence does not complete prior to this timeout, it may either abort the call or attempt to use the digits already dialled and signal that dialling is complete with an originated event. 8. If the Make Call service is used to initiate a multistage dialling sequence, the computing function is signalled to continue the dialling sequence via either the Service Initiated event (i.e., if the calledDirectoryNumber is Null) or the Digits Dialled event (i.e., if the calledDirectoryNumber has a partial dialling sequence character). 9. When prompting a device which has a call appearance, bridged, or hybrid device configuration, only one of the appearances will be delivered the call. 10. The switching function may or may not adjust the digital data characteristics (e.g., connection rate) and connection information (e.g., number of channels) that were supplied on the Make Call service request (Use the capabilities exchange services to determine which feature the switching function supports). If the switching function supports adjusting the characteristics/connection information but cannot adjust them in this case, the service request will be rejected with an appropriate error code, if the original characteristics/connection information cannot be provided. If the switching function can adjust of the characteristics/connection information, the positive acknowledgement will contain the adjusted value or values. If the computing function determines that the adjusted values are not adequate, it can terminate the digital data call (e.g., Clear Call). 11. If the computing function makes a digital data call and wants to also bind a particular Media Service to the call, then the computing function shall use the Media Attach Service service. 12. The callingDevice parameter in the Make Call service request may represent a group of devices from which the actual calling device is selected. In this case, the callingDevice parameter in subsequent events shall refer to the actual calling device. In addition, the Originated event contains a parameter (originatingDevice) that represents the group of devices (the callingDevice parameter passed in service request).
- 309 -
C
17.1.19 Make Connection
S
The Make Connection service allows the computing function to create a connection at an initiating device. The created connection is in an initiated or a connected state. The service assigns a ConnectionID to this connection and returns it in the positive acknowledgement. In the process of establishing the connection with the initiating device, the initiating device may be prompted to go off-hook (if necessary) and when that device does so, a call to the connection transits to the connected state, otherwise the connection remains in the initiated state. The Make Connection service may be used to create a connection at a conferencing device to reserve resources so they are available when other devices are added at a later time (e.g. meet me conferencing). Figure 17-23 Make Connection Service BEFORE SERVICE
AFTER SERVICE
D1 (initiating)
i, c
D1
C1
DEVICES D1 : initiatingDevice
AFFECTED CONNECTIONS D1C1 : initiatingDevice connection
CALLS C1 : initiated call
CONNECTION STATES c : connected state i : initiated state
17.1.19.1 Service Request Table 17-105 Make Connection—Service Request Parameter Name initiatingDevice
Type
M/ O/C
DeviceID
M
Description Specifies the device initiating the call. Note that this device may be a device that represents a group of devices. In this case the initiatingDevice in the service request is different from the actual initiating device.
accountCode
AccountInfo
O
Specifies the account code to associate with the new call.
authCode
AuthCode
O
Specifies the authorization code to allow the call.
autoOriginate
Enumerated
O
Specifies if the initiating device’s connection is automatically answered. The complete set of possible values is: • Prompt (default) • Do Not Prompt (auto originate)
correlatorData
CorrelatorData
O
- 310 -
Specifies the correlator data to associate with the call.
Table 17-105 Make Connection—Service Request (continued) Parameter Name callCharacteristics
Type CallCharacteristics
M/ O/C
Description
O
Specifies the high level characteristics (Priority call, for example) to be associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values. If the supported characteristics cannot be honoured, the switching function shall reject the service request.
mediaCallCharacteristics
MediaCallCharacteristics
O
This specifies the media characteristics to be associated with the call being made. If this parameter is not present then the media class is Voice.
connectionInfo
ConnectionInformation
O
This specifies the connection information needed for the creation of a connection at the initiatingDevice. If this parameter is not present then the connection information is switching function specific.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences to be associated with the call.
reason
EventCause
O
Specifies the reason the call is being made. See 12.2.15, “EventCause”, on page 132 for a list of possible values.
maxDevices
Value
O
Specifies the maximum number of devices for the call. It is switching function dependent whether additional devices can be added to the call beyond the maxDevices limit. See Functional Requirement #5. If this parameter is not supported by the switching function, or if this parameter is supported but not present, or if a value of zero is specified then the maximum number of devices for the call determined by the switching function.
startTime
Timeinfo
O
Specifies the time when devices can be added to the call. It is switching function dependent whether devices can be added to the call prior to the specified startTime. See Functional Requirement #5. If this parameter is not supported by the switching function, or if this parameter is supported but not present then devices can be added to the call at any time.
duration
Value
O
Specifies the length of time (in seconds) that the connection shall exist before being cleared by the switching function. It is switching function dependent whether to exceed this specified duration for the connection (e.g. the switching function may choose to maintain the connection that exceeds the specified duration when there are multiple devices in the call). See Functional Requirement #5. If this parameter is not supported by the switching function, or if this parameter is supported but not present, or if a value of zero is specified then the duration is determined by the switching function.
security
CSTASecurityData
- 311 -
O
Specifies timestamp information, message sequence number, and security information.
Table 17-105 Make Connection—Service Request (concluded) Parameter Name privateData
Type
M/ O/C
CSTAPrivateData
O
Description Non-standardized information.
17.1.19.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.19.2.1Positive Acknowledgement Table 17-106 Make Connection—Positive Acknowledgement Parameter Name initiatingDevice
Type
M/ O/C
ConnectionID
M
Description Specifies the initial connection to the new call. The ConnectionID shall have the CallID of the resulting new call and the DeviceID of the initiating device. Note that the initiatingDevice parameter in the service request may be different from the deviceID in the connectionID of initiatingDevice in the positive acknowledgement (when the initiatingDevice in the service request represents a group of devices, for example).
mediaCallCharacteristics
MediaCallCharacteristics
C
This specifies the adjusted media characteristics for the call being made. This parameter shall be provided if the call characteristics have been adjusted, otherwise it is optional.
initiatedCallInfo
ConnectionInformation
O
This specifies the adjusted connection information used during the creation of the initiatedCall for the initiatingDevice. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.19.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.19.3 Operational Model
- 312 -
17.1.19.3.1Connection State Transitions Table 17-107 Make Connection—Connection State Transitions Connection
Initial State (Required)
D1C1 (initiatingDevice)
Final State
Null
Initiated, Connected
17.1.19.3.2Device-Type Monitoring Event Sequences Table 17-108 Make Connection—Device-Type Monitoring Event Sequences Monitored Device D1 (initiatingDevice)
Connection D1C1
Event
Event Cause
Service Initiated (optional)
Make Connection, if initiating device is prompted by the switching function. Otherwise the Make Connection’s reason parameter is reflected. New Call, if the reason parameter was not provided.
D1C1
Originated
Reflects the reason parameter of the Make Connection service request. New Call if the reason parameter was not provided.
17.1.19.3.3Call-Type Monitoring Event Sequences Table 17-109 Make Connection—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1
Event
Event Cause
Service Initiated (optional)
Make Connection, if initiating device is prompted by the switching function. Otherwise the Make Connection’s reason parameter is reflected. New Call, if the reason parameter was not provided.
D1C1
Originated
Reflects the reason parameter of the Make Connection service request. New Call if the reason parameter was not provided.
17.1.19.3.4Functional Requirements
1. Prompting of the initiating device during the processing of the Make Connection service is switching function specific. 2. If the validation of the Make Connection service fails for any reason, the computing function receives a negative acknowledgement, and no valid ConnectionIDs will have been created. 3. If the switching function is unable to support any of the values specified in the maxDevices, startTime, and duration parameters than it shall provide a negative response.
- 313 -
4. If the autoOriginate parameter is supported by the switching function and has a value of “Do Not Prompt”, and if the initiating device is not capable of automatically answering the device, then the processing of this parameter is switching function dependent. 5. The maxDevices, startTime, and duration parameters may be used by the switching function to allocate future resources associated with the connection being created. There may be situations where the switching function might not be able to add another device to the call before the specified maxDevices is exceeded or situations when the switching function must clear the connection before the duration is reached. 6. Call Forwarding and Do Not Disturb features for the initiating device are not honoured for the call being made. If a switching function supports prompting of the initiating device and detects that a feature was activated while processing the Make Connection service and this feature cannot be overridden, then the switching function will return a negative acknowledgement. 7. When prompting a device which has a call appearance, bridged, or hybrid device configuration, only one of the appearances will be delivered the call. 8. The switching function may or may not adjust the digital data characteristics (e.g., connection rate) and connection information (e.g., number of channels) that were supplied on the Make Connection service request (Use the capabilities exchange services to determine which feature the switching function supports). If the switching function supports adjusting the characteristics/connection information but cannot adjust them in this case, the service request will be rejected with an appropriate error code, if the original characteristics/connection information cannot be provided. If the switching function can adjust of the characteristics/connection information, the positive acknowledgement will contain the adjusted value or values. If the computing function determines that the adjusted values are not adequate, it can terminate the digital data call (e.g., Clear Call). 9. If the computing function makes a digital data call and wants to also bind a particular Media Service to the call, then the computing function shall use the Media Attach Service service. 10. The initiatingDevice parameter in the Make Connection service request may represent a group of devices from which the actual initiating device is selected. In this case, the callingDevice parameter in subsequent events shall refer to the actual initiating device (not the initiatingDevice passed in the service request). In addition, the Originated event contains a parameter (originatingDevice) that represents the group of devices (the initiatingDevice parameter passed in service request).
- 314 -
C
17.1.20 Make Predictive Call
S
The Make Predictive Call service shall originate a call between two devices by first creating a connection to the called device. The service returns a positive acknowledgement that provides the connection at the called device. Subsequent actions are taken depending upon the call progress and the actions requested. Examples are: •
An attempt is made to connect at the calling device because a connected state was determined at the called device.
•
The call was cleared because a connected state was determined at the called device and the switching function detected a FAX and was instructed by the computing function to clear the call in this case. Figure 17-24 Make Predictive Call Service BEFORE SERVICE
D1 (calling)
AFTER SERVICE
D2 (called)
DEVICES D1 : callingDevice D2 : called device CALLS C1 : initiatedCall
D1
i, n
C1
a, c, f, n, q
AFFECTED CONNECTIONS D2C1 : initiated connection CONNECTION STATES a : alerting state c : connected state f : failed state i : initiated state n : null state q : queued state
17.1.20.1 Service Request Table 17-110 Make Predictive Call—Service Request Parameter Name
Type
M/ O/C
Description
callingDevice
DeviceID
M
Specifies the device on behalf of which the call is originated.
calledDirectoryNumber
DeviceID
M
Specifies the called device.
- 315 -
D2
Table 17-110 Make Predictive Call—Service Request (continued) Parameter Name signallingDetection
Type Structure
M/ O/C
Description
O
Specifies the switching function actions to be taken when the specified call progress conditions at the called device or network are met. It includes the following components: • signallingCondition (M) Enumerated - Specifies the conditions that must be satisfied before the switching function processes the signallingConditionsAction. The complete set of possible values is: •
callDelivered - Process the specified actions when the call is delivered to or answered at the called device (whichever occurs first).
•
callEstablished - Process the specified actions when the call has been answered at the called device.
• signallingConditionsAction (M) Enumerated - Action to be taken by the switching function upon detecting a signallingCondition. The complete set of possible values is:
destinationDetection
List of Structures
O
•
destinationDetection - The conditions/actions specified in the destinationDetection parameter should be followed.
•
remainConnected - The called device is to remain in the call and the connection to the calling device is attempted.
Specifies the switching function actions to be taken when the specified signallingCondition at the called device is met. Each entry in the list contains the following: • destinationCondition (M) Enumerated - Specifies the condition that must be satisfied before the switching function processes the detectionAction. The complete set of possible values is: •
humanVoice - Process the specified actions when a human voice is detected at the called device.
•
answeringMachine - Process the specified actions when an answering machine is detected at the called device.
•
facsimileMachine - Process the specified actions when a (FAX) machine or modem is detected at the called device.
• detectionAction (M) Enumerated - Action to be taken by the switching function upon detecting of a particular destination condition. The complete set of possible values is: •
clearCalledConnection - The connection for the called device is to be cleared.
•
remainConnected - The called device is to remain in the call and the connection to the calling device is attempted.
Note that if multiple entries are provided, the switching function shall process the detectionAction associated with the first destinationCondition that is detected.
- 316 -
Table 17-110 Make Predictive Call—Service Request (concluded) Parameter Name defaultAction
Type Enumerated
M/ O/C O
Description Specifies the actions to be taken when the switching function determines that the condition specified in the signallingCondition component cannot be met. The complete list of possible values is: • clearCalledConnection - The connection for the called device is to be cleared. • remainConnected - The called device is to remain in the call and the connection to the calling device is attempted.
accountCode
AccountInfo
O
Specifies the account code to associate with the new call.
authCode
AuthCode
O
Specifies the authorization code to allow the call.
autoOriginate
Enumerated
O
Specifies if the calling device’s connection is automatically answered (hands-free mode). The complete set of possible values is: • prompt (default) • doNotPrompt (auto originate)
alertTime
Value
O
Specifies the amount of time, in seconds, the called device is to be alerted before the call is cleared.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (Priority call, for example) to be associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values. If the supported characteristics cannot be honoured, the switching function shall reject the service request.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences to be associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information.
17.1.20.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.20.2.1Positive Acknowledgement Table 17-111 Make Predictive Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
initiatedCall
ConnectionID
M
Specifies the initial connection between the called device and the call. The ConnectionID shall have the CallID of the resulting new call and the DeviceID representing the called device.
initiatedCallInfo
ConnectionInformation
O
Specifies the connection information associated with the initiatedCall connection. If this parameter is not present, then the connection information is switching function specific.
- 317 -
Table 17-111 Make Predictive Call—Positive Acknowledgement (concluded) Parameter Name
Type
M/ O/C
Description
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information.
17.1.20.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.20.3 Operational Model 17.1.20.3.1Connection State Transitions Table 17-112 Make Predictive Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1
Null
Initiated, Null
D2C1 (initiated)
Null
Alerting, Connected, Failed, Queued, or Null
17.1.20.3.2Device-Type Monitoring Event Sequences Table 17-113 Make Predictive Call—Device-Type Monitoring Event Sequences Monitored Device D2 (called device) or the device representing D2 when D2 is outside the switching sub-domain.
D1 (calling device)
Connection D2C1
Event
Event Cause
The sequence of events for the called device will depend on the type of called device and if it is in the switching subdomain. See item #1 for the service completion criteria.
D1C1
Delivered (see item #2).
Normal, Entering Distribution
D1C1
Service Initiated (Optional) see Functional Requirement #10 and Item #3).
Make Predictive Call, Reserved
D2C1
The sequence of events for the called device will depend on the type of called device and if it is in the switching subdomain. See item #1 for the service completion criteria.
D1C1
Delivered (see item #2).
- 318 -
Normal, Entering Distribution
17.1.20.3.3Call-Type Monitoring Event Sequences Table 17-114 Make Predictive Call—Call-Type Monitoring Event Sequences Monitored Call C1
Connection
Event
Event Cause
D1C1
Service Initiated (Optional see functional requirements #10 and Item #3).
Make Predictive Call, Reserved
D2C1
The sequence of events for the called device will depend on the type of called device and if it is in the switching subdomain See item #1 for the service completion criteria.
D1C1
Delivered (See item #2).
Normal, Entering Distribution
1. The completion criteria for this service depends upon the signallingCondition component specified in the service request: a. the Delivered or Established event (whichever flows first) for D2 if the signallingCondition is Delivered b. the Established event for D2 if the signallingCondition is Established In the case where the switching function detects that the conditions specified in the signallingCondition component cannot be met (for example when the call fails or queues at the called device), the service is completed when the switching function generates the event corresponding to the condition at the called device that prevented the signallingCondition from being met (Failed, Queued events, for example) or Connection Cleared if the switching function cleared the called connection (see Functional Requirement #4). 2. If the signallingConditionAction parameter specifies remainConnected, then depending on the type of calling device and its state, the Delivered, Queued, Failed, and Established events can flow for D1. These events are not part of the service completion criteria. 3. In the case where the switching function reserves the calling device for allocating the predictive call to it, Functional Requirement #10 applies but the cause code of reserved shall be used. 17.1.20.3.4Functional Requirements
1. The service does not guarantee the connection to the calling device; only that an attempt will be made to connect to the device. 2. The calling device in a Make Predictive Call service request is often a group or ACD device that then allocates the new call to another calling device. 3. A typical use of the Make Predictive Call service is to place calls outside the CSTA switching subdomain. The CSTA connection identifier reported in the positive acknowledgement refers to the Network Interface Device associated with the called device. 4. The parameter defaultAction is used in situations where the switching function detects that the signallingCondition in the service request cannot be met. For example, the requestor of the service has the capability to instruct the switching function to either connect the calling device for listening to the voice channel or to clear the call. 5. If the validation of the Make Predictive Call fails initial for any reason, the computing function receives a negative acknowledgement, and no valid ConnectionIDs will have been created. 6. If the autoOriginate parameter is supported by the switching function and has a value of attempt, and if the calling device is not capable of automatically answering the device, then the processing of this parameter is switching function dependent. - 319 -
7. Call Forwarding and Do Not Disturb features for the calling device are not honoured for the call being made. If a switching function determines that it will not be able to deliver the call to the calling device (due to an active feature that cannot be overridden), then the switching function shall return a negative acknowledgement before the call is launched to the called device. 8. All active features are honoured for the called device. 9. Multi-stage dialling is not supported for the Make Predictive Call service. 10. The switching function may indicate that the calling device is involved with a predictive call prior to any call activity at the calling device by generating a Service Initiated event (with a cause of Make Predictive Call) for the calling device. When the Service Initiated event is generated in this case, it is generated prior to any call control events at the called device. If the switching function does not generate the Service Initiated event in this case, no call control events will be generated for the calling device until after the calling device is joined into the call. If the calling device cannot be joined in the call, a Connection Cleared event is generated for the initiatedConnection.
- 320 -
C
17.1.21 Park Call
S
The Park Call service moves a specified call at a device to a specified (parked-to) destination. The device on whose behalf Park Call was invoked (the parking device) is no longer associated with the call (except when the parking device parks a call back to the parking device). Figure 17-25 Park Call Service BEFORE SERVICE
D1 (parking)
c, h
*
C1
AFTER SERVICE
D2 (parked)
D3 (parkTo)
D1
C1
D2
q
D3
DEVICES D1 : parking device D2 : parked device D3 : parkTo device
*
AFFECTED CONNECTIONS D1C1 : parking connection D3C1 : parkedTo connection CONNECTION STATES c : connected state h : hold state q : queued state * : (unspecified/unaffected)
CALLS C1 : existing call
Note that the parking device and the parkTo device may be the same (when a call is parked to the parking device). Note that D1C1 can transit to the Queued state for certain Shared Bridged device configurations (see Functional Requirement #6). 17.1.21.1 Service Request Table 17-115 Park Call—Service Request Parameter Name
Type
M/ O/C
Description
parking
ConnectionID
M
Specifies the connection to be parked.
parkTo
DeviceID
M
Specifies the device to which the call is to be parked (parked-to device). This may be either a station or a Park device.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences to be associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.21.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 321 -
17.1.21.2.1Positive Acknowledgement Table 17-116 Park Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
parkedTo
ConnectionID
O
Specifies the connection at the parkedTo device.
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.21.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.21.3 Operational Model 17.1.21.3.1Connection State Transitions Table 17-117 Park Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (parking)
Hold or Connected
Null, Queued (see item #1)
D2C1 (parked)
(Unspecified)
(Unaffected; no transition due to this service).
D3C1 (parkTo)
Null
Queued
1. Connection D1C1 may transit to the Queued state for certain shared bridged device configurations (see functional requirement #5). 17.1.21.3.2Device-Type Monitoring Event Sequences Table 17-118 Park Call—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
Event Cause
D1 (parking device)
D1C1
Diverted (see items #1, #2)
Park or Normal
D2 (parked device)
D1C1
Diverted (optional) (see items #1, #2, #4)
Park or Normal
D3C1
Queued
Park or Normal
D3C1
Queued
Park or Normal
D3 (parkTo device)
17.1.21.3.3Call-Type Monitoring Event Sequences Table 17-119 Park Call—Call-Type Monitoring Event Sequences Monitored Call C1
Connection
Event
Event Cause
D1C1
Diverted (optional) (see items #1, #2, #5)
Park or Normal
D3C1
Queued
Park or Normal
1. A Connection Cleared event will not be provided for the parking ConnectionID. The Diverted event implies the ConnectionID has gone to Null. 2. The Diverted event is not provided when a call is parked to the parking device (devices D1 and D3 are the same).
- 322 -
3. If the parking device stays offhook and receives busy or blocked tone, the switching function sends a Failed event (event cause of Blocked or Busy) for a call with a different callID (not C1), followed by a Connection Cleared event. 4. The switching function provides the Diverted event for D2 only if it is providing Diverted events for all devices in a call.This is indicated through the capabilities exchange services. 5. For call-type monitoring, the switching function provides the Diverted event for C1 only if it is providing Diverted events for call-type monitors. This is indicated through the capabilities exchange services. 6. If a Bridged event is generated for an Independent Shared Bridged device configuration (see Functional Requirement #5), it is not part of the service completion criteria. 17.1.21.3.4Functional Requirements
1. As a result of the Park Call service, the call ID associated with this call remains unchanged. 2. A call may be parked at a device which is already involved with the call. In this case the parking device (D1) and the parkTo (D3) are the same. Refer to Figure 17-25 for specific requirements for this configuration. 3. The switching function may have a time-out period for the call once it is parked. If the call is not unparked before the time-out period ends, then the parked call may ringback the parking device or another switching defined device such as an attendant console, for example, or the call may be dropped. 4. Features such as Do Not Disturb and Forwarding are honoured at the parkedTo device when the call is being parked. 5. For Shared Bridged device configurations, when a call is parked from an appearance (parking) all appearances will be cleared from the call (i.e., Connection Cleared events with a cause of Normal Clearing), except when the call that is being parked is part of an Independent Shared Bridged device configuration and the appearance that is parking the call is not the last appearance connected into the call. In this case the appearance parking the call will return to the inactive mode (i.e., Bridged event with a cause of Normal) and the other appearances are unaffected. For more information, refer to Annex A.2.3, “Shared-Bridged”. 6. This service request does not support the use of a null device identifier or a Diallable Digits format (DD) device identifier that has a partial dialling sequence character (i.e., the “;” character) in it for the parkTo parameter. A complete and valid device identifier shall be provided, otherwise the switching function will reject the service request with a negative acknowledgement.
- 323 -
C
17.1.22 Reconnect Call
S
The Reconnect Call service will clear a specified connection at the reconnecting device and retrieve a specified held connection at the same device. Figure 17-26 Reconnect Call Service BEFORE SERVICE
D1 (reconnecting)
AFTER SERVICE
h
C1
*
D2
a, c, f, i, q
C2
!
D3
D1
DEVICES D1 : reconnecting device D2 : device in call C1 with device D1 D3 : device in call C2 with device D3
c
C1
*
D2
C2
!
D3
AFFECTED CONNECTIONS D1C1 : heldCall connection CONNECTION STATES a : alerting state c : connected state f : fail state h : hold state i : initiated state q : queued state ! : (unspecified) * : (unspecified/unaffected)
CALLS C1 : held call C2 : active call
17.1.22.1 Service Request Table 17-120 Reconnect Call—Service Request Parameter Name
Type
M/ O/C
Description
activeCall
ConnectionID
M
Specifies the connection to be cleared.
heldCall
ConnectionID
M
Specifies the held connection.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.22.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.22.2.1Positive Acknowledgement Table 17-121 Reconnect Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.22.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121.
- 324 -
17.1.22.3 Operational Model 17.1.22.3.1Connection State Transitions Table 17-122 Reconnect Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (heldCall)
Hold
Connected
D1C2 (activeCall)
Alerting, Connected, Initiated, Fail, or Queued
Null
D2C1
(Unspecified)
(Unaffected)
D3C2
(Unspecified)
(Unspecified)
17.1.22.3.2Device-Type Monitoring Event Sequences Table 17-123 Reconnect Call—Device-Type Monitoring Event Sequences Monitored Device D1 (reconnecting device)
Connection
Event
Event Cause
D1C2
Connection Cleared
Normal Clearing, Call Canceled
D1C1
Retrieved
Normal
D2 (and other devices in call C1)
D1C1
Retrieved
Normal
D3 (and other device in call C2)
D1C2
Connection Cleared
Normal Clearing, Call Canceled
17.1.22.3.3Call-Type Monitoring Event Sequences Table 17-124 Reconnect Call—Call-Type Monitoring Event Sequences Monitored Call
Connection
Event
Event Cause
C2
D1C2
Connection Cleared
Normal Clearing, Call Canceled
C1
D1C1
Retrieved
Normal Clearing
17.1.22.3.4Functional Requirements
1. This service is a compound service that is equivalent to a computing function issuing a Clear Connection service for the activeCall ConnectionID and then issuing a Retrieve Call service for the heldCall ConnectionID. 2. If all appearances of a shared bridged device configuration are in the hold state and the heldCall parameter contains an appearance’s connection ID in the call, then the other appearances in the device configuration will return to the inactive mode (queued state, Bridged events). 3. When the last connected appearance, in a shared bridged device configuration, is cleared as a result of the Reconnect service, all other device configuration appearance associated with the activeCall connection are also cleared from the call (i.e., Connection Cleared events). 4. If the Hold Call, Consultation Call, or the Alternate Call service was used to place the call on hold and the connectionReservation parameter was used to reserve the media stream channel(s) for the held call (e.g., ISDN bearer channel), then the same media stream channel(s) will be used for the call when it becomes reconnected.
- 325 -
C
17.1.23 Retrieve Call
S
The Retrieve Call service connects a specified held connection. Figure 17-27 Retrieve Call Service BEFORE SERVICE
D1 (retrieving)
h
C1
AFTER SERVICE
D2 (held)
*
D1
DEVICES D1 : retrieving device D2 : held device
c
C1
*
D2
AFFECTED CONNECTIONS D1C1 : callToBeRetrieved connection CONNECTION STATES h : hold state c : connected state * : (unspecified/unaffected)
CALLS C1 : held call
17.1.23.1 Service Request Table 17-125 Retrieve Call—Service Request Parameter Name
Type
M/ O/C
Description
callToBeRetrieved
ConnectionID
M
Specifies the held connection to be retrieved.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.23.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.23.2.1Positive Acknowledgement Table 17-126 Retrieve Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.23.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.23.3 Operational Model 17.1.23.3.1Connection State Transitions Table 17-127 Retrieve Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (callToBeRetrieved)
Hold
Connected
D2C1 (and any other connections in call C1)
(Unspecified)
(Unaffected; no transition due to this service).
- 326 -
17.1.23.3.2Device-Type Monitoring Event Sequences Table 17-128 Retrieve Call—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
Event Cause
D1 (retrieving device)
D1C1
Retrieved
Normal
D2 (and any other devices in call C1)
D1C1
Retrieved
Normal
17.1.23.3.3Call-Type Monitoring Event Sequences Table 17-129 Retrieve Call—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1
Event Retrieved
Event Cause Normal
17.1.23.3.4Functional Requirements
1. The Retrieve Call service may only be requested for a connection at a device’s physical element if there is no other connected connection already present at the device’s physical element. A device’s physical elements can only interact with one voice call at a time so if an attempt is made to retrieve a call while another voice call is connected, the switching function sends a negative acknowledgement to the Retrieve Call service request. 2. If the Hold Call, Consultation Call, or the Alternate Call service was used to place the call on hold and the connectionReservation parameter was used to reserve the media stream channel(s) for the held call (e.g., ISDN bearer channel), then the same media stream channel(s) will be used for the call when it becomes reconnected. 3. There may or may not be a media stream channel(s) available for the call on hold. In the case where a media stream channel(s) is not available, the switching function is unable to comply with the service request. In this case the switching function will send either a negative acknowledgement or the Service Completion Failure event, depending upon the acknowledgement model. 4. If all appearances of a shared-bridged or exclusive-bridged device configuration are in the hold state and the callToBeRetrieved parameter contains an appearance’s connection ID in the call, then the other appearances in the device configuration will return to the inactive mode (queued state, Bridged events) in the case of shared-bridging or the blocked mode (fail state, failed events) in the case of exclusive bridging.
- 327 -
C
17.1.24 Send Message
S
The Send Message service allows the computing function to send a message to one or more devices. The message, composed of one or more MIME body parts, is included in the Send Message service request. This service can be used to send messages for many different types of applications (Instant Messaging, Email, Pager, and Short Message Service (SMS), etc.). A message created by the Send Message service creates a non-interactive CSTA call (i.e., a call with only one device associated with the call at any time). This is different from a CSTA call created by the Make Call service which is usually associated with more than one device. Initially a connection is created with the calling device for each destination device provided in the service request. After the connection is established then each message is diverted to its specified destination device. The list of CSTA ConnectionIDs that were created at the calling device is provided in the positive acknowledgement. The CSTA ConnectionIDs can be used to track the movement of the message throughout CSTA devices and can be used to manage the message using CSTA services. Figure 17-28 Send Message Service DURING SERVICE
BEFORE SERVICE
AFTER SERVICE
D2 D1 (calling)
D2 D1
c
C1
c
C2
D1
a, c f, q, n
D2
C1 C2
a, c f, q, n
D3
D3
D3 DEVICES D1 : callingDevice D2 : destination device 1 D3 : destination device 2 CALLS C1 : initiated call 1 C2 : initiated call 2
AFFECTED CONNECTIONS D1C1 : callingDevice connection 1 D1C2 : callingDevice connection 2 CONNECTION STATES a : alerting state c : connected state f : failed state n : null state q : queued state
In the above figure, a unique connection has been established at the calling device for each message destination specified in the service request. After the service is completed, the message(s) have been diverted from the calling device. 17.1.24.1 Service Request Table 17-130 Send Message—Service Request Parameter Name callingDevice
Type DeviceID
M/ O/C
Description
M
Specifies the calling/originating device. This is the device on whose behalf the message is being sent. Note that this device may be a device that represents a group of devices. In this case the callingDevice in the service request is different from the actual calling device.
destinationDevices
List of DeviceID
M
- 328 -
Specifies the list of devices where the message is to be sent.
Table 17-130 Send Message—Service Request (concluded) Parameter Name messageInfo
Type MessageInfo
M/ O/C
Description
M
Specifies the message to be sent. The message consists of one or more parts. Each part consists of: • contentTypeAndSubtype (O) Characters. A character string indicating the IANA assigned media content type and subtype. If this component is omitted the default is “text/plain”. • contents (M) Characters. A sequence of characters representing the contents of the message part. • contentsLength (O) Value. The length of the contents associated with the message part, in bytes.
accountCode
AccountInfo
O
Specifies the account code to associate with the new call.
authCode
AuthCode
O
Specifies the authorization code to allow the call.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call. This parameter can be used to associate multiple messages to the same “conversation”.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (Priority call, for example) to be associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values. If the supported characteristics cannot be honoured, the switching function shall reject the service request.
mediaCallCharacteristics
MediaCallCharacteristics
O
This specifies the media characteristics to be associated with the call being made. If this parameter is not present then the media class is Message.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences to be associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information.
17.1.24.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 329 -
17.1.24.2.1Positive Acknowledgement Table 17-131 Send Message—Positive Acknowledgement Parameter Name connectionList
Type list of ConnectionIDs
M/ O/C
Description
M
Specifies the connections that have been created at the calling device. Note that the calling device parameter in the service request may be different from the deviceID in the connectionID of callingDevice in the positive acknowledgement (when the callingDevice in the service request represents a group of stations, for example).
mediaCallCharacteristics
MediaCallCharacteristics
C
This specifies the adjusted media characteristics for the call being made. This parameter shall be provided if the call characteristics have been adjusted, otherwise it is optional.
listOfCallLinkageData
list of CallLinkageData
O
Specifies the global call data and thread data associated with the call. Note that the callLinkageData and connectionIDs items are in the same order.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.24.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.24.3 Operational Model 17.1.24.3.1Connection State Transitions
This section assumes one message is being sent. In the case where the service request indicates multiple destinations, there would be multiple calls established and diverted from the calling device. Table 17-132 Send Message—Connection State Transitions Connection
Initial State (Required)
Transient State (See Note 1)
D1C1 (callingDevice)
Null
Connected
D2C1 (called)
Null
Null
Final State Null Alerting, Connected, Queued, Fail, or Null (Null if call moves away from the originally called device [i.e., forwarded]).
1. For each message that is to be sent, a connection is established at the calling device before it is diverted to its destination device.
- 330 -
17.1.24.3.2Device-Type Monitoring Event Sequences
This section assumes one message is being sent. In the case where the service request indicates multiple destinations, there would be multiple calls established and diverted from the calling device. Table 17-133 Send Message—Device-Type Monitoring Event Sequences Monitored Device D1 (calling device)
D2 (called device)
Connection
Event
Event Cause
D1C1
Originated
Normal
D1C1
Diverted
Normal
D2C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (i.e., Forward, Do Not Disturb, etc.). (see item #1)
17.1.24.3.3Call-Type Monitoring Event Sequences
Table 17-134 Send Message —Call-Type Monitoring Event Sequences Monitored Call C1
Connection
Event
Event Cause
D1C1
Originated
Normal
D1C1
Diverted
Normal
D2C1
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (i.e., Forward, Do Not Disturb, etc.). (see item #1)
17.1.24.3.4Functional Requirements
1. A message created by the Send Message service is modeled as a single non-interactive CSTA call. This non-interactive call is independent of any other call. The correlatorData parameter can be used by an application to associate several of these non-interactive calls to a specific “conversation” or “dialog” between users. 2. If an application wants to establish an interactive call between users for the purpose of exchanging messages (e.g. an Internet Chat session), it should use the Make Call service to establish a CSTA call (specifying a mediaClass in mediaCallCharacteristics of “chat” and specifying via connectionInformation that no media channels should be allocated for the call) and then use the Send User Information service to send the messages. 3. The ability to send messages to a device, the timing of when the information can be sent, and the size of the data that can be sent, depends upon the switching function’s capabilities and the underlying signalling network. 4. If the validation of the Send Message service fails for any reason, the computing function receives a negative acknowledgement, and no ConnectionIDs will have been created. 5. The Send Message positive response only indicates that the request to send a message(s) has been accepted. It does not indicate that the message has been received by the intended destination. If a service request results in a positive response, but a message was unable to be diverted to a destination device, the switching function shall indicate that the connection associated with the message at the calling device has failed (Failed event) and then cleared (Connection Cleared). The connectionID associated with the cleared connection shall be included in the list of connections in the positive acknowledgement. The application should monitor the calling device to determine if a message has been diverted or failed.
- 331 -
6. Call Forwarding and Do Not Disturb features for the calling device are not honoured for the call being made. 7. All active features are honoured for the called device. 8. The switching function may or may not adjust the media characteristics and connection information that were supplied on the Send Message service request (Use the capabilities exchange services to determine which feature the switching function supports). If the switching function supports adjusting the characteristics/connection information and if the original characteristics/connection information cannot be provided the service request will be rejected with an appropriate error code. If the switching function can adjust the characteristics/connection information, the positive acknowledgement will contain the adjusted value or values. If the computing function determines that the adjusted values are not adequate, it can terminate the call (e.g., Clear Connection). 9. The callingDevice parameter in the Send Message service request may represent a group of devices from which the actual calling device is selected. In this case, the callingDevice parameter in subsequent events shall refer to the actual calling device. In addition, the Originated event contains a parameter (originatingDevice) that represents the group of devices (the callingDevice parameter passed in service request). 10. The Send Message service can be used for content adaptation - where the switching function modifies the format of the messageContents to match the mediaCallCharacteristics in the service request and/or the characteristics of the destinationDevice. For example, a voice encoded message in the messageInfo parameter in the service request could be converted to a plain text formatted message for display on a device. This content adaptation is switching function specific. 11. The mediaCallCharacteristics parameter can provide protocol specific information via the switchingSubDomainInformationElements parameter. This can be used to provide SIP-specific header information, for example. The use of this protocol specific information is switching function specific.
- 332 -
C
17.1.25 Single Step Conference Call
S
The Single Step Conference Call joins a new device into an existing call. This service can be repeated to make n-device conference calls (subject to switching function limits). This service is distinguished from the Join Call service by the way the device being added to the call perceives the direction of the resulting connection (e.g. alerts). In the case of the Join Call service, the device generates an outgoing connection (e.g. prompts). This affects the parameters associated with the service and the events flowing as a result of the service. Figure 17-29 Single Step Conference Call Service BEFORE SERVICE
D1
*
AFTER SERVICE
*
C1
D2
D1
*
D3 (deviceToJoin)
DEVICES D1 : device in call C1 with device D2 D2 : device in call C1 with device D1 D3 : deviceToJoin device
*
D2
a, c f, n, q
D3
C1
AFFECTED CONNECTIONS D3C1 : conferencedCall connection CONNECTION STATES a : alerting state c : connected state f : fail state n : null state q : queued state * : (unspecified/unaffected)
CALLS C1 : existing call
Note that the activeCall connection in the service request may be either D1C1 or D2C1. 17.1.25.1 Service Request Table 17-135 Single Step Conference Call—Service Request Parameter Name
Type
M/ O/C
Description
activeCall
ConnectionID
M
Specifies an existing connection in the call to which a new device is to be added.
deviceToJoin
DeviceID
M
Specifies the device that is to be added to the call.
- 333 -
Table 17-135 Single Step Conference Call—Service Request (concluded) Parameter Name participationType
Type Enumerated
M/ O/C
Description
O
Specifies the type of participation the added device has in the resulting call. The complete set of possible values is: • Active (default) - The added device actively participates in the resulting conference call. As a result, the flow direction of the deviceToJoin’s connection (i.e., conferencedCall) will be Transmit and Receive. • Silent - The added device can listen but cannot actively participate in the resulting conference call. As a result, the flow direction of the deviceToJoin’s connection (i.e., conferencedCall) will be Receive. • None - The added device cannot actively participate in the resulting conference call. As a result, the flow direction of the deviceToJoin’s connection (i.e., conferencedCall) will be None.
accountCode
AccountInfo
O
Specifies the account code to associate with the call.
authCode
AuthCode
O
Specifies the authorization code to allow the call.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences to be associated with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.25.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 334 -
17.1.25.2.1Positive Acknowledgement Table 17-136 Single Step Conference Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
conferencedCall
ConnectionID
M
Specifies the callID of the existing active call and the DeviceID of the joining device.
conferencedCallInfo
ConnectionInformation
O
Specifies the connection information associated with the conferencedCall connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageDataList
List
O
Specifies the global call data and thread data associated with the call. The parameter consists of the following components: • newCallLinkageData (M) CallLinkageData - specifies the call linkage data associated with the resulting call. • oldCallLinkageData (M) CallLinkageData - specifies the call linkage data that was discarded as the result of the conference.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.25.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121.
17.1.25.3 Operational Model 17.1.25.3.1Connection State Transitions Table 17-137 Single Step Conference Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1
(Unspecified)
(Unaffected; no transition due to this service)
D2C1
(Unspecified)
(Unaffected; no transition due to this service)
D3C1 (conferencedCall)
Null
Alerting, Connected, Queued, Fail, or Null (Null if call moves away from D3 [i.e., forwarded]).
- 335 -
17.1.25.3.2Device-Type Monitoring Event Sequences Table 17-138 Single Step Conference Call—Device-Type Monitoring Event Sequences Monitored Device D1
D2
D3 (deviceToJoin)
Connection
Event
Event Cause
D3C1 (conferencedCall)
Note that it is switching function dependent if other events flow before the Conferenced event. (See item #2)
D3C1 (conferencedCall)
Conferenced
D3C1 (conferencedCall)
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (See item #3)
D3C1 (conferencedCall)
Note that it is switching function dependent if other events flow before the Conferenced event. See Functional Requirement #2.
D3C1 (conferencedCall)
Conferenced
D3C1 (conferencedCall)
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (See Item #3)
D3C1 (conferencedCall)
Note that it is switching function dependent if other events flow before the Conferenced event. See Functional Requirement #2.
D3C1 (conferencedCall)
Conferenced
D3C1 (conferencedCall)
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (See Item #3)
Silent or Active Participation, or Single Step Conference
Silent or Active Participation, or Single Step Conference
Silent or Active Participation, or Single Step Conference
17.1.25.3.3Call-Type Monitoring Event Sequences Table 17-139 Single Step Conference Call—Call-Type Monitoring Event Sequences Monitored Call C1
Connection
Event
Event Cause
D3C1
Note that it is switching function dependent if other events flow before the conferenced event. See Functional Requirement #2.
D3C1
Conferenced
D3C1 (conferencedCall)
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see Item #3)
Silent or Active Participation, or Single Step Conference
1. The event cause is based on the value of the participationType parameter. •
If it was set to active, then the event cause will be Active Participation.
•
If it was set to silent or none, then the event cause will be Silent Participation.
•
If the switching function cannot determine the type used, then the event cause will be Single Step Conference.
2. If the deviceToJoin is not in the connected state after the Single Step Conference Call service is executed, then normal call progress events will flow regarding the state of this device after the - 336 -
Conferenced event. Devices in the resulting call will hear the call progress associated with the deviceToJoin. 3. Providing of these events by the switching function does not affect the service completion conditions (i.e., a service is considered complete without these events being provided). 17.1.25.3.4Functional Requirements
1. The call ID in the ConnectionIDs for the resulting conference call is the same as that in the original active call. 2. It is switching function dependent to determine at which point in the call progress a device is actually conferenced into a call. For example, a device may become part of an existing call before it is actually conferenced into a call. In this case, additional events may flow before the Conferenced event. The callID in the ConnectionIDs for these events shall be the same as that in the original active call and shall be the same as in the Conferenced event that follows. 3. The appearances in a shared bridged device configuration are unaffected by this service. 4. This service request does not support the use of a null device identifier or a Diallable Digits format (DD) device identifier that has a partial dialling sequence character (i.e., the “;” character) in it for the deviceToJoin parameter. A complete and valid device identifier shall be provided, otherwise the switching function will reject the service request with a negative acknowledgement. 5. For the new destination device (deviceToJoin), all active features for the device are honoured. 6. If this service is used to add a device into a digital data call, the connection for the deviceToJoin (i.e., conferencedCall) will inherit the characteristics of the call with the exception of connection flow direction and the number of channels used. In these cases, the connection flow direction is dependent on the value of participationType and the number of channels is based on what the switching function will use to allow the deviceToJoin to effectively participate in the call.
- 337 -
C
17.1.26 Single Step Transfer Call
S
The Single Step Transfer Call service transfers an existing connection at a device to another device. This transfer is performed in a single-step, that is the device doing the transfer does not have to place the existing call on hold before issuing the Single Step Transfer Call service. The transferring connection may be in the Alerting, Connected, Failed, Held, or Queued state. Figure 17-30 Single Step Transfer Call Service BEFORE SERVICE
D1 (transferring)
a, c f, h, q
C1
AFTER SERVICE
D2 (transferred)
#
#
D2
a, c f, n, q
D3
D1 C3
D3 (transferredTo)
DEVICES D1 : transferring device D2 : transferred device D3 : transferredTo device
AFFECTED CONNECTIONS D1C1 : activeCall connection D3C3 : transferredCall connection CONNECTION STATES a : alerting state c : connected state f : fail state n : null state q : queued state h : held state
CALLS C1 : activeCall C3 : transferredCall
17.1.26.1 Service Request Table 17-140 Single Step Transfer Call—Service Request Parameter Name
Type
M/ O/C
Description
activeCall
ConnectionID
M
Specifies the connection in the call to be replaced.
transferredTo
DeviceID
M
Specifies the new called (transferredTo) device.
accountCode
AccountInfo
O
Specifies the account code to associate with the call.
authCode
AuthCode
O
Specifies the authorization code to allow the call.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
userData
UserData
O
Specifies the user data to be sent to parties in the call.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (Priority call, for example) to be associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values. If the supported characteristics cannot be honoured, the switching function shall reject the service request.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences to be associated with the call.
reason
EventCause
O
Specifies the reason the connection is being transferred. See 12.2.15, “EventCause”, on page 132 for a list of possible values.
- 338 -
Table 17-140 Single Step Transfer Call—Service Request (concluded) Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.26.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.26.2.1Positive Acknowledgement Table 17-141 Single Step Transfer Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
transferredCall
ConnectionID
M
Specifies the ConnectionID of the transferredTo device in the transferred call.
connections
ConnectionList
O
Specifies information on each device/connection that is remaining in the call as a result of the service.
transferredCallInfo
ConnectionInformation
O
Specifies the connection information associated with the transferredCall connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageDataList
List
O
Specifies the global call data and thread data associated with the call. The parameter consists of the following components: • newCallLinkageData (M) CallLinkageData - specifies the call linkage data associated with the resulting call. • oldCallLinkageData (M) CallLinkageData - specifies the call linkage data that was discarded as the result of the transfer.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.26.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.26.3 Operational Model 17.1.26.3.1Connection State Transitions Table 17-142 Single Step Transfer Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (activeCall)
Connected, Alerting, Failed, Held, Queued
Null
D2C1 and any other Connections in the call C1
(Unspecified)
Null
D2C3
Null
(Inherited from the corresponding connection in call C1)
D3C3 (transferredCall)
Null
Alerting, Connected, Queued, Fail, or Null (Null if call moves away from the originally transferredTo device [i.e., forwarded])
- 339 -
17.1.26.3.2Device-Type Monitoring Event Sequences Table 17-143 Single Step Transfer Call—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
Event Cause
D1 (transferring)
D1C1
Transferred (see item #3)
Single Step Transfer
D2 (transferred device) (and any other devices in the resulting call)
D1C1
Transferred
Single Step Transfer
D3C3 (transferredCall)
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #4)
D3C3 (transferredCall)
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #4)
D3 (transferredTo)
17.1.26.3.3Call-Type Monitoring Event Sequences Table 17-144 Single Step Transfer Call—Call-Type Monitoring Event Sequences Monitored Call
Connection
Event
Event Cause
C1
D1C1
Transferred (see item #3)
Single Step Transfer
C3
D3C3 (transferredCall)
Events depend on the type of device (ACD, extension, external device, etc.) and features activated at it at the time of this service (Forward, Do Not Disturb, etc.). (see item #4)
1. If the transferredTo device is not in the connected state after the Single Step Transfer Call service is executed, then normal call progress events will flow regarding the state of this device after the Transferred event. 2. A Connection Cleared event will not be seen for the activeCall ConnectionID; the Transferred event implies that the connection at the transferringDevice has been cleared. 3. If the transferring device stays off-hook and receives busy or blocked tone, the switching function sends a Failed event (event cause of Blocked or Busy) for a call with a different callID (not C1 or C3), followed by a Connection Cleared event. 4. Providing of these events by the switching function does not affect the service completion conditions (i.e., a service is considered complete without these events being provided). 5. If a Bridged event is generated for an Independent Shared Bridged device configuration (see Functional Requirement #5), it is not part of the service completion criteria. 17.1.26.3.4Functional Requirements
1. The computing function should never assume the reuse of callIDs, although some switching functions may reuse the activeCall callID for the transferredCall callID 2. As a result of this service, the device or devices being transferred may hear call-progress signals for the new device. For example, if the new device answers, the call resumes or if the new device is busy or does not answer, the other devices in the call may receive resulting call progress tones. In either case, the transferring device has left the call and has no further relationship with it. 3. If the Single Step Transfer Call service fails for any reason after the positive acknowledgement is returned, the switching function may return the call to the transferring device. Refer to 6.7.3, “Recall”, on page 73. 4. For the new destination device (transferredTo device), all active features for the device are honoured. 5. Shared Bridged device configurations, when a call is transferred by an appearance (transferring device) all appearances will be cleared from the call (i.e., Connection Cleared events with a cause of - 340 -
Normal Clearing), except when the call that is being transferred is part of an Independent Shared Bridged device configuration and the appearance that is transferring the call is not the last appearance connected into the call. In this case the appearance transferring the call will return to the inactive mode (i.e., Bridged event with a cause of Normal) and the other appearances are unaffected. For more information, refer to Annex A.2.3, “Shared-Bridged”. 6. This service request does not support the use of a null device identifier or a Diallable Digits format (DD) device identifier that has a partial dialling sequence character (i.e., the “;” character) in it for the transferredTo parameter. A complete and valid device identifier shall be provided, otherwise the switching function will reject the service request with a negative acknowledgement. 7. If this service is used to single step transfer a digital data call, the connection for the transferredTo device (i.e., transferredCall) will inherit the characteristics of the call.
- 341 -
C
17.1.27 Transfer Call
S
The Transfer Call service transfers a call held at a device to an active call at the same device. The held and active calls at the transferring device shall be merged into a new call. Also, the Connections of the held and active calls at the transferring device shall become Null and their ConnectionIDs shall be released (i.e., the transferring device is no longer involved with the call). Figure 17-31 Transfer Call Service BEFORE SERVICE
D1 (transferring)
h, c
c, h
AFTER SERVICE
C1
#
D2 (transferred)
C2
#
D3 (transferredTo)
DEVICES D1 : transferring device D2 : transferred device D3 : transferredTo device
D1
C3
#
D2
#
D3
AFFECTED CONNECTIONS D1C1 : originally heldCall connection D1C2 : originally activeCall connection D2C1 : transferred connection D3C2 : transferredTo connection
CALLS C1 : originally held call C2 : originally active call C3 : transferredCall
CONNECTION STATES c : connected state h : hold state # : (unspecified/inherited)
Note that both the D1C1 and D1C2 connections may be held or connected prior to the transfer. 17.1.27.1 Service Request Table 17-145 Transfer Call—Service Request Parameter Name
Type
M/ O/C
Description
heldCall
ConnectionID
M
Specifies the held connection.
activeCall
ConnectionID
M
Specifies the active connection.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.27.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 17.1.27.2.1Positive Acknowledgement Table 17-146 Transfer Call—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
transferredCall
ConnectionID
M
Specifies the ConnectionID of the transferredTo device in the resulting call.
connections
ConnectionList
O
Specifies information on each device/connection that is remaining in the call as a result of the service.
- 342 -
Table 17-146 Transfer Call—Positive Acknowledgement (concluded) Parameter Name
Type
M/ O/C
Description
transferredCallInfo
ConnectionInformation
O
Specifies the connection information associated with the transferredCall connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageDataList
List
O
Specifies the global call data and thread data associated with the call. The parameter consists of the following components: • newCallLinkageData (M) CallLinkageData - specifies the call linkage data associated with the resulting call. • oldCallLinkageData (M) CallLinkageData - specifies the call linkage data that was discarded as the result of the transfer.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.1.27.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 17.1.27.3 Operational Model 17.1.27.3.1Connection State Transitions Table 17-147 Transfer Call—Connection State Transitions Connection
Initial State (Required)
Final State
D1C1 (heldCall)
Connected, Hold
Null
D1C2 (activeCall)
Connected, Hold
Null
D2C1 and any other connections in call C1
(unspecified)
Null
D3C2 and any other connections in call C2
(unspecified)
Null
D3C3 and any other connections in call C3
Null
(Inherited from the corresponding connection in calls C1 and C2)
17.1.27.3.2Device-Type Monitoring Event Sequences Table 17-148 Transfer Call—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
Event Cause
D1 (transferring)
(See item #4)
Transferred (see item #3)
Transfer or Normal
D2 (transferred)
(See item #4)
Transferred
Transfer or Normal
D3 (transferredTo)
(See item #4)
Transferred
Transfer or Normal
17.1.27.3.3Call-Type Monitoring Event Sequences Table 17-149 Transfer Call—Call-Type Monitoring Event Sequences Monitored Call C1 or C2
Connection (See item #4)
Event Transferred (see items #1 and #2)
Event Cause Transfer
1. If the transferredTo device was not in the connected state prior to the Transfer Call service, then normal call progress events will flow after the Transferred event. Devices in the original held call will hear the call progress associated with the connection to the transferredTo device. - 343 -
2. A Connection Cleared Event will not be provided for the activeCall or heldCall ConnectionIDs. The Transferred event implies connection cleared for the transferring device. 3. If the transferring device stays off-hook and receives busy or blocked tone, the switching function may send a Failed event (event cause of Blocked or Busy) for a different call, followed by a Connection Cleared event. 4. There are multiple connections affected by this service. 5. If a Bridged event is generated for an Independent Shared Bridged device configuration (see Functional Requirement #4), it is not part of the service completion criteria. 17.1.27.3.4Functional Requirements
1. To get the connections for each of the devices to their initial states, the computing function can either: •
Use the Consultation Call service to place a call on hold and place a new call.
•
Use the Alternate Call service to place a call on hold and answer an alerting call.
In either of these cases, if the switching function supports the consultOptions parameter in these services, the computing function shall provide this parameter with a value of either “Transfer Only” or “Unrestricted”. Some switching function support a third approach for preparing for the Transfer Call service involving the use of a hold service followed by a Make Call. The fourth approach supported by some switching functions involves two held calls at the same device. Certain switching functions also support a fifth approach involving two active calls at the same device. The computing function should use the capabilities exchange services to determine which of these approaches is supported by the switching function. 2. If the computing function uses the Consultation Call service and specifies the consultOptions parameter with a value of Conference, and then attempts to complete the consultation call with a Transfer Call service, it will be rejected with a negative acknowledgement. 3. If the call is not established at the transferredTo device, the switching function may return the call to the transferring device. Refer to 6.7.3, “Recall”, on page 73. 4. For Shared Bridged device configurations, when a call is transferred by an appearance (transferring device) all appearances will be cleared from the call (i.e., Connection Cleared events with a cause of Normal Clearing), except when the call that is being transferred is part of an Independent Shared Bridged device configuration and the appearance that is transferring the call is not the last appearance connected into the call. In this case the appearance transferring the call will return to the inactive mode (i.e., Bridged event with a cause of Normal) and the other appearances are unaffected. For more information, refer to Annex A.2.3, “Shared-Bridged”. 5. The computing function should never assume the reuse of callIDs, although some switching functions may reuse one or the other.
- 344 -
17.2
Events Table 17-150 Call Control Events Summary Call Control Event
Description
Pg.
17.2.1 Bridged
Indicates that an appearance at a shared bridged device configuration has been placed into an inactive mode (i.e., queued state).
346
17.2.2 Call Cleared
Indicates that all devices have been removed from an existing call.
348
17.2.3 Conferenced
Indicates that the conferencing device has conferenced itself or another device with an existing call.
351
17.2.4 Connection Cleared
Indicates that a device in a call has disconnected or dropped out from a call.
357
17.2.5 Delivered
Indicates that a call is being presented to a device in either the Ringing or Entering Distribution modes of the alerting state.
361
17.2.6 Digits Dialled
Indicates that a call or feature is being attempted from a device and that a portion of the dialling sequence has been completed.
366
17.2.7 Diverted
Indicates that a call has been diverted from a device.
369
17.2.8 Established
Indicates that a device has answered or has been connected to a call.
374
17.2.9 Failed
Indicates that a call cannot be completed and/or a connection has entered the Fail state.
380
17.2.10 Held
Indicates that an existing call has been put on hold.
385
17.2.11 Network Capabilities Changed
Indicates that a situation occurred during a call’s progress in a public or private network that modifies its signalling capability (i.e., inter-networking).
387
17.2.12 Network Reached
Indicates that a call has been connected to an external network using a Network Interface Device (e.g., trunk, CO Line).
390
17.2.13 Offered
Indicates that a call is in a pre-delivery state at a device (prior to ringing indication or delivering ringback, for example).
394
17.2.14 Originated
Indicates that a call is being attempted from a device.
399
17.2.15 Queued
Indicates that a call has been queued.
402
17.2.16 Retrieved
Indicates that a previously held call has been retrieved.
406
17.2.17 Service Initiated
Indicates that a device has gone off-hook for service or is being prompted to go off-hook.
408
17.2.18 Transferred
Indicates that an existing call has been transferred to another device and that the device transferring the call has been dropped from the call.
412
- 345 -
17.2.1
Bridged The Bridged event indicates that an appearance at a shared bridged device configuration has been placed into an inactive mode (i.e., queued state). See the device configuration section for more details on shared bridged device configurations, Common situations that generate this event include: •
When the first appearance in a shared bridged device configuration appearance connects into the call at the device (i.e., Answer Call) (manual and service request initiated), the other appearances enter the inactive mode.
•
When the first appearance in a shared bridged device configuration leaves a call at the device and at least one appearance is still connected into the call. (i.e., Clear Connection) (manual and service request initiated).
•
When the first appearance in a shared bridged device configuration retrieves a call and the other appearances return to the inactive mode. Figure 17-32 Bridged Event BEFORE EVENT
AFTER EVENT
D21
D21
*
*
D1
*
a, c h, n
C1
D1 (calling device)
D22
DEVICES D1 : calling device D21 : bridgedAppearance D22 : bridgedAppearance
*
C1
q
D22
AFFECTED CONNECTIONS D22C1 : bridgedConnection CONNECTION STATES c : connected state a : alerting state h : hold state q : queued state n : null state * : (unspecified/unaffected)
CALLS C1 : bridged call
17.2.1.1 Event Parameters Table 17-151 Bridged—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
bridgedConnection
ConnectionID
M
Specifies the connection of the appearance that was placed in the inactive mode.
bridgedAppearance
SubjectDeviceID
M
Specifies the appearance which was placed in the inactive mode.
- 346 -
Table 17-151 Bridged—Event Parameters (concluded) Parameter Name localConnectionInfo
Type LocalConnectionState
M/ O/C C
Description Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the bridged appearance at the bridged device: Queued
•
For the other appearances at the bridged device & all other devices left in the call: (unaffected)
This parameter is mandatory for events generated for device-type monitors and shall otherwise not be provided. correlatorData
CorrelatorData
O
Specifies the correlator data associated with the call.
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
bridgedConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the bridgedConnection connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies the non-standardized information attached to the event.
17.2.1.2 Event Causes Table 17-152 Bridged—Event Causes Event Cause Normal
Description An appearance has been placed into an inactive mode.
- 347 -
Associated Features Multi-Appearance
17.2.2
Call Cleared The Call Cleared event is only provided for calls that are being call-type monitored. This event indicates that a call has been cleared and no longer exists within the switching sub-domain. A call is cleared when there is no longer any device associated with the call. Common situations that generate this event include: •
After the last remaining device disconnects from the call.
•
All devices in a call are immediately disconnected from a call such as when a conference controller dissolves a call.
•
The computing function issues a Clear Call service request that is successful. Figure 17-33 Call Cleared Event BEFORE EVENT
D1
n
C1
AFTER EVENT
n
D2
n
D3
D1
D2
D3
DEVICES D1 : device in conference with D2 & D3 D2 : device in conference with D1 & D3 D3 : device in conference with D1 & D2
AFFECTED CONNECTIONS CONNECTION STATES n : null state
CALLS C1 : call to clear
17.2.2.1 Event Parameters Table 17-153 Call Cleared—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
clearedCall
ConnectionID
M
Specifies the ConnectionID of the cleared call. Note that the DeviceID shall be omitted in this ConnectionID.
correlatorData
CorrelatorData
O
Specifies the correlator data associated with the call.
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
cause
EventCause
M
Specifies the reason for the event. The cause supplied will be the same as the cause supplied on the last Connection Cleared event for the call.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
- 348 -
Table 17-153 Call Cleared—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information attached to the event.
17.2.2.2 Event Causes Table 17-154 Call Cleared—Event Causes Event Cause
Description
Associated Features
Busy
The call was cleared because it reached a busy destination.
Connection Failure
Busy Overflow
The call was cleared because all possible destinations for the call are busy or unavailable and there is no queueing mechanism (ACD, for example) available.
Clear Connection, Clear Call, Connection Failure
Calendar Overflow
The call was cleared because all possible calendar based destinations for the call are unavailable due to the time of the day or the day of the week.
Clear Connection, Clear Call, Connection Failure
Call Back
The call was cleared after a call back or call back message feature was invoked.
Call Back Call-Related, Call Back Message Call-Related
Call Cancelled
The call was cleared without a device going onhook (via the Clear Call service, for example).
Clear Connection, Clear Call, Connection Failure
Call Not Answered
The call was cleared because it was not answered before a timer elapsed.
Clear Connection, Clear Call, Connection Failure
Capacity Overflow
The call was cleared because all possible destinations are busy or unavailable and the call cannot be queued because the system is already at capacity.
Clear Connection, Clear Call, Connection Failure
Destination Out of Order
The call was cleared because it encountered a destination out of service.
Connection Failure
Do Not Disturb
The call was cleared because the call encountered a destination that has the Do Not Disturb feature set.
Do Not Disturb
Incompatible Destination
The call was cleared because it encountered an incompatible destination.
Connection Failure
Invalid Account Code
The call was cleared because of an invalid account code.
Connection Failure
Invalid Number Format
The call was cleared because of an incorrect dialled number.
Connection Failure
Maintenance
The call was cleared because it encountered a facility or endpoint in a maintenance condition.
Connection Failure
- 349 -
Table 17-154 Call Cleared—Event Causes (concluded) Event Cause
Description
Associated Features
Network Congestion
The call was cleared because it reached a congested network.
External Call
Network Not Obtainable
The call was cleared because it could not reach the destination network.
External Call
Network Out of Order
The call was cleared because it encountered a network that is out of order.
Connection Failure
Network Signal
The call was cleared that involved a device that is outside of the switching sub-domain.
Clear Connection, Clear Call, Connection Failure, External Call
Normal Clearing
The call was cleared (a more specific event cause cannot be provided).
Clear Connection, Clear Call, Any feature
Not Available Bearer Service
The call was cleared because it was requested with bearer capability that is currently not available.
Connection Failure
Not Supported Bearer Service
The call was cleared because it was requested with a bearer capability that is currently not supported.
Connection Failure
Number Changed
The call was cleared because the called number has been changed to a new number and the call cannot be completed.
Connection Failure
Number Unallocated
The call was cleared because the called number is not allocated to a subscriber.
Connection Failure
Override
The call was cleared because of an Override (e.g. Intrude) feature.
Connection Failure
Path Replacement
The call was cleared due to optimization of network (NID) resources.
Network feature
Queue Time Overflow
The call was cleared because all possible destinations for the call are busy or unavailable and the estimated holding time before the call can be answered is too long.
Clear Connection, Clear Call, Connection Failure
Reorder Tone
The call was cleared because the call encountered a reorder condition.
Connection Failure
Resource not Available
The call was cleared because resources were not available.
Connection Failure
Selected Trunk Busy
The call was cleared because the specific selected Network Interface Device (e.g., trunk, CO Line) is busy.
Connection Failure
Trunks Busy
The call was cleared because there was no available Network Interface Device (e.g. trunk, CO Line).
Connection Failure
Unauthorized Bearer Service
The call was cleared because it was requested with an unauthorized bearer capability.
Connection Failure
Unknown Overflow
The call was cleared because an overflow condition exists but the specific overflow reason is not known.
Clear Connection, Clear Call, Connection Failure
17.2.2.3 Functional Requirements 1. Connection Cleared events shall be sent for all devices in the call before the Call Cleared event is sent. The Call Cleared event can not be used as a substitute for the appropriate Connection Cleared events. 2. The Call Cleared event is only sent to call-type monitors. It is never sent to device-type monitors.
- 350 -
17.2.3
Conferenced The Conferenced event indicates that the conferencing device has conferenced itself or another device with an existing call and that no devices have been removed from the resulting call. Common situations that generate this event include: •
Two step conferencing situations (manual and service initiated)
•
Single step conferencing situations (manual and service initiated)
•
Intrude situations (manual and service initiated)
•
Join situations (manual and service initiated) Figure 17-34 Conferenced Event—Case A: Two Step Conferencing BEFORE EVENT
D1
c, h, q
c, h
AFTER EVENT
C1
#
D2
C2
#
D3
DEVICES D1 : conferencingDevice device D2 : device in conference with D1 and D3 D3 : addedParty device CALLS* C1 : primary old call C2 : secondary old call C3 : resulting call * the primary/secondary old call and the primary/secondary old call connections mentioned in this figure are from the perspective of the conferencingDevice (D1). See Functional
- 351 -
D1 (conferencingDevice)
c
C3
#
D2
#
D3 (addedParty)
AFFECTED CONNECTIONS D1C1 : primaryOldCall connection D1C2 : secondaryOldCall connection D2C1 : initial call at device D2 D3C2 : initial call at device D3 D1C3 : resulting call at device D1 D2C3 : resulting call at device D2 D3C3 : resulting call at device D3 CONNECTION STATES c : connected state h : hold state q : queued state # : (unspecified/inherited)
Figure 17-35 Conferenced Event—Case B: Single Step Conferencing BEFORE EVENT
D1
*
AFTER EVENT
C1
*
D2
D1 (conferencingDevice)
*
DEVICES D1 : conferencingDevice device D2 : device in conference with D1 & D3 D3 : addedParty device
C1
*
D2
a, c f, n, q
D3 (addedParty)
AFFECTED CONNECTIONS D1C1 : resulting call at device D1 D2C1 : resulting call at device D2 D3C1 : resulting call at device D3
CALLS C1 : primary old call C1 : resulting call (1)
CONNECTION STATES a : alerting state c : connected state f : failed state n : null state q : queued state * : (unspecified/unaffected)
1. Since the Call ID does not change for a Single Step Conference Call, the primary old call and the resulting call are the same.
Figure 17-36 Conferenced Event—Case C: Join Call BEFORE EVENT
D1
*
C1
AFTER EVENT
*
D2
*
DEVICES D1 : device in conference with D2 & D3 D2 : device in conference with D1 & D3 D3 : addedParty device, conferencingDevice
D2
*
D1
C1
c
D3 (addedParty, conferencingDevice)
AFFECTED CONNECTIONS D1C1 : resulting call at device D1 D2C1 : resulting call at device D2 D3C1 : resulting call at device D3 CONNECTION STATES * : (unspecified/unaffected) c : connected state
CALLS C1 : primary old call
1. Since the Call ID does not change for the Join Call service, the primary old call and the resulting call are the same.
- 352 -
Figure 17-37 Conferenced Event - Case D: Intrude Call BEFORE EVENT
AFTER EVENT D3
D3
# C2 # D1 (calling)
c
C1
#
D1 (addedParty,
c
C3
conferencingDevice)
#
D2 (called)
f
D2
f DEVICES D1 : calling device in call C1, addedParty/conferencingDevice in call C3 D2 : called device in call C1 D3 : device in call C2 with device D2
AFFECTED CONNECTIONS D1C1 : intrude connection D2C1 : called connection D2C2 : connection D3C2 : connection complete connection ID not provided
CALLS C1 : call that is attempting to connect to D2 C2 : existing call involving D2 & D3 C3 : resulting call involving D1, D2 & D3
CONNECTION STATES c : connected state f : fail state # : (unspecified/inherited)
Refer to 6.7.2, “Connection Failure”, on page 71 for a complete description of partial connection IDs. Refer to 17.1.16, “Intrude Call”, on page 294 for information on how a connection can transit to the connected state. 17.2.3.1 Event Parameters Table 17-155 Conferenced—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
primaryOldCall
ConnectionID
M
Specifies the connection of the primary call. See Functional Requirement #1.
secondaryOldCall
ConnectionID
C
Specifies the connection of the secondary call. If the switching function supports the “fixed-view” option (as indicated by the capability exchange services), this parameter is mandatory. If the switching function supports the “local-view” option, this parameter is mandatory if there are two known calls involved with the conference (before the conference is created) from the perspective of the monitored device, otherwise it shall not be provided. See Functional Requirement #1.
M
Specifies the device ID of the conferencing device.
addedParty
SubjectDeviceID 1 SubjectDeviceID 1
M
Specifies the device ID of the last device added to the call.
conferenceConnections
ConnectionList
M
Specifies information on each device/ConnectionID in the resulting conference call. See Functional Requirement #2.
conferencingDevice
- 353 -
Table 17-155 Conferenced—Event Parameters (continued) Parameter Name localConnectionInfo
Type
M/ O/C
LocalConnectionState
C
Description Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices that are in the conference call: •
Conferencing device - Connected (or Unaffected for Case B).
•
Other devices - (See above figures for specific cases of the Conferenced event)
This parameter is mandatory for events generated for device-type monitors and otherwise shall not be provided. correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call and shall otherwise not be provided.
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
callLinkageDataList
List
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided. The parameter consists of the following components: • newCallLinkageData (M) CallLinkageData - specifies the call linkage data associated with the resulting call. • oldCallLinkageData (M) CallLinkageData - specifies the call linkage data that was discarded as the result of the conference.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
deviceHistory
DeviceHistory
O
Specifies the list of devices which were previously associated with the call (e.g. redirecting, transferring, clearing devices).
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
- 354 -
Table 17-155 Conferenced—Event Parameters (concluded) Parameter Name privateData
Type
M/ O/C
CSTAPrivateData
O
Description Non-standardized information attached to the event.
1. Note that SubjectDeviceID refers to a parameter type—not the subject device of the Conferenced event. This parameter type is used to represent the two devices in this event because the two devices are affected by the generation of this event (i.e., the conferencing device and the addedParty device). However, there is only one device which is the subject of the event and that is the conferencing device. For more details on the SubjectDeviceID parameter type, see 12.3.30, “SubjectDeviceID”, on page 156.
17.2.3.2 Event Causes Table 17-156 Conferenced—Event Causes Event Cause Active Participation
Description The call was conferenced and the added device can actively participate in the call.
Associated Features Single Step Conference Call, Intrude Call, Join Call
This feature is typically used to allow intrusion by a supervisor with the ability to speak and listen into an agent call. Conference
The call was conferenced because of a two step conference.
Conference Call, Conference
Join Call
The call was conferenced because of a Join Call.
Join Call
Network Signal
The call was involved in a conference located outside of the switching sub-domain.
External Call
Normal
The call was conferenced (a more specific event cause cannot be provided).
Conference
Override
The call was conferenced because of an override (e.g., Intrude Call) feature. This event cause may be used when the participation type (active, silent) cannot be provided.
Intrude Call
Silent Participation
The call was conferenced and the added device can silently participate in the call.
Single Step Conference Call, Intrude Call, Join Call
This feature 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 originating party. The feature, sometimes called Silent Intrusion, may provide a tone to one or both parties to indicate that the joining party is listening to the call. Single Step Conference
The call was conferenced because of a single step conference.
Single Step Conference Call, Intrude Call
17.2.3.3 Functional Requirements 1. The contents of the primaryOldCall and the secondaryOldCall parameters may be either a “fixed view” or a “local view” of the connections at a device before the conference has been completed. The switching function indicates which view it provides via the connectionView parameter in the capability exchange services. •
fixed view - for each conferenced event generated by monitors placed on different devices in a call, the switching function provides the same information in the primaryOldCall and the secondaryOldCall parameters independent of the monitorType (call or device-type monitor) and independent of the role of the device in the conference (conferencingDevice, addedParty, etc.). The meaning of these parameters for the fixed-view are: - 355 -
•
•
primaryOldCall - specifies the first call visible at the conferencingDevice.
•
secondaryOldCall - specifies the second call visible at the conferencingDevice.
local view - for each conferenced event generated by monitors placed on different devices in a call, the switching function provides different information in the primaryOldCall and the secondaryOldCall parameters that depends upon which call was made visible first, from the perspective of the monitored device. The meaning of these parameters for the local-view are: •
primaryOldCall - specifies the first call visible at the monitored device. For example, for a device-type monitor placed on the conferencingDevice (two step conference), this is the first call placed on hold (C1). For a device-type monitor placed on the addedParty device, this is the first (and only) call involved in the conference (C2) from the perspective of the monitored device.
•
secondaryOldCall - specifies the second call visible at the monitored device. For example, for a device-type monitor placed on the conferencingDevice (two step conference), this is the consultation call (C2). For a monitor placed on the addedParty device, there is no secondaryOldCall parameter.
2. The conferenceConnections parameter is a list that contains the new ConnectionID and may contain the old ConnectionID, the DeviceID (values such as ANI, etc.), and for externally located devices the associated Network Interface DeviceID. 3. The computing function should never assume the reuse of callIDs, although some switching functions may reuse one or the other.
- 356 -
17.2.4
Connection Cleared The Connection Cleared event indicates that a single device has disconnected or dropped out of a call. Common situations that generate this event include: •
A user manually terminates the call (by going on-hook, for example).
•
The Clear Connection service is successfully invoked.
•
Connection clears as a result of some other service’s operation. Figure 17-38 Connection Cleared Event BEFORE EVENT
D1
*
C1
AFTER EVENT
*
D2
!
D3
D1
*
C1
D2
*
D3 (releasingDevice)
DEVICES D1 : device in conference with D2 & D3 D2 : device in conference with D1 & D3 D3 : releasingDevice
AFFECTED CONNECTIONS D3C1 : droppedConnection CONNECTION STATES ! : (unspecified) * : (unspecified/unaffected)
CALLS C1 : existing call
17.2.4.1 Event Parameters Table 17-157 Connection Cleared—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
droppedConnection
ConnectionID
M
Specifies the connection of the device that was dropped from the call.
releasingDevice
SubjectDeviceID
M
Specifies the device that dropped from the call.
localConnectionInfo
LocalConnectionState
C
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the clearing device: Null
•
For the other devices left in the call: (unaffected)
This parameter is mandatory for events generated for device-type monitors and otherwise shall not be provided. correlatorData
CorrelatorData
O
Specifies the correlator data associated with the call.
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
chargingInfo
ChargingInfo
O
Specifies a total value of charging or currency units for the device that dropped from the call.
- 357 -
Table 17-157 Connection Cleared—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
droppedConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the droppedConnection connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
deviceHistory
DeviceHistory
O
Specifies the list of devices which were previously associated with the call (e.g. redirecting, transferring, clearing devices).
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information attached to the event.
17.2.4.2 Event Causes Table 17-158 Connection Cleared—Event Causes Event Cause
Description
Associated Features
Alert Time Expired
The connection was cleared because a timer associated with the Make Predictive call expired.
Make Predictive Call
Busy
The connection was cleared because the call reached a busy destination.
Connection Failure
Busy Overflow
The connection was cleared because all possible destinations for the call are busy or unavailable and there is no queueing mechanism (ACD, for example) available.
Clear Connection, Clear Call, Connection Failure
Calendar Overflow
The connection was cleared because all possible calendar based destinations for the call are unavailable due to the time of the day or the day of the week.
Clear Connection, Clear Call, Connection Failure
Call Back
The connection was cleared after a Call Back or a Call Back Message feature has been invoked.
Call Back Call-Related, Call Back Message Call-Related
- 358 -
Table 17-158 Connection Cleared—Event Causes (continued) Event Cause
Description
Associated Features
Call Cancelled
The connection was cleared without a device going on-hook (via the Clear Call service, for example).
Clear Connection, Clear Call, Connection Failure
Call Not Answered
The connection was cleared because the call was not answered before a timer elapsed.
Clear Connection, Clear Call, Connection Failure
Capacity Overflow
The connection was cleared because all possible destinations are busy or unavailable and the call cannot be queued because the system is already at capacity.
Clear Connection, Clear Call, Connection Failure
Destination Detected
The connection was cleared because the call encountered a specific destination.
Make Predictive Call
Destination Not Obtainable
The connection was cleared because the call could not reach the destination.
Connection Failure
Destination Out of Order
The connection was cleared because the call encountered a destination that is out of service.
Connection Failure
Do Not Disturb
The connection was cleared because the call encountered a destination that has the Do Not Disturb feature set.
Do Not Disturb
Incompatible Destination
The connection was cleared because the call encountered an incompatible destination.
Connection Failure
Invalid Account Code
The connection was cleared because of an invalid account code.
Connection Failure
Invalid Number Format
The connection was cleared because of an incorrect dialled number.
Connection Failure
Maintenance
The connection was cleared because it encountered a facility or endpoint in a maintenance condition.
Connection Failure
Multiple Alerting
The connection was cleared and the call is alerting at least one other device.
Multiple Alerting
Network Congestion
The connection was cleared because the call reached a congested network.
External Call
Network Not Obtainable
The connection was cleared because the call could not reach the destination network.
External Call
Network Out of Order
The connection was cleared because the call encountered a network that is out of order.
Connection Failure
Network Signal
The device located outside the switching subdomain has dropped from the call.
Clear Connection, Clear Call, Connection Failure, External Call
Normal Clearing
The connection was cleared (a more specific event cause cannot be provided).
Clear Connection, Clear Call, Any feature
Not Available Bearer Service
The connection was cleared because the call was requested with a bearer capability that is currently not available.
Connection Failure
Not Supported Bearer Service
The connection was cleared because the call was requested with a bearer capability that is currently not supported.
Connection Failure
Number Changed
The connection was cleared because the called number has been changed to a new number and the call cannot be completed.
Connection Failure
Number Unallocated
The connection was cleared because the called number is not allocated to a subscriber.
Connection Failure
- 359 -
Table 17-158 Connection Cleared—Event Causes (concluded) Event Cause
Description
Associated Features
Override
The connection was cleared because of an override (e.g., Intrude Call) feature.
Connection Failure
Queue Cleared
A call is queued in multiple ACD queues and the connection associated with one of the ACD queues was cleared because the call was distributed to an available agent from another ACD queue.
ACD
Path Replacement
The connection was cleared due to optimization of network (NID) resources.
Network feature
Queue Time Overflow
The connection was cleared because all possible destinations for the call are busy or unavailable and the estimated holding time before the call can be answered is too long.
Clear Connection, Clear Call, Connection Failure
Reorder Tone
The connection was cleared because the call encountered a reorder condition.
Connection Failure
When this occurs, the network usually provides Reorder Tone to indicate that a request (call, feature, or supplementary service) was not recognizable. This condition typically results when a user dials a number that is not valid or attempts to obtain a service that is not enabled for that user or device. Resource Not Available
The connection was cleared because of resources not available.
Connection Failure
Selected Trunk Busy
The connection was cleared because the specific selected Network Interface Device (e.g., trunk, CO Line) is busy.
Connection Failure
Trunks Busy
The connection was cleared because there was no available Network Interface Device (e.g., trunk, CO Line).
Connection Failure
Unauthorized Bearer Service
The connection was cleared because the call was requested with an unauthorized bearer capability.
Connection Failure
Unknown Overflow
The connection was cleared because an overflow condition exists but the specific overflow reason is not known.
Clear Connection, Clear Call, Connection Failure
17.2.4.3 Functional Requirements 1. A Connection Cleared event will be generated for appearances of a shared bridged device configuration under the following conditions. •
The call is ended.
•
The appearance permanently drops from the call through some feature/service.
•
The call moves away from the device configuration and none of the appearances are connected into the call.
•
The call moves away from the device configuration and the device configuration is an appearance interdependent shared bridged device configuration.
The event cause will be Normal Clearing, the droppedConnection will be the connection identifier associated with the appearance and the releasingDevice will depend on the type of referencing model that is supported by the switching function (refer to 6.1.5, “Referencing Devices, Elements, Appearances and Device Configurations”, on page 54).
- 360 -
17.2.5
Delivered The Delivered event indicates that a call is being presented to a device in either the Ringing or Entering Distribution modes of the alerting state. Common situations that generate this event include: •
A call has been assigned to a device and that device is alerting.
•
A call has been assigned to a distribution device such as an ACD, routeing device, or hunt group. Figure 17-39 Delivered Event BEFORE EVENT
a, h n, q, f
D1
C1
AFTER EVENT
D2
*
D1 (alertingDevice)
DEVICES D1 : alertingDevice D2 : callingDevice*
a
C1
*
D2 (callingDevice)
AFFECTED CONNECTIONS D1C1 : connection CONNECTION STATES a : alerting state h : hold state n : null state q : queued state f : failed state * : (unspecified/unaffected)
CALLS C1 : call that has been delivered to D1
*There are some situations where D1 can be the calling device (e.g. Make Predictive Call). 17.2.5.1 Event Parameters Table 17-159 Delivered—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
Specifies the connection that is alerting.
alertingDevice
SubjectDeviceID
M
Specifies the device that is alerting.
callingDevice
CallingDeviceID
M
Specifies the calling device.
calledDevice
CalledDeviceID
M
Specifies the originally called device.
lastRedirectionDevice
RedirectionDeviceID
M
Specifies the previously known redirected from device.
originatingNIDConnection
ConnectionID
O
Specifies the connection of the Network Interface Device (NID) that the call originated from. If this parameter is supported, it shall be provided if there is an originating NID associated with the call, otherwise it shall not be provided. See Functional Requirement #4.
localConnectionInfo
LocalConnectionState
C
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the alerting device: Alerting
•
For the calling device: (unaffected)
This parameter is mandatory for events generated for device-type monitors and otherwise shall not be provided.
- 361 -
Table 17-159 Delivered—Event Parameters (continued) Parameter Name
Type
M/ O/C
Description
correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call and shall otherwise not be provided.
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
networkCallingDevice
NetworkCallingDeviceID
O
Specifies the original calling device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
networkCalledDevice
NetworkCalledDeviceID
O
Specifies the original called device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
associatedCallingDevice
AssociatedCallingDeviceID
C
Specifies the Network Interface Device associated with the calling device if the call is an external incoming call. This parameter is mandatory for all external incoming calls and shall not be provided otherwise.
associatedCalledDevice
AssociatedCalledDeviceID
C
For outgoing external calls, this parameter specifies the Network Interface Device associated with the called device. For incoming external calls, this parameter specifies a device within the switching sub-domain associated with the originally called device. This parameter is mandatory for all external outgoing calls and it is optional for external incoming calls.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
connectionInfo
ConnectionInformation
O
Specifies the connection information associated with the alerting connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call. This could represent the subject header of an Email (text call) or intent for a voice call, for example.
messageInfo
MessageInfo
O
Specifies the contents of message information associated with a call. The message information consists of one of more items.
- 362 -
Table 17-159 Delivered—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
deviceHistory
DeviceHistory
O
Specifies the list of devices which were previously associated with the call (e.g. redirecting, transferring, clearing devices).
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information attached to the event.
17.2.5.2 Event Causes Table 17-160 Delivered—Event Causes Event Cause
Description
Associated Features
ACD Busy
The call was delivered to an ACD device that has currently no available agents.
ACD, Consultation Call
ACD Forward
The call was delivered to a new device and is no longer queued at the previous ACD device.
ACD
ACD Saturated
The call was delivered to an ACD device that has currently no internal resources available (including agents).
ACD, Consultation Call
Call Back
The call was delivered to a device because of a previously set call back feature.
Call Back Call-Related
Call Forward
The call was delivered to a device after it was forwarded (any type of forwarding).
Call Forwarding
Call Forward—Busy
The call was delivered to a device after it was forwarded because of a busy condition.
Call Forwarding
Call Forward— Immediate
The call was delivered to a device after it was forwarded (forwarding on all conditions).
Call Forwarding
Call Forward—No Answer
The call was delivered to a device after it was forwarded because of a no answer condition.
Call Forwarding
Call Interception
The call was delivered to a device as part of the call interception (any type of call interception).
Call Interception
Call Interception - Busy
The call was delivered to a device as part of the call interception due to a busy condition at the intended device.
Call Interception
Call Interception Forwarded
The call was delivered to a device as part of the call interception due to a forwarding condition at the intended destination.
Call Interception
Call Interception - No Answer
The call was delivered to a device as part of the call interception due to a no answer condition or timeout at the intended device.
Call Interception
Call Interception Resources Not Available
The call was delivered to a device as part of the call interception due to unavailable resources at the intended device.
Call Interception
Conference
The call that was delivered to a device involves a conference resource or is intended to be part of a conference.
Any conference feature
- 363 -
Table 17-160 Delivered—Event Causes (continued) Event Cause
Description
Associated Features
Distributed
The call was delivered to a device because the call has moved from the distribution mechanism (ACD, Hunt) to an available device associated with the distribution mechanism.
ACD, Routeing Services
Entering Distribution
The call was delivered to a distribution mechanism (ACD, Hunt) for the purpose of being distributed.
ACD, Routeing Services
Key Operation
The call was delivered to a device that has an appearance in a call appearance, bridged, or hybrid device configuration.
Multiple Appearance
Multiple Alerting
The call that is alerting the subject device is also alerting other devices.
Multiple Alerting
Lawful Interception
The call was intercepted after a legally sanctioned official request.
Call Interception
Network Signal
The call was delivered to a device that is outside of the switching sub-domain.
External Calls
New Call
The call was not redirected.
Any feature
No Available Agents
The call was delivered to a device because there were no available devices in a group (ACD).
ACD, Forwarding
Normal
The call was delivered to a device (a more specific cause cannot be provided).
Any feature
Overflow
The call was delivered to a device after it overflowed a queue, group, or target.
ACD
Override
The call was delivered to a device as a result of an override (e.g., Intrude Call) feature.
Intrude Call
Recall
The call was delivered to a device as part of the recall feature (any type of recall).
Recall
Recall - Busy
The call was delivered to a device as part of the recall feature due to a busy condition at the intended device.
Recall
Recall - No Answer
The call was delivered to a device as part of the recall feature due to a no answer condition or timeout at the intended device.
Recall
Recall - Forwarded
The call was delivered to a device as part of the recall feature due to a forwarding condition at the intended destination.
Recall
Recall - Resources Not Available
The call was delivered to a device as part of the recall feature due to unavailable resources at the intended device.
Recall
Redirected
The call was delivered to a device after it was diverted from or deflected to this device.
Deflect Call
Remains in Queue
The call was delivered to a device while the calling device’s position in the queue is retained. For example, the call could be delivered to a VRU or other automated answering equipment while the calling device retains its position in the ACD queue.
ACD, Queuing, Single Step Conference, Join Call
Resources not available
The call was delivered because some resources were not available (ACD, forwarding).
ACD, Forwarding
Single Step Transfer
The call alerted the device due to a Single Step Transfer service.
Single Step Transfer
Single Step Conference
The call alerted the device due to a Single Step Conference service.
Single Step Conference
- 364 -
Table 17-160 Delivered—Event Causes (concluded) Event Cause Timeout
Description The event was generated because a trunk timer expired. It is not generated as the result of a particular network event or condition.
Associated Features External calls
17.2.5.3 Functional Requirements 1. The Delivered event should not be used to determine when a device is physically ringing. (The Ringer Status event should be used for this.) 2. When a call is delivered to a bridged device configuration, multiple Delivered events are sent (one for each appearance of the device configuration). Each event will contain the following type of information: •
The event for the appearance which is delivered the call first will have the appropriate event cause on why the call is being delivered to the device configuration. All subsequent events for the other appearances will have an event cause of Key Operation.
•
The connection parameter will be the connection identifier of the specific appearance.
•
The alertingDevice will depend on the type of referencing model that is supported by the switching function (refer to 6.1.5, “Referencing Devices, Elements, Appearances and Device Configurations”, on page 54).
•
The calledDevice or associatedCalledDevice will contain the device identifier associated with the logical element of the device.
3. When observing a call or a device in a call, and the call diverts from a device in the call, if the switching function does not provide the Diverted event for all devices in a call or for call-type monitors (as indicated through the capabilities exchange services option), the computing function shall use the alertingDevice, calledDevice, lastRedirectionDevice, and cause parameters to properly track the progress of the call as the result of the redirection. See 6.7.6, “Tracking a Diverted Call”, on page 75 for more information. 4. If there is more than one calling device (i.e. a conference calling back to a device), then the originatingNIDConnection parameter will not be present. 5. For external incoming calls, the contents of the networkCallingDeviceID and the networkCalledDeviceID parameters shall not change as long as the associatedCallingDevice remains in the call. This differs from the callingDeviceID and the calledDeviceID parameters in that these parameters may change as a result of features such as transfer, forwarding, and conferencing, etc.
- 365 -
17.2.6
Digits Dialled The Digits Dialled event indicates that a call or feature is being attempted from a device and that a portion of the dialling sequence has been completed. It implies that only part of the input activity is complete, and that more of the dialling sequence needs to be supplied before the entire input activity is complete. After the entire dialling sequence is complete, the Originated event will be generated in the case where a call is being attempted. The last Digits Dialled event received prior to receiving the Originated event will report the last digits dialled to complete the dialling sequence. Figure 17-40 Digits Dialled Event BEFORE EVENT
i
D1
AFTER EVENT
D1
D2
c*, n
C1
(diallingDevice)
i
C1
*
DEVICES D1 : diallingDevice
AFFECTED CONNECTIONS D1C1 : diallingConnection
CALLS C1 : existing call
CONNECTION STATES i : initiated state c : connected state n : null state * : (unspecified/unaffected)
D2
Note that the *connected state when D2 is a NID. 17.2.6.1 Event Parameters Table 17-161 Digits Dialled—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
diallingConnection
ConnectionID
M
Specifies the connection at which the digits were dialled.
diallingDevice
SubjectDeviceID
M
Specifies the device at which the digits were dialled.
diallingSequence
DeviceID
M
Specifies the sequence of digits that was dialled.
localConnectionInfo
LocalConnectionState
C
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the device dialling the digits: Initiated.
This parameter is mandatory for events generated for device-type monitors and otherwise shall not be provided. correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call and shall otherwise not be provided.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
- 366 -
Table 17-161 Digits Dialled—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
networkCallingDevice
NetworkCallingDeviceID
O
Specifies the original calling device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
networkCalledDevice
NetworkCalledDeviceID
O
Specifies the original called device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
associatedCallingDevice
AssociatedCallingDeviceID
C
Specifies the Network Interface Device associated with the calling device if the call is an external incoming call. This parameter is mandatory for all external incoming calls and shall not be provided otherwise.
associatedCalledDevice
AssociatedCalledDeviceID
C
For outgoing external calls, this parameter specifies the Network Interface Device associated with the called device. For incoming external calls, this parameter specifies a device within the switching sub-domain associated with the originally called device. This parameter is mandatory for all external outgoing calls and it is optional for external incoming calls.
diallingConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the diallingConnection connection. If this parameter is not present, then the connection information is switching function specific.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching if the switching function supports the call linkage feature otherwise it shall not be provided.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.2.6.2 Event Causes Table 17-162 Digits Dialled—Event Causes Event Cause
Description
Conference
Digits were dialled as part of a consultation for the purpose of a conference.
Associated Features Consultation Call with consultOptions of ConferenceOnly
Consultation
Digits were dialled as part of a consultation.
Consultation Call
Network Dialling
Digits were dialled after a call has left the switching sub-domain.
External Calls
Normal
Digits were dialled (a more specific event cause cannot be provided).
Any feature, Dial Digits, Make Call
Transfer
Digits were dialled as part of a consultation for the purpose of a transfer.
Consultation Call with consultOptions of TransferOnly
- 367 -
17.2.6.3 Functional Requirements 1. This event will only be generated when the computing function has a device-type or call-type monitoring applied to a device that is initiating a call. 2. The grouping and number of digits reported in each event is switching function dependent. 3. The first Digits Dialled event includes the first digit specified in the Make Call or Consultation Call service which started the dialling sequence. If no digits were specified in the initiating Make Call or Consultation Call service (in the case where a null string was passed in the service request), the diallingSequence parameter in the Digits Dialled event contains a null string. 4. The digit sequence reported by the sequence of Digits Dialled events reflects the digits actually dialled through manual interaction or by CSTA service requests. It will not reflect any filtering or manipulation of the digit sequence by the switching function 5. If a Network Reached event is received prior to the receipt of an originated event, it may not be possible to determine the complete dialling sequence. 6. The switching function may have a timeout period for multi-stage dialling. If the dialling sequence does not complete prior to this timeout, it may either abort the call or attempt to use the digits already dialled and signal that dialling is complete with an originated event.
- 368 -
17.2.7
Diverted The Diverted event indicates that a call has been diverted from a device and that the call is no longer present at the device. Common situations that generate this event include: •
A call leaves a device that has some type of forwarding feature activated. Examples are Ring No Answer, Forward Immediate (depends upon the forwarding feature model supported by the switching function. See 6.7.1, “Forwarding”, on page 69), Recall, etc.
•
A call leaves an ACD/Split/Hunt group device to be redirected to an agent, an extension, another ACD/Split/Hunt Group device, or to an offsite destination.
•
A call leaves an ACD queue and is redirected to either an agent or an extension.
•
A divert (Deflect, Pick, etc.) is successfully invoked. Figure 17-41 Diverted Event BEFORE EVENT
a, c, h, q, n
D1
C1
AFTER EVENT
D2
*
D1
D3
D3
C1
(divertingDevice)
(newDestination)
DEVICES D1 : divertingDevice D2 : callingDevice* D3 : newDestination
D2 *
(callingDevice)
a, c f, n, q
AFFECTED CONNECTIONS D1C1 : connection D3C1 : newDestination connection CONNECTION STATES a : alerting state c : connected state f : fail state h : hold state n : null state q : queued state * : (unspecified/unaffected)
CALLS C1 : existing call
*There are some situations where D1 can also be the Calling Device (e.g. Make Predictive Call). 17.2.7.1 Event Parameters Table 17-163 Diverted—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
Specifies the connection that was diverted.
divertingDevice
SubjectDeviceID
M
Specifies the device from which the call was diverted.
newDestination
SubjectDeviceID
M
Specifies the device to which the call was diverted.
- 369 -
Table 17-163 Diverted—Event Parameters (continued) Parameter Name callingDevice
Type
M/ O/C
CallingDeviceID
C
Description Specifies a device remaining in the call with the newDestination device. This parameter shall be provided in the case of Immediate Forwarding, where forwarding is triggered after the call is delivered to a device (see Function Requirement #3). Otherwise the parameter is optional.
calledDevice
CalledDeviceID
C
Specifies the originally called device. This parameter shall be provided in the case of Immediate Forwarding, where forwarding is triggered after the call is delivered to a device (see Function Requirement #3). Otherwise the parameter is optional.
lastRedirectionDevice
RedirectionDeviceID
M
Specifies the previously known redirected from device. Note that this is not the divertingDevice that caused this event, but the device that performed a redirection towards the current divertingDevice just before the current redirection.
localConnectionInfo
LocalConnectionState
C
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the diverting device: Null
•
For the other devices left in the call: (unaffected)
This parameter is mandatory for events generated for device-type monitors and otherwise shall not be provided. correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call and shall otherwise not be provided.
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
connectionInfo
ConnectionInformation
O
Specifies the connection information associated with the connection. If this parameter is not present, then the connection information is switching function specific.
- 370 -
Table 17-163 Diverted—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
networkCallingDevice
NetworkCallingDeviceID
O
Specifies the original calling device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
networkCalledDevice
NetworkCalledDeviceID
O
Specifies the original called device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
associatedCallingDevice
AssociatedCallingDeviceID
C
Specifies the Network Interface Device associated with the calling device if the call is an external incoming call. This parameter is mandatory for all external incoming calls and shall not be provided otherwise.
associatedCalledDevice
AssociatedCalledDeviceID
C
For outgoing external calls, this parameter specifies the Network Interface Device associated with the called device. For incoming external calls, this parameter specifies a device within the switching sub-domain associated with the originally called device. This parameter is mandatory for all external outgoing calls and it is optional for external incoming calls.
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call. This could represent the subject header of an Email (text call) or intent for a voice call, for example.
messageInfo
MessageInfo
O
Specifies the contents of message information associated with a call. The message information consists of one of more items.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
deviceHistory
DeviceHistory
O
Specifies the list of devices which were previously associated with the call (e.g. redirecting, transferring, clearing devices).
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information attached to the event.
17.2.7.2 Event Causes Table 17-164 Diverted—Event Causes Event Cause
Description
Associated Features
ACD Forward
The call was diverted from one ACD device to a new ACD device and is no longer queued at the previous ACD device.
ACD
Busy Overflow
The call was diverted because all possible destinations for the call are busy or unavailable and there is no queueing mechanism (ACD, for example) available.
Call Forwarding
- 371 -
Table 17-164 Diverted—Event Causes (continued) Event Cause
Description
Associated Features
Calendar Overflow
The call was diverted because all possible calendar based destinations for the call are unavailable due to the time of the day or the day of the week.
Call Forwarding
Call Forward
The call was diverted from a device after it was forwarded from another device (any type of forwarding).
Call Forwarding
Call Forward—Busy
The call was diverted from a device after it was forwarded (forwarding on a busy condition).
Call Forwarding
Call Forward— Immediate
The call was diverted from a device after it was forwarded (forwarding on all conditions).
Call Forwarding
Call Forward—No Answer
The call was diverted from a device after it was forwarded because of a no answer condition.
Call Forwarding
Call Not Answered
The call was diverted from a device because it was not answered before a timer elapsed.
Recall
Call Pickup
The call was diverted from a device because of the pickup feature.
Directed Pickup Call, Group Pickup Call
Capacity Overflow
The call was diverted because all possible destinations are busy or unavailable and the call cannot be queued because the system is already at capacity.
Call Forwarding
Distributed
The call was diverted from a device because it was distributed by a distribution group (ACD or Hunt group).
ACD
Do Not Disturb
The call was diverted from a device because the device had the Do Not Disturb feature set.
Call Forwarding
No Available Agents
The call was diverted from a device because there were no available devices in a group (ACD).
ACD
Normal
The call was diverted from a device (a more specific cause cannot be provided).
Any feature
Overflow
The call was diverted from a device after it overflowed a queue, group, or target.
ACD
Park
The park feature has been invoked to either park or un-park a call at a device.
Park Call
Path Replacement
The call was diverted due to optimization of network (NID) resources.
Network feature
Queue Time Overflow
The call was diverted because all possible destinations for the call are busy or unavailable and the estimated holding time before the call can be answered is too long.
Call Forwarding
Recall
The call was diverted from a device as part of a recall feature (any type of recall).
Recall
Recall - Busy
The call was diverted from a device as part of the recall feature due to a busy condition at the intended device.
Recall
Recall - No Answer
The call was diverted from a device as part of the recall feature due to a no answer condition at the intended device.
Recall
Recall - Forwarded
The call was diverted from a device as part of the recall feature due to a forwarding condition at the intended destination.
Recall
- 372 -
Table 17-164 Diverted—Event Causes (concluded) Event Cause
Description
Associated Features
Recall - Resources Not Available
The call was diverted from a device as part of the recall feature due to unavailable resources at the intended device.
Recall
Redirected
The call was diverted from a device because of a deflect or divert feature.
Deflect Call
Resources Not Available
The call was diverted from a device because there were no resources available to process it.
ACD
Unknown Overflow
The call was diverted because an overflow condition exists but the specific overflow reason is not known.
Call Forwarding
17.2.7.3 Functional Requirements 1. Based upon the switching function (as indicated through the capabilities exchange services), the switching function may send the Diverted event to either: •
Only the divertingDevice (D1) for device-type monitors, and not for call-type monitors, or
•
To all devices in a call (device-type monitors) and for call-type monitors.
2. When observing a call or a device in a call, and the call previously diverts from a device in the call, if the switching function does not provide the Diverted event for all devices in a call or for call-type monitors (as indicated through the capabilities exchange services option), the computing function shall use the divertingDevice, calledDevice, lastRedirectionDevice, and cause parameters to properly track the progress of the call as a result of the previous redirection. See 6.7.6, “Tracking a Diverted Call”, on page 75 for more information. 3. In the case of Immediate Forwarding, where forwarding is triggered after the call is delivered to a device (as indicated by the capability exchange services), the Diverted event for the Diverting device shall contain a cause of Immediate Forwarding and a localConnectionInfo of Null. When this Diverted event is the first and last event generated for the call at the Diverting device, it is an example of a Null to Null connection state transition. 4. For external incoming calls, the contents of the networkCallingDeviceID and the networkCalledDeviceID parameters shall not change as long as the associatedCallingDevice remains in the call. This differs from the callingDeviceID and the calledDeviceID parameters in that these parameters may change as a result of features such as transfer, forwarding, and conferencing, etc.
- 373 -
17.2.8
Established The Established event indicates that a call has been answered at a device or that a call has been connected to a device. Common situations that generate this event include: •
A call has been answered at a device (e.g., a user has manually gone off-hook).
•
The Answer Call service has been successfully invoked.
•
A call has been picked by another device. Figure 17-42 Established Event BEFORE EVENT
a, f, n, q
D1
AFTER EVENT
*
C1
D1
D2
(answeringDevice)
DEVICES D1 : answeringDevice D2 : callingDevice*
c
C1
*
D2 (callingDevice)
AFFECTED CONNECTIONS D1C1 : establishedConnection CONNECTION STATES a : alerting state q : queued state f : fail state n : null state c : connected state * : (unspecified/unaffected)
CALLS C1 : existing call
*There may be some situations where D1 can be the calling device (e.g. Make Predictive Call). 17.2.8.1 Event Parameters Table 17-165 Established—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
establishedConnection
ConnectionID
M
Specifies the connection that was connected.
answeringDevice
SubjectDeviceID
M
Specifies the device that connected into the call.
callingDevice
CallingDeviceID
M
Specifies the calling device.
calledDevice
CalledDeviceID
M
Specifies the originally called device.
lastRedirectionDevice
RedirectionDeviceID
M
Specifies the previously known redirected from device.
originatingNIDConnection
ConnectionID
O
Specifies the connection of the Network Interface Device (NID) that the call originated from. If this parameter is supported, it shall be provided if there is an originating NID associated with the call, otherwise it shall not be provided. See Functional Requirement #4.
- 374 -
Table 17-165 Established—Event Parameters (continued) Parameter Name localConnectionInfo
Type LocalConnectionState
M/ O/C C
Description Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the answering device: Connected
•
For the calling device: (unaffected - never Null)
This parameter is mandatory for events generated for device-type monitors and otherwise shall not be provided. correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call and shall otherwise not be provided.
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
networkCallingDevice
NetworkCallingDeviceID
O
Specifies the original calling device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
networkCalledDevice
NetworkCalledDeviceID
O
Specifies the original called device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
associatedCallingDevice
AssociatedCallingDeviceID
C
Specifies the Network Interface Device associated with the calling device if the call is an external incoming call. This parameter is mandatory for all external incoming calls and shall not be provided otherwise.
associatedCalledDevice
AssociatedCalledDeviceID
C
For outgoing external calls, this parameter specifies the Network Interface Device associated with the called device. For incoming external calls, this parameter specifies a device within the switching sub-domain associated with the originally called device. This parameter is mandatory for all external outgoing calls and it is optional for external incoming calls.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
establishedConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the establishedConnection connection. If this parameter is not present, then the connection information is switching function specific.
- 375 -
Table 17-165 Established—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call. This could represent the subject header of an Email (text call) or intent of a voice call, for example.
messageInfo
MessageInfo
O
Specifies the contents of message information associated with a call. The message information consists of one of more items.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
deviceHistory
DeviceHistory
O
Specifies the list of devices which were previously associated with the call (e.g. redirecting, transferring, clearing devices).
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information attached to the event.
17.2.8.2 Event Causes Table 17-166 Established—Event Causes Event Cause
Description
Associated Features
ACD Forward
The call was established at a device (immediately, before being delivered) and is no longer queued at the previous ACD device.
ACD
Alternate
The call was reestablished or answered at a device due to the alternate feature.
Alternate Call
Call Back
The call was established at a device (immediately, before being delivered) because of a previously set call back feature.
Call Back Call-Related
Call Forward
The call was established at a device (immediately, before being delivered) after it was forwarded (any type of forwarding).
Call Forwarding
Call Forward—Busy
The call was established at a device (immediately, before being delivered) after it was forwarded because of a busy condition.
Call Forwarding
Call Forward— Immediate
The call was established at a device (immediately, before being delivered) after it was forwarded (forwarding on all conditions).
Call Forwarding
Call Forward—No Answer
The call was established at a device (immediately, before being delivered) after it was forwarded because of a no answer condition.
Call Forwarding
Call Pickup
The call was established at a device via a pickup feature.
Directed Pickup Call, Group Pickup Call
Call Interception
The call was established to a device as part of the call interception (any type of call interception).
Call Interception
- 376 -
Table 17-166 Established—Event Causes (continued) Event Cause
Description
Associated Features
Call Interception - Busy
The call was established to a device as part of the call interception due to a busy condition at the intended device.
Call Interception
Call Interception Forwarded
The call was established to a device as part of the call interception due to a forwarding condition at the intended destination.
Call Interception
Call Interception - No Answer
The call was established to a device as part of the call interception due to a no answer condition or timeout at the intended device.
Call Interception
Call Interception Resources Not Available
The call was established to a device as part of the call interception due to unavailable resources at the intended device.
Call Interception
Conference
The call that was established at a device involves a conference resource or is intended to be part of a conference.
Any conference feature
Distributed
The call was distributed, (and was established immediately, before being delivered) to a device because the call has moved from the distribution mechanism (ACD, Hunt) to an available device associated with the distribution mechanism
ACD, Routeing Services
Intrude
The call was established at a device because the Intrude Call service was executed successfully.
Intrude Call
Key Operation
The call was established at a device that has an appearance in a call appearance, bridged, or hybrid device configuration.
Multiple Appearance
Network Signal
The call was established at a device that is outside of the switching sub-domain.
External Calls
Lawful Interception
The call was intercepted after a legally sanctioned official request.
Call Interception
New Call
The call was not redirected.
Any Feature
No Available Agents
The call was established immediately, before being delivered, at a device because there were no available devices in a group (ACD)
ACD, Forwarding
Normal
The call was established at a device (a more specific cause cannot be provided).
Any feature
Overflow
The call was established at a device (immediately, before being delivered) after it overflowed a queue, group, or target.
ACD
Override
The call was established at a device as a result of an override (e.g., Single Step Conference Call, Intrude Call) feature.
Intrude Call
Recall
The call was established at a device as part of the recall feature (e.g., any type of recall) the call was established immediately (e.g. auto answer), before being delivered.
Recall
Recall - Busy
The call was established at a device as part of the recall feature due to a busy condition at the intended device. The call was established immediately (e.g. auto answer), before being delivered.
Recall
- 377 -
Table 17-166 Established—Event Causes (concluded) Event Cause
Description
Associated Features
Recall - No Answer
The call was established at a device as part of the recall feature due to a no answer condition or timeout at the intended device. The call was established immediately (e.g. auto answer), before being delivered.
Recall
Recall - Forwarded
The call was established at a device as part of the recall feature due to a forwarding condition at the intended destination. The call was established immediately (e.g. auto answer), before being delivered.
Recall
Recall - Resources Not Available
The call was established at a device as part of the recall feature due to unavailable resources at the intended device. The call was established immediately (e.g. auto answer), before being delivered.
Recall
Redirected
The call was established at a device after it was previously diverted from or deflected to this device the call was established immediately, before being delivered.
Deflect Call
Remains in Queue
The call was established at a device and the calling device’s position in the ACD queue is retained and the call will be routed to an agent when one becomes available. For example, the call could be established at a VRU or other automated answering equipment while the calling device retains its position in the ACD queue.
ACD
Resources Not Available
The call was established at a device (immediately, before being delivered) because some resources were not available (ACD, forwarding).
ACD, Forwarding
Single Step Conference
The call was established at a device (immediately, before being delivered) due to the Single Step Conference feature.
Single Step Conference
Single Step Transfer
The call was established at a device (immediately, before being delivered) due to the Single Step Transfer feature.
Single Step Transfer
Timeout
The event was generated because a trunk timer expired. It is not generated as the result of a network event or condition.
External Call
17.2.8.3 Functional Requirements 1. A computing function will not see an Established event after a Service Initiated event (e.g. because of Make Call with prompting) indicating that the calling device is connected in the call. Instead, the computing function will see an Originated event indicating connection into the call. 2. When an appearance from a bridged device configuration connects into a call, an Established event is sent. The event will contain the following type of information: •
The event cause will be Normal.
•
The establishedConnection will be the connection identifier of the specific appearance.
•
The answeringDevice will depend on the type of referencing model that is supported by the switching function (refer to 6.1.5, “Referencing Devices, Elements, Appearances and Device Configurations”, on page 54).
- 378 -
•
The calledDevice or associatedCalledDevice will contain the device identifier associated with the logical element of the device.
3. When observing a call or a device in a call, and the call diverts from a device in the call, if the switching function does not provide the Diverted event for all devices in a call or for call-type monitors (as indicated through the capabilities exchange services option), the computing function shall use the answeringDevice, calledDevice, lastRedirectionDevice, and cause (eventCause parameter type) parameters to properly track the progress of the call as a result of the redirection. See 6.7.6, “Tracking a Diverted Call”, on page 75 for more information. 4. If there is more than one calling device (i.e. a conference calling back to a device), then the originatingNIDConnection parameter will not be present. 5. For external incoming calls, the contents of the networkCallingDeviceID and the networkCalledDeviceID parameters shall not change as long as the associatedCallingDevice remains in the call. This differs from the callingDeviceID and the calledDeviceID parameters in that these parameters may change as a result of features such as transfer, forwarding, and conferencing, etc.
- 379 -
17.2.9
Failed The Failed event indicates that a call cannot be completed or a connection has entered the Fail state for any of the reasons described in the Event Causes table on page 382. Figure 17-43 Failed Event BEFORE EVENT
*
D1
AFTER EVENT
a c, h, i, n, q
C1
D1 (callingDevice)
D2
*
C1
f
D2 (failingDevice)
f
DEVICES D1 : callingDevice D2 : failingDevice*
AFFECTED CONNECTIONS D2C1 : failedConnection complete connection ID not provided
CALLS C1 : existing call
CONNECTION STATES a : alerting state c : connected state f : fail state h : hold state i : initiated state n : null state q : queued * : (unspecified/unaffected)
Refer to 6.7.2, “Connection Failure”, on page 71 for a complete description of partial connection IDs. In some situations D2 can be the calling device. 17.2.9.1 Event Parameters Table 17-167 Failed—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
failedConnection
ConnectionID
M
Specifies the connection that failed. (See Functional Requirement #3 at the end of this section.)
failingDevice
SubjectDeviceID
M
Specifies the device that failed.
callingDevice
CallingDeviceID
M
Specifies the calling device.
calledDevice
CalledDeviceID
M
Specifies the originally called device.
lastRedirectionDevice
RedirectionDeviceID
M
Specifies the previously known redirected-from device.
originatingNIDConnection
ConnectionID
O
Specifies the connection of the Network Interface Device (NID) that the call originated from. If this parameter is supported, it shall be provided if there is an originating NID associated with the call, otherwise it shall not be provided.
localConnectionInfo
LocalConnectionState
C
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the failing device: Fail
•
For the other devices left in the call: (unaffected)
This parameter is mandatory for events generated for device-type monitors and otherwise shall not be provided.
- 380 -
Table 17-167 Failed—Event Parameters (continued) Parameter Name
Type
M/ O/C
Description
correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call and shall otherwise not be provided.
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
networkCallingDevice
NetworkCallingDeviceID
O
Specifies the original calling device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
networkCalledDevice
NetworkCalledDeviceID
O
Specifies the original called device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
associatedCallingDevice
AssociatedCallingDeviceID
C
Specifies the Network Interface Device associated with the otherDevice if the call is an external incoming call. This parameter is mandatory for all external incoming calls and shall not be provided otherwise.
associatedCalledDevice
AssociatedCalledDeviceID
C
For outgoing external calls, this parameter specifies the Network Interface Device associated with the called device. For incoming external calls, this parameter specifies a device within the switching sub-domain associated with the originally called device. This parameter is mandatory for all external outgoing calls and it is optional for external incoming calls.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
failedConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the failedConnection connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call. This could represent the subject header of an Email (text call) or intent for a voice call, for example.
- 381 -
Table 17-167 Failed—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
messageInfo
MessageInfo
O
Specifies the contents of message information associated with a call. The message information consists of one of more items.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
deviceHistory
DeviceHistory
O
Specifies the list of devices which were previously associated with the call (e.g. redirecting, transferring, clearing devices).
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.2.9.2 Event Causes Table 17-168 Failed—Event Causes Event Cause
Description
Associated Features
Blocked
The call failed after a device has disconnected from a call leaving one other device remaining in the call.
Connection Failure
Busy
The call failed after it encountered a busy or unavailable device.
Connection Failure
Busy Overflow
The call failed because all possible destinations for the call are busy or unavailable and there is no queueing mechanism (ACD, for example) available.
Connection Failure
Calendar Overflow
The call failed because all possible calendar based destinations for the call are unavailable due to the time of the day or the day of the week.
Connection Failure
Call Cancelled
The call failed before the associated device has gone on-hook.
Connection Failure
Call Not Answered
The call failed because it was not answered before a timer expired.
Connection Failure
Capacity Overflow
The call failed because all possible destinations are busy or unavailable and the call cannot be queued because the system is already at capacity.
Connection Failure
Destination Not Obtainable
The call failed because it could not reach the destination.
Connection Failure
Destination Out of Order
The call failed because it encountered a destination out of service.
Connection Failure
Do Not Disturb
The call failed because it encountered a device that has the do not disturb feature set.
Do Not Disturb, Call Forwarding
Incompatible Destination
The call failed because it encountered an incompatible destination.
Connection Failure
Invalid Account Code
The call failed because of an invalid account code.
Connection Failure
Invalid Number Format
The call failed because the dialled number is incorrect.
Connection Failure
- 382 -
Table 17-168 Failed—Event Causes (continued) Event Cause
Description
Associated Features
Key Operation in Use
The call failed because an appearance is associated with an exclusive bridged device configuration and that the appearance is disabled until the call is terminated or until the call moves away from the device.
Multiple Appearance
Lockout
The call failed because it encountered an inter-digit time-out while dialling.
Connection Failure
Maintenance
The call failed because it encountered a facility or endpoint in a maintenance condition.
Connection Failure
Network Congestion
The call failed because it encountered a congested network.
Connection Failure
In some circumstances, this event cause indicates that the user is listening to a special signal tone from a network. The tone may be accompanied by a voiced statement similar to “All circuits are busy...” Network Not Obtainable
The call failed because it could not reach a destination network.
Connection Failure
Network Out of Order
The call failed because it encountered a network that is out of order.
Connection Failure
Network Signal
The call failed because it encountered a problem after it left the switching sub-domain.
External Calls
Normal
Normal cause for event.
Any feature
Not Available Bearer Service
The call failed because it was requested with a bearer capability that is currently not available.
Connection Failure
Not Supported Bearer Service
The call failed because it was requested with a bearer capability that is currently not supported.
Connection Failure
Number Changed
The call failed because the called number has been changed to a new number and the call cannot be completed.
Connection Failure
Number Unallocated
The call failed because the called number is not allocated to a subscriber.
Connection Failure
Queue Time Overflow
The call failed because all possible destinations for the call are busy or unavailable and the estimated holding time before the call can be answered is too long.
Connection Failure
Reorder Tone
The call failed because it encountered a reorder condition.
Connection Failure
When this occurs, the network usually provides Reorder Tone to indicate that a request (call, feature, or supplementary service) was not recognizable. This condition typically results when a user dials a number that is not valid or attempts to obtain a service that is not enabled for that user or device. Resources Not Available
The call failed because resources were not available.
Connection Failure
Selected Trunk Busy
The call failed because a specific selected Network Interface Device (e.g., trunk, CO line) is busy.
Connection Failure
Trunks Busy
The call failed because there is no available Network Interface Device (e.g., trunk, CO line).
Connection Failure
- 383 -
Table 17-168 Failed—Event Causes (concluded) Event Cause
Description
Associated Features
Unauthorized Bearer Service
The call failed because it was requested with an unauthorized bearer capability.
Connection Failure
Unknown Overflow
The call was failed because an overflow condition exists but the specific overflow reason is not known.
Connection Failure
17.2.9.3 Functional Requirements 1. With an exclusive bridged device configuration, a Failed event is generated for each appearance that does not enter the call. Each event will contain the following type of information: •
The event cause will be Key Operation In Use.
•
The failedConnection will be the connection identifier of the specific appearance.
•
The failingDevice will depend on the type of referencing model that is supported by the switching function (refer to 6.1.5, “Referencing Devices, Elements, Appearances and Device Configurations”, on page 54).
•
The calledDevice or associatedCalledDevice will contain the device identifier associated with the logical element of the device.
2. When observing a call or a device in a call, and the call diverts from a device in the call, if the switching function does not provide the Diverted event for all devices in a call or for call-type monitors (as indicated through the capabilities exchange services option), the computing function shall use the failingDevice, calledDevice, lastRedirectionDevice, and cause (EventCause parameter type) parameters to properly track the progress of the call as a result of the redirection. See 6.7.6, “Tracking a Diverted Call”, on page 75 for more information. 3. The content of the failedConnection parameter, depending on whether or not the Failed event is reported to the failing device’s monitor, will contain one of the following types of connection identifiers (use the capabilities exchange services to determine which approach is supported by a particular switching function): a. A complete connection identifier (i.e., an identifier that contains both a device identifier and call identifier). This indicates that a connection is made with the failing device, and that the Failed event will be reported to all active device-type monitors associated with the call, as well as all calltype monitors associated with the call. b. A call identifier only connection identifier (i.e., an identifier that contains a valid call identifier and no device identifier). This indicates that a connection is not made with the failing device, and that the Failed event will only be reported to the active device and call-type monitors associated with the devices that were in the call prior to the failure (i.e., if a device-type monitor was on the failing device, then the Failed event is not reported). c.
A complete connection identifier (i.e., an identifier that contains both a device identifier and call identifier), not being reported for monitors on the failing device. This indicates that the Failed event will only be reported to the active device and call-type monitors associated with the devices that were in the call prior to the failure (i.e., if a device-type monitor was on the failing device, then the Failed event is not reported).
4. For external incoming calls, the contents of the networkCallingDeviceID and the networkCalledDeviceID parameters shall not change as long as the associatedCallingDevice remains in the call. This differs from the callingDeviceID and the calledDeviceID parameters in that these parameters may change as a result of features such as transfer, forwarding, and conferencing, etc.
- 384 -
17.2.10 Held The Held event indicates that a call has been placed on hold. Common situations that generate this event include: •
Consultation situations (manual and service initiated).
•
Hold situations (manual and service initiated). Figure 17-44 Held Event BEFORE EVENT
c
D1
C1
AFTER EVENT
D2
*
D1 (holdingDevice)
DEVICES D1 : holdingDevice D2 : device being held
h
C1
*
D2 (device being held)
AFFECTED CONNECTIONS D1C1 : heldConnection CONNECTION STATES c : connected state h : hold state * : (unspecified/unaffected)
CALLS C1 : existing call
17.2.10.1 Event Parameters Table 17-169 Held—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
heldConnection
ConnectionID
M
Specifies the connection at which the hold was activated.
holdingDevice
SubjectDeviceID
M
Specifies the device at which hold was activated.
localConnectionInfo
LocalConnectionState
C
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the holding device: Hold
•
For the other devices left in the call: (unaffected)
This parameter is mandatory for events generated for device-type monitors. correlatorData
CorrelatorData
O
Specifies the correlator data associated with the call.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
- 385 -
Table 17-169 Held—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
heldConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the heldConnection connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies on-standardized information.
17.2.10.2 Event Causes Table 17-170 Held —Event Causes Event Cause
Description
Associated Features
Alternate
The call was held at a device as part of an alternate feature.
Alternate Call
Conference
The call was held at a device as a part of a consultation with the intended purpose of establishing a conference.
Consultation Call with a consultOptions of ConferenceOnly
Consultation
The call was held at a device as part of a consultation.
Consultation Call
Intrude
The call was held at a device because the Intrude Call service was executed successfully.
Intrude Call
Maintenance
The call was placed on hold at a device that entered maintenance conditions (e.g. mobile handset out of coverage).
Maintenance
Network Signal
The call was held by a device that is outside of the switching sub-domain.
External Call
Normal
The call was held at a device (a more specific cause cannot be provided).
Any feature
Recall
The call was held at a device due to the activation of the recall feature.
Recall
Suspend
The call was temporarily placed on hold at a device that went onhook.
Call Clearing
Transfer
The call was held at a device as part of a transfer feature.
Consultation Call with a consultOptions of Transfer Only
- 386 -
17.2.11
Network Capabilities Changed The Network Capabilities Changed event indicates that a situation occurred during a call’s progress in a public or private network that modifies its signalling capability (i.e., inter-networking). It does not indicate a change in the connection state of the Network Interface Device (e.g., trunk, CO Line) through which the call has accessed the network. This event shall always be preceded by a Network Reached event that included the networkCapability parameter. The event may be repeated according to the situations encountered in the network. Figure 17-45 Network Capabilities Changed Event
BEFORE EVENT
D1
c, i, h*
C1
AFTER EVENT
c
D1 (calling)
D3
switching sub-domain boundary
c, i, h
C1
D3
c
(networkInterfaceUsed)
switching sub-domain boundary
D2 (calledDevice)
D2
DEVICES D1 : calling device D2 : calledDevice D3 :networkInterfaceUsed
AFFECTED CONNECTIONS D3C1 : outboundConnection CONNECTION STATES c : connected state h : held state i : initiated state
CALLS C1 : existing call
Note that the * held state when an external outgoing call in progress is placed held. 17.2.11.1 Event Parameters Table 17-171 Network Capabilities Changed—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
outboundConnection
ConnectionID
M
Specifies the outbound connection of the network interface device.
networkInterfaceUsed
SubjectDeviceID
M
Specifies the Network Interface Device (e.g., trunk, CO Line) that was selected.
calledDevice
CalledDeviceID
M
Specifies the destination device.
- 387 -
Table 17-171 Network Capabilities Changed—Event Parameters (continued) Parameter Name progressIndicator
Type Structure
M/ O/C
Description
M
Specifies an interworking situation encountered in the public or private network outside the switching subdomain. As a consequence of entering the network, the level of event reporting associated with this call may be reduced. This parameter consists of the following components: 1. progressLocation (M) - It may be one of the following: •
User
•
Private network serving the local user
•
Public network serving the local user
•
Transit network
•
Public network serving the remote user
•
Private network serving the remote user
•
Local interface controlled by the signalling link
•
International Network
•
Network beyond interworking point
•
Other
2. progressDescription (M) - It may be one of the following:
localConnectionInfo
LocalConnectionState
C
•
ISDN Progress Description - This information is derived from ETSI ETS 300 182: 1993.
•
QSIG Progress Description - This information is derived from ECMA-143.
•
Other
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the network interface device: Connected
•
For the other devices left in the call: (Unaffected)
This parameter is mandatory for events generated for device-type monitors. correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call and shall otherwise not be provided.
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
- 388 -
Table 17-171 Network Capabilities Changed—Event Parameters (concluded) Parameter Name
Type
networkCapability
Structure
M/ O/C
Description
O
Specifies the type of network reached and the Call Control events supported by the network. It includes the following components: 1. networkType (M) - The complete set of possible values is: •
ISDN public
•
Non-ISDN public
•
ISDN private
•
Non-ISDN private
•
Other
2. eventsProvided (O) - This is a bitmap of all of the Call Control events defined in this Standard. cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
outboundConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the outboundConnection connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
17.2.11.2 Event Causes Table 17-172 Network Capabilities Changed—Event Causes Event Cause Network Signal
Description The call encountered an interworking situation.
- 389 -
Associated Features External Call
17.2.12 Network Reached The Network Reached event indicates that a call has cut through the switching sub-domain boundary to another network; that is, has reached and engaged a Network Interface Device (e.g., trunk, CO Line). This event indicates that there may be a reduced level of event reporting and possibly no additional device feedback, except connection/call clearing, provided for this device in the call due to a lack of network signalling. The level of signalling provided by the network may be indicated by the networkCapability parameter. Additionally, the computing function should assume that it cannot directly manipulate the far-end device associated with the Network Interface Device. This event is never sent for calls made to devices that are within the switching sub-domain. This event indicates that a connection with a Network Interface Device has reached the connected state, and that further events for that connection refer to the state of the endpoint which the Network Interface Device is associated. A common situation that generates this event includes: •
An outgoing call has cut-through at a network interface device and further call progress information, such as the Delivered and Established events, may not be available. Figure 17-46 Network Reached Event
BEFORE EVENT
D1
c, i
AFTER EVENT
D1 (calling)
D3
C1 switching sub-domain boundary
c, i
D3
c
C1
(networkInterfaceUsed)
switching sub-domain boundary
D2 (calledDevice)
D2
DEVICES D1 : calling device D2 : calledDevice D3 : networkInterfaceUsed
AFFECTED CONNECTIONS D3C1 : outboundConnection CONNECTION STATES c : connected state i : initiated state
CALLS C1 : existing call
17.2.12.1 Event Parameters Table 17-173 Network Reached—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
outboundConnection
ConnectionID
M
Specifies the outbound connection associated with the call that is leaving the switching sub-domain.
networkInterfaceUsed
SubjectDeviceID
M
Specifies the Network Interface Device that was selected.
callingDevice
CallingDeviceID
M
Specifies the calling device.
calledDevice
CalledDeviceID
M
Specifies the originally called device.
lastRedirectionDevice
RedirectionDeviceID
M
Specifies the previously known redirected from device.
- 390 -
Table 17-173 Network Reached—Event Parameters (continued) Parameter Name originatingNIDConnection
Type ConnectionID
M/ O/C O
Description Specifies the connection of the Network Interface Device (NID) that the call originated from. If this parameter is supported, it shall be provided if there is an originating NID associated with the call, otherwise it shall not be provided.
localConnectionInfo
LocalConnectionState
C
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the Network Interface Device: Connected
•
For the other devices left in the call: (unaffected)
This parameter is mandatory for events generated for device-type monitors. correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call and shall otherwise not be provided.
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
networkCapability
Structure
O
Specifies the type of network reached and the Call Control events supported by the network. It includes the following components: 1. networkType (M) - The complete set of possible values is: •
ISDN public
•
Non-ISDN public
•
ISDN private
•
Non-ISDN private
•
Other
2. eventsProvided (O) - This is a bitmap of the Call Control events defined in this Standard. cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
outboundConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the outboundConnection connection. If this parameter is not present, then the connection information is switching function specific.
- 391 -
Table 17-173 Network Reached—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
networkCallingDevice
NetworkCallingDeviceID
O
Specifies the original calling device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls (that, in this case are also outgoing calls).
networkCalledDevice
NetworkCalledDeviceID
O
Specifies the original called device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls (that, in this case are also outgoing calls).
associatedCallingDevice
AssociatedCallingDeviceID
C
Specifies the Network Interface Device associated with the calling device if the call is an external incoming call (that, in this case is also an outgoing). This parameter is mandatory for all external incoming calls and shall not be provided otherwise.
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
deviceHistory
DeviceHistory
O
Specifies the list of devices which were previously associated with the call (e.g. redirecting, transferring, clearing devices).
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information attached to the event.
17.2.12.2 Event Causes Table 17-174 Network Reached—Event Causes Event Cause
Description
Associated Features
ACD Forward
The call left the switching sub-domain because it was forwarded from one ACD device to another ACD device and is no longer present at the previous ACD device.
ACD
Call Forward
The call left the switching sub-domain after it was forwarded (any type of forwarding).
Forwarding
Call Forward—Busy
The call left the switching sub-domain after it was forwarded because of a busy condition.
Forwarding
Call Forward— Immediate
The call left the switching sub-domain after it was forwarded (forwarding on all conditions).
Forwarding
Call Forward—No Answer
The call left the switching sub-domain after it was forwarded because of a no answer condition.
Forwarding
Conference
The call that left the switching sub-domain involves a conference resource or is intended to be part of a conference.
Any conference feature
Distributed
The call left the switching sub-domain after it was distributed by an ACD or hunt group.
ACD
- 392 -
Table 17-174 Network Reached—Event Causes (concluded) Event Cause
Description
Associated Features
No Agents Available
The call left the switching sub-domain after it was diverted from a device because there were no available devices in a group (ACD).
ACD, distribution
Normal
The call left the switching sub-domain (a more specific event cause cannot be provided).
Any feature
Overflow
The call left the switching sub-domain after it overflowed a queue, group, or target.
ACD
Redirected
The call left the switching sub-domain after it was diverted or deflected.
Deflect Call
Resources Not Available
The call left the switching sub-domain after it was diverted from a device because there were no resources available to process it.
ACD, distribution
Transfer
The call was transferred to a destination outside the switching sub-domain.
Transfer
17.2.12.3 Functional Requirements 1. When observing a call or a device in a call, and the call diverts from a device in the call, if the switching function does not provide the Diverted event for all devices in a call or for call-type monitors (as indicated through the capabilities exchange services option), the computing function shall use the networkInterfaceUsed, calledDevice, lastRedirectionDevice, and cause (EventCause parameter type) parameters to properly track the progress of the call as a result of the redirection. See 6.7.6, “Tracking a Diverted Call”, on page 75 for more information. 2. After a call has cut through the switching sub-domain boundary to another network (Network Reached event generated), all subsequent events reported for the endpoint to which the Network Interface Device (e.g., trunk, CO Line) is associated shall include a cause parameter with a cause of Network Signal or a more specific cause representing network information. 3. For external incoming calls, the contents of the networkCallingDeviceID and the networkCalledDeviceID parameters shall not change as long as the associatedCallingDevice remains in the call. This differs from the callingDeviceID and the calledDeviceID parameters in that these parameters may change as a result of features such as transfer, forwarding, and conferencing, etc.
- 393 -
17.2.13 Offered The Offered event indicates that the connection is in the Offered mode of the Alerting state. This indicates that a call is in a pre-delivery state. In this pre-delivery state, the opportunity exists for a computing function to issue one of a set of supported services (e.g., Accept Call, Clear Connection (“reject”), Deflect Call) or an ISDN device to accept or reject the call. From the calling side perspective, the call is not delivered at the called device. As a consequence, delivery information such as Ringback indication and/or Network signalling is not provided. For example, the device makes no ringing sounds while in the Offered mode of the Alerting state. The connection may transit to the Ringing mode of the Alerting state after the call is accepted (See 17.1.1, “Accept Call”, on page 243) or after a time out period, for example. Figure 17-47 Offered Event BEFORE EVENT
a, h n, q, f
D1
C1
AFTER EVENT
D1 (offeredDevice)
D2
*
DEVICES D1 : offeredDevice D2 : callingDevice
a
C1
*
D2 (callingDevice)
AFFECTED CONNECTIONS D1C1 : offeredConnection CONNECTION STATES a : alerting state h : hold state n : null state q : queued state f : failed state * : (unspecified/unaffected)
CALLS C1 : call that has been delivered to D1
17.2.13.1 Event Parameters Table 17-175 Offered—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
offeredConnection
ConnectionID
M
Specifies the connection that is alerting.
offeredDevice
SubjectDeviceID
M
Specifies the device that is alerting.
callingDevice
CallingDeviceID
M
Specifies the calling device.
calledDevice
CalledDeviceID
M
Specifies the originally called device.
lastRedirectionDevice
RedirectionDeviceID
M
Specifies the previously known redirected from device.
originatingNIDConnection
ConnectionID
O
Specifies the connection of the Network Interface Device (NID) that the call originated from. If this parameter is supported, it shall be provided if there is an originating NID associated with the call, otherwise it shall not be provided. See Functional Requirement #3.
- 394 -
Table 17-175 Offered—Event Parameters (continued) Parameter Name localConnectionInfo
Type LocalConnectionState
M/ O/C C
Description Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the alerting device: Alerting
•
For the calling device: (unaffected)
This parameter is mandatory for events generated for device-type monitors. correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call and shall otherwise not be provided.
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
networkCallingDevice
NetworkCallingDeviceID
O
Specifies the original calling device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
networkCalledDevice
NetworkCalledDeviceID
O
Specifies the original called device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
associatedCallingDevice
AssociatedCallingDeviceID
C
Specifies the Network Interface Device associated with the calling device if the call is an external incoming call. This parameter is mandatory for all external incoming calls and shall not be provided otherwise.
associatedCalledDevice
AssociatedCalledDeviceID
C
For outgoing external calls, this parameter specifies the Network Interface Device associated with the called device. For incoming external calls, this parameter specifies a device within the switching sub-domain associated with the originally called device. This parameter is mandatory for all external outgoing calls and it is optional for external incoming calls.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
offeredConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the offeredConnection connection. If this parameter is not present, then the connection information is switching function specific.
- 395 -
Table 17-175 Offered—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call. This could represent the subject header of an Email (text call) or intent for a voice call, for example.
messageInfo
MessageInfo
O
Specifies the contents of message information associated with a call. The message information consists of one of more items.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
deviceHistory
DeviceHistory
O
Specifies the list of devices which were previously associated with the call (e.g. redirecting, transferring, clearing devices).
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information attached to the event.
17.2.13.2 Event Causes Table 17-176 Offered—Event Causes Event Cause
Description
Associated Features
ACD Busy
The call was offered to an ACD device that has currently no available agents.
ACD, Consultation Call
ACD Forward
The call was offered to a new device and is no longer queued at the previous ACD device.
ACD
ACD Saturated
The call was offered to an ACD device that has currently no internal resources available (including agents).
ACD, Consultation Call
Call Back
The call was offered to a device because of a previously set call back feature.
Call Back Call-Related
Call Forward
The call was offered to a device after it was forwarded (any type of forwarding).
Call Forwarding
Call Forward—Busy
The call was offered to a device after it was forwarded because of a busy condition.
Call Forwarding
Call Forward— Immediate
The call was offered to a device after it was forwarded (forwarding on all conditions).
Call Forwarding
Call Forward—No Answer
The call was offered to a device after it was forwarded because of a no answer condition.
Call Forwarding
Conference
The call that is being offered to a device involves a conference resource or is intended to be part of a conference.
Any conference feature
Distributed
The call was offered to a device because the call has moved from the distribution mechanism (ACD, Hunt) to an available device associated with the distribution mechanism.
ACD, Routeing Services
- 396 -
Table 17-176 Offered—Event Causes (concluded) Event Cause
Description
Associated Features
Entering Distribution
The call was offered to a distribution mechanism (ACD, Hunt) for the purpose of being distributed.
ACD, Routeing Services
Key Operation
The call was offered to a device that has an appearance in a call appearance, bridged, or hybrid device configuration.
Multiple Appearance
Multiple Alerting
The call that is alerting the subject device is also alerting other devices.
Multiple Alerting
Network Signal
The call was offered to a device that is outside of the switching sub-domain.
External Calls
New Call
The call was not redirected.
Any feature
No Available Agents
The call was offered to a device because there were no available devices in a group (ACD).
ACD, Forwarding
Normal
The call was offered to a device (a more specific cause cannot be provided).
Any feature
Overflow
The call was offered to a device after it overflowed a queue, group, or target.
ACD
Override
The call was offered to a device as a result of an override (e.g., Intrude Call) feature.
Intrude Call
Recall
The call was offered to a device as part of the recall feature (any type of recall).
Recall
Recall - Busy
The call was offered to a device as part of the recall feature due to a busy condition at the intended device.
Recall
Recall - No Answer
The call was offered to a device as part of the recall feature due to a no answer condition at the intended device.
Recall
Recall - Forwarded
The call was offered to a device as part of the recall feature due to a forwarding condition at the intended destination.
Recall
Recall - Resources Not Available
The call was offered to a device as part of the recall feature due to unavailable resources at the intended device.
Recall
Redirected
The call was offered to a device after it was diverted from or deflected to this device.
Deflect Call
Remains in Queue
The call was offered to a device while the calling device’s position in the queue is retained. For example, the call could be offered to a VRU or other automated answering equipment while the calling device retains its position in the ACD queue.
ACD, Queuing, Single Step Conference, Join Call
Resources Not Available
The call was offered because some resources were not available (ACD, forwarding).
ACD, Forwarding
Single Step Transfer
The call alerted the device due to a Single Step Transfer service.
Single Step Transfer
Single Step Conference
The call alerted the device due to a Single Step Conference service.
Single Step Conference
Timeout
The event was generated because a trunk timer expired. It is not generated as the result of a particular network event or condition.
External calls
- 397 -
17.2.13.3 Functional Requirements 1. Switching function implementations vary in their support for call control services while the Offered mode of the alerting state. The computing function shall determine supported services for Offered mode through the capabilities exchange services. 2. The switching function may support an Offered mode time-out. For example, if no service is applied to the connection within an switching function-specific period, it will transit from the Offered mode to the Ringing mode of the alerting state. 3. If there is more than one calling device (i.e. a conference calling back to a device), then the originatingNIDConnection parameter will not be present. 4. When a call is offered to a bridged device configuration, multiple Offered events are sent (one for each appearance of the device configuration). Each event will contain the following type of information: •
The event for the appearance which is offered the call first will have the appropriate event cause on why the call is being offered to the device configuration. All subsequence events for the other appearances will have an event cause of Key Operation.
•
The offeredConnection will be the connection identifier of the specific appearance.
•
The offeredDevice will depend on the type of referencing model that is supported by the switching function (refer to 6.1.5, “Referencing Devices, Elements, Appearances and Device Configurations”, on page 54).
•
The calledDevice or associatedCalledDevice will contain the device identifier associated with the logical element of the device.
5. When observing a call or a device in a call, and the call diverts from a device in the call, if the switching function does not provide the Diverted event for all devices in a call or for call-type monitors (as indicated through the capabilities exchange services option), the computing function shall use the offeredDevice, calledDevice, lastRedirectionDevice, and cause (eventCause parameter type) parameters to properly track the progress of the call as a result of the redirection. See 6.7.6, “Tracking a Diverted Call”, on page 75 for more information. 6. For external incoming calls, the contents of the networkCallingDeviceID and the networkCalledDeviceID parameters shall not change as long as the associatedCallingDevice remains in the call. This differs from the callingDeviceID and the calledDeviceID parameters in that these parameters may change as a result of features such as transfer, forwarding, and conferencing, etc.
- 398 -
17.2.14 Originated The Originated event indicates that a call is being attempted from a device. It implies that input activity for the call is complete and that a call (rather than a feature) has been requested. Common situations that generate this event when the switch has originated a call at the originating device are: •
Due to the execution of the Make Call service.
•
Due to the execution of the Consultation Call service.
•
After a user has completed manually dialling a number.
•
When an external incoming call originates from a Network Interface Device (e.g., trunk, CO line). Figure 17-48 Originated Event BEFORE EVENT
i, n
D1
C1
AFTER EVENT
D2
c, n
D1 (originatingDevice)
c
C1
c, n
DEVICES D1 : originatingDevice
AFFECTED CONNECTIONS D1C1 : originatedConnection
CALLS C1 : existing call
CONNECTION STATES c : connected state i : initiated state n : null state
D2
Note that the connected state for D2C1 is when D2 is a NID. 17.2.14.1 Event Parameters Table 17-177 Originated—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
originatedConnection
ConnectionID
M
Specifies the connection at which the call originated.
callingDevice
SubjectDeviceID
M
Specifies the calling device.
calledDevice
CalledDeviceID
M
Specifies the originally called device.
originatingDevice
DeviceID
O
Specifies the originating device. The originating device represents a device that originated a call in the switching sub-domain on behalf of the calling device (e.g., a group of stations). The originating device shall not represent a Network Interface Device. This parameter may be provided for external outgoing and internal calls when the originating device is different from the calling device. This parameter shall not be provided for external incoming calls or when the originating device is identical to the calling device.
- 399 -
Table 17-177 Originated—Event Parameters (continued) Parameter Name localConnectionInfo
Type
M/ O/C
LocalConnectionState
C
Description Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the device initiating the call: Connected
This parameter is mandatory for events generated for device-type monitors. correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call and shall otherwise not be provided.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
networkCallingDevice
NetworkCallingDeviceID
O
Specifies the original calling device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
networkCalledDevice
NetworkCalledDeviceID
O
Specifies the original called device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
associatedCallingDevice
AssociatedCallingDeviceID
C
Specifies the Network Interface Device associated with the calling device if the call is an external incoming call. This parameter is mandatory for all external incoming calls and shall not be provided otherwise.
associatedCalledDevice
AssociatedCalledDeviceID
C
For outgoing external calls, this parameter specifies the Network Interface Device associated with the called device. For incoming external calls, this parameter specifies a device within the switching sub-domain associated with the originally called device. This parameter is mandatory for all external outgoing calls and it is optional for external incoming calls.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
originatedConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the originatedConnection connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call. This could represent the subject header of an Email (text call) or intent for a voice call, for example.
- 400 -
Table 17-177 Originated—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
messageInfo
MessageInfo
O
Specifies the contents of message information associated with a call. The message information consists of one of more items.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information attached to the event.
17.2.14.2 Event Causes Table 17-178 Originated—Event Causes Event Cause
Description
Associated Features
Call Back
A call was originated from a device because a previously set call back feature.
Call Back Call-Related, Call Back NonCall-Related
Conference
A call was originated from a device with the intended purpose of establishing a conference.
Consultation Call with a consultOptions of ConferenceOnly, Make Connection
Consultation
A call was originated from a device as part of a consultation call.
Consultation Call
Make Call
A call was originated from a device as the result of the Make Call service.
Make Call (without prompting)
New Call
A call was originated.
Any feature
Normal
A call was originated from a device (a more specific event cause cannot be provided).
Any feature, Make Call
Transfer
A call was originated from a device as part of a consultation for the purpose of transferring a call.
Consultation Call with a consultOptions of TransferOnly
17.2.14.3 Functional Requirements 1. This event will only be generated when the computing function has a device-type or call-type monitoring applied to a device that is initiating a call. 2. This event will only be generated on an incoming call from a device outside the switching subdomain when the device is a Network Interface Device that can have monitoring applied to it. 3. For external incoming calls, the contents of the networkCallingDeviceID and the networkCalledDeviceID parameters shall not change as long as the associatedCallingDevice remains in the call. This differs from the callingDeviceID and the calledDeviceID parameters in that these parameters may change as a result of features such as transfer, forwarding, and conferencing, etc.
- 401 -
17.2.15 Queued The Queued event indicates that a call has been queued. Common situations that generate this event include: •
A call is queued at an ACD or hunt group device.
•
A call is queued (camped on or parked, for example) at a device. Figure 17-49 Queued Event
BEFORE EVENT
D1
*
AFTER EVENT
a, f, n, q
C1
D1 (callingDevice)
D2
DEVICES D1 : callingDevice D2 : queue device*
*
C1
q
D2 (queue device)
AFFECTED CONNECTIONS D2C1 : queuedConnection CONNECTION STATES a : queue state f : fail state n : null state q : queued state * : (unspecified/unaffected)
CALLS C1 : existing call
*There are some situations where D2 can be the calling device. 17.2.15.1 Event Parameters Table 17-179 Queued—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
queuedConnection
ConnectionID
M
Specifies the queued connection.
queue
SubjectDeviceID
M
Specifies the queue device.
callingDevice
CallingDeviceID
M
Specifies the calling device.
calledDevice
CalledDeviceID
M
Specifies the originally called device.
lastRedirectionDevice
RedirectionDeviceID
M
Specifies the previously known redirected from device.
numberQueued
Value
O
Specifies the total number of calls in queue, including this call.
callsInFront
Value
O
Specifies the number of calls ahead of the call when it was enqueued (this call is not counted in this number).
localConnectionInfo
LocalConnectionState
C
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the queue device: Queued
•
For the other devices left in the call: (unaffected)
This parameter is mandatory for events generated for device-type monitors. correlatorData
CorrelatorData
C
- 402 -
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call and shall otherwise not be provided.
Table 17-179 Queued—Event Parameters (continued) Parameter Name
Type
M/ O/C
Description
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
networkCallingDevice
NetworkCallingDeviceID
O
Specifies the original calling device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
networkCalledDevice
NetworkCalledDeviceID
O
Specifies the original called device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
associatedCallingDevice
AssociatedCallingDeviceID
C
Specifies the Network Interface Device associated with the calling device if the call is an external incoming call. This parameter is mandatory for all external incoming calls and shall not be provided otherwise.
associatedCalledDevice
AssociatedCalledDeviceID
C
For outgoing external calls, this parameter specifies the Network Interface Device associated with the called device. For incoming external calls, this parameter specifies a device within the switching sub-domain associated with the originally called device. This parameter is mandatory for all external outgoing calls and it is optional for external incoming calls.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
queuedConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the queuedConnection connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call. This could represent the subject header of an Email (text call) or intent for a voice call, for example.
messageInfo
MessageInfo
O
Specifies the contents of message information associated with a call. The message information consists of one of more items.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
- 403 -
Table 17-179 Queued—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
deviceHistory
DeviceHistory
O
Specifies the list of devices which were previously associated with the call (e.g. redirecting, transferring, clearing devices).
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specified non-standardized information.
17.2.15.2 Event Causes Table 17-180 Queued—Event Causes Event Cause
Description
Associated Features
Busy
The call was queued at a called device because the device was active on another call and unable to accept this call.
Make Call, Consultation Call, Deflect Call, Single-Step Conference Call, Single-Step Transfer Call
Call Forward
The call was immediately queued to a device after it was forwarded.
Call Forwarding
Call Forward—Busy
The call was immediately queued to a device after it was forwarded because of a busy condition.
Call Forwarding
Call Forward— Immediate
The call was immediately queued to a device after it was forwarded (forwarding on all conditions).
Call Forwarding
Call Forward—No Answer
The call was immediately queued to a device after it was forwarded because of a no answer condition.
Call Forwarding
Camp On
The call was queued to a device because of the camp on feature.
Camp On Call
Camp On Trunks
The call was queued to a trunk because of the camp on feature.
External Call, Camp On Call
Distribution Delay
The distribution of the call was delayed at a distribution device for distribution device specific reasons (e.g. preconnect announcement).
ACD, queueing
Do Not Disturb
The call was queued at a device after it encountered a device with Do Not Disturb feature set.
Forwarding
Multiple Queueing
The call that is queued is also queued at other devices.
Multiple Queueing
Network Congestion
The call was queued because the call encountered a congested network.
External Call
Network Not Obtainable
The call could not reach a destination network.
External Call
Network Signal
The call was queued to a device outside of the switching sub-domain.
External Call
No Available Agents
The call was queued to a device because there were no available agents.
ACD
Normal
The call was queued to a device (a more specific cause cannot be provided).
Any feature
Overflow
The call was queued to a device after it overflowed a queue, group, or target.
ACD, queueing
Park
The call was queued because of the park feature.
Park Call
- 404 -
Table 17-180 Queued—Event Causes (concluded) Event Cause
Description
Associated Features
Recall
The call was queued to a device as part of the recall feature (any type of recall).
Recall
Recall - Busy
The call was queued to a device as part of the recall feature due to a busy condition at the intended device.
Recall
Recall - No Answer
The call was queued to a device as part of the recall feature due to a no answer condition at the intended device.
Recall
Recall - Forwarded
The call was queued to a device as part of the recall feature due to a forwarding condition at the intended destination.
Recall
Recall - Resources Not Available
The call was queued to a device as part of the recall feature due to unavailable resources at the intended device.
Recall
Redirected
The call was queued to a device after it was diverted from or deflected to this device.
Deflect Call
Remains in Queue
The call was queued to a device while the calling device’s position in the queue is retained. For example, the call could be queued to a VRU or other automated answering equipment while the calling device retains its position in the ACD queue.
ACD, Queuing, Single Step Conference, Join Call
Resources Not Available
The call was queued to a device because resources were not available.
ACD
Trunks Busy
The call was queued to a device because there is no available Network Interface Device (e.g., Trunk, CO line).
External Call
17.2.15.3 Functional Requirements 1. When observing a call or a device in a call, and the call diverts from a device in the call, if the switching function does not provide the Diverted event for all devices in a call or for call-type monitors (as indicated through the capabilities exchange services option), the computing function shall use the queue, calledDevice, lastRedirectionDevice, and cause (eventCause parameter type) parameters to properly track the progress of the call as a result of the redirection. See 6.7.6, “Tracking a Diverted Call”, on page 75 for more information. 2. For external incoming calls, the contents of the networkCallingDeviceID and the networkCalledDeviceID parameters shall not change as long as the associatedCallingDevice remains in the call. This differs from the callingDeviceID and the calledDeviceID parameters in that these parameters may change as a result of features such as transfer, forwarding, and conferencing, etc.
- 405 -
17.2.16 Retrieved The Retrieved event indicates that a previously held call has been retrieved. Common situations that generate this event include: •
When a held call is retrieved through the phone using features such as Retrieve, Alternate, etc.
•
When a held call is retrieved during the successful execution of the Alternate Call, Reconnect Call, or the Retrieve Call service. Figure 17-50 Retrieved Event
BEFORE EVENT
h
D1
C1
AFTER EVENT
D1
D2
*
(retrievingDevice)
DEVICES D1 : retrievingDevice D2 : device in call with D1
c
C1
*
D2
AFFECTED CONNECTIONS D1C1 : retrievedConnection CONNECTION STATES c : connected state h : hold state * : (unspecified/unaffected)
CALLS C1 : existing call
17.2.16.1 Event Parameters Table 17-181 Retrieved—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
retrievedConnection
ConnectionID
M
Specifies the connection at which hold was deactivated.
retrievingDevice
SubjectDeviceID
M
Specifies the device at which hold was deactivated.
localConnectionInfo
LocalConnectionState
C
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the retrieving device: Connected
•
For the other devices left in the call: (unaffected)
This parameter is mandatory for events generated for device-type monitors. correlatorData
CorrelatorData
O
Specifies the correlator data associated with the call.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
- 406 -
Table 17-181 Retrieved—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
retrievedConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the retrievedConnection connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information attached to the event.
17.2.16.2 Event Causes Table 17-182 Retrieved—Event Causes Event Cause
Description
Associated Features
Alternate
The call was retrieved at a device as part of the alternate feature.
Alternate Call
Network Signal
The call was retrieved at a device that is outside of the switching sub-domain.
External Call
Normal
The call was retrieved at a device (a more specific cause cannot be provided).
Any feature, Alternate Call, Reconnect Call, Retrieve Call
Recall
The call was retrieved at a device because a hold timeout expired.
Recall
17.2.16.3 Functional Requirements 1. This event is only generated for the Alternate feature when the device is alternating between a connection that is in the Connected state and a connection that is in the Hold state. Note that this event shall not be generated when the Alternate feature is used to answer an alerting call (the Established event is generated in this case). Refer to 17.1.2, “Alternate Call”, on page 245 for more information.
- 407 -
17.2.17 Service Initiated The Service Initiated event indicates that a telephony service has been initiated at a monitored device. The switching function typically generates this event when “dial-tone” is being provided. This event indicates that either a call may be originated or a feature may be invoked. This event also may indicate that a device is prompting a user. Common situations that generate this event include: •
When a service or feature prompts a user to take a phone off-hook and that phone is not able to do so without manual intervention.
•
A Make Call or Consultation Call service has been invoked and the originating device is initiating a new call that is associated with the originating device.
•
When manually invoking any feature at a device for an existing call that requires a new call to be created to input the feature.
•
When a device is taken off-hook manually.
•
When an incoming call arrives on a monitored Network Interface Device (e.g. trunk, CO line). Figure 17-51 Service Initiated Event BEFORE EVENT
AFTER EVENT
D1
D1
(initiatingDevice)
i
C1
DEVICES D1 : initiatingDevice
AFFECTED CONNECTIONS D1C1 : initiatedConnection
CALLS C1 : initiated call
CONNECTION STATES i : initiated state
17.2.17.1 Event Parameters Table 17-183 Service Initiated—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
initiatedConnection
ConnectionID
M
Specifies the connection at which service was initiated.
initiatingDevice
SubjectDeviceID
M
Specifies the initiating device.
calledDevice
CalledDeviceID
O
Specifies the originally called device. In the case of prompting, this parameter specifies the device that will be called after the prompt is answered.
localConnectionInfo
LocalConnectionState
C
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
When the device is initiating a service of some form: Initiated
This parameter is mandatory for events generated for device-type monitors. correlatorData
CorrelatorData
C
- 408 -
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call.
Table 17-183 Service Initiated—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
initiatedConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the initiatedConnection connection. If this parameter is not present, then the connection information is switching function specific.
networkCallingDevice
NetworkCallingDeviceID
O
Specifies the original calling device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
networkCalledDevice
NetworkCalledDeviceID
O
Specifies the original called device information provided by the network for external incoming calls. This parameter is provided only for external incoming calls.
associatedCallingDevice
AssociatedCallingDeviceID
C
Specifies the Network Interface Device associated with the calling device if the call is an external incoming call. This parameter is mandatory for all external incoming calls and shall not be provided otherwise.
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent of the call. This could represent the subject header of an Email (text call) or intent for a voice call, for example.
messageInfo
MessageInfo
O
Specifies the contents of message information associated with a call. The message information consists of one of more items.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information attached to the event.
- 409 -
17.2.17.2 Event Causes Table 17-184 Service Initiated—Event Causes Description
Associated Features
Active Participation
Event Cause
The telephony service was initiated at a device and the device is being prompted to go off-hook.
Join Call with a participationType of Active (prompting)
Call Back
The telephony service was initiated at a device and the device is being prompted to go off-hook because of a previously set call back feature.
Call Back Call-Related, Call Back NonCall-Related
Call Pickup
The telephony service was initiated at a device and the device is being prompted to go off-hook.
Directed Pickup, Group Pickup (prompting)
Conference
The telephony service was initiated at a device with the intended purpose of establishing a conference.
Consultation Call with a consultOptions of ConferenceOnly, Make Connection
Consultation
The telephony service was initiated at a device as part of a consultation.
Consultation Call
Join Call
The telephony service was initiated at a device and the device is being prompted to go off-hook.
Join Call (prompting)
Make Call
The telephony service was initiated at a device and the device is being prompted to go off-hook.
Make Call (prompting)
Make Connection
The telephony service was initiated at a device and the device is being prompted to go off-hook.
Make Connection (prompting)
Make Predictive call
The telephony service was initiated at a (calling) device prior to call activity at a called device as part of a predictive call feature.
Make Predictive Call
New Call
The telephony service was initiated for establishing a connection with another device.
Any feature, Make Call
Normal
A more specific cause cannot be provided.
Any feature
Reserved
A device was reserved prior to call delivery.
Make Predictive Call, incoming call
Silent Participation
The telephony service was initiated at a device and the device is being prompted to go off-hook.
Join Call with a participationType of Silent (prompting)
Transfer
The telephony service was initiated at a device as part of a consultation for the purpose of transferring a call.
Consultation Call with a consultOptions of TransferOnly
17.2.17.3 Functional Requirements 1. Some CSTA services (Make Call, Call Back, Pickup, Join Call) may require to prompt the user of the targeted device in order to take that device off-hook. In this case a Service Initiated event is generated containing the appropriate cause code (Make Call, Call Back, Call Pickup, Join Call). The implementation of this prompting mechanism is switching function specific (display flashing, ring pattern, lamp blinking, etc.). 2. It is switching function dependent as to whether this event is provided to the computing function. For those switching functions that cannot detect prompting, or a device going off-hook and being provided dialtone, the first event seen by the computing function, for the calling device, will be the Originated event. 3. When prompting a call appearance, bridged, or hybrid device configuration as a result of a Make Call service request, only one of the appearances (initiatedConnection) will be prompted. 4. When prompting a call appearance, bridged, or hybrid device configuration as a result of a Call Back service request or Recall feature, only the appearance (initiatedConnection) that issued the Call Back service request or that was the Recall device, will be prompted.
- 410 -
5. For an external incoming call, this event is generated at the Network Interface Device (when this device can have monitoring applied to it). 6. It is not required to send the Service Initiated event for functional (e.g. en-bloc BRI) terminals nor is it required to be sent for calls that are set up without receiving dial tone or other prompting, like CSTA calls initiated with the Make Call service from a hands-free telephone.
- 411 -
17.2.18 Transferred The Transferred event indicates that an existing call has been transferred to another device and the transferring device has been dropped from the call. The transferring device does not appear in any future events for the call. Common situations that generate this event include: •
Two step transferring situations (manual and service initiated).
•
Single step transferring situations (manual and service initiated). Figure 17-52 Transferred Event (Case A: Two Step Transfer) BEFORE EVENT
c, h
D1
c, h
AFTER EVENT
C1
#
D2
C2
#
D3
D1
#
(transferringDevice)
C3
DEVICES D1 : transferringDevice D2 : transferred device D3 : transferredToDevice CALLS C1 : primary old call* C2 : secondary old call* C3 : resulting call
#
D2 (transferred device)
D3 (transferredToDevice)
AFFECTED CONNECTIONS D1C1 : primaryOldCall connection* D1C2 : secondaryOldCall connection D2C1 : initial call at D2 D3C2 : initial call at D3 D2C3 : resulting call at D2 D3C3 : resulting call at D3 CONNECTION STATES c : connected state h : hold state # : (unspecified/inherited)
* the primary/secondary old call and the primary/secondary old call connections mentioned in this figure are from the perspective of the transferringDevice (D1). See Functional Requirement #1.
- 412 -
Figure 17-53 Transferred Event (Case B: Single Step Transfer) BEFORE EVENT
c
D1
AFTER EVENT
#
C1
D2
D1
#
(transferringDevice)
C3
D3
DEVICES D1 : transferringDevice D2 : transferred device D3 : transferredToDevice
D2 (transferred device)
D3
a, c f, n, q (transferredToDevice)
AFFECTED CONNECTIONS D1C1 : primaryOldCall connection D2C1 : initial call at D2 D2C3 : resulting call at D2 D3C3 : resulting call at D3
CALLS C1 : primary old call C3 : resulting call
CONNECTION STATES c : connected state # : (unspecified/inherited)
17.2.18.1 Event Parameters Table 17-185 Transferred—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
primaryOldCall
ConnectionID
M
Specifies the connection of the primary call. See Functional Requirement #1.
secondaryOldCall
ConnectionID
C
Specifies the connection of the secondary call. If the switching function supports the “fixed-view” option (as indicated by the capability exchange services), this parameter is mandatory. If the switching function supports the “local-view” option, this parameter is mandatory if there are two known calls involved with the transfer (before the transfer is created) from the perspective of the monitored device, otherwise it shall not be provided. See Functional Requirement #1.
transferringDevice
SubjectDeviceID
transferredToDevice
SubjectDeviceID
transferredConnections
ConnectionList
1
1
- 413 -
M
Specifies the device that transferred the call.
M
Specifies the transferred to device.
M
Specifies information on each device/ConnectionID in the resulting transferred call that are known by the switching function.
Table 17-185 Transferred—Event Parameters (continued) Parameter Name localConnectionInfo
Type
M/ O/C
LocalConnectionState
C
Description Specifies the local connection state of the device associated with the Monitor Cross Reference ID. The following are the states of the devices in the call. •
For the transferring device (any Connection IDs associated with the transfer, i.e., this event should be used for both single and multi-step transfers.): Null
•
For the other devices associated with the transfer: (unaffected)
This parameter is mandatory for events generated for device-type monitors. correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call and shall otherwise not be provided.
userData
UserData
C
Specifies user information that is related to the call. This parameter is mandatory if user data is sent and the parameter is supported, otherwise it shall not be included.
chargingInfo
ChargingInfo
O
Specifies a total value of charging or currency units for the device that transferred the call.
cause
EventCause
M
Specifies the reason for the event.
servicesPermitted
ServicesPermitted
C
Specifies a list of the call control services that can be applied to the local connection. This parameter is mandatory if the switching function supports the Dynamic Feature Availability option (as indicated through the capabilities exchange services), otherwise this parameter is optional.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.20, “MediaCallCharacteristics”, on page 138 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
callLinkageDataList
List
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided. The parameter consists of the following components: • newCallLinkageData (M) CallLinkageData - specifies the call linkage data associated with the resulting call. • oldCallLinkageData (M) CallLinkageData - specifies the call linkage data that was discarded as the result of the transfer.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
deviceHistory
DeviceHistory
O
Specifies the list of devices which were previously associated with the call (e.g. redirecting, transferring, clearing devices).
locationInfo
LocationInfoList
O
Specifies the location information associated with the devices in the call.
- 414 -
Table 17-185 Transferred—Event Parameters (concluded) Parameter Name security
Type
M/ O/C
CSTASecurityData
O
Description Specifies timestamp information, message sequence number, and security information.
privateData CSTAPrivateData O Non-standardized information attached to the event. 1. Note that SubjectDeviceID refers to a parameter type—not the subject device of the Transferred event. This parameter type is used to represent the two devices in this event because the two devices are affected by the generation of this event (i.e., the transferring device and the transferred device). However, there is only one subject device of the event and that is the transferring device. For more details on the SubjectDeviceID parameter type, see 12.3.30, “SubjectDeviceID”, on page 156.
17.2.18.2 Event Causes Table 17-186 Transferred—Event Causes Event Cause
Description
Associated Features
Network Signal
The call was involved in a transfer located outside of the switching sub-domain.
External Call
Normal
The call was transferred (a more specific event cause cannot be provided).
Transfer
Path Replacement
The call was transferred due to optimization of network (NID) resources.
Network feature
Single Step Transfer
The call was transferred because of a single step transfer.
Single Step Transfer Call
Transfer
The call was transferred because of a two step transfer.
Transfer Call, Two Step Transfer
17.2.18.3 Functional Requirements 1. The contents of the primaryOldCall and the secondaryOldCall parameters may contain either a “fixed view” or a “local view” of the connections at a device before the transfer has been completed. The switching function indicates which view it provides via the connectionView parameter in the capability exchange services. •
•
fixed view - for each transferred event generated by monitors placed on different devices in a call, the switching function provides the same information in the primaryOldCall and the secondaryOldCall parameters independent of the monitorType (call or device-type monitor) and independent of the role of the device in the conference (conferencingDevice, addedParty, etc.). The meaning of these parameters for the fixed-view are: •
primaryOldCall - specifies the first call visible at the transferringDevice.
•
secondaryOldCall - specifies the second call visible at the transferringDevice.
local view - for each transferred event generated by monitors placed on different devices in a call, the switching function provides different information in the primaryOldCall and the secondaryOldCall parameters that depends upon which call was made visible first, from the perspective of the monitored device. The meaning of these parameters for the local-view are: •
primaryOldCall - specifies the first call visible at the monitored device. For example, for a device-type monitor placed on the transferringDevice (two step transfer), this is the first call placed on hold (C1). For a device-type monitor placed on the transferredTo device, this is the first (and only) call involved in call C2 from the perspective of the monitored device.
•
secondaryOldCall - specifies the second call visible at the monitored device. For example, for a device-type monitor placed on the transferringDevice (two step transfer), this is call
- 415 -
C2. For a monitor placed on the transferredTo device, there is no secondaryOldCall parameter. 2. The transferredConnections parameter is a list that contains the new ConnectionID, old ConnectionID, DeviceID (values such as ANI, etc.), and for externally located devices the associated Network Interface DeviceID. Refer to 12.2.9, “ConnectionList”, on page 118, for a description of which components are optional and mandatory. 3. The computing function should never assume the reuse of callIDs, although some switching functions may reuse one or the other.
- 416 -
18
Call Associated Features This clause describes call associated (non-Call Control related) features including: •
Call Associated Feature services
•
Call Associated Feature events
Refer to 6.1.2, “Call”, on page 41 and 6.1.3, “Connection”, on page 49 for information on the identifiers used to reference calls and connections.
18.1
Services Table 18-1 Call Associated Feature Services Summary Call Associated Feature Service
Description
Pg.
18.1.1 Associate Data
Associates information (such as correlator data, account code, authorisation code, call qualifying data, language preference, etc.) with a specified call.
418
18.1.2 Cancel Telephony Tones
Cancels a telephony tone that is being generated on a specified connection.
420
18.1.3 Change Connection Information
Changes the connection information associated with the connection.
422
18.1.4 Generate Digits
Generates DTMF or rotary digits on behalf of a connection in a call.
425
18.1.5 Generate Telephony Tones
Generates a specified telephony tone on behalf of a connection in a call.
428
18.1.6 Send User Information
Sends user-to-user information from a specified connection in a call.
431
- 417 -
18.1.1
C
Associate Data
S
The Associate Data service associates computing function information (such as correlator data, account code, authorization code, call qualifying data, call characteristics, subject of call, language preferences, etc.) with a specified call. This service does not affect the state or progress of a call. Figure 18-1 Associate Data Service BEFORE SERVICE
D1
*
C1
AFTER SERVICE
*
D2
*
D1
C1
*
D2
CONNECTIONS D1C1 : existingCall
DEVICES D1 : device in call C1 with device D2 D2 : device in call C1 with device D1
CONNECTION STATES
* : (unspecified/unaffected)
CALLS C1 : existingCall
Note that the existingCall connectionID could either be the D1C1 or the D2C1 connections in Figure 18-1. 18.1.1.1 Service Request Table 18-2 Associate Data—Service Request Parameter Name
Type
M/ O/C M
Description
existingCall
ConnectionID
Specifies the call with which the information is to be associated.
accountCode 1
AccountInfo
C
Specifies the account code to associate with the call.
authCode 1
AuthCode
C
Specifies the authorization code to allow the call.
correlatorData1
CorrelatorData
C
Specifies the correlator data to associate with the call.
callQualifyingData1
CallQualifyingData
C
Specifies the call qualifying data (wrap code, walk away code, etc.) to associate with the call.
callCharacteristics1
CallCharacteristics
C
Specifies the high level characteristics (ACD call, Priority call, etc.) to associate with the call. See 12.2.4 for the complete set of possible values.
subjectOfCall1
SubjectOfCall
C
Specifies the subject/intent to associate with the call.
languagePreferences1
LanguagePreferences
C
Specifies the language preferences to associate with the call.
deviceInfo
DeviceID
C
Specifies the device information (e.g. name) to be associated with the specified connection.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
1. At least one of these parameters shall be specified on this service (see Functional Requirement #1).
18.1.1.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. - 418 -
18.1.1.2.1 Positive Acknowledgement Table 18-3 Associate Data—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
18.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 18.1.1.3 Operational Model 18.1.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 18.1.1.3.2 Device-Type Monitoring Event Sequences Table 18-4 Associate Data—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
D1
D1C1
Call Information
D2
D2C1
Call Information
18.1.1.3.3 Call-Type Monitoring Event Sequences Table 18-5 Associate Data—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1/D2C1
Event Call Information
18.1.1.3.4 Functional Requirements
1. At least one of the service specific parameters (accountCode, authCode, correlatorData, callQualifyingData, callCharacteristics, subjectOfCall, languagePreferences) shall be provided in the service request, otherwise the service shall be rejected. 2. The Call Information event is generated as the result of this service. 3. For a complete description of the behaviour of correlator data, refer to 6.1.2.3, “Correlator Data”, on page 42. 4. When either the accountCode or callQualifyingData parameter is provided on the service request, the callID component of the connectionID in the service request may be omitted or may refer to the connectionID that no longer exists at the device. This may occur when a user enters a wrap code for a call that has just cleared, for example. It is switching function specific (as indicated by the capability exchange services) whether the switching function rejects the service (with an invalid connectionID) or accepts the service under this condition. 5. When accountInfo, authorisationCode, or callQualifyingData is provided, the ConnectionID in the service request shall be related to the device on whose behalf the data is being associated. 6. An application may use the deviceInfo parameter to update or replace information associated with a device in a call. This may be used, for example, to associate a person’s name or SIP URI to a device in a call.
- 419 -
18.1.2
C
Cancel Telephony Tones
S
The Cancel Telephony Tones service cancels a telephony tone that is being sent on a connection by the Generate Telephony Tones service. This service does not affect the state or progress of a call. Figure 18-2 Cancel Telephony Tones Service BEFORE SERVICE
D1
*
C1
AFTER SERVICE
D2
*
D1
DEVICES D1 : device in call C1 with device D2 D2 : device in call C1 with device D1 CALLS C1 : existing call
*
C1
*
D2
CONNECTIONS D1C1 : connectionToStopTone CONNECTION STATES * : (unspecified/unaffected)
18.1.2.1 Service Request Table 18-6 Cancel Telephony Tones—Service Request Parameter Name
Type
M/ O/C
Description
connectionToStopTone
ConnectionID
M
Connection on which the tones are being generated.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
18.1.2.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 18.1.2.2.1 Positive Acknowledgement Table 18-7 Cancel Telephony Tones—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
18.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 18.1.2.3 Operational Model 18.1.2.3.1 Connection State Transitions
There are no connection state changes due to this service.
- 420 -
18.1.2.3.2 Device-Type Monitoring Event Sequences Table 18-8 Cancel Telephony Tones—Device-Type Monitoring Event Sequences Monitored Device
Connection
D1 (device in call C1 with device D2)
D1C1 (connectionToStopTone)
Event Telephony Tones Generated (with the toneGenerated parameter not provided)
18.1.2.3.3 Call-Type Monitoring Event Sequences Table 18-9 Cancel Telephony Tones—Call-Type Monitoring Event Sequences Monitored Call C1 (existingCall)
Connection D1C1 (connectionToStopTone)
18.1.2.3.4 Functional Requirements
None.
- 421 -
Event Telephony Tones Generated (with the toneGenerated parameter not provided)
18.1.3
C
Change Connection Information
S
The Change Connection Information service allows an application to change the connection information associated with a specified connection. The connection information consists of: •
flowDirection (i.e., participation type)
•
number of media channels
•
media session information.(e.g. SIP Session Description Protocol (SDP) information)
This service does not affect the connection state or progress of a call. Figure 18-3 Change Connection Information Service BEFORE SERVICE
D1
*
C1
AFTER SERVICE
D2
*
D1
DEVICES D1 : device in call C1 with device D2 D2 : device in call C1 with device D1 CALLS C1 : existingCall
C1
*
*
D2
CONNECTIONS D1C1 : connectionToBeChanged CONNECTION STATE * : (unspecified/unaffected)
Note that the existingCall connectionID could either be the D1C1 or the D2C1 connections in the above figure. 18.1.3.1 Service Request Table 18-10 Change Connection Information—Service Request Parameter Name
Type
M/ O/C
Description
connectionToBeChanged
ConnectionID
M
Specifies the connectionID whose connection information is to be changed.
requestedConnectionInfo
ConnectionInformation
M
Specifies the requested connection information. This information includes the flow direction (i.e., participation type, number of channels, and the media session information (e.g., SDP information). See 12.2.8, “ConnectionInformation”, on page 117 for more information.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
18.1.3.2 Service Response This service follows the atomic acknowledgement model for this service request.
- 422 -
18.1.3.2.1 Positive Acknowledgement Table 18-11 Change Connection Information—Positive Acknowledgement Parameter Name actualConnectionInfo
Type
M/ O/C
ConnectionInformation
M
Description Specifies the actual connection information that will be associated with the connection. The actualConnectionInfo may differ from the requestedConnectionInfo parameter in the service request (See Functional Requirement #2).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
18.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 18.1.3.3 Operational Model 18.1.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 18.1.3.3.2 Device-Type Monitoring Event Sequences Table 18-12 Change Connection Information—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
D1
D1C1
Call Information (with the connectionInfo parameter)
D2
D1C1
Call Information (with the connectionInfo parameter)
18.1.3.3.3 Call-Type Monitoring Event Sequences Table 18-13 Change Connection Information—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1
Event Call Information (with the connectionInfo parameter)
18.1.3.3.4 Functional Requirements
1. This service allows the application to change the connection information after a connection has already been created. This can be used to control media flow (transmit and receive media flow direction) associated with a connection. For example a user at a device may be participating in a voice call as listen only (flowDirection is “Receive”) meaning that the user can only hear and not contribute media into the call (i.e. silent monitoring). The application can use the Change Connection Information service to change the flowDirection associated with its connection to “TransmitAndReceive” to enable the user to both listen and speak in the call. 2. In some cases the connection information cannot be changed to the specific information as requested in the service request. If the service request results in no changes to the connection information, a negative acknowledgement should be provided. If the connection information has changed as a result of the service, either partially or completely, a positive response should be provided with the actual connection information provided in the actualConnectionInfo parameter. 3. There are several ways to control the participation type (i.e., media flow direction) associated with a connection:
- 423 -
•
When a new connection is created with certain CSTA services (e.g., Consultation Call, Make Call), the connection information can be specified in the service request via the connectionInformation parameter.
•
When a device is added to an existing call (e.g., Intrude Call, Join Call, Single Step Conference), the participationType parameter can be specified in the service request.
•
Once a connection has been created, the Change Connection Information service can be used to change the media flow direction.
- 424 -
18.1.4
C
Generate Digits
S
The Generate Digits service causes a series of digits to be sent on behalf of a connection in a call. The digits may be sent in the form of DTMF tones or rotary pulses. This service also supports optional parameters to control digit generation. This service is used for generating end-to-end information that is to be sent to a device in a call (i.e., not to address/select a device). This service does not affect the state or progress of a call. Figure 18-4 Generate Digits Service BEFORE SERVICE
*
D1
AFTER SERVICE
*
C1
D2
D1
DEVICES D1 : device in call C1 with device D2 D2 : device in call C1 with device D1
*
C1
*
D2
CONNECTIONS D1C1 : connectionToSendDigits CONNECTION STATES * : (unspecified/unaffected)
CALLS C1 : existing call
18.1.4.1 Service Request Table 18-14 Generate Digits—Service Request Parameter Name
Type
M/ O/C
Description
connectionToSendDigits
ConnectionID
M
Connection of the device which is generating the digits for the call.
digitMode
Enumerated
O
Specifies the signalling format. The complete set of possible values is:
charactersToSend
Characters (64)
M
•
rotaryPulse - rotary signalling.
•
DTMF - DTMF signalling (default).
Specifies the string of characters to send. Shall consist of the following set: •
For rotary digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D
•
For DTMF digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, *, #, A, B, C, D
A comma “,” may be included in the parameter string to indicate a pause between characters. The length of the pause is switching function specific and may be determined using the capabilities exchange services. This parameter type is a character string. The maximum length supported by the switching function is provided via the capabilities exchange services. toneDuration
Value
O
Specifies the duration, in milliseconds, of each tone to be provided (valid for DTMF digitMode only).
pulseRate
Value
O
Specifies the number of pulses per second (valid for rotaryPulse digitMode only).
- 425 -
Table 18-14 Generate Digits—Service Request (concluded) Parameter Name
Type
M/ O/C
Description
pauseDuration
Value
O
Specifies the duration, in milliseconds, of the silences between the digits (interdigit delay).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
18.1.4.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 18.1.4.2.1 Positive Acknowledgement Table 18-15 Generate Digits—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
Note that the positive acknowledgement does not necessarily mean that the charactersToSend have been successfully received by a device in the call. 18.1.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 18.1.4.3 Operational Model 18.1.4.3.1 Connection State Transitions
There are no connection state changes due to this service. 18.1.4.3.2 Device-Type Monitoring Event Sequences Table 18-16 Generate Digits—Device-Type Monitoring Event Sequences Monitored Device D1
Connection D1C1 (connectionToSendDigits)
Event Digits Generated
18.1.4.3.3 Call-Type Monitoring Event Sequences Table 18-17 Generate Digits—Call-Type Monitoring Event Sequences Monitored Call C1 (existingCall)
Connection D1C1 (connectionToSendDigits)
Event Digits Generated
18.1.4.3.4 Functional Requirements
1. This service is used for end-to-end signalling purposes. This service shall not be used to perform dialling sequences (the Dial Digits service shall be used to perform this function). 2. The charactersToSend parameter may contain additional non-standardised characters. Handling of the additional characters is switching function dependent. 3. If the toneDuration or pulseRate parameters in the service request are not present or if they are present but cannot be satisfied, the switching function may use its default value. 4. A Generate Digits service request may be rejected if there is already a switching function generated tone (busy, music, ringback, etc.) on the call. - 426 -
5. If a Generate Digits service request is received by the switching function while a previous Generate Digits service request has not yet been completed, the new request may or may not be rejected but in any case the digits shall not be interleaved or overlaid.
- 427 -
18.1.5
C
Generate Telephony Tones
S
The Generate Telephony Tones service causes a telephony tone such as a beep, busy, or ringback to be sent on behalf of a connection in a call. This service also supports optional parameters to control tone generation. This service does not affect the state or progress of a call. Figure 18-5 Generate Telephony Tones Service BEFORE SERVICE
*
D1
C1
AFTER SERVICE
*
D2
D1
DEVICES D1 : device in call C1 with device D2 D2 : device in call C1 with device D1 CALLS C1 : existing call
*
C1
*
D2
CONNECTIONS D1C1 : connectionToSendTone CONNECTION STATES * : (unspecified/unaffected)
18.1.5.1 Service Request Table 18-18 Generate Telephony Tones—Service Request Parameter Name connectionToSendTone
Type
M/ O/C
ConnectionID
M
- 428 -
Description Connection of the device which is generating the telephony tones for the call
Table 18-18 Generate Telephony Tones—Service Request (concluded) Parameter Name
Type
toneToSend
Enumerated
M/ O/C
Description
M
Specifies the tone to send. The complete set of possible values is: • beep • billing • busy • carrier • confirmation • dial • faxCNG • hold • howler • intrusion • modemCNG • park • record warning (indicates call may be being recorded) • reorder • ringback • silence • SIT VC • SIT IC • SIT RO • SIT NC • SwitchSpecified0 through SwitchSpecified100 reserved for switch specified tones.
toneDuration
Value
O
Specifies the total length in milliseconds of the tones to be provided. A value of 0 indicates that the tone should be continuous.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
18.1.5.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 18.1.5.2.1 Positive Acknowledgement Table 18-19 Generate Telephony Tones—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
Note that the positive acknowledgement indicates that the requested tone is successfully being presented. 18.1.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. - 429 -
18.1.5.3 Operational Model 18.1.5.3.1 Connection State Transitions
There are no connection state changes due to this service. 18.1.5.3.2 Device-Type Monitoring Event Sequences Table 18-20 Generate Telephony Tones—Device-Type Monitoring Event Sequences Monitored Device D1
Connection D1C1 (connectionToSendTone)
Event Telephony Tones Generated
18.1.5.3.3 Call-Type Monitoring Event Sequences Table 18-21 Generate Telephony Tones—Call-Type Monitoring Event Sequences Monitored Call C1 (existingCall)
Connection D1C1 (connectionToSendTone)
Event Telephony Tones Generated
18.1.5.3.4 Functional Requirements
1. This service is used to send inband tones for end-to-end signalling purposes. 2. The toneToSend parameter specifies standard tones. The switching function provides the exact tone based upon many factors such as country and configuration information. 3. A Generate Telephony Tones service request may be rejected if there is already a switching function generated tone (busy, music, ringback, etc.) on the call. 4. If the toneDuration parameter is not present in the service request, or if it is present but cannot be satisfied, the switching function may use its default value. 5. If a Generate Telephony Tones service request is received by the switching function while a previous Generate Digits service request has not yet been completed, the new request may or may not be rejected, but in any case the digits shall not be interleaved or overlaid. 6. The requested tone continues to be generated until the specified duration expires, until it is canceled by using the Cancel Telephony Tones service, or until the call is cleared.
- 430 -
18.1.6
C
Send User Information
S
The Send User Information service is used to send user data information. This service does not affect the state or progress of a call. Figure 18-6 Send User Information Service BEFORE SERVICE
D1
C1
*
AFTER SERVICE
*
D2
D1
DEVICES D1 : device in call C1 with device D2 D2 : device in call C1 with device D1 CALLS C1 : existingCall
C1
*
*
D2
CONNECTIONS D1C1 : existingCall CONNECTION STATE * : (unspecified/unaffected)
Note that the existingCall connectionID could either be the D1C1 or the D2C1 connections in the above figure. 18.1.6.1 Service Request Table 18-22 Send User Information—Service Request Parameter Name
Type
M/ O/C
Description
existingCall
ConnectionID
M
Specifies the connection on whose behalf user data is to be sent.
userData
UserData
M
Specifies the user data to send.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
18.1.6.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 18.1.6.2.1 Positive Acknowledgement Table 18-23 Send User Information—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
Note that the positive acknowledgement does not necessarily mean that the user information has been successfully received by the other device in the call. It only indicates that user information has been sent. 18.1.6.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 18.1.6.3 Operational Model 18.1.6.3.1 Connection State Transitions
There are no connection state changes due to this service. - 431 -
18.1.6.3.2 Device-Type Monitoring Event Sequences Table 18-24 Send User Information—Device-Type Monitoring Event Sequences Monitored Device
Connection
Event
D1
D1C1
Call Information
D2
D1C1
Call Information
18.1.6.3.3 Call-Type Monitoring Event Sequences Table 18-25 Send User Information—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1
Event Call Information
18.1.6.3.4 Functional Requirements
1. The Send User Information is used to send information end to end. The user data provided in the Send User Information service is not managed or maintained by the switching function, but instead transmitted to all devices in the call. For a complete description of the behaviour of user data, refer to 6.1.2.4, “User Data”, on page 43. 2. The ability to send user information, the timing of when the information can be sent, and the size of the data, depends upon the switching function’s capabilities and the underlying network (such as ISDN). 3. The Call Information event is used to provide the user data information received on a call. 4. The Send User Information service can be used to send call-related messages between devices in a call. The call can either be an existing call (with media) or a call created (without media) for the purpose of exchanging messages. 5. The format of user data is switching function dependent. It is recommended that a format such as MessageInfo (see 12.2.22 on page 141) be used to describe the type of data contained in the user data parameter.
- 432 -
18.2
Events Table 18-26 Call Associated Feature Events Summary Call Associated Feature Event
Description
Pg.
18.2.1 Call Information
Indicates that call associated information (such as correlator data, account code, authorisation code, call qualifying data, etc.) has been collected for a call.
434
18.2.2 Charging
Indicates that new charging information has arrived for a device involved in a call.
437
18.2.3 Digits Generated
Indicates that (DTMF or rotary) digits have been generated.
438
18.2.4 Telephony Tones Generated
Indicates that telephony tones have been generated.
440
18.2.5 Service Completion Failure
Indicates that a previous multi-step computing function initiated service request has failed before that service’s successful completion conditions were satisfied.
443
- 433 -
18.2.1
Call Information The Call Information event indicates that call associated information has been collected/updated for a call. Common situations that generate this event include: •
The account code or authorization code has been included or changed via a call control service request, or has been manually entered.
•
The Associate Data service has been used to associate information with a call.
•
User data or correlator data has been received independent of call activity (via the Send User Information service or as a result of non-call related activity from an external network).
•
CallerID information associated with the call has been updated.
•
Services permitted information has been updated as a result of another connection changing state.
•
Device information associated with a device in a call has been updated. Figure 18-7 Call Information Event BEFORE SERVICE
*
D1
C1
AFTER SERVICE
*
D1 (device)
D2
DEVICES D1 : device D2 : device in call C1
*
C1
*
D2
AFFECTED CONNECTIONS (none) CONNECTION STATES * : (unspecified/unaffected)
CALLS C1 : connection
Note that in some situations, there may only be one device (D1) in the call. 18.2.1.1 Event Parameters Table 18-27 Call Information—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
Indicates the connection of the device responsible for associating the information with the call.
device
SubjectDeviceID
M
Indicates the device responsible for associating the information with the call.
callingDevice 1
CallingDeviceID
C
Indicates the original calling device associated with the call
accountInfo 1
AccountInfo
C
Indicates the account code associated with the call.
authorisationCode 1
AuthCode
C
Indicates the authorization code associated with the call.
correlatorData 1
CorrelatorData
C
Indicates the correlator data associated with the call.
servicesPermitted 1
ServicesPermitted
C
Provides a list of services that can be applied to the specified connection.
userData 1
UserData
C
Provides information that has been sent from another device.
- 434 -
Table 18-27 Call Information—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
callQualifyingData1
CallQualifyingData
C
Indicates the call qualifying data (wrap code, walk away code, etc.) associated with the call.
connectionInfo1
ConnectionInformation
C
Indicates the connection information associated with the connection.
callLinkageDataList1
List
C
Specifies the global call data and thread data associated with the call. The parameter consists of the following components: • newCallLinkageData (M) CallLinkageData - specifies the call linkage data associated with the resulting call. • oldCallLinkageData (M) CallLinkageData - specifies the call linkage data that was discarded as the result of a feature. See Functional Requirement # 7.
callCharacteristics1
CallCharacteristics
C
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4 for the complete set of possible values.
subjectOfCall1
SubjectOfCall
C
Specifies the subject/intent associated with the call.
languagePreferences1
LanguagePreferences
C
Specifies the language preferences associated with the call.
deviceInfo
DeviceID
C
Specifies the device information (e.g. name) that has been associated with the connection.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information with the event.
1. At least one of these service specific parameters shall be provided on this event.
18.2.1.2 Functional Requirements 1. When either the accountInfo or callQualifyingData parameters is provided, the callID component of the connectionID in the event may be omitted or may refer to the connectionID that no longer exists at the device. This may occur when a user enters a wrap code for a call that has just cleared, for example. 2. This event is generated when the switching function receives user data independent of call activity as a result of the Send User Information service or as a result of non-call activity from an external network, for example. 3. This event is generated when correlator data is created or changed independently of a call control service. It is not generated when correlator data is passed with a Call Control service request (in this case, the new correlator data is presented to the computing function through the appropriate call control event). 4. This event is generated when connection information (number of media stream channels, for example) is changed independently of a call control service. It is not generated when connection information is passed with a Call Control service request (in this case, the new connection information is presented to the computing function through the appropriate call control event). 5. If the Associate Data service is used to associate data with a call, the Call Information event is generated.
- 435 -
6. If the list of CSTA services that can be applied to a connection changes as the result of another connection changing state, for example, the Call Information event is generated with the updated servicesPermitted parameter associated with the specified connection that did not change state. 7. The callLinkageDataList parameter is used to indicate that the callLinkageData associated with a call has been updated. See 6.1.2.7.4, “Synchronization of Call Linkage Data”, on page 48 for more information.
- 436 -
18.2.2
Charging The Charging event indicates that new call charging information (such as a network provided Periodic Pulse Metering (PPM) signal) has been detected for a device involved in a call. This event may occur after the call has been released, to report arrival of additional call charge information. Figure 18-8 Charging Event BEFORE SERVICE
C1
*
D1
AFTER SERVICE
*
D1 (chargedDevice)
D2
DEVICES D1 : chargedDevice D2 : device in call C1
*
C1
*
D2
CONNECTIONS D1C1 : connection CONNECTION STATES * : (unspecified/unaffected)
CALLS C1 : connection
18.2.2.1 Event Parameters Table 18-28 Charging—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
Indicates the call for which the device is being charged.
chargedDevice
DeviceID
M
Indicates the device that is being charged. If this device is not specified then this parameter indicates “Unknown” or “Not Required”.
chargingInfo
ChargingInfo
M
Indicates an intermediate or total value of charging or currency units for the device being charged.
cause
EventCause
O
Indicates a reason for the event.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information.
18.2.2.2 Event Causes Table 18-29 Charging—Event Causes Event Cause
Description
Associated Features
Network Signal
The event was generated as the result of a particular network event or condition.
External Call
Normal
Charging information has been detected.
External Call
Timeout
The event was generated because of a timeout.
External Call
18.2.2.3 Functional Requirements 1. The frequency with which this event is generated depends upon the implementation of the call charge information providing service outside the switching sub-domain. It also may depend upon the switching function implementation.
- 437 -
18.2.3
Digits Generated The Digits Generated event indicates that DTMF or rotary digits have been generated at a device. Common situations that generate this event include: •
The switching function generates DTMF or rotary digits for the device of a given connection as the result of the Generate Digits service or through manual activity. Figure 18-9 Digits Generated Event BEFORE SERVICE
D1
*
C1
AFTER SERVICE
*
D2
D1
DEVICES D1 : device in call C1 with device D2 D2 : device in call C1 with device D1 CALLS C1 : existing call
*
C1
*
D2
CONNECTIONS D1C1 : connection CONNECTION STATES * : (unspecified/unaffected)
18.2.3.1 Event Parameters Table 18-30 Digits Generated—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
The connection at the device
digitGeneratedList
Characters (64)
M
The sequence of digits generated. • For rotary digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D • For DTMF digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, *, #, A, B, C, D This parameter shall only include previously unreported digits.
digitDurationList
List of Values
O
The list of corresponding digit durations, in milliseconds for each generated digit.
pauseDurationList
List of Values
O
The list of corresponding pauses, in milliseconds, before each generated digit. The duration of the pause before the first digit is zero.
connectionInfo
ConnectionInformation
O
Specifies the connection information associated with the connection. If this parameter is not present, then the connection information is switching function specific.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
18.2.3.2 Functional Requirements 1. A Digits Generated event is sent when the device of the specified connection generates digits (via the Generate Digits service or through manual activity).
- 438 -
2. The Data Collection services (Clause 25, “Data Collection Services”) are used to report DTMF or rotary digits that are received over a connection at a device.
- 439 -
18.2.4
Telephony Tones Generated The Telephony Tones Generated event indicates that telephony tones have been generated at a device. Common situations that generate this event include: •
The switching function generates telephony tones (via the Generate Telephony Tones service, for example) for the device of a given connection. Figure 18-10 Telephony Tones Generated Event BEFORE SERVICE
D1
*
C1
AFTER SERVICE
*
D2
D1
DEVICES D1 : device in call C1 with device D2 D2 : device in call C1 with device D1
*
C1
*
CONNECTIONS D1C1 : connection CONNECTION STATES * : (unspecified/unaffected)
CALLS C1 : existing call
18.2.4.1 Event Parameters Table 18-31 Telephony Tones Generated—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
The connection at the device
- 440 -
D2
Table 18-31 Telephony Tones Generated—Event Parameters (concluded) Parameter Name toneGenerated
Type Enumerated
M/ O/C C
Description Specifies the generated tone. The complete set of possible values is: • beep • billing • busy • carrier • confirmation • dial • faxCNG • hold • howler • intrusion • modemCNG • park • record warning (indicates call may be being recorded) • reorder • ringback • silence • SIT VC • SIT IC • SIT RO • SIT NC • SwitchSpecified0 through SwitchSpecified100 reserved for switch specified tones. • other • unknown This parameter shall not be provided when a previously reported tone has stopped being generated.
toneFrequency
Value
O
Specifies (in Hz) the switching function determined frequency of the generated tone. This parameter shall not be provided if the toneGenerated is anything other than “other”.
toneDuration
Value
O
The duration, in milliseconds, of the tone. This parameter shall not be provided if the toneGenerated is anything other than “other”.
pauseDuration
Value
O
The pause, in milliseconds, between the last tone and this one. This parameter shall not be provided if the toneGenerated is anything other than “other”.
connectionInfo
ConnectionInformation
O
Specifies the connection information associated with the connection. If this parameter is not present, then the connection information is switching function specific.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 441 -
18.2.4.2 Functional Requirements 1. The Telephony Tones Generated event is sent when the device of the specified connection generates telephony tones (via the Generate Telephony Tones service). 2. When the generated telephony tone is no longer generated (due to the Cancel Telephony Tones service, for example) another Telephony Tones Generated event may be sent (if the switching function supports the generation of the event when a telephony tone is stopped) to indicate that the telephony tone is no longer being generated (with the toneGenerated parameter not provided). 3. The toneFrequency, toneDuration, and pauseDuration parameters can only be provided when the generatedTone is “other”. 4. The services described in Clause 25, “Data Collection Services” are used to report telephony tones that are received over a connection at a device.
- 442 -
18.2.5
Service Completion Failure
The Service Completion Failure event indicates that a previous multi-step computing function initiated service request (as indicated by the switching function in the capabilities exchange services) has failed before that service’s successful completion conditions were satisfied. 18.2.5.1 Event Parameters Table 18-32 Service Completion Failure—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
primaryCall
Structure
M
Specifies information for the connection in the primary call that is associated with the service request. This includes: • deviceID (M) DeviceID - a device involved in the call. • connectionID (M) ConnectionID - a connection at the device. • localConnectionState (M) LocalConnectionState the local connection state of the connection. • connectionInformation (O) ConnectionInformation the connection information for the connection.
secondaryCall
Structure
O
Specifies information for the connection in the secondary call that is associated with the service request. This includes: • deviceID (M) DeviceID - a device involved in the call. • connectionID (M) ConnectionID - a connection at the device. • localConnectionState (M) LocalConnectionState the local connection state of the connection. • connectionInformation (O) ConnectionInformation the connection information for the connection. This parameter may only be present if the service request involved a secondary call.
otherDevicesPrimaryCallList
List of Structures
O
Specifies information for each connection in the primary call. This includes: • deviceID (M) DeviceID - a device involved in the call. • connectionID (M) ConnectionID - a connection at the device. • localConnectionState (O) LocalConnectionState the local connection state of the connection. • connectionInformation (O) ConnectionInformation the connection information for the connection. This parameter may only be present if the other connections in the primary call still exist. This parameter may not contain the information associated with the primaryCall parameter.
- 443 -
Table 18-32 Service Completion Failure—Event Parameters (concluded) Parameter Name otherDevicesSecondary CallList
Type
M/ O/C
Description
List of Structures
O
Specifies information for each of the other connection in the secondary call. This includes: • deviceID (M) DeviceID - a device involved in the call. • connectionID (M) ConnectionID - a connection at the device. • localConnectionState (O) LocalConnectionState the local connection state of the connection. • connectionInformation (O) ConnectionInformation connection information for the connectionID. This parameter shall only be present if the service request involved a secondary call and the other connections associated with the secondary call still exist. This parameter shall not contain the information associated with the secondaryCall parameter.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call.
cause
EventCause
M
Indicates the reason why the service request did not complete.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information with the event.
18.2.5.2 Event Causes Table 18-33 Service Completion Failure—Event Causes Event Cause
Description
Associated Features
Blocked
The call failed after a device has disconnected from a call leaving one other device remaining in the call.
Service Request Failure
Busy
The call encountered a busy or unavailable device.
Service Request Failure
Call Cancelled
The call has been terminated before the associated device has gone on-hook.
Service Request Failure
Call Not Answered
The call was not answered because a timer elapsed.
Service Request Failure
Destination Not Obtainable
The call could not reach the destination.
Service Request Failure
Destination Out of Order
The call failed because it encountered a destination out of service.
Service Request Failure
Do Not Disturb
The call failed because it encountered a device that has the do not disturb feature set.
Service Request Failure
Incompatible Destination
The call encountered an incompatible destination.
Service Request Failure
Invalid Account Code
The call has an invalid account code.
Service Request Failure
Invalid Number Format
The call failed because the dialled number is incorrect
Service Request Failure
Key Operation in Use
The call failed because an appearance is associated with an exclusive bridged device configuration and that the appearance is disabled until the call is terminated or until the call moves away from the device.
Service Request Failure
Lockout
The call encountered inter-digit time-out while dialling.
Service Request Failure
Maintenance
The call encountered a facility or device in a maintenance condition.
Service Request Failure
- 444 -
Table 18-33 Service Completion Failure—Event Causes (concluded) Event Cause
Description
Associated Features
Network Congestion
The call encountered a congested network.
Service Request Failure
Network Not Obtainable
The call could not reach a destination network.
Service Request Failure
Network Signal
The call failed because it encountered a problem after it left the switching sub-domain.
Service Request Failure
No Available Agents
The call could not access any agent.
Service Request Failure
Not Available Bearer Service
The call failed because it was requested with a bearer capability that is currently not available.
Service Request Failure
Not Supported Bearer Service
The call failed because it was requested with a bearer capability that is currently not supported.
Service Request Failure
Number Changed
The called number has been changed to a new number.
Service Request Failure
Number Unallocated
The call failed because the called number is not allocated to a subscriber.
Service Request Failure
Reorder Tone
The call encountered a reorder condition.
Service Request Failure
Resources not Available
Resources were not available.
Service Request Failure
Selected Trunk Busy
The call failed because a specific selected Network Interface Device (e.g., trunk, CO line) is busy.
Service Request Failure
Trunks Busy
The call encountered Trunks Busy.
Service Request Failure
Unauthorized Bearer Service
The call failed because it was requested with an unauthorized bearer capability.
Service Request Failure
18.2.5.3 Functional Requirements 1. This event is only reported to device-type monitors on the device which has or had connection(s) that were used in the particular service request which is associated with this event (i.e., this event is not reported to any call-type monitors or device-type monitors for other devices in the call(s) associated with the service request). 2. If the switching function supports this event, it shall be provided on all multi-step service requests (supported by the switching function) if the completion conditions is not successfully met. 3. The Service Completion Failure event shall not be provided by the switching function to indicate a connection’s transition to the Fail state. A Failed event shall be provided to indicate this. 4. If event flow, prior to receiving the Service Completion Failure event, has indicated that the service request has caused a state change, it is up to the computing function to apply the appropriate service(s) to return the call(s) and/or device(s) back to their original conditions (if needed and possible).
- 445 -
19
Media Attachment Services & Events This clause describes services and events which enable access to the media stream of a call through attachment and detachment of media services to the call.
19.1
Services Table 19-1 Media Attachment Services Summary Media Attachment Service
Description
Pg.
19.1.1 Attach Media Service
Attaches a media service instance to a call.
447
19.1.2 Detach Media Service
Detaches a media service instance from a call.
451
- 446 -
19.1.1
Attach Media Service
C
S
The Attach Media Service service attaches an existing call to a media service instance for the purpose of transmitting media stream data to the call or receiving media stream data from the call. The attachment is made at a connection associated with a media access device (MAD). The attachment may be performed by the switching function selecting a MAD and adding it to the call by means of a call control service(s) (e.g., Conference Call, Transfer Call, Deflect Call, Directed Pickup Call, Join Call), or may be performed via a device already in the call (that has media access capabilities). At the completion of this service request a Media Attached event is generated on monitors associated with the specified call or device. This event may contain the associated mediaStreamID for accessing the media service instance. The service request specifies a media service instance by choosing appropriate values for the mediaServiceType and mediaServiceInstanceID parameters, and a connectionMode parameter that specifies how the attachment is to be made. The roles played by the various devices in the call, and the means by which the attachment is performed, depend upon the connectionMode. The connectionMode consists of a set of values that specify the call control service(s) that is to be applied to the connection so that the MAD can be added to the call, or the value of direct, which specifies that the MAD is already part of the call. Refer to the specification of the call control service(s) associated with the specified connectionMode for a description of the operational model. 19.1.1.1 Service Request Table 19-2 Attach Media Service—Service Request Parameter Name
Type
M/ O/C
Description
connection
ConnectionID
M
Specifies the connection at the attaching device.
mediaServiceType
MediaServiceType
M
Specifies the requested media service type.
mediaServiceVersion
Value
O
Specifies the version of the media services.
mediaServiceInstanceID
MediaServiceInstanceID
O
Specifies the desired media service instance.
- 447 -
Table 19-2 Attach Media Service—Service Request (concluded) Parameter Name connectionMode
Type Enumerated
M/ O/C
Description
M
Specifies the requested media service connection mode. The complete set of possible values is: • consultationConference - conference the media access device (MAD) into the call via the Consultation Call and Conference Call models. • consultationConferenceHold - conference the MAD into the call via a Consultation Call and Hold Call models (the connection at the attaching device is placed on hold). • deflect - move the call from the attaching device to the MAD via the Deflect Call model. • directedPickup - direct the call from the attaching device to the MAD via the Directed Pickup Call model. • join - add a device into the call via the Join Call model. The application chooses which device is the MAD in the resulting conference. • singleStepConference - conference the MAD into the call via the Single Step Conference Call models. • singleStepConferenceHold - conference the MAD into the call via a Single Step Conference Call and Hold Call models (the connection at the attaching device is placed on hold). • singleStepTransfer - transfer that MAD into the call via the Single Step Transfer Call model. • transfer - transfer the MAD into the call via the Consultation Call and Transfer Call models. • direct - bind the media service instance directly to the existing connection at the attaching device.
requestedConnectionState
LocalConnectionState
O
Specifies the connection state in which the MAD shall be at the time that the Media Attached event is generated.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
19.1.1.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 448 -
19.1.1.2.1 Positive Acknowledgement Table 19-3 Attach Media Service—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
mediaConnection
ConnectionID
C
Specifies the connection at the media access device.
mediaDevice
DeviceID
C
Specifies the device identifier of the media access device.
See Functional Requirement #7.
See Functional Requirement #7. mediaServiceInstanceID
MediaServiceInstanceID
O
Specifies the media service instance used.
mediaConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the mediaConnection connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
O
Specifies the global call data and thread data associated with the call. See Functional Requirement #7.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
19.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 19.1.1.3 Operational Model 19.1.1.3.1 Connection State Transitions
Refer to the specification of the call control service(s) associated with the specified connectionMode for a description of the connection state transitions. 19.1.1.3.2 Device-Type Monitoring Event Sequences Table 19-4 Attach Media Service—Device-Type Monitoring Event Sequences Monitored Device (media access device)
(other devices in the call)
Connection
Event
Event Cause
DxCx
Call Control events depend upon the connectionMode parameter.
DxCx
Media Attached
DxCx
Call Control events depend upon the connectionMode parameter.
DxCx
Media Attached
(not applicable)
(not applicable)
19.1.1.3.3 Call-Type Monitoring Event Sequences Table 19-5 Attach Media Service—Call-Type Monitoring Event Sequences Monitored Call Cx
Connection
Event
Event Cause
DxCx
Call Control events depend upon the connectionMode parameter.
DxCx
Media Attached
(not applicable)
Note that the Media Attached event may be generated before other call control events associated with adding the media access device to the call.
- 449 -
19.1.1.3.4 Functional Requirements
1. If the computing function is monitoring the call or any devices in the call, it shall be prepared to receive the call control events, if any, associated with adding the media access device to the call (e.g., Conferenced, Transferred, Held) events. 2. The specification of the call control service(s) (service description, operational model, functional requirements, etc.) that are described by the connectionMode parameter apply to the Attach Media service. 3. Multiple attachments to media services for the same call and connection are possible. However, implementations may place limits on the number of such attachments. Each additional attachment may or may not involve a conference/transfer operation (as in the case of the first attachment). If the computing function tries to attach a mediaServiceType to a connection that already has that mediaServiceType attached, the request will be rejected by the switching function. 4. Authentication with the media service is not implied by a positive acknowledgement to an Attach Media Service service request. The computing function shall open a session to and authenticate to the media service through the appropriate mechanisms. 5. Versioning of the media service is supported via a separate mediaServiceVersion parameter. With respect to this service, however, different versions of a media service are treated as if they were different media services. 6. The switching function may place restrictions on the services that may be applied to a media access device. As a result, the computing function should always use the Detach Media Service service to release the binding of the media service instance from the call rather than trying to manipulate the media access device directly using other call control services. 7. mediaConnection, callLinkageData and mediaDevice shall not be provided if the connectionMode parameter in the service request is direct.
- 450 -
19.1.2
Detach Media Service
C
S
The Detach Media Service service removes a previously attached media service instance from a call. This request releases a previously established association (binding) between a connection and a media service. If a media access device was added to the call when the media service instance was attached and that media access device is no longer needed, then the media access device is removed (i.e., cleared) from the call. There are two cases for the Detach Media Service service request: •
Case A: A media access device (D3) was previously connected into the call using the Attach Media Service service. In this case the media access device is removed from the call by this service. Figure 19-1 is an example where a media access device that was conferenced into a call is detached from a call. Figure 19-1 Detach Media Service (Case A) BEFORE SERVICE
D1
C1
*
D3 (media access device)
AFTER SERVICE
*
D2 (other device)
a, c, h, q, f
D1
*
*
D2
D3
AFFECTED CONNECTIONS D3C1 : media connection
DEVICES D1 : attaching device D2 : other device in call C1 D3 : media access device
CONNECTION STATES a : alerting state c : connected state h : hold state q : queued state f : fail state * : (unspecified/unaffected)
CALLS C1 : existing call (connection)
•
C1
Case B: The media service instance was directly bound to an existing connection (D1C1) in the call. In this case this detaching device remains in the call after the service request. Figure 19-2 Detach Media Service (Case B) BEFORE SERVICE
D1 (detaching device)
*
C1
AFTER SERVICE
*
DEVICES D1 : detaching device D2 : other device in call C1 CALLS C1 : connection (existing call)
- 451 -
D2 (other device)
D1
*
C1
*
D2
AFFECTED CONNECTIONS D1C1 : detaching connection (existing media connection) CONNECTION STATES * : (unspecified/unaffected)
19.1.2.1 Service Request Table 19-6 Detach Media Service—Service Request Parameter Name
Type
M/ O/C
Description
connection
ConnectionID
M
Specifies the connection at the media access device, if used. Otherwise, specifies the connection at the detaching device.
mediaServiceType
MediaServiceType
M
Specifies the requested media service type to detach.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
19.1.2.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 19.1.2.2.1 Positive Acknowledgement Table 19-7 Detach Media Service—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
19.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 19.1.2.3 Operational Model 19.1.2.3.1 Connection State Transitions
The following tables describes the connections that are affected by this service. •
Case A: A previously added media access device (D3) is removed from the call. Table 19-8 Detach Media Service—Connection State Transitions (Case A) Connection
•
Initial State (Required)
Final State
D1C1
(Ignored)
(Unaffected; no transition due to this service)
D2C1
(Ignored)
(Unaffected; no transition due to this service)
D3C1 (media connection)
Alerting, Connected, Hold, Queued, Fail
Null
Case B: The media service instance is unbound from a detaching device (D1) in the call. Table 19-9 Detach Media Service—Connection State Transitions (Case B) Connection
Initial State (Required)
Final State
D1C1
(Ignored)
(Unaffected; no transition due to this service)
D2C1
(Ignored)
(Unaffected; no transition due to this service)
- 452 -
19.1.2.3.2 Device-Type Monitoring Event Sequences
The following table describes the connections that are affected by this service. •
Case A: A previously added media access device (D3) is removed from the call. Table 19-10 Detach Media Service—Device-Type Monitoring Event Sequences (Case A) Monitored Device D1
D2
D3 (media access device)
•
Connection
Event
Event Cause
D3C1
Media Detached
(not applicable)
D3C1
Connection Cleared
Normal Clearing
D3C1
Media Detached
(not applicable)
D3C1
Connection Cleared
Normal Clearing
D3C1
Media Detached
(not applicable)
D3C1
Connection Cleared
Normal Clearing
Case B: The media service instance is unbound from a detaching device (D1) in the call. Table 19-11 Detach Media Service—Device-Type Monitoring Event Sequences (Case B) Monitored Device
Connection
Event
Event Cause
D1 (detaching device)
D1C1
Media Detached
(not applicable)
D2 (other device)
D1C1
Media Detached
(not applicable)
19.1.2.3.3 Call-Type Monitoring Event Sequences
•
Case A: A previously added media access device (D3) is removed from the call. Table 19-12 Detach Media Service—Call-Type Monitoring Event Sequences (Case A) Monitored Call C1
•
Connection
Event
Event Cause
D3C1
Media Detached
(not applicable)
D3C1
Connection Cleared
Normal Clearing
Case B: The media service instance is unbound from a detaching device (D1) in the call. Table 19-13 Detach Media Service—Call-Type Monitoring Event Sequences (Case B) Monitored Call C1 (existing call)
Connection D1C1
Event Media Detached
- 453 -
Event Cause (not applicable)
19.2
Events Table 19-14 Media Attachment Events Summary Media Attachment Event
Description
Pg.
19.2.1 Media Attached
Indicates that a media service instance has been attached to a call.
455
19.2.2 Media Detached
Indicates that a media service instance has been detached from a call.
456
- 454 -
19.2.1
Media Attached The Media Attached event indicates an attachment of media services to a call. This event may be generated as a result of a previous Attach Media Service service request, or as a result of an automatic media service attachment.
Refer to the specification of the call control services(s) and resulting call control events(s) associated with the specified connectionMode for a description of the operational model. 19.2.1.1 Event Parameters Table 19-15 Media Attached—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
mediaConnection
ConnectionID
M
Specifies the connection that was bound to the media service.
mediaDevice
SubjectDeviceID
M
Specifies the device identifier associated with the attached media service.
mediaServiceType
MediaServiceType
M
Specifies the media service type.
mediaServiceVersion
Value
O
Specifies the version of the media services.
mediaServiceInstanceID
MediaServiceInstanceID
O
Specifies the media service instance associated with the attached media service.
mediaStreamID
MediaStreamID
C
Specifies the Media stream ID used to access the media service. This parameter shall be provided if the switching function supports providing the mediaStreamID as indicated by the capability exchange services.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.15, “MediaCallCharacteristics”, on page 113 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
localConnectionInfo
LocalConnectionState
C
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. This parameter is mandatory for events generated for device-type monitors and otherwise shall not be provided.
mediaConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the mediaConnection connection. If this parameter is not present, then the connection information is switching function specific.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
19.2.1.2 Functional Requirements 1. If a media access device was added to the call as a result of a successful Attach Media Service service request, then the mediaConnection and mediaDevice parameters refer to the media access device. If the media service instance was directly bound to an existing connection in the call, then the mediaConnection and mediaDevice parameters refer to the connection at that attaching device.
- 455 -
19.2.2
Media Detached The Media Detached event indicates a detachment of media services from a connection. This event may be generated as a result of a previous Detach Media Service service request, or as a result of an automatic media service detachment. There are two cases for the Media Detached event: •
Case A: A media access device (D3) was previously connected into the call using the Attach Media Service service. In this case the media access device is removed from the call by this service.
•
Case B: The media service instance was directly bound to an existing connection (D1C1) in the call. In this case this detaching device remains in the call after the service request. Figure 19-3 Media Detached Event (Case A) BEFORE EVENT
D1
D3
C1
*
AFTER EVENT
D2
*
D1
C1
*
*
D2 (other device)
D3 (media access device)
a, c h, q, f
DEVICES D1 : attaching device D2 : other device in call C1 D3 : media access device
AFFECTED CONNECTIONS D3C1 : mediaConnection CONNECTION STATES h : hold state c : connected state q : queued state f : fail state a : alerting state n : null * : (unspecified/unaffected)
CALLS C1 : mediaConnection (existing call)
Figure 19-4 Media Detached Event (Case B) BEFORE EVENT
D1
*
C1
AFTER EVENT
D1
D2
*
(detaching device)
C1
*
*
D2 (other device)
AFFECTED CONNECTIONS D1C1 : mediaConnection
DEVICES D1 : detaching device D2 : other device in call C1
CONNECTION STATES CALLS C1 : mediaConnection (existing call)
* : (unspecified/unaffected)
19.2.2.1 Event Parameters Table 19-16 Media Detached—Event Parameters Parameter Name monitorCrossRefID
Type
M/ O/C
MonitorCrossRefID
M
- 456 -
Description Associates the event to an established monitor.
Table 19-16 Media Detached—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
mediaConnection
ConnectionID
M
Specifies the connection that was unbound from the media service.
mediaDevice
SubjectDeviceID
M
Specifies the device identifier associated with the detached media service.
mediaServiceType
MediaServiceType
M
Specifies the media service type detached.
mediaServiceVersion
Value
O
Specifies the version of the media services.
mediaServiceInstanceID
MediaServiceInstanceID
O
Specifies the media service instance associated with the detached media service.
mediaStreamID
MediaStreamID
C
Specifies the Media stream ID associated with the media service that was detached. This parameter shall be provided if the switching function supports providing the mediaStreamID as indicated by the capability exchange services.
mediaCallCharacteristics
MediaCallCharacteristics
O
Specifies the media class and media characteristics of the call. See 12.2.15, “MediaCallCharacteristics”, on page 113 for the complete description.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4, “CallCharacteristics”, on page 114 for the complete set of possible values.
localConnectionInfo
LocalConnectionState
C
Specifies the local connection state of the device associated with the Monitor Cross Reference ID. This parameter is mandatory for events generated for device-type monitors and otherwise shall not be provided.
mediaConnectionInfo
ConnectionInformation
O
Specifies the connection information associated with the mediaConnection connection. If this parameter is not present, then the connection information is switching function specific.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
19.2.2.2 Functional Requirements 1. If a media access device was added to the call as a result of a successful Attach Media Service, then the mediaConnection and mediaDevice parameters refer to the media access device. If the media service instance was directly bound to an existing connection in the call, then the mediaConnection and mediaDevice parameters refer to the connection at the attaching device. 2. The switching function may initiate a media service detachment whenever it is unable to maintain the binding of the connection to the media service. This may occur as a result of other activity on the call.
- 457 -
20
Routeing Services This section specifies two types of Routeing services: •
Route Registration services
•
Call Routeing services
NOTE This clause describes Routeing services between the Switching Function and the Computing Function.
20.1
Registration Services Table 20-1 Route Registration Services Summary Route Registration Service
Description
Pg.
20.1.1 Route Register
Registers the computing function as a routeing server for a specified routeing device or for the entire switching function.
459
20.1.2 Route Register Abort
Specifies that the switching function has terminated a routeing server registration.
462
20.1.3 Route Register Cancel
Unregisters the computing function as a routeing server.
463
- 458 -
20.1.1
Route Register
C
S
The Route Register service is used to register the computing function as a routeing server for a specific routeing device or as a routeing server for all routeing devices within the switching sub-domain. The computing function may be required to register for routeing services before it can receive any route requests for a routeing device from the switching function. A computing function may register to be the routeing server for more than one routeing device. 20.1.1.1 Service Request Table 20-2 Route Register—Service Request Parameter Name
Type
M/ O/C
Description
routeingDevice
DeviceID
C
Specifies the routeing device for which the computing function requests to be the routeing server. This parameter is mandatory if the switching function does not support the option of registering for all routeing devices in the switching sub-domain. Otherwise, the parameter is optional and if not present, indicates the registration is to be for all routeing devices in the switching sub-domain.
requestedRouteingMediaClass
Bitmap
O
Specifies the media classes of calls that are being requested to be routed.
See Functional Requirement #2.
Refer to the mediaClass component in 12.2.15, “MediaCallCharacteristics”, on page 113 for the complete set of possible values. Note that multiple bits may be set. If this parameter is not provided (or if the parameter is not supported by the switching function), it is switching function dependent which types of media calls are routed. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
20.1.1.2 Service Response This service follows the atomic acknowledgement model for this service request.
- 459 -
20.1.1.2.1 Positive Acknowledgement Table 20-3 Route Register—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
routeRegisterReqID
RouteRegisterReqID
M
Specifies the routeing registration request identifier for this registration.
actualRouteingMediaClass
Bitmap
C
This parameter specifies the actual media classes of calls that are routed by the switching function for routeing registration. The actual media classes of calls routed may be the same or a subset of what was requested on the service request. If this parameter is supported by the switching function, it may be omitted if the requested and actual routeing media class parameters are the same otherwise it shall be provided. If the parameter is not supported by the switching function, then the switching function does not filter media classes for calls for specific routeing registrations. The capability exchange services indicates the media classes of calls that can be routed.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
20.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 20.1.1.3 Operational Model 20.1.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 20.1.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.1.1.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.1.1.3.4 Functional Requirements
1. The routeRegisterReqID parameter returned in the positive acknowledgement is used to identify the registration over which routeing requests will be sent. All routeing dialogues for the routeing device occur over this routeing registration. The routeRegisterReqID is also used when cancelling the routeing registration. 2. If the routeingDevice parameter on the service request is not provided and this option is supported, then the registration request is for all routeing devices within the switching sub-domain. If the switching function sends a positive acknowledgement to this request, the routeing server will receive route requests generated for all routeing devices within the switching sub-domain. Some switching function implementations may not support the capability to register for all routeing devices with a single Route Register request (i.e., with the routeingDevice parameter not provided), in which case the switching function will send a negative acknowledgement to the Route Register request. The capabilities exchange services can be used by the computing function to determine if registering for all routeing devices within the switching sub-domain is supported. 3. The number of simultaneous registrations allowed for the same routeing device is switching function dependent. Some switching functions may limit this number to one, in which case only one registration per routeing device is allowed. When the limit is reached, subsequent route register - 460 -
requests for the same routeing device will result in negative acknowledgements from the switching function.
- 461 -
20.1.2
Route Register Abort
S
C
This service is used by the switching function to asynchronously cancel an active routeing registration. This service invalidates a current routeing registration. There is no positive acknowledgement defined for this service. 20.1.2.1 Service Request Table 20-4 Route Register Abort—Service Request Parameter Name
Type
M/ O/C
Description
routeRegisterReqID
RouteRegisterReqID
M
Specifies the routeing registration request identifier for the routeing registration that was aborted.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
20.1.2.2 Service Response There are no service completion conditions for this service. 20.1.2.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service. 20.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 20.1.2.3 Operational Model 20.1.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 20.1.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.1.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.1.2.3.4 Functional Requirements
1. The switching function may issue this service at any time when it can no longer maintain the routeing registration (e.g., when the associated routeing device goes out of service).
- 462 -
20.1.3
Route Register Cancel
C
S
The Route Register Cancel service is used to cancel a previous route registration. This request terminates the routeing registration and the computing function receives no further routeing requests for that routeing registration once it receives the positive acknowledgement to the Route Register Cancel request. 20.1.3.1 Service Request Table 20-5 Route Register Cancel—Service Request Parameter Name
Type
M/ O/C
Description
routeRegisterReqID
RouteRegisterReqID
M
Specifies the routeing registration request identifier for which the routeing registration is to be cancelled.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
20.1.3.2 Service Response This service follows the atomic acknowledgement model for this service request. 20.1.3.2.1 Positive Acknowledgement Table 20-6 Route Register Cancel—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
20.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 20.1.3.3 Operational Model 20.1.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 20.1.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.1.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.1.3.3.4 Functional Requirements
1. The computing function shall continue to process outstanding routeing requests from the routeing device until it receives a positive acknowledgement for the Route Register Cancel service request. The switching function will not send any further route requests for a registration once it has sent the positive acknowledgement.
- 463 -
20.2
Services Table 20-7 Call Routeing Services Summary Routeing Services
Description
Pg.
20.2.1 Re-Route
This service requests an alternate destination from the one provided by a previous Route Select service and based on previous information provided for the call.
465
20.2.2 Route End
This service ends a routeing dialogue.
467
20.2.3 Route Reject
This service is sent to the switching function during a routeing dialogue to indicate that a call should be returned to the network for alternate routeing.
469
20.2.4 Route Request
This service requests that the computing function provides a destination for a call. To aid in the selection of a destination, the service request includes the current destination and may include additional information.
471
20.2.5 Route Select
This service is used by the computing function to provide the destination requested by a previous Route Request or Re-Route request.
474
20.2.6 Route Used
This service provides 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.
476
- 464 -
20.2.1
Re-Route
S
C
The Re-Route service requests an alternate destination from the one provided by a previous Route Select service and based on previous information provided for the call. 20.2.1.1 Service Request Table 20-8 Re-Route—Service Request Parameter Name
Type
M/ O/C
Description
crossRefIdentifier
RouteingCrossRefID
M
Specifies the cross reference identifier associated with the routeing dialogue.
routeRegisterReqID
RouteRegisterReqID
C
Specifies the route register request identifier associated with the route registration for this routeing dialogue. See Functional Requirement #2.
replyTimeout
Value
O
Specifies the amount of time (in milliseconds) that the switching function will wait for a reply from the computing function, before it proceeds with default routeing for the call. If the parameter is not present or the value is 0, the amount of time is switching function specific.
correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call (and if the parameter is supported).
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
20.2.1.2 Service Response There are no service completion conditions for this service. 20.2.1.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service. 20.2.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 20.2.1.3 Operational Model 20.2.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 20.2.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.2.1.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.2.1.3.4 Functional Requirements
1. The requested route is sent from the computing function to the switching function by the Route Select service. The switching function shall use the routeingCrossRefID and routeRegisterReqID (if supported) parameters from the initial Route Request service to link this service to the others that are used to provide a route. 2. The routeRegisterReqID parameter is mandatory if the switching function supports route registration, and shall not be provided otherwise.
- 465 -
3. If the number of remaining retries (remainRetries parameter) is not provided by the computing function in the Route Select service, the computing function should be prepared to respond to all ReRoute service requests or terminate the routeing dialogue by using the Route End service when it cannot provide additional destinations.
- 466 -
20.2.2
Route End
C
S
The Route End service ends a routeing dialogue. This service is bi-directional (i.e., it may be invoked by the switching function or the computing function). The computing function can use the Route End service when it cannot provide a route for a call. Typically, this can occur if: •
The computing function receives a valid routeing request for a call without sufficient call information and it cannot determine a routeing destination.
•
The computing function has already provided all available destinations for a call and no more alternate destinations are available.
•
The computing function does not have access to a database necessary to route the call.
In these cases, the computing function uses the Route End service to inform the switching function that it cannot provide a route for the call in question. The Route End service request will terminate the routeing dialogue (routeingCrossRefID) for the call. The Route End request does not clear the call. The switching function will continue to process the call using whatever default routeing algorithm is available (i.e., in a switching function specific way). The switching function uses the Route End service when it ends a routeing dialogue. Typically, this can occur if: •
The call associated with the routeing cross reference identifier has been successfully routed. This may occur when the computing function has sent a Route Select service request and the switching function has successfully routed the call.
•
The calling party has abandoned a call associated with the routeing cross reference identifier.
•
The switching function timeout for a route request response has expired. This may occur if the computing function did not respond to a Route Request or Re-Route Request service within a switching function defined period.
•
The switching function has ended a routeing dialogue due to internal resource (or other) problems.
20.2.2.1 Service Request Table 20-9 Route End—Service Request Parameter Name
Type
M/ O/C
Description
crossRefIdentifier
RouteingCrossRefID
M
Specifies the cross reference identifier associated with the routeing dialogue.
routeRegisterReqID
RouteRegisterReqID
C
Specifies the route register request identifier associated with the route registration for this routeing dialogue. See Functional Requirement #3.
errorValue
ErrorValue
O
Specifies the reason for the route end request (see 12.2.14, “ErrorValue”, on page 121 for more information on this parameter).
correlatorData
CorrelatorData
C
Specifies correlator data. See Functional Requirement #4.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
20.2.2.2 Service Response There are no service completion conditions for this service.
- 467 -
20.2.2.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service. 20.2.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 20.2.2.3 Operational Model 20.2.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 20.2.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.2.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.2.2.3.4 Functional Requirements
1. The computing function can use this service to respond to either a Route Request or a Re-Route service request. 2. The routeingCrossRefID and routeRegisterReqID (if supported) parameters from the initial Route Request service shall be used to link this service to the others that are used to provide a route. 3. The routeRegisterReqID parameter is mandatory if the switching function supports route registration, and shall not be provided otherwise. 4. The correlatorData parameter meaning is dependent upon the direction of the service request. •
if the Route End service request is sent from the Switching Function to the Computing Function then the parameter specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call (and if the parameter is supported).
•
if the Route End service request is sent from the Computing Function to the Switching Function then the parameter specifies the correlator data to associate with the call.
- 468 -
20.2.3
Route Reject
C
S
The Route Reject service request is sent to the switching function during a routeing dialogue to indicate that a call should be returned to the originating network (the network from where the call entered the switching sub-domain where the routeing request was issued from) for alternate routeing. 20.2.3.1 Service Request Table 20-10 Route Reject—Service Request Parameter Name
Type
M/ O/C
Description
crossRefIdentifier
RouteingCrossRefID
M
Specifies the cross reference identifier associated with the routeing dialogue.
routeRegisterReqID
RouteRegisterReqID
C
Specifies the route register request identifier associated with the route registration for this routeing dialogue. See Functional Requirement #3.
rejectCause
Enumerated
O
Specifies the reason why call should be returned to the originating network for alternate routeing. The complete set of possible values is: • BusyOverflow - all possible destinations for the call are busy or unavailable and there is no queueing mechanism (ACD, for example) available. • QueueTimeOverflow - all possible destinations for the call are busy or unavailable and the estimated holding time before an agent is able to answer the call is too long. • CapacityOverflow - all possible destinations are busy or unavailable and the call cannot be queued because the system is already at capacity. • CalendarOverflow - all possible calendar based destinations for the call are unavailable because of the time of the day or the day of the week. • UnknownOverflow - the computing function is unable to be more specific. See Functional Requirement #4.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
20.2.3.2 Service Response There are no service completion conditions for this service. 20.2.3.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service. 20.2.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 20.2.3.3 Operational Model 20.2.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 20.2.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.2.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 469 -
20.2.3.3.4 Functional Requirements
1. The computing function should issue the Route Reject service only in response to a Route Request or Re-Route Request from the switching function. 2. The routeingCrossRefID and routeRegisterReqID (if supported) parameters from the initial Route Request service shall be used to link this service to the others that are used to provide a route. 3. The routeRegisterReqID parameter is mandatory if the switching function supports route registration, and shall not be provided otherwise. 4. The rejectCause parameter provides additional information why the computing function is requesting that the switching function return the call to the originating network (the network from where the call entered the switching sub-domain where the routeing request was issued from) for alternate routeing. This information can be used by the switching function and/or passed to the originating network via network signalling protocols.
- 470 -
20.2.4
Route Request
S
C
The Route Request service requests that the computing function provide a destination for a call. To aid in the selection of a destination, the service request includes the current destination and may include additional information. 20.2.4.1 Service Request Table 20-11 Route Request—Service Request Parameter Name
Type
M/ O/C
Description
crossRefIdentifier
RouteingCrossRefID
M
Specifies the cross reference identifier associated with the routeing dialogue.
routeRegisterReqID
RouteRegisterReqID
C
Specifies the route register request identifier associated with the route registration for this routeing dialogue. See Functional Requirement #3.
currentRoute
CalledDeviceID
M
Specifies the current destination of the call for which a route is requested.
callingDevice
CallingDeviceID
O
Specifies the originator of the call.
routeingDevice
SubjectDeviceID
O
Specifies the device that initiated the Route Request service.
routedCall
ConnectionID
C
Specifies the ConnectionID of the call. This parameter is mandatory if the route request is call related. If the request is not call-related, then this parameter shall not be provided.
routeSelAlgorithm
Enumerated
O
Specifies the type of routeing algorithm requested. The complete set of possible values is: • ACD • Emergency • Least Cost • Normal • User Defined
associatedCallingDevice
AssociatedCallingDeviceID
C
Specifies the Network Interface Device associated with the calling device if the call is an external incoming call. This parameter is mandatory for all external incoming calls and shall not be provided otherwise.
associatedCalledDevice
AssociatedCalledDeviceID
C
For outgoing external calls, this parameter specifies the Network Interface Device associated with the originally called device. For incoming external calls, this parameter specifies a device within the switching sub-domain associated with the originally called device. This parameter is mandatory for all external outgoing calls and it is optional for external incoming calls.
priority
Boolean
O
Specifies the call priority. This may affect the selection of alternative routes. The complete set of possible values is: • True - Priority call. • False - Non-priority call.
replyTimeout
Value
O
- 471 -
Specifies the amount of time (in milliseconds) that the switching function will wait for a reply from the computing function, before it proceeds with default routeing for the call. If the parameter is not present or the value is 0, the amount of time is switching function specific.
Table 20-11 Route Request—Service Request (concluded) Parameter Name
Type
M/ O/C
Description
correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call (and if the parameter is supported).
mediaCallCharacteristics
MediaCallCharacteristics
O
This specifies the media class (voice, digital data, etc.) and characteristics of the call. If this parameter is not present (and the parameter is supported) then the call is a voice call.
callCharacteristics
CallCharacteristics
O
Specifies the high level characteristics (ACD call, Priority call, etc.) associated with the call. See 12.2.4 for complete the set of possible values.
routedCallInfo
ConnectionInformation
O
Specifies the connection information associated with the routedCall connection. If this parameter is not present, then the connection information is switching function specific.
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
subjectOfCall
SubjectOfCall
O
Specifies the subject/intent associated with the call. This could represent the subject header of an Email (text call) or intent for a voice call, for example.
messageInfo
MessageInfo
O
Specifies the contents of message information associated with a call. The message information consists of one of more items.
languagePreferences
LanguagePreferences
O
Specifies the language preferences associated with the call.
deviceHistory
DeviceHistory
O
Specifies the list of devices which were previously associated with the call (e.g. redirecting, transferring, clearing devices).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
20.2.4.2 Service Response There are no service completion conditions for this service. 20.2.4.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service. 20.2.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 20.2.4.3 Operational Model 20.2.4.3.1 Connection State Transitions
There are no connection state changes due to this service. 20.2.4.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.2.4.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.2.4.3.4 Functional Requirements
1. The requested route is sent from the computing function to the switching function by the Route Select service. - 472 -
2. The switching function generates the routeingCrossRefID to link this service to the others that are used to provide a route. 3. The routeRegisterReqID parameter is mandatory if the switching function supports route registration, and shall not be provided otherwise. If the routeRegisterReqID parameter is not present, then the routeingCrossRefID shall be unique across the entire switching sub-domain.
- 473 -
20.2.5
Route Select
C
S
The Route Select service is used by the computing function to provide the destination requested by a previous Route Request or Re-Route service. 20.2.5.1 Service Request Table 20-12 Route Select—Service Request Parameter Name
Type
M/ O/C
Description
CrossRefIdentifier
RouteingCrossRefID
M
Specifies the cross reference identifier associated with the routeing dialogue.
routeRegisterReqID
RouteRegisterReqID
C
Specifies the route register request identifier associated with the route registration for this routeing dialogue. See Functional Requirement #3.
routeSelected
DeviceID
M
Specifies the primary selected destination of the call for which a route was requested.
alternateRoutes
List of DeviceIDs
O
Specifies the list of alternate destinations (in priority order) which are to be used sequentially for routeing the call if the primary selected destination initially (i.e., the routeSelected parameter) or a previous entry in the list is not valid or available.
remainRetries
Choice Structure
O
Specifies either the number of alternative routes remaining or the reason why the computing function is not providing it. This shall consist of one of the following choices: •
noListAvailable (Boolean) - indicates if the computing function does not maintain a fixed list of alternate routes: •
TRUE - the computing function does not maintain a list.
•
FALSE - the computing function does maintain a list.
• noCountAvailable (Boolean) - indicates if the computing function does not maintain or cannot provide a count of the remaining routes to try:
•
•
TRUE - the computing function does not maintain or cannot provide a count.
•
FALSE - the computing function does maintain a count.
retryCount (Value) - indicates the actual number of alternative routes remaining.
See Functional Requirement #4 for more information on this parameter. routeUsedReq
Boolean
O
Specifies whether the switching function should issue the Route Used service when it has accepted a route. • True - Route Used service should be issued. • False - Route Used service should not be issued.
correlatorData
CorrelatorData
O
Specifies the correlator data to associate with the call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
20.2.5.2 Service Response There are no service completion conditions for this service. - 474 -
20.2.5.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service. 20.2.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 20.2.5.3 Operational Model 20.2.5.3.1 Connection State Transitions
There are no connection state changes due to this service. 20.2.5.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.2.5.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.2.5.3.4 Functional Requirements
1. The computing function shall issue a Route Select service request only in response to a Route request or Re-Route request from the switching function. 2. The routeingCrossRefID and routeRegisterReqID (if supported) parameters from the initial Route Request service shall be used to link this service to the others that are used to provide a route. 3. The routeRegisterReqID parameter is mandatory if the switching function supports route registration, and shall not be provided otherwise. 4. If the computing function is unable to supply an actual count (retryCount) of the number of alternative routes in the remainRetries parameter, it can provide one of two other options in the parameter: •
noListAvailable. This indicates a specific reason why the retry count is not being provided - that the computing function does not maintain a fixed list of alternate routes. For example, the alternative routes may be calculated algorithmically or by progressive database searches (i.e. returns the next entry matched to the search criterion).
•
noCountAvailable. This indicates a more general reason why the retry count is not being provided - that the computing function does not maintain or cannot provide a count of the remaining routes to try. For example, the design of the database does not enable a count of the entries left to be provided or it does not maintain a fixed list of routes.
- 475 -
20.2.6
Route Used
S
C
The Route Used service provides 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. 20.2.6.1 Service Request Table 20-13 Route Used—Service Request Parameter Name
Type
M/ O/C
Description
crossRefIdentifier
RouteingCrossRefID
M
Specifies the cross reference identifier associated with the routeing dialogue.
routeRegisterReqID
RouteRegisterReqID
C
Specifies the route register request identifier associated with the route registration for this routeing dialogue. See Functional Requirement #4.
routeUsed
CalledDeviceID
M
Specifies the actual destination of the call for which a route was requested.
callingDevice
CallingDeviceID
O
Specifies the originator of the call.
domain
Boolean
O
Specifies whether the resolved destination is within the switching sub-domain. The complete set of possible values is: • True - Resolved destination is within the switching sub-domain. • False - The call has been routed outside the switching sub-domain.
correlatorData
CorrelatorData
C
Specifies the correlator data associated with the call. This parameter is mandatory if there is correlator data associated with the call (and if the parameter is supported).
callLinkageData
CallLinkageData
C
Specifies the global call data and thread data associated with the call. This parameter is mandatory if the switching function supports the call linkage feature otherwise it shall not be provided.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
20.2.6.2 Service Response There are no service completion conditions for this service. 20.2.6.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service. 20.2.6.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 20.2.6.3 Operational Model 20.2.6.3.1 Connection State Transitions
There are no connection state changes due to this service. 20.2.6.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.2.6.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 20.2.6.3.4 Functional Requirements
1. This service is used to inform the computing function of the actual route that was used by the switching function. This route could be different than the route provided by the computing function
- 476 -
with the Route Select service because the route could have been altered via interactions in the switching function with features such as Forwarding or ACD routeing, for example. 2. The Route Used service should be completed via a Route End service sent by either the computing or switching functions. 3. The routeingCrossRefID and routeRegisterReqID (if supported) parameters from the initial Route Request service shall be used to link this service to the others that are used to provide a route. 4. The routeRegisterReqID parameter is mandatory if the switching function supports route registration, and shall not be provided otherwise.
- 477 -
21
Physical Device Features This section describes the feature capabilities as related to the device’s physical element including descriptions of: •
Physical Device Feature services
•
Physical Device Feature events
General Functional Requirements 1. The device identifier supplied on each Physical Device Feature service shall be the device identifier associated with the device’s physical element. Otherwise, the request is rejected with a negative acknowledgement. 2. Some switching functions may reject certain services if there is not a call at a device. For example, the Set Speaker Volume service may be rejected if there is no call at a device.
21.1
Services Table 21-1 Physical Device Feature Services Summary Physical Device Feature Service
Description
Pg.
21.1.1 Button Press
Simulates the activation of a specified button on a device.
479
21.1.2 Get Auditory Apparatus Information
Get information on one or all auditory apparatuses at a specified device.
480
21.1.3 Get Button Information
Get the button information for either a specified button or all buttons on a device.
482
21.1.4 Get Display
Get a snapshot of the contents of the physical device’s display.
484
21.1.5 Get Hookswitch Status
Get the hookswitch status of a specified device.
486
21.1.6 Get Lamp Information
Get the lamp information for either a specified lamp or all lamps on a device.
482
21.1.7 Get Lamp Mode
Get the lamp mode status of a specified button on a device.
489
21.1.8 Get Message Waiting Indicator
Get the message waiting status at a specified device.
492
21.1.9 Get Microphone Gain
Get the microphone gain setting at a specified device.
493
21.1.10 Get Microphone Mute
Get the microphone mute status at a specified device.
494
21.1.11 Get Ringer Status
Get the ringer status (ringing/not ringing, ring count, ring pattern, ring volume) of one or all ringers associated with a device.
495
21.1.12 Get Speaker Mute
Get the speaker mute status of a specified device.
497
21.1.13 Get Speaker Volume
Get the speaker volume setting of a specified device.
498
21.1.14 Set Button Information
Set the button information of a specified button on a device.
499
21.1.15 Set Display
Set the display on a specified device.
500
21.1.16 Set Hookswitch Status
Set the hookswitch status of a specified device.
502
21.1.17 Set Lamp Mode
Set the lamp mode status of a specified button on a device.
503
21.1.18 Set Message Waiting Indicator
Set the message waiting status of a specified device.
505
21.1.19 Set Microphone Gain
Set the microphone gain setting of a specified device.
506
21.1.20 Set Microphone Mute
Set the microphone mute status of a specified device.
508
21.1.21 Set Ringer Status
Set the specified ringer to ring or not to ring. May also be used to set the ring pattern and ring volume of a ringer at a specified device.
509
21.1.22 Set Speaker Mute
Set the speaker mute status of a specified device.
511
21.1.23 Set Speaker Volume
Set the speaker volume setting of a specified device.
512
- 478 -
21.1.1
Button Press
C
S
The Button Press service allows a computing function to simulate the activation of a specified button at a specified device. The button model is described in 6.1.1.1.3, “Button”, on page 14. 21.1.1.1 Service Request Table 21-2 Button Press—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
button
ButtonID
M
Specifies the button on the device. See 12.3.5, “ButtonID”, on page 148 for reserved button assignments.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.1.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 21.1.1.2.1 Positive Acknowledgement Table 21-3 Button Press—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.1.3 Operational Model 21.1.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 21.1.1.3.2 Device-Type Monitoring Event Sequences Table 21-4 Button Press—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Button Press
21.1.1.3.3 Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence. 21.1.1.3.4 Functional Requirements
1. A Button Press could initiate any potential call sequences, but these sequences would appear as manually initiated activities equivalent to a user pressing the given button on the set. Invoking a speed-dial button is an example of a common use for the Button Press service.
- 479 -
21.1.2
Get Auditory Apparatus Information
C
S
The Get Auditory Apparatus Information service provides information about one or more auditory apparatuses at a device. 21.1.2.1 Service Request Table 21-5 Get Auditory Apparatus Information—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
auditoryApparatus
AuditoryApparatusID
O
Specifies which auditory apparatus to query. If not provided, then information is obtained on all the auditory apparatuses associated with the device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.2.2 Service Response This service follows the atomic acknowledgement model for this service request. 21.1.2.2.1 Positive Acknowledgement Table 21-6 Get Auditory Apparatus Information—Positive Acknowledgement Parameter Name
Type
M/ O/C
auditoryApparatusList
List of Structures
M
Description Specifies information about the specified auditory apparatus or about all apparatuses associated with the device if no auditoryApparatus was provided in the request. Each entry contains the following: • auditoryApparatus (M) AuditoryApparatusID -This parameter indicates the auditory apparatus to which the other provided information applies. • auditoryApparatusType (M) Enumerated -This parameter indicates the auditory apparatus type. The complete set of possible values is: •
Speakerphone - Designates a logical hookswitch associated with a speakerphone.
•
Handset - Designates a physical hookswitch associated with a typical telephone handset that is operated (i.e., “opened” and “closed”) by manually lifting the handset from, and replacing it in, a handset cradle.
•
Headset - Designates a logical hookswitch associated with a headset.
•
SpeakerOnlyPhone - Designates a logical hookswitch associated with a speaker-only phone.
•
Other - not one of the above values.
• speaker (M) Bitmap - Specifies information about the speaker associated with this auditory apparatus. Multiple bits may be set: •
present - If the bit is TRUE, then a speaker is associated with this auditory apparatus.
•
volumeSettable - If the bit is TRUE, then the speaker’s volume can be set.
(continued)
- 480 -
Table 21-6 Get Auditory Apparatus Information—Positive Acknowledgement (concluded) Parameter Name auditoryApparatusList (continued)
Type (continued)
M/ O/C
Description
M
•
volumeReadable - If the bit is TRUE, then the speaker’s volume can be read.
•
muteSettable - If the bit is TRUE, then the speaker’s mute status can be set.
•
muteReadable - If the bit is TRUE, then the speaker’s mute status can be read.
• microphone (M) Bitmap - Specifies information about the microphone associated with this auditory apparatus: •
present - If the bit is TRUE, then a microphone is associated with this auditory apparatus.
•
gainSettable - If the bit is TRUE, then the microphone’s gain can be set.
•
gainReadable - If the bit is TRUE, then the microphone’s gain can be read.
•
muteSettable - If the bit is TRUE, then the microphone’s mute status can be set.
•
muteReadable - If the bit is TRUE, then the microphone’s mute status can be read.
• hookswitch (M) Bitmap - Specifies information about the hookswitch associated with this auditory apparatus: •
hookswitchSettable - If the bit is TRUE, then the hookswitch status can be set.
•
hookswitchOnHook - If the bit is TRUE, then the hookswitch associated with this auditory apparatus is currently on-hook (hookswitchOnHook = TRUE) or off-hook (hookswitchOnHook = FALSE).
• hookswitchID (M) HookswitchID - Indicates the hookswitchID of the hookswitch which is associated with this auditory apparatus. Note that a given hookswitch can be associated with multiple auditory apparatuses. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.2.3 Operational Model 21.1.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 21.1.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 481 -
21.1.3
Get Button Information
C
S
The Get Button Information service provides information about the specified button or buttons on a device. 21.1.3.1 Service Request Table 21-7 Get Button Information—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
button
ButtonID
O
Specifies which button to query. If not provided, then information is obtained on all the buttons associated with the device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.3.2 Service Response This service follows the atomic acknowledgement model for this service request.
- 482 -
21.1.3.2.1 Positive Acknowledgement Table 21-8 Get Button Information—Positive Acknowledgement Parameter Name buttonList
Type
M/ O/C
Description
List of Structures
M
Specifies information about the specified button or about all buttons associated with the device if no button was provided in the request. Each entry contains the following: • button (M) ButtonID - Specifies the buttonID of the button described by this entry. • buttonLabel (O) Characters - The label by which a button may be referenced. The maximum length supported by the switching function is provided via the capabilities exchange services. • buttonLabelSettable (O) Boolean - If the bit is TRUE the button label can be set by the Set Button Information service. • buttonFunction (O) Characters - The function assigned to the button. • buttonAssociatedNumber (O) DeviceID - This indicates a number (in Diallable Digits format) associated with this button. • buttonAssociatedNumberSettable (O) Boolean - If the bit is TRUE a number can be associated with this button via the Set Button Information service. • buttonPressIndicator (O) Boolean - If the bit is TRUE (default) the button can be pressed via the Button Press service. • lampList (O) List of LampIDs - These are the lamps that are associated with the button. If the list is empty, then there are no lamps associated with this button.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.3.3 Operational Model 21.1.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 21.1.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 483 -
21.1.4
Get Display
C
S
The Get Display service provides a snapshot of the contents of the device’s display. The capabilities exchange services can be used to determine the number of displays associated with a device. 21.1.4.1 Service Request Table 21-9 Get Display—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
displayID
DisplayID
O
Specifies which display to query. If not provided, then information is obtained on all the displays associated with the device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.4.2 Service Response This service follows the atomic acknowledgement model for this service request. 21.1.4.2.1 Positive Acknowledgement Table 21-10 Get Display—Positive Acknowledgement Parameter Name displayList
Type
M/ O/C
Description
List of Structures
M
Specifies information about the specified display or about all displays associated with the device if no displayID was provided in the request. Each entry contains the following: • displayID (M) DisplayID - This parameter indicates the display to which the other provided information applies. • logicalRows (M) Value - The number of rows on the logical display. • logicalColumns (M) Value - The number of columns on the logical display. • physicalRows (C) Value - The number of rows on the physical display. When the number of physical Rows is equal to the number of logical Rows this parameter shall be omitted, otherwise it shall be present. • physicalColumns (C) Value - The number of columns on the physical display. When the number of physicalColumns is equal to the number of logicalColumns this parameter shall be omitted, otherwise it shall be present. • physicalBaseRowNumber (C) Value - The row number of the physical base, i.e. the logical row that appears at the first row of the physical display. When the number of physicalRows is equal to the number of logicalRows this parameter shall be omitted, otherwise it shall be present. (continued)
- 484 -
Table 21-10 Get Display—Positive Acknowledgement (concluded) Parameter Name displayList
Type (continued)
M/ O/C
Description
M
• physicalBaseColumnNumber (C) Value - The column number of the physical base, i.e. the logical column that appears at the first column of the physical display. When the number of physicalColumns is equal to the number of logicalColumns this parameter shall be omitted, otherwise it shall be present.
(continued)
• characterSet (O) Enumerated - Specifies the character set which is being used to represent the text on the display. The complete set of possible values is: •
ASCII (default)
•
Unicode (UTF-8)
•
Proprietary
• contentsOfDisplay (M) Characters - Specifies the text on display as a string of characters consisting of the text on each row of the display (including spaces) concatenated together. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.4.3 Operational Model 21.1.4.3.1 Connection State Transitions
There are no connection state changes due to this service. 21.1.4.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.4.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.4.3.4 Functional Requirements
1. The contentsOfDisplay parameter always contains the maximum number of characters on the display as indicated by the number of logicalRows and logicalColumns.
- 485 -
21.1.5
Get Hookswitch Status
C
S
This Get Hookswitch Status service provides the hookswitch status of one or more hookswitches associated with a specified device. The hookswitch status indicates which hookswitches are present on a device and which hookswitches are currently off-hook. 21.1.5.1 Service Request Table 21-11 Get Hookswitch Status—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
hookswitch
HookSwitchID
O
Specifies which hookswitch to query. If not provided, then information is obtained on all the hookswitches associated with the device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.5.2 Service Response This service follows the atomic acknowledgement model for this service request. 21.1.5.2.1 Positive Acknowledgement Table 21-12 Get Hookswitch Status—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
hookswitchStatusList
List of Structures
M
Specifies information about the specified hookswitch or about all hookswitches associated with the device if no hookswitch was provided in the request. Each entry contains the following: • hookswitch (M) HookswitchID - Indicates the hookswitch whose status is reported. • hookswitchOnHook (M) Boolean - Indicates the state of the hookswitch. The complete set of possible values is: •
TRUE - Indicates that the switch is onhook.
•
FALSE - Indicates that the switch is offhook.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.5.3 Operational Model 21.1.5.3.1 Connection State Transitions
There are no connection state changes due to this service. 21.1.5.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.5.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 486 -
21.1.6
Get Lamp Information
C
S
The Get Lamp Information service provides information about the specified lamp(s) on a device and if the specified lamp(s) is currently lit. 21.1.6.1 Service Request Table 21-13 Get Lamp Information—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
lamp
LampID
O
Specifies which lamp to query. If not provided, then information is obtained on all the lamps associated with the device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.6.2 Service Response This service follows the atomic acknowledgement model for this service request. 21.1.6.2.1 Positive Acknowledgement Table 21-14 Get Lamp Information—Positive Acknowledgement Parameter Name lampList
Type
M/ O/C
Description
List of Structures
M
Specifies information about the specified lamp or about all lamps associated with the device if no lamp was provided in the request. Each entry contains the following: • lamp (M) LampID - Indicates the lampID of this lamp. • lampLabel (O) Characters - The label by which a lamp may be referenced. The maximum length supported by the switching function is provided via the capabilities exchange services. • button (O) ButtonID -Specifies a button that is associated with this lamp. If not present, then a button is not associated with this lamp. • lampColor (O) Value - A value from 0 - 100 specifying the color of the lamp. The meaning of the following values are pre-assigned: •
0 - no color
•
1 - Red
•
2 - Yellow
•
3 - Green
•
4 - Blue
•
5 - Unknown (the switching function cannot determine the color of the lamp) (default if this parameter is not present).
All other values (6-100) are switching function specific. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.6.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. - 487 -
21.1.6.3 Operational Model 21.1.6.3.1 Connection State Transitions
There are no connection state changes due to this service. 21.1.6.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.6.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.6.3.4 Functional Requirements
1. If the computing function requests all lamps associated with a given device, then this will include both lamps with or without buttons associated with them.
- 488 -
21.1.7
Get Lamp Mode
C
The Get Lamp Mode service provides the lamp mode status. 21.1.7.1 Service Request Table 21-15 Get Lamp Mode—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
lamp
LampID
O
Specifies which lamp to query. If not provided, then information is obtained on all the lamps associated with the device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.7.2 Service Response This service follows the atomic acknowledgement model for this service request.
- 489 -
S
21.1.7.2.1 Positive Acknowledgement Table 21-16 Get Lamp Mode—Positive Acknowledgement Parameter Name lampModeList
Type
M/ O/C
Description
List of Structures
M
Specifies information about the specified lamp or about all lamps associated with the device if no lamp was provided in the request. Each entry contains the following: • lamp (M) LampID - Indicates the lampID of this lamp. • lampMode (M) Value - A value from 0 - 100 specifying how the lamp is lit. The complete set of possible values is: •
0 - Brokenflutter. Superposition of wink and flutter.
•
1 - Flutter. Fast on and off.
•
2 - Off. Lamp is off.
•
3 - Steady. Lamp is continuously lit.
•
4 - Wink. Lamp is winking.
•
5 - Unknown (the switching function cannot determine the mode of the lamp)
•
All other values (6-100) are switching function specific.
• lampBrightness (O) Enumerated - Indicates the intensity of lamp if the lamp is on (as indicated by lampMode parameter). Actual visible brightness levels are lamp-dependent. The complete set of possible values is: •
Unspecified/Normal (default)
•
Dim
•
Bright
• lampColor (O) Value - A value from 0 - 100 specifying the color of the lamp. The meaning of the following values are pre-assigned: •
0 - no color
•
1 - Red
•
2 - Yellow
•
3 - Green
•
4 - Blue
•
5 - Unknown (the switching function cannot determine the color of the lamp) (default if this parameter is not present).
•
All other values (6-100) are switching function specific.
• button (O) ButtonID - Specifies a button that is associated with this lamp. If not present, then a button is not associated with this lamp. lamp
LampID
O
Specifies the lamp identifier associated with the lamp.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.7.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.7.3 Operational Model - 490 -
21.1.7.3.1 Connection State Transitions
There are no connection state changes due to this service. 21.1.7.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.7.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 491 -
21.1.8
Get Message Waiting Indicator
C
S
The Get Message Waiting Indicator service provides the message waiting feature status at a specified device. The message waiting feature is typically used to notify a user (typically via a dedicated lamp on a phone device) when messages are available. 21.1.8.1 Service Request Table 21-17 Get Message Waiting Indicator—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.8.2 Service Response This service follows the atomic acknowledgement model for this service request. 21.1.8.2.1 Positive Acknowledgement Table 21-18 Get Message Waiting Indicator—Positive Acknowledgement Parameter Name messageWaitingOn
Type
M/ O/C
Boolean
M
Description Specifies the value of the requested feature. The complete set of possible values is: •
FALSE - Message waiting off.
•
TRUE - Message waiting on.
deviceForMessage
DeviceID
O
Specifies the device where the message is waiting.
lampIsPresent
Boolean
O
Specifies the value of the requested feature, based on the messageWaitingOn parameter. The complete set of possible values is: •
FALSE - Lamp is not present.
•
TRUE - Lamp is present.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.8.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.8.3 Operational Model 21.1.8.3.1 Connection State Transitions
There are no connection state changes due to this service. 21.1.8.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.8.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 492 -
21.1.9
Get Microphone Gain
C
S
The Get Microphone Gain service provides the microphone gain setting (input level) for a microphone associated with a particular auditory apparatus at a specified device. 21.1.9.1 Service Request Table 21-19 Get Microphone Gain—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
auditoryApparatus
AuditoryApparatusID
O
Specifies which auditory apparatus to query. If not provided, then information is obtained on all the auditory apparatuses associated with the device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.9.2 Service Response This service follows the atomic acknowledgement model for this service request. 21.1.9.2.1 Positive Acknowledgement Table 21-20 Get Microphone Gain—Positive Acknowledgement Parameter Name microphoneGainList
Type
M/ O/C
Description
List of Structures
M
Specifies information about the specified auditory apparatus or about all auditory apparatuses associated with the device if no auditoryApparatus was provided in the request. Each entry contains the following: • auditoryApparatus (M) AuditoryApparatusID Specifies the auditory apparatus that the microphone belongs to. • micGainAbs (O) Value - Specifies the microphone gain. A value of 0 indicates silence, and 100 indicates maximum gain. The granularity and quantization of the values 1 though 99 are device specific. If this component is not provided, the absolute gain value is unknown.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.9.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.9.3 Operational Model 21.1.9.3.1 Connection State Transitions
There are no connection state changes due to this service. 21.1.9.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.9.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 493 -
21.1.10 Get Microphone Mute
C
S
The Get Microphone Mute service provides the microphone mute feature status of a microphone associated with an auditory apparatus at a specified device. While a device’s microphone is muted, no audio information is transmitted over the device microphone. This feature is used when it is desired to prevent the other party(s) in a call from hearing a conversation through the device. 21.1.10.1 Service Request Table 21-21 Get Microphone Mute—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
auditoryApparatus
AuditoryApparatusID
O
Specifies which auditory apparatus to query. If not provided, then information is obtained on all the auditory apparatuses associated with the device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.10.2 Service Response This service follows the atomic acknowledgement model for this service request. 21.1.10.2.1Positive Acknowledgement Table 21-22 Get Microphone Mute—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
microphoneMuteList
List of Structures
M
Specifies information about the specified auditory apparatus or about all auditory apparatuses associated with the device if no auditoryApparatus was provided in the request. Each entry contains the following: • auditoryApparatus (M) AuditoryApparatusID Specifies the auditory apparatus that the microphone belongs to. • microphoneMuteOn (M) Boolean - Specifies whether the microphone is muted or not. The complete set of possible values is: •
FALSE - Microphone is activated.
•
TRUE - Microphone is muted.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.10.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.10.3 Operational Model 21.1.10.3.1Connection State Transitions
There are no connection state changes due to this service. 21.1.10.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.10.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 494 -
21.1.11
Get Ringer Status
C
S
The Get Ringer Status service provides the ringer status of one or all ringers associated with a specific device. This allows a computing function to determine if a ringer is engaged in a ringing cycle, the number of ring cycles that it has been ringing, and the ring pattern and ring volume settings. 21.1.11.1 Service Request Table 21-23 Get Ringer Status—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
ringer
RingerID
O
Specifies which ringer to query. If not provided, then information is obtained on all the ringers associated with the device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.11.2 Service Response This service follows the atomic acknowledgement model for this service request.
- 495 -
21.1.11.2.1Positive Acknowledgement Table 21-24 Get Ringer Status—Positive Acknowledgement Parameter Name ringerStatusList
Type
M/ O/C
Description
List of Structures
M
Specifies information about the specified ringer or about all ringers associated with the device if no ringer was provided in the request. Each entry contains the following components: • ringer (M) RingerID - Indicates the ringerID. • ringMode (M) Enumerated - Indicates if the ringer is in a ringing cycle. The complete set of possible values is: •
ringing - The ringer is ringing (provided when either the ringer is physically ringing or is in the “quiet phase” of a ring cycle)
•
not ringing - The ringer is not being rung.
• ringCount (O) Value - Indicates the value (0...1000) of the number of complete ring cycles that the ringer has been, or was, ringing. The values 0-999 indicate the actual number of complete ring cycles. The value of 1000 indicates that a value greater than 999 was reached. • ringDuration (O) Value - Indicates the time (in seconds) that the ringer has been ringing, ringDuration should not be provided if ringCount is provided. • ringPattern (O) Value - Indicates the value of the ringing pattern of the ringer. The meaning of ringing patterns and the number of supported patterns is device specific. The ring pattern is associated with the ringer until reset by the switching function or until reset by the Set Ringer Status service. • ringVolAbs (O) Value - Indicates the absolute volume level (0...100) of the ringer. The ring volume is associated with the ringer until reset by the switching function or until reset by the Set Ringer Status service. A value of 0 indicates silence, and 100 indicates maximum volume. The granularity and quantization of the values 1 though 99 are device specific. If this component is not provided, the absolute ringer volume is unknown. Note that the relationship between the ringer volume and loudness is ringer specific. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.11.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.11.3 Operational Model 21.1.11.3.1Connection State Model Transitions
There are no connection state changes due to this service. 21.1.11.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.11.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. - 496 -
21.1.12 Get Speaker Mute
C
S
The Get Speaker Mute service provides the speaker mute feature status for speakers associated with one or more auditory apparatuses at a specified device. While a device’s speaker is muted, no audio information is transmitted over the speaker. 21.1.12.1 Service Request Table 21-25 Get Speaker Mute—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
auditoryApparatus
AuditoryApparatusID
O
Specifies which auditory apparatus to query. If not provided, then information is obtained on all the auditory apparatuses associated with the device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.12.2 Service Response This service follows the atomic acknowledgement model for this service request. 21.1.12.2.1Positive Acknowledgement Table 21-26 Get Speaker Mute—Positive Acknowledgement Parameter Name speakerMuteList
Type
M/ O/C
Description
List of Structures
M
Specifies information about the specified auditory apparatus or about all auditory apparatuses associated with the device if no auditoryApparatus was provided in the request. Each entry contains the following: • auditoryApparatus (M) AuditoryApparatusID Specifies the auditory apparatus to which this speaker belongs. • speakerMuteOn (M) Boolean - Specifies whether the speaker mute setting is on or not. The complete set of possible values is: •
FALSE - Mute is off (i.e., speaker is activated).
•
TRUE - Mute is on (i.e., speaker is muted).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.12.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.12.3 Operational Model 21.1.12.3.1Connection State Transitions
There are no connection state changes due to this service. 21.1.12.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.12.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 497 -
21.1.13 Get Speaker Volume
C
S
The Get Speaker Volume service provides the speaker volume setting for the speakers associated with one or more auditory apparatuses at a specified device. 21.1.13.1 Service Request Table 21-27 Get Speaker Volume—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
auditoryApparatus
AuditoryApparatusID
O
Specifies which auditory apparatus to query. If not provided, then information is obtained on all the auditory apparatuses associated with the device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.13.2 Service Response This service follows the atomic acknowledgement model for this service request. 21.1.13.2.1Positive Acknowledgement Table 21-28 Get Speaker Volume—Positive Acknowledgement Parameter Name speakerVolumeList
Type
M/ O/C
Description
List of Structures
M
Specifies information about the specified auditory apparatus or about all auditory apparatuses associated with the device if no auditoryApparatus was provided in the request. Each entry contains the following: • auditoryApparatus (M) AuditoryApparatusID Specifies the auditory apparatus to which this speaker belongs. • speakerVolAbs (O) Value - Specifies the absolute speaker volume. A value of 0 indicates silence, and 100 indicates maximum volume. The granularity and quantization of the values 1 though 99 are device specific. If this component is not provided, the absolute speaker volume is unknown.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.13.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.13.3 Operational Model 21.1.13.3.1Connection State Transitions
There are no connection state changes due to this service. 21.1.13.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 21.1.13.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 498 -
21.1.14 Set Button Information
C
S
The Set Button Information service allows a computing function to set the information for a specified button at a specified device. 21.1.14.1 Service Request Table 21-29 Set Button Information—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
button
ButtonID
M
Specifies the button to be set.
buttonLabel1
Characters (64)
C
Specifies the label by which a button may be referenced. The maximum length supported by the switching function is provided via the capabilities exchange services.
buttonAssociatedNumber
DeviceID
C
Specifies a diallable string (in diallable digit format, such as a speed-dial number) to be associated with the button.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
1. At least one of the following parameters must be provided: buttonLabel, buttonAssociatedNumber.
21.1.14.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 21.1.14.2.1Positive Acknowledgement Table 21-30 Set Button Information—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.14.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.14.3 Operational Model 21.1.14.3.1Connection State Transitions
There are no connection state changes due to this service. 21.1.14.3.2Device-Type Monitoring Event Sequences Table 21-31 Set Button Information—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Button Information
21.1.14.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence.
- 499 -
21.1.15 Set Display
C
S
The Set Display service allows the computing function to set a display associated with a device. The Get Display service can be used to determine the size of a specific display. The capabilities exchange services can be used to determine the number of displays associated with a device. 21.1.15.1 Service Request Table 21-32 Set Display—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
displayID
DisplayID
C
Specifies which display on the physical device needs to be set. If the device has only one display this parameter may be omitted, but it may also be filled in (specifying the one and only displayID). If the device has more than one display this parameter shall be present.
physicalBaseRowNumber
Value
O
The row number of the physical base, i.e. the logical row that appears at the first row of the physical display. This parameter may be omitted or may be present when it needs to be changed. The parameter shall be omitted when it is not relevant because the number of physical rows is equal to the number of logical rows.
physicalBaseColumnNumber
Value
O
The column number of the physical base, i.e. the logical column that appears at the first column of the physical display. This parameter may be omitted or may be present when it needs to be changed. This parameter shall be omitted when it is not relevant because the number of physical columns is equal to the number of logical columns.
contentsOfDisplay
Characters (240)
M
Specifies the text to place on the display as a string of characters consisting of the text on each row of the display (including spaces) concatenated together. If a null string is sent, the display will be cleared.
offset
Value
O
This parameter specifies the offset, in number-ofcharacters (not bytes in the characters-to-be-displayed message string), where text is to start on the display. Allowed values are from zero (default) to (MaxNbrOfLogicalColumns * MaxNbrOfLogicalRows - 1). Non-printable characters (e.g. Carriage Return (CR), Line Feed (LF), and Tab) are counted in determining offsets and the message length.
characterSet
Enumerated
O
Specifies the character set which is being used to represent the text on the display. The complete set of possible values is: • ASCII (default) • Unicode (UTF-8) • Proprietary
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.15.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. - 500 -
21.1.15.2.1Positive Acknowledgement Table 21-33 Set Display—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.15.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.15.3 Operational Model 21.1.15.3.1Connection State Transitions
There are no connection state changes due to this service. 21.1.15.3.2Device-Type Monitoring Event Sequences Table 21-34 Set Display—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Display Updated
21.1.15.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence. 21.1.15.3.4Functional Requirements
1. If the characters in the contentsOfDisplay parameter overflow the display space, they will be truncated. 2. This service will only affect the areas of the display which are overlaid with the characters in the contentsOfDisplay parameter. The Set Display service overwrites existing display contents on a character-position by character-position basis. (Character positions which are before or after the character positions of the to-be-displayed characters are not affected.) 3. The contentsOfDisplay parameter will be interpreted as being in the same character set as that provided by the switching function in the Get Display service. 4. Characters in the contentsOfDisplay parameter that do not have associated symbols in the display’s current character set appear as spaces. Characters with special attributes like highlighting shall have their own symbols represented in the display’s current character set. 5. If the contentsOfDisplay parameter consists of a null string, the display will be cleared from the offset position to the end of the display. 6. The display area available to the Set Display service may be larger than the visible display area. For example, the display may use paging or scrolling to bring portions of the display into view. All display services and events reference the entire display size rather than only the simultaneously-visible size. Similarly, any formatting or display manipulation to sequentially present multiple pages of information are the responsibility of the switching function and display. 7. When the physicalBaseRowNumber and/or the physicalBaseColumnNumber parameters are provided in the service request with values that are different from the current values, the switching function can either accept the service and modify the relative positions of the logical and physical displays (i.e., scrolling) or it can reject the service if it does not support this capability as indicated by the capability exchange services. 8. If the switching function does not support the optional parameter characterSet the switching function shall either reject the service request or interpret contentsOfDisplay in the default characterSet. - 501 -
21.1.16 Set Hookswitch Status
C
S
The Set Hookswitch Status service allows the computing function to activate and deactivate (i.e., go offhook/onhook) an auditory apparatus (e.g. speakerphone, handset, headset) at a specified device. 21.1.16.1 Service Request Table 21-35 Set Hookswitch Status—Service Request Parameter Name device
Type
M/ O/C
Description
DeviceID
M
Specifies the device’s physical element.
hookswitch
HookswitchID
M
Specifies the hookswitch whose status is to be set.
hookswitchOnHook
Boolean
M
Specifies the state of the hookswitch. The complete set of possible values is: • TRUE - The switch is onhook. • FALSE - The switch is offhook.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.16.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 21.1.16.2.1Positive Acknowledgement Table 21-36 Set Hookswitch Status—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.16.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.16.3 Operational Model 21.1.16.3.1Connection State Transitions
There are no connection state changes due to this service. 21.1.16.3.2Device-Type Monitoring Event Sequences Table 21-37 Set Hookswitch Status—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Hookswitch
21.1.16.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence.
- 502 -
21.1.17 Set Lamp Mode
C
S
The Set Lamp Mode service allows a computing function to control how a specified lamp is lit at a specified device. 21.1.17.1 Service Request Table 21-38 Set Lamp Mode—Service Request Parameter Name device
Type
M/ O/C
Description
DeviceID
M
Specifies the device’s physical element.
lamp
LampID
M
Specifies the LampID of the lamp on the device.
lampMode
Value
M
Specifies how the lamp associated with the specified device should be lit. The complete set of possible values is: • 0 - Brokenflutter. Superposition of wink and flutter. • 1 - Flutter. Fast on and off. • 2 - Off. Lamp is off. • 3 - Steady. Lamp is continuously lit. • 4 - Wink. Lamp is winking. • 5 - not used • All other values (6-100) are switching function specific.
lampBrightness
Enumerated
O
Indicates intensity of lamp when the lamp is on (as indicated by lampMode parameter). Actual visible brightness levels are lamp-dependent. The complete set of possible values is: • Unspecified/Normal (default) • Dim • Bright
lampColor
Value
O
Specifies the color of the lamp. The meaning of the following values are pre-assigned: • 0 - no color • 1 - Red • 2 - Yellow • 3 - Green • 4 - Blue • 5 - not used • All other values (6-100) are switching function specific.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.17.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 503 -
21.1.17.2.1Positive Acknowledgement Table 21-39 Set Lamp Mode—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.17.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.17.3 Operational Model 21.1.17.3.1Connection State Transitions
There are no connection state changes due to this service. 21.1.17.3.2Device-Type Monitoring Event Sequences Table 21-40 Set Lamp Mode—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Lamp Mode
21.1.17.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence.
- 504 -
21.1.18 Set Message Waiting Indicator
C
S
The Set Message Waiting Indicator service allows a computing function to control the status of the message waiting feature at a specified device. The message waiting feature is typically used to notify a user (typically via a dedicated lamp on a phone device) when messages are available. 21.1.18.1 Service Request Table 21-41 Set Message Waiting Indicator—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
messageWaitingOn
Boolean
M
Specifies the setting of the message waiting feature. The complete set of possible values is: • OFF - Message waiting off. • ON - Message waiting on.
deviceForMessage
DeviceID
O
Specifies the device where the message is waiting.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.18.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 21.1.18.2.1Positive Acknowledgement Table 21-42 Set Message Waiting Indicator—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.18.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.18.3 Operational Model 21.1.18.3.1Connection State Transitions
There are no connection state changes due to this service. 21.1.18.3.2Device-Type Monitoring Event Sequences Table 21-43 Set Message Waiting Indicator—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Message Waiting
21.1.18.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence.
- 505 -
21.1.19 Set Microphone Gain
C
S
The Set Microphone Gain service allows the computing function to control the microphone gain setting (input level) of the microphone associated with one auditory apparatus at a specified device. 21.1.19.1 Service Request Table 21-44 Set Microphone Gain—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
auditoryApparatus
AuditoryApparatusID
M
Specifies the auditory apparatus at the designated device on which to set the feature.
microphoneGain
Choice Structure
M
Specifies the gain as an absolute gain value or that the gain should be incremented or decremented by a switch specified increment. It may be one of the following possible choices: • micGainAbs (Value) - Specifies a value from 0 through 100. 0 indicates silence, and 100 indicates maximum gain. The granularity and quantization of the values 1 though 99 are device specific • micGainInc (Enumerated) - Specifies if the gain is to be incremented or decremented by a switch specified amount. The complete set of possible values is: •
increment - the gain value is incremented
•
decrement - the gain value is decremented.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.19.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 21.1.19.2.1Positive Acknowledgement Table 21-45 Set Microphone Gain—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.19.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.19.3 Operational Model 21.1.19.3.1Connection State Transitions
There are no connection state changes due to this service.
- 506 -
21.1.19.3.2Device-Type Monitoring Event Sequences Table 21-46 Set Microphone Gain—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Microphone Gain
21.1.19.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence.
- 507 -
21.1.20 Set Microphone Mute
C
S
The Set Microphone Mute service allows the computing function to control the microphone mute status of the microphone associated with one auditory apparatus at a specified device. While a device’s microphone is muted, no audio information is transmitted over the microphone. This is used when it is desired to prevent the other device(s) in a call from hearing a conversation. 21.1.20.1 Service Request Table 21-47 Set Microphone Mute—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
auditoryApparatus
AuditoryApparatusID
M
Specifies the auditory apparatus at the designated device on which to set the feature.
microphoneMuteOn
Boolean
M
Specifies the microphone mute setting of a particular microphone. The complete set of possible values is: • OFF - Microphone is activated. • ON - Microphone is muted.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.20.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 21.1.20.2.1Positive Acknowledgement Table 21-48 Set Microphone Mute—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.20.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.20.3 Operational Model 21.1.20.3.1Connection State Transitions
There are no connection state changes due to this service. 21.1.20.3.2Device-Type Monitoring Event Sequences Table 21-49 Set Microphone Mute—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Microphone Mute
21.1.20.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence.
- 508 -
21.1.21 Set Ringer Status
C
S
The Set Ringer Status service allows the computing function to control ringing of a specified ringer on a device. It also allows a computing function to control the ring pattern and ring volume settings only during the ringing cycle that is being initiated with this service (i.e. does not permanently change the configuration or programming of the ringer attributes). 21.1.21.1 Service Request Table 21-50 Set Ringer Status—Service Request Parameter Name device ringer ringMode
1
Type
M/ O/C
Description
DeviceID
M
Specifies the device’s physical element.
RingerID
M
Specifies the ringer to be set.
Enumerated
C
Indicates if the ringer should be rung or not rung. The complete set of possible values is: • ringing - The ringer should be rung. • not ringing - The ringer should not be rung.
ringPattern
1
Value
C
Indicates the value of the ringing pattern of the ringer. The meaning of the ringing patterns and the number of supported patters is device specific. This parameter is only valid when ringMode has a value of ringing and has no effect on the ringPattern used during subsequent call related ringing. If ringMode has a value of Ringing then ringPattern is Mandatory.
ringVolume
1
Choice Structure
C
Indicates the volume level of the ringer. May specify either an absolute value or may specify that the volume should be incremented or decremented by a switch specified increment. It may be one of the following possible choices: • ringVolAbs (Value) - Specifies a value from 0 through 100. 0 indicates silence, and 100 indicates maximum volume. The granularity and quantization of the values 1 though 99 are device specific • ringVolInc (Enumerated) - Specifies if the volume is to be incremented or decremented by a switch specified amount. The complete set of possible values is: •
increment - the volume is incremented
•
decrement - the volume is decremented.
Note that the relationship between the ringer volume and loudness is ringer specific. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
1. At least one of the following parameters in the service request described above shall be provided in the service request: ringMode, ringPattern, ringVolume.
21.1.21.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 509 -
21.1.21.2.1Positive Acknowledgement Table 21-51 Set Ringer Status—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.21.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.21.3 Operational Model 21.1.21.3.1Connection State Model Transitions
There are no connection state changes due to this service. 21.1.21.3.2Device-Type Monitoring Event Sequences Table 21-52 Set Ringer Status—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Ringer Status
21.1.21.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence. 21.1.21.3.4Functional Requirements
1. Note that some switching functions do not allow the computing function to directly control ringing of a device. (Switching functions will ring a device to indicate that a call has arrived at a device, for example.)
- 510 -
21.1.22 Set Speaker Mute
C
S
The Set Speaker Mute service allows a computing function to control the speaker mute status of the hookswitch components at a specified device. While a device’s speaker is muted, no audio information is transmitted over the speaker. 21.1.22.1 Service Request Table 21-53 Set Speaker Mute—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
auditoryApparatus
AuditoryApparatusID
M
Specifies the auditory apparatus at the designated device on which to set the feature.
speakerMuteOn
Boolean
M
Specifies the speaker mute setting of a particular speaker at a device. The complete set of possible values is: • FALSE - Mute is off (i.e., speaker is activated). • TRUE - Mute is on (i.e., speaker is muted).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.22.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 21.1.22.2.1Positive Acknowledgement Table 21-54 Set Speaker Mute—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.22.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.22.3 Operational Model 21.1.22.3.1Connection State Transitions
There are no connection state changes due to this service. 21.1.22.3.2Device-Type Monitoring Event Sequences Table 21-55 Set Speaker Mute—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Speaker Mute
21.1.22.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence.
- 511 -
21.1.23 Set Speaker Volume
C
S
The Set Speaker Volume service allows the computing function to control the speaker volume of the speaker associated with one auditory apparatus at a specified device. 21.1.23.1 Service Request Table 21-56 Set Speaker Volume—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device’s physical element.
auditoryApparatus
AuditoryApparatusID
M
Specifies the auditory apparatus containing the speaker whose volume is to be set.
speakerVolume
Choice Structure
M
Specifies the speaker volume as an absolute value or that the volume should be incremented or decremented by a switch specified increment. It may be one of the following possible choices: • speakerVolAbs (Value) - Specifies a value from 0 through 100. 0 indicates silence, and 100 indicates maximum volume. The granularity and quantization of the values 1 though 99 are device specific • speakerVolInc (Enumerated) - Specifies if the volume is to be incremented or decremented by a switch specified amount. The complete set of possible values is: •
increment - the volume is incremented
•
decrement - the volume is decremented.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.23.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 21.1.23.2.1Positive Acknowledgement Table 21-57 Set Speaker Volume—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
21.1.23.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 21.1.23.3 Operational Model 21.1.23.3.1Connection State Transitions
There are no connection state changes due to this service.
- 512 -
21.1.23.3.2Device-Type Monitoring Event Sequences Table 21-58 Set Speaker Volume—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Speaker Volume
21.1.23.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence. 21.1.23.3.4Functional Requirements
1. Some switching functions may reset the speaker volume after each call. 2. Some switching functions reject the setting of the speaker volume if there is not an active call at a device.
- 513 -
21.2
Events Table 21-59 Physical Device Feature Event Summary Physical Device Feature Event
Description
Pg.
21.2.1 Button Information
The information associated with a button on a device has changed.
515
21.2.2 Button Press
A button has been pressed.
516
21.2.3 Display Updated
The contents of a device’s display has changed.
517
21.2.4 Hookswitch
A hookswitch status has changed.
519
21.2.5 Lamp Mode
The lamp mode status of a particular lamp has changed.
520
21.2.6 Message Waiting
The message waiting status has changed.
521
21.2.7 Microphone Gain
The microphone gain setting has changed for one of the hookswitches.
522
21.2.8 Microphone Mute
The microphone mute status has changed for one of the hookswitches.
523
21.2.9 Ringer Status
The ringer attribute associated with a device has changed.
524
21.2.10 Speaker Mute
The speaker mute status has changed for one of the hookswitches.
526
21.2.11 Speaker Volume
The speaker volume setting has changed for one of the hookswitches.
527
- 514 -
21.2.1
Button Information The Button Information event indicates that information associated with a button has changed. This event may be generated in any one of the following ways: •
The button information has changed manually through the telephone keypad or through a management feature.
•
A computing function, on behalf of a user, has invoked the Set Button Information service.
21.2.1.1 Event Parameters Table 21-60 Button Information—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Specifies the device where the button information feature was changed.
ButtonID
M
Specifies the button on the device.
Characters (64)
C
Specifies the label by which the button may be referenced.
buttonAssociatedNumber
DeviceID
C
Specifies a number (in diallable string format) associated with the button.
buttonPressIndicator
Boolean
C
Specifies if the button can be pressed via the Button Press service. The complete set of possible values is:
button buttonLabel
1
• TRUE - the button can be pressed. • FALSE - the button can not be pressed. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
1. At least one of the buttonPressIndicator.
following
parameters
- 515 -
shall
be
provided:
buttonLabel,
buttonAssociatedNumber,
21.2.2
Button Press The Button Press event indicates that a button has been pressed. This event may be generated in any one of the following ways: •
The button has been pressed manually.
•
A computing function, on behalf of a user, has invoked the Button Press service.
21.2.2.1 Event Parameters Table 21-61 Button Press—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Specifies the device where the button press feature was changed.
button
ButtonID
M
Specifies the button that was pressed.
buttonLabel1
Characters (64)
C
Specifies the label by which the button may be referenced.
buttonAssociatedNumber
DeviceID
C
Indicates a number (in diallable string format) associated with the button.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
1. At least on of the following parameters must be provided: buttonLabel, buttonAssociatedNumber.
21.2.2.2 Functional Requirements 1. The Button Press event is only provided when the button is physically pressed or when the Button Press service is used. It is not to be used to track the function that the button represents.
- 516 -
21.2.3
Display Updated The Display Updated event indicates that the contents of one of the displays associated with a device has changed.
The capabilities exchange services can be used to determine the number of displays associated with a device. 21.2.3.1 Event Parameters Table 21-62 Display Updated—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Specifies the device where the display information was changed.
displayID
DisplayID
O
Specifies the display to which the other provided information applies. When there is exactly one display this parameter may be omitted, but it may then also be present containing the one and only displayID. When there is more than one display this parameter shall be present.
logicalRows
Value
M
The number of rows on the logical display.
logicalColumns
Value
M
The number of columns on the logical display.
physicalRows
Value
C
The number of rows on the physical display. When the number of physical Rows is equal to the number of logical Rows this parameter shall be omitted, otherwise it shall be present.
physicalColumns
Value
C
The number of columns on the physical display. When the number of physicalColumns is equal to the number of logicalColumns this parameter shall be omitted, otherwise it shall be present.
physicalBaseRowNumber
Value
C
The row number of the physical base, i.e. the logical row that appears at the first row of the physical display. When the number of physicalRows is equal to the number of logicalRows this parameter shall be omitted, otherwise it shall be present.
physicalBaseColumnNumber
Value
C
The column number of the physical base, i.e. the logical column that appears at the first column of the physical display. When the number of physicalColumns is equal to the number of logicalColumns this parameter shall be omitted, otherwise it shall be present.
characterSet
Enumerated
O
Specifies the character set which is being used to represent the text on the display. The complete set of possible values is: • ASCII (default) • Unicode • Proprietary
contentsOfDisplay
Characters (240)
M
Specifies the text on display as a string of characters consisting of the text on each row of the display (including spaces) concatenated together.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 517 -
21.2.3.2 Functional Requirements 1. The contentsOfDisplay parameter always contains the maximum number of characters on the display as indicated by the number of logicalRows and logicalColumns. 2. The character set for a specific display associated with a given device is fixed so the value returned in characterSet shall always be the same for a given device. The same applies to logicalRows, logicalColumns, physicalRows, and physicalColumns. 3. Only display contents in areas that are controlled or readable by the switching function are modeled as part of the physical device’s display. Areas that are under local-station or user control only may or may not, depending upon the switching function, be considered part of the physical device’s display. 4. When the switching function supports the Display Updated event for a given device, then anytime one of the displays associated with that device is updated by the switching function, the Display Updated event is generated. In a Display Updated event, the entire contents of the specified display is provided. The computing function may compare the received display snapshots to track specific changes in the display. 5. This event is generated when a display update has been completed by the switching function. The determination of when completion occurs (or even whether the display has changed at all) is switching-function specific if the display change has not been changed via the Set Display service. For example, depending upon the switching function, it could occur on a character-by-character basis (though this is not recommended or when the entire new display contents have been sent (recommended). Similarly, it is switching-function dependent whether locally-controlled (i.e., by the station device itself) or frequently-changed information (such as clock times) are modeled as part of the physical device’s display and if so, at what interval the Display Updated event is generated. 6. If the Set Display service is used to update the display, then the update is considered complete (for purposes of generating this event) when the Set Display’s completion criteria are fulfilled.
- 518 -
21.2.4
Hookswitch The Hookswitch event indicates that the hookswitch status (on-hook/off-hook) has changed. This event may be generated in any one of the following ways: •
The computing function has invoked the Set Hookswitch Status service.
•
The hookswitch status has been changed manually.
•
The computing function has invoked a call control service that indirectly affected the hookswitch.
21.2.4.1 Event Parameters Table 21-63 Hookswitch—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Specifies the device where the feature was changed.
hookswitch
HookswitchID
M
Specifies the hookswitch at the device where the feature was invoked.
hookswitchOnHook
Boolean
M
Specifies the state of the hookswitch. The complete set of possible values is: • On-hook - The switch is open and the hookswitch is inactive. • Off-hook - The switch is closed and the hookswitch is active.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 519 -
21.2.5
Lamp Mode The Lamp Mode event indicates that the lamp mode status has changed for a device. This event may be generated in any one of the following ways: •
A feature associated with the lamp has changed status because of a manual button depression.
•
A computing function, on behalf of a user, has invoked the Set Lamp Mode service.
21.2.5.1 Event Parameters Table 21-64 Lamp Mode—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Specifies the device where the lamp mode status was changed.
lamp
LampID
M
Specifies the lamp identifier of the lamp on the device.
lampLabel1
Characters (64)
C
Specifies the label by which the lamp may be referenced.
lampMode
Value
M
Specifies how the lamp is lit. The complete set of possible values is: • 0 - Brokenflutter. Superposition of wink and flutter. • 1 - Flutter. Fast on and off. • 2 - Off. Lamp is off. • 3 - Steady. Lamp is continuously lit. • 4 - Wink. Lamp is winking. • 5 - Unknown (the switching function cannot determine the mode of the lamp) • All other values (6-100) are switching function specific.
lampBrightness
Enumerated
O
Indicates the intensity of the lamp if it is on (as indicated by lampMode parameter). Actual visible brightness levels are lamp-dependent. The complete set of possible values is: • Unspecified/Normal (default) • Dim • Bright
lampColor
Value
O
• Indicates the color of the lamp. The meaning of the following values are pre-assigned: •
0 - no color
•
1 - Red
•
2 - Yellow
•
3 - Green
•
4 - Blue
•
5 - Unknown (the switching function cannot determine the color of the lamp) (default if this parameter is not present).
•
All other values (6-100) are switching function specific.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
1. At least one of the following parameters shall be provided: lampLabel, lampBrightness, lampColor.
- 520 -
21.2.6
Message Waiting The Message Waiting event indicates that the message waiting status has been changed for a device. This event may be generated in any one of the following ways: •
The message waiting feature has been changed on the telephone.
•
A computing function, on behalf of a user, has invoked the Set Message Waiting service.
21.2.6.1 Event Parameters Table 21-65 Message Waiting—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
targetDevice
SubjectDeviceID
M
Specifies the device where the message waiting feature has changed.
deviceForMessage
DeviceID
O
Specifies the device where the message is waiting.
messageWaitingOn
Boolean
M
Specifies the setting of the message waiting feature. The complete set of possible values is: • FALSE - Message waiting off. • TRUE - Message waiting on.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 521 -
21.2.7
Microphone Gain The Microphone Gain event indicates that the microphone gain setting associated with an auditory apparatus at a specified device has been changed. This event may be generated in any one of the following ways: •
The microphone gain setting has been adjusted on the telephone.
•
A computing function, on behalf of a user, has invoked the Set Microphone Gain service.
21.2.7.1 Event Parameters Table 21-66 Microphone Gain—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
invokingDevice
SubjectDeviceID
M
Specifies the device where the feature was invoked.
auditoryApparatus
AuditoryApparatusID
M
Specifies the auditory apparatus containing the microphone whose gain has changed.
microphoneGain
Choice Structure
M
Specifies the gain as an absolute gain value or that the gain has been incremented or decremented by a switch specified increment. It may be one of the following possible choices: • micGainAbs (Value) - Specifies a value from 0 through 100. 0 indicates silence, and 100 indicates maximum gain. The granularity and quantization of the values 1 though 99 are device specific. • micGainInc (Enumerated) - Specifies if the gain was incremented or decremented by a switch specified amount. The complete set of possible values is: •
increment - the gain value was incremented
•
decrement - the gain value was decremented.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 522 -
21.2.8
Microphone Mute The Microphone Mute event indicates that the microphone mute status for a microphone associated with an auditory apparatus at a specified device has changed. This event may be generated in any one of the following ways: •
The microphone mute feature has been invoked manually on the telephone.
•
A computing function, on behalf of a user, has invoked the Set Microphone Mute service.
21.2.8.1 Event Parameters Table 21-67 Microphone Mute—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
invokingDevice
SubjectDeviceID
M
Specifies the device where the feature was invoked.
auditoryApparatus
AuditoryApparatusID
M
Specifies the auditory apparatus where the mute status was changed.
microphoneMuteOn
Boolean
M
Specifies whether the microphone is muted or not. The complete set of possible values is: • FALSE - Microphone is activated. • TRUE - Microphone is muted.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 523 -
21.2.9
Ringer Status This event indicates that a ringer status associated with a device has changed. This event may be generated in any one of the following ways: •
The ringer status has been changed via the Set Ringer Status service.
•
The switching function has changed the ringer status.
Note that this event only indicates the status of a ringer. Call control events such as the Delivered event should be used to determine call activity at a device. 21.2.9.1 Event Parameters Table 21-68 Ringer Status—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Specifies the device where the ring status was changed.
ringer
RingerID
M
Specifies the ringer associated with the device.
Enumerated
C
Indicates if the ringer is in an active ring cycle. The complete set of possible values is:
ringMode
1
• ringing - The ringer is ringing (provided when either the ringer is physically ringing or is in the “quiet phase” of a ring cycle). • not ringing - The ringer is not in an active ring cycle. ringCount
1
ringDuration
1
ringPattern 1
ringVolume
1
Value (0...1000)
C
Indicates the number of complete ring cycles that the ringer has been ringing. The values 0-999 indicate the actual number of complete ring cycles. The value of 1000 indicates that a value greater than 999 was reached.
Value
C
Indicates the time (in seconds) that the ringer has been ringing. ringDuration should not be provided if ringCount is provided.
Value
C
Indicates the ringing pattern of the ringer. The meaning of the ringing pattern and the number of ringing patterns is device specific.
Choice Structure
C
Indicates the ring volume as an absolute value or that the volume was incremented or decremented by a switch specified increment. The ring volume is associated with the ringer until reset by the switching function or until reset by the Set Ringer Status service. It may be one of the following possible choices: • ringVolAbs (Value) - Specifies a value from 0 through 100. 0 indicates silence, and 100 indicates maximum volume. The granularity and quantization of the values 1 though 99 are device specific. • ringVolInc (Enumerated) - Specifies if the volume was incremented or decremented by a switch specified amount. The complete set of possible values is: •
increment - the volume was incremented
•
decrement - the volume was decremented.
Note that the relationship between the ringer volume and loudness is ringer specific. security
CSTASecurityData
O
- 524 -
Specifies timestamp information, message sequence number, and security information.
Table 21-68 Ringer Status—Event Parameters (concluded) Parameter Name privateData
Type CSTAPrivateData
M/ O/C O
Description Specifies non-standardized information.
1. At least one of the following parameters shall be provided: ringMode, ringCount, ringPattern, ringVolume, ringDuration.
- 525 -
21.2.10 Speaker Mute The Speaker Mute event indicates that the speaker mute status of a speaker associated with an auditory apparatus in a specified device has changed. This event may be generated in any one of the following ways: •
The Speaker Mute feature has been invoked manually on the telephone.
•
The computing function has invoked the Set Speaker Mute service.
21.2.10.1 Event Parameters Table 21-69 Speaker Mute—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
invokingDevice
SubjectDeviceID
M
Specifies the device where the feature was invoked.
auditoryApparatus
AuditoryApparatusID
M
Specifies the auditory apparatus containing the speaker whose mute status has changed.
speakerMuteOn
Boolean
M
Specifies whether the speaker mute setting is on or not. The complete set of possible values is: • FALSE - Mute is off (i.e., speaker is activated). • TRUE - Mute is on (i.e., speaker is muted).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 526 -
21.2.11
Speaker Volume The Speaker Volume event indicates that the speaker volume setting of a speaker associated with an auditory apparatus at a specified device has changed. This event may be generated in any one of the following ways: •
The speaker volume feature has been invoked manually on the telephone.
•
The computing function has invoked the Set Speaker Volume service.
21.2.11.1 Event Parameters Table 21-70 Speaker Volume—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
invokingDevice
SubjectDeviceID
M
Specifies the device where the feature was invoked.
auditoryApparatus
AuditoryApparatusID
M
Specifies the auditory device containing the speaker whose volume has changed.
speakerVolume
Choice Structure
M
Specifies the speaker volume as an absolute value or that the volume was incremented or decremented by a switch specified increment. It may be one of the following possible choices: • speakerVolAbs (Value) - Specifies a value from 0 through 100. 0 indicates silence, and 100 indicates maximum volume. The granularity and quantization of the values 1 though 99 are device specific. • speakerVolInc (Enumerated) - Specifies if the volume was incremented or decremented by a switch specified amount. The complete set of possible values is: •
increment - the volume was incremented
•
decrement - the volume was decremented.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 527 -
22
Logical Device Features This clause describes the feature capabilities as related to a logical device. It including the specification of:
22.1
•
Logical Device Feature services
•
Logical Device Feature events
Services Table 22-1 Logical Device Feature Services Summary Logical Device Feature Service
Description
Pg.
22.1.1 Call Back Non-Call-Related
Requests that the switching function originate a call back call between two devices.
529
22.1.2 Call Back Message NonCall-Related
Requests that the switching function leave a pre-defined message requesting that the target device call the originating device.
530
22.1.3 Cancel Call Back
Cancels a previous (or all) Call Back feature at a device.
532
22.1.4 Cancel Call Back Message
Cancels a previous (or all) Call Back Message feature at a device.
533
22.1.5 Get Agent State
Get the agent state of a specified device.
534
22.1.6 Get Auto Answer
Get the auto-answer status of a specified device
536
22.1.7 Get Auto Work Mode
Get the auto-work mode status of a specified device.
538
22.1.8 Get CallBack
Get the list of callbacks at a specified device.
539
22.1.9 Get Caller ID Status
Get the Caller ID status of a specified device.
541
22.1.10 Get Do Not Disturb
Get the do not disturb status of a specified device.
542
22.1.11 Get Forwarding
Get the forwarding status of a specified device.
544
22.1.12 Get Last Number Dialled
Get the last number dialled at a specified device.
547
22.1.13 Get Presence State
Get the presence at a logical device.
548
22.1.14 Get Routeing Mode
Get the routeing mode at a specified device.
549
22.1.15 Set Agent State
Set the agent state of a specified device.
550
22.1.16 Set Auto Answer
Set the auto-answer status of a specified device.
554
22.1.17 Set Auto Work Mode
Set the auto-work mode status of a specified device.
556
22.1.18 Set Caller ID Status
Set the Caller ID Status at the specified device.
558
22.1.19 Set Do Not Disturb
Set the do not disturb status of a specified device.
559
22.1.20 Set Forwarding
Set the forwarding status of a specified device.
561
22.1.21 Set Presence State
Set the presence at a logical device.
563
22.1.22 Set Routeing Mode
Set the routeing mode of a specified device.
565
- 528 -
22.1.1
C
Call Back Non-Call-Related
S
The Call Back Non-Call-Related service allows a computing function to request that the switching function originate a call back call between two devices. As an example, the service might be used when a device is busy so that a call between an originating device and a target device can be attempted when a device becomes free. 22.1.1.1 Service Request Table 22-2 Call Back Non-Call-Related—Service Request Parameter Name
Type
M/ O/C
Description
originatingDevice
deviceID
M
Specifies the originating device for the call back call.
targetDevice
deviceID
M
Specifies the target device for the call back call.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.1.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 22.1.1.2.1 Positive Acknowledgement Table 22-3 Call Back Non-Call-Related—Positive Acknowledgement Parameter Name
Type
M/O/ C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.1.3 Operational Model 22.1.1.3.1 Connection State Transitions
There are no connection state transitions due to this service. 22.1.1.3.2 Device-Type Monitoring Event Sequences Table 22-4 Call Back Non-Call-Related—Device-Type Monitoring Event Sequences Monitored Device D1 (originatingDevice)
Event Call Back
22.1.1.3.3 Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence. 22.1.1.3.4 Functional Requirements
1. Only one Call Back service request (Call-Related or Non-Call-Related) can be outstanding for any originating and target device pair. It is a switching function option (as indicated by the capability exchange services) if additional Call Back service requests (Call-Related or Non-Call-Related) for that pair result in a positive or negative acknowledgement from the switching function. 2. To cancel a Call Back, the computing function shall issue the Cancel Call Back service, alternatively, the Call back should be manually canceled.
- 529 -
22.1.2
C
Call Back Message Non-Call-Related
S
The Call Back Message Non-Call-Related service allows a computing function to instruct the switching function to leave a pre-defined message requesting that the target device call the originating device. 22.1.2.1 Service Request Table 22-5 Call Back Message Non-Call-Related—Service Request Parameter Name
Type
M/ O/C
Description
originatingDevice
deviceID
M
Specifies the originating device for the call back message.
targetDevice
deviceID
M
Specifies the target device for the call back message.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.2.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 22.1.2.2.1 Positive Acknowledgement Table 22-6 Call Back Message Non-Call-Related—Positive Acknowledgement Parameter Name
Type
M/O/ C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.2.3 Operational Model 22.1.2.3.1 Connection State Transitions
There are no connection state transitions due to this service. 22.1.2.3.2 Device-Type Monitoring Event Sequences Table 22-7 Call Back Message Non-Call-Related—Device-Type Monitoring Event Sequences Monitored Device D1 (originatingDevice)
Event Call Back Message
22.1.2.3.3 Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence. 22.1.2.3.4 Functional Requirements
1. Only one Call Back service request (Call-Related or Non-Call-Related) can be outstanding for any originating and target device pair. It is a switching function option (as indicated by the capability exchange services) if additional Call Back Message service requests (Call-Related or Non-CallRelated) for that pair result in a positive or negative acknowledgement from the switching function. 2. To cancel a Call Back Message, the computing function shall issue the Cancel Call Back Message service, alternatively the Call Back should be manually canceled.
- 530 -
3. The Call Back Message service (Call-Related or Non-Call-Related) differs from the Call Back service in that with the Call Back Message service, no originating device will not call back the target device. Instead, this service leaves a message at the target device. 4. The switching function defines the message left at the target device. A computing function cannot use the service to specify the message content or how the switching function will notify the user (e.g., text message, voice message, indicator only).
- 531 -
22.1.3
C
Cancel Call Back
S
The Cancel Call Back service allows the computing function to cancel a previous (or all) Call Back feature at a device. Note that this service cancels call backs that were created with either call related or non-call related Call Back features. 22.1.3.1 Service Request Table 22-8 Cancel Call Back—Service Request Parameter Name
Type
M/ O/C
Description
originatingDevice
DeviceID
M
The DeviceID of the device who initiated the original Call Back service.
targetDevice
DeviceID
M
The DeviceID of the target of the original Call Back service. If the switching function supports clearing of all Call Back features (as indicated by the capability exchange services) and a null format DeviceID (a DeviceID with 0 characters) is provided, all of the Call Back features at the originatingDevice are cancelled.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information.
22.1.3.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 22.1.3.2.1 Positive Acknowledgement Table 22-9 Cancel Call Back—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Non-standardized information.
22.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.3.3 Operational Model 22.1.3.3.1 Connection State Transitions
There are no connection state transitions due to this service. 22.1.3.3.2 Device-Type Monitoring Event Sequences Table 22-10 Cancel Call Back—Device-Type Monitoring Event Sequences Monitored Device D1 (originatingDevice)
Event Call Back
22.1.3.3.3 Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence. 22.1.3.3.4 Functional Requirements
1. The originating and target DeviceIDs shall be known to the switching function.
- 532 -
22.1.4
C
Cancel Call Back Message
S
The Cancel Call Back Message service allows the computing function to cancel a previous (or all) Call Back Message feature at a device. Note that this service cancels call back messages that were created with either call related or non-call related Call Back Message features. 22.1.4.1 Service Request Table 22-11 Cancel Call Back Message—Service Request Parameter Name
Type
M/ O/C
Description
originatingDevice
DeviceID
M
The DeviceID of the party who initiated the original Call Back Message service.
targetDevice
DeviceID
M
The DeviceID of the target of the original Call Back Message service. If the switching function supports clearing of all Call Back Message features (as indicated by the capability exchange services) and a null format DeviceID (a DeviceID with 0 characters) is provided, all of the Call Back Message features at the originatingDevice are cancelled.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.4.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 22.1.4.2.1 Positive Acknowledgement Table 22-12 Cancel Call Back Message—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.4.3 Operational Model 22.1.4.3.1 Connection State Transitions
There are no connection state transitions due to this service. 22.1.4.3.2 Device-Type Monitoring Event Sequences Table 22-13 Cancel Call Back Message—Device-Type Monitoring Event Sequences Monitored Device D1 (originatingDevice)
Event Call Back Message
22.1.4.3.3 Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence. 22.1.4.3.4 Functional Requirements
1. The originating and target DeviceIDs shall be known to the switching function.
- 533 -
22.1.5
C
Get Agent State
The Get Agent State service provides the agent state at a specified device. 22.1.5.1 Service Request Table 22-14 Get Agent State—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the DeviceID of the device on which the agent state is being queried.
acdGroup
DeviceID
O
Specifies the ACD group to which the associated state applies. If provided, this DeviceID parameter will limit response data to only the group specified by the parameter.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.5.2 Service Response This service follows the atomic acknowledgement model for this request.
- 534 -
S
22.1.5.2.1 Positive Acknowledgement Table 22-15 Get Agent State—Positive Acknowledgement Parameter Name agentStateList
Type
M/ O/C
Description
List of Structures
M
This parameter specifies a list of agent identifiers, and/or their corresponding agent states and ACD groups for a given device. This list parameter has a maximum list size of 32 entries. Each entry contains the following components: • agentID (C) AgentID - Indicates the agentID of the agent with respect to the associated ACD device or ACD group. This component shall be provided if there are multiple agentIDs associated with the agent device. • loggedOnState (M) Boolean - Indicates the logged on state of the agent. The complete set of possible values is: •
TRUE - Agent is logged on.
•
FALSE - Agent is not logged on.
• agentInfo (O) List of Structures - A specific agent may be associated with one or more agent states. The following components are associated with each agent state: •
acdGroup (C) DeviceID - This component is mandatory in an entry when there is more than one entry in the list.
•
agentState (M) Enumerated- The complete set of possible values is Busy, Not Ready, Null, Ready, and Working After Call.
•
pendingAgentState (C) Enumerated - Indicates the pending agent state if the agentState is Busy or Working After Call. This component shall be provided if the switching function is delaying the transition to the pendingAgentState until the agent is no longer Busy or Working After Call, otherwise the parameter is optional. The possible complete set of possible values is: Working After Call, Not Ready, Ready, Null.
•
agentStateCondition (O) Enumerated - Indicates the agent state condition associated with the agent state. The complete set of possible values is: Forced Pause, Other.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.5.3 Operational Model 22.1.5.3.1 Connection State Transitions
There are no connection state transitions due to this service. 22.1.5.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.5.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.5.3.4 Functional Requirements
None. - 535 -
22.1.6
C
Get Auto Answer
S
The Get Auto Answer service provides the auto-answer feature status at a specified device. The auto-answer feature is used to automatically connect to (answer) a call when it arrives at a device, without manual intervention (hands-free mode). The service provides the number of rings at the device before the device is auto-answered. 22.1.6.1 Service Request Table 22-16 Get Auto Answer—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the DeviceID of the device on which the autoanswer status is being queried.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.6.2 Service Response This service follows the atomic acknowledgement model for this request. 22.1.6.2.1 Positive Acknowledgement Table 22-17 Get Auto Answer—Positive Acknowledgement Parameter Name autoAnswerOn
Type
M/ O/C
Boolean
M
Description Specifies the value of the requested feature. The complete set of possible values is: • FALSE - auto answer is not enabled at the device. • TRUE - auto answer is enabled at the device.
numberOfRings
Value
O
Indicates the number of rings before a call is autoanswered.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.6.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.6.3 Operational Model 22.1.6.3.1 Connection State Transitions
There are no connection state transitions due to this service. 22.1.6.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.6.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.6.3.4 Functional Requirements
1. The auto-answer feature is different than the auto-originate feature: a. Auto-originate (specified as the autoOriginate parameter in some Call Control services such as the Make Call service) is used to connect the originating device to the call. It applies only to the originating device (not to the called device) for the specified call.
- 536 -
b. auto-answer applies to all calls that arrive at a device when the device is being called by another device. Auto-answer is a mode that exists until it is changed. The auto-answer mode may be changed via the Set Auto Answer service.
- 537 -
22.1.7
Get Auto Work Mode The Get Auto Work Mode service provides the auto-work mode feature status at a specified device.
The auto-work feature is used to automatically transition an agent state to the WorkingAfterCall state (from the Busy state) after an agent is finished with a call. The feature may also automatically transition the agent state from WorkingAfterCall (to Ready, for example) after a certain amount of time. 22.1.7.1 Service Request Table 22-18 Get Auto Work Mode—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the DeviceID of the device on which the autowork mode status is being queried. The DeviceID may refer to an ACD device, ACD group, or to an Agent.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.7.2 Service Response This service follows the atomic acknowledgement model for this request. 22.1.7.2.1 Positive Acknowledgement Table 22-19 Get Auto Work Mode—Positive Acknowledgement Parameter Name autoWorkOn
Type
M/ O/C
Boolean
M
Description Specifies the value of the requested feature. The complete set of possible values is: • FALSE - Auto-work mode off. • TRUE - Auto-work mode on.
autoWorkInterval
Value
O
Indicates the number of seconds that the agent state remains in the AfterCallWork state. The value of zero indicates that the auto work mode feature does not automatically cause the transition of the agent state from WorkingAfterCall (i.e., the transition must be done manually or via the Set Agent State service).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.7.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.7.3 Operational Model 22.1.7.3.1 Connection State Transitions
There are no connection state transitions due to this service. 22.1.7.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.7.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.7.3.4 Functional Requirements
1. When an agent state transitions to WorkingAfterCall state due to the auto work feature, the state may be terminated before the auto work timer expires by changing the agent state manually or via the Set Agent State service. - 538 -
22.1.8
Get CallBack The Get CallBack service provides the list of callbacks at a specified device. This service provides callbacks where the specified device is either the device that originated the callback or is a device that is the target of the callback.
This service provides call backs that were created with either call related or non-call related call back features. The service also provides callbacks that either involves or does not involve (pre-defined) messages. 22.1.8.1 Service Request Table 22-20 Get CallBack —Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device to query for callbacks.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.8.2 Service Response This service follows the atomic acknowledgement model for this request. 22.1.8.2.1 Positive Acknowledgement Table 22-21 Get CallBack—Positive Acknowledgement Parameter Name callBackList
Type
M/ O/C
List of Structures
C
Description Specifies a list of callbacks that involve the specified device. Each entry consists of the following: • originatingDevice DeviceID (M) - specifies the device that originated the callback. • targetDevice DeviceID (M) - specifies the device which is the target of the callback. • callBackMessageIndicator Boolean (O) - indicates if this callback is a callback message type. Shall be one of the following: •
TRUE - This callback is a callBack message.
•
FALSE - This callback is not a callBack message (default).
This parameter is mandatory if there is at least one callback that involves the specified device. This parameter is not provided if there are no callbacks that involve the specified device. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.8.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.8.3 Operational Model 22.1.8.3.1 Connection State Transitions
There are no connection state transitions due to this service.
- 539 -
22.1.8.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.8.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.8.3.4 Functional Requirements
1. Once a callback has been deactivated the callback is no longer provided by this service. See 6.7.4 for examples of how callbacks are deactivated. 2. Each entry in the callBack list must include the device in the service request as either the originatingDevice or as the targetDevice.
- 540 -
22.1.9
C
Get Caller ID Status
S
The Get Caller ID Status service provides the Caller ID status at the specified device. When the status is set to TRUE, the device’s Caller ID will be provided on all calls originating from it. When the status is set to FALSE, the switching function will not provide the device’s Caller ID on calls, which originate from it, to the called device. 22.1.9.1 Service Request Table 22-22 Get Caller ID Status—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the DeviceID of the device on which the Caller ID status feature is being queried.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.9.2 Service Response This service follows the atomic acknowledgement model for this request. 22.1.9.2.1 Positive Acknowledgement Table 22-23 Get Caller ID Status—Positive Acknowledgement Parameter Name callerIDProvided
Type
M/ O/C
M
Boolean
Description Specifies the value of the requested feature. The complete set of possible values is: • FALSE - Caller ID is not provided on calls originating from this device. • TRUE - Caller ID is provided on calls originating from this device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.9.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.9.3 Operational Model 22.1.9.3.1 Connection State Transitions
There are no connection state transitions due to this service. 22.1.9.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.9.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 541 -
C
22.1.10 Get Do Not Disturb The Get Do Not Disturb service provides the do not disturb feature status at a specified device. The do not disturb feature is used to prevent incoming calls at a device. 22.1.10.1 Service Request Table 22-24 Get Do Not Disturb—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the DeviceID of the device on which the do not disturb feature is being queried.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.10.2 Service Response This service follows the atomic acknowledgement model for this request. 22.1.10.2.1Positive Acknowledgement Table 22-25 Get Do Not Disturb—Positive Acknowledgement Parameter Name doNotDisturbOn
Type
M/ O/C
Boolean
M
Description Specifies the value of the requested feature. The complete set of possible values is: • FALSE - Do not disturb feature is not enabled. • TRUE - Do not disturb feature is enabled.
callOrigination
Bitmap
O
Specifies a bitmap where each bit represents a different type of call origination on which the do not disturb feature is to be honoured. The following is the list of bits (multiple bits may be set): • Internal - Calls originating from within the switching sub-domain. • External - Calls originating from outside the switching sub-domain. If this parameter is not supported, the type of call origination on which do not disturb is honoured is switching function specific (as indicated in the capability exchange services). If this parameter is supported, but not provided by the switching function, then the default value for the bitmap is all bits ON (all types of call origination are honoured).
callingDeviceList
List of DeviceIDs
O
Specifies the calling device(s) from which the do not disturb feature is to be honoured (i.e., calls originating from this device will not be delivered). If this parameter is supported but not provided, then the do not disturb feature is being processed without regard to the calling device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.10.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. - 542 -
S
22.1.10.3 Operational Model 22.1.10.3.1Connection State Transitions
There are no connection state transitions due to this service. 22.1.10.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.10.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 543 -
22.1.11
C
Get Forwarding
S
The Get Forwarding service provides the forwarding feature status at a specified device. The status returned may consist of one or more forwarding types that are active at the specified device based on user defined conditions. The forwarding feature is used to redirect calls that arrive at a specified device to an alternate destination. 22.1.11.1 Service Request Table 22-26 Get Forwarding—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device on which to query.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.11.2 Service Response This service follows the atomic acknowledgement model for this request.
- 544 -
22.1.11.2.1Positive Acknowledgement Table 22-27 Get Forwarding—Positive Acknowledgement Parameter Name forwardList
Type
M/ O/C
Description
List of Structures
M
The list contains one structure per forwardingType/ forwardDN combination. The structure has the following components: • forwardingType (C) Enumerated. Specifies the type of forwarding. It shall be provided for user specified settings and it is optional for switching function default settings (see Functional Requirement #1). The “internal” and “external” types refer to the type of call origination (for example an external call) that will be forwarded if it matches a forwarding type (for example forwardImmExt) enabled at the device. The complete set of possible values is: •
forwardImmediate
•
forwardBusy
•
forwardDND
•
forwardNoAns
•
forwardBusyInt
•
forwardBusyExt
•
forwardDNDInt
•
forwardDNDExt
•
forwardNoAnsInt
•
forwardNoAnsExt
•
forwardImmInt
•
forwardImmExt
• forwardStatus (M) Boolean. Indicates the status of the forwarding type. The complete set of possible values is: •
FALSE - the forwarding type is deactivated.
•
TRUE - the forwarding type is active.
• forwardDN (C) DeviceID. Specifies the destination to which calls are forwarded. It shall be provided for user specified settings and it is optional for switching function default settings (see Functional Requirement #1). • forwardDefault (O) Enumerated. Specifies that the provided forwardingType and/or the forwardDN is a default setting. If the forwardDefault parameter is supported by the switching function and it is not present, the information is not a default setting. The complete set of possible values is: •
defaultForwardingTypeAndForwardDN
•
defaultForwardingType
•
defaultForwardDN
See Functional Requirement #2. • ringCount (O) Value (1...100). Specifies the number of times that the device rings prior to forward no answer. See Functional Requirement 3. • ringDuration (O) Value. Specifies the time (in seconds) that the device rings prior to forward no answer. ringDuration should not be provided if ringCount is provided. See Functional Requirement 3.
- 545 -
Table 22-27 Get Forwarding—Positive Acknowledgement (concluded) Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.11.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.11.3 Operational Model 22.1.11.3.1Connection State Transitions
There are no connection state transitions due to this service. 22.1.11.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.11.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.11.3.4Functional Requirements
1. There are two possible levels of forwarding settings (see 6.7.1, “Forwarding”, on page 69) that can be supported by a switching function. (refer to the capability exchange services for the levels supported by an implementation): •
switching function default settings - a single set of forwarding type/forwarding destination combinations that can be activated/deactivated as a set.
•
user specified settings - individual forwarding type/forwarding destination combinations that can be activated/deactivated one at a time.
2. The forwardDefault component in the forwardList indicates if information in the forwardList is the default information associated with the device (in the case where the forwarding settings have never been changed, for example) and what forwarding level the information is associated with. The possible values for forwardDefault are: •
defaultForwardingTypeAndForwardDN - indicates that the information is associated with the switching function default settings.
•
defaultForwardingType - indicates that forwardingType is a default value associated with user specified settings.
•
defaultForwardDN - indicates that forwardDN is a default value associated with user specified settings.
3. When supported, ringCount or ringDuration is provided for the following forwarding types: •
forwardingType (forwardNoAns)
•
forwardingType (forwardNoAnsInt)
•
forwardingType (forwardNoAnsExt)
- 546 -
C
22.1.12 Get Last Number Dialled
S
The Get Last Number Dialled service provides the last number dialled at a specified device. 22.1.12.1 Service Request Table 22-28 Get Last Number Dialled—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the DeviceID of the device on which the last number is being queried.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.12.2 Service Response This service follows the atomic acknowledgement model for this request. 22.1.12.2.1Positive Acknowledgement Table 22-29 Get Last Number Dialled—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
numberDialled
DeviceID
M
Indicates the last number dialled. “Unknown” is provided if the switching function cannot accurately provide the information.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.12.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.12.3 Operational Model 22.1.12.3.1Connection State Transitions
There are no connection state transitions due to this service. 22.1.12.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.12.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.12.3.4Functional Requirements
1. The last number dialled may be a manually dialled number or may be the originally called device provided in services such as Consultation Call, Make Call, and Make Predictive Call, whichever occurred most recently.
- 547 -
C
22.1.13 Get Presence State The Get Presence State service provides the presence status at a logical device. . 22.1.13.1 Service Request Table 22-30 Get Presence State—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
the logical device on which the presence state feature is being queried
security
CSTASecurityData
O
timestamp information, message sequence number and security information
privateData
CSTAPrivateData
O
non-standardized information
22.1.13.2 Service Response This service follows the atomic acknowledgement model for this request. 22.1.13.2.1Positive Acknowledgement Table 22-31 Get Presence State—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
presenceState
PresenceState
M
the actual presence state
fromTime
TimeInfo
O
the start date and time of the presence state
untilTime
TimeInfo
O
the end date and time of the presence state
place
Characters
O
a natural language description of the user’s current location
mood
Characters
O
a natural language description of the user’s current mood
namedPresenceState
Characters
O
a natural language description of the availability status
security
CSTASecurityData
O
timestamp information, message sequence number and security information
privateData
CSTAPrivateData
O
non-standardized information
22.1.13.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.13.3 Operational Model 22.1.13.3.1Connection State Transitions
There are no connection state transitions due to this service. 22.1.13.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.13.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.13.3.4Functional Requirements
None.
- 548 -
S
C
22.1.14 Get Routeing Mode
S
The Get Routeing Mode service indicates if a device is able to make routeing requests to the computing function. For example, devices that are able to make routeing requests will request instructions (see 20.2.4, “Route Request”, on page 471) when a call arrives at the device. 22.1.14.1 Service Request Table 22-32 Get Routeing Mode—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the DeviceID of the device on which the routeing mode is being queried.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.14.2 Service Response This service follows the atomic acknowledgement model for this request. 22.1.14.2.1Positive Acknowledgement Table 22-33 Get Routeing Mode—Positive Acknowledgement Parameter Name routeingMode
Type Boolean
M/ O/C
Description
M
Indicates the routeing mode of the device. The complete set of possible values is: • TRUE - the device will request routeing instructions when a call arrives at the device. • FALSE - the device will not request routeing instructions.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.14.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.14.3 Operational Model 22.1.14.3.1Connection State Transitions
There are no connection state transitions due to this service. 22.1.14.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.14.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 22.1.14.3.4Functional Requirements
1. The routeing mode may be set by using the “Set Routeing Mode” service or it may be set by the switching function based upon configuration information, for example.
- 549 -
C
22.1.15 Set Agent State
S
The Set Agent State service requests a new agent state at a specified device. In the case where an ACD agent is involved with an ACD call, the transition to the requested state may or may not occur until the current connection transitions to the null state. 22.1.15.1 Service Request Table 22-34 Set Agent State—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the DeviceID for the ACD agent for which the state is to be changed. The device may also be an ACD device or an ACD group device if allowed by the switching function, as indicated by the capability exchange services.
requestedAgentState
Enumerated
M
Specifies the requested agent state. The complete set of possible values is: • loggedOn - Requests that the agent be logged on. • loggedOff - Requests that the agent be logged off. • notReady - Requests that the agent be placed into the notReady agent state. • ready - Requests that the agent be placed into the ready state. • workingAfterCall - Requests that the agent be placed into the workingAfterCall state. Note that the list of values in this parameter is different from the list of values in the agentState parameter in the Get Agent State service.
agentID
AgentID
C
Specifies the agent identifier. This parameter must be provided if there are multiple agentIDs associated with the device.
password
AgentPassword
O
Specifies the agent password. This parameter can only be provided when the requestedAgentState is loggedOn or loggedOff. Note that the switching function may omit this information in subsequent events for security reasons, etc. This parameter type is a character string. The maximum length supported by the switching function is provided via the capabilities exchange services.
group
DeviceID
C
Specifies the agent ACD group that the agent is logging in or out of. The presence or absence of this parameter indicates the type of agent log on model. Refer to the modeling concepts in 6.1.1.6, “Agent”, on page 38 for the when this parameter must be provided.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.15.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 550 -
22.1.15.2.1Positive Acknowledgement Table 22-35 Set Agent State—Positive Acknowledgement Parameter Name pendingAgentState
Type Enumerated
M/ O/C
Description
C
Indicates the agent state that the agent will transition to after the agent state is no longer Busy or Working After Call. The complete set of possible values is: • Working After Call • Not Ready • Ready • Null This parameter shall be provided if the switching function is delaying the transition to the pendingAgentState until the agent is no longer Busy or Working After Call, otherwise the parameter is optional.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.15.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.15.3 Operational Model 22.1.15.3.1Connection State Transitions
There are no connection state transitions due to this service. 22.1.15.3.2Device-Type Monitoring Event Sequences Table 22-36 Set Agent State—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event The event corresponding to the value of the requestedAgentState parameter (i.e., Agent Logged Off, Agent Logged On, Agent Not Ready, Agent Ready, Agent Working After Call). Note that if the current agent state is Busy or WorkingAfterCall, then (depending upon the switching function, as indicated by the capability exchange services) the transition to the requestedAgentState may be delayed until the agent is no longer Busy or WorkingAfterCall. See Functional requirement #1.
22.1.15.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence. 22.1.15.3.4Functional Requirements
1. If the device parameter in the service request is an ACD device or an ACD group, (if allowed by the switching function, as indicated by the capability exchange services), then the service shall be applied to all member/associated devices as if the service were applied to each member/associated device individually. If the device parameter in the service request is an ACD group or ACD device and the switching function does not allow such a device in this service, it shall reject the service request. 2. If this service is issued while the agent is Busy or WorkingAfterCall, the transition to the requestedAgentState may be delayed (depending upon the switching function, as indicated by the capability exchange services) until the agent is no longer Busy or in Agent Working After Call. If the switching function delays the transition in this manner, and if there is a monitor on the Agent Busy or the Agent Working After Call event, the switching function shall generate a Agent Busy or Agent Working After Call event with the pendingAgentState parameter that reflects the requestedAgentState. - 551 -
3. If there is a pendingAgentState while the agent state is Busy or WorkingAfterCall, and a Set Agent State is received, the switching function shall override the previous pendingAgentState with the new requestedAgentState and generate an Agent Busy or an Agent Working After Call event that reflects the new pendingAgentState. If the switching function is unable to override the previous pendingAgentState, it shall reject the service request. Tables 22-37 through Table 22-40 illustrate various examples of agent log on/off. In these tables, the notation G1 and G2 refers to an ACD group and the number in parenthesis refers to the acdGroup parameter in the agent events. The agent log on models are described in 6.1.1.6, “Agent”, on page 38. Table 22-37 Agent Logs On and Then Logs Off an ACD Device Without Entering an ACD Group Action
Agent Events
pre ACD
Agent Logge d On State
Agent State
False
G1: -
Comment
Agent is not yet associated with an ACD device.
G2: Agent logs on to an ACD device
Agent Logged On ()
Agent logs off of an ACD device
Agent Logged Off ()
True
G1: G2: -
False
G1: -
Agent becomes associated with the activities of the ACD device but is not associated with an ACD group.
Agent logs off the ACD device.
G2: -
Table 22-38 Agent Logs On to an ACD Device and then Logs On to Two ACD Groups (Explicit/Two Step Model) Action
Events
pre ACD
Logged On State
Agent State
False
G1: -
True
G1: -
Comment
Agent is not yet associated with an ACD device.
G2: Agent logs on to an ACD device
Agent Logged On ()
Agent logs on to an ACD group
Agent Logged On (G1)
Agent logs on to another ACD group
Agent Logged On (G2)
Agent logs off of an ACD group
Agent Logged Off (G2)
True
Agent logs off another ACD group
Agent Logged Off (G1)
True
G2: True
G1:NotReady G2: -
Agent becomes associated with the activities of the ACD device but is not yet associated with an ACD group. Agent logs on to ACD group 1 and becomes associated with the activities of the ACD group.
Agent Not Ready (G1) True
G1:NotReady G2:NotReady
Agent logs on to ACD group 2 and becomes available for ACD group 2 activity.
Agent Not Ready (G2) G1:NotReady G2: G1: G2: -
- 552 -
Agent logs off of just ACD Group 2, stays in ACD Group 1.
Agent logs off of last ACD Group 1, stays logged on to the ACD device.
Table 22-38 Agent Logs On to an ACD Device and then Logs On to Two ACD Groups (Explicit/Two Step Model) (concluded) Action
Events
Logged On State
Agent State
Agent logs off an ACD device
Agent Logged Off ()
False
G1: -
Comment
Agent logs off the ACD device.
G2: -
Table 22-39 Agent Logs On to an ACD Group Directly (Explicit/One Step Model) Action
Events
Logged On State
Agent State
False
G1: -
pre ACD
G2: Agent logs on to ACD group 2
Agent Logged On () optional
True
Agent Logged On (G2)
False
Agent Logged Off (G2) optional
Agent is not yet associated with an ACD device.
G1: -
Agent logs on to ACD Group 2 directly.
G2: NR
Note that the “Agent Logged On ()” event is optional.
G1: -
Agent logs off the ACD device.
G2: -
Note that the “Agent Logged Off (G2)” event is optional.
Agent Not Ready (G2) Agent logs off.
Comment
Agent Logged Off ()
Table 22-40 Agent Logs On to the ACD Device and is Automatically Logged On to ACD Groups (Implicit/One Step Model) Action
Events
Logged On State
Agent State
False
G1: -
pre ACD
G2: Agent logs on to an ACD group (ACD group not specified)
Agent Logged On () optional
Agent logs off.
Agent Logged Off (G1) optional
True
Agent Logged On (G1)
G1:NotReady G2:NotReady
Comment
Agent is not yet associated with an ACD device.
Agent logs on to ACD and is automatically logged onto groups by the system. Note that the “Agent Logged On ()” event is optional.
Agent Logged On (G2) Agent Not Ready (G1) Agent Not Ready (G2) False
Agent Logged Off (G2) optional Agent Logged Off ()
- 553 -
G1: -
Agent logs off ACD device.
G2: -
Note that the “Agent Logged Off (G1)” and the “Agent Logged Off (G2)”events are optional.
C
22.1.16 Set Auto Answer
S
The Set Auto Answer service allows the computing function to control the auto-answer feature at a specified device. The auto-answer feature is used to automatically connect to (answer) a call when it arrives at a device, without manual intervention (handsfree operation). 22.1.16.1 Service Request Table 22-41 Set Auto Answer—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device on which to set the feature.
autoAnswerOn
Boolean
M
Specifies the requested value of the auto-answer feature. The complete set of possible values is: • FALSE - Auto-answer off. • TRUE - Auto-answer on.
numberOfRings
Value
O
Indicates the number of rings before a call is autoanswered. If not provided (and the parameter is supported), the default will be zero (0).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.16.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 22.1.16.2.1Positive Acknowledgement Table 22-42 Set Auto Answer—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.16.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.16.3 Operational Model 22.1.16.3.1Connection State Transitions
There are no connection state transitions due to this service. 22.1.16.3.2Device-Type Monitoring Event Sequences Table 22-43 Set Auto Answer—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Auto Answer
22.1.16.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence.
- 554 -
22.1.16.3.4Functional Requirements
1. The auto-answer feature is different than the auto-originate feature: •
auto-originate (specified as the autoOriginate parameter in some Call Control services such as the Make Call service) is used to connect the originating device to the call. It applies only to the originating device (not to the called device) for the specified call.
•
auto-answer applies to all calls that arrive at a device when the device is being called by another device. Auto-answer is a mode that exists until it is changed. The auto-answer mode may be changed via the Set Auto Answer service.
- 555 -
C
22.1.17 Set Auto Work Mode
S
The Set Auto Work Mode service allows the computing function to control the auto-work feature at a specified device. The auto-work feature is used to automatically transition an agent state to the WorkingAfterCall state (from the Busy state) after an agent has finished with a call. The feature may also automatically transition the agent state from WorkingAfterCall (to Ready, for example) after a certain amount of time. 22.1.17.1 Service Request Table 22-44 Set Auto Work Mode —Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the DeviceID for the ACD agent for which the auto work mode is to be changed. The device may also be an ACD device or an ACD group device if allowed by the switching function, as indicated by the capability exchange services.
autoWorkOn
Boolean
M
Specifies the requested value of the auto-work feature. The complete set of possible values is: • FALSE - Auto-work off. • TRUE - Auto-work on.
autoWorkInterval
Value (0..6000)
O
Indicates the number of seconds that the agent state remains in the WorkingAfterCall state. The value of zero indicates that the auto work mode feature does not automatically cause the transition of the agent state out of the WorkingAfterCall state (i.e., the transition must be done manually or via the Set Agent State service). If this parameter is not provided, a switching function default value is used.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.17.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 22.1.17.2.1Positive Acknowledgement Table 22-45 Set Auto Work Mode—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.17.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.17.3 Operational Model 22.1.17.3.1Connection State Transitions
There are no connection state transitions due to this service.
- 556 -
22.1.17.3.2Device-Type Monitoring Event Sequences Table 22-46 Set Auto Work Mode—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Auto Work Mode
22.1.17.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence. 22.1.17.3.4Functional Requirements
1. Note that this service is different from the Set Agent State service in that the Set Agent State service causes a transition to a specified agent state (WorkingAfterCall, for example). The Set Auto Work Mode service controls how the switch automatically transitions to/from the WorkingAfterCall state after an agent completes a call. 2. When an agent state transitions to WorkingAfterCall due to the auto-work feature, the WorkingAfterCall state may be terminated before the auto work timer expires by setting the agent to another agent state manually or via the Set Agent State service. 3. If the Auto Work Mode is disabled while the agent state is already in the WorkingAfterCall state, the agent state shall remain in the WorkingAfterCall state until changed (e.g., manually or via the Set Agent State service). 4. The setting of the value of the auto-work mode feature as a result of this service is persistent (i.e., it remains as specified in the service request until it is changed manually or by the Set Agent State service).
- 557 -
C
22.1.18 Set Caller ID Status
S
This Set Caller ID Status service sets the Caller ID Status at the specified device. When the status is set to TRUE, the device’s Caller ID will be provided on all calls originating from it. When the status is set to FALSE, the switching function will not provide the device’s Caller ID on calls, which originate from it, to the called device. 22.1.18.1 Service Request Table 22-47 Set Caller ID Status—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device on which to query.
callerIDProvided
Boolean
M
Specifies whether this device’s caller ID value is being provided on outbound calls. The complete set of possible values is: • FALSE - Caller ID is not to be provided on call(s) originating from this device. • TRUE - Caller ID is to be provided on call(s) originating from this device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.18.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 22.1.18.2.1Positive Acknowledgement Table 22-48 Set Caller ID Status—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.18.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.18.3 Operational Model 22.1.18.3.1Connection State Transitions
There are no connection state transitions due to this service. 22.1.18.3.2Device-Type Monitoring Event Sequences Table 22-49 Set Caller ID Status—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Caller ID Status
22.1.18.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence.
- 558 -
C
22.1.19 Set Do Not Disturb
S
The Set Do Not Disturb service allows the computing function to control the do not disturb feature at a specified device. The do not disturb feature is typically used to prevent a specified device from being alerted. 22.1.19.1 Service Request Table 22-50 Set Do Not Disturb—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device on which to set the feature.
doNotDisturbOn
Boolean
M
Specifies whether the do not disturb feature is enabled. The complete set of possible values is: • FALSE- Do not disturb feature is not enabled. • TRUE- Do not disturb feature is enabled.
callOrigination
Bitmap
O
Specifies a bitmap where each bit represents a different type of call origination on which the do not disturb feature is to be honoured. The following is the list of bits (multiple bits may be set): • Internal - Calls originating from within the switching sub-domain. • External - Calls originating from outside the switching sub-domain. If this parameter is not supported, the type of call origination on which do not disturb is honoured is switching function specific (as indicated in the capability exchange services). If this parameter is supported, but not provided by the computing function, then the default value for the bitmap is all bits on (all types of call origination are honoured).
callingDeviceList
List of DeviceIDs
O
Specifies the calling device(s) from which the do not disturb feature is to be honoured (i.e., calls originating from this device will not be delivered). If this parameter is supported but not provided, then the do not disturb feature shall be processed without regard to the calling device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.19.1.1Service Response
The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request.
- 559 -
22.1.19.1.2Positive Acknowledgement Table 22-51 Set Do Not Disturb—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.19.1.3Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.19.2 Operational Model 22.1.19.2.1Connection State Transitions
Existing connected and held calls are not affected. Calls that are alerting or queued when this feature is turned on may be affected in that the newly-activated feature may be applied to them by the switching function. 22.1.19.2.2Device-Type Monitoring Event Sequences Table 22-52 Set Do Not Disturb—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Do Not Disturb
22.1.19.2.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence. 22.1.19.2.4Functional Requirements
1. If a device is called that has do not disturb activated, depending upon the Forwarding type activated at the device, the call may be forwarded to an alternate destination.
- 560 -
C
22.1.20 Set Forwarding
S
The Set Forwarding service allows the computing function to control the forwarding feature at a specified device based on user defined conditions. The forwarding feature is used to redirect calls that arrive at a specified device to an alternate destination. This service allows only one user-specified setting (forwarding type/forward-destination combination) to be changed per service invocation. 22.1.20.1 Service Request Table 22-53 Set Forwarding—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device on which to set the feature.
forwardingType
Enumerated
C
Specifies the type of forwarding. The “internal” and “external” types refer to the type of call origination (for example an external call) that will be forwarded if it matches a forwarding type (for example, forwardImmExt) enabled at the device. The complete set of possible values is: • forwardImmediate • forwardBusy • forwardDND • forwardNoAns • forwardBusyInt • forwardBusyExt • forwardDNDInt • forwardDNDExt • forwardNoAnsInt • forwardNoAnsExt • forwardImmInt • forwardImmExt This parameter shall be provided for user specified forwarding settings and shall not be provided for switching function default settings. See Functional Requirement #1.
activateForward
Boolean
M
Indicates the status of the forwarding type. The complete set of possible values is: • FALSE - Deactivate forwarding. • TRUE - Activate forwarding.
forwardDN
DeviceID
C
Specifies the device to which new calls are forwarded. This parameter shall be provided for user specified forwarding settings when activateForward is TRUE (it is optional when FALSE). It shall not be provided for switching function default settings. See Functional Requirement #1.
ringCount
Value (1...100)
O
Specifies the number of times a device should ring prior to forwarding no answer. See Functional Requirement #2.
ringDuration
Value
O
Specifies the time (in seconds) that the device should ring prior to forwarding no answer. ringDuration should not be provided if ringCount is provided. See Functional Requirement #2.
- 561 -
Table 22-53 Set Forwarding—Service Request (concluded) Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.20.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 22.1.20.2.1Positive Acknowledgement Table 22-54 Set Forwarding—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.20.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.20.3 Operation Model 22.1.20.3.1Functional Requirements
1. To activate or deactivate user specified settings, the computing function shall specify the forwardingType. To activate or deactivate switching function default settings, the computing function shall not specify the forwardingType. The computing function should use the capabilities exchange services to determine which level(s) of forwarding settings are supported by the switching function. 2. If ringCount or ringDuration is specified, the activateForward shall be TRUE and the forwardingType or default value shall be one of the following values: •
forwardingType (forwardNoAns)
•
forwardingType (forwardNoAnsInt)
•
forwardingType (forwardNoAnsExt)
3. If multiple user-specified settings need to be set and if activation of multiple settings is supported by the switching function (as indicated through the capabilities exchange services), multiple Set Forwarding service requests can be used to activate multiple settings for the same device.
- 562 -
C
22.1.21 Set Presence State
S
The Set Presence State service allows the computing function to control the presence state at a specified logical device based on the user defined conditions. 22.1.21.1 Service Request Table 22-55 Set Presence State—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
the logical device on which to set the feature
requestedPresenceState
PresenceState
M
the requested presence state
fromTime
TimeInfo
O
the start date and time of the presence state
untilTime
TimeInfo
O
the end date and time of the presence state
place
Characters
O
a natural language description of the user’s current location
mood
Characters
O
a natural language description of the user’s current mood
namedPresenceState
Characters
O
a natural language description of the availability status
security
CSTASecurityData
O
timestamp information, message sequence number and security information
privateData
CSTAPrivateData
O
non-standardized information
22.1.21.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 22.1.21.2.1Positive Acknowledgement Table 22-56 Set Presence State—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
timestamp information, message sequence number and security information
privateData
CSTAPrivateData
O
non-standardized information
22.1.21.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.21.3 Operation Model 22.1.21.3.1Connection State Transitions
There are no connection state transitions due to this service. 22.1.21.3.2Device-Type Monitoring Event Sequences Table 22-57 Set Presence State—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Presence State
22.1.21.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence.
- 563 -
22.1.21.3.4Functional Requirements
1. Changing the presence state does not have any influence to other services. E.g. the requestedPresenceState dnd does not activate the feature do not disturb (see 22.1.19, “Set Do Not Disturb”, on page 559).
- 564 -
C
22.1.22 Set Routeing Mode
S
The Set Routeing Mode service allows the computing function to control the routeing mode at a specified device. The routeing mode indicates if a device is able to make routeing requests to the computing function. For example, if the routeing mode is set, a device may request routeing instructions (see 20.2.4, “Route Request”, on page 471) from the computing function when a call arrives at the device. 22.1.22.1 Service Request Table 22-58 Set Routeing Mode—Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device on which to set the feature.
routeingMode
Boolean
M
Specifies the routeing mode of the device. The complete set of possible values is: • TRUE - the device will request routeing instructions from the computing function when a call arrives at the device. • FALSE - the device will not request routeing instructions.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.22.2 Service Response The capability exchange services describe the type of acknowledgement model (atomic or multi-step) that the switching function supports for this service request. 22.1.22.2.1Positive Acknowledgement Table 22-59 Set Routeing Mode—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.1.22.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 22.1.22.3 Operational Model 22.1.22.3.1Connection State Transitions
There are no connection state transitions due to this service. 22.1.22.3.2Device-Type Monitoring Event Sequences Table 22-60 Set Routeing Mode—Device-Type Monitoring Event Sequences Monitored Device D1 (device)
Event Routeing Mode
22.1.22.3.3Call-Type Monitoring Event Sequences
If the monitor object is a device, if supported, the monitoring event sequence is the same as the DeviceType Monitoring event sequence.
- 565 -
22.1.22.3.4Functional Requirements
1. Some switching functions may change the routeing mode of a device without using this service. This may occur based upon configuration information in the switching function or for other reasons.
- 566 -
22.2
Events Table 22-61 Logical Device Feature Event Summary Logical Device Feature Event
Description
Pg.
22.2.1 Agent Busy
An agent is occupied with serving an ACD call.
568
22.2.2 Agent Logged Off
An agent has logged off of an ACD group or an ACD device.
569
22.2.3 Agent Logged On
An agent has logged on to an ACD group or an ACD device.
570
22.2.4 Agent Not Ready
An agent is unavailable and cannot receive incoming ACD calls.
571
22.2.5 Agent Ready
An agent is available for an ACD call.
573
22.2.6 Agent Working After Call
An agent is involved with after call work and cannot receive ACD calls.
574
22.2.7 Auto Answer
The auto-answer status has changed.
576
22.2.8 Auto Work Mode
The auto-work mode status has changed.
577
22.2.9 Call Back
The call back feature status has changed.
578
22.2.10 Call Back Message
The call back message status has changed.
579
22.2.11 Caller ID Status
The Caller ID status has been changed for a device.
580
22.2.12 Do Not Disturb
The do not disturb status has changed.
581
22.2.13 Forwarding
The forwarding status has changed.
582
22.2.14 Presence State
The presence state has changed.
585
22.2.15 Routeing Mode
The routeing mode status has changed.
586
- 567 -
22.2.1
Agent Busy The Agent Busy event indicates that an agent has entered the Busy state. In this state an agent is involved with an existing ACD call at a device, even if that call is on hold at the device. It also implies that the agent may be able to accept non-ACD calls. Calls between agents, calls between supervisors and agents and private calls may or may not cause this transition.
An example of when this event is generated is when an agent is connected to an ACD call. 22.2.1.1 Event Parameters Table 22-62 Agent Busy—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
agentDevice
SubjectDeviceID
M
Indicates the device at which the agent entered the Agent Busy state.
agentID
AgentID
C
Indicates the agent identifier. This parameter shall be provided if there are multiple agentIDs associated with the agent device.
acdGroup
DeviceID
C
Indicates the acd group. This parameter shall be provided if the event is associated with an ACD group activity otherwise it shall not be provided. See 6.1.1.6.5, “Agent State Models”, on page 40.
pendingAgentState
Enumerated
C
Indicates the agent state that the agent will transition to after the agent state is no longer Busy. The complete set of possible values is: • Working After Call • Not Ready • Ready • Null This parameter shall be provided if the switching function is delaying the transition to the pendingAgentState until the agent is no longer Busy, otherwise the parameter is optional.
cause
EventCause
O
Indicates a reason for the event.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.2.1.2 Event Causes Table 22-63 Agent Busy—Event Causes Event Cause Normal
Description An agent is connected to an ACD call.
Associated Features Any feature
22.2.1.3 Functional Requirements 1. This event can be reported in conjunction with either a monitor on the ACD device, ACD group or the device associated with the agent. For more details on ACD and the agent, see 6.1.1.6, “Agent”, on page 38 and 6.1.1.4.3, “ACD Device Category”, on page 25. 2. Call Control events provide information on involvement with both ACD and non-ACD calls.
- 568 -
22.2.2
Agent Logged Off The Agent Logged Off event indicates that an agent has logged off an ACD device or an ACD group. Typical examples of when this event may be generated are: •
An agent logs off using the telephone.
•
An agent is logged off via the Set Agent State service.
•
A supervisor logs off an agent on behalf of the agent.
•
A logged on device leaves a switching sub-domain or becomes an invalid device in a switching subdomain (is deconfigured, for example).
22.2.2.1 Event Parameters Table 22-64 Agent Logged Off—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
agentDevice
SubjectDeviceID
M
Indicates the device where the agent logged off.
agentID
AgentID
C
Indicates the agent identifier. This parameter shall be provided if there are multiple agentIDs associated with the agent device.
acdGroup
DeviceID
C
Indicates the ACD group from which the agent logged off. This parameter shall be provided if the agent is logging off of an ACD group. See 6.1.1.6, “Agent”, on page 38.
agentPassword
AgentPassword
O
Indicates the agent password. Note that the switching function may omit this information for security reasons, etc.
cause
EventCause
O
Indicates a reason for the event.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.2.2.2 Event Causes Table 22-65 Agent Logged Off—Event Causes Event Cause Normal
Description An agent has logged off an ACD group or ACD device.
- 569 -
Associated Features Any feature
22.2.3
Agent Logged On The Agent Logged On event indicates that an agent is logged-on at a particular device to an ACD device or ACD group and is ready to contribute to the activities of the ACD device or ACD group. It does not indicate that the agent is ready to accept ACD calls. Typical examples of when this event may be generated are: •
The agent logged on using the telephone.
•
The agent logged on using the Set Agent State service.
•
During system start-up, if the agent is configured for logging on automatically.
22.2.3.1 Event Parameters Table 22-66 Agent Logged On—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
agentDevice
SubjectDeviceID
M
Indicates the device where the agent logged on.
agentID
AgentID
C
Indicates the agent identifier. This parameter shall be provided if there are multiple agentIDs associated with the agent device.
acdGroup
DeviceID
C
Indicates the ACD group to which the agent logged on. This parameter shall be provided if the agent is logging on to an ACD group. See 6.1.1.6, “Agent”, on page 38.
agentPassword
AgentPassword
O
Indicates the agent password that was used for logging on. Note that the switching function may omit this information for security reasons, etc.
cause
EventCause
O
Indicates a reason for the event.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.2.3.2 Event Causes Table 22-67 Agent Logged On—Event Causes Event Cause Normal
Description An agent has logged on to an ACD group or ACD device.
Associated Features Any feature
22.2.3.3 Functional Requirements 1. This event can be reported in conjunction with either a monitor on the ACD group or the device where the agent is logging on (i.e. agent device). For more details on ACD and the agent, see 6.1.1.6, “Agent”, on page 38 and 6.1.1.4.3, “ACD Device Category”, on page 25. 2. Call Control events provide information on involvement with both ACD and non-ACD calls.
- 570 -
22.2.4
Agent Not Ready The Agent Not Ready event indicates that an agent has entered the Agent Not Ready state. In this state an agent is logged-on at a particular device to an ACD device or ACD group but is not prepared to handle calls that the ACD distributes. While in this state an agent may receive calls that are not ACD calls. Typical examples of when this event may be generated are: •
An agent logs on using the telephone and is placed into the Not Ready agent state.
•
An agent invokes the Agent Not Ready feature on the telephone.
•
The agent invoked Agent Not Ready by using the Set Agent State service.
•
A supervisor invokes the Agent Not Ready feature on behalf of the agent.
22.2.4.1 Event Parameters Table 22-68 Agent Not Ready—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
agentDevice
SubjectDeviceID
M
Indicates the device at which the agent entered the Agent Not Ready state.
agentID
AgentID
C
Indicates the agent identifier. This parameter shall be provided if there are multiple agentIDs associated with the agent device.
acdGroup
DeviceID
C
Indicates the ACD group from which the agent logged on. This parameter shall be provided if the event is associated with an ACD group activity otherwise it shall not be provided. See 6.1.1.6, “Agent”, on page 38.
cause
EventCause
O
Indicates a reason for the event.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.2.4.2 Event Causes Table 22-69 Agent Not Ready—Event Causes Event Cause
Description
Associated Features
Auto Work
The event is due to the auto-work feature.
Auto-work
Normal
An agent cannot receive incoming ACD calls but is still logged on to an ACD group or ACD device (a more specific cause cannot be provided).
Any feature
Forced Pause
The agent entered a periodic non-working condition. This usually occurs because of regulations that requires agents to have a certain amount of time between handling successive ACD calls.
ACD call
Forced Transition
The agent state is Not Ready due to activity in another ACD device or an ACD group.
ACD call
22.2.4.3 Functional Requirements 1. This event can be reported in conjunction with either a monitor on the ACD device, ACD group, or the device associated with the agent. For more details on ACD and the agent, see 6.1.1.6, “Agent”, on page 38 and 6.1.1.4.3, “ACD Device Category”, on page 25. - 571 -
2. Call Control events provide information on involvement with both ACD and non-ACD calls.
- 572 -
22.2.5
Agent Ready The Agent Ready event indicates that an agent has entered the Ready state. In this state, an agent is logged-on at a particular device to an ACD device or ACD group and is prepared to handle ACD calls even though it may be involved with non-ACD calls. Typical examples of when this event may be generated are: •
An agent auto-work timer expires. (This is a configuration option.)
•
An agent invokes the Agent Ready feature on the telephone.
•
The agent invoked Agent Ready by using the Set Agent State service.
•
A supervisor invokes the Agent Ready feature on behalf of the agent.
22.2.5.1 Event Parameters Table 22-70 Agent Ready—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
agentDevice
SubjectDeviceID
M
Indicates the device at which the agent entered the Agent Ready state.
agentID
AgentID
C
Indicates the agent identifier. This parameter shall be provided if there are multiple agentIDs associated with the agent device.
acdGroup
DeviceID
C
Indicates the ACD group from which the agent logged on. This parameter shall be provided if the event is associated with an ACD group activity otherwise it shall not be provided. See 6.1.1.6, “Agent”, on page 38.
cause
EventCause
O
Indicates a reason for the event.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.2.5.2 Event Causes Table 22-71 Agent Ready—Event Causes Event Cause
Description
Associated Features
Auto Work
The event is due to the auto-work feature.
Auto-work
Normal
An agent may receive ACD calls.
Any feature
22.2.5.3 Functional Requirements 1. This event can be reported in conjunction with either a monitor on the ACD device, ACD group or the device associated with the agent. For more details on ACD and the agent, see 6.1.1.6, “Agent”, on page 38 and 6.1.1.4.3, “ACD Device Category”, on page 25. 2. Call Control events provide information on involvement with both ACD and non-ACD calls.
- 573 -
22.2.6
Agent Working After Call The Agent Working After Call event indicates that an agent has entered the Working After Call state. In this state an agent is no longer connected to an ACD call but is still occupied with work related to a previous ACD call. In this state, an agent cannot receive ACD calls but may be able to receive non-ACD calls. The agent may be performing administrative duties (e.g., updating a business order form) for a previous call, or may be involved with a non-ACD call. Typical examples of when this event may be generated are: •
An agent completes an ACD call and goes into the workingAfterCall state. (This is a configuration option.)
•
An agent invokes the Working After Call feature on the telephone.
•
An agent invoked workingAfterCall state by using the Set Agent State service.
22.2.6.1 Event Parameters Table 22-72 Agent Working After Call—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
agentDevice
SubjectDeviceID
M
Indicates the device at which the agent entered the workingAfterCall state.
agentID
AgentID
C
Indicates the agent identifier. This parameter shall be provided if there are multiple agentIDs associated with the agent device.
acdGroup
DeviceID
C
Indicates the ACD group from which the agent logged on. This parameter shall be provided if the event is associated with an ACD group activity otherwise it shall not be provided. See 6.1.1.6, “Agent”, on page 38.
pendingAgentState
Enumerated
C
Indicates the agent state that the agent will transition to after the agent state is no longer WorkingAfterCall. The complete set of possible values is: • Not Ready • Ready • Null This parameter shall be provided if the switching function is delaying the transition to the pendingAgentState until the agent is no longer AfterCallWork, otherwise the parameter is optional.
cause
EventCause
O
Indicates a reason for the event.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.2.6.2 Event Causes Table 22-73 Agent Working After Call—Event Causes Event Cause
Description
Associated Features
Auto Work
The event is due to the auto-work feature.
Auto-work
Normal
An agent is no longer connected to the ACD call but is still occupied with work related to the call.
Any feature
- 574 -
22.2.6.3 Functional Requirements 1. This event can be reported in conjunction with either a monitor on the ACD device, ACD group or the device associated with the agent. For more details on ACD and the agent, see 6.1.1.6, “Agent”, on page 38 and 6.1.1.4.3, “ACD Device Category”, on page 25. 2. Call Control events provide information on involvement with both ACD and non-ACD calls.
- 575 -
22.2.7
Auto Answer The Auto Answer event indicates that the auto answer status has changed (On/Off) for a device. Typical examples of when this event may be generated are: •
The auto-answer feature has been changed on the telephone.
•
The computing function, on behalf of a user, has invoked the Set Auto Answer service.
22.2.7.1 Event Parameters Table 22-74 Auto Answer—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
invokingDevice
SubjectDeviceID
M
Indicates the device where the auto answer status has changed.
autoAnswerOn
Boolean
M
Indicates the status of the feature. Shall be one of the following: •
FALSE - Auto-answer feature is not enabled.
•
TRUE - Auto-answer feature is enabled (on).
numberOfRings
Value
O
Indicates the number of rings before a call is auto answered.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 576 -
22.2.8
Auto Work Mode The Auto Work Mode event indicates that the auto work mode feature has changed for a specific device. The auto-work feature is used to automatically transition an agent state to the WorkingAfterCall state (from the Busy state) after an agent is finished with a call. The feature may also automatically transition the agent state from WorkingAfterCall (to Ready, for example) after a certain amount of time. Typical examples of when this event may be generated are: •
The auto-work mode feature has been changed on the telephone.
•
The computing function, on behalf of a user, has invoked the Set Auto Work Mode service.
22.2.8.1 Event Parameters Table 22-75 Auto Work Mode—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
invokingDevice
SubjectDeviceID
M
Indicates the device where the auto work mode status has changed.
autoWorkOn
Boolean
M
Indicates the status of the feature. It shall be one of the following: • FALSE - Auto-work mode off. • TRUE - Auto-work mode on.
autoWorkInterval
Value
M
Indicates the number of seconds that the agent state remains in the AfterCallWork state. The value of zero indicates that the auto work mode feature does not automatically cause the transition of the agent state from WorkingAfterCall (i.e., the transition must be done manually or via the Set Agent State service).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 577 -
22.2.9
Call Back The Call Back event indicates that a call back feature has been set or cancelled between two devices. Typical examples of when this event may be generated are: •
A call back was set or a pending call back was cancelled manually from a phone.
•
The computing function, on behalf of a user, set or cancelled a call back.
22.2.9.1 Event Parameters Table 22-76 Call Back—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
originatingDevice
SubjectDeviceID
M
Indicates the DeviceID of the originating device when the call back relationship was established.
targetDevice
SubjectDeviceID
M
Indicates the DeviceID of the target device when the call back relationship was established.
callBackSetCancelled
Boolean
M
Indicates whether a call back was set or cancelled. Shall be one of the following: • FALSE - Call Back was cancelled. • TRUE - Call Back was set.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 578 -
22.2.10 Call Back Message The Call Back Message event indicates that a call back message feature has been set or cancelled between two devices. Typical examples of when this event may be generated are: •
A call back message was set or a pending call back message was cancelled manually from a phone.
•
The computing function, on behalf of a user, set or cancelled a call back message.
22.2.10.1 Event Parameters Table 22-77 Call Back Message—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
originatingDevice
SubjectDeviceID
M
Indicates the DeviceID of the “return-call-to” device when the call back message relationship was established).
targetDevice
SubjectDeviceID
M
Indicates the DeviceID of the target device at which the call back message was lodged.
callBackMsgSetCancelled
Boolean
M
Indicates whether a call back message was set or cancelled. Shall be one of the following: • FALSE - Call Back Message was cancelled. • TRUE - Call Back message was set.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 579 -
22.2.11
Caller ID Status The CallerID Status event indicates that the caller ID status has been changed for a device. Typical examples of when this event may be generated are: •
The Caller ID status change has been invoked on the telephone.
•
The computing function, on behalf of a user, has invoked the Set Caller ID Status service.
22.2.11.1 Event Parameters Table 22-78 Caller ID Status—Event Parameters Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device on which to set the feature.
callerIDProvided
Boolean
M
Specifies the value of the requested feature. The complete set of possible values is: • FALSE - Caller ID is not to be provided on calls originating from this device. • TRUE - Caller ID is to be provided on calls originating from this device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 580 -
22.2.12 Do Not Disturb The Do Not Disturb event indicates that the do not disturb feature has been changed for a device. Typical examples of when this event may be generated are: •
The do not disturb feature has been changed on the telephone.
•
The computing function, on behalf of a user, has invoked the Set Do Not Disturb service.
22.2.12.1 Event Parameters Table 22-79 Do Not Disturb—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Indicates the device where the do not disturb feature was changed.
doNotDisturbOn
Boolean
M
Indicates the status of the feature. The complete set of possible values is: • FALSE - Do not disturb feature is not enabled. • TRUE - Do not disturb feature is enabled.
callOrigination
Bitmap
O
Specifies a bitmap where each bit represents a different type of call origination on which the do not disturb feature is to be honoured. The following is the list of bits (multiple bits may be set): • Internal - Calls originating from within the switching sub-domain. • External - Calls origination from outside the switching sub-domain. If this parameter is not supported, the type of call origination on which do not disturb is honoured is switching function specific.
callingDeviceList
List of DeviceIDs
O
Specifies the calling device(s) from which the do not disturb feature is to be honoured (i.e., calls originating from this device will not be delivered). If this parameter is supported but not provided, then the do not disturb feature is being processed without regard to the calling device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
- 581 -
22.2.13 Forwarding The Forwarding event indicates that the forwarding feature has been changed for a device. Typical examples of when this event may be generated are: •
The forwarding feature has been changed on the telephone.
•
The computing function, on behalf of a user, has invoked the Set Forwarding service.
22.2.13.1 Event Parameters Table 22-80 Forwarding—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Indicates the device where the forwarding feature was changed.
forwardingType
Enumerated
O
Indicates the type of forwarding. It shall be provided for user specified settings and it is optional for switching function default settings (see Functional Requirement #3). The “internal” and “external” types refer to the type of call origination (for example an external call) that will be forwarded if it matches a forwarding type (for example forwardImmExt) enabled at the device. The complete set of possible values is: • forwardImmediate • forwardBusy • forwardNoAns • forwardDND • forwardBusyInt • forwardBusyExt • forwardNoAnsInt • forwardNoAnsExt • forwardImmInt • forwardImmExt • forwardDNDInt • forwardDNDExt
forwardStatus
Boolean
M
Indicates the status of the forwarding type. The complete set of possible values is: • FALSE - the forwarding type is deactivated. • TRUE - the forwarding type is active.
forwardTo
DeviceID
O
- 582 -
Specifies the destination to which calls are forwarded. It shall be provided for user specified settings and it is optional for switching function default settings (see Functional Requirement #3).
Table 22-80 Forwarding—Event Parameters (concluded) Parameter Name forwardDefault
Type Enumerated
M/ O/C
Description
O
Specifies that provided forwardingType and/or the forwardDN is a default setting. If the forwardDefault parameter is supported by the switching function and it is not present, the forwarding information is not a default setting. The complete set of possible values is: • defaultForwardingTypeAndForwardDN • defaultForwardingType • defaultForwardDN. See Functional Requirement #4.
ringCount
Value (1...100)
O
Specifies the number of times a device should ring prior to forwarding no answer. See Functional Requirement #5.
ringDuration
Value
O
Specifies the time (in seconds) that a device rings prior to forwarding no answer. ringDuration should not be provided if ringCount is provided. See Functional Requirement #5.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.2.13.2 Functional Requirements 1. Only a single forwardingType parameter is provided per Forwarding event. If multiple forwarding types are changed for the same device, the switching function provides multiple Forwarding events. 2. This event is only generated when forwarding status is changed, not when forwarding occurs. 3. There are two possible levels of forwarding settings (see 6.7.1, “Forwarding”, on page 69) that can be supported by a switching function. (refer to the capability exchange services for the levels supported by an implementation): •
switching function default settings - a single set of forwarding type/forwarding destination combinations that can be activated/deactivated as a set.
•
user specified settings - individual forwarding type/forwarding destination combinations that can be activated/deactivated one at a time.
4. The forwardDefault parameter indicates if either the forwardingType or the forwardDN parameters is default information associated with the device (in the case where the forwarding settings have never been changed, for example) and what forwarding level the information is associated with. The possible values for forwardDefault are: •
defaultForwardingTypeAndForwardDN - indicates that the information is associated with the switching function default settings.
•
defaultForwardingType - indicates that forwardingType is a default value associated with user specified settings.
•
defaultForwardDN - indicates that forwardDN is a default value associated with user specified settings.
5. ringCount or ringDuration, if supported, is only specified when one of the following forwarding types is provided: •
forwardNoAns - 583 -
•
forwardNoAnsInt
•
forwardNoAnsExt
- 584 -
22.2.14 Presence State The Presence State event indicates that the presence state has been changed for a device. Typical examples of when this event may be generated are: •
The presence state has been changed on the telephone.
•
The computing function, on behalf of a user, has invoked the Set Presence State service.
22.2.14.1 Event Parameters Table 22-81 Presence State—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to a monitor.
device
SubjectDeviceID
M
Indicates the logical device where the presence status was changed.
presenceState
PresenceState
M
the actual presence state
fromTime
TimeInfo
O
the start date and time of the presence state
untilTime
TimeInfo
O
the end date and time of the presence state
place
Characters
O
a natural language description of the user’s current location
mood
Characters
O
a natural language description of the user’s current mood
namedPresenceState
Characters
O
a natural language description of the availability status
security
CSTASecurityData
O
timestamp information, message sequence number and security information
privateData
CSTAPrivateData
O
non-standardized information
22.2.14.2 Functional Requirements None.
- 585 -
22.2.15 Routeing Mode The Routeing Mode event indicates that the routeing mode has been changed for a device. Typical examples of when this event may be generated are: •
The computing function, on behalf of a user, has invoked the Set Routeing Mode service.
•
The switching function has changed the routeing mode for a device.
22.2.15.1 Event Parameters Table 22-82 Routeing Mode—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Indicates the device where the routeing mode was changed.
routeingMode
Boolean
M
Indicates the routeing mode of the device. The complete set of possible values is: • TRUE - the device will request routeing instructions (when a call arrives at the device, for example). • FALSE - the device will not request routeing instructions.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
22.2.15.2 Functional Requirements 1. This event is only generated when the routeing mode is changed, not when a call arrives at the device or when the Route Request service is issued.
- 586 -
23
Device Maintenance Events
23.1
Events Table 23-1 Device Maintenance Events Summary Device Maintenance Event
Description
Pg.
23.1.1 Back In Service
Indicates that the device has been returned to service.
588
23.1.2 Device Capabilities Changed
Indicates that the device level information has changed.
589
23.1.3 Out Of Service
Indicates that the device has entered a maintenance state (i.e., has been taken out of service).
590
23.1.4 Partially In Service
Indicates that the device has entered a partially in service maintenance state.
591
- 587 -
23.1.1
Back In Service
The Back In Service event indicates that the device has been returned to service and is operating normally. 23.1.1.1 Event Parameters Table 23-2 Back In Service—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Indicates the device that is back in service.
cause
EventCause
O
Specifies a reason for the event.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
23.1.1.2 Event Causes Table 23-3 Back In Service—Event Causes Event Cause Normal
Description The device is back in service.
Associated Features Maintenance
23.1.1.3 Functional Requirements 1. If the Device Capabilities Changed Event is supported by the switching function (as indicated by the capability exchange services) then the Back In Service event does not imply that the capabilities of the out-of-service device have changed - only that the device is back in service.
- 588 -
23.1.2
Device Capabilities Changed The Device Capabilities Changed event indicates that device level information that can be obtained with the capability exchange services (e.g. the Get Physical Device Information and/or Get Logical Device Information services) has changed.
The current device level capability information can be obtained by issuing a Get Physical Device Information and/or a Get Logical Device Information service. 23.1.2.1 Event Parameters Table 23-4 Device Capabilities Changed—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Indicates the device whose information has changed.
cause
EventCause
O
Specifies a reason for the event.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
23.1.2.2 Event Causes Table 23-5 Device Capabilities Changed—Event Causes Event Cause Normal
Description Device information has changed.
Associated Features Maintenance, Capabilities Exchange
23.1.2.3 Functional Requirements 1. The Device Capabilities Changed event shall be generated whether or not the device level capability information has been previously obtained via the capability exchange services.
- 589 -
23.1.3
Out Of Service
The Out Of Service event indicates that the device has entered a maintenance state (i.e., has been taken out of service) and can no longer accept calls and some categories of CSTA service requests (Call Control services, for example). 23.1.3.1 Event Parameters Table 23-6 Out Of Service—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Indicates the device that has been taken out of service.
cause
EventCause
O
Specifies a reason for the event.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
23.1.3.2 Event Causes Table 23-7 Out Of Service—Event Causes Event Cause
Description
Associated Features
Forced Transition
Another dependent resource has caused this device to go out of service.
Maintenance
Maintenance
The device has been taken out of service for maintenance.
Maintenance
Normal
The device has been taken out of service (a more specific cause is not available).
Maintenance
23.1.3.3 Functional Requirements 1. This event is generated when any logical and physical element associated with a particular device configuration becomes out of service. For devices with both logical and physical elements, separate Out Of Service events may be generated when the logical and physical elements become out of service. 2. When a device becomes out of service, existing monitors are not removed (e.g., existing MonitorCrossRefIDs remain valid). However: •
It may not be possible (as specified in the capability exchange services) to start a new monitor on an out of service device. If a monitor cannot be started because the a device is out of service, the Monitor Start service will result in a negative acknowledgment (with an error code of Device Out Of Service).
•
Event flows over an existing monitors may be reduced (or even completely stopped except for the Back In Service event).
•
Snapshot services (such as Snapshot Device) may result in a negative acknowledgment (with an error code of Device Out Of Service) if attempted on an out of service device.
3. If the Device Capabilities Changed Event is supported by the switching function (as indicated by the capability exchange services) then the Out Of Service event does not imply that the capabilities of the out of service device have changed - only that the device is out of service.
- 590 -
23.1.4
Partially In Service The Partially In Service event indicates that a device is “partially in service”. This means that part of the device can no longer be able to accept calls and some categories of CSTA service requests.
This might occur, for example, for a CSTA group device when one or more members of a group device are in In Service while one or more members of a group device are Out of Service. 23.1.4.1 Event Parameters Table 23-8 Partially In Service - Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
device
SubjectDeviceID
M
Indicates the device that gone partially in service.
cause
EventCause
O
Specifies the reason for the event.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
23.1.4.2 Event Causes Table 23-9 Partially In Service - Event Causes Event Cause
Description
Associated Feature
Forced Transition
Another resource has caused this device to go partially in service.
Maintenance.
Maintenance
Part of the device has been taken out of service for maintenance.
Maintenance.
Normal
The device is partially in service (a specific cause is not available).
Maintenance.
23.1.4.3 Functional Requirements 1. When a device becomes partially in service, existing monitors are not removed (e.g., existing MonitorCrossRefIDs remain valid). However: •
Event flows over an existing monitor may be reduced (or even completely stopped except for the Back In Service event).
•
Some CSTA services may not be allowed for a partially in service device.
2. When a partially in service device becomes in service, a Back In Service event is generated. 3. When a partially in service device becomes out of service, an Out of Service event is generated.
- 591 -
- 592 -
24
I/O Services This section includes:
24.1
•
I/O Registration services
•
I/O services
Registration Services Table 24-1 I/O Registration Services Summary I/O Registration Service
Description
Pg.
24.1.1 I/O Register
Registers the computing function as an I/O server for a specified device or for the entire switching function.
594
24.1.2 I/O Register Abort
Specifies that the switching function has terminated an I/O server registration.
596
24.1.3 I/O Register Cancel
Unregisters the computing function as an I/O server.
597
- 593 -
24.1.1
I/O Register
C
S
The I/O Register service is used to register the computing function as an I/O server for a specific device or as an I/O server for all devices within the switching sub-domain. The computing function may be required to register for I/O services before it can receive I/O service requests for a device from the switching function. A computing function may register to be the I/O server for more than one I/O device. Note that an I/O registration is not applicable when a data path is initiated by the computing function (i.e., a computing function can initiate a I/O data path after an I/O registration but the ioRegisterReqID parameter is not provided in the I/O services related to a data path that has been initiated by the computing function). 24.1.1.1 Service Request Table 24-2 I/O Register—Service Request Parameter Name
Type
M/ O/C
Description
ioDevice
DeviceID
C
Specifies the device for which the computing function requests to be the I/O server. This parameter is mandatory if the switching function does not support the option of registering for all devices in the switching subdomain. Otherwise, the parameter is optional and if not present, indicates the registration is to be for all devices in the switching sub-domain.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.1.1.2 Service Response This service follows the atomic acknowledgement model for this service request. 24.1.1.2.1 Positive Acknowledgement Table 24-3 I/O Register—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
ioRegisterReqID
IORegisterReqID
M
Specifies the I/O registration request identifier for this registration.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 24.1.1.3 Operational Model 24.1.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 24.1.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.1.1.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.1.1.3.4 Functional Requirements
1. The ioRegisterReqID parameter returned in the positive acknowledgement is used to identify the registration over which I/O service requests will be sent. The subsequent I/O services that are related to this request contain this parameter. The ioRegisterReqID is also used when cancelling the I/O registration. - 594 -
2. If the ioDevice parameter on the service request is not provided and this option is supported, then the registration request is for all devices within the switching sub-domain. Some switching function implementations may not support the capability to register for all devices with a single I/O Register request (i.e., with the ioDevice parameter not provided), in which case the switching function will send a negative acknowledgement to the I/O Register request. The capabilities exchange services can be used by the computing function to determine if registering for all devices within the switching sub-domain is supported. 3. The number of simultaneous registrations allowed for the same device is switching function dependent. When the limit is reached, I/O register requests for the same device will result in negative acknowledgements from the switching function.
- 595 -
24.1.2
I/O Register Abort
S
C
This service is used by the switching function to asynchronously cancel an active I/O registration. This service invalidates a current I/O registration. 24.1.2.1 Service Request Table 24-4 I/O Register Abort—Service Request Parameter Name
Type
M/ O/C
Description
ioRegisterReqID
IORegisterReqID
M
Specifies the I/O registration request identifier for the I/O registration that was aborted.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.1.2.2 Service Response There are no service completion conditions for this service. 24.1.2.2.1 Positive Acknowledgement
There is no positive acknowledgement associated with this service. 24.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 24.1.2.3 Operational Model 24.1.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 24.1.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.1.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.1.2.3.4 Functional Requirements
1. The switching function may issue this service at any time when it can no longer maintain the I/O registration (e.g. when the associated device goes out of service).
- 596 -
24.1.3
I/O Register Cancel
C
S
The I/O Register Cancel service is used to cancel a previous I/O registration. This request terminates the I/O registration and the computing function receives no further I/O services requests for that I/O registration once it receives the positive acknowledgement to the I/O Register Cancel request. 24.1.3.1 Service Request Table 24-5 I/O Register Cancel—Service Request Parameter Name
Type
M/ O/C
Description
ioRegisterReqID
IORegisterReqID
M
Specifies the I/O registration to be cancelled.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.1.3.2 Service Response This service follows the atomic acknowledgement model for this service request. 24.1.3.2.1 Positive Acknowledgement Table 24-6 I/O Register Cancel—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 24.1.3.3 Operational Model 24.1.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 24.1.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.1.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.1.3.3.4 Functional Requirements
1. The computing function shall continue to process I/O requests from the device until it receives a positive acknowledgement for the I/O Register Cancel service request. The switching function shall not send any further I/O service requests for a registration once it has sent the positive acknowledgement.
- 597 -
24.2
I/O Services Table 24-7 I/O Services Summary Description
Pg.
24.2.1 Data Path Resumed
I/O Service
The Data Path Resumed service provides information that a previously suspended data path has been resumed.
599
24.2.2 Data Path Suspended
The Data Path Suspended service provides information that a data path has been suspended.
600
24.2.3 Fast Data
The Fast Data service starts a data path for only the duration of sending one data message.
601
24.2.4 Resume Data Path
The Resume Data Path requests the switching function to resume a currently suspended data path.
604
24.2.5 Send Broadcast Data
The Send Broadcast Data service writes to all open data paths for a given application association and data path type.
605
24.2.6 Send Data
The Send Data service writes data to a specified data path.
607
24.2.7 Send Multicast Data
The Send Multicast Data service writes to multiple data paths.
609
24.2.8 Start Data Path
The Start Data Path service starts a data path on the specified object.
611
24.2.9 Stop Data Path
The Stop Data Path service terminates an existing data path.
613
24.2.10 Suspend Data Path
The Suspend Data Path suspends a specified data path but does not destroy the data path.
614
- 598 -
24.2.1
Data Path Resumed
S
C
The Data Path Resumed service provides information that a previously suspended data path has been resumed. 24.2.1.1 Service Request Table 24-8 Data Path Resumed—Service Request Parameter Name
Type
M/ O/C
Description
ioCrossRefID
IOCrossRefID
M
Specifies the cross reference identifier associated with the data path and whether the computing function or switching function started the data path.
ioRegisterReqID
IORegisterReqID
C
Specifies the I/O register request identifier associated with the registration for I/O services. This parameter is mandatory if the switching function supports I/O registration and the I/O Data Path was requested from the switching function, and shall not be provided otherwise.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.1.2 Service Response This service follows the atomic acknowledgement model for this service request. 24.2.1.2.1 Positive Acknowledgement Table 24-9 Data Path Resumed—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 24.2.1.3 Operational Model 24.2.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 24.2.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.1.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.1.3.4 Functional Requirements
1. This service allows the switching function to inform the computing function that the switching function has resumed a previously suspended data path.
- 599 -
24.2.2
Data Path Suspended
S
C
The Data Path Suspended service provides information that a data path has been suspended. 24.2.2.1 Service Request Table 24-10 Data Path Suspended—Service Request Parameter Name
Type
M/ O/C
Description
ioCrossRefID
IOCrossRefID
M
Specifies the cross reference identifier associated with the data path and whether the computing function or switching function started the data path.
ioRegisterReqID
IORegisterReqID
C
Specifies the I/O register request identifier associated with the registration for I/O services. This parameter is mandatory if the switching function supports I/O registration and the I/O Data Path was requested from the switching function, and shall not be provided otherwise.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.2.2 Service Response This service follows the atomic acknowledgement model for this service request. 24.2.2.2.1 Positive Acknowledgement Table 24-11 Data Path Suspended—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 24.2.2.3 Operational Model 24.2.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 24.2.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.2.3.4 Functional Requirements
1. This service allows the switching function to inform the computing function that the switching function has suspended a data path. The Resume Data Path service may then be used to resume the flow of data on the data path.
- 600 -
24.2.3
Fast Data
C
S
The Fast Data service transfers data to/from a specified CSTA object. The services results in a data path to be created for only the duration of sending information contained in the Fast Data service request. 24.2.3.1 Service Request Table 24-12 Fast Data—Service Request Parameter Name ioRegisterReqID
Type IORegisterReqID
M/ O/C C
Description Specifies the I/O register request identifier associated with the registration for I/O services. This parameter is mandatory if the switching function supports I/O registration and the I/O Data Path was requested from the switching function, and shall not be provided otherwise.
object
Choice Structure
M
Specifies the object with which a data path should be initiated. This shall be one of the following choices: • Device (DeviceID) - specifies the device upon which the data path is to be started. • Call (ConnectionID) - specifies the call (connection) upon which the data path is to be started.
dataPathType
Enumerated
O
Specifies the data-type of the data path. The complete set of possible values is: • text - a digitally encoded text stream • voice - a digitally encoded voice stream.
- 601 -
Table 24-12 Fast Data—Service Request (continued) Parameter Name displayAttributes
Type Structure
M/ O/C
Description
O
Specifies information about the display to be updated. This parameter may only be provided if the ioData is being sent to a display on a device. The list contains the following components: • displayID (C) DisplayID - Specifies which display on the physical device needs to be updated. If the device has only one display this component may be omitted, but it may also be filled in (specifying the one and only displayID). If the device has more than one display and the service will be used to update a display, than this component shall be provided. • physicalBaseRowNumber (O) Value - Specifies the row number of the physical base, i.e. the logical row that appears at the first row of the physical display. This parameter may be omitted or may be present when it needs to be changed. The parameter shall be omitted when it is not relevant because the number of physical rows is equal to the number of logical rows. • physicalBaseColumnNumber (O) Value - Specifies the column number of the physical base, i.e. the logical column that appears at the first column of the physical display. This parameter may be omitted or may be present when it needs to be changed. This parameter shall be omitted when it is not relevant because the number of physical columns is equal to the number of logical columns. • offset (O) Value - This component specifies the offset, in number-of-characters (not bytes in the ioData message string), where text is to start on the display. Allowed values are from zero (default) to (MaxNbrOfLogicalColumns * MaxNbrOfLogicalRows 1). Non-printable characters (e.g. Carriage Return (CR), Line Feed (LF), and Tab) are counted in determining offsets and the message length.
ioData
Characters (240)
M
Specifies the data to be sent.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.3.2 Service Response This service follows the atomic acknowledgement model for this service request. 24.2.3.2.1 Positive Acknowledgement Table 24-13 Fast Data—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 24.2.3.3 Operational Model 24.2.3.3.1 Connection State Transitions
There are no connection state changes due to this service. - 602 -
24.2.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.3.3.4 Functional Requirements
1. This service is functionally similar to the sequence of service requests: “Start Data Path, Send Data, Stop Data Path”. 2. To send object-dependent data (e.g. to present information on a device’s display) via the Fast Data service, CSTA applications should know the characteristics of the target object. 3. When the physicalBaseRowNumber and/or the physicalBaseColumnNumber parameters are provided in the service request with values that are different from the current values, the switching function can either accept the service and modify the relative positions of the logical and physical displays (i.e., scrolling) or it can reject the service if it does not support this capability as indicated by the capability exchange services.
- 603 -
24.2.4
Resume Data Path
C
S
The Resume Data Path requests the switching function to resume a currently suspended data path. 24.2.4.1 Service Request Table 24-14 Resume Data Path—Service Request Parameter Name
Type
M/ O/C
Description
ioCrossRefID
IOCrossRefID
M
Specifies the cross reference identifier associated with the data path and whether the computing function or switching function started the data path.
ioRegisterReqID
IORegisterReqID
C
Specifies the I/O register request identifier associated with the registration for I/O services. This parameter is mandatory if the switching function supports I/O registration and the I/O Data Path was requested from the switching function, and shall not be provided otherwise.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.4.2 Service Response This service follows the atomic acknowledgement model for this service request. 24.2.4.2.1 Positive Acknowledgement Table 24-15 Resume Data Path—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 24.2.4.3 Operational Model 24.2.4.3.1 Connection State Transitions
There are no connection state changes due to this service. 24.2.4.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.4.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.4.3.4 Functional Requirements
1. If the data path is already resumed, this service may or may not be rejected (as indicated by the capability exchange services). 2. Some implementations may send the Data Path Resumed service as the result of this service (as indicated by the capability exchange services).
- 604 -
24.2.5
Send Broadcast Data
C
S
The Send Broadcast Data service writes to all open data paths for a given application association and data path type. 24.2.5.1 Service Request Table 24-16 Send Broadcast data—Service Request Parameter Name
Type
M/ O/C
Description
ioData
Characters (240)
M
Specifies the data to be sent.
dataPathType
Enumerated
O
Specifies the data-type of the data path. The complete set of possible values is: • text - a digitally encoded text stream • voice - a digitally encoded voice stream
displayAttributes
List of Values
O
Specifies information about the display to be updated. This parameter may only be provided if the ioData is being sent to displays on devices. The list contains the following components: • physicalBaseRowNumber (O) Value - Specifies the row number of the physical base, i.e. the logical row that appears at the first row of the physical display. This parameter may be omitted or may be present when it needs to be changed. The parameter shall be omitted when it is not relevant because the number of physical rows is equal to the number of logical rows. • physicalBaseColumnNumber (O) Value - Specifies the column number of the physical base, i.e. the logical column that appears at the first column of the physical display. This parameter may be omitted or may be present when it needs to be changed. This parameter shall be omitted when it is not relevant because the number of physical columns is equal to the number of logical columns. • offset (O) - This component specifies the offset, in number-of-characters (not bytes in the ioData message string), where text is to start on the display. Allowed values are from zero (default) to (MaxNbrOfLogicalColumns * MaxNbrOfLogicalRows 1). Non-printable characters (e.g. Carriage Return (CR), Line Feed (LF), and Tab) are counted in determining offsets and the message length.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.5.2 Service Response This service follows the atomic acknowledgement model for this service request.
- 605 -
24.2.5.2.1 Positive Acknowledgement Table 24-17 Send Broadcast Data—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 24.2.5.3 Operational Model 24.2.5.3.1 Connection State Transitions
There are no connection state changes due to this service. 24.2.5.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.5.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.5.3.4 Functional Requirements
1. This service transfers data from the computing function to all CSTA objects for which an appropriate data path exists. 2. The response to this service request only indicates that the service request was received correctly, that none of the enumerated error conditions has been encountered, and that processing of the data is proceeding on the assumption that the data is otherwise correct. 3. To send object-dependent data (e.g. to present information on a device’s display) via the Send Broadcast Data service, the switching function should know the characteristics of the target object. This service may be used, for example, to send information to all video displays and audio channels. 4. When the physicalBaseRowNumber and/or the physicalBaseColumnNumber parameters are provided in the service request with values that are different from the current values, the switching function can either accept the service and modify the relative positions of the logical and physical displays (i.e., scrolling) or it can reject the service if it does not support this capability as indicated by the capability exchange services.
- 606 -
24.2.6
Send Data
S
The Send Data service sends data to a specified data path. This is a bi-directional service. 24.2.6.1 Service Request Table 24-18 Send Data—Service Request Parameter Name
Type
M/ O/C
Description
ioCrossRefID
IOCrossRefID
M
Specifies the cross reference identifier associated with the data path and whether the computing function or switching function started the data path.
ioRegisterReqID
IORegisterReqID
C
Specifies the I/O register request identifier associated with the registration for I/O services. This parameter is mandatory if the switching function supports I/O registration and the I/O Data Path was requested from the switching function, and shall not be provided otherwise.
displayAttributes
List of Values
O
Specifies information about the display to be updated. This parameter may only be provided if the ioData is being sent to a display on a device. The list contains the following components: • physicalBaseRowNumber (O) Value - Specifies the row number of the physical base, i.e. the logical row that appears at the first row of the physical display. This parameter may be omitted or may be present when it needs to be changed. The parameter shall be omitted when it is not relevant because the number of physical rows is equal to the number of logical rows. • physicalBaseColumnNumber (O) Value - Specifies the column number of the physical base, i.e. the logical column that appears at the first column of the physical display. This parameter may be omitted or may be present when it needs to be changed. This parameter shall be omitted when it is not relevant because the number of physical columns is equal to the number of logical columns. • offset (O) - This parameter specifies the offset, in number-of-characters (not bytes in the ioData message string), where text is to start on the display. Allowed values are from zero (default) to (MaxNbrOfLogicalColumns * MaxNbrOfLogicalRows 1). Non-printable characters (e.g. Carriage Return (CR), Line Feed (LF), and Tab) are counted in determining offsets and the message length.
ioData
Characters (240)
M
Specifies the data to be sent. When writing to a display on a device, this specifies the data to place on the display as a string of characters consisting of the text on each row of the display (including spaces) concatenated together. If a null string is sent, the display will be cleared.
- 607 -
C
Table 24-18 Send Data—Service Request (concluded) Parameter Name ioCause
Type
M/ O/C
EventCause
O
Description Specifies the reason why data is being sent. The complete set of possible values is: • terminationCharacterReceived - the specified termination character was received. • characterCountReached - the specified number of characters was reached. • timeout - a timeout occurred. • switchingFunctionTerminated - the switching function terminated collection before other termination conditions were encountered. Note that even though ioCause parameter is used in a service, the EventCause parameter type is used to represent the reason why the data is being sent.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.6.2 Service Response This service follows the atomic acknowledgement model for this service request. 24.2.6.2.1 Positive Acknowledgement Table 24-19 Send Data—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.6.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 24.2.6.3 Operational Model 24.2.6.3.1 Connection State Transitions
There are no connection state changes due to this service. 24.2.6.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.6.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.6.3.4 Functional Requirements
1. The response to this service request only indicates that the request was received correctly, that none of the enumerated error conditions have been encountered, and that processing of the data is proceeding on the assumption that the data is otherwise correct. 2. To send object-dependent data (e.g. to present information on a device’s display) via the Send Data service, the computing function should know the characteristics of the target object. This service may, for example, be used to send information to a display or an audio channel on a device. 3. When the physicalBaseRowNumber and/or the physicalBaseColumnNumber parameters are provided in the service request with values that are different from the current values, the switching function can either accept the service and modify the relative positions of the logical and physical displays (i.e., scrolling) or it can reject the service if it does not support this capability as indicated by the capability exchange services. - 608 -
24.2.7
Send Multicast Data
C
The Send Multicast Data service writes to multiple data paths specified in the service request. 24.2.7.1 Service Request Table 24-20 Send Multicast Data—Service Request Parameter Name
Type
M/ O/C
Description
ioCrossRefIDList
List of IOCrossRefID
M
Specifies the list of I/O Cross Reference Identifiers that should receive the data.
ioData
Characters (240)
O
Specifies the data to be sent.
displayAttributes
List of Values
O
Specifies information about the display to be updated. This parameter may only be provided if the ioData is being sent displays on devices. The list contains the following components: • physicalBaseRowNumber (O) Value - Specifies the row number of the physical base, i.e. the logical row that appears at the first row of the physical display. This parameter may be omitted or may be present when it needs to be changed. The parameter shall be omitted when it is not relevant because the number of physical rows is equal to the number of logical rows. • physicalBaseColumnNumber (O) Value - Specifies the column number of the physical base, i.e. the logical column that appears at the first column of the physical display. This parameter may be omitted or may be present when it needs to be changed. This parameter shall be omitted when it is not relevant because the number of physical columns is equal to the number of logical columns. • offset (O) - This component specifies the offset, in number-of-characters (not bytes in the ioData message string), where text is to start on the display. Allowed values are from zero (default) to (MaxNbrOfLogicalColumns * MaxNbrOfLogicalRows 1). Non-printable characters (e.g. Carriage Return (CR), Line Feed (LF), and Tab) are counted in determining offsets and the message length.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.7.2 Service Response This service follows the atomic acknowledgement model for this service request. 24.2.7.2.1 Positive Acknowledgement Table 24-21 Send Multicast Data—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.7.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121.
- 609 -
S
24.2.7.3 Operational Model 24.2.7.3.1 Connection State Transitions
There are no connection state changes due to this service. 24.2.7.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.7.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.7.3.4 Functional Requirements
1. This service sends data from the computing function to one or more CSTA objects. 2. The response to this service request only indicates that the request was received correctly, that none of the enumerated error conditions has been encountered, and that processing of the data is proceeding on the assumption that the data is otherwise correct. 3. To send object-dependent data (e.g. to present information on a device’s display) via the Send Multicast Data Service, the computing function should know the characteristics of the target objects. This service may be used, for example, to send information to multiple displays and audio channels. 4. When the physicalBaseRowNumber and/or the physicalBaseColumnNumber parameters are provided in the service request with values that are different from the current values, the switching function can either accept the service and modify the relative positions of the logical and physical displays (i.e., scrolling) or it can reject the service if it does not support this capability as indicated by the capability exchange services.
- 610 -
24.2.8
Start Data Path
C
The Start Data Path service starts a data path on the specified object. This is a bi-directional service. 24.2.8.1 Service Request Table 24-22 Start Data Path—Service Request Parameter Name ioRegisterReqID
Type IORegisterReqID
M/ O/C C
Description Specifies the I/O register request identifier associated with the registration for I/O services. This parameter is mandatory if the switching function supports I/O registration and the I/O Data Path was requested from the switching function, and shall not be provided otherwise.
object
Choice Structure
M
Specifies the object to which a data path should be initiated. The complete set of possible objects is: • Device (DeviceID) - specifies the device upon which the data path is to be started. • Call (ConnectionID) - specifies the call (connection) upon which the data path is to be started.
dataPathDirection
Enumerated
O
Specifies the direction of the data path. The complete set of possible values is: • from the computing function to the identified object • from the identified object to the computing function • bi-directional between the computing function and the identified object.
dataPathType
Enumerated
O
Specifies the data-type of the data path. The complete set of possible values is: • text - a digitally encoded text stream • voice - a digitally encoded voice stream
displayID
DisplayID
C
Specifies which display on the physical device needs to be updated. If the device has only one display this parameter may be omitted, but it may also be filled in (specifying the one and only displayID). If the device has more than one display and the data path will be used to update a display, than this parameter shall be provided.
numberOfCharsToCollect
Value
O
Specifies the number of characters to collect before sending collected characters on the data path.
terminationCharacter
Character(1)
O
Specifies an ASCII (IA5) character that, if received, causes the switching function to send collected characters on the data path.
timeout
Value
O
Specifies a duration in seconds such that characters will be sent on the data path.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.8.2 Service Response This service follows the atomic acknowledgement model for this service request.
- 611 -
S
24.2.8.2.1 Positive Acknowledgement Table 24-23 Start Data Path—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
ioCrossRefID
IOCrossRefID
M
Specifies the cross reference identifier associated with the data path that has been created.
numberOfCharsToCollect
Value
O
Specifies the number of characters to collect before sending collected characters on the data path.
terminationCharacter
Character(1)
O
Specifies an ASCII (IA5) character that, if received, causes the switching function to send collected characters on the data path.
timeout
Value
O
Specifies a duration in seconds such that characters will be sent on the data path.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.8.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 24.2.8.3 Operational Model 24.2.8.3.1 Connection State Transitions
There are no connection state changes due to this service. 24.2.8.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.8.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.8.3.4 Functional Requirements
1. Starting a device’s data path means that the computing function has requested control of the device either on its own initiative or at the request of a device user. When a computing function that has a data path association with a device starts a data path, data may be collected by the switching function prior to informing the computing function of an invocation request. Whether or not this “automatic starting” of a data path occurs is implementation specific. 2. If a termination condition, as specified by the terminationCharacter parameter, is encountered, then data is returned to the requesting client and data collection continues until the termination condition is encountered again or until the data path is explicitly stopped.
- 612 -
24.2.9
Stop Data Path
S
The Stop Data Path service terminates an existing data path. This is a bi-directional service. 24.2.9.1 Service Request Table 24-24 Stop Data Path—Service Request Parameter Name
Type
M/ O/C
Description
ioCrossRefID
IOCrossRefID
M
Specifies the cross reference identifier associated with the data path to be terminated.
ioRegisterReqID
IORegisterReqID
C
Specifies the I/O register request identifier associated with the registration for I/O services. This parameter is mandatory if the switching function supports I/O registration and the I/O Data Path was requested from the switching function, and shall not be provided otherwise.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.9.2 Service Response This service follows the atomic acknowledgement model for this service request. 24.2.9.2.1 Positive Acknowledgement Table 24-25 Stop Data Path—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.9.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 24.2.9.3 Operational Model 24.2.9.3.1 Connection State Transitions
There are no connection state changes due to this service. 24.2.9.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.9.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.9.3.4 Functional Requirements
1. It is not necessary for a suspended data path to be resumed for this service to be carried out.
- 613 -
C
24.2.10 Suspend Data Path The Suspend Data Path suspends a specified data path but does not destroy the data path. This is a bi-directional service. 24.2.10.1 Service Request Table 24-26 Suspend Data Path—Service Request Parameter Name
Type
M/ O/C
Description
ioCrossRefID
IOCrossRefID
M
Specifies the cross reference identifier associated with the data path to be suspended.
ioRegisterReqID
IORegisterReqID
C
Specifies the I/O register request identifier associated with the registration for I/O services. This parameter is mandatory if the switching function supports I/O registration and the I/O Data Path was requested from the switching function, and shall not be provided otherwise.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.10.2 Service Response This service follows the atomic acknowledgement model for this service request. 24.2.10.2.1Positive Acknowledgement Table 24-27 Suspend Data Path—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
24.2.10.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 24.2.10.3 Operational Model 24.2.10.3.1Connection State Transitions
There are no connection state changes due to this service. 24.2.10.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.10.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 24.2.10.3.4Functional Requirements
1. The sender informs its peer that the data path should be suspended, but not destroyed. The Resume Data Path service may then be used to resume the flow of data on the data path. 2. This service allows the consumer of the data path to start and stop the flow of data. It is expected that no flow control of the data that has been suspended will occur. That is, if a data path is suspended the consumer is not provided with the data between the time the data path was suspended and the time it was resumed.
- 614 -
25
Data Collection Services This clause includes the data collection services.
25.1
Services Table 25-1 Data Collection Services Summary Data Collection Service
Description
Pg.
25.1.1 Data Collected
The Data Collected service provides information (e.g., telephony tones, DTMF digits) that was received over a connection as part of the data collection.
616
25.1.2 Data Collection Resumed
The Data Collection Resumed service provides information that a previously suspended data collection has been resumed.
619
25.1.3 Data Collection Suspended
The Data Collection Suspended service provides information that a data collection has been suspended.
620
25.1.4 Resume Data Collection
The Resume Data Collection service requests the switching function to resume a currently suspended data collection.
621
25.1.5 Start Data Collection
The Start Data Collection service starts data collection on a connection.
622
25.1.6 Stop Data Collection
The Stop Data Collection service terminates an existing data collection.
624
25.1.7 Suspend Data Collection
The Suspend Data Collection service suspends a specified data collection but does not destroy the data collection.
625
- 615 -
25.1.1
Data Collected
S
The Data Collected service sends data that was received over a connection to the computing function. 25.1.1.1 Service Request Table 25-2 Data Collected—Service Request Parameter Name
Type
M/ O/C
Description
dcollCrossRefID
DcollCrossRefID
M
Specifies the cross reference identifier associated with the data collection.
digitsData
Structure
C
Specifies the collected DTMF/rotary pulse digit information. This parameter shall be provided if the dcollType specified in the Start Data Collection service is digits, otherwise it shall not be provided. This parameter consists of the following components: • digitsDetected (M) Characters(64) - Specifies the ASCII (IA5) sequence of DTMF/rotary pulse digits detected. • digitsDuration (O) List of Values - Specifies the list of corresponding digit durations. If this component is provided, a digit duration shall be provided for each detected digit. This component may only be provided for DTMF digits. • digitsPauseDuration (O) List of Values - Specifies the list of corresponding pauses between the last digit and this one. If this component is provided, a pause duration shall be provided for each detected digit.
- 616 -
C
Table 25-2 Data Collected—Service Request (continued) Parameter Name telTonesData
Type Structure
M/ O/C
Description
C
Specifies the collected telephony tones information. This parameter shall be provided if the dcollType specified in the Start Data Collection service is telephony tones, otherwise it shall not be provided. This parameter consists of the following component: • toneDetected (M) Enumerated - Specifies the telephony tone detected. The complete set of possible values is: •
beep
•
billing
•
busy
•
carrier
•
confirmation
•
dial
•
faxCNG
•
hold
•
howler
•
intrusion
•
modemCNG
•
park
•
record warning (indicates call may be being recorded)
•
reorder
•
ringback
•
silence
•
SIT VC
•
SIT IC
•
SIT RO
•
SIT NC
•
other
• toneFrequency (O) Value - Specifies the switching function determined frequency, in Hz.,of the detected tone. This component shall not be provided if the toneDetected is anything other than “other”. • toneDuration (O) Value - Specifies the duration, in milliseconds, of the detected tone. This component shall not be provided if the toneDetected is anything other than “other”. • tonePauseDuration (O) Value - Specifies the duration, in milliseconds, of the pause between the last tone and this one. This component shall not be provided if the toneDetected is anything other than “other”. connectionInfo
ConnectionInformation
- 617 -
O
Specifies the connection information associated with the connection. If this parameter is not present, then the connection information is switching function specific.
Table 25-2 Data Collected—Service Request (concluded) Parameter Name dcollCause
Type
M/ O/C
Enumerated
O
Description Specifies the reason why data is being sent. The complete set of possible values is: • flushCharReceived - the specified flush character was received (for digits collection only) • charCountReached - the specified number of characters was reached (for digits collection only) • timeout - a timeout occurred. • sfTerminated - the switching function terminated collection before other termination conditions were encountered.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.1.2 Service Response This service follows the atomic acknowledgement model for this service request. 25.1.1.2.1 Positive Acknowledgement Table 25-3 Data Collected—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 25.1.1.3 Operational Model 25.1.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 25.1.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.1.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.1.3.4 Functional Requirements
None.
- 618 -
25.1.2
Data Collection Resumed
S
C
The Data Collection Resumed service provides information that a previously suspended data collection has been resumed. 25.1.2.1 Service Request Table 25-4 Data Collection Resumed—Service Request Parameter Name
Type
M/ O/C
Description
dcollCrossRefID
DcollCrossRefID
M
Specifies the cross reference identifier associated with the data collection.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.2.2 Service Response This service follows the atomic acknowledgement model for this service request. 25.1.2.2.1 Positive Acknowledgement Table 25-5 Data Collection Resumed—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 25.1.2.3 Operational Model 25.1.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 25.1.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.2.3.4 Functional Requirements
1. This services allows the switching function to inform the computing function that the switching function has resumed a previously suspended data collection.
- 619 -
25.1.3
Data Collection Suspended
S
C
The Data Collection Suspended service provides information that a data collection has been suspended. 25.1.3.1 Service Request Table 25-6 Data Collection Suspended—Service Request Parameter Name
Type
M/ O/C
Description
dcollCrossRefID
DcollCrossRefID
M
Specifies the cross reference identifier associated with the data collection.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.3.2 Service Response This service follows the atomic acknowledgement model for this service request. 25.1.3.2.1 Positive Acknowledgement Table 25-7 Data Collection Suspended—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 25.1.3.3 Operational Model 25.1.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 25.1.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.3.3.4 Functional Requirements
1. This services allows the switching function to inform the computing function that the switching function has suspended a data collection. The Resume Data Collection service may then be used to resume the flow of data on the data collection.
- 620 -
25.1.4
Resume Data Collection
C
S
The Resume Data Collection requests the switching function to resume a currently suspended data collection. 25.1.4.1 Service Request Table 25-8 Resume Data Collection —Service Request Parameter Name
Type
M/ O/C
Description
dcollCrossRefID
DcollCrossRefID
M
Specifies the cross reference identifier associated with the data collection.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.4.2 Service Response This service follows the atomic acknowledgement model for this service request. 25.1.4.2.1 Positive Acknowledgement Table 25-9 Resume Data Collection —Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 25.1.4.3 Operational Model 25.1.4.3.1 Connection State Transitions
There are no connection state changes due to this service. 25.1.4.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.4.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.4.3.4 Functional Requirements
1. This service resumes a suspended data collection. If the data collection is not suspended, this service shall be rejected.
- 621 -
25.1.5
Start Data Collection
C
S
The Start Data Collection service is used to collect information such as DTMF/rotary pulse digits and telephony tones from a connection at a specified device. Data Collection may be started on either an existing connection or on the first connection that appears at a device after the service request has been acknowledged. Data Collection continues until the Stop Data Collection service is used to terminate the collection or until the connection over which data is being collected is cleared. This connection is either an existing connection or the first connection that appears at a device after the service request has been acknowledged. The service request specifies criteria that specify when the collection of DTMF/rotary pulse digits is reported via the Data Collected service. 25.1.5.1 Service Request Table 25-10 Start Data Collection —Service Request Parameter Name object
Type
M/ O/C
Description
Choice Structure
M
Specifies the object to which a data collection should be initiated. This shall be one of the following choices: • device (DeviceID) - specifies the device upon which the data collection is to be started. Data collection occurs on the next connection at this device and is stopped when this connection is cleared. If there are one or more calls at this device and this choice is selected, then this service request shall be rejected. • call (ConnectionID) - specifies a specific call (connection) upon which the data collection is to be started.
dataCollType
Enumerated
O
Specifies the data-type of the data collection. The complete set of possible values is: • digits - DTMF/rotary pulse digits • telephonyTones - telephony tones.
digitsReportingCriteria
Structure
O
Specifies the criteria associated with the reporting of the DTMF/rotary pulse digits This value may be provided only when the dataCollType value is Digits. This parameter consists of the following components: • numChars (C) Value - specifies the number of characters to collect before sending the Data Collected service with the collected digit characters. • flushChar (C) Character(1) - specifies an ASCII (IA5) character that, if detected, causes any previously unreported digit characters (including this character) to be sent in the Data Collected service. • timeout (C) Value - specifies a duration, in milliseconds, when any previously unreported digit characters are sent in the Data Collected service. If this parameter is provided, at least one component must be provided.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.5.2 Service Response This service follows the atomic acknowledgement model for this service request. - 622 -
25.1.5.2.1 Positive Acknowledgement Table 25-11 Start Data Collection —Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
dcollCrossRefID
DcollCrossRefID
M
Specifies the cross reference identifier associated with the data collection that has been created.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 25.1.5.3 Operational Model 25.1.5.3.1 Connection State Transitions
There are no connection state changes due to this service. 25.1.5.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.5.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.5.3.4 Functional Requirements
1. The Start Data Collection service collects information (e.g., DTMF digits, telephony tones) that is received over a connection at a device (i.e. information that has been sent over a connection from another device in the call). 2. The Data Collected service is used to report the collected information. When DTMF/rotary pulse digits are being collected, it is sent when one of the reporting criteria, as specified in the digitsReportingCriteria parameter, is satisfied. When telephony tones are being collected, the Data Collected service is sent after a single telephony tone is collected. 3. The purpose of the Start Data Collection service is to detect digits and tones sent to the specified device. However, it cannot be presumed that the source of the digits and tones can be determined by the collection device in every situation (e.g., analog lines). 4. If the digitsReportingCriteria is not provided, the number of digits (for digits collection) that need to be detected before the Data Collected service is generated is switching function specific. 5. For telephonyTones collection, the detected tone is reported via the Data Collected service as soon as the switching function has recognized the tone. 6. If the switching function receives a subsequent request for this service with the object parameter specified as call (connection), and data collection has already started due to a previous Start Data Collection service, the switching function shall respond with a negative acknowledgement specifying an error code of “Feature Already Set”.
- 623 -
25.1.6
Stop Data Collection
S
C
The Stop Data Collection service terminates an existing data collection. 25.1.6.1 Service Request Table 25-12 Stop Data Collection —Service Request Parameter Name
Type
M/ O/C
Description
dcollCrossRefID
DcollCrossRefID
M
Specifies the cross reference identifier associated with the data collection to be terminated.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.6.2 Service Response This service follows the atomic acknowledgement model for this service request. 25.1.6.2.1 Positive Acknowledgement Table 25-13 Stop Data Collection —Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.6.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 25.1.6.3 Operational Model 25.1.6.3.1 Connection State Transitions
There are no connection state changes due to this service. 25.1.6.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.6.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.6.3.4 Functional Requirements
1. It is not necessary for a suspended data collection to be resumed for the data collection to be stopped.
- 624 -
25.1.7
Suspend Data Collection
S
C
The Suspend Data Collection suspends a specified data collection but does not destroy the data collection. 25.1.7.1 Service Request Table 25-14 Suspend Data Collection —Service Request Parameter Name
Type
M/ O/C
Description
dcollCrossRefID
DcollCrossRefID
M
Specifies the cross reference identifier associated with the data collection to be suspended.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.7.2 Service Response This service follows the atomic acknowledgement model for this service request. 25.1.7.2.1 Positive Acknowledgement Table 25-15 Suspend Data Collection —Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
25.1.7.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 25.1.7.3 Operational Model 25.1.7.3.1 Connection State Transitions
There are no connection state changes due to this service. 25.1.7.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.7.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 25.1.7.3.4 Functional Requirements
1. The sender informs its peer that the data collection should be suspended, but not destroyed. The Resume Data Collection service may then be used to resume the flow of data on the data collection. 2. This service allows the consumer of the data collection to start and stop the flow of data. It is expected that no flow control of the data that has been suspended will occur. That is, if a data collection is suspended the consumer is not provided with the data between the time the data collection was suspended and the time it was resumed.
- 625 -
26
Voice Services & Events This clause specifies Voice services and events1.
26.1
Services Table 26-1 Voice Services Summary Voice Service
Description
Pg.
26.1.1 Activate
The Activate service enables a grammar rule to be considered in matching the speech of the call.
627
26.1.2 Clear
The Clear service halts operations and releases any data held by a Listener, DTMF, or Prompt Queue.
628
26.1.3 Concatenate Message
The Concatenate Message service combines multiple messages, in the sequence provided, into a single resulting message.
630
26.1.4 Deactivate
The Deactivate service excludes a grammar rule from being considered in matching the speech of a call.
631
26.1.5 Delete Message
The Delete Message service deletes a specified voice message.
632
26.1.6 Play Message
The Play Message service plays a voice message on a particular Connection.
633
26.1.7 Query Voice Attribute
The Query Voice Attribute obtains the current value of a specified voice attribute for a specified message.
635
26.1.8 Queue
The Queue service stores a copy of a Prompt to the Prompt Queue.
641
26.1.9 Record Message
The Record Message service starts recording a voice message from a specified connection.
643
26.1.10 Reposition
The Reposition service moves the current position pointer forward or backward a specified number of milliseconds in a message.
645
26.1.11 Resume
The Resume service restarts the playing or recording of a previously suspended message at its current position.
647
26.1.12 Review
The Review service plays a portion of a voice message during a recording session.
649
26.1.13 Set Voice Attribute
The Set Voice Attribute service sets a voice attribute for a specified connection and message.
651
26.1.14 Start
The Start service starts the interaction between a call and an interactive voice resource.
651
26.1.15 Stop
The Stop service halts the operation of a voice resource.
657
26.1.16 Suspend
The Suspend service temporarily stops the playing or recording of the current message and leaves the position pointer at its current location.
660
26.1.17 Synthesize Message
The Synthesize Message service constructs a voice message from a text message.
662
1. Voice services and events defined in this clause may alternatively be provided using media services and events as described in Clause 6.7.7, “Media Stream Access”, on page 75.
- 626 -
26.1.1
Activate
The Activate service enables a grammar rule to be considered in matching the speech of a call. 26.1.1.1 Service Request Table 26-2 Activate —Service Request Parameter Name
Type
M/ O/C
Description
overConnection
ConnectionID
M
Specifies the connection for which grammar of the Listener is to be played.
resource
ResourceID
C
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
ruleName
Characters
M
Specifies the rule name of the grammar to be activated.
grammarName
Characters
O
Specifies the name of the grammar to be activated. If not specified, all of the grammars will be activated.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.1.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.1.2.1 Positive Acknowledgement Table 26-3 Activate—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.1.3 Operational Model Refer to Clause 6.1.1.4.8, “Generic Interactive Voice Device Category”, beginning on page 30 for the operational model. 26.1.1.3.1 Connection State Transitions
There are no connection state changes due to this service. For Interactive Voice Devices refer to for normative resource state transitions specified in Figure 6-17, Figure 6-18, and Figure 6-19 in Clause 6.1.1.4.8, “Generic Interactive Voice Device Category”, beginning on page 30. 26.1.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 26.1.1.3.3 Call-Type Monitoring Event Sequence
There are no events generated as a result of this service. 26.1.1.3.4 Functional Requirements
None.
- 627 -
26.1.2
Clear
The Clear service halts operations and releases any data held by a Listener, DTMF or Prompt Queue. 26.1.2.1 Service Request Table 26-4 Clear —Service Request Parameter Name
Type
M/ O/C
Description
overConnection
ConnectionID
M
Specifies the connection for which the operations and data held by a Listener, DTMF, or a Prompt Queue is to be cleared.
resource
ResourceID
C
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.2.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.2.2.1 Positive Acknowledgement Table 26-5 Clear —Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.2.3 Operational Model Refer to Clause 6.1.1.4.8, “Generic Interactive Voice Device Category”, beginning on page 30 for the operational model. 26.1.2.3.1 Connection State Transitions
There are no connection state changes due to this service. For Interactive Voice Devices refer to for normative resource state transitions specified in Figure 6-17, Figure 6-18, and Figure 6-19 in Clause 6.1.1.4.8, “Generic Interactive Voice Device Category”, beginning on page 30. 26.1.2.3.2 Device-Type Monitoring Event Sequences Table 26-6 Clear—Device-Type Monitoring Event Sequences Monitored Device D1
Connection D1C1 (overConnection)
Event Emptied
Event Cause Normal
26.1.2.3.3 Call-Type Monitoring Event Sequences Table 26-7 Clear—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1 (overConnection)
- 628 -
Event Emptied
Event Cause Normal
26.1.2.3.4 Functional Requirements
None.
- 629 -
26.1.3
C
Concatenate Message
S
The Concatenate Message service combines multiple messages (original messages), in the sequence provided, into a single resulting message. The concatenated message consists of copies of the original messages. The concatenated message has a single set of attributes (e.g., coder, message ID). The original messages are neither deleted nor otherwise changed. This Service provides a unique Message Identifier for the resulting (concatenated) message that shall remain valid until the resulting message is deleted. 26.1.3.1 Service Request Table 26-8 Concatenate Message—Service Request Parameter Name
Type
M/ O/C
Description
messagesToConcatenate
List of MessageID
M
Specifies the list of MessageIDs of the messages to be concatenated. The list shall contain at least two MessageIDs.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.3.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.3.2.1 Positive Acknowledgement Table 26-9 Concatenate Message—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
concatenatedMessage
MessageID
M
Specifies the resulting Message Identifier.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.3.3 Operational Model Refer to Figure 6-16, “Voice Unit Operational Model,” on page 29 for the operational model. 26.1.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 26.1.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 26.1.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 26.1.3.3.4 Functional Requirements
1. The original messages are preserved by this function. 2. The Message Identifier of the resulting message returned by this service is valid until the resulting message is deleted. 3. If the Voice Unit is unable to concatenate the messages (e.g., because it is not possible to convert all of the original messages to a common encoding), the request shall be rejected. 4. The order of the original messages is preserved in the resulting concatenated message. - 630 -
26.1.4
Deactivate
The Deactivate service excludes a grammar rule to be considered in matching the speech of a call. 26.1.4.1 Service Request Table 26-10 Deactivate —Service Request Parameter Name
Type
M/ O/C
Description
overConnection
ConnectionID
M
Specifies the connection for which grammar of the Listener is to be deactivated.
resource
ResourceID
C
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
ruleName
Characters
M
Specifies the rule name of the grammar to be deactivated.
grammarName
Characters
O
Specifies the name of the grammar to be deactivated. If not specified, all of the grammars will be affected.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.4.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.4.2.1 Positive Acknowledgement Table 26-11 Deactivate—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.4.3 Operational Model Refer to Clause 6.1.1.4.8, “Generic Interactive Voice Device Category”, beginning on page 30 for the operational model. 26.1.4.3.1 Connection State Transitions
There are no connection state changes due to this service. 26.1.4.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 26.1.4.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 26.1.4.3.4 Functional Requirements
None.
- 631 -
26.1.5
C
Delete Message
The Delete Message service deletes a specified message. 26.1.5.1 Service Request Table 26-12 Delete Message—Service Request Parameter Name
Type
M/ O/C
Description
messageToBeDeleted
MessageID
M
Specifies the message to be deleted.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.5.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.5.2.1 Positive Acknowledgement Table 26-13 Delete Message—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.5.3 Operational Model 26.1.5.3.1 Connection State Transitions
There are no connection state changes due to this service. 26.1.5.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 26.1.5.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 26.1.5.3.4 Functional Requirements
None.
- 632 -
S
26.1.6
C
Play Message
S
The Play Message service plays a voice message on a particular connection. The service may also specify termination conditions, which if encountered, causes message playback to stop. 26.1.6.1 Service Request Table 26-14 Play Message—Service Request Parameter Name
Type
M/ O/C
Description
messageToBePlayed
MessageID
M
Specifies the message to be played.
overConnection
ConnectionID
M
Specifies the connection on which the message is to be played.
duration
Value
O
Specifies the length of time to play the message (in milliseconds).
termination
Bitmap
O
Specifies the list of conditions that cause the playback to terminate. This may include one or more of the following actions: • duration exceeded (this value can only be provided if the duration parameter is provided) • DTMF digit (external to the message being played) detected • end of message detected • speech (external to the message being played) detected
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.6.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.6.2.1 Positive Acknowledgement Table 26-15 Play Message—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.6.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.6.3 Operational Model Refer to Clause 6.1.1.4.8, “Generic Interactive Voice Device Category”, beginning on page 30 for the operational model. 26.1.6.3.1 Connection State Transitions
There are no connection state changes due to this service. 26.1.6.3.2 Device-Type Monitoring Event Sequences Table 26-16 Play Message—Device-Type Monitoring Event Sequences Monitored Device D1
Connection D1C1 (overConnection)
- 633 -
Event Play
Event Cause Normal
26.1.6.3.3 Call-Type Monitoring Event Sequences Table 26-17 Play Message—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1 (overConnection)
Event Play
Event Cause Normal
26.1.6.3.4 Functional Requirements
1. The Play Message service plays a designated message until the reception of a valid Stop service request or a Suspend service request or until the end of the message or other specified termination condition is detected. 2. If the duration parameter is set to zero, then the message will go immediately to the Suspend Play State. 3. This service may provide media conversion (as indicated be the capability exchange services). 4. It is implementation dependent if only one message can be played on a connection at one time. When multiple messages are played at one time, the audio shall be mixed. 5. If a message on a given connection is suspended, the Play service (for the same message) shall be rejected.
- 634 -
26.1.7
C
Query Voice Attribute
S
The Query Voice Attribute service obtains the attribute for a specified connection and message in the Voice Unit, or the operating parameters for a specified connection or Interactive Voice device. To query the global voice attributes for an Interactive Voice Device, the callID portion of the connectionID can be omitted. The attributes that can be queried depend on the device type as defined below. 26.1.7.1 Service Request Table 26-18 Query Voice Attribute—Service Request Parameter Name
Type
M/ O/C
Description
messageToQuery
MessageID
C
Specifies the message whose attribute is to be queried. This parameter is required if the voice attribute pertains to a message.
resource
ResourceID
C
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
- 635 -
Table 26-18 Query Voice Attribute—Service Request (continued) Parameter Name attributeToQuery
Type Enumerated
M/ O/C
Description
M
Specifies the attribute to be queried. The complete set of possible values is: • encoding algorithm - requests the encoding algorithm used for the specified message (for Voice Unit) • sampling rate - requests the sampling rate used for the specified message (for Voice Unit) • duration - requests the duration (in milliseconds) of the specified message (for Voice Unit) • file name - requests the (implementation-specific) name of the specified message (for Voice Unit) • current position* - requests the value of the position pointer (in milliseconds after the beginning of the message) (for Voice Unit) • current speed* - requests the current playing speed of the specified message (for Voice Unit, Prompt Queue) • current volume* - requests the current playing volume of the specified message (for Voice Unit, Prompt Queue) • current level* - requests the current recording level of the specified message (for Voice Unit) • current state* - requests the current state of the specified message. (for Voice Unit) • grammars - requests a list of grammars currently used to process speech or DTMF inputs (for Listener, DTMF) • language - requests the languages(s) the Listener is capable of processing, or the language the Prompt is currently using (for Listener, Prompt) • mode - requests the operation mode (6.1.1.4.8) (for Listener) • retain audio - requests the boolean flag indicating whether the audio is being recorded (for Listener) • silence timeout - requests the timeout value in milliseconds that will causes Silence Timeout expiration (for Listener, DTMF) • max timeout - requests the value in milliseconds that will cause Max Timeout expiration (for Voice Unit, Listener, Prompt, DTMF, Prompt Queue) • babble timeout - requests the value in milliseconds that will cause Babble Timeout expiration (for Listener) • end silence - requests the period in milliseconds for which the Listener will observe as an end of utterance marker or for which the DTMF will observe as end of input marker (for Listener, DTMF) • rejection threshold - requests the value below which the Listener will raise the outcome under the Not Recognized as opposed to the Recognized Event.(for Listener)
- 636 -
Table 26-18 Query Voice Attribute—Service Request (concluded) Parameter Name
Type
M/ O/C
attribute to query (continued)
Description • auto interruptible - requests the boolean flag indicating whether the prompt will be automatically stopped by the activity of a Listener or a DTMF resource (for Prompt) • inner XML - requests the Speech Synthesis Markup Language document the Prompt is rendering (for Prompt) • inter-digit timeout - requests the timeout value in milliseconds that will cause inter-digit timeout expiration (for DTMF) • preflush - request the boolean flag indicating whether DTMF will always clear up its buffer before interaction starts (for DTMF)
connection
ConnectionID
C
Specifies the connection of the message/resource whose attribute is being queried. This parameter is required if the voice attribute pertains to an Interactive Voice Device.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.7.2 Service Response This service follows the atomic acknowledgement model for this service request.
- 637 -
26.1.7.2.1 Positive Acknowledgement Table 26-19 Query Voice Attribute—Positive Acknowledgement Parameter Name attribute
Type
M/ O/C
Description
Choice Structure
M
Specifies the value of the specified attribute. May be one of the following (choice depends upon the attribute specified in the service request): • encodingAlgorithm (Enumerated) - encoding algorithm used for the specified message (for Voice Unit). The complete set of possible values is: •
ADPCM6K
•
ADPCM8K
•
muLawPCM6k
•
aLawPCM6K
• samplingRate (Value) used for the specified message (for Voice Unit) • duration (Value) in milliseconds of the specified message (for Voice Unit) • filename (Characters) implementation specific name of the specified message (for Voice Unit) • currentPosition (Value) in the message (milliseconds from the beginning of the message) (for Voice Unit) • currentSpeed (Value) of the message (represents the percentage of normal speed, with 100% being normal speed and the slowest reportable speed being 1%) (for Voice Unit, Prompt Queue) (for Voice Unit) • currentVolAbs (Value 0..100) - absolute play volume of the message (100 indicating maximum volume and 0 indicating silence) (for Voice Unit, Prompt Queue) • currentGain (Value 0..100) gain at which the message was recorded (100 indicating maximum level and 0 indicating minimum level) (for Voice Unit) • current state (Enumerated) - a voice resource state. The complete set of possible states (see 6.1.1.4.7 through 6.1.1.4.13 for a description of the states) is:
- 638 -
•
formed
•
dtmf detected
•
null
•
play
•
playing
•
ready
•
record
•
review
•
speech detected
•
started
•
stop
•
suspend play
•
suspend record
Table 26-19 Query Voice Attribute—Positive Acknowledgement (concluded) Parameter Name
Type
M/ O/C
Description
(attribute continued)
• grammars (Characters) - a list of grammars in URI currently used to process speech or DTMF inputs (for Listener, DTMF, Prompt Queue) • language (Characters) - the languages(s) in XML:LANG format the Listener is capable of processing, or the language the Prompt is currently using (for Listener, Prompt) • mode (Enumerated) - the operation mode (for Listener). The complete set of possible values is: •
automatic
•
single
•
multiple
• retain audio (Boolean) - boolean flag indicating whether the audio is being recorded (for Listener) • silence timeout (Value) - the timeout value in milliseconds that will cause Silence Timeout expiration (for Listener, DTMF) • max timeout (Value) - the value in milliseconds that will cause Max Timeout expiration (for Voice Unit, Listener, Prompt, DTMF, Prompt Queue) • babble timeout: (Value) - the value in milliseconds that will cause Babble Timeout expiration (for Listener) • end silence (Value) - the period in milliseconds for which the Listener will observe as an end of utterance marker or for which the DTMF will observe as end of input marker (for Listener, DTMF) • rejection threshold (Value) - the value below which the Listener will raise the outcome under the Not Recognized as opposed to the Recognized Event (for Listener) • auto interruptible (Boolean)- the boolean flag indicating whether the prompt will be automatically stopped by the activity of a Listener or a DTMF resource (for Prompt) • inner XML (Characters) - the Speech Synthesis Markup Language document the Prompt is rendering (for Prompt) • inter-digit timeout (Value) - timeout value in milliseconds that will cause inter-digit timeout expiration (for DTMF) • preflush (Boolean) - the boolean flag indicating whether DTMF will always clear up its buffer before interaction starts security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.7.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.7.3 Operational Model 26.1.7.3.1 Connection State Transitions
There are no connection state changes due to this service. 26.1.7.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. - 639 -
26.1.7.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service.
- 640 -
26.1.8
Queue
The Queue service generates the voice of a prompt and stores the copy to the Prompt Queue. 26.1.8.1 Service Request Table 26-20 Queue —Service Request Parameter Name
Type
M/ O/C
Description
overConnection
ConnectionID
M
Specifies the connection for which the voice of the Prompt is to be generated.
message
MessageID
C
Specifies the message to be queued to the Prompt Queue. This parameter is required if the voice attribute pertains to a message.
resource
ResourceID
C
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
text
Characters
O
Specifies the text to be synthesized and stored on the Prompt Queue.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.8.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.8.2.1 Positive Acknowledgement Table 26-21 Queue—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.8.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.8.3 Operational Model Refer to Clause 6.1.1.4.8, “Generic Interactive Voice Device Category”, beginning on page 30 for the operational model. 26.1.8.3.1 Connection State Transitions
There are no connection state changes due to this service. For Interactive Voice Devices refer to for normative resource state transitions specified in Figure 6-17, Figure 6-18, and Figure 6-19 in Clause 6.1.1.4.8, “Generic Interactive Voice Device Category”, beginning on page 30. 26.1.8.3.2 Device-Type Monitoring Event Sequences Table 26-22 Queue —Device-Type Monitoring Event Sequences Monitored Device D1
Connection D1C1 (overConnection)
*Note that only one event will be generated. - 641 -
Event
Event Cause
Started*
Normal
Voice Error Occurred*
BadVoice, BadURI
26.1.8.3.3 Call-Type Monitoring Event Sequences Table 26-23 Queue Message—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1 (overConnection)
*Note that only one event will be generated. 26.1.8.3.4 Functional Requirements
None.
- 642 -
Event
Event Cause
Started*
Normal
Voice Error Occurred*
BadVoice, BadURI
26.1.9
C
Record Message The Record Message service starts recording a new message from a specified connection.
This service provides a message identifier for the resulting message. 26.1.9.1 Service Request
Table 26-24 Record Message—Service Request Parameter Name
Type
M/ O/C
Description
callToBeRecorded
ConnectionID
M
Specifies the connection from which the message is to recorded.
resource
ResourceID
C
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
samplingRate
Value
O
Specifies the sampling rate to be used for recording.
encodingAlgorithm
Enumerated
O
Specifies the encoding algorithm to be used for recording. The complete set of possible values is: • ADPCM6K • ADPCM8K • muLawPCM6k • aLawPCM6K
maxDuration
Value
O
Specifies the maximum message time to record (in milliseconds).
termination
Bitmap
O
Specifies the list of actions that causes the recording to terminate. This may include one or more of the following actions: • duration exceeded • DTMF digit detected • end of data detected • speech detected
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.9.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.9.2.1 Positive Acknowledgement Table 26-25 Record Message—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
resultingMessage
MessageID
M
Specifies the resulting Message Identifier.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.9.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.9.3 Operational Model Refer to Figure 6-16, “Voice Unit Operational Model,” on page 29 for the operational model. - 643 -
S
26.1.9.3.1 Connection State Transitions
There are no connection state changes due to this service. 26.1.9.3.2 Device-Type Monitoring Event Sequences Table 26-26 Record Message—Device-Type Monitoring Event Sequences Monitored Device D1
Connection D1C1 (callToBeRecorded)
Event Record
Event Cause Normal
26.1.9.3.3 Call-Type Monitoring Event Sequences Table 26-27 Record Message—Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1 (callToBeRecorded)
Event Record
Event Cause Normal
26.1.9.3.4 Functional Requirements
1. If the sampling rate or encoding algorithm are not specified or cannot be provided, then the Voice Unit may use its default sampling rate and/or encoding algorithm.
- 644 -
C
26.1.10 Reposition
S
The Reposition Service changes the flow of voice play back. •
For Voice Unit, the service move the position pointer forward or backward a specified number of milliseconds in a message.
•
For Prompt Queue, the service changes the playing prompts within the frontmost subqueue, moving back or forward a specified number of prompts in the subqueue. Note that the subqueue must be in the Playing state for repositioning.
26.1.10.1 Service Request Table 26-28 Reposition—Service Request Parameter Name
Type
M/ O/C
Description
connection
ConnectionID
M
Specifies the connection on which the message is to be repositioned.
messageToReposition
MessageID
C
Specifies the message whose pointer is to be repositioned. This parameter is mandatory if there are multiple active messages on the specified connection, otherwise the parameter is optional. If this parameter is not provided and the service pertains to a message, the service applies to the currently active message on the specified connection.
resource
ResourceID
C
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
periodOfReposition
Choice Structure
M
Specifies how the pointer should be repositioned. This shall be one of the following choices: • start of message/subqueue • end of message/subqueue • relative position from current pointer (Value) - a positive value moves the message pointer forward (toward the end of the message), a negative value moves the message pointer backward (towards the beginning of the message). For Prompt Queue, the value is capped by the boundaries of the subqueue.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.10.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.10.2.1Positive Acknowledgement Table 26-29 Reposition—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.10.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. - 645 -
26.1.10.3 Operational Model Refer to Figure 6-16, “Voice Unit Operational Model,” on page 29 for the operational model. 26.1.10.3.1Connection State Transitions
There are no connection state changes due to this service. 26.1.10.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 26.1.10.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 26.1.10.3.4Functional Requirements
1. Moving forward and backward within the indicated message on the indicated connection is accomplished by using positive or negative values for the period, respectively. 2. An attempt to move backward beyond the beginning of a message moves to the start of the message. An attempt to move forward beyond the end of the message moves to the end of the message.
- 646 -
26.1.11
C
Resume
S
The Resume Service resumes a voice resource. •
For a message, the Resume Service restarts the playing or recording of a previously suspended message at the current position in the Voice Unit.
•
For Prompt Queue, the Resume Service the playing of a previously suspended prompt.
26.1.11.1 Service Request Table 26-30 Resume—Service Request Parameter Name
Type
M/ O/C
Description
connection
ConnectionID
M
Specifies the connection on which the message is to be resumed.
messageToResume
MessageID
C
Specifies the message to be resumed. This parameter is mandatory if there are multiple suspended messages on the specified connection, otherwise the parameter is optional. If this parameter is not provided and the service applies to a message, the service applies to the currently suspended message on the specified connection.
resource
ResourceID
C
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
duration
Value
O
Specifies the length of time for playback or recording (in milliseconds).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.11.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.11.2.1Positive Acknowledgement Table 26-31 Resume—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.11.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.11.3 Operational Model Refer to Figure 6-16, “Voice Unit Operational Model,” on page 29 for the operational model of the Voice Unit, or Figure 6-19, “Operational Model of a subqueue in a Prompt Queue Resource,” on page 34 for the operational model of Prompt Queue. 26.1.11.3.1Connection State Transitions
There are no connection state changes due to this service. 26.1.11.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 26.1.11.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. - 647 -
26.1.11.3.4Functional Requirements
1. The position pointer in the message may have been changed by using the Reposition service.
- 648 -
C
26.1.12 Review
S
The Review service plays a portion of a voice message during a recording session, until either the end of the portion is reached or a Suspend service request is issued. When this service completes, the position reached becomes the value of the position pointer. This service does not affect the current position unless a suspend occurs before the review completes. 26.1.12.1 Service Request Table 26-32 Review—Service Request Parameter Name
Type
M/ O/C
Description
connection
ConnectionID
M
Specifies the connection on which the message is to be reviewed.
messageToReview
MessageID
C
Specifies the message to be reviewed. This parameter is mandatory if there are multiple active messages on the specified connection, otherwise the parameter is optional. If this parameter is not provided and the service pertains to a message, the service applies to the currently active message on the specified connection.
resource
ResourceID
C
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
periodToReview
Choice Structure
M
Specifies the length of the message to be reviewed. This shall be one of the following choices: • start of message - specifies that the message shall be reviewed from the beginning of the message. • length of review (Value) - specifies the length in milliseconds that the message pointer should be moved towards the beginning of the message before being reviewed.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.12.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.12.2.1Positive Acknowledgement Table 26-33 Review—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.12.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.12.3 Operational Model Refer to Figure 6-16, “Voice Unit Operational Model,” on page 29 for the operational model. 26.1.12.3.1Connection State Transitions
There are no connection state changes due to this service.
- 649 -
26.1.12.3.2Device-Type Monitoring Event Sequences Table 26-34 Review Message—Device-Type Monitoring Event Sequences Monitored Device
Connection
D1
D1C1 (connection)
Event Review
Event Cause Normal
26.1.12.3.3Call-Type Monitoring Event Sequences Table 26-35 Review —Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1 (connection)
Event Review
Event Cause Normal
26.1.12.3.4Functional Requirements
1. The Review service cannot be issued while the Voice Unit is already in the Review state.
- 650 -
C
26.1.13 Set Voice Attribute
S
The Set Voice Attribute service sets the voice attribute for a specified connection and message/resource. To set the global attributes for a specific device, the callID portion of the connectionID can be omitted. The global attributes for a device will be overwritten by consequent Set Voice Attributes with a fully specified connection D. The voice attributes that can be set vary by the device type as specified below. 26.1.13.1 Service Request Table 26-36 Set Voice Attribute—Service Request Parameter Name
Type
M/ O/C
Description
connection
ConnectionID
M
Specifies the Connection on which the voice attribute should be set. To set a global attribute for a device, the callID portion of the connectionID can be omitted.
message
MessageID
C
Specifies the message whose voice attribute is to be set. This parameter is mandatory if there are multiple active messages on the specified connection, otherwise the parameter is optional. If this parameter is not provided and the service applies to a message, then the service applies to the currently active message on the specified connection.
resource
ResourceID
C
- 651 -
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
Table 26-36 Set Voice Attribute—Service Request (continued) Parameter Name attributeToSet
Type
M/ O/C
Description
Choice Structure
M
Specifies the attribute to be set. This shall be one of the following choices: • currentSpeed (Value) - sets the playing speed of the message (represents the percentage of normal speed, with 100% being normal speed and the slowest reportable speed being 1%) (for message, prompt queue) • currentVolume (Choice Structure) - sets the playing volume of the message. May specify either an absolute value or may specify that the volume should be incremented or decremented by a implementation specified increment. It may be one of the following possible choices (for message, prompt queue): •
currentVolAbs (Value) - Specifies a value from 0 through 100. 0 indicates silence, and 100 indicates maximum volume. The granularity and quantization of the values 1 though 99 are device specific
•
currentVolInc (Enumerated) - Specifies if the volume is to be incremented or decremented by a switch specified amount. The complete set of possible values is: increment - the volume is incremented or decrement - the volume is decremented.
• currentGain (Value 0..100) - sets the recording gain of the message (100 indicating maximum level and 0 indicating minimum level) (for message) • grammars (Characters) - sets a list of grammars currently used to process speech or DTMF inputs (for Listener, DTMF) • language (Characters) - sets the languages(s) the Listener is capable of processing, or the language the Prompt is currently using (for Listener, Prompt)
- 652 -
Table 26-36 Set Voice Attribute—Service Request (concluded) Parameter Name
Type
M/ O/C
attributeToSet (continued)
Description • mode (Enumerated) - sets the operation mode (6.1.1.4.8). The possible choices are: (for Listener) •
automatic
•
single
•
multiple
• retain audio (Boolean) - sets the boolean flag indicating whether the audio is being recorded (for Listener) • silence timeout (Value) - sets the timeout value in milliseconds that will causes Silence Timeout expiration (for Listener, DTMF) • max timeout (Value) - sets the value in milliseconds that will cause Max Timeout expiration (for Voice Unit, Listener) • babble timeout (Value) - sets the value in milliseconds that will cause Babble Timeout expiration (for Listener) • end silence (Value) - sets the period in milliseconds for which the Listener will observe as an end of utterance marker or for which the DTMF will observe as end of input marker (for Listener, DTMF) • rejection threshold (Value) - sets the value below which the Listener will raise the outcome under the Not Recognized as opposed to the Recognized Event.(for Listener) • auto interruptible (Boolean) - sets the boolean flag indicating whether the prompt will be automatically stopped by the activity of a Listener or a DTMF resource (for Prompt) • inner XML (Characters) - sets the Speech Synthesis Markup Language document the Prompt is rendering (for Prompt) • inter-digit timeout (Value) - sets the timeout value in milliseconds that will cause inter-digit timeout expiration (for DTMF) • preflush (Boolean) - sets the boolean flag indicating whether DTMF will always clear up its buffer before interaction starts (for DTMF) security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.13.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.13.2.1Positive Acknowledgement Table 26-37 Set Voice Attribute—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.13.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. - 653 -
26.1.13.3 Operational Model 26.1.13.3.1Connection State Transitions
There are no connection state changes due to this service. 26.1.13.3.2Device-Type Monitoring Event Sequences Table 26-38 Set Voice Attribute —Device-Type Monitoring Event Sequences Monitored Device D1
Connection D1C1 (connection)
Event Voice Attribute Changed
Event Cause Normal
26.1.13.3.3Call-Type Monitoring Event Sequences Table 26-39 Set Voice Attribute —Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1 (connection)
Event Voice Attribute Changed
Event Cause Normal
26.1.13.3.4Functional Requirements
1. This service can only be used to set one attribute per service request. If multiple attributes need to be set for the same message, multiple service requests shall be used.
- 654 -
26.1.14 Start The Start service initiates the interaction between a call and an Interactive Voice resource. The service induces the input processing device, such as Listener or DTMF, to transition out of the Null State. For Prompt Queue, the service causes the first prompt subqueue that is not in the Playing State to transition to the Ready State. For Prompt, the service causes the voice of the Prompt to be generated and, if used with Prompt Queue, be queued to the Prompt Queue, and the hosting subqueue to transition to the Ready State. 26.1.14.1 Service Request Table 26-40 Start —Service Request Parameter Name
Type
M/ O/C
Description
overConnection
ConnectionID
M
Specifies the connection for which the interaction is to be started.
resource
ResourceID
C
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
text
Character
O
Specifies, for the Prompt or Prompt Queue only, the text to be synthesized and played, and for Listener or DTMF, the text to be parsed by the grammar.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.14.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.14.2.1Positive Acknowledgement Table 26-41 Start—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.14.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.14.3 Operational Model Refer to Clause 6.1.1.4.8, “Generic Interactive Voice Device Category”, beginning on page 30 for the operational model. 26.1.14.3.1Connection State Transitions
There are no connection state changes due to this service. For Interactive Voice Devices refer to for normative resource state transitions specified in Figure 6-17, Figure 6-18, and Figure 6-19 in Clause 6.1.1.4.8, “Generic Interactive Voice Device Category”, beginning on page 30.
- 655 -
26.1.14.3.2Device-Type Monitoring Event Sequences Table 26-42 Start —Device-Type Monitoring Event Sequences Monitored Device D1
Connection D1C1 (overConnection)
Event
Event Cause
Started
Normal, Forced Transition
Voice Error Occurred
Activation, Bad Grammar, Bad URI, Duplicate DTMF, Empty Queue, Max Timeout, No Audio Saved, No Rule
26.1.14.3.3Call-Type Monitoring Event Sequences Table 26-43 Start —Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1 (overConnection)
Event
Event Cause
Started
Normal
Voice Error Occurred
Activation, Bad Grammar, Bad URI, Duplicate DTMF, Empty Queue, Max Timeout, No Audio Saved, No Rule
26.1.14.3.4Functional Requirements
1. For Prompt with Prompt Queue, the service request is semantically equivalent to a Queue immediately followed by a Start service on the Prompt Queue of the call. For call without a Prompt Queue joined or conferenced in, the service immediately starts the playback. 2. The service request directed at a non NULL input device will be ignored with a positive acknowledgement.
- 656 -
C
26.1.15 Stop
S
The Stop service stops a voice resource. •
For message, the Stop service stops playing or recording of a message and resets the position pointer to the beginning of the message.
•
For Listener, the Stop Service halts the speech input and forces a result based on the input collected up to the point the service request is received.
•
For DTMF, the Stop Service halts the DTMF inputs and forces a result based on the input collected up to the point the service request is received.
•
For Prompt Queue, the Stop service halts the playback and discards the contents of the frontmost subqueue.
26.1.15.1 Service Request Table 26-44 Stop—Service Request Parameter Name
Type
M/ O/C
Description
connection
ConnectionID
M
Specifies the connection on which the interaction is to be stopped.
messageToBeStopped
MessageID
C
Specifies the message whose voice attribute is to be set. This parameter is mandatory if there are multiple active messages on the specified connection, otherwise the parameter is optional. If this parameter is not provided and the service applies to a message, then the service applies to the currently active message on the specified connection.
resource
ResourceID
C
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.15.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.15.2.1Positive Acknowledgement Table 26-45 Stop—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.15.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.15.3 Operational Model Refer to Clause 6.1.1.4.8, “Generic Interactive Voice Device Category”, beginning on page 30 for the operational models of the various types of Voice devices. 26.1.15.3.1Connection State Transitions
There are no connection state changes due to this service.
- 657 -
For Interactive Voice Devices refer to for normative resource state transitions specified in Figure 6-17, Figure 6-18, and Figure 6-19 in Clause 6.1.1.4.8, “Generic Interactive Voice Device Category”, beginning on page 30. 26.1.15.3.2Device-Type Monitoring Event Sequence
Event sequences depend upon the type of voice device. For a Message device: Table 26-46 Stop —Device-Type Monitoring Event Sequences for Voice Unit device Monitored Device D1
Connection D1C1 (connection)
Event Stop
Event Cause Normal
For Listener and DTMF devices: Table 26-47 Stop —Device-Type Monitoring Event Sequences for Listener & DTMF devices Monitored Device D1
Connection D1C1 (connection)
Event
Event Cause
Recognized*
Normal
Not Recognized*
Normal
Voice Error Occurred*
Early Stop
*Note that only one event will be generated. For Prompt device: There are no Voice events for a Prompt device. For Prompt Queue device: Table 26-48 Stop —Device-Type Monitoring Event Sequences for Prompt Queue device Monitored Device D1
Connection D1C1 (connection)
Event Emptied
Event Cause Normal
26.1.15.3.3Call-Type Monitoring Event Sequence
Event sequences depend upon the type of voice device. For a Message device: Table 26-49 Stop —Call-Type Monitoring Event Sequences for Voice Unit device Monitored Device C1
Connection D1C1 (connection)
Event Stop
Event Cause Normal
For Listener and DTMF devices: Table 26-50 Stop —Call-Type Monitoring Event Sequences for Listener & DTMF devices Monitored Device C1
Connection D1C1 (connection)
Event Recognized*
Normal
Not Recognized*
Normal
Voice Error Occurred*
Early Stop
*Note that only one event will be generated. For Prompt device: There are no Voice events for a Prompt device.
- 658 -
Event Cause
For Prompt Queue device: Table 26-51 Stop —Call-Type Monitoring Event Sequences for Prompt Queue device Monitored Device C1
Connection D1C1 (connection)
26.1.15.3.4Functional Requirements
None.
- 659 -
Event Emptied
Event Cause Normal
C
26.1.16 Suspend
S
The Suspend service temporarily stops the voice resource. •
For message, the Suspend Service temporarily stops the playing or recording of a message at the current message and sets the position pointer to be the current position for the Voice Unit,
•
For Prompt Queue, the Suspend Service temporarily stops the playing back of a prompt in the Prompt Queue.
26.1.16.1 Service Request Table 26-52 Suspend—Service Request Parameter Name
Type
M/ O/C
Description
connection
ConnectionID
M
Specifies the connection on which the message is to be suspended.
message
MessageID
C
Specifies the message to be suspended. This parameter is mandatory if there are multiple active messages on the specified connection, otherwise the parameter is optional. If this parameter is not provided and the service is intended for a message, the service applies to the currently active message on the specified connection.
resource
ResourceID
C
Specifies the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.16.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.16.2.1Positive Acknowledgement Table 26-53 Suspend—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.16.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.16.3 Operational Model Refer to Figure 6-16, “Voice Unit Operational Model,” on page 29 for the operational model of the Voice Unit, or Figure 6-19, “Operational Model of a subqueue in a Prompt Queue Resource,” on page 34 for the operational model of Prompt Queue. 26.1.16.3.1Connection State Transitions
There are no connection state changes due to this service.
- 660 -
26.1.16.3.2Device-Type Monitoring Event Sequences Table 26-54 Suspend —Device-Type Monitoring Event Sequences Monitored Device
Connection
D1
D1C1 (connection)
Event
Event Cause
Suspend Play (if suspended while playing)
Normal
Suspend Record (if suspended while recording)
Normal
26.1.16.3.3Call-Type Monitoring Event Sequences Table 26-55 Suspend —Call-Type Monitoring Event Sequences Monitored Call C1
Connection D1C1 (connection)
Event
Event Cause
Suspend Play (if suspended while playing)
Normal
Suspend Record (if suspended while recording)
Normal
26.1.16.3.4Functional Requirements
1. While the message is suspended, the position pointer in the message can be changed by using the Reposition service. 2. The Voice Unit shall continue to play or record the message starting at its position pointer upon receiving the Resume service request.
- 661 -
C
26.1.17 Synthesize Message
S
The Synthesize Message service constructs a voice message from a text stream. This service returns the Message Identifier of the constructed message in the positive acknowledgement. The Synthesize Message service is a “text to speech” function. 26.1.17.1 Service Request Table 26-56 Synthesize Message—Service Request Parameter Name
Type
M/ O/C
Description
textToBeSynthesized
Characters
M
Specifies the text to be converted to voice.
control
List
O
Specifies the control information to be used in construction the voice message. This includes the following: • gender (M) Enumerated - The complete set of possible values is: •
male voice
•
female voice
• language (M) Characters - This is a character string specifying the language. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.17.2 Service Response This service follows the atomic acknowledgement model for this service request. 26.1.17.2.1Positive Acknowledgement Table 26-57 Synthesize Message—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
synthesizedMessage
MessageID
M
Specifies the Message ID that was constructed.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
26.1.17.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 26.1.17.3 Operational Model 26.1.17.3.1Connection State Transitions
There are no connection state changes due to this service. 26.1.17.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 26.1.17.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 26.1.17.3.4Functional Requirements
None.
- 662 -
26.2
Events Table 26-58 Voice Events Summary Description
Pg.
26.2.1 Bookmark Reached
Voice Event
The Bookmark Reached event indicates a mark in the speech synthesis markup language has been reached. No resource state is changed as a result of this event.
664
26.2.2 Completed
The Completed event indicates a prompt has been fully rendered. Just prior to this event, the subqueue containing the prompt must be in the Playing state.
665
26.2.3 DTMF Detected
The DTMF Detected event indicates a DTMF digit has been detected.
666
26.2.4 Emptied
The Emptied event indicates the data of a Listener, DTMF or a subqueue in the Prompt Queue has been emptied.
667
26.2.5 Interruption Detected
The Interruption Detected event indicates an activity has been detected at an Interactive Voice input device during the prompt playback.
668
26.2.6 Not Recognized
The Not Recognized event indicates no outcome or an outcome below the rejection threshold has been detected.
669
26.2.7 Play
The Play event indicates that a message is being played.
670
26.2.8 Recognized
The Recognized event indicates an outcome above the rejection threshold has been detected.
671
26.2.9 Record
The Record event indicates that a message is being recorded.
672
26.2.10 Review
The Review event indicates that a message is being reviewed.
673
26.2.11 Silence Timeout Expired
The Silence Timeout Expired event indicates the silence timeout has been expired for an Interactive Voice input device.
674
26.2.12 Speech Detected
The Speech Detected event indicates a speech like sound has been detected at a Listener.
675
26.2.13 Started
The Started event indicates a voice resource has started interactions with the call and entered the Started state.
676
26.2.14 Stop
The Stop event indicates that a message play or record operation on a connection has stopped.
677
26.2.15 Suspend Play
The Suspend Play event indicates that a message is suspended in play.
678
26.2.16 Suspend Record
The Suspend Record event indicates that a message is suspended during record.
679
26.2.17 Voice Attribute Changed
The Voice Attribute changed event indicates that one or more attributes of a voice message/resource has changed.
680
26.2.18 Voice Error Occurred
The Voice Error Occurred event indicates an error or exception has been encountered.
682
- 663 -
26.2.1
Bookmark Reached
The Bookmark Reached event indicates a mark in the speech synthesis markup language has been reached. No resource state is changed as a result of this event. 26.2.1.1 Event Parameters Table 26-59 Bookmark Reached—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
overConnection
ConnectionID
M
Indicates the connection from which the event is generated.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
bookmark
Characters
M
Indicates the name of the bookmark in the synthesis markup being reached.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.1.2 Event Causes Table 26-60 Bookmark Reached—Event Causes Event Cause Normal
Description The prompt rendering has reached a bookmark in the speech synthesis markup.
- 664 -
Associated Features Start
26.2.2
Completed
The Completed event indicates a prompt has been fully rendered. Just prior to this event, the subqueue containing the prompt must be in the Playing state. This event indicates the prompt queue has either entered the Null state if the prompt is the last entry in the subqueue, or has proceeded to play the next prompt and remains in the Playing state. 26.2.2.1 Event Parameters Table 26-61 Completed—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
overConnection
ConnectionID
M
Indicates the connection from which the event is generated.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.2.2 Event Causes Table 26-62 Completed—Event Causes Event Cause Normal
Description A prompt has been rendered in its entirety.
- 665 -
Associated Features Start
26.2.3
DTMF Detected
The DTMF Detected event indicates a DTMF character has been detected. This event indicates the resource has entered the DTMF Detected state. 26.2.3.1 Event Parameters Table 26-63 DTMF Detected—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
overConnection
ConnectionID
M
Indicates the connection from which the event is generated.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
dtmfChar
Characters
M
Indicates the single DTMF character detected.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.3.2 Event Causes Table 26-64 DTMF Detected—Event Causes Event Cause Normal
Description A DTMF character has been detected
- 666 -
Associated Features Start
26.2.4
Emptied
The Emptied event indicates the data of a Listener, DTMF or a subqueue in the Prompt Queue has been emptied. This event indicates the voice resource has entered the Null resource state. 26.2.4.1 Event Parameters Table 26-65 Emptied—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
overConnection
ConnectionID
M
Indicates the connection from which the event is generated.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.4.2 Event Causes Table 26-66 Emptied—Event Causes Event Cause
Description
Associated Features
Forced Transition
The data in the Listener, DTMF or the frontmost subqueue of the Prompt Queue have been discarded due to the operations of other interactive voice resources.
Start, Queue
Normal
The contents in the DTMF or the frontmost subqueue of a Prompt Queue have been depleted
Start, Clear, Stop
- 667 -
26.2.5
Interruption Detected
The Interruption Detected event indicates an activity has been detected at an Interactive Voice input device during the prompt playback. The prompt being played will be stopped automatically if and only if it is designated as auto-interruptible. If the playback has been stopped, this event indicates the resource has entered the Null state. Otherwise, the resource remains in the Playing state. 26.2.5.1 Event Parameters Table 26-67 Interruption Detected—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
overConnection
ConnectionID
M
Indicates the connection from which the event is generated.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.5.2 Event Causes Table 26-68 Interruption Detected—Event Causes Event Cause Normal
Description An input activity is detected during a prompt playback.
- 668 -
Associated Features Start
26.2.6
Not Recognized
The Not Recognized event indicates no outcome or an outcome below the rejection threshold has been detected. This event indicates the resource has entered the Null resource state. 26.2.6.1 Event Parameters Table 26-69 Not Recognized—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
overConnection
ConnectionID
M
Indicates the connection from which the event is generated.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
result
Characters
O
Indicates the processed outcome from the input.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.6.2 Event Causes Table 26-70 Not Recognized—Event Causes Event Cause
Description
Associated Features
Babble
Speech is detected but the Babble Timeout has expired.
Start
InterdigitTimeout
inter-digit timeout has expired.
Start
Normal
A result exceeding the rejection threshold cannot be found.
Start, Stop
OutOfGrammar
A DTMF key outside of the grammar is detected.
Start
- 669 -
26.2.7
Play
The Play event indicates that a message is being played. 26.2.7.1 Event Parameters Table 26-71 Play—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
Indicates the connection on which the message is being played.
message
MessageID
C
Indicates the message that is being played. This parameter is required if the event pertains to a message.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
length
Value
O
Indicates the length of the message in milliseconds.
currentPosition
Value
O
Indicates the number of milliseconds from the start of the message.
speed
Value
O
Indicates the current playing speed of the message (represents the percentage of normal speed, with 100% being normal speed and the slowest reportable speed being 1%).
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.7.2 Event Causes Table 26-72 Play—Event Causes Event Cause
Description
Associated Features
Next Message
The next message within a sequence of messages is being played (in the case where concurrent play operations are queued, for example).
Play Message
Normal
A message is being played (a more specific cause cannot be provided).
Play Message
- 670 -
26.2.8
Recognized
The Recognized event indicates an outcome above the rejection threshold has been detected. For a Listener under the multiple mode, the resource state can be either Speech Detected or Null. Otherwise, this event indicates the resource has entered the Null resource state. 26.2.8.1 Event Parameters Table 26-73 Recognized—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
overConnection
ConnectionID
M
Indicates the connection from which the event is generated.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
result
Characters
M
Indicates the processed outcome from the input device. The result string can be in either SALT SML or W3C EMMA format, which include confidence measures as well as semantic parses.
text
Characters
M
A text transcription for the result.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.8.2 Event Causes Table 26-74 Recognized—Event Causes Event Cause Normal
Description The result exceeding the rejection threshold has been detected.
- 671 -
Associated Features Start, Stop
26.2.9
Record
The Record event indicates that a message is being recorded. 26.2.9.1 Event Parameters Table 26-75 Record—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
Indicates the connection on which the message is being recorded.
message
MessageID
C
Indicates the message that is being recorded. This parameter is required if the event pertains to a message.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
length
Value
O
Indicates the length of the message in milliseconds.
currentPosition
Value
O
Indicates the number of milliseconds from the start of the message.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.9.2 Event Causes Table 26-76 Record—Event Causes Event Cause Normal
Description A message is being recorded (a more specific cause cannot be provided).
- 672 -
Associated Features Record Message
26.2.10 Review The Review event indicates that a previously recorded message is being reviewed. 26.2.10.1 Event Parameters Table 26-77 Review—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
Indicates the connection on which the message is being reviewed.
message
MessageID
C
Indicates the message that is being reviewed. This parameter is required if the event pertains to a message.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
length
Value
O
Indicates the length of the message in milliseconds.
currentPosition
Value
O
Indicates the number of milliseconds from the start of the message.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.10.2 Event Causes Table 26-78 Review—Event Causes Event Cause Normal
Description A message is being reviewed (a more specific cause cannot be provided).
- 673 -
Associated Features Review Message
26.2.11
Silence Timeout Expired
The Silence Timeout Expired event indicates the silence timeout has expired for an Interactive Voice input device. This event indicates the resource has entered the Null resource state. 26.2.11.1 Event Parameters Table 26-79 Silence Timeout Expired—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
overConnection
ConnectionID
M
Indicates the connection from which the event is generated.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.11.2 Event Causes Table 26-80 Silence Timeout Expired—Event Causes Event Cause Normal
Description The silence timeout has expired.
- 674 -
Associated Features Start
26.2.12 Speech Detected The Speech Detected event indicates a speech-like sound has been detected at a Listener. This event indicates the resource has entered the Speech Detected state. 26.2.12.1 Event Parameters Table 26-81 Speech Detected—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
overConnection
ConnectionID
M
Indicates the connection from which the event is generated.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.12.2 Event Causes Table 26-82 Speech Detected—Event Causes Event Cause Normal
Description Speech has been detected from the audio input.
- 675 -
Associated Features Start
26.2.13 Started The Started event indicates a voice resource has started interactions with the call and entered the Started state. 26.2.13.1 Event Parameters Table 26-83 Started—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
overConnection
ConnectionID
M
Indicates the connection from which the event is generated.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.13.2 Event Causes Table 26-84 Started—Event Causes Event Cause
Description
Associated Features
Forced Transition
The interaction is started due to activity of another resource involved with the call.
Start
Normal
The interaction is started as a result of the Start service
Start
- 676 -
26.2.14 Stop The Stop event indicates that a play or record operation for a message on a connection has been stopped. 26.2.14.1 Event Parameters Table 26-85 Stop—Event Parameters Parameter Name monitorCrossRefID
Type
M/ O/C
Description
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
Indicates the connection of the stopped message.
message
MessageID
C
Indicates the message that is being stopped. This parameter is required if the event pertains to a message.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
length
Value
O
Indicates the length of the message in milliseconds.
currentPosition
Value
O
Indicates the number of milliseconds from the start of the message.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.14.2 Event Causes Table 26-86 Stop—Event Causes Event Cause
Description
Associated Features
DTMF Digit Detected
A DTMF digit was detected during a play or record operation.
Play Message, Record Message, Review Message
End of Message Detected
The end of the message was detected during a play or record operation.
Play Message, Record message
Message Duration Exceeded
The maximum permitted time duration for a play or record operation was detected.
Play Message, Record Message
Message Size Exceeded
The maximum permitted size of the message was detected during a recording operation.
Record Message
Normal
A message has stopped playing or recording (a more specific cause cannot be provided).
Stop Message, Play Message, Record Message
No Speech Detected
A period of silence was detected during a record operation.
Record Message
Speech Detected
Speech (or non-silence) was detected while a message was playing.
Play Message, Review Message
- 677 -
26.2.15 Suspend Play The Suspend Play event indicates that a message is suspended in play. 26.2.15.1 Event Parameters Table 26-87 Suspend Play—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
Indicates the connection of the suspended message.
message
MessageID
C
Indicates the message that is being suspended. This parameter is required if the event pertains to a message.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
length
Value
O
Indicates the length of the message in milliseconds.
currentPosition
Value
O
Indicates the number of milliseconds from the start of the message.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.15.2 Event Causes Table 26-88 Suspend Play—Event Causes Event Cause
Description
Associated Features
DTMF Digit Detected
A DTMF digit was detected during a play operation.
Play Message
Normal
A message has suspended playing (a more specific cause cannot be provided).
Play Message
Speech Detected
Speech (or non-silence) was detected while a message was playing.
Play Message
- 678 -
26.2.16 Suspend Record The Suspend Record event indicates that a message is suspended during recording. 26.2.16.1 Event Parameters Table 26-89 Suspend Record—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
Indicates the connection of the suspended message.
message
MessageID
C
Indicates the message that is being suspended. This parameter is required if the event pertains to a message.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
length
Value
O
Indicates the length of the message in milliseconds.
currentPosition
Value
O
Indicates the number of milliseconds from the start of the message.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.16.2 Event Causes Table 26-90 Suspend Record—Event Causes Event Cause
Description
Associated Features
DTMF Digit Detected
A DTMF digit was detected during a record operation.
Record Message
Message Size Exceeded
The maximum permitted size of the message was detected during a recording operation.
Record Message
Normal
A message has stopped recording (a more specific cause cannot be provided).
Record Message
No Speech Detected
A period of silence was detected during a record operation.
Record Message
- 679 -
26.2.17 Voice Attribute Changed The Voice Attribute changed event indicates that one or more attributes of a voice message/resource has changed. 26.2.17.1 Event Parameters Table 26-91 Voice Attribute Changed—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
connection
ConnectionID
M
Indicates the connection for the message whose attribute has changed.
message
MessageID
C
Indicates the message that has changed. This parameter is required if the changed attribute pertains to a message.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
playVolume
Choice Structure
O
Indicates the current play volume as an absolute value or that the volume was incremented or decremented by a switch specified increment. It may be one of the following possible choices: • playVolAbs (Value) - Specifies a value from 0 through 100. 0 indicates silence, and 100 indicates maximum volume. The granularity and quantization of the values 1 though 99 are device specific. • playVolInc (Enumerated) - Specifies if the volume was incremented or decremented by a switch specified amount. The complete set of possible values is: •
increment - the volume was incremented.
•
decrement - the volume was decremented.
recordingGain
Value (0..100)
O
Indicates the current recording level (100 indicating maximum gain and 0 indicating minimum gain).
speed
Value
O
Indicates the current playing speed of the message (represents the percentage of normal speed, with 100% being normal speed and the slowest reportable speed being 1%).
currentPosition
Value
O
Indicates the number of milliseconds from the start of the message.
grammars
Characters
O
Indicates a list of grammars in URI currently used to process speech or DTMF inputs (for Listener, DTMF, Prompt Queue).
language
Characters
O
Indicates the languages(s) in XML:LANG format the Listener is capable of processing, or the language the Prompt is currently using (for Listener, Prompt).
mode
Enumerated
O
Indicates the operation mode (for Listener). The complete set of possible values is: • automatic • single • multiple
retainAudio
Boolean
O
- 680 -
Indicates the boolean flag indicating whether the audio is being recorded (for Listener).
Table 26-91 Voice Attribute Changed—Event Parameters (concluded) Parameter Name
Type
M/ O/C
Description
silenceTimeout
Value
O
Indicates the timeout value in milliseconds that will cause Silence Timeout expiration (for Listener, DTMF).
maxTimeout
Value
O
Indicates the value in milliseconds that will cause Max Timeout expiration (for Voice Unit, Listener, Prompt, DTMF, Prompt Queue).
babbleTimeout
Value
O
Indicates the value in milliseconds that will cause Babble Timeout expiration (for Listener).
endSilence
Value
O
Indicates the period in milliseconds for which the Listener will observe as an end of utterance marker or for which the DTMF will observe as end of input marker (for Listener, DTMF).
rejectionThreshold
Value
O
Indicates the value below which the Listener will raise the outcome under the Not Recognized as opposed to the Recognized Event (for Listener).
autoInterruptable
Boolean
O
Indicates whether the prompt will be automatically stopped by the activity of a Listener or a DTMF resource (for Prompt).
innerXML
Characters
O
Indicates the Speech Synthesis Markup Language document the Prompt is rendering (for Prompt).
interdigitTimeout
Value
O
Indicates the timeout value in milliseconds that will cause inter-digit timeout expiration (for DTMF).
preflush
Boolean
O
preflush - the boolean flag indicating whether DTMF will always clear up its buffer before interaction starts.
cause
EventCause
O
Indicates the reason for the event.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.17.2 Event Causes Table 26-92 Voice Attribute Changed—Event Causes Event Cause Normal
Description A voice attribute of a message/resource has changed.
- 681 -
Associated Features Set Voice Attribute
26.2.18 Voice Error Occurred The Voice Error Occurred event indicates an error or exception has been encountered. This event indicates the resource has entered the Null resource state. 26.2.18.1 Event Parameters Table 26-93 Voice Error Occurred—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
overConnection
ConnectionID
M
Indicates the connection from which the event is generated.
resource
ResourceID
C
Indicates the interactive voice resource for this service. This parameter is required if there are multiple interactive voice resources per connection.
cause
EventCause
O
Indicates the reason for the event.
servicesPermitted
ServicesPermitted
O
Indicates a list of services that can be applied to the local connection.
security
CSTASecurityData
O
Indicates timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Indicates the non-standardized information attached to the event.
26.2.18.2 Event Causes Table 26-94 Voice Error Occurred—Event Causes Event Cause
Description
Associated Features
Activation
An attempt to activate or deactivate rules has failed
Start
BadAttribute
The attributes cannot be set
Set Voice Attribute
BadGrammar
A grammar cannot be compiled
Start
BadURI
An URI in the synthesis markup cannot be reached
Queue, Start
BadVoice
A voice attribute on the Prompt cannot be met for text to speech synthesis
Queue, Start
DuplicateDTMF
More than one DTMF has been started at the same time
Start
EarlyStop
An input device is stopped before exiting the Started state
Stop
EmptyQueue
An attempt to start an empty Prompt Queue has been detected
Start
InvalidConnection
The call is no longer at the device
any
InvalidConnectionState
The connection at the device has entered a state that halts the media flow, i.e., Queued, Failed, or Hold State
any
NoQueue
An attempt to insert a Prompt voice to the Prompt Queue has failed
Queue
Normal
A voice error has been detected - no specific error cause can be provided.
any
MaxTimeout
A Max timeout has been expired
Start
NoRule
No active rule is detected in the grammar
Start
- 682 -
Table 26-94 Voice Error Occurred—Event Causes (concluded) Event Cause NoAudioSaved
Description No audio can be saved for RetainAudio
- 683 -
Associated Features Start
27
Call Detail Record (CDR) Services This clause specifies the Call Detail Record (CDR) services.
27.1
Services Table 27-1 CDR Services Summary Service
Description
Pg.
27.1.1 Call Detail Records Notification
The Call Detail Records Notification service notifies the computing function that it should obtain the CDR information that has been stored by the switching function (by using the Send Stored Call Detail Records service).
685
27.1.2 Call Detail Records Report
The Call Detail Records Report service provides CDR information to the computing function.
686
27.1.3 Send Stored Call Detail Records
The Send Stored Call Detail Records service initiates the transfer of stored CDR information to the computing function.
691
27.1.4 Start Call Detail Records Transmission
The Start Call Detail Records Transmission service starts the transmission of CDR information.
693
27.1.5 Stop Call Detail Records Transmission
The Stop Call Detail Records Transmission service cancels a previously initiated Call Detail Records Transmission.
695
- 684 -
27.1.1
Call Detail Records Notification
S
C
The Call Detail Records Notification service notifies the computing function that it should obtain the CDR information that has been stored in the switching function. The Send Stored Call Detail Records service should be used to obtain the CDR information. 27.1.1.1 Service Request Table 27-2 Call Detail Records Notification—Service Request Parameter Name
Type
M/ O/C
Description
cdrCrossRefID
CDRCrossRefID
M
Specifies the CDR cross reference identifier.
cdrReason
Enumerated
O
Specifies the reason for sending the service. The complete set of possible values is: • timeout - a timeout has occurred in the switching function • thresholdReached - a threshold reached condition has occurred in the switching function • other - any other reason
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
27.1.1.2 Service Response This service follows the atomic acknowledgement model for this service request. 27.1.1.2.1 Positive Acknowledgement Table 27-3 Call Detail Records Notification—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
27.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 27.1.1.3 Operational Model 27.1.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 27.1.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 27.1.1.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 27.1.1.3.4 Functional Requirements
1. This service is used if a previous Start Call Detail Records Transmission service has specified that the switching function should store CDR information until requested by the computing function (transferMode of transferOnRequest or transferOnThresholdReached) and when a threshold reached condition or a timeout has occurred in the switching function, as indicated in the cdrReason parameter.
- 685 -
27.1.2
Call Detail Records Report
S
The Call Detail Records Report service provides call detail information for one or more calls. This information may be used to derive charging information, statistic purposes, etc. 27.1.2.1 Service Request Table 27-4 Call Detail Records Report—Service Request Parameter Name
Type
M/ O/C
cdrCrossRefID
CDRCrossRefID
M
Specifies the CDR cross reference identifier.
numberOfRecordsSent
Value (1..128)
M
Specifies the number of call detail records that are provided in this service.
- 686 -
Description
C
Table 27-4 Call Detail Records Report—Service Request (continued) Parameter Name cdrInfo
Type
M/ O/C
List of Structures
M
Description Specifies a list CDR information. Each entry in the list consists of the following components: • recordNumber (O) Value (1..128) - Indicates the record number, if more that one record is sent. • recordCreationTime (M) TimeInfo - Indicates the time that the CDR record was created. • callingDevice (O) CallingDeviceID - Indicates the calling device. • calledDevice (O) CalledDeviceID - Indicates the called device. • associatedCallingDevice (O) AssociatedCallingDeviceID - Indicates the Network Interface Device (trunk, for example) associated with the calling device. • associatedCalledDevice (O) AssociatedCalledDeviceID - Indicates the Network Interface Device (trunk, for example) associated with the called device. • networkCallingDevice (O) NetworkCallingDeviceID Indicates the calling device that was provided by the network. • networkCalledDevice (O) NetworkCalledDeviceID Indicates the called device that was provided by the network. • callCharacteristics (O) CallCharacteristics - Indicates the high level characteristics of the call (ACD, for example). • mediaCallCharacteristics (O) MediaCallCharacteristics - Specifies the media class (voice, digital data, etc.), connection rate, etc. of the call. • chargedDevice (O) Choice Structure- Indicates the charged device. Shall be one of the following choices: •
operator (DeviceID) - Indicates the DeviceID of the attendant.
•
nonOperator (DeviceID) - Indicates the nonattendant DeviceID.
• recordedCall (O) ConnectionID - Indicates the call for which the call details are recorded. • nodeNumber (O) List of Values - Indicates the originating node within a switching network. This consists of a list of values corresponding to areas: •
area0 (O) - area0
•
area1 (O) - area1
•
area2 (O) - area2
• tariffTable (O) Value - Indicates the table to be used according to the network type characteristics (PSTN, ISDN, etc.).
- 687 -
Table 27-4 Call Detail Records Report—Service Request (continued) Parameter Name (continued)
Type
M/ O/C
(continued)
Description • connectionStart (O) TimeInfo - Indicates the date and time that the connection was created. • connectionEnd (O) TimeInfo - Indicates the date and time that the connection ended. • connectionDuration (O) Value - Indicates the duration of the connection, in tenths of seconds. • accessCode (O) Characters - Indicates the dialled access number (e.g. to differentiate between business or private external calls). • carrier (O) Value - Indicates the network that was used. • selectedRoute (O) Value - Indicates the route that was used. • billingIdentifier (O) Enumerated - Indicates the type of charging. The complete set of possible values is: •
normalCharging
•
reverseCharging
•
creditCardCharging
•
callForwarding
•
callDeflection
•
callTransfer
•
other
• chargingInfo (O) ChargingInfo - Indicates the value of charging or currency units charged to a device in a call. • supplServiceInfo (O) Bitmap - Indicates the features (supplementary services) used. Multiple bits may be set. The possible values are:
- 688 -
•
normalCall
•
consultationCall
•
transferCall
•
callCompletion
•
callForwarding
•
callDiversion
•
conferencing
•
intrusion
•
userUserInfo - indicates that user related information was exchanged during the call (e.g., public ISDN User to User signalling was used)
•
other
Table 27-4 Call Detail Records Report—Service Request (continued) Parameter Name (continued)
Type (continued)
M/ O/C
Description • reasonForTerm (O) Enumerated - Indicates the reason that the connection was terminated. The complete set of possible values is: • • • • •
normalClearing unsuccessfulCallAttempt abnormalTermination callTransferred other
• authCode (O) AuthCode - Indicates the authorization code used to authorize the call. • accountInfo (O) AccountInfo - Indicates the account code used for the call. • deviceCategory (O) Enumerated - Indicates the device category (station, ACD device, etc.) of the charged device. The complete set of possible values is: • • • • • • • • • • • • • • •
ACD Group Network Interface (e.g., trunk, CO line) Park Routeing Device Station (default) Voice Unit Generic Interactive Voice Listener Interactive Voice DTMF Interactive Voice Prompt Interactive Voice Prompt Queue Interactive Voice Message Interactive Voice Conference Other
• namedDeviceTypes (O) Enumerated - Indicates the named device type of the charged device. The complete set of possible values are: • • • • • • • • • • • • • • • •
ACD ACD Group Button Button Group Conference Bridge Line Line Group Operator Operator Group Parking Device Station Station Group Trunk Trunk Group Other Other Group
• operatorDevice (O) DeviceID - Indicates the operator involved with the call.
- 689 -
Table 27-4 Call Detail Records Report—Service Request (concluded) Parameter Name
Type
M/ O/C
Boolean
lastStoredCDRReportSent
C
Description Specifies if this Call Detail Records Report is the last stored Call Detail Records Report that is being sent by the switching function as a result of a Send Stored Call Detail Records service. The complete set of possible values is: • True - this CDR report is the last stored report that is being sent. After this CDR report is sent, the switching function shall store additional CDR information until the information is requested via another Send Stored Call Detail Records service. • False - this CDR report is not the last stored report being sent. More stored CDR reports will be sent by the switching function. This parameter shall be provided if this service is the result of a Send Stored Call Detail Records service, otherwise it shall not be provided.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
27.1.2.2 Service Response This service follows the atomic acknowledgement model for this service request. 27.1.2.2.1 Positive Acknowledgement Table 27-5 Call Detail Records Report—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
27.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 27.1.2.3 Operational Model 27.1.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 27.1.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 27.1.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 27.1.2.3.4 Functional Requirements
1. This service is sent by the switching function when: •
a Start Call Detail Records Transmission service has indicated the transferMode of transferAtEndOfCall in which case the value of the numberRecords parameter is one, or
•
a Start Call Detail Records Transmission service has indicated the transferMode of transferOnRequest or transferOnThresholdReached and a Send Stored Call Detail Records service has requested that the stored CDR records be sent.
- 690 -
27.1.3
Send Stored Call Detail Records
C
S
The Send Stored Call Detail Records service initiates the en-bloc transfer of CDR information from the switching function for call records that have been stored by the switching function. The service allows CDR information to be requested for a specific time period. 27.1.3.1 Service Request Table 27-6 Send Stored Call Detail Records—Service Request Parameter Name
Type
M/ O/C
Description
cdrCrossRefID
CDRCrossRefID
M
Specifies the CDR cross reference identifier.
timePeriod
List of TimeInfo
O
Specifies the time interval for which CDR information is being requested. This parameter consists of the following components: • beginningOfCDR (M) - specifies the start time • endOfCDR (M) - specifies the end time The time interval refers to the time that the CDR record was created (i.e., the recordCreationTime in the Call Detail Records Report service).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
27.1.3.2 Service Response This service follows the atomic acknowledgement model for this service request. 27.1.3.2.1 Positive Acknowledgement Table 27-7 Send Stored Call Detail Records—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
27.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 27.1.3.3 Operational Model 27.1.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 27.1.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 27.1.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 27.1.3.3.4 Functional Requirements
1. If the transferMode parameter in the Start Call Detail Records Transmission service has indicated transferOnRequest or transferOnThresholdReached, a Send Call Detail Records service request shall be sent when the computing function wants to retrieve the stored call detail information. It shall also be sent if the switching function has indicated, via the Call Detail Records Notification service, that the computing function should obtain the stored CDR information because of a threshold reached condition or timeout, for example.
- 691 -
2. If this service is positively acknowledged, the CDR information is sent to the computing function via the Call Detail Records Report service. 3. If the timePeriod parameter is not supported by the switch, all recorded Call Detail Records should be transmitted, which have not been previously transmitted to the computing function.
- 692 -
27.1.4
Start Call Detail Records Transmission
C
S
The Start Call Detail Records Transmission service starts the collection, and optionally the transmission, of Call Detail Records. The switching function either starts transmitting call detail information at the end of each call (or call segment) or it stores the CDR information until it is requested, as specified in the service request. 27.1.4.1 Service Request Table 27-8 Start Call Detail Records Transmission—Service Request Parameter Name transferMode
Type Enumerated
M/ O/C
Description
M
Specifies the mode of transmission. The complete set of possible modes is: • transferAtEndOfCall - specifies that the requested information shall be sent after the end of each call or call segment. • transferOnRequest - specifies that the requested information shall be stored in the switching function then sent en-bloc on explicit request. • transferOnThresholdReached - specifies that the requested information shall be stored in the switching function then sent en-bloc on explicit request, or when the switching function has determined that a threshold (high water mark) has been reached.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
27.1.4.2 Service Response This service follows the atomic acknowledgement model for this service request. 27.1.4.2.1 Positive Acknowledgement Table 27-9 Start Call Detail Records Transmission Service—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
cdrCrossRefID
CDRCrossRefID
M
Specifies the CDR cross reference identifier.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
27.1.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 27.1.4.3 Operational Model 27.1.4.3.1 Connection State Transitions
There are no connection state changes due to this service. 27.1.4.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 27.1.4.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 27.1.4.3.4 Functional Requirements
1. The cdrCrossRefID parameter is used to correlate subsequent CDR services back to the Start Call Detail Records Transmission service.
- 693 -
2. If the transferMode parameter is specified as transferAtEndOfCall, the switching function shall send the CDR information after the end of a call or call segment (after a call is transferred, for example). 3. If the transferMode parameter is specified as transferOnRequest, the switching function shall store the CDR information until explicitly requested via the Send Stored Call Detail Records service. 4. If the transferMode parameter is specified as transferOnThresholdReached, the switching function shall store the CDR information until explicitly requested via the Send Stored Call Detail Records service or when the switching function has determined that a threshold has been reached.
- 694 -
27.1.5
Stop Call Detail Records Transmission
S
C
The Stop Call Detail Records Transmission service is used to cancel a previously initiated Start Call Detail Records Transmission service. A positive acknowledgement to the service request indicates that the CDR cross reference identifier used in the Start Call Detail Records Transmission service has become invalid. Either the computing function or the switching function may issue the service. 27.1.5.1 Service Request Table 27-10 Stop Call Detail Records Transmission—Service Request Parameter Name
Type
M/ O/C
Description
cdrCrossRefID
CDRCrossRefID
M
Specifies the CDR cross reference identifier.
cdrTermReason
Enumerated
O
Specifies the reason to terminate call detail reports. The possible values are: •
endOfDataDetected
•
errorDetected
•
thresholdReached
•
other
This parameter shall not be provided if the service request is sent from the computing function. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
27.1.5.2 Service Response This service follows the atomic acknowledgement model for this service request. 27.1.5.2.1 Positive Acknowledgement Table 27-11 Stop Call Detail Records Transmission Service—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
27.1.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 27.1.5.3 Operational Model 27.1.5.3.1 Connection State Transitions
There are no connection state changes due to this service. 27.1.5.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 27.1.5.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 27.1.5.3.4 Functional Requirements
1. The computing function may issue the Stop Call Detail Records Transmission service when it no longer wants to receive CDR information. 2. The switching function shall issue the service when it terminates a Call Detail Records Transmission and may supply a reason that the transmission was stopped. - 695 -
3. Once the request has been positively acknowledged, the Call Detail Records Reports shall cease to be sent and the cdrCrossRefID shall be invalid.
- 696 -
28
Location Services
28.1
Location Services Table 28-1 Location Services - Summary Location Service
Description
Pg.
28.1.1 Get Location Information
The Get Location Information service obtains location information associated with a device.
698
28.1.2 Set Location Information
The Set Location Information service associates application-specified location information with a device.
699
28.1.3 Location Tracking Session Resumed
The Location Tracking Session Resumed service indicates that a previously suspended location tracking session has been resumed.
701
28.1.4 Location Tracking Session Suspended
The Location Tracking Session Suspended service indicates that a location tracking session has been suspended.
702
28.1.5 Resume Location Tracking Session
The Resume Location Tracking Session resumes a currently suspended location tracking session.
704
28.1.6 Location Information Report
The Location Information Report indicates location information for a device in a location tracking session.
705
28.1.7 Start Location Tracking Session
The Start Location Tracking Session service starts location tracking for a CSTA device.
707
28.1.8 Stop Location Tracking Session
The Stop Location Tracking Session service terminates an existing location tracking session.
711
28.1.9 Suspend Location Tracking Session
The Suspend Location Tracking Session service suspends a location tracking session.
712
28.1.10 Get Location Tracking Capabilities
The Get Location Tracking Capabilities service obtains the location tracking capabilities associated with a device.
713
28.1.11 Get Location Tracking Sessions
The Get Location Tracking Sessions service obtains a list of existing location tracking sessions in this application association.
715
28.1.12 Location Session Info
The Location Session Info service provides a list of existing location tracking sessions in segments.
717
- 697 -
28.1.1
Get Location Information
C
S
The Get Location Information service requests location information associated with a specified device. 28.1.1.1 Service Request Table 28-2 Get Location Information —Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device to query.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.1.2 Service Response This service follows the atomic acknowledgement model for this service request. 28.1.1.2.1 Positive Acknowledgement Table 28-3 Get Location Information —Positive Acknowledgement Parameter Name locationInfo
Type LocationInfo
M/ O/C O
Description Specifies the location information associated with the device. See 12.2.18, “LocationInfo”, for more information.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 28.1.1.3 Operational Model 28.1.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 28.1.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.1.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.1.3.4 Functional Requirements
1. If this service is supported by the switching function and there is no location information currently associated with the device, the switching function should respond with a Positive Acknowledgement with no locationInfo parameter. 2. This service may be used at any time to obtain the current location information associated with a device. 3. The locationInfo parameter in the service response contains location information associated with the specified device in the service request. For example, depending upon the type of device (user, device, group device, etc.), the locationInfo parameter may be location information contained in one or more device, user, or tuple elements. See 12.2.18, “LocationInfo”, for more information.
- 698 -
28.1.2
Set Location Information
C
The Set Location Information service associates application-specified location information with a device. 28.1.2.1 Service Request Table 28-4 Set Location Information —Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device to which location information is to be associated.
locationInfo
LocationInfo
O
Specifies the location information to associate with the device. If this parameter is not provided, then all existing location information for the specified device shall be cleared. See Functional Requirement #5.
replaceMode
Enumeration
O
Specifies that the provided locationInfo should replace all or a portion of the existing location information associated with the specified device. The set of possible values is: • replaceAll (default) - the provided locationInfo shall replace all existing location information for the specified device • replacePortion - the provided locationInfo shall replace only the equivalent (person, device, or tuple) components in existing location information. Other existing location information components are not affected. See Functional Requirement #4. If this parameter is not provided, then the replaceAll value is used (i.e default).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.2.2 Service Response This service follows the atomic acknowledgement model for this service request. 28.1.2.2.1 Positive Acknowledgement Table 28-5 Set Location Information —Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 28.1.2.3 Operational Model 28.1.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 28.1.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. - 699 -
S
28.1.2.3.4 Functional Requirements
1. If this service is not supported by the specified device the switching function shall respond with a Negative Acknowledgement. 2. The computing function can determine the Location features supported by the device via the Get Location Tracking Capabilities service. 3. If there is a location tracking session associated with the device and the location information is changed via the Set Location Information service, then the changed information shall be reported (subject to the collection and reporting criteria association with the location tracking session) via the Location Information Report service for any location tracking sessions associated with the device. 4. The locationInfo parameter (see 12.2.18, “LocationInfo”) may contain location information that is associated with different elements of the specified device such as a “person” element, one or more “device” elements, or one or more “tuple” elements. This service may be used to replace all the existing location information (e.g. all elements) of the specified device at one time by specifying the replaceMode parameter with a value of “replaceAll”. This service may also be used to replace existing location information elements by specifying the replaceMode parameter with a value of “replacePortion” (for example adding a “user” element to existing location information with one or more “device” elements). 5. Location information associated with specific elements can be cleared by providing replaceMode with a value of replacePortion and by specifying null data for the location information.
- 700 -
28.1.3
Location Tracking Session Resumed
S
C
The Location Tracking Session Resumed service provides information that a previously suspended location tracking session has been resumed. 28.1.3.1 Service Request Table 28-6 Location Tracking Session Resumed—Service Request Parameter Name
Type
M/ O/C
Description
locCrossRefID
LocCrossRefID
M
Specifies the cross reference identifier associated with the location tracking session.
locReason
Enumeration
O
Specifies the reason that the location tracking session was resumed. The set of possible values is: • connection to device/network restored • performance condition relieved
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.3.2 Service Response This service follows the atomic acknowledgement model for this service request. 28.1.3.2.1 Positive Acknowledgement Table 28-7 Location Tracking Session Resumed—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 28.1.3.3 Operational Model 28.1.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 28.1.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.3.3.4 Functional Requirements
1. This service informs the computing function that a previously suspended location tracking session has been resumed. 2. The location tracking session may have been resumed as a result of: •
a CSTA Resume Location Tracking Session service issued by a computing function
•
the switching function resuming a suspended location tracking session because a condition that caused the location tracking session to be suspended is no longer present (e.g. performance condition relieved).
3. When the location tracking session is resumed, the computing function should use the Get Location Info service (28.1.1) to obtain the latest location information. - 701 -
28.1.4
Location Tracking Session Suspended
S
C
The Location Tracking Session Suspended service indicates that a location tracking session has been suspended. Location Information is not collected nor reported during the time when a Location Tracking Session is suspended. 28.1.4.1 Service Request Table 28-8 Location Tracking Session Suspended—Service Request Parameter Name
Type
M/ O/C
Description
locCrossRefID
LocCrossRefID
M
Specifies the cross reference identifier associated with the location session tracking session.
locReason
Enumeration
O
Specifies the reason that the location tracking session was suspended. The set of possible values is: • connection to device/network interrupted • performance condition
locationInfoList
LocationInfoList
O
Specifies the list of collected location information that has not been reported when the location tracking session is suspended.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.4.2 Service Response This service follows the atomic acknowledgement model for this service request. 28.1.4.2.1 Positive Acknowledgement Table 28-9 Location Tracking Session Suspended—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.4.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 28.1.4.3 Operational Model 28.1.4.3.1 Connection State Transitions
There are no connection state changes due to this service. 28.1.4.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.4.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.4.3.4 Functional Requirements
1. This service informs the computing function that the switching function has suspended a location tracking session. 2. Location information that has been collected but not yet reported when the Location Tracking Session is suspended should be provided in the locationInfoList parameter. - 702 -
3. The location tracking session may have been suspended as a result of: •
a CSTA Suspend Location Tracking Session service issued by a computing function
•
a switching function suspending a location tracking session due to performance, when the SF is unable to communicate with a device (loss of network connectivity), etc.
4. The Resume Location Tracking service may be used to attempt to resume a suspended location tracking session.
- 703 -
28.1.5
Resume Location Tracking Session
C
S
The Resume Location Tracking Session service requests the switching function to resume a currently suspended location tracking session. 28.1.5.1 Service Request Table 28-10 Resume Location Tracking Session —Service Request Parameter Name
Type
M/ O/C
Description
locCrossRefID
LocCrossRefID
M
Specifies the cross reference identifier associated with the location tracking session.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.5.2 Service Response This service follows the atomic acknowledgement model for this service request. 28.1.5.2.1 Positive Acknowledgement Table 28-11 Resume Location Tracking Session —Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.5.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 28.1.5.3 Operational Model 28.1.5.3.1 Connection State Transitions
There are no connection state changes due to this service. 28.1.5.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.5.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.5.3.4 Functional Requirements
1. If the Resume Location Tracking Session service is received while the specified location tracking session is not suspended, the switching function shall respond with negative acknowledgement 2. When the location tracking session has been resumed the switching function sends the Location Tracking Session Resumed service. 3. If the switching function is unable to resume the location tracking session (performance condition still exists, for example), it shall respond with a negative acknowledgement and no Location Tracking Session Resumed service shall be sent.
- 704 -
28.1.6
Location Information Report
S
C
The Location Information Report service provides location information for a device in the context of a location tracking session. A location tracking session must be established before a Location Information Report service is sent by a switching function. Location Information Report services continue to be sent (subject to collection and reporting criteria) as long as the location tracking session is maintained (not suspended). 28.1.6.1 Service Request Table 28-12 Location Information Report —Service Request Parameter Name
Type
M/ O/C
Description
locCrossRefID
LocCrossRefID
M
Specifies the cross reference identifier associated with the location tracking session.
device
deviceID
M
Specifies the device associated with the location information.
locationInfoList
LocationInfoList
O
Specifies a list of location information associated with the device. This parameter consists of zero or more locationInfo structures. If this parameter is not provided, then there is no location information to report (subject to the location tracking session collection and reporting criteria).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.6.2 Service Response This service follows the atomic acknowledgement model for this service request. 28.1.6.2.1 Positive Acknowledgement Table 28-13 Location Information Report —Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.6.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 28.1.6.3 Operational Model 28.1.6.3.1 Connection State Transitions
There are no connection state changes due to this service. 28.1.6.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.6.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.6.3.4 Functional Requirements
1. The switching function sends a Location Information Report service whenever it has location information to report to the switching function (subject to the location tracking session collection and reporting criteria as specified in the Start Location Tracking Session service).
- 705 -
2. The locationInfoList parameter contains a list of collected location information associated with the location tracking session. Each location information in the list for example, depending upon the type of device (user, device, group device, etc.), may contain location information in one or more device, user, or tuple elements. See 12.2.19, “LocationInfoList”, for more information.
- 706 -
28.1.7
Start Location Tracking Session
C
S
The Start Location Tracking Session service creates a location tracking session. A location tracking session provides a context in which to control the sending of location information. A parameter is returned in the positive acknowledgement that is used to identify the location tracking session in subsequent services. Tracking location information involves the following: 1. The collection of location information. In order to control the rate in which location information is collected, this service specifies a set of collection criteria that indicates how the switching function should collect location information. For example collect location information every minute. 2. The reporting of location information. In order to reduce the frequency of CSTA Location Information Report service(s), this service specifies a set of reporting criteria that indicates how the switching function should buffer collected location information before sending them to the computing function. For example send collected location information every 5 minutes. Once a location tracking session has been created, the Location Information Report service provides the location information. Location Information Report services continue to be generated (subject to collection and reporting criteria) as long as the location tracking session exists. 28.1.7.1 Service Request Table 28-14 Start Location Tracking Session —Service Request Parameter Name
Type
M/ O/C
Description
locDevice
DeviceID
M
Specifies the device for which location information is to be tracked.
collectionType
Enumeration
O
Specifies the type of collection. The possible values are: •
periodic - the SF should collect location information at a specified interval (see collectionInterval parameter).
•
updates only - the SF should collect location information whenever it changes (subject to collectionFilter)
•
periodic with updates - the SF should collect location information whenever it changes (subject to collectionFilter). If the location information has not changed within the specified collectionInterval then the SF should collect the location information at the specified collectionInterval.
If the parameter is not supported by the switching function or if the parameter is supported but not provided, the switching function shall use a switching function default value (as indicated in the capability exchange services). collectionInterval
Value
O
Specifies the time in seconds between when the SF collects location information. If the parameter is not supported by the switching function or if the parameter is supported but not provided, the switching function shall use a switching function default value (as indicated in the capability exchange services).
- 707 -
Table 28-14 Start Location Tracking Session —Service Request (continued) Parameter Name maxCollections
Type Value
M/ O/C
Description
O
Specifies the maximum number of collections (per hour). The switching function will not collect any additional location information for this tracked resource that exceeds this value until the next hour. If the parameter is not supported by the switching function or if the parameter is supported but not provided, the switching function shall use a switching function default value (as indicated in the capability exchange services).
collectionFilter
Structure
O
Specifies the filter criteria for collecting location information. This consists of one or more of the following filters: • horizontalMovement (O) Value - collect location information when a tracked resource moves at least a specified horizontal distance (in meters) from the last position where the data was collected. The collection filter criteria can contain a maximum of one horizontalMovement filter. • verticalMovement (O) Value - collect location information when a tracked resource moves at least a specified vertical distance (in meters) from the last position where the data was collected. The collection filter criteria can contain a maximum of one verticalMovement filter. • civicAddressChange (O) Enumeration - collect location information when the civic address associated with a tracked resource changes. This parameter consists of a specific list of civic address type attributes as specified in IETF RFC-4776. If any of these specified civic address type labels change than the location information is collected. There may be multiple civicAddressChange filters specified in this parameter but each must be a unique civic address type label. Location information is collected whenever any of the collection filter criteria is satisfied. If the parameter is not supported by the switching function or if the parameter is supported but not provided, the switching function shall use a switching function default value (as indicated in the capability exchange services).
reportingType
Enumeration
O
Specifies the type of reporting. The possible values are: •
immediate - the SF should report collected location information whenever it has been collected.
•
periodic - the SF should report collected location information at a specified interval (subject to reportingInterval parameter).
•
count - the SF should report collected location information after the specified number of location information have been collected (subject to reportingCount)
If the parameter is not supported by the switching function or if the parameter is supported but not provided, the switching function shall use a switching function default value (as indicated in the capability exchange services).
- 708 -
Table 28-14 Start Location Tracking Session —Service Request (concluded) Parameter Name reportingInterval
Type
M/ O/C
Value
O
Description Specifies the time in seconds between when the SF reports collected location information. This parameter is only used when the reportingType is periodic. If the parameter is not supported by the switching function or if the parameter is supported but not provided, the switching function shall use a switching function default value when the reportingType is periodic (as indicated in the capability exchange services).
reportingCount
Value
O
Specifies the number of location information records that should be collected before the SF reports them. This parameter is only used when the reportingType is count. If the parameter is not supported by the switching function or if the parameter is supported but not provided, the switching function shall use a switching function default value when the reportingType is count (as indicated in the capability exchange services).
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.7.2 Service Response This service follows the atomic acknowledgement model for this service request. 28.1.7.2.1 Positive Acknowledgement Table 28-15 Start Location Tracking Session —Positive Acknowledgement Parameter Name locCrossRefID
Type
M/ O/C
Description
LocCrossRefID
M
Specifies the cross reference identifier associated with the location tracking session that has been created. This value is unique within the switching function.
pidfProfile
Enumeration
M
Specifies the CSTA PIDF-LO Profile for the creation and interpretation of the PIDF-LO data in the locationInfo parameter. The possible values are: •
PIDF Profile Option 1
•
PIDF Profile Option 2
See 12.2.18, “LocationInfo”, on page 137 for a description. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.7.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 28.1.7.3 Operational Model 28.1.7.3.1 Connection State Transitions
There are no connection state changes due to this service. 28.1.7.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. - 709 -
28.1.7.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.7.3.4 Functional Requirements
1. Prior to issuing the Start Location Tracking Session service the computing function can obtain the location capabilities supported by the switching function via 28.1.10, “Get Location Tracking Capabilities” service. 2. If the switching function is unable to support the collection and reporting criteria specified in the service request the switching function may either reject the request or it may create a location tracking session using switching function specified criteria. 3. The collectionFilter parameter can be used to adjust conditions for which location information is collected in order to reduce unwanted information and to and to optimize performance. For example if a computing function wants to collect location information whenever: a. a tracked resource moves to a new zip/postal code (civic address type label PC) it should specify a collectionFilter with a civicAddressChange of PC b. a tracked resource moves to a new street (civic address type label RD) or to a new city (civic address type label A3) it should specify a collectionFilter with a civicAddressChange of RD and one with A3 c.
a tracked resource moves 1000 meters horizontally from the last position that was collected it should specify a collectionFilter with a horizontalMovement of 1000
d. a tracked resource moves to a different floor of a building or changes buildings it should specify a collectionFilter with a civicAddressChange of BLD and one with FLR. 4. Stopping a location tracking session: a. An existing location tracking session can be stopped via 28.1.8, “Stop Location Tracking Session”. This service can be issued by either the computing function or by the switching function. 5. Suspending & Resuming a location tracking session: a. At any time the computing function can request a suspension and later resumption of a location tracking session via the 28.1.9, “Suspend Location Tracking Session” and 28.1.5, “Resume Location Tracking Session” services. b. At any time based upon switching function criteria (e.g. performance) the switching function may suspend and later resume a location tracking session (e.g. performance condition relieved). c.
The Location Tracking Session Suspended service indicates that a location tracking session has been suspended (either by the switching function or at the request of the computing function).
d. The Location Tracking Session Resumed service indicates that a location tracking session has been resumed (either by the switching function or at the request of the computing function).
- 710 -
28.1.8
Stop Location Tracking Session
S
C
The Stop Location Tracking service terminates an existing location tracking session. This is a bi-directional service. 28.1.8.1 Service Request Table 28-16 Stop Location Tracking Session —Service Request Parameter Name
Type
M/ O/C
Description
locCrossRefID
LocCrossRefID
M
Specifies the cross reference identifier associated with the location tracking session to be terminated.
reason
EventCause
O
Specifies the reason the location tracking session is being terminated. See 12.2.15, “EventCause” for a list of possible values.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.8.2 Service Response This service follows the atomic acknowledgement model for this service request. 28.1.8.2.1 Positive Acknowledgement Table 28-17 Stop Location Tracking Session —Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.8.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 28.1.8.3 Operational Model 28.1.8.3.1 Connection State Transitions
There are no connection state changes due to this service. 28.1.8.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.8.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.8.3.4 Functional Requirements
1. It is not necessary for a suspended location tracking session to be resumed for this service to be carried out.
- 711 -
28.1.9
Suspend Location Tracking Session
C
S
The Suspend Location Tracking Session service suspends a specified location tracking session but does not destroy the location tracking session. Location Information is not collected nor reported during the time when a location tracking session is suspended. 28.1.9.1 Service Request Table 28-18 Suspend Location Tracking Session —Service Request Parameter Name
Type
M/ O/C
Description
locCrossRefID
LocCrossRefID
M
Specifies the cross reference identifier associated with the location tracking session to be suspended.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.9.2 Service Response This service follows the atomic acknowledgement model for this service request. 28.1.9.2.1 Positive Acknowledgement Table 28-19 Suspend Location Tracking Session —Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.9.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 28.1.9.3 Operational Model 28.1.9.3.1 Connection State Transitions
There are no connection state changes due to this service. 28.1.9.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.9.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.9.3.4 Functional Requirements
1. The computing function indicates that the location tracking session should be suspended, but not destroyed. The Resume Location Tracking Session service may then be used to resume the location tracking session. 2. A Location Tracking Session Suspended service will be generated as a result of this service. Collected location information that has not yet been reported will be provided with this service.
- 712 -
28.1.10 Get Location Tracking Capabilities
C
S
The Get Location Tracking Capabilities service obtains the current set of location tracking capabilities supported by the device. This service may be used to determine which location tracking capabilities are supported for a device prior to issuing the Start Location Tracking Session service. 28.1.10.1 Service Request Table 28-20 Get Location Tracking Capabilities —Service Request Parameter Name
Type
M/ O/C
Description
device
DeviceID
M
Specifies the device being queried.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.10.2 Service Response This service follows the atomic acknowledgement model for this request. 28.1.10.2.1Positive Acknowledgement Table 28-21 Get Location Tracking Capabilities —Positive Acknowledgement Parameter Name collectionTypeDefault
Type
M/ O/C
Description
Enumeration
M
Specifies the collectionType default value. The possible values are: • periodic • updatesOnly • periodicWithUpdates
collectionTypePeriodic
Boolean
M
If TRUE then the capability is supported.
collectionTypeUpdatesOnly
Boolean
M
If TRUE then the capability is supported.
collectionTypePeriodicWithUpd ates
Boolean
M
If TRUE then the capability is supported.
collectionIntervalDefault
Value
M
Specifies collectionInterval default value in seconds.
collectionIntervalMin
Value
M
Specifies the minimal supported collection interval value.
collectionIntervalMax
Value
M
Specifies the maximum supported collection interval value.
maxCollectionsDefault
Value
M
Specifies maxCollections default value for one hour.
maxCollectionsMin
Value
M
Specifies the minimal supported maxCollections value.
maxCollectionsMax
Value
M
Specifies the maximum supported maxCollections value.
collectionFilterDefault
Enumeration
M
Specifies the collectionType default value. The possible values are: • horizontalMovement • verticalMovement • civicAddressChange • none
collectionFilterHorizontal
Boolean
M
If TRUE then the capability is supported.
collectionFilterVertical
Boolean
M
If TRUE then the capability is supported.
collectionFilterCivicAddress
Boolean
M
If TRUE then the capability is supported.
- 713 -
Table 28-21 Get Location Tracking Capabilities —Positive Acknowledgement (concluded) Parameter Name reportingTypeDefault
Type
M/ O/C
Description
Enumeration
M
Specifies the reportingType default value. The possible values are: • immediate • periodic • count
reportingTypeImmediate
Boolean
M
If TRUE then the capability is supported.
reportingTypePeriodic
Boolean
M
If TRUE then the capability is supported.
reportingTypeCount
Boolean
M
If TRUE then the capability is supported.
reportingIntervalDefault
Value
M
Specifies the default value.
reportingIntervalMin
Value
M
Specifies the minimal supported reporting interval value.
reportingIntervalMax
Value
M
Specifies the maximum supported reporting interval value.
reportingCountDefault
Value
M
Specifies the default value.
reportingCountMin
Value
M
Specifies the minimal supported reporting count value.
reportingCountMax
Value
M
Specifies the maximum supported reporting count value.
supportsSuspendingTracking
Boolean
M
Specifies if the Suspend Location Tracking Session service is supported.
supportsResumingTracking
Boolean
M
Specifies if the Suspend Location Tracking Session service is supported.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.10.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 28.1.10.3 Operational Model 28.1.10.3.1Connection State Transitions
There are no connection state changes as the result of this service. 28.1.10.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.10.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.10.3.4Functional Requirements
1. This service shall be rejected with a negative acknowledgement if the device does not support location tracking. 2. The device specified in the service request may refer to a single device (e.g. phone) or a group device (e.g. user). 3. If the device is a group device then the location tracking capabilities returned in the response shall reflect the capabilities of the group device in the context of what the switching function supports on the Set Location Tracking Session service for the specified group device. •
The group device may consist of members that have different location tracking capabilities. A Get Location Tracking Capabilities service can be used to determine the location tracking capabilities of a specific member of the group device.
- 714 -
28.1.11
Get Location Tracking Sessions
C
S
The Get Location Tracking Sessions service is used to obtain information about switching function location tracking sessions for the CSTA application association. The location tracking session information includes the value of the location cross referenceID and the deviceID of the resource being tracked. Information shall be provided using one of two possible mechanisms (as indicated by the capability exchange services): either in the Get Location Tracking Sessions positive acknowledgement or in one or more messages using the Location Session Info Service. Note that both mechanisms cannot be used at the same time. 28.1.11.1 Service Request Table 28-22 Get Location Tracking Sessions —Service Request Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.11.2 Service Response This service follows the atomic acknowledgement model for this request. 28.1.11.2.1Positive Acknowledgement Table 28-23 Get Location Tracking Sessions —Positive Acknowledgement Parameter Name serviceCrossRefID
Type
M/ O/C
Description
ServiceCrossRefID
C
Specifies the reference used to associate subsequent Location Session Info services to this service request. This parameter is mandatory if the switching function is providing the existing monitor information using the Location Session Info service, otherwise it shall not be provided.
locationSessionInfoList
Structure
C
This parameter contains zero or more entries. Each entry contains information about an existing switching function location tracking session that includes: •
locCrossRefID (M) LocCrossRefID - the location tracking session cross referenceID that was provided when the location tracking session was created
•
locDevice (M) DeviceID - the deviceID associated with the tracked resource
This parameter is mandatory if the switching function is providing all of the response information in this message. This parameter shall not be provided if the switching function is providing the response information using the Location Session Info Service. security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.11.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 28.1.11.3 Operational Model
- 715 -
28.1.11.3.1Connection State Transitions
There are no connection state changes as the result of this service. 28.1.11.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.11.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.11.3.4Functional Requirements
1. None.
- 716 -
28.1.12 Location Session Info
S
C
This service provides information about existing location tracking sessions in the switching function for the CSTA application association. This service is generated as a result of the Get Location Tracking Sessions service. It is used when the switching function is providing location tracking sessions information in multiple messages (otherwise the switching function provides the registration information in the Get Location Tracking Sessions positive acknowledgement). The switching function may generate a sequence of Location Session Info services, individually referred to as segments, in response to a single Get Location Tracking Sessions service request. 28.1.12.1 Service Request Table 28-24 Location Sessions Info—Service Request Parameter Name
Type
M/ O/C
Description
serviceCrossRefID
ServiceCrossRefID
M
Specifies the reference used to associate the Location Sessions Info service messages to the Get Location Tracking Sessions service request.
segmentID
Value
O
Specifies the segment number of this message. Each successive segment number in the sequence increments the segmentID by one.
lastSegment
Boolean
M
Specifies if this segment is the last one associated with the serviceCrossRefID. The complete set of possible values is: • TRUE - Indicates that this is the last segment. • FALSE - Indicates that this is not the last segment in the sequence.
locationSessionInfoList
Structure
M
This parameter contains zero or more entries. Each entry contains information about an existing switching function location tracking session that includes: •
locCrossRefID (M) MonitorCrossRefID - the location tracking session cross referenceID that was provided when the location tracking session was created
•
locDevice (M) DeviceID - the deviceID associated with the tracked resource
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
28.1.12.2 Service Response There are no service request completion conditions associated with this service. 28.1.12.2.1Positive Acknowledgement
There is no positive acknowledgement associated with this service request. 28.1.12.2.2Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 28.1.12.3 Operational Model 28.1.12.3.1Connection State Transitions
There are no connection state changes due to this service. 28.1.12.3.2Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 28.1.12.3.3Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. - 717 -
28.1.12.3.4Functional Requirements
1. Due to the nature of the switching function configuration, the switching function may buffer the Location Session Info messages to the computing function. The time between these messages may vary significantly between various implementations. 2. The information reported in the sequence of segments generated from the Get Location Tracking Session service request represents the state of the location tracking sessions at the time the Get Location Tracking Sessions service is positively acknowledged.
- 718 -
29
Vendor Specific Extensions Services & Events This clause consists of:
29.1
•
Escape Registration Services
•
Escape Services
•
Private Events
Registration Services Table 29-1 Escape Registration Services Summary Escape Registration Service
Description
Pg.
29.1.1 Escape Register
Registers the computing function for escape services with the switching function.
720
29.1.2 Escape Register Abort
Indicates that the switching function has terminated an escape service registration.
721
29.1.3 Escape Register Cancel
Unregisters the computing function for escape services with the switching function.
722
- 719 -
29.1.1
Escape Register
C
S
The Escape Register service is used by the computing function to register to receive escape services from the switching function. The computing function may be required to register for escape services before it can receive any Escape service requests from the switching function. 29.1.1.1 Service Request Table 29-2 Escape Register—Service Request Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
29.1.1.2 Service Response This service follows the atomic acknowledgement model for this service request. 29.1.1.2.1 Positive Acknowledgement Table 29-3 Escape Register—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
escapeRegisterID
EscapeRegisterID
M
Specifies the escape registration identifier for this registration.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
29.1.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 29.1.1.3 Operational Model 29.1.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 29.1.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 29.1.1.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 29.1.1.3.4 Functional Requirements
1. The escapeRegisterID parameter returned in the positive acknowledgement is used to identify the registration over which escape services will be sent. The escapeRegisterID is also used when cancelling the escape registration. 2. The number of simultaneous escape registrations allowed is switching function dependent. When the limit is reached, subsequent Escape Register service requests shall result in negative acknowledgements from the switching function.
- 720 -
29.1.2
Escape Register Abort
S
C
The Escape Register Abort service is used by the switching function to asynchronously cancel an active escape registration. This service invalidates a current escape registration. 29.1.2.1 Service Request Table 29-4 Escape Register Abort—Service Request Parameter Name
Type
M/ O/C
Description
escapeRegisterID
EscapeRegisterID
M
Specifies the escape registration identifier for the escape registration that was aborted.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
29.1.2.2 Service Response There are no service completion conditions for this service. 29.1.2.2.1 Positive Acknowledgement
There is no positive acknowledgement defined for this service. 29.1.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 29.1.2.3 Operational Model 29.1.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 29.1.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 29.1.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 29.1.2.3.4 Functional Requirements
1. The switching function may issue this service at any time when it can no longer maintain the escape registration (e.g. when the vendor-specific extensions are no longer available). 2. The computing function may send a negative acknowledgement to this service request, but no positive acknowledgement is defined.
- 721 -
29.1.3
Escape Register Cancel
C
S
The Escape Register Cancel service is used to cancel a previous escape registration. This request terminates the escape registration and the computing function receives no further escape service requests for that escape registration once it receives the positive acknowledgement to the Escape Register Cancel request. 29.1.3.1 Service Request Table 29-5 Escape Register Cancel—Service Request Parameter Name
Type
M/ O/C
Description
escapeRegisterID
EscapeRegisterID
M
Specifies the escape registration identifier for which the escape registration is to be cancelled.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
29.1.3.2 Service Response This service follows the atomic acknowledgement model for this service request. 29.1.3.2.1 Positive Acknowledgement Table 29-6 Escape Register Cancel—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
29.1.3.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 29.1.3.3 Operational Model 29.1.3.3.1 Connection State Transitions
There are no connection state changes due to this service. 29.1.3.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 29.1.3.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 29.1.3.3.4 Functional Requirements
1. The computing function shall continue to process outstanding escape service requests from the switching function until it receives a positive acknowledgement for the Escape Register Cancel service request. The switching function shall not send any further escape service requests for a registration once it has sent the positive acknowledgement.
- 722 -
29.2
Services Table 29-7 Escape Services Summary Escape Service
Description
Pg.
29.2.1 Escape
Provides a mechanism to send a non-standardized feature.
724
29.2.2 Private Data Version Selection
Provides the switching function with the selected version for private data.
725
- 723 -
29.2.1
Escape
C
S
The Escape service is used by an implementation to send a non-standardized (implementation specific) feature using the CSTA protocol. This service shall not be used for features that can be invoked with standardized services. The Escape service allows an implementation to “escape” from standard operations in order to exploit some special feature of an implementation. This mechanism also allows manufacturers to experiment with new features that may, at a later date, become standardized. 29.2.1.1 Service Request Table 29-8 Escape—Service Request Parameter Name escapeRegisterID
Type EscapeRegisterID
M/ O/C
Description
C
Specifies the escape registration identifier associated with the escape registration for this request. This parameter is mandatory if the switching function is issuing the request and supports escape registration, and shall not be provided otherwise.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
M
Specifies the non-standardized information.
29.2.1.2 Service Response This service follows the atomic acknowledgement model for this service request. 29.2.1.2.1 Positive Acknowledgement Table 29-9 Escape—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
29.2.1.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 29.2.1.3 Operational Model 29.2.1.3.1 Connection State Transitions
There are no connection state changes due to this service. 29.2.1.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 29.2.1.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 29.2.1.3.4 Functional Requirements
1. The privateData parameter in the service request shall be used to provide the non-standardized feature information (feature specific parameters, for example). 2. The privateData parameter in the positive acknowledgement shall be used, if necessary, to provide feature specific response information. 3. Although there are no connection state transitions or events specified by this service, the nonstandardized feature requested via this service may cause some implementation-specific connection state change(s) or event(s) to occur. 4. The Escape service shall use ASN.1 (Abstract Syntax Notation) Object Identifiers. - 724 -
29.2.2
Private Data Version Selection
C
S
The Private Data Version Selection service provides the switching function with the selected version for Private Data. 29.2.2.1 Service Request Table 29-10 Private Data Version Selection—Service Request Parameter Name privateDataVersion
Type Value
M/ O/C
Description
M
Represents the version number to be used for future Private Data. A value of 0 means Private Data is not to be used.
29.2.2.2 Service Response This service follows the atomic acknowledgement model for this service request. 29.2.2.2.1 Positive Acknowledgement Table 29-11 Private Data Version Selection—Positive Acknowledgement Parameter Name
Type
M/ O/C
Description
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
O
Specifies non-standardized information.
29.2.2.2.2 Negative Acknowledgement
The negative acknowledgement error codes are described in 12.2.14, “ErrorValue”, on page 121. 29.2.2.3 Operational Model 29.2.2.3.1 Connection State Transitions
There are no connection state changes due to this service. 29.2.2.3.2 Device-Type Monitoring Event Sequences
There are no events generated as a result of this service. 29.2.2.3.3 Call-Type Monitoring Event Sequences
There are no events generated as a result of this service. 29.2.2.3.4 Functional Requirements
1. The computing function shall choose one of the private data version number(s) supported by the switching function (or if it does not want the switching function to provide private data, it should provide a value of 0). The computing function may obtain the list of private data versions: a. in the response to the Get Switching Function Capability service and b. in the ACSE Association Information provided by the switching function. 2. This service should not be issued before the first Get Switching Function Capabilities acknowledgement has been received by the computing function, unless the switching function has provided its supported private data version numbers in the ACSE Association Information.
- 725 -
29.3
Events Table 29-12 Private Events Summary Private Event 29.3.1 Private Event
Description
Pg.
Provides a mechanism to send implementation-specific extended information event.
727
- 726 -
29.3.1
Private Event The Private Event is used by an implementation to send unsolicited, non-standardized (implementation specific) event information using the CSTA protocol. The Private Event shall not be used to convey event information that can be reported with standardized events.
The Private Event allows an implementation to exploit some special feature of an implementation. 29.3.1.1 Event Parameters Table 29-13 Private Event—Event Parameters Parameter Name
Type
M/ O/C
Description
monitorCrossRefID
MonitorCrossRefID
M
Associates the event to an established monitor.
security
CSTASecurityData
O
Specifies timestamp information, message sequence number, and security information.
privateData
CSTAPrivateData
M
Specifies the non-standardized information.
29.3.1.2 Functional Requirements 1. The privateData parameter shall be used to provide the non-standardized event information (feature specific parameters, for example). 2. The type of monitors (i.e., device-type or call-type) for which this event is reported is switching function implementation specific.
- 727 -
- 728 -
Annex A (normative)
Device Appearances This annex describes the types of appearances supported by CSTA devices and their associated behaviour. For an introduction to logical elements and appearances, refer to 6.1.1.2, “Logical Element”, on page 17. The type of appearance is based on its relationship with other devices. The type of appearance plays a great role in determining the functionality and behaviour associated with the logical element of the device. There are two types of appearances: •
Standard Appearance (see A.1)
•
Bridged Appearance (see A.2)
The following notation is used in the figures throughout this Annex. D
represents another device
L
represents the identifiers for the logical elements
A
represents an appearance of a logical element
indicates that there is an interaction and/or association between the elements or components of an element.
A.1
Standard Appearance A standard appearance of a device’s logical element is not associated with other devices (i.e., cannot handle calls at another device). When a call arrives at the logical element, standard appearances are selected according to their behaviour: •
Selected-Standard Appearance (see A.1.1)
•
Basic-Standard Appearance (see A.2.1)
In addition, all media streams associated with calls corresponding to the appearances are only available to the physical element of the device (if it has one). This type of appearance can be either addressable or non-addressable. Refer to Clause 10, “CSTA Device Identifier Formats”, on page 102 for information on how to reference this appearance. When a call activity at one appearance results in the need for another appearance (i.e., the appearance puts the call on hold and wants to allow for the initiation of another call from the logical element), the logical element will use one of the available appearance (i.e., idle). If an available appearance is not present, the call will not be accepted by the logical element.
A.1.1
Selected-Standard Appearance When calls are presented to the logical element, an available (i.e., idle) appearance is selected and only that appearance is presented with the call. From that point on, the handling of the call does not have any special characteristics or behaviours. Figure A-1 illustrates selected-standard appearances. In this example, the logical element is L and it has three addressable selected-standard appearances (A1, A2, A3). A call is currently being handled by appearance A3. When a new call (call 2) is presented to the logical element, it selects one of the available appearances (A2) to handle the call. - 729 -
Figure A-1 Selected-Standard Appearances
Before the new call arrives
After the new call arrives
L
L A3 c Call 1 *
D
D
D
a Call 2 *
c Call 1 *
A2
A1
A3
A2
A1
A.1.2
Basic-Standard Appearance When calls are presented to the logical element, each available (i.e., idle) appearance is presented with the call. When the call is answered by one of the appearances (i.e., the associated connection state has transitioned to the connected state), the other appearances are cleared from the call. From that point on, the handling of the call does not have any special characteristics or behaviours. The appearances that were cleared from the call can then be used to process other call and call-related activities associated with the logical element. Figure A-2 illustrates basic-standard appearances. In this example, the logical element is L and it has three addressable basic-standard appearances (A1, A2, A3). A call is currently being handled by appearance A3. When a new call (call 2) is presented to the logical element, it presented to all available appearances (A2, A1). Appearance A2 answers the call and appearance A1 is cleared.
Figure A-2 Basic-Standard Appearances
Before the call (C2) is answered
After the call (C2) is answered
L
L A2
A3
c Call 2 *
c Call 1 *
D
D
A1
D
D
a Call 2 *
c Call 1 *
A2
a
A3
A1
A.2
Bridged Appearance A bridged appearance of a device’s logical element may be associated with other devices that have a physical element (i.e., can handle calls at another device). - 730 -
A bridged appearance is a particular implementation of a shared logical element. Note that associated in the context of appearances means a relationship between a specific call appearance of a logical element and a device. A call appearance that is associated with a device implies that the call is physically handled at the device’s physical element through this call appearance (e.g., makes use of the physical element’s auditory apparatus). These appearances can not be associated with devices that only have a logical element. When a call arrives at the logical element, bridged call appearances are simultaneously selected. Subsequent different behaviours are possible: •
Basic-Bridged (see A.2.1)
•
Exclusive-Bridged (see A.2.2)
•
Shared-Bridged (see A.2.3)
This type of appearance can be either addressable or non-addressable. Refer to Clause 10, “CSTA Device Identifier Formats”, on page 102 for information on how to reference this appearance. When the appearance is addressable, the association between the appearance and the other device is one to one but the other device may have multiple bridged appearances associated with it. Changes in this association are reflected by the capabilities exchange services (13.1 beginning on page 158). In addition, all media streams associated with calls corresponding to this appearance are only available to the physical element (of the other device that is associated with this appearance). When the appearance is non-addressable, the association between the appearance and the other device is one to one as long as a call is present at the appearance (i.e., a different device may be associated with this appearance every time a call is present). As a result, the media stream associated with the call is only available to the other device that was assigned to the particular appearance for the call. When a call activity at one appearance results in the need for another appearance (i.e., the appearance puts the call on hold and wants to allow for the initiation of another call from the logical element), the logical element will use one of the available appearance (i.e., idle) at the associated device. If an available appearance at the associated device is not present, the call will not be accepted by the logical element.
A.2.1
Basic-Bridged When calls are presented to the logical element, each available (i.e., idle) appearance is presented with the call. When the call is answered by one of the appearances (i.e., the associated connection state has transitioned to the connected state), the other appearances are cleared from the call. From that point on, the handling of the call does not have any special characteristics or behaviours. The appearances that were cleared from the call can then be used to process other call and call-related activities associated with the logical element. Figure A-3 illustrates basic-bridged appearances. In this example, the logical element is L and it has three addressable basic-bridged appearances (A1, A2, A3). When a new call (call 1) is presented to the logical element, it is presented to all available appearances (A1, A2, A3). Appearance A2 answers the call and appearances A3 and A1 are cleared. The arrows indicates that the particular bridged appearance of the logical element is associated with the corresponding device.
- 731 -
Figure A-3 Basic-Bridged Appearances
Before appearance A2answers
D1
D3
D1
D3
A3
c Call 1 * D
D
A.2.2
D2
A2
A1
a Call 1 *
L
a
A2
a
A3
A1
L
D2
After appearance A2 answers
Exclusive-Bridged When calls are presented to the logical element, each available (i.e., idle) appearance is presented with the call. When the call is answered by one of the appearances (i.e., the associated connection state has transitioned to the connected state), the other appearances are blocked from being used (i.e., the associated connection state is transitioned to the Failed state) until the connection that answered the call is cleared or the call is moved away. At which time, the connections in the Failed state are cleared. Otherwise, the handling of the call does not have any special characteristics or behaviours. Figure A-4 illustrates exclusive-bridged appearances. In this example, the logical element is L has three addressable exclusive-bridged appearances (A1, A2, A3). When a new call (call 1) is presented to the logical element, it presented to all available appearances (A1, A2, A3). Appearance A2 answers the call and appearances A1 and A3 are blocked. Figure A-4 Exclusive-Bridged Appearances
Before appearance A2 answers
A3 f
a
D3
c Call 1 *
A3
a Call 1 *
D2
A2
A2
a
L
D1
f
D3
A1
L
D2
A1
D1
After appearance A2 answers
D
D
When the connected appearance places the call on hold, all other appearances will transition to the hold state. If all appearances are in the hold state and one of appearances retrieves the call, then the appearance retrieving the call will transition to the connected state and the other appearances will transition to the blocked from use mode (i.e., the associated connection state is transitioned to the Failed - 732 -
state). Figure A-5 illustrates this behaviour of exclusive-bridged appearances (Note that this is a continuation of the illustration above). Appearance A2 places the call on hold while appearances A2 and A3 are in the blocked from use mode. Figure A-5 Exclusive-Bridged Appearances (Continuation of Figure A-4)
Before appearance A2 holds
D2
D3
A2
A3
h Call 1 *
h
c Call 1 *
f
A2
f
L
D1
h
D3
A3
A1
L
D2
A1
D1
After appearance A2 holds
D
D
A.2.3
Shared-Bridged This is the most common form of bridged appearances. When calls are presented to the logical element, each available (i.e., idle) appearance is presented with the call. When the call is answered by one of the appearances (i.e., the associated connection state has transitioned to the connected state), the other appearances enter an inactive mode (i.e., the associated connection state transitions to the queued state) until one of the following actions happen: •
They connect to the call.
•
The call is ended.
•
They are permanently cleared from the call through some feature/service.
•
The call moves away from the device and none of the appearances are connected into the call.
Figure A-6 illustrates this behaviour of shared-bridged appearances. In this example, the logical element is L and it has three addressable shared-bridged appearances (A1, A2, A3). When a new call (call 1) is presented to the logical element, it presented to all available appearances (A1, A2, A3). Appearance A2 answers the call and appearances A1 and A3 are made inactive.
- 733 -
Figure A-6 Shared-Bridged Appearances
Before appearance A2 answers
A3 q
a
D3
c Call 1 *
A3
a Call 1 *
D2
A2
A2
a
L
D1
q
D3
A1
L
D2
A1
D1
After appearance A2 answers
D
D
The significant behaviour of shared-bridged appearances is that any appearance can join and/or clear from the call at any time up to a switching function limit on the number of appearances connected on the call. As long as at least one of the appearances remains connected to the call, all of the other appearances retain the ability to join the call. The Answer Call model is used to inform the computing function of appearances joining the call (Established Events). When an appearance clears from the call (with other appearances still connected), the appearance is returned to the inactive mode (i.e., the associated connection state transitions to the queued state). The call ends when all of the appearances clear from the call (i.e., all associated connection states transition to the queued state). Figure A-7 illustrates this behaviour of shared-bridged appearances (Note that this is a continuation of the illustration above). In this case, appearance A1 adds to and clears from the call while appearance A2 remains in the call.
- 734 -
Figure A-7 Shared-Bridged Appearances (Continuation of Figure A-6)
Before appearance A1 answers
After appearance A1 clears
A3 q
q
D3
c Call 1 *
A3
c Call 1 *
D2
A2
A2
c
L
D1
q
D3
A1
D2
A1
L
q
D
D
Before appearance A1 clears
D1
D3
c Call 1 *
q
c
A3
c Call 1 *
A1
A2
q
L
D2
A3
D1
D3
A1
L
D2
A2
D1
After appearance A1 answers
D
D
When the call is moved away from an appearance or an appearance places the call on hold, the sharedbridged appearance type becomes two types: •
Independent-shared-bridged - When the call is moved away from the logical element by one of the appearances, the other appearances are unaffected, as long as one appearance remains connected in the call, otherwise all appearances are cleared from the call. As for the appearance moving the call, it will return to the inactive mode (if another appearance remains connected in the call). Figure A8 illustrates this behaviour of independent-shared-bridged appearances (Note that this is a continuation of the illustration above). In case one, appearance A2 immediately transfers the call to another device while appearance A1 remains in the call. In case two, appearance A2 immediately transfers the call to another device while all appearances A1 and A3 are in the inactive mode.
- 735 -
Figure A-8 Independent-Shared-Bridged Appearances
Case One Before appearance A2 transfers
D3
*
q
q
c
A3
c Call 1 *
A1
A2
c
L
D2
A3
D1
q Call 1 *
D3
A1
L
D2
A2
D1
After appearance A2 transfers
D
D
D
Case Two Before appearance A2 transfers
D3
A3
A3
c Call 1 *
D2
A2
A2
q
L
D1
A1
D3
q
D2
A1
L
D1
After appearance A2 transfers
*
Call 1 *
D
D
D
When one of the appearances places the call on hold and at least one other appearance is connected in the call, only the holding appearance will transition to the hold state (i.e., the other appearances are unaffected). When one of the appearances places the call on hold and the holding appearance was the only one connected in the call, all other appearances will transition to the hold state. If all appearances are in the hold state and one of appearances retrieves the call, then the appearance retrieving the call will transition to the connected state and the other appearances will transition to the inactive mode. Figure A-9 illustrates this behaviour of independent-shared-bridged appearances (Note that this is a continuation of the illustration above). In case one, appearance A2 places the call on hold while appearance A1 remains in the call. In case two, appearance A2 places the call on hold while all appearances A2 and A3 are in the inactive mode.
- 736 -
Figure A-9 Independent-Shared-Bridged Appearances (Continuation of Figure A-8)
Case One Before appearance A2 holds
D1
D3
q
h Call 1 *
q
c
A3
c Call 1 *
A1
A2
c
L
D2
A3
D3
A1
L
D2
A2
D1
After appearance A2 holds
D
D
Case Two Before appearance A2 holds
A3 h
q
D3
h Call 1 *
A3
c Call 1 *
D2
A2
A2
q
D
D
•
L
D1
h
D3
A1
D2
A1
L
D1
After appearance A2 holds
Interdependent-shared-bridged - When the call is moved away from the logical element by one of the appearances (no matter what the connection state of the other appearances in the call), all appearances are cleared from the call. Figure A-8 in Case 2 illustrates this behaviour of interdependent-shared-bridged appearances. When one of the appearances places the call on hold, all appearances will transition to the hold state. When one of appearances retrieves the call, then the appearance retrieving the call will transition to the connected state and the other appearances will transition to the inactive mode. Figure A-9 in Case 2 illustrates this behaviour of interdependent-shared-bridged appearances.
- 737 -
- 738 -
Annex B (normative)
ISDN User-User Information Element Encoding for CSTA This annex specifies one possible mechanism for sending CSTA information such as correlator data, user data, and call linkage data over an external network. This mechanism transmits CSTA information through the network in the ISDN User-User (UU) Information Element (IE) in ISDN call control and User Info messages where supported. Transmission of User-User data is not supported by all parts of the public network. Figure B-1 describes the CSTA UU IE format used for sending CSTA information. The first three bytes of the UU IE are defined in ITU-T Rec. Q.931. Note that this format supports sending a combination of different types of CSTA information (e.g., both user data and correlator data) in the same CSTA UU IE (see Functional Requirement #1). Figure B-1 CSTA User-User Information Element (UU IE) Field Format 1 byte UU IE Identifier (1 byte) Length (1 byte) Protocol Discriminator (1 byte) CSTA UU IE Format Identifier (1 byte)
Data (optional) may be sent multiple times Checksum (1 byte)
•
The UU IE Identifier field identifies the UU IE packet. Its value is 0x7E.
•
The Length field provides the total length of the UU IE packet.
•
The Protocol Discriminator signals end-to-end transparency to the public switch vendor. Its value is 0x00.
•
The CSTA UU IE Format Identifier identifies that the information element contains CSTA Information such as correlator data, user data, or call linkage data. Its value is 0x45.
•
The Data field is optional, may be sent multiple times and has the following format: Figure B-2 Data Field Format 1 byte Data Type (1 byte) Data Length (1 byte)
Content (variable length)
- 739 -
•
The Data Type sub-field specifies the type of CSTA information. The possible types are: correlator data (value is 0x80), user data (value is 0x81), and call linkage data (value is 0x82).
•
The Data Length sub-field provides the length of the Content field.
•
The Content sub-field contains the appropriate CSTA information (correlator data, user data, or call linkage data).
•
The Checksum field verifies that the packet is the CSTA UU IE packet defined in this annex.
Functional Requirements 1. Multiple Data Type entries may be sent in each UU IE. The entries may be repeated up to a maximum packet length of 128 bytes.1 2. A switching function reports its supported maximum lengths for correlator data and user data in the capabilities exchange services. 3. The possible maximum data lengths in ISDN messages are 121 bytes for user data and 32 bytes for correlator data.1 4. If a switching function does not support a data type, it is discarded. If a switching function does not support as many entries of a particular type as were received, the additional entries are discarded. 5. Length 0 (zero) of correlator data is used to signal null correlator data to the receiving switching subdomain. Current correlator data associated with the call shall be deleted. 6. Format and interpretation of the Content sub-field is a function of the computing function. 7. The Checksum byte contains the XOR checksum of all the bytes starting with the CSTA UU IE Format Identifier.
1. The maximum size of an ISDN UU IE packet may be limited based upon certain implementations (i.e., some public network implementations).
- 740 -
Annex C (normative)
Capability Bitmap Parameters Types This annex specifies the capability bitmap parameters types that are included in the Get Physical Device Information, Get Logical Device Information and Get Switching Function Capabilities services. These parameter types are summarized in the following table. Table C-1 Capability Bitmap Parameter Types Capability Bitmap Parameter Type
Description
Pg.
C.1 CapExchangeServList
Specifies the Capability Exchange services that are supported by the switching function.
742
C.2 SystemStatusServList
Specifies the System Status services that are supported by the switching function.
744
C.3 MonitoringServList
Specifies the Monitoring services that are supported by the switching function.
746
C.4 SnapshotServList
Specifies the Snapshot services that are supported by the switching function.
747
C.5 CallControlServList
Specifies the Call Control services that are supported by the switching function.
748
C.6 CallControlEvtsList
Specifies the Call Control events that are supported by the switching function.
761
C.7 CallAssociatedServList
Specifies the Call Associated services that are supported by the switching function.
769
C.8 CallAssociatedEvtsList
Specifies the Call Control events that are supported by the switching function.
771
C.9 MediaServList
Specifies the Media Attachment services that are supported by the switching function.
772
C.10 MediaEvtsList
Specifies the Media Attachment events that are supported by the switching function.
773
C.11 RouteingServList
Specifies the Routeing services that are supported by the switching function.
773
C.12 PhysDevServList
Specifies the Physical Device Feature services that are supported by the switching function.
775
C.13 PhysDevEvtsList
Specifies the Physical Device Feature events that are supported by the switching function.
780
C.14 LogicalServList
Specifies the Logical Device Feature services that are supported by the switching function.
782
C.15 LogicalEvtsList
Specifies the Logical Device Feature events that are supported by the switching function.
786
C.16 DeviceMaintEvtsList
Specifies the Device Maintenance events that are supported by the switching function.
789
C.17 IOServicesServList
Specifies the I/O services that are supported by the switching function.
789
C.18 DataCollectionServList
Specifies the Data Collection services that are supported by the switching function.
792
C.19 VoiceServList
Specifies the Voice services that are supported by the switching function.
793
C.20 VoiceEvtsList
Specifies the Voice events that are supported by the switching function.
796
C.21 CDRServList
Specifies the CDR services that are supported by the switching function.
800
C.22 LocationServicesServList
Specifies the Location services that are supported by the switching function.
802
C.23 VendorSpecificServList
Specifies the Vendor Specific services that are supported by the switching function.
804
- 741 -
Table C-1 Capability Bitmap Parameter Types (continued) Capability Bitmap Parameter Type C.24 VendorSpecificEvtsList
Description
Pg.
Specifies the Vendor Specific events that are supported by the switching function.
804
The capability bitmap parameter types specified in this clause consists of sets of entries. A unique entry is defined for each service/event. The switching function provides the appropriate entry for a given service/ event if it supports that service/event. It shall not provide an entry for a service/event that is not supported. An entry is a bitmap where each bit represents an option that the switching function either supports or does not support. The options that are specified in the capability bitmaps include: •
initial connection states supported for a service request. If the operational model for a service specifies more than one possible initial connection state, then the switching function shall indicate which initial connection states it supports for the service request be setting to TRUE the capability bit corresponding to the supported connections states.
•
optional parameters. The switching function shall indicate the optional parameters that it supports by setting to TRUE the capability bit corresponding to the supported optional parameter. Note that some optional parameters in services/events are not included in the service/event specific bitmaps since they are specified at a switching function level (via the Get Switching Function Capabilities service). An example of a “global” optional parameter is security type information (timestamp, message sequence numbers, securityInfo).
•
conditional parameters. In most cases conditional parameters are not included in the capability bitmaps since, by their definition, the switching function is required to support the parameter under the conditions specified in the parameter description (e.g., support of a specific feature). In some cases where the conditions allow the parameter to be optionally supported then the parameter is included in the capability bitmaps.
•
parameter values supported. The switching function shall indicate the set of values that are supported in an enumerated list or in a bitmap list by setting to TRUE the capability bit corresponding to the value supported.
•
•
for optional parameters that are represented as a bitmap parameter type, there is a bit in the capability list to indicate if the parameter itself is present, and a bit in the capability list for each possible bit in the parameter.
•
for optional parameters that are represented as an enumerated parameter type, there will be a bit in the capability list for each possible value in the parameter (a separate bit to indicate if the parameter itself is present is not necessary).
miscellaneous characteristics. The switching function shall indicate the miscellaneous characteristics that are supported by setting to TRUE the capability bit corresponding to the characteristic supported.
Note that, in the following lists, items that apply to the service acknowledgement are indicated by the text “in the acknowledgement”, otherwise the item applies to the service request.
C.1
CapExchangeServList The CapExchangeServList parameter type specifies the capability exchange services supported by the switching function. The information in the CapExchangeServList represents the optional parameters that are supported by the switching function.
C.1.1
Get CSTA Features Optional parameters, values, and choices supported: •
privateData - 742 -
•
C.1.2
privateData in the acknowledgement
Get Logical Device Information Optional parameters, values, and choices supported:
C.1.3
•
privateData
•
namedDeviceTypes in the acknowledgement
•
shortFormDeviceID in the acknowledgement
•
miscMonitorCaps in the acknowledgement
•
maxCallbacks in the acknowledgement
•
maxAutoAnswerRings in the acknowledgement
•
maxActiveCalls in the acknowledgement
•
maxHeldCalls in the acknowledgement
•
maxFwdSettings in the acknowledgement
•
maxDevicesInConf in the acknowledgement
•
transAndConfSetup parameter, transAndConfSetup (consultationCall, alternateCall, twoCallsHold, twoCallsConnected) in the acknowledgement
•
mediaClassSupport in the acknowledgement
•
connectionRateList in the acknowledgement
•
delayToleranceList in the acknowledgement
•
numberofChannels in the acknowledgement
•
maxChannelBind in the acknowledgement
•
privateData in the acknowledgement
Get Physical Device Information Optional parameters, values, and choices supported: •
privateData
•
namedDeviceTypes in the acknowledgement
•
otherLogicalDeviceList in the acknowledgement
•
deviceModelName in the acknowledgement
•
maxDisplays in the acknowledgement
•
maxButtons in the acknowledgement
•
maxLamps in the acknowledgement
•
maxRingPatterns in the acknowledgement
•
privateData in the acknowledgement
C.1.4
Get Switching Function Capabilities
C.1.5
Get Switching Function Devices
Note that there are no capability bits associated with this service. Optional parameters, values, and choices supported: •
requestedDeviceID
- 743 -
holdCallMakeCall,
C.1.6
•
requestedDeviceCategory (aCD, aCDGroup, huntGroup, pickGroup, otherGroup, networkInterface, park, routeingDevice, station, voiceUnit, other)
•
privateData
•
privateData in the acknowledgement
Switching Function Devices Optional parameters, values, and choices supported:
C.2
•
segmentID
•
deviceListDeviceCategory
•
deviceListNamedDeviceTypes
•
deviceListDeviceAttributes
•
deviceListDeviceModelName
•
deviceListDeviceNIDGroup
•
privateData
SystemStatusServList The SystemStatusServList parameter type specifies the system status services supported by the switching function.
C.2.1
Change System Status Filter Optional parameters, values, and choices supported:
C.2.2
•
requestedStatusFilter (initializing, enabled, normal, messagesLost, disabled, partiallyDisabled, overloadImminent, overloadReached, overloadRelieved)
•
privateData
•
privateData in the acknowledgement
System Register Optional parameters, values, and choices supported:
C.2.3
•
requestTypes (systemStatus, requestSystemStatus, sfCapabilitiesChanged, sfDevicesChanged)
•
requestedStatusFilter (initializing, enabled, normal, messagesLost, disabled, partiallyDisabled, overloadImminent, overloadReached, overloadRelieved)
•
privateData
•
privateData in the acknowledgement
System Status Register Abort Optional parameters, values, and choices supported:
C.2.4
•
privateData
•
privateData in the acknowledgement
System Status Register Cancel Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
- 744 -
C.2.5
Request System Status Optional parameters, values, and choices supported: •
privateData in the service request
•
systemStatus (initializing, enabled, normal, messagesLost, disabled, partiallyDisabled, overloadImminent, overloadReached, overloadRelieved) in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics:
C.2.6
•
Switching Functions supports sending the service request
•
Switching Functions supports receiving the service request
System Status Optional parameters, values, and choices supported: •
systemStatus (initializing, enabled, normal, messagesLost, disabled, overloadImminent, overloadReached, overloadRelieved) in the service request
•
privateData
•
privateData in the acknowledgement
partiallyDisabled,
Miscellaneous Characteristics:
C.2.7
•
Switching Functions supports sending the service request
•
Switching Functions supports receiving the service request
Switching Function Capabilities Changed Optional parameters, values, and choices supported:
C.2.8
•
privateData
•
privateData in the acknowledgement
Switching Function Devices Changed Optional parameters, values, and choices supported:
C.2.9
•
privateData
•
privateData in the acknowledgement
Get Registrations Optional parameters, values, and choices supported: •
requestedRegTypes
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Does the switching function use the Registration Info service to report the requested information?
C.2.10 Registration Info Optional parameters, values, and choices supported: •
segmentID
•
privateData - 745 -
C.3
MonitoringServList The MonitoringServList parameter type specifies the monitoring services that are supported by the switching function.
C.3.1
Change Monitor Filter Optional parameters, values, and choices supported:
C.3.2
•
privateData
•
privateData in the acknowledgement
Monitor Start Optional parameters, values, and choices supported: •
monitorObject (call, device)
•
requestedMonitorFilter
•
monitorType (callType, deviceType)
•
requestedMonitorMediaClass parameter, requestedMonitorMediaClass (audio, data, image, voice)
•
monitorExistingCalls in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics:
C.3.3
•
CallIDOnly - Does the switching function accept or support the CallID only format of the Connection ID for this service?
•
Switching function default for monitor-type is device-type (if FALSE then it is call-type).
•
Does the switching function accept a Monitor Start service request on a device that is out of service?
Monitor Stop Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics:
C.3.4
•
Does the switching function generate this service request?
•
Does the switching function support receiving this service request?
Get Monitors Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
C.3.5
Does the switching function use the Monitor Info service to report the requested information?
Monitor Info Optional parameters, values, and choices supported: •
segmentID - 746 -
•
C.4
privateData
SnapshotServList The SnapshotServList parameter type specifies the snapshot services supported by the switching function.
C.4.1
Snapshot Call Optional parameters, values, and choices supported: •
privateData
•
localConnectionState in the acknowledgement
•
mediaServiceInformationList in the acknowledgement •
mediaServiceVersion
•
mediaServiceInstance
•
mediaStreamID
•
connectionInformation
•
mediaCallCharacteristics in the acknowledgement
•
callCharacteristics in the acknowledgement
•
callingDevice in the acknowledgement
•
calledDevice in the acknowledgement
•
privateData in the acknowledgement
•
subjectOfCall in the acknowledgement
•
messageInfo in the acknowledgement
•
languagePreferences in the acknowledgement
•
deviceHistory in the acknowledgement
•
locationInfoList in the acknowledgement
Miscellaneous Characteristics:
C.4.2
•
CallIDOnly - Does the switching function accept or support the CallID only format of the Connection ID for this service?
•
Does the switching function use the Snapshot CallData service to report the requested information?
Snapshot Device Optional parameters, values, and choices supported: •
privateData
•
localCallState (compoundCallState, simpleCallState, unknown) in the acknowledgement
•
mediaServiceInformationList in the acknowledgement •
mediaServiceVersion
•
mediaServiceInstance
•
mediaStreamID
•
connectionInformation
•
mediaCallCharacteristics in the acknowledgement
•
callLinkageData in the acknowledgement - 747 -
•
privateData in the acknowledgement
•
endpointDevice in the acknowledgement
Miscellaneous Characteristics: •
C.4.3
Does the switching function use the Snapshot DeviceData service to report the requested information?
Snapshot CallData Optional parameters, values, and choices supported:
C.4.4
•
segmentID
•
localConnectionState
•
mediaServiceInformationList •
mediaServiceVersion
•
mediaServiceInstance
•
mediaStreamID
•
connectionInformation
•
locationInfoList
•
callLinkageData
Snapshot DeviceData Optional parameters, values, and choices supported:
C.5
•
segmentID
•
localCallState (compoundCallState, simpleCallState, unknown)
•
mediaServiceInformationList •
mediaServiceVersion
•
mediaServiceInstance
•
mediaStreamID
•
connectionInformation
•
mediaCallCharacteristics
•
privateData
•
endpointDevice
CallControlServList The CallControlServList parameter specifies the call control services that are supported by the switching function.
C.5.1
Accept Call Optional parameters, values, and choices supported: •
correlatorData
•
userData
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: - 748 -
C.5.2
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
Alternate Call Initial states heldCall: •
Alerting
•
Hold
•
Queued
Optional parameters, values, and choices supported: •
connectionReservation
•
consultOptions (consultOnly, transferOnly, conferenceOnly, unrestricted)
•
privateData
•
privateData in the Acknowledgement
Miscellaneous Characteristics:
C.5.3
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Supports Offered Mode of Alerting?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
Answer Call Initial states callToBeAnswered: •
Alerting
•
Initiated
•
Queued
Optional parameters, values, and choices supported: •
correlatorData
•
userData
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics:
C.5.4
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Supports Offered Mode of Alerting?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
Call Back Call-Related Initial states target: •
Alerting
•
Fail
•
Null - 749 -
•
Queued
Optional parameters, values, and choices supported: •
callCharacteristics
•
privateData
•
targetDevice in the acknowledgement
•
privateData in the acknowledgement
•
subjectOfCall in the request
•
languagePreferences in the request
Miscellaneous Characteristics:
C.5.5
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Do additional Call Back Call-Related services for the same calling and called devices result in a negative acknowledgement? (if FALSE, then it is positively acknowledged).
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
Call Back Message Call-Related Initial states target: •
Alerting
•
Fail
•
Null
•
Queued
Optional parameters, values, and choices supported: •
privateData
•
targetDevice in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics:
C.5.6
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Do additional Call Back Message Call-Related services for the same calling and called devices result in a negative acknowledgement? (if FALSE, then it is positively acknowledged).
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
Camp On Call Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE]) - 750 -
C.5.7
Clear Call Initial states callToBeCleared: •
Alerting
•
Connected
•
Fail
•
Queued
•
Initiated
•
Hold
Optional parameters, values, and choices supported: •
userData
•
privateData
•
privateData in the acknowledgement
•
reason in the request
Miscellaneous Characteristics:
C.5.8
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
CallIDOnly - Does the switching function accept or support the CallID only format of the connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
Clear Connection Initial states callToBeCleared: •
Alerting
•
Connected
•
Fail
•
Queued
•
Hold
•
Initiated
Optional parameters, values, and choices supported: •
correlatorData
•
userData
•
privateData
•
privateData in the acknowledgement
•
reason in the request
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
- 751 -
C.5.9
Conference Call Initial states activeCall: •
Connected
•
Hold
Initial states heldCall: •
Connected
•
Hold
Optional parameters, values, and choices supported: •
privateData
•
connections parameter in the acknowledgement •
endpointDeviceID
•
resultingConnectionInformation parameter
•
conferenceCallInfo parameter in the acknowledgement
•
callLinkageDataList in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Is the resulting conference call protected against being cleared if the conferencing device leaves the call?
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.10 Consultation Call Optional parameters, values, and choices supported: •
connectionReservation
•
accountCode
•
authCode
•
correlatorData
•
userData
•
callCharacteristics, callCharacteristics (acdCall, priorityCall, maintenanceCall, directAgent, assistCall, voiceUnitCall, privateCall, personalCall, sensitiveCall, confidentialCall)
•
mediaCallCharacteristics
•
callingConnectionInfo parameter •
flowDirection (transmit, receive, transmitAndReceive, none)
•
numberOfChannels
•
consultOptions (consultOnly, transferOnly, conferenceOnly, Unrestricted)
•
privateData
•
initiatedCallInfo in the acknowledgement
•
callLinkageData in the acknowledgement - 752 -
•
privateData in the acknowledgement
•
subjectOfCall in the request
•
languagePreferences in the request
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
MultiStage- Does the switching function support multistage dialling with this service?
•
Does the switching function support adjustment of the media characteristics?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.11 Deflect Call Initial states callToBeDeflected: •
Alerting
•
Connected
•
Failed
•
Hold
•
Queued
Optional parameters, values, and choices supported: •
correlatorData
•
userData
•
privateData
•
privateData in the acknowledgement
•
subjectOfCall in the request
•
languagePreferences in the request
•
reason in the request
•
callCharacteristics in the request
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
•
Multiple Destination Devices? Does the switching function support multiple DeviceIDs in the newDestination parameter?
C.5.12 Dial Digits Optional parameters, values, and choices supported: •
correlatorData
•
privateData
•
privateData in the acknowledgement
- 753 -
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.13 Directed Pickup Call Initial states callToBePickedUp: •
Alerting
•
Connected
•
Hold
•
Queued
Optional parameters, values, and choices supported: •
correlatorData
•
userData
•
privateData
•
pickedCall in the acknowledgement
•
pickedCallInfo in the acknowledgement
•
callLinkageData in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Supports Offered Mode of Alerting?
•
Prompting - Does the switching function support prompting for the newDestinationDevice?
•
Prompting Mode - Is prompting part of the execution of the service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.14 Group Pickup Call Initial states for the connection that is picked: •
Alerting
•
Connected
•
Hold
•
Queued
Optional parameters, values, and choices supported: •
pickGroup
•
correlatorData
•
userData
•
privateData
•
pickedCall in the acknowledgement
- 754 -
•
pickedCallInfo in the acknowledgement
•
callLinkageData in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Prompting - Does the switching function support prompting for the newDestinationDevice?
•
Prompting Mode - Is prompting part of the execution of the service?
•
Supports Offered Mode of Alerting?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.15 Hold Call Optional parameters, values, and choices supported: •
connectionReservation
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.16 Intrude Call Optional parameters, values, and choices supported: •
participationType (active, silent, none)
•
userData
•
privateData
•
conferencedCallInfo in the acknowledgement
•
callLinkageDataList in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Conference - Does the switching function support conferencing the intruder with the existing call?
•
Alternate - Does the switching function support putting the existing call on hold and establishing a call with the intruder?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.17 Join Call Optional parameters, values, and choices supported: •
autoOriginate (prompt, doNotPrompt)
•
participationType (active, silent, none)
•
accountCode
•
authCode - 755 -
•
correlatorData
•
userData
•
privateData
•
conferencedCall in the acknowledgement
•
conferencedCallInfo in the acknowledgement
•
callLinkageDataList in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Prompting - Does the switching function support prompting for the joiningDevice?
•
Prompting Mode - Is prompting part of the execution of the service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.18 Make Call Initial states for the calling device connection: •
Initiated
•
Null
Optional parameters, values, and choices supported: •
accountCode
•
authCode
•
autoOriginate (prompt, doNotPrompt)
•
correlatorData
•
userData
•
callCharacteristics parameter, callCharacteristics (acdCall, priorityCall, maintenanceCall, directAgent, assistCall, voiceUnitCall, privateCall, personalCall, sensitiveCall, confidentialCall)
•
mediaCallCharacteristics
•
callingConnectionInfo
•
privateData
•
initiatedCallInfo in the acknowledgement
•
callLinkageData in the acknowledgement
•
privateData in the acknowledgement
•
subjectOfCall in the request
•
languagePreferences in the request
•
reason in the request
Miscellaneous Characteristics: •
MultiStage- Does the switching function support multistage dialling with this service?
•
Prompting - Does the switching function support prompting for the callingDevice?
•
Prompting Mode - Is prompting part of the execution of the service? - 756 -
•
Offhook - Does the switching function support the performing of a Make Call while the callingDevice is off-hook?
•
Can the switching function adjust the media characteristics of the call?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.19 Make Connection Initial states for the initiating device connection: •
Null
Optional parameters, values, and choices supported: •
accountCode
•
authCode
•
autoOriginate (prompt, doNotPrompt)
•
correlatorData
•
callCharacteristics parameter, callCharacteristics (acdCall, priorityCall, maintenanceCall, directAgent, assistCall, voiceUnitCall, privateCall, personalCall, sensitiveCall, confidentialCall)
•
mediaCallCharacteristics
•
connectionInfo
•
subjectOfCall
•
languagePreferences
•
reason
•
maxDevices
•
startTime
•
duration
•
securityData
•
privateData
•
mediaCallCharacteristics in the acknowledgement
•
initiatedCallInfo in the acknowledgement
•
callLinkageData in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Prompting - Does the switching function support prompting for the initiatingDevice?
•
Prompting Mode - Is prompting part of the execution of the service?
•
Can the switching function adjust the media characteristics of the call?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.20 Make Predictive Call Optional parameters, values, and choices supported: •
signallingDetection parameter •
signallingCondition (callDelivered, CallEstablished)
- 757 -
• •
signallingConditionsAction (destinationDetection, remainConnected)
destinationDetection parameter •
destinationCondition (humanVoice, answeringMachine, facimileMachine)
•
detectionAction (clearCallConnection, remainConnected)
•
defaultAction (clearCalledConnection, remainConnected)
•
accountCode
•
authCode
•
autoOriginate (prompt, doNotPrompt)
•
alertTime
•
correlatorData
•
callCharacteristics, callCharacteristics (acdCall, priorityCall, maintenanceCall, directAgent, assistCall, voiceUnitCall, privateCall, personalCall, sensitiveCall, confidentialCall)
•
userData
•
privateData
•
initiatedCallInfo in the acknowledgement
•
callLinkageData in the acknowledgement
•
privateData in the acknowledgement
•
subjectOfCall in the request
•
languagePreferences in the request
Miscellaneous Characteristics: •
Prompting - Does the switching function support prompting for the callingDevice?
•
Prompting Mode - Is prompting part of the execution of the service?
•
Does the switching function generate a Service Initiated event for the calling device prior to any call activity at the calling device (i.e. reserve the calling device)?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.21 Park Call Initial states callToBeParked: •
Connected
•
Hold
Optional parameters, values, and choices supported: •
correlatorData
•
privateData
•
parkedTo in the acknowledgement
•
callLinkageData in the acknowledgement
•
privateData in the acknowledgement
•
subjectOfCall in the request
•
languagePreferences in the request
Miscellaneous Characteristics: - 758 -
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.22 Reconnect Call Initial states activeCall: •
Alerting
•
Connected
•
Fail
•
Initiated
•
Queued
Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.23 Retrieve Call Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.24 Send Message Service Optional parameters, values, and choices supported: •
accountCode
•
authCode
•
correlatorData
•
callCharacteristics
•
mediaCallCharacteristics
•
subjectOfCall
•
languagePreferences
•
privateData
•
listOfCallLinkageData in the acknowledgement
•
privateData in the acknowledgement
- 759 -
C.5.25 Single Step Conference Call Optional parameters, values, and choices supported: •
participationType (active, silent, none)
•
accountCode
•
authCode
•
correlatorData
•
userData
•
privateData
•
conferencedCallInfo in the acknowledgement
•
callLinkageDataList in the acknowledgement
•
privateData in the acknowledgement
•
subjectOfCall in the request
•
languagePreferences in the request
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.26 Single Step Transfer Call Initial states activeCall: •
Alerting
•
Connected
•
Failed
•
Hold
•
Queued
Optional parameters, values, and choices supported: •
accountCode
•
authCode
•
correlatorData
•
userData
•
privateData
•
connections parameter in the acknowledgement •
endpointDeviceID
•
resultingConnectionInformation
•
transferredCallInfo in the acknowledgement
•
callLinkageDataList in the acknowledgement
•
privateData in the acknowledgement
•
subjectOfCall in the request - 760 -
•
languagePreferences in the request
•
reason in the request
•
callCharacteristics in the request
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
MultipleDevices - Does the switching function support transferring multiple devices or a conference call?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.5.27 Transfer Call Initial states activeCall: •
Connected
•
Hold
Initial states heldCall: •
Connected
•
Hold
Optional parameters, values, and choices supported: •
privateData
•
connections parameter in the acknowledgement •
endpointDeviceID
•
resultingConnectionInformation
•
transferredCallInfo in the acknowledgement
•
callLinkageDataList in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics:
C.6
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
MultipleDevices - Does the switching function support transferring multiple devices or a conference call?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
CallControlEvtsList The CallControlEvtsList parameter type specifies the call control events that are supported by the switching function. The following list describes some general requirements for the capability options related to the Call Control events. 1. The localConnectionInfo parameter is not specified in the capability bit maps for the events. The computing function can use the Get Switching Function Capabilities service to determine if devicetype monitoring is supported.
- 761 -
2. The conditional parameters correlatorData and callLinkageData are not specified in the capability bit maps for the events since it is required if the switching function supports correlator data. The computing function can use the Get Switching Function Capabilities service to determine if the correlator data and the call linkage features are supported. Note that for the events where the correlatorData and callLinkageData have been defined as optional, the capability bit is specified.
C.6.1
Bridged Optional parameters, values, and choices supported:
C.6.2
•
correlatorData
•
userData
•
servicesPermitted
•
mediaCallCharacteristics
•
callCharacteristics
•
bridgedConnectionInfo
•
callLinkageData
•
privateData
•
languagePreferences
•
locationInfoList in service request
Call Cleared Optional parameters, values, and choices supported: •
correlatorData
•
userData
•
mediaCallCharacteristics
•
callCharacteristics
•
callLinkageData
•
privateData
•
languagePreferences
•
locationInfoList
Miscellaneous Characteristics: •
C.6.3
CallIDOnly - Does the switching function accept or support the CallID only format of the Connection ID for this event?
Conferenced Optional parameters, values, and choices supported: •
conferenceConnections (endpointDeviceID, resultingConnectionInformation)
•
userData
•
servicesPermitted
•
mediaCallCharacteristics
•
callCharacteristics
•
privateData - 762 -
C.6.4
•
languagePreferences
•
deviceHistory
•
locationInfoList
Connection Cleared Optional parameters, values, and choices supported:
C.6.5
•
correlatorData
•
userData
•
chargingInfo •
numberUnits (numberOfChargingUnits, typeOfUnits, numberOfCurrencyUnits)
•
typeOfChargingInformation (subTotal, total)
•
chargingMultiplier (.001, .01, .1, 1, 10, 100, 1000)
•
servicesPermitted
•
mediaCallCharacteristics
•
callCharacteristics
•
droppedConnectionInfo
•
callLinkageData
•
privateData
•
languagePreferences
•
deviceHistory
•
locationInfoList
Delivered Optional parameters, values, and choices supported: •
originatingNIDConnection
•
userData
•
servicesPermitted
•
networkCallingDevice
•
networkCalledDevice
•
mediaCallCharacteristics
•
callCharacteristics
•
connectionInfo
•
privateData
•
subjectOfCall
•
messageInfo
•
languagePreferences
•
deviceHistory
•
locationInfoList
- 763 -
C.6.6
Digits Dialed Optional parameters, values, and choices supported:
C.6.7
•
servicesPermitted
•
networkCallingDevice
•
networkCalledDevice
•
diallingConnectionInfo
•
callCharacteristics
•
privateData
•
languagePreferences
•
locationInfoList
Diverted Optional parameters, values, and choices supported:
C.6.8
•
callingDevice
•
calledDevice
•
userData
•
servicesPermitted
•
mediaCallCharacteristics
•
callCharacteristics
•
connectionInfo
•
networkCallingDevice
•
networkCalledDevice
•
privateData
•
Does the switching function send the Diverted Event to all devices in a call (for Device-type monitor) and to a Call-type monitor?
•
subjectOfCall
•
messageInfo
•
languagePreferences
•
deviceHistory
•
locationInfoList
Established Optional parameters, values, and choices supported: •
originatingNIDConnection
•
userData
•
servicesPermitted
•
networkCallingDevice
•
networkCalledDevice
•
mediaCallCharacteristics - 764 -
C.6.9
•
callCharacteristics
•
establishedConnectionInfo
•
privateData
•
subjectOfCall
•
messageInfo
•
languagePreferences
•
deviceHistory
•
locationInfoList
Failed Optional parameters, values, and choices supported: •
originatingNIDConnection
•
userData
•
servicesPermitted
•
networkCallingDevice
•
networkCalledDevice
•
mediaCallCharacteristics
•
callCharacteristics
•
failedConnectionInfo
•
privateData
•
subjectOfCall
•
messageInfo
•
languagePreferences
•
deviceHistory
•
locationInfoList
Miscellaneous Characteristics: •
CallIDOnly - Does the switching function support the CallID only format of the Connection ID for this event?
C.6.10 Held Optional parameters, values, and choices supported: •
correlatorData
•
servicesPermitted
•
mediaCallCharacteristics
•
callCharacteristics
•
heldConnectionInfo
•
callLinkageData
•
privateData
•
languagePreferences - 765 -
•
locationInfoList
C.6.11 Network Capabilities Changed Optional parameters, values, and choices supported: •
progressLocation (user, privateServingLocal, publicServingLocal, transitNetwork, publicServingRemote, privateServingRemote, local, international, networkBeyondInterworkingPoint, other)
•
progressDescription (iSDN, qSIG, other)
•
userData
•
networkType (iSDNPublic, nonISDNPublic, iSDNPrivate, nonISDNPrivate, other)
•
eventsProvided parameter, eventsProvided (bridged, callCleared, conferenced, connectionCleared, delivered, digitsDialled, diverted, established, failed, held, networkCapabilitiesChanged, networkReached, offered, originated, queued, retrieved, serviceInitiated, transferred)
•
servicesPermitted
•
mediaCallCharacteristics
•
callCharacteristics
•
outboundConnectionInfo
•
privateData
•
languagePreferences
•
locationInfoList
C.6.12 Network Reached Optional parameters, values, and choices supported: •
originatingNIDConnection
•
userData
•
networkType (iSDNPublic, nonISDNPublic, iSDNPrivate, nonISDNPrivate, other)
•
eventsProvided parameter, eventsProvided (bridged, callCleared, conferenced, connectionCleared, delivered, digitsDialled, diverted, established, failed, held, networkCapabilitiesChanged, networkReached, offered, originated, queued, retrieved, serviceInitiated, transferred)
•
servicesPermitted
•
mediaCallCharacteristics
•
callCharacteristics
•
outboundConnectionInfo
•
networkCallingDevice
•
networkCalledDevice
•
privateData
•
languagePreferences
•
deviceHistory
•
locationInfoList
C.6.13 Offered Optional parameters, values, and choices supported: - 766 -
•
originatingNIDConnection
•
userData
•
servicesPermitted
•
networkCallingDevice
•
networkCalledDevice
•
mediaCallCharacteristics
•
callCharacteristics
•
offeredConnectionInfo
•
privateData
•
subjectOfCall
•
messageInfo
•
languagePreferences
•
deviceHistory
•
locationInfoList
C.6.14 Originated Optional parameters, values, and choices supported: •
originatingDevice
•
servicesPermitted
•
networkCallingDevice
•
networkCalledDevice
•
mediaCallCharacteristics
•
callCharacteristics
•
originatedConnectionInfo
•
privateData
•
subjectOfCall
•
messageInfo
•
languagePreferences
•
locationInfoList
C.6.15 Queued Optional parameters, values, and choices supported: •
numberQueued
•
callsInFront
•
userData
•
servicesPermitted
•
networkCallingDevice
•
networkCalledDevice
•
mediaCallCharacteristics - 767 -
•
callCharacteristics
•
queuedConnectionInfo
•
privateData
•
subjectOfCall
•
messageInfo
•
languagePreferences
•
deviceHistory
•
locationInfoList
C.6.16 Retrieved Optional parameters, values, and choices supported: •
correlatorData
•
servicesPermitted
•
mediaCallCharacteristics
•
callCharacteristics
•
retrievedConnectionInfo
•
callLinkageData
•
privateData
•
languagePreferences
•
locationInfoList
C.6.17 Service Initiated Optional parameters, values, and choices supported: •
servicesPermitted
•
mediaCallCharacteristics
•
callCharacteristics
•
initiatedConnectionInfo
•
networkCallingDevice
•
networkCalledDevice
•
privateData
•
subjectOfCall
•
messageInfo
•
languagePreferences
•
calledDevice
•
locationInfoList
C.6.18 Transferred Optional parameters, values, and choices supported: •
transferredConnections (endpointDeviceID, resultingConnectionInformation)
•
userData - 768 -
•
C.7
chargingInfo •
numberUnits (numberOfChargingUnits, typeOfUnits, numberOfCurrencyUnits)
•
typeOfChargingInformation (subTotal, total)
•
chargingMultiplier (.001, .01, .1, 1, 10, 100, 1000)
•
servicesPermitted
•
mediaCallCharacteristics
•
callCharacteristics
•
connectionInfo
•
privateData
•
languagePreferences
•
deviceHistory
•
locationInfoList
CallAssociatedServList The CallAssociatedServList parameter type specifies the call associated services that are supported by the switching function.
C.7.1
Associate Data Optional parameters, values, and choices supported: •
accountCode
•
authCode
•
correlatorData
•
callQualifyingData
•
privateData
•
privateData in the acknowledgement
•
callCharacteristics in the request
•
subjectOfCall in the request
•
languagePreferences in the request
•
deviceInfo in the request
Miscellaneous Characteristics:
C.7.2
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Does the switching function reject Associate Data service requests (for accountCode or callQualifyingData) that contain a connectionID that no longer exists?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
Cancel Telephony Tone Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
- 769 -
Miscellaneous Characteristics: •
C.7.3
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
Change Connection Information Optional parameters, values, and choices supported:
C.7.4
•
privateData
•
privateData in the acknowledgement
Generate Digits Optional parameters, values, and choices supported: •
digitMode (rotaryPulse, dTMF)
•
toneDuration
•
pulseRate
•
pauseDuration
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics:
C.7.5
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Does the switching function support the DTMF tones “A, B, C, D”?
•
Does the switching function support the pause tone character of “;”?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
Generate Telephony Tones Optional parameters, values, and choices supported: •
toneToSend (beep, billing, busy, carrier, confirmation, dial, faxCNG, hold, howler, intrusion, modemCNG, park, recordWarning, reorder, ringback, silence, sitVC, sitIC, sitRO, sitNC, sf0 through sf100)
•
toneDuration
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics:
C.7.6
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
Send User Information Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics:
- 770 -
C.8
•
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
CallAssociatedEvtsList The CallAssociatedEvtsList parameter type specifies the call associated events that are supported by the switching function.
C.8.1
Call Information Optional parameters, values, and choices supported: •
callingDevice
•
accountInfo
•
authorisationCode
•
correlatorData
•
servicesPermitted
•
userData
•
callQualifyingData
•
connectionInfo
•
callLinkageData
•
privateData
•
callCharacteristics
•
subjectOfCall
•
languagePreferences
•
deviceInfo
Miscellaneous Characteristics: •
C.8.2
Does the switching function generate Call Information events (for accountCode or callQualifyingData) that contain a connectionID that no longer exists?
Charging Optional parameters, values, and choices supported:
C.8.3
•
numberUnits (numberOfChargingUnits, typeOfUnits, numberOfCurrencyUnits)
•
typeOfChargingInformation (subTotal, total)
•
chargingMultiplier (.001, .01, .1, 1, 10, 100, 1000)
•
privateData
Digits Generated Optional parameters, values, and choices supported: •
digitDurationList
•
pauseDurationList
•
connectionInfo
•
privateData
- 771 -
C.8.4
Telephony Tones Generated Optional parameters, values, and choices supported:
C.8.5
•
toneGenerated (beep, billing, busy, carrier, confirmation, dial, faxCNG, hold, howler, intrusion, modemCNG, park, recordWarning, reorder, ringback, silence, sitVC, sitIC, sitRO, sitNC, sf0 through sf100, other, unknown)
•
toneFrequency
•
toneDuration
•
pauseDuration
•
connectionInfo
•
privateData
Service Completion Failure Optional parameters, values, and choices supported:
C.9
•
primaryCallConnectionInfo
•
secondaryCall parameter, secondaryCallConnectionInfo
•
otherDevicesPrimaryCallList parameter, otherDevicesPrimaryCallListConnectionInfo
•
otherDevicesSecondaryCallList parameter, otherDevicesSecondaryCallListConnectionInfo
•
mediaCallCharacteristics
•
privateData
MediaServList The MediaServList parameter type specifies the media attachment services that are supported by the switching function.
C.9.1
Attach Media Service Optional parameters, values, and choices supported: •
mediaServiceVersion
•
mediaServiceInstanceID
•
connectionMode (consultationConference, consultationConferenceHold, deflect, directedPickup, join, singleStepConference, singleStepConferenceHold, singleStepTransfer, transfer, direct)
•
requestedConnectionState
•
privateData
•
mediaServiceInstanceID in the acknowledgement
•
mediaConnectionInfo in the acknowledgement
•
callLinkageData in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
- 772 -
C.9.2
Detach Media Service Initial States connection •
Alerting
•
Connected
•
Fail
•
Hold
•
Queued
Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
DeviceIDOnly - Does the switching function accept or support the DeviceID only format of the Connection ID for this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.10 MediaEvtsList The MediaEvtsList parameter type specifies the media attachment services that are supported by the switching function.
C.10.1 Media Attached Optional parameters, values, and choices supported: •
mediaServiceVersion
•
mediaServiceInstanceID
•
mediaStreamID
•
mediaCallCharacteristics
•
callCharacteristics
•
mediaConnectionInfo
•
privateData
C.10.2 Media Detached Optional parameters, values, and choices supported:
C.11
•
mediaServiceVersion
•
mediaServiceInstanceID
•
mediaStreamID
•
mediaCallCharacteristics
•
callCharacteristics
•
mediaConnectionInfo
•
privateData
RouteingServList The RouteingServList parameter type specifies the routeing services which the switching function might request from the computing function or that the switching function supports from the computing function. - 773 -
C.11.1 Route Register Optional parameters, values, and choices supported: •
routeingDevice
•
requestedMonitorMediaClass parameter, requestedMonitorMediaClass (audio, data, image, voice)
•
privateData
•
actualRouteingMediaClass in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
AllrouteingDevices - Does the switching function support the ability to register for all routeing devices within the switching function?
C.11.2 Route Register Abort Optional parameters, values, and choices supported: •
privateData
C.11.3 Route Register Cancel Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.11.4 Re-Route Optional parameters, values, and choices supported: •
replyTimeout
•
correlatorData
•
privateData
C.11.5 Route End Optional parameters, values, and choices supported: •
errorValue
•
correlatorData
•
privateData
Miscellaneous Characteristics: •
Switching function supports sending this service request to the computing function?
•
Switching function supports receiving this service request from the computing function?
C.11.6 Route Reject Optional parameters, values, and choices supported: •
rejectCause (busyOverflow, unknownOverflow)
•
correlatorData
•
privateData
queueTimeOverflow,
- 774 -
capacityOverflow,
calendarOverflow,
C.11.7 Route Request Optional parameters, values, and choices supported: •
callingDevice
•
routeingDevice
•
routeSelAlgorithm (aCD, emergency, leastCost, normal, userDefined)
•
priority
•
replyTimeout
•
correlatorData
•
mediaCallCharacteristics
•
callCharacteristics
•
routedCallInfo
•
privateData
•
subjectOfCall
•
messageInfo
•
languagePreferences
•
deviceHistory
Miscellaneous Characteristics: •
Does the switching function use the Route Request for non-call related routeing?
C.11.8 Route Select Optional parameters, values, and choices supported: •
alternateRoutes
•
remainRetries (noListAvailable, noCountAvailable, retryCount)
•
routeUsedReq
•
correlatorData
•
privateData
C.11.9 Route Used Optional parameters, values, and choices supported: •
callingDevice
•
domain
•
correlatorData
•
privateData
C.12 PhysDevServList The PhysDevServList parameter type specifies the physical device feature services that are supported by the switching function.
C.12.1 Press Button Optional parameters, values, and choices supported: •
privateData - 775 -
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.12.2 Get Auditory Apparatus Information Optional parameters, values, and choices supported: •
auditoryApparatus
•
privateData
•
auditoryApparatusType (speakerphone, handset, headset, speakerOnlyPhone, other)
•
speaker (present, volumeSettable, volumeReadable, muteSettable, muteReadable)
•
microphone (present, gainSettable, gainReadable, muteSettable, muteReadable)
•
hookswitch (hookswitchSettable, hookswitchOnhook)
•
privateData in the acknowledgement
C.12.3 Get Button Information Optional parameters, values, and choices supported: •
button
•
privateData
•
buttonLabel in the acknowledgement
•
buttonLabelSettable in the acknowledgement
•
buttonFunction in the acknowledgement
•
buttonAssociatedNumber in the acknowledgement
•
buttonAssociatedNumberSettable in the acknowledgement
•
buttonPressIndicator in the acknowledgement
•
lampList in the acknowledgement
•
privateData in the acknowledgement
C.12.4 Get Display Optional parameters, values, and choices supported: •
displayID
•
privateData
•
characterSet (aSCII, unicode, proprietary) in the acknowledgement
•
privateData in the acknowledgement
C.12.5 Get HookSwitch Status Optional parameters, values, and choices supported: •
hookswitch
•
privateData
•
privateData in the acknowledgement
C.12.6 Get Lamp Information Optional parameters, values, and choices supported: - 776 -
•
lamp
•
privateData
•
lampLabel in the acknowledgement
•
button in the acknowledgement
•
lampColor in the acknowledgement
•
privateData in the acknowledgement
C.12.7 Get Lamp Mode Optional parameters, values, and choices supported: •
lamp
•
privateData
•
lampMode in the acknowledgement
•
lampBrightness (unspecifiedNormal, dim, bright) in the acknowledgement
•
lampColor in the acknowledgement
•
button in the acknowledgement
•
privateData in the acknowledgement
C.12.8 Get Message Waiting Indicator Optional parameters, values, and choices supported: •
privateData
•
deviceForMessage in the acknowledgement
•
lampIsPresent in the acknowledgement
•
privateData in the acknowledgement
C.12.9 Get Microphone Gain Optional parameters, values, and choices supported: •
auditoryApparatus
•
privateData
•
micGainAbs in the acknowledgement
•
privateData in the acknowledgement
C.12.10Get Microphone Mute Optional parameters, values, and choices supported: •
auditoryApparatus
•
privateData
•
privateData in the acknowledgement
C.12.11 Get Ringer Status Optional parameters, values, and choices supported: •
ringer
•
privateData
•
ringCount in the acknowledgement - 777 -
•
ringDuration in the acknowledgement
•
ringPattern in the acknowledgement
•
ringVolume in the acknowledgement
•
ringVolAbs in the acknowledgement
•
privateData in the acknowledgement
C.12.12Get Speaker Mute Optional parameters, values, and choices supported: •
auditoryApparatus
•
privateData
•
privateData in the acknowledgement
C.12.13Get Speaker Volume Optional parameters, values, and choices supported: •
auditoryApparatus
•
privateData
•
speakerVolAbs in the acknowledgement
•
privateData in the acknowledgement
C.12.14Set Button Information Optional parameters, values, and choices supported: •
buttonLabel
•
buttonAssociatedNumber
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.12.15Set Display Optional parameters, values, and choices supported: •
physicalBaseRowNumber
•
physicalBaseColumnNumber
•
offset
•
characterSet
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Does the switching function support modifying the relative positions of the logical and physical displays (i.e., scrolling) via this service?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
- 778 -
C.12.16Set HookSwitch Status Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.12.17Set Lamp Mode Optional parameters, values, and choices supported: •
lampMode (brokenFlutter, flutter, off, steady, wink, reserved, sf0 through sf94)
•
lampBrightness (unspecifiedNormal, dim, bright)
•
lampColor (noColor, red, yellow, green, blue, reserved, sf0 through sf94)
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.12.18Set Message Waiting Indicator Optional parameters, values, and choices supported: •
deviceForMessage
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.12.19Set Microphone Gain Optional parameters, values, and choices supported: •
microphoneGain (micGainAbs, micGainInc)
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.12.20Set Microphone Mute Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.12.21Set Ringer Status Optional parameters, values, and choices supported: - 779 -
•
ringerMode (ringing, not ringing)
•
ringVolume (ringVolAbs, ringVolInc)
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.12.22Set Speaker Mute Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.12.23Set Speaker Volume Optional parameters, values, and choices supported: •
speakerVolume (speakerVolAbs, speakerVolInc)
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
•
The speaker volume is reset after every call.
•
The setting of the speaker volume is not allowed while participating in an active call.
C.13 PhysDevEvtsList The PhysDevEvtsList parameter type specifies the physical device feature events that are supported by the switching function.
C.13.1 Button Information Optional parameters, values, and choices supported: •
buttonLabel
•
buttonAssociatedNumber
•
buttonPressIndicator
•
privateData
C.13.2 Button Press Optional parameters, values, and choices supported: •
buttonLabel
•
buttonAssociatedNumber
•
privateData
C.13.3 Display Updated Optional parameters, values, and choices supported: - 780 -
•
characterSet (aSCII, unicode, proprietary)
•
privateData
C.13.4 Hookswitch Optional parameters, values, and choices supported: •
privateData
C.13.5 Lamp Mode Optional parameters, values, and choices supported: •
lampMode (brokenFlutter, flutter, off, steady, wink, unknown, sf0 through sf94)
•
lampBrightness (unspecifiedNormal, dim, bright)
•
lampColor (noColor, red, yellow, green, blue, unknown, sf0 through sf94)
•
privateData
C.13.6 Message Waiting Optional parameters, values, and choices supported: •
deviceForMessage
•
privateData
C.13.7 Microphone Gain Optional parameters, values, and choices supported: •
microphoneGain (micGainAbs, micGainInc)
•
privateData
C.13.8 Microphone Mute Optional parameters, values, and choices supported: •
privateData
C.13.9 Ringer Status Optional parameters, values, and choices supported: •
ringerMode (ringing, not ringing)
•
ringCount
•
ringDuration
•
ringPattern
•
ringVolume (ringVolAbs, ringVolInc)
•
privateData
C.13.10Speaker Mute Optional parameters, values, and choices supported: •
privateData
C.13.11 Speaker Volume Optional parameters, values, and choices supported: •
speakerVolume (speakerVolAbs, speakerVolInc)
•
privateData - 781 -
C.14 LogicalServList The LogicalServList parameter type specifies the logical device feature services that are supported by the switching function.
C.14.1 Call Back Non-Call-Related Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Do additional Call Back Non-Call-Related service requests for the same originating and target devices result in a negative acknowledgement?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.14.2 Call Back Message Non-Call-Related Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Do additional Call Back Message Non-Call-Related service requests for the same originating and target devices result in a negative acknowledgement?
•
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.14.3 Cancel Call Back Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
•
Does the switching function support clearing of all Call Back features at a device (e.g., supporting a null format Device ID)?
C.14.4 Cancel Call Back Message Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
•
Does the switching function support clearing of all Call Back Message features at a device (e.g., supporting a null format Device ID)?
C.14.5 Get Agent State Optional parameters, values, and choices supported: •
acdGroup - 782 -
•
privateData
•
agentStateList (Agent ID) in the acknowledgement
•
agentInfo (pendingAgentState, agentStateCondition (forcedPause, pause)) in the acknowledgement
•
privateData in the acknowledgement
C.14.6 Get Auto Answer Optional parameters, values, and choices supported: •
privateData
•
numberOfRings in the acknowledgement
•
privateData in the acknowledgement
C.14.7 Get Auto Work Mode Optional parameters, values, and choices supported: •
privateData
•
autoWorkInterval in the acknowledgement
•
privateData in the acknowledgement
C.14.8 Get CallBack Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.14.9 Get Caller ID Status Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.14.10Get Do Not Disturb Optional parameters, values, and choices supported: •
privateData
•
callOrigination parameter, callOrigination (internal, external) in the acknowledgement
•
callingDeviceList in the acknowledgement
•
privateData in the acknowledgement
C.14.11 Get Forwarding Optional parameters, values, and choices supported: •
privateData
•
forwardList (forwardImmediate, forwardBusy, forwardDND, forwardNoAns, forwardBusyInt, forwardBusyExt, forwardDNDInt, forwardDNDExt, forwardNoAnsInt, forwardNoAnsExt, forwardImmInt, forwardImmExt) in the acknowledgement
•
forwardDN in the acknowledgement
•
forwardDefault (defaultForwardingTypeAndForwardingDN, defaultForwardingType, defaultForwardDN) in the acknowledgement
•
ringCount in the acknowledgement - 783 -
•
ringDuration in the acknowledgement
•
privateData in the acknowledgement
C.14.12Get Last Number Dialed Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.14.13Get Presence State Optional parameters, values, and choices supported: •
privateData
•
fromTime in the acknowledgement
•
untilTime in the acknowledgement
•
place in the acknowledgement
•
mood in the acknowledgement
•
namedPresenceState in the acknowledgement
•
privateData in the acknowledgement
C.14.14Get Routeing Mode Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.14.15Set Agent State Optional parameters, values, and choices supported: •
requestedAgentState (loggedOn, loggedOff, notReady, ready, workingAfterCall)
•
agentID
•
password
•
group
•
privateData
•
pendingAgentState (workingAfterCall, notReady, null) in the acknowledgement
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
•
Does the switching function allow a group (ACD group) device in the service request (i.e. service applies to all agents associated with the ACD group)?
•
Does the switching function allow an ACD device in the service request (i.e. service applies to all agents associated with the ACD device)?
•
Does the switching function delay transition to the requestedAgentState if it is Busy (i.e. support the pending agent state)?
•
Does the switching function delay transition to the requestedAgentState if it is WorkingAfterCall(i.e. support the pending agent state)? - 784 -
C.14.16Set Auto Answer Optional parameters, values, and choices supported: •
numberOfRings
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.14.17Set Auto Work Mode Optional parameters, values, and choices supported: •
autoWorkInterval
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
•
Does the switching function allow a group (ACD group) device in the service request (i.e. service applies to all agents associated with the ACD group)?
•
Does the switching function allow an ACD device in the service request (i.e. service applies to all agents associated with the ACD device)?
C.14.18Set Caller ID Status Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.14.19Set Do Not Disturb Optional parameters, values, and choices supported: •
callOrigination parameter, callOrigination (internal, external)
•
callingDeviceList
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.14.20Set Forwarding Optional parameters, values, and choices supported: •
forwardingType (forwardImmediate, forwardBusy, forwardDND, forwardNoAns, forwardBusyInt, forwardBusyExt, forwardDNDInt, forwardDNDExt, forwardNoAnsInt, forwardNoAnsExt, forwardImmInt, forwardImmExt)
•
forwardDN - 785 -
•
ringCount
•
ringDuration
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.14.21Set Presence State Optional parameters, values, and choices supported: •
fromTime
•
untilTime
•
place
•
mood
•
namedPresenceState
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.14.22Set Routeing Mode Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
Service Request Acknowledgement Model (Atomic [FALSE] or Multi-Step [TRUE])
C.15 LogicalEvtsList The LogicalEvtsList parameter type specifies the logical device feature services that are supported by the switching function.
C.15.1 Agent Busy Optional parameters, values, and choices supported: •
agentID
•
acdGroup
•
pendingAgentState (workingAfterCall, notReady, ready, null)
•
cause
•
privateData
C.15.2 Agent Logged Off Optional parameters, values, and choices supported: •
agentID
•
acdGroup - 786 -
•
agentPassword
•
cause
•
privateData
C.15.3 Agent Logged On Optional parameters, values, and choices supported: •
agentID
•
acdGroup
•
agentPassword
•
cause
•
privateData
C.15.4 Agent Not Ready Optional parameters, values, and choices supported: •
agentID
•
acdGroup
•
cause
•
privateData
C.15.5 Agent Ready Optional parameters, values, and choices supported: •
agentID
•
acdGroup
•
cause
•
privateData
C.15.6 Agent Working After Call Optional parameters, values, and choices supported: •
agentID
•
acdGroup
•
pendingAgentState (notReady, ready, null)
•
cause
•
privateData
C.15.7 Auto Answer Optional parameters, values, and choices supported: •
numberOfRings
•
privateData
C.15.8 Auto Work Mode Optional parameters, values, and choices supported: •
privateData
- 787 -
C.15.9 Call Back Optional parameters, values, and choices supported: •
privateData
C.15.10Call Back Message Optional parameters, values, and choices supported: •
privateData
C.15.11 Caller ID Status Optional parameters, values, and choices supported: •
privateData
C.15.12Do Not Disturb Optional parameters, values, and choices supported: •
callOrigination parameter, callOrigination (internal, external)
•
callingDeviceList
•
privateData
C.15.13Forwarding Optional parameters, values, and choices supported: •
forwardingType (forwardImmediate, forwardBusy, forwardNoAns, forwardDND, forwardBusyInt, forwardNoAnsInt, forwardNoAnsExt, forwardImmInt, forwardImmExt, forwardDNDInt, forwardDNDExt)
•
forwardTo
•
forwardDefault (defaultForwardingTypeAndForwardDN, defaultForwardingType, defaultForwardDN)
•
ringCount
•
ringDuration
•
privateData
C.15.14Presence State Optional parameters, values, and choices supported: •
fromTime
•
untilTime
•
place
•
mood
•
namedPresenceState
•
privateData
C.15.15Routeing Mode Optional parameters, values, and choices supported: •
privateData
- 788 -
C.16 DeviceMaintEvtsList The DevicemaintenanceEvtsList parameter type specifies the device maintenance events that are supported by the switching function.
C.16.1 Back In Service Optional parameters, values, and choices supported: •
cause
•
privateData
C.16.2 Device Capabilities Changed Optional Parameters •
cause
•
privateData
C.16.3 Out of Service Optional parameters, values, and choices supported: •
cause
•
privateData
C.16.4 Partially In Service •
device
•
cause
•
privateData
C.17 IOServicesServList The IOServicesServList parameter type specifies the I/O services that are supported by the switching function.
C.17.1 I/O Register •
ioDevice
•
privateData
•
privateData in the acknowledgement
Miscellaneous Characteristics: •
allIODevices - Does the switching function support the ability to register for all I/O devices within the switching function?
C.17.2 I/O Register Abort Optional parameters, values, and choices supported: •
privateData
C.17.3 I/O Register Cancel Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement - 789 -
C.17.4 Data Path Resumed Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.17.5 Data Path Suspended Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.17.6 Fast Data Optional parameters, values, and choices supported: •
object (device, call)
•
dataPathType (text, voice)
•
displayAttributes (physicalBaseRowNumber, physicalBaseColumnNumber, offset)
•
privateData
•
privateData in the acknowledgement
Miscellaneous characteristics: •
Does the switching function support modifying the relative positions of the logical and physical displays (i.e., scrolling) via this service?
C.17.7 Resume Data Path Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
Miscellaneous characteristics: •
Does the switching function send the Data Path Resumed service as the result of this service request?
C.17.8 Send Broadcast Data Optional parameters, values, and choices supported: •
privateData
•
dataPathType (text, voice)
•
displayAttributes (physicalBaseRowNumber, physicalBaseColumnNumber, offset)
•
privateData in the acknowledgement
Miscellaneous characteristics: •
Does the switching function support modifying the relative positions of the logical and physical displays (i.e., scrolling) via this service?
C.17.9 Send Data Optional parameters, values, and choices supported: •
displayAttributes (physicalBaseRowNumber, physicalBaseColumnNumber, offset)
- 790 -
•
ioCause (terminationCharReceived, charCountReached, timeout, sfTerminated)
•
privateData
•
privateData in the acknowledgement
Miscellaneous characteristics: •
Does the switching function support modifying the relative positions of the logical and physical displays (i.e., scrolling) via this service?
C.17.10Send Multicast Data Optional parameters, values, and choices supported: •
ioData
•
displayAttributes (physicalBaseRowNumber, physicalBaseColumnNumber, offset)
•
privateData
•
privateData in the acknowledgement
Miscellaneous characteristics: •
Does the switching function support modifying the relative positions of the logical and physical displays (i.e., scrolling) via this service?
C.17.11 Start Data Path Optional parameters, values, and choices supported: •
object (device, call)
•
dataPathDirection (fromCfToObject, fromObjectToCF, biDirectional)
•
dataPathType (text, voice)
•
numberOfCharsToCollect
•
terminationCharacter
•
timeout
•
privateData
•
numberOfCharsToCollect in the acknowledgement
•
terminationCharacter in the acknowledgement
•
timeout in the acknowledgement
•
privateData in the acknowledgement
C.17.12Stop Data Path Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.17.13Suspend Data Path Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
- 791 -
C.18 DataCollectionServList The DataCollectionServList parameter type specifies the Data Collection services that are supported by the switching function.
C.18.1 Data Collected Optional parameters, values, and choices supported: •
digitsDuration
•
digitsPauseDuration
•
toneDetected (beep, billing, busy, carrier, confirmation, dial, faxCNG, hold, howler, intrusion, modemCNG, park, recordWarning, reorder, ringback, silence, sitVC, sitIC, sitRO, sitNC, sf0, sf1, sf2, sf3, sf4, sf5, sf6, sf7, sf8, sf9, sf10, other)
•
toneFrequency
•
toneDuration
•
tonesPauseDuration
•
connectionInfo
•
dcollCause (flushCharReceived, charCountReached, timeout, sfTerminated)
•
privateData
•
privateData in the acknowledgement
C.18.2 Data Collection Resumed Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.18.3 Data Collection Suspended Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.18.4 Resume Data Collection Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.18.5 Start Data Collection Optional parameters, values, and choices supported: •
object (device, call)
•
dataCollectionType (digits, telephonyTones)
•
digitsReportingCriteria (numChars, flushChar, timeout)
•
privateData
•
privateData in the acknowledgement
- 792 -
C.18.6 Stop Data Collection Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.18.7 Suspend Data Collection Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.19 VoiceServList The VoiceServList parameter type specifies the Voice services that are supported by the switching function.
C.19.1 Activate Optional parameters, values, and choices supported: •
resource
•
grammarName
•
privateData
•
privateData in the acknowledgement
C.19.2 Clear Optional parameters, values, and choices supported: •
resource
•
privateData
•
privateData in the acknowledgement
C.19.3 Concatenate Message Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.19.4 Deactivate Optional parameters, values, and choices supported: •
resource
•
grammarName
•
privateData
•
privateData in the acknowledgement
C.19.5 Delete Message Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
- 793 -
C.19.6 Play Message Optional parameters, values, and choices supported: •
duration
•
termination parameter, termination (durationExceeded, dtmfDigitDetected, endOfMessageDetected, speechDetected)
•
privateData
•
privateData in the acknowledgement
Miscellaneous characteristics: •
Can multiple messages be played on the same connection at the same time?
C.19.7 Query Voice Attribute Optional parameters, values, and choices supported: •
messageToQuery
•
resource
•
attributeToQuery (encodingAlgorithm, samplingRate, duration, filename, currentPosition, currentSpeed, currentVolume, currentLevel, currentState, grammars, language, mode, retainAudio, silenceTimeout, maxTimeout, babbleTimeout, endSilence, rejectionThreshold, autoInterruptable, innerXML, interdigitTimeout, preflush)
•
connection
•
duration
•
termination parameter, termination (durationExceeded, dtmfDigitDetected, endOfSpeechDetected, speech)
•
privateData
•
attribute (encodingAlgorithm (aDPCM6K, aDPCM8K, muLawPCM6k, aLawPCM6K), samplingRate, duration, filename, currentPosition, currentSpeed, currentVolAbs, currentGain, currentState, grammars, language, mode (automatic, single, multiple), retainAudio, silenceTimeout, maxTimeout, babbleTimeout, endSilence, rejectionThreshold, autoInterruptable, innerXML, interdigitTimeout, preflush) in the acknowledgement
•
privateData in the acknowledgement
C.19.8 Queue Optional parameters, values, and choices supported: •
message
•
resource
•
text
•
privateData
•
privateData in the acknowledgement
C.19.9 Record Message Optional parameters, values, and choices supported: •
resource
•
samplingRate - 794 -
•
encodingAlgorithm (aDPCM6K, aDPCM8K, muLawPCM6k, aLawPCM6K)
•
maxDuration
•
termination parameter, termination (durationExceeded, dtmfDigitDetected, endOfDataDetected, speechDetected)
•
privateData
•
privateData in the acknowledgement
C.19.10Reposition Optional parameters, values, and choices supported: •
messageToReposition
•
resource
•
periodOfReposition (startOfMessage, endOfMessage, relativePointer)
•
privateData
•
privateData in the acknowledgement
C.19.11 Resume Optional parameters, values, and choices supported: •
messageToResume
•
resource
•
duration
•
privateData
•
privateData in the acknowledgement
C.19.12Review Optional parameters, values, and choices supported: •
messageToReview
•
resource
•
periodToReview (startOfMessage, lengthOfReview)
•
privateData
•
privateData in the acknowledgement
C.19.13Set Voice Attribute Optional parameters, values, and choices supported: •
message
•
resource
•
attributeToSet (currentSpeed, currentVolume (currentVolAbs, currentVolInc), currentGain, grammars, language, mode (automatic, single, multiple), retainAudio, silenceTimeout, maxTimeout, babbleTimeout, endSilence, rejectionThreshold, autoInterruptable, innerXML, interdigitTimeout, preflush)
•
privateData
•
privateData in the acknowledgement
- 795 -
C.19.14Start Optional parameters, values, and choices supported: •
resource
•
text
•
privateData
•
privateData in the acknowledgement
C.19.15Stop Optional parameters, values, and choices supported: •
messageToBeStopped
•
resource
•
privateData
•
privateData in the acknowledgement
C.19.16Suspend Optional parameters, values, and choices supported: •
message
•
resource
•
privateData
•
privateData in the acknowledgement
C.19.17Synthesize Message Optional parameters, values, and choices supported: •
gender (male, female)
•
privateData
•
privateData in the acknowledgement
C.20 VoiceEvtsList The VoiceEvtsList parameter type specifies the voice events that are supported by the switching function.
C.20.1 Bookmark Reached Optional parameters, values, and choices supported: •
resource
•
cause
•
servicesPermitted
•
privateData
C.20.2 Completed Optional parameters, values, and choices supported: •
resource
•
cause
•
servicesPermitted
•
privateData - 796 -
C.20.3 DTMF Detected Optional parameters, values, and choices supported: •
resource
•
cause
•
servicesPermitted
•
privateData
C.20.4 Emptied Optional parameters, values, and choices supported: •
resource
•
cause
•
servicesPermitted
•
privateData
C.20.5 Interruption Detected Optional parameters, values, and choices supported: •
resource
•
cause
•
servicesPermitted
•
privateData
C.20.6 Not Recognized Optional parameters, values, and choices supported: •
resource
•
cause
•
servicesPermitted
•
privateData
C.20.7 Play Optional parameters, values, and choices supported: •
message
•
resource
•
length
•
currentPosition
•
speed
•
cause
•
servicesPermitted
•
privateData
C.20.8 Recognized Optional parameters, values, and choices supported: •
resource - 797 -
•
cause
•
servicesPermitted
•
privateData
C.20.9 Record Optional parameters, values, and choices supported: •
message
•
resource
•
length
•
currentPosition
•
servicesPermitted
•
privateData
C.20.10Review Optional parameters, values, and choices supported: •
message
•
resource
•
length
•
currentPosition
•
cause
•
servicesPermitted
•
privateData
C.20.11 Silence Timeout Expired Optional parameters, values, and choices supported: •
resource
•
cause
•
servicesPermitted
•
privateData
C.20.12Speech Detected Optional parameters, values, and choices supported: •
resource
•
cause
•
servicesPermitted
•
privateData
C.20.13Started Optional parameters, values, and choices supported: •
resource
•
cause
•
servicesPermitted - 798 -
•
privateData
C.20.14Stop Optional parameters, values, and choices supported: •
message
•
resource
•
length
•
currentPosition
•
cause
•
servicesPermitted
•
privateData
C.20.15Suspend Play Optional parameters, values, and choices supported: •
message
•
resource
•
length
•
currentPosition
•
cause
•
servicesPermitted
•
privateData
C.20.16Suspend Record Optional parameters, values, and choices supported: •
message
•
resource
•
length
•
currentPosition
•
cause
•
servicesPermitted
•
privateData
C.20.17Voice Attribute Changed Optional parameters, values, and choices supported: •
message
•
resource
•
playVolume (playVolAbs, playVolInc)
•
recordingGain
•
speed
•
currentPosition
•
grammars - 799 -
•
language
•
mode
•
retainAudio
•
silenceTimeout
•
maxTimeout
•
babbleTimeout
•
endSilence
•
rejectionThreshold
•
autoInterruptabe
•
innerXML
•
interdigitTimeout
•
preflush
•
cause
•
privateData
C.20.18Voice Error Occurred Optional parameters, values, and choices supported: •
resource
•
cause
•
servicesPermitted
•
privateData
C.21 CDRServList The CDRServicesServList parameter type specifies the CDR services that are supported by the switching function.
C.21.1 Call Detail Records Notification Optional parameters, values, and choices supported: •
cdrReason (timeout, thresholdReached, other)
•
privateData
•
privateData in the acknowledgement
C.21.2 Call Detail Records Report Optional parameters, values, and choices supported: •
cdrReason (timeout, thresholdReached, other)
•
recordNumber
•
recordCreationTime
•
callingDevice
•
calledDevice
•
associatedCallingDevice
•
associatedcalledDevice - 800 -
•
networkCallingDevice
•
networkCalledDevice
•
callCharacteristics
•
mediaCallCharacteristics
•
chargedDevice (operator, nonOperator)
•
recordedCall
•
nodeNumber (area0, area1, area2)
•
tariffTable
•
connectionStart
•
connectionEnd
•
connectionDuration
•
accessCode
•
carrier
•
selectedRoute
•
billingIndicator (normalCharging, reverseCharging, creditCardCharging, callForwarding, callDeflection, callTransfer, other)
•
chargingInfo
•
suppServiceInfo (normalCall, consultationCall, transferCall, callCompletion, callForwarding, callDiversion, conferencing, intrusion, userUserInfo, other)
•
reasonForTerm (normalClearing, unsuccessfulCallAttempt, abnormalTermination, callTransferred, other)
•
authCode
•
accountInfo
•
deviceCategory
•
namedDeviceTypes
•
operatorDevice
•
lastStoredCDRReportSent
•
privateData
•
privateData in the acknowledgement
C.21.3 Send Stored Call Detail Records Optional parameters, values, and choices supported: •
timePeriod
•
privateData
•
privateData in the acknowledgement
C.21.4 Start Call Detail Records Transmission Optional parameters, values, and choices supported: •
transferMode (transferAtEndOfCall, transferOnRequest, transferOnThresholdReached)
•
privateData - 801 -
•
privateData in the acknowledgement
C.21.5 Stop Call Detail Records Transmission Optional parameters, values, and choices supported: •
cdrTermReason (endOfDataDetected, errorDetected, thresholdReached, other)
•
privateData
•
privateData in the acknowledgement
Miscellaneous characteristics: •
Does the switching function generate this service request?
•
Does the switching function support receiving this request?
C.22 LocationServicesServList The LocationServList parameter type specifies the Location services that are supported by the switching function.
C.22.1 Get Location Information Optional parameters, values, and choices supported: •
privateData
•
locationInfo in the acknowledgement
•
privateData in the acknowledgement
C.22.2 Set Location Information Optional parameters, values, and choices supported: •
locationInfo
•
replaceMode
•
privateData
•
privateData in the acknowledgement
C.22.3 Location Tracking Session Resumed Optional parameters, values, and choices supported: •
locReason
•
privateData
•
privateData in the acknowledgement
C.22.4 Location Tracking Session Suspended Optional parameters, values, and choices supported: •
locReason
•
locationInfoList
•
privateData
•
privateData in the acknowledgement
C.22.5 Resume Location Tracking Session Optional parameters, values, and choices supported: •
privateData - 802 -
•
privateData in the acknowledgement
C.22.6 Location Information Report Optional parameters, values, and choices supported: •
locationInfoList
•
privateData
•
privateData in the acknowledgement
C.22.7 Start Location Tracking Session Optional parameters, values, and choices supported: •
collectionType
•
collectionInterval
•
maxCollections
•
collectionFilter
•
reportingType
•
reportingInterval
•
reportingCount
•
privateData
•
pIDFProfileOption1 in the acknowledgement
•
pIDFProfileOption2 in the acknowledgement
•
privateData in the acknowledgement
C.22.8 Stop Location Tracking Session Optional parameters, values, and choices supported: •
reason
•
privateData
•
privateData in the acknowledgement
C.22.9 Suspend Location Tracking Session Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.22.10Get Location Tracking Capabilities Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.22.11 Get Location Tracking Sessions Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
- 803 -
C.22.12Location Session Info Optional parameters, values, and choices supported: •
segmentID
•
privateData
C.23 VendorSpecificServList The VendorSpecificServList parameter type specifies the vendor specific extension services which the switching function might request/send from the computing function or that the switching function supports from the computing function.
C.23.1 Escape Register Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.23.2 Escape Register Abort Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.23.3 Escape Register Cancel Optional parameters, values, and choices supported: •
privateData
•
privateData in the acknowledgement
C.23.4 Escape Optional parameters, values, and choices supported: •
privateData in the acknowledgement
Miscellaneous Characteristics: •
Does the switching function generate this service request?
•
Does the switching function support receiving this service request?
C.23.5 Private Data Version Selection Optional parameters, values, and choices supported: •
privateData in the acknowledgement
C.24 VendorSpecificEvtsList The VendorSpecificEvtsList parameter type specifies the vendor specific events that are supported by the switching function.
C.24.1 Private Event None.
- 804 -
Annex D (informative)
Connection State Transition Examples This annex contains examples that describes the connection state transitions specified in 6.1.3, “Connection”.
- 805 -
Table D-1 Connection State Transition Call Flow Examples State Change
Action
(D1) Null -> Initiated
A device goes offhook or the computing function issues a Make Call service and the calling device is prompted.
(D3) Null -> Queued
Device D2 parks the call to another device (D3).
Initial State
Final State
D1
D1
c
C1
D3
D1
i
C1
D1
c
C1
Comments
q
D3
c D2 The computing function issues a Make Call service request. The switching function sends the Originated event for the calling device.
(D2) Null -> Fail
Device D1 dials Device D2. Device D2 is currently active in another call and can not accept D1’s call. D1 hears a busy tone.
- 806 -
(D1) Null -> Connected
D2
D1
D1
c
C1
D2
D1
c
C1
D1
c
C1
The calling device is an Auto Answer device therefore no Service Initiated event is seen prior to the Originated event.
f
D2
Table D-1 Connection State Transition Call Flow Examples (continued) State Change
Action
(D2) Null -> Alerting
Switching function alerts a device. This could be the result of a Make Call service and the called device is being alerted.
(D2) Null -> Null
- 807 (D1) Initiated -> Null
Device D1 dials Device D2. Device D2 is busy on another call and cannot accept D1’s call. The call is immediately forwarded and moves to the new device without ever creating a connection at D2. To report this, a Diverted event shall be based on a Null>Null transition. A device that was taken off-hook is placed back on-hook before any actions are taken.
Initial State
Final State
D1
c
C1
D2
D1
c
C1
D1
c
C1
D2
D1
c
C1
D1
i
C1
D1
Comments
a
D2
D2
The switching function could alert a device that originates outside the device’s switching domain.
Table D-1 Connection State Transition Call Flow Examples (continued) State Change
Action
(D1) Initiated -> Fail
A device that was taken off-hook is left off-hook without entering any digits. After a time-out period, the device receives the reorder tone and the computing function receives the Failed event.
- 808 -
(D1) Initiated -> Connected
A device goes offhook and finishes dialling. A call is originated to another device and the computing function receives an Originated event.
(D1) Initiated -> Alerting
Device D1 is the calling device in a predictive call. Before any activity at D2, the D1C1 connection goes to initiated. After D2 is connected into the call, D1 is alerted.
Initial State
Final State
D1
i
C1
D1
f
C1
D1
i
C1
D1
c
C1
D1
i
C1
D1
a
C1
D2
Comments
c
D2
Table D-1 Connection State Transition Call Flow Examples (continued) State Change
Action
- 809 -
(D1) Initiated -> Queued
Device D1 is the calling device in a predictive call. Before any activity at D2, the D1C1 connection goes to initiated. After D2 is connected into the call, the call is queued at D1 (D1 is busy on another call).
(D2) Queued -> Null
A calling device can be queued to an ACD device or queued due to a Campon situation. The call moves from the queued device to a device that accepts the call. The computing function receives a Diverted event.
(D2) Queued -> Alerting
A device that has a camped on call clears from its active call and is alerted by the camped on call.
Initial State
D1
i
C1
D1
c
C1
Final State
q
D2
D1
q
C1
D2
D1
c
C1
Comments
c
D2
D2
* D3
D1
c
C1
q
D2
D1
c
C1
a
D2
Table D-1 Connection State Transition Call Flow Examples (continued) State Change
Action
(D2) Queued -> Fail
A call is queued to an ACD device and then ACD becomes unstaffed with no alternate routeing for queued calls on an unstaffed condition. An appearance of a shared bridged device configuration that is in the inactive mode has been placed on hold as a result of actions by another appearance in the device configuration.
(D2) Queued -> Connected
A call has been parked at device D2. The computing function successfully issues the Answer Call service for device D2.
(D1) Connected -> Null
A device in a twoparty call manually goes on-hook or a Clear Connection service is successfully invoked on behalf of this device.
- 810 -
(D2) Queued -> Hold
Initial State
Final State
Comments
D1
c
C1
q
D2
D1
c
C1
f
D2
D1
c
C1
q
D2
D1
c
C1
h
D2
D1
c
C1
q
D2
D1
c
C1
c
D2
D1
c
C1
c
D2
D1
C1
c
D2
Table D-1 Connection State Transition Call Flow Examples (continued)
- 811 -
State Change
Action
(D1) Connected -> Fail
A device that was in a two-party call stays off-hook after the other device goes on-hook. After a time-out period, the device receives the blocked tone and the computing function receives the Failed event.
(D1) Connected -> Hold
A device in a twoparty call manually places the other device on hold or the Hold Call service is successfully executed.
(D2) Connected -> Queued
In a shared bridged configuration, Device D2 goes onhook while another appearance in the bridged configuration remains connected to the call.
(D2) Hold -> Alerting
A held or consulted call returns to a device because of a time-out.
Initial State
D1
c
C1
D1
c
C1
D1
c
D1
c
Final State
Comments
D2
D1
f
C1
c
D2
D1
h
C1
c
D2
C1
c
D2
D1
c
C1
q
D2
C1
h
D2
D1
c
C1
a
D2
D2
Device D1 is the device placing the call on hold.
Table D-1 Connection State Transition Call Flow Examples (continued) State Change
Action
(D1) Hold -> Connected
A device that has previously placed another device on hold manually retrieves the held device or the Reconnect or Retrieve Call service is successfully executed.
(D1) Hold -> Null
A device that has previously placed another device on hold manually goes on-hook or the Clear Connection service is successfully executed for the holding device.
- 812 -
(D2) Hold -> Queued
A held appearance of a shared bridged device configuration is retrieved from hold and is placed in the inactive mode as a result of actions by another appearance in the device configuration.
Initial State
D1
h
C1
c
D2
D1
D1
h
C1
c
D2
D1
D1
c
C1
h
D2
D1
c
c
Final State
Comments
C1
c
D2
Device D1 is the device that retrieves the call.
C1
c
D2
C1
q
D2
Table D-1 Connection State Transition Call Flow Examples (continued) State Change (D2) Hold -> Fail
Action A device that has previously placed another device on hold has exceeded the holding timer and has transitioned to the Fail state.
- 813 -
C1
h
D2
D1
c
C1
f
D2
D1
c
C1
f
D2
D1
c
C1
c
D2
D1
c
C1
f
D2
D1
c
C1
a
D2
D1
c
C1
f
D2
D1
c
C1
h
D2
A called device is busy. The calling device camps on to the called device.
D1
c
C1
f
D2
D1
c
C1
q
D2
A device is busy. The calling device goes back on-hook.
D1
c
C1
f
D2
D1
(D2) Fail -> Alerting
A called device that was busy begins to alert.
(D2) Fail -> Null
Comments
c
A device intrudes into a call that first failed because the called device was busy.
(D2) Fail -> Queued
Final State
D1
(D2) Fail -> Connected
(D2) Fail -> Hold
Initial State
An exclusivebridged appearance has placed a call on hold and the other appearances which were blocked from use, transition to the hold state as well.
D2
Table D-1 Connection State Transition Call Flow Examples (concluded) State Change
Action
(D2) Alerting -> Null
A call is delivered to a device. Before the called device answers, the calling device goes onhook.
- 814 -
(D2) Alerting -> Queued
A call is delivered to an ACD device. No agents are available so the call queues at the ACD device.
(D2) Alerting -> Connected
A call delivered to a device. The called device either manually answers the call or the Answer Call service is used.
(D2) Alerting -> Alerted
A call has been offered to a device. After a timeout the call is delivered to the same device.
(D2) Alerting -> Fail
A call is alerting a device. That device is removed from service and there is no coverage or redirection criteria for this situation.
Initial State
Final State
Comments
D1
c
C1
a
D2
D1
D1
c
C1
a
D2
D1
c
C1
q
D2
D1
c
C1
a
D2
D1
c
C1
c
D2
D1
c
C1
a
D2
D1
c
C1
a
D2
D1
c
C1
a
D2
D1
c
C1
f
D2
D2
Annex E (informative)
Summary of changes in this edition 1. 6.1.1.1.6: Display - update definition of Character Set 2. 12.2.15: Event Cause - added new cause values 3. 12.2.24: Parameter Types - added definition for PresenceState 4. 13.1.4: Get Switching Function Capabilities - added statusReporting ServList in parameter servEvtsList 5. 16.1.2: Snapshot Device - added parameter callLinkageData 6. 16.1.3: Snapshot CallData - added parameter callLinkageData 7. 17.1: Call control services a. added optional parameter callLinkageData: Consultation Call, Directed Pickup Call, Group Pickup Call, Make Call, Make Connection, Make Predictive Call, Park Call b. added optional parameter CallLinkageDataList: Conference Call, Intrude Call, Join Call, Single Step Conference Call, Single Step Transfer Call, Transfer Call c.
added optional parameter listOfCallLinkageData: Send Message
8. 17.2: Call control events - added new cause values for Delivered and Established and update definition of Recall - No Answer 9. 19.1: Media attachment services a. added optional parameter callLinkageData: Attach Media Service 10. 21.1.15: Set Display - added optional parameter characterSet 11. 22.1: Logical Device feature services: added new services Get Presence State, Set Presence State 12. 22.2: Logical Device feature events: added new event Presence State 13. 26.2.17: Voice Attribute Changed - optional parameter mode is type Enumerated 14. Annex C: added new services, events and optional parameters
- 815 -
- 816 -