One document matched: draft-tsang-ivrcontrol-00.txt
Internet Engineering Task Force Simon Tsang
INTERNET DRAFT Jerome Privat
draft-tsang-ivrcontrol-00.txt BT Labs
October 1998
Expires in six months
IVR control
Status of this document
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document describes IVR (Interactive Voice Response Unit) control.
It is intended as an input for the device control interface defined by
the IETF.
1. Introduction
The IETF is defining a device control interface between a Media Gateway
Controller (MC) and a Media Gateway (MG). An MC has to be able to
control not only VoIP gateways or Network Access Servers (NAS) but
should also be generic enough to control devices like IVRs or ACDs. IVR
control is essential to provide user interaction in services.
The IVR control requirements outlined in this document should be
provided by a solution which is common across all the VoIP protocols.
However, the terminology and architecture adopted in this document are
targetted specifically at the IETF device control working group.
2. What is an IVR?
An IVR (Interactive Voice Response unit) is a specialised resource which
provides network facilities for interacting with a user or call party.
The IVR functionality may be integrated into a Media Gateway (MG) or
exist as a standalone unit. This is illustrated in Figure 1 which shows
Media Gateway 1 with an integrated IVR unit and Media Gateway 2
utilising an external IVR unit.
+--------------+
| |
| MC |
| |
+--------------+
/ | \
/ | \
/ +--------+ \
/ |external| \
/ | IVR |\\ \
/ +--------+ \\ \
+--------------+ +--------------+
| | | |
| MG1 |=============| MG2 |
| +IVR | | |
+--------------+ +--------------+
single line: control channel
double line (=== or \\): bearer channel
Figure 1: IVR elements in VoIP network
IVR uses include:
- DTMF digit collection
- The ability to play prompts and announcements (e.g. inband tones on a
phone or text messages on a terminal)
- The ability to inject tones (e.g. call waiting tone) mid call
- Speech recognition (NB. this is another form of digit collection)
- Record a message on the IVR
- The ability to hold a call, while playing an announcement
- The ability to “park” a call while playing an announcement
An IVR can be under the control of a Media Controller (MC) or another
call or service control entity. Mechanisms must exist to allow the IVR
to report the results of the user interaction to the Media Controller.
As with Media Gateways, it is envisaged that external IVRs will
register themselves with a Media Controller when they are activated in
the network. If a Media Gateway has internal IVRs, these should be
registered with the Media Controller as part of the Media Gateway/Media
Controller discovery procedure.
It is envisaged that external IVRs will have different levels of control
intelligence. Some may have only bearer control capabilities, while
others may have the ability to run scripts. The minimum required by an
external IVR is bearer control and the ability to understand
instructions from the Media Controller.
3. When is IVR control needed?
IVR control is needed whenever user notification or interaction is
required. This covers all phases of the call: call establishment, mid
call, and call release. Examples of possible IVR involvement and
functionality include:
Call Establishment:
- Secure access service: Play a prompt or announcement to the caller to
enter User ID and PIN number. Collect these from the caller and pass
this information to the service intelligence for authentication. If
authentication succeeds, prompt the caller to dial a number and collect
digits.
- Directly connected customer: Apply dial-tone, collect DTMF digits,
and insert DTMF tones when the user “off-hooks”.
Mid Call:
- Call waiting: Inject (switch in) call waiting tone into the user’s
current call to indicate that there is a call waiting.
- Pre-paid card service: If the user is using a pre-paid card service,
inject a tone or announcement to indicate to the user when they are “low
on credit”.
Call Release:
- Televoting service: After the caller has dialled the specific voting
number, it is advantageous if the call control or service intelligence
can simply “park” the call onto an IVR rather than keeping the call
context alive until the user “on-hooks” and clears the call. The caller
will then hear an announcement (e.g. “Your vote for xxxx has been
logged. Thank you. Please hang up.”) until they hang up and release th
call.
- Calling party call release: When the calling party clears the call,
it may be desirable to connect the called party to an announcement (e.g.
“The other party has ended the call. Please hang up.”) or tone until
they also clear.
- Called party call release: If the called party clears the call first.
It may be desirable to connect the calling party to an announcement
until they also clear (e.g. “The other party has ended the call. Please
hang-up.”).
- Call re-origination (e.g. Card service): Alternatively after one
party has released the call, IVR functionality may allow the other party
to enter a specific digit sequence and make another call. An
announcement (e.g. “The other party has ended the call. Please press ##
to make another call.”) will be played to indicate this to the user.
4. Connecting to and Disconnecting from an IVR
One of the most important aspects of IVR control is the ability to
connect to and disconnect from an IVR (either internal or external)
without destroying the current call/session context. It is important
that this can be performed numerous times within a call by the Media
Controller. IVRs may be connected to or disconnected from any Media
Gateway in the IP network.
4.1 Media Gateway has internal IVR
The simplest case is when an internal IVR is used by a Media Gateway.
The Media Controller controls the IVR by sending instructions to the
Media Gateway. One possible case is illustrated by the high-level
information flow provided in Figure 2 and Table 1. This information
flow shows the case when a call arrives at Media Gateway 1, the MC
requires further digits to complete the call and uses MG 1’s IVR to
obtain the information. The call terminates on MG 2.
(from SG)
|
| (1)
|
+--------------+
| |
| MC |
| |
+--------------+
/ \
(2,4,8) / \ (6)
/ (7) \
/ (3,5) \
/ \
/ \
+--------------+ +--------------+
| | (9) | |
| MG1 |=============| MG2 |
| +IVR | | |
+--------------+ +--------------+
single line: control channel
double line (=== or \\): bearer channel
Figure 2: Media Controller controlling internal IVR
------------------------------------------------------------
| No. | Source/Sink | Event |
------------------------------------------------------------
| 1 | SG-MC | Set-up call request |
| 2 | MC-IVR | Prompt and collect for digits |
| 3 | IVR-MC | Digits collected information |
| 4 | MC-MG1 | Connect Message |
| 5 | MG1-MC | Ack message |
| 6 | MC-MG2 | Call Indication message |
| 7 | MG2-MC | Answer message |
| 8 | MC-MG1 | Modify connection message |
| 9 | (action) | Connection between MGs set up |
------------------------------------------------------------
Table 1: Information flows for MC controlling internal IVR
4.2 Media Gateway uses external IVR
When an external IVR is used by a Media Gateway, the procedure to
connect to and disconnect from the IVR is more complex as it requires
interaction with the Media Gateway to set up the bearer to the IVR and
then tear it down when the user interaction is complete. It should be
noted that the Media Controller controls the IVR directly, not through
the Media Gateway. In this scenario, the Media Gateway is only used to
set up and tear down the connection to the IVR.
One possible case is illustrated by the high-level information flow
provided in Figure 3 and Table 2. This information flow shows the case
when a call arrives at Media Gateway 1, the Media Controller requires
further digits to complete the call. Media Gateway 1 connects to the
external IVR to obtain the information. The call terminates on Media
Gateway 2.
(from SG)
|
| (1)
|
+--------------+
| |
| MC |
| |
+--------------+
/ | \
/ | \
/ |(5) \
/(10) |(4,6) (11)\ (12)
(2,7,9,13) / | \
/ | \
+--------------+ | +--------------+
| | | (14) | |
| MG1 |=============| MG2 |
| | | | |
+--------------+ | +--------------+
\\ |
(3,8)\\ |
\\ |
+-------------+
|External IVR |
+-------------+
single line: control channel
double line (=== or \\): bearer channel
Figure 3: Media Controller controlling external IVR
-----------------------------------------------------------------------
| No. | Source/Sink | Event |
-----------------------------------------------------------------------
| 1 | SG-MC | Set-up call request |
| 2 | MC-MG1 | Connect to IVR |
| 3 | (action) | MG1 sets up bearer to external IVR |
| 4 | IVR-MC | IVR indication: ready to receive instructions |
| 5 | MC-IVR | Prompt and collect for digits |
| 6 | IVR-MC | Digits collected information |
| 7 | MC-MG1 | Disconnect from IVR |
| 8 | (action) | MG1 tears down bearer to external IVR |
| 9 | MC-MG1 | Connect message |
| 10 | MG1-MC | Ack message |
| 11 | MC-MG2 | Call indication message |
| 12 | MG2-MC | Answer message |
| 13 | MC-MG1 | Modify connection message |
| 14 | (action) | Connection between MGs set up |
-----------------------------------------------------------------------
Table 2: Information flows for MC controlling external IVR
5. Security Considerations
When an IVR is controlled by a Media Controller across a public IP
network it is very important that only legitimate actions, from a
legitimate source are permitted. Media controllers, Media gateways or
IVR must only accept messages for which IP security provides
authentication. Encryption should also be used to prevent third parties
from eavesdropping.
6. Next step
This document will be followed by another draft outlining in more detail
IVR control requirements. These IVR control requirements will have to be
included in a generic device control protocol.
7. References
* Cuervo, Greene, Holdrege, Ong, Huitema, "SS7-Internet Interworking -
Architectural Framework, draft-greene-ss7-arch-frame-01.txt.
* ETSI, “Intelligent Network (IN); Intelligent Network Capability Set 1
(CS1); Core Intelligent Network Application Protocol (INAP); Part 1:
Protocol Specification”, ETS 300 374-1, DE/SPS-03015, September 1994.
* ETSI, “Intelligent Network (IN); Intelligent Network Capability Set 2,
Intelligent Network Application Protocol (INAP); Part 1: Protocol
Specification for Capability Set 2”, DEN/SPS 03038-1, November 1997.
* ITU-T, “Interface Recommendation For Intelligent Network CS-1”, ITU-
Recommendation Q.1218, March 1993.
* ITU-T, “Interface Recommendation For Intelligent Network CS-2”, ITU-
Recommendation Q.1228, September 1997.
* Bellcore, ISCP-IP Interface specification (1129+), SR-3511, version
4.0, issue 1, October 1995.
8. Acronyms
ACD: Automatic Call Distribution
DTMF: Dual Tone Multifrequency
IVR: Interactive Voice Response (unit)
MC: Media Controller
MG: Media Gateway
NAS: Network Access Server
SG: Signalling Gateway
9. Authors' Addresses
Simon Tsang
BT laboratories, Martlesham Heath
Ipswich, IP5 3RE,
UK
Phone: +44 1473 649441
Email: simon.tsang@bt.com
Jerome Privat
BT laboratories, Martlesham Heath
Ipswich, IP5 3RE,
UK
Phone: +44 1473 648910
Email: jerome.privat@bt-sys.bt.co.uk
DISCLAIMER
Notice: This contribution has been prepared to assist the IETF as a
basis for discussion. It is not a binding proposal on British
telecommunications plc; specifically, British Telecommunications plc
reserves the right to modify, delete and amend any statements contain
herein.
| PAFTECH AB 2003-2026 | 2026-04-24 13:04:30 |