Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 6086 Ericsson
Obsoletes: 2976 E. Burger
Category: Standards Track Georgetown University
ISSN: 2070-1721 H. Kaplan
Acme Packet
January 2011
Session Initiation Protocol (SIP) INFO Method and Package Framework
会话发起协议（SIP）INFO 方法与包框架
Abstract 摘要
This document defines a method, INFO, for the Session Initiation Protocol (SIP), and an Info Package mechanism. This document obsoletes RFC 2976. For backward compatibility, this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document.
本文件定义了用于会话发起协议（SIP）的 INFO 方法及信息包机制。本文件取代了 RFC 2976。为了向后兼容，本文件还规定了与 RFC 2976 中先前定义的用法兼容的 INFO 方法的“传统”使用模式，在本文中称为“传统 INFO 用法”。
Status of This Memo
本备忘录的状态
This is an Internet Standards Track document.
这是一份互联网标准跟踪文档。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产物。它代表了 IETF 社区的共识。该文件已接受公众审查，并已获互联网工程指导小组（IESG）批准发布。有关互联网标准的更多信息，请参见 RFC 5741 的第 2 节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6086.
有关本文档的当前状态、勘误以及如何提供反馈的信息，可从以下网址获取：http://www.rfc-editor.org/info/rfc6086。
Copyright Notice 版权声明
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF 信托及被认定为文档作者的人员。保留所有权利。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受 BCP 78 以及 IETF 信托关于 IETF 文件的法律条款（http://trustee.ietf.org/license-info）约束，这些条款自本文件发布之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包含信托法律条款第 4.e 节所述的简化 BSD 许可证文本，并按简化 BSD 许可证所述提供，不附带任何保证。
Table of Contents 目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Motivation ......................................................4
3. Applicability and Backward Compatibility ........................5
4. The INFO Method .................................................6
4.1. General ....................................................6
4.2. INFO Request ...............................................6
4.2.1. INFO Request Sender .................................6
4.2.2. INFO Request Receiver ...............................7
4.2.3. SIP Proxies .........................................8
4.3. INFO Message Body ..........................................8
4.3.1. INFO Request Message Body ...........................8
4.3.2. INFO Response Message Body ..........................9
4.4. Order of Delivery ..........................................9
5. Info Packages ...................................................9
5.1. General ....................................................9
5.2. User Agent Behavior .......................................10
5.2.1. General ............................................10
5.2.2. UA Procedures ......................................10
5.2.3. Recv-Info Header Field Rules .......................11
5.2.4. Info Package Fallback Rules ........................12
5.3. REGISTER Processing .......................................12
6. Formal INFO Method Definition ..................................13
6.1. INFO Method ...............................................13
7. INFO Header Fields .............................................15
7.1. General ...................................................15
7.2. Info-Package Header Field .................................15
7.3. Recv-Info Header Field ....................................16
8. Info Package Considerations ....................................16
8.1. General ...................................................16
8.2. Appropriateness of Info Package Usage .....................16
8.3. INFO Request Rate and Volume ..............................16
8.4. Alternative Mechanisms ....................................17
8.4.1. Alternative SIP Signaling Plane Mechanisms .........17
8.4.2. Media Plane Mechanisms .............................18
8.4.3. Non-SIP-Related Mechanisms .........................19
9. Syntax .........................................................19
9.1. General ...................................................19
9.2. ABNF ......................................................19
10. Info Package Requirements .....................................20
10.1. General ..................................................20
10.2. Overall Description ......................................20
10.3. Applicability ............................................20
10.4. Info Package Name ........................................21
10.5. Info Package Parameters ..................................21
10.6. SIP Option-Tags ..........................................22
10.7. INFO Message Body Parts ..................................22
10.8. Info Package Usage Restrictions ..........................22
10.9. Rate of INFO Requests ....................................23
10.10. Info Package Security Considerations ....................23
10.11. Implementation Details ..................................23
10.12. Examples ................................................24
11. IANA Considerations ...........................................24
11.1. Update to Registration of SIP INFO Method ................24
11.2. Registration of the Info-Package Header Field ............24
11.3. Registration of the Recv-Info Header Field ...............24
11.4. Creation of the Info Packages Registry ...................25
11.5. Registration of the Info-Package Content-Disposition .....25
11.6. SIP Response Code 469 Registration .......................26
12. Examples ......................................................26
12.1. Indication of Willingness to Receive INFO Requests
for Info Packages ........................................26
12.1.1. Initial INVITE Request ............................26
12.1.2. Target Refresh ....................................27
12.2. INFO Request Associated with Info Package ................28
12.2.1. Single Payload ....................................28
12.2.2. Multipart INFO ....................................28
13. Security Considerations .......................................30
14. References ....................................................31
14.1. Normative References .....................................31
14.2. Informative References ...................................32
Appendix A. Acknowledgements .....................................35
This document defines a method, INFO, for the Session Initiation Protocol (SIP) [RFC3261].
本文件定义了一种方法，即 INFO，用于会话发起协议（SIP）[RFC3261]。
The purpose of the INFO message is to carry application level information between endpoints, using the SIP dialog signaling path. Note that the INFO method is not used to update characteristics of a SIP dialog or session, but to allow the applications that use the SIP session to exchange information (which might update the state of those applications).
INFO 消息的目的是在端点之间通过 SIP 对话信令路径传递应用层信息。需要注意的是，INFO 方法不用于更新 SIP 对话或会话的特性，而是允许使用 SIP 会话的应用程序交换信息（这可能会更新这些应用程序的状态）。
Use of the INFO method does not constitute a separate dialog usage. INFO messages are always part of, and share the fate of, an invite dialog usage [RFC5057]. INFO messages cannot be sent as part of other dialog usages, or outside an existing dialog.
使用 INFO 方法并不构成独立的对话使用。INFO 消息始终是邀请对话使用的一部分，并与其共享命运[RFC5057]。INFO 消息不能作为其他对话使用的一部分发送，也不能在现有对话之外发送。
This document also defines an Info Package mechanism. An Info Package specification defines the content and semantics of the information carried in an INFO message associated with the Info Package. The Info Package mechanism also provides a way for user
本文件还定义了一种信息包机制。信息包规范定义了与信息包相关的 INFO 消息所携带内容和语义。信息包机制还为用户提供了一种方式。
agents (UAs) to indicate for which Info Packages they are willing to receive INFO requests, and which Info Package a specific INFO request is associated with.
代理（UAs）用于指示他们愿意接收 INFO 请求的信息包，以及特定 INFO 请求所关联的信息包。
A UA uses the Recv-Info header field, on a per-dialog basis, to indicate for which Info Packages it is willing to receive INFO requests. A UA can indicate an initial set of Info Packages during dialog establishment and can indicate a new set during the lifetime of the invite dialog usage.
UA 在每个对话基础上使用 Recv-Info 头字段，来指示它愿意接收哪些信息包的 INFO 请求。UA 可以在对话建立期间指示初始的信息包集合，并在邀请对话使用期间指示新的集合。
NOTE: A UA can use an empty Recv-Info header field (a header field without a value) to indicate that it is not willing to receive INFO requests for any Info Package, while still informing other UAs that it supports the Info Package mechanism.
注意：用户代理（UA）可以使用空的 Recv-Info 头字段（即无值的头字段）来表明其不愿意接收任何信息包的 INFO 请求，同时仍告知其他用户代理它支持信息包机制。
When a UA sends an INFO request, it uses the Info-Package header field to indicate which Info Package is associated with the request. One particular INFO request can only be associated with a single Info Package.
当用户代理（UA）发送一个 INFO 请求时，它会使用 Info-Package 头字段来指明与该请求相关联的信息包。一个特定的 INFO 请求只能与一个信息包相关联。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“需要”、“应”、“不应”、“应该”、“不应该”、“建议”、“可以”和“可选”应按照 RFC 2119 [RFC2119]中的描述进行解释。
A number of applications, standardized and proprietary, make use of the INFO method as it was previously defined in RFC 2976 [RFC2976], here referred to as "legacy INFO usage". These include but are not limited to the following:
许多应用程序，包括标准化的和专有的，都采用了 INFO 方法，该方法在 RFC 2976 [RFC2976]中先前有所定义，在此称为“传统 INFO 使用”。这些应用包括但不限于以下几种：
o RFC 3372 [RFC3372] specifies the encapsulation of ISDN User Part (ISUP) in SIP message bodies. ITU-T and the Third Generation Partnership Project (3GPP) have specified similar procedures.
RFC 3372 [RFC3372] 规定了在 SIP 消息体中封装 ISDN 用户部分（ISUP）的方法。国际电信联盟电信标准化部门（ITU-T）和第三代合作伙伴计划（3GPP）也制定了类似的流程。
o [ECMA-355] specifies the encapsulation of "QSIG" in SIP message bodies.
o [ECMA-355] 规定了在 SIP 消息体中封装“QSIG”的方法。
o RFC 5022 [RFC5022] specifies how INFO is used as a transport mechanism by the Media Server Control Markup Language (MSCML) protocol. MSCML uses an option-tag in the Require header field to ensure that the receiver understands the INFO content.
RFC 5022 [RFC5022] 规定了媒体服务器控制标记语言（MSCML）协议如何使用 INFO 作为传输机制。MSCML 通过在 Require 头字段中使用 option-tag 来确保接收方理解 INFO 内容。
o RFC 5707 [RFC5707] specifies how INFO is used as a transport mechanism by the Media Server Markup Language (MSML) protocol.
RFC 5707 [RFC5707] 规定了媒体服务器标记语言（MSML）协议如何使用 INFO 作为传输机制。
o Companies have been using INFO messages in order to request fast video update. Currently, a standardized mechanism, based on the Real-time Transport Control Protocol (RTCP), has been specified in RFC 5168 [RFC5168].
公司一直使用 INFO 消息来请求快速视频更新。目前，基于实时传输控制协议（RTCP）的标准化机制已在 RFC 5168 [RFC5168]中得到规定。
o Companies have been using INFO messages in order to transport Dual-Tone Multi-Frequency (DTMF) tones. All mechanisms are proprietary and have not been standardized.
公司一直使用 INFO 消息来传输双音多频（DTMF）音调。所有机制均为专有，尚未标准化。
Some legacy INFO usages are also recognized as being shortcuts to more appropriate and flexible mechanisms.
一些传统的 INFO 用法也被视为是更合适和灵活机制的快捷方式。
Furthermore, RFC 2976 did not define mechanisms that would enable a SIP UA to indicate (1) the types of applications and contexts in which the UA supports the INFO method or (2) the types of applications and contexts with which a specific INFO message is associated.
此外，RFC 2976 并未定义机制，使 SIP 用户代理（UA）能够指明（1）UA 支持 INFO 方法的应用类型和上下文，或（2）特定 INFO 消息所关联的应用类型和上下文。
Because legacy INFO usages do not have associated Info Packages, it is not possible to use the Recv-Info and Info-Package header fields with legacy INFO usages. That is, a UA cannot use the Recv-Info header field to indicate for which legacy INFO usages it is willing to receive INFO requests, and a UA cannot use the Info-Package header field to indicate with which legacy INFO usage an INFO request is associated.
由于传统的 INFO 用法没有关联的信息包，因此无法将 Recv-Info 和 Info-Package 头字段用于传统的 INFO 用法。也就是说，用户代理（UA）不能使用 Recv-Info 头字段来指示它愿意接收哪些传统 INFO 用法的 INFO 请求，并且 UA 不能使用 Info-Package 头字段来指示某个 INFO 请求与哪个传统 INFO 用法相关联。
Due to the problems described above, legacy INFO usages often require static configuration to indicate the types of applications and contexts for which the UAs support the INFO method, and the way they handle application information transported in INFO messages. This has caused interoperability problems in the industry.
由于上述问题，传统的 INFO 用法通常需要静态配置来指明 UA 支持 INFO 方法的应用类型和上下文，以及它们处理 INFO 消息中传输的应用信息的方式。这导致了行业内的互操作性问题。
To overcome these problems, the SIP Working Group has spent significant discussion time over many years coming to agreement on whether it was more appropriate to fix INFO (by defining a registration mechanism for the ways in which it was used) or to deprecate it altogether (with the usage described in RFC 3398 [RFC3398] being grandfathered as the sole legitimate usage). Although it required substantial consensus building and concessions by those more inclined to completely deprecate INFO, the eventual direction of the working group was to publish a framework for registration of Info Packages as defined in this specification.
为解决这些问题，SIP 工作组在过去多年中投入大量讨论时间，以达成共识：是更适宜通过定义使用方式的注册机制来修复 INFO，还是彻底弃用它（其中 RFC 3398 [RFC3398]描述的使用方式作为唯一合法的遗留使用）。尽管需要建立广泛的共识并做出让步，特别是那些倾向于完全弃用 INFO 的成员，但工作组最终的方向是发布本规范中定义的 Info 包注册框架。
This document defines a method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. This document obsoletes RFC 2976 [RFC2976]. For backward compatibility,
本文件定义了一种用于会话发起协议（SIP）[RFC3261]的方法——INFO，以及一个信息包机制。本文件取代了 RFC 2976 [RFC2976]。为了向后兼容，
this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, here referred to as "legacy INFO Usage".
本文件还规定了 INFO 方法的“传统”使用模式，该模式与之前在 RFC 2976 中定义的使用方式兼容，此处称为“传统 INFO 使用”。
For backward compatibility purposes, this document does not deprecate legacy INFO usages, and does not mandate users to define Info Packages for such usages. However:
为了向后兼容，本文档并未废弃传统的 INFO 用法，也未强制要求用户为此类用法定义信息包。然而：
1. A UA MUST NOT insert an Info-Package header field in a legacy INFO request (as described in Section 4.2.1, an INFO request associated with an Info Package always contains an Info-Package header field).
1. UA 不得在传统 INFO 请求中插入 Info-Package 头字段（如第 4.2.1 节所述，与信息包关联的 INFO 请求始终包含 Info-Package 头字段）。
2. Any new usage MUST use the Info Package mechanism defined in this specification, since it does not share the issues associated with legacy INFO usage, and since Info Packages can be registered with IANA.
2. 任何新用途必须采用本规范中定义的信息包机制，因为它不共享与传统 INFO 使用相关的问题，并且信息包可以向 IANA 注册。
3. UAs are allowed to enable both legacy INFO usages and Info Package usages as part of the same invite dialog usage, but UAs SHALL NOT mix legacy INFO usages and Info Package usages in order to transport the same application level information. If possible, UAs SHALL prefer the usage of an Info Package.
3. 用户代理允许在同一邀请对话中启用传统 INFO 用法和信息包用法，但用户代理不得混合使用传统 INFO 用法和信息包用法来传输相同的应用层信息。如果可能，用户代理应优先使用信息包。
The INFO method provides a mechanism for transporting application level information that can further enhance a SIP application. Section 8 gives more details on the types of applications for which the use of INFO is appropriate.
INFO 方法提供了一种传输应用层信息的机制，可进一步增强 SIP 应用的功能。第 8 节详细介绍了适合使用 INFO 的应用类型。
This section describes how a UA handles INFO requests and responses, as well as the message bodies included in INFO messages.
本节描述了用户代理（UA）如何处理 INFO 请求和响应，以及 INFO 消息中包含的消息体。
An INFO request can be associated with an Info Package (see Section 5), or associated with a legacy INFO usage (see Section 2).
INFO 请求可以与信息包相关联（参见第 5 节），或者与传统 INFO 用法相关联（参见第 2 节）。
The construction of the INFO request is the same as any other non-target refresh request within an existing invite dialog usage as described in Section 12.2 of RFC 3261.
INFO 请求的构建与 RFC 3261 第 12.2 节所述的现有邀请对话使用中的任何其他非目标刷新请求相同。
When a UA sends an INFO request associated with an Info Package, it MUST include an Info-Package header field that indicates which Info Package is associated with the request. A specific INFO request can be used only for a single Info Package.
当用户代理（UA）发送与信息包相关的 INFO 请求时，必须包含一个 Info-Package 头域，以指明该请求关联的是哪个信息包。特定的 INFO 请求仅能用于单一的信息包。
When a UA sends an INFO request associated with a legacy INFO usage, there is no Info Package associated with the request, and the UA MUST NOT include an Info-Package header field in the request.
当用户代理（UA）发送与传统 INFO 用法相关的 INFO 请求时，该请求没有关联的信息包（Info Package），因此用户代理不得在请求中包含 Info-Package 头字段。
The INFO request MUST NOT contain a Recv-Info header field. A UA can only indicate a set of Info Packages for which it is willing to receive INFO requests by using the SIP methods (and their responses) listed in Section 5.
INFO 请求不得包含 Recv-Info 头字段。用户代理只能通过使用第 5 节中列出的 SIP 方法（及其响应）来表明它愿意接收 INFO 请求的一组信息包。
A UA MUST NOT send an INFO request outside an invite dialog usage and MUST NOT send an INFO request for an Info Package inside an invite dialog usage if the remote UA has not indicated willingness to receive that Info Package within that dialog.
UA 不得在邀请对话使用范围之外发送 INFO 请求，并且如果远程 UA 未在该对话中表明愿意接收该信息包，则不得在邀请对话使用范围内为该信息包发送 INFO 请求。
If a UA receives a 469 (Bad Info Package) response to an INFO request, based on RFC 5057 [RFC5057], the response represents a Transaction Only failure, and the UA MUST NOT terminate the invite dialog usage.
如果用户代理（UA）在发送 INFO 请求后收到 469（错误信息包）响应，根据 RFC 5057 的规定，该响应表示仅事务失败，用户代理不得终止邀请对话的使用。
Due to the possibility of forking, the UA that sends the initial INVITE request MUST be prepared to receive INFO requests from multiple remote UAs during the early dialog phase. In addition, the UA MUST be prepared to receive different Recv-Info header field values from different remote UAs.
由于存在分支的可能性，发送初始 INVITE 请求的用户代理（UA）必须准备好在接受早期对话阶段从多个远程 UA 接收 INFO 请求。此外，UA 必须准备好从不同的远程 UA 接收不同的 Recv-Info 头字段值。
NOTE: If the User Agent Server (UAS) (receiver of the initial INVITE request) sends an INFO request just after it has sent the response that creates the dialog, the UAS needs to be prepared for the possibility that the INFO request will reach the User Agent Client (UAC) before the dialog-creating response, and might therefore be rejected by the UAC. In addition, an INFO request might be rejected due to a race condition, if a UA sends the INFO request at the same time that the remote UA sends a new set of Info Packages for which it is willing to receive INFO requests.
注意：如果用户代理服务器（UAS，即初始 INVITE 请求的接收者）在发送创建对话的响应后立即发送 INFO 请求，UAS 需准备好应对 INFO 请求可能先于对话创建响应到达用户代理客户端（UAC）的情况，从而导致 UAC 拒绝该 INFO 请求。此外，若两个用户代理同时发送 INFO 请求，且远程 UA 恰好发送了一组新的信息包，表示愿意接收 INFO 请求，此时可能因竞态条件导致 INFO 请求被拒绝。
If a UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 (Bad Info Package) response (see Section 11.6), which contains a Recv-Info header field with Info Packages for which the UA is willing
如果用户代理（UA）收到一个与其未表示接收意愿的信息包相关的 INFO 请求，该 UA 必须发送一个 469（错误信息包）响应（参见第 11.6 节），其中包含一个 Recv-Info 头域，列出该 UA 愿意接收的信息包。
to receive INFO requests. The UA MUST NOT use the response to update the set of Info Packages, but simply to indicate the current set. In the terminology of multiple dialog usages [RFC5057], this represents a Transaction Only failure, and does not terminate the invite dialog usage.
接收 INFO 请求。用户代理不得利用响应来更新信息包集合，而仅用于指示当前集合。在多对话使用的术语中[RFC5057]，这代表仅事务失败，并不终止邀请对话使用。
If a UA receives an INFO request associated with an Info Package, and the message body part with Content-Disposition "Info-Package" (see Section 4.3.1) has a Multipurpose Internet Mail Extensions (MIME) type that the UA supports but not in the context of that Info Package, it is RECOMMENDED that the UA send a 415 (Unsupported Media Type) response.
如果用户代理（UA）收到与信息包相关的 INFO 请求，并且具有 Content-Disposition 为“Info-Package”的消息体部分（参见第 4.3.1 节）的 MIME 类型是 UA 支持的，但不在该信息包的上下文中，建议 UA 发送 415（不支持的媒体类型）响应。
The UA MAY send other error responses, such as Request Failure (4xx), Server Failure (5xx), and Global Failure (6xx), in accordance with the error-handling procedures defined in RFC 3261.
UA 可根据 RFC 3261 中定义的错误处理程序，发送其他错误响应，如请求失败（4xx）、服务器失败（5xx）和全局失败（6xx）。
Otherwise, if the INFO request is syntactically correct and well structured, the UA MUST send a 200 (OK) response.
否则，如果 INFO 请求在语法上正确且结构良好，用户代理必须发送 200（OK）响应。
NOTE: If the application needs to reject the information that it received in an INFO request, that needs to be done on the application level. That is, the application needs to trigger a new INFO request, which contains information that the previously received application data was not accepted. Individual Info Package specifications need to describe the details for such procedures.
注意：如果应用程序需要拒绝在 INFO 请求中收到的信息，这需要在应用程序层面进行处理。也就是说，应用程序需要触发一个新的 INFO 请求，其中包含之前接收到的应用程序数据未被接受的信息。各个信息包规范需要详细描述此类程序的细节。
Proxies need no additional behavior beyond that described in RFC 3261 to support INFO.
代理服务器无需在 RFC 3261 描述的行为之外增加额外行为来支持 INFO 方法。
The purpose of the INFO request is to carry application level information between SIP UAs. The application information data is carried in the payload of the message body of the INFO request.
INFO 请求的目的是在 SIP 用户代理之间传递应用层信息。应用信息数据承载在 INFO 请求消息体的负载中。
NOTE: An INFO request associated with an Info Package can also include information associated with the Info Package using Info-Package header field parameters.
注意：与信息包相关的 INFO 请求还可以通过信息包头字段参数包含与该信息包相关的信息。
If an INFO request associated with an Info Package contains a message body part, the body part is identified by a Content-Disposition header field "Info-Package" value. The body part can contain a single MIME type, or it can be a multipart [RFC5621] that contains other body parts associated with the Info Package.
如果与信息包相关的 INFO 请求包含消息体部分，该体部分由 Content-Disposition 头字段中的"Info-Package"值标识。该体部分可以包含单一的 MIME 类型，或者它可以是一个包含与信息包相关其他体部分的多部分结构[RFC5621]。
UAs MUST support multipart body parts in accordance with RFC 5621.
用户代理必须按照 RFC 5621 的规定支持多部分主体部分。
NOTE: An INFO request can also contain other body parts that are meaningful within the context of an invite dialog usage but are not specifically associated with the INFO method and the application concerned.
注意：INFO 请求还可以包含在邀请对话上下文中具有意义的其他主体部分，但这些部分并不特定于 INFO 方法或相关应用程序。
When a UA supports a specific Info Package, the UA MUST also support message body MIME types in accordance with that Info Package. However, in accordance with RFC 3261, the UA still indicates the supported MIME types using the Accept header.
当用户代理（UA）支持特定信息包时，UA 必须也按照该信息包的要求支持消息体 MIME 类型。然而，根据 RFC 3261 的规定，UA 仍需通过 Accept 头字段来表明其支持的 MIME 类型。
A UA MUST NOT include a message body associated with an Info Package in an INFO response. Message bodies associated with Info Packages MUST only be sent in INFO requests.
UA 不得在 INFO 响应中包含与信息包相关的消息体。与信息包相关的消息体必须仅在 INFO 请求中发送。
A UA MAY include a message body that is not associated with an Info Package in an INFO response.
UA 可以在 INFO 响应中包含一个与信息包无关的消息体。
The Info Package mechanism does not define a delivery order mechanism. Info Packages can rely on the CSeq header field [RFC3261] to detect if an INFO request is received out of order.
信息包机制并未定义传递顺序机制。信息包可依赖 CSeq 头字段[RFC3261]来检测 INFO 请求是否被无序接收。
If specific applications need additional mechanisms for order of delivery, those mechanisms, and related procedures, are specified as part of the associated Info Package (e.g., the use of sequence numbers within the application data).
如果特定应用需要额外的机制来确保交付顺序，这些机制及其相关程序将作为关联信息包的一部分进行规定（例如，在应用数据中使用序列号）。
An Info Package specification defines the content and semantics of the information carried in an INFO message associated with an Info Package. The Info Package mechanism provides a way for UAs to indicate for which Info Packages they are willing to receive INFO requests, and with which Info Package a specific INFO request is associated.
信息包规范定义了与信息包相关的 INFO 消息中所携带内容和语义。信息包机制为 UA 提供了一种方式，用于表明它们愿意接收哪些信息包的 INFO 请求，并指明特定 INFO 请求与哪个信息包相关联。
This section describes how a UA handles Info Packages, how a UA uses the Recv-Info header field, and how the UA acts in re-INVITE rollback situations.
本节介绍用户代理（UA）如何处理信息包，如何使用 Recv-Info 头域，以及在 re-INVITE 回滚情况下的 UA 行为。
A UA that supports the Info Package mechanism MUST indicate, using the Recv-Info header field, the set of Info Packages for which it is willing to receive INFO requests for a specific session. A UA can list multiple Info Packages in a single Recv-Info header field, and the UA can use multiple Recv-Info header fields. A UA can use an empty Recv-Info header field, i.e., a header field without any header field values.
支持信息包机制的用户代理（UA）必须使用 Recv-Info 头字段指示，对于特定会话，它愿意接收哪些信息包的 INFO 请求。UA 可以在单个 Recv-Info 头字段中列出多个信息包，并且可以使用多个 Recv-Info 头字段。UA 还可以使用空的 Recv-Info 头字段，即没有任何头字段值的头字段。
A UA provides its set of Info Packages for which it is willing to receive INFO requests during the dialog establishment. A UA can update the set of Info Packages during the invite dialog usage.
UA 提供一组信息包，它愿意在对话建立期间接收 INFO 请求。UA 可以在邀请对话使用过程中更新信息包集合。
If a UA is not willing to receive INFO requests for any Info Packages, during dialog establishment or later during the invite dialog usage, the UA MUST indicate this by including an empty Recv-Info header field. This informs other UAs that the UA still supports the Info Package mechanism.
如果用户代理（UA）不愿意接收任何信息包（Info Package）的 INFO 请求，无论是在会话建立期间还是后续在邀请会话使用过程中，UA 必须通过包含一个空的 Recv-Info 头字段来表明这一点。这通知其他 UA，该 UA 仍然支持信息包机制。
Example: If a UA has previously indicated Info Packages "foo" and "bar" in a Recv-Info header field, and the UA during the lifetime of the invite dialog usage wants to indicate that it does not want to receive INFO requests for any Info Packages anymore, the UA sends a message with an empty Recv-Info header field.
示例：如果 UA 先前在 Recv-Info 头字段中指定了信息包“foo”和“bar”，并且在邀请对话使用期间，UA 希望表明不再希望接收任何信息包的 INFO 请求，则 UA 会发送一个带有空 Recv-Info 头字段的消息。
Once a UA has sent a message with a Recv-Info header field containing a set of Info Packages, the set is valid until the UA sends a new Recv-Info header field containing a new, or empty, set of Info Packages.
一旦用户代理（UA）发送了一条包含一组信息包的 Recv-Info 头字段的消息，该组信息包在 UA 发送包含新的或空的信息包集合的新 Recv-Info 头字段之前一直有效。
Once a UA has indicated that it is willing to receive INFO requests for a specific Info Package, and a dialog has been established, the UA MUST be prepared to receive INFO requests associated with that Info Package until the UA indicates that it is no longer willing to receive INFO requests associated with that Info Package.
一旦用户代理（UA）表明愿意接收针对特定信息包的 INFO 请求，并且会话已建立，UA 必须准备好接收与该信息包相关的 INFO 请求，直到 UA 表明不再愿意接收与该信息包相关的 INFO 请求为止。
For a specific dialog usage, a UA MUST NOT send an INFO request associated with an Info Package until it has received an indication that the remote UA is willing to receive INFO requests for that Info
对于特定的对话用途，用户代理（UA）在收到远程用户代理（UA）愿意接收该信息包（Info Package）相关 INFO 请求的指示之前，不得发送与该信息包关联的 INFO 请求
Package, or after the UA has received an indication that the remote UA is no longer willing to receive INFO requests associated with that Info Package.
包，或在用户代理（UA）收到远程 UA 不再愿意接收与该信息包相关联的 INFO 请求的指示之后。
NOTE: When a UA sends a message that contains a Recv-Info header field with a new set of Info Packages for which the UA is willing to receive INFO requests, the remote UA might, before it receives the message, send an INFO request based on the old set of Info Packages. In this case, the receiver of the INFO requests rejects, and sends a 469 (Bad Info Package) response to, the INFO request.
注意：当用户代理（UA）发送包含 Recv-Info 头字段的消息，该字段指定了 UA 愿意接收 INFO 请求的新一组信息包时，远程 UA 可能在接收到该消息之前，基于旧的信息包集合发送 INFO 请求。在这种情况下，接收 INFO 请求的一方应拒绝该请求，并向其发送 469（错误信息包）响应。
If a UA indicates multiple Info Packages that provide similar functionality, it is not possible to indicate a priority order of the Info Packages, or to indicate that the UA wishes to only receive INFO requests for one of the Info Packages. It is up to the application logic associated with the Info Packages, and particular Info Package specifications, to describe application behavior in such cases.
如果用户代理（UA）指示了多个提供类似功能的信息包（Info Packages），则无法表明这些信息包的优先顺序，也无法表明用户代理希望仅接收其中一个信息包的 INFO 请求。在这种情况下，应用程序逻辑以及特定信息包规范需要描述此类情况下的应用程序行为。
For backward compatibility purposes, even if a UA indicates support of the Info Package mechanism, it is still allowed to enable legacy INFO usages. In addition, if a UA indicates support of the INFO method using the Allow header field [RFC3261], it does not implicitly indicate support of the Info Package mechanism. A UA MUST use the Recv-Info header field in order to indicate that it supports the Info Package mechanism. Likewise, even if a UA uses the Recv-Info header field to indicate that it supports the Info Package mechanism, in addition the UA still indicates support of the INFO method using the Allow header.
为了向后兼容，即使用户代理（UA）表明支持信息包机制，仍允许启用传统的 INFO 用法。此外，如果 UA 通过 Allow 头字段[RFC3261]表明支持 INFO 方法，这并不隐含表明其支持信息包机制。UA 必须使用 Recv-Info 头字段来表明它支持信息包机制。同样，即使 UA 使用 Recv-Info 头字段来表明支持信息包机制，UA 仍需通过 Allow 头字段表明支持 INFO 方法。
This document does not define a SIP option-tag [RFC3261] for the Info Package mechanism. However, an Info Package specification can define an option-tag associated with the specific Info Package, as described in Section 10.6.
本文档未为信息包机制定义 SIP 选项标签[RFC3261]。然而，如第 10.6 节所述，信息包规范可以定义与特定信息包相关的选项标签。
The text below defines rules on when a UA is required to include a Recv-Info header field in SIP messages. Section 7.1 lists the SIP methods for which a UA can insert a Recv-Info header field in requests and responses.
下文规定了用户代理（UA）在何时必须在 SIP 消息中包含 Recv-Info 头字段的规则。第 7.1 节列出了 UA 可以在请求和响应中插入 Recv-Info 头字段的 SIP 方法。
o The sender of an initial INVITE request MUST include a Recv-Info header field in the initial INVITE request, even if the sender is not willing to receive INFO requests associated with any Info Package.
o 初始 INVITE 请求的发送方必须在初始 INVITE 请求中包含一个 Recv-Info 头域，即使发送方不愿意接收与任何信息包相关的 INFO 请求。
o The receiver of a request that contains a Recv-Info header field MUST include a Recv-Info header field in a reliable 18x/2xx response to the request, even if the request contains an empty Recv-Info header field, and even if the header field value of the receiver has not changed since the previous time it sent a Recv-Info header field.
接收包含 Recv-Info 头域的请求的接收方，必须在对该请求的可靠 18x/2xx 响应中包含 Recv-Info 头域，即使请求中的 Recv-Info 头域为空，即使接收方的头域值自上次发送 Recv-Info 头域以来未发生变化。
o A UA MUST NOT include a Recv-Info header field in a response if the associated request did not contain a Recv-Info header field.
如果关联的请求中未包含 Recv-Info 头字段，则 UA 不得在响应中包含 Recv-Info 头字段。
NOTE: In contrast to the rules for generating Session Description Protocol (SDP) answers [RFC3264], the receiver of a request is not restricted to generating its own set of Info Packages as a subset of the Info Package set received in the Info-Package header field of the request.
注意：与生成会话描述协议（SDP）应答的规则[RFC3264]不同，请求接收方不受限于将其自身的信息包集合生成作为请求中信息包头字段接收到的信息包集合的子集。
As with SDP answers, the receiver can include the same Recv-Info header field value in multiple responses (18x/2xx) for the same INVITE/re-INVITE transaction, but the receiver MUST use the same Recv-Info header field value (if included) in all responses for the same transaction.
与 SDP 应答类似，接收方可以在同一 INVITE/re-INVITE 事务的多个响应（18x/2xx）中包含相同的 Recv-Info 头域值，但接收方在同一事务的所有响应中必须使用相同的 Recv-Info 头域值（如果包含的话）。
If the receiver of a request that contains a Recv-Info header field rejects the request, both the sender and receiver of the request MUST roll back to the set of Info Packages that was used before the request was sent. This also applies to the case where the receiver of an INVITE/re-INVITE request has included a Recv-Info header field in a provisional response, but later rejects the request.
如果请求的接收方拒绝包含 Recv-Info 头字段的请求，请求的发送方和接收方都必须回滚到请求发送前使用的信息包集合。这也适用于以下情况：INVITE/re-INVITE 请求的接收方在临时响应中包含了 Recv-Info 头字段，但随后拒绝了该请求。
NOTE: The dialog state rollback rules for Info Packages might differ from the rules for other types of dialog state information (SDP, target, etc.).
注意：信息包的对话状态回滚规则可能与其他类型的对话状态信息（如 SDP、目标等）的规则不同。
This document allows a UA to insert a Recv-Info header field in a REGISTER request. However, a UA SHALL NOT include a header value for a specific Info Package unless the particular Info Package specification describes how the header field value shall be interpreted and used by the registrar, e.g., in order to determine request targets.
本文件允许 UA 在 REGISTER 请求中插入 Recv-Info 头字段。然而，除非特定信息包规范描述了注册器应如何解释和使用该头字段值，例如，以确定请求目标，否则 UA 不得为特定信息包包含头字段值。
Rather than using the Recv-Info header field in order to determine request targets, it is recommended to use more appropriate mechanisms, e.g., based on RFC 3840 [RFC3840]. However, this document does not define a feature tag for the Info Package mechanism, or a mechanism to define feature tags for specific Info Packages.
建议采用更为适宜的机制来确定请求目标，而非依赖 Recv-Info 头字段，例如基于 RFC 3840 [RFC3840]的方法。然而，本文档并未为信息包机制定义特性标签，也未提供为特定信息包定义特性标签的机制。
This document describes one new SIP method: INFO. This document replaces the definition and registrations found in RFC 2976 [RFC2976].
本文件介绍了一种新的 SIP 方法：INFO。本文件取代了 RFC 2976 [RFC2976]中定义和注册的内容。
This table expands on Tables 2 and 3 in RFC 3261 [RFC3261].
此表对 RFC 3261 [RFC3261]中的表 2 和表 3 进行了扩展。
Header field where INFO
--------------------------------------------
Accept R o
Accept 415 o
Accept-Encoding R o
Accept-Encoding 2xx o
Accept-Encoding 415 c
Accept-Language R o
Accept-Language 2xx o
Accept-Language 415 o
Accept-Resource-Priority 2xx,417 o
Alert-Info -
Allow R o
Allow 405 m
Allow r o
Authentication-Info 2xx o
Authorization R o
Call-ID c m
Call-Info o
Contact -
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length o
Content-Type *
CSeq c m
Date o
Error-Info 3xx-6xx o
Expires -
From c m
Geolocation R o
Geolocation-Error r o Max-Breadth R - Max-Forwards R o MIME-Version o Min-Expires - Organization - Priority R - Privacy o Proxy-Authenticate 401 o Proxy-Authenticate 407 m Proxy-Authorization R o Proxy-Require R o Reason R o Record-Route R o Record-Route 2xx,18x o Referred-By R o Request-Disposition R o Require o Resource-Priority o Retry-After R - Retry-After 404,413,480,486 o Retry-After 500,503 o Retry-After 600,603 o Route R o Security-Client R o Security-Server 421,494 o Security-Verify R o Server r o Subject R o Supported R o Supported 2xx o Timestamp o To c m (w/ Tag) Unsupported 420 o User-Agent o Via m Warning r o WWW-Authenticate 401 m WWW-Authenticate 407 o
地理位置错误 r o 最大广度 R - 最大转发 R o MIME 版本 o 最小过期时间 - 组织 - 优先级 R - 隐私 o 代理认证 401 o 代理认证 407 m 代理授权 R o 代理要求 R o 原因 R o 记录路由 R o 记录路由 2xx,18x o 被引用者 R o 请求处理 R o 要求 o 资源优先级 o 重试后 R - 重试后 404,413,480,486 o 重试后 500,503 o 重试后 600,603 o 路由 R o 客户端安全 R o 服务器安全 421,494 o 安全验证 R o 服务器 r o 主题 R o 支持 R o 支持 2xx o 时间戳 o 至 c m (带标签) 不支持 420 o 用户代理 o 通过 m 警告 r o WWW 认证 401 m WWW 认证 407 o
Table 1: Summary of Header Fields
表 1：头部字段概要
This table expands on Tables 2 and 3 in RFC 3261 [RFC3261].
此表对 RFC 3261 [RFC3261]中的表 2 和表 3 进行了扩展。
Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD
------------------------------------------------------------------
Info-Package R - - - - - - - m* - -
Recv-Info R - - - m - o o - - o
Recv-Info 2xx - - - o** - - o***- - o***
Recv-Info 1xx - - - o** - - - - - -
Recv-Info 469 - - - - - - - m* - -
Recv-Info r - - - o - - o - - o
Header field where SUB NOT RFR
--------------------------------
Info-Package R - - -
Recv-Info R - - -
Recv-Info 2xx - - -
Recv-Info 1xx - - -
Recv-Info 469 - - -
Recv-Info r - - -
Table 2: INFO-Related Header Fields
表 2：与 INFO 相关的头部字段
The support and usage of the Info-Package and Recv-Info header fields are not applicable to UAs that only support legacy INFO usages.
对于仅支持传统 INFO 用法的用户代理，Info-Package 和 Recv-Info 头字段的支持与使用并不适用。
* Not applicable to INFO requests and responses associated with legacy INFO usages.
* 不适用于与传统 INFO 用法相关的 INFO 请求和响应。
** Mandatory in at least one reliable 18x/2xx response, if sent, to the INVITE request, if the associated INVITE request contained a Recv-Info header field.
** 如果发出的 INVITE 请求中包含 Recv-Info 头字段，则在至少一个可靠的 18x/2xx 响应中必须包含此信息。
*** Mandatory if the associated request contained a Recv-Info header
field.
As defined in Section 20 of RFC 3261, a "mandatory" header field MUST be present in a request, and MUST be understood by the UAS receiving the request.
根据 RFC 3261 第 20 节的规定，“强制性”头字段必须存在于请求中，并且必须被接收请求的用户代理服务器所理解。
This document adds "Info-Package" to the definition of the element "message-header" in the SIP message grammar [RFC3261]. Section 4 describes the Info-Package header field usage.
本文件在 SIP 消息语法[RFC3261]中对元素“message-header”的定义中增加了“Info-Package”。第 4 节描述了 Info-Package 头字段的用法。
For the purposes of matching Info Package types indicated in Recv-Info with those in the Info-Package header field value, one compares the Info-package-name portion of the Info-package-type portion of the Info-Package header field octet by octet with that of the Recv-Info header field value. That is, the Info Package name is case sensitive. Info-package-param is not part of the comparison-checking algorithm.
为了匹配 Recv-Info 中指示的信息包类型与 Info-Package 头字段值中的类型，需逐字节比较 Info-Package 头字段中 Info-package-type 部分的 Info-package-name 部分与 Recv-Info 头字段值。也就是说，信息包名称区分大小写。Info-package-param 不参与比较检查算法。
This document does not define values for Info-Package types. Individual Info Package specifications define these values.
本文件未定义信息包类型的值。各个信息包规范定义了这些值。
This document adds Recv-Info to the definition of the element "message-header" in the SIP message grammar [RFC3261]. Section 5 describes the Recv-Info header field usage.
本文件在 SIP 消息语法[RFC3261]中对元素“message-header”的定义中增加了 Recv-Info。第 5 节描述了 Recv-Info 头字段的用法。
This section covers considerations to take into account when deciding whether the usage of an Info Package is appropriate for transporting application information for a specific use-case.
本节涵盖了在决定是否适合使用信息包来传输特定用例的应用信息时需要考虑的因素。
When designing an Info Package, for application level information exchange, it is important to consider: is signaling, using INFO requests, within a SIP dialog, an appropriate mechanism for the use-case? Is it because it is the most reasonable and appropriate choice, or merely because "it's easy"? Choosing an inappropriate mechanism for a specific use-case can cause negative effects in SIP networks where the mechanism is used.
在设计信息包时，针对应用层信息交换，考虑以下问题至关重要：在 SIP 会话中，使用 INFO 请求进行信令传递，是否为该用例的恰当机制？这一选择是因为它是最合理且适宜的选项，还是仅仅因为“操作简便”？为特定用例选择不适当的机制，在采用该机制的 SIP 网络中可能会产生负面影响。
INFO messages differ from many other sorts of SIP messages in that they carry application information, and the size and rate of INFO messages are directly determined by the application. This can cause application information traffic to interfere with other traffic on that infrastructure, or to self-interfere when data rates become too high.
INFO 消息与其他类型的 SIP 消息不同，因为它们携带应用程序信息，且 INFO 消息的大小和速率直接由应用程序决定。这可能导致应用程序信息流量干扰同一基础设施上的其他流量，或在数据速率过高时自我干扰。
There is no default throttling mechanism for INFO requests. Apart from the SIP session establishment, the number of SIP messages exchanged during the lifetime of a normal SIP session is rather small.
对于 INFO 请求，不存在默认的限流机制。除了 SIP 会话建立之外，在正常 SIP 会话的生命周期内，交换的 SIP 消息数量相对较少。
Some applications, like those sending Dual-Tone Multi-Frequency (DTMF) tones, can generate a burst of up to 20 messages per second. Other applications, like constant GPS location updates, could generate a high rate of INFO requests during the lifetime of the invite dialog usage.
某些应用程序，例如发送双音多频（DTMF）音调的应用，每秒可产生高达 20 条消息的突发。而其他应用，如持续的 GPS 位置更新，可能在邀请对话框使用期间产生大量 INFO 请求。
A designer of an Info Package, and the application that uses it, need to consider the impact that the size and the rate of the INFO messages have on the network and on other traffic, since it normally cannot be ensured that INFO messages will be carried over a congestion-controlled transport protocol end-to-end. Even if an INFO message is sent over such a transport protocol, a downstream SIP entity might forward the message over a transport protocol that does not provide congestion control.
信息包的设计者及其使用的应用程序需要考虑 INFO 消息的大小和速率对网络及其他流量的影响，因为通常无法确保 INFO 消息会通过端到端的拥塞控制传输协议进行传输。即使 INFO 消息通过此类传输协议发送，下游的 SIP 实体也可能将消息转发至不提供拥塞控制的传输协议。
Furthermore, SIP messages tend to be relatively small, on the order of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct exchange of bulk data beyond these limits, especially if the headers plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768]. Appropriate mechanisms for such traffic include the Hypertext Transfer Protocol (HTTP) [RFC2616], the Message Session Relay Protocol (MSRP) [RFC4975], or other media plane data transport mechanisms.
此外，SIP 消息通常相对较小，大小约为 500 字节至 32 千字节。SIP 不适用于超出此范围的大量数据直接交换，特别是当头部加主体超过用户数据报协议（UDP）的最大传输单元（MTU）[RFC0768]时。此类流量的适当机制包括超文本传输协议（HTTP）[RFC2616]、消息会话中继协议（MSRP）[RFC4975]或其他媒体平面数据传输机制。
RFC 5405 [RFC5405] provides additional guidelines for applications using UDP that may be useful background reading.
RFC 5405 [RFC5405] 为使用 UDP 的应用程序提供了额外的指导方针，这些内容可能作为背景阅读材料非常有用。
This subsection describes some alternative mechanisms for transporting application information on the SIP signaling plane, using SIP messages.
本小节描述了在 SIP 信令平面上，利用 SIP 消息传输应用信息的一些替代机制。
An alternative for application level interaction is to use subscription-based events [RFC3265] that use the SIP SUBSCRIBE and NOTIFY methods. Using that mechanism, a UA requests state information, such as keypad presses from a device to an application server, or key-map images from an application server to a device.
应用程序级交互的另一种选择是使用基于订阅的事件[RFC3265]，这些事件采用 SIP 的 SUBSCRIBE 和 NOTIFY 方法。通过该机制，用户代理请求状态信息，例如从设备向应用服务器发送的按键信息，或从应用服务器向设备发送的键映射图像。
Event Packages [RFC3265] perform the role of disambiguating the context of a message for subscription-based events. The Info Package mechanism provides similar functionality for application information exchange using invite dialog usages [RFC5057].
事件包[RFC3265]用于明确订阅事件消息的上下文。信息包机制则为使用邀请对话的应用信息交换提供了类似的功能[RFC5057]。
While an INFO request is always part of, and shares the fate of, an existing invite dialog usage, a SUBSCRIBE request creates a separate dialog usage [RFC5057], and is normally sent outside an existing dialog usage.
虽然 INFO 请求总是作为现有邀请对话使用的一部分，并与该使用共享命运，但 SUBSCRIBE 请求会创建一个独立的对话使用[RFC5057]，并且通常在现有对话使用之外发送。
The subscription-based mechanism can be used by SIP entities to receive state information about SIP dialogs and sessions, without requiring the entities to be part of the route set of those dialogs and sessions.
订阅机制可被 SIP 实体用于接收有关 SIP 对话和会话的状态信息，而无需这些实体成为这些对话和会话的路由集的一部分。
As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies and back-to-back user agents (B2BUAs), the resource impact caused by the subscription dialogs needs to be considered. The number of subscription dialogs per user also needs to be considered.
随着 SUBSCRIBE/NOTIFY 消息在有状态 SIP 代理和背靠背用户代理（B2BUA）中传递，订阅对话所造成的资源影响需要被考虑。每个用户的订阅对话数量同样需要被考虑。
As for any other SIP-signaling-plane-based mechanism for transporting application information, the SUBSCRIBE/NOTIFY messages can put a significant burden on intermediate SIP entities that are part of the dialog route set, but do not have any interest in the application information transported between the end users.
对于任何基于 SIP 信令平面传输应用信息的机制，SUBSCRIBE/NOTIFY 消息可能会给对话路由集中虽涉及但并不关心终端用户间传输的应用信息的中间 SIP 实体带来显著负担。
The MESSAGE method [RFC3428] defines one-time instant message exchange, typically for sending MIME contents for rendering to the user.
MESSAGE 方法[RFC3428]定义了一次性即时消息交换，通常用于发送 MIME 内容以供用户呈现。
In SIP, media plane channels associated with SIP dialogs are established using SIP signaling, but the data exchanged on the media plane channel does not traverse SIP signaling intermediates, so if there will be a lot of information exchanged, and there is no need for the SIP signaling intermediaries to examine the information, it is recommended to use a media plane mechanism, rather than a SIP-signaling-based mechanism.
在 SIP 中，与 SIP 对话关联的媒体平面通道通过 SIP 信令建立，但媒体平面通道上交换的数据不经过 SIP 信令中间节点。因此，如果需要交换大量信息，且无需 SIP 信令中介检查这些信息，建议采用媒体平面机制，而非基于 SIP 信令的机制。
A low-latency requirement for the exchange of information is one strong indicator for using a media channel. Exchanging information through the SIP routing network can introduce hundreds of milliseconds of latency.
对信息交换的低延迟要求是使用媒体通道的一个有力指标。通过 SIP 路由网络交换信息可能会引入数百毫秒的延迟。
One mechanism for media plane exchange of application data is the Media Resource Control Protocol (MRCP) [SPEECHSC-MRCPv2], where a media plane connection-oriented channel, such as a Transmission Control Protocol (TCP) [RFC0793] or Stream Control Transmission Protocol (SCTP) [RFC4960] stream is established.
应用程序数据在媒体平面交换的一种机制是媒体资源控制协议（MRCP）[SPEECHSC-MRCPv2]，其中建立了一个面向连接的媒体平面通道，例如传输控制协议（TCP）[RFC0793]或流控制传输协议（SCTP）[RFC4960]流。
MSRP [RFC4975] defines session-based instant messaging as well as bulk file transfer and other such large-volume uses.
MSRP [RFC4975] 定义了基于会话的即时消息传递，以及批量文件传输和其他大规模应用。
Another alternative is to use a SIP-independent mechanism, such as HTTP [RFC2616]. In this model, the UA knows about a rendezvous point to which it can direct HTTP requests for the transfer of information. Examples include encoding of a prompt to retrieve in the SIP Request URI [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC-voicexml21-20070619] script.
另一种替代方案是采用与 SIP 无关的机制，如 HTTP [RFC2616]。在此模式下，用户代理知晓一个会合点，可向其发送 HTTP 请求以传输信息。例如，在 SIP 请求 URI 中编码提示获取信息[RFC4240]，或在 VoiceXML [W3C.REC-voicexml21-20070619]脚本中编码 SUBMIT 目标。
This section describes the syntax extensions to the ABNF syntax defined in RFC 3261 required for the INFO method, and adds definitions for the Info-Package and Recv-Info header fields. The previous sections describe the semantics. The ABNF defined in this specification is conformant to RFC 5234 [RFC5234].
本节阐述了为 INFO 方法所需的 ABNF 语法扩展，该语法在 RFC 3261 中定义，并新增了 Info-Package 和 Recv-Info 头部字段的定义。前文已描述了其语义。本规范中定义的 ABNF 遵循 RFC 5234 [RFC5234]的标准。
INFOm = %x49.4E.46.4F ; INFO in caps
Method =/ INFOm
message-header =/ (Info-Package / Recv-Info) CRLF
Info-Package = "Info-Package" HCOLON Info-package-type
Recv-Info = "Recv-Info" HCOLON [Info-package-list]
Info-package-list = Info-package-type *( COMMA Info-package-type )
Info-package-type = Info-package-name *( SEMI Info-package-param )
Info-package-name = token
Info-package-param = generic-param
This section provides guidance on how to define an Info Package, and what information needs to exist in an Info Package specification.
本节提供关于如何定义信息包以及信息包规范中需要包含哪些信息的指导。
If, for an Info Package, there is a need to extend or modify the behavior described in this document, that behavior MUST be described in the Info Package specification. It is bad practice for Info Package specifications to repeat procedures defined in this document, unless needed for purposes of clarification or emphasis.
如果对于某个信息包，需要扩展或修改本文档所述的行为，该行为必须在信息包规范中进行描述。信息包规范重复本文档中已定义的流程是不良做法，除非出于澄清或强调的需要。
Info Package specifications MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. However, Info Package specifications MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" if applications associated with the Info Package require it.
信息包规范不得削弱本规范中标记为“应”或“必须”的任何行为。然而，如果与信息包相关的应用程序需要，信息包规范可以加强“应”、“可”或“推荐”的要求至“必须”。
Info Package specifications MUST address the issues defined in the following subsections, or document why an issue is not applicable to the specific Info Package.
信息包规范必须解决以下小节中定义的问题，或者说明某个问题为何不适用于特定的信息包。
Section 8.4 describes alternative mechanisms, which should be considered as part of the process for solving a specific use-case, when there is a need for transporting application information.
第 8.4 节描述了替代机制，在需要传输应用程序信息时，应将其作为解决特定用例过程的一部分来考虑。
The Info Package specification MUST contain an overall description of the Info Package: what type of information is carried in INFO requests associated with the Info Package, and for what types of applications and functionalities UAs can use the Info Package.
信息包规范必须包含对信息包的总体描述：信息包所关联的 INFO 请求中承载了哪类信息，以及用户代理可针对哪些类型的应用和功能使用该信息包。
If the Info Package is defined for a specific application, the Info Package specification MUST state which application UAs can use the Info Package with.
如果信息包是为特定应用程序定义的，信息包规范必须声明哪些应用程序用户代理可以使用该信息包。
The Info Package specification MUST describe why the Info Package mechanism, rather than some other mechanism, has been chosen for the specific use-case to transfer application information between SIP endpoints. Common reasons can be a requirement for SIP proxies or
信息包规范必须阐述为何在特定用例中，选择信息包机制而非其他机制来在 SIP 端点间传输应用信息。常见原因可能包括对 SIP 代理的需求或
back-to-back user agents (B2BUAs) to see the transported application information (which would not be the case if the information was transported on a media path), or that it is not seen as feasible to establish separate dialogs (subscription) in order to transport the information.
背靠背用户代理（B2BUA）以查看传输的应用信息（如果信息在媒体路径上传输则不会出现此情况），或者认为建立单独的对话（订阅）以传输信息并不可行。
Section 8 provides more information and describes alternative mechanisms that one should consider for solving a specific use-case.
第 8 节提供了更多信息，并描述了应考虑用于解决特定用例的替代机制。
The Info Package specification MUST define an Info Package name, which UAs use as a header field value (e.g., "infoX") to identify the Info Package in the Recv-Info and Info-Package header fields. The header field value MUST conform to the ABNF defined in Section 9.2.
信息包规范必须定义一个信息包名称，用户代理将其用作头字段值（例如，“infoX”），以在 Recv-Info 和 Info-Package 头字段中标识该信息包。头字段值必须符合第 9.2 节中定义的 ABNF 规则。
The Info Package mechanism does not support package versioning. Specific Info Package message body payloads can contain version information, which is handled by the applications associated with the Info Package. However, such a feature is outside the scope of the generic Info Package mechanism.
信息包机制不支持包版本控制。特定信息包消息体负载可以包含版本信息，这些信息由与信息包相关的应用程序处理。然而，这一特性超出了通用信息包机制的范围。
NOTE: Even if an Info Package name contains version numbering (e.g., foo_v2), the Info Package mechanism does not distinguish a version number from the rest of the Info Package name.
注意：即使信息包名称包含版本编号（例如，foo_v2），信息包机制并不区分版本号与信息包名称的其余部分。
The Info Package specification MAY define Info Package parameters, which can be used in the Recv-Info or Info-Package header fields, together with the header field value that indicates the Info Package name (see Section 10.4).
信息包规范可以定义信息包参数，这些参数可用于 Recv-Info 或 Info-Package 头部字段中，同时头部字段值指示信息包名称（参见第 10.4 节）。
The Info Package specification MUST define the syntax and semantics of the defined parameters. In addition, the specification MUST define whether a specific parameter is applicable to only the Recv-Info header field, only the Info-Package header field, or to both.
信息包规范必须定义所定义参数的语法和语义。此外，规范必须明确指定某个参数是仅适用于 Recv-Info 头字段，仅适用于 Info-Package 头字段，还是两者都适用。
By default, an Info Package parameter is only applicable to the Info Package for which the parameter has been explicitly defined.
默认情况下，信息包参数仅适用于已明确为其定义参数的信息包。
Info Package parameters defined for specific Info Packages can share the name with parameters defined for other Info Packages, but the parameter semantics are specific to the Info Package for which they are defined. However, when choosing the name of a parameter, it is RECOMMENDED to not use the same name as an existing parameter for another Info Package, if the semantics of the parameters are different.
特定信息包定义的参数可以与其他信息包定义的参数共享名称，但参数的语义仅针对定义它们的信息包。然而，在选择参数名称时，如果参数的语义不同，建议不要使用与另一个信息包现有参数相同的名称。
The Info Package specification MAY define SIP option-tags, which can be used as described in RFC 3261.
信息包规范可以定义 SIP 选项标签，这些标签的使用方式在 RFC 3261 中有详细描述。
The registration requirements for option-tags are defined in RFC 5727 [RFC5727].
选项标签的注册要求在 RFC 5727 [RFC5727]中定义。
The Info Package specification MUST define which message body part MIME types are associated with the Info Package. The specification MUST either define those body parts, including the syntax, semantics, and MIME type of each body part, or refer to other documents that define the body parts.
信息包规范必须定义与信息包相关联的消息体部分 MIME 类型。该规范必须定义这些体部分，包括每个体部分的语法、语义和 MIME 类型，或者引用其他定义这些体部分的文档。
If multiple message body part MIME types are associated with an Info Package, the Info Package specification MUST define whether UAs need to use multipart body parts, in order to include multiple body parts in a single INFO request.
如果多个消息体部分 MIME 类型与一个信息包相关联，信息包规范必须定义用户代理是否需要使用多部分体部分，以便在单个 INFO 请求中包含多个体部分。
If there are restrictions on how UAs can use an Info Package, the Info Package specification MUST document such restrictions.
如果对用户代理如何使用信息包有任何限制，信息包规范必须记录这些限制。
There can be restrictions related to whether UAs are allowed to send overlapping (outstanding) INFO requests associated with the Info Package, or whether the UA has to wait for the response for a previous INFO request associated with the same Info Package.
可能存在与用户代理是否允许发送与信息包相关的重叠（未完成）INFO 请求相关的限制，或者用户代理是否必须等待与同一信息包相关的先前 INFO 请求的响应。
There can also be restrictions related to whether UAs need to support and use other SIP extensions and capabilities when they use the Info Package, and if there are restrictions related to how UAs can use the Info Package together with other Info Packages.
在使用信息包时，用户代理是否需要支持并使用其他 SIP 扩展和功能，以及在使用信息包与其他信息包结合时是否存在限制，这些都可能受到相关限制。
As the SIP stack might not be aware of Info Package specific restrictions, it cannot be assumed that overlapping requests would be rejected. As defined in Section 4.2.2, UAs will normally send a 200 (OK) response to an INFO request. The application logic associated with the Info Package needs to handle situations where UAs do not follow restrictions associated with the Info Package.
由于 SIP 栈可能不了解信息包特定的限制，因此不能假定重叠请求会被拒绝。如 4.2.2 节所定义，用户代理（UA）通常会对 INFO 请求发送 200（OK）响应。与信息包相关的应用逻辑需要处理 UA 未遵循信息包相关限制的情况。
If there is a maximum or minimum rate at which UAs can send INFO requests associated with the Info Package within a dialog, the Info Package specification MUST document the rate values.
如果存在用户代理（UA）在对话中发送与信息包（Info Package）相关的 INFO 请求的最大或最小速率限制，信息包规范必须记录这些速率值。
If the rates can vary, the Info Package specification MAY define Info Package parameters that UAs can use to indicate or negotiate the rates. Alternatively, the rate information can be part of the application data information associated with the Info Package.
如果费率可以变动，信息包规范可以定义信息包参数，供用户代理用来指示或协商费率。或者，费率信息可以作为与信息包相关的应用数据信息的一部分。
If the application information carried in INFO requests associated with the Info Package requires a certain level of security, the Info Package specification MUST describe the mechanisms that UAs need to use in order to provide the required security.
如果与信息包相关的 INFO 请求中携带的应用信息需要一定级别的安全性，信息包规范必须描述用户代理需要使用的机制，以提供所需的安全性。
If the Info Package specification does not require any additional security, other than what the underlying SIP protocol provides, this MUST be stated in the Info Package specification.
如果信息包规范不需要除底层 SIP 协议提供的之外的任何额外安全措施，这一点必须在信息包规范中明确说明。
NOTE: In some cases, it may not be sufficient to mandate Transport Layer Security (TLS) [RFC5246] in order to secure the Info Package payload, since intermediaries will have access to the payload, and because beyond the first hop, there is no way to assure subsequent hops will not forward the payload in clear text. The best way to ensure secure transport at the application level is to have the security at the application level. One way of achieving this is to use end-to-end security techniques such as Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751].
注意：在某些情况下，仅要求使用传输层安全（TLS）[RFC5246]可能不足以保护信息包的有效载荷，因为中间节点能够访问该载荷，并且无法确保在第一跳之后的各跳不会以明文形式转发该载荷。确保应用层安全传输的最佳方式是在应用层实施安全措施。实现这一点的一种方法是采用端到端安全技术，如安全/多用途互联网邮件扩展（S/MIME）[RFC5751]。
It is strongly RECOMMENDED that the Info Package specification define the procedure regarding how implementors shall implement and use the Info Package, or refer to other locations where implementors can find that information.
强烈建议信息包规范定义实施者应如何实现和使用信息包的程序，或指引实施者至其他可获取该信息的地点。
NOTE: Sometimes an Info Package designer might choose to not reveal the details of an Info Package. However, in order to allow multiple implementations to support the Info Package, Info Package designers are strongly encouraged to provide the implementation details.
注意：有时信息包设计者可能会选择不透露信息包的详细信息。然而，为了使多个实现能够支持信息包，强烈建议信息包设计者提供实现细节。
It is RECOMMENDED that the Info Package specification provide demonstrative message flow diagrams, paired with complete messages and message descriptions.
建议信息包规范提供演示性的消息流图，并配以完整的消息及其描述。
Note that example flows are by definition informative, and do not replace normative text.
请注意，示例流程本质上具有参考性，并不替代规范性文本。
IANA updated the existing registration in the "Methods and Response Codes" registry under "Session Initiation Protocol (SIP) Parameters" from:
IANA 更新了 "会话发起协议 (SIP) 参数" 下的 "方法和响应代码" 注册表中的现有条目，内容如下：
Method: INFO Reference: [RFC2976]
方法：INFO 参考：[RFC2976]
to: 致：
Method: INFO Reference: [RFC6086]
方法：INFO 参考：[RFC6086]
IANA added the following new SIP header field in the "Header Fields" registry under "Session Initiation Protocol (SIP) Parameters".
IANA 在"会话发起协议(SIP)参数"下的"头字段"注册表中添加了以下新的 SIP 头字段。
Header Name: Info-Package Compact Form: (none) Reference: [RFC6086]
标题名称：信息包 紧凑形式：（无） 参考文献：[RFC6086]
IANA added the following new SIP header field in the "Header Fields" registry under "Session Initiation Protocol (SIP) Parameters".
IANA 在"会话发起协议(SIP)参数"下的"头字段"注册表中添加了以下新的 SIP 头字段。
Header Name: Recv-Info Compact Form: (none) Reference: [RFC6086]
标题名称：接收信息 紧凑形式：（无） 参考文献：[RFC6086]
IANA created the following registry under "Session Initiation Protocol (SIP) Parameters":
IANA 在"会话发起协议（SIP）参数"下创建了以下注册表：
Info Packages 信息包
Note to the reviewer:
审阅者须知：
The policy for review of Info Packages is "Specification Required", as defined in [RFC5226]. This policy was selected because Info Packages re-use an existing mechanism for transport of arbitrary session-associated data within SIP; therefore, new Info Packages do not require the more extensive review required by specifications that make fundamental protocol changes. However, the reviewer is expected to verify that each Info Package registration is in fact consistent with this definition. Changes to the SIP protocol and state machine are outside of the allowable scope for an Info Package and are governed by other procedures including RFC 5727 and its successors, if any.
信息包审查的政策为“规范要求”，如[RFC5226]所定义。选择此政策是因为信息包复用了 SIP 中用于传输任意会话关联数据的现有机制；因此，新的信息包不需要像那些进行基本协议变更的规范那样进行更广泛的审查。然而，审查者应验证每个信息包注册实际上是否符合此定义。对 SIP 协议和状态机的更改超出了信息包允许的范围，并受其他程序的约束，包括 RFC 5727 及其后续版本（如有）。
The following data elements populate the Info Packages Registry.
以下数据元素填充信息包注册表。
o Info Package Name: The Info Package Name is a case-sensitive token. In addition, IANA shall not register multiple Info Package names that have identical case-insensitive values.
信息包名称：信息包名称是一个区分大小写的标识符。此外，IANA 不应注册多个在忽略大小写情况下值相同的信息包名称。
o Reference: A reference to a specification that describes the Info Package.
参考：对描述信息包的规范的引用。
The initial population of this table shall be:
该表的初始数据应为：
Name Reference 名称引用
IANA added the following new header field value to the "Mail Content Disposition Values" registry under "Mail Content Disposition Values and Parameters".
IANA 在 "邮件内容处置值和参数" 下的 "邮件内容处置值" 注册表中添加了以下新的头字段值。
Name: info-package Description: The body contains information associated with an Info Package Reference: RFC6086
名称：信息包描述：正文包含与信息包相关的信息参考：RFC6086
IANA registered the following new response code in the "Session Initiation Protocol (SIP) Parameters" -- "Response Codes" registry.
IANA 在"会话发起协议（SIP）参数"的"响应代码"注册表中注册了以下新的响应代码。
Response Code: 469 Default Reason Phrase: Bad Info Package Reference: RFC6086
响应代码：469 默认原因短语：错误信息包引用：RFC6086
12.1. Indication of Willingness to Receive INFO Requests for Info Packages
12.1. 表明愿意接收信息请求以获取信息包
The UAC sends an initial INVITE request, where the UAC indicates that it is willing to receive INFO requests for Info Packages P and R.
UAC 发送一个初始的 INVITE 请求，其中 UAC 表明它愿意接收关于信息包 P 和 R 的 INFO 请求。
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 INVITE
Recv-Info: P, R
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: ...
...
The UAS sends a 200 (OK) response back to the UAC, where the UAS indicates that it is willing to receive INFO requests for Info Packages R and T.
UAS 向 UAC 发送 200（OK）响应，表明其愿意接收关于信息包 R 和 T 的 INFO 请求。
SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;
received=192.0.2.1
To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 INVITE
Contact: <sip:bob@pc33.example.com>
Recv-Info: R, T
Content-Type: application/sdp
Content-Length: ...
...
The UAC sends an ACK request.
UAC 发送一个 ACK 请求。
ACK sip:bob@pc33.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 ACK
Content-Length: 0
The UAC sends an UPDATE request within the invite dialog usage, where the UAC indicates (using an empty Recv-Info header field) that it is not willing to receive INFO requests for any Info Packages.
UAC 在邀请对话使用中发送一个 UPDATE 请求，其中 UAC 通过使用空的 Recv-Info 头字段表明它不愿意接收任何信息包的 INFO 请求。
UPDATE sip:bob@pc33.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314163 UPDATE
Recv-Info:
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: ...
...
The UAS sends a 200 (OK) response back to the UAC, where the UAS indicates that it is willing to receive INFO requests for Info Packages R and T.
UAS 向 UAC 发送 200（OK）响应，表明其愿意接收关于信息包 R 和 T 的 INFO 请求。
SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;
received=192.0.2.1
To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314163 INVITE
Contact: <sip:alice@pc33.example.com>
Recv-Info: R, T
Content-Type: application/sdp
Content-Length: ...
...
The UA sends an INFO request associated with Info Package "foo".
UA 发送一个与信息包“foo”相关的 INFO 请求。
INFO sip:alice@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774
Call-Id: a84b4c76e66710@pc33.example.com
CSeq: 314333 INFO
Info-Package: foo
Content-type: application/foo
Content-Disposition: Info-Package
Content-length: 24
I am a foo message type
我是一条 foo 消息类型
SIP extensions can sometimes add body part payloads into an INFO request, independent of the Info Package. In this case, the Info Package payload gets put into a multipart MIME body, with a Content-Disposition header field that indicates which body part is associated with the Info Package.
SIP 扩展有时会在 INFO 请求中独立于信息包添加负载部分，此时，信息包负载会被放入多部分 MIME 主体中，并带有 Content-Disposition 头部字段，用以指明与信息包相关联的负载部分。
INFO sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Alice <sip:alice@example.net>;tag=1234567 From: Bob <sip:bob@example.com>;tag=abcdefg Call-Id: a84b4c76e66710@pc33.example.com CSeq: 314400 INFO Info-Package: foo Content-Type: multipart/mixed;boundary="theboundary" Content-Length: ...
INFO sip:alice@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Alice <sip:alice@example.net>;tag=1234567
From: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: a84b4c76e66710@pc33.example.com
CSeq: 314400 INFO
Info-Package: foo
Content-Type: multipart/mixed;boundary="theboundary"
Content-Length: ...
--theboundary
Content-Type: application/mumble
...
<mumble stuff> <咕哝内容>
--theboundary Content-Type: application/foo-x Content-Disposition: Info-Package Content-length: 59
I am a foo-x message type, and I belong to Info Package foo --theboundary--
我是一种 foo-x 消息类型，属于信息包 foo --分界线--
12.2.2.2. Info Package with Multiple Body Parts inside Multipart Body Part
12.2.2.2. 包含多个主体部分的多部分主体部分信息包
Multiple body part payloads can be associated with a single Info Package. In this case, the body parts are put into a multipart MIME body, with a Content-Disposition header field that indicates which body part is associated with the Info Package.
多个身体部位的有效载荷可以与单个信息包相关联。在这种情况下，身体部位被放入一个多部分 MIME 主体中，并带有一个 Content-Disposition 头字段，用于指示哪个身体部位与信息包相关联。
INFO sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Alice <sip:alice@example.net>;tag=1234567 From: Bob <sip:bob@example.com>;tag=abcdefg Call-Id: a84b4c76e66710@pc33.example.com CSeq: 314423 INFO Info-Package: foo Content-Type: multipart/mixed;boundary="theboundary" Content-Disposition: Info-Package Content-Length: ...
INFO sip:alice@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Alice <sip:alice@example.net>;tag=1234567
From: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: a84b4c76e66710@pc33.example.com
CSeq: 314423 INFO
Info-Package: foo
Content-Type: multipart/mixed;boundary="theboundary"
Content-Disposition: Info-Package
Content-Length: ...
--theboundary Content-Type: application/foo-x Content-length: 59
I am a foo-x message type, and I belong to Info Package foo
我是一种 foo-x 消息类型，属于信息包 foo
<mumble stuff> <咕哝内容>
--theboundary Content-Type: application/foo-y Content-length: 59
I am a foo-y message type, and I belong to Info Package foo --theboundary--
我是一种 foo-y 消息类型，属于信息包 foo --边界--
The body part payload associated with the Info Package can have a Content-Disposition header field value other than "Info-Package". In this case, the body part is put into a multipart MIME body, with a Content-Disposition header field that indicates which body part is associated with the Info Package.
与信息包相关联的正文部分负载可以具有不同于“Info-Package”的 Content-Disposition 头字段值。在这种情况下，该正文部分被放入一个多部分 MIME 正文中，其 Content-Disposition 头字段指示与信息包相关联的正文部分。
INFO sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Alice <sip:alice@example.net>;tag=1234567 From: Bob <sip:bob@example.com>;tag=abcdefg Call-Id: a84b4c76e66710@pc33.example.com CSeq: 314423 INFO Info-Package: foo Content-Type: multipart/mixed;boundary="theboundary" Content-Disposition: Info-Package Content-Length: ...
INFO sip:alice@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Alice <sip:alice@example.net>;tag=1234567
From: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: a84b4c76e66710@pc33.example.com
CSeq: 314423 INFO
Info-Package: foo
Content-Type: multipart/mixed;boundary="theboundary"
Content-Disposition: Info-Package
Content-Length: ...
--theboundary Content-Type: application/foo-x Content-Disposition: icon Content-length: 59
I am a foo-x message type, and I belong to Info Package foo --theboundary--
我是一种 foo-x 消息类型，属于信息包 foo --分界线--
By eliminating multiple usages of INFO messages without adequate community review, and by eliminating the possibility of rogue SIP UAs confusing another UA by purposely sending unrelated INFO requests, we expect this document's clarification of the use of INFO to improve the security of the Internet. While rogue UAs can still send unrelated INFO requests, this mechanism enables the UAS and other security devices to associate INFO requests with Info Packages that have been negotiated for a session.
通过消除未经充分社区审查的多次 INFO 消息使用，并消除恶意 SIP UA 通过故意发送无关 INFO 请求来混淆其他 UA 的可能性，我们期望本文档对 INFO 使用的澄清能提升互联网的安全性。尽管恶意 UA 仍可发送无关 INFO 请求，但此机制使 UAS 及其他安全设备能将 INFO 请求与为会话协商的 Info 包关联起来。
If the content of the Info Package payload is private, UAs will need to use end-to-end encryption, such as S/MIME, to prevent access to the content. This is particularly important, as transport of INFO is likely not to be end-to-end, but through SIP proxies and back-to-back user agents (B2BUAs), which the user may not trust.
如果信息包载荷的内容属于私密性质，用户代理（UAs）将需要采用端到端加密技术，如 S/MIME，以防止内容被访问。这一点尤为重要，因为 INFO 的传输很可能不是端到端的，而是通过 SIP 代理和背靠背用户代理（B2BUAs）进行，这些环节用户可能并不信任。
The INFO request transports application level information. One implication of this is that INFO messages may require a higher level of protection than the underlying SIP dialog signaling. In particular, if one does not protect the SIP signaling from eavesdropping or authentication and repudiation attacks, for example by using TLS transport, then the INFO request and its contents will be vulnerable as well. Even with SIP/TLS, any SIP hop along the path from UAC to UAS can view, modify, or intercept INFO requests, as they can with any SIP request. This means some applications may require end-to-end encryption of the INFO payload, beyond, for example, hop-by-hop protection of the SIP signaling itself. Since the application dictates the level of security required, individual Info Packages have to enumerate these requirements. In any event, the Info Package mechanism described by this document provides the tools for such secure, end-to-end transport of application data.
INFO 请求用于传输应用层信息。这一特性的一个含义是，INFO 消息可能需要比底层 SIP 对话信令更高级别的保护。特别是，如果不通过使用 TLS 传输等方式来保护 SIP 信令免受窃听或认证与否认攻击，那么 INFO 请求及其内容也将同样易受攻击。即便在 SIP/TLS 环境下，从用户代理客户端（UAC）到用户代理服务器（UAS）路径上的任何 SIP 跳转节点都能查看、修改或截取 INFO 请求，正如它们能对任何 SIP 请求所做的那样。这意味着某些应用可能需要对 INFO 负载进行端到端加密，而不仅仅是对 SIP 信令本身进行逐跳保护。由于应用决定了所需的安全级别，因此各个信息包（Info Package）必须详细列出这些要求。无论如何，本文档描述的信息包机制提供了实现应用数据安全、端到端传输的工具。
One interesting property of Info Package usage is that one can re-use the same digest-challenge mechanism used for INVITE-based authentication for the INFO request. For example, one could use a quality-of-protection (qop) value of authentication with integrity (auth-int), to challenge the request and its body, and prevent intermediate devices from modifying the body. However, this assumes the device that knows the credentials in order to perform the INVITE challenge is still in the path for the INFO request, or that the far-end UAS knows such credentials.
信息包使用的一个有趣特性是，可以为 INFO 请求重用基于 INVITE 认证的摘要-挑战机制。例如，可以使用带有完整性验证的认证质量（qop）值（即 auth-int）来挑战请求及其主体，防止中间设备篡改主体内容。然而，这假设了知道执行 INVITE 挑战所需凭证的设备仍在 INFO 请求的路径上，或者远端 UAS 知晓这些凭证。
[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 月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten, T. 和 H. Alvestrand, "撰写 RFC 中 IANA 考虑章节的指南", BCP 26, RFC 5226, 2008 年 5 月.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker, D. 和 P. Overell, "用于语法规范的扩充巴科斯-瑙尔范式：ABNF", STD 68, RFC 5234, 2008 年 1 月.
[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] 罗森伯格, J., 舒尔茨林, H., 卡马里洛, G., 约翰斯顿, A., 彼得森, J., 斯帕克斯, R., 汉德利, M., 和 E. 斯库勒默, "SIP: 会话发起协议", RFC 3261, 2002 年 6 月.
[RFC5621] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, September 2009.
[RFC5621] Camarillo, G., "会话发起协议(SIP)中的消息体处理", RFC 5621, 2009 年 9 月.
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.
[RFC5727] Peterson, J., Jennings, C., 和 R. Sparks, "会话发起协议（SIP）及实时应用与基础设施领域的变更流程", BCP 67, RFC 5727, 2010 年 3 月.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel, J., "传输控制协议", STD 7, RFC 793, 1981 年 9 月.
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[RFC2976] Donovan, S., "SIP INFO 方法", RFC 2976, 2000 年 10 月.
[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] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., 和 T. Berners-Lee, "超文本传输协议 -- HTTP/1.1", RFC 2616, 1999 年 6 月.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel, J., "用户数据报协议", STD 6, RFC 768, 1980 年 8 月.
[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 月.
[RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.
[RFC3398] Camarillo, G., Roach, A., Peterson, J., 和 L. Ong, "综合业务数字网(ISDN)用户部分(ISUP)到会话初始协议(SIP)的映射", RFC 3398, 2002 年 12 月.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., 和 P. Kyzivat, "在会话发起协议(SIP)中指示用户代理能力", RFC 3840, 2004 年 8 月.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
[RFC3372] Vemuri, A. 和 J. Peterson, "电话会话初始协议（SIP-T）：上下文与架构", BCP 63, RFC 3372, 2002 年 9 月.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach, A., "会话发起协议（SIP）特定事件通知", RFC 3265, 2002 年 6 月.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 和 D. Gurle, "用于即时消息的会话发起协议(SIP)扩展", RFC 3428, 2002 年 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 4240, 2005 年 12 月.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] 斯图尔特, R., "流控制传输协议", RFC 4960, 2007 年 9 月.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell, B., Mahy, R., 和 C. Jennings, "消息会话中继协议（MSRP）", RFC 4975, 2007 年 9 月.
[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 5022, September 2007.
[RFC5022] Van Dyke, J., Burger, E., 和 A. Spitzer, "媒体服务器控制标记语言（MSCML）与协议", RFC 5022, 2007 年 9 月.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007.
[RFC5057] Sparks, R., "会话发起协议中的多重对话使用", RFC 5057, 2007 年 11 月.
[RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for Media Control", RFC 5168, March 2008.
[RFC5168] Levin, O., Even, R., 和 P. Hagendorf, "媒体控制 XML 模式", RFC 5168, 2008 年 3 月.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks, T. 和 E. Rescorla, "传输层安全（TLS）协议版本 1.2", RFC 5246, 2008 年 8 月.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405] Eggert, L. 和 G. Fairhurst, "应用程序设计者单播 UDP 使用指南", BCP 145, RFC 5405, 2008 年 11 月.
[RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup Language (MSML)", RFC 5707, February 2010.
[RFC5707] Saleem, A., Xin, Y., 和 G. Sharratt, "媒体服务器标记语言（MSML）", RFC 5707, 2010 年 2 月.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell, B. 和 S. Turner, "安全/多用途互联网邮件扩展（S/MIME）第 3.2 版消息规范", RFC 5751, 2010 年 1 月.
[W3C.REC-voicexml21-20070619] Porter, B., Oshry, M., Rehor, K., Auburn, R., Bodell, M., Carter, J., Burke, D., Baggia, P., Candell, E., Burnett, D., McGlashan, S., and A. Lee, "Voice Extensible Markup Language (VoiceXML) 2.1", World Wide Web Consortium Recommendation REC-voicexml21-20070619, June 2007, <http://www.w3.org/TR/2007/REC-voicexml21-20070619>.
[W3C.REC-voicexml21-20070619] Porter, B., Oshry, M., Rehor, K., Auburn, R., Bodell, M., Carter, J., Burke, D., Baggia, P., Candell, E., Burnett, D., McGlashan, S., 及 A. Lee, "语音可扩展标记语言（VoiceXML）2.1", 万维网联盟推荐标准 REC-voicexml21-20070619, 2007 年 6 月, <http://www.w3.org/TR/2007/REC-voicexml21-20070619>.
[SPEECHSC-MRCPv2] Burnett, D. and S. Shanmugham, "Media Resource Control Protocol Version 2 (MRCPv2)", Work in Progress, November 2010.
[SPEECHSC-MRCPv2] 伯内特（Burnett），D. 与 S. 尚穆根（Shanmugham），“媒体资源控制协议版本 2（MRCPv2）”，工作进展，2010 年 11 月。
[ECMA-355] "Standard ECMA-355 Corporate Telecommunication Networks - Tunnelling of QSIG over SIP", ECMA http:// www.ecma-international.org/publications/standards/ Ecma-355.htm, June 2008.
[ECMA-355] "标准 ECMA-355 企业电信网络 - 通过 SIP 的 QSIG 隧道技术", ECMA http://www.ecma-international.org/publications/standards/Ecma-355.htm, 2008 年 6 月。
The work on this document was influenced by "The Session Initiation Protocol (SIP) INFO Considered Harmful" (26 December 2002) written by Jonathan Rosenberg, and by "Packaging and Negotiation of INFO Methods for the Session Initiation Protocol" (15 January 2003) written by Dean Willis.
本文件的工作受到 Jonathan Rosenberg 所著的《会话发起协议（SIP）INFO 被认为有害》（2002 年 12 月 26 日）以及 Dean Willis 所著的《会话发起协议 INFO 方法的打包与协商》（2003 年 1 月 15 日）的影响。
The following individuals have been involved in the work, and have provided input and feedback on this document:
以下个人参与了这项工作，并为本文档提供了意见和反馈：
Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Jonathan Rosenberg, Juha Heinanen, Keith Drage, Kevin Attard Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, Rayees Khan, Robert Sparks, Roland Jesske, Roni Even, Salvatore Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit Garg, and Xavier Marjoum.
亚当·罗奇, 安德斯·克里斯滕森, 安德鲁·艾伦, 阿伦·阿鲁纳查拉姆, 本·坎贝尔, 鲍勃·彭菲尔德, 布拉姆·弗伯格, 布莱恩·斯图克, 克里斯·博尔顿, 克里斯蒂安·斯特雷迪克, 卡伦·詹宁斯, 戴尔·沃利, 迪恩·威利斯, 埃里克·雷斯克拉, 弗兰克·米勒, 贡萨洛·卡马里略, 戈登·贝斯, 亨利·辛雷布里奇, 伊尼基·巴斯·卡斯蒂略, 詹姆斯·杰克逊, 詹姆斯·拉弗蒂, 杰罗恩·范·贝梅尔, 乔尔·哈尔彭, 约翰·埃尔韦尔, 乔纳森·罗森伯格, 尤哈·海南恩, 基思·德雷奇, 凯文·阿塔德·康帕尼奥, 曼普利特·辛格, 马丁·多利, 玛丽·巴恩斯, 迈克尔·普罗克特, 保罗·基兹瓦特, 徐培利, 彼得·布拉瑟威克, 拉吉·杰恩, 雷伊斯·汗, 罗伯特·斯帕克斯, 罗兰·耶斯克, 罗尼·埃文, 萨尔瓦托雷·洛雷托, 萨姆·加内桑, 桑杰·辛哈, 斯宾塞·道金斯, 史蒂夫·兰斯特夫, 苏米特·加尔格, 以及泽维尔·马尔朱姆。
John Elwell and Francois Audet helped with QSIG references. In addition, Francois Audet provided text for the revised abstract. Keith Drage provided comments and helped immensely with Table 1.
约翰·埃尔韦尔和弗朗索瓦·奥代协助提供了 QSIG 参考资料。此外，弗朗索瓦·奥代为修订后的摘要提供了文本。基思·德雷奇提供了评论，并在表 1 的修订中给予了极大的帮助。
Arun Arunachalam, Brett Tate, John Elwell, Keith Drage, and Robert Sparks provided valuable feedback during the working group last call process, in order to prepare this document for publication.
Arun Arunachalam、Brett Tate、John Elwell、Keith Drage 和 Robert Sparks 在工作组最终呼叫过程中提供了宝贵的反馈，以准备这份文件的发布。
Adam Roach, Dean Willis, John Elwell, and Paul Kyzivat provided valuable input in order to sort out the message body part usage for Info Packages.
亚当·罗奇、迪安·威利斯、约翰·埃尔韦尔和保罗·基兹维特为梳理信息包中消息体部分的用法提供了宝贵的意见。
Authors' Addresses 作者地址
Christer Holmberg Ericsson Hirsalantie 11 Jorvas, 02420 Finland
克里斯特·霍姆伯格·爱立信
赫尔萨兰蒂街 11 号
约尔瓦斯，02420
芬兰
EMail: christer.holmberg@ericsson.com
Eric W. Burger Georgetown University
埃里克·W·伯格 乔治城大学
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
Hadriel Kaplan Acme Packet 100 Crosby Drive Bedford, MA 01730 USA
哈德瑞尔·卡普兰
Acme Packet 公司
100 Crosby Drive
贝德福德，马萨诸塞州 01730
美国
EMail: hkaplan@acmepacket.com