Network Working Group R. Sparks
Request for Comments: 3515 dynamicsoft
Category: Standards Track April 2003
Network Working Group R. Sparks
Request for Comments: 3515 dynamicsoft
Category: Standards Track April 2003
The Session Initiation Protocol (SIP) Refer Method
会话启动协议（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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer.
本文档定义了REFER方法。此会话启动协议（SIP）扩展请求接收方引用请求中提供的资源。它提供了一种机制，允许发送REFER的一方收到被引用请求的结果的通知。这可以用于启用许多应用程序，包括呼叫转移。
In addition to the REFER method, this document defines the the refer event package and the Refer-To request header.
除REFER方法外，本文档还定义了REFER事件包和REFER-REFER请求头。
Table of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The REFER Method . . . . . . . . . . . . . . . . . . . . . . 3
2.1 The Refer-To Header Field . . . . . . . . . . . . . . . 3
2.2 Header Field Support for the REFER Method . . . . . . . 4
2.3 Message Body Inclusion. . . . . . . . . . . . . . . . . 5
2.4 Behavior of SIP User Agents . . . . . . . . . . . . . . 6
2.4.1 Forming a REFER request . . . . . . . . . . . . . 6
2.4.2 Processing a REFER request. . . . . . . . . . . . 6
2.4.3 Accessing the Referred-to Resource. . . . . . . . 6
2.4.4 Using SIP Events to Report the Results
of the Reference. . . . . . . . . . . . . . . . . 7
2.4.5 The Body of the NOTIFY. . . . . . . . . . . . . . 8
2.4.6 Multiple REFER Requests in a Dialog . . . . . . . 9
2.4.7 Using the Subscription-State Header
Field with Event Refer. . . . . . . . . . . . . . 9
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The REFER Method . . . . . . . . . . . . . . . . . . . . . . 3
2.1 The Refer-To Header Field . . . . . . . . . . . . . . . 3
2.2 Header Field Support for the REFER Method . . . . . . . 4
2.3 Message Body Inclusion. . . . . . . . . . . . . . . . . 5
2.4 Behavior of SIP User Agents . . . . . . . . . . . . . . 6
2.4.1 Forming a REFER request . . . . . . . . . . . . . 6
2.4.2 Processing a REFER request. . . . . . . . . . . . 6
2.4.3 Accessing the Referred-to Resource. . . . . . . . 6
2.4.4 Using SIP Events to Report the Results
of the Reference. . . . . . . . . . . . . . . . . 7
2.4.5 The Body of the NOTIFY. . . . . . . . . . . . . . 8
2.4.6 Multiple REFER Requests in a Dialog . . . . . . . 9
2.4.7 Using the Subscription-State Header
Field with Event Refer. . . . . . . . . . . . . . 9
2.5 Behavior of SIP Registrars/Redirect Servers . . . . . . 9
2.6 Behavior of SIP Proxies . . . . . . . . . . . . . . . . 10
3. Package Details: Event refer . . . . . . . . . . . . . . . . 10
3.1 Event Package Name. . . . . . . . . . . . . . . . . . . 10
3.2 Event Package Parameters. . . . . . . . . . . . . . . . 10
3.3 SUBSCRIBE Bodies. . . . . . . . . . . . . . . . . . . . 10
3.4 Subscription Duration . . . . . . . . . . . . . . . . . 10
3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . 11
3.6 Notifier processing of SUBSCRIBE requests . . . . . . . 11
3.7 Notifier Generation of NOTIFY Requests. . . . . . . . . 11
3.8 Subscriber Processing of NOTIFY Requests. . . . . . . . 11
3.9 Handling of Forked Requests . . . . . . . . . . . . . . 11
3.10 Rate of Notifications . . . . . . . . . . . . . . . . . 11
3.11 State Agents. . . . . . . . . . . . . . . . . . . . . . 11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Prototypical REFER callflow . . . . . . . . . . . . . . 12
4.2 Multiple REFERs in a dialog . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . 16
5.1 Constructing a Refer-To URI . . . . . . . . . . . . . . 16
5.2 Authorization Considerations for REFER. . . . . . . . . 17
5.3 Considerations for the use of message/sipfrag . . . . . 18
5.3.1 Circumventing Privacy . . . . . . . . . . . . . . 18
5.3.2 Circumventing Confidentiality . . . . . . . . . . 19
5.3.3 Limiting the Breach . . . . . . . . . . . . . . . 19
5.3.4 Cut, Paste and Replay Considerations. . . . . . . 19
6. Historic Material . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1 Normative References. . . . . . . . . . . . . . . . . . 21
9.2 Informative References. . . . . . . . . . . . . . . . . 21
10. Intellectual Property Statement. . . . . . . . . . . . . . . 21
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . 22
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
2.5 Behavior of SIP Registrars/Redirect Servers . . . . . . 9
2.6 Behavior of SIP Proxies . . . . . . . . . . . . . . . . 10
3. Package Details: Event refer . . . . . . . . . . . . . . . . 10
3.1 Event Package Name. . . . . . . . . . . . . . . . . . . 10
3.2 Event Package Parameters. . . . . . . . . . . . . . . . 10
3.3 SUBSCRIBE Bodies. . . . . . . . . . . . . . . . . . . . 10
3.4 Subscription Duration . . . . . . . . . . . . . . . . . 10
3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . 11
3.6 Notifier processing of SUBSCRIBE requests . . . . . . . 11
3.7 Notifier Generation of NOTIFY Requests. . . . . . . . . 11
3.8 Subscriber Processing of NOTIFY Requests. . . . . . . . 11
3.9 Handling of Forked Requests . . . . . . . . . . . . . . 11
3.10 Rate of Notifications . . . . . . . . . . . . . . . . . 11
3.11 State Agents. . . . . . . . . . . . . . . . . . . . . . 11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Prototypical REFER callflow . . . . . . . . . . . . . . 12
4.2 Multiple REFERs in a dialog . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . 16
5.1 Constructing a Refer-To URI . . . . . . . . . . . . . . 16
5.2 Authorization Considerations for REFER. . . . . . . . . 17
5.3 Considerations for the use of message/sipfrag . . . . . 18
5.3.1 Circumventing Privacy . . . . . . . . . . . . . . 18
5.3.2 Circumventing Confidentiality . . . . . . . . . . 19
5.3.3 Limiting the Breach . . . . . . . . . . . . . . . 19
5.3.4 Cut, Paste and Replay Considerations. . . . . . . 19
6. Historic Material . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1 Normative References. . . . . . . . . . . . . . . . . . 21
9.2 Informative References. . . . . . . . . . . . . . . . . 21
10. Intellectual Property Statement. . . . . . . . . . . . . . . 21
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . 22
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
This document defines the REFER method. This SIP [1] extension requests that the recipient REFER to a resource provided in the request.
本文档定义了REFER方法。此SIP[1]扩展请求接收方引用请求中提供的资源。
This can be used to enable many applications, including Call Transfer. For instance, if Alice is in a call with Bob, and decides Bob needs to talk to Carol, Alice can instruct her SIP user agent (UA) to send a SIP REFER request to Bob's UA providing Carol's SIP Contact information. Assuming Bob has given it permission, Bob's UA will attempt to call Carol using that contact. Bob's UA will then report whether it succeeded in reaching the contact to Alice's UA.
这可以用于启用许多应用程序，包括呼叫转移。例如，如果Alice正在与Bob通话，并且确定Bob需要与Carol通话，Alice可以指示她的SIP用户代理（UA）向Bob的UA发送SIP REFER请求，提供Carol的SIP联系信息。假设Bob允许，Bob的UA将尝试使用该联系人给Carol打电话。Bob的UA随后将向Alice的UA报告其是否成功联系到联系人。
REFER is a SIP method as defined by RFC 3261 [1]. The REFER method indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request.
REFER是RFC 3261[1]定义的SIP方法。refere方法指示接收者（由请求URI标识）应该使用请求中提供的联系信息联系第三方。
Unless stated otherwise, the protocol for emitting and responding to a REFER request are identical to those for a BYE request in [1]. The behavior of SIP entities not implementing the REFER (or any other unknown) method is explicitly defined in [1].
除非另有说明，否则发送和响应REFER请求的协议与[1]中BYE请求的协议相同。[1]中明确定义了未实现REFERE（或任何其他未知）方法的SIP实体的行为。
A REFER request implicitly establishes a subscription to the refer event. Event subscriptions are defined in [2].
REFER请求隐式地建立对REFER事件的订阅。事件订阅在[2]中定义。
A REFER request MAY be placed outside the scope of a dialog created with an INVITE. REFER creates a dialog, and MAY be Record-Routed, hence MUST contain a single Contact header field value. REFERs occurring inside an existing dialog MUST follow the Route/Record-Route logic of that dialog.
引用请求可能位于使用INVITE创建的对话框的范围之外。REFER创建一个对话框，并且可能是记录路由的，因此必须包含一个联系人标题字段值。在现有对话框中发生的引用必须遵循该对话框的路由/记录路由逻辑。
Refer-To is a request header field (request-header) as defined by [1]. It only appears in a REFER request. It provides a URL to reference.
请参阅[1]中定义的请求标头字段（请求标头）。它仅出现在引用请求中。它提供了一个要引用的URL。
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) *
(SEMI generic-param)
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) *
(SEMI generic-param)
The following should be interpreted as if it appeared in Table 3 of RFC 3261.
应将以下内容解释为RFC 3261表3中的内容。
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________________
Refer-To R - - - - - -
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________________
Refer-To R - - - - - -
The Refer-To header field MAY be encrypted as part of end-to-end encryption.
引用标头字段可以作为端到端加密的一部分进行加密。
The Contact header field is an important part of the Route/Record-Route mechanism and is not available to be used to indicate the target of the reference.
联系人标头字段是路由/记录路由机制的重要组成部分，不能用于指示引用的目标。
Examples
例子
Refer-To: sip:alice@atlanta.example.com
Refer-To: sip:alice@atlanta.example.com
Refer-To: <sip:bob@biloxi.example.net?Accept-Contact=sip:bobsdesk.
biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com>
Refer-To: <sip:bob@biloxi.example.net?Accept-Contact=sip:bobsdesk.
biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com>
Refer-To: <sip:dave@denver.example.org?Replaces=12345%40192.168.118.3%3B
to-tag%3D12345%3Bfrom-tag%3D5FFE-3994>
Refer-To: <sip:dave@denver.example.org?Replaces=12345%40192.168.118.3%3B
to-tag%3D12345%3Bfrom-tag%3D5FFE-3994>
Refer-To: <sip:carol@cleveland.example.org;method=SUBSCRIBE>
Refer-To: <sip:carol@cleveland.example.org;method=SUBSCRIBE>
Refer-To: http://www.ietf.org
Refer-To: http://www.ietf.org
Long headers field values are line-wrapped here for clarity only.
长标题字段值在此处换行仅为清晰起见。
This table adds a column to tables 2 and 3 in [1], describing header field presence in a REFER method. See [1] for a key for the symbols used. A row for the Refer-To request-header should be inferred, mandatory for REFER. Refer-To is not applicable for any other methods. The proxy column in [1] applies to the REFER method unmodified.
此表在[1]中的表2和表3中添加了一列，描述了REFER方法中存在的标题字段。有关所用符号的键，请参见[1]。应该推断refere-To请求头的行，refere是必需的。参考不适用于任何其他方法。[1]中的proxy列适用于未修改的REFER方法。
Header Where REFER Accept R o Accept 2xx - Accept 415 c Accept-Encoding R o Accept-Encoding 2xx - Accept-Encoding 415 c Accept-Language R o Accept-Language 2xx - Accept-Language 415 c Alert-Info - Allow Rr o Allow 405 m Authentication-Info 2xx o Authorization R o Call-ID c m Call-Info - Contact R m Contact 1xx - Contact 2xx m Contact 3-6xx o Content-Disposition o Content-Encoding o
标题，其中参考接受R o接受2xx-接受415 c接受编码R o接受编码2xx-接受编码415 c接受语言R o接受语言2xx-接受语言415 c警报信息-允许Rr o允许405 m身份验证信息2xx o授权R o呼叫ID c m呼叫信息-联系R m联系人1xx-联系2xx m联系人3-6xx o内容处理o内容编码o
Content-Language o Content-Length o Content-Type * CSeq c m Date o Error-Info 3-6xx o Expires R o From c m In-Reply-To - Max-Forwards R m Min-Expires - MIME-Version o Organization o Priority R - Proxy-Authenticate 401 o Proxy-Authenticate 407 m Proxy-Authorization R o Proxy-Require R o Record-Route R o Record-Route 2xx,18x o Reply-To - Require c Retry-After 404,413,480,486 o Retry-After 500,503 o Retry-After 600,603 o Route R c Server r o Subject R - Supported R,2xx o Timestamp o To c(1) m Unsupported 420 o User-Agent o Via c(2) m Warning r o WWW-Authenticate 401 m WWW-Authenticate 407 o
内容语言o内容长度o内容类型*CSeq c m日期o错误信息3-6xx o过期R o从c m回复-最大转发R m最小过期-MIME版本o组织o优先级R-代理验证401 o代理验证407 m代理授权R o代理要求R o记录路由R o记录路由2xx，18x o回复-404413480486后要求c重试500503后重试600603后重试o路由R c服务器R o主题R-支持R，2xx o时间戳o到c（1）m不支持420 o用户代理o通过c（2）m警告R o WWW认证401 m WWW认证407 o
Table 1: Header Field Support
表1：标题字段支持
A REFER method MAY contain a body. This specification assigns no meaning to such a body. A receiving agent may choose to process the body according to its Content-Type.
引用方法可能包含一个主体。本规范不赋予此类主体任何意义。接收代理可以根据正文的内容类型选择处理正文。
REFER is a SIP request and is constructed as defined in [1]. A REFER request MUST contain exactly one Refer-To header field value.
REFER是一个SIP请求，按照[1]中的定义构造。引用请求必须仅包含一个引用标头字段值。
A UA accepting a well-formed REFER request SHOULD request approval from the user to proceed (this request could be satisfied with an interactive query or through accessing configured policy). If approval is granted, the UA MUST contact the resource identified by the URI in the Refer-To header field value as discussed in Section 2.4.3.
接受格式良好的REFER请求的UA应请求用户批准继续（该请求可以通过交互式查询或通过访问配置的策略来满足）。如果批准获得批准，UA必须联系第2.4.3节中讨论的引用标题字段值中URI标识的资源。
If the approval sought above for a well-formed REFER request is immediately denied, the UA MAY decline the request.
如果上述对格式良好的转介请求的批准被立即拒绝，UA可拒绝该请求。
An agent responding to a REFER method MUST return a 400 (Bad Request) if the request contained zero or more than one Refer-To header field values.
如果请求包含零个或多个REFER-REFER标头字段值，则响应REFER方法的代理必须返回400（错误请求）。
An agent (including proxies generating local responses) MAY return a 100 (Trying) or any appropriate 4xx-6xx class response as prescribed by [1].
代理（包括生成本地响应的代理）可以返回[1]规定的100（尝试）或任何适当的4xx-6xx类响应。
Care should be taken when implementing the logic that determines whether or not to accept the REFER request. A UA not capable of accessing non-SIP URIs SHOULD NOT accept REFER requests to them.
在实现确定是否接受REFER请求的逻辑时，应小心。无法访问非SIP URI的UA不应接受对其的REFER请求。
If no final response has been generated according to the rules above, the UA MUST return a 202 Accepted response before the REFER transaction expires.
如果没有根据上述规则生成最终响应，UA必须在REFER事务到期之前返回202接受的响应。
If a REFER request is accepted (that is, a 2xx class response is returned), the recipient MUST create a subscription and send notifications of the status of the refer as described in Section 2.4.4.
如果接受REFER请求（即返回2xx类响应），则接收方必须创建订阅并发送REFER状态通知，如第2.4.4节所述。
The resource identified by the Refer-To URI is contacted using the normal mechanisms for that URI type. For example, if the URI is a SIP URI indicating INVITE (using a method=INVITE URI parameter for example), the UA would issue a new INVITE using all of the normal rules for sending an INVITE defined in [1].
由refereferuri标识的资源使用该URI类型的正常机制进行联系。例如，如果URI是指示INVITE的SIP URI（例如使用method=INVITE URI参数），UA将使用[1]中定义的发送INVITE的所有常规规则发出新INVITE。
The NOTIFY mechanism defined in [2] MUST be used to inform the agent sending the REFER of the status of the reference. The dialog identifiers (To, From, and Call-ID) of each NOTIFY must match those of the REFER as they would if the REFER had been a SUBSCRIBE request.
必须使用[2]中定义的通知机制将引用的状态通知发送引用的代理。每个NOTIFY的对话框标识符（To、From和Call ID）必须与refere的标识符匹配，就像refere是SUBSCRIBE请求一样。
Each NOTIFY MUST contain an Event header field with a value of refer and possibly an id parameter (see Section 2.4.6).
每个NOTIFY必须包含一个值为refer的事件标题字段，可能还包含一个id参数（见第2.4.6节）。
Each NOTIFY MUST contain a body of type "message/sipfrag" [3].
每个通知必须包含类型为“message/sipfrag”[3]的正文。
The creation of a subscription as defined by [2] always results in an immediate NOTIFY. Analogous to the case for SUBSCRIBE described in that document, the agent that issued the REFER MUST be prepared to receive a NOTIFY before the REFER transaction completes.
[2]定义的订阅的创建始终会导致立即通知。与该文档中描述的SUBSCRIBE类似，发出REFER的代理必须准备在REFER事务完成之前接收通知。
The implicit subscription created by a REFER is the same as a subscription created with a SUBSCRIBE request. The agent issuing the REFER can terminate this subscription prematurely by unsubscribing using the mechanisms described in [2]. Terminating a subscription, either by explicitly unsubscribing or rejecting NOTIFY, is not an indication that the referenced request should be withdrawn or abandoned. In particular, an agent acting on a REFER request SHOULD NOT issue a CANCEL to any referenced SIP requests because the agent sending the REFER terminated its subscription to the refer event before the referenced request completes.
引用创建的隐式订阅与使用订阅请求创建的订阅相同。发出REFER的代理可以使用[2]中描述的机制取消订阅，从而提前终止此订阅。通过明确取消订阅或拒绝NOTIFY来终止订阅，并不表示引用的请求应被撤回或放弃。特别是，对引用请求执行操作的代理不应向任何引用的SIP请求发出取消，因为发送引用的代理在引用的请求完成之前终止了对引用事件的订阅。
The agent issuing the REFER may extend its subscription using the subscription refresh mechanisms described in [2].
发出REFER的代理可以使用[2]中描述的订阅刷新机制扩展其订阅。
REFER is the only mechanism that can create a subscription to event refer. If a SUBSCRIBE request for event refer is received for a subscription that does not already exist, it MUST be rejected with a 403.
REFER是唯一可以创建订阅事件REFER的机制。如果针对不存在的订阅接收到事件引用的订阅请求，则必须使用403拒绝该请求。
Notice that unlike SUBSCRIBE, the REFER transaction does not contain a duration for the subscription in either the request or the response. The lifetime of the state being subscribed to is determined by the progress of the referenced request. The duration of the subscription is chosen by the agent accepting the REFER and is communicated to the agent sending the REFER in the subscription's initial NOTIFY (using the Subscription-State expires header parameter). Note that agents accepting REFER and not wishing to hold subscription state can terminate the subscription with this initial NOTIFY.
请注意，与SUBSCRIBE不同，refere事务在请求或响应中都不包含订阅的持续时间。订阅状态的生存期由引用请求的进度决定。订阅的持续时间由接受引用的代理选择，并在订阅的初始通知（使用订阅状态expires标头参数）中传递给发送引用的代理。请注意，接受REFER且不希望保持订阅状态的代理可以使用此初始通知终止订阅。
Each NOTIFY MUST contain a body of type "message/sipfrag" [3]. The body of a NOTIFY MUST begin with a SIP Response Status-Line as defined in [1]. The response class in this status line indicates the status of the referred action. The body MAY contain other SIP header fields to provide information about the outcome of the referenced action. This body provides a complete statement of the status of the referred action. The refer event package does not support state deltas.
每个通知必须包含类型为“message/sipfrag”[3]的正文。通知的正文必须以[1]中定义的SIP响应状态行开头。此状态行中的响应类指示所引用操作的状态。正文可能包含其他SIP头字段，以提供有关引用操作结果的信息。本机构提供了所述行动状态的完整说明。引用事件包不支持状态增量。
If a NOTIFY is generated when the subscription state is pending, its body should consist only of a status line containing a response code of 100.
如果在订阅状态为挂起时生成通知，则其正文应仅由包含响应代码100的状态行组成。
A minimal, but complete, implementation can respond with a single NOTIFY containing either the body:
一个最小但完整的实现可以通过一个包含以下内容之一的通知进行响应：
SIP/2.0 100 Trying
SIP/2.0 100
if the subscription is pending, the body:
如果订阅处于挂起状态，则正文：
SIP/2.0 200 OK
SIP/2.0 200正常
if the reference was successful, the body:
如果引用成功，主体将：
SIP/2.0 503 Service Unavailable
SIP/2.0 503服务不可用
if the reference failed, or the body:
如果引用失败，或主体失败：
SIP/2.0 603 Declined
SIP/2.0 603被拒绝
if the REFER request was accepted before approval to follow the reference could be obtained and that approval was subsequently denied (see Section 2.4.7).
如果在获得批准之前接受了参考请求，则可以获得参考，且该批准随后被拒绝（见第2.4.7节）。
An implementation MAY include more of a SIP message in that body to convey more information. Warning header field values received in responses to the referred action are good candidates. In fact, if the reference was to a SIP URI, the entire response to the referenced action could be returned (perhaps to assist with debugging). However, doing so could have grave security repercussions (see Section 5). Implementers must carefully consider what they choose to include.
一种实现可以在该主体中包括更多SIP消息以传递更多信息。在响应所引用的操作时收到的警告标头字段值是很好的候选值。事实上，如果引用是一个SIPURI，那么可以返回对所引用操作的整个响应（可能是为了帮助调试）。然而，这样做可能会产生严重的安全影响（见第5节）。实施者必须仔细考虑他们选择的内容。
Note that if the reference was to a non-SIP URI, status in any NOTIFYs to the referrer must still be in the form of SIP Response Status-Lines. The minimal implementation discussed above is
请注意，如果引用是非SIP URI，则向引用方发送的任何NOTIFY中的状态必须仍然是SIP响应状态行的形式。上面讨论的最小实现是
sufficient to provide a basic indication of success or failure. For example, if a client receives a REFER to a HTTP URL, and is successful in accessing the resource, its NOTIFY to the referrer can contain the message/sipfrag body of "SIP/2.0 200 OK". If the notifier wishes to return additional non-SIP protocol specific information about the status of the request, it may place it in the body of the sipfrag message.
足以提供成功或失败的基本指示。例如，如果客户端接收到一个引用HTTP URL的消息，并且成功地访问了该资源，则其对引用者的通知可以包含消息/sipfrag正文“SIP/2.0 200 OK”。如果通知者希望返回关于请求状态的附加非SIP协议特定信息，则可以将其置于sipfrag消息体中。
A REFER creates an implicit subscription sharing the dialog identifiers in the REFER request. If more than one REFER is issued in the same dialog (a second attempt at transferring a call for example), the dialog identifiers do not provide enough information to associate the resulting NOTIFYs with the proper REFER.
REFERE创建一个隐式订阅，共享REFERE请求中的对话框标识符。如果在同一个对话框中发出了多个引用（例如，第二次尝试传输调用），则对话框标识符不会提供足够的信息来将生成的NOTIFY与正确的引用相关联。
Thus, for the second and subsequent REFER requests a UA receives in a given dialog, it MUST include an id parameter[2] in the Event header field of each NOTIFY containing the sequence number (the number from the CSeq header field value) of the REFER this NOTIFY is associated with. This id parameter MAY be included in NOTIFYs to the first REFER a UA receives in a given dialog. A SUBSCRIBE sent to refresh or terminate this subscription MUST contain this id parameter.
因此，对于UA在给定对话框中接收的第二个和后续REFER请求，它必须在每个通知的事件头字段中包含id参数[2]，其中包含与该通知相关联的REFER的序列号（CSeq头字段值中的数字）。此id参数可包括在通知UA在给定对话框中接收的第一个参考中。发送用于刷新或终止此订阅的订阅必须包含此id参数。
Each NOTIFY must contain a Subscription-State header field as defined in [2]. The final NOTIFY sent in response to a REFER MUST indicate the subscription has been "terminated" with a reason of "noresource". (The resource being subscribed to is the state of the referenced request).
每个通知必须包含[2]中定义的订阅状态标头字段。为响应转介而发送的最终通知必须表明订阅已“终止”，原因为“noresource”。（订阅的资源是引用请求的状态）。
If a NOTIFY indicates a reason that indicates a re-subscribe is appropriate according to [2], the agent sending the REFER is NOT obligated to re-subscribe.
如果通知表明原因表明根据[2]重新订阅是适当的，则发送参考的代理没有重新订阅的义务。
In the case where a REFER was accepted with a 202, but approval to follow the reference was subsequently denied, the reason and retry-after elements of the Subscription-State header field can be used to indicate if and when the REFER can be re-attempted (as described for SUBSCRIBE in [2]).
如果202接受了引用，但随后拒绝了对引用的批准，则订阅状态标题字段的“原因”和“重试时间”元素可用于指示是否以及何时可以重新尝试引用（如[2]中针对订阅所述）。
A registrar that is unaware of the definition of the REFER method will return a 501 response as defined in [1]. A registrar aware of the definition of REFER SHOULD return a 405 response.
不知道refere方法定义的注册器将返回[1]中定义的501响应。知道REFER定义的注册员应返回405响应。
This specification places no requirements on redirect server behavior beyond those specified in [1]. Thus, it is possible for REFER requests to be redirected.
本规范对重定向服务器行为的要求不超过[1]中规定的要求。因此，可以重定向REFER请求。
SIP proxies do not require modification to support the REFER method. Specifically, as required by [1], a proxy should process a REFER request the same way it processes an OPTIONS request.
SIP代理不需要修改以支持REFER方法。具体地说，正如[1]所要求的，代理处理REFER请求的方式应与处理OPTIONS请求的方式相同。
This document defines an event package as defined in [2].
本文档定义了[2]中定义的事件包。
The name of this event package is "refer".
此事件包的名称为“参考”。
This package uses the "id" parameter defined in [2]. Its use in package is described in Section 2.4.6.
此包使用[2]中定义的“id”参数。第2.4.6节描述了其在包装中的使用。
SUBSCRIBE bodies have no special meaning for this event package.
订阅主体对此事件包没有特殊意义。
The duration of an implicit subscription created by a REFER request is initially determined by the agent accepting the REFER and communicated to the subscribing agent in the Subscription-State header field's expire parameter in the first NOTIFY sent in the subscription. Reasonable choices for this initial duration depend on the type of request indicated in the Refer-To URI. The duration SHOULD be chosen to be longer than the time the referenced request will be given to complete. For example, if the Refer-To URI is a SIP INVITE URI, the subscription interval should be longer than the Expire value in the INVITE. Additional time MAY be included to account for time needed to authorize the subscription. The subscribing agent MAY extend the subscription by refreshing it, or terminate it by unsubscribing. As described in Section 2.4.7, the agent accepting the REFER will terminate the subscription when it reports the final result of the reference, indicating that termination in the Subscription-State header field.
由REFER请求创建的隐式订阅的持续时间最初由接受REFER的代理确定，并在订阅中发送的第一个通知中，在订阅状态标头字段的expire参数中传递给订阅代理。此初始持续时间的合理选择取决于Refer-Refer URI中指示的请求类型。持续时间应选择为比所引用请求的完成时间长。例如，如果Refer-Refer URI是SIP INVITE URI，则订阅间隔应大于INVITE中的EXIRE值。可能会包括额外的时间，以说明授权订阅所需的时间。订阅代理可以通过刷新来扩展订阅，也可以通过取消订阅来终止订阅。如第2.4.7节所述，接受引用的代理将在报告引用的最终结果时终止订阅，这表明在订阅状态标头字段中终止。
The bodies of NOTIFY requests for event refer are discussed in Section 2.4.5.
第2.4.5节讨论了事件参考通知请求的主体。
Notifier processing of SUBSCRIBE requests is discussed in Section 2.4.4.
第2.4.4节讨论了订阅请求的通知程序处理。
Notifier generation of NOTIFY requests is discussed in Section 2.4.4.
第2.4.4节讨论了NOTIFY请求的通知程序生成。
Subscriber processing of NOTIFY requests is discussed in Section 2.4.4.
第2.4.4节讨论了订户对通知请求的处理。
A REFER sent within the scope of an existing dialog will not fork. A REFER sent outside the context of a dialog MAY fork, and if it is accepted by multiple agents, MAY create multiple subscriptions. These subscriptions are created and managed as per "Handling of Forked Requests" in [2] as if the REFER had been a SUBSCRIBE. The agent sending the REFER manages the state associated with each subscription separately. It does NOT merge the state from the separate subscriptions. The state is the status of the referenced request at each of the accepting agents.
在现有对话框范围内发送的引用将不会分叉。在对话框上下文之外发送的引用可能会分叉，如果它被多个代理接受，则可能会创建多个订阅。这些订阅是按照[2]中的“Forked Requests Handling”创建和管理的，就像引用是订阅一样。发送REFER的代理分别管理与每个订阅关联的状态。它不会合并单独订阅中的状态。状态是每个接受代理上引用的请求的状态。
An event refer NOTIFY might be generated each time new knowledge of the status of a referenced requests becomes available. For instance, if the REFER was to a SIP INVITE, NOTIFYs might be generated with each provisional response and the final response to the INVITE. Alternatively, the subscription might only result in two NOTIFY requests, the immediate NOTIFY and the NOTIFY carrying the final result of the reference. NOTIFYs to event refer SHOULD NOT be sent more frequently than once per second.
每次对引用请求的状态有了新的了解时，都可能会生成事件引用通知。例如，如果引用的是SIP INVITE，则可能会使用每个临时响应和对INVITE的最终响应生成NOTIFY。或者，订阅可能只会导致两个通知请求，立即通知和携带引用最终结果的通知。向事件引用发送NOTIFY的频率不应超过每秒一次。
Separate state agents are not defined for event refer.
未为事件引用定义单独的状态代理。
Agent A Agent B
| |
| F1 REFER |
|----------------------->|
| F2 202 Accepted |
|<-----------------------|
| F3 NOTIFY |
|<-----------------------|
| F4 200 OK |
|----------------------->|
| |
| |
| |------->
| | (whatever)
| |<------
| |
| F5 NOTIFY |
|<-----------------------|
| F6 200 OK |
|----------------------->|
| |
| |
Agent A Agent B
| |
| F1 REFER |
|----------------------->|
| F2 202 Accepted |
|<-----------------------|
| F3 NOTIFY |
|<-----------------------|
| F4 200 OK |
|----------------------->|
| |
| |
| |------->
| | (whatever)
| |<------
| |
| F5 NOTIFY |
|<-----------------------|
| F6 200 OK |
|----------------------->|
| |
| |
Here are examples of what the four messages between Agent A and Agent B might look like if the reference to (whatever) that Agent B makes is successful. The details of this flow indicate this particular REFER occurs outside a session (there is no To tag in the REFER request). If the REFER occurs inside a session, there would be a non-empty To tag in the request.
下面是代理A和代理B之间的四条消息的示例，如果代理B成功引用（无论什么）的话。此流的详细信息表明此特定引用发生在会话之外（引用请求中没有To标记）。如果引用发生在会话中，则请求中会有一个非空的To标记。
Message One (F1)
信息一（F1）
REFER sip:b@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809823 REFER
Max-Forwards: 70
Refer-To: (whatever URI)
Contact: sip:a@atlanta.example.com
Content-Length: 0
REFER sip:b@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809823 REFER
Max-Forwards: 70
Refer-To: (whatever URI)
Contact: sip:a@atlanta.example.com
Content-Length: 0
Message Two (F2)
信息二（F2）
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>;tag=4992881234
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809823 REFER
Contact: sip:b@atlanta.example.com
Content-Length: 0
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223
To: <sip:b@atlanta.example.com>;tag=4992881234
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809823 REFER
Contact: sip:b@atlanta.example.com
Content-Length: 0
Message Three (F3)
信息三（F3）
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993402 NOTIFY
Max-Forwards: 70
Event: refer
Subscription-State: active;expires=(depends on Refer-To URI)
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 20
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993402 NOTIFY
Max-Forwards: 70
Event: refer
Subscription-State: active;expires=(depends on Refer-To URI)
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 20
SIP/2.0 100 Trying
SIP/2.0 100
Message Four (F4)
信息四（F4）
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993402 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993402 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
Message Five (F5)
信息五（F5）
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9323394234
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993403 NOTIFY
Max-Forwards: 70
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9323394234
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993403 NOTIFY
Max-Forwards: 70
Event: refer
Subscription-State: terminated;reason=noresource
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 16
Event: refer
Subscription-State: terminated;reason=noresource
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 16
SIP/2.0 200 OK
SIP/2.0 200正常
Message Six (F6)
信息六（F6）
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9323394234
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993403 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9323394234
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993403 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
Message One above brings an implicit subscription dialog into existence. Suppose Agent A issued a second REFER inside that dialog:
上面的消息1使隐式订阅对话框存在。假设代理A在该对话框中发出了第二个引用：
Agent A Agent B
| |
| F7 REFER |
|----------------------->|
| F8 202 Accepted |
|<-----------------------|
| F9 NOTIFY |
|<-----------------------|
| F10 200 OK |
|----------------------->|
| |------->
| | (something different)
| |<------
| |
| F11 NOTIFY |
|<-----------------------|
| F12 200 OK |
|----------------------->|
| |
| |
Agent A Agent B
| |
| F7 REFER |
|----------------------->|
| F8 202 Accepted |
|<-----------------------|
| F9 NOTIFY |
|<-----------------------|
| F10 200 OK |
|----------------------->|
| |------->
| | (something different)
| |<------
| |
| F11 NOTIFY |
|<-----------------------|
| F12 200 OK |
|----------------------->|
| |
| |
Message Seven (F7)
信息七（F7）
REFER sip:b@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK9390399231
To: <sip:b@atlanta.example.com>;tag=4992881234
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809824 REFER
Max-Forwards: 70
Refer-To: (some different URI)
Contact: sip:a@atlanta.example.com
Content-Length: 0
REFER sip:b@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK9390399231
To: <sip:b@atlanta.example.com>;tag=4992881234
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809824 REFER
Max-Forwards: 70
Refer-To: (some different URI)
Contact: sip:a@atlanta.example.com
Content-Length: 0
Message Eight (F8)
信息八（F8）
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK9390399231
To: <sip:b@atlanta.example.com>;tag=4992881234
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809824 REFER
Contact: sip:b@atlanta.example.com
Content-Length: 0
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK9390399231
To: <sip:b@atlanta.example.com>;tag=4992881234
From: <sip:a@atlanta.example.com>;tag=193402342
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 93809824 REFER
Contact: sip:b@atlanta.example.com
Content-Length: 0
Message Nine (F9)
信息九（F9）
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9320394238995
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993404 NOTIFY
Max-Forwards: 70
Event: refer;id=93809824
Subscription-State: active;expires=(depends on Refer-To URI)
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 20
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9320394238995
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993404 NOTIFY
Max-Forwards: 70
Event: refer;id=93809824
Subscription-State: active;expires=(depends on Refer-To URI)
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 20
SIP/2.0 100 Trying
SIP/2.0 100
Message Ten (F10)
信息十（F10）
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9320394238995
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9320394238995
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993404 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
CSeq: 1993404 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
Message Eleven (F11)
信息11（F11）
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK2994a93eb-fe
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993405 NOTIFY
Max-Forwards: 70
Event: refer;id=93809824
Subscription-State: terminated;reason=noresource
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 16
NOTIFY sip:a@atlanta.example.com SIP/2.0
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK2994a93eb-fe
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993405 NOTIFY
Max-Forwards: 70
Event: refer;id=93809824
Subscription-State: terminated;reason=noresource
Contact: sip:b@atlanta.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: 16
SIP/2.0 200 OK
SIP/2.0 200正常
Message Twelve (F12)
信息十二（F12）
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK2994a93eb-fe
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993405 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK2994a93eb-fe
To: <sip:a@atlanta.example.com>;tag=193402342
From: <sip:b@atlanta.example.com>;tag=4992881234
Call-ID: 898234234@agenta.atlanta.example.com
CSeq: 1993405 NOTIFY
Contact: sip:a@atlanta.example.com
Content-Length: 0
The security considerations described in Section 26 of [1] apply to the REFER transaction. In particular, the implementation requirements and considerations in Section 26.3 address securing a generic SIP transaction. Special consideration is warranted for the authorization polices applied to REFER requests and for the use of message/sipfrag to convey the results of the referenced request.
[1]第26节所述的安全注意事项适用于REFER交易。特别是，第26.3节中的实现要求和注意事项涉及保护通用SIP事务。需要特别考虑应用于引用请求的授权策略，以及使用消息/sipfrag来传达引用请求的结果。
This mechanism relies on providing contact information for the referred-to resource to the party being referred. Care should be taken to provide a suitably restricted URI if the referred-to resource should be protected.
该机制依赖于向被推荐方提供被推荐资源的联系信息。如果引用的资源应该受到保护，则应注意提供适当限制的URI。
As described in Section 2.4.2, an implementation can receive a REFER requests with a Refer-To URI containing an arbitrary scheme. For instance, a user could be referred to an online service such as a MUD using a telnet URI. Customer service could refer a customer to an order tracking web page using an HTTP URI. Section 2.4.2 allows a user agent to reject a REFER request when it can not process the referenced scheme. It also requires the user agent to obtain authorization from its user before attempting to use the URI. Generally, this could be achieved by prompting the user with the full URI and a question such as "Do you wish to access this resource (Y/N)". Of course, URIs can be arbitrarily long and are occasionally constructed with malicious intent, so care should be taken to avoid surprise even in the display of the URI itself (such as partial display or crashing). Further, care should be taken to expose as much information about the reference as possible to the user to mitigate the risk of being misled into a dangerous decision. For instance, the Refer-To header may contain a display name along with the URI. Nothing ensures that any property implied by that display name is shared by the URI. For instance, the display name may contain "secure" or "president" and when the URI indicates sip:agent59@telemarketing.example.com. Thus, prompting the user with the display name alone is insufficient.
如第2.4.2节所述，实现可以接收带有包含任意方案的REFER-REFER URI的REFER请求。例如，用户可以使用telnet URI访问在线服务，如MUD。客户服务可以使用HTTP URI向客户推荐订单跟踪网页。第2.4.2节允许用户代理在无法处理引用的方案时拒绝引用请求。它还要求用户代理在尝试使用URI之前获得其用户的授权。通常，这可以通过向用户提示完整URI和诸如“您希望访问此资源（Y/N）”之类的问题来实现。当然，URI可以是任意长的，并且偶尔是恶意构造的，因此应注意避免在URI本身的显示中出现意外情况（例如部分显示或崩溃）。此外，应注意向用户披露尽可能多的参考信息，以降低被误导做出危险决策的风险。例如，Refer-Refer标头可能包含一个显示名称和URI。没有任何东西可以确保该显示名称所隐含的任何属性都被URI共享。例如，显示名称可以包含“secure”或“president”，并且当URI指示sip时：agent59@telemarketing.example.com. 因此，仅用显示名称提示用户是不够的。
In some cases, the user can provide authorization for some REFER requests ahead of time by providing policy to the user agent. This is appropriate, for instance, for call transfer as discussed in [4]. Here, a properly authenticated REFER request within an existing SIP dialog to a sip:, sips:, or tel: URI may be accepted through policy without interactively obtaining the user's authorization. Similarly, it may be appropriate to accept a properly authenticated REFER to an HTTP URI if the referror is on an explicit list of approved referrors. In the absence of such pre-provided authorization, the user must interactively provide authorization to reference the indicated resource.
在某些情况下，用户可以通过向用户代理提供策略提前为某些REFER请求提供授权。例如，这适用于[4]中讨论的呼叫转移。这里，可以通过策略接受现有SIP对话框中正确认证的对SIP:、sips:、或tel:URI的引用请求，而无需交互地获得用户的授权。类似地，如果referror位于已批准的referror的显式列表中，则接受对HTTP URI的正确身份验证的referre可能是合适的。在没有此类预先提供的授权的情况下，用户必须以交互方式提供引用所指示资源的授权。
To see the danger of a policy that blindly accepts and acts on an HTTP URI, for example, consider a web server configured to accept requests only from clients behind a small organization's firewall. As it sits in this soft-creamy-middle environment where the small organization trusts all its members and has little internal security, the web server is frequently behind on maintenance, leaving it vulnerable to attack through maliciously constructed URIs (resulting perhaps in running arbitrary code provided in the URI). If a SIP UA inside this firewall blindly accepted a reference to an arbitrary HTTP URI, an attacker outside the firewall could compromise the web server. On the other hand, if the UA's user has to take positive
为了看到盲目接受并作用于HTTP URI的策略的危险性，例如，考虑配置为只接受来自小型组织防火墙后面的客户端的请求的Web服务器。由于它位于这种软质的中间环境中，小型组织信任其所有成员，内部安全性很低，因此web服务器经常在维护方面落后，容易受到恶意构造的URI的攻击（可能导致运行URI中提供的任意代码）。如果此防火墙内的SIP UA盲目接受对任意HTTP URI的引用，则防火墙外的攻击者可能会危害web服务器。另一方面，如果UA的用户必须采取积极措施
action (such as responding to a prompt) before acting on this URI, the risk is reduced to the same level as the user clicking on the URI in a web-browser or email message.
操作（例如响应提示）在对该URI执行操作之前，风险会降低到与用户在web浏览器或电子邮件中单击URI相同的级别。
The conclusion in the above paragraph generalizes to URIs with an arbitrary scheme. An agent that takes automated action to access a URI with a given scheme risks being used to indirectly attack another host that is vulnerable to some security flaw related to that scheme. This risk and the potential for harm to that other host is heightened when the host and agent reside behind a common policy-enforcement point such as a firewall. Furthermore, this agent increases its exposure to denial of service attacks through resource exhaustion, especially if each automated action involves opening a new connection.
上述段落中的结论推广到具有任意方案的URI。使用给定方案自动访问URI的代理可能会被用来间接攻击另一台易受与该方案相关的安全漏洞攻击的主机。当主机和代理驻留在公共策略实施点（如防火墙）后面时，这种风险和对其他主机造成伤害的可能性就会增加。此外，此代理通过资源耗尽增加了其遭受拒绝服务攻击的风险，特别是在每个自动操作都涉及打开新连接的情况下。
User agents should take care when handing an arbitrary URI to a third-party service such as that provided by some modern operating systems, particularly if the user agent is not aware of the scheme and the possible ramifications using the protocols it indicates. The opportunity for violating the principal of least surprise is very high.
当用户代理将任意URI传递给第三方服务（如某些现代操作系统提供的服务）时，尤其是当用户代理不知道该方案以及使用其指示的协议可能产生的后果时，用户代理应该小心。违反最小意外原则的机会非常高。
Using message/sipfrag bodies to return the progress and results of a REFER request is extremely powerful. Careless use of that capability can compromise confidentiality and privacy. Here are a couple of simple, somewhat contrived, examples to demonstrate the potential for harm.
使用message/sipfrag body返回REFER请求的进度和结果是非常强大的。不小心使用该功能可能会损害机密性和隐私。这里有几个简单的，有点做作的例子来证明潜在的危害。
Suppose Alice has a user agent that accepts REFER requests to SIP INVITE URIs, and NOTIFYs the referrer of the progress of the INVITE by copying each response to the INVITE into the body of a NOTIFY.
假设Alice有一个用户代理，它接受SIP INVITE URI的REFER请求，并通过将对INVITE的每个响应复制到NOTIFY的主体中来通知REFER INVITE的进度。
Suppose further that Carol has a reason to avoid Mallory and has configured her system at her proxy to only accept calls from a certain set of people she trusts (including Alice), so that Mallory doesn't learn when she's around, or what user agent she's actually using.
进一步假设Carol有理由避开Mallory，并且在她的代理服务器上配置了她的系统，只接受她信任的某一组人（包括Alice）的呼叫，这样Mallory就不会知道她在什么时候，或者她实际使用的是什么用户代理。
Mallory can send a REFER to Alice, with a Refer-To URI indicating Carol. If Alice can reach Carol, the 200 OK Carol sends gets returned to Mallory in a NOTIFY, letting him know not only that Carol is around, but also the IP address of the agent she's using.
Mallory可以发送一个referetoAlice，referetoURI表示Carol。如果Alice能联系到Carol，Carol发送的200 OK会在通知中返回给Mallory，让他不仅知道Carol在附近，还知道她正在使用的代理的IP地址。
Suppose Alice, with the same user agent as above, is working at a company that is working on the greatest SIP device ever invented - the SIP FOO. The company has been working for months building the device and the marketing materials, carefully keeping the idea, even the name of the idea secret (since a FOO is one of those things that anybody could do if they'd just had the idea first). FOO is up and running, and anyone at the company can use it, but it's not available outside the company firewall.
假设Alice使用与上述相同的用户代理，在一家公司工作，该公司正在开发有史以来最伟大的SIP设备——SIP FOO。该公司已经花了数月的时间制作设备和营销材料，小心翼翼地保守这个想法，甚至是这个想法的名字（因为FOO是任何人都可以做的事情之一，只要他们首先有了这个想法）。FOO已经启动并运行，公司的任何人都可以使用它，但在公司防火墙之外是不可用的。
Mallory has heard rumor that Alice's company is onto something big, and has even managed to get his hands on a URI that he suspects might have something to do with it. He sends a REFER to ALICE with the mysterious URI and as Alice connects to the FOO, Mallory gets NOTIFYs with bodies containing
马洛里听到谣言说爱丽丝的公司正在做一件大事，甚至设法弄到了一个他怀疑可能与之有关的URI。他发送了一个带有神秘URI的REFER-to-ALICE，当ALICE连接到FOO时，Mallory收到包含
Server: FOO/v0.9.7
服务器：FOO/v0.9.7
For each of these cases, and in general, returning a carefully selected subset of the information available about the progress of the reference through the NOTIFYs mitigates risk. The minimal implementation described in Section 2.4.5 exposes the least information about what the agent operating on the REFER request has done, and is least likely to be a useful tool for malicious users.
对于这些情况中的每一种，一般来说，通过NOTIFYs返回有关参考进度的精心挑选的可用信息子集可以降低风险。第2.4.5节中描述的最小实现公开了有关代理对REFER请求所做操作的最少信息，并且对于恶意用户来说，它最不可能是一个有用的工具。
The mechanism defined in this specification is not directly susceptible to abuse through copying the message/sipfrag bodies from NOTIFY requests and inserting them, in whole or in part, in future NOTIFY requests associated with the same or a different REFER. Under this specification the agent replying to the REFER request is in complete control of the content of the bodies of the NOTIFY it sends. There is no mechanism defined here requiring this agent to faithfully forward any information from the referenced party. Thus, saving a body for later replay gives the agent no more ability to affect the mechanism defined in this document at its peer than it has without that body. Similarly, capture of a message/sipfrag body by eavesdroppers will give them no more ability to affect this mechanism than they would have without it.
通过从NOTIFY请求复制消息/sipfrag主体并将其全部或部分插入与相同或不同引用关联的未来NOTIFY请求，本规范中定义的机制不会直接受到滥用。根据该规范，响应REFER请求的代理完全控制其发送的NOTIFY的主体内容。此处未定义要求该代理忠实转发被引用方的任何信息的机制。因此，保存一个主体以备以后重播，这样代理就不会像没有该主体时那样，在其对等方影响本文档中定义的机制。类似地，窃听者捕获消息/sipfrag主体将不会给他们带来更多的能力来影响这种机制，就像没有它一样。
Future extensions may place additional constraints on the agent responding to REFER to allow using the message/sipfrag body part in a NOTIFY to make statements like "I contacted the party you referred me to, and here's cryptographic proof". These statements might be used
未来的扩展可能会对响应reference的代理施加额外的限制，以允许在NOTIFY中使用message/sipfrag body部分来做出诸如“我联系了您所指的一方，这里是加密证明”之类的声明。可以使用这些语句
to affect the behavior of the receiving UA. This kind of extension will need to define additional mechanism to protect itself from copy based attacks.
影响接收UA的行为。这种扩展需要定义额外的机制来保护自身免受基于拷贝的攻击。
This method was initially motivated by the call-transfer application. Starting as TRANSFER, and later generalizing to REFER, this method improved on the BYE/Also concept of the expired draft-ietf-sip-cc-01 by disassociating transfers from the processing of BYE. These changes facilitate recovery of failed transfers and clarify state management in the participating entities.
此方法最初由呼叫转移应用程序驱动。该方法从传输开始，后来推广到引用，通过将传输与BYE处理分离，改进了过期草案-ietf-sip-cc-01的BYE/ALL概念。这些变化有助于恢复失败的转让，并澄清参与实体的国家管理。
Early versions of this work required the agent responding to REFER to wait until the referred action completed before sending a final response to the REFER. That final response reflected the success or failure of the referred action. This was infeasible due to the transaction timeout rules defined for non-INVITE requests in [1]. A REFER must always receive an immediate (within the lifetime of a non-INVITE transaction) final response.
这项工作的早期版本要求响应refere的代理在向refere发送最终响应之前，等待所引用的操作完成。最后的答复反映了所述行动的成败。这是不可行的，因为[1]中为非INVITE请求定义了事务超时规则。refere必须始终收到即时（在非INVITE事务的生存期内）最终响应。
This document defines a new SIP method name (REFER), a new SIP header field name with a compact form (Refer-To and r respectively), and an event package (refer).
本文档定义了一个新的SIP方法名（REFER）、一个具有紧凑形式的新SIP头字段名（分别为REFER和r）和一个事件包（REFER）。
The following has been added to the method sub-registry under http://www.iana.org/assignments/sip-parameters.
以下内容已添加到下的方法子注册表中http://www.iana.org/assignments/sip-parameters.
REFER [RFC3515]
参考[RFC3515]
The following information also has been be added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.
以下信息也已添加到标题子注册表中http://www.iana.org/assignments/sip-parameters.
Header Name: Refer-To
标题名称：请参阅
Compact Form: r
紧凑型：r
Reference: RFC 3515
参考：RFC3515
This specification registers an event package, based on the registration procedures defined in [2]. The following is the information required for such a registration:
本规范根据[2]中定义的注册过程注册事件包。以下是此类注册所需的信息：
Package Name: refer
包装名称：请参阅
Package or Package-Template: This is a package.
包或包模板：这是一个包。
Published Specification: RFC 3515
已发布规范：RFC3515
Person to Contact: Robert Sparks, rsparks@dynamicsoft.com
联系人：罗伯特·斯帕克斯，rsparks@dynamicsoft.com
This document is a collaborative product of the SIP working group.
本文件是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] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[3] Sparks，R.，“互联网媒体类型信息/sipfrag”，RFC 3420，2002年11月。
[4] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", Work in Progress.
[4] Sparks，R.和A.Johnston，“会话启动协议呼叫控制-传输”，正在进行中。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024
Robert J.Sparks dynamicsoft 5100田纳西州普莱诺市坦尼生大道1200号套房，邮编75024
EMail: rsparks@dynamicsoft.com
EMail: rsparks@dynamicsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。