Network Working Group C. Boulton Internet-Draft Avaya Intended status: Standards Track T. Melanchuk Expires:May 17,August 26, 2008TJM ConsultingRain Willow Communications S. McGlashan Hewlett-PackardNovember 14, 2007February 23, 2008 A Basic Interactive Voice Response (IVR) Control Package for theSession Initiation Protocol (SIP) draft-boulton-ivr-control-package-05Media Control Channel Framework draft-boulton-ivr-control-package-06 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onMay 17,August 26, 2008. Copyright Notice Copyright (C) The IETF Trust(2007).(2008). Abstract This document defines aSession Initiation (SIP)Media Control Channel Framework 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 . . . . . . . . . . . . . . . . .67 3. Control Package Definition . . . . . . . . . . . . . . . . . .78 3.1. Control Package Name . . . . . . . . . . . . . . . . . . .78 3.2. Framework Message Usage . . . . . . . . . . . . . . . . .78 3.3. Common XML Support . . . . . . . . . . . . . . . . . . . .79 3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . .89 3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . .89 4. Dialog Management Element Definitions . . . . . . . . . . . .. . . . . . . . . 911 4.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . .911 4.1.1. <dialogprepare> . . . . . . . . . . . . . . . . . . .912 4.1.2. <dialogstart> . . . . . . . . . . . . . . . . . . . .1113 4.1.3. <dialogterminate> . . . . . . . . . . . . . . . . . .1316 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . .1317 4.2.1. <response> . . . . . . . . . . . . . . . . . . . . . .1317 4.3. Notifications . . . . . . . . . . . . . . . . . . . . . .1619 4.3.1. <event> . . . . . . . . . . . . . . . . . . . . . . .16 4.4. <data>19 4.3.2. <dialogexit> . . . . . . . . . . . . . . . . . . . . . 19 5. Basic IVR Dialog Element Definitions . . . . .17 4.5. <subscribe>. . . . . . . . 21 5.1. <basicivr> . . . . . . . . . . . . . . .17 5. IVR Template Dialogs. . . . . . . . . 23 5.2. <prompt> . . . . . . . . . . . .19 5.1. Play Announcement. . . . . . . . . . . . . 23 5.2.1. <media> . . . . . . .19 5.2. Prompt and Collect. . . . . . . . . . . . . . . . 25 5.2.2. <variable> . . . . . . . . . . . . . . . . . . . . . . 26 5.2.3. <dtmf> . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3.Prompt and Record<collect> . . . . . . . . . . . . . . . . . . . .37. . . . 28 5.3.1. <grammar> . . . . . . . . . . . . . . . . . . . . . . 31 5.4.Status Codes<record> . . . . . . . . . . . . . . . . . . . . . . .45. . 34 5.5.Type DefinitionsExit Information . . . . . . . . . . . . . . . . . . . . .46 6. AS-MS Interaction Examples36 5.5.1. <promptinfo> . . . . . . . . . . . . . . . . . .48. . . 37 5.5.2. <collectinfo> . . . . . . . . . . . . . . . . . . . . 37 5.5.3. <recordinfo> . . . . . . . . . . . . . . . . . . . . . 37 6. AS-MS Dialog Interaction Examples . . . . . . . . . . . . . . 39 6.1. Starting an IVR dialog . . . . . . . . . . . . . . . . . .4839 6.2. IVR dialog fails to start . . . . . . . . . . . . . . . .4939 6.3. Preparing and starting an IVR dialog . . . . . . . . . . .4940 6.4. Terminating a dialogimmediately. . . . . . . . . . . . .51 6.5. Terminating a dialog non-immediately. . . . . . 41 7. Basic IVR Dialog Examples . . . . .51 7. Template Dialog Examples. . . . . . . . . . . . . 43 7.1. Playing announcements . . . . . . . .53 7.1. playannouncement. . . . . . . . . . 43 7.2. Prompt and collect . . . . . . . . . . . . .53 7.2. promptandcollect. . . . . . . 44 7.3. Prompt and record . . . . . . . . . . . . . . . .54 7.3. promptandrecord. . . . 45 8. Type Definitions . . . . . . . . . . . . . . . . .56 8.. . . . . . 46 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .57 9.48 9.1. msc-ivr-common.xsd . . . . . . . . . . . . . . . . . . . . 48 9.2. msc-ivr-basic.xsd . . . . . . . . . . . . . . . . . . . . 55 10. Security Considerations . . . . . . . . . . . . . . . . . . .62 10.67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .63 10.1.68 11.1. Control Package Registration . . . . . . . . . . . . . . .63 10.2.68 11.2. URN Sub-Namespace Registration . . . . . . . . . . . . . .63 11.68 11.3. Mime Type Registration . . . . . . . . . . . . . . . . . . 68 12. Change Summary . . . . . . . . . . . . . . . . . . . . . . . .64 12.69 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . .66 13.72 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .67 14.73 15. References . . . . . . . . . . . . . . . . . . . . . . . . . .68 14.1.74 15.1. Normative References . . . . . . . . . . . . . . . . . . .68 14.2.74 15.2. Informative References . . . . . . . . . . . . . . . . . .6874 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .7076 Intellectual Property and Copyright Statements . . . . . . . . . .7177 1. Introduction TheSIPMedia Control Channel Framework[SIPCF][MCCF] provides a generic approach for establishment and reporting capabilities of remotely initiated commands. The Framework utilizes many functions provided by the Session Initiation Protocol [RFC3261] (SIP) for the rendezvous and establishment of a reliable channel for control interactions. The Control Framework also introduces the concept of a Control Package. A Control Package is an explicit usage of the Control Framework for a particular interaction set. Thisspecificationdocument defines apackageControl Package for basicIVR. The scopeIVR dialogs. This package has been designed to satisfy the IETF MediaCtrl requirements ([I-D.ietf-mediactrl-requirements]) by building upon two major approaches to IVR dialog design. These approaches address a wide range of IVR use cases and are used in many applications which are extensively deployed today. First, the package iscontroldesigned to provide the major IVR functionality ofmedia server functions for basic interactive media (e.g. play a prompt, collecting DTMF, recording user input)SIP Media Server languages such aswellnetann ([RFC4240]), MSCML ([RFC5022]) and MSML ([MSML]) which themselves build upon more traditional non-SIP languages ([H.248.9], [RFC2897]). A key differentiator is that this package provides the functionality using the Media Control Channel Framework. Second, its design is aligned with key concepts in W3C Voice Browser languages. The key dialog management mechanism is closely aligned with CCXML ([CCXML10]). The basic dialog functionality in this package can be seen asnotifications related to these functions. These functionsa subset of VoiceXML ([VXML20], [VXML21]): where possible, basic prompting, DTMF collection andnotificationsmedia recording features aredefinedincorporated, but not any advanced VoiceXML constructs (such asmessages<form>, its interpretation algorithm, or a dynamic data model). As W3C develops VoiceXML 3.0, we expect to see further alignment, especially inXML [XML]. The message use XMLproviding a set of basic independent primitive elementsfor preparing, starting and stopping dialogs,(such aswell as elements for responsesprompt, collect andnotifications ([CCXML10], [MSML]record) which can be re-used in different dialog languages. By reusing and[MSCP]). This basicbuilding upon design patterns from these approaches to IVR languages, this packageuses template dialogsis intended to provide a foundation which is familiar to current IVRfunctionality. Three basicivr template dialogs are defined: playannouncement:developers and sufficient for 'basic' IVR applications, as well as adialogpath toplayother languages - including control packages which extend this package - which address more advanced applications. The scope of this package is 'basic' IVR functionality of a media server which includes: o playing one or moreprompts to the user promptandcollect:media resources as adialog toprompt to the userand collect theiro collecting DTMF inputpromptandrecord: a dialog to promptfrom the userand record theiraccording to a grammar o recording user media inputTemplate dialogsOut of scope of this package areintended to provide basic IVR functionality ([H.248.9], [RFC4240], [MSML], [RFC2897]more advanced functions including ASR (Automatic Speech Recognition), TTS (Text-to-Speech), VoiceXML, fax and[RFC5022]). The template approach follows previous approaches in that it provides IVRmedia transformation. Such functionalitywhich is commonly required for applications. It differs in that themay be addressed by extension packages. This functionality of this package isexpressed indefined by messages, containing XML [XML] elements, transported usinga referencethe Media Control Channel Framework. The XML elements can be divided into two types: dialog management elements; and carried within those, elements which define the specific IVR operations for the dialog. Dialog management elements are designed to manage thetemplategeneral lifecycle of a dialog. Elements are provided for preparing a dialog, starting the dialog on a conference or connection, andparameters expressed interminating execution of asimple XML data structure. Thisdialog. Each of these elements is contained in alightweight approach sinceMedia Control Channel Framework CONTROL message sent to thecontents ofmedia server. When thedialog itself does not need to be transported overappropriate action has been executed, thecontrol channelmedia server sends a REPORT message (orfetched from an external source), onlyatemplate reference plus configuration data is required. From200 if it can execute in time) with a response element indicating whether thedeveloper's perspective, this simplifies application development: they dooperation was successful or notneed to write their IVR dialog using custom XML elements, they only need to reference(e.g. if thetemplatedialogand, if required, populate a simple XML data structure to pass configuration data. To use a template dialog,cannot be started, then theAS developer references it by nameerror is reported inan XML message for preparing or startingthis response). Once adialog; for example <dialogstart src="basicivr:promptandrecord"/>. The XML messagedialog has been successfully started, the media server mayalso contain template input parameterssend further event notifications in a<data> element to configure specific behavior defined by the template dialog; e.g. using "prompts" withframework CONTROL message. This package defines one event notification, namely a dialogexit event indicating that thevalue "http://www.example.com/welcome.wav".dialog has exited. If the dialogstarts successfully,has executed successful, the dialogexit event includes information collected during the dialog. If an error occurs during execution (e.g. a<response status="200"/>media resource failed to play, no recording resource available, etc), then error information isreturned. Whenreported in thedialogdialogexit event. Once a dialogexit event iscompleted,sent, theMS returns template output parameters indialog lifecycle is terminated. Specific dialog types are referenced or contained within dialog management elements for preparing and starting dialogs. This package defines adialogexit <event> notificationbasic IVR dialog type which contains child elements for playing prompts to theAS.user, collects DTMF input from the user and recording media input from the user. Theimplementationchild elements can co-occur in the basic IVR dialog type so as to provide 'play announcement', 'prompt and collect' as well as 'prompt and record' functionality. Implementation oftemplate dialogs requires only that theythis control package MUST adhere to the syntax and semantics oftemplatesXML elements described in this document. In cases where there is a difference in constraints between the XML schema and the textual description of elements, the textual definition takes priority. Other control packages MAYbe defined whichextend this package. Two extension points are RECOMMENDED: 1. Retaining thecapabilities ofdialog management capability but extending thetemplates dialogs defined in this document. Suchbasic IVR dialog type by adding new capabilities. For example, adding speech recognition capability. 2. Extending the dialog management capability with alternative dialog types. For example, using the VoiceXML dialog type rather than the basic IVR dialog type ([VXMLCP]). Otherwise, extension control packages MUST respect the syntax and semantics of this control package. This document specifies how the basic IVR control packagefulfilsfulfills the requirements of theSIPMedia Control Channel Framework control packages (Section 3),which XMLthe dialog management elementsaredefined by the package (Section 4), thetemplatebasic IVR dialog type definitions (Section 5) as well as providing examples (Section 6, Section7)7), type definitions (Section 8) andanXML schema (Section8).9). 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 isidentified byspecified as inline XML, or via a URIand hasreference to anassociated mimetype.external XML document type. Dialogs typically feature basic capabilities such as playing audio prompts, collecting DTMF input and recording audio input from the user. More advanced dialogs may also feature synthesized speech, recording and playback of video, recognition of spoken input, and mixed initiative conversations. Application server: A SIP [RFC3261] application server (AS) hosts and executes services such as interactive media and conferencing in an operator's network. An AS influences and impacts the SIP session, in particular by terminating SIP sessions on a media server, which is under its control. Media Server: A media server (MS) processes media streams on behalf of an AS by offering functionality such as interactive media, conferencing, and transcoding to the end user. Interactive media functionality is realized by way ofdialogs,dialogs which areidentified by a URI andinitiated by the application server. 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 Section98 of[SIPCF].[MCCF]. 3.1. Control Package Name The Control Framework requires a Control Packagedefinitionto 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 - version1.0 ).1.0). Its IANA registration is specified in Section 11.1. 3.2. Framework Message UsageIVR functionality includes capabilities suchThe Control Framework requires a Control Package to explicitly detail the control messages that can be used asplaying prompts, collecting DTMF and recording user input. These functions are expressed using template dialogs defined in Section 5.well as provide an indication of directionality between entities. This will include which role type is allowed to initiate a request type. This package defines XML elements for dialog management in Section44; these elements specify dialog requests, responses andprovides an XML Schemaevent notifications. The package also defined elements for the basic IVR dialog type in Section8.5. The basic IVR dialog elements are contained inside dialog management elements. XML Schema for all XML elements defined in this package aresplit into requests, responsesspecified in Section 9. In this package, the MS operates as a Control Framework Server in receiving requests from, andevent notifications. Requestssending responses to, the AS (operating as Control Framework Client). These requests are carried in CONTROL messagebodies;bodies from AS to MS; <dialogprepare>, <dialogstart> and <dialogterminate> elements are defined as package requests. Responses to these requests are carried either in REPORTmessagemessages or Control Framework 200 responsebodies; thebodies with <response> elementis defined as a package response. Event notifications are also carried in REPORT message bodies; the <event> element is defined for package event notifications.payload. Note that package responses are different from framework response codes. Framework error response codes (see Section 8 of[SIPCF])[MCCF]) are used when the request or event notification is invalid; for example, a request is invalid XML (400), or not understood (500). Package responses are carried in 200 response or REPORT message bodies. This package's response codes are defined in Section 4.2.1. Theschema uses "connection-id" and "conf-id" attributes whichMS also operates as a Control Framework Client in sending event notifications to the AS (Control Framework Server). Event notifications areimported from schemacarried in CONTROL message bodies; the <event> element is defined for package event notifications. AS responses are carried incoreControl Framework[SIPCF].responses or, if the transaction is extended, in REPORT messages. 3.3. Common XML Support The Control Framework requires a Control Package definition to specify if the attributes for media dialog or conference references are required. This package requires that the XML Schema in Section 16.1 of[SIPCF][MCCF] MUST be supported for media dialogs and conferences. The package schema uses "connectionid" and "conferenceid" attributes which are imported from the XML schema. 3.4. CONTROL Message BodyA valid CONTROLThe Control Framework requires a Control Package to define the control bodymessage MUST conformthat can be contained within a CONTROL command request and to indicate theschema defined in Section 8location of detailed syntax definitions anddescribed in Section 4. XML messages appearing insemantics for the appropriate body types. When operating as Control Framework Server, the MS receives CONTROL messagesMUST containwith a body containing a valid <dialogprepare>, <dialogstart> or <dialogterminate> request element. The syntax and semantics of these elements are defined in Section 4.1. When operating as Control Framework Client, the MS sends CONTROL messages with a body containing a valid notification <event> element. The syntax and semantics of this element(Section 4.1).is defined in Section 4.3. 3.5. REPORT Message BodyA validThe Control Framework requires a control package definition to define the REPORT bodyMUST conform tothat can be contained within a REPORT command request, or that no report package body is required. This section should indicate theschema defined in Section 8location of detailed syntax definitions anddescribedsemantics for the appropriate body types. When operating as Control Framework Server, the MS sends REPORT bodies containing a valid <response> element. The syntax and semantics of this element is specified in Section4. XML messages appearing in4.2. When operating as Control Framework Client, the MS receives REPORT messagesMUSTwhich SHOULD NOT contain a<response> (Section 4.2), orbody. [Editors Note:IVR01 need to clarify the behavior when the MS receives a(notification) <event> element (Section 4.3).REPORT in response to sending an event notification CONTROL.] 4. Dialog Management Element Definitions This section defines the dialog management XML messages for this control package.[Editors Note: since XML Schema may not be ableThese messages are divided into requests (Section 4.1), responses (Section 4.2) and notifications (Section 4.3). 4.1. Requests Requests are send toexpress all constraints expressed in these definitions, in cases where there is a difference in constraints,thedefinitionsMS (operating as a Control Framework Server) in thesection take priority.] 4.1. Requestsbody of CONTROL messages. The following request elements are defined: <dialogprepare>: prepare an IVR dialog for later execution <dialogstart>: start an IVR dialog on a connection or conference <dialogterminate>: terminate anactiveIVR dialog These elements control the life cycle of a dialog. Each dialog has the following states: IDLE: the dialog is uninitialized. PREPARING: the dialog is being prepared. If an error occurs the dialog transitions to the TERMINATED state. PREPARED: the dialog has been successfully prepared and has a valid dialog identifier. STARTING: the dialog is being started. If an error occurs the dialog transitions to the TERMINATED state. STARTED: the dialog has been successfully started and is now active. When the dialog exits (normally or terminated), or due to an error, a dialogexit notification event is sent and the dialog transitions to the TERMINATED state. TERMINATED: the dialog is terminated and its dialogid is no longer valid. No further dialog notifications are sent for this dialog. As a consequence, it is an error if the same dialog is prepared or started more than once. 4.1.1. <dialogprepare> The <dialogprepare> request is sentfrom the ASto the MS to request preparation of an IVR dialog. Dialog preparation consists of (a) retrieving an external dialog document (if specified), and (b) validating the document both syntactically and semantically. A prepared dialog is executed when the AS sends a <dialogstart> request referencing the prepared dialog (see Section 4.1.2). A <dialogprepare> element has the following attributes: src:string identifyingspecifies theURIlocation ofthean external dialog document to prepare. A valid value is a URI (see Section 8.9). It is an error if the document cannot be retrieved or processed (e.g. URI protocol not supported). The attribute ismandatory. The MS MUST support "basicivr: playannouncement", "basicivr:promptandcollect" and "basicivr: promptandrecord" basicivr template dialogs asoptional. type: specifies thevalue for thistype of the external dialog document indicated in the 'src' attribute. A valid value is a MIME type (see Section 8.10). TheMS MAY support other URI formats.attribute is optional. dialogid: string indicating a unique name for the dialog. If this attribute is not specified, the MS creates a unique name for the dialog. The value is used in subsequent references to the dialog (e.g. as dialogid in a <response>). It is an error if a dialog with the same name already exists on the MS. The attribute is optional. The <dialogprepare> elementhasin this package is extended with the thefollowingchildelements: <data>: an XML data structureelement <basicivr> for inline Basic IVR dialog (see Section4.4)5.1). Other packages which extend this package MAY use alternative dialog types. The dialog topass parameters intoprepare can either be specified inline as a child element or externally using thedialog.src attribute (but not both). It is an error ifa specified parameter is not supported by the implementation. Theboth an inline dialog elementis optional. <subscribe>:and a src attribute are specified. When anXML data structure (see Section 4.5) indicating notification events to whichMS receives a <dialogprepare> request, theAS subscribes. Itdialog isan error ifin aspecified notification event is not supported byPREPARING state. If dialog preparation was successful, theimplementation. The elementdialog isoptional. For example, a request to preparein aplayannouncementPREPARED state; otherwise the dialogwhere a single promptisplayed 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 receivedin a<dialogprepare> request, itTERMINATED state. The MS MUST reply to <dialogprepare> request with a <response> element (Section4.2). [Editors Note. Using the src attribute to indicate the type of the4.2), reporting whether dialogblocks referencepreparation was successful or not. Example: in CONTROL message from AS toan external dialog. InMS, thenext version,following request prepares atype attribute will be added to bothbasic IVR dialog where a single prompt is played once: <dialogprepare>and <dialogstart> to indicate the MIME type of<basicivr> <prompt> <media src="http://www.example.com/prompt1.wav"/> </prompt> </basicivr> </dialogprepare> Alternatively, the same dialogandcould be referenced: <dialogprepare type="application/msc-ivr-basic+xml" src="http://example.org/basic1.xml"/> if thesrc attribute will have a URI value for external dialogs. Thedialogcanis prepared successful, thenbe specified inlinea Control Framework 200 orexternally (but not both).] [Editors Note. We are investigating whether to re-structurea REPORT message for thecontent of basicivr commands (no change in content). This could include: Container elements <playannouncement>, <promptandcollect> and <promptandrecord>. Each elementsame transaction wouldhave the defined attributes for each dialog type.contain a response such as: <response status="200" dialogid="d100"/> The<data> element would be obsoleted since information would expressed through these more specific elements. For example, <dialogprepare type="basicivr"> <playannouncement prompts="http://www.example.com/prompt1.wav" iterations="1"/> </dialogprepare> This approachControl Framework transaction ismore compact than the current approach,then complete. See Section 6 andallows constraints on attribute values to be checked by an XML schema validator (the <data> approach does not allows this). We could goSection 7 for furtherand factor out prompt information into a separate <prompt> element which is then used in the above dialog types. ]examples. 4.1.2. <dialogstart> The <dialogstart> element is sent by the AS torequest execution ofstart a dialog. The dialog may bedefinedspecified in thedialogstart<dialogstart> request itself, or reference a previously prepared dialog. Starting a dialog consists of (a) retrieving any resources (e.g. media, grammar, etc) associated with the dialog, and (b) activating these resources according to the dialog type. For example, with <basicivr>, retrieving media resources and playing them to the user. The <dialogstart> element has the following attributes: src:string identifyingspecifies theURIlocation ofthean external dialog document to start. A valid value is a URI (see Section 8.9). It is an error if the document cannot be retrieved or processed (e.g. URI protocol not supported). The attribute is optional.The MS MUST support "basicivr: playannouncement", "basicivr:promptandcollect" and "basicivr: promptandrecord" basicivr template dialogs astype: specifies thevalue for thistype of the external dialog document indicated in the 'src' attribute. A valid value is a MIME type (see Section 8.10). TheMS MAY support other URI formats.attribute is optional. dialogid: string indicating a unique name for the dialog. If this attribute is not specified, the MS creates a unique name for the dialog. The value is used in subsequent references to the dialog (e.g. as dialogid in a <response>). It is an error if a dialog with the same name already exists on the MS. The attribute is optional. prepareddialogid: string identifying a dialog previously prepared using a dialogprepare request. The attribute is optional.connection-id:connectionid: string identifying the SIP dialog connection on which this dialog is to be started (see Section 16.1 of[SIPCF]).[MCCF]). The attribute is optional.conf-id:conferenceid: string identifying the conference on which this dialog is to be started (see Section 16.1 of[SIPCF]).[MCCF]). 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 theconnection-idconnectionid orconf-idconferenceid attributes MUST be specified. It is an error to specify bothconnection-idconnectionid andconf-id.conferenceid attributes or neither. The <dialogstart> element has the following child elements defined: <stream>: contains the following attributes: media: a string indicating the type of media associated with the stream. It is stronglyrecommendedRECOMMENDED 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 theconnection-idconnectionid (see Section 16.1 of[SIPCF]). <data>: an XML data structure[MCCF]). The <dialogstart> element in this package is extended with the the child element <basicivr> for inline Basic IVR dialog (see Section4.4)5.1). Other packages which extend this package MAY use alternative dialog types. The dialog topass parameters into thestart can be specified either inline, or externally, or reference a previously prepared dialog.ItExactly one of the src attribute, the prepareddialogid or a dialog type child element MUST be specified. If the prepareddialogid is specified, it is an errorifto specify the src attribute, the dialogid attribute or aspecified parameterdialog type child element. If the src attribute isnot supported byspecified, it is an error to specify theimplementation. Theprepareddialogid attribute, or a dialog type child element. If a dialog type child element isoptional. <subscribe>:specified, it is anXML data structure (see Section 4.5) indicating notification eventserror towhichspecify theAS subscribes. Itsrc attribute or the prepareddialogid attribute. When an MS receives a <dialogstart> request, the dialog is either in anerror ifIDLE or PREPARED state (if aspecified notification eventpreviously prepared dialog isnot supported bybeing started). If in theimplementation.The elementIDLE state, then the dialog isoptional. [Editors Note:first prepared and if successful, transitions to the<stream> element assumes thatPREPARED state. When theuse ofprepared dialog is started it transitions to theSDP label by itselfSTARTING state and, if the dialog isinsufficient for media stream control. In particular,started successfully, theSDP labeldialog then transition to the STARTED state. If a error occurs during dialog preparation or starting, then the error MUST be reported, and the dialog transitions to a TERMINATED state. The MS MUST reply to <dialogstart> request with a <response> element (Section 4.2), reporting whether the dialog was started successful or not. [Editors Note:IVR02 This specification does notaddress directionality, nor does it address conferences. Further investigation ofdefined the<stream>behavior when more than one dialog isrequired.] Ifstarted on theprepareddialogidsame connection or conference. Various models could be applied: reject: only one dialog per connection or conference replace: the current dialog isspecifiedstopped and the<dialogprepare> contained a <data> element, itnew one started queue: the new dialog isan error to specify it in <dialogstart>. Likewise, Ifqueued for starting after current dialog exits. mix: multiple dialogs are permitted with theprepareddialogidsame connection or conference: input isspecifiedpassed to both dialog; andthe <dialogprepare> contained a <subscribe> element, itdialog output isan errormixed. We also need to take into account that the <stream> element can be used to specifyit in <dialogstart>.that different dialogs affect different media streams of the same connection or conference. For example,a requestone dialog that only generates output, and another dialog on the same connection only receives input. Workgroup input on this issue is required. ] Example: in CONTROL message from AS tostartMS, the following request starts apromptandrecord templatebasic ivr recording dialog on a conference: <dialogstartconf-id="conference11" src="basicivr:playandrecord"> <data> <item name="maxtime" value="384000s"/> </data>conferenceid="conference11"> <basicivr> <record maxtime="384000s"/> </basicivr> </dialogstart>When an MS has successfully receivedAlternatively, the same dialog could be referenced: <dialogstart conferenceid="conference11" type="application/msc-ivr-basic+xml" src="http://example.org/basic2.xml"/> if the dialog is started successfully, then a<dialogstart> request, it MUST reply withControl Framework 200 or a<response> element (Section 4.2).REPORT message for the same transaction would contain a response such as: <response status="200" dialogid="d101" conferenceid="conference11"/> The Control Framework transaction is then complete. See Section 6 and Section 7 for further examples. 4.1.3. <dialogterminate> A dialog that has been successfully prepared or started can be terminated by sending a <dialogterminate> request elementfromto theAS.MS. The <dialogterminate> element has the following attributes: dialogid: string identifyingan existing dialog.the dialog to terminate. The attribute is mandatory. immediate:string with the values "true" or "false" indicatingindicates whether the dialog is to be terminated immediately or not.IfA valid value is a boolean (see Section 8.1). A value of true indicates that the dialog is terminatedimmediately, no further dialog event notifications areand a dialogexit <event> notification MUST be sent(includingimmediately. A value of false indicates that the dialog terminates normally, sending a dialogexit<event>). The default<event> notification is"false".sent when the dialog has exited. The attribute is optional.For example, assuming a dialog withThe default value is false. It is an error if the dialogid"vxi1" has been started, it can be terminated immediately with the following request: <dialogterminate dialogid="vxi1" immediate="true"/>is invalid. When an MShas successfully receivedreceives a <dialogterminate> request, the dialog MUST be in a PREPARED, STARTING or STARTED states. If it is in a PREPARED state, then it transitions immediately to the TERMINATED state. If it is in STARTING state, then any further starting (or preparation) of the dialog is canceled, the response of the dialogstart command reporting that the dialog is terminated, and the dialog transitions to the TERMINATED state. If the dialog is in a STARTED state, then the dialog is terminated according to the value of the immediate attribute, and when the dialogexit notification is sent, the dialog moves into the TERMINATED state. The MS MUST reply to <dialogterminate> request with a <response> element (Section4.2).4.2), reporting whether the dialog was stopped successful or not. Example: in CONTROL message from AS to MS, the following request terminate a dialog with dialogid "vxi1": <dialogterminate dialogid="vxi1" immediate="true"/> if the dialog is terminated successfully, then a Control Framework 200 or a REPORT message for the same transaction would contain a response such as: <response status="200" dialogid="d100"/> The Control Framework transaction is then complete. See Section 6 and Section 7 for further examples. 4.2. Responses Responses are generated in response to <dialogprepare>, <dialogstart> and <dialogterminate> requests. Responses are specified in a <response> element. 4.2.1. <response>ReponsesResponses 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:connectionid: string identifying the SIP dialog connection associated with the dialog (see Section 16.1 of[SIPCF]).[MCCF]). The attribute is optional.conf-id:conferenceid: string identifying the conference associated with the dialog (see Section 16.1 of[SIPCF]).[MCCF]). The attribute is optional. The following status codes are defined: +-----------+-------------------------------------------------------+ | code | description | +-----------+-------------------------------------------------------+ | 200 | OK | | | | | 401 | dialogid already exists | | | | | 402 | dialogid does not exist | | | | | 403 |connection-idconnectionid does not exist | | | | | 404 |conf-idconferenceid does not exist | | | | | 405 | Unknown or unsupported element | | | | | 406 | Element required | | | | | 407 | Unknown or unsupported attribute | | | | | 408 | Attribute required | | | | | 409 |templatedialog type not supported | | | | | 410 |data parameter not supportedRetrieving document resource failed | | | | | 411 |event subscription not supported | | | | | 412 | stream parameter invalidInvalid attribute value | | | | | 499 | other error | +-----------+-------------------------------------------------------+ Table 1: <response> status codes [EditorsNote:Note:IVR03 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 anunknown template:unsupported dialog type: <response status="409" dialogid="vxi1"reason="Unknown template: promptandrecod"/>reason="Unsupported dialog type: application/basicirv+xml"/> For example, a response when the dialog was started successfully. <response status="200" dialogid="vxi1"connection-id="7HDY839~HJKSkyHS"/>connectionid="7HDY839~HJKSkyHS"/> See Section 6 and Section 7 for further examples. 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 eventEvent notificationsare defined as part of a Control Package. The AS SHOULD NOT subscribe to these event notifications. The MSMUSTsupport these event notifications. This package defines one automatic notification event: "dialogexit" which indicates that an active dialog has terminated. Note that this notification is notNOT be sentifunless the dialoghas been terminated by the AS usingis in a<dialogterminate/> request where "immediate=true".STARTED state. 4.3.1. <event> When a dialog generates a notification event, the MS sends the event to the AS using an <event> element. The <event> element has the following attributes: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 thedialog.dialog which generated the event. The attribute is mandatory. The <event> element has the following childelement: <data>: an XML data structure (see Section 4.4) to pass information additional information aboutelements: <dialogexit>: indicates that the dialogevent.has exited. The element is optional.ForExtension packages may define other child elements for notifications which they support. See Section 6 and Section 7 for examples. 4.3.2. <dialogexit> The <dialogexit> event indicates that an active dialog has exited because it is complete, has been terminated, or because an error occurred during execution (for example,whenadialog exitsmedia resource cannot be played). This event MUST be sent by the MSmay send awhen the dialog exits. Once the dialogexit<event> with data indicatingevent is sent, thestatus of a template dialog: <event name="dialogexit" dialogid="vxi1"> <data> <item name="status" value="1"/> </data> </event> 4.4. <data>dialog transitions from the STARTED state to the TERMINATED state. The<data> element is a general containerMS MUST NOT send any further notifications forparameterized data.a dialog in the TERMINATED state. The<data><dialogexit> element hasno attributes, but has the following child elements defined: <item>: containsthe following attributes:name:status: astringstatus code indicatingthe namesuccess or failure of theparameter. The attributedialog. A valid value ismandatory. value:astring indicating thenon-negative integer (see Section 8.4). A value of 0 indicates that theparameter. Multiple valuesdialog has been terminated externally. A value ofa parameters can be specified using space separation.1 indicates success. Any other value indicate an error. 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> specifyingreason: aplayannouncement template withtextual description providing acomplex valuereason for theprompts 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> elementstatus code; e.g. details about an error. A valid value is acontainer for specifying dialog notification events to which an AS subscribes. Notifications of dialog events are delivered using the <event> elementstring (see Section4.3.1). The <subscribe> element has no attributes, but has the following child elements defined: <notify>: contains the following attributes: name: a string indicating the name of the event to be notified of.8.6). The attribute ismandatory.optional. There is no default value. [Editors Note:IVR04 do we need to specify specific error codes?] The<notify><dialogexit> elementmay have a <data>in this package is extended with childelement. Multiple <notify>elementsmay be specified. For example, the AS wishes to subscribe to DTMFfor reporting prompt, collect andbargein 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 duringrecord information (see Section 5.5) of the basic IVR dialogto the AStype. Other packages which extend this package MAY use alternative child elements. Example: whenthe events occurred. [Editors Note: It may be possible to defineageneral event subscription mechanism as part of the SIP Control Framework.] [Editors Note: This Control Package does not specifySTARTED <basicivr> dialognotification 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 onexits normally the MS sends aprompt),dialogexit <event>: <event dialogid="vxi1"/> <dialogexit status="1"> <collectinfo dtmf="1234" termmode="match"/> </dialogexit> See Section 6 and"rtpcontrol" (control data, e.g. VFU, PoC, etc, is received over the RTP control channel.]Section 7 for further examples. 5. Basic IVRTemplate DialogsDialog Element Definitions Theexecution ofbasic IVRtemplatedialogtakes place on the MS. The AS specifies the nameis an instance ofthe template and configuration parameters, and receives the result from thea dialog described in Section 4.1. The MSafterMUST support the Basic IVR dialoghas 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 templatetype in this package. A basic IVR dialog isreported 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 bespecified inline or bythe implementation. Template dialogs are invoked by referencing themreference inthe src attribute of<dialogprepare> (Section 4.1.1) or <dialogstart> (Section4.1.2). Input parameters4.1.2) elements. Inline basic ivr dialogs are specified inthe <data>a <basicivr> childelement (Section 4.4)of these elements.Output parametersThe basic IVR dialog is a simple XML container - <basicivr> - for executing basic IVR operations of playing prompts (<prompt> - see Section 5.2), collecting DTMF (<collect> - see Section 5.3),and recording user input (<record> - see Section 5.4. Results of the dialog execution arespecifiedreported inthe <data> child element ofa dialogexit<event>notification(Section 4.3.1). The detailed mapping of template dialogs to XML CONTROL and REPORT messagesevent. Three execution models are defined: playannouncements: only a <prompt> element isdescribedspecified inSection 3 and examplesthe container. The prompt media resources areprovidedplayed inSection 7. The implementationsequence. promptandcollect: a <collect> element is specified and, optionally, a <prompt> element. If a <prompt> element is specified and bargein is enabled, playing oftemplate dialogs MUST adhere tothesyntaxprompt is terminated when bargein occurs, andsemantics of templates described in this document. Implementations MAY support additional parametersDTMF collection is initiated; otherwise, the prompt is played to completion before DTMF collection is initiated. If no prompt element is specified, DTMF collection is initiated immediately. promptandrecord: a <record> element is specified and, optionally, a <prompt> element. If a <prompt> element is specified and bargein is enabled, playing of thedefined template dialogs. Implementations MAY support additional template dialogs. The actual implementation may be based on any technology or scripting language. The media requirements onprompt is terminated when bargein occurs, and recording is initiated; otherwise, thetemplate implementation are restrictedprompt is played to completion before recording is initiated. If no prompt element is specified, recording is initiated immediately. Each of thecapability to play audio prompts (specified as URIs), collect DTMF input, and record audio input. The implementation MUST support G.711 audio formats (headerlesscore elements - <prompt>, <collect> andwav) for playback<record> - are specified so that their execution andrecording. The implementation MAY supportreporting is largely self- contained. This facilitates their re-use in othermedia formats. [Editors Note: Later versions may consider additional media requirements including TTS, ASR, video, etc. ] 5.1. Play Announcement A templatedialogto play announcements tocontainer elements. Execution results are reported in theuser. The template dialog is invoked using<dialogexit> notification event whose definition is extended with theURI "playannouncement". The dialog execution model consists of: 1. Playing promptselements defined in Section 5.5. If theorder specified until completion. 2. Repeating step 1dialog terminated normally (i.e. not due to an error or to a <dialogterminate> request), then the MS MUST report the results for at least thevalue of iterations. 3. Returning statuscore operation: <prompt> only: <promptinfo> (see Section 5.5.1) with at least the termmode attribute specified. <collect>: <collectinfo> (see Section 5.5.2) with the dtmf andreason parameters. [Editors Note:termmode attributes specified. <record>: <recordinfo> (see Section 5.5.3) with at least theexecution model needsrecording, type and termmode attributes specified. The media format requirements for basic IVR dialogs are undefined. This package is agnostic to the media types and codecs for media resources and recording which need to beupdatedsupported by an implementation. For example, a MS implementation may choose to support only audio and in particular the 'audio/basic' codec for media playback and recording. However, if an MS encounters when executing a dialog a media type or codec which it cannot process, thefollowing new attributes: duration, interval, maxage, maxstale, speed, volumeMS MUST stop further processing andoffset.]report an error to the AS using the dialogexit notification. Theinputimplementation of basic IVR dialogs MUST adhere to the syntax andoutput parameters are summarizedsemantics described in this section. Implementations MAY support additional (non-basicivr namespace) attributes anddefined below. +------------+-----------+-----------------------------+------------+ | Name | Direction | Description | Definition | +------------+-----------+-----------------------------+------------+ | prompts | input | promptselements of these dialogs. If an implementation encounters additional (non-basicivr namespace) elements or attributes which it cannot process, it MUST ignore them and continue processing. [Editors Note:IVR05 One use case which is not covered by this specification is that of attaching a dialog toplay | Table 3 | | | | | | | iterations | input | maximum iterations | Table 4 | | | | | | | duration | input | maximum duration fora connection, which itself is attached to a conference, and allowing that dialog to repeatedly collect and return matching DTMF without terminating. The current specification requires that the| Table 5 | | | |dialogincluding iterations | | | | | | | | interval | input | timeexits at the end of its DTMF collection. For the next collection cycle, a new dialog would need toelapse between | Table 6 | | | | successive iterations | | | | | | | | maxage | input | maxage cache controlbe started. If the use case is in scope for| Table 7 | | | |this package, then the definition of <basicivr> could be modified as follows: 1. A signalmode attribute/element is added to <basicivr> indicating the conditions under which the dialog sends a (non-terminating) notification event (TBD). If any of its child elements completes with a termmode value matching a condition (e.g. a 'match' from <collect>), then information collected by the children is returned to the AS in a notification event. The dialog is always restarted and it needs to be terminated by the AS (unless an error occurs). 2. If the signalmode attribute/element is not specified, then the behavior is as currently defined. 3. Note that if media prompts| | | | | | | | maxstale | input | maxstale cache control for | Table 8 | | | |were specified, the same prompts| | | | | | | | speed | input | playback speed forwould play repeatedly - a more sophisticated approach would be required to play different prompts| Table 9 | | | | | | | volume |on different termmodes like nomatch, noinput, etc Working Group input| playback volumeis needed to determined if this use case is in scope forprompts | Table 10 | | | | | | | offset | input |this package and whether this type of solution is adequate.] 5.1. <basicivr> A dialog to playfrom offset inprompts| Table 11 | | | | | | | status | output | status code | Table 12 | | | | | | | reason | output | reason for status | Table 13 | +------------+-----------+-----------------------------+------------+ Table 2: playannouncement parameter overview Note that playannouncement requires at least one promptto the user, collect DTMF or record input. The dialog is specified using a <basicivr> element with the namespace defined inprompts. +-------------+-----------------------------------------------------+ | Name | prompts | +-------------+-----------------------------------------------------+ | Description | One or more promptsSection 11.2. A <basicivr> element has the following attributes: version: a string specifying the version of the basicivr package. The attribute is optional. The default value is '1.0'. The <basicivr> element has the following child elements: <prompt>: defines media resources to play| | | | | Direction |in sequence (see Section 5.2). The element is optional. <collect>: defines how DTMF is collected (see Section 5.3). The element is optional. <record>: defines how recording takes place (see Section 5.4). The element is optional. It is an error if no child element is specified. The behavior is not defined if both <collect> and <record> are specified. 5.2. <prompt> The <prompt> element specifies a sequence of media resources to play. A <prompt> element has the following attributes: xml:base: A string declaring the base URI from which relative URIs in child elements are resolved. A valid value is a URI (see Section 8.9). The attribute is optional. bargein: Indicates whether user input| | | | | Type | URIList | | | | | Optional | No | | | | | Possible |stops prompt playback. A validURIList whichvalue isnon-empty | | Values | | | | | | Default | none | +-------------+-----------------------------------------------------+ Table 3: prompts +-------------+-----------------------------------------------------+ | Name | iterations | +-------------+-----------------------------------------------------+ | Description | Maximuma boolean (see Section 8.1). A value of true indicates that bargein is permitted and prompt playback is stopped. A value of false indicates that bargein is not permitted: user input does not terminate prompt playback. The attribute is optional. The default value is true. iterations: number of times theplayannouncement dialog | | |prompt is to beplayed | | | | | Direction | input | | | | | Type | Non-Negative Integer | | | | | Optional | Yes | | | | | Possible |played. A valid value is a non-negativeinteger.integer (see Section 8.4). A value of 0| | Values |indicates that thedialogprompt is repeated until halted| | |by other means.| | | | | Default | 1 | +-------------+-----------------------------------------------------+ Table 4: iterations +-------------+-----------------------------------------------------+ | Name | duration | +-------------+-----------------------------------------------------+ | Description | MaximumThe attribute is optional. The default value is 1. duration: maximum duration for thedialog iterations | | | | | Direction | input | | | | | Type | Time Designation | | | | | Optional | Yes | | | | | Possible |prompt playback. A validTimeDesignation value.value is a Time Designation (see Section 8.7). If no value is| | Values |specified, then there is no limit on the duration| | |of thedialog | | | | | Default | none | +-------------+-----------------------------------------------------+ Table 5: duration +-------------+-----------------------------------------------------+ | Name | interval | +-------------+-----------------------------------------------------+ | Description | time to elapse between successive iterations | | | | | Direction | input | | | | | Type | Time Designation | | | | | Optional | Yes | | | | | Possible | A valid TimeDesignation value. | | Values | | | | | | Default | 0s | +-------------+-----------------------------------------------------+ Table 6: interval +-------------+-----------------------------------------------------+ | Name | maxage | +-------------+-----------------------------------------------------+ | Description | maxage cache control for prompts | | | | | Direction | input | | | | | Type | Non-Negative Integer | | | | | Optional | Yes | | | | | Possible | A valid non-negative integer. The value indicates | | Values | that the media server can use cached prompt | | | resources whose age must be no greater than | | | specified time in seconds (cf. 'max-age' in HTTP | | | 1.1 [RFC2616]).prompt. Themedia server will not use | | | stale resources, unless a maxstale valueattribute is optional. There isalso | | | provided. | | | | | Default | none | +-------------+-----------------------------------------------------+ Table 7: maxage +-------------+-----------------------------------------------------+ | Name | maxstale | +-------------+-----------------------------------------------------+ | Description | Maxstale cache control for prompts | | | | | Direction | input | | | | | Type | Non-Negative Integer | | | | | Optional | Yes | | | | | Possible | A valid non-negative integer. The value indicates | | Values | that the media server can use cached prompt | | | resources which have exceeded their expiration time | | | bynomore than the specified number of seconds | | | (cf. 'max-stale' in HTTP 1.1 [RFC2616]). | | | | | Default | none | +-------------+-----------------------------------------------------+ Table 8: maxstale +-------------+-----------------------------------------------------+ | Name | speed | +-------------+-----------------------------------------------------+ | Description | Playback speeddefault value. volume: playback volume forprompts | | | | | Direction | input | | | | | Type | Percentage | | | | | Optional | Yes | | | | | Possible | A valid percentage indicating rate increase or | | Values | decrease relative totheoriginal rate of the | | | media.prompt. A valid valueof 100% (the default) indicates no | | | modification of rate, 200% indicates twice the | | | original rate,is a percentage (see Section 8.4). The valueof 50%indicateshalf the | | | original rate, and so on. | | | | | Default | 100% | +-------------+-----------------------------------------------------+ Table 9: speed +-------------+-----------------------------------------------------+ | Name | volume | +-------------+-----------------------------------------------------+ | Description | Playback volume for prompts | | | | | Direction | input | | | | | Type | Percentage | | | | | Optional | Yes | | | | | Possible | A valid percentage indicatingincrease or decrease| | Values |relative to the original recorded volume of the| | |media. A value of 100% (the default) plays the| | |media at its recorded volume, a value of 200% will| | |play the media twice recorded volume, 50% at half| | |its recorded volume, and so on.| | | | | Default | 100% | +-------------+-----------------------------------------------------+ Table 10: volume +-------------+-----------------------------------------------------+ | Name |The attribute is optional. The default value is 100%. offset: offset| +-------------+-----------------------------------------------------+ | Description | Offsetto begin playingprompts.the prompt. A valid value is a Time Designation (see Section 8.7). The offset is| | |measured in normal media playback time from the| | |beginning of theprompts. | | | | | Direction | input | | | | | Type | Time Designation | | | | | Optional | Yes | | | | | Possible | A valid time designation value. | | Values | | | | | | Default | 0s | +-------------+-----------------------------------------------------+ Table 11:media resource. The attribute is optional. The default value is 0s. The duration attribute takes priority over the iterations attribute in determining maximum duration of the prompt. [Editors Note:IVR06 iterations could be replaced with 'repeatCount', duration with 'repeatDur', volume could be replaced with 'soundLevel' and offset+-------------+-----------------------------------------------------+ | Name | status | +-------------+-----------------------------------------------------+ | Description | A status code indicating successwith 'clipBegin' for better alignment with SMIL and possibly VoiceXML.] [Editors Note:IVR07 should volume use a linear orfailurelogarithmic scaling?] The <prompt> element has the following child elements: <media>: media resource (see Section 5.2.1) to play. Multiple instances of this element are permitted. The element is optional. <variable>: specifies a variable media announcement (see Section 5.2.2) to play. Multiple instances of this element are permitted. The element is optional. <dtmf>: generates one or more DTMF tones (see Section 5.2.3) to play. Multiple instances of this element are permitted. The element is optional. It is an error if no child element is specified. Prompt playing has the| | | playannouncement dialog | | | | | Direction | output | | | | | Type | Non-Negative Integer | | | | | Optional | No | | | | | Possible | 1 for success; otherwisefollowing execution model upon initialization: 1. If an errorcode (600, 601, | | Values | 602). See Table 47 | | | | | Default | none | +-------------+-----------------------------------------------------+ Table 12:occurs during execution, then playback terminates and the error is reported in the status+-------------+-----------------------------------------------------+ | Name | reason | +-------------+-----------------------------------------------------+ | Description |attribute (see Section 5.5) of the <dialogexit> event. 2. Atextual description providing a reasoniterations counter is initialized to 0. 3. A timer is started for the| | | status code; e.g. details about an error | | | | | Direction | output | | | | | Type | String | | | | | Optional | Yes | | | | | Possible | A valid Stringvalue| | Values | | | | | | Default | Empty string | +-------------+-----------------------------------------------------+ Table 13: reason The following additional input parameters are under consideration for later versions: +-----------+-------------------------------------------------------+ | Name | Description | +-----------+-------------------------------------------------------+ | variables | references to common types such as money, time, | | | numbers, etc | +-----------+-------------------------------------------------------+ Table 14: Additional playannouncement parameters 5.2. Promptof the duration attribute. If the timer expires before playback is complete, then playback terminates andCollect A template dialogthe dialogexit result contains the <promptinfo> termmode attribute set toplay promptsmaxduration (see Section 5.5.1). 4. A playback cycle is initiated playing each <media>, <variable> andcollect DTMF input.<dtmf> in document order. Thedialogvalue of the volume attribute isinvoked withapplied to each <media> and <variable> if they are rendered as audio media. If theURI "promptandcollect". The dialog execution model consists of: 1. Clearingoffset attribute is specified, playback begins at that offset. If thedigit buffer depending onoffset is greater than thevaluecumulative duration ofcleardigitbuffer. 2. Playingthe child elements, then no prompts are played in theorder specified. Thecycle. 5. If the value of the bargeinparameter determines whetherattribute is true, then user inputcan be collected during promptcauses playbackstops (if so, promptto terminate and the dialogexit result contains the <promptinfo> termmode attribute is set to bargein (see Section 5.5.1). 6. If the playback cycle completes successfully, then the iterations counter isstopped). 3. Collecting DTMF input fromupdated. If theuser. Valid DTMF patterns are either a simple digit string wherecounter reaches themaximum lengthvalue of the iterations attribute, then playback isdetermined by maxdigits and may beterminatedbyand thecharacter in termchar; ordialogexit result contains acustom<promptinfo> termmode attribute set to completed (see Section 5.5.1). Otherwise, another playback cycle is initiated. [Editors Note:IVR08 Need to clarify that DTMFgrammar specified by grammar.used for VCR controls does not cause playback to be stopped, but causes the appropriate operation to be applied to the playing prompts. ] 5.2.1. <media> Theparameters timeout, interdigittimeout and termtimeout control user input timeout, interdigit timeout and<media> element specifies a media resource to play. A <media> element has theterminating timeout respectively. 4. Iffollowing attributes: src: specifies the location of the media resource. A valid value is a URI (see Section 8.9). The attribute is mandatory. type: specifies the type of the media resource indicated in the 'src' attribute. The type value may include additional parameters for guiding playback; for example, [RFC4281] defines a 'codec' parameter for 'bucket' media types like video/3gpp. A valid value is a MIME type (see Section 8.10). The attribute is optional. There is noinputdefault value. The <media> element has no children. It iscollectedan error if the media resource cannot be retrieved or played. 5.2.2. <variable> The <variable> element specifies variable announcements using predefined media resources. Each variable has at least a type (e.g. date) and a value (e.g. 2008-02-25). The value is rendered according to theinputvariable type (e.g. 25th February 2008) as well as other defined attributes. A <variable> element has the following attributes: value: specifies the string to be rendered. A valid value isinvalid, steps 1 - 3 are repeateda string (see Section 8.6). The attribute is mandatory. type: specifies the type to use for rendering. A valid value is a string (see Section 8.6). The attribute is mandatory. format: specifies format information to use in conjunction with the type for the rendering. A valid valueof iterations. 5. Returning status, reason and result parameters. [Editors Note:is a string (see Section 8.6). The attribute is optional. There is no default value. xml:lang: specifies theexecution model needslanguage tobe updateduse when rendering the variable. A valid value is a language identifier (see Section 8.11). The attribute is optional. The default value is platform-specific. [Editors Note:IVR09 do we need a gender attribute forhandling VCR commands like rewind and fast-forwards.]variable announcements? ] Theinput<variable> element has no children. This package is agnostic to which <variable> values, types andoutput parameterformats aresummarizedsupported by an implementation. However it is RECOMMENDED that an implementation support the following type/format combinations: type=date Supported formats: "mdy", "ymd", "dym" type=time Supported formats: "t12", "t24" type=digits Supported formats: "gen", "ndn", "crn", "ord" [Editors Note:IVR10 Further work needed on these definitions. Which other types anddefined below. +-------------------+-----------+----------------------+------------+ | Name | Direction | Description | Definition | +-------------------+-----------+----------------------+------------+ | prompts | input | promptsformats need to, or can, be specified? ] This specification is agnostic toplay | Table 16 | | | | | | | iterations | input | maximum attempts | Table 17 | | | | | | | cleardigitbuffer | input | dtmf buffer clearing | Table 18 | | | | | | | bargein | input | interruption of | Table 19 | | | | prompts | | | | | | | | timeout | input | timeout for user | Table 20 | | | | input | | | | | | | | interdigittimeout | input | timeout between | Table 21 | | | | digits | | | | | | | | termtimeout | input | terminating timeout | Table 22 | | | | | | | termchar | input | terminating | Table 23 | | | | character | | | | | | | | maxdigits | input | maximum numberthe type and codec of| Table 24 | | | | digits | | | | | | | | grammar | input | custom grammar | Table 25 | | | | | | | skipinterval | input | Intervalmedia resources into which variable are rendered. For example, an MS choosing toskip | Table 26 | | | | Backwards/Forwards | | | | | | | | ffkey | input | Mapssupport audio may render the <variable> into one or more audio media resources. It is an error if aDTMF key to<variable> element cannot be rendered successfully. Execution of this element can seen, at least logically, as conversion of a| Table 27 | | | | fast forward | | | | | operation equal to | | | | | skipinterval | | | | | | | | rwkey | input | Maps<variable> into aDTMF key tolist of <media> elements. For example, <variable value="2008-02-25" type="date" format="dmy" xml:lang="en"/> could be transformed into audio saying "twenty-fifth of February two thousand and eight" using a| Table 28 | | | | rewind operation | | | | | equal to | | | | | skipinterval | | | | | | | | status | output | status code | Table 29 | | | | | | | reason | output | reasonlist of <media> resources: <media src="voicebase/en/25th.wav"/> <media src="voicebase/en/of.wav"/> <media src="voicebase/en/february.wav"/> <media src="voicebase/en/2000.wav"/> <media src="voicebase/en/and.wav"/> <media src="voicebase/en/8.wav"/> 5.2.3. <dtmf> The <dtmf> element specifies a sequence of DTMF tones forstatus | Table 30 | | | | | | | result |output. DTMF tones could be generated using <media> resources where the output| input collected | Table 31 | +-------------------+-----------+----------------------+------------+ promptandcollect parameter overview +-------------+-----------------------------------------------------+ | Name | prompts | +-------------+-----------------------------------------------------+ | Description | Initial promptsis transported as RTP audio packets. However, <media> resources are not sufficient for cases where DTMF tones are toplay | | | | | Direction | input | | | | | Type | URIList | | | | | Optional | Yes | | | | | Possible |be transported as DTMF RTP ([RFC2833]) or in event packages. Avalid URIList | | Values | | | | | | Default | none | +-------------+-----------------------------------------------------+ Table 16: prompts +-------------+-----------------------------------------------------+ | Name | iterations | +-------------+-----------------------------------------------------+ | Description | Maximum number of times<dtmf> element has thepromptandcollect dialog | | |following attributes: digits: specifies the DTMF sequence to output. A valid value is a DTMF string (see Section 8.3). The attribute is mandatory. level: used to define the power level for which the DTMF tones will beplayed | | | | | Direction | input | | | | | Type | Non-Negative Integer | | | | | Optional | Yes | | | | | Possible |generated. Values are expressed in dBm0. A validnon-negative integer. Avalue is an integer in the range of 0| | Values | indicatesto -96 (dBm0). Larger negative values express lower power levels. Note that values lower than -55 dBm0 will be rejected by most receivers (TR-TSY-000181, ITU-T Q.24A). The attribute is optional. The default value is -6 (dBm0). duration: specifies thedialogduration for which each DTMF tone isrepeated until halted by | | | other means. | | | | | Default | 0 | +-------------+-----------------------------------------------------+ Table 17: iterations +-------------+-----------------------------------------------------+ | Name | cleardigitbuffer | +-------------+-----------------------------------------------------+ | Description | Cleargenerated. A valid value is a time designation (see Section 8.7). Implementations may round the value if they only support discrete durations. The attribute is optional. The default value is 100ms. interval: specifies the duration of a silence interval following each generated DTMF tone. A valid value is a time designation (see Section 8.7). Implementations may round the value if they only support discrete durations. The attribute is optional. The default value is 100ms. The <dtmf> element has no children. It is an error if a <dtmf> element cannot be processed successfully. 5.3. <collect> The <collect> element defines how DTMF input is collected. The <collect> element has the following attributes: cleardigitbuffer: indicates whether the digit bufferprioris toprompt playback | | | | | Direction | input | | | | | Type | Boolean | | | | | Optional | Yes | | | | | Possible |be cleared. A valid value is a booleanvalue.(see Section 8.1). A value of true indicates| | Values |that thedigitbufferdigit buffer is to be cleared. A value of| | |false indicates that thedigitbufferdigit buffer is not to be| | |cleared.| | | | | Default | true | +-------------+-----------------------------------------------------+ Table 18: 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 bargeinThe attribute ispermitted. Aoptional. The default valueof false | | | indicates that bargeinisnot permitted. | | | | | Default | true | +-------------+-----------------------------------------------------+ Table 19: bargein +-------------+-----------------------------------------------------+ | Name | timeout | +-------------+-----------------------------------------------------+ | Description | Indicatestrue. timeout: indicates the time to wait for userinput | | | | | Direction | input | | | | | Type | Time Designation | | | | | Optional | Yes | | | | | Possible |input. A validTimeDesignation value. | | Values | | | | | | Default | 5s | +-------------+-----------------------------------------------------+ Table 20: timeout +-------------+-----------------------------------------------------+ | Name | interdigittimeout | +-------------+-----------------------------------------------------+ | Description |value is a Time Designation (see Section 8.7). The attribute is optional. The default value is 5s. interdigittimeout: indicates inter-digit timeout value to use when| | |recognizing DTMFinput | | | | | Direction | input | | | | | Type | Time Designation | | | | | Optional | Yes | | | | | Possible |input. A validTimeDesignation value. | | Values | | | | | | Default | 2s | +-------------+-----------------------------------------------------+ Table 21: interdigittimeout +-------------+-----------------------------------------------------+ | Name | termtimeout | +-------------+-----------------------------------------------------+ | Description |value is a Time Designation (see Section 8.7). The attribute is optional. The default value is 2s. termtimeout: indicates the terminating timeout value to use when recognizing| | |DTMFinput | | | | | Direction | input | | | | | Type |input. A valid value is a Time Designation| | | | | Optional | Yes | | | | | Possible |(see Section 8.7). The attribute is optional. The default value is 0s. escapekey: specifies a DTMF key that indicates the DTMF collection is to be re-initiated. A validTimeDesignation value. | | Values | | | | | | Default | 0s | +-------------+-----------------------------------------------------+ Table 22: termtimeout +-------------+-----------------------------------------------------+ | Name | termchar | +-------------+-----------------------------------------------------+ | Description |value is a DTMF Character (see Section 8.2). Theterminatingattribute is optional. There is no default value. termchar: specifies a DTMF character for terminating DTMF input| | | recognition. This parameter is ignored ifcollection using the| | | grammar parameter is specified. | | | | | Direction | input | | | | | Type | DTMFChar | | | | | Optional | Yes | | | | | Possible |internal grammar. A validDTMFChar value.value is a DTMF character (see Section 8.2). To disable termination by| | Values |a conventional DTMF character, set the parameter to| | |an unconventional character like 'A'.| | | | | Default | # | +-------------+-----------------------------------------------------+ Table 23: termchar +-------------+-----------------------------------------------------+ | Name | maxdigits | +-------------+-----------------------------------------------------+ | Description |The attribute is optional. The default value is '#'. maxdigits: 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 24: 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 validURIvaluereferencingis avalid custom DTMF | | Values | grammar. | | | | | Default | none | +-------------+-----------------------------------------------------+ Table 25: grammar [Editors note:positive integer (see Section 8.5). Theformat of the custom DTMF grammarattribute isnot yet defined. Possibilities include: [SRGS], [H.248.1], and [RFC4730]. If more than one formatoptional. The default value ispermitted, then an additional input parameter "grammartype" would indicate the format used in the grammar parameter.] +-------------+-----------------------------------------------------+ | Name | skipinterval | +-------------+-----------------------------------------------------+ | Description | An indication of5. skipinterval: indicates how far amedia serverMS should skip| | |backwards or forwards through prompt playback when the rewind (rwkey) of| | |fast forward key (ffkey) is pressed.| | | | | Direction | input | | | | | Type | Time Designation | | | | | Optional | Yes | | | | | Possible |A validtime designation value. | | Values | | | | | | Default | 6s | +-------------+-----------------------------------------------------+ Table 26: skipinterval +-------------+-----------------------------------------------------+ | Name | ffkey | +-------------+-----------------------------------------------------+ | Description | Mapsvalue is a Time Designation (see Section 8.7). The attribute is optional. The default value is 6s. ffkey: maps a DTMF key to a fast forward operation equal| | |to the value of 'skipinterval'.| | | | | Direction | input | | | | | Type | DTMFChar | | | | | Optional | Yes | | | | | Possible |A validDTMFCharvalue is a DTMF Character (see Section 8.2). The attribute is optional. There is no default value.| | Values | | | | | | Default | none | +-------------+-----------------------------------------------------+ Table 27: ffkey +-------------+-----------------------------------------------------+ | Name | rwkey | +-------------+-----------------------------------------------------+ | Description | Mapsrwkey: maps a DTMF key to a rewind operation equal to the| | |value of 'skipinterval'.| | | | | Direction | input | | | | | Type | DTMFChar | | | | | Optional | Yes | | | | | Possible |A validDTMFCharvalue is a DTMF Character (see Section 8.2). The attribute is optional. There is no default value.| | Values | | | | | | Default | none | +-------------+-----------------------------------------------------+ Table 28: rwkey +-------------+-----------------------------------------------------+ | 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 47 | | | | | Default | none | +-------------+-----------------------------------------------------+ Table 29: status +-------------+-----------------------------------------------------+ | Name | reason | +-------------+-----------------------------------------------------+ | Description | A textual description providingpauseinterval: indicates how long areason forMS should pause prompt playback when the| | | status code; e.g. details on an error | | | | | Direction | output | | | | | Type | String | | | | | Optional | Yes | | | | | Possible |pausekey is pressed. A validStringvalue| | Values | | | | | | Default | Empty string | +-------------+-----------------------------------------------------+ Table 30: reason +-------------+-----------------------------------------------------+ | Name | result | +-------------+-----------------------------------------------------+ | Description |is a Time Designation (see Section 8.7). The attribute is optional. The default value is 10s. pausekey: maps a DTMFinput collected fromkey to a pause operation equal to theuser. | | | | | Direction | output | | | | | Type | DTMFString | | | | | Optional | The parametervalue of 'pauseinterval'. A valid value ismandatory if statusa DTMF Character (see Section 8.2). The attribute is1; | | | otherwise,optional.| | | | | Possible |There is no default value. resumekey: maps a DTMF key to a resume operation. A validDTMFString (no spaces between characters). | | Values | | | | | | Default | Empty String | +-------------+-----------------------------------------------------+ Table 31: result In addition tovalue is a DTMF Character (see Section 8.2). The attribute is optional. There is no default value. volumeinterval: indicates theprompt extensions describedincrease or decrease inTable 14, the following parameters are under consideration for later versions: +--------------------+----------------------------------------------+ | Name | Description | +--------------------+----------------------------------------------+ | nomatchprompts | promptsplayback volume (relative toplaythe current volume) wheninput doesn't matchthe| | |volupkey or voldnkey is pressed. A valid value is a percentage (see Section 8.8). The attribute is optional. The default value is 10%. volupkey: maps a DTMFgrammar | | | | | noinputprompts | promptskey toplay when there is no user input | | | | | successprompts | promptsa volume increase operation equal toplay when user inputthe value of 'volumeinterval'. A valid value is a DTMF Character (see Section 8.2). The attribute is optional. There iscollected | | | | | failureprompts | prompts to play whennovalid user input has | | | been collected after all iterations tried | | | | | escapechar | character which causes the dialogdefault value. voldnkey: maps a DTMF key to a volume decrease operation equal torestart | | | without incrementingtheiterations counter | | | | | iterationcount | number of iterations (output) | | | | | promptplayedamount | durationvalue ofinitial prompts played'volumeinterval'.A valid value is a DTMF Character (see Section 8.2). The attribute is optional. There is no default value. It is an error ifprompt | | | interrupted (output) | +--------------------+----------------------------------------------+ 5.3. Promptany VCR key (ffkey, rwkey, pausekey, resumekey, volupkey, voldnkey) is specified with the same value except that the pausekey andRecord A template dialogresumekey may have the same value. [Editors Note:IVR11 Do we need a speed VCR control as well? ] [Editors Note:IVR12 it has been proposed that termchar should be replaced by termkeys (DTMF string value) topromptallow termination by multiple characters (e.g. '**'). An additional attribute would probably also be need to control interdigit timing within this string. Is this functionality required for this package?] The <collect> element has theuser and record their audio (or other media) input.following child elements: <grammar>: indicates a custom grammar format (see Section 5.3.1). Thedialogelement isinvoked with the URI "promptandrecord".optional. Thedialogcustom grammar takes priority over the internal grammar. If a <grammar> element is specified, it MUST be used for DTMF collection. DTMF collection has the following execution modelconsists of:upon initialization: 1.Playing prompts in the order specified until completion. 2. Recording input fromIf an error occurs during execution, then collection terminates and theusererror is reported in themimetype format. Recordingstatus attribute (see Section 5.5) of the <dialogexit> event. 2. The digit buffer isinitiatedcleared ifuser inputthe value of the cleardigitbuffer attribute isreceived beforetrue. 3. A timer with the duration of the value of the timeoutexpires. The recordingattribute isterminated byactivated. If the timer expires before DTMFinput,input collection has completed, then collection execution terminates and themaximum duration being exceeded ordialogexit result contains afinal silence after recording, as specified in dtmfterm, maxtime and finalsilence parameters respectively. Use of VAD (Voice Activity Detection)<collectinfo> (see Section 5.5.2) with the termmode attribute set toinitiate and terminate recording is controlled by vadinitial and vadfinal respectively. 3.noinput. 4. IfrecordingDTMF input matches any VCR keys (for example the ffkey), then the appropriate operation is applied to the active prompts; this is a no-op if a prompt is notinitiated, steps 1 - 2specified, or there arerepeated forno active prompts. If a seek operation (ffkey, rwkey) attempts to go beyond thevaluebeginning or end ofiterations. 4. Returning status, reason and result parameters. The input andthe prompt queue, then it is automatically truncated to the prompt beginning or end respectively. If the pause operation attempts to pause outputparameter are summarized and defined below. +--------------+-----------+---------------------------+------------+ | Name | Direction | Description | Definition | +--------------+-----------+---------------------------+------------+ | prompts | input |when it is already paused, then the operation is ignored. If the resume operation attempts to resume when the prompts are not paused, then the operation is ignored. If a volume operations attempts toplay | Table 34 | | | | | | | iterations | input |go beyond the minimum or maximumattempts | Table 35 | | | | | | | timeout |volume supported by the platform, then the operation is ignored. DTMF input| timeout to waitmatching VCR controls is ignored for grammar matching. 5. If DTMF input| Table 36 | | | | | | | mimetype | input | mimetypematches the value of therecording | Table 37 | | | | | | | vadinitial | input | whether VADescapekey attribute, then the timer isused to | Table 38 | | | | initiate recording | | | | | | | | vadfinal |canceled and DTMF collection is re-initialized. 6. Other DTMF input| whether VADisusedmatched to| Table 39 | | | | terminate recording | | | | | | | | dtmf | input | recordingthe grammar. Valid DTMF patterns are either a simple digit string where the maximum length is determined by the maxdigits attribute and may be terminated by| Table 40 | | | |the character in the termchar attribute; or a custom DTMF| | | | | | | | maxtime | input | maximum duration of | Table 41 | | | | recording | | | | | | | | finalsilence |grammar specified with the <grammar> element. The attributes interdigittimeout and termtimeout control interdigit timeout and the terminating timeout respectively. 7. If the input| final silence to | Table 42 | | | | terminate recording | | | | | | | | status | output | status code | Table 43 | | | | | | | reason | output | reason for status | Table 44 | | | | | | |completely matches the grammar, the timer is canceled, collection execution terminates and the dialogexit result| output | URI for recording | Table 45 | +--------------+-----------+---------------------------+------------+ +-------------+-----------------------------------------------------+ | Name | prompts | +-------------+-----------------------------------------------------+ | Description | Initial promptscontains a <collectinfo> (see Section 5.5.2) with the termmode attribute set toplay | | | | | Direction |match. 8. If the input| | | | | Type | URIList | | | | | Optional | Yes | | | | | Possible | A valid URIList | | Values | | | | | | Default | none | +-------------+-----------------------------------------------------+ Table 34: prompts +-------------+-----------------------------------------------------+ | Name | iterations | +-------------+-----------------------------------------------------+ | Description | Maximum numberdoes not match the grammar, the timer is canceled, collection execution terminates and the dialogexit result contains a <collectinfo> (see Section 5.5.2) with the termmode attribute set to nomatch. 5.3.1. <grammar> The <grammar> element allows a custom grammar, inline or external, to be specified. Custom grammars permit the full range oftimesDTMF characters including '*' and '#' to be specified for DTMF pattern matching. The <grammar> element has thepromptandrecord dialog | | | is to be played | | | | | Direction | input | | | | | Type | Non-Negative Integer | | | | | Optional | Yes | | | | | Possible |following attributes: src: specifies the location of an external grammar. A validnon-negative integer.value is a URI (see Section 8.9). The attribute is optional. There is no default value. type: identifies the preferred type of the grammar document identified by the src attribute. A valid value is a MIME type (see Section 8.10). The attribute is optional. There is no default value. The <grammar> element allows inline grammars to be specified. XML grammar formats MUST use a namespace other than the one used in this specification. Non-XML grammar formats MAY use a CDATA section. The MS MUST support the [SRGS] grammar format and MS MAY support KPML ([RFC4730]) or other grammar formats. It is an error if a grammar format is specified which is not supported by the MS. [Editors Note:IVR13 One drawback of0 | | Values | indicatesusing <grammar> with an inline custom grammar is that nested <grammar> elements are needed for SRGS: i.e. custom <grammar> element and inside that a <grammar> element in the SRGS namespace. The alternative would be (a) <grammar> element is only for external grammars, and (b) inline grammars are specified as children of <collect> (with suitable co-occurrence restrictions). Feedback is required to determined if the nesting is confusing or not. ] Example: in CONTROL message from AS to MS, the following request starts a dialog where DTMF collection isrepeated until halted | | |determined byother means. | | | | | Default | 0 | +-------------+-----------------------------------------------------+ Table 35: iterations +-------------+-----------------------------------------------------+ | Name | timeout | +-------------+-----------------------------------------------------+ | Description | Indicatesan inline SRGS grammar: <dialogstart connectionid="con1"> <basicivr> <collect cleardigitbuffer="false" timeout="20s" interdigittimeout="1s" skipinterval="10s" rwkey="4" ffkey="6"> <grammar> <grammar xmlns="http://www.w3.org/2001/06/grammar" version="1.0" mode="dtmf"> <rule id="digit"> <one-of> <item>0</item> <item>1</item> <item>2</item> <item>3</item> <item>4</item> <item>5</item> <item>6</item> <item>7</item> <item>8</item> <item>9</item> </one-of> </rule> <rule id="pin" scope="public"> <one-of> <item> <item repeat="4"> <ruleref uri="#digit"/> </item>#</item> <item>* 9</item> </one-of> </rule> </grammar> </grammar> </collect> </basicivr> </dialogstart> The same grammar could also be referenced externally (and take advantage of HTTP caching): <dialogstart connectionid="con1"> <basicivr> <collect cleardigitbuffer="false" timeout="20s" interdigittimeout="1s" skipinterval="10s" rwkey="4" ffkey="6"> <grammar type=""application/srgs+xml" src="http://example.org/pin.grxml/> </collect> </basicivr> </dialogstart> See Section 6 and Section 7 for further examples. 5.4. <record> The <record> element defines how media input is recorded. The <record> element has the following attributes: timeout: indicates the time to wait for user input.| | | | | Direction | input | | | | | Type |A valid value is a Time Designation| | | | | Optional | Yes | | | | | Possible |(see Section 8.7). The attribute is optional. The default value is 5s. type: specifies the type of the resulting recording format. The type value may include additional parameters for guiding recording; for example, [RFC4281] defines a 'codec' parameter for 'bucket' media types like video/3gpp. A validTimeDesignation value. | | Values | | | | | | Default | 5s | +-------------+-----------------------------------------------------+ Table 36: timeout +-------------+-----------------------------------------------------+ | Name | mimetype | +-------------+-----------------------------------------------------+ | Description |value is a MIME type (see Section 8.10). Themediaattribute is optional. There is no default value (recording format is MS-specific). dest: specifies the location of the resulting recording.| | | | | Direction | input | | | | | Type | mimetype | | | | | Optional | Yes | | | | | Possible |The MS MAY stream the recorded data to the location as recording occurs. A validmimetype value. | | Values | | | | | | Default | None | +-------------+-----------------------------------------------------+ Table 37: mimetype +-------------+-----------------------------------------------------+ | Name | vadinitial | +-------------+-----------------------------------------------------+ | Description |value is a URI (see Section 8.9). The attribute is optional. If not specified, the MS MUST provide a recording location URI; this recording is available until the connection or conference associated with the dialog is destroyed. vadinitial: Control whether voice activity detection can be| | |used to initiate the recording| | | | | Direction | input | | | | | Type | Boolean | | | | | Optional | Yes | | | | | Possible |operation. A validBoolean value.value is a boolean (see Section 8.1). A value of true indicates| | Values |recording may be initiated using voice activity| | |detection. A value of false indicates that| | |recording must not be initiated using voice| | |activity detection.| | | | | Default | true | +-------------+-----------------------------------------------------+ Table 38: vadinitial +-------------+-----------------------------------------------------+ | Name | vadfinal | +-------------+-----------------------------------------------------+ | Description |The attribute is optional. The default value is true. vadfinal: Control whether voice activity detection can be| | |used to terminate the recording| | | | | Direction | input | | | | | Type | Boolean | | | | | Optional | Yes | | | | | Possible |operation. A validBoolean value.value is a boolean (see Section 8.1). A value of true indicates| | Values |recording may be terminated using voice activity| | |detection. A value of false indicates that| | |recording must not be terminated using voice| | |activity detection.| | | | | Default | true | +-------------+-----------------------------------------------------+ Table 39: vadfinal +-------------+-----------------------------------------------------+ | Name | dtmfterm | +-------------+-----------------------------------------------------+ | Description |The attribute is optional. The default value is true. dtmfterm: Indicates whether the recordingcan beoperation is terminated by| | |DTMFinput | | | | | Direction | input | | | | | Type | Boolean | | | | | Optional | Yes | | | | | Possible |input. A validBoolean value.value is a boolean (see Section 8.1). A value of true indicates| | Values |that recordingcan beis terminated byDTMF.DTMF input. A value| | |of false indicates that recordingcannot be | | |is not terminated byDTMF. | | | | | Default | true | +-------------+-----------------------------------------------------+ Table 40: dtmfterm +-------------+-----------------------------------------------------+ | Name | maxtime | +-------------+-----------------------------------------------------+ | Description |DTMF input. The attribute is optional. The default value is true. maxtime: indicates The maximum duration of therecording | | | | | Direction | input | | | | | Type |recording. A valid value is a Time Designation| | | | | Optional | Yes | | | | | Possible |(see Section 8.7). The attribute is optional. The default value is 15s. beep: indicates whether a 'beep' should be played immediately prior to initiation of the recording operation. A validTimeDesignation value. | | Values | | | | | | Default | 15s | +-------------+-----------------------------------------------------+ Table 41: maxtime +-------------+-----------------------------------------------------+ | Name | finalsilence | +-------------+-----------------------------------------------------+ | Description |value is a boolean (see Section 8.1). The attribute is optional. The default value is false. finalsilence: indicates the interval of silence that indicates end of| | |speech. This parameter is ignored if vadfinal (vadfinal) has| | |the value false.| | | | | Direction | input | | | | | Type | Time Designation | | | | | Optional | Yes | | | | | Possible |A validTimeDesignation value. | | Values | | | | | | Default | 5s | +-------------+-----------------------------------------------------+ Table 42: 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; otherwisevalue is a Time Designation (see Section 8.7). The attribute is optional. The default value is 5s. It is an errorcode (600, 601, | | Values | 603). See Table 47 | | | | | Default | none | +-------------+-----------------------------------------------------+ Table 43: status +-------------+-----------------------------------------------------+ | Name | reason | +-------------+-----------------------------------------------------+ | Description | A textual description providingif areason fordest attribute is specified and 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 44: reason +-------------+-----------------------------------------------------+ | Name | result | +-------------+-----------------------------------------------------+ | Description | A URI referencingMS does not understand themedia recording | | | | | Direction | output | | | | | Type |URI| | | | | Optional |protocol, cannot locate the URI, or cannot send recorded data successfully to the location. Theparameter<record> element has no child elements. Recording has the following execution model upon initialization: 1. If an error occurs during execution, then recording terminates and the error ismandatory ifreported in the status attribute (see Section 5.5) of the <dialogexit> event. 2. If a beep attribute with the value of true is1; | | | otherwise, optional. | | | | | Possible |specified, then a beep tone is played. 3. Avalid URItimer with the duration of the value| | Values | | | | | | Default | Empty string | +-------------+-----------------------------------------------------+ Table 45: result In addition toof theprompt extensions described in Table 14,timeout attribute is activated. If thefollowing additional parameters are under consideration fortimer expires before the recording operation is completed, then recording execution terminates and the dialogexit result contains alater version. +--------------------+----------------------------------------------+ | Name | Description | +--------------------+----------------------------------------------+ | destination | URI<recordinfo> (see Section 5.5.3) with the termmode attribute set tosendnoinput. 4. Initiation of the recordingusing HTTP | | | | | beep | indicates whether a platform-specific beep | | |operation depends on the value of the vadinitial attribute. If vadinitial has the value false, then the recording operation isused immediately prior toinitiated immediately. Otherwise, the recording| | | | | noinputprompts | prompts to playoperations is initiated whentherevoice activity isnodetected. 5. When the recording operation is initiated, a timer is started for the value of the maxtime attribute. If the timer expires before the recording operation is complete, then recording execution terminates and the dialogexit result contains a <recordinfo> (see Section 5.5.3) with the termmode attribute set to maxtime. 6. During the record operation user media input| | | | | successprompts | prompts to play whenis recording in the format specified by the value of the type attribute. If the dest attribute issuccessful | | | | | failureprompts | promptsspecified, then recorded input is sent toplay when no recordingthat location. Otherwise, MS uses an internal location. 7. If the dtmfterm attribute hasbeen | | | made after alltheiterations tried | | | | | duration | duration ofvalue true and DTMF input is detected during the record operation, then the recording(output) | | | | | mimetype | mimetype ofterminates and and the dialogexit result contains a <recordinfo> (see Section 5.5.3) with the termmode attribute set to dtmf. 8. If vadfinal attribute has the value true, then the recording(output) | | | | | iterationcount | number of iterations (output) | | | | | terminationmode | indicationoperation is terminated when a period ofwhy recording terminated: e.g. | | | dtmf, maxtime reached, externalevent or | | | finalsilence detected (output) | | | | | promptplayedamount |silence, with the duration specified by the value ofinitial prompts played if prompt | | | interrupted (output) | +--------------------+----------------------------------------------+ 5.4. Status Codesthe finalsilence attribute, is detected. Thefollowing table describesdialogexit result contains a <recordinfo> (see Section 5.5.3) with thecodes returnedtermmode attribute set to finalsilence. 5.5. Exit Information When a basic ivr dialog exits, information is reported in a <dialogexit> notification event. The content model of thestatus output parameter for template dialogs. +-----------+-------------------------------------------------------+ | status | description | +-----------+-------------------------------------------------------+ | 0 | dialog terminated externally | | | | | 1 | success | | | | | 600 | unspecified error | | | | | 601 | invalid input parameter | | | | | 602 | no prompts<dialogexit> element defined(only playannouncement) | | | | | 603 | maximum iterations reached without valid input (not | | | playannouncement) | +-----------+-------------------------------------------------------+ Table 47: status codes for all templates dialogs 5.5. Type Definitions This section defines types referencedintemplate parameters. 5.5.1. BooleanSection 4.3.2 is extended with the following child elements: <promptinfo>: reports information about the prompt execution (see Section 5.5.1). Thevalue space of booleanelement is optional. <collectinfo>: reports information about theset {true, false}. 5.5.2. DTMFChar A DTMF character.collect execution (see Section 5.5.2). Thevalue spaceelement is optional. <recordinfo>: reports information about theset {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 Integerrecord execution (see Section 5.5.3). Thevalue spaceelement is optional. 5.5.1. <promptinfo> The <promptinfo> element reports the information about prompt execution. It has the following attributes: duration: indicates the cumulative duration of prompt playing in milliseconds. A valid value is a non-negative integer (see Section 8.4). The attribute is optional. There is no default value. iterations: indicates theinfinite set {0,1,2,...}. 5.5.5. Positive Integer The value spacenumber of iterations played completely. A valid value is a positive integer (see Section 8.5). The attribute is optional. There is no default value. termmode: indicates how playback was terminated. Valid values are: 'completed', 'maxduration' or 'bargein'. The attribute is mandatory. The <promptinfo> element has no child elements. 5.5.2. <collectinfo> The <collectinfo> element reports theinfinite set {1,2,...}. 5.5.6. String A string ininformation about collect execution. It has thecharacter encoding associated withfollowing attributes: dtmf: DTMF input collected from theXML element. 5.5.7. Time Designationuser. Atime designation consists of a non-negative real number followed byvalid value is atime unit identifier.DTMF string (see Section 8.3 with no space between characters. Thetime unit identifiersattribute is optional. There is no default value. termmode: indicates how collection was terminated. Valid values are:"ms" (milliseconds) and "s" (seconds). Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s". 5.5.8. Percentage'match', 'noinput' or 'nomatch'. The attribute is mandatory. The <collectinfo> element has no child elements. 5.5.3. <recordinfo> The <recordinfo> element reports the information about record execution. It has the following attributes: recording: references the location to which media is recorded. Apercentage consists ofvalid value is aPositive Integer followed by "%". Examples include: "100%", "500%" and "10%". 5.5.9.URIUniform Resource Indicator as defined(see Section 8.9). The attribute is optional. There is no default value. type: indicates the format of the recording. A valid value is a MIME type (see Section 8.10). The attribute is optional. There is no default value. duration: indicates the duration of the recording in[RFC2396]. 5.5.10. URIListmilliseconds. Alistvalid value is a non-negative integer (see Section 8.4). The attribute is optional. There is no default value. size: indicates the size ofURIs. 5.5.11. mimetypethe recording in bytes. Astring formated asvalid value is aIANA mimetype.non-negative integer (see Section 8.4). The attribute is optional. There is no default value. termmode: indicates how recording was terminated. Valid values are: 'noinput', 'dtmf', 'maxtime', and 'finalsilence'. The attribute is mandatory. The <recordinfo> element has no child elements. 6. AS-MS Dialog Interaction Examples The following example assume a control channel has been established as described in theSIPMedia Control Channel Framework[SIPCF].([MCCF]). The XML messages are in angled brackets; the REPORT status is in round brackets. Other aspects of the protocol are omitted for readability. 6.1. Starting an IVR dialog An IVR dialog is started successfully, and dialogexit notification <event> is sent from the MS to the AS when the dialog exits normally. Application Server (AS) Media Server (MS) | | | (1) CONTROL: <dialogstart> | | ----------------------------------------> | | | | (2) 202 | | <--------------------------------------- | | | |(3) REPORT: (pending) | | <---------------------------------------- | | | | (4) 200 | | ----------------------------------------> | || |(5)(3) REPORT: <response status="200"/> | | (terminate) | | <---------------------------------------- | | | |(6)(4) 200 | | ----------------------------------------> | | | |(7) REPORT:<event name="dialogexit"/>(5) CONTROL: <event ... /> | |(notify)| | <---------------------------------------- | | | |(8)(6) 200 | | ----------------------------------------> | | | 6.2. IVR dialog fails to start An IVR dialog fails to start due to an unknowntemplate.dialog type. Application Server (AS) Media Server (MS) | | | (1) CONTROL: <dialogstart> | | ----------------------------------------> | | | | (2) 202 | | <--------------------------------------- | | | | (3) REPORT:(pending) | | <---------------------------------------- | | | | (4) 200 | | ----------------------------------------> | | | | (5) REPORT:<response status="409"/> | | (terminate) | | <---------------------------------------- | | | |(6)(4) 200 | | ----------------------------------------> | | | 6.3. Preparing and starting an IVR dialog An IVR dialog is prepared and started successfully, and then the dialog exits normally. Application Server (AS) Media Server (MS) | | | (1) CONTROL: <dialogprepare> | | ----------------------------------------> | | | | (2) 202 | | <--------------------------------------- | | | | (3) REPORT:(pending) | | <---------------------------------------- | | | | (4) 200 | | ----------------------------------------> | | | | (5) REPORT:<response status="200"/> | | (terminate) | | <---------------------------------------- | | | |(6)(4) 200 | | ----------------------------------------> | | | |(7)(5) CONTROL: <dialogstart> | | ----------------------------------------> | | | |(8)(6) 202 | | <--------------------------------------- | | | |(9) REPORT: (pending) | | <---------------------------------------- | | | | (10) 200 | | ---------------------------------------> | | | | (11)(7) REPORT: <response status="200"/> | | (terminate) | | <---------------------------------------- | | | |(12)(8) 200 | | ----------------------------------------> | | | |(13) REPORT:<event name="dialogexit"/>| | (notify)(9) CONTROL: <event .../> | | <---------------------------------------- | | | |(14)(10) 200 | | ----------------------------------------> | | | 6.4. Terminating a dialogimmediatelyAn IVR dialog is started successfully, and then terminatedimmediatelyby the AS.No dialog notification <event>s areThe dialogexit event is sentbackby to theAS. 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 toAS when the<dialogterminate/> request is carried on a framework 200 response. 6.5. Terminating a dialog non-immediately An IVRdialogis 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.exits. Application Server (AS) Media Server (MS) | | | (1) CONTROL: <dialogstart> | | ----------------------------------------> | | | | (2) 202 | | <--------------------------------------- | | | | (3) REPORT:(pending) | | <---------------------------------------- | | | | (4) 200 | | ----------------------------------------> | | | | (5) REPORT:<response status="200"/> | | (terminate) | | <---------------------------------------- | | | |(6)(4) 200 | | ----------------------------------------> | | | |(7)(5) CONTROL: <dialogterminate> | | ----------------------------------------> | | | |(8)(6) 200: <response status="200"/> | | <---------------------------------------- | | | |(9) REPORT:<event name="dialogexit"/> | | (notify)(7) CONTROL: <event .../> | | <---------------------------------------- | | | |(10)(8) 200 | | ----------------------------------------> | | | Note that in(8)(6) theresponse<response> payload to the <dialogterminate/> request is carried on a framework 200response.response since it could complete the requested operation before the transaction timeout. 7.TemplateBasic IVR Dialog Examples The following examples show howplayannouncement, promptandcollect and promptandrecord template dialogs are<basicivr> is used with <dialogprepare>, <dialogstart> and <event>elements.elements to play prompts, collect DTMF input and record user input. The examples do not specify all messages between the AS and MS. 7.1.playannouncementPlaying announcements 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> <basicivr> <prompt> <media src="http://www.example.com/media/Number_09.wav"/> <media src="http://www.example.com/media/Number_11.wav"/> </prompt> </basicivr> </dialogprepare> If the dialog is prepared successfully, adialogprepared message<response> with status 200 is returned: <response status="200" dialogid="vxi78"/> The prepared dialog is then started on a conference playing the prompts twice: <dialogstart prepareddialogid="vxi78"conf-id="conference11"/>conferenceid="conference11"/> In the case of a successful dialog, the output is provided in <event>; for example <eventname="dialogexit"dialogid="vxi78"><data> <item name="status" value="1"/> </data> </event> In this example, the dialog is started on a sip dialog connection, but no <data> is specified: <dialogstart src="basicivr:playannouncement" connection-id="7HDY839~HJKSkyHS~HUwkuh7ns"/> and an error message is returned: <event name="dialogexit" dialogid="vxi79"> <data> <item name="status" value="602"/> <item name="reason" value="prompts not defined"/> </data><dialogexit status="1"> <promptinfo termmode="completed"/> </dialogexit> </event> 7.2.promptandcollectPrompt and collect This example plays no prompts and just waits for DTMF input from the user: <dialogstartsrc="basicivr:promptandcollect" connection-id="7HDY839~HJKSkyHS~HUwkuh7ns"/>connectionid="7HDY839~HJKSkyHS~HUwkuh7ns"> <basicivr> <collect/> </basicivr> </dialogstart> If the dialog is successful, then "dialogexit" <event> contains the dtmf collected in its result parameter: <eventname="dialogexit"dialogid="vxi80"><data> <item name="status" value="1"/> <item name="result" value="12345"/> </data><dialogexit status="1"> <collectinfo dtmf="12345" termmode="match"/> </dialogexit> </event> In this example, a prompt is played and then we wait for 3 hours for a two digit sequence: <dialogstartsrc="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>connectionid="7HDY839~HJKSkyHS~HUwkuh7ns"> <basicivr> <prompt> <media src="http://www.example.com/prompt1.wav"/> </prompt> <collect timeout="1080s" maxdigits="2"/> </basicivr> </dialogstart> If no user input is collected within 3 hours, then following would be returned: <eventname="dialogexit"dialogid="vxi81"><data> <item name="status" value="603"/> </data><dialogexit status="1" > <collectinfo termmode="noinput"/> </dialogexit> </event> And finally in this example, one of the input parameters is invalid: <dialogstartsrc="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>connectionid="7HDY839~HJKSkyHS~HUwkuh7ns"> <basicivr> <prompt iterations="two"> <media src="http://www.example.com/prompt1.wav"/> </prompt> <collect cleardigitbuffer="true" bargein="true" timeout="4s" interdigittimeout="2s" termtimeout="0s maxdigits="2"/> </basicivr> </dialogstart> The error is reported in adialogexit <event>: <event name="dialogexit" dialogid="vxi82"> <data> <item name="status" value="601"/> <item name="reason" value="iterationsthe response: <response status="411" dialogid="vxi82" reason="iterations value invalid: two"/></data> </event>7.3.promptandrecordPrompt and record In this example, the user is prompted, then their input is recorded for a maximum of 30 seconds. <dialogstartsrc="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>connectionid="7HDY839~HJKSkyHS~HUwkuh7ns"> <basicivr> <prompt> <media src="http://www.example.com/media/sayname.wav"/> </prompt> <record dtmfterm="false" maxtime="30s" beep="true"/> </basicivr> </dialogstart> If successful, the following is returned in a dialogexit <event>: <eventname="dialogexit"dialogid="vxi83"><data> <item name="status" value="1"/> <item name="result" value="http://www.example.com/recording1.wav"/> </data><dialogexit status="1"> <recordinfo recording="http://www.example.com/recording1.wav" termmode="dtmf"/> </dialogexit> </event> 8.Formal Syntax [Editors Note:Type Definitions This section defines types referenced in attribute definitions. 8.1. Boolean The value space of boolean is the set {true, false}. 8.2. DTMFChar Alater versionDTMF character. The value space is the set {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, #, *, A, B, C, D}. 8.3. DTMFString A String composed of one or more DTMFChars. 8.4. Non-Negative Integer The value space of non-negative integer is the infinite set {0,1,2,...}. 8.5. Positive Integer The value space of positive integer is the infinite set {1,2,...}. 8.6. String A string in the character encoding associated with the XMLschema will provide more constraintselement. 8.7. Time Designation A time designation consists of a non-negative real number followed by a time unit identifier. The time unit identifiers are: "ms" (milliseconds) and "s" (seconds). Examples include: "3s", "850ms", "0.7s", ".5s" and "+1.5s". 8.8. Percentage A percentage consists of a Positive Integer followed by "%". Examples include: "100%", "500%" and "10%". 8.9. URI Uniform Resource Indicator asexpresseddefined in [RFC3986]. 8.10. mimetype A string formated as a IANA mimetype. 8.11. Language Identifier A language identifier labels information content as being of a particular human language variant. Following thetextual definitions;XML specification forexample, single occurrence of <data>language identification [XML], a legal language identifier is identified by a RFC3066 ([RFC3066]) code where the language code is required and a country code or other subtag identifier is optional. 9. Formal Syntax This package defines two XML schema: 1. msc-ivr-common.xsd: defines the common datatypes, attributes and dialog management elements. It does not use a namespace. 2. msc-ivr-basic.xsd: defines the basic ivr elements and uses schema redefinition to extend dialog management elements. All elements in this schema, including the imported dialog management elements,co-occurence on attributes, etc.] [Editors Note:are in the urn:ietf:params:xml:ns:msc-ivr-basic namespace. The schema are dependent upon the schema (framework.xsd) defined in Section 16.1 of the05 version does not allign with changes made sinceControl Framework [MCCF] Both schema are fully extensible: attributes and elements from other namespaces are permitted, and extensions can be specified using the04 version. These changes will occur in<redefine> mechanism. The schema of extension control packages MUST imported one of these schema and specify how they extend thenextelements. Extensions to the <basicivr> element use msc-ivr-basic.xsd. Extensions to the dialog management elements use msc-ivr-common.xsd. [Editors Note:IVR14 A later version ofthe document.]this document may provide a RelaxNG schema which provides better support for co-occurrence constraints than XML schema. Does anyone want/need such a schema?] 9.1. msc-ivr-common.xsd <?xml version="1.0" encoding="UTF-8"?> <xsd:schematargetNamespace="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:fw="urn:ietf:params:xml:ns:control:framework-attributes" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:annotation><xsd:documentation>Basic<xsd:documentation> IETF MediaCtrl IVR Common 1.0 (20080225) This is the common core schema(20061019)</xsd:documentation>of the IVR packages defined as part of the Basic IVR Control Package. It specifies common datatypes, attributes and dialog control element definitions. </xsd:documentation> </xsd:annotation> <!-- ################################################### SCHEMA IMPORTS ################################################### --> <xsd:import namespace="urn:ietf:params:xml:ns:control:framework-attributes"schemaLocation="framework.xsd"/> <xsd: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>schemaLocation="framework.xsd"> <xsd:annotation> <xsd:documentation> This import brings in the framework attributes for conferenceid and connectionid. </xsd:documentation> </xsd:annotation> </xsd:import> <xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"> <xsd:annotation> <xsd:documentation> This import brings in the XML attributes for xml:base, xml:lang, etc See http://www.w3.org/2001/xml.xsd for latest version </xsd:documentation> </xsd:annotation> </xsd:import> <!-- ##################################################### COMMON ELEMENTS ##################################################### --> <!-- dialogprepare --> <xsd:attributeGroup name="msc.ivr.common.dialogprepare.attlist"> <xsd:attribute name="src"type="URI.datatype" use="required"/>type="xsd:anyURI" /> <xsd:attribute name="type" type="mime.datatype" /> <xsd:attribute name="dialogid"type="dialogid.datatype"/> <xsd:anyAttribute namespace="##other" processContents="strict"/> </xsd:complexType> </xsd:element> <xsd:element name="dialogstart"> <xsd:complexType> <xsd:choicetype="dialogid.datatype" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.common.dialogprepare.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0"maxOccurs="unbounded"> <xsd:element ref="stream"/> <xsd:element ref="data"/> <xsd:element ref="subscribe"/> <xsd:any namespace="##other" processContents="strict"/>maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.common.dialogprepare.content"> <xsd:sequence> <xsd:group ref="msc.ivr.common.dialogprepare.mix" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.common.dialogprepare.type"> <xsd:group ref="msc.ivr.common.dialogprepare.content" /> <xsd:attributeGroup ref="msc.ivr.common.dialogprepare.attlist" /> </xsd:complexType> <xsd:element name="dialogprepare" type="msc.ivr.common.dialogprepare.type" /> <!-- dialogstart --> <xsd:attributeGroup name="msc.ivr.common.dialogstart.attlist"> <xsd:attribute name="src"type="URI.datatype"/>type="xsd:anyURI" /> <xsd:attribute name="type" type="mime.datatype" /> <xsd:attribute name="dialogid"type="dialogid.datatype"/>type="dialogid.datatype" /> <xsd:attribute name="prepareddialogid"type="dialogid.datatype"/>type="dialogid.datatype" /> <xsd:attributeGroupref="fw:framework-attributes"/> <xsd:anyAttribute namespace="##other" processContents="strict"/> </xsd:complexType> </xsd:element>ref="fw:framework-attributes" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.common.dialogstart.mix"> <xsd:choice> <xsd:elementname="dialogterminate"> <xsd:complexType> <xsd:choiceref="stream" minOccurs="0"maxOccurs="unbounded"> <xsd:any namespace="##other" processContents="strict"/>maxOccurs="unbounded" /> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.common.dialogstart.content"> <xsd:sequence> <xsd:group ref="msc.ivr.common.dialogstart.mix" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.common.dialogstart.type"> <xsd:group ref="msc.ivr.common.dialogstart.content" /> <xsd:attributeGroup ref="msc.ivr.common.dialogstart.attlist" /> </xsd:complexType> <xsd:element name="dialogstart" type="msc.ivr.common.dialogstart.type" /> <!-- dialogterminate --> <xsd:attributeGroup name="msc.ivr.common.dialogterminate.attlist"> <xsd:attribute name="dialogid" type="dialogid.datatype"use="required"/>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:choicedefault="false" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.common.dialogterminate.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0"maxOccurs="unbounded"> <xsd:any namespace="##other" processContents="strict"/>maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.common.dialogterminate.content"> <xsd:sequence> <xsd:group ref="msc.ivr.common.dialogterminate.mix" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.common.dialogterminate.type"> <xsd:group ref="msc.ivr.common.dialogterminate.content" /> <xsd:attributeGroup ref="msc.ivr.common.dialogterminate.attlist" /> </xsd:complexType> <xsd:element name="dialogterminate" type="msc.ivr.common.dialogterminate.type" /> <!-- response --> <xsd:attributeGroup name="msc.ivr.common.response.attlist"> <xsd:attribute name="status" type="status.datatype"use="required"/>use="required" /> <xsd:attribute name="reason"type="xsd:string"/>type="xsd:string" /> <xsd:attribute name="dialogid"type="dialogid.datatype"/>type="dialogid.datatype" /> <xsd:attributeGroupref="fw:framework-attributes"/> <xsd:anyAttribute namespace="##other" processContents="strict"/>ref="fw:framework-attributes" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.common.response.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.common.response.content"> <xsd:sequence> <xsd:group ref="msc.ivr.common.response.mix" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.common.response.type"> <xsd:group ref="msc.ivr.common.response.content" /> <xsd:attributeGroup ref="msc.ivr.common.response.attlist" /> </xsd:complexType></xsd:element><xsd:elementname="event"> <xsd:complexType> <xsd:choicename="response" type="msc.ivr.common.response.type" /> <!-- event --> <xsd:attributeGroup name="msc.ivr.common.event.attlist"> <xsd:attribute name="dialogid" type="dialogid.datatype" use="required" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.common.event.mix"> <xsd:choice> <xsd:element ref="dialogexit" /> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.common.event.content"> <xsd:choice> <xsd:group ref="msc.ivr.common.event.mix" minOccurs="0"maxOccurs="unbounded">maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:complexType name="msc.ivr.common.event.type"> <xsd:group ref="msc.ivr.common.event.content" /> <xsd:attributeGroup ref="msc.ivr.common.event.attlist" /> </xsd:complexType> <xsd:elementref="data"/> <xsd:any namespace="##other" processContents="strict"/>name="event" type="msc.ivr.common.event.type" /> <!-- dialogexit--> <xsd:attributeGroup name="msc.ivr.common.dialogexit.attlist"> <xsd:attribute name="status" type="xsd:positiveInteger" use="required" /> <xsd:attribute name="reason" type="xsd:string" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.common.dialogexit.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.common.dialogexit.content"> <xsd:sequence> <xsd:group ref="msc.ivr.common.dialogexit.mix" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.common.dialogexit.type"> <xsd:group ref="msc.ivr.common.dialogexit.content" /> <xsd:attributeGroup ref="msc.ivr.common.dialogexit.attlist" /> </xsd:complexType> <xsd:element name="dialogexit" type="msc.ivr.common.dialogexit.type" /> <!-- stream --> <xsd:attributeGroup name="msc.ivr.common.stream.attlist"> <xsd:attributename="name" type="eventname.datatype" use="required"/>name="media" type="media.datatype" use="required" /> <xsd:attributename="dialogid" type="dialogid.datatype" use="required"/>name="label" type="label.datatype" /> <xsd:attribute name="direction" type="direction.datatype" default="sendrecv" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.common.stream.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.common.stream.content"> <xsd:sequence> <xsd:group ref="msc.ivr.common.stream.mix" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.common.stream.type"> <xsd:group ref="msc.ivr.common.stream.content" /> <xsd:attributeGroup ref="msc.ivr.common.stream.attlist" /> </xsd:complexType> <xsd:element name="stream" type="msc.ivr.common.stream.type" /> <!-- ##################################################### COMMON ATTRIBUTES AND ELEMENTS ##################################################### --> <xsd:attributeGroup name="msc.common.attribs"> <xsd:annotation> <xsd:documentation> group allowing attributes from other namespaces </xsd:documentation> </xsd:annotation> <xsd:anyAttribute namespace="##other"processContents="strict"/> </xsd:complexType> </xsd:element>processContents="lax" /> </xsd:attributeGroup> <xsd:group name="msc.common.content"> <xsd:annotation> <xsd:documentation> group allowing elements from other namespaces </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <!-- #################################################### COMMON DATATYPES #################################################### --> <xsd:simpleTypename="URI.datatype">name="mime.datatype"> <xsd:restrictionbase="xsd:anyURI"/>base="xsd:string" /> </xsd:simpleType> <xsd:simpleType name="dialogid.datatype"> <xsd:restrictionbase="xsd:string"/>base="xsd:string" /> </xsd:simpleType> <xsd:simpleType name="boolean.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumerationvalue="true"/>value="true" /> <xsd:enumerationvalue="false"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="eventname.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:pattern value="[a-zA-Z0-9\.]+"/>value="false" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="status.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:patternvalue="[0-9][0-9][0-9]"/>value="[0-9][0-9][0-9]" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="media.datatype"> <xsd:restrictionbase="xsd:string"/>base="xsd:string" /> </xsd:simpleType> <xsd:simpleType name="label.datatype"> <xsd:restrictionbase="xsd:string"/>base="xsd:string" /> </xsd:simpleType> <xsd:simpleType name="direction.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumerationvalue="sendrecv"/>value="sendrecv" /> <xsd:enumerationvalue="sendonly"/>value="sendonly" /> <xsd:enumerationvalue="recvonly"/>value="recvonly" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="timedesignation.datatype"> <xsd:annotation> <xsd:documentation> Time designation following Time in CSS2 </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:pattern value="(\+)?([0-9]*\.)?[0-9]+(ms|s)" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="dtmfchar.datatype"> <xsd:annotation> <xsd:documentation>DTMF character [0-9#*A-D]</xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:pattern value="[0-9#*A-D]" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="dtmfstring.datatype"> <xsd:annotation> <xsd:documentation>DTMF sequence [0-9#*A-D]</xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:pattern value="([0-9#*A-D])+" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="percentage.datatype"> <xsd:annotation> <xsd:documentation> whole integer followed by '%' </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:pattern value="([0-9])+%" /> </xsd:restriction> </xsd:simpleType> </xsd:schema> 9.2. msc-ivr-basic.xsd <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="urn:ietf:params:xml:ns:msc-ivr-basic" elementFormDefault="qualified" xmlns="urn:ietf:params:xml:ns:msc-ivr-basic" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:annotation> <xsd:documentation> IETF MediaCtrl IVR Basic 1.0 (20080225) This is the schema of the Basic IVR control package. It imports the msc-ivr-common schema (dialogprepare, etc) and specifies basicivr, prompt, collect and record elements. The schema namespace is urn:ietf:params:xml:ns:msc-ivr-basic </xsd:documentation> </xsd:annotation> <!-- ############################################################# SCHEMA IMPORTS ############################################################# --> <xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"> <xsd:annotation> <xsd:documentation> This import brings in the XML attributes for xml:base, xml:lang, etc See http://www.w3.org/2001/xml.xsd for latest version </xsd:documentation> </xsd:annotation> </xsd:import> <xsd:redefine schemaLocation="msc-ivr-common.xsd"> <xsd:annotation> <xsd:documentation> This import brings in the IVR common package and redefines some elements as follows: [1] adds basicivr element to dialogprepare [2] adds basicivr element to dialogstart [3] adds promptinfo, collectinfo and recordinfo as children of dialogexit element </xsd:documentation> </xsd:annotation> <xsd:group name="msc.ivr.common.dialogprepare.mix"> <xsd:choice> <xsd:group ref="msc.ivr.common.dialogprepare.mix" /> <xsd:element ref="basicivr" minOccurs="0" maxOccurs="1" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.common.dialogstart.mix"> <xsd:choice> <xsd:group ref="msc.ivr.common.dialogstart.mix" /> <xsd:element ref="basicivr" minOccurs="0" maxOccurs="1" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.common.dialogexit.mix"> <xsd:choice> <xsd:group ref="msc.ivr.common.dialogexit.mix" /> <xsd:element ref="promptinfo" minOccurs="0" maxOccurs="1" /> <xsd:element ref="collectinfo" minOccurs="0" maxOccurs="1" /> <xsd:element ref="recordinfo" minOccurs="0" maxOccurs="1" /> </xsd:choice> </xsd:group> </xsd:redefine> <!--SHARED############################################################# BASIC IVR ELEMENTS ############################################################# --> <!-- basicivr --> <xsd:attributeGroup name="msc.ivr.basicivr.basicivr.attlist"> <xsd:attribute name="version" type="xsd:string" default="1.0" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.basicivr.basicivr.mix"> <xsd:choice> <xsd:elementname="data"> <xsd:complexType> <xsd:choiceref="prompt" minOccurs="0"maxOccurs="unbounded">maxOccurs="1" /> <xsd:elementref="item"/> <xsd:any namespace="##other" processContents="strict"/>ref="collect" minOccurs="0" maxOccurs="1" /> <xsd:element ref="record" minOccurs="0" maxOccurs="1" /> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice><xsd:anyAttribute namespace="##other" processContents="strict"/></xsd:group> <xsd:group name="msc.ivr.basicivr.basicivr.content"> <xsd:sequence> <xsd:group ref="msc.ivr.basicivr.basicivr.mix" minOccurs="1" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.basicivr.basicivr.type"> <xsd:group ref="msc.ivr.basicivr.basicivr.content" /> <xsd:attributeGroup ref="msc.ivr.basicivr.basicivr.attlist" /> </xsd:complexType></xsd:element><xsd:elementname="item"> <xsd:complexType>name="basicivr" type="msc.ivr.basicivr.basicivr.type" /> <!-- prompt --> <xsd:attributeGroup name="msc.ivr.basicivr.prompt.attlist"> <xsd:attributename="name" type="xsd:string" use="required"/>ref="xml:base" /> <xsd:attribute name="bargein" type="boolean.datatype" default="true" /> <xsd:attribute name="iterations" type="xsd:nonNegativeInteger" default="1" /> <xsd:attribute name="duration" type="timedesignation.datatype" /> <xsd:attribute name="volume" type="percentage.datatype" default="100%" /> <xsd:attribute name="offset" type="timedesignation.datatype" default="0s" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.basicivr.prompt.mix"> <xsd:choice> <xsd:element ref="media" minOccurs="0" maxOccurs="unbounded" /> <xsd:element ref="variable" minOccurs="0" maxOccurs="unbounded" /> <xsd:element ref="dtmf" minOccurs="0" maxOccurs="unbounded" /> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.basicivr.prompt.content"> <xsd:choice> <xsd:group ref="msc.ivr.basicivr.prompt.mix" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:complexType name="msc.ivr.basicivr.prompt.type"> <xsd:group ref="msc.ivr.basicivr.prompt.content" /> <xsd:attributeGroup ref="msc.ivr.basicivr.prompt.attlist" /> </xsd:complexType> <xsd:element name="prompt" type="msc.ivr.basicivr.prompt.type" /> <!-- media --> <xsd:attributeGroup name="msc.ivr.basicivr.media.attlist"> <xsd:attribute name="src" type="xsd:anyURI" use="required" /> <xsd:attribute name="type" type="mime.datatype" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.basicivr.media.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.basicivr.media.content"> <xsd:sequence> <xsd:group ref="msc.ivr.basicivr.media.mix" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.basicivr.media.type"> <xsd:group ref="msc.ivr.basicivr.media.content" /> <xsd:attributeGroup ref="msc.ivr.basicivr.media.attlist" /> </xsd:complexType> <xsd:element name="media" type="msc.ivr.basicivr.media.type" /> <!-- variable --> <xsd:attributeGroup name="msc.ivr.basicivr.variable.attlist"> <xsd:attribute name="value" type="xsd:string"use="required"/> <xsd:anyAttribute namespace="##other" processContents="strict"/>use="required" /> <xsd:attribute name="type" type="xsd:string" use="required" /> <xsd:attribute name="format" type="xsd:string" /> <xsd:attribute ref="xml:lang" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.basicivr.variable.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.basicivr.variable.content"> <xsd:sequence> <xsd:group ref="msc.ivr.basicivr.variable.mix" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.basicivr.variable.type"> <xsd:group ref="msc.ivr.basicivr.variable.content" /> <xsd:attributeGroup ref="msc.ivr.basicivr.variable.attlist" /> </xsd:complexType></xsd:element><xsd:elementname="stream"> <xsd:complexType> <xsd:choicename="variable" type="msc.ivr.basicivr.variable.type" /> <!-- dtmf --> <xsd:attributeGroup name="msc.ivr.basicivr.dtmf.attlist"> <xsd:attribute name="digits" type="dtmfstring.datatype" use="required" /> <xsd:attribute name="level" type="xsd:integer" default="-6" /> <xsd:attribute name="duration" type="timedesignation.datatype" default="100ms" /> <xsd:attribute name="interval" type="timedesignation.datatype" default="100ms" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.basicivr.dtmf.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0"maxOccurs="unbounded"> <xsd:any namespace="##other" processContents="strict"/>maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.basicivr.dtmf.content"> <xsd:sequence> <xsd:group ref="msc.ivr.basicivr.dtmf.mix" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.basicivr.dtmf.type"> <xsd:group ref="msc.ivr.basicivr.dtmf.content" /> <xsd:attributeGroup ref="msc.ivr.basicivr.dtmf.attlist" /> </xsd:complexType> <xsd:element name="dtmf" type="msc.ivr.basicivr.dtmf.type" /> <!-- collect --> <xsd:attributeGroup name="msc.ivr.basicivr.collect.attlist"> <xsd:attributename="media" type="media.datatype" use="required"/>name="cleardigitbuffer" type="boolean.datatype" default="true" /> <xsd:attributename="label" type="label.datatype"/>name="timeout" type="timedesignation.datatype" default="5s" /> <xsd:attributename="direction" type="direction.datatype" default="sendrecv"name="interdigittimeout" type="timedesignation.datatype" default="2s" /> <xsd:attribute name="termtimeout" type="timedesignation.datatype" default="0s" /> <xsd:attribute name="escapekey" type="dtmfchar.datatype" /> <xsd:attribute name="termchar" type="dtmfchar.datatype" default="#" /> <xsd:attribute name="maxdigits" type="xsd:positiveInteger" default="5" /> <xsd:attribute name="skipinterval" type="timedesignation.datatype" default="6s" /> <xsd:attribute name="ffkey" type="dtmfchar.datatype" /> <xsd:attribute name="rwkey" type="dtmfchar.datatype" /> <xsd:attribute name="pauseinterval" type="timedesignation.datatype" default="10s" /> <xsd:attribute name="pausekey" type="dtmfchar.datatype" /> <xsd:attribute name="resumekey" type="dtmfchar.datatype" /> <xsd:attribute name="volumeinterval" type="percentage.datatype" default="10%" /> <xsd:attribute name="volupkey" type="dtmfchar.datatype" /> <xsd:attribute name="voldnkey" type="dtmfchar.datatype" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.basicivr.collect.mix"> <xsd:choice> <xsd:element ref="grammar" minOccurs="0" maxOccurs="1" /> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.basicivr.collect.content"> <xsd:sequence> <xsd:group ref="msc.ivr.basicivr.collect.mix" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.basicivr.collect.type"> <xsd:group ref="msc.ivr.basicivr.collect.content" /> <xsd:attributeGroup ref="msc.ivr.basicivr.collect.attlist" /><xsd:anyAttribute namespace="##other" processContents="strict"/></xsd:complexType></xsd:element><xsd:elementname="subscribe"> <xsd:complexType> <xsd:choicename="collect" type="msc.ivr.basicivr.collect.type" /> <!-- grammar --> <xsd:attributeGroup name="msc.ivr.basicivr.grammar.attlist"> <xsd:attribute name="src" type="xsd:anyURI" /> <xsd:attribute name="type" type="mime.datatype" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.basicivr.grammar.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.basicivr.grammar.content"> <xsd:sequence> <xsd:group ref="msc.ivr.basicivr.grammar.mix" minOccurs="0"maxOccurs="unbounded">maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.basicivr.grammar.type" mixed="true"> <xsd:group ref="msc.ivr.basicivr.grammar.content" /> <xsd:attributeGroup ref="msc.ivr.basicivr.grammar.attlist" /> </xsd:complexType> <xsd:elementref="notify"/>name="grammar" type="msc.ivr.basicivr.grammar.type" /> <!-- record --> <xsd:attributeGroup name="msc.ivr.basicivr.record.attlist"> <xsd:attribute name="timeout" type="timedesignation.datatype" default="5s" /> <xsd:attribute name="type" type="mime.datatype" /> <xsd:attribute name="dest" type="xsd:anyURI" /> <xsd:attribute name="beep" type="boolean.datatype" default="false" /> <xsd:attribute name="vadinitial" type="boolean.datatype" default="true" /> <xsd:attribute name="vadfinal" type="boolean.datatype" default="true" /> <xsd:attribute name="dtmfterm" type="boolean.datatype" default="true" /> <xsd:attribute name="maxtime" type="timedesignation.datatype" default="15s" /> <xsd:attribute name="finalsilence" type="timedesignation.datatype" default="5s" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.basicivr.record.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice><xsd:anyAttribute namespace="##other" processContents="strict"/></xsd:group> <xsd:group name="msc.ivr.basicivr.record.content"> <xsd:sequence> <xsd:group ref="msc.ivr.basicivr.record.mix" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.basicivr.record.type"> <xsd:group ref="msc.ivr.basicivr.record.content" /> <xsd:attributeGroup ref="msc.ivr.basicivr.record.attlist" /> </xsd:complexType></xsd:element><xsd:elementname="notify"> <xsd:complexType> <xsd:choicename="record" type="msc.ivr.basicivr.record.type" /> <!-- promptinfo --> <xsd:attributeGroup name="msc.ivr.basicivr.promptinfo.attlist"> <xsd:attribute name="duration" type="xsd:nonNegativeInteger" /> <xsd:attribute name="iterations" type="xsd:positiveInteger" /> <xsd:attribute name="termmode" type="prompt_termmode.datatype" use="required" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.basicivr.promptinfo.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.basicivr.promptinfo.content"> <xsd:sequence> <xsd:group ref="msc.ivr.basicivr.promptinfo.mix" minOccurs="0"maxOccurs="1">maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.basicivr.promptinfo.type"> <xsd:group ref="msc.ivr.basicivr.promptinfo.content" /> <xsd:attributeGroup ref="msc.ivr.basicivr.promptinfo.attlist" /> </xsd:complexType> <xsd:elementref="data"/>name="promptinfo" type="msc.ivr.basicivr.promptinfo.type" /> <!-- collectinfo --> <xsd:attributeGroup name="msc.ivr.basicivr.collectinfo.attlist"> <xsd:attribute name="dtmf" type="dtmfstring.datatype" /> <xsd:attribute name="termmode" type="collect_termmode.datatype" use="required" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.basicivr.collectinfo.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.basicivr.collectinfo.content"> <xsd:sequence> <xsd:group ref="msc.ivr.basicivr.collectinfo.mix" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.basicivr.collectinfo.type"> <xsd:group ref="msc.ivr.basicivr.collectinfo.content" /> <xsd:attributeGroup ref="msc.ivr.basicivr.collectinfo.attlist" /> </xsd:complexType> <xsd:element name="collectinfo" type="msc.ivr.basicivr.collectinfo.type" /> <!-- recordinfo --> <xsd:attributeGroup name="msc.ivr.basicivr.recordinfo.attlist"> <xsd:attributename="name" type="xsd:string" use="required"/> <xsd:anyAttribute namespace="##other" processContents="strict"/>name="recording" type="xsd:anyURI" /> <xsd:attribute name="type" type="mime.datatype" /> <xsd:attribute name="duration" type="xsd:nonNegativeInteger" /> <xsd:attribute name="size" type="xsd:nonNegativeInteger" /> <xsd:attribute name="termmode" type="record_termmode.datatype" use="required" /> <xsd:attributeGroup ref="msc.common.attribs" /> </xsd:attributeGroup> <xsd:group name="msc.ivr.basicivr.recordinfo.mix"> <xsd:choice> <xsd:group ref="msc.common.content" minOccurs="0" maxOccurs="unbounded" /> </xsd:choice> </xsd:group> <xsd:group name="msc.ivr.basicivr.recordinfo.content"> <xsd:sequence> <xsd:group ref="msc.ivr.basicivr.recordinfo.mix" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="msc.ivr.basicivr.recordinfo.type"> <xsd:group ref="msc.ivr.basicivr.recordinfo.content" /> <xsd:attributeGroup ref="msc.ivr.basicivr.recordinfo.attlist" /> </xsd:complexType></xsd:element><xsd:element name="recordinfo" type="msc.ivr.basicivr.recordinfo.type" /> <!-- ############################################################# BASIC IVR DATATYPES ############################################################# --> <xsd:simpleType name="prompt_termmode.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="completed" /> <xsd:enumeration value="maxduration" /> <xsd:enumeration value="bargein" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="collect_termmode.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="match" /> <xsd:enumeration value="noinput" /> <xsd:enumeration value="nomatch" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="record_termmode.datatype"> <xsd:restriction base="xsd:NMTOKEN"> <xsd:enumeration value="noinput" /> <xsd:enumeration value="dtmf" /> <xsd:enumeration value="maxtime" /> <xsd:enumeration value="finalsilence" /> </xsd:restriction> </xsd:simpleType> </xsd:schema>9. Security Considerations10. Security Considerationsto be included in later versions ofAs thisdocument. 10.control package uses XML markup, implementation MUST address the security considerations of [RFC3023]. 11. IANA Considerations Thisdocument registersspecification instructs IANA to register a newSIPMedia Control Channel Framework Package, a new XML namespace and a newURI scheme "basicivr:". 10.1.mime type. 11.1. Control Package Registration Control Package name: msc-ivr-basic/1.010.2.11.2. URN Sub-Namespace Registration XML namespace: urn:ietf:params:xml:ns:msc-ivr-basic11.11.3. Mime Type Registration MIME type: application/msc-ivr-basic+xml 12. Change Summary Note to RFC Editor: Please remove this whole section. The following are the major changes between the -06 of the draft and the -05 version. o Event notifications are sent in CONTROL messages with the MS acting as Control Framework Client. Compared with the previous approach, this means that a <dialogstart> transaction is now complete when the MS sends a <response>. A new transaction is initiated by the MS each time the MS sends a notification <event> to the AS. o Changed conf-id to conferenceid and connection-id to connectionid. o Clarification of the state model for dialogs o <dialogprepare>: modified definition of src attribute to allow reference to external dialog documents; added (MIME) type attribute; removed <data> child element. o <dialogstart>: modified definition of src attribute to allow reference to external dialog documents; added (MIME) type attribute; removed <data> child element; o <dialogterminate>: modified so that a dialogexit event is always sent for active dialogs (i.e. the dialogexit event is a terminating notification) o <event> notification simplified and make more extensible. Manual notifications (via <subscribe> element) are removed from the basic package. A <dialogexit> event is defined as <event> child and it can be extended with additional child elements o <data> element is removed. o <subscribe> element removed. o Replaced dialog templates with a general <basicivr> element. It has child elements for playing media resource (<prompt>), collecting DTMF (<collect>) and recording (<record>). The functionality is largely unchanged. o <dialogprepare> and <dialogstart> are extended with <basicivr> child element. o <event> is extended with a <dialogexit> element which contains status and reported information (replacement for output parameters in template dialogs) o Prompts: now structured as a <prompt> element with <media>, <variable> and <dtmf> children. The <prompt> element has xml:base attribute, bargein, iterations, duration, volume and offset attributes. The speed attribute is removed. A <media> element has src and type attributes. The maxage and maxstale attributes are removed. o DTMF input: parameters now specified as attributes of a <collect> element. Custom grammar specified with a <grammar> element as child of <collect> element. Added 'escapekey' to allow the dialog to be retried. Added 'pauseinterval', 'pausekey' and 'resumekey' to allow the prompts to paused/resumed. Added 'volumeinterval', 'volupkey' and voldnkey' to add prompt volume to be increased/ decreased. Moved 'bargein' attribute to prompt. o Recording: parameters now specified as attributes of <record> element. Added 'dest' and 'beep' attributes. The following are the major changes between the -05 of the draft and the -04 version. o Mainly anallignment/evaluationalignment/evaluation exercise with requirements produced by MEDIACTRL IVR design team. o playannouncement parameters from Table 7 of '04' version are now reflected in text - schema to be updated. o Added VCR commands based on MSCML. The following are the major changes between the -04 of the draft and the -03 version. o None. The following are the major changes between the -03 of the draft and the -02 version. o added "basicivr:" protocol to template dialog types which must be supported as values of the "src" attribute in <dialogprepare> and <dialogstart>. Note alternative: "/basicivr/playannouncement" offered in [RFC4240]. o added "basicivr:" URI schema to IANA considerations o Added mimetype, vadinitial and vadfinal parameters to 'promptandrecord' dialog type o updated references The following are the major changes between the -02 of the draft and the -01 version. o added version 1.0 to package name o separate section for element definitions o dialogterminate treated as request rather than notification o simplified responses: single element <response> o removed response elements: <dialogprepared>, <dialogstarted>, <errordialognotprepared>, <errordialognotstarted> o simplified event notifications to single <event> element carried in a REPORT o <dialogexit> element replaced with <event name="dialogexit"> o removed <dialoguser> element o added <stream> element as child of <dialogstart> o removed 'type' attribute from <dialogprepare> and <dialogstart> o added dialogid attribute to <dialogprepare> and <dialogstart> o removed template "Sample Implementation" section o renamed <namelist> to <data> o re-organized so that template details after general package framework and element description. The following are the primary changes between the -01 of the draft and the -00 version. o Removed requirement for VoiceXML dialog support o Added requirement for template dialog support12.13. Contributors Asher Shiratzky from Radvision provided valuable support and contributions to the early versions of this document. The authors would like to thank the IVR design team consisting of Roni Even, Lorenzo Miniero, Adnan Saleem and Diego Besprosvan who provided valuable feedback, input and text to this document.13.14. Acknowledgments The authors would like to thank Adnan Saleem of Radisys, Gene Shtirmer ofIntel andIntel, Dave Burke of Google and Dan York of Voxeo for useful reviews of this work.14.15. References14.1.15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.14.2.15.2. Informative References [CCXML10] Auburn, R J., "Voice Browser Call Control: CCXML Version 1.0", W3C Working Draft (work in progress), January 2007. [H.248.1] "Gateway control protocol: Version 3", ITU-T Recommendation H.248.1. [H.248.9] "Gateway control protocol: Advanced media server packages", ITU-T Recommendation H.248.9.[MSCP] McGlashan, S., Auburn, R., Burke, D., Candell, E.,[I-D.ietf-mediactrl-requirements] Dolly, M. and R.Surapaneni,Even, "Media Server Control Protocol(MSCP)", draft-mcglashan-mscp-03Requirements", draft-ietf-mediactrl-requirements-03 (work in progress),MarchDecember 2007. [MCCF] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "Media Control Channel Framework", draft-ietf-mediactrl-sip-control-framework-01 (work in progress), February 2008. [MSML] Saleem, A., Xin, Y., and G. Sharratt, "Media Session Markup Language (MSML)",draft-saleem-msml-05draft-saleem-msml-06 (work in progress),August 2007. [RFC2396] Berners-Lee, T., Fielding, R.,February 2008. [RFC2833] Schulzrinne, H. andL. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P.,S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones andT. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",Telephony Signals", RFC2616, June 1999.2833, May 2000. [RFC2897] Cromwell, D., "Proposal for an MGCP Advanced Audio Package", RFC 2897, August 2000. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", RFC 3066, January 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, 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, June 2002. [RFC3264] Rosenberg, J.[RFC3986] Berners-Lee, T., Fielding, R., andH. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)",L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC3264, June 2002.3986, January 2005. [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005. [RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs Parameter for "Bucket" Media Types", RFC 4281, November 2005. [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006. [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006. [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 5022, September 2007.[SIPCF] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "A Control Framework for the Session Initiation Protocol (SIP)", draft-ietf-mediactrl-sip-control-framework-00 (work in progress), August 2007.[SRGS] Hunt, A. and S. McGlashan, "Speech Recognition Grammar Specification Version 1.0", W3C Recommendation, March 2004. [VXML20] McGlashan, S., Burnett, D., Carter, J., Danielsen, P., Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K., and S. Tryphonas, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C Recommendation, March 2004. [VXML21] Oshry, M., Auburn, RJ., Baggia, P., Bodell, M., Burke, D., Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee, A., Porter, B., and K. Rehor, "Voice Extensible Markup Language (VoiceXML) Version 2.1", W3C Recommendation, June 2007. [VXMLCP] Boulton, C., Melanchuk, T., and S. McGlashan, "A VoiceXML Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework", draft-boulton-ivr-vxml-control-package-04 (work in progress), February 2008. [XML] Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C Recommendation, February 2004. Authors' Addresses Chris Boulton Avaya Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA Email: cboulton@avaya.com Tim MelanchukTJM ConsultingRain Willow Communications Email: tim.melanchuk@gmail.com Scott McGlashan Hewlett-Packard Gustav III:s boulevard 36 SE-16985 Stockholm, Sweden Email: scott.mcglashan@hp.com Full Copyright Statement Copyright (C) The IETF Trust(2007).(2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).