Icm - Vru - Interface Ged 125

ICM / VRU
Interface Specification
Revision 3.0c
20-Sep-2002
Copyright © 1995-2002 CISCO SYSTEMs, Inc.
The information in this document is subject to change without notice. Cisco Systems assumes no responsibility
for any errors or omissions in this document. This document contains confidential and proprietary information.
No part of this document may be reproduced, recorded, translated, or transmitted by any means, electronic or
otherwise, without the express written permission of Cisco Systems.
Document Version Number: 3.0c

Document Revision Date: 20-Sep-2002
Protocol Version: 6
ICM Version: 5.0
ICM / VRU Interface Specification Rev 3.0c
Table of Contents
1. REVISION INFORMATION................................................................................................................................. 1
CHANGES IN REVISION 1.1................................................................................................................................................1
CHANGES IN REVISION 2.8A .............................................................................................................................................5
CHANGES IN REVISION 2.8B .............................................................................................................................................5
CHANGES IN REVISION 2.8C .............................................................................................................................................5
CHANGES IN REVISION 2.9A .............................................................................................................................................5
CHANGES IN REVISION 3.0B .............................................................................................................................................6
CHANGES IN REVISION 3.0C .............................................................................................................................................6
2. OVERVIEW ............................................................................................................................................................. 7
3. GENERIC VRU MODEL........................................................................................................................................ 7

3.1 PORTS, TRUNKS AND TRUNK GROUPS..............................................................................................................7
3.2 SYSTEM CLOCK....................................................................................................................................................8
3.3 OPERATIONAL STATUS......................................................................................................................................8
4. MESSAGING CONVENTIONS ........................................................................................................................... 9

4.1 M ESSAGE HEADER (MHDR)...............................................................................................................................9
4.1.1 Base Message Types.................................................................................................................................. 9
4.2 FIXED-LENGTH DATA TYPES..........................................................................................................................11
4.3 VARIABLE-LENGTH DATA TYPES...................................................................................................................12
4.3.1 Message Element Data Type: MEDIA_SPECIFIER..........................................................................12
4.3.1.1 HTTP, File, or Streaming Media Specifiers ............................................................................................13
Page iii
4.3.1.2 Text -to-Speech Media Specifiers............................................................................................................ 13
4.3.1.3 Data Media Specifiers............................................................................................................................. 13
4.3.1.4 Null Media Specifiers ............................................................................................................................. 14
4.4 FLOATING FIELD M ESSAGE ELEMENTS........................................................................................................ 14
5. EXPANDED CALL CONTEXT ..........................................................................................................................17

5.1 REGISTERING INTEREST IN VARIABLES ........................................................................................................ 17
5.2 SENDING AND RECEIVING ECC VARIABLES.................................................................................................. 18
5.3 SPECIAL ECC MESSAGE ELEMENTS............................................................................................................... 19
5.3.1 ExpCallVarName Message Element ....................................................................................................19
5.3.2 ExpCallVarValue Message Element....................................................................................................19
5.3.3 ExpCallVarArray Message Element ....................................................................................................19
5.4 ECC VARIABLE SIZE LIMITATIONS ............................................................................................................... 19
6. FAILURE INDICATION MESSAGES ...............................................................................................................19
7. COMMUNICATIONS INTERFACES................................................................................................................20
7.1 PHYSICAL CONNECTION .................................................................................................................................. 20
7.2 TRANSPORT SERVICES...................................................................................................................................... 21
7.3 CONNECTION M ANAGEMENT AND DUPLEXED VRU PG’S........................................................................ 21
7.4 SESSION INITIALIZATION ................................................................................................................................ 21
7.5 SESSION M AINTENANCE .................................................................................................................................. 23
7.6 SESSION TERMINATION ................................................................................................................................... 25
8. APPLICATION LEVEL INTERFACES.............................................................................................................26

8.1 A PPLICATION LEVEL INITIALIZATION ........................................................................................................ 27
8.2 EVENT DATA FEED........................................................................................................................................... 27
8.2.1 Data Initialization...................................................................................................................................28
8.2.2 Event Data Feed Database Reporting.................................................................................................33
8.2.2.1 Termination Call Detail........................................................................................................................... 33
8.2.2.2 Service Real-time..................................................................................................................................... 35
8.2.2.3 Peripheral Real-time................................................................................................................................ 35
8.2.2.4 Trunk Group Real-time .......................................................................................................................... 36
8.2.3 Unsolicited Events...................................................................................................................................36

8.2.3.1 Delivered Event...................................................................................................................................... 36
8.2.3.2 Originated Event ..................................................................................................................................... 37
8.2.3.3 Call Cleared Event................................................................................................................................... 39
8.2.3.4 Conferenced Event .................................................................................................................................. 41
8.2.3.5 Diverted Event ........................................................................................................................................ 41
Page iv
8.2.3.6 New Transaction Event ...........................................................................................................................42
8.2.3.7 Set Call Variables Event...........................................................................................................................43
8.2.3.8 VRU Status Event ...................................................................................................................................43
8.2.3.9 Trunk Group Status Event ......................................................................................................................45
8.2.3.10 Service Status Event ............................................................................................................................45
8.3 CALL ROUTING INTERFACE .............................................................................................................................46

8.4 TIME SYNCHRONIZATION INTERFACE ..........................................................................................................51
8.5 SERVICE CONTROL INTERFACE ......................................................................................................................52
8.5.1 Initializing the Service Control Interface...........................................................................................52
8.5.1.1 Initializing Trunk Group Data.................................................................................................................53
8.5.1.2 Initializing VRU Service Data..................................................................................................................53
8.5.1.3 Initializing VRU Peripheral Data.............................................................................................................54
8.5.2 Service Control Database Reporting .................................................................................................55

8.5.2.1 Termination_Call_Detail Database Records............................................................................................56
8.5.2.2 Service_Real_Time Database Records.....................................................................................................57
8.5.2.3 Peripheral_Real_Time Database Records................................................................................................59
8.5.2.4 Trunk Group_Real_Time Database Records ..........................................................................................61
8.5.3 Service Control Dialogues....................................................................................................................61

8.5.3.1 Establishing Service Control Dialogues ...................................................................................................62
8.5.3.2 Sending Event Reports via Dialogues ......................................................................................................62
8.5.3.3 Sending Call Control Instructions via Dialogues .....................................................................................63
8.5.3.4 Canceling Running VRU Scripts or MicroApplications .........................................................................63
8.5.3.5 Terminating Service Control Dialogues ...................................................................................................64
8.5.4 Using MicroApplications ......................................................................................................................64

8.5.4.1 Using Media Specifiers............................................................................................................................65
8.5.4.2 Using Automatic Speech Recognition (ASR)..........................................................................................68
8.5.4.3 MicroApplication Message Flow ...........................................................................................................68
8.5.5 Service Control Messages .....................................................................................................................69

8.5.5.1 Service Control Interface Initialization Messages ...................................................................................71
8.5.5.2 Service Control Interface Status Reporting Messages.............................................................................77
8.5.5.3 NEW_CALL Message (VRU to PG)......................................................................................................79
8.5.5.4 REQUEST_INSTRUCTION Message (VRU to PG)............................................................................82
8.5.5.5 RUN_SCRIPT_REQ Message (PG to VRU).........................................................................................83
8.5.5.6 RUN_SCRIPT_RESULT Message (VRU to PG)..................................................................................84
8.5.5.7 MICROAPP_CONTEXT (PG to VRU)................................................................................................86
8.5.5.8 MICROAPP_PLAY (PG to VRU).........................................................................................................88
Page v
8.5.5.9 MICROAPP_PLAY_CONTINUE (PG to VRU)................................................................................. 90
8.5.5.10 MICROAPP_COLLECT_DATA (PG to VRU) .............................................................................. 90
8.5.5.11 MICROAPP_MENU (PG to VRU).................................................................................................. 93
8.5.5.12 MICROAPP_RESULT (VRU to PG)............................................................................................... 94
8.5.5.13 CANCEL Message (PG to VRU) ...................................................................................................... 98
8.5.5.14 CONNECT Message (PG to VRU)................................................................................................... 98
8.5.5.15 RELEASE Message (PG to VRU) ................................................................................................... 101
8.5.5.16 NEW_DIALOGUE Message (VRU to PG) .................................................................................... 101
8.5.5.17 EVENT_REPORT Message (VRU to PG)...................................................................................... 103
8.5.5.18 DIALOGUE_FAILURE_CONF Message (VRU to PG) ............................................................... 104
8.5.5.19 DIALOGUE_FAILURE_EVENT Message (VRU to PG or PG to VRU)..................................... 105
8.5.5.20 CONNECT_TO_RESOURCE Message (PG to VRU)................................................................... 106
8.5.5.21 RESOURCE_CONNECTED Message (VRU to PG)..................................................................... 106
8.5.5.22 TEMPORARY_CONNECT Message (PG to VRU)...................................................................... 107
8.5.6 Service Control Dialogue state machine ......................................................................................... 108

8.5.6.1 State Transition Table........................................................................................................................... 111
8.5.7 Service Control Dialogue Examples................................................................................................. 113

8.5.7.1 Pre-Routed Call..................................................................................................................................... 113
8.5.7.2 Non-Pre-Routed Call ............................................................................................................................ 114
8.5.7.3 Non-Pre-Routed Call with a Cancel Request........................................................................................ 114
8.5.7.4 Failed Cancel Request........................................................................................................................... 115
8.5.7.5 Release Request .................................................................................................................................... 116
8.5.7.6 Blind Transfer....................................................................................................................................... 117
8.5.7.7 NIC Take-Back..................................................................................................................................... 118
8.5.7.8 Service Control Dialogue with Re-Route............................................................................................. 119
8.5.7.9 Dialogue Creation Failure...................................................................................................................... 120
8.5.7.10 Service Control Dialogue Creation Timeout ..................................................................................... 121
8.5.7.11 Request Failure without Recovery ................................................................................................... 121
8.5.7.12 Request Failure with Recovery ........................................................................................................ 122
8.5.7.13 MicroApplication Request............................................................................................................... 122
9. IMPLEMENTATION OPTIONS ..................................................................................................................... 123

9.1 EVENT DATA FEED INTERFACE ................................................................................................................... 123
9.2 CALL ROUTING INTERFACE .......................................................................................................................... 124
9.3 TIME SYNCHRONIZATION INTERFACE ....................................................................................................... 124
9.4 SERVICE CONTROL INTERFACE .................................................................................................................... 124
Page vi
10. STATUS CODES AND CONSTANTS.......................................................................................................125
Page vii
Table of Tables
Table 1. General Message Layout ........................................................................................................................................9
Table 2. Message Header (MHDR) Format........................................................................................................................9
Table 3. Message Set...........................................................................................................................................................11
Table 4. Fixed-length Data Types ......................................................................................................................................11
Table 5. Variable-length Data Types .................................................................................................................................12
Table 6. MEDIA_SPECIFIER for HTTP, File, or Streaming Media ................................................................................13
Table 7. MEDIA_SPECIFIER for Text -to-Speech.............................................................................................................13
Table 8. MEDIA_SPECIFIER for Data ...............................................................................................................................13
Table 9. Null MEDIA_SPECIFIER ......................................................................................................................................14
Table 10. Floating Field Message Element Format..........................................................................................................14
Table 11. Message Element Names and Types ................................................................................................................16
Table 12. REGISTER_VARIABLES Message Format.....................................................................................................17
Table 13. FAILURE_CONF Message Format ..................................................................................................................20
Table 14. FAILURE_EVENT Message Format ................................................................................................................20
Table 15. OPEN_REQ Message Format............................................................................................................................22
Table 16. OPEN_CONF Message Format.........................................................................................................................23
Table 17. HEARTBEAT_REQ Message Format..............................................................................................................24
Table 18. HEARTBEAT_CONF Message Format...........................................................................................................24
Table 19. CLOSE_REQ Message Format..........................................................................................................................26
Table 20. CLOSE_CONF Message Format.......................................................................................................................26
Table 21: Application Interface Initialization ....................................................................................................................27
Table 22. INIT_DATA_REQ Message Format................................................................................................................29
Table 23. INIT_DATA_CONF Message Format.............................................................................................................29
Table 24. INIT_TRKGRP_DATA_EVENT Message Format ........................................................................................30
Table 25. INIT_SERVICE_DATA_EVENT Message Format........................................................................................31
Table 26. INIT_VRU_DATA_EVENT Message Format................................................................................................32
Table 27. INIT_DATA_END_EVENT Message Format................................................................................................32
Table 28. Trunk Status Definitions....................................................................................................................................32
Table 29: Termination Call Detail Support .........................................................................................................................35
Table 30: Peripheral Real-time Support ..............................................................................................................................36
Table 31. DELIVERED_EVENT Message Format............................................................................................................37
Table 32. ORIGINATED_EVENT Message Format ........................................................................................................38
Table 33. CALL_CLEARED_EVENT Message Format..................................................................................................39
Table 34. Call Cleared Causes.............................................................................................................................................40
Page ix
Table 35. CONFERENCED_EVENT Message Format......................................................................................................41

Table 36. DIVERTED_EVENT Message Format...............................................................................................................41
Table 37. NEW_TRANSACTION_EVENT Message Format........................................................................................42
Table 38. SET_CALL_VARIABLES_EVENT Message Format ....................................................................................43
Table 39. VRU_STATUS_EVENT Message Format.......................................................................................................44
Table 40. TRKGRP_STATUS_EVENT Message Format ...............................................................................................45
Table 41. SERVICE_STATUS_EVENT Message Format...............................................................................................45
Table 42. ROUTE_REQUEST_EVENT Message Format................................................................................................49
Table 43. ROUTE_SELECT Message Format...................................................................................................................50
Table 44. ROUTE_END_EVENT Message Format..........................................................................................................50
Table 45. ROUTE_END Message Format.........................................................................................................................51
Table 46. Label Types ..........................................................................................................................................................51
Table 47. TIME_SYNCH_REQ Message Format.............................................................................................................52
Table 48. TIME_SYNCH_CONF Message Format..........................................................................................................52
Table 49: Termination_Call_Detail Database Records.....................................................................................................56
Table 50 Service_Real_Time Database Records...............................................................................................................59
Table 51: Peripheral_Real_Time Database Records.........................................................................................................60
Table 52: TrunkGroup_Real_Time Database Records.....................................................................................................61
Table 53: Components of a Media URL .............................................................................................................................66
Table 54: Playback Types in Data Media Specifiers ........................................................................................................67
Table 55: Playback Formats in Data Media Specifiers .....................................................................................................67
Table 56. Service Control Message Header (SERVICEHDR) Format............................................................................69
Table 57. Service Control Message Sub-Types...............................................................................................................71
Table 58. INIT_SERVICE_CTRL_REQ Message Format ...............................................................................................71
Table 59. INIT_SERVICE_CTRL_CONF Message Format ............................................................................................72
Table 60. INIT_SERVICE_CTRL_DATA Message Format...........................................................................................72
Table 61. Supported Service Feature Bit Masks ...............................................................................................................73
Table 62. INIT_SERVICE_CTRL_TRKGRP Message Format .......................................................................................74
Table 63. INIT_SERVICE_CTRL_SERVICE Message Format.......................................................................................75
Table 64. INIT_SERVICE_CTRL_VRU Message Format...............................................................................................76
Table 65. INIT_SERVICE_CTRL_END Message Format...............................................................................................77
Table 66. TRKGRP_STATUS Message Format...............................................................................................................77
Table 67. SERVICE_STATUS Message Format ..............................................................................................................78
Table 68. NEW_CALL Message Format...........................................................................................................................81
Table 69. REQUEST_INSTRUCTION Message Format.................................................................................................83
Table 70. RUN_SCRIPT_REQ Message Format...............................................................................................................84
Page x
Table 71. RUN_SCRIPT_RESULT Message Format ......................................................................................................86

Table 72. MICROAPP_CONTEXT Message Format.......................................................................................................87
Table 73. MICROAPP_PLAY Message Format ...............................................................................................................89
Table 74. MICROAPP_PLAY_CONTINUE Message Format........................................................................................90
Table 75. MICROAPP_COLLECT_DATA Message Format .........................................................................................92
Table 76. Bit Mask Values DTMF Termination Key........................................................................................................93
Table 77. MICROAPP_MENU Message Format..............................................................................................................94
Table 78. MICROAPP_RESULT Message Format...........................................................................................................96
Table 79. Microapp Error Codes .........................................................................................................................................98
Table 80: CANCEL Message Format..................................................................................................................................98
Table 81. CONNECT Message Format............................................................................................................................100
Table 82. Label Types........................................................................................................................................................100
Table 83: RELEASE Message Format ..............................................................................................................................101
Table 84. NEW_DIALOGUE Message Format..............................................................................................................102
Table 85. EVENT_REPORT Message Format................................................................................................................103
Table 86. Event Report Codes ...........................................................................................................................................104
Table 87. DIALOGUE_FAILURE_CONF Message Format.........................................................................................104
Table 88. DIALOGUE_FAILURE_EVENT Message Format.......................................................................................105
Table 89. CONNECT_TO_RESOURCE Message Format .............................................................................................106
Table 90. RESOURCE_CONNECTED Message Format................................................................................................106
Table 91. TEMPORARY_CONNECT Message Format.................................................................................................108
Table 92. Status Codes ......................................................................................................................................................126
Table 93. Special Values ....................................................................................................................................................127
Page xi
Table of Figures
Figure 1. Typical configuration with duplexed PG’s.......................................................................................................20
Figure 2. Session Initialization Message Flow.................................................................................................................22
Figure 3. Heartbeat Message Flow....................................................................................................................................24
Figure 4. Session Termination Message Flow.................................................................................................................25
Figure 5. Data Initialization Message Flow......................................................................................................................28
Figure 6: Termination Call Detail Record Example ............................................................................................................34
Figure 7. Call Routing Message Flow................................................................................................................................47
Figure 8. Call Routing Error Message Flow......................................................................................................................48
Figure 9. Service Control Initialization Sequence.............................................................................................................55
Figure 10: NEW_DIALOGUE Example Message Flow..................................................................................................102
Figure 11: State Diagram with Cancel Supported ...........................................................................................................109
Figure 12: State Diagram with Cancel Not Supported....................................................................................................110
Figure 13: Service Control Dialogue for Pre-Routed Call Example ...............................................................................113
Figure 14: Service Control Dialogue for Non-Pre-Routed Call Example ......................................................................114
Figure 15: Non-Pre-Routed Call with a Successful Cancel Request............................................................................115
Figure 16: Service Control Dialogue with a Failed Cancel Request.............................................................................116
Figure 17: Service Control Dialogue with a Release Request.......................................................................................117
Figure 18: Blind Transfer with CONNECT .......................................................................................................................117
Figure 19: Blind Transfer with CONNECT_TO_RESOURCE........................................................................................118
Figure 20: NIC Take-Back Example ...................................................................................................................................119
Figure 21. Reroute Service Control Dialogue Example...................................................................................................120
Figure 22. Dialogue Creation Failure Example .................................................................................................................120
Figure 23. Service Control Dialogue Creation Timeout Example ..................................................................................121
Figure 24. Request Failure without Recovery Example..................................................................................................121
Figure 25. Request Failure with Recovery Example........................................................................................................122
Figure 26: MicroApplication Requests with a Disconnect Event................................................................................123
Page xiii
1. Revision Information
Changes in Revision 1.1

• The message type numbers have been added to Table 3.
• Message fields in the floating parts of messages have been labeled to indicate their required or optional
status.
• The maximum length of the Text field in the CLOSE_REQ message has been changed from 256 to 255 bytes.
• The data type of the TimeZoneDelta field in four messages (INIT_VRU_DATA_EVENT,
VRU_STATUS_EVENT, CHKPNT_VRU_DATA_EVENT, and POLL_VRU_STATUS_CONF) has been
changed from UINT to INT.
• Tag values 2 through 17 have been removed from Table 11. They were not used.
• Specific status code values have been documented for messages that include a status code field.
• The DEFAULT label type has been added to Table 46.
• The message flow diagrams for call routing dialogues have been clarified.
• The requirements for trunk numbering have been clarified.
• The use of labels in the Call Routing interface has been clarified.

• The requirements for trunk group and trunk numbering have been clarified (section 3.1).
• An implementation note has been added regarding the use of cumulative …Today counters in the Event
Data Feed Interface (section 8.2.1).
• An implementation note has been added regarding resets of cumulative …Today counters in the Event
Data Feed Interface (section 8.2.1).
• The description of the CONFERENCED_EVENT message has been clarified (section 8.2.3.4).
• An implementation note has been added regarding the use of the Checkpoint facility within the Event Data
Feed Interface (section 6.1.3).
• Implementation notes have been added regarding resets of cumulative …Today counters in the Polled Data
Feed Interface.

• The STRING data type (section 4.2) has been clarified and an implementation note has been added.
• The Session Maintenance section (section 5.5) has been corrected to state that the heartbeat mechanism is
independent of all other messages. The section previously incorrectly stated that heartbeat requests
would only be sent if the session was idle (no messages received).
• The checkpoint functionality has been permanently removed from the interface (previously section 6.1.3).
• The description of the Call Routing Interface (section 6.3) has been expanded to include a discussion of
the relationship of the LABEL_TYPE element to LABEL element within the ROUTE_SELECT message.
• Support for the POST_QUERY label type in the ROUTE_SELECT message has been removed (section 6.3).
Page 1
• The SERVICE _CONTROL message type has been added to the Message Set table (see Table 1).
• The Service Control message header type has been added to the Data Types table (see Table 2).
• The Connection Management (section 5.3) procedure has been to changed to require that a VRU post
multiple TCP/IP listen request with a backlog greater than 1. Furthermore, if a connection request arrives
while a previously established connection is in place, the previous connection will be closed and new
connection establishment will proceed.
• The Session Initialization (section 5.4) OPEN_REQ message has been modified to support both version 1
and version 2 of the VRU Interface Protocol.
• The Session Initialization (section 5.4) procedure has been modified accept session initialization requests
while there is an existing session. The existing session should be terminated and the new session
initialization request should be processed.
• A Boolean value has been added to the OPEN_REQ_CONF message (section 5.4) to allow the VRU to
indicate if support exists for the Service Control Interface (section 8.5).
• The CALL_CLEARED event message (section 6.1.2.3) has been modified to allow either the TrunkGroupID
or the TrunkNumber to be specified. Details are contained in the related implementation note.
• The Service Control application interface (section 8.5) has been added to allow ICM Scripts to control VRU
call handling operations.
• The Implementation Options section (section 8.5.7.13) has been expanded to include a discussion of the
Service Control Interface (section 9.4).
• The Status Codes and Constants Section (10) has been expanded to include the new Service Control error
codes.

• Corrected implementation notes by removing the references to ICM Release 1.6, and added an
implementation note stating that the INIT_TRKGRP_DATA_EVENT and INIT_SERVICE_DATA_EVENT
messages may now be sent optionally (section 8.2.1).
• Added Event Interface Database Reporting (sections 8.2.2, 8.2.2.1, 8.2.2.2, 8.2.2.3, 8.2.2.4) sections to
document ICM Database reporting.
• Modified the Initializing the Service Control Interface (section 8.5.1) section to allow for optional
initialization of Trunk Group, Service, and VRU Peripheral Data objects.
• Added Service Control Database Reporting (sections 8.5.2, 8.5.2.1, 8.5.2.2, 8.5.2.3, 8.5.2.4) sections to allow
ICM database reporting based on Service Control messages.
• Updated the Sending Event Reports via Dialogues (section 8.5.3.2) discussion regarding ABANDON
event report messages.
• Updated Table 57. Service Control Message Sub-Types to include new messages related to initialization
and Service Control database reporting.
• Corrected cases where message descriptions for the INIT_SERVICE_CTRL_CONF,
INIT_SERVICE_CTRL_DATA, INIT_SERVICE_CONTROL_END, RUN_SCRIPT_RESULT messages
incorrectly specified the sending of a DIALOGUE_FAILURE_EVENT rather than a
DIALOGUE_FAILURE_CONF message (sections 8.5.5.1.2, 8.5.5.1.3, 8.5.5.1.7)
• Added an optional CorrelationID field to the REQUEST_INSTRUCTION message to be used by in- network
VRU’s within INAP networks.
Page 2
• Added an optional CauseCode to the EVENT_REPORT / DISCONNECT message (section 8.5.5.14).

• Modified sections 9.1, 9.2, and 9.4 to document compatibility issues when using multiple application
interfaces.
• Updated Table 11 to include tags for the new optional CorrelationID and CauseCode fields.

• Corrected the INIT_SERVICE_CTRL_VRU (Section 8.5.5.1.6) and the VRU_STATUS messages to include
the current time in UTC format. These fields were omitted in revision 2.1 of the message definitions.
• Corrected the EVENT_REPORT (Section 8.5.5.14) CauseCode element description to point to Table 34. Call
Cleared Causes rather than Table 23.

• Corrected Figure 4 and the text in Session Termination section (Section 7.6). The text failed to indicate that
a CLOSE_REQ would be sent to close an open session in response to a FAILURE_EVENT.
• Corrected the text describing the Service Control Connect message that incorrectly specified that a
DIALOGUE_FAILURE_CONF message be sent when the Connect message can not be processed. The text
should have specified a DIALOGUE_FAILURE_EVENT message in this case (Sections 8.5.3.3,8.5.3.4).
• Updated the Service Control Message Sub-Types (Table 57) to define include the CANCEL, and RELEASE
messages.
• Modified the INIT_SERVICE_CTRL_DATA message Supported Feature Masks Bits (Table 61) to define
the CANCEL and RELEASE operations.
• Added two new Service Control Messages to support ICM Queue Points. The Cancel Request will allow
the ICM Router to Cancel out-standing RUN_SCRIPT_REQ requests asynchronously. The Release
request will allow the ICM Router to instruct the VRU to release the call associated with a given dialogue.
• Updated the Service Control protocol example section to illustrate the use of the new messages.
• Added an additional pair of status codes to Table 92, E_OPERATION_NOT_CANCELLED, and
E_OPERATION_CANCELLED to indicate the success or failure of a CANCEL operation.

• Changed protocol version from 2 to 3.
• Added new message type: REGISTER_VARIABLES.
• Added new message elements: ECC Variable Registration, ECC Value.
• Added Section 5: Expanded Call Context.
• Added table of result codes to Release message definitions to match CRSP protocol.

• Moved declaration of the REGISTER_VARIABLES message to section 5: Expanded Call Context.
• Fixed various typographical and grammatical errors.
• Removed mention of the real-time database entries that are not based on VRU messages.
Page 3

• Fixed description of Expanded Call Context array element index. Was documented as UINT but built as
UCHAR

• Allowed for the Event Data Feed and Service Control Interface to both be used within a single session.
• Added a NEW_DIALOGUE Service Control message to allow an Event Feed call to be converted to a
Service Control dialogue.
• Added a NewTransaction flag to the RUN_SCRIPT_RESULT Service Control message to provide the
functionality of the NEW_TRANSACTION_EVENT message of the Event Data Feed interface.
• Changed the protocol version from 3 to 4.
• Spelled out in section 8.1 the initialization behavior when Event Data Feed and Service Control Interface are
both enabled by the VRU.
• Removed the GED-125 cover page.

• Changed ICM revision to 4.5
• A problem in OPC causes a ROUTE_REQUEST_EVENT from the VRU to get a CONNECT in reply if
UseServiceControl is set to TRUE in OPEN_CONF. Made UseCallRouting and UseServiceControl mutually
exclusive.
• Network Blind Transfer
NOTE: Since the message changes only appear when a VRU selects the new Blind Transfer capability,
the protocol version will remain at 4.
• Added “FEATURE_BLIND_TRANSFER” and “FEATURE_NEED_RELEASE” capability flags to
INIT_SERVICE_CTRL_DATA ServiceFeatures flags.
• Added CONNECT_TO_RESOURCE and RESOURCE_CONNECTED messages under Service
Control Interface. These will allow the VRU PG to tell the VRU to connect the call to the
announcement-playing function (possibly disconnecting from an existing destination).
• Added a new TransferHint (optional) field to CONNECT. This will be set to TRUE if the VRU PG
reserves the right to do a Transfer for this call after this CONNECT.
• Added more description to Event Data Feed messages DELIVERED_EVENT and
ROUTE_REQUEST_EVENT to spell out the special requirements for completing a Translation Route.
• Fixed the format of the VRU_STATUS message. It was shown with an “InvokeID” field that should not
have been there.
• Fixed the format of the NEW_CALL message. It was shown without the optional CallerEnteredDigits field
that should have been there.
• Added E_OPERATION_NOT_CANCELLED, E_SIMULATOR_RESET, and E_SIMULATOR_REINIT to
the Status Codes list.
• Added a state transition diagram and state transition table to the description of the Service Control
Interface.
• Added mentions in the description of messages that depend on FEATURE_ flags.
• Added Termination_Call_Detail disposition codes to table of CAUSE codes.
Page 4
• Put back the old real-time reporting tables that showed what database fields the VRU PIM populated when
using Service Control Reporting.
• Revised and expanded the discussions of ECC variables and the floating field section of the message.
Changes in Revision 2.8a

• Corrected Cancel and Release capability flags
Changes in Revision 2.8b

• Clarified the description of what happens when the VRU refuses to CANCEL a running script or
MicroApplication.
• Revised fault tolerance discussion
• Expanded discussion of registering ECC variables
Changes in Revision 2.8c

• Added Routing Client initialization comments to Call Routing Interface
• Call Routing Interface and Service Control Interface are no longer mutually exclusive.

Clarifications and additions:
• Documented restriction that no trunk group may contain more than 1024 trunks
• Added an announcement that Polled Data Feed will no longer be supported as of ICM Release 5.0.
Changes which apply specifically to ICM Release 4.6.2:
• Changed Protocol Version from 4 to 5
• Added TemporaryConnect message
Changes in Revision 2.9a

