Network Working Group                                         C. Boulton
Internet-Draft                             Ubiquity Software Corporation                                                     Avaya
Intended status: Standards Track                            T. Melanchuk
Expires: May 5, August 26, 2008                                          BlankSpace                      Rain Willow Communications
                                                            S. McGlashan
                                                         Hewlett-Packard
                                                            A. Shiratzky
                                                               Radvision
                                                        November 2, 2007
                                                       February 23, 2008

   A VoiceXML Interactive Voice Response (IVR) Control Package for the
                   Session Initiation Protocol (SIP)
               draft-boulton-ivr-vxml-control-package-03 Media Control Channel Framework
               draft-boulton-ivr-vxml-control-package-04

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 5, August 26, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007). (2008).

Abstract

   This document defines a Session Initiation (SIP) VoiceXML Control Package for
   Interactive Voice Response (IVR) interaction using VoiceXML. the Media
   Control Channel Framework.  This Control Package provides IVR functionality using the SIP Control
   Framework and extends the Basic
   IVR control package with support for VoiceXML dialogs.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  4
   3.  Control Package Definition . . . . . . . . . . . . . . . . . .  5
     3.1.  Control Package Name . . . . . . . . . . . . . . . . . . .  5
     3.2.  Framework Message Usage  . . . . . . . . . . . . . . . . .  5
     3.3.  Common XML Support . . . . . . . . . . . . . . . . . . . .  5
     3.4.  CONTROL Message Body . . . . . . . . . . . . . . . . . . .  6  5
     3.5.  REPORT Message Body  . . . . . . . . . . . . . . . . . . .  6
   4.  Element Definitions Extensions . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Requests . . . . . . . . . . . . . . . . . . . . . . .  <dialogprepare>  . .  7
       4.1.1.  <dialogprepare> . . . . . . . . . . . . . . . . . . .  7
       4.1.2.
     4.2.  <dialogstart>  . . . . . . . . . . . . . . . . . . . .  9
       4.1.3.  <dialogterminate>  . . . . . . . . . . . .  7
     4.3.  <event>  . . . . . . 12
     4.2.  Responses . . . . . . . . . . . . . . . . . . .  8
     4.4.  <dialogexit> . . . . . 13
       4.2.1.  <response> . . . . . . . . . . . . . . . . . .  8
   5.  Element Definitions  . . . . 13
     4.3.  Notifications . . . . . . . . . . . . . . . . . 10
     5.1.  <params> . . . . . 15
       4.3.1.  <event> . . . . . . . . . . . . . . . . . . . . 10
   6.  Examples . . . 15
     4.4.  <data> . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Formal Syntax  . . 16
     4.5.  <subscribe> . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . 16
   5.  Formal Syntax . . . . . . . . . . . . . . . . . . 17
   9.  IANA Considerations  . . . . . . 18
   6.  Security Considerations . . . . . . . . . . . . . . . 18
     9.1.  Control Package Registration . . . . 24
   7.  IANA Considerations . . . . . . . . . . . 18
     9.2.  URN Sub-Namespace Registration . . . . . . . . . . 25
     7.1.  Control Package Registration . . . . 18
   10. Change Summary . . . . . . . . . . . 25
     7.2.  URN Sub-Namespace Registration . . . . . . . . . . . . . 19
   11. Contributors . 25
   8.  Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 26
   9. 20
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
   10. 21
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     10.1. 22
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 28
     10.2. 22
     13.2. Informative References . . . . . . . . . . . . . . . . . . 28 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 31 25

1.  Introduction

   The SIP Media Control Channel Framework [SIPCF] [MCCF] provides a generic
   approach for establishment and reporting capabilities of remotely
   initiated commands.  The Framework utilizes many functions provided
   by the Session Initiation Protocol [RFC3261] (SIP) 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 specification defines a package Control Package for IVR functions using
   VoiceXML 2.0 dialogs [VXML20]. ([VXML20], [VXML21]).  As a recognized
   international standard for IVR dialogs, VoiceXML is used extensively
   within media server control languages (cf. [MSCP], [CCXML10], [MSML], [RFC4722],
   [RFC4240]).

   To ensure interoperability, if a media server supports this package,
   then it implementations MUST support VoiceXML 2.0 dialog scripts.  It MAY
   dialogs.  They SHOULD support later versions of VoiceXML or other dialog script formats. (e.g.
   [VXML21]).

   The VoiceXML package extends the basic IVR control package
   ([BASICIVRCP]).  The extensions only affect
   ([BASEIVRCP]) by replacing the <dialogprepare> and
   <dialogstart> elements: in particular,

   1. basic ivr dialog scripts may also be specified inline using a child <src>
       element

   2.  a type attribute is introduced with the default value
       "application/voicexml+xml"

   3.  HTTP fetching and caching of a VoiceXML
   dialog scripts can be configured
       using type.  In particular, this package

   1.  extends <dialogprepare> and <dialogstart> elements to include
       inline <vxml> dialogs, http related attributes of and a child <httpparams> <params>
       element to pass information into the dialog.

   2.  extends <dialogexit> to provide VoiceXML exit information

   Otherwise, this package follows precisely the syntax and semantics of
   the basic IVR control package.

   Other control packages may be defined which extend the capabilities
   of the control package defined in this document.  Such control
   package must respect the syntax and semantics of this control
   package.

2.  Conventions and Terminology

   In this document, BCP 14/RFC 2119 [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.  A dialog
      is identified by a URI and has an associated mimetype.  Dialogs
      typically feature basic capabilities such as playing audio
      prompts, collecting DTMF input and recording audio input from the
      user.  More advanced dialogs may also feature 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 Section 2 of dialogs, which [BASEIVRCP] are identified
      by a URI and initiated by the application server. used in
   this document.

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 9 8 of [SIPCF]. [MCCF].

3.1.  Control Package Name

   The Control Framework requires a Control Package definition to
   specify and register a unique name and version.

   The name and version of this Control Package is "msc-ivr-vxml/1.0"
   (Media Server Control - Interactive Voice Response - VoiceXML -
   version 1.0 ). 1.0).  Its IANA registration is specified in Section 9.1.

