Internet Engineering Task Force (IETF) R. Sparks
Request for Comments: 7614 Oracle
Category: Standards Track August 2015
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Sparks
Request for Comments: 7614 Oracle
Category: Standards Track August 2015
ISSN: 2070-1721
Explicit Subscriptions for the REFER Method
引用方法的显式订阅
Abstract
摘要
The Session Initiation Protocol (SIP) REFER request, as defined by RFC 3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible and complicates avoiding SIP dialog sharing. This document defines extensions to REFER that remove the implicit subscription and, if desired, replace it with an explicit one.
RFC3515定义的会话发起协议（SIP）REFER请求触发隐式SIP特定事件通知框架订阅。将订阅的开始与处理REFER请求混为一谈会使协商订阅扩展变得不可能，并使避免SIP对话共享变得复杂。本文档定义了要引用的扩展，这些扩展将删除隐式订阅，如果需要，将其替换为显式订阅。
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/rfc7614.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7614.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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
2. Conventions .....................................................3
3. Overview ........................................................4
3.1. Explicit Subscriptions .....................................4
3.2. No Subscriptions ...........................................5
4. The Explicit Subscription Extension .............................5
4.1. Sending a REFER ............................................5
4.2. Processing a REFER Response ................................5
4.3. Processing a Received REFER ................................6
4.4. Subscribing to the 'refer' Event ...........................7
4.5. Processing a Received SUBSCRIBE ............................7
4.6. Sending a NOTIFY ...........................................7
4.7. Managing 'refer' Event State ...............................8
4.8. The Refer-Events-At Header Field ...........................8
5. The No Subscription Extension ...................................9
5.1. Sending a REFER ............................................9
5.2. Processing a REFER Response ................................9
5.3. Processing a Received REFER ................................9
6. The 'explicitsub' and 'nosub' Option Tags ......................10
7. Updates to RFC 3515 ............................................10
8. Security Considerations ........................................10
9. IANA Considerations ............................................12
9.1. Register the 'explicitsub' Option Tag .....................12
9.2. Register the 'nosub' Option Tag ...........................12
9.3. Register the Refer-Events-At Header Field .................12
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................13
Author's Address ..................................................14
1. Introduction ....................................................3
2. Conventions .....................................................3
3. Overview ........................................................4
3.1. Explicit Subscriptions .....................................4
3.2. No Subscriptions ...........................................5
4. The Explicit Subscription Extension .............................5
4.1. Sending a REFER ............................................5
4.2. Processing a REFER Response ................................5
4.3. Processing a Received REFER ................................6
4.4. Subscribing to the 'refer' Event ...........................7
4.5. Processing a Received SUBSCRIBE ............................7
4.6. Sending a NOTIFY ...........................................7
4.7. Managing 'refer' Event State ...............................8
4.8. The Refer-Events-At Header Field ...........................8
5. The No Subscription Extension ...................................9
5.1. Sending a REFER ............................................9
5.2. Processing a REFER Response ................................9
5.3. Processing a Received REFER ................................9
6. The 'explicitsub' and 'nosub' Option Tags ......................10
7. Updates to RFC 3515 ............................................10
8. Security Considerations ........................................10
9. IANA Considerations ............................................12
9.1. Register the 'explicitsub' Option Tag .....................12
9.2. Register the 'nosub' Option Tag ...........................12
9.3. Register the Refer-Events-At Header Field .................12
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................13
Author's Address ..................................................14
REFER, as defined by [RFC3515], triggers an implicit SIP-Specific Event Framework subscription. Sending a REFER within a dialog established by an INVITE results in dialog reuse and the associated problems described in [RFC5057]. The SIP-Specific Event Notification framework definition [RFC6665] disallows such dialog reuse. Call transfer, as defined in [RFC5589], thus requires sending a REFER request on a new dialog, associating it with an existing dialog using the 'Target-Dialog' mechanism defined in [RFC4538].
如[RFC3515]所定义，REFERE触发隐式SIP特定事件框架订阅。在INVITE建立的对话框中发送REFER会导致对话框重用和[RFC5057]中描述的相关问题。特定于SIP的事件通知框架定义[RFC6665]不允许此类对话框重用。因此，[RFC5589]中定义的呼叫转移需要在新对话框上发送REFER请求，并使用[RFC4538]中定义的“目标对话框”机制将其与现有对话框关联。
Because there is no explicit SUBSCRIBE request, the tools for negotiating subscription details are unavailable for REFER subscriptions. This includes negotiating subscription duration and providing information through Event header field parameters. The use of the SIP 'Supported' and 'Require' extension mechanisms [RFC3261] is complicated by the implicit subscription. It is unclear whether or not the extension applies to handling the REFER request itself, to the messages in the subscription created by the REFER, or to both. Avoiding this confusion requires careful specification in each extension. Existing extensions do not provide this clarity.
由于没有明确的订阅请求，因此协商订阅详细信息的工具无法用于引用订阅。这包括协商订阅持续时间和通过事件头字段参数提供信息。SIP“受支持”和“需要”扩展机制[RFC3261]的使用因隐式订阅而变得复杂。目前尚不清楚该扩展是否适用于处理REFER请求本身、REFER创建的订阅中的消息，或者两者都适用。避免这种混淆需要在每个扩展中仔细说明。现有的扩展没有提供这种清晰性。
This document defines two mechanisms that remove the implicit subscription, one of which replaces it with an explicit one. The benefits of doing so include:
本文档定义了两种删除隐式订阅的机制，其中一种机制将其替换为显式订阅。这样做的好处包括：
o Allowing REFER to be used within INVITE-created dialogs without creating dialog reuse.
o 允许在INVITE创建的对话框中使用REFERE，而不创建对话框重用。
o Allowing standard subscription parameter negotiation.
o 允许标准订阅参数协商。
o Allowing standard negotiation of SIP extensions.
o 允许SIP扩展的标准协商。
There are limitations on when it is appropriate to use the extension that allows an explicit subscription, related directly to definition of non-INVITE transaction handling SIP. These limitations are discussed in Section 4.1.
在何时使用允许显式订阅的扩展是合适的，这与非邀请事务处理SIP的定义直接相关。第4.1节讨论了这些限制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section provides a non-normative overview of the behaviors defined in subsequent sections.
本节提供了后续章节中定义的行为的非规范性概述。
A SIP User Agent (UA) that wishes to issue a REFER request that will not create an implicit subscription, but will allow an explicit one, will include a new option tag, 'explicitsub', in the Require header field of the REFER request. This REFER could be sent either within an existing dialog or as an out-of-dialog request.
希望发出不会创建隐式订阅但允许显式订阅的REFER请求的SIP用户代理（UA）将在REFER请求的Require header字段中包含一个新的选项标记“explicitsub”。此引用可以在现有对话框内发送，也可以作为对话框外请求发送。
If the recipient of the REFER accepts the request, it will begin managing the 'refer' event state described in RFC 3515 and will provide a URI that will reach an event server that will service subscriptions to that state. (In many cases, the recipient of the REFER will perform the role of event server itself.) That URI is returned in a new header field in the REFER response named 'Refer-Events-At'.
如果REFER的接收者接受请求，它将开始管理RFC 3515中描述的“REFER”事件状态，并将提供一个URI，该URI将到达将为该状态的订阅提供服务的事件服务器。（在许多情况下，REFER的接收者将执行事件服务器本身的角色。）该URI在名为“REFER Events At”的REFER响应中的新头字段中返回。
The UA that issued the REFER can now subscribe to the 'refer' event at the provided URI, using a SUBSCRIBE request with a new dialog identifier. The full range of negotiation mechanisms is available for its use in that request. As detailed in RFCs 6665 and 3515, the event server accepting the subscription will send an immediate NOTIFY with the current refer event state, additional NOTIFY messages as the refer state changes, and a terminal NOTIFY message when the referred action is complete. It is, of course, possible that the initial NOTIFY is also the terminal NOTIFY.
发出REFER的UA现在可以使用带有新对话框标识符的subscribe请求在提供的URI上订阅“REFER”事件。在该请求中，可以使用各种谈判机制。如RFCs 6665和3515中所述，接受订阅的事件服务器将立即发送带有当前引用事件状态的通知、引用状态更改时的附加通知消息，并在引用操作完成时发送终端通知消息。当然，初始通知也可能是终端通知。
It is possible that the referred action is completed before the SUBSCRIBE arrives at the event server. The server needs to retain the final refer event state for some period of time to include in the terminal NOTIFY that will be sent for such subscriptions. It is also possible that a SUBSCRIBE will never arrive.
引用的操作可能在订阅到达事件服务器之前完成。服务器需要将最终引用事件状态保留一段时间，以便包含在将为此类订阅发送的终端通知中。也有可能永远不会收到订阅。
This extension makes it possible to separate the event server that will handle subscriptions from the UA that accepted the REFER. Such a UA could use mechanisms such as PUBLISH [RFC3903] to convey the refer event state to the event server. This extension also makes it possible to allow more than one subscription to the refer event state.
此扩展使处理订阅的事件服务器与接受引用的UA分离成为可能。这样的UA可以使用诸如发布[RFC3903]之类的机制将引用事件状态传递给事件服务器。此扩展还允许多个订阅引用事件状态。
A UA that wishes to issue a REFER request that will not create an implicit subscription and wishes to tell the recipient that it is not interested in creating an explicit subscription will include a new option tag, 'nosub', in the Require header field of the REFER request. This REFER could be sent either within an existing dialog or as an out-of-dialog request.
如果UA希望发出不会创建隐式订阅的REFER请求，并希望告知收件人其对创建显式订阅不感兴趣，则该UA将在REFER请求的Require header字段中包含一个新选项标记“nosub”。此引用可以在现有对话框内发送，也可以作为对话框外请求发送。
If the recipient of the REFER accepts the request, it knows not to create an implicit subscription and knows that no explicit subscription will be forthcoming. The recipient will continue to process the request indicated in the Refer-To header field as specified in RFC 3515, but it can avoid the cost of preparing to handle any 'refer' event subscriptions related to this REFER request.
如果refere的接收者接受了请求，那么它知道不创建隐式订阅，并且知道不会有显式订阅。收件人将继续处理RFC 3515中指定的引用标头字段中指示的请求，但可以避免准备处理与此引用请求相关的任何“引用”事件订阅的成本。
To suppress the creation of any implicit subscription, and allow for an explicit one, a UA forming a REFER request will include the option tag 'explicitsub' in the Require header field of the request. The REFER request is otherwise formed following the requirements of [RFC3515]. Since this REFER has no chance of creating an implicit subscription, the UA MAY send the REFER request within an existing dialog or out-of-dialog.
为了抑制任何隐式订阅的创建并允许显式订阅，形成REFER请求的UA将在请求的Require header字段中包含选项标记“explicitsub”。参考请求按照[RFC3515]的要求以其他方式形成。由于此REFER没有机会创建隐式订阅，UA可以在现有对话框内或对话框外发送REFER请求。
Note that if the REFER forks (see [RFC3261]), only one final response will be returned to the issuing UA. If it is important that the UA be able to subscribe to any refer state generated by accepting this request, the UA needs to form the request so that it will only be accepted in one place. This can be achieved by sending the REFER request within an existing dialog or by using the 'Target-Dialog' mechanism defined in [RFC4538]. If it is possible for the request to be accepted in more than one location, and things would go wrong if the UA did not learn about each location that the request was accepted, using this extension is not appropriate.
请注意，如果引用forks（请参见[RFC3261]），则只会向发布UA返回一个最终响应。如果UA能够订阅通过接受此请求而生成的任何refer状态很重要，则UA需要形成请求，以便它只在一个地方被接受。这可以通过在现有对话框内发送REFER请求或使用[RFC4538]中定义的“目标对话框”机制来实现。如果请求有可能在多个地点被接受，并且如果UA没有了解到请求被接受的每个地点，事情就会出错，那么使用此扩展是不合适的。
The UA will process responses to the REFER request as specified in [RFC3515] (and, consequently, [RFC3261]). In particular, if the REFER was sent to an element that does not support or is unwilling to use this extension, the response will contain a 420 (Bad Extension) response code (see Section 8.1.3.5 of [RFC3261]). As that document states, the UA can retry the request without using this extension.
UA将按照[RFC3515]（以及[RFC3261]）中的规定处理对REFER请求的响应。特别是，如果REFER被发送到不支持或不愿意使用此扩展的元素，则响应将包含420（错误扩展）响应代码（参见[RFC3261]第8.1.3.5节）。正如该文档所述，UA可以在不使用此扩展的情况下重试请求。
If the UA receives a 2xx-class response, it will contain a Refer-Events-At header field (Section 4.8) with a single URI as its value. If the UA is interested in the state of the referenced action, it will subscribe to the 'refer' event at that URI.
如果UA收到2xx类响应，它将包含一个REFEREVENTS At header字段（第4.8节），其值为一个URI。如果UA对所引用操作的状态感兴趣，它将在该URI订阅“referel”事件。
An element receiving a REFER request requiring the 'explicitsub' extension will use the same admissions policies that are used without the extension, with the addition that it is acceptable to admit an in-dialog REFER request requiring this extension since it cannot create another usage inside that dialog. In particular, see Section 5.2 of [RFC3515].
接收到需要“explicitsub”扩展的REFER请求的元素将使用与未使用扩展的元素相同的接纳策略，此外，允许需要此扩展的对话内REFER请求是可以接受的，因为它无法在该对话内创建其他用法。具体见[RFC3515]第5.2节。
Accepting a REFER request that requires 'explicitsub' does not create a dialog or a new usage within an existing dialog. The element MUST NOT create an implicit subscription when accepting the REFER request.
接受需要“explicitsub”的REFER请求不会在现有对话框中创建对话框或新用法。元素在接受引用请求时不得创建隐式订阅。
If the REFER request was received within an existing dialog, the accepting element will not be acting as a SIP-Events notifier in the context of that dialog. If it is not otherwise subject to becoming a notifier in the context of the dialog, none of the requirements in [RFC6665], particularly the requirement to provide a Globally Routable User Agent URI (GRUU) as the local contact, apply to the message accepting the REFER request.
如果在现有对话框中接收到REFER请求，则接受元素将不会在该对话框的上下文中充当SIP事件通知程序。如果在对话框的上下文中不需要成为通知者，[RFC6665]中的任何要求，特别是提供全局可路由用户代理URI（GRUU）作为本地联系人的要求，都不适用于接受REFER请求的消息。
An element that accepts a REFER request with 'explicitsub' in its Require header field MUST return a 200 response containing a sip: or sips: URI in the Refer-Events-At header field that can be used to subscribe to the refer event state associated with this REFER request. This URI MUST uniquely identify this refer event state. The URI needs to reach the event server when used in a SUBSCRIBE request from the element that sent the REFER. One good way to ensure the URI provided has that property is to use a GRUU [RFC5627] for the event server. As discussed in Section 8, possession of this URI is often the only requirement for authorizing a subscription to it. Implementations SHOULD provide a URI constructed in a way that is hard to guess. Again, using a GRUU (specifically, a temporary GRUU) is one good way to achieve this property.
接受Require标头字段中带有“explicitsub”的REFER请求的元素必须返回200响应，该响应在REFER Events At标头字段中包含sip:或sips:URI，可用于订阅与此REFER请求关联的REFER事件状态。此URI必须唯一标识此引用事件状态。当从发送引用的元素在订阅请求中使用URI时，URI需要到达事件服务器。确保提供的URI具有该属性的一个好方法是为事件服务器使用GRUU[RFC5627]。正如第8节所讨论的，拥有这个URI通常是授权订阅它的唯一要求。实现应该提供一个以难以猜测的方式构造的URI。同样，使用GRUU（特别是临时GRUU）是实现此属性的一个好方法。
The accepting element will otherwise proceed with the processing defined in [RFC3515].
否则，接受元素将继续进行[RFC3515]中定义的处理。
The event server identified by the Refer-Events-At URI could receive SUBSCRIBE requests at any point after the response containing the Refer-Events-At header field is sent. Implementations should take care to ensure the event server is ready to receive those SUBSCRIBE requests before sending the REFER response, but as with all non-
在发送包含refereevents-At-header字段的响应后，由refereevents-At-URI标识的事件服务器可以在任意点接收订阅请求。实现应注意确保事件服务器在发送REFER响应之前准备好接收这些SUBSCRIBE请求，但与所有非事件服务器一样-
INVITE responses, the response should be sent as soon as possible (see [RFC4321]). It is also possible that the referred action may complete before any SUBSCRIBE request arrives. The event server will need to maintain the final refer event state for a period of time after the action completes in order to serve such subscriptions (see Section 4.7).
邀请响应，应尽快发送响应（请参阅[RFC4321]）。还可能在任何订阅请求到达之前完成所引用的操作。事件服务器需要在操作完成后的一段时间内保持最终引用事件状态，以便为此类订阅提供服务（请参见第4.7节）。
A UA that possesses a URI obtained from a Refer-Events-At header field MAY subscribe to the refer event state at that URI. It does so following the requirements of [RFC6665], placing the token 'refer' in the Event header field and the URI in the Request-URI of the SUBSCRIBE request. The SUBSCRIBE request MUST NOT reuse any existing dialog identifiers.
拥有从refereevents At header字段获得的URI的UA可以订阅该URI处的refereevent状态。它按照[RFC6665]的要求进行操作，将令牌“refer”放在事件头字段中，将URI放在订阅请求的请求URI中。订阅请求不得重用任何现有的对话框标识符。
Subsequent handling of the subscription MUST follow the requirements of [RFC6665] and [RFC3515]. In particular, as discussed in Section 2.4.6 of [RFC3515], the NOTIFY messages in the subscription might include an id parameter in their Event header fields. Subsequent SUBSCRIBE requests used to refresh or terminate this subscription MUST contain this id parameter. Note that the rationale for the id parameter provided in that section is not relevant when this extension is used. The URI returned in the Refer-Events-At header field uniquely identifies appropriate state, making the id parameter redundant. However, this behavioral requirement is preserved to reduce the number of changes to existing implementations in order to support this extension and to make it more likely that existing diagnostic tools will work with little or no modification.
订阅的后续处理必须遵循[RFC6665]和[RFC3515]的要求。特别是，如[RFC3515]第2.4.6节所述，订阅中的通知消息可能在其事件头字段中包含id参数。用于刷新或终止此订阅的后续订阅请求必须包含此id参数。请注意，使用此扩展时，该节中提供的id参数的基本原理不相关。在refereevents-At-header字段中返回的URI唯一地标识适当的状态，这使得id参数是冗余的。但是，保留此行为需求是为了减少对现有实现的更改数量，以支持此扩展，并使现有诊断工具更有可能在很少修改或不修改的情况下工作。
An event server receiving a SUBSCRIBE request will process it according to the requirements of [RFC6665]. The event server MAY choose to authorize the SUBSCRIBE request based on the Request-URI corresponding to existing refer event state. It MAY also require further authorization as discussed in Section 8.
接收订阅请求的事件服务器将根据[RFC6665]的要求对其进行处理。事件服务器可以基于与现有引用事件状态相对应的请求URI来选择授权订阅请求。如第8节所述，还可能需要进一步授权。
When accepting a subscription, the event server will establish the initial subscription duration using the guidance in Section 3.4 of [RFC3515].
接受订阅时，事件服务器将使用[RFC3515]第3.4节中的指南确定初始订阅持续时间。
NOTIFY messages within a subscription are formed and sent following the requirements in [RFC3515]. See, in particular, Section 2.4.5 of that document.
订阅中的通知消息是按照[RFC3515]中的要求形成和发送的。具体见该文件第2.4.5节。
As described in [RFC3515], an element creates the state for event 'refer' when it accepts a REFER request. It updates that state as the referred request proceeds, ultimately reaching a state where the request has completed and the final state is known.
如[RFC3515]中所述，元素在接受refer请求时为事件“refer”创建状态。它会在引用的请求进行时更新该状态，最终到达请求已完成且最终状态已知的状态。
In RFC 3515 implementations, it was a reasonable design choice to destroy the refer event state immediately after sending the NOTIFY that terminated the implicit subscription. This is not the case when using this extension. It is possible for the referenced request to complete very quickly, perhaps sooner than the time it takes the response to the REFER to traverse the network to the UA that sent the request and the time it takes that agent to send the SUBSCRIBE request for the event state to the URI the response provides. Thus, the event server MUST retain the final refer event state for a reasonable period of time, which SHOULD be at least 2*64*T1 (that is, 64 seconds), representing an upper-bound estimate of the time it would take to complete two non-INVITE transactions: the REFER and an immediate SUBSCRIBE.
在RFC3515实现中，在发送终止隐式订阅的通知后立即销毁refereevent状态是一种合理的设计选择。使用此扩展时并非如此。被引用的请求有可能很快完成，可能比对引用的响应穿越网络到发送请求的UA所需的时间以及该代理将事件状态的订阅请求发送到响应提供的URI所需的时间还要快。因此，事件服务器必须在一段合理的时间内保留最终的refer事件状态，该时间段应至少为2*64*T1（即64秒），表示完成两个非INVITE事务所需时间的上限估计值：refer和immediate SUBSCRIBE。
If an otherwise acceptable SUBSCRIBE arrives during this retention period, the subscription would be accepted and immediately terminated with a NOTIFY containing the final event state with a Subscription-State of terminated with a reason value of "noresource".
如果在此保留期内收到其他可接受的订阅，则该订阅将被接受并立即终止，通知中包含最终事件状态，订阅状态为terminated，原因值为“noresource”。
The Refer-Events-At header field is an extension-header as defined by [RFC3261]. Its ABNF [RFC5234] is as follows:
标题处的引用事件字段是由[RFC3261]定义的扩展标题。其ABNF[RFC5234]如下所示：
Refer-Events-At = "Refer-Events-At" HCOLON LAQUOT ( SIP-URI / SIPS-URI ) RAQUOT *( SEMI generic-param )
refereevents At=“refereevents At”HCOLON LAQUOT（SIP-URI/SIPS-URI）RAQUOT*（半通用参数）
See [RFC3261] for the definition of the elements used in that production.
参见[RFC3261]了解该生产中使用的元素的定义。
Note that this rule does not allow a full addr-spec as defined in RFC 3261, and it mandates the use of the angle brackets. That is:
请注意，此规则不允许RFC 3261中定义的完整addr规范，并且强制使用尖括号。即:
Refer-Events-At: <sips:vPT3izGmo8NTxaPADRZvEAY22BKx@example.com;gr>
Refer-Events-At: <sips:vPT3izGmo8NTxaPADRZvEAY22BKx@example.com;gr>
is well formed, but
结构良好，但是
Refer-Events-At: sip:wsXa9mkHtPcGu8@example.com
Refer-Events-At: sip:wsXa9mkHtPcGu8@example.com
is invalid.
这是无效的。
The Refer-Events-At header field is only meaningful in a 2xx-class response to a REFER request. If it appears in the header of any other SIP message, its meaning is undefined, and it MUST be ignored.
标头处的引用事件字段仅在对引用请求的2xx类响应中有意义。如果它出现在任何其他SIP消息的头中，则其含义未定义，必须忽略。
To suppress the creation of any implicit subscription and signal that no explicit subscription will be forthcoming, a UA forming a REFER request will include the option tag 'nosub' in the Require header field of the request. The REFER request is otherwise formed following the requirements of [RFC3515]. Since this REFER has no chance of creating an implicit subscription, the UA MAY send the REFER request within an existing dialog or out-of-dialog.
为了抑制任何隐式订阅的创建并发出无显式订阅即将到来的信号，形成REFER请求的UA将在请求的Require header字段中包含选项标记“nosub”。参考请求按照[RFC3515]的要求以其他方式形成。由于此REFER没有机会创建隐式订阅，UA可以在现有对话框内或对话框外发送REFER请求。
The UA will process responses to the REFER request as specified in [RFC3515] (and, consequently, [RFC3261]). In particular, if the REFER was sent to an element that does not support or is unwilling to use this extension, the response will contain a 420 (Bad Extension) response code (see Section 8.1.3.5 of [RFC3261]). As that document states, the UA can retry the request without using this extension.
UA将按照[RFC3515]（以及[RFC3261]）中的规定处理对REFER请求的响应。特别是，如果REFER被发送到不支持或不愿意使用此扩展的元素，则响应将包含420（错误扩展）响应代码（参见[RFC3261]第8.1.3.5节）。正如该文档所述，UA可以在不使用此扩展的情况下重试请求。
An element receiving a REFER request requiring the 'nosub' extension will use the same admissions policies that would be used without the extension, with the addition that it is acceptable to admit an in-dialog REFER request requiring this extension since it cannot create another usage inside that dialog. In particular, see Section 5.2 of [RFC3515].
接收到需要“nosub”扩展名的引用请求的元素将使用与不使用扩展名时相同的接纳策略，此外，允许需要此扩展名的对话框内引用请求是可以接受的，因为它无法在该对话框内创建其他用法。具体见[RFC3515]第5.2节。
Accepting a REFER request that requires 'nosub' does not create a dialog or a new usage within an existing dialog. The element MUST NOT create an implicit subscription when accepting the REFER request. Furthermore, the element accepting the REFER request is not required to maintain any state for serving refer event subscriptions.
接受需要“nosub”的引用请求不会在现有对话框中创建对话框或新用法。元素在接受引用请求时不得创建隐式订阅。此外，接受REFER请求的元素不需要维护任何状态来服务REFER事件订阅。
If the REFER is received within an existing dialog, the accepting element will not be acting as a SIP-Events notifier in the context of that dialog. If it is not otherwise subject to becoming a notifier in the context of the dialog, none of the requirements in [RFC6665], particularly the requirement to provide a GRUU as the local contact, apply to the message accepting the REFER request.
如果在现有对话框中接收到引用，则接受元素将不会在该对话框的上下文中充当SIP事件通知程序。如果在对话框的上下文中不需要成为通知者，[RFC6665]中的任何要求，特别是作为本地联系人提供GRUU的要求，都不适用于接受REFER请求的消息。
The accepting element will otherwise proceed with the processing defined in [RFC3515].
否则，接受元素将继续进行[RFC3515]中定义的处理。
This document defines the 'explicitsub' option tag, used to signal the use of the extension defined in Section 4, and the 'nosub' option tag, used to signal the use of the extension defined in Section 5.
本文件定义了“explicitsub”选项标签，用于表示第4节中定义的扩展的使用，以及“nosub”选项标签，用于表示第5节中定义的扩展的使用。
The use of either option tag in a Require header field is only defined when it appears in a REFER request or a response to a REFER request. A UA MUST NOT include the 'explicitsub' or 'nosub' option tag in the Require header field of any request other than REFER. A UA MUST NOT include the 'explicitsub' or 'nosub' option tag in the Require header field of any SIP response other than a 200 or 421 response to a REFER request.
只有在REFER请求或REFER请求响应中出现选项标记时，才定义在REFER标头字段中使用选项标记。UA不得在除REFER以外的任何请求的Require header字段中包含“explicitsub”或“nosub”选项标记。UA不得将'explicitsub'或'nosub'选项标记包含在任何SIP响应的Require头字段中，对REFER请求的200或421响应除外。
The 'explicitsub' and 'nosub' option tags MAY appear in the Supported header field of SIP messages and in the sip.extensions feature tag defined in [RFC3840]. This signals only that the UA including the value is aware of the extensions. In particular, a UA can only invoke the use of one of the extensions in a request. A UA MUST NOT include either option tag in the Require header field of a 200 response to a REFER request if that tag was not present in the Require header field of the request. A User Agent Server (UAS) that is processing a REFER request that lists 'explicitsub' or 'nosub' in its Supported header field and wishes to use one of those extensions will return a 421 response indicating which extension is required.
“explicitsub”和“nosub”选项标记可能出现在SIP消息的受支持标头字段和[RFC3840]中定义的SIP.extensions功能标记中。这仅表示UA（包括该值）知道扩展。特别是，UA只能在请求中调用其中一个扩展的使用。如果请求的Require header字段中不存在某个选项标记，则UA不得将该选项标记包含在refere请求的200响应的Require header字段中。正在处理REFER请求的用户代理服务器（UAS）在其受支持的标头字段中列出“explicitsub”或“nosub”，并希望使用其中一个扩展，它将返回421响应，指示需要哪个扩展。
The requirement in Section 2.4.4 of [RFC3515] to reject out-of-dialog SUBSCRIBE requests to event 'refer' is removed. An element MAY accept a SUBSCRIBE request to event 'refer', following the requirements and guidance in this document. REFER is no longer the only mechanism that can create a subscription to event 'refer'.
删除了[RFC3515]第2.4.4节中拒绝对话外订阅事件“参考”请求的要求。根据本文件中的要求和指导，要素可接受“参考”事件的订阅请求。REFERE不再是可以创建事件“REFERE”订阅的唯一机制。
The security considerations of [RFC3515] all still apply to a REFER request using this extension. The security considerations there for the implicit subscription apply to any explicit subscription for the 'refer' event.
[RFC3515]的安全注意事项仍然适用于使用此扩展的REFER请求。隐式订阅的安全注意事项适用于“refer”事件的任何显式订阅。
This update to RFC 3515 introduces a new authorization consideration. An element receiving an initial SUBSCRIBE request to the 'refer' event needs to decide whether the subscriber should be allowed to see the refer event state. In RFC 3515, this decision was conflated with
RFC 3515的更新引入了新的授权考虑。接收到对“refere”事件的初始订阅请求的元素需要决定是否允许订阅者查看refere事件状态。在RFC3515中，该决定与
accepting the REFER request, and the only possible subscriber was the element that sent the REFER. With this update, there may be multiple subscribers to any given refer event state.
接受REFER请求，唯一可能的订阅者是发送REFER的元素。通过此更新，任何给定的引用事件状态都可能有多个订阅服务器。
This document allows an element to accept an initial SUBSCRIBE request based on having a Request-URI that identifies existing refer event state. (Such a URI will have previously been sent in the Refer-Events-At header field in a successful REFER response). The element retrieving that URI from the response and any elements that element shares the URI with are authorized to SUBSCRIBE to the event state. Consequently, the URI should be constructed so that it is not easy to guess and should be protected against eavesdroppers when transmitted. [RFC3261] details mechanisms for providing such protection, such as sending SIP messages over Transport Layer Security (TLS) or Datagram TLS (DTLS). See the Security Considerations section of [RFC3261] for considerations when using other security mechanisms. An event server receiving a REFER request over an unprotected transport can redirect the requester to use a protected transport before accepting the request. A good way to ensure that subscriptions use a protected transport is to only construct sips: URIs. The event server can also require any of the additional authorization mechanisms allowed for any SIP request. For example, the event server could require a valid assertion of the subscriber's identity using [RFC4474].
此文档允许元素基于具有标识现有引用事件状态的请求URI来接受初始订阅请求。（在成功的Refer响应中，这样的URI先前已在Refer事件标题字段中发送）。从响应中检索该URI的元素以及与该元素共享该URI的任何元素都有权订阅事件状态。因此，URI的构造应使其不容易猜测，并应在传输时防止被窃听。[RFC3261]详细说明了提供此类保护的机制，例如通过传输层安全性（TLS）或数据报TLS（DTL）发送SIP消息。有关使用其他安全机制时的注意事项，请参阅[RFC3261]的安全注意事项部分。通过不受保护的传输接收REFER请求的事件服务器可以在接受请求之前将请求者重定向到使用受保护的传输。确保订阅使用受保护传输的一个好方法是只构造sips:uri。事件服务器还可以要求任何SIP请求允许的任何附加授权机制。例如，事件服务器可能需要使用[RFC4474]对订阅者身份进行有效断言。
The URI provided in a Refer-Events-At header field will be used as the Request-URI of SUBSCRIBE requests. A malicious agent could take advantage of being able to choose this URI in ways similar to the ways an agent sending a REFER request can take advantage of the Refer-To URI, as described in the Security Considerations section of [RFC3515]. In particular, the malicious agent could cause a SIP SUBSCRIBE to be sent as raw traffic towards a victim. If the victim is not SIP aware and the SUBSCRIBE is sent over UDP, there is (at most) a factor of 11 amplification due to retransmissions of the request. The potential for abuse in this situation is lower than that of the Refer-To URI, since the URI can only have a sip: or sips: scheme, and is only provided in a REFER response. A malicious agent would have to first receive a REFER request to take advantage of providing a Refer-Events-At URI.
refereevents At header字段中提供的URI将用作订阅请求的请求URI。恶意代理可以利用能够选择此URI的方式，类似于发送REFER请求的代理可以利用REFER-REFER URI的方式，如[RFC3515]的安全注意事项部分所述。特别是，恶意代理可能导致SIP订阅作为原始流量发送给受害者。如果受害者不知道SIP，并且订阅是通过UDP发送的，则由于请求的重新传输，（最多）有11倍的放大。这种情况下滥用的可能性低于refere-ref-URI，因为URI只能有sip:或sips:方案，并且只能在refere响应中提供。恶意代理必须首先接收REFER请求，才能利用在URI处提供REFER事件的优势。
The option tag 'explicitsub' has been registered in the 'Option Tags' subregistry of the 'Session Initiation Protocol (SIP) Parameters' registry by adding a row with these values:
通过添加具有以下值的行，选项标记“explicitsub”已在“会话启动协议（SIP）参数”注册表的“选项标记”子域中注册：
Name: explicitsub
姓名：explicitsub
Description: This option tag identifies an extension to REFER to suppress the implicit subscription and provide a URI for an explicit subscription.
描述：此选项标记标识要引用的扩展，以禁止隐式订阅并为显式订阅提供URI。
Reference: RFC 7614 (this document)
参考：RFC 7614（本文件）
The option tag 'nosub' has been registered in the 'Option Tags' subregistry of the 'Session Initiation Protocol (SIP) Parameters' registry by adding a row with these values:
通过添加具有以下值的行，选项标记“nosub”已在“会话启动协议（SIP）参数”注册表的“选项标记”子域中注册：
Name: nosub
姓名：nosub
Description: This option tag identifies an extension to REFER to suppress the implicit subscription and indicate that no explicit subscription is forthcoming.
描述：此选项标记标识要引用的扩展，以禁止隐式订阅，并指示没有显式订阅。
Reference: RFC 7614 (this document)
参考：RFC 7614（本文件）
The header field described in Section 4.8 has been registered in the 'Header Fields' subregistry of the 'Session Initiation Protocol (SIP) Parameters' registry by adding a row with these values:
通过添加具有以下值的行，第4.8节中描述的标题字段已在“会话启动协议（SIP）参数”注册表的“标题字段”子区中注册：
Header Name: Refer-Events-At
标题名称：在以下位置引用事件：
compact: none
紧凑型：无
Reference: RFC 7614 (this document)
参考：RFC 7614（本文件）
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, <http://www.rfc-editor.org/info/rfc3515>.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，DOI 10.17487/RFC3515，2003年4月<http://www.rfc-editor.org/info/rfc3515>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，DOI 10.17487/RFC3840，2004年8月<http://www.rfc-editor.org/info/rfc3840>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, DOI 10.17487/RFC6665, July 2012, <http://www.rfc-editor.org/info/rfc6665>.
[RFC6665]Roach，A.，“SIP特定事件通知”，RFC 6665，DOI 10.17487/RFC66652012年7月<http://www.rfc-editor.org/info/rfc6665>.
[RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, DOI 10.17487/RFC3903, October 2004, <http://www.rfc-editor.org/info/rfc3903>.
[RFC3903]Niemi，A.，编辑，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，DOI 10.17487/RFC3903，2004年10月<http://www.rfc-editor.org/info/rfc3903>.
[RFC4321] Sparks, R., "Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4321, DOI 10.17487/RFC4321, January 2006, <http://www.rfc-editor.org/info/rfc4321>.
[RFC4321]Sparks，R.“与会话启动协议（SIP）非邀请事务相关的问题”，RFC 4321，DOI 10.17487/RFC4321，2006年1月<http://www.rfc-editor.org/info/rfc4321>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, <http://www.rfc-editor.org/info/rfc4474>.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，DOI 10.17487/RFC4474，2006年8月<http://www.rfc-editor.org/info/rfc4474>.
[RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, DOI 10.17487/RFC4538, June 2006, <http://www.rfc-editor.org/info/rfc4538>.
[RFC4538]Rosenberg，J.，“通过会话启动协议（SIP）中的对话标识请求授权”，RFC 4538，DOI 10.17487/RFC4538，2006年6月<http://www.rfc-editor.org/info/rfc4538>.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057, November 2007, <http://www.rfc-editor.org/info/rfc5057>.
[RFC5057]Sparks，R.，“会话启动协议中的多个对话用法”，RFC 5057，DOI 10.17487/RFC5057，2007年11月<http://www.rfc-editor.org/info/rfc5057>.
[RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, <http://www.rfc-editor.org/info/rfc5589>.
[RFC5589]Sparks，R.，Johnston，A.，Ed.，和D.Petrie，“会话启动协议（SIP）呼叫控制-传输”，BCP 149，RFC 5589，DOI 10.17487/RFC5589，2009年6月<http://www.rfc-editor.org/info/rfc5589>.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, <http://www.rfc-editor.org/info/rfc5627>.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，DOI 10.17487/RFC5627，2009年10月<http://www.rfc-editor.org/info/rfc5627>.
Author's Address
作者地址
Robert Sparks Oracle 7460 Warren Parkway, Suite 300 Frisco, Texas 75034 United States
Robert Sparks Oracle 7460 Warren Parkway，美国德克萨斯州弗里斯科300号套房，邮编75034
Email: rjsparks@nostrum.com
Email: rjsparks@nostrum.com