• Corrected Table 91, TEMPORARY_CONNECT Message Format, to eliminate the Label Type field. The
inclusion of that field in the Table was an error.
• Added discussion in Section 8.5.5.14, CONNECT Message (PG to VRU), about the use of the ICM/VRU
Interface protocol with partner Type 8 NetworkVRU’s.
• Corrected Table 84, which had an incorrect MessageSubType code for the NewDialogue message.
• Added NewTransactionTag to Table 11, Message Element Names and Types.
• Corrected the appropriate response to a Connect message that cannot be processed by the VRU. It should
return an EventReport/CONNECT_INVALID rather than a DIALOGUE_FAILURE_CONF. This is also a
change from the prior ICM release, in which EventReport/CONNECT_FAILURE was used to report both an
invalid Connect request and to report the network’s inability to complete the connection.
• Corrected the state diagrams in Figure 11 and Figure 12 to reflect the above change.
• Corrected other references to DIALOGUE_FAILURE_CONF. The PG never sends this message to the
VRU; it is strictly a VRU to PG message. In most cases, where DIALOGUE_FAILURE_CONF was
mentioned, it should have been DIALOGUE_FAILURE_EVENT.
Page 5
• Added information about the re-use of Event Data Feed CallID’s in the ORIGINATED_EVENT and
DELIVERED_EVENT discussions, Sections 8.2.3.2 and 8.2.3.1, respectively.

• Changed protocol version from 4 to 5
• Added MicroApplication Support:
• New discussion about using ICM MicroApplications
• New INIT_SERVICE_CTRL_DATA ServiceFeature bit: FEATURE_RUN_MICROAPP
• New element datatype: MEDIA_SPECIFIER
• Added call termination disposition DBCD_CALLED_PARTY_DISCONNECTED
Changes in Revision 3.0b

• Changed Protocol Version from 5 to 6.
Changes in Revision 3.0c

• Corrected Sections 8.5.4.1.3 and 8.5.4.2, which indicated that MediaSpecifier Data values, and ASR Grammar
Strings are null terminated. In fact they are not, but like any string message element their lengths can be
determined based on the message element’s LENGTH field.
• For MicroappMenu and MicroappCollectData messages, added definition and description of DTMF
KEY_NONE. Also clarified use of the DTMF Termination Key field in MicroappCollectData for fixed length
input strings.
• Clarified that trunk group ID’s may only be in the range 0 to 65535, even when 4 bytes are available in the
message field.
Page 6
2. Overview
This document describes the hardware and software interface between the ICM and Voice Response Units.
The interface allows an ICM Peripheral Gateway to collect data from a VRU for use in call routing, real time
monitoring, and historical reporting. The interface also allows the VRU to make use of the ICM’s call routing
function to select the target for a call being transferred. The Service Control interface will allow an ICM script to
provide call-handling instructions to the VRU.
The interface is not specific to a particular VRU type or manufacturer. Instead, the interface is based on a
generic VRU model. To interface a particular VRU to the ICM, the VRU must be programmed to meet the
interface in this specification. Section 3 describes the generic VRU model.
The ICM / VRU interface is divided into two major sections. The communications interfaces define low level
conventions and protocols necessary to establish, maintain, and terminate data communications between the
ICM and the VRU. The communications interfaces are defined in section 7. The application interfaces define
the higher level messages which allow the VRU to exchange call processing information with the ICM. The
application interfaces are defined in section 8. The messaging conventions common to both interfaces are
described in section 4.
The interface need not be implemented in its entirety for a given VRU type. Section 7 identifies the required and
optional components of the interface, and describes how they can be combined.
Section 8 gives numeric values for constants used in the ICM / VRU interface.
3. Generic VRU Model

In the ICM’s generic model, a VRU is a switch that interconnects multiple telephone trunks to audio
record/playback units under program control. This gives rise to a range of capabilities that include:
• Initiating calls
• Answering calls
• Playback of pre-recorded announcements and prompts
• Playback of pre-recorded announcements with variable inserts
• Recording of voice messages
• Playback of voice messages
• Collection of caller entered digits
• Holding calls in a wait state
• Transferring calls to an attached switch or network
• Tandem connection of incoming and outgoing calls
• Interaction with a Service computer system over a Service link
• Interaction with an ACD over an ACD-specific CTI link
3.1 Ports, Trunks and Trunk Groups

Each trunk terminating at the VRU connects to a VRU port capable of answering or initiating a call. There is a
one-to-one correspondence between trunks and ports. This interface specification will always refer to the
combination of a port and trunk as simply a trunk .
Page 7
At the VRU, trunks are organized into trunk groups. A trunk group is a collection of trunks having the same
remote termination. Each trunk belongs to exactly one trunk group. Trunks belonging to the same trunk group
are for practical purposes interchangeable.
A VRU must define at least one trunk group for each distinct remote termination. For example, if a VRU has
some trunks which terminate in the network and some which terminate at an ACD, at least two trunk groups
must be defined -- one for the network trunks, and one for the ACD trunks. Similarly, if a VRU has some trunks
which terminate in one IXC network and some which terminate in another IXC network, at least two trunk
groups must be defined -- one for each IXC network.
The VRU may define mo re than one trunk group for a single remote termination, so long as each physical trunk
appears in exactly one trunk group, and the trunks in any one trunk group all have the same remote termination.
The VRU assigns a trunk group ID to each trunk group. The trunk group ID is a number between 0 and 65,535
that serves to identify the trunk group among those configured on the VRU. The VRU also assigns a trunk
number to each trunk. Trunk numbers must be unique within a trunk group, and may range from 0 to 32767.
However, in total there may not be more than 1024 trunks defined for a particular trunk group. The combination
of a trunk group ID and a trunk number is used to identify an individual trunk and its trunk group membership.
Trunk group ID’s and trunk numbers are configured in the ICM’s central database and should remain constant
across VRU restarts.
The ICM uses information about trunks and trunk groups to make call routing decisions. The ICM also
provides this information in real time monitor screens and historical reports. Services
A service is a particular type of processing that a caller requires. For example, in a software company’s call
center, a caller might have a question about installing software. This caller would be directed to the “Technical
Support” service. A different caller wishing to purchase software might be directed to the “Sales” service.
In a VRU, a service might be represented by a call processing script, or by a set of related call processing
scripts.
A VRU may provide one or more services to its callers. The VRU assigns a unique identifier to each service that
it provides. Each call that the VRU receives or initiates is attributed to a service.
The VRU assigns a Service ID to each service. The Service ID is a static identifier for the service. The ICM
uses the Service ID to distinguish one service on the VRU from another. The ID’s are configured in the ICM’s
central database and should remain constant across VRU restarts.
The ICM uses information about services to make call routing decisions. The ICM also provides this
information in real time monitor screens and historical reports.
3.2 System Clock

The VRU has a system clock, capable of reporting the current time with one-second precision. The VRU may
keep time in the local time zone, but must be capable of reporting time in Coordinated Universal Time (UTC).
The VRU may optionally adjust its time zone for Daylight Savings Time.
The VRU may optionally support adjusting the system clock to synchronize with an external time reference.
3.3 Operational Status

The VRU maintains and reports to the ICM an operational status value that indicates whether the VRU is fully
operational, operating in a degraded state, or non-operational.
In addition, the VRU may maintain and report other status information that may be relevant to the ICM. This
status may comprise up to 16 integer values.
Page 8
4. Messaging Conventions
Communication between the VRU and the Peripheral Gateway is accomplished by the exchange of messages.
The message set defined in this specification is loosely modeled after CSTA messaging conventions. An
attempt has been made to follow CSTA naming conventions and the request / confirmation and unsolicited
event paradigms. A simpler set of data types than those defined by CSTA are used, however.
In the CSTA model, one party acts as a server and the other as a client. In the ICM / VRU interface, the
Peripheral Gateway takes the client role, issuing requests to the VRU. The VRU takes the server role,
responding to requests from the Peripheral Gateway and originating unsolicited events.
Field Name Value
Message Header A standard header containing Message Length and Message Type. See section
4.1 below.
Fixed Fields Section Fixed-length required message data, if any. Each data item has an implied type
and implied length.
Floating Fields Section Optional or variable-length message elements, if any. Each message element
consists of a 1-byte type tag, a 1-byte length field, followed by up to 255 bytes of
payload. The payload itself may contain zero or more fixed-length data fields,
and, optionally, a single variable-length data item.
Table 1. General Message Layout
4.1 Message Header (MHDR)

The MHDR data type is a common message header that precedes all messages exchanged between the
Peripheral Gateway and the VRU. Table 2 defines the message header format.
Field Name Value Data Type Byte Size
MessageLength The length of the message in bytes, excluding the size of UINT 4
the message header (the first 8 bytes)
MessageType The type of message UINT 4
Table 2. Message Header (MHDR) Format
4.1.1 Base Message Types

Table 3 defines the base message set. The messages are described in greater detail in the remainder of this
document. The Sub-Types for messages of type 47 (SERVICE_CONTROL) are found in Table 57 on page 71.
Message Type # Purpose
FAILURE_CONF 1 Negative confirmation; may be sent in response to any
request.
FAILURE_EVENT 2 Unsolicited notification of a failure or error.
OPEN_REQ 3 Communication session establishment request.
OPEN_CONF 4 Communication session establishment confirmation.
HEARTBEAT_REQ 5 Communication session maintenance request.
HEARTBEAT_CONF 6 Communication session maintenance confirmation.
Page 9
CLOSE_REQ 7 Communication session termination request.

CLOSE_CONF 8 Communication session termination confirmation.
INIT_DATA_REQ 9 Request for initial state for event data feed.
INIT_DATA_CONF 10 Confirmation that event data initialization will proceed.
INIT_TRKGRP_DATA_EVENT 11 Event feed initial state for one trunk group.
INIT_SERVICE_DATA_EVENT 12 Event feed initial state for one service.
INIT_VRU_DATA_EVENT 13 Global VRU event feed initial state.
INIT_DATA_END_EVENT 14 Indication that event feed initial state has been
transferred completely.
DELIVERED_EVENT 15 Notification of inbound calls arrival.
ORIGINATED_EVENT 16 Notification of outbound calls initiation.
CALL_CLEARED_EVENT 17 Notification of call termination.
CONFERENCED_EVENT 18 Notification of tandem connection of inbound and
outbound calls.
DIVERTED_EVENT 19 Notification of calls changing to a different service.
NEW_TRANSACTION_EVENT 20 Notification of an existing calls changing to a new call.
SET_CALL_VARIABLES_EVENT 21 Notification of call-associated data to record.
VRU_STATUS_EVENT 22 Notification of a change in the call-processing status
of the VRU.
TRKGRP_STATUS_EVENT 23 Notification of a change in the call-processing status
of a trunk group.
SERVICE_STATUS_EVENT 24 Notification of a change in the call-processing status
of a service.
25-40 (obsolete)
ROUTE_REQUEST_EVENT 41 Initiates a call routing dialogue and requests a routing
destination for a call.
ROUTE_SELECT 42 Routing destination information.
ROUTE_END_EVENT 43 Terminates call routing dialogue. (VRU)
ROUTE_END 44 Terminates call routing dialogue. (PG)
TIME_SYNCH_REQ 45 Request to synchronize time.
TIME_SYNCH_CONF 46 Confirmation of time synchronization request.
SERVICE _CONTROL 47 Indicates that the message is a Service Control
message. The Service Control message header must be
parsed to determine the message subtype (see Table
57 on page 71 for the list of subtypes).
48 (Simulator Reset Event)
REGISTER_VARIABLES 49 Register for access to a list of Call Variables and
Extended Call Context variables.
Page 10
Table 3. Message Set
4.2 Fixed-length Data Types

The data types used to define fields within the Fixed Fields Section are listed in Table 4. Note that all numeric
data longer than one byte are transmitted in order of most significant byte to least significant byte. This is the
canonical network byte order defined by TCP/IP standards.
Data Type Meaning Byte Size
CHAR Signed integer, -128 to 127 1
UCHAR Unsigned integer, 0 to 255 1
SHORT Signed integer, -32,768 to 32,767 2
USHORT Unsigned integer, 0 to 65,535 2
INT Signed Integer, -2,147,483,648 to 2,147,483,647 4
UINT Unsigned Integer, 0 to 4,294,967,295 4
BOOL Boolean (False = 0, True = 1) 4
TIME A date/time, expressed as the number of seconds since midnight 4
January 1, 1970 Coordinated Universal Time (UTC).
MHDR Message header (see below) 8
SERVICEHDR Service Control Message header (see section 8.5.4) 12
Table 4. Fixed-length Data Types
Page 11
4.3 Variable-length Data Types

The data types used to define the tagged message elements within the Floating Fields Section are listed in
Table 5.
Data Type Meaning Byte Size
STRING A series of bytes of ASCII data NOT terminated by a null 0-255
character. Unless otherwise specified, it is valid for a STRING
data item to have a minimum length of zero.
UNSPEC A series of arbitrary data bytes. Unless otherwise specified, it is 0-255
valid for an UNSPEC data item to have a minimum length of zero.
ECC_VAR_NAME A UINT tag and a STRING name (up to 32 characters). The VRU 4-36
uses this element to associate a tag number with an ECC variable.
The tag number will identify the ECC variable in values passed to
or from the VRU.
ECC_VAR_VALUE A UINT tag and a STRING value (up to 210 characters). The 4-214
UINT tag references a particular ECC scalar variable whose
contents is to be set. The STRING value provides the new value
of the scalar variable.
ECC_VAR_ARRAY A UINT tag, a UCHAR array index and a STRING value (up to 210 5-215
characters). The UINT tag references a particular ECC array
variable and the UCHAR array index specifies which array element
is to be set. The STRING value provides the new value of the
array element.
MEDIA_SPECIFIER First byte: Format (including first byte): 1-219
H, S, F or O UCHAR, UCHAR, STRING(210)
T UCHAR, STRING(210)
D UCHAR, UINT, UINT, STRING(210)
Null (zero) UCHAR only
Table 5. Variable-length Data Types
4.3.1 Message Element Data Type: MEDIA_SPECIFIER

All MEDIA_SPECIFIER element types begin with the Media Protocol field, but what follows depends on the
particular Media Protocol selected. The Media Protocol field is a single byte containing a case-specific
alphanumeric character, or zero. Currently only H, S, F, O, T, D and Null Media Protocols can be generated by
the ICM Script Editor, but others may be defined in the future as required, without modifying the ICM/VRU
protocol. In the mean time, the VRU should assume that any media protocol it encounters which is not included
in the above list will be formatted the same as if it were an HTTP (H) protocol.
Of the seven Media Protocols, the first four (H, S, F and O) share a common format. The remaining Media
Protocols have their own individual formats, as described in the following sections.
Page 12
4.3.1.1 HTTP, File, or Streaming Media Specifiers

If the Media Protocol is HTTP, File, or Streaming media, the MEDIA_SPECIFIER contains the following fields:
Field Name Data Items Valid Lengths
Media Protocol UCHAR: ‘H’=HTTP, ‘F’=File, ‘S’=Streaming, 1
‘O’=Other
Library Designator UCHAR: ‘S’=System, ‘A’=Application, ‘N’=None 1
Media Filename STRING 0-210
Table 6. MEDIA_SPECIFIER for HTTP, File, or Streaming Media

The STRING length is calculated by subtracting 2 from the payload length contained in the tagged message
element header.
4.3.1.2 Text-to-Speech Media Specifiers

For Text -to-Speech, the MEDIA_SPECIFIER contains the following fields:
Media Protocol UCHAR: ‘T’=Text 1
Text String STRING 0-210
Table 7. MEDIA_SPECIFIER for Text-to-Speech

element header.
Note that Text-to-Speech can also be accomplished using a Data Media Specifier, with a Data Playback Type of
PLAYBACK_TYPE_TEXT. If a specific VRU implementation is to support Text -to-Speech capabilities, it
should support both of these methods.
4.3.1.3 Data Media Specifiers

For Data, the MEDIA_SPECIFIER contains the following fields:
Media Protocol UCHAR: ‘D’=Data 1
Data Playback Type UINT (see below) 4
Data Playback Format UINT (see below) 4
Data Value STRING 0-210
Table 8. MEDIA_SPECIFIER for Data

Data Playback Types:
PLAYBACK_TYPE_NUMBER 1
PLAYBACK_TYPE_CHAR 2
PLAYBACK_TYPE_ETIME 3
PLAYBACK_TYPE_TOD 4
PLAYBACK_TYPE_24TOD 5
PLAYBACK_TYPE_DOW 6
PLAYBACK_TYPE_DATE 7
Page 13
PLAYBACK_TYPE_CURRENCY 8
PLAYBACK_TYPE_TEXT 9
Data Playback Formats:
(This field is only relevant if Data Playback Type is one of the time formats. It should contain
PLAYBACK_FORMAT_OTHER in all other cases.)
PLAYBACK_FORMAT_HHMM 1
PLAYBACK_FORMAT_HHMMSS 2
PLAYBACK_FORMAT_HHMMAP 3
PLAYBACK_FORMAT_OTHER 0
element header.
4.3.1.4 Null Media Specifiers

For some purposes it may be necessary to use a null media specifier as a placeholder. This indicates that no
media is to be played. A null media specifier contains only the following field:
Media Protocol UCHAR: ‘\0’=Null 1
Table 9. Null MEDIA_SPECIFIER
4.4 Floating Field Message Elements

Fields that are either optional or of variable length are added at the end of a message as tagged message
elements. Each element contains zero or more fixed-length data items (see Table 4 above) and, optionally, a
single variable-length data item.
Tag The type of message element. UCHAR 1
Length The number of bytes of data, ‘N’, in the message element UCHAR 1
payload.
Payload The data. UCHAR N
Table 10. Floating Field Message Element Format
Page 14
Each tagged message element carries an implied data type from the list of fixed-length or variable-length data
types. Table 11 lists the message elements that may appear in the Floating Field Section.
Message Element Name Tag Data Type Valid Lengths
Invalid 0
Text 1 STRING 1-255
(obsolete) 2-17
ANI 18 STRING 1-40
UUI 19 UNSPEC 1-131
DNIS 20 STRING 1-32
Digits Dialed 21 STRING 1-40
Call Variable 1 through Call 22-31 STRING 1-40
Variable 10
Dialed Number 32 STRING 1-32
CED 33 STRING 1-40
Label 34 STRING 1-48
Trunk Group ID 35 UINT 4
Trunk Number 36 UINT 4
Called Number 37 STRING 1-32
Script ID 38 STRING 1-40
Script Configuration 39 STRING 1-40
Correlation ID 40 STRING 1-40
Cause Code 41 UINT 4
ExpCallVarName 42 ECC_VAR_NAME 5-36
ExpCallVarValue 43 ECC_VAR_VALUE 5-214
ExpCallVarArray 44 ECC_VAR_ARRAY 6-215
NewTransactionTag 45 BOOL 4
TransferHintTag 46 BOOL 4
Media Specifier 47 MEDIA_SPECIFIER
1-219
Initial Prompt 48 MEDIA_SPECIFIER 1-219
Invalid Entry Prompt 49 MEDIA_SPECIFIER 1-219
Timeout Prompt 50 MEDIA_SPECIFIER 1-219
CustomerID 51 STRING(255) 0-255
Application media library 52 STRING(255) 0-255
System media library 53 STRING(255) 0-255
Page 15
Message Element Name Tag Data Type Valid Lengths

Locale 54 STRING(10) 0-10
Media-server set 55 STRING(255) 0-255
Microapp Error Text 56 STRING(255) 0-255
ASR Grammar 57 STRING(40) 0-40
Currency 58 STRING(10) 0-10
Table 11. Message Element Names and Types
Page 16
5. Expanded Call Context

As of ICM Version 4.1 the ICM is capable of associating named scalar and array variables with each call. The
VRU can take advantage of this new feature by registering interest in these Expanded Call Context variables by
name. All user-defined ECC variable names must start with the lower-case prefix “user”.
5.1 Registering Interest in Variables

After opening a session and before using any Expanded Call Context (ECC) variables the VRU must send a
RegisterVariables message to the ICM. The Register Variables message contains a flag of each of the ten
standard call variables and an optional list of ECC variable names for variables it is interested in.
The flags allow the VRU to select which call variables (CallVariable1 through CallVariable10) it wishes to
receive from the ICM. In the absence of a RegisterVariables message, the VRU is assumed to have interest in all
10 standard call variables. The VRU may send a new value for any standard call variable in any message that
includes them. The flags only control the sending of call variable values from the ICM to the VRU.
Each ECC variable name has a unique associated tag value, chosen by the VRU, which will be used to identify
the variable in all subsequent messages. If the VRU attempts to register a variable name that is not configured
in the ICM, the attempt will have no effect. Multiple RegisterVariables messages are allowed, but the VRU
should take care not to duplicate individual variable registrations. Specifically, each ECC Variable Name and
each ECC Variable Tag should only be registered once per session.
Fixed Part
MessageHeader Standard message header. MessageType = 49 MHDR 8
CallVarsMask Flags for the standard call variables: USHORT 2
Call Variable 1 = 0x0001
Floating Part
Field Name Value Data Type Max. Size
Variable The tag and name of a call variable to register to ExpCallVarName 36
receive
… … … …
Variable The tag and name of a call variable to register to ExpCallVarName 36
receive
Table 12. REGISTER_VARIABLES Message Format
For example, suppose the VRU wishes to register interest in Call Variables 1 through 5, one 25-byte scalar ECC
variable named “userECC_Scalar”, and a 10-element 42-byte wide array ECC variable named “userECC_Array”.
It would send a RegisterVariables message containing the following fields:
Page 17
Length
Field Name Value
(bytes)
Fixed Part:
Message Header:
Message Length: 43 4
Message Type: 49 4 (REGISTER_VARIABLES)
CallVarsMask: 0x001F 4 (Variables 1 through 5)
Floating Part:
Msg Element Tag: 42 1 (ECC Variable)
Msg Element Length: 18 1
Msg Element Payload:
ECC Tag: 200 4
ECC Name: userECC_Scalar 14
Msg Element Tag: 42 1 (ECC Variable)

Msg ElementLength: 17 1
Msg Element Payload:
ECC Tag: 201 4
ECC Name: userECC_Array 13
This example shows how to register interest in a subset of the ten standard Call Variables, as well as in a scalar
and an array ECC variable. It illustrates several significant points:
• The CallVarsMask is a bit map, with the least significant bit referring to Call Variable 1.
• The Msg Element Length in each ECC Variable element indicates the number of bytes in the payload,
not the number of bytes in the entire message element.
• The ECC Tags are assigned by the VRU via this RegisterVariables message. The VRU may use any
numbering scheme it wishes, as long as each ECC variable has its own unique ECC Tag within the
scope of this VRU.
• Customer-defined ECC Names must begin with “user”. There is also a small number of ICM-predefined
ECC variables (whose names do not begin with “user”). The VRU may register interest in those
variables, but they are not usually relevant to VRU’s.
• The ECC Names must correspond to ECC variables which have already been configured in the ICM.
However, this RegisterVariables message represents the last time (in the current session) that the VRU
refers to these variables by name. All subsequent references use the ECC Tags instead.
• The RegisterVariables message contains no reference to the size of an ECC Array variable. That size
must be configured properly in the ICM, and the VRU must not reference array elements outside those
boundaries, but the size itself is not transmitted here.
5.2 Sending and Receiving ECC Variables

Messages to and from the VRU that allow for the standard call variable message elements (CallVariable1
through CallVariable10) may now also include any number of ExpCallVarValue and ExpCallVarArray message
elements for registered ECC variables.
Messages from the ICM to the VRU will include an ExpCallVarValue element for each VRU-registered variable
name that matches an ICM ECC scalar variable that has a value and an ExpCallVarArray element values for each
VRU-registered variable name that matches an ICM ECC array variable element that has a value.
Page 18
Messages from the VRU may contain new scalar or array element values for any VRU-registered ECC variable
names. Any attempt to use a scalar value on an array variable or an array value on a scalar variable will result in
the closing of the session.
Messages that contain a section for ECC variables must always include all registered ECC variables that have a
non-empty value. Omitting a registered ECC variable has the effect of setting its value to an empty string.
5.3 Special ECC Message Elements
5.3.1 ExpCallVarName Message Element

This message element contains a UINT tag and a STRING name. The VRU uses this element to associate a tag
number with an ECC variable. The tag number will identify the ECC variable in values passed to or from the
VRU.
5.3.2 ExpCallVarValue Message Element

This message element contains a UINT tag and a STRING value. The UINT tag references a particular ECC
scalar variable whose contents is to be set. The STRING value provides the new value of the scalar variable.
5.3.3 ExpCallVarArray Message Element

This message element contains a UINT tag, a UCHAR array index and a STRING value. The UINT tag
references a particular ECC array variable and the UCHAR array index specifies which array element is to be set.
The STRING value provides the new value of the array element.
5.4 ECC Variable Size Limitations

In addition to the maximum length limitation of 210 for each ECC scalar variable and each element of an ECC
array variable there is a strict limit on the total number and size of ECC variables that can be defined and enabled
for a particular ICM, NAM or CICM. Each ECC scalar variable is defined with a specific maximum length and
each ECC array variable is defined with a specific maximum number of elements and a specific maximum element
length. The total maximum size of all defined and enabled variables along with their overhead requirements
must total 2000 bytes or less. The overhead for an ECC scalar variable is five (5) bytes and the overhead for an
ECC array variable is five (5) bytes for the array plus one (1) byte for each array element.
For example: A scalar of 40 bytes will take up 45 bytes (40 + 5). An array of ten elements of 40 bytes each will
take up 415 bytes (10*40 + 5 + 10*1).
The protocol user should rely as little as possible on particular ECC variables being defined and enabled. The
2000 byte limit applies across all uses of ECC anywhere within the ICM environment and the end user should be
given as much leeway as possible when deciding how to allocate those 2000 bytes.
6. Failure Indication Messages

The VRU may indicate errors to the Peripheral Gateway using the FAILURE_CONF and FAILURE_EVENT
messages.
Page 19
The VRU may use the FAILURE_CONF message in response to any request message from the Peripheral
Gateway. The VRU sends the FAILURE_CONF message in lieu of the positive confirmation message specific to
the request. The format of the FAILURE_CONF message is defined in Table 13.
MessageHeader Standard message header. MessageType = 1. MHDR 8
InvokeID Set to the same value as the InvokeID from the UINT 4
corresponding request message.
Status A status code indicating the cause of the failure. The UINT 4
possible status codes are defined in Table 92.
Table 13. FAILURE_CONF Message Format
The VRU may use the FAILURE_EVENT message to asynchronously indicate a failure or error condition to the
Peripheral Gateway. The format of the FAILURE_EVENT message is defined in Table 14.
Status A status code indicating the nature of the failure. UINT 4
Table 14. FAILURE_EVENT Message Format
7. Communications Interfaces
7.1 Physical Connection

The physical network used between the VRU and the Peripheral Gateway is 10 Base-T Ethernet. The Ethernet
interface used for communication with the ICM may be used for other purposes; a dedicated interface is not
required.
In simplex configurations, there is one Peripheral Gateway on the local network with the VRU. In duplex
configurations, two Peripheral Gateways are present. There may be other equipment (e.g. ACD’s) on the
network as well. Figure 1 shows a typical duplex configuration.
10 Base-T
Ethernet Hub
PG A VRU PG B ACD
Figure 1. Typical configuration with duplexed PG’s.
Page 20
7.2 Transport Services

TCP/IP transport services are used in ICM / VRU communications.
The TCP “linger” option must be enabled and set to zero, so that TCP connections are closed immediately upon
request without waiting for previously transmitted data to be acknowledged. This ensures that communications
can be re-established quickly after a failure.
If possible, the Nagle transmit delay algorithm of TCP should be disabled to ensure timely delivery of all data.
(Disabling the Nagle algorithm is sometimes referred to as the TCP_NODELAY option.) Disabling this
algorithm ensures that messages are always transmitted immediately upon request.
7.3 Connection Management and Duplexed VRU PG’s

Duplexed Peripheral Gateways are transparent to the VRU. The Peripheral Gateways are configured with the IP
address of the VRU and the TCP port number corresponding to the VRU’s ICM service. One of the Peripheral
Gateways attempts to connect to the VRU; the other is quiescent. Once a connection between the Peripheral
Gateway and the VRU has been established, the connection remains in place until a failure occurs.
In duplexed configurations, most types of single point failure, either within the PG or between the PG and other
ICM components, are handled automatically by the ICM’s built-in fault tolerance mechanisms. When such a
recoverable failure occurs, the VRU will not even be aware of the event, and can continue processing calls
without interruption or degradation.
If the Peripheral Gateway component which handles socket communication with the VRU fails, or if there is a
network failure between it and the VRU, then the VRU will lose its socket connection. Such connection failures
may be detected by the TCP layer or by the heartbeat mechanism described below. Should a failure occur, the
active Peripheral Gateway may try to reconnect, or the quiescent Peripheral Gateway may become active and
attempt to connect to the VRU. It will make repeated attempts to connect to the VRU until it succeeds. The
interval between connection attempts is 10 seconds by default, and is configurable. The VRU does not need
any special awareness of duplexed Peripheral Gateways; it simply accepts one connection at a time from
whichever Peripheral Gateway is active. In certain failure scenarios, the VRU may actually see a new connection
request while a previously established connection still exists. In this case, the VRU should terminate the
previously established connection by closing the TCP/IP socket, and accept the new connection request.
No matter how a new connection is established, however, the Peripheral Gateway will always initialize a new
communication session by sending an OPEN_REQ message to the VRU, as described below. When this
happens, the VRU cannot assume that any calls currently in progress are known to the VRU PIM. Therefore the
VRU should perform default call handling functions on any existing calls, allowing them to terminate without
further interaction with the ICM. New calls may be handled normally.
7.4 Session Initialization

Once a TCP connection has been established, the Peripheral Gateway attempts to initialize a communications
session by sending an OPEN_REQ message to the VRU. The OPEN_REQ message will specify the protocol
version number to be used for the session.
The VersionNumber field’s initial contents depend on the ICM release, as follows:
• ICM releases prior to 3.0: VersionNumber 1
• ICM releases 3.0 and 4.0: VersionNumber 2
• ICM release 4.1 to 4.1.2: VersionNumber 3
• ICM release 4.1.3 to 4.1.5: VersionNumber 4
• ICM release 5.0: VersionNumber 5
Page 21
If E_INVALID_VERSION is returned by the VRU, the PG will try progressively lower version numbers until one
is successful. The VRU responds with an OPEN_CONF message to confirm the successful establishment of a
session. Figure 2 depicts the message flow.
PG VRU
OPEN_REQ
OPEN_CONF
Figure 2. Session Initialization Message Flow
Table 15 defines the OPEN_REQ message.

InvokeID An ID for this request message that will be returned in the UINT 4
corresponding OPEN_CONF message.
VersionNumber The version number of the interface requested by the UINT 4
Peripheral Gateway. This defines the version of all
messages in the message set. (Initially 6 ).
IdleTimeout The session idle time expressed in milliseconds. If the UINT 4
session is idle (no messages received) for this length of
time, the VRU should reset the TCP connection and await
the establishment of a new session.
Table 15. OPEN_REQ Message Format
Page 22
Table 16 defines the OPEN_CONF message.