3.2.  Framework Message Usage

   IVR functionality includes capabilities such

   The Control Framework requires a Control Package to explicitly detail
   the control messages that can be used as playing prompts,
   collecting DTMF and recording user input.  These functions are
   expressed well as provide an
   indication of directionality between entities.  This will include
   which role type is allowed to initiate a request type.

   This package adheres to Framework Message usage defined in VoiceXML dialogs. Section
   3.2 of [BASEIVRCP].  This package defines XML extends the dialog control elements
   as defined in Section 4 and provides an XML
   Schema 4; additional elements are defined in
   Section 5.

   The  A XML elements in Schema for this package are split into requests, responses
   and event notifications.  Requests are carried is provided in CONTROL message
   bodies; <dialogprepare>, <dialogstart> Section 7.

   Implementation of this control package MUST adhere to the syntax and <dialogterminate>
   semantics of XML elements
   are defined as package requests.  Responses are carried either in
   REPORT message or Control Framework 200 response bodies; the
   <response> element this document.  In cases where
   there is defined as a package response.  Event
   notifications are also carried difference in REPORT message bodies; the <event>
   element is defined for package event notifications.

   Note that package responses are different from framework response
   codes.  Framework error response codes (see Section 8 of [SIPCF]) are
   used when constraints between the request or event notification is invalid; for example,
   a request is invalid XML (400), or not understood (500).  Package
   responses are carried in 200 response or REPORT message bodies.  This
   package's response codes are defined in Section 4.2.1.

   The schema uses "connection-id" and "conf-id" attributes which are
   imported from schema defined in core Control Framework [SIPCF]. the
   textual description of elements, the textual definition takes
   priority.

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 adheres to Common XML Schema Support defined in Section 16.1 3.3 of [SIPCF]
   MUST be supported for media dialogs and conferences.
   [BASEIVRCP].

3.4.  CONTROL Message Body

   A valid CONTROL

   The Control Framework requires a Control Package to define the
   control body message MUST conform that can be contained within a CONTROL command request
   and to indicate the schema defined in
   Section 5 location of detailed syntax definitions and described
   semantics for the appropriate body types.

   This package adheres to CONTROL Message Body as defined in Section 4.  XML messages appearing in
   CONTROL messages MUST contain a <dialogprepare>, <dialogstart> or
   <dialogterminate> request element (Section 4.1).
   3.4 of [BASEIVRCP].

3.5.  REPORT Message Body

   A valid REPORT body MUST conform

   The Control Framework requires a control package definition to define
   the schema defined in Section 5
   and described in Section 4.  XML messages appearing in REPORT
   messages MUST contain body that can be contained within a <response> (Section 4.2), REPORT command
   request, or a (notification)
   <event> element (Section 4.3).

4.  Element Definitions that no report package body is required.  This section defines
   should indicate the XML messages location of detailed syntax definitions and
   semantics for this control package.

   [Editors Note: since XML Schema may not be able the appropriate body types.

   This package adheres to express all
   constraints expressed REPORT Message Body as defined in these definitions, Section 3.5
   of [BASEIVRCP].

4.  Element Extensions

   The XML elements used in cases where there is a
   difference this package are those defined in constraints, the definitions Section 4
   of [BASEIVRCP] unless otherwise specified in the section take
   priority.] this section.

4.1.  Requests

   The following request elements are defined:

   <dialogprepare>:  prepare an IVR dialog for later execution

   <dialogstart>:  start an IVR dialog on a connection or conference

   <dialogterminate>:  terminate an active IVR dialog

4.1.1.  <dialogprepare>

   The <dialogprepare> request is sent from the AS to

   This package extends the MS to request
   preparation definition of an IVR dialog.  A prepared dialog is executed when the
   AS sends a <dialogstart> <dialogprepare> request referencing the prepared dialog (see in
   Section 4.1.2).

   A 4.1.1 of [BASEIVRCP] as follows.

   The <dialogprepare> element has the following modified attributes:

   src:  string identifying the URI of the dialog document to prepare.
      The attribute is mandatory.  The MS  implementations MUST support VoiceXML 2.0
      dialogs and MAY support later versions of VoiceXML or other dialog
      types.

   type:  string identifying the MIME type of the document. HTTP protocol

   type:  The default value is "application/voicexml+xml".

   The attribute is optional.

   dialogid:  string indicating a unique name for the dialog.  If this
      attribute is not specified, the MS creates a unique name for the
      dialog.  The value is used in subsequent references to the dialog
      (e.g. as dialogid in a <response>).  It is an error if a dialog
      with the same name already exists on the MS.  The attribute is
      optional.

   The <dialogprepare> element has the following child elements:

   <data>:  an XML data structure (see Section 4.4) to pass parameters
      into the dialog.  It is an error if a specified parameter is not
      supported by the implementation.  The element is optional.

   <subscribe>:  an XML data structure (see Section 4.5) indicating
      notification events to which the AS subscribes.  It is an error if
      a specified notification event is not supported by the
      implementation.  The element is optional.

   <src>:  contains the dialog script itself; e.g. a VoiceXML document.
      The MS MUST support VoiceXML 2.0 dialogs and MAY support later
      versions of VoiceXML or other dialog types.  The element is
      optional.

   <httpparams>:  contains attributes to configure HTTP 1.1 [RFC2616]
      fetching and caching. additional attributes:

   maxage:  string defining a time interval according to the max-age
      parameter in HTTP.  The attribute is optional.

   maxstale:  string defining a time interval according to the max-
         stale max-stale
      parameter in HTTP.  The attribute is optional.

      enctype:  string identifying the encoding type of the submitted
         document.  The default value is "application/
         x-www-form-url-encoded".  The attribute is optional.

   method:  string indicating the HTTP method to use.  Permitted values
      are "post" or "get".  The default value is "get".  The attribute
      is optional.

      The element is optional.

   Exactly one of the src attribute or the <src> element MUST be
   specified; otherwise, it is an error.

   For example, a request to prepare a dialog where the dialog script is
   indicated using the src attribute:

   <dialogprepare src="http://www.example.com/playprompt.vxml">
     <data>
        <item name="audio" value="/media/prompt1.wav"/>
     </data>
   </dialogprepare>

   Where the data parameter "audio" would be available in the VoiceXML
   script as "connection.ccxml.values.audio" so different prompts can be
   played using the same dialog script.

   In the following example, the VoiceXML dialog script is specified
   inline:

   <dialogprepare>
    <src>
      <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
         <form id='main'>
            <block>
               <audio expr="http://www.example.com/media/prompt1.wav"/>
               <exit/>
             </block>
         </form>
      </vxml>
     </src>
   </dialogprepare>

   When an MS has successfully received a <dialogprepare> request, it
   MUST reply with a <response> element (Section 4.2).

