IVR Applications Description
Neda Document Number: 103-102-06
Last Updated: 2000/03/23 18:31:30
Doc. Revision: 1.1.1.1

Neda Communications, Inc.
17005 SE 31st Place
Bellevue, WA 98008

November 11, 1999

Contents

• 1 Introduction
  • 1.1 Conventions
  
  
• 2 Public Applications
  • 2.1 Features Test
    • 2.1.1 Introduction
    • 2.1.2 Required list of VOX files
    • 2.1.3 Sample run script
    • 2.1.4 Origin
    • 2.1.5 Main Features
    • 2.1.6 Status
    • 2.1.7 External processes
  • 2.2 Catch Missed DTMFs
    • 2.2.1 Introduction
    • 2.2.2 Required list of VOX files
    • 2.2.3 Sample run script
    • 2.2.4 Origin
    • 2.2.5 Main Features
    • 2.2.6 Status
    • 2.2.7 External processes
  • 2.3 System Management
    • 2.3.1 Introduction
    • 2.3.2 Required list of VOX files
    • 2.3.3 Sample run script
    • 2.3.4 Origin
    • 2.3.5 Main Features
    • 2.3.6 Status
    • 2.3.7 External processes
  • 2.4 The V Compiler
  
  
• 3 Private Applications
• 4 POTS Access to Neda's Messaging Services (IVRMSG)
  • 4.1 Introduction
    • 4.1.1 Objectives
  • 4.2 Description
    • 4.2.1 Interactive Voice Response Menu
    • 4.2.2 Normal Operation With Successful Outcome
    • 4.2.3 Checking Message Status
    • 4.2.4 Access to Subscriber's Reply
    • 4.2.5 Subscriber Message Retrieval from MC
  • 4.3 User Interface
  
  
• 5 Dialout
  • 5.1 Dialout
    • 5.1.1 Introduction
    • 5.1.2 Required list of VOX files
    • 5.1.3 Sample run script
    • 5.1.4 Origin
    • 5.1.5 Main Features
    • 5.1.6 Status
    • 5.1.7 External processes
  
  
• 6 Indirect
  • 6.1 Indirect program
    • 6.1.1 Introduction
    • 6.1.2 Required list of VOX files
    • 6.1.3 Sample run script
    • 6.1.4 Origin
    • 6.1.5 Main Features
    • 6.1.6 Status
    • 6.1.7 External processes
  
  
• 7 Hertz
  • 7.1 Hertz Program
    • 7.1.1 Introduction
    • 7.1.2 Required list of VOX files
    • 7.1.3 Sample run script
    • 7.1.4 Origin
    • 7.1.5 Main Features
    • 7.1.6 Status
    • 7.1.7 External processes
  
  
• 8 Attendant
  • 8.1 Attendant program
    • 8.1.1 Introduction
    • 8.1.2 Required list of VOX files
    • 8.1.3 Sample run script
    • 8.1.4 Origin
    • 8.1.5 Main Features
    • 8.1.6 Status
    • 8.1.7 External processes
  
  
• 9 Recordex
  • 9.1 Recordex Program
    • 9.1.1 Introduction
    • 9.1.2 Required list of VOX files
    • 9.1.3 Sample run script
    • 9.1.4 Origin
    • 9.1.5 Main Features
    • 9.1.6 Status
    • 9.1.7 External processes
  
  
• 10 Alarm
  • 10.1 Alarm program
    • 10.1.1 Introduction
    • 10.1.2 Required list of VOX files
    • 10.1.3 Sample run script
    • 10.1.4 Origin
    • 10.1.5 Main Features
    • 10.1.6 Status
    • 10.1.7 External processes
  
  
• Bibliography

1 Introduction

This document defines the collection of Neda's Interactive Voice Response (IVR) Applications.

Distribution of this document in its present form should be limited to the parties directly involved in planning and creating a document for Neda Communications, Inc. Overtime this document will be available for public.

