Network Working Group C. Boulton
Internet-Draft Avaya
Intended status: Standards Track T. Melanchuk
Expires: August 26, 2008 Rain Willow Communications
S. McGlashan
Hewlett-Packard
February 23, 2008
A Basic Interactive Voice Response (IVR) Control Package for the Media
Control Channel Framework
draft-boulton-ivr-control-package-06
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Boulton, et al. Expires August 26, 2008 [Page 1]
Internet-Draft Media Server Control Package February 2008
Abstract
This document defines a Media Control Channel Framework Package for
basic Interactive Voice Response (IVR) interaction.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7
3. Control Package Definition . . . . . . . . . . . . . . . . . . 8
3.1. Control Package Name . . . . . . . . . . . . . . . . . . . 8
3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 8
3.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 9
3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 9
3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 9
4. Dialog Management Element Definitions . . . . . . . . . . . . 11
4.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. <dialogprepare> . . . . . . . . . . . . . . . . . . . 12
4.1.2. <dialogstart> . . . . . . . . . . . . . . . . . . . . 13
4.1.3. <dialogterminate> . . . . . . . . . . . . . . . . . . 16
4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1. <response> . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1. <event> . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.2. <dialogexit> . . . . . . . . . . . . . . . . . . . . . 19
5. Basic IVR Dialog Element Definitions . . . . . . . . . . . . . 21
5.1. <basicivr> . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2. <prompt> . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2.1. <media> . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.2. <variable> . . . . . . . . . . . . . . . . . . . . . . 26
5.2.3. <dtmf> . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3. <collect> . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.1. <grammar> . . . . . . . . . . . . . . . . . . . . . . 31
5.4. <record> . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5. Exit Information . . . . . . . . . . . . . . . . . . . . . 36
5.5.1. <promptinfo> . . . . . . . . . . . . . . . . . . . . . 37
5.5.2. <collectinfo> . . . . . . . . . . . . . . . . . . . . 37
5.5.3. <recordinfo> . . . . . . . . . . . . . . . . . . . . . 37
6. AS-MS Dialog Interaction Examples . . . . . . . . . . . . . . 39
6.1. Starting an IVR dialog . . . . . . . . . . . . . . . . . . 39
6.2. IVR dialog fails to start . . . . . . . . . . . . . . . . 39
6.3. Preparing and starting an IVR dialog . . . . . . . . . . . 40
6.4. Terminating a dialog . . . . . . . . . . . . . . . . . . . 41
7. Basic IVR Dialog Examples . . . . . . . . . . . . . . . . . . 43
7.1. Playing announcements . . . . . . . . . . . . . . . . . . 43
7.2. Prompt and collect . . . . . . . . . . . . . . . . . . . . 44
7.3. Prompt and record . . . . . . . . . . . . . . . . . . . . 45
Boulton, et al. Expires August 26, 2008 [Page 2]
Internet-Draft Media Server Control Package February 2008
8. Type Definitions . . . . . . . . . . . . . . . . . . . . . . . 46
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 48
9.1. msc-ivr-common.xsd . . . . . . . . . . . . . . . . . . . . 48
9.2. msc-ivr-basic.xsd . . . . . . . . . . . . . . . . . . . . 55
10. Security Considerations . . . . . . . . . . . . . . . . . . . 67
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68
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
Boulton, et al. Expires August 26, 2008 [Page 3]
Internet-Draft Media Server Control Package February 2008
1. Introduction
The Media Control Channel Framework [MCCF] provides a generic
approach for establishment and reporting capabilities of remotely
initiated commands. The Framework utilizes many functions provided
by the Session Initiation Protocol [RFC3261] (SIP) for the rendezvous
and establishment of a reliable channel for control interactions.
The Control Framework also introduces the concept of a Control
Package. A Control Package is an explicit usage of the Control
Framework for a particular interaction set. This document defines a
Control Package for basic IVR dialogs.
This package has been designed to satisfy the IETF MediaCtrl
requirements ([I-D.ietf-mediactrl-requirements]) by building upon two
major approaches to IVR dialog design. These approaches address a
wide range of IVR use cases and are used in many applications which
are extensively deployed today.
First, the package is designed to provide the major IVR functionality
of SIP Media Server languages such as netann ([RFC4240]), MSCML
([RFC5022]) and MSML ([MSML]) which themselves build upon more
traditional non-SIP languages ([H.248.9], [RFC2897]). A key
differentiator is that this package provides the functionality using
the Media Control Channel Framework.
Second, its design is aligned with key concepts in W3C Voice Browser
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.
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.
The scope of this package is 'basic' IVR functionality of a media
server which includes:
Boulton, et al. Expires August 26, 2008 [Page 4]
Internet-Draft Media Server Control Package February 2008
o playing one or more media resources as a prompt to the user
o collecting DTMF input from the user according to a grammar
o recording user media input
Out of scope of this package are more advanced functions including
ASR (Automatic Speech Recognition), TTS (Text-to-Speech), VoiceXML,
fax and media transformation. Such functionality may be addressed by
extension packages.
This functionality of this package is defined by messages, containing
XML [XML] elements, transported using the Media Control Channel
Framework. The XML elements can be divided into two types: dialog
management elements; and carried within those, elements which define
the specific IVR operations for the dialog.
Dialog management elements are designed to manage the general
lifecycle of a dialog. Elements are provided for preparing a dialog,
starting the dialog on a conference or connection, and terminating
execution of a dialog. Each of these elements is contained in a
Media Control Channel Framework CONTROL message sent to the media
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
Boulton, et al. Expires August 26, 2008 [Page 5]
Internet-Draft Media Server Control Package February 2008
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).
Boulton, et al. Expires August 26, 2008 [Page 6]
Internet-Draft Media Server Control Package February 2008
2. Conventions and Terminology
In this document, BCP 14/RFC 2119 [RFC2119] defines the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL". In addition, BCP 15 indicates requirement levels for
compliant implementations.
The following additional terms are defined for use in this document:
Dialog: A dialog performs media interaction with a user. A dialog
is specified as inline XML, or via a URI reference to an external
XML document type. Dialogs typically feature basic capabilities
such as playing audio prompts, collecting DTMF input and recording
audio input from the user. More advanced dialogs may also feature
synthesized speech, recording and playback of video, recognition
of spoken input, and mixed initiative conversations.
Application server: A SIP [RFC3261] application server (AS) hosts
and executes services such as interactive media and conferencing
in an operator's network. An AS influences and impacts the SIP
session, in particular by terminating SIP sessions on a media
server, which is under its control.
Media Server: A media server (MS) processes media streams on behalf
of an AS by offering functionality such as interactive media,
conferencing, and transcoding to the end user. Interactive media
functionality is realized by way of dialogs which are initiated by
the application server.
Boulton, et al. Expires August 26, 2008 [Page 7]
Internet-Draft Media Server Control Package February 2008
3. Control Package Definition
This section fulfills the mandatory requirement for information that
MUST be specified during the definition of a Control Framework
Package, as detailed in Section 8 of [MCCF].
3.1. Control Package Name
The Control Framework requires a Control Package to specify and
register a unique name and version.
The name and version of this Control Package is "msc-ivr-basic/1.0"
(Media Server Control - Interactive Voice Response - Basic - version
1.0). Its IANA registration is specified in Section 11.1.
3.2. Framework Message Usage
The Control Framework requires a Control Package to explicitly detail
the control messages that can be used as well as provide an
indication of directionality between entities. This will include
which role type is allowed to initiate a request type.
This package defines XML elements for dialog management in Section 4;
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.
In this package, the MS operates as a Control Framework Server in
receiving requests from, and sending responses to, the AS (operating
as Control Framework Client). These requests are carried in CONTROL
message bodies from AS to MS; <dialogprepare>, <dialogstart> and
<dialogterminate> elements are defined as package requests.
Responses to these requests are carried either in REPORT messages or
Control Framework 200 response bodies with <response> element
payload.
Note that package responses are different from framework response
codes. Framework error response codes (see Section 8 of [MCCF]) are
used when the request or event notification is invalid; for example,
a request is invalid XML (400), or not understood (500). Package
responses are carried in 200 response or REPORT message bodies. This
package's response codes are defined in Section 4.2.1.
The MS also operates as a Control Framework Client in sending event
notifications to the AS (Control Framework Server). Event
notifications are carried in CONTROL message bodies; the <event>
Boulton, et al. Expires August 26, 2008 [Page 8]
Internet-Draft Media Server Control Package February 2008
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
The Control Framework requires a Control Package definition to
specify if the attributes for media dialog or conference references
are required.
This package requires that the XML Schema in Section 16.1 of [MCCF]
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
The Control Framework requires a Control Package to define the
control body that can be contained within a CONTROL command request
and to indicate the location of detailed syntax definitions and
semantics for the appropriate body types.
When operating as Control 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
The Control Framework requires a control package definition to define
the REPORT body that can be contained within a REPORT command
request, or that no report package body is required. This section
should indicate the location of detailed syntax definitions and
semantics for the appropriate body types.
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.
When operating as Control Framework Client, the MS receives REPORT
messages which SHOULD NOT contain a body.
[Editors Note:IVR01 need to clarify the behavior when the MS receives
Boulton, et al. Expires August 26, 2008 [Page 9]
Internet-Draft Media Server Control Package February 2008
a REPORT in response to sending an event notification CONTROL.]
Boulton, et al. Expires August 26, 2008 [Page 10]
Internet-Draft Media Server Control Package February 2008
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
Requests are send to the MS (operating as a Control Framework Server)
in the body of CONTROL messages.
The following request elements are defined:
<dialogprepare>: prepare an IVR dialog for later execution
<dialogstart>: start an IVR dialog on a connection or conference
<dialogterminate>: terminate an 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.
Boulton, et al. Expires August 26, 2008 [Page 11]
Internet-Draft Media Server Control Package February 2008
4.1.1. <dialogprepare>
The <dialogprepare> request is sent to the MS to request preparation
of an IVR dialog. Dialog preparation consists of (a) retrieving an
external dialog document (if specified), and (b) validating the
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:
src: specifies the location of an external dialog document to
prepare. A valid value is a URI (see Section 8.9). It is an
error if the document cannot be retrieved or processed (e.g. URI
protocol not supported). The attribute is optional.
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
attribute is not specified, the MS creates a unique name for the
dialog. The value is used in subsequent references to the dialog
(e.g. as dialogid in a <response>). It is an error if a dialog
with the same name already exists on the MS. The attribute is
optional.
The <dialogprepare> element 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.
The dialog to prepare can either be specified inline as a child
element or externally using the src attribute (but not both). It is
an error if both an inline dialog element and a src attribute are
specified.
When an MS receives a <dialogprepare> request, the dialog is in a
PREPARING state. If dialog preparation was successful, the dialog is
in a PREPARED state; otherwise the dialog is in a TERMINATED state.
The MS MUST reply to <dialogprepare> request with a <response>
element (Section 4.2), reporting whether dialog preparation was
successful or not.
Example: in CONTROL message from AS to MS, the following request
prepares a basic IVR dialog where a single prompt is played once:
Boulton, et al. Expires August 26, 2008 [Page 12]
Internet-Draft Media Server Control Package February 2008
<dialogprepare>
<basicivr>
<prompt>
<media src="http://www.example.com/prompt1.wav"/>
</prompt>
</basicivr>
</dialogprepare>
Alternatively, the same dialog could be referenced:
<dialogprepare type="application/msc-ivr-basic+xml"
src="http://example.org/basic1.xml"/>
if the dialog is prepared successful, then a Control Framework 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.1.2. <dialogstart>
The <dialogstart> element is sent by the AS to start a dialog. The
dialog may be specified in the <dialogstart> request itself, or
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:
src: specifies the location of an external dialog document to start.
A valid value is a URI (see Section 8.9). It is an error if the
document cannot be retrieved or processed (e.g. URI protocol not
supported). The attribute is optional.
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.
Boulton, et al. Expires August 26, 2008 [Page 13]
Internet-Draft Media Server Control Package February 2008
dialogid: string indicating a unique name for the dialog. If this
attribute is not specified, the MS creates a unique name for the
dialog. The value is used in subsequent references to the dialog
(e.g. as dialogid in a <response>). It is an error if a dialog
with the same name already exists on the MS. The attribute is
optional.
prepareddialogid: string identifying a dialog previously prepared
using a dialogprepare request. The attribute is optional.
connectionid: string identifying the SIP dialog connection on which
this dialog is to be started (see Section 16.1 of [MCCF]). The
attribute is optional.
conferenceid: string identifying the conference on which this dialog
is to be started (see Section 16.1 of [MCCF]). The attribute is
optional.
Exactly one of the connectionid or conferenceid attributes MUST be
specified. It is an error to specify both connectionid and
conferenceid attributes or neither.
The <dialogstart> element has the following child elements defined:
<stream>: contains the following attributes:
media: a string indicating the type of media associated with the
stream. It is strongly RECOMMENDED that the following values
are used for common types of media: "audio" for audio media,
and "video" for video media. The attribute is mandatory.
label: a string indicating the SDP label associated with a media
stream ([RFC4574]). The attribute is optional.
direction: a string indicating the direction of the media flow
between a dialog and its end point conference or connection.
Defined values are: "sendrecv" (media can be sent and
received), "sendonly" (media can only be sent), and "recvonly"
(media can only be received). The default value is "sendrecv".
The attribute is optional.
One or more <stream> elements may be specified so that individual
media streams can be controlled independently; for example, audio
only for transmission, but video only for reception. The <stream>
element is optional. If no <stream> elements are specified, then
the default is the media configuration of the connection or
conference. It is an error if a <stream> element is in conflict
with (a) another <stream> element, (b) with dialog, connection or
Boulton, et al. Expires August 26, 2008 [Page 14]
Internet-Draft Media Server Control Package February 2008
conference media capabilities, or (c) with a SDP label value as
part of the connectionid (see Section 16.1 of [MCCF]).
The <dialogstart> 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.
The dialog to start can be specified either inline, or externally, or
reference a previously prepared dialog. Exactly one of the src
attribute, the prepareddialogid or a dialog type child element MUST
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.
When an MS receives a <dialogstart> request, the dialog is either in
an IDLE or PREPARED state (if a previously prepared dialog is being
started). If in the IDLE state, then the dialog is first prepared
and if successful, transitions to the PREPARED state. When the
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.
[Editors Note:IVR02 This specification does not defined the behavior
when more than one dialog is started on the same connection or
conference. Various models could be applied:
reject: only one dialog per connection or conference
replace: the current dialog is stopped and the new one started
queue: the new dialog is queued for starting after current dialog
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
Boulton, et al. Expires August 26, 2008 [Page 15]
Internet-Draft Media Server Control Package February 2008
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>
Alternatively, the same dialog could be referenced:
<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>
A dialog that has been successfully prepared or started can be
terminated by sending a <dialogterminate> request element to the MS.
The <dialogterminate> element has the following attributes:
dialogid: string identifying the dialog to terminate. The attribute
is mandatory.
immediate: indicates whether the dialog is to be terminated
immediately or not. A valid value is a boolean (see Section 8.1).
A value of true indicates that the dialog is terminated and a
dialogexit <event> notification MUST be sent immediately. A value
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.
It is an error if the dialogid is invalid.
Boulton, et al. Expires August 26, 2008 [Page 16]
Internet-Draft Media Server Control Package February 2008
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"/>
if the dialog is terminated successfully, then a Control Framework
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
Responses are generated in response to <dialogprepare>, <dialogstart>
and <dialogterminate> requests. Responses are specified in a
<response> element.
4.2.1. <response>
Responses to requests are indicated by a <response> element.
The <response> element has following attributes:
status: numeric code indicating the response status. The attribute
is mandatory.
Boulton, et al. Expires August 26, 2008 [Page 17]
Internet-Draft Media Server Control Package February 2008
reason: string specifying a reason for the response status. The
attribute is optional.
dialogid: string identifying the dialog. The attribute is optional.
connectionid: string identifying the SIP dialog connection
associated with the dialog (see Section 16.1 of [MCCF]). The
attribute is optional.
conferenceid: string identifying the conference associated with the
dialog (see Section 16.1 of [MCCF]). The attribute is optional.
The following status codes are defined:
+-----------+-------------------------------------------------------+
| code | description |
+-----------+-------------------------------------------------------+
| 200 | OK |
| | |
| 401 | dialogid already exists |
| | |
| 402 | dialogid does not exist |
| | |
| 403 | connectionid does not exist |
| | |
| 404 | conferenceid does not exist |
| | |
| 405 | Unknown or unsupported element |
| | |
| 406 | Element required |
| | |
| 407 | Unknown or unsupported attribute |
| | |
| 408 | Attribute required |
| | |
| 409 | dialog type not supported |
| | |
| 410 | Retrieving document resource failed |
| | |
| 411 | Invalid attribute value |
| | |
| 499 | other error |
+-----------+-------------------------------------------------------+
Table 1: <response> status codes
[Editors Note:IVR03 more status codes may need to be defined.]
Boulton, et al. Expires August 26, 2008 [Page 18]
Internet-Draft Media Server Control Package February 2008
For example, a response when a dialog was prepared successfully:
<response status="200" dialogid="vxi1"/>
The response if dialog preparation failed due to an unsupported
dialog type:
<response status="409" dialogid="vxi1"
reason="Unsupported dialog type: application/basicirv+xml"/>
For example, a response when the dialog was started successfully.
<response status="200" dialogid="vxi1"
connectionid="7HDY839~HJKSkyHS"/>
See Section 6 and Section 7 for further examples.
4.3. Notifications
Event notifications are specified in an <event> element.
Event notifications MUST NOT be sent unless the dialog is in a
STARTED state.
4.3.1. <event>
When a dialog generates a notification event, the MS sends the event
to the AS using an <event> element.
The <event> element has the following attributes:
dialogid: string identifying the dialog which generated the event.
The attribute is mandatory.
The <event> element has the following child elements:
<dialogexit>: indicates that the dialog has exited. The element is
optional.
Extension packages may define other child elements for notifications
which they support.
See Section 6 and Section 7 for examples.
4.3.2. <dialogexit>
The <dialogexit> event indicates that an active dialog has exited
because it is complete, has been terminated, or because an error
Boulton, et al. Expires August 26, 2008 [Page 19]
Internet-Draft Media Server Control Package February 2008
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 <dialogexit> element has 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.
reason: a textual description providing a reason for the status
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.
[Editors Note:IVR04 do we need to specify specific error codes?]
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.
Example: when a STARTED <basicivr> dialog exits normally the MS sends
a dialogexit <event>:
<event dialogid="vxi1"/>
<dialogexit status="1">
<collectinfo dtmf="1234" termmode="match"/>
</dialogexit>
See Section 6 and Section 7 for further examples.
Boulton, et al. Expires August 26, 2008 [Page 20]
Internet-Draft Media Server Control Package February 2008
5. Basic IVR Dialog Element Definitions
The basic IVR dialog is an instance of a dialog described in
Section 4.1. The MS MUST support the Basic IVR dialog type in this
package.
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 basic IVR dialog is a simple XML container - <basicivr> - for
executing basic IVR operations of playing prompts (<prompt> - see
Section 5.2), collecting DTMF (<collect> - see Section 5.3),and
recording user input (<record> - see Section 5.4. Results of the
dialog execution are reported in a dialogexit notification event.
Three execution models are defined:
playannouncements: only a <prompt> element is specified in the
container. The prompt media resources are played in sequence.
promptandcollect: a <collect> element is specified and, optionally,
a <prompt> element. If a <prompt> element is specified and
bargein is enabled, playing of the prompt is terminated when
bargein occurs, and DTMF collection is initiated; otherwise, the
prompt is played to completion before DTMF collection is
initiated. If no prompt element is specified, DTMF collection is
initiated immediately.
promptandrecord: a <record> element is specified and, optionally, a
<prompt> element. If a <prompt> element is specified and bargein
is enabled, playing of the prompt is terminated when bargein
occurs, and recording is initiated; otherwise, the prompt is
played to completion before recording is initiated. If no prompt
element is specified, recording is initiated immediately.
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.
Execution results are reported in the <dialogexit> notification event
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:
Boulton, et al. Expires August 26, 2008 [Page 21]
Internet-Draft Media Server Control Package February 2008
<prompt> only: <promptinfo> (see Section 5.5.1) with at least the
termmode attribute specified.
<collect>: <collectinfo> (see Section 5.5.2) with the dtmf and
termmode attributes specified.
<record>: <recordinfo> (see Section 5.5.3) with at least the
recording, type and termmode attributes specified.
The media format requirements for basic IVR dialogs are undefined.
This package is agnostic to the media types and codecs for media
resources and recording which need to be supported by an
implementation. For example, a MS implementation may choose to
support only audio and in particular the 'audio/basic' codec for
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.
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.
[Editors Note:IVR05 One use case which is not covered by this
specification is that of attaching a dialog to a connection, which
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:
1. A signalmode attribute/element is added to <basicivr> indicating
the conditions under which the dialog sends a (non-terminating)
notification event (TBD). If any of its child elements completes
with a termmode value matching a condition (e.g. a 'match' from
<collect>), then information collected by the children is
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).
2. If the signalmode attribute/element is not specified, then the
behavior is as currently defined.
Boulton, et al. Expires August 26, 2008 [Page 22]
Internet-Draft Media Server Control Package February 2008
3. Note that if media prompts were specified, the same prompts would
play repeatedly - a more sophisticated approach would be required
to play different prompts on different termmodes like nomatch,
noinput, etc
Working Group input is needed to determined if this use case is in
scope for this package and whether this type of solution is
adequate.]
5.1. <basicivr>
A dialog to play prompts to the user, collect DTMF or record input.
The dialog is specified using a <basicivr> element with the namespace
defined in Section 11.2.
A <basicivr> element has the following attributes:
version: a string specifying the version of the basicivr package.
The attribute is optional. The default value is '1.0'.
The <basicivr> element has the following child elements:
<prompt>: defines media resources to play in sequence (see
Section 5.2). The element is optional.
<collect>: defines how DTMF is collected (see Section 5.3). The
element is optional.
<record>: defines how recording takes place (see Section 5.4). The
element is optional.
It is an error if no child element is specified. The behavior is not
defined if both <collect> and <record> are specified.
5.2. <prompt>
The <prompt> element specifies a sequence of media resources to play.
A <prompt> element has the following attributes:
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.
bargein: Indicates whether user input stops prompt playback. A
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
Boulton, et al. Expires August 26, 2008 [Page 23]
Internet-Draft Media Server Control Package February 2008
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
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.
The attribute is optional. The default value is 1.
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
percentage (see Section 8.4). The value indicates increase or
decrease 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. The attribute is
optional. The default value is 100%.
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
in determining maximum duration of the prompt.
[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
scaling?]
The <prompt> element has the following child elements:
<media>: media resource (see Section 5.2.1) to play. Multiple
instances of this element are permitted. The element is optional.
<variable>: specifies a variable media announcement (see
Section 5.2.2) to play. Multiple instances of this element are
permitted. The element is optional.
Boulton, et al. Expires August 26, 2008 [Page 24]
Internet-Draft Media Server Control Package February 2008
<dtmf>: generates one or more DTMF tones (see Section 5.2.3) to
play. Multiple instances of this element are permitted. The
element is optional.
It is an error if no child element is specified.
Prompt playing has the following execution model upon initialization:
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.
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>
and <dtmf> in document order. The value of the volume attribute
is applied to each <media> and <variable> if they are rendered as
audio media. If the offset attribute is specified, playback
begins at that offset. If the offset is greater than the
cumulative duration of the child elements, then no prompts are
played in the cycle.
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
counter is updated. If the counter reaches the value of the
iterations attribute, then playback is terminated and the
dialogexit result contains a <promptinfo> termmode attribute set
to completed (see Section 5.5.1). Otherwise, another playback
cycle is initiated.
[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>
The <media> element specifies a media resource to play.
A <media> element has the following attributes:
Boulton, et al. Expires August 26, 2008 [Page 25]
Internet-Draft Media Server Control Package February 2008
src: specifies the location of the media resource. A valid value is
a URI (see Section 8.9). The attribute is mandatory.
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.
The <media> element has no children.
It is an error if the media resource cannot be retrieved or played.
5.2.2. <variable>
The <variable> element specifies variable announcements using
predefined media resources. Each variable has at least a type (e.g.
date) and a value (e.g. 2008-02-25). The value is rendered according
to the variable type (e.g. 25th February 2008) as well as other
defined attributes.
A <variable> element has the following attributes:
value: specifies the string to be rendered. A valid value is a
string (see Section 8.6). The attribute is mandatory.
type: specifies the type to use for rendering. A valid value is a
string (see Section 8.6). The attribute is mandatory.
format: specifies format information to use in conjunction with the
type for the rendering. A valid value is a string (see
Section 8.6). The attribute is optional. There is no default
value.
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:IVR09 do we need a gender attribute for variable
announcements? ]
The <variable> element has no children.
This package is agnostic to which <variable> values, types and
formats are supported by an implementation. However it is
RECOMMENDED that an implementation support the following type/format
combinations:
Boulton, et al. Expires August 26, 2008 [Page 26]
Internet-Draft Media Server Control Package February 2008
type=date Supported formats: "mdy", "ymd", "dym"
type=time Supported formats: "t12", "t24"
type=digits Supported formats: "gen", "ndn", "crn", "ord"
[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
resources into which variable are rendered. For example, an MS
choosing to support audio may render the <variable> into one or more
audio media resources.
It is an error if a <variable> element cannot be rendered
successfully.
Execution of this element can seen, at least logically, as conversion
of a <variable> into a list of <media> elements. For example,
<variable value="2008-02-25" type="date" format="dmy"
xml:lang="en"/>
could be transformed into audio saying "twenty-fifth of February two
thousand and eight" using a list of <media> resources:
<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>
The <dtmf> element specifies a sequence of DTMF tones for output.
DTMF tones could be generated using <media> resources where the
output is transported as RTP audio packets. However, <media>
resources are not sufficient for cases where DTMF tones are to be
transported as DTMF RTP ([RFC2833]) or in event packages.
A <dtmf> element has the following attributes:
digits: specifies the DTMF sequence to output. A valid value is a
DTMF string (see Section 8.3). The attribute is mandatory.
Boulton, et al. Expires August 26, 2008 [Page 27]
Internet-Draft Media Server Control Package February 2008
level: used to define the power level for which the DTMF tones will
be generated. Values are expressed in dBm0. A valid value is an
integer in the range of 0 to -96 (dBm0). Larger negative values
express lower power levels. Note that values lower than -55 dBm0
will be rejected by most receivers (TR-TSY-000181, ITU-T Q.24A).
The attribute is optional. The default value is -6 (dBm0).
duration: specifies the duration for which each DTMF tone is
generated. A valid value is a time designation (see Section 8.7).
Implementations may round the value if they only support discrete
durations. The attribute is optional. The default value is
100ms.
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.
It is an error if a <dtmf> element cannot be processed successfully.
5.3. <collect>
The <collect> element defines how DTMF input is collected.
The <collect> element has the following attributes:
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
is a Time Designation (see Section 8.7). The attribute is
optional. The default value is 5s.
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
recognizing DTMF input. A valid value is a Time Designation (see
Section 8.7). The attribute is optional. The default value is
0s.
Boulton, et al. Expires August 26, 2008 [Page 28]
Internet-Draft Media Server Control Package February 2008
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
collection using the internal grammar. A valid value is a DTMF
character (see Section 8.2). To disable termination by a
conventional DTMF character, set the parameter to an
unconventional character like 'A'. The attribute is optional.
The default value is '#'.
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
forwards through prompt playback when the rewind (rwkey) of fast
forward key (ffkey) is pressed. A valid value is a Time
Designation (see Section 8.7). The attribute is optional. The
default value is 6s.
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
'skipinterval'. A valid value is a DTMF Character (see
Section 8.2). The attribute is optional. There is no default
value.
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.
pausekey: maps a DTMF key to a pause operation equal to the value of
'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
a DTMF Character (see Section 8.2). The attribute is optional.
There is no default value.
Boulton, et al. Expires August 26, 2008 [Page 29]
Internet-Draft Media Server Control Package February 2008
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%.
volupkey: maps a DTMF key to a volume increase 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.
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.
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.
[Editors Note:IVR11 Do we need a speed VCR control as well? ]
[Editors Note:IVR12 it has been proposed that termchar should be
replaced by termkeys (DTMF string value) to allow termination by
multiple characters (e.g. '**'). An additional attribute would
probably also be need to control interdigit timing within this
string. Is this functionality required for this package?]
The <collect> element has the following child elements:
<grammar>: indicates a custom grammar format (see Section 5.3.1).
The element is optional.
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
initialization:
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
attribute is true.
3. A timer with the duration of the value of the timeout attribute
is activated. If the timer expires before DTMF input collection
Boulton, et al. Expires August 26, 2008 [Page 30]
Internet-Draft Media Server Control Package February 2008
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
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
prompts. If a seek operation (ffkey, rwkey) attempts to go
beyond the beginning or end of the prompt queue, then it is
automatically truncated to the prompt beginning or end
respectively. If the pause operation attempts to pause output
when it is already paused, then the operation is ignored. If the
resume operation attempts to resume when the prompts are not
paused, then the operation is ignored. If a volume operations
attempts to go beyond the minimum or maximum volume supported by
the platform, then the operation is ignored. DTMF input matching
VCR controls is ignored for grammar matching.
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
are either a simple digit string where the maximum length is
determined by the maxdigits attribute and may be terminated by
the character in the termchar attribute; or a custom DTMF grammar
specified with the <grammar> element. The attributes
interdigittimeout and termtimeout control interdigit timeout and
the terminating timeout respectively.
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,
collection execution terminates and the dialogexit result
contains a <collectinfo> (see Section 5.5.2) with the termmode
attribute set to nomatch.
5.3.1. <grammar>
The <grammar> element allows a custom grammar, inline or external, to
be specified. Custom grammars permit the full range of DTMF
characters including '*' and '#' to be specified for DTMF pattern
matching.
The <grammar> element has the following attributes:
Boulton, et al. Expires August 26, 2008 [Page 31]
Internet-Draft Media Server Control Package February 2008
src: specifies the location of an external grammar. A valid value
is a URI (see Section 8.9). The attribute is optional. There is
no default value.
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
grammar formats MUST use a namespace other than the one used in this
specification. Non-XML grammar formats MAY use a CDATA section.
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
supported by the MS.
[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
starts a dialog where DTMF collection is determined by an inline SRGS
grammar:
Boulton, et al. Expires August 26, 2008 [Page 32]
Internet-Draft Media Server Control Package February 2008
<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">
<one-of>
<item>
<item repeat="4">
<ruleref uri="#digit"/>
</item>#</item>
<item>* 9</item>
</one-of>
</rule>
</grammar>
</grammar>
</collect>
</basicivr>
</dialogstart>
The same grammar could also be referenced externally (and take
advantage of HTTP caching):
Boulton, et al. Expires August 26, 2008 [Page 33]
Internet-Draft Media Server Control Package February 2008
<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>
See Section 6 and Section 7 for further examples.
5.4. <record>
The <record> element defines how media input is recorded.
The <record> element has the following attributes:
timeout: indicates the time to wait for user input. A valid value
is a Time Designation (see Section 8.7). The attribute is
optional. The default value is 5s.
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).
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.
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.
Boulton, et al. Expires August 26, 2008 [Page 34]
Internet-Draft Media Server Control Package February 2008
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.
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.
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.
beep: indicates whether a 'beep' should be played immediately prior
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.
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.
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.
The <record> element has no child elements.
Recording has the following execution model upon initialization:
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.
2. If a beep attribute with the value of true is specified, then a
beep tone is played.
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
Boulton, et al. Expires August 26, 2008 [Page 35]
Internet-Draft Media Server Control Package February 2008
the dialogexit result contains a <recordinfo> (see Section 5.5.3)
with the termmode attribute set to noinput.
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. 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.
6. During the record operation user media input is recording in the
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.
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.
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. Exit Information
When a basic ivr dialog exits, information is reported in a
<dialogexit> notification event.
The content model of the <dialogexit> element defined in
Section 4.3.2 is extended with the following child elements:
<promptinfo>: reports information about the prompt execution (see
Section 5.5.1). The element is optional.
<collectinfo>: reports information about the collect execution (see
Section 5.5.2). The element is optional.
Boulton, et al. Expires August 26, 2008 [Page 36]
Internet-Draft Media Server Control Package February 2008
<recordinfo>: reports information about the record execution (see
Section 5.5.3). The element is optional.
5.5.1. <promptinfo>
The <promptinfo> element reports the information about prompt
execution. It has the following attributes:
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.
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.
Boulton, et al. Expires August 26, 2008 [Page 37]
Internet-Draft Media Server Control Package February 2008
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.
Boulton, et al. Expires August 26, 2008 [Page 38]
Internet-Draft Media Server Control Package February 2008
6. AS-MS Dialog Interaction Examples
The following example assume a control channel has been established
as described in the Media Control Channel Framework ([MCCF]).
The XML messages are in angled brackets; the REPORT status is in
round brackets. Other aspects of the protocol are omitted for
readability.
6.1. Starting an IVR dialog
An IVR dialog is started successfully, and dialogexit notification
<event> is sent from the MS to the AS when the dialog exits normally.
Application Server (AS) Media Server (MS)
| |
| (1) CONTROL: <dialogstart> |
| ----------------------------------------> |
| |
| (2) 202 |
| <--------------------------------------- |
| |
| |
| (3) REPORT: <response status="200"/> |
| (terminate) |
| <---------------------------------------- |
| |
| (4) 200 |
| ----------------------------------------> |
| |
| (5) CONTROL: <event ... /> |
| |
| <---------------------------------------- |
| |
| (6) 200 |
| ----------------------------------------> |
| |
6.2. IVR dialog fails to start
An IVR dialog fails to start due to an unknown dialog type.
Boulton, et al. Expires August 26, 2008 [Page 39]
Internet-Draft Media Server Control Package February 2008
Application Server (AS) Media Server (MS)
| |
| (1) CONTROL: <dialogstart> |
| ----------------------------------------> |
| |
| (2) 202 |
| <--------------------------------------- |
| |
| (3) REPORT: <response status="409"/> |
| (terminate) |
| <---------------------------------------- |
| |
| (4) 200 |
| ----------------------------------------> |
| |
6.3. Preparing and starting an IVR dialog
An IVR dialog is prepared and started successfully, and then the
dialog exits normally.
Boulton, et al. Expires August 26, 2008 [Page 40]
Internet-Draft Media Server Control Package February 2008
Application Server (AS) Media Server (MS)
| |
| (1) CONTROL: <dialogprepare> |
| ----------------------------------------> |
| |
| (2) 202 |
| <--------------------------------------- |
| |
| (3) REPORT: <response status="200"/> |
| (terminate) |
| <---------------------------------------- |
| |
| (4) 200 |
| ----------------------------------------> |
| |
| (5) CONTROL: <dialogstart> |
| ----------------------------------------> |
| |
| (6) 202 |
| <--------------------------------------- |
| |
| (7) REPORT: <response status="200"/> |
| (terminate) |
| <---------------------------------------- |
| |
| (8) 200 |
| ----------------------------------------> |
| |
| (9) CONTROL: <event .../> |
| <---------------------------------------- |
| |
| (10) 200 |
| ----------------------------------------> |
| |
6.4. Terminating a dialog
An IVR dialog is started successfully, and then terminated by the AS.
The dialogexit event is sent by to the AS when the dialog exits.
Boulton, et al. Expires August 26, 2008 [Page 41]
Internet-Draft Media Server Control Package February 2008
Application Server (AS) Media Server (MS)
| |
| (1) CONTROL: <dialogstart> |
| ----------------------------------------> |
| |
| (2) 202 |
| <--------------------------------------- |
| |
| (3) REPORT: <response status="200"/> |
| (terminate) |
| <---------------------------------------- |
| |
| (4) 200 |
| ----------------------------------------> |
| |
| (5) CONTROL: <dialogterminate> |
| ----------------------------------------> |
| |
| (6) 200: <response status="200"/> |
| <---------------------------------------- |
| |
| (7) CONTROL: <event .../> |
| <---------------------------------------- |
| |
| (8) 200 |
| ----------------------------------------> |
| |
Note that in (6) the <response> payload to the <dialogterminate/>
request is carried on a framework 200 response since it could
complete the requested operation before the transaction timeout.
Boulton, et al. Expires August 26, 2008 [Page 42]
Internet-Draft Media Server Control Package February 2008
7. Basic IVR Dialog Examples
The following examples show how <basicivr> is used with
<dialogprepare>, <dialogstart> and <event> elements to play prompts,
collect DTMF input and record user input.
The examples do not specify all messages between the AS and MS.
7.1. Playing announcements
This example prepares an announcement composed of two prompts.
<dialogprepare>
<basicivr>
<prompt>
<media src="http://www.example.com/media/Number_09.wav"/>
<media src="http://www.example.com/media/Number_11.wav"/>
</prompt>
</basicivr>
</dialogprepare>
If the dialog is prepared successfully, a <response> with status 200
is returned:
<response status="200" dialogid="vxi78"/>
The prepared dialog is then started on a conference playing the
prompts twice:
<dialogstart prepareddialogid="vxi78" conferenceid="conference11"/>
In the case of a successful dialog, the output is provided in
<event>; for example
<event dialogid="vxi78">
<dialogexit status="1">
<promptinfo termmode="completed"/>
</dialogexit>
</event>
Boulton, et al. Expires August 26, 2008 [Page 43]
Internet-Draft Media Server Control Package February 2008
7.2. Prompt and collect
This example plays no prompts and just waits for DTMF input from the
user:
<dialogstart connectionid="7HDY839~HJKSkyHS~HUwkuh7ns">
<basicivr>
<collect/>
</basicivr>
</dialogstart>
If the dialog is successful, then "dialogexit" <event> contains the
dtmf collected in its result parameter:
<event dialogid="vxi80">
<dialogexit status="1">
<collectinfo dtmf="12345" termmode="match"/>
</dialogexit>
</event>
In this example, a prompt is played and then we wait for 3 hours for
a two digit sequence:
<dialogstart connectionid="7HDY839~HJKSkyHS~HUwkuh7ns">
<basicivr>
<prompt>
<media src="http://www.example.com/prompt1.wav"/>
</prompt>
<collect timeout="1080s" maxdigits="2"/>
</basicivr>
</dialogstart>
If no user input is collected within 3 hours, then following would be
returned:
<event dialogid="vxi81">
<dialogexit status="1" >
<collectinfo termmode="noinput"/>
</dialogexit>
</event>
And finally in this example, one of the input parameters is invalid:
Boulton, et al. Expires August 26, 2008 [Page 44]
Internet-Draft Media Server Control Package February 2008
<dialogstart connectionid="7HDY839~HJKSkyHS~HUwkuh7ns">
<basicivr>
<prompt iterations="two">
<media src="http://www.example.com/prompt1.wav"/>
</prompt>
<collect cleardigitbuffer="true" bargein="true"
timeout="4s" interdigittimeout="2s"
termtimeout="0s maxdigits="2"/>
</basicivr>
</dialogstart>
The error is reported in a the response:
<response status="411" dialogid="vxi82"
reason="iterations value invalid: two"/>
7.3. Prompt and record
In this example, the user is prompted, then their input is recorded
for a maximum of 30 seconds.
<dialogstart connectionid="7HDY839~HJKSkyHS~HUwkuh7ns">
<basicivr>
<prompt>
<media src="http://www.example.com/media/sayname.wav"/>
</prompt>
<record dtmfterm="false" maxtime="30s" beep="true"/>
</basicivr>
</dialogstart>
If successful, the following is returned in a dialogexit <event>:
<event dialogid="vxi83">
<dialogexit status="1">
<recordinfo recording="http://www.example.com/recording1.wav"
termmode="dtmf"/>
</dialogexit>
</event>
Boulton, et al. Expires August 26, 2008 [Page 45]
Internet-Draft Media Server Control Package February 2008
8. Type Definitions
This section defines types referenced in attribute definitions.
8.1. Boolean
The value space of boolean is the set {true, false}.
8.2. DTMFChar
A DTMF character. The value space is the set {0, 1, 2, 3, 4, 5, 6,
7, 8, 9, #, *, A, B, C, D}.
8.3. DTMFString
A String composed of one or more DTMFChars.
8.4. Non-Negative Integer
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%".
Boulton, et al. Expires August 26, 2008 [Page 46]
Internet-Draft Media Server Control Package February 2008
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.
Boulton, et al. Expires August 26, 2008 [Page 47]
Internet-Draft Media Server Control Package February 2008
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>
<!--
###################################################
Boulton, et al. Expires August 26, 2008 [Page 48]
Internet-Draft Media Server Control Package February 2008
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:group>
<xsd:group name="msc.ivr.common.dialogprepare.content">
<xsd:sequence>
<xsd:group ref="msc.ivr.common.dialogprepare.mix" minOccurs="0"
Boulton, et al. Expires August 26, 2008 [Page 49]
Internet-Draft Media Server Control Package February 2008
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"
Boulton, et al. Expires August 26, 2008 [Page 50]
Internet-Draft Media Server Control Package February 2008
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: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>
Boulton, et al. Expires August 26, 2008 [Page 51]
Internet-Draft Media Server Control Package February 2008
<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" />
Boulton, et al. Expires August 26, 2008 [Page 52]
Internet-Draft Media Server Control Package February 2008
</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" />
<!--
#####################################################
COMMON ATTRIBUTES AND ELEMENTS
#####################################################
-->
<xsd:attributeGroup name="msc.common.attribs">
<xsd:annotation>
<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
Boulton, et al. Expires August 26, 2008 [Page 53]
Internet-Draft Media Server Control Package February 2008
####################################################
-->
<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]" />
Boulton, et al. Expires August 26, 2008 [Page 54]
Internet-Draft Media Server Control Package February 2008
</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
Boulton, et al. Expires August 26, 2008 [Page 55]
Internet-Draft Media Server Control Package February 2008
#############################################################
-->
<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" />
Boulton, et al. Expires August 26, 2008 [Page 56]
Internet-Draft Media Server Control Package February 2008
<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:group>
<xsd:group name="msc.ivr.basicivr.basicivr.content">
<xsd:sequence>
<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:element name="basicivr" type="msc.ivr.basicivr.basicivr.type" />
Boulton, et al. Expires August 26, 2008 [Page 57]
Internet-Draft Media Server Control Package February 2008
<!-- prompt -->
<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:group>
<xsd:group name="msc.ivr.basicivr.prompt.content">
<xsd:choice>
<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:element name="prompt" type="msc.ivr.basicivr.prompt.type" />
<!-- media -->
<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>
Boulton, et al. Expires August 26, 2008 [Page 58]
Internet-Draft Media Server Control Package February 2008
<xsd:group name="msc.ivr.basicivr.media.mix">
<xsd:choice>
<xsd:group ref="msc.common.content" minOccurs="0"
maxOccurs="unbounded" />
</xsd:choice>
</xsd:group>
<xsd:group name="msc.ivr.basicivr.media.content">
<xsd:sequence>
<xsd:group ref="msc.ivr.basicivr.media.mix" minOccurs="0"
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:element name="media" type="msc.ivr.basicivr.media.type" />
<!-- variable -->
<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:group>
<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" />
Boulton, et al. Expires August 26, 2008 [Page 59]
Internet-Draft Media Server Control Package February 2008
<xsd:attributeGroup ref="msc.ivr.basicivr.variable.attlist" />
</xsd:complexType>
<xsd:element name="variable" type="msc.ivr.basicivr.variable.type" />
<!-- dtmf -->
<xsd:attributeGroup name="msc.ivr.basicivr.dtmf.attlist">
<xsd:attribute name="digits" type="dtmfstring.datatype"
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:group name="msc.ivr.basicivr.dtmf.mix">
<xsd:choice>
<xsd:group ref="msc.common.content" minOccurs="0"
maxOccurs="unbounded" />
</xsd:choice>
</xsd:group>
<xsd:group name="msc.ivr.basicivr.dtmf.content">
<xsd:sequence>
<xsd:group ref="msc.ivr.basicivr.dtmf.mix" minOccurs="0"
maxOccurs="unbounded" />
</xsd:sequence>
</xsd:group>
<xsd:complexType name="msc.ivr.basicivr.dtmf.type">
<xsd:group ref="msc.ivr.basicivr.dtmf.content" />
<xsd:attributeGroup ref="msc.ivr.basicivr.dtmf.attlist" />
</xsd:complexType>
<xsd:element name="dtmf" type="msc.ivr.basicivr.dtmf.type" />
<!-- collect -->
<xsd:attributeGroup name="msc.ivr.basicivr.collect.attlist">
<xsd:attribute name="cleardigitbuffer" type="boolean.datatype"
default="true" />
<xsd:attribute name="timeout" type="timedesignation.datatype"
default="5s" />
Boulton, et al. Expires August 26, 2008 [Page 60]
Internet-Draft Media Server Control Package February 2008
<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:group name="msc.ivr.basicivr.collect.mix">
<xsd:choice>
<xsd:element ref="grammar" minOccurs="0" maxOccurs="1" />
<xsd:group ref="msc.common.content" minOccurs="0"
maxOccurs="unbounded" />
</xsd:choice>
</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:element name="collect" type="msc.ivr.basicivr.collect.type" />
<!-- grammar -->
Boulton, et al. Expires August 26, 2008 [Page 61]
Internet-Draft Media Server Control Package February 2008
<xsd:attributeGroup name="msc.ivr.basicivr.grammar.attlist">
<xsd:attribute name="src" type="xsd:anyURI" />
<xsd:attribute name="type" type="mime.datatype" />
<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:element name="grammar" type="msc.ivr.basicivr.grammar.type" />
<!-- record -->
<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>
Boulton, et al. Expires August 26, 2008 [Page 62]
Internet-Draft Media Server Control Package February 2008
<xsd:group name="msc.ivr.basicivr.record.mix">
<xsd:choice>
<xsd:group ref="msc.common.content" minOccurs="0"
maxOccurs="unbounded" />
</xsd:choice>
</xsd:group>
<xsd:group name="msc.ivr.basicivr.record.content">
<xsd:sequence>
<xsd:group ref="msc.ivr.basicivr.record.mix" minOccurs="0"
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:element name="record" type="msc.ivr.basicivr.record.type" />
<!-- promptinfo -->
<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: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" />
Boulton, et al. Expires August 26, 2008 [Page 63]
Internet-Draft Media Server Control Package February 2008
<xsd:attributeGroup ref="msc.ivr.basicivr.promptinfo.attlist" />
</xsd:complexType>
<xsd:element name="promptinfo"
type="msc.ivr.basicivr.promptinfo.type" />
<!-- 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:group>
<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:element name="collectinfo"
type="msc.ivr.basicivr.collectinfo.type" />
<!-- recordinfo -->
<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" />
Boulton, et al. Expires August 26, 2008 [Page 64]
Internet-Draft Media Server Control Package February 2008
<xsd:attributeGroup ref="msc.common.attribs" />
</xsd:attributeGroup>
<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" />
Boulton, et al. Expires August 26, 2008 [Page 65]
Internet-Draft Media Server Control Package February 2008
<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>
Boulton, et al. Expires August 26, 2008 [Page 66]
Internet-Draft Media Server Control Package February 2008
10. Security Considerations
As this control package uses XML markup, implementation MUST address
the security considerations of [RFC3023].
Boulton, et al. Expires August 26, 2008 [Page 67]
Internet-Draft Media Server Control Package February 2008
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
11.2. URN Sub-Namespace Registration
XML namespace: urn:ietf:params:xml:ns:msc-ivr-basic
11.3. Mime Type Registration
MIME type: application/msc-ivr-basic+xml
Boulton, et al. Expires August 26, 2008 [Page 68]
Internet-Draft Media Server Control Package February 2008
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.
Boulton, et al. Expires August 26, 2008 [Page 69]
Internet-Draft Media Server Control Package February 2008
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 -04 version.
o Mainly an alignment/evaluation exercise with requirements produced
by MEDIACTRL IVR design team.
o playannouncement parameters from Table 7 of '04' version are now
reflected in text - schema to be updated.
o Added VCR commands based on MSCML.
The following are the major changes between the -04 of the draft and
the -03 version.
o None.
The following are the major changes between the -03 of the draft and
the -02 version.
o added "basicivr:" protocol to template dialog types which must be
supported as values of the "src" attribute in <dialogprepare> and
<dialogstart>. Note alternative: "/basicivr/playannouncement"
offered in [RFC4240].
o added "basicivr:" URI schema to IANA considerations
Boulton, et al. Expires August 26, 2008 [Page 70]
Internet-Draft Media Server Control Package February 2008
o Added mimetype, vadinitial and vadfinal parameters to
'promptandrecord' dialog type
o updated references
The following are the major changes between the -02 of the draft and
the -01 version.
o added version 1.0 to package name
o separate section for element definitions
o dialogterminate treated as request rather than notification
o simplified responses: single element <response>
o removed response elements: <dialogprepared>, <dialogstarted>,
<errordialognotprepared>, <errordialognotstarted>
o simplified event notifications to single <event> element carried
in a REPORT
o <dialogexit> element replaced with <event name="dialogexit">
o removed <dialoguser> element
o added <stream> element as child of <dialogstart>
o removed 'type' attribute from <dialogprepare> and <dialogstart>
o added dialogid attribute to <dialogprepare> and <dialogstart>
o removed template "Sample Implementation" section
o renamed <namelist> to <data>
o re-organized so that template details after general package
framework and element description.
The following are the primary changes between the -01 of the draft
and the -00 version.
o Removed requirement for VoiceXML dialog support
o Added requirement for template dialog support
Boulton, et al. Expires August 26, 2008 [Page 71]
Internet-Draft Media Server Control Package February 2008
13. Contributors
Asher Shiratzky from Radvision provided valuable support and
contributions to the early versions of this document.
The authors would like to thank the IVR design team consisting of
Roni Even, Lorenzo Miniero, Adnan Saleem and Diego Besprosvan who
provided valuable feedback, input and text to this document.
Boulton, et al. Expires August 26, 2008 [Page 72]
Internet-Draft Media Server Control Package February 2008
14. Acknowledgments
The authors would like to thank Adnan Saleem of Radisys, Gene
Shtirmer of Intel, Dave Burke of Google and Dan York of Voxeo for
useful reviews of this work.
Boulton, et al. Expires August 26, 2008 [Page 73]
Internet-Draft Media Server Control Package February 2008
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References
[CCXML10] Auburn, R J., "Voice Browser Call Control: CCXML Version
1.0", W3C Working Draft (work in progress), January 2007.
[H.248.1] "Gateway control protocol: Version 3", ITU-T
Recommendation H.248.1.
[H.248.9] "Gateway control protocol: Advanced media server
packages", ITU-T Recommendation H.248.9.
[I-D.ietf-mediactrl-requirements]
Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", draft-ietf-mediactrl-requirements-03 (work
in progress), December 2007.
[MCCF] Boulton, C., Melanchuk, T., McGlashan, S., and A.
Shiratzky, "Media Control Channel Framework",
draft-ietf-mediactrl-sip-control-framework-01 (work in
progress), February 2008.
[MSML] Saleem, A., Xin, Y., and G. Sharratt, "Media Session
Markup Language (MSML)", draft-saleem-msml-06 (work in
progress), February 2008.
[RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF
Digits, Telephony Tones and Telephony Signals", RFC 2833,
May 2000.
[RFC2897] Cromwell, D., "Proposal for an MGCP Advanced Audio
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,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
Boulton, et al. Expires August 26, 2008 [Page 74]
Internet-Draft Media Server Control Package February 2008
June 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
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
Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol
(SIP) Event Package for Key Press Stimulus (KPML)",
RFC 4730, November 2006.
[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 5022,
September 2007.
[SRGS] Hunt, A. and S. McGlashan, "Speech Recognition Grammar
Specification Version 1.0", W3C Recommendation,
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.,
and F. Yergeau, "Extensible Markup Language (XML) 1.0
(Third Edition)", W3C Recommendation, February 2004.
Boulton, et al. Expires August 26, 2008 [Page 75]
Internet-Draft Media Server Control Package February 2008
Authors' Addresses
Chris Boulton
Avaya
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: cboulton@avaya.com
Tim Melanchuk
Rain Willow Communications
Email: tim.melanchuk@gmail.com
Scott McGlashan
Hewlett-Packard
Gustav III:s boulevard 36
SE-16985 Stockholm, Sweden
Email: scott.mcglashan@hp.com
Boulton, et al. Expires August 26, 2008 [Page 76]
Internet-Draft Media Server Control Package February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Boulton, et al. Expires August 26, 2008 [Page 77]