< draft-boulton-ivr-control-package-05.txt		draft-boulton-ivr-control-package-06.txt >
	Network Working Group C. Boulton		Network Working Group C. Boulton
	Internet-Draft Avaya		Internet-Draft Avaya
	Intended status: Standards Track T. Melanchuk		Intended status: Standards Track T. Melanchuk
	Expires: May 17, 2008 TJM Consulting		Expires: August 26, 2008 Rain Willow Communications
	S. McGlashan		S. McGlashan
	Hewlett-Packard		Hewlett-Packard
	November 14, 2007		February 23, 2008
	A Basic Interactive Voice Response (IVR) Control Package for the Session		A Basic Interactive Voice Response (IVR) Control Package for the Media
	Initiation Protocol (SIP)		Control Channel Framework
	draft-boulton-ivr-control-package-05		draft-boulton-ivr-control-package-06
	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 38 ¶		skipping to change at page 1, line 38 ¶
	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 17, 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 Media Control Channel Framework Package for
	basic Interactive Voice Response (IVR) interaction. The control of		basic Interactive Voice Response (IVR) interaction.
	Media Servers and their related resources in decomposed network
	architectures plays an important role in various Next Generation
	Networks. This Control Package provides IVR functionality using the
	SIP Control Framework.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6		2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7
	3. Control Package Definition . . . . . . . . . . . . . . . . . . 7		3. Control Package Definition . . . . . . . . . . . . . . . . . . 8
	3.1. Control Package Name . . . . . . . . . . . . . . . . . . . 7		3.1. Control Package Name . . . . . . . . . . . . . . . . . . . 8
	3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 7		3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 8
	3.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 7		3.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 9
	3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 8		3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 9
	3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 8		3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 9
	4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 9		4. Dialog Management Element Definitions . . . . . . . . . . . . 11
	4.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1.1. <dialogprepare> . . . . . . . . . . . . . . . . . . . 9		4.1.1. <dialogprepare> . . . . . . . . . . . . . . . . . . . 12
	4.1.2. <dialogstart> . . . . . . . . . . . . . . . . . . . . 11		4.1.2. <dialogstart> . . . . . . . . . . . . . . . . . . . . 13
	4.1.3. <dialogterminate> . . . . . . . . . . . . . . . . . . 13		4.1.3. <dialogterminate> . . . . . . . . . . . . . . . . . . 16
	4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 13		4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 17
	4.2.1. <response> . . . . . . . . . . . . . . . . . . . . . . 13		4.2.1. <response> . . . . . . . . . . . . . . . . . . . . . . 17
	4.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 16		4.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 19
	4.3.1. <event> . . . . . . . . . . . . . . . . . . . . . . . 16		4.3.1. <event> . . . . . . . . . . . . . . . . . . . . . . . 19
	4.4. <data> . . . . . . . . . . . . . . . . . . . . . . . . . . 17		4.3.2. <dialogexit> . . . . . . . . . . . . . . . . . . . . . 19
	4.5. <subscribe> . . . . . . . . . . . . . . . . . . . . . . . 17		5. Basic IVR Dialog Element Definitions . . . . . . . . . . . . . 21
	5. IVR Template Dialogs . . . . . . . . . . . . . . . . . . . . . 19		5.1. <basicivr> . . . . . . . . . . . . . . . . . . . . . . . . 23
	5.1. Play Announcement . . . . . . . . . . . . . . . . . . . . 19		5.2. <prompt> . . . . . . . . . . . . . . . . . . . . . . . . . 23
	5.2. Prompt and Collect . . . . . . . . . . . . . . . . . . . . 26		5.2.1. <media> . . . . . . . . . . . . . . . . . . . . . . . 25
	5.3. Prompt and Record . . . . . . . . . . . . . . . . . . . . 37		5.2.2. <variable> . . . . . . . . . . . . . . . . . . . . . . 26
	5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 45		5.2.3. <dtmf> . . . . . . . . . . . . . . . . . . . . . . . . 27
	5.5. Type Definitions . . . . . . . . . . . . . . . . . . . . . 46		5.3. <collect> . . . . . . . . . . . . . . . . . . . . . . . . 28
	6. AS-MS Interaction Examples . . . . . . . . . . . . . . . . . . 48		5.3.1. <grammar> . . . . . . . . . . . . . . . . . . . . . . 31
	6.1. Starting an IVR dialog . . . . . . . . . . . . . . . . . . 48		5.4. <record> . . . . . . . . . . . . . . . . . . . . . . . . . 34
	6.2. IVR dialog fails to start . . . . . . . . . . . . . . . . 49		5.5. Exit Information . . . . . . . . . . . . . . . . . . . . . 36
	6.3. Preparing and starting an IVR dialog . . . . . . . . . . . 49		5.5.1. <promptinfo> . . . . . . . . . . . . . . . . . . . . . 37
	6.4. Terminating a dialog immediately . . . . . . . . . . . . . 51		5.5.2. <collectinfo> . . . . . . . . . . . . . . . . . . . . 37
	6.5. Terminating a dialog non-immediately . . . . . . . . . . . 51		5.5.3. <recordinfo> . . . . . . . . . . . . . . . . . . . . . 37
	7. Template Dialog Examples . . . . . . . . . . . . . . . . . . . 53		6. AS-MS Dialog Interaction Examples . . . . . . . . . . . . . . 39
	7.1. playannouncement . . . . . . . . . . . . . . . . . . . . . 53		6.1. Starting an IVR dialog . . . . . . . . . . . . . . . . . . 39
	7.2. promptandcollect . . . . . . . . . . . . . . . . . . . . . 54		6.2. IVR dialog fails to start . . . . . . . . . . . . . . . . 39
	7.3. promptandrecord . . . . . . . . . . . . . . . . . . . . . 56		6.3. Preparing and starting an IVR dialog . . . . . . . . . . . 40
	8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 57		6.4. Terminating a dialog . . . . . . . . . . . . . . . . . . . 41
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 62		7. Basic IVR Dialog Examples . . . . . . . . . . . . . . . . . . 43
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63		7.1. Playing announcements . . . . . . . . . . . . . . . . . . 43
	10.1. Control Package Registration . . . . . . . . . . . . . . . 63		7.2. Prompt and collect . . . . . . . . . . . . . . . . . . . . 44
	10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 63		7.3. Prompt and record . . . . . . . . . . . . . . . . . . . . 45
	11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 64
	12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 66		8. Type Definitions . . . . . . . . . . . . . . . . . . . . . . . 46
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67		9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 48
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68		9.1. msc-ivr-common.xsd . . . . . . . . . . . . . . . . . . . . 48
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 68		9.2. msc-ivr-basic.xsd . . . . . . . . . . . . . . . . . . . . 55
	14.2. Informative References . . . . . . . . . . . . . . . . . . 68		10. Security Considerations . . . . . . . . . . . . . . . . . . . 67
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68
	Intellectual Property and Copyright Statements . . . . . . . . . . 71		11.1. Control Package Registration . . . . . . . . . . . . . . . 68
			11.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 68
			11.3. Mime Type Registration . . . . . . . . . . . . . . . . . . 68
			12. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 69
			13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 72
			14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 73
			15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
			15.1. Normative References . . . . . . . . . . . . . . . . . . . 74
			15.2. Informative References . . . . . . . . . . . . . . . . . . 74
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76
			Intellectual Property and Copyright Statements . . . . . . . . . . 77
	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. This specification defines a package for		Framework for a particular interaction set. This document defines a
	basic IVR.		Control Package for basic IVR dialogs.
	The scope of the package is control of media server functions for		This package has been designed to satisfy the IETF MediaCtrl
	basic interactive media (e.g. play a prompt, collecting DTMF,		requirements ([I-D.ietf-mediactrl-requirements]) by building upon two
	recording user input) as well as notifications related to these		major approaches to IVR dialog design. These approaches address a
	functions.		wide range of IVR use cases and are used in many applications which
			are extensively deployed today.
	These functions and notifications are defined as messages in XML		First, the package is designed to provide the major IVR functionality
	[XML]. The message use XML elements for preparing, starting and		of SIP Media Server languages such as netann ([RFC4240]), MSCML
	stopping dialogs, as well as elements for responses and notifications		([RFC5022]) and MSML ([MSML]) which themselves build upon more
	([CCXML10], [MSML] and [MSCP]).		traditional non-SIP languages ([H.248.9], [RFC2897]). A key
			differentiator is that this package provides the functionality using
			the Media Control Channel Framework.
	This basic IVR package uses template dialogs to provide IVR		Second, its design is aligned with key concepts in W3C Voice Browser
	functionality. Three basicivr template dialogs are defined:		languages. The key dialog management mechanism is closely aligned
			with CCXML ([CCXML10]). The basic dialog functionality in this
			package can be seen as a subset of VoiceXML ([VXML20], [VXML21]):
			where possible, basic prompting, DTMF collection and media recording
			features are incorporated, but not any advanced VoiceXML constructs
			(such as <form>, its interpretation algorithm, or a dynamic data
			model). As W3C develops VoiceXML 3.0, we expect to see further
			alignment, especially in providing a set of basic independent
			primitive elements (such as prompt, collect and record) which can be
			re-used in different dialog languages.
	playannouncement: a dialog to play one or more prompts to the user		By reusing and building upon design patterns from these approaches to
			IVR languages, this package is intended to provide a foundation which
			is familiar to current IVR developers and sufficient for 'basic' IVR
			applications, as well as a path to other languages - including
			control packages which extend this package - which address more
			advanced applications.
	promptandcollect: a dialog to prompt the user and collect their		The scope of this package is 'basic' IVR functionality of a media
	input		server which includes:
	promptandrecord: a dialog to prompt the user and record their input		o playing one or more media resources as a prompt to the user
	Template dialogs are intended to provide basic IVR functionality		o collecting DTMF input from the user according to a grammar
	([H.248.9], [RFC4240], [MSML], [RFC2897] and [RFC5022]). The
	template approach follows previous approaches in that it provides IVR
	functionality which is commonly required for applications. It
	differs in that the functionality is expressed in XML using a
	reference to the template dialog, and parameters expressed in a
	simple XML data structure. This is a lightweight approach since the
	contents of the dialog itself does not need to be transported over
	the control channel (or fetched from an external source), only a
	template reference plus configuration data is required. From the
	developer's perspective, this simplifies application development:
	they do not need to write their IVR dialog using custom XML elements,
	they only need to reference the template dialog and, if required,
	populate a simple XML data structure to pass configuration data.
	To use a template dialog, the AS developer references it by name in		o recording user media input
	an XML message for preparing or starting a dialog; for example
	<dialogstart src="basicivr:promptandrecord"/>. The XML message may
	also contain template input parameters in a <data> element to
	configure specific behavior defined by the template dialog; e.g.
	using "prompts" with the value "http://www.example.com/welcome.wav".
	If the dialog starts successfully, a <response status="200"/> is
	returned. When the dialog is completed, the MS returns template
	output parameters in a dialogexit <event> notification to the AS.
	The implementation of template dialogs requires only that they adhere		Out of scope of this package are more advanced functions including
	to the syntax and semantics of templates described in this document.		ASR (Automatic Speech Recognition), TTS (Text-to-Speech), VoiceXML,
			fax and media transformation. Such functionality may be addressed by
			extension packages.
	Other control packages MAY be defined which extend the capabilities		This functionality of this package is defined by messages, containing
	of the templates dialogs defined in this document. Such control		XML [XML] elements, transported using the Media Control Channel
	packages MUST respect the syntax and semantics of this control		Framework. The XML elements can be divided into two types: dialog
	package.		management elements; and carried within those, elements which define
			the specific IVR operations for the dialog.
	This document specifies how the basic IVR control package fulfils the		Dialog management elements are designed to manage the general
	requirements of the SIP Control Framework control packages		lifecycle of a dialog. Elements are provided for preparing a dialog,
	(Section 3), which XML elements are defined by the package		starting the dialog on a conference or connection, and terminating
	(Section 4), the template dialog definitions (Section 5) as well as		execution of a dialog. Each of these elements is contained in a
	providing examples (Section 6, Section 7) and an XML schema		Media Control Channel Framework CONTROL message sent to the media
	(Section 8).		server. When the appropriate action has been executed, the media
			server sends a REPORT message (or a 200 if it can execute in time)
			with a response element indicating whether the operation was
			successful or not (e.g. if the dialog cannot be started, then the
			error is reported in this response). Once a dialog has been
			successfully started, the media server may send further event
			notifications in a framework CONTROL message. This package defines
			one event notification, namely a dialogexit event indicating that the
			dialog has exited. If the dialog has executed successful, the
			dialogexit event includes information collected during the dialog.
			If an error occurs during execution (e.g. a media resource failed to
			play, no recording resource available, etc), then error information
			is reported in the dialogexit event. Once a dialogexit event is
			sent, the dialog lifecycle is terminated.
			Specific dialog types are referenced or contained within dialog
			management elements for preparing and starting dialogs. This package
			defines a basic IVR dialog type which contains child elements for
			playing prompts to the user, collects DTMF input from the user and
			recording media input from the user. The child elements can co-occur
			in the basic IVR dialog type so as to provide 'play announcement',
			'prompt and collect' as well as 'prompt and record' functionality.
			Implementation of this control package MUST adhere to the syntax and
			semantics of XML elements described 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.
			Other control packages MAY extend this package. Two extension points
			are RECOMMENDED:
			1. Retaining the dialog management capability but extending the
			basic IVR dialog type by adding new capabilities. For example,
			adding speech recognition capability.
			2. Extending the dialog management capability with alternative
			dialog types. For example, using the VoiceXML dialog type rather
			than the basic IVR dialog type ([VXMLCP]).
			Otherwise, extension control packages MUST respect the syntax and
			semantics of this control package.
			This document specifies how the basic IVR control package fulfills
			the requirements of the Media Control Channel Framework control
			packages (Section 3), the dialog management elements defined by the
			package (Section 4), the basic IVR dialog type definitions
			(Section 5) as well as providing examples (Section 6, Section 7),
			type definitions (Section 8) and XML schema (Section 9).
	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 following additional terms are defined for use in this document:
	Dialog: A dialog performs media interaction with a user. A dialog		Dialog: A dialog performs media interaction with a user. A dialog
	is identified by a URI and has an associated mimetype. Dialogs		is specified as inline XML, or via a URI reference to an external
	typically feature basic capabilities such as playing audio		XML document type. Dialogs typically feature basic capabilities
	prompts, collecting DTMF input and recording audio input from the		such as playing audio prompts, collecting DTMF input and recording
	user. More advanced dialogs may also feature synthesized speech,		audio input from the user. More advanced dialogs may also feature
	recording and playback of video, recognition of spoken input, and		synthesized speech, recording and playback of video, recognition
	mixed initiative conversations.		of spoken input, and mixed initiative conversations.
	Application server: A SIP [RFC3261] application server (AS) hosts		Application server: A SIP [RFC3261] application server (AS) hosts
	and executes services such as interactive media and conferencing		and executes services such as interactive media and conferencing
	in an operator's network. An AS influences and impacts the SIP		in an operator's network. An AS influences and impacts the SIP
	session, in particular by terminating SIP sessions on a media		session, in particular by terminating SIP sessions on a media
	server, which is under its control.		server, which is under its control.
	Media Server: A media server (MS) processes media streams on behalf		Media Server: A media server (MS) processes media streams on behalf
	of an AS by offering functionality such as interactive media,		of an AS by offering functionality such as interactive media,
	conferencing, and transcoding to the end user. Interactive media		conferencing, and transcoding to the end user. Interactive media
	functionality is realized by way of dialogs, which are identified		functionality is realized by way of dialogs which are initiated by
	by a URI and initiated by the application server.		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 to specify and
	specify and register a unique name and version.		register a unique name and version.
	The name and version of this Control Package is "msc-ivr-basic/1.0"		The name and version of this Control Package is "msc-ivr-basic/1.0"
	(Media Server Control - Interactive Voice Response - Basic - version		(Media Server Control - Interactive Voice Response - Basic - version
	1.0 ).		1.0). Its IANA registration is specified in Section 11.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 using template dialogs defined in Section 5.		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		This package defines XML elements for dialog management in Section 4;
	Schema in Section 8.		these elements specify dialog requests, responses and event
			notifications. The package also defined elements for the basic IVR
			dialog type in Section 5. The basic IVR dialog elements are
			contained inside dialog management elements. XML Schema for all XML
			elements defined in this package are specified in Section 9.
	The XML elements in this package are split into requests, responses		In this package, the MS operates as a Control Framework Server in
	and event notifications. Requests are carried in CONTROL message		receiving requests from, and sending responses to, the AS (operating
	bodies; <dialogprepare>, <dialogstart> and <dialogterminate> elements		as Control Framework Client). These requests are carried in CONTROL
	are defined as package requests. Responses are carried either in		message bodies from AS to MS; <dialogprepare>, <dialogstart> and
	REPORT message or Control Framework 200 response bodies; the		<dialogterminate> elements are defined as package requests.
	<response> element is defined as a package response. Event		Responses to these requests are carried either in REPORT messages or
	notifications are also carried in REPORT message bodies; the <event>		Control Framework 200 response bodies with <response> element
	element is defined for package event notifications.		payload.
	Note that package responses are different from framework response		Note that package responses are different from framework response
	codes. Framework error response codes (see Section 8 of [SIPCF]) are		codes. Framework error response codes (see Section 8 of [MCCF]) are
	used when the request or event notification is invalid; for example,		used when the request or event notification is invalid; for example,
	a request is invalid XML (400), or not understood (500). Package		a request is invalid XML (400), or not understood (500). Package
	responses are carried in 200 response or REPORT message bodies. This		responses are carried in 200 response or REPORT message bodies. This
	package's response codes are defined in Section 4.2.1.		package's response codes are defined in Section 4.2.1.
	The schema uses "connection-id" and "conf-id" attributes which are		The MS also operates as a Control Framework Client in sending event
	imported from schema defined in core Control Framework [SIPCF].		notifications to the AS (Control Framework Server). Event
			notifications are carried in CONTROL message bodies; the <event>
			element is defined for package event notifications. AS responses are
			carried in Control Framework responses or, if the transaction is
			extended, in REPORT messages.
	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 requires that the XML Schema in Section 16.1 of [MCCF]
	MUST be supported for media dialogs and conferences.		MUST be supported for media dialogs and conferences.
			The package schema uses "connectionid" and "conferenceid" attributes
			which are imported from the XML schema.
	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 8 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.
			When operating as Control Framework Server, the MS receives CONTROL
			messages with a body containing a valid <dialogprepare>,
			<dialogstart> or <dialogterminate> request element. The syntax and
			semantics of these elements are defined in Section 4.1.
			When operating as Control Framework Client, the MS sends CONTROL
			messages with a body containing a valid notification <event> element.
			The syntax and semantics of this element is defined in Section 4.3.
	3.5. REPORT Message Body		3.5. REPORT Message Body
	A valid REPORT body MUST conform to the schema defined in Section 8		The Control Framework requires a control package definition to define
	and described in Section 4. XML messages appearing in REPORT		the REPORT body that can be contained within a REPORT command
	messages MUST contain a <response> (Section 4.2), or a (notification)		request, or that no report package body is required. This section
	<event> element (Section 4.3).		should indicate the location of detailed syntax definitions and
			semantics for the appropriate body types.
	4. Element Definitions		When operating as Control Framework Server, the MS sends REPORT
			bodies containing a valid <response> element. The syntax and
			semantics of this element is specified in Section 4.2.
	This section defines the XML messages for this control package.		When operating as Control Framework Client, the MS receives REPORT
			messages which SHOULD NOT contain a body.
	[Editors Note: since XML Schema may not be able to express all		[Editors Note:IVR01 need to clarify the behavior when the MS receives
	constraints expressed in these definitions, in cases where there is a		a REPORT in response to sending an event notification CONTROL.]
	difference in constraints, the definitions in the section take
	priority.]		4. Dialog Management Element Definitions
			This section defines the dialog management XML messages for this
			control package. These messages are divided into requests
			(Section 4.1), responses (Section 4.2) and notifications
			(Section 4.3).
	4.1. Requests		4.1. Requests
			Requests are send to the MS (operating as a Control Framework Server)
			in the body of CONTROL messages.
	The following request elements are defined:		The following request elements are defined:
	<dialogprepare>: prepare an IVR dialog for later execution		<dialogprepare>: prepare an IVR dialog for later execution
	<dialogstart>: start an IVR dialog on a connection or conference		<dialogstart>: start an IVR dialog on a connection or conference
	<dialogterminate>: terminate an active IVR dialog		<dialogterminate>: terminate an IVR dialog
			These elements control the life cycle of a dialog. Each dialog has
			the following states:
			IDLE: the dialog is uninitialized.
			PREPARING: the dialog is being prepared. If an error occurs the
			dialog transitions to the TERMINATED state.
			PREPARED: the dialog has been successfully prepared and has a valid
			dialog identifier.
			STARTING: the dialog is being started. If an error occurs the
			dialog transitions to the TERMINATED state.
			STARTED: the dialog has been successfully started and is now active.
			When the dialog exits (normally or terminated), or due to an
			error, a dialogexit notification event is sent and the dialog
			transitions to the TERMINATED state.
			TERMINATED: the dialog is terminated and its dialogid is no longer
			valid. No further dialog notifications are sent for this dialog.
			As a consequence, it is an error if the same dialog is prepared or
			started more than once.
	4.1.1. <dialogprepare>		4.1.1. <dialogprepare>
	The <dialogprepare> request is sent from the AS to the MS to request		The <dialogprepare> request is sent to the MS to request preparation
	preparation of an IVR dialog. A prepared dialog is executed when the		of an IVR dialog. Dialog preparation consists of (a) retrieving an
	AS sends a <dialogstart> request referencing the prepared dialog (see		external dialog document (if specified), and (b) validating the
	Section 4.1.2).		document both syntactically and semantically.
			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:		A <dialogprepare> element has the following attributes:
	src: string identifying the URI of the dialog document to prepare.		src: specifies the location of an external dialog document to
	The attribute is mandatory. The MS MUST support "basicivr:		prepare. A valid value is a URI (see Section 8.9). It is an
	playannouncement", "basicivr:promptandcollect" and "basicivr:		error if the document cannot be retrieved or processed (e.g. URI
	promptandrecord" basicivr template dialogs as the value for this		protocol not supported). The attribute is optional.
	attribute. The MS MAY support other URI formats.
			type: specifies the type of the external dialog document indicated
			in the 'src' attribute. A valid value is a MIME type (see
			Section 8.10). The attribute is optional.
	dialogid: string indicating a unique name for the dialog. If this		dialogid: string indicating a unique name for the dialog. If this
	attribute is not specified, the MS creates a unique name for the		attribute is not specified, the MS creates a unique name for the
	dialog. The value is used in subsequent references to the dialog		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		(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		with the same name already exists on the MS. The attribute is
	optional.		optional.
	The <dialogprepare> element has the following child elements:		The <dialogprepare> element in this package is extended with the the
			child element <basicivr> for inline Basic IVR dialog (see
			Section 5.1). Other packages which extend this package MAY use
			alternative dialog types.
	<data>: an XML data structure (see Section 4.4) to pass parameters		The dialog to prepare can either be specified inline as a child
	into the dialog. It is an error if a specified parameter is not		element or externally using the src attribute (but not both). It is
	supported by the implementation. The element is optional.		an error if both an inline dialog element and a src attribute are
			specified.
	<subscribe>: an XML data structure (see Section 4.5) indicating		When an MS receives a <dialogprepare> request, the dialog is in a
	notification events to which the AS subscribes. It is an error if		PREPARING state. If dialog preparation was successful, the dialog is
	a specified notification event is not supported by the		in a PREPARED state; otherwise the dialog is in a TERMINATED state.
	implementation. The element is optional.		The MS MUST reply to <dialogprepare> request with a <response>
			element (Section 4.2), reporting whether dialog preparation was
			successful or not.
	For example, a request to prepare a playannouncement dialog where a		Example: in CONTROL message from AS to MS, the following request
	single prompt is played once:		prepares a basic IVR dialog where a single prompt is played once:
	<dialogprepare src="basicivr:playannouncement">		<dialogprepare>
	<data>		<basicivr>
	<item name="prompts"		<prompt>
	value="http://www.example.com/prompt1.wav"/>		<media src="http://www.example.com/prompt1.wav"/>
	<item name="iterations" value="1"/>		</prompt>
	</data>		</basicivr>
	</dialogprepare>		</dialogprepare>
	When an MS has successfully received a <dialogprepare> request, it		Alternatively, the same dialog could be referenced:
	MUST reply with a <response> element (Section 4.2).
	[Editors Note. Using the src attribute to indicate the type of the
	dialog blocks reference to an external dialog. In the next version,
	a type attribute will be added to both <dialogprepare> and
	<dialogstart> to indicate the MIME type of the dialog and the src
	attribute will have a URI value for external dialogs. The dialog can
	then be specified inline or externally (but not both).]
	[Editors Note. We are investigating whether to re-structure the
	content of basicivr commands (no change in content). This could
	include:
	Container elements <playannouncement>, <promptandcollect> and		<dialogprepare type="application/msc-ivr-basic+xml"
	<promptandrecord>. Each element would have the defined attributes		src="http://example.org/basic1.xml"/>
	for each dialog type.
	The <data> element would be obsoleted since information would		if the dialog is prepared successful, then a Control Framework 200 or
	expressed through these more specific elements.		a REPORT message for the same transaction would contain a response
			such as:
	For example,		<response status="200" dialogid="d100"/>
	<dialogprepare type="basicivr">		The Control Framework transaction is then complete.
	<playannouncement prompts="http://www.example.com/prompt1.wav"
	iterations="1"/>
	</dialogprepare>
	This approach is more compact than the current approach, and allows		See Section 6 and Section 7 for further examples.
	constraints on attribute values to be checked by an XML schema
	validator (the <data> approach does not allows this). We could go
	further and factor out prompt information into a separate <prompt>
	element which is then used in the above dialog types. ]
	4.1.2. <dialogstart>		4.1.2. <dialogstart>
	The <dialogstart> element is sent by the AS to request execution of a		The <dialogstart> element is sent by the AS to start a dialog. The
	dialog. The dialog may be defined in the dialogstart request itself,		dialog may be specified in the <dialogstart> request itself, or
	or reference a previously prepared dialog.		reference a previously prepared dialog.
			Starting a dialog consists of (a) retrieving any resources (e.g.
			media, grammar, etc) associated with the dialog, and (b) activating
			these resources according to the dialog type. For example, with
			<basicivr>, retrieving media resources and playing them to the user.
	The <dialogstart> element has the following attributes:		The <dialogstart> element has the following attributes:
	src: string identifying the URI of the dialog document to start.		src: specifies the location of an external dialog document to start.
	The attribute is optional. The MS MUST support "basicivr:		A valid value is a URI (see Section 8.9). It is an error if the
	playannouncement", "basicivr:promptandcollect" and "basicivr:		document cannot be retrieved or processed (e.g. URI protocol not
	promptandrecord" basicivr template dialogs as the value for this		supported). The attribute is optional.
	attribute. The MS MAY support other URI formats.
			type: specifies the type of the external dialog document indicated
			in the 'src' attribute. A valid value is a MIME type (see
			Section 8.10). The attribute is optional.
	dialogid: string indicating a unique name for the dialog. If this		dialogid: string indicating a unique name for the dialog. If this
	attribute is not specified, the MS creates a unique name for the		attribute is not specified, the MS creates a unique name for the
	dialog. The value is used in subsequent references to the dialog		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		(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		with the same name already exists on the MS. The attribute is
	optional.		optional.
	prepareddialogid: string identifying a dialog previously prepared		prepareddialogid: string identifying a dialog previously prepared
	using a dialogprepare request. The attribute is optional.		using a dialogprepare request. The attribute is optional.
	connection-id: string identifying the SIP dialog connection on which		connectionid: string identifying the SIP dialog connection on which
	this dialog is to be started (see Section 16.1 of [SIPCF]). The		this dialog is to be started (see Section 16.1 of [MCCF]). The
	attribute is optional.		attribute is optional.
	conf-id: string identifying the conference on which this dialog is		conferenceid: string identifying the conference on which this dialog
	to be started (see Section 16.1 of [SIPCF]). The attribute is		is to be started (see Section 16.1 of [MCCF]). The attribute is
	optional.		optional.
	If the prepareddialogid is specified, it is an error to specify the		Exactly one of the connectionid or conferenceid attributes MUST be
	src or dialogid attributes.		specified. It is an error to specify both connectionid and
			conferenceid attributes or neither.
	If the prepareddialogid is not specified, exactly the src attribute
	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.
	The <dialogstart> element has the following child elements defined:		The <dialogstart> element has the following child elements defined:
	<stream>: contains the following attributes:		<stream>: contains the following attributes:
	media: a string indicating the type of media associated with the		media: a string indicating the type of media associated with the
	stream. It is strongly recommended that the following values		stream. It is strongly RECOMMENDED that the following values
	are used for common types of media: "audio" for audio media,		are used for common types of media: "audio" for audio media,
	and "video" for video media. The attribute is mandatory.		and "video" for video media. The attribute is mandatory.
	label: a string indicating the SDP label associated with a media		label: a string indicating the SDP label associated with a media
	stream ([RFC4574]). The attribute is optional.		stream ([RFC4574]). The attribute is optional.
	direction: a string indicating the direction of the media flow		direction: a string indicating the direction of the media flow
	between a dialog and its end point conference or connection.		between a dialog and its end point conference or connection.
	Defined values are: "sendrecv" (media can be sent and		Defined values are: "sendrecv" (media can be sent and
	received), "sendonly" (media can only be sent), and "recvonly"		received), "sendonly" (media can only be sent), and "recvonly"
	skipping to change at page 12, line 30 ¶		skipping to change at page 15, line 5 ¶
	The attribute is optional.		The attribute is optional.
	One or more <stream> elements may be specified so that individual		One or more <stream> elements may be specified so that individual
	media streams can be controlled independently; for example, audio		media streams can be controlled independently; for example, audio
	only for transmission, but video only for reception. The <stream>		only for transmission, but video only for reception. The <stream>
	element is optional. If no <stream> elements are specified, then		element is optional. If no <stream> elements are specified, then
	the default is the media configuration of the connection or		the default is the media configuration of the connection or
	conference. It is an error if a <stream> element is in conflict		conference. It is an error if a <stream> element is in conflict
	with (a) another <stream> element, (b) with dialog, connection or		with (a) another <stream> element, (b) with dialog, connection or
	conference media capabilities, or (c) with a SDP label value as		conference media capabilities, or (c) with a SDP label value as
	part of the connection-id (see Section 16.1 of [SIPCF]).		part of the connectionid (see Section 16.1 of [MCCF]).
	<data>: an XML data structure (see Section 4.4) to pass parameters		The <dialogstart> element in this package is extended with the the
	into the dialog. It is an error if a specified parameter is not		child element <basicivr> for inline Basic IVR dialog (see
	supported by the implementation. The element is optional.		Section 5.1). Other packages which extend this package MAY use
			alternative dialog types.
	<subscribe>: an XML data structure (see Section 4.5) indicating		The dialog to start can be specified either inline, or externally, or
	notification events to which the AS subscribes. It is an error if		reference a previously prepared dialog. Exactly one of the src
	a specified notification event is not supported by the		attribute, the prepareddialogid or a dialog type child element MUST
	implementation.The element is optional.		be specified. If the prepareddialogid is specified, it is an error
			to specify the src attribute, the dialogid attribute or a dialog type
			child element. If the src attribute is specified, it is an error to
			specify the prepareddialogid attribute, or a dialog type child
			element. If a dialog type child element is specified, it is an error
			to specify the src attribute or the prepareddialogid attribute.
	[Editors Note: the <stream> element assumes that the use of the SDP		When an MS receives a <dialogstart> request, the dialog is either in
	label by itself is insufficient for media stream control. In		an IDLE or PREPARED state (if a previously prepared dialog is being
	particular, the SDP label does not address directionality, nor does		started). If in the IDLE state, then the dialog is first prepared
	it address conferences. Further investigation of the <stream> is		and if successful, transitions to the PREPARED state. When the
	required.]		prepared dialog is started it transitions to the STARTING state and,
			if the dialog is started successfully, the dialog then transition to
			the STARTED state. If a error occurs during dialog preparation or
			starting, then the error MUST be reported, and the dialog transitions
			to a TERMINATED state. The MS MUST reply to <dialogstart> request
			with a <response> element (Section 4.2), reporting whether the dialog
			was started successful or not.
	If the prepareddialogid is specified and the <dialogprepare>		[Editors Note:IVR02 This specification does not defined the behavior
	contained a <data> element, it is an error to specify it in		when more than one dialog is started on the same connection or
	<dialogstart>. Likewise, If the prepareddialogid is specified and		conference. Various models could be applied:
	the <dialogprepare> contained a <subscribe> element, it is an error
	to specify it in <dialogstart>.
	For example, a request to start a promptandrecord template dialog on		reject: only one dialog per connection or conference
	a conference:
	<dialogstart conf-id="conference11" src="basicivr:playandrecord">		replace: the current dialog is stopped and the new one started
	<data>
	<item name="maxtime" value="384000s"/>		queue: the new dialog is queued for starting after current dialog
	</data>		exits.
			mix: multiple dialogs are permitted with the same connection or
			conference: input is passed to both dialog; and dialog output is
			mixed.
			We also need to take into account that the <stream> element can be
			used to specify that different dialogs affect different media streams
			of the same connection or conference. For example, one dialog that
			only generates output, and another dialog on the same connection only
			receives input. Workgroup input on this issue is required. ]
			Example: in CONTROL message from AS to MS, the following request
			starts a basic ivr recording dialog on a conference:
			<dialogstart conferenceid="conference11">
			<basicivr>
			<record maxtime="384000s"/>
			</basicivr>
	</dialogstart>		</dialogstart>
	When an MS has successfully received a <dialogstart> request, it MUST		Alternatively, the same dialog could be referenced:
	reply with a <response> element (Section 4.2).
			<dialogstart conferenceid="conference11"
			type="application/msc-ivr-basic+xml"
			src="http://example.org/basic2.xml"/>
			if the dialog is started successfully, then a Control Framework 200
			or a REPORT message for the same transaction would contain a response
			such as:
			<response status="200" dialogid="d101" conferenceid="conference11"/>
			The Control Framework transaction is then complete.
			See Section 6 and Section 7 for further examples.
	4.1.3. <dialogterminate>		4.1.3. <dialogterminate>
	A dialog that has been successfully prepared or started can be		A dialog that has been successfully prepared or started can be
	terminated by a <dialogterminate> request element from the AS.		terminated by sending a <dialogterminate> request element to the MS.
	The <dialogterminate> element has the following attributes:		The <dialogterminate> element has the following attributes:
	dialogid: string identifying an existing dialog. The attribute is		dialogid: string identifying the dialog to terminate. The attribute
	mandatory.		is mandatory.
	immediate: string with the values "true" or "false" indicating		immediate: indicates whether the dialog is to be terminated
	whether the dialog is to be terminated immediately or not. If a		immediately or not. A valid value is a boolean (see Section 8.1).
	dialog is terminated immediately, no further dialog event		A value of true indicates that the dialog is terminated and a
	notifications are sent (including a dialogexit <event>). The		dialogexit <event> notification MUST be sent immediately. A value
	default is "false". The attribute is optional.		of false indicates that the dialog terminates normally, sending a
			dialogexit <event> notification is sent when the dialog has
			exited. The attribute is optional. The default value is false.
	For example, assuming a dialog with the dialogid "vxi1" has been		It is an error if the dialogid is invalid.
	started, it can be terminated immediately with the following request:
			When an MS receives a <dialogterminate> request, the dialog MUST be
			in a PREPARED, STARTING or STARTED states. If it is in a PREPARED
			state, then it transitions immediately to the TERMINATED state. If
			it is in STARTING state, then any further starting (or preparation)
			of the dialog is canceled, the response of the dialogstart command
			reporting that the dialog is terminated, and the dialog transitions
			to the TERMINATED state. If the dialog is in a STARTED state, then
			the dialog is terminated according to the value of the immediate
			attribute, and when the dialogexit notification is sent, the dialog
			moves into the TERMINATED state.
			The MS MUST reply to <dialogterminate> request with a <response>
			element (Section 4.2), reporting whether the dialog was stopped
			successful or not.
			Example: in CONTROL message from AS to MS, the following request
			terminate a dialog with dialogid "vxi1":
	<dialogterminate dialogid="vxi1" immediate="true"/>		<dialogterminate dialogid="vxi1" immediate="true"/>
	When an MS has successfully received a <dialogterminate> request, it		if the dialog is terminated successfully, then a Control Framework
	MUST reply with a <response> element (Section 4.2).		200 or a REPORT message for the same transaction would contain a
			response such as:
			<response status="200" dialogid="d100"/>
			The Control Framework transaction is then complete.
			See Section 6 and Section 7 for further examples.
	4.2. Responses		4.2. Responses
	Responses are specified in a <response> element.		Responses are generated in response to <dialogprepare>, <dialogstart>
			and <dialogterminate> requests. Responses are specified in a
			<response> element.
	4.2.1. <response>		4.2.1. <response>
	Reponses to requests are indicated by a <response> element.		Responses to requests are indicated by a <response> element.
	The <response> element has following attributes:		The <response> element has following attributes:
	status: numeric code indicating the response status. The attribute		status: numeric code indicating the response status. The attribute
	is mandatory.		is mandatory.
	reason: string specifying a reason for the response status. The		reason: string specifying a reason for the response status. The
	attribute is optional.		attribute is optional.
	dialogid: string identifying the dialog. The attribute is optional.		dialogid: string identifying the dialog. The attribute is optional.
	connection-id: string identifying the SIP dialog connection		connectionid: string identifying the SIP dialog connection
	associated with the dialog (see Section 16.1 of [SIPCF]). The		associated with the dialog (see Section 16.1 of [MCCF]). The
	attribute is optional.		attribute is optional.
	conf-id: string identifying the conference associated with the		conferenceid: string identifying the conference associated with the
	dialog (see Section 16.1 of [SIPCF]). The attribute is optional.		dialog (see Section 16.1 of [MCCF]). The attribute is optional.
	The following status codes are defined:		The following status codes are defined:
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	| code | description |		| code | description |
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	| 200 | OK |		| 200 | OK |
	| | |		| | |
	| 401 | dialogid already exists |		| 401 | dialogid already exists |
	| | |		| | |
	| 402 | dialogid does not exist |		| 402 | dialogid does not exist |
	| | |		| | |
	| 403 | connection-id does not exist |		| 403 | connectionid does not exist |
	| | |		| | |
	| 404 | conf-id does not exist |		| 404 | conferenceid does not exist |
	| | |		| | |
	| 405 | Unknown or unsupported element |		| 405 | Unknown or unsupported element |
	| | |		| | |
	| 406 | Element required |		| 406 | Element required |
	| | |		| | |
	| 407 | Unknown or unsupported attribute |		| 407 | Unknown or unsupported attribute |
	| | |		| | |
	| 408 | Attribute required |		| 408 | Attribute required |
	| | |		| | |
	| 409 | template dialog not supported |		| 409 | dialog type not supported |
	| | |
	| 410 | data parameter not supported |
	| | |		| | |
	| 411 | event subscription not supported |		| 410 | Retrieving document resource failed |
	| | |		| | |
	| 412 | stream parameter invalid |		| 411 | Invalid attribute value |
	| | |		| | |
	| 499 | other error |		| 499 | other error |
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	Table 1: <response> status codes		Table 1: <response> status codes
	[Editors Note: more status codes may need to be defined.]		[Editors Note:IVR03 more status codes may need to be defined.]
	For example, a response when a dialog was prepared successfully:		For example, a response when a dialog was prepared successfully:
	<response status="200" dialogid="vxi1"/>		<response status="200" dialogid="vxi1"/>
	The response if dialog preparation failed due to an unknown template:		The response if dialog preparation failed due to an unsupported
			dialog type:
	<response status="409" dialogid="vxi1"		<response status="409" dialogid="vxi1"
	reason="Unknown template: promptandrecod"/>		reason="Unsupported dialog type: application/basicirv+xml"/>
	For example, a response when the dialog was started successfully.		For example, a response when the dialog was started successfully.
	<response status="200" dialogid="vxi1"		<response status="200" dialogid="vxi1"
	connection-id="7HDY839~HJKSkyHS"/>		connectionid="7HDY839~HJKSkyHS"/>
			See Section 6 and Section 7 for further examples.
	4.3. Notifications		4.3. Notifications
	Event notifications are specified in an <event> element.		Event notifications are specified in an <event> element.
	4.3.1. <event>		Event notifications MUST NOT be sent unless the dialog is in a
			STARTED state.
	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		4.3.1. <event>
	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		When a dialog generates a notification event, the MS sends the event
	to the AS using an <event> element.		to the AS using an <event> element.
	The <event> element has the following attributes:		The <event> element has the following attributes:
	name: string indicating the name of dialog event. The string is		dialogid: string identifying the dialog which generated the event.
	restricted to a sequence of alphanumeric or "." characters. The		The attribute is mandatory.
	attribute is mandatory.
	dialogid: string identifying the dialog. The attribute is
	mandatory.
	The <event> element has the following child element:		The <event> element has the following child elements:
	<data>: an XML data structure (see Section 4.4) to pass information		<dialogexit>: indicates that the dialog has exited. The element is
	additional information about the dialog event. The element is
	optional.		optional.
	For example, when a dialog exits the MS may send a dialogexit <event>		Extension packages may define other child elements for notifications
	with data indicating the status of a template dialog:		which they support.
	<event name="dialogexit" dialogid="vxi1">		See Section 6 and Section 7 for examples.
	<data>
	<item name="status" value="1"/>
	</data>
	</event>
	4.4. <data>		4.3.2. <dialogexit>
	The <data> element is a general container for parameterized data.		The <dialogexit> event indicates that an active dialog has exited
			because it is complete, has been terminated, or because an error
			occurred during execution (for example, a media resource cannot be
			played). This event MUST be sent by the MS when the dialog exits.
			Once the dialogexit event is sent, the dialog transitions from the
			STARTED state to the TERMINATED state. The MS MUST NOT send any
			further notifications for a dialog in the TERMINATED state.
	The <data> element has no attributes, but has the following child		The <dialogexit> element has the following attributes:
	elements defined:
	<item>: contains the following attributes:		status: a status code indicating success or failure of the dialog.
			A valid value is a non-negative integer (see Section 8.4). A
			value of 0 indicates that the dialog has been terminated
			externally. A value of 1 indicates success. Any other value
			indicate an error. The attribute is mandatory.
	name: a string indicating the name of the parameter. The		reason: a textual description providing a reason for the status
	attribute is mandatory.		code; e.g. details about an error. A valid value is a string (see
			Section 8.6). The attribute is optional. There is no default
			value.
	value: a string indicating the value of the parameter. Multiple		[Editors Note:IVR04 do we need to specify specific error codes?]
	values of a parameters can be specified using space separation.
	The attribute is mandatory.
	Multiple <item> elements may be specified.		The <dialogexit> element in this package is extended with child
			elements for reporting prompt, collect and record information (see
			Section 5.5) of the basic IVR dialog type. Other packages which
			extend this package MAY use alternative child elements.
	For example, a <data> specifying promptandcollect template parameters		Example: when a STARTED <basicivr> dialog exits normally the MS sends
	with simple values:		a dialogexit <event>:
	<data>		<event dialogid="vxi1"/>
	<item name="iterations" value="5"/>		<dialogexit status="1">
	<item name="timeout" value="10s"/>		<collectinfo dtmf="1234" termmode="match"/>
	</data>		</dialogexit>
	In this example, a <data> specifying a playannouncement template with		See Section 6 and Section 7 for further examples.
	a complex value for the prompts parameter:
	<data>		5. Basic IVR Dialog Element Definitions
	<item name="prompts" value="http://example.com/balance.wav
	http://example.com/five.wav http://example.com/euros.wav"/>
	</data>
	[Editors Note: we may also want to investigate the use of <item>s		The basic IVR dialog is an instance of a dialog described in
	nested within a top-level <item> to specify complex values. ]		Section 4.1. The MS MUST support the Basic IVR dialog type in this
			package.
	4.5. <subscribe>		A basic IVR dialog is specified inline or by reference in
			<dialogprepare> (Section 4.1.1) or <dialogstart> (Section 4.1.2)
			elements. Inline basic ivr dialogs are specified in a <basicivr>
			child of these elements.
	The <subscribe> element is a container for specifying dialog		The basic IVR dialog is a simple XML container - <basicivr> - for
	notification events to which an AS subscribes. Notifications of		executing basic IVR operations of playing prompts (<prompt> - see
	dialog events are delivered using the <event> element (see		Section 5.2), collecting DTMF (<collect> - see Section 5.3),and
	Section 4.3.1).		recording user input (<record> - see Section 5.4. Results of the
			dialog execution are reported in a dialogexit notification event.
	The <subscribe> element has no attributes, but has the following		Three execution models are defined:
	child elements defined:
	<notify>: contains the following attributes:		playannouncements: only a <prompt> element is specified in the
			container. The prompt media resources are played in sequence.
	name: a string indicating the name of the event to be notified		promptandcollect: a <collect> element is specified and, optionally,
	of. The attribute is mandatory.		a <prompt> element. If a <prompt> element is specified and
			bargein is enabled, playing of the prompt is terminated when
			bargein occurs, and DTMF collection is initiated; otherwise, the
			prompt is played to completion before DTMF collection is
			initiated. If no prompt element is specified, DTMF collection is
			initiated immediately.
	The <notify> element may have a <data> child element.		promptandrecord: a <record> element is specified and, optionally, a
			<prompt> element. If a <prompt> element is specified and bargein
			is enabled, playing of the prompt is terminated when bargein
			occurs, and recording is initiated; otherwise, the prompt is
			played to completion before recording is initiated. If no prompt
			element is specified, recording is initiated immediately.
	Multiple <notify> elements may be specified.		Each of the core elements - <prompt>, <collect> and <record> - are
			specified so that their execution and reporting is largely self-
			contained. This facilitates their re-use in other dialog container
			elements.
	For example, the AS wishes to subscribe to DTMF and bargein		Execution results are reported in the <dialogexit> notification event
	notification events associated with a dialog:		whose definition is extended with the elements defined in
			Section 5.5. If the dialog terminated normally (i.e. not due to an
			error or to a <dialogterminate> request), then the MS MUST report the
			results for at least the core operation:
	<dialogstart src="basicivr:promptandcollect"		<prompt> only: <promptinfo> (see Section 5.5.1) with at least the
	connection-id="7HDY839~HJKSkyHS~HUwkuh7ns">		termmode attribute specified.
	<subscribe>
	<notify name="dtmf"/>
	<notify name="bargein"/>
	</subscribe>
	</dialogstart>
	If the MS supports these notification events, then it would use the		<collect>: <collectinfo> (see Section 5.5.2) with the dtmf and
	<event> element to send notifications during the dialog to the AS		termmode attributes specified.
	when the events occurred.
	[Editors Note: It may be possible to define a general event		<record>: <recordinfo> (see Section 5.5.3) with at least the
	subscription mechanism as part of the SIP Control Framework.]		recording, type and termmode attributes specified.
	[Editors Note: This Control Package does not specify dialog		The media format requirements for basic IVR dialogs are undefined.
	notification events apart from "dialogexit". Later versions may		This package is agnostic to the media types and codecs for media
	define events such as: "dtmf" (a DTMF key is pressed), "mediastart"		resources and recording which need to be supported by an
	(media playback started), "bargein" (user has barged in on a prompt),		implementation. For example, a MS implementation may choose to
	and "rtpcontrol" (control data, e.g. VFU, PoC, etc, is received over		support only audio and in particular the 'audio/basic' codec for
	the RTP control channel.]		media playback and recording. However, if an MS encounters when
			executing a dialog a media type or codec which it cannot process, the
			MS MUST stop further processing and report an error to the AS using
			the dialogexit notification.
	5. IVR Template Dialogs		The implementation of basic IVR dialogs MUST adhere to the syntax and
			semantics described in this section. Implementations MAY support
			additional (non-basicivr namespace) attributes and elements of these
			dialogs. If an implementation encounters additional (non-basicivr
			namespace) elements or attributes which it cannot process, it MUST
			ignore them and continue processing.
	The execution of IVR template dialog takes place on the MS. The AS		[Editors Note:IVR05 One use case which is not covered by this
	specifies the name of the template and configuration parameters, and		specification is that of attaching a dialog to a connection, which
	receives the result from the MS after the dialog has been executed.		itself is attached to a conference, and allowing that dialog to
			repeatedly collect and return matching DTMF without terminating. The
			current specification requires that the dialog exits at the end of
			its DTMF collection. For the next collection cycle, a new dialog
			would need to be started. If the use case is in scope for this
			package, then the definition of <basicivr> could be modified as
			follows:
	Input parameters are used to configure and customize the behavior of		1. A signalmode attribute/element is added to <basicivr> indicating
	the template. For many input parameters, the templates provide		the conditions under which the dialog sends a (non-terminating)
	default values; a developer can specify an alternative value if the		notification event (TBD). If any of its child elements completes
	default is not appropriate for their application. Input parameters		with a termmode value matching a condition (e.g. a 'match' from
	for templates may be mandatory, requiring a specific value to be		<collect>), then information collected by the children is
	provided.		returned to the AS in a notification event. The dialog is always
			restarted and it needs to be terminated by the AS (unless an
			error occurs).
	The result of executing a template dialog is reported to the AS using		2. If the signalmode attribute/element is not specified, then the
	output parameters. These parameters may describe status information,		behavior is as currently defined.
	error information or information collected from the user. Output
	parameters are mandatory or optional depending on the specific
	template; mandatory parameters must be specified by the
	implementation.
	Template dialogs are invoked by referencing them in the src attribute		3. Note that if media prompts were specified, the same prompts would
	of <dialogprepare> (Section 4.1.1) or <dialogstart> (Section 4.1.2).		play repeatedly - a more sophisticated approach would be required
	Input parameters are specified in the <data> child element		to play different prompts on different termmodes like nomatch,
	(Section 4.4) of these elements. Output parameters are specified in		noinput, etc
	the <data> child element of a dialogexit <event> notification
	(Section 4.3.1). The detailed mapping of template dialogs to XML
	CONTROL and REPORT messages is described in Section 3 and examples
	are provided in Section 7.
	The implementation of template dialogs MUST adhere to the syntax and		Working Group input is needed to determined if this use case is in
	semantics of templates described in this document. Implementations		scope for this package and whether this type of solution is
	MAY support additional parameters of the defined template dialogs.		adequate.]
	Implementations MAY support additional template dialogs. The actual
	implementation may be based on any technology or scripting language.
	The media requirements on the template implementation are restricted		5.1. <basicivr>
	to the capability to play audio prompts (specified as URIs), collect
	DTMF input, and record audio input. The implementation MUST support
	G.711 audio formats (headerless and wav) for playback and recording.
	The implementation MAY support other media formats.
	[Editors Note: Later versions may consider additional media		A dialog to play prompts to the user, collect DTMF or record input.
	requirements including TTS, ASR, video, etc. ]		The dialog is specified using a <basicivr> element with the namespace
			defined in Section 11.2.
	5.1. Play Announcement		A <basicivr> element has the following attributes:
	A template dialog to play announcements to the user.		version: a string specifying the version of the basicivr package.
			The attribute is optional. The default value is '1.0'.
	The template dialog is invoked using the URI "playannouncement".		The <basicivr> element has the following child elements:
	The dialog execution model consists of:		<prompt>: defines media resources to play in sequence (see
			Section 5.2). The element is optional.
	1. Playing prompts in the order specified until completion.		<collect>: defines how DTMF is collected (see Section 5.3). The
			element is optional.
	2. Repeating step 1 for the value of iterations.		<record>: defines how recording takes place (see Section 5.4). The
			element is optional.
	3. Returning status and reason parameters.		It is an error if no child element is specified. The behavior is not
			defined if both <collect> and <record> are specified.
	[Editors Note: the execution model needs to be updated for the		5.2. <prompt>
	following new attributes: duration, interval, maxage, maxstale,
	speed, volume and offset.]
	The input and output parameters are summarized and defined below.		The <prompt> element specifies a sequence of media resources to play.
	+------------+-----------+-----------------------------+------------+		A <prompt> element has the following attributes:
	| Name | Direction | Description | Definition |
	+------------+-----------+-----------------------------+------------+
	| prompts | input | prompts to play | Table 3 |
	| | | | |
	| iterations | input | maximum iterations | Table 4 |
	| | | | |
	| duration | input | maximum duration for the | Table 5 |
	| | | dialog including iterations | |
	| | | | |
	| interval | input | time to elapse between | Table 6 |
	| | | successive iterations | |
	| | | | |
	| maxage | input | maxage cache control for | Table 7 |
	| | | prompts | |
	| | | | |
	| maxstale | input | maxstale cache control for | Table 8 |
	| | | prompts | |
	| | | | |
	| speed | input | playback speed for prompts | Table 9 |
	| | | | |
	| volume | input | playback volume for prompts | Table 10 |
	| | | | |
	| offset | input | play from offset in prompts | Table 11 |
	| | | | |
	| status | output | status code | Table 12 |
	| | | | |
	| reason | output | reason for status | Table 13 |
	+------------+-----------+-----------------------------+------------+
	Table 2: playannouncement parameter overview		xml:base: A string declaring the base URI from which relative URIs
			in child elements are resolved. A valid value is a URI (see
			Section 8.9). The attribute is optional.
	Note that playannouncement requires at least one prompt specified in		bargein: Indicates whether user input stops prompt playback. A
	prompts.		valid value is a boolean (see Section 8.1). A value of true
			indicates that bargein is permitted and prompt playback is
			stopped. A value of false indicates that bargein is not
			permitted: user input does not terminate prompt playback. The
			attribute is optional. The default value is true.
	+-------------+-----------------------------------------------------+		iterations: number of times the prompt is to be played. A valid
	| Name | prompts |		value is a non-negative integer (see Section 8.4). A value of 0
	+-------------+-----------------------------------------------------+		indicates that the prompt is repeated until halted by other means.
	| Description | One or more prompts to play |		The attribute is optional. The default value is 1.
	| | |
	| Direction | input |
	| | |
	| Type | URIList |
	| | |
	| Optional | No |
	| | |
	| Possible | A valid URIList which is non-empty |
	| Values | |
	| | |
	| Default | none |
	+-------------+-----------------------------------------------------+
	Table 3: prompts		duration: maximum duration for the prompt playback. A valid value
			is a Time Designation (see Section 8.7). If no value is
			specified, then there is no limit on the duration of the prompt.
			The attribute is optional. There is no default value.
	+-------------+-----------------------------------------------------+		volume: playback volume for the prompt. A valid value is a
	| Name | iterations |		percentage (see Section 8.4). The value indicates increase or
	+-------------+-----------------------------------------------------+		decrease relative to the original recorded volume of the media. A
	| Description | Maximum number of times the playannouncement dialog |		value of 100% (the default) plays the media at its recorded
	| | is to be played |		volume, a value of 200% will play the media twice recorded volume,
	| | |		50% at half its recorded volume, and so on. The attribute is
	| Direction | input |		optional. The default value is 100%.
	| | |
	| Type | Non-Negative Integer |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid non-negative integer. A value of 0 |
	| Values | indicates that the dialog is repeated until halted |
	| | by other means. |
	| | |
	| Default | 1 |
	+-------------+-----------------------------------------------------+
	Table 4: iterations		offset: offset to begin playing the prompt. A valid value is a Time
			Designation (see Section 8.7). The offset is measured in normal
			media playback time from the beginning of the media resource. The
			attribute is optional. The default value is 0s.
	+-------------+-----------------------------------------------------+		The duration attribute takes priority over the iterations attribute
	| Name | duration |		in determining maximum duration of the prompt.
	+-------------+-----------------------------------------------------+
	| Description | Maximum duration for the dialog iterations |
	| | |
	| Direction | input |
	| | |
	| Type | Time Designation |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid TimeDesignation value. If no value is |
	| Values | specified, then there is no limit on the duration |
	| | of the dialog |
	| | |
	| Default | none |
	+-------------+-----------------------------------------------------+
	Table 5: duration		[Editors Note:IVR06 iterations could be replaced with 'repeatCount',
			duration with 'repeatDur', volume could be replaced with 'soundLevel'
			and offset with 'clipBegin' for better alignment with SMIL and
			possibly VoiceXML.]
	+-------------+-----------------------------------------------------+		[Editors Note:IVR07 should volume use a linear or logarithmic
	| Name | interval |		scaling?]
	+-------------+-----------------------------------------------------+
	| Description | time to elapse between successive iterations |
	| | |
	| Direction | input |
	| | |
	| Type | Time Designation |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid TimeDesignation value. |
	| Values | |
	| | |
	| Default | 0s |
	+-------------+-----------------------------------------------------+
	Table 6: interval		The <prompt> element has the following child elements:
	+-------------+-----------------------------------------------------+		<media>: media resource (see Section 5.2.1) to play. Multiple
	| Name | maxage |		instances of this element are permitted. The element is optional.
	+-------------+-----------------------------------------------------+
	| Description | maxage cache control for prompts |
	| | |
	| Direction | input |
	| | |
	| Type | Non-Negative Integer |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid non-negative integer. The value indicates |
	| Values | that the media server can use cached prompt |
	| | resources whose age must be no greater than |
	| | specified time in seconds (cf. 'max-age' in HTTP |
	| | 1.1 [RFC2616]). The media server will not use |
	| | stale resources, unless a maxstale value is also |
	| | provided. |
	| | |
	| Default | none |
	+-------------+-----------------------------------------------------+
	Table 7: maxage		<variable>: specifies a variable media announcement (see
			Section 5.2.2) to play. Multiple instances of this element are
			permitted. The element is optional.
	+-------------+-----------------------------------------------------+		<dtmf>: generates one or more DTMF tones (see Section 5.2.3) to
	| Name | maxstale |		play. Multiple instances of this element are permitted. The
	+-------------+-----------------------------------------------------+		element is optional.
	| Description | Maxstale cache control for prompts |
	| | |
	| Direction | input |
	| | |
	| Type | Non-Negative Integer |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid non-negative integer. The value indicates |
	| Values | that the media server can use cached prompt |
	| | resources which have exceeded their expiration time |
	| | by no more than the specified number of seconds |
	| | (cf. 'max-stale' in HTTP 1.1 [RFC2616]). |
	| | |
	| Default | none |
	+-------------+-----------------------------------------------------+
	Table 8: maxstale		It is an error if no child element is specified.
	+-------------+-----------------------------------------------------+		Prompt playing has the following execution model upon initialization:
	| Name | speed |
	+-------------+-----------------------------------------------------+
	| Description | Playback speed for prompts |
	| | |
	| Direction | input |
	| | |
	| Type | Percentage |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid percentage indicating rate increase or |
	| Values | decrease relative to the original rate of the |
	| | media. A value of 100% (the default) indicates no |
	| | modification of rate, 200% indicates twice the |
	| | original rate, a value of 50% indicates half the |
	| | original rate, and so on. |
	| | |
	| Default | 100% |
	+-------------+-----------------------------------------------------+
	Table 9: speed		1. If an error occurs during execution, then playback terminates and
			the error is reported in the status attribute (see Section 5.5)
			of the <dialogexit> event.
	+-------------+-----------------------------------------------------+		2. A iterations counter is initialized to 0.
	| Name | volume |
	+-------------+-----------------------------------------------------+
	| Description | Playback volume for prompts |
	| | |
	| Direction | input |
	| | |
	| Type | Percentage |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid percentage indicating increase or decrease |
	| Values | relative to the original recorded volume of the |
	| | media. A value of 100% (the default) plays the |
	| | media at its recorded volume, a value of 200% will |
	| | play the media twice recorded volume, 50% at half |
	| | its recorded volume, and so on. |
	| | |
	| Default | 100% |
	+-------------+-----------------------------------------------------+
	Table 10: volume		3. A timer is started for the value of the duration attribute. If
			the timer expires before playback is complete, then playback
			terminates and the dialogexit result contains the <promptinfo>
			termmode attribute set to maxduration (see Section 5.5.1).
	+-------------+-----------------------------------------------------+		4. A playback cycle is initiated playing each <media>, <variable>
	| Name | offset |		and <dtmf> in document order. The value of the volume attribute
	+-------------+-----------------------------------------------------+		is applied to each <media> and <variable> if they are rendered as
	| Description | Offset to begin playing prompts. The offset is |		audio media. If the offset attribute is specified, playback
	| | measured in normal media playback time from the |		begins at that offset. If the offset is greater than the
	| | beginning of the prompts. |		cumulative duration of the child elements, then no prompts are
	| | |		played in the cycle.
	| Direction | input |
	| | |
	| Type | Time Designation |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid time designation value. |
	| Values | |
	| | |
	| Default | 0s |
	+-------------+-----------------------------------------------------+
	Table 11: offset		5. If the value of the bargein attribute is true, then user input
			causes playback to terminate and the dialogexit result contains
			the <promptinfo> termmode attribute is set to bargein (see
			Section 5.5.1).
	+-------------+-----------------------------------------------------+		6. If the playback cycle completes successfully, then the iterations
	| Name | status |		counter is updated. If the counter reaches the value of the
	+-------------+-----------------------------------------------------+		iterations attribute, then playback is terminated and the
	| Description | A status code indicating success or failure of the |		dialogexit result contains a <promptinfo> termmode attribute set
	| | playannouncement dialog |		to completed (see Section 5.5.1). Otherwise, another playback
	| | |		cycle is initiated.
	| Direction | output |
	| | |
	| Type | Non-Negative Integer |
	| | |
	| Optional | No |
	| | |
	| Possible | 1 for success; otherwise an error code (600, 601, |
	| Values | 602). See Table 47 |
	| | |
	| Default | none |
	+-------------+-----------------------------------------------------+
	Table 12: status		[Editors Note:IVR08 Need to clarify that DTMF used for VCR controls
			does not cause playback to be stopped, but causes the appropriate
			operation to be applied to the playing prompts. ]
	+-------------+-----------------------------------------------------+		5.2.1. <media>
	| Name | reason |
	+-------------+-----------------------------------------------------+
	| Description | A textual description providing a reason for the |
	| | status code; e.g. details about an error |
	| | |
	| Direction | output |
	| | |
	| Type | String |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid String value |
	| Values | |
	| | |
	| Default | Empty string |
	+-------------+-----------------------------------------------------+
	Table 13: reason		The <media> element specifies a media resource to play.
	The following additional input parameters are under consideration for		A <media> element has the following attributes:
	later versions:
	+-----------+-------------------------------------------------------+		src: specifies the location of the media resource. A valid value is
	| Name | Description |		a URI (see Section 8.9). The attribute is mandatory.
	+-----------+-------------------------------------------------------+
	| variables | references to common types such as money, time, |
	| | numbers, etc |
	+-----------+-------------------------------------------------------+
	Table 14: Additional playannouncement parameters		type: specifies the type of the media resource indicated in the
			'src' attribute. The type value may include additional parameters
			for guiding playback; for example, [RFC4281] defines a 'codec'
			parameter for 'bucket' media types like video/3gpp. A valid value
			is a MIME type (see Section 8.10). The attribute is optional.
			There is no default value.
	5.2. Prompt and Collect		The <media> element has no children.
	A template dialog to play prompts and collect DTMF input.		It is an error if the media resource cannot be retrieved or played.
	The dialog is invoked with the URI "promptandcollect".		5.2.2. <variable>
	The dialog execution model consists of:		The <variable> element specifies variable announcements using
			predefined media resources. Each variable has at least a type (e.g.
			date) and a value (e.g. 2008-02-25). The value is rendered according
			to the variable type (e.g. 25th February 2008) as well as other
			defined attributes.
	1. Clearing the digit buffer depending on the value of		A <variable> element has the following attributes:
	cleardigitbuffer.
	2. Playing prompts in the order specified. The bargein parameter		value: specifies the string to be rendered. A valid value is a
	determines whether user input can be collected during prompt		string (see Section 8.6). The attribute is mandatory.
	playback stops (if so, prompt playback is stopped).
	3. Collecting DTMF input from the user. Valid DTMF patterns are		type: specifies the type to use for rendering. A valid value is a
	either a simple digit string where the maximum length is		string (see Section 8.6). The attribute is mandatory.
	determined by maxdigits and may be terminated by the character in
	termchar; or a custom DTMF grammar specified by grammar. The
	parameters timeout, interdigittimeout and termtimeout control
	user input timeout, interdigit timeout and the terminating
	timeout respectively.
	4. If no input is collected or the input is invalid, steps 1 - 3 are		format: specifies format information to use in conjunction with the
	repeated for the value of iterations.		type for the rendering. A valid value is a string (see
			Section 8.6). The attribute is optional. There is no default
			value.
	5. Returning status, reason and result parameters.		xml:lang: specifies the language to use when rendering the variable.
			A valid value is a language identifier (see Section 8.11). The
			attribute is optional. The default value is platform-specific.
	[Editors Note: the execution model needs to be updated for handling		[Editors Note:IVR09 do we need a gender attribute for variable
	VCR commands like rewind and fast-forwards.]		announcements? ]
	The input and output parameter are summarized and defined below.		The <variable> element has no children.
	+-------------------+-----------+----------------------+------------+		This package is agnostic to which <variable> values, types and
	| Name | Direction | Description | Definition |		formats are supported by an implementation. However it is
	+-------------------+-----------+----------------------+------------+		RECOMMENDED that an implementation support the following type/format
	| prompts | input | prompts to play | Table 16 |		combinations:
	| | | | |
	| iterations | input | maximum attempts | Table 17 |
	| | | | |
	| cleardigitbuffer | input | dtmf buffer clearing | Table 18 |
	| | | | |
	| bargein | input | interruption of | Table 19 |
	| | | prompts | |
	| | | | |
	| timeout | input | timeout for user | Table 20 |
	| | | input | |
	| | | | |
	| interdigittimeout | input | timeout between | Table 21 |
	| | | digits | |
	| | | | |
	| termtimeout | input | terminating timeout | Table 22 |
	| | | | |
	| termchar | input | terminating | Table 23 |
	| | | character | |
	| | | | |
	| maxdigits | input | maximum number of | Table 24 |
	| | | digits | |
	| | | | |
	| grammar | input | custom grammar | Table 25 |
	| | | | |
	| skipinterval | input | Interval to skip | Table 26 |
	| | | Backwards/Forwards | |
	| | | | |
	| ffkey | input | Maps a DTMF key to a | Table 27 |
	| | | fast forward | |
	| | | operation equal to | |
	| | | skipinterval | |
	| | | | |
	| rwkey | input | Maps a DTMF key to a | Table 28 |
	| | | rewind operation | |
	| | | equal to | |
	| | | skipinterval | |
	| | | | |
	| status | output | status code | Table 29 |
	| | | | |
	| reason | output | reason for status | Table 30 |
	| | | | |
	| result | output | input collected | Table 31 |
	+-------------------+-----------+----------------------+------------+
	promptandcollect parameter overview
	+-------------+-----------------------------------------------------+		type=date Supported formats: "mdy", "ymd", "dym"
	| Name | prompts |
	+-------------+-----------------------------------------------------+
	| Description | Initial prompts to play |
	| | |
	| Direction | input |
	| | |
	| Type | URIList |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid URIList |
	| Values | |
	| | |
	| Default | none |
	+-------------+-----------------------------------------------------+
	Table 16: prompts		type=time Supported formats: "t12", "t24"
	+-------------+-----------------------------------------------------+		type=digits Supported formats: "gen", "ndn", "crn", "ord"
	| Name | iterations |
	+-------------+-----------------------------------------------------+
	| Description | Maximum number of times the promptandcollect dialog |
	| | is to be played |
	| | |
	| Direction | input |
	| | |
	| Type | Non-Negative Integer |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid non-negative integer. A value of 0 |
	| Values | indicates the dialog is repeated until halted by |
	| | other means. |
	| | |
	| Default | 0 |
	+-------------+-----------------------------------------------------+
	Table 17: iterations		[Editors Note:IVR10 Further work needed on these definitions. Which
			other types and formats need to, or can, be specified? ]
	+-------------+-----------------------------------------------------+		This specification is agnostic to the type and codec of media
	| Name | cleardigitbuffer |		resources into which variable are rendered. For example, an MS
	+-------------+-----------------------------------------------------+		choosing to support audio may render the <variable> into one or more
	| Description | Clear digit buffer prior to prompt playback |		audio media resources.
	| | |
	| Direction | input |
	| | |
	| Type | Boolean |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid boolean value. A value of true indicates |
	| Values | that the digitbuffer is to be cleared. A value of |
	| | false indicates that the digitbuffer is not to be |
	| | cleared. |
	| | |
	| Default | true |
	+-------------+-----------------------------------------------------+
	Table 18: cleardigitbuffer		It is an error if a <variable> element cannot be rendered
			successfully.
	+-------------+-----------------------------------------------------+		Execution of this element can seen, at least logically, as conversion
	| Name | bargein |		of a <variable> into a list of <media> elements. For example,
	+-------------+-----------------------------------------------------+
	| Description | Indicates whether the user can interrupt the prompt |
	| | with their input |
	| | |
	| Direction | input |
	| | |
	| Type | Boolean |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid boolean value. A value of true indicates |
	| Values | that bargein is permitted. A value of false |
	| | indicates that bargein is not permitted. |
	| | |
	| Default | true |
	+-------------+-----------------------------------------------------+
	Table 19: bargein		<variable value="2008-02-25" type="date" format="dmy"
			xml:lang="en"/>
	+-------------+-----------------------------------------------------+		could be transformed into audio saying "twenty-fifth of February two
	| Name | timeout |		thousand and eight" using a list of <media> resources:
	+-------------+-----------------------------------------------------+
	| Description | Indicates the time to wait for user input |
	| | |
	| Direction | input |
	| | |
	| Type | Time Designation |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid TimeDesignation value. |
	| Values | |
	| | |
	| Default | 5s |
	+-------------+-----------------------------------------------------+
	Table 20: timeout		<media src="voicebase/en/25th.wav"/>
			<media src="voicebase/en/of.wav"/>
			<media src="voicebase/en/february.wav"/>
			<media src="voicebase/en/2000.wav"/>
			<media src="voicebase/en/and.wav"/>
			<media src="voicebase/en/8.wav"/>
	+-------------+-----------------------------------------------------+		5.2.3. <dtmf>
	| Name | interdigittimeout |
	+-------------+-----------------------------------------------------+
	| Description | The inter-digit timeout value to use when |
	| | recognizing DTMF input |
	| | |
	| Direction | input |
	| | |
	| Type | Time Designation |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid TimeDesignation value. |
	| Values | |
	| | |
	| Default | 2s |
	+-------------+-----------------------------------------------------+
	Table 21: interdigittimeout		The <dtmf> element specifies a sequence of DTMF tones for output.
	+-------------+-----------------------------------------------------+		DTMF tones could be generated using <media> resources where the
	| Name | termtimeout |		output is transported as RTP audio packets. However, <media>
	+-------------+-----------------------------------------------------+		resources are not sufficient for cases where DTMF tones are to be
	| Description | The terminating timeout to use when recognizing |		transported as DTMF RTP ([RFC2833]) or in event packages.
	| | DTMF input |
	| | |
	| Direction | input |
	| | |
	| Type | Time Designation |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid TimeDesignation value. |
	| Values | |
	| | |
	| Default | 0s |
	+-------------+-----------------------------------------------------+
	Table 22: termtimeout		A <dtmf> element has the following attributes:
	+-------------+-----------------------------------------------------+		digits: specifies the DTMF sequence to output. A valid value is a
	| Name | termchar |		DTMF string (see Section 8.3). The attribute is mandatory.
	+-------------+-----------------------------------------------------+
	| Description | The terminating DTMF character for DTMF input |
	| | recognition. This parameter is ignored if the |
	| | grammar parameter is specified. |
	| | |
	| Direction | input |
	| | |
	| Type | DTMFChar |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid DTMFChar value. To disable termination by |
	| Values | a conventional DTMF character, set the parameter to |
	| | an unconventional character like 'A'. |
	| | |
	| Default | # |
	+-------------+-----------------------------------------------------+
	Table 23: termchar		level: used to define the power level for which the DTMF tones will
			be generated. Values are expressed in dBm0. A valid value is an
			integer in the range of 0 to -96 (dBm0). Larger negative values
			express lower power levels. Note that values lower than -55 dBm0
			will be rejected by most receivers (TR-TSY-000181, ITU-T Q.24A).
			The attribute is optional. The default value is -6 (dBm0).
	+-------------+-----------------------------------------------------+		duration: specifies the duration for which each DTMF tone is
	| Name | maxdigits |		generated. A valid value is a time designation (see Section 8.7).
	+-------------+-----------------------------------------------------+		Implementations may round the value if they only support discrete
	| Description | The maximum number of digits to collect using an |		durations. The attribute is optional. The default value is
	| | internal digits (0-9 only) grammar. This parameter |		100ms.
	| | is ignored if the grammar parameter is specified. |
	| | |
	| Direction | input |
	| | |
	| Type | Positive Integer |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid positive integer value. |
	| Values | |
	| | |
	| Default | 5 |
	+-------------+-----------------------------------------------------+
	Table 24: maxdigits		interval: specifies the duration of a silence interval following
			each generated DTMF tone. A valid value is a time designation
			(see Section 8.7). Implementations may round the value if they
			only support discrete durations. The attribute is optional. The
			default value is 100ms.
	+-------------+-----------------------------------------------------+		The <dtmf> element has no children.
	| Name | grammar |
	+-------------+-----------------------------------------------------+
	| Description | A URI reference to a custom DTMF grammar. If this |
	| | parameter is specified, then the referenced DTMF |
	| | grammar is used instead of the internal digits |
	| | grammar (i.e. maxdigits and termchar are ignored |
	| | even if specified). Custom grammars permit the |
	| | full range of DTMF characters including '*' and '#' |
	| | to be specified for DTMF pattern matching. |
	| | |
	| Direction | input |
	| | |
	| Type | URI |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid URI value referencing a valid custom DTMF |
	| Values | grammar. |
	| | |
	| Default | none |
	+-------------+-----------------------------------------------------+
	Table 25: grammar		It is an error if a <dtmf> element cannot be processed successfully.
	[Editors note: The format of the custom DTMF grammar is not yet		5.3. <collect>
	defined. Possibilities include: [SRGS], [H.248.1], and [RFC4730].
	If more than one format is permitted, then an additional input		The <collect> element defines how DTMF input is collected.
	parameter "grammartype" would indicate the format used in the grammar
	parameter.]
	+-------------+-----------------------------------------------------+		The <collect> element has the following attributes:
	| Name | skipinterval |
	+-------------+-----------------------------------------------------+
	| Description | An indication of how far a media server should skip |
	| | backwards or forwards when the rewind (rwkey) of |
	| | fast forward key (ffkey) is pressed. |
	| | |
	| Direction | input |
	| | |
	| Type | Time Designation |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid time designation value. |
	| Values | |
	| | |
	| Default | 6s |
	+-------------+-----------------------------------------------------+
	Table 26: skipinterval		cleardigitbuffer: indicates whether the digit buffer is to be
			cleared. A valid value is a boolean (see Section 8.1). A value
			of true indicates that the digit buffer is to be cleared. A value
			of false indicates that the digit buffer is not to be cleared.
			The attribute is optional. The default value is true.
	+-------------+-----------------------------------------------------+		timeout: indicates the time to wait for user input. A valid value
	| Name | ffkey |		is a Time Designation (see Section 8.7). The attribute is
	+-------------+-----------------------------------------------------+		optional. The default value is 5s.
	| Description | Maps a DTMF key to a fast forward operation equal |
	| | to the value of 'skipinterval'. |
	| | |
	| Direction | input |
	| | |
	| Type | DTMFChar |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid DTMFChar value. |
	| Values | |
	| | |
	| Default | none |
	+-------------+-----------------------------------------------------+
	Table 27: ffkey		interdigittimeout: indicates inter-digit timeout value to use when
			recognizing DTMF input. A valid value is a Time Designation (see
			Section 8.7). The attribute is optional. The default value is
			2s.
	+-------------+-----------------------------------------------------+		termtimeout: indicates the terminating timeout value to use when
	| Name | rwkey |		recognizing DTMF input. A valid value is a Time Designation (see
	+-------------+-----------------------------------------------------+		Section 8.7). The attribute is optional. The default value is
	| Description | Maps a DTMF key to a rewind operation equal to the |		0s.
	| | value of 'skipinterval'. |
	| | |
	| Direction | input |
	| | |
	| Type | DTMFChar |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid DTMFChar value. |
	| Values | |
	| | |
	| Default | none |
	+-------------+-----------------------------------------------------+
	Table 28: rwkey		escapekey: specifies a DTMF key that indicates the DTMF collection
			is to be re-initiated. A valid value is a DTMF Character (see
			Section 8.2). The attribute is optional. There is no default
			value.
	+-------------+-----------------------------------------------------+		termchar: specifies a DTMF character for terminating DTMF input
	| Name | status |		collection using the internal grammar. A valid value is a DTMF
	+-------------+-----------------------------------------------------+		character (see Section 8.2). To disable termination by a
	| Description | A status code indicating success or failure of the |		conventional DTMF character, set the parameter to an
	| | promptandcollect dialog |		unconventional character like 'A'. The attribute is optional.
	| | |		The default value is '#'.
	| Direction | output |
	| | |
	| Type | Non-Negative Integer |
	| | |
	| Optional | No |
	| | |
	| Possible | 1 for success; otherwise an error code (600, 601, |
	| Values | 603). See Table 47 |
	| | |
	| Default | none |
	+-------------+-----------------------------------------------------+
	Table 29: status		maxdigits: The maximum number of digits to collect using an internal
			digits (0-9 only) grammar. A valid value is a positive integer
			(see Section 8.5). The attribute is optional. The default value
			is 5.
	+-------------+-----------------------------------------------------+		skipinterval: indicates how far a MS should skip backwards or
	| Name | reason |		forwards through prompt playback when the rewind (rwkey) of fast
	+-------------+-----------------------------------------------------+		forward key (ffkey) is pressed. A valid value is a Time
	| Description | A textual description providing a reason for the |		Designation (see Section 8.7). The attribute is optional. The
	| | status code; e.g. details on an error |		default value is 6s.
	| | |
	| Direction | output |
	| | |
	| Type | String |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid String value |
	| Values | |
	| | |
	| Default | Empty string |
	+-------------+-----------------------------------------------------+
	Table 30: reason		ffkey: maps a DTMF key to a fast forward operation equal to the
			value of 'skipinterval'. A valid value is a DTMF Character (see
			Section 8.2). The attribute is optional. There is no default
			value.
	+-------------+-----------------------------------------------------+		rwkey: maps a DTMF key to a rewind operation equal to the value of
	| Name | result |		'skipinterval'. A valid value is a DTMF Character (see
	+-------------+-----------------------------------------------------+		Section 8.2). The attribute is optional. There is no default
	| Description | The DTMF input collected from the user. |		value.
	| | |
	| Direction | output |
	| | |
	| Type | DTMFString |
	| | |
	| Optional | The parameter is mandatory if status is 1; |
	| | otherwise, optional. |
	| | |
	| Possible | A valid DTMFString (no spaces between characters). |
	| Values | |
	| | |
	| Default | Empty String |
	+-------------+-----------------------------------------------------+
	Table 31: result		pauseinterval: indicates how long a MS should pause prompt playback
			when the pausekey is pressed. A valid value is a Time Designation
			(see Section 8.7). The attribute is optional. The default value
			is 10s.
	In addition to the prompt extensions described in Table 14, the		pausekey: maps a DTMF key to a pause operation equal to the value of
	following parameters are under consideration for later versions:		'pauseinterval'. A valid value is a DTMF Character (see
			Section 8.2). The attribute is optional. There is no default
			value.
	+--------------------+----------------------------------------------+		resumekey: maps a DTMF key to a resume operation. A valid value is
	| Name | Description |		a DTMF Character (see Section 8.2). The attribute is optional.
	+--------------------+----------------------------------------------+		There is no default value.
	| nomatchprompts | prompts to play when input doesn't match the |
	| | DTMF grammar |
	| | |
	| noinputprompts | prompts to play when there is no user input |
	| | |
	| successprompts | prompts to play when user input is collected |
	| | |
	| failureprompts | prompts to play when no valid user input has |
	| | been collected after all iterations tried |
	| | |
	| escapechar | character which causes the dialog to restart |
	| | without incrementing the iterations counter |
	| | |
	| iterationcount | number of iterations (output) |
	| | |
	| promptplayedamount | duration of initial prompts played if prompt |
	| | interrupted (output) |
	+--------------------+----------------------------------------------+
	5.3. Prompt and Record		volumeinterval: indicates the increase or decrease in playback
			volume (relative to the current volume) when the volupkey or
			voldnkey is pressed. A valid value is a percentage (see
			Section 8.8). The attribute is optional. The default value is
			10%.
	A template dialog to prompt the user and record their audio (or other		volupkey: maps a DTMF key to a volume increase operation equal to
	media) input.		the value of 'volumeinterval'. A valid value is a DTMF Character
			(see Section 8.2). The attribute is optional. There is no
			default value.
	The dialog is invoked with the URI "promptandrecord".		voldnkey: maps a DTMF key to a volume decrease operation equal to
			the value of 'volumeinterval'.A valid value is a DTMF Character
			(see Section 8.2). The attribute is optional. There is no
			default value.
	The dialog execution model consists of:		It is an error if any VCR key (ffkey, rwkey, pausekey, resumekey,
			volupkey, voldnkey) is specified with the same value except that the
			pausekey and resumekey may have the same value.
	1. Playing prompts in the order specified until completion.		[Editors Note:IVR11 Do we need a speed VCR control as well? ]
	2. Recording input from the user in the mimetype format. Recording		[Editors Note:IVR12 it has been proposed that termchar should be
	is initiated if user input is received before timeout expires.		replaced by termkeys (DTMF string value) to allow termination by
	The recording is terminated by DTMF input, the maximum duration		multiple characters (e.g. '**'). An additional attribute would
	being exceeded or a final silence after recording, as specified		probably also be need to control interdigit timing within this
	in dtmfterm, maxtime and finalsilence parameters respectively.		string. Is this functionality required for this package?]
	Use of VAD (Voice Activity Detection) to initiate and terminate
	recording is controlled by vadinitial and vadfinal respectively.
	3. If recording is not initiated, steps 1 - 2 are repeated for the		The <collect> element has the following child elements:
	value of iterations.
	4. Returning status, reason and result parameters.		<grammar>: indicates a custom grammar format (see Section 5.3.1).
			The element is optional.
	The input and output parameter are summarized and defined below.		The custom grammar takes priority over the internal grammar. If a
			<grammar> element is specified, it MUST be used for DTMF collection.
	+--------------+-----------+---------------------------+------------+		DTMF collection has the following execution model upon
	| Name | Direction | Description | Definition |		initialization:
	+--------------+-----------+---------------------------+------------+
	| prompts | input | prompts to play | Table 34 |
	| | | | |
	| iterations | input | maximum attempts | Table 35 |
	| | | | |
	| timeout | input | timeout to wait for input | Table 36 |
	| | | | |
	| mimetype | input | mimetype of the recording | Table 37 |
	| | | | |
	| vadinitial | input | whether VAD is used to | Table 38 |
	| | | initiate recording | |
	| | | | |
	| vadfinal | input | whether VAD is used to | Table 39 |
	| | | terminate recording | |
	| | | | |
	| dtmf | input | recording terminated by | Table 40 |
	| | | DTMF | |
	| | | | |
	| maxtime | input | maximum duration of | Table 41 |
	| | | recording | |
	| | | | |
	| finalsilence | input | final silence to | Table 42 |
	| | | terminate recording | |
	| | | | |
	| status | output | status code | Table 43 |
	| | | | |
	| reason | output | reason for status | Table 44 |
	| | | | |
	| result | output | URI for recording | Table 45 |
	+--------------+-----------+---------------------------+------------+
	+-------------+-----------------------------------------------------+
	| Name | prompts |
	+-------------+-----------------------------------------------------+
	| Description | Initial prompts to play |
	| | |
	| Direction | input |
	| | |
	| Type | URIList |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid URIList |
	| Values | |
	| | |
	| Default | none |
	+-------------+-----------------------------------------------------+
	Table 34: prompts		1. If an error occurs during execution, then collection terminates
			and the error is reported in the status attribute (see
			Section 5.5) of the <dialogexit> event.
	+-------------+-----------------------------------------------------+		2. The digit buffer is cleared if the value of the cleardigitbuffer
	| Name | iterations |		attribute is true.
	+-------------+-----------------------------------------------------+
	| Description | Maximum number of times the promptandrecord dialog |
	| | is to be played |
	| | |
	| Direction | input |
	| | |
	| Type | Non-Negative Integer |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid non-negative integer. A value of 0 |
	| Values | indicates that the dialog is repeated until halted |
	| | by other means. |
	| | |
	| Default | 0 |
	+-------------+-----------------------------------------------------+
	Table 35: iterations		3. A timer with the duration of the value of the timeout attribute
			is activated. If the timer expires before DTMF input collection
			has completed, then collection execution terminates and the
			dialogexit result contains a <collectinfo> (see Section 5.5.2)
			with the termmode attribute set to noinput.
	+-------------+-----------------------------------------------------+		4. If DTMF input matches any VCR keys (for example the ffkey), then
	| Name | timeout |		the appropriate operation is applied to the active prompts; this
	+-------------+-----------------------------------------------------+		is a no-op if a prompt is not specified, or there are no active
	| Description | Indicates the time to wait for user input. |		prompts. If a seek operation (ffkey, rwkey) attempts to go
	| | |		beyond the beginning or end of the prompt queue, then it is
	| Direction | input |		automatically truncated to the prompt beginning or end
	| | |		respectively. If the pause operation attempts to pause output
	| Type | Time Designation |		when it is already paused, then the operation is ignored. If the
	| | |		resume operation attempts to resume when the prompts are not
	| Optional | Yes |		paused, then the operation is ignored. If a volume operations
	| | |		attempts to go beyond the minimum or maximum volume supported by
	| Possible | A valid TimeDesignation value. |		the platform, then the operation is ignored. DTMF input matching
	| Values | |		VCR controls is ignored for grammar matching.
	| | |
	| Default | 5s |
	+-------------+-----------------------------------------------------+
	Table 36: timeout		5. If DTMF input matches the value of the escapekey attribute, then
			the timer is canceled and DTMF collection is re-initialized.
	+-------------+-----------------------------------------------------+		6. Other DTMF input is matched to the grammar. Valid DTMF patterns
	| Name | mimetype |		are either a simple digit string where the maximum length is
	+-------------+-----------------------------------------------------+		determined by the maxdigits attribute and may be terminated by
	| Description | The media format of the resulting recording. |		the character in the termchar attribute; or a custom DTMF grammar
	| | |		specified with the <grammar> element. The attributes
	| Direction | input |		interdigittimeout and termtimeout control interdigit timeout and
	| | |		the terminating timeout respectively.
	| Type | mimetype |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid mimetype value. |
	| Values | |
	| | |
	| Default | None |
	+-------------+-----------------------------------------------------+
	Table 37: mimetype		7. If the input completely matches the grammar, the timer is
			canceled, collection execution terminates and the dialogexit
			result contains a <collectinfo> (see Section 5.5.2) with the
			termmode attribute set to match.
	+-------------+-----------------------------------------------------+		8. If the input does not match the grammar, the timer is canceled,
	| Name | vadinitial |		collection execution terminates and the dialogexit result
	+-------------+-----------------------------------------------------+		contains a <collectinfo> (see Section 5.5.2) with the termmode
	| Description | Control whether voice activity detection can be |		attribute set to nomatch.
	| | used to initiate recording |
	| | |
	| Direction | input |
	| | |
	| Type | Boolean |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid Boolean value. A value of true indicates |
	| Values | recording may be initiated using voice activity |
	| | detection. A value of false indicates that |
	| | recording must not be initiated using voice |
	| | activity detection. |
	| | |
	| Default | true |
	+-------------+-----------------------------------------------------+
	Table 38: vadinitial		5.3.1. <grammar>
	+-------------+-----------------------------------------------------+		The <grammar> element allows a custom grammar, inline or external, to
	| Name | vadfinal |		be specified. Custom grammars permit the full range of DTMF
	+-------------+-----------------------------------------------------+		characters including '*' and '#' to be specified for DTMF pattern
	| Description | Control whether voice activity detection can be |		matching.
	| | used to terminate recording |
	| | |
	| Direction | input |
	| | |
	| Type | Boolean |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid Boolean value. A value of true indicates |
	| Values | recording may be terminated using voice activity |
	| | detection. A value of false indicates that |
	| | recording must not be terminated using voice |
	| | activity detection. |
	| | |
	| Default | true |
	+-------------+-----------------------------------------------------+
	Table 39: vadfinal		The <grammar> element has the following attributes:
	+-------------+-----------------------------------------------------+		src: specifies the location of an external grammar. A valid value
	| Name | dtmfterm |		is a URI (see Section 8.9). The attribute is optional. There is
	+-------------+-----------------------------------------------------+		no default value.
	| Description | Indicates whether recording can be terminated by |
	| | DTMF input |
	| | |
	| Direction | input |
	| | |
	| Type | Boolean |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid Boolean value. A value of true indicates |
	| Values | that recording can be terminated by DTMF. A value |
	| | of false indicates that recording cannot be |
	| | terminated by DTMF. |
	| | |
	| Default | true |
	+-------------+-----------------------------------------------------+
	Table 40: dtmfterm		type: identifies the preferred type of the grammar document
			identified by the src attribute. A valid value is a MIME type
			(see Section 8.10). The attribute is optional. There is no
			default value.
	+-------------+-----------------------------------------------------+		The <grammar> element allows inline grammars to be specified. XML
	| Name | maxtime |		grammar formats MUST use a namespace other than the one used in this
	+-------------+-----------------------------------------------------+		specification. Non-XML grammar formats MAY use a CDATA section.
	| Description | The maximum duration of the recording |
	| | |
	| Direction | input |
	| | |
	| Type | Time Designation |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid TimeDesignation value. |
	| Values | |
	| | |
	| Default | 15s |
	+-------------+-----------------------------------------------------+
	Table 41: maxtime		The MS MUST support the [SRGS] grammar format and MS MAY support KPML
			([RFC4730]) or other grammar formats.
	+-------------+-----------------------------------------------------+		It is an error if a grammar format is specified which is not
	| Name | finalsilence |		supported by the MS.
	+-------------+-----------------------------------------------------+
	| Description | The interval of silence that indicates end of |
	| | speech. This parameter is ignored if vadfinal has |
	| | the value false. |
	| | |
	| Direction | input |
	| | |
	| Type | Time Designation |
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid TimeDesignation value. |
	| Values | |
	| | |
	| Default | 5s |
	+-------------+-----------------------------------------------------+
	Table 42: finalsilence		[Editors Note:IVR13 One drawback of using <grammar> with an inline
			custom grammar is that nested <grammar> elements are needed for SRGS:
			i.e. custom <grammar> element and inside that a <grammar> element in
			the SRGS namespace. The alternative would be (a) <grammar> element
			is only for external grammars, and (b) inline grammars are specified
			as children of <collect> (with suitable co-occurrence restrictions).
			Feedback is required to determined if the nesting is confusing or
			not. ]
	+-------------+-----------------------------------------------------+		Example: in CONTROL message from AS to MS, the following request
	| Name | status |		starts a dialog where DTMF collection is determined by an inline SRGS
	+-------------+-----------------------------------------------------+		grammar:
	| Description | A status code indicating success or failure of the |
	| | promptandrecord dialog |
	| | |
	| Direction | output |
	| | |
	| Type | Non-Negative Integer |
	| | |
	| Optional | No |
	| | |
	| Possible | 1 for success; otherwise an error code (600, 601, |
	| Values | 603). See Table 47 |
	| | |
	| Default | none |
	+-------------+-----------------------------------------------------+
	Table 43: status		<dialogstart connectionid="con1">
			<basicivr>
			<collect cleardigitbuffer="false" timeout="20s"
			interdigittimeout="1s" skipinterval="10s"
			rwkey="4" ffkey="6">
			<grammar>
			<grammar xmlns="http://www.w3.org/2001/06/grammar"
			version="1.0" mode="dtmf">
			<rule id="digit">
			<one-of>
			<item>0</item>
			<item>1</item>
			<item>2</item>
			<item>3</item>
			<item>4</item>
			<item>5</item>
			<item>6</item>
			<item>7</item>
			<item>8</item>
			<item>9</item>
			</one-of>
			</rule>
	+-------------+-----------------------------------------------------+		<rule id="pin" scope="public">
	| Name | reason |		<one-of>
	+-------------+-----------------------------------------------------+		<item>
	| Description | A textual description providing a reason for the |		<item repeat="4">
	| | status code; e.g. details on an error |		<ruleref uri="#digit"/>
	| | |		</item>#</item>
	| Direction | output |		<item>* 9</item>
	| | |		</one-of>
	| Type | String |		</rule>
	| | |
	| Optional | Yes |
	| | |
	| Possible | A valid String value |
	| Values | |
	| | |
	| Default | Empty string |
	+-------------+-----------------------------------------------------+
	Table 44: reason		</grammar>
			</grammar>
			</collect>
			</basicivr>
			</dialogstart>
	+-------------+-----------------------------------------------------+		The same grammar could also be referenced externally (and take
	| Name | result |		advantage of HTTP caching):
	+-------------+-----------------------------------------------------+
	| Description | A URI referencing the media recording |
	| | |
	| Direction | output |
	| | |
	| Type | URI |
	| | |
	| Optional | The parameter is mandatory if status is 1; |
	| | otherwise, optional. |
	| | |
	| Possible | A valid URI value |
	| Values | |
	| | |
	| Default | Empty string |
	+-------------+-----------------------------------------------------+
	Table 45: result		<dialogstart connectionid="con1">
			<basicivr>
			<collect cleardigitbuffer="false" timeout="20s"
			interdigittimeout="1s" skipinterval="10s"
			rwkey="4" ffkey="6">
			<grammar type=""application/srgs+xml"
			src="http://example.org/pin.grxml/>
			</collect>
			</basicivr>
			</dialogstart>
	In addition to the prompt extensions described in Table 14, the		See Section 6 and Section 7 for further examples.
	following additional parameters are under consideration for a later
	version.
	+--------------------+----------------------------------------------+		5.4. <record>
	| Name | Description |
	+--------------------+----------------------------------------------+
	| destination | URI to send recording using HTTP |
	| | |
	| beep | indicates whether a platform-specific beep |
	| | is used immediately prior to recording |
	| | |
	| noinputprompts | prompts to play when there is no user input |
	| | |
	| successprompts | prompts to play when recording is successful |
	| | |
	| failureprompts | prompts to play when no recording has been |
	| | made after all the iterations tried |
	| | |
	| duration | duration of the recording (output) |
	| | |
	| mimetype | mimetype of the recording (output) |
	| | |
	| iterationcount | number of iterations (output) |
	| | |
	| terminationmode | indication of why recording terminated: e.g. |
	| | dtmf, maxtime reached, externalevent or |
	| | finalsilence detected (output) |
	| | |
	| promptplayedamount | duration of initial prompts played if prompt |
	| | interrupted (output) |
	+--------------------+----------------------------------------------+
	5.4. Status Codes		The <record> element defines how media input is recorded.
	The following table describes the codes returned in the status output		The <record> element has the following attributes:
	parameter for template dialogs.
	+-----------+-------------------------------------------------------+		timeout: indicates the time to wait for user input. A valid value
	| status | description |		is a Time Designation (see Section 8.7). The attribute is
	+-----------+-------------------------------------------------------+		optional. The default value is 5s.
	| 0 | dialog terminated externally |
	| | |
	| 1 | success |
	| | |
	| 600 | unspecified error |
	| | |
	| 601 | invalid input parameter |
	| | |
	| 602 | no prompts defined (only playannouncement) |
	| | |
	| 603 | maximum iterations reached without valid input (not |
	| | playannouncement) |
	+-----------+-------------------------------------------------------+
	Table 47: status codes for all templates dialogs		type: specifies the type of the resulting recording format. The
			type value may include additional parameters for guiding
			recording; for example, [RFC4281] defines a 'codec' parameter for
			'bucket' media types like video/3gpp. A valid value is a MIME
			type (see Section 8.10). The attribute is optional. There is no
			default value (recording format is MS-specific).
	5.5. Type Definitions		dest: specifies the location of the resulting recording. The MS MAY
			stream the recorded data to the location as recording occurs. A
			valid value is a URI (see Section 8.9). The attribute is
			optional. If not specified, the MS MUST provide a recording
			location URI; this recording is available until the connection or
			conference associated with the dialog is destroyed.
	This section defines types referenced in template parameters.		vadinitial: Control whether voice activity detection can be used to
			initiate the recording operation. A valid value is a boolean (see
			Section 8.1). A value of true indicates recording may be
			initiated using voice activity detection. A value of false
			indicates that recording must not be initiated using voice
			activity detection. The attribute is optional. The default value
			is true.
	5.5.1. Boolean		vadfinal: Control whether voice activity detection can be used to
			terminate the recording operation. A valid value is a boolean
			(see Section 8.1). A value of true indicates recording may be
			terminated using voice activity detection. A value of false
			indicates that recording must not be terminated using voice
			activity detection. The attribute is optional. The default value
			is true.
	The value space of boolean is the set {true, false}.		dtmfterm: Indicates whether the recording operation is terminated by
			DTMF input. A valid value is a boolean (see Section 8.1). A
			value of true indicates that recording is terminated by DTMF
			input. A value of false indicates that recording is not
			terminated by DTMF input. The attribute is optional. The default
			value is true.
	5.5.2. DTMFChar		maxtime: indicates The maximum duration of the recording. A valid
			value is a Time Designation (see Section 8.7). The attribute is
			optional. The default value is 15s.
	A DTMF character. The value space is the set {0, 1, 2, 3, 4, 5, 6,		beep: indicates whether a 'beep' should be played immediately prior
	7, 8, 9, #, *, A, B, C, D}.		to initiation of the recording operation. A valid value is a
			boolean (see Section 8.1). The attribute is optional. The
			default value is false.
	5.5.3. DTMFString		finalsilence: indicates the interval of silence that indicates end
			of speech. This parameter is ignored if vadfinal (vadfinal) has
			the value false. A valid value is a Time Designation (see
			Section 8.7). The attribute is optional. The default value is
			5s.
	A String composed of one or more DTMFChars.		It is an error if a dest attribute is specified and the MS does not
			understand the URI protocol, cannot locate the URI, or cannot send
			recorded data successfully to the location.
	5.5.4. Non-Negative Integer		The <record> element has no child elements.
	The value space of non-negative integer is the infinite set		Recording has the following execution model upon initialization:
	{0,1,2,...}.
	5.5.5. Positive Integer		1. If an error occurs during execution, then recording terminates
			and the error is reported in the status attribute (see
			Section 5.5) of the <dialogexit> event.
	The value space of positive integer is the infinite set {1,2,...}.		2. If a beep attribute with the value of true is specified, then a
			beep tone is played.
	5.5.6. String		3. A timer with the duration of the value of the timeout attribute
			is activated. If the timer expires before the recording
			operation is completed, then recording execution terminates and
			the dialogexit result contains a <recordinfo> (see Section 5.5.3)
			with the termmode attribute set to noinput.
	A string in the character encoding associated with the XML element.		4. Initiation of the recording operation depends on the value of the
			vadinitial attribute. If vadinitial has the value false, then
			the recording operation is initiated immediately. Otherwise, the
			recording operations is initiated when voice activity is
			detected.
	5.5.7. Time Designation		5. When the recording operation is initiated, a timer is started for
			the value of the maxtime attribute. If the timer expires before
			the recording operation is complete, then recording execution
			terminates and the dialogexit result contains a <recordinfo> (see
			Section 5.5.3) with the termmode attribute set to maxtime.
	A time designation consists of a non-negative real number followed by		6. During the record operation user media input is recording in the
	a time unit identifier.		format specified by the value of the type attribute. If the dest
			attribute is specified, then recorded input is sent to that
			location. Otherwise, MS uses an internal location.
	The time unit identifiers are: "ms" (milliseconds) and "s" (seconds).		7. If the dtmfterm attribute has the value true and DTMF input is
			detected during the record operation, then the recording
			terminates and and the dialogexit result contains a <recordinfo>
			(see Section 5.5.3) with the termmode attribute set to dtmf.
	Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s".		8. If vadfinal attribute has the value true, then the recording
			operation is terminated when a period of silence, with the
			duration specified by the value of the finalsilence attribute, is
			detected. The dialogexit result contains a <recordinfo> (see
			Section 5.5.3) with the termmode attribute set to finalsilence.
	5.5.8. Percentage		5.5. Exit Information
	A percentage consists of a Positive Integer followed by "%".		When a basic ivr dialog exits, information is reported in a
			<dialogexit> notification event.
	Examples include: "100%", "500%" and "10%".		The content model of the <dialogexit> element defined in
			Section 4.3.2 is extended with the following child elements:
	5.5.9. URI		<promptinfo>: reports information about the prompt execution (see
			Section 5.5.1). The element is optional.
	Uniform Resource Indicator as defined in [RFC2396].		<collectinfo>: reports information about the collect execution (see
			Section 5.5.2). The element is optional.
	5.5.10. URIList		<recordinfo>: reports information about the record execution (see
			Section 5.5.3). The element is optional.
	A list of URIs.		5.5.1. <promptinfo>
	5.5.11. mimetype		The <promptinfo> element reports the information about prompt
			execution. It has the following attributes:
	A string formated as a IANA mimetype.		duration: indicates the cumulative duration of prompt playing in
			milliseconds. A valid value is a non-negative integer (see
			Section 8.4). The attribute is optional. There is no default
			value.
	6. AS-MS Interaction Examples		iterations: indicates the number of iterations played completely. A
			valid value is a positive integer (see Section 8.5). The
			attribute is optional. There is no default value.
			termmode: indicates how playback was terminated. Valid values are:
			'completed', 'maxduration' or 'bargein'. The attribute is
			mandatory.
			The <promptinfo> element has no child elements.
			5.5.2. <collectinfo>
			The <collectinfo> element reports the information about collect
			execution. It has the following attributes:
			dtmf: DTMF input collected from the user. A valid value is a DTMF
			string (see Section 8.3 with no space between characters. The
			attribute is optional. There is no default value.
			termmode: indicates how collection was terminated. Valid values
			are: 'match', 'noinput' or 'nomatch'. The attribute is mandatory.
			The <collectinfo> element has no child elements.
			5.5.3. <recordinfo>
			The <recordinfo> element reports the information about record
			execution. It has the following attributes:
			recording: references the location to which media is recorded. A
			valid value is a URI (see Section 8.9). The attribute is
			optional. There is no default value.
			type: indicates the format of the recording. A valid value is a
			MIME type (see Section 8.10). The attribute is optional. There
			is no default value.
			duration: indicates the duration of the recording in milliseconds.
			A valid value is a non-negative integer (see Section 8.4). The
			attribute is optional. There is no default value.
			size: indicates the size of the recording in bytes. A valid value
			is a non-negative integer (see Section 8.4). The attribute is
			optional. There is no default value.
			termmode: indicates how recording was terminated. Valid values are:
			'noinput', 'dtmf', 'maxtime', and 'finalsilence'. The attribute
			is mandatory.
			The <recordinfo> element has no child elements.
			6. AS-MS Dialog Interaction Examples
	The following example assume a control channel has been established		The following example assume a control channel has been established
	as described in the SIP Control Framework [SIPCF].		as described in the Media Control Channel Framework ([MCCF]).
	The XML messages are in angled brackets; the REPORT status is in		The XML messages are in angled brackets; the REPORT status is in
	round brackets. Other aspects of the protocol are omitted for		round brackets. Other aspects of the protocol are omitted for
	readability.		readability.
	6.1. Starting an IVR dialog		6.1. Starting an IVR dialog
	An IVR dialog is started successfully, and dialogexit notification		An IVR dialog is started successfully, and dialogexit notification
	<event> is sent from the MS to the AS when the dialog exits normally.		<event> is sent from the MS to the AS when the dialog exits normally.
	Application Server (AS) Media Server (MS)		Application Server (AS) Media Server (MS)
	| |		| |
	| (1) CONTROL: <dialogstart> |		| (1) CONTROL: <dialogstart> |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	| (2) 202 |		| (2) 202 |
	| <--------------------------------------- |		| <--------------------------------------- |
	| |		| |
	| (3) REPORT: (pending) |
	| <---------------------------------------- |
	| |
	| (4) 200 |
	| ----------------------------------------> |
	| |		| |
	| (5) REPORT: <response status="200"/> |		| (3) REPORT: <response status="200"/> |
	| (terminate) |		| (terminate) |
	| <---------------------------------------- |		| <---------------------------------------- |
	| |		| |
	| (6) 200 |		| (4) 200 |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	| (7) REPORT:<event name="dialogexit"/> |		| (5) CONTROL: <event ... /> |
	| (notify) |		| |
	| <---------------------------------------- |		| <---------------------------------------- |
	| |		| |
	| (8) 200 |		| (6) 200 |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	6.2. IVR dialog fails to start		6.2. IVR dialog fails to start
	An IVR dialog fails to start due to an unknown template.		An IVR dialog fails to start due to an unknown dialog type.
	Application Server (AS) Media Server (MS)		Application Server (AS) Media Server (MS)
	| |		| |
	| (1) CONTROL: <dialogstart> |		| (1) CONTROL: <dialogstart> |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	| (2) 202 |		| (2) 202 |
	| <--------------------------------------- |		| <--------------------------------------- |
	| |		| |
	| (3) REPORT: (pending) |		| (3) REPORT: <response status="409"/> |
	| <---------------------------------------- |
	| |
	| (4) 200 |
	| ----------------------------------------> |
	| |
	| (5) REPORT: <response status="409"/> |
	| (terminate) |		| (terminate) |
	| <---------------------------------------- |		| <---------------------------------------- |
	| |		| |
	| (6) 200 |		| (4) 200 |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	6.3. Preparing and starting an IVR dialog		6.3. Preparing and starting an IVR dialog
	An IVR dialog is prepared and started successfully, and then the		An IVR dialog is prepared and started successfully, and then the
	dialog exits normally.		dialog exits normally.
	Application Server (AS) Media Server (MS)		Application Server (AS) Media Server (MS)
	| |		| |
	| (1) CONTROL: <dialogprepare> |		| (1) CONTROL: <dialogprepare> |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	| (2) 202 |		| (2) 202 |
	| <--------------------------------------- |		| <--------------------------------------- |
	| |		| |
	| (3) REPORT: (pending) |		| (3) REPORT: <response status="200"/> |
	| <---------------------------------------- |
	| |
	| (4) 200 |
	| ----------------------------------------> |
	| |
	| (5) REPORT: <response status="200"/> |
	| (terminate) |		| (terminate) |
	| <---------------------------------------- |		| <---------------------------------------- |
	| |		| |
	| (6) 200 |		| (4) 200 |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	| (7) CONTROL: <dialogstart> |		| (5) CONTROL: <dialogstart> |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	| (8) 202 |		| (6) 202 |
	| <--------------------------------------- |		| <--------------------------------------- |
	| |		| |
	| (9) REPORT: (pending) |		| (7) REPORT: <response status="200"/> |
	| <---------------------------------------- |
	| |
	| (10) 200 |
	| ---------------------------------------> |
	| |
	| (11) REPORT: <response status="200"/> |
	| (terminate) |		| (terminate) |
	| <---------------------------------------- |		| <---------------------------------------- |
	| |		| |
	| (12) 200 |		| (8) 200 |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	| (13) REPORT:<event name="dialogexit"/>|		| (9) CONTROL: <event .../> |
	| (notify) |
	| <---------------------------------------- |		| <---------------------------------------- |
	| |		| |
	| (14) 200 |		| (10) 200 |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	6.4. Terminating a dialog immediately		6.4. Terminating a dialog
	An IVR dialog is started successfully, and then terminated		An IVR dialog is started successfully, and then terminated by the AS.
	immediately by the AS. No dialog notification <event>s are sent back		The dialogexit event is sent by to the AS when the dialog exits.
	to the AS.
	Application Server (AS) Media Server (MS)		Application Server (AS) Media Server (MS)
	| |		| |
	| (1) CONTROL: <dialogstart> |		| (1) CONTROL: <dialogstart> |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	| (2) 202 |		| (2) 202 |
	| <--------------------------------------- |		| <--------------------------------------- |
	| |		| |
	| (3) REPORT: (pending) |		| (3) REPORT: <response status="200"/> |
	| <---------------------------------------- |
	| |
	| (4) 200 |
	| ----------------------------------------> |
	| |
	| (5) REPORT: <response status="200"/> |
	| (terminate) |		| (terminate) |
	| <---------------------------------------- |		| <---------------------------------------- |
	| |		| |
	| (6) 200 |
	| ----------------------------------------> |
	| |
	| (7) CONTROL: <dialogterminate> |
	| ----------------------------------------> |
	| |
	| (8) 200: <response status="200"/> |
	| <---------------------------------------- |
	| |
	Note that in (8) the response to the <dialogterminate/> request is
	carried on a framework 200 response.
	6.5. Terminating a dialog non-immediately
	An IVR dialog is started successfully, and then terminated non-
	immediately by the AS, allowing the MS to send a dialogexit
	notification <event> with information collected during the dialog.
	Application Server (AS) Media Server (MS)
	| |
	| (1) CONTROL: <dialogstart> |
	| ----------------------------------------> |
	| |
	| (2) 202 |
	| <--------------------------------------- |
	| |
	| (3) REPORT: (pending) |
	| <---------------------------------------- |
	| |
	| (4) 200 |		| (4) 200 |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	| (5) REPORT: <response status="200"/> |		| (5) CONTROL: <dialogterminate> |
	| (terminate) |
	| <---------------------------------------- |
	| |
	| (6) 200 |
	| ----------------------------------------> |
	| |
	| (7) CONTROL: <dialogterminate> |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	| (8) 200: <response status="200"/> |		| (6) 200: <response status="200"/> |
	| <---------------------------------------- |		| <---------------------------------------- |
	| |		| |
	| (9) REPORT:<event name="dialogexit"/> |		| (7) CONTROL: <event .../> |
	| (notify) |
	| <---------------------------------------- |		| <---------------------------------------- |
	| |		| |
	| (10) 200 |		| (8) 200 |
	| ----------------------------------------> |		| ----------------------------------------> |
	| |		| |
	Note that in (8) the response to the <dialogterminate/> request is		Note that in (6) the <response> payload to the <dialogterminate/>
	carried on a framework 200 response.		request is carried on a framework 200 response since it could
			complete the requested operation before the transaction timeout.
	7. Template Dialog Examples		7. Basic IVR Dialog Examples
	The following examples show how playannouncement, promptandcollect		The following examples show how <basicivr> is used with
	and promptandrecord template dialogs are used with <dialogprepare>,		<dialogprepare>, <dialogstart> and <event> elements to play prompts,
	<dialogstart> and <event> elements.		collect DTMF input and record user input.
	The examples do not specify all messages between the AS and MS.		The examples do not specify all messages between the AS and MS.
	7.1. playannouncement		7.1. Playing announcements
	This example prepares an announcement composed of two prompts.		This example prepares an announcement composed of two prompts.
	<dialogprepare src="basicivr:playannouncement">		<dialogprepare>
	<data>		<basicivr>
	<item name="prompts"		<prompt>
	value="http://www.example.com/media/Number_09.wav		<media src="http://www.example.com/media/Number_09.wav"/>
	http://www.example.com/media/Number_11.wav"/>		<media src="http://www.example.com/media/Number_11.wav"/>
	<item name="iterations" value="2"/>		</prompt>
	</data>		</basicivr>
	</dialogprepare>		</dialogprepare>
	If the dialog is prepared successfully, a dialogprepared message is		If the dialog is prepared successfully, a <response> with status 200
	returned:		is returned:
	<response status="200" dialogid="vxi78"/>		<response status="200" dialogid="vxi78"/>
	The prepared dialog is then started on a conference playing the		The prepared dialog is then started on a conference playing the
	prompts twice:		prompts twice:
	<dialogstart prepareddialogid="vxi78" conf-id="conference11"/>		<dialogstart prepareddialogid="vxi78" conferenceid="conference11"/>
	In the case of a successful dialog, the output is provided in		In the case of a successful dialog, the output is provided in
	<event>; for example		<event>; for example
	<event name="dialogexit" dialogid="vxi78">		<event dialogid="vxi78">
	<data>		<dialogexit status="1">
	<item name="status" value="1"/>		<promptinfo termmode="completed"/>
	</data>		</dialogexit>
	</event>
	In this example, the dialog is started on a sip dialog connection,
	but no <data> is specified:
	<dialogstart src="basicivr:playannouncement"
	connection-id="7HDY839~HJKSkyHS~HUwkuh7ns"/>
	and an error message is returned:
	<event name="dialogexit" dialogid="vxi79">
	<data>
	<item name="status" value="602"/>
	<item name="reason" value="prompts not defined"/>
	</data>
	</event>		</event>
	7.2. promptandcollect		7.2. Prompt and collect
	This example plays no prompts and just waits for input from the user:		This example plays no prompts and just waits for DTMF input from the
			user:
	<dialogstart src="basicivr:promptandcollect"		<dialogstart connectionid="7HDY839~HJKSkyHS~HUwkuh7ns">
	connection-id="7HDY839~HJKSkyHS~HUwkuh7ns"/>		<basicivr>
			<collect/>
			</basicivr>
			</dialogstart>
	If the dialog is successful, then "dialogexit" <event> contains the		If the dialog is successful, then "dialogexit" <event> contains the
	dtmf collected in its result parameter:		dtmf collected in its result parameter:
	<event name="dialogexit" dialogid="vxi80">		<event dialogid="vxi80">
	<data>		<dialogexit status="1">
	<item name="status" value="1"/>		<collectinfo dtmf="12345" termmode="match"/>
	<item name="result" value="12345"/>		</dialogexit>
	</data>
	</event>		</event>
	In this example, a prompt is played and then we wait for 3 hours for		In this example, a prompt is played and then we wait for 3 hours for
	a two digit sequence:		a two digit sequence:
	<dialogstart src="basicivr:promptandcollect"		<dialogstart connectionid="7HDY839~HJKSkyHS~HUwkuh7ns">
	connection-id="7HDY839~HJKSkyHS~HUwkuh7ns">		<basicivr>
	<data>		<prompt>
	<item name="prompts" value="http://www.example.com/prompt1.wav"/>		<media src="http://www.example.com/prompt1.wav"/>
	<item name="timeout" value="1080s"/>		</prompt>
	<item name="maxdigits" value="2"/>		<collect timeout="1080s" maxdigits="2"/>
	<item name="iterations" value="1"/>		</basicivr>
	</data>
	</dialogstart>		</dialogstart>
	If no user input is collected within 3 hours, then following would be		If no user input is collected within 3 hours, then following would be
	returned:		returned:
	<event name="dialogexit" dialogid="vxi81">		<event dialogid="vxi81">
	<data>		<dialogexit status="1" >
	<item name="status" value="603"/>		<collectinfo termmode="noinput"/>
	</data>		</dialogexit>
	</event>		</event>
	And finally in this example, one of the input parameters is invalid:		And finally in this example, one of the input parameters is invalid:
	<dialogstart src="basicivr:promptandcollect"		<dialogstart connectionid="7HDY839~HJKSkyHS~HUwkuh7ns">
	connection-id="7HDY839~HJKSkyHS~HUwkuh7ns">		<basicivr>
	<data>		<prompt iterations="two">
	<item name="prompts" value="http://www.example.com/prompt1.wav"/>		<media src="http://www.example.com/prompt1.wav"/>
	<item name="iterations" value="two"/>		</prompt>
	<item name="cleardigitbuffer" value="true"/>		<collect cleardigitbuffer="true" bargein="true"
	<item name="bargein" value="true"/>		timeout="4s" interdigittimeout="2s"
	<item name="timeout" value="4s"/>		termtimeout="0s maxdigits="2"/>
	<item name="interdigittimeout" value="2s"/>		</basicivr>
	<item name="termtimeout" value="0s"/>
	<item name="maxdigits" value="2"/>
	</data>
	</dialogstart>		</dialogstart>
	The error is reported in a dialogexit <event>:		The error is reported in a the response:
	<event name="dialogexit" dialogid="vxi82">
	<data>
	<item name="status" value="601"/>
	<item name="reason" value="iterations invalid: two"/>
	</data>
	</event>		<response status="411" dialogid="vxi82"
			reason="iterations value invalid: two"/>
	7.3. promptandrecord		7.3. Prompt and record
	In this example, the user is prompted, then their input is recorded		In this example, the user is prompted, then their input is recorded
	for a maximum of 30 seconds.		for a maximum of 30 seconds.
	<dialogstart src="basicivr:promptandrecord"		<dialogstart connectionid="7HDY839~HJKSkyHS~HUwkuh7ns">
	connection-id="7HDY839~HJKSkyHS~HUwkuh7ns">		<basicivr>
	<data>		<prompt>
	<item name="prompts"		<media src="http://www.example.com/media/sayname.wav"/>
	value="http://www.example.com/media/sayname.wav		</prompt>
	http://www.example.com/media/beep.wav"/>		<record dtmfterm="false" maxtime="30s" beep="true"/>
	<item name="dtmfterm" value="false"/>		</basicivr>
	<item name="maxtime" value="30s"/>
	</data>
	</dialogstart>		</dialogstart>
	If successful, the following is returned in a dialogexit <event>:		If successful, the following is returned in a dialogexit <event>:
	<event name="dialogexit" dialogid="vxi83">		<event dialogid="vxi83">
	<data>		<dialogexit status="1">
	<item name="status" value="1"/>		<recordinfo recording="http://www.example.com/recording1.wav"
	<item name="result" value="http://www.example.com/recording1.wav"/>		termmode="dtmf"/>
	</data>		</dialogexit>
	</event>		</event>
	8. Formal Syntax		8. Type Definitions
	[Editors Note: A later version of the XML schema will provide more		This section defines types referenced in attribute definitions.
	constraints as expressed in the textual definitions; for example,
	single occurrence of <data> elements, co-occurence on attributes,
	etc.]
	[Editors Note: The schema in the 05 version does not allign with		8.1. Boolean
	changes made since the 04 version. These changes will occur in the
	next version of the document.]
	<?xml version="1.0" encoding="UTF-8"?>		The value space of boolean is the set {true, false}.
	<xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-ivr-basic"
	xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
	elementFormDefault="qualified"
	xmlns="urn:ietf:params:xml:ns:msc-ivr-basic"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<xsd:annotation>		8.2. DTMFChar
	<xsd:documentation>Basic IVR 1.0 schema (20061019)</xsd:documentation>
	</xsd:annotation>
	<xsd:import		A DTMF character. The value space is the set {0, 1, 2, 3, 4, 5, 6,
	namespace="urn:ietf:params:xml:ns:control:framework-attributes"		7, 8, 9, #, *, A, B, C, D}.
	schemaLocation="framework.xsd"/>
	<xsd:element name="dialogprepare">		8.3. DTMFString
	<xsd:complexType>
	<xsd:choice minOccurs="0" maxOccurs="unbounded">		A String composed of one or more DTMFChars.
	<xsd:element ref="data"/>
	<xsd:element ref="subscribe"/>		8.4. Non-Negative Integer
	<xsd:any namespace="##other" processContents="strict"/>
			The value space of non-negative integer is the infinite set
			{0,1,2,...}.
			8.5. Positive Integer
			The value space of positive integer is the infinite set {1,2,...}.
			8.6. String
			A string in the character encoding associated with the XML element.
			8.7. Time Designation
			A time designation consists of a non-negative real number followed by
			a time unit identifier.
			The time unit identifiers are: "ms" (milliseconds) and "s" (seconds).
			Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s".
			8.8. Percentage
			A percentage consists of a Positive Integer followed by "%".
			Examples include: "100%", "500%" and "10%".
			8.9. URI
			Uniform Resource Indicator as defined in [RFC3986].
			8.10. mimetype
			A string formated as a IANA mimetype.
			8.11. Language Identifier
			A language identifier labels information content as being of a
			particular human language variant. Following the XML specification
			for language identification [XML], a legal language identifier is
			identified by a RFC3066 ([RFC3066]) code where the language code is
			required and a country code or other subtag identifier is optional.
			9. Formal Syntax
			This package defines two XML schema:
			1. msc-ivr-common.xsd: defines the common datatypes, attributes and
			dialog management elements. It does not use a namespace.
			2. msc-ivr-basic.xsd: defines the basic ivr elements and uses schema
			redefinition to extend dialog management elements. All elements
			in this schema, including the imported dialog management
			elements, are in the urn:ietf:params:xml:ns:msc-ivr-basic
			namespace.
			The schema are dependent upon the schema (framework.xsd) defined in
			Section 16.1 of the Control Framework [MCCF]
			Both schema are fully extensible: attributes and elements from other
			namespaces are permitted, and extensions can be specified using the
			<redefine> mechanism.
			The schema of extension control packages MUST imported one of these
			schema and specify how they extend the elements. Extensions to the
			<basicivr> element use msc-ivr-basic.xsd. Extensions to the dialog
			management elements use msc-ivr-common.xsd.
			[Editors Note:IVR14 A later version of this document may provide a
			RelaxNG schema which provides better support for co-occurrence
			constraints than XML schema. Does anyone want/need such a schema?]
			9.1. msc-ivr-common.xsd
			<?xml version="1.0" encoding="UTF-8"?>
			<xsd:schema elementFormDefault="qualified"
			xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
			xmlns:xsd="http://www.w3.org/2001/XMLSchema">
			<xsd:annotation>
			<xsd:documentation>
			IETF MediaCtrl IVR Common 1.0 (20080225)
			This is the common core schema of the IVR packages defined
			as part of the Basic IVR Control Package. It specifies common
			datatypes, attributes and dialog control element definitions.
			</xsd:documentation>
			</xsd:annotation>
			<!--
			###################################################
			SCHEMA IMPORTS
			###################################################
			-->
			<xsd:import
			namespace="urn:ietf:params:xml:ns:control:framework-attributes"
			schemaLocation="framework.xsd">
			<xsd:annotation>
			<xsd:documentation>
			This import brings in the framework attributes for conferenceid
			and connectionid.
			</xsd:documentation>
			</xsd:annotation>
			</xsd:import>
			<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
			schemaLocation="http://www.w3.org/2001/xml.xsd">
			<xsd:annotation>
			<xsd:documentation>
			This import brings in the XML attributes for xml:base, xml:lang,
			etc
			See http://www.w3.org/2001/xml.xsd for latest version
			</xsd:documentation>
			</xsd:annotation>
			</xsd:import>
			<!--
			#####################################################
			COMMON ELEMENTS
			#####################################################
			-->
			<!-- dialogprepare -->
			<xsd:attributeGroup name="msc.ivr.common.dialogprepare.attlist">
			<xsd:attribute name="src" type="xsd:anyURI" />
			<xsd:attribute name="type" type="mime.datatype" />
			<xsd:attribute name="dialogid" type="dialogid.datatype" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.common.dialogprepare.mix">
			<xsd:choice>
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
	</xsd:choice>		</xsd:choice>
	<xsd:attribute name="src" type="URI.datatype" use="required"/>		</xsd:group>
	<xsd:attribute name="dialogid" type="dialogid.datatype"/>		<xsd:group name="msc.ivr.common.dialogprepare.content">
	<xsd:anyAttribute namespace="##other" processContents="strict"/>		<xsd:sequence>
			<xsd:group ref="msc.ivr.common.dialogprepare.mix" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.common.dialogprepare.type">
			<xsd:group ref="msc.ivr.common.dialogprepare.content" />
			<xsd:attributeGroup ref="msc.ivr.common.dialogprepare.attlist" />
			</xsd:complexType>
			<xsd:element name="dialogprepare"
			type="msc.ivr.common.dialogprepare.type" />
			<!-- dialogstart -->
			<xsd:attributeGroup name="msc.ivr.common.dialogstart.attlist">
			<xsd:attribute name="src" type="xsd:anyURI" />
			<xsd:attribute name="type" type="mime.datatype" />
			<xsd:attribute name="dialogid" type="dialogid.datatype" />
			<xsd:attribute name="prepareddialogid" type="dialogid.datatype" />
			<xsd:attributeGroup ref="fw:framework-attributes" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.common.dialogstart.mix">
			<xsd:choice>
			<xsd:element ref="stream" minOccurs="0" maxOccurs="unbounded" />
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:choice>
			</xsd:group>
			<xsd:group name="msc.ivr.common.dialogstart.content">
			<xsd:sequence>
			<xsd:group ref="msc.ivr.common.dialogstart.mix" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.common.dialogstart.type">
			<xsd:group ref="msc.ivr.common.dialogstart.content" />
			<xsd:attributeGroup ref="msc.ivr.common.dialogstart.attlist" />
			</xsd:complexType>
			<xsd:element name="dialogstart"
			type="msc.ivr.common.dialogstart.type" />
			<!-- dialogterminate -->
			<xsd:attributeGroup name="msc.ivr.common.dialogterminate.attlist">
			<xsd:attribute name="dialogid" type="dialogid.datatype"
			use="required" />
			<xsd:attribute name="immediate" type="boolean.datatype"
			default="false" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.common.dialogterminate.mix">
			<xsd:choice>
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:choice>
			</xsd:group>
			<xsd:group name="msc.ivr.common.dialogterminate.content">
			<xsd:sequence>
			<xsd:group ref="msc.ivr.common.dialogterminate.mix" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.common.dialogterminate.type">
			<xsd:group ref="msc.ivr.common.dialogterminate.content" />
			<xsd:attributeGroup ref="msc.ivr.common.dialogterminate.attlist" />
	</xsd:complexType>		</xsd:complexType>
			<xsd:element name="dialogterminate"
			type="msc.ivr.common.dialogterminate.type" />
			<!-- response -->
			<xsd:attributeGroup name="msc.ivr.common.response.attlist">
			<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:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.common.response.mix">
			<xsd:choice>
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:choice>
			</xsd:group>
			<xsd:group name="msc.ivr.common.response.content">
			<xsd:sequence>
			<xsd:group ref="msc.ivr.common.response.mix" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.common.response.type">
			<xsd:group ref="msc.ivr.common.response.content" />
			<xsd:attributeGroup ref="msc.ivr.common.response.attlist" />
			</xsd:complexType>
			<xsd:element name="response" type="msc.ivr.common.response.type" />
			<!-- event -->
			<xsd:attributeGroup name="msc.ivr.common.event.attlist">
			<xsd:attribute name="dialogid" type="dialogid.datatype"
			use="required" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.common.event.mix">
			<xsd:choice>
			<xsd:element ref="dialogexit" />
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:choice>
			</xsd:group>
			<xsd:group name="msc.ivr.common.event.content">
			<xsd:choice>
			<xsd:group ref="msc.ivr.common.event.mix" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:choice>
			</xsd:group>
			<xsd:complexType name="msc.ivr.common.event.type">
			<xsd:group ref="msc.ivr.common.event.content" />
			<xsd:attributeGroup ref="msc.ivr.common.event.attlist" />
			</xsd:complexType>
			<xsd:element name="event" type="msc.ivr.common.event.type" />
			<!-- dialogexit-->
			<xsd:attributeGroup name="msc.ivr.common.dialogexit.attlist">
			<xsd:attribute name="status" type="xsd:positiveInteger"
			use="required" />
			<xsd:attribute name="reason" type="xsd:string" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.common.dialogexit.mix">
			<xsd:choice>
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:choice>
			</xsd:group>
			<xsd:group name="msc.ivr.common.dialogexit.content">
			<xsd:sequence>
			<xsd:group ref="msc.ivr.common.dialogexit.mix"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.common.dialogexit.type">
			<xsd:group ref="msc.ivr.common.dialogexit.content" />
			<xsd:attributeGroup ref="msc.ivr.common.dialogexit.attlist" />
			</xsd:complexType>
			<xsd:element name="dialogexit"
			type="msc.ivr.common.dialogexit.type" />
			<!-- stream -->
			<xsd:attributeGroup name="msc.ivr.common.stream.attlist">
			<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:attributeGroup ref="msc.common.attribs" />
	</xsd:element>		</xsd:attributeGroup>
			<xsd:group name="msc.ivr.common.stream.mix">
			<xsd:choice>
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:choice>
			</xsd:group>
			<xsd:group name="msc.ivr.common.stream.content">
			<xsd:sequence>
			<xsd:group ref="msc.ivr.common.stream.mix" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.common.stream.type">
			<xsd:group ref="msc.ivr.common.stream.content" />
			<xsd:attributeGroup ref="msc.ivr.common.stream.attlist" />
			</xsd:complexType>
			<xsd:element name="stream" type="msc.ivr.common.stream.type" />
			<!--
			#####################################################
	<xsd:element name="dialogstart">		COMMON ATTRIBUTES AND ELEMENTS
	<xsd:complexType>
	<xsd:choice minOccurs="0" maxOccurs="unbounded">		#####################################################
	<xsd:element ref="stream"/>		-->
	<xsd:element ref="data"/>		<xsd:attributeGroup name="msc.common.attribs">
	<xsd:element ref="subscribe"/>		<xsd:annotation>
	<xsd:any namespace="##other" processContents="strict"/>		<xsd:documentation>
			group allowing attributes from other namespaces
			</xsd:documentation>
			</xsd:annotation>
			<xsd:anyAttribute namespace="##other" processContents="lax" />
			</xsd:attributeGroup>
			<xsd:group name="msc.common.content">
			<xsd:annotation>
			<xsd:documentation>
			group allowing elements from other namespaces
			</xsd:documentation>
			</xsd:annotation>
			<xsd:sequence>
			<xsd:any namespace="##other" processContents="lax" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<!--
			####################################################
			COMMON DATATYPES
			####################################################
			-->
			<xsd:simpleType name="mime.datatype">
			<xsd:restriction base="xsd:string" />
			</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="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>
			<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 name="timedesignation.datatype">
			<xsd:annotation>
			<xsd:documentation>
			Time designation following Time in CSS2
			</xsd:documentation>
			</xsd:annotation>
			<xsd:restriction base="xsd:string">
			<xsd:pattern value="(\+)?([0-9]*\.)?[0-9]+(ms|s)" />
			</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType name="dtmfchar.datatype">
			<xsd:annotation>
			<xsd:documentation>DTMF character [0-9#*A-D]</xsd:documentation>
			</xsd:annotation>
			<xsd:restriction base="xsd:string">
			<xsd:pattern value="[0-9#*A-D]" />
			</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType name="dtmfstring.datatype">
			<xsd:annotation>
			<xsd:documentation>DTMF sequence [0-9#*A-D]</xsd:documentation>
			</xsd:annotation>
			<xsd:restriction base="xsd:string">
			<xsd:pattern value="([0-9#*A-D])+" />
			</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType name="percentage.datatype">
			<xsd:annotation>
			<xsd:documentation>
			whole integer followed by '%'
			</xsd:documentation>
			</xsd:annotation>
			<xsd:restriction base="xsd:string">
			<xsd:pattern value="([0-9])+%" />
			</xsd:restriction>
			</xsd:simpleType>
			</xsd:schema>
			9.2. msc-ivr-basic.xsd
			<?xml version="1.0" encoding="UTF-8"?>
			<xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-ivr-basic"
			elementFormDefault="qualified"
			xmlns="urn:ietf:params:xml:ns:msc-ivr-basic"
			xmlns:xsd="http://www.w3.org/2001/XMLSchema">
			<xsd:annotation>
			<xsd:documentation>
			IETF MediaCtrl IVR Basic 1.0 (20080225)
			This is the schema of the Basic IVR control package. It imports
			the msc-ivr-common schema (dialogprepare, etc) and specifies
			basicivr, prompt, collect and record elements.
			The schema namespace is urn:ietf:params:xml:ns:msc-ivr-basic
			</xsd:documentation>
			</xsd:annotation>
			<!--
			#############################################################
			SCHEMA IMPORTS
			#############################################################
			-->
			<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
			schemaLocation="http://www.w3.org/2001/xml.xsd">
			<xsd:annotation>
			<xsd:documentation>
			This import brings in the XML attributes for xml:base, xml:lang,
			etc
			See http://www.w3.org/2001/xml.xsd for latest version
			</xsd:documentation>
			</xsd:annotation>
			</xsd:import>
			<xsd:redefine schemaLocation="msc-ivr-common.xsd">
			<xsd:annotation>
			<xsd:documentation>
			This import brings in the IVR common package and redefines some
			elements as follows: [1] adds basicivr element to dialogprepare
			[2] adds basicivr element to dialogstart [3] adds promptinfo,
			collectinfo and recordinfo as children of dialogexit element
			</xsd:documentation>
			</xsd:annotation>
			<xsd:group name="msc.ivr.common.dialogprepare.mix">
			<xsd:choice>
			<xsd:group ref="msc.ivr.common.dialogprepare.mix" />
			<xsd:element ref="basicivr" minOccurs="0" maxOccurs="1" />
			</xsd:choice>
			</xsd:group>
			<xsd:group name="msc.ivr.common.dialogstart.mix">
			<xsd:choice>
			<xsd:group ref="msc.ivr.common.dialogstart.mix" />
			<xsd:element ref="basicivr" minOccurs="0" maxOccurs="1" />
			</xsd:choice>
			</xsd:group>
			<xsd:group name="msc.ivr.common.dialogexit.mix">
			<xsd:choice>
			<xsd:group ref="msc.ivr.common.dialogexit.mix" />
			<xsd:element ref="promptinfo" minOccurs="0" maxOccurs="1" />
			<xsd:element ref="collectinfo" minOccurs="0" maxOccurs="1" />
			<xsd:element ref="recordinfo" minOccurs="0" maxOccurs="1" />
			</xsd:choice>
			</xsd:group>
			</xsd:redefine>
			<!--
			#############################################################
			BASIC IVR ELEMENTS
			#############################################################
			-->
			<!-- basicivr -->
			<xsd:attributeGroup name="msc.ivr.basicivr.basicivr.attlist">
			<xsd:attribute name="version" type="xsd:string" default="1.0" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.basicivr.basicivr.mix">
			<xsd:choice>
			<xsd:element ref="prompt" minOccurs="0" maxOccurs="1" />
			<xsd:element ref="collect" minOccurs="0" maxOccurs="1" />
			<xsd:element ref="record" minOccurs="0" maxOccurs="1" />
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
	</xsd:choice>		</xsd:choice>
	<xsd:attribute name="src" type="URI.datatype"/>		</xsd:group>
	<xsd:attribute name="dialogid" type="dialogid.datatype"/>
	<xsd:attribute name="prepareddialogid" type="dialogid.datatype"/>		<xsd:group name="msc.ivr.basicivr.basicivr.content">
	<xsd:attributeGroup ref="fw:framework-attributes"/>		<xsd:sequence>
	<xsd:anyAttribute namespace="##other" processContents="strict"/>		<xsd:group ref="msc.ivr.basicivr.basicivr.mix" minOccurs="1"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.basicivr.basicivr.type">
			<xsd:group ref="msc.ivr.basicivr.basicivr.content" />
			<xsd:attributeGroup ref="msc.ivr.basicivr.basicivr.attlist" />
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>
	<xsd:element name="dialogterminate">		<xsd:element name="basicivr" type="msc.ivr.basicivr.basicivr.type" />
	<xsd:complexType>		<!-- prompt -->
	<xsd:choice minOccurs="0" maxOccurs="unbounded">
	<xsd:any namespace="##other" processContents="strict"/>		<xsd:attributeGroup name="msc.ivr.basicivr.prompt.attlist">
			<xsd:attribute ref="xml:base" />
			<xsd:attribute name="bargein" type="boolean.datatype"
			default="true" />
			<xsd:attribute name="iterations" type="xsd:nonNegativeInteger"
			default="1" />
			<xsd:attribute name="duration" type="timedesignation.datatype" />
			<xsd:attribute name="volume" type="percentage.datatype"
			default="100%" />
			<xsd:attribute name="offset" type="timedesignation.datatype"
			default="0s" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.basicivr.prompt.mix">
			<xsd:choice>
			<xsd:element ref="media" minOccurs="0" maxOccurs="unbounded" />
			<xsd:element ref="variable" minOccurs="0" maxOccurs="unbounded" />
			<xsd:element ref="dtmf" minOccurs="0" maxOccurs="unbounded" />
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
	</xsd:choice>		</xsd:choice>
	<xsd:attribute name="dialogid" type="dialogid.datatype"		</xsd:group>
	use="required"/>
	<xsd:attribute name="immediate" type="boolean.datatype"		<xsd:group name="msc.ivr.basicivr.prompt.content">
	default="false"/>		<xsd:choice>
	<xsd:anyAttribute namespace="##other" processContents="strict"/>		<xsd:group ref="msc.ivr.basicivr.prompt.mix"
			maxOccurs="unbounded" />
			</xsd:choice>
			</xsd:group>
			<xsd:complexType name="msc.ivr.basicivr.prompt.type">
			<xsd:group ref="msc.ivr.basicivr.prompt.content" />
			<xsd:attributeGroup ref="msc.ivr.basicivr.prompt.attlist" />
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>
	<xsd:element name="response">		<xsd:element name="prompt" type="msc.ivr.basicivr.prompt.type" />
	<xsd:complexType>
	<xsd:choice minOccurs="0" maxOccurs="unbounded">		<!-- media -->
	<xsd:any namespace="##other" processContents="strict"/>
			<xsd:attributeGroup name="msc.ivr.basicivr.media.attlist">
			<xsd:attribute name="src" type="xsd:anyURI" use="required" />
			<xsd:attribute name="type" type="mime.datatype" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.basicivr.media.mix">
			<xsd:choice>
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
	</xsd:choice>		</xsd:choice>
	<xsd:attribute name="status" type="status.datatype"		</xsd:group>
	use="required"/>
	<xsd:attribute name="reason" type="xsd:string"/>		<xsd:group name="msc.ivr.basicivr.media.content">
	<xsd:attribute name="dialogid" type="dialogid.datatype"/>		<xsd:sequence>
	<xsd:attributeGroup ref="fw:framework-attributes"/>		<xsd:group ref="msc.ivr.basicivr.media.mix" minOccurs="0"
	<xsd:anyAttribute namespace="##other" processContents="strict"/>		maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.basicivr.media.type">
			<xsd:group ref="msc.ivr.basicivr.media.content" />
			<xsd:attributeGroup ref="msc.ivr.basicivr.media.attlist" />
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>
	<xsd:element name="event">		<xsd:element name="media" type="msc.ivr.basicivr.media.type" />
	<xsd:complexType>
	<xsd:choice minOccurs="0" maxOccurs="unbounded">		<!-- variable -->
	<xsd:element ref="data"/>
	<xsd:any namespace="##other" processContents="strict"/>		<xsd:attributeGroup name="msc.ivr.basicivr.variable.attlist">
			<xsd:attribute name="value" type="xsd:string" use="required" />
			<xsd:attribute name="type" type="xsd:string" use="required" />
			<xsd:attribute name="format" type="xsd:string" />
			<xsd:attribute ref="xml:lang" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.basicivr.variable.mix">
			<xsd:choice>
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
	</xsd:choice>		</xsd:choice>
	<xsd:attribute name="name" type="eventname.datatype"		</xsd:group>
	use="required"/>
	<xsd:attribute name="dialogid" type="dialogid.datatype"
	use="required"/>
	<xsd:anyAttribute namespace="##other" processContents="strict"/>		<xsd:group name="msc.ivr.basicivr.variable.content">
			<xsd:sequence>
			<xsd:group ref="msc.ivr.basicivr.variable.mix" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.basicivr.variable.type">
			<xsd:group ref="msc.ivr.basicivr.variable.content" />
			<xsd:attributeGroup ref="msc.ivr.basicivr.variable.attlist" />
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>
	<!-- DATATYPES -->		<xsd:element name="variable" type="msc.ivr.basicivr.variable.type" />
	<xsd:simpleType name="URI.datatype">		<!-- dtmf -->
	<xsd:restriction base="xsd:anyURI"/>
	</xsd:simpleType>
	<xsd:simpleType name="dialogid.datatype">		<xsd:attributeGroup name="msc.ivr.basicivr.dtmf.attlist">
	<xsd:restriction base="xsd:string"/>		<xsd:attribute name="digits" type="dtmfstring.datatype"
	</xsd:simpleType>		use="required" />
			<xsd:attribute name="level" type="xsd:integer" default="-6" />
			<xsd:attribute name="duration" type="timedesignation.datatype"
			default="100ms" />
			<xsd:attribute name="interval" type="timedesignation.datatype"
			default="100ms" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
	<xsd:simpleType name="boolean.datatype">		<xsd:group name="msc.ivr.basicivr.dtmf.mix">
	<xsd:restriction base="xsd:NMTOKEN">		<xsd:choice>
	<xsd:enumeration value="true"/>		<xsd:group ref="msc.common.content" minOccurs="0"
	<xsd:enumeration value="false"/>		maxOccurs="unbounded" />
	</xsd:restriction>		</xsd:choice>
	</xsd:simpleType>		</xsd:group>
	<xsd:simpleType name="eventname.datatype">		<xsd:group name="msc.ivr.basicivr.dtmf.content">
	<xsd:restriction base="xsd:NMTOKEN">		<xsd:sequence>
	<xsd:pattern value="[a-zA-Z0-9\.]+"/>		<xsd:group ref="msc.ivr.basicivr.dtmf.mix" minOccurs="0"
	</xsd:restriction>		maxOccurs="unbounded" />
	</xsd:simpleType>		</xsd:sequence>
			</xsd:group>
	<xsd:simpleType name="status.datatype">		<xsd:complexType name="msc.ivr.basicivr.dtmf.type">
	<xsd:restriction base="xsd:NMTOKEN">		<xsd:group ref="msc.ivr.basicivr.dtmf.content" />
	<xsd:pattern value="[0-9][0-9][0-9]"/>		<xsd:attributeGroup ref="msc.ivr.basicivr.dtmf.attlist" />
	</xsd:restriction>		</xsd:complexType>
	</xsd:simpleType>
	<xsd:simpleType name="media.datatype">		<xsd:element name="dtmf" type="msc.ivr.basicivr.dtmf.type" />
	<xsd:restriction base="xsd:string"/>
	</xsd:simpleType>
	<xsd:simpleType name="label.datatype">		<!-- collect -->
	<xsd:restriction base="xsd:string"/>
	</xsd:simpleType>
	<xsd:simpleType name="direction.datatype">		<xsd:attributeGroup name="msc.ivr.basicivr.collect.attlist">
	<xsd:restriction base="xsd:NMTOKEN">		<xsd:attribute name="cleardigitbuffer" type="boolean.datatype"
	<xsd:enumeration value="sendrecv"/>		default="true" />
	<xsd:enumeration value="sendonly"/>		<xsd:attribute name="timeout" type="timedesignation.datatype"
	<xsd:enumeration value="recvonly"/>		default="5s" />
	</xsd:restriction>
	</xsd:simpleType>
	<!-- SHARED ELEMENTS -->		<xsd:attribute name="interdigittimeout"
			type="timedesignation.datatype" default="2s" />
			<xsd:attribute name="termtimeout" type="timedesignation.datatype"
			default="0s" />
			<xsd:attribute name="escapekey" type="dtmfchar.datatype" />
			<xsd:attribute name="termchar" type="dtmfchar.datatype"
			default="#" />
			<xsd:attribute name="maxdigits" type="xsd:positiveInteger"
			default="5" />
			<xsd:attribute name="skipinterval" type="timedesignation.datatype"
			default="6s" />
			<xsd:attribute name="ffkey" type="dtmfchar.datatype" />
			<xsd:attribute name="rwkey" type="dtmfchar.datatype" />
			<xsd:attribute name="pauseinterval" type="timedesignation.datatype"
			default="10s" />
			<xsd:attribute name="pausekey" type="dtmfchar.datatype" />
			<xsd:attribute name="resumekey" type="dtmfchar.datatype" />
			<xsd:attribute name="volumeinterval" type="percentage.datatype"
			default="10%" />
			<xsd:attribute name="volupkey" type="dtmfchar.datatype" />
			<xsd:attribute name="voldnkey" type="dtmfchar.datatype" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
	<xsd:element name="data">		<xsd:group name="msc.ivr.basicivr.collect.mix">
	<xsd:complexType>		<xsd:choice>
	<xsd:choice minOccurs="0" maxOccurs="unbounded">		<xsd:element ref="grammar" minOccurs="0" maxOccurs="1" />
	<xsd:element ref="item"/>		<xsd:group ref="msc.common.content" minOccurs="0"
	<xsd:any namespace="##other" processContents="strict"/>		maxOccurs="unbounded" />
	</xsd:choice>		</xsd:choice>
	<xsd:anyAttribute namespace="##other" processContents="strict"/>		</xsd:group>
			<xsd:group name="msc.ivr.basicivr.collect.content">
			<xsd:sequence>
			<xsd:group ref="msc.ivr.basicivr.collect.mix" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.basicivr.collect.type">
			<xsd:group ref="msc.ivr.basicivr.collect.content" />
			<xsd:attributeGroup ref="msc.ivr.basicivr.collect.attlist" />
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>
	<xsd:element name="item">		<xsd:element name="collect" type="msc.ivr.basicivr.collect.type" />
	<xsd:complexType>
	<xsd:attribute name="name" type="xsd:string"		<!-- grammar -->
	use="required"/>		<xsd:attributeGroup name="msc.ivr.basicivr.grammar.attlist">
	<xsd:attribute name="value" type="xsd:string"		<xsd:attribute name="src" type="xsd:anyURI" />
	use="required"/>		<xsd:attribute name="type" type="mime.datatype" />
	<xsd:anyAttribute namespace="##other" processContents="strict"/>		<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.basicivr.grammar.mix">
			<xsd:choice>
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:choice>
			</xsd:group>
			<xsd:group name="msc.ivr.basicivr.grammar.content">
			<xsd:sequence>
			<xsd:group ref="msc.ivr.basicivr.grammar.mix" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.basicivr.grammar.type"
			mixed="true">
			<xsd:group ref="msc.ivr.basicivr.grammar.content" />
			<xsd:attributeGroup ref="msc.ivr.basicivr.grammar.attlist" />
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>
	<xsd:element name="stream">		<xsd:element name="grammar" type="msc.ivr.basicivr.grammar.type" />
	<xsd:complexType>
	<xsd:choice minOccurs="0" maxOccurs="unbounded">		<!-- record -->
	<xsd:any namespace="##other" processContents="strict"/>
			<xsd:attributeGroup name="msc.ivr.basicivr.record.attlist">
			<xsd:attribute name="timeout" type="timedesignation.datatype"
			default="5s" />
			<xsd:attribute name="type" type="mime.datatype" />
			<xsd:attribute name="dest" type="xsd:anyURI" />
			<xsd:attribute name="beep" type="boolean.datatype" default="false" />
			<xsd:attribute name="vadinitial" type="boolean.datatype"
			default="true" />
			<xsd:attribute name="vadfinal" type="boolean.datatype"
			default="true" />
			<xsd:attribute name="dtmfterm" type="boolean.datatype"
			default="true" />
			<xsd:attribute name="maxtime" type="timedesignation.datatype"
			default="15s" />
			<xsd:attribute name="finalsilence" type="timedesignation.datatype"
			default="5s" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.basicivr.record.mix">
			<xsd:choice>
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
	</xsd:choice>		</xsd:choice>
	<xsd:attribute name="media" type="media.datatype"		</xsd:group>
	use="required"/>
	<xsd:attribute name="label" type="label.datatype"/>		<xsd:group name="msc.ivr.basicivr.record.content">
	<xsd:attribute name="direction" type="direction.datatype"		<xsd:sequence>
	default="sendrecv" />		<xsd:group ref="msc.ivr.basicivr.record.mix" minOccurs="0"
	<xsd:anyAttribute namespace="##other" processContents="strict"/>		maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.basicivr.record.type">
			<xsd:group ref="msc.ivr.basicivr.record.content" />
			<xsd:attributeGroup ref="msc.ivr.basicivr.record.attlist" />
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>
	<xsd:element name="subscribe">		<xsd:element name="record" type="msc.ivr.basicivr.record.type" />
	<xsd:complexType>
	<xsd:choice minOccurs="0" maxOccurs="unbounded">		<!-- promptinfo -->
	<xsd:element ref="notify"/>
			<xsd:attributeGroup name="msc.ivr.basicivr.promptinfo.attlist">
			<xsd:attribute name="duration" type="xsd:nonNegativeInteger" />
			<xsd:attribute name="iterations" type="xsd:positiveInteger" />
			<xsd:attribute name="termmode" type="prompt_termmode.datatype"
			use="required" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.basicivr.promptinfo.mix">
			<xsd:choice>
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
	</xsd:choice>		</xsd:choice>
	<xsd:anyAttribute namespace="##other" processContents="strict"/>		</xsd:group>
			<xsd:group name="msc.ivr.basicivr.promptinfo.content">
			<xsd:sequence>
			<xsd:group ref="msc.ivr.basicivr.promptinfo.mix" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.basicivr.promptinfo.type">
			<xsd:group ref="msc.ivr.basicivr.promptinfo.content" />
			<xsd:attributeGroup ref="msc.ivr.basicivr.promptinfo.attlist" />
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>
	<xsd:element name="notify">		<xsd:element name="promptinfo"
	<xsd:complexType>		type="msc.ivr.basicivr.promptinfo.type" />
	<xsd:choice minOccurs="0" maxOccurs="1">
	<xsd:element ref="data"/>		<!-- collectinfo -->
			<xsd:attributeGroup name="msc.ivr.basicivr.collectinfo.attlist">
			<xsd:attribute name="dtmf" type="dtmfstring.datatype" />
			<xsd:attribute name="termmode" type="collect_termmode.datatype"
			use="required" />
			<xsd:attributeGroup ref="msc.common.attribs" />
			</xsd:attributeGroup>
			<xsd:group name="msc.ivr.basicivr.collectinfo.mix">
			<xsd:choice>
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
	</xsd:choice>		</xsd:choice>
	<xsd:attribute name="name" type="xsd:string" use="required"/>		</xsd:group>
	<xsd:anyAttribute namespace="##other" processContents="strict"/>
			<xsd:group name="msc.ivr.basicivr.collectinfo.content">
			<xsd:sequence>
			<xsd:group ref="msc.ivr.basicivr.collectinfo.mix" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.basicivr.collectinfo.type">
			<xsd:group ref="msc.ivr.basicivr.collectinfo.content" />
			<xsd:attributeGroup ref="msc.ivr.basicivr.collectinfo.attlist" />
	</xsd:complexType>		</xsd:complexType>
	</xsd:element>
	</xsd:schema>		<xsd:element name="collectinfo"
	9. Security Considerations		type="msc.ivr.basicivr.collectinfo.type" />
	Security Considerations to be included in later versions of this		<!-- recordinfo -->
	document.
	10. IANA Considerations		<xsd:attributeGroup name="msc.ivr.basicivr.recordinfo.attlist">
			<xsd:attribute name="recording" type="xsd:anyURI" />
			<xsd:attribute name="type" type="mime.datatype" />
			<xsd:attribute name="duration" type="xsd:nonNegativeInteger" />
			<xsd:attribute name="size" type="xsd:nonNegativeInteger" />
			<xsd:attribute name="termmode" type="record_termmode.datatype"
			use="required" />
	This document registers a new SIP Control Framework Package, a new		<xsd:attributeGroup ref="msc.common.attribs" />
	XML namespace and a new URI scheme "basicivr:".		</xsd:attributeGroup>
	10.1. Control Package Registration		<xsd:group name="msc.ivr.basicivr.recordinfo.mix">
			<xsd:choice>
			<xsd:group ref="msc.common.content" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:choice>
			</xsd:group>
			<xsd:group name="msc.ivr.basicivr.recordinfo.content">
			<xsd:sequence>
			<xsd:group ref="msc.ivr.basicivr.recordinfo.mix" minOccurs="0"
			maxOccurs="unbounded" />
			</xsd:sequence>
			</xsd:group>
			<xsd:complexType name="msc.ivr.basicivr.recordinfo.type">
			<xsd:group ref="msc.ivr.basicivr.recordinfo.content" />
			<xsd:attributeGroup ref="msc.ivr.basicivr.recordinfo.attlist" />
			</xsd:complexType>
			<xsd:element name="recordinfo"
			type="msc.ivr.basicivr.recordinfo.type" />
			<!--
			#############################################################
			BASIC IVR DATATYPES
			#############################################################
			-->
			<xsd:simpleType name="prompt_termmode.datatype">
			<xsd:restriction base="xsd:NMTOKEN">
			<xsd:enumeration value="completed" />
			<xsd:enumeration value="maxduration" />
			<xsd:enumeration value="bargein" />
			</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType name="collect_termmode.datatype">
			<xsd:restriction base="xsd:NMTOKEN">
			<xsd:enumeration value="match" />
			<xsd:enumeration value="noinput" />
			<xsd:enumeration value="nomatch" />
			</xsd:restriction>
			</xsd:simpleType>
			<xsd:simpleType name="record_termmode.datatype">
			<xsd:restriction base="xsd:NMTOKEN">
			<xsd:enumeration value="noinput" />
			<xsd:enumeration value="dtmf" />
			<xsd:enumeration value="maxtime" />
			<xsd:enumeration value="finalsilence" />
			</xsd:restriction>
			</xsd:simpleType>
			</xsd:schema>
			10. Security Considerations
			As this control package uses XML markup, implementation MUST address
			the security considerations of [RFC3023].
			11. IANA Considerations
			This specification instructs IANA to register a new Media Control
			Channel Framework Package, a new XML namespace and a new mime type.
			11.1. Control Package Registration
	Control Package name: msc-ivr-basic/1.0		Control Package name: msc-ivr-basic/1.0
	10.2. URN Sub-Namespace Registration		11.2. URN Sub-Namespace Registration
	XML namespace: urn:ietf:params:xml:ns:msc-ivr-basic		XML namespace: urn:ietf:params:xml:ns:msc-ivr-basic
	11. Change Summary		11.3. Mime Type Registration
			MIME type: application/msc-ivr-basic+xml
			12. Change Summary
			Note to RFC Editor: Please remove this whole section.
			The following are the major changes between the -06 of the draft and
			the -05 version.
			o Event notifications are sent in CONTROL messages with the MS
			acting as Control Framework Client. Compared with the previous
			approach, this means that a <dialogstart> transaction is now
			complete when the MS sends a <response>. A new transaction is
			initiated by the MS each time the MS sends a notification <event>
			to the AS.
			o Changed conf-id to conferenceid and connection-id to connectionid.
			o Clarification of the state model for dialogs
			o <dialogprepare>: modified definition of src attribute to allow
			reference to external dialog documents; added (MIME) type
			attribute; removed <data> child element.
			o <dialogstart>: modified definition of src attribute to allow
			reference to external dialog documents; added (MIME) type
			attribute; removed <data> child element;
			o <dialogterminate>: modified so that a dialogexit event is always
			sent for active dialogs (i.e. the dialogexit event is a
			terminating notification)
			o <event> notification simplified and make more extensible. Manual
			notifications (via <subscribe> element) are removed from the basic
			package. A <dialogexit> event is defined as <event> child and it
			can be extended with additional child elements
			o <data> element is removed.
			o <subscribe> element removed.
			o Replaced dialog templates with a general <basicivr> element. It
			has child elements for playing media resource (<prompt>),
			collecting DTMF (<collect>) and recording (<record>). The
			functionality is largely unchanged.
			o <dialogprepare> and <dialogstart> are extended with <basicivr>
			child element.
			o <event> is extended with a <dialogexit> element which contains
			status and reported information (replacement for output parameters
			in template dialogs)
			o Prompts: now structured as a <prompt> element with <media>,
			<variable> and <dtmf> children. The <prompt> element has xml:base
			attribute, bargein, iterations, duration, volume and offset
			attributes. The speed attribute is removed. A <media> element
			has src and type attributes. The maxage and maxstale attributes
			are removed.
			o DTMF input: parameters now specified as attributes of a <collect>
			element. Custom grammar specified with a <grammar> element as
			child of <collect> element. Added 'escapekey' to allow the dialog
			to be retried. Added 'pauseinterval', 'pausekey' and 'resumekey'
			to allow the prompts to paused/resumed. Added 'volumeinterval',
			'volupkey' and voldnkey' to add prompt volume to be increased/
			decreased. Moved 'bargein' attribute to prompt.
			o Recording: parameters now specified as attributes of <record>
			element. Added 'dest' and 'beep' attributes.
	The following are the major changes between the -05 of the draft and		The following are the major changes between the -05 of the draft and
	the -04 version.		the -04 version.
	o Mainly an allignment/evaluation exercise with requirements		o Mainly an alignment/evaluation exercise with requirements produced
	produced by MEDIACTRL IVR design team.		by MEDIACTRL IVR design team.
	o playannouncement parameters from Table 7 of '04' version are now		o playannouncement parameters from Table 7 of '04' version are now
	reflected in text - schema to be updated.		reflected in text - schema to be updated.
	o Added VCR commands based on MSCML.		o Added VCR commands based on MSCML.
	The following are the major changes between the -04 of the draft and		The following are the major changes between the -04 of the draft and
	the -03 version.		the -03 version.
	o None.		o None.
	skipping to change at page 66, line 5 ¶		skipping to change at page 72, line 5 ¶
	o re-organized so that template details after general package		o re-organized so that template details after general package
	framework and element description.		framework and element description.
	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 Removed requirement for VoiceXML dialog support		o Removed requirement for VoiceXML dialog support
	o Added requirement for template dialog support		o Added requirement for template dialog support
	12. Contributors		13. Contributors
	Asher Shiratzky from Radvision provided valuable support and		Asher Shiratzky from Radvision provided valuable support and
	contributions to the early versions of this document.		contributions to the early versions of this document.
	The authors would like to thank the IVR design team consisting of		The authors would like to thank the IVR design team consisting of
	Roni Even, Lorenzo Miniero, Adnan Saleem and Diego Besprosvan who		Roni Even, Lorenzo Miniero, Adnan Saleem and Diego Besprosvan who
	provided valuable feedback, input and text to this document.		provided valuable feedback, input and text to this document.
	13. Acknowledgments		14. Acknowledgments
	The authors would like to thank Adnan Saleem of Radisys, Gene		The authors would like to thank Adnan Saleem of Radisys, Gene
	Shtirmer of Intel and Dave Burke of Google for useful reviews of this		Shtirmer of Intel, Dave Burke of Google and Dan York of Voxeo for
	work.		useful reviews of this work.
	14. References		15. References
	14.1. Normative References		15.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.
	14.2. Informative References		15.2. Informative References
	[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.
	[H.248.1] "Gateway control protocol: Version 3", ITU-T		[H.248.1] "Gateway control protocol: Version 3", ITU-T
	Recommendation H.248.1.		Recommendation H.248.1.
	[H.248.9] "Gateway control protocol: Advanced media server		[H.248.9] "Gateway control protocol: Advanced media server
	packages", ITU-T Recommendation H.248.9.		packages", ITU-T Recommendation H.248.9.
	[MSCP] McGlashan, S., Auburn, R., Burke, D., Candell, E., and R.		[I-D.ietf-mediactrl-requirements]
	Surapaneni, "Media Server Control Protocol (MSCP)",		Dolly, M. and R. Even, "Media Server Control Protocol
	draft-mcglashan-mscp-03 (work in progress), March 2007.		Requirements", draft-ietf-mediactrl-requirements-03 (work
			in progress), December 2007.
	[MSML] Saleem, A., Xin, Y., and G. Sharratt, "Media Session		[MCCF] Boulton, C., Melanchuk, T., McGlashan, S., and A.
	Markup Language (MSML)", draft-saleem-msml-05 (work in		Shiratzky, "Media Control Channel Framework",
	progress), August 2007.		draft-ietf-mediactrl-sip-control-framework-01 (work in
			progress), February 2008.
	[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[MSML] Saleem, A., Xin, Y., and G. Sharratt, "Media Session
	Resource Identifiers (URI): Generic Syntax", RFC 2396,		Markup Language (MSML)", draft-saleem-msml-06 (work in
	August 1998.		progress), February 2008.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Digits, Telephony Tones and Telephony Signals", RFC 2833,
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		May 2000.
	[RFC2897] Cromwell, D., "Proposal for an MGCP Advanced Audio		[RFC2897] Cromwell, D., "Proposal for an MGCP Advanced Audio
	Package", RFC 2897, August 2000.		Package", RFC 2897, August 2000.
			[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
			Types", RFC 3023, January 2001.
			[RFC3066] Alvestrand, H., "Tags for the Identification of
			Languages", RFC 3066, 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		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Provisional Responses in Session Initiation Protocol		Resource Identifier (URI): Generic Syntax", STD 66,
	(SIP)", RFC 3262, June 2002.		RFC 3986, January 2005.
	[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
	Protocol (SIP): Locating SIP Servers", RFC 3263,
	June 2002.
	[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	with Session Description Protocol (SDP)", RFC 3264,
	June 2002.
	[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network		[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.
			[RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs
			Parameter for "Bucket" Media Types", RFC 4281,
			November 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.
	[RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol		[RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol
	(SIP) Event Package for Key Press Stimulus (KPML)",		(SIP) Event Package for Key Press Stimulus (KPML)",
	RFC 4730, November 2006.		RFC 4730, November 2006.
	[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server		[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
	Control Markup Language (MSCML) and Protocol", RFC 5022,		Control Markup Language (MSCML) and Protocol", RFC 5022,
	September 2007.		September 2007.
	[SIPCF] Boulton, C., Melanchuk, T., McGlashan, S., and A.
	Shiratzky, "A Control Framework for the Session Initiation
	Protocol (SIP)",
	draft-ietf-mediactrl-sip-control-framework-00 (work in
	progress), August 2007.
	[SRGS] Hunt, A. and S. McGlashan, "Speech Recognition Grammar		[SRGS] Hunt, A. and S. McGlashan, "Speech Recognition Grammar
	Specification Version 1.0", W3C Recommendation,		Specification Version 1.0", W3C Recommendation,
	March 2004.		March 2004.
			[VXML20] McGlashan, S., Burnett, D., Carter, J., Danielsen, P.,
			Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K.,
			and S. Tryphonas, "Voice Extensible Markup Language
			(VoiceXML) Version 2.0", W3C Recommendation, March 2004.
			[VXML21] Oshry, M., Auburn, RJ., Baggia, P., Bodell, M., Burke, D.,
			Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee,
			A., Porter, B., and K. Rehor, "Voice Extensible Markup
			Language (VoiceXML) Version 2.1", W3C Recommendation,
			June 2007.
			[VXMLCP] Boulton, C., Melanchuk, T., and S. McGlashan, "A VoiceXML
			Interactive Voice Response (IVR) Control Package for the
			Media Control Channel Framework",
			draft-boulton-ivr-vxml-control-package-04 (work in
			progress), February 2008.
	[XML] Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E.,		[XML] Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E.,
	and F. Yergeau, "Extensible Markup Language (XML) 1.0		and F. Yergeau, "Extensible Markup Language (XML) 1.0
	(Third Edition)", W3C Recommendation, February 2004.		(Third Edition)", W3C Recommendation, February 2004.
	Authors' Addresses		Authors' Addresses
	Chris Boulton		Chris Boulton
	Avaya		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@avaya.com		Email: cboulton@avaya.com
	Tim Melanchuk		Tim Melanchuk
	TJM Consulting		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
	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. 392 change blocks.
	1812 lines changed or deleted		2243 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/