corresponding OPEN_REQ message.
UseEventFeed If set to TRUE, indicates that the VRU supports the Event BOOL 4
Data Feed (see section 8.2).
UsePolledFeed If set to TRUE, indicates that the VRU supports the Polled BOOL 4
Data Feed.
This setting is no longer supported as of ICM Release 5.0.
UseCallRouting If set to TRUE, indicates that the VRU supports the Call BOOL 4
Routing Interface (see section 8.3).
UseTimeSynch If set to TRUE, indicates that the VRU supports the Time BOOL 4
Synchronization Interface (see section 8.4).
UseServiceControl If set to TRUE, indicates that the VRU supports the BOOL 4
Service Control Interface (see section 8.5).
Note: Requires Protocol Version 2 or later.
Table 16. OPEN_CONF Message Format
If for any reason the VRU determines that a new session should not be opened, it responds to the OPEN_REQ
message with a FAILURE_CONF message.
In duplex configurations, it is possible for one Peripheral Gateway to attempt to open a session while the other
Peripheral Gateway has a session established. When this occurs, the VRU should immediately terminate the
existing session by closing the TCP/IP socket and process the newly received open request.
The VRU PG will initially set the OPEN_REQ VersionNumber to a value of 6 for ICM releases 5.0 and beyond.
If the VRU rejects an OPEN_REQ message with E_INVALID_VERSION, the Peripheral Gateway will retry with 4,
3, 2 and 1 successively. In all other cases of session rejection, the Peripheral Gateway resets the TCP
connection and may retry after a delay period.
The Peripheral Gateway treats a lack of response to the OPEN_REQ message within 5 seconds as a failure to
open the session.
7.5 Session Maintenance

To detect communication and certain application failures, the Peripheral Gateway sends a HEARTBEAT_REQ
message to the VRU periodically. The heartbeat interval is configured on the Peripheral Gateway, and will
typically be on the order of 5 seconds. Upon receipt of a HEARTBEAT_REQ message, the VRU should
immediately respond with a HEARTBEAT_CONF message. If three heartbeats go unconfirmed, the Peripheral
Gateway declares a session failure and resets the TCP connection.
Figure 3 depicts the heartbeat message flow. Table 17 defines the HEARTBEAT_REQ message and Table 18
defines the HEARTBEAT_CONF message.
The VRU does not initiate HEARTBEAT_REQ messages. Failure detection on the VRU is accomplished using
the IdleTimeout value from the OPEN_REQ message. The Peripheral Gateway sets this value to four times the
heartbeat interval. If the VRU does not receive a HEARTBEAT_REQ messages for this period of time, the VRU
declares a session failure and resets the TCP connection.
Page 23
The VRU may respond to a HEARTBEAT_REQ message with a FAILURE_CONF message with status code
E_VRU_OFFLINE. This indicates to the Peripheral Gateway that the VRU is off-line, and causes the Peripheral
Gateway to reset the TCP connection.
PG VRU
HEARTBEAT_REQ
Heartbeat
Interval
HEARTBEAT_CONF
HEARTBEAT_REQ
HEARTBEAT_CONF
Figure 3. Heartbeat Message Flow

corresponding confirm message.
Table 17. HEARTBEAT_REQ Message Format

corresponding HEARTBEAT_REQ message.
Table 18. HEARTBEAT_CONF Message Format
Page 24
7.6 Session Termination

The Peripheral Gateway may initiate the graceful termination of a communication session. The Peripheral
Gateway sends a CLOSE_REQ message; the VRU responds with a CLOSE_CONF message. Upon receipt of the
CLOSE_CONF message, the Peripheral Gateway resets the TCP connection. The Peripheral Gateway waits up
to 5 seconds for the CLOSE_CONF message before resetting the connection.
The VRU may indicate to the Peripheral Gateway that it no longer wishes to communicate by sending an
unsolicited FAILURE_EVENT message with the Status field set to E_VRU_OFFLINE. Upon receipt of this
message, the Peripheral Gateway will send a CLOSE_REQ message to the VRU to initiate the session close
procedure if a session was active. If a session was not active at the time the FAILURE_EVENT was received,
the socket will simply be closed.
The Peripheral Gateway includes a status code in the CLOSE_REQ message indicating the reason for closing
the session. This status code will be E_NO_ERROR if the VRU requested that the session be terminated,
E_PG_OFFLINE if the Peripheral Gateway is no longer online, or E_TIMEOUT if the VRU does not respond to a
request message within the time-out period.
Figure 4 depicts the session termination message flow. The CLOSE_REQ and CLOSE_CONF messages are
defined in Table 19 and Table 20.
PG VRU
PG
Closing CLOSE_REQ
CLOSE_CONF
-- OR --
VRU
FAILURE_EVENT
(E_VRU_OFFLINE)
Closing
If a
Session is
CLOSE_REQ
Active
CLOSE_CONF
Figure 4. Session Termination Message Flow
Page 25
Fixed Part
corresponding confirm message.
Status A status code indicating the reason for closing the UINT 4
session.
Floating Part
Text (optional) A text message explaining why the session is being STRING 255
closed.
Table 19. CLOSE_REQ Message Format

corresponding CLOSE_REQ message.
Table 20. CLOSE_CONF Message Format
8. Application Level Interfaces

The protocol supports four distinct application level interfaces between the VRU and the Peripheral Gateway, as
listed below. The VRU specifies in its OPEN_CONF message to the PG which interfaces it plans to use in a
given session.
1. Event Data Feed
2. Call Routing Interface
3. Time Synchronization Interface
4. Service Control Interface
The first two of these, the Event Data Feed and the Call Routing Interface, are usually used together. The Event
Data Feed provides means for the VRU to convey status information to the ICM for call routing and monitoring
purposes. The Event Data Feed is described in section 8.2.
The second application level interface is the Call Routing Interface. The VRU uses this interface to request
routing instructions for calls that need to be transferred. This interface is described in section 8.3.
The third application level interface is the Time Synchronization Interface. The VRU can use this interface to
synchronize the VRU clock with the ICM clock to ensure that times are reported consistently. It may be used
together with any of the other interfaces. The Time Synchronization Interface is described in section 8.4.
The fourth application level interface is the Service Control Interface. This interface is used to allow the ICM
Router to provide call-handling instructions to a VRU, rather than vice versa. This interface is described in
section 8.5.
Page 26
The various application-level interfaces that transmit call variables to or from the VRU have been extended to
support the Expanded Call Context feature of ICM V4.1. See section 5 for a description of how to work with
Expanded Call Context variables.
8.1 Application Level Initialization

In cases where the ICM Router will route calls to a VRU based on trunk utilization, or calls in progress for a
given service it is important for the ICM Router to know the current state of all trunks and services on the VRU.
The Event Data Feed and Service Control Interface each allows the ICM Router to track state changes in real
time through asynchronous events from the VRU. The initialization process allows the VRU to specify a current
state to which the state change events can be applied. If the VRU provides complete initialization the ICM
Router can exactly track the state of the VRU.
In cases where calls will not be routed to the VRU directly for a given Service or Trunk Group, it is acceptable
for the VRU to provide only partial initialization or no initialization. In cases where the complete initial state was
not provided by the VRU, the ICM will learn the state of the VRU. The learning process will complete when all
calls in progress at initialization time have terminated, and all trunks within uninitialized trunk groups have been
used following the initialization process. The learning process may take several minutes depending on call load,
the VRU applications, the number of trunks within a trunk group, and the average call handle time for calls
within a given VRU application. Partial initialization should ONLY be used for Trunk Groups and Services that
the ICM Router does not route to in real-time since at start-up the data will be inaccurate during the learning
process.
Initialization begins with a request from the PG to the VRU. The form of message used will depend on which
application-level interfaces are enabled in the OPEN_CONF message from the VRU (See 7.4 above).
Interfaces Enabled
in OPEN_CONF
Service Event
Control Data Request From PG Response from VRU
Interface Feed
No No None None
No Yes INIT_DATA_REQ INIT_DATA_CONF
INIT_TRKGRP_DATA_EVENT*
INIT_SERVICE_DATA_EVENT*
INIT_VRU_DATA_EVENT
INIT_DATA_END_EVENT
Yes Don't INIT_SERVICE_CTRL_REQ INIT_SERVICE_CTRL_CONF
care. INIT_SERVICE_CTRL_TRKGRP*
INIT_SERVICE_CTRL_SERVICE*
INIT_SERVICE_CTRL_VRU**
INIT_SERVICE_CTRL_DATA
INIT_SERVICE_CTRL_END
* Zero or more occurrences ** At most one occurrence
Table 21: Application Interface Initialization
8.2 Event Data Feed

The Event Data Feed provides a means for the VRU to convey current status information to the ICM in real time
on an event by event basis. The information provided by the events is used to populate ICM Real-time
database elements that can then be accessed by Monitor ICM reports. There are two parts to the Event Data
Feed: initialization and unsolicited events.
Page 27
This interface has been extended to support the Expanded Call Context feature of ICM V4.1. See section 5 for a
description of how to work with Expanded Call Context variables.
8.2.1 Data Initialization

