Network Working Group G. Camarillo
Request for Comments: 5366 Ericsson
Category: Standards Track A. Johnston
Avaya
October 2008
Network Working Group G. Camarillo
Request for Comments: 5366 Ericsson
Category: Standards Track A. Johnston
Avaya
October 2008
Conference Establishment Using Request-Contained Lists 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 describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a User Agent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list.
本文档描述如何使用SIPURI列表服务创建会议。特别地，它描述了一种机制，该机制允许用户代理客户端使用包含INVITE的URI列表向会议服务器提供参与者的初始列表。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. User Agent Client Procedures ....................................2
3.1. Response Handling ..........................................2
3.2. Re-INVITE Request Generation ...............................3
4. URI-List Document Format ........................................3
5. Conference Server Procedures ....................................5
5.1. Re-INVITE Request Handling .................................6
6. Example .........................................................6
7. Security Considerations ........................................10
8. IANA Considerations ............................................10
9. Acknowledgments ................................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
1. Introduction ....................................................2
2. Terminology .....................................................2
3. User Agent Client Procedures ....................................2
3.1. Response Handling ..........................................2
3.2. Re-INVITE Request Generation ...............................3
4. URI-List Document Format ........................................3
5. Conference Server Procedures ....................................5
5.1. Re-INVITE Request Handling .................................6
6. Example .........................................................6
7. Security Considerations ........................................10
8. IANA Considerations ............................................10
9. Acknowledgments ................................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
Section 5.4 of [RFC4579] describes how to create a conference using ad hoc SIP [RFC3261] methods. The client sends an INVITE request to a conference factory URI and receives the actual conference URI, which contains the "isfocus" feature tag, in the Contact header field of a response -- typically a 200 (OK) response.
[RFC4579]的第5.4节描述了如何使用特别SIP[RFC3261]方法创建会议。客户端向会议工厂URI发送INVITE请求，并在响应的Contact header字段（通常是200（OK）响应）中接收实际的会议URI，其中包含“isfocus”特性标记。
Once the UAC (User Agent Client) obtains the conference URI, it can add participants to the newly created conference in several ways, which are described in [RFC4579].
一旦UAC（用户代理客户端）获得会议URI，它就可以通过多种方式将参与者添加到新创建的会议中，如[RFC4579]所述。
Some environments have tough requirements regarding conference establishment time. They require the UAC to be able to request the creation of an ad hoc conference and to provide the conference server with the initial set of participants in a single operation. This document describes how to meet this requirement using the mechanism to transport URI lists in SIP messages described in [RFC5363].
有些环境对会议建立时间有严格的要求。它们要求UAC能够请求创建临时会议，并在单个操作中向会议服务器提供初始参与者集。本文档描述了如何使用[RFC5363]中描述的传输SIP消息中URI列表的机制来满足此要求。
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]中所述进行解释。
A UAC that wants to include the set of initial participants in its initial INVITE request to create an ad hoc conference adds a body whose disposition type is 'recipient-list', as defined in [RFC5363], with a URI list that contains the participants that the UAC wants the conference server to invite. Additionally, the UAC MUST include the 'recipient-list-invite' option-tag (which is registered with the IANA in Section 8) in a Require header field. The UAC sends this INVITE request to the conference factory URI.
如果UAC希望在其创建临时会议的初始邀请请求中包含初始参与者集，则会添加一个处置类型为[RFC5363]中定义的“收件人列表”的主体，其中包含UAC希望会议服务器邀请的参与者的URI列表。此外，UAC必须在Require头字段中包含“收件人列表邀请”选项标记（在第8节中向IANA注册）。UAC将此INVITE请求发送到会议工厂URI。
The INVITE transaction is also part of an offer/answer exchange that will establish a session between the UAC and the conference server, as specified in [RFC4579]. Therefore, the INVITE request may need to carry a multipart body: a session description and a URI list.
INVITE事务也是提供/应答交换的一部分，该交换将在UAC和会议服务器之间建立会话，如[RFC4579]中所述。因此，INVITE请求可能需要携带一个多部分主体：会话描述和URI列表。
The status code in the response to the INVITE request does not provide any information about whether or not the conference server was able to bring the users in the URI list into the conference. That is, a 200 (OK) response means that the conference was created successfully, that the UAC that generated the INVITE request is in
INVITE请求响应中的状态代码不提供有关会议服务器是否能够将URI列表中的用户带入会议的任何信息。也就是说，200（OK）响应意味着会议已成功创建，生成INVITE请求的UAC处于活动状态
the conference, and that the server understood the URI list. If the UAC wishes to obtain information about the status of other users in the conference, it SHOULD use general conference mechanisms, such as the conference package, which is defined in [RFC4575].
会议，并且服务器理解URI列表。如果UAC希望获得有关会议中其他用户状态的信息，则应使用一般会议机制，如[RFC4575]中定义的会议包。
The previous sections have specified how to include a URI list in an initial INVITE request to a conference server. Once the INVITE-initiated dialog between the UAC and the conference server has been established, the UAC can send subsequent INVITE requests (typically referred to as re-INVITE requests) to the conference server to, for example, modify the characteristics of the media exchanged with the server.
前面几节指定了如何在对会议服务器的初始邀请请求中包含URI列表。一旦UAC和会议服务器之间建立了邀请发起的对话，UAC可以向会议服务器发送后续邀请请求（通常称为重新邀请请求），以修改与服务器交换的媒体的特征。
At this point, there are no semantics associated with 'recipient-list' bodies in re-INVITE requests (although future extensions may define them). Therefore, UACs SHOULD NOT include 'recipient-list' bodies in re-INVITE requests sent to a conference server.
此时，在重新邀请请求中没有与“收件人列表”主体相关联的语义（尽管将来的扩展可能会定义它们）。因此，UAC不应在发送到会议服务器的重新邀请请求中包含“收件人列表”主体。
Note that a difference between an initial INVITE request and a re-INVITE request is that while the initial INVITE request is sent to the conference factory URI, the re-INVITE request is sent to the URI provided by the server in a Contact header field when the dialog was established. Therefore, from the UAC's point of view, the resource identified by the former URI supports 'recipient-list' bodies, while the resource identified by the latter does not support them.
注意，初始INVITE请求和重新邀请请求之间的区别在于，当初始INVITE请求被发送到会议工厂URI时，重新邀请请求被发送到建立对话框时服务器在联系人标头字段中提供的URI。因此，从UAC的角度来看，前一个URI标识的资源支持“收件人列表”主体，而后一个URI标识的资源不支持它们。
As described in [RFC5363], specifications of individual URI-list services, like the conferencing service described here, need to specify a default format for 'recipient-list' bodies used within the particular service.
如[RFC5363]所述，单个URI列表服务的规范（如此处所述的会议服务）需要为特定服务中使用的“收件人列表”主体指定默认格式。
The default format for 'recipient-list' bodies for conferencing UAs (User Agents) is the XML resource list format (which is specified in [RFC4826]) extended with the "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" [RFC5364]. Consequently, conferencing UACs generating 'recipient-list' bodies MUST support both of these formats and MAY support other formats. Conferencing servers able to handle 'recipient-list' bodies MUST support both of these formats and MAY support other formats.
会议UAs（用户代理）的“收件人列表”主体的默认格式是XML资源列表格式（在[RFC4826]中指定），扩展为“用于表示资源列表中的复制控制属性的可扩展标记语言（XML）格式扩展”[RFC5364]。因此，生成“收件人列表”主体的会议UAC必须支持这两种格式，并且可能支持其他格式。能够处理“收件人列表”主体的会议服务器必须支持这两种格式，并且可能支持其他格式。
As described in "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" [RFC5364], each URI can be tagged with a 'copyControl' attribute set
如“用于在资源列表中表示复制控制属性的可扩展标记语言（XML）格式扩展”[RFC5364]中所述，每个URI都可以用“复制控制”属性集进行标记
to either "to", "cc", or "bcc", indicating the role in which the recipient will get the INVITE request. Additionally, URIs can be tagged with the 'anonymize' attribute to prevent the conference server from disclosing the target URI in a URI list.
发送至“收件人”、“抄送”或“密件抄送”，表示收件人将在其中接收邀请请求的角色。此外，可以使用“匿名化”属性标记URI，以防止会议服务器在URI列表中公开目标URI。
In addition, "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" [RFC5364] defines a 'recipient-list-history' body that contains the list of recipients. The default format for 'recipient-list-history' bodies for conferencing UAs is also the XML resource list document format specified in [RFC4826] extended with "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" [RFC5364]. Consequently, conferencing UACs able to generate 'recipient-list-history' bodies MUST support these formats and MAY support others. Conferencing UAs able to understand 'recipient-list-history' MUST support these formats and MAY support others. Conferencing servers able to handle 'recipient-list-history' bodies MUST support these formats and MAY support others.
此外，“用于在资源列表中表示复制控制属性的可扩展标记语言（XML）格式扩展”[RFC5364]定义了包含收件人列表的“收件人列表历史记录”正文。用于会议UAs的“收件人列表历史记录”正文的默认格式也是[RFC4826]中指定的XML资源列表文档格式，并使用“用于表示资源列表中的复制控制属性的可扩展标记语言（XML）格式扩展”[RFC5364]进行扩展。因此，能够生成“收件人列表历史记录”主体的会议UAC必须支持这些格式，并且可能支持其他格式。能够理解“收件人列表历史记录”的会议UAs必须支持这些格式，并且可能支持其他格式。能够处理“收件人列表历史记录”正文的会议服务器必须支持这些格式，并且可能支持其他格式。
Nevertheless, the XML resource list document specified in [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 conferencing service defined in this document, which only needs to transfer a flat list of URIs between a UA (User Agent) and the conference server. Therefore, when using the default resource list document, conferencing UAs SHOULD use flat lists (i.e., no hierarchical lists) and SHOULD NOT use <entry-ref> elements. A conference factory application receiving a URI list with more information than what has just been described MAY discard all the extra information.
然而，[RFC4826]中指定的XML资源列表文档提供了本文档中定义的会议服务不需要的功能，例如分层列表和通过引用包含与XML配置访问协议（XCAP）根URI相关的条目的能力，它只需要在UA（用户代理）和会议服务器之间传输URI的平面列表。因此，当使用默认资源列表文档时，会议UAs应该使用平面列表（即，没有层次列表），而不应该使用<entry ref>元素。一个会议工厂应用程序接收到一个URI列表，其中包含比刚才描述的更多的信息，它可能会丢弃所有额外的信息。
Figure 1 shows an example of a flat list that follows the XML resource list document (specified in [RFC4826]) extended with "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists" [RFC5364].
图1显示了XML资源列表文档（在[RFC4826]中指定）后面的平面列表示例，该文档使用“用于表示资源列表中的复制控制属性的可扩展标记语言（XML）格式扩展”[RFC5364]进行扩展。
<?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>
<?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>
Figure 1: URI list
图1:URI列表
Conference servers that are able to receive and process INVITE requests with a 'recipient-list' body SHOULD include a 'recipient-list-invite' option-tag in a Supported header field when responding to OPTIONS requests.
能够接收和处理带有“收件人列表”正文的邀请请求的会议服务器在响应选项请求时，应在受支持的标题字段中包含“收件人列表邀请”选项标记。
On reception of an INVITE request containing a 'recipient-list' body as described in Section 3, a conference server MUST follow the rules described in [RFC4579] to create ad hoc conferences. Once the ad hoc conference is created, the conference server SHOULD attempt to add the participants in the URI list to the conference as if their addition had been requested using any of the methods described in [RFC4579].
在收到包含第3节所述“收件人列表”主体的邀请请求时，会议服务器必须遵循[RFC4579]中所述的规则来创建临时会议。创建临时会议后，会议服务器应尝试将URI列表中的参与者添加到会议中，就像使用[RFC4579]中描述的任何方法请求添加一样。
The INVITE transaction is also part of an offer/answer exchange that will establish a session between the UAC and the conference server, as specified in [RFC4579]. Therefore, the INVITE request may carry a multipart body: a session description and a URI list.
INVITE事务也是提供/应答交换的一部分，该交换将在UAC和会议服务器之间建立会话，如[RFC4579]中所述。因此，INVITE请求可能包含一个多部分主体：会话描述和URI列表。
Once the conference server has created the ad hoc conference and has attempted to add the initial set of participants, the conference server behaves as a regular conference server and MUST follow the rules in [RFC4579].
一旦会议服务器创建了临时会议并尝试添加初始参与者集，会议服务器将作为常规会议服务器运行，并且必须遵循[RFC4579]中的规则。
The incoming INVITE request will contain a URI-list body or reference (as specified in [RFC5363]) with the actual list of recipients. If this URI list includes resources tagged with the 'copyControl' attribute set to a value of "to" or "cc", the conference server SHOULD include a URI list in each of the outgoing INVITE requests. This list SHOULD be formatted according to the XML format for representing resource lists (specified in [RFC4826]) and the copyControl extension specified in [RFC5364].
传入的INVITE请求将包含一个URI列表主体或引用（如[RFC5363]中所述），其中包含实际的收件人列表。如果此URI列表包含标记为“copyControl”属性并设置为“to”或“cc”值的资源，则会议服务器应在每个传出INVITE请求中包含URI列表。此列表的格式应符合用于表示资源列表的XML格式（在[RFC4826]中指定）和[RFC5364]中指定的copyControl扩展。
The URI-list service MUST follow the procedures specified in [RFC5364] with respect to the handling of the 'anonymize', 'count', and 'copyControl' attributes.
URI列表服务必须遵循[RFC5364]中规定的有关“匿名化”、“计数”和“复制控制”属性处理的程序。
If the conference server includes a URI list in an outgoing INVITE request, it MUST include a Content-Disposition header field (which is specified in [RFC2183]) with the value set to 'recipient-list-history' and a 'handling' parameter (as specified in [RFC3204]) set to "optional".
如果会议服务器在传出的INVITE请求中包含URI列表，则它必须包含一个内容处置头字段（在[RFC2183]中指定），该字段的值设置为“收件人列表历史记录”，而“处理”参数（在[RFC3204]中指定）设置为“可选”。
At this point, there are no semantics associated with 'recipient-list' bodies in re-INVITE requests (although future extensions may define them). Therefore, a conference server receiving a re-INVITE request with a 'recipient-list' body and, consequently, a 'recipient-list-invite' option-tag, following standard SIP procedures, rejects it with a 420 (Bad Extension), which carries an Unsupported header field listing the 'recipient-list-invite' option-tag.
此时，在重新邀请请求中没有与“收件人列表”主体相关联的语义（尽管将来的扩展可能会定义它们）。因此，会议服务器接收到带有“收件人列表”主体的重新邀请请求，并因此带有“收件人列表邀请”选项标记，按照标准SIP过程，使用420（坏扩展名）拒绝该请求，该420带有不受支持的头字段，其中列出了“收件人列表邀请”选项标记。
This is because the resource identified by the conference URI does not actually support this extension. On the other hand, the resource identified by the conference factory URI does support this extension and, consequently, would include the 'recipient-list-invite' option-tag in, for example, responses to OPTIONS requests.
这是因为会议URI标识的资源实际上不支持此扩展。另一方面，由会议工厂URI标识的资源确实支持此扩展，因此将在例如对选项请求的响应中包括“收件人列表邀请”选项标记。
Figure 2 shows an example of operation. A UAC sends an INVITE request (F1) that contains an SDP body and a URI list to the conference server. The conference server answers with a 200 (OK) response and generates an INVITE request to each of the UASs (User Agent Servers) identified by the URIs included in the URI list. The conference server includes SDP and a manipulated URI list in each of the outgoing INVITE requests.
图2显示了一个操作示例。UAC向会议服务器发送包含SDP正文和URI列表的INVITE请求（F1）。会议服务器以200（OK）响应进行应答，并向URI列表中包含的URI标识的每个UAS（用户代理服务器）生成INVITE请求。会议服务器在每个传出的INVITE请求中包括SDP和被操纵的URI列表。
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | confer. | |SIP UAS | |SIP UAS | |SIP UAS |
| | | server | | 1 | | 2 | | n |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 INVITE | | | |
| ---------------->| | | |
| F2 200 OK | | | |
|<---------------- | F3 INVITE | | |
| | ------------->| | |
| | F4 INVITE | | |
| | ------------------------>| |
| | F5 INVITE | | |
| | ----------------------------------->|
| | F6 200 OK | | |
| |<------------- | | |
| | F7 200 OK | | |
| |<------------------------ | |
| | F8 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | confer. | |SIP UAS | |SIP UAS | |SIP UAS |
| | | server | | 1 | | 2 | | n |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1 INVITE | | | |
| ---------------->| | | |
| F2 200 OK | | | |
|<---------------- | F3 INVITE | | |
| | ------------->| | |
| | F4 INVITE | | |
| | ------------------------>| |
| | F5 INVITE | | |
| | ----------------------------------->|
| | F6 200 OK | | |
| |<------------- | | |
| | F7 200 OK | | |
| |<------------------------ | |
| | F8 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 2: Example of operation
图2：操作示例
Figure 3 shows an example of the INVITE request F1, which carries a multipart/mixed body composed of two other bodies: an application/sdp body that describes the session and an application/resource-lists+xml body that contains the list of target URIs.
图3显示了INVITE请求F1的一个示例，它携带一个多部分/混合体，由另外两个体组成：一个描述会话的应用程序/sdp体和一个包含目标URI列表的应用程序/资源列表+xml体。
INVITE sip:conf-fact@example.com SIP/2.0
Via: SIP/2.0/TCP atlanta.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: "Conf Factory" <sip:conf-fact@example.com>
From: Alice <sip:alice@example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 1 INVITE
Contact: <sip:alice@atlanta.example.com>
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Require: recipient-list-invite
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 690
INVITE sip:conf-fact@example.com SIP/2.0
Via: SIP/2.0/TCP atlanta.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: "Conf Factory" <sip:conf-fact@example.com>
From: Alice <sip:alice@example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 1 INVITE
Contact: <sip:alice@atlanta.example.com>
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Require: recipient-list-invite
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 690
--boundary1
Content-Type: application/sdp
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000
v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list
--boundary1内容类型：应用程序/资源列表+xml内容处置：收件人列表
<?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:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list>
</resource-lists>
--boundary1--
<?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:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list>
</resource-lists>
--boundary1--
Figure 3: INVITE request received at the conference server
图3：在会议服务器上收到的INVITE请求
The INVITE requests F3, F4, and F5 are similar in nature. All those INVITE requests contain a multipart/mixed body that is composed of two other bodies: an application/sdp body describing the session and an application/resource-lists+xml containing the list of recipients. The application/resource-lists+xml bodies are not equal to the application/resource-lists+xml included in the received INVITE request F1, because the conference server has anonymized those URIs tagged with the 'anonymize' attribute and has removed those URIs tagged with a "bcc" 'copyControl' attribute. Figure 4 shows an example of the message F3.
INVITE请求F3、F4和F5的性质类似。所有这些INVITE请求都包含一个多部分/混合体，它由两个其他体组成：一个描述会话的应用程序/sdp体和一个包含收件人列表的应用程序/资源列表+xml。应用程序/资源列表+xml正文不等于接收到的INVITE请求F1中包含的应用程序/资源列表+xml，因为会议服务器已匿名化了那些标记为“匿名化”属性的URI，并删除了那些标记为“密件抄送”属性的URI。图4显示了消息F3的示例。
INVITE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP conference.example.com
;branch=z9hG4bKhjhs8as454
Max-Forwards: 70
To: <sip:bill@example.com>
From: Conference Server <sip:conf34@example.com>;tag=234332
Call-ID: 389sn189dasdf
CSeq: 1 INVITE
Contact: <sip:conf34@conference.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog, conference
Accept: application/sdp, message/sipfrag
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 690
INVITE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP conference.example.com
;branch=z9hG4bKhjhs8as454
Max-Forwards: 70
To: <sip:bill@example.com>
From: Conference Server <sip:conf34@example.com>;tag=234332
Call-ID: 389sn189dasdf
CSeq: 1 INVITE
Contact: <sip:conf34@conference.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog, conference
Accept: application/sdp, message/sipfrag
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 690
--boundary1
Content-Type: application/sdp
--boundary1
Content-Type: application/sdp
v=0
o=conf 2890844343 2890844343 IN IP4 conference.example.com
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 40000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 40002 RTP/AVP 31
a=rtpmap:31 H261/90000
v=0
o=conf 2890844343 2890844343 IN IP4 conference.example.com
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 40000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 40002 RTP/AVP 31
a=rtpmap:31 H261/90000
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list-history; handling=optional
--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list-history; handling=optional
<?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:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/>
</list>
</resource-lists>
--boundary1--
<?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:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/>
</list>
</resource-lists>
--boundary1--
Figure 4: INVITE request sent by the conference server
图4：会议服务器发送的INVITE请求
This document discusses setup of SIP conferences using a request-contained URI list. Both conferencing and URI-list services have specific security requirements, which are summarized here. Conferences generally have authorization rules about who can or cannot join a conference, what type of media can or cannot be used, etc. This information is used by the focus to admit or deny participation in a conference. It is RECOMMENDED that these types of authorization rules be used to provide security for a SIP conference.
本文档讨论使用包含请求的URI列表设置SIP会议。会议服务和URI列表服务都有特定的安全要求，下面对其进行总结。会议通常有关于谁可以或不能参加会议、什么类型的媒体可以或不能使用等的授权规则。焦点使用这些信息来允许或拒绝参加会议。建议使用这些类型的授权规则为SIP会议提供安全性。
For this authorization information to be used, the focus needs to be able to authenticate potential participants. Normal SIP mechanisms, including Digest authentication and certificates, can be used. These conference-specific security requirements are discussed further in the requirements and framework documents -- [RFC4245] and [RFC4353].
要使用此授权信息，焦点需要能够对潜在参与者进行身份验证。可以使用普通的SIP机制，包括摘要身份验证和证书。这些特定于会议的安全需求将在需求和框架文件[RFC4245]和[RFC4353]中进一步讨论。
For conference creation using a list, there are some additional security considerations. "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services" [RFC5363] discusses issues related to SIP URI-list services. Given that a conference server sending INVITE requests to a set of users acts as a URI-list service, implementations of conference servers that handle lists MUST follow the security-related rules in [RFC5363]. These rules include opt-in lists and mandatory authentication and authorization of clients.
对于使用列表创建会议，还有一些额外的安全注意事项。“会话初始化协议（SIP）URI列表服务的框架和安全注意事项”[RFC5363]讨论了与SIP URI列表服务相关的问题。鉴于向一组用户发送INVITE请求的会议服务器充当URI列表服务，处理列表的会议服务器的实现必须遵循[RFC5363]中的安全相关规则。这些规则包括选择加入列表和客户端的强制身份验证和授权。
This document defines the 'recipient-list-invite' SIP option-tag. It has been registered in the Option Tags subregistry under the SIP parameter registry. The following is the description used in the registration:
此文档定义了“收件人列表邀请”SIP选项标记。它已在SIP参数注册表下的Option Tags子注册表中注册。以下是注册中使用的说明：
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-invite | The body contains a list of | [RFC5366] |
| | URIs that indicates the | |
| | recipients of the SIP INVITE | |
| | request | |
+------------------------+------------------------------+-----------+
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-invite | The body contains a list of | [RFC5366] |
| | URIs that indicates the | |
| | recipients of the SIP INVITE | |
| | request | |
+------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-invite' option-tag in SIP
表1:SIP中“收件人列表邀请”选项标记的注册
Cullen Jennings, Hisham Khartabil, Jonathan Rosenberg, and Keith Drage provided useful comments on this document. Miguel Garcia-Martin assembled the dependencies to the 'copyControl' attribute extension.
Cullen Jennings、Hisham Khartabil、Jonathan Rosenberg和Keith Drage对该文件提供了有用的评论。Miguel Garcia Martin将依赖项组装到“copyControl”属性扩展。
[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, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183]Troost，R.，Dorner，S.，和K.Moore，Ed.，“在互联网消息中传达呈现信息：内容处置标题字段”，RFC 2183，1997年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月。
[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月。
[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月。
[RFC4245] Levin, O. and R. Even, "High-Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005.
[RFC4245]Levin，O.和R.Een，“紧耦合SIP会议的高级别要求”，RFC 42452005年11月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353]Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，2006年2月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]Rosenberg，J.，Schulzrinne，H.，和O.Levin，Ed.，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年8月。
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
Alan Johnston Avaya St. Louis, MO 63124 USA
美国密苏里州圣路易斯市艾伦·约翰斯顿·阿瓦亚63124
EMail: alan@sipstation.com
EMail: alan@sipstation.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.