Recording VoiceXML sessions with SIPREC
draft-lum-siprec-vxml-00

Abstract

This document addresses the use case of recording Interactive Voice Response (IVR) VoiceXML applications using the SIPREC protocol. This document also provides a potential solution for capturing additional information about the call flow within the VoiceXML application from a recording perspective.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on January 04, 2014.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Usage
• 1.2. Deployment types
• 2. Recording requirements for VoiceXML applications
• 3. Solution
• 3.1. VoiceXML extensions
• 3.1.1. Recording indication
• 3.1.2. Pause/Resume
• 3.2. DTMF input
• 3.3. Metadata
• 4. IANA Considerations
• 5. Security Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Author's Address

1. Introduction

One of the use case defined in [RFC6341] is the use of recording self-service Interactive Voice Response (IVR) calls. Recording IVR calls are required in some cases to meet compliance requriements or to provide application performance tuning purposes. VoiceXML is the standard for defining a voice dialog, and this document provides a proposed method for providing SIPREC metadata for VoiceXML sessions. A list of requirements is provided define the scope of the solution defined in this document.

1.1. Usage

As VoiceXML is the standard markup for defining voice dialogs, the usage of a voice dialog varies a depending on the use cases. The main use case for VoiceXML application is to provide a self-service voice application, for example, to take self-service orders for the user. In some environments it is required that the voice application must be recorded before any self-service transaction can take place, and this means that the voice application must have some form of awareness that the recording is taking place at the moment before presenting the option of self-service transaction to the user. Certain types of self-service transactions may request the user to enter sensitive information such as a PIN or the CVV of a credit card, and it is required that the VoiceXML application has the ability to explicitly mark certain parts of the application as sensitive portion and that recording is paused while taking senstive data.

Another type usage for a VoiceXML application would be started within a media server dialog to provide basic annoucements, prompts, or controls. This type of usage is typically not related to self-service transactions while does require recording for compliance purposes. Recording may be useful in this context to provide data to help tuning and reporting of the application.

1.2. Deployment types

Depending on the implementation of the IVR and the implementation of the VoiceXML interpreter, there are different ways recording can happen based on the deployment model. As per [RFC5552], the IVR is a SIP User Agent that serves VoiceXML applications. The IVR in this case can be a SIPREC-aware SIP UA and relies on a separate SRC to provide recording capabilities. Being a SIPREC-aware SIP UA allows the IVR to provide recording indications to the VoiceXML application.

The IVR can also be implemented as an SRC so that the IVR can directly initiate recording sessions to an SRS. This gives the IVR more control over local recording policies by ensuring recording can happen before executing certain VoiceXML applications that require recording.

2. Recording requirements for VoiceXML applications

REQ1:

Provide an ability for the VoiceXML application to know that it is being recorded.

REQ2:

Provide an ability for the VoiceXML application to pause/resume certain parts of the application from being recorded

REQ3:

Define the scope which the recording starts or stops within the VoiceXML application.

REQ4:

Capture DTMF input as media or metadata.

REQ5:

Define metadata format to provide essential information about the recorded application.

REQ6:

Define additional metadata to provide detailed information about about the application executed.

3. Solution

3.1. VoiceXML extensions

3.1.1. Recording indication

The VoiceXML interpreter can provide a new session variable called session.recording (a boolean) to indicate whether recording is currently taking place. It is possible that the recording is taking place over the connection by a separate SRC, so a separate session variable called session.connection.recording (a boolean) can indicate whether the recording is taking place over the connection.

If the recording is taking place over the connection while the application is executing, a new event can be thrown so that the application can catch this event. The new event is called connection.record, and the default action would not reprompt so that an application which does not care about this event can simply ignore this event.

3.1.2. Pause/Resume

As the use case for pause/resume is to mask the recording while taking sensitive data, this can map naturally to the <field> element in VoiceXML. A new attribute siprec:mask (boolean) is introduced to note that the field is taking sensitive data and shall mask the audio portion when accepting input for this field. If the IVR is an SRC, then the SRC would initiate a pause request while accepting input for the field, and then resume when the field is filled. If the IVR is a SIPREC-aware SIP UA, then the IVR would request to pause the recording, and it is up to the SRC to determine whether the recording is pause or not.

3.2. DTMF input

The typical input method for an IVR application is DTMF input, and in addition, some VoiceXML applications supports speech input. In order to ensure the recording of the VoiceXML application captures DTMF as input, the media codec telephone-event must be supported to record DTMF input, which is part of the audio media stream.

3.3. Metadata

The IVR is modeled as a participant in a Communication Session. As per [I-D.ietf-siprec-metadata], the participant only contains the address of record. Additional information can be provided about the VoiceXML session to provide more context of about the IVR. Example attributes:

• The URI of the VoiceXML page;
• The session.connection.* session variables;
• Any input parameters to the VoiceXML page, such as parmaters injected by a media server dialog;
• <exit> namelist parameters
• Any additional messages and parameters logged by the VoiceXML application.

Some pieces of metadata relevant to a VoiceXML application may be generated during runtime, for example, the <exit> tag can only happen as the last statement in the application. Any metadata generated after the initial execution of the VoiceXML session may not get a chance to provide the metadata in the initial INVITE or UPDATE in the RS. The SRC would need to initiate an UPDATE to provide additional metadata to the SRS. It is important to note that it is not a good idea to generate an UPDATE every time new messages or parameters are generated by the VoiceXML application, as this can potentially generate large amount of SIP transactions. The SRC should either wait until the end of the VoiceXML session to present all the metadata or limit the rate which UPDATE transactions are generated.

4. IANA Considerations

This document contains no IANA considerations.

5. Security Considerations

Not explicitly covered in this version.

6. References

6.1. Normative References

6.2. Informative References

Author's Address