Network Working Group D. Burke
Request for Comments: 5552 Google
Category: Standards Track M. Scott
Genesys
May 2009
Network Working Group D. Burke
Request for Comments: 5552 Google
Category: Standards Track M. Scott
Genesys
May 2009
SIP Interface to VoiceXML Media Services
VoiceXML媒体服务的SIP接口
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document describes a SIP interface to VoiceXML media services. Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism.
本文档描述了VoiceXML媒体服务的SIP接口。通常，控制媒体服务器的应用程序服务器使用此协议实现纯VoiceXML处理功能。此协议是完整MEDIACTRL协议和包机制的附加协议。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Use Cases ..................................................3
1.1.1. IVR Services with Application Servers ...............3
1.1.2. PSTN IVR Service Node ...............................4
1.1.3. 3GPP IMS Media Resource Function (MRF) ..............5
1.1.4. CCXML <-> VoiceXML Interaction ......................6
1.1.5. Other Use Cases .....................................6
1.2. Terminology ................................................7
2. VoiceXML Session Establishment and Termination ..................7
2.1. Service Identification .....................................7
2.2. Initiating a VoiceXML Session .............................10
2.3. Preparing a VoiceXML Session ..............................11
2.4. Session Variable Mappings .................................12
2.5. Terminating a VoiceXML Session ............................15
2.6. Examples ..................................................16
2.6.1. Basic Session Establishment ........................16
2.6.2. VoiceXML Session Preparation .......................17
2.6.3. MRCP Establishment .................................18
3. Media Support ..................................................19
3.1. Offer/Answer ..............................................19
3.2. Early Media ...............................................19
3.3. Modifying the Media Session ...............................21
3.4. Audio and Video Codecs ....................................21
3.5. DTMF ......................................................22
4. Returning Data to the Application Server .......................22
4.1. HTTP Mechanism ............................................22
4.2. SIP Mechanism .............................................23
5. Outbound Calling ...............................................25
6. Call Transfer ..................................................25
6.1. Blind .....................................................26
6.2. Bridge ....................................................27
6.3. Consultation ..............................................29
7. Contributors ...................................................31
8. Acknowledgements ...............................................31
9. Security Considerations ........................................31
10. IANA Considerations ...........................................32
11. References ....................................................32
11.1. Normative References .....................................32
11.2. Informative References ...................................35
Appendix A. Notes on Normative References ........................36
1. Introduction ....................................................3
1.1. Use Cases ..................................................3
1.1.1. IVR Services with Application Servers ...............3
1.1.2. PSTN IVR Service Node ...............................4
1.1.3. 3GPP IMS Media Resource Function (MRF) ..............5
1.1.4. CCXML <-> VoiceXML Interaction ......................6
1.1.5. Other Use Cases .....................................6
1.2. Terminology ................................................7
2. VoiceXML Session Establishment and Termination ..................7
2.1. Service Identification .....................................7
2.2. Initiating a VoiceXML Session .............................10
2.3. Preparing a VoiceXML Session ..............................11
2.4. Session Variable Mappings .................................12
2.5. Terminating a VoiceXML Session ............................15
2.6. Examples ..................................................16
2.6.1. Basic Session Establishment ........................16
2.6.2. VoiceXML Session Preparation .......................17
2.6.3. MRCP Establishment .................................18
3. Media Support ..................................................19
3.1. Offer/Answer ..............................................19
3.2. Early Media ...............................................19
3.3. Modifying the Media Session ...............................21
3.4. Audio and Video Codecs ....................................21
3.5. DTMF ......................................................22
4. Returning Data to the Application Server .......................22
4.1. HTTP Mechanism ............................................22
4.2. SIP Mechanism .............................................23
5. Outbound Calling ...............................................25
6. Call Transfer ..................................................25
6.1. Blind .....................................................26
6.2. Bridge ....................................................27
6.3. Consultation ..............................................29
7. Contributors ...................................................31
8. Acknowledgements ...............................................31
9. Security Considerations ........................................31
10. IANA Considerations ...........................................32
11. References ....................................................32
11.1. Normative References .....................................32
11.2. Informative References ...................................35
Appendix A. Notes on Normative References ........................36
VoiceXML [VXML20], [VXML21] is a World Wide Web Consortium (W3C) standard for creating audio and video dialogs that feature synthesized speech, digitized audio, recognition of spoken and dual tone multi-frequency (DTMF) key input, recording of audio and video, telephony, and mixed-initiative conversations. VoiceXML allows Web-based development and content delivery paradigms to be used with interactive video and voice response applications.
VoiceXML[VXML20]，[VXML21]是一个万维网联盟（W3C）标准，用于创建音频和视频对话框，其功能包括合成语音、数字化音频、语音和双音多频（DTMF）按键输入识别、音频和视频录制、电话和混合主动对话。VoiceXML允许在交互式视频和语音响应应用程序中使用基于Web的开发和内容交付模式。
This document describes a SIP [RFC3261] interface to VoiceXML media services. Commonly, Application Servers controlling media servers use this protocol for pure VoiceXML processing capabilities. SIP is responsible for initiating a media session to the VoiceXML media server and simultaneously triggering the execution of a specified VoiceXML application. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism.
本文档描述了VoiceXML媒体服务的SIP[RFC3261]接口。通常，控制媒体服务器的应用程序服务器使用此协议实现纯VoiceXML处理功能。SIP负责启动到VoiceXML媒体服务器的媒体会话，同时触发指定VoiceXML应用程序的执行。此协议是完整MEDIACTRL协议和包机制的附加协议。
The interface described here leverages a mechanism for identifying dialog media services first described in [RFC4240]. The interface has been updated and extended to support the W3C Recommendation for VoiceXML 2.0 [VXML20] and VoiceXML 2.1 [VXML21]. A set of commonly implemented functions and extensions have been specified including VoiceXML dialog preparation, outbound calling, video media support, and transfers. VoiceXML session variable mappings have been defined for SIP with an extensible mechanism for passing application-specific values into the VoiceXML application. Mechanisms for returning data to the Application Server have also been added.
这里描述的接口利用了一种机制来识别[RFC4240]中首先描述的对话媒体服务。该接口已更新和扩展，以支持W3C对VoiceXML 2.0[VXML20]和VoiceXML 2.1[VXML21]的建议。已经指定了一组通常实现的功能和扩展，包括VoiceXML对话框准备、出站呼叫、视频媒体支持和传输。已经为SIP定义了VoiceXML会话变量映射，该映射具有可扩展机制，用于将特定于应用程序的值传递到VoiceXML应用程序。还添加了将数据返回到应用服务器的机制。
The VoiceXML media service user in this document is generically referred to as an Application Server. In practice, it is intended that the interface defined by this document be applicable across a wide range of use cases. Several intended use cases are described below.
本文档中的VoiceXML媒体服务用户一般称为应用程序服务器。在实践中，本文档定义的接口适用于广泛的用例。下面描述了几个预期用例。
SIP Application Servers provide services to users of the network. Typically, there may be several Application Servers in the same network, each specialized in providing a particular service. Throughout this specification and without loss of generality, we posit the presence of an Application Server specialized in providing Interactive Voice Response (IVR) services. A typical configuration for this use case is illustrated below.
SIP应用服务器为网络用户提供服务。通常，在同一网络中可能有多个应用服务器，每个服务器专门提供特定的服务。在本规范中，在不丧失通用性的情况下，我们假定存在专门提供交互式语音响应（IVR）服务的应用服务器。此用例的典型配置如下所示。
+--------------+
| |
| Application |\
| Server | \
| | \ HTTP
SIP +--------------+ \
/ \ \
+-------------+ / SIP \ +--------------+
| |/ \| |
| SIP | | VoiceXML |
| User Agent | RTP/SRTP | Media Server |
| |=====================| |
+-------------+ +--------------+
+--------------+
| |
| Application |\
| Server | \
| | \ HTTP
SIP +--------------+ \
/ \ \
+-------------+ / SIP \ +--------------+
| |/ \| |
| SIP | | VoiceXML |
| User Agent | RTP/SRTP | Media Server |
| |=====================| |
+-------------+ +--------------+
Assuming the Application Server also supports HTTP, the VoiceXML application may be hosted on it and served up via HTTP [RFC2616]. Note, however, that the Web model allows the VoiceXML application to be hosted on a separate (HTTP) Application Server from the (SIP) Application Server that interacts with the VoiceXML Media Server via this specification. It is also possible for a static VoiceXML application to be stored locally on the VoiceXML Media Server, leveraging the VoiceXML 2.1 [VXML21] <data> mechanism to interact with a Web/Application Server when dynamic behavior is required. The viability of static VoiceXML applications is further enhanced by the mechanisms defined in Section 2.4, through which the Application Server can make session-specific information available within the VoiceXML session context.
假设应用服务器也支持HTTP，VoiceXML应用程序可以托管在该服务器上，并通过HTTP[RFC2616]提供服务。但是，请注意，Web模型允许VoiceXML应用程序托管在单独的（HTTP）应用程序服务器上，而不是通过此规范与VoiceXML媒体服务器交互的（SIP）应用程序服务器上。静态VoiceXML应用程序也可以本地存储在VoiceXML媒体服务器上，利用VoiceXML 2.1[VXML21]<data>机制在需要动态行为时与Web/应用程序服务器交互。第2.4节中定义的机制进一步增强了静态VoiceXML应用程序的可行性，通过这些机制，应用服务器可以在VoiceXML会话上下文中提供特定于会话的信息。
The approach described in this document is sometimes termed the "delegation model" -- the Application Server is essentially delegating programmatic control of the human-machine interactions to one or more VoiceXML documents running on the VoiceXML Media Server. During the human-machine interactions, the Application Server remains in the signaling path and can respond to results returned from the VoiceXML Media Server or other external network events.
本文档中描述的方法有时被称为“委托模型”——应用服务器实质上是将人机交互的编程控制委托给VoiceXML媒体服务器上运行的一个或多个VoiceXML文档。在人机交互期间，应用程序服务器保持在信令路径中，并且可以响应从VoiceXML媒体服务器返回的结果或其他外部网络事件。
While this document is intended to enable enhanced use of VoiceXML as a component of larger systems and services, it is intended that devices that are completely unaware of this specification remain capable of invoking VoiceXML services offered by a VoiceXML Media Server compliant with this document. A typical configuration for this use case is as follows:
虽然本文档旨在增强VoiceXML作为更大系统和服务组件的使用，但完全不了解本规范的设备仍能够调用符合本文档的VoiceXML媒体服务器提供的VoiceXML服务。此用例的典型配置如下所示：
+-------------+ SIP +--------------+
| |---------------------| |
| IP/PSTN | | VoiceXML |
| Gateway | RTP/SRTP | Media Server |
| |=====================| |
+-------------+ +--------------+
+-------------+ SIP +--------------+
| |---------------------| |
| IP/PSTN | | VoiceXML |
| Gateway | RTP/SRTP | Media Server |
| |=====================| |
+-------------+ +--------------+
Note also that beyond the invocation and termination of a VoiceXML dialog, the semantics defined for call transfers using REFER are intended to be compatible with standard, existing IP/PSTN (Public Switched Telephone Network) gateways.
还请注意，除了调用和终止VoiceXML对话框之外，使用REFER为呼叫转移定义的语义旨在与标准的现有IP/PSTN（公共交换电话网络）网关兼容。
The 3rd Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS) [TS23002] defines a Media Resource Function (MRF) used to offer media processing services such as conferencing, transcoding, and prompt/collect. The capabilities offered by VoiceXML are ideal for offering richer media processing services in the context of the MRF. In this architecture, the interface defined here corresponds to the "Mr" interface to the MRFC (MRF Controller); the implementation of this interface might use separated MRFC and MRFP (MRF Processor) elements (as per the IMS architecture), or might be an integrated MRF (as is common practice).
第三代合作伙伴计划（3GPP）IP多媒体子系统（IMS）[TS23002]定义了一种媒体资源功能（MRF），用于提供媒体处理服务，如会议、转码和提示/收集。VoiceXML提供的功能非常适合在MRF环境中提供更丰富的媒体处理服务。在此架构中，此处定义的接口对应于MRFC（MRF控制器）的“Mr”接口；该接口的实现可能使用分离的MRFC和MRFP（MRF处理器）元素（根据IMS体系结构），或者可能是一个集成的MRF（按照惯例）。
+----------+
| App |
| Server |
+----------+
|
| SIP (ISC)
|
+----------+ SIP (Mr) +--------------+
| S-CSCF |---------------| VoiceXML |
| | | MRF |
+----------+ +--------------+
||
|| RTP/SRTP (Mb)
||
+----------+
| App |
| Server |
+----------+
|
| SIP (ISC)
|
+----------+ SIP (Mr) +--------------+
| S-CSCF |---------------| VoiceXML |
| | | MRF |
+----------+ +--------------+
||
|| RTP/SRTP (Mb)
||
The above diagram is highly simplified and shows a subset of nodes typically involved in MRF interactions. It should be noted that while the MRF will primarily be used by the Application Server via the Serving Call Session Control Function (S-CSCF), it is also possible for calls to be routed directly to the MRF without the involvement of an Application Server.
上图高度简化，显示了MRF交互中通常涉及的节点子集。应当注意的是，虽然MRF将主要由应用服务器通过服务呼叫会话控制功能（S-CSCF）使用，但是也可以在不涉及应用服务器的情况下将呼叫直接路由到MRF。
Although the above is described in terms of the 3GPP IMS architecture, it is intended that it is also applicable to 3GPP2, Next Generation Network (NGN), and PacketCable architectures that are converging with 3GPP IMS standards.
尽管以上是根据3GPP IMS体系结构描述的，但其目的是也适用于与3GPP IMS标准融合的3GPP2、下一代网络（NGN）和分组电缆体系结构。
Call Control eXtensible Markup Language (CCXML) 1.0 [CCXML10] applications provide services mainly through controlling the interaction between Connections, Conferences, and Dialogs. Although CCXML is capable of supporting arbitrary dialog environments, VoiceXML is commonly used as a dialog environment in conjunction with CCXML applications; CCXML is specifically designed to effectively support the use of VoiceXML. CCXML 1.0 defines language elements that allow for Dialogs to be prepared, started, and terminated; it further allows for data to be returned by the dialog environment, for call transfers to be requested (by the dialog) and responded to by the CCXML application, and for arbitrary eventing between the CCXML application and running dialog application.
调用控制可扩展标记语言（CCXML）1.0[CCXML10]应用程序主要通过控制连接、会议和对话框之间的交互来提供服务。尽管CCXML能够支持任意对话环境，但VoiceXML通常与CCXML应用程序一起用作对话环境；CCXML是专门为有效支持VoiceXML的使用而设计的。CCXML 1.0定义了允许准备、启动和终止对话框的语言元素；它还允许对话环境返回数据，允许CCXML应用程序请求（对话）和响应调用传输，允许CCXML应用程序和正在运行的对话应用程序之间发生任意事件。
The interface described in this document can be used by CCXML 1.0 implementations to control VoiceXML Media Servers. Note, however, that some CCXML language features require eventing facilities between CCXML and VoiceXML sessions that go beyond what is defined in this specification. For example, VoiceXML-controlled call transfers and mid-dialog, application-defined events cannot be fully realized using this specification alone. A SIP event package [RFC3265] MAY be used in addition to this specification to provide extended eventing.
本文档中描述的接口可由CCXML 1.0实现用于控制VoiceXML媒体服务器。但是，请注意，一些CCXML语言特性需要CCXML和VoiceXML会话之间的事件处理功能，这超出了本规范中的定义。例如，仅使用此规范无法完全实现VoiceXML控制的呼叫转移和mid对话、应用程序定义的事件。除了本规范之外，还可以使用SIP事件包[RFC3265]来提供扩展事件。
In addition to the use cases described in some detail above, there are a number of other intended use cases that are not described in detail, such as:
除了上面一些详细描述的用例外，还有一些未详细描述的其他预期用例，例如：
1. Use of a VoiceXML Media Server as an adjunct to an IP-based Private Branch Exchange / Automatic Call Distributor (PBX/ACD), possibly to provide voicemail/messaging, automated attendant, or other capabilities.
1. 使用VoiceXML媒体服务器作为基于IP的专用分支交换机/自动呼叫分发服务器（PBX/ACD）的附件，可能提供语音邮件/消息传递、自动助理或其他功能。
2. Invocation and control of a VoiceXML session that provides the voice modality component in a multimodal system.
2. 调用和控制VoiceXML会话，该会话在多模式系统中提供语音模态组件。
Application Server: A SIP Application Server hosts and executes services, in particular by terminating SIP sessions on a media server. The Application Server MAY also act as an HTTP server [RFC2616] in interactions with media servers.
应用服务器：SIP应用服务器承载和执行服务，特别是通过终止媒体服务器上的SIP会话。应用服务器还可以在与媒体服务器的交互中充当HTTP服务器[RFC2616]。
VoiceXML Media Server: A VoiceXML interpreter including a SIP-based interpreter context and the requisite media processing capabilities to support VoiceXML functionality.
VoiceXML媒体服务器：VoiceXML解释器，包括基于SIP的解释器上下文和支持VoiceXML功能所需的媒体处理功能。
VoiceXML Session: A VoiceXML Session is a multimedia session comprising of at least a SIP User Agent, a VoiceXML Media Server, the data streams between them, and an executing VoiceXML application.
VoiceXML会话：VoiceXML会话是多媒体会话，至少包括SIP用户代理、VoiceXML媒体服务器、它们之间的数据流和正在执行的VoiceXML应用程序。
VoiceXML Dialog: Equivalent to VoiceXML Session.
VoiceXML对话框：相当于VoiceXML会话。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section describes how to establish a VoiceXML Session, with or without preparation, and how to terminate a session. This section also addresses how session information is made available to VoiceXML applications.
本节介绍如何建立VoiceXML会话（无论是否准备），以及如何终止会话。本节还讨论了如何将会话信息提供给VoiceXML应用程序。
The SIP Request-URI is used to identify the VoiceXML media service. The user part of the SIP Request-URI is fixed to "dialog". This is done to ensure compatibility with [RFC4240], since this document extends the dialog interface defined in that specification and because this convention from [RFC4240] is widely adopted by existing media servers.
SIP请求URI用于标识VoiceXML媒体服务。SIP请求URI的用户部分固定为“对话框”。这样做是为了确保与[RFC4240]的兼容性，因为本文档扩展了该规范中定义的对话框接口，并且[RFC4240]中的此约定被现有媒体服务器广泛采用。
Standardizing the SIP Request-URI including the user part also improves interoperability between Application Servers and media servers, and reduces the provisioning overhead that would be required if use of a media server by an Application Server required an individually provisioned URI. In this respect, this document (and [RFC4240]) do not add semantics to the user part, but rather standardize the way that targets on media servers are provisioned. Further, since Application Servers -- and not human beings -- are generally the clients of media servers, issues such as interpretation and internationalization do not apply.
标准化包括用户部分的SIP请求URI还改进了应用服务器和媒体服务器之间的互操作性，并减少了在应用服务器使用媒体服务器需要单独配置的URI时所需的配置开销。在这方面，本文档（和[RFC4240]）没有向用户部分添加语义，而是标准化了媒体服务器上目标的配置方式。此外，由于应用服务器（而不是人类）通常是媒体服务器的客户机，因此解释和国际化等问题不适用。
Exposing a VoiceXML media service with a well-known address may enhance the possibility of exploitation: the VoiceXML Media Server is RECOMMENDED to use standard SIP mechanisms to authenticate endpoints as discussed in Section 9.
公开具有已知地址的VoiceXML媒体服务可能会增加利用该服务的可能性：建议VoiceXML媒体服务器使用标准SIP机制对端点进行身份验证，如第9节所述。
The initial VoiceXML document is specified with the "voicexml" parameter. In addition, parameters are defined that control how the VoiceXML Media Server fetches the specified VoiceXML document. The list of parameters defined by this specification is as follows (note the parameter names are case-insensitive):
初始VoiceXML文档由“VoiceXML”参数指定。此外，还定义了控制VoiceXML媒体服务器如何获取指定VoiceXML文档的参数。本规范定义的参数列表如下（注意，参数名称不区分大小写）：
voicexml: URI of the initial VoiceXML document to fetch. This will typically contain an HTTP URI, but may use other URI schemes, for example, to refer to local, static VoiceXML documents. If the "voicexml" parameter is omitted, the VoiceXML Media Server may select the initial VoiceXML document by other means, such as by applying a default, or may reject the request.
voicexml：要获取的初始voicexml文档的URI。这通常包含一个HTTP URI，但可能使用其他URI模式，例如，引用本地静态VoiceXML文档。如果省略了“voicexml”参数，voicexml媒体服务器可以通过其他方式（例如通过应用默认值）选择初始voicexml文档，或者可以拒绝请求。
maxage: Used to set the max-age value of the Cache-Control header in conjunction with VoiceXML documents fetched using HTTP, as per [RFC2616]. If omitted, the VoiceXML Media Server will use a default value.
maxage：用于根据[RFC2616]结合使用HTTP获取的VoiceXML文档设置缓存控制头的最大年龄值。如果省略，VoiceXML媒体服务器将使用默认值。
maxstale: Used to set the max-stale value of the Cache-Control header in conjunction with VoiceXML documents fetched using HTTP, as per [RFC2616]. If omitted, the VoiceXML Media Server will use a default value.
maxstale：用于根据[RFC2616]结合使用HTTP获取的VoiceXML文档设置缓存控制头的最大stale值。如果省略，VoiceXML媒体服务器将使用默认值。
method: Used to set the HTTP method applied in the fetch of the initial VoiceXML document. Allowed values are "get" or "post" (case-insensitive). Default is "get".
方法：用于设置获取初始VoiceXML文档时应用的HTTP方法。允许的值为“get”或“post”（不区分大小写）。默认值为“get”。
postbody: Used to set the application/x-www-form-urlencoded encoded [HTML4] HTTP body for "post" requests (or is otherwise ignored).
postbody：用于为“post”请求设置application/x-www-form-urlencoded[HTML4]HTTP正文（否则将被忽略）。
ccxml: Used to specify a "JSON value" [RFC4627] that is mapped to the session.connection.ccxml VoiceXML session variable -- see Section 2.4.
ccxml：用于指定映射到session.connection.ccxml VoiceXML会话变量的“JSON值”[RFC4627]——请参见第2.4节。
aai: Used to specify a "JSON value" [RFC4627] that is mapped to the session.connection.aai VoiceXML session variable -- see Section 2.4.
aai：用于指定映射到session.connection.aai VoiceXML会话变量的“JSON值”[RFC4627]——请参见第2.4节。
Other application-specific parameters may be added to the Request-URI and are exposed in VoiceXML session variables (see Section 2.4).
其他特定于应用程序的参数可以添加到请求URI中，并在VoiceXML会话变量中公开（参见第2.4节）。
Formally, the Request-URI for the VoiceXML media service has a fixed user part "dialog". Seven URI parameters are defined (see the definition of uri-parameter in Section 25.1 of [RFC3261]).
形式上，VoiceXML媒体服务的请求URI有一个固定的用户部分“对话框”。定义了七个URI参数（参见[RFC3261]第25.1节中URI参数的定义）。
dialog-param = "voicexml=" vxml-url ; vxml-url follows the URI
; syntax defined in [RFC3986]
maxage-param = "maxage=" 1*DIGIT
maxstale-param = "maxstale=" 1*DIGIT
method-param = "method=" ("get" / "post")
postbody-param = "postbody=" token
ccxml-param = "ccxml=" json-value
aai-param = "aai=" json-value
json-value = false /
null /
true /
object /
array /
number /
string ; defined in [RFC4627]
dialog-param = "voicexml=" vxml-url ; vxml-url follows the URI
; syntax defined in [RFC3986]
maxage-param = "maxage=" 1*DIGIT
maxstale-param = "maxstale=" 1*DIGIT
method-param = "method=" ("get" / "post")
postbody-param = "postbody=" token
ccxml-param = "ccxml=" json-value
aai-param = "aai=" json-value
json-value = false /
null /
true /
object /
array /
number /
string ; defined in [RFC4627]
Parameters of the Request-URI in subsequent re-INVITEs are ignored. One consequence of this is that the VoiceXML Media Server cannot be instructed by the Application Server to change the executing VoiceXML Application after a VoiceXML Session has been started.
忽略后续重新邀请中请求URI的参数。这样做的一个后果是，在VoiceXML会话启动后，应用程序服务器无法指示VoiceXML媒体服务器更改正在执行的VoiceXML应用程序。
Special characters contained in the dialog-param, postbody-param, ccxml-param, and aai-param values must be URL-encoded ("escaped") as required by the SIP URI syntax, for example, '?' (%3f), '=' (%3d), and ';' (%3b). The VoiceXML Media Server MUST therefore unescape these parameter values before making use of them or exposing them to running VoiceXML applications. It is important that the VoiceXML Media Server only unescape the parameter values once since the desired VoiceXML URI value could itself be URL encoded, for example.
对话框参数、postbody参数、ccxml参数和aai参数值中包含的特殊字符必须按照SIP URI语法的要求进行URL编码（“转义”），例如，“？”（%3f）、“=”（%3d）和“；”（%3b）。因此，VoiceXML媒体服务器必须在使用这些参数值或将其公开给运行中的VoiceXML应用程序之前取消对这些参数值的扫描。VoiceXML媒体服务器仅对参数值取消扫描一次很重要，因为所需的VoiceXML URI值本身可以是URL编码的，例如。
Since some applications may choose to transfer confidential information, the VoiceXML Media Server MUST support the sips: scheme as discussed in Section 9.
由于某些应用程序可能选择传输机密信息，VoiceXML媒体服务器必须支持第9节中讨论的sips:scheme。
Informative note: With respect to the postbody-param value, since the application/x-www-form-urlencoded content itself escapes non-alphanumeric characters by inserting %HH replacements, the escaping rules above will result in the '%' characters being further escaped in addition to the '&' and '=' name/value separators.
资料性说明：关于postbody参数值，由于应用程序/x-www-form-urlencoded内容本身通过插入%HH替换来转义非字母数字字符，因此上述转义规则将导致“%”字符在“&”和“=”名称/值分隔符之外进一步转义。
As an example, the following SIP Request-URI identifies the use of VoiceXML media services, with 'http://appserver.example.com/promptcollect.vxml' as the initial VoiceXML document, to be fetched with max-age/max-stale values of 3600s/0s, respectively:
例如，下面的SIP请求URI标识VoiceXML媒体服务的使用，带有'http://appserver.example.com/promptcollect.vxml'作为初始VoiceXML文档，分别以3600s/0s的最大年龄/最大过时值获取：
sip:dialog@mediaserver.example.com; \
voicexml=http://appserver.example.com/promptcollect.vxml; \
maxage=3600;maxstale=0
sip:dialog@mediaserver.example.com; \
voicexml=http://appserver.example.com/promptcollect.vxml; \
maxage=3600;maxstale=0
A VoiceXML Session is initiated via the Application Server using a SIP INVITE. Typically, the Application Server will be specialized in providing VoiceXML services. At a minimum, the Application Server may behave as a simple proxy by rewriting the Request-URI received from the User Agent to a Request-URI suitable for consumption by the VoiceXML Media Server (as specified in Section 2.1). For example, a User Agent might present a dialed number:
VoiceXML会话通过应用服务器使用SIP INVITE启动。通常，应用服务器将专门提供VoiceXML服务。至少，应用服务器可以通过将从用户代理接收的请求URI重写为适合VoiceXML媒体服务器使用的请求URI（如第2.1节所述），作为简单代理。例如，用户代理可能会显示一个已拨号码：
tel:+1-201-555-0123
电话：+1-201-555-0123
that the Application Server maps to a directory assistance application on the VoiceXML Media Server with a Request-URI of:
应用程序服务器映射到VoiceXML媒体服务器上的目录辅助应用程序，请求URI为：
sip:dialog@ms1.example.com; \
voicexml=http://as1.example.com/da.vxml
sip:dialog@ms1.example.com; \
voicexml=http://as1.example.com/da.vxml
Certain header values in the INVITE message to the VoiceXML Media Server are mapped into VoiceXML session variables and are specified in Section 2.4.
到VoiceXML媒体服务器的INVITE消息中的某些头值映射到VoiceXML会话变量中，并在第2.4节中指定。
On receipt of the INVITE, the VoiceXML Media Server issues a provisional response, 100 Trying, and commences the fetch of the initial VoiceXML document. The 200 OK response indicates that the VoiceXML document has been fetched and parsed correctly and is ready for execution. Application execution commences on receipt of the ACK (except if the dialog is being prepared as specified in Section 2.3). Note that the 100 Trying response will usually be sent on receipt of the INVITE in accordance with [RFC3261], since the VoiceXML Media Server cannot in general guarantee that the initial fetch will complete in less than 200 ms. However, certain implementations may be able to guarantee response times to the initial INVITE, and thus may not need to send a 100 Trying response.
在收到邀请后，VoiceXML媒体服务器发出一个临时响应100 Trying，并开始获取初始VoiceXML文档。200OK响应表示VoiceXML文档已被正确获取和解析，并准备好执行。应用程序执行在收到ACK后开始（除非按照第2.3节的规定准备对话框）。请注意，由于VoiceXML媒体服务器通常不能保证初始提取在200毫秒内完成，因此根据[RFC3261]，100 Trying响应通常会在收到邀请后发送。但是，某些实现可能能够保证对初始邀请的响应时间，因此可能不需要发送100次尝试响应。
As an optimization, prior to sending the 200 OK response, the VoiceXML Media Server MAY execute the application up to the point of the first VoiceXML waiting state or prompt flush.
作为优化，在发送200 OK响应之前，VoiceXML媒体服务器可以执行应用程序，直到第一个VoiceXML等待状态或提示刷新。
A VoiceXML Media Server, like any SIP User Agent, may be unable to accept the INVITE request for a variety of reasons. For instance, a Session Description Protocol (SDP) offer contained in the INVITE might require the use of codecs that are not supported by the Media Server. In such cases, the Media Server should respond as defined by [RFC3261]. However, there are error conditions specific to VoiceXML, as follows:
VoiceXML媒体服务器与任何SIP用户代理一样，可能由于各种原因无法接受INVITE请求。例如，INVITE中包含的会话描述协议（SDP）服务可能需要使用媒体服务器不支持的编解码器。在这种情况下，媒体服务器应按照[RFC3261]的定义进行响应。但是，VoiceXML特有的错误条件如下：
1. If the Request-URI does not conform to this specification, a 400 Bad Request MUST be returned (unless it is used to select other services not defined by this specification).
1. 如果请求URI不符合本规范，则必须返回400错误请求（除非它用于选择本规范未定义的其他服务）。
2. If a URI parameter in the Request-URI is repeated, then the request MUST be rejected with a 400 Bad Request response.
2. 如果请求URI中的URI参数被重复，则必须以400错误的请求响应拒绝该请求。
3. If the Request-URI does not include a "voicexml" parameter, and the VoiceXML Media Server does not elect to use a default page, the VoiceXML Media Server MUST return a final response of 400 Bad Request, and it SHOULD include a Warning header with a 3-digit code of 399 and a human-readable error message.
3. 如果请求URI不包含“voicexml”参数，并且voicexml媒体服务器不选择使用默认页面，则voicexml媒体服务器必须返回400个错误请求的最终响应，并且它应该包含一个警告标头，其中有一个3位代码399和一条人类可读的错误消息。
4. If the VoiceXML document cannot be fetched or parsed, the VoiceXML Media Server MUST return a final response of 500 Server Internal Error and SHOULD include a Warning header with a 3-digit code of 399 and a human-readable error message.
4. 如果无法获取或解析VoiceXML文档，VoiceXML媒体服务器必须返回500服务器内部错误的最终响应，并应包含一个警告标头，其中包含一个3位代码399和一条人类可读的错误消息。
Informative note: Certain applications may pass a significant amount of data to the VoiceXML dialog in the form of Request-URI parameters. This may cause the total size of the INVITE request to exceed the MTU of the underlying network. In such cases, applications/ implementations must take care either to use a transport appropriate to these larger messages (such as TCP) or to use alternative means of passing the required information to the VoiceXML dialog (such as supplying a unique session identifier in the initial VoiceXML URI and later using that identifier as a key to retrieve data from the HTTP server).
信息提示：某些应用程序可能会以请求URI参数的形式向VoiceXML对话框传递大量数据。这可能导致INVITE请求的总大小超过基础网络的MTU。在这种情况下，应用程序/实现必须注意使用适合于这些较大消息的传输（如TCP），或者使用其他方式将所需信息传递到VoiceXML对话框（例如在初始VoiceXMLURI中提供唯一的会话标识符，然后将该标识符用作从HTTP服务器检索数据的密钥）。
In certain scenarios, it is beneficial to prepare a VoiceXML Session for execution prior to running it. A previously prepared VoiceXML Session is expected to execute with minimal delay when instructed to do so.
在某些场景中，在运行VoiceXML会话之前，为其执行做好准备是有益的。当指示执行之前准备好的VoiceXML会话时，预期该会话将以最小的延迟执行。
If a media-less SIP dialog is established with the initial INVITE to the VoiceXML Media Server, the VoiceXML application will not execute after receipt of the ACK. To run the VoiceXML application, the Application Server (AS) must issue a re-INVITE to establish a media session.
如果通过对VoiceXML媒体服务器的初始邀请建立了无媒体SIP对话框，则VoiceXML应用程序在收到ACK后将不会执行。要运行VoiceXML应用程序，应用程序服务器（AS）必须发出重新邀请以建立媒体会话。
A media-less SIP dialog can be established by sending an SDP containing no media lines in the initial INVITE. Alternatively, if no SDP is sent in the initial INVITE, the VoiceXML Media Server will include an offer in the 200 OK message, which can be responded to with an answer in the ACK with the media port(s) set to 0.
通过在初始邀请中发送不包含媒体行的SDP，可以建立无媒体SIP对话框。或者，如果初始邀请中未发送SDP，VoiceXML媒体服务器将在200 OK消息中包含一个要约，该要约可以在媒体端口设置为0的ACK中用应答进行响应。
Once a VoiceXML application is running, a re-INVITE that disables the media streams (i.e., sets the ports to 0) will not otherwise affect the executing application (except that recognition actions initiated while the media streams are disabled will result in noinput timeouts).
VoiceXML应用程序运行后，禁用媒体流（即，将端口设置为0）的重新邀请不会影响正在执行的应用程序（除非禁用媒体流时启动的识别操作将导致无输入超时）。
The standard VoiceXML session variables are assigned values according to:
标准VoiceXML会话变量的赋值依据：
session.connection.local.uri: Evaluates to the SIP URI specified in the To: header of the initial INVITE.
session.connection.local.uri：计算为初始邀请的to:头中指定的SIP uri。
session.connection.remote.uri: Evaluates to the SIP URI specified in the From: header of the initial INVITE.
session.connection.remote.uri:计算为初始邀请的From:头中指定的SIP uri。
session.connection.redirect: This array is populated by information contained in the History-Info [RFC4244] header in the initial INVITE or is otherwise undefined. Each entry (hi-entry) in the History-Info header is mapped, in reverse order, into an element of the session.connection.redirect array. Properties of each element of the array are determined as follows:
session.connection.redirect：此数组由初始邀请中历史信息[RFC4244]头中包含的信息填充，或者未定义。历史信息头中的每个条目（hi条目）按相反顺序映射到session.connection.redirect数组的元素中。数组中每个元素的属性确定如下：
* uri - Set to the hi-targeted-to-uri value of the History-Info entry
* uri-设置为历史信息项的hi目标uri值
* pi - Set to 'true' if hi-targeted-to-uri contains a "Privacy=history" parameter, or if the INVITE Privacy header includes 'history'; 'false' otherwise
* pi-如果针对uri的hi包含“Privacy=history”参数，或者如果INVITE Privacy标头包含“history”，则设置为“true”否则为假
* si - Set to the value of the "si" parameter if it exists, undefined otherwise
* si-设置为“si”参数的值（如果存在），否则未定义
* reason - Set verbatim to the value of the "Reason" parameter of hi-targeted-to-uri
* reason-将verbatim设置为hi的“reason”参数的值，该参数的目标是uri
session.connection.protocol.name: Evaluates to "sip". Note that this is intended to reflect the use of SIP in general, and does not distinguish between whether the media server was accessed via SIP or SIPS procedures.
session.connection.protocol.name:计算为“sip”。请注意，这是为了反映SIP的一般使用，并不区分是通过SIP还是SIPS过程访问媒体服务器。
session.connection.protocol.version: Evaluates to "2.0".
session.connection.protocol.version:计算结果为“2.0”。
session.connection.protocol.sip.headers: This is an associative array where each key in the array is the non-compact name of a SIP header in the initial INVITE converted to lowercase (note the case conversion does not apply to the header value). If multiple header fields of the same field name are present, the values are combined into a single comma-separated value. Implementations MUST at a minimum include the Call-ID header and MAY include other headers. For example, session.connection.protocol.sip.headers["call-id"] evaluates to the Call-ID of the SIP dialog.
session.connection.protocol.sip.headers：这是一个关联数组，其中数组中的每个键都是初始INVITE中sip头的非压缩名称，转换为小写（注意，大小写转换不适用于头值）。如果存在具有相同字段名的多个标题字段，则这些值将合并为一个逗号分隔的值。实现必须至少包括Call ID头，还可以包括其他头。例如，session.connection.protocol.sip.headers[“call id”]计算为sip对话框的调用id。
session.connection.protocol.sip.requesturi: This is an associative array where the array keys and values are formed from the URI parameters on the SIP Request-URI of the initial INVITE. The array key is the URI parameter name converted to lowercase (note the case conversion does not apply to the parameter value). The corresponding array value is obtained by evaluating the URI parameter value as a "JSON value" [RFC4627] in the case of the ccxml-param and aai-param values and otherwise as a string. In addition, the array's toString() function returns the full SIP Request-URI. For example, assuming a Request-URI of sip:dialog@ example.com;voicexml=http://example.com;aai=%7b"x":1%2c"y":true%7d then session.connection.protocol.sip.requesturi["voicexml"] evaluates to "http://example.com", session.connection.protocol.sip.requesturi["aai"].x evaluates to 1 (type Number), session.connection.protocol.sip.requesturi["aai"].y evaluates to true (type Boolean), and session.connection.protocol.sip.requesturi evaluates to the complete Request-URI (type String) 'sip:dialog@ example.com;voicexml=http://example.com;aai={"x":1,"y":true}'.
session.connection.protocol.sip.requesturi：这是一个关联数组，其中数组键和值由初始INVITE的sip请求URI上的URI参数组成。数组键是转换为小写的URI参数名（注意大小写转换不适用于参数值）。对于ccxml参数和aai参数值，通过将URI参数值作为“JSON值”[RFC4627]进行求值，或者作为字符串进行求值，从而获得相应的数组值。此外，数组的toString（）函数返回完整的SIP请求URI。例如，假设请求URI为sip:dialog@example.com；voicexml=http://example.com;aai=%7b“x”：1%2c“y”：true%7d然后session.connection.protocol.sip.requesturi[“voicexml”]计算结果为“http://example.com，session.connection.protocol.sip.requesturi[“aai”].x计算为1（类型编号），session.connection.protocol.sip.requesturi[“aai”].y计算为true（类型布尔），session.connection.protocol.sip.requesturi计算为完整的请求URI（类型字符串）'sip:dialog@example.com；voicexml=http://example.com;aai={“x”：1，“y”：真}。
session.connection.aai: Evaluates to session.connection.protocol.sip.requesturi["aai"].
session.connection.aai：计算为session.connection.protocol.sip.requesturi[“aai”]。
session.connection.ccxml: Evaluates to session.connection.protocol.sip.requesturi["ccxml"].
session.connection.ccxml：计算结果为session.connection.protocol.sip.requesturi[“ccxml”]。
session.connection.protocol.sip.media: This is an array where each array element is an object with the following properties:
session.connection.protocol.sip.media：这是一个数组，其中每个数组元素都是具有以下属性的对象：
* type: - This required property indicates the type of the media associated with the stream. The value is a string. It is strongly recommended that the following values are used for common types of media: "audio" for audio media, and "video" for video media.
* 类型：-此必需属性表示与流关联的媒体类型。该值是一个字符串。强烈建议将以下值用于常见类型的媒体：“音频”用于音频媒体，“视频”用于视频媒体。
* direction: - This required property indicates the directionality of the media relative to session.connection.originator. Defined values are sendrecv, sendonly, recvonly, and inactive.
* 方向：-此必需属性表示媒体相对于session.connection.originator的方向性。定义的值为sendrecv、sendonly、RecVoOnly和inactive。
* format: - This property is optional. If defined, the value of the property is an array. Each array element is an object that specifies information about one format of the media (there is an array element for each payload type on the m-line). The object contains at least one property called "name" whose value is the MIME subtype of the media format (MIME subtypes are registered in [RFC4855]). Other properties may be defined with string values; these correspond to required and, if defined, optional parameters of the format.
* 格式：-此属性是可选的。如果已定义，则该属性的值为数组。每个数组元素都是一个对象，用于指定有关一种媒体格式的信息（m行上的每个有效负载类型都有一个数组元素）。该对象至少包含一个名为“name”的属性，其值为媒体格式的MIME子类型（MIME子类型在[RFC4855]中注册）。其他属性可以用字符串值定义；这些参数对应于格式的必需参数和可选参数（如果已定义）。
As a consequence of this definition, there is an array entry in session.connection.protocol.sip.media for each non-disabled m-line for the negotiated media session. Note that this session variable is updated if the media session characteristics for the VoiceXML Session change (i.e., due to a re-INVITE). For an example, consider a connection with bidirectional G.711 mu-law "audio" sampled at 8 kHz. In this case, session.connection.protocol.sip.media[0].type evaluates to "audio", session.connection.protocol.sip.media[0].direction to "sendrecv", session.connection.protocol.sip.media[0].format[0].name evaluates to "audio/PCMU", and session.connection.protocol.sip.media[0].format[0].rate evaluates to "8000".
根据此定义，在session.connection.protocol.sip.media中，对于协商的媒体会话，每个未禁用的m线都有一个数组条目。请注意，如果VoiceXML会话的媒体会话特征发生更改（即，由于重新邀请），则会更新此会话变量。例如，考虑与8 GHz采样的双向G.711μ定律“音频”的连接。在本例中，session.connection.protocol.sip.media[0]。类型的计算结果为“audio”，session.connection.protocol.sip.media[0]。指向“sendrecv”，session.connection.protocol.sip.media[0]。格式[0]。名称的计算结果为“audio/PCMU”，session.connection.protocol.sip.media[0]。格式[0]。速率的计算结果为“8000”。
Note that when accessing SIP headers and Request-URI parameters via the session.connection.protocol.sip.headers and session.connection.protocol.sip.requesturi associative arrays defined above, applications can choose between two semantically equivalent ways of referring to the array. For example, either of the following can be used to access a Request-URI parameter named "foo":
请注意，当通过上面定义的session.connection.protocol.SIP.headers和session.connection.protocol.SIP.requesturi关联数组访问SIP头和请求URI参数时，应用程序可以在引用数组的两种语义等效方式之间进行选择。例如，可以使用以下任一项访问名为“foo”的请求URI参数：
session.connection.protocol.sip.requesturi["foo"] session.connection.protocol.sip.requesturi.foo
session.connection.protocol.sip.requesturi[“foo”]session.connection.protocol.sip.requesturi.foo
However, it is important to note that not all SIP header names or Request-URI parameter names are valid ECMAScript identifiers, and as such, can only be accessed using the first form (array notation). For example, the Call-ID header can only be accessed as session.connection.protocol.sip.headers["call-id"]; attempting to access the same value as session.connection.protocol.sip.headers.call-id would result in an error.
但是，需要注意的是，并非所有SIP头名称或请求URI参数名称都是有效的ECMAScript标识符，因此只能使用第一种形式（数组表示法）进行访问。例如，调用ID头只能作为session.connection.protocol.sip.headers[“Call ID”]访问；尝试访问与session.connection.protocol.sip.headers.call-id相同的值将导致错误。
The Application Server can terminate a VoiceXML Session by issuing a BYE to the VoiceXML Media Server. Upon receipt of a BYE in the context of an existing VoiceXML Session, the VoiceXML Media Server MUST send a 200 OK response and MUST throw a 'connection.disconnect.hangup' event to the VoiceXML application. If the Reason header [RFC3326] is present on the BYE Request, then the value of the Reason header is provided verbatim via the '_message' variable within the catch element's anonymous variable scope.
应用服务器可以通过向VoiceXML媒体服务器发出BYE来终止VoiceXML会话。在现有VoiceXML会话的上下文中收到BYE后，VoiceXML媒体服务器必须发送200 OK响应，并且必须向VoiceXML应用程序抛出“connection.disconnect.hangup”事件。如果BYE请求中存在原因头[RFC3326]，则通过catch元素匿名变量范围内的“\u message”变量逐字提供原因头的值。
The VoiceXML Media Server may also initiate termination of the session by issuing a BYE request. This will typically occur as a result of encountering a <disconnect> or <exit> in the VoiceXML application, due to the VoiceXML application running to completion, or due to unhandled errors within the VoiceXML application.
VoiceXML媒体服务器还可以通过发出BYE请求来发起会话终止。这通常是由于在VoiceXML应用程序中遇到<disconnect>或<exit>、VoiceXML应用程序运行到完成或VoiceXML应用程序中未处理的错误而导致的。
See Section 4 for mechanisms to return data to the Application Server.
有关将数据返回到应用服务器的机制，请参见第4节。
This example illustrates an Application Server setting up a VoiceXML Session on behalf of a User Agent.
此示例演示了一个应用程序服务器代表用户代理设置VoiceXML会话。
SIP VoiceXML HTTP
User Application Media Application
Agent Server Server Server
| | | |
|(1) INVITE [offer] | | |
|------------------->|(2) INVITE [offer] | |
|(3) 100 Trying |------------------->| |
|<-------------------|(4) 100 Trying | |
| |<-------------------| |
| | | |
| | |(5) GET |
| | |------------------->|
| | |(6) 200 OK [VXML] |
| | |<-------------------|
| | | |
| |(7) 200 OK [answer] | |
|(8) 200 OK [answer] |<-------------------| |
|<-------------------| | |
|(9) ACK | | |
|------------------->|(10) ACK | |
| |------------------->| (execute |
|(11) RTP/SRTP | | VoiceXML |
|.........................................| application) |
| | | |
SIP VoiceXML HTTP
User Application Media Application
Agent Server Server Server
| | | |
|(1) INVITE [offer] | | |
|------------------->|(2) INVITE [offer] | |
|(3) 100 Trying |------------------->| |
|<-------------------|(4) 100 Trying | |
| |<-------------------| |
| | | |
| | |(5) GET |
| | |------------------->|
| | |(6) 200 OK [VXML] |
| | |<-------------------|
| | | |
| |(7) 200 OK [answer] | |
|(8) 200 OK [answer] |<-------------------| |
|<-------------------| | |
|(9) ACK | | |
|------------------->|(10) ACK | |
| |------------------->| (execute |
|(11) RTP/SRTP | | VoiceXML |
|.........................................| application) |
| | | |
This example demonstrates the preparation of a VoiceXML Session. In this example, the VoiceXML session is prepared prior to placing an outbound call to a User Agent, and is started as soon as the User Agent answers.
此示例演示VoiceXML会话的准备。在本例中，VoiceXML会话在向用户代理发出出站呼叫之前准备好，并在用户代理应答后立即启动。
The [answer1:0] notation is used to indicate an SDP answer with the media ports set to 0.
[answer1:0]符号用于指示媒体端口设置为0的SDP应答。
SIP VoiceXML HTTP
User Application Media Application
Agent Server Server Server
| | | |
| |(1) INVITE | |
| |-------------------->| |
| |(2) 100 Trying | |
| |<--------------------| |
| | | |
| | |(3) GET |
| | |------------------->|
| | |(4) 200 OK [VXML] |
| | |<-------------------|
| | | |
| |(5) 200 OK [offer1] | |
| |<--------------------| |
| |(6) ACK [answer1:0] | |
|(7) INVITE |-------------------->| |
|<-------------------| | |
|(8) 200 OK [offer2] | | |
|------------------->|(9) INVITE [offer2'] | |
| |-------------------->| |
| |(10) 100 Trying | |
| |<--------------------| |
| |(11) 200 OK [answer2]| |
|(12) ACK [answer2] |<--------------------| |
|<-------------------|(13) ACK | |
| |-------------------->| (execute |
|(14) RTP/SRTP | VoiceXML |
|..........................................| application) |
| | | |
SIP VoiceXML HTTP
User Application Media Application
Agent Server Server Server
| | | |
| |(1) INVITE | |
| |-------------------->| |
| |(2) 100 Trying | |
| |<--------------------| |
| | | |
| | |(3) GET |
| | |------------------->|
| | |(4) 200 OK [VXML] |
| | |<-------------------|
| | | |
| |(5) 200 OK [offer1] | |
| |<--------------------| |
| |(6) ACK [answer1:0] | |
|(7) INVITE |-------------------->| |
|<-------------------| | |
|(8) 200 OK [offer2] | | |
|------------------->|(9) INVITE [offer2'] | |
| |-------------------->| |
| |(10) 100 Trying | |
| |<--------------------| |
| |(11) 200 OK [answer2]| |
|(12) ACK [answer2] |<--------------------| |
|<-------------------|(13) ACK | |
| |-------------------->| (execute |
|(14) RTP/SRTP | VoiceXML |
|..........................................| application) |
| | | |
Implementation detail: offer2' is derived from offer2 -- it duplicates the m-lines and a-lines from offer2. However, offer2' differs from offer2 since it must contain the same o-line as used in answer1:0 but with the version number incremented. Also, if offer1 has more m-lines than offer2, then offer2' must be padded with extra (rejected) m-lines.
实现细节：offer2’是从offer2派生的——它复制了offer2的m线和a线。但是，offer2'与offer2不同，因为它必须包含与answer1:0中使用的o形线相同的o形线，但版本号增加。此外，如果报价人1的m-线多于报价人2，则报价人2'必须用额外的（被拒绝的）m-线填充。
Media Resource Control Protocol (MRCP) [MRCPv2] is a protocol that enables clients such as a VoiceXML Media Server to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network.
媒体资源控制协议（MRCP）[MRCPv2]是一种协议，它使客户端（如VoiceXML媒体服务器）能够控制媒体服务资源（如语音合成器、识别器、验证器和驻留在网络服务器中的标识符）。
The example below illustrates how a VoiceXML Media Server may establish an MRCP session in response to an initial INVITE.
下面的示例说明了VoiceXML媒体服务器如何建立MRCP会话以响应初始邀请。
VoiceXML HTTP
User Media MRCPv2 Application
Agent Server Server Server
| | | |
|(1) INVITE [offer1] | | |
|------------------->| | |
|(2) 100 Trying | | |
|<-------------------|(3) GET | |
| |---------------------------------------->|
| | | |
| |(4) 200 OK [VXML] | |
| |<----------------------------------------|
| | | |
| |(5) INVITE [offer2] | |
| |--------------------->| |
| | | |
| |(6) 200 OK [answer2] | |
| |<---------------------| |
| | | |
| |(7) ACK | |
| |--------------------->| |
| | | |
| |(8) MRCP connection | |
| |<-------------------->| |
|(9) 200 OK [answer1]| | |
|<-------------------| | |
| | | |
|(10) ACK | | |
|------------------->| | |
| | | |
|(11) RTP/SRTP | | |
|...........................................| |
| | | |
VoiceXML HTTP
User Media MRCPv2 Application
Agent Server Server Server
| | | |
|(1) INVITE [offer1] | | |
|------------------->| | |
|(2) 100 Trying | | |
|<-------------------|(3) GET | |
| |---------------------------------------->|
| | | |
| |(4) 200 OK [VXML] | |
| |<----------------------------------------|
| | | |
| |(5) INVITE [offer2] | |
| |--------------------->| |
| | | |
| |(6) 200 OK [answer2] | |
| |<---------------------| |
| | | |
| |(7) ACK | |
| |--------------------->| |
| | | |
| |(8) MRCP connection | |
| |<-------------------->| |
|(9) 200 OK [answer1]| | |
|<-------------------| | |
| | | |
|(10) ACK | | |
|------------------->| | |
| | | |
|(11) RTP/SRTP | | |
|...........................................| |
| | | |
In this example, the VoiceXML Media Server is responsible for establishing a session with the MRCPv2 Media Resource Server prior to sending the 200 OK response to the initial INVITE. The VoiceXML Media Server will perform the appropriate offer/answer with the MRCPv2 Media Resource Server based on the SDP capabilities of the Application Server and the MRCPv2 Media Resource Server. The VoiceXML Media Server will change the offer received from step 1 to establish an MRCPv2 session in step (5) and will re-write the SDP to include an m-line for each MRCPv2 resource to be used and other required SDP modifications as specified by MRCPv2. Once the VoiceXML Media Server performs the offer/answer with the MRCPv2 Media Resource Server, it will establish an MRCPv2 control channel in step (8). The MRCPv2 resource is deallocated when the VoiceXML Media Server receives or sends a BYE (not shown).
在本例中，VoiceXML媒体服务器负责在向初始邀请发送200 OK响应之前与MRCPv2媒体资源服务器建立会话。VoiceXML媒体服务器将根据应用服务器和MRCPv2媒体资源服务器的SDP功能，使用MRCPv2媒体资源服务器执行适当的提供/应答。VoiceXML媒体服务器将更改从步骤1收到的报价，以在步骤（5）中建立MRCPv2会话，并将重新写入SDP，以包括每个要使用的MRCPv2资源的m线以及MRCPv2指定的其他所需SDP修改。VoiceXML媒体服务器使用MRCPv2媒体资源服务器执行提供/应答后，将在步骤（8）中建立MRCPv2控制通道。当VoiceXML媒体服务器接收或发送BYE（未显示）时，MRCPv2资源被解除分配。
This section describes the mandatory and optional media support required by this interface.
本节介绍此接口所需的强制和可选媒体支持。
The VoiceXML Media Server MUST support the standard offer/answer mechanism of [RFC3264]. In particular, if an SDP offer is not present in the INVITE, the VoiceXML Media Server will make an offer in the 200 OK response listing its supported codecs.
VoiceXML媒体服务器必须支持[RFC3264]的标准提供/应答机制。特别是，如果邀请中不存在SDP报价，VoiceXML媒体服务器将在200 OK响应中提供报价，列出其支持的编解码器。
The VoiceXML Media Server MAY support early establishment of media streams as described in [RFC3960]. This allows the Application Server to establish media streams between a User Agent and the VoiceXML Media Server in parallel with the initial VoiceXML document being processed (which may involve dynamic VoiceXML page generation and interaction with databases or other systems). This is useful primarily for minimizing the delay in starting a VoiceXML Session, particularly in cases where a session with the User Agent already exists but the media stream associated with that session needs to be redirected to a VoiceXML Media Server.
VoiceXML媒体服务器可支持如[RFC3960]所述的媒体流的早期建立。这允许应用服务器在用户代理和VoiceXML媒体服务器之间建立媒体流，同时处理初始VoiceXML文档（这可能涉及动态VoiceXML页面生成以及与数据库或其他系统的交互）。这主要用于最小化启动VoiceXML会话的延迟，特别是在与用户代理的会话已经存在但与该会话相关联的媒体流需要重定向到VoiceXML媒体服务器的情况下。
The following flow demonstrates the use of early media (using the Gateway model defined in [RFC3960]):
以下流程演示了早期媒体的使用（使用[RFC3960]中定义的网关模型）：
SIP VoiceXML HTTP
User Application Media Application
Agent Server Server Server
| | | |
|..(existing session)..| | |
| |(1) INVITE | |
| |------------------>| |
| | |(2) HTTP GET |
| | |------------------>|
| |(3) 183 [offer] | |
|(4) re-INVITE [offer] |<------------------| |
|<---------------------| | |
|(5) 200 OK [answer] | | |
|--------------------->| | |
|(6) ACK | | |
|<---------------------| | |
| | (7) PRACK [answer]| |
| |------------------>| |
| | (8) PRACK 200 OK | |
| |<------------------| |
|(9) RTP/SRTP | | |
|..........................................| |
| | |(10) 200 OK [VXML] |
| | |<------------------|
| | | |
| |(11) 200 OK | |
| |<------------------| |
| |(12) ACK | |
| |------------------>| (execute |
| | | VoiceXML |
| | | application) |
| | | |
SIP VoiceXML HTTP
User Application Media Application
Agent Server Server Server
| | | |
|..(existing session)..| | |
| |(1) INVITE | |
| |------------------>| |
| | |(2) HTTP GET |
| | |------------------>|
| |(3) 183 [offer] | |
|(4) re-INVITE [offer] |<------------------| |
|<---------------------| | |
|(5) 200 OK [answer] | | |
|--------------------->| | |
|(6) ACK | | |
|<---------------------| | |
| | (7) PRACK [answer]| |
| |------------------>| |
| | (8) PRACK 200 OK | |
| |<------------------| |
|(9) RTP/SRTP | | |
|..........................................| |
| | |(10) 200 OK [VXML] |
| | |<------------------|
| | | |
| |(11) 200 OK | |
| |<------------------| |
| |(12) ACK | |
| |------------------>| (execute |
| | | VoiceXML |
| | | application) |
| | | |
Although [RFC3960] prefers the use of the Application Server model for early media over the Gateway model, the primary issue with the Gateway model -- forking -- is significantly less common when issuing requests to VoiceXML Media Servers. This is because VoiceXML Media Servers respond to all requests with 200 OK responses in the absence of unusual errors, and they typically do so within several hundred milliseconds. This makes them unlikely targets in forking scenarios, since alternative targets of the forking process would virtually never be able to respond more quickly than an automated system, unless they are themselves automated systems -- in which case, there is little point in setting up a response time race between two automated systems. Issues with ringing tone generation in the Gateway model are also mitigated, both by the typically quick 200 OK
尽管[RFC3960]更喜欢在早期媒体中使用应用服务器模型而不是网关模型，但网关模型的主要问题——分叉——在向VoiceXML媒体服务器发出请求时明显不太常见。这是因为VoiceXML媒体服务器在没有异常错误的情况下以200 OK响应响应所有请求，并且通常在几百毫秒内完成。这使得它们不太可能成为分叉场景中的目标，因为分叉过程的替代目标几乎永远无法比自动化系统更快地响应，除非它们本身是自动化系统——在这种情况下，在两个自动化系统之间建立响应时间竞赛没有什么意义。网关型号中的铃声生成问题也可以通过典型的quick 200 OK解决
response time, and because this specification mandates that no media packets are generated until the receipt of an ACK (thus eliminating the need for the User Agent to perform media packet analysis).
响应时间，并且因为该规范要求在接收到ACK之前不生成媒体分组（从而消除了用户代理执行媒体分组分析的需要）。
Note that the offer of early media by a VoiceXML Media Server does not imply that the referenced VoiceXML application can always be fetched and executed successfully. For instance, if the HTTP Application Server were to return a 4xx response in step 10 above, or if the provided VoiceXML content was not valid, the VoiceXML Media Server would still return a 500 response (as per Section 2.2). At this point, it would be the responsibility of the Application Server to tear down any media streams established with the media server.
请注意，VoiceXML媒体服务器提供的早期媒体并不意味着引用的VoiceXML应用程序总能成功获取和执行。例如，如果HTTP应用程序服务器在上述步骤10中返回4xx响应，或者如果提供的VoiceXML内容无效，VoiceXML媒体服务器仍将返回500响应（根据第2.2节）。此时，应用程序服务器将负责断开与媒体服务器建立的任何媒体流。
The VoiceXML Media Server MUST allow the media session to be modified via a re-INVITE and SHOULD support the UPDATE method [RFC3311] for the same purpose. In particular, it MUST be possible to change streams between sendrecv, sendonly, and recvonly as specified in [RFC3264].
VoiceXML媒体服务器必须允许通过重新邀请修改媒体会话，并应支持更新方法[RFC3311]，以达到相同目的。特别是，必须能够按照[RFC3264]中的规定在sendrecv、sendonly和RecVoOnly之间更改流。
Unidirectional streams are useful for announcement- or listening-only (hotword). The preferred mechanism for putting the media session on hold is specified in [RFC3264], i.e., the UA modifies the stream to be sendonly and mutes its own stream. Modification of the media session does not affect VoiceXML application execution (except that recognition actions initiated while on hold will result in noinput timeouts).
单向流对于公告或仅收听（hotword）非常有用。[RFC3264]中规定了用于暂停媒体会话的首选机制，即UA将流修改为仅发送，并使其自己的流静音。对媒体会话的修改不会影响VoiceXML应用程序的执行（除非在保留期间启动的识别操作将导致noinput超时）。
For the purposes of achieving a basic level of interoperability, this section specifies a minimal subset of codecs and RTP [RFC3550] payload formats that MUST be supported by the VoiceXML Media Server.
为了实现基本的互操作性，本节规定了VoiceXML媒体服务器必须支持的编解码器和RTP[RFC3550]有效负载格式的最小子集。
For audio-only applications, G.711 mu-law and A-law MUST be supported using the RTP payload type 0 and 8 [RFC3551]. Other codecs and payload formats MAY be supported.
对于仅音频应用，必须使用RTP有效负载类型0和8支持G.711 mu定律和A定律[RFC3551]。可能支持其他编解码器和有效负载格式。
Video telephony applications, which employ a video stream in addition to the audio stream, are possible in VoiceXML 2.0/2.1 through the use of multimedia file container formats such as the .3gp [TS26244] and .mp4 formats [IEC14496-14]. Video support is optional for this specification. If video is supported then:
通过使用多媒体文件容器格式，例如.3gp[TS26244]和.mp4格式[IEC14496-14]，可以在VoiceXML 2.0/2.1中使用除音频流之外的视频流的视频电话应用程序。对于本规范，视频支持是可选的。如果支持视频，则：
1. H.263 Baseline [RFC4629] MUST be supported. For legacy reasons, the 1996 version of H.263 MAY be supported using the RTP payload format defined in [RFC2190] (payload type 34 [RFC3551]).
1. 必须支持H.263基线[RFC4629]。出于传统原因，可以使用[RFC2190]（有效负载类型34[RFC3551]）中定义的RTP有效负载格式支持1996版H.263。
2. Adaptive Multi-Rate (AMR) narrow band audio [RFC4867] SHOULD be supported.
2. 应支持自适应多速率（AMR）窄带音频[RFC4867]。
3. MPEG-4 video [RFC3016] SHOULD be supported.
3. 应支持MPEG-4视频[RFC3016]。
4. MPEG-4 Advanced Audio Coding (AAC) audio [RFC3016] SHOULD be supported.
4. 应支持MPEG-4高级音频编码（AAC）音频[RFC3016]。
5. Other codecs and payload formats MAY be supported.
5. 可能支持其他编解码器和有效负载格式。
Video record operations carried out by the VoiceXML Media Server typically require receipt of an intra-frame before the recording can commence. The VoiceXML Media Server SHOULD use the mechanism described in [RFC4585] to request that a new intra-frame be sent.
VoiceXML媒体服务器执行的视频录制操作通常需要在开始录制之前接收帧内帧。VoiceXML媒体服务器应使用[RFC4585]中描述的机制来请求发送新的帧内帧。
Since some applications may choose to transfer confidential information, the VoiceXML Media Server MUST support Secure RTP (SRTP) [RFC3711] as discussed in Section 9.
由于某些应用程序可能选择传输机密信息，VoiceXML媒体服务器必须支持安全RTP（SRTP）[RFC3711]，如第9节所述。
DTMF events [RFC4733] MUST be supported. When the User Agent does not indicate support for [RFC4733], the VoiceXML Media Server MAY perform DTMF detection using other means such as detecting DTMF tones in the audio stream. Implementation note: the reason only [RFC4733] telephone-events must be used when the User Agent indicates support of it is to avoid the risk of double detection of DTMF if detection on the audio stream was simultaneously applied.
必须支持DTMF事件[RFC4733]。当用户代理未指示支持[RFC4733]时，VoiceXML媒体服务器可使用诸如检测音频流中的DTMF音调等其他手段执行DTMF检测。实施说明：当用户代理表示支持[RFC4733]电话事件时，仅使用[RFC4733]电话事件的原因是为了避免在同时应用音频流检测时双重检测DTMF的风险。
This section discusses the mechanisms for returning data (e.g., collected utterance or digit information) from the VoiceXML Media Server to the Application Server.
本节讨论从VoiceXML媒体服务器向应用程序服务器返回数据（例如，收集的话语或数字信息）的机制。
At any time during the execution of the VoiceXML application, data can be returned to the Application Server via HTTP using standard VoiceXML elements such as <submit> or <subdialog>. Notably, the <data> element in VoiceXML 2.1 [VXML21] allows data to be sent to the Application Server efficiently without requiring a VoiceXML page transition and is ideal for short VoiceXML applications such as "prompt and collect".
在VoiceXML应用程序执行期间的任何时候，都可以使用标准VoiceXML元素（如<submit>或<subdialog>）通过HTTP将数据返回到应用程序服务器。值得注意的是，VoiceXML 2.1[VXML21]中的<data>元素允许将数据高效地发送到应用程序服务器，而无需VoiceXML页面转换，并且非常适合于简短的VoiceXML应用程序，如“提示和收集”。
For most applications, it is necessary to correlate the information being passed over HTTP with a particular VoiceXML Session. One way this can be achieved is to include the SIP Call-ID (accessible in
对于大多数应用程序，有必要将通过HTTP传递的信息与特定的VoiceXML会话关联起来。实现这一点的一种方法是包含SIP呼叫ID（可在中访问）
VoiceXML via the session.connection.protocol.sip.headers array) within the HTTP POST fields. Alternatively, a unique "POST-back URI" can be specified as an application-specific URI parameter in the Request-URI of the initial INVITE (accessible in VoiceXML via the session.connection.protocol.sip.requesturi array).
通过HTTP POST字段中的session.connection.protocol.sip.headers数组）访问VoiceXML。或者，可以在初始邀请的请求URI中指定唯一的“回发URI”作为特定于应用程序的URI参数（可通过session.connection.protocol.sip.requesturi数组在VoiceXML中访问）。
Since some applications may choose to transfer confidential information, the VoiceXML Media Server MUST support the https: scheme as discussed in Section 9.
由于某些应用程序可能选择传输机密信息，VoiceXML媒体服务器必须支持https:方案，如第9节所述。
Data can be returned to the Application Server via the expr or namelist attribute on <exit> or the namelist attribute on <disconnect>. A VoiceXML Media Server MUST support encoding of the expr/namelist data in the message body of a BYE request sent from the VoiceXML Media Server as a result of encountering the <exit> or <disconnect> element. A VoiceXML Media Server MAY support inclusion of the expr/namelist data in the message body of the 200 OK message in response to a received BYE request (i.e., when the VoiceXML application responds to the connection.disconnect.hangup event and subsequently executes an <exit> element with the expr or namelist attribute specified).
数据可以通过<exit>上的expr或namelist属性或<disconnect>上的namelist属性返回到应用程序服务器。由于遇到<exit>或<disconnect>元素，VoiceXML媒体服务器必须支持对从VoiceXML媒体服务器发送的BYE请求的消息体中的expr/namelist数据进行编码。VoiceXML媒体服务器可支持响应接收到的BYE请求（即，当VoiceXML应用程序响应connection.disconnect.hangup事件并随后使用指定的expr或namelist属性执行<exit>元素时），在200 OK消息的消息体中包含expr/名称列表数据。
Note that sending expr/namelist data in the 200 OK response requires that the VoiceXML Media Server delay the final response to the received BYE request until the VoiceXML application's post-disconnect final processing state terminates. This mechanism is subject to the constraint that the VoiceXML Media Server must respond before the User Agent Client's (UAC's) timer F expires (defaults to 32 seconds). Moreover, for unreliable transports, the UAC will retransmit the BYE request according to the rules of [RFC3261]. The VoiceXML Media Server SHOULD implement the recommendations of [RFC4320] regarding when to send the 100 Trying provisional response to the BYE request.
请注意，在200 OK响应中发送expr/namelist数据需要VoiceXML媒体服务器延迟对收到的BYE请求的最终响应，直到VoiceXML应用程序的断开后最终处理状态终止。此机制受到以下约束：VoiceXML媒体服务器必须在用户代理客户端（UAC）计时器F过期（默认为32秒）之前响应。此外，对于不可靠的传输，UAC将根据[RFC3261]的规则重新传输BYE请求。VoiceXML媒体服务器应实现[RFC4320]中关于何时向BYE请求发送临时响应的建议。
If a VoiceXML application executes a <disconnect> [VXML21] and then subsequently executes an <exit> with namelist information, the namelist information from the <exit> element is discarded.
如果VoiceXML应用程序执行<disconnect>[VXML21]，然后使用名称列表信息执行<exit>，则<exit>元素中的名称列表信息将被丢弃。
Namelist variables are first converted to their "JSON value"
equivalent [RFC4627] and encoded in the message body using the
application/x-www-form-urlencoded format content type [HTML4]. The
behavior resulting from specifying a recording variable in the
namelist or an ECMAScript object with circular references is not
defined. If the expr attribute is specified on the <exit> element
instead of the namelist attribute, the reserved name __exit is used.
Namelist variables are first converted to their "JSON value"
equivalent [RFC4627] and encoded in the message body using the
application/x-www-form-urlencoded format content type [HTML4]. The
behavior resulting from specifying a recording variable in the
namelist or an ECMAScript object with circular references is not
defined. If the expr attribute is specified on the <exit> element
instead of the namelist attribute, the reserved name __exit is used.
To allow the Application Server to differentiate between a BYE
resulting from a <disconnect> from one resulting from an <exit>, the
reserved name __reason is used, with a value of "disconnect" (without
brackets) to reflect the use of VoiceXML's <disconnect> element, and
a value of "exit" (without brackets) to an explicit <exit> in the
VoiceXML document. If the session terminates for other reasons (such
as the media server encountering an error), this parameter may be
omitted, or may take on platform-specific values prefixed with an
underscore.
To allow the Application Server to differentiate between a BYE
resulting from a <disconnect> from one resulting from an <exit>, the
reserved name __reason is used, with a value of "disconnect" (without
brackets) to reflect the use of VoiceXML's <disconnect> element, and
a value of "exit" (without brackets) to an explicit <exit> in the
VoiceXML document. If the session terminates for other reasons (such
as the media server encountering an error), this parameter may be
omitted, or may take on platform-specific values prefixed with an
underscore.
This specification extends the application/x-www-form-urlencoded by replacing non-ASCII characters with one or more octets of the UTF-8 representation of the character, with each octet in turn replaced by %HH, where HH represents the uppercase hexadecimal notation for the octet value and % is a literal character. As a consequence, the Content-Type header field in a BYE message containing expr/namelist data MUST be set to application/x-www-form-urlencoded;charset=utf-8.
本规范扩展了应用程序/x-www-form-urlencoded，将非ASCII字符替换为字符UTF-8表示形式的一个或多个八位字节，每个八位字节依次替换为%HH，其中HH表示八位字节值的大写十六进制表示法，%为文字字符。因此，包含expr/namelist数据的BYE消息中的内容类型头字段必须设置为application/x-www-form-urlencoded；字符集=utf-8。
The following table provides some examples of <exit> usage and the corresponding result content.
下表提供了一些<exit>用法示例和相应的结果内容。
+----------------------------------------------------------------+
|<exit> Usage | Result Content |
|------------------------------|---------------------------------|
|<exit/> | __reason=exit |
|<exit expr="5"/> | __exit=5&__reason=exit |
|<exit expr="'done'"/> | __exit="done"&__reason=exit |
|<exit expr="userAuthorized"/> | __exit=true&__reason=exit |
|<exit namelist="pin errors"/> | pin=1234&errors=0&__reason=exit |
+----------------------------------------------------------------+
assuming the following VoiceXML variables and values:
userAuthorized = true
pin = 1234
errors = 0
+----------------------------------------------------------------+
|<exit> Usage | Result Content |
|------------------------------|---------------------------------|
|<exit/> | __reason=exit |
|<exit expr="5"/> | __exit=5&__reason=exit |
|<exit expr="'done'"/> | __exit="done"&__reason=exit |
|<exit expr="userAuthorized"/> | __exit=true&__reason=exit |
|<exit namelist="pin errors"/> | pin=1234&errors=0&__reason=exit |
+----------------------------------------------------------------+
assuming the following VoiceXML variables and values:
userAuthorized = true
pin = 1234
errors = 0
For example, consider the VoiceXML snippet:
例如，考虑Voice XML片段：
... <exit namelist="id pin"/> ...
... <退出namelist=“id pin”/>。。。
If id equals 1234 and pin equals 9999, say, the BYE message would look similar to:
例如，如果id等于1234，pin等于9999，则BYE消息看起来类似于：
BYE sip:user@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: sip:dialog@example.com;tag=a6c85cf
To: sip:user@example.com;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Type: application/x-www-form-urlencoded;charset=utf-8
Content-Length: 30
BYE sip:user@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: sip:dialog@example.com;tag=a6c85cf
To: sip:user@example.com;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Type: application/x-www-form-urlencoded;charset=utf-8
Content-Length: 30
id=1234&pin=9999&__reason=exit
id=1234&pin=9999&__reason=exit
Since some applications may choose to transfer confidential information, the VoiceXML Media Server MUST support the S/MIME encoding of SIP message bodies as discussed in Section 9.
由于某些应用程序可能选择传输机密信息，VoiceXML媒体服务器必须支持SIP消息体的S/MIME编码，如第9节所述。
Outbound calls can be triggered via the Application Server using third-party call control [RFC3725].
出站呼叫可以使用第三方呼叫控制[RFC3725]通过应用服务器触发。
Flow IV from [RFC3725] is recommended in conjunction with the VoiceXML Session preparation mechanism. This flow has several advantages over others, namely:
建议将[RFC3725]中的流IV与VoiceXML会话准备机制结合使用。与其他流程相比，此流程有几个优点，即：
1. Selection of a VoiceXML Media Server and preparation of the VoiceXML application can occur before the call is placed to avoid the callee experiencing delays.
1. 在拨打电话之前，可以选择VoiceXML媒体服务器并准备VoiceXML应用程序，以避免被叫方遇到延迟。
2. Avoidance of timing difficulties that could occur with other flows due to the time taken to fetch and parse the initial VoiceXML document.
2. 避免了由于获取和解析初始VoiceXML文档所花费的时间而导致其他流可能出现的计时困难。
3. The flow is IPv6 compatible.
3. 该流与IPv6兼容。
An example flow for an Application-Server-initiated outbound call is provided in Section 2.6.2.
第2.6.2节提供了应用服务器发起的出站调用的示例流程。
While VoiceXML is at its core a dialog language, it also provides optional call transfer capability. VoiceXML's transfer capability is particularly suited to the PSTN IVR Service Node use case described in Section 1.1.2. It is NOT RECOMMENDED to use VoiceXML's call transfer capability in networks involving Application Servers. Rather, the Application Server itself can provide call routing
虽然VoiceXML的核心是一种对话语言，但它还提供可选的呼叫转移功能。VoiceXML的传输能力特别适合于第1.1.2节中描述的PSTN IVR服务节点用例。不建议在涉及应用服务器的网络中使用VoiceXML的呼叫转移功能。相反，应用服务器本身可以提供呼叫路由
functionality by taking signaling actions based on the data returned to it from the VoiceXML Media Server via HTTP or in the SIP BYE message.
通过基于通过HTTP或SIP BYE消息从VoiceXML媒体服务器返回的数据执行信令操作的功能。
If VoiceXML transfer is supported, the mechanism described in this section MUST be employed. The transfer flows specified here are selected on the basis that they provide the best interworking across a wide range of SIP devices. CCXML<->VoiceXML implementations, which require tight-coupling in the form of bidirectional eventing to support all transfer types defined in VoiceXML, may benefit from other approaches, such as the use of SIP event packages [RFC3265].
如果支持VoiceXML传输，则必须采用本节中描述的机制。这里指定的传输流是根据它们在广泛的SIP设备上提供最佳互通而选择的。CCXML<->VoiceXML实现需要以双向事件的形式紧密耦合，以支持VoiceXML中定义的所有传输类型，可以从其他方法中受益，例如使用SIP事件包[RFC3265]。
In what follows, the provisional responses have been omitted for clarity.
在下文中，为了清楚起见，省略了临时回复。
The blind-transfer sequence is initiated by the VoiceXML Media Server via a REFER message [RFC3515] on the original SIP dialog. The Refer-To header contains the URI for the called party, as specified via the dest or destexpr attributes on the VoiceXML <transfer> tag.
VoiceXML媒体服务器通过原始SIP对话框上的REFER消息[RFC3515]启动盲传输序列。Refer-Refer标头包含被调用方的URI，这是通过VoiceXML<transfer>标记上的dest或destexpr属性指定的。
If the REFER request is accepted, in which case the VoiceXML Media Server will receive a 2xx response, the VoiceXML Media Server throws the connection.disconnect.transfer event and will terminate the VoiceXML Session with a BYE message. For blind transfers, implementations MAY use [RFC4488] to suppress the implicit subscription associated with the REFER message.
如果REFER请求被接受，在这种情况下，VoiceXML媒体服务器将收到2xx响应，VoiceXML媒体服务器将抛出connection.disconnect.transfer事件，并使用BYE消息终止VoiceXML会话。对于盲传输，实现可以使用[RFC4488]来抑制与REFER消息相关联的隐式订阅。
If the REFER request results in a non-2xx response, the <transfer>'s form item variable (or event raised) depends on the SIP response and is specified in the following table. Note that this indicates that the transfer request was rejected.
如果REFER请求导致非2xx响应，<transfer>的表单项变量（或引发的事件）取决于SIP响应，并在下表中指定。请注意，这表示传输请求已被拒绝。
+-------------------------+-----------------------------------+
| SIP Response | <transfer> variable / event |
+-------------------------+-----------------------------------+
| 404 Not Found | error.connection.baddestination |
| 405 Method Not Allowed | error.unsupported.transfer.blind |
| 503 Service Unavailable | error.connection.noresource |
| (No response) | network_busy |
| (Other 3xx/4xx/5xx/6xx) | unknown |
+-------------------------+-----------------------------------+
+-------------------------+-----------------------------------+
| SIP Response | <transfer> variable / event |
+-------------------------+-----------------------------------+
| 404 Not Found | error.connection.baddestination |
| 405 Method Not Allowed | error.unsupported.transfer.blind |
| 503 Service Unavailable | error.connection.noresource |
| (No response) | network_busy |
| (Other 3xx/4xx/5xx/6xx) | unknown |
+-------------------------+-----------------------------------+
An example is illustrated below (provisional responses and NOTIFY messages corresponding to provisional responses have been omitted for clarity).
下面举例说明（为了清楚起见，省略了与临时响应相对应的临时响应和通知消息）。
User Agent 1 VoiceXML User Agent 2
(Caller) Media Server (Callee)
| | |
|(0) RTP/SRTP | |
|.................| |
| | |
|(1) REFER | <transfer> |
|<----------------| |
|(2) 202 Accepted | |
|---------------->| |
|(3) BYE | |
|<----------------| |
|(4) 200 OK | |
|---------------->| |
| | Stop RTP (0) |
|(5) INVITE |
|---------------------------------->|
|(6) 200 OK |
|<----------------------------------|
|(7) NOTIFY | |
|---------------->| |
|(8) 200 OK | |
|<--------------- | |
|(9) ACK |
|---------------------------------->|
|(10) RTP/SRTP |
|...................................|
| | |
User Agent 1 VoiceXML User Agent 2
(Caller) Media Server (Callee)
| | |
|(0) RTP/SRTP | |
|.................| |
| | |
|(1) REFER | <transfer> |
|<----------------| |
|(2) 202 Accepted | |
|---------------->| |
|(3) BYE | |
|<----------------| |
|(4) 200 OK | |
|---------------->| |
| | Stop RTP (0) |
|(5) INVITE |
|---------------------------------->|
|(6) 200 OK |
|<----------------------------------|
|(7) NOTIFY | |
|---------------->| |
|(8) 200 OK | |
|<--------------- | |
|(9) ACK |
|---------------------------------->|
|(10) RTP/SRTP |
|...................................|
| | |
If the aai or aaiexpr attribute is present on <transfer>, it is appended to the Refer-To URI as a parameter named "aai" in the REFER method. Reserved characters are URL-encoded as required for SIP/SIPS URIs [RFC3261]. The mapping of values outside of the ASCII range is platform specific.
如果aai或aaiexpr属性出现在<transfer>上，它将作为refere方法中名为“aai”的参数附加到refere-refereuri。保留字符按照SIP/SIPS URI[RFC3261]的要求进行URL编码。ASCII范围之外的值映射是特定于平台的。
The bridge transfer function results in the creation of a small multi-party session involving the Caller, the VoiceXML Media Server, and the Callee. The VoiceXML Media Server invites the Callee to the session and will eject the Callee if the transfer is terminated.
桥接传输函数导致创建一个小型多方会话，涉及调用者、VoiceXML媒体服务器和被调用者。VoiceXML媒体服务器邀请被叫方加入会话，并在传输终止时弹出被叫方。
If the aai or aaiexpr attribute is present on <transfer>, it is appended to the Request-URI in the INVITE as a URI parameter named "aai". Reserved characters are URL-encoded as required for SIP/SIPS URIs [RFC3261]. The mapping of values outside of the ASCII range is platform specific.
如果aai或aaiexpr属性出现在<transfer>上，它将作为名为“aai”的URI参数附加到INVITE中的请求URI中。保留字符按照SIP/SIPS URI[RFC3261]的要求进行URL编码。ASCII范围之外的值映射是特定于平台的。
During the transfer attempt, audio specified in the transferaudio attribute of <transfer> is streamed to User Agent 1. A VoiceXML Media Server MAY play early media received from the Callee to the Caller if the transferaudio attribute is omitted.
在传输尝试期间，在<transfer>的transferaudio属性中指定的音频流传输到用户代理1。如果省略了transferaudio属性，VoiceXML媒体服务器可以向调用者播放从被调用者接收的早期媒体。
The bridge transfer sequence is illustrated below. The VoiceXML Media Server (acting as a UAC) makes a call to User Agent 2 with the same codecs used by User Agent 1. When the call setup is complete, RTP flows between User Agent 2 and the VoiceXML Media Server. This stream is mixed with User Agent 1's.
桥接传输顺序如下所示。VoiceXML媒体服务器（充当UAC）使用用户代理1使用的相同编解码器调用用户代理2。呼叫设置完成后，RTP在用户代理2和VoiceXML媒体服务器之间流动。此流与用户代理1混合。
User Agent 1 VoiceXML User Agent 2
(Caller) Media Server (Callee)
| | |
|(0)RTP/SRTP | |
|...................| |
| | |
| <transfer>|(1)INVITE [offer] |
| |------------------>|
| |(2) 200 OK [answer]|
| |<------------------|
| |(3) ACK |
| |------------------>|
| |(4) RTP/SRTP |
| mix |...................|
| (0)+(4)| |
User Agent 1 VoiceXML User Agent 2
(Caller) Media Server (Callee)
| | |
|(0)RTP/SRTP | |
|...................| |
| | |
| <transfer>|(1)INVITE [offer] |
| |------------------>|
| |(2) 200 OK [answer]|
| |<------------------|
| |(3) ACK |
| |------------------>|
| |(4) RTP/SRTP |
| mix |...................|
| (0)+(4)| |
If a final response is not received from User Agent 2 from the INVITE and the connecttimeout expires (specified as an attribute of <transfer>), the VoiceXML Media Server will issue a CANCEL to terminate the transaction and the <transfer>'s form item variable is set to noanswer.
如果没有从用户代理2接收到来自INVITE的最终响应，并且connecttimeout过期（指定为<transfer>的属性），VoiceXML媒体服务器将发出CANCEL以终止事务，<transfer>的表单项变量设置为noanswer。
If INVITE results in a non-2xx response, the <transfer>'s form item variable (or event raised) depends on the SIP response and is specified in the following table.
如果INVITE导致非2xx响应，<transfer>的表单项变量（或引发的事件）取决于SIP响应，并在下表中指定。
+-------------------------+-----------------------------------+
| SIP Response | <transfer> variable / event |
+-------------------------+-----------------------------------+
| 404 Not Found | error.connection.baddestination |
| 405 Method Not Allowed | error.unsupported.transfer.bridge |
| 408 Request Timeout | noanswer |
| 486 Busy Here | busy |
| 503 Service Unavailable | error.connection.noresource |
| (No response) | network_busy |
| (Other 3xx/4xx/5xx/6xx) | unknown |
+-------------------------+-----------------------------------+
+-------------------------+-----------------------------------+
| SIP Response | <transfer> variable / event |
+-------------------------+-----------------------------------+
| 404 Not Found | error.connection.baddestination |
| 405 Method Not Allowed | error.unsupported.transfer.bridge |
| 408 Request Timeout | noanswer |
| 486 Busy Here | busy |
| 503 Service Unavailable | error.connection.noresource |
| (No response) | network_busy |
| (Other 3xx/4xx/5xx/6xx) | unknown |
+-------------------------+-----------------------------------+
Once the transfer is established, the VoiceXML Media Server can "listen" to the media stream from User Agent 1 to perform speech or DTMF hotword, which when matched results in a near-end disconnect, i.e., the VoiceXML Media Server issues a BYE to User Agent 2 and the VoiceXML application continues with User Agent 1. A BYE will also be issued to User Agent 2 if the call duration exceeds the maximum duration specified in the maxtime attribute on <transfer>.
一旦建立传输，VoiceXML媒体服务器可以“侦听”来自用户代理1的媒体流以执行语音或DTMF热词，匹配后会导致近端断开，即VoiceXML媒体服务器向用户代理2发出再见，VoiceXML应用程序继续使用用户代理1。如果呼叫持续时间超过<transfer>上maxtime属性中指定的最大持续时间，则还会向用户代理2发出BYE。
If User Agent 2 issues a BYE during the transfer, the transfer terminates and the VoiceXML <transfer>'s form item variable receives the value far_end_disconnect. If User Agent 1 issues a BYE during the transfer, the transfer terminates and the VoiceXML event connection.disconnect.transfer is thrown.
如果用户代理2在传输过程中发出BYE，传输将终止，VoiceXML<transfer>的表单项变量将接收值far\u end\u disconnect。如果用户代理1在传输过程中发出BYE，则传输终止，并抛出VoiceXML事件connection.disconnect.transfer。
The consultation transfer (also called attended transfer [RFC5359]) is similar to a blind transfer except that the outcome of the transfer call setup is known and the Caller is not dropped as a result of an unsuccessful transfer attempt.
协商转移（也称为有人参与转移[RFC5359]）与盲转移类似，不同之处在于转移呼叫设置的结果是已知的，并且呼叫者不会因为转移尝试失败而被丢弃。
Consultation transfer commences with the same flow as for bridge transfer except that the RTP streams are not mixed at step (4) and error.unsupported.transfer.consultation supplants error.unsupported.transfer.bridge. Assuming a new SIP dialog with User Agent 2 is created, the remainder of the sequence follows as illustrated below (provisional responses and NOTIFY messages corresponding to provisional responses have been omitted for clarity). Consultation transfer makes use of the Replaces: header [RFC3891] such that User Agent 1 calls User Agent 2 and replaces the latter's SIP dialog with the VoiceXML Media Server with a new SIP dialog between the Caller and Callee.
协商传输以与桥接传输相同的流程开始，但RTP流在步骤（4）中未混合，并且error.unsupported.transfer.Consultation替代error.unsupported.transfer.bridge。假设创建了与用户代理2的新SIP对话，序列的其余部分如下所示（为了清楚起见，省略了与临时响应相对应的临时响应和通知消息）。协商传输使用Replaces:header[RFC3891]，这样用户代理1调用用户代理2，并用VoiceXML媒体服务器替换用户代理2的SIP对话框，并在调用者和被调用者之间创建一个新的SIP对话框。
User Agent 1 VoiceXML User Agent 2
(Caller) Media Server (Callee)
| | |
|(0) RTP/SRTP | |
|.................|(4) RTP/SRTP |
| |.................|
|(5) REFER | |
|<----------------| |
|(6) 202 Accepted | |
|---------------->| |
|(7) INVITE Replaces:ms1.example.com|
|---------------------------------->|
|(8) 200 OK |
|<----------------------------------|
|(9) ACK |
|---------------------------------->|
|(10) RTP/SRTP |
|...................................|
| |(11) BYE |
| |<----------------|
| |(12) 200 OK |
| |---------------->| Stop
|(13) NOTIFY | | RTP (4)
|---------------->| |
|(14) 200 OK | |
|<----------------| |
|(15) BYE | |
|<----------------| |
|(16) 200 OK | |
|---------------->| Stop |
| | RTP (0) |
User Agent 1 VoiceXML User Agent 2
(Caller) Media Server (Callee)
| | |
|(0) RTP/SRTP | |
|.................|(4) RTP/SRTP |
| |.................|
|(5) REFER | |
|<----------------| |
|(6) 202 Accepted | |
|---------------->| |
|(7) INVITE Replaces:ms1.example.com|
|---------------------------------->|
|(8) 200 OK |
|<----------------------------------|
|(9) ACK |
|---------------------------------->|
|(10) RTP/SRTP |
|...................................|
| |(11) BYE |
| |<----------------|
| |(12) 200 OK |
| |---------------->| Stop
|(13) NOTIFY | | RTP (4)
|---------------->| |
|(14) 200 OK | |
|<----------------| |
|(15) BYE | |
|<----------------| |
|(16) 200 OK | |
|---------------->| Stop |
| | RTP (0) |
If a response other than 202 Accepted is received in response to the REFER request sent to User Agent 1, the transfer terminates and an error.unsupported.transfer.consultation event is raised. In addition, a BYE is sent to User Agent 2 to terminate the established outbound leg.
如果在响应发送给用户代理1的REFER请求时接收到除202 Accepted以外的响应，则传输将终止，并引发error.UNSUPPORED.transfer.CONSUNCTION事件。此外，向用户代理2发送BYE以终止所建立的出站分支。
The VoiceXML Media Server uses receipt of a NOTIFY message with a sipfrag message of 200 OK to determine that the consultation transfer has succeeded. When this occurs, the connection.disconnect.transfer event will be thrown to the VoiceXML application, and a BYE is sent to User Agent 1 to terminate the session. A NOTIFY message with a non-2xx final response sipfrag message body will result in the transfer terminating and the associated VoiceXML input item variable being set to 'unknown'. Note that as a consequence of this
VoiceXML媒体服务器通过接收sipfrag消息为200 OK的NOTIFY消息来确定协商传输已成功。发生这种情况时，connection.disconnect.transfer事件将抛出到VoiceXML应用程序，并向用户代理1发送BYE以终止会话。带有非2xx最终响应sipfrag消息正文的NOTIFY消息将导致传输终止，并且相关的VoiceXML输入项变量将设置为“未知”。请注意，因此
mechanism, implementations MUST NOT use [RFC4488] to suppress the implicit subscription associated with the REFER message for consultation transfers.
机制，实现不得使用[RFC4488]抑制与协商传输的REFER消息关联的隐式订阅。
The bulk of the early work for this effort was carried out on weekly teleconferences and over email. The authors would particularly like to recognize the contributions of R. J. Auburn (Voxeo), Jeff Haynie (Hakano), and Scott McGlashan (Hewlett-Packard).
这项工作早期的大部分工作是通过每周的电话会议和电子邮件进行的。作者特别想感谢R.J.奥本（Voxeo）、杰夫·海尼（Hakano）和斯科特·麦克拉珊（Hewlett-Packard）的贡献。
This document owes its genesis to, "A SIP Interface to VoiceXML Dialog Servers", authored by J. Rosenberg, P. Mataga, and D. Ladd. The following people had input to the current document:
本文档的起源归功于J.Rosenberg、P.Mataga和D.Ladd编写的“VoiceXML对话服务器的SIP接口”。以下人员对当前文档进行了输入：
R. J. Auburn (Voxeo)
R.J.奥本（Voxeo）
Hans Bjurstrom (Hewlett-Packard)
Hans Bjurstrom（惠普公司）
Emily Candell (Comverse)
艾米丽·坎德尔（康维斯）
Peter Danielsen (Lucent)
彼得·丹尼尔森（朗讯）
Brian Frasca (Tellme)
布莱恩·弗拉斯卡（Tellme）
Jeff Haynie (Hakano)
杰夫·海尼（白野）
Scott McGlashan (Hewlett-Packard)
斯科特·麦克拉山（惠普公司）
Matt Oshry (Tellme)
马特·奥什里（Tellme）
Rao Surapaneni (Tellme)
拉奥·苏拉帕内尼（泰勒姆）
The authors would like to acknowledge the support of Cullen Jennings and the Mediactrl chairs, Eric Burger and Spencer Dawkins.
作者要感谢Cullen Jennings和Mediactrl主席Eric Burger和Spencer Dawkins的支持。
Exposing a VoiceXML media service with a well-known address may enhance the possibility of exploitation (for example, an invoked network service may trigger a billing event). The VoiceXML Media Server is RECOMMENDED to use standard SIP mechanisms [RFC3261] to authenticate requesting endpoints and authorize per local policy.
公开具有已知地址的VoiceXML媒体服务可能会增加利用该服务的可能性（例如，被调用的网络服务可能会触发计费事件）。建议VoiceXML媒体服务器使用标准SIP机制[RFC3261]对请求的端点进行身份验证，并根据本地策略进行授权。
Some applications may choose to transfer confidential information to or from the VoiceXML Media Server. To provide data confidentiality, the VoiceXML Media Server MUST implement the sips: and https: schemes in addition to S/MIME message body encoding as described in [RFC3261].
某些应用程序可能会选择将机密信息传输到VoiceXML媒体服务器或从中传输机密信息。为了提供数据保密性，VoiceXML媒体服务器必须实现sips:和https:方案，以及[RFC3261]中所述的S/MIME消息体编码。
The VoiceXML Media Server MUST support Secure RTP (SRTP) [RFC3711] to provide confidentiality, authentication, and replay protection for RTP media streams (including RTCP control traffic).
VoiceXML媒体服务器必须支持安全RTP（SRTP）[RFC3711]为RTP媒体流（包括RTCP控制流量）提供机密性、身份验证和重播保护。
To mitigate the possibility of denial-of-service attacks, the VoiceXML Media Server is RECOMMENDED (in addition to authenticating and authorizing endpoints described above) to provide mechanisms for implementing local policies such as the time-limiting of VoiceXML application execution.
为了减少拒绝服务攻击的可能性，建议VoiceXML媒体服务器（除了验证和授权上述端点之外）提供实现本地策略的机制，如VoiceXML应用程序执行的时间限制。
IANA has registered the following parameters in the SIP/SIPS URI Parameters registry, following the Specification Required policy of [RFC3969]:
IANA已按照[RFC3969]的规范要求策略，在SIP/SIPS URI参数注册表中注册了以下参数：
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
maxage No RFC 5552
maxstale No RFC 5552
method "get" / "post" RFC 5552
postbody No RFC 5552
ccxml No RFC 5552
aai No RFC 5552
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
maxage No RFC 5552
maxstale No RFC 5552
method "get" / "post" RFC 5552
postbody No RFC 5552
ccxml No RFC 5552
aai No RFC 5552
[HTML4] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", W3C Recommendation, Dec 1999.
[HTML4]Raggett，D.，Le Hors，A.，和I.Jacobs，“HTML4.01规范”，W3C建议，1999年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H. Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Streams", RFC 3016, November 2000.
[RFC3016]菊口，Y.，野村，T.，福永，S.，松井，Y.，和H.Kimata，“MPEG-4音频/视频流的RTP有效载荷格式”，RFC3016，2000年11月。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[RFC3326]Schulzrinne，H.，Oran，D.，和G.Camarillo，“会话启动协议（SIP）的原因头字段”，RFC 3326，2002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725]Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的当前最佳实践”，BCP 85，RFC 37252004年4月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891]Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244]Barnes，M.，“请求历史信息会话启动协议（SIP）的扩展”，RFC 4244，2005年11月。
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, January 2006.
[RFC4320]Sparks，R.，“解决会话启动协议（SIP）非邀请事务已识别问题的措施”，RFC 4320，2006年1月。
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006.
[RFC4488]Levin，O.“会话启动协议（SIP）的抑制是指方法隐式订阅”，RFC 4488，2006年5月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4627]Crockford，D.，“JavaScript对象表示法（json）的应用程序/json媒体类型”，RFC4627，2006年7月。
[RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R. Even, "RTP Payload Format for ITU-T Rec", RFC 4629, January 2007.
[RFC4629]Ott，H.，Bormann，C.，Sullivan，G.，Wenger，S.，和R.偶，“ITU-T Rec的RTP有效载荷格式”，RFC 46292007年1月。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC4733]Schulzrinne，H.和T.Taylor，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 47332006年12月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855]Casner，S.，“RTP有效负载格式的媒体类型注册”，RFC 48552007年2月。
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, April 2007.
[RFC4867]Sjoberg，J.，Westerlund，M.，Lakaniemi，A.，和Q.Xie，“自适应多速率（AMR）和自适应多速率宽带（AMR-WB）音频编解码器的RTP有效载荷格式和文件存储格式”，RFC 4867，2007年4月。
[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.
[VXML20]McGrashan，S.，Burnett，D.，Carter，J.，Danielsen，P.，Ferrans，J.，Hunt，A.，Lucas，B.，Porter，B.，Rehor，K.，和S.Tryphonas，“语音可扩展标记语言（VoiceXML）2.0版”，W3C建议，2004年3月。
[VXML21] Oshry, M., Auburn, R J., Baggia, P., Bodell, M., Burke, D., Burnett, D., Candell, E., Kilic, H., McGlashan, S., Lee, A., Porter, B., and K. Rehor, "Voice Extensible Markup Language (VoiceXML) Version 2.1", W3C Candidate Recommendation, June 2005.
[VXML21]Oshry，M.，Auburn，R J.，Baggia，P.，Bodell，M.，Burke，D.，Burnett，D.，Candell，E.，Kilic，H.，McGlashan，S.，Lee，A.，Porter，B.，和K.Rehor，“语音可扩展标记语言（VoiceXML）版本2.1”，W3C候选推荐，2005年6月。
[CCXML10] Auburn, R J., "Voice Browser Call Control: CCXML Version 1.0", W3C Working Draft, June 2005.
[CCXML10]Auburn，R J.，“语音浏览器呼叫控制：CCXML 1.0版”，W3C工作草案，2005年6月。
[IEC14496-14] "Information technology. Coding of audio-visual objects. MP4 file format", ISO/IEC ISO/IEC 14496- 14:2003, October 2003.
[IEC14496-14]“信息技术.视听对象的编码.MP4文件格式”，ISO/IEC ISO/IEC 14496-14:2003，2003年10月。
[MRCPv2] Shanmugham, S. and D. Burnett, "Media Resource Control Protocol Version 2 (MRCPv2)", Work in Progress, November 2008.
[MRCPv2]Shanmugham，S.和D.Burnett，“媒体资源控制协议版本2（MRCPv2）”，正在进行的工作，2008年11月。
[RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 2190, September 1997.
[RFC2190]Zhu，C.“H.263视频流的RTP有效载荷格式”，RFC 21901997年9月。
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[RFC3960]Camarillo，G.和H.Schulzrinne，“会话启动协议（SIP）中的早期媒体和铃声生成”，RFC 39602004年12月。
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.
[RFC3969]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，2004年12月。
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4240]Burger，E.，Van Dyke，J.，和A.Spitzer，“具有SIP的基本网络媒体服务”，RFC 42402005年12月。
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
[RFC5359]Johnston，A.，Sparks，R.，Cunningham，C.，Donovan，S.，和K.Summers，“会话启动协议服务示例”，BCP 144，RFC 5359，2008年10月。
[TS23002] "3rd Generation Partnership Project: Network architecture (Release 6)", 3GPP TS 23.002 v6.6.0, December 2004.
[TS23002]“第三代合作伙伴关系项目：网络架构（版本6）”，3GPP TS 23.002 v6.6.0，2004年12月。
[TS26244] "Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)", 3GPP TS 26.244 v6.4.0, December 2004.
[TS26244]“透明端到端分组交换流媒体服务（PSS）；3GPP文件格式（3GP）”，3GPP TS 26.244 v6.4.0，2004年12月。
We make a "downref" normative reference to [RFC4627] -- an Informational document describing a proprietary (but extremely popular) format.
我们对[RFC4627]进行了“downref”规范性引用，这是一个描述专有（但非常流行）格式的信息性文档。
Authors' Addresses
作者地址
Dave Burke Google Belgrave House, 76 Buckingham Palace Road London SW1W 9TQ United Kingdom
Dave Burke Google Belgrave House，英国伦敦白金汉宫路76号SW1W 9TQ
EMail: daveburke@google.com
EMail: daveburke@google.com
Mark Scott Genesys 1120 Finch Avenue West, 8th floor Toronto, Ontario M3J 3H7 Canada
加拿大安大略省多伦多芬奇大道西1120号8楼MarkScott Genesys M3J 3H7
EMail: Mark.Scott@genesyslab.com
EMail: Mark.Scott@genesyslab.com