Before it can accept any unsolicited events from the VRU, the Peripheral Gateway must first obtain an initial
snapshot of the VRU’s status. If the Service Control Interface is enabled in the OPEN_CONF message from the
VRU, the initialization is done through the Service Control Interface (See 8.5.1). If the Service Control Interface
is NOT enabled, initialization proceeds as follows: The Peripheral Gateway sends an INIT_DATA_REQ
message to the VRU. The VRU responds by sending an INIT_DATA_CONF message to indicate that it is
prepared to send the initial data. The VRU may then optionally send one INIT_TRKGRP_DATA_EVENT
message for every configured trunk group, and one INIT_SERVICE_DATA_EVENT message for every
configured service. If these messages are omitted for a given Trunk Group or Service configured in the ICM
Database, default values will be assumed. In either partial or complete initialization cases, a single
INIT_VRU_DATA_EVENT message must be sent. When all initialization data has been transmitted, the VRU
sends an INIT_DATA_END_EVENT message to indicate that data initialization is complete.
PG VRU
Events
Included
INIT_DATA_REQ in
Initial
State
Snapshot
INIT_DATA_CONF
INIT_TRKGRP_DATA_EVENT
Optional
Initialization
Messages { INIT_SERVICE_DATA_EVEN
T
INIT_VRU_DATA_EVEN
Events
not
included
in
Initial
State
INIT_DATA_END_EVEN
T
First
Unsolicited
Event
Figure 5. Data Initialization Message Flow

The INIT_TRKGRP_DATA_EVENT, INIT_SERVICE_DATA_EVENT, and INIT_VRU_DATA_EVENT
messages represent a consistent snapshot of the VRU’s state at a given point in time. Events that occur at the
VRU prior to the snapshot are incorporated into the snapshot; events that occur after the snapshot are
transmitted to the Peripheral Gateway individually in unsolicited event messages. The VRU may not transmit
unsolicited events until the transmission of the initial state is complete (INIT_DATA_END_EVENT). For the
Page 28
Peripheral Gateway to maintain an accurate model of the VRU’s call processing state, the VRU must transmit all
events that occur after the initial snapshot has been taken, even those that occur before the initial snapshot has
been transmitted completely.
The VRU may respond to the INIT_DATA_REQ message with a FAILURE_CONF message, setting the status
code to one of the following values:
• E_VRU_OFFLINE, if the VRU is off-line. The Peripheral Gateway closes the session with the VRU when it
receives this response.
• E_REQUEST_REFUSED, if the VRU is not ready to initialize. The Peripheral Gateway retries the
initialization request after a delay period.
• E_EVENTS_NOT_SUPPORTED, if the VRU does not support the Event Data Feed interface.
Figure 5. Data Initialization Message Flow depicts the data initialization message flow. Table 22 through Table
27 describe the data initialization messages.

corresponding response messages.
Table 22. INIT_DATA_REQ Message Format

InvokeID Set to the same value as the InvokeID of the UINT 4
corresponding INIT_DATA_REQ message.
Table 23. INIT_DATA_CONF Message Format
Page 29

TrunkGroupID An ID assigned by the VRU to this trunk group, UINT 4
in the range 0 to 65535.
TrunkCount The number of trunks, t, configured in this UINT 4
message. TrunkCount may not exceed 1024
because the total number of trunks in a trunk
group may not exceed 1024.
CallsInToday The cumulative number of inbound calls that UINT 4
have arrived on the trunk group this day. See
text.
CallsOutToday The cumulative number of outbound calls that UINT 4
have been placed on the trunk group this day.
See text.
InServiceTimeToday The cumulative amount of time, expressed in UINT 4
seconds, that trunks in the trunk group have
been in service this day. See text.
InUseInboundTimeToday The cumulative amount of time, expressed in UINT 4
been in use on incoming calls this day. See text.
InUseOutboundTimeToday The cumulative amount of time, expressed in UINT 4
been in use on outgoing calls this day. See text.
AllTrunksInUseTimeToday The cumulative amount of time, expressed in UINT 4
seconds, that all trunks in the trunk group were
simultaneously busy this day. See text.
TrunkNumber1 The trunk number of the first trunk. USHORT 2
TrunkStatus1 The current status of the first trunk in the trunk USHORT 2
group. (See Table 28 for status definitions)
... ... ... ...
TrunkNumbert The trunk number of the last trunk. No trunk USHORT 2
group may contain more than 1024 trunks.
TrunkStatust The current status of the last trunk in the trunk USHORT 2
group.
Table 24. INIT_TRKGRP_DATA_EVENT Message Format
Page 30

ServiceID An ID assigned by the VRU to this service. UINT 4
AvailableNow A flag indicating the current availability of the BOOL 4
service.
CallsInNow The number of inbound calls currently in progress on UINT 4
the service.
CallsOutNow The number of outbound calls currently in progress UINT 4
on the service.
CallsInToday The cumulative number of inbound calls on the UINT 4
service this day. See text .
CallsOutToday The cumulative number of outbound calls on the UINT 4
service this day. See text.
CallsHandledToday The cumulative number of calls handled on the UINT 4
service this day. See text.
HandleTimeToday The cumulative amount of time, expressed in UINT 4
seconds, spent handling calls on the service this day.
See text.
DivertedInToday The cumulative number of calls diverted from another UINT 4
service to this service this day. See text.
DivertedOutToday The cumulative number of calls diverted from this UINT 4
service to another service this day. See text.
Table 25. INIT_SERVICE_DATA_EVENT Message Format
Page 31

TimeZoneDelta The current local time zone delta, expressed in seconds. INT 4
This value is added to a UTC time to form a time in the
local time zone.
OperationalStatus The operational status of the VRU. UINT 4
0: Normal Operation
1-31: Loss of redundant component or other transparent
failure; still fully functional for call processing
32-63: Degraded call processing
64-127: Conditions prevent call processing
StatusVariable1 VRU-specific status information INT 4
... ... ... ...
Table 26. INIT_VRU_DATA_EVENT Message Format

InitDataTime The UTC time at which the initial snapshot was taken. TIME 4
StartOfDay The UTC time at which the ...Today values were last reset TIME 4
to zero. Ordinarily, this will correspond to midnight local
time at the VRU. However, this may refer to a different
time if the VRU has restarted. See text.
Table 27. INIT_DATA_END_EVENT Message Format
Symbol Meaning Value

TRUNK_OUT_OF_SERVICE The trunk is not available for either incoming or 1
outgoing calls.
TRUNK_IN_USE_INBOUND The trunk is in use on an inbound call. 2
TRUNK_IN_USE_OUTBOUND The trunk is in use on an outbound call. 3
TRUNK_IDLE The trunk is not in use. 4
Table 28. Trunk Status Definitions
Page 32
Implementation Note: The INIT_TRKGRP_DATA_EVENT and INIT_SERVICE_DATA_EVENT messages

contain some fields which are cumulative counters for the current day (...Today fields). These fields are not
used by the ICM. The VRU may supply correct values for these fields, or may simply set these fields to
NULL_DATA_ELEMENT.
Implementation Note: The StartOfDay field in the INIT_DATA_END_EVENT message is not used by the ICM.
The VRU may supply the correct value for this field, or may simply set the field to NULL_DATA_ELEMENT.
Implementation Note: As of ICM Release 3.0, INIT_TRKGRP_DATA_EVENT and
INIT_SERVICE_DATA_EVENT are now optional messages during the initialization process. Earlier releases of
the VRU Interface required that all Trunk Groups and Services configured in the ICM database be initialized
during the Event Data Feed Initialization sequence. Note that INIT_TRKGRP_DATA_EVENT and
INIT_SERVICE_DATA_EVENT messages should be sent for those Trunk Groups and Services that the ICM
Router targets calls using real-time data. Failure to fully initialize Trunk Groups and Services targeted by the
ICM may lead to erratic route selection immediately following startup or a restart.
8.2.2 Event Data Feed Database Reporting

The Event Data Feed Interface will report termination call detail records, service, trunk group, and peripheral
real-time records. The VRU PG will derive the real-time statistics from the Event Data Feed Interface messages
exchanged with a given VRU. Initial baseline values may be supplied by the VRU during the Event Data Feed
Interface Initialization by sending the optional initialization messages. If the optional baseline information is not
supplied, all call related real-time in-progress counters are initialized to zero. Statistics derived from the Event
Data Feed Interface will appear in the following database elements: Termination_Call_Detail,
Service_Real_Time, Peripheral_Real_Time and TrunkGroup_Real_Time records. The real-time records are
accumulated to derive the five-minute1 and half-hour database records. For a description of the individual
database elements, refer to the Cisco ICM Software Database Schema Handbook.
8.2.2.1 Termination Call Detail

Termination Call Detail records are written for each call delivered to a given VRU via the Event Data Feed
Interface. These records exist in the ICM instance to which the VRU PG is connected. As the name implies,
termination call detail records are written upon termination of a given call. Calls may be terminated by the VRU
by sending a CALL_CEARED_EVENT message, or by sending a NEW_TRANSACTION_EVENT message.
The NEW_TRANSACTION_EVENT message causes the original call to terminate while at the same time
creating a new call that is assigned the same call resources (trunk, etc.). The NEW_TRANSACTION_EVENT
message may be used by the VRU implementation to force Termination Call Detail records to be written to the
ICM database.
Termination Call Detail fields include a variety of call state times, dialed number, ANI, call disposition, as well as
the ten peripheral variables that may be set by the VRU. The Termination Call Detail fields may be divided into
two groups: time values and data values. Time values are calculated based on the elapsed time between Event
Interface messages. Data values are either taken directly from VRU Event Data Feed Interface messages, or
calculated based on data received in Event Interface messages. In addition to time values, there are a number of
data values present in a Termination Call Detail record. The table shown below (Table 29) defines the fields that
will be populated by a VRU PG when implementing the Event Data Feed Interface. For a description of the
individual database elements, refer to the Cisco ICM Software Database Schema Handbook.
In the example illustrated below, a call is initially delivered to Service 1 and re-targeted to Service 2 by the VRU
using a DIVERTED_EVENT message. Note that the call is re-targeted prior to the
NEW_TRANSACTION_EVENT message that causes the first termination record to be written. As, a result, the
first termination record will contain a service mapping of 2 and a reference service 1 will not exist. The
1
Note: Reporting of five-minute records is suppressed by default.
Page 33
NEW_TRANSACTION_EVENT message not only writes the first termination record, it also re-assigns to the
call to Service 3 which will appear in the second termination record when the call is cleared.
VRU
VRU PG
DELIVERED_EVENT
(Service 1)
SET_CALL_VARIABLES_EVENT
Duration/
TalkTime DIVERTED_EVENT
(Service 2)
Termination Call Detail NEW_TRANSACTION_EVENT

Record 1 (Service 3)
Duration/
TalkTime
Termination Call Detail CALL_CLEARED_EVENT

Record 2
Figure 6: Termination Call Detail Record Example
Page 34
Field Name Data Source

DigitsDialed VRU in ORIGINATED_EVENT message.
PeripheralCallKey Provided by VRU in DELIVERED_EVENT message as CallID.
CallDisposition Provided by VRU in CALL_CLEARED_EVENT message as
clearing code.
Variable1 through Variable10 Provided by VRU in SET_CALL_VARIABLES_EVENT message
or ROUTE_REQUEST_EVENT message if Call Routing Interface
is in use.
UserToUser Provided by VRU in DELIVERED_EVENT message.
NewTransaction Set if VRU created call via NEW_TRANSACTION_EVENT
message.
TimeZone Provided by VRU in INIT_VRU_DATA_EVENT message
TrunkGroupID Provided by VRU in DELIVERED_EVENT message.
DNIS Provided by VRU in DELIVERED_EVENT message.
ANI Provided by VRU in DELIVERED_EVENT message or
ROUTE_REQUEST_EVENT message if Call Routing Interface is
in use.
Trunk Provided by VRU in DELIVED_EVENT message.
Table 29: Termination Call Detail Support
8.2.2.2 Service Real-time

The ICM will write Service Real-time records based on the information provided by the VRU via Event Data
Feed Interface messages. During Event Data Feed Interface Initialization, the status and calls in progress count
of each Service resident on a given VRU may optionally be sent by the VRU via an
INIT_SERVICE_DATA_EVENT message. As calls arrive, are redirected to other services on the VRU, or
terminate, the service statistics for each service a call passes through will be updated.
Failure to provide initialization data will result in the service being marked as AVAILABLE and the calls in
progress count being set to zero. This may cause certain ICM Routing Scripts that make routing decisions
based on the zero calls in progress counts at PG startup to route calls to a less desirable VRU until such time
that the counters reach steady state values.
Refer to the Cisco ICM Software Database Schema Handbook for additional details on the Service Real-time
records.
8.2.2.3 Peripheral Real-time

The VRU may provide Peripheral Real-time updates periodically by sending VRU_STATUS_EVENT messages
to the VRU PG. The VRU_STATUS_EVENT message is used to communicate a change in the operational
status of a VRU that may affect the ability of the VRU to properly handle calls. The VRU_STATUS_EVENT
message also contains the VRU time of day and time zone that is used to synchronize the VRU PG clock to that
of the VRU, as well as, sixteen status variables. In order to ensure proper clock synchronization between the
VRU and the VRU PG, it is suggested that that VRU send a VRU_STATUS_EVENT message each time the clock
on the VRU crosses a minute boundary (ex. 12:01:00, 12:02:00…).
The status variables may be used to pass additional VRU status information to the ICM to be used in routing
decisions. The use and definition of the status variables is left up to the implementation of the particular VRU
Page 35
platform. The status variables may be tested in ICM Routing Scripts to make routing decisions. The VRU PG
keeps a snapshot of the current Peripheral Real-time record that is updated upon receipt of a VRU Status
message. Periodically, the VRU PG will forward a Peripheral Real-time update to the ICM Router thereby
causing an ICM database record to be written. The table shown below lists each on the Peripheral Real-time
fields and the source of the data.
Status Provided by VRU in VRU_STATUS_EVENT message.
PeripheralData1 Provided by VRU in VRU_STATUS_EVENT message.
through
PeripheralData16
Table 30: Peripheral Real-time Support
8.2.2.4 Trunk Group Real-time

The ICM will write Trunk Group Real-time records based on the information provided by the VRU via the Event
Data Feed Interface. During Event Data Feed Interface Initialization, the status of each trunk within a trunk
group may optionally be sent by the VRU via an INIT_TRKGRP_DATA_EVENT message. Following the Event
Data Feed Interface initialization sequence, the VRU and PIM will be synchronized in respect to trunk states.
As calls arrive and terminate at the VRU, the trunk states will be updated and new real-time vales calculated by
the VRU PG.
Failure to provide trunk initialization data will result in all trunk counts being zeroed for the trunk groups
configured in the ICM database. This may cause ICM Routing Scripts that make routing decisions based on
real-time trunk group availability or utilization to behave strangely.
Each initialized trunk will be added to the total trunk count for the given trunk group. The trunk states will be
used to calculate the number of in use inbound, in use outbound, out of service, and idle trunks. Periodically
the VRU PG will send updates to the ICM Router containing the latest calculated trunk group real-time values.
Refer to the Cisco ICM Software Database Schema Handbook for additional details on Trunk Group Real-time
records.
8.2.3 Unsolicited Events

As the VRU processes calls, it undergoes changes in its call processing state. The VRU informs the ICM about
each significant state change by sending an unsolicited event message to the Peripheral Gateway as it occurs.
There are no request or confirmation messages associated with unsolicited events.
8.2.3.1 Delivered Event

The arrival of a new inbound call at the VRU generates a DELIVERED_EVENT message (as defined in Table 31)
to the Peripheral Gateway. If the Call Routing interface is to be used with this call, the DELIVERED_EVENT
message must arrive before the first ROUTE_SELECT message for the call.
The floating part of the message consists of the fields ANI, and UserToUserInfo, which are optional, and DNIS
which is strongly recommended for Translation Routed calls but is otherwise optional.
The VRU normally fills in the ServiceID element of the DELIVERED_EVENT message with the ID of the service
to which the call is attributed. It may, however, set the ServiceID element to the special value
NULL_SERVICE_ID. When this occurs, the ICM uses the DNIS value supplied to derive the service
attribution.
Page 36
The DELIVERED_EVENT and ORIGINATE_EVENT messages announce the beginning of an incoming or

outgoing call at this VRU, respectively. These messages assign a CallID to the call. If the VRU re-uses the
CallID from a prior call which has not been cleared, then the VRU PG assumes this is a continuation of the
existing call. The old call’s entire call context, including its call variables, will be available to the new call, and
when the new call is cleared, only a single Termination Call Detail record will be written. If this is not the
intended effect, then it is important for the VRU to send a CallClearedEvent with respect to the first call before
announcing the second call.
Fixed Part
CallID An ID assigned to the call by the VRU. UINT 4
TrunkGroupID The ID of the trunk group on which the call arrived, UINT 4
TrunkNumber The number of the trunk on which the call arrived. UINT 4
ServiceID The ID of the service to which this call is attributed. UINT 4
Floating Part
ANI (optional) The calling line ID of the caller. STRING 40
UserToUserInfo The ISDN user-to-user information element. UNSPEC 131
(optional)
DNIS (optional except The DNIS provided with the call. STRING 32
for Translation Routed
If this call is being Translation Routed, the DNIS
calls)
must be set and this message must be followed by a
ROUTE_REQUEST_EVENT that specifies the same
CallID and the DialedNumber
“TRANSLATION_ROUTE”.
Table 31. DELIVERED_EVENT Message Format
8.2.3.2 Originated Event

The initiation of a new outbound call from the VRU generates a ORIGINATED_EVENT message to the
Peripheral Gateway. This is described in Table 32.
The floating part of the message consists of the fields UserToUserInfo and DigitsDialed. Both of these fields
are optional.
The DELIVERED_EVENT and ORIGINATE_EVENT messages announce the beginning of an incoming or
outgoing call at this VRU, respectively. These messages assign a CallID to the call. If the VRU re-uses the
CallID from a prior call which has not been cleared, then the VRU PG assumes this is a continuation of the
existing call. The old call’s entire call context, including its call variables, will be available to the new call, and
when the new call is cleared, only a single Termination Call Detail record will be written. If this is not the
intended effect, then it is important for the VRU to send a CallClearedEvent with respect to the first call before
announcing the second call.
Page 37
Fixed Part
CallID An ID assigned to the call by the VRU. UINT 4
TrunkGroupID The ID of the trunk group on which the call was UINT 4
placed, in the range 0 to 65535.
TrunkNumber The number of the trunk on which the call was UINT 4
placed.
Floating Part
UserToUserInfo The ISDN user-to-user information element supplied UNSPEC 131
(optional) with the outbound call.
DigitsDialed (optional) The digits dialed to place the outbound call. STRING 40
Table 32. ORIGINATED_EVENT Message Format
Page 38
8.2.3.3 Call Cleared Event

The cessation of a call (either inbound or outbound) at the VRU generates a CALL_CLEARED_EVENT
message to the Peripheral Gateway. When a call clears, its CallID becomes invalid. In VRU Interface Version 2.0
or later, the CALL_CLEARED message may also optionally contain either the TrunkGroupID or the
TrunkNumber.
Implementation Note: The TrunkGroupID and TrunkNumber optional message elements have been added in an
effort to resolve an event feed start-up condition. Upon initialization, the VRU PG is informed of the number of
trunks in use for a given trunk group since there are likely to be calls in progress. As these calls terminate, call
cleared events are received by the VRU PG and an attempt is made to match the CallID to a call known by the
VRU PG in order to increment the available trunk count. However, a delivered event was not received for these
calls since the PG was not connected at the time the call originated and the VRU PG is therefore unable to match
the call to a known call. This leads to a condition where the available trunk counts may appear to be artificially
low. The condition will correct itself over time since the PG will see new calls delivered which will serve as
synchronization points for the trunks assigned to the calls. In order to eliminate this window, the
TrunkGroupID and TrunkNumber have been added as an option to the CALL_CLEARED message. Specifying
either value will allow the VRU PG to increment the available trunk count immediately thereby avoiding
artificially low counts. It is recommended that one of these fields be specified for all CALL_CLEARED events.
CallID The ID of the cleared call. UINT 4
Cause The reason for clearing the call. See Table 34. UINT 4
Floating Part
TrunkGroupID The ID of the trunk group on which the call was UINT 4
placed, in the range 0 to 65535. ( Note: Version 2.0 or
(optional)
later)
TrunkNumber The number of the trunk on which the call was UINT 4
placed. ( Note: Version 2.0 or later)
(optional)
Table 33. CALL_CLEARED_EVENT Message Format
Page 39
Cause Value Termination_Call_Detail Disposition TCD

Code
Normal 1 DBCD_DROP_HANDLED_PRIMARY_ROUTE 13
Completion
Call Abandoned 2 DBCD_ABAND_AGENT_TERMINAL 6
Call Transferred 3 DBCD_BLIND_TRANSFER 28
New 4 DBCD_DROP_HANDLED_PRIMARY_ROUTE 13
Transaction
Busy 5 DBCD_DROP_BUSY 11
No Answer 6 DBCD_DROP_NO_ANSWER 10
Maintenance 7 DBCD_TIME_OUT 22
Net Congestion 8 DBCD_FORCED_BUSY 9
Net Not 9 DBCD_INTERCEPT_REORDER 20
Obtainable
Reorder Tone 10 DBCD_DROP_REORDER 12
Resources Not 11 DBCD_INTERCEPT_DENIAL 21
Available
Trunks Busy 12 DBCD_FORCED_BUSY 9
Called Party 13 DBCD_CALLED_PARTY_DISCONNECTED 52
Disconnected
Table 34. Call Cleared Causes
Page 40
8.2.3.4 Conferenced Event

When the VRU tandem connects an incoming call with an outgoing call, it generates a CONFERENCED_EVENT
message to the Peripheral Gateway. This is described in Table 35.
The CONFERENCED_EVENT refers to the inbound call, identified by PrimaryCallID, the outbound call,
identified by SecondaryCallID, and the resultant conference call, identified by ConferenceCallID.
ConferenceCallID may specify a new call ID for the resulting conference call, or may specify that the resultant
conference call will use the call ID of the outbound call.
If ConferenceCallID specifies a new call ID, the CONFERENCED_EVENT marks the termination of the outbound
call identified by SecondaryCallID and the creation of a new call (the resultant conference call) identified by
ConferenceCallID. The new conference call is attributed to the service identified by ServiceID.
If ConferenceCallID and SecondaryCallID specify the same call, the CONFERENCED_EVENT does not mark the
termination of the outgoing call or the creation of a new conference call. Instead, the CONFERENCED_EVENT
marks the diversion of the outbound call, identified by SecondaryCallID, to the service specified by ServiceID.
The resultant conference call occupies two trunks, one for the incoming leg and one for the outgoing leg. Both
of these trunks are released when the conference call terminates.
The CONFERENCED_EVENT always marks the termination of the inbound call identified by PrimaryCallID.
ConferenceCallID An ID assigned to the resultant conference call by UINT 4
the VRU. This may be the same as the secondary
call ID.
PrimaryCallID The ID of the primary (inbound) call being UINT 4
conferenced.
SecondaryCallID The ID of the secondary (outbound) call being UINT 4
conferenced.
ServiceID The ID of the service to which the resultant UINT 4
conference call is attributed
Table 35. CONFERENCED_EVENT Message Format
8.2.3.5 Diverted Event

When the VRU diverts a call from one service to another, it generates a DIVERTED_EVENT message to the
Peripheral Gateway. This is described in Table 36. When a call is diverted, the call continues to exist, but is
attributed to the new service instead of the old.
CallID The ID of the diverted call. UINT 4
NewServiceID The ID of the new service to which the call was UINT 4
diverted.
Table 36. DIVERTED_EVENT Message Format
Page 41
8.2.3.6 New Transaction Event

The VRU may change an existing call into a new call using the NEW_TRANSACTION_EVENT message,
described in Table 37. This event marks the simultaneous end of one call and beginning of another. The same
trunk(s) that the old call occupied continue to be occupied by the new call.
CallID The ID of the existing call. UINT 4
NewCallID The ID of the new call. UINT 4
ServiceID The ID of the service to which the new call is UINT 4
attributed.
Table 37. NEW_TRANSACTION_EVENT Message Format
Page 42
8.2.3.7 Set Call Variables Event

The ICM maintains a set of 10 call variables for each call. Each variable is capable of storing a string of up to 40
bytes (STRING[40]). When a new call is established (via the DELIVERED_EVENT, ORIGINATED_EVENT,
CONFERENCED_EVENT, or NEW_TRANSACTION_EVENT messages), these variables are initialized to null
strings.
The VRU may set some or all of a call’s variables using the SET_CALL_VARIABLES_EVENT message and the
ROUTE_REQUEST_EVENT message. The ICM may also set a call’s variables in the ROUTE_SELECT message
(see section 8.3 for a discussion of the Call Routing Interface).
The values of the call variables may be used by the ICM to make routing decisions. The variables may contain
additional information about the caller, such as result of a Service database query. While routing a call, the ICM
may update one or more of the call variables. The updated variables are returned to the VRU in the
ROUTE_SELECT message.
When a call terminates (via the CALL_CLEARED_EVENT or CONFERENCED_EVENT message), the final
values of the call variables are recorded in the ICM’s central database and are available for use in historical
reports.
Table 38 defines the format of the SET_CALL_VARIABLES_EVENT message. The floating part of the message
consists of the fields CallVariable1 through CallVariable10. All of these fields are optional. Variables not
provided in the message are not affected.
Fixed Part
MessageHeader Standard message header. MessageType = MHDR 8
21.
CallID The ID of the call whose variables are to be UINT 4
set.
Floating Part
CallVariable1 (optional) Call-related data STRING 40
... ... ... ...
CallVariable10 Call-related data STRING 40
(optional)
ECC Value Call-related data ExpCallVarValue 215
or
(optional)
ExpCallVarArray
… … … …
or
(optional)
ExpCallVarArray
Table 38. SET_CALL_VARIABLES_EVENT Message Format
8.2.3.8 VRU Status Event

Changes in the operational status of the VRU are reported to the Peripheral Gateway in the
VRU_STATUS_EVENT message, defined in Table 39. The information in the VRU_STATUS_EVENT message
Page 43
is made available to the ICM in real time and is available for making routing decisions and for real time
monitoring.
The VRU should send this message to the Peripheral Gateway each time the VRU’s clock crosses a minute
boundary, and any other time a significant status change occurs.
CurrentTime The current UTC time according to the VRU clock. TIME 4
TimeZoneDelta The current local time zone delta, expressed in INT 4
seconds. This value is added to a UTC time to form
a time in the local time zone.
0: Normal Operation
1-31: Loss of redundant component or other
transparent failure; still fully functional for call
processing
... ... ... ...
Table 39. VRU_STATUS_EVENT Message Format
Page 44
8.2.3.9 Trunk Group Status Event

Changes in the operational status of a trunk group are reported to the Peripheral Gateway in the
TRKGRP_STATUS_EVENT message, defined in Table 40. The VRU generates this event when trunks have
been placed into service or taken out of service. The VRU sends one TRKGRP_STATUS_EVENT message for
each trunk group in which trunks change status.
When a trunk is brought into service, its state is initially TRUNK_IDLE (see Table 28). When a trunk is
removed from service, the ICM assumes that any call in progress on that trunk is cleared.
TrunkGroupID The ID of the trunk group affected, in the range 0 to 65535. UINT 4
TrunkCount The number of trunks, t, affected. TrunkCount may not exceed UINT 4
1024 because the total number of trunks in a trunk group may
not exceed 1024.
InService A flag indicating that the affected trunks have been placed BOOL 4
into service (True) or removed from service (False).
TrunkNumber1 The number of the first affected trunk. UINT 4
... ... ... ...
TrunkNumbert The number of the last affected trunk. UINT 4
Table 40. TRKGRP_STATUS_EVENT Message Format
8.2.3.10 Service Status Event

When a service becomes available or unavailable on the VRU, the VRU notifies the Peripheral Gateway by
sending a SERVICE_STATUS_EVENT message, defined in Table 41. The information in the
SERVICE_STATUS_EVENT message is made available to the ICM in real time and is available for making
routing decisions and for real time monitoring. The VRU sends one SERVICE_STATUS_EVENT message for
each affected service.
ServiceID The ID of the affected service. UINT 4
ServiceAvailable A flag indicating that the service has become BOOL 4
available (True) or unavailable (False).
Table 41. SERVICE_STATUS_EVENT Message Format
Page 45
8.3 Call Routing Interface

The Call Routing Interface is the means by which the VRU asks the ICM for instructions on how to route
(transfer) a call. The VRU supplies information about the call to be routed, and the ICM returns a label
specifying how the call should be routed. The label is a character string that encodes the instructions for
routing the call. How the routing instructions are encoded in the label is a matter of convention and may vary
from one VRU to another. For example, a label might consist of the digits necessary to outpulse to accomplish
the desired transfer; or contain the name of a program or script to be executed to accomplish the transfer.
This interface has been extended to support the Expanded Call Context feature of ICM V4.1. See section 5 for a
description of how to work with Expanded Call Context variables.
The VRU requests routing instructions by sending a ROUTE_REQUEST_EVENT message to the Peripheral
Gateway. This message begins a routing dialogue identified by the cross-reference ID. The Peripheral Gateway
responds with routing instructions in the ROUTE_SELECT message. The VRU accepts the route and
terminates the routing dialogue by sending a ROUTE_END_EVENT message. This is depicted in Figure 7.
Either the VRU or the Peripheral Gateway may terminate the routing dialogue prior to normal completion. The
VRU may send a ROUTE_END_EVENT prior to receiving a ROUTE_SELECT message from the Peripheral
Gateway if, for example, it times out and takes some default routing action. The Peripheral Gateway may send a
ROUTE_END message if it cannot deliver a route, or if it times out waiting for the arrival of a
ROUTE_END_EVENT. Messages received on an inactive routing dialogue are discarded without processing.
Figure 8 depicts the message flow for these error cases.
If the VRU issues ROUTE_REQUEST_EVENT's immediately upon session initialization, it may receive a
ROUTE_END message containing a status code of E_ROUTING_NOT_AVAILABLE. This is because it takes a
certain amount of time following session initialization for the ICM Router to become ready to handle route
requests. The VRU may simply try the ROUTE_REQUEST_EVENT again, possibly after delaying a second or
two. Alternatively, routing services will generally be available by the time the first heartbeat message arrives
from the PG, so the VRU might instead wait until it receives the first heartbeat before allowing any route
requests.
The floating part of the ROUTE_REQUEST_EVENT message includes the fields DialedNumber, ANI, CED, and
CallVariable1 through CallVariable10. The DialedNumber field is required; the other fields are optional. If a valid
CallID is provided, the call variables associated with that call are updated and then made available to the ICM
for call routing purposes. If the special value NULL_CALL_ID is provided, only the call variables provided in
the message are made available to the ICM (variables not provided are set to the null string).
The floating part of the ROUTE_SELECT message includes the fields Label and CallVariable1 through
CallVariable10. The Label field is required in all ROUTE_SELECT messages, although in cases where the
LabelType field is set to BUSY, RING, or DEFAULT; the label field will be null (FieldLength equal to zero).
Conversely, if the LabelType field is specified as NORMAL, the Label field will be non-null (FieldLength greater
than zero). Other fields in the ROUTE_SELECT message are optional. Only the call variables whose values
have changed are included.
Table 42 through Table 45 define the Call Routing Interface message formats.
The VRU specifies the final disposition of the routing dialogue by setting the status code in the
ROUTE_END_EVENT message to one of the following values:
• E_NO_ERROR, if the routing transaction completed normally.
• E_TIMEOUT, if the VRU did not receive the ROUTE_SELECT message within the allotted time.
• E_ROUTE_NOT_ACCEPTED, if the label supplied in the ROUTE_SELECT message is unacceptable to the
VRU.
If the Peripheral Gateway ends the routing dialogue by sending a ROUTE_END message, it specifies the final
disposition by setting the status code to one of the following values:
Page 46
• E_ROUTING_NOT_SUPPORTED, if the VRU did not indicate that the Call Routing interface was to be
used.
• E_ROUTING_NOT_AVAILABLE, if the Peripheral Gateway is unable to honor routing requests. If this
occurs very soon after session initialization, then it only means that the ICM Router is not yet ready to handle
route requests from this VRU.
• E_TIMEOUT, if the Peripheral Gateway times out awaiting the receipt of a ROUTE_END_EVENT message.
• E_INVALID_DIALED_NUMBER, if the dialed number provided in the ROUTE_REQUEST_EVENT is not
known to the ICM.
• E_UNSPECIFIED_FAILURE, if the route request could not be processed for any other reason.
The Call Routing Interface is also utilized when the ICM has routed the call to the VRU using a translation
route. In this case, the ICM has additional information associated with the call, and the ICM arranges for the
call to arrive at the VRU with a reserved DNIS value. The VRU recognizes this reserved DNIS value and uses
the ROUTE_REQUEST_EVENT message to request the additional information associated with the call; the ICM
provides the additional information in the ROUTE_SELECT message.
PG VRU
ROUTE_REQUEST_EVENT
ROUTE_SELECT
ROUTE_END_EVENT
Figure 7. Call Routing Message Flow
Page 47
PG VRU
Timeout
ROUTE_REQUEST_EVENT
or
Error
ROUTE_END_EVENT
-- OR --
ROUTE_REQUEST_EVENT
Timeout
or
Error ROUTE_SELECT
ROUTE_END
Figure 8. Call Routing Error Message Flow
Page 48
Fixed Part
Field Name Value Data Type Byte
Size
CrossRefID A cross-reference identifier assigned by the VRU to this UINT 4
call routing dialogue.
CallID The ID of the associated Event Data Feed call. If no UINT 4
DELIVERED_EVENT was sent for this call, use
NULL_CALL_ID.
Floating Part
Field Name Value Data Type Max.
Size
DialedNumber The number dialed by the caller. STRING 40
(required)
If this Route Request Event is to complete a Translation
Route and the CallID field above is set to
NULL_CALL_ID, this field must be set to the DNIS of
the arriving call.
If this Route Request Event is to complete a Translation
Route and the CallID is not set to NULL_CALL_ID this
field MUST NOT match any configured Dialed Number.
Use the string “TRANSLATION_ROUTE”. The DNIS
in the DELIVERED_EVENT of the referenced call record
will be used.
ANI (optional) The calling line ID of the caller. STRING 40
CED (optional) Caller-entered digits. STRING 40
CallVariable1 Additional information to be used in routing the call. STRING 40
(optional)
... ... ... ...
CallVariable10 Additional information to be used in routing the call. STRING 40
(optional)
or
(optional)
ExpCallVarArray
… … … …
or
(optional)
ExpCallVarArray
Table 42. ROUTE_REQUEST_EVENT Message Format
Page 49
Fixed Part
Size
CrossRefID Set to the same value as the CrossRefID of the UINT 4
corresponding ROUTE_REQUEST_EVENT message.
LabelType The type of the label returned in the following field. See UINT 4
Table 46 for a description of label types.
Floating Part
Size
Label (required) The destination to which the call should be routed. STRING 48
CallVariable1 Additional information related to the call. STRING 40
(optional)
... ... ... ...
(optional)
or
(optional)
ExpCallVarArray
… … … …
or
(optional)
ExpCallVarArray
Table 43. ROUTE_SELECT Message Format

Status A status code indicating the reason for terminating the UINT 4
Table 44. ROUTE_END_EVENT Message Format
Page 50

Status A status code indicating the reason for terminating the UINT 4
Table 45. ROUTE_END Message Format
Label Type Meaning Value

NORMAL The label refers to the destination to which the call should be 1
routed.
BUSY The label indicates that the caller should receive a busy signal. 2
RING The label indicates that the caller should receive ring-no-answer. 3
--- Value Not Supported. 4
DEFAULT The label indicates that the default routing action should be taken. 5
Table 46. Label Types
8.4 Time Synchronization Interface

The Time Synchronization interface ensures that the ICM and VRU clocks agree to within a reasonable
tolerance.
The ICM receives time indications from the VRU as part of the data it collects using the Event Data Feed or the
Service Control Interface. If the time reported by the VRU differs from the ICM time by more than a configured
threshold, the Peripheral Gateway will report the time difference to the VRU in a TIME_SYNCH_REQ message.
The VRU responds with a TIME_SYNCH_CONF message.
The VRU may adjust its clock based on the time difference reported in the TIME_SYNCH_REQ message.
However, care must be taken to ensure that time values reported to the ICM remain monotonically increasing.
The VRU must never report time going backwards, and sudden forward jumps in time have an undesirable effect
on real time monitoring and historical reporting. The recommended method for adjusting the clock is to make a
large number of small incremental adjustments, so the clock appears to run fast or slow until the time difference
has been eliminated. (For example, setting the clock back by 0.1 seconds every second has the effect of
running the clock 10% slow.)
The Peripheral Gateway only sends the TIME_SYNCH_REQ message if the time difference is greater than the
configured threshold (typically 15 seconds). The Peripheral Gateway sends at most one TIME_SYNCH_REQ
message in any 15-minute period.
The VRU may respond to the TIME_SYNCH_REQ message with a FAILURE_CONF message, setting the status
code to one of the following values:
• E_VRU_OFFLINE, if the VRU is no longer online. The Peripheral Gateway closes the session with the VRU
when it receives this response.
• E_REQUEST_REFUSED, if the VRU is temporarily unable to comply with the request. The Peripheral
Gateway tries again at the next interval.
• E_TIME_SYNCH_NOT_SUPPORTED, if the VRU does not support the Time Synchronization interface.
Page 51
The time synchronization message formats are detailed in Table 47 and Table 48.
InvokeID An ID for this request message that will be returned in UINT 4
the corresponding confirm message.
VRUTimeLag The number of seconds that the VRU clock lags the ICM INT 4
clock. The VRU may adjust its clock to match the ICM
by adding this value to its clock (see text). If the VRU
clock leads the ICM clock, this value will be negative.
Table 47. TIME_SYNCH_REQ Message Format

corresponding TIME_SYNCH_REQ message.
Table 48. TIME_SYNCH_CONF Message Format
8.5 Service Control Interface

The Service Control interface enables an ICM Script to determine the call handling steps that will be performed
by a VRU. The Service Control Interface must be initialized before it is used. Once initialized, the interface will
allow an ICM Script to control calls arriving at a VRU. The calls may have been Pre-Routed to the VRU by the
ICM Router, or routed to the VRU by other means. In either case, a Service Control dialogue must be initiated
by the VRU for each call the ICM Router will control.
A Service Control dialogue can be defined as a conversation between the VRU and the ICM router that consists
of one or more related call control transactions. A Service Control dialogue provides the context under which
the transactions will be performed. Once a Service Control dialogue has been established, the ICM Router will
control the VRU call handling via an ICM Script. Once the ICM Router has taken control of a call, the router will
retain call control until the Service Control dialogue is terminated.
The ICM Script will initiate Service Control transactions to the VRU using the Service Control message set. The
VRU will process request messages and perform the requested action. Acknowledgment messages will be sent
by the VRU to indicate a request has been completed. In addition to request/response call control
transactions, the VRU will provide event reports indicating changes in call state.
The Service Control dialogue will terminate when one of the following conditions occurs: the ICM Script
controlling the call has run to completion, the call terminates with respect to the VRU, or an unrecoverable error
occurs. In addition to providing VRU call handling instructions, the Service Control Interface may be
configured to report service, trunk, and per call statistics to the ICM database. The Service Control interface
has been designed to support VRU’s located in the telephone network, as well as those located on a customer
premise.
8.5.1 Initializing the Service Control Interface

Service Control Interface initialization is initiated by the VRU PG if the UseServiceControl flag of the
OPEN_CONF message is set when returned from the VRU. The VRU PG will send a INIT_SERVICE_CTRL_REQ
to the VRU to initiate the initialization sequence. The VRU will respond with INIT_SERVICE_CTRL_CONF
message followed by a INIT_SERVICE_CTRL_DATA message. The INIT_SERVICE_CTRL_DATA message
Page 52
will identify the Service Control Interface features that are supported by the given VRU. Optional initialization
messages may be sent following the INIT_SERVICE_CTRL_DATA message prior to sending the
INIT_SERVICE_CTRL_END message. The optional messages may be sent to initialize Trunk Group, Service,
and Peripheral data objects. Optional data objects that are not explicitly initialized will assume default values
based upon the object type as described below. The INIT_SERVICE_CTRL_END message will signify the end
of the initialization of the Service Control Interface after which dialogues may be created. The VRU should not
send NEW_CALL or REQUEST_INSTRUCTION, or NEW_DIALOGUE messages to the VRU PG prior to the
completion of the initialization sequence. If the Event Data Feed interface is also to be used, the Service Control
Interface initialization will also initialize the Event Data Feed interface. The VRU should not send any event
messages to the VRU PG prior to the completion of the initialization sequence.
8.5.1.1 Initializing Trunk Group Data

Trunk Groups may optionally be initialized during the Service Control Interface initialization sequence.
Providing trunk group initialization data will allow the ICM to immediately synchronize with the state of the
trunks within the various VRU trunk groups. Trunk Group initialization data includes the number of trunks
within the trunk group as well as the state of each trunk. The VRU provides trunk group initialization data
during the Service Control Interface optional initialization sequence by sending an
INIT_SERVICE_CTRL_TRKGRP message. A INIT_SERVICE_CTRL_TRKGRP message should be sent for
each trunk group to be initialized. The trunk status information will be made available to the ICM Router in real-
time to allow routing to available trunk ports. Failure to provide trunk initialization information during the
initialization sequence will result in the default of zero available trunks being reported to the ICM Router at
startup. As a result, it is necessary to provide trunk initialization information in all cases where ICM Routing
decisions will be made on trunk availability. In cases where calls arriving at the VRU where not routed by the
ICM Router, trunk group initialization data may be omitted. Omission of trunk initialization data will result in
inaccurate trunk group reporting until such time that all trunks within a trunk group have received a call
following the completion of Service Control Interface initialization. In either case, TRUNK_STATUS messages
should be sent by the VRU following the Service Control initialization sequence to indicate that a given trunk
port has been removed from service or restored to service. Failure to provide TRUNK_STATUS events may
result in routing decisions based on incorrect trunk availability data.
8.5.1.2 Initializing VRU Service Data

VRU Services may optionally be initialized during the Service Control Interface initialization sequence.
Providing service initialization data will allow the ICM to immediately synchronize with the state of the VRU
services. Service initialization data includes the number of inbound calls in progress attributed to the service,
the number of outbound calls in progress attributed to a service and a flag indicating the availability of the
service.
The VRU provides service initialization data during the Service Control Interface optional initialization sequence
by sending an INIT_SERVICE_CTRL_SERVICE message. An INIT_SERVICE_CTRL_SERVICE message should
be sent for each service to be initialized. The service availability and call counts will be made available to the
ICM Router in real-time. ICM Routing Scripts may route based on the in-progress call counts as well as the
availability of a given service at a particular peripheral. Failure to provide service initialization information
during the initialization sequence will result in the default of zero inbound and outbound calls in progress being
reported to the ICM Router at startup. In addition, all services configured in the ICM will be assumed to be
available. As a result, it is necessary to provide service initialization information in all cases where ICM Routing
decisions will be made on the number of calls in progress at a VRU.
In cases where calls in progress for a given service are not used in ICM routing decisions, service initialization
data may be omitted. Omission of service initialization data will result in inaccurate service reporting of calls in
progress counts until such time that all calls in progress when the VRU initially connects to the VRU PG have
terminated. In either case, SERVICE_STATUS messages should be sent by the VRU following the Service
Control initialization sequence to indicate that the availability of a given service has changed. Failure to
provide SERVICE_STATUS indications may result in calls being routed to unavailable services.
Page 53
8.5.1.3 Initializing VRU Peripheral Data

The peripheral VRU data may optionally be initialized during the Service Control Interface initialization
sequence. Providing peripheral VRU initialization data will allow the ICM to immediately synchronize with the
peripheral data of the VRU. Peripheral VRU Data includes the time zone of the VRU, the operational status of
the VRU and sixteen status variables. The status variables may be used to pass additional VRU status
information to the ICM to be used in routing decisions. The use and definition of the status variables is left up
to the implementation of the particular VRU platform. The status variable values may be tested in ICM Routing
Scripts to make routing decisions.
The VRU may initialize peripheral data during the Service Control Interface optional initialization sequence by
sending a single INIT_SERVICE_CTRL_VRU message. The operational status and the status variable values
will be made available to the ICM Router in real-time. Failure to provide peripheral data initialization information
during the initialization sequence will result in the default of operational status of NORMAL and status variable
values of zero. The time zone of the VRU will default to be equal to that of the VRU PG.
In cases where operational status or status variable values are not used in ICM routing decisions, and the VRU
resides in the same time zone as the VRU PG, peripheral data initialization may be omitted. Omitting initialization
of peripheral data will result in inaccurate peripheral reporting of status variables and possibly operational
status. In either case, VRU_STATUS messages should be sent by the VRU following the Service Control
initialization sequence to indicate changes in the operational status of the VRU or updates to the status variable
values. Failure to provide VRU_STATUS indications may result in calls being routed to a VRU whose
operational status is such that the call can not be properly handled.
Page 54
PG VRU
INIT_SERVICE_CTRL_REQ
INIT_SERVICE_CTRL_CONF
INIT_SERVICE_CTRL_DATA
Optional Initialization
Messages
} INIT_SERVICE_CTRL_TRKGRP
INIT_SERVICE_CTRL_SERVICE
INIT_SERVICE_CTRL_VRU
INIT_SERVICE_CTRL_END
First
Service Control
Message
Figure 9. Service Control Initialization Sequence
8.5.2 Service Control Database Reporting

The Service Control Interface may be optionally configured to report termination call detail records, service,
trunk group, and peripheral real-time records. The option to report statistics is set during the VRU PG
installation process. The Service Control Reporting box and the Service Control Queue Reporting box should be
checked to enable reporting for a given peripheral. The VRU PG will derive the real-time statistics from the
Service Control Messages exchanged with a given VRU. Initial baseline values may be supplied by the VRU
during the Service Control Initialization by sending the optional initialization messages. If the optional baseline
information is not supplied, all call related real-time in-progress counters are initialized to zero.
Enabling call statistics reporting will enable real-time reporting of the following ICM Database Schema Elements:
Termination_Call_Detail, Service_Real_Time, Peripheral_Real_Time, and TrunkGroup_Real_Time records. The
VRU PG accumulates real-time records to derive the corresponding five-minute2 and half-hour database records.
For a description of the individual database elements, refer to the Cisco ICM Software Database Schema
Handbook .
2
Note: Reporting of five-minute records is suppressed by default.
Page 55
8.5.2.1 Termination_Call_Detail Database Records