This document must be read with other Neda's documents: Open C Platform[1] and VoRDE Programmers Manual[2].

1.1 Conventions

2 Public Applications

2.1 Features Test

featuresTest is a program that demonstrate the ability to receive DTMF digits.

2.1.1 Introduction

Using an Interactive Voice Response (IVR) capability, callers will be able to provide the DTMF digits required and then the program will verify those digits. The verification process will determine whether the caller pass or fail the test.

2.1.2 Required list of VOX files

Following vox files are required for the application.

	welcome.vox
	passed.vox
	failed.vox

2.1.3 Sample run script

#!/bin/sh
#

./featuresTest -p 1 -c featuresTest.ini

2.1.4 Origin

2.1.5 Main Features

  - Answer a call and play a greeting message
  - Request and receive the DTMFs digits
  - If the user enter the correct digits, play a ``pass the test'' message
    otherwise play a ``fail the test'' message and terminate the process

2.1.6 Status

Functional.

2.1.7 External processes

None.

2.2 Catch Missed DTMFs

catchMissedDTMFs is a program that demonstrate the ability to receive DTMF digits.

2.2.1 Introduction

Using an Interactive Voice Response (IVR) capability, callers will be able to provide the DTMF digits required and then the program will verify those digits. The verification process will determine whether the caller pass or fail the test. This program is almost the same as featuresTest but catchMissedDTMFs will record the DTMFs entries to a vox file called monitor.vox. It will also identify the caller with its callerId feature.

2.2.2 Required list of VOX files

Following vox files are required for the application.

	welcome.vox
	passed.vox
	failed.vox

2.2.3 Sample run script

#!/bin/sh
#

./catchMissedDTMFs -p 1 -c catchMissedDTMFs.ini

2.2.4 Origin

2.2.5 Main Features

  - Answer a call and play a greeting message
  - Identify the caller using callerId feature
  - Request and receive the DTMFs digits
  - Record the DTMFs received to monitor.vox file
  - If the user enter the correct digits, play a ``pass the test'' message
    otherwise play a ``fail the test'' message and terminate the process

2.2.6 Status

Functional.

2.2.7 External processes

None.

2.3 System Management

2.3.1 Introduction

Using an Interactive Voice Response (IVR) capability, callers will be able to provide the DTMF digits required and then the program will verify those digits. The verification process will determine whether the caller pass or fail the test. This program is almost the same as catchMissedDTMFs with the exception of playing the vox file.

2.3.2 Required list of VOX files

Following vox files are required for the application.

	welcome.vox
	passed.vox
	failed.vox

The size of these vox file are zero. They only serve as dummy files.

2.3.3 Sample run script

#!/bin/sh
#

./sysMgmt -p 1 -c sysMgmt.ini

2.3.4 Origin

2.3.5 Main Features

  - Answer a call
  - Request and receive the DTMFs digits
  - Record the DTMFs received to monitor.vox file
  - If the user enter the correct digits, play a ``pass the test'' message
    otherwise play a ``fail the test'' message and terminate the process

2.3.6 Status

Functional.

2.3.7 External processes

None.

2.4 The V Compiler

3 Private Applications

4 POTS Access to Neda's Messaging Services (IVRMSG)

4.1 Introduction

Using an Interactive Voice Response (IVR) capability, calllers will be able to communicate with two-way subscribers through PSTN/POTS.

Using the IVR functionality, the callers will be able to:

• originate numeric paging,
• originate alphanumeric messages through a dispatch center,
• leave a voice mail message followed by a voice mail notification,
• check responses.

Also, using the IVR functionality, the subscribers should have access to the MC stored messages.

4.1.1 Objectives

The major marketing objectives aroe to:

• Encourage two-way messaging service usage by making access methods (IVR) simple and efficient to use. This means to:
  1. provide one number access to all telephone access method of message origination (operator dispatch/text messaging, voice mail, numeric messaging).
  2. create intuitive and efficient navigation through the IVR, especially for those services that are used most often (i.e. send numeric page).
  3. provide subscribers access to message (which have been submitted for them) via the IVR (text-to-speech) while they are traveling outside the coverage area. (This will be particularly important in the early days when coverage is limited or when subscribers travel to countries without a pACT network.)
• Increase the value of ancillary services to subscribers by making ancillary services more accessible to message originators. Subscribers are more likely to sign up for ancillary services (voice mail, operator dispatch, ``meet me'' service) if message originators are willing to use them. Message originators are more willing to use them if they have easy access to them.

4.2 Description

IVR provides capability for a caller to originate message and to check message status. Several services may use IVR capability. These services may include human interaction (e.g. operator services) to originate messages, or they may be restricted to equipment interactions between a WES to acknowledge the network the receipt of a message. This IVR capability description includes capabilities related to the user interface and interaction between different network elements.

The callers, subscribers or non-subscribers, should be able to get access to all of the following options via a single number:

• Numeric Paging. If the caller chooses to send a numeric paging message, the system prompts the caller to enter through DTMF a call back telephone number. The call back number may be palyed back for caller verification.
• Record a Voice Message. If the caller chooses to leave a voice mail message instead of sending a message, they should be transferred to the subscriber's voice mail system. The subscribers' voice mail system should be configured to generate a notification message which should be sent to their WES.
• Transfer to a Dispatch center for alpha messages.
• Retrieve Responses. If the caller selects the option to check the message status a generic information related with the customer mailbox or a specific information related with a specific message can be played.

The subscriber should have access to the MC stored messages using text-to-speech translation.

IVR requires caller information be sent from the caller to the network. Data which must be sent includes destinations address, message type, message content, and origination address. The message type provides information about the purpose of the message, such as if it is a system acknowledgement, user acknowledgement, numeric paging, alpha message, or response to a message. The message content provides the information that is displayed or used by the receiving equipment or subscriber (e.g. call back number or free text entered by an operator). The origination address provides the identity of the caller that is originating the message. An optional urgency indicator is also available for message originators who wish to attach an urgency level to the message (the urgency level is an annotation only and does not speed delivery through the network).

4.2.1 Interactive Voice Response Menu

The caller's interface should allow an experienced caler to bypass system prompts. Independent of the access method, after the greeting, the caller will be prompted to identify the subscriber. A menu should provide options that depend on what services are listed under subscriber profile.

If new messages are originated, the caller may hang up after 7 or 10 digit numbers are entered. The system should accept this information and rely it to the MC for routing. If a 10 digit number was entered, then the system should append (1).

If the caller requires a reply, the system prompts the caller's confirmation number (CCN).

4.2.2 Normal Operation With Successful Outcome

Incoming calls will be answered by a Front End System (e.g. Summa4 switch) (FES). The Figure 1 depicts the Front End System (FES), the Voice Mail System(s), the Message Center (MC), and the Operator Services System (Op. Serv.). The MC routes all messages to the subscriber's wireless end device.

Figure 1: Normal Operation

The FES answers the call and plays a greeting. If the access method is through a personal 800 number then the calls are answered with a greeting specifically for your subscriber. For all incoming calls

1. FES prompts the caller for the subscriber identification (PIN), if the access method was through a non-personal 800 number.
2. FES adds the MC/VAS on the call and the PIN is verified.
3. If the PIN is correct, the caller is prompted with an appropriate menu to enter the menu option

    1 - numeric paging
    2 - voice mail
    3 or time out - transfer to an operator
   

Case 1 - caller enters digit 1

• Call back number using the DTMF telephone keypad.
• The system (FES/MC) collects the entered call back number and play it back.
• The sysytem prompts caller to confirm the correctness of the number. If it is not, the caller re-enters the call back number. step 4 and 5 repeated until the caller is satisfied that the correct call back number has been recorded.
• After the message has been submitted, the IVR reads a message confirmation number to the caller.
• The MC generates the numeric paging and routes the message to the WES.

