Network Working Group A. Johnston
Request for Comments: 4579 Avaya
BCP: 119 O. Levin
Category: Best Current Practice Microsoft Corporation
August 2006
Network Working Group A. Johnston
Request for Comments: 4579 Avaya
BCP: 119 O. Levin
Category: Best Current Practice Microsoft Corporation
August 2006
Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents
会话启动协议（SIP）呼叫控制-用户代理会议
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from the perspective of different user agent (UA) types: conference-unaware, conference-aware, and focus UAs. The use of Uniform Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined.
本规范定义了会话启动协议（SIP）的会议呼叫控制功能。本文档以会议需求和框架文档为基础，定义紧密耦合的SIP会议的工作方式。该方法是从不同的用户代理（UA）类型的角度进行探讨的：会议感知、会议感知和焦点UAs。会议中统一资源标识符（URI）的使用、功能发现选项以及使用REFER的呼叫控制将在示例呼叫流图中详细介绍。定义了isfocus功能标记的用法。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. SIP User Agent Conferencing Capability Types ....................3
3.1. Focus UA ...................................................4
3.2. Conference Factory URI .....................................4
3.3. Conference-Unaware UA ......................................5
3.4. Conference-Aware UA ........................................5
4. Usage of the 'isfocus' Feature Parameter ........................6
4.1. General ....................................................6
4.2. Session Establishment ......................................6
4.3. Discovery ..................................................7
5. SIP Conferencing Primitives .....................................7
5.1. INVITE: Joining a Conference Using the Conference
1. Introduction ....................................................2
2. Terminology .....................................................3
3. SIP User Agent Conferencing Capability Types ....................3
3.1. Focus UA ...................................................4
3.2. Conference Factory URI .....................................4
3.3. Conference-Unaware UA ......................................5
3.4. Conference-Aware UA ........................................5
4. Usage of the 'isfocus' Feature Parameter ........................6
4.1. General ....................................................6
4.2. Session Establishment ......................................6
4.3. Discovery ..................................................7
5. SIP Conferencing Primitives .....................................7
5.1. INVITE: Joining a Conference Using the Conference
URI - Dial-In ..............................................7
5.2. INVITE: Adding a Participant by the Focus - Dial-Out ......11
5.3. INVITE: Manually Creating a Conference by Dialing
In to a Conferencing Application ..........................15
5.4. INVITE: Creating a Conference Using Ad-Hoc SIP Methods ....16
5.5. REFER: Requesting a Focus to Add a New Resource to
a Conference (Dial Out to a New Participant) ..............18
5.6. REFER: Requesting a User to Dial in to a Conference
Using a Conference URI ....................................21
5.7. REFER with REFER: Requesting a Focus to Refer a
Participant to Dial in to the Conference ..................23
5.8. Join Header Field: Dialing in to a Conference
Using a (3rd Party) Dialog Identifier .....................26
5.9. Replaces Header Field: Switching User Agents
within a Conference .......................................28
5.10. Replaces Header Field: Transferring a Point-to-Point
Session in to a Conference ...............................29
5.11. REFER with BYE: Requesting That the Focus Remove a
Participant from a Conference ............................31
5.12. Deleting a Conference ....................................33
5.13. Discovery of URI Properties Using OPTIONS ................34
6. Security Considerations ........................................36
7. Contributors ...................................................37
8. References .....................................................38
8.1. Normative References ......................................38
8.2. Informative References ....................................38
Appendix A: Creating a Conference by a Conference-Unaware UA.......40
URI - Dial-In ..............................................7
5.2. INVITE: Adding a Participant by the Focus - Dial-Out ......11
5.3. INVITE: Manually Creating a Conference by Dialing
In to a Conferencing Application ..........................15
5.4. INVITE: Creating a Conference Using Ad-Hoc SIP Methods ....16
5.5. REFER: Requesting a Focus to Add a New Resource to
a Conference (Dial Out to a New Participant) ..............18
5.6. REFER: Requesting a User to Dial in to a Conference
Using a Conference URI ....................................21
5.7. REFER with REFER: Requesting a Focus to Refer a
Participant to Dial in to the Conference ..................23
5.8. Join Header Field: Dialing in to a Conference
Using a (3rd Party) Dialog Identifier .....................26
5.9. Replaces Header Field: Switching User Agents
within a Conference .......................................28
5.10. Replaces Header Field: Transferring a Point-to-Point
Session in to a Conference ...............................29
5.11. REFER with BYE: Requesting That the Focus Remove a
Participant from a Conference ............................31
5.12. Deleting a Conference ....................................33
5.13. Discovery of URI Properties Using OPTIONS ................34
6. Security Considerations ........................................36
7. Contributors ...................................................37
8. References .....................................................38
8.1. Normative References ......................................38
8.2. Informative References ....................................38
Appendix A: Creating a Conference by a Conference-Unaware UA.......40
This specification uses the concepts and definitions from the high level requirements [14] and the SIP conferencing framework [8] documents. This approach is applicable to tightly coupled SIP conferences. In this architecture, a user agent (UA), known as a participant, establishes a SIP dialog with another UA, known as a focus. The focus is the central point of control, authentication, and authorization. This specification defines the operation of a focus and participant UAs. Note that only the signalling (SIP) needs to be centralized in this model; the media can be centrally mixed, distributed, or even multicast. For a full discussion of this architecture, see the SIP conferencing framework document [8].
本规范使用了高级需求[14]和SIP会议框架[8]文档中的概念和定义。这种方法适用于紧密耦合的SIP会议。在该体系结构中，称为参与者的用户代理（UA）与另一个称为焦点的UA建立SIP对话。重点是控制、身份验证和授权的中心点。本规范定义了焦点和参与者UAs的操作。注意，在这个模型中，只有信令（SIP）需要集中；媒体可以集中混合、分布，甚至多播。有关此体系结构的完整讨论，请参阅SIP会议框架文档[8]。
The approach described in this document implements key functions in the conferencing framework using SIP primitives only. This allows for conducting simple conferences with defined functionalities using SIP mechanisms and conventions. Many other advanced functions can be implemented using additional means, but they are not in the scope of this document.
本文档中描述的方法仅使用SIP原语实现会议框架中的关键功能。这允许使用SIP机制和约定进行具有定义功能的简单会议。许多其他高级功能可以使用其他方法实现，但它们不在本文档的范围内。
This document presents the basic call control (dial-in and dial-out) conferencing building blocks from the UA perspective. Possible applications include ad-hoc conferences and scheduled conferences.
本文档从UA的角度介绍了基本呼叫控制（拨入和拨出）会议构建块。可能的应用包括临时会议和预定会议。
Note that a single conference can bridge participants that have different capabilities and who potentially have joined the conference by different means (i.e., dial-in, dial-out, scheduled, or ad-hoc).
请注意，单个会议可以将具有不同能力且可能通过不同方式（即拨入、拨出、预定或临时）加入会议的参与者连接起来。
The call control and dialog manipulation approach is based on the multiparty framework document [15]. That document defines the basic approach of service design adopted for SIP, which includes the following:
调用控制和对话框操作方法基于多方框架文档[15]。该文件定义了SIP采用的服务设计的基本方法，包括以下内容：
- Definition of primitives, not services - Signaling model independent - Invoker oriented - Primitives make full use of URIs - Include policies for authentication, authorization, logging, etc. - Define graceful fallback to baseline SIP
- 原语而非服务的定义-独立于信令模型-面向调用方-原语充分利用URI-包括身份验证、授权、日志记录等策略-定义到基线SIP的优雅回退
The use of opaque URIs and the ability to communicate call control context information within a URI (as opposed to using service-related header fields), as discussed in RFC 3087 [11], is fundamental to this approach.
如RFC 3087[11]中所述，使用不透明URI和在URI内传递调用控制上下文信息的能力（与使用服务相关的头字段相反）是这种方法的基础。
Capabilities discovery is an important feature of SIP systems, and conferencing systems can make use of such features. For a UA acting as a focus in a conference, this specification defines the usage of the 'isfocus' feature parameter.
功能发现是SIP系统的一个重要功能，会议系统可以利用这些功能。对于充当会议焦点的UA，本规范定义了“isfocus”特性参数的用法。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 and indicate requirement levels for compliant implementations [1].
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”将按照RFC 2119中的描述进行解释，并表示符合性实施的要求级别[1]。
From a conferencing perspective, the framework document outlines a number of possible different SIP components such as conference-unaware participant, conference-aware participant, and focus.
从会议的角度来看，框架文档概述了许多可能的不同SIP组件，例如会议不知道参与者、会议知道参与者和焦点。
This document applies the concepts above to the SIP call control part of the conferencing components. It defines normative behavior of the SIP UAs in various conferencing situations (referred to later as "scenarios").
本文档将上述概念应用于会议组件的SIP呼叫控制部分。它定义了SIP UAs在各种会议情况下的规范行为（后面称为“场景”）。
A focus, as defined in the framework, hosts a SIP conference and maintains a SIP signaling relationship with each participant in the conference. A focus contains a conference-aware user agent that supports the conferencing call control conventions as defined in this document.
框架中定义的焦点主持SIP会议，并与会议中的每个参与者保持SIP信令关系。focus包含支持本文档中定义的会议呼叫控制约定的会议感知用户代理。
A focus SHOULD support the conference package RFC 4575 [9], behave as a notifier for that package, and indicate its support in the Allow-Events header fields in requests and responses. A focus MAY include information about the conference in Session Description Protocol (SDP) bodies sent as part of normal SIP signaling by populating the Session Information, URI, Email Address, and Phone Number SDP fields.
焦点应支持会议包RFC 4575[9]，充当该包的通知程序，并在请求和响应中的允许事件标头字段中指示其支持。焦点可以通过填充会话信息、URI、电子邮件地址和电话号码SDP字段来包括关于作为正常SIP信令的一部分发送的会话中会议描述协议（SDP）主体的信息。
In order to support advanced features, where a session established between two endpoints can migrate to a centralized conference, a focus SHOULD support the Replaces header field [6].
为了支持高级功能，即在两个端点之间建立的会话可以迁移到集中会议，焦点应支持Replaces header字段[6]。
A user agent with focus capabilities could be implemented in end user equipment and would be used for the creation of ad-hoc conferences.
具有焦点功能的用户代理可以在最终用户设备中实现，并用于创建临时会议。
A dedicated conferencing server, whose primary task is to simultaneously host conferences of arbitrary type and size, may allocate and publish a conference factory URI (as defined in the next section) for creating an arbitrary number of ad-hoc conferences (and subsequently their focuses) using SIP call control means.
专用会议服务器（其主要任务是同时主持任意类型和大小的会议）可以分配和发布会议工厂URI（如下一节中定义的），用于使用SIP呼叫控制手段创建任意数量的自组织会议（以及随后它们的焦点）。
According to the framework, there are many ways in which a conference can be created. A conferencing server implementation is free to choose from these methods, which include non-automated means (such as an Interactive Voice Response (IVR) system), SIP, or any conference control protocol.
根据该框架，可以通过多种方式创建会议。会议服务器实现可以从这些方法中自由选择，这些方法包括非自动方法（如交互式语音响应（IVR）系统）、SIP或任何会议控制协议。
In order to automatically create an arbitrary number of ad-hoc conferences (and subsequently their focuses) using SIP call control means, a globally routable Conference Factory URI can be allocated and published.
为了使用SIP呼叫控制手段自动创建任意数量的ad-hoc会议（以及随后它们的焦点），可以分配和发布全局可路由的会议工厂URI。
A successful attempt to establish a call to this URI would result in the automatic creation of a new conference and its focus. As a result, note that the Conference Factory URI and the newly created focus URI MAY resolve to different physical devices.
成功尝试建立对此URI的调用将导致自动创建新会议及其焦点。因此，请注意，会议工厂URI和新创建的焦点URI可能解析为不同的物理设备。
A scenario showing the use of the conference factory URI is shown in Section 5.4.
第5.4节显示了使用会议工厂URI的场景。
The simplest user agent can participate in a conference ignoring all SIP conferencing-related information. The simplest user agent is able to dial in to a conference and to be invited to a conference. Any conferencing information is optionally conveyed to/from it using non-SIP means. Such a user agent would not usually host a conference (at least, not using SIP explicitly). A conference-unaware UA need only support RFC 3261 [2]. Call flows for conference-unaware UAs are not shown in general in this document as they would be identical to those in the SIP call flows document [13].
最简单的用户代理可以忽略所有SIP会议相关信息参与会议。最简单的用户代理能够拨入会议并被邀请参加会议。任何会议信息都可以使用非SIP方式选择性地向it传递或从it传递。这样的用户代理通常不会主持会议（至少不会显式使用SIP）。会议只需要支持RFC 3261[2]。本文件一般不显示会议非感知UAs的呼叫流，因为它们与SIP呼叫流文件中的呼叫流相同[13]。
Note that the presence of an 'isfocus' feature tag in a Contact header field will not cause interoperability issues between a focus and a conference-unaware UA since it will be treated as an unknown header parameter and ignored, as per standard SIP behavior.
请注意，联系人标头字段中存在“isfocus”功能标记不会导致焦点和会议UA之间的互操作性问题，因为根据标准SIP行为，它将被视为未知标头参数并被忽略。
A conference-aware user agent supports SIP conferencing call control conventions defined in this document as a conference participant, in addition to support of RFC 3261 [2]. A conference-aware UA should be able to process SIP redirections such as described in Section 8.1.3.4 of RFC 3261.
会议感知用户代理除了支持RFC 3261[2]之外，还支持本文档中定义为会议参与者的SIP会议呼叫控制约定。具有会议意识的UA应能够处理SIP重定向，如RFC 3261第8.1.3.4节所述。
A conference-aware UA MUST recognize the 'isfocus' feature parameter. A conference-aware UA SHOULD support REFER [4], SIP events [3], and the conferencing package [9].
具有会议意识的UA必须识别“isfocus”功能参数。会议感知UA应支持REFER[4]、SIP事件[3]和会议包[9]。
A conference-aware UA SHOULD subscribe to the conference package if the 'isfocus' parameter is in the remote target URI of a dialog and if the conference package is listed by a focus in an Allow-Events header field. The SUBSCRIBE to the conference package SHOULD be sent outside any INVITE-initiated dialog. A termination of the INVITE dialog with a BYE does not necessarily terminate the SUBSCRIBE dialog.
如果“isfocus”参数位于对话框的远程目标URI中，并且如果会议包在允许事件标头字段中由焦点列出，则会议感知UA应订阅会议包。订阅会议包应发送到任何邀请发起的对话框之外。使用BYE终止INVITE对话框并不一定会终止SUBSCRIBE对话框。
A conference-aware UA MAY render to the user any information about the conference obtained from the SIP header fields and SDP fields from the focus.
会议感知UA可以向用户呈现从SIP报头字段和来自焦点的SDP字段获得的关于会议的任何信息。
A conference-aware UA SHOULD render to the user any information about the conference obtained from the SIP conference package.
会议感知UA应向用户提供从SIP会议包获得的关于会议的任何信息。
The main design guidelines for the development of SIP extensions and conventions for conferencing are to define the minimum number of extensions and to have seamless backward compatibility with conference-unaware SIP UAs. The minimal requirement for SIP is being able to express that a dialog is a part of a certain conference referenced to by a URI. As a result of these extensions, it is possible to do the following using SIP:
开发SIP扩展和会议约定的主要设计准则是定义最小扩展数量，并与会议无关SIP UAs无缝向后兼容。SIP的最低要求是能够表示对话是URI引用的特定会议的一部分。作为这些扩展的结果，可以使用SIP执行以下操作：
- Create a conference - Join a conference - Invite a user to a conference - Expel a user by third party - Discover if a URI is a conference URI - Delete a conference
- 创建会议-加入会议-邀请用户参加会议-由第三方驱逐用户-发现URI是否为会议URI-删除会议
The approach taken is to use the feature parameter 'isfocus' to express that a SIP dialog belongs to a conference. The use of feature parameters in Contact header fields to describe the characteristics and capabilities of a UA is described in the User Agent Capabilities document [5], which includes the definition of the 'isfocus' feature parameter.
所采用的方法是使用特性参数“isfocus”表示SIP对话框属于会议。用户代理能力文档[5]中描述了在联系人标题字段中使用特征参数来描述UA的特征和能力，其中包括“isfocus”特征参数的定义。
In session establishment, a focus MUST include the 'isfocus' feature parameter in the Contact header field unless the focus wishes to hide the fact that it is a focus. To a participant, the feature parameter will be associated with the remote target URI of the dialog. It is an indication to a conference-aware UA that the resulting dialog belongs to a conference, identified by the URI in the Contact header field, and that the call control conventions defined in this document can be applied.
在会话建立中，焦点必须在联系人标题字段中包含“isfocus”功能参数，除非该焦点希望隐藏它是焦点的事实。对于参与者来说，功能参数将与对话框的远程目标URI相关联。它是对会议感知UA的一种指示，表明生成的对话属于会议，由联系人标头字段中的URI标识，并且可以应用本文档中定义的呼叫控制约定。
By their nature, the conferences supported by this specification are centralized. Therefore, typically a conferencing system needs to allocate a SIP conference URI such that SIP requests to this URI are not forked and are routed to a dedicated conference focus. For example, a globally accessible SIP conference could be well constructed with a conference URI using a Globally Routable User Agent URI (GRUU) (defined in [16]), because of its ability to support the non-forking and global routability requirements.
根据其性质，本规范支持的会议是集中的。因此，典型地，会议系统需要分配SIP会议URI，使得对该URI的SIP请求不会分叉，而是路由到专用的会议焦点。例如，全局可访问的SIP会议可以通过使用全局可路由用户代理URI（GRUU）（在[16]中定义）的会议URI很好地构建，因为它能够支持非分叉和全局可路由性需求。
Using the mechanism described in this section, it is possible, given an opaque URI, to determine if it belongs to a certain conference (i.e., meaning that it is a conference URI) or not. This discovery function can be implemented in SIP using an OPTIONS request, and can be done either inside an active dialog or outside a dialog. A focus MUST include the 'isfocus' feature parameter in a 200 OK response to an OPTIONS unless the focus wishes to hide the fact that it is a focus.
使用本节中描述的机制，在给定不透明URI的情况下，可以确定它是否属于某个会议（即，意味着它是一个会议URI）。此发现功能可以使用选项请求在SIP中实现，并且可以在活动对话框内部或对话框外部完成。焦点必须在对选项的200 OK响应中包含“isfocus”特性参数，除非焦点希望隐藏它是焦点的事实。
The SIP conferencing call control flows presented in this section are the call control building blocks for various SIP conferencing applications as described in the conferencing requirements [14] and framework [8] documents. The major design goal is that the same SIP conferencing primitives would be used by user agents having different conferencing capabilities and implementing different applications.
本节介绍的SIP会议呼叫控制流是各种SIP会议应用程序的呼叫控制构建块，如会议要求[14]和框架[8]文档所述。主要设计目标是，具有不同会议功能和实现不同应用程序的用户代理将使用相同的SIP会议原语。
In this section, a user knows the conference URI and "dials in" to join this conference. The focus will authenticate the participant and apply authorization policy before allowing the participant to join the conference.
在本节中，用户知道会议URI并“拨入”以加入此会议。focus将在允许参与者加入会议之前对参与者进行身份验证并应用授权策略。
If the UA is the first participant of the conference to dial-in, it is likely that this INVITE will activate the focus and hence the conference. However, the conference URI must have been reserved prior to its use.
如果UA是第一个拨入会议的参与者，则此邀请可能会激活焦点，从而激活会议。但是，会议URI必须在使用前保留。
If the conference is up and running already, the dialing-in participant is joined to the conference by its focus.
如果会议已启动并运行，则拨入参与者将通过其焦点加入会议。
To join an existing specific conference, a UA will send an INVITE with the Request-URI set to the conference URI. The focus MUST include the 'isfocus' feature parameter in the Contact header field of the 200 OK response to the INVITE.
要加入现有的特定会议，UA将发送一个邀请，请求URI设置为会议URI。焦点必须在对邀请的200 OK响应的联系人标题字段中包含“isfocus”功能参数。
An example call flow for joining a conference is shown in Figure 1.
图1显示了加入会议的示例调用流。
Alice Focus Bob Carol
| | |
| | Carol joins the conference |
| | |
| | INVITE sip:Conf-ID F1 |
| |<----------------------------------------|
| | 180 Ringing F2 |
| |---------------------------------------->|
| | 200 OK Contact:Conf-ID;isfocus F3 |
| |---------------------------------------->|
| | ACK F4 |
| |<----------------------------------------|
| | RTP |
| |<=======================================>|
| | SUBSCRIBE sip:Conf-ID F5 |
| |<----------------------------------------|
| | 200 OK F6 |
| |---------------------------------------->|
| | NOTIFY F7 |
| |---------------------------------------->|
| | 200 OK F8 |
| |<----------------------------------------|
Alice Focus Bob Carol
| | |
| | Carol joins the conference |
| | |
| | INVITE sip:Conf-ID F1 |
| |<----------------------------------------|
| | 180 Ringing F2 |
| |---------------------------------------->|
| | 200 OK Contact:Conf-ID;isfocus F3 |
| |---------------------------------------->|
| | ACK F4 |
| |<----------------------------------------|
| | RTP |
| |<=======================================>|
| | SUBSCRIBE sip:Conf-ID F5 |
| |<----------------------------------------|
| | 200 OK F6 |
| |---------------------------------------->|
| | NOTIFY F7 |
| |---------------------------------------->|
| | 200 OK F8 |
| |<----------------------------------------|
Figure 1. A Participant Joins a Conference Using the Conference URI.
图1。参与者使用会议URI加入会议。
F1 INVITE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 45 INVITE
Contact: <sip:carol@client.chicago.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
F1 INVITE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 45 INVITE
Contact: <sip:carol@client.chicago.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
(SDP not shown)
（未显示SDP）
F3 SIP/2.0 200 OK
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83;received=192.0.2.4
To: <sip:3402934234@conf.example.com>;tag=733413
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 45 INVITE
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog, conference
Accept: application/sdp, application/conference-info+xml,
message/sipfrag
Supported: replaces, join, gruu
Content-Type: application/sdp
Content-Length: ...
F3 SIP/2.0 200 OK
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83;received=192.0.2.4
To: <sip:3402934234@conf.example.com>;tag=733413
From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 45 INVITE
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog, conference
Accept: application/sdp, application/conference-info+xml,
message/sipfrag
Supported: replaces, join, gruu
Content-Type: application/sdp
Content-Length: ...
v=0
o=focus431 2890844526 2890842807 IN IP4 ms5.conf.example.com
s=-
i=Example Conference Hosted by Example.com
u=http://conf.example.com/3402934234
e=3402934234@conf-help.example.com
p=+1-888-2934234
c=IN IP4 ms5.conf.example.com
t=0 0
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
v=0
o=focus431 2890844526 2890842807 IN IP4 ms5.conf.example.com
s=-
i=Example Conference Hosted by Example.com
u=http://conf.example.com/3402934234
e=3402934234@conf-help.example.com
p=+1-888-2934234
c=IN IP4 ms5.conf.example.com
t=0 0
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
F5 SUBSCRIBE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKdf334
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Carol <sip:carol@chicago.example.com>;tag=43524545
Call-ID: k3l43id034ksereree
CSeq: 22 SUBSCRIBE
Contact: <sip:carol@client.chicago.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/conference-info+xml
Supported: replaces
Content-Length: 0
F5 SUBSCRIBE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.chicago.example.com
;branch=z9hG4bKdf334
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Carol <sip:carol@chicago.example.com>;tag=43524545
Call-ID: k3l43id034ksereree
CSeq: 22 SUBSCRIBE
Contact: <sip:carol@client.chicago.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/conference-info+xml
Supported: replaces
Content-Length: 0
F7 NOTIFY sip:carol@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1
Max-Forwards: 70
To: Carol <sip:carol@chicago.example.com>;tag=43524545
From: <sip:3402934234@conf.example.com>;tag=a3343df32
Call-ID: k3l43id034ksereree
CSeq: 34321 NOTIFY
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/sdp, message/sipfrag
Subscription-State: active;expires=3600
Supported: replaces, join, gruu
Content-Type: application/conference-info+xml
F7 NOTIFY sip:carol@chicago.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1
Max-Forwards: 70
To: Carol <sip:carol@chicago.example.com>;tag=43524545
From: <sip:3402934234@conf.example.com>;tag=a3343df32
Call-ID: k3l43id034ksereree
CSeq: 34321 NOTIFY
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Event: conference
Accept: application/sdp, message/sipfrag
Subscription-State: active;expires=3600
Supported: replaces, join, gruu
Content-Type: application/conference-info+xml
Content-Length: ...
内容长度：。。。
<conference-info version="0" state="full"
entity="sip:3402934234@conf.example.com">
<conference-description>
<conf-uris>
<entry>
<uri>tel:+18882934234</uri>
</entry>
</conf-uris>
</conference-description>
<users>
<user entity="sip:carol@chicago.example.com" state="full">
<display-text>Carol</display-text>
<endpoint entity="sip:carol@client.chicago.example.com">
<status>connected</status>
<joining-method>dialed-in</joining-method>
<media id="1">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>583398</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<type>video</type>
<src-id>345212</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>
<conference-info version="0" state="full"
entity="sip:3402934234@conf.example.com">
<conference-description>
<conf-uris>
<entry>
<uri>tel:+18882934234</uri>
</entry>
</conf-uris>
</conference-description>
<users>
<user entity="sip:carol@chicago.example.com" state="full">
<display-text>Carol</display-text>
<endpoint entity="sip:carol@client.chicago.example.com">
<status>connected</status>
<joining-method>dialed-in</joining-method>
<media id="1">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>583398</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<type>video</type>
<src-id>345212</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>
To directly add a participant to a conference, a focus SHOULD send an INVITE to the participant containing a Contact header field with the conference URI and the 'isfocus' feature parameter.
要将参与者直接添加到会议中，焦点应向参与者发送邀请，其中包含带有会议URI和“isfocus”功能参数的联系人标题字段。
Note that a conference-unaware UA would simply ignore the conferencing information and treat the session (from a SIP perspective) as a point-to-point session. This is because standard RFC 3261 [2] behavior is to ignore unknown header parameters such as 'isfocus'.
注意，不知道会议的UA只会忽略会议信息，并将会话（从SIP的角度）视为点对点会话。这是因为标准RFC 3261[2]行为是忽略未知的头参数，例如“isfocus”。
An example call flow is shown in Figure 2. It is assumed that Alice is already a participant of the conference. The focus invites Carol to the conference by sending an INVITE. After the session is established, Carol subscribes to the conference URI. It is important to note that there is no dependency on Carol's SUBSCRIBE (F5) and the NOTIFY to Alice (F9) -- they occur asynchronously and independently.
图2显示了一个示例调用流。假定Alice已经是会议的参与者。focus通过发送邀请邀请Carol参加会议。会话建立后，Carol订阅会议URI。需要注意的是，对Carol的SUBSCRIBE（F5）和NOTIFY to Alice（F9）没有依赖性——它们是异步和独立发生的。
Alice Focus Bob Carol
| | | |
|<==================>| | |
| | |
| Focus "dials out" to add Carol to the conference |
| | |
| | INVITE Contact:Conf-ID;isfocus F1 |
| |---------------------------------------->|
| | 180 Ringing F2 |
| |<----------------------------------------|
| | 200 OK F3 |
| |<----------------------------------------|
| | ACK F4 |
| |---------------------------------------->|
| | RTP |
| |<=======================================>|
| | SUBSCRIBE sip:Conf-ID F5 |
| |<----------------------------------------|
| | 200 OK F6 |
| |---------------------------------------->|
| | NOTIFY F7 |
| |---------------------------------------->|
| | 200 OK F8 |
| |<----------------------------------------|
| NOTIFY F9 | |
|<-------------------| |
| 200 OK F10 | |
|------------------->| |
Alice Focus Bob Carol
| | | |
|<==================>| | |
| | |
| Focus "dials out" to add Carol to the conference |
| | |
| | INVITE Contact:Conf-ID;isfocus F1 |
| |---------------------------------------->|
| | 180 Ringing F2 |
| |<----------------------------------------|
| | 200 OK F3 |
| |<----------------------------------------|
| | ACK F4 |
| |---------------------------------------->|
| | RTP |
| |<=======================================>|
| | SUBSCRIBE sip:Conf-ID F5 |
| |<----------------------------------------|
| | 200 OK F6 |
| |---------------------------------------->|
| | NOTIFY F7 |
| |---------------------------------------->|
| | 200 OK F8 |
| |<----------------------------------------|
| NOTIFY F9 | |
|<-------------------| |
| 200 OK F10 | |
|------------------->| |
Figure 2. A Focus "Dials Out" to Add a Participant to the Conference.
图2。焦点“拨出”以将参与者添加到会议中。
F7 NOTIFY sip:carol@chicago.example.com SIP/2.0 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3343d1 Max-Forwards: 70 To: Carol <sip:carol@chicago.example.com>;tag=43524545 From: <sip:3402934234@conf.example.com>;tag=a3343df32 Call-ID: k3l43id034ksereree CSeq: 34321 NOTIFY Contact: <sip:3402934234@conf.example.com>;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: conference Accept: application/sdp, message/sipfrag Subscription-State: active;expires=3600 Supported: replaces, gruu Content-Type: application/conference-info+xml Content-Length: ...
F7通知sip：carol@chicago.example.comSIP/2.0 Via:SIP/2.0/UDP ms5.conf.example.com；branch=Z9HG4BK343D1最大转发：70到：Carol<sip:carol@chicago.example.com>;标签=43524545发件人：<sip:3402934234@conf.example.com>;tag=a3343df32呼叫ID:K3L43ID034KSEREE CSeq:34321通知联系人：<sip:3402934234@conf.example.com>;isfocus允许：邀请、确认、取消、选项、再见、参考、订阅、通知事件：会议接受：应用程序/sdp、消息/sipfrag订阅状态：活动；expires=3600支持：替换，gruu内容类型：应用程序/会议信息+xml内容长度：。。。
<conference-info version="0" state="full"
entity="sip:3402934234@conf.example.com">
<conference-description>
<conf-uris>
<entry>
<uri>tel:+18882934234</uri>
</entry>
</conf-uris>
</conference-description>
<users>
<user entity="sip:alice@atlanta.example.com" state="full">
<display-text>Alice</display-text>
<endpoint entity="sip:alice@client.atlanta.example.com">
<status>connected</status>
<joining-method>dialed-in</joining-method>
<media id="3">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>647231</src-id>
<status>sendrecv</status>
</media>
<media id="4">
<type>video</type>
<src-id>21345</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
<user entity="sip:carol@chicago.example.com" state="full">
<display-text>Carol</display-text>
<endpoint entity="sip:carol@client.chicago.example.com">
<status>connected</status>
<joining-method>dialed-out</joining-method>
<media id="1">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>583398</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<type>video</type>
<src-id>345212</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>
<conference-info version="0" state="full"
entity="sip:3402934234@conf.example.com">
<conference-description>
<conf-uris>
<entry>
<uri>tel:+18882934234</uri>
</entry>
</conf-uris>
</conference-description>
<users>
<user entity="sip:alice@atlanta.example.com" state="full">
<display-text>Alice</display-text>
<endpoint entity="sip:alice@client.atlanta.example.com">
<status>connected</status>
<joining-method>dialed-in</joining-method>
<media id="3">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>647231</src-id>
<status>sendrecv</status>
</media>
<media id="4">
<type>video</type>
<src-id>21345</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
<user entity="sip:carol@chicago.example.com" state="full">
<display-text>Carol</display-text>
<endpoint entity="sip:carol@client.chicago.example.com">
<status>connected</status>
<joining-method>dialed-out</joining-method>
<media id="1">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>583398</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<type>video</type>
<src-id>345212</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>
F9 NOTIFY sip:alice@atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK3432 Max-Forwards: 70 To: Alice <sip:alice@atlanta.example.com>;tag=43524545 From: <sip:3402934234@conf.example.com>;tag=a3343df32 Call-ID: 8820450524545 CSeq: 998 NOTIFY Contact: <sip:3402934234@conf.example.com>;isfocus Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Event: conference Accept: application/sdp, message/sipfrag Subscription-State: active;expires=2450 Supported: replaces, gruu Content-Type: application/conference-info+xml Content-Length: ...
F9通知sip：alice@atlanta.example.comSIP/2.0 Via:SIP/2.0/UDP ms5.conf.example.com；branch=z9hG4bK3432最大转发：70到：Alice<sip:alice@atlanta.example.com>;标签=43524545发件人：<sip:3402934234@conf.example.com>;tag=a3343df32呼叫ID:882045052455 CSeq:998通知联系人：<sip:3402934234@conf.example.com>;isfocus允许：邀请、确认、取消、选项、再见、参考、订阅、通知事件：会议接受：应用程序/sdp、消息/sipfrag订阅状态：活动；expires=2450支持：替换，gruu内容类型：应用程序/会议信息+xml内容长度：。。。
<conference-info version="1" state="partial"
entity="sip:3402934234@conf.example.com">
<users>
<user entity="sip:carol@chicago.example.com" state="full">
<display-text>Carol</display-text>
<endpoint entity="sip:carol@client.chicago.example.com">
<status>connected</status>
<joining-method>dialed-out</joining-method>
<media id="1">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>583398</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<type>video</type>
<src-id>345212</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>
<conference-info version="1" state="partial"
entity="sip:3402934234@conf.example.com">
<users>
<user entity="sip:carol@chicago.example.com" state="full">
<display-text>Carol</display-text>
<endpoint entity="sip:carol@client.chicago.example.com">
<status>connected</status>
<joining-method>dialed-out</joining-method>
<media id="1">
<display-text>Main Audio</display-text>
<type>audio</type>
<src-id>583398</src-id>
<status>sendrecv</status>
</media>
<media id="2">
<type>video</type>
<src-id>345212</src-id>
<status>sendrecv</status>
</media>
</endpoint>
</user>
</users>
</conference-info>
5.3. INVITE: Manually Creating a Conference by Dialing in to a Conferencing Application
5.3. 邀请：通过拨入会议应用程序手动创建会议
In this section, a user sends an INVITE to a conference server application. The application (such as an IVR system or a web page) is implemented because the system requires additional input from the user before it is able to create a conference. After a normal dialog is established, additional information is received and the conference together with its focus are created. Since the UA is now in a dialog with a focus, the focus will re-INVITE the user with the conference URI in Contact with the 'isfocus' feature parameter.
在本节中，用户向会议服务器应用程序发送邀请。实现应用程序（如IVR系统或网页）是因为系统需要用户的额外输入才能创建会议。建立正常对话后，将收到其他信息，并创建会议及其焦点。由于UA现在处于具有焦点的对话框中，因此焦点将使用与“isfocus”特性参数联系的会议URI重新邀请用户。
Alternatively, the additional information can be provided by the user during an early dialog (see RFC 3261 [2] for a discussion of early dialogs in SIP). This could be accomplished by a 183 Session Progress response sent by the conferencing application. After the conference is created, the conference URI would then be returned in a Contact in the 200 OK.
或者，用户可以在早期对话期间提供附加信息（有关SIP中早期对话的讨论，请参阅RFC 3261[2]）。这可以通过会议应用程序发送183会话进度响应来实现。创建会议后，会议URI将在200 OK中的联系人中返回。
Note that since this flow is all about human interaction with a conferencing application, any errors and failures will be returned to the human (recorded announcements, error tones, etc.).
请注意，由于此流程都是关于人与会议应用程序的交互，因此任何错误和故障都将返回给人（录制的公告、错误提示音等）。
As discussed in the conferencing framework, the conference URI must be unique across all distinct conferences within the same domain. In general, the user part of a conference URI will contain a pseudo random string.
正如会议框架中所讨论的，会议URI在同一域中的所有不同会议中必须是唯一的。通常，会议URI的用户部分将包含伪随机字符串。
An example call flow is shown in Figure 3. In this example, Alice uses a conference application that is triggered when Alice sends an INVITE to the conference application. In this example, Conf-App is used to represent the conference application URI. Alice's conference-aware UA learns of the existence of the conference from the 'isfocus' feature parameter and subscribes to the conference package to receive notifications of the conference state.
图3显示了一个示例调用流。在本例中，Alice使用一个会议应用程序，当Alice向会议应用程序发送邀请时会触发该应用程序。在本例中，Conf-App用于表示会议应用程序URI。Alice的会议感知UA通过“isfocus”功能参数了解会议的存在，并订阅会议包以接收会议状态的通知。
Alice Focus Bob Carol
| | | |
| Alice establishes session with conference application. |
| | | |
| INVITE sip:Conf-App F1 | |
|------------------->| | |
| 180 Ringing F2 | | |
|<-------------------| | |
| 200 OK F3 | | |
|<-------------------| | |
| ACK F4 | | |
|------------------->| | |
| RTP | | |
|<==================>| | |
| | | |
| Alice uses the application to create the conference. |
| | | |
| INVITE Contact:Conf-ID;isfocus F5 | |
|<-------------------| | |
| 200 OK F6 | | |
|------------------->| | |
| ACK F7 | | |
|<-------------------| | |
| RTP | | |
|<==================>| | |
| | | |
| SUBSCRIBE sip:Conf-ID F8 | |
|------------------->| | |
| 200 OK F9 | | |
|<-------------------| | |
| NOTIFY F10 | | |
|<-------------------| | |
| 200 OK F11 | | |
|------------------->| | |
Alice Focus Bob Carol
| | | |
| Alice establishes session with conference application. |
| | | |
| INVITE sip:Conf-App F1 | |
|------------------->| | |
| 180 Ringing F2 | | |
|<-------------------| | |
| 200 OK F3 | | |
|<-------------------| | |
| ACK F4 | | |
|------------------->| | |
| RTP | | |
|<==================>| | |
| | | |
| Alice uses the application to create the conference. |
| | | |
| INVITE Contact:Conf-ID;isfocus F5 | |
|<-------------------| | |
| 200 OK F6 | | |
|------------------->| | |
| ACK F7 | | |
|<-------------------| | |
| RTP | | |
|<==================>| | |
| | | |
| SUBSCRIBE sip:Conf-ID F8 | |
|------------------->| | |
| 200 OK F9 | | |
|<-------------------| | |
| NOTIFY F10 | | |
|<-------------------| | |
| 200 OK F11 | | |
|------------------->| | |
Figure 3. A Participant Creates a Conference Using an Application.
图3。参与者使用应用程序创建会议。
This section addresses creating a conference by using ad-hoc SIP means. The conference factory URI (as defined in Section 3.2) is used to automatically create the conference in this example. This is different from the previous scenario in that no human intervention is required -- an automaton can create the conference and add participants. Since the conference does not need to be scheduled or reserved, but is created "on the fly", it is an "ad-hoc" conference creation.
本节介绍如何使用特设SIP方法创建会议。在本例中，会议工厂URI（定义见第3.2节）用于自动创建会议。这与前面的场景不同，因为不需要人工干预——一个自动装置可以创建会议并添加参与者。由于会议不需要安排或保留，而是“动态”创建的，因此它是一个“临时”会议创建。
The benefit of this approach is that the conference URI need not be known to the user; instead it is created by a focus and used by the participants' UAs. The main difference between this scenario and Section 5.3 is that no user intervention (IVR, web page form, etc.) is required to create the conference.
这种方法的好处是用户不需要知道会议URI；相反，它由焦点创建，并由参与者的UAs使用。此场景与第5.3节的主要区别在于，创建会议不需要用户干预（IVR、网页表单等）。
The SIP URI of the conference factory can be provisioned in the UA (as in a "create new conference" button on a SIP phone) or can be discovered using other means.
会议工厂的SIP URI可以在UA中设置（如在SIP电话上的“创建新会议”按钮中），或者可以使用其他方式发现。
A SIP entity (such as conferencing server) can distinguish this INVITE request as a request to create a new ad-hoc conference from a request to join an existing conference by the Request-URI. That is, although both requests may route to the same application, the differing services requested can be identified by the differing URIs in the request itself.
SIP实体（如会议服务器）可以将此INVITE请求区分为创建新的自组织会议的请求和通过请求URI加入现有会议的请求。也就是说，尽管两个请求都可以路由到同一个应用程序，但请求本身中的不同URI可以识别请求的不同服务。
Assuming that all security and policy requirements have been met, a new conference will be created with the Contact URI returned in the 200 OK being the conference URI. The Contact header field MUST contain the 'isfocus' feature parameter to indicate that this URI is for a conference.
假设满足了所有安全和策略要求，将创建一个新的会议，其中200 OK中返回的联系人URI为会议URI。联系人标头字段必须包含“isfocus”功能参数，以指示此URI用于会议。
An example call flow is shown in Figure 4. Note that Conf-Factory is shorthand for the conference factory URI and Conf-ID Is short for the conference URI. In this flow, Alice has a conference-aware UA and creates a conference by sending an INVITE to the conference factory URI. The conference factory application creates the conference and redirects Alice to the focus using a 302 Moved Temporarily response. Note that with proxy recursion as part of normal RFC 3261 [2] behavior, Alice may never see the redirect but may just receive the responses from the focus starting with message F5. Once the media session is established, Alice subscribes to the conference URI obtained through the Contact in the 200 OK response from the focus.
图4显示了一个示例调用流。请注意，Conf Factory是会议工厂URI的缩写，Conf ID是会议URI的缩写。在这个流程中，Alice有一个会议感知UA，并通过向会议工厂URI发送邀请来创建会议。会议工厂应用程序创建会议，并使用302移动临时响应将Alice重定向到焦点。注意，当代理递归作为正常RFC 3261[2]行为的一部分时，Alice可能永远看不到重定向，但可能只是从焦点接收到从消息F5开始的响应。一旦建立了媒体会话，Alice将订阅通过focus的200 OK响应中的联系人获得的会议URI。
Alice Conf-Factory App Focus Bob
| | | |
| Alice creates the conference. | |
| | | |
| INVITE sip:Conf-Factory F1 | |
|------------------->| | |
| 302 Moved Contact:Conf-ID;isfocus F2 | |
|<-------------------| | |
| ACK F3 | | |
|------------------->| | |
| INVITE sip:Conf-ID F4 | |
|---------------------------------------->| |
| 180 Ringing F5 | |
|<----------------------------------------| |
| 200 OK Contact:Conf-ID;isfocus F6 | |
|<----------------------------------------| |
| ACK F7 | |
|---------------------------------------->| |
| RTP | |
|<=======================================>| |
| | |
| Alice subscribes to the conference URI. | |
| | |
| SUBSCRIBE sip:Conf-ID F8 | |
|---------------------------------------->| |
| 200 OK F9 | |
|<----------------------------------------| |
| NOTIFY F10 | |
|<----------------------------------------| |
| 200 OK F11 | |
|---------------------------------------->| |
Alice Conf-Factory App Focus Bob
| | | |
| Alice creates the conference. | |
| | | |
| INVITE sip:Conf-Factory F1 | |
|------------------->| | |
| 302 Moved Contact:Conf-ID;isfocus F2 | |
|<-------------------| | |
| ACK F3 | | |
|------------------->| | |
| INVITE sip:Conf-ID F4 | |
|---------------------------------------->| |
| 180 Ringing F5 | |
|<----------------------------------------| |
| 200 OK Contact:Conf-ID;isfocus F6 | |
|<----------------------------------------| |
| ACK F7 | |
|---------------------------------------->| |
| RTP | |
|<=======================================>| |
| | |
| Alice subscribes to the conference URI. | |
| | |
| SUBSCRIBE sip:Conf-ID F8 | |
|---------------------------------------->| |
| 200 OK F9 | |
|<----------------------------------------| |
| NOTIFY F10 | |
|<----------------------------------------| |
| 200 OK F11 | |
|---------------------------------------->| |
Figure 4. Creation of a Conference Using SIP Ad-Hoc Methods.
图4。使用SIP临时方法创建会议。
5.5. REFER: Requesting a Focus to Add a New Resource to a Conference (Dial Out to a New Participant)
5.5. 请参阅：请求焦点以向会议添加新资源（拨出给新参与者）
A SIP conference URI can be used to inject different kinds of information into the conference. Examples include new participants, new real-time media sources, new IM messages, and pointers to passive information references (such as HTTP URIs).
SIP会议URI可用于向会议中注入不同类型的信息。示例包括新的参与者、新的实时媒体源、新的IM消息和指向被动信息引用（如HTTP URI）的指针。
To request that the focus add a new information resource to the specified conference, any SIP UA can send a REFER to the conference URI with a Refer-To containing the URI of the new resource. Since this REFER is sent to the conference URI and not the conference factory URI, the semantics to the focus are to bring the resource into the conference and make it visible to the conference
为了请求焦点向指定的会议添加新的信息资源，任何SIP UA都可以发送一个refere-To-the-conference URI，其中refere包含新资源的URI。由于此引用被发送到会议URI而不是会议工厂URI，因此焦点的语义是将资源引入会议并使其对会议可见
participants. The resultant focus procedures are dependent both on the nature of the new resource (as expressed by its URI) and the policy of the focus regarding IM, central vs. distributed real-time media processing, and so on.
参与者。由此产生的聚焦过程既取决于新资源的性质（由其URI表示），也取决于聚焦的IM策略、中央与分布式实时媒体处理等。
The scenario for adding a new UA participant is important to support because it works even if the new participant does not support REFER and transfer call control -- only the requesting participant and the focus need to support the REFER and transfer call control.
添加新UA参与者的场景需要支持，因为即使新参与者不支持转介和转接呼叫控制，该场景也可以工作——只有请求参与者和焦点需要支持转介和转接呼叫控制。
Upon receipt of the REFER containing a Refer-To header with a SIP URI, the focus SHOULD send an INVITE to the new participant identified by the Refer-To SIP URI containing a Contact header field with the conference URI and the 'isfocus' feature parameter.
在收到包含带有SIP URI的REFER-REFER标头的REFER后，focus应向由REFER-REFER SIP URI标识的新参与者发送邀请，REFER-REFER SIP URI包含带有会议URI和“isfocus”功能参数的联系人标头字段。
A conference-unaware UA would simply ignore the conferencing information and treat the session (from a SIP perspective) as a point-to-point session.
不知道会议的UA只会忽略会议信息，并将会话（从SIP的角度）视为点对点会话。
An example call flow is shown in Figure 5. While this flow shows the use of REFER to add a new participant to the conference, the mechanism can generally add a resource as identified by a URI to the conference. It is assumed that Alice is already a participant of the conference. Alice sends a REFER to the conference URI. The focus invites Carol to the conference by sending an INVITE. After the session is established, Carol subscribes to the conference URI. It is important to note that there is no dependency on Carol's SUBSCRIBE (F11) and the NOTIFY to Alice (F15) -- they occur asynchronously and independently.
图5显示了一个示例调用流。虽然此流程显示了使用REFER向会议添加新参与者，但该机制通常可以向会议添加由URI标识的资源。假定Alice已经是会议的参与者。Alice发送一个指向会议URI的引用。focus通过发送邀请邀请Carol参加会议。会话建立后，Carol订阅会议URI。需要注意的是，不依赖于Carol的SUBSCRIBE（F11）和NOTIFY to Alice（F15）——它们是异步和独立发生的。
Alice Focus Bob Carol
| | | |
|<==================>| | |
| REFER sip:Conf-ID Refer-To:Carol F1 | |
|------------------->| |
| 202 Accepted F2 | |
|<-------------------| |
| NOTIFY (Trying) F3 |
|<-------------------| |
| 200 OK F4 | |
|------------------->| |
| | |
| Focus "dials out" to join Carol to the conference |
| | |
| | INVITE Contact:Conf-ID;isfocus F5 |
| |---------------------------------------->|
| | 180 Ringing F6 |
| |<----------------------------------------|
| | 200 OK F7 |
| |<----------------------------------------|
| | ACK F8 |
| |---------------------------------------->|
| | RTP |
| |<=======================================>|
| NOTIFY (OK) F9 | |
|<-------------------| |
| 200 OK F10 | |
|------------------->| |
| | SUBSCRIBE sip:Conf-ID F11 |
| |<----------------------------------------|
| | 200 OK F12 |
| |---------------------------------------->|
| | NOTIFY F13 |
| |---------------------------------------->|
| | 200 OK F14 |
| |<----------------------------------------|
| NOTIFY F15 | |
|<-------------------| |
| 200 OK F16 | |
|------------------->| |
Alice Focus Bob Carol
| | | |
|<==================>| | |
| REFER sip:Conf-ID Refer-To:Carol F1 | |
|------------------->| |
| 202 Accepted F2 | |
|<-------------------| |
| NOTIFY (Trying) F3 |
|<-------------------| |
| 200 OK F4 | |
|------------------->| |
| | |
| Focus "dials out" to join Carol to the conference |
| | |
| | INVITE Contact:Conf-ID;isfocus F5 |
| |---------------------------------------->|
| | 180 Ringing F6 |
| |<----------------------------------------|
| | 200 OK F7 |
| |<----------------------------------------|
| | ACK F8 |
| |---------------------------------------->|
| | RTP |
| |<=======================================>|
| NOTIFY (OK) F9 | |
|<-------------------| |
| 200 OK F10 | |
|------------------->| |
| | SUBSCRIBE sip:Conf-ID F11 |
| |<----------------------------------------|
| | 200 OK F12 |
| |---------------------------------------->|
| | NOTIFY F13 |
| |---------------------------------------->|
| | 200 OK F14 |
| |<----------------------------------------|
| NOTIFY F15 | |
|<-------------------| |
| 200 OK F16 | |
|------------------->| |
Figure 5. Participant Requests That the Focus Add a Participant to the Conference.
图5。参与者要求焦点为会议添加一名参与者。
F1 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:alice@alice.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:carol@chicago.example.com>
Supported: replaces
Content-Length: 0
F1 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:alice@alice.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:carol@chicago.example.com>
Supported: replaces
Content-Length: 0
5.6. REFER: Requesting a User to Dial in to a Conference Using a Conference URI
5.6. 请参阅：请求用户使用会议URI拨入会议
A participant wishing to add a new participant will request this participant to send an INVITE to the conference URI. This can be done using a non-SIP means (such as passing or publishing the conference URI in an email, IM, or web page). If a non-SIP means is used, then the flow and requirements are identical to Section 5.1.
希望添加新参与者的参与者将请求该参与者向会议URI发送邀请。这可以使用非SIP方式来完成（例如在电子邮件、IM或网页中传递或发布会议URI）。如果使用非SIP方式，则流程和要求与第5.1节相同。
The SIP mechanism to do this utilizes the REFER method.
执行此操作的SIP机制使用REFER方法。
A UA wishing to add a new participant SHOULD send a REFER request to the participant with a Refer-To header containing the conference URI.
希望添加新参与者的UA应向参与者发送包含会议URI的REFER-REFER标头的REFER请求。
The requirements are then identical to the dial-in case of Section 5.1. The inviting participant MAY receive notification through the REFER action that the new participant has been added in addition to the notification received through the conference package.
这些要求与第5.1节中的刻度盘相同。邀请参与者可通过REFER操作收到通知，说明除了通过会议包收到的通知外，还添加了新参与者。
An example is shown in Figure 6. In this call flow, it is assumed that Alice is already a participant of the conference. Alice sends Bob an "out of band" REFER - that is, a REFER outside of an established dialog. Should Bob reject the REFER, Alice might try sending an INVITE to Bob to establish a session first, then send a REFER within the dialog, effectively transferring Bob into the conference [17].
图6显示了一个示例。在此呼叫流中，假定Alice已经是会议的参与者。Alice向Bob发送一个“带外”引用，即在已建立的对话框之外的引用。如果Bob拒绝转介，Alice可能会尝试先向Bob发送邀请以建立会话，然后在对话框中发送转介，从而有效地将Bob转移到会议中[17]。
Alice Focus Bob Carol
| | | |
|<==================>| | |
| | | |
| Alice adds Bob into conference | |
| | | |
| REFER Refer-To:Conf-ID F1 | |
|---------------------------------------->| |
| 202 Accepted F2 | | |
|<----------------------------------------| |
| NOTIFY (Trying) F3| | |
|<----------------------------------------| |
| 200 OK F4 | | |
|---------------------------------------->| |
| | INVITE sip:Conf-ID F5 |
| |<-------------------| |
| | 180 Ringing F6 | |
| |------------------->| |
| | 200 OK Contact:Conf-ID;isfocus F7 |
| |------------------->| |
| | ACK F8 | |
| |<-------------------| |
| | RTP | |
| |<==================>| |
| NOTIFY (OK) F9 | | |
|<----------------------------------------| |
| 200 OK F10 | | |
|---------------------------------------->| |
| NOTIFY F11 | | |
|<-------------------| | |
| 200 OK F12 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F13 |
| |<-------------------| |
| | 200 OK F14 | |
| |------------------->| |
| | NOTIFY F15 | |
| |------------------->| |
| | 200 OK F16 | |
| |<-------------------| |
Alice Focus Bob Carol
| | | |
|<==================>| | |
| | | |
| Alice adds Bob into conference | |
| | | |
| REFER Refer-To:Conf-ID F1 | |
|---------------------------------------->| |
| 202 Accepted F2 | | |
|<----------------------------------------| |
| NOTIFY (Trying) F3| | |
|<----------------------------------------| |
| 200 OK F4 | | |
|---------------------------------------->| |
| | INVITE sip:Conf-ID F5 |
| |<-------------------| |
| | 180 Ringing F6 | |
| |------------------->| |
| | 200 OK Contact:Conf-ID;isfocus F7 |
| |------------------->| |
| | ACK F8 | |
| |<-------------------| |
| | RTP | |
| |<==================>| |
| NOTIFY (OK) F9 | | |
|<----------------------------------------| |
| 200 OK F10 | | |
|---------------------------------------->| |
| NOTIFY F11 | | |
|<-------------------| | |
| 200 OK F12 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F13 |
| |<-------------------| |
| | 200 OK F14 | |
| |------------------->| |
| | NOTIFY F15 | |
| |------------------->| |
| | 200 OK F16 | |
| |<-------------------| |
Figure 6. Adding a Participant to an Existing Conference.
图6。将参与者添加到现有会议。
5.7. REFER with REFER: Requesting a Focus to Refer a Participant to Dial in to the Conference
5.7. 参考：请求焦点，以推荐参与者拨入会议
A participant may request that the focus refer a participant into the conference by sending a REFER method. The Refer-To header field will have the method set to REFER and an escaped Refer-To header field containing the conference URI.
参与者可以请求焦点通过发送refer方法将参与者引入会议。refere-To-header字段将方法设置为refere，并将包含会议URI的转义refere-To-header字段设置为refere。
Note that in Message F1 below, the Refer-To header field is shown as continuing across two lines -- this would not be the case in an actual message; the URI would have continued beyond the formatting limitations of this document.
请注意，在下面的消息F1中，refere-To-header字段显示为跨两行继续显示——实际消息中并非如此；此文档的格式将超出URI的限制。
This scenario is shown in Figure 7.
此场景如图7所示。
Alice Focus Bob Carol
| | | |
|<==================>| | |
| Alice asks focus to REFER Bob into conference |
| | | |
|REFER sip:Conf-ID Refer-To:Bob;method=REFER?Refer-To=Conf-ID F1
|------------------->| | |
| 202 Accepted F2 | | |
|<-------------------| | |
| NOTIFY (Trying) F3| | |
|<-------------------| | |
| 200 OK F4 | | |
|------------------->| | |
| Focus REFERs Bob to the conference |
| | | |
| | REFER Refer-To:Conf-ID F5 |
| |------------------->| |
| | 202 Accepted F6 | |
| NOTIFY (202) F7 |<-------------------| |
|<-------------------| NOTIFY (Trying) F8 | |
| 200 OK F9 |<-------------------| |
|------------------->| 200 OK F10 | |
| |------------------->| |
| | INVITE sip:Conf-ID F11 |
| |<-------------------| |
| | 180 Ringing F12 | |
| |------------------->| |
| | 200 OK Contact:Conf-ID;isfocus F13 |
| |------------------->| |
| | ACK F14 | |
| NOTIFY F15 |<-------------------| |
|<-------------------| RTP | |
| 200 OK F16 |<==================>| |
|------------------->| NOTIFY (200) F17 | |
| |<-------------------| |
| | 200 OK F18 | |
| |------------------->| |
| | SUBSCRIBE sip:Conf-ID F17 |
| |<-------------------| |
| | 200 OK F19 | |
| |------------------->| |
| | NOTIFY F20 | |
| |------------------->| |
| | 200 OK F21 | |
| |<-------------------| |
Alice Focus Bob Carol
| | | |
|<==================>| | |
| Alice asks focus to REFER Bob into conference |
| | | |
|REFER sip:Conf-ID Refer-To:Bob;method=REFER?Refer-To=Conf-ID F1
|------------------->| | |
| 202 Accepted F2 | | |
|<-------------------| | |
| NOTIFY (Trying) F3| | |
|<-------------------| | |
| 200 OK F4 | | |
|------------------->| | |
| Focus REFERs Bob to the conference |
| | | |
| | REFER Refer-To:Conf-ID F5 |
| |------------------->| |
| | 202 Accepted F6 | |
| NOTIFY (202) F7 |<-------------------| |
|<-------------------| NOTIFY (Trying) F8 | |
| 200 OK F9 |<-------------------| |
|------------------->| 200 OK F10 | |
| |------------------->| |
| | INVITE sip:Conf-ID F11 |
| |<-------------------| |
| | 180 Ringing F12 | |
| |------------------->| |
| | 200 OK Contact:Conf-ID;isfocus F13 |
| |------------------->| |
| | ACK F14 | |
| NOTIFY F15 |<-------------------| |
|<-------------------| RTP | |
| 200 OK F16 |<==================>| |
|------------------->| NOTIFY (200) F17 | |
| |<-------------------| |
| | 200 OK F18 | |
| |------------------->| |
| | SUBSCRIBE sip:Conf-ID F17 |
| |<-------------------| |
| | 200 OK F19 | |
| |------------------->| |
| | NOTIFY F20 | |
| |------------------->| |
| | 200 OK F21 | |
| |<-------------------| |
Figure 7. Requesting That the Focus Refer a Participant to a Conference.
图7。要求焦点将参与者引向会议。
F1 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:alice@alice.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:bob@biloxi.example.com;method=REFER
?Refer-To=sip:3402934234%40example.com>
Supported: replaces
Content-Length: 0
F1 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:alice@alice.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:bob@biloxi.example.com;method=REFER
?Refer-To=sip:3402934234%40example.com>
Supported: replaces
Content-Length: 0
F5 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK33445243
Max-Forwards: 70
To: <sip:bob@biloxi.example.com>
From: <sip:3402934234@conf.example.com>;tag=345621412
Call-ID: 5494204
CSeq: 4524323 REFER
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:3402934234@conf.example.com>
Supported: join, gruu, replaces
Content-Length: 0
F5 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK33445243
Max-Forwards: 70
To: <sip:bob@biloxi.example.com>
From: <sip:3402934234@conf.example.com>;tag=345621412
Call-ID: 5494204
CSeq: 4524323 REFER
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:3402934234@conf.example.com>
Supported: join, gruu, replaces
Content-Length: 0
F11 INVITE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3887
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Bob <sip:bob@biloxi.example.com>;tag=32411
Call-ID: 5d4324fa84b4c76e66710
CSeq: 764 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Supported: replaces, join
Content-Type: application/sdp
Content-Length: ...
F11 INVITE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3887
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Bob <sip:bob@biloxi.example.com>;tag=32411
Call-ID: 5d4324fa84b4c76e66710
CSeq: 764 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Supported: replaces, join
Content-Type: application/sdp
Content-Length: ...
(SDP not shown)
（未显示SDP）
5.8. Join Header Field: Dialing in to a Conference Using a (3rd Party) Dialog Identifier
5.8. 加入标题字段：使用（第三方）对话框标识符拨入会议
Under some circumstances, a participant wanting to join a conference may only know a dialog identifier of one of the legs of the conference. The information may have been learned using the dialog package [18] or some non-SIP means to retrieve this information from another conference participant.
在某些情况下，想要参加会议的参与者可能只知道会议一个分支的对话标识符。该信息可能已经使用对话包[18]或一些非SIP手段从另一个会议参与者处检索到。
A UA can request to be added to a conference by sending a request to the focus containing a Join [7] header field containing a dialog ID of one leg of the conference (a dialog between another participant and the focus).
UA可以通过向焦点发送请求来请求添加到会议中，该请求包含加入[7]头字段，该字段包含会议一个分支的对话ID（另一参与者和焦点之间的对话）。
There are other scenarios in which a UA can use the Join header for certain conferencing call control scenarios. See [7] for further examples and details.
UA还可以在某些会议呼叫控制场景中使用连接头。有关更多示例和详细信息，请参见[7]。
An example is shown in Figure 8. It is assumed that Alice is a participant of the conference. The dialog identifier between Alice and the focus is abbreviated as A-F and is known by Bob. Bob requests to be added to the conference by sending an INVITE message F1 to the focus containing a Join header that contains the dialog identifier A-F. Bob is added into the conference by the focus.
图8显示了一个示例。假定Alice是会议的参与者。Alice和焦点之间的对话框标识符缩写为A-F，Bob知道该标识符。Bob通过向focus发送邀请消息F1请求添加到会议，该消息包含包含对话框标识符a-F的Join标头。focus将Bob添加到会议中。
Alice Focus Bob Carol
| | | |
|<==================>| | |
| | | |
| Bob requests to be added to the conference. |
| | | |
| | INVITE Join:A-F F1| |
| |<-------------------| |
| | 180 Ringing F2 | |
| |------------------->| |
| | 200 OK Contact:Conf-ID;isfocus F3 |
| |------------------->| |
| | ACK F4 | |
| |<-------------------| |
| | RTP | |
| NOTIFY F5 |<==================>| |
|<-------------------| SUBSCRIBE sip:Conf-ID F6 |
| 200 OK F7 |<-------------------| |
|------------------->| 200 OK F8 | |
| |------------------->| |
| | NOTIFY F9 | |
| |------------------->| |
| | 200 OK F10 | |
| |<-------------------| |
Alice Focus Bob Carol
| | | |
|<==================>| | |
| | | |
| Bob requests to be added to the conference. |
| | | |
| | INVITE Join:A-F F1| |
| |<-------------------| |
| | 180 Ringing F2 | |
| |------------------->| |
| | 200 OK Contact:Conf-ID;isfocus F3 |
| |------------------->| |
| | ACK F4 | |
| |<-------------------| |
| | RTP | |
| NOTIFY F5 |<==================>| |
|<-------------------| SUBSCRIBE sip:Conf-ID F6 |
| 200 OK F7 |<-------------------| |
|------------------->| 200 OK F8 | |
| |------------------->| |
| | NOTIFY F9 | |
| |------------------->| |
| | 200 OK F10 | |
| |<-------------------| |
Figure 8. Adding a Participant to an Existing Conference using Join.
图8。使用“加入”将参与者添加到现有会议。
F1 INVITE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3832
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Bob <sip:bob@biloxi.example.com>;tag=32411
Call-ID: d432fa84b4c76e66710
CSeq: 8 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Join: 3434034-293553453;to-tag=fdj3l34;from-tag=12f331
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Supported: replaces, join
Content-Type: application/sdp
Content-Length: ...
F1 INVITE sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.biloxi.com;branch=z9hG4bKh3832
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Bob <sip:bob@biloxi.example.com>;tag=32411
Call-ID: d432fa84b4c76e66710
CSeq: 8 INVITE
Contact: <sip:bob@client.biloxi.example.com>
Join: 3434034-293553453;to-tag=fdj3l34;from-tag=12f331
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Supported: replaces, join
Content-Type: application/sdp
Content-Length: ...
(SDP not shown)
（未显示SDP）
Participants in a conference may want to change the user agent (i.e., the endpoint or the device) with which they participate in the conference. This could be done by simply sending a BYE from one user agent to leave the conference and an INVITE from the other user agent to rejoin. However, the SIP Replaces [6] primitive is perfectly suited to this operation.
会议参与者可能希望更改他们参与会议的用户代理（即端点或设备）。这可以通过简单地从一个用户代理发送“再见”以离开会议，并从另一个用户代理发送“邀请”以重新加入会议来实现。但是，SIP Replaces[6]原语非常适合此操作。
An example is shown in Figure 9. It is assumed that Alice is a participant of the conference using user agent #1. The dialog identifier between Alice's user agent #1 and the focus is abbreviated as A-F. Alice switches to user agent #2 and sends an INVITE message F1 to the focus containing a Replaces header that contains the dialog identifier A-F. Note that this dialog identifier could be learned through some non-SIP mechanism, or by use of SUBSCRIBE/NOTIFY and the dialog event package [18]. Alice's user agent #2 is added into the conference by the focus. The focus sends a BYE to user agent #1. User agent #1 then automatically terminates the subscription by sending a SUBSCRIBE with Expires:0 to terminate the subscription. Note that the participant list (roster) has not necessarily changed during this scenario, unless detailed information about Alice user agents (i.e. endpoints) is included in the conference state notifications. For a full discussion of conference package notifications, refer to [9].
图9显示了一个示例。假设Alice是使用用户代理1的会议参与者。Alice的用户代理#1和焦点之间的对话标识符缩写为A-F。Alice切换到用户代理#2并向焦点发送邀请消息F1，其中包含包含对话标识符A-F的替换头。请注意，可以通过一些非SIP机制学习此对话标识符，或者使用订阅/通知和对话框事件包[18]。Alice的用户代理2由focus添加到会议中。焦点向用户代理1发送再见。然后，用户代理#1通过发送过期时间为0的订阅来自动终止订阅，以终止订阅。请注意，在此场景中，参与者列表（花名册）不一定会更改，除非有关Alice用户代理（即端点）的详细信息包含在会议状态通知中。有关会议包通知的完整讨论，请参阅[9]。
Alice UA#1 Focus Alice UA#2 Carol
| | | |
|<==================>| | |
| | | |
| Alice switches user agents during the conference. |
| | | |
| | INVITE sip:Conf-ID Replaces:A-F F1 |
| |<-------------------| |
| | 200 OK Contact:Conf-ID;isfocus F2 |
| |------------------->| |
| | ACK F3 | |
| |<-------------------| |
| | RTP | |
| |<==================>| |
| BYE F4 | | |
|<-------------------| | |
| 200 OK F5 | | |
|------------------->| | |
| SUBSCRIBE Expires:0 F6 | |
|------------------->| | |
| 200 OK F7 | | |
|<-------------------| | |
| NOTIFY Subscription-State:terminated F8 | |
|<-------------------| | |
| 200 OK F9 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F10 |
| |<-------------------| |
| | 200 OK F11 | |
| |------------------->| |
| | NOTIFY F12 | |
| |------------------->| |
| | 200 OK F13 | |
| |<-------------------| |
Alice UA#1 Focus Alice UA#2 Carol
| | | |
|<==================>| | |
| | | |
| Alice switches user agents during the conference. |
| | | |
| | INVITE sip:Conf-ID Replaces:A-F F1 |
| |<-------------------| |
| | 200 OK Contact:Conf-ID;isfocus F2 |
| |------------------->| |
| | ACK F3 | |
| |<-------------------| |
| | RTP | |
| |<==================>| |
| BYE F4 | | |
|<-------------------| | |
| 200 OK F5 | | |
|------------------->| | |
| SUBSCRIBE Expires:0 F6 | |
|------------------->| | |
| 200 OK F7 | | |
|<-------------------| | |
| NOTIFY Subscription-State:terminated F8 | |
|<-------------------| | |
| 200 OK F9 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F10 |
| |<-------------------| |
| | 200 OK F11 | |
| |------------------->| |
| | NOTIFY F12 | |
| |------------------->| |
| | 200 OK F13 | |
| |<-------------------| |
Figure 9. Switching a User Agent within a Conference.
图9。在会议中切换用户代理。
5.10. Replaces Header Field: Transferring a Point-to-Point Session into a Conference
5.10. 替换标题字段：将点对点会话传输到会议
This call flow shows how a point-to-point call can be transferred to a conference call involving an external focus.
此呼叫流显示如何将点对点呼叫转移到涉及外部焦点的会议呼叫。
Alice and Bob have an established session with a dialog identifier A-B. Alice joins the conference with the focus by sending an INVITE to the Conference URI. Alice then sends a REFER request to the focus to send an INVITE request to the other participant. Alice includes an escaped Replaces header field in the URI included in the Refer-To
Alice和Bob有一个已建立的会话，会话标识符为a-B。Alice通过向会议URI发送邀请来加入会议。然后，Alice向焦点发送一个REFER请求，向另一个参与者发送一个INVITE请求。Alice在引用中包含的URI中包含转义的Replaces头字段
header field. Bob receives the INVITE from the focus and matches the dialog in the Replaces header field with the dialog with Alice. As a result, Bob accepts the INVITE, joins the conference, and sends a BYE to Alice to tear down their point-to-point dialog.
标题字段。Bob从focus接收到邀请，并将Replaces header字段中的对话框与Alice对话框匹配。结果，Bob接受了邀请，加入了会议，并向Alice发送了一个拜拜，打断了他们的点对点对话。
Alice Focus Bob Carol
| | | |
| Alice is in a session with Bob | |
|<=======================================>| |
| | | |
| Alice joins the conference | |
| | | |
| INVITE sip:Conf-ID F1 | |
|------------------->| | |
| 200 OK Contact:sip:Conf-ID;isfocus F2 | |
|<-------------------| | |
| ACK F3 | | |
|------------------->| | |
| SUBSCRIBE F4 | | |
|------------------->| | |
| 200 OK F5 | | |
|<-------------------| | |
| NOTIFY F6 | | |
|<-------------------| | |
| 200 OK F7 | | |
|------------------->| | |
|<==================>| | |
| | | |
| Alice asks focus to REFER Bob into conference |
| | | |
| REFER sip:Conf-ID Refer-To:Bob?Replaces=A-B F8 |
|------------------->| | |
| 202 Accepted F9 | | |
|<-------------------| | |
| NOTIFY (Trying) F10| | |
|<-------------------| | |
| 200 OK F11 | | |
|------------------->| | |
| | | |
| Focus invites Bob to the conference |
| | | |
| | INVITE sip:Conf-ID Replaces:A-B F12 |
| |------------------->| |
| | 200 OK F13 | |
| |<-------------------| |
| | ACK F14 | |
| |------------------->| |
| | RTP | |
Alice Focus Bob Carol
| | | |
| Alice is in a session with Bob | |
|<=======================================>| |
| | | |
| Alice joins the conference | |
| | | |
| INVITE sip:Conf-ID F1 | |
|------------------->| | |
| 200 OK Contact:sip:Conf-ID;isfocus F2 | |
|<-------------------| | |
| ACK F3 | | |
|------------------->| | |
| SUBSCRIBE F4 | | |
|------------------->| | |
| 200 OK F5 | | |
|<-------------------| | |
| NOTIFY F6 | | |
|<-------------------| | |
| 200 OK F7 | | |
|------------------->| | |
|<==================>| | |
| | | |
| Alice asks focus to REFER Bob into conference |
| | | |
| REFER sip:Conf-ID Refer-To:Bob?Replaces=A-B F8 |
|------------------->| | |
| 202 Accepted F9 | | |
|<-------------------| | |
| NOTIFY (Trying) F10| | |
|<-------------------| | |
| 200 OK F11 | | |
|------------------->| | |
| | | |
| Focus invites Bob to the conference |
| | | |
| | INVITE sip:Conf-ID Replaces:A-B F12 |
| |------------------->| |
| | 200 OK F13 | |
| |<-------------------| |
| | ACK F14 | |
| |------------------->| |
| | RTP | |
| |<==================>| |
| BYE F15 | |
|<----------------------------------------| |
| 200 OK F16 | |
|---------------------------------------->| |
| NOTIFY (200) F17 | | |
|<-------------------| | |
| 200 OK F18 | | |
|------------------->| | |
| NOTIFY F19 | | |
|<-------------------| | |
| 200 OK F20 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F21 |
| |<-------------------| |
| | 200 OK F22 | |
| |------------------->| |
| | NOTIFY F23 | |
| |------------------->| |
| | 200 OK F24 | |
| |<-------------------| |
| | | |
| |<==================>| |
| BYE F15 | |
|<----------------------------------------| |
| 200 OK F16 | |
|---------------------------------------->| |
| NOTIFY (200) F17 | | |
|<-------------------| | |
| 200 OK F18 | | |
|------------------->| | |
| NOTIFY F19 | | |
|<-------------------| | |
| 200 OK F20 | | |
|------------------->| | |
| | SUBSCRIBE sip:Conf-ID F21 |
| |<-------------------| |
| | 200 OK F22 | |
| |------------------->| |
| | NOTIFY F23 | |
| |------------------->| |
| | 200 OK F24 | |
| |<-------------------| |
| | | |
Figure 10. Transitioning a Point to Point Session into a Conference.
图10。将点对点会话转换为会议。
5.11. REFER with BYE: Requesting That the Focus Remove a Participant from a Conference
5.11. 用“再见”表示：请求焦点将参与者从会议中移除
To request that the focus remove a participant from the specified conference, a properly authorized SIP UA (typically the conference owner) can send a REFER to the conference URI with a Refer-To containing the URI of the participant and with the method set to BYE. The requestor does not need to know the dialog information about the dialog between the focus and the participant who will be removed -- the focus knows this information and fills it when it generates the BYE request.
为了请求焦点将参与者从指定的会议中移除，经过适当授权的SIP UA（通常是会议所有者）可以发送refere-refere会议URI，其中refere包含参与者的URI，并且方法设置为BYE。请求者不需要知道焦点和将被删除的参与者之间的对话信息——焦点知道这些信息，并在生成BYE请求时填充这些信息。
An example call flow is shown in Figure 11. It is assumed that Alice and Carol are already participants of the conference and that Alice is authorized to remove members from the conference. Alice sends a REFER to the conference URI with a Refer-To header containing a URI of the form sip:carol@chicago.example.com;method=BYE.
图11显示了一个示例调用流。假设Alice和Carol已经是会议的参与者，并且Alice有权从会议中删除成员。Alice发送一个refere-to-the-conference URI，其中refere-to头包含一个形式为sip:carol@chicago.example.com;方法=再见。
Alice Focus Bob Carol
| | | |
|<==================>| |
| REFER sip:Conf-ID Refer-To:Carol;method=BYE F1 |
|------------------->| |
| 202 Accepted F2 | |
|<-------------------| |
| NOTIFY (Trying) F3 |
|<-------------------| |
| 200 OK F4 | |
|------------------->| |
| | |
| Focus removes Carol from the conference |
| | |
| | BYE sip:Carol F5 |
| |---------------------------------------->|
| | 200 OK F6 |
| |<----------------------------------------|
| | NOTIFY Subscription-State:terminated F7 |
| |---------------------------------------->|
| | 200 OK F8 |
| |<----------------------------------------|
| NOTIFY (200) F9 | |
|<-------------------| |
| 200 OK F10 | |
|------------------->| |
| NOTIFY F11 | |
|<-------------------| |
| 200 OK F12 | |
|------------------->| |
Alice Focus Bob Carol
| | | |
|<==================>| |
| REFER sip:Conf-ID Refer-To:Carol;method=BYE F1 |
|------------------->| |
| 202 Accepted F2 | |
|<-------------------| |
| NOTIFY (Trying) F3 |
|<-------------------| |
| 200 OK F4 | |
|------------------->| |
| | |
| Focus removes Carol from the conference |
| | |
| | BYE sip:Carol F5 |
| |---------------------------------------->|
| | 200 OK F6 |
| |<----------------------------------------|
| | NOTIFY Subscription-State:terminated F7 |
| |---------------------------------------->|
| | 200 OK F8 |
| |<----------------------------------------|
| NOTIFY (200) F9 | |
|<-------------------| |
| 200 OK F10 | |
|------------------->| |
| NOTIFY F11 | |
|<-------------------| |
| 200 OK F12 | |
|------------------->| |
Figure 11. Participant Requests That the Focus Remove a Participant from the Conference.
图11。参与者请求焦点将参与者从会议中移除。
F1 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:alice@alice.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:carol@chicago.example.com;method=BYE>
Supported: replaces
Content-Length: 0
F1 REFER sip:3402934234@conf.example.com SIP/2.0
Via: SIP/2.0/UDP client.atlanta.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:3402934234@conf.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:alice@alice.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Accept: application/sdp, message/sipfrag
Refer-To: <sip:carol@chicago.example.com;method=BYE>
Supported: replaces
Content-Length: 0
F5 BYE sip:carol@client.chicago.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK343gf4
Max-Forwards: 70
From: <sip:3402934234@conf.example.com>;tag=5393k2312
To: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 78654 BYE
Content-Length: 0
F5 BYE sip:carol@client.chicago.example.com SIP/2.0
Via: SIP/2.0/UDP ms5.conf.example.com;branch=z9hG4bK343gf4
Max-Forwards: 70
From: <sip:3402934234@conf.example.com>;tag=5393k2312
To: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 78654 BYE
Content-Length: 0
The default conference policy for conferences created using the Conference Factory URI is that the conference is deleted when the creator departs.
使用会议工厂URI创建的会议的默认会议策略是，在创建者离开时删除会议。
Figure 12 shows this call flow in which the creator Alice departs causing the conference to be deleted. Note that the order of sending BYEs and final NOTIFYs is not important.
图12显示了创建者Alice离开导致会议被删除的调用流。请注意，发送“是”和“最终通知”的顺序并不重要。
Alice Focus Bob Carol
| | | |
|<==================>|<==================>| |
| BYE F1 |<=======================================>|
|------------------->| | |
| 200 OK F2 | | |
|<-------------------| | |
| | BYE F3 | |
| |------------------->| |
| | 200 OK F4 | |
| |<-------------------| |
| | BYE F5 |
| |---------------------------------------->|
| | 200 OK F6 |
| |<----------------------------------------|
| NOTIFY Subscription-State:terminated F7 |
|<-------------------| | |
| 200 OK F8 | | |
|------------------->| NOTIFY Subscription-State:terminated F9 |
| |------------------->| |
| | 200 OK F10 | |
| |<-------------------| |
| | NOTIFY Subscription-State:terminated F11|
| |---------------------------------------->|
| | 200 OK F12 |
| |<----------------------------------------|
Alice Focus Bob Carol
| | | |
|<==================>|<==================>| |
| BYE F1 |<=======================================>|
|------------------->| | |
| 200 OK F2 | | |
|<-------------------| | |
| | BYE F3 | |
| |------------------->| |
| | 200 OK F4 | |
| |<-------------------| |
| | BYE F5 |
| |---------------------------------------->|
| | 200 OK F6 |
| |<----------------------------------------|
| NOTIFY Subscription-State:terminated F7 |
|<-------------------| | |
| 200 OK F8 | | |
|------------------->| NOTIFY Subscription-State:terminated F9 |
| |------------------->| |
| | 200 OK F10 | |
| |<-------------------| |
| | NOTIFY Subscription-State:terminated F11|
| |---------------------------------------->|
| | 200 OK F12 |
| |<----------------------------------------|
Figure 12. Deleting a Conference.
图12。删除会议。
A UA MAY send an OPTIONS request to discover if an opaque URI is a conference URI (resolves to a focus). In addition, the reply to the OPTIONS request can also indicate support for various SIP call control extensions used in this document.
UA可以发送选项请求，以发现不透明URI是否为会议URI（解析为焦点）。此外，对选项请求的回复还可以表示对本文档中使用的各种SIP呼叫控制扩展的支持。
Note that the Allow, Accept, Allow-Events, and Supported header fields should be present in an INVITE from a focus or a 200 OK answer from the focus to an INVITE as a part of a normal dialog establishment process.
请注意，作为正常对话框建立过程的一部分，允许、接受、允许事件和支持的标题字段应该出现在来自焦点的邀请或来自焦点的200 OK回答中。
An example is shown in Figure 13 where Alice sends an OPTIONS to a URI that resolves to a focus.
图13显示了一个示例，其中Alice向解析为焦点的URI发送一个选项。
Alice Focus Bob Carol
| | | |
| OPTIONS sip:Conf-ID F1 | |
|------------------->| | |
| 200 OK Contact:Conf-ID;isfocus F2 | |
|<-------------------| | |
Alice Focus Bob Carol
| | | |
| OPTIONS sip:Conf-ID F1 | |
|------------------->| | |
| 200 OK Contact:Conf-ID;isfocus F2 | |
|<-------------------| | |
Figure 13. Participant Queries Capabilities of URI of a Focus.
图13。参与者查询焦点的URI的功能。
Following is an example of message detail of message F2 in Figure 13. Based on the response, Alice's UA learns that the URI is a conference URI and that the responding UA is focus that supports a number of SIP call control extensions.
下面是图13中消息F2的消息细节示例。根据响应，Alice的UA了解到URI是一个会议URI，并且响应的UA是支持多个SIP呼叫控制扩展的焦点。
The response details are as follows:
回应详情如下:
F2 SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKhjsas87
;received=192.0.2.4
To: <sip:3402934234@conf.example.com>;tag=93810874
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: refer, conference
Accept: application/sdp, message/sipfrag
Accept-Language: en
Supported: replaces, join, gruu
Content-Type: application/sdp
Content-Length: ...
F2 SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKhjsas87
;received=192.0.2.4
To: <sip:3402934234@conf.example.com>;tag=93810874
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:3402934234@conf.example.com>;isfocus
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: refer, conference
Accept: application/sdp, message/sipfrag
Accept-Language: en
Supported: replaces, join, gruu
Content-Type: application/sdp
Content-Length: ...
v=0
o=focus431 2890844563 2890842835 IN IP4 ms5.conf.example.com
s=-
i=Example Conference Hosted by Example.com
u=http://conf.example.com/3402934234
e=3402934234@conf-help.example.com
p=+18882934234
c=IN IP4 ms5.conf.example.com
t=0 0
m=audio 0 RTP/AVP 0 3 5 7
m=video 0 RTP/AVP 31 32
v=0
o=focus431 2890844563 2890842835 IN IP4 ms5.conf.example.com
s=-
i=Example Conference Hosted by Example.com
u=http://conf.example.com/3402934234
e=3402934234@conf-help.example.com
p=+18882934234
c=IN IP4 ms5.conf.example.com
t=0 0
m=audio 0 RTP/AVP 0 3 5 7
m=video 0 RTP/AVP 31 32
Useful information from each of these headers is detailed in the next sections.
下面几节将详细介绍这些标题中的有用信息。
Allow. The support of methods such as REFER, SUBSCRIBE, and NOTIFY indicates that the user agent supports call control and SIP events.
允许对引用、订阅和通知等方法的支持表明用户代理支持呼叫控制和SIP事件。
Accept. The support of bodies such as message/sipfrag [12] indicates support of call control.
接受消息/sipfrag[12]等主体的支持表示对呼叫控制的支持。
Allow-Events. Indicates support of event packages such as refer [4] and conference [9].
允许事件。表示支持事件包，如参考[4]和会议[9]。
Supported. Indicates support of extensions such as replaces, join, and gruu.
支持。表示支持诸如replaces、join和gruu等扩展。
Contact. The presence of the 'isfocus' feature parameter in the Contact header indicates that the URI is a conference URI and that the UA is a focus.
联系联系人标头中存在“isfocus”特性参数表示URI是会议URI，UA是焦点。
This specification defines the interaction between a focus UA and a participant UA in a conferencing application. As a result, the security considerations and mechanisms defined in RFC 3261 [2] apply. However, there are some aspects unique to conferencing that will be discussed here.
本规范定义了会议应用程序中焦点UA和参与者UA之间的交互。因此，RFC 3261[2]中定义的安全注意事项和机制适用。但是，这里将讨论一些会议特有的方面。
A conference often involves the use of substantial network bandwidth and computing resources. As a result, authentication is even more important than in a simple peer-to-peer session. As discussed in the conferencing framework [8], conferences often have policy related to conferencing resources. A focus SHOULD authenticate participants before joining them to a conference and allowing utilization of conferencing resources. Different policies can be applied by a focus to different participants based on the result of authentication.
会议通常涉及大量网络带宽和计算资源的使用。因此，身份验证比简单的对等会话更重要。正如会议框架[8]中所讨论的，会议通常具有与会议资源相关的策略。焦点应该在参与者加入会议并允许使用会议资源之前对他们进行身份验证。根据身份验证的结果，焦点可以将不同的策略应用于不同的参与者。
A participant will be interacting with a number of other participants through the focus. As a result, a participant should authenticate the focus and be sure that the focus used for the conference is trusted. Normal SIP authentication mechanisms are suitable for participant and focus authentication, such as SIP Digest utilizing a shared secret, or certificates, or a secured SIP identity mechanism. In addition, a focus SHOULD support Secure SIP connections so that hop-by-hop mutual authentication and confidentiality provided by TLS can be achieved.
一名参与者将通过focus与许多其他参与者进行互动。因此，参与者应该验证焦点，并确保用于会议的焦点是可信的。普通的SIP身份验证机制适用于参与者和焦点身份验证，例如利用共享秘密或证书的SIP摘要，或安全的SIP身份验证机制。此外，focus应支持安全SIP连接，以便实现TLS提供的逐跳相互认证和机密性。
In the SIP dialog between them, a focus utilizes the 'isfocus' feature tag to indicate that the UA is acting as a focus. As such, the SIP header fields such as Contact SHOULD have end to end integrity. A participant and focus SHOULD support an end-to-end integrity mechanism such as S/MIME.
在它们之间的SIP对话框中，焦点利用“isfocus”特性标记来指示UA作为焦点。因此，诸如Contact之类的SIP头字段应该具有端到端的完整性。参与者和焦点应该支持端到端的完整性机制，如S/MIME。
Once a participant has learned that the other UA is a focus, SIP call control operations (such as REFER) can be implemented, or a subscription to the conference package of the focus might be attempted. The security considerations described in RFC 3515 [4] apply to any REFER call control operations. A focus and participant will apply policy to determine which call control operations are allowed.
一旦参与者了解到另一UA是焦点，就可以实施SIP呼叫控制操作（例如REFER），或者可以尝试订阅焦点的会议包。RFC 3515[4]中描述的安全注意事项适用于任何REFER呼叫控制操作。焦点和参与者将应用策略来确定允许哪些呼叫控制操作。
A focus accepting subscriptions to the conference package must follow the security considerations in RFC 4575 [9]. Since notifications can carry sensitive information, the subscriptions should be authenticated and the notifications delivered with confidentiality and integrity protection. Since a participant is not able to authenticate other participants directly, a participant must rely on the focus to perform this authentication.
接受会议包订阅的焦点必须遵循RFC 4575[9]中的安全注意事项。由于通知可能携带敏感信息，因此订阅应经过身份验证，发送的通知应具有机密性和完整性保护。由于参与者无法直接对其他参与者进行身份验证，因此参与者必须依赖焦点来执行此身份验证。
A focus MUST support a participant's request for privacy, either through conference policy or as expressed through the signaling. For example, a participant joining a conference and including a Privacy header field [10] must not have identity information revealed to other participants by the focus. If other signaling protocols are used, privacy signaled through them also must be respected.
焦点必须支持参与者的隐私请求，无论是通过会议政策还是通过信号表达。例如，参加会议并包含隐私标题字段[10]的参与者不得有焦点向其他参与者透露的身份信息。如果使用其他信令协议，也必须尊重通过它们发送的隐私。
We would like to thank Rohan Mahy, Jonathan Rosenberg, Roni Even, Petri Koskelainen, Brian Rosen, Paul Kyzivat, Eric Burger, and others in list discussions.
我们要感谢Rohan Mahy、Jonathan Rosenberg、Roni Even、Petri Koskelainen、Brian Rosen、Paul Kyzivat、Eric Burger和列表讨论中的其他人。
Thanks to Miguel Garcia for his detailed last-call review and suggestions.
感谢Miguel Garcia对上次通话的详细回顾和建议。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] 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.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[3] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[4] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[5] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[6] Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了RFC 38912004年9月的“头”。
[7] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[7] Mahy，R.和D.Petrie，“会话启动协议（SIP）”加入“头”，RFC 3911，2004年10月。
[8] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[8] Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，2006年2月。
[9] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[9] Rosenberg，J.，Schulzrinne，H.，和O.Levin，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年8月。
[10] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[10] Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[11] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
[11] Campbell，B.和R.Sparks，“使用SIP请求URI控制服务上下文”，RFC3087，2001年4月。
[12] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[12] Sparks，R.，“互联网媒体类型信息/sipfrag”，RFC 3420，2002年11月。
[13] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.
[13] Johnston，A.，Donovan，S.，Sparks，R.，Cunningham，C.，和K.Summers，“会话发起协议（SIP）基本呼叫流示例”，BCP 75，RFC 3665，2003年12月。
[14] Levin, O. and R. Even, "High Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005.
[14] Levin，O.和R.Even，“紧密耦合SIP会议的高级别要求”，RFC 42452005年11月。
[15] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, February 2005.
[15] Mahy，R.，“会话启动协议（SIP）的呼叫控制和多方使用框架”，正在进行的工作，2005年2月。
[16] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, February 2005.
[16] Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理（UA）URI（GRUU）”，正在进行的工作，2005年2月。
[17] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol Call Control - Transfer", Work in Progress, April 2005.
[17] Sparks，R.，Johnston，A.，和D.Petrie，“会话启动协议呼叫控制-传输”，正在进行的工作，2005年4月。
[18] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[18] Rosenberg，J.，Schulzrinne，H.，和R.Mahy，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 42352005年11月。
Appendix A: Creating a Conference by a Conference-Unaware UA
附录A：通过会议创建会议
This section discusses how a human user operating a conference-unaware UA can create and add participants to a conference. This method is described as an appendix since it is NOT RECOMMENDED. The scenarios involving creating a conference using ad-hoc or manual means are recommended over this scenario. This scenario is included, however, for completeness.
本节讨论操作会议的人工用户如何创建和向会议添加参与者。本方法作为附录进行说明，因为不推荐使用。在此场景中，推荐使用临时或手动方式创建会议的场景。但是，为了完整性，包含了此场景。
A user (human) would choose a conference URI according to system rules and insert it into the Request-URI of the INVITE. This same URI is echoed by a focus adhering to certain addressing conventions (discussed below) in the Contact header by the focus. Additional participants could be added by non-SIP means (publication of the chosen conference URI using web pages, email, IM, etc.). Alternatively, the conference-unaware UA could then add other participants to the conference using SIP call control by establishing a session with them, then transferring [17] them to the conference URI. Note that in this scenario only the user (human) is aware of the conferencing application, and the conference-unaware UA only need support RFC 3261 [2] and optionally call transfer.
用户（人类）将根据系统规则选择会议URI，并将其插入到邀请的请求URI中。焦点在联系人头中遵循某些寻址约定（如下所述）的焦点会响应相同的URI。可以通过非SIP方式添加其他参与者（使用网页、电子邮件、IM等发布选定的会议URI）。或者，会议UA可以使用SIP呼叫控制将其他参与者添加到会议中，方法是与他们建立会话，然后将[17]他们传输到会议URI。请注意，在此场景中，只有用户（人类）知道会议应用程序，而不知道会议的UA只需要支持RFC 3261[2]和可选的呼叫转移。
Making this work does impose certain addressing conventions on a system. As a service/implementation choice, a system could allow the creator of the conference to choose the user portion of the conference URI. However, this requires the URI format to be agreed upon between a user and the system.
使这项工作在系统上实施某些寻址约定。作为服务/实现选择，系统可以允许会议的创建者选择会议URI的用户部分。但是，这需要用户和系统之间商定URI格式。
For example, a service provider might reserve the domain conf.example.com for all conference URIs. Any URI in the domain of conf.example.com would resolve to the focus. The focus could be configured to interpret an unknown user part in the conf.example.com domain as a request for a conference to be created with the conference URI as the Request-URI. For example, an INVITE sent with a Request-URI of sip:k32934208ds72@conf.example.com could be routed to the focus that would then create the conference. This conference URI should be registered by the newly created focus to become routable as a conference URI within the conf.example.com domain. The returned Contact would look as follows:
例如，服务提供商可能会为所有会议URI保留域conf.example.com。conf.example.com域中的任何URI都将解析为焦点。焦点可以配置为将conf.example.com域中的未知用户部分解释为会议请求，以会议URI作为请求URI创建会议。例如，使用sip的请求URI发送的INVITE：k32934208ds72@conf.example.com可以路由到焦点，然后创建会议。新创建的focus应注册此会议URI，以便在conf.example.com域中作为会议URI进行路由。返回的联系人如下所示：
Contact: <sip:k32934208ds72@conf.example.com>;isfocus
Contact: <sip:k32934208ds72@conf.example.com>;isfocus
Note, however, that this approach relies on conventions adopted between the user (human) and the focus. Also, the approach is not robust against collisions in the conference names. If a second user wishing to create a new conference happened to choose the same user part as an existing conference, the result would be that the second user would be added into the existing conference instead of creating a new one.
但是，请注意，这种方法依赖于用户（人员）和焦点之间采用的约定。此外，该方法对会议名称中的冲突也不具有鲁棒性。如果希望创建新会议的第二个用户碰巧选择了与现有会议相同的用户部分，则结果将是将第二个用户添加到现有会议中，而不是创建新会议。
As a result, methods of conference creation in which the conference URI is an opaque URI generated by the focus are preferred.
结果，优选其中会议URI是由焦点生成的不透明URI的会议创建方法。
An example call flow is shown in Figure 14. The participant Alice creates the conference URI (using some convention agreed to with the focus domain) and sends an INVITE to that URI which creates the focus. The focus creates the conference and returns the same conference URI in the 200 OK answer to the INVITE (which is ignored by the conference-unaware UA).
图14显示了一个示例调用流。参与者Alice创建会议URI（使用与焦点域商定的某种约定），并向创建焦点的URI发送邀请。focus创建会议，并在200 OK答案中返回相同的会议URI（该URI被会议忽略）。
Alice Focus Bob Carol
| | | |
| Alice creates the conference and chooses the conference URI. |
| | | |
| INVITE sip:Conf-ID F1 | |
|------------------->| | |
| 180 Ringing F2 | | |
|<-------------------| | |
| 200 OK Contact:Conf-ID;isfocus F3 | |
|<-------------------| | |
| ACK F4 | | |
|------------------->| | |
| RTP | | |
|<==================>| | |
Alice Focus Bob Carol
| | | |
| Alice creates the conference and chooses the conference URI. |
| | | |
| INVITE sip:Conf-ID F1 | |
|------------------->| | |
| 180 Ringing F2 | | |
|<-------------------| | |
| 200 OK Contact:Conf-ID;isfocus F3 | |
|<-------------------| | |
| ACK F4 | | |
|------------------->| | |
| RTP | | |
|<==================>| | |
Figure 14. Not Recommended: Conferencing Unaware Participant Creates a Conference
图14。不推荐：会议参与者创建会议
Authors' Addresses
作者地址
Alan Johnston Avaya St. Louis, MO 63102
密苏里州圣路易斯市艾伦·约翰斯顿·阿瓦亚63102
EMail: alan@sipstation.com
EMail: alan@sipstation.com
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052
奥利特·莱文微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: oritl@microsoft.com
EMail: oritl@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the 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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。