Network Working Group C. Boulton
Internet-Draft Ubiquity Software Corporation
Intended status: Standards Track T. Melanchuk
Expires: April 26, 2007 BlankSpace
S. McGlashan
Hewlett-Packard
A. Shiratzky
Radvision
October 23, 2006
A VoiceXML Interactive Voice Response (IVR) Control Package for the
Session Initiation Protocol (SIP)
draft-boulton-ivr-vxml-control-package-01
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 April 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Boulton, et al. Expires April 26, 2007 [Page 1]
Internet-Draft Media Server Control Package October 2006
Abstract
This document defines a Session Initiation (SIP) Control Package for
Interactive Voice Response (IVR) interaction using VoiceXML. 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
3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 6
4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 7
4.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. <dialogprepare> . . . . . . . . . . . . . . . . . . . 7
4.1.2. <dialogstart> . . . . . . . . . . . . . . . . . . . . 9
4.1.3. <dialogterminate> . . . . . . . . . . . . . . . . . . 12
4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. <response> . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1. <event> . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. <data> . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. <subscribe> . . . . . . . . . . . . . . . . . . . . . . . 16
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7.1. Control Package Registration . . . . . . . . . . . . . . . 25
7.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 25
8. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Boulton, et al. Expires April 26, 2007 [Page 2]
Internet-Draft Media Server Control Package October 2006
1. Introduction
The SIP Control Framework [SIPCF] 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 for IVR functions using VoiceXML
dialogs [VXML20]. As a recognized international standard for IVR
dialogs, VoiceXML is used extensively within media server control
languages (cf. [MSCP], [CCXML10], [MSML], [MSCML], [RFC4240]). To
ensure interoperability, if a media server supports this package,
then it MUST support VoiceXML 2.0 dialog scripts. It MAY support
later versions of VoiceXML or other dialog script formats.
The VoiceXML package extends the basic IVR control package
([BASICIVRCP]). The extensions only affect the <dialogprepare> and
<dialogstart> elements: in particular,
1. 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 dialog scripts can be configured
using attributes of a child <httpparams> element
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.
Boulton, et al. Expires April 26, 2007 [Page 3]
Internet-Draft Media Server Control Package October 2006
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 of dialogs, which are identified
by a URI and initiated by the application server.
Boulton, et al. Expires April 26, 2007 [Page 4]
Internet-Draft Media Server Control Package October 2006
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 of [SIPCF].
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 ).
3.2. Framework Message Usage
IVR functionality includes capabilities such as playing prompts,
collecting DTMF and recording user input. These functions are
expressed in VoiceXML dialogs.
This package defines XML elements in Section 4 and provides an XML
Schema in Section 5.
The XML elements in this package are split into requests, responses
and event notifications. Requests are carried in CONTROL message
bodies; <dialogprepare>, <dialogstart> and <dialogterminate> elements
are defined as package requests. Responses are carried either in
REPORT message or Control Framework 200 response bodies; the
<response> element is defined as a package response. Event
notifications are also carried 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 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].
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.
Boulton, et al. Expires April 26, 2007 [Page 5]
Internet-Draft Media Server Control Package October 2006
This package requires that the XML Schema in Section 16.1 of [SIPCF]
MUST be supported for media dialogs and conferences.
3.4. CONTROL Message Body
A valid CONTROL body message MUST conform to the schema defined in
Section 5 and described in Section 4. XML messages appearing in
CONTROL messages MUST contain a <dialogprepare>, <dialogstart> or
<dialogterminate> request element (Section 4.1).
3.5. REPORT Message Body
A valid REPORT body MUST conform to the schema defined in Section 5
and described in Section 4. XML messages appearing in REPORT
messages MUST contain a <response> (Section 4.2), or a (notification)
<event> element (Section 4.3).
Boulton, et al. Expires April 26, 2007 [Page 6]
Internet-Draft Media Server Control Package October 2006
4. Element Definitions
This section defines the XML messages for this control package.
[Editors Note: since XML Schema may not be able to express all
constraints expressed in these definitions, in cases where there is a
difference in constraints, the definitions in the section take
priority.]
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 the MS to request
preparation of an IVR dialog. A prepared dialog is executed when the
AS sends a <dialogstart> request referencing the prepared dialog (see
Section 4.1.2).
A <dialogprepare> element has the following attributes:
src: string identifying the URI of the dialog document to prepare.
The attribute is mandatory. The MS 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. 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:
Boulton, et al. Expires April 26, 2007 [Page 7]
Internet-Draft Media Server Control Package October 2006
<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.
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 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.
Boulton, et al. Expires April 26, 2007 [Page 8]
Internet-Draft Media Server Control Package October 2006
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: string identifying the URI of the dialog 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 the MIME type of the document. 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.
prepareddialogid: string identifying a dialog previously prepared
using a dialogprepare request. The attribute is optional.
Boulton, et al. Expires April 26, 2007 [Page 9]
Internet-Draft Media Server Control Package October 2006
connection-id: string identifying the SIP dialog connection on which
this dialog is to be started (see Section 16.1 of [SIPCF]). The
attribute is optional.
conf-id: string identifying the conference on which this dialog is
to be started (see Section 16.1 of [SIPCF]). The attribute is
optional.
The <dialogstart> element has the following child elements defined:
<stream>: contains the following 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 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. 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. 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.
Boulton, et al. Expires April 26, 2007 [Page 10]
Internet-Draft Media Server Control Package October 2006
<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.
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 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 the type attribute.
If the prepareddialogid is not specified, exactly one of the src
attribute or the <src> element MUST be specified; otherwise, it is an
error.
Exactly one 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:
Boulton, et al. Expires April 26, 2007 [Page 11]
Internet-Draft Media Server Control Package October 2006
<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 attribute is
mandatory.
Boulton, et al. Expires April 26, 2007 [Page 12]
Internet-Draft Media Server Control Package October 2006
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>). The
default is "false". The attribute is optional.
For example, assuming a dialog with the dialogid "vxi1" has been
started, it can be terminated immediately with the following request:
<dialogterminate dialogid="vxi1" immediate="true"/>
When an MS has successfully received a <dialogterminate> request, it
MUST reply with a <response> element (Section 4.2).
4.2. Responses
Responses are specified 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. The attribute is optional.
connection-id: string identifying the SIP dialog connection
associated with the dialog (see Section 16.1 of [SIPCF]). The
attribute is optional.
conf-id: string identifying the conference associated with the
dialog (see Section 16.1 of [SIPCF]). The attribute is optional.
The following status codes are defined:
Boulton, et al. Expires April 26, 2007 [Page 13]
Internet-Draft Media Server Control Package October 2006
+-----------+-------------------------------------------------------+
| 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 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 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.
Boulton, et al. Expires April 26, 2007 [Page 14]
Internet-Draft Media Server Control Package October 2006
<response status="200" dialogid="vxi1"
connection-id="7HDY839~HJKSkyHS"/>
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 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 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 the AS using an <event> element.
The <event> element has the following attributes:
name: string indicating the name of dialog event. The string is
restricted to a sequence of alphanumeric or "." characters. The
attribute is mandatory.
dialogid: string identifying the dialog. The attribute is
mandatory.
The <event> element has the following child element:
<data>: an XML data structure (see Section 4.4) to pass information
additional information about the dialog event. 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>
Boulton, et al. Expires April 26, 2007 [Page 15]
Internet-Draft Media Server Control Package October 2006
</event>
4.4. <data>
The <data> element is a general container for parameterized data.
The <data> element has no attributes, but has the following child
elements defined:
<item>: contains the following attributes:
name: a string indicating the name of the parameter. The
attribute is mandatory.
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>
[Editors Note: we may also want to investigate the use of <item>s
nested within a top-level <item> to specify complex values. ]
4.5. <subscribe>
The <subscribe> element is a container for specifying dialog
notification events to which an AS subscribes. Notifications of
dialog events are delivered using the <event> element (see
Section 4.3.1).
The <subscribe> element has no attributes, but has the following
child elements defined:
<notify>: contains the following attributes:
name: a string indicating the name of the event to be notified
of. The attribute is mandatory.
The <notify> element may have a <data> child element.
Multiple <notify> elements may be specified.
Boulton, et al. Expires April 26, 2007 [Page 16]
Internet-Draft Media Server Control Package October 2006
For example, the AS wishes to subscribe to DTMF and bargein
notification events associated with a dialog:
<dialogstart src="promptandcollect"
connection-id="7HDY839~HJKSkyHS~HUwkuh7ns">
<subscribe>
<notify name="dtmf"/>
<notify name="bargein"/>
</subscribe>
</dialogstart>
If the MS supports these notification events, then it would use the
<event> element to send notifications during the dialog to the AS
when the events occured.
[Editors Note: It may be possible to define a general event
subscription mechanism as part of the SIP Control Framework.]
[Editors Note: This Control Package does not specify 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, is received over
the RTP control channel.]
Boulton, et al. Expires April 26, 2007 [Page 17]
Internet-Draft Media Server Control Package October 2006
5. Formal Syntax
[Editors note: A later version of the XML schema may be reference the
basic IVR schema and specify the package extensions in terms of
schema extensions. ]
[Editors note: A later version of the XML schema will provide more
constraints as expressed in the textual definitions; for example,
single occurrence of <data> elements, co-occurence on attributes,
etc.]
<?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:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>
VoiceXML IVR 1.0 schema (20061019)
</xsd:documentation>
</xsd:annotation>
<xsd:import
namespace="urn:ietf:params:xml:ns:control:framework-attributes"
schemaLocation="framework.xsd"/>
<!-- MODIFIED DEFINITIONS -->
<xsd:element name="dialogprepare">
<xsd:complexType>
<xsd:choice 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"/>
</xsd:choice>
<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>
Boulton, et al. Expires April 26, 2007 [Page 18]
Internet-Draft Media Server Control Package October 2006
<xsd:element name="dialogstart">
<xsd:complexType>
<xsd:choice 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"/>
</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:attributeGroup ref="fw:framework-attributes"/>
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
</xsd:element>
<!-- ADDITIONAL VXML DEFINITIONS -->
<xsd:simpleType name="mime.datatype">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:element name="src">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="strict"/>
</xsd:choice>
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
</xsd:element>
<xsd:element 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"/>
<xsd:attribute name="maxstale" type="xsd:string"/>
<xsd:attribute name="enctype" type="xsd:string"
default="application/x-www-form-urlencoded"/>
<xsd:attribute name="method" type="method.datatype"
default="get"/>
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
Boulton, et al. Expires April 26, 2007 [Page 19]
Internet-Draft Media Server Control Package October 2006
</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"/>
Boulton, et al. Expires April 26, 2007 [Page 20]
Internet-Draft Media Server Control Package October 2006
</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>
<!-- 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">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true"/>
<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]"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="media.datatype">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="label.datatype">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
Boulton, et al. Expires April 26, 2007 [Page 21]
Internet-Draft Media Server Control Package October 2006
<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">
Boulton, et al. Expires April 26, 2007 [Page 22]
Internet-Draft Media Server Control Package October 2006
<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>
Boulton, et al. Expires April 26, 2007 [Page 23]
Internet-Draft Media Server Control Package October 2006
6. Security Considerations
Security Considerations to be included in later versions of this
document.
Boulton, et al. Expires April 26, 2007 [Page 24]
Internet-Draft Media Server Control Package October 2006
7. IANA Considerations
This document registers a new SIP Control Framework Package and a new
XML namespace.
7.1. Control Package Registration
Control Package name: msc-ivr-vxml/1.0
7.2. URN Sub-Namespace Registration
XML namespace: urn:ietf:params:xml:ns:msc-ivr-vxml
Boulton, et al. Expires April 26, 2007 [Page 25]
Internet-Draft Media Server Control Package October 2006
8. Change Summary
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.
Boulton, et al. Expires April 26, 2007 [Page 26]
Internet-Draft Media Server Control Package October 2006
9. Acknowledgments
TODO
Boulton, et al. Expires April 26, 2007 [Page 27]
Internet-Draft Media Server Control Package October 2006
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[BASICIVRCP]
Boulton, C., Melanchuk, T., McGlashan, S., and A.
Shiratzky, "A Basic Interactive Voice Response (IVR)
Control Package for the Session Initiation Protocol
(SIP)", draft-boulton-ivr-control-package-02 (work in
progress), October 2006.
[CCXML10] Auburn, R J., "Voice Browser Call Control: CCXML Version
1.0", W3C Working Draft (work in progress), June 2005.
[MSCML] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol",
draft-vandyke-mscml-09 (work in progress), June 2006.
[MSCP] McGlashan, S., Auburn, R., Burke, D., Candell, E., and R.
Surapaneni, "Media Server Control Protocol (MSCP)",
draft-mcglashan-mscp-02 (work in progress), July 2006.
[MSML] Saleem, A. and G. Sharratt, "Media Session Markup Language
(MSML)", draft-saleem-msml-01 (work in progress),
June 2006.
[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.
[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.
Boulton, et al. Expires April 26, 2007 [Page 28]
Internet-Draft Media Server Control Package October 2006
[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.
[SIPCF] Boulton, C., Melanchuk, T., McGlashan, S., and A.
Shiratzky, "A Control Framework for the Session Initiation
Protocol (SIP)", draft-boulton-sip-control-framework-04
(work in progress), October 2006.
[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.
Boulton, et al. Expires April 26, 2007 [Page 29]
Internet-Draft Media Server Control Package October 2006
Authors' Addresses
Chris Boulton
Ubiquity Software Corporation
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: cboulton@ubiquitysoftware.com
Tim Melanchuk
BlankSpace
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
Boulton, et al. Expires April 26, 2007 [Page 30]
Internet-Draft Media Server Control Package October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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).
Boulton, et al. Expires April 26, 2007 [Page 31]