TelAlert
™
UMS
Copyrights
Copyright © 2005 - 2009, 2010 MIR3, Inc. TelAlert™ UMS Administrator Guide
This document is copyrighted and all rights are reserved. The distribution and sale of this product are intended for the use of the original purchaser only per the terms of the Agreement.
This document may not, in whole or part, be copied, photocopied, reproduced, translated, reduced, or transferred to any electronic medium or machine-readable form without prior written consent in writing from MIR3, Inc.
MIR3, TelAlert, IN, inEnterprise, inEnterprisePRO, inAlertCenter, inAlertCenterPRO, inCampusAlert inGovAlert, inGovAlertPRO, inSalesTalk, inTechCenter, inTechCenterPRO, inWebServices, inConnect, inConsole and Enterprise Access Control are trademarks of MIR3, Inc. All other product and
company names are marks of their respective holders.
This document is the property of MIR3, Inc. and may not be distributed in any manner except with the express written permission of MIR3, Inc.
Software Version: 5.71 07Sep2010 [20100907] Document Revision: 3.0
MIR3, Inc.
3398 Carmel Mountain Road San Diego, CA 92121
Phone: 858.724.1200 Fax: 858.724.1201
Preface
The TelAlert Version 5.71 Administrator Guide describes how to use the TelAlert™ software. It can run on all major platforms (Sun Solaris, Windows, HP-UX and Linux). The information in this document is accurate regardless of the platform used to support the TelAlert system.
Table of Contents
Introduction ... 1
1.1
Overview ... 1
1.2
TelAlert Overview ... 1
1.3
TelAlert Text to Speech (TTS) ... 3
1.3.1 Full Range of Voice Destinations ... 3
1.3.2 Customizable Vocabulary in Four Languages ... 3
1.3.3 Interactive Voice Response (IVR) ... 3
1.3.4 Dialogic Telephony Card... 3
1.4
TelAlert Integrations... 4
1.4.1 TelAlert Integrations Make it Easy ... 4
1.4.2 Do-it-Yourself Integrations for In-House Applications ... 4
1.5
Supported Platforms ... 5
1.5.1 Server and Client Platforms ... 5
1.5.2 Client Platforms ... 5
1.5.3 Operating Systems Not Supported for Version 5.71 ... 7
1.6
Guide Introduction ... 8
1.6.1 Contents ... 8
1.6.2 Audience ... 8
1.6.3 Related Technical Documentation ... 8
1.7
Product Support Contact Information ... 8
1.8
TelAlert
™Solutions from MIR3 ... 8
1.9
Guide Conventions ... 9
1.9.1 Screen Captures ... 11
1.9.2 File Locations ... 11
Technical Overview ... 13
2.1
Overview ... 13
2.2
How TelAlert Works ... 13
2.2.1 A Typical Alert ... 14
2.3
TelAlert Programs and Processes ... 15
2.4
Key TelAlert Files ... 17
2.5
Key Configuration Concepts ... 19
2.5.1 Sections, Definitions, Keywords, and Cross-Referencing ... 20
2.5.2 Configuration ... 21
2.5.3 Destination ... 21
2.5.4 User ... 22
2.5.5 Group ... 22
2.5.6 Schedule ... 23
2.5.7 Strategy ... 23
Implementation Planning ... 27
3.1
Overview ... 27
3.2
Your Accomplishments So Far ... 27
3.3
Structure of the Administrator Guide ... 28
3.3.1 Chapter 1: Introduction ... 28
3.3.2 Chapter 2: Technical Overview ... 28
3.3.3 Chapter 3: Implementation Planning ... 28
3.3.4 Chapter 4: Configuration Basics ... 28
3.3.5 Chapter 5: The Role of Ports in TelAlert ... 28
3.3.6 Chapter 6: Dialing the Telephone... 28
3.3.7 Chapter 7: Configuring for Paging Notification ... 28
3.3.8 Chapter 8: Configuring for Text to Speech (TTS) Notification ... 29
3.3.9 Chapter 9: Configuring for Other Notification Media ... 29
3.3.10 Chapter 10: Applying Filtering Techniques ... 29
3.3.11 Chapter 11: Setting Up and Applying Schedules ... 30
3.3.12 Chapter 12: Representing Users ... 30
3.3.13 Chapter 13: Enabling Responses ... 30
3.3.14 Chapter 14: Broadcasting to Groups and Creating Escalations ... 30
3.3.15 Chapter 15: Processing Events ... 31
3.3.16 Chapter 16: Miscellaneous Administrative Tasks ... 31
3.3.17 Chapter 17: Security Features ... 31
3.3.18 Chapter 18: Integrating XML Output ... 31
3.4
The Alert Timeline ... 31
3.4.1 Send and Release ... 31
3.4.2 Send, Wait, and Release ... 32
3.4.3 Send, Wait, Hold, and Release ... 33
3.4.4 The Alert Timeline and Escalations ... 33
3.4.5 Summary ... 34
3.4.6 Organizational Scenarios ... 34
3.4.7 Scenario One: Paging Only—Small Organization ... 35
3.4.8 Scenario Two: Paging, Voice, and Email—Small Organization ... 40
3.4.9 Scenario Three: A Larger Organization ... 43
Configuration Basics ... 47
4.1
Overview ... 47
4.2
TelAlert Configuration Methods: telalert.ini; TADesktop ... 47
4.2.1 Choosing a Configuration Method ... 49
4.2.2 What “Make TelAlert Re-Read its Configuration File” Means ... 50
4.3
Understanding Configuration Examples ... 50
4.3.1 Singular vs. Plural Section Names ... 52
4.4
Performing Common Configuration Tasks ... 53
The Role of Ports in TelAlert ... 57
5.1
Overview ... 57
5.2
What is a Port? ... 57
5.4
If You Are Using a Terminal Server... 61
5.4.1 Testing Connectivity on a Terminal Server ... 62
5.5
More Advanced Port Considerations ... 62
5.5.1 Directing Specific Notifications to Specific Ports ... 62
5.5.2 Providing Port Backup... 64
5.5.3 Controlling Port Deactivation Due To Errors ... 65
5.5.4 What Remote Ports Are Used For ... 66
Dialing the Telephone ... 69
6.1
Overview ... 69
6.2
What’s So Hard About Dialing the Phone? ... 69
6.2.1 Local Dialing ... 70
6.2.2 Alternate Numbers ... 70
6.2.3 Inside and Outside Lines ... 70
6.2.4 Special Dialing Scenarios ... 70
6.2.5 Dialing After the Main Number is Answered ... 70
6.2.6 Inserting Pauses During Dialing ... 70
6.3
Dialing Logic ... 71
6.3.1 Dialing Components ... 71
6.3.2 Dialing Process ... 72
6.4
Local Dialing ... 72
6.4.1 Normal Local Dialing ... 72
6.4.2 Ten-Digit Local Dialing ... 73
6.4.3 Eleven-Digit Local Dialing ... 73
6.5
Long Distance Dialing ... 73
6.5.1 Normal Long Distance Dialing ... 73
6.5.2 Other Long Distance Dialing... 74
6.5.3 Alternate Numbers ... 74
6.6
Inside and Outside Lines ... 75
6.6.1 Getting an Outside Line ... 75
6.6.2 Getting an Inside Line ... 75
6.7
Special Dialing Scenarios ... 76
6.8
Dialing After the Main Number is Answered ... 76
6.8.1 Dialing a Number, Then an Extension ... 76
6.8.2 Dialing a Number, Then Accessing a Mailbox ... 77
6.9
Inserting Pauses During Dialing ... 77
6.10
Specifying Telephone Dialing Components at the Command Line... 78
6.11
Overriding the Need for Dialtone ... 78
Configuring for Paging Notification ... 79
7.1
Overview ... 79
7.2
Getting Started ... 79
7.2.1 Needed Information ... 79
7.2.2 General Considerations ... 80
7.3
Setting Up Text Paging ... 81
7.3.2 Pointing to a Modem ... 82
7.3.3 Creating a Text Pager Destination ... 83
7.3.4 Sending a Page by Invoking a Destination ... 83
7.3.5 Sending a Page Without Invoking a Destination ... 84
7.3.6 Sending to Text Pagers via [Configurations] Definitions of
Type=InteractiveTextPager ... 84
7.3.7 Sending Text Pages via Modem without TAP (Protocol=Chat) ... 85
7.4
Setting Up Numeric Paging ... 89
7.4.1 Sending Numeric Pages Using the TAP Protocol ... 89
7.4.2 Sending Numeric Pages Without TAP ... 90
7.5
Setting Up Two-Way Paging ... 93
7.5.1 Creating a Two-Way Pager [Configurations] Definition ... 93
7.5.2 Pointing to a Modem ... 94
7.5.3 Creating Two-Way Pager Destinations ... 95
7.5.4 Enabling Responses ... 95
7.5.5 Enabling Polling ... 98
7.5.6 Enabling Notifications ... 98
7.6
Setting Up Requests: Unsolicited Messages From Two-Way Pagers ... 99
7.6.1 Receiving Requests ... 99
7.6.2 Having Requests Trigger [Notifications] Actions ... 99
7.6.3 Simulating Requests for Testing Purposes ... 99
7.7
Setting Up Internet-Based Paging ... 100
7.7.1 One-Way Internet-Based Paging ... 100
7.7.2 Two-Way Internet-Based Paging ... 101
7.8
Initiating Pages via Email ... 104
7.8.1 Responses to Two-Way Email-Based Text Pages ... 105
7.9
Adding ID Numbers to Pages ... 105
Configuring for Voice Notification ... 107
8.1
Overview ... 107
8.2
Configuration for Voice Notification now in TelAlert Voice and Hardware
Guide 107
Configuring for Other Notification Media ... 109
9.1
Overview ... 109
9.2
Getting Started ... 109
9.2.1 Needed Information ... 109
9.2.2 General Considerations ... 111
9.3
Setting up Electronic Signboard Notification ... 112
9.3.1 Signboard Overview ... 112
9.3.2 Initial Signboard Firmware Setup ... 112
9.4
Standard Signboard Setup (DeviceSubtype=2) ... 112
9.4.1 TelAlert-Controlled Signboard Message Display... 113
9.4.2 Signboard [Port] Definition ... 113
9.4.3 Signboard [Configurations] Definition ... 114
9.4.4 Signboard [Destinations] Definitions ... 116
9.4.6 Controlling Signboard Text Color and Effects ... 117
9.4.7 Configuring Multiple Signboards ... 119
9.5
Alternative Signboard Setup (DeviceSubtype=1) ... 119
9.5.1 Signboard [Port] Definition when DeviceSubtype=1 ... 120
9.5.2 Signboard [Configurations] Definition when DeviceSubtype=1... 120
9.5.3 Additional Signboard Firmware Setup when DeviceSubtype=1 ... 121
9.5.4 Signboard [Destinations] Definitions when DeviceSubtype=1 ... 122
9.6
Setting up Email Notification ... 125
9.6.1 Email [Port] Definition ... 126
9.6.2 Email [Configurations] Definition ... 126
9.6.3 Email [Destinations] Definition ... 127
9.6.4 Using Email as a Backup Notification Medium ... 127
9.6.5 Handling Responses to Email With Readmail ... 127
9.7
Setting up Command Line Notification ... 133
9.7.1 Command-Line [Configurations] Definition ... 133
9.7.2 Command-Line [Destinations] Definition ... 133
9.7.3 Applications for Command-Line Notification ... 134
9.8
POPUP Message Boxes on Windows ... 134
9.9
Sending Messages to Other Systems ... 135
9.9.1 UNIX Syslog Processes ... 135
9.9.2 TelaConsole ... 136
9.9.3 AS/400s ... 136
9.10
Sending Messages to Web-Enabled Phones ... 136
9.11
Sending Text Messages to Nextel Cellular Phones ... 138
9.12
Sending One-Way Text Messages to GSM Cellular Telephones ... 139
9.13
Sending Two-Way Text Messages to SMS Mobile Telephones Via a GSM Wireless
Modem ... 140
9.13.1 Set-Up During Installation ... 140
9.13.2 New Technique in TelAlert 5.4 ... 140
9.13.3 Differences Between the Two Techniques ... 141
9.13.4 Samples for Both Techniques ... 142
9.14
Sending Messages to a DN400E Fax Modem ... 146
9.15
Sending a File or a Line from stdin as a Message ... 147
9.15.1 Sending a File as a Message ... 147
9.15.2 Sending a Line from stdin as a Message ... 148
9.16
SMPP ... 149
9.16.1 SMPP Confirmed Delivery Option ... 149
9.16.2 SMPP Sample Configuration ... 149
9.17
WCTP Proxy Configuration ... 150
Applying Filtering Techniques ... 152
10.1
Overview ... 152
10.2
Getting Started ... 152
10.2.1 What is Filtering? ... 152
10.2.2 Needed Information ... 152
10.3
A Simple Filter ... 153
10.3.1 The Scenario ... 153
10.3.2 Procedure ... 153
10.4
Filtering Strategies ... 156
10.4.1 Filtering and Default Logic ... 156
10.4.2 RequiresFullMatch and Exclusive Value Combinations ... 157
10.4.3 RequiresClientMatch ... 159
10.4.4 The MatchKeyword ... 159
10.4.5 Filtering and Groups ... 160
10.4.6 Filtering and Schedules ... 162
10.4.7 Filtering and Users ... 162
10.5
Filtering by Message Priority ... 164
10.5.1 Extended Example ... 165
10.5.2 Default Logic ... 166
10.6
Filtering Messages by IP Address ... 166
10.7
Filtering out Duplicate and Transient Messages ... 167
10.7.1 Filtering Out Duplicate “Node Down” Messages ... 167
10.7.2 Suppressing Transient Messages ... 168
10.8
Suppressing Unwanted Messages During Scheduled Downtime ... 169
10.8.1 Suppressing Orphan “Up” Messages ... 170
10.8.2 When a Device Does Not Come Back Online as Scheduled... 170
10.9
Filtering Messages by Source ... 171
10.10
Pattern Matching ... 171
10.10.1 Other Uses ... 172
10.10.2 Pre-Defining Regular Expressions ... 173
Setting Up and Applying Schedules ... 175
11.1
Overview ... 175
11.2
Getting Started ... 175
11.2.1 What are Schedules? ... 175
11.2.2 Needed Information ... 176
11.2.3 Other Considerations ... 176
11.3
A Simple Schedule ... 176
11.3.1 The Scenario ... 176
11.3.2 Procedure ... 176
11.4
Scheduling Approaches ... 177
11.4.1 Schedules and Default Logic... 177
11.4.2 Schedules and Groups ... 178
11.4.3 Schedules and [Filter] Definitions ... 181
11.4.4 Schedules and [User]Definitions ... 181
11.4.5 Vacations and Holidays ... 182
11.4.6 Adding Time to a Schedule: ExtraDuty ... 182
11.4.7 Including Other Schedules in a Schedule ... 183
11.4.8 Schedules and Message Priority ... 184
11.4.10 Changing a Rotation Schedule to Account for Unexpected Leave... 192
11.4.11 Reverse Schedules: Exclusive ... 192
Representing Users ... 195
12.1
Overview ... 195
12.2
Getting Started ... 195
12.2.1 What Are Users? What Are They For? ... 195
12.2.2 Needed Information ... 196
12.2.3 Other Considerations ... 196
12.3
Creating a [User] definition: Essentials ... 197
12.4
Values for Inheritance by Associated Destinations ... 197
12.4.1 Direct Inheritance ... 198
12.4.2 Minimum of the [User] Value and the [Destinations] Default ... 198
12.4.3 Maximum of the [User] Value and the [Destinations] Default... 198
12.4.4 Maximum of the [User] Value, the [Destinations] Default, and the
[Configurations] Value ... 199
12.5
Values for Dial-in and Dial-out Access ... 199
12.6
User-Based Administrative Techniques ... 200
12.6.1 Viewing Messages: -show ... 200
12.6.2 Getting Rid of Messages: -clear and -release ... 201
12.6.3 Listing Users ... 201
Enabling Responses ... 203
13.1
Overview ... 203
13.2
Getting Started ... 203
13.2.1 What are Responses? ... 203
13.2.2 Needed Information ... 203
13.2.3 Other Considerations ... 204
13.3
Taking Advantage of Pre-Defined Responses ... 204
13.3.1 Responding Via the Command Line ... 205
13.4
Creating Custom Responses ... 206
13.5
Two-Way Pager Considerations... 207
13.6
Responses and the [Notifications] Feature ... 207
Broadcasting to Groups and Creating Escalations ... 211
14.1
Overview ... 211
14.2
Getting Started ... 211
14.2.1 What Are Groups? What Are They For? ... 211
14.2.2 Needed Information ... 211
14.2.3 Other Considerations ... 212
14.3
Group Basics... 212
14.3.1 Building a Group from a List of Destinations ... 212
14.3.2 Building a Group From a List of Other Groups ... 212
14.3.3 Supported Group Attributes ... 213
14.4
Broadcast Notification ... 214
14.4.1 About Group IDs ... 215
14.4.3 Schedules and Broadcast Notifications ... 215
14.5
Escalation ... 216
14.5.1 A Simple Escalation ... 216
14.5.2 Other Approaches to Strategy ... 218
14.5.3 Escalations Involving Subgroups ... 219
14.5.4 Balancing Workloads by Rotating the First Destination ... 222
14.5.5 Schedules and Escalation ... 222
Processing Events ... 223
15.1
Overview ... 223
15.2
Getting Started ... 223
15.2.1 Needed Information ... 223
15.2.2 Other Considerations ... 224
15.3
Event Processing Defined ... 224
15.3.1 What Is Event Processing? ... 224
15.3.2 What Is an Event? ... 225
15.4
Event Processing Overview ... 225
15.4.1 About Notification and Related Keywords ... 226
15.5
Triggering Actions ... 227
15.5.1 Sending an SNMP Trap ... 227
15.5.2 Writing to the System Log ... 228
15.5.3 Issuing a Command ... 228
15.5.4 Making One Event Trigger Multiple Actions ... 230
15.6
Alert-Related and Miscellaneous Events: The [Notification] Section ... 231
15.6.1 Event Keywords Supported in the [Notification] Section ... 233
15.6.2 Event Substitution Parameters Supported in the [Notification] Section
... 236
15.7
Process-Related Events: The [Heartbeat] Section ... 238
15.7.1 Event Keywords Supported in the [Heartbeat] Section ... 239
15.7.2 Event Substitution Parameters Supported in the [Heartbeat] Section 239
15.8
Logging-Related Events: The [File] Section ... 240
15.8.1 Handling Rollover of telaconfe.log and telainetde.log ... 242
15.8.2 Handling telalert.sects and telalert.ini file Backups when TelAdmin
is Used ... 242
15.8.3 Miscellaneous [File] Functions ... 243
15.8.4 Event Substitution Parameters Supported in the [File] Section ... 243
Miscellaneous Administrative Tasks ... 245
16.1
Overview ... 245
16.2
Starting, Stopping, and Initializing TelAlert ... 245
16.3
Configuring TelAlert to Run Automatically ... 246
16.3.1 On Windows... 246
16.3.2 On UNIX ... 246
16.4
Installing TelAlert Clients... 246
16.4.1 Configuring the Server To Accept Remote Clients ... 246
16.4.3 Installing Remote Command-Line Clients on Windows ... 247
16.4.4 Installing Remote Command-Line Clients on UNIX ... 249
16.5
Setting up the TelAlert Web Clients ... 250
16.5.1 Installing the Web Clients ... 250
16.5.2 Running Multiple Web Clients on the Same Machine ... 250
16.5.3 Using the Web Clients with Web-Enabled Cell Phones ... 251
16.5.4 Installing Online Help for the Web Clients ... 251
16.5.5 Configuring telalerth with telalerth.ini ... 251
16.5.6 Other Keywords ... 256
16.6
Setting up Logging ... 259
16.6.1 Default Log Files ... 259
16.6.2 Setting Maximum Sizes ... 260
16.6.3 WriteExecsToTrail ... 260
16.6.4 Configuring Additional Logging Behavior ... 260
16.7
Miscellaneous Administrative Tasks ... 260
16.7.1 Specifying Maximum ID Assignments ... 260
16.7.2 Viewing Listen Sockets ... 261
Security Features ... 262
17.1
Overview ... 262
17.2
TelAlert’s Security-Conscious Architecture ... 262
17.2.1 telalerte: The Central Hub of TelAlert ... 263
17.2.2 The Media Controllers ... 264
17.2.3 TelAlert Desktop ... 265
17.2.4 Client Programs ... 265
17.3
Password Encryption ... 266
17.4
Scheduling of Client Connections ... 267
17.5
Authentication for Admin and Client Connections ... 267
17.6
Control Over Remote Connections ... 268
17.7
Security Event Available in [Notifications] ... 269
17.8
Control Over IVR Interactions ... 269
17.9
Using SSL with Skytel Devices ... 269
17.9.1 Obtain and Install Wrapper/Proxy Software ... 270
17.10
Development Example ... 274
Integrating XML Output ... 280
18.1
Overview ... 280
18.2
Enabling XML Output ... 280
18.3
Defining the Task... 283
18.4
A (Very) Brief Overview of XML ... 284
18.5
The Parser Toolkit ... 286
18.6
The Event Matrix ... 287
18.7
The User Methods ... 289
18.8
The Notification Objects ... 292
18.9
Development Example ... 293
1
Introduction
1.1 Overview
This chapter includes the following sections:
A high-level look at TelAlert and related products.
An overview of the TelAlert Administrator Guide and other TelAlert documentation.
1.2 TelAlert Overview
TelAlert Mission-Critical Messaging Server is the core of MIR3 Application Mobilization Platform (AMP). The flexibility and reliability of TelAlert make it the Urgent Messaging System used by more than half of the Fortune 500.
TelAlert Takes Messages from Any Source...
TelAlert works with virtually any kind of application, including network monitoring, enterprise management, help desk, and dispatch solutions—anything capable of generating event-based messages and issuing user-defined Windows or UNIX commands.
... Applies Your Business Rules
TelAlert lets you exert an unparalleled degree of control over how it processes messages. You can:
Define groups for broadcast notifications—or person-by-person escalations that ensure someone responds, even if the first addressee is unavailable.
Set up rules governing how escalations proceed.
Create schedules determining when each support technician is available to receive messages.
Process messages based on priority.
... Sends Messages to the Right Destinations
TelAlert can deliver text messages to a wide range of destinations, including:
Cell phones equipped with text screens (WAP or SMS)
Wireless PDAs (RIM, Palm, Visor)
Pagers
Email addresses
Electronic Signboards
... And Accepts and Processes Responses
TelAlert does much more than deliver messages. It also allows recipients to respond to messages—a key factor in TelAlert's ability escalate an alert and ensure that someone takes control of the
situation.
Two-Way Pagers
Recipients can choose from a customizable menu of reply options to accept or decline messages, update trouble tickets, ping a node, and more. More sophisticated functionality can be achieved through server-side scripting.
WAP- and SMS-Enabled Cell Phones
Recipients can wirelessly acknowledge and manage messages through the TelAlert Web Client. Applet-Based Remote Interactions
1.3 TelAlert Text to Speech (TTS)
TelAlert Text to Speech (TTS) gives you all the capabilities of TelAlert, plus the license and hardware you need to deliver voice messages and let recipients interact with TelAlert and integrated
applications via touch-tone telephone.
See the TelAlert Voice and Hardware Guide for complete technical instructions relating to TelAlert TTS functionality.
1.3.1 Full Range of Voice Destinations
TelAlert Voice can dial a telephone number, monitor call progress, validate the identity of the person who answers, and then speak its message. When appropriate, it will negotiate voicemail or
answering machine systems and leave a recorded message.
1.3.2 Customizable Vocabulary in Four Languages
The voice fonts TelAlert TSS are generated by AT&T’s Natural Voices. These fonts are available in English, French, German, and Spanish. All languages are available in male and females voices. English is also available in American, UK and Indian Accent.
1.3.3 Interactive Voice Response (IVR)
Users can enter keypad input to accept or decline messages when they are delivered by TelAlert over the telephone. Users can also dial in and interact with TelAlert —and even the backoffice applications with which it is integrated—via customizable IVR menus.
This capability is delivered through a Dialogic telephony card. The TelAlert Voice Engine is no longer available.
1.3.4 Dialogic Telephony Card
1.4 TelAlert Integrations
TelAlert is designed to work with other applications—to take the messages they generate and, following your business rules, pass them to the right people, using the medium of your choice.
1.4.1 TelAlert Integrations Make it Easy
It is easy to make TelAlert work with almost any application, whether it be a network monitoring, enterprise management, help desk, or dispatch solution. The following integrations have been developed and documented by TelAlert engineers. Many come with special scripts and other support files that help you get up and running as quickly as possible.
Computer Associates TNG Advanced Help Desk
Computer Associates Unicenter TNG
HP Software Operations Manager (formerly HP OpenView IT/Operations )
HP Software Network Node Manager
HP Software ServiceDesk
HP Software ServiceCenter (formerly Peregrine)
HP Software ServiceManager
Remedy AR System
Remedy Help Desk
Tivoli Enterprise Console
Tivoli NetView
1.4.2 Do-it-Yourself Integrations for In-House Applications
Even with applications for which no certified integration exists, integration with TelAlert is typically a simple matter, since most TelAlert integrations are carried out at the command line. For instance, perhaps your organization relies on an application it has developed in-house. If this application can be configured to issue UNIX or Windows commands in response to specified events, it can be
1.5 Supported Platforms
The list below is current as of this writing. Please refer to the current TelAlert Release Notes for the most up to date platform support.
1.5.1 Server and Client Platforms
HP-UX PA-RISC 1.1 (11.31 and higher)
HP-UX PA-RISC 2.0 (11.31 and higher)
HP-UX Itanium2 (11.31 and higher)
Linux (glibc 2.5) (Intel x86 32bit) (Red Hat 5.4)
Windows (32 bit – Server) (2000)
Windows (32 bit – Server) (2003)
Windows (32 bit – Server) (2008)
Solaris 2.9 (Solaris 9) + (SunOS 5.9+) (SPARC 32/64 bit)
Solaris 2.9 (Solaris 9) + (SunOS 5.9+) (Intel X86 32/64 bit)
Solaris 2.10 (Solaris 10) + (SunOS 5.10+) (SPARC 32/64 bit)
Solaris 2.10 (Solaris 10) + (SunOS 5.10+) (Intel X86 32/64 bit)
1.5.2 Client Platforms
Client systems have 3 states, supported on the current version, supported with an older version and discontinued. All 5.00 – 5.70 client versions are compatible with the 5.71 server software.
Operating System
Status
AIX
AIX 3.2.5
Supported with TA 5.20
AIX 4.1.3 (and higher)
Supported with TA 5.20
HP-UX
HP-UX PA-RISC 1.0 (9.04 and higher)
Supported with TA 5.50
HP-UX PA-RISC 1.1 (9.04 and higher)
Supported with TA 5.50
HP-UX PA-RISC 1.1 (10.20 and higher)
Supported with TA 5.
70
HP-UX PA-RISC 2.0 (10.20 and higher)
Supported with TA 5.70
HP-UX PA-RISC 1.1 (11.31 and higher)
EXISTING
HP-UX PA-RISC 2.0 (11.31 and higher)
EXISTING
HP-UX Itanium2 (11.31 and higher)
EXISTING
Java
Java 1.50 (TelAlert Admin "telalert")
EXISTING
Java 1.50 (TelAlert EndUser "telalertc")
EXISTING
Java 1.60 (TelAlert Admin "telalert")
EXISTING
Java 1.60 (TelAlert EndUser "telalertc")
EXISTING
Linux
Linux (glibc 2.0) (Intel x86 32bit)
Supported with TA 5.70Linux (glibc 2.1) (Intel x86 32bit)
Supported with TA 5.70Linux (glibc 2.5) (Intel x86 32bit) (Red Hat 5.4)
NEW
Microsoft
Windows (32 bit – Server) (4.0/2000/XP Professional)
EXISTING
Windows (32 bit – Server) (2003)
EXISTING
Windows (32 bit – Server) (2008)
NEW
SGI
SGI Irix
Supported with TA 5.50
SGI MIPS ABI
Supported with TA 5.50
SCO
SCO Release 3
Supported with TA 5.50
Sun
SunOS 4.1.3 (SPARC 32bit)
Supported with TA 5.50
Solaris 2.7 (Solaris 7) + (SunOS 5.7+) (SPARC 32/64 bit)
Supported with TA 5.
70
Solaris 2.9 (Solaris 9) + (SunOS 5.9+) (Intel X86 32/64 bit)
NEW
Solaris 2.9 (Solaris 9) + (SunOS 5.9+) (SPARC 32/64 bit)
NEW
Solaris 2.10 (Solaris 10) + (SunOS 5.10+) (Intel X86 32/64 bit)
NEW
Solaris 2.10 (Solaris 10) + (SunOS 5.10+) (SPARC 32/64 bit)
NEW
Other
AT&T GIS (System 3000)
Supported with TA 5.50
BSDI 4.1
Supported with TA 5.50
Digital Unix (Tru64 UNIX 5.1A BL4)
Supported with TA 5.70
Tandem Guardian & Tandem OSS
Supported with TA 4.03
IBM OS/2
Supported with TA 5.10
HP MPE/iX (WRQ format)
Supported with TA 5.20
1.5.3 Operating Systems Not Supported for Version 5.71
TelAlert no longer has access to the following platforms, so we cannot build 5.71 server or client software for them; nor can we provide bug fixes for prior versions. Customers with support contracts, who are running TelAlert version 5.1 or 5.2 on these platforms, can continue to receive technical support with configuration, operation, and other such issues that are not related to the operating system. We encourage migrating as soon as possible to a fully-supported platform. Server/Client platforms:
HP-UX PA-RISC 1.1 (10.20 and higher)
HP-UX PA-RISC 2.0 (10.20 and higher)
AIX 5.2 (No AIX version is supported in this release)
Linux (glibc 2.0) (Intel x86 32bit)
Linux (glibc 2.1) (Intel x86 32bit)
Solaris 2.7 (Solaris 7) + (SunOS 5.7+) (SPARC 32/64 bit)
1.6 Guide Introduction
Thank you for using the MIR3 TelAlert™ Administrator Guide, your primary source for information about the use of recipient-related features in the TelAlert system. The purpose of this Guide is to provide detailed information on how to use these functions in the TelAlert system. . It assumes you have installed TelAlert and are ready to begin configuring and administering it.
1.6.1 Contents
To help you learn how to use the TelAlert system effectively, the first page of each chapter includes a bulleted table of contents summarizing the information in the chapter. Each chapter also contains step-by-step instructions and procedures for using each function with the TelAlert system. The Guide provides recipient-directed information, including changing login IDs, passwords, and notification retrieval.
1.6.2 Audience
The TelAlert Administrator Guide is designed for use by individuals who configure notifications using the TelAlert system.
1.6.3 Related Technical Documentation
There are other sources of information available concerning deployment of the TelAlert system:
TelAlert Voice and Hardware Guide - This guide contains complete instructions on
sending Text to Speech (TTS) notifications using a TelAlert Dialogic telephony card.
TelAlert Keyword and Command Reference - This guide contains information that was
previously part of the Administrator Guide. It is a detailed reference to the keywords supported by the TelAlert configuration file, the commands and command line options supported by TelAlert, and the event and state messages issued by TelAlert.
The TelAlert Desktop Guide - This guide contains details on using the TelAlert Desktop—
including TelAdmin, a GUI-based configuration tool that is included with TelAlert. TelAdmin allows you to configure TelAlert from within a graphical application rather than from a command line.
1.7 Product Support Contact Information
1.8 TelAlert
™Solutions from MIR3
TelAlert is a trademark of MIR3, Inc., but is referred to without trademark symbols in the
remainder of this document.
1.9 Guide Conventions
This guide is written in Microsoft Word format and converted to PDF format to preserve the formatting. The following information provides you with the key to help you identify information as you navigate through this Guide:
Example Purpose
Use of Monospaced Fonts
telalertc -i DestinationName -m "Message"
Italicized text within a command line example represents a variable. In the above example, DestinationName is the invocation of an item in TelAlert’s configuration file; message represents the message text to be sent by TelAlert.2001/03/16 11:50:11>Event [21]Alert
Completed (23), Status: [81]Message
sent, TelamonTestPage
Command line text — Text
representing information entered by the user at the command line or presented by TelAlert as output is shown in a monospaced font.
Click OK. Within procedural (how-to) text, boldface words are characters you type or elements you can click. Within overview or conceptual text, bolded words may simply represent concepts that have been highlighted to emphasize their relative importance.
1. Go to the Add User page.
Within procedural text, numbered steps denote actions that should be followed in sequence.
Message Formatting
Example Purpose
"Open telalert.ini and search for ..."
" ... gives the file a .bak
extension and then ..."
File names and extensions — The same
monospaced font is used to represent file names and extensions.
{LauraTextPager}
...
Configuration=SkyTelNationalTe
xtPager
PIN=4850879
The ellipses (...) indicate information that may be present in the actual
telalert.ini entry but which is
omitted in the example because it is not relevant here.telalert.iniexamples — Entries drawn from the
TelAlert configuration file are also represented in a monospaced font.
Click OK. Within procedural (how-to) text, boldface words
are characters you type or elements you can click. Within overview or conceptual text, bolded words may simply represent concepts that have been highlighted to emphasize their relative importance.
2. Go to the Add User page. Within procedural text, numbered steps denote actions that should be followed in sequence.
Click Save to save your work. Click Cancel to exit without
saving.
Within procedural text, bulleted text denotes available options. Within overview or conceptual text, bulleted text also denotes supporting information that is subordinate to the major topic being discussed in the Guide.
The light bulb icon denotes a helpful tip.
The information icon denotes reference material.
1.9.1 Screen Captures
Due to the flexibility of permissions in the TelAlert system, some of the functionality represented in the screen captures for this Guide is not always visible to, or functional for, all users. The User Interface screen captures are intended for instructional use. The system administrator determines access to specific functions using the Enterprise Access Control (EAC) role-based access functions available in the TelAlert system.
1.9.2 File Locations
By default, TelAlert is installed in /usr/telalert on UNIX systems. Note that some files, (including log files) are placed in /tmp. On Windows files are placed in c:\ProgramFiles\telalert. Other TelAlert files are placed in directories relative to this location.
You are not required to accept these defaults during installation, but all references to file locations in TelAlert documentation assume (for simplicity of representation) that these default settings have been used.
Broken Lines in
telalert.ini
In telalert.ini excerpts presented here, some lines are too long to be presented as single lines. In such cases, the line is broken and continued below. The continuation is indented. It is assumed that, in the telalert.ini entry itself, the line will not actually be broken. Note that telalert(c) does not support breaking command lines.
If you want to break a line in telalert.ini so that it continues on the next, you must place an ampersand (&) immediately preceding the line break. Otherwise, TelAlert will treat the continuation as a new line.
2
Technical Overview
2.1
Overview
A high-level look at TelAlert from a technical perspective:
How it works
The programs and processes comprising it
Key TelAlert files
The concepts underlying TelAlert configuration
Some frequently asked questions—and their answers
2.2 How TelAlert Works
TelAlert follows instructions issued by applications and human users. These instructions fall into three main categories:
Notification instructions include a message that TelAlert is to send to some recipient.
Administrative instructions relate to starting and stopping TelAlert, modifying the way it
works, and checking the status of the work it does.
Responsive instructions come from message recipients and acknowledge receipt of the
message, update the status of a problem, ask for more information, and so on.
TelAlert can accept instructions via two command line interfaces, telalert and telalertc. In addition, specially integrated applications can call TelAlert API functions or Java methods to interact with TelAlert. The command line interfaces are the most common means of interaction, and so instructions typically take the form of commands.
2.2.1 A Typical Alert
A typical scenario has TelAlert running on the same server machine as a network management application (referred to here as the “controlling application”). This application has been configured to respond to certain network events by passing an appropriate command to TelAlert using
telalertc. Thus, when the controlling application detects a node failure, for example, it issues a
command to TelAlert, along with the message to be delivered.The following diagram shows how a network monitoring application, on detecting that a server is down, could use TelAlert to send a message to a single text pager:
Figure 1. A Typical TelAlert Send
First, the controlling application issues the following command:
telalertc -i BobTextPager -m "node 2745 down"
This command invokes telalertc(the command-line client), which passes the command to
telalerte (the primary TelAlert server process).
telalerte then looks in telalert.sects, the compiled version of the telalert.ini
configuration file, to find the definition for the recipient, the configuration information for the modem to be used, etc. Next telalerte tells telalertm (TelAlert’s modem daemon, the process that actually controls the modem) precisely what to do, providing it with instructions for dialing the specified service provider, the PIN for this particular recipient, and finally the message itself.2.3 TelAlert Programs and Processes
TelAlert is comprised primarily of two command line programs and six daemon processes, some of which have been mentioned already in this chapter. Each is described in greater detail below.
telaconf
telaconf is the database management system that controls and stores
information on changes you make to your configuration using TelAdmin,
a component of the TelAlert Desktop, the graphical configuration
environment for TelAlert. On Windows, telaconf runs as a service; use
Control Panel/ Administrative Tools/Services
on Windows to make sure the
Startup
parameter is set to
Automatic. However, you should not use the
Start
button in the
Services applet to actually start telaconf;
instead, give the telaconf -start command from a command line.
On UNIX,
telaconf runs as a daemon. To have it start automatically when UNIX boots, look at
telaconf.init.d file, which contains comments about how to customize it and copy it to the
startup directory. It can also be manually started with the command telaconf -start. If an error message such as Error*Can’t connect to host... appears in either a popup box inside TelAdmin, or on the command line, there’s a good chance that telaconf has not been started.telalertc
telalertc is a command line program used to issue notification and response instructions to
telalerte. It can be run on the same machine as the TelAlert server. It can also be installed on
another machine and used to interact with telalerte remotely.telalertc is a client program designed for end users. It lacks certain administrative commands
that control the way TelAlert works.telalert
telalert is a command line program used to issue administrative instructions to telalerte. It
can also be used to issue the same notification and response instructions as those supported bytelalertc.
telalerth
telalerth is a CGI application that allows a Web server to communicate with telalerte. For
instance, if you set up a Web form for users to acknowledge or send alerts, telalerth takes the information sent via this form to the Web server and passes it to telalerte in a formtelalerte can understand.
telalerte
telalerte is the TelAlert server, the central nervous system of TelAlert. A continually running
daemon process, telalerte takes commands and messages received by telalert and renders them complete, incorporating information referred to in the TelAlert configuration file. It then passes complete instructions to the daemon responsible for carrying out the responsibility at hand.Telalerte tracks all TelAlert activity, recording it in a comprehensive events file called
telalert.trail. It maintains a record of all active alerts in telalert.alert.
telalerte is also the part of TelAlert that processes responses and requests. If a message
recipient dials in and acknowledges receipt of a message using TelAlert’s voice menus, this response is passed by telalertd (the daemon handling interactions with the TelAlert Dialogic telephony card) to telalerte, which updates the status of the alert (internally and, where applicable, with the monitoring application that originally issued the command) to reflect the acknowledgment. Similarly, if someone uses telalert to request a list of all active alerts, it istelalerte that retrieves this information and passes it to telalert for display.
telalertm
telalertm is the process responsible for dialing the modem of the server machine on which
TelAlert is installed and, following instructions passed to it by telalerte, sending and receiving information over this connection. Telalertm handles only numeric and text paging and polling.telalert vs. telalertc
telalertr
telalertr is the process responsible for controlling electronic signboards and other RS232
devices (excluding modems).telalerts
telalerts is the process responsible for all sockets-based TelAlert interactions. It communicates
with SMTP and SNPP servers to send email and online pages, respectively.readmail
TelAlert comes with an email-reading program (readmail, or readmail.exe for Windows) that allows TelAlert to accept and process replies using email. This includes replies to messages sent straightforwardly as emails and replies to certain two-way pager notifications (PageNet and
WebLink Wireless) that take the form of emails. See the section “Handling Responses to Email With Readmail” in Chapter 9 of this manual for more information.
2.4 Key TelAlert Files
Below is a description of some of the key files comprising a TelAlert installation.
telalert.trail
telalerte records all TelAlert activity in this file. When it reaches a specified size (100 K is the
default), the file name is changed to telalert.trbak and telalerte begins a new trail file. This backup file will be overwritten each time the current trail file reaches 100 K. (TheTrailSwitchCmd= line in the [Files] section lets you define an external process for archiving
the data in these backup .trail files.)telalert.alert
Maintained by telalerte, telalert.alert is a continuously updated file containing all the information TelAlert needs to process all active alerts.
telalert[e/f/r/s/d/m/h/v].log
By default, TelAlert maintains a separate log file for each of the daemon processes.
telalert.ini
This is TelAlert’s configuration file. It contains a variety of information that TelAlert uses to carry out commands. This includes licensing details; information about ports, devices, groups, schedules, and users; and instructions about sending messages to specific destinations and general
destination types.
telalert.ini is divided into “sections” headed by words enclosed in “straight” [brackets]. Many
of these sections are further subdivided into “definitions” headed by words enclosed in “curly” {braces}. Lines in the telalert.ini file that are neither section nor definition headings take the form keyword=value, where keyword is any of the many words TelAlert is programmed to recognize (including but not limited to section names), and value is the value you assign (including but not limited to definition names).The telalert.ini file can be configured directly, using a text editor. The other
configuration/administration option is to use TelAdmin, a Windows application, to modify the
telalert.sects file (the compiled version of the telalert.ini file; see below). For a more
in-depth discussion of these two options, refer to the TelAlert Desktop Guide.telalert.sects
This is the compiled version of the telalert.ini file. Strictly speaking, telalerte reads this file, not telalert.ini, in order to process commands. You can control the way TelAlert works by using TelAdmin to modify this file—as opposed to editing the telalert.ini file directly. For more information on the two configuration options, refer to the TelAlert Desktop Guide.
2.5 Key Configuration Concepts
In order to understand your notification and response objectives, TelAlert relies on two sources of information. The first is the command interface (be it command line, API functions, or Java methods), which may be used by another program or a human user. The second is the TelAlert configuration file—telalert.ini—or, more directly, its compiled version, telalert.sects. These two sources are heavily dependent on one another. While it is possible to pass varying amounts of information directly on the command line, virtually all commands use configuration keywords to make explicit reference to information stored in the configuration file.
For example, to send a message to Bob’s text pager, you might use the following command:
telalertc -c SkyTelNationalTextPager -pin 1234567 -m "node 2745 down"
Here, -c tells TelAlert to understand SkyTelNationalTextPager as a reference to the[Configurations] definition of the same name. This definition contains information on how to
use the SkyTel service, but the PIN for the intended individual recipient is passed here on the command line, as is the message itself (the text following -m, which is best enclosed in quotation marks).Alternatively, you could issue a command referring to a specific “destination” (see below) defined in the configuration file. For instance:
telalertc -i BobTextPager -m "node 2745 down"
Here, -i tells TelAlert to understand BobTextPager as referring to an individual
[Destinations] definition (as opposed to a [Configurations] or [Group] definition,
signaled by –c and -g, respectively). Typically, {BobTextPager} would include the PIN and, by means of a keyword reference, needed configuration information (that stored in the definition of, for instance, {SkyTelNationalTextPager}).2.5.1 Sections, Definitions, Keywords, and Cross-Referencing
telalert.ini is divided into “sections” headed by words enclosed in “straight” [brackets]. Many
(but not all) of these sections are further subdivided into “definitions” headed by words enclosed in “curly” {braces}. Lines in the telalert.ini file that are neither section nor definition headings take the form keyword=value, where keyword is one of the many words TelAlert isprogrammed to recognize (including but not limited to section names), and value is the value you assign (in some cases an integer; in others, True/ False or a definition name).
Generally, a definition represents a specific instance of the concept underlying that section. For instance, an entry under [Configurations] contains configuration information for a specific instance of a general medium type—such as a pager type, an email gateway, or an electronic signboard. An entry under [Destinations] contains the information specific to a given destination (e.g., an individual’s pager), as well as a keyword-based reference to the general configuration information for that type of pager.
A [Destinations] definition might look something like this:
{LauraTextPager}
Configuration=SkyTelNationalTextPager
PIN=4850879
The second line of this definition refers to the entry in the [Configurations] section called
{SkyTelNationalTextPager}, which might look something like this:
{SkyTelNationalTextPager}
Type=TextPager
AreaCode=800
Number=6792778
Speed=19200
2.5.2 Configuration
The [Configurations] section contains entries defining basic configuration information for different media types (e.g., email, a specific kind of pager, or an electronic signboard model). These definitions can be drawn from external files using $include relativepath/filename. TelAlert ships with a
telalert.ini file filled with commented-out $includefile references and a set of files containing
[Configurations] definitions for a wide range of paging service providers.
2.5.3 Destination
The [Destinations] section contains entries defining specific “destinations” such as a text pager belonging to David, his home telephone number, the email address of Joan, or a specific instance of a certain type of electronic signboard. Typically, some of the information for a
[Destinations] definition is drawn from a [Configurations]entry. For instance,
{DavidPager} might include a Configuration=TextPager line, where TextPager points
to the [Configurations] definition of the same name, which may be shared by manydestinations.
Some destinations (a signboard, for instance) have nothing to do with any person. Others may make reference to a person by means of a User= line. Since it may be possible for TelAlert to contact a person via several different destinations, this optional line allows TelAlert to recognize destinations in terms of the person they have in common. Such an association may be useful if you want to analyze sent messages in terms of the people to whom (rather than destinations to which) they were sent.
Sectional Default Values
2.5.4 User
“Users,” defined individually in the [User]section and referred to elsewhere in telalert.ini by User= lines, represent the people associated with destinations (some other parts of the
telalert.ini file permit association with a user, as well). Generally speaking, this is an
optional aspect of TelAlert configuration: most [Destinations] definitions do not have to be associated with a user. Creating such associations, however, is the key to several important techniques:By including a User= line in a [Destinations]definition, you cause it to inherit values contained in the invoked [User] definition: Schedule, Password, etc. This tells TelAlert how to assess the destination’s validity (i.e., by referring to the schedule), or how to determine the identity of someone with whom it is interacting (i.e., by asking for a password when the person attempts to respond to a notification).
Moreover, whenever [Destinations] definitions are associated with users, it is possible to track messages in terms of the people to whom they were sent. This is helpful because it may be possible to notify a single person via a number of different destinations. While the “user” concept can be very helpful, not all organizations use it when implementing TelAlert. Some simply create a general user—{Operator}—and invoke this user by keyword (User=Operator) wherever necessary. Others may have no need to use this keyword at all.
2.5.5 Group
A group is a collection of destinations. Under the [Group] section of telalert.ini, each entry is identified by a name in {braces}, and all of the destinations in that group are invoked by means of a single keyword line. For instance:
Destinations=BobHomePhone,LauraTextPager,JohnEmail
Sending a message to a group means sending it to all of the destinations comprising that group, either all at once or one at a time, according to specified rules. For instance, if a
[Destinations]definition invokes a [Schedule] entry, TelAlert has to evaluate the schedule
to see if the destination is valid at that time. The priority of the message may override theschedule for the destination, in which case TelAlert will send to it anyway; otherwise, it may move on to the second destination. Similarly, when TelAlert is instructed to send to one destination and wait for a positive acknowledgment before sending to another, it begins by looking through the list for the first [Destinations] definition that it can use, based on the rules that have been set up. When it succeeds in sending the message, it waits for acknowledgment for a specified time before locating the next valid entry and sending the message to this destination.
[Group] definitions are critical to TelAlert’s escalation capability (as is the concept of strategy;
refer to the Strategy section, below). Only by setting up a [Group] definition and invoking it in a command can you ensure that a message reaches someone who can handle the problem, even if the initial send fails or goes unacknowledged.Alternatively, creating a group comprised of all the destinations associated with one person allows you to send a message to that person without specifying a particular destination. As long as each of these destinations is associated with a schedule, TelAlert will examine them one by one until it finds the right one to use, based upon its schedule.
2.5.6 Schedule
A schedule is a list of times during which a destination is considered available, or “on duty.” A
[Destinations] definition can invoke a schedule by means of a keyword referring to an entry
in the [Schedule] section. If a destination is linked with a [User] definition, however, this definition may invoke the schedule instead—so that the destination refers to a user, which in turn refers to an entry under [Schedule].Having one [Schedule] definition associated with a [Destinations] definition means that TelAlert will use that schedule to assess that destination and then either send the notification to it or not. But you can include more then one schedule reference in a [Destinations] definition, which allows TelAlert to decide what to do based on the message’s priority. For example:
{JohnPager}
...
User=John
Schedule=RegularSchedule
AlternateSchedule=LateShift
...
{RegularSchedule} and {LateShift} appear under [Schedule], with {LateShift}
defined so that it includes the hours comprising {RegularSchedule} and additional hours as well. Then you might include the following line as part of the [User] definition representing John:AlternateSchedulePriority=80
Thus, when TelAlert processes a message of priority 80 or higher, it finds it is permitted to send it to {JohnPager}, even if it comes at a time outside of his normal schedule (assuming it falls within the hours of his alternate schedule).
2.5.7 Strategy
Entries under [Strategy] are relevant for a message sent to a group and are referred to in
[Group] definitions. They determine two things: (1) how TelAlert recognizes an alert as complete
and (2) under what conditions it escalates the alert by sending to a subsequent destination. The first is accomplished through a Complete= line. For instance,Complete=acked>0
tells TelAlert to consider the alert complete when it receives positive acknowledgment from any recipient.
An Escalate= line tells TelAlert under what conditions to escalate the alert. For example,
Escalate=Incomplete=0
tells TelAlert to escalate the alert to the next sub-group when the number of sends in an “incomplete” state (i.e., those marked Active, Pending, or AckWait) equals zero. Together, these two lines form a commonly used [Strategy] definition called
{FirstAcknowledge}. Under the terms of {FirstAcknowledge}, the alert will be escalated
until it has been acknowledged once (and thus has been completed); assuming noIf the requirements for completion (set in the Complete= line) are met, TelAlert always ceases escalation, even if the conditions for escalation (set in the Escalate= line) remain unmet. TelAlert allows you to set a higher standard for completion in case you want to keep an alert active (for tracking purposes, say) even after escalation has ceased.
A default strategy may be invoked under [Group] using a Strategy= line placed before the first definition. A group may also invoke its own strategy using a Strategy=line; these group-specific strategies override the default. In the absence of a reference to a [Strategy] definition, no escalation occurs; TelAlert sends to all destinations at once. Note that when you send a message to a group that includes one or more other groups, TelAlert uses the strategy defined in the group to which the message is addressed, and ignores any Strategy= lines in the subsidiary groups.
2.5.8 Other Configuration File Sections
There are a number of other sections comprising the telalert.ini file. Some of these, like the ones described above, provide a means of controlling the way TelAlert interacts with users. Others pertain to TelAlert’s internal functioning or its interaction with various optional components. Each of these is described briefly below. All the behavior governed by these other sections can be modified using TelAdmin, as well. For more information on these two configuration options, refer to the
TelAlert Desktop Guide.
[Access]
Configures the prompts issued by TelAlert in both dial-in and dial-out calls.
[Analog]
Used to configure certain environmental monitors which connect via the Sensor Interface Unit. (Obsolete - TelAlert Classic Engine only.)
[Battery]
Specifies the battery charge level range to monitor and the means of notification when this range is exceeded. (Obsolete - TelAlert Classic Engine only.)
[CallProgress]
Contains values associated with the ability of the Dialogic telephony card to listen for and recognize various telephone rings and voice interaction cues.
[Files]
Allows you to configure TelAlert’s standard logging activity.
[Filter]
[Heartbeat]
Contains values relating to TelAlert’s ability to notify other applications or scripts regarding changes in the status of TelAlert.
[License]
Contains settings related to your TelAlert software license that allow TelAlert to function according to its terms.
[Limits]
Establishes values for miscellaneous parameters internal to the TelAlert software.
[Menu]
Specifies how the Dialogic telephony card prompts and receives input from users.
[Message]
Defines rules for modifying a message so it can be sent to a group of destinations with varying display capabilities.
[Modem]
Configures numerous modem parameters.
[Notifications]
Specifies when and how TelAlert should deliver information to the trouble ticketing or other application with which it is integrated.
[Patterns]
Specifies patterns that can be used to view, manage, and modify alerts in progress.
[PhonePrefixes]
Specifies the phone prefix information associated with the telephone lines used by TelAlert.
[Port]
Defines the connections TelAlert uses to send notifications.
[Power]
[Process]
Allows you to configure TelAlert’s control over helper applications such as Readmail.
[Relay]
Allows you to configure TelAlert’s control over devices connected to the TelAlert Relay Interface Unit. (Obsolete - TelAlert Relay Interface Unit only.)
[Response]
Defines any responses that recipients may be able to make after receiving a message.
[Sensor]
3
Implementation Planning
3.1 Overview
An introduction to the work of setting up TelAlert to meet your organization’s unique notification needs.
3.2 Your Accomplishments So Far
Chapter 1: Introduction and Chapter 2: Technical Overview provide a conceptual understanding
of TelAlert, from both a product and a technical perspective. This chapter is designed to acquaint you with the major issues you will face as you prepare to implement TelAlert in ways that make sense for your company. It also explains how the organization of the Administrator Guide is connected to the work you have ahead of you.
Here it is assumed that you have read the previous chapters and are familiar with basic TelAlert terminology. Further, by now you should have installed the product following instructions in the
Chapter 16: Miscellaneous Administrative Tasks and checked your installation by sending a
test page. Also, you should have read the integration guide pertaining to any third-party product(s) with which you plan to integrate TelAlert. As you will see, integration accompanies rather than follows general implementation, and, as you move ahead, it will be helpful to understand what kind of integration you need to perform.
Integration Assumptions
TelAlert is designed to work with a controlling application. Many such applications control TelAlert via the command line—either directly, issuing a TelAlert command just as a human user might, or indirectly, invoking a script that builds and issues a TelAlert command. (Some others call TelAlert APIs or Java classes to communicate directly with TelAlert.) Because the command itself is the key to achieving the desired TelAlert behavior, the rest of the
Administrator Guide focuses on these commands and associated parameters, ignoring the
different ways they might be produced in different integrations.
