Internet Engineering Task Force (IETF) S. McGlashan
Request for Comments: 6231 Hewlett-Packard
Category: Standards Track T. Melanchuk
ISSN: 2070-1721 Rainwillow
C. Boulton
NS-Technologies
May 2011
An Interactive Voice Response (IVR) Control Package
for the Media Control Channel Framework
Abstract
This document defines a Media Control Channel Framework Package for
Interactive Voice Response (IVR) dialog interaction on media
connections and conferences. The package defines dialog management
request elements for preparing, starting, and terminating dialog
interactions, as well as associated responses and notifications.
Dialog interactions are specified in a dialog language. This package
defines a lightweight IVR dialog language (supporting prompt
playback, runtime controls, Dual-Tone Multi-Frequency (DTMF)
collection, and media recording) and allows other dialog languages to
be used. The package also defines elements for auditing package
capabilities and IVR dialogs.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6231.
Copyright Notice
Copyright (c) 2011 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
McGlashan, et al. Standards Track [Page 1]
RFC 6231 IVR Control Package May 2011 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 8 3. Control Package Definition . . . . . . . . . . . . . . . . . 9 3.1. Control Package Name . . . . . . . . . . . . . . . . . . 9 3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 9 3.3. Common XML Support . . . . . . . . . . . . . . . . . . . 10 3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . 10 3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 10 3.6. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 11 4.1. <mscivr> . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Dialog Management Elements . . . . . . . . . . . . . . . 14 4.2.1. <dialogprepare> . . . . . . . . . . . . . . . . . . . 18 4.2.2. <dialogstart> . . . . . . . . . . . . . . . . . . . . 20 4.2.2.1. <subscribe> . . . . . . . . . . . . . . . . . . . 24 4.2.2.1.1. <dtmfsub> . . . . . . . . . . . . . . . . . . 25 4.2.2.2. <stream> . . . . . . . . . . . . . . . . . . . . 26 4.2.2.2.1. <region> . . . . . . . . . . . . . . . . . . 27 4.2.2.2.2. <priority> . . . . . . . . . . . . . . . . . 27 4.2.3. <dialogterminate> . . . . . . . . . . . . . . . . . . 28 4.2.4. <response> . . . . . . . . . . . . . . . . . . . . . 28 4.2.5. <event> . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.5.1. <dialogexit> . . . . . . . . . . . . . . . . . . 30 4.2.5.2. <dtmfnotify> . . . . . . . . . . . . . . . . . . 32 4.2.6. <params> . . . . . . . . . . . . . . . . . . . . . . 33 4.2.6.1. <param> . . . . . . . . . . . . . . . . . . . . . 33 McGlashan, et al. Standards Track [Page 2]
RFC 6231 IVR Control Package May 2011 4.3. IVR Dialog Elements . . . . . . . . . . . . . . . . . . . 34 4.3.1. <dialog> . . . . . . . . . . . . . . . . . . . . . . 35 4.3.1.1. <prompt> . . . . . . . . . . . . . . . . . . . . 38 4.3.1.1.1. <variable> . . . . . . . . . . . . . . . . . 39 4.3.1.1.1.1. Date Type . . . . . . . . . . . . . . . . 40 4.3.1.1.1.2. Time Type . . . . . . . . . . . . . . . . 41 4.3.1.1.1.3. Digits Type . . . . . . . . . . . . . . . 42 4.3.1.1.2. <dtmf> . . . . . . . . . . . . . . . . . . . 42 4.3.1.1.3. <par> . . . . . . . . . . . . . . . . . . . . 43 4.3.1.1.3.1. <seq> . . . . . . . . . . . . . . . . . . 45 4.3.1.2. <control> . . . . . . . . . . . . . . . . . . . . 46 4.3.1.3. <collect> . . . . . . . . . . . . . . . . . . . . 49 4.3.1.3.1. <grammar> . . . . . . . . . . . . . . . . . . 52 4.3.1.4. <record> . . . . . . . . . . . . . . . . . . . . 53 4.3.1.5. <media> . . . . . . . . . . . . . . . . . . . . . 57 4.3.2. Exit Information . . . . . . . . . . . . . . . . . . 59 4.3.2.1. <promptinfo> . . . . . . . . . . . . . . . . . . 59 4.3.2.2. <controlinfo> . . . . . . . . . . . . . . . . . . 59 4.3.2.2.1. <controlmatch> . . . . . . . . . . . . . . . 59 4.3.2.3. <collectinfo> . . . . . . . . . . . . . . . . . . 60 4.3.2.4. <recordinfo> . . . . . . . . . . . . . . . . . . 60 4.3.2.4.1. <mediainfo> . . . . . . . . . . . . . . . . . 61 4.4. Audit Elements . . . . . . . . . . . . . . . . . . . . . 61 4.4.1. <audit> . . . . . . . . . . . . . . . . . . . . . . . 61 4.4.2. <auditresponse> . . . . . . . . . . . . . . . . . . . 63 4.4.2.1. <codecs> . . . . . . . . . . . . . . . . . . . . 65 4.4.2.1.1. <codec> . . . . . . . . . . . . . . . . . . . 65 4.4.2.2. <capabilities> . . . . . . . . . . . . . . . . . 66 4.4.2.2.1. <dialoglanguages> . . . . . . . . . . . . . . 68 4.4.2.2.2. <grammartypes> . . . . . . . . . . . . . . . 68 4.4.2.2.3. <recordtypes> . . . . . . . . . . . . . . . . 68 4.4.2.2.4. <prompttypes> . . . . . . . . . . . . . . . . 68 4.4.2.2.5. <variables> . . . . . . . . . . . . . . . . . 69 4.4.2.2.5.1. <variabletype> . . . . . . . . . . . . . 69 4.4.2.2.6. <maxpreparedduration> . . . . . . . . . . . . 70 4.4.2.2.7. <maxrecordduration> . . . . . . . . . . . . . 70 4.4.2.3. <dialogs> . . . . . . . . . . . . . . . . . . . . 70 4.4.2.3.1. <dialogaudit> . . . . . . . . . . . . . . . . 71 4.5. Response Status Codes . . . . . . . . . . . . . . . . . . 71 4.6. Type Definitions . . . . . . . . . . . . . . . . . . . . 77 4.6.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 77 4.6.2. DTMFChar . . . . . . . . . . . . . . . . . . . . . . 77 4.6.3. DTMFString . . . . . . . . . . . . . . . . . . . . . 77 4.6.4. Non-Negative Integer . . . . . . . . . . . . . . . . 77 4.6.5. Positive Integer . . . . . . . . . . . . . . . . . . 77 4.6.6. String . . . . . . . . . . . . . . . . . . . . . . . 78 4.6.7. Time Designation . . . . . . . . . . . . . . . . . . 78 4.6.8. Percentage . . . . . . . . . . . . . . . . . . . . . 78 McGlashan, et al. Standards Track [Page 3]
RFC 6231 IVR Control Package May 2011 4.6.9. URI . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.6.10. MIME Media Type . . . . . . . . . . . . . . . . . . . 78 4.6.11. Language Identifier . . . . . . . . . . . . . . . . . 78 4.6.12. DateTime . . . . . . . . . . . . . . . . . . . . . . 79 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 79 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 105 6.1. AS-MS Dialog Interaction Examples . . . . . . . . . . . . 105 6.1.1. Starting an IVR Dialog . . . . . . . . . . . . . . . 105 6.1.2. IVR Dialog Fails to Start . . . . . . . . . . . . . . 106 6.1.3. Preparing and Starting an IVR Dialog . . . . . . . . 107 6.1.4. Terminating a Dialog . . . . . . . . . . . . . . . . 108 6.2. IVR Dialog Examples . . . . . . . . . . . . . . . . . . . 108 6.2.1. Playing Announcements . . . . . . . . . . . . . . . . 109 6.2.2. Prompt and Collect . . . . . . . . . . . . . . . . . 109 6.2.3. Prompt and Record . . . . . . . . . . . . . . . . . . 111 6.2.4. Runtime Controls . . . . . . . . . . . . . . . . . . 112 6.2.5. Subscriptions and Notifications . . . . . . . . . . . 113 6.2.6. Dialog Repetition until DTMF Collection Complete . . 113 6.3. Other Dialog Languages . . . . . . . . . . . . . . . . . 114 6.4. Foreign Namespace Attributes and Elements . . . . . . . . 115 7. Security Considerations . . . . . . . . . . . . . . . . . . . 116 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 119 8.1. Control Package Registration . . . . . . . . . . . . . . 119 8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 120 8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 120 8.4. MIME Media Type Registration for application/msc-ivr+xml . . . . . . . . . . . . . . . . . 120 8.5. IVR Prompt Variable Type Registration Information . . . . 121 9. Using VoiceXML as a Dialog Language . . . . . . . . . . . . . 122 9.1. Preparing a VoiceXML Dialog . . . . . . . . . . . . . . . 122 9.2. Starting a VoiceXML Dialog . . . . . . . . . . . . . . . 123 9.2.1. Session Protocol Information . . . . . . . . . . . . 124 9.2.2. Session Media Stream Information . . . . . . . . . . 125 9.2.3. Session Parameter Information . . . . . . . . . . . . 127 9.3. Terminating a VoiceXML Dialog . . . . . . . . . . . . . . 128 9.4. Exiting a VoiceXML Dialog . . . . . . . . . . . . . . . . 128 9.5. Call Transfer . . . . . . . . . . . . . . . . . . . . . . 129 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 130 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 130 12.1. Normative References . . . . . . . . . . . . . . . . . . 130 12.2. Informative References . . . . . . . . . . . . . . . . . 132 McGlashan, et al. Standards Track [Page 4]
RFC 6231 IVR Control Package May 2011 1. Introduction The Media Control Channel Framework [RFC6230] provides a generic approach for establishment and reporting capabilities of remotely initiated commands. The Channel Framework -- an equivalent term for the Media Control Channel Framework -- utilizes many functions provided by the Session Initiation Protocol (SIP) [RFC3261] for the rendezvous and establishment of a reliable channel for control interactions. The Control Framework also introduces the concept of a Control Package. A Control Package is an explicit usage of the Control Framework for a particular interaction set. This document defines a Control Package for Interactive Voice Response (IVR) dialogs on media connections and conferences. The term 'dialog' in this document refers to an IVR dialog and is completely unrelated to the notion of a SIP dialog. The term 'IVR' is used in its inclusive sense, allowing media other than voice for dialog interaction. The package defines dialog management request elements for preparing, starting, and terminating dialog interactions, as well as associated responses and notifications. Dialog interactions are specified using a dialog language where the language specifies a well-defined syntax and semantics for permitted operations (play a prompt, record input from the user, etc.). This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, DTMF collection, and media recording) and allows other dialog languages to be used. These dialog languages are specified inside dialog management elements for preparing and starting dialog interactions. The package also defines elements for auditing package capabilities and IVR dialogs. This package has been designed to satisfy IVR requirements documented in "Media Server Control Protocol Requirements" [RFC5167] -- more specifically, REQ-MCP-28, REQ-MCP-29, and REQ-MCP-30. It achieves this by building upon two major approaches to IVR dialog design. These approaches address a wide range of IVR use cases and are used in many applications that are extensively deployed today. First, the package is designed to provide the major IVR functionality of SIP media server languages such as netann [RFC4240], Media Server Control Markup Language (MSCML) [RFC5022], and Media Server Markup Language (MSML) [RFC5707], which themselves build upon more traditional non-SIP languages ([H.248.9], [RFC2897]). A key differentiator is that this package provides IVR functionality using the Channel Framework. Second, its design is aligned with key concepts of the web model as defined in W3C Voice Browser languages. The key dialog management mechanism is closely aligned with Call Control XML (CCXML) [CCXML10]. McGlashan, et al. Standards Track [Page 5]
RFC 6231 IVR Control Package May 2011 The dialog functionality defined in this package can be largely seen as a subset of VoiceXML ([VXML20], [VXML21]): where possible, basic prompting, DTMF collection, and media recording features are incorporated, but not any advanced VoiceXML constructs (such as <form>, its interpretation algorithm, or a dynamic data model). As W3C develops VoiceXML 3.0 [VXML30], we expect to see further alignment, especially in providing a set of basic independent primitive elements (such as prompt, collect, record, and runtime controls) that can be reused in different dialog languages. By reusing and building upon design patterns from these approaches to IVR languages, this package is intended to provide a foundation that is familiar to current IVR developers and sufficient for most IVR applications, as well as a path to other languages that address more advanced applications. This Control Package defines a lightweight IVR dialog language. The scope of this dialog language is the following IVR functionality: o playing one or more media resources as a prompt to the user o runtime controls (including VCR controls like speed and volume) o collecting DTMF input from the user according to a grammar o recording user media input Out of scope for this dialog language are more advanced functions including ASR (Automatic Speech Recognition), TTS (Text-to-Speech), fax, automatic prompt recovery ('media fallback'), and media transformation. Such functionality can be addressed by other dialog languages (such as VoiceXML) used with this package, extensions to this package (addition of foreign elements or attributes from another namespace), or other Control Packages. The functionality of this package is defined by messages, containing XML [XML] elements, transported using the Media Control Channel Framework. The XML elements can be divided into three types: dialog management elements; a dialog element that defines a lightweight IVR dialog language used with dialog management elements; and finally, elements for auditing package capabilities as well as dialogs managed by the package. Dialog management elements are designed to manage the general lifecycle of a dialog. Elements are provided for preparing a dialog, starting the dialog on a conference or connection, and terminating execution of a dialog. Each of these elements is contained in a Media Control Channel Framework CONTROL message sent to the media McGlashan, et al. Standards Track [Page 6]
RFC 6231 IVR Control Package May 2011 server. When the appropriate action has been executed, the media server sends a REPORT message (or a 200 response to the CONTROL message if it can execute in time) with a response element indicating whether or not the operation was successful (e.g., if the dialog cannot be started, then the error is reported in this response). Once a dialog has been successfully started, the media server can send further event notifications in a framework CONTROL message. This package defines two event notifications: a DTMF event indicating the DTMF activity, and a dialogexit event indicating that the dialog has exited. If the dialog has executed successfully, the dialogexit event includes information collected during the dialog. If an error occurs during execution (e.g., a media resource failed to play, no recording resource available, etc.), then error information is reported in the dialogexit event. Once a dialogexit event is sent, the dialog lifecycle is terminated. The dialog management elements for preparing and starting a dialog specify the dialog using a dialog language. A dialog language has well-defined syntax and semantics for defined dialog operations. Typically, dialog languages are written in XML where the root element has a designated XML namespace and, when used as standalone documents, have an associated MIME media type. For example, VoiceXML is an XML dialog language with the root element <vxml> with the designated namespace 'http://www.w3.org/2001/vxml' and standalone documents are associated with the MIME media type 'application/ voicexml+xml' [RFC4267]. This Control Package defines its own lightweight IVR dialog language. The language has a root element (<dialog>) with the same designated namespace as used for other elements defined in this package (see Section 8.2). The root element contains child elements for playing prompts to the user, specifying runtime controls, collecting DTMF input from the user, and recording media input from the user. The child elements can co-occur so as to provide 'play announcement', 'prompt and collect', as well as 'prompt and record' functionality. The dialog management elements for preparing and starting a dialog can specify the dialog language either by including inline a fragment with the root element or by referencing an external dialog document. The dialog language defined in this package is specified inline. Other dialog languages, such as VoiceXML, can be used by referencing an external dialog document. The document is organized as follows. Section 3 describes how this Control Package fulfills the requirements for a Media Control Channel Framework Control Package. Section 4 describes the syntax and semantics of defined elements, including dialog management (Section 4.2), the IVR dialog element (Section 4.3), and audit McGlashan, et al. Standards Track [Page 7]
RFC 6231 IVR Control Package May 2011 elements (Section 4.4). Section 5 describes an XML schema for these elements and provides extensibility by allowing attributes and elements from other namespaces. Section 6 provides examples of package usage. Section 7 describes important security considerations for use of this Control Package. Section 8 provides information on IANA registration of this Control Package, including its name, XML namespace, and MIME media type. It also establishes a registry for prompt variables. Finally, Section 9 provides additional information on using VoiceXML when supported as an external dialog language. 2. Conventions and Terminology In this document, BCP 14 [RFC2119] defines the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In addition, BCP 15 indicates requirement levels for compliant implementations. The following additional terms are defined for use in this document: Dialog: A dialog performs media interaction with a user following the concept of an IVR (Interactive Voice Response) dialog (this sense of 'dialog' is completely unrelated to a SIP dialog). A dialog is specified as inline XML or via a URI reference to an external dialog document. Traditional IVR dialogs typically feature capabilities such as playing audio prompts, collecting DTMF input, and recording audio input from the user. More inclusive definitions include support for other media types, runtime controls, synthesized speech, recording and playback of video, recognition of spoken input, and mixed initiative conversations. Application Server: A SIP [RFC3261] application server (AS) hosts and executes services such as interactive media and conferencing in an operator's network. An AS influences and impacts the SIP session, in particular by terminating SIP sessions on a media server, which is under its control. Media Server: A media server (MS) processes media streams on behalf of an AS by offering functionality such as interactive media, conferencing, and transcoding to the end user. Interactive media functionality is realized by way of dialogs that are initiated by the application server. McGlashan, et al. Standards Track [Page 8]
RFC 6231 IVR Control Package May 2011 3. Control Package Definition This section fulfills the mandatory requirement for information that MUST be specified during the definition of a Control Framework Package, as detailed in Section 7 of [RFC6230]. 3.1. Control Package Name The Control Framework requires a Control Package to specify and register a unique name. The name of this Control Package is "msc-ivr/1.0" (Media Server Control - Interactive Voice Response - version 1.0). Its IANA registration is specified in Section 8.1. Since this is the initial ("1.0") version of the Control Package, there are no backwards-compatibility issues to address. 3.2. Framework Message Usage The Control Framework requires a Control Package to explicitly detail the CONTROL messages that can be used as well as provide an indication of directionality between entities. This will include which role type is allowed to initiate a request type. This package specifies Control and response messages in terms of XML elements defined in Section 4, where the message bodies have the MIME media type defined in Section 8.4. These elements describe requests, responses, and notifications and all are contained within a root <mscivr> element (Section 4.1). In this package, the MS operates as a Control Server in receiving requests from, and sending responses to, the AS (operating as Control Client). Dialog management requests and responses are defined in Section 4.2. Audit requests and responses are defined in Section 4.4. Dialog management and audit responses are carried in a framework 200 response or REPORT message bodies. This package's response codes are defined in Section 4.5. Note that package responses are different from framework response codes. Framework error response codes (see Section 7 of [RFC6230]) are used when the request or event notification is invalid; for example, a request is invalid XML (400), or not understood (500). The MS also operates as a Control Client in sending event notification to the AS (Control Server). Event notifications (Section 4.2.5) are carried in CONTROL message bodies. The AS MUST respond with a Control Framework 200 response. McGlashan, et al. Standards Track [Page 9]
RFC 6231 IVR Control Package May 2011 3.3. Common XML Support The Control Framework requires a Control Package definition to specify if the attributes for media dialog or conference references are required. This package requires that the XML schema in Section A.1 of [RFC6230] MUST be supported for media dialogs and conferences. The package uses "connectionid" and "conferenceid" attributes for various element definitions (Section 4). The XML schema (Section 5) imports the definitions of these attributes from the framework schema. 3.4. CONTROL Message Body The Control Framework requires a Control Package to define the control body that can be contained within a CONTROL command request and to indicate the location of detailed syntax definitions and semantics for the appropriate body types. When operating as Control Server, the MS receives Control message bodies with the MIME media type defined in Section 8.4 and containing an <mscivr> element (Section 4.1) with either a dialog management or audit request child element. The following dialog management request elements are carried in CONTROL message bodies to the MS: <dialogprepare> (Section 4.2.1), <dialogstart> (Section 4.2.2), and <dialogterminate> (Section 4.2.3) elements. The <audit> request element (Section 4.4.1) is also carried in CONTROL message bodies. When operating as Control Client, the MS sends CONTROL messages with the MIME media type defined in Section 8.4 and a body containing an <mscivr> element (Section 4.1) with a notification <event> child element (Section 4.2.5). 3.5. REPORT Message Body The Control Framework requires a Control Package definition to define the REPORT body that can be contained within a REPORT command request, or that no report package body is required. This section indicates the location of detailed syntax definitions and semantics for the appropriate body types. McGlashan, et al. Standards Track [Page 10]
RFC 6231 IVR Control Package May 2011 When operating as Control Server, the MS sends REPORT bodies with the MIME media type defined in Section 8.4 and containing a <mscivr> element (Section 4.1) with a response child element. The response element for dialog management requests is a <response> element (Section 4.2.4). The response element for an audit request is an <auditresponse> element (Section 4.4.2). 3.6. Audit The Control Framework encourages Control Packages to specify whether auditing is available, how it is triggered, as well as the query/ response formats. This Control Package supports auditing of package capabilities and dialogs on the MS. An audit request is carried in a CONTROL message (see Section 3.4) and an audit response in a REPORT message (or a 200 response to the CONTROL if it can execute the audit in time) (see Section 3.5). The syntax and semantics of audit request and response elements are defined in Section 4.4. 3.7. Examples The Control Framework recommends Control Packages to provide a range of message flows that represent common flows using the package and this framework document. This Control Package provides examples of such message flows in Section 6. 4. Element Definitions This section defines the XML elements for this package. The elements are defined in the XML namespace specified in Section 8.2. The root element is <mscivr> (Section 4.1). All other XML elements (requests, responses, and notification elements) are contained within it. Child elements describe dialog management (Section 4.2) and audit (Section 4.4) functionality. The IVR dialog element (contained within dialog management elements) is defined in Section 4.3. Response status codes are defined in Section 4.5 and type definitions in Section 4.6. Implementation of this Control Package MUST address the Security Considerations described in Section 7. McGlashan, et al. Standards Track [Page 11]
RFC 6231 IVR Control Package May 2011 Implementation of this Control Package MUST adhere to the syntax and semantics of XML elements defined in this section and the schema (Section 5). Since XML schema is unable to support some types of syntactic constraints (such as attribute and element co-occurrence), some elements in this package specify additional syntactic constraints in their textual definition. If there is a difference in constraints between the XML schema and the textual description of elements in this section, the textual definition takes priority. The XML schema supports extensibility by allowing attributes and elements from other namespaces. Implementations MAY support additional capabilities by means of attributes and elements from other (foreign) namespaces. Attributes and elements from foreign namespaces are not described in this section. Some elements in this Control Package contain attributes whose value is a URI. These elements include: <dialogprepare> (Section 4.2.1), <dialogstart> (Section 4.2.2), <media> (Section 4.3.1.5), <grammar> (Section 4.3.1.3.1), and <record> (Section 4.3.1.4). The MS MUST support both HTTP [RFC2616] and HTTPS [RFC2818] protocol schemes for fetching and uploading resources, and the MS MAY support other schemes. The implementation SHOULD support storage of authentication information as part of its configuration, including security certificates for use with HTTPS. If the implementation wants to support user authentication, user certifications and passwords can also be stored as part of its configuration or the implementation can extend the schema (adding, for example, an http-password attribute in its own namespace) and then map user authentication information onto the appropriate headers following the HTTP authentication model [RFC2616]. Some elements in this Control Package contain attributes whose value is descriptive text primarily for diagnostic use. The implementation can indicate the language used in the descriptive text by means of a 'desclang' attribute ([RFC2277], [RFC5646]). The desclang attribute can appear on the root element as well as selected subordinate elements (see Section 4.1). The desclang attribute value on the root element applies to all desclang attributes in subordinate elements unless the subordinate element has an explicit desclang attribute that overrides it. Usage examples are provided in Section 6. 4.1. <mscivr> The <mscivr> element has the following attributes (in addition to standard XML namespace attributes such as xmlns): McGlashan, et al. Standards Track [Page 12]
RFC 6231 IVR Control Package May 2011 version: a string specifying the mscivr package version. The value is fixed as '1.0' for this version of the package. The attribute is mandatory. desclang: specifies the language used in descriptive text attributes of subordinate elements (unless the subordinate element provides a desclang attribute that overrides the value for its descriptive text attributes). The descriptive text attributes on subordinate elements include: the reason attribute on <response> (Section 4.2.4), <dialogexit> (Section 4.2.5.1), and <auditresponse> (Section 4.4.2); desc attribute on <variabletype> and <format> (Section 4.4.2.2.5.1). A valid value is a language identifier (Section 4.6.11). The attribute is optional. The default value is i-default (BCP 47 [RFC5646]). The <mscivr> element has the following defined child elements, only one of which can occur: 1. dialog management elements defined in Section 4.2: <dialogprepare> prepare a dialog. See Section 4.2.1. <dialogstart> start a dialog. See Section 4.2.2. <dialogterminate> terminate a dialog. See Section 4.2.3. <response> response to a dialog request. See Section 4.2.4. <event> dialog or subscription notification. See Section 4.2.5. 2. audit elements defined in Section 4.4: <audit> audit package capabilities and managed dialogs. See Section 4.4.1. <auditresponse> response to an audit request. See Section 4.4.2. For example, a request to the MS to start an IVR dialog playing a prompt: McGlashan, et al. Standards Track [Page 13]
RFC 6231 IVR Control Package May 2011 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart connectionid="ssd3r3:sds345b"> <dialog> <prompt> <media loc="http://www.example.com/welcome.wav"/> </prompt> </dialog> </dialogstart> </mscivr> and a response from the MS that the dialog started successfully: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" dialogid="d1"/> </mscivr> and finally a notification from the MS indicating that the dialog exited upon completion of playing the prompt: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr" desclang="en"> <event dialogid="d1"> <dialogexit status="1" reason="successful completion of the dialog"> <promptinfo termmode="completed"/> </dialogexit> </event> </mscivr> The language of the descriptive text in the reason attribute of <dialogexit> is explicitly indicated by the desclang attribute of the <mscivr> root element. 4.2. Dialog Management Elements This section defines the dialog management XML elements for this Control Package. These elements are divided into requests, responses, and notifications. Request elements are sent to the MS to request a specific dialog operation to be executed. The following request elements are defined: <dialogprepare>: prepare a dialog for later execution <dialogstart>: start a (prepared) dialog on a connection or conference <dialogterminate>: terminate a dialog McGlashan, et al. Standards Track [Page 14]
RFC 6231 IVR Control Package May 2011 Responses from the MS describe the status of the requested operation. Responses are specified in a <response> element (Section 4.2.4) that includes a mandatory attribute describing the status in terms of a numeric code. Response status codes are defined in Section 4.5. The MS MUST respond to a request message with a response message. If the MS is not able to process the request and carry out the dialog operation, the request has failed and the MS MUST indicate the class of failure using an appropriate 4xx response code. Unless an error response code is specified for a class of error within this section, implementations follow Section 4.5 in determining the appropriate status code for the response. Notifications are sent from the MS to provide updates on the status of a dialog or operations defined within the dialog. Notifications are specified in an <event> element (Section 4.2.5). McGlashan, et al. Standards Track [Page 15]
RFC 6231 IVR Control Package May 2011 +---------+ | IDLE | +---------+ | | | | <dialogprepare>/| |<dialogstart>/ | | +---------+ | | +---------+ +-----<--| |<--------+ +------------>| |+------>-+ | +-<----|PREPARING| |STARTING | | | | | | ----------->| |---->--+ | | | +---------+ / +---------+ | | | | | / | | | | | |/200 response / /200 response| | | | | | / | | | | | | / | | | | | | / | | | V V v /<dialogstart>/ v | | | | +---------+ / +---------+ | | | | | |--------+ +----| | | | | | |PREPARED |---------+ | | STARTED | | | | | | | | +--->| | | | | | | |--------+| <dialogterminate>/| | | | | | +---------+ || 200 response +---------+ | | | | || | | | | | /dialogexit notification|| | | | | | (timeout) || | | | | | || | | | | | || | | | | | || | | | | | ||<dialogterminate>/ | | | | | || 200 response | | | | | || + |/dialogexit | | | | || /dialogexit | notification | | | | || notification | | | | | || | | | | | vv | | | | | /ERROR response +-----------+ | | | | +---------------------->| |<----------+ /ERROR response| | +------------------------>|TERMINATED |<---------------------------+ | <dialogterminate>/ | |<-----------------------------+ 410 response +-----------+ <dialogterminate>/410 response Figure 1: Dialog Lifecycle The MS implementation MUST adhere to the dialog lifecycle shown in Figure 1, where each dialog has the following states: McGlashan, et al. Standards Track [Page 16]
RFC 6231 IVR Control Package May 2011 IDLE: the dialog is uninitialized. PREPARING: the dialog is being prepared. The dialog is assigned a valid dialog identifier (see below). If an error occurs, the dialog transitions to the TERMINATED state and the MS MUST send a response indicating the error. If the dialog is terminated before preparation is complete, the dialog transitions to the TERMINATED state and the MS MUST send a 410 response (Section 4.5) for the prepare request. PREPARED: the dialog has been successfully prepared and the MS MUST send a 200 response indicating the prepare operation was successful. If the dialog is terminated, then the MS MUST send a 200 response, the dialog transitions to the TERMINATED state and the MS MUST send a dialogexit notification event (see Section 4.2.5.1). If the duration the dialog remains in the PREPARED state exceeds the maximum preparation duration, the dialog transitions to the TERMINATED state and the MS MUST send a dialogexit notification with the appropriate error status code (see Section 4.2.5.1). A maximum preparation duration of 300s is RECOMMENDED. STARTING: the dialog is being started. If the dialog has not already been prepared, it is first prepared and assigned a valid dialog identifier (see below). If an error occurs the dialog transitions to the TERMINATED state and the MS MUST send a response indicating the error. If the dialog is terminated, the dialog transitions to the TERMINATED state and the MS MUST send a 410 response (Section 4.5) for the start request. STARTED: the dialog has been successfully started and is now active. The MS MUST send a 200 response indicating the start operation was successful. If any dialog events occur that were subscribed to, the MS MUST send a notifications when the dialog event occurs. When the dialog exits (due to normal termination, an error, or a terminate request), the MS MUST send a dialogexit notification event (see Section 4.2.5.1) and the dialog transitions to the TERMINATED state. TERMINATED: the dialog is terminated and its dialog identifier is no longer valid. Dialog notifications MUST NOT be sent for this dialog. Each dialog has a valid identifier until it transitions to a TERMINATED state. The dialog identifier is assigned by the MS unless the <dialogprepare> or <dialogstart> request already specifies a McGlashan, et al. Standards Track [Page 17]
RFC 6231 IVR Control Package May 2011 identifier (dialogid) that is not associated with any other dialog on the MS. Once a dialog is in a TERMINATED state, its dialog identifier is no longer valid and can be reused for another dialog. The identifier is used to reference the dialog in subsequent requests, responses, and notifications. In a <dialogstart> request, the dialog identifier can be specified in the prepareddialogid attribute indicating the prepared dialog to start. In <dialogterminate> and <audit> requests, the dialog identifier is specified in the dialogid attribute, indicating which dialog is to be terminated or audited, respectively. If these requests specify a dialog identifier already associated with another dialog on the MS, the MS sends a response with a 405 status code (see Section 4.5) and the same dialogid as in the request. The MS MUST specify a dialog identifier in notifications associated with the dialog. The MS MUST specify a dialog identifier in responses unless it is a response to a syntactically invalid request. For a given dialog, the <dialogprepare> or <dialogstart> request elements specify the dialog content to execute either by including inline a <dialog> element (the dialog language defined in this package; see Section 4.3) or by referencing an external dialog document (a dialog language defined outside this package). When referencing an external dialog document, the request element contains a URI reference to the remote document (specifying the dialog definition) and, optionally, a type attribute indicating the MIME media type associated with the dialog document. Consequently, the dialog language associated with a dialog on the MS is identified either inline by a <dialog> child element or by a src attribute referencing a document containing the dialog language. The MS MUST support inline the IVR dialog language defined in Section 4.3. The MS MAY support other dialog languages by reference. 4.2.1. <dialogprepare> The <dialogprepare> request is sent to the MS to request preparation of a dialog. Dialog preparation consists of (a) retrieving an external dialog document and/or external resources referenced within an inline <dialog> element and (b) validating the dialog document syntactically and semantically. A prepared dialog is executed when the MS receives a <dialogstart> request referencing the prepared dialog identifier (see Section 4.2.2). The <dialogprepare> element has the following attributes: McGlashan, et al. Standards Track [Page 18]
RFC 6231 IVR Control Package May 2011 src: specifies the location of an external dialog document to prepare. A valid value is a URI (see Section 4.6.9). The MS MUST support both HTTP [RFC2616] and HTTPS [RFC2818] schemes and the MS MAY support other schemes. If the URI scheme is unsupported, the MS sends a <response> with a 420 status code (Section 4.5). If the document cannot be retrieved within the timeout interval, the MS sends a <response> with a 409 status code. If the document contains a type of dialog language that the MS does not support, the MS sends a <response> with a 421 status code. The attribute is optional. There is no default value. type: specifies the type of the external dialog document indicated in the 'src' attribute. A valid value is a MIME media type (see Section 4.6.10). If the URI scheme used in the src attribute defines a mechanism for establishing the authoritative MIME media type of the media resource, the value returned by that mechanism takes precedence over this attribute. The attribute is optional. There is no default value. maxage: Used to set the max-age value of the 'Cache-Control' header in conjunction with an external dialog document fetched using HTTP, as per [RFC2616]. A valid value is a non-negative integer (see Section 4.6.4). The attribute is optional. There is no default value. maxstale: Used to set the max-stale value of the 'Cache-Control' header in conjunction with an external dialog document fetched using HTTP, as per [RFC2616]. A valid value is a non-negative integer (see Section 4.6.4). The attribute is optional. There is no default value. fetchtimeout: the maximum timeout interval to wait when fetching an external dialog document. A valid value is a Time Designation (see Section 4.6.7). The attribute is optional. The default value is 30s. dialogid: string indicating a unique name for the dialog. If a dialog with the same name already exists on the MS, the MS sends a <response> with a 405 status code (Section 4.5). If this attribute is not specified, the MS MUST create a unique name for the dialog (see Section 4.2 for dialog identifier assignment). The attribute is optional. There is no default value. The <dialogprepare> element has the following sequence of child elements: <dialog> an IVR dialog (Section 4.3) to prepare. The element is optional. McGlashan, et al. Standards Track [Page 19]
RFC 6231 IVR Control Package May 2011 <params>: specifies input parameters (Section 4.2.6) for dialog languages defined outside this specification. The element is optional. If a parameter is not supported by the MS for the external dialog language, the MS sends a <response> with a 427 status code (Section 4.5). The dialog to prepare can be specified either inline with a <dialog> child element or externally (for dialog languages defined outside this specification) using the src attribute. It is a syntax error if both an inline <dialog> element and a src attribute are specified and the MS sends a <response> with a 400 status code (see Section 4.5). The type, maxage, maxstale, and fetchtimeout attributes are only relevant when a dialog is specified as an external document. For example, a <dialogprepare> request to prepare an inline IVR dialog with a single prompt: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogprepare> <dialog> <prompt> <media loc="http://www.example.com/welcome.wav"/> </prompt> </dialog> </dialogprepare> </mscivr> In this example, a request with a specified dialogid to prepare a VoiceXML dialog document located externally: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogprepare dialogid="d2" type="application/voicexml+xml" src="http://www.example.com/mydialog.vxml" fetchtimeout="15s"/> </mscivr> Since MS support for dialog languages other than the IVR dialog language defined in this package is optional, if the MS does not support the dialog language, it would send a response with the status code 421 (Section 4.5). Further information on using VoiceXML can be found in Section 9. 4.2.2. <dialogstart> The <dialogstart> element is sent to the MS to start a dialog. If the dialog has not been prepared, the dialog is prepared (retrieving external document and/or external resources referenced within <dialog> element and the dialog document validated syntactically and McGlashan, et al. Standards Track [Page 20]
RFC 6231 IVR Control Package May 2011 semantically). Media processors (e.g., DTMF and prompt queue) are activated and associated with the specified connection or conference. The <dialogstart> element has the following attributes: src: specifies the location of an external dialog document to start. A valid value is a URI (see Section 4.6.9). The MS MUST support both HTTP [RFC2616] and HTTPS [RFC2818] schemes and the MS MAY support other schemes. If the URI scheme is unsupported, the MS sends a <response> with a 420 status code (Section 4.5). If the document cannot be retrieved with the timeout interval, the MS sends a <response> with a 409 status code. If the document contains a type of dialog language that the MS does not support, the MS sends a <response> with a 421 status code. The attribute is optional. There is no default value. type: specifies the type of the external dialog document indicated in the 'src' attribute. A valid value is a MIME media type (see Section 4.6.10). If the URI scheme used in the src attribute defines a mechanism for establishing the authoritative MIME media type of the media resource, the value returned by that mechanism takes precedence over this attribute. The attribute is optional. There is no default value. maxage: Used to set the max-age value of the 'Cache-Control' header in conjunction with an external dialog document fetched using HTTP, as per [RFC2616]. A valid value is a non-negative integer (see Section 4.6.4). The attribute is optional. There is no default value. maxstale: Used to set the max-stale value of the 'Cache-Control' header in conjunction with an external dialog document fetched using HTTP, as per [RFC2616]. A valid value is a non-negative integer (see Section 4.6.4). The attribute is optional. There is no default value. fetchtimeout: the maximum timeout interval to wait when fetching an external dialog document. A valid value is a Time Designation (see Section 4.6.7). The attribute is optional. The default value is 30s. dialogid: string indicating a unique name for the dialog. If a dialog with the same name already exists on the MS, the MS sends a <response> with a 405 status code (Section 4.5). If neither the dialogid attribute nor the prepareddialogid attribute is specified, the MS MUST create a unique name for the dialog (see Section 4.2 for dialog identifier assignment). The attribute is optional. There is no default value. McGlashan, et al. Standards Track [Page 21]
RFC 6231 IVR Control Package May 2011 prepareddialogid: string identifying a dialog previously prepared using a dialogprepare (Section 4.2.1) request. If neither the dialogid attribute nor the prepareddialogid attribute is specified, the MS MUST create a unique name for the dialog (see Section 4.2 for dialog identifier assignment). The attribute is optional. There is no default value. connectionid: string identifying the SIP dialog connection on which this dialog is to be started (see Appendix A.1 of [RFC6230]). The attribute is optional. There is no default value. conferenceid: string identifying the conference on which this dialog is to be started (see Appendix A.1 of [RFC6230]). The attribute is optional. There is no default value. Exactly one of the connectionid or conferenceid attributes MUST be specified. If both the connectionid and conferenceid attributes are specified or neither is specified, it is a syntax error and the MS sends a <response> with a 400 status code (Section 4.5). It is an error if the connection or conference referenced by a specific connectionid or conferenceid attribute is not available on the MS at the time the <dialogstart> request is executed. If an invalid connectionid is specified, the MS sends a <response> with a 407 status code (Section 4.5). If an invalid conferenceid is specified, the MS sends a <response> with a 408 status code. The <dialogstart> element has the following sequence of child elements: <dialog>: specifies an IVR dialog (Section 4.3) to execute. The element is optional. <subscribe>: specifies subscriptions to dialog events (Section 4.2.2.1). The element is optional. <params>: specifies input parameters (Section 4.2.6) for dialog languages defined outside this specification. The element is optional. If a parameter is not supported by the MS for the external dialog language, the MS sends a <response> with a 427 status code (Section 4.5). <stream>: determines the media stream(s) associated with the connection or conference on which the dialog is executed (Section 4.2.2.2). The <stream> element is optional. Multiple <stream> elements can be specified. McGlashan, et al. Standards Track [Page 22]
RFC 6231 IVR Control Package May 2011 The dialog to start can be specified either (a) inline with a <dialog> child element, (b) externally using the src attribute (for dialog languages defined outside this specification), or (c) by referencing a previously prepared dialog using the prepareddialogid attribute. If exactly one of the src attribute, the prepareddialogid, or a <dialog> child element is not specified, it is a syntax error and the MS sends a <response> with a 400 status code (Section 4.5). If the prepareddialogid and dialogid attributes are specified, it is also a syntax error and the MS sends a <response> with a 400 status code. The type, maxage, maxstale, and fetchtimeout attributes are only relevant when a dialog is specified as an external document. The <stream> element provides explicit control over which media streams on the connection or conference are used during dialog execution. For example, if a connection supports both audio and video streams, a <stream> element could be used to indicate that only the audio stream is used in receive mode. In cases where there are multiple media streams of the same type for a dialog, the AS MUST use <stream> elements to explicitly specify the configuration. If no <stream> elements are specified, then the default media configuration is that defined for the connection or conference. If a <stream> element is in conflict (a) with another <stream> element, (b) with specified connection or conference media capabilities, or (c) with a Session Description Protocol (SDP) label value as part of the connectionid (see Appendix A.1 of [RFC6230]), then the MS sends a <response> with a 411 status code (Section 4.5). If the media stream configuration is not supported by the MS, then the MS sends a <response> with a 428 status code (Section 4.5). The MS MAY support multiple, simultaneous dialogs being started on the same connection or conference. For example, the same connection can receive different media streams (e.g., audio and video) from different dialogs, or receive (and implicitly mix where appropriate) the same type of media streams from different dialogs. If the MS does not support starting another dialog on the same connection or conference, it sends a <response> with a 432 status code (Section 4.5) when it receives the second (or subsequent) dialog request. For example, a request to start an ivr dialog on a connection subscribing to DTMF notifications: McGlashan, et al. Standards Track [Page 23]
RFC 6231 IVR Control Package May 2011 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart connectionid="connection1"> <dialog> <prompt> <media loc="http://www.example.com/getpin.wav"/> </prompt> <collect maxdigits="2"/> </dialog> <subscribe> <dtmfsub matchmode="all"/> </subscribe> </dialogstart> </mscivr> In this example, the dialog is started on a conference where the conference only receives an audio media stream from the dialog: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart conferenceid="conference1"> <dialog> <record maxtime="384000s"/> </dialog> <stream media="audio" direction="recvonly"/> </dialogstart> </mscivr> 4.2.2.1. <subscribe> The <subscribe> element allows the AS to subscribe to, and be notified of, specific events that occur during execution of the dialog. Notifications of dialog events are delivered using the <event> element (see Section 4.2.5). The <subscribe> element has no attributes. The <subscribe> element has the following sequence of child elements (0 or more occurrences): <dtmfsub>: Subscription to DTMF input during the dialog (Section 4.2.2.1.1). The element is optional. If a request has a <subscribe> with no child elements, the MS treats the request as if no <subscribe> element were specified. The MS MUST support <dtmfsub> subscription for the IVR dialog language defined in this specification (Section 4.3). It MAY support other dialog subscriptions (specified using attributes and child elements from a foreign namespace). If the MS does not support a McGlashan, et al. Standards Track [Page 24]
RFC 6231 IVR Control Package May 2011 subscription specified in a foreign namespace, the MS sends a response with a 431 status code (see Section 4.5). 4.2.2.1.1. <dtmfsub> The <dtmfsub> element has the following attributes: matchmode: controls which DTMF input is subscribed to. Valid values are "all" - notify all DTMF key presses received during the dialog; "collect" - notify only DTMF input matched by the collect operation (Section 4.3.1.3); and "control" - notify only DTMF input matched by the runtime control operation (Section 4.3.1.2). The attribute is optional. The default value is "all". The <dtmfsub> element has no child elements. DTMF notifications are delivered in the <dtmfnotify> element (Section 4.2.5.2). For example, the AS wishes to subscribe to DTMF key press matching a runtime control: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart dialogid="d3" connectionid="connection1"> <dialog> <prompt> <media loc="http://www.example.com/getpin.wav"/> </prompt> <control ffkey="2" rwkey="3"/> </dialog> <subscribe> <dtmfsub matchmode="control"/> </subscribe> </dialogstart> </mscivr> Each time a '2' or '3' DTMF input is received, the MS sends a notification event: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="d3"> <dtmfnotify matchmode="collect" dtmf="2" timestamp="2008-05-12T12:13:14Z"/> </event> </mscivr> McGlashan, et al. Standards Track [Page 25]
RFC 6231 IVR Control Package May 2011 4.2.2.2. <stream> The <stream> element has the following attributes: media: a string indicating the type of media associated with the stream. A valid value is a MIME type-name as defined in Section 4.2 of [RFC4288]. The following values MUST be used for common types of media: "audio" for audio media, and "video" for video media. See [IANA] for registered MIME type names. The attribute is mandatory. label: a string indicating the SDP label associated with a media stream [RFC4574]. The attribute is optional. direction: a string indicating the direction of the media flow relative to the endpoint conference or connection. Defined values are "sendrecv" (the endpoint can send media to, and receive media from, the dialog), "sendonly" (the endpoint can only send media to the dialog), "recvonly" (the endpoint can only receive media from the dialog), and "inactive" (stream is not to be used). The default value is "sendrecv". The attribute is optional. The <stream> element has the following sequence of child elements: <region>: an element to specify the area within a mixer video layout where a media stream is displayed (Section 4.2.2.2.1). The element is optional. <priority>: an element to configure priority associated with the stream in the conference mix (Section 4.2.2.2.2). The element is optional. If conferenceid is not specified or if the "media" attribute does not have the value of "video", then the MS ignores the <region> and <priority> elements. For example, assume a User Agent connection with multiple audio and video streams associated with the user and a separate web camera. In this case, the dialog could be started to record only the audio and video streams associated with the user: McGlashan, et al. Standards Track [Page 26]
RFC 6231 IVR Control Package May 2011 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart connectionid="connection1"> <dialog> <record maxtime="384000s"/> </dialog> <stream media="audio" label="camaudio" direction="inactive"/> <stream media="video" label="camvideo" direction="inactive"/> <stream media="audio" label="useraudio" direction="sendonly"/> <stream media="video" label="uservideo" direction="sendonly"/> </dialogstart> </mscivr> Using the <region> element, the dialog can be started on a conference mixer so that the video output from the dialog is directed to a specific area within a video layout. For example: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart conferenceid="conference1"> <dialog> <prompt> <media loc="http://www.example.com/presentation.3gp"/> </prompt> </dialog> <stream media="video" direction="recvonly"> <region>1</region> </stream> </dialogstart> </mscivr> 4.2.2.2.1. <region> The <region> element is used to specify a named area within a presentation layout where a video media stream is displayed. The MS could, for example, play video media into an area of a video layout where the layout and its named regions are specified using the Mixer Control Package [MIXER-CP]. The <region> element has no attributes and its content model specifies the name of the region. If the region name is invalid, then the MS reports a 416 status code (Section 4.5) in the response to the request element containing the <region> element. 4.2.2.2.2. <priority> The <priority> element is used to explicitly specify the priority of the dialog for presentation in a conference mix. McGlashan, et al. Standards Track [Page 27]
RFC 6231 IVR Control Package May 2011 The <priority> element has no attributes and its content model specifies a positive integer (see Section 4.6.5). The lower the value, the higher the priority. 4.2.3. <dialogterminate> A dialog can be terminated by sending a <dialogterminate> request element to the MS. The <dialogterminate> element has the following attributes: dialogid: string identifying the dialog to terminate. If the specified dialog identifier is invalid, the MS sends a response with a 405 status code (Section 4.5). The attribute is mandatory. immediate: indicates whether or not a dialog in the STARTED state is to be terminated immediately (in other states, termination is always immediate). A valid value is a boolean (see Section 4.6.1). A value of true indicates that the dialog is terminated immediately and the MS MUST send a dialogexit notification (Section 4.2.5.1) without report information. A value of false indicates that the dialog terminates after the current iteration and the MS MUST send a dialogexit notification with report information. The attribute is optional. The default value is false. The MS MUST reply to the <dialogterminate> request with a <response> element (Section 4.2.4), reporting whether or not the dialog was terminated successfully. For example, immediately terminating a STARTED dialog with dialogid "d4": <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogterminate dialogid="d4" immediate="true"/> </mscivr> If the dialog is terminated successfully, then the response to the dialogterminate request would be: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" dialogid="d4"/> </mscivr> 4.2.4. <response> Responses to dialog management requests are specified with a <response> element. McGlashan, et al. Standards Track [Page 28]
RFC 6231 IVR Control Package May 2011 The <response> element has following attributes: status: numeric code indicating the response status. Valid values are defined in Section 4.5. The attribute is mandatory. reason: string specifying a reason for the response status. The attribute is optional. There is no default value. desclang: specifies the language used in the value of the reason attribute. A valid value is a language identifier (Section 4.6.11). The attribute is optional. If not specified, the value of the desclang attribute on <mscivr> (Section 4.1) applies. dialogid: string identifying the dialog. If the request specifies a dialogid, then that value is used. Otherwise, with <dialogprepare> and <dialogstart> requests, the dialogid generated by the MS is used. If there is no available dialogid because the request is syntactically invalid (e.g., a <dialogterminate> request with no dialogid attribute specified), then the value is the empty string. The attribute is mandatory. connectionid: string identifying the SIP dialog connection associated with the dialog (see Appendix A.1 of [RFC6230]). The attribute is optional. There is no default value. conferenceid: string identifying the conference associated with the dialog (see Appendix A.1 of [RFC6230]). The attribute is optional. There is no default value. For example, a response when a dialog was prepared successfully: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="200" dialogid="d5"/> </mscivr> The response if dialog preparation failed due to an unsupported dialog language: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="421" dialogid="d5" reason="Unsupported dialog language: application/voicexml+xml"/> </mscivr> In this example, a <dialogterminate> request does not specify a dialogid: McGlashan, et al. Standards Track [Page 29]
RFC 6231 IVR Control Package May 2011 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogterminate/> </mscivr> The response status indicates a 400 (Syntax error) status code and the dialogid attribute has an empty string value: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <response status="400" dialogid=" " reason="Attribute required: dialogid"/> </mscivr> 4.2.5. <event> When a dialog generates a notification event, the MS sends the event using an <event> element. The <event> element has the following attributes: dialogid: string identifying the dialog that generated the event. The attribute is mandatory. The <event> element has the following child elements, only one of which can occur: <dialogexit>: indicates that the dialog has exited (Section 4.2.5.1). <dtmfnotify>: indicates that a DTMF key press occurred (Section 4.2.5.2). 4.2.5.1. <dialogexit> The <dialogexit> event indicates that a prepared or active dialog has exited because it is complete, it has been terminated, or an error occurred during execution (for example, a media resource cannot be played). This event MUST be sent by the MS when the dialog exits. The <dialogexit> element has the following attributes: status: a status code indicating the status of the dialog when it exits. A valid value is a non-negative integer (see Section 4.6.4). The MS MUST support the following values: 0 indicates the dialog has been terminated by a <dialogterminate> request. 1 indicates successful completion of the dialog. McGlashan, et al. Standards Track [Page 30]
RFC 6231 IVR Control Package May 2011 2 indicates the dialog terminated because the connection or conference associated with the dialog has terminated. 3 indicates the dialog terminated due to exceeding its maximum duration. 4 indicates the dialog terminated due to an execution error. All other valid but undefined values are reserved for future use, where new status codes are assigned using the Standards Action process defined in [RFC5226]. The AS MUST treat any status code it does not recognize as being equivalent to 4 (dialog execution error). The attribute is mandatory. reason: a textual description that the MS SHOULD use to provide a reason for the status code, e.g., details about an error. A valid value is a string (see Section 4.6.6). The attribute is optional. There is no default value. desclang: specifies the language used in the value of the reason attribute. A valid value is a language identifier (Section 4.6.11). The attribute is optional. If not specified, the value of the desclang attribute on <mscivr> (Section 4.1) applies. The <dialogexit> element has the following sequence of child elements: <promptinfo>: report information (Section 4.3.2.1) about the prompt execution in an IVR <dialog>. The element is optional. <controlinfo>: reports information (Section 4.3.2.2) about the control execution in an IVR <dialog>. The element is optional. <collectinfo>: reports information (Section 4.3.2.3) about the collect execution in an IVR <dialog>. The element is optional. <recordinfo>: reports information (Section 4.3.2.4) about the record execution in an IVR <dialog>. The element is optional. <params>: reports exit parameters (Section 4.2.6) for a dialog language defined outside this specification. The element is optional. For example, when an active <dialog> exits normally, the MS sends a dialogexit <event> reporting information: McGlashan, et al. Standards Track [Page 31]
RFC 6231 IVR Control Package May 2011 <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="d6"> <dialogexit status="1"> <collectinfo dtmf="1234" termmode="match"/> </dialogexit> </event> </mscivr> 4.2.5.2. <dtmfnotify> The <dtmfnotify> element provides a notification of DTMF input received during the active dialog as requested by a <dtmfsub> subscription (Section 4.2.2.1). The <dtmfnotify> element has the following attributes: matchmode: indicates the matching mode specified in the subscription request. Valid values are as follows: "all" - all DTMF key presses notified individually; "collect" - only DTMF input matched by the collect operation notified; and "control" - only DTMF input matched by the control operation notified. The attribute is optional. The default value is "all". dtmf: DTMF key presses received according to the matchmode. A valid value is a DTMF string (see Section 4.6.3) with no space between characters. The attribute is mandatory. timestamp: indicates the time (on the MS) at which the last key press occurred according to the matchmode. A valid value is a dateTime expression (Section 4.6.12). The attribute is mandatory. For example, a notification of DTMF input matched during the collect operation: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="d3"> <dtmfnotify matchmode="collect" dtmf="3123" timestamp="2008-05-12T12:13:14Z"/> </event> </mscivr> McGlashan, et al. Standards Track [Page 32]
RFC 6231 IVR Control Package May 2011 4.2.6. <params> The <params> element is a container for <param> elements (Section 4.2.6.1). The <params> element has no attributes, but the following child elements are defined (0 or more): <param>: specifies a parameter name and value (Section 4.2.6.1). For example, usage with a dialog language defined outside this specification to send additional parameters into the dialog: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <dialogstart type="application/x-dialog" src="nfs://nas01/dialog4" connectionid="c1"> <params> <param name="mode">playannouncement</param> <param name="prompt1">nfs://nas01/media1.3gp</param> <param name="prompt2">nfs://nas01/media2.3gp</param> </params> </dialogstart> </mscivr> 4.2.6.1. <param> The <param> element describes a parameter name and value. The <param> element has the following attributes: name: a string indicating the name of the parameter. The attribute is mandatory. type: specifies a type indicating how the inline value of the parameter is to be interpreted. A valid value is a MIME media type (see Section 4.6.10). The attribute is optional. The default value is "text/plain". encoding: specifies a content-transfer-encoding schema applied to the inline value of the parameter on top of the MIME media type specified with the type attribute. A valid value is a content- transfer-encoding schema as defined by the "mechanism" token in Section 6.1 of [RFC2045]. The attribute is optional. There is no default value. The <param> element content model is the value of the parameter. Note that a value that contains XML characters (e.g., "<") needs to be escaped following standard XML conventions. McGlashan, et al. Standards Track [Page 33]
RFC 6231 IVR Control Package May 2011 For example, usage with a dialog language defined outside this specification to receive parameters from the dialog when it exits: <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr"> <event dialogid="d6"> <dialogexit status="1"> <params> <param name="mode">recording</param> <param name="recording1" type="audio/x-wav" encoding="base64"> <![CDATA[ R0lGODlhZABqALMAAFrMYr/BvlKOVJKOg2xZUKmenMfDw8tgWJpV ]]> </param> </params> </dialogexit> </event> </mscivr> 4.3. IVR Dialog Elements This section describes the IVR dialog language defined as part of this specification. The MS MUST support this dialog language. The <dialog> element is an execution container for operations of playing prompts (Section 4.3.1.1), runtime controls (Section 4.3.1.2), collecting DTMF (Section 4.3.1.3), and recording user input (Section 4.3.1.4). Results of the dialog execution (Section 4.3.2) are reported in a dialogexit notification event. Using these elements, three common dialog models are supported: playannouncements: only a <prompt> element is specified in the container. The prompt media resources are played in sequence. promptandcollect: a <collect> element is specified and, optionally, a <prompt> element. If a <prompt> element is specified and bargein is enabled, playing of the prompt is terminated when bargein occurs, and DTMF collection is initiated; otherwise, the prompt is played to completion before DTMF collection is initiated. If no prompt element is specified, DTMF collection is initiated immediately. promptandrecord: a <record> element is specified and, optionally, a <prompt> element. If a <prompt> element is specified and bargein is enabled, playing of the prompt is terminated when bargein occurs, and recording is initiated; otherwise, the prompt is played to completion before recording is initiated. If no prompt element is specified, recording is initiated immediately. McGlashan, et al. Standards Track [Page 34]
RFC 6231 IVR Control Package May 2011 In addition, this dialog language supports runtime ('VCR') controls enabling a user to control prompt playback using DTMF. Each of the core elements -- <prompt>, <control>, <collect>, and <record> -- are specified so that their execution and reporting is largely self-contained. This facilitates their reuse in other dialog container elements. Note that DTMF and bargein behavior affects multiple elements and is addressed in the relevant element definitions. Execution results are reported in the <dialogexit> notification event with child elements defined in Section 4.3.2. If the dialog terminated normally (i.e., not due to an error or to a <dialogterminate> request), then the MS MUST report the results for the operations specified in the dialog: <prompt>: <promptinfo> (see Section 4.3.2.1) with at least the termmode attribute specified. <control>: <controlinfo> (see Section 4.3.2.2) if any runtime controls are matched. <collect>: <collectinfo> (see Section 4.3.2.3) with the dtmf and termmode attributes specified. <record>: <recordinfo> (see Section 4.3.2.4) with at least the termmode attribute and one <mediainfo> element specified. The media format requirements for IVR dialogs are undefined. This package is agnostic to the media types and codecs for media resources and recording that need to be supported by an implementation. For example, an MS implementation might only support audio and in particular the 'audio/basic' codec for media playback and recording. However, when executing a dialog, if an MS encounters a media type or codec that it cannot process, the MS MUST stop further processing and report the error using the dialogexit notification. 4.3.1. <dialog> An IVR dialog to play prompts to the user, allow runtime controls, collect DTMF, or record input. The dialog is specified using a <dialog> element. A <dialog> element has the following attributes: McGlashan, et al. Standards Track [Page 35]
RFC 6231 IVR Control Package May 2011 repeatCount: number of times the dialog is to be executed. A valid value is a non-negative integer (see Section 4.6.4). A value of 0 indicates that the dialog is repeated until halted by other means. The attribute is optional. The default value is 1. repeatDur: maximum duration for dialog execution. A valid value is a time designation (see Section 4.6.7). If no value is specified, then there is no limit on the duration of the dialog. The attribute is optional. There is no default value. repeatUntilComplete: indicates whether the MS terminates dialog execution when an input operation is completed successfully. A valid value is a boolean (see Section 4.6.1). A value of true indicates that dialog execution is terminated when an input operation associated with its child elements is completed successfully (see execution model below for precise conditions). A value of false indicates that dialog execution is terminated by other means. The attribute is optional. The default value is false. The repeatDur attribute takes priority over the repeatCount attribute in determining maximum duration of the dialog. See 'repeatCount' and 'repeatDur' in the Synchronized Multimedia Integration Language (SMIL) [W3C.REC-SMIL2-20051213] for further information. In the situation where a dialog is repeated more than once, only the results of operations in the last dialog iteration are reported. The <dialog> element has the following sequence of child elements (at least one, any order): <prompt>: defines media resources to play in sequence (see Section 4.3.1.1). The element is optional. <control>: defines how DTMF is used for runtime controls (see Section 4.3.1.2). The element is optional. <collect>: defines how DTMF is collected (see Section 4.3.1.3). The element is optional. <record>: defines how recording takes place (see Section 4.3.1.4). The element is optional. Although the behavior when both <collect> and <record> elements are specified in a request is not defined in this Control Package, the MS MAY support this configuration. If the MS does not support this configuration, the MS sends a <response> with a 433 status code. McGlashan, et al. Standards Track [Page 36]
RFC 6231 IVR Control Package May 2011 The MS has the following execution model for the IVR dialog after initialization (initialization errors are reported by the MS in the response): 1. If an error occurs during execution, then the MS terminates the dialog and reports the error in the <dialogexit> event by setting the status attribute (see Section 4.3.2). Details about the error are specified in the reason attribute. 2. The MS initializes a counter to 0. 3. The MS starts a duration timer for the value of the repeatDur attribute. If the timer expires before the dialog is complete, then the MS terminates the dialog and sends a dialogexit whose status attribute is set to 3 (see Section 4.2.5.1). The MS MAY report information in the dialogexit gathered in the last execution cycle (if any). 4. The MS initiates a dialog execution cycle. Each cycle executes the operations associated with the child elements of the dialog. If a <prompt> element is specified, then execute the element's prompt playing operation and activate any controls (if the <control> element is specified). If no <prompt> is specified or when a specified <prompt> terminates, then start the collect operation or the record operation if the <collect> or <record> elements, respectively, are specified. If subscriptions are specified for the dialog, then the MS sends a notification event when the specified event occurs. If execution of a child element results in an error, the MS terminates dialog execution (and stops other child element operations) and the MS sends a dialogexit status event, reporting any information gathered. 5. If the dialog execution cycle completes successfully, then the MS increments the counter by one. The MS terminates dialog execution if either of the following conditions is true: * the value of the repeatCount attribute is greater than zero, and the counter is equal to the value of the repeatCount attribute. * the value of the repeatUntilComplete attribute is true and one of the following conditions is true: + <collect> reports termination status of 'match' or 'stopped'. + <record> reports termination status of 'stopped', 'dtmf', 'maxtime', or 'finalsilence'. McGlashan, et al. Standards Track [Page 37]
RFC 6231 IVR Control Package May 2011 When the MS terminates dialog execution, it sends a dialogexit (with a status of 1) reporting operation information collected in the last dialog execution cycle only. Otherwise, another dialog execution cycle is initiated. 4.3.1.1. <prompt> The <prompt> element specifies a sequence of media resources to play back in document order. A <prompt> element has the following attributes: xml:base: A string declaring the base URI from which relative URIs in child elements are resolved prior to fetching. A valid value is a URI (see Section 4.6.9). The attribute is optional. There is no default value. bargein: Indicates whether user input stops prompt playback unless the input is associated with a specified runtime <control> operation (input matching control operations never interrupts prompt playback). A valid value is a boolean (see Section 4.6.1). A value of true indicates that bargein is permitted and prompt playback is stopped. A value of false indicates that bargein is not permitted: user input does not terminate prompt playback. The attribute is optional. The default value is true. The <prompt> element has the following child elements (at least one, any order, multiple occurrences of elements permitted): <media>: specifies a media resource (see Section 4.3.1.5) to play. The element is optional. <variable>: specifies a variable media announcement (see Section 4.3.1.1.1) to play. The element is optional. <dtmf>: generates one or more DTMF tones (see Section 4.3.1.1.2) to play. The element is optional. <par>: specifies media resources to play in parallel (see Section 4.3.1.1.3). The element is optional. If the MS does not support the configuration required for prompt playback to the output media streams and a more specific error code is not defined for its child elements, the MS sends a <response> with a 429 status code (Section 4.5). The MS MAY support transcoding between the media resource format and the output stream format. McGlashan, et al. Standards Track [Page 38]
RFC 6231 IVR Control Package May 2011 The MS has the following execution model for prompt playing after initialization: 1. The MS initiates prompt playback playing its child elements (<media>, <variable>, <dtmf>, and <par>) one after another in document order. 2. If any error (including fetching and rendering errors) occurs during prompt execution, then the MS terminates playback and reports its error status to the dialog container (see Section 4.3) with a <promptinfo> (see Section 4.3.2.1) where the termmode attribute is set to stopped and any additional information is set. 3. If DTMF input is received and the value of the bargein attribute is true, then the MS terminates prompt playback and reports its execution status to the dialog container (see Section 4.3) with a <promptinfo> (see Section 4.3.2.1) where the termmode attribute is set to bargein and any additional information is set. 4. If prompt playback is stopped by the dialog container, then the MS reports its execution status to the dialog container (see Section 4.3) with a <promptinfo> (see Section 4.3.2.1) where the termmode attribute is set to stopped and any additional information is set. 5. If prompt playback completes successfully, then the MS reports its execution status to the dialog container (see Section 4.3) with a <promptinfo> (see Section 4.3.2.1) where the termmode attribute is set to completed and any additional information is set. 4.3.1.1.1. <variable> The <variable> element specifies variable announcements using predefined media resources. Each variable has at least a type (e.g., date) and a value (e.g., 2008-02-25). The value is rendered according to the prompt variable type (e.g., 2008-02-25 is rendered as the date 25th February 2008). The precise mechanism for generating variable announcements (including the location of associated media resources) is implementation specific. A <variable> element has the following attributes: type: specifies the type of prompt variable to render. This specification defines three values -- date (Section 4.3.1.1.1.1), time (Section 4.3.1.1.1.2), and digits (Section 4.3.1.1.1.3). All other valid but undefined values are reserved for future use, McGlashan, et al. Standards Track [Page 39]
RFC 6231 IVR Control Package May 2011 where new values are assigned as described in Section 8.5. A valid value is a string (see Section 4.6.6). The attribute is mandatory. value: specifies a string to be rendered according to the prompt variable type. A valid value is a string (see Section 4.6.6). The attribute is mandatory. format: specifies format information that the prompt variable type uses to render the value attribute. A valid value is a string (see Section 4.6.6). The attribute is optional. There is no default value. gender: specifies the gender that the prompt variable type uses to render the value attribute. Valid values are "male" or "female". The attribute is optional. There is no default value. xml:lang: specifies the language that the prompt variable type uses to render the value attribute. A valid value is a language identifier (see Section 4.6.11). The attribute is optional. There is no default value. The <variable> element has no children. This specification is agnostic to the type and codec of media resources into which variables are rendered as well as the rendering mechanism itself. For example, an MS implementation supporting audio rendering could map the <variable> into one or more audio media resources. This package is agnostic to which <variable> types are supported by an implementation. If a <variable> element configuration specified in a request is not supported by the MS, the MS sends a <response> with a 425 status code (Section 4.5). 4.3.1.1.1.1. Date Type The date variable type provides a mechanism for dynamically rendering a date prompt. The <variable> type attribute MUST have the value "date". The <variable> format attribute MUST be one of the following values and comply with its rendering of the value attribute: mdy indicating that the <variable> value attribute is to be rendered as sequence composed of month, then day, then year. McGlashan, et al. Standards Track [Page 40]
RFC 6231 IVR Control Package May 2011 ymd indicating that the <variable> value attribute is to be rendered as sequence composed of year, then month, then day. dym indicating that the <variable> value attribute is to be rendered as sequence composed of day, then year, then month. dm indicating that the <variable> value attribute is to be rendered as sequence composed of day then month. The <variable> value attribute MUST comply with a lexical representation of date where yyyy '-' mm '-' dd as defined in Section 3.2.9 of [XMLSchema:Part2]. For example, <variable type="date" format="dmy" value="2010-11-25" xml:lang="en" gender="male"/> describes a variable date prompt where the date can be rendered in audio as "twenty-fifth of November two thousand and ten" using a list of <media> resources: <media loc="nfs://voicebase/en/male/25th.wav"/> <media loc="nfs://voicebase/en/male/of.wav"/> <media loc="nfs://voicebase/en/male/november.wav"/> <media loc="nfs://voicebase/en/male/2000.wav"/> <media loc="nfs://voicebase/en/male/and.wav"/> <media loc="nfs://voicebase/en/male/10.wav"/> 4.3.1.1.1.2. Time Type The time variable type provides a mechanism for dynamically rendering a time prompt. The <variable> type attribute MUST have the value "time". The <variable> format attribute MUST be one of the following values and comply with its rendering of the value attribute: t12 indicating that the <variable> value attribute is to be rendered as a time in traditional 12-hour format using am or pm (for example, "twenty-five minutes past 2 pm" for "14:25"). McGlashan, et al. Standards Track [Page 41]
RFC 6231 IVR Control Package May 2011 t24 indicating that the <variable> value attribute is to be rendered as a time in 24-hour format (for example, "fourteen twenty-five" for "14:25"). The <variable> value attribute MUST comply with a lexical representation of time where hh ':' mm ( ':' ss )? as defined in Section 3.2.8 of [XMLSchema:Part2]. 4.3.1.1.1.3. Digits Type The digits variable type provides a mechanism for dynamically rendering a digit sequence. The <variable> type attribute MUST have the value "digits". The <variable> format attribute MUST be one of the following values and comply with its rendering of the value attribute: gen indicating that the <variable> value attribute is to be rendered as a general digit string (for example, "one two three" for "123"). crn indicating that the <variable> value attribute is to be rendered as a cardinal number (for example, "one hundred and twenty- three" for "123"). ord indicating that the <variable> value attribute is to be rendered as an ordinal number (for example, "one hundred and twenty- third" for "123"). The <variable> value attribute MUST comply with the lexical representation d+ i.e., one or more digits. 4.3.1.1.2. <dtmf> The <dtmf> element specifies a sequence of DTMF tones for output. DTMF tones could be generated using <media> resources where the output is transported as RTP audio packets. However, <media> resources are not sufficient for cases where DTMF tones are to be transported as DTMF RTP [RFC4733] or in event packages. McGlashan, et al. Standards Track [Page 42]
RFC 6231 IVR Control Package May 2011 A <dtmf> element has the following attributes: digits: specifies the DTMF sequence to output. A valid value is a DTMF string (see Section 4.6.3). The attribute is mandatory. level: used to define the power level for which the DTMF tones will be generated. Values are expressed in dBm0. A valid value is an integer in the range of 0 to -96 (dBm0). Larger negative values express lower power levels. Note that values lower than -55 dBm0 will be rejected by most receivers (TR-TSY-000181, ITU-T Q.24A). The attribute is optional. The default value is -6 (dBm0). duration: specifies the duration for which each DTMF tone is generated. A valid value is a time designation (see Section 4.6.7). The MS MAY round the value if it only supports discrete durations. The attribute is optional. The default value is 100 ms. interval: specifies the duration of a silence interval following each generated DTMF tone. A valid value is a time designation (see Section 4.6.7). The MS MAY round the value if it only supports discrete durations. The attribute is optional. The default value is 100 ms. The <dtmf> element has no children. If a <dtmf> element configuration is not supported, the MS sends a <response> with a 426 status code (Section 4.5). 4.3.1.1.3. <par> The <par> element allows media resources to be played in parallel. Each of its child elements specifies a media resource (or a sequence of media resources using the <seq> element). When playback of the <par> element is initiated, the MS begins playback of all its child elements at the same time. This element is modeled after the <par> element in SMIL [W3C.REC-SMIL2-20051213]. The <par> element has the following attributes: endsync: indicates when playback of the element is complete. Valid values are "first" (indicates that the element is complete when any child element reports that it is complete) and "last" (indicates it is complete when every child elements are complete). The attribute is optional. The default value is "last". If the value is "first", then playback of other child elements is stopped when one child element reports it is complete. McGlashan, et al. Standards Track [Page 43]
RFC 6231 IVR Control Package May 2011 The <par> element has the following child elements (at least one, any order, multiple occurrences of each element permitted): <seq>: specifies a sequence of media resources to play in parallel with other <par> child elements (see Section 4.3.1.1.3.1). The element is optional. <media>: specifies a media resource (see Section 4.3.1.5) to play. The MS is responsible for assigning the appropriate media stream(s) when more than one is available. The element is optional. <variable>: specifies a variable media annmirror server hosted at Truenetwork, Russian Federation.