Case 2 - caller enters digit 2

• FES transfer the call to the Voice Mail System (VMS).
• The caller is prompted to leave a voice message.
• The VMS stores the message and disconnect the call.
• The VMS generates a VM notification and relays it to the MC.
• The MC generates message and routes the message to the WES.

Case 3 - caller enter digit 3 or a time-out condition occurs

• FES transfer the call to the operator services system/switch (OSS).
• The OSS directs the call to an operator station.
• The OSS collects the PIN and verifies it.
• If the PIN is correct the operator types the message.
• The OSS generates a message and submit it to the MC.
• After the message has been submitted, the IVR reads a message confirmation number to the caller.

Case 4 - caller enters digit 4

• FES transfers the call to the MC system.
• The system plays a generic message or requests the CCN.
• If the CCN is correct, the system plays the message status or reply.

4.2.3 Checking Message Status

WES provides an acknowledgment that a message was accurately received. This acknowledgment is transparent to the user of the WES. The acknowledgment includes address information of the originating message, address of the WES, and the time the message was delivered. The caller should be capable to call and check the status of a previously submitted message.

The caller will be able to check on the status of message up to 72 hours after the message was originally sent. If all subscriber messages are successfully delivered, then a generic system message (e.g. all message were delivered) will be played to the caller and no message identification is needed.

If the delivery status of the message is negative, the system should