Termination Call Detail records are written for each call delivered to a given VRU if the Service Control
Reporting option has been enabled. The Termination Call Detail record provides a summary of a call and the
treatment applied to a call. Termination Call Detail fields include a variety of call state times, dialed number,
ANI, call disposition, as well as the ten peripheral variables and the Expanded Call Context variables that may be
set by the VRU.
As the name implies, a termination call detail record will be written upon termination of a given call. It will be
written only to the ICM instance which controls the corresponding VRU PG. The VRU may optionally write an
additional termination call detail record any time it sends a RUN_SCRIPT_RESULT message. A Termination Call
Detail record is also automatically written when the VRU uses the NEW_DIALOGUE message to transfer a call
from the Event Data Feed interface to the Service Control Interface.
The Termination Call Detail fields may be divided into two groups: time values and data values. Time values are
calculated based on the elapsed time between Service Control messages. Data values are either taken directly
from VRU Service Control messages, or calculated based on data received in Service Control messages. In
addition to time values, there are a number of data values present in a Termination Call Detail record. Table 49
below defines the fields that will be populated by a VRU PG when implementing the Service Control Interface.
For a description of the individual database elements, refer to the Cisco ICM Software Database Schema
Handbook .
PeripheralCallKey VRU (in NEW_CALL or REQUEST_INSTRUCTION messages as DialogueID)
CallDisposition VRU (based on CauseCode in EVENT_REPORT/ABANDON or
EVENT_REPORT/DISCONNECT). See Table 34 for Cause Code list.
Variable1 VRU (in NEW_CALL or RUN_SCRIPT_RESULT message)
through or ICM (set by ICM Routing Script)
Variable10
UserToUser VRU (in (NEW_CALL, NEW_DIALOGUE, or REQUEST_INSTRUCTION message)
TimeZone VRU (in INIT_SERVICE_CTRL_VRU message)
TrunkGroupID VRU (in NEW_CALL or REQUEST_INSTRUCTION message)
DNIS VRU (in NEW_CALL or REQUEST_INSTRUCTION message)
ANI VRU (in NEW_CALL or RUN_SCRIPT_RESULT message)
or ICM (set by ICM Routing Script)
Trunk VRU (in NEW_CALL or REQUEST_INSTRUCTION message)
Table 49: Termination_Call_Detail Database Records
Page 56
8.5.2.2 Service_Real_Time Database Records

The ICM will write Service Real-time records based on the information provided by the VRU via Service Control
messages if the Service Control Reporting option has been selected. During Service Control Initialization, the
status of each Service resident on a given VRU may optionally be sent by the VRU via an
INIT_SERVICE_CTRL_SERVICE message. The calls in progress counts will be initialized during the Service
Control initialization sequence. As calls arrive, are redirected to other services on the VRU, or terminate, the
service statistics for all services a call passes through will be updated.
Failure to provide initialization data for a service configured in the ICM configuration will result in the service
being marked as AVAILABLE and the in progress call counts will be set to zero. This may cause certain ICM
Routing Scripts that make routing decisions based on the zero calls in progress counts at PG startup to route
calls to a less desirable VRU until such time that the counters reach steady state values.
Refer to the Cisco ICM Software Database Schema Handbook for additional details on Service Real-time
records.
SkillTargetID ICM Configuration
DateTime ICM Router
AgentsTalking N/A
AnswerWaitTimeHalf N/A
AnswerWaitTimeTo5 N/A
AnswerWaitTimeToday N/A
AvgDelayQAbandTo5 N/A
AvgDelayQNow N/A
AvgHandleTimeTo5 VRU PG
AvgSpeedAnswerTo5 N/A
AvgTalkTimeTo5 VRU PG
CallsAbandQHalf N/A
CallsAbandQTo5 N/A
CallsAbandQToday N/A
CallsAnsweredHalf VRU PG
CallsAnsweredTo5 VRU PG
CallsAnsweredToday VRU PG
CallsHandledToHalf VRU PG
CallsHandledTo5 VRU PG
CallsHandledToday VRU PG
CallsIncomingHalf VRU PG
CallsIncomingTo5 VRU PG
CallsIncomingToday VRU PG
Page 57
CallsInNow VRU PG
CallsInProgress VRU PG
CallsLeftQTo5 N/A
CallsOfferedHalf VRU PG
CallsOfferedTo5 VRU PG
CallsOfferedToday VRU PG
CallsOutHalf N/A
CallsOutNow N/A
CallsOutTo5 N/A
CallsOutToday N/A
CallsQNow N/A
CallsQNowTime N/A
CallsRoutedHalf ICM Router
CallsRoutedToday ICM Router
CallsTerminatedOtherHalf N/A
CallsTerminatedOtherTo5 N/A
CallsTerminatedOtherToday N/A
DelayQAbandTimeTo5 N/A
ExpectedDelay ICM Router
HandleTimeHalf VRU PG
HandleTimeTo5 VRU PG
HandleTimeToday VRU PG
LongestAvailAgent N/A
LongestCallQ N/A
OverflowInHalf N/A
OverflowInTo5 N/A
OverflowInMode N/A
OverflowInNow N/A
OverflowInToday N/A
OverflowOutHalf N/A
OverflowOutMode N/A
OverflowOutNow N/A
OverflowOutTo5 N/A
OverflowOutToday N/A
Page 58
PeriphServiceLevelCallsHalf N/A
PeriphServiceLevelCallsToday N/A
PeriphServiceLevelHalf N/A
PeriphServiceLevelOfferHalf N/A
PeriphServiceLevelOfferToday N/A
PeriphServiceLevelTo5 N/A
PeriphServiceLevelToday N/A
ServiceLevelAbandHalf N/A
ServiceLevelAbandTo5 N/A
ServiceLevelAbandToday N/A
ServiceLevelCallsHalf N/A
ServiceLevelCallsOfferedHalf N/A
ServiceLevelCallsOfferedTo5 N/A
ServiceLevelCallsOfferedToday N/A
ServiceLevelCallsQHeld N/A
ServiceLevelCallsTo5 N/A
ServiceLevelCallsToday N/A
ServiceLevelHalf N/A
ServiceLevelTo5 N/A
ServiceLevelToday N/A
ServiceModeIndicator N/A
TalkTimeHalf VRU PG
TalkTimeTo5 VRU PG
TalkTimeToday VRU PG
TransferInCallsHalf N/A
TransferInCallsTo5 N/A
TransferInCallsToday N/A
TransferOutCallsHalf N/A
TransferOutCallsTo5 N/A
TransferOutCallsToday N/A
Table 50 Service_Real_Time Database Records
8.5.2.3 Peripheral_Real_Time Database Records

The VRU may provide Peripheral Real-time updates periodically by sending VRU_STATUS messages to the
VRU PG if the Service Control Reporting option has been selected. The VRU_STATUS message is used to
Page 59
communicate a change in the operational status of a VRU that may affect the ability of the VRU to properly
handle calls. The VRU_STATUS message also contains the VRU time of day and time zone that is used to
synchronize the VRU PG clock to that of the VRU, as well as, sixteen status variables. Periodically, the VRU PG
will forward a Peripheral Real-time update to the ICM Router thereby causing an ICM database record to be
written.
In order to ensure proper clock synchronization between the VRU and the VRU PG, it is suggested that that
VRU send a VRU_STATUS message each time the clock on the VRU crosses a minute boundary.
The status variables may be used to pass additional VRU status information to the ICM. The status variables
may be tested in ICM Routing Scripts to make routing decisions. The use and definition of the status variables
is left up to the implementation of the particular VRU platform.
PeripheralID ICM Configuration
DateTime VRU PG
PeripheralTimeZone VRU PG
Status VRU (in VRU_STATUS message)
Online VRU PG
PeripheralTimeOffset ICM Router
CallsInProgress VRU PG
AgentsLoggedOn N/A
CallsOfferedHalf VRU PG
CallsOfferedToday VRU PG
ServiceLevelCallsOfferedHalf N/A
ServiceLevelCallsOfferedToday N/A
ServiceLevelAbandHalf N/A
ServiceLevelAbandToday N/A
ServiceLevelCallsHalf N/A
ServiceLevelCallsToday N/A
PeripheralData1 through VRU (in VRU_STATUS message)
PeripheralData16
ModePeripheralData1 VRU PG.
CurrentHalfHour VRU PG.
UserControl N/A
CallsRoutedHalf VRU PG.
CallsRoutedToday VRU PG.
Table 51: Peripheral_Real_Time Database Records
Page 60
8.5.2.4 Trunk Group_Real_Time Database Records

The ICM will write Trunk Group Real-time records based on the information provided by the VRU via Service
Control messages if the Service Control Reporting option has been selected. During Service Control
Initialization, the status of each trunk within a trunk group may optionally be sent by the VRU via an
INIT_SERVICE_CTRL_TRKGRP message. Each initialized trunk will be added to the total trunk count for the
given trunk group. The trunk states will be used to calculate the number of trunks in use inbound, in use
outbound, out of service, and idle. As calls arrive and terminate at the VRU, the trunk states will be updated
and new real-time vales calculated by the VRU PG. Periodically the VRU PG will send updates to the ICM
Router containing the latest calculated trunk group real-time values.
Failure to provide trunk initialization data will result in all trunk counts being zeroed for the trunk groups
configured in the ICM database. This may cause ICM Routing Scripts that make routing decisions based on
real-time trunk group availability or utilization to behave strangely.
Refer to the Cisco ICM Software Database Schema Handbook for additional details on Trunk Group Real-time
records.
TrunkGroupID ICM Configuration
DateTime VRU PG
AllTrunksBusyHalf VRU PG
AllTrunksBusyToday VRU PG
CallAbandonedHalf VRU PG
CallsAbandonedToday VRU PG
CallsInHalf VRU PG
CallsInToday VRU PG
InUseInboundTimeToday VRU PG
InUseOutboundTimeHalf VRU PG
InUseOutboundTimeToday VRU PG
TrunksIdle VRU PG
TrunksInService VRU PG
Table 52: TrunkGroup_Real_Time Database Records
8.5.3 Service Control Dialogues

Creation of a Service Control dialogue is initiated by the VRU when it is desired that the ICM Router control
call-handling operations. A Service Control dialogue must be established for each and every call on the VRU
that will be controlled by the ICM Router. The dialogue will provide the context necessary to relate the ICM
Script to a series of call handling operations. A single dialogue may consist of one or more call handling
transactions. A call handling transaction is defined as a request made to the VRU followed by an
acknowledgment from the VRU. As the ICM Router processes ICM script nodes, requests will be made to the
VRU to perform the desired call handling operations. The VRU will perform the operation and respond with
either a positive or negative acknowledgment. A positive result will signal the ICM Router to execute the next
script node on the positive path, while a negative result will cause the error path of the ICM Script node to be
taken. The ICM Router will retain control of VRU call handling operations until one of the following events
Page 61
occur: the ICM Script runs to completion, a failure scenario occurs such that the ICM Router can no longer
provide instructions to the VRU, or the call being controlled terminates.
8.5.3.1 Establishing Service Control Dialogues

The VRU must establish a Service Control dialogue prior to receiving instructions from the ICM Router. Exactly
how a VRU establishes a Service Control dialogue is a function of whether the call is under ICM Script control
when it arrives at the VRU. In cases where the ICM Router routed the call to the VRU the call will already be
under script control. If a call is under script control when arriving at the VRU, a REQUEST_INSTRUCTION
message should be sent by the VRU to continue script processing. In cases where the call is not under script
control when arriving at the VRU a NEW_CALL message should be used to initiate the creation of the Service
Control dialogue. The NEW_CALL message will cause the ICM Router to begin running the ICM Script
scheduled for the given call type. In either case, the active ICM Script will begin sending instructions to the
VRU. The VRU does not send any further REQUEST_INSTRUCTION or NEW_CALL messages for this call.
The ICM Router will retain control of the call until the Service Control dialogue either terminates (normally or
failure scenarios), or the ICM Router relinquishes control following a CONNECT message.
Each dialogue between the ICM Router and a VRU will be uniquely identified via a dialogue identifier
(DialogueID). The uniqueness of the dialogue identifier is limited in scope to a given VRU/VRU PG pair. It is
the responsibility of the VRU to ensure the dialogue identifier is unique since it is chosen by the VRU. The
dialogue identifier must be unique for the entire life of the dialogue that it identifies. If an attempt is made to
establish a dialogue using a dialogue identifier that is currently in use, a DIALOGUE_FAILURE_EVENT will be
sent with an error code of E_DUPLICATE_DIALOGUEID. This event will essentially provide a negative
acknowledgment to the attempt to create a new dialogue as well as a termination event for the existing dialogue
using the given dialogue identifier. The existing session must also be terminated since it can no longer be
uniquely addressed.
The dialogue identifier will be chosen by the VRU at the time the dialogue is created by either the NEW_CALL
or REQUEST_INSTRUCTION message. All messages sent and received under the context of a given dialogue
will contain the dialogue identifier. It is imperative that the dialogue identifier be unique
The VRU must be configured to send the appropriate message to establish a Service Control dialogue. This is
accomplished by classifying arriving calls based on the characteristics (Dialed Number, DNIS, Trunk Group,
User To User Info, Correlation ID) of the call. A given Dialed Number, DNIS, or Trunk Group combination
should be configured to send either a NEW_CALL or REQUEST_INSTRUCTION message. Those calls that
result in the sending of a REQUEST_INSTRUCTION message must have been Pre-Routed by the ICM Router.
Calls not Pre-Routed by the ICM Router should result in the VRU initiating a Service Control dialogue by
sending a NEW_CALL message. Call arrival characteristics at the VRU must be configured such that Pre-
Routed calls are distinguishable from those calls that were not Pre-routed.
8.5.3.2 Sending Event Reports via Dialogues

The previous section described the procedures for establishing a Service Control dialogue. Once a dialogue
has been established the VRU must provide event reports for calls associated with dialogues. The
EVENT_REPORT message will be sent by the VRU as an unsolicited event. The EVENT_REPORT message will
be used to communicate the following call status events: ANSWERED, BUSY, NO_ANSWER, ABANDON,
CONNECT_FAILURE, or DISCONNECT. The ANSWERED event should be sent when a call is established with
the destination specified in the CONNECT message. The BUSY event should be sent when a call receives a
busy indication for the destination specified in the CONNECT message. The NO_ANSWER event will be sent
by the VRU when an out-dialed call is not answered within the designated time limit or ring count. The
CONNECT_FAILURE status code should be sent if call fails to connect due to telephone network errors. An
example of such a case would be TRITONE played by the network for an invalid number.
The ABANDON status code may be sent by the VRU to indicate that a call disconnected prior to the caller
receiving the service offered by the VRU. An example of such a call might be a case where a VRU service
provides call treatment waiting for an ACD (Automatic Call Distributor) agent to become available. When an
Page 62
ACD agent becomes available, the call is transferred by the VRU to the available agent. If the caller chooses to
end the call prior to being connected to an agent, an ABANDON status may be sent by the VRU to indicate that
the call terminated before the intended service was provided.
The DISCONNECT message is sent when the call terminates with respect to the VRU. The DISCONNECT and
ABANDON events will also terminate the Service Control dialogue. The choice between either the
DISCONNECT or ABANDON message is left to the VRU implementation.
8.5.3.3 Sending Call Control Instructions via Dialogues

Independent of how the Service Control dialogues are created, a Service Control dialogue is used to provide
call-handling instructions to a VRU. As the ICM Router executes the ICM Script associated with the dialogue,
instructions are sent to the VRU. The VRU performs the requested operation and sends an acknowledgment
when the request has been completed. The ICM may attempt to cancel operations at any time prior to receiving
the acknowledgment that the operation has completed. An acknowledgment may contain result data that was
calculated or collected by the VRU. The result data may be used by the ICM Router to determine an ultimate
target for the call. A typical ICM Router/VRU dialogue may consist of a number of call-control transactions
taking place before the dialogue terminates. The current implementation of the Service Control interface is
limited to performing CONNECT, CANCEL. RELEASE, RUN_SCRIPT_REQ, or various MICROAPP requests.
A RUN_SCRIPT_REQ request will be sent by the ICM Router to select a VRU script to be run in order to handle
a given call. The VRU executes the requested script upon receiving the RUN_SCRIPT_REQ message and sends
a RUN_SCRIPT_RESULT response message as a positive acknowledgment. The RUN_SCRIPT_RESULT
message may contain data collected or calculated by the VRU. In the event an error occurs attemp ting to run
the script, the VRU should return a DIALOGUE_FAILURE_CONF message to indicate that the request could
not be processed.
The ICM Router will send a CONNECT message to the VRU in order to transfer or re-target the call to a new
destination. Upon receipt of a CONNECT message, the VRU will transfer the call to the destination specified by
the label or label type. In the event a CONNECT operation can not be processed, a
DIALOGUE_FAILURE_EVENT will be sent by the VRU to the ICM Router to indicate a failure has occurred.
The success of a CONNECT request will be communicated through a subsequent EVENT_REPORT which will
indicate that the call was either ANSWERED or the selected destination was BUSY. If the destination was
busy, the ICM Router may specify a new destination by sending a second CONNECT message. The VRU
again will attempt to retarget the call to the specified destination.
The ICM Router will send a RELEASE message to the VRU in order to instruct the VRU to release the call
currently associated with the specified dialogue. Upon receipt of a RELEASE message, the VRU will
immediately release the call and send an EVENT_REPORT to indicate that the call has disconnected. The
CauseCode in the disconnected EVENT_REPORT message should be set to Normal Completion. In the event a
RELEASE operation can not be processed, a DIALOGUE_FAILURE_EVENT should be sent by the VRU to the
ICM Router to indicate a failure has occurred. The success of a RELEASE request will be communicated
through a subsequent EVENT_REPORT that will indicate that the call has disconnected.
8.5.3.4 Canceling Running VRU Scripts or MicroApplications

If an ICM routing script MicroApplication node has the “ICM may interrupt” box checked, or if the VRU Script
has been configured in the ICM as “Interruptible”, then the ICM Router may elect to interrupt the VRU
operation with a Connect request. This occurs most often when the call has been queued in the ICM, and an
agent becomes available.
Assuming the VRU has declared in its INIT_SERVICE_CTRL_DATA message that it supports CANCEL
requests (“FEATURE_CANCEL”), the VRU will receive a CANCEL request first. The VRU should immediately
cancel the currently executing VRU script or MicroApplication identified by the RequestID field, and return a
DIALOGUE_FAILURE_CONF message, containing an error code of E_OPERATION_CANCELLED and the
InvokeID should identify the script or MicroApplication operation that was cancelled. This replaces the normal
Page 63
RUN_SCRIPT_RESULT or MICROAPP_RESULT message. The VRU will then receive the CONNECT request
that the ICM Router has prepared. In the case of MICROAPP_PLAY and MICROAPP_PLAY_CONTINUE, the
VRU PG will never interrupt a sequence of these messages with a CANCEL request.
Generally, if the ICM application designer has declared the operation (either VRU Script or MicroApplication
node) as interruptible, then the VRU should be willing to abort that operation on a moment’s notice. However,
if for some reason the VRU cannot abort immediately, it can return a DIALOGUE_FAILURE_CONF message
containing an error code of E_OPERATION_NOT_CANCELLED and an InvokeID identifying the rejected
CANCEL message. When it is finally ready, the VRU should send its usual RUN_SCRIPT_RESULT or
MICROAPP_RESULT message. However, depending on how much time has elapsed, the ICM Router may by
that time have assigned the agent to a different call. The VRU may then receive the (now invalid) CONNECT
request anyway, or it may receive a DIALOGUE_FAILURE_EVENT message.
As a result, it is strongly recommended that if a VRU Script or MicroApplication node is configured as
Interruptible, the VRU should be sure it can abort the corresponding operation. If a delay is absolutely
necessary, a period of approximately 2 seconds or so should be safe.3
8.5.3.5 Terminating Service Control Dialogues

A Service Control dialogue will terminate when any one of the following conditions has occurred: the call
associated with the dialogue disconnected for any reason, a non-recoverable failure occurred making further
call control impossible. As long as a dialogue is active for a given call, the ICM Router will retain call control.
In a typical scenario, a Service Control dialogue will terminate when a DISCONNECT EVENT_REPORT or an
ABANDON EVENT_REPORT message is received from the VRU. In the case of non-recoverable failures,
dialogues will be terminated by a DIALOGUE_FAILURE_EVENT message. The ICM Router or the VRU can
send a DIALOGUE_FAILURE_EVENT message at any time. In the event that VRU PG to VRU connection is
lost, all active dialogues will fail and the VRU should take default call handling actions.
8.5.4 Using MicroApplications

VRU MicroApplications are a set of elementary operations which are executed by the VRU under the control of
an ICM Router script. These operations consist essentially of the ability to play individual prompts of various
media, and to accept DTMF keystroke input from the caller. They are invoked via the, Collect Data, Menu,
Play, and Set VRU Data ICM Script Editor nodes.
Architecturally, MicroApplications are very similar to VRU scripts. In fact, they are literally nothing more than
VRU scripts which have been specialized for specific purposes. All call handling and call treatment
considerations therefore follow the Run Script paradigm.
There is a rough correlation between the MicroApplication Script Editor nodes and the ICM/VRU Interface
messages they generate.
• A Collect Data node generates a MICROAPP_COLLECT_DATA message
• A Menu node generates a MICROAPP_MENU message
• A Play node generates a MICROAPP_PLAY message followed by zero or more
MICROAPP_PLAY_CONTINUE messages.
• A Set VRU Data node is linked to the MICROAPP_CONTEXT message, but doesn’t always generate
one. This relationship will be discussed in Section 8.5.4.3, “MicroApplication Message Flow”.
3
What constitutes a safe period is actually dependent on the settings of several different timers, as well as on
current network congestion and message processing performance characteristics. The choice of two seconds is
based on typical default settings and typical characteristics, and leaves a substantial margin for error, but it is
not guaranteed.
Page 64
The one remaining MicroApplication message in the ICM/VRU Interface is MICROAPP_RESULT, which the
VRU sends back to the ICM to return the results of the prior MicroApplication request.
8.5.4.1 Using Media Specifiers

Integral to most of these messages is a variable-length datatype called MEDIA_SPECIFIER. This datatype has
its own internal syntax, and can be used to ask the VRU to play one of several Media Protocols: either a media
file (prompt), a streaming media file (such as music on hold), a synthesized prompt (text -to-speech), or a data
value from an ICM script variable. Though the ICM script nodes don’t allow quite all these possibilities in all
instances, the VRU should be prepared to play any of these types of prompts, wherever a MEDIA_SPECIFIER
field appears. Also, it is not expected that every VRU can support all defined Media Protocols. If the VRU is
asked to play a Media Protocol that it does not support, it should immediately abort the current
MicroApplication request and return a MICROAPP_RESULT message with the Microapp Error Code field set to
MICROAPP_E_MEDIA_PROTOCOL. (However, if the current MicroApplication request is a
MICROAPP_PLAY / MICROAPP_PLAY_CONTINUE set, then it should wait for the last message in the set
before sending its MICROAPP_RESULT.)
As described in the MEDIA_SPECIFIER Message Element Data Type discussion in Section 4.3.1, each
MEDIA_SPECIFIER begins with a Media Protocol field which dictates the layout of the remaining bytes. Four
of the defined Media Protocols (H, S, F and O) are used to designate Media URL’s, which are described in
Sections 8.5.4.1.1 and 8.5.4.1.2,below. The remaining Media Protocols are D, which carries a data value to be
played according to a specified format, and T, which designates a Text -to-Speech announcement. These are
described in Sections 8.5.4.1.3 and 8.5.4.1.4, respectively. Finally, Section 8.5.4.1.5 contains a discussion of how
Protocol H MEDIA_SPECIFIER’s can be used to play non-voice messages, such as web pages and images.
8.5.4.1.1 Media URL’s - The MicroApplication Media Model

Traditional voice-only VRU’s can play pre-recorded prompts according to instructions provided by their
scripts. These individual prompts may be addressed by prompt number, by directory path and filename, by an
alias name – every VRU uses a different method. Furthermore, addressing the same prompt for a different
language may be accomplished by offsetting the prompt number, re-basing the directory path, prefixing the
alias, etc. Other variations in addressing are equally inconsis tent.
In order to find some overarching prompt addressing model which would be compatible with most VRU’s, the
ICM employs a concept called Media URL. The idea is to view the VRU’s prompt address as if it were a
resource on the World Wide Web, containing a number of specific components:
• Media Protocol, such as HTTP or RTSP (streaming media), which helps to indicate how the media file
should be rendered;
• Media Server Set, which generally identifies the host;
• CustomerID, which identifies the particular customer whose media is to be played (this is important in
multi-tenant configurations);
• Locale, which specifies a country and language combination;
• Whether or not the application-independent (“System”) or application-dependent (“Application”)
media library is being referenced; and
• The Media Filename and extension.
Thus, a Media URL is expected to be constructed by the VRU as follows:
<Protocol>://<MediaServerSet>/<CustomerID>/<Locale>/<Library>/<Filename>
Clearly however, most VRU’s do not address their prompts in this way. It is therefore up to each VRU vendor
to decide how to map this structure into one which makes sense for that VRU’s addressing scheme. The
Page 65
vendor should then make its mapping known to the ICM routing script designer so that he can reference VRU
prompts appropriately from the script level.
For example, a VRU which only addresses prompts by number, with each language group being selected by
adding a numeric offset, might elect to completely ignore all the URL components except <Locale> and
<Filename>, and only allow numeric values in either of those fields. In that case the script designer would not
bother filling in the unused fields, and would enter the appropriate numeric values for <Locale> and <Filename>.
8.5.4.1.2 Playing Media URL’s

MEDIA_SPECIFIER fields containing Media Protocol codes H (for HTTP), F (for FILE), S (for Streaming), or O
(for Other) designate Media URL’s. Media URL’s are constructed by combining information from each
MEDIA_SPECIFIER with context information from a recent MICROAPP_CONTEXT message. (See Section
8.5.4.3 below for information about when and why this message appears.) The URL should be built as follows:
<Protocol> For MediaSpecifier.cProtocol value of ‘H’, use HTTP
For MediaSpecifier.cProtocol value of ‘F’, use FILE
For MediaSpecifier.cProtocol value of ‘S’, use RTSP
For MediaSpecifier.cProtocol value of ‘O’, use nothing. <Protocol> will be
embedded in the MicroappContext.MediaServerSet string.
<MediaServerSet> Use MicroappContext.MediaServerSet
<CustomerID> Use MicroappContext.CustomerID
<Locale> Use MicroappContext.Locale
<Library> For MediaSpecifier.cLibrary value of ‘S’, use MicroappContext.SysLibName
For MediaSpecifier.cLibrary value of ‘A’, use MicroappContext.AppLibName
For MediaSpecifier.cLibrary value of NULL, use nothing.
<Filename> Use MediaSpecifier.sFilename
Table 53: Components of a Media URL
For example, a MediaSpecifier containing these fields:

cProtocol H
cLibrary A
sFilename GoodMorning.wav
against a MicroappContext containing these fields:
MediaServerSet www.internalweb.com
CustomerID CiscoSystemsInc
Locale en_US
SysLibName sys
AppLibName app
would build a Media URL that looks like this:
HTTP://www.internalweb.com/CiscoSystemsInc/en_US/app/GoodMorning.wav
Of course, a VRU which doesn’t use URL’s to address prompt files would do something completely different,
but the purpose behind each field should be maintained.
8.5.4.1.3 Playing Data Values

MEDIA_SPECIFIER fields containing Media Protocol code ‘D’ (for Data) designate data values which the VRU
is to play. These specifiers contain a Value field, which will always be a string, and a PlaybackType field, which
indicates how the Value string should be interpreted. For example, the string “25.01” should be rendered as a
Page 66
dollar figure (“twenty-five dollars and one cent”) if the PlaybackType is PLAYBACK_TYPE_CURRENCY, or a
number (“twenty-five point zero one”) if the PlaybackType is PLAYBACK_TYPE_NUMBER.
The following table shows how the VRU should interpret each PlaybackType code:
PLAYBACK_TYPE_NUMBER Number. The value could be positive or negative, and could
contain a decimal point.
PLAYBACK_TYPE_CHAR Characters. For example “five” should be played as “eff aye
vee ee”.
PLAYBACK_TYPE_ETIME Elapsed Time. The Playback Format field describes how to
play this value.
PLAYBACK_TYPE_TOD Time of Day. The Playback Format field describes how to play
this value.
PLAYBACK_TYPE_24TOD 24-Hour Time of Day. The Playback Format field describes
how to play this value.
PLAYBACK_TYPE_DOW Day of Week. 1-7 correspond to Sunday through Saturday.
PLAYBACK_TYPE_DATE Date. Format is YYYYMMDD.
PLAYBACK_TYPE_CURRENCY Currency. The value may or may not contain a decimal point,
but will not contain a currency sign (such as ‘$’).
PLAYBACK_TYPE_TEXT Text. This is one way of specifying Text -to-Speech synthesis.
If the VRU does not support Text -to-Speech, it should
immediately return a MICROAPP_RESULT message with the
Microapp Error Code set to
MICROAPP_E_MEDIA_PROTOCOL.
Table 54: Playback Types in Data Media Specifiers
For time-oriented PlaybackType codes, the VRU should further examine the PlaybackFormat field, which
contains one of the following:
PLAYBACK_FORMAT_HHMM Play hours and minutes only, in military style. For
example, “1605” should play as “sixteen oh five”.
PLAYBACK_FORMAT_HHMMSS Play hours, minutes and seconds, in military style. For
example, “160523” should play as “sixteen oh five and
twenty-three seconds”.
PLAYBACK_FORMAT_HHMMAP Play hours and minutes, with AM or PM. For example,
“1605” should play as “four oh five PM”.
PLAYBACK_FORMAT_OTHER None of the above. This is only the default code which
appears in this field for playback types other than those
related to time.
Table 55: Playback Formats in Data Media Specifiers
Note that neither the ICM Router nor the Script Editor perform any validation on the data format which appears
in the Value field of a Data MEDIA_SPECIFIER. It is possible, for example, for the script designer to
erroneously place letters into a date or number field. Therefore the VRU should verify the data it receives
against its corresponding legal format, before attempting to play it. If it detects a format error, it should
immediately abort the current MicroApplication request, and return a MICROAPP_RESULT message with
Microapp Error Code set to MICROAPP_E_NUMBER_FORMAT or MICROAPP_E_DATA_RANGE, as
appropriate. As a debugging aid, the VRU might also pass a detailed error message string back to the PG in the
Microapp Error Text field. (If the current MicroApplication request is a MICROAPP_PLAY /
MICROAPP_PLAY_CONTINUE set, then it should wait for the last message in the set before sending its
MICROAPP_RESULT.)
Page 67
8.5.4.1.4 Playing Synthesized Speech (Text to Speech)

MEDIA_SPECIFIER fields containing Media Protocol code ‘T’ (for Text) designate Text -to-Speech synthesis.
The VRU should simply pass the contents of the Text String field to its Text -to-Speech synthesizer. If the VRU
does not support Text -to-Speech, it should return a MICROAPP_RESULT message with the Microapp Error
Code set to MICROAPP_E_MEDIA_PROTOCOL.
8.5.4.1.5 Using Non-Voice Media and Protocols

The ICM MicroApplication capabilities are designed to interact with VRU-like devices which can work with
other media besides voice. One such device is a web browser, which can access and render many different
kinds of file formats, based only on the format and content of a web address, or URL. For example, a URL
containing the protocol string HTTP: and file type .wav would cause the web browser to play a Windows wav-
format file. Change the file type to .jpg, and the browser would display an image. Change the protocol string to
RTSP:, and the browser would play streaming media.
As described in Section 8.5.4.1.2 above, a Media URL may reference any web address, and any
MEDIA_SPECIFIER may specify a Media URL. The file type would be embedded in the MEDIA_SPECIFIER’s
Filename field, and the protocol would be selected by the Media Protocol field. Media Protocols which are not
on the intrinsically supported list (HTTP, RTSP, or FILE) are handled via a Media Protocol of OTHER. In that
case, the actual URL protocol string may be found in the MICROAPP_CONTEXT message, as an explicit prefix
to the Media Server Set field.
8.5.4.2 Using Automatic Speech Recognition (ASR)

The MICROAPP_MENU and MICROAPP_COLLECT_DATA MicroApplication requests each contain two
ASR-related fields: a Boolean which indicates whether ASR is enabled, and a text string which contains the
ASR grammar. These fields come directly from the corresponding Script Editor nodes, and are filled in by the
script designer.
If the VRU supports ASR, then these fields should be used to indicate that the caller is allowed to speak his
answer to the Menu or CollectData prompt, in addition to possibly entering it with touch-tone keys. The
grammar string is completely arbitrary, and is up to the VRU to interpret. If a recognition or other ASR-related
error occurs, the VRU should return a MICROAPP_RESULT message with the Microapp Error Code set to
MICROAPP_E_RECOGNITION.
If the VRU does not support ASR, it should simply ignore these fields, and continue with data entry using
touch-tone only.
8.5.4.3 MicroApplication Message Flow

MicroApplication messages are very much like VRU script messages. Most notably, MicroApplication
requests can be sent to the VRU any time RUN_SCRIPT_REQuests can be sent to the VRU (as long as the VRU
has initialized Service Control with FEATURE_RUN_MICROAPP). The VRU’s job is to execute the request,
and respond with a MICROAPP_RESULT message. It can also receive CANCEL requests during the execution
of a MicroApplication (see Section 8.5.3.4 above for information on how to handle CANCEL requests).
However, there are some additional subtleties with respect to certain specific messages which need to be
considered. These are described below.
MICROAPP_CONTEXT. A MICROAPP_CONTEXT message is always delivered to the VRU near the
beginning of a dialogue, ahead of any other MicroApplication request. The values contained in that message
are usually good for the life of the dialogue; however the script designer may choose to change some of those
values by placing additional Set VRU Data nodes into the ICM routing script. In that case, the VRU may
receive subsequent MICROAPP_CONTEXT messages. With each such message it should discard the
information it had saved from the prior message, and replace it with the contents of the new message. Each
MICROAPP_CONTEXT message always contains all fields.
Page 68
MICROAPP_PLAY and MICROAPP_PLAY_CONTINUE. A MICROAPP_PLAY message contains among

other things a list of up to five MEDIA_SPECIFIERS, whose contents are to be played to the caller. However,
there is no such limit in the Play Script Editor node. The ICM script designer may enter six, ten, even 50 items to
play, mixing and matching prompts with data of various formats, all within the same Play node.
To accommodate this flexibility, there is a continuation message, and a to-be-continued flag. If more than five
MEDIA_SPECIFIERS are to be played, the VRU will see one MICROAPP_PLAY message, followed by one or
more MICROAPP_PLAY_CONTINUE messages (each of which may each contain up to 15 more
MEDIA_SPECIFIERS). Both of these message types contain a to-be-continued flag. Only the last message in
the set will have this flag set to FALSE. The ICM Router automatically divides long lists of
MEDIA_SPECIFIERS into multiple MICROAPP_PLAY and MICROAPP_PLAY_CONTINUE messages, and
automatically sets the to-be-continued flag as necessary.
The VRU should consider a PLAY/CONTINUE sequence of messages as an atomic message set. It could begin
playing MEDIA_SPECIFIERS as soon as it receives the first MICROAPP_PLAY message, and continue until it
has finished processing all specifiers received, but it should only send back a single MICROAPP_RESULT
message, and should only do so at the end of the set. Even if an error is encountered early in the sequence, the
VRU must wait for the entire set to be received before it sends its MICROAPP_RESULT.
MICROAPP_MENU and MICROAPP_COLLECT_DATA. The message flow associated with these messages
is straightforward, and directly parallels that of VRU script messages. The VRU receives the request, processes
it, and sends back a MICROAPP_RESULT message.
8.5.5 Service Control Messages

The Service Control Interface introduces a number of new messages to the VRU interface. All Service Control
Interface messages have a message type of SERVICE _CONTROL. The new messages introduce the notion of a
message subtype that is contained in a new Service Control message header. The Service Control message
header contains the values that are common to all Service Control operations.
The Service Control message header will follow the message header when formatting messages. The length of
the Service Control message header should be included when calculating the message length. The
MessageSubType field will be used to identify the Service Control message that follows. The DialogueID field
will be used to identify the dialogue to which the message belongs. The SendSeqNo field provides a sequence
number for all messages sent under the context of a given dialogue. The SendSeqNo will initially begin at one
and increment by one for each message sent by a given dialogue participant within the context of a given
dialogue. All messages received on a given dialogue will be ordered with respect to the SendSeqNo value.
The receiver should verify that the SendSeqNo value is valid prior to processing the message.
MessageSubType The subtype of the Service Control message. (see Table UINT 4
57, “Service Control Message Sub-Types”, below)
DialogueID The dialogue ID to which the message belongs. UINT 4
SendSeqNo The send sequence for the sent message. UINT 4
Table 56. Service Control Message Header (SERVICEHDR) Format
Implementation Note: For messages sent outside the context of a particular dialogue the DialogueID and the
SendSeqNo fields of the ServiceControlHeader must both be set to NULL_DATA_ELEMENT.
Message SubType # Purpose
Page 69
INIT_SERVICE_CTRL_REQ 1 Request to begin Service Control initialization.

INIT_SERVICE_CTRL_CONF 2 Confirmation of INIT_SERVICE_CTRL_REQ.
INIT_SERVICE_CTRL_DATA 3 Service Control Interface initialization data message.
INIT_SERVICE_CTRL_END 4 Service Control Interface initialization termination message.
NEW_CALL 5 Notification that a Service Control dialogue should be created
for a call with no active ICM script.
REQUEST_INSTRUCTION 6 Notification that a Service Control dialogue should be created
for a call that has an active ICM script.
RUN_SCRIPT_REQ 7 Request to run the specified VRU script.
RUN_SCRIPT_RESULT 8 Results obtained by the previous RUN_SCRIPT_REQ request.
CONNECT 9 Instructs the VRU to disconnect the outgoing leg, if any, of an
existing call, and connect the call to the specified destination.
EVENT_REPORT 10 Notification that a call with an active Service Control dialogue
has disconnected, been answered, or received a busy
indication.
DIALOGUE_FAILURE_CONF 11 Notification that failure occurred attempting to process the
request identified by the InvokeID.
DIALOGUE_FAILURE_EVENT 12 Notification that a dialogue has terminated due to an error.
INIT_SERVICE_CTRL_TRKGRP 13 Initialize a trunk group for use with the Service Control
Interface.
INIT_SERVICE_CTRL_SERVICE 14 Initialize a VRU service for use with the Service Control
Interface.
INIT_SERVICE_CTRL_VRU 15 Initialize VRU Data for use with the Service Control Interface.
TRKGRP_STATUS 16 Notification that one or more trunks within a given trunk group
has undergone a status change.
SERVICE_STATUS 17 Notification that a given service has undergone a status
change.
VRU_STATUS 18 Notification that the VRU data has changed.
CANCEL 19 Requests that the VRU cancel a previously requested
operation.
RELEASE 20 Instructs the VRU to release the call associated with the given
dialogue.
NEW_DIALOGUE 21 Instructs the PG to convert an existing Event Data Feed call
into a Service Control Interface dialogue.
CONNECT_TO_RESOURCE 22 Instructs the VRU to disconnect the outgoing leg, if any, of an
existing call and prepare to accept a possible
RUN_SCRIPT_REQ or other VRU operation. The VRU
responds with RESOURCE_CONNECTED
RESOURCE_CONNECTED 23 Tells the PG that the VRU has finished processing a
CONNECT_TO_RESOURCE message and is ready to accept a
RUN_SCRIPT_REQ or other VRU operation.
Page 70
MICROAPP_CONTEXT 24 Set persistent values for subsequent MicroApplication

requests
MICROAPP_PLAY 25 Request to run a PLAY MicroApplication
MICROAPP_PLAY_CONTINUE 26 Provides additional Media Specifiers for a PLA Y
MicroApplication
MICROAPP_COLLECT_DATA 27 Request to run a COLLECT_DATA MicroApplication
MICROAPP_MENU 28 Request to run a MENU MicroApplication
MICROAPP_RESULT 29 Results obtained by the previous MicroApplication request
TEMPORARY_CONNECT 30 Instructs the VRU to disconnect the outgoing leg, if any, of an
existing call, and temporarily connect the call to the specified
destination. This message is used when the services of an
alternate VRU are required.
Table 57. Service Control Message Sub-Types
8.5.5.1 Service Control Interface Initialization Messages
8.5.5.1.1 INIT_SERVICE_CTRL_REQ Message (PG to VRU)

The INIT_SERVICE_CTRL_REQ message is sent by the VRU PG to initialize the Service Control Interface. The
DialogueID and the SendSeqNo fields of the ServiceControlHeader will both be set to
NULL_DATA_ELEMENT. The VRU should respond with an INIT_SERVICE_CTRL_CONF message. If the
VRU is not ready or not able to initialize service control, it can simply ignore the request and wait for another
one.

ServiceControlHeader Standard Service Control message header. SERVICEHDR 12
MessageSubType = 1
InvokeID An ID for this request that will be returned in the UINT 4
corresponding response messages.
Table 58. INIT_SERVICE_CTRL_REQ Message Format
8.5.5.1.2 INIT_SERVICE_CTRL_CONF Message (VRU to PG)

The INIT_SERVICE_CTRL_CONF message is sent by the VRU to positively acknowledge the request to
initialize the Service Control Interface. Following this message, the VRU will send
INIT_SERVICE_CTRL_DATA messages. In the event a INIT_SERVICE_CTRL_CONF message is received and
initialization is not in progress, the dialogue will be terminated by a DIALOGUE_FAILURE_EVENT with a
status code of E_INVALID_INVOKEID. The DialogueID and the SendSeqNo fields of the
ServiceControlHeader must both be set to NULL_DATA_ELEMENT.
Page 71

MessageSubType = 2
corresponding INIT_SERVICE_CTRL_REQ
message.
Table 59. INIT_SERVICE_CTRL_CONF Message Format
8.5.5.1.3 INIT_SERVICE_CTRL_DATA Message (VRU to PG)

The INIT_SERVICE_CTRL_DATA message is sent by the VRU following the INIT_SERVICE_CTRL_CONF to
provide initialization data to the VRU PG. The VRU PG will start a timer after receiving a
INIT_SERVICE_CTRL_CONF message and a INIT_SERVICE_CTRL_DATA must arrive before the timer
expires. If VRU fails to provide a INIT_SERVICE_DATA message before the timer expires, the VRU PG will
send a DIALOGUE_FAILURE_EVENT containing a status code of E_TIMEOUT. The DialogueID and the
SendSeqNo fields of the ServiceControlHeader will both be set to NULL_DATA_ELEMENT. In the event a
INIT_SERVICE_CTRL_DATA message is received while initialization is not in progress, or with an InvokeID
which does not match that of a prior INIT_SERVICE_CTRL_REQ message, the message will be ignored by the
VRU PG.

MessageSubType = 3
message.
ServiceFeatures A bit mask that is a logical OR of the Service Control UINT 4
features supported by the VRU. See Table 61 for
individual feature bit masks.
Table 60. INIT_SERVICE_CTRL_DATA Message Format
Feature Mask Description

FEATURE_RUN_SCRIPT 0x00000001 Indicates the VRU supports the run script feature.
FEATURE_CONNECT 0x00000002 Indicates the VRU supports connect instructions to retarget
calls.
FEATURE_CANCEL 0x00000004 Indicates the VRU supports the cancel request operation.
FEATURE_RELEASE 0x00000008 Indicates the VRU supports the release call operation.
FEATURE_BLIND_TRANSFER 0x00000010 Indicates the VRU supports the blind transfer operation (a
CONNECT, CONNECT_TO_RESOURCE, or
Page 72
CONNECT, CONNECT_TO_RESOURCE, or
TEMPORARY_CONNECT arriving while already
connected). To do so, the VRU must have the capability of
retaining call control even after it has connected the call to a
destination.
FEATURE_NEED_RELEASE 0x00000020 Indicates the VRU needs to have the destination of the
outgoing leg release the call (go On-Hook) before it can
complete a blind transfer operation.
FEATURE_RUN_MICROAPP 0x00000040 Indicates the VRU is capable of executing MicroApplication
request.
Table 61. Supported Service Feature Bit Masks
8.5.5.1.4 INIT_SERVICE_CTRL_TRKGRP Message (VRU to PG)

The INIT_SERVICE_CTRL_TRKGRP message is sent by the VRU during the optional initialization segment of
the Service Control initialization sequence. The VRU should send an INIT_SERVICE_CTRL_TRKGRP message
for each trunk group on the VRU to be initialized. Failure to initialize all trunk groups configured in the ICM
database may result in inaccurate trunk group real-time data at PG startup. The DialogueID and the SendSeqNo
fields of the ServiceControlHeader must both be set to NULL_DATA_ELEMENT. In the event a
INIT_SERVICE_CTRL_TRKGRP message is received while initialization is not in progress, or with an InvokeID
VRU PG.
Page 73

ServiceControlHeader Standard Service Control message header. SERVICEH 12
DR
MessageSubType =13
message.
TrunkGroupID An ID assigned by the VRU to this trunk group, UINT 4
TrunkCount The number of trunks, t, configured in this UINT 4
message. TrunkCount may not exceed 1024
because the total number of trunks in a trunk
group may not exceed 1024.
TrunkNumber1 The trunk number of the first trunk. USHORT 2
TrunkStatus1 The current status of the first trunk in the trunk USHORT 2
group. (See Table 28 for status definitions)
... ... ... ...
TrunkNumbert The trunk number of the last trunk. USHORT 2
TrunkStatust The current status of the last trunk in the trunk USHORT 2
group.
Table 62. INIT_SERVICE_CTRL_TRKGRP Message Format
8.5.5.1.5 INIT_SERVICE_CTRL_SERVICE Message (VRU to PG)

The INIT_SERVICE_CTRL_SERVICE message is sent by the VRU during the optional initialization segment of
the Service Control initialization sequence. The VRU should send an INIT_SERVICE_CTRL_SERVICE message
for each service on the VRU to be initialized. Failure to initialize all services configured in the ICM database
may result in inaccurate service real-time data at PG startup. The DialogueID and the SendSeqNo fields of the
ServiceControlHeader must both be set to NULL_DATA_ELEMENT. In the event a
INIT_SERVICE_CTRL_SERVICE message is received while initialization is not in progress, or with an InvokeID
VRU PG.
Page 74

ServiceControlHeader Standard Service Control message header. SERVICEH 12
MessageSubType = 14 DR
corresponding INIT_SERVICE_CTRL_REQ message.
ServiceID An ID assigned by the VRU to this service. UINT 4
AvailableNow A flag indicating the current availability of the BOOL 4
service.
CallsInNow The number of inbound calls currently in progress on UINT 4
the service.
CallsOutNow The number of outbound calls currently in progress UINT 4
on the service.
Table 63. INIT_SERVICE_CTRL_SERVICE Message Format
8.5.5.1.6 INIT_SERVICE_CTRL_VRU Message (VRU to PG)

The INIT_SERVICE_CTRL_VRU message is sent by the VRU during the initialization segment of the Service
Control initialization sequence. Failure to initialize the VRU data may result in inaccurate peripheral real-time
data at PG startup. The DialogueID and the SendSeqNo fields of the ServiceControlHeader must both be set to
NULL_DATA_ELEMENT. In the event a INIT_SERVICE_CTRL_VRU message is received while initialization is
not in progress, or with an InvokeID which does not match that of a prior INIT_SERVICE_CTRL_REQ message,
the message will be ignored by the VRU PG.
Page 75

Size
MessageSubType = 15
message.
CurrentTime The current UTC time according to the VRU clock TIME 4
(sending NULL_DATA_ELEMENT for the
CurrentTime element will default to the PG clock).
TimeZoneDelta The current local time zone delta, expressed in INT 4
seconds. This value is added to a UTC time to
form a time in the local time zone.
0: Normal Operation
processing
... ... ... ...
Table 64. INIT_SERVICE_CTRL_VRU Message Format
8.5.5.1.7 INIT_SERVICE_CTRL_END Message (VRU to PG)

The INIT_SERVICE_CTRL_END message is sent by the VRU to signify that all initialization data has now been
sent. The DialogueID and the SendSeqNo fields of the ServiceControlHeader must both be set to
NULL_DATA_ELEMENT. Following this message, the VRU will send NEW_CALL or
REQUEST_INSTRUCTION messages to initiate the creation of Service Control dialogues. If the VRU PG
receives an INIT_SERVICE_CTRL_END message while initialization is not in progress, or with an InvokeID
VRU PG. Eventually, if an acceptable INIT_SERVICE_CTRL_END message is not received within a defined time
limit, the VRU PG will terminate the initialization sequence and begin again.
Page 76

MessageSubType = 4
message.
Table 65. INIT_SERVICE_CTRL_END Message Format
8.5.5.2 Service Control Interface Status Reporting Messages
8.5.5.2.1 TRUNK_GROUP_STATUS Message (VRU to PG)

The TRKGRP_STATUS message is sent by the VRU to signify that a trunk or a set of trunks has either come
into service, or been removed from service for a given trunk group. The Service Control Interface initialization
sequence must have completed prior to the VRU sending a TRKGRP_STATUS message. Following this
message, the VRU PG will update the appropriate trunk group and trunk objects in order to report the change in
the Trunk Group Real-time report. The DialogueID and the SendSeqNo fields of the ServiceControlHeader
must both be set to NULL_DATA_ELEMENT.
When a trunk is brought into service, its state is initially TRUNK_IDLE (See Table 28. Trunk Status
Definitions). When a trunk is removed from service, the ICM assumes that any call in progress on that trunk is
cleared.
MessageSubType = 16
TrunkGroupID The ID of the trunk group affected, in the range 0 to UINT 4
65535.
TrunkCount The number of trunks, t, affected. May not exceed UINT 4
1024.
InService A flag indicating that the affected trunks have been BOOL 4
placed into service (TRUE) or removed from service
(FALSE).
TrunkNumber1 The number of the first affected trunk. UINT 4
…
TrunkNumbert The number of the last affected trunk. UINT 4
Table 66. TRKGRP_STATUS Message Format
Page 77
8.5.5.2.2 SERVICE_STATUS Message (VRU to PG)

The SERVICE_STATUS message is sent by the VRU to signify that a service has either come into service, or
been removed from service. The Service Control Interface initialization sequence must have completed prior to
the VRU sending a SERVICE_STATUS message. Following this message, the VRU PG will update the
appropriate service object in order to report statistics on the service via a Service Real-time report. The
DialogueID and the SendSeqNo fields of the ServiceControlHeader must both be set to
NULL_DATA_ELEMENT.
MessageHeader Standard message header. MHDR 8
MessageType = 47.
ServiceControlHeader Standard Service Control message SERVICEHDR 12
header.
MessageSubType = 17
ServiceID The ID of the service affected. UINT 4
ServiceAvailable A flag indicating that the service has UINT 4
become available (TRUE) or unavailable
(FALSE).
Table 67. SERVICE_STATUS Message Format
Page 78
8.5.5.2.3 VRU_STATUS Message (VRU to PG)

The VRU_STATUS message is sent by the VRU to update the peripheral real-time data. The Service Control
Interface initialization sequence must have completed prior to the VRU sending a VRU_STATUS message.
Following this message, the VRU PG will update its view of the peripheral real-time data. Periodically, the PG
view of the peripheral real-time data will be sent to the ICM Router in order to update the ICM Database
Peripheral Real-time schema element. Note that a VRU_STATUS message should be sent each time the VRU
clock crosses a minute boundary in order to keep the VRU and PG clocks synchronized (ex. 12:00:00, 12:01:00,
12:02:00, …..). The DialogueID and the SendSeqNo fields of the ServiceControlHeader must both be set to
NULL_DATA_ELEMENT.
Size
ServiceControlHeader Standard Service Control message header. SERVICEHD 12
R
MessageSubType = 18
CurrentTime The current UTC time according to the VRU clock TIME 4
(sending NULL_DATA_ELEMENT for the
CurrentTime element will default to the PG clock).
TimeZoneDelta The current local time zone delta expressed in INT 4
seconds. This value is added to a UTC time to
form a time in the local time zone.
0: Normal Operation
processing
... ... ... ...
Table 61. VRU_STATUS Message Format
8.5.5.3 NEW_CALL Message (VRU to PG)

The NEW_CALL message is sent by the VRU to establish a Service Control dialogue that is not currently under
ICM Script control. After sending a NEW_CALL message, the VRU should await instruction from the ICM
Router. If the dialogue fails for any reason, including a case where the ICM Router fails to provide instruction
within a reasonable amount of time, the VRU should perform default call handling operations. The VRU should
send a DIALOGUE_FAILURE_EVENT with a status code of E_TIMEOUT to indicate that the dialogue has
been terminated abnormally.
The DialedNumber field is required to be present in a NEW_CALL message. The specified number is used to
determine the ICM call type in turn is used to select an active script. If the DialedNumber is not present in a
NEW_CALL message, a DIALOGUE_FAILURE_EVENT will be sent to terminate the dialogue with a status
code of E_INVALID_MESSAGE. If the DialedNumber is not configured in the ICM, a
Page 79
DIALOGUE_FAILURE_EVENT will be sent to terminate the dialogue with a status code of

E_INVALID_DIALED_NUMBER.
The ANI, CallerEnteredDigits, UserToUserInfo, CalledNumber, and DNIS fields are optional elements since a
given trunk group/network configuration may provide a subset of these values. The VRU implementation must
populate all the fields as provided by the network without modification.
The optional CallVariable fields allow the VRU to pass call information to the ICM Script to be used in the call
handling decision making process.
In the event that the ICM Router can not provide instructions because a script is not active for the given call
type, a DIALOGUE_FAILURE_EVENT will be sent to the VRU with a status code of E_NO_SCRIPT.
In all other fatal error cases a DIALOGUE_FAILURE_EVENT will be sent to terminate the dialogue with a status
code of E_UNSPECIFIED_FAILURE.
Page 80
Fixed Part
Size
MessageSubType = 5
Floating Part
Size
DialedNumber The number used to determine the ICM Call Type. STRING 32
(Required)
ANI The calling line ID of the caller. STRING 40
(optional)
CallerEnteredDigits Digits gathered from the caller by network prompts.. STRING 40
(optional)
(optional)
CalledNumber The complete called number if available from the STRING 32
(optional) network.
DNIS The DNIS provided with the call. STRING 32
(optional)
CallVariable1 (optional) Additional VRU information to be used when STRING 40
running the ICM script.
... ... ... ...
CallVariable10 Additional VRU information to be used when STRING 40
(optional) running the ICM script.
ECC Value Call-related data ExpCallVarValue or 215
ExpCallVarArray
(optional)
… … … …
ExpCallVarArray
(optional)
Table 68. NEW_CALL Message Format
Page 81
8.5.5.4 REQUEST_INSTRUCTION Message (VRU to PG)

The REQUEST_INSTRUCTION message is sent by the VRU to establish a Service Control dialogue for a call
that is already under ICM Script control. After sending a REQUEST_INSTRUCTION message, the VRU should
await instruction from the ICM Router. If the dialogue fails for any reason, including a case where the ICM
Router fails to provide instruction within a reasonable amount of time, the VRU should perform default call
handling operations. The VRU should send a DIALOGUE_FAILURE_EVENT with a status code of
E_TIMEOUT to indicate that the dialogue has been terminated abnormally.
The optional CorrelationID may be used in cases where the value is explicitly delivered by the network to an in
network VRU. In other cases, or if the VRU is located on the customer side of the network demarcation, the
CorrelationID should not be used.
The ANI, UserToUserInfo, CalledNumber, and DNIS fields are optional elements since a given trunk
group/network configuration may provide a subset of these values. The VRU implementation must populate all
the fields as provided by the network without modification.
The VRU should send a DIALOGUE_FAILURE_EVENT with a status code of E_TIMEOUT to indicate that the
dialogue has been terminated abnormally if the ICM Router fails to respond in a timely fashion.
In the event that the ICM Router can not provide instructions because a script is not active for the given call
type, a DIALOGUE_FAILURE_EVENT will be sent to the VRU with a status code of E_NO_SCRIPT.
In all other fatal error cases a DIALOGUE_FAILURE_EVENT will be sent to terminate the dialogue with a status
code of E_UNSPECIFIED_FAILURE.
Page 82
Fixed Part
MessageSubType = 6
Floating Part
(optional)
(optional)
CalledNumber The complete called number if available from the STRING 32
(optional) network.
DNIS The DNIS provided with the call. STRING 32
(optional)
CorrelationID The CorrelationID as provided by an INAP network. STRING 40
(optional)
Table 69. REQUEST_INSTRUCTION Message Format
8.5.5.5 RUN_SCRIPT_REQ Message (PG to VRU)

Enabled by the FEATURE_RUN_SCRIPT flag in the ServiceFeatures field of INIT_SERVICE_CTRL_DATA.
The RUN_SCRIPT_REQ message is sent by the ICM Router to instruct the VRU to run the specified script. The
VRU will run the specified script and respond with either a RUN_SCRIPT_RESULT message or a
DIALOGUE_FAILURE_CONF message.
The RUN_SCRIPT_REQ message can be used to optionally provide script parameters to the VRU to specify
options within the script. The options can be static or dynamic in nature. A static option will apply to
RUN_SCRIPT_REQ messages, while a dynamic option can be applied to a particular run script request.
Static parameters will be set when configuring a script in the ICM. The contents of the script Configuration
String will be sent to the VRU in the ScriptConfiguration field. This configuration string specified in the ICM
configuration may be null in which case the element will be specified with a length of zero.
The ANI and CED fields allow the ICM router to share information with the VRU it may have obtained from the
network when the call was originally pre-routed by the ICM Router. These fields are optional and will only be
populated if so specified by the ICM Script.
Page 83
Dynamic parameters can be specified on a call by call basis via an ICM Script in the optional call variable fields.
The ICM Script running on the ICM Router may populate these values to provide supplemental information to
the VRU when executing the script. The VRU interface does not define the use of these values so care must be
taken to ensure that the ICM Script populating these values is compatible with the VRU. If the VRU is unable to
process the run script request due to an error in the call variable fields, a DIALOGUE_FAILURE_CONF
message should be sent by the VRU identifying the problematic variable (E_CALL_VARIABLE1 …
E_CALL_VARIABLE10).
Fixed Part
MessageSubType = 7
InvokeID An ID for this request message that will be UINT 4
returned in the corresponding result message.
Floating Part
ScriptID The ID of the script to run on the VRU. STRING 40
(Required)
ScriptConfiguration A configuration string configured in the ICM to STRING 40
select static script options.
(Required)
(optional)
CallVariable1 (optional) Additional information passed to the VRU to be STRING 40
used when running the script.
... ... ... ...
CallVariable10 Additional information passed to the VRU to be STRING 40
(optional) used when running the script.
ExpCallVarArray
(optional)
… … … …
ExpCallVarArray
(optional)
Table 70. RUN_SCRIPT_REQ Message Format
8.5.5.6 RUN_SCRIPT_RESULT Message (VRU to PG)

The RUN_SCRIPT_RESULT message is sent by the VRU to inform the ICM Router that the specified script has
been run successfully. The RUN_SCRIPT_RESULT message may optionally place script results in the call
variable fields and collected digits in the CED field. Note that all call variables for this dialogue will be
Page 84
overwritten in the ICM Router’s memory based on the values in these fields. Therefore, if the VRU should be
sure to return all the variables which it received in the RUN_SCRIPT_REQ message, only changing those which
it needs to modify.
The InvokeID contained in the RUN_SCRIPT_RESULT message must match the InvokeID specified in the
RUN_SCRIPT_REQ message. If an invalid InvokeID is specified in the RUN_SCRIPT_RESULT message, a
DIALOGUE_FAILURE_EVENT message will be sent to the offending VRU with an error code of
E_INVALID_INVOKEID.
The ResultCode field should be set to TRUE (1) when the VRU successfully completes a script without error. A
FALSE value (0) indicates that the VRU detected an error while running the script. The VRU may return error
information in the call variables to be examined by the ICM Script.
If the specified script is not known to the VRU, a DIALOGUE_FAILURE_CONF should be sent with a status
code of E_INVALID_SCRIPT.
If the DialogueID specified in the RUN_SCRIPT_REQ message is not under Service Control or no longer
connected to the VRU, a DIALOGUE_FAILURE_EVENT should be sent with a status code of
E_INVALID_DIALOGUEID.
Page 85
Fixed Part
MessageSubType = 8
InvokeID Set to the same value as the InvokeID of the UNIT 4
corresponding RUN_SCRIPT_REQ message.
ResultCode Set to TRUE (1) if no errors were encountered BOOL 4
actually running the script and FALSE (0) if an
error was encountered.
Floating Part
NewTransaction Set to TRUE (non-zero) if the VRU PIM should BOOL 4
(optional) write a Call Termination Record into the database
immediately after processing this message.
CallVariable1 (optional) Additional information related to the call. STRING 40
... ... ... ...
(optional)
ExpCallVarArray
(optional)
… … … …
ExpCallVarArray
(optional)
Table 71. RUN_SCRIPT_RESULT Message Format
8.5.5.7 MICROAPP_CONTEXT (PG to VRU)

Enabled by the FEATURE_RUN_MICROAPP flag in the ServiceFeatures field of
INIT_SERVICE_CTRL_DATA.
The MICROAPP_CONTEXT message is sent by the ICM Router prior to the first MicroApplication request in a
dialogue. It is valid for the life of the dialogue. The VRU should simply store the fields it receives, for use in
interpreting any subsequent MicroApplication requests with the same dialogue ID. It may receive additional
MICROAPP_CONTEXT messages as well. The VRU should simply replace its stored values with the new
values, and use the new values with any MicroApplication requests which follow.
For example, suppose a MICROAPP_CONTEXT message sets the CustomerID field to “AcmeManufacturing”,
and a subsequent MICROAPP_PLAY message contains an HTTP media specifier with a filename of
“welcome.wav”. The VRU might then act on the media specifier by playing the media file
“HTTP://AcmeManufacturing/welcome.wav”. If a later MICROAPP_PLAY message contains an HTTP media
Page 86
specifier with a filename of “goodbye.wav”, then the VRU would play the media file
“HTTP://AcmeManufacturing/goodbye.wav”.
Note that all fields in the MICROAPP_CONTEXT message are required fields. Therefore, if the ICM Router
wishes to change the setting for any one field, it must send all the fields again. For additional information about
the structure of these fields, see Section 4.
There is no VRU response to a MICROAPP_CONTEXT message.
Fixed Part
MessageSubType = 24
Floating Part
CustomerID String identifying the requesting customer in STRING(255) 255
(required) multi-tenant configurations
Media-server set IP address or DNS name, optionally this is the STRING(255) 255
(required) root URL of the media files.
Locale One of: “en_US”, or “en_GB”. If supported by STRING(10) 10
(required) the VRU, additional Locales may be added to
the ICM Locale configuration table and may
appear here.
System media library Library of media files/prompts for individual STRING(255) 255
(required) digits, months, default error messages, etc.
Application-specific prompts should not be
stored in this library. The full set of
media/prompts needs to be created/ recorded
for each locale referenced.
Application media Library of media files/prompts specific to a set STRING(255) 255
library of related ICM scripts. This set of
(required) media/prompts needs to be created/recorded for
each locale referenced.
Currency Currency to use, such as “dollar”. If supported STRING(10) 10
(required) by the VRU, additional Currencies may be
added to the ICM Currency configuration table
and may appear here.
Table 72. MICROAPP_CONTEXT Message Format
Page 87
8.5.5.8 MICROAPP_PLAY (PG to VRU)

The MICROAPP_PLAY message is sent by the ICM Router to instruct the VRU to play a list of Media
Specifiers. The VRU will perform the specified action and respond with a MICROAPP_RESULT message.
Note that the Media Specifier field is a tagged message element which can appear zero or more times in this
message. Successive Media Specifier elements are taken to mean that they should be played to the caller in the
order in which they appear. There is no specific maximum number of such fields; however note that the ICM
message communication mechanism imposes an architectural limit of 4k bytes for the entire message. Zero
Media Specifiers means simply that no media should be played. Other processing associated with this request,
if any, should still be executed.
If the number of Media Specifiers requested by the ICM Router would cause the MICROAPP_PLAY message
to grow beyond its maximum size, then the Router will split the request into multiple messages. One
MICROAPP_PLAY message will be followed by one or more MICROAPP_PLAY_CONTINUE messages, which
can carry additional Media Specifiers. All of these messages except the last one will have their ToBeContinued
field set to TRUE. It will be set to FALSE in the last message of the request.
All MICROAPP_PLAY and MICROAPP_PLAY_CONTINUE messages which make up a single
MicroApplication play request will contain the same InvokeID. The VRU may process each message as it
arrives, without waiting for subsequent messages. However it should only send a MICROAPP_RESULT
message after it receives the last one in the sequence; ie., once it receives a MICROAPP_PLAY or
MICROAPP_PLAY_CONTINUE message which has its ToBeContinued field set to FALSE.
Media Specifiers are meant to be interpreted by the VRU within the context of the fields specified by a prior
MICROAPP_CONTEXT message. See Section 8.5.5.7 for more information.
The MICROAPP_PLAY message is formatted as follows. Floating Part message elements may appear in any
order. For detailed information about the structure of these fields, see Section 4.
Fixed Part
MessageSubType = 25
ToBeContinued A flag which indicates whether additional BOOL 4
MICROAPP_PLAY_CONTINUE messages will
follow.
Barge-In Allowed Indicates whether caller is allowed to interrupt BOOL 4
playing. Applies to all media, data fields, and
prompts.
Page 88
Floating Part
Media Specifier Identifies a particular media to play. Can be MEDIA_ SPECIFIER 1-255
(optional) HTTP, File, Streaming, Text -to-Speech, or Data.
Any number of Media Specifier elements may
appear in the message.
… … … …
CallVariable1 through Additional information passed to the VRU to be STRING 40
CallVariable 10 used when running the script.
(optional)
(optional) ExpCallVarArray
… … … …
Table 73. MICROAPP_PLAY Message Format
Page 89
8.5.5.9 MICROAPP_PLAY_CONTINUE (PG to VRU)

The MICROAPP_PLAY_CONTINUE message is sent by the ICM Router to provide more Media Specifiers than
can fit in a single MICROAPP_PLAY message. See Section 8.5.5.8 for more information.
The MICROAPP_PLAY message is formatted as follows. Floating Part message elements may appear in any
order. For detailed information about the structure of these fields, see Section 4.
Fixed Part
MessageSubType = 26
This ID will match the InvokeID of the first
MICROAPP_PLAY message in the current
request.
ToBeContinued A flag which indicates whether additional BOOL 4
MICROAPP_PLAY_CONTINUE messages will
follow.
Floating Part
… … … …
Table 74. MICROAPP_PLAY_CONTINUE Message Format
8.5.5.10 MICROAPP_COLLECT_DATA (PG to VRU)

The MICROAPP_COLLECT_DATA message is sent by the ICM Router to instruct the VRU to run the
COLLECT_DATA MicroApplication, which prompts for and collects input digits. The VRU will perform the
specified action and respond with a MICROAPP_RESULT message.
Floating Part message elements which are listed as (optional) should be taken by the VRU as empty strings if
they do not appear in the message. Floating Part message elements may appear in any order.
Page 90
The Initial Prompt, Timeout Prompt and Invalid Entry Prompt fields are all Media Specifier fields. They are
meant to be interpreted by the VRU within the context of the fields specified by a prior MICROAPP_CONTEXT
message. See Section 8.5.5.7 for more information. Note that these prompts are required fields. However, the
ICM Router may indicate that a particular prompt should not be played by including a NULL specifier in the
corresponding prompt field.
The MICROAPP_COLLECT_DATA message is formatted as follows. For detailed information about the
structure of these fields, see Section 4.
Fixed Part
MessageSubType = 27
DTMF Termination Key Terminates a variable length string of DTMF UINT 4
digits (typically # key). The value is a bit map;
usually only one bit is set, but all bits could be
zero in order to indicate no key is to be
considered a termination key. The special bit
KEY_NONE also means that no key is to be
considered a termination key. See Table 76 for
bit arrangement. This field should be ignored
for fixed length strings; ie., when Minimum
Length and Maximum Length are equal.
No Entry Timeout Determines how many seconds a caller is UINT 4
allowed to start entering data.
Interdigit Timeout Determines how many seconds the caller is UINT 4
allowed between digits, before the system
assumes the caller is finished.
Numb er of No Entry Number of times VRU should repeat the “Get UINT 4
Tries data” cycle when the caller doesn’t enter any
data, where the caller hears the prompt and is
allowed to enter data (including the first time).
Number of Invalid Entry Number of times VRU should repeat the “Get UINT 4
Tries data” cycle when the caller enters invalid data
(including the first time).
Minimum Length Minimum number of digits expected from the UINT 4
caller, not counting a termination key. If
Minimum and Maximum Length are equal, then
a fixed number of keystrokes are expected and
the DTMF Termination Key field should be
ignored.
Page 91
Maximum Length Maximum number of digits expected from the UINT 4

caller, not counting a termination key. If
Minimum and Maximum Length are equal, then
a fixed number of keystrokes are expected and
the DTMF Termination Key field should be
ignored.
prompts.
ASR Allowed Indicates whether Automatic Speech BOOL 4
Recognition should be enabled for this request.
Floating Part
Initial Prompt Prompt to play in order to request caller input. MEDIA_ SPECIFIER 255
(required)
Timeout Prompt Prompt to play upon Interdigit or No-Entry MEDIA_ SPECIFIER 255
(required) Timeout.
Invalid Entry Prompt Prompt to play upon Invalid Entry condition. MEDIA_ SPECIFIER 255
(required)
ASR Grammar Arbitrary string which indicates to the VRU STRING 40
which speech recognition grammar to use, if
speech recognition is enabled.
(optional)
… … … …
Table 75. MICROAPP_COLLECT_DATA Message Format
DTMF Termination Key is a bit map, of which zero or more bits may be set. The following table shows how
these bits are arranged.
Key Bit Mask
KEY_0 0x0001
KEY_1 0x0002
KEY_2 0x0004
KEY_3 0x0008
KEY_4 0x0010
KEY_5 0x0020
KEY_6 0x0040
KEY_7 0x0080
KEY_8 0x0100
Page 92
Key Bit Mask

KEY_9 0x0200
KEY_STAR 0x0400
KEY_POUND 0x0800
KEY_NONE 0x1000
Table 76. Bit Mask Values DTMF Termination Key
8.5.5.11 MICROAPP_MENU (PG to VRU)

The MICROAPP_MENU message is sent by the ICM Router to instruct the VRU to run the MENU
MicroApplication. The VRU should perform the specified action and respond with a MICROAPP_RESULT
message, passing the return keystroke as a single character string in the CED field. For example, if the user
presses zero, the CED field should be populated with the string “0”. If the user presses pound, CED should be
populated with the string “#”. The DTMF Menu Keys field contains a bit mask indicating which keys have
been enabled in the Menu node. The VRU should take care to only return a key from the enabled set; otherwise
the ICM script will exit through the failure branch even if the VRU indicates a successful Microapp Result. The
special menu key mask DTMF_KEYMASK_NONE indicates that the VRU is allowed to return an empty string
in CED. This means the user did not enter any keystroke, and it may be useful when more complicated data is
being returned by the VRU in other fields, such as the call variables.
The Initial Prompt, Timeout Prompt and Invalid Entry Prompt fields are all media specifier fields. They are meant
to be interpreted by the VRU within the context of the fields specified by a prior MICROAPP_CONTEXT
message. See Section 8.5.5.7 for more information. Note that these prompts are required fields, so they will
always be present. However, the ICM Router may indicate that a particular prompt should not be played by
including a NULL specifier in the corresponding prompt field.
The MICROAPP_MENU message is formatted as follows. For detailed information about the structure of these
fields, see Section 4.
Fixed Part
MessageSu bType = 28
No Entry Timeout Determines how many seconds a caller is UINT 4
allowed to start entering data.
Number of No Entry Number of times VRU will repeat the “Get data” UINT 4
Tries cycle when the caller doesn’t enter any data,
where the caller hears the prompt and is allowed
to enter data (including the first time).
Page 93
Number of Invalid Entry Number of times we will repeat the “Get data” UINT 4
Tries cycle when the caller enters invalid data
(including the first time).
DTMF Menu Keys Indicates which keypad keys represent valid UINT 4
menu choices. See Table 76 above for bitmap
definitions.
prompts.
ASR Allowed Indicates whether Automatic Speech BOOL 4
Recognition should be enabled for this request.
Floating Part
Initial Prompt Prompt to play in order to request caller input. MEDIA_ SPECIFIER 255
(required)
Timeout Prompt Prompt to play upon No-Entry Timeout. MEDIA_ SPECIFIER 255
(required)
Invalid Entry Prompt Prompt to play upon Invalid Entry condition. MEDIA_ SPECIFIER 255
(required)
ASR Grammar Arbitrary string which indicates to the VRU STRING 40
which speech recognition grammar to use, if
speech recognition is enabled.
(optional)
… … … …
Table 77. MICROAPP_MENU Message Format
8.5.5.12 MICROAPP_RESULT (VRU to PG)

The MICROAPP_RESULT message is sent by the VRU to inform the ICM Router that the specified
MicroApplication request has completed. The MICROAPP_RESULT message will place collected keystroke
data in the CED field if appropriate, and may update the call variable fields as well. Note that all call variables for
this dialogue will be overwritten in the ICM Router’s memory based on the values in these fields. Therefore,
the VRU should be sure to return all the variables which it received in the MicroApplication request message,
only changing those which it needs to modify.
The InvokeID contained in the MICROAPP_RESULT message must match the InvokeID specified in the
original MICROAPP request message. If an invalid InvokeID is specified in the MICROAPP_RESULT message,
a DIALOGUE_FAILURE_EVENT message will be sent to the offending VRU with an error code of
E_INVALID_INVOKEID.
Page 94
In the case of a sequence of MICROAPP_PLAY and MICROAPP_PLAY_CONTINUE messages which make up

a single MicroApplication play request, only one MICROAPP_RESULT message should be sent by the VRU,
after the VRU has received and processed the entire set.
The Microapp Error Code field affects two ICM Router call variables accessible to the routing script: VRUStatus
and MicroappStatus. If the VRU returns a Microapp Error Code of MICROAPP_E_OK (0), then both variables
will be set to this value, and control in the ICM routing script proceeds through the success branch. If the VRU
returns a Microapp Error Code of 1001 or greater (see Table 79 below), then the routing script will see a
VRUStatus of 1 (MICROAPP_E_ERROR), and the actual returned error code in MicroappStatus. If an error
occurs at the Router level, then the routing script will see both the VRUStatus and the MicroappStatus set to a
value between 1 and 1000. The VRU should never explicitly return a status in this range. Any VRUStatus or
MicroappStatus other than zero causes the routing script to proceed through the failure branch.
If the specified MicroApplication is not known to the VRU, a MICROAPP_RESULT message should be sent by
the VRU with a Microapp Error Code of MICROAPP_E_UNSUPPORTED.
If the DialogueID specified in the MICROAPP_RESULT message is not under Service Control or no longer
connected to the VRU, a DIALOGUE_FAILURE_EVENT will be sent with a status code of
E_INVALID_DIALOGUEID.
Fixed Part
MessageSubType = 29
corresponding RUN_SCRIPT_REQ message.
Microapp Error Code MICROAPP_E_OK = 0 UINT 4
See Table 79 below for additional values.
Floating Part
Microapp Error Text If Microapp Error Code is not STRING 255
MICROAPP_E_OK, then this field may contain
(optional)
additional textual information about the error.
The VRU PIM will include this text in its trace
log, but it will not be stored in the call record.
... ... ... ...
(optional)
ExpCallVarArray
(optional)
Page 95
… … … …
ExpCallVarArray
(optional)
Table 78. MICROAPP_RESULT Message Format
Page 96
Error Code Name Code Meaning

MICROAPP_E_OK 0 Operation was successful
MICROAPP_E_ERROR (*) 1 The MicroApplication script node
encountered an error. This value should
never be provided by the VRU. It is
reserved for the Router’s use only
MICROAPP_E_VRU_TIMED_OUT (*) 2 VRU did not respond to the Router in
time. This value should never be
provided by the VRU. It is reserved for
the Router’s use only
MICROAPP_E_ABORTED (*) 3 MicroApplication request was aborted.
This value should never be provided by
the VRU. It is reserved for the Router’s
use only
MICROAPP_E_DIALOG_FAILED (*) 4 MicroApplication script node terminated
due to a DialogFail message. This value
should never be provided by the VRU. It
is reserved for the Router’s use only
MICROAPP_E_VRU_SCRIPT_NOT_FOUND 5 Not relevant to MicroApplication
(*) requests. Reserved for the Router’s use
only
MICROAPP_E_INTERNAL 1001 A semantic runtime error occurred
MICROAPP_E_MAX_INVALID 1002 Maximum number of invalid entry
attempts was exceeded
MICROAPP_E_MAX_NO_ENTRY 1003 Maximum number of no-entry attempts
was exceeded
MICROAPP_E_MEDIA_PROTOCOL 1004 The Media Protocol field in a Media
Specifier indicated a protocol which is
not supported by the VRU
MICROAPP_E_MEDIA_TYPE 1005 The type of media (usually derived from
the filename extension) indicated in a
Media Specifier is not supported by the
VRU
MICROAPP_E_NETWORK 1006 A network error occurred
MICROAPP_E_NO_MEDIA 1007 The specified media file could not be
found. Could also indicate that any of
the URL components (Locale,
CustomerId, etc.) is incorrect
MICROAPP_E_NUMBER_FORMAT 1008 In a Data Specifier, the value could not
be interpreted relative to the data format
indicated by the Specifier
MICROAPP_E_PARAMETER 1009 An invalid parameter provided by ICM
MICROAPP_E_SYSTEM 1010 A system error occurred
MICROAPP_E_UNSUPPORTED 1011 VRU does not support this
MicroApplication request
MICROAPP_E_DATA_RANGE 1012 A data value was out of range
MICROAPP_E_INTERNAL_TIMEOUT 1013 A timeout occurred
MICROAPP_E_RECOGNITION 1014 A speech recognition failure occurred
MICROAPP_E_OTHER 1999 Some other error occurred. Ideally more
information can be found in the
Microapp Error Text field
Page 97
Table 79. Microapp Error Codes

(*) These error codes are generated only by the ICM Router, not by the VRU. The VRU should
never return an error code less than 1001 except MICROAPP_E_OK (0).
8.5.5.13 CANCEL Message (PG to VRU)

Enabled by the FEATURE_CANCEL flag in the ServiceFeatures field of INIT_SERVICE_CTRL_DATA.
The CANCEL message is sent by the ICM Router to instruct the VRU to cancel a previously requested
RunScript or MicroApplication operation identified by its InvokeID. The VRU will cancel the operation
identified by the InvokeID in the RequestID field and respond with DIALOGUE_FAILURE_CONF message with
an ErrorCode of E_OPERATION_CANCELLED if the operation was successfully cancelled. The InvokeID of
the cancelled operation will be present in the DIALOGUE_FAILURE_CONF message.
In the event the previously requested operation can not be cancelled immediately, a
DIALOGUE_FAILURE_CONF message will be returned with the status code set to
E_OPERATION_NOT_CANCELLED. In this case, the InvokeID in the DIALOGUE_FAILURE_CONF message
will identify the unsuccessful cancel operation. An operation that could not be successfully cancelled should
complete in the usual manner, however it should do so as quickly as possible. See Section 8.5.3.4, “Canceling
Running VRU Scripts or MicroApplications” for a detailed discussion of this topic.
The CANCEL message may be used to terminate call treatment including announcements prior to redirecting a
call to a destination selected by the ICM Router.
If the specified RequestID in the CANCEL message is not active on the VRU for the given dialogue, a
DIALOGUE_FAILURE_CONF should be sent with a status code of E_INVALID_INVOKEID.
If the DialogueID specified in the CANCEL message is not under Service Control or no longer connected to the
VRU, a DIALOGUE_FAILURE_EVENT should be sent with a status code of E_INVALID_DIALOGUEID.
Fixed Part
MessageSubType = 19
InvokeID An ID for this request message that will be returned UINT 4
in the corresponding result message.
RequestID The InvokeID of the previously issued request to be UINT 4
cancelled.
Table 80: CANCEL Message Format
8.5.5.14 CONNECT Message (PG to VRU)

Enabled by the FEATURE_CONNECT flag in the ServiceFeatures field of INIT_SERVICE_CTRL_DATA.
The CONNECT message is sent by the ICM Router to instruct the VRU to CONNECT the specified call to the
destination identified explicitly by the label, or implicitly by the label type. If the VRU is unable to process the
CONNECT message for any reason a DIALOGUE_FAILURE_EVENT message should be sent to the ICM
Router. Note that the VRU should only send a DIALOGUE_FAILURE_EVENT message in cases where the
CONNECT message could not be processed. In all other cases additional status should be sent in
EVENT_REPORT messages that will indicate if the call was answered, busied, or disconnected.
Page 98
The Label message field will be set to a zero length value in cases where the Label type is set to a value of
BUSY, RING, or DEFAULT. Conversely the label should be set to a non-zero length value in all cases where the
Label type is set to a value of NORMAL. If the VRU receives a label of type BUSY or RING, it should if
possible provide busy or ring tone to the caller. Once the caller actually hangs up, the VRU should send an
DISCONNECT EVENT_REPORT to the PG, specifying either BUSY or NO_ANSWER in the CauseCode field.
This guarantees that the event will be reported correctly in the ICM database.
The TransferHint field can appear only if the VRU has indicated that it supports
FEATURE_BLIND_TRANSFER. If this field is present and TRUE, then the VRU should retain call control when
it connects the call to the specified destination. It may do this by bridging the call through via a second VRU
port, or it may ask the switch to connect the call but retain some sort of call key which the VRU can later use to
pull the call back and target it elsewhere. It also should not send a DISCONNECT event to the PG until such
time as the calling party actually hangs up, or the VRU loses control of the call.
Some VRU implementations always retain call control until the calling party actually hangs up. Such VRU’s are
capable of supporting partner Type 8 VRU configurations. These are configurations which use two or more
VRU's: one VRU acts as the call's initial routing client, and its partner, a second VRU configured as a Type 8
Network VRU, is used to perform customary VRU services. If the ICM routing script calls for VRU services,
then the Router sends a CONNECT message to the initial routing client VRU, containing a label which targets
the second VRU. Other than the label itself, this CONNECT message contains no charactistic which identifies
its target as another VRU rather than an ACD or other final target. In particular, the TransferHint flag will not be
set. Once the Router determines a final destination for the call, it sends an additional CONNECT message to the
initial routing client VRU, containing a label which targets that final destination. Therefore, a VRU which wishes
to support partner Type 8 VRU configurations must retain call control following any CONNECT message, until
the original caller hangs up. As with the blind transfer feature, it should only then send a DISCONNECT event
to the PG.
The CONNECT message can optionally provide parameters in the call variable fields. The ICM Script running
on the ICM Router may populate these values to provide supplemental information to the VRU when
connecting the call. The VRU interface does not define the use of these values so care must be taken to ensure
that the ICM Script populating these values is compatible with the VRU.
Page 99
Fixed Part
MessageSubType = 9
LabelType The type of the label returned in the following field. UINT 4
See Table 82 (below) for a description of label
types.
Floating Part
TransferHint Only present if the VRU supports BOOL 4
FEATURE_BLIND_TRANSFER.
(optional)
If present and set to TRUE the VRU PG reserves
the right to send a CONNECT or
CONNECT_TO_RESOURCE message after this
CONNECT.
(optional)
... ... ... ...
(optional)
or
(optional)
ExpCallVarArray
… … … …
or
(optional)
ExpCallVarArray
Table 81. CONNECT Message Format

Label Type Meaning Value
NORMAL The label refers to the destination to which the call should be 1
routed.
BUSY The label indicates that the caller should receive a busy signal. 2
RING The label indicates that the caller should receive ring-no-answer. 3
--- Value Not Supported. 4
DEFAULT The label indicates that the default routing action should be taken. 5
Table 82. Label Types
Page 100
8.5.5.15 RELEASE Message (PG to VRU)

Enabled by the FEATURE_RELEASE flag in the ServiceFeatures field of INIT_SERVICE_CTRL_DATA.
The RELEASE message is sent by the ICM to instruct the VRU to release the call associated with the specified
dialogue. If the VRU is successful in releasing the call it shall send an EVENT_REPORT message that specifies
a DISCONNECT or ABANDON event code. If the VRU is unable to release the call it shall send a
DIALOGUE_FAILURE_EVENT message.
The Cause element of the RELEASE message will indicate the reason that the call was released. The valid
values are:
0: Normal Call Clearing
1: No Route to Destination
The code for No Route to Destination is used when the VRU is unable to connect a call to a destination and no
alternative destinations are known to the ICM. The code for Normal Call Clearing is used for all other
circumstances.
If the DialogueID specified in the RELEASE message is not under Service Control or no longer connected to the
VRU, a DIALOGUE_FAILURE_EVENT will be sent with a status code of E_INVALID_DIALOGUEID.
Fixed Part
MessageSubType = 20
Cause The reason for clearing the call. UINT 4
Table 83: RELEASE Message Format
8.5.5.16 NEW_DIALOGUE Message (VRU to PG)

The NEW_DIALOGUE message (described in Table 84) allows the VRU to convert a call from an Event Data
Feed call to a Service Control Interface dialogue. This can be done any time after the Event Data Feed
“Delivered” event has been sent for the call. Once the call has been converted to a dialogue it should only be
used with Service Control Interface messages and not Event Data Feed or Call Routing Interface messages.
The Service Control Header contains the Dialogue ID of the new Service Control Interface dialogue and the
message contains the Call ID of the existing Event Data Feed call. A termination record will be written for the
Call ID. The same trunk(s) that the old call occupied continue to be occupied by the new dialogue.
A NEW_CALL message is sent to the ICM to trigger the running of an ICM script. The ICM script will perform
the desired Service Control Interface operations such as RUN_SCRIPT_REQ, CONNECT, and RELEASE. The
NEW_CALL message will contain the ServiceID, DialedNumber and UserToUseInfo provided in the
NEW_DIALOGUE message and the TrunkGroupID, TrunkNumber, ANI, DNIS, CallVariable1 through
CallVariable10 and ECC data associated with the Event Data Feed call.
Page 101
Fixed Part
Size
MessageSubType = 21
CallID The ID of the exis ting Event Data Feed call. UINT 4
ServiceID The ID of the service to which the new call is UINT 4
attributed.
Floating Part
Size
DialedNumber The number used to determine the ICM Call Type. STRING 32
(Required)
(optional)
Table 84. NEW_DIALOGUE Message Format
PG VRU
DELIVERED_EVENT
ROUTE_REQUEST_EVENT
Event
Event ROUTE_SELECT Data
Data ROUTE_END Feed
Feed
SET_CALL_VARIABLES_EVENT
NEW_DIALOGUE
RUN_SCRIPT_REQ
Service
SCRIPT_RESULT
Service Control
Control Interface
CONNECT
Interface
EVENT_REPORT
(ANSWERED)
EVENT_REPORT
(DISCONNECT)
Figure 10: NEW_DIALOGUE Example Message Flow
Page 102
8.5.5.17 EVENT_REPORT Message (VRU to PG)

The EVENT_REPORT message is sent by the VRU to indicate call progress events for the dialogue.
EVENT_REPORT messages are asynchronous in nature and may be sent independent of whether a Service
Control request is outstanding. The ICM Router may provide additional instructions to the VRU based on the
receipt of an EVENT_REPORT message.
An EVENT_REPORT message that specifies a CONNECT_FAILURE, BUSY, or NO_ANSWER event code will
signal the failure of a CONNECT request. If the ICM has an alternative destination for the failing CONNECT it
will send a new CONNECT. If the ICM has no further alternative destination for the failing CONNECT and the
VRU supports the Release feature the ICM will send a RELEASE message with a cause code of 1 (No Route to
Destination).
An EVENT_REPORT message that specifies a DISCONNECT or ABANDON event code will cause the dialogue
to terminate. If the DISCONNECT or ABANDON event report includes the optional CauseCode a call
disposition based on the CauseCode (See: Table 34) will be written to the termination call detail record. If the
optional CauseCode field is not supplied, a default call disposition of
DBCD_DROP_HANDLED_PRIMARY_ROUTE is used.
Fixed Part
MessageSubType = 10
EventID A code that identifies the event detected by the VRU. UINT 4
See Table 86 for a list of valid event codes.
Floating Part
Size
CauseCode An optional value that identifies the cause of the UINT 4
event. Currently only the DISCONNECT and
(optional)
ABANDON events make use of the cause code. See
Table 34. Call Cleared Causes for a list of valid cause
codes.
Table 85. EVENT_REPORT Message Format
Page 103
Event Type Code Description

CONNECT_FAILURE 1 Indicates a network failure occurred attempting to connect the call.
BUSY 2 Indicates a BUSY condition at the intended call destination.
NO_ANSWER 3 Indicates the call was ringing at the target destination but not answered
within some unspecified time-out or ring count.
ANSWER 4 Indicates the call has connected to destination.
ABANDON 5 Indicates that the calling party disconnected. This event terminates the
dialogue.
DISCONNECT 6 Indicates that the calling party has disconnected. This event terminates
the dialogue.
Table 86. Event Report Codes
8.5.5.18 DIALOGUE_FAILURE_CONF Message (VRU to PG)

The DIALOGUE_FAILURE_CONF message is sent by the VRU in response to a Service Control request when
the operation can not be performed due to a recoverable failure. The DIALOGUE_FAILURE_CONF message is
considered to be a negative acknowledgment to a Service Control request. Failures in this category will include
errors related to temporarily unavailable resources or configuration mismatch errors. After sending the
DIALOGUE_FAILURE_CONF message, the VRU will await further instruction from the ICM Router. If the ICM
Router fails to provide additional instruction within a reasonable amount of time the VRU should timeout the
dialogue and perform default call handling operations. When dialogues are timed-out, a
DIALOGUE_FAILURE_EVENT should be sent by the VRU to the ICM Router.
The InvokeID contained in the DIALOGUE_FAILURE_CONF message must match the InvokeID specified in
the request message. If an invalid InvokeID is specified in the DIALOGUE_FAILURE_CONF message, the ICM
Router will send a DIALOGUE_FAILURE_EVENT message with an error code of E_INVALID_INVOKEID to
terminate the dialogue.
The ErrorCode field may be used to indicate the cause of the request failure.
MessageSubType = 11
InvokeID Set to the same value as the InvokeID of the UNIT 4
corresponding request message.
ErrorCode A status code indicating the cause of the failure. The UINT 4
possible status codes for each request are defined
with the request message, and summarized in Table
92.
Table 87. DIALOGUE_FAILURE_CONF Message Format
Page 104
8.5.5.19 DIALOGUE_FAILURE_EVENT Message (VRU to PG or PG to VRU)

The DIALOGUE_FAILURE_EVENT message may be sent by either the ICM Router or the VRU to indicate a
dialogue has failed in an unrecoverable fashion. This message may be sent independent of whether or not a
request is outstanding. The DIALOGUE_FAILURE_EVENT terminates a dialogue in all cases.
The ErrorCode field may be used to indicate the cause of the dialogue failure. See Table 92 for ErrorCode
values.
MessageSubType = 12
ErrorCode An error code indicating the cause of the dialogue UINT 4
failure. See Table 92.
Table 88. DIALOGUE_FAILURE_EVENT Message Format
Page 105
8.5.5.20 CONNECT_TO_RESOURCE Message (PG to VRU)

Enabled by the FEA TURE_BLIND_TRANSFER flag in the ServiceFeatures field of
This message will instruct the VRU to disconnect the outgoing leg, if any, of an existing call and prepare to
accept a possible RUN_SCRIPT_REQ. The VRU responds with RESOURCE_CONNECTED.
Fixed Part
MessageSubType = 22
Floating Part
(optional)
... ... ... ...
(optional)
or
(optional)
ExpCallVarArray
… … … …
or
(optional)
ExpCallVarArray
Table 89. CONNECT_TO_RESOURCE Message Format
8.5.5.21 RESOURCE_CONNECTED Message (VRU to PG)

This message will tell the PG that the VRU has finished processing a CONNECT_TO_RESOURCE message and
is ready to accept a RUN_SCRIPT_REQ , CONNECT, RELEASE or CONNECT_TO_RESOURCE message.
MessageSubType = 23
Table 90. RESOURCE_CONNECTED Message Format
Page 106
8.5.5.22 TEMPORARY_CONNECT Message (PG to VRU)

Enabled by the FEATURE_CONNECT flag in the ServiceFeatures field of INIT_SERVICE_CTRL_DATA.
Also, this message only appears in configurations where the VRU is acting as a routing client only, and an
alternate VRU has been configured as the call’s Type 3 or Type 7 NetworkVRU. The routing client VRU will
receive this message when the ICM Router determines that the call requires VRU services, and must therefore
be temporarily connected to a VRU which is capable of those services.
The TEMPORARY_CONNECT message requests the routing client VRU to temporarily connect the call to the
alternate VRU. The routing client VRU should retain call control as it connects the call to the destination
specified by the Label. It may do this by bridging the call through via a second VRU port, or it may ask the
switch to connect the call but retain some sort of call key which it can later use to pull the call back and target it
elsewhere. It also should not send a DISCONNECT event to the PG until such time as the calling party actually
hangs up, or it actually loses control of the call.
The TEMPORARY_CONNECT message contains a required CorrelationID field, which the routing client VRU
must arrange to deliver somehow to the alternate VRU. The alternate VRU will include that CorrelationID in its
REQUEST_INSTRUCTION message to its VRU PG.
If the routing client VRU is not capable of retaining call control as described above, it should send a
DIALOGUE_FAIL_EVENT to the VRU PG. Otherwise, it should attempt to connect the call as requested, and
respond to the VRU PG with an EVENT_REPORT of type ANSWERED if successful, or BUSY, NO_ANSWER
or CONNECT_FAILURE otherwise. The ICM may send subsequent TEMPORARY_CONNECT messages if
additional destinations are available. If the routing client VRU cannot ascertain whether the call was
successfully connected to the alternate VRU, it should assume success and send the ANSWERED event
immediately.
Once the ICM Router has completed its business at the alternate VRU, it will send a RELEASE, a CONNECT, or
another TEMPORARY_CONNECT message to the routing client VRU, which should then pull the call back from
the alternate VRU and process the new message as indicated.
Page 107

MessageSubType = 30
Floating Part
Size
CorrelationID An identifying string which must be passed STRING 40
through to the receiving VRU.
(required)
... ... ... ...
(optional)
or
(optional)
ExpCallVarArray
… … … …
or
(optional)
ExpCallVarArray
Table 91. TEMPORARY_CONNECT Message Format
8.5.6 Service Control Dialogue state machine

Bold lines show the most common state transitions.
Abbreviations:
• DFC = DIALOGUE_FAILURE_CONF
• ER/CF = EVENT_REPORT / CONNECT_FAILURE
• ER/BUSY = EVENT_REPORT / BUSY
• ER/NA = EVENT_REPORT / NO_ANSWER
• ER/ANS = EVENT_REPORT / ANSWER
• ER/ABAND = EVENT_REPORT / ABANDON
• ER/DISCON = EVENT_REPORT / DISCONNECT
Page 108
IDLE
<9>
<1> Caller Disconnects
<4> Send ER/ABAND
Call Arrives
Receive RELEASE
Send NEW_CALL or <5>
Release Call
REQUEST_INSTRUCTION Receive CONNECT_TO_RESOURCE
Send ER/DISCON
Send RESOURCE_CONNECTED
Selecting
Script
<2>
Receive
RUN_SCRIPT_REQ <11>
Connection Error
Send ER/CF,
<7>
ER/BUSY or
Script Invalid
ER/NA
Send DFC Connecting
<6> READY
Script <3>
Vaild Receive
<12> CONNECT or
Script Completes TEMPORARY_CONNECT
Send SCRIPT_RESULT <14> <10> <8>
CANCEL Successful Label Invalid
Send DFC Connection Successful
Send ER/CINV Send ER/ANS
<20>
<13> Receive CONNECT or
Receive CANCEL <19> TEMPORARY_CONNECT
Canceling Disconnect Current Destination
Script Receive CONNECT_TO_RESOURCE
Disconnect Current Destination
Running Script <15>
CANCEL Failed Connected
Send DFC
Figure 11: State Diagram with Cancel Supported
Page 109
<16>
Receive RELEASE IDLE
Release Call
<9>
Send ER/DISCON Caller Disconnects
<1>
<4> Send ER/ABAND
Call Arrives
Receive RELEASE
Send NEW_CALL or <5>
Release Call
REQUEST_INSTRUCTION Receive CONNECT_TO_RESOURCE
Send ER/DISCON
Selecting
Script
<2> <11>
Receive Connection Error
RUN_SCRIPT_REQ Send ER/CF,
ER/BUSY or
<7> ER/NA
Script Invalid
Send DFC <3> Connecting
<6> READY Receive
Script CONNECT or
Vaild TEMPORARY_CONNECT
<12>
Script Completes
<10>
Send SCRIPT_RESULT
Label Invalid <8>
Send ER/CINV Connection Successful
<18> Send ER/ANS
Receive CONNECT_TO_RESOURCE <20>
Send RESOURCE_CONNECTED Receive CONNECT or
TEMPORARY_CONNECT
<17>
Receive CONNECT <19>
Running Script Receive CONNECT_TO_RESOURCE Connected
Figure 12: State Diagram with Cancel Not Supported
Page 110
8.5.6.1 State Transition Table

Label From To Cause Action
Not <Any> IDLE VRU detects fatal error Send DIALOGUE_FAILURE_EVENT
shown
Not <Any> IDLE Receive None.
shown DIALOGUE_FAILURE_EVENT
(ICM detected fatal error)
Not <Any except IDLE Calling party disconnects. Disconnect called party, if any.
shown Connecting>
Send EVENT_REPORT/DISCONNECT.
1 IDLE READY Call arrives on a trunk. Send NEW_CALL or
REQUEST_INSTRUCTION
2 READY Selecting Receive RUN_SCRIPT_REQ. Validate script name
Script
Only occurs if VRU has enabled

the Run Script feature.
3 READY Connecting Receive CONNECT or Attempt to connect the caller to the
TEMPORARY_CONNECT. destination specified by the label.

the Connect feature.
4 READY IDLE Receive RELEASE. Release call.
Only occurs if VRU has enabled Send EVENT_REPORT /

the Release feature. DISCONNECT
5 READY READY Receive Send RESOURCE_CONNECTED.
CONNECT_TO_RESOURCE.
(no change
of state)
the Blind Transfer feature.
6 Selecting Running Script name is Valid Run Script
Script Script
7 Selecting READY Script name is not valid. Send DIALOGUE_FAILURE_CONF /
Script E_INVALID_SCRIPT for the
RUN_SCRIPT_REQ request.
8 Connecting Connected Called party answers Send EVENT_REPORT / ANSWER
9 Connecting IDLE Calling party disconnects. Send EVENT_REPORT / ABANDON
10 Connecting READY Label in CONNECT is invalid. Send EVENT_REPORT /
CONNECT_INVALID for the
CONNECT request.
Page 111
11 Connecting READY Connection attempt failed. Send EVENT_REPORT /

CONNECT_FAILURE,
EVENT_REPORT / BUSY, or
EVENT_REPORT / NO_ANSWER, as
appropriate.
12 Running READY Script Completed Send RUN_SCRIPT_RESULT for the
Script RUN_SCRIPT_REQ request.
13 Running Canceling Receive CANCEL with Invoke ID Check to see if the running script can
Script Script of running script. be canceled.

the Cancel feature.
14 Canceling READY Script can be canceled Send DIALOGUE_FAILURE_CONF /
Script E_OPERATION_CANCELLED for the
RUN_SCRIPT_REQ.
15 Canceling Running Script can’t be canceled Send DIALOGUE_FAILURE_CONF /
Script Script E_OPERATION_NOT_CANCELLED
for the CANCEL request.
16 Running IDLE Receive RELEASE Release call.
Script
Send EVENT_REPORT /
DISCONNECT
the Release feature.
Only occurs if VRU has NOT
enabled the Cancel feature.
17 Running Connecting Receive CONNECT. Attempt to connect the caller to the
Script destination specified by the label.

the Connect feature.
18 Running READY Receive Prepare for RUN_SCRIPT_REQ.
Script CONNECT_TO_RESOURCE.
Send RESOURCE_CONNECTED.

19 Connected READY Receive Disconnect called party, if connected
CONNECT_TO_RESOURCE. (or wait for called party to disconnect if
FEATURE_NEED_RELEASE is used).
Prepare for possible
RUN_SCRIPT_REQ.
Page 112
Send RESOURCE_CONNECTED.
20 Connected Connecting Receive CONNECT or Disconnect called party, if connected
TEMPORARY_CONNECT. (or wait for called party to disconnect if
FEATURE_NEED_RELEASE is used).
Attempt to connect the caller to the
CONNECT and
destination specified by the label.
TEMPORARY_CONNECT only
occur if VRU has enabled the
Blind Transfer feature.
8.5.7 Service Control Dialogue Examples

The previous section defined the Service Control Interface message set. This section will illustrate some
common Service Control Interface message sequences. Common error cases will be included in order to
illustrate error recovery procedures. Note that these examples constitute an illustration of a number of common
message sequences and not a comprehensive illustration of all possible message sequences.
8.5.7.1 Pre-Routed Call

The VRU sends a REQUEST_INSTRUCTION message to alert the ICM Router that the call routed to the VRU
has arrived at the VRU and is awaiting instruction. The REQUEST_INSTRUCTION message will cause a new
Service Control dialogue to be established with the ICM Router. The ICM Router will continue executing the
script previously associated with the call.
In this example, the script results in a RUN_SCRIPT_REQ being sent to the VRU. The VRU will run the script
and return any results to the ICM Router via the RUN_SCRIPT_RESULT message. The call terminates with
respect to the VRU when either: the caller hangs up since the VRU has provided the requested service, or the
network re-targets the call to another destination. The VRU detects that the call has terminated and sends a
EVENT_REPORT / DISCONNECT to terminate the Service Control dialogue.
PG VRU
REQUEST_INSTRUCTION
RUN_SCRIPT_REQ
SCRIPT_RESULT
EVENT_REPORT
(DISCONNECT)
Figure 13: Service Control Dialogue for Pre-Routed Call Example
Page 113
8.5.7.2 Non-Pre-Routed Call

The VRU sends a NEW_CALL message to alert the ICM Router that the call has arrived and that the VRU is
awaiting instruction. The NEW_CALL message will cause a new Service Control dialogue to be established
with the ICM Router. The ICM Router will choose the ICM Script which is scheduled for the given call type.
In this example, the script results in a RUN_SCRIPT_REQ being sent to the VRU. The VRU will run the
specified VRU script and return any results to the ICM Router via the RUN_SCRIPT_RESULT message. Based
on the results received in the RUN_SCRIPT_RESULT message, the ICM Router chooses a destination for the
call which results in a CONNECT message being sent to the VRU. The VRU interprets the label contained in the
CONNECT message and delivers the call to the specified destination. The VRU then sends an
EVENT_REPORT/ANSWERED when the call connects to the destination and a EVENT_REPORT/
DISCONNECT message when the call terminates. In this example, the dialogue is terminated by the
EVENT_REPORT/DISCONNECT.
PG VRU
NEW_CALL
RUN_SCRIPT_REQ
SCRIPT_RESULT
CONNECT
EVENT_REPORT
(ANSWERED)
EVENT_REPORT
(DISCONNECT)
Figure 14: Service Control Dialogue for Non-Pre-Routed Call Example
8.5.7.3 Non-Pre-Routed Call with a Cancel Request

The ICM Script queues the call for the next available agent based on the ICM Script. The ICM Script will then
issue a RUN_SCRIPT_REQ the VRU to select a VRU script to play delay announcements. The VRU will begin
running the specified VRU script. A short time later, an agent will become available and the ICM Router will
cancel the script that is playing the delay announcement via the CANCEL message. The VRU will indicate that
the request was cancelled by sending a DIALOGUE_FAILURE_CONF message to the ICM with a error code of
E_OPERATION_CANCELLED. Note that the InvokeID in the DIALOGUE_FAILURE_CONF message will be
that of the RUN_SCRIPT_REQ. The ICM will then send a CONNECT message to the VRU to transfer the call to
the available agent. The VRU interprets the label contained in the CONNECT message and delivers the call to
the specified destination. The VRU then sends an ANSWERED EVENT_REPORT when the call connects to the
Page 114
destination and a DISCONNECT EVENT_REPORT message when the call terminates. In this example, the
dialogue is terminated by the DISCONNECT EVENT_REPORT.
PG VRU
NEW_CALL
RUN_SCRIPT_REQ
CANCEL_REQ
DIALOGUE_FAILURE_CONF
( E_OPERATION_CANCELLED )
CONNECT
EVENT_REPORT
(ANSWERED)
EVENT_REPORT
(DISCONNECT)
Figure 15: Non-Pre-Routed Call with a Successful Cancel Request
8.5.7.4 Failed Cancel Request

The ICM Script queues the call for the next available agent based on the ICM Script. The ICM Script will then
issue a RUN_SCRIPT_REQ to the VRU to select a VRU script to play delay announcements. The VRU will
begin running the specified VRU script.
A short time later, an agent will become available and the ICM Router will attempt to cancel the script that is
playing the delay announcement via the CANCEL message. The VRU will not be able to cancel the request
immediately since it is in the middle of playing a forced announcement in the delay loop. The inability to
immediately cancel the running script will be indicated by the VRU sending a DIALOGUE_FAILURE_CONF
message to the ICM with an error code of E_OPERATION_NOT_CANCELLED. The InvokeID in the
DIALOGUE_FAILURE_CONF message will be the InvokeID of the failed cancel operation. The in progress
RUN_SCRIPT_REQ operation will not be affected by the failed CANCEL operation; however after a reasonable
time has elapsed, the ICM may assign the selected agent to the next call waiting in queue, and the VRU PG may
choose not to forward a subsequent CONNECT message to the VRU.
The VRU will send a Script Result message when the RUN_SCRIPT_REQ request completes on the VRU. The
ICM Script may then re-evaluate the availability of an agent resource to handle the call. If an agent is available,
the ICM Script will send a CONNECT message to the VRU to transfer the call to the available agent. If an agent
resource is not available, the ICM Script may re-queue the call to agent resources and send additional
RUN_SCRIPT_REQ or MICROAPP requests to play delay announcements.
Page 115
The VRU interprets the label contained in the CONNECT message and delivers the call to the specified
destination. The VRU then sends an ANSWERED EVENT_REPORT when the call connects to the destination
and a DISCONNECT EVENT_REPORT message when the call terminates. In this example, the dialogue is
terminated by the DISCONNECT EVENT_REPORT.
PG VRU
NEW_CALL
RUN_SCRIPT_REQ
CANCEL_REQ
(E_OPERATION_NOT_CANCELED)
SCRIPT_RESULT
CONNECT
EVENT_REPORT
(ANSWERED)
EVENT_REPORT
(DISCONNECT)
Figure 16: Service Control Dialogue with a Failed Cancel Request
8.5.7.5 Release Request

The ICM Script will then issue a RUN_SCRIPT_REQ the VRU to select a VRU script to play a call center closed
announcement. The VRU will begin running the specified VRU script. A short time later the announcement will
complete and a RUN_SCRIPT_RESULT message will be sent by the VRU to the ICM. The ICM Script will cause
the call to be released by the VRU by sending a RELEASE message to the VRU. The VRU will send a
DISCONNECT EVENT_REPORT message when the call terminates. In this example, the dialogue is terminated
by the DISCONNECT EVENT_REPORT.
Page 116
PG VRU
NEW_CALL
RUN_SCRIPT_REQ
SCRIPT_RESULT
RELEASE
EVENT_REPORT
(DISCONNECT)
Figure 17: Service Control Dialogue with a Release Request
8.5.7.6 Blind Transfer

If the VRU supports FEATURE_BLIND_TRANSFER and a call was connected with ‘TransferHint’ set to TRUE
the ICM may initiate a blind transfer by sending a CONNECT or CONNECT_TO_RESOURCE message.
PG VRU
Called Party was connected

with TransferHint=TRUE
CONNECT
Disconnect current Called

Party and connect to new
Called Party
EVENT_REPORT
(ANSWERED)
Figure 18: Blind Transfer with CONNECT
Page 117
PG VRU
Called Party was connected

with TransferHint=TRUE
CONNECT_TO_RESOURCE
Disconnect current Called

Party and prepare for
possible
RUN_SCRIPT_REQ
RESOURCE_CONNECTED
Figure 19: Blind Transfer with CONNECT_TO_RESOURCE
8.5.7.7 NIC Take-Back

The script results in a RUN_SCRIPT_REQ being sent to the VRU. The VRU will run the specified VRU script
and return any results to the ICM Router via the RUN_SCRIPT_RESULT message. Based on the results
received in the RUN_SCRIPT_RESULT message, the ICM Router chooses a destination for the call which
results in a CONNECT message being sent to the VRU. The VRU interprets the label contained in the
CONNECT message which results in a take-back and transfer request being made to the network by the VRU.
The VRU will send a DISCONNECT EVENT_REPORT when the take-back and transfer is complete to terminate
the dialogue.
Page 118
PG VRU
NEW_CALL
RUN_SCRIPT_REQ
SCRIPT_RESULT
CONNECT
EVENT_REPORT
(DISCONNECT)
Figure 20: NIC Take-Back Example
8.5.7.8 Service Control Dialogue with Re-Route

The example below illustrates a Service Control dialogue that reroutes a call due to the original destination
being busy. The VRU sends a NEW_CALL message to alert the ICM Router that the call has arrived and that
the VRU is awaiting instruction. The ICM Router will choose the script which is scheduled for the given call
type. The NEW_CALL message will cause a new Service Control dialogue to be established with the ICM
Router. The ICM script results in a RUN_SCRIPT_REQ being sent to the VRU. The VRU will run the specified
VRU script and return any results to the ICM Router via the RUN_SCRIPT_RESULT message. Based on the
results received in the RUN_SCRIPT_RESULT message, the ICM Router chooses a list of destinations in
prioritized order for the call which results in a CONNECT message being sent to the VRU using the first label.
The VRU interprets the label contained in the CONNECT message and attempts to deliver the call to the
specified destination. The VRU then sends a BUSY EVENT_REPORT to indicate that the selected destination
is presently engaged. A second CONNECT message is sent to the VRU using the second label in the prioritized
list. The VRU again attempts to connect the call to the destination specified by the label in the CONNECT
message. This time the call connects successfully and the VRU sends an ANSWERED EVENT_REPORT
message. At some time later the call terminates and the VRU sends a DISCONNECT EVENT_REPORT message
to indicate that the call has terminated and the dialogue has completed.
Page 119
PG VRU
NEW_CALL
RUN_SCRIPT_REQ
SCRIPT_RESULT
CONNECT
EVENT_REPORT
(BUSY)
CONNECT
EVENT_REPORT
(ANSWERED)
EVENT_REPORT
(DISCONNECT)
Figure 21. Reroute Service Control Dialogue Example
8.5.7.9 Dialogue Creation Failure

The example below illustrates a failed attempt at trying to establish a Service Control dialogue for a call that was
not pre-routed (not routed to the VRU by an ICM Script). The VRU sends a NEW_CALL message to alert the
ICM Router that the call has arrived and that the VRU is awaiting instruction. The ICM Router attempts to
select the script which is scheduled for the given call type, but no such script exists. The dialogue is terminated
by the DIALOGUE_FAILURE_EVENT and the VRU performs default call handling operations.
PG VRU
NEW_CALL
DIALOGUE_FAILURE_EVENT
Figure 22. Dialogue Creation Failure Example
Page 120
8.5.7.10 Service Control Dialogue Creation Timeout

The example below illustrates failed attempt to establish a Service Control dialogue for a call that has not been
routed to the VRU by the ICM Router. The VRU sends a NEW_CALL message to alert the ICM Router that the
call has arrived and that the VRU is awaiting instruction. The ICM Router fails to respond within the time-out
specified on the VRU. The VRU terminates the dialogue by sending a DIALOGUE_FAILURE_EVENT and the
VRU performs default call handling operations.
PG VRU
NEW_CALL
:
:
Figure 23. Service Control Dialogue Creation Timeout Example
8.5.7.11 Request Failure without Recovery

The example below illustrates the failure of a Service Control dialogue. The VRU sends a NEW_CALL message
to alert the ICM Router that the call has arrived and that the VRU is awaiting instruction. The NEW_CALL
message will cause a new Service Control dialogue to be established with the ICM Router. The ICM Router will
choose the ICM Script which is scheduled for the given call type. The script results in a RUN_SCRIPT_REQ
being sent to the VRU. The VRU is unable to run the specified VRU script, due to a configuration mismatch,
because no such script exists on the VRU. The VRU responds with a DIALOGUE_FAILURE_CONF message
since the request can not be processed. The ICM Script was not coded to provide error handling so it
terminates. The termination of the ICM script results in a DIALOGUE_FAILURE_EVENT being sent which
terminates the dialogue. The VRU performs default call handling operations upon receiving the
DIALOGUE_FAILURE_EVENT.
PG VRU
NEW_CALL
RUN_SCRIPT_REQ
Figure 24. Request Failure without Recovery Example
Page 121
8.5.7.12 Request Failure with Recovery

The example below illustrates the failure recovery procedure of a Service Control dialogue. The VRU sends a
REQUEST_INSTRUCTION message to alert the ICM Router that the call has arrived and that the VRU is
awaiting instruction. The REQUEST_INSTRUCTION message will cause a new Service Control dialogue to be
established with the ICM Router. The ICM Router continues execution of the script assigned at the time the
call was routed to the VRU. The script results in a RUN_SCRIPT_REQ being sent to the VRU.
The VRU is unable to run the specified script, due to a configuration mismatch, because no such script exists on
the VRU. The VRU sends a DIALOGUE_FAILURE_CONF message to indicate the operation could not be
performed. The ICM Script executes the error path of the RunScript node, which contains error-handling
instructions. The error handling instructions select a second script to run and a second RUN_SCRIPT_REQ
message is send to the VRU. The VRU executes the script and sends a RUN_SCRIPT_RESULT message to
indicate the script was successfully run. The caller ends the call since the VRU has provided the requested
service. The VRU detects that the call has terminated and sends a DISCONNECT EVENT_REPORT to terminate
the Service Control dialogue.
PG VRU
REQUEST_INSTRUCTION
RUN_SCRIPT_REQ
RUN_SCRIPT
SCRIPT_RESULT
EVENT_REPORT
(DISCONNECT)
Figure 25. Request Failure with Recovery Example
8.5.7.13 MicroApplication Request

with the ICM Router. The ICM Router chooses to issue a MICROAPP_MENU request followed by a lengthy
MICROAPP_PLAY – MICROAPP_PLAY_CONTINUE sequence. Then the ICM Router transfers the call to an
agent, though the VRU only sees a RELEASE message.
The VRU will send a DISCONNECT EVENT_REPORT message when the call terminates. In this example, the
dialogue is terminated by the DISCONNECT EVENT_REPORT.
Page 122
PG VRU
NEW_CALL
MICROAPP_CONTEXT
MICROAPP_MENU
MICROAPP_RESULT
MICROAPP_PLAY
MICROAPP_PLAY_CONTINUE
MICROAPP_RESULT
RELEASE
EVENT_REPORT
(DISCONNECT)
Figure 26: MicroApplication Requests with a Disconnect Event
9. Implementation Options
While this document specifies the complete interface between a VRU and the ICM, there are a number of
options for implementing only a subset of the complete specification.
The VRU must always implement the communications interfaces described in section 7. This is required to
establish basic connectivity between the VRU and the ICM. A subset of the application level interfaces
described in section 8 may be implemented, depending on how the VRU will participate in the ICM’s virtual call
center.
9.1 Event Data Feed Interface

If the VRU acts as the target of calls, i.e. the ICM may route calls directly to the VRU, the VRU must support the
Event Data Feed (section 8.2). This interface provides the ICM with the data necessary to choose the target for
a call based on current resource availability.
Event Data Feed provides the ability for the VRU to report cumulative current-day call statistics. If reporting
any or all of these cumulative data elements presents difficulty, the VRU may elect not to report selected
cumulative data elements.
Page 123
The data feed interface is independent of the other application level interfaces. In particular, a VRU may
support the Event Data Feed interface without also supporting the Call Routing Interface. This may occur when
the ICM routes calls to the VRU but the VRU does no transfers or only simple transfers that do not require the
ICM’s routing services.
9.2 Call Routing Interface

For the VRU to take advantage of the ICM’s call routing services, the VRU must support the Call Routing
Interface (section 8.3) in all cases where the Service Control Interface is not in use (section 8.5). Note that the
Call Routing Interface is incompatible with the Service Control Interface. If the Service Control Interface
successfully initializes, the Call Routing Interface will be disabled. The Call Routing Interface is independent of
the other application level interfaces. In particular, a VRU may support the Call Routing Interface without also
supporting Event Data Feed. This may occur when the VRU is located behind an ACD, but needs to select call
transfer targets on an enterprise-wide basis.
9.3 Time Synchronization Interface

The Time Synchronization Interface is optional.
9.4 Service Control Interface

For the VRU to take advantage of the ICM’s Service Control features, the VRU must support the Service
Control Interface (section 8.5). The Service Control Interface is compatible with the other application level
interfaces with the exception of the Call Routing Interface. The VRU PG will first attempt to initialize the Service
Control Interface and if successful the Call Routing Interface will be disabled. A VRU may support the Service
Control Interface as well as Event Data Feed as long as the Service Control Reporting feature has not been
enabled in VRU PG Setup. If Service Control reporting has been enabled, then the Event Data Feed interface
will be disabled.
In addition, the VRU may elect to support or not support various specific features within the Service Control
Interface. It provides this information to the VRU PG via a bitmap in the ServiceFeatures field of the
INIT_SERVICE_CTRL_DATA. See Section 8.5.1 and 8.5.5.1 for more information.
Page 124
10. Status Codes and Constants

Table 92 shows the status codes that may be included in the FAILURE_CONF, FAILURE_EVENT,
DIALOGUE_FAILURE_CONF, DIALOGUE_FAILURE_EVENT, ROUTE_END_EVENT, and ROUTE_END
messages. Table 93 shows the values used to indicate special ID’s or unspecified data elements.
Status Code Description Value

E_NO_ERROR No error occurred. 0
E_INVALID_VERSION The version number requested by the 1
Peripheral Gateway is not supported by the
VRU.
E_SESSION_ALREADY_ACTIVE The VRU already has an active communication 2
session with a Peripheral Gateway.
E_VRU_OFFLINE The VRU is unavailable. 3
E_SESSION_NOT_ACTIVE No session is currently active. 4
E_INVALID_DIALED_NUMBER The dialed number specified is not known to 5
the ICM.
E_EVENTS_NOT_SUPPORTED The VRU does not support the Event Data 6
Feed.
E_POLLING_NOT_SUPPORTED (Obsolete) 7
E_ROUTING_NOT_SUPPORTED The VRU does not support the Call Routing 8
Interface.
E_TIME_SYNCH_NOT_SUPPORTED The VRU does not support the Time 9
Synchronization Interface.
E_TIMEOUT A time-out has occurred. 10
E_PG_OFFLINE The Peripheral Gateway is off-line. 11
E_REQUEST_REFUSED The request was refused due to a temporary 12
condition.
E_ROUTING_NOT_AVAILABLE The ICM routing service is not available. 13
E_ROUTE_NOT_ACCEPTED The VRU did not accept the supplied route. 14
E_UNSPECIFIED_FAILURE An unspecified error occurred. 15
E_INVALID_INVOKEID An invalid InvokeID has been specified in a 16
result or response message.
E_SERVICE_CTRL_NOT_SUPPORTED A request was made to initialize the Service 17
Control Interface to a VRU that does not
support the interface.
E_NO_SCRIPT An ICM Script has not been scheduled for the 18
call type which the VRU is seeking instruction.
E_CALL_VARIABLE1 The VRU could not process a request due to 19
invalid value in CallVariable1
Page 125

E_INVALID_SCRIPT The Script ID specified in the 29
RUN_SCRIPT_REQ message was invalid on
the VRU
E_INVALID_CALLID The CallID specified in a Service Control 30
request message not valid on the VRU.
E_DUPLICATE_DIALOGUEID The dialogue identifier specified in either a 31
NEW_CALL or REQUEST_INSTRUCTION
message was not unique.
E_INVALID_MESSAGE This error code may be sent in response to 32
any message received with missing required
floating fields.
E_INVALID_DIALOGUEID The DialogueID specified in a request message 33
is no longer valid.
E_OPERATION_CANCELLED The specified operation was successfully 34
cancelled by a cancel request.
E_OPERATION_NOT_CANCELLED The specified operation could not be cancelled 35
by a cancel request.
E_SIMULATOR_RESET Reserved for VRU Simulator use. 36
E_SIMULATOR_REINIT Reserved for VRU Simulator use. 37
Table 92. Status Codes
Page 126
Constant Description Value

NULL_DATA_ELEMENT Indicates a data element that is not supplied. 0xFFFFFFFF
May be specified for certain cumulative
values.
NULL_SERVICE_ID In the DELIVERED_EVENT message, 0xFFFFFFFF
indicates that the service to which the call is
attributed should be determined based on the
DNIS.
NULL_CALL_ID In the ROUTE_REQUEST_EVENT message, 0xFFFFFFFF
indicates that the call variables are not
associated with a call previously known to
the ICM.
Table 93. Special Values
Page 127

Icm - Vru - Interface Ged 125

Uploaded by

Copyright:

Available Formats

Icm - Vru - Interface Ged 125

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

Icm - Vru - Interface Ged 125

Uploaded by

Copyright:

Available Formats

ICM / VRU

Document Version Number: 3.0c

3. GENERIC VRU MODEL........................................................................................................................................ 7

4. MESSAGING CONVENTIONS ........................................................................................................................... 9

4.3.1.2 Text -to-Speech Media Specifiers............................................................................................................ 13

4.3.1.3 Data Media Specifiers............................................................................................................................. 13

4.3.1.4 Null Media Specifiers ............................................................................................................................. 14

4.4 FLOATING FIELD M ESSAGE ELEMENTS........................................................................................................ 14

5. EXPANDED CALL CONTEXT ..........................................................................................................................17

6. FAILURE INDICATION MESSAGES ...............................................................................................................19

8. APPLICATION LEVEL INTERFACES.............................................................................................................26

8.2.2.2 Service Real-time..................................................................................................................................... 35

8.2.2.3 Peripheral Real-time................................................................................................................................ 35

8.2.2.4 Trunk Group Real-time .......................................................................................................................... 36

8.2.3 Unsolicited Events...................................................................................................................................36

8.2.3.2 Originated Event ..................................................................................................................................... 37

8.2.3.3 Call Cleared Event................................................................................................................................... 39

8.2.3.4 Conferenced Event .................................................................................................................................. 41

8.2.3.5 Diverted Event ........................................................................................................................................ 41

8.2.3.6 New Transaction Event ...........................................................................................................................42

8.2.3.7 Set Call Variables Event...........................................................................................................................43

8.2.3.8 VRU Status Event ...................................................................................................................................43

8.2.3.9 Trunk Group Status Event ......................................................................................................................45

8.2.3.10 Service Status Event ............................................................................................................................45

8.3 CALL ROUTING INTERFACE .............................................................................................................................46

8.5.1.2 Initializing VRU Service Data..................................................................................................................53

8.5.1.3 Initializing VRU Peripheral Data.............................................................................................................54

8.5.2 Service Control Database Reporting .................................................................................................55

8.5.2.2 Service_Real_Time Database Records.....................................................................................................57

8.5.2.3 Peripheral_Real_Time Database Records................................................................................................59

8.5.2.4 Trunk Group_Real_Time Database Records ..........................................................................................61

8.5.3 Service Control Dialogues....................................................................................................................61

8.5.3.2 Sending Event Reports via Dialogues ......................................................................................................62

8.5.3.3 Sending Call Control Instructions via Dialogues .....................................................................................63

8.5.3.4 Canceling Running VRU Scripts or MicroApplications .........................................................................63

8.5.3.5 Terminating Service Control Dialogues ...................................................................................................64

8.5.4 Using MicroApplications ......................................................................................................................64

8.5.4.2 Using Automatic Speech Recognition (ASR)..........................................................................................68

8.5.4.3 MicroApplication Message Flow ...........................................................................................................68

8.5.5 Service Control Messages .....................................................................................................................69

8.5.5.2 Service Control Interface Status Reporting Messages.............................................................................77

8.5.5.3 NEW_CALL Message (VRU to PG)......................................................................................................79

8.5.5.4 REQUEST_INSTRUCTION Message (VRU to PG)............................................................................82

8.5.5.5 RUN_SCRIPT_REQ Message (PG to VRU).........................................................................................83

8.5.5.6 RUN_SCRIPT_RESULT Message (VRU to PG)..................................................................................84

8.5.5.7 MICROAPP_CONTEXT (PG to VRU)................................................................................................86

8.5.5.8 MICROAPP_PLAY (PG to VRU).........................................................................................................88

8.5.5.9 MICROAPP_PLAY_CONTINUE (PG to VRU)................................................................................. 90

8.5.5.10 MICROAPP_COLLECT_DATA (PG to VRU) .............................................................................. 90

8.5.5.11 MICROAPP_MENU (PG to VRU).................................................................................................. 93

8.5.5.12 MICROAPP_RESULT (VRU to PG)............................................................................................... 94

8.5.5.13 CANCEL Message (PG to VRU) ...................................................................................................... 98

8.5.5.14 CONNECT Message (PG to VRU)................................................................................................... 98

8.5.5.15 RELEASE Message (PG to VRU) ................................................................................................... 101

8.5.5.16 NEW_DIALOGUE Message (VRU to PG) .................................................................................... 101

8.5.5.17 EVENT_REPORT Message (VRU to PG)...................................................................................... 103

8.5.5.18 DIALOGUE_FAILURE_CONF Message (VRU to PG) ............................................................... 104

8.5.5.19 DIALOGUE_FAILURE_EVENT Message (VRU to PG or PG to VRU)..................................... 105

8.5.5.20 CONNECT_TO_RESOURCE Message (PG to VRU)................................................................... 106