Network Working Group N. Cook
Request for Comments: 5616 Cloudmark
Category: Informational August 2009
Network Working Group N. Cook
Request for Comments: 5616 Cloudmark
Category: Informational August 2009
Streaming Internet Messaging Attachments
流式Internet消息传递附件
Abstract
摘要
This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content.
本文档描述了一种将资源和/或网络受限设备从IMAP服务器接收的多媒体附件流式传输的方法。它允许这些客户机播放视频和音频电子邮件内容，这些客户机通常在存储空间和带宽方面有限制。
The document describes a profile for making use of the URLAUTH-authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022).
本文档描述了使用URLAUTH授权IMAP URL（RFC 5092）、网络公告SIP媒体服务（RFC 4240）和媒体服务器控制标记语言（RFC 5022）的配置文件。
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
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). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview of Mechanism . . . . . . . . . . . . . . . . . . 3
3.2. Media Server Discovery . . . . . . . . . . . . . . . . . . 5
3.3. Client Use of GENURLAUTH Command . . . . . . . . . . . . . 7
3.4. Client Determination of Media Server Capabilities . . . . 9
3.5. Client Use of the Media Server Announcement Service . . . 10
3.6. Media Negotiation and Transcoding . . . . . . . . . . . . 11
3.7. Client Use of the Media Server MSCML IVR Service . . . . . 13
3.8. Media Server Use of IMAP Server . . . . . . . . . . . . . 17
3.9. Protocol Diagrams . . . . . . . . . . . . . . . . . . . . 18
3.9.1. Announcement Service Protocol Diagram . . . . . . . . 18
3.9.2. IVR Service Protocol Diagram . . . . . . . . . . . . . 19
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Digital Rights Management (DRM) Issues . . . . . . . . . . . . 24
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 24
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview of Mechanism . . . . . . . . . . . . . . . . . . 3
3.2. Media Server Discovery . . . . . . . . . . . . . . . . . . 5
3.3. Client Use of GENURLAUTH Command . . . . . . . . . . . . . 7
3.4. Client Determination of Media Server Capabilities . . . . 9
3.5. Client Use of the Media Server Announcement Service . . . 10
3.6. Media Negotiation and Transcoding . . . . . . . . . . . . 11
3.7. Client Use of the Media Server MSCML IVR Service . . . . . 13
3.8. Media Server Use of IMAP Server . . . . . . . . . . . . . 17
3.9. Protocol Diagrams . . . . . . . . . . . . . . . . . . . . 18
3.9.1. Announcement Service Protocol Diagram . . . . . . . . 18
3.9.2. IVR Service Protocol Diagram . . . . . . . . . . . . . 19
4. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6. Digital Rights Management (DRM) Issues . . . . . . . . . . . . 24
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 24
8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 28
Email clients on resource- and/or network-constrained devices, such as mobile phones, may have difficulties in retrieving and/or storing large attachments received in a message. For example, on a poor network link, the latency required to download the entire attachment before displaying any of it may not be acceptable to the user. Conversely, even on a high-speed network, the device may not have enough storage space to secure the attachment once retrieved.
资源和/或网络受限设备（如移动电话）上的电子邮件客户端在检索和/或存储邮件中接收的大型附件时可能会遇到困难。例如，在较差的网络链路上，用户可能无法接受在显示任何附件之前下载整个附件所需的延迟。相反，即使在高速网络上，设备也可能没有足够的存储空间来保护一旦检索到的附件。
For certain media, such as audio and video, there is a solution: the media can be streamed to the device, using protocols such as RTP [RTP]. Streaming can be initiated and controlled using protocols such as SIP [SIP] and particularly the media server profiles as specified in RFC 4240 [NETANN] or MSCML [MSCML]. Streaming the media to the device addresses both the latency issue, since the client can start playing the media relatively quickly, and the storage issue, since the client does not need to store the media locally. A tradeoff is that the media cannot be viewed/played when the device is offline.
对于某些媒体，如音频和视频，有一种解决方案：可以使用RTP[RTP]等协议将媒体流式传输到设备。可以使用SIP[SIP]等协议，特别是RFC 4240[NETANN]或MSCML[MSCML]中指定的媒体服务器配置文件来启动和控制流媒体。将媒体流传输到设备解决了延迟问题（因为客户端可以相对快速地开始播放媒体）和存储问题（因为客户端不需要在本地存储媒体）。折衷的办法是，当设备脱机时，无法查看/播放媒体。
Examples of the types of media that would benefit from the ability to stream to the device include:
将受益于流式传输到设备的能力的媒体类型的示例包括：
o Voice or video mail messages received as an attachment
o 作为附件接收的语音或视频邮件
o Audio clips such as ring tones received as an attachment
o 音频剪辑，如作为附件接收的铃声
o Video clips, such as movie trailers, received as an attachment
o 作为附件接收的视频剪辑，如电影预告片
The client may wish to present the user with the ability to use simple "VCR-style" controls such as pause, fast-forward, and rewind. In consideration of this, the document presents two alternatives for streaming media -- a simple mechanism that makes use of the announcement service of RFC 4240, and a more complex mechanism which allows VCR controls, based on MSCML (RFC 5022) [MSCML]. The choice of which mechanism to use is up to the client; for example, it may be based on limitations of the client or the configured media server. This document presents suggestions for determining which of these streaming services are available.
客户可能希望向用户展示使用简单“VCR风格”控件的能力，例如暂停、快进和快退。考虑到这一点，本文介绍了流媒体的两种替代方案——一种是利用RFC 4240公告服务的简单机制，另一种是基于MSCML（RFC 5022）[MSCML]允许VCR控制的更复杂机制。使用哪种机制的选择取决于客户；例如，它可能基于客户端或配置的媒体服务器的限制。本文档提供了确定哪些流媒体服务可用的建议。
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 RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then some of the line breaks between those lines are for editorial clarity only and may not be part of the actual protocol exchange.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。如果单个“C:”或“S:”标签适用于多行，则这些行之间的一些换行符仅用于编辑清晰性，可能不是实际协议交换的一部分。
The proposed mechanism for streaming media to messaging clients is a profile for making use of several existing mechanisms, namely:
建议的流媒体到消息传递客户端的机制是一种利用几种现有机制的配置文件，即：
o IMAP URLAUTH Extension [URLAUTH] - Providing the ability to generate an IMAP URL that allows access by external entities to specific message parts, e.g., an audio clip.
o IMAP URLAUTH扩展[URLAUTH]-提供生成IMAP URL的能力，允许外部实体访问特定的消息部分，例如音频片段。
o URLFETCH Binary Extension [URLFETCH_BINARY] - Providing the ability to specify BINARY and BODYPARTSTRUCTURE arguments to the URLFETCH command.
o URLFETCH二进制扩展[URLFETCH\U Binary]-提供为URLFETCH命令指定二进制和BODYPARTSTRUCTURE参数的功能。
o Media Server Announcement Service (RFC 4240) [NETANN] - Providing the ability for a media server to stream media using a reference provided by the media server client in a URL.
o 媒体服务器公告服务（RFC 4240）[NETANN]-提供媒体服务器使用媒体服务器客户端在URL中提供的引用来流媒体的能力。
o Media Server Interactive Voice Response (IVR) Service (RFC 5022) [MSCML] - Providing the ability to stream media as above, but with VCR-style controls.
o 媒体服务器交互式语音响应（IVR）服务（RFC 5022）[MSCML]-提供如上所述的流媒体功能，但具有VCR风格的控件。
The approach is shown in the following figure:
该方法如下图所示：
+--------------+
| |
| Email Client |^
| | \
+--------------+ \
^ ^ \
| \ \ (5)
| (1), \ \
| (2) \ \
| (3),\ \
| (6) \ \
| \ \
v v v
+--------------+ +----------------+
| | (4) | |
| IMAP Server |<----->| Media Server |
| | | |
+--------------+ +----------------+
+--------------+
| |
| Email Client |^
| | \
+--------------+ \
^ ^ \
| \ \ (5)
| (1), \ \
| (2) \ \
| (3),\ \
| (6) \ \
| \ \
v v v
+--------------+ +----------------+
| | (4) | |
| IMAP Server |<----->| Media Server |
| | | |
+--------------+ +----------------+
Figure 1: Proposed Mechanism
图1：拟议机制
The proposed mechanism has the following steps:
拟议的机制包括以下步骤：
(1) The client determines from MIME headers of a particular message that a particular message part (attachment) should be streamed to the user. Note that no assumptions are made about how/when/if the client contacts the user of the client about this decision. User input may be required in order to initiate the proposed mechanism.
(1) 客户端根据特定消息的MIME头确定应将特定消息部分（附件）流式传输给用户。请注意，对于客户如何/何时/是否就此决定联系客户的用户，没有做出任何假设。可能需要用户输入以启动提议的机制。
(2) The client constructs an IMAP URL referencing the message part, and uses the GENURLAUTH [URLAUTH] command to generate a URLAUTH-authorized IMAP URL.
(2) 客户端构造一个引用消息部分的IMAP URL，并使用GENURLAUTH[URLAUTH]命令生成一个URLAUTH授权的IMAP URL。
(3) The client connects to a SIP Media Server using the announcement service as specified in RFC 4240 [NETANN], or the IVR service as specified in RFC 5022 [MSCML], and passes the URLAUTH-authorized URL to the media server.
(3) 客户端使用RFC 4240[NETANN]中指定的公告服务或RFC 5022[MSCML]中指定的IVR服务连接到SIP媒体服务器，并将URLAUTH授权URL传递给媒体服务器。
(4) The media server connects to the IMAP server specified in the referenced URL, and uses the IMAP URLFETCH [URLAUTH] command to retrieve the message part.
(4) 媒体服务器连接到引用URL中指定的IMAP服务器，并使用IMAP URLFETCH[URLAUTH]命令检索消息部分。
(5) The media server streams the retrieved message part to the client using RTP [RTP].
(5) 媒体服务器使用RTP[RTP]将检索到的消息部分流式传输到客户端。
(6) The media server or the client terminates the media streaming, or the streaming ends naturally. The SIP session is terminated by either client or server.
(6) 媒体服务器或客户端终止媒体流，或流自然结束。SIP会话由客户端或服务器终止。
It should be noted that the proposed mechanism makes several assumptions about the mobile device, as well as available network services, namely:
应注意，所提议的机制对移动设备以及可用网络服务做出了若干假设，即：
o The mobile device is provisioned with, or obtains via some dynamic mechanism (see Section 3.2), the location of a media server which supports either RFC 4240 [NETANN] and/or RFC 5022 [MSCML].
o 移动设备配备或通过某种动态机制（见第3.2节）获得支持RFC 4240[NETANN]和/或RFC 5022[MSCML]的媒体服务器的位置。
o The media server(s) used by the mobile device support the IMAP URL [IMAPURL] scheme for the announcement and/or IVR services.
o 移动设备使用的媒体服务器支持用于公告和/或IVR服务的IMAP URL[IMAPURL]方案。
o The IMAP server used by the mobile device supports generating anonymous IMAP URLs using the URLAUTH mechanism as well as the IMAP URLFETCH BINARY [URLFETCH_BINARY] extension.
o 移动设备使用的IMAP服务器支持使用URLAUTH机制以及IMAP URLFETCH BINARY[URLFETCH\ U BINARY]扩展生成匿名IMAP URL。
This section discusses possibilities for the automatic discovery of suitable media servers to perform streaming operations, and provides for such a mechanism using the IMAP METADATA [METADATA] extension.
本节讨论自动发现合适的媒体服务器以执行流操作的可能性，并提供使用IMAP METADATA[元数据]扩展的这种机制。
There are two possibilities for clients with regard to determining the hostname and port number information of a suitable media server:
在确定合适媒体服务器的主机名和端口号信息方面，客户端有两种可能：
1. No discovery of media servers is required: clients are configured with suitable media server information in an out-of-band manner.
1. 不需要发现媒体服务器：客户端以带外方式配置了适当的媒体服务器信息。
2. Discovery of media servers is required: clients use a discovery mechanism to determine a suitable media server that will be used for streaming multimedia message parts.
2. 需要发现媒体服务器：客户端使用发现机制来确定将用于流媒体消息部分的合适媒体服务器。
There are several scenarios where media server discovery would be a requirement for streaming to be successful:
有几种情况下，媒体服务器发现是流媒体成功的必要条件：
o Client is not configured with the address of any media servers.
o 客户端未配置任何媒体服务器的地址。
o Client is configured with the address of one or more media servers, but the IMAP server is configured to only accept URLFETCH requests from specific media servers (for security or site policy reasons), and thus streaming would fail due to the media server not being able to retrieve the media from the IMAP server.
o 客户端配置了一个或多个媒体服务器的地址，但IMAP服务器配置为仅接受来自特定媒体服务器的URLFETCH请求（出于安全或站点策略原因），因此，由于媒体服务器无法从IMAP服务器检索媒体，流式传输将失败。
There is also a scenario where media server discovery would improve the security of the streaming mechanism, by avoiding the use of completely anonymous URLs. For example, the client could discover a media server address that was an authorized user of the IMAP server for streaming purposes, which would allow the client to generate a URL, which was secure in that it could *only* be accessed by an entity that is trusted by the IMAP server to retrieve content. The issue of trust in media servers is discussed more fully in Section 4.
还有一种情况是，通过避免使用完全匿名的URL，媒体服务器发现将提高流机制的安全性。例如，客户端可以发现一个媒体服务器地址，该地址是IMAP服务器的授权用户，用于流式传输，这将允许客户端生成一个URL，该URL是安全的，因为它*只能*被IMAP服务器信任的实体访问以检索内容。第4节将更全面地讨论媒体服务器中的信任问题。
This document describes using the IMAP METADATA [METADATA] extension, via the use of a server entry that provides the contact information for suitable media servers for use with the IMAP server. Media Server discovery is optional: clients are free to use pre-configured information about media servers, or to fall back to pre-configured information if they encounter IMAP servers that do not support either the METADATA extension or the proposed entry, or that do not provide a value for the entry.
本文档描述了通过使用服务器条目来使用IMAP METADATA[元数据]扩展，该服务器条目提供了与IMAP服务器一起使用的合适媒体服务器的联系信息。媒体服务器发现是可选的：客户端可以自由使用有关媒体服务器的预配置信息，或者在遇到不支持元数据扩展或建议的条目，或者不提供条目值的IMAP服务器时，可以退回到预配置信息。
A METADATA entry with the name of "/shared/mediaServers" is used to store the locations of suitable media servers known to the IMAP server. The entry is formatted according to the formalSyntax specified in Section 8. This consists of a tuple of a URI and optional "stream" string, where the URI is surrounded by <> symbols, the URI and "stream" are separated using a colon ":", and tuples are separated using a ";".
名为“/shared/mediaServers”的元数据条目用于存储IMAP服务器已知的适当媒体服务器的位置。根据第8节规定的formalSyntax对条目进行格式化。这包括URI的元组和可选的“流”字符串，其中URI由<>符号包围，URI和“流”使用冒号“：”分隔，元组使用“；”分隔。
The "stream" string (c.f. the "stream" access identifier from [ACCESSID]) is used to identify media servers capable of connecting to the IMAP server as users authorized to retrieve URLs constructed using the "stream" access identifier. It indicates that the client MUST create the content URI using the "stream" access identifier. See Section 3.3 for a description of how the client should make use of the access identifier when generating IMAP URLs.)
“流”字符串（c.f.[ACCESSID]中的“流”访问标识符）用于将能够连接到IMAP服务器的媒体服务器标识为有权检索使用“流”访问标识符构造的URL的用户。它指示客户端必须使用“流”访问标识符创建内容URI。有关客户端在生成IMAP URL时应如何使用访问标识符的说明，请参见第3.3节。）
Example values of the /shared/mediaServers METADATA entry (N.B. Any line-wrapping below is for the purpose of clarity):
/shared/mediaServers元数据项的示例值（注意，以下任何换行都是为了清楚起见）：
"<sip:ivr@ms.example.net:5060>:stream;<sip:annc@
ms1.example.net:5060>;<sips:ivr@ms2.example.net:5061>"
"<sip:ivr@ms.example.net:5060>:stream;<sip:annc@
ms1.example.net:5060>;<sips:ivr@ms2.example.net:5061>"
"<sip:ivr@192.0.2.40:5060>;<sip:192.0.2.41:5060>;<sips:annc@
192.0.2.42:5060>:stream"
"<sip:ivr@192.0.2.40:5060>;<sip:192.0.2.41:5060>;<sips:annc@
192.0.2.42:5060>:stream"
It should be noted that the URI specified in the ABNF (in Section 8) is generic, i.e., not restricted to SIP URIs; however, this document only specifies how to make use of SIP URIs. Additionally, the "userinfo" (known as the "service indicator" in RFC 4240 and RFC 4722) component of the URI is optional; if specified, it gives the client additional information about the media server capabilities. For example, a "userinfo" component of "annc" indicates that the media server supports RFC 4240, and "ivr" indicates support for RFC 4722. Section 3.4 further describes how clients should behave if the "userinfo" component is not present.
应该注意的是，ABNF（第8节）中指定的URI是通用的，即不限于SIP URI；但是，本文档仅指定如何使用SIPURI。此外，URI的“userinfo”（在rfc4240和rfc4722中称为“服务指示符”）组件是可选的；如果指定，它将向客户端提供有关媒体服务器功能的其他信息。例如，“annc”的“userinfo”组件表示媒体服务器支持RFC 4240，“ivr”表示支持RFC 4722。第3.4节进一步描述了在“userinfo”组件不存在的情况下客户端的行为。
Clients SHOULD parse the value of the /shared/mediaServers entry, and contact a media server using one of the returned URIs. The servers are returned in order of preference as suggested by the server; however, it is left to the client to decide if a different order is more appropriate when selecting the media server(s) to contact, as well as the selection of alternates under failure conditions.
客户端应解析/shared/mediaServers项的值，并使用返回的URI之一联系媒体服务器。按照服务器建议的优先顺序返回服务器；但是，在选择要联系的媒体服务器时，以及在故障情况下选择备用介质时，由客户机决定不同的顺序是否更合适。
Administrators configuring the values of the /shared/mediaServers entry, who do not know the capabilities of the media servers being configured, SHOULD NOT include a "userinfo" component as part of the URI. In that case, the client will determine which service to use as specified in Section 3.4. Note that if a media server supports multiple services, a URI with the appropriate userinfo component SHOULD be configured for each service.
配置/shared/mediaServers条目值的管理员不知道正在配置的媒体服务器的功能，不应将“userinfo”组件作为URI的一部分。在这种情况下，客户将根据第3.4节的规定确定使用哪种服务。请注意，如果媒体服务器支持多个服务，则应为每个服务配置具有适当userinfo组件的URI。
Note that even though the media server address can be discovered dynamically, it is assumed that the necessary security arrangements between the client and the media server already exist. For example, the media server could use SIP digest authentication to provide access only to authenticated clients; in this case, it is assumed the username and password have already been set up. Likewise, if the client wants to authenticate the media server using, e.g., TLS and certificates, it is assumed the necessary arrangements (trust anchors and so on) already exist. In some deployments, the clients and media servers may even be willing to rely on the security of the underlying network, and omit authentication between the client and the media server entirely. See Section 4 for more details.
请注意，即使可以动态发现媒体服务器地址，但假定客户端和媒体服务器之间已经存在必要的安全安排。例如，媒体服务器可以使用SIP摘要认证来仅向认证的客户端提供访问；在这种情况下，假定用户名和密码已经设置好。类似地，如果客户端希望使用例如TLS和证书来认证媒体服务器，则假定已经存在必要的安排（信任锚等）。在某些部署中，客户端和媒体服务器甚至可能愿意依赖底层网络的安全性，而完全忽略客户端和媒体服务器之间的身份验证。详见第4节。
The decision to make use of streaming services for a message part will usually be predicated on the content type of the message part. Using the capabilities of the IMAP FETCH command, clients determine the MIME [MIME] Content-Type of particular message parts, and based on local policies or heuristics, they decide whether streaming for that message part will be attempted.
消息部分使用流式服务的决定通常取决于消息部分的内容类型。使用IMAP FETCH命令的功能，客户端确定特定消息部分的MIME[MIME]内容类型，并根据本地策略或启发式方法，决定是否尝试对该消息部分进行流式传输。
Once the client has determined that a particular message part requires streaming, the client generates an IMAP URL that refers to the message part according to the method described in RFC 5092 [IMAPURL]. The client then begins the process of generating an URLAUTH URL by appending ";EXPIRE=<datetime>" and ";URLAUTH=<access>" to the initial URL.
一旦客户机确定特定消息部分需要流式传输，客户机将根据RFC 5092[IMAPURL]中描述的方法生成引用消息部分的IMAP URL。然后，客户端通过在初始URL后面附加“EXPIRE=<datetime>”和“URLAUTH=<access>”开始生成URLAUTH URL的过程。
The ";EXPIRE=<datetime>" parameter is optional; however, it SHOULD be used, since the use of anonymous URLAUTH-authorized URLs is a security risk (see Section 4), and it ensures that at some point in the future, permission to access that URL will cease. IMAP server implementors may choose to reject anonymous URLs that are considered insecure (for example, with an EXPIRE date too far in the future), as a matter of local security policy. To prevent this from causing interoperability problems, IMAP servers that implement this profile MUST NOT reject GENURLAUTH commands for anonymous URLs on the basis of the EXPIRE time, if that time is equal to, or less than, 1 hour in the future.
“EXPIRE=<datetime>”参数是可选的；但是，应该使用它，因为使用匿名URLAUTH授权URL是一种安全风险（见第4节），并且它确保在将来某个时候，访问该URL的权限将停止。IMAP服务器实现者可以根据本地安全策略选择拒绝被认为不安全的匿名URL（例如，过期日期太长）。为了防止这会导致互操作性问题，实现此配置文件的IMAP服务器不得基于过期时间拒绝匿名URL的GENURLAUTH命令（如果该时间等于或小于未来1小时）。
The <access> portion of the URLAUTH URL MUST be 'stream' (see [ACCESSID]) if an out-of-band mechanism or the media server discovery mechanism discussed in Section 3.2 specifies that the media server is an authorized user of the IMAP server for the purposes of retrieving content via URLFETCH. Without specific prior knowledge of such a configuration (either through the discovery mechanism described in this document, or by an out-of-band mechanism), the client SHOULD use the 'stream' access identifier, which will cause streaming to fail if the media server is not an authorized user of the IMAP server for the purposes of streaming.
如果带外机制或第3.2节中讨论的媒体服务器发现机制指定媒体服务器是IMAP服务器的授权用户，以便通过URLFETCH检索内容，则URLAUTH URL的<access>部分必须是“流”（请参见[ACCESSID]）。在事先不知道此类配置的情况下（通过本文档中描述的发现机制或带外机制），客户端应使用“流”访问标识符，如果媒体服务器不是IMAP服务器的授权用户，则流将失败。
However, if the client wishes to take the risk associated with generating a URL that can be used by any media server (see Section 4), it MAY use 'anonymous' as the <access> portion of the URLAUTH URL passed to the GENURLAUTH command. For example, the client may have been pre-configured with the address of media servers in the local administrative domain (thus implying a level of trust in those media servers), without knowing whether those media servers have a pre-existing trust relationship with the IMAP server to be used (which may well be in a different administrative domain). See Section 4 for a full discussion of the security issues.
但是，如果客户端希望承担与生成可由任何媒体服务器使用的URL相关的风险（参见第4节），则可以使用“匿名”作为传递给GENURLAUTH命令的URLAUTH URL的<access>部分。例如，客户机可能已经预先配置了本地管理域中媒体服务器的地址（因此意味着这些媒体服务器中的信任级别），而不知道这些媒体服务器是否与要使用的IMAP服务器（很可能位于不同的管理域）具有预先存在的信任关系. 有关安全问题的完整讨论，请参见第4节。
The client uses the URL generated as a parameter to the GENURLAUTH command, using the INTERNAL authorization mechanism. The URL returned by a successful response to this command will then be passed to the media server. If no successful response to the GENURLAUTH command is received, then no further action will be possible with respect to streaming media to the client.
客户端使用内部授权机制将生成的URL作为GENURLAUTH命令的参数。成功响应此命令返回的URL将传递给媒体服务器。如果未收到对GENURLAUTH命令的成功响应，则无法对客户端的流媒体执行进一步的操作。
Examples:
示例：
C: a122 UID FETCH 24356 (BODYSTRUCTURE)
S: * 26 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN"
S: ("CHARSET" "US-ASCII") NIL
S: NIL "7BIT" 1152 23)("VIDEO" "MPEG"
NIL NIL "BASE64" 655350)) UID 24356)
S: a122 OK FETCH completed.
C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:57-08:00;
urlauth=anonymous" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:57-08:00;
urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920"
S: a123 OK GENURLAUTH completed
C: a122 UID FETCH 24356 (BODYSTRUCTURE)
S: * 26 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN"
S: ("CHARSET" "US-ASCII") NIL
S: NIL "7BIT" 1152 23)("VIDEO" "MPEG"
NIL NIL "BASE64" 655350)) UID 24356)
S: a122 OK FETCH completed.
C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:57-08:00;
urlauth=anonymous" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:57-08:00;
urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920"
S: a123 OK GENURLAUTH completed
C: a122 UID FETCH 24359 (BODYSTRUCTURE)
S: * 27 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN"
S: ("CHARSET" "US-ASCII") NIL
S: NIL "7BIT" 1152 23)("AUDIO" "G729"
NIL NIL "BASE64" 87256)) UID 24359)
S: a122 OK FETCH completed.
C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;
section=1.3;expire=2006-12-19T16:39:57-08:00;
urlauth=stream" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;
section=1.3;expire=2006-12-20T18:31:45-08:00;
urlauth=stream:
internal:098230923409284092384092840293480239482"
S: a123 OK GENURLAUTH completed
C: a122 UID FETCH 24359 (BODYSTRUCTURE)
S: * 27 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN"
S: ("CHARSET" "US-ASCII") NIL
S: NIL "7BIT" 1152 23)("AUDIO" "G729"
NIL NIL "BASE64" 87256)) UID 24359)
S: a122 OK FETCH completed.
C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;
section=1.3;expire=2006-12-19T16:39:57-08:00;
urlauth=stream" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;
section=1.3;expire=2006-12-20T18:31:45-08:00;
urlauth=stream:
internal:098230923409284092384092840293480239482"
S: a123 OK GENURLAUTH completed
Once an authorized IMAP URL has been generated, it is up to the client to pass that URL to a suitable media server that is capable of retrieving the URL via IMAP, and streaming the content to the client using the RTP [RTP] protocol.
一旦生成了授权的IMAP URL，客户机就可以将该URL传递给合适的媒体服务器，该服务器能够通过IMAP检索URL，并使用RTP[RTP]协议将内容流式传输到客户机。
This section specifies the behavior of clients that have not determined (either statically through configuration, or dynamically through a discovery process as discussed in Section 3.2), the capabilities of the media server with respect to the services (i.e., RFC 4240 or 5022) supported by that media server. Clients that have determined those capabilities should use the mechanisms described in Sections 3.5 or 3.7, as appropriate.
本节规定了尚未确定（静态通过配置或动态通过第3.2节中讨论的发现过程）媒体服务器与该媒体服务器支持的服务（即RFC 4240或5022）相关的能力的客户端的行为。已确定这些能力的客户应酌情使用第3.5节或第3.7节中描述的机制。
If the client supports the MSCML IVR service, then it SHOULD attempt to contact the media server using the MSCML protocol by sending a SIP INVITE that has the service indicator "ivr".
如果客户端支持MSCML IVR服务，则应尝试通过发送带有服务指示符“IVR”的SIP INVITE来使用MSCML协议联系媒体服务器。
Assuming the media server responds to the INVITE without error, the client can carry on using the MSCML IVR service as specified in Section 3.7. If the media server responds with an error indicating that the "ivr" service is not supported, then if the client supports it, the client SHOULD attempt to contact the media server using the announcement service, as described in Section 3.5.
假设媒体服务器响应INVITE没有错误，客户端可以继续使用第3.7节中指定的MSCML IVR服务。如果媒体服务器响应错误，指示不支持“ivr”服务，则如果客户端支持该服务，客户端应尝试使用公告服务联系媒体服务器，如第3.5节所述。
The following example shows an example SIP INVITE using the "ivr" service indicator:
以下示例显示了使用“ivr”服务指示符的SIP INVITE示例：
C: INVITE sip:ivr@ms2.example.com SIP/2.0
< SIP Header fields omitted for reasons of brevity >
C: INVITE sip:ivr@ms2.example.com SIP/2.0
< SIP Header fields omitted for reasons of brevity >
Assuming the client or media server does not support use of the MSCML protocol, the media server announcement service is used, as described in RFC 4240 [NETANN]. This service allows the client to send a SIP INVITE to a special username ('annc') at the media server (the "announcement" user), supplying the URL obtained as per Section 3.3.
假设客户端或媒体服务器不支持使用MSCML协议，则使用媒体服务器公告服务，如RFC 4240[NETANN]中所述。此服务允许客户端向媒体服务器（“公告”用户）的特殊用户名（“annc”）发送SIP邀请，并提供根据第3.3节获得的URL。
The SIP INVITE is constructed as shown in the examples below; note that as per RFC 4240, the play parameter is mandatory and specifies the authorized IMAP URL to be played.
SIP INVITE的构造如下面的示例所示；请注意，根据RFC 4240，play参数是必需的，并指定要播放的授权IMAP URL。
Examples of valid SIP INVITE URIs sent to the media server announcement service:
发送到媒体服务器公告服务的有效SIP INVITE URI示例：
C: sip:annc@ms2.example.net;
play=imap:%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3Bsection
%3D1.2%3Bexpire%3D2006-12-19T16:39:57-08:00%3Burlauth%3Danonymous:
internal:238234982398239898a9898998798b987s87920
C: sip:annc@ms2.example.net;
play=imap:%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3Bsection
%3D1.2%3Bexpire%3D2006-12-19T16:39:57-08:00%3Burlauth%3Danonymous:
internal:238234982398239898a9898998798b987s87920
C: sip:annc@ms1.example.net;
play=imap:%2F%2Ffred@
example.com%2FINBOX%2F%3Buid%3D24359%2F%3Bsection
%3D1.3%3Bexpire%3D2006-12-20T18:31:45-08:00%3Burlauth%3Dstream:
internal:098230923409284092384092840293480239482
C: sip:annc@ms1.example.net;
play=imap:%2F%2Ffred@
example.com%2FINBOX%2F%3Buid%3D24359%2F%3Bsection
%3D1.3%3Bexpire%3D2006-12-20T18:31:45-08:00%3Burlauth%3Dstream:
internal:098230923409284092384092840293480239482
Notice that many of the characters that are used as parameters of the IMAP URI are escaped, as otherwise they would change the meaning of the enclosing SIP URI, by being regarded as SIP URI parameters instead of IMAP URL parameters.
请注意，许多用作IMAP URI参数的字符都被转义，否则它们将被视为SIP URI参数而不是IMAP URL参数，从而改变封闭SIP URI的含义。
If the client receives a 200 (OK) response, the media server has successfully retrieved the content from the IMAP server and the negotiated RTP stream will shortly begin.
如果客户端收到200（OK）响应，则媒体服务器已成功从IMAP服务器检索到内容，协商的RTP流将很快开始。
There are many possible response codes; however, a response code of 404 received from the media server indicates that the content could not be found or could not be retrieved for some reason. For example, the media server may not support the use of IMAP URLs. At this point, there are several options to the client, such as using alternate media servers, or giving up in attempting to stream the required message part.
有许多可能的响应代码；但是，从媒体服务器接收到的404响应代码表示由于某种原因无法找到或检索内容。例如，媒体服务器可能不支持使用IMAP URL。此时，客户机有几个选项，例如使用备用媒体服务器，或放弃尝试对所需消息部分进行流式传输。
This document uses standards and protocols from two traditionally separate application areas: Mobile Email (primarily IMAP) and Internet Telephony/Streaming (e.g., SIP/RTP). Since the document primarily addresses enhancing the capabilities of mobile email, it is felt worthwhile to give some examples of simple SIP/SDP exchanges and to discuss capabilities such as media negotiation (using SDP) and media transcoding.
本文档使用两个传统上独立的应用领域的标准和协议：移动电子邮件（主要是IMAP）和互联网电话/流（例如SIP/RTP）。由于本文档主要讨论增强移动电子邮件的功能，因此有必要给出一些简单SIP/SDP交换的示例，并讨论媒体协商（使用SDP）和媒体转码等功能。
In the below example, the client contacts the media server using the SIP INVITE command to contact the announcement service (see Section 3.5), advertising support for a range of audio and video codecs (using SDP [SDP]), and in response the media server advertises only a set of audio codecs. This process is identical for the IVR service, except that the IVR service does not use the SIP Request-URI to indicate the content to be played; instead, this is carried in a subsequent SIP INFO request.
在下面的示例中，客户端使用SIP INVITE命令与媒体服务器联系，以联系公告服务（参见第3.5节），宣传对一系列音频和视频编解码器的支持（使用SDP[SDP]），作为响应，媒体服务器仅宣传一组音频编解码器。该过程与IVR服务相同，只是IVR服务不使用SIP请求URI来指示要播放的内容；相反，这将在后续的SIP INFO请求中进行。
The client and server now know from the SDP session description advertised by both client and server that communication must be using the subset of audio codecs supported by both client and server (in the example SDP session description below, it is clear that the server does not support any video codecs). The media server may perform transcoding (i.e., converting between codecs) on the media received from the IMAP server in order to satisfy the codecs supported by the client. For example, the media server may downgrade the video retrieved from the IMAP server to the audio component only.
客户机和服务器现在从客户机和服务器发布的SDP会话描述中知道，通信必须使用客户机和服务器都支持的音频编解码器子集（在下面的示例SDP会话描述中，很明显服务器不支持任何视频编解码器）。媒体服务器可以对从IMAP服务器接收的媒体执行转码（即，在编解码器之间转换），以满足客户端支持的编解码器。例如，媒体服务器可以将从IMAP服务器检索的视频降级为仅音频组件。
For clients using the announcement service, the media server MUST return an error to the INVITE if it cannot find a common codec between the client, server and media, or it cannot transcode to a suitable codec. Similarly, for clients using the MSCML IVR service, the media server MUST return a suitable error response to the <playcollect> request.
对于使用公告服务的客户端，如果媒体服务器在客户端、服务器和媒体之间找不到通用编解码器，或者无法转换到合适的编解码器，则必须向INVITE返回错误。类似地，对于使用MSCML IVR服务的客户端，媒体服务器必须对<playcollect>请求返回适当的错误响应。
Example SIP INVITE and SDP Media Negotiation
SIP邀请和SDP媒体协商示例
C: INVITE sip:annc@ms2.example.com;
play=imap:%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3B
section%3D1.2%3Bexpire%3D2006-12-19T16:39:57-08:00%3Burlauth%3D
anonymous:internal:238234982398239898a9898998798b987s87920 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: NetAnn <sip:annc@ms2.example.com>
C: Call-ID: 8204589102@example.com
C: CSeq: 1 INVITE
C: Contact: <sip:UAA@192.0.2.40>
C: Content-Type: application/sdp
C: Content-Length: 481
C:
C: v=0
C: o=UserA 2890844526 2890844526 IN IP4 192.0.2.40
C: s=Session SDP
C: c=IN IP4 192.0.2.40
C: t=3034423619 0
C: m=audio 9224 RTP/AVP 0 8 3 98 101
C: a=alt:1 1 : 01BB7F04 6CBC7A28 192.0.2.40 9224
C: a=fmtp:101 0-15
C: a=rtpmap:98 ilbc/8000
C: a=rtpmap:101 telephone-event/8000
C: a=recvonly
C: m=video 9226 RTP/AVP 105 34 120
C: a=alt:1 1 : 01BCADB3 95DFFD80 192.0.2.40 9226
C: a=fmtp:105 profile=3;level=20
C: a=fmtp:34 CIF=2 QCIF=2 MAXBR=5120
C: a=rtpmap:105 h263-2000/90000
C: a=rtpmap:120 h263/90000
C: a=recvonly
C: INVITE sip:annc@ms2.example.com;
play=imap:%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3B
section%3D1.2%3Bexpire%3D2006-12-19T16:39:57-08:00%3Burlauth%3D
anonymous:internal:238234982398239898a9898998798b987s87920 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: NetAnn <sip:annc@ms2.example.com>
C: Call-ID: 8204589102@example.com
C: CSeq: 1 INVITE
C: Contact: <sip:UAA@192.0.2.40>
C: Content-Type: application/sdp
C: Content-Length: 481
C:
C: v=0
C: o=UserA 2890844526 2890844526 IN IP4 192.0.2.40
C: s=Session SDP
C: c=IN IP4 192.0.2.40
C: t=3034423619 0
C: m=audio 9224 RTP/AVP 0 8 3 98 101
C: a=alt:1 1 : 01BB7F04 6CBC7A28 192.0.2.40 9224
C: a=fmtp:101 0-15
C: a=rtpmap:98 ilbc/8000
C: a=rtpmap:101 telephone-event/8000
C: a=recvonly
C: m=video 9226 RTP/AVP 105 34 120
C: a=alt:1 1 : 01BCADB3 95DFFD80 192.0.2.40 9226
C: a=fmtp:105 profile=3;level=20
C: a=fmtp:34 CIF=2 QCIF=2 MAXBR=5120
C: a=rtpmap:105 h263-2000/90000
C: a=rtpmap:120 h263/90000
C: a=recvonly
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: NetAnn <sip:annc@ms2.example.com>
S: Call-ID: 8204589102@example.com
S: CSeq: 1 INVITE
S: Contact: <sip:netann@192.0.2.41>
S: Content-Type: application/sdp
S: Content-Length: 317
S:
S: v=0
S: o=NetAnn 2890844527 2890844527 IN IP4 192.0.2.41
S: s=Session SDP
S: c=IN IP4 192.0.2.41
S: t=3034423619 0
S: m=audio 17684 RTP/AVP 0 8 3 18 98 101
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: NetAnn <sip:annc@ms2.example.com>
S: Call-ID: 8204589102@example.com
S: CSeq: 1 INVITE
S: Contact: <sip:netann@192.0.2.41>
S: Content-Type: application/sdp
S: Content-Length: 317
S:
S: v=0
S: o=NetAnn 2890844527 2890844527 IN IP4 192.0.2.41
S: s=Session SDP
S: c=IN IP4 192.0.2.41
S: t=3034423619 0
S: m=audio 17684 RTP/AVP 0 8 3 18 98 101
S: a=rtpmap:0 PCMU/8000
S: a=rtpmap:8 PCMA/8000
S: a=rtpmap:3 GSM/8000
S: a=rtpmap:18 G729/8000
S: a=fmtp:18 annexb=no
S: a=rtpmap:98 iLBC/8000
S: a=rtpmap:101 telephone-event/8000
S: a=fmtp:101 0-16
S: a=rtpmap:0 PCMU/8000
S: a=rtpmap:8 PCMA/8000
S: a=rtpmap:3 GSM/8000
S: a=rtpmap:18 G729/8000
S: a=fmtp:18 annexb=no
S: a=rtpmap:98 iLBC/8000
S: a=rtpmap:101 telephone-event/8000
S: a=fmtp:101 0-16
C: ACK sip:netann@192.0.2.41 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: NetAnn <sip:annc@ms2.example.com>
C: Call-ID: 8204589102@example.com
C: CSeq: 1 ACK
C: Content-Length: 0
C: ACK sip:netann@192.0.2.41 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: NetAnn <sip:annc@ms2.example.com>
C: Call-ID: 8204589102@example.com
C: CSeq: 1 ACK
C: Content-Length: 0
Once the client has determined that the media server supports the IVR service, it is up to the client to generate a suitable MSCML request to initiate streaming of the required media.
一旦客户端确定媒体服务器支持IVR服务，则由客户端生成合适的MSCML请求以启动所需媒体的流式传输。
When using the IVR service, the initial SIP invite is used only to establish that the media server supports the MSCML IVR service, and to negotiate suitable media codecs. Once the initial SIP INVITE and response to that INVITE have been completed successfully, the client must generate a SIP INFO request with MSCML in the body of the request to initiate streaming.
使用IVR服务时，初始SIP invite仅用于确定媒体服务器支持MSCML IVR服务，并协商合适的媒体编解码器。一旦初始SIP INVITE和对该INVITE的响应成功完成，客户端必须在请求主体中生成一个包含MSCML的SIP INFO请求，以启动流式传输。
The <playcollect> request is used, as this allows the use of dual tone multi-frequency (DTMF) digits to control playback of the media, such as fast-forward or rewind.
使用<playcollect>请求，因为这允许使用双音多频（DTMF）数字来控制媒体的播放，例如快进或快退。
Since the <playcollect> request is used purely for its VCR-like capabilities, there is no need for the media server to perform DTMF collection. Therefore, the playcollect attributes "firstdigittimer", "interdigittimer", and "extradigittimer" SHOULD all be set to "0ms", which will have the effect of causing digit collection to cease immediately after the media has finished playing.
由于<playcollect>请求仅用于其类似VCR的功能，因此媒体服务器无需执行DTMF采集。因此，playcollect属性“firstdigittimer”、“interdigittimer”和“extradigittimer”都应设置为“0ms”，这将导致在媒体完成播放后立即停止数字采集。
The "ffkey" and "rwkey" attributes of <playcollect> are used to control fast-forward and rewind behavior, with the "skipinterval" attribute being used to control the 'speed' of these actions.
<playcollect>的“ffkey”和“rwkey”属性用于控制快进和快退行为，“skipinterval”属性用于控制这些动作的“速度”。
The <prompt> tag is used to specify the media to be played, and SHOULD have a single <audio> tag that gives the URL of the media, as per the Section 3.3. The audio-specific name of the tag is historical, as the tag can be used for video as well as audio
<prompt>标签用于指定要播放的媒体，并且应具有一个<audio>标签，根据第3.3节给出媒体的URL。标签的音频特定名称是历史的，因为标签可以用于视频和音频
content. The "stoponerror" attribute SHOULD be set to "yes", so that meaningful error messages will be returned by the media server in the event of problems such as retrieving the media from the IMAP server.
所容纳之物“StopOneError”属性应设置为“yes”，以便在出现问题（如从IMAP服务器检索媒体）时，媒体服务器将返回有意义的错误消息。
An example SIP INFO request using the <playcollect> request is shown at the end of this section.
本节末尾显示了使用<playcollect>请求的SIP信息请求示例。
It should be noted that under normal (i.e., non-error) conditions, the response to the <playcollect> request is a SIP 200 (OK) response. The media server then streams the media, and only when the media has finished playing (naturally or due to a user request) does the media server send a <playcollect> response, which includes details of the media played, such as length and any digits collected.
应当注意，在正常（即，非错误）条件下，对<playcollect>请求的响应是SIP 200（OK）响应。然后，媒体服务器对媒体进行流式传输，并且仅当媒体已完成播放（自然播放或由于用户请求）时，媒体服务器才会发送<playcollect>响应，其中包括所播放媒体的详细信息，例如长度和所收集的任何数字。
The client may suspend playback of the media at any time by either sending the DTMF escape key (specified as an attribute to the <playcollect> request) or by sending a <stop> request to the media server in a SIP INFO request. Upon receipt of the request, the media server will acknowledge it, and then cease streaming of the media, followed by a SIP INFO request containing the <playcollect> response.
客户端可通过发送DTMF转义键（指定为<playcollect>请求的属性）或通过在SIP信息请求中向媒体服务器发送<stop>请求，随时暂停媒体播放。在收到请求后，媒体服务器将确认该请求，然后停止媒体流，然后是包含<playcollect>响应的SIP INFO请求。
If the media server cannot play the media for any reason (for example, if it cannot retrieve the media from the IMAP server), streaming will not take place, and the <playcollect> response will be sent, usually with meaningful values in the <error_info> element.
如果媒体服务器因任何原因无法播放媒体（例如，如果无法从IMAP服务器检索媒体），将不会进行流式传输，并且将发送<playcollect>响应，通常在<error\u info>元素中包含有意义的值。
The following gives an example dialog between a client and media server, including a rewind request, and termination of the playback by use of the escape key. Some elements of the SIP dialog such as full SIP header fields and SDP are omitted for reasons of brevity. (The protocol diagram in Section 3.9.2 shows the high-level message flow between all the components, including the IMAP server.)
下面给出了客户机和媒体服务器之间的示例对话框，包括回放请求和使用escape键终止播放。为了简洁起见，省略了SIP对话框的一些元素，例如完整SIP头字段和SDP。（第3.9.2节中的协议图显示了所有组件（包括IMAP服务器）之间的高级消息流。）
C: INVITE sip:ivr@ms.example.com SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 1 INVITE
C: Contact: <sip:UAA@192.0.2.40>
C: Content-Type: application/sdp
C: Content-Length: XXX
C:
C: <SDP Here>
C: INVITE sip:ivr@ms.example.com SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 1 INVITE
C: Contact: <sip:UAA@192.0.2.40>
C: Content-Type: application/sdp
C: Content-Length: XXX
C:
C: <SDP Here>
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: IVR <sip:ivr@ms.example.com>
S: Call-ID: 3298420296@example.com
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: IVR <sip:ivr@ms.example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 1 INVITE
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Type: application/sdp
S: Content-Length: XXX
S:
S: <SDP Here>
S: CSeq: 1 INVITE
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Type: application/sdp
S: Content-Length: XXX
S:
S: <SDP Here>
C: ACK sip:ivr@ms.example.com SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms2.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 1 ACK
C: Content-Length: 0
C: ACK sip:ivr@ms.example.com SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms2.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 1 ACK
C: Content-Length: 0
C: INFO sip:ivr@192.0.2.41 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 2 INFO
C: Content-Type: application/mediaservercontrol+xml
C: Content-Length: 423
C:
C: <?xml version="1.0"?>
C: <MediaServerControl version="1.0">
C: <request>
C: <playcollect id="332985001"
C: firstdigittimer="0ms" interdigittimer="0ms" extradigittimer="0ms"
C: skipinterval="6s" ffkey="6" rwkey="4" escape="*">
C: <prompt stoponerror="yes"
C: locale="en_US" offset="0" gain="0" rate="0"
C: delay="0" duration="infinite" repeat="0">
C: <audio url="imap://joe@example.com/INBOX/;uid=24356/;section=1.2;
expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920"/>
C: </prompt>
C: </playcollect>
C: </request>
C: </MediaServerControl>
C: INFO sip:ivr@192.0.2.41 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 2 INFO
C: Content-Type: application/mediaservercontrol+xml
C: Content-Length: 423
C:
C: <?xml version="1.0"?>
C: <MediaServerControl version="1.0">
C: <request>
C: <playcollect id="332985001"
C: firstdigittimer="0ms" interdigittimer="0ms" extradigittimer="0ms"
C: skipinterval="6s" ffkey="6" rwkey="4" escape="*">
C: <prompt stoponerror="yes"
C: locale="en_US" offset="0" gain="0" rate="0"
C: delay="0" duration="infinite" repeat="0">
C: <audio url="imap://joe@example.com/INBOX/;uid=24356/;section=1.2;
expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920"/>
C: </prompt>
C: </playcollect>
C: </request>
C: </MediaServerControl>
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: IVR <sip:ivr@ms.example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 2 INFO
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Length: 0
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: IVR <sip:ivr@ms.example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 2 INFO
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Length: 0
S: <Media server retrieves media from IMAP server and streams to client>
S:<媒体服务器从IMAP服务器检索媒体并流到客户端>
C: <Client streams 6 key>
C: <Client streams 6 key>
S: <Media Server fast forwards media by 6 seconds>
S: <Media Server fast forwards media by 6 seconds>
C: <Client streams * key>
C: <Client streams * key>
S: <Media Server stops streaming>
S: <Media Server stops streaming>
S: INFO sip:UAA@192.0.2.40 SIP/2.0
S: From: IVR <sip:ivr@ms.example.com>
S: To: UserA <sip:UAA@example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 5 INFO
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Type: application/mediaservercontrol+xml
S: Content-Length: XXX
S:
S: <?xml version="1.0"?>
S: <MediaServerControl version="1.0">
S: <response id="332985001" request="playcollect" code="200"
S: reason="escapekey" playduration="34s"
S: playoffset="34s" digits="" />
S: </MediaServerControl>
S: INFO sip:UAA@192.0.2.40 SIP/2.0
S: From: IVR <sip:ivr@ms.example.com>
S: To: UserA <sip:UAA@example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 5 INFO
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Type: application/mediaservercontrol+xml
S: Content-Length: XXX
S:
S: <?xml version="1.0"?>
S: <MediaServerControl version="1.0">
S: <response id="332985001" request="playcollect" code="200"
S: reason="escapekey" playduration="34s"
S: playoffset="34s" digits="" />
S: </MediaServerControl>
C: SIP/2.0 200 OK
C: From: IVR <sip:ivr@ms.example.com>
C: To: UserA <sip:UAA@example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 5 INFO
C: Content-Length: 0
C: SIP/2.0 200 OK
C: From: IVR <sip:ivr@ms.example.com>
C: To: UserA <sip:UAA@example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 5 INFO
C: Content-Length: 0
C: BYE sip:ivr@192.0.2.41 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 6 BYE
C: Content-Length: 0
C: BYE sip:ivr@192.0.2.41 SIP/2.0
C: From: UserA <sip:UAA@example.com>
C: To: IVR <sip:ivr@ms.example.com>
C: Call-ID: 3298420296@example.com
C: CSeq: 6 BYE
C: Content-Length: 0
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: IVR <sip:ivr@ms.example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 6 BYE
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Length: 0
S: SIP/2.0 200 OK
S: From: UserA <sip:UAA@example.com>
S: To: IVR <sip:ivr@ms.example.com>
S: Call-ID: 3298420296@example.com
S: CSeq: 6 BYE
S: Contact: <sip:ivr@192.0.2.41>
S: Content-Length: 0
This section describes how the media server converts the IMAP URL received via the announcement or IVR service into suitable IMAP commands for retrieving the content.
本节介绍媒体服务器如何将通过公告或IVR服务接收的IMAP URL转换为适当的IMAP命令以检索内容。
The media server first connects to the IMAP server specified in the URL. Once connected, the media server SHOULD use TLS [TLS] to encrypt the communication path.
媒体服务器首先连接到URL中指定的IMAP服务器。连接后，媒体服务器应使用TLS[TLS]加密通信路径。
If the media server has a user identity on the IMAP server, the media server SHOULD authenticate itself to the IMAP server using the media server's user identity.
如果媒体服务器在IMAP服务器上具有用户标识，则媒体服务器应使用媒体服务器的用户标识向IMAP服务器进行身份验证。
If the media server is not configured as an authorized user of the IMAP server, then the behavior specified in IMAP URL [IMAPURL] MUST be followed. That is, if the server advertises AUTH=ANONYMOUS IMAP capability, the media server MUST use the AUTHENTICATE command with the ANONYMOUS [ANONYMOUS] SASL mechanism. If SASL ANONYMOUS is not available, the username "anonymous" is used with the "LOGIN" command and the password is supplied as the Internet email address of the administrative contact for the media server.
如果媒体服务器未配置为IMAP服务器的授权用户，则必须遵循IMAP URL[IMAPURL]中指定的行为。也就是说，如果服务器播发AUTH=ANONYMOUS IMAP功能，则媒体服务器必须使用带有ANONYMOUS[ANONYMOUS]SASL机制的AUTHENTICATE命令。如果SASL ANONYMOUS不可用，用户名“ANONYMOUS”将与“LOGIN”命令一起使用，密码将作为媒体服务器管理联系人的Internet电子邮件地址提供。
Once authenticated, the media server issues the URLFETCH command, using the URL supplied in the 'play' parameter of the SIP INVITE (or audio tag of the MSCML). If the IMAP server does not advertise URLAUTH=BINARY in its post-authentication capability string, then the media server returns a suitable error code to the client.
经过身份验证后，媒体服务器使用SIP INVITE（或MSCML的音频标记）的“播放”参数中提供的URL发出URLFETCH命令。如果IMAP服务器未在其身份验证后功能字符串中公布URLAUTH=BINARY，则媒体服务器将向客户端返回适当的错误代码。
The additional parameters to the URLFETCH command specified in (URLFETCH BINARY) [URLFETCH_BINARY] are used by the media server to tell the IMAP server to remove any transfer encoding and return the content type of the media (as content-type information is not contained in the IMAP URL).
媒体服务器使用（URLFETCH BINARY）[URLFETCH_BINARY]中指定的URLFETCH命令的附加参数通知IMAP服务器删除任何传输编码并返回媒体的内容类型（因为IMAP URL中不包含内容类型信息）。
A successful URLFETCH command will return the message part containing the media to be streamed. If the URLFETCH was unsuccessful, then the media server MUST return an appropriate error response to the client.
成功的URLFETCH命令将返回包含要流媒体的消息部分。如果URLFETCH失败，则媒体服务器必须向客户端返回适当的错误响应。
Assuming the content is retrieved successfully, the media server returns a 200 (OK) response code to the client. After an ACK is received, an RTP stream is delivered to the client using the parameters negotiated in the SDP.
假设内容检索成功，媒体服务器将向客户端返回200（确定）响应代码。在接收到ACK之后，使用SDP中协商的参数将RTP流传送到客户端。
If appropriate, the media server MAY choose to implement connection caching, in which case, connection and disconnection from the IMAP server are handled according to whatever algorithm the media server chooses. For example, the media server may know, a priori, that it
如果合适，媒体服务器可以选择实现连接缓存，在这种情况下，根据媒体服务器选择的任何算法处理与IMAP服务器的连接和断开。例如，媒体服务器可能事先知道它
will always access the same IMAP server using the same login credentials with an access pattern that would benefit from connection caching, without unduly impacting server resources.
将始终使用相同的登录凭据访问相同的IMAP服务器，访问模式将受益于连接缓存，而不会过度影响服务器资源。
Examples:
示例：
C: a001 LOGIN anonymous null
S: a001 OK LOGIN completed.
C: a002 URLFETCH
("imap://joe@example.com/INBOX/;uid=24356/;section=1.2;
expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920" BODYPARTSTRUCTURE
BINARY)
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920"
(BODYPARTSTRUCTURE ("VIDEO" "MPEG" () NIL NIL "BINARY" 655350))
(BINARY ~{655350}
S: [ ~655350 octets of binary data, containing NUL octets ])
S: a002 OK URLFETCH completed.
C: a003 LOGOUT
S: a003 OK LOGOUT completed.
C: a001 LOGIN anonymous null
S: a001 OK LOGIN completed.
C: a002 URLFETCH
("imap://joe@example.com/INBOX/;uid=24356/;section=1.2;
expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920" BODYPARTSTRUCTURE
BINARY)
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=24356/;
section=1.2;expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
internal:238234982398239898a9898998798b987s87920"
(BODYPARTSTRUCTURE ("VIDEO" "MPEG" () NIL NIL "BINARY" 655350))
(BINARY ~{655350}
S: [ ~655350 octets of binary data, containing NUL octets ])
S: a002 OK URLFETCH completed.
C: a003 LOGOUT
S: a003 OK LOGOUT completed.
This section gives examples of using the mechanism described in the document to stream media from a media server to a client, fetching the content from an IMAP server. In all of the examples, the IMAP, SIP, and RTP protocols use the line styles "-", "=", and "+", respectively.
本节给出了使用文档中描述的机制将媒体从媒体服务器流式传输到客户机、从IMAP服务器获取内容的示例。在所有示例中，IMAP、SIP和RTP协议分别使用线样式“-”、“=”和“+”。
The following diagram shows the protocol interactions between the email client, the IMAP server, and the media server when the client uses the announcement service.
下图显示了当客户端使用公告服务时，电子邮件客户端、IMAP服务器和媒体服务器之间的协议交互。
Client IMAP Server Media Server
| FETCH (BODYSTRUCTURE) | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| GENURLAUTH | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| | |
| SIP INVITE |
|===========================================================>|
| | |
| | URLFETCH |
| |<-----------------------------|
| | OK |
| |----------------------------->|
| | |
| 200 OK |
|<===========================================================|
| ACK |
|===========================================================>|
| | |
| Stream Message Part (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| BYE |
|<===========================================================|
| 200 OK |
|===========================================================>|
Client IMAP Server Media Server
| FETCH (BODYSTRUCTURE) | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| GENURLAUTH | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| | |
| SIP INVITE |
|===========================================================>|
| | |
| | URLFETCH |
| |<-----------------------------|
| | OK |
| |----------------------------->|
| | |
| 200 OK |
|<===========================================================|
| ACK |
|===========================================================>|
| | |
| Stream Message Part (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| BYE |
|<===========================================================|
| 200 OK |
|===========================================================>|
The following diagram shows a simplified view of the protocol interactions between the email client, the IMAP server, and the media server when the client uses the MSCML IVR service.
下图显示了当客户端使用MSCML IVR服务时，电子邮件客户端、IMAP服务器和媒体服务器之间协议交互的简化视图。
Client IMAP Server Media Server
| FETCH (BODYSTRUCTURE) | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| GENURLAUTH | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| | |
| SIP INVITE |
|===========================================================>|
| | |
| 200 OK |
|<===========================================================|
| ACK |
|===========================================================>|
| | |
| SIP INFO (playcollect) |
|===========================================================>|
| | |
| 200 OK |
|<===========================================================|
| | |
| | URLFETCH |
| |<-----------------------------|
| | OK |
| |----------------------------->|
| | |
| Stream Message Part (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| SIP INFO (e.g., DTMF ff) |
|===========================================================>|
| 200 OK |
|<===========================================================|
| | |
| Continue streaming (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| (Streaming Ends or is terminated) |
| | |
| SIP INFO (playcollect response) |
|<===========================================================|
| BYE |
|===========================================================>|
| 200 OK |
|<===========================================================|
Client IMAP Server Media Server
| FETCH (BODYSTRUCTURE) | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| GENURLAUTH | |
|---------------------------->| |
| OK | |
|<----------------------------| |
| | |
| SIP INVITE |
|===========================================================>|
| | |
| 200 OK |
|<===========================================================|
| ACK |
|===========================================================>|
| | |
| SIP INFO (playcollect) |
|===========================================================>|
| | |
| 200 OK |
|<===========================================================|
| | |
| | URLFETCH |
| |<-----------------------------|
| | OK |
| |----------------------------->|
| | |
| Stream Message Part (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| SIP INFO (e.g., DTMF ff) |
|===========================================================>|
| 200 OK |
|<===========================================================|
| | |
| Continue streaming (RTP) |
|<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
| | |
| (Streaming Ends or is terminated) |
| | |
| SIP INFO (playcollect response) |
|<===========================================================|
| BYE |
|===========================================================>|
| 200 OK |
|<===========================================================|
This document proposes the use of URLAUTH [URLAUTH] "pawn tickets", received over IMAP [IMAP], and transmitted over SIP [SIP], possibly within the MSCML payload of RFC 5022 [MSCML], in order to stream media received in messages. As such, the security considerations in all these documents apply to this specification.
本文件建议使用URLAUTH[URLAUTH]“典当票”，通过IMAP[IMAP]接收，并通过SIP[SIP]传输，可能在RFC 5022[MSCML]的MSCML有效载荷内，以便流式传输消息中接收的媒体。因此，所有这些文件中的安全注意事项适用于本规范。
In summary, as the authorized URLs may grant access to data, implementors of this specification need to consider the following with respect to the security implications of using IMAP URLs:
综上所述，当授权URL可以授予对数据的访问时，本规范的实现者需要考虑以下关于使用IMAP URL的安全含义：
o Use of an anonymous pawn ticket grants access to any client of the IMAP server without requiring any authentication credentials. The security mechanisms referenced above (with the caveats specified below) SHOULD be used to prevent unauthorized access to the pawn ticket.
o 使用匿名典当票据可授予对IMAP服务器的任何客户端的访问权限，而无需任何身份验证凭据。应使用上文提及的安全机制（以及下文规定的注意事项）防止未经授权访问当票。
o Use of pawn tickets that contain the "stream" access identifier restricts access to the content to those entities that are authorized users of the IMAP server for the purposes of streaming retrieved content. Use of such pawn tickets is thus desirable and so implementors should consult Section 3.3, which describes when such pawn tickets should be used.
o 使用包含“流”访问标识符的典当票证会将内容访问限制在那些作为IMAP服务器授权用户的实体上，以便对检索到的内容进行流式传输。因此，使用此类当票是可取的，因此实施者应参考第3.3节，该节描述了何时应使用此类当票。
o If the announcement service is used to set up streaming, then RFC 4240 [NETANN] specifies that the pawn ticket is passed in the Request-URI, and so untrusted third parties may be able to intercept the pawn ticket. The SIP communication channel MAY be secured by using SIPS URIs [SIP], which would provide hop-by-hop TLS encryption.
o 如果使用公告服务设置流，则RFC 4240[NETANN]指定在请求URI中传递当票，因此不受信任的第三方可能能够拦截当票。SIP通信信道可以通过使用SIPS URI[SIP]来保护，SIP URI[SIP]将提供逐跳TLS加密。
o If the IVR service (RFC 5022 [MSCML]) is used to set up and control streaming, then MSCML is used to carry the pawn ticket in the body of the request, and so untrusted third parties may be able to intercept the pawn ticket. This MAY be secured by using SIPS URIs [SIP], which would provide hop-by-hop TLS encryption.
o 如果IVR服务（RFC 5022[MSCML]）用于设置和控制流，则MSCML用于在请求主体中携带当票，因此不受信任的第三方可能能够拦截当票。这可以通过使用SIPS URI[SIP]来保护，SIP将提供逐跳TLS加密。
o Using SIPS URIs in the above situations protects the pawn ticket from third parties; however, it still allows proxies access to the pawn ticket, which could result in misuse by malicious proxies; see note below.
o 在上述情况下使用SIPS URI可保护当票不受第三方影响；但是，它仍然允许代理访问当票，这可能导致恶意代理滥用；见下文注释。
This document describes a mechanism that makes use of two separate servers to achieve the goal of streaming the content desired by the client. A major security implication of this is that the media server and IMAP server may well be located in separate administrative domains. This leads us to consider the security implications of a
本文档描述了一种机制，该机制使用两个独立的服务器来实现对客户端所需内容进行流式传输的目标。这样做的一个主要安全含义是，媒体服务器和IMAP服务器可能位于不同的管理域中。这使我们考虑了A的安全含义。
three-way protocol exchange, and the potential trust model implicit in that tripartite relationship. The security implications of the individual protocols have already been referenced; therefore, this section describes the security considerations specific to the three-way data exchange, as follows:
三方协议交换，以及三方关系中隐含的潜在信任模型。各个协议的安全含义已经被提及；因此，本节描述了特定于三方数据交换的安全注意事项，如下所示：
o The client grants the media server full access to the potentially private media content specified by the IMAP URL. As a result, the client is responsible for verifying the authenticity of the media server to a degree it finds acceptable for the content (we can refer to this process as determining the "trust" that the client has in a particular media server). The security mechanisms provided by SIP [SIP] and RTP [RTP] may be used for this purpose, as well as out of band mechanisms such as pre-configuration.
o 客户端授予媒体服务器对IMAP URL指定的潜在私有媒体内容的完全访问权。因此，客户机负责验证媒体服务器的真实性，以达到其认为内容可接受的程度（我们可以将此过程称为确定客户机对特定媒体服务器的“信任”）。SIP[SIP]和RTP[RTP]提供的安全机制可用于此目的，以及带外机制，例如预配置。
o However, since the media server will retrieve content from an IMAP server on the user's behalf, the issue of security between the IMAP server and the media server also needs to be considered. A client has no way of determining (programatically at least) the security of the exchanges between the media server and the IMAP server. However, it can determine, using the "stream" token that is part of the media server discovery mechanism described in Section 3.2, that the media server has a pre-existing authentication relationship with the IMAP server for the purposes of retrieving content using IMAP URLs. The IMAP server administrator may put prerequisites on media server administrator before this relationship can be established, for example, to guarantee the security of the communication between the media server and the IMAP server.
o 但是，由于媒体服务器将代表用户从IMAP服务器检索内容，因此还需要考虑IMAP服务器和媒体服务器之间的安全问题。客户端无法确定（至少在编程上）媒体服务器和IMAP服务器之间交换的安全性。但是，它可以使用第3.2节中描述的媒体服务器发现机制的一部分“流”令牌来确定媒体服务器与IMAP服务器具有预先存在的身份验证关系，以便使用IMAP URL检索内容。IMAP服务器管理员可以在建立此关系之前在media server administrator上设置先决条件，例如，以确保媒体服务器和IMAP服务器之间通信的安全性。
o The above two security considerations will influence the decision the client makes with regards to generation of the pawn ticket that is subsequently passed to the media server. This document mandates the use of URLs protected with the "stream" access identifier where the client knows in advance that the "stream" authentication relationship between media server and IMAP server exists. However, it does allow the use of anonymous pawn tickets where the possibility exists that use of "stream" would cause streaming to fail.
o 上述两个安全考虑因素将影响客户端在生成随后传递给媒体服务器的当票方面所做的决定。本文档强制使用受“流”访问标识符保护的URL，其中客户端提前知道媒体服务器和IMAP服务器之间存在“流”身份验证关系。但是，如果使用“流”可能导致流失败，则它允许使用匿名典当票。
o There exists the possibility of several types of attack by a malicious media server, SIP proxy, or other network elements even against pawn tickets protected with the "stream" access identifier. All of these attacks allow access to the RTP stream, if not the original content. These attacks include:
o 恶意媒体服务器、SIP代理或其他网络元素甚至可能对受“流”访问标识符保护的典当票进行多种类型的攻击。所有这些攻击都允许访问RTP流（如果不是原始内容的话）。这些攻击包括：
* The client contacts a malicious media server, MS1, that then proxies the streaming request to a second media server, MS2, that it has determined or guessed to have "stream" authorization credentials with the IMAP server specified in the pawn ticket. The media server can then redirect the streamed RTP traffic elsewhere.
* 客户端联系恶意媒体服务器MS1，然后将流式传输请求代理给第二个媒体服务器MS2，该服务器已确定或猜测具有与当票中指定的IMAP服务器的“流”授权凭据。然后，媒体服务器可以将流式RTP流量重定向到其他位置。
* Any proxy on the path between the client and the media server has access to the client's message in cleartext. In this case, a malicious proxy could perform a man-in-the-middle attack and could change the message to redirect RTP traffic elsewhere.
* 客户端和媒体服务器之间路径上的任何代理都可以访问明文形式的客户端消息。在这种情况下，恶意代理可能执行中间人攻击，并可能更改消息以将RTP通信重定向到其他位置。
* Any network element that is able to "see" the traffic between the client and the media server (or between any two proxies) can capture the pawn ticket, and then reissue a request using that pawn ticket to the same media server. Again the streamed traffic can be redirected to any desired location.
* 任何能够“查看”客户机和媒体服务器（或任何两个代理之间）之间通信量的网元都可以捕获当票，然后使用该当票向同一媒体服务器重新发出请求。同样，流式流量可以重定向到任何所需位置。
Media servers handling streaming requests will be making use of pawn-ticket URLs for the period of time required to process the streaming request, after which the URL will be forgotten. However, media servers may log the URLs received from clients, in which case, the private data contained in the IMAP server could be accessed by a malicious or curious media server administrator. Even URLs protected with EXPIRE may be accessed within the period of expiry. Therefore, media servers SHOULD remove or anonymize the internal portion of the IMAP URL when logging that URL.
处理流媒体请求的媒体服务器将在处理流媒体请求所需的时间段内使用当票URL，之后URL将被遗忘。但是，媒体服务器可能会记录从客户端接收到的URL，在这种情况下，恶意或好奇的媒体服务器管理员可能会访问IMAP服务器中包含的私有数据。即使使用EXPIRE保护的URL也可以在过期期间访问。因此，在记录IMAP URL时，媒体服务器应删除该URL的内部部分或使其匿名。
Additionally, many of the security considerations in the Message Submission BURL Extension apply to this document, particularly around the use of pawn tickets and prearranged trust relationships such as those described above.
此外，Message Submission BURL扩展中的许多安全注意事项适用于本文档，特别是关于典当票的使用和预先安排的信任关系，如上文所述。
Message parts that are encrypted using mechanisms such as S/MIME [SMIME] are designed to prevent third parties from accessing the data, thus media servers will not be able to fulfill streaming requests for messages parts that are encrypted.
使用S/MIME[SMIME]等机制加密的消息部分旨在防止第三方访问数据，因此媒体服务器将无法满足对加密消息部分的流式请求。
IANA has registered the following [METADATA] server entry to be used for media server discovery, using the [METADATA] registry.
IANA已使用[METADATA]注册表注册了用于媒体服务器发现的以下[METADATA]服务器项。
To: iana@iana.org
致：iana@iana.org
Subject: IMAP METADATA Entry Registration
主题：IMAP元数据条目注册
Type: Server
类型：服务器
Name: /shared/mediaServers
Name: /shared/mediaServers
Description: Defines a set of URIs containing the locations of suitable media servers for streaming multimedia content
描述：定义一组URI，其中包含用于流媒体内容的合适媒体服务器的位置
Content-type: text/plain; charset=utf-8
Content-type: text/plain; charset=utf-8
Contact: neil.cook@noware.co.uk
联系人：尼尔。cook@noware.co.uk
This document does not specify any Digital Rights Management (DRM) mechanisms for controlling access to and copying of the media to be streamed. This is intentional. A reference to a piece of media content is created using the URLAUTH [URLAUTH] command; thus, any DRM required should be implemented within the media itself, as implementing checks within URLAUTH could affect any use of the URLAUTH command, such as the BURL [BURL] command for message submission.
本文档未指定任何数字版权管理（DRM）机制来控制对要流媒体的访问和复制。这是故意的。使用URLAUTH[URLAUTH]命令创建对媒体内容的引用；因此，所需的任何DRM都应该在媒体本身中实现，因为在URLAUTH中实现检查可能会影响URLAUTH命令的任何使用，例如用于消息提交的BURL[BURL]命令。
The use of URLAUTH in this specification is believed to be pursuant with, and used only for, the execution of those rights to be expected when media is sent via traditional internet messaging, and causes no duplication of media content that is not essentially provided by the action of sending the message. In other words, the use of the content for downloading and viewing *is* implicitly granted by the sender of the message, in as much as the sender has the right to grant such rights.
在本规范中使用URLAUTH被认为是符合并且仅用于执行通过传统互联网消息发送媒体时预期的那些权利，并且不会导致媒体内容的复制，而这些媒体内容基本上不是通过发送消息的行为提供的。换言之，使用内容进行下载和查看*是*由消息的发送者隐式授予的，只要发送者有权授予此类权利。
The document author believes that if DRM is a requirement for Internet messaging, then a suitable DRM mechanism should be created. How such a mechanism would work is outside the scope of this document.
文档作者认为，如果DRM是Internet消息传递的一个要求，那么应该创建一个合适的DRM机制。这一机制如何运作超出了本文件的范围。
This document assumes an Internet deployment where there are no network restrictions between the different components. Specifically, it does not address issues that can occur when network policies restrict the communication between different components, especially between the media server and the IMAP server, and between the client the media server. In particular, RFC 5022 states that "It is
本文档假设在不同组件之间没有网络限制的Internet部署。具体而言，它没有解决网络策略限制不同组件之间的通信时可能出现的问题，特别是媒体服务器和IMAP服务器之间以及客户端和媒体服务器之间的通信。具体而言，RFC 5022声明“它是
unlikely, but not prohibited, for end-user SIP UACs to have a direct signaling relationship with a media server". This caveat makes it likely that firewalls and other network security mechanisms will be configured to block direct end-user access to media servers.
最终用户SIP UAC与媒体服务器之间不太可能存在直接信令关系，但并非禁止这种情况”。此警告可能会导致防火墙和其他网络安全机制被配置为阻止最终用户直接访问媒体服务器。
In order for either of the streaming mechanisms described in this document to work, local administrators MUST relax firewall policies such that appropriate SIP UACs (user agent clients) running on mobile devices are permitted to access the media servers directly using the SIP protocol. The detail of how the restrictions are relaxed (for example, only allowing clients connecting from the network space owned/maintained by the operator of the media server) is a matter of local policy, and so is outside the scope of this document.
为了使本文档中描述的任一流机制能够工作，本地管理员必须放松防火墙策略，以便允许在移动设备上运行的适当SIP UAC（用户代理客户端）使用SIP协议直接访问媒体服务器。如何放宽限制的细节（例如，仅允许客户端从媒体服务器运营商拥有/维护的网络空间连接）是本地政策的问题，因此不在本文档的范围内。
The following syntax specification for the mediaServers METADATA entry value uses the Augmented Backus-Naur Form (ABNF) notation as specified in RFC 5234 [ABNF] and the "absolute-URI" definition from RFC 3986 [RFC3986].
以下mediaServers元数据条目值的语法规范使用RFC 5234[ABNF]中指定的扩展Backus Naur Form（ABNF）表示法和RFC 3986[RFC3986]中的“绝对URI”定义。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅为编辑目的。实现必须以不区分大小写的方式接受这些字符串。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2009 IETF信托基金和被确定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
在满足以下条件的情况下，允许以源代码和二进制格式重新分发和使用，无论是否修改：
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- 源代码的重新分发必须保留上述版权声明、此条件列表和以下免责声明。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- 以二进制形式重新分发时，必须在分发时提供的文档和/或其他材料中复制上述版权声明、本条件列表和以下免责声明。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- 未经事先书面许可，不得使用互联网协会、IETF或IETF Trust的名称或特定贡献者的名称来认可或推广源自本软件的产品。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
本软件由版权所有者和贡献者提供，仅限于对适销性和适用性的默示保证
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
不承认有特定目的。在任何情况下，版权所有人或贡献者均不对任何直接、间接、偶然、特殊、惩戒性或后果性损害（包括但不限于替代商品或服务的采购；使用、数据或利润的损失；或业务中断）负责，无论是在合同中还是在任何责任理论下，严格责任，或因使用本软件而产生的侵权行为（包括疏忽或其他），即使告知可能发生此类损害。
media-servers = ms-tuple *(";" ms-tuple)
ms-tuple = "<" absolute-URI ">" [":" "stream"]
media-servers = ms-tuple *(";" ms-tuple)
ms-tuple = "<" absolute-URI ">" [":" "stream"]
Eric Burger (eburger@standardstrack.com) provided the initial inspiration for this document, along with advice and support on aspects of the media server IVR and announcement services, as well as help with the IETF process.
埃里克汉堡(eburger@standardstrack.com)提供了本文档的初始灵感，以及媒体服务器IVR和公告服务方面的建议和支持，以及IETF流程方面的帮助。
Many people made helpful comments on the document, including Alexey Melnikov, Dave Cridland, Martijn Koster, and a variety of folks in the LEMONADE and SIPPING WGs.
许多人对这份文件发表了有益的评论，包括阿列克谢·梅尔尼科夫、戴夫·克里德兰、玛蒂恩·科斯特，以及许多喝柠檬水和喝WGs的人。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[ACCESSID] Cook, N., "Internet Message Access Protocol (IMAP) - URL Access Identifier Extension", RFC 5593, June 2009.
[ACCESSID]Cook，N.，“互联网消息访问协议（IMAP）-URL访问标识符扩展”，RFC 55932009年6月。
[ANONYMOUS] Zeilenga, K., "Anonymous Simple Authentication and Security Layer (SASL) Mechanism", RFC 4505, June 2006.
[匿名]Zeilenga，K.，“匿名简单身份验证和安全层（SASL）机制”，RFC 45052006年6月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[IMAPURL] Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme", RFC 5092, October 2007.
[IMAPURL]Melnikov，A.，Ed.和C.Newman，“IMAP URL方案”，RFC 5092，2007年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[METADATA] Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009.
[元数据]Daboo，C.，“IMAP元数据扩展”，RFC 54642009年2月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME)", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）”，RFC 20451996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
Freed，N.和J.Klensin，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 4289，2005年12月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[MSCML] Van Dyke, J., Burger, E., Ed., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 5022, September 2007.
[MSCML]Van Dyke，J.，Burger，E.，Ed.，和A.Spitzer，“媒体服务器控制标记语言（MSCML）和协议”，RFC 5022，2007年9月。
[NETANN] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[NETANN]Burger，E.，Van Dyke，J.，和A.Spitzer，“具有SIP的基本网络媒体服务”，RFC 42402005年12月。
[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月。
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RTP]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[SDP]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[SIP] 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.
[SIP]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[URLAUTH]Crispin，M.，“互联网消息访问协议（IMAP）-URLAUTH扩展”，RFC 4467，2006年5月。
[URLFETCH_BINARY] Cridland, D., "Extended URLFETCH for Binary and Converted Parts", RFC 5524, May 2009.
[URLFETCH_BINARY]Cridland，D.，“二进制和转换部件的扩展URLFETCH”，RFC 5524，2009年5月。
[BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[BURL]Newman，C.，“消息提交BURL扩展”，RFC 4468，2006年5月。
[SMIME] Ramsdell, B., Ed., ""Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification"", RFC 3851, July 2004.
[SMIME]Ramsdell，B.，Ed.“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
Author's Address
作者地址
Neil L Cook Cloudmark
尼尔·库克·克劳马克
EMail: neil.cook@noware.co.uk
EMail: neil.cook@noware.co.uk