Network Working Group G. Camarillo
Request for Comments: 5368 Ericsson
Category: Standards Track A. Niemi
M. Isomaki
Nokia
M. Garcia-Martin
Ericsson
H. Khartabil
Ericsson Australia
October 2008
Network Working Group G. Camarillo
Request for Comments: 5368 Ericsson
Category: Standards Track A. Niemi
M. Isomaki
Nokia
M. Garcia-Martin
Ericsson
H. Khartabil
Ericsson Australia
October 2008
Referring to Multiple Resources in the Session Initiation Protocol (SIP)
引用会话启动协议（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）。本备忘录的分发不受限制。
Abstract
摘要
This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request. These extensions include the use of pointers to Uniform Resource Identifier (URI) lists in the Refer-To header field and the "multiple-refer" SIP option-tag.
本文档定义了SIP REFER方法的扩展，以便可以使用它在单个请求中引用多个资源。这些扩展包括使用指向引用头字段和“多引用”SIP选项标记中的统一资源标识符（URI）列表的指针。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . . 4
5. Suppressing REFER's Implicit Subscription . . . . . . . . . . 4
6. URI-List Format . . . . . . . . . . . . . . . . . . . . . . . 5
7. Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . . . 6
8. Behavior of REFER-Recipients . . . . . . . . . . . . . . . . . 6
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . . 4
5. Suppressing REFER's Implicit Subscription . . . . . . . . . . 4
6. URI-List Format . . . . . . . . . . . . . . . . . . . . . . . 5
7. Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . . . 6
8. Behavior of REFER-Recipients . . . . . . . . . . . . . . . . . 6
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11
RFC 3261 (SIP) [RFC3261] is extended by RFC 3515 [RFC3515] with a REFER method that allows a user agent (UA) to request a second UA to send a SIP request to a third party. For example, if Alice is in a call with Bob, and decides Bob needs to talk to Carol, Alice can instruct her SIP UA to send a 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. That is, it will send an INVITE request to that contact.
RFC 3261（SIP）[RFC3261]由RFC 3515[RFC3515]使用REFER方法扩展，该方法允许用户代理（UA）请求第二UA向第三方发送SIP请求。例如，如果Alice正在与Bob通话，并且确定Bob需要与Carol通话，Alice可以指示她的SIP UA向Bob的UA发送转介请求，提供Carol的SIP联系信息。假设Bob允许，Bob的UA将尝试使用该联系人给Carol打电话。也就是说，它将向该联系人发送邀请请求。
A number of applications need to request this second UA to initiate transactions towards a set of destinations. In one example, the moderator of a conference may want the conference server to send BYE requests to a group of participants. In another example, the same moderator may want the conference server to INVITE a set of new participants.
许多应用程序需要请求第二个UA向一组目的地发起事务。在一个示例中，会议主持人可能希望会议服务器向一组参与者发送BYE请求。在另一个示例中，同一主持人可能希望会议服务器邀请一组新参与者。
We define an extension to the REFER method so that REFER requests can be used to refer other user agents (such as conference servers) to multiple destinations. In addition, this mechanism uses the suppression of the REFER method implicit subscription specified in RFC 4488 [RFC4488].
我们定义了REFER方法的扩展，以便REFER请求可用于将其他用户代理（如会议服务器）引用到多个目的地。此外，此机制使用RFC 4488[RFC4488]中指定的REFER方法隐式订阅的抑制。
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 BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的描述进行解释，并指出合规实施的要求级别。
This document reuses the following terminology defined in RFC 3261 [RFC3261]:
本文件重复使用RFC 3261[RFC3261]中定义的以下术语：
o User Agent (UA) o User Agent Client (UAC) o User Agent Server (UAS)
o 用户代理（UA）o用户代理客户端（UAC）o用户代理服务器（UAS）
This document defines the following new terms:
本文件定义了以下新术语：
REFER-Issuer: a user agent issuing a REFER request.
引用颁发者：发出引用请求的用户代理。
REFER-Recipient: an entity receiving a REFER request and forwarding a SIP request to a number of REFER-Targets. The REFER-Recipient is typically a network entity, such as a URI-list server, that acts as a UAS for REFER requests and as a UAC for other SIP requests.
参考接收者：接收参考请求并将SIP请求转发给多个参考目标的实体。refererecipient通常是一个网络实体，例如URI列表服务器，它充当refere请求的UAS和其他SIP请求的UAC。
REFER-Target: a UA of the intended final recipient of a SIP request generated by the REFER-Recipient.
参考目标：由参考接收者生成的SIP请求的预期最终接收者的UA。
This document describes an application of URI-list services [RFC5363] that allows a URI-list service to receive a SIP REFER request containing a list of targets. The URI-list service invokes the requested SIP method to each of the targets contained in the list. This type of URI-list service is referred to as a REFER-Recipient throughout this document.
本文档描述了URI列表服务[RFC5363]的应用程序，该应用程序允许URI列表服务接收包含目标列表的SIP REFER请求。URI列表服务对列表中包含的每个目标调用请求的SIP方法。在本文档中，这种类型的URI列表服务被称为refererecipient。
This document defines an extension to the SIP REFER method specified in RFC 3515 [RFC3515] that allows a SIP UAC to include a URI list as specified in RFC 4826 [RFC4826] of REFER-Targets in a REFER request and send it to a REFER-Recipient. The REFER-Recipient creates a new SIP request for each entry in the URI list and sends it to each REFER-Recipient.
本文档定义了对RFC 3515[RFC3515]中指定的SIP REFER方法的扩展，该扩展允许SIP UAC在REFER请求中包括RFC 4826[RFC4826]中指定的REFER目标的URI列表，并将其发送给REFER接收方。refererecipient为URI列表中的每个条目创建一个新的SIP请求，并将其发送给每个refererecipient。
The URI list that contains the list of targets is used in conjunction with RFC 5364 [RFC5364] to allow the sender indicate the role (e.g., 'to', 'cc', or anonymous) in which the REFER-Target is involved in the signalling.
包含目标列表的URI列表与RFC 5364[RFC5364]一起使用，以允许发送方指示引用目标在信令中所涉及的角色（例如，“收件人”、“抄送”或匿名）。
We represent multiple targets of a REFER request using a URI list as specified in RFC 4826 [RFC4826]. A REFER-Issuer that wants to refer a REFER-Recipient to a set of destinations creates a SIP REFER request. The Refer-To header contains a pointer to a URI list, which is included in a body part, and an option-tag in the Require header field: "multiple-refer". This option-tag indicates the requirement to support the functionality described in this specification.
我们使用RFC 4826[RFC4826]中指定的URI列表表示REFER请求的多个目标。要将引用收件人引用到一组目的地的引用颁发者创建SIP引用请求。Refer-Refer标头包含一个指向URI列表的指针，该列表包含在主体部分中，并在Require标头字段中包含一个选项标记：“multiple-Refer”。此选项标签表示支持本规范所述功能的要求。
When the REFER-Recipient receives such a request, it creates a new request per REFER-Target and sends them, one to each REFER-Target.
当refererecipient收到这样的请求时，它会为每个referetarget创建一个新的请求，并向每个referetarget发送一个请求。
This document does not provide any mechanism for REFER-Issuers to find out about the results of a REFER request containing multiple REFER-Targets. Furthermore, it does not provide support for the implicit subscription mechanism that is part of the SIP REFER method. The way REFER-Issuers are kept informed about the results of a REFER is service specific. For example, a REFER-Issuer sending a REFER request to invite a set of participants to a conference can discover which participants were successfully brought into the conference by subscribing to the conference state event package specified in RFC 4575 [RFC4575].
本文件未为转介发行人提供任何机制，以了解包含多个转介目标的转介请求的结果。此外，它不支持作为SIP REFER方法一部分的隐式订阅机制。转介发行人了解转介结果的方式是特定于服务的。例如，通过订阅RFC 4575[RFC4575]中指定的会议状态事件包，发送REFER请求以邀请一组参与者参加会议的REFER发卡机构可以发现哪些参与者已成功加入会议。
We define a new SIP option-tag for the Require and Supported header fields: "multiple-refer".
我们为Require和Supported头字段定义了一个新的SIP选项标记：“multiple refere”。
A user agent including the "multiple-refer" option-tag in a Supported header field indicates compliance with this specification.
在受支持的标题字段中包含“多个引用”选项标记的用户代理表示符合本规范。
A user agent generating a REFER with a pointer to a URI list in its Refer-To header field MUST include the "multiple-refer" option-tag in the Require header field of the REFER.
生成引用的用户代理在其引用标头字段中使用指向URI列表的指针，必须在引用的Require标头字段中包含“multiple refere”选项标记。
REFER requests with a single REFER-Target establish implicitly a subscription to the refer event. The REFER-Issuer is informed about the result of the transaction towards the REFER-Target through this implicit subscription. As described in RFC 3515 [RFC3515], NOTIFY requests sent as a result of an implicit subscription created by a REFER request contain a body of type "message/sipfrag", RFC 3420 [RFC3420], that describes the status of the transaction initiated by the REFER-Recipient.
具有单个REFER目标的REFER请求隐式地建立对REFER事件的订阅。转介发行人通过该隐式认购被告知转介目标的交易结果。如RFC 3515[RFC3515]所述，由于REFER请求创建的隐式订阅而发送的NOTIFY请求包含类型为“message/sipfrag”的主体RFC 3420[RFC3420]，该主体描述了REFER接收方发起的事务的状态。
In the case of a REFER-Issuer that generates a REFER with multiple REFER-targets, the REFER-Issuer is typically already subscribed to other event packages that can provide the information about the result of the transactions towards the REFER-Targets. For example, a moderator instructing a conference server to send a BYE request to a set of participants is usually subscribed to the conference state event package for the conference. Notifications to this event package will keep the moderator and the rest of the subscribers informed of the current list of conference participants.
对于生成具有多个参考目标的参考的参考发行人，参考发行人通常已经订阅了其他事件包，这些事件包可以提供关于针对参考目标的交易结果的信息。例如，主持人指示会议服务器向一组参与者发送BYE请求，通常订阅会议的会议状态事件包。此活动包的通知将使主持人和其他订阅者了解会议参与者的当前名单。
Most of the applications using the multiple REFER technology described in this memo do not need its implicit subscription. Consequently, a SIP REFER-Issuer generating a REFER request with multiple REFER-Targets SHOULD include the "norefersub" option-tag in a Require header field and SHOULD include a Refer-Sub header field set to "false" to indicate that no notifications about the requests should be sent to the REFER-Issuer. The REFER-Recipient SHOULD honor the suggestion and also include a Refer-Sub header field set to "false" in the 200 (OK) response. The "norefersub" SIP option-tag and the Refer-Sub header field are specified in RFC 4488 [RFC4488].
使用本备忘录中描述的多引用技术的大多数应用程序不需要隐式订阅。因此，生成具有多个refere目标的refere请求的SIP refere颁发者应在Require报头字段中包括“norefersub”选项标记，并应包括设置为“false”的refere Sub报头字段，以指示不应向refere颁发者发送关于请求的通知。推荐接收人应尊重该建议，并在200（确定）响应中包含一个设置为“false”的推荐子标题字段。RFC 4488[RFC4488]中指定了“norefersub”SIP选项标记和Refer Sub报头字段。
RFC 4488 [RFC4488] indicates that a condition for the REFER-Issuer to include a Refer-Sub header is that the REFER-Issuer is sure that the REFER request will not fork.
RFC 4488[RFC4488]表示REFER发卡机构包含REFER子报头的条件是REFER发卡机构确保REFER请求不会分叉。
At the time of writing, there is no extension that allows to report the status of several transactions over the implicit subscription associated with a REFER dialog. That is the motivation for this document to recommend the usage of the "norefersub" option-tag. If in the future such an extension is defined, REFER-Issuers using it could refrain from using the "norefersub" option-tag and use the new extension instead.
在编写本文时，没有允许通过与引用对话框关联的隐式订阅报告多个事务状态的扩展。这就是本文档推荐使用“norefersub”选项标记的动机。如果将来定义了此类扩展，则使用该扩展的发行人可以避免使用“norefersub”选项标签，而使用新的扩展。
As described in RFC 5363 [RFC5363], specifications of individual URI-list services need to specify a default format for 'recipient-list' bodies used within the particular service.
如RFC 5363[RFC5363]所述，单个URI列表服务的规范需要为特定服务中使用的“收件人列表”主体指定默认格式。
The default format for 'recipient-list' bodies for REFER-Issuers and REFER-Recipients is RFC 4826 [RFC4826] extended with RFC 5364 [RFC5364]. REFER-Recipients handling 'recipient-list' bodies MUST support both of these formats. Both REFER-Issuers and REFER-Recipients MAY support other formats.
转介发行人和转介接收人的“收件人列表”主体的默认格式为RFC 4826[RFC4826]，扩展为RFC 5364[RFC5364]。处理“收件人列表”正文的引用收件人必须支持这两种格式。推荐发行人和推荐接收人都可能支持其他格式。
As described in RFC 5364 [RFC5364], each URI can be tagged with a 'copyControl' attribute set to either "to", "cc", or "bcc", indicating the role in which the target will get the referred SIP request. However, depending on the target SIP method, a 'copyControl' attribute lacks sense. For example, while a 'copyControl' attribute can be applied to INVITE requests, it does not make sense with mid-dialog requests such as BYE requests.
如RFC 5364[RFC5364]中所述，每个URI都可以使用设置为“to”、“cc”或“bcc”的“copyControl”属性进行标记，以指示目标将在其中获得引用的SIP请求的角色。但是，根据目标SIP方法，“copyControl”属性缺乏意义。例如，虽然“copyControl”属性可以应用于INVITE请求，但对于中间对话请求（如BYE请求）来说，它没有意义。
In addition to the 'copyControl' attribute, URIs can be tagged with the 'anonymize' attribute (also specified in RFC 5364 [RFC5364]) to prevent that the REFER-Recipient discloses the target URI in a URI list.
除了“copyControl”属性外，URI还可以标记为“匿名化”属性（也在RFC 5364[RFC5364]中指定），以防止引用收件人在URI列表中披露目标URI。
Additionally, RFC 5364 [RFC5364] defines a 'recipient-list-history' body that contains the list of targets. The default format for 'recipient-list-history' bodies for conference services is also RFC 4826 [RFC4826] extended with RFC 5364 [RFC5364]. REFER-Recipients supporting this specification MUST support both of these formats; REFER-Targets MAY support these formats. Both REFER-Recipients and REFER-Targets MAY support other formats.
此外，RFC 5364[RFC5364]定义了包含目标列表的“收件人列表历史记录”正文。会议服务的“收件人列表历史记录”主体的默认格式也是RFC 4826[RFC4826]，扩展为RFC 5364[RFC5364]。支持本规范的收件人必须同时支持这两种格式；参考目标可能支持这些格式。引用收件人和引用目标都可能支持其他格式。
Nevertheless, RFC 4826 [RFC4826] provides features, such as hierarchical lists and the ability to include entries by reference relative to the XML Configuration Access Protocol (XCAP) root URI, that are not needed by the multiple REFER service defined in this document.
尽管如此，RFC 4826[RFC4826]提供了本文档中定义的多引用服务不需要的功能，例如分层列表和通过引用包含与XML配置访问协议（XCAP）根URI相关的条目的能力。
Figure 1 shows an example of a flat list that follows the resource list document.
图1显示了资源列表文档后面的平面列表示例。
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
</list>
</resource-lists>
<list>
<entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
</list>
</resource-lists>
Figure 1: URI list
图1:URI列表
As indicated in Sections 4 and 5, a SIP REFER-Issuer that creates a REFER request with multiple REFER-Targets includes a "multiple-refer" and "norefersub" option-tags in the Require header field and, if appropriate, a Refer-Sub header field set to "false". The REFER-Issuer includes the set of REFER-Targets in a recipient-list body whose disposition type is 'recipient-list', as defined in RFC 5363 [RFC5363]. The URI-list body is further described in Section 6.
如第4节和第5节所述，创建具有多个引用目标的引用请求的SIP引用颁发者在Require标头字段中包括“multiple refere”和“norefersub”选项标记，如果合适，还包括设置为“false”的引用子标头字段。如RFC 5363[RFC5363]中所定义，推荐发行人在处置类型为“收件人列表”的收件人列表主体中包括一组推荐目标。URI列表主体将在第6节中进一步描述。
The Refer-To header field of a REFER request with multiple REFER-Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part that carries the URI list. The REFER-Issuer SHOULD NOT include any particular URI more than once in the URI list.
具有多个引用目标的引用请求的引用头字段必须包含指向承载URI列表的主体部分的指针（即，根据RFC 2392[RFC2392]的内容ID统一资源定位器（URL））。引用颁发者不应在URI列表中多次包含任何特定URI。
RFC 4826 [RFC4826] provides features, such as hierarchical lists and the ability to include entries by reference relative to the XCAP root URI. However, these features are not needed by the multiple REFER service defined in this document. Therefore, when using the default resource list document, SIP REFER-Issuers generating REFER requests with multiple REFER-Targets SHOULD use flat lists (i.e., no hierarchical lists) and SHOULD NOT use <entry-ref> elements.
RFC 4826[RFC4826]提供了一些特性，例如分层列表和通过引用包含相对于XCAP根URI的条目的能力。但是，本文档中定义的多重引用服务不需要这些功能。因此，当使用默认资源列表文档时，生成具有多个REFER目标的REFER请求的SIP REFER颁发者应使用平面列表（即，无分层列表），而不应使用<entry ref>元素。
The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515 [RFC3515] to determine the status code of the response to the REFER.
参考接收人遵循RFC 3515[RFC3515]第2.4.2节中的规则确定参考响应的状态代码。
The REFER-Recipient SHOULD not create an implicit subscription, and SHOULD add a Refer-Sub header field set to "false" in the 200 OK response.
refererecipient不应创建隐式订阅，而应在200ok响应中添加一个设置为“false”的referesubheader字段。
The incoming REFER request typically contains a URI-list document or reference with the actual list of targets. If this URI list includes resources tagged with the 'copyControl' attribute set to a value of "to" or "cc", and if the request is appropriate for the service, e.g., it is not received mid-dialog, the REFER-Recipient SHOULD include a URI list in each of the outgoing requests. This list SHOULD be formatted according to RFC 4826 [RFC4826] and RFC 5364 [RFC5364]. The REFER-Recipient MUST follow the procedures specified in RFC 4826 [RFC4826] with respect to handling of the 'anonymize', 'count', and 'copyControl' attributes.
传入的REFER请求通常包含一个URI列表文档或带有实际目标列表的引用。如果此URI列表包含标记有“copyControl”属性的资源，该属性的值设置为“to”或“cc”，并且如果请求适合于服务，例如，在对话框中未收到请求，则引用收件人应在每个传出请求中包含URI列表。该列表应根据RFC 4826[RFC4826]和RFC 5364[RFC5364]进行格式化。转介收件人必须遵循RFC 4826[RFC4826]中规定的有关处理“匿名化”、“计数”和“复制控制”属性的程序。
Section 4 of RFC 5363 [RFC5363] discusses cases when duplicated URIs are found in a URI list. In order to avoid duplicated requests, REFER-Recipients MUST take those actions specified in RFC 5363 [RFC5363] into account to avoid sending a duplicated request to the same target.
RFC 5363[RFC5363]的第4节讨论了在URI列表中发现重复URI的情况。为了避免重复请求，参考收件人必须考虑RFC 5363[RFC5363]中指定的操作，以避免向同一目标发送重复请求。
If the REFER-Recipient includes a URI list in an outgoing request, it MUST include a Content-Disposition header field, specified in RFC 2183 [RFC2183], with the value set to 'recipient-list-history' and a 'handling' parameter, specified in RFC 3204 [RFC3204], set to "optional".
如果引用收件人在传出请求中包含URI列表，则必须包含RFC 2183[RFC2183]中指定的内容处置头字段，其值设置为“收件人列表历史记录”，并且RFC 3204[RFC3204]中指定的“处理”参数设置为“可选”。
Since the multiple REFER service does not use hierarchical lists nor lists that include entries by reference to the XCAP root URI, a REFER-Recipient receiving a URI list with more information than what has been described in Section 6 MAY discard all the extra information.
由于多重引用服务不使用分层列表，也不使用通过引用XCAP根URI包含条目的列表，因此接收到比第6节中描述的信息更多的URI列表的引用接收方可能会丢弃所有额外信息。
The REFER-Recipient follows the rules in RFC 3515 [RFC3515] to generate the necessary requests towards the REFER-Targets, acting as if it had received a regular (no URI list) REFER per each URI in the URI list.
refererecipient遵循RFC 3515[RFC3515]中的规则生成指向refere目标的必要请求，就好像它已经收到了针对URI列表中每个URI的常规（无URI列表）refere一样。
Figure 2 shows an example flow where a REFER-Issuer sends a multiple-REFER request to the focus of a conference, which acts as the REFER-Recipient. The REFER-Recipient generates a BYE request per REFER-Target. Details for using REFER request to remove participants from a conference are specified in RFC 4579 [RFC4579].
图2显示了一个示例流程，其中REFER发卡机构向会议的焦点发送多个REFER请求，会议的焦点充当REFER接收方。REFER收件人为每个REFER目标生成BYE请求。RFC 4579[RFC4579]中规定了使用REFER请求从会议中删除参与者的详细信息。
+--------+ +---------+ +--------+ +--------+ +--------+
| REFER | | REFER | | REFER | | REFER | | REFER |
| issuer | |recipient| |target 1| |target 2| |target 3|
| | | | | | | | | |
| Carol | | (focus) | | Bill | | Joe | | Ted |
+--------+ +---------+ +--------+ +--------+ +--------+
| 1. REFER | | | |
| ---------------->| | | |
| 2. 202 Accepted | | | |
|<---------------- | 3. BYE | | |
| | ----------->| | |
| | 4. BYE | | |
| | ----------------------->| |
| | 5. BYE | | |
| | ----------------------------------->|
| | 6. 200 OK | | |
| |<----------- | | |
| | 7. 200 OK | | |
| |<----------------------- | |
| | 8. 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
+--------+ +---------+ +--------+ +--------+ +--------+
| REFER | | REFER | | REFER | | REFER | | REFER |
| issuer | |recipient| |target 1| |target 2| |target 3|
| | | | | | | | | |
| Carol | | (focus) | | Bill | | Joe | | Ted |
+--------+ +---------+ +--------+ +--------+ +--------+
| 1. REFER | | | |
| ---------------->| | | |
| 2. 202 Accepted | | | |
|<---------------- | 3. BYE | | |
| | ----------->| | |
| | 4. BYE | | |
| | ----------------------->| |
| | 5. BYE | | |
| | ----------------------------------->|
| | 6. 200 OK | | |
| |<----------- | | |
| | 7. 200 OK | | |
| |<----------------------- | |
| | 8. 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 2: Example flow of a REFER request containing multiple REFER-Targets
图2：包含多个REFER目标的REFER请求的示例流程
The REFER request (1) contains a Refer-To header field that includes a pointer to the message body, which carries a list with the URIs of the REFER-Targets. In this example, the URI list does not contain the 'copyControl' attribute extension. The REFER's Require header field carries the "multiple-refer" and "norefersub" option-tags. The Request-URI is set to a Globally Routable User Agent URI (GRUU) [SIP-GRUU] (as a guarantee that the REFER request will not fork). The Refer-Sub header field is set to "false" to request the suppression of the implicit subscription. Figure 3 shows an example of this REFER request. The resource list document contains the list of REFER-Target URIs along with the method of the SIP request that the REFER-Recipient generates.
REFER请求（1）包含一个REFER REFER头字段，该字段包含一个指向消息体的指针，该指针携带一个带有REFER目标URI的列表。在本例中，URI列表不包含“copyControl”属性扩展名。REFER的Require标头字段带有“多个REFER”和“norefersub”选项标记。请求URI被设置为全局可路由用户代理URI（GRUU）[SIP-GRUU]（作为REFER请求不会分叉的保证）。Refer Sub header字段设置为“false”以请求抑制隐式订阅。图3显示了该REFER请求的示例。资源列表文档包含引用目标URI的列表以及引用接收方生成的SIP请求的方法。
REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0
Via: SIP/2.0/TCP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: "Conference 123" <sip:conf-123@example.com>
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 2 REFER
Contact: <sip:carol@client.chicago.example.com>
Refer-To: <cid:cn35t8jf02@example.com>
Refer-Sub: false
Require: multiple-refer, norefersub
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-Length: 362
Content-ID: <cn35t8jf02@example.com>
REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0
Via: SIP/2.0/TCP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: "Conference 123" <sip:conf-123@example.com>
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 2 REFER
Contact: <sip:carol@client.chicago.example.com>
Refer-To: <cid:cn35t8jf02@example.com>
Refer-Sub: false
Require: multiple-refer, norefersub
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
Content-Length: 362
Content-ID: <cn35t8jf02@example.com>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:bill@example.com?method=BYE" />
<entry uri="sip:joe@example.org?method=BYE" />
<entry uri="sip:ted@example.net?method=BYE" />
</list>
</resource-lists>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:bill@example.com?method=BYE" />
<entry uri="sip:joe@example.org?method=BYE" />
<entry uri="sip:ted@example.net?method=BYE" />
</list>
</resource-lists>
Figure 3: REFER request with multiple REFER-Targets
图3：具有多个REFER目标的REFER请求
Figure 4 shows an example of the BYE request (3) that the REFER-Recipient sends to the first REFER-Target.
图4显示了REFER接收方发送给第一个REFER目标的BYE请求（3）的示例。
BYE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP conference.example.com
;branch=z9hG4bKhjhs8assmm
Max-Forwards: 70
From: "Conference 123" <sip:conf-123@example.com>;tag=88734
To: <sip:bill@example.com>;tag=29872
Call-ID: d432fa84b4c34098s812
CSeq: 34 BYE
Content-Length: 0
BYE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP conference.example.com
;branch=z9hG4bKhjhs8assmm
Max-Forwards: 70
From: "Conference 123" <sip:conf-123@example.com>;tag=88734
To: <sip:bill@example.com>;tag=29872
Call-ID: d432fa84b4c34098s812
CSeq: 34 BYE
Content-Length: 0
Figure 4: BYE request
图4：BYE请求
RFC 5363 [RFC5363] discusses issues related to SIP URI-list services. Given that a REFER-Recipient accepting REFER requests with multiple REFER-targets acts as a URI-list service, implementations of this type of server MUST follow the security-related rules in RFC 5363 [RFC5363]. These rules include opt-in lists and mandatory authentication and authorization of clients.
RFC 5363[RFC5363]讨论与SIP URI列表服务相关的问题。假设接受具有多个引用目标的引用请求的引用收件人充当URI列表服务，则此类服务器的实现必须遵循RFC 5363[RFC5363]中的安全相关规则。这些规则包括选择加入列表和客户端的强制身份验证和授权。
Additionally, REFER-Recipients SHOULD only accept REFER requests within the context of an application that the REFER-Recipient understands (e.g., a conferencing application). This implies that REFER-Recipients MUST NOT accept REFER requests for methods they do not understand. The idea behind these two rules is that REFER-Recipients are not used as dumb servers whose only function is to fan-out random messages they do not understand.
此外，推荐收件人应仅在推荐收件人理解的应用程序（例如，会议应用程序）的上下文中接受推荐请求。这意味着引用收件人不得接受对其不理解的方法的引用请求。这两条规则背后的思想是，refererecipients不被用作哑服务器，其唯一功能是散播他们不理解的随机消息。
This document defines a new SIP option-tag: "multiple-refer". This option-tag has been registered in the SIP Parameters registry.
本文档定义了一个新的SIP选项标记：“多重引用”。此选项标记已在SIP参数注册表中注册。
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
以下行已添加到SIP参数注册表的“选项标记”部分：
+-----------------+-------------------------------------+-----------+
| Name | Description | Reference |
+-----------------+-------------------------------------+-----------+
| multiple-refer | This option tag indicates support | [RFC5368] |
| | for REFER requests that contain a | |
| | resource list document describing | |
| | multiple REFER targets. | |
+-----------------+-------------------------------------+-----------+
+-----------------+-------------------------------------+-----------+
| Name | Description | Reference |
+-----------------+-------------------------------------+-----------+
| multiple-refer | This option tag indicates support | [RFC5368] |
| | for REFER requests that contain a | |
| | resource list document describing | |
| | multiple REFER targets. | |
+-----------------+-------------------------------------+-----------+
Table 1: Registration of the 'multiple-refer' option-tag in SIP
表1:SIP中“多重引用”选项标记的注册
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183]Troost，R.，Dorner，S.，和K.Moore，“在Internet消息中传递表示信息：内容处置头字段”，RFC 2183，1997年8月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]Levinson，E.“内容ID和消息ID统一资源定位器”，RFC 2392，1998年8月。
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
[RFC3204]Zimmerer，E.，Peterson，J.，Vemuri，A.，Ong，L.，Audet，F.，Watson，M.，和M.Zonoun，“ISUP和QSIG对象的MIME媒体类型”，RFC 32042001年12月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[RFC3420]Sparks，R.，“互联网媒体类型消息/sipfrag”，RFC 3420，2002年11月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription", RFC 4488, May 2006.
[RFC4488]Levin，O.“会话启动协议（SIP）的抑制是指方法隐式订阅”，RFC 4488，2006年5月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]Rosenberg，J.，“用于表示资源列表的可扩展标记语言（XML）格式”，RFC 4826，2007年5月。
[RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services", RFC 5363, October 2008.
[RFC5363]Camarillo，G.和A.B.Roach，“会话启动协议（SIP）URI列表服务的框架和安全注意事项”，RFC 5363，2008年10月。
[RFC5364] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists", RFC 5364, October 2008.
[RFC5364]Garcia Martin，M.和G.Camarillo，“用于在资源列表中表示复制控制属性的可扩展标记语言（XML）格式扩展”，RFC 5364，2008年10月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]Rosenberg，J.，Schulzrinne，H.，和O.Levin，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年8月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579]Johnston，A.和O.Levin，“会话发起协议（SIP）呼叫控制-用户代理会议”，BCP 119，RFC 4579，2006年8月。
[SIP-GRUU] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2007.
[SIP-GRUU]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理（UA）URI（GRUU）”，正在进行的工作，2007年10月。
Authors' Addresses
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Aki Niemi Nokia P.O. Box 321 NOKIA GROUP, FIN 00045 Finland
芬兰芬兰芬兰诺基亚集团321号诺基亚邮政信箱Aki Niemi 00045
EMail: Aki.Niemi@nokia.com
EMail: Aki.Niemi@nokia.com
Markus Isomaki Nokia P.O. Box 100 NOKIA GROUP, FIN 00045 Finland
芬兰芬兰芬兰诺基亚集团Markus Isomaki诺基亚邮政信箱100
EMail: markus.isomaki@nokia.com
EMail: markus.isomaki@nokia.com
Miguel A. Garcia-Martin Ericsson Via de los Poblados 13 Madrid 28033 Spain
Miguel A.Garcia Martin Ericsson Via de los Poblados 13马德里28033西班牙
EMail: miguel.a.garcia@ericsson.com
EMail: miguel.a.garcia@ericsson.com
Hisham Khartabil Ericsson Australia
澳大利亚爱立信哈塔比尔酒店
EMail: hisham.khartabil@gmail.com
EMail: hisham.khartabil@gmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.