[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06
Network Working Group C. Boulton
Internet-Draft Ubiquity Software Corporation
Intended status: Standards Track T. Melanchuk
Expires: May 5, 2008 BlankSpace
S. McGlashan
Hewlett-Packard
A. Shiratzky
Radvision
November 2, 2007
A Basic Interactive Voice Response (IVR) Control Package for the Session
Initiation Protocol (SIP)
draft-boulton-ivr-control-package-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Boulton, et al. Expires May 5, 2008 [Page 1]
Internet-Draft Media Server Control Package November 2007
Abstract
This document defines a Session Initiation (SIP) Control Package for
basic Interactive Voice Response (IVR) interaction. The control of
Media Servers and their related resources in decomposed network
architectures plays an important role in various Next Generation
Networks. This Control Package provides IVR functionality using the
SIP Control Framework.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
3. Control Package Definition . . . . . . . . . . . . . . . . . . 7
3.1. Control Package Name . . . . . . . . . . . . . . . . . . . 7
3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 7
3.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 7
3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 8
3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 8
4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 9
4.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. <dialogprepare> . . . . . . . . . . . . . . . . . . . 9
4.1.2. <dialogstart> . . . . . . . . . . . . . . . . . . . . 10
4.1.3. <dialogterminate> . . . . . . . . . . . . . . . . . . 12
4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. <response> . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1. <event> . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. <data> . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. <subscribe> . . . . . . . . . . . . . . . . . . . . . . . 16
5. IVR Template Dialogs . . . . . . . . . . . . . . . . . . . . . 18
5.1. Play Announcement . . . . . . . . . . . . . . . . . . . . 18
5.2. Prompt and Collect . . . . . . . . . . . . . . . . . . . . 22
5.3. Prompt and Record . . . . . . . . . . . . . . . . . . . . 31
5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 39
5.5. Type Definitions . . . . . . . . . . . . . . . . . . . . . 40
6. AS-MS Interaction Examples . . . . . . . . . . . . . . . . . . 42
6.1. Starting an IVR dialog . . . . . . . . . . . . . . . . . . 42
6.2. IVR dialog fails to start . . . . . . . . . . . . . . . . 43
6.3. Preparing and starting an IVR dialog . . . . . . . . . . . 43
6.4. Terminating a dialog immediately . . . . . . . . . . . . . 45
6.5. Terminating a dialog non-immediately . . . . . . . . . . . 45
7. Template Dialog Examples . . . . . . . . . . . . . . . . . . . 47
7.1. playannouncement . . . . . . . . . . . . . . . . . . . . . 47
7.2. promptandcollect . . . . . . . . . . . . . . . . . . . . . 48
7.3. promptandrecord . . . . . . . . . . . . . . . . . . . . . 50
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 51
Boulton, et al. Expires May 5, 2008 [Page 2]
Internet-Draft Media Server Control Package November 2007
9. Security Considerations . . . . . . . . . . . . . . . . . . . 56
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
10.1. Control Package Registration . . . . . . . . . . . . . . . 57
10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 57
11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 58
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
13.1. Normative References . . . . . . . . . . . . . . . . . . . 61
13.2. Informative References . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . . . . 64
Boulton, et al. Expires May 5, 2008 [Page 3]
Internet-Draft Media Server Control Package November 2007
1. Introduction
The SIP Control Framework [SIPCF] provides a generic approach for
establishment and reporting capabilities of remotely initiated
commands. The Framework utilizes many functions provided by the
Session Initiation Protocol [RFC3261] (SIP) for the rendezvous and
establishment of a reliable channel for control interactions. The
Control Framework also introduces the concept of a Control Package.
A Control Package is an explicit usage of the Control Framework for a
particular interaction set. This specification defines a package for
basic IVR.
The scope of the package is control of media server functions for
basic interactive media (e.g. play a prompt, collecting DTMF,
recording user input) as well as notifications related to these
functions.
These functions and notifications are defined as messages in XML
[XML]. The message use XML elements for preparing, starting and
stopping dialogs, as well as elements for responses and notifications
([CCXML10], [MSML] and [MSCP]).
This basic IVR package uses template dialogs to provide IVR
functionality. Three basicivr template dialogs are defined:
playannouncement: a dialog to play one or more prompts to the user
promptandcollect: a dialog to prompt the user and collect their
input
promptandrecord: a dialog to prompt the user and record their input
Template dialogs are intended to provide basic IVR functionality
([H.248.9], [RFC4240], [MSML], [RFC2897] and [RFC4722]). The
template approach follows previous approaches in that it provides IVR
functionality which is commonly required for applications. It
differs in that the functionality is expressed in XML using a
reference to the template dialog, and parameters expressed in a
simple XML data structure. This is a lightweight approach since the
contents of the dialog itself does not need to be transported over
the control channel (or fetched from an external source), only a
template reference plus configuration data is required. From the
developer's perspective, this simplifies application development:
they do not need to write their IVR dialog using custom XML elements,
they only need to reference the template dialog and, if required,
populate a simple XML data structure to pass configuration data.
To use a template dialog, the AS developer references it by name in
Boulton, et al. Expires May 5, 2008 [Page 4]
Internet-Draft Media Server Control Package November 2007
an XML message for preparing or starting a dialog; for example
<dialogstart src="basicivr:promptandrecord"/>. The XML message may
also contain template input parameters in a <data> element to
configure specific behavior defined by the template dialog; e.g.
using "prompts" with the value "http://www.example.com/welcome.wav".
If the dialog starts successfully, a <response status="200"/> is
returned. When the dialog is completed, the MS returns template
output parameters in a dialogexit <event> notification to the AS.
The implementation of template dialogs requires only that they adhere
to the syntax and semantics of templates described in this document.
Other control packages MAY be defined which extend the capabilities
of the templates dialogs defined in this document. Such control
packages MUST respect the syntax and semantics of this control
package.
This document specifies how the basic IVR control package fulfils the
requirements of the SIP Control Framework control packages
(Section 3), which XML elements are defined by the package
(Section 4), the template dialog definitions (Section 5) as well as
providing examples (Section 6, Section 7) and an XML schema
(Section 8).
Boulton, et al. Expires May 5, 2008 [Page 5]
Internet-Draft Media Server Control Package November 2007
2. Conventions and Terminology
In this document, BCP 14/RFC 2119 [RFC2119] defines the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL". In addition, BCP 15 indicates requirement levels for
compliant implementations.
The following additional terms are defined for use in this document:
Dialog: A dialog performs media interaction with a user. A dialog
is identified by a URI and has an associated mimetype. Dialogs
typically feature basic capabilities such as playing audio
prompts, collecting DTMF input and recording audio input from the
user. More advanced dialogs may also feature synthesized speech,
recording and playback of video, recognition of spoken input, and
mixed initiative conversations.
Application server: A SIP [RFC3261] application server (AS) hosts
and executes services such as interactive media and conferencing
in an operator's network. An AS influences and impacts the SIP
session, in particular by terminating SIP sessions on a media
server, which is under its control.
Media Server: A media server (MS) processes media streams on behalf
of an AS by offering functionality such as interactive media,
conferencing, and transcoding to the end user. Interactive media
functionality is realized by way of dialogs, which are identified
by a URI and initiated by the application server.
Boulton, et al. Expires May 5, 2008 [Page 6]
Internet-Draft Media Server Control Package November 2007
3. Control Package Definition
This section fulfills the mandatory requirement for information that
MUST be specified during the definition of a Control Framework
Package, as detailed in Section 9 of [SIPCF].
3.1. Control Package Name
The Control Framework requires a Control Package definition to
specify and register a unique name and version.
The name and version of this Control Package is "msc-ivr-basic/1.0"
(Media Server Control - Interactive Voice Response - Basic - version
1.0 ).
3.2. Framework Message Usage
IVR functionality includes capabilities such as playing prompts,
collecting DTMF and recording user input. These functions are
expressed using template dialogs defined in Section 5.
This package defines XML elements in Section 4 and provides an XML
Schema in Section 8.
The XML elements in this package are split into requests, responses
and event notifications. Requests are carried in CONTROL message
bodies; <dialogprepare>, <dialogstart> and <dialogterminate> elements
are defined as package requests. Responses are carried either in
REPORT message or Control Framework 200 response bodies; the
<response> element is defined as a package response. Event
notifications are also carried in REPORT message bodies; the <event>
element is defined for package event notifications.
Note that package responses are different from framework response
codes. Framework error response codes (see Section 8 of [SIPCF]) are
used when the request or event notification is invalid; for example,
a request is invalid XML (400), or not understood (500). Package
responses are carried in 200 response or REPORT message bodies. This
package's response codes are defined in Section 4.2.1.
The schema uses "connection-id" and "conf-id" attributes which are
imported from schema defined in core Control Framework [SIPCF].
3.3. Common XML Support
The Control Framework requires a Control Package definition to
specify if the attributes for media dialog or conference references
are required.
Boulton, et al. Expires May 5, 2008 [Page 7]
Internet-Draft Media Server Control Package November 2007
This package requires that the XML Schema in Section 16.1 of [SIPCF]
MUST be supported for media dialogs and conferences.
3.4. CONTROL Message Body
A valid CONTROL body message MUST conform to the schema defined in
Section 8 and described in Section 4. XML messages appearing in
CONTROL messages MUST contain a <dialogprepare>, <dialogstart> or
<dialogterminate> request element (Section 4.1).
3.5. REPORT Message Body
A valid REPORT body MUST conform to the schema defined in Section 8
and described in Section 4. XML messages appearing in REPORT
messages MUST contain a <response> (Section 4.2), or a (notification)
<event> element (Section 4.3).
Boulton, et al. Expires May 5, 2008 [Page 8]
Internet-Draft Media Server Control Package November 2007
4. Element Definitions
This section defines the XML messages for this control package.
[Editors Note: since XML Schema may not be able to express all
constraints expressed in these definitions, in cases where there is a
difference in constraints, the definitions in the section take
priority.]
4.1. Requests
The following request elements are defined:
<dialogprepare>: prepare an IVR dialog for later execution
<dialogstart>: start an IVR dialog on a connection or conference
<dialogterminate>: terminate an active IVR dialog
4.1.1. <dialogprepare>
The <dialogprepare> request is sent from the AS to the MS to request
preparation of an IVR dialog. A prepared dialog is executed when the
AS sends a <dialogstart> request referencing the prepared dialog (see
Section 4.1.2).
A <dialogprepare> element has the following attributes:
src: string identifying the URI of the dialog document to prepare.
The attribute is mandatory. The MS MUST support "basicivr:
playannouncement", "basicivr:promptandcollect" and "basicivr:
promptandrecord" basicivr template dialogs as the value for this
attribute. The MS MAY support other URI formats.
dialogid: string indicating a unique name for the dialog. If this
attribute is not specified, the MS creates a unique name for the
dialog. The value is used in subsequent references to the dialog
(e.g. as dialogid in a <response>). It is an error if a dialog
with the same name already exists on the MS. The attribute is
optional.
The <dialogprepare> element has the following child elements:
<data>: an XML data structure (see Section 4.4) to pass parameters
into the dialog. It is an error if a specified parameter is not
supported by the implementation. The element is optional.
Boulton, et al. Expires May 5, 2008 [Page 9]
Internet-Draft Media Server Control Package November 2007
<subscribe>: an XML data structure (see Section 4.5) indicating
notification events to which the AS subscribes. It is an error if
a specified notification event is not supported by the
implementation. The element is optional.
For example, a request to prepare a playannouncement dialog where a
single prompt is played once:
<dialogprepare src="basicivr:playannouncement">
<data>
<item name="prompts"
value="http://www.example.com/prompt1.wav"/>
<item name="iterations" value="1"/>
</data>
</dialogprepare>
When an MS has successfully received a <dialogprepare> request, it
MUST reply with a <response> element (Section 4.2).
4.1.2. <dialogstart>
The <dialogstart> element is sent by the AS to request execution of a
dialog. The dialog may be defined in the dialogstart request itself,
or reference a previously prepared dialog.
The <dialogstart> element has the following attributes:
src: string identifying the URI of the dialog document to start.
The attribute is optional. The MS MUST support "basicivr:
playannouncement", "basicivr:promptandcollect" and "basicivr:
promptandrecord" basicivr template dialogs as the value for this
attribute. The MS MAY support other URI formats.
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.
connection-id: string identifying the SIP dialog connection on which
this dialog is to be started (see Section 16.1 of [SIPCF]). The
attribute is optional.
Boulton, et al. Expires May 5, 2008 [Page 10]
Internet-Draft Media Server Control Package November 2007
conf-id: string identifying the conference on which this dialog is
to be started (see Section 16.1 of [SIPCF]). The attribute is
optional.
If the prepareddialogid is specified, it is an error to specify the
src or dialogid attributes.
If the prepareddialogid is not specified, exactly the src attribute
MUST be specified; otherwise, it is an error.
Exactly one of the connection-id or conf-id attributes MUST be
specified. It is an error to specify both connection-id and conf-id.
The <dialogstart> element has the following child elements defined:
<stream>: contains the following attributes:
media: a string indicating the type of media associated with the
stream. It is strongly recommended that the following values
are used for common types of media: "audio" for audio media,
and "video" for video media. The attribute is mandatory.
label: a string indicating the SDP label associated with a media
stream ([RFC4574]). The attribute is optional.
direction: a string indicating the direction of the media flow
between a dialog and its end point conference or connection.
Defined values are: "sendrecv" (media can be sent and
received), "sendonly" (media can only be sent), and "recvonly"
(media can only be received). The default value is "sendrecv".
The attribute is optional.
One or more <stream> elements may be specified so that individual
media streams can be controlled independently; for example, audio
only for transmission, but video only for reception. The <stream>
element is optional. If no <stream> elements are specified, then
the default is the media configuration of the connection or
conference. It is an error if a <stream> element is in conflict
with (a) another <stream> element, (b) with dialog, connection or
conference media capabilities, or (c) with a SDP label value as
part of the connection-id (see Section 16.1 of [SIPCF]).
<data>: an XML data structure (see Section 4.4) to pass parameters
into the dialog. It is an error if a specified parameter is not
supported by the implementation. The element is optional.
Boulton, et al. Expires May 5, 2008 [Page 11]
Internet-Draft Media Server Control Package November 2007
<subscribe>: an XML data structure (see Section 4.5) indicating
notification events to which the AS subscribes. It is an error if
a specified notification event is not supported by the
implementation.The element is optional.
[Editors Note: the <stream> element assumes that the use of the SDP
label by itself is insufficent for media stream control. In
particular, the SDP label does not address directionality, nor does
it address conferences. Further investigation of the <stream> is is
required.]
If the prepareddialogid is specified and the <dialogprepare>
contained a <data> element, it is an error to specify it in
<dialogstart>. Likewise, If the prepareddialogid is specified and
the <dialogprepare> contained a <subscribe> element, it is an error
to specify it in <dialogstart>.
For example, a request to start a promptandrecord template dialog on
a conference:
<dialogstart conf-id="conference11" src="basicivr:playandrecord">
<data>
<item name="maxtime" value="384000s"/>
</data>
</dialogstart>
When an MS has successfully received a <dialogstart> request, it MUST
reply with a <response> element (Section 4.2).
4.1.3. <dialogterminate>
A dialog that has been successfully prepared or started can be
terminated by a <dialogterminate> request element from the AS.
The <dialogterminate> element has the following attributes:
dialogid: string identifying an existing dialog. The attribute is
mandatory.
immediate: string with the values "true" or "false" indicating
whether the dialog is to be terminated immediately or not. If a
dialog is terminated immediately, no further dialog event
notifications are sent (including a dialogexit <event>). The
default is "false". The attribute is optional.
For example, assuming a dialog with the dialogid "vxi1" has been
started, it can be terminated immediately with the following request:
Boulton, et al. Expires May 5, 2008 [Page 12]
Internet-Draft Media Server Control Package November 2007
<dialogterminate dialogid="vxi1" immediate="true"/>
When an MS has successfully received a <dialogterminate> request, it
MUST reply with a <response> element (Section 4.2).
4.2. Responses
Responses are specified in a <response> element.
4.2.1. <response>
Reponses to requests are indicated by a <response> element.
The <response> element has following attributes:
status: numeric code indicating the response status. The attribute
is mandatory.
reason: string specifying a reason for the response status. The
attribute is optional.
dialogid: string identifying the dialog. The attribute is optional.
connection-id: string identifying the SIP dialog connection
associated with the dialog (see Section 16.1 of [SIPCF]). The
attribute is optional.
conf-id: string identifying the conference associated with the
dialog (see Section 16.1 of [SIPCF]). The attribute is optional.
The following status codes are defined:
Boulton, et al. Expires May 5, 2008 [Page 13]
Internet-Draft Media Server Control Package November 2007
+-----------+-------------------------------------------------------+
| code | description |
+-----------+-------------------------------------------------------+
| 200 | OK |
| | |
| 401 | dialogid already exists |
| | |
| 402 | dialogid does not exist |
| | |
| 403 | connection-id does not exist |
| | |
| 404 | conf-id does not exist |
| | |
| 405 | Unknown or unsupported element |
| | |
| 406 | Element required |
| | |
| 407 | Unknown or unsupported attribute |
| | |
| 408 | Attribute required |
| | |
| 409 | template dialog not supported |
| | |
| 410 | data parameter not supported |
| | |
| 411 | event subscription not supported |
| | |
| 412 | stream parameter invalid |
| | |
| 499 | other error |
+-----------+-------------------------------------------------------+
Table 1: <response> status codes
[Editors Note: more status codes may need to be defined.]
For example, a response when a dialog was prepared successfully:
<response status="200" dialogid="vxi1"/>
The response if dialog preparation failed due to an unknown template:
<response status="409" dialogid="vxi1"
reason="Unknown template: promptandrecod"/>
For example, a response when the dialog was started successfully.
<response status="200" dialogid="vxi1"
Boulton, et al. Expires May 5, 2008 [Page 14]
Internet-Draft Media Server Control Package November 2007
connection-id="7HDY839~HJKSkyHS"/>
4.3. Notifications
Event notifications are specified in an <event> element.
4.3.1. <event>
Dialog event notifications are either manual or automatic.
Manual event notifications are defined when an AS subscribes to
notifications for dialog events using the <subscribe> element of
<dialogprepare> or <dialogstart>.
Automatic event notifications are defined as part of a Control
Package. The AS SHOULD NOT subscribe to these event notifications.
The MS MUST support these event notifications. This package defines
one automatic notification event: "dialogexit" which indicates that
an active dialog has terminated. Note that this notification is not
sent if the dialog has been terminated by the AS using a
<dialogterminate/> request where "immediate=true".
When a dialog generates a notification event, the MS sends the event
to the AS using an <event> element.
The <event> element has the following attributes:
name: string indicating the name of dialog event. The string is
restricted to a sequence of alphanumeric or "." characters. The
attribute is mandatory.
dialogid: string identifying the dialog. The attribute is
mandatory.
The <event> element has the following child element:
<data>: an XML data structure (see Section 4.4) to pass information
additional information about the dialog event. The element is
optional.
For example, when a dialog exits the MS may send a dialogexit <event>
with data indicating the status of a template dialog:
<event name="dialogexit" dialogid="vxi1">
<data>
<item name="status" value="1"/>
</data>
</event>
Boulton, et al. Expires May 5, 2008 [Page 15]
Internet-Draft Media Server Control Package November 2007
4.4. <data>
The <data> element is a general container for parameterized data.
The <data> element has no attributes, but has the following child
elements defined:
<item>: contains the following attributes:
name: a string indicating the name of the parameter. The
attribute is mandatory.
value: a string indicating the value of the parameter. Multiple
values of a parameters can be specified using space separation.
The attribute is mandatory.
Multiple <item> elements may be specified.
For example, a <data> specifying promptandcollect template parameters
with simple values:
<data>
<item name="iterations" value="5"/>
<item name="timeout" value="10s"/>
</data>
In this example, a <data> specifying a playannouncement template with
a complex value for the prompts parameter:
<data>
<item name="prompts" value="http://example.com/balance.wav
http://example.com/five.wav http://example.com/euros.wav"/>
</data>
[Editors Note: we may also want to investigate the use of <item>s
nested within a top-level <item> to specify complex values. ]
4.5. <subscribe>
The <subscribe> element is a container for specifying dialog
notification events to which an AS subscribes. Notifications of
dialog events are delivered using the <event> element (see
Section 4.3.1).
The <subscribe> element has no attributes, but has the following
child elements defined:
Boulton, et al. Expires May 5, 2008 [Page 16]
Internet-Draft Media Server Control Package November 2007
<notify>: contains the following attributes:
name: a string indicating the name of the event to be notified
of. The attribute is mandatory.
The <notify> element may have a <data> child element.
Multiple <notify> elements may be specified.
For example, the AS wishes to subscribe to DTMF and bargein
notification events associated with a dialog:
<dialogstart src="basicivr:promptandcollect"
connection-id="7HDY839~HJKSkyHS~HUwkuh7ns">
<subscribe>
<notify name="dtmf"/>
<notify name="bargein"/>
</subscribe>
</dialogstart>
If the MS supports these notification events, then it would use the
<event> element to send notifications during the dialog to the AS
when the events occured.
[Editors Note: It may be possible to define a general event
subscription mechanism as part of the SIP Control Framework.]
[Editors Note: This Control Package does not specify dialog
notification events apart from "dialogexit". Later versions may
define events such as: "dtmf" (a DTMF key is pressed), "mediastart"
(media playback started), "bargein" (user has barged in on a prompt),
and "rtpcontrol" (control data, e.g. VFU, PoC, etc, is received over
the RTP control channel.]
Boulton, et al. Expires May 5, 2008 [Page 17]
Internet-Draft Media Server Control Package November 2007
5. IVR Template Dialogs
The execution of IVR template dialog takes place on the MS. The AS
specifies the name of the template and configuration parameters, and
receives the result from the MS after the dialog has been executed.
Input parameters are used to configure and customize the behavior of
the template. For many input parameters, the templates provide
default values; a developer can specify an alternative value if the
default is not appropriate for their application. Input parameters
for templates may be mandatory, requiring a specific value to be
provided.
The result of executing a template dialog is reported to the AS using
output parameters. These parameters may describe status information,
error information or information collected from the user. Output
parameters are mandatory or optional depending on the specific
template; mandatory parameters must be specified by the
implementation.
Template dialogs are invoked by referencing them in the src attribute
of <dialogprepare> (Section 4.1.1) or <dialogstart> (Section 4.1.2).
Input parameters are specified in the <data> child element
(Section 4.4) of these elements. Output parameters are specified in
the <data> child element of a dialogexit <event> notification
(Section 4.3.1). The detailed mapping of template dialogs to XML
CONTROL and REPORT messages is described in Section 3 and examples
are provided in Section 7.
The implementation of template dialogs MUST adhere to the syntax and
semantics of templates described in this document. Implementations
MAY support additional parameters of the defined template dialogs.
Implementations MAY support additional template dialogs. The actual
implementation may be based on any technology or scripting language.
The media requirements on the template implementation are restricted
to the capability to play audio prompts (specified as URIs), collect
DTMF input, and record audio input. The implementation MUST support
G.711 audio formats (headerless and wav) for playback and recording.
The implementation MAY support other media formats.
[Editors Note: Later versions may consider additional media
requirements including TTS, ASR, video, etc. ]
5.1. Play Announcement
A template dialog to play announcements to the user.
Boulton, et al. Expires May 5, 2008 [Page 18]
Internet-Draft Media Server Control Package November 2007
The template dialog is invoked using the URI "playannouncement".
The dialog execution model consists of:
1. Playing prompts in the order specified until completion.
2. Repeating step 1 for the value of iterations.
3. Returning status and reason parameters.
The input and output parameters are summarized and defined below.
+------------+-----------+-------------------------+------------+
| Name | Direction | Description | Definition |
+------------+-----------+-------------------------+------------+
| prompts | input | prompts to play | Table 3 |
| | | | |
| iterations | input | maximum iterations | Table 4 |
| | | | |
| status | output | status code | Table 5 |
| | | | |
| reason | output | reason for status | Table 6 |
+------------+-----------+-------------------------+------------+
Table 2: playannouncement parameter overview
Note that playannouncement requires at least one prompt specified in
prompts.
+-------------+-----------------------------------------------------+
| Name | prompts |
+-------------+-----------------------------------------------------+
| Description | One or more prompts to play |
| | |
| Direction | input |
| | |
| Type | URIList |
| | |
| Optional | No |
| | |
| Possible | A valid URIList which is non-empty |
| Values | |
| | |
| Default | none |
+-------------+-----------------------------------------------------+
Table 3: prompts
Boulton, et al. Expires May 5, 2008 [Page 19]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | iterations |
+-------------+-----------------------------------------------------+
| Description | Maximum number of times the playannouncement dialog |
| | is to be played |
| | |
| Direction | input |
| | |
| Type | Non-Negative Integer |
| | |
| Optional | Yes |
| | |
| Possible | A valid non-negative integer. A value of 0 |
| Values | indicates that the dialog is repeated until halted |
| | by other means. |
| | |
| Default | 1 |
+-------------+-----------------------------------------------------+
Table 4: iterations
+-------------+-----------------------------------------------------+
| Name | status |
+-------------+-----------------------------------------------------+
| Description | A status code indicating success or failure of the |
| | playannouncement dialog |
| | |
| Direction | output |
| | |
| Type | Non-Negative Integer |
| | |
| Optional | No |
| | |
| Possible | 1 for success; otherwise an error code (600, 601, |
| Values | 602). See Table 37 |
| | |
| Default | none |
+-------------+-----------------------------------------------------+
Table 5: status
Boulton, et al. Expires May 5, 2008 [Page 20]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | reason |
+-------------+-----------------------------------------------------+
| Description | A textual description providing a reason for the |
| | status code; e.g. details about an error |
| | |
| Direction | output |
| | |
| Type | String |
| | |
| Optional | Yes |
| | |
| Possible | A valid String value |
| Values | |
| | |
| Default | Empty string |
+-------------+-----------------------------------------------------+
Table 6: reason
The following additional input parameters are under consideration for
later versions:
+---------------+---------------------------------------------------+
| Name | Description |
+---------------+---------------------------------------------------+
| duration | maximum duration for the dialog including |
| | iterations |
| | |
| interval | time to elapse between successive iterations |
| | |
| audiomaxage | maxage cache control for prompts |
| | |
| audiomaxstale | maxstale cache control for prompts |
| | |
| speed | playback speed for prompts |
| | |
| volume | playback volume for prompts |
| | |
| offset | play from offset in prompts |
| | |
| variables | references to common types such as money, time, |
| | numbers, etc |
+---------------+---------------------------------------------------+
Table 7: Additional playannouncement parameters
Boulton, et al. Expires May 5, 2008 [Page 21]
Internet-Draft Media Server Control Package November 2007
5.2. Prompt and Collect
A template dialog to play prompts and collect DTMF input.
The dialog is invoked with the URI "promptandcollect".
The dialog execution model consists of:
1. Clearing the digit buffer depending on the value of
cleardigitbuffer.
2. Playing prompts in the order specified. The bargein parameter
determines whether user input can be collected during prompt
playback stops (if so, prompt playback is stopped).
3. Collecting DTMF input from the user. Valid DTMF patterns are
either a simple digit string where the maximum length is
determined by maxdigits and may be terminated by the character in
termchar; or a custom DTMF grammar specified by grammar. The
parameters timeout, interdigittimeout and termtimeout control
user input timeout, interdigit timeout and the terminating
timeout respectively.
4. If no input is collected or the input is invalid, steps 1 - 3 are
repeated for the value of iterations.
5. Returning status, reason and result parameters.
The input and output parameter are summarized and defined below.
Boulton, et al. Expires May 5, 2008 [Page 22]
Internet-Draft Media Server Control Package November 2007
+-------------------+-----------+----------------------+------------+
| Name | Direction | Description | Definition |
+-------------------+-----------+----------------------+------------+
| prompts | input | prompts to play | Table 9 |
| | | | |
| iterations | input | maximum attempts | Table 10 |
| | | | |
| cleardigitbuffer | input | dtmf buffer clearing | Table 11 |
| | | | |
| bargein | input | interruption of | Table 12 |
| | | prompts | |
| | | | |
| timeout | input | timeout for user | Table 13 |
| | | input | |
| | | | |
| interdigittimeout | input | timeout between | Table 14 |
| | | digits | |
| | | | |
| termtimeout | input | terminating timeout | Table 15 |
| | | | |
| termchar | input | terminating | Table 16 |
| | | character | |
| | | | |
| maxdigits | input | maximum number of | Table 17 |
| | | digits | |
| | | | |
| grammar | input | custom grammar | Table 18 |
| | | | |
| status | output | status code | Table 19 |
| | | | |
| reason | output | reason for status | Table 20 |
| | | | |
| result | output | input collected | Table 21 |
+-------------------+-----------+----------------------+------------+
promptandcollect parameter overview
Boulton, et al. Expires May 5, 2008 [Page 23]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | prompts |
+-------------+-----------------------------------------------------+
| Description | Initial prompts to play |
| | |
| Direction | input |
| | |
| Type | URIList |
| | |
| Optional | Yes |
| | |
| Possible | A valid URIList |
| Values | |
| | |
| Default | none |
+-------------+-----------------------------------------------------+
Table 9: prompts
+-------------+-----------------------------------------------------+
| Name | iterations |
+-------------+-----------------------------------------------------+
| Description | Maximum number of times the promptandcollect dialog |
| | is to be played |
| | |
| Direction | input |
| | |
| Type | Non-Negative Integer |
| | |
| Optional | Yes |
| | |
| Possible | A valid non-negative integer. A value of 0 |
| Values | indicates the dialog is repeated until halted by |
| | other means. |
| | |
| Default | 0 |
+-------------+-----------------------------------------------------+
Table 10: iterations
Boulton, et al. Expires May 5, 2008 [Page 24]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | cleardigitbuffer |
+-------------+-----------------------------------------------------+
| Description | Clear digit buffer prior to prompt playback |
| | |
| Direction | input |
| | |
| Type | Boolean |
| | |
| Optional | Yes |
| | |
| Possible | A valid boolean value. A value of true indicates |
| Values | that the digitbuffer is to be cleared. A value of |
| | false indicates that the digitbuffer is not to be |
| | cleared. |
| | |
| Default | true |
+-------------+-----------------------------------------------------+
Table 11: cleardigitbuffer
+-------------+-----------------------------------------------------+
| Name | bargein |
+-------------+-----------------------------------------------------+
| Description | Indicates whether the user can interrupt the prompt |
| | with their input |
| | |
| Direction | input |
| | |
| Type | Boolean |
| | |
| Optional | Yes |
| | |
| Possible | A valid boolean value. A value of true indicates |
| Values | that bargein is permitted. A value of false |
| | indicates that bargein is not permitted. |
| | |
| Default | true |
+-------------+-----------------------------------------------------+
Table 12: bargein
Boulton, et al. Expires May 5, 2008 [Page 25]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | timeout |
+-------------+-----------------------------------------------------+
| Description | Indicates the time to wait for user input |
| | |
| Direction | input |
| | |
| Type | Time Designation |
| | |
| Optional | Yes |
| | |
| Possible | A valid TimeDesignation value. |
| Values | |
| | |
| Default | 5s |
+-------------+-----------------------------------------------------+
Table 13: timeout
+-------------+-----------------------------------------------------+
| Name | interdigittimeout |
+-------------+-----------------------------------------------------+
| Description | The inter-digit timeout value to use when |
| | recognizing DTMF input |
| | |
| Direction | input |
| | |
| Type | Time Designation |
| | |
| Optional | Yes |
| | |
| Possible | A valid TimeDesignation value. |
| Values | |
| | |
| Default | 2s |
+-------------+-----------------------------------------------------+
Table 14: interdigittimeout
Boulton, et al. Expires May 5, 2008 [Page 26]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | termtimeout |
+-------------+-----------------------------------------------------+
| Description | The terminating timeout to use when recognizing |
| | DTMF input |
| | |
| Direction | input |
| | |
| Type | Time Designation |
| | |
| Optional | Yes |
| | |
| Possible | A valid TimeDesignation value. |
| Values | |
| | |
| Default | 0s |
+-------------+-----------------------------------------------------+
Table 15: termtimeout
+-------------+-----------------------------------------------------+
| Name | termchar |
+-------------+-----------------------------------------------------+
| Description | The terminating DTMF character for DTMF input |
| | recognition. This parameter is ignored if the |
| | grammar parameter is specified. |
| | |
| Direction | input |
| | |
| Type | DTMFChar |
| | |
| Optional | Yes |
| | |
| Possible | A valid DTMFChar value. To disable termination by |
| Values | a conventional DTMF character, set the parameter to |
| | an unconventional character like 'A'. |
| | |
| Default | # |
+-------------+-----------------------------------------------------+
Table 16: termchar
Boulton, et al. Expires May 5, 2008 [Page 27]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | maxdigits |
+-------------+-----------------------------------------------------+
| Description | The maximum number of digits to collect using an |
| | internal digits (0-9 only) grammar. This parameter |
| | is ignored if the grammar parameter is specified. |
| | |
| Direction | input |
| | |
| Type | Positive Integer |
| | |
| Optional | Yes |
| | |
| Possible | A valid positive integer value. |
| Values | |
| | |
| Default | 5 |
+-------------+-----------------------------------------------------+
Table 17: maxdigits
+-------------+-----------------------------------------------------+
| Name | grammar |
+-------------+-----------------------------------------------------+
| Description | A URI reference to a custom DTMF grammar. If this |
| | parameter is specified, then the referenced DTMF |
| | grammar is used instead of the internal digits |
| | grammar (i.e. maxdigits and termchar are ignored |
| | even if specified). Custom grammars permit the |
| | full range of DTMF characters including '*' and '#' |
| | to be specified for DTMF pattern matching. |
| | |
| Direction | input |
| | |
| Type | URI |
| | |
| Optional | Yes |
| | |
| Possible | A valid URI value referencing a valid custom DTMF |
| Values | grammar. |
| | |
| Default | none |
+-------------+-----------------------------------------------------+
Table 18: grammar
[Editors note: The format of the custom DTMF grammar is not yet
defined. Possibilities include: [SRGS], [H.248.1], and [RFC4730].
Boulton, et al. Expires May 5, 2008 [Page 28]
Internet-Draft Media Server Control Package November 2007
If more than one format is permitted, then an additional input
parameter "grammartype" would indicate the format used in the grammar
parameter.]
+-------------+-----------------------------------------------------+
| Name | status |
+-------------+-----------------------------------------------------+
| Description | A status code indicating success or failure of the |
| | promptandcollect dialog |
| | |
| Direction | output |
| | |
| Type | Non-Negative Integer |
| | |
| Optional | No |
| | |
| Possible | 1 for success; otherwise an error code (600, 601, |
| Values | 603). See Table 37 |
| | |
| Default | none |
+-------------+-----------------------------------------------------+
Table 19: status
+-------------+-----------------------------------------------------+
| Name | reason |
+-------------+-----------------------------------------------------+
| Description | A textual description providing a reason for the |
| | status code; e.g. details on an error |
| | |
| Direction | output |
| | |
| Type | String |
| | |
| Optional | Yes |
| | |
| Possible | A valid String value |
| Values | |
| | |
| Default | Empty string |
+-------------+-----------------------------------------------------+
Table 20: reason
Boulton, et al. Expires May 5, 2008 [Page 29]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | result |
+-------------+-----------------------------------------------------+
| Description | The DTMF input collected from the user. |
| | |
| Direction | output |
| | |
| Type | DTMFString |
| | |
| Optional | The parameter is mandatory if status is 1; |
| | otherwise, optional. |
| | |
| Possible | A valid DTMFString (no spaces between characters). |
| Values | |
| | |
| Default | Empty String |
+-------------+-----------------------------------------------------+
Table 21: result
In addition to the prompt extensions described in Table 7, the
following parameters are under consideration for later versions:
+--------------------+----------------------------------------------+
| Name | Description |
+--------------------+----------------------------------------------+
| nomatchprompts | prompts to play when input doesn't match the |
| | DTMF grammar |
| | |
| noinputprompts | prompts to play when there is no user input |
| | |
| successprompts | prompts to play when user input is collected |
| | |
| failureprompts | prompts to play when no valid user input has |
| | been collected after all iterations tried |
| | |
| escapechar | character which causes the dialog to restart |
| | without incrementing the iterations counter |
| | |
| iterationcount | number of iterations (output) |
| | |
| promptplayedamount | duration of initial prompts played if prompt |
| | interrupted (output) |
+--------------------+----------------------------------------------+
Boulton, et al. Expires May 5, 2008 [Page 30]
Internet-Draft Media Server Control Package November 2007
5.3. Prompt and Record
A template dialog to prompt the user and record their audio (or other
media) input.
The dialog is invoked with the URI "promptandrecord".
The dialog execution model consists of:
1. Playing prompts in the order specified until completion.
2. Recording input from the user in the mimetype format. Recording
is initiated if user input is received before timeout expires.
The recording is terminated by DTMF input, the maximum duration
being exceeded or a final silence after recording, as specified
in dtmfterm, maxtime and finalsilence parameters respectively.
Use of VAD (Voice Activity Detection) to initiate and terminate
recording is controlled by vadinitial and vadfinal respectively.
3. If recording is not initiated, steps 1 - 2 are repeated for the
value of iterations.
4. Returning status, reason and result parameters.
The input and output parameter are summarized and defined below.
Boulton, et al. Expires May 5, 2008 [Page 31]
Internet-Draft Media Server Control Package November 2007
+--------------+-----------+---------------------------+------------+
| Name | Direction | Description | Definition |
+--------------+-----------+---------------------------+------------+
| prompts | input | prompts to play | Table 24 |
| | | | |
| iterations | input | maximum attempts | Table 25 |
| | | | |
| timeout | input | timeout to wait for input | Table 26 |
| | | | |
| mimetype | input | mimetype of the recording | Table 27 |
| | | | |
| vadinitial | input | whether VAD is used to | Table 28 |
| | | initiate recording | |
| | | | |
| vadfinal | input | whether VAD is used to | Table 29 |
| | | terminate recording | |
| | | | |
| dtmf | input | recording terminated by | Table 30 |
| | | DTMF | |
| | | | |
| maxtime | input | maximum duration of | Table 31 |
| | | recording | |
| | | | |
| finalsilence | input | final silence to | Table 32 |
| | | terminate recording | |
| | | | |
| status | output | status code | Table 33 |
| | | | |
| reason | output | reason for status | Table 34 |
| | | | |
| result | output | URI for recording | Table 35 |
+--------------+-----------+---------------------------+------------+
Boulton, et al. Expires May 5, 2008 [Page 32]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | prompts |
+-------------+-----------------------------------------------------+
| Description | Initial prompts to play |
| | |
| Direction | input |
| | |
| Type | URIList |
| | |
| Optional | Yes |
| | |
| Possible | A valid URIList |
| Values | |
| | |
| Default | none |
+-------------+-----------------------------------------------------+
Table 24: prompts
+-------------+-----------------------------------------------------+
| Name | iterations |
+-------------+-----------------------------------------------------+
| Description | Maximum number of times the promptandrecord dialog |
| | is to be played |
| | |
| Direction | input |
| | |
| Type | Non-Negative Integer |
| | |
| Optional | Yes |
| | |
| Possible | A valid non-negative integer. A value of 0 |
| Values | indicates that the dialog is repeated until halted |
| | by other means. |
| | |
| Default | 0 |
+-------------+-----------------------------------------------------+
Table 25: iterations
Boulton, et al. Expires May 5, 2008 [Page 33]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | timeout |
+-------------+-----------------------------------------------------+
| Description | Indicates the time to wait for user input. |
| | |
| Direction | input |
| | |
| Type | Time Designation |
| | |
| Optional | Yes |
| | |
| Possible | A valid TimeDesignation value. |
| Values | |
| | |
| Default | 5s |
+-------------+-----------------------------------------------------+
Table 26: timeout
+-------------+-----------------------------------------------------+
| Name | mimetype |
+-------------+-----------------------------------------------------+
| Description | The media format of the resulting recording. |
| | |
| Direction | input |
| | |
| Type | mimetype |
| | |
| Optional | Yes |
| | |
| Possible | A valid mimetype value. |
| Values | |
| | |
| Default | None |
+-------------+-----------------------------------------------------+
Table 27: mimetype
Boulton, et al. Expires May 5, 2008 [Page 34]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | vadinitial |
+-------------+-----------------------------------------------------+
| Description | Control whether voice activity detection can be |
| | used to initiate recording |
| | |
| Direction | input |
| | |
| Type | Boolean |
| | |
| Optional | Yes |
| | |
| Possible | A valid Boolean value. A value of true indicates |
| Values | recording may be initiated using voice activity |
| | detection. A value of false indicates that |
| | recording must not be initiated using voice |
| | activity detection. |
| | |
| Default | true |
+-------------+-----------------------------------------------------+
Table 28: vadinitial
+-------------+-----------------------------------------------------+
| Name | vadfinal |
+-------------+-----------------------------------------------------+
| Description | Control whether voice activity detection can be |
| | used to terminate recording |
| | |
| Direction | input |
| | |
| Type | Boolean |
| | |
| Optional | Yes |
| | |
| Possible | A valid Boolean value. A value of true indicates |
| Values | recording may be terminated using voice activity |
| | detection. A value of false indicates that |
| | recording must not be terminated using voice |
| | activity detection. |
| | |
| Default | true |
+-------------+-----------------------------------------------------+
Table 29: vadfinal
Boulton, et al. Expires May 5, 2008 [Page 35]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | dtmfterm |
+-------------+-----------------------------------------------------+
| Description | Indicates whether recording can be terminated by |
| | DTMF input |
| | |
| Direction | input |
| | |
| Type | Boolean |
| | |
| Optional | Yes |
| | |
| Possible | A valid Boolean value. A value of true indicates |
| Values | that recording can be terminated by DTMF. A value |
| | of false indicates that recording cannot be |
| | terminated by DTMF. |
| | |
| Default | true |
+-------------+-----------------------------------------------------+
Table 30: dtmfterm
+-------------+-----------------------------------------------------+
| Name | maxtime |
+-------------+-----------------------------------------------------+
| Description | The maximum duration of the recording |
| | |
| Direction | input |
| | |
| Type | Time Designation |
| | |
| Optional | Yes |
| | |
| Possible | A valid TimeDesignation value. |
| Values | |
| | |
| Default | 15s |
+-------------+-----------------------------------------------------+
Table 31: maxtime
Boulton, et al. Expires May 5, 2008 [Page 36]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | finalsilence |
+-------------+-----------------------------------------------------+
| Description | The interval of silence that indicates end of |
| | speech. This parameter is ignored if vadfinal has |
| | the value false. |
| | |
| Direction | input |
| | |
| Type | Time Designation |
| | |
| Optional | Yes |
| | |
| Possible | A valid TimeDesignation value. |
| Values | |
| | |
| Default | 5s |
+-------------+-----------------------------------------------------+
Table 32: finalsilence
+-------------+-----------------------------------------------------+
| Name | status |
+-------------+-----------------------------------------------------+
| Description | A status code indicating success or failure of the |
| | promptandrecord dialog |
| | |
| Direction | output |
| | |
| Type | Non-Negative Integer |
| | |
| Optional | No |
| | |
| Possible | 1 for success; otherwise an error code (600, 601, |
| Values | 603). See Table 37 |
| | |
| Default | none |
+-------------+-----------------------------------------------------+
Table 33: status
Boulton, et al. Expires May 5, 2008 [Page 37]
Internet-Draft Media Server Control Package November 2007
+-------------+-----------------------------------------------------+
| Name | reason |
+-------------+-----------------------------------------------------+
| Description | A textual description providing a reason for the |
| | status code; e.g. details on an error |
| | |
| Direction | output |
| | |
| Type | String |
| | |
| Optional | Yes |
| | |
| Possible | A valid String value |
| Values | |
| | |
| Default | Empty string |
+-------------+-----------------------------------------------------+
Table 34: reason
+-------------+-----------------------------------------------------+
| Name | result |
+-------------+-----------------------------------------------------+
| Description | A URI referencing the media recording |
| | |
| Direction | output |
| | |
| Type | URI |
| | |
| Optional | The parameter is mandatory if status is 1; |
| | otherwise, optional. |
| | |
| Possible | A valid URI value |
| Values | |
| | |
| Default | Empty string |
+-------------+-----------------------------------------------------+
Table 35: result
In addition to the prompt extensions described in Table 7, the
following additional parameters are under consideration for a later
version.
Boulton, et al. Expires May 5, 2008 [Page 38]
Internet-Draft Media Server Control Package November 2007
+--------------------+----------------------------------------------+
| Name | Description |
+--------------------+----------------------------------------------+
| destination | URI to send recording using HTTP |
| | |
| beep | indicates whether a platform-specific beep |
| | is used immediately prior to recording |
| | |
| noinputprompts | prompts to play when there is no user input |
| | |
| successprompts | prompts to play when recording is successful |
| | |
| failureprompts | prompts to play when no recording has been |
| | made after all the iterations tried |
| | |
| duration | duration of the recording (output) |
| | |
| mimetype | mimetype of the recording (output) |
| | |
| iterationcount | number of iterations (output) |
| | |
| terminationmode | indication of why recording terminated: e.g. |
| | dtmf, maxtime reached, externalevent or |
| | finalsilence detected (output) |
| | |
| promptplayedamount | duration of initial prompts played if prompt |
| | interrupted (output) |
+--------------------+----------------------------------------------+
5.4. Status Codes
The following table describes the codes returned in the status output
parameter for template dialogs.
Boulton, et al. Expires May 5, 2008 [Page 39]
Internet-Draft Media Server Control Package November 2007
+-----------+-------------------------------------------------------+
| status | description |
+-----------+-------------------------------------------------------+
| 0 | dialog terminated externally |
| | |
| 1 | success |
| | |
| 600 | unspecified error |
| | |
| 601 | invalid input parameter |
| | |
| 602 | no prompts defined (only playannouncement) |
| | |
| 603 | maximum iterations reached without valid input (not |
| | playannouncement) |
+-----------+-------------------------------------------------------+
Table 37: status codes for all templates dialogs
5.5. Type Definitions
This section defines types referenced in template parameters.
5.5.1. Boolean
The value space of boolean is the set {true, false}.
5.5.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}.
5.5.3. DTMFString
A String composed of one or more DTMFChars.
5.5.4. Non-Negative Integer
The value space of non-negative integer is the infinite set
{0,1,2,...}.
5.5.5. Positive Integer
The value space of positive integer is the infinite set {1,2,...}.
Boulton, et al. Expires May 5, 2008 [Page 40]
Internet-Draft Media Server Control Package November 2007
5.5.6. String
A string in the character encoding associated with the XML element.
5.5.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".
5.5.8. URI
Uniform Resource Indicator as defined in [RFC2396].
5.5.9. URIList
A list of URIs.
5.5.10. mimetype
A string formated as a IANA mimetype.
Boulton, et al. Expires May 5, 2008 [Page 41]
Internet-Draft Media Server Control Package November 2007
6. AS-MS Interaction Examples
The following example assume a control channel has been established
as described in the SIP Control Framework [SIPCF].
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: (pending) |
| <---------------------------------------- |
| |
| (4) 200 |
| ----------------------------------------> |
| |
| (5) REPORT: <response status="200"/> |
| (terminate) |
| <---------------------------------------- |
| |
| (6) 200 |
| ----------------------------------------> |
| |
| (7) REPORT:<event name="dialogexit"/> |
| (notify) |
| <---------------------------------------- |
| |
| (8) 200 |
| ----------------------------------------> |
| |
Boulton, et al. Expires May 5, 2008 [Page 42]
Internet-Draft Media Server Control Package November 2007
6.2. IVR dialog fails to start
An IVR dialog fails to start due to an unknown template.
Application Server (AS) Media Server (MS)
| |
| (1) CONTROL: <dialogstart> |
| ----------------------------------------> |
| |
| (2) 202 |
| <--------------------------------------- |
| |
| (3) REPORT: (pending) |
| <---------------------------------------- |
| |
| (4) 200 |
| ----------------------------------------> |
| |
| (5) REPORT: <response status="409"/> |
| (terminate) |
| <---------------------------------------- |
| |
| (6) 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 May 5, 2008 [Page 43]
Internet-Draft Media Server Control Package November 2007
Application Server (AS) Media Server (MS)
| |
| (1) CONTROL: <dialogprepare> |
| ----------------------------------------> |
| |
| (2) 202 |
| <--------------------------------------- |
| |
| (3) REPORT: (pending) |
| <---------------------------------------- |
| |
| (4) 200 |
| ----------------------------------------> |
| |
| (5) REPORT: <response status="200"/> |
| (terminate) |
| <---------------------------------------- |
| |
| (6) 200 |
| ----------------------------------------> |
| |
| (7) CONTROL: <dialogstart> |
| ----------------------------------------> |
| |
| (8) 202 |
| <--------------------------------------- |
| |
| (9) REPORT: (pending) |
| <---------------------------------------- |
| |
| (10) 200 |
| ---------------------------------------> |
| |
| (11) REPORT: <response status="200"/> |
| (terminate) |
| <---------------------------------------- |
| |
| (12) 200 |
| ----------------------------------------> |
| |
| (13) REPORT:<event name="dialogexit"/>|
| (notify) |
| <---------------------------------------- |
| |
| (14) 200 |
| ----------------------------------------> |
| |
Boulton, et al. Expires May 5, 2008 [Page 44]
Internet-Draft Media Server Control Package November 2007
6.4. Terminating a dialog immediately
An IVR dialog is started successfully, and then terminated
immediately by the AS. No dialog notification <event>s are sent back
to the AS.
Application Server (AS) Media Server (MS)
| |
| (1) CONTROL: <dialogstart> |
| ----------------------------------------> |
| |
| (2) 202 |
| <--------------------------------------- |
| |
| (3) REPORT: (pending) |
| <---------------------------------------- |
| |
| (4) 200 |
| ----------------------------------------> |
| |
| (5) REPORT: <response status="200"/> |
| (terminate) |
| <---------------------------------------- |
| |
| (6) 200 |
| ----------------------------------------> |
| |
| (7) CONTROL: <dialogterminate> |
| ----------------------------------------> |
| |
| (8) 200: <response status="200"/> |
| <---------------------------------------- |
| |
Note that in (8) the response to the <dialogterminate/> request is
carried on a framework 200 response.
6.5. Terminating a dialog non-immediately
An IVR dialog is started successfully, and then terminated non-
immediately by the AS, allowing the MS to send a dialogexit
notification <event> with information collected during the dialog.
Boulton, et al. Expires May 5, 2008 [Page 45]
Internet-Draft Media Server Control Package November 2007
Application Server (AS) Media Server (MS)
| |
| (1) CONTROL: <dialogstart> |
| ----------------------------------------> |
| |
| (2) 202 |
| <--------------------------------------- |
| |
| (3) REPORT: (pending) |
| <---------------------------------------- |
| |
| (4) 200 |
| ----------------------------------------> |
| |
| (5) REPORT: <response status="200"/> |
| (terminate) |
| <---------------------------------------- |
| |
| (6) 200 |
| ----------------------------------------> |
| |
| (7) CONTROL: <dialogterminate> |
| ----------------------------------------> |
| |
| (8) 200: <response status="200"/> |
| <---------------------------------------- |
| |
| (9) REPORT:<event name="dialogexit"/> |
| (notify) |
| <---------------------------------------- |
| |
| (10) 200 |
| ----------------------------------------> |
| |
Note that in (8) the response to the <dialogterminate/> request is
carried on a framework 200 response.
Boulton, et al. Expires May 5, 2008 [Page 46]
Internet-Draft Media Server Control Package November 2007
7. Template Dialog Examples
The following examples show how playannouncement, promptandcollect
and promptandrecord template dialogs are used with <dialogprepare>,
<dialogstart> and <event> elements.
The examples do not specify all messages between the AS and MS.
7.1. playannouncement
This example prepares an announcement composed of two prompts.
<dialogprepare src="basicivr:playannouncement">
<data>
<item name="prompts"
value="http://www.example.com/media/Number_09.wav
http://www.example.com/media/Number_11.wav"/>
<item name="iterations" value="2"/>
</data>
</dialogprepare>
If the dialog is prepared successfully, a dialogprepared message is
returned:
<response status="200" dialogid="vxi78"/>
The prepared dialog is then started on a conference playing the
prompts twice:
<dialogstart prepareddialogid="vxi78" conf-id="conference11"/>
In the case of a successful dialog, the output is provided in
<event>; for example
<event name="dialogexit" dialogid="vxi78">
<data>
<item name="status" value="1"/>
</data>
</event>
Boulton, et al. Expires May 5, 2008 [Page 47]
Internet-Draft Media Server Control Package November 2007
In this example, the dialog is started on a sip dialog connection,
but no <data> is specified:
<dialogstart src="basicivr:playannouncement"
connection-id="7HDY839~HJKSkyHS~HUwkuh7ns"/>
and an error message is returned:
<event name="dialogexit" dialogid="vxi79">
<data>
<item name="status" value="602"/>
<item name="reason" value="prompts not defined"/>
</data>
</event>
7.2. promptandcollect
This example plays no prompts and just waits for input from the user:
<dialogstart src="basicivr:promptandcollect"
connection-id="7HDY839~HJKSkyHS~HUwkuh7ns"/>
If the dialog is successful, then "dialogexit" <event> contains the
dtmf collected in its result parameter:
<event name="dialogexit" dialogid="vxi80">
<data>
<item name="status" value="1"/>
<item name="result" value="12345"/>
</data>
</event>
In this example, a prompt is played and then we wait for 3 hours for
a two digit sequence:
Boulton, et al. Expires May 5, 2008 [Page 48]
Internet-Draft Media Server Control Package November 2007
<dialogstart src="basicivr:promptandcollect"
connection-id="7HDY839~HJKSkyHS~HUwkuh7ns">
<data>
<item name="prompts" value="http://www.example.com/prompt1.wav"/>
<item name="timeout" value="1080s"/>
<item name="maxdigits" value="2"/>
<item name="iterations" value="1"/>
</data>
</dialogstart>
If no user input is collected within 3 hours, then following would be
returned:
<event name="dialogexit" dialogid="vxi81">
<data>
<item name="status" value="603"/>
</data>
</event>
And finally in this example, one of the input parameters is invalid:
<dialogstart src="basicivr:promptandcollect"
connection-id="7HDY839~HJKSkyHS~HUwkuh7ns">
<data>
<item name="prompts" value="http://www.example.com/prompt1.wav"/>
<item name="iterations" value="two"/>
<item name="cleardigitbuffer" value="true"/>
<item name="bargein" value="true"/>
<item name="timeout" value="4s"/>
<item name="interdigittimeout" value="2s"/>
<item name="termtimeout" value="0s"/>
<item name="maxdigits" value="2"/>
</data>
</dialogstart>
The error is reported in a dialogexit <event>:
<event name="dialogexit" dialogid="vxi82">
<data>
<item name="status" value="601"/>
<item name="reason" value="iterations invalid: two"/>
</data>
Boulton, et al. Expires May 5, 2008 [Page 49]
Internet-Draft Media Server Control Package November 2007
</event>
7.3. promptandrecord
In this example, the user is prompted, then their input is recorded
for a maximum of 30 seconds.
<dialogstart src="basicivr:promptandrecord"
connection-id="7HDY839~HJKSkyHS~HUwkuh7ns">
<data>
<item name="prompts"
value="http://www.example.com/media/sayname.wav
http://www.example.com/media/beep.wav"/>
<item name="dtmfterm" value="false"/>
<item name="maxtime" value="30s"/>
</data>
</dialogstart>
If successful, the following is returned in a dialogexit <event>:
<event name="dialogexit" dialogid="vxi83">
<data>
<item name="status" value="1"/>
<item name="result" value="http://www.example.com/recording1.wav"/>
</data>
</event>
Boulton, et al. Expires May 5, 2008 [Page 50]
Internet-Draft Media Server Control Package November 2007
8. Formal Syntax
[Editors Note: A later version of the XML schema will provide more
constraints as expressed in the textual definitions; for example,
single occurrence of <data> elements, co-occurence on attributes,
etc.]
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-ivr-basic"
xmlns:fw="urn:ietf:params:xml:ns:control:framework-attributes"
elementFormDefault="qualified"
xmlns="urn:ietf:params:xml:ns:msc-ivr-basic"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation>Basic IVR 1.0 schema (20061019)</xsd:documentation>
</xsd:annotation>
<xsd:import
namespace="urn:ietf:params:xml:ns:control:framework-attributes"
schemaLocation="framework.xsd"/>
<xsd:element name="dialogprepare">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="data"/>
<xsd:element ref="subscribe"/>
<xsd:any namespace="##other" processContents="strict"/>
</xsd:choice>
<xsd:attribute name="src" type="URI.datatype" use="required"/>
<xsd:attribute name="dialogid" type="dialogid.datatype"/>
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="dialogstart">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="stream"/>
<xsd:element ref="data"/>
<xsd:element ref="subscribe"/>
<xsd:any namespace="##other" processContents="strict"/>
</xsd:choice>
<xsd:attribute name="src" type="URI.datatype"/>
<xsd:attribute name="dialogid" type="dialogid.datatype"/>
<xsd:attribute name="prepareddialogid" type="dialogid.datatype"/>
Boulton, et al. Expires May 5, 2008 [Page 51]
Internet-Draft Media Server Control Package November 2007
<xsd:attributeGroup ref="fw:framework-attributes"/>
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="dialogterminate">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="strict"/>
</xsd:choice>
<xsd:attribute name="dialogid" type="dialogid.datatype"
use="required"/>
<xsd:attribute name="immediate" type="boolean.datatype"
default="false"/>
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="response">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="strict"/>
</xsd:choice>
<xsd:attribute name="status" type="status.datatype"
use="required"/>
<xsd:attribute name="reason" type="xsd:string"/>
<xsd:attribute name="dialogid" type="dialogid.datatype"/>
<xsd:attributeGroup ref="fw:framework-attributes"/>
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="event">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="data"/>
<xsd:any namespace="##other" processContents="strict"/>
</xsd:choice>
<xsd:attribute name="name" type="eventname.datatype"
use="required"/>
<xsd:attribute name="dialogid" type="dialogid.datatype"
use="required"/>
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
</xsd:element>
Boulton, et al. Expires May 5, 2008 [Page 52]
Internet-Draft Media Server Control Package November 2007
<!-- DATATYPES -->
<xsd:simpleType name="URI.datatype">
<xsd:restriction base="xsd:anyURI"/>
</xsd:simpleType>
<xsd:simpleType name="dialogid.datatype">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="boolean.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="true"/>
<xsd:enumeration value="false"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="eventname.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="[a-zA-Z0-9\.]+"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="status.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="[0-9][0-9][0-9]"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="media.datatype">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="label.datatype">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<xsd:simpleType name="direction.datatype">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="sendrecv"/>
<xsd:enumeration value="sendonly"/>
<xsd:enumeration value="recvonly"/>
</xsd:restriction>
</xsd:simpleType>
<!-- SHARED ELEMENTS -->
Boulton, et al. Expires May 5, 2008 [Page 53]
Internet-Draft Media Server Control Package November 2007
<xsd:element name="data">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="item"/>
<xsd:any namespace="##other" processContents="strict"/>
</xsd:choice>
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="item">
<xsd:complexType>
<xsd:attribute name="name" type="xsd:string"
use="required"/>
<xsd:attribute name="value" type="xsd:string"
use="required"/>
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="stream">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:any namespace="##other" processContents="strict"/>
</xsd:choice>
<xsd:attribute name="media" type="media.datatype"
use="required"/>
<xsd:attribute name="label" type="label.datatype"/>
<xsd:attribute name="direction" type="direction.datatype"
default="sendrecv" />
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="subscribe">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="notify"/>
</xsd:choice>
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="notify">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="1">
Boulton, et al. Expires May 5, 2008 [Page 54]
Internet-Draft Media Server Control Package November 2007
<xsd:element ref="data"/>
</xsd:choice>
<xsd:attribute name="name" type="xsd:string" use="required"/>
<xsd:anyAttribute namespace="##other" processContents="strict"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Boulton, et al. Expires May 5, 2008 [Page 55]
Internet-Draft Media Server Control Package November 2007
9. Security Considerations
Security Considerations to be included in later versions of this
document.
Boulton, et al. Expires May 5, 2008 [Page 56]
Internet-Draft Media Server Control Package November 2007
10. IANA Considerations
This document registers a new SIP Control Framework Package, a new
XML namespace and a new URI scheme "basicivr:".
10.1. Control Package Registration
Control Package name: msc-ivr-basic/1.0
10.2. URN Sub-Namespace Registration
XML namespace: urn:ietf:params:xml:ns:msc-ivr-basic
Boulton, et al. Expires May 5, 2008 [Page 57]
Internet-Draft Media Server Control Package November 2007
11. Change Summary
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
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>
Boulton, et al. Expires May 5, 2008 [Page 58]
Internet-Draft Media Server Control Package November 2007
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 May 5, 2008 [Page 59]
Internet-Draft Media Server Control Package November 2007
12. Acknowledgments
The authors would like to thank Adnan Saleem of Radisys, Gene
Shtirmer of Intel and Dave Burke of Google for useful reviews of this
work.
Boulton, et al. Expires May 5, 2008 [Page 60]
Internet-Draft Media Server Control Package November 2007
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
13.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.
[MSCP] McGlashan, S., Auburn, R., Burke, D., Candell, E., and R.
Surapaneni, "Media Server Control Protocol (MSCP)",
draft-mcglashan-mscp-03 (work in progress), March 2007.
[MSML] Saleem, A., Xin, Y., and G. Sharratt, "Media Session
Markup Language (MSML)", draft-saleem-msml-02 (work in
progress), October 2006.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2897] Cromwell, D., "Proposal for an MGCP Advanced Audio
Package", RFC 2897, August 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
Boulton, et al. Expires May 5, 2008 [Page 61]
Internet-Draft Media Server Control Package November 2007
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4722] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 4722,
November 2006.
[RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol
(SIP) Event Package for Key Press Stimulus (KPML)",
RFC 4730, November 2006.
[SIPCF] Boulton, C., Melanchuk, T., McGlashan, S., and A.
Shiratzky, "A Control Framework for the Session Initiation
Protocol (SIP)", draft-boulton-sip-control-framework-05
(work in progress), February 2007.
[SRGS] Hunt, A. and S. McGlashan, "Speech Recognition Grammar
Specification Version 1.0", W3C Recommendation,
March 2004.
[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 May 5, 2008 [Page 62]
Internet-Draft Media Server Control Package November 2007
Authors' Addresses
Chris Boulton
Ubiquity Software Corporation
Building 3
Wern Fawr Lane
St Mellons
Cardiff, South Wales CF3 5EA
Email: cboulton@ubiquitysoftware.com
Tim Melanchuk
BlankSpace
Email: tim.melanchuk@gmail.com
Scott McGlashan
Hewlett-Packard
Gustav III:s boulevard 36
SE-16985 Stockholm, Sweden
Email: scott.mcglashan@hp.com
Asher Shiratzky
Radvision
24 Raoul Wallenberg st
Tel-Aviv, Israel
Email: ashers@radvision.com
Boulton, et al. Expires May 5, 2008 [Page 63]
Internet-Draft Media Server Control Package November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 May 5, 2008 [Page 64]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/