idnits 2.17.1 draft-boulton-ivr-vxml-control-package-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1100. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1111. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1118. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1124. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2006) is 6366 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-9' is mentioned on line 885, but not defined == Unused Reference: 'RFC3262' is defined on line 1028, but no explicit reference was found in the text == Unused Reference: 'RFC3263' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 1036, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-boulton-ivr-control-package-02 == Outdated reference: A later version (-03) exists of draft-mcglashan-mscp-02 == Outdated reference: A later version (-09) exists of draft-saleem-msml-01 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-05) exists of draft-boulton-sip-control-framework-04 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Boulton 3 Internet-Draft Ubiquity Software Corporation 4 Intended status: Standards Track T. Melanchuk 5 Expires: April 26, 2007 BlankSpace 6 S. McGlashan 7 Hewlett-Packard 8 A. Shiratzky 9 Radvision 10 October 23, 2006 12 A VoiceXML Interactive Voice Response (IVR) Control Package for the 13 Session Initiation Protocol (SIP) 14 draft-boulton-ivr-vxml-control-package-01 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 26, 2007. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 45 Abstract 47 This document defines a Session Initiation (SIP) Control Package for 48 Interactive Voice Response (IVR) interaction using VoiceXML. This 49 Control Package provides IVR functionality using the SIP Control 50 Framework and extends the Basic IVR control package with support for 51 VoiceXML dialogs. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 57 3. Control Package Definition . . . . . . . . . . . . . . . . . . 5 58 3.1. Control Package Name . . . . . . . . . . . . . . . . . . . 5 59 3.2. Framework Message Usage . . . . . . . . . . . . . . . . . 5 60 3.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 5 61 3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 6 62 3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 6 63 4. Element Definitions . . . . . . . . . . . . . . . . . . . . . 7 64 4.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1.1. . . . . . . . . . . . . . . . . . . . 7 66 4.1.2. . . . . . . . . . . . . . . . . . . . . 9 67 4.1.3. . . . . . . . . . . . . . . . . . . 12 68 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.2.1. . . . . . . . . . . . . . . . . . . . . . . 13 70 4.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 15 71 4.3.1. . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.4. . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 4.5. . . . . . . . . . . . . . . . . . . . . . . . 16 74 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 77 7.1. Control Package Registration . . . . . . . . . . . . . . . 25 78 7.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 25 79 8. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 26 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 85 Intellectual Property and Copyright Statements . . . . . . . . . . 31 87 1. Introduction 89 The SIP Control Framework [SIPCF] provides a generic approach for 90 establishment and reporting capabilities of remotely initiated 91 commands. The Framework utilizes many functions provided by the 92 Session Initiation Protocol [RFC3261] (SIP) for the rendezvous and 93 establishment of a reliable channel for control interactions. The 94 Control Framework also introduces the concept of a Control Package. 95 A Control Package is an explicit usage of the Control Framework for a 96 particular interaction set. 98 This specification defines a package for IVR functions using VoiceXML 99 dialogs [VXML20]. As a recognized international standard for IVR 100 dialogs, VoiceXML is used extensively within media server control 101 languages (cf. [MSCP], [CCXML10], [MSML], [MSCML], [RFC4240]). To 102 ensure interoperability, if a media server supports this package, 103 then it MUST support VoiceXML 2.0 dialog scripts. It MAY support 104 later versions of VoiceXML or other dialog script formats. 106 The VoiceXML package extends the basic IVR control package 107 ([BASICIVRCP]). The extensions only affect the and 108 elements: in particular, 110 1. dialog scripts may also be specified inline using a child 111 element 113 2. a type attribute is introduced with the default value 114 "application/voicexml+xml" 116 3. HTTP fetching and caching of dialog scripts can be configured 117 using attributes of a child element 119 Otherwise, this package follows precisely the syntax and semantics of 120 the basic IVR control package. 122 Other control packages may be defined which extend the capabilities 123 of the control package defined in this document. Such control 124 package must respect the syntax and semantics of this control 125 package. 127 2. Conventions and Terminology 129 In this document, BCP 14/RFC 2119 [RFC2119] defines the key words 130 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 131 "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL". In addition, BCP 15 indicates requirement levels for 133 compliant implementations. 135 The following additional terms are defined for use in this document: 137 Dialog: A dialog performs media interaction with a user. A dialog 138 is identified by a URI and has an associated mimetype. Dialogs 139 typically feature basic capabilities such as playing audio 140 prompts, collecting DTMF input and recording audio input from the 141 user. More advanced dialogs may also feature synthesized speech, 142 recording and playback of video, recognition of spoken input, and 143 mixed initiative conversations. 145 Application server: A SIP [RFC3261] application server (AS) hosts 146 and executes services such as interactive media and conferencing 147 in an operator's network. An AS influences and impacts the SIP 148 session, in particular by terminating SIP sessions on a media 149 server, which is under its control. 151 Media Server: A media server (MS) processes media streams on behalf 152 of an AS by offering functionality such as interactive media, 153 conferencing, and transcoding to the end user. Interactive media 154 functionality is realized by way of dialogs, which are identified 155 by a URI and initiated by the application server. 157 3. Control Package Definition 159 This section fulfills the mandatory requirement for information that 160 MUST be specified during the definition of a Control Framework 161 Package, as detailed in Section 9 of [SIPCF]. 163 3.1. Control Package Name 165 The Control Framework requires a Control Package definition to 166 specify and register a unique name and version. 168 The name and version of this Control Package is "msc-ivr-vxml/1.0" 169 (Media Server Control - Interactive Voice Response - VoiceXML - 170 version 1.0 ). 172 3.2. Framework Message Usage 174 IVR functionality includes capabilities such as playing prompts, 175 collecting DTMF and recording user input. These functions are 176 expressed in VoiceXML dialogs. 178 This package defines XML elements in Section 4 and provides an XML 179 Schema in Section 5. 181 The XML elements in this package are split into requests, responses 182 and event notifications. Requests are carried in CONTROL message 183 bodies; , and elements 184 are defined as package requests. Responses are carried either in 185 REPORT message or Control Framework 200 response bodies; the 186 element is defined as a package response. Event 187 notifications are also carried in REPORT message bodies; the 188 element is defined for package event notifications. 190 Note that package responses are different from framework response 191 codes. Framework error response codes (see Section 8 of [SIPCF]) are 192 used when the request or event notification is invalid; for example, 193 a request is invalid XML (400), or not understood (500). Package 194 responses are carried in 200 response or REPORT message bodies. This 195 package's response codes are defined in Section 4.2.1. 197 The schema uses "connection-id" and "conf-id" attributes which are 198 imported from schema defined in core Control Framework [SIPCF]. 200 3.3. Common XML Support 202 The Control Framework requires a Control Package definition to 203 specify if the attributes for media dialog or conference references 204 are required. 206 This package requires that the XML Schema in Section 16.1 of [SIPCF] 207 MUST be supported for media dialogs and conferences. 209 3.4. CONTROL Message Body 211 A valid CONTROL body message MUST conform to the schema defined in 212 Section 5 and described in Section 4. XML messages appearing in 213 CONTROL messages MUST contain a , or 214 request element (Section 4.1). 216 3.5. REPORT Message Body 218 A valid REPORT body MUST conform to the schema defined in Section 5 219 and described in Section 4. XML messages appearing in REPORT 220 messages MUST contain a (Section 4.2), or a (notification) 221 element (Section 4.3). 223 4. Element Definitions 225 This section defines the XML messages for this control package. 227 [Editors Note: since XML Schema may not be able to express all 228 constraints expressed in these definitions, in cases where there is a 229 difference in constraints, the definitions in the section take 230 priority.] 232 4.1. Requests 234 The following request elements are defined: 236 : prepare an IVR dialog for later execution 238 : start an IVR dialog on a connection or conference 240 : terminate an active IVR dialog 242 4.1.1. 244 The request is sent from the AS to the MS to request 245 preparation of an IVR dialog. A prepared dialog is executed when the 246 AS sends a request referencing the prepared dialog (see 247 Section 4.1.2). 249 A element has the following attributes: 251 src: string identifying the URI of the dialog document to prepare. 252 The attribute is mandatory. The MS MUST support VoiceXML 2.0 253 dialogs and MAY support later versions of VoiceXML or other dialog 254 types. 256 type: string identifying the MIME type of the document. The default 257 value is "application/voicexml+xml". The attribute is optional. 259 dialogid: string indicating a unique name for the dialog. If this 260 attribute is not specified, the MS creates a unique name for the 261 dialog. The value is used in subsequent references to the dialog 262 (e.g. as dialogid in a ). It is an error if a dialog 263 with the same name already exists on the MS. The attribute is 264 optional. 266 The element has the following child elements: 268 : an XML data structure (see Section 4.4) to pass parameters 269 into the dialog. It is an error if a specified parameter is not 270 supported by the implementation. The element is optional. 272 : an XML data structure (see Section 4.5) indicating 273 notification events to which the AS subscribes. It is an error if 274 a specified notification event is not supported by the 275 implementation. The element is optional. 277 : contains the dialog script itself; e.g. a VoiceXML document. 278 The MS MUST support VoiceXML 2.0 dialogs and MAY support later 279 versions of VoiceXML or other dialog types. The element is 280 optional. 282 : contains attributes to configure HTTP 1.1 [RFC2616] 283 fetching and caching. 285 maxage: string defining a time interval according to the max-age 286 parameter in HTTP. The attribute is optional. 288 maxstale: string defining a time interval according to the max- 289 stale parameter in HTTP. The attribute is optional. 291 enctype: string identifying the encoding type of the submitted 292 document. The default value is "application/ 293 x-www-form-url-encoded". The attribute is optional. 295 method: string indicating the HTTP method to use. Permitted 296 values are "post" or "get". The default value is "get". The 297 attribute is optional. 299 The element is optional. 301 Exactly one of the src attribute or the element MUST be 302 specified; otherwise, it is an error. 304 For example, a request to prepare a dialog where the dialog script is 305 indicated using the src attribute: 307 308 309 310 311 313 Where the data parameter "audio" would be available in the VoiceXML 314 script as "connection.ccxml.values.audio" so different prompts can be 315 played using the same dialog script. 317 In the following example, the VoiceXML dialog script is specified 318 inline: 320 321 322 323
324 325 328
329
330
331
333 When an MS has successfully received a request, it 334 MUST reply with a element (Section 4.2). 336 4.1.2. 338 The element is sent by the AS to request execution of a 339 dialog. The dialog may be defined in the dialogstart request itself, 340 or reference a previously prepared dialog. 342 The element has the following attributes: 344 src: string identifying the URI of the dialog document to start. 345 The attribute is optional. The MS MUST support VoiceXML 2.0 346 dialogs and MAY support later versions of VoiceXML or other dialog 347 types. 349 type: string identifying the MIME type of the document. The default 350 value is "application/voicexml+xml". The attribute is optional. 352 dialogid: string indicating a unique name for the dialog. If this 353 attribute is not specified, the MS creates a unique name for the 354 dialog. The value is used in subsequent references to the dialog 355 (e.g. as dialogid in a ). It is an error if a dialog 356 with the same name already exists on the MS. The attribute is 357 optional. 359 prepareddialogid: string identifying a dialog previously prepared 360 using a dialogprepare request. The attribute is optional. 362 connection-id: string identifying the SIP dialog connection on which 363 this dialog is to be started (see Section 16.1 of [SIPCF]). The 364 attribute is optional. 366 conf-id: string identifying the conference on which this dialog is 367 to be started (see Section 16.1 of [SIPCF]). The attribute is 368 optional. 370 The element has the following child elements defined: 372 : contains the following attributes: 374 media: a string indicating the type of media associated with the 375 stream. It is strongly recommended that the following values 376 are used for common types of media: "audio" for audio media, 377 and "video" for video media. The attribute is mandatory. 379 label: a string indicating the SDP label associated with a media 380 stream ([RFC4574]). The attribute is optional. 382 direction: a string indicating the direction of the media flow 383 between a dialog and its end point conference or connection. 384 Defined values are: "sendrecv" (media can be sent and 385 received), "sendonly" (media can only be sent), and "recvonly" 386 (media can only be received). The default value is "sendrecv". 387 The attribute is optional. 389 One or more elements may be specified so that individual 390 media streams can be controlled independently; for example, audio 391 only for transmission, but video only for reception. The 392 element is optional. If no elements are specified, then 393 the default is the media configuration of the connection or 394 conference. It is an error if a element is in conflict 395 with (a) another element, (b) with dialog, connection or 396 conference media capabilities, or (c) with a SDP label value as 397 part of the connection-id (see Section 16.1 of [SIPCF]). 399 : an XML data structure (see Section 4.4) to pass parameters 400 into the dialog. It is an error if a specified parameter is not 401 supported by the implementation. The element is optional. 403 : an XML data structure (see Section 4.5) indicating 404 notification events to which the AS subscribes. It is an error if 405 a specified notification event is not supported by the 406 implementation.The element is optional. 408 : contains the dialog script itself; e.g. a VoiceXML document. 409 The MS MUST support VoiceXML 2.0 dialogs and MAY support later 410 versions of VoiceXML or other dialog types. The element is 411 optional. 413 : contains attributes to configure HTTP 1.1 [RFC2616] 414 fetching and caching. 416 maxage: string defining a time interval according to the max-age 417 parameter in HTTP. The attribute is optional. 419 maxstale: string defining a time interval according to the max- 420 stale parameter in HTTP. The attribute is optional. 422 enctype: string identifying the encoding type of the submitted 423 document. The default value is "application/ 424 x-www-form-url-encoded". The attribute is optional. 426 method: string indicating the HTTP method to use. Permitted 427 values are "post" or "get". The default value is "get". The 428 attribute is optional. 430 The element is optional. 432 [Editors Note: the element assumes that the use of the SDP 433 label by itself is insufficent for media stream control. In 434 particular, the SDP label does not address directionality, nor does 435 it address conferences. Further investigation of the is is 436 required.] 438 If the prepareddialogid is specified, it is an error to specify the 439 src attribute, element or the type attribute. 441 If the prepareddialogid is not specified, exactly one of the src 442 attribute or the element MUST be specified; otherwise, it is an 443 error. 445 Exactly one of the connection-id or conf-id attributes MUST be 446 specified. It is an error to specify both connection-id and conf-id. 448 If the prepareddialogid is specified and the 449 contained a element, it is an error to specify it in 450 . Likewise, If the prepareddialogid is specified and 451 the contained a element, it is an error 452 to specify it in . 454 For example, a request to start a dialog on a conference where the 455 dialog script is indicated using the src attribute: 457 459 460 461 462 464 Where the data parameter "media" would be available in the VoiceXML 465 script as "connection.ccxml.values.media" so different prompts can be 466 played using the same dialog script. 468 In the following example, the VoiceXML dialog script is specified 469 inline. 471 472 473 474
475 476 479
480
481
482
484 In this example, a previously prepared dialog with the dialogid 485 "vxi1" is started. 487 489 When an MS has successfully received a request, it MUST 490 reply with a element (Section 4.2). 492 4.1.3. 494 A dialog that has been successfully prepared or started can be 495 terminated by a request element from the AS. 497 The element has the following attributes: 499 dialogid: string identifying an existing dialog. The attribute is 500 mandatory. 502 immediate: string with the values "true" or "false" indicating 503 whether the dialog is to be terminated immediately or not. If a 504 dialog is terminated immediately, no further dialog event 505 notifications are sent (including a dialogexit ). The 506 default is "false". The attribute is optional. 508 For example, assuming a dialog with the dialogid "vxi1" has been 509 started, it can be terminated immediately with the following request: 511 513 When an MS has successfully received a request, it 514 MUST reply with a element (Section 4.2). 516 4.2. Responses 518 Responses are specified in a element. 520 4.2.1. 522 Reponses to requests are indicated by a element. 524 The element has following attributes: 526 status: numeric code indicating the response status. The attribute 527 is mandatory. 529 reason: string specifying a reason for the response status. The 530 attribute is optional. 532 dialogid: string identifying the dialog. The attribute is optional. 534 connection-id: string identifying the SIP dialog connection 535 associated with the dialog (see Section 16.1 of [SIPCF]). The 536 attribute is optional. 538 conf-id: string identifying the conference associated with the 539 dialog (see Section 16.1 of [SIPCF]). The attribute is optional. 541 The following status codes are defined: 543 +-----------+-------------------------------------------------------+ 544 | code | description | 545 +-----------+-------------------------------------------------------+ 546 | 200 | OK | 547 | | | 548 | 401 | dialogid already exists | 549 | | | 550 | 402 | dialogid does not exist | 551 | | | 552 | 403 | connection-id does not exist | 553 | | | 554 | 404 | conf-id does not exist | 555 | | | 556 | 405 | Unknown or unsupported element | 557 | | | 558 | 406 | Element required | 559 | | | 560 | 407 | Unknown or unsupported attribute | 561 | | | 562 | 408 | Attribute required | 563 | | | 564 | 409 | Invalid VoiceXML URI or content | 565 | | | 566 | 410 | data parameter not supported | 567 | | | 568 | 411 | event subscription not supported | 569 | | | 570 | 412 | stream parameter invalid | 571 | | | 572 | 499 | other error | 573 +-----------+-------------------------------------------------------+ 575 Table 1: status codes 577 [Editors Note: more status codes may need to be defined.] 579 For example, a response when a dialog was prepared successfully: 581 583 The response if dialog preparation failed due to an invalid VoiceXML 584 script: 586 589 For example, a response when the dialog was started successfully. 591 594 4.3. Notifications 596 Event notifications are specified in an element. 598 4.3.1. 600 Dialog event notifications are either manual or automatic. 602 Manual event notifications are defined when an AS subscribes to 603 notifications for dialog events using the element of 604 or . 606 Automatic event notifications are defined as part of a Control 607 Package. The AS SHOULD NOT subscribe to these event notifications. 608 The MS MUST support these event notifications. This package defines 609 one automatic notification event: "dialogexit" which indicates that 610 an active dialog has terminated. Note that this notification is not 611 sent if the dialog has been terminated by the AS using a 612 request where "immediate=true". 614 When a dialog generates a notification event, the MS sends the event 615 to the AS using an element. 617 The element has the following attributes: 619 name: string indicating the name of dialog event. The string is 620 restricted to a sequence of alphanumeric or "." characters. The 621 attribute is mandatory. 623 dialogid: string identifying the dialog. The attribute is 624 mandatory. 626 The element has the following child element: 628 : an XML data structure (see Section 4.4) to pass information 629 additional information about the dialog event. The element is 630 optional. 632 For example, when a dialog exits the MS may send a dialogexit 633 with data collected during the VoiceXML dialog execution: 635 636 637 638 640 642 4.4. 644 The element is a general container for parameterized data. 646 The element has no attributes, but has the following child 647 elements defined: 649 : contains the following attributes: 651 name: a string indicating the name of the parameter. The 652 attribute is mandatory. 654 value: a string indicating the value of the parameter. Multiple 655 values of a parameters can be specified using space separation. 656 The attribute is mandatory. 658 Multiple elements may be specified. 660 For example, a specifying parameters with simple values: 662 663 664 665 667 [Editors Note: we may also want to investigate the use of s 668 nested within a top-level to specify complex values. ] 670 4.5. 672 The element is a container for specifying dialog 673 notification events to which an AS subscribes. Notifications of 674 dialog events are delivered using the element (see 675 Section 4.3.1). 677 The element has no attributes, but has the following 678 child elements defined: 680 : contains the following attributes: 682 name: a string indicating the name of the event to be notified 683 of. The attribute is mandatory. 685 The element may have a child element. 687 Multiple elements may be specified. 689 For example, the AS wishes to subscribe to DTMF and bargein 690 notification events associated with a dialog: 692 694 695 696 697 698 700 If the MS supports these notification events, then it would use the 701 element to send notifications during the dialog to the AS 702 when the events occured. 704 [Editors Note: It may be possible to define a general event 705 subscription mechanism as part of the SIP Control Framework.] 707 [Editors Note: This Control Package does not specify dialog 708 notification events apart from "dialogexit". Later versions may 709 define events such as: "dtmf" (a DTMF key is pressed), "mediastart" 710 (media playback started), "bargein" (user has barged in on a prompt), 711 and "rtpcontrol" (control data, e.g. VFU, PoC, etc, is received over 712 the RTP control channel.] 714 5. Formal Syntax 716 [Editors note: A later version of the XML schema may be reference the 717 basic IVR schema and specify the package extensions in terms of 718 schema extensions. ] 720 [Editors note: A later version of the XML schema will provide more 721 constraints as expressed in the textual definitions; for example, 722 single occurrence of elements, co-occurence on attributes, 723 etc.] 725 726 732 733 734 VoiceXML IVR 1.0 schema (20061019) 735 736 738 742 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 778 780 781 782 784 785 786 787 788 789 790 791 793 794 795 796 797 798 799 800 802 804 805 807 809 810 811 812 813 814 816 818 819 820 821 822 823 825 827 828 829 831 832 833 834 835 836 838 839 840 841 842 843 845 846 847 848 849 851 852 854 856 857 858 860 862 863 864 866 867 868 870 871 872 873 874 875 877 878 879 880 881 883 884 885 886 887 889 890 891 893 894 895 896 897 898 899 900 901 902 904 906 907 908 909 910 911 912 913 914 916 917 918 919 920 921 922 924 925 926 927 928 929 931 932 934 935 936 938 939 940 941 942 943 944 945 947 948 949 950 951 952 953 954 955 957 959 6. Security Considerations 961 Security Considerations to be included in later versions of this 962 document. 964 7. IANA Considerations 966 This document registers a new SIP Control Framework Package and a new 967 XML namespace. 969 7.1. Control Package Registration 971 Control Package name: msc-ivr-vxml/1.0 973 7.2. URN Sub-Namespace Registration 975 XML namespace: urn:ietf:params:xml:ns:msc-ivr-vxml 977 8. Change Summary 979 The following are the primary changes between the -01 of the draft 980 and the -00 version. 982 o Changes in Basic IVR package version 02 applied. 984 9. Acknowledgments 986 TODO 988 10. References 990 10.1. Normative References 992 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 993 Requirement Levels", BCP 14, RFC 2119, March 1997. 995 10.2. Informative References 997 [BASICIVRCP] 998 Boulton, C., Melanchuk, T., McGlashan, S., and A. 999 Shiratzky, "A Basic Interactive Voice Response (IVR) 1000 Control Package for the Session Initiation Protocol 1001 (SIP)", draft-boulton-ivr-control-package-02 (work in 1002 progress), October 2006. 1004 [CCXML10] Auburn, R J., "Voice Browser Call Control: CCXML Version 1005 1.0", W3C Working Draft (work in progress), June 2005. 1007 [MSCML] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server 1008 Control Markup Language (MSCML) and Protocol", 1009 draft-vandyke-mscml-09 (work in progress), June 2006. 1011 [MSCP] McGlashan, S., Auburn, R., Burke, D., Candell, E., and R. 1012 Surapaneni, "Media Server Control Protocol (MSCP)", 1013 draft-mcglashan-mscp-02 (work in progress), July 2006. 1015 [MSML] Saleem, A. and G. Sharratt, "Media Session Markup Language 1016 (MSML)", draft-saleem-msml-01 (work in progress), 1017 June 2006. 1019 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1020 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1021 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1023 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1024 A., Peterson, J., Sparks, R., Handley, M., and E. 1025 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1026 June 2002. 1028 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1029 Provisional Responses in Session Initiation Protocol 1030 (SIP)", RFC 3262, June 2002. 1032 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1033 Protocol (SIP): Locating SIP Servers", RFC 3263, 1034 June 2002. 1036 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1037 with Session Description Protocol (SDP)", RFC 3264, 1038 June 2002. 1040 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1041 Media Services with SIP", RFC 4240, December 2005. 1043 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 1044 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 1046 [SIPCF] Boulton, C., Melanchuk, T., McGlashan, S., and A. 1047 Shiratzky, "A Control Framework for the Session Initiation 1048 Protocol (SIP)", draft-boulton-sip-control-framework-04 1049 (work in progress), October 2006. 1051 [VXML20] McGlashan, S., Burnett, D., Carter, J., Danielsen, P., 1052 Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K., 1053 and S. Tryphonas, "Voice Extensible Markup Language 1054 (VoiceXML) Version 2.0", W3C Recommendation, March 2004. 1056 Authors' Addresses 1058 Chris Boulton 1059 Ubiquity Software Corporation 1060 Building 3 1061 Wern Fawr Lane 1062 St Mellons 1063 Cardiff, South Wales CF3 5EA 1065 Email: cboulton@ubiquitysoftware.com 1067 Tim Melanchuk 1068 BlankSpace 1070 Email: tim.melanchuk@gmail.com 1072 Scott McGlashan 1073 Hewlett-Packard 1074 Gustav III:s boulevard 36 1075 SE-16985 Stockholm, Sweden 1077 Email: scott.mcglashan@hp.com 1079 Asher Shiratzky 1080 Radvision 1081 24 Raoul Wallenberg st 1082 Tel-Aviv, Israel 1084 Email: ashers@radvision.com 1086 Full Copyright Statement 1088 Copyright (C) The Internet Society (2006). 1090 This document is subject to the rights, licenses and restrictions 1091 contained in BCP 78, and except as set forth therein, the authors 1092 retain all their rights. 1094 This document and the information contained herein are provided on an 1095 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1096 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1097 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1098 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1099 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1100 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1102 Intellectual Property 1104 The IETF takes no position regarding the validity or scope of any 1105 Intellectual Property Rights or other rights that might be claimed to 1106 pertain to the implementation or use of the technology described in 1107 this document or the extent to which any license under such rights 1108 might or might not be available; nor does it represent that it has 1109 made any independent effort to identify any such rights. Information 1110 on the procedures with respect to rights in RFC documents can be 1111 found in BCP 78 and BCP 79. 1113 Copies of IPR disclosures made to the IETF Secretariat and any 1114 assurances of licenses to be made available, or the result of an 1115 attempt made to obtain a general license or permission for the use of 1116 such proprietary rights by implementers or users of this 1117 specification can be obtained from the IETF on-line IPR repository at 1118 http://www.ietf.org/ipr. 1120 The IETF invites any interested party to bring to its attention any 1121 copyrights, patents or patent applications, or other proprietary 1122 rights that may cover technology that may be required to implement 1123 this standard. Please address the information to the IETF at 1124 ietf-ipr@ietf.org. 1126 Acknowledgment 1128 Funding for the RFC Editor function is provided by the IETF 1129 Administrative Support Activity (IASA).