4.1.2.  <dialogstart>

   The <dialogstart> element is sent by the AS to request execution of a
   dialog.  The dialog may be defined in the dialogstart request itself,
   or reference a previously prepared dialog.

   The <dialogstart> element has the following attributes:

   src:

   enctype:  string identifying the URI encoding type of the dialog submitted
      document to start.
      The attribute is optional.  The MS MUST support VoiceXML 2.0
      dialogs and MAY support later versions of VoiceXML or other dialog
      types.

   type:  string identifying (when the MIME type value of the document. method attribute is 'post').  The
      default value is "application/voicexml+xml". "application/x-www-form-url-encoded".  The
      attribute is optional.

   dialogid:  string indicating a unique name for the dialog.  If this
      attribute is not specified, the MS creates a unique name for the
      dialog.

   The value is used in subsequent references to <dialogprepare> element has the dialog
      (e.g. as dialogid in a <response>).  It is following additional child
   elements:

   <vxml>:  contains an error if a dialog
      with the same name already exists on inline VoiceXML document in the MS.  The attribute is
      optional.

   prepareddialogid:  string identifying a dialog previously prepared
      using a dialogprepare request. VoiceXML
      namespace.  The attribute element is optional.

   connection-id:  string identifying

4.2.  <dialogstart>

   This package extends the SIP dialog connection on which
      this dialog is to be started (see Section 16.1 definition of [SIPCF]).  The
      attribute is optional.

   conf-id:  string identifying the conference on which this dialog is
      to be started (see <dialogstart> request in
   Section 16.1 4.1.2 of [SIPCF]).  The attribute is
      optional. [BASEIVRCP] as follows.

   The <dialogstart> element has the following child elements defined:

   <stream>:  contains the following modified attributes:

      media:  a string indicating the type of media associated with the
         stream.  It is strongly recommended that the following values
         are used for common types of media: "audio" for audio media,
         and "video" for video media.  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

   src:  implementations MUST support the media flow
         between a dialog and its end point conference or connection.
         Defined values are: "sendrecv" (media can be sent and
         received), "sendonly" (media can only be sent), and "recvonly"
         (media can only be received).  The default value is "sendrecv".
         The attribute is optional.

      One or more <stream> elements may be specified so that individual
      media streams can be controlled independently; for example, audio
      only for transmission, but video only for reception. HTTP URI protocol

   type:  The <stream>
      element is optional.  If no <stream> elements are specified, then
      the default is the media configuration of the connection or
      conference.  It is an error if a <stream> element is in conflict
      with (a) another <stream> element, (b) with dialog, connection or
      conference media capabilities, or (c) with a SDP label value as
      part of the connection-id (see Section 16.1 of [SIPCF]).

   <data>:  an XML data structure (see Section 4.4) to pass parameters
      into the dialog.  It is an error if a specified parameter is not
      supported by the implementation. "application/voicexml+xml".

   The <dialogstart> element is optional.

   <subscribe>:  an XML data structure (see Section 4.5) indicating
      notification events to which the AS subscribes.  It is an error if
      a specified notification event is not supported by the
      implementation.The element is optional.

   <src>:  contains has the dialog script itself; e.g. a VoiceXML document.
      The MS MUST support VoiceXML 2.0 dialogs and MAY support later
      versions of VoiceXML or other dialog types.  The element is
      optional.

   <httpparams>:  contains attributes to configure HTTP 1.1 [RFC2616]
      fetching and caching. following additional attributes:

   maxage:  string defining a time interval according to the max-age
      parameter in HTTP.  The attribute is optional.

   maxstale:  string defining a time interval according to the max-
         stale max-stale
      parameter in HTTP.  The attribute is optional.

      enctype:  string identifying the encoding type of the submitted
         document.  The default value is "application/
         x-www-form-url-encoded".  The attribute is optional.

   method:  string indicating the HTTP method to use.  Permitted values
      are "post" or "get".  The default value is "get".  The attribute
      is optional.

      The element is optional.

   [Editors Note: the <stream> element assumes that the use of the SDP
   label by itself is insufficent for media stream control.  In
   particular, the SDP label does not address directionality, nor does
   it address conferences.  Further investigation of the <stream> is is
   required.]

   If the prepareddialogid is specified, it is an error to specify the
   src attribute, <src> element or

   enctype:  string identifying the encoding type attribute.

   If the prepareddialogid is not specified, exactly one of the src
   attribute or submitted
      document (when the <src> element MUST be specified; otherwise, it is an
   error.

   Exactly one value of the connection-id or conf-id attributes MUST be
   specified.  It is an error to specify both connection-id and conf-id.

   If the prepareddialogid is specified and the <dialogprepare>
   contained a <data> element, it is an error to specify it in
   <dialogstart>.  Likewise, If the prepareddialogid is specified and
   the <dialogprepare> contained a <subscribe> element, it is an error
   to specify it in <dialogstart>.

   For example, a request to start a dialog on a conference where the
   dialog script is indicated using the src attribute:

    <dialogstart conf-id="conference11"
       src="http://www.example.com/playprompt.vxml">
       <data>
         <item name="media" value="/media/prompt1.wav"/>
       </data>
    </dialogstart>

   Where the data parameter "media" would be available in the VoiceXML
   script as "connection.ccxml.values.media" so different prompts can be
   played using the same dialog script.

   In the following example, the VoiceXML dialog script is specified
   inline.

    <dialogstart conf-id="conference11">
       <src>
        <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
         <form id='main'>
            <block>
               <audio expr="http://www.example.com/media/prompt1.wav"/>
               <exit/>
             </block>
          </form>
        </vxml>
       </src>
     </dialogstart>

   In this example, a previously prepared dialog with the dialogid
   "vxi1" is started.

   <dialogstart prepareddialogid="vxi1" conf-id="conference11"/>

   When an MS has successfully received a <dialogstart> request, it MUST
   reply with a <response> element (Section 4.2).

4.1.3.  <dialogterminate>

   A dialog that has been successfully prepared or started can be
   terminated by a <dialogterminate> request element from the AS.

   The <dialogterminate> element has the following attributes:

   dialogid:  string identifying an existing dialog.  The method attribute is
      mandatory.

   immediate:  string with the values "true" or "false" indicating
      whether the dialog is to be terminated immediately or not.  If a
      dialog is terminated immediately, no further dialog event
      notifications are sent (including a dialogexit <event>). 'post').  The
      default value is "false". "application/x-www-form-url-encoded".  The
      attribute is optional.

   For example, assuming a dialog with the dialogid "vxi1"

   The <dialogstart> element has been
   started, it can be terminated immediately with the following request:

   <dialogterminate dialogid="vxi1" immediate="true"/>

   When additional child elements
   defined:

   <vxml>:  contains an MS has successfully received a <dialogterminate> request, it
   MUST reply with a <response> element (Section 4.2).

