8g Ref Events-Models

Genesys
Events and Models

Reference Manual
The information contained herein is proprietary and confidential and cannot be disclosed or duplicated
without the prior written consent of Genesys Telecommunications Laboratories, Inc.
Copyright 20072011 Genesys Telecommunications Laboratories, Inc. All rights reserved.
About Genesys
Alcatel-Lucent's Genesys solutions feature leading software that manages customer interactions over phone, Web,
and mobile devices. The Genesys software suite handles customer conversations across multiple channels and
resourcesself-service, assisted-service, and proactive outreachfulfilling customer requests and optimizing
customer care goals while efficiently using resources. Genesys software directs more than 100 million customer
interactions every day for 4,000 companies and government agencies in 80 countries. These companies and agencies
leverage their entire organization, from the contact center to the back office, while dynamically engaging their
customers. Go to www.genesyslab.com for more information.
Each product has its own documentation for online viewing at the Genesys Technical Support website or on the
Documentation Library DVD, which is available from Genesys upon request. For more information, contact your sales
representative.
Notice
Although reasonable effort is made to ensure that the information in this document is complete and accurate at the
time of release, Genesys Telecommunications Laboratories, Inc., cannot assume responsibility for any existing errors.
Changes and/or corrections to the information contained in this document may be incorporated in future versions.
Your Responsibility for Your Systems Security
You are responsible for the security of your system. Product administration to prevent unauthorized use is your
responsibility. Your system administrator should read all documents provided with this product to fully understand the
features available that reduce your risk of incurring charges for unlicensed use of Genesys products.
Trademarks
Genesys, the Genesys logo, and T-Server are registered trademarks of Genesys Telecommunications Laboratories,
Inc. All other trademarks and trade names referred to in this document are the property of other companies. The
Crystal monospace font is used by permission of Software Renovation Corporation, www.SoftwareRenovation.com.
Technical Support from VARs
If you have purchased support from a value-added reseller (VAR), please contact the VAR for technical support.
Technical Support from Genesys
If you have purchased support directly from Genesys, please contact Genesys Technical Support at the regional
numbers provided on page 16. For complete contact information and procedures, refer to the Genesys Technical
Support Guide.
Ordering and Licensing Information
Complete information on ordering and licensing Genesys products can be found in the Genesys Licensing Guide.
Released by
Genesys Telecommunications Laboratories, Inc. www.genesyslab.com
Document Version: 8g_ref_events-models_03-2011_v8.0.001.00
Events and ModelsReference Manual 3
Table of Contents
Preface ................................................................................................................. 13
Intended Audience................................................................................... 13
Usage Guidelines .................................................................................... 14
Making Comments on This Document .................................................... 15
Contacting Genesys Technical Support................................................... 16
Part 1 Genesys Events .......................................................... 17
Genesys Events and Models Overview................................................... 17
Servers and Their Events and Models................................................ 18
Protocol-Specific Issues...................................................................... 20
Voice................................................................................................... 21
Chapter 1 T-Library Events ................................................................................... 23
How to Use This Chapter ........................................................................ 23
List of T-Library Events............................................................................ 24
General Events........................................................................................ 28
EventServerConnected....................................................................... 28
EventServerDisconnected .................................................................. 29
EventLinkConnected........................................................................... 30
EventLinkDisconnected ...................................................................... 32
Registration Events ................................................................................. 33
EventRegistered ................................................................................. 33
EventUnregistered.............................................................................. 34
Call-Handling & Transfer/Conference Events.......................................... 36
EventDialing........................................................................................ 36
EventRinging ...................................................................................... 37
EventEstablished................................................................................ 39
EventAbandoned ................................................................................ 41
EventDestinationBusy......................................................................... 42
EventDiverted ..................................................................................... 44
EventHeld ........................................................................................... 45
EventNetworkReached....................................................................... 47
EventPartyAdded................................................................................ 48
EventPartyChanged............................................................................ 50
Table of Contents
4 Genesys
EventPartyDeleted.............................................................................. 51
EventQueued...................................................................................... 53
EventBridged ...................................................................................... 55
EventReleased ................................................................................... 57
EventRetrieved ................................................................................... 59
Network Attended Transfer Events.......................................................... 61
EventNetworkCallStatus ..................................................................... 61
EventNetworkPrivateInfo .................................................................... 62
Call-Routing Events................................................................................. 64
EventRouteRequest............................................................................ 64
EventRouteUsed................................................................................. 66
Call-Treatment Events............................................................................. 68
EventTreatmentApplied ...................................................................... 68
EventTreatmentEnd............................................................................ 69
EventTreatmentNotApplied................................................................. 71
EventTreatmentRequired.................................................................... 72
DTMF Events........................................................................................... 73
EventDigitsCollected........................................................................... 73
EventDTMFSent ................................................................................. 75
Voice-Mail Events.................................................................................... 76
EventMailBoxLogin............................................................................. 76
EventMailBoxLogout ........................................................................... 78
EventVoiceFileOpened ....................................................................... 78
EventVoiceFileClosed......................................................................... 79
EventVoiceFileEndPlay....................................................................... 80
Agent-State & DN Events ........................................................................ 81
EventAgentLogin ................................................................................ 81
EventAgentLogout .............................................................................. 83
EventQueueLogout ............................................................................. 84
EventAgentReady............................................................................... 85
EventAgentNotReady ......................................................................... 86
EventAgentAfterCallWork (ObsoleteNo Longer Supported) ........... 89
EventAgentIdleReasonSet (ObsoleteNo Longer Supported) .......... 89
EventDNOutOfService........................................................................ 90
EventDNBackInService ...................................................................... 90
EventDNDOn...................................................................................... 91
EventDNDOff ...................................................................................... 93
EventForwardSet ................................................................................ 94
EventForwardCancel .......................................................................... 95
EventMonitoringNextCall .................................................................... 96
EventMonitoringCancelled.................................................................. 97
EventOffHook...................................................................................... 99
EventOnHook ................................................................................... 100
EventMuteOn.................................................................................... 101
Table of Contents
EventMuteOff .................................................................................... 102
EventListenDisconnected ................................................................. 103
EventListenReconnected.................................................................. 104
EventMessageWaitingOn ................................................................. 106
EventMessageWaitingOff ................................................................. 107
Query Events......................................................................................... 108
EventAddressInfo ............................................................................. 108
EventPartyInfo .................................................................................. 115
EventLocationInfo............................................................................. 117
EventServerInfo................................................................................ 119
EventSwitchInfo................................................................................ 120
User-Data Events .................................................................................. 121
EventAttachedDataChanged ............................................................ 121
ISCC Events.......................................................................................... 123
EventAnswerAccessNumber ............................................................ 123
EventRemoteConnectionSuccess .................................................... 124
EventRemoteConnectionFailed........................................................ 125
EventReqGetAccessNumberCanceled............................................. 125
Special Events....................................................................................... 126
EventACK ......................................................................................... 126
EventAgentReserved........................................................................ 128
EventCallInfoChanged...................................................................... 129
EventPrivateInfo ............................................................................... 129
EventUserEvent ................................................................................ 130
EventPrimaryChanged...................................................................... 131
EventRestoreConnection.................................................................. 132
EventHardwareError ......................................................................... 133
EventResourceAllocated (ObsoleteNo Longer Supported)........... 133
EventResourceFreed (ObsoleteNo Longer Supported) ................ 134
Negative-Response Events................................................................... 134
EventError......................................................................................... 134
Agent States and Work Modes .............................................................. 135
Unified Call-Party States........................................................................ 139
Availability of State Information......................................................... 140
Generic Telephony State................................................................... 140
Supplementary State......................................................................... 143
State Modifiers .................................................................................. 144
Routing / Treatment State................................................................. 145
Event Attributes ..................................................................................... 146
TEvent Structure.................................................................................... 159
Chapter 2 T-Library Call-Based Notifications.................................................... 163
Call Definition ........................................................................................ 163
Table of Contents
6 Genesys
Call Attributes ................................................................................... 164
T-Library Call-Based Events.................................................................. 164
List of T-Library Call-Based Events................................................... 165
EventCallCreated.............................................................................. 165
EventCallDataChanged .................................................................... 166
EventCallDeleted.............................................................................. 167
EventReleasedDEPRECATED...................................................... 168
Multi-Site Call Scenarios ....................................................................... 171
Simple Multi-Site Call........................................................................ 172
Multi-Site Call Transfer ..................................................................... 174
Attaching the IS-Link Post Mortem................................................... 176
Client-Side IS-Link Processing ......................................................... 179
Chapter 3 ISCC Transaction Monitoring............................................................ 181
The Subscription Type........................................................................... 181
TSubscriptionOperationType ............................................................ 182
Subscribing to Transaction Monitoring .................................................. 182
TTransactionMonitoring .................................................................... 182
Subscription Rules............................................................................ 183
The Transaction Monitoring Event......................................................... 184
EventTransactionStatus.................................................................... 184
Transaction Monitoring States ............................................................... 186
Object State ...................................................................................... 187
Abstract Transaction State................................................................ 188
IS Link Creation Feature State.......................................................... 189
Call Operation Feature State ............................................................ 191
Resource Feature State.................................................................... 192
Transaction Monitoring Elements .......................................................... 193
Chapter 4 T-Library Unstructured Data.............................................................. 197
User Data .............................................................................................. 197
Arrival, Use, and Manipulation of User Data..................................... 198
User Data in Consultation Calls........................................................ 198
User Data in Multi-Site Consultation Calls........................................ 200
Extensions............................................................................................. 201
Extensions Common to All T-Servers According to Request............ 201
Reasons ................................................................................................ 205
Persistent Reasons........................................................................... 207
Chapter 5 IVR Protocol Messages...................................................................... 209
General Messages ................................................................................ 209
Table of Contents
LoginResp......................................................................................... 209
MonitorInfo........................................................................................ 210
Server Subtype................................................................................. 210
Port Subtype..................................................................................... 211
Agent Subtype .................................................................................. 212
Routing Messages................................................................................. 212
RouteResponse................................................................................ 213
Call Treatment Messages...................................................................... 213
TreatCall ........................................................................................... 213
Cancel............................................................................................... 214
External Routing Messages................................................................... 214
AccessNumResp .............................................................................. 214
Transfer/Conferencing Messages.......................................................... 214
CallStatus.......................................................................................... 215
CallError............................................................................................ 215
Call Information Messages.................................................................... 216
CallInfoResp ..................................................................................... 216
Statistics Messages............................................................................... 217
StatResp ........................................................................................... 217
User Data Messages............................................................................. 218
UDataResp ....................................................................................... 218
Outbound Messages ............................................................................. 219
DialOutRegistryResp ........................................................................ 219
DialOut .............................................................................................. 219
Part 2 Genesys Interaction Models .................................... 221
Chapter 6 Call Models and Flows....................................................................... 223
Legend................................................................................................... 223
List of Call Models ................................................................................. 225
Basic Call Models.................................................................................. 229
Simple Call Model ............................................................................. 229
Connection-Establishing Phase (Internal/Inbound Call) ................... 230
Connection-Establishing Phase (Internal/Inbound
Call to ACD).................................................................................. 233
Connection-Establishing Phase (Internal/Inbound Call Queued to
Multiple ACDs).............................................................................. 236
Connection-Establishing Phase (Internal/Inbound Call
with Call Parking).......................................................................... 240
with RoutingRouteQueue Case) ............................................... 243
with Routing)................................................................................. 247
Table of Contents
8 Genesys
with Routing Outbound) ................................................................ 251
Connection-Establishing Phase (Outbound Call).............................. 254
Connection-Establishing Phase While On Hold
(Internal/Outbound Call) ............................................................... 257
Releasing Calls...................................................................................... 258
Release Phase ................................................................................. 258
Release from Conference Phase...................................................... 259
Delete from Conference Phase ........................................................ 260
Holding, Transferring, and Conferencing............................................... 261
Hold/Retrieve Function, Consulted Party Answers........................... 262
Hold/Retrieve Function, Consulted Party Does Not Answer............. 265
Single-Step Transfer ......................................................................... 268
Single-Step Transfer (Outbound) ...................................................... 271
Mute Transfer.................................................................................... 274
Two-Step Transfer: Complete After Consulted Party Answers ......... 277
Two-Step Transfer: Complete Before Consulted Party Answers
(Blind) ........................................................................................... 280
Two-Step Transfer: to ACD............................................................... 283
Two-Step Transfer: to a Routing Point .............................................. 288
Trunk Optimization: Trunk Anti-Tromboning ..................................... 292
Single-Step Conference.................................................................... 294
Conference ....................................................................................... 296
Blind Conference (Complete Before Consulted
Party Answers) ............................................................................. 300
Conference with Two Incoming Calls Using TMergeCalls ................ 304
Handling User Data ............................................................................... 307
Attaching/Updating User Data to Internal Call .................................. 307
Attaching/Updating User Data to Call by Third Party........................ 308
Special Cases........................................................................................ 310
Outbound Call to a Busy Destination................................................ 310
Rejected Call .................................................................................... 312
Internal Call to Destination with DND Activated................................ 316
Call Forwarding (on No Answer)....................................................... 318
Alternate-Call Service....................................................................... 321
Reconnect-Call Service .................................................................... 323
Redirect-Call Service........................................................................ 325
Internal/Inbound Call with Bridged Appearance ............................... 328
Outbound Call from Bridged Appearance......................................... 331
Hold/Retrieve for Bridged Appearance............................................. 334
Internal/Inbound Call Answerable by Several Agents
(Party B Answers)......................................................................... 336
Call Treatment with Routing.............................................................. 339
Predictive Dialing................................................................................... 343
Table of Contents
Predictive Call ................................................................................... 343
Predictive Call with Routing.............................................................. 347
Predictive Call (Connected to a Device Specified in Extensions) ..... 352
Monitoring Calls..................................................................................... 357
Service Observing on Agent ............................................................. 357
Service Observing for Agent-Initiated Call ........................................ 363
Service Observing on Queue............................................................ 366
Working With Queues............................................................................ 370
Multiple-Queue Call Treated at an IVR Port: Treatment
at IVR Queue................................................................................ 370
Multiple-Queue Call Treated at an IVR Port: Direct Treatment
at IVR Port .................................................................................... 374
Multiple-Queue Call: Call Removed from Queue.............................. 377
Network T-Server Attended Transfer
Call Flows ......................................................................................... 379
Standard Network Call Initiation........................................................ 379
Consultation Leg Initiation, Specific Destination ............................... 380
Failed Consultation: Specific Target.................................................. 381
Consultation Leg Initiation, URS Selected Destination..................... 381
Failed Consultation: URS Selected Destination................................ 382
Transfer/Conference Completion: Explicit ........................................ 383
Transfer Completion: Implicit ............................................................ 384
Conference Completion.................................................................... 385
Alternate Call Service ....................................................................... 385
Alternate Call Service with Transfer Completion .............................. 386
Reconnection.................................................................................... 387
Caller Abandonment ......................................................................... 389
Network Single-Step Transfer ........................................................... 390
Premature Disconnection, One Variation.......................................... 390
Premature Disconnection, a Second Variation ................................. 391
Transactional Error ........................................................................... 392
Chapter 7 Basic Interaction Models ................................................................... 393
Overview................................................................................................ 393
Registration ........................................................................................... 394
Successful Registration .................................................................... 394
Unsuccessful Registration ................................................................ 395
Media Server Submits Interaction ......................................................... 396
Media Server Asks to Submit ........................................................... 396
Unsuccessful Submission by Media Server...................................... 397
Agent Submits Interaction ..................................................................... 397
Successful Submission..................................................................... 398
Unsuccessful Submission................................................................. 398
Table of Contents
10 Genesys
Stop Processing..................................................................................... 399
A: Initiated by Media Server, Agent Involved.................................... 399
B: Initiated by Media Server, URS Involved...................................... 400
C: Initiated By Agent ......................................................................... 401
D: Initiated by URS ........................................................................... 402
Unsuccessful .................................................................................... 403
Change Properties................................................................................. 404
Media Server Requests While Agent is Processing.......................... 404
Media Server Requests While URS is Processing ........................... 405
URS Requests .................................................................................. 406
Unsuccessful Request ...................................................................... 407
Place Interaction in Queue .................................................................... 408
Place Interaction in Workbin.................................................................. 409
Deliver Interaction to Agent ................................................................... 411
URS Requests Delivery .................................................................... 411
Agent Accepts Delivery..................................................................... 412
Agent Rejects Delivery...................................................................... 413
Agent Fails to Respond in Time........................................................ 413
Agent Pulls Interaction........................................................................... 414
Agent Issues Pull Request................................................................ 414
Processing Occurs............................................................................ 416
No Processing: Timeout.................................................................... 417
Transfer ................................................................................................. 418
Invitation Issued................................................................................ 418
Invitation Accepted............................................................................ 419
Invitation Rejected ............................................................................ 419
Invitation Times Out .......................................................................... 420
Invitation Is Invalid ............................................................................ 421
Conference............................................................................................ 421
Invitation Issued................................................................................ 422
Invitation Accepted............................................................................ 423
Invitation Rejected ............................................................................ 424
Invitation Times Out .......................................................................... 424
Invitation Is Invalid ............................................................................ 425
Leave the Conference ...................................................................... 426
Fail to Leave the Conference............................................................ 427
Workbin Operations............................................................................... 427
Agent Gets Workbin Content ............................................................ 428
Agent Fails to Get Workbin Content ................................................. 428
Agent Requests Workbin Notification ............................................... 429
Agent Cancels Workbin Notifications................................................ 429
Snapshot Operations............................................................................. 430
Take a Snapshot ............................................................................... 430
Table of Contents
Get Snapshot Interactions ................................................................ 431
Lock or Unlock Interactions .............................................................. 432
Release Snapshot............................................................................. 432
Intrusion................................................................................................. 433
Intrusion Requested.......................................................................... 433
Intrusion Accepted............................................................................ 434
Intrusion Rejected by Agent.............................................................. 435
Intrusion Rejected by Interaction Server........................................... 436
Intrusion Times Out........................................................................... 437
Login/Logout.......................................................................................... 437
Agent Logs In.................................................................................... 438
Agent Logs Out ................................................................................. 439
Reporting Engine Connects................................................................... 440
Disconnection and Failover ................................................................... 441
Agent Disconnects............................................................................ 442
Interaction Server Disconnects......................................................... 442
Interaction Server Restarts ............................................................... 443
Invoke Autoresponse............................................................................. 444
Chapter 8 IVR Call Flows..................................................................................... 447
Overview................................................................................................ 447
Call Routing Call Flow........................................................................... 448
Route Failed .......................................................................................... 449
Reroute.................................................................................................. 450
Call Treatment ....................................................................................... 451
Call Treatment Failed ............................................................................ 452
Call Treatment Interrupted..................................................................... 453
MakeCall Call Flow................................................................................ 454
MakeCall (Busy) .................................................................................... 454
Conference Call Flow Diagrams............................................................ 454
One-Step Conference....................................................................... 455
One-Step Conference, Scenario 2.................................................... 456
Conference Consult Call ................................................................... 457
Conference Consult Call, Scenario 2................................................ 458
Conference Consult Call (Busy) ....................................................... 459
Conference Consult Call (Failed)...................................................... 460
Transfer Call Flow Diagrams ................................................................. 461
Transfer to Remote Site.................................................................... 461
Single-Step Transfer ......................................................................... 462
Transfer Consult Call ........................................................................ 463
Transfer Consult Call (Busy)............................................................. 464
Transfer Consult Call (Failed) ........................................................... 465
Table of Contents
12 Genesys
Supplements Related Documentation Resources ................................................... 467
Document Conventions ...................................................................... 470
Index ............................................................................................................... 473
Preface
Welcome to the Genesys Events and Models Reference Manual. This manual
introduces you to many of the call and interaction events and models that you
may encounter in a Genesys deployment.
This document is valid for the 7.x and 8.x releases of products related to these
models.
This preface contains the following sections:
Intended Audience, page 13
Usage Guidelines, page 14
Making Comments on This Document, page 15
Contacting Genesys Technical Support, page 16

In brief, you will find the following information in this guide:
A full list of call and other interaction events and their descriptions.
A collection of common call and other interaction models and flows.
Some specialized information on call and other interaction state.
For information about related resources and about the conventions that are
used in this document, see the supplementary material starting on page 467.
Intended Audience
This guide is intended for application developers who are familiar with
Genesys deployments and need to do gain greater insight into their workings.
Experienced system administrators might also use this Reference for advanced
configuration issues. For instance, you might use this Events and Models
Reference and its sample call models to help you handle and anticipate events
for a custom application you are designing to work in a Genesys deployment.
Or you might look at the important values associated with certain events in a
model, and use that information to specially configure a routing strategy.
This document provides detailed information on the workings of interactions
in a Genesys environment.
It assumes that you have a basic understanding of:
The underlying concepts of CTI technology.
14 Genesys
Preface Usage Guidelines
A familiarity with the workings of Genesys Interactions.
Genesys environment deployment and operation.
Your own Genesys configurations.
You may also find that a familiarity with messaging-compliant programming
gives you greater insight into issues as you read this document. A solid
understanding of client-server implementations is also useful.
Usage Guidelines
The Genesys developer materials outlined in this document are intended to be
used for the following purposes:
Creation of contact-center agent desktop applications associated with
Genesys software implementations.
Server-side integration between Genesys software and third-party
software.
Creation of a specialized client application specific to customer needs.
The Genesys software functions available for development are clearly
documented. No undocumented functionality is to be utilized without
Genesyss express written consent.
The following Use Conditions apply in all cases for developers employing the
Genesys developer materials outlined in this document:
1. Possession of interface documentation does not imply a right to use by a
third party. Genesys conditions for use, as outlined below or in the Genesys
Developer Program Guide, must be met.
2. This interface shall not be used unless the developer is a member in good
standing of the Genesys Interacts program or has a valid Master Software
License and Services Agreement with Genesys.
3. A developer shall not be entitled to use any licenses granted hereunder
unless the developers organization has met or obtained all prerequisite
licensing and software as set out by Genesys.
4. A developer shall not be entitled to use any licenses granted hereunder if
the developers organization is delinquent in any payments or amounts
owed to Genesys.
5. A developer shall not use the Genesys developer materials outlined in this
document for any general application development purposes that are not
associated with the above-mentioned intended purposes for the use of the
Genesys developer materials outlined in this document.
6. A developer shall disclose the developer materials outlined in this
document only to those employees who have a direct need to create, debug,
and/or test one or more participant-specific objects and/or software files
that access, communicate, or interoperate with the Genesys API.
Preface Making Comments on This Document
7. The developed works and Genesys software running in conjunction with
one another (hereinafter referred to together as the integrated solutions)
should not compromise data integrity. For example, if both the Genesys
software and the integrated solutions can modify the same data, then
modifications by either product must not circumvent the other products
data integrity rules. In addition, the integration should not cause duplicate
copies of data to exist in both participant and Genesys databases, unless it
can be assured that data modifications propagate all copies within the time
required by typical users.
8. The integrated solutions shall not compromise data or application security,
access, or visibility restrictions that are enforced by either the Genesys
software or the developed works.
9. The integrated solutions shall conform to design and implementation
guidelines and restrictions described in the Genesys Developer Program
Guide and Genesys software documentation. For example:
a. The integration must use only published interfaces to access Genesys
data.
b. The integration shall not modify data in Genesys database tables
directly using SQL.
c. The integration shall not introduce database triggers or stored
procedures that operate on Genesys database tables.
Any schema extension to Genesys database tables must be carried out using
Genesys Developer software through documented methods and features.
The Genesys developer materials outlined in this document are not intended to
be used for the creation of any product with functionality comparable to any
Genesys products, including products similar or substantially similar to
Genesyss current general-availability, beta, and announced products.
Any attempt to use the Genesys developer materials outlined in this document
or any Genesys Developer software contrary to this clause shall be deemed a
material breach with immediate termination of this addendum, and Genesys
shall be entitled to seek to protect its interests, including but not limited to,
preliminary and permanent injunctive relief, as well as money damages.
Making Comments on This Document
If you especially like or dislike anything about this document, feel free to e-
mail your comments to [email protected].
You can comment on what you regard as specific errors or omissions, and on
the accuracy, organization, subject matter, or completeness of this document.
Please limit your comments to the scope of this document only and to the way
in which the information is presented. Contact your Genesys Account
Representative or Genesys Technical Support, if you have suggestions about
the product itself.
16 Genesys
Preface Contacting Genesys Technical Support
When you send us comments, you grant Genesys a nonexclusive right to use or
distribute your comments in any way that it believes appropriate, without
incurring any obligation to you.
Contacting Genesys Technical Support
If you have purchased support directly from Genesys, contact Genesys
Technical Support at the following regional numbers:
Region Telephone E-Mail
North America and
Latin America
+888-369-5555 (toll-free)
+506-674-6767
[email protected]
Europe, Middle East, and
Africa
+44-(0)-1276-45-7002 [email protected]
Asia Pacific +61-7-3368-6868 [email protected]
Malaysia 1-800-814-472 (toll-free)
+61-7-3368-6868 (International)
[email protected]
India 000-800-100-7136 (toll-free)
+61-7-3368-6868 (International)
[email protected]
Japan +81-3-6361-8950 [email protected]
Before you contact technical support, refer to the Genesys Technical Support Guide for complete contact
information and procedures.
Part
1 Genesys Events
Part One of this document contains both an overview of this entire document,
and specific information about Genesys events. This event information is wide
ranging, and may include everything from the names and descriptions of
events to the attendant event attributes, to the definitions of event substates.
Based on the history of how this information has been presented in the past in
various documents, event information may differ from chapter to chapter. This
information appears in the following chapters:
Chapter 1, T-Library Events, on page 23 contains a list and description
of each T-Library event that T-Servers generate. It also identifies the
attributes that accompany each event.
Chapter 2, T-Library Call-Based Notifications, on page 163 contains
information on the TLIB events that relate to a call (as opposed to a DN or
device).
Chapter 3, ISCC Transaction Monitoring, on page 181 describes how to
work with ISCC regarding issues such as multi-site call transfer, inter-site
call linkage, call overflow, and other, possibly non-callrelated, multi-site
operations.
Chapter 4, T-Library Unstructured Data, on page 197 provides
information on how TLIB handles UserData, Extensions, and Reasons in
events in a Genesys system.
Chapter 5, IVR Protocol Messages, on page 209 offers detailed
information about IVR Server events.
Genesys Events and Models Overview
This Reference Manual provides you with a large collection of two different
types of information: descriptions of Genesys events and illustrations of
Genesys interaction models. Generally, you need to know about Genesys
events and standard interaction models if you are developing custom
18 Genesys
Part 1: Genesys Events Genesys Events and Models Overview
applications for integration with Genesys systems, or if you are trying to gain
greater insight into the flow of interactions in your contact center.
Genesys Events on page 17 is the events portion of this document. The
information in this Part is wide ranging, and includes everything from the
names and descriptions of events, to the attributes that attend events, to the
definitions of event substates. Based on the history of how this information has
been presented in the past in various documents, event information may differ
from chapter to chapter.
Genesys Interaction Models on page 221 is the models portion of this
document. It contains a selected list of call/interaction models. This
information is also wide ranging. Based on the history of how this information
has been presented in the past in various documents, model details may differ
from chapter to chapter.
In both parts of this document, chapters are organized according to the type of
event or model being described. So, both Part One and Part Two have specific
chapters on voice-based issues that center on T-Librarys generation of events
and how calls are routed in a contact center.
Servers and Their Events and Models
When Genesys Servers start up and when they process interactions, they
repeatedly perform certain tasks. This manual presents examples of these tasks
in the form of events the servers generate and models that show how the
components interact. You can study these events and models to:
Get a better idea of how the various portions of your system work.
Troubleshoot your system by inspecting the logs that record interactions of
the type exemplified in this document.
Understand what functions must be performed by a custom-built
component that you want to design.
Events
Genesys servers generate events. These events can both be in response to
requests that other components make of those servers, or they can be
unsolicited (Genesys servers are programmed to notify clients for any number
of reasons). Events that arrive in response to a request have an identifier you
can use to link the two.
Note: Event names may differ slightly across Genesys SDK products and
technologies. The names you see in this document correspond
generally to the names you will see when using the SDKs. For the
authoritative names of events used by your SDK, refer to the API
Reference of the SDK your are using.
This document attempts to provide enough information about each event you
may encounter so that you can intelligently handle events in your customized
code, but also so you can better understand issues that arise in your contact
center. Reviewing log files is far easier when you have an understanding of the
implications of given events.
Each event has a number of attributes associated with it to give you more
information on the process that is occurring. A given events attributes are not
static. Depending on the request or environment, certain attributes may or may
not be present. For completeness, this book documents all attributes that you
might encounter with a given event.
Models
Call models and interaction flows serve a number of important purposes. First,
no development for the core Genesys servers can take place unless there is a
general understanding of how a given call scenario, for instance, should
proceed in a contact center. The collections of interaction flows presented in
this Reference Manual represents the most common scenarios that Genesys
software users encounter.
Elements in Call and Interaction Models
Events as depicted in the models are protocol-specific. That is, a given library
issues its own events according to its own definitions (though some events
from different libraries have similar names). The ordering and naming of
events passed between components (messaging) in these models makes use of
the various protocols being described. These include, but are not limited to:
T-Library (the TLIB protocol): The core library for use in processing all
voice-based interactions.
Multimedia Interaction Management (the ITX and ESP protocols): The
means by which Interaction Server processes its non-voice interactions.
Multimedia Reporting protocol: This is Genesys Multimedias own
reporting protocol, different from the one used by other Genesys
applications that are reporting-specific.
Universal Routing Servers (URS) use of a subset of T-Library events:
Interaction Server uses these events to communicate with URS. When
these T-Library events occur in the model diagrams, the equivalent
Interaction Management protocol event is also shown. (The full collection
of T-Library events, available in Chapter 1, T-Library Events, on
page 23, is the authoritative list of T-Library events.)
20 Genesys
Note: For events and models of protocols not listed here (for instance,
STATLIB or CONFIGLIB), refer to the API Reference (Statistics or
Configuration Platform SDK API Reference for .NET or Java, in these
cases) of the SDK you are using.
Diagrams show time along the vertical axis, moving from top to bottom.
Participants are arranged along the horizontal axis.
Interactions
The term interaction in a Genesys context has the following sense: an
attempted communication between a customer and a contact center, in either
direction. The attempt may be successful or not; it has a media type; it may
give rise to other interactions (as when an incoming e-mail gives rise to an
automatic acknowledgement). It may belong to a series of related interactions,
known as a thread. Interaction properties are generally recorded in a database.
Participants
Participants are software components that send and receive messages. The
participants in the models in this book include the following:
T-Server and IVR Server
Switch and IVR
Interaction Server
Media server (E-mail Server Java, Chat Server, or a custom application)
Agent application
Universal Routing Server
Reporting engine (Stat Server or Call Concentrator)
Protocol-Specific Issues
In general, this manual attempts to unify the concept of events and models
across a number of disparate Genesys components. This allows you to move
from component to component with one reference as your guide for how
interactions are processed. However, you may find that you want more
information about specific protocols. In each case, the authoritative collection
of function calls and events for a given servers protocol is available from its
corresponding Platform SDK API Reference. (See the Platform SDK API
Reference, .NET or Java, available from the Developer Documentation CD
and the Genesys DevZone portal, for the server that interests you.)
Voice
The characteristic feature of events related to voice interactions is T-Servers
use of the TEvent data structure to return the results of requests sent by
applications using T-Library functions or as notification that there has been
some activity on a monitored object.
Some examples of event member values include:
EventRegistered
application has registered a DN.
EventUnregistered
application has unregistered a DN.
EventAgentLogin
agent has logged in to ACD group.
EventAgentLogout
agent has logged out of ACD.
EventAgentReady
agent is ready to receive ACD calls.
Chapter 1, T-Library Events, on page 23, has detailed information on the
TEvent data structure.
While this document presents a full representation of the TEvent structure,
certain of its members are reserved for internal use only.
22 Genesys
Chapter
1 T-Library Events
This chapter provides detailed information about the T-Library Events.
Information for this chapter is divided among the following sections:
How to Use This Chapter, page 23
List of T-Library Events, page 24
General Events, page 28
Registration Events, page 33
Call-Handling & Transfer/Conference Events, page 36
Network Attended Transfer Events, page 61
Call-Routing Events, page 64
Call-Treatment Events, page 68
DTMF Events, page 73
Voice-Mail Events, page 76
Agent-State & DN Events, page 81
Query Events, page 108
User-Data Events, page 121
ISCC Events, page 123
Special Events, page 126
Negative-Response Events, page 134
Agent States and Work Modes, page 135
Unified Call-Party States, page 139
Event Attributes, page 146
TEvent Structure, page 159

How to Use This Chapter
This chapter lists the events that developers can expect to see while working
with a Genesys implementation. Each event listed here is identified with a
description, the contents of the event (presented in table format as a list of the
24 Genesys
Chapter 1: T-Library Events List of T-Library Events
attributes associated with it), and an example of where the event is likely to be
encountered during a call flow. The end of this chapter includes general
information about various event-related issues, including an agent-state
diagram, definitions of event attributes (including, for the reference ID
attribute, a table of the relationships between requests and events), and a
description of the TEvent structure.
Event contents are presented as the collection of attributes associated with each
event, as well as an indication of that attributes Type. For the purposes of this
chapter, Type has one of two values: Mandatory or Optional. Here Type refers
to the presence of the attribute at the time of the generation of its event, and not
to a characteristic of the attribute itself.
Attribute Type:
MandatoryIndicates that this autoboot is always present when its
associated event occurs.
OptionalIndicates that this attribute may or may not be present when the
List of T-Library Events
Table 1: List of T-Library Events
Event Page #
General Events
EventServerConnected page 28
EventServerDisconnected page 29
EventLinkConnected page 30
EventLinkDisconnected page 32
Registration Events
EventRegistered page 33
EventUnregistered page 34
Call-Handling & Transfer/Conference Events
EventDialing page 36
EventRinging page 37
EventEstablished page 39
EventAbandoned page 41
EventDestinationBusy page 42
EventDiverted page 44
EventHeld page 45
EventNetworkReached page 47
EventPartyAdded page 48
EventPartyChanged page 50
EventPartyDeleted page 51
EventQueued page 53
EventBridged page 55
EventReleased page 57
EventRetrieved page 59
Network Attended Transfer Events
EventNetworkCallStatus page 61
EventNetworkPrivateInfo page 62
Call-Routing Events
EventRouteRequest page 64
EventRouteUsed page 66
Call-Treatment Events
EventTreatmentApplied page 68
EventTreatmentEnd page 69
EventTreatmentNotApplied page 71
EventTreatmentRequired page 72
DTMF Events
EventDigitsCollected page 73
Table 1: List of T-Library Events (Continued)
Event Page #
26 Genesys
EventDTMFSent page 75
Voice-Mail Events
EventMailBoxLogin page 76
EventMailBoxLogout page 78
EventVoiceFileOpened page 78
EventVoiceFileClosed page 79
EventVoiceFileEndPlay page 80
Agent-State & DN Events
EventAgentLogin page 81
EventAgentLogout page 83
EventQueueLogout page 84
EventAgentReady page 85
EventAgentNotReady page 86
EventAgentAfterCallWork (ObsoleteNo
Longer Supported)
page 89
EventAgentIdleReasonSet (ObsoleteNo
Longer Supported)
page 89
EventDNOutOfService page 90
EventDNBackInService page 90
EventDNDOn page 91
EventDNDOff page 93
EventForwardSet page 94
EventForwardCancel page 95
EventMonitoringNextCall page 96
EventMonitoringCancelled page 97
EventOffHook page 99
Event Page #
EventOnHook page 100
EventMuteOn page 101
EventMuteOff page 102
EventListenDisconnected page 103
EventListenReconnected page 104
EventMessageWaitingOn page 106
EventMessageWaitingOff page 107
Query Events
EventAddressInfo page 108
EventPartyInfo page 115
EventLocationInfo page 117
EventServerInfo page 119
EventSwitchInfo page 120
User-Data Events
EventAttachedDataChanged page 121
ISCC Events
EventAnswerAccessNumber page 123
EventRemoteConnectionSuccess page 124
EventRemoteConnectionFailed page 125
EventReqGetAccessNumberCanceled page 125
Special Events
EventACK page 126
EventAgentReserved page 128
EventCallInfoChanged page 129
EventPrivateInfo page 129
Event Page #
28 Genesys
Chapter 1: T-Library Events General Events
General Events
EventServerConnected
Event Description
The communication session with the server in question has been opened. This
event is generated on the client side and only in asynchronous communication
mode.
Event Contents
EventUserEvent page 130
EventPrimaryChanged page 131
EventRestoreConnection page 131
EventHardwareError page 133
EventResourceAllocated (ObsoleteNo
Longer Supported)
page 133
EventResourceFreed (ObsoleteNo
Longer Supported)
page 134
Negative-Response Events
EventError page 134
Event Page #
Table 2: EventServerConnected Contents
Event Attribute Type
Event Mandatory
Server Mandatory
Extensions Optional
Example
Figure 1: EventServerConnected Feature Example
EventServerDisconnected
Event Description
The communication session with the server in question has failed. T-Library
generates this event as soon as it recognizes that the connection with T-Server
has been lost.
T-Server Client
TOpenServer
EventLinkConnected
T-Library
30 Genesys
Event Contents
Example
Figure 2: EventServerDisconnected Feature Example
EventLinkConnected
Event Description
This event is generated in two ways: either as a notification that the connection
between the switch and T-Server, through the CTI link, has been restored, or as
a response to the TOpenServerEx() and TOpenServer() functions (that is, after
connecting to T-Server) to indicate the current CTI-link status.
If you are working with a pair of T-Servers with Hot Standby mode in a high-
availability environment, this event is also generated during T-Server
switchover.
Table 3: EventServerDisconnected Contents
Event Mandatory
Server Mandatory
Extensions Optional
connection failed
EventServerDisconnected
T-Library
Client T-Server
Event Contents
Examples
Figure 3: EventLinkConnected Feature, Example 1
Figure 4: EventLinkConnected Feature, Example 2
Table 4: EventLinkConnected Contents
ApplicationName Optional
Event Mandatory
Server Mandatory
SessionID Optional
CustomerID Optional
time Mandatory
Extensions Optional
T-Server Client
TOpenServer
EventLinkConnected
T-Library
T-Server Client
EventLinkConnected
LinkRecovered
Switch
32 Genesys
EventLinkDisconnected
Event Description
This event is generated as a notification that the connection between the switch
and T-Server, through the CTI link, has been severed.
If you are working with a pair of T-Servers with Hot Standby mode in a high-
availability environment, this event is also generated during T-Server
switchover.
Event Contents
Examples
Figure 5: EventLinkDisconnected Feature, Example 1
Table 5: EventLinkDisconnected Contents
SessionID Optional
CustomerID Optional
ErrorCode Optional
ErrorMessage Optional
Event Mandatory
Server Mandatory
time Mandatory
Extensions Optional
T-Server Client
LinkFail
Switch
Chapter 1: T-Library Events Registration Events
Figure 6: EventLinkDisconnected Feature, Example 2
Registration Events
EventRegistered
Event Description
The application has been registered to send requests and receive events
regarding the telephony object specified by ThisDN.
Event Contents
T-Server
TOpenServer
Client
T-Library
Table 6: EventRegistered Contents
AgentID
a
Optional
CustomerID Optional
Event Mandatory
Extensions
b
Mandatory
InfoStatus.AddressType Optional
InfoType=AddressInfoAddressType Mandatory
ReferenceID Mandatory
Server Mandatory
34 Genesys
Example
Figure 7: EventRegistered Feature Example
EventUnregistered
Event Description
The applications registration to send requests and receive events regarding the
telephony object specified by ThisDN has been canceled.
ThisDN Mandatory
time Mandatory
a. The AgentID attribute can only be present for objects of
AddressTypePosition or AddressTypeDN. See the contents
of Extensions.
b. The Extensions attribute contains the same information as
in EventAddressInfo:
For objects of AddressTypePosition or
AddressTypeDN, see the corresponding
InfoType=TAddressInfoDNStatus.
For objects of AddressTypeQueue, AddressTypeRouteDN, or
AddressTypeRouteQueue, see InfoType=TAddressInfo-
QueueStatus.
Details for Extensions in EventAddressInfo are available
on page 110.
Table 6: EventRegistered Contents (Continued)
T-Server Client
TRegisterAddress
EventRegistered
Event Contents
Example
Figure 8: EventUnregistered Feature Example
Table 7: EventUnregistered Contents
CustomerID Optional
ErrorCode Optional
Event Mandatory
ReferenceID
a
a. The ReferenceID attribute is mandatory in most cases,
but not present if the switch configuration has been
changed while the CTI link was down or if T-Server
configuration has been changed dynamically through
Configuration Manager. Meanwhile, the cause of un-
registration is specified by the attributes ErrorCode and
ErrorMessage.
Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
Extensions Optional
T-Server Client
TUnregisterAddress
EventUnregistered
36 Genesys
Chapter 1: T-Library Events Call-Handling & Transfer/Conference Events
Call-Handling & Transfer/Conference
Events
EventDialing
Event Description
An attempt to make a call on behalf of the telephony object specified by ThisDN
is in progress.
Event Contents
Table 8: EventDialing Contents
AgentID Optional
ANI Optional
CallHistory Optional
CallID Mandatory
CallType
a
Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
NetworkCallID Optional
NetworkNodeID Optional
OtherDN
b
Optional
OtherDNRole
b
Optional
OtherQueue Optional
OtherTrunk Optional
Examples
See the example after EventRinging.
EventRinging
Event Description
A call has been delivered to the telephony object specified by ThisDN.
PreviousConnID
c
Optional
Reasons Optional
ReferenceID Optional
Server Mandatory
ThisDN Mandatory
ThisDNRole Mandatory
ThisQueue
d
Optional
time Mandatory
TransferredNetworkCallID Optional
TransferredNetworkNodeID Optional
UserData Optional
a. CallType may be Unknown.
b. OtherDN may be either a dialed number or not present
if T-Server has no information about the other party.
OtherDNRole appears if the attribute OtherDN is present.
c. PreviousConnID must appear if the value of CallType is
Consult.
d. ThisQueue must appear in predictive dialing and be
equal to ThisDN.
Table 8: EventDialing Contents (Continued)
38 Genesys
Event Contents
Table 9: EventRinging Contents
AgentID Optional
ANI Optional
CallID Mandatory
CallState Mandatory
CallType Mandatory
ConnID Mandatory
CollectedDigits Optional
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
OtherDN Optional
OtherDNRole Optional
OtherQueue Optional
OtherTrunk Optional
PreviousConnID
a
Optional
Reasons Optional
Server Mandatory
ThisDN Mandatory
Example
Figure 9: EventRinging Feature Example
EventEstablished
Event Description
For the application associated with the calling party: the telephony object
specified by OtherDN has answered (either the calling party answered or the
switch simulated an answer if option auto-answer is set on the switch) and the
connection has been established. For the application associated with the called
party: the call associated with ConnID has been established.
ThirdPartyDN Optional
ThisQueue
b
Optional
time Mandatory
UserData Optional
a. The attribute must appear if the value of CallType is
Consult.
b. The attribute must appear in case of an ACD call.
Table 9: EventRinging Contents (Continued)
T-Server Client_1
TMakeCall
EventRinging
Client_2
EventDialing
40 Genesys
Event Contents
Table 10: EventEstablished Contents
Event Mandatory
Server Mandatory
CustomerID Optional
ConnID Mandatory
PreviousConnID
a
Optional
CallID Mandatory
CallType Mandatory
CallState Optional
AgentID Optional
ThisDN Mandatory
ThisQueue Optional
OtherDN Optional
OtherTrunk Optional
OtherQueue Optional
DNIS Optional
ANI Optional
UserData Optional
EventAbandoned
Event Description
The caller abandoned the call before it was answered.
Event Contents
Reasons Optional
Extensions Optional
time Mandatory
Consult.
Table 10: EventEstablished Contents (Continued)
Table 11: EventAbandoned Contents
ANI Optional
CallID Mandatory
CallState Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
42 Genesys
EventDestinationBusy
Event Description
The called party specified by OtherDN is busy with another call.
PreviousConnID
a
Optional
OtherDN Optional
OtherQueue Optional
OtherTrunk Optional
Server Mandatory
ThisDN Mandatory
ThisQueue
b
Optional
ThisTrunk Optional
time Mandatory
UserData Optional
Consult.
b. The attribute must appear in case of an ACD call.
Table 11: EventAbandoned Contents (Continued)
Event Contents
Table 12: EventDestinationBusy Contents
ANI Optional
CallID Mandatory
CallState
a
Optional
CallType Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
OtherDN Optional
OtherQueue Optional
OtherTrunk Optional
PreviousConnID
b
Optional
Server Mandatory
ThisDN Mandatory
ThisQueue Optional
time Mandatory
UserData Optional
44 Genesys
EventDiverted
Event Description
The call has been diverted from the queue to another telephony object.
Event Contents
a. For scenarios initiated with RequestMakeCall, this at-
tribute may have values that clarify the reason for the
destination being busy, for instance
CallStateSitInvalidNum.
b. The attribute must appear if the value of CallType is
Consult.
Table 13: EventDiverted Contents
CallID Mandatory
CallState Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
Event Mandatory
Extensions Optional
OtherDN Optional
OtherQueue Optional
EventHeld
Event Description
The call has been placed on hold.
OtherTrunk Optional
PreviousConnID
a
Optional
Server Mandatory
ThirdPartyDN
b
Optional
ThirdPartyDNRole Optional
ThirdPartyQueue
b
Optional
ThisDN
c
Mandatory
ThisQueue
c
Mandatory
ThisTrunk Optional
time Mandatory
UserData Optional
Consult.
b. Attributes must be present if the value of CallState is
Redirected. (See Redirect-Call Service on
page 325.) In all other call scenarios, ThirdPartyDN
must be present only if such information is provided
by a CTI link.
c. These attributes must be equal.
Table 13: EventDiverted Contents (Continued)
46 Genesys
Event Contents
Table 14: EventHeld Contents
AgentID Optional
ANI Optional
CallID Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
OtherDN Optional
OtherQueue Optional
OtherTrunk Optional
PreviousConnID
a
Optional
Reasons Optional
Server Mandatory
ThisDN Mandatory
ThisQueue Optional
time Mandatory
EventNetworkReached
Event Description
The call has reached the public network interface.
Event Contents
UserData Optional
Consult.
Table 14: EventHeld Contents (Continued)
Table 15: EventNetworkReached Contents
ANI Optional
CallID Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
OtherDN Optional
48 Genesys
EventPartyAdded
Event Description
One or more parties has been added to the call as a result of a conference. If
only one party is added (as in the case of a simple conference call), the
corresponding telephony object is specified in OtherDN. If more than one party
is added, then the corresponding telephony objects are specified in Extensions.
Event Contents
OtherTrunk Optional
PreviousConnID
a
Optional
Server Mandatory
ThisDN Mandatory
ThisTrunk Optional
time Mandatory
UserData Optional
Consult.
Table 15: EventNetworkReached Contents (Continued)
Table 16: EventPartyAdded Contents
AgentID Optional
ANI Optional
CallState Optional
CallType Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
OtherDN Optional
OtherQueue Optional
OtherTrunk Optional
Server Mandatory
ThirdPartyDN
a
Mandatory
ThirdPartyDNRole
a
Mandatory
ThisDN Mandatory
ThisQueue Optional
ThisTrunk Optional
time Mandatory
UserData Optional
Table 16: EventPartyAdded Contents (Continued)
50 Genesys
EventPartyChanged
Event Description
The telephony object specified by OtherDN has replaced the telephony object
specified by OtherDN in the previously received event; or the PreviousConnID of
the call has been given a new value, ConnID.
Event Contents
a. This attribute is not present if the switch does not dis-
tribute it to T-Server.
Table 17: EventPartyChanged Contents
AgentID Optional
ANI Optional
CallID Mandatory
CallState
a
Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
OtherDN
b
Optional
OtherDNRole
b
Optional
OtherTrunk
b
Optional
EventPartyDeleted
Event Description
The telephony object specified by OtherDN has been deleted from the
conference call in question.
PreviousConnID Mandatory
Server Mandatory
ThirdPartyDN
c
Mandatory
ThirdPartyDNRole
c
Mandatory
ThisDN Mandatory
ThisQueue Optional
ThisTrunk Optional
time Mandatory
UserData Optional
a. The value can be either Transferred or Conferenced.
For more information, see Chapter 6.
b. The attribute must not appear if the CallState is
Conferenced.
c. This attribute is not present if the switch does not dis-
tribute it to T-Server.
Table 17: EventPartyChanged Contents (Continued)
52 Genesys
Event Contents
Table 18: EventPartyDeleted Contents
AgentID Optional
ANI Optional
CallID Mandatory
CallState
a
Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
OtherDN Optional
OtherQueue Optional
OtherTrunk Optional
Reasons Optional
Server Mandatory
ThirdPartyDNRole Optional
ThisDN Mandatory
EventQueued
Event Description
The call has been queued in the ACD group specified by ThisQueue.
Event Contents
ThisQueue Optional
ThisTrunk Optional
time Mandatory
UserData Optional
a. The attribute indicates whether a call is still consid-
ered as a conference (that is, the number of parties in
the call is more than two).
Table 18: EventPartyDeleted Contents (Continued)
Table 19: EventQueued Contents
AgentID Optional
ANI Optional
CallID Mandatory
CallState Optional
CallType Mandatory
ConnID Mandatory
54 Genesys
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
LastCollectedDigit Optional
OtherDN Optional
OtherQueue Optional
OtherTrunk Optional
PreviousConnID
a
Optional
Server Mandatory
ThisDN
b
Mandatory
ThisQueue
b
Mandatory
ThisTrunk Optional
time Mandatory
UserData Optional
Consult.
b. These attributes must be equal.
Table 19: EventQueued Contents (Continued)
EventBridged
Event Description
Used in situations where Coverage Path is available or bridged calls can be
handled. EventBridged indicates an extension, besides the one pointed to by
ThisDN, has picked up the call, and that the telephony object specified by
ThisDN is no longer ringing (although it still can pick up the call, establishing a
three-way conversation).
EventBridged is used to describe a state where the call is neither ringing nor
established. The nature of a bridge is such that it is possible for a call to move
to a bridged state even after it has been released. Because of this, only calls
released through CTI will be detected as moving into the bridged state. If a
client issues a RequestReleaseCall() on a bridged call with two or more active
bridged or bridging parties, EventReleased, with CallState =
CallStateBridged, follows for the releasing party; the releasing party then
receives EventBridged. At this point, a client may issue a RequestAnswerCall()
to activate the call. If the client does this, EventEstablished follows.
Notes:
Currently, T-Server does not fully support placing a bridged or
bridging call on hold when there is only one active bridge. If a
client attempts to place such a call on hold, T-Server does not
reflect the held state of all members.
Transferring and conferencing a bridged or bridging call currently
works only when there is no more than one active bridge member.
There may be cases where a call is made from a bridged DN to the
principle extension on the bridge. In such an instance, the dialing
and ringing between two DNs on the same bridge is happening
within the context of a single call. While such a circumstance is
supported, the bridged appearance of the call should be ignored
and not used.
Event Contents
Table 20: EventBridged Contents
Event Mandatory
Server Mandatory
56 Genesys
CustomerID Optional
ConnID Mandatory
PreviousConnID
a
Optional
CallID Mandatory
CallType Mandatory
CallState
b
Optional
AgentID Optional
ThisDN Mandatory
ThisQueue
c
Optional
OtherDN
b
Optional
OtherTrunk
b
Optional
OtherQueue Optional
OtherDNRole
b
Optional
DNIS Optional
ANI Optional
UserData Optional
Extensions Optional
time Mandatory
Table 20: EventBridged Contents (Continued)
EventReleased
Event Description
The telephony object specified by ThisDN has disconnected or has been
dropped from the call.
Event Contents
Consult.
b. For the Avaya Communication Manager only: In a
Coverage Path scenario, the second party that has an-
swered a call must receive CallState=Conferenced, but
does not receive information about the other party (Ot-
herDN = NULL). See Chapter 6.
c. The attribute must appear in case of an ACD call.
Table 21: EventReleased Contents
AgentID Optional
ANI Optional
CallID Mandatory
CallState Mandatory
Cause Optional
CallType Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
58 Genesys
Extensions Optional
OtherDN
a
Optional
OtherDNRole
a
Optional
OtherQueue
a
Optional
OtherTrunk
a
Optional
PreviousConnID
b
Optional
Reasons Optional
Server Mandatory
ThirdPartyDN
c
Optional
ThisDN Mandatory
ThisQueue Optional
ThisTrunk Optional
time Mandatory
UserData Optional
a. This attribute does not appear if the release is from a
conference. In all other call scenarios, the attribute
must be present only if such information is provided
by a CTI link.
b. The attribute must appear if the value of CallType is
Consult.
Table 21: EventReleased Contents (Continued)
Example
Figure 10: EventReleased Feature Example
For more information, refer to Chapter 6.
EventRetrieved
Event Description
The call has been retrieved from hold.
Event Contents
c. The appearance of ThirdPartyDN depends on the fol-
lowing conditions:
If information about the new destination is available
from the switch at the moment when EventReleased is
generated, then ThirdPartyDN is mandatory. Or, if
T-Server has initiated a single-step transfer, redirec-
tion, or previously set the forwarding target, this attri-
bute is also mandatory.
If a call has gone through a single-step transfer, been
redirected, or forwarded by another application (not
the T-Server in question), this attribute is absent.
T-Server Client
TReleaseCall
EventReleased
Table 22: EventRetrieved Contents
AgentID Optional
ANI Optional
60 Genesys
CallID Mandatory
CallState Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
OtherDN
a
Optional
OtherDNRole
a
Optional
OtherQueue
a
Optional
OtherTrunk
a
Optional
Reasons Optional
Server Mandatory
ThisDN Mandatory
ThisDNRole
b
Mandatory
ThisQueue
c
Optional
ThisTrunk Optional
time Mandatory
UserData Optional
Table 22: EventRetrieved Contents (Continued)
Chapter 1: T-Library Events Network Attended Transfer Events
Network Attended Transfer Events
EventNetworkCallStatus
Event Description
Contains all pertinent information about the current state of a multi-party
network call. It is sent to all interested parties whenever the calls state
changes.
Event Contents
a. In all call scenarios, this attribute must be present only
if the information is provided by a CTI link.
b. The value here is the same as that for the events pre-
ceding EventRetrieved (EventEstablished and Even-
tRinging) for the same call.
c. The value here is the same as that for the events pre-
ceding EventRetrieved (EventEstablished and Even-
tRinging) for the same call. (For non-ACD calls,
ThisQueue is not reported)
Table 23: EventNetworkCallStatus Contents
ANI Optional
CallID Mandatory
CallType Mandatory
ConnID Mandatory
Cause Optional
CustomerID Optional
62 Genesys
EventNetworkPrivateInfo
Event Description
This event is generated both in response to a TNetworkPrivateService()
function call and when it is used to notify selected sets of clients of
T-Serverspecific information. This event indicates that one of two forms of
data has been passed:
DNIS Optional
Event Mandatory
Extensions Optional
NetworkCallState Mandatory
NetworkPartyRole
a
Mandatory
NetworkOrigDN Optional
NetworkDestDN Optional
NetworkDestState Mandatory
Reasons Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
UserData Optional
a. This attribute is not present for events distributed by
network T-Servers.
Table 23: EventNetworkCallStatus Contents (Continued)
Information supported only by certain T-Servers, and which is not covered
by general feature requests.
Notification about changes in T-Server behavior or device/call statuses.
This event can be distributed to the following clients:
Those who made a request for the private service,
TNetworkPrivateService().
Those registered on the specified device, depending on the nature of the
service.
Those who would otherwise be ineligible (for security reasons) for
receiving given events, and who thus require additional registration in
order to be notified.
Event Contents
Table 24: EventNetworkPrivateInfo Contents
PrivateEvent Mandatory
Event Mandatory
Reasons Optional
UserData Optional
Extensions Optional
Server Mandatory
ConnID Optional
ThisDN Optional
NetworkCallState Optional
NetworkPartyRole Optional
NetworkOrigDN Optional
NetworkDestDN Optional
NetworkDestState Optional
time Mandatory
64 Genesys
Chapter 1: T-Library Events Call-Routing Events
Example
Figure 11: EventNetworkPrivateInfo Example
Call-Routing Events
EventRouteRequest
Event Description
The call has been placed on the routing point specified by ThisDN, and the
switch is waiting for routing instructions.
Event Contents
Local
T-Server
TNetworkPrivateService
Client
Network
T-Server
TNetworkPrivateService
Table 25: EventRouteRequest Contents
ANI Optional
CallID Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
Examples
See EventRegistered on page 33 and Figure 12 on page 67.
DNIS Optional
Event Mandatory
Extensions Optional
OtherDN Optional
OtherQueue Optional
OtherTrunk Optional
PreviousConnID
a
Optional
Server Mandatory
ThisDN
b
Mandatory
ThisQueue
b
Mandatory
ThisTrunk Optional
time Mandatory
UserData Optional
a. The PreviousConnID attribute must appear if a call with
CallType=Consult has been placed on a routing point.
b. ThisDN and ThisQueue attributes must have equal val-
ues.
Table 25: EventRouteRequest Contents (Continued)
66 Genesys
EventRouteUsed
Event Description
The call has been routed as requested in the function TRouteCall() or has been
default routed by the switch after the routing timeout has expired (that is, there
was no routing instruction from the computer domain within the specified
timeout).
Event Contents
Table 26: EventRouteUsed Contents
ANI Optional
CallID Mandatory
CallState Optional
CallType Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
Reasons Optional
Server Mandatory
ThirdPartyDN
a
Optional
OtherDN
b
Optional
ThirdPartyDNRole = Destination Optional
Example
Figure 12: EventRouteRequest and EventRouteUsed Feature, Example 1
ThisDN
c
Mandatory
ThisQueue
c
Mandatory
ThisTrunk Optional
time Mandatory
UserData Optional
a. This attribute specifies the destination DN or dialing
number. It is:
Mandatory if routing was done by URS (or another
routing application connected to T-Server).
Absent if the call was rejected.
Optional in other cases.
b. The OtherDN attribute is used to specify the target party
when the forward feature is in progress.
c. These attributes must be equal.
Table 26: EventRouteUsed Contents (Continued)
T-Server Client
EventRouteRequest
TRouteCall
EventRouteUsed
Switch
CallAppearedOnRoutingPoint
RouteCallToDestination
CallLeftRoutingPoint
68 Genesys
Chapter 1: T-Library Events Call-Treatment Events
Figure 13: EventRouteRequest and EventRouteUsed Feature, Example 2
(if the Routing Timeout Expires Before the TRouteCall Request
Generated by Computer Domain [Interaction Router])
Call-Treatment Events
EventTreatmentApplied
Event Description
The call has been treated, and the Treatment Device (TD) is processing the
treatment instruction.
Event Contents
T-Server Client
EventRouteRequest
EventRouteUsed
Switch
CallAppearedOnRoutingPoint
CallLeftRoutingPoint
Table 27: EventTreatmentApplied Contents
CallID Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Mandatory
Event Mandatory
Extensions Mandatory
EventTreatmentEnd
Event Description
The call has been treated and the Treatment Device (TD) is waiting for another
instruction.
Note: This event does not appear in cases of continuing treatments like
Silence or RingBack.
Event Contents
Reasons Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
TransferConnID Optional
TreatmentParameters Optional
TreatmentType Mandatory
UserData Optional
Table 27: EventTreatmentApplied Contents (Continued)
Table 28: EventTreatmentEnd Contents
CallID Mandatory
CallType Mandatory
70 Genesys
CollectedDigits
a
Optional
ConnID Mandatory
Event Mandatory
Extensions
b
Optional
LastCollectedDigit
a
Optional
Reasons Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
UserData Optional
a. The attributes are present if TreatmentType is either CollectDigits or
PlayAnnouncementAndCollectDigits.
Table 28: EventTreatmentEnd Contents (Continued)
EventTreatmentNotApplied
Event Description
The call has not been treated for some reason. The reason is returned in
ErrorCode and ErrorMessage parameters.
Event Contents
b. The following key-value pairs are set for all Treatment Types,
except in the case of the Nortel Communication Server
2000/2100 (formerly, DMS-100):
For all Treatment Types where an announcement was played,
INTERRUPTED is set to:
NO, if the announcement was not interrupted.
KEYPAD, if it was interrupted by keypad entry.
VOICE, if it was interrupted by the caller speaking something.
For all Treatment Types where digits are to be collected from the
caller, COMPLETION_STATUS is set to:
NORMAL, if the treatment completed normally (optional).
TIMEOUT, if the digit collection timed out before all required dig-
its could be collected.
CANCELLED, if the treatment was cancelled by a request from rout-
er.
For TreatmentType=DigitsVerification only, the following key-
value pairs apply:
VERIFICATION_STATUS (the result of digits verification) is set to 1 if
verification succeed, 0 if it did not.
ATTEMPTS is set to the number of digit-collection attempts made.
For TreatmentType=RecordUserAnnouncement, the following key-
value pair applies:
USER_ANN_ID is set to the message identifier, an integer, recorded
by the user specified with USER_ID.
Table 29: EventTreatmentNotApplied Contents
CallID Mandatory
CallType Mandatory
ConnID Mandatory
72 Genesys
EventTreatmentRequired
Event Description
A call has been placed to a treatment device port specified by ThisDN, and the
switch or the treatment device is waiting for treatment instructions.
ErrorCode Mandatory
Event Mandatory
Extensions Optional
Reasons Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
UserData Optional
Table 29: EventTreatmentNotApplied Contents (Continued)
Chapter 1: T-Library Events DTMF Events
Event Contents
DTMF Events
EventDigitsCollected
Event Description
The digits specified by CollectedDigits have been collected. This event is sent
either to the DN representing the device collecting the digits or to all
monitored parties for the call.
Table 30: EventTreatmentRequired Contents
ANI Optional
CallID Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Mandatory
Event Mandatory
Extensions Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
UserData Optional
74 Genesys
Event Contents
Table 31: EventDigitsCollected Contents
CallID Mandatory
CallState Mandatory
CallType Mandatory
CollectedDigits Mandatory
ConnID Mandatory
CustomerID Optional
Event Mandatory
Extensions Optional
OtherDN
a
Optional
OtherQueue Optional
Reasons Optional
Server Mandatory
ThisDN Mandatory
ThisTrunk Optional
time Mandatory
EventDTMFSent
Event Description
The specified DTMF sequence has been sent.
Event Contents
UserData Optional
a. This attribute indicates the source of the collected dig-
its, if T-Server can identify that source.
Table 31: EventDigitsCollected Contents (Continued)
Table 32: EventDTMFSent Contents
ANI Optional
CallID Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
Reasons Optional
Server Mandatory
76 Genesys
Chapter 1: T-Library Events Voice-Mail Events
Voice-Mail Events
EventMailBoxLogin
Event Description
The telephony object specified by ThisDN has logged in to the mailbox
specified by the mbox_number parameter in the corresponding TLoginMailBox()
function.
Event Contents
ThisDN Mandatory
ThisTrunk Optional
time Mandatory
UserData Optional
Table 32: EventDTMFSent Contents (Continued)
Table 33: EventMailBoxLogin Contents
CustomerID Optional
Event Mandatory
Reasons Optional
Server Mandatory
ThisDN Mandatory
Example
Figure 14: Voice-Processing Feature Example
time Mandatory
Extensions Optional
Table 33: EventMailBoxLogin Contents (Continued)
T-Server Client
TLoginMailbox
EventMailBoxLogin
TOpenVoiceFile
EventVoiceFileOpened
TPlayVoiceFile
EventVoiceFileEndPlay
TCollectDigits
EventDigitsCollected
.
.
.
TMuteTransfer
TLogoutMailbox
EventMailBoxLogout
TCloseVoiceFile
EventVoiceFileClosed
Application Unregistration Phase
Call Processing Phase
Application Registration Phase
78 Genesys
EventMailBoxLogout
Event Description
The telephony object specified by ThisDN has logged out of the mailbox it
logged in to earlier.
Event Contents
Example
See Figure 14 on page 77.
EventVoiceFileOpened
Event Description
The voice file specified by the file_handle parameter in the corresponding
TOpenVoiceFile() function has been opened.
Table 34: EventMailBoxLogout Contents
CustomerID Optional
Event Mandatory
Reasons Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
Extensions Optional
Event Contents
Example
EventVoiceFileClosed
Event Description
TCloseVoiceFile() function has been closed.
Event Contents
Table 35: EventVoiceFileOpened Contents
CustomerID Optional
Event Mandatory
Extensions Optional
FileHandle Mandatory
Reasons Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
UserData Optional
Table 36: EventVoiceFileClosed Contents
CustomerID Optional
Event Mandatory
80 Genesys
Example
EventVoiceFileEndPlay
Event Description
TPlayVoice() function has been played back completely.
Event Contents
Extensions Optional
Reasons Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
UserData Optional
Table 36: EventVoiceFileClosed Contents (Continued)
Table 37: EventVoiceFileEndPlay Contents
CallID Mandatory
CallState Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
Event Mandatory
Extensions Optional
Chapter 1: T-Library Events Agent-State & DN Events
Example
Agent-State & DN Events
EventAgentLogin
Event Description
The agent has logged in to the ACD group specified by ThisQueue.
Note: Multiple agent logins are allowed for the same DN and agent ID
combination (since EventAgentLogin does not indicate by itself a
transition of agent state).
FileHandle Mandatory
Reasons Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
UserData Optional
Table 37: EventVoiceFileEndPlay Contents (Continued)
82 Genesys
Event Contents
Example
Figure 15: EventAgentLogin Feature Example
Table 38: EventAgentLogin Contents
AgentID
a
a. AgentID must be present if the agent is logged in
through T-Server or if the information is available.
Optional
CustomerID Optional
Event Mandatory
Reasons Optional
Server Mandatory
ThisDN Mandatory
ThisQueue Optional
time Mandatory
WorkMode Optional
Extensions
b
b. If present, the Extensions attribute may include a Rea-
sonCode value specifically used to communicate hard-
ware reasons.
Optional
T-Server Client
TAgentLogin
EventAgentLogin
EventAgentReady or
EventAgentNotReady
EventAgentLogout
Event Description
The agent has logged out of the ACD group specified by ThisQueue.
Note: With CTI platforms that support agent login for multiple queues, this
event signals that the agent has been moved to the Logged Out state,
and is thus used only for an agents final logout. (EventQueueLogout,
on the other hand, indicates that an agent remains logged in to some
other ACD queue. See EventQueueLogout on page 84.)
Event Contents
Table 39: EventAgentLogout Contents
Event Mandatory
Server Mandatory
CustomerID Optional
AgentID
a
a. AgentID must be present if the agent is logged out
Optional
ThisDN Mandatory
ThisQueue Optional
Reasons Optional
time Mandatory
Extensions
b
ware reasons.
Optional
84 Genesys
Examples
Figure 16: EventAgentLogout (Through Link) Feature, Example 1
Figure 17: EventAgentLogout (Through PhoneSet) Feature, Example 2
EventQueueLogout
Event Description
The agent has logged out of the ACD queue specified by ThisQueue, but
remains logged in to some other ACD queue.
Event Contents
T-Server Client
TAgentLogout
EventAgentLogout
T-Server Client
EventAgentLogout
AgentLoggedOut
Switch
Table 40: EventQueueLogout Contents
Event Mandatory
Server Mandatory
CustomerID Optional
AgentID
a
Optional
ThisDN Mandatory
EventAgentReady
Event Description
The agent is ready to receive ACD calls.
Event Contents
ThisQueue Optional
Reasons Optional
time Mandatory
Extensions
b
Optional
a. AgentID must be present if the agent is logged out
ware reasons.
Table 40: EventQueueLogout Contents (Continued)
Table 41: EventAgentReady Contents
AgentID
a
Optional
CustomerID Optional
Event Mandatory
Reasons Optional
Server Mandatory
ThisDN Mandatory
ThisQueue Optional
time Mandatory
86 Genesys
Examples
Figure 18: EventAgentReady (Through Link) Feature, Example 1
Figure 19: EventAgentReady (Through PhoneSet) Feature, Example 2
EventAgentNotReady
Event Description
The agent is not ready to receive ACD calls.
WorkMode
b
Mandatory
Extensions
c
Optional
a. AgentID must be present if the agent-state change is re-
quested through T-Server or if the information is
available.
b. WorkMode is mandatory for the Avaya Communication
Manager T-Server when not in Soft Agent mode.
c. If present, the Extensions attribute may include a Rea-
ware reasons.
Table 41: EventAgentReady Contents (Continued)
T-Server Client
TAgentSetReady
EventAgentReady
T-Server Client
EventAgentReady
AgentReady
Switch
Event Contents
Table 42: EventAgentNotReady Contents
AgentID
a
a. AgentID must be present if the agent-state change is re-
quested through T-Server or if the information is
available.
Optional
CustomerID Optional
Event Mandatory
Reasons Optional
Server Mandatory
ThisDN Mandatory
ThisQueue Optional
time Mandatory
WorkMode
b
b. This attribute is mandatory for the Avaya Communi-
cation Manager T-Server when not in Soft Agent
mode.
Optional
Extensions
c
c. If present, the Extensions attribute may include a Rea-
ware reasons.
Optional
88 Genesys
Examples
Figure 20: EventAgentNotReady (Through Link) Feature, Example 1
Figure 21: EventAgentNotReady (Through PhoneSet) Feature, Example 2
Figure 22: EventAgentNotReady Feature, Example 3 (for the Nortel
Communication Server 2000/2100 (formerly, DMS-100) only)
Note: A timeout in Figure 22 (*) is specified as the wrap-up time in the
Configuration Layer. T-Server distributes EventAgentReady
automatically if there is no activity on the DN that can be considered
an agent-state change within the specified timeout. See also
EventAgentLogin on page 81.
T-Server Client
TAgentSetNotReady
EventAgentNotReady
T-Server Client
EventAgentNotReady
AgentNotReady
Switch
T-Server Client
EventAgentNotReady
Released
Switch
EventAgentReady
timeout*
EventAgentAfterCallWork (ObsoleteNo Longer Supported)
Event Description
The agent is performing administrative duties for a previous call (that is,
updating some information) and, therefore, is not ready to receive further ACD
calls.
EventAgentIdleReasonSet (ObsoleteNo Longer Supported)
Event Description
Indicates that the Idle reason for the telephony object specified by the
parameter ThisDN has been successfully set.
Event Contents
Table 43: EventAgentIdleReasonSet Contents
AgentID Optional
CustomerID Optional
Event Mandatory
Reasons Optional
Server Mandatory
ThisDN Mandatory
ThisQueue Optional
time Mandatory
Extensions Optional
90 Genesys
EventDNOutOfService
Event Description
The DN specified in the ThisDN attribute is out of service and cannot make or
receive calls. This event is generated when an out-of-service state is first
detected or when a new client registers on a DN known to be out of service.
When a DN is out of service, only the following T-Library requests can be
issued for it: client registration and unregistration, queries, agent login, and
private service requests.
Note: T-Server returns a TERR_OUT_OF_SERVICE error if it is called on to
attempt a supported operation that cannot progress on an out-of-service
DN.
When a DN goes out of service, T-Server notifies the user about the
termination of active calls or changes an agent state (not ready/logout) using
normal T-Library events. The other applications should rely only on those
events to change the DN/agent state.
Event Contents
Example
See EventDNBackInService.
EventDNBackInService
Event Description
The DN specified in the ThisDN attribute is back in service and can make or
receive calls. This event is generated when a DN, which has been out of
service and for which the EventDNOutOfService was previously distributed,
returns to service.
Table 44: EventDNOutOfService Contents
ThisDN Mandatory
Extensions Optional
In the absence of EventDNOutOfService and EventDNBackInService, all clients
should assume, for backward-compatibility reasons, that the DN is in service.
Event Contents
Example
Figure 23: EventDNBackInService Feature Example
Note: Between EventDNOutOfService and EventDNBackInService, the client is
not able to perform any requests, and no events should be expected
during this outage. Genesys recommends that you perform
TQueryAddress() after EventDNBackInService to ensure synchronization
between T-Server and client.
EventDNDOn
Event Description
The Do-Not-Disturb (DND) feature has been turned on for the telephony
object specified by ThisDN.
Table 45: EventDNBackInService Contents
ThisDN Mandatory
Extensions Optional
T-Server
EventDNOutOfService
Client
EventDNBackInService
92 Genesys
Event Contents
Examples
Figure 24: EventDNDOn (Through Link) Feature, Example 1
Figure 25: EventDNDOn (Through PhoneSet) Feature, Example 2
Table 46: EventDNDOn Contents
CustomerID Optional
Event Mandatory
Reasons Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
Extensions Optional
T-Server Client
TSetDNDOn
EventDNDOn
T-Server Client
EventDNDOn
DNDOn
Switch
EventDNDOff
Event Description
The Do-Not-Disturb (DND) feature has been turned off for the telephony
object specified by ThisDN.
Event Contents
Examples
Figure 26: EventDNDOff (Through Link) Feature, Example 1
Table 47: EventDNDOff Contents
CustomerID Optional
Event Mandatory
Reasons Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
Extensions Optional
T-Server Client
TSetDNDOff
EventDNDOff
94 Genesys
Figure 27: EventDNDOff (Through PhoneSet) Feature, Example 2
EventForwardSet
Event Description
The Forwarding feature has been turned on for the telephony object specified
by ThisDN.
Event Contents
T-Server Client
EventDNDOff
DNDOff
Switch
Table 48: EventForwardSet Contents
CustomerID Optional
Event Mandatory
Extensions Optional
InfoStatus (CallForwardingStatus,
SendAllCallsStatus)
Optional
OtherDN
a
a. The OtherDN attribute is used to specify the target party
when the Forward feature is in progress.
Optional
Reasons Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
ForwardMode Optional
Examples
Figure 28: EventForwardSet (Through Link) Feature, Example 1
Figure 29: EventForwardSet (Through PhoneSet) Feature, Example 2
EventForwardCancel
Event Description
The Forwarding feature has been turned off for the telephony object specified
by ThisDN.
Event Contents
T-Server Client
TCallSetForward
EventForwardSet
T-Server Client
EventForwardSet
ForwardSet
Switch
Table 49: EventForwardCancel Contents
CustomerID Optional
Event Mandatory
Extensions Optional
Reasons Optional
Server Mandatory
96 Genesys
Examples
Figure 30: EventForwardCancel (Through Link) Feature, Example 1
Figure 31: EventForwardCancel (Through PhoneSet) Feature, Example 2
EventMonitoringNextCall
Event Description
A request to monitor the next call(s) has been accepted. The event is delivered
to the applications on the supervisors and agents desktops.
Note: A supervisor who monitors calls as a result of the request
TMonitorNextCall() is able to hear and participate in conversations on
the monitored DN. If it is necessary to receive events associated with
conversations, the supervisors soft phone must be registered with the
various DNs that might be monitored.
ThisDN Mandatory
time Mandatory
Table 49: EventForwardCancel Contents (Continued)
T-Server Client
TCallCancelForward
EventForwardCancel
T-Server Client
EventForwardCancel
ForwardCancel
Switch
Event Contents
Example
See EventMonitoringCancelled.
EventMonitoringCancelled
Event Description
The call monitoring has been canceled either by a separate call to the
TMonitorNextCall() function or to the TCancelMonitoring() function. The
event is delivered to the applications on the supervisor's and agents desktops.
Table 50: EventMonitoringNextCall Contents
ThisDN
a
a. When the event is delivered to an application on the su-
pervisors desktop, ThisDN is set to the supervisors DN
and ThisDNRole is set to DNRoleObserver. When the
event is delivered to an application on the agents desk-
top, ThisDN is set to the agents DN and ThisDNRole is
set to DNRoleDestination.
Mandatory
ThisDNRole
a
Mandatory
OtherDN
b
b. When the event is delivered to an application on the su-
pervisors desktop, OtherDN is set to the agents DN and
OtherDNRole is set to DNRoleDestination. When the
top, OtherDN is set to the supervisors DN and OtherDN-
Role is set to DNRoleObserver.
Mandatory
OtherDNRole
b
Mandatory
MonitorNextCallType Mandatory
Reasons Optional
Extensions Optional
98 Genesys
Event Contents
Table 51: EventMonitoringCancelled Contents
ThisDN
a
a. When the event is delivered to an application on the su-
pervisors desktop, ThisDN is set to the supervisors DN
and ThisDNRole is set to DNRoleObserver. When the
top, ThisDN is set to the agents DN and ThisDNRole is
set to DNRoleDestination.
Mandatory
ThisDNRole
a
Mandatory
OtherDN
b
b. When the event is delivered to an application on the su-
pervisors desktop, OtherDN is set to the agents DN and
OtherDNRole is set to DNRoleDestination. When the
top, OtherDN is set to the supervisors DN and OtherDN-
Role is set to DNRoleObserver.
Mandatory
OtherDNRole
b
Mandatory
Reasons Optional
Extensions Optional
Example
Figure 32: EventMonitoringCancelled Feature Example
EventOffHook
Event Description
The telephony object specified by ThisDN has gone off-hook.
Event Contents
T-Server
EventMonitoringNextCall
Client
EventMonitoringCancelled
TMonitorNextCall
TCancelMonitoring
Unless only one call is
designated for monitoring,
the supervisor monitors
the selected DN until
TCancelMonitoring is
requested.
Table 52: EventOffHook Contents
AgentID Optional
CallID Optional
CallState Optional
CallType Optional
ConnID Optional
CustomerID Optional
100 Genesys
EventOnHook
Event Description
The telephony object specified by ThisDN has gone on-hook.
Event Contents
Event Mandatory
Extensions Optional
Server Mandatory
ThisDN Mandatory
ThisTrunk Optional
time Mandatory
UserData Optional
Table 52: EventOffHook Contents (Continued)
Table 53: EventOnHook Contents
AgentID Optional
CallID Optional
ConnID Optional
CustomerID Optional
Event Mandatory
EventMuteOn
Event Description
A party identified by ThisDN is now in the Mute mode.
Event Contents
Extensions Optional
Server Mandatory
ThisDN Mandatory
ThisDNRole Optional
ThisTrunk Optional
time Mandatory
UserData Optional
Table 53: EventOnHook Contents (Continued)
Table 54: EventMuteOn Contents
ConnID Mandatory
CustomerID Optional
Extensions Optional
Reasons Optional
102 Genesys
EventMuteOff
Event Description
A party identified by ThisDN is no longer in Mute (microphone-disabled) mode.
The ReferenceID attribute is set to indicate the corresponding TSetMuteOff()
function.
Event Contents
ThisDN Mandatory
UserData Optional
Table 54: EventMuteOn Contents (Continued)
Table 55: EventMuteOff Contents
ConnID Mandatory
CustomerID Optional
Reasons Optional
Extensions Optional
ThisDN Mandatory
EventListenDisconnected
Event Description
The switch has registered Deaf mode for the specified telephony object (in
OtherDN).
Event Contents
UserData Optional
Table 55: EventMuteOff Contents (Continued)
Table 56: EventListenDisconnected Contents
CallID Mandatory
CallState
a
Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
Event Mandatory
Extensions Optional
OtherDN
b
Mandatory
OtherQueue Optional
OtherTrunk Optional
104 Genesys
EventListenReconnected
Event Description
The switch has canceled Deaf mode for the specified telephony object.
Reasons Optional
Server Mandatory
ThirdPartyDN
c
Mandatory
ThisDN
d
Mandatory
ThisQueue Optional
ThisTrunk Optional
time Mandatory
UserData Optional
a. The following CallStates are used:
CallStateOk: the party can still participate in conver-
sation with some active members of the conference.
CallStateDeafened: the party cannot listen to the con-
versation, but can be heard by the conference mem-
bers.
CallStateHeld: the party cannot hear or be heard by
the conference members.
b. Applies to the disconnected party.
c. The party that cannot be heard by the disconnected
party.
d. The party that initiated the request.
Table 56: EventListenDisconnected Contents (Continued)
Event Contents
Table 57: EventListenReconnected Contents
CallID Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
Event Mandatory
Extensions Optional
OtherDN
a
Mandatory
OtherQueue Optional
OtherTrunk Optional
Reasons Optional
Server Mandatory
ThirdPartyDN
b
Optional
ThisDN
c
Mandatory
ThisQueue Optional
ThisTrunk Optional
time Mandatory
106 Genesys
EventMessageWaitingOn
Event Description
The Waiting indicator has been turned on for the telephony object specified by
ThisDN.
Event Contents
UserData Optional
a. The reconnected party.
b. The party that is heard by the reconnected party.
c. The party that initiated the request.
Table 57: EventListenReconnected Contents (Continued)
Table 58: EventMessageWaitingOn Contents
CustomerID Optional
Event Mandatory
Extensions Optional
Reasons Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
Examples
Figure 33: EventMessageWaitingOn (Through Link) Feature, Example 1
Figure 34: EventMessageWaitingOn (Through PhoneSet) Feature,
Example 2
EventMessageWaitingOff
Event Description
The Waiting indicator has been turned off for the telephony object specified by
ThisDN.
Event Contents
T-Server Client
TSetMessageWaitingOn
T-Server Client
MessageWaitingOn
Switch
Table 59: EventMessageWaitingOff Contents
CustomerID Optional
Event Mandatory
Reasons Optional
Server Mandatory
108 Genesys
Chapter 1: T-Library Events Query Events
Examples
Figure 35: EventMessageWaitingOff (Through Link) Feature, Example 1
Figure 36: EventMessageWaitingOff (Through PhoneSet) Feature,
Example 2
Query Events
EventAddressInfo
Event Description
This event is generated as a response to the TQueryAddress() function and
includes information specified by InfoType and InfoStatus about the telephony
object specified by either ThisDN or ThisQueue.
ThisDN Mandatory
time Mandatory
Extensions Optional
Table 59: EventMessageWaitingOff Contents (Continued)
T-Server Client
TSetMessageWaitingOff
T-Server Client
MessageWaitingOff
Switch
Event Contents
Table 60: EventAddressInfo Contents
AgentID
a
a. The AgentID attribute can only be present for objects of Ad-
dressTypePosition or AddressTypeDN.
Optional
CallID Optional
ConnID
b
Optional
CustomerID Optional
Event Mandatory
Extensions
c
Optional
InfoStatus Mandatory
InfoType
c
Mandatory
PreviousConnID
b
Optional
Reasons
d
Optional
Server Mandatory
ThisDN Mandatory
ThisQueue Optional
time Mandatory
UserData Optional
110 Genesys
b. The ConnID and PreviousConnID attributes are mandatory
when the InfoType parameter is set to AddressInfoCallsQue-
ry. ConnID is the connection ID for the active call; Previ-
ousConnID is the connection ID for the held call, if any.
c. Based on the InfoType value, additional information is pro-
vided in the InfoStatus, which is a union element, and in
Extensions attributes. See Table 61 for InfoType=AddressIn-
foQueueStatus and AddressInfoDNStatus, which are available
on all T-Servers. See Table 62 on page 113 for all other In-
foTypes that are available on a device-specific basis. If a par-
ticular InfoType is not supported, T-Server responds with
EventError.
d. If present, the value here is the last known KVList data sup-
plied by recent activity for this address.
Table 61: InfoStatus and Extensions in EventAddressInfo
Available for All T-Servers
Attribute InfoStatus Attribute Extensions
Key Value
Type
Value Description
InfoType=AddressInfoQueueStatus
NumberOfCalls
a
conn-%d string The connection ID of a call (converted into
a string)
ct-%d integer The CallType for the corresponding
ConnectionID
mt-%d integer The media type of the corresponding
ConnectionID. (The value may be absent
here if the media type is voice.
b
)
0 (or absent) if voice
>0 for non-voice media
ps-%d integer The Call-Party state for the corresponding
Connection ID. See Unified Call-Party
States on page 139 for more details.
status integer The DN status
c
InfoType=AddressInfoDNStatus
NumberOfCalls
a
conn-%d string The connection ID of a call (converted into
a string)
connection ID
mt-%d integer The media type of the corresponding
connection ID. (The value may be absent
here if the media type is voice.
b)
0 (or absent) if voice
>0 for non-voice media
ps-%d integer The Call-Party state for the corresponding
Connection ID. See Unified Call-Party
States on page 139 for more details.
queue-%d string The enumerated queues associated with an
agent logged into a DN
AgentStatus integer The Agent status
d
status integer The DN status
c
dnd integer Do Not Disturb status
e
Not present if T-Server has no information
about the DND status
fwd string Specifies forwarding targets based on
corresponding conditions.
f
about Forward status
mwl integer Message Waiting Lamp status
g
about MWL status
a. The information is based on what T-Server can provide; it may be inaccurate when T-Server is not in sync
with the switch. It is possible for T-Server to return a non-error message with missing parameters in re-
sponse to a request regarding an incorrectly configured DN or queried DN.
Available for All T-Servers (Continued)
Key Value
Type
Value Description
112 Genesys
b. Client applications should set this value to 0 (zero) if it is absent in the event. This insures that the media
type is understood to be voice.
c. The following are the DN statuses:
<0 (UNKNOWN): there is no available information about the DN status.
0 (IDLE): there is no activity on the DN.
>0 (NOT_IDLE): there is some activity on the DNthere is at least one call on the DN or the device is off-
hook. Note the following special values:
0x80: DN is out of service.
0xC0: DN is undergoing maintenance.
0x90: Device associated with DN is locked out.
0x88: DN is vacant.
d. The following are the Agent statuses:
<0 (UNKNOWN): the status of an agent is unknown.
0 (LOGGED_OUT): there is no agent logged on this DN.
1 (LOGGED_IN): an agent is logged in but work mode is unknown.
2 (READY): the status of agent is Ready.
3 (NOT_READY): the status of agent is NotReady.
4 (ACW): the status of agent is AfterCallWork.
5 (WALK_AWAY): the status of agent is WalkAway.
Note: The AgentStatus Extensions key is delivered only for objects with an Address type of AddressTypePosi-
tion or AddressTypeDN.
e. The following are the DND statuses:
0: DND off
1: DND on
f. Possible values are:
off, on, or the designated destination DN (for unconditional forwarding), or the designated destinationDN
list (with conditions for forwarding). The following conditions may be used:
OnBusy, OnNoAnswer, OnBusyAndNoAnswer, SendAllCalls.
Examples:
1. Unconditional Destination DN: 3000
2. Conditions with Destination-DN list: OnBusy:1000 OnNoAnswer:2000 (This forwards calls to two different
DNs based on certain conditions being met.)
g. The following are the MWL statuses:
0: MWL off
1: MWL on
Available for Particular T-Servers
Key Value
Type
Value Description
InfoType=AddressInfoAddressStatus
AddressStatus
InfoType=AddressInfoMessageWaitingStatus
MsgWaitingStatus
InfoType=AddressInfoAssociationStatus
AssociationStatus
InfoType=AddressInfoCallForwardingStatus
CallForwardingStatus
InfoType=AddressInfoAgentStatus
AgentStatus
InfoType=AddressInfoNumberOfAgentsInQueue
NumberOfAgentsInQueue AgentsInQueue integer Requested number is returned in
AddressInfoStatus attribute; in addition,
the Extensions attribute contains all of
three keys
AvailableAgents integer
CallsInQueue integer
InfoType=AddressInfoNumberOfAvailableAgentsInQueue
NumberOfAvailable-
AgentsInQueue
AgentsInQueue integer Requested number is returned in
three keys
InfoType=AddressInfoNumberOfCallsInQueue
NumberOfCallsInQueue AgentsInQueue integer Requested number is returned in
three keys
InfoType=AddressInfoAddressType
114 Genesys
AddressType
InfoType=AddressInfoCallsQuery
NumberOfListElements call-%d integer The Call ID of a call
conn-%d string The Connection ID of a call (converted
into a string)
state-%d integer The state of the DN in question as a party
of the call. See AddressStatusInfoType in
the Voice Platform SDK API Reference for
details.
InfoType=AddressInfoQueueLoginAudit
NumberOfListElements agent-extension string The agent ID
InfoType=AddressInfoNumberOfIdleClassifiers
NumberOfIdleClassifiers Idle integer NumberOfIdleClassifiers
InUse integer NumberOfClassifiersInUse
InfoType=AddressInfoNumberOfClassifiersInUse
NumberOfClassifiersInUse Idle integer NumberOfIdleClassifiers
InfoType=AddressInfoNumberOfIdleTrunks
NumberOfIdleTrunks Idle integer NumberOfIdleTrunks
InUse integer NumberOfTrunksInUse
InfoType=AddressInfoNumberOfTrunksInUse
NumberOfTrunksInUse Idle integer NumberOfIdleTrunks
InUse integer NumberOfTrunksInUse
InfoType=AddressInfoDatabaseValue
ID string A database value
Available for Particular T-Servers (Continued)
Key Value
Type
Value Description
Example
Figure 37: EventAddressInfo Feature Example
EventPartyInfo
Event Description
The information about the call specified by ConnID. T-Server returns
EventPartyInfo only to the client that issued a call to the TQueryCall()
function.
Event Contents
T-Server Client
TQueryAddress
EventAddressInfo
Table 63: EventPartyInfo Contents
ANI Optional
CallID Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions
a
Mandatory
InfoStatus.NumberOfListElements
b
Mandatory
116 Genesys
OtherDN
c
Optional
OtherDNRole
c
Optional
PreviousConnID
d
Optional
Server Mandatory
ThisDN
e
Optional
ThisDNRole
e
Optional
ThisTrunk Optional
time Mandatory
UserData Optional
a. The directory numbers of parties participating in the call specified
by ConnID are specified as key-value pairs with the key party-<n>
in the Extensions attribute, where <n> is the party number. Some
switches might not report a Queue or a Routing Point as a call par-
ty.
b. This attribute consists of the number of known parties participat-
ing in a call.
c. T-Server returns the OtherDN and OtherDNRole attributes if the con-
dition described in Table Footnote a. takes place, and the number
of parties involved in the call specified by ConnID is 2.
d. The attribute must appear if the value of CallType is Consult.
e. T-Server returns the ThisDN and ThisDNRole attributes if the party
specified as a DN in the TQueryCall() request is a call member.
Table 63: EventPartyInfo Contents (Continued)
Example
Figure 38: EventPartyInfo Feature Example
EventLocationInfo
Event Description
This event is generated as a response to the TQueryLocation() function and
includes information specified by InfoType about the remote location specified
by the Location parameter.
Event Contents
T-Server Client
TQueryCall
EventPartyInfo
Table 64: EventLocationInfo Contents
Event Mandatory
Extensions Optional
InfoType Mandatory
Location Optional
Server Mandatory
time Mandatory
118 Genesys
Additional information based on InfoType is provided in the Extensions
attributes. When information is requested about one remote location, the
Extensions attribute can contain the following key-value pairs:
When information is requested about more than one location, these same key-
value pairs for each location are referred to in the loc-list[i] value of the LQ-
location-%d key within the Extensions attribute, where i is the number of a
remote location (i=0 defines the first location).
Table 65: Extensions in EventLocationInfo
Key Value Value Type
LQ-location-name location string
LQ-location-status loc-status,
0 - disconnected (configured)
1 - connected
integer
LQ-link-status link-status,
0 - disconnected
1 - connected
integer
Table 66: InfoType and Extensions in EventLocationInfo
InfoType=LocationInfoAllLocations or
InfoType=LocationInfoMonitorAllLocations
LQ-location-%d loc-list[i] kv-list
InfoType=LocationInfoLocationData or
InfoType=LocationInfoMonitorLocation
LQ-location-name location string
LQ-location-status loc-status,
0 - disconnected (configured)
1 - connected
integer
LQ-link-status link-status,
0 - disconnected
1 - connected
integer
EventServerInfo
Event Description
Delivers the information about T-Server specified in ServerVersion,
ServerRole, and Capabilities.
Event Contents
Table 67: EventServerInfo Contents
Capabilities Mandatory
CustomerID Optional
Event Mandatory
Extensions
a
a. See Extensions in EventServerInfo on page 120 for
details.
When related to information about a T-Servers ability
to support transaction monitoring, this attribute indi-
cates that support, and its key-value pairs contain in-
formation about the supported transaction monitoring
classes. (For transaction monitoring purposes, this at-
tribute is not present when the T-Server in question
does not support that feature.)
Mandatory
HomeLocation Optional
Server Mandatory
ServerRole Mandatory
ServerVersion Mandatory
time Mandatory
ServerCapabilityMask Mandatory
b
b. If the capability mask includes TransactionMonitoring
and EventTransactionStatus, the T-Server in question
supports transaction monitoring.
120 Genesys
Example
Figure 39: EventServerInfo Feature Example
EventSwitchInfo
Event Description
This event is generated as a response to the TQuerySwitch() function and
includes the requested information.
Event Contents
Table 68: Extensions in EventServerInfo
T-Server The full string designating information about
the current version of T-Server (the same as
if T-Server has been started with the -V
command line option)
string
Features The list of features with which T-Server is
built (the same list as that which results from
T-Server being started with the -V command
line option)
string
T-Server Client
TQueryServer
EventServerInfo
Table 69: EventSwitchInfo Contents
CustomerID Optional
Event Mandatory
Chapter 1: T-Library Events User-Data Events
User-Data Events
EventAttachedDataChanged
Event Description
The attached data for the call has been changed.
Reasons Optional
Server Mandatory
time Mandatory
Table 69: EventSwitchInfo Contents (Continued)
Table 70: Extensions in EventSwitchInfo
InfoStatus Attribute Extensions
Key Value
Type
Value Description
SwitchInfoDataTime Date/Time string Current date and time information on the switch
in the MM/DD/YYYY HH:MM:SS format
SwitchInfoClassifierStat Idle integer NumberOfIdleClassifiers
122 Genesys
Chapter 1: T-Library Events User-Data Events
Event Contents
Table 71: EventAttachedDataChanged Contents
ANI Optional
CallID Mandatory
CallType Mandatory
ConnID Mandatory
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
Server Mandatory
ThirdPartyDN
a
a. The ThirdPartyDN attribute is used to identify who ini-
tiated a change in user data. It is mandatory if it can be
specified.
Optional
ThisDN Optional
ThisDNRole Optional
ThisTrunk Optional
time Mandatory
UserData Mandatory
Chapter 1: T-Library Events ISCC Events
ISCC Events
EventAnswerAccessNumber
Event Description
T-Server has processed a previously called TGetAccessNumber() function and
has returned the requested access number.
Event Contents
Examples
Figure 40: EventAnswerAccessNumber when GetAccessNumber
Does Not Contain AttributeLocation
Table 72: EventAnswerAccessNumber Contents
AccessNumber Mandatory
ThisDN Mandatory
ConnID Mandatory
Event Mandatory
Server Mandatory
time Mandatory
Extensions Optional
T-Server Client
TGetAccessNumber
124 Genesys
Figure 41: EventAnswerAccessNumber when TGetAccessNumber
Contains AttributeLocation
Note: In Figure 41 T-Server A acts as an origination, and T-Server B a
destination T-Server.
EventRemoteConnectionSuccess
Event Description
The call has successfully reached the remote switch.
Event Contents
T-Server A Client
TGetAccessNumber
XRGetAccessNumber
T-Server B
XREventAnswerAccessNumber
Table 73: EventRemoteConnectionSuccess Contents
ConnID Mandatory
CustomerID Optional
Event Mandatory
Extensions Optional
Server Mandatory
ThisDN Mandatory
time Mandatory
EventRemoteConnectionFailed
Event Description
The call failed to reach the remote switch or could not be treated as successful
(for example, ISCC could not route the call to a requested destination DN).
Event Contents
EventReqGetAccessNumberCanceled
Event Description
T-Server has canceled a previously called TGetAccessNumber() function before
processing is complete.
Table 74: EventRemoteConnectionFailed Contents
ConnID Mandatory
CustomerID Optional
Event Mandatory
Server Mandatory
time Mandatory
ThisDN Mandatory
Extensions Optional
126 Genesys
Chapter 1: T-Library Events Special Events
Event Contents
Special Events
EventACK
Event Description
T-Server has acknowledged a request received from a client application. This
event is a response to the TSendUserEvent(), TSendEvent(), TSendEventEx(),
TSetInputMask(), TTransactionMonitoring(), and TPrivateSevice()
functions.
Event Contents
Table 75: EventReqGetAccessNumberCanceled
Contents
Event Mandatory
Server Mandatory
time Mandatory
XReferenceID Mandatory
Extensions Optional
Table 76: EventACK Contents
Event Mandatory
Server Mandatory
time Mandatory
Examples
Figure 42: EventACK Feature, Example 1
Figure 43: EventACK Feature, Example 2
UserEvent
a
Optional
Extensions Optional
SubscriptionID Optional
b
a. UserEvent is the identifier of the request that has
caused T-Server to generate EventACK. The attribute is
derived from the request.
b. This attribute, applicable only to EventACK in response
to TTransactionMonitoring(), is mandatory for the op-
eration SubscriptionStart, but is not present for the
operations SubscriptionStop and SubscriptionModify.
This attribute represents a subscription identifier: the
call has successfully reached the remote switch.
Table 76: EventACK Contents (Continued)
T-Server Client 1
TSendUserEvent
EventACK
Client 2
EventUserEvent
T-Server Client
TSetInputMask
EventACK
128 Genesys
EventAgentReserved
Event Description
This event is generated as a positive response to the TReserveAgent() request,
confirming that those of the parameters agent_dn, agent_id, and agent_place
that were present in the request have been successfully reserved. When an
agent becomes reserved as the result of TReserveAgent() request, the event is
sent to the application that sent the request and to all clients registered on the
agents DN.
Event Contents
Table 77: EventAgentReserved Contents
AgentID
a
a. At least one of the AgentID, Place, or ThisDN attri-
butes must be present. The attributes are equal to the
corresponding parameters of the TReserveAgent()
function.
Optional
Event Mandatory
Place
a
Optional
Reasons Optional
Server Mandatory
ThisDN
a
Optional
Timeout
b
b. The duration of the reservation is in milliseconds.
Optional
time Mandatory
Extensions Optional
EventCallInfoChanged
Event Description
The call information has been changed.
Event Contents
EventPrivateInfo
Event Description
This event is generated both in response to a TPrivateService() function call
and when it is used to notify selected sets of clients of T-Serverspecific
information. This event indicates that one of two forms of data has been
passed:
Information supported only by certain T-Servers, and which is not covered
by general feature requests.
Notification about changes in T-Server behavior or device/call statuses.
This event can be distributed to the following clients:
Those who made a request for the private service, TPrivateService().
Those registered on the specified device, depending on the nature of the
service.
Those who would otherwise be ineligible (for security reasons) for
receiving given events, and who thus require additional registration in
order to be notified.
Table 78: EventCallInfoChanged Contents
ConnID Mandatory
CustomerID Optional
Event Mandatory
Extensions Optional
Server Mandatory
time Mandatory
130 Genesys
Event Contents
Example
Figure 44: EventPrivateInfo Feature Example
EventUserEvent
Event Description
A user event from another client application has been received.
Table 79: EventPrivateInfo Contents
PrivateEvent Mandatory
Event Mandatory
Reasons Optional
UserData Optional
Extensions Optional
Server Mandatory
ConnID Optional
ThisDN Optional
time Mandatory
T-Server Client
TPrivateService
EventPrivateInfo
Event Contents
Table 80 contains T-Server-required attributes. Other attributes are specified
by the initiator of this event.
EventPrimaryChanged
Event Description
A change in the role of one of a pair of synchronized T-Servers in hot standby
mode has taken place: the T-Servers role has been changed from backup to
primary.
Warning! After a client receives EventPrimaryChanged, it should re-
synchronize with the new primary T-Server (the one reporting this
event) by calling the TQueryLocation() function and either the
TQueryAddress() or TQueryCall() function.
If T-Server issues EventPrimaryChanged, and the two T-Servers have different
link statuses at the time of switchover, EventLinkDisconnected or
EventLinkConnected is generated as follows:
If the former primary T-Server has its link connected, and the new one
does not, EventLinkDisconnected is delivered just prior to
EventPrimaryChanged.
If the former primary T-Server has its link disconnected, and the new one
has its link connected, EventLinkConnected is delivered immediately after
EventPrimaryChanged.
Table 80: EventUserEvent Contents
CustomerID
a
a. See description of CustomerID on page 148.
Optional
Event Mandatory
Server Mandatory
ThisDN Mandatory
time Mandatory
Extensions Optional
132 Genesys
The ordering of these messages is intended to simplify the processing logic on
the client sidereceiving EventPrimaryChanged when the link is disconnected
may be safely ignored.
Note: The event generated for a primary-to-backup
switchoverEventRestoreconnection, page 132is different from
EventPrimaryChanged in that it is processed internally by T-Library and
is never delivered to clients.
Event Contents
EventRestoreConnection
Event Description
A synchronized connection between a pair of T-Servers in hot standby mode
has been established, or the T-Servers role has been changed from primary to
backup.
Event Contents
Note: EventRestoreConnection is processed internally by T-Library, and is
not delivered to the user dispatch function. As such, it does not use the
conventional event contents structure.
Attributes
ServerRole
The primary T-Server generates EventRestoreConnection, with
the attribute ServerRole set to 0, when the connection to the
backup T-Server has been established.
T-Server generates EventRestoreConnection and sets the
attribute ServerRole to 1 to indicate that it has been changed
from the primary to the backup T-Server. This value is used to
Table 81: EventPrimaryChanged Contents
time Mandatory
prevent a race condition in situations where two or more
switchovers happen within a short interval of time. (Otherwise,
T-Library relies on EventPrimaryChanged to identify the
primary T-Server.)
UserData
This attribute contains the reference to the backup T-Server.
T-Library uses this information to try to connect to that server.
EventHardwareError
Event Description
T-Server has detected inconsistent data or an incomplete event flow in switch
messagingfor instance, a wrong checksum or missing attributes.
Event Contents
EventResourceAllocated (ObsoleteNo Longer Supported)
Event Description
The switch has registered the CTI link to receive events about the specified
telephony object.
Table 82: EventHardwareError Contents
CustomerID Optional
ThisDN Optional
ConnID Optional
PreviousConnID Optional
ErrorCode Optional
Event Mandatory
Server Mandatory
time Mandatory
Extensions Optional
134 Genesys
Chapter 1: T-Library Events Negative-Response Events
EventResourceFreed (ObsoleteNo Longer Supported)
Event Description
The switch has canceled registration of the CTI link, so that it no longer can
receive events about the specified telephony object.
Negative-Response Events
EventError
Event Description
The requested function cannot be performed. The reasons are specified by the
values of the ErrorCode and ErrorMessage parameters.
Event Contents
Table 83: EventError Contents
ConnID Optional
CustomerID Optional
ErrorCode Mandatory
a
Event Mandatory
Server Mandatory
ThisDN Optional
time Mandatory
Extensions Optional
b
Chapter 1: T-Library Events Agent States and Work Modes
Note: The Reasons attribute was formerly included in this event. It is now
obsolete. (It is omitted from the EventError message since,
presumably, the requestor is aware of the reason for the request.)
Agent States and Work Modes
Agent states specify what state an agent is in. For example, an agent in Ready
state is available to handle calls from an ACD queue. An agent can have
several states with respect to different ACD devices, or he can use a single
state to describe his relationship to all ACD devices. Agent states are reported
in agent-state events.
Figure 45 on page 137 shows the agent states. Transitions between states,
represented by arrows, show subsequent states that may be entered from a
given state. The agent-state change occurs after T-Server generates a proper
event.
Agent Null
The state where an agent is not logged in to an ACD group. Logging on and
logging off cause the transition to and from this state.
Agent Not Ready
The state where an agent is logged in to an ACD group, but is not prepared to
handle calls that the ACD distributes. While in this state, an agent can receive
calls that are not handled by the ACD.
Agent Ready
The state where an agent is logged in to an ACD group and is prepared to
handle calls that the ACD distributes.
a. ErrorCode, when received as a negative response to
TTransactionMonitoring(), may include the following
reasons:
TERR_UNSUP_OPER (unsupported operation), the Transac-
tion Monitoring Feature is not supported by this
T-Server.
TERR_INVALID_ATTR (invalid attribute value), the trans-
action monitoring request contains an invalid attribute.
b. Contains additional information on a failure.
136 Genesys
Agent Busy Ready
The state where a device, on behalf of an agent, is involved with an existing
ACD call even if that call is on hold at this device. After the call has been
completed, the device is placed in the Agent Ready state (that is, it can pick up a
new call). Direct calls between agents, calls between supervisors and agents,
and private calls do not cause this transition.
Agent Busy NotReady
completed, the device is placed in the Agent Not Ready state (that is, it cannot
receive further calls from the ACD). Direct calls between agents, calls between
supervisors and agents, and private calls do not cause this transition.
Agent Busy AfterCallWork
completed, the device is placed in the Agent After Call Work state (that is, it is
not able to receive further calls). Direct calls between agents, calls between
supervisors and agents, and private calls do not cause this transition.
Agent After Call Work
The state where a device, on behalf of an agent, is no longer involved with an
ACD call. While in this state, the agent is performing administrative duties for
a previous call and cannot receive further calls from the ACD.
Agent Return Back
The state where an agent is logged in to an ACD group upon having returned
from the WalkAway state. The agent may or may not be ready to receive calls.
Agent Walk Away
The state where an agent is logged in to an ACD group, but is understood not
to be at his station, and thus not prepared to handle calls that the ACD
distributes.
Figure 45: Agent-State Diagram
Agent-State Diagram Comments
In certain cases, even though the agent state remains the same, T-Server might
generate distinct events to represent internal state transitions or data changes
within this state. This can take place if T-Server is required to support switch-
specific substates or if it must distribute additional resources or extensions.
The following rules apply to these existing-state transitions:
T-Server filters out unsolicited CTI messages that do not provide new
information from the last EventReady/NotReady. For instance, if the switch
re-sends the exact same event every time an ACD call is released on an
agents DN, T-Server does not continue to pass on these events to its
clients. On the other hand, if switch-specific sub-states, as reported in
AttributeWorkMode, or if the ReasonCode attribute is changed, then
T-Server distributes EventReady/NotReady.
T-Server distributes a corresponding EventReady/NotReady when clients
initiate a same-state transition, provided T-Server can confirm the state
with the switch, or T-Server has enough confidence that the internally kept
state is correct. In the process of confirming the state with the switch, if
T-Server receives an error message that suggests in the same state, it
translates this into a positive response. If these CTI messages do not
Ready
AfterCall
Work
Logged
Out
Not
Ready
Walk
Away
EventAgentNotReady
w/m = AgentAfterCallWork
EventAgentReady
EventAgentNotReady
EventAgentNotReady
w/m = AgentWalkAway
EventAgentNotReady
w/m = AgentWalkAway
EventAgentNotReady
w/m = AgentReturnBack
EventAgentReady
EventAgentLogout
EventAgentLogout
EventAgentLogin &
EvenAgentNotReady
EventAgentLogin &
EvenAgentReady
Ready
AfterCall
Work
Not
Ready
Walk
Away
EventAgentNotReady
w/m = AgentAfterCallWork
EventAgentReady
EventAgentNotReady
EventAgentNotReady
w/m = AgentWalkAway
EventAgentNotReady
w/m = AgentWalkAway
EventAgentNotReady
EventAgentReady
EventReleased
EventReleased
EventReleased
EventReleased
EventRinging/
EventDialing
Agent Busy
Agent Not Ready
138 Genesys
provide adequate information regarding the problem with the request,
based on internal data, T-Server may generate a response to the client on
its own.
Note: Beginning with the 7.1 release of T-Server, the function
TAgentSetIdleReason(), and its corresponding event, is no longer
supported. Instead, use the generic Request/EventAgentReady/NotReady
with a new value for ReasonCode in the Extensions attribute and/or in
the attribute Reason.
The following transitions are available as of the 7.1 release of T-Library:
T-Server responds with EventAgentLogin (distributed to all registered

clients) in response to the AgentLogin() function, as long as the
credentials (AgentID and ThisQueue) used by the already-logged-in
agent are the same for this DN (and provided T-Server is able to verify
this information on the switch). In the case of credentials that differ:
Since the Genesys model supports only one agent with distinct
AgentID logged in on a given device, depending on the switch,
T-Server either rejects a request with a distinct AgentID or forces a
logout of the old AgentID.
Requests that have different ThisQueue values are processed

according to whether multiple logins are allowed by the CTI
protocol.
EventAgentLogout in connection with a Logged Out state is allowed in
response to a clients request, but is not required. Genesys recommends
that you direct the request to the switch and translate any positive
acknowledgement (one indicating a previous agent state de-
synchronization) into EventAgentLogout.
Agent-State Diagram Limitations
Not all agent states are available on all switching platforms. Furthermore,
some platforms may have additional substates. Please refer to the switchs
documentation for more information.
Depending on switch capabilities, not all transitions are available on all
platforms. Please refer to the switchs documentation for more
information.
In some cases, when T-Server does not have sufficient information from
the CTI link, it may use the Logged In state (not shown in the diagram) to
indicate that an agent is logged in, but that his status is not known.
In order to report the transition from the Logged Out to the Logged In state,
T-Server sends a single EventAgentLogin, without also sending an
EventReady or EventNotReady.
Chapter 1: T-Library Events Unified Call-Party States
Unified Call-Party States
A call-party is the relationship between a call and a given telephony device.
Call-Party is often referred to as party. For the purposes of this chapter, the two
terms are interchangeable.
A call is typically an interaction between two or more telephony objects (or
between a telephony object and a network entity) that is established by the use
of telephony network capabilities. However, in fact, Genesys assumes this
association may have zero to many parties. In the context of the Genesys
model, a call is a stateless object, and it always has a unique connection ID.
A party (call-party) represents the calls relationship to a given telephony
deviceeither an internal DN or an external (out-of-PBX) call participant.
Each call-party has state (and a number of other attributes).
A call-party state is a packaging of the fuller expression of a partys status
(which may be multifaceted)a compound state made up of the following
groups:
Generic Telephony State (GTS);
Supplementary Telephony State (STS);
Routing/Treatment State (RTS).
State modifiers
Each of these groups has parts that are referred to as elementary states, or
properties (the basic attribute of a call-party). Typically, a call-party state
consists of just one of these groups. However, there are certain cases where a
coexistence of multiple groups in one call-party state is the norm. These, for
instance, should be familiar:
Routing with Queueing involves GTS and RTS.
Service Observing involves both GTS and STS.
Note: Although not all combinations of elementary states make sense, there
is no restriction on them.
A state is packed into one integer according to the structure found in Figure 46.
Figure 46: Call-Party Structure
Reserved for
Internal Use
31... ...24 ...18 23... 16 ...12 11 10 9 8 7 6 5 4 3 2 1 0
State
Modifiers
di rt au br nt nl Treat
Reserved
RTS STS
GTS
Changes here cause the generation of EventCallPartyState Changes appear here only when there are changes to other half
17
uc
140 Genesys
Availability of State Information
The Genesys Framework assumes a particular call-party state for each call-
party in the enterprise and supports the generic party-state set common to those
T-Servers that support it. Not all party states or party-state transitions are
mandatory for each T-Server. A given vendor-specific CTI may not provide a
specific call-party state. Or, if a given state is available with the CTI, it may
lack some relevant information required for T-Server to represent that
particular state on the Genesys side of the software, or permit Genesys to
perform a party-state transition. Thus the implementation of call-party states in
T-Server is only complete to the extent that information is available from the
switch. See PartyState in your API reference for details and state numeric
values.
Generic Telephony State
The Generic Telephony State part of a call-party state comprises the most
important of the sub-party states.
Note: Previously, the Genesys model did not include the states Initiated and
Failed as marking participation in a call. As a result, there were no
special events in DN-based event reporting to indicate a transition
between those states and NULL. Some T-Servers used device-related
EventOffHook/OnHook with attribute ConnID to indicate a party had been
added or deleted, but this event is optional and cannot be used when
there is another active call on the same device (otherwise the status of
the device is reported incorrectly). It is not possible to reconstruct the
Initiated and Failed states from DN-based reporting. Furthermore,
for compatibility reasons, parties in these states are not included in the
EventPartyInfo list, and related calls are not included in
EventRegistered and EventAddressInfo.
The Generic Telephony State has the following possible properties:
Null and Null
2
Represent intermediate states when party information exists in T-Server
memory, but when there is no logical relation between a call and device.
Initiated
Indicates that a call has been initiated by a device. Any telephony device that is
initiating a new call enters the Initiated state while it awaits the availability of
switch resources or user input. That is, the device remains in the Initiated
state from the moment it goes off-hook until EventDialing is sent.
Queued
Identifies that a call is queued or parked on a given device, and that it awaits
the availability of some service (for example, ACD queue distribution) or of
some device (for example, a phone line).
Alerting
Means that a call is alerting on a device, indicating an incoming call (for
example, the phone is ringing), or that a call is in the process of being
distributed to a destination (for example, is being processed by the telephony
network).
Connected
Indicates that a given device has a voice connection with other participants.
Note: The Dialing state (which is implicitly used in the DN call model) does
not exist in the unified party-state model. Dialing was an attempt to
report the state of the other party on the call. Such other parties cease
to be clear in complex scenarios where transfers and conferences
confuse matters. However, Dialing, as a state modifier, is available for
compatibility with traditional reporting.
Call Progress (CP) Detection
The originating device (either a queue or a route point) for predictive dialing is
put in this state from the time a call is made (and EventDialing is sent) to the
moment the call is classified, at which time it is either moved to the Queued
state, or is released.
Held
A device has temporarily suspended its connection to other call participants.
Busy
A call cannot reach the intended device, which is busy.
Failed
Indicates that a call originating on a given device has not succeeded (either the
dialed number is wrong, or the switch was not able to allocate the trunk). This
state is used instead of Busy when a destination party was never created for the
call.
Failed also applies to a party whose call has been disconnected, but who
remains off hook.
142 Genesys
Generic Telephony State Diagram for Regular DNs
Figure 47, indicates the event flow that leads to the various sub states that
comprise the Generic Telephony State. This diagram applies to all regular
DNs. That is, all types except ACD queues and route points.
Note: Although they appear in Figure 47, events Alerting, Initiated,
Failed, and Cleared do not currently exist. These names are reserved
for future use.
Figure 47: Generic Telephony State for Regular DNs
op
Note that in this case, with a DN-based call model, EventDestinationBusy is re-
ported for the opposite party.
EventAbandoned is only sent if there is an EventRinging for that party. This occurs
only with external parties.
Alerting
Connected
NULL
Alerting
+Dialing
Queued Busy Ev.Queued
Ev.Alerting
Ev.Queued
Ev.Released
or
Ev.Abandoned
NULL
2
Ev.DestinationBusy
op
)
Ev.Ringing
Ev.Released
or
Ev.Abandoned
Ev.Abandoned )
Connected
+Dialing
Ev.Dialing
Held
Held
+Dialing
Initiated
Ev.Dialing
Ev.Dialing
Ev.Initiated
Ev.Ringing
Ev.Established
Ev.Established
Ev.Released
Ev.Held
Ev.Retrieved
Ev.Released
CallStateFailed
Ev.Released
Ev.Established
Ev.Released
CallStateFailed
Failed
Ev.Cleared
Ev.Held
Ev.Retrieved
Ev.Failed
Ev.DestinationBusy
op
)
NULL
2
Generic Telephony State Diagram for ACD Queues and
Route Points
Figure 48, indicates the event flow that leads to the various sub states that
comprise the Generic Telephony State. This diagram applies to ACD queues
and route points.
Figure 48: Generic Telephony State for ACD Queues and Route Points
Supplementary State
The Supplementary State refers to combinations of the following party
properties. Not all combinations of these properties make logical sense, but the
general model does not put any restrictions on them. Furthermore, there is no
transitional model for these properties (any state can change to any other).
NoListen
A party cannot hear other participants on the call.
NoTalk
A party is muted, and other participants on the call do not hear that party.
Audit
A party is attached to a call as Service Observer or Service Assistant.
Bridged
A party is attached to the call with the Bridged Call Appearance feature.
NULL
Queued
CP
Detection
Ev.Dialing
Predictive Dialing
scenario
Ev.RouteRequest
Ev.Released
Ev.Diverted
or
Ev.Abandoned
Ev.Queued
GTS=NULL
+Routing
Queued
+Routing
Ev.RouteUsed
+ Ev.Diverted
or
Ev.Abandoned
Ev.RouteUsed
or
Ev.Abandoned Ev.Queued
Ev.Diverted
NULL
2
NULL
2
Ev.RouteUsed
Ev.RouteRequest
Ev.Queued
144 Genesys
State Modifiers
State Modifiers further nuance the relationships between events and call states
by allowing for intermediate sub states. These sub states provide additional
information to the system, but may otherwise be unnecessary in the unified
call-party state model.
Dialing Modifier
The unified call-party state model uses Dialing, although not actually a party
state, as a state modifier. This allows the system to handle the following
scenarios, also illustrated in Figure 49:
Reporting applications may need to measure dialing time, which is defined
as the interval between the moment a party is connected to a call and the
moment when the voice connection with the other participant is established
for the first time. It is possible to reconstruct the time spent in a dialing
state without this modifier, but, since T-Server does not provide historical
data, this calculation needs to be done when the full history of the call is
available (by factoring in the states of other parties). The Dialing modifier
provides clients access to this information during the call.
T-Server needs an indication of whether EventEstablished has been
distributed for a given party. In a DN-based call model this event is sent
only when a connection is first established. (See Figure 49 for an instance
of why a subsequent EventEstablished would be useful.) While it is
possible to have this indication stored in device-specific states, the Dialing
modifier allows for common functionality across media devices.
Uncertain Modifier
This modifier is set when the party information is not reliable. See Reliability
in your API reference for details.
Figure 49: Modifier Dialing
Routing / Treatment State
The Routing / Treatment State consists of the following properties:
TreatmentReq
The switch is waiting for a treatment to be applied to the call.
Treatment
A treatment has been applied while the call is located on a given device.
Routing
The switch is waiting for routing instructions.
Routing / Treatment State Diagram
Figure 50 indicates the event flows that lead to the various states comprising
the Routing (left portion of the diagram) and Treatment (right portion of the
diagram) states. The Routing portion pertains to route points; the Treatment
portion pertains directly to monitored IVR ports.
Alerting
Connected
NULL NULL
2
Ev.Released
or
Ev.Abandoned
Held
Ev.Ringing
Ev.Established
Ev.Established
Ev.Released
Ev.Released
Ev.Held
Ev.Held
Ev.Retrieved
NULL
2
Alerting
+Bridged
Ev.Released
CallStateBridged
+ Ev.Bridged
Ev.Released
CallStateBridged
+ Ev.Bridged
Ev.Released
Ev.Bridged
146 Genesys
Chapter 1: T-Library Events Event Attributes
Figure 50: Routing (left portion) and Treatment States (right portion)
Event Attributes
This section describes the attributes that make up each event.
AccessNumber
A pointer to a number by dialing which a client application from the specified
switch can reach a specific external routing point (This DN).
AgentID
This parameter uniquely identifies the ACD agent. For more information, refer
to the type AgentID in your API reference.
ANI
Automatic Number Identification. Indicates the telephony-company charge
number.
CallHistory
Information about transferring/routing of the call through a multi-site contact
center network. For more information, refer to the type CallHistoryInfo in
RTS=
NULL
Ev.RouteUsed
or
Ev.Abandoned
Routing
Ev.RouteRequest
Routing
+Treatment
Ev.TreatmentApplied
Ev.TreatmentEnd
NULL
Ev.Released
or
Ev.Abandoned
Connected
+TreatmentReq
Ev.Treatment
Required
Connected
+Treatment
Ev.TreatmentApplied
Ev.TreatmentEnd
Connected
Ev.Established
your API reference. Typically used to keep track of a call in multi-site contact
centers.
CallID
This attribute contains the call identification provided by the switch, which
uniquely identifies a call. As opposed to ConnID assigned by T-Server, CallID is
created by the switch when the incoming call arrives, or when agent/system
out-dial calls are created. The attribute must be present if the switch generates
and distributes the corresponding parameter to T-Server. (CallID is zero as
long as the switch does not provide that information to T-Server.) For more
information, refer to the type CallID in your API reference.
CallingLineName (Obsolete)
A pointer to the name of the person associated with the directory number from
where the inbound call in question has been made. It can be distributed by an
originating switch through an ISDN trunk only.
CallState
The current status of the call the event relates to. For more information, refer to
the type CallState in your API reference.
CallType
The type of the call in question. For more information, refer to the type
CallType in your API reference.
Capabilities
Switch-specific mask specifying the set of requests and events that this
T-Server can handle.
Cause
For network calls, the reason for transitions to certain statesRouting and
NoParty. (This helps clarify delivery failure, such as Busy or NoAnswer.)
CLID (Obsolete)
Calling Line Identifier. The directory number from where the inbound call was
made.
148 Genesys
CollectedDigits
A pointer to the digits that have been collected from the calling party.
ConnID
A current connection identifier of the call to which this event relates.
ConnID Parameters
Reserved (bits 0 & 1)
Bits reserved for future usage.
Global Server Identifier (bits 2-15)
Unique identifier for this T-Server specified by the server-id
option. If server-id is not specified, the ConnID may not be
unique within a multi-site contact center.
Local Connection Identifier (bits 16-63)
Local identifier of the call this event relates to.
For more information, refer to the type ConnectionID in your API reference.
CustomerID
A pointer to the string containing the assigned Customer (Tenant) identifier
through which the processing of the call was initiated. The attribute must be
present in every event for a multi-tenant contact center.
Table 84: Connection ID Structure
Byte Bits
0 1 2 3 4 5 6 7
0 Reserved Global Server Identifier
1 Global Server Identifier
2 Local Connection Identifier
DNIS
Directory Number Information Service. The directory number to where the
inbound call has been made.
ErrorCode
This attribute contains a value that indicates why a client request failed.
ErrorMessage
A pointer to the character string containing additional information about an
error.
Event
The event identifier. For more information, refer to the type MessageType in
your API reference.
Extensions
A pointer to an additional data structure that takes into account switch-specific
features that cannot be described by the other parameters in an event or a
request. Extensions that are specific to particular events are noted with their
event information in this chapter. Some extensions for requests, however, are
applicable to all T-Servers, and permit tuning of T-Server operations.
FileHandle
The handle of the voice file in question. For more information, refer to the type
File in your API reference.
HomeLocation
A pointer to the name of the host where T-Server is running.
InfoStatus
The InfoType information about the telephony object specified by ThisDN
and/or ThisQueue.
InfoType
The type of information about the telephony object in question.
150 Genesys
LastCollectedDigit
The last digit collected from the calling party.
Location
The remote locations name, in the form of
<Switch Name>
or
<T-Server Application Name>@<Switch Name>.
(Switch Name and T-Server Application Name are as defined in the
Configuration Layer.)
LocationInfoType
A type of information requested by a client in the TQueryLocation() request.
For more information, refer to the type LocationInfoType in your API
reference.
NetworkCallID
In case of network routing, the call identifier assigned by the switch where the
call initially arrived.
NetworkCallState
The current status of the network call the event relates to. For more
information, refer to the type NetworkCallState in your API reference.
NetworkDestDN
The intended destination of the network operation. This may be in the form:
location::DN.
NetworkDestState
The state of the destination party for a network call.
NetworkNodeID
In case of network routing, the identifier of the switch where the call initially
arrived.
NetworkOrigDN
DN of the internal origination party in the form location::DN. This attribute is
only available for first-party operations, those made on behalf of Agent 1,
requested through a premise T-Server.
NetworkPartyRole
The role of a call participant with respect to an in-progress network-transfer
request. For the agent who originated the last network-transfer request, the
value is RoleNtwkOrigParty. For the new destination, the value is
RoleNtwkDestParty. (Network T-Servers do not send this attribute.)
NodeID
Uniquely identifies a switch within a network.
OtherDN
The directory number of the second most significant telephony object (except
an ACD group or trunk group) with respect to the event in question. The
application does not have to be registered to this directory number to receive
the event in question.
OtherDNRole
The role of the telephony object specified by OtherDN in the event in question.
For more information, refer to the type DNRole in your API reference.
OtherQueue
The directory number of the second most significant ACD group with respect
to the event in question.
OtherTrunk
The identifier of the second most significant trunk group with respect to the
event in question.
Place
The identifier of the place requested for reservation.
152 Genesys
PreviousConnID
This attribute links two associated calls. For example, events related to an
original call include the connection ID of a consultation call; events related to a
consultation call include the connection ID of the original call. See ConnID
on page 148.
Warning! When EventPartyChanged is generated for the party that is still only
involved in an original call (that is, ConnID has not been changed
during a two-step operation), the PreviousConnID attribute is equal
to ConnID of the original call.
PrivateEvent
The private event identifier. For more information, refer to the type
PrivateMsgType in your API reference.
Reasons
A pointer to an additional data structure that provides reasons for and results of
actions taken by the user of ThisDN. Any Reasons attribute that appears in
TEvent is taken directly from the corresponding request. (See Table 85.) There
is no other source for the information found in the content of the Reasons
attribute. That is, no Reasons attribute should be expected for an event that is
unsolicited. An event with no reference ID has no identifiable request that
prompted it. See Persistent Reasons on page 207 for more information.
(Switch information of a similar nature to this Genesys Reasons attribute is
sometimes available, but those switch reasons are passed in the Extensions
attribute.)
RefConnID
This attribute identifies the connection ID that results from the merging of two
calls.
ReferenceID
ReferenceID is the identifier generated by T-Library or a TSetReferenceID()
function call and attached to the request a client sends to T-Server. Every time
a client sends a request to T-Server, it uses the current ReferenceID (increasing
it by one each time). In response, T-Server generates an event. Only in the
response to the client who initiated the request, as acknowledgment that the
request has been fulfilled, the resulting event includes the same ReferenceID
that was attached to the request. If the request fails, EventError will be sent
only to the requestor. Table 85 lists the event in which you will find the
ReferenceID corresponding to that found with the request that prompted its
assignment initially.
Note: For a limited number of specific requests, as noted in Table 85,
T-Server may send more than one event with the same ReferenceID.

Table 85: ReferenceID in Events
That Correspond to Requests
Request Event
General Requests
TOpenServer Not Applicable
TOpenServerEx Not Applicable
TDispatch Not Applicable
TCloseServer Not Applicable
TScanServer Not Applicable
TScanServerEx Not Applicable
TSetInputMask EventACK
Registration Requests
TRegisterAddress
a
EventRegistered
TUnregisterAddress
a
EventUnregistered
Call-Handling Requests
TAnswerCall EventEstablished
TClearCall EventReleased
THoldCall EventHeld
TMakeCall
b
EventDialing
TMakePredictiveCall EventDialing
TReleaseCall EventReleased
TRetrieveCall EventRetrieved
TRedirectCall EventReleased
154 Genesys
Transfer/Conference Requests
TInitiateConference
b
EventDialing
TInitiateTransfer
b
EventDialing
TCompleteConference EventReleased
TCompleteTransfer First arriving EventReleased
TDeleteFromConference EventPartyDeleted or EventReleased
TReconnectCall EventRetrieved
TMergeCalls EventReleased
TMuteTransfer
b
EventDialing
TAlternateCall EventHeld
TSingleStepConference EventPartyAdded or EventRinging
TSingleStepTransfer
b
EventReleased
Network Transfer/Conference Requests
TNetworkConsult EventNetworkCallStatus
TNetworkAlternate EventNetworkCallStatus
TNetworkTransfer EventNetworkCallStatus
TNetworkMerge EventNetworkCallStatus
TNetworkReconnect EventNetworkCallStatus
TNetworkSingleStepTransfer EventNetworkCallStatus
TNetworkPrivateService EventNetworkPrivateInfo
Call-Routing Requests
TRouteCall
b
EventRouteUsed
Call-Treatment Requests
TApplyTreatment EventTreatmentApplied+
EventTreatmentEnd or
EventTreatmentNotApplied
That Correspond to Requests (Continued)
Request Event
TGiveMusicTreatment EventTreatmentApplied
TGiveRingBackTreatment EventTreatmentApplied
TGiveSilenceTreatment EventTreatmentApplied
DTMF Requests
TCollectDigits EventDigitsCollected
TSendDTMF EventDTMFSent
Voice-Mail Requests
TOpenVoiceFile EventVoiceFileOpened
TCloseVoiceFile EventVoiceFileClosed
TLoginMailBox EventMailBoxLogin
TLogoutMailBox EventMailBoxLogout
TPlayVoice EventVoiceFileEndPlay
Agent & DN Feature Requests
TAgentLogin EventAgentLogin
TAgentLogout EventAgentLogout or EventQueueLogout
TAgentSetReady EventAgentReady
TAgentSetNotReady EventAgentNotReady
TCallSetForward EventForwardSet
TCallCancelForward EventForwardCancel
TMonitorNextCall EventMonitoringNextCall
TCancelMonitoring EventMonitoringCancelled
TSetMuteOff EventMuteOff
TSetMuteOn EventMuteOn
TListenDisconnect EventListenDisconnected
TListenReconnect EventListenReconnected
Request Event
156 Genesys
TSetDNDOn EventDNDOn
TSetDNDOff EventDNDOff
TSetMessageWaitingOn EventMessageWaitingOn
TSetMessageWaitingOff EventMessageWaitingOff
Query Requests
TQueryAddress
a
EventAddressInfo
TQueryCall
a
EventPartyInfo
TQueryLocation
a
EventLocationInfo
TQueryServer
a
EventServerInfo
TQuerySwitch
a
EventSwitchInfo
User-Data Requests
TAttachUserData EventAttachedDataChanged
TUpdateUserData EventAttachedDataChanged
TDeleteUserData EventAttachedDataChanged
TDeleteAllUserData EventAttachedDataChanged
ISCC Requests
TGetAccessNumber
b
TCancelReqGetAccessNumber EventReqAccessNumberCanceled
Special Requests
TReserveAgent EventAgentReserved
TSendUserEvent EventACK
TSendEvent EventACK
TSendEventEx EventACK
TSetCallAttributes EventCallInfoChanged
TPrivateService EventPrivateInfo or EventAck
Request Event
Reliability
Indicates uncertainty with respect to the reliability of an event. For more
information, see Reliability in your API reference.
RouteType
The type of routing to be applied to the telephony object in question. For more
information, refer to the type RouteType in your API reference.
XRouteType
The type of routing between T-Servers to be applied to the telephony object in
question. For more information, refer to the type XRouteType in your API
reference.
Server
A local server handle to the T-Server in question. In other words, a unique
identifier assigned by T-Library to the connection between a client and
T-Server. For more information, refer to the type TServer in your API
reference.
ServerRole
Specifies the Role of T-Server. For more information, refer to the type
ServerRole in your API reference.
ServerVersion
The version (release) number of the running T-Server, for example,
7.2.000.02.
a. Only the requestor will receive a notification of the event associated with this re-
quest.
b. Since this feature request may be made across locations in a multi-site environ-
ment, if the location attribute of the request contains a value relating to any loca-
tion other than the local site, except when the response to this request is
EventError, there will be a second event response that contains the same reference
ID as the first event. This second event will be either EventRemoteConnectionSuc-
cess or EventRemoteConnectionFailed. See page 149 for more information on data
passed in multi-site environments.
158 Genesys
SessionID
A unique session identifier generated by T-Server.
SubscriptionID
A unique subscription identifier generated by T-Server on the creation of a
new transaction monitoring subscription.
ThirdPartyDN
The directory number of the third most significant telephony object (except an
ACD group or trunk group) with respect to the event in question. The
application does not have to be registered to this directory number to receive
ThirdPartyDNRole
The role of the telephony object specified by ThirdPartyDN in the event in
question. For more information, refer to the type DNRole in your API reference.
ThirdPartyQueue
The directory number of the third most significant ACD group with respect to
ThirdPartyTrunk
The identifier of the third most significant trunk group with respect to the event
in question.
ThisDN
The directory number of the most significant telephony object (except an ACD
group or trunk group) with respect to the event in question. The application
must be registered to this directory number to receive the event in question.
ThisDNRole
The role of the telephony object specified by ThisDN in the event in question.
For more information, refer to the type DNRole in your API reference.
Chapter 1: T-Library Events TEvent Structure
ThisQueue
The directory number of the most significant ACD group with respect to the
event in question.
ThisTrunk
The identifier of the most significant trunk with respect to the event in
question.
time
The structure specifies event generation time that is expressed in elapsed
seconds and microseconds since 00:00 GMT, January 1, 1970 (zero hour). For
more information, refer to the type Time in your API reference.
TreatmentType
The type of treatment to be applied to the telephony object in question. For
more information, refer to the type TreatmentType in your API reference.
UserData
Specifies the pointer to the call-related user data. For more information about
user data, refer to the KVList section of your API reference.
WorkMode
This attribute indicates the agent/supervisor-related current work mode. For
more information, refer to the type AgentWorkMode in your API reference.
XReferenceID
The reference number of a TGetAccessNumber() function that is called by an
application.
TEvent Structure
This section describes the syntax of the TEvent structure. For information on
types of attributes and possible values, see a full description of this structure in
your API reference.
160 Genesys
Note: Although listed here, certain components of the TEvent structure are
reserved for internal use only.
typedef struct TEvent_tag {
enum TMessageType Event;
TServer Server;
int ReferenceID;
char *HomeLocation;
char *CustomerID;
TConnectionID ConnID;
TConnectionID PreviousConnID;
TCallID CallID;
int NodeID;
TCallID NetworkCallID;
int NetworkNodeID;
TCallHistoryInfo CallHistory;
TCallType CallType;
TCallState CallState;
TAgentID AgentID;
TAgentWorkMode WorkMode;
long ErrorCode;
char *ErrorMessage;
TFile FileHandle;
char *CollectedDigits;
char LastCollectedDigit;
TDirectoryNumber ThisDN;
TDirectoryNumber ThisQueue;
unsigned long ThisTrunk;
TDNRole ThisDNRole;
TDirectoryNumber OtherDN;
TDirectoryNumber OtherQueue;
unsigned long OtherTrunk;
TDNRole OtherDNRole;
TDirectoryNumber ThirdPartyDN;
TDirectoryNumber ThirdPartyQueue;
unsigned long ThirdPartyTrunk;
TDNRole ThirdPartyDNRole;
TDirectoryNumber DNIS;
TDirectoryNumber ANI;
TAddressInfoType InfoType;
TAddressInfoStatus InfoStatus;
TTreatmentType TreatmentType;
TRouteType RouteType;
char *ServerVersion;
TServerRole ServerRole;
TMask Capabilities;
TKVList *UserData;
TKVList *Reasons;
TKVList *Extensions;
TTimeStamp Time;
void *RawData;
TDirectoryNumber AccessNumber;
TXRouteType XRouteType;
TReferenceID XReferenceID;
TKVList *TreatmentParameters;
char *Place;
int Timeout;
TMediaType MediaType;
TLocationInfoType LocationInfo;
TMonitorNextCallType MonitorNextCallType;
TPrivateMsgType PrivateEvent;
/* Application data (set by TSetApplicationData) */
void *ApplicationData;
} TEvent;
162 Genesys
Chapter
2 T-Library Call-Based
Notifications
This chapter describes the events generated when T-Server notifies a client of
call-based activity. Each event listed here is identified with a description, the
contents of the event (presented in table format as a list of the attributes
associated with it), and an example of where the event is likely to be
encountered during a call flow. (The format of this part of the chapter is the
same as the general-events chapter, T-Library Events on page 23.)
This chapter has the following section:
Call Definition, page 163
T-Library Call-Based Events, page 164
Multi-Site Call Scenarios, page 171

Note: The information in this chapter replaces a now deprecated solution that
used existing DN-based functions to obtain call-based notifications.
That former solution required that T-Server clients register for abstract
DNs in a Genesys implementation. In order to indicate that an abstract DN
was notifying or was being referred to by a parameter of a function, a double
colon was used after certain event attributes or parameters, namely dn and
location, as in AttributeThisDN=<location>::.
Call Definition
A call is a temporary association among several telephony objects (or between
a telephony object and a network entity) that is established by the use of
telephony network capabilities. This association may have from zero to many
parties. A call is a stateless object that has a Universally Unique ID (UUID)
attribute, a Connection ID (comparable to the DN-based attribute of the same
164 Genesys
Chapter 2: T-Library Call-Based Notifications T-Library Call-Based Events
name used in event reporting), a type, a number of optional attributes, and a list
of parties.
Note: Consultation calls not only have references to the active call, but also
to the main (original) call. In multi-site environments, related calls are
linked to each other my means of Inter-Site Links (IS-Links). (See
Multi-Site Call Scenarios on page 171 for details.) Except for these
two cases of additional references, all calls are processed and reported
on independently of one another.
Call Attributes
CallUUID (string)
UUID of the call.
ISLinkList
List of links to call instances distributed across remote sites.
ConnID (conn-id)
Connection ID of the call.
CallType (int)
Call type (Internal/Inbound/Outbound/Consult).
OrigCallUUID
UUID of the main call (for consult calls only)
Note: The following additional attributes for calls have the same definitions
as their DN-based analogs. See individual listings under Event
Attributes, beginning on page 146.
CallID
NodeID (int)
NetworkCallID (ulong64)
NetworkNodeID (int)
ANI (string)
DNIS (string)
UserData (kv-list)
T-Library Call-Based Events
This section describes the call-based events and how they differ from their
DN-based counterparts.
Event contents are presented as the collection of attributes associated with each
event, as well as an indication of that attributes type. For the purposes of this
chapter, type has one of two values: Mandatory or Optional. Here type refers to
the presence of the attribute at the time of the generation of its event, and not to
a characteristic of the attribute itself.
Attribute Type:
MandatoryIndicates that this attribute is always present when its
OptionalIndicates that this attribute may or may not be present when the
List of T-Library Call-Based Events
There are only three notifications available for calls: CallCreated,
CallDataChanged, and CallDeleted. Each call-based event may have a
number of attributes, and, except for a calls CallUUID, all call attributes
(including ConnID and ISLinkList) may have values that change. For Hot
Standby redundant environments, CallUUID is replicated from the primary to
the backup T-Server.
Note: T-Server may report several changes to a call in one event, even if the
changes are caused by different CTI messages.
EventCallCreated
Event Description
Indicates that a call has been created in T-Server.
Table 86: List of T-Library Call-Based Events
Events Page #
General Events
EventCallCreated page 165
EventCallDataChanged page 166
EventCallDeleted page 167
EventReleasedDEPRECATED page 168
166 Genesys
Event Contents
EventCallDataChanged
Event Description
Indicates that some of a given calls properties have changed.
Table 87: EventCallCreated Contents
CallUUID Mandatory
ISLinkList
a
a. Applies to resynchronization cases only (T-Server
with clients upon initial connect or reconnect at HA
switchover). Otherwise, this value is typically un-
known at call creation.
Optional
ConnID Mandatory
CallType Optional
OrigCallUUID Optional
CallID Optional
NodeID Optional
ANI Optional
DNIS Optional
UserData Optional
CustomerID Optional
DialedNumber
b
b. Applies to outgoing calls only. This optional attri-
bute (string) contains the number dialed, if known
when the call is created (which would be possible
only if it had been created at a clients request).
Optional
Event Contents
Note: Unlike DN-based notifications, EventCallDataChanged includes as
attributes only those call attributes that have changed. (Except for
CallUUID and ConnID, unchanged attributes are not present in the event,
including ISLinkList; in the event that user data is deleted from the
call, the UserData attribute contains an empty TKVList.)
EventCallDeleted
Event Description
Indicates that the call has been deleted.
Table 88: EventCallDataChanged Contents
CallUUID Mandatory
ISLinkList Optional
ConnID Mandatory
CallType Optional
OrigCallUUID Optional
CallID Optional
NodeID Optional
ANI Optional
DNIS Optional
UserData Optional
CustomerID Optional
CtrlParty
a
a. A reference to the party that caused the change.
Optional
168 Genesys
Event Contents
EventReleasedDEPRECATED
Event Description
The telephony object specified by ConnID has been deleted from T-Server
memory.
Note: T-Server delivers this version of EventReleased when the DN referred
to by the parameter ThisDN is an abstract DN. (Here the attribute ThisDN
uses the name of the T-Server application as listed in the Configuration
Layer, with a double colon added, or the name of the switch, also with
a double colon added.) Clients receive this event each time a call is
released on each of the abstract DNs for which they are registered.
Table 89: EventCallDeleted Contents
CallUUID Mandatory
ConnID Mandatory
Cause
a
a. An integer indicating the cause of the deletion, for in-
stance, a transfer or conference.
Optional
RefCallUUID
b
b. CallUUID for the call to which this one was merged, as
in the case of a transfer, conference, or merge.
Optional
RefConnID
c
c. The RefConnID attribute can only be present if the
cause of the call deletion is a transfer, conference, or
merge.
Optional
CtrlParty
d
d. A reference to the party that initiated the disconnec-
tion of the call.
Optional
Event Contents
Table 90: EventReleased ContentsDEPRECATED
ANI Optional
CallID Mandatory
CallState Mandatory
CallType Mandatory
ConnID Mandatory
RefConnID Optional
a
CustomerID Optional
DNIS Optional
Event Mandatory
Extensions Optional
PreviousConnID
b
Optional
Reasons Optional
Server Mandatory
ThisDN
c
Mandatory
time Mandatory
UserData Optional
Reliability Mandatory
170 Genesys
Example
Figure 51: EventReleased Feature ExampleDEPRECATED
For more information, refer to Chapter 6.
a. This attribute is mandatory for call CallStateTrans-
ferred, CallStateConferenced, and CallStateRemot-
eRelease.
b. The attribute must appear if CallType is Consult.
c. The attribute ThisDN uses the name of the T-Server ap-
plication as listed in the Configuration Layer or the
name of the switch. In both cases, the indication that
EventReleased is based on an abstract DN is through
the use of the double colon in the notification, as in
AttributeThisDN=<location>::, where location is the
name of the T-Server or switch.
TReleaseCall (DN A)
EventReleased (DN A)
EventReleased ( ::)
T-Server Client
Table 91: Extensions in EventAddressInfo and EventRegistered for Abstract
DNsDEPRECATED
InfoStatus Attribute Extensions
Key Value
Type
Value Description
InfoType=AddressInfoDNStatus
NumberOfCalls conn-%d string The ConnectionID of a call (converted into
a string)
ConnectionID
Chapter 2: T-Library Call-Based Notifications Multi-Site Call Scenarios
Multi-Site Call Scenarios
A basic principle for multi-site reporting is that T-Server does not try to
support the same model for multi-site calls as it does for those that are local.
Instead, it is the clients responsibility to merge call information into a single
unit based on the calls relationship information provided by T-Server. To help
with multi-site call reporting, Genesys has introduced the Inter-Site Link
(IS-Link) with the following properties:
Each IS-Link has a UUID, assigned at the time of creation and reported in
ISLinkList.
For Hot Standby redundant environments, IS-Links on each side are also
replicated from the primary to the backup T-Server
At any moment, IS-Link may be associated with no more than two calls
(located on different T-Servers).
IS-Link may represent a communication channel, for instance, a voice

channel between calls in different switching domains.
Alternatively, IS-Link may associate two calls that continue each other,
connected together through association with the same external
participant, for instance, an incoming call overflowed or re-routed by
an external network to another switching domain.
On each T-Server the IS-Linkassociated call is reported in the context of
the CallUUID, independent of the other T-Server.
The IS-Link call association does not depend on any T-Server options. In
Figure 52, for instance, the link is always connected to the call labelled
cons, even if T-Server is instructed to populate the ConnID/UserData of the
call labelled orig for the remote site.
An IS-Link may be re-attached to a different call on the same T-Server, but
only as a result of a merge operation. This action is not reported explicitly,
but assumed from EventCallDeleted, with a RefCallUUID attribute
specification.
A call may have more than one associated IS-Link.
In some scenarios when there is an overflow from a queue, an IS-Link may
be attached to a call after the call is reported as deleted.
Figure 52 illustrates a case of three related calls, of which only two are linked
together.
172 Genesys
Figure 52: Multi-Site Call Transfer
The association between an IS-Link and a call is reported in
EventCallDataChanged, which is distributed to call-monitoring clients. Often,
the same event may also report a change in ConnID and UserData as the result of
multi-site synchronization.
Note: In most cases, IS-Link is attached before the first DN-based event is
sent. (That is, before EventRinging and EventRouteRequest.) The
exception is with events for trunks that have trunk monitoring.
T-Server clients should be capable of processing later updates.
Simple Multi-Site Call
In this scenario, events for which are described in Table 92, DN A on Site 1
calls DN B on Site 2.
connected
orig cons
any state Held
connected
Alerting
B0 A0
B1
C1
ext
Alerting
C2
Origination
site
Destination
site
IS-link
UUID-1
consult
call to
device A device B device C
B2
trunk trunk
IS-link
UUID-1
Table 92: Simple Multi-Site Call
Origination (Site 1) Destination (Site 2)
DN-Based Events Call-Based
Notifications
Notifications
A: TMakeCall to B (Site 2)
EventCallCreated
CallUUID UUID-X
ConnID x
EventDialing
CallUUID UUID-X
ConnID c
(x replaced by ISCC)
ThisDN A
OtherDN B
a
CallUUID UUID-X
ConnID c
ISLinkList
UUID-L@site2
EventNetwork-Reached
(Optional)
CallUUID UUID-X
ConnID c
ThisDN A
OtherDN B
a
EventCallCreated
CallUUID UUID-Y
ConnID y
EventRinging
CallUUID UUID-Y
ConnID c
(y replaced by ISCC)
ThisDN B
OtherDN A
a
EventCallData-
Changed
CallUUID UUID-Y
ConnID c
ISLinkList
UUID-L@site1
B: TAnswerCall()
EventEstablished
CallUUID UUID-X
ConnID c
ThisDN A
OtherDN B
a
EventEstablished
CallUUID UUID-Y
ConnID c
ThisDN B
OtherDN A
a
174 Genesys
Multi-Site Call Transfer
In this scenario, events for which are described in Table 93, DN B on Site 1
initiates a transfer for an existing call to DN C on Site 2.
Table 93: Multi-Site Call Transfer
Notifications
Notifications
B is in conversation with A.
B: TInitiateTransfer to C (Site 2)
EventCallCreated
CallUUID UUID-X
OriginCallUUID
UUID-W
ConnID c
EventDialing
CallUUID UUID-X
ConnID cons
(c replaced by ISCC)
TransferConnID orig
ThisDN B
OtherDN C
CallUUID UUID-X
ConnID cons
ISLinkList
UUID-L@site2
Transfer/Conference Completion
At the completion of a transfer or conference, the origination T-Server
distributes the same events as in a standard single-site model. The destination
T-Server may not report the completion of the transfer or conference at all, or
may report it and even report on the call context change, for instance, if EPP is
in effect. Transfer completion might be reported as in Table 94.
For transfer completion, no explicit reporting of changes in call relations is
required. EventCallDeleted with RefCallUUID implies a move of all previously
attached IS-Links from call UUID-X to UUID-W.
EventNetwork-Reached
(Optional)
CallUUID UUID-X
ConnID cons
TransferConnID orig
ThisDN B
OtherDN C
EventCallCreated
CallUUID UUID-Y
ConnID y
EventRinging
CallUUID UUID-Y
ConnID ext
a
(y replaced by ISCC)
ThisDN C
OtherDN B
EventCallData-
Changed
CallUUID UUID-Y
ConnID ext
a
ISLinkList
UUID-L@site1,
(optional: uuid-2B)
B: TAnswerCall()
EventEstablished
CallUUID UUID-X
ConnID cons
ThisDN B
OtherDN C
EventEstablished
CallUUID UUID-Y
ConnID ext
a
ThisDN C
OtherDN B
a. For compatibility with existing solutions, ConnID is assigned at the remote site based on the value of the use-
data-from option at the origination T-Server. If there exists a call with a duplicate ConnID, a new, unique ID
is generated (and, for DN-based reporting purposes, the reference to the other call is passed in the Last-
TransferConnID attribute).
Table 93: Multi-Site Call Transfer (Continued)
Notifications
Notifications
176 Genesys
Attaching the IS-Link Post Mortem
The following three scenarios (Simple Call Overflow on page 177,
Overflow On the Intermediate Switch on page 177, and Mute Transfer With
Overflow on page 179) describe instances where the IS-Link is assigned in
non-standard ways, after the call has been deleted.
Table 94: Multi-Site Call Transfer Completion
Notifications
Notifications
EventReleased
CallUUID UUID-W
ConnID orig
ThisDN B
OtherDN A
EventReleased
CallUUID UUID-X
ConnID cons
TransferConnID orig
ThisDN B
OtherDN C
EventPartyChanged
CallUUID UUID-W
ConnID orig
PreviousConnID orig
ThisDN A
OtherDN C
EventCallDeleted
CallUUID UUID-X
RefCallUUID UUID-W
Cause Transfer
CtrlParty B
EventPartyChanged
(Optional)
CallUUID UUID-Y
ThisDN C
ConnID orig
PreviousConnID ext
EventCallData-
Changed (Optional)
CallUUID UUID-Y
ConnID orig
Simple Call Overflow
In the case of call overflow, even for a simple scenario (Table 95), T-Server
may discover the relation between two calls only after overflowed call has
already been deleted.
Overflow On the Intermediate Switch
In the case of a call being overflowed on the intermediate switch (distinct from
both the original and destination), or overflowed two or more times, call
information may be deleted at the transit site, even if that information still
exists at the end site. The reporting is similar to the case of the simple
overflow, and is shown in Table 96.
Table 95: Simple Call Overflow
Notifications
Notifications
EventQueued
CallUUID UUID-X
ConnID loc
ThisDN B
OtherDN A
EventCallCreated
CallUUID UUID-X
ConnID loc
EventDiverted
CallUUID UUID-X
ConnID loc
ThisDN B
OtherDN A
EventCallDeleted
CallUUID UUID-X
CallUUID UUID-X
ISLinkList
UUID-L@site2
EventQueued
CallUUID UUID-Y
ConnID rem (y
replaced by ISCC)
ThisDN C
OtherDN A
EventCallCreated
CallUUID UUID-Y
ConnID y
EventCallData-
Changed
CallUUID UUID-Y
ConnID rem
ISLinkList
UUID-L@site1
178 Genesys
Table 96: Overflow On the Intermediate Switch
Origination (Site 1) Transit (Site 2) Destination (Site 3)
Call-Based Notifications Call-Based Notifications Call-Based Notifications
EventCallCreated
CallUUID UUID-X
ConnID conn-1
EventCallCreated
CallUUID UUID-Y
ConnID conn-2
EventCallDeleted
CallUUID UUID-Y
CallUUID UUID-X
ConnID rem1
ISLinkList
UUID-L1@site2
CallUUID UUID-Y
ISLinkList
UUID-L1@site1
EventCallCreated
CallUUID UUID-Z
ConnID conn-3
CallUUID UUID-Y
ISLinkList
UUID-L1@site1
UUID-L2@site3
CallUUID UUID-Z
ConnID rem3
ISLinkList
UUID-L2@site2
Mute Transfer With Overflow
In case of a mute transfer to a remote site, in combination with a call overflow,
the relationship between the two calls may be discovered after the active call
has been merged into the main call. See Table 97.
Client-Side IS-Link Processing
Genesys recommends taking into consideration the following principles when
developing for client-side support of multi-site call-linkage discovery.
If the same IS-Link is listed for two calls, the calls are linked together.
An IS-Link relation is transitive: If A is linked to B, and B linked to C,
then A is also linked to C.
Table 97: Mute Transfer With Overflow
Notifications
Notifications
... ...
EventPartyChanged
CallUUID UUID-W
ConnID orig
PreviousConnID cons
ThisDN A
EventCallDeleted
CallUUID UUID-X
RefCallUUID UUID-W
Cause Transfer
EventCallCreated
CallUUID UUID-Y
ConnID y
CallUUID UUID-X
ISLinkList
UUID-L@site2
EventRinging
CallUUID UUID-Y
ConnID ext (y
replaced by ISCC)
ThisDN C
OtherDN B
EventCallData-
Changed
CallUUID UUID-Y
ConnID ext
ISLinkList
UUID-L@site1
180 Genesys
In order to accommodate overflow scenarios and possible network delays,
you should preserve call information, even after EventCallDeleted, for a
short time before purging it.
In order to accommodate transitive call linkage, call information should be
preserved as long as there are two or more active IS-Link associations with
a call for which information would otherwise be purged. (For instance,
avoid unlinking A and C by deleting Bs call information.)
Static storage of IS-Links can be presented in a table indexed by
ISLinkUUID. In such a table, each IS-Link record provides placeholders for
two calls (UUIDs) and two sites.
For situations where only a subset of sites is visible to a client or an
external routing request proves unsuccessful, the IS-Link record may
remain incomplete (refer to one call only). These types of records will be
discarded when the single call is purged.
For dynamic IS-Link storage when one call is merged with another, all
IS-Links should be moved to (or applied towards) the remaining call.
An IS-Link record expires when either of two calls is purged.
Chapter
3 ISCC Transaction
Monitoring
ISCC Transaction monitoring is a feature for working with multi-site
environments. ISCC is an internal T-Server component responsible for
T-Servers multi-site operations such as multi-site call transfer, inter-site call
linkage, call overflow, and other, possibly non-callrelated, multi-site
operations. Internally, those operations are called transactions.
This chapter describes the interfaces that allow you to work with ISCC
Transaction Monitoring: the TTransactionMonitoring() function, the
TSubscriptionOperationType enumeration, and EventTransactionStatus. Use
these to subscribe and work with this feature. In particular, the key-value pairs
of the Extensions attribute returned in EventTransactionStatus expose details
of call-transfer availability (the current state of ISCC transactions), such as
delays and losses, in the multi-site environment.
The content of this chapter represents the implementation of the transaction
model exposed as an extension of the existing T-Library SDK.
This chapter has the following section:
The Subscription Type, page 181
Subscribing to Transaction Monitoring, page 182
The Transaction Monitoring Event, page 184
Transaction Monitoring States, page 186
Transaction Monitoring Elements, page 193

The Subscription Type
There is one enumeration that relates to transaction monitoring,
TSubscriptionOperationType.
182 Genesys
Chapter 3: ISCC Transaction Monitoring Subscribing to Transaction Monitoring
TSubscriptionOperationType
This enumeration defines an operation on a subscription to Transaction
Monitoring Feature notifications.
Syntax
typedef enum {
SubscriptionStart,
SubscriptionStop,
SubscriptionModify
} TSubscriptionOperationType;
Values
SubscriptionStart
Request to create a new subscription.
SubscriptionStop
Request to stop an existing subscription.
SubscriptionModify
Request to modify the rules of an existing subscription.
Subscribing to Transaction Monitoring
In order to initiate transaction monitoring, your code must call the following
function.
TTransactionMonitoring
This function requests a T-Server to start, stop, or modify a subscription to the
Transaction Monitoring Feature notifications. If a request is successful
(EventACK), EventTransactionStatus (EventTransactionStatus on page 184)
is distributed to the requestor.
Syntax
int TTransactionMonitoring (
TServer tserver_handle,
TSubscriptionOperationType subscription_operation,
const char * subscription_identifier,
const TKVList * subscription_rules
);
Chapter 3: ISCC Transaction Monitoring Subscribing to Transaction Monitoring
Parameters
tserver_handle
Local server handle to the T-Server in question.
subscription_operation
This parameter represents an operation on a subscription to
Transaction Monitoring Feature notifications. Its value is one
of TSubscriptionOperationType. A value of this parameter
should be provided by the T-Server client.
subscription_identifier
This parameter represents a subscription identifier. A value
should be NULL for the operation SubscriptionStart. For other
operations its value should be taken from the message
EventACK. It is generated by a T-Server on a creation of a new
subscription.
subscription_rules
This parameter contains subscription rules. A value of this
parameter should be provided by the T-Server client. Its value
should be NULL for the operation SubscriptionStop. See
Subscription Rules for details.
Return Values
The Transaction Monitoring Feature return value is a standard return value for
the T-Library API:
> 0 Reference number (ReferenceID) assigned to this request by the
T-Library API.
< 0 Error condition.
Subscription Rules
Subscription rules are provided by T-Server clients and passed as part of a
notify key-value pair in the Extensions attribute for
RequestTransactionMonitoring. They are represented as a key-value list.
Every subscription rule key-value pair contains a notification mode for one
element. The key represents the name of the element. The value represents the
requested notification mode. If no key has as its name a given element, then
that elements default notification mode is used. See Transaction Monitoring
Elements on page 193 for the list of all default notification modes.
Example
The following is an example RequestTransactionMonitoring with subscription
rules included:
184 Genesys
Chapter 3: ISCC Transaction Monitoring The Transaction Monitoring Event
AttributeReferenceID reference-id-1
AttributeSubscriptionOperation SubscriptionStart
AttributeExtensions
notify (list)
class.name always
object.local-id
1
always
iscc.transaction.state always
iscc.direction.role once
iscc.is-link-creation never
The Transaction Monitoring Event
You can expect to receive EventTransactionStatus once you have successfully
subscribed to transaction monitoring. Information about your subscription
request is also available from EventACK, EventError, and EventServerInfo.
For descriptions of these general T-Library events and their transaction
monitoring specifics, see EventACK on page 126, EventError on
page 134, and EventServerInfo on page 119. For descriptions of event
attributes generally, see Event Attributes on page 146.
EventTransactionStatus
Event Description
This message is an implementation of Transaction Monitoring Feature
notification. This notification is associated with one of the subscriptions
requested by the T-Server client. The key-value pairs of the Extensions
attribute expose details of call-transfer availability (the current state of ISCC
transactions), such as delays and losses, in the multi-site environment.
1.The local attribute represents a unique identifier of the Local Transaction Instance.
The value of this attribute is different from the value of the Global Identifier attribute.
Table 98: EventTransactionStatus Contents
SubscriptionID
a
a. For a description of this attribute, see, in the general
event attribute descriptions, SubscriptionID on
page 158.
Mandatory
Chapter 3: ISCC Transaction Monitoring The Transaction Monitoring Event
Examples
The following examples demonstrate the main requests and expected responses
for cases related to transaction monitoring.
Figure 53: Transaction Monitoring Feature: Query Server
Figure 54: Transaction Monitoring Feature: Subscribe
Client T-Server
1 RequestQueryServer
2 EventServerInfo
Client Subscription T-Server
1 RequestTransactionMonitoring
3 EventACK
4 EventTransactionStatus
2 Create New Subscription
186 Genesys
Chapter 3: ISCC Transaction Monitoring Transaction Monitoring States
Figure 55: Transaction Monitoring Feature: Unsubscribe
Figure 56: Transaction Monitoring Feature: Modify Subscription
Transaction Monitoring States
This section presents models (including substates and transitions) of the states
related to transaction monitoring: the Object, Abstract Transaction, IS Link
Creation Feature, Call Operation Feature, and Resource Feature states.
Client Subscription T- Server
5 EventACK
4 Destroy Subscription
Client Subscription T-Server
5 EventACK
1 EventTransactionStatus (current )
4 Modify Subscription
3 EventTransactionStatus (current )
6 EventTransactionStatus (new)
Object State
Figure 57: Object State
Transitions
created For an object that has just been created; the first transition for
every object (from initial to alive).
changed An objects attributes have been changed (from alive to alive).
destroyed An object has just been destroyed; the last transition for every
object (from alive to dead).
mortinato An object has been created and destroyed at one time; the last
transition for every object (from initial to dead).
Appearance
The Object component is present with every object instance, from the initial to
the final transition. All attributes of an object component are present with
every object instance at all times. If the object instance has exactly one
transition, for instance, iscc.transaction.rejected or
iscc.transaction.done, the object component of such an object instance has
one transition as well. In this case the transition is object.mortinato. If the
object instance has two transitions, for instance, iscc.transaction.started
and iscc.transaction.completed, the object component of the object instance
has two transitions: object.created and then object.destroyed. If the object
instance has more then two transitions, the object component of this object
instance is present for every notification event. The first notification event has
a transition of object.created. The last notification event has a transition
object.destroyed. Notification events that occur between those two have a
transition of object.changed.
Alive
Dead
Mortinato
Created
Destroyed
Changed
188 Genesys
Abstract Transaction State
Figure 58: Abstract Transaction State
SubStates
in-progress
The transaction instance is in progress.
successful
The transaction instance has successfully completed.
failed
The transaction instance has abnormally terminated.
Transitions
started Transaction instance has started (from initial to in-progress).
completed Transaction instance has completed successfully (from in-
progress to successful).
terminated Transaction instance has completed abnormally (from in-
progress to failed).
done Transaction instance has started and has completed
successfully at the same time (from initial to successful). This
transition might be considered as two consecutive
transitionsstarted and completedoccurring without an
intermediate delay. Such a transition might happen when the
initial conditions for this transaction instance are met (all the
In Progress
Successful Failed
Done Started
Completed Terminated
Rejected
required resources are available), and the transaction can be
completed at this same time.
rejected Transaction has started and has completed abnormally at the
same time (from initial to failed). You could consider this
transition as two consecutive transitionsstarted and
terminatedoccurring without an intermediate delay. Such a
transition might happen when the initial conditions for this
transaction are not met (a required resource is permanently
unavailable), or the transaction can never succeed.
Appearance
The Abstract Transaction component is present with every object instance,
from the initial to the final transition. All attributes of an abstract transaction
component are present with every object instance and at all times.
IS Link Creation Feature State
Figure 59: IS Link Creation Feature State
SubStates
in-progress
IS Link creation is in progress.
successful
IS Link creation has successfully completed.
In Progress
Successful Failed
Done Started
Rejected
190 Genesys
failed
IS Link creation has terminated abnormally.
Transitions
started IS Link creation has started (from initial to in-progress).
completed IS Link creation has completed successfully (from in-progress
to successful).
terminated IS Link creation has completed abnormally (from in-progress
to failed).
done IS Link creation has started and has completed successfully at
the same time (from initial to successful). This transition might
be considered as two consecutive transitionsstarted and
completedoccurring without an intermediate delay.
rejected IS Link creation has started and has completed abnormally at
the same time (from initial to failed). You could consider this
terminatedoccurring without an intermediate delay.
Appearance
The IS Link Creation feature component works asynchronously with respect to
the Call Operation and Resource features. The IS Link Creation feature
component starts when all checks for transaction validity have successfully
passed. It ends when the transaction instance ends. Attributes of this
component are present with the transaction instance from the time the IS Link
Creation feature component starts and till it ends.
Call Operation Feature State
Figure 60: Call Operation Feature State
SubStates
in-progress
Call operation is in progress.
successful
Call operation has successfully completed.
failed
Call operation has abnormally terminated.
Transitions
started Call operation has started (from initial to in-progress).
completed Call operation has successfully completed (from in-progress to
successful).
terminated Call operation has completed abnormally (from in-progress to
failed).
done Call operation has started and completed at the same time
(from initial to successful). This transition might be considered
as two consecutive transitionsstarted and
completedoccurring without an intermediate delay.
rejected Call operation has started and has completed abnormally at the
same time (from initial to failed). You could consider this
In Progress
Successful Failed
Done Started
Rejected
192 Genesys
terminatedoccurring without an intermediate delay.
Appearance
The Call Operation feature component works asynchronously with respect to
the IS Link Creation and Resource features. The Call Operation feature
component starts when ISCC starts performing a given call operation to fulfill
a multi-site operation. Usually, it represents a request/response message pair.
The Call Operation feature component ends when the transaction instance
ends. (The attribute iscc.call-operation.call-id is present when a call
related to the call operation is known.)
Resource Feature State
Figure 61: Resource Feature State
SubStates
exclusive
The resource has been acquired in exclusive mode.
shared
The resource has been released, and might be acquired by another transaction.
pending
A resource is temporarily unavailable.
Pending
Shared Unavailable
Acquired
Resumed
Released Terminated
Postponed
Exclusive
Rejected
Chapter 3: ISCC Transaction Monitoring Transaction Monitoring Elements
unavailable
A resource is permanently unavailable.
Transitions
acquired The resource has been acquired exclusively (from initial to
exclusive).
released The resource has been released (from exclusive to shared).
postponed The resource is temporarily unavailable; the transaction has
been postponed (from initial to pending).
resumed The resource is available; the transaction has resumed (from
pending to exclusive).
rejected A resource is unavailable permanently from the outset; the
transaction has been rejected (from initial to unavailable).
terminated A resource became unavailable permanently; the transaction
has been terminated (from pending to unavailable).
Appearance
The Resource feature component works asynchronously with respect to the IS
Link Creation and Call Operation features. The Resource feature component
starts when ISCC tries for first time to acquire a resource required for the
multi-site operation. The Resource feature component ends when the
transaction instance ends. The attribute iscc.resource.name is present from the
time when ISCC successfully acquires the corresponding resource.
Transaction Monitoring Elements
Table 99 contains a full list of transaction monitoring elements and their
default notification modes.
Table 99: Full Set of Transaction Elements
Element Type Element Name Default
Notification Mode
feature class never
attribute class.id never
attribute class.name once
attribute
class.namespace
never
194 Genesys
attribute class.feature-set once
feature object never
attribute object.id always
attribute object.local-id never
attribute object.state never
state object.alive
state object.dead
transition object.created never
transition object.changed never
transition object.destroyed never
transition object.mortinato never
namespace iscc
feature iscc.transaction always
attribute iscc.transaction.state never
state iscc.transaction.in-progress
state iscc.transaction.successful
state iscc.transaction.failed
transition iscc.transaction.started always
transition iscc.transaction.completed always
transition iscc.transaction.terminated always
transition iscc.transaction.done always
transition iscc.transaction.terminated always
feature iscc.direction always
attribute iscc.direction.role once
feature iscc.is-link-creation always
Table 99: Full Set of Transaction Elements (Continued)
Notification Mode
attribute iscc.is-link-creation.is-link-id once
attribute iscc.is-link-creation.state never
state iscc.is-link-creation.in-progress
state iscc.is-link-creation.successful
state iscc.is-link-creation.failed
transition iscc.is-link-creation.started always
transition iscc.is-link-creation.completed always
transition iscc.is-link-creation.terminated always
transition iscc.is-link-creation.done always
transition iscc.is-link-creation.rejected always
feature iscc.call-operation always
attribute iscc.call-operation.call-id on-change
attribute iscc.call-operation.state never
state iscc.call-operation.in-progress
state iscc.call-operation.successful
state iscc.call-operation.failed
transition iscc.call-operation.started always
transition iscc.call-operation.completed always
transition iscc.call-operation.terminated always
transition iscc.call-operation.done always
transition iscc.call-operation.rejected always
feature iscc.resource always
attribute iscc.resource.name once
attribute iscc.resource.state never
state iscc.resource.exclusive
Notification Mode
196 Genesys
state iscc.resource.shared
state iscc.resource.pending
state iscc.resource.unavailable
transition iscc.resource.acquired always
transition iscc.resource.released always
transition iscc.resource.postponed always
transition iscc.resource.resumed always
transition iscc.resource.terminated always
transition iscc.resource.rejected always
class iscc.transaction-route always
class iscc.transaction-direct-callid always
class iscc.transaction-reroute always
class iscc.transaction-direct-uui always
class iscc.transaction-direct-ani always
class iscc.transaction-direct-notoken always
class iscc.transaction-dnis-pool always
class iscc.transaction-direct-digits always
class iscc.transaction-pullback always
class iscc.transaction-route-uui always
class iscc.transaction-network-callid always
class iscc.transaction-cof-callid always
class iscc.transaction-cof-ani always
class iscc.transaction-cof-network-callid always
Notification Mode
Chapter
4
T-Library Unstructured
Data
This chapter describes how T-Server accommodates and allows programmers
to work with unstructured data. There are three types of unstructured data
supported by T-Server: user data, extensions, and reasons. Accordingly, this
chapter is divided according to the following groupings:
User Data, page 197
Extensions, page 201
Reasons, page 205

User Data
Transaction-related user data is structured as a list of data items described as
key-value pairs, where the key stands for a parameter name and the value
represents the current value of that parameter. Each key-value pair may contain
information about only one parameter, whose value can be an integer, character
string, binary type, or unicode.
Warning! Support for unicode is not backward compatible. Unicode should
only be used in uniform 7.0 environments (where all clients use the
7.0 release of T-Library). In mixed environments, clients built with
earlier releases of T-Library will not be able to decode unicode sent
from 7.0 clients and servers.
There is no specific size limitation for the number of key-value pairs or for the
size of individual keys or values. However, the total size of the key-value pairs
is limited. When in a packed format, the total size of the pairs must not exceed
the configured value (default is 16,000 bytes); the configured value has a
maximum of 65,535 bytes.
198 Genesys
Chapter 4: T-Library Unstructured Data User Data
Note: Increasing the configured value above 16,000 bytes, a feature
introduced with release 7.0, may degrade performance. Moreover, if
the value is set above the 16,000-byte default, release 6.5 components
of a Genesys environment cannot properly process the data passed to
them, and may even become unstable.
Arrival, Use, and Manipulation of User Data
User Data can arrive at a client application with any event that contains the
UserData attribute in its TEvent structure. Client applications should be
designed with the ability to view that data. Moreover, since applications may
need to create or modify user data and send it to T-Server for processing
elsewhere in the system, Genesys provides built-in functions for this purpose.
There are a variety of functions available for the creation and manipulation of
user data. (See the Voice Platform SDK API Reference .NET or Java for details
on all such available functions.) While these functions do not generate requests
of T-Server, they allow client applications to create contact-related data
structures understandable for other T-Server clients and to read and modify
contact-related information coming from other clients via T-Server. A created
or modified data structure will typically be sent to T-Server using the
TAttachUserData() or TUpdateUserData() function (both of which are specified
in the tlibrary.h header file). Examples of how to use user data functions are
also available with the SDK documentation.
The functions for the creation and manipulation of user data fall into three
broad groups: reading functions, creation functions, and modification
functions. Reading functions are invoked every time an application wants to
use contact-related information for its internal purposes. Creation and
modification functions are only used by an application to make new data
available to other client applications of T-Server.
User Data in Consultation Calls
In addition to creating and modifying user data, it is also important to provide
ways for user data to be shared among parties on a consultation call. T-Server
provides three methods of handling user data for consultation calls. In the first
method, called the separate method, user data for the consultation call is
attached and stored separately from the user data attached to the original call.
In the second, called the inherited method, user data attached to the original
call is copied to the consultation call at the moment the consultation call is
initiated; after that, any changes to the original calls user data do not affect the
consultation calls user data, and vice versa. In the third, called the joint
method, user data attached to either the original or the consultation call is
associated with the original call and, yet, can be seen and changed by the
parties of both calls.
A consultation call can be initiated with a T-Library request, such as
TInitiateConference(), TInitiateTransfer(), or TMuteTransfer(). Use the
Extensions attribute with the ConsultUserData key specified in the request to
set the method of handling user data for a consultation call. See Extensions
on page 149 for details on this attribute in other contexts. A key-value pair
with the ConsultUserData key can have the following values:
default
separate
inherited
joint
Default Value
Applying the value default to the ConsultUserData key causes T-Server to use
the current value specified for its consult-user-data configuration option. See
your specific T-Server Deployment Guide to learn more about this option. If a
conference/transfer request does not contain the ConsultUserData key, the
value specified in the consult-user-data option applies. Otherwise, the
method of handling user data is based on the value of the ConsultUserData key-
value pair of the request.
Separate Method
Assigning the value separate to the ConsultUserData key tells T-Server to
store an original calls user data separately from the consultation calls user
data. Consequently, the data attached to the original call is only available to the
original calls parties for review and change, while the data attached to the
consultation call is only available to the consultation calls parties.
Inherited Method
Using the inherited value for the ConsultUserData key tells T-Server to copy
the user data from the original call to the user data structure of the consultation
call when the consultation call is initiated. After the consultation call is
established, its user data is stored separately from the original calls user data.
Further changes to the original calls user data are not available to the
consultation calls parties and vice versa.
Joint Method
Using the joint value for the ConsultUserData key tells T-Server to maintain
the same user data structure for the original call and for any number of derived
consultation calls. The user data structure is associated with the original call,
but any of the parties of the original and consultation calls can see and make
changes in the common user data. T-Server associates the user data structure
200 Genesys
with the first consultation call in a consultation call chain when the original
call has ended. (A consultation call chain is created when a consulted party
initiates another consultation call.) If two consultation call chains are created
on different legs of the ended original call, T-Server duplicates the user data
structure and associates the structures with the chains independently. Further
changes of user data made by the parties of one chain will not be visible to the
parties of other chains.
User Data in Multi-Site Consultation Calls
For multi-site (ISCC) consultation calls, in addition to the ConsultUserData key
or the consult-user-data option, setting the use-data-from T-Server common
option also affects user data. The use-data-from option specifies for a given
consultation call that is routed or transferred to a remote location, what the
source of its values for the UserData and ConnID attributes should be. (For the
full description, see the Multi-Site Support Section of the T-Server
Common Configuration Options chapter of the T-Server Deployment Guide.)
The following call flow example illustrates how setting these different values
affects the availability of user data.
Example
An established call for DN A on site A has a UserData attribute with the key M.
1. DN A on site A initiates a conference with DN B on site B. This call has
additional UserData with the key C.
2. DN A on site A completes the conference.
Events on DN B have the following UserData according to how you set options
consult-user-data and use-data-from.
Table 100: Resulting Keys for User Data Based on Use of Different
Options
Value of
use-data-from
Value of consult-user-data
separate inherited joint
original M M M; C
active C M; C M; C
current (1)
a
a. If UserData is reported after the initiation of the conference, these keys
result.
C M; C M; C
current (2)
b
M M M; C
Chapter 4: T-Library Unstructured Data Extensions
Extensions
An extension is a pointer to a data structure that takes into account switch-
specific features and information that cannot be described by the other
parameters in an event or a request. The extensions detailed in this section,
however, pertain only to requests. They are applicable to all T-Servers and
permit tuning of T-Server operations. Extensions for requests that apply only
to particular T-Servers are described in the individual T-Server Deployment
Guides.
Note: See Chapter 1, T-Library Events, page 23 for information on the key-
value pairs (the extensions) that appear in the Extensions attribute of
events (as members of the TEvent structure).
Hardware Reasons in Extensions
In most cases, hardware-issued reasons are noted in the ReasonCode key-value
pair in the Extensions attribute of four specific function calls and their
corresponding events. (See TAgentLogin, TAgentLogout, TAgentSetReady,
and TAgentSetNotReady on page 203 for more information.) However, such
issues are not limited to being present in those four functions (or their
corresponding events).
Hardware-based reasons, as passed by extensions, are handled differently than
Genesys reasons. For an illustration of the handling differences between
hardware-based reasons and Genesys reasons, see Figure 62 on page 206.
Extensions Common to All T-Servers According to Request
This section details the relationship between certain extensions and the
relationships they may have with specific requests.
ISCC Extensions
Note: With the 7.0 release of T-Library, the iscc prefix for extensions does
not necessarily mean that multiple sites are involved in a given request.
These extensions are now supported for single-site scenarios as well.
b. If UserData is reported after the completion of the conference, these
keys result. The assumption for this case is that the option merged-user-da-
ta is set to main-only (the default value).
202 Genesys
The Extensions attributes in Table 101 apply to requests passed between
T-Servers. (In multi-site environments, these are ISCC-processed requests.)
The requests that use these extensions include the functions TMakeCall(),
TInitiateConference(), TInitiateTransfer(), TMuteTransfer(),
TSingleStepTransfer(), TRouteCall(), and TGetAccessNumber().
For all requests taking place between T-Servers, when the cast-type has the
value route, extensions are passed to the media device noted in the function
TRouteCall() from the ExtRoutePoint to the requested destination. After the
first unsuccessful attempt to route a call that arrives at a final destination,
subsequent TRouteCall() requests do not contain extensions from an original
clients request.
Table 101: Extensions Common to All ISCC-Processed Requests
Key Value Value Description
iscc-pass-extension
a
string (local, remote, or
both)
Controls where extension attributes are
passed from an original client request.
iscc-xaction-type integer (or string value of one
of the enumerated route
types)
Routing type to be used. See TXRouteType()
in your API reference for the complete list
of route types available.
iscc-ar-agent-dn string Destination DN
iscc-ar-agent-id string Destination agents ID
iscc-ar-place string The destination agents place
iscc-ar-duration integer Required time that an agent is to be
reserved, in milliseconds (Specify -1 to use
the default of 100000 milliseconds.)
iscc-ar-priority integer Requested priority (Specify -1 to use
default of 0, the lowest priority value.)
iscc-ar-priority-1 integer Additional granularity for setting priority.
These are only evaluated if there are several
concurrent requests with the same iscc-ar-
priority. If any of these sub-priorities is
absent, its value is assumed to be 0.
iscc-ar-priority-2 integer
iscc-ar-priority-3 integer
a. Exception: Do not use iscc-pass-extension with the TGetAccessNumber() function.
Note: To insure backward compatibility to 6.x and in order to comply with certain T-Servers, the default
value for this key-value pair is both. An explicit value for iscc-pass-extensions is expected with ISCC
requests when the same extensions interfere with origination and destination T-Servers. When the
iscc-pass-extensions pair contains an invalid value, the default value is used.
TAgentLogin, TAgentLogout, TAgentSetReady,
and TAgentSetNotReady
The Extensions attribute listed in Table 102 is used to pass hardware reason
codes and pertains to all of the following functions: TAgentLogin(),
TAgentLogout(), TAgentSetReady(), and TAgentSetNotReady(). Recall that
these are the typical, but not the exclusive, functions where hardware-reason
codes are found.
Note: The corresponding events (EventAgentLogin, EventAgentLogout,
EventAgentReady, and EventAgentNotReady) for these four functions
communicate the hardware reason codes as well.
TMakePredictiveCall
The Extensions attributes listed in Table 103, for Call Progress Detection
(CPD), and Table 104, for Call Party Number (CPN), pertain to the function
TMakePredictiveCall(), but are not applicable to all switches. Furthermore,
some switches support only some subset of these extensions. Refer to
individual T-Server deployment guides for applicability.
Table 102: Extensions in TAgentLogin, TAgentLogout,
TAgentSetReady, and TAgentSetNotReady
ReasonCode String A hardware reason code available for
communication through these four
function calls.
Table 103: CPD-Related Extensions in TMakePredictiveCall
VoiceDest Any valid
ACD Queue or
Routing Point
A Queue or Routing Point to which an
outbound call answered by a live voice will be
transferred
AnsMachine Any valid
ACD Queue or
Routing Point
outbound call answered by an answering
machine will be transferred
FaxDest Any valid
ACD Queue or
Routing Point
outbound call answered by a fax machine will
be transferred
204 Genesys
Note: Depending on switch capabilities and the means of call answer
detection, T-Server can route an answered outbound call to a target DN
specified in Extensions using the VoiceDest, AnsMachine, or FaxDest
key.
TInitiateConference, TInitiateTransfer, and
TMuteTransfer
The Extensions attribute listed in Table 105 applies to the functions
TInitiateConference(), TInitiateTransfer(), and TMuteTransfer(). A more
detailed description of ConsultUserData appears under User Data in
Consultation Calls on page 198, above.
Table 104: CPN-Related Extensions in TMakePredictiveCall
Key Type Required Default Value Description
CPNType KVTypeInt No 0 Number type
CPNPlan KVTypeInt No 0 Numbering plan
CPN-
Presentation
KVTypeInt No 0 Presentation indicator
CPN-
Screening
KVTypeInt Screening indicator
CPNDigits KVType-
String
Yes A5 characters, according to formats specified in
the appropriate numbering/dialing plan
Chapter 4: T-Library Unstructured Data Reasons
TReserveAgent
The Extensions attributes listed in Table 106 pertain to the function
TReserveAgent().
Reasons
A reason is a pointer to an additional data structure that provides information
on causes for, and results of, actions taken by the user of ThisDN. If the Reasons
attribute appears in the TEvent structure, it has been taken directly from the
corresponding T-Library request.
Table 105: Extensions in TInitiateConference, TInitiateTransfer, TMuteTransfer
ConsultUserData default The method specified in the consult-user-data
configuration option is used.
separate User data for the consultation call is attached and
stored separately from the user data attached to the
original call.
inherited User data attached to the original call is copied to the
consultation call at the moment the consultation call is
initiated; after that, any changes to the original calls
user data will not affect the consultation calls user
data and vice versa.
joint User data attached to either the original or the
consultation call is associated with the original call
and, yet, can be seen and changed by the parties of
both calls.
Table 106: Extensions in TReserveAgent
ar-priority-1 integer Additional granularity for setting
priority. These are only evaluated if
there are several concurrent requests
with the same value for the parameter
priority. If any of these sub-priorities
is absent, its value is assumed to be 0.
ar-priority-2 integer
ar-priority-3 integer
206 Genesys
Warning! There is no other source for the information found in the content of
the Reasons attribute. Media device/hardware reason codes, and
similar information, do not appear in the Reasons attribute. Rather,
if they are supported, those hardware reasons are provided by
T-Server in the Extensions attribute. Figure 62 diagrams the
difference between media-device reasons and the Reasons attribute
(Genesys Reasons).
Figure 62: Genesys Reasons versus Media-Device Reasons
TEvent with:
Request with:
Media-Device Event with:
TEvent with:
T-Server
Client
T-Server
Media Device
S
c
e
n
a
r
i
o

1
S
c
e
n
a
r
i
o

2
S
c
e
n
a
r
i
o

3
TClient Request with:
Genesys Reasons
Media-Device Reason B
Media-Device Reason B
Media-Device Reason A
Genesys Reasons
Extension that includes
Reason A = Reported Reason
Reason B = Recognized Reason
From the perspective of the media device:
TClient Request with:
Genesys Reasons
Genesys Reasons
TEvent with:
Extension that includes
Media-Device Event with:
Note: Both reasons A and B will be in the
ReasonCode key in the Extensions.
Persistent Reasons
There are times when the value of the Reasons attribute does not pertain to the
most recent activity related to the DN or device in question. Such reasons are
considered persistent or current. In particular, TQueryAddress and
TRegisterAddress return the current reason for a DN. This allows applications
such as Stat Server to retrieve the state of a DN, with its associated reason, at
the time of startup or re-start and improves metrics quality and accuracy.
In any given instance, the value of the Reasons attribute is stored by T-Server
in a TKVList. T-Server, however, does not control the context for this list. It
therefore becomes the job of the application receiving this value as part of an
event to interpret it appropriately. This is not always straightforward, since
T-Server only preserves one reason for a given DN at any given time.
Additionally, T-Server only stores reasons that arrive from successful requests.
Thus, if you receive an error in response to, for instance, an AgentNotReady
request (because the agent or DN could not be set to the not ready state), the
reason that you passed with the request is not preserved, and the reason from
the previous successful request is still active.
Note: In order to erase a reason completely, applications need to pass an
empty TKVList in a request (and receive successful confirmation).
Requests with NULL as the reason do not affect the current reason. (This
is done to preserve backward compatibility.)
To change a reason without changing the state of the agent or DN, you can
send a request with a different reason several times. (This is supported for all
7.x T-Servers, by invoking the concept of self-transition states. Some older
T-Servers may return errors.)
Note: A T-Server synchronizes its Reasons attributes with its backup for use
in failover. But there is no resynchronization of these attributes at the
time of a backup T-Servers reconnection.
208 Genesys
Chapter
5 IVR Protocol Messages
This chapter presents detailed explanations of the messages and parameters
used by the Genesys IVR XML protocol and it includes these sections:
General Messages, page 209
Routing Messages, page 212
Call Treatment Messages, page 213
External Routing Messages, page 214
Transfer/Conferencing Messages, page 214
Call Information Messages, page 216
Statistics Messages, page 217
User Data Messages, page 218
Outbound Messages, page 219

The messages in this chapter are those sent by the IVR Server to the IVR.
General Messages
This section includes the responses to login, logging, and reset messages.
LoginResp
This message is sent by the IVR Server to the IVR in response to a LoginReq
message.
The Status parameter of the LoginResp message has the following possible
values. (See Table 107 for a complete list of message parameters.)
NoSuchClient There is no IVR object configured in the Configuration
Layer with the name supplied in the ClientName parameter
of the LoginReq message.
InitInProgress The IVR Server is in the process of initializing and is not
ready to process new calls.
210 Genesys
Chapter 5: IVR Protocol Messages General Messages
OK Initialization is complete, and the IVR Server can process
calls.
Place required configuration information in the data transport section of the
IVR Application object in Configuration Manager. If you do this, the
information is returned in the ConfigOptions section of the LoginResp message.
MonitorInfo
This message will be sent when a significant event occurs related to the server
monitoring. These will be events pertinent to managing agent status. The ReqId
parameter will be present when this event is in response to an XML request, as
opposed to an unsolicited event.
See Table 108 for a complete list of message parameters.
Server Subtype
A Server type of MonitorInfo message is created when the information being
sent is related to T-Server connections. This message is never directly
requested by a client, so the ReqId parameter of the MonitorInfo message will
never be supplied.
Table 107: LoginResp Message
Message Parameter Optional/
Required
Name Value
LoginResp IServerVersion Required
Result Success
InvalidProtocolVersion
Required
ConfigOptions Optional
Status NoSuchClient
InitInProgress
OK
Optional
Table 108: MonitorInfo Message
Message Parameter Optional/Required
Name Value
MonitorInfo ReqId Optional
Chapter 5: IVR Protocol Messages General Messages
This message will be sent when either an EventLinkDisconnected or
EventLinkConnected event occurs, or when the T-Server socket is closed. For
this event to be forwarded, it must occur on a T-Server that is used by the IVR.
This is based upon the configuration of the IVR in ConfigServer and the name
provided by the login request. Server status events are shown in Table 109.
Port Subtype
This message will be sent to inform the client that no further successful
requests can be submitted for that port due to configuration database changes.
As with the Server subtype; this message will never have a ReqId associated
with it.
Table 109: Server Status Events
T-library Event XML
EventLinkConnected <Server Status=OK/>
EventLinkDisconnected/Socket Closed/
No Connection
<Server
Status=Unavailable/>
Table 110: Server Message
Name Value
Server Name Required
Status OK
Unavailable
Required
Switch Optional
Table 111: Port Message
Name Value
Port PortNum Required
Status
OK
Unavailable
Required
212 Genesys
Chapter 5: IVR Protocol Messages Routing Messages
Agent Subtype
Agent related events occurring on relevant ports are conveyed using the Agent
subtype. These messages can either be in response to control messages, or due
to external sources. When in response to a control message, ReqId from that
related message will be used. Table 112 shows the relationship between
T-Library events and XML messaging.
In T-Library, the LoggedIn state is not a steady state, it only indicates that the
login was successful. Another status message will always follow the LoggedIn
indication to signify whether the agent is in the ready or not ready state. This
is a function of the switch and may be one or the other depending on
configuration. Therefore, Ready and NotReady imply LoggedIn.
It is also important to note that the query event may return an Unknown state
from the switch. As a general rule, treat Unknown as LoggedOut.
Routing Messages
This message is the basic response resulting from requests to start a call, route
it, confirm the connection or indicate failure to connect, and end the call.
Table 112: Agent Status Events
T-library Event XML
EventAgentLogin <Agent PortNum=01 Status=LoggedIn/>
EventAgentLogout <Agent PortNum=01 Status=LoggedOut/>
EventAgentReady <Agent PortNum=01 Status=Ready/>
EventAgentNotReady <Agent PortNum=01 Status=NotReady/>
Table 113: Agent Message
Name Value
Agent PortNum Required
Status
LoggedIn
LoggedOut
Ready
NotReady
Unknown
Required
Chapter 5: IVR Protocol Messages Call Treatment Messages
RouteResponse
This message is sent by the IVR Server to the IVR to indicate that the call
should be routed to the specified destination.
Call Treatment Messages
Call treatment messages are used to start and control an external application
that processes a call and which might return data that can then be used to route
the call.
TreatCall
This message is sent by the IVR Server to the IVR to indicate that the specified
call treatment should be run by the IVR.
Table 114: RouteResponse Message
Required
Name Value
RouteResponse RouteType Default
Normal
Reroute
RerouteAttended
RerouteConferenced
Present only if
supplied by URS.
Dest Optional
ExtnsEx Optional
Table 115: TreatCall Message
Message Parameter Name Optional/Required
TreatCall CallId Required
Type Required
Parameters Optional
ExtnsEx Optional
214 Genesys
Chapter 5: IVR Protocol Messages External Routing Messages
Cancel
This message is sent by the IVR Server to the IVR to indicate that a previously
started call treatment process must be canceled.
External Routing Messages
This message is used as a response to a request for an inter-switch transfer.
AccessNumResp
This message is sent by the IVR Server to the IVR to indicate the result of a
previous AccessNumGet/AccessNumCancel. The Action parameter indicates to
which type of request this message is in response. The access number is only
present for a successful AccessNumGet.
Transfer/Conferencing Messages
These messages are used to monitor call transfers and conferencing.
Table 116: Cancel Message
Cancel
Table 117: AccessNumResp Message
Name Value
AccessNumResp Action Get
Cancel
Required
Result Success
Failure
Required
AccessNum Optional
Chapter 5: IVR Protocol Messages Transfer/Conferencing Messages
CallStatus
This message is sent by the IVR Server to inform the IVR of certain call
events. The list of possible events are alternatives. Only one parameter from
this list appears in any message.
CallError
This message is sent by the IVR Server to inform the IVR that an error
occurred during the setup of a transfer or a conference call.
Errors related to agent control activities will be represented by the
AgentControl or the NotAllowed indication. When the error is due to an
EventError, the TlibErrCode will be populated with AttributeErrorCode and
the type will be AgentControl. NotAllowed will be used exclusively when
attempting to control a server controlled port. The user supplied ReqId will be
returned in the error.
Table 118: CallStatus Message
Name Value
CallStatus Event Dialing
Ringing
Established
Retrieved
Busy
Held
ConfPartyAdd
ConfPartyDel
XferComplete
Released
Required
216 Genesys
Chapter 5: IVR Protocol Messages Call Information Messages
Call Information Messages
This message is in response to a request for data attached to the call.
CallInfoResp
The response contains information on all of the listed parameters for which
data has been collected.
Note: The value of the FirstHomeLocation parameter is only returned for
logins with version 3.0 or later of the IServer.dtd file. This attribute
corresponds to T-Librarys AttributeFirstTransferHomeLocation
attribute. See T-Library events for details.
Table 119: CallError Message
Name Value
CallError FailedReq Unknown
NoSuchCall
OneStepXfer
OneStepConf
InitConf
CompleteConf
InitXfer
CompleteXfer
RetrieveCall
MakeCall
AgentControl
NotAllowed
Required
TLibErrCode Optional
ReqId Optional
Chapter 5: IVR Protocol Messages Statistics Messages
Statistics Messages
The statistics message enables you to receive data on the
CurrNumberWaitingCalls and ExpectedWaitTime statistics. These statistics must
be configured in Stat Server before they can be accessed through the IVR
Server.
StatResp
Supplies the response to requests for statistics.
See Table 121 on page 218 for a complete list of message parameters.
Table 120: CallInfoResp Message
CallInfoResp ANI Optional
DNIS Optional
CalledNum Optional
ConnId Optional
TSCallId Optional
PortDN Optional
PortTrunk Optional
PortQueue Optional
OtherDN Optional
OtherTrunk Optional
OtherQueue Optional
LastEvent (The most
recently recorded
T-Server event.)
Optional
FirstHomeLocation Optional
218 Genesys
Chapter 5: IVR Protocol Messages User Data Messages
User Data Messages
This message is in response to a request to access and control data about the
actions performed by callers.
UDataResp
This message contains the response to the previous user data messages. The
responses for UDataSet and UDataDel indicate either success or, if failure, the
reason for the failure.
The response for a successful UDataGet includes the values for the requested
keys.
Table 121: StatResp Message
Name Value
StatResp RequestId Required
ResultCode Success
NoSuchStat
MiscError
Required
Result Optional
Table 122: UDataResp Message
Required
Name Value
UDataResp RequestId Required
Result Success
NoSuchCall
NoMatch
FeatureNotSupported
MiscError
Required
UDataEx Optional
Chapter 5: IVR Protocol Messages Outbound Messages
Outbound Messages
DialOutRegistryResp
Sent from IVR Server to the IVR, this message returns information about the
related DialOutRegistry message. ConfigError is returned when the
corresponding DN from the DialOutRegistry message either is not defined in
the Configuration Layer or is not a route point. MiscFailure is currently not
used. Success will be returned in all other cases. When using commands Remove
and RemoveAll, Success will always be returned.
DialOut
Sent from IVR Server to the IVR, this message indicates that an outbound call
has been requested. Values from the original TMakePredictiveCall are included
in this message where UDataEx and ExtnsEx are AttributeUserData and
AttributeExtensions, respectively. Also, OrigNum is retrieved from
AttributeThisDN and DestNum is AttributeOtherDN. TimeToAnswer gives the
amount of time, in seconds, that the IVR should allow for an outbound call to
be answered before a NoAnswer failure should be returned.
Table 123: Dial Out Registry Resp Message
Name Value
DialOutRegistryResp Result MiscFailure
ConfigError
Success
Required
220 Genesys
Chapter 5: IVR Protocol Messages Outbound Messages
Table 124: Dial Out Message
Name Value
DialOut OrigNum Required
DestNum Required
RefID Required
TimeToAnswer Required
Part
2 Genesys Interaction
Models
Part Two of this document contains information on a selected list of call and
interaction models. This information ranges from basic call scenarios to
complex, but common ones. Based on the history of how this information has
been presented in the past in various documents, model details may differ from
chapter to chapter. This information appears in the following chapters:
Chapter 6, Call Models and Flows, on page 223 presents the bulk of
Genesys voice-based models. In this case, you can view call model details,
and network attended transfer call flows. In each case, selected event
information is provided to enhance your understanding of the model.
Chapter 7, Basic Interaction Models, on page 393 offers a look at
selected models for interactions of non-voice type.
Chapter 8, IVR Call Flows, on page 447 contains the standard IVR call
flows, with annotations.
222 Genesys
Part 2: Genesys Interaction Models
Chapter
6
Call Models and Flows
The information in this chapter is divided among the following sections:
Legend, page 223
List of Call Models, page 225
Basic Call Models, page 229
Releasing Calls, page 258
Holding, Transferring, and Conferencing, page 261
Handling User Data, page 307
Special Cases, page 310
Predictive Dialing, page 343
Monitoring Calls, page 357
Working With Queues, page 370
Network T-Server Attended Transfer Call Flows, page 379

Legend
All parties shown in a call scenario, except where stated explicitly, are
considered internal and are monitored by T-Server. If one or more external
parties participated in the call, the following apply:
T-Server will not distribute any events to the external (nonmonitored)
party.
T-Server may not have any information about the nonmonitored party, so
its reference may not be specified.
Figure 63 illustrates a basic call model.
224 Genesys
Chapter 6: Call Models and Flows Legend
Figure 63: Sample Call Model
Activities like conference and transfer can be performed to an existing multi-
party call (a conference call). When so, Party A is considered a complex
party and the following apply:
Events assigned to Party A, as shown in call scenarios, are sent to

every party of complex party.
Reference to Party A in AttributeOtherDN are not present.

This is also represented in Table 125 and Table 126.
Table 125: Depiction of Complex Parties in Call Models 1
PARTY A
(complex)
PARTY C
EventPartyChanged
ConnID 1
ThisDN A
OtherDN C
EventPartyChanged
ConnID 1
ThisDN C
OtherDN A
A
B
Make a Call to B
EventDialing (ConnID 1)
EventRinging (ConnID 1)
EventEstablished (ConnID 1)
Answer
Conversation
Hold
EventHeld (ConnID 1)
Shaded ovals
represent manual
actions on the
corresponding
phone set or
requests made
by client
applications and
communicated by
T-Library to the
media device.
Chapter 6: Call Models and Flows List of Call Models
Since T-Library is a superset of functions, not every scenario described in this
document is supported by every type of switch. For more details, see the
T-Server Deployment Guide that applies to your T-Server/switch pair.
When more than one event is presented in one table cell, the order in which the
events are distributed may vary.
Attributes ThirdPartyDN and ThirdPartyDNRole specify DNs to which two-step
operations are initiated and completed.
A call is considered to be queued until either EventDiverted or EventAbandoned
regarding the queue is generated.
Comments
*OPT Optional.
*DIAL May be a dialed number or is not present if T-Server has no
information about the other party.
List of Call Models
Table 127 presents the list of call models documented in this chapter.
Table 126: Depiction of Complex Parties in Call Models 2
PARTY A0 PARTY A1 PARTY C
EventPartyChanged
ConnID 1
ThisDN A0
OtherDN C
EventPartyChanged
ConnID 1
ThisDN A1
OtherDN C
EventPartyChanged
ConnID 1
ThisDN C
Table 127: List of Call Models
Call Model Page
Basic Call Models
Simple Call Model
page 229
Connection-Establishing Phase (Internal/Inbound Call)
page 230
to ACD)
page 233
Connection-Establishing Phase (Call Queued to
Multiple ACDs)
page 236
226 Genesys
Connection-Establishing Phase (Internal/ Inbound Call
with Call Parking)
page 240
with RoutingRouteQueue Case)
page 243
with Routing)
page 247
Connection-Establishing Phase (Internal/ Inbound Call
with Routing Outbound)
page 251
Connection-Establishing Phase (Outbound Call)
page 254
(Internal/Outbound Call)
page 257
Releasing Calls
Release Phase
page 258
Release from Conference Phase
page 259
Delete from Conference Phase
page 260
Holding, Transferring, and Conferencing
Hold/Retrieve Function, Consulted Party Answers
page 262
Hold/Retrieve Function, Consulted Party Does Not
Answer
page 265
Single-Step Transfer
page 268
Single-Step Transfer (Outbound)
page 271
Mute Transfer
page 274
Two-Step Transfer: Complete After Consulted Party
Answers
page 277
Two-Step Transfer: (Blind) Complete Before Consulted
Party Answers
page 280
Two-Step Transfer: to ACD
page 283
Two-Step Transfer: to a Routing Point
page 288
Trunk Optimization: Trunk Anti-Tromboning
page 292
Single-Step Conference
page 294
Table 127: List of Call Models (Continued)
Call Model Page
Conference
page 296
Blind Conference (Complete Before Consulted Party
Answers)
page 300
Conference with Two Incoming Calls Using TMergeCalls
page 304
Handling User Data
Attaching/Updating User Data to Internal Call
page 307
Attaching/Updating User Data to Call by Third Party
page 308
Special Cases
Outbound Call to a Busy Destination
page 310
Rejected Call
page 312
Internal Call to Destination with DND Activated
page 316
Call Forwarding (on No Answer)
page 318
Alternate-Call Service
page 321
Reconnect-Call Service
page 323
Redirect-Call Service
page 325
Internal/Inbound Call with Bridged Appearance
page 328
Outbound Call from Bridged Appearance
page 331
Hold/Retrieve for Bridged Appearance
page 334
Internal/Inbound Call Answerable by Several Agents
(Party B Answers)
page 336
Call Treatment with Routing
page 339
Predictive Dialing
Predictive Call
page 343
Predictive Call with Routing
page 347
Predictive Call (Connected to a Device Specified in
Extensions)
page 352
Call Model Page
228 Genesys
Monitoring Calls
Service Observing on Agent
page 357
Service Observing for Agent-Initiated Call
page 363
Service Observing on Queue
page 366
Working With Queues
Multiple-Queue Call Treated at IVR Port: Treatment at
IVR Queue
page 370
Multiple-Queue Call Treated at IVR Port: Direct
Treatment at IVR Port
page 374
Multiple-Queue Call: Call Removed from Queue
page 377
Handling Network Calls
Standard Network Call Initiation
page 379
Consultation Leg Initiation, Specific Destination
page 380
Failed Consultation: Specific Target
page 381
Consultation Leg Initiation, URS Selected Destination
page 381
Failed Consultation: URS Selected Destination
page 382
Transfer/Conference Completion: Explicit
page 383
Transfer Completion: Implicit
page 384
Conference Completion
page 385
Alternate Call Service
page 385
Alternate Call Service with Transfer Completion
page 386
Explicit Reconnect
page 388
Implicit Reconnection (by SCP)
page 388
Implicit Reconnection (by Network T-Server)
page 388
Caller Abandonment
page 389
Network Single-Step Transfer
page 390
Premature Disconnection, One Variation 1
page 390
Call Model Page
Chapter 6: Call Models and Flows Basic Call Models
Basic Call Models
This section documents the basic scenarios under which calls arrive in a
contact center.
Simple Call Model
Figure 64: Simple Call Model
Premature Disconnection, a Second Variation
page 391
Transactional Error
page 392
Call Model Page
A B
Connection Establishing Phase (ConnID 1)
Release Phase (ConnID 1)
230 Genesys
Connection-Establishing Phase (Internal/Inbound Call)
Figure 65: Connection-Establishing Phase (Internal/Inbound Call)
Table 128: Connection-Establishing Phase
(Internal/Inbound Call)
PARTY A PARTY B
Make Call to B (TMakeCall)
EventDialing
ConnID 1
ThisDN A
ThisDNRole Origination
OtherDN
*DIAL
OtherDNRole Destination
*DIAL
A
B
Make Call to B
Answer
Conversation
*
***
**
EventRinging
ConnID 1
ThisDN B
ThisDNRole Destination
OtherDN A
OtherDNRole Origination
CallState OK
Answer (TAnswerCall)
EventEstablished
ConnID 1
ThisDN A
OtherDN B
EventEstablished
ConnID 1
ThisDN B
OtherDN A
Conversation
Table 129: Abnormal Call Flow
Interruption
Point
PARTY A PARTY B
* EventReleased
ConnID 1
ThisDN A
CallState OK
(Internal/Inbound Call) (Continued)
PARTY A PARTY B
232 Genesys
** EventDestinationBusy
ConnID 1
ThisDN A
CallState
a
*** EventReleased
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
CallState OK
EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
a. CallState may have values that clarify the reason for the destination being busy, for
instance CallStateSitInvalidNum.
Table 129: Abnormal Call Flow (Continued)
Interruption
Point
PARTY A PARTY B
Connection-Establishing Phase (Internal/Inbound
Call to ACD)
Figure 66: Connection-Establishing Phase (Internal/Inbound Call to ACD)
Make Call to ACD
A B
(ACD)
Diverts Call to C
EventDiverted (ConnID 1)
EventQueued (ConnID 1)
B C
Answer
Conversation
***
*
**
234 Genesys
(Internal/Inbound Call to ACD)
PARTY A PARTY B (ACD Group) PARTY C
Make Call to B
EventDialing
ConnID 1
ThisDN A
OtherDN B
*DIAL
OtherDNRole
Destination
*DIAL
EventQueued
ConnID 1
ThisDN B
ThisQueue B
OtherDN A
Diverts call to C
EventDiverted
ConnID 1
ThisDN B
ThisQueue B
OtherDN A
ThirdPartyDN C
*OPT
ThirdPartyDNRole
Destination
*OPT
EventRinging
ConnID 1
ThisDN C
ThisQueue B
OtherDN A
CallState OK
EventEstablished
ConnID 1
ThisDN A
OtherDN C
EventEstablished
ConnID 1
ThisDN C
ThisQueue B
OtherDN A
Conversation
(Internal/Inbound Call to ACD) (Continued)
Interruption
Point
PARTY A PARTY B PARTY C
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
*** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
236 Genesys
Queued to Multiple ACDs)
Figure 67: Connection-Establishing Phase (Internal/Inbound Call Queued to Multiple ACDs)
A
B
Make Internal/Inbound
Call to B
Diverts Call to D
Conversation
*
****
C D
Answer
**
***
(Internal/Inbound Call Queued to Multiple ACDs)
PARTY A PARTY B (ACD) PARTY C (ACD) PARTY D
Make
Internal/Inbound Call
to B (ACD)
EventDialing
ConnID 1
ThisDN A
ThisDNRole
Origination
OtherDN B
*DIAL
OtherDNRole
Destination
*DIAL
EventQueued
ConnID 1
ThisDN B
ThisQueue B
ThisDNRole
Destination
OtherDN A
OtherDNRole
Origination
EventQueued
ConnID 1
ThisDN C
ThisQueue C
ThisDNRole
Destination
OtherDN A
OtherDNRole
Origination
Diverts Call to D
EventDiverted
ConnID 1
ThisDN B
ThisDNRole
Origination
OtherDN C
OtherDNRole
Destination
EventDiverted
ConnID 1
ThisDN C
ThisQueue C
ThirdPartyDN D
ThirdPartyQueue B
CallState Redirected
a
238 Genesys
EventRinging
ConnID 1
ThisDN D
ThisQueue B
ThisDNRole
Destination
OtherDN A
OtherDNRole
Origination
CallState OK
Answer
(TAnswerCall)
EventEstablished
ConnID 1
ThisDN A
ThisDNRole
Origination
OtherDN D
OtherDNRole
Destination
CallState OK
EventEstablished
ConnID 1
ThisDN D
ThisDNRole
Destination
OtherDN A
OtherDNRole
Origination
CallState OK
Conversation
a. For ACD configurations where calls are distributed to agents assigned directly to ACD groups, CallState
and its value of Redirected are present.
For ACD configurations where calls are distributed to agents assigned to secondary ACD groups associated
with top-level ACD queues, the CallState, with the value Redirected, is not present.
(Internal/Inbound Call Queued to Multiple ACDs) (Continued)
PARTY A PARTY B (ACD) PARTY C (ACD) PARTY D
Interruption
Point
PARTY A PARTY B PARTY C PARTY D
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventAbandoned
ConnID 1
ThisDN B
ThisQueue B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventAbandoned
ConnID 1
ThisDN B
ThisQueue B
OtherDN A
CallState OK
EventAbandoned
ConnID 1
ThisDN C
ThisQueue C
OtherDN A
CallState OK
*** EventReleased
ConnID 1
ThisDN A
OtherDN D
CallState OK
**** EventReleased
ConnID 1
ThisDN A
OtherDN D
CallState OK
EventAbandoned
ConnID 1
ThisDN D
ThisQueue C
OtherDN A
CallState OK
240 Genesys
with Call Parking)
Figure 68: Connection-Establishing Phase (Internal/Inbound Call with Call Parking)
A
B
Call to B
*
Call Is Parked On B
Call Is Picked Up By B
Answer
EventDestinationBusy (ConnID 1)
*OPT
Table 134: Connection-Establishing Phase (Internal/Inbound Call
with Call Parking)
PARTY A PARTY B
Make Call To B (TMakeCall)
EventDialing
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
Call Is Parked On B
*OPT
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
EventQueued
ConnID 1
ThisDN B
OtherDN A
CallState OK
Call Is Picked Up By B
EventRinging
*RE
ConnID 1
ThisDN B
OtherDN A
CallState OK
242 Genesys
EventEstablished
ConnID 1
ThisDN A
OtherDN B
EventEstablished
ConnID 1
ThisDN B
OtherDN A
Conversation
Interruption
Point
PARTY A PARTY B
* EventReleased
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
CallState OK
EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
Table 134: Connection-Establishing Phase (Internal/Inbound Call
with Call Parking) (Continued)
PARTY A PARTY B
with RoutingRouteQueue Case)
Figure 69: Connection-Establishing Phase, Internal/Inbound Call with Routing (RouteQueue Case)
A
B C
Make Inbound Call to B
EventRouteUsed (ConnID 1)
Answer
Conversation
EventRouteRequest (ConnID 1)
Route Call to C
*
****
***
**
This step may
be missing.
244 Genesys
Table 136: Connection-Establishing Phase, Internal/Inbound Call with Routing
(RouteQueue Case)
PARTY A PARTY B
(Routing Point/CDN)
PARTY C
Make Incoming Call to
Information Service
EventDialing
ConnID 1
ThisDN A
OtherDN B
EventQueued
ConnID 1
ThisDN B
ThisQueue B
OtherDN A
EventRouteRequest
ConnID 1
ThisDN B
ThisQueue B
OtherDN A
Route Call to C
(TRouteCall)
a
EventRouteUsed
ConnID 1
ThisDN B
OtherDN A
ThirdPartyDN C
*OPT
ThirdPartyDNRole Destination
*OPT
EventDiverted
ConnID 1
ThisDN B
ThisQueue B
OtherDN A
ThirdPartyDN C
*OPT
*OPT
EventRinging
ConnID 1
ThisDN C
ThisQueue B
OtherDN A
CallState OK
(RouteQueue Case) (Continued)
PARTY A PARTY B
(Routing Point/CDN)
PARTY C
246 Genesys
EventEstablished
ConnID 1
ThisDN A
OtherDN C
EventEstablished
ConnID 1
ThisDN C
OtherDN A
Conversation
a. RouteCall to C (TRouteCall()) may be missing.
(RouteQueue Case) (Continued)
PARTY A PARTY B
(Routing Point/CDN)
PARTY C
Interruption
Point
*
And
**
EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
*** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
**** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
with Routing)
Figure 70: Connection-Establishing Phase (Internal/Inbound Call with Routing)
A
B C
Make Inbound Call
Answer
Conversation
Route Call to C
*
****
***
**
248 Genesys
(Internal/Inbound Call with Routing)
PARTY A PARTY B
(Routing Point/CDN)
PARTY C
Make Incoming Call to
Information Service
EventDialing
ConnID 1
ThisDN A
OtherDN B
*DIAL
OtherDNRole
Destination
*DIAL
EventRouteRequest
ConnID 1
ThisDN B
OtherDN A
Route Call to C
a

(TRouteCall)
EventRouteUsed
ConnID 1
ThisDN B
OtherDN A
ThirdPartyDN C
b
*OPT
CallState OK/Redirected
c
EventRinging
ConnID 1
ThisDN C
OtherDN A
CallState OK
EventEstablished
ConnID 1
ThisDN A
OtherDN C
EventEstablished
ConnID 1
ThisDN C
OtherDN A
Conversation
a. Not present if a call has been routed by default; that is, a switch did not receive any routing instruction
from a computer domain within a timeout configured on the switch side (scripted or otherwise) and there-
fore processed the call using switch logic.
b. Content of ThirdPartyDN depends on the call scenario:
If information about the destination is available at the moment EventRouteUsed is generated, this attribute
is mandatory; a DN where the call has been delivered must be reported.
If the information is not available, but the call has been routed through T-Server, this attribute is mandato-
ry; a DN where the call has been sent must be reported.
If a call has been routed to a default destination or routed by another application, this attribute is optional
(depends on switch capabilities).
c. CallState has a value of Redirected (22) if a call has been routed by a switch. For Aspect ACD, Rock-
well Spectrum, and Hicom 300 E CS switches, the attribute Callstate is not present.
(Internal/Inbound Call with Routing) (Continued)
PARTY A PARTY B
(Routing Point/CDN)
PARTY C
250 Genesys
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
a
ConnID 1
ThisDN B
OtherDN A
CallState OK
*** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
**** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
a. EventError must be sent after EventAbandoned in this case to make the ReferenceID available.
with Routing Outbound)
Figure 71: Connection-Establishing Phase (Internal/Inbound Call with Routing Outbound)
A
B C
Call to B
Answer
*
* *
TRouteCall
EventNetworkReached (ConnID 1)
Table 140: Connection-Establishing Phase (Internal/Inbound Call with Routing
Outbound)
PARTY A PARTY B
(Routing Point)
PARTY C
Incoming Call
EventDialing
ConnID 1
ThisDN A
OtherDN B
*DIAL
OtherDNRole
Destination
*DIAL
EventRouteRequest
ConnID 1
ThisDN B
OtherDN A
Route Call to C
a

(TRouteCall)
252 Genesys
EventNetworkReached
ConnID 1
ThisDN A
OtherDN C
*DIAL
OtherDNRole
Destination
*DIAL
EventRouteUsed
ConnID 1
ThisDN B
OtherDN A
ThirdPartyDN C
b
ThirdPartyDNRole
Destination
*OPT
CallState OK/Redirected
c
EventRinging
ConnID 1
ThisDN C
OtherDN A
CallState OK
EventEstablished
ConnID 1
ThisDN A
OtherDN C
EventEstablished
ConnID 1
ThisDN C
OtherDN A
Conversation
a. Not present if a call has been routed by default; that is, a switch did not receive any routing instruction
from a computer domain within a timeout configured on the switch side (scripted or otherwise) and there-
fore processed the call using switch logic.
b. Content of ThirdPartyDN depends on the call scenario:
If information about the destination is available at the moment EventRouteUsed is generated, this attribute
is mandatory; a DN where the call has been delivered must be reported
If the information is not available, but the call has been routed through T-Server, this attribute is mandato-
ry; a DN where the call has been sent must be reported
If a call has been routed to a default destination or routed by another application, this attribute is optional
(depends on switch capabilities)
c. CallState has a value of Redirected (22) if a call has been routed by a switch. For Nortel Communication
Server 1000 with SCCS MLS, Aspect ACD, Rockwell Spectrum, and Hicom 300 E CS switches, the attri-
bute CallState is not present.
Table 140: Connection-Establishing Phase (Internal/Inbound Call with Routing
Outbound) (Continued)
PARTY A PARTY B
(Routing Point)
PARTY C
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
254 Genesys
Connection-Establishing Phase (Outbound Call)
Figure 72: Connection-Establishing Phase (Outbound Call)
(Outbound Call)
PARTY A PARTY B
Make Outside Call (TMakeCall)
EventDialing
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
A
B
Make Outbound Call
Answer
Conversation
*
***
**
**
EventNetworkReached
a
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
Answer
EventEstablished
ConnID 1
ThisDN A
OtherDN B
*OPT
*OPT
Conversation
a. When a switch does not report network reached, T-Server simulates
EventNetworkReached right before distributing EventEstablished.
Interruption Point PARTY A
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
(Outbound Call) (Continued)
PARTY A PARTY B
256 Genesys
** EventDestinationBusy
ConnID 1
ThisDN A
OtherDN B
CallState
a
*** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
a. CallState may have values that clarify the reason for the destination be-
ing busy, for instance CallStateSitInvalidNum.
Interruption Point PARTY A
Figure 73: Connection-Establishing Phase While On Hold
Table 144: Connection-Establishing Phase While On Hold
PARTY A PARTY B
Call to B
EventDialing
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventRinging
ConnID 1
ThisDN B
OtherDN A
CallState OK
Hold
A
B
Call to B
EventRetrieved (ConnID 1)
EventEstablished (ConnID 1) EventEstablished (ConnID 1)
Answer
Hold
Retrieve
258 Genesys
Chapter 6: Call Models and Flows Releasing Calls
Releasing Calls
This section illustrates the standard processes by which calls are released.
Release Phase
Figure 74: Release Phase
EventHeld
ConnID 1
ThisDN A
OtherDN B
Answer
EventEstablished
ConnID 1
ThisDN A
OtherDN B
EventEstablished
ConnID 1
ThisDN B
OtherDN A
Retrieve
EventRetrieved
ConnID 1
ThisDN A
OtherDN B
CallState OK
Table 144: Connection-Establishing Phase While On Hold
(Internal/Outbound Call) (Continued)
PARTY A PARTY B
Release
EventReleased (ConnID 1) EventReleased (ConnID 1)
Conversation
A B
Figure 75: Release from Conference Phase
Table 145: Release Phase
PARTY A PARTY B
Conversation
Release (TReleaseCall)
EventReleased
ConnID 1
ThisDN A
OtherDN B
*OPT
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
*OPT
CallState OK
EventPartyDeleted (ConnID 1) EventPartyDeleted (ConnID 1)
EventReleased (ConnID 1)
Release
Conference
Conversation
A B
C
Table 146: Release from Conference Phase
Conference
260 Genesys
Delete from Conference Phase
Figure 76: Delete from Conference Phase
EventPartyDeleted
ConnID 1
ThisDN A
OtherDN B
OtherDNRole DeletedParty
ThirdPartyDN B
ThirdPartyDNRole DeletedBy
CallState OK/Conferenced
a
EventReleased
ConnID 1
ThisDN B
CallState OK
EventPartyDeleted
ConnID 1
ThisDN C
OtherDN B
ThirdPartyDN B
a
Conversation
a. If more than two parties remain in the conference call, CallState has a value of Conferenced; otherwise,
CallState has a value of OK.
Table 146: Release from Conference Phase (Continued)
A
B C
EventPartyDeleted (ConnID 1)
Delete (B)
EventPartyDeleted (ConnID 1) EventPartyReleased (ConnID 1)
Conference
Conversation
Chapter 6: Call Models and Flows Holding, Transferring, and Conferencing
Holding, Transferring, and Conferencing
The call models here show the functions and events related to placing calls on
hold, transferring calls, and creating conference calls.
Table 147: Delete from Conference Phase
Conference
Delete B
(TDeleteFromConference)
EventPartyDeleted
ConnID 1
ThisDN A
OtherDN B
ThirdPartyDN A
a
EventReleased
ConnID 1
ThisDN B
CallState OK
EventPartyDeleted
ConnID 1
ThisDN C
OtherDN B
ThirdPartyDN A
a
Conversation
a. If more than two parties remain in the conference call, CallState has a value of Conferenced; otherwise,
CallState has a value of OK.
262 Genesys
Hold/Retrieve Function, Consulted Party Answers
Figure 77: Hold/Retrieve Function, Consulted Party Answers
A BB
C
Hold
Consultation Call to C
Retrieve Call from A
*
**
***
Table 148: Hold/Retrieve Function, Consulted Party Answers
Call-Establishing Phase (ConnID 1)
Hold (THoldCall)
EventHeld
ConnID 1
ThisDN B
OtherDN A
Make Call to C
(Consultation)
(TMakeCall)
(TRetrieveCall)
EventRetrieved
a
ConnID 1
ThisDN B
OtherDN A
CallState OK
a. With EventRetrieved, the values for attributes ThisDNRole and ThisQueue are the same as those for the attri-
butes of the same names, if any, in the events preceding EventRetrieved (EventEstablished and EvenRing-
ing). For non-ACD calls, however, ThisQueue is not reported.
Table 148: Hold/Retrieve Function, Consulted Party Answers (Continued)
264 Genesys
Interruption
Point
PARTY A PARTY B
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
*** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
Hold/Retrieve Function, Consulted Party Does Not Answer
Figure 78: Hold/Retrieve Function, Consulted Party Does Not Answer
A BB C
Hold
Unsuccessful Internal Call
(Party Does Not Answer) (ConnID 2)
*
**
Table 150: Hold/Retrieve Function, Consulted Party Does Not Answer
266 Genesys
Hold (THoldCall)
EventHeld
ConnID 1
ThisDN B
OtherDN A
Unsuccessful Internal Call (Party Does Not Answer) (ConnID 2)
(TRetrieveCall)
EventRetrieved
a
ConnID 1
ThisDN B
OtherDN A
CallState OK
Table 150: Hold/Retrieve Function, Consulted Party Does Not Answer (Continued)
Interruption
Point
PARTY A PARTY B
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
268 Genesys
Figure 79: Single-Step Transfer
A
B C
Connection-Establishing Phase (ConnID 1)
Single-Step Transfer to C
Answer
*
Update/Attach Data to Call
EventPartyChanged (ConnID 1)
* *
Recommended to use
if user_data update/
change/attachment is
required. For details,
see a corresponding
telephony model.
Table 152: Single-Step Transfer
(TSingleStepTransfer)
EventPartyChanged
ConnID 1
PreviousConnID 1
ThisDN A
OtherDN C
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
CallState Transferred
EventReleased
ConnID 1
ThisDN B
ThirdPartyDN C
OtherDN A
Cause 1stepTransfer
EventRinging
ConnID 1
ThisDN C
OtherDN A
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
EventEstablished
ConnID 1
ThisDN C
OtherDN A
Table 152: Single-Step Transfer (Continued)
270 Genesys
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
Single-Step Transfer (Outbound)
Figure 80: Single-Step Transfer (Outbound)
A
B C
Answer
*
* *
Recommended to use
if user_data update/
change/attachment is
required. For details,
see a corresponding
telephony model.
Table 154: Single-Step Transfer (Outbound)
272 Genesys
(TSingleStepTransfer)
EventPartyChanged
ConnID 1
PreviousConnID 1
ThisDN A
OtherDN C
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
EventNetworkReached
ConnID 1
ThisDN A
OtherDN C
*DIAL
*DIAL
EventReleased
ConnID 1
ThisDN B
ThirdPartyDN C
OtherDN A
Cause 1stepTransfer
EventRinging
ConnID 1
ThisDN C
OtherDN A
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
EventEstablished
ConnID 1
ThisDN C
OtherDN A
Table 154: Single-Step Transfer (Outbound) (Continued)
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
274 Genesys
Mute Transfer
Figure 81: Mute Transfer
A
B C
Mute Transfer to C
EventPartyChanged (ConnID 1) EventPartyChanged (ConnID 1)
Answer
*
* *
* * *
Table 156: Mute Transfer
Mute Transfer to C
(TMuteTransfer*)
EventHeld
ConnID 1
ThisDN B
OtherDN A
EventDialing
ConnID 2
ThisDN B
OtherDN C
EventRinging
ConnID 2
ThisDN C
OtherDN B
CallState OK
EventPartyChanged
ConnID 1
PreviousConnID 1
ThisDN A
OtherDN C
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
EventReleased
ConnID 1
ThisDN B
OtherDN A
EventReleased
ConnID 2
ThisDN B
OtherDN C
EventPartyChanged
ConnID 1
PreviousConnID 2
ThisDN C
OtherDN A
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
Table 156: Mute Transfer (Continued)
276 Genesys
EventEstablished
ConnID 1
ThisDN C
OtherDN A
Table 156: Mute Transfer (Continued)
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventReleased
ConnID 2
ThisDN B
OtherDN C
CallState OK
EventAbandoned
ConnID 2
ThisDN C
OtherDN B
CallState OK
*** EventReleased
ConnID 1
ThisDN B
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN B
CallState OK
Two-Step Transfer: Complete After Consulted Party Answers
Figure 82: Two-Step Transfer (Complete After Consulted Party Answers)
A
B C
EventPartyChanged (ConnID 1) EventReleased (ConnID 1)
Answer
*
* *
Hold
Transfer Held Call to C
Table 158: Two-Step Transfer (Complete After Consulted Party Answers)
278 Genesys
Hold (TInitiateTransfer*)
EventHeld
ConnID 1
ThisDN B
OtherDN A
(TInitiateTransfer
Continues)
(TCompleteTransfer)
EventPartyChanged
ConnID 1
PreviousConnID 1
ThisDN A
OtherDN C
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
EventReleased
ConnID 1
ThisDN B
OtherDN A
EventReleased
ConnID 2
ThisDN B
OtherDN C
EventPartyChanged
ConnID 1
PreviousConnID 2
ThisDN C
OtherDN A
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
Table 158: Two-Step Transfer (Complete After Consulted Party Answers) (Continued)
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventReleased
ConnID 2
ThisDN B
OtherDN C
CallState OK
EventAbandoned
ConnID 2
ThisDN C
OtherDN B
CallState OK
280 Genesys
Two-Step Transfer: Complete Before Consulted Party
Answers (Blind)
Figure 83: Blind Transfer (Two-Step Transfer, Complete Before Consulted Party Answers)
A
B C
EventPartyChanged (ConnID 1) EventReleased (ConnID 1)
Answer
*
* *
Hold
* * *
Table 160: Blind Transfer (Two-Step Transfer, Complete
Before Consulted Party Answers)
Hold (TInitiateTransfer)
EventHeld
ConnID 1
ThisDN B
OtherDN A
(TInitiateTransfer
Continues)
EventDialing
ConnID 2
ThisDN B
OtherDN C
*DIAL
*DIAL
EventRinging
ConnID 2
ThisDN C
OtherDN B
CallState OK
(TCompleteTransfer)
EventPartyChanged
ConnID 1
PreviousConnID 1
ThisDN A
OtherDN C
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
EventReleased
ConnID 1
ThisDN B
OtherDN A
EventReleased
ConnID 2
ThisDN B
OtherDN C
EventPartyChanged
ConnID 1
PreviousConnID 2
ThisDN C
OtherDN A
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
Before Consulted Party Answers) (Continued)
282 Genesys
Note: If a call appears on the terminating party after transfer completion, the
ConnID field of EventRinging is equal to the connection ID of the
original call (ConnID 1), and EventPartyChanged is not generated.
EventEstablished
ConnID 1
ThisDN C
OtherDN A
Before Consulted Party Answers) (Continued)
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
Two-Step Transfer: to ACD
Note: Two-step transfer to ACD means that a call is waiting in a queue, and
the transfer completed before any ACD agent is available to receive the
call.
** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventReleased
ConnID 2
ThisDN B
OtherDN C
CallState OK
EventAbandoned
ConnID 2
ThisDN C
OtherDN B
CallState OK
*** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
Interruption
Point
284 Genesys
Figure 84: Two-Step Transfer to ACD
**
*
***
A B
ACD
C
Hold
EventDiverted (ConnID 1) EventRinging (ConnID 1)
D
Diverts Call to D
Answer
Release Phase (ConnID 1) A<->D
Table 162: Two-Step Transfer to ACD
PARTY A PARTY B PARTY C (ACD) PARTY D
Hold (TInitiateTransfer)
EventHeld
ConnID 1
ThisDN B
OtherDN A
(TInitiateTransfer
Continues)
EventDialing
ConnID 2
ThisDN B
OtherDN C
*DIAL
EventQueued
ConnID 2
ThisDN C
ThisQueue C
OtherDN B
(TCompleteTransfer)
EventPartyChanged
ConnID 1
PreviousConnID 1
ThisDN A
OtherDN C
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
EventReleased
ConnID 2
ThisDN B
OtherDN C
EventReleased
ConnID 1
ThisDN B
OtherDN A
EventPartyChanged
ConnID 1
PreviousConnID 2
ThisDN C
ThisQueue C
OtherDN A
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
Diverts Call to D
Table 162: Two-Step Transfer to ACD (Continued)
286 Genesys
Note: If a call transfer is completed before it is put in an ACD queue, an
EventPartyChanged is not generated.
EventDiverted
ConnID 1
ThisDN C
OtherDN A
ThirdPartyDN C
*OPT
ThirdPartyDNRole
Destination
*OPT
EventRinging
ConnID 1
ThisDN D
ThisQueue C
OtherDN A
CallState OK
Answer
(TAnswerCall)
EventEstablished
ConnID 1
ThisDN D
ThisQueue C
OtherDN A
CallState OK
Table 162: Two-Step Transfer to ACD (Continued)
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventReleased
ConnID 2
ThisDN B
OtherDN C
CallState OK
EventAbandoned
ConnID 2
ThisDN C
OtherDN B
CallState OK
*** EventReleased
ConnID 1
ThisDN A
OtherDN D
CallState OK
EventAbandoned
ConnID 1
ThisDN D
OtherDN A
CallState OK
288 Genesys
Two-Step Transfer: to a Routing Point
Figure 85: Two-Step Transfer to a Routing Point
A B
Routing Point
C
Hold
EventRouteUsed (ConnID 1) EventRinging (ConnID 1)
D
Routes Call to D
Answer
Release Phase (ConnID 1) A<->D
**
*
****
***
Table 164: Two-Step Transfer to a Routing Point
Hold
(TInitiateTransfer)
EventHeld
ConnID 1
ThisDN B
OtherDN A
Consultation Call
to C
(TInitiateTransfer
Continues)
EventDialing
ConnID 2
ThisDN B
ThisDNRole
Origination
OtherDN C
*DIAL
OtherDNRole
Destination
CallType Consult
EventRouteRequest
ConnID 2
ThisDN C
ThisDNRole
Destination
OtherDN B
OtherDNRole
Origination
Transfer Held Call to
C (TComplete-
Transfer)
Table 164: Two-Step Transfer to a Routing Point (Continued)
290 Genesys
EventPartyChanged
ConnID 1
PreviousConnID 1
ThisDN A
ThisDNRole
Origination
a
OtherDN C
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
EventReleased
ConnID 2
ThisDN B
ThisDNRole
Origination
OtherDN C
OtherDNRole
Destination
EventReleased
ConnID 1
ThisDN B
ThisDNRole
Destination
OtherDN A
EventPartyChanged
ConnID 1
PreviousConnID 2
ThisDN C
OtherDN A
ThirdPartyDN B
ThirdPartyDNRole
TransferredBy
Diverts Call to D
EventRouteUsed
ConnID 1
ThisDN C
OtherDN A
ThirdPartyDN D
*OPT
EventRinging
ConnID 1
ThisDN D
OtherDN A
CallState OK
Answer
(TAnswerCall)
EventEstablished
ConnID 1
ThisDN D
OtherDN A
a. ThisDNRole must be Destination if party B is the call originator.
Table 164: Two-Step Transfer to a Routing Point (Continued)
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventReleased
ConnID 2
ThisDN B
OtherDN C
CallState OK
EventAbandoned
ConnID 2
ThisDN C
OtherDN B
CallState OK
*** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
**** EventReleased

ConnID 1
ThisDN A
OtherDN D
CallState OK
EventAbandoned
ConnID 1
ThisDN D
OtherDN A
CallState OK
292 Genesys
Trunk Optimization: Trunk Anti-Tromboning
Trunk optimization: trunk anti-tromboning (TAT) scenarios apply to
functionality available from certain Nortel switches and are very similar to the
case of Two-Step Transfer: Complete After Consulted Party Answers on
page 277. Figure 86 identifies the call model used by T-Servers to indicate a
TAT event.
Figure 86: Trunk Optimization: Trunk Anti-Tromboning
Hold
T-Server 1
Party A
T-Server 1
Party C
T-Server 2
Party B
TCompleteTransfer :
TAT Occurs
Table 166: Trunk Optimization: Trunk Anti-Tromboning
T-Server 1
PARTY A
T-Server 1
PARTY C
T-Server 2
PARTY B
Hold
(TInitiateTransfer to C)
EventHeld
ConnID 1
ThisDN B
OtherDN A
EventRinging
ConnID 2
ThisDN C
OtherDN B
EventDialing
ConnID 2
ThisDN B
OtherDN C
EventEstablished
ConnID 2
ThisDN C
OtherDN B
EventEstablished
ConnID 2
ThisDN B
OtherDN C
TCompleteTransfer
Trunk Optimization Occurs
EventPartyChanged
ConnID 1
ThisDN A
OtherDN C
ThirdPartyDN B
CallState RemoteRelease
EventPartyChanged
ConnID 1
PreviousConnID 2
ThisDN C
OtherDN A
ThirdPartyDN B
CallState RemoteRelease
EventReleased
ConnID 1
ThisDN B
OtherDN A
EventReleased
ConnID 2
ThisDN B
OtherDN C
Table 166: Trunk Optimization: Trunk Anti-Tromboning (Continued)
T-Server 1
PARTY A
T-Server 1
PARTY C
T-Server 2
PARTY B
294 Genesys
Single-Step Conference
Figure 87: Single-Step Conference
A
B C
Single-Step Conference to C
Release Phase (ConnID 1) A<->C
EventPartyAdded (ConnID 1) EventPartyAdded (ConnID 1) EventRinging (ConnID 1)
*
* Party C may issue SingleStepConference as well as Party B; in both cases the event
flow is the same.
Conference
Table 167: Single-Step Conference
TSingleStepConference
EventPartyAdded
ConnID 1
ThisDN A
OtherDN C
ThirdPartyDN B
a
EventPartyAdded
ConnID 1
ThisDN B
OtherDN C
ThirdPartyDN B
a
EventRinging
ConnID 1
ThisDN C
ThisDNRole
ConferenceMember
CallState OK
EventEstablished
ConnID 1
ThisDN C
ThisDNRole
ConferenceMember
CallState Conferenced
a. ThirdPartyDN has a value of C if Party C initiates the request for a conference.
Table 167: Single-Step Conference (Continued)
296 Genesys
Conference
Note: This call model applies to two types of conferences: Two-Step
Conference and Conference with Calls Merge.
Figure 88: Conference
A B
Conference
C
Hold
EventPartyAdded (ConnID 1) EventPartyAdded (ConnID 1)
Release Phase (ConnID 1) A<->C
*
Table 168: Conference
Hold (See Table 170.)
EventHeld
ConnID 1
ThisDN B
ThisDNRole Previous Role of
DN
OtherDN A
OtherDNRole Previous Role of
DN
(See Table 170.)
298 Genesys
Conference (See Table 170.)
EventPartyAdded
ConnID 1
ThisDN A
OtherDN C
ThirdPartyDN B
ThirdPartyDNRole AddedBy
EventReleased
ConnID 2
ThisDN B
OtherDN C
EventRetrieved
a
ConnID 1
ThisDN B
OtherDN A
EventPartyAdded
ConnID 1
ThisDN B
OtherDN
b
C
OtherDNRole NewParty
ThirdPartyDN B
EventPartyChanged
ConnID 1
PreviousConnID 2
ThisDN C
ThirdPartyDN B
ThirdPartyDNRole
ConferencedBy
b. If only one party is added (as in the case of a simple conference call), the corresponding telephony object is
specified in OtherDN. If more than one party is added, then the corresponding telephony objects are speci-
fied in Extensions.
Table 168: Conference (Continued)
Interruption
Point
PARTY A PARTY B
* EventReleased

ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
Table 170: Application Activities for Different Types of Conference
Call Phase Two-Step Conference Conference with Calls
Merge
HOLD TInitiateConference THoldCall
CONSULTATION CALL TMakeCall
CONFERENCE TCompleteConference TMergeCalls
300 Genesys
Blind Conference (Complete Before Consulted
Party Answers)
Figure 89: Blind Conference (Complete Before Consulted Party Answers)
A
B C
Answer
Release-From-Conference Phase
*
Hold
Conference
* *
EventPartyAdded (ConnID 1)
Table 171: Blind Conference (Complete Before Consulted Party Answers)
Hold (See Table 170 on
page 299.)
EventHeld
ConnID 1
ThisDN B
OtherDN A
(See Table 170 on page 299.)
EventDialing
ConnID 2
ThisDN B
OtherDN C
*DIAL
*DIAL
CallType Consult
EventRinging
ConnID 2
ThisDN C
OtherDN B
CallType Consult
302 Genesys
Conference (See Table 170
on page 299.)
EventPartyAdded
ConnID 1
ThisDN A
OtherDN C
ThirdPartyDN B
EventReleased
ConnID 2
ThisDN B
OtherDN C
EventRetrieved
a
ConnID 1
ThisDN B
OtherDN A
EventPartyAdded
ConnID 1
ThisDN B
OtherDN C
ThirdPartyDN B
EventPartyChanged
ConnID 1
PreviousConnID 2
ThisDN C
ThirdPartyDN B
ThirdPartyDNRole
ConferencedBy
EventEstablished
ConnID 1
ThisDN C
Table 171: Blind Conference (Complete Before Consulted Party Answers) (Continued)
Note: If a call appears on the terminating party after completion of
conference, the ConnID field of EventRinging is equal to the connection
ID of the original call (ConnID 1), and EventPartyChanged is not
generated.
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN B
*DIAL
CallState OK
EventPartyDeleted
ConnID 1
ThisDN B
OtherDN A
OtherDNRole
DeletedParty
ThirdPartyDN A
ThirdPartyDNRole
DeletedBy
CallState OK
304 Genesys
Conference with Two Incoming Calls Using TMergeCalls
Figure 90: Conference with Two Incoming Calls Using TMergeCalls
A B
Conference
C
Hold
Answer
EventPartyAdded (ConnID 1) EventPartyAdded (ConnID 1)
Make Call to B
Release from Conference Phase (ConnID 1)
*
**
Table 173: Conference with Two Incoming Calls Using TMergeCalls
EventRinging
ConnID 2
ThisDN B
OtherDN C
CallState OK
EventDialing
ConnID 2
ThisDN C
OtherDN B
*DIAL
Place A on Hold (THoldCall)
EventHeld
ConnID 1
ThisDN B
OtherDN A
EventEstablished
ConnID 2
ThisDN B
OtherDN C
EventEstablished
ConnID 2
ThisDN C
OtherDN B
306 Genesys
Conference (TMergeCalls)
EventPartyAdded
ConnID 1
ThisDN A
OtherDN C
ThirdPartyDN B
EventReleased
ConnID 2
ThisDN B
OtherDN C
EventRetrieved
a
ConnID 1
ThisDN B
OtherDN A
EventPartyAdded
ConnID 1
ThisDN B
OtherDN C
ThirdPartyDN B
EventPartyChanged
ConnID 1
PreviousConnID 2
ThisDN C
ThirdPartyDN B
ThirdPartyDNRole
ConferencedBy
Table 173: Conference with Two Incoming Calls Using TMergeCalls (Continued)
Chapter 6: Call Models and Flows Handling User Data
Handling User Data
Attaching/Updating User Data to Internal Call
Figure 91: Attaching/Updating User Data to Internal Call
Interruption
Point
* EventAbandoned
ConnID 2
ThisDN B
OtherDN C
CallState OK
EventReleased
ConnID 2
ThisDN C
OtherDN B
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
OtherDN A
CallState OK
A BB
EventAttachedDataChanged (ConnID 1) EventAttachedDataChanged (ConnID 1)
Attach Data to Call
308 Genesys
Attaching/Updating User Data to Call by Third Party
Figure 92: Attaching/Updating User Data to Call by Third Party
Table 175: Attaching/Updating User Data to Internal Call
PARTY A PARTY B
Attach User Data to a Call
(TUpdateUserData)
ConnID 1
ThisDN A
ThirdPartyDN A
ConnID 1
ThisDN B
ThirdPartyDN A
A
B C
EventAttachedDataChanged EventAttachedDataChanged
Table 176: Attaching/Updating User Data to Call by Third Party
Attach User Data to a Call
(TUpdateUserData)
ConnID 1
ThisDN A
ThirdPartyDN C
ConnID 1
ThisDN B
ThirdPartyDN C
ConnID 1
ThirdPartyDN C
Table 176: Attaching/Updating User Data to Call by Third Party (Continued)
310 Genesys
Chapter 6: Call Models and Flows Special Cases
Special Cases
Outbound Call to a Busy Destination
Figure 93: Outbound Call to a Busy Destination
A
B
B Is Busy
*
Make Outbound Call
* *
Table 177: Outbound Call to a Busy Destination
PARTY A PARTY B
Make Outbound Call to B
(TMakeCall)
EventDialing
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
EventNetworkReached
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
B is busy
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
312 Genesys
Rejected Call
Call rejection can apply both to incoming and outgoing calls. However, since
most call centers forbid dropping the caller (without explaining why the call
cannot be answered), for the inbound version of this, rejection is primarily for
re-routing calls on a network level.
Generally, the rejected call scenario works either with RouteTypeDefault and
an empty destination to reject the route request (using the default route
destination as configured on the switch), or RouteTypeCallDisconnect to reject
the call. (RouteTypeReject has been deprecated since it is switch-specific.) Two
scenarios are applicable here. Figure 94 shows this with a route point involved,
and Figure 95 on page 314 shows it with a route queue.
Interruption
Point
PARTY A
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
Figure 94: Rejected Call (Route Point)
Table 179: Rejected Call (Route Point)
External Party Route Point
Place Inbound Call to
Route Point
EventRouteRequest
ConnID 1
ThisDN B
OtherDN A
CallState OK
TRouteCall
(TRouteType=TRouteCallDisconnect)
EventRouteUsed
ConnID 1
ThisDN B
OtherDN A
CallState OK
Note: ThirdPartyDN is not present for this
event.
Route Point
TRouteCall
(TRouteType = RouteTypeCallDisconnect)
314 Genesys
Figure 95: Rejected Call (Route Queue)
Table 180: Rejected Call (Route Queue)
External Party Route Queue
Place Inbound Call to
Route Point
EventQueued
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventRouteRequest
ConnID 1
ThisDN B
OtherDN A
CallState OK
Route Queue
TRouteCall
(TRouteType = RouteTypeCallDisconnect)
TRouteCall
(TRouteType=TRouteCallDisconnect)
EventRouteUsed
ConnID 1
ThisDN B
OtherDN A
CallState OK
event.
EventDiverted
ConnID 1
ThisDN B
OtherDN A
CallState Dropped
event.
Table 180: Rejected Call (Route Queue) (Continued)
External Party Route Queue
316 Genesys
Internal Call to Destination with DND Activated
Figure 96: Internal Call to Destination with DND Activated
A
B
Press DND Button Again
*
Make Call to B
Press DND Button
EventDNDOn
EventDNDOff
Release
Table 181: Internal Call to Destination with DND Activated
PARTY A PARTY B
Press DND button (TSetDNDOn)
EventDNDOn
ThisDN B
EventDialing
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
Press DND button again (TSetDNDOff)
EventDNDOff
ThisDN B
Table 181: Internal Call to Destination with DND Activated (Continued)
PARTY A PARTY B
318 Genesys
Call Forwarding (on No Answer)
Figure 97: Call Forwarding (on No Answer)
Interruption
Point
PARTY A
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
C B A
Make Call to B
EventReleased (ConnID 1) EventRinging (ConnID 1)
Answer
**
*
Table 183: Call Forwarding (on No Answer)
EventDialing
ConnID 1
ThisDN A
OtherDN B
*DIAL
EventRinging
ConnID 1
ThisDN B
OtherDN A
CallState OK
Call Forwarding
(On No Answer)
EventReleased
ConnID 1
ThisDN B
ThirdPartyDN C
OtherDN A
CallState Forwarded
EventRinging
ConnID 1
ThisDN C
OtherDN A
CallState Forwarded
EventEstablished
ConnID 1
ThisDN A
OtherDN C
EventEstablished
ConnID 1
ThisDN C
OtherDN A
320 Genesys
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
Alternate-Call Service
Figure 98: Alternate-Call Service
A
B C
Alternate
*
Hold
Table 185: Alternate-Call Service
Hold (THoldCall)
EventHeld
ConnID 1
ThisDN B
OtherDN A
Alternate (TAlternateCall)
322 Genesys
EventHeld
ConnID 2
ThisDN B
OtherDN C
EventRetrieved
a
ConnID 1
ThisDN B
OtherDN A
CallState OK
Conversation (ConnID 1)
Table 185: Alternate-Call Service (Continued)
Interruption Point PARTY A PARTY B PARTY C
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
Reconnect-Call Service
Figure 99: Reconnect-Call Service
A
B C
Reconnect
*
Hold
Any Phase of a Call (ConnID 2)
or
EventAbandoned (ConnID 2)
Table 187: Reconnect-Call Service
Hold (THoldCall) or
Transfer (TInitiateTransfer)
*
/
Conference
(TInitiateConference)
a
EventHeld
ConnID 1
ThisDN B
OtherDN A
Any Phase of a Call (ConnID 2)
324 Genesys
Reconnect (TReconnectCall)
EventReleased
ConnID 2
ThisDN B
OtherDN C
CallState OK
EventRetrieved
b
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventReleased/EventAbandoned
ConnID 2
ThisDN C
OtherDN B
CallState OK
a. For the Hicom 300 E CS switch: service is available when EventHeld is generated as a result of one of these
requests.
b. With EventRetrieved, the values for attributes ThisDNRole and ThisQueue are the same as those for the attri-
Table 187: Reconnect-Call Service (Continued)
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
Redirect-Call Service
Figure 100: Redirect-Call Service
A B C
EventDialing (ConnID 1) EventRinging (ConnID 1)
Answer
*
**
***
Redirect
Table 189: Redirect-Call Service
EventDialing
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
EventRinging
ConnID 1
ThisDN B
OtherDN A
CallState OK
Redirect (TRedirectCall)
326 Genesys
EventReleased
ConnID 1
ThisDN B
ThirdPartyDN C
OtherDN A
CallState Redirected EventRinging
ConnID 1
ThisDN C
ThirdPartyDN B
CallState Redirected
EventEstablished
ConnID 1
ThisDN A
OtherDN C
EventEstablished
ConnID 1
ThisDN C
OtherDN C
Table 189: Redirect-Call Service (Continued)
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
*** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
328 Genesys
Internal/Inbound Call with Bridged Appearance
Figure 101: Internal/Inbound Call with Bridged Appearance
A
B C
Answer
*
Make Call to B
EventBridged (ConnID 1)
* *
* * *
EventReleased (ConnID 1) EventReleased (ConnID 1) EventReleased (ConnID 1)
Bridged Appearance
Table 191: Internal/Inbound Call with Bridged Appearance
or Inbound Call
EventDialing
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
EventRinging
ConnID 1
ThisDN B
OtherDN A
CallState OK
Coverage Path
EventRinging
ConnID 1
ThisDN C
OtherDN A
CallState Covered
EventEstablished
ConnID 1
ThisDN A
OtherDN C
EventBridged
ConnID 1
ThisDN B
OtherDN A
EventEstablished
ConnID 1
ThisDN C
OtherDN A
Release
a
Release
a
EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventReleased
ConnID 1
ThisDN C
OtherDN A
CallState OK
a. Either Party A or Party C can release the call.
Table 191: Internal/Inbound Call with Bridged Appearance (Continued)
330 Genesys
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
*** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
Outbound Call from Bridged Appearance
Figure 102: Outbound Call from Bridged Appearance
A
B C
Answer
*
Make Outbound Call
EventBridged (ConnID 1)
* *
EventNetworkReached
Conversation
Bridged Appearance
Table 193: Outbound Call from Bridged Appearance
Make Outside Call
(TMakeCall)
EventDialing
ConnID 1
ThisDN A
OtherDN C
*DIAL
*DIAL
332 Genesys
EventRinging
ConnID 1
ThisDN B
OtherDN C
*DIAL
*DIAL
CallState Covered
EventBridged
ConnID 1
ThisDN B
OtherDN C
*OPT
EventNetworkReached
ConnID 1
ThisDN A
OtherDN C
*DIAL
*DIAL
Answer
EventEstablished
ConnID 1
ThisDN A
OtherDN C
*OPT
*OPT
Table 193: Outbound Call from Bridged Appearance (Continued)
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN C
CallState OK
334 Genesys
Hold/Retrieve for Bridged Appearance
Figure 103: Hold/Retrieve for Bridged Appearance
A
B C
Retrieve Call
*
Hold
EventBridged
EventHeld
EventRetrieved
Bridged Active Active
EventHeld
EventReleased
Bridged Active Active
EventRinging
Table 195: Hold/Retrieve for Bridged Appearance
Call Established between Party A and Party C, with Party B Bridged
Hold (THoldCall)
EventHeld
ConnID 1
ThisDN B
OtherDN A
EventHeld
ConnID 1
ThisDN C
OtherDN A
Retrieve Call (TRetrieveCall)
EventRetrieved
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventReleased
ConnID 1
ThisDN C
OtherDN A
CallState Bridged
EventRinging
ConnID 1
ThisDN C
OtherDN A
CallState Covered
EventBridged
ConnID 1
ThisDN C
OtherDN A
Table 195: Hold/Retrieve for Bridged Appearance (Continued)
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B or C
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventReleased
ConnID 1
ThisDN C
OtherDN A
CallState OK
336 Genesys
Internal/Inbound Call Answerable by Several Agents (Party B
Answers)
1
Figure 104: Internal/Inbound Call Answerable by Several Agents (Party B Answers)
1.Depending on the maker of the switch, the ability of multiple agents to handle a call may be known by
names such as Coverage Path or Pickup Group.
A
B C
Answer
*
* *
Make Call to B
* * *
Multiple-Agent Answering
Table 197: Internal/Inbound Call Answerable by Several Agents
(Party B Answers)
or Inbound Call
EventDialing
ConnID 1
ThisDN A
OtherDN B
*DIAL
*DIAL
EventRinging
ConnID 1
ThisDN B
OtherDN A
CallState OK
Coverage Path
EventRinging
ConnID 1
ThisDN C
OtherDN A
CallState Covered
EventEstablished
ConnID 1
ThisDN A
OtherDN B
EventEstablished
ConnID 1
ThisDN B
OtherDN A
EventReleased
ConnID 1
ThisDN C
OtherDN A
338 Genesys
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
*** EventReleased
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
Call Treatment with Routing
Figure 105: Call Treatment with Routing
A
B C
Call to B
EventTreatmentRequired (ConnID 1)
TApplyTreatment
EventTreatmentApplied (ConnID 1)
EventTreatmentEnd (ConnID 1)
TRouteCall
Answer
*OPT
*
* *
340 Genesys
Table 199: Call Treatment with Routing
PARTY A PARTY B
(Routing Point)
PARTY C
Call to B
EventDialing
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventRouteRequest
*OPT
ConnID 1
ThisDN B
OtherDN A
EventTreatmentRequired
ConnID 1
ThisDN B
OtherDN A
Treatment Instruction
(TApplyTreatment)
EventTreatmentApplied
ConnID 1
ThisDN B
TreatmentType
EventTreatmentEnd
ConnID 1
ThisDN B
TreatmentType
UserData
Route (TRouteCall)
EventRouteUsed
ConnID 1
ThisDN B
ThisQueue B
OtherDN A
ThirdPartyDN C
*OPT
ThirdPartyDNRole
Destination
*OPT
EventRinging
ConnID 1
ThisDN C
OtherDN A
CallState OK
EventEstablished
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventEstablished
ConnID 1
ThisDN C
OtherDN A
CallState OK
Table 199: Call Treatment with Routing (Continued)
PARTY A PARTY B
(Routing Point)
PARTY C
342 Genesys
Interruption
Point
* EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventAbandoned
ConnID 1
ThisDN B
ThisQueue B
OtherDN A
* * EventReleased
ConnID 1
ThisDN A
OtherDN B
CallState OK
EventAbandoned
ConnID 1
ThisDN B
ThisQueue B
OtherDN A
Chapter 6: Call Models and Flows Predictive Dialing
Predictive Dialing
Predictive Call
Figure 106: Predictive Call
A
B C
Make Predictive Call
Answer
*
***
**
Answer
344 Genesys
Table 201: Predictive Call
(TMakePredictiveCall)
EventDialing
ConnID 1
ThisDN B
ThisQueue B
OtherDN C
*DIAL
Answer
EventQueued
ConnID 1
ThisDN B
ThisQueue B
CallState OK /
AnsweringMachineDetected
a
EventDiverted
ConnID 1
ThisDN B
ThisQueue B
OtherDN C
ThirdPartyDN A
*OPT
ThirdPartyDNRole Origination
*OPT
EventRinging
ConnID 1
ThisDN A
OtherDN C
CallState OK
EventEstablished
ConnID 1
ThisDN A
OtherDN C
a. If the switch reports that a call is connected to an answering machine, T-Server also attaches a key-value
pair AnswerClass=AM to the calls UserData.
Table 201: Predictive Call (Continued)
Interruption
Point
* EventReleased
ConnID 1
ThisDN B
OtherDN C
CallState
a
346 Genesys
** EventAbandoned
ConnID 1
ThisDN B
OtherDN C
CallState OK
*** EventAbandoned
ConnID 1
ThisDN A
OtherDN C
CallState OK
a. CallState in this case may be any of the following:
CallStateGeneralError
CallStateSystemError
CallStateBusy
CallStateNoAnswer
CallStateAnsweringMachineDetected
CallStateFaxDetected
CallStateAllTrunksBusy
CallStateQueueFull
CallStateDropped
CallStateSitDetected
CallStateSitInvalidnum
CallStateSitVacant
CallStateSitIntercept
CallStateSitUnknown
CallStateSitNocircuit
CallStateSitReorder
Interruption
Point
Predictive Call with Routing
Figure 107: Predictive Call with Routing
A
B C
Answer
Route Call to A
*
****
***
**
This step may
be missing.
Answer
348 Genesys
Table 203: Predictive Call with Routing
EventDialing
ConnID 1
ThisDN B
ThisQueue B
OtherDN C
*DIAL
Answer
EventQueued
ConnID 1
ThisDN B
ThisQueue B
CallState OK / FaxDetected /
AnsweringMachineDetected
a
EventRouteRequest
ConnID 1
ThisDN B
ThisQueue B
OtherDN C
Route Call to A
(TRouteCall)
EventRouteUsed
ConnID 1
ThisDN B
OtherDN C
ThirdPartyDN A
*OPT
*OPT
EventDiverted
ConnID 1
ThisDN B
ThisQueue B
OtherDN C
ThirdPartyDN A
*OPT
*OPT
EventRinging
ConnID 1
ThisDN A
OtherDN C
CallState OK
Table 203: Predictive Call with Routing (Continued)
350 Genesys
EventEstablished
ConnID 1
ThisDN A
OtherDN C
a. If the switch reports that a call is connected to an answering machine, T-Server also attaches a key-value
pair AnswerClass=AM to the calls UserData.
Interruption
Point
* EventReleased
ConnID 1
ThisDN B
OtherDN C
CallState
a
**
and
***
EventAbandoned
ConnID 1
ThisDN B
OtherDN C
CallState OK
**** EventAbandoned
ConnID 1
ThisDN A
OtherDN C
CallState OK
Table 203: Predictive Call with Routing (Continued)
CallStateBusy
CallStateNoAnswer
CallStateQueueFull
CallStateDropped
CallStateSitVacant
CallStateSitUnknown
CallStateSitReorder
352 Genesys
Predictive Call (Connected to a Device Specified in
Extensions)
Figure 108: Predictive Call (Connected to a Device Specified in Extensions)
A B C
D
Answer
***
*
**
Answer
(Connected to a Device Specified in Extensions)
PARTY A PARTY B (ACD Group
Specified in the
Extensions of
TMakePredictiveCall)
PARTY C (Routing
Point or ACD Group)
PARTY D
EventDialing
ConnID 1
ThisDN C
ThisQueue C
OtherDN D
*DIAL
Answer
EventQueued
ConnID 1
ThisDN C
ThisQueue C
CallState
OK/AnsweringMachine-
Detected
EventDiverted
ConnID 1
ThisDN C
ThisQueue C
OtherDN D
ThirdPartyDN B
ThirdPartyDNRole
Origination
354 Genesys
EventQueued
ConnID 1
This DN B
ThisQueue B
OtherDN D
EventDiverted
ConnID 1
ThisDN B
ThisQueue B
OtherDN D
ThirdPartyDN A
*OPT
ThirdPartyDNRole
Origination
*OPT
EventRinging
ConnID 1
ThisDN A
ThisDNRole
Origination
OtherDN D
OtherDNRole
Destination
CallState OK
(Connected to a Device Specified in Extensions) (Continued)
Specified in the
Extensions of
PARTY C (Routing
Point or ACD Group)
PARTY D
Answer
(TAnswerCall)
EventEstablished
ConnID 1
ThisDN A
ThisDNRole
Origination
OtherDN D
OtherDNRole
Destination
(Connected to a Device Specified in Extensions) (Continued)
Specified in the
Extensions of
PARTY C (Routing
Point or ACD Group)
PARTY D
Interruption
Point
* EventReleased
ConnID 1
ThisDN C
OtherDN D
CallState
a
356 Genesys
** EventAbandoned
ConnID 1
ThisDN B
OtherDN D
CallState OK
*** EventAbandoned
ConnID 1
ThisDN A
OtherDN D
CallState OK
CallStateBusy
CallStateNoAnswer
CallStateQueueFull
CallStateDropped
CallStateSitVacant
CallStateSitUnknown
CallStateSitReorder
Interruption
Point
Chapter 6: Call Models and Flows Monitoring Calls
Monitoring Calls
Service Observing on Agent
A
B C
Answer
*
Inbound Call to B
See release phases in next diagrams.
Service
Observer
Conference
A
B C
Release
Service
Observer
Agent Releases First
358 Genesys
Figure 109: Service Observing on Agent
A
B C
Release
Service
Observer
External Party Releases First
A
B C
Service
Observer
EventPartyDeleted (ConnID 1) EventReleased (ConnID 1)
Observer Releases First
Table 207: Service Observing on Agent
PARTY A
(External)
PARTY B PARTY C
(Service Observer)
Inbound Call
EventRinging
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventEstablished
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventRinging
ConnID 1
ThisDN C
ThisDNRole Observer
OtherDN A
a
b
CallState Bridged
EventPartyAdded
ConnID 1
ThisDN B
OtherDN C
OtherDNRole Observer
CallState Bridged
EventEstablished
ConnID 1
ThisDN C
ThisDNRole Observer
OtherDN A
CallState Bridged
Conference
Release Phase, see description below.
a. T-Server for the NEC NEAX/APEX switch uses the party that initialized the Service Observer instead of
Party A.
b. T-Server for the NEC NEAX/APEX switch uses the role of the party that initialized the Service Observer instead
of the role of Party A.
Table 207: Service Observing on Agent (Continued)
PARTY A
(External)
PARTY B PARTY C
(Service Observer)
360 Genesys
Table 208: Agent Releases First
PARTY A
(External)
PARTY B PARTY C
(Service Observer)
EventReleased
ConnID 1
ThisDN B
CallState OK
EventPartyDeleted
ConnID 1
ThisDN C
ThisDNRole Observer
OtherDN B
CallState OK
EventReleased
ConnID 1
ThisDN C
ThisDNRole Observer
OtherDN A
CallState OK
Table 209: External Party Releases First
PARTY A
(External)
PARTY B PARTY C
(Service Observer)
External Party Releases a Call
EventPartyDeleted
ConnID 1
ThisDN B
OtherDN A
ThirdPartyDNRole Observer
a
ThirdPartyDN C
a
CallState OK
EventPartyDeleted
ConnID 1
ThisDN C
ThisDNRole Observer
OtherDN A
CallState OK
EventReleased
ConnID 1
ThisDN B
OtherDN C
CallState OK
EventReleased
ConnID 1
ThisDN C
ThisDNRole Observer
OtherDN B
CallState OK
a. The attribute contains observer information.
362 Genesys
Table 210: Observer Releases First
PARTY A
(External)
PARTY B PARTY C
(Service Observer)
Observer Releases a Call
EventPartyDeleted
ConnID 1
ThisDN B
OtherDN C
OtherDNRole Observer
ThirdPartyDNRole
DeletedBy
ThirdPartyDN C
CallState OK
EventReleased
ConnID 1
ThisDN C
ThisDNRole Observer
CallState OK
Interruption
Point
* EventAbandoned
ConnID 1
ThisDN B
OtherDN A
CallState OK
Service Observing for Agent-Initiated Call
Figure 110: Service Observing for Agent-Initiated Call
A
B C
Answer
*
Make Call to B
See release phases from the "Service Observing on Agent" call model.
Service
Observer
Conference
Answer
364 Genesys
Table 212: Service Observing for Agent-Initiated Call
EventDialing
ConnID 1
ThisDN A
ThisDNRole
Origination
OtherDN B
OtherDNRole
Destination
CallState OK
EventRinging
ConnID 1
ThisDN B
OtherDN A
CallState OK
EventRinging
ConnID 1
ThisDN C
ThisDNRole Observer
OtherDN A
a
OtherDNRole
Origination
b
CallState Bridged
Answer
EventEstablished
ConnID 1
ThisDN C
ThisDNRole Observer
CallState Bridged
Answer
EventEstablished
ConnID 1
ThisDN A
ThisDNRole
Origination
OtherDN B
OtherDNRole
Destination
CallState Bridged
EventEstablished
ConnID 1
ThisDN B
OtherDN A
CallState Bridged
EventPartyAdded
ConnID 1
ThisDN A
ThisDNRole
Origination
OtherDN B
CallState Bridged
EventPartyAdded
ConnID 1
ThisDN C
ThisDNRole Observer
OtherDN B
CallState Bridged
Conference
Release Phase, see description in Service Observer on Agent.
a. Depending on the make of the switch in use, T-Server might employ the party that
initialized the Service Observing instead of Party A.
b. Depending on the make of the switch in use, T-Server might employ the role of the
party that initialized the Service Observing instead of the role of Party A.
Interruption
Point
* EventAbandoned
ThisDN B
OtherDN A
CallState OK
Table 212: Service Observing for Agent-Initiated Call (Continued)
366 Genesys
Service Observing on Queue
Figure 111: Service Observing on Queue
A
B D
Answer
*
Inbound Call to B
See release phases from the "Service Observing on Agent" call model.
Service
Observer
Conference
C
Table 214: Service Observing on Queue
PARTY A
(External)
PARTY B PARTY C Party D
(Observer)
Inbound Call
EventQueued
ConnID 1
ThisDN B
ThisDNRole
Destination
OtherDN A
OtherDNRole
Origination
EventRinging
ConnID 1
ThisDN D
ThisDNRole Observer
OtherDN A
OtherDNRole
Origination
CallState Bridged
EventEstablished
ConnID 1
ThisDN D
ThisDNRole Observer
OtherDN A
OtherDNRole
Origination
CallState Bridged
EventDiverted
ConnID 1
ThisDN B
ThisQueue B
ThisDNRole
Destination
OtherDN A
OtherDNRole
Origination
ThirdPartyDN C
*OPT
ThirdPartyDNRole
Destination
*OPT
EventRinging
ConnID 1
ThisDN C
ThisDNRole
Destination
OtherDN A
OtherDNRole
Origination
CallState Bridged
Answer
(TAnswerCall)
EventEstablished
ConnID 1
ThisDN C
ThisDNRole
Destination
OtherDN A
OtherDNRole
Origination
CallState Bridged
Extensions:
OrigDN-1=A
OrigDN-2=D
EventPartyAdded
ConnID 1
ThisDN D
ThisDNRole Observer
OtherDN C
OtherDNRole
NewParty
ThirdPartyDN C
ThirdPartyDNRole
AddedBy
CallState Bridged
Table 214: Service Observing on Queue (Continued)
PARTY A
(External)
(Observer)
368 Genesys
EventEstablished
ConnID 1
ThisDN D
ThisDNRole Observer
OtherDN A
OtherDNRole
Origination
CallState Bridged
EventDiverted
ConnID 1
ThisDN B
ThisQueue B
ThisDNRole
Destination
OtherDN A
OtherDNRole
Origination
ThirdPartyDN C
*OPT
ThirdPartyDNRole
Destination
*OPT
EventRinging
ConnID 1
ThisDN C
ThisDNRole
Destination
OtherDN A
OtherDNRole
Origination
CallState Bridged
Answer
(TAnswerCall)
EventEstablished
ConnID 1
ThisDN C
ThisDNRole
Destination
OtherDN A
OtherDNRole
Origination
CallState Bridged
Extensions:
OrigDN-1=A
OrigDN-2=D
EventPartyAdded
ConnID 1
ThisDN D
ThisDNRole Observer
OtherDN C
OtherDNRole
NewParty
ThirdPartyDN C
ThirdPartyDNRole
AddedBy
CallState Bridged
PARTY A
(External)
(Observer)
Conference
Release Phase, see description in Service Observer on Agent.
PARTY A
(External)
(Observer)
Interruption
Point
* EventAbandoned
ConnID 1
ThisDN C
OtherDN A
CallState OK
EventReleased
ConnID 1
ThisDN D
ThisDNRole Observer
OtherDN A
CallState OK
370 Genesys
Chapter 6: Call Models and Flows Working With Queues
Working With Queues
Multiple-Queue Call Treated at an IVR Port: Treatment at IVR
Queue
Figure 112: Multiple Queue, Call Treated at an IVR Port: Treatment at IVR Queue
A
Q2 Q3
Inbound/Internal
Call to Q1
Q1
DN
(IVR)
DN
(Agent)
Answer
EventRinging
(ConnID 1)
EventEstablished
(ConnID 1)
Conversation
EventDiverted
(ConnID 1)
Agent Becomes Ready
EventRinging
(ConnID 1)
EventReleased
(ConnID 1)
EventDiverted
(ConnID 1)
EventDiverted
(ConnID 1)
Conversation
*
Answer
EventEstablished
(ConnID 1)
Table 216: Multiple Queue, Call Treated at an IVR Port:
Treatment at IVR Queue
A Q1 Q2 Q3 IVR Agent
Inbound
/Internal Call to
Q1
Call to Q1
EventDialing
ConnID 1
ThisDN A
ThisDNRole
Origination
OtherDN* Q1
OtherDNRole
Destination
EventQueued
ConnID 1
ThisDN Q1
ThisQueue Q1
OtherDN A
Call Placed in
Second
Queue
EventQueued
ConnID 1
ThisDN Q2
ThisQueue Q2
OtherDN A
Call Placed in
IVR Queue
for Treatment
When No
Agents
Ready
372 Genesys
EventQueued
ConnID 1
ThisDN Q2
ThisQueue Q2
OtherDN A
EventDiverted
ConnID 1
ThisDN Q3
ThisQueue Q3
OtherDN A
ThirdPartyDN
IVR DN
CallState
ConverseOn
EventRinging
ConnID 1
ThisDN IVR
ThisQueue Q3
OtherDN A
CallState
ConverseOn
Answer
EventEstablished
ConnID 1
ThisDN IVR
ThisQueue Q3
OtherDN A
Agent Ready
EventDiverted
ConnID 1
ThisDN RQ2
ThisQueue
RQ2
OtherDN A
ThirdPartyDN
AgentDN
EventDiverted
ConnID 1
ThisDN Q2
ThisQueue Q2
OtherDN A
ThirdPartyDN
AgentDN
EventReleased
a
ConnID 1
ThisDN IVR
ThisQueue Q3
OtherDN A
EventRinging
ConnID 1
ThisDN
AgentDN
ThisQueue Q1
OtherDN A
Treatment at IVR Queue (Continued)
Answer
EventEstablished
b
ConnID 1
ThisDN A
OtherDN AgentDN
CallState OK
Event-
Established
ConnID 1
ThisDN
AgentDN
ThisQueue Q1
OtherDN A
CallState OK
a. EventReleased can occur before an agent becomes available because the IVR finishes call treatment.
b. In some deployments, EventEstablished for party A can occur at the same time as the IVR EventEstablished, espe-
cially if a call comes through the PSTN.
Treatment at IVR Queue (Continued)
Interruption
Point
* EventReleased
OtherDN Q1
Event-
Abandoned
ConnID 1
ThisDN Q1
OtherDN A
Event-
Abandoned
ConnID 1
ThisDN Q2
OtherDN A
Event-
Abandoned
ConnID 1
ThisDN Q3
OtherDN A
EventReleased
ConnID 1
ThisDN IVR
OtherDN A
374 Genesys
Multiple-Queue Call Treated at an IVR Port: Direct Treatment
at IVR Port
Figure 113: Multiple Queue, Call Treated at an IVR Port: Direct Treatment at IVR Port
A
Q2
Answer
Answer
EventRinging
(ConnID 1)
EventEstablished
(ConnID 1)
Conversation
Q1
DN
(IVR)
DN
(Agent)
Agent Becomes Ready
EventRinging
(ConnID 1)
EventReleased
(ConnID 1)
EventDiverted
(ConnID 1)
EventDiverted
(ConnID 1)
Conversation
*
Inbound/Internal
Call to Q1
EventEstablished
(ConnID 1)
Direct Treatment at IVR Port
External Party Q1 Q2 IVR Agent
Inbound
/Internal Call to
Q1
Call to Q1
EventDialing
ConnID 1
ThisDN A
ThisDNRole
Origination
OtherDN* Q1
OtherDNRole
Destination
EventQueued
ConnID 1
ThisDN Q1
ThisQueue Q1
OtherDN A
Call Placed in
Second Queue
EventQueued
ConnID 1
ThisDN Q2
ThisQueue Q2
OtherDN A
Call Placed
Directly to IVR
Port
EventRinging
ConnID 1
ThisDN IVR
OtherDN A
CallState
ConverseOn
376 Genesys
Answer
EventEstablished
ConnID 1
ThisDN IVR
OtherDN A
Agent Ready
EventDiverted
ConnID 1
ThisDN RQ2
ThisQueue RQ2
OtherDN A
ThirdPartyDN
AgentDN
EventDiverted
ConnID 1
ThisDN Q2
ThisQueue Q2
OtherDN A
ThirdPartyDN
AgentDN
EventReleased
a
ConnID 1
ThisDN IVR
OtherDN A
EventRinging
ConnID 1
ThisDN AgentDN
ThisQueue Q1
OtherDN A
Answer
EventEstablished
b
ConnID 1
ThisDN A
OtherDN AgentDN
CallState OK
EventEstablished
ConnID 1
ThisDN AgentDN
ThisQueue Q1
OtherDN A
CallState OK
a. EventReleased can occur before an agent becomes available because the IVR finishes call treatment.
b. In some deployments, EventEstablished for party A can occur at the same time as the IVR EventEstab-
lished, especially if a call comes through the PSTN.
Direct Treatment at IVR Port (Continued)
Multiple-Queue Call: Call Removed from Queue
Figure 114: Multiple-Queue Call (Call Removed from Queue)
Interruption
Point
* EventReleased
OtherDN Q1
EventAbandoned
ConnID 1
ThisDN Q1
OtherDN A
EventAbandoned
ConnID 1
ThisDN Q2
OtherDN A
EventReleased
ConnID 1
ThisDN IVR
OtherDN A
A
Conversation
Inbound Cal to Q1
Q1
Q2
Q3
Agent Becomes Ready
DN
(Agent)
EventRinging(ConnID 1)
EventEstablished(ConnID 1)
Answer
378 Genesys
Table 220: Multiple-Queue Call (Call Removed from Queue)
A Q1 Q2 IVR Agent
Inbound Call to
Q1
Call to Q1
EventQueued
ConnID 1
ThisDN Q1
ThisQueue Q1
OtherDN A
Call Placed in
Second Queue
EventQueued
ConnID 1
ThisDN Q2
ThisQueue Q2
OtherDN A
Call Placed in
Third Queue for
Treatment When
No Agents
Ready
EventQueued
ConnID 1
ThisDN Q3
ThisQueue Q3
OtherDN A
Call Cleared
from Third
Queue
EventDiverted
ConnID 1
ThisDN Q3
ThisQueue Q3
OtherDN A
CallState Cleared
Chapter 6: Call Models and Flows Network T-Server Attended Transfer Call Flows
Network T-Server Attended Transfer
Call Flows
Standard Network Call Initiation
Figure 115 illustrates the standard call setup for a call entering a Genesys
environment through a network T-Server. The diagrams that follow it in this
section assume the completion of this stage and present common network
attended transfer scenarios and a few error cases.
Agent Ready
EventDiverted
ConnID 1
ThisDN Q1
ThisQueue Q1
OtherDN A
ThirdPartyDN
AgentDN
EventDiverted
ConnID 1
ThisDN Q2
ThisQueue Q2
OtherDN A
ThirdPartyDN
AgentDN
EventRinging
ConnID 1
ThisDN AgentDN
ThisQueue Q1
OtherDN A
CallState OK
Answer
EventEstablished
ConnID 1
ThisDN AgentDN
ThisQueue Q1
OtherDN A
CallState OK
Table 220: Multiple-Queue Call (Call Removed from Queue) (Continued)
A Q1 Q2 IVR Agent
380 Genesys
Figure 115: Standard Network Call Initiation
Consultation Leg Initiation, Specific Destination
Figure 116 illustrates the creation of the consultation leg in a case where the
destination DN and its location are provided in the TNetworkConsult() function
call.
Figure 116: Consultation Leg Initiation, Specific Destination
New Call
Agent 1 /
T-Server A
Agent 2 /
T-Server B URS
Network
T-Server SCP
EventRouteRequest
TRouteCall
Route Response
Connected
EventRouteUsed
TNetworkConsult
Get Access Number
Access Number
Consult Connected
EventNetworkCallStatus (NtwCall/DestState = Consulting/OK)
EventNetworkCallStatus (same as above)
EventNtwCallStatus (same as above)
EventRinging (NtwPartyRole = DestParty ,
NtwCall/DestState = Consulting / Delivering)
EventEstablished
Agent 1 /
T-Server A
Agent 2 /
T-Server B URS
Network
T-Server SCP
Initialize Consult
EventNetworkCallStatus (NtwCall/DestState = Consulting/Delivering)
Failed Consultation: Specific Target
In Figure 117, the request to consult has failed. Events shown with dotted lines
are distributed only when the call is delivered to the intended destination, but
not answered (for instance, when State = NoAnswer). Since the consult request
in this case is made to a specific DN and location, an explicit reconnect request
(or another TNetworkConsult request, if allowed by the given SCP) from
Agent 1 is required. Until such a request is made, the call remains in the
Consulting/NoParty state.
Figure 117: Failed Consultation: Direct Target
Consultation Leg Initiation, URS Selected Destination
Figure 118 illustrates the creation of the consultation leg in a case where the
destination DN and its location are provided by URS. In this case the original
caller is still connected to the call (speaking with Agent 1) while URS selects
the target. The caller is then placed on hold the moment the consultation leg is
created. Depending on the given SCPs capabilities, other scenarios are also
possible. For example:
The original caller might be put on hold immediately (as is the case with
conventional local two-step transfers). In such a case, the value for
NetworkState for the first event is Consulting/Routing.
TNetworkConsult
Agent 1 /
T-Server A
Agent 2 /
T-Server B
Network
T-Server SCP
EventNetworkCallStatus (NtwCallState = Consulting/Delivering)
URS
Consult Failed
Initialize Consult
EventAbandoned
Get Access Number
Access Number
EventRinging (NtwPartyRole = DestParty, NtwCall/DestState = Consulting/Delivering)
EventNetworkCallStatus (NtwCall/DestState = Consulting/NoParty,
Cause = Busy/NoAnswer/Other)
382 Genesys
The original caller might be connected to the call throughout the entire
consult and delivery phase, and then put on hold only when the destination
(Agent 2) answers the call. In this case, the second event has a value of
ConsultHeld instead of Consulting.
Figure 118: Consultation Leg Initiation, URS Selected Destination
Failed Consultation: URS Selected Destination
Figure 119 shows a failed request for consultation. Events shown with dotted
lines are distributed only when the call is delivered to the intended destination,
but not answered (for instance, when State = NoAnswer).Because URS controls
consultation initiation in this case, no explicit reconnection is required. URS
continues to offer different route targets until the consultation is connected.
(The shaded portion of the diagram may repeat several times.) At this point:
Reconnect can still occur manually.
URS can reconnect using a reject or default route instruction.
TNetworkConsult
Get Access Number
Access Number
Consult Connected
EventNetworkCallStatus (NtwCall/DestState = Consulting/OK)
EventEstablished
Agent 1 /
T-Server A
Agent 2 /
T-Server B URS
Network
T-Server SCP
Initialize Consult
EventRouteUsed
(NtwCallState =
Consulting)
TRouteCall
EventNetworkCallStatus (NtwCall/DestState = ConsultHeld/Routing)
EventRouteRequest
(NtwCallState =
ConsultHeld)
Figure 119: Failed Consultation: URS Selected Target
Transfer/Conference Completion: Explicit
Figure 120 illustrates the completion of either a network-attended transfer or
conference. It assumes that the call had a successful consultation phase for its
transfer or conference completion to be valid. This assumption is necessary
TNetworkConsult
Agent 1 /
T-Server A
Agent 2 /
T-Server B
Network
T-Server SCP
EventNetworkCallStatus (NtwCallState = Consulting/Delivering)
URS
Consult Failed
Initialize Consult
EventAbandoned
Get Access Number
Access Number
EventNetworkCallStatus (NtwCall/DestState = Consulting/Routing,
Cause = Busy/NoAnswer/GeneralError)
TRouteCall
EventRouteRequest
(NtwCallState =
ConsultHeld)
EventNetworkCallStatus (NtwCall/DestState = ConsultHeld/Routing)
EventError
TRouteCall(Reject)
EventRouteRequest
(NtwCallState =
Reconnected)
Drop Consult
Call Reconnected
EventNetworkCallStatus (NtwCallState = Reconnected)
384 Genesys
since EventNetworkCallStatus is a direct response to the TNetworkTransfer
feature request. The Network T-Server sends Agent 1 EventNetworkCallStatus
regardless of whether the call has already been released.
Figure 120: Transfer/Conference Completion: Explicit
Transfer Completion: Implicit
An implicit transfer completion occurs when Agent 1s channel becomes
disconnected and the call has a status of Consulting, ConsultHeld, or
Conferencing.
Note: This scenario applies only when the disconnection is with respect to
Agent 1. (For details on a disconnection with Agent 2, see Implicit
Reconnection (by SCP) on page 388 and Implicit Reconnection (by
Network T-Server) on page 388. For a disconnection with respect to
the caller, see Caller Abandonment on page 389.)
EventNetworkCallStatus is sent to Agent 1 only if T-Server A delays the
release of EventReleased for some reason.
TNetworkTransfer
Call Transferred
EventNetworkCallStatus (NtwCallState = Transferred)
EventReleased
Agent 1 /
T-Server A
Agent 2 /
T-Server B URS
Network
T-Server SCP
Transfer Call
Figure 121: Network Attended Transfer Completion: Implicit
Conference Completion
Figure 122 illustrates a standard conference completion.
Figure 122: Conference Completion
Alternate Call Service
Figure 123 shows alternate call service. This diagram contains two variations
of the service to show different possible network states for the events.
Leg Disconnected
Agent Hangs Up;
EventReleased
Agent 1 /
T-Server A
Agent 2 /
T-Server B URS
Network
T-Server SCP
(NtwCallState = Consulting, ConsultHeld, or Conferenced)
EventNetworkCallStatus (NtwCallState = Conferenced)
Agent 1 /
T-Server A
Agent 2 /
T-Server B URS
Network
T-Server SCP
EventNetworkCallStatus (NtwCallState = Consulting or ConsultHeld)
TNetworkMerge
Calls Merged
Merge Calls
386 Genesys
Figure 123: Alternate Call Service
Alternate Call Service with Transfer Completion
Figure 124 demonstrates the applicability of TNetworkTransfer after the use of
the alternate call service.
Note: TNetworkConference, TNetworkReconnect, and the implicit form of
transfer completion are also available after an instance of the alternate
call service.
TNetworkAlternate
Calls Swapped
Agent 1 /
T-Server A
Agent 2 /
T-Server B
Network
T-Server SCP
Alternate Calls
EventNetworkCallStatus (NtwCallState = ConsultHeld)
EventNetworkCallStatus (NtwCallState = Consulting)
URS
Calls Swapped
Alternate Calls
TNetworkAlternate
Figure 124: Alternate Call Service with Transfer Completion
Reconnection
The following three figures show the call flows for reconnecting the caller to
Agent 1. As with transfer completion, reconnection has both explicit
(Figure 125) and implied (Figure 126 and Figure 127 on page 389) forms. In
fact, the only difference between the implicit form for network transfer and
network reconnect is a partys relationship to the original call. If the
controlling agent disconnects, the action is considered a transfer. If the
destination agent disconnects, it is considered a reconnection.
TNetworkAlternate
Call Transferred
Agent 1 /
T-Server A
Agent 2 /
T-Server B
Network
T-Server SCP
Transfer Call
EventNetworkCallStatus (NtwCallState = ConsultHeld)
URS
Calls Swapped
Alternate Calls
TNetworkTransfer
EventReleased
388 Genesys
Explicit Reconnect
Figure 125: Network Attended Reconnect: Explicit
Implicit Reconnection (by SCP)
Figure 126: Network Attended Reconnect: Implicit by SCP
Implicit Reconnection (by Network T-Server)
In some cases, if Agent 2 disconnects while the consultation call is on hold,
SCP leaves the consultation leg to be dropped manually. Although this
operation then becomes the responsibility of the Network T-Server, the client
may get a notification regarding an intermediate state, as shown in Figure 127.
TNetworkReconnect
Agent 1 /
T-Server A
Agent 2 /
T-Server B
Network
T-Server SCP
URS
EventNetworkCallStatus (any NetworkState)
Leg Disconnected
Drop Call
EventReleased
Agent 1 /
T-Server A
Agent 2 /
T-Server B
Network
T-Server SCP
URS
Leg Disconnected
Agent Hangs Up:
EventReleased
Figure 127: Network Attended Reconnect: Implicit by Network T-Server
Caller Abandonment
Figure 128 illustrates a caller abandonment scenario. If at any time during a
multi-party call the origination party disconnects, the SCP may choose to end
the call outright, or send a leg disconnected message.
Figure 128: Caller Abandonment
Agent 1 /
T-Server A
Agent 2 /
T-Server B
Network
T-Server SCP
EventNetworkCallStatus (NtwCall/DestState = ConsultHeld/NoParty)
URS
Leg Disconnected
Agent Hangs Up:
EventReleased
Alternate Calls
Drop Consult
Call Reconnected
Leg Disconnected
EventNetworkCallStatus (NtwCallState = Disconnected)
Agent 1 /
T-Server A
Agent 2 /
T-Server B URS
Network
T-Server SCP
(NtwCall/DestState = Consulting, ConsultHeld, or Conferenced)
390 Genesys
Network Single-Step Transfer
For single-step transfers, the operation is complete immediately after the new
call leg is created. Thus, for the external observer, there is no consultation
phase.
Figure 129: Network Attended Single-Step Transfer
Premature Disconnection, One Variation
If an agent disconnects the call prior to completion of the consultation leg, a
number of things can happen, depending on the current state of the
consultation. One variation is detailed in Figure 130. In this case, the
disconnection occurs prior to the SCP being aware of a pending consultation.
The message from the SCP is likely to be Call Dropped, as only the caller
would remain on the call.
TNetworkSingleStepTransfer
Call Transferred
EventNetworkCallStatus (NtwCall/DestState = Transferred/Delivering)
EventReleased
Agent 1 /
T-Server A
Agent 2 /
T-Server B URS
Network
T-Server SCP
Initialize Consult
Get Access Number
Access Number
Transfer Call
EventNetworkCallStatus (NtwCall/DestState =
Transferred/OK)
EventRinging (NtwPartyRole = DestParty, NtwCall/DestState = Transferred/Delivering)
Consult Connected
EventEstablished
Figure 130: Premature Disconnection 1
Premature Disconnection, a Second Variation
Figure 131 shows Agent 1 disconnecting after the SCP has been notified of a
call, but prior to its connection (or failure). Since the state of the consultation is
not known, the call considered to have transferred. The SCP at this point
should connect the original caller with the consultation target. The call at this
point is treated identically to a normal inbound call that is waiting for its
connection status from the SCP. The network attended session is complete, and
no further NetworkCallStatus events are distributed.
If the delivery results in failure (or a NoAnswer condition), URS should re-route
the call to a different target. However, if the call was intended for an explicitly
specified target (and URS is not in control of the consultation leg), any call
status other than Connected results in default routing instructions being
returned to the SCP, and the call ending.
Leg Disconnected
or Call Dropped
EventNetworkCallStatus (NtwCallState = Null)
Agent 1 /
T-Server A
Agent 2 /
T-Server B URS
Network
T-Server SCP
TNetworkConsult
EventNetworkCallStatus (NtwDestState = Routing)
EventRouteRequest
(NtwCallState =
Consulting/ConsultHeld)
Event Abandoned Agent Hangs Up;
EventReleased
392 Genesys
Figure 131: Premature Disconnection: a Second Variation
Transactional Error
A T-Library client is required to wait for a network status message prior to
attempting further call control. This message is either the next status message
after making its network request or EventError. Failure to abide by this results
in an error being returned to the requestor.
Figure 132: Transactional Error
Leg Disconnected
Agent 1 /
T-Server A
Agent 2 /
T-Server B URS
Network
T-Server SCP
TNetworkConsult
EventNetworkCallStatus (NtwDestState = Routing)
EventRouteRequest
(NtwCallState =
Consulting/ConsultHeld)
Agent Hangs Up;
EventReleased
TRouteCall
Get Access Number
Access Number
Initialize Consult
Agent 1 /
T-Server A
Agent 2 /
T-Server B URS
Network
T-Server SCP
TNetworkConsult
Initialize Consult
EventError
TNetworkTransfer
Chapter
7 Basic Interaction Models
This chapter presents models representing basic tasks that the Multimedia
components perform. It consists of these sections:
Overview, page 393
Registration, page 394
Media Server Submits Interaction, page 396
Agent Submits Interaction, page 397
Stop Processing, page 399
Change Properties, page 404
Place Interaction in Queue, page 408
Place Interaction in Workbin, page 409
Deliver Interaction to Agent, page 411
Agent Pulls Interaction, page 414
Transfer, page 418
Conference, page 421
Workbin Operations, page 427
Snapshot Operations, page 430
Intrusion, page 433
Login/Logout, page 437
Reporting Engine Connects, page 440
Disconnection and Failover, page 441
Invoke Autoresponse, page 444

Overview
This chapter presents interaction models in terms of scenarios. Some scenarios
are made up of a single model. Others consist of several models that represent
different temporal phases. Others collect several models that represent
different but related versions of a single general scenario.
394 Genesys
Chapter 7: Basic Interaction Models Registration
The events that occur in each model are all documented in Open Media
Interaction Models documentation.
Registration
This set of models illustrates successful and unsuccessful registration.
Successful registration proceeds as follows:
1. A client connects to Interaction Server.
2. The client asks to register.
3. Interaction Server checks to see if the client is valid. If the client is valid,
Interaction Server sends EventAck.
Unsuccessful registration proceeds as follows:
1. A client connects to Interaction Server.
2. One of the following happens:
The client asks to register, but Interaction Server finds that it is not a
valid client.
The client sends any other message to Interaction Server.

3. In either case, Interaction Server returns EventError.
4. When a timeout expires, Interaction Server disconnects.
Successful Registration
In this phase, shown in Figure 133, a client connects, then asks to register.
Figure 133: Successful Registration
Interaction Server Any client
Connect
RequestRegisterClient
Set timer
Check client
EventAck
Cancel timer
Chapter 7: Basic Interaction Models Registration
This phase uses the messages listed in Table 221.
Unsuccessful Registration
In this phase, shown in Figure 134, Interaction Server finds that the client is
not valid. It may do this in response to RequestRegisterClient or to any other
message from the client. In any case, Interaction Server responds with
EventError, then disconnects from the client.
Figure 134: Unsuccessful Registration
Table 221: Messages in Successful Registration
Message Protocol
EventAck Interaction Management
Any client Interaction Server
Connect
Set timer
RequestRegisterClient
EventError
Any message
EventError
(not registered)
Timer
Disconnect
(server initiated)
Check client
Either this step
or the next or
both.
396 Genesys
Chapter 7: Basic Interaction Models Media Server Submits Interaction
Figure 134 actually contains three possible versions:
a. Client sends RequestRegisterClient, Interaction Server finds that the
client is not valid, Interaction server returns EventError.
b. Client sends any message Interaction Server finds that the client is not
registered, Interaction server returns EventError.
c. First a, then b.
Media Server Submits Interaction
This set of models illustrates the following scenario:
1. A media server asks to submit an interaction to Interaction Server.
Interaction Server checks the interactions parameters. If the parameters
are correct, Interaction Server accepts the request.
2. If Interaction Server discovers that the parameters are incorrect, it rejects
the request.
Media Server Asks to Submit
In this phase, shown in Figure 135, a media server sends RequestSubmit to
Interaction Server.
Figure 135: Media Server Asks to Submit
Table 222: Messages in Unsuccessful Registration
Message Protocol
EventError Interaction Management
Media server Interaction Server Reporting engine
RequestSubmit
EventInteractionSubmitted
Check parameters
EventAck
Chapter 7: Basic Interaction Models Agent Submits Interaction
Unsuccessful Submission by Media Server
In this phase, shown in Figure 136, Interaction Server discovers a problem,
such as that the media server is not registered as a client, or that there is a error
in one of the attributes of RequestSubmit.
Figure 136: Unsuccessful Submission by Media Server
Agent Submits Interaction
1. An agent asks to submit an interaction.
2. Interaction Server checks the validity of the agent application.
Table 223: Messages in Media Server Asks to Submit
Message Protocol
EventInteractionSubmitted Reporting
Table 224: Messages in Unsuccessful Submission by Media
Server
Message Protocol
Media server Interaction Server
RequestSubmit
EventError
Check parameters
398 Genesys
Chapter 7: Basic Interaction Models Agent Submits Interaction
If the agent application is valid, Interaction Server accepts the

submission and informs the reporting engine.
If the agent application is not valid, Interaction Server rejects the

submission.
Successful Submission
A successful submission is shown in Figure 137.
.
Figure 137: Successful Submission by Agent
This model uses the messages listed in Table 225.
Unsuccessful Submission
An unsuccessful submission is shown in Figure 138.
Table 225: Messages in Successful Submission by Agent
Message Protocol
EventPartyAdded Reporting
Interaction Server Agent application Reporting engine
RequestSubmit
Check parameters
EventAck
EventPartyAdded
EventInteractionSubmitted
Chapter 7: Basic Interaction Models Stop Processing
Figure 138: Unsuccessful Submission by Agent
Stop Processing
This scenario has several versions, depending on these two points:
Which entity initiates the stop processing request: media server, agent, or
URS
If a media server initiates the request, there is a further difference
according to whether an agent or URS is involved in processing.
This produces four possible versions, called A, B, C, and D in this section:
AInitiated by media server, agent involved in processing
B (page 400)Initiated by media server, URS involved in processing
C (page 401)Initiated by agent
D (page 402)Initiated by URS
A: Initiated by Media Server, Agent Involved
In this version, shown in Figure 139, an agent is processing the interaction
when a media server asks for processing to stop.
Table 226: Messages in Unsuccessful Submission by Agent
Message Protocol
Interaction Server Agent application
RequestSubmit
EventError
Check parameters
400 Genesys
Figure 139: Stop Processing A: Media Server Initiates, Agent Involved
This version uses the messages listed in Table 227.
B: Initiated by Media Server, URS Involved
In this version, shown in Figure 140, URS is processing the interaction when a
media server asks for processing to stop.
Interaction Server Agent application Reporting engine Media server
RequestStopProcessing
Check interaction
EventRevoked
EventProcessingStopped
EventAck
EventPartyRemoved
for each party processing the
interaction
(including strategy)
Table 227: Messages in Stop Processing A
Message Protocol
EventPartyRemoved Reporting
EventProcessingStopped Reporting
EventRevoked Interaction Management
Figure 140: Stop Processing B: Media Server Initiates, URS Involved
This model uses the T-Library EventRouteUsed to stand in for the Interaction
Management EventRevoked.
C: Initiated By Agent
In this version, shown in Figure 141, an agent initiates the stop processing
request.
Interaction Server URS Reporting engine Media server
Check interaction
EventRevoked (EventRouteUsed)
EventAck
EventPartyRemoved
for each party processing the
interaction
(including strategy)
Table 228: Messages in Stop Processing B
Message Protocol
EventAbandoned, used
here in place of
EventRevoked
T-Library
402 Genesys
Figure 141: Stop Processing C: Initiated by Agent
D: Initiated by URS
In this version, shown in Figure 142, URS initiates the stop processing request.
Check interaction
EventAck
EventRevoked
to all other
agents involved
EventPartyRemoved
for each party
processing the
interaction
only if media server
registered to receive such
notification
Table 229: Messages in Stop Processing C
Message Protocol
Figure 142: Stop Processing D: Initiated by URS
This phase uses the T-Library RequestRouteCall to stand in for the Interaction
Management RequestStopProcessing. It also uses the T-Library
EventRouteUsed to stand in for the Interaction Management EventAck.
Unsuccessful
In this version, shown in Figure 143, Interaction Server finds that the request is
invalid and rejects it.
Interaction Server URS Reporting engine Media server
RequestStopProcessing (RequestRouteCall)
Check interaction
EventAck (EventRouteUsed)
EventPartyRemoved
for
strategy
notification
Table 230: Messages in Stop Processing D
Message Protocol
EventRouteUsed, used
here in place of EventAck
T-Library
404 Genesys
Chapter 7: Basic Interaction Models Change Properties
Figure 143: Stop Processing: Unsuccessful
Change Properties
This scenario has several versions, differentiated first of all according to which
entity initiates the request to change properties:
Media server initiates the request
While an agent is processing the interaction.
While URS is processing the interaction.

URS initiates the request (only while URS is processing).
Media Server Requests While Agent is Processing
In this phase, shown in Figure 144, a media server asks to change the
properties of an interaction. Interaction Server informs the reporting engine
and the agent who is processing the interaction.
Table 231: Messages in Stop Processing: Unsuccessful
Message Protocol
Interaction Server Media server or
Agent application
Check interaction
EventError
Figure 144: Media Server Requests While Agent is Processing
This phase uses the messages shown in Table 232.
Media Server Requests While URS is Processing
In this phase, shown in Figure 145, a media server asks to change the
properties of an interaction. Interaction Server informs the reporting engine
and URS, which is processing the interaction.
RequestChangeProperties
Check interaction
EventPropertiesChanged
EventAck
Table 232: Messages in Media Server Requests While Agent is
Processing
Message Protocol
EventPropertiesChanged Interaction Management
406 Genesys
Figure 145: Media Server Requests While URS is Processing
This phase uses the T-Library EventAttachedDataChanged to stand in for the
Interaction Management EventPropertiesChanged.
URS Requests
In this phase, shown in Figure 146, URS changes the interaction properties. If
the media server has included the extension event_properties_changed, with
nonzero value, in its RequestRegisterClient message, then Interaction Server
sends EventProperitesChanged informing it of the change.
Interaction Server URS Reporting engine Media Server
Check interaction
(EventAttachedDataChanged)
EventAck
Table 233: Messages in Media Server Requests, URS is
Processing
Message Protocol
EventAck Interaction
Management
EventAttachedDataChanged,
used here in place of
T-Library
Figure 146: URS Requests
This phase uses the T-Library RequestUpdateUserData to stand in for the
Interaction Management RequestChangeproperties. It also uses the T-Library
EventAttachedDataChanged to stand in for the Interaction Management
EventAck.
Unsuccessful Request
In this phase, shown in Figure 147, Interaction Server finds that the request is
invalid.
Interaction Server URS Reporting engine Media Server
(RequestUpdateUserData)
Check interaction
notification
EventAck
(EventAttachedDataChanged)
Table 234: Messages in URS Requests
Message Protocol
EventAttachedDataChanged,
used here in place of
EventAck
T-Library
EventPropertiesChanged Interaction
Management
408 Genesys
Chapter 7: Basic Interaction Models Place Interaction in Queue
Figure 147: Unsuccessful
Place Interaction in Queue
In this model, shown in Figure 148, URS requests Interaction Server to place
an interaction in a queue.
Figure 148: Place Interaction in Queue
Table 235: Messages in Unsuccessful
Message Protocol
Interaction Server Media Server
Check interaction
EventError
Interaction Server URS Reporting engine
RequestPlaceInQueue (RequestRouteCall)
EventPlacedInQueue
EventPartyRemoved (strategy)
Chapter 7: Basic Interaction Models Place Interaction in Workbin
Note: The agent application can also make the request to place an interaction
in a queue. In that case the model would look the same, except that
Interaction Server would simply send EventAck rather than
EventRouteUsed.
This model uses the following substitutions:
T-Library EventRouteUsed stands in for Interaction Management
EventAck.
T-Library RequestRouteCall stands in for Interaction Management
RequestPlaceInQueue.
Place Interaction in Workbin
In this model, shown in Figure 149, URS asks Interaction Server to place an
interaction in a workbin.
Table 236: Messages in Place Interaction in Queue
Message Protocol
EventPlacedInQueue Reporting
EventRouteUsed, used here in place of EventAck T-Library
410 Genesys
Chapter 7: Basic Interaction Models Place Interaction in Workbin
Figure 149: Place Interaction in Workbin
Note: The agent application can also make the request to place an interaction
in a workbin. In that case the model would look the same, except that
Interaction Server would simply send EventAck rather than
EventRouteUsed.
This model uses the following substitutions:
T-Library EventRouteUsed stands in for Interaction Management
EventAck.
Interaction Server Agent application URS Reporting engine
RequestPlaceInWorkbin (RequestRouteCall)
EventPlacedInQueue
EventWorkbinContent
Changed
To all subscribers
that issued
RequestWorkbin
Notifications
EventPlacedInWorkbin
EventPartyRemoved (strategy)
Table 237: Messages in Place Interaction in Workbin
Message Protocol
EventPlacedInWorkbin Reporting
EventRouteUsed, used here in place of EventAck T-Library
EventWorkbinContentChanged Interaction Management
Chapter 7: Basic Interaction Models Deliver Interaction to Agent
T-Library RequestRouteCall stands in for Interaction Management
RequestPlaceInWorkbin.
Deliver Interaction to Agent
1. URS asks Interaction Server to attempt to deliver an interaction to an
agent.
2. Then one of the following happens:
a. The agent accepts the interaction.
b. The agent rejects the interaction.
c. The agent fails to respond.
URS Requests Delivery
In this phase, shown in Figure 150, URS sends RequestRouteCall to
Interaction Server, specifying the agent and place to receive the interaction.
Then Interaction Server sends EventInvite to the agent application and sets a
timer.
Figure 150: URS Requests Delivery
Interaction Server Agent application URS Reporting engine
RequestRouteCall
EventInvite
EventPartyRemoved
EventAgentInvited
Set timer
EventRouteUsed
412 Genesys
The second phase of this scenario can have one of the following three forms.
Agent Accepts Delivery
In this version of the second phase, shown in Figure 151, the agent application
accepts delivery of the interaction, and Interaction Server sends
EventRouteUsed to URS, informing it that its Deliver request has been filled.
Interaction Server also cancels the timer that it started in the previous phase.
Figure 151: Agent Accepts Delivery
Table 238: Messages in URS Requests Delivery
Message Protocol
EventAgentInvited Reporting
EventInvite Interaction Management
EventRouteUsed T-Library
RequestAccept
EventPartyAdded (Agent)
EventAck
Cancel timer
Table 239: Messages in Agent Accepts Delivery
Message Protocol
There are two ways that the delivery attempt can fail, shown in the next
sections.
Agent Rejects Delivery
In this version of the second phase, rather than accepting the interaction as in
Figure 151 on page 412, the agent rejects the interaction using RequestReject,
as shown in Figure 152. Interaction Server cancels the timer, acknowledges
RequestReject using EventAck, and informs URS of the situation with
EventRouteUsed.
Figure 152: Agent Rejects Delivery
Agent Fails to Respond in Time
In the first phase of this scenario, Interaction Server set a timer. In this version
of the second phase, shown in Figure 153, the agent application does not
respond within the time set and Interaction Server revokes the interaction.
RequestReject
EventRejected
EventAck
Cancel timer
Table 240: Messages in Agent Rejects Delivery
Message Protocol
EventRejected Reporting
414 Genesys
Chapter 7: Basic Interaction Models Agent Pulls Interaction
Figure 153: Time Limit Reached
Agent Pulls Interaction
1. Agent application asks to pull an interaction:
a. From some place other than a workbin.
b. From a workbin.
2. Some processing activity occurs.
3. Timeout: Processing activity stops (or never occurred).
Agent Issues Pull Request
This phase has two versions, depending on whether the interaction is to be
pulled from a workbin or from some other location.
From Non-Workbin
In this version of the first phase, shown in Figure 154, the interaction is pulled
from somewhere other than a workbin (most likely a queue). Notice that
EventRevoked
EventRevoked
Timer expires
Table 241: Messages in Time Limit Reached
Message Protocol
Interaction Server starts a timer, which continues running into the following
phases.
Figure 154: Agent Pulls From Non-Workbin
From Workbin
In this version of the first phase, shown in Figure 155, the interaction is pulled
from a workbin.
Table 242: Messages in Agent Pulls From Non-Workbin
Message Protocol
EventPulledInteractions Interaction Management
EventTakenFromQueue Reporting
Agent application Interaction Server Reporting engine
RequestPull
Check interaction
EventPulledInteractions
Set timer
EventPartyAdded
EventTakenFromQueue
416 Genesys
Figure 155: Agent Pulls Interaction From Workbin
This version uses the same messages as the previously-described version, plus
two more. All are listed in Table 243.
Processing Occurs
In this phase, shown in Figure 156, Interaction Server resets its timer each time
it receives a request from the agent application. The interaction remains with
the agent as long as the agent continues to send requests.
Table 243: Messages in Agent Pulls From Workbin
Message Protocol
EventPulledInteractions Interaction Management
EventTakenFromQueue Reporting
EventTakenFromWorkbin Reporting
EventWorkbinContentChanged Interaction Management
to any agent application
registered to receive
notification of change in
workbin content
RequestPull
Check interaction
EventPulledInteractions
Set timer
EventWorkbinContentChanged
EventPartyAdded
EventTakenFromQueue
EventTakenFromWorkbin
Figure 156: Processing Occurs
This phase uses any request from the Interaction Management Protocol.
No Processing: Timeout
In this phase, shown in Figure 157, the timer expires and Interaction Server
revokes the interaction.
Figure 157: No Processing: Timeout
Any interaction management
protocol request
Cancel timer
Set timer
Table 244: Messages in No Processing: Timeout
Message Protocol
Timer expires
EventRevoked
Make available
for Pull
EventPartyRemoved
418 Genesys
Chapter 7: Basic Interaction Models Transfer
Transfer
1. One agent invites another to accept a transfer.
a. The second agent accepts the invitation and the transfer completes.
b. The second agent rejects the invitation.
c. There is no response and the invitation times out.
d. Interaction Server finds that either the first agent application or the
interaction is invalid.
Invitation Issued
In this phase, shown in Figure 158, Agent 1 asks Interaction Server to invite
Agent 2 to accept a transfer.
Figure 158: Transfer Invitation Issued
This phase uses the messages shown in listed in Table 245.
Agent application 1 Agent Application 2 Interaction Server Reporting engine
RequestTransfer
Check agent &
interaction
Set timer
EventInvite
EventAgentInvited
Table 245: Messages in Transfer Invitation Issued
Message Protocol
Invitation Accepted
In this phase, shown in Figure 159, Agent 2 accepts the transfer.
Figure 159: Transfer Invitation Accepted
Invitation Rejected
In this phase, shown in Figure 160, Agent 2 rejects the invitation.
Cancel timer
EventAck
EventAck
EventPartyAdded (Agent 2)
EventPartyRemoved (Agent 1)
Also sent to
other parties (if
any)
RequestAccept
Table 246: Messages in Transfer Invitation Accepted
Message Protocol
420 Genesys
Figure 160: Transfer Invitation Rejected
Invitation Times Out
In this phase, shown in Figure 161, Agent 2 does not respond within the
timeout period, so Interaction Server revokes the invitation.
Figure 161: Transfer Invitation Times Out
RequestReject
Cancel timer
EventRejected
EventAck
EventError
Table 247: Messages in Transfer Invitation Rejected
Message Protocol
Timeout
EventRevoked
EventRevoked
EventError
Chapter 7: Basic Interaction Models Conference
Invitation Is Invalid
In this phase, shown in Figure 162, Interaction Server finds that either the
agent or the interaction is not valid (for example, the agent is not registered
with Interaction Server).
Note: This phase replaces, rather than follows, the initial phase Invitation
Issued on page 418.
Figure 162: Transfer Invitation Is Invalid
Conference
1. One agent invites another to join a conference.
Table 248: Messages in Transfer Invitation Times Out
Message Protocol
Table 249: Messages in Transfer Invitation Is Invalid
Message Protocol
Agent application 1 Interaction Server
RequestTransfer
Check agent &
interaction
EventError
422 Genesys
a. The second agent accepts the invitation and joins the conference.
b. The second agent rejects the invitation.
c. There is no response and the invitation times out.
d. Interaction Server finds that either the first agent application or the
interaction is invalid.
If the second agent accepts, the conference proceeds until:
3. The second agent then attempts to leave the conference, successfully or
not.
Invitation Issued
In this phase, shown in Figure 163, Agent 1 invites Agent 2 to join a
conference.
Figure 163: Conference Invitation Issued
Agent application 1 Agent application 2 Interaction Server Reporting engine
RequestConference
Check agent &
interaction
EventInvite
EventAgentInvited
Set timer
Table 250: Messages in Conference Invitation Issued
Message Protocol
Invitation Accepted
In this phase, shown in Figure 164, Agent 2 accepts the invitation and
Interaction Server informs all parties to the interaction that Agent 2 has joined.
Figure 164: Conference Invitation Accepted
RequestAccept
Cancel timer
EventAck
EventAck
Also sent to
other parties (if
any)
Table 251: Messages in Conference Invitation Accepted
Message Protocol
EventPartyAdded Reporting and
Interaction Management
424 Genesys
Invitation Rejected
In this phase, shown in Figure 165, Agent 2 rejects the invitation.
Figure 165: Conference Invitation Rejected
Invitation Times Out
In this phase, shown in Figure 166, Agent 2 does not respond within the
timeout period, so Interaction Server revokes the invitation.
RequestReject
Cancel timer
EventRejected
EventAck
EventError
Table 252: Messages in Conference Invitation Rejected
Message Protocol
Figure 166: Conference Invitation Times Out
Invitation Is Invalid
agent or the interaction is not valid (for example, the agent is not registered
with Interaction Server).
Note: This phase replaces, rather than follows, the initial phase Invitation
Issued on page 422.
Figure 167: Conference Invitation Is Invalid
Timeout
EventError
EventRevoked
EventRevoked
Table 253: Messages in Conference Invitation Time Out
Message Protocol
Agent application 1 Interaction Server
RequestConference
Check agent &
interaction
EventError
426 Genesys
Leave the Conference
In this phase, shown in Figure 168, Agent 2 leaves the conference.
Figure 168: Leave the Conference
When the last party leaves the interaction, Interaction Server returns the
interaction to its former location and informs the Reporting engine.
Table 254: Messages in Conference Invitation Is Invalid
Message Protocol
Agent Application 2 Interaction Server Agent application 1 Reporting engine
RequestLeaveInteraction
Check agent &
interaction
EventAck
Also sent to
other parties (if
any)
EventPlacedIn<location>
Table 255: Messages in Leave the Conference
Message Protocol
EventPartyRemoved Interaction Management
Chapter 7: Basic Interaction Models Workbin Operations
Fail to Leave the Conference
In this phase, shown in Figure 169, Agent 2 attempts to leave the conference,
but Interaction Server rejects the request.
Figure 169: Fail to Leave the Conference
Workbin Operations
This set of models illustrates the following two ways that an agent application
can interact with a workbin:
Get content from the workbin
Register to receive notification when the workbins content changes.
EventPlacedInWorkbin Reporting
Table 255: Messages in Leave the Conference (Continued)
Message Protocol
Table 256: Messages in Fail to Leave the Conference
Message Protocol
Agent Application 2 Interaction Server Agent application 1
RequestLeaveInteraction
Check agent &
interaction
EventError
428 Genesys
Agent Gets Workbin Content
In this phase, shown in Figure 170, the agent application requests and receives
data on the interactions that the workbin contains.
Figure 170: Agent Gets Workbin Content
Agent Fails to Get Workbin Content
In this phase, shown in Figure 171, Interaction Server rejects the agents
request for workbin data. This happens when either the agent or the workbin is
not registered with Interaction Server.
Figure 171: Agent Fails to Get Workbin Content
Table 257: Messages in Agent Gets Workbin Content
Message Protocol
EventWorkbinContent Interaction Management
RequestGetWorkbinContent
Check work bin &
agent
EventWorkbinContent
EventError
RequestGetWorkbinContent
Check work bin &
agent
Agent Requests Workbin Notification
In this phase, shown in Figure 172, the agent asks to be notified of all future
changes in the contents of a specified workbin.
Figure 172: Agent Requests Workbin Notification
Interaction Server checks that both the workbin and the agent are registered
with it.
If either is unknown to Interaction Server, it returns EventError.
If both are registered, Interaction returns EventAck to the agent.
Agent Cancels Workbin Notifications
In this phase, shown in Figure 173, the agent cancels its subscription for
workbin notification.
Table 258: Messages in Agent Fails to Get Workbin Content
Message Protocol
Table 259: Messages in Agent Requests Workbin Notification
Message Protocol
RequestWorkbinNotifications
Check work bin &
agent
EventAck
430 Genesys
Chapter 7: Basic Interaction Models Snapshot Operations
Figure 173: Agent Cancels Workbin Notifications
If either the workbin or the agent is unknown to Interaction Server, or if the
agent has not subscribed for workbin notification, Interaction Server returns
EventError.
Snapshot Operations
This set of models illustrates various operations on snapshots. A snapshot is a
list of all of the interactions in the Interaction Servers database that meet
specified conditions at a given time. The agent application requests a snapshot
from Interaction Server and uses the results to populate the list of interactions
that display on the Agent or Supervisor desktop. The operations that are
illustrated in this section are:
1. Take a snapshot
2. Get snapshot interactions
3. Lock/unlock
4. Release snapshot
Take a Snapshot
In this phase, shown in Figure 174, the agent application defines a set of
conditions and requests a snapshot of the interactions that meet the conditions.
Table 260: Messages in Agent Cancels Workbin Notifications
Message Protocol
RequestCancelWorkbinNotifications
EventAck
Figure 174: Take a Snapshot
Get Snapshot Interactions
In this phase, shown in Figure 175, the agent application requests the content
of a previously taken snapshot; that is, information about the interactions that
are included in the snapshot.
l;k
Figure 175: Get Snapshot Interactions
Table 261: Messages in Take a Snapshot
Message Protocol
EventSnapshotTaken Interaction Management
Agent application Interaction Server
RequestTakeSnapshot
EventSnapshotTaken (id=x)
EventSnapshotInteractions
RequestGetSnapshotInteractions (id=x)
432 Genesys
Lock or Unlock Interactions
In this phase, shown in Figure 176, an agent application asks Interaction Server
to lock or unlock an interaction. Locked interactions are not visible to views
and can not be pulled from queues by URS or an agent.
Figure 176: Lock or Unlock Interactions
Release Snapshot
In this phase, shown in Figure 177, an agent application asks Interaction Server
to release a specified snapshot; that is, to unlock any interactions that were
locked in the context of this snapshot.
Table 262: Messages in Get Snapshot Interactions
Message Protocol
EventSnaphotInteractions Interaction Management
Table 263: Messages in Lock or Unlock Interactions
Message Protocol
RequestLockInteraction
or
RequestUnlockInteraction
EventAck
Interactions can
be locked only in
the context of a
snapshot.
Chapter 7: Basic Interaction Models Intrusion
Figure 177: Release Snapshot
Intrusion
Intrusion is like a conference, except that a conference is initiated by an entity
that is already a party to the interaction, while intrusion is initiated by an entity
that is not a party to the interaction. Therefore intrusion may also be described
as an externally-initiated conference. This set of models illustrates the
following scenario:
1. While Agent 1 is processing an interaction, Agent 2 asks to join in a
conference.
a. The conference is set up and proceeds.
b. Agent 2 declines the conference.
c. The request times out.
d. Interaction Server rejects Agent 2s request.
Intrusion Requested
In this phase, shown in Figure 178, Agent 2 asks to join an interaction that is
already being processed by Agent 1. Interaction Server responds by sending
EventInvite to Agent 2.
Table 264: Messages in Release Snapshot
Message Protocol
RequestReleaseSnapshot
EventAck
434 Genesys
Figure 178: Intrusion Requested
Intrusion Accepted
In this phase, shown in Figure 179, Agent 2 accepts the invitation to join the
interaction. Interaction Server responds with two instances of EventAck: the
first one acknowledges the agents RequestAccept from this phase, the other
acknowledges the agents RequestIntrude from the preceding phase.
Agent application 2 Interaction Server Agent application 1 Reporting engine
RequestIntrude
Check agent &
interaction
EventInvite
EventAgentInvited
Set timer
Table 265: Messages in Intrusion Requested
Message Protocol
Figure 179: Intrusion Accepted
Interaction Server then reports the addition of Agent 2 to the interaction by
sending EventPartyAdded to Agent 1, the reporting engine, and any other
parties to the interaction.
Intrusion Rejected by Agent
In this phase, shown in Figure 180, Agent 2 rejects the invitation to join the
interaction. Interaction Server responds with EventAck, replying to
RequestReject from this phase, and with EventError, replying to
RequestIntrude from the previous Intrusion Requested on page 433.
RequestAccept
Cancel timer
EventAck (refid=RequestAccept .refid)
Also sent to any
other parties of
the interaction
EventAck (refid=RequestIntrude.refid)
Table 266: Messages in Intrusion Accepted
Message Protocol
EventPartyAdded Reporting and
Interaction Management
436 Genesys
Figure 180: Intrusion Rejected by Agent
Intrusion Rejected by Interaction Server
agent or the interaction are not registered, and so rejects Agent 2s request for
intrusion.
Figure 181: Intrusion Rejected by Interaction Server
RequestReject
Cancel timer
EventRejected
EventAck (refid=RequestReject.refid)
EventError (refid=RequestIntrude.refid)
Table 267: Messages in Rejected by Agent
Message Protocol
Agent application 2 Interaction Server Agent application 1
RequestIntrude
Check agent &
interaction
EventError
Chapter 7: Basic Interaction Models Login/Logout
Intrusion Times Out
In this phase, shown in Figure 182, the timer that Interaction Server started in
the first phase (Intrusion Requested on page 433) expires. Interaction Server
then sends EventRevoked to Agent 2 and to the reporting engine. It also sends
EventError as a response to Agent 2s original RequestIntrude in the first
phase.
Figure 182: Intrusion Times Out
Login/Logout
This set of models illustrates a scenario which follows Successful
Registration on page 394:
1. After connecting and registering, the agent application logs in to all
available Interaction Servers.
Table 268: Messages in Intrusion Rejected by Interaction Server
Message Protocol
Timeout
EventRevoked
EventRevoked
EventError (refid=RequestIntrude.refid)
Table 269: Messages in Intrusion Times Out
Message Protocol
438 Genesys
2. The agent application logs out from the Interaction Servers.
Agent Logs In
In this phase, shown in Figure 183,
1. The agent application sends RequestAgentLogin to the primary Interaction
Server.
2. The primary Interaction Server sends EventAgentLogin to the reporting
engine, which responds with EventCurrentAgentStatus.
3. The agent applications sends RequestAgentAvailable to all other
Interaction Servers that are running.
4. The primary Interaction Server relays EventCurrentAgentStatus to the
agent application.
Note that the agent application uses different events to log in to primary versus
secondary Interaction Servers.
Figure 183: Agent Logs In
Interaction Server
(secondary)
Agent application Reporting engine
Interaction Server
(primary)
initiate login
RequestAgentLogin
EventAck
EventAgentLogin
RequestAgentAvailable
EventAck
to all other Interaction
Servers that are running
check license
EventCurrentAgentStatus
update GUI
To primary Interaction
Server only
Agent Logs Out
In this phase, shown in Figure 184, the agent application sends
RequestAgentLogout to the primary Interaction Server, which relays that
information to the reporting engine. After the agent application receives
EventAck from this Interaction Server, it sends RequestAgentNotAvailable to
all secondary Interaction Servers.
Figure 184: Agent Logs Out
Table 270: Messages in Agent Logs In
Message Protocol
EventAgentLogin Reporting
EventCurrentAgentStatus Reporting
Interaction Server
(secondary)
Agent application
Reporting engine
Interaction Server
(primary)
RequestAgentLogout
return licenses
EventAgentLogout
EventAck
RequestAgentNotAvailable
EventAck
Table 271: Messages in Agent Logs Out
Message Protocol
EventAgentLogout Reporting
440 Genesys
Chapter 7: Basic Interaction Models Reporting Engine Connects
Reporting Engine Connects
This model illustrates the following scenario:
1. The reporting engine connects with Interaction Server, then uses
RequestStartPlaceAgentReportingAll to request data on all agents that are
logged in to this Interaction Server.
2. Interaction Server uses EventPlaceAgentState to inform the reporting
engine of the state (media state, interactions being handled) of all agents
that are logged in with this Interaction Server.
3. The reporting engine (in this case, Stat Server) combines this state
information with any applicable capacity rules to calculate the agents
status. It relays the status information to Interaction Server using
EventCurrentAgentStatus. Interaction Server passes the same event to the
agent application, which displays the status information in its UI.
Note: In this scenario the reporting engine must be Stat Server. In the
current release, Stat Server is the only component that calculates
capacity.
4. If there are multiple Interaction Servers, the reporting engine then connects
with each one in turn and repeats Steps 2 and 3 with each.
Note that this model distinguishes between state and status of an agent, as
follows:
State indicates the media that this agent is ready to use and the interactions
that the agent is currently handling.
Status is the output of an Agent Capacity Rule, which Stat Server
calculates using the agents state as part of the input.
This model, which is not further divided into phases, is shown in Figure 185.
Chapter 7: Basic Interaction Models Disconnection and Failover
Figure 185: Reporting Engine Connects
This model uses the messages shown in Table 272.
Disconnection and Failover
This set of models illustrates the following scenarios:
The agent application disconnects from Interaction Server(s).
The Interaction Server disconnects from agent application and reporting
engine. Then the following happens:
The agent application connects to secondary Interaction Server, which

becomes primary.
The former primary Interaction Server restarts.

Agent application Reporting engine Interaction Server
Connect
RequestStartPlaceAgentReportingAll
EventPlaceAgentState
update GUI
EventAck
Table 272: Messages in Reporting Engine Connects
Message Protocol
EventCurrentAgentStatus Reporting
EventPlaceAgentState Reporting
442 Genesys
Agent Disconnects
In this phase, shown in Figure 186, the agent application disconnects from
Interaction Server. This may due to a failure or to normal shutdown.
Figure 186: Agent Disconnects
The primary Interaction Server sends EventAgentLogout only if the agent was
known to be logged in.
This phase uses the message shown in Table 273.
Interaction Server Disconnects
In this phase, shown in Figure 187:
1. The primary Interaction Server disconnects from the agent application and
the reporting engine. This may due to a failure or to normal shutdown. The
reporting engine sets the state of each agent logged in with this Interaction
Server to not logged in.
2. The agent application connects to the secondary Interaction Server and
registers with it. Registration is not shown here; see Registration on
page 394 for a description.
3. The agent application logs in to the secondary Interaction Server.
4. The secondary Interaction Server responds with EventAck, thereby
becoming the new primary Interaction Server.
Interaction Server
(secondary)
(primary)
Disconnect
Mark agent unavailable
EventAgentLogout
Disconnect
Mark agent unavailable
Table 273: Messages in Agent Disconnects
Message Protocol
EventAgentLogout Reporting
Figure 187: Interaction Server Disconnects
Interaction Server Restarts
In this phase, shown in Figure 188:
1. The original primary Interaction Server restarts.
2. The agent application connects to it and registers (registration is not shown
here; see Registration on page 394)
3. The agent application logs in to the Interaction Server using
RequestAgentAvailable, upon which this Interaction Server becomes
secondary.
Interaction Server
(secondary)
(primary)
Disconnect
Change state
to 'not logged in'
Disconnect
Connect (or reuse connection) Client
registration, etc
not shown
RequestAgentLogin
EventAgentLogin
EventAck
Initiate reconnect
Table 274: Messages in Interaction Server Disconnects
Message Protocol
EventAgentLogin Reporting
444 Genesys
Chapter 7: Basic Interaction Models Invoke Autoresponse
Figure 188: Interaction Server Restarts
Invoke Autoresponse
1. URS, triggered by an Autoresponse strategy object, generates a request for
E-mail Server Java to generate a new autoresponse interaction. It sends this
request to Interaction Server using Request3rdServer.
2. Interaction Server relays the request to E-mail Server Java using the same
Request3rdServer. It also relays the content of the request to the reporting
engine using EventExternalServiceRequested.
3. E-mail Server Java generates a new Autoresponse interaction and submits
it to Interaction Server using RequestSubmit. When Interaction Server
acknowledges the submission, E-mail Server Java sends
Event3rdServerResponse, which Interaction Server relays to URS.
Interaction Server also relays the content of that event to the reporting
engine using EventExternalServiceResponded.
This model, which is not further divided into phases, is shown in Figure 189.
Table 275: Messages in Interaction Server Restarts
Message Protocol
(primary)
Reconnect timer
Connect
Client registration,
etc not shown
RequestAgentAvailable
EventAck
Mark agent available
Figure 189: Invoke Autoresponse
Interaction Server URS Reporting engine
E-mail Server
Java
EventExternalServiceRequested
EventExternalServiceResponded
RequestSubmit
Request3rdServer (ESP)
EventAck (on submit) EventInteractionSubmitted
Event3rdServerResponse (ESP)
Request3rdServer (T-library)
Event3rdServerResponse (T-library)
Table 276: Messages in Invoke Autoresponse
Message Protocol
Event3rdServerResponse ESP
EventExternalServiceRequested Reporting
EventExternalServiceResponded Reporting
446 Genesys
In this scenario, URS uses Interaction Server as an intermediary to
communicate with E-mail Server Java, which in this case is called a third-party
server. Another example of such a third-party server is Classification Server,
with which URS must similarly communicate when a strategy includes a
Classify object. To relay these messages to third-party servers, Interaction
Server uses the T-Library messages RequestPrivateService and
EventPrivateInfo, with special content in their extensions and user_data
attributes. With that special content, these messages make up a small External
Services Protocol (ESP), as shown in Table 277.
ESP is not further described in this manual. However, much of the relevant
content of Request3rdServer and Event3rdServerResponse is repeated in the
attributes of the reporting protocol events EventExternalServiceRequested
and EventExternalServiceResponded.
Components that understand ESP are called ESP servers. Classification Server
is an ESP server. E-mail Server Java functions both as a media server
(processing Interaction Management Protocol messages) and as an ESP server,
processing ESP messages. You can also create custom ESP servers using the
Genesys Open Media Platform SDK.
Table 277: ESP Messages
T-Library Message ESP Message Description
EventPrivateInfo Event3rdServerResponse Returns results of third-
party servers operation
Event3rdServerFault Contains information about
failure of third-party
servers operation
Chapter
8 IVR Call Flows
This chapter includes call flow diagrams that show all of the commonly
encountered request-response sequences needed to create your IVR driver
client. This chapter contains these sections:
Overview, page 447
Call Routing Call Flow, page 448
Route Failed, page 449
Reroute, page 450
Call Treatment, page 451
Call Treatment Failed, page 452
Call Treatment Interrupted, page 453
MakeCall Call Flow, page 454
MakeCall (Busy), page 454
Conference Call Flow Diagrams, page 454
Transfer Call Flow Diagrams, page 461

Overview
This chapter consists of a series of call flow diagrams. It is intended to be used
as a reference. The remaining call flow diagrams illustrate the request-response
sequences for additional interaction types.
You can find complete lists of the Conference and Transfer call flow diagrams
under Conference Call Flow Diagrams on page 454 and Transfer Call Flow
Diagrams on page 461.
448 Genesys
Chapter 8: IVR Call Flows Call Routing Call Flow
Call Routing Call Flow
Figure 190: Call Routing Call Flow
NewCall (Network)
RouteRequest
RouteResponse
IVR Connected
EndCall
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
Connected
IVR EndCall
IVR RouteRequest
CallStatus (Ringing)
CallStatus (Established)
IVR CallRinging
IVR CallEstablished
Chapter 8: IVR Call Flows Route Failed
Route Failed
Figure 191: Call Flow Showing Failed Route Attempt
NewCall (Network)
RouteRequest
RouteResponse
IVR Connected
EndCall
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
Connected
IVR EndCall
IVR RouteRequest
IVR Failure
Failure
RouteResponse
IVR Connect
IVR CallRinging
IVR CallEstablished
Repeatable
Until
Successf ul
RouteResponse
450 Genesys
Chapter 8: IVR Call Flows Reroute
Reroute
Figure 192: Rerouted Call
The external routing request is delivered from URS by the IVR Server.
NewCall (Network)
RouteRequest
RouteResponse
IVR Connected
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
Connected
IVR RouteRequest
RouteResponse
IVR Connected
EndCall
IVR Connect
Connected
IVR EndCall
External Routing
Reroute Request
IVR CallRinging
IVR CallEstablished
May occur
many ti mes.
Chapter 8: IVR Call Flows Call Treatment
Call Treatment
Figure 193: Call Treatment Call Flow
NewCall (Network)
RouteRequest
TreatCall
IVR Connected
EndCall
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR TreatCall
Connected
IVR EndCall
IVR RouteRequest
IVR TreatStatusStarted
TreatStatus (Started)
RouteResponse
IVR Connect
IVR TreatStatusCompleted
TreatStatus (Completed)
IVR CallRinging
IVR CallEstablished
Multiple
Treatment
Cy cles
May Occur
452 Genesys
Chapter 8: IVR Call Flows Call Treatment Failed
Call Treatment Failed
Figure 194: Call Treatment Failed Call Flow
NewCall (Network)
RouteRequest
TreatCall
IVR Connected
EndCall
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR TreatCall
Connected
IVR EndCall
IVR RouteRequest
RouteResponse
IVR Connect
IVR TreatStatusCompleted
IVR TreatStatusNotStarted
TreatStatus (NotStarted)
TreatCall
IVR TreatCall
TreatStatus (Completed)
IVR CallRinging
IVR CallEstablished
Multiple
Treatment
Not Started
Cy cles May
Occur
Chapter 8: IVR Call Flows Call Treatment Interrupted
Call Treatment Interrupted
Figure 195: Interrupted Call Treatment
The command to cancel the call treatment is forwarded from the Genesys
Framework by IVR Server.
NewCall (Network)
RouteRequest
TreatCall
IVR Connected
EndCall
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR TreatCall
Connected
IVR EndCall
IVR RouteRequest
RouteResponse
IVR Connect
Cancel
IVR Cancelled
CancelCompleted
IVR Cancel
IVR CallRinging
IVR CallEstablished
454 Genesys
Chapter 8: IVR Call Flows MakeCall Call Flow
MakeCall Call Flow
Figure 196: MakeCall Operation
MakeCall (Busy)
Figure 197: MakeCall(Busy) Call Flow
Conference Call Flow Diagrams
The following call flow diagrams illustrate several scenarios involving
conferenced calls.
MakeCall
CallStatus (Dialing)
IVR
Driver
IVR
Server
IVR
IVR MakeCall
IVR CallEstablished
IVR CallDialing
MakeCall
IVR
Driver
IVR
Server IVR
IVR MakeCall
CallStatus (Busy)
IVR CallDialing
IVR CallBusy
EndCall
IVR EndCall
Chapter 8: IVR Call Flows Conference Call Flow Diagrams
One-Step Conference, page 455
One-Step Conference, Scenario 2, page 456
Conference Consult Call, page 457
Conference Consult Call, Scenario 2, page 458
Conference Consult Call (Busy), page 459
Conference Consult Call (Failed), page 460
One-Step Conference
Figure 198: Call Flow for a One-Step Conference
If a CallError occurs, IVR Server automatically returns you to the same status
as before the conference call was started. This means that the original call is
retrieved without any input from the IVR.
NewCall (Network)
RouteRequest
RouteResponse
EndCall
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
IVR EndCall
IVR RouteRequest
OneStepConf
IVR OneStepConf
CallStatus (Conf PartyAdded)
(Original party hangs up)
IVR PartyAdded
IVR CallRinging
IVR CallEstablished
456 Genesys
One-Step Conference, Scenario 2
Figure 199: One-Step Conference with Alternative Disconnect Scenario
NewCall (Network)
RouteRequest
RouteResponse
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
IVR RouteRequest
OneStepConf
IVR OneStepConf
CallStatus (Conf PartyDeleted)
IVR PartyDeleted
(Conf erenced party hangs up)
IVR PartyAdded
IVR CallRinging
IVR CallEstablished
Conf erence
May Be
Repeated
In This
Scenario
Conference Consult Call
Figure 200: Call Flow for Conference Consult Call
NewCall (Network)
RouteRequest
RouteResponse
EndCall
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
IVR EndCall
IVR RouteRequest
InitConf
IVR InitConf
CallStatus (Held)
CallStatus (Retrieved)
(Original party hangs up)
IVR CallHeld
IVR CallDialing
IVR CallEstablished
IVR CallRetrieved
IVR PartyAdded
IVR CompleteConf
CompleteConf
IVR CallRinging
IVR CallEstablished
458 Genesys
Conference Consult Call, Scenario 2
Figure 201: Conference Consult Call Alternative Scenario
NewCall (Network)
RouteRequest
RouteResponse
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
IVR RouteRequest
InitConf
IVR InitConf
CallStatus (Held)
CallStatus( Conf PartyAdded )
(Conf erenced party hangs up)
CallStatus( Conf PartyDeleted )
IVR CallHeld
IVR CallDialing
IVR CallEstablished
IVR CallRetrieved
IVR PartyAdded
IVR PartyDeleted
IVR CompleteConf
CompleteConf
IVR CallRinging
IVR CallEstablished
Conf erence
May Be
Repeated
In This
Scenario
Conference Consult Call (Busy)
Figure 202: Conference Consult Call, Line Busy
A Busy response is not considered an error. When the party which is to be
conferenced with the original caller is busy, the IVR driver must send a
RetrieveCall message to retrieve the original call. Compare this to
Conference Consult Call (Failed) on page 460.
NewCall (Network)
RouteRequest
RouteResponse
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
IVR RouteRequest
InitConf
IVR InitConf
CallStatus (Held)
CallStatus (Busy)
RetrieveCall
IVR CallHeld
IVR CallDialing
CallStatus (Busy)
IVR RetrieveCall
IVR CallRetrieved
IVR CallRinging
IVR CallEstablished
Conf erence
May Be
Repeated
In This
Scenario
460 Genesys
Conference Consult Call (Failed)
Figure 203: Conference Consult Call Failed Call Flow
as before the conference call was started. This means that the second call is
terminated and the original call is retrieved without any input from the IVR.
Note: If the IVR tries to retrieve the original call after a CallError message,
the IVR will receive another error message because the original call
has already been taken off hold.
NewCall (Network)
RouteRequest
RouteResponse
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
IVR RouteRequest
InitConf
IVR InitConf
CallStatus (Held)
CallError
IVR CallHeld
IVR CallDialing
IVR CallError
IVR CallRinging
IVR CallEstablished
Chapter 8: IVR Call Flows Transfer Call Flow Diagrams
Transfer Call Flow Diagrams
The following call flow diagrams illustrate several scenarios involving
transferring calls.
Transfer to Remote Site, page 461
Single-Step Transfer, page 462
Transfer Consult Call, page 463
Transfer Consult Call (Busy), page 464
Transfer Consult Call (Failed), page 465
Transfer to Remote Site
Figure 204: Transfer to a Remote Site
NewCall (Network)
RouteRequest
RouteResponse
IVR Connected
EndCall
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
Connected
IVR EndCall
IVR RouteRequest
AccessNumGet
AccessNumResp
IVR Connect
IVR AccessNumGet
IVR CallRinging
IVR CallEstablished
462 Genesys
Figure 205: Single-Step Transfer
as before the transfer was started. This means that the original call is retrieved
without any input from the IVR.
NewCall (Network)
RouteRequest
RouteResponse
EndCall
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
IVR EndCall
IVR RouteRequest
OneStepXf er
IVR OneStepXf er
IVR CallRinging
IVR CallEstablished
CallStatus (Xf erComplete)
IVR CallXf erComplete
CallStatus (Held)
In The Case
Where Single
Step Transf er
Is Not Supported
By The Switch,
These Ev ents
Will Also Be
Sent By
IVR Serv er
Transfer Consult Call
Figure 206: Call Flow for a Transfer Consult Call
NewCall (Network)
RouteRequest
RouteResponse
EndCall
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
IVR EndCall
IVR RouteRequest
InitXf er
IVR InitXf er
CompleteXf er
IVR CompleteXf er
CallStatus (Held)
IVR CallHeld
IVR CallDialing
IVR CallEstablished
IVR CallRinging
IVR CallEstablished
CallStatus (Xf erComplete)
IVR CallXf erComplete
464 Genesys
Transfer Consult Call (Busy)
Figure 207: Transfer Consult Call, Line Busy
A Busy response is not considered an error. When the party to which the
original caller is to be transferred is busy, the IVR driver must send a
RetrieveCall message to retrieve the original call. Compare this to Transfer
Consult Call (Failed) on page 465.
NewCall (Network)
RouteRequest
RouteResponse
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
IVR RouteRequest
InitXf er
IVR InitXf er
CallStatus (Held)
CallStatus (Busy)
RetrieveCall
IVR CallHeld
IVR CallDialing
IVR CallBusy
IVR RetrieveCall
IVR CallRetrieved
IVR CallRinging
IVR CallEstablished
Transf er
May Be
Repeated
In This
Scenario
Transfer Consult Call (Failed)
Figure 208: Transfer of Consult Call Failed
as before the call transfer was started. This means that the second call is
terminated and the original call is retrieved without any input from the IVR.
Note: If the IVR tries to retrieve the original call after a CallError message,
the IVR will receive another error message because the original call
has already been taken off hold.
NewCall (Network)
RouteRequest
RouteResponse
IVR
Driver
IVR
Server
IVR
IVR NewCall
IVR Connect
IVR RouteRequest
InitXf er
IVR InitXf er
CallStatus (Held)
CallError
IVR CallHeld
IVR CallDialing
IVR CallError
IVR CallRinging
IVR CallEstablished
Transf er
May Be
Repeated
In This
Scenario
466 Genesys
Supplements
Related Documentation
Resources
The following resources provide additional information that is relevant to this
software. Consult these additional resources, as necessary.
Universal SDK
Generally, the Universal SDK documentation, which includes Platform,
Interaction, and IVR SDKs, is the most pertinent related set of documents for
this Reference. All SDK documentation is available from the Genesys
Developer Portal, the Genesys DevZone (http://devzone.genesyslab.com).
In particular, consult these resources as necessary:
Platform SDK documentation
Platform SDK 8.x Developers Guide, which provides detailed

information on how to develop applications of all types using a given
Platform SDK.
The Platform SDK 8.x API Reference for the particular SDK you might
be using, which provides the authoritative information on methods and
functions for each SDK.
The Platform SDK 8.x Application Block Guide for any given
application block. Each Guide explains how to use the application
block and documents all code used in the application block itself.
(Application blocks are production-quality available code.)
Platform SDK 8.x Code Examples, which offer illustrative ways to

begin using Platform SDKs. These code examples are fully functioning
software applications, but are for educational purposes only and are not
supported.
Interaction SDK documentation
Interaction SDK 8.x Developers Guides, which provide detailed

information on how to develop applications of all types using a given
Interaction SDK.
468 Genesys
Related Documentation Resources
The Interaction SDK 8.x API Reference for the particular SDK you
might be using, which provides the authoritative information on
methods and functions for each SDK.
The Interaction SDK 8.x Application Block Guide for any collection of
application blocks. Each Guide explains how to use the application
blocks and documents all code used in the application block itself.
(Application blocks are production-quality available code.)
Interaction SDK 8.x Code Examples, which offer illustrative ways to

begin using Platform SDKs. These code examples are fully functioning
software applications, but are for educational purposes only and are not
supported.
IVR SDK documentation
IVR SDK 8.x C and XML Developers Guides, which provide detailed
information on how to develop custom applications for use with IVR
Server.
The IVR SDK 8.x C API Reference, which provides the authoritative
information on functions for that SDK.
The Deployment Guides for the underlying Genesys servers with which
you intend to integrate. For instance, be sure to check the Framework 8.x
SIP Server Deployment Guide if you plan on using the Voice Platform
SDK and the SIP Endpoint Application Block. In particular, the Genesys
Multimedia documentation contains the detailed information you need for
understanding the underlying servers that handle non-voice interactions
(Interaction Server).
Genesys
The Genesys Technical Publications Glossary, which ships on the Genesys
Documentation Library DVD and provides a comprehensive list of the
Genesys and computer-telephony integration (CTI) terminology and
acronyms that are used in this document.
The Genesys Migration Guide, which ships on the Genesys Documentation
Library DVD and provides documented migration strategies for Genesys
product releases. Contact Genesys Technical Support, for more
information.
Release Notes and Product Advisories for this product, which are available
on the Genesys Technical Support website at
http://genesyslab.com/support.
Information about supported hardware and third-party software is available on
the Genesys Technical Support website in the following documents:
Genesys Supported Operating Environment Reference Manual
Genesys Supported Media Interfaces Reference Manual
Related Documentation Resources
Consult the following additional resources, as necessary:
The Genesys Hardware Sizing Guide, which provides information about
Genesys hardware sizing guidelines for the Genesys 7.x and 8.x releases.
The Genesys Interoperability Guide, which provides information about the
compatibility of Genesys products with various Configuration Layer
Environments; Interoperability of Reporting Templates and Solutions; and
Gplus Adapters Interoperability.
The Genesys Licensing Guide, which introduces you to the concepts,
terminology, and procedures that are relevant to the Genesys licensing
system.
The Genesys Database Sizing Estimator Worksheets, which provides a
range of expected database sizes for various Genesys products.
For additional system-wide planning tools and information, see the
release-specific listings of System Level Documents on the Genesys Technical
Support website, accessible from the system level documents by release tab
in the Knowledge Base Browse Documents Section.
Genesys product documentation is available on the:
Genesys Technical Support website at http://genesyslab.com/support.
Genesys Documentation Library DVD, which you can order by e-mail
from Genesys Order Management at [email protected].
470 Genesys
Document Conventions
This document uses certain stylistic and typographical
conventionsintroduced herethat serve as shorthands for particular kinds of
information.
Document Version Number
A version number appears at the bottom of the inside front cover of this
document. Version numbers change as new information is added to this
document. The following is a sample version number:
80fr_ref_06-2008_v8.0.001.00
You will need this number when you are talking with Genesys Technical
Support about this product.
Screen Captures Used in This Document
Screen captures from the product graphical user interface (GUI), as used in this
document, may sometimes contain minor spelling, capitalization, or
grammatical errors. The text that accompanies and explains the screen captures
corrects such errors except when such a correction would prevent you from
installing, configuring, or successfully using the product. For example, if the
name of an option contains a usage error, the name would be presented exactly
as it appears in the product GUI; the error would not be corrected in any
accompanying text.
Type Styles
Table 278 describes and illustrates the type conventions that are used in this
document.
Table 278: Type Styles
Type Style Used For Examples
Italic Document titles
Emphasis
Definitions of (or first references to)
unfamiliar terms
Mathematical variables
Also used to indicate placeholder text within
code samples or commands, in the special case
where angle brackets are a required part of the
syntax (see the note about angle brackets on
page 471).
Please consult the Genesys Migration
Guide for more information.
Do not use this value for this option.
A customary and usual practice is one
that is widely accepted and used within a
particular industry or profession.
The formula, x +1 = 7
where x stands for . . .
Monospace
font
(Looks like
teletype or
typewriter
text)
All programming identifiers and GUI
elements. This convention includes:
The names of directories, files, folders,
configuration objects, paths, scripts, dialog
boxes, options, fields, text and list boxes,
operational modes, all buttons (including
radio buttons), check boxes, commands,
tabs, CTI events, and error messages.
The values of options.
Logical arguments and command syntax.
Code samples.
Also used for any text that users must
manually enter during a configuration or
installation procedure, or on a command line.
Select the Show variables on screen
check box.
In the Operand text box, enter your
formula.
Click OK to exit the Properties dialog
box.
T-Server distributes the error messages in
EventError events.
If you select true for the
inbound-bsns-calls option, all
established inbound calls on a local agent
are considered business calls.
Enter exit on the command line.
Square
brackets ([ ])
A particular parameter or value that is optional
within a logical argument, a command, or
some programming syntax. That is, the
presence of the parameter or value is not
required to resolve the argument, command, or
block of code. The user decides whether to
include this optional information.
smcp_server -host [/flags]
Angle
brackets
(< >)
A placeholder for a value that the user must
specify. This might be a DN or a port number
that is specific to your enterprise.
Note: In some cases, angle brackets are
required characters in code syntax (for
example, in XML schemas). In these cases,
italic text is used for placeholder values.
smcp_server -host <confighost>
472 Genesys
Index
Symbols
[] (square brackets). . . . . . . . . . . . . . 471
< > (angle brackets) . . . . . . . . . . . . . 471
A
AccessNumber
event attribute . . . . . . . . . . . . . . . 146
AccessNumResp. . . . . . . . . . . . . . . 214
Agent After Call Work . . . . . . . . . . . . 136
Agent Busy AfterCallWork . . . . . . . . . . 136
Agent Busy NotReady . . . . . . . . . . . . 136
Agent Busy Ready . . . . . . . . . . . . . . 136
Agent Not Ready . . . . . . . . . . . . . . . 135
Agent Null . . . . . . . . . . . . . . . . . . 135
Agent Ready . . . . . . . . . . . . . . . . . 135
Agent states
Agent After Call Work . . . . . . . . . . . 136
Agent Busy AfterCallWork. . . . . . . . . 136
Agent Busy NotReady. . . . . . . . . . . 136
Agent Busy Ready. . . . . . . . . . . . . 136
Agent Not Ready . . . . . . . . . . . . . 135
Agent Null . . . . . . . . . . . . . . . . . 135
Agent Ready. . . . . . . . . . . . . . . . 135
description. . . . . . . . . . . . . . . . . 135
Agent Subtype . . . . . . . . . . . . . . . . 212
AgentID
event attribute . . . . . . . . . . . . . . . 146
agent-status & DN events . . . . . . . . 81108
EventAgentAfterCallWork . . . . . . . . . . 89
EventAgentIdleReasonSet . . . . . . . . . 89
EventAgentLogin . . . . . . . . . . . . . . 81
EventAgentLogout. . . . . . . . . . . . . . 83
EventAgentNotReady . . . . . . . . . . . . 86
EventAgentReady . . . . . . . . . . . . . . 85
EventDNBackInService . . . . . . . . . . . 90
EventDNDOff . . . . . . . . . . . . . . . . 93
EventDNDOn . . . . . . . . . . . . . . . . 91
EventDNOutOfService . . . . . . . . . . . 90
EventForwardCancel . . . . . . . . . . . . 95
EventForwardSet . . . . . . . . . . . . . . 94
EventListenDisconnected. . . . . . . . . 103
EventListenReconnected . . . . . . . . . 104
EventMessageWaitingOff . . . . . . . . . 107
EventMessageWaitingOn . . . . . . . . . 106
EventMonitoringCancelled . . . . . . . . . 97
EventMonitoringNextCall . . . . . . . . . . 96
EventMuteOff . . . . . . . . . . . . . . . 102
EventMuteOn . . . . . . . . . . . . . . . 101
EventOffHook . . . . . . . . . . . . . . . . 99
EventOnHook . . . . . . . . . . . . . . . 100
EventQueueLogout . . . . . . . . . . . . . 84
list . . . . . . . . . . . . . . . . . . . . . . 26
Alternate Call Service . . . . . . . . . . . . 385
Alternate Call Service with Transfer
Completion . . . . . . . . . . . . . 386
Alternate-Call Service . . . . . . . . . . . . 321
angle brackets . . . . . . . . . . . . . . . . 471
ANI
event attribute. . . . . . . . . . . . . . . 146
Attaching/Updating User Data
to Call by Third Party . . . . . . . . . . . 308
to Internal Call . . . . . . . . . . . . . . 307
attribute type . . . . . . . . . . . . . . . . . . 24
audience
defining . . . . . . . . . . . . . . . . . . . 13
Autoresponse . . . . . . . . . . . . . . . . 444
B
Blind Conference . . . . . . . . . . . . . . 300
brackets
angle . . . . . . . . . . . . . . . . . . . 471
square. . . . . . . . . . . . . . . . . . . 471
Bridged Appearance for Hold/Retrieve . . . 334
Bridged Appearance
from an Outbound Call . . . . . . . 331
Bridged Appearance
with an Internal/Inbound Call . . . . 328
Index
474 Genesys
C
call (definition) . . . . . . . . . . . . . . . . 139
Call Established for Call On Hold . . . . . . 257
Call Forwarding (on No Answer) . . . . . . . 318
Call Models
Alternate-Call Service . . . . . . . . . . . 321
Attaching/Updating User Data
to Call by Third Party. . . . . . . 308, 307
Blind Conference . . . . . . . . . . . . . 300
Bridged Appearance
for Hold/Retrieve . . . . . . . . . 334, 331
with an Internal/Inbound Call. . . . . . 328
Call Established for Call On Hold . . . . . 257
Call Forwarding (on No Answer) . . . . . 318
Call Treatment with Routing. . . . . . . . 339
Conference . . . . . . . . . . . . . . . . 296
Conference with Two Incoming Calls
Using TMergeCalls . . . . . . . . . . . 304
Connection-Establishing Phase
Call Queued to Multiple ACD . . . . . 236
Internal/Inbound Call . . 230, 233, 240, 247,
251, 243
Outbound Call . . . . . . . . . . . . . 254
Hold/Retrieve Function
Consulted Party Answers . . . . 262, 265
Internal Call to Destination
with DND Activated . . . . . . . . . . . 316
Internal/Inbound Call Answerable by
Several Agents
(Party B Answers) . . . . . . . . . . . 336
List
basic call models. . . . . . . . . . . . 225
handling network calls . . . . 228, 227, 226
monitoring calls . . . . . . . . . . . . 228
predictive dialing . . . . . . . . . . . . 227
releasing calls . . . . . . . . . . . . . 226
special cases. . . . . . . . . . . . . . 227
working with queues . . . . . . . . . . 228
Multiple-Queue Call
Call Removed from Queue. . . . . . . 377
Treated at an IVR port
at IVR Queue . . . . . . . . . 370, 374
Mute Transfer . . . . . . . . . . . . . . . 274
Network Call Flows
Alternate Call Service . . . . . . 385, 386
Caller Abandonment . . 389, 385, 380, 381
Failed Consultation (Specific
Target) . . . . . . . . . . . . . 381, 382
Premature Disconnection (One Variation) .
390, 391
Reconnection . . . . . . . . . . 387, 388
Single-Step Transfer . . . . . . . 390, 379
Transactional Error. . . . . . 392, 384, 383
Network T-Server Call Flows . . . . . . . 379
Outbound Call to a Busy Destination . . . 310
Predictive Call. . . . . . . . . . . . . 343, 347
Predictive Call (Connected to a Device
Specified in Extensions) . . . . . . . . 352
Reconnect-Call Service. . . . . . . . . . 323
Redirect-Call Service . . . . . . . . . . . 325
Rejected Call . . . . . . . . . . . . . . . 312
Release from Conference. . . . . . . . . 259
Release Phase . . . . . . . . . . . . . . 258
Service Observing
for Agent-Initiated Call . . . . . . . . . 363
on Agent . . . . . . . . . . . . . 357, 366
Simple Call Model. . . . . . . . . . . . . 229
Single-Step Conference. . . . . . . . . . 294
Single-Step Transfer . . . . . . . . . . . 268
Single-Step Transfer (Outbound) . . . . . 271
Two-Step Transfer
(Blind) Complete Before
Consulted Party Answers . . . . . . 280
Complete After Consulted
Party Answers . . . . . . . . . . . . 277
to a Routing Point . . . . . . . . 288, 283
Call Treatment with Routing . . . . . . . . . 339
call-based events
EventCallCreated . . . . . . . . . . . . . 165
EventCallDataChanged . . . . . . . . . . 166
EventCallDeleted . . . . . . . . . . . . . 167
EventReleased (DEPRECATED) . . . . . 168
general . . . . . . . . . . . . . . . . 168170
list . . . . . . . . . . . . . . . . . . . . . 165
Caller Abandonment . . . . . . . . . . . . . 389
CallError . . . . . . . . . . . . . . . . . . . 215
call-handling & transfer/conference
events . . . . . . . . . . . . . . . 3661
call-handling & transfer/conference events
EventAbandoned . . . . . . . . . . . . . . 41
EventBridged . . . . . . . . . . . . . . . . 55
EventDestinationBusy . . . . . . . . . . . 42
EventDialing . . . . . . . . . . . . . . . . 36
EventDiverted. . . . . . . . . . . . . . . . 44
EventEstablished . . . . . . . . . . . . . . 39
EventHeld. . . . . . . . . . . . . . . . . . 45
EventNetworkReached . . . . . . . . . . . 47
EventPartyAdded . . . . . . . . . . . . . . 48
EventPartyChanged . . . . . . . . . . . . 50
EventPartyDeleted . . . . . . . . . . . . . 51
EventQueued . . . . . . . . . . . . . . . . 53
EventReleased . . . . . . . . . . . . . . . 57
EventRetrieved . . . . . . . . . . . . . . . 59
EventRinging . . . . . . . . . . . . . . . . 37
list . . . . . . . . . . . . . . . . . . . . . . 24
CallHistory
event attribute. . . . . . . . . . . . . . . 146
Index
CallID
event attribute . . . . . . . . . . . . . . . 147
CallInfoResp . . . . . . . . . . . . . . . . . 216
CallingLineName
event attribute . . . . . . . . . . . . . . . 147
call-party state . . . . . . . . . . . . . . . . 139
call . . . . . . . . . . . . . . . . . . . . . 139
call-party states
party . . . . . . . . . . . . . . . . . . . . 139
call-routing events . . . . . . . . . . . . .6468
EventRouteRequest . . . . . . . . . . . . . 64
EventRouteUsed . . . . . . . . . . . . . . 66
list . . . . . . . . . . . . . . . . . . . . . . 25
CallState
event attribute . . . . . . . . . . . . . . . 147
CallStatus . . . . . . . . . . . . . . . . . . 215
call-treatment events . . . . . . . . . . . .6873
EventTreatmentApplied . . . . . . . . . . . 68
EventTreatmentEnd . . . . . . . . . . . . . 69
EventTreatmentNotApplied . . . . . . . . . 71
EventTreatmentRequired . . . . . . . . . . 72
list . . . . . . . . . . . . . . . . . . . . . . 25
CallType
event attribute . . . . . . . . . . . . . . . 147
Cancel . . . . . . . . . . . . . . . . . . . . 214
Capabilities
event attribute . . . . . . . . . . . . . . . 147
Cause
event attribute . . . . . . . . . . . . . . . 147
Classification Server . . . . . . . . . . . . . 446
CLID
event attribute . . . . . . . . . . . . . . . 147
CollectedDigits
event attribute . . . . . . . . . . . . . . . 148
commenting on this document . . . . . . . . 15
Conference. . . . . . . . . . . . . . . . . . 296
Conference Completion . . . . . . . . . . . 385
Conference with Two Incoming Calls
Using TMergeCalls . . . . . . . . . 304
Connection-Establishing Phase
Call Queued to Multiple ACD . . . . . . . 236
Internal/Inbound Call . . . . . . . . . . . 230
Internal/Inbound Call to ACD . . . . . . . 233
Internal/Inbound Call with Call Parking . . 240
Internal/Inbound Call with Routing . . . . 247
Internal/Inbound Call with
Routing Outbound. . . . . . . . . . . . 251
Internal/Inbound Call with Routing--
RouteQueue Case . . . . . . . . . . . 243
Outbound Call . . . . . . . . . . . . . . . 254
ConnID
event attribute . . . . . . . . . . . . . . . 148
Consultation Leg Initiation
Specific Destination . . . . . . . . . . . . 380
URS Selected Destination. . . . . . . . . 381
conventions
in document . . . . . . . . . . . . . . . . 470
type styles. . . . . . . . . . . . . . . . . 471
CustomerID
event attribute. . . . . . . . . . . . . . . 148
D
DialOut . . . . . . . . . . . . . . . . . . . . 219
DialOutRegistryResp . . . . . . . . . . . . 219
DNIS
event attribute. . . . . . . . . . . . . . . 149
document
conventions . . . . . . . . . . . . . . . . 470
errors, commenting on . . . . . . . . . . . 15
version number . . . . . . . . . . . . . . 470
DTMF events . . . . . . . . . . . . . . . 7376
EventDigitsCollected . . . . . . . . . . . . 73
EventDTMFSent . . . . . . . . . . . . . . 75
list . . . . . . . . . . . . . . . . . . . . . . 25
E
ErrorCode
event attribute. . . . . . . . . . . . . . . 149
ErrorMessage
event attribute. . . . . . . . . . . . . . . 149
ESP . . . . . . . . . . . . . . . . . . . . . 446
server . . . . . . . . . . . . . . . . . . . 446
Event
event attribute. . . . . . . . . . . . . . . 149
event attributes . . . . . . . . . . . . . . . 146
AccessNumber . . . . . . . . . . . . . . 146
AgentID . . . . . . . . . . . . . . . . . . 146
ANI . . . . . . . . . . . . . . . . . . . . 146
CallHistory . . . . . . . . . . . . . . . . 146
CallID . . . . . . . . . . . . . . . . . . . 147
CallingLineName . . . . . . . . . . . . . 147
CallState . . . . . . . . . . . . . . . . . 147
CallType. . . . . . . . . . . . . . . . . . 147
Capabilities . . . . . . . . . . . . . . . . 147
Cause . . . . . . . . . . . . . . . . . . . 147
CLID . . . . . . . . . . . . . . . . . . . 147
CollectedDigits . . . . . . . . . . . . . . 148
ConnID . . . . . . . . . . . . . . . . . . 148
CustomerID . . . . . . . . . . . . . . . . 148
DNIS . . . . . . . . . . . . . . . . . . . 149
ErrorCode. . . . . . . . . . . . . . . . . 149
ErrorMessage. . . . . . . . . . . . . . . 149
Event . . . . . . . . . . . . . . . . . . . 149
extensions . . . . . . . . . . . . . . . . 149
FileHandle . . . . . . . . . . . . . . . . 149
HomeLocation . . . . . . . . . . . . . . 149
InfoStatus . . . . . . . . . . . . . . . . . 149
InfoType. . . . . . . . . . . . . . . . . . 149
LastCollectedDigits . . . . . . . . . . . . 150
Index
476 Genesys
Location . . . . . . . . . . . . . . . . . . 150
LocationInfoType . . . . . . . . . . . . . 150
NetworkCallID . . . . . . . . . . . . . . . 150
NetworkCallState . . . . . . . . . . . . . 150
NetworkDestDN . . . . . . . . . . . . . . 150
NetworkDestState . . . . . . . . . . . . . 150
NetworkNodeID . . . . . . . . . . . . . . 150
NetworkOrigDN . . . . . . . . . . . . . . 151
NetworkPartyRole . . . . . . . . . . . . . 151
NodeID . . . . . . . . . . . . . . . . . . 151
OtherDN. . . . . . . . . . . . . . . . . . 151
OtherDNRole . . . . . . . . . . . . . . . 151
OtherQueue . . . . . . . . . . . . . . . . 151
OtherTrunk . . . . . . . . . . . . . . . . 151
Place . . . . . . . . . . . . . . . . .151, 152
PreviousConnID. . . . . . . . . . . . . . 152
reasons . . . . . . . . . . . . . . . . . . 152
RefConnID. . . . . . . . . . . . . . . . . 152
ReferenceID. . . . . . . . . . . . . . . . 152
Reliability . . . . . . . . . . . . . . . . . 157
RouteType. . . . . . . . . . . . . . . . . 157
Server . . . . . . . . . . . . . . . . . . . 157
ServerRole . . . . . . . . . . . . . . . . 157
ServerVersion . . . . . . . . . . . . . . . 157
SessionID . . . . . . . . . . . . . . . . . 158
ThirdPartyDN . . . . . . . . . . . . . . . 158
ThirdPartyDNRole . . . . . . . . . . . . . 158
ThirdPartyQueue . . . . . . . . . . . . . 158
ThirdPartyTrunk . . . . . . . . . . . . . . 158
ThisDN . . . . . . . . . . . . . . . . . . 158
ThisDNRole . . . . . . . . . . . . . . . . 158
ThisQueue. . . . . . . . . . . . . . . . . 159
ThisTrunk . . . . . . . . . . . . . . . . . 159
time . . . . . . . . . . . . . . . . . . . . 159
TreatmentType . . . . . . . . . . . . . . 159
userdata . . . . . . . . . . . . . . . . . . 159
WorkMode. . . . . . . . . . . . . . . . . 159
XReferenceID . . . . . . . . . . . . . . . 159
XRouteType . . . . . . . . . . . . . . . . 157
EventAbandoned. . . . . . . . . . . . . . . 41
EventAck . . . . . . . . . . . . . . . . . . . 126
EventAddressInfo . . . . . . . . . . . . . . 108
EventAgentAfterCallWork . . . . . . . . . . 89
EventAgentIdleReasonSet . . . . . . . . . . 89
EventAgentLogin . . . . . . . . . . . . . . . 81
EventAgentLogout . . . . . . . . . . . . . . 83
EventAgentNotReady . . . . . . . . . . . . 86
EventAgentReady . . . . . . . . . . . . . . 85
EventAgentReserved. . . . . . . . . . . . . 128
EventAnswerAccessNumber . . . . . . . . . 123
EventAttachedDataChanged. . . . . . . . . 121
EventBridged. . . . . . . . . . . . . . . . . 55
EventCallCreated . . . . . . . . . . . . . . 165
EventCallDataChanged . . . . . . . . . . . 166
EventCallDeleted. . . . . . . . . . . . . . . 167
EventCallInfoChanged . . . . . . . . . . . . 129
EventDestinationBusy . . . . . . . . . . . . . 42
EventDialing . . . . . . . . . . . . . . . . . . 36
EventDigitsCollected. . . . . . . . . . . . . . 73
EventDiverted . . . . . . . . . . . . . . . . . 44
EventDNBackInService . . . . . . . . . . . . 90
EventDNDOff . . . . . . . . . . . . . . . . . 93
EventDNDOn . . . . . . . . . . . . . . . . . 91
EventDNOutOfService. . . . . . . . . . . . . 90
EventDTMFSent . . . . . . . . . . . . . . . . 75
EventError . . . . . . . . . . . . . . . . . . 134
EventEstablished . . . . . . . . . . . . . . . 39
EventForwardCancel . . . . . . . . . . . . . 95
EventForwardSet . . . . . . . . . . . . . . . 94
EventHardwareError . . . . . . . . . . . . . 133
EventHeld . . . . . . . . . . . . . . . . . . . 45
EventLinkConnected. . . . . . . . . . . . . . 30
EventLinkDisconnected . . . . . . . . . . . . 32
EventListenDisconnected . . . . . . . . . . 103
EventListenReconnected . . . . . . . . . . 104
EventLocationInfo . . . . . . . . . . . . . . 117
EventMailBoxLogin . . . . . . . . . . . . . . 76
EventMailBoxLogout . . . . . . . . . . . . . . 78
EventMessageWaitingOff . . . . . . . . . . 107
EventMessageWaitingOn . . . . . . . . . . 106
EventMonitoringCancelled. . . . . . . . . . . 97
EventMonitoringNextCall . . . . . . . . . . . 96
EventMuteOff . . . . . . . . . . . . . . . . 102
EventMuteOn . . . . . . . . . . . . . . . . 101
EventNetworkCallStatus . . . . . . . . . . . . 61
EventNetworkPrivateInfo . . . . . . . . . . . 62
EventNetworkReached . . . . . . . . . . . . 47
EventOffHook . . . . . . . . . . . . . . . . . 99
EventOnHook . . . . . . . . . . . . . . . . 100
EventPartyAdded . . . . . . . . . . . . . . . 48
EventPartyChanged . . . . . . . . . . . . . . 50
EventPartyDeleted. . . . . . . . . . . . . . . 51
EventPartyInfo . . . . . . . . . . . . . . . . 115
EventPrimaryChanged. . . . . . . . . . . . 131
EventPrivateInfo . . . . . . . . . . . . . . . 129
EventQueued . . . . . . . . . . . . . . . . . 53
EventQueueLogout . . . . . . . . . . . . . . 84
EventRegistered . . . . . . . . . . . . . . . . 33
EventReleased . . . . . . . . . . . . . . . . 57
EventReleased (DEPRECATED) . . . . . . 168
EventRemoteConnectionFailed . . . . . . . 125
EventRemoteConnectionSuccess . . . . . . 124
EventReqGetAccessNumberCanceled . . . 125
EventResourceAllocated. . . . . . . . . . . 133
EventResourceFreed . . . . . . . . . . . . 134
EventRestoreConnection . . . . . . . . . . 132
EventRetrieved . . . . . . . . . . . . . . . . 59
EventRinging . . . . . . . . . . . . . . . . . 37
EventRouteRequest . . . . . . . . . . . . . . 64
EventRouteUsed. . . . . . . . . . . . . . . . 66
events
agent-status & DN events. . . . . . . 81108
Index
call-based events
general . . . . . . . . . . . . . . 168170
call-handling & transfer/conference
events . . . . . . . . . . . . . . . . . 3661
call-routing events . . . . . . . . . . . . 6468
call-treatment events . . . . . . . . . . 6873
DTMF events . . . . . . . . . . . . . . 7376
general events. . . . . . . . . . . . . . 2833
ISCC events . . . . . . . . . . . . . .123126
negative-response events . . . . . . .134135
network attended transfer events . . . . 6164
query events. . . . . . . . . . . . . .108121
registration events. . . . . . . . . . . . 3335
special events . . . . . . . . . . . . .126134
user data events. . . . . . . . . . . .121122
voice-mail events . . . . . . . . . . . . 7681
EventServerConnected . . . . . . . . . . . 28
EventServerDisconnected . . . . . . . . . . 29
EventServerInfo . . . . . . . . . . . . . . . 119
EventSwitchInfo . . . . . . . . . . . . . . . 120
EventTransactionStatus (transaction
monitoring). . . . . . . . . . . . . . 184
EventTreatmentApplied . . . . . . . . . . . 68
EventTreatmentEnd . . . . . . . . . . . . . 69
EventTreatmentNotApplied. . . . . . . . . . 71
EventTreatmentRequired. . . . . . . . . . . 72
EventUnregistered . . . . . . . . . . . . . . 34
EventUserEvent . . . . . . . . . . . . . . . 130
EventVoiceFileClosed . . . . . . . . . . . . 79
EventVoiceFileEndPlay . . . . . . . . . . . 80
EventVoiceFileOpened. . . . . . . . . . . . 78
extensions . . . . . . . . . . . . . . . . . . 201
event attribute . . . . . . . . . . . . . . . 149
unstructured data . . . . . . . . . . . . . 201
Extensions in
TMuteTransfer. . . . . . . . . . . . . . 204
TMakePredictiveCall . . . . . . . . .203, 205
External Services Protocol
See ESP
F
Failed Consultation
Specific Target . . . . . . . . . . . . . . . 381
URS Selected Destination. . . . . . . . . 382
FileHandle
event attribute . . . . . . . . . . . . . . . 149
font styles
italic . . . . . . . . . . . . . . . . . . . . 471
monospace . . . . . . . . . . . . . . . . 471
G
general events . . . . . . . . . . . . . . .2833
EventLinkConnected . . . . . . . . . . . . 30
EventLinkDisconnected. . . . . . . . . . . 32
EventServerConnected . . . . . . . . . . . 28
EventServerDisconnected . . . . . . . . . 29
list . . . . . . . . . . . . . . . . . . . . . . 24
Generic Telephony State. . . . . . . . . . . 140
H
Hold/Retrieve Function
Consulted Party Answers . . . . . . . . . 262
Consulted Party Does Not Answer . . . . 265
HomeLocation
event attribute. . . . . . . . . . . . . . . 149
I
InfoStatus
event attribute. . . . . . . . . . . . . . . 149
InfoType
event attribute. . . . . . . . . . . . . . . 149
inherited method. . . . . . . . . . . . . . . 198
interaction
defined . . . . . . . . . . . . . . . . . . . 20
models . . . . . . . . . . . . . . . . 393446
Internal Call to Destination
with DND Activated . . . . . . . . . 316
Internal/Inbound Call Answerable by
Several Agents
(Party B Answers). . . . . . . . . . . . . 336
ISCC events . . . . . . . . . . . . . . 123126
EventAnswerAccessNumber . . . . . . . 123
EventRemoteConnectionFailed. . . . . . 125
EventRemoteConnectionSuccess . . . . 124
EventReqAccessNumberCanceled . . . . 125
list . . . . . . . . . . . . . . . . . . . . . . 27
ISCC Transaction Monitoring . . . . . . . . 181
italics. . . . . . . . . . . . . . . . . . . . . 471
J
joint method . . . . . . . . . . . . . . . . . 198
L
LastCollectedDigits
event attribute. . . . . . . . . . . . . . . 150
Location
event attribute. . . . . . . . . . . . . . . 150
LocationInfoType
event attribute. . . . . . . . . . . . . . . 150
LoginResp . . . . . . . . . . . . . . . . . . 209
Index
478 Genesys
M
mandatory attribute. . . . . . . . . . . . . . 24
messages
AccessNumResp . . . . . . . . . . . . . 214
Agent Subtype. . . . . . . . . . . . . . . 212
CallError . . . . . . . . . . . . . . . . . . 215
CallInfoResp. . . . . . . . . . . . . . . . 216
CallStatus . . . . . . . . . . . . . . . . . 215
Cancel . . . . . . . . . . . . . . . . . . . 214
DialOut . . . . . . . . . . . . . . . . . . 219
DialOutRegistryResp . . . . . . . . . . . 219
LoginResp . . . . . . . . . . . . . . . . . 209
MonitorInfo . . . . . . . . . . . . . . . . 210
Port Subtype. . . . . . . . . . . . . . . . 211
RouteResponse . . . . . . . . . . . . . . 213
Server Subtype . . . . . . . . . . . . . . 210
StatResp. . . . . . . . . . . . . . . . . . 217
TreatCall . . . . . . . . . . . . . . . . . . 213
UDataResp . . . . . . . . . . . . . . . . 218
MonitorInfo . . . . . . . . . . . . . . . . . . 210
monospace font . . . . . . . . . . . . . . . 471
Multimedia Reporting Protocol . . . . . . . . 19
Multiple-Queue Call
Call Removed from Queue . . . . . . . . 377
Direct Treatment at IVR . . . . . . . . 374
at IVR Queue . . . . . . . . . . . . . . 370
Mute Transfer . . . . . . . . . . . . . . . . 274
N
negative-response events . . . . . . . 134135
EventError . . . . . . . . . . . . . . . . . 134
list . . . . . . . . . . . . . . . . . . . . . . 28
network attended transfer events . . . . .6164
EventNetworkCallStatus. . . . . . . . . . . 61
EventNetworkPrivateInfo . . . . . . . . . . 62
Network Call Flows
Alternate Call Service . . . . . . . . . . . 385
Alternate Call Service with Transfer
Completion . . . . . . . . . . . . . . . 386
Caller Abandonment. . . . . . . . . . . . 389
Conference Completion . . . . . . . . . . 385
Consultation Leg Initiation (Specific
Destination) . . . . . . . . . . . . . . . 380
Consultation Leg Initiation (URS Selected
Destination) . . . . . . . . . . . . . . . 381
Failed Consultation (Specific Target) . . . 381
Failed Consultation (URS Selected
Destination) . . . . . . . . . . . . . . . 382
Premature Disconnection (One Variation). 390
Premature Disconnection 2 . . . . . . . . 391
Reconnection . . . . . . . . . . . . . . . 387
Reconnection (Explicit) . . . . . . . . . . 388
Reconnection (Implicit by Network
T-Server) . . . . . . . . . . . . . . . . 388
Reconnection (Implicit by SCP). . . . . . 388
Single-Step Transfer . . . . . . . . . . . 390
Standard Network Call Initiation . . . . . 379
Transactional Error . . . . . . . . . . . . 392
Transfer Completion (Implicit). . . . . . . 384
(Explicit). . . . . . . . . . . . . . . . . 383
Network Single-Step Transfer . . . . . . . . 390
Network T-Server Call Flows . . . . . . . . 379
NetworkCallID
event attribute. . . . . . . . . . . . . . . 150
NetworkCallState
event attribute. . . . . . . . . . . . . . . 150
NetworkDestDN
event attribute. . . . . . . . . . . . . . . 150
NetworkDestState
event attribute. . . . . . . . . . . . . . . 150
NetworkNodeID
event attribute. . . . . . . . . . . . . . . 150
NetworkOrigDN
event attribute. . . . . . . . . . . . . . . 151
NetworkPartyRole
event attribute. . . . . . . . . . . . . . . 151
NodeID
event attribute. . . . . . . . . . . . . . . 151
O
Open Media Platform SDK. . . . . . . . . . 446
optional attribute . . . . . . . . . . . . . . . . 24
OtherDN
event attribute. . . . . . . . . . . . . . . 151
OtherDNRole
event attribute. . . . . . . . . . . . . . . 151
OtherQueue
event attribute. . . . . . . . . . . . . . . 151
OtherTrunk
event attribute. . . . . . . . . . . . . . . 151
Outbound Call to a Busy Destination . . . . 310
P
participant . . . . . . . . . . . . . . . . . . . 20
party
call-party states . . . . . . . . . . . . . . 139
persistent reasons . . . . . . . . . . . . . . 207
Place
event attribute. . . . . . . . . . . . . 151, 152
Port Subtype . . . . . . . . . . . . . . . . . 211
Predictive Call . . . . . . . . . . . . . 343, 347
Predictive Call (Connected to a Device
Specified in Extensions). . . . . . . 352
Premature Disconnection
Index
A Second Variation . . . . . . . . . . . . 391
One Variation . . . . . . . . . . . . . . . 390
PreviousConnID
event attribute . . . . . . . . . . . . . . . 152
protocol . . . . . . . . . . . . . . . . . . . . 19
Q
query events . . . . . . . . . . . . . . 108121
EventAddressInfo . . . . . . . . . . . . . 108
EventLocationInfo . . . . . . . . . . . . . 117
EventPartyInfo. . . . . . . . . . . . . . . 115
EventServerInfo . . . . . . . . . . . . . . 119
EventSwitchInfo . . . . . . . . . . . . . . 120
list . . . . . . . . . . . . . . . . . . . . . . 27
R
reasons
event attribute . . . . . . . . . . . . . . . 152
unstructured data . . . . . . . . . . . . . 205
Reconnect-Call Service . . . . . . . . . . . 323
Reconnection. . . . . . . . . . . . . . . . . 387
Reconnection (Explicit). . . . . . . . . . . . 388
Reconnection (Implicit by Network
T-Server). . . . . . . . . . . . . . . 388
Reconnection (Implicit by SCP) . . . . . . . 388
Redirect-Call Service. . . . . . . . . . . . . 325
RefConnID
event attribute . . . . . . . . . . . . . . . 152
ReferenceID
event attribute . . . . . . . . . . . . . . . 152
registration events . . . . . . . . . . . . .3335
EventRegistered. . . . . . . . . . . . . . . 33
EventUnregistered. . . . . . . . . . . . . . 34
list . . . . . . . . . . . . . . . . . . . . 24, 25
Rejected Call . . . . . . . . . . . . . . . . . 312
Route Point . . . . . . . . . . . . . .313, 314
Release from Conference . . . . . . . . . . 259
Release Phase . . . . . . . . . . . . . . . . 258
Reliability
event attribute . . . . . . . . . . . . . . . 157
reliability . . . . . . . . . . . . . . . . . . . 157
RouteResponse . . . . . . . . . . . . . . . 213
RouteType
event attribute . . . . . . . . . . . . . . . 157
Routing / Treatment State . . . . . . . . . . 145
S
separate method . . . . . . . . . . . . . . . 198
Server
event attribute . . . . . . . . . . . . . . . 157
Server Subtype. . . . . . . . . . . . . . . . 210
ServerRole
event attribute. . . . . . . . . . . . . . . 157
ServerVersion
event attribute. . . . . . . . . . . . . . . 157
Service Observing
for Agent-Initiated Call . . . . . . . . . . 363
on Agent . . . . . . . . . . . . . . . . . 357
on Queue . . . . . . . . . . . . . . . . . 366
SessionID
event attribute. . . . . . . . . . . . . . . 158
Simple Call Model . . . . . . . . . . . . . . 229
Single-Step Conference . . . . . . . . . . . 294
Single-Step Transfer . . . . . . . . . . . . . 268
Single-Step Transfer (Outbound) . . . . . . 271
snapshot
defined . . . . . . . . . . . . . . . . . . 430
special events . . . . . . . . . . . . . 126134
EventAck . . . . . . . . . . . . . . . . . 126
EventAgentReserved . . . . . . . . . . . 128
EventCallInfoChanged . . . . . . . . . . 129
EventHardwareError . . . . . . . . . . . 133
EventPrimaryChanged . . . . . . . . . . 131
EventPrivateInfo . . . . . . . . . . . . . 129
EventResourceAllocated . . . . . . . . . 133
EventResourceFreed . . . . . . . . . . . 134
EventRestoreConnection . . . . . . . . . 132
EventUserEvent. . . . . . . . . . . . . . 130
list . . . . . . . . . . . . . . . . . . . . . . 27
square brackets . . . . . . . . . . . . . . . 471
Standard Network Call Initiation . . . . . . . 379
StatResp . . . . . . . . . . . . . . . . . . . 217
structures
TEvent . . . . . . . . . . . . . . . . . . 159
Supplementary State. . . . . . . . . . . . . 143
T
TEvent
structure. . . . . . . . . . . . . . . . . . 159
third-party server. . . . . . . . . . . . . . . 446
ThirdPartyDN
event attribute. . . . . . . . . . . . . . . 158
ThirdPartyDNRole
event attribute. . . . . . . . . . . . . . . 158
ThirdPartyQueue
event attribute. . . . . . . . . . . . . . . 158
ThirdPartyTrunk
event attribute. . . . . . . . . . . . . . . 158
ThisDN
event attribute. . . . . . . . . . . . . . . 158
ThisDNRole
event attribute. . . . . . . . . . . . . . . 158
ThisQueue
event attribute. . . . . . . . . . . . . . . 159
ThisTrunk
event attribute. . . . . . . . . . . . . . . 159
Index
480 Genesys
time
event attribute . . . . . . . . . . . . . . . 159
TMuteTransfer
Extensions in . . . . . . . . . . . . . . . 204
T-Library events
list . . . . . . . . . . . . . . . . . . . . . . 23
TMakePredictiveCall
Extensions in . . . . . . . . . . . . .203, 205
Transaction Monitoring . . . . . . . . . . . . 181
elements. . . . . . . . . . . . . . . . . . 193
enumeration
TSubscriptionOperationType . . . . . 182
events
EventTransactionStatus . . . . . . . . 184
function call
TTransactionMonitoring . . . . . . . . 182
subscription rules . . . . . . . . . . . . . 183
Transactional Error . . . . . . . . . . . . . . 392
transactions . . . . . . . . . . . . . . . . . 181
Transfer Completion
Implicit . . . . . . . . . . . . . . . . . . . 384
Explicit . . . . . . . . . . . . . . . . . . . 383
TreatCall . . . . . . . . . . . . . . . . . . . 213
TreatmentType
event attribute . . . . . . . . . . . . . . . 159
TSubscriptionOperationType. . . . . . . . . 182
TTransactionMonitoring . . . . . . . . . . . 182
Two-Step Transfer
(Blind) Complete Before
Consulted Party Answers . . . . . . . . 280
Complete After Consulted
Party Answers. . . . . . . . . . . . . . 277
to a Routing Point . . . . . . . . . . . . . 288
to ACD. . . . . . . . . . . . . . . . . . . 283
type
as attribute. . . . . . . . . . . . . . . . . . 24
type styles
conventions . . . . . . . . . . . . . . . . 471
italic . . . . . . . . . . . . . . . . . . . . 471
monospace . . . . . . . . . . . . . . . . 471
typographical styles . . . . . . . . . . 470, 471
U
UDataResp. . . . . . . . . . . . . . . . . . 218
unstructured data
extensions . . . . . . . . . . . . . . . . . 201
reasons . . . . . . . . . . . . . . . . . . 205
user data
userdata event attribute . . . . . . . . . . 159
user data events . . . . . . . . . . . . 121122
EventAttachedDataChanged . . . . . . . 121
list . . . . . . . . . . . . . . . . . . . . . . 27
V
version numbering, document . . . . . . . . 470
voice-mail events . . . . . . . . . . . . . 7681
EventMailBoxLogin . . . . . . . . . . . . . 76
EventMailBoxLogout . . . . . . . . . . . . 78
EventVoiceFileClosed. . . . . . . . . . . . 79
EventVoiceFileEndPlay . . . . . . . . . . . 80
EventVoiceFileOpened . . . . . . . . . . . 78
list . . . . . . . . . . . . . . . . . . . . . . 26
W
WorkMode
event attribute. . . . . . . . . . . . . . . 159
X
XReferenceID
event attribute. . . . . . . . . . . . . . . 159
XRouteType
event attribute. . . . . . . . . . . . . . . 157

8g Ref Events-Models

Uploaded by

Copyright:

Available Formats

8g Ref Events-Models

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

8g Ref Events-Models

Uploaded by

Copyright:

Available Formats

Genesys

Events and Models

Intended Audience, page 13

Usage Guidelines, page 14

Making Comments on This Document, page 15

Contacting Genesys Technical Support, page 16

How to Use This Chapter, page 23

List of T-Library Events, page 24

General Events, page 28

Registration Events, page 33

Call-Handling & Transfer/Conference Events, page 36

Network Attended Transfer Events, page 61

Call-Routing Events, page 64

Call-Treatment Events, page 68

DTMF Events, page 73

Voice-Mail Events, page 76

Agent-State & DN Events, page 81

Query Events, page 108

User-Data Events, page 121

ISCC Events, page 123

Special Events, page 126

Negative-Response Events, page 134

Agent States and Work Modes, page 135

Unified Call-Party States, page 139

Event Attributes, page 146

TEvent Structure, page 159

T-Server responds with EventAgentLogin (distributed to all registered

Requests that have different ThisQueue values are processed

Call Definition, page 163

T-Library Call-Based Events, page 164

Multi-Site Call Scenarios, page 171

IS-Link may represent a communication channel, for instance, a voice

The Subscription Type, page 181

Subscribing to Transaction Monitoring, page 182

The Transaction Monitoring Event, page 184

Transaction Monitoring States, page 186

Transaction Monitoring Elements, page 193

User Data, page 197

Extensions, page 201

Reasons, page 205

General Messages, page 209

Routing Messages, page 212

Call Treatment Messages, page 213

External Routing Messages, page 214

Transfer/Conferencing Messages, page 214

Call Information Messages, page 216

Statistics Messages, page 217

User Data Messages, page 218

Outbound Messages, page 219

Legend, page 223

List of Call Models, page 225

Basic Call Models, page 229

Releasing Calls, page 258

Holding, Transferring, and Conferencing, page 261

Handling User Data, page 307

Special Cases, page 310

Predictive Dialing, page 343

Monitoring Calls, page 357

Working With Queues, page 370