idnits 2.17.1 draft-boulton-ivr-vxml-control-package-00.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 968. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 945. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 958. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([9], [10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (March 8, 2006) is 6625 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) == Unused Reference: '4' is defined on line 862, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 866, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 869, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '2') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-09) exists of draft-vandyke-mscml-06 == Outdated reference: A later version (-05) exists of draft-boulton-sip-control-framework-01 == Outdated reference: A later version (-06) exists of draft-boulton-ivr-control-package-01 == Outdated reference: A later version (-03) exists of draft-mcglashan-mscp-01 Summary: 5 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 Expires: September 9, 2006 T. Melanchuk 5 BlankSpace 6 S. McGlashan 7 Hewlett-Packard 8 A. Shiratzky 9 Radvision 10 March 8, 2006 12 A VoiceXML Interactive Voice Response (IVR) Control Package for the 13 Session Initiation Protocol (SIP) 14 draft-boulton-ivr-vxml-control-package-00 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 September 9, 2006. 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 [9] and extends the Basic IVR control package [10] with 51 support for VoiceXML dialogs. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 57 3. Control Package Definition . . . . . . . . . . . . . . . . . . 4 58 3.1. Control Package Name . . . . . . . . . . . . . . . . . . . 4 59 3.2. Common XML Support . . . . . . . . . . . . . . . . . . . . 4 60 3.3. Framework Message Usage . . . . . . . . . . . . . . . . . 4 61 3.4. CONTROL Message Body . . . . . . . . . . . . . . . . . . . 5 62 3.4.1. dialogprepare . . . . . . . . . . . . . . . . . . . . 5 63 3.4.2. dialogstart . . . . . . . . . . . . . . . . . . . . . 7 64 3.4.3. dialoguser . . . . . . . . . . . . . . . . . . . . . . 9 65 3.4.4. dialogterminate . . . . . . . . . . . . . . . . . . . 10 66 3.5. REPORT Message Body . . . . . . . . . . . . . . . . . . . 10 67 3.5.1. dialogprepared . . . . . . . . . . . . . . . . . . . . 11 68 3.5.2. dialogstarted . . . . . . . . . . . . . . . . . . . . 11 69 3.5.3. dialogexit . . . . . . . . . . . . . . . . . . . . . . 11 70 3.5.4. dialoguser . . . . . . . . . . . . . . . . . . . . . . 12 71 3.5.5. Error Messages . . . . . . . . . . . . . . . . . . . . 12 72 4. Namelist . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 76 7.1. Control Package Registration . . . . . . . . . . . . . . . 19 77 7.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 19 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 83 Intellectual Property and Copyright Statements . . . . . . . . . . 22 85 1. Introduction 87 The SIP Control Framework [9] provides a generic approach for 88 establishment and reporting capabilities of remotely initiated 89 commands. The Framework utilizes many functions provided by the 90 Session Initiation Protocol [3] (SIP) for the rendezvous and 91 establishment of a reliable channel for control interactions. The 92 Control Framework also introduces the concept of a Control Package. 93 A Control Package is an explicit usage of the Control Framework for a 94 particular interaction set. 96 This specification defines a package for IVR functions using VoiceXML 97 dialogs [12]. As a recognized international standard for IVR 98 dialogs, VoiceXML is used extensively within media server control 99 languages (cf. [14], [11], [13], [8], [7]). To ensure 100 interoperability, if a media server supports this package, then it 101 MUST support VoiceXML 2.0 dialog scripts. It MAY support other 102 dialog script formats. 104 The VoiceXML package extends the basic IVR control package ([10]). 105 The extensions only affect the and 106 elements: in particular, 107 dialog scripts may also be specified inline using a element 108 the default value for the type attribute is "application/ 109 voicexml+xml" 110 HTTP fetching and caching of dialog scripts can be configured 111 using attributes of an element 112 Otherwise, this package follows precisely the syntax and semantics of 113 the basic IVR control package. 115 Other control packages may be defined which extend the capabilities 116 of the control package defined in this document. Such control 117 package must respect the syntax and semantics of this control 118 package. 120 2. Conventions and Terminology 122 In this document, BCP 14/RFC 2119 [1] defines the key words "MUST", 123 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 124 "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". In 125 addition, BCP 15 indicates requirement levels for compliant 126 implementations. 128 The following additional terms are defined for use in this document: 130 Dialog: A dialog performs media interaction with a user. A dialog is 131 identified by a URI and has an associated mimetype. Dialogs 132 typically feature basic capabilities such as playing audio 133 prompts, collecting DTMF input and recording audio input from the 134 user. More advanced dialogs may also feature synthesized speech, 135 recording and playback of video, recognition of spoken input, and 136 mixed initiative conversations. 137 Application server: A SIP [3] application server (AS) hosts and 138 executes services such as interactive media and conferencing in an 139 operator's network. An AS influences and impacts the SIP session, 140 in particular by terminating SIP sessions on a media server, which 141 is under its control. 142 Media Server: A media server (MS) processes media streams on behalf 143 of an AS by offering functionality such as interactive media, 144 conferencing, and transcoding to the end user. Interactive media 145 functionality is realized by way of dialogs, which are identified 146 by a URI and initiated by the application server. 148 3. Control Package Definition 150 This section fulfills the mandatory requirement for information that 151 MUST be specified during the definition of a Control Framework 152 Package, as detailed in Section 8 of [9]. 154 3.1. Control Package Name 156 The Control Framework requires a Control Package definition to 157 specify and register a unique name. 159 The name of this Control Package is "msc-ivr-vxml" (Media Server 160 Control - Interactive Voice Response - VoiceXML). This value appears 161 in the 'Control-Packages' SIP header that is present in the INVITE 162 dialog request that creates the control channel, as specified in [9]. 164 3.2. Common XML Support 166 The Control Framework requires a Control Package definition to 167 specify if the attributes for media dialog or conference references 168 are required. 170 This package requires that the XML Schema in Section 12.1 of [9] MUST 171 be supported. 173 3.3. Framework Message Usage 175 IVR functionality includes capabilities such as playing a prompt, 176 recording user input, collecting DTMF, TTS, ASR and other media-based 177 processing. These functions are expressed in VoiceXML dialogs. 179 The AS can send the following CONTROL messages to the MS: 180 : prepare a dialog for later execution 181 : execute a dialog (as defined or previously prepared) 182 : send a user-defined message to an active dialog 183 : terminate a dialog (prepared or started) 185 The MS response is specified in responses and/or REPORT messages. 186 The precise response is depend on the IVR dialog state, and the 187 contents of the control message. If an XML message is not well- 188 formed or invalid according to the schema in Section 5, then 4XX 189 response is generated. 191 For the command, the response is a (terminate) REPORT 192 with message (if the dialog was prepared 193 successfully) or with message (if there was 194 an error preparing the dialog). 196 For the command, the response is an (update) REPORT 197 with message (if the dialog was started 198 successfully), then zero or more (update) REPORT 199 messages (reporting information gathered during the dialog) and 200 finally a (terminate) REPORT with a message. If the 201 dialog does not start, the response is a (terminate) REPORT with a 202 message. 204 For the command, the response is 200 if the message is 205 understood. 207 For the command, the response is 200 if the command 208 is understood. 210 The MS can send following CONTROL message to the AS: 211 : send a user-defined message from an active dialog 213 The AS responds with a 200 response if the message was understood. 215 3.4. CONTROL Message Body 217 A valid CONTROL body message MUST conform to the schema defined in 218 Section 5. 220 3.4.1. dialogprepare 222 The request is sent from the AS to the MS to request 223 preparation of an IVR dialog. A prepared dialog is executed when the 224 AS sends a request referencing the prepared dialog (see 225 Section 3.4.2). 227 A element has the following attributes: 228 src: string identifying the URI of the dialog document to prepare. 229 The parameter is optional. The MS MUST support VoiceXML dialogs 230 and MAY support other dialog types. 231 type: string identifying the MIME type of the document. The default 232 value is "application/voicexml+xml". The attribute is optional. 234 The element has the following child elements: 235 : an XML data structure (see Section 4) to pass parameters 236 into the dialog. The element is optional. 237 : contains a list of one or more elements where 238 each item element has mandatory name and value attributes. The 239 element is optional. The AS uses this element to subscribe to 240 events generated by the MS. Notifications of dialog events are 241 delivered using a REPORT (see Section 3.4.3). If the 242 MS does not support a specific event notification to which the AS 243 subscribes, then the MS MUST ignore the individual . This 244 protocol does not require the MS to support any specific event 245 notifications, but the MS MAY support notification events such as 246 "dtmf" (indicating that a DTMF key has been pressed), or "tone" 247 (indicating that a tone has been detected), "audiostart" (audio 248 playback has started), "bargein" (user has barged in), "mark" (a 249 mark has been encountered in the output stream), "goto" (dialog 250 has transitioned to another location), and so forth. 251 : contains the dialog script itself; e.g. a VoiceXML document. 252 The element is optional. 253 : contains attributes to configure HTTP 1.1 [2] fetching 254 and caching. 255 maxage: string defining a time interval according to the max-age 256 parameter in HTTP. The attribute is optional. 257 maxstale: string defining a time interval according to the max- 258 stale parameter in HTTP. The attribute is optional. 259 enctype: string identifying the encoding type of the submitted 260 document. The default value is "application/ 261 x-www-form-url-encoded". The attribute is optional. 262 method: string indicating the HTTP method to use. Permitted 263 values are "post" or "get". The default value is "get". The 264 attribute is optional. 265 The element is optional. 266 Exactly one of the src attribute or the element MUST be 267 specified; otherwise, it is an error. 269 For example, a request to prepare a dialog where the dialog script is 270 indicated using the src attribute: 272 273 274 275 276 278 Where the namelist parameter "audio" would be available in the 279 VoiceXML script as "connection.ccxml.values.audio" so different 280 prompts can be played using the same dialog script. 282 In the following example, the VoiceXML dialog script is specified 283 inline. 285 286 287 288
289 290 293
294 295 296 298 When an MS has received a request, it MUST reply with 299 a or REPORT message. 301 3.4.2. dialogstart 303 The element is sent by the AS to request execution of a 304 dialog. The dialog may be defined in the dialogstart request itself, 305 or reference a previously prepared dialog. 307 The element has the following attributes: 308 src: string identifying the URI of the dialog document to start. The 309 attribute is optional. The MS MUST support VoiceXML dialogs and 310 MAY support other dialog types. 311 type: string identifying the MIME type of the document. The default 312 value is "application/voicexml+xml". The attribute is optional. 313 prepareddialogid: string identifying a dialog previously prepared 314 using a dialogprepare request. The attribute is optional. 315 connection-id: string identifying the SIP dialog connection on which 316 this dialog is to be started (see Section 12.1 of [9]). The 317 attribute is optional. 319 conf-id: string identifying the conference on which this dialog is to 320 be started (see Section 12.1 of [9]). The attribute is optional. 322 Exactly one of the connection-id or conf-id attributes MUST be 323 specified. It is an error to specify both connection-id and conf-id. 325 The element has the following child elements defined: 326 : an XML data structure (see Section 4) to pass parameters 327 into the dialog. The element is optional. 328 : contains a list of one or more elements where 329 each item element has mandatory name and value attributes. The 330 element is optional. 331 The AS uses this element to subscribe to events generated by the 332 MS. Notifications of dialog events are delivered using 333 REPORT (see Section 3.4.3). If the MS does not 334 support a specific event notification to which the AS subscribes, 335 then the MS MUST ignore the individual . This protocol does 336 not require the MS to support any specific event notifications, 337 but the MS MAY support notification events such as "dtmf" 338 (indicating that a DTMF key has been pressed), or "tone" 339 (indicating that a tone has been detected), "audiostart" (audio 340 playback has started), "bargein" (user has barged in), "mark" (a 341 mark has been encountered in the output stream), "goto" (dialog 342 has transitioned to another location), and so forth. 343 : contains the dialog script itself; e.g. a VoiceXML document. 344 The element is optional. 345 : contains attributes to configure HTTP 1.1 [2] fetching 346 and caching. 347 maxage: string defining a time interval according to the max-age 348 parameter in HTTP. The attribute is optional. 349 maxstale: string defining a time interval according to the max- 350 stale parameter in HTTP. The attribute is optional. 351 enctype: string identifying the encoding type of the submitted 352 document. The default value is "application/ 353 x-www-form-url-encoded". The attribute is optional. 354 method: string indicating the HTTP method to use. Permitted 355 values are "post" or "get". The default value is "get". The 356 attribute is optional. 357 The element is optional. 359 If the prepareddialogid is not specified, exactly one of the src 360 attribute or the element MUST be specified; otherwise, it is an 361 error. 363 If the prepareddialogid is specified, it is an error to specify the 364 src attribute, src element or the type attribute. 366 If the prepareddialogid is specified and the 367 contained a element, it is an error to specify it in 368 . Likewise, If the prepareddialogid is specified and 369 the contained a element, it is an error 370 to specify it in . 372 For example, a request to start a dialog on a conference where the 373 dialog script is indicated using the src attribute: 375 377 378 379 380 382 Where the namelist parameter "media" would be available in the 383 VoiceXML script as "connection.ccxml.values.media" so different 384 prompts can be played using the same dialog script. 386 In the following example, the VoiceXML dialog script is specified 387 inline. 389 390 391 392
393 394 397
398 399 400 402 In this example, a previously prepared dialog with the dialogid 403 "vxi1" is started. 405 407 When an MS has received a request, it MUST reply with a 408 or REPORT message. 410 3.4.3. dialoguser 412 During execution of a dialog, a CONTROL can be used to 413 pass asynchronous, user-defined events from the AS to the MS, or vice 414 versa from the MS to the AS. 416 The MS is not required to support receiving or sending asynchronous 417 events. If it does not support receiving asynchronous events, a 4XX 418 response will be returned instead of 200. 420 The element has the following attributes: 421 name: string indicating the name of event. The string is restricted 422 to a sequence of alphanumeric or "." characters. The attribute is 423 mandatory. 424 dialogid: string identifying the dialog. The attribute is mandatory. 426 A element has the following child element: 427 : an XML data structure (see Section 4) to pass information 428 from the AS to the dialog. The element is optional. 430 For example, the AS sends the MS information which may be announced 431 to the user in the dialog identified as "vxi1": 433 434 435 436 437 439 3.4.4. dialogterminate 441 A dialog that has been prepared or has been started can be terminated 442 by a request element from the AS. 444 The element has the following attributes: 445 dialogid: string identifying the dialog. The attribute is mandatory. 446 immediate: string with the values "true" or "false" indicating 447 whether the dialog is to be terminated immediately or not. The 448 default is "false". The attribute is optional. 450 For example, assuming a dialog with the dialogid "vxi1" has been 451 started, it can be terminated immediately with the following request: 453 455 The request causes execution of the dialog to be 456 terminated. If the request is for immediate termination, then the MS 457 sends a 200 response. If the request is for non-immediate 458 termination, then the MS send a REPORT (or a failure 459 message). 461 3.5. REPORT Message Body 463 A valid REPORT body MUST conform to the schema defined in Section 5. 465 3.5.1. dialogprepared 467 The element has following attributes: 468 dialogid: string identifying the dialog. The MS assigns a globally 469 unique identifier for this dialog and reuses it in subsequent 470 references to the dialog; for example, as the prepareddialogid in 471 and in dialog notifications. The attribute is 472 mandatory. 474 For example, a response when the dialog was prepared successfully: 476 478 3.5.2. dialogstarted 480 The element has the following attributes: 481 dialogid: string identifying the dialog. If prepareddialogid is 482 specified in the request, then dialogid MUST have the same value. 483 If prepareddialogid is not specified, then the MS assigns a 484 globally unique identifier for this dialog and reuses it in 485 subsequent references to the dialog; for example, in dialog 486 notifications. The attribute is mandatory. 488 [Editors Note: do we want to allow dialog names to be defined by the 489 AS?] 491 For example, a response when the dialog was started successfully. 493 495 3.5.3. dialogexit 497 The element has the following attributes: 498 dialogid: string identifying the dialog. The attribute is mandatory. 500 The element has the following child element: 501 : an XML data structure (see Section 4) to pass information 502 from the dialog to the AS. The element is optional. 504 For example, the dialog exits without data being returned: 506 508 The dialog exits and data is returned to the AS: 510 511 512 513 514 515 517 3.5.4. dialoguser 519 The element in a REPORT message can provide asychronous 520 user-defined information to the MS during execution of a dialog. 522 The element has the following attributes: 523 name: string indicating the name of event. The string is restricted 524 to a sequence of alphanumeric or "." characters. The attribute is 525 mandatory. 526 dialogid: string identifying the dialog. The attribute is mandatory. 528 A element has the following child element: 529 : an XML data structure (see Section 4) to pass information 530 from the AS to the dialog. The element is optional. 532 For example, the MS sends the AS a midcall update on data collected 533 so far: 535 536 537 538 539 540 542 [Editors note: Since is available as a CONTROL message, 543 it may not be necessary as REPORT message.] 545 3.5.5. Error Messages 547 [Editors Note: These message may be restructured as a general error 548 element with a type attribute (e.g. type="dialognotprepared").] 550 The element has following attributes: 551 dialogid: string identifying the dialog. The attribute is mandatory. 552 reason: string specifying the reason why dialog preparation failed. 553 The attribute is optional. 555 For example, a response when dialog preparation failed due to an HTTP 556 404 error when fetching a VoiceXML script: 558 561 The element has the following attributes: 562 dialogid: string identifying the dialog. The attribute is mandatory. 563 reason: string specifying the reason why the dialog failed to start. 564 The attribute is optional. 566 For example, a response when dialog failed to start due to a resource 567 error: 569 572 4. Namelist 574 The element is a container for parameter data. 576 Each parameter is specified using a top-level element. The 577 name of the parameter is specified in a "name" attribute with a non- 578 empty string value. 580 A simple value for a parameter is specified using a "value" attribute 581 with a string value. For example: 583 584 585 586 588 Multiple value parameters, such as a list of prompt URIs, can be 589 specified using space separation. For example: 591 592 593 595 [Editors Note: we may also want to investigate the use of s 596 nested within a top-level to specify complex values. ] 598 5. Formal Syntax 600 [Editors note: A later version of the XML schema may be reference the 601 basic IVR schema and specify the package extensions in terms of 602 schema extensions. ] 604 [Editors note: A later version of the XML schema will provide more 605 constraints as expressed in the textual definitions; for example, 606 single occurrence of elements, co-occurence on attributes, 607 etc.] 609 610 615 616 VoiceXML IVR 1.0 schema (20060308) 617 619 622 623 624 625 626 627 628 629 630 631 632 634 635 637 639 640 641 642 643 644 645 646 647 648 649 651 652 653 654 655 657 658 659 660 661 662 663 664 665 666 668 669 670 671 672 673 674 675 676 678 679 680 681 682 683 684 685 687 688 689 690 691 692 693 694 696 697 698 699 700 701 702 703 704 706 707 708 709 710 711 712 713 714 716 717 718 719 720 721 722 723 724 726 728 729 730 732 733 734 736 737 738 740 741 742 743 744 745 747 748 749 750 751 753 754 755 756 757 758 760 762 763 764 765 767 769 770 771 772 773 774 775 776 778 779 780 781 783 784 785 786 788 790 791 792 794 795 796 797 798 799 800 801 803 804 805 806 807 808 809 810 811 813 814 815 816 817 818 819 821 823 6. Security Considerations 825 Security Considerations to be included in later versions of this 826 document. 828 7. IANA Considerations 830 This document registers a new SIP Control Framework Package and a new 831 XML namespace. 833 7.1. Control Package Registration 835 Control Package name: msc-ivr-vxml 837 7.2. URN Sub-Namespace Registration 839 TODO: urn:ietf:params:xml:ns:msc-ivr-vxml 841 8. Acknowledgments 843 TODO 845 9. References 847 9.1. Normative References 849 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 850 Levels", BCP 14, RFC 2119, March 1997. 852 9.2. Informative References 854 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 855 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 856 HTTP/1.1", RFC 2616, June 1999. 858 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 859 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 860 Session Initiation Protocol", RFC 3261, June 2002. 862 [4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 863 Responses in Session Initiation Protocol (SIP)", RFC 3262, 864 June 2002. 866 [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 867 (SIP): Locating SIP Servers", RFC 3263, June 2002. 869 [6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 870 Session Description Protocol (SDP)", RFC 3264, June 2002. 872 [7] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media 873 Services with SIP", RFC 4240, December 2005. 875 [8] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control 876 Markup Language (MSCML) and Protocol", draft-vandyke-mscml-06 877 (work in progress), December 2004. 879 [9] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "A 880 Control Framework for the Session Initiation Protocol (SIP)", 881 draft-boulton-sip-control-framework-01 (work in progress), 882 March 2006. 884 [10] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "A 885 Basic Interactive Voice Response (IVR) Control Package for the 886 Session Initiation Protocol (SIP)", 887 draft-boulton-ivr-control-package-01 (work in progress), 888 March 2006. 890 [11] Auburn, R J., "Voice Browser Call Control: CCXML Version 1.0", 891 W3C Working Draft (work in progress), June 2005. 893 [12] McGlashan, S., Burnett, D., Carter, J., Danielsen, P., Ferrans, 894 J., Hunt, A., Lucas, B., Porter, B., Rehor, K., and S. 895 Tryphonas, "Voice Extensible Markup Language (VoiceXML) Version 896 2.0", W3C Recommendation, March 2004. 898 [13] Melanchuk, T., "Media Session Markup Language (MSML)", 899 draft-melanchuk-sipping-msml-07 (work in progress), 900 November 2005. 902 [14] McGlashan, S., Auburn, R., Burke, D., Candell, E., and R. 903 Surapaneni, "Media Server Control Protocol (MSCP)", 904 draft-mcglashan-mscp-01 (work in progress), January 2006. 906 Authors' Addresses 908 Chris Boulton 909 Ubiquity Software Corporation 910 Building 3 911 Wern Fawr Lane 912 St Mellons 913 Cardiff, South Wales CF3 5EA 915 Email: cboulton@ubiquitysoftware.com 917 Tim Melanchuk 918 BlankSpace 920 Email: tim.melanchuk@gmail.com 922 Scott McGlashan 923 Hewlett-Packard 924 Gustav III:s boulevard 36 925 SE-16985 Stockholm, Sweden 927 Email: scott.mcglashan@hp.com 929 Asher Shiratzky 930 Radvision 931 24 Raoul Wallenberg st 932 Tel-Aviv, Israel 934 Email: ashers@radvision.com 936 Intellectual Property Statement 938 The IETF takes no position regarding the validity or scope of any 939 Intellectual Property Rights or other rights that might be claimed to 940 pertain to the implementation or use of the technology described in 941 this document or the extent to which any license under such rights 942 might or might not be available; nor does it represent that it has 943 made any independent effort to identify any such rights. Information 944 on the procedures with respect to rights in RFC documents can be 945 found in BCP 78 and BCP 79. 947 Copies of IPR disclosures made to the IETF Secretariat and any 948 assurances of licenses to be made available, or the result of an 949 attempt made to obtain a general license or permission for the use of 950 such proprietary rights by implementers or users of this 951 specification can be obtained from the IETF on-line IPR repository at 952 http://www.ietf.org/ipr. 954 The IETF invites any interested party to bring to its attention any 955 copyrights, patents or patent applications, or other proprietary 956 rights that may cover technology that may be required to implement 957 this standard. Please address the information to the IETF at 958 ietf-ipr@ietf.org. 960 Disclaimer of Validity 962 This document and the information contained herein are provided on an 963 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 964 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 965 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 966 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 967 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 968 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 970 Copyright Statement 972 Copyright (C) The Internet Society (2006). This document is subject 973 to the rights, licenses and restrictions contained in BCP 78, and 974 except as set forth therein, the authors retain all their rights. 976 Acknowledgment 978 Funding for the RFC Editor function is currently provided by the 979 Internet Society.