Network Working Group R. Mahy
Request for Comments: 3911 Airespace
Category: Standards Track D. Petrie
Pingtel
October 2004
Network Working Group R. Mahy
Request for Comments: 3911 Airespace
Category: Standards Track D. Petrie
Pingtel
October 2004
The Session Initiation Protocol (SIP) "Join" Header
会话启动协议（SIP）“加入”头
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call Center Monitoring". Note that definition of these example features is non-normative.
本文档定义了一个用于SIP多方应用程序和呼叫控制的新头。联接头用于将现有SIP对话框与新SIP对话框逻辑联接。此原语可用于启用多种功能，例如：“闯进来”、“应答机式的“消息屏蔽”和“呼叫中心监控”。请注意，这些示例特征的定义是非规范性的。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability of RFC 2804 ("Raven"). . . . . . . . . . . . . 3
4. User Agent Server Behavior: Receiving a Join Header . . . . 4
5. User Agent Client Behavior: Sending a Join header . . . . . 6
6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . 7
7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. The Join Header . . . . . . . . . . . . . . . . . . . 7
7.2. New option tag for Require and Supported headers . . . 8
8. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Join accepted and transitioned to central conference . 9
8.2. Join rejected . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
10.1. Registration of "Join" SIP header. . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability of RFC 2804 ("Raven"). . . . . . . . . . . . . 3
4. User Agent Server Behavior: Receiving a Join Header . . . . 4
5. User Agent Client Behavior: Sending a Join header . . . . . 6
6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . 7
7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. The Join Header . . . . . . . . . . . . . . . . . . . 7
7.2. New option tag for Require and Supported headers . . . 8
8. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Join accepted and transitioned to central conference . 9
8.2. Join rejected . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
10.1. Registration of "Join" SIP header. . . . . . . . . . . 14
10.2. Registration of "join" SIP Option-tag. . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . 15
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
10.2. Registration of "join" SIP Option-tag. . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . 15
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
This document describes a SIP [1] extension header field as part of the SIP multiparty applications architecture framework [12]. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This is especially useful in peer-to-peer call control environments.
本文档描述了SIP[1]扩展头字段，作为SIP多方应用程序体系结构框架[12]的一部分。联接头用于将现有SIP对话框与新SIP对话框逻辑联接。这在对等呼叫控制环境中特别有用。
One use of the "Join" header is to insert a new participant into a multimedia conversation (which may be a two-party call or a SIP conference [15]). While this functionality is already available using 3rd party call control [17], style call control, the 3pcc model requires a central point of control which may not be desirable in many environments. As such, a method of performing these same call control primitives in a distributed, peer-to-peer fashion is very desirable.
“加入”头的一个用途是将新参与者插入多媒体对话（可能是双方通话或SIP会议[15]）。虽然使用第三方呼叫控制[17]样式的呼叫控制已经可以使用此功能，但3pcc模型需要一个中心控制点，这在许多环境中可能并不理想。因此，以分布式对等方式执行这些相同的呼叫控制原语的方法是非常可取的。
Use of an explicit Join header is needed in some cases instead of addressing an INVITE to a conference URI for the following reasons:
在某些情况下，需要使用显式连接头，而不是寻址会议URI的邀请，原因如下：
o A conference may not yet exist--the new invitation may be trying to join an ordinary two-party call.
o 会议可能还不存在——新的邀请可能试图加入一个普通的两党电话会议。
o The party joining may not know if the dialog it wants to join is part of a conference.
o 参与方可能不知道它想要加入的对话是否是会议的一部分。
o The party joining may not know the conference URI.
o 加入方可能不知道会议URI。
The Join header enables services such as barge-in, real-time message screening, and call center monitoring in a distributed peer-to-peer way. This list of services is not exhaustive.
Join header以分布式点对点的方式启用诸如驳入、实时消息筛选和呼叫中心监控等服务。此服务列表并非详尽无遗。
For example, the Boss has an established 2-party conversation with a Customer, and using some out-of-band mechanism (e.g., voice, gestures, or email) asks an Assistant to join the conversation. The Assistant sends an INVITE with a Join header to the Boss with the dialog information for the established dialog. The Assistant obtained this information from some other mechanism, for example a web-page, an instant message, or from the SIP session dialog package [13].
例如，老板与客户进行了既定的两方对话，并使用一些带外机制（如语音、手势或电子邮件）要求助手加入对话。助手向Boss发送带有连接头的邀请，其中包含已建立对话框的对话框信息。助手从其他一些机制（例如网页、即时消息或SIP会话对话框包）获得该信息[13]。
Assistant Boss Customer
| callid: 4@A | callid: 7@c |
| | |
| |<============>|
| | |
|INVITE------>| |
|Join: 7@c | |
| |reINVITE----->|
|<----200-----|<----200------|
|-----ACK---->|<----ACK------|
| | |
| .. begins mixing .. |
| | |
|<===========>|<============>|
|<::::::::::::::::::::::::::>|
Assistant Boss Customer
| callid: 4@A | callid: 7@c |
| | |
| |<============>|
| | |
|INVITE------>| |
|Join: 7@c | |
| |reINVITE----->|
|<----200-----|<----200------|
|-----ACK---->|<----ACK------|
| | |
| .. begins mixing .. |
| | |
|<===========>|<============>|
|<::::::::::::::::::::::::::>|
Note that this operation effectively creates a new conference. The Boss needs to cause a new conference to start (and consequently create or obtain a new conference URI). In our example, the Boss mixes all media locally, so it needs to generate a new conference URI, return the conference URI as the Contact to the Join INVITE (with the "isfocus" Contact header field parameter as defined in [6], and reINVITE or UPDATE [22] the Customer with the conference URI as the new Contact. This scenario is also discussed in more detail in [16].
请注意，此操作有效地创建了一个新会议。Boss需要启动一个新的会议（从而创建或获取一个新的会议URI）。在我们的示例中，Boss在本地混合所有媒体，因此它需要生成一个新的会议URI，将会议URI作为联系人返回加入邀请（使用[6]中定义的“isfocus”联系人标头字段参数），并重新邀请或更新[22]将会议URI作为新联系人的客户。此场景也将在[16]中进行更详细的讨论。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
This document refers frequently to the terms "confirmed dialog" and "early dialog". These are defined in Section 12 of SIP [1].
本文件经常提及术语“确认对话”和“早期对话”。这些在SIP[1]第12节中定义。
This primitive can be used to create services which are used for monitoring purposes, however these services do not meet the definition of a wiretap according to RFC 2804 [14]. The definition from RFC 2804 is included here:
该原语可用于创建用于监控目的的服务，但这些服务不符合RFC 2804[14]中的窃听定义。RFC 2804中的定义包含在此处：
Wiretapping is what occurs when information passed across the Internet from one party to one or more other parties is delivered to a third party:
当通过互联网从一方传递给另一方或多方的信息被传递给第三方时，就会发生窃听：
1. Without the sending party knowing about the third party
1. 发送方不知道第三方的情况下
2. Without any of the recipient parties knowing about the delivery to the third party
2. 在任何接收方不知道向第三方交付的情况下
3. When the normal expectation of the sender is that the transmitted information will only be seen by the recipient parties or parties obliged to keep the information in confidence
3. 当发送方的正常期望是传输的信息只能被接收方或有义务保密的各方看到时
4. When the third party acts deliberately to target the transmission of the first party, either because he is of interest, or because the second party's reception is of interest.
4. 当第三方故意以第一方的传输为目标，或者因为他感兴趣，或者因为第二方的接收感兴趣。
Specifically, item 2 of this definition does not apply to this extension, as one party is always aware of a Join request and can even decline such requests. In addition, in many applications of this primitive, some or all of the other items may not apply. For example, in many call centers which handle financial transactions, all conversations are recorded with the full knowledge and expectation of all parties involved.
具体而言，此定义的第2项不适用于此扩展，因为一方始终知道加入请求，甚至可以拒绝此类请求。此外，在该原语的许多应用程序中，某些或所有其他项可能不适用。例如，在许多处理金融交易的呼叫中心，所有对话都是在所有相关方充分了解和期望的情况下进行记录的。
The Join header contains information used to match an existing SIP dialog (call-id, to-tag, and from-tag). Upon receiving an INVITE with a Join header, the UA attempts to match this information with a confirmed or early dialog. The to-tag and from-tag parameters are matched as if they were tags present in an incoming request. In other words the to-tag parameter is compared to the local tag, and the from-tag parameter is compared to the remote tag.
联接头包含用于匹配现有SIP对话框（调用id、to标记和from标记）的信息。收到带有加入头的邀请后，UA会尝试将此信息与已确认的或早期的对话框相匹配。to标记和from标记参数被匹配，就像它们是传入请求中存在的标记一样。换句话说，to-tag参数与本地标记进行比较，from-tag参数与远程标记进行比较。
If more than one Join header field is present in an INVITE, or if a Join header field is present in a request other than INVITE, the UAS MUST reject the request with a 400 Bad Request response.
如果INVITE中存在多个Join header字段，或者如果INVITE以外的请求中存在Join header字段，UAS必须以400错误请求响应拒绝该请求。
The Join header has specific call control semantics. If both a Join header field and another header field with contradictory semantics (for example a Replaces [8] header field) are present in a request, the request MUST be rejected with a 400 "Bad Request" response.
联接头具有特定的调用控制语义。如果请求中同时存在一个连接头字段和另一个语义矛盾的头字段（例如替换[8]头字段），则必须以400“错误请求”响应拒绝该请求。
If the Join header field matches more than one dialog, the UA MUST act as if no match is found.
如果Join header字段与多个对话框匹配，则UA必须表现为未找到匹配项。
If no match is found, but the Request-URI in the INVITE corresponds to a conference URI, the UAS MUST ignore the Join header and continue processing the INVITE as if the Join header did not exist. This allows User Agents which receive an INVITE with Join to redirect the request directly to a conference URI.
如果未找到匹配项，但INVITE中的请求URI对应于会议URI，UAS必须忽略Join头并继续处理INVITE，就像Join头不存在一样。这允许使用Join接收INVITE的用户代理将请求直接重定向到会议URI。
Otherwise if no match is found, the UAS rejects the INVITE and returns a 481 Call/Transaction Does Not Exist response. Likewise, if the Join header field matches a dialog which was not created with an INVITE, the UAS MUST reject the request with a 481 response.
否则，如果未找到匹配项，UAS将拒绝邀请并返回481呼叫/事务不存在响应。同样，如果Join header字段与未使用INVITE创建的对话框匹配，UAS必须使用481响应拒绝该请求。
If the Join header field matches a dialog which has already terminated, the UA SHOULD decline the request with a 603 Declined response.
如果Join header字段与已终止的对话框匹配，UA应使用603拒绝响应拒绝请求。
If the Join header field matches an active dialog (n.b. unlike the Replaces header, the Join header has no limitation on its use with early dialogs), the UA MUST verify that the initiator of the new INVITE is authorized to join the matched dialog. If the initiator of the new INVITE has authenticated successfully as equivalent to the user who is being joined, then the join is authorized. For example, if the user being joined and the initiator of the joining dialog share the same credentials for Digest authentication [4], or they sign the join request with S/MIME [5] with the same private key and present the (same) corresponding certificate used in the original dialog, then the join is authorized.
如果Join header字段与活动对话框匹配（注意：与Replaces header不同，Join header不限制其与早期对话框的使用），UA必须验证新邀请的发起人是否有权加入匹配的对话框。如果新邀请的发起人已成功验证为与正在加入的用户等效，则该加入将被授权。例如，如果正在加入的用户和加入对话框的发起人共享相同的摘要身份验证凭据[4]，或者他们使用相同的私钥使用S/MIME[5]签署加入请求，并提供原始对话框中使用的（相同）相应证书，则加入被授权。
Alternatively, the Referred-By mechanism [9] defines a mechanism that the UAS can use to verify that a join request was sent on behalf of the other participant in the matched dialog (in this case, triggered by a REFER request). If the join request contains a Referred-By header which corresponds to the user being joined, the UA SHOULD treat the join as if it was authorized by the joined party. The Referred-By header MUST reference a corresponding, valid Refererred-By Authenticated Identity Body [10]. The UA MAY apply other local policy to authorize the remainder of the request. In other words, the UAS may apply different policy to the joined dialog than was applied to the target dialog.
或者，refered By机制[9]定义了一种机制，UAS可以使用该机制来验证是否代表匹配对话框中的其他参与者发送了加入请求（在这种情况下，由refered请求触发）。如果加入请求包含与被加入的用户相对应的Referenced By标头，UA应将加入视为已被加入方授权的加入。Referred By标头必须引用一个相应的、有效的Referred By Authenticated Identity Body[10]。UA可以应用其他本地策略来授权请求的其余部分。换言之，UAS可以将不同的策略应用于已加入的对话框，而不是应用于目标对话框。
The UA MAY also maintain a list of authorized entities who are allowed to join any dialog with certain characteristics (for example, all dialogs placed in the call center context of the UA). In addition, the UA MAY use other authorization mechanisms defined for this purpose in standards track extensions. For example, an extension could define a mechanism for transitively asserting authorization of a join.
UA还可以维护授权实体的列表，允许这些实体加入具有特定特征的任何对话（例如，UA呼叫中心上下文中的所有对话）。此外，UA可以使用标准跟踪扩展中为此目的定义的其他授权机制。例如，扩展可以定义一种机制，用于传递地断言连接的授权。
If authorization is successful, the UA attempts to accept the new INVITE, and assign any mixing or conferencing resources necessary to complete the join. If the UA cannot accept the new INVITE (for example: it cannot establish required QoS or keying, or it has incompatible media), the UA MUST return an appropriate error response and MUST leave the matched dialog unchanged.
如果授权成功，UA将尝试接受新邀请，并分配完成加入所需的任何混合或会议资源。如果UA不能接受新的邀请（例如：它不能建立所需的QoS或密钥，或者它有不兼容的媒体），UA必须返回适当的错误响应，并且必须保持匹配的对话框不变。
A User Agent that accepts a Join header needs to setup dialogs or conferences such that the requesting UAC is logically added to the conversation space associated with the matched dialog. Any dialogs which are already logically associated with the matched dialog in the same conversation space are included as well. For a detailed description of various conferencing mechanisms that could be used to handle a Join, please consult the SIP conferencing framework [15].
接受连接头的用户代理需要设置对话框或会议，以便将请求的UAC逻辑地添加到与匹配的对话框关联的对话空间中。还包括在同一对话空间中已与匹配对话框逻辑关联的任何对话框。有关可用于处理加入的各种会议机制的详细说明，请参阅SIP会议框架[15]。
If the UAS has sufficient resources to locally handle the Join request, the UAS SHOULD accept the Join request and perform the appropriate media mixing or combining. The UAS MAY rearrange appropriate dialogs instead as described below, based on some local policy.
如果UAS有足够的资源在本地处理加入请求，则UAS应接受加入请求并执行适当的媒体混合或组合。UAS可以根据某些本地策略，按照如下所述重新安排适当的对话框。
If the UAS does not have sufficient resources locally to handle the request, or does not wish to use these local resources, but is aware of other resources which could be used to satisfy the request (e.g., a centralized conference server), the UA SHOULD create a conference using this resource (e.g., INVITE the conference server to obtain a conference URI), redirect the requestor to this resource, and request other participants in the same conversation space to use this resource. The UA MAY use any appropriate mechanism to transition participants to the new resource (e.g., 3xx response, 3rd-party call control reinvitiations, REFER requests, or reinvitations to a multicast group). The UA SHOULD only use mechanisms which are expected to be acceptable to the other participants. For example, the UA SHOULD NOT attempt to transition the participants to a multicast group unless the UA can reasonably expect that all the participants can support multicast.
如果UAS在本地没有足够的资源来处理请求，或者不希望使用这些本地资源，但知道可用于满足请求的其他资源（例如，集中式会议服务器），则UA应使用该资源创建会议（例如，邀请会议服务器获取会议URI），将请求者重定向到此资源，并请求同一会话空间中的其他参与者使用此资源。UA可以使用任何适当的机制将参与者转移到新资源（例如，3xx响应、第三方呼叫控制恢复、参考请求或多播组恢复）。UA应仅使用预期其他参与者可接受的机制。例如，UA不应尝试将参与者转换为多播组，除非UA可以合理预期所有参与者都可以支持多播。
If the UAS is incapable of satisfying the Join request, it MUST return a 488 "Not Acceptable Here" response.
如果UAS无法满足加入请求，则必须返回488“此处不可接受”响应。
A User Agent that wishes to add a new dialog of its own to a single existing early or confirmed dialog and any associated dialogs or conferences, MAY send the target User Agent an INVITE request containing a Join header field. The UAC places the Call-ID, to-tag, and from-tag information for the target dialog in a single Join header field and sends the new INVITE to the target.
希望将自己的新对话框添加到单个现有早期或已确认对话框以及任何关联对话框或会议的用户代理可以向目标用户代理发送包含加入标头字段的INVITE请求。UAC将目标对话框的Call ID、to标记和from标记信息放在一个Join头字段中，并向目标发送新的INVITE。
If the User Agent receives a 300-class response, and acts on this response by sending an INVITE to a Contact in the response, this redirected INVITE MUST contain the same Join header which was present in the original request. Although this is unusual, this allows INVITE requests with a Join header to be redirected before reaching the target UAS.
如果用户代理收到300类响应，并通过向响应中的联系人发送邀请对此响应进行操作，则此重定向的邀请必须包含原始请求中存在的相同加入标头。尽管这是不寻常的，但这允许在到达目标UAS之前重定向带有连接头的INVITE请求。
Note that use of the Join mechanism does not provide a way to match multiple dialogs, nor does it provide a way to match an entire call, an entire transaction, or to follow a chain of proxy forking logic.
注意，连接机制的使用并没有提供匹配多个对话框的方法，也没有提供匹配整个调用、整个事务或遵循代理分叉逻辑链的方法。
Proxy Servers do not require any new behavior to support this extension. They simply pass the Join header field transparently as described in the SIP specification.
代理服务器不需要任何新的行为来支持此扩展。它们只是像SIP规范中描述的那样透明地传递连接头字段。
Note that it is possible for a proxy (especially when forking based on some application layer logic, such as caller screening or time-of-day routing) to forward an INVITE request containing a Join header field to a completely orthogonal set of Contacts than the original request it was intended to replace. In this case, the INVITE request with the Join header field will fail.
请注意，代理（特别是在基于某些应用层逻辑（如呼叫方筛选或时间路由）进行分叉时）可以将包含连接头字段的INVITE请求转发到一组完全正交的联系人，而不是它要替换的原始请求。在这种情况下，带有Join header字段的INVITE请求将失败。
The Join header field indicates that a new dialog (created by the INVITE in which the Join header field in contained) should be joined with a dialog identified by the header field, and any associated dialogs or conferences. It is a request header only, and defined only for INVITE requests. The Join header field MAY be encrypted as part of end-to-end encryption. Only a single Join header field value may be present in a SIP request
Join header字段表示新对话框（由包含Join header字段的INVITE创建）应与由header字段标识的对话框以及任何关联的对话框或会议连接。它只是一个请求头，仅为INVITE请求定义。连接头字段可以作为端到端加密的一部分进行加密。SIP请求中只能存在一个联接头字段值
This document adds the following entry to Table 3 of [1]. Additions to this table are also provided for extension methods defined at the time of publication of this document. This is provided as a courtesy to the reader and is not normative in any way. MESSAGE, SUBSCRIBE and NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined respectively in [19], [20], [7], [21], [22], [23], and [24].
本文件将以下条目添加到[1]的表3中。本表还提供了本文件发布时定义的扩展方法的补充内容。这是出于对读者的礼貌，在任何方面都不规范。[19]、[20]、[7]、[21]、[22]、[23]和[24]分别定义了消息、订阅和通知、参考、信息、更新、PRACK和发布。
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
Join R - - - o - - -
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
Join R - - - o - - -
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
Join R - - - - - - -
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
Join R - - - - - - -
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 2234 [3].
以下语法规范使用RFC 2234[3]中所述的增广巴科斯诺尔形式（BNF）。
Join = "Join" HCOLON callid *(SEMI join-param)
join-param = to-tag / from-tag / generic-param
to-tag = "to-tag" EQUAL token
from-tag = "from-tag" EQUAL token
Join = "Join" HCOLON callid *(SEMI join-param)
join-param = to-tag / from-tag / generic-param
to-tag = "to-tag" EQUAL token
from-tag = "from-tag" EQUAL token
A Join header MUST contain exactly one to-tag and exactly one from-tag, as they are required for unique dialog matching. For compatibility with dialogs initiated by RFC 2543 [11] compliant UAs, a to-tag of zero matches both a to-tag value of zero and a null to-tag. Likewise, a from-tag of zero matches both a to-tag value of zero and a null from-tag.
联接头必须正好包含一个to标记和一个from标记，因为它们是唯一对话框匹配所必需的。为了与符合RFC 2543[11]的UAs启动的对话框兼容，零的to标记与零的to标记值和null to标记值匹配。同样，from标记为零与to标记值为零和null from标记匹配。
Examples:
示例：
Join: 98732@sip.example.com
;from-tag=r33th4x0r
;to-tag=ff87ff
Join: 98732@sip.example.com
;from-tag=r33th4x0r
;to-tag=ff87ff
Join: 12adf2f34456gs5;to-tag=12345;from-tag=54321
Join: 12adf2f34456gs5;to-tag=12345;from-tag=54321
Join: 87134@192.0.2.23;to-tag=24796;from-tag=0
Join: 87134@192.0.2.23;to-tag=24796;from-tag=0
This specification defines a new Require/Supported header option tag "join". UAs which support the Join header MUST include the "join" option tag in a Supported header field. UAs that want explicit failure notification if Join is not supported MAY include the "join" option in a Require header field.
本规范定义了一个新的Require/Supported标题选项标记“join”。支持联接标头的UAs必须在支持的标头字段中包含“联接”选项标记。如果不支持联接，则需要显式故障通知的UAs可能会在Require头字段中包含“Join”选项。
Example:
例子：
Require: join, 100rel
要求：加入，100rel
The following non-normative examples are not intended to enumerate all the possibilities for the usage of this extension, but rather to provide examples or ideas only. For more examples, please see service-examples [18].
以下非规范性示例并非旨在列举使用此扩展的所有可能性，而是仅提供示例或想法。有关更多示例，请参阅服务示例[18]。
A B C conf
| | callid: 7@c | |
| | | |
| |<-INVITE------| | *1
| |-----200----->| | *2
| |<----ACK------| | *3
| |<============>| |
| | | |
|INVITE------>| | | *4
|Join: 7@c |--INVITE-------------------->| *5
| |<----200---------------------| *6
| |-----ACK-------------------->|
|<----302-----| | | *7
|-----ACK---->| | |
|INVITE------------------------------------>| *8
|<--200-------------------------------------| *9
|---ACK------------------------------------>|
| |--REFER------>| | *10
| |<---202-------| |
| |<--NOTIFY-----|--INVITE-*11->|
| |------200---->|<----200-*12--|
| |<--NOTIFY-----|-----ACK----->|
| |------200---->| |
| |---BYE------->| |
| |<--200--------| |
| | | |
|<=========================================>| mixes the
| |<===========================>| three sessions
| | |<============>| together
A B C conf
| | callid: 7@c | |
| | | |
| |<-INVITE------| | *1
| |-----200----->| | *2
| |<----ACK------| | *3
| |<============>| |
| | | |
|INVITE------>| | | *4
|Join: 7@c |--INVITE-------------------->| *5
| |<----200---------------------| *6
| |-----ACK-------------------->|
|<----302-----| | | *7
|-----ACK---->| | |
|INVITE------------------------------------>| *8
|<--200-------------------------------------| *9
|---ACK------------------------------------>|
| |--REFER------>| | *10
| |<---202-------| |
| |<--NOTIFY-----|--INVITE-*11->|
| |------200---->|<----200-*12--|
| |<--NOTIFY-----|-----ACK----->|
| |------200---->| |
| |---BYE------->| |
| |<--200--------| |
| | | |
|<=========================================>| mixes the
| |<===========================>| three sessions
| | |<============>| together
The conversation now appears identical to the locally mixed one from the example in the Introduction. Details of how the Join are implemented are transparent to A. B could have used 3rd party call control instead to move the necessary sessions.
现在，对话看起来与引言中示例中的本地混合对话完全相同。如何实现连接的细节对A是透明的。B可以使用第三方呼叫控制来移动必要的会话。
Message *1: C -> B
Message *1: C -> B
INVITE sip:bob@example.org SIP/2.0
To: <bob@example.org>
From: <carol@example.org>;tag=xyz
Call-Id: 7@c.example.org
CSeq 1 INVITE
Contact: <sip:carol@c.example.org>
INVITE sip:bob@example.org SIP/2.0
To: <bob@example.org>
From: <carol@example.org>;tag=xyz
Call-Id: 7@c.example.org
CSeq 1 INVITE
Contact: <sip:carol@c.example.org>
Message *2: B -> C
Message *2: B -> C
SIP/2.0 200 OK
To: <bob@example.org>;tag=pdq
From: <carol@example.org>;tag=xyz
Call-Id: 7@c.example.org
CSeq 1 INVITE
Contact: <sip:bob@b.example.org>
SIP/2.0 200 OK
To: <bob@example.org>;tag=pdq
From: <carol@example.org>;tag=xyz
Call-Id: 7@c.example.org
CSeq 1 INVITE
Contact: <sip:bob@b.example.org>
Message *3: C -> B
Message *3: C -> B
ACK sip:carol@c.example.org SIP/2.0
To: <bob@example.org>;tag=pdq
From: <carol@example.org>;tag=xyz
Call-Id: 7@c.example.org
CSeq 1 INVITE
ACK sip:carol@c.example.org SIP/2.0
To: <bob@example.org>;tag=pdq
From: <carol@example.org>;tag=xyz
Call-Id: 7@c.example.org
CSeq 1 INVITE
Message *4: A -> B
Message *4: A -> B
INVITE sip:bob@b.example.org SIP/2.0
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=iii
Call-Id: 777@a.example.org
CSeq: 1 INVITE
Contact: <sip:alice@a.example.org>
Join: 7@c.example.org;to-tag=xyz;from-tag=pdq
INVITE sip:bob@b.example.org SIP/2.0
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=iii
Call-Id: 777@a.example.org
CSeq: 1 INVITE
Contact: <sip:alice@a.example.org>
Join: 7@c.example.org;to-tag=xyz;from-tag=pdq
Message *5: B -> conf
Message *5: B -> conf
INVITE sip:conf-factory@example.org SIP/2.0
To: <sip:conf-factory@example.org>
From: <sip:bob@example.org>;tag=abc
Call-Id: 999@b.example.org
CSeq: 1INVITE
Contact: <sip:bob@b.example.org>
INVITE sip:conf-factory@example.org SIP/2.0
To: <sip:conf-factory@example.org>
From: <sip:bob@example.org>;tag=abc
Call-Id: 999@b.example.org
CSeq: 1INVITE
Contact: <sip:bob@b.example.org>
Message *6: conf -> B
Message *6: conf -> B
SIP/2.0 200 OK
To: <sip:conf-factory@example.org>;tag=def
From: <sip:bob@example.org>;tag=abc
Call-Id: 999@b.example.org
CSeq: 1INVITE
Contact: <sip:conf456@conf-srv2.example.org>;isfocus
SIP/2.0 200 OK
To: <sip:conf-factory@example.org>;tag=def
From: <sip:bob@example.org>;tag=abc
Call-Id: 999@b.example.org
CSeq: 1INVITE
Contact: <sip:conf456@conf-srv2.example.org>;isfocus
Message *7: B -> A
Message *7: B -> A
SIP/2.0 302 Moved Temporarily
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=iii
Call-Id: 777@a.example.org
CSeq: 1 INVITE
Contact: <sip:conf456@conf-srv2.example.org>;isfocus
SIP/2.0 302 Moved Temporarily
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=iii
Call-Id: 777@a.example.org
CSeq: 1 INVITE
Contact: <sip:conf456@conf-srv2.example.org>;isfocus
Message *8: A -> conf
Message *8: A -> conf
INVITE sip:conf456@conf-srv2.example.org SIP/2.0
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=iii
Call-Id: 777@a.example.org
CSeq: 2 INVITE
Contact: <sip:alice@a.example.org>
Join: 7@c.example.org;to-tag=xyz;from-tag=pdq
INVITE sip:conf456@conf-srv2.example.org SIP/2.0
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=iii
Call-Id: 777@a.example.org
CSeq: 2 INVITE
Contact: <sip:alice@a.example.org>
Join: 7@c.example.org;to-tag=xyz;from-tag=pdq
Message *9: conf ->A
Message *9: conf ->A
SIP/2.0 200 OK
To: <sip:bob@example.org>;tag=jjj
From: <sip:alice@example.org>;tag=iii
Call-Id: 777@a.example.org
CSeq: 2 INVITE
Contact: <sip:conf456@conf-srv2.example.org>;isfocus
SIP/2.0 200 OK
To: <sip:bob@example.org>;tag=jjj
From: <sip:alice@example.org>;tag=iii
Call-Id: 777@a.example.org
CSeq: 2 INVITE
Contact: <sip:conf456@conf-srv2.example.org>;isfocus
Message *10: B -> C
Message *10: B -> C
REFER sip:carol@c.example.org SIP/2.0
To: <carol@example.org>;tag=xyz
From: <bob@example.org>;tag=pdq
Call-Id: 7@c.example.org
CSeq: 1 REFER
Contact: <sip:bob@b.example.org>
Refer-To: <sip:conf456@conf-srv2.example.org>
Referred-By: <sip:bob@b.example.org>
REFER sip:carol@c.example.org SIP/2.0
To: <carol@example.org>;tag=xyz
From: <bob@example.org>;tag=pdq
Call-Id: 7@c.example.org
CSeq: 1 REFER
Contact: <sip:bob@b.example.org>
Refer-To: <sip:conf456@conf-srv2.example.org>
Referred-By: <sip:bob@b.example.org>
Message *11: C -> conf
Message *11: C -> conf
INVITE sip:conf456@conf-srv2.example.org SIP/2.0
To: <sip:conf456@conf-srv2.example.org>
From: <carol@example.org>;tag=mmm
INVITE sip:conf456@conf-srv2.example.org SIP/2.0
To: <sip:conf456@conf-srv2.example.org>
From: <carol@example.org>;tag=mmm
Call-Id: 34343@c.example.com
CSeq: 1 INVITE
Contact: <sip:carol@c.example.com>
Referred-By: <sip:bob@b.example.org>
Call-Id: 34343@c.example.com
CSeq: 1 INVITE
Contact: <sip:carol@c.example.com>
Referred-By: <sip:bob@b.example.org>
Message *12: C -> conf
Message *12: C -> conf
SIP/2.0 200 OK
To: <sip:conf456@conf-srv2.example.org>
From: <carol@example.org>;tag=mmm
Call-Id: 34343@c.example.com
CSeq: 1 INVITE
Contact: <sip:conf456@conf-srv2.example.org>;isfocus
Referred-By: <sip:bob@b.example.org>
SIP/2.0 200 OK
To: <sip:conf456@conf-srv2.example.org>
From: <carol@example.org>;tag=mmm
Call-Id: 34343@c.example.com
CSeq: 1 INVITE
Contact: <sip:conf456@conf-srv2.example.org>;isfocus
Referred-By: <sip:bob@b.example.org>
A B C
| | callid: 7@c |
| | |
| |<============>|
| | |
|INVITE------>| *1 |
|Join: 7@c | |
| | |
|<----486-----| *2 |
|-----ACK---->| |
| | |
A B C
| | callid: 7@c |
| | |
| |<============>|
| | |
|INVITE------>| *1 |
|Join: 7@c | |
| | |
|<----486-----| *2 |
|-----ACK---->| |
| | |
In this example B is Busy (does not want to be disturbed), and therefore does not wish to add A. B could also decline the request with a 603 response.
在本例中，B忙（不想被打扰），因此不希望添加A。B也可以使用603响应拒绝请求。
Message *1: A -> B
Message *1: A -> B
INVITE sip:bob@b.example.org SIP/2.0
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=iii
Call-Id: 777@a.example.org
CSeq: 1 INVITE
Contact: <sip:alice@a.example.org>
Join: 7@c.example.org;to-tag=xyz;from-tag=pdq
INVITE sip:bob@b.example.org SIP/2.0
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=iii
Call-Id: 777@a.example.org
CSeq: 1 INVITE
Contact: <sip:alice@a.example.org>
Join: 7@c.example.org;to-tag=xyz;from-tag=pdq
Message *2: B -> A
Message *2: B -> A
SIP/2.0 486 Busy
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=iii
Call-Id: 777@a.example.org
CSeq: 1 INVITE
SIP/2.0 486 Busy
To: <sip:bob@example.org>
From: <sip:alice@example.org>;tag=iii
Call-Id: 777@a.example.org
CSeq: 1 INVITE
The extension specified in this document significantly changes the relative security of SIP devices. Currently in SIP, even if an eavesdropper learns the Call-ID, To, and From headers of a dialog, they cannot easily modify or destroy that dialog if Digest authentication or end-to-end message integrity are used.
本文档中指定的扩展显著改变了SIP设备的相对安全性。目前在SIP中，即使窃听者从对话的标题中了解到呼叫ID、到和，如果使用摘要身份验证或端到端消息完整性，他们也无法轻松修改或破坏该对话。
This extension can be used to insert or monitor potentially sensitive content in a multimedia conversation. As such, invitations with the Join header MUST only be accepted if the peer requesting replacement has been properly authenticated using a standard SIP mechanism (Digest or S/MIME), and authorized to be joined with the target dialog. (All SIP implementations are already required to support Digest Authentication.) Generally authorization for joins are configured as a matter of local policy as long-duration persistent relationships.
此扩展可用于在多媒体对话中插入或监视潜在的敏感内容。因此，只有当请求替换的对等方已使用标准SIP机制（摘要或S/MIME）进行了正确的身份验证，并且被授权与目标对话框连接时，才必须接受带有连接头的邀请。（所有SIP实现都已经需要支持摘要身份验证。）通常，连接的授权被配置为本地策略的一部分，作为长持续时间的持久关系。
For example, the UAs used by call center agents might be configured with a list of identities who could join their calls (supervisors and any call center monitoring User Agents). Alternatively the call center agents might rely on transitive authorization assertions from a (shorter) list of authorized hosts (e.g., a certificate authority). For answering-machine-style message screening this is even easier. Presumably the user screening their messages already has some credentials with their messaging server.
例如，呼叫中心代理使用的UAs可能配置有可以加入其呼叫的身份列表（主管和任何呼叫中心监控用户代理）。或者，呼叫中心代理可能依赖于来自授权主机（例如，证书颁发机构）的（较短的）列表的可传递授权断言。对于电话答录机式的信息筛选，这更容易。可能筛选消息的用户已经在消息服务器上拥有一些凭据。
Some mechanisms for obtaining the dialog information needed by the Join header (Call-ID, to-tag, and from-tag) include URIs on a web page, subscriptions to an appropriate event package, and notifications after a REFER request. Use of end-to-end security mechanisms to integrity protect and encrypt this information is also RECOMMENDED.
获取联接头所需的对话框信息（调用ID、to标记和from标记）的一些机制包括网页上的URI、对适当事件包的订阅以及REFER请求后的通知。还建议使用端到端安全机制来完整性保护和加密此信息。
This extension was designed to take advantage of future signature or authorization schemes defined by standards track extensions. In general, call control features would benefit considerably from such work.
此扩展旨在利用标准跟踪扩展定义的未来签名或授权方案。一般来说，呼叫控制功能将从这类工作中受益匪浅。
Section 4 describes specific mechanisms for authorization using Digest Authentication and S/MIME (RFC 3261) and Referred-by [9], the currently available capabilities in SIP.
第4节描述了使用摘要身份验证和S/MIME（RFC 3261）进行授权的具体机制，并在[9]中提到了SIP中当前可用的功能。
Name of Header: Join
标题名称：Join
Short form: none
简表：无
Normative description: section 7.1 of this document
规范性说明：本文件第7.1节
Name of option: join
选项名称：加入
Description: Support for the SIP Join header
描述：支持SIP连接头
SIP headers defined: Join
定义的SIP头：Join
Normative description: This document
规范性说明：本文件
Thanks to Robert Sparks, Alan Johnston, and Ben Campbell and many other members of the SIP WG for their continued support of the cause of distributed call control in SIP.
感谢Robert Sparks、Alan Johnston和Ben Campbell以及SIP工作组的许多其他成员对SIP中分布式呼叫控制事业的持续支持。
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[4] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[5] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[5] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[6] Rosenberg, J., "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[6] Rosenberg，J.，“指出会话启动协议（SIP）中的用户代理功能”，RFC3840，2004年8月。
[7] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[7] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[8] Dean, R., Biggs, B., and R. Mahy, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[8] Dean，R.，Biggs，B.，和R.Mahy，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”。
[9] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004.
[9] Sparks，R.，“机制引用的会话启动协议（SIP）”，RFC 38922004年9月。
[10] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[10] Peterson，J.，“会话发起协议（SIP）认证身份主体（AIB）格式”，RFC 3893，2004年9月。
[11] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[11] Handley，M.，Schulzrinne，H.，Schooler，E.，和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[12] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[12] Mahy，R.，“会话启动协议（SIP）的呼叫控制和多方使用框架”，正在进行的工作，2003年3月。
[13] Rosenberg, J. and H. Schulzrinne, "An INVITE Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", Work in Progress, March 2003.
[13] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）的邀请启动对话事件包”，正在进行的工作，2003年3月。
[14] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[14] IAB和IESG，“IETF关于窃听的政策”，RFC 2804，2000年5月。
[15] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", Work in Progress, May 2003.
[15] Rosenberg，J.，“使用会话启动协议的会议框架”，正在进行的工作，2003年5月。
[16] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", Work in Progress, April 2003.
[16] Johnston，A.和O.Levin，“会话发起协议呼叫控制-用户代理会议”，正在进行的工作，2003年4月。
[17] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[17] Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，BCP 85，RFC 37252004年4月。
[18] Johnston, A. and S. Donovan, "Session Initiation Protocol Service Examples", Work in Progress, March 2003.
[18] Johnston，A.和S.Donovan，“会话启动协议服务示例”，正在进行的工作，2003年3月。
[19] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[19] Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[20] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[20] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[21] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[21] Donovan，S.，“SIP信息方法”，RFC 29762000年10月。
[22] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[22] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
[23] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[23] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）中临时响应的可靠性”，RFC 3262，2002年6月。
[24] Campbell, B., "SIMPLE Presence Publication Mechanism", Work in Progress, February 2003.
[24] 坎贝尔，B.，“简单存在-发布机制”，正在进行的工作，2003年2月。
Rohan Mahy Airespace 110 Nortech Parkway San Jose, CA 95134 USA
美国加利福尼亚州圣何塞Nortech Parkway 110 Rohan Mahy Airespace，邮编95134
EMail: rohan@airespace.com
EMail: rohan@airespace.com
Dan Petrie Pingtel 400 West Cummings Park, Suite 2200 Woburn, MA 01801 USA
Dan Petrie Pingtel美国马萨诸塞州沃本市西卡明斯公园400号2200室01801
EMail: dpetrie@pingtel.com
EMail: dpetrie@pingtel.com
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。