< draft-boulton-ivr-vxml-control-package-03.txt		draft-boulton-ivr-vxml-control-package-04.txt >
	Network Working Group C. Boulton		Network Working Group C. Boulton
	Internet-Draft Ubiquity Software Corporation		Internet-Draft Avaya
	Intended status: Standards Track T. Melanchuk		Intended status: Standards Track T. Melanchuk
	Expires: May 5, 2008 BlankSpace		Expires: August 26, 2008 Rain Willow Communications
	S. McGlashan		S. McGlashan
	Hewlett-Packard		Hewlett-Packard
	A. Shiratzky		February 23, 2008
	Radvision
	November 2, 2007
	A VoiceXML Interactive Voice Response (IVR) Control Package for the		A VoiceXML Control Package for the Media Control Channel Framework
	Session Initiation Protocol (SIP)		draft-boulton-ivr-vxml-control-package-04
	draft-boulton-ivr-vxml-control-package-03
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 37 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 5, 2008.		This Internet-Draft will expire on August 26, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document defines a Session Initiation (SIP) Control Package for		This document defines a VoiceXML Control Package for the Media
	Interactive Voice Response (IVR) interaction using VoiceXML. This		Control Channel Framework. This Control Package extends the Basic
	Control Package provides IVR functionality using the SIP Control		IVR control package with support for VoiceXML dialogs.
	Framework and extends the Basic IVR control package with support for
	VoiceXML dialogs.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4		2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
	3. Control Package Definition . . . . . . . . . . . . . . . . . . 5		3. Control Package Definition . . . . . . . . . . . . . . . . . . 5
	3.1. Control Package Name . . . . . . . . . . . . . . . . . . . 5		3.1. Control Package Name . . . . . . . . . . . . . . . . . . . 5
	3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 5		3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 5
	3.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 5		3.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 5
	3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 6		3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 5
	3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 6		3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 6
	4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 7		4. Element Extensions . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.1. <dialogprepare> . . . . . . . . . . . . . . . . . . . . . 7
	4.1.1. <dialogprepare> . . . . . . . . . . . . . . . . . . . 7		4.2. <dialogstart> . . . . . . . . . . . . . . . . . . . . . . 7
	4.1.2. <dialogstart> . . . . . . . . . . . . . . . . . . . . 9		4.3. <event> . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1.3. <dialogterminate> . . . . . . . . . . . . . . . . . . 12		4.4. <dialogexit> . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 13		5. Element Definitions . . . . . . . . . . . . . . . . . . . . . 10
	4.2.1. <response> . . . . . . . . . . . . . . . . . . . . . . 13		5.1. <params> . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 15		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.3.1. <event> . . . . . . . . . . . . . . . . . . . . . . . 15		7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.4. <data> . . . . . . . . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	4.5. <subscribe> . . . . . . . . . . . . . . . . . . . . . . . 16		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18		9.1. Control Package Registration . . . . . . . . . . . . . . . 18
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 24		9.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 18
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25		10. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 19
	7.1. Control Package Registration . . . . . . . . . . . . . . . 25		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
	7.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 25		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
	8. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 26		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27		13.1. Normative References . . . . . . . . . . . . . . . . . . . 22
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		13.2. Informative References . . . . . . . . . . . . . . . . . . 22
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
	10.2. Informative References . . . . . . . . . . . . . . . . . . 28		Intellectual Property and Copyright Statements . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
	Intellectual Property and Copyright Statements . . . . . . . . . . 31
	1. Introduction		1. Introduction
	The SIP Control Framework [SIPCF] provides a generic approach for		The Media Control Channel Framework [MCCF] provides a generic
	establishment and reporting capabilities of remotely initiated		approach for establishment and reporting capabilities of remotely
	commands. The Framework utilizes many functions provided by the		initiated commands. The Framework utilizes many functions provided
	Session Initiation Protocol [RFC3261] (SIP) for the rendezvous and		by the Session Initiation Protocol [RFC3261] (SIP) for the rendezvous
	establishment of a reliable channel for control interactions. The		and establishment of a reliable channel for control interactions.
	Control Framework also introduces the concept of a Control Package.		The Control Framework also introduces the concept of a Control
	A Control Package is an explicit usage of the Control Framework for a		Package. A Control Package is an explicit usage of the Control
	particular interaction set.		Framework for a particular interaction set.
	This specification defines a package for IVR functions using VoiceXML		This specification defines a Control Package for IVR functions using
	dialogs [VXML20]. As a recognized international standard for IVR		VoiceXML 2.0 dialogs ([VXML20], [VXML21]). As a recognized
	dialogs, VoiceXML is used extensively within media server control		international standard for IVR dialogs, VoiceXML is used extensively
	languages (cf. [MSCP], [CCXML10], [MSML], [RFC4722], [RFC4240]). To		within media server control languages (cf. [CCXML10], [MSML],
	ensure interoperability, if a media server supports this package,		[RFC4240]).
	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		To ensure interoperability, implementations MUST support VoiceXML 2.0
	([BASICIVRCP]). The extensions only affect the <dialogprepare> and		dialogs. They SHOULD support later versions of VoiceXML (e.g.
	<dialogstart> elements: in particular,		[VXML21]).
	1. dialog scripts may also be specified inline using a child <src>		The VoiceXML package extends the basic IVR control package
	element		([BASEIVRCP]) by replacing the basic ivr dialog type with a VoiceXML
			dialog type. In particular, this package
	2. a type attribute is introduced with the default value		1. extends <dialogprepare> and <dialogstart> elements to include
	"application/voicexml+xml"		inline <vxml> dialogs, http related attributes and a <params>
			element to pass information into the dialog.
	3. HTTP fetching and caching of dialog scripts can be configured		2. extends <dialogexit> to provide VoiceXML exit information
	using attributes of a child <httpparams> element
	Otherwise, this package follows precisely the syntax and semantics of		Otherwise, this package follows precisely the syntax and semantics of
	the basic IVR control package.		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		2. Conventions and Terminology
	In this document, BCP 14/RFC 2119 [RFC2119] defines the key words		In this document, BCP 14/RFC 2119 [RFC2119] defines the key words
	"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",		"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
	"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL". In addition, BCP 15 indicates requirement levels for		"OPTIONAL". In addition, BCP 15 indicates requirement levels for
	compliant implementations.		compliant implementations.
	The following additional terms are defined for use in this document:		The additional terms defined in Section 2 of [BASEIVRCP] are used 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.
	3. Control Package Definition		3. Control Package Definition
	This section fulfills the mandatory requirement for information that		This section fulfills the mandatory requirement for information that
	MUST be specified during the definition of a Control Framework		MUST be specified during the definition of a Control Framework
	Package, as detailed in Section 9 of [SIPCF].		Package, as detailed in Section 8 of [MCCF].
	3.1. Control Package Name		3.1. Control Package Name
	The Control Framework requires a Control Package definition to		The Control Framework requires a Control Package definition to
	specify and register a unique name and version.		specify and register a unique name and version.
	The name and version of this Control Package is "msc-ivr-vxml/1.0"		The name and version of this Control Package is "msc-ivr-vxml/1.0"
	(Media Server Control - Interactive Voice Response - VoiceXML -		(Media Server Control - Interactive Voice Response - VoiceXML -
	version 1.0 ).		version 1.0). Its IANA registration is specified in Section 9.1.
	3.2. Framework Message Usage		3.2. Framework Message Usage
	IVR functionality includes capabilities such as playing prompts,		The Control Framework requires a Control Package to explicitly detail
	collecting DTMF and recording user input. These functions are		the control messages that can be used as well as provide an
	expressed in VoiceXML dialogs.		indication of directionality between entities. This will include
			which role type is allowed to initiate a request type.
	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		This package adheres to Framework Message usage defined in Section
	codes. Framework error response codes (see Section 8 of [SIPCF]) are		3.2 of [BASEIVRCP]. This package extends the dialog control elements
	used when the request or event notification is invalid; for example,		as defined in Section 4; additional elements are defined in
	a request is invalid XML (400), or not understood (500). Package		Section 5. A XML Schema for this package is provided in Section 7.
	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		Implementation of this control package MUST adhere to the syntax and
	imported from schema defined in core Control Framework [SIPCF].		semantics of XML elements defined in this document. In cases where
			there is a difference in constraints between the XML schema and the
			textual description of elements, the textual definition takes
			priority.
	3.3. Common XML Support		3.3. Common XML Support
	The Control Framework requires a Control Package definition to		The Control Framework requires a Control Package definition to
	specify if the attributes for media dialog or conference references		specify if the attributes for media dialog or conference references
	are required.		are required.
	This package requires that the XML Schema in Section 16.1 of [SIPCF]		This package adheres to Common XML Support defined in Section 3.3 of
	MUST be supported for media dialogs and conferences.		[BASEIVRCP].
	3.4. CONTROL Message Body		3.4. CONTROL Message Body
	A valid CONTROL body message MUST conform to the schema defined in		The Control Framework requires a Control Package to define the
	Section 5 and described in Section 4. XML messages appearing in		control body that can be contained within a CONTROL command request
	CONTROL messages MUST contain a <dialogprepare>, <dialogstart> or		and to indicate the location of detailed syntax definitions and
	<dialogterminate> request element (Section 4.1).		semantics for the appropriate body types.
	3.5. REPORT Message Body
	A valid REPORT body MUST conform to the schema defined in Section 5		This package adheres to CONTROL Message Body as defined in Section
	and described in Section 4. XML messages appearing in REPORT		3.4 of [BASEIVRCP].
	messages MUST contain a <response> (Section 4.2), or a (notification)
	<event> element (Section 4.3).
	4. Element Definitions		3.5. REPORT Message Body
	This section defines the XML messages for this control package.		The Control Framework requires a control package definition to define
			the REPORT body that can be contained within a REPORT command
			request, or that no report package body is required. This section
			should indicate the location of detailed syntax definitions and
			semantics for the appropriate body types.
	[Editors Note: since XML Schema may not be able to express all		This package adheres to REPORT Message Body as defined in Section 3.5
	constraints expressed in these definitions, in cases where there is a		of [BASEIVRCP].
	difference in constraints, the definitions in the section take
	priority.]
	4.1. Requests		4. Element Extensions
	The following request elements are defined:		The XML elements used in this package are those defined in Section 4
			of [BASEIVRCP] unless otherwise specified in this section.
	<dialogprepare>: prepare an IVR dialog for later execution		4.1. <dialogprepare>
	<dialogstart>: start an IVR dialog on a connection or conference		This package extends the definition of <dialogprepare> request in
			Section 4.1.1 of [BASEIVRCP] as follows.
	<dialogterminate>: terminate an active IVR dialog		The <dialogprepare> element has the following modified attributes:
	4.1.1. <dialogprepare>		src: implementations MUST support the HTTP protocol
	The <dialogprepare> request is sent from the AS to the MS to request		type: The default value is "application/voicexml+xml".
	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:		The <dialogprepare> element has the following additional attributes:
	src: string identifying the URI of the dialog document to prepare.		maxage: string defining a time interval according to the max-age
	The attribute is mandatory. The MS MUST support VoiceXML 2.0		parameter in HTTP. The attribute is optional.
	dialogs and MAY support later versions of VoiceXML or other dialog
	types.
	type: string identifying the MIME type of the document. The default		maxstale: string defining a time interval according to the max-stale
	value is "application/voicexml+xml". The attribute is optional.		parameter in HTTP. The attribute is optional.
	dialogid: string indicating a unique name for the dialog. If this		method: string indicating the HTTP method to use. Permitted values
	attribute is not specified, the MS creates a unique name for the		are "post" or "get". The default value is "get". The attribute
	dialog. The value is used in subsequent references to the dialog		is optional.
	(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:		enctype: string identifying the encoding type of the submitted
			document (when the value of the method attribute is 'post'). The
			default value is "application/x-www-form-url-encoded". The
			attribute is optional.
	<data>: an XML data structure (see Section 4.4) to pass parameters		The <dialogprepare> element has the following additional child
	into the dialog. It is an error if a specified parameter is not		elements:
	supported by the implementation. The element is optional.
	<subscribe>: an XML data structure (see Section 4.5) indicating		<vxml>: contains an inline VoiceXML document in the VoiceXML
	notification events to which the AS subscribes. It is an error if		namespace. The element is optional.
	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.		4.2. <dialogstart>
	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]		This package extends the definition of <dialogstart> request in
	fetching and caching.		Section 4.1.2 of [BASEIVRCP] as follows.
	maxage: string defining a time interval according to the max-age		The <dialogstart> element has the following modified attributes:
	parameter in HTTP. The attribute is optional.
	maxstale: string defining a time interval according to the max-		src: implementations MUST support the HTTP URI protocol
	stale parameter in HTTP. The attribute is optional.
	enctype: string identifying the encoding type of the submitted		type: The default value is "application/voicexml+xml".
	document. The default value is "application/
	x-www-form-url-encoded". The attribute is optional.
	method: string indicating the HTTP method to use. Permitted		The <dialogstart> element has the following additional attributes:
	values are "post" or "get". The default value is "get". The
	attribute is optional.
	The element is optional.		maxage: string defining a time interval according to the max-age
			parameter in HTTP. The attribute is optional.
	Exactly one of the src attribute or the <src> element MUST be		maxstale: string defining a time interval according to the max-stale
	specified; otherwise, it is an error.		parameter in HTTP. The attribute is optional.
	For example, a request to prepare a dialog where the dialog script is		method: string indicating the HTTP method to use. Permitted values
	indicated using the src attribute:		are "post" or "get". The default value is "get". The attribute
			is optional.
	<dialogprepare src="http://www.example.com/playprompt.vxml">		enctype: string identifying the encoding type of the submitted
	<data>		document (when the value of the method attribute is 'post'). The
	<item name="audio" value="/media/prompt1.wav"/>		default value is "application/x-www-form-url-encoded". The
	</data>		attribute is optional.
	</dialogprepare>
	Where the data parameter "audio" would be available in the VoiceXML		The <dialogstart> element has the following additional child elements
	script as "connection.ccxml.values.audio" so different prompts can be		defined:
	played using the same dialog script.
	In the following example, the VoiceXML dialog script is specified		<vxml>: contains an inline VoiceXML document in the VoiceXML
	inline:		namespace. The element is optional.
	<dialogprepare>		<params>: an XML data structure (see Section 5.1) to pass parameters
	<src>		into the dialog. The element is optional.
	<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		[Editors Note: further work is required to define how connection
	MUST reply with a <response> element (Section 4.2).		related information is passed to the VoiceXML interpreter.]
	4.1.2. <dialogstart>		4.3. <event>
	The <dialogstart> element is sent by the AS to request execution of a		Transfer behavior is not defined.
	dialog. The dialog may be defined in the dialogstart request itself,
	or reference a previously prepared dialog.
	The <dialogstart> element has the following attributes:		[Editors Note: A later version of this package may specify how
			<event> is extended with child elements describing transfer events.]
	src: string identifying the URI of the dialog document to start.		4.4. <dialogexit>
	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		This package extends the definition of <dialogexit> in Section 4.3.2
	value is "application/voicexml+xml". The attribute is optional.		of [BASEIVRCP] as follows.
	dialogid: string indicating a unique name for the dialog. If this		The <dialogexit> element has the following additional attributes:
	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		termmode: indicates how the voicexml dialog was terminated. Valid
	using a dialogprepare request. The attribute is optional.		values are: exit, disconnect, or implementation specific string
			values beginning with "_". The attribute is mandatory.
	connection-id: string identifying the SIP dialog connection on which		The <dialogexit> element has the following additional child element:
	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		<params>: parameters returned from the dialog. The element is
	to be started (see Section 16.1 of [SIPCF]). The attribute is
	optional.		optional.
	The <dialogstart> element has the following child elements defined:		5. Element Definitions
	<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		5.1. <params>
	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		The <params> element is a general container for parameterized data.
	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		The <data> element has no attributes, but has the following child
	into the dialog. It is an error if a specified parameter is not		elements defined:
	supported by the implementation. The element is optional.
	<subscribe>: an XML data structure (see Section 4.5) indicating		<param>: specifies a parameter. Multiple instances of this element
	notification events to which the AS subscribes. It is an error if		are permitted. The element is mandatory.
	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 <param> element has the following attributes:
	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]		name: a string indicating the name of the parameter. The attribute
	fetching and caching.		is mandatory.
	maxage: string defining a time interval according to the max-age		type: a string indicating the type of the value. The attribute is
	parameter in HTTP. The attribute is optional.		optional. The default is a string type.
	maxstale: string defining a time interval according to the max-		value: a string indicating the value of the parameter. separation.
	stale parameter in HTTP. The attribute is optional.		The attribute is mandatory.
	enctype: string identifying the encoding type of the submitted		The <param> element has no children.
	document. The default value is "application/
	x-www-form-url-encoded". The attribute is optional.
	method: string indicating the HTTP method to use. Permitted		[Editors Note: this defintion of <param> may be extended in a later
	values are "post" or "get". The default value is "get". The		version to allow inline binary data, used reporting recordings when
	attribute is optional.		the dialog exits. ]
	The element is optional.		6. Examples
	[Editors Note: the <stream> element assumes that the use of the SDP		[Editors Note: this section needs further work.]
	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		Example: a request to prepare a dialog where the dialog script is is
	src attribute, <src> element or the type attribute.		referenced:
	If the prepareddialogid is not specified, exactly one of the src		<dialogprepare type="application/voicexml+xml"
	attribute or the <src> element MUST be specified; otherwise, it is an		src="http://www.example.com/playprompt.vxml">
	error.		</dialogprepare>
	Exactly one of the connection-id or conf-id attributes MUST be		In the following example, the VoiceXML dialog script is specified
	specified. It is an error to specify both connection-id and conf-id.		inline:
	If the prepareddialogid is specified and the <dialogprepare>		<dialogprepare>
	contained a <data> element, it is an error to specify it in		<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
	<dialogstart>. Likewise, If the prepareddialogid is specified and		<form id='main'>
	the <dialogprepare> contained a <subscribe> element, it is an error		<block>
	to specify it in <dialogstart>.		<audio expr="http://www.example.com/media/prompt1.wav"/>
			<exit/>
			</block>
			</form>
			</vxml>
			</dialogprepare>
	For example, a request to start a dialog on a conference where the		The following example shows a request to start a dialog on a
	dialog script is indicated using the src attribute:		conference where the dialog script is indicated using the src
			attribute:
	<dialogstart conf-id="conference11"		<dialogstart conferenceid="conference11"
			type="application/voicexml+xml"
	src="http://www.example.com/playprompt.vxml">		src="http://www.example.com/playprompt.vxml">
	<data>		<params>
	<item name="media" value="/media/prompt1.wav"/>		<param name="media"
	</data>		value="http://www.example.com/media/prompt1.wav"/>
			</params>
	</dialogstart>		</dialogstart>
	Where the data parameter "media" would be available in the VoiceXML		Where the parameter "media" would be available in the VoiceXML script
	script as "connection.ccxml.values.media" so different prompts can be		as "connection.ccxml.values.media" so different prompts can be played
	played using the same dialog script.		using the same dialog script.
	In the following example, the VoiceXML dialog script is specified		In the following example, the VoiceXML dialog script is specified
	inline.		inline.
	<dialogstart conf-id="conference11">		<dialogstart conferenceid="conference11">
	<src>
	<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">		<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
	<form id='main'>		<form id='main'>
	<block>		<block>
	<audio expr="http://www.example.com/media/prompt1.wav"/>		<audio expr="http://www.example.com/media/prompt1.wav"/>
	<exit/>		<exit/>
	</block>		</block>
	</form>		</form>
	</vxml>		</vxml>
	</src>
	</dialogstart>		</dialogstart>
	In this example, a previously prepared dialog with the dialogid		7. Formal Syntax
	"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.
	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:
	+-----------+-------------------------------------------------------+
	| 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.
	<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:		This package defines an XML schema which extends the msc-ivr-
			common.xsd schema defined in Section 9 of [BASEIVRCP].
	<data>: an XML data structure (see Section 4.4) to pass information		All elements in the defined schema are in the
	additional information about the dialog event. The element is		urn:ietf:params:xml:ns:msc-ivr-vxml namespace.
	optional.
	For example, when a dialog exits the MS may send a dialogexit <event>		<?xml version="1.0" encoding="UTF-8"?>
	with data collected during the VoiceXML dialog execution:		<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">
	<event name="dialogexit" dialogid="vxi1">		<xsd:annotation>
	<data>		<xsd:documentation>
	<item name="userinput" value="12345"/>		IETF MediaCtrl VoiceXML IVR 1.0 (20080225)
	</data>
	</event>		This is the schema of the VoiceXML IVR Control Package.
			It imports the msc-ivr-common schema (dialogprepare, etc)
			and extends them for VoiceXML support.
	4.4. <data>		The schema namespace is urn:ietf:params:xml:ns:msc-ivr-vxml
	The <data> element is a general container for parameterized data.		</xsd:documentation>
			</xsd:annotation>
	The <data> element has no attributes, but has the following child		<!--
	elements defined:		#############################################################
	<item>: contains the following attributes:		SCHEMA IMPORTS
	name: a string indicating the name of the parameter. The		#############################################################
	attribute is mandatory.		-->
	value: a string indicating the value of the parameter. Multiple		<xsd:redefine schemaLocation="msc-ivr-common.xsd">
	values of a parameters can be specified using space separation.		<xsd:annotation>
	The attribute is mandatory.		<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>
	Multiple <item> elements may be specified.		</xsd:annotation>
	For example, a <data> specifying parameters with simple values:		<xsd:attributeGroup name="msc.ivr.common.dialogprepare.attlist">
			<xsd:attributeGroup ref="msc.ivr.common.dialogprepare.attlist" />
			<xsd:attributeGroup ref="httpparams" />
			</xsd:attributeGroup>
	<data>		<xsd:group name="msc.ivr.common.dialogstart.mix">
	<item name="initialuri" value="http://www.example.com/start.vxml"/>		<xsd:choice>
	<item name="timeout" value="10s"/>		<xsd:group ref="msc.ivr.common.dialogstart.mix" />
	</data>		<xsd:element ref="params" minOccurs="0" maxOccurs="1" />
			</xsd:choice>
			</xsd:group>
	[Editors Note: we may also want to investigate the use of <item>s		<xsd:attributeGroup name="msc.ivr.common.dialogstart.attlist">
	nested within a top-level <item> to specify complex values. ]		<xsd:attributeGroup ref="msc.ivr.common.dialogstart.attlist" />
			<xsd:attributeGroup ref="httpparams" />
			</xsd:attributeGroup>
	4.5. <subscribe>		<xsd:attributeGroup name="msc.ivr.common.dialogexit.attlist">
			<xsd:attributeGroup ref="msc.ivr.common.dialogexit.attlist" />
			<xsd:attribute name="termmode" type="vxml_termmode.datatype"
			use="required" />
			</xsd:attributeGroup>
	The <subscribe> element is a container for specifying dialog		<xsd:group name="msc.ivr.common.dialogexit.mix">
	notification events to which an AS subscribes. Notifications of		<xsd:choice>
	dialog events are delivered using the <event> element (see		<xsd:group ref="msc.ivr.common.dialogexit.mix" />
	Section 4.3.1).		<xsd:element ref="params" minOccurs="0" maxOccurs="1" />
			</xsd:choice>
			</xsd:group>
	The <subscribe> element has no attributes, but has the following		</xsd:redefine>
	child elements defined:
	<notify>: contains the following attributes:		<!--
			#############################################################
	name: a string indicating the name of the event to be notified		ELEMENTS
	of. The attribute is mandatory.
	The <notify> element may have a <data> child element.		#############################################################
			-->
			<!-- params -->
	Multiple <notify> elements may be specified.		<xsd:attributeGroup name="msc.ivr.vxml.params.attlist">
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
	For example, the AS wishes to subscribe to DTMF and bargein		<xsd:group name="msc.ivr.vxml.params.mix">
	notification events associated with a dialog:		<xsd:choice>
			<xsd:element ref="param" minOccurs="1" maxOccurs="unbounded" />
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:choice>
			</xsd:group>
	<dialogstart src="promptandcollect"		<xsd:group name="msc.ivr.vxml.params.content">
	connection-id="7HDY839~HJKSkyHS~HUwkuh7ns">		<xsd:sequence>
	<subscribe>		<xsd:group ref="msc.ivr.vxml.params.mix" minOccurs="0"
	<notify name="dtmf"/>		maxOccurs="unbounded" />
	<notify name="bargein"/>		</xsd:sequence>
	</subscribe>		</xsd:group>
	</dialogstart>
	If the MS supports these notification events, then it would use the		<xsd:complexType name="msc.ivr.vxml.params.type">
	<event> element to send notifications during the dialog to the AS		<xsd:group ref="msc.ivr.vxml.params.content" />
	when the events occured.		<xsd:attributeGroup ref="msc.ivr.vxml.params.attlist" />
			</xsd:complexType>
	[Editors Note: It may be possible to define a general event		<xsd:element name="params" type="msc.ivr.vxml.params.type" />
	subscription mechanism as part of the SIP Control Framework.]
	[Editors Note: This Control Package does not specify dialog		<!-- param -->
	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.]
	5. Formal Syntax		<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>
	[Editors note: A later version of the XML schema may be reference the		<xsd:group name="msc.ivr.vxml.param.mix">
	basic IVR schema and specify the package extensions in terms of		<xsd:choice>
	schema extensions. ]		<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:choice>
			</xsd:group>
	[Editors note: A later version of the XML schema will provide more		<xsd:group name="msc.ivr.vxml.param.content">
	constraints as expressed in the textual definitions; for example,		<xsd:sequence>
	single occurrence of <data> elements, co-occurence on attributes,		<xsd:group ref="msc.ivr.vxml.param.mix" minOccurs="0"
	etc.]		maxOccurs="unbounded" />
	<?xml version="1.0" encoding="UTF-8"?>		</xsd:sequence>
	<xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-ivr-vxml"		</xsd:group>
	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:complexType name="msc.ivr.vxml.param.type" mixed="true">
	<xsd:documentation>		<xsd:group ref="msc.ivr.vxml.param.content" />
	VoiceXML IVR 1.0 schema (20061019)		<xsd:attributeGroup ref="msc.ivr.vxml.param.attlist" />
	</xsd:documentation>		</xsd:complexType>
	</xsd:annotation>
	<xsd:import		<xsd:element name="param" type="msc.ivr.vxml.param.type" />
	namespace="urn:ietf:params:xml:ns:control:framework-attributes"
	schemaLocation="framework.xsd"/>
	<!-- MODIFIED DEFINITIONS -->		<!--
			#############################################################
	<xsd:element name="dialogprepare">		ATTRIBUTES
	<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>
	<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:attributeGroup name="httpparams">
	<xsd:restriction base="xsd:string"/>		<xsd:attribute name="maxage" type="timedesignation.datatype" />
	</xsd:simpleType>		<xsd:attribute name="maxstale" type="timedesignation.datatype" />
			<xsd:attribute name="enctype" type="xsd:string"
			default="application/x-www-form-urlencoded" />
			<xsd:attribute name="method" type="method.datatype" default="get" />
			</xsd:attributeGroup>
	<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">		DATATYPES
	<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>
	</xsd:element>		#############################################################
			-->
	<xsd:simpleType name="method.datatype">		<xsd:simpleType name="method.datatype">
	<xsd:restriction base="xsd:NMTOKEN">		<xsd:restriction base="xsd:NMTOKEN">
	<xsd:enumeration value="get"/>		<xsd:enumeration value="get" />
	<xsd:enumeration value="post"/>		<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>
	<!-- 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:restriction>
	</xsd:simpleType>		</xsd:simpleType>
	<xsd:simpleType name="media.datatype">		<xsd:simpleType name="vxml_termmode.datatype">
	<xsd:restriction base="xsd:string"/>		<xsd:restriction 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>		</xsd:simpleType>
	<!-- SHARED ELEMENTS -->		</xsd:schema>
	<xsd:element name="data">		8. Security Considerations
	<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">		As this control package uses XML markup, implementation MUST address
	<xsd:complexType>		the security considerations of [RFC3023].
	<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">		9. IANA Considerations
	<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">		This specification instructs IANA to register a new Media Control
	<xsd:complexType>		Channel Framework Package and a new XML namespace.
	<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">		9.1. Control Package Registration
	<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>		Control Package name: msc-ivr-vxml/1.0
	6. Security Considerations		9.2. URN Sub-Namespace Registration
	Security Considerations to be included in later versions of this		XML namespace: urn:ietf:params:xml:ns:msc-ivr-vxml
	document.
	7. IANA Considerations		10. Change Summary
	This document registers a new SIP Control Framework Package and a new		The following are the primary changes between the -04 of the draft
	XML namespace.		and the -03 version.
	7.1. Control Package Registration		o Aligned with the -06 version of the basic ivr control package.
	Control Package name: msc-ivr-vxml/1.0		o Simplified the structure so that only differences with the basic
			ivr control package are specified.
	7.2. URN Sub-Namespace Registration		o Specified how VoiceXML data is returned in a <dialogexit>
	XML namespace: urn:ietf:params:xml:ns:msc-ivr-vxml		o replaced <data> with <params>
	8. Change Summary		o updated references
	The following are the primary changes between the -03 of the draft		The following are the primary changes between the -03 of the draft
	and the -02 version.		and the -02 version.
	o None		o None
	The following are the primary changes between the -02 of the draft		The following are the primary changes between the -02 of the draft
	and the -01 version.		and the -01 version.
	o Updated references.		o Updated references.
	The following are the primary changes between the -01 of the draft		The following are the primary changes between the -01 of the draft
	and the -00 version.		and the -00 version.
	o Changes in Basic IVR package version 02 applied.		o Changes in Basic IVR package version 02 applied.
	9. Acknowledgments		11. Contributors
	TODO		Asher Shiratzky from Radvision provided valuable support and
			contributions to the early versions of this document.
	10. References		12. Acknowledgments
	10.1. Normative References		TBD
			13. References
			13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	10.2. Informative References		13.2. Informative References
	[BASICIVRCP]		[BASEIVRCP]
	Boulton, C., Melanchuk, T., McGlashan, S., and A.		Boulton, C., Melanchuk, T., and S. McGlashan, "A Basic
	Shiratzky, "A Basic Interactive Voice Response (IVR)		Interactive Voice Response (IVR) Control Package for the
	Control Package for the Session Initiation Protocol		Media Control Channel Framework",
	(SIP)", draft-boulton-ivr-control-package-04 (work in		draft-boulton-ivr-control-package-06 (work in progress),
	progress), November 2007.		February 2008.
	[CCXML10] Auburn, R J., "Voice Browser Call Control: CCXML Version		[CCXML10] Auburn, R J., "Voice Browser Call Control: CCXML Version
	1.0", W3C Working Draft (work in progress), January 2007.		1.0", W3C Working Draft (work in progress), January 2007.
	[MSCP] McGlashan, S., Auburn, R., Burke, D., Candell, E., and R.		[MCCF] Boulton, C., Melanchuk, T., McGlashan, S., and A.
	Surapaneni, "Media Server Control Protocol (MSCP)",		Shiratzky, "Media Control Channel Framework",
	draft-mcglashan-mscp-03 (work in progress), March 2007.		draft-ietf-mediactrl-sip-control-framework-01 (work in
			progress), February 2008.
	[MSML] Saleem, A., Xin, Y., and G. Sharratt, "Media Session		[MSML] Saleem, A., Xin, Y., and G. Sharratt, "Media Session
	Markup Language (MSML)", draft-saleem-msml-02 (work in		Markup Language (MSML)", draft-saleem-msml-06 (work in
	progress), October 2006.		progress), February 2008.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		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,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of		[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
	Provisional Responses in Session Initiation Protocol		Provisional Responses in Session Initiation Protocol
	(SIP)", RFC 3262, June 2002.		(SIP)", RFC 3262, June 2002.
	[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation		[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
	skipping to change at page 29, line 15 ¶		skipping to change at page 23, line 19 ¶
	[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network		[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
	Media Services with SIP", RFC 4240, December 2005.		Media Services with SIP", RFC 4240, December 2005.
	[RFC4574] Levin, O. and G. Camarillo, "The Session Description		[RFC4574] Levin, O. and G. Camarillo, "The Session Description
	Protocol (SDP) Label Attribute", RFC 4574, August 2006.		Protocol (SDP) Label Attribute", RFC 4574, August 2006.
	[RFC4722] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server		[RFC4722] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
	Control Markup Language (MSCML) and Protocol", RFC 4722,		Control Markup Language (MSCML) and Protocol", RFC 4722,
	November 2006.		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.,		[VXML20] McGlashan, S., Burnett, D., Carter, J., Danielsen, P.,
	Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K.,		Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K.,
	and S. Tryphonas, "Voice Extensible Markup Language		and S. Tryphonas, "Voice Extensible Markup Language
	(VoiceXML) Version 2.0", W3C Recommendation, March 2004.		(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		Authors' Addresses
	Chris Boulton		Chris Boulton
	Ubiquity Software Corporation		Avaya
	Building 3		Building 3
	Wern Fawr Lane		Wern Fawr Lane
	St Mellons		St Mellons
	Cardiff, South Wales CF3 5EA		Cardiff, South Wales CF3 5EA
	Email: cboulton@ubiquitysoftware.com		Email: cboulton@avaya.com
	Tim Melanchuk		Tim Melanchuk
	BlankSpace		Rain Willow Communications
	Email: tim.melanchuk@gmail.com		Email: tim.melanchuk@gmail.com
	Scott McGlashan		Scott McGlashan
	Hewlett-Packard		Hewlett-Packard
	Gustav III:s boulevard 36		Gustav III:s boulevard 36
	SE-16985 Stockholm, Sweden		SE-16985 Stockholm, Sweden
	Email: scott.mcglashan@hp.com		Email: scott.mcglashan@hp.com
	Asher Shiratzky
	Radvision
	24 Raoul Wallenberg st
	Tel-Aviv, Israel
	Email: ashers@radvision.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 163 change blocks.
	774 lines changed or deleted		390 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/