4.2.  Responses

   Responses are specified inline VoiceXML document in a <response> element.

4.2.1.  <response>

   Reponses to requests are indicated by a <response> element.

   The <response> element has following attributes:

   status:  numeric code indicating the response status.  The attribute
      is mandatory.

   reason:  string specifying a reason for the response status.  The
      attribute is optional.

   dialogid:  string identifying the dialog. VoiceXML
      namespace.  The attribute element is optional.

   connection-id:  string identifying the SIP dialog connection
      associated with the dialog

   <params>:  an XML data structure (see Section 16.1 of [SIPCF]).  The
      attribute is optional.

   conf-id:  string identifying the conference associated with 5.1) to pass parameters
      into the
      dialog (see Section 16.1 of [SIPCF]). dialog.  The attribute element is optional.

   The following status codes are defined:

   +-----------+-------------------------------------------------------+
   | code      | description                                           |
   +-----------+-------------------------------------------------------+
   | 200       | OK                                                    |
   |           |                                                       |
   | 401       | dialogid already exists                               |
   |           |                                                       |
   | 402       | dialogid does not exist                               |
   |           |                                                       |
   | 403       | connection-id does not exist                          |
   |           |                                                       |
   | 404       | conf-id does not exist                                |
   |           |                                                       |
   | 405       | Unknown or unsupported element                        |
   |           |                                                       |
   | 406       | Element required                                      |
   |           |                                                       |
   | 407       | Unknown or unsupported attribute                      |
   |           |                                                       |
   | 408       | Attribute required                                    |
   |           |                                                       |
   | 409       | Invalid VoiceXML URI or content                       |
   |           |                                                       |
   | 410       | data parameter not supported                          |
   |           |                                                       |
   | 411       | event subscription not supported                      |
   |           |                                                       |
   | 412       | stream parameter invalid                              |
   |           |                                                       |
   | 499       | other error                                           |
   +-----------+-------------------------------------------------------+

                     Table 1: <response> status codes

   [Editors Note: more status codes may need further work is required to be defined.]

   For example, a response when a dialog was prepared successfully:

   <response status="200" dialogid="vxi1"/>

   The response if dialog preparation failed due define how connection
   related information is passed to an invalid VoiceXML
   script:

    <response status="409" dialogid="vxi1"
       reason="HTTP 404: http://www.example.com/myscript.vxml"/>

   For example, a response when the dialog was started successfully.

    <response status="200" dialogid="vxi1"
                 connection-id="7HDY839~HJKSkyHS"/> VoiceXML interpreter.]

4.3.  Notifications

   Event notifications are specified in an <event> element.

4.3.1.  <event>

   Dialog event notifications are either manual or automatic.

   Manual event notifications are defined when an AS subscribes to
   notifications for dialog events using the <subscribe> element of
   <dialogprepare> or <dialogstart>.

   Automatic event notifications are defined as part

   Transfer behavior is not defined.

   [Editors Note: A later version of a Control
   Package.  The AS SHOULD NOT subscribe to these event notifications.
   The MS MUST support these event notifications.  This package defines
   one automatic notification event: "dialogexit" which indicates that
   an active dialog has terminated.  Note that this notification package may specify how
   <event> is not
   sent if the dialog has been terminated by the AS using a
   <dialogterminate/> request where "immediate=true".

   When a dialog generates a notification event, the MS sends the event
   to extended with child elements describing transfer events.]