• provide a generic prompt (e.g. subscriber's mailbox contains 2 hours old messages),
• retrieve the caller confirmation number, and then
• prompt the caller to indicate whether the system should continue to try to deliver the message.

4.2.4 Access to Subscriber's Reply

The subscriber will be able to check the reply of messages up to 72 hours after the message was originally sent. The caller will be able to check replies in the same way as the caller has access to the message status. Only a caller requesting a reply and indicating a CCN at the time the message was originated will be capable to access message replies.

4.2.5 Subscriber Message Retrieval from MC

The subscriber should have access to the MC stored messages. The access can be through:

• Voice connection using Text-to-Speech translation or
• Data connection using a TAP interface. Subscribers must be able to use properly equipped (hardware and software) PC or other client device to access their mailbox to retrieve new messages.

If the subscriber slects to retrieve messages directly from MC, in the log-in session, subscribers shall be required to enter PIN.

A message including the number and types of new messages should be available. As the subscribers retrieve the new messages, they will be offered the options of repeating, deleting, or sending a reply.

All messages are time stamped and presented to the subscriber in the order of their arrival. The time of a message reception needs to be reported relative to ``now'' (e.g. you received a message 2h and 15min. ago). For message over a day old, it is acceptable to report delivery time in standard format.

The MC should support an integrated mailbox (e.g. one mailbox for all email, paging and notification messages).

4.3 User Interface

1. IVRMSG system goes onhook, waiting for a call.
2. After ring detection it plays introduction message. Example: ``Welsome to Interactive Voice Response System ffor Limited Size Messaging system.''
3. Next play a request for subscriber ID. Example: ``Please enter your subscriber ID.''
4. The subscriber ID entered is checked for correctness and then saved. In case of error, the user is given a second chance to enter a correct subscriber ID.
5. Next plays a request for the recipient subscriber ID. Example: ``Please enter the recipient subscriber ID.''
6. The recipient subscriber ID entered is checked for correctness and then saved. In case of error, the user is given a second chance to enter a correct recipient subscriber ID.
7. Next plays a request for selection. Example: ``Choose from this menu of canned messages:
   1. [1] Will be late.
   2. [2] Got your message.
   3. [3] Yes, can do.
   4. [4] No, can't do
8. The selection entered is checked for correctness and then saved. In case of error the user is given a second chance to enter a correct selection.
9. Next plays a request for second selection. Example: Press
   1. [1] to review your message.
   2. [2] to add additional recipients.
   3. [3] to send the message.
10. The selection entered is cheked for correctness and then saved. In case of error, the user is given a second chance to enter a correct selection. If 1 is selected start at the top with the addition of playing the ID and giving them a chance to change it. If 2 is selected request for additional recipient subscriber ID. If 3 is selected continue.
11. Send the email information to send mail program.

5 Dialout

5.1 Dialout

Dialout is a sample program that demonstrate the ability to dial out using VoRDE. Dialout is also used by Indirect as described in the next section.

5.1.1 Introduction

Using an Interactive Voice Response (IVR) capability, callers will be able to dial any number and receive the status of call. Possible return status may be No Dialtone, Busy, No answer or Answered.

Using the IVR functionality, the callers will be able to:

• Originate phone call to any number.
• Provide the current status of the call.

5.1.2 Required list of VOX files

Following vox files are required for the application.

        None.

5.1.3 Sample run script

#!/bin/sh
#

./dialout.exe  -p 1 -d . -n ,9,,,,,6448026,,,,,,,,,,,,, -T PP_,ffff
   -T VM_,ffff -T G_,ffff

5.1.4 Origin

Demonstration program for VoRDE. Dialout capability was developed for use by Indirect as described in the next section.

5.1.5 Main Features

        Dial out
        Call status

5.1.6 Status

Program ends once the telephone number is dialed. The program needs to wait till proper status is returned.

5.1.7 External processes

None.

6 Indirect

6.1 Indirect program

Indirect proides the means to forward a call to a new number.

6.1.1 Introduction

Dialout is a sample program that demonstrate the ability to receive a call, play greeting. The caller is then instructed to enter a new telephone number to be dialed. One possible usage of the program is to have a incoming 800 number. The caller then can forward the call to a number of their choice.

Using the IVR functionality, the callers will be able to:

• Answer a call and play greeting message.
• Receive any number of DTMF digits.
• Dial the same digits on second telephone line.
• Connect the incoming line to outgoing line.

6.1.2 Required list of VOX files

Following vox files are required for the application.

• entrnu.vox
• indirect.vox

6.1.3 Sample run script

#!/bin/sh
#

./indirect.exe  -p 1 -d "." -x indirect -T PP_,ffff
   -T VM_,ffff -T G_,ffff

echo ""
echo "To see the trace file, run:"
echo tail -f callerIdTest.trace

6.1.4 Origin

Demonstration program for VoRDE.

6.1.5 Main Features

        Receive a call
        Play a greeting message.
        Receive DTMF digits to setup a new call.
        Dial the received digits on a second line.
        Connect the two call together.

6.1.6 Status

The program is designed to switch calls using a switch. The new cards support virtual switch and do not require a physical switch. Current release of the code works with dialogic D4x series and requires a separate switch.

6.1.7 External processes

fork is used to start a second process for dialout.

7 Hertz

7.1 Hertz Program

Credit card verification software.

7.1.1 Introduction

Hertz is a program that provides automatic over the phone credit card verification. Once the credit line is approved, cellular phone device in the Hertz rent car is enabled for normal use.

Using the IVR functionality, the callers will be able to:

• Answer a call and play greeting message.
• Request and receive credit card number.
• Request and receive expiration date.
• Credit card information is sent to another process for verification using IPC.
• Provide for retries in case the credit card information entered is not correct.
• Instruct user and take them through steps needed to activate the cellular phone.

7.1.2 Required list of VOX files

Following vox files are required for the application.

   abort.vox     badgen.vox    five.vox      one.vox       six.vox       two.vox
   approved.vox  eight.vox     four.vox      reactcnf.vox  test.vox      zero.vox
   badcc.vox     entrcc.vox    intro.vox     reactive.vox  thankyou.vox
   badexpr.vox   entrexpr.vox  nine.vox      seven.vox     three.vox

7.1.3 Sample run script

#!/bin/sh
#

./hertz.exe  -p 1 -T PP_,ffff -T VM_,ffff -T G_,ffff

7.1.4 Origin

Demonstration program for AT&T Wireless.

7.1.5 Main Features

        Answer a call and play greeting message.
        Request and receive credit card number.
        Request and receive expiration date.
        Credit card information is sent to another process for verification using IPC.
        Provide for retries in case the credit card information entered is not correct.
        Instruct user and take them through steps needed to activate the cellular phone.

7.1.6 Status

The IVR portion of the code is ported to PC. The Credit verification interface through IPC is not currently ported to PC.

7.1.7 External processes

IPC services are needed.

8 Attendant

8.1 Attendant program

8.1.1 Introduction

Attendant is a sample program demonstrating the ability to answer a line and Play appropriate instructions. The user has the option to leave additional voice messages. Or retrieve the current messages on the system.

Using the IVR functionality, the callers will be able to:

• Answer a call and play greeting message.
• Ability to record a new message.
• Ability to retreive old messages.

8.1.2 Required list of VOX files

Following vox files are required for the application.

   abort.vox
   amessage.vox
   badId.vox
   hello.vox
   nomsg.vox
   thankyou.vox

8.1.3 Sample run script

#!/bin/sh
#

./attendant.exe  -p 1 -T PP_,ffff -T VM_,ffff -T G_,ffff

8.1.4 Origin

Demonstration program for VoRDE.

8.1.5 Main Features

        Answer a call and play greeting message.
        Ability to record a new message.
        Ability to retreive old messages.

8.1.6 Status

Functional.

8.1.7 External processes

None

9 Recordex

9.1 Recordex Program

9.1.1 Introduction

Attendant is a sample program demonstrating the ability to answer a line and Play appropriate instructions. The user has the option to leave additional voice messages. Or retreive the current messages on the system.

Using the IVR functionality, the callers will be able to:

• Answer a call and play greeting message.
• Ability to record a new message.
• Ability to retreive old messages.

9.1.2 Required list of VOX files

Following vox files are required for the application.

   abort.vox
   amessage.vox
   badId.vox
   hello.vox
   nomsg.vox
   thankyou.vox

9.1.3 Sample run script

#!/bin/sh
#

./recordex.exe  -p 1 -d . -T PP_,ffff -T VM_,ffff -T G_,ffff

9.1.4 Origin

Demonstration program for VoRDE.

9.1.5 Main Features

        Answer a call and play greeting message.
        Ability to record a new message.
        Ability to retreive old messages.

9.1.6 Status

Functional.

9.1.7 External processes

None

10 Alarm

10.1 Alarm program

10.1.1 Introduction

Alarm is a program that provides automatic notification of network status using (IVR) Interactive Voice Response system. It's like being in contact with your personal NOC (Network Operation Center) using a regular phone or cellular phone.

Using the IVR functionality, the callers will be able to:

• Initiate calls from alarm program.
• Play a text message indicating current status of the system.

10.1.2 Required list of VOX files

Following vox files are required for the application.

        whenrdy.vox     error.vox       sysidis.vox     alarmis.vox
        confirm.vox     thanks.vox      error.vox

10.1.3 Sample run script

#!/bin/sh
#

./alarmd.exe  -p 1 -T PP_,ffff -T VM_,ffff -T G_,ffff

10.1.4 Origin

Demonstration program for VoRDE.

10.1.5 Main Features

10.1.6 Status

        Not ported to PC due to heavy use of IPC calls.
        Need IPC library for PC environment.

10.1.7 External processes

IPC services are needed.

Bibliography

1

Neda Public Document.
Open C Platform.
Neda Published Document 103-103-01, Neda Communications Inc, Bellevue, WA, October 1996.
Online document is available at http://www.public.neda.com/pubs/biblio/103-103-01/index.html.

2

Neda's Voice Processing Public Document.
VoRDE Programmers Manual.
Neda Published Document 103-102-01, Neda Communications Inc, Bellevue, WA, November 1999.
Online document is available at http://www.vorde.org/pubs/biblio/103-102-01/index.html.