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 users 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 1s 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.