4.4.  <dialogexit>

   This package extends the AS using an <event> element. definition of <dialogexit> in Section 4.3.2
   of [BASEIVRCP] as follows.

   The <event> <dialogexit> element has the following additional attributes:

   name:  string indicating

   termmode:  indicates how the name of voicexml dialog event.  The string is
      restricted to a sequence of alphanumeric was terminated.  Valid
      values are: exit, disconnect, or "." characters.  The
      attribute is mandatory.

   dialogid: implementation specific string identifying the dialog.
      values beginning with "_".  The attribute is mandatory.

   The <event> <dialogexit> element has the following additional child element:

   <data>:  an XML data structure (see Section 4.4) to pass information
      additional information about

   <params>:  parameters returned from the dialog event. dialog.  The element is
      optional.

   For example, when a dialog exits the MS may send a dialogexit <event>
   with data collected during the VoiceXML dialog execution:

   <event name="dialogexit" dialogid="vxi1">
    <data>
      <item name="userinput" value="12345"/>
    </data>

   </event>

4.4.  <data>

5.  Element Definitions

5.1.  <params>

   The <data> <params> element is a general container for parameterized data.

   The <data> element has no attributes, but has the following child
   elements defined:

   <item>:  contains

   <param>:  specifies a parameter.  Multiple instances of this element
      are permitted.  The element is mandatory.

   The <param> element has the following attributes:

   name:  a string indicating the name of the parameter.  The attribute
      is mandatory.

   type:  a string indicating the type of the value.  The attribute is
      optional.  The default is a string type.

   value:  a string indicating the value of the parameter.  Multiple
         values of a parameters can be specified using space separation.
      The attribute is mandatory.

   Multiple <item> elements may be specified.

   For example, a <data> specifying parameters with simple values:

  <data>
     <item name="initialuri" value="http://www.example.com/start.vxml"/>
     <item name="timeout" value="10s"/>
  </data>

   The <param> element has no children.

   [Editors Note: we may also want to investigate the use this defintion of <item>s
   nested within <param> may be extended in a top-level <item> later
   version to specify complex values. allow inline binary data, used reporting recordings when
   the dialog exits. ]

4.5.  <subscribe>

   The <subscribe> element is

6.  Examples

   [Editors Note: this section needs further work.]

   Example: a container for specifying dialog
   notification events request to which an AS subscribes.  Notifications of prepare a dialog events are delivered using the <event> element (see
   Section 4.3.1).

   The <subscribe> element has no attributes, but has where the following
   child elements defined:

   <notify>:  contains dialog script is is
   referenced:

   <dialogprepare type="application/voicexml+xml"
                     src="http://www.example.com/playprompt.vxml">
   </dialogprepare>

   In the following attributes:

      name:  a string indicating the name of example, the event to be notified
         of.  The attribute VoiceXML dialog script is mandatory. specified
   inline:

   <dialogprepare>
      <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
         <form id='main'>
            <block>
               <audio expr="http://www.example.com/media/prompt1.wav"/>
               <exit/>
             </block>
         </form>
      </vxml>
   </dialogprepare>

   The <notify> element may have following example shows a <data> child element.

   Multiple <notify> elements may be specified.

   For example, the AS wishes to subscribe request to DTMF and bargein
   notification events associated with start a dialog on a dialog:
   conference where the dialog script is indicated using the src
   attribute:

    <dialogstart src="promptandcollect"
        connection-id="7HDY839~HJKSkyHS~HUwkuh7ns">
    <subscribe>
       <notify name="dtmf"/>
       <notify name="bargein"/>
     </subscribe> conferenceid="conference11"
       type="application/voicexml+xml"
       src="http://www.example.com/playprompt.vxml">
       <params>
         <param name="media"
         value="http://www.example.com/media/prompt1.wav"/>
       </params>
    </dialogstart>

   If

   Where the MS supports these notification events, then it parameter "media" would use be available in the
   <event> element to send notifications during VoiceXML script
   as "connection.ccxml.values.media" so different prompts can be played
   using the same dialog to the AS
   when script.

   In the events occured.

   [Editors Note: It may be possible to define a general event
   subscription mechanism as part of following example, the SIP Control Framework.]

   [Editors Note: This Control Package does not specify VoiceXML dialog
   notification events apart from "dialogexit".  Later versions may
   define events such as: "dtmf" (a DTMF key is pressed), "mediastart"
   (media playback started), "bargein" (user has barged in on a prompt),
   and "rtpcontrol" (control data, e.g.  VFU, PoC, etc, script is received over
   the RTP control channel.]

5. specified
   inline.

    <dialogstart conferenceid="conference11">
        <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
         <form id='main'>
            <block>
               <audio expr="http://www.example.com/media/prompt1.wav"/>
               <exit/>
             </block>
          </form>
        </vxml>
     </dialogstart>

7.  Formal Syntax

   [Editors note: A later version of the

   This package defines an XML schema may be reference which extends the
   basic IVR msc-ivr-
   common.xsd schema and specify the package extensions defined in terms of
   schema extensions. ]

   [Editors note: A later version Section 9 of [BASEIVRCP].

   All elements in the XML defined schema will provide more
   constraints as expressed are in the textual definitions; for example,
   single occurrence of <data> elements, co-occurence on attributes,
   etc.]
   urn:ietf:params:xml:ns:msc-ivr-vxml namespace.

  <?xml version="1.0" encoding="UTF-8"?>
  <xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-ivr-vxml"
   xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
   elementFormDefault="qualified"
   xmlns="urn:ietf:params:xml:ns:msc-ivr-vxml"
   xmlns:vxml="http://www.w3.org/2001/vxml"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">

   <xsd:annotation>
    <xsd:documentation>
     IETF MediaCtrl VoiceXML IVR 1.0 (20080225)

     This is the schema of the VoiceXML IVR Control Package.
     It imports the msc-ivr-common schema (20061019) (dialogprepare, etc)
     and extends them for VoiceXML support.

     The schema namespace is urn:ietf:params:xml:ns:msc-ivr-vxml

    </xsd:documentation>
   </xsd:annotation>

     <xsd:import
         namespace="urn:ietf:params:xml:ns:control:framework-attributes"
     schemaLocation="framework.xsd"/>

   <!--  MODIFIED DEFINITIONS
    #############################################################

    SCHEMA IMPORTS

    #############################################################
   -->

   <xsd:redefine schemaLocation="msc-ivr-common.xsd">
    <xsd:annotation>
     <xsd:documentation>
      This import brings in the IVR common package Redefinitions: [1]
      Adds http related attributes in dialogprepare [2] Adds http
      related attributes in dialogstart [3] Allow params in dialogstart
      [4] Adds attribute and params to dialogexit
     </xsd:documentation>

    </xsd:annotation>

    <xsd:attributeGroup name="msc.ivr.common.dialogprepare.attlist">
     <xsd:attributeGroup ref="msc.ivr.common.dialogprepare.attlist" />
     <xsd:attributeGroup ref="httpparams" />
    </xsd:attributeGroup>

    <xsd:group name="msc.ivr.common.dialogstart.mix">
     <xsd:choice>
      <xsd:group ref="msc.ivr.common.dialogstart.mix" />
      <xsd:element name="dialogprepare">
    <xsd:complexType>
     <xsd:choice ref="params" minOccurs="0" maxOccurs="unbounded">
      <xsd:element ref="src"/>
      <xsd:element ref="httpparams"/>
      <xsd:element ref="data"/>
      <xsd:element ref="subscribe"/>
      <xsd:any namespace="##other" processContents="strict"/> maxOccurs="1" />
     </xsd:choice>
    </xsd:group>

    <xsd:attributeGroup name="msc.ivr.common.dialogstart.attlist">
     <xsd:attributeGroup ref="msc.ivr.common.dialogstart.attlist" />
     <xsd:attributeGroup ref="httpparams" />
    </xsd:attributeGroup>

    <xsd:attributeGroup name="msc.ivr.common.dialogexit.attlist">
     <xsd:attributeGroup ref="msc.ivr.common.dialogexit.attlist" />
     <xsd:attribute name="type" type="mime.datatype"/>
     <xsd:attribute name="src" type="URI.datatype" use="required"/>
     <xsd:attribute name="dialogid" type="dialogid.datatype"/>
     <xsd:anyAttribute namespace="##other" processContents="strict"/>
    </xsd:complexType>
   </xsd:element> name="termmode" type="vxml_termmode.datatype"
      use="required" />
    </xsd:attributeGroup>

    <xsd:group name="msc.ivr.common.dialogexit.mix">
     <xsd:choice>
      <xsd:group ref="msc.ivr.common.dialogexit.mix" />
      <xsd:element name="dialogstart">
    <xsd:complexType>
     <xsd:choice ref="params" minOccurs="0" maxOccurs="unbounded">
      <xsd:element ref="src"/>
      <xsd:element ref="httpparams"/>
      <xsd:element ref="stream"/>
      <xsd:element ref="data"/>
      <xsd:element ref="subscribe"/>
      <xsd:any namespace="##other" processContents="strict"/> maxOccurs="1" />
     </xsd:choice>
     <xsd:attribute name="type" type="mime.datatype"/>
     <xsd:attribute name="src" type="URI.datatype"/>
     <xsd:attribute name="dialogid" type="dialogid.datatype"/>
     <xsd:attribute name="prepareddialogid" type="dialogid.datatype"/>
    </xsd:group>

   </xsd:redefine>

   <!--
    #############################################################

    ELEMENTS

    #############################################################
   -->
   <!-- params -->

   <xsd:attributeGroup name="msc.ivr.vxml.params.attlist">
    <xsd:attributeGroup ref="msc.common.attribs" />
   </xsd:attributeGroup>

   <xsd:group name="msc.ivr.vxml.params.mix">
    <xsd:choice>
     <xsd:element ref="param" minOccurs="1" maxOccurs="unbounded" />
     <xsd:group ref="msc.common.content" minOccurs="0"
      maxOccurs="unbounded" />
    </xsd:choice>
   </xsd:group>

   <xsd:group name="msc.ivr.vxml.params.content">
    <xsd:sequence>
     <xsd:group ref="msc.ivr.vxml.params.mix" minOccurs="0"
      maxOccurs="unbounded" />
    </xsd:sequence>
   </xsd:group>

   <xsd:complexType name="msc.ivr.vxml.params.type">
    <xsd:group ref="msc.ivr.vxml.params.content" />
    <xsd:attributeGroup ref="fw:framework-attributes"/>
     <xsd:anyAttribute namespace="##other" processContents="strict"/> ref="msc.ivr.vxml.params.attlist" />
   </xsd:complexType>
   </xsd:element>

   <xsd:element name="params" type="msc.ivr.vxml.params.type" />

   <!--  ADDITIONAL VXML DEFINITIONS  param -->

      <xsd:simpleType name="mime.datatype">
          <xsd:restriction base="xsd:string"/>
      </xsd:simpleType>

   <xsd:element name="src">
    <xsd:complexType>
     <xsd:choice

   <xsd:attributeGroup name="msc.ivr.vxml.param.attlist">
    <xsd:attribute name="name" type="xsd:string" use="required" />
    <xsd:attribute name="valuetype" type="xsd:string" />
    <xsd:attribute name="value" type="xsd:string" />
    <xsd:attributeGroup ref="msc.common.attribs" />
   </xsd:attributeGroup>

   <xsd:group name="msc.ivr.vxml.param.mix">
    <xsd:choice>
     <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded">
      <xsd:any namespace="##other" processContents="strict"/>
      maxOccurs="unbounded" />
    </xsd:choice>
     <xsd:anyAttribute namespace="##other" processContents="strict"/>
   </xsd:group>

   <xsd:group name="msc.ivr.vxml.param.content">
    <xsd:sequence>
     <xsd:group ref="msc.ivr.vxml.param.mix" minOccurs="0"
      maxOccurs="unbounded" />

    </xsd:sequence>
   </xsd:group>

   <xsd:complexType name="msc.ivr.vxml.param.type" mixed="true">
    <xsd:group ref="msc.ivr.vxml.param.content" />
    <xsd:attributeGroup ref="msc.ivr.vxml.param.attlist" />
   </xsd:complexType>
   </xsd:element>

   <xsd:element name="param" type="msc.ivr.vxml.param.type" />

   <!--
    #############################################################

    ATTRIBUTES

    #############################################################
   -->

   <xsd:attributeGroup name="httpparams">
    <xsd:complexType>
     <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:any namespace="##other" processContents="strict"/>
     </xsd:choice>
    <xsd:attribute name="maxage" type="xsd:string"/> type="timedesignation.datatype" />
    <xsd:attribute name="maxstale" type="xsd:string"/> type="timedesignation.datatype" />
    <xsd:attribute name="enctype" type="xsd:string"
     default="application/x-www-form-urlencoded"/>
     default="application/x-www-form-urlencoded" />
    <xsd:attribute name="method" type="method.datatype"
     default="get"/>
     <xsd:anyAttribute namespace="##other" processContents="strict"/>
    </xsd:complexType>

   </xsd:element>

   <xsd:simpleType name="method.datatype">
    <xsd:restriction base="xsd:NMTOKEN">
     <xsd:enumeration value="get"/>
     <xsd:enumeration value="post"/>
    </xsd:restriction>
   </xsd:simpleType>

  <!-- UNCHANGED BASIC IVR DEFINITIONS -->

   <xsd:element name="dialogterminate">
    <xsd:complexType>
     <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:any namespace="##other" processContents="strict"/>
     </xsd:choice>
     <xsd:attribute name="dialogid" type="dialogid.datatype"
         use="required"/>
     <xsd:attribute name="immediate" type="boolean.datatype"
         default="false"/>
     <xsd:anyAttribute namespace="##other" processContents="strict"/>
    </xsd:complexType>
   </xsd:element>

   <xsd:element name="response">
    <xsd:complexType>
     <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:any namespace="##other" processContents="strict"/>
     </xsd:choice>
     <xsd:attribute name="status" type="status.datatype"
         use="required"/>
     <xsd:attribute name="reason" type="xsd:string"/>
     <xsd:attribute name="dialogid" type="dialogid.datatype"/>
     <xsd:attributeGroup ref="fw:framework-attributes"/>
     <xsd:anyAttribute namespace="##other" processContents="strict"/>
    </xsd:complexType>
   </xsd:element>

   <xsd:element name="event">
    <xsd:complexType>
     <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element ref="data"/>
      <xsd:any namespace="##other" processContents="strict"/>

     </xsd:choice>
     <xsd:attribute name="name" type="eventname.datatype"
         use="required"/>
     <xsd:attribute name="dialogid" type="dialogid.datatype"
         use="required"/>
     <xsd:anyAttribute namespace="##other" processContents="strict"/>
    </xsd:complexType>
   </xsd:element> default="get" />
   </xsd:attributeGroup>

   <!--
    #############################################################

    DATATYPES

    #############################################################
   -->

   <xsd:simpleType name="URI.datatype">
          <xsd:restriction base="xsd:anyURI"/>
      </xsd:simpleType>

      <xsd:simpleType name="dialogid.datatype">
          <xsd:restriction base="xsd:string"/>
      </xsd:simpleType>

   <xsd:simpleType name="boolean.datatype"> name="method.datatype">
    <xsd:restriction base="xsd:NMTOKEN">
     <xsd:enumeration value="true"/> value="get" />
     <xsd:enumeration value="false"/>
    </xsd:restriction>
   </xsd:simpleType>

   <xsd:simpleType name="eventname.datatype">
    <xsd:restriction base="xsd:NMTOKEN">
     <xsd:pattern value="[a-zA-Z0-9\.]+"/>
    </xsd:restriction>
   </xsd:simpleType>

   <xsd:simpleType name="status.datatype">
    <xsd:restriction base="xsd:NMTOKEN">
     <xsd:pattern value="[0-9][0-9][0-9]"/> value="post" />
    </xsd:restriction>
   </xsd:simpleType>

   <xsd:simpleType name="media.datatype"> name="vxml_termmode.datatype">
    <xsd:restriction base="xsd:string"/> base="xsd:string"></xsd:restriction>
   </xsd:simpleType>

   <xsd:simpleType name="label.datatype">
      <xsd:restriction base="xsd:string"/>
   </xsd:simpleType>
   <xsd:simpleType name="direction.datatype">
    <xsd:restriction base="xsd:NMTOKEN">
     <xsd:enumeration value="sendrecv"/>
     <xsd:enumeration value="sendonly"/>
     <xsd:enumeration value="recvonly"/>
    </xsd:restriction>
   </xsd:simpleType>

   <!-- SHARED ELEMENTS -->

   <xsd:element name="data">
    <xsd:complexType>
     <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element ref="item"/>
      <xsd:any namespace="##other" processContents="strict"/>
     </xsd:choice>
     <xsd:anyAttribute namespace="##other" processContents="strict"/>
    </xsd:complexType>
   </xsd:element>

   <xsd:element name="item">
    <xsd:complexType>
     <xsd:attribute name="name" type="xsd:string" use="required"/>
     <xsd:attribute name="value" type="xsd:string" use="required"/>
     <xsd:anyAttribute namespace="##other" processContents="strict"/>
    </xsd:complexType>
   </xsd:element>

   <xsd:element name="stream">
    <xsd:complexType>
     <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:any namespace="##other" processContents="strict"/>
     </xsd:choice>
     <xsd:attribute name="media" type="media.datatype"
         use="required"/>
     <xsd:attribute name="label" type="label.datatype"/>
     <xsd:attribute name="direction" type="direction.datatype"
                    default="sendrecv" />
     <xsd:anyAttribute namespace="##other" processContents="strict"/>
    </xsd:complexType>
   </xsd:element>

   <xsd:element name="subscribe">
    <xsd:complexType>
     <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element ref="notify"/>
     </xsd:choice>
     <xsd:anyAttribute namespace="##other" processContents="strict"/>
    </xsd:complexType>
   </xsd:element>

   <xsd:element name="notify">
    <xsd:complexType>
     <xsd:choice minOccurs="0" maxOccurs="1">
      <xsd:element ref="data"/>
     </xsd:choice>
     <xsd:attribute name="name" type="xsd:string" use="required"/>
     <xsd:anyAttribute namespace="##other" processContents="strict"/>
    </xsd:complexType>
   </xsd:element>

  </xsd:schema>

6.  Security Considerations

8.  Security Considerations to be included in later versions of

   As this
   document.

7. control package uses XML markup, implementation MUST address
   the security considerations of [RFC3023].

9.  IANA Considerations

   This document registers specification instructs IANA to register a new SIP Media Control
   Channel Framework Package and a new XML namespace.

7.1.

9.1.  Control Package Registration

   Control Package name: msc-ivr-vxml/1.0

7.2.

9.2.  URN Sub-Namespace Registration

   XML namespace: urn:ietf:params:xml:ns:msc-ivr-vxml

8.

10.  Change Summary

   The following are the primary changes between the -04 of the draft
   and the -03 version.

   o  Aligned with the -06 version of the basic ivr control package.

   o  Simplified the structure so that only differences with the basic
      ivr control package are specified.

   o  Specified how VoiceXML data is returned in a <dialogexit>

   o  replaced <data> with <params>

   o  updated references

   The following are the primary changes between the -03 of the draft
   and the -02 version.

   o  None

   The following are the primary changes between the -02 of the draft
   and the -01 version.

   o  Updated references.

   The following are the primary changes between the -01 of the draft
   and the -00 version.

   o  Changes in Basic IVR package version 02 applied.

9.

11.  Contributors

   Asher Shiratzky from Radvision provided valuable support and
   contributions to the early versions of this document.

12.  Acknowledgments

   TODO

10.

   TBD

13.  References

10.1.

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.

13.2.  Informative References

   [BASICIVRCP]

   [BASEIVRCP]
              Boulton, C., Melanchuk, T., McGlashan, S., and A.
              Shiratzky, S. McGlashan, "A Basic
              Interactive Voice Response (IVR) Control Package for the Session Initiation Protocol
              (SIP)", draft-boulton-ivr-control-package-04
              Media Control Channel Framework",
              draft-boulton-ivr-control-package-06 (work in progress), November 2007.
              February 2008.

   [CCXML10]  Auburn, R J., "Voice Browser Call Control: CCXML Version
              1.0", W3C Working Draft (work in progress), January 2007.

   [MSCP]

   [MCCF]     Boulton, C., Melanchuk, T., McGlashan, S., Auburn, R., Burke, D., Candell, E., and R.
              Surapaneni, A.
              Shiratzky, "Media Server Control Protocol (MSCP)",
              draft-mcglashan-mscp-03 Channel Framework",
              draft-ietf-mediactrl-sip-control-framework-01 (work in
              progress), March 2007. February 2008.

   [MSML]     Saleem, A., Xin, Y., and G. Sharratt, "Media Session
              Markup Language (MSML)", draft-saleem-msml-02 draft-saleem-msml-06 (work in
              progress), October 2006. February 2008.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
              Provisional Responses in Session Initiation Protocol
              (SIP)", RFC 3262, June 2002.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 2002.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC4240]  Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
              Media Services with SIP", RFC 4240, December 2005.

   [RFC4574]  Levin, O. and G. Camarillo, "The Session Description
              Protocol (SDP) Label Attribute", RFC 4574, August 2006.

   [RFC4722]  Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
              Control Markup Language (MSCML) and Protocol", RFC 4722,
              November 2006.

   [SIPCF]    Boulton, C., Melanchuk, T., McGlashan, S., and A.
              Shiratzky, "A Control Framework for the Session Initiation
              Protocol (SIP)", draft-boulton-sip-control-framework-05
              (work in progress), February 2007.

   [VXML20]   McGlashan, S., Burnett, D., Carter, J., Danielsen, P.,
              Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K.,
              and S. Tryphonas, "Voice Extensible Markup Language
              (VoiceXML) Version 2.0", W3C Recommendation, March 2004.

   [VXML21]   Oshry, M., Auburn, RJ., Baggia, P., Bodell, M., Burke, D.,
              Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee,
              A., Porter, B., and K. Rehor, "Voice Extensible Markup
              Language (VoiceXML) Version 2.1", W3C Recommendation,
              June 2007.

Authors' Addresses

   Chris Boulton
   Ubiquity Software Corporation
   Avaya
   Building 3
   Wern Fawr Lane
   St Mellons
   Cardiff, South Wales  CF3 5EA

   Email: cboulton@ubiquitysoftware.com cboulton@avaya.com

   Tim Melanchuk
   BlankSpace
   Rain Willow Communications

   Email: tim.melanchuk@gmail.com

   Scott McGlashan
   Hewlett-Packard
   Gustav III:s boulevard 36
   SE-16985 Stockholm, Sweden

   Email: scott.mcglashan@hp.com

   Asher Shiratzky
   Radvision
   24 Raoul Wallenberg st
   Tel-Aviv, Israel

   Email: ashers@radvision.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).