Network Working Group C. Boulton Internet-Draft Ubiquity Software Corporation Intended status: Standards Track T. Melanchuk Expires: September 3, 2007 BlankSpace S. McGlashan Hewlett-Packard A. Shiratzky Radvision March 2, 2007 A Basic Interactive Voice Response (IVR) Control Package for the Session Initiation Protocol (SIP) draft-boulton-ivr-control-package-03 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 September 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Boulton, et al. Expires September 3, 2007 [Page 1] Internet-Draft Media Server Control Package March 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. . . . . . . . . . . . . . . . . . . . 9 4.1.2. . . . . . . . . . . . . . . . . . . . . 10 4.1.3. . . . . . . . . . . . . . . . . . . 12 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 15 4.3.1. . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.5. . . . . . . . . . . . . . . . . . . . . . . . 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 September 3, 2007 [Page 2] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 3] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 4] Internet-Draft Media Server Control Package March 2007 an XML message for preparing or starting a dialog; for example . The XML message may also contain template input parameters in a 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 is returned. When the dialog is completed, the MS returns template output parameters in a dialogexit 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 September 3, 2007 [Page 5] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 6] Internet-Draft Media Server Control Package March 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; , and elements are defined as package requests. Responses are carried either in REPORT message or Control Framework 200 response bodies; the element is defined as a package response. Event notifications are also carried in REPORT message bodies; the 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 September 3, 2007 [Page 7] Internet-Draft Media Server Control Package March 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 , or 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 (Section 4.2), or a (notification) element (Section 4.3). Boulton, et al. Expires September 3, 2007 [Page 8] Internet-Draft Media Server Control Package March 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: : prepare an IVR dialog for later execution : start an IVR dialog on a connection or conference : terminate an active IVR dialog 4.1.1. The 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 request referencing the prepared dialog (see Section 4.1.2). A 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 ). It is an error if a dialog with the same name already exists on the MS. The attribute is optional. The element has the following child elements: : 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 September 3, 2007 [Page 9] Internet-Draft Media Server Control Package March 2007 : 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: When an MS has successfully received a request, it MUST reply with a element (Section 4.2). 4.1.2. The 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 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 ). 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 September 3, 2007 [Page 10] Internet-Draft Media Server Control Package March 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 element has the following child elements defined: : 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 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 element is optional. If no elements are specified, then the default is the media configuration of the connection or conference. It is an error if a element is in conflict with (a) another 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]). : 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 September 3, 2007 [Page 11] Internet-Draft Media Server Control Package March 2007 : 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 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 is is required.] If the prepareddialogid is specified and the contained a element, it is an error to specify it in . Likewise, If the prepareddialogid is specified and the contained a element, it is an error to specify it in . For example, a request to start a promptandrecord template dialog on a conference: When an MS has successfully received a request, it MUST reply with a element (Section 4.2). 4.1.3. A dialog that has been successfully prepared or started can be terminated by a request element from the AS. The 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 ). 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 September 3, 2007 [Page 12] Internet-Draft Media Server Control Package March 2007 When an MS has successfully received a request, it MUST reply with a element (Section 4.2). 4.2. Responses Responses are specified in a element. 4.2.1. Reponses to requests are indicated by a element. The 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 September 3, 2007 [Page 13] Internet-Draft Media Server Control Package March 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: status codes [Editors Note: more status codes may need to be defined.] For example, a response when a dialog was prepared successfully: The response if dialog preparation failed due to an unknown template: For example, a response when the dialog was started successfully. 4.3. Notifications Event notifications are specified in an element. 4.3.1. Dialog event notifications are either manual or automatic. Manual event notifications are defined when an AS subscribes to notifications for dialog events using the element of or . 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 request where "immediate=true". When a dialog generates a notification event, the MS sends the event to the AS using an element. The 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 element has the following child element: : 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 with data indicating the status of a template dialog: Boulton, et al. Expires September 3, 2007 [Page 15] Internet-Draft Media Server Control Package March 2007 4.4. The element is a general container for parameterized data. The element has no attributes, but has the following child elements defined: : 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 elements may be specified. For example, a specifying promptandcollect template parameters with simple values: In this example, a specifying a playannouncement template with a complex value for the prompts parameter: [Editors Note: we may also want to investigate the use of s nested within a top-level to specify complex values. ] 4.5. The element is a container for specifying dialog notification events to which an AS subscribes. Notifications of dialog events are delivered using the element (see Section 4.3.1). The element has no attributes, but has the following child elements defined: Boulton, et al. Expires September 3, 2007 [Page 16] Internet-Draft Media Server Control Package March 2007 : contains the following attributes: name: a string indicating the name of the event to be notified of. The attribute is mandatory. The element may have a child element. Multiple elements may be specified. For example, the AS wishes to subscribe to DTMF and bargein notification events associated with a dialog: If the MS supports these notification events, then it would use the 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 September 3, 2007 [Page 17] Internet-Draft Media Server Control Package March 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 (Section 4.1.1) or (Section 4.1.2). Input parameters are specified in the child element (Section 4.4) of these elements. Output parameters are specified in the child element of a dialogexit 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 September 3, 2007 [Page 18] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 19] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 20] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 21] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 22] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 23] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 24] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 25] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 26] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 27] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 28] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 29] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 30] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 31] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 32] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 33] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 34] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 35] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 36] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 37] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 38] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 39] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 40] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 41] Internet-Draft Media Server Control Package March 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 is sent from the MS to the AS when the dialog exits normally. Application Server (AS) Media Server (MS) | | | (1) CONTROL: | | ----------------------------------------> | | | | (2) 202 | | <--------------------------------------- | | | | (3) REPORT: (pending) | | <---------------------------------------- | | | | (4) 200 | | ----------------------------------------> | | | | (5) REPORT: | | (terminate) | | <---------------------------------------- | | | | (6) 200 | | ----------------------------------------> | | | | (7) REPORT: | | (notify) | | <---------------------------------------- | | | | (8) 200 | | ----------------------------------------> | | | Boulton, et al. Expires September 3, 2007 [Page 42] Internet-Draft Media Server Control Package March 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: | | ----------------------------------------> | | | | (2) 202 | | <--------------------------------------- | | | | (3) REPORT: (pending) | | <---------------------------------------- | | | | (4) 200 | | ----------------------------------------> | | | | (5) REPORT: | | (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 September 3, 2007 [Page 43] Internet-Draft Media Server Control Package March 2007 Application Server (AS) Media Server (MS) | | | (1) CONTROL: | | ----------------------------------------> | | | | (2) 202 | | <--------------------------------------- | | | | (3) REPORT: (pending) | | <---------------------------------------- | | | | (4) 200 | | ----------------------------------------> | | | | (5) REPORT: | | (terminate) | | <---------------------------------------- | | | | (6) 200 | | ----------------------------------------> | | | | (7) CONTROL: | | ----------------------------------------> | | | | (8) 202 | | <--------------------------------------- | | | | (9) REPORT: (pending) | | <---------------------------------------- | | | | (10) 200 | | ---------------------------------------> | | | | (11) REPORT: | | (terminate) | | <---------------------------------------- | | | | (12) 200 | | ----------------------------------------> | | | | (13) REPORT:| | (notify) | | <---------------------------------------- | | | | (14) 200 | | ----------------------------------------> | | | Boulton, et al. Expires September 3, 2007 [Page 44] Internet-Draft Media Server Control Package March 2007 6.4. Terminating a dialog immediately An IVR dialog is started successfully, and then terminated immediately by the AS. No dialog notification s are sent back to the AS. Application Server (AS) Media Server (MS) | | | (1) CONTROL: | | ----------------------------------------> | | | | (2) 202 | | <--------------------------------------- | | | | (3) REPORT: (pending) | | <---------------------------------------- | | | | (4) 200 | | ----------------------------------------> | | | | (5) REPORT: | | (terminate) | | <---------------------------------------- | | | | (6) 200 | | ----------------------------------------> | | | | (7) CONTROL: | | ----------------------------------------> | | | | (8) 200: | | <---------------------------------------- | | | Note that in (8) the response to the 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 with information collected during the dialog. Boulton, et al. Expires September 3, 2007 [Page 45] Internet-Draft Media Server Control Package March 2007 Application Server (AS) Media Server (MS) | | | (1) CONTROL: | | ----------------------------------------> | | | | (2) 202 | | <--------------------------------------- | | | | (3) REPORT: (pending) | | <---------------------------------------- | | | | (4) 200 | | ----------------------------------------> | | | | (5) REPORT: | | (terminate) | | <---------------------------------------- | | | | (6) 200 | | ----------------------------------------> | | | | (7) CONTROL: | | ----------------------------------------> | | | | (8) 200: | | <---------------------------------------- | | | | (9) REPORT: | | (notify) | | <---------------------------------------- | | | | (10) 200 | | ----------------------------------------> | | | Note that in (8) the response to the request is carried on a framework 200 response. Boulton, et al. Expires September 3, 2007 [Page 46] Internet-Draft Media Server Control Package March 2007 7. Template Dialog Examples The following examples show how playannouncement, promptandcollect and promptandrecord template dialogs are used with , and 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. If the dialog is prepared successfully, a dialogprepared message is returned: The prepared dialog is then started on a conference playing the prompts twice: In the case of a successful dialog, the output is provided in ; for example Boulton, et al. Expires September 3, 2007 [Page 47] Internet-Draft Media Server Control Package March 2007 In this example, the dialog is started on a sip dialog connection, but no is specified: and an error message is returned: 7.2. promptandcollect This example plays no prompts and just waits for input from the user: If the dialog is successful, then "dialogexit" contains the dtmf collected in its result parameter: In this example, a prompt is played and then we wait for 3 hours for a two digit sequence: Boulton, et al. Expires September 3, 2007 [Page 48] Internet-Draft Media Server Control Package March 2007 If no user input is collected within 3 hours, then following would be returned: And finally in this example, one of the input parameters is invalid: The error is reported in a dialogexit : Boulton, et al. Expires September 3, 2007 [Page 49] Internet-Draft Media Server Control Package March 2007 7.3. promptandrecord In this example, the user is prompted, then their input is recorded for a maximum of 30 seconds. If successful, the following is returned in a dialogexit : Boulton, et al. Expires September 3, 2007 [Page 50] Internet-Draft Media Server Control Package March 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 elements, co-occurence on attributes, etc.] Basic IVR 1.0 schema (20061019) Boulton, et al. Expires September 3, 2007 [Page 51] Internet-Draft Media Server Control Package March 2007 Boulton, et al. Expires September 3, 2007 [Page 52] Internet-Draft Media Server Control Package March 2007 Boulton, et al. Expires September 3, 2007 [Page 53] Internet-Draft Media Server Control Package March 2007 Boulton, et al. Expires September 3, 2007 [Page 54] Internet-Draft Media Server Control Package March 2007 Boulton, et al. Expires September 3, 2007 [Page 55] Internet-Draft Media Server Control Package March 2007 9. Security Considerations Security Considerations to be included in later versions of this document. Boulton, et al. Expires September 3, 2007 [Page 56] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 57] Internet-Draft Media Server Control Package March 2007 11. Change Summary 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 and . 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 o removed response elements: , , , o simplified event notifications to single element carried in a REPORT o element replaced with o removed element o added element as child of o removed 'type' attribute from and o added dialogid attribute to and o removed template "Sample Implementation" section o renamed to Boulton, et al. Expires September 3, 2007 [Page 58] Internet-Draft Media Server Control Package March 2007 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 September 3, 2007 [Page 59] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 60] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 61] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 62] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 63] Internet-Draft Media Server Control Package March 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 September 3, 2007 [Page 64]