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
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）信息方法和包框架
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。为了向后兼容，本文档还指定了INFO方法的“传统”使用模式，该模式与先前在RFC 2976中定义的用法兼容，在本文档中称为“传统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
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
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].
本文档定义了会话启动协议（SIP）[RFC3261]的方法INFO。
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方法的使用并不构成单独的对话框用法。信息消息始终是邀请对话框用法的一部分，并与邀请对话框用法的命运共享[RFC5057]。信息消息不能作为其他对话框使用的一部分或在现有对话框之外发送。
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
本文档还定义了信息包机制。信息包规范定义了与信息包关联的信息消息中携带的信息的内容和语义。信息包机制也为用户提供了一种方法
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）指示他们愿意接收哪些信息包的信息请求，以及特定信息请求与哪个信息包关联。
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 header字段来指示它愿意接收哪些信息包的信息请求。UA可以在对话框建立期间指示初始信息包集，也可以在invite对话框使用期间指示新信息包集。
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 header字段（没有值的header字段）来表示它不愿意接收任何信息包的信息请求，同时仍然通知其他UA它支持信息包机制。
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发送信息请求时，它使用信息包标题字段指示与请求关联的信息包。一个特定的信息请求只能与单个信息包关联。
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:
许多标准化和专有的应用程序使用了之前在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.
o 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.
o RFC 5022[RFC5022]指定媒体服务器控制标记语言（MSCML）协议如何将信息用作传输机制。MSCML在Require头字段中使用一个选项标记，以确保接收者理解信息内容。
o RFC 5707 [RFC5707] specifies how INFO is used as a transport mechanism by the Media Server Markup Language (MSML) protocol.
o RFC 5707[RFC5707]指定媒体服务器标记语言（MSML）协议如何将信息用作传输机制。
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].
o 公司一直在使用信息消息来请求快速视频更新。目前，RFC 5168[RFC5168]中规定了基于实时传输控制协议（RTCP）的标准化机制。
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.
o 公司一直在使用信息信息来传输双音多频（DTMF）音。所有机制都是专有的，尚未标准化。
Some legacy INFO usages are also recognized as being shortcuts to more appropriate and flexible mechanisms.
一些遗留信息的使用也被认为是通往更合适、更灵活机制的捷径。
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.
由于旧版信息用法没有关联的信息包，因此无法将Recv INFO和INFO Package header字段与旧版信息用法一起使用。也就是说，UA不能使用Recv Info header字段指示其愿意接收信息请求的遗留信息使用，UA不能使用Info Package header字段指示信息请求与哪些遗留信息使用相关联。
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.
由于上述问题，遗留信息使用通常需要静态配置，以指示UAs支持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工作组多年来花费了大量的讨论时间，就修复信息（通过定义信息使用方式的注册机制）或完全弃用信息（使用RFC 3398[RFC3398]中描述的用法）是否更合适达成一致作为唯一合法用途而被赋予祖父身份）。尽管这需要更多倾向于完全反对信息的人达成实质性的共识和让步，但工作组的最终方向是发布本规范中定义的信息包注册框架。
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中定义的用法兼容，这里称为“传统信息用法”。
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:
出于向后兼容性的目的，本文档不反对旧版信息使用，也不要求用户定义此类使用的信息包。然而：
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不得在旧版信息请求中插入信息包标题字段（如第4.2.1节所述，与信息包关联的信息请求始终包含信息包标题字段）。
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. 任何新的使用都必须使用本规范中定义的信息包机制，因为它不会共享与旧信息使用相关的问题，而且信息包可以向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. UAs允许在同一invite对话框使用中同时启用传统信息使用和信息包使用，但UAs不得混合使用传统信息使用和信息包使用来传输相同的应用程序级信息。如果可能，UAs应倾向于使用信息包。
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节详细介绍了适用于使用信息的应用程序类型。
This section describes how a UA handles INFO requests and responses, as well as the message bodies included in INFO messages.
本节描述UA如何处理信息请求和响应，以及信息消息中包含的消息正文。
An INFO request can be associated with an Info Package (see Section 5), or associated with a legacy INFO usage (see Section 2).
信息请求可以与信息包相关联（参见第5节），也可以与遗留信息使用相关联（参见第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节所述的现有invite对话框使用中的任何其他非目标刷新请求相同。
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发送与信息包关联的信息请求时，它必须包含一个信息包标题字段，该字段指示哪个信息包与该请求关联。特定信息请求只能用于单个信息包。
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发送与遗留信息使用相关联的信息请求时，没有与该请求相关联的信息包，UA不得在请求中包含信息包头字段。
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标头字段。UA只能通过使用第5节中列出的SIP方法（及其响应）指示其愿意接收信息请求的一组信息包。
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未表示愿意在该对话框内接收信息包，则UA不得在邀请对话框外发送信息请求，也不得在邀请对话框内发送信息包的信息请求。
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根据RFC 5057[RFC5057]接收到对信息请求的469（错误信息包）响应，则该响应表示仅事务失败，UA不得终止invite对话框的使用。
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必须准备在早期对话阶段接收来自多个远程UAs的信息请求。此外，UA必须准备好从不同的远程UAs接收不同的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）（初始邀请请求的接收者）在发送创建对话框的响应后立即发送信息请求，则UAS需要准备信息请求在创建对话框响应之前到达用户代理客户端（UAC）的可能性，因此可能会被UAC拒绝。此外，如果UA在远程UA发送其愿意接收信息请求的一组新信息包的同时发送信息请求，则信息请求可能会由于竞争条件而被拒绝。
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收到与UA未表示愿意接收的信息包相关的信息请求，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.
接收信息请求。UA不得使用响应来更新信息包集，而只能指示当前信息包集。在多对话框使用术语[RFC5057]中，这表示仅事务失败，并且不会终止invite对话框的使用。
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接收到与信息包相关联的信息请求，并且具有内容处置“信息包”（参见第4.3.1节）的消息正文部分具有UA支持但不在该信息包上下文中的多用途Internet Mail Extensions（MIME）类型，则建议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.
否则，如果信息请求语法正确且结构良好，UA必须发送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.
注意：如果应用程序需要拒绝它在信息请求中收到的信息，则需要在应用程序级别上执行此操作。也就是说，应用程序需要触发一个新的信息请求，该请求包含以前收到的应用程序数据未被接受的信息。个别信息包规范需要描述此类程序的细节。
Proxies need no additional behavior beyond that described in RFC 3261 to support INFO.
除了RFC 3261中描述的行为之外，代理不需要其他行为来支持信息。
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 UAs之间传输应用程序级信息。应用信息数据被携带在信息请求的消息体的有效载荷中。
NOTE: An INFO request associated with an Info Package can also include information associated with the Info Package using Info-Package header field parameters.
注意：与信息包关联的信息请求还可以使用信息包标题字段参数包含与信息包关联的信息。
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 Package”值标识。正文部分可以包含单个MIME类型，也可以是包含与信息包关联的其他正文部分的多部分[RFC5621]。
UAs MUST support multipart body parts in accordance with RFC 5621.
UAs必须根据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请求还可以包含其他正文部分，这些正文部分在invite对话框的使用上下文中有意义，但与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类型。然而，根据RFC3261，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不得在信息响应中包含与信息包关联的消息正文。与信息包关联的邮件正文只能在信息请求中发送。
A UA MAY include a message body that is not associated with an Info Package in an INFO response.
UA可以包括与信息响应中的信息包不关联的消息体。
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]来检测信息请求是否按顺序接收。
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.
信息包规范定义了与信息包关联的信息消息中携带的信息的内容和语义。信息包机制为UAs提供了一种方式，以指示他们愿意接收哪些信息包的信息请求，以及特定信息请求与哪个信息包相关联。
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如何处理信息包，UA如何使用Recv Info header字段，以及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 header字段指示其愿意接收特定会话信息请求的信息包集。UA可以在单个Recv信息头字段中列出多个信息包，UA可以使用多个Recv信息头字段。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提供一组信息包，在对话建立期间，UA愿意接收这些信息包的信息请求。UA可以在invite对话框使用期间更新信息包集。
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不愿意在对话框建立期间或之后的邀请对话框使用期间接收任何信息包的信息请求，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信息头字段中指示信息包“foo”和“bar”，并且UA在invite对话框使用期间希望指示它不想再接收任何信息包的信息请求，UA将发送一条带有空Recv信息头字段的消息。
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表示愿意接收特定信息包的信息请求，并且建立了对话，UA必须准备接收与该信息包相关的信息请求，直到UA表示不再愿意接收与该信息包相关的信息请求为止。
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愿意接收该信息的信息请求的指示
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不再愿意接收与该信息包相关联的信息请求的指示之后。
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愿意接收信息请求的一组新信息包时，远程UA可能会在收到该消息之前，基于旧信息包组发送信息请求。在这种情况下，信息请求的接收者拒绝并向信息请求发送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指示提供类似功能的多个信息包，则无法指示信息包的优先级顺序，或指示UA希望仅接收其中一个信息包的信息请求。在这种情况下，由与信息包相关联的应用程序逻辑以及特定的信息包规范来描述应用程序的行为。
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表示支持信息包机制，也仍然允许启用遗留信息使用。此外，如果UA使用Allow header字段[RFC3261]表示支持INFO方法，则它不会隐式表示支持INFO包机制。UA必须使用Recv Info header字段，以表明其支持信息包机制。同样，即使UA使用Recv Info header字段表示支持信息包机制，此外，UA仍然使用Allow header表示支持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 header字段，即使发件人不愿意接收与任何信息包关联的信息请求。
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.
o 包含Recv Info header字段的请求的接收方必须在对请求的可靠18x/2xx响应中包含Recv Info header字段，即使请求包含空的Recv Info header字段，并且即使接收方的header字段值自上次发送Recv Info header字段以来未发生更改。
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.
o 如果相关请求不包含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应答一样，接收方可以在同一邀请/再邀请事务的多个响应（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 header字段的请求的接收者拒绝该请求，则该请求的发送者和接收者都必须回滚到发送该请求之前使用的信息包集。这也适用于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在注册请求中插入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.
建议使用更合适的机制，例如基于RFC 3840[RFC3840]，而不是使用Recv Info header字段来确定请求目标。但是，本文档没有为信息包机制定义功能标签，也没有为特定信息包定义功能标签的机制。
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
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后重试-404413480486后重试o 500503后重试o路由R o安全客户端R o安全服务器421494 o安全验证R o服务器R o主题R o支持R o支持的2xx o时间戳o到c m（带标签）不支持的420 o用户代理o Via m Warning r o WWW Authenticate 401 m WWW Authenticate 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 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 - - -
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：与信息相关的标题字段
The support and usage of the Info-Package and Recv-Info header fields are not applicable to UAs that only support legacy INFO usages.
信息包和Recv Info header字段的支持和使用不适用于仅支持旧信息使用的UAs。
* Not applicable to INFO requests and responses associated with legacy INFO usages.
* 不适用于与旧版信息使用相关的信息请求和响应。
** 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响应（如果发送）中必须发送到INVITE请求。
*** Mandatory if the associated request contained a Recv-Info header
field.
*** 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节所定义，请求中必须存在“强制”标题字段，并且接收请求的UAS必须理解该字段。
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]中“消息头”元素的定义中。第4节介绍信息包标题字段的用法。
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中指示的信息包类型与信息包标题字段值中的信息包类型进行匹配，需要将信息包标题字段的信息包类型部分的信息包名称部分逐八位字节与Recv Info header字段值的信息包名称部分进行比较。也就是说，信息包名称区分大小写。信息包参数不是比较检查算法的一部分。
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.
本文档将Recv Info添加到SIP消息语法[RFC3261]中元素“消息头”的定义中。第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对话框中使用信息请求的信令是否是用例的适当机制？是因为这是最合理、最恰当的选择，还是仅仅因为“很简单”？为特定用例选择不合适的机制可能会在使用该机制的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.
信息消息不同于许多其他类型的SIP消息，因为它们携带应用程序信息，并且信息消息的大小和速率直接由应用程序决定。这可能会导致应用程序信息流量干扰该基础结构上的其他流量，或在数据速率过高时自行干扰。
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.
对于信息请求，没有默认的限制机制。除了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位置更新，可能会在invite对话框使用期间生成高速率的信息请求。
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.
信息包的设计者和使用它的应用程序需要考虑信息消息的大小和速率对网络和其他业务的影响，因为通常不能保证信息消息将通过端到端的拥塞控制传输协议来承载。即使信息消息通过这样的传输协议发送，下游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字节到32K字节。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方法。使用该机制，UA请求状态信息，例如从设备到应用服务器的键盘按压，或从应用服务器到设备的按键映射图像。
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]为基于订阅的事件执行消除消息上下文歧义的作用。信息包机制使用invite对话框用法为应用程序信息交换提供了类似的功能[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.
虽然信息请求始终是现有邀请对话框用法的一部分，并与现有邀请对话框用法命运相同，但订阅请求创建单独的对话框用法[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.
当订阅/通知消息通过有状态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信令平面的机制，订阅/通知消息可对作为对话路由集的一部分的中间SIP实体施加重大负担，但对在最终用户之间传输的应用程序信息不感兴趣。
The MESSAGE method [RFC3428] defines one-time instant message exchange, typically for sending MIME contents for rendering to the user.
消息方法[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]。在这个模型中，UA知道一个会合点，它可以将HTTP请求定向到该会合点进行信息传输。示例包括SIP请求URI[RFC4240]中检索提示的编码或VoiceXML[W3C.REC-voicexml21-20070619]脚本中提交目标的编码。
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方法所需的RFC 3261中定义的ABNF语法的语法扩展，并添加INFO包和Recv INFO头字段的定义。前面的部分描述了语义。本规范中定义的ABNF符合RFC 5234[RFC5234]。
INFOm = %x49.4E.46.4F ; INFO in caps
Method =/ INFOm
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
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.
信息包规范必须包含信息包的总体描述：与信息包相关联的信息请求中携带的信息类型，以及UAs可以使用信息包的应用程序和功能类型。
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.
如果信息包是为特定应用程序定义的，则信息包规范必须说明哪些应用程序UAs可以使用该信息包。
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.
信息包规范必须定义一个信息包名称，UAs将其用作头字段值（例如，“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或信息包标题字段（见第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 header字段、仅适用于Info Package header字段，还是同时适用于两者。
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类型与信息包相关联，则信息包规范必须定义UAs是否需要使用多部分正文部分，以便在单个信息请求中包含多个正文部分。
If there are restrictions on how UAs can use an Info Package, the Info Package specification MUST document such restrictions.
如果UAs如何使用信息包存在限制，则信息包规范必须记录此类限制。
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.
对于是否允许UA发送与信息包关联的重叠（未完成）信息请求，或者UA是否必须等待与同一信息包关联的先前信息请求的响应，可能存在一些限制。
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.
还可能存在与UAs在使用信息包时是否需要支持和使用其他SIP扩展和功能相关的限制，以及与UAs如何将信息包与其他信息包一起使用相关的限制。
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节所述，UAs通常会对信息请求发送200（正常）响应。与信息包关联的应用程序逻辑需要处理UAs不遵守与信息包关联的限制的情况。
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.
如果UAs可以在对话框中发送与信息包相关联的信息请求的最大或最小速率，则信息包规范必须记录速率值。
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.
如果费率可能不同，则信息包规范可能定义UAs可用于指示或协商费率的信息包参数。或者，速率信息可以是与信息包相关联的应用程序数据信息的一部分。
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.
如果与信息包关联的信息请求中包含的应用程序信息需要一定级别的安全性，则信息包规范必须描述UAs需要使用的机制，以提供所需的安全性。
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]可能不够，因为中介机构将有权访问有效负载，并且因为在第一个跃点之后，无法确保后续跃点不会以明文转发有效负载。确保应用程序级安全传输的最佳方法是在应用程序级实现安全性。实现这一点的一种方法是使用端到端安全技术，如安全/多用途Internet邮件扩展（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]
方法：信息参考：[RFC2976]
to:
致：
Method: INFO 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: 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]
标题名称：Recv信息压缩格式：（无）参考：[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.
o 信息包名称：信息包名称是区分大小写的标记。此外，IANA不得注册具有相同不区分大小写值的多个信息包名称。
o Reference: A reference to a specification that describes the Info Package.
o 引用：对描述信息包的规范的引用。
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的信息请求。
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: ...
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）响应，其中UAS表示它愿意接收信息包R和T的信息请求。
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: ...
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
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在invite对话框usage中发送更新请求，其中UAC表示（使用空的Recv Info header字段）不愿意接收任何信息包的信息请求。
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: ...
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）响应，其中UAS表示它愿意接收信息包R和T的信息请求。
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: ...
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 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
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扩展有时可以将身体部位有效载荷添加到信息请求中，而不依赖于信息包。在这种情况下，信息包负载被放入一个多部分MIME主体中，该主体具有一个Content Disposition header字段，该字段指示哪个主体部分与信息包相关联。
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: ...
信息sip：alice@pc33.example.comSIP/2.0 Via:SIP/2.0/UDP 192.0.2.2:5060；分支=z9hG4bKnabcdef到：Alice<sip:alice@example.net>;标签=1234567发件人：Bob<sip:bob@example.com>;tag=abcdefg呼叫Id:a84b4c76e66710@pc33.example.comCSeq:314400信息包：foo内容类型：多部分/混合；boundary=“theboundary”内容长度：。。。
--theboundary
Content-Type: application/mumble
...
--theboundary
Content-Type: application/mumble
...
<mumble stuff>
<mumble stuff>
--theboundary Content-Type: application/foo-x Content-Disposition: Info-Package Content-length: 59
--边界内容类型：应用程序/foo-x内容处置：信息包内容长度：59
I am a foo-x message type, and I belong to Info Package foo --theboundary--
我是一个foo-x消息类型，属于信息包foo--theboundary--
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: ...
信息sip：alice@pc33.example.comSIP/2.0 Via:SIP/2.0/UDP 192.0.2.2:5060；分支=z9hG4bKnabcdef到：Alice<sip:alice@example.net>;标签=1234567发件人：Bob<sip:bob@example.com>;tag=abcdefg呼叫Id:a84b4c76e66710@pc33.example.comCSeq:314423信息包：foo内容类型：多部分/混合；boundary=“theboundary”内容处置：信息包内容长度：。。。
--theboundary Content-Type: application/foo-x Content-length: 59
--边界内容类型：应用程序/foo-x内容长度：59
I am a foo-x message type, and I belong to Info Package foo
我是一个foo-x消息类型，我属于信息包foo
<mumble stuff>
<mumble stuff>
--theboundary Content-Type: application/foo-y Content-length: 59
--边界内容类型：应用程序/foo-y内容长度：59
I am a foo-y message type, and I belong to Info Package foo --theboundary--
我是一个foo-y消息类型，属于信息包foo--theboundary--
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.
与信息包关联的身体部位有效载荷可以具有除“信息包”以外的内容处置标题字段值。在这种情况下，主体部分被放入一个多部分MIME主体中，其中包含一个Content Disposition header字段，该字段指示哪个主体部分与信息包关联。
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: ...
信息sip：alice@pc33.example.comSIP/2.0 Via:SIP/2.0/UDP 192.0.2.2:5060；分支=z9hG4bKnabcdef到：Alice<sip:alice@example.net>;标签=1234567发件人：Bob<sip:bob@example.com>;tag=abcdefg呼叫Id:a84b4c76e66710@pc33.example.comCSeq:314423信息包：foo内容类型：多部分/混合；boundary=“theboundary”内容处置：信息包内容长度：。。。
--theboundary Content-Type: application/foo-x Content-Disposition: icon Content-length: 59
--边界内容类型：应用程序/foo-x内容配置：图标内容长度：59
I am a foo-x message type, and I belong to Info Package foo --theboundary--
我是一个foo-x消息类型，属于信息包foo--theboundary--
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.
通过在没有充分社区审查的情况下消除信息消息的多次使用，并通过消除恶意SIP UAs故意发送无关信息请求而混淆另一UA的可能性，我们期望本文档对信息使用的澄清能够提高互联网的安全性。虽然流氓UAs仍然可以发送不相关的信息请求，但该机制使UAs和其他安全设备能够将信息请求与会话协商的信息包相关联。
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）来阻止对内容的访问。这一点尤其重要，因为信息传输可能不是端到端的，而是通过用户可能不信任的SIP代理和背靠背用户代理（B2BUA）。
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请求传输应用程序级别的信息。这意味着信息消息可能需要比底层SIP对话信令更高级别的保护。特别是，如果不保护SIP信令免受窃听或身份验证和否认攻击（例如通过使用TLS传输），则信息请求及其内容也将易受攻击。即使使用SIP/TLS，从UAC到UAS的路径上的任何SIP跃点都可以查看、修改或截获信息请求，就像任何SIP请求一样。这意味着一些应用程序可能需要对信息有效负载进行端到端加密，例如，除了SIP信令本身的逐跳保护之外。由于应用程序规定了所需的安全级别，因此各个信息包必须列举这些要求。无论如何，本文档描述的信息包机制为应用程序数据的安全端到端传输提供了工具。
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.
信息包使用的一个有趣特性是，可以重复使用用于对信息请求进行基于邀请的身份验证的相同摘要质询机制。例如，可以使用完整性身份验证（auth int）的保护质量（qop）值来质询请求及其主体，并防止中间设备修改主体。但是，这假设知道凭据以执行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，“在RFCs中编写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，“语法规范的扩充BNF: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]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“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 56212009年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.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[RFC2976]Donovan，S.，“SIP信息方法”，RFC 29762000年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]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——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）-特定事件通知”，RFC3265，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 34282002年12月。
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4240]Burger，E.，Van Dyke，J.，和A.Spitzer，“具有SIP的基本网络媒体服务”，RFC 42402005年12月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年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 49752007年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 57072010年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，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年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）信息”（2002年12月26日）和Dean Willis编写的“会话启动协议信息方法的打包和协商”（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.
亚当·罗奇、安德斯·克里斯滕森、安德鲁·艾伦、阿伦·阿鲁纳恰拉姆、本·坎贝尔、鲍勃·彭菲尔德、布拉姆·韦堡、布赖恩·斯图克、克里斯·博尔顿、克里斯蒂安·斯特雷迪克、卡伦·詹宁斯、戴尔·沃利、迪安·威利斯、埃里克·雷斯科拉、弗兰克·米勒、冈萨洛·卡马里洛、戈登·贝思、亨利·辛里奇、伊纳基·巴兹·卡斯蒂洛、詹姆斯·杰克逊、詹姆斯·拉弗蒂、杰伦·范贝梅尔、，Joel Halpern、John Elwell、Jonathan Rosenberg、Juha Heinanen、Keith Drage、Kevin Attard Compagno、Manpret Singh、Martin Dolly、Mary Barnes、Michael Procter、Paul Kyzivat、Peili Xu、Peter Blatherwick、Raj Jain、Rayees Khan、Robert Sparks、Roland Jeske、Roni Even、Salvatore Loreto、Sam Ganesan、Sanjay Sinha、Spencer Dawkins、Steve Langstaff、，Sumit Garg和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.
John Elwell和Francois Audet帮助提供QSIG参考资料。此外，Francois Audet为修订后的摘要提供了文本。Keith Drage提供了意见，并在表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.
Adam Roach、Dean Willis、John Elwell和Paul Kyzivat提供了有价值的输入，以整理信息包的消息正文部分用法。
Authors' Addresses
作者地址
Christer Holmberg Ericsson Hirsalantie 11 Jorvas, 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas，02420芬兰
EMail: christer.holmberg@ericsson.com
EMail: christer.holmberg@ericsson.com
Eric W. Burger Georgetown University
埃里克·W·伯格乔治敦大学
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
Hadriel Kaplan Acme Packet 100 Crosby Drive Bedford, MA 01730 USA
美国马萨诸塞州贝德福德克罗斯比大道100号Hadriel Kaplan Acme Package 01730
EMail: hkaplan@acmepacket.com
EMail: hkaplan@acmepacket.com