Network Working Group J. Rosenberg
Request for Comments: 4353 Cisco Systems
Category: Informational February 2006
Network Working Group J. Rosenberg
Request for Comments: 4353 Cisco Systems
Category: Informational February 2006
A Framework for Conferencing with the Session Initiation Protocol (SIP)
使用会话启动协议（SIP）的会议框架
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing.
会话发起协议（SIP）支持在用户代理之间发起、修改和终止媒体会话。这些会话由SIP对话框管理，该对话框表示一对用户代理之间的SIP关系。由于对话是在成对的用户代理之间进行的，因此SIP用于双方通信（如电话呼叫）是显而易见的。与多个参与者的交流会议（通常称为会议）更为复杂。本文档定义了如何进行此类会议的框架。该框架描述了多方会议所需的总体架构、术语和协议组件。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview of Conferencing Architecture ...........................6
3.1. Usage of URIs ..............................................9
4. Functions of the Elements ......................................10
4.1. Focus .....................................................10
4.2. Conference Policy Server ..................................11
4.3. Mixers ....................................................11
4.4. Conference Notification Service ...........................12
4.5. Participants ..............................................13
4.6. Conference Policy .........................................13
5. Common Operations ..............................................13
5.1. Creating Conferences ......................................13
5.2. Adding Participants .......................................14
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview of Conferencing Architecture ...........................6
3.1. Usage of URIs ..............................................9
4. Functions of the Elements ......................................10
4.1. Focus .....................................................10
4.2. Conference Policy Server ..................................11
4.3. Mixers ....................................................11
4.4. Conference Notification Service ...........................12
4.5. Participants ..............................................13
4.6. Conference Policy .........................................13
5. Common Operations ..............................................13
5.1. Creating Conferences ......................................13
5.2. Adding Participants .......................................14
5.3. Removing Participants .....................................15
5.4. Destroying Conferences ....................................15
5.5. Obtaining Membership Information ..........................16
5.6. Adding and Removing Media .................................16
5.7. Conference Announcements and Recordings ...................16
6. Physical Realization ...........................................18
6.1. Centralized Server ........................................18
6.2. Endpoint Server ...........................................19
6.3. Media Server Component ....................................21
6.4. Distributed Mixing ........................................22
6.5. Cascaded Mixers ...........................................24
7. Security Considerations ........................................26
8. Contributors ...................................................26
9. Acknowledgements ...............................................26
10. Informative References ........................................27
5.3. Removing Participants .....................................15
5.4. Destroying Conferences ....................................15
5.5. Obtaining Membership Information ..........................16
5.6. Adding and Removing Media .................................16
5.7. Conference Announcements and Recordings ...................16
6. Physical Realization ...........................................18
6.1. Centralized Server ........................................18
6.2. Endpoint Server ...........................................19
6.3. Media Server Component ....................................21
6.4. Distributed Mixing ........................................22
6.5. Cascaded Mixers ...........................................24
7. Security Considerations ........................................26
8. Contributors ...................................................26
9. Acknowledgements ...............................................26
10. Informative References ........................................27
The Session Initiation Protocol (SIP) [1] supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, however, are more complicated. SIP can support many models of multi-party communications. One, referred to as loosely coupled conferences, makes use of multicast media groups. In the loosely coupled model, there is no signaling relationship between participants in the conference. There is no central point of control or conference server. Participation is gradually learned through control information that is passed as part of the conference (using the Real Time Control Protocol (RTCP) [2], for example). Loosely coupled conferences are easily supported in SIP by using multicast addresses within its session descriptions.
会话发起协议（SIP）[1]支持在用户代理之间发起、修改和终止媒体会话。这些会话由SIP对话框管理，该对话框表示一对用户代理之间的SIP关系。由于对话是在成对的用户代理之间进行的，因此SIP用于双方通信（如电话呼叫）是显而易见的。然而，与多个参与者的交流会更为复杂。SIP可以支持多种模式的多方通信。其中一个被称为松散耦合会议，使用多播媒体组。在松散耦合模型中，会议参与者之间不存在信号传递关系。没有中央控制点或会议服务器。通过作为会议一部分传递的控制信息（例如，使用实时控制协议（RTCP）[2]）逐渐了解参与情况。通过在会话描述中使用多播地址，SIP很容易支持松散耦合的会议。
In another model, referred to as fully distributed multiparty conferencing, each participant maintains a signaling relationship with the other participants, using SIP. There is no central point of control; it is completely distributed amongst the participants. This model is outside the scope of this document.
在另一个模型中，称为完全分布式多方会议，每个参与者使用SIP和其他参与者保持信令关系。没有中央控制点；它完全分布在参与者之间。此模型不在本文档的范围内。
In another model, sometimes referred to as the tightly coupled conference, there is a central point of control. Each participant connects to this central point. It provides a variety of conference functions, and may possibly perform media mixing functions as well. Tightly coupled conferences are not directly addressed by RFC 3261, although basic participation is possible without any additional protocol support.
在另一个模型中，有时称为紧耦合会议，有一个控制中心点。每个参与者都连接到这个中心点。它提供多种会议功能，也可能执行媒体混合功能。紧密耦合的会议不直接由RFC 3261解决，尽管基本参与是可能的，无需任何附加协议支持。
This document presents the overall framework for tightly coupled SIP conferencing, referred to simply as "conferencing" from this point forward. This framework presents a general architectural model for these conferences and presents terminology used to discuss such conferences. It also discusses the ways in which SIP itself is involved in conferencing. The aim of the framework is to meet the general requirements for conferencing that are outlined in [3]. This specification alludes to non-SIP-specific mechanisms for achieving several conferencing functions. Those mechanisms are outside the scope of this specification.
本文档介绍了紧密耦合SIP会议的总体框架，从现在起简称为“会议”。该框架为这些会议提供了一个通用的体系结构模型，并提供了用于讨论此类会议的术语。它还讨论了SIP本身参与会议的方式。该框架的目的是满足[3]中概述的会议的一般要求。本规范提及用于实现多个会议功能的非SIP特定机制。这些机制不在本规范的范围内。
Conference: Conference is an overused term, which has different meanings in different contexts. In SIP, a conference is an instance of a multi-party conversation. Within the context of this specification, a conference is always a tightly coupled conference.
会议：会议是一个被滥用的术语，在不同的语境中有不同的含义。在SIP中，会议是多方对话的一个实例。在本规范的上下文中，会议始终是紧密耦合的会议。
Loosely Coupled Conference: A loosely coupled conference is a conference without coordinated signaling relationships amongst participants. Loosely coupled conferences frequently use multicast for distribution of conference memberships.
松散耦合会议：松散耦合会议是参与者之间没有协调的信令关系的会议。松散耦合的会议经常使用多播来分发会议成员资格。
Tightly Coupled Conference: A tightly coupled conference is a conference in which a single user agent, referred to as a focus, maintains a dialog with each participant. The focus plays the role of the centralized manager of the conference, and is addressed by a conference URI.
紧密耦合会议：紧密耦合会议是一种会议，其中单个用户代理（称为焦点）与每个参与者保持对话。焦点扮演会议集中管理者的角色，并由会议URI处理。
Focus: The focus is a SIP user agent that is addressed by a conference URI and identifies a conference (recall that a conference is a unique instance of a multi-party conversation). The focus maintains a SIP signaling relationship with each participant in the conference. The focus is responsible for ensuring, in some way, that each participant receives the media that make up the conference. The focus also implements conference policies. The focus is a logical role.
焦点：焦点是一个SIP用户代理，由会议URI寻址并标识一个会议（回想一下，会议是多方对话的唯一实例）。focus与会议中的每个参与者保持SIP信令关系。focus负责在某种程度上确保每位与会者都能收到组成会议的媒体。该中心还实施会议政策。重点是逻辑角色。
Conference URI: A URI, usually a SIP URI, that identifies the focus of a conference.
会议URI：标识会议焦点的URI，通常是SIPURI。
Participant: The software element that connects a user or automata to a conference. It implements, at a minimum, a SIP user agent, but may also implement non-SIP-specific mechanisms for additional functionality.
参与者：将用户或自动机连接到会议的软件元素。它至少实现一个SIP用户代理，但也可以实现非SIP特定的机制来实现附加功能。
Conference State: The state of the conference includes the state of the focus, the set of participants connected to the conference, and the state of their respective dialogs.
会议状态：会议状态包括焦点状态、连接到会议的参与者集及其各自对话框的状态。
Conference Notification Service: A conference notification service is a logical function provided by the focus. The focus can act as a notifier [4], accepting subscriptions to the conference state, and notifying subscribers about changes to that state.
会议通知服务：会议通知服务是focus提供的逻辑功能。焦点可以充当通知程序[4]，接受对会议状态的订阅，并将该状态的更改通知订阅者。
Conference Policy Server: A conference policy server is a logical function that can store and manipulate the conference policy. This logical function is not specific to SIP, and may not physically exist. It refers to the component that interfaces a protocol to the conference policy.
会议策略服务器：会议策略服务器是可以存储和操作会议策略的逻辑功能。此逻辑功能不是特定于SIP的，并且可能在物理上不存在。它是指将协议连接到会议策略的组件。
Conference Policy: The complete set of rules governing a particular conference.
会议政策：管理特定会议的一整套规则。
Mixer: A mixer receives a set of media streams of the same type, and combines their media in a type-specific manner, redistributing the result to each participant. This includes media transported using RTP [2]. As a result, the term defined here is a superset of the mixer concept defined in RFC 3550, since it allows for non-RTP-based media such as instant messaging sessions [5].
混合器：混合器接收一组相同类型的媒体流，并以特定类型的方式组合媒体，将结果重新分发给每个参与者。这包括使用RTP传输的介质[2]。因此，此处定义的术语是RFC 3550中定义的混音器概念的超集，因为它允许非RTP媒体，如即时消息会话[5]。
Conference-Unaware Participant: A conference-unaware participant is a participant in a conference that is not aware that it is actually in a conference. As far as the UA is concerned, it is a point-to-point call.
不知道会议的参与者：不知道会议的参与者是不知道自己实际在会议中的会议参与者。就UA而言，这是一个点对点呼叫。
Cascaded Conferencing: A mechanism for group communications in which a set of conferences are linked by having their focuses interact in some fashion.
级联会议：一种群体交流机制，其中一组会议通过其焦点以某种方式进行交互而相互联系。
Simplex Cascaded Conferences: a group of conferences that are linked such that the user agent that represents the focus of one conference is a conference-unaware participant in another conference.
单纯形级联会议：一组相互链接的会议，以使代表一个会议焦点的用户代理是另一个会议中的一个不知道会议的参与者。
Conference-Aware Participant: A conference-aware participant is a participant in a conference that has learned, through automated means, that it is in a conference. A conference-aware participant can use the conference notification service or additional non-SIP-specific mechanisms for additional functionality.
会议感知参与者：会议感知参与者是指通过自动方式了解自己在会议中的会议参与者。会议感知参与者可以使用会议通知服务或其他非SIP特定机制来实现其他功能。
Conference Server: A conference server is a physical server that contains, at a minimum, the focus. It may also include a conference policy server and mixers.
会议服务器：会议服务器是至少包含焦点的物理服务器。它还可能包括会议策略服务器和混音器。
Mass Invitation: An attempt to add a large number of users into a conference.
大规模邀请：试图将大量用户添加到会议中。
Mass Ejection: An attempt to remove a large number of users from a conference.
从大会中排除大量用户的企图。
Sidebar: A sidebar appears to the users within the sidebar as a "conference within the conference". It is a conversation amongst a subset of the participants to which the remaining participants are not privy.
侧栏：侧栏中的侧栏对用户显示为“会议中的会议”。这是一种参与者子集之间的对话，其余参与者并不知情。
Anonymous Participant: An anonymous participant is one that is known to other participants through the conference notification service, but whose identity is being withheld.
匿名参与者：匿名参与者是指通过会议通知服务为其他参与者所知，但其身份被保留的参与者。
+-----------+
| |
| |
|Participant|
| 4 |
| |
+-----------+
|
|SIP
|Dialog
|4
|
+-----------+ +-----------+ +-----------+
| | | | | |
| | | | | |
|Participant|-----------| Focus |------------|Participant|
| 1 | SIP | | SIP | 3 |
| | Dialog | | Dialog | |
+-----------+ 1 +-----------+ 3 +-----------+
|
|
|SIP
|Dialog
|2
|
+-----------+
| |
| |
|Participant|
| 2 |
| |
+-----------+
+-----------+
| |
| |
|Participant|
| 4 |
| |
+-----------+
|
|SIP
|Dialog
|4
|
+-----------+ +-----------+ +-----------+
| | | | | |
| | | | | |
|Participant|-----------| Focus |------------|Participant|
| 1 | SIP | | SIP | 3 |
| | Dialog | | Dialog | |
+-----------+ 1 +-----------+ 3 +-----------+
|
|
|SIP
|Dialog
|2
|
+-----------+
| |
| |
|Participant|
| 2 |
| |
+-----------+
Figure 1
图1
The central component (literally) in a SIP conference is the focus. The focus maintains a SIP signaling relationship with each participant in the conference. The result is a star topology, as shown in Figure 1.
SIP会议的中心部分（字面上）是焦点。focus与会议中的每个参与者保持SIP信令关系。结果是一个星形拓扑，如图1所示。
The focus is responsible for making sure that the media streams that constitute the conference are available to the participants in the conference. It does that through the use of one or more mixers, each of which combines a number of input media streams to produce one or more output media streams. The focus uses the media policy to determine the proper configuration of the mixers.
focus负责确保会议参与者可以使用构成会议的媒体流。它通过使用一个或多个混频器来实现这一点，每个混频器组合多个输入媒体流以产生一个或多个输出媒体流。焦点使用媒体策略来确定混频器的正确配置。
The focus has access to the conference policy, an instance of which exists for each conference. Effectively, the conference policy can be thought of as a database that describes the way that the conference should operate. It is the responsibility of the focus to enforce those policies. Not only does the focus need read access to the database, but it needs to know when it has changed. Such changes might result in SIP signaling (for example, the ejection of a user from the conference using BYE), and those changes that affect the conference state will require a notification to be sent to subscribers using the conference notification service.
focus可以访问会议策略，每个会议都有一个该策略的实例。实际上，会议策略可以看作是一个描述会议运行方式的数据库。执行这些政策是焦点的责任。焦点不仅需要对数据库进行读取访问，还需要知道它何时发生了更改。此类更改可能导致SIP信令（例如，使用BYE将用户从会议中驱逐），并且影响会议状态的那些更改将要求使用会议通知服务向订户发送通知。
The conference is represented by a URI that identifies the focus. Each conference has a unique focus and a unique URI identifying that focus. Requests to the conference URI are routed to the focus for that specific conference.
会议由标识焦点的URI表示。每个会议都有一个唯一的焦点和一个标识该焦点的唯一URI。对会议URI的请求被路由到该特定会议的焦点。
Users usually join the conference by sending an INVITE to the conference URI. As long as the conference policy allows, the INVITE is accepted by the focus and the user is brought into the conference. Users can leave the conference by sending a BYE, as they would in a normal call.
用户通常通过向会议URI发送邀请来加入会议。只要会议策略允许，焦点就会接受邀请，并将用户带入会议。用户可以像在正常通话中一样，通过发送“再见”离开会议。
Similarly, the focus can terminate a dialog with a participant, should the conference policy change to indicate that the participant is no longer allowed in the conference. A focus can also initiate an INVITE to bring a participant into the conference.
类似地，如果会议策略发生变化，表明不再允许参与者参加会议，则焦点可以终止与参与者的对话。焦点还可以发起邀请，邀请参与者参加会议。
The notion of a conference-unaware participant is important in this framework. A conference-unaware participant does not even know that the UA it is communicating with happens to be a focus. As far as it's concerned, the UA appears like any other UA. The focus, of course, knows that it's a focus, and it performs the tasks needed for the conference to operate.
会议参与者的概念在这一框架中很重要。没有意识到会议的参与者甚至不知道与之通信的UA恰好是一个焦点。就其而言，UA与其他UA一样。当然，焦点知道这是一个焦点，它执行会议运作所需的任务。
Conference-unaware participants have access to a good deal of functionality. They can join and leave conferences using SIP, and obtain more advanced features through stimulus signaling, as discussed in [6]. However, if the participant wishes to explicitly control aspects of the conference using functional signaling protocols, the participant must be conference-aware.
会议参与者可以使用大量功能。他们可以使用SIP加入和离开会议，并通过刺激信号获得更高级的功能，如[6]中所述。然而，如果参与者希望使用功能信令协议显式地控制会议的各个方面，那么参与者必须是会议感知的。
.....................................
. .
. .
. .
. .
. .
. .
. .
. +-----------+ //-----\\ .
. | | || || .
non-SIP . | Conference| \\-----// .
+---------------->| Policy | | | .
| . | Server |----> | | .
| . | | |Conference| .
| . +-----------+ | Policy | .
| . | | .
| . | | .
+-----------+ . +-----------+ | | .
| | . | | \ // .
| | . | | \-----/ .
|Participant|<--------->| Focus | | .
| | SIP . | | | .
| | Dialog . | |<-----------+ .
+-----------+ . |...........| .
^ . | Conference| .
| . |Notification .
+------------>| Service | .
Subscription. +-----------+ .
. .
. .
. .
. .
.....................................
.....................................
. .
. .
. .
. .
. .
. .
. .
. +-----------+ //-----\\ .
. | | || || .
non-SIP . | Conference| \\-----// .
+---------------->| Policy | | | .
| . | Server |----> | | .
| . | | |Conference| .
| . +-----------+ | Policy | .
| . | | .
| . | | .
+-----------+ . +-----------+ | | .
| | . | | \ // .
| | . | | \-----/ .
|Participant|<--------->| Focus | | .
| | SIP . | | | .
| | Dialog . | |<-----------+ .
+-----------+ . |...........| .
^ . | Conference| .
| . |Notification .
+------------>| Service | .
Subscription. +-----------+ .
. .
. .
. .
. .
.....................................
Conference Functions
会议职能
Figure 2
图2
A conference-aware participant is one that has access to advanced functionality through additional protocol interfaces, which may include access to the conference policy through non-SIP-specific mechanisms. A model for this interaction is shown in Figure 2. The participant can interact with the focus using extensions, such as REFER, in order to access enhanced call control functions [7]. The participant can SUBSCRIBE to the conference URI, and be connected to the conference notification service provided by the focus. Through this mechanism, it can learn about changes in participants - effectively, the state of the dialogs and the media.
会议感知参与者是通过附加协议接口访问高级功能的参与者，附加协议接口可能包括通过非SIP特定机制访问会议策略。图2显示了这种交互作用的模型。参与者可以使用扩展（如REFER）与焦点交互，以访问增强的呼叫控制功能[7]。参与者可以订阅会议URI，并连接到focus提供的会议通知服务。通过对话，参与者可以有效地了解媒体的状态变化。
The participant can communicate with the conference policy server using some kind of non-SIP-specific mechanism by which it can affect the conference policy. The conference policy server need not be available in any particular conference, although there is always a conference policy.
参与者可以使用某种非SIP特定的机制与会议策略服务器通信，通过这种机制参与者可以影响会议策略。会议策略服务器不需要在任何特定会议中可用，尽管始终存在会议策略。
The interfaces between the focus and the conference policy, and between the conference policy server and the conference policy are non-SIP-specific. For the purposes of SIP-based conferencing, they serve as logical roles involved in a conference, as opposed to representing a physical decomposition. The separation of these functions is documented here to encourage clarity in the requirements. This approach provides individual SIP implementations the flexibility to compose a conferencing system in a scalable and robust manner without requiring the complete development of these interfaces.
焦点和会议策略之间以及会议策略服务器和会议策略之间的接口不是特定于SIP的。对于基于SIP的会议，它们充当会议中涉及的逻辑角色，而不是表示物理分解。此处记录了这些功能的分离，以促进需求的清晰。这种方法为单个SIP实现提供了灵活性，可以以可扩展和健壮的方式组成会议系统，而无需完全开发这些接口。
It is fundamental to this framework that a conference is uniquely identified by a URI, and that this URI identifies the focus that is responsible for the conference. The conference URI is unique, such that no two conferences have the same conference URI. A conference URI is always a SIP or SIPS URI.
对于这个框架来说，一个会议是由一个URI唯一标识的，并且这个URI标识负责会议的焦点是非常重要的。会议URI是唯一的，因此没有两个会议具有相同的会议URI。会议URI始终是SIP或SIPS URI。
The conference URI is opaque to any participants that might use it. There is no way to look at the URI and know for certain whether it identifies a focus, as opposed to a user or an interface on a PSTN gateway. This is in line with the general philosophy of URI usage [8]. However, contextual information surrounding the URI (for example, SIP header parameters) may indicate that the URI represents a conference.
会议URI对可能使用它的任何参与者都是不透明的。无法查看URI并确定它是否标识了焦点，而不是PSTN网关上的用户或接口。这符合URI使用的一般原则[8]。然而，围绕URI的上下文信息（例如，SIP报头参数）可以指示URI表示会议。
When a SIP request is sent to the conference URI, that request is routed to the focus, and only to the focus. The element or system that creates the conference URI is responsible for guaranteeing this property.
当SIP请求被发送到会议URI时，该请求被路由到焦点，并且仅路由到焦点。创建会议URI的元素或系统负责保证此属性。
The conference URI can represent a long-lived conference or interest group, such as "sip:discussion-on-dogs@example.com". The focus identified by this URI would always exist, and always be managing the conference for whatever participants are currently joined. Other conference URIs can represent short-lived conferences, such as an ad-hoc conference.
会议URI可以表示长期存在的会议或兴趣组，例如“sip:discussion on”-dogs@example.com". 此URI确定的焦点将始终存在，并且始终为当前加入的任何参与者管理会议。其他会议URI可以表示短期会议，例如临时会议。
Ideally, a conference URI is never constructed or guessed by a user. Rather, conference URIs are learned through many mechanisms. A conference URI can be emailed or sent in an instant message. A conference URI can be linked on a web page. A conference URI can also be obtained from some non-SIP mechanism.
理想情况下，用户永远不会构造或猜测会议URI。相反，会议URI是通过许多机制学习的。会议URI可以通过电子邮件发送或通过即时消息发送。会议URI可以链接到网页上。还可以从一些非SIP机制获取会议URI。
To determine that a SIP URI does represent a focus, standard techniques for URI capability discovery can be used. Specifically, the callee capabilities specification [9] provides the "isfocus" feature tag to indicate that the UA is acting as focus in this dialog. Callee capability parameters are also used to indicate that a focus supports the conference notification service. This is done by declaring support for the SUBSCRIBE method and the relevant package(s) in the caller preferences feature parameters associated with the conference URI.
要确定SIPURI确实代表焦点，可以使用URI功能发现的标准技术。具体而言，被叫方能力规范[9]提供了“isfocus”功能标签，以指示UA在该对话框中充当焦点。被叫方能力参数还用于指示焦点支持会议通知服务。这是通过在与会议URI关联的调用者首选项功能参数中声明对SUBSCRIBE方法和相关包的支持来实现的。
Other functions in a conference may be represented by URIs. If the conference policy is exposed through a web application, it is identified by an HTTP URI. If it is accessed using an explicit protocol, it is a URI defined for that protocol.
会议中的其他功能可以由URI表示。如果会议策略通过web应用程序公开，则由HTTP URI标识。如果使用显式协议访问它，则它是为该协议定义的URI。
Starting with the conference URI, the URIs for the other logical entities in the conference can be learned using the conference notification service.
从会议URI开始，可以使用会议通知服务了解会议中其他逻辑实体的URI。
This section gives a more detailed description of the functions typically implemented in each of the elements.
本节对每个元素中通常实现的功能进行了更详细的描述。
As its name implies, the focus is the center of the conference. All participants in the conference are connected to it by a SIP dialog. The focus is responsible for maintaining the dialogs connected to it. It ensures that the dialogs are connected to a set of participants who are allowed to participate in the conference, as defined by the membership policy. The focus also uses SIP to manipulate the media sessions, in order to make sure each participant obtains all the media for the conference. To do that, the focus makes use of mixers.
顾名思义，焦点是会议的中心。会议的所有参与者都通过SIP对话框连接到它。焦点负责维护与其连接的对话框。它确保对话框连接到一组允许参加会议的参与者，如成员资格政策所定义。focus还使用SIP操纵媒体会话，以确保每个参与者获得会议的所有媒体。为了做到这一点，focus使用了混合器。
When a focus receives an INVITE, it checks the conference policy. The policy might indicate that this participant is not allowed to join, in which case the call can be rejected. It might indicate that another participant, acting as a moderator, needs to approve this new participant. In that case, the INVITE might be parked on a music-on-hold server, or a 183 response might be sent to indicate progress. A notification, using the conference notification service, would be sent to the moderator. The moderator could then allow this new participant to join, and the focus could then accept the INVITE (or unpark it from the music-on-hold server). The interpretation of policy by the focus is, itself, a matter of local policy, and not subject to standardization.
当焦点收到邀请时，它会检查会议策略。策略可能指示不允许此参与者加入，在这种情况下，呼叫可能会被拒绝。它可能表示另一个参与者作为主持人需要批准此新参与者。在这种情况下，INVITE可能停在music on hold服务器上，或者发送183响应以指示进度。将使用会议通知服务向主持人发送通知。然后，主持人可以允许这个新参与者加入，然后焦点可以接受邀请（或者从音乐保留服务器上取消邀请）。焦点对政策的解释本身是一个地方政策问题，不受标准化的约束。
When it is necessary to remove a SIP participant (with a confirmed dialog) from a conference, the focus would send a BYE to that participant to remove the participant. This is often referred to as "ejecting" a user from the conference, and is called "mass ejection" when done for many users. Similarly, if it is necessary to add a new SIP participant to a conference, the focus would send an INVITE request to that participant. When done for a large number of users, this is called mass invitation. Finally, if it is necessary to change the properties of the media of a session (for example to remove video) for a SIP participant, the focus can update the session description for that participant by sending a re-INVITE or UPDATE [15] request with a new offer to that participant.
当需要从会议中删除SIP参与者（带有已确认的对话）时，焦点将向该参与者发送再见以删除该参与者。这通常被称为将用户从会议中“驱逐”，对于许多用户来说，这被称为“大规模驱逐”。类似地，如果需要将新的SIP参与者添加到会议中，focus将向该参与者发送INVITE请求。当对大量用户执行此操作时，称为批量邀请。最后，如果需要为SIP参与者改变会话的媒体的属性（例如移除视频），则焦点可以通过向该参与者发送带有新要约的重新邀请或更新[15]请求来更新该参与者的会话描述。
In many cases, the signaling actions performed by the focus, such as ejection or addition of a participant, will change the media composition of the conference. To affect these changes, the focus interacts with the mixer. Through that interaction, it makes sure that all valid participants received a copy of the media streams, and that each participant sends media to an IP address and port on the mixer that cause it to be appropriately mixed with the other media in the conference. The means by which the focus interacts with the mixer are outside the scope of this specification.
在许多情况下，焦点执行的信号动作，例如取消或增加参与者，将改变会议的媒体组成。要影响这些更改，焦点将与混合器交互。通过该交互，它确保所有有效参与者收到媒体流的副本，并且每个参与者将媒体发送到混合器上的IP地址和端口，从而使其与会议中的其他媒体适当混合。焦点与混合器交互的方式不在本规范的范围内。
The conference policy server is a logical component of the system. It represents the interface between clients and the conference policy that governs the operation of the conference. Clients communicate with the conference policy server using a non-SIP-specific mechanism.
会议策略服务器是系统的逻辑组件。它表示客户端和控制会议操作的会议策略之间的接口。客户端使用非SIP特定机制与会议策略服务器通信。
A mixer is responsible for combining the media streams that make up the conference, and generating one or more output streams that are distributed to recipients (which could be participants or other
混合器负责组合组成会议的媒体流，并生成一个或多个分发给接收者（可能是参与者或其他人）的输出流
mixers). The process of combining media is specific to the media type, and is directed by the focus, under the guidance of the rules described in the media policy.
搅拌机）。组合媒体的过程特定于媒体类型，并由焦点在媒体策略中描述的规则指导下进行。
A mixer is not aware of a "conference" as an entity, per se. A mixer receives media streams as inputs, and based on directions provided by the focus, generates media streams as outputs. There is no grouping of media streams beyond the policies that describe the ways in which the streams are mixed.
混音器本身并不知道“会议”是一个实体。混合器接收媒体流作为输入，并基于焦点提供的方向，生成媒体流作为输出。除了描述流混合方式的策略之外，没有媒体流分组。
A mixer is always under the control of a focus, either directly or indirectly. The focus is responsible for interpreting the media policy, and then installing the appropriate rules in the mixer. If the focus is directly controlling a mixer, the mixer can either be co-resident with the focus, or can be controlled through some kind of protocol. If the focus is indirectly controlling a mixer, it delegates the mixing to the participants, each of which has its own mixer. This is described in Section 6.4.
混音器总是直接或间接地受焦点控制。focus负责解释媒体策略，然后在混合器中安装适当的规则。如果焦点直接控制混合器，则混合器可以与焦点共存，也可以通过某种协议进行控制。如果焦点间接控制混音器，它会将混音委托给参与者，每个参与者都有自己的混音器。第6.4节对此进行了说明。
The focus can provide a conference notification service. In this role, it acts as a notifier, as defined in RFC 3265 [4]. It accepts subscriptions from clients for the conference URI, and generates notifications to them as the state of the conference changes.
focus可以提供会议通知服务。在这个角色中，它充当RFC 3265[4]中定义的通知程序。它接受客户端对会议URI的订阅，并在会议状态更改时向客户端生成通知。
The state of the conference includes the participants connected to the focus, and also information about the dialogs associated with them. As new participants join, this state changes, and is reported through the notification service. Similarly, when someone leaves, this state also changes, allowing subscribers to learn about this fact.
会议状态包括与焦点相关的参与者，以及与他们相关的对话信息。当新参与者加入时，此状态会发生变化，并通过通知服务进行报告。类似地，当有人离开时，这种状态也会改变，从而允许订阅者了解这一事实。
If a participant is anonymous, the conference notification service will either withhold the identity of a new participant from other conference participants, or will neglect to inform other conference participants about the presence of the anonymous participant. The choice of approach depends on the level of anonymity provided to the anonymous participant.
如果参与者是匿名的，会议通知服务将向其他会议参与者隐瞒新参与者的身份，或者忽略通知其他会议参与者匿名参与者的存在。方法的选择取决于提供给匿名参与者的匿名级别。
A participant in a conference is any SIP user agent that has a dialog with the focus. This SIP user agent can be a PC application, a SIP hardphone, or a PSTN gateway. It can also be another focus. A conference that has a participant that is the focus of another conference is called a simplex cascaded conference. They can also be used to provide scalable conferences where there are regional sub-conferences, each of which is connected to the main conference.
会议的参与者是具有焦点对话的任何SIP用户代理。此SIP用户代理可以是PC应用程序、SIP硬电话或PSTN网关。它也可以是另一个焦点。有一个参与者作为另一个会议的焦点的会议称为单纯形级联会议。它们还可以用于提供可扩展的会议，其中有区域子会议，每个子会议都连接到主会议。
The conference policy contains the rules that guide the operation of the focus. The rules can be simple, such as an access list that defines the set of allowed participants in a conference. The rules can also be incredibly complex, specifying time-of-day-based rules on participation, conditional on the presence of other participants. It is important to understand that there is no restriction on the type of rules that can be encapsulated in a conference policy.
会议策略包含指导焦点操作的规则。规则可以很简单，例如定义会议中允许的参与者集的访问列表。这些规则也可能非常复杂，以其他参与者在场为条件，指定基于参与时间的规则。重要的是要了解，对于可以封装在会议策略中的规则类型没有限制。
The conference policy can be manipulated using web applications or voice applications. It can also be manipulated with non-SIP-specific standard or proprietary protocols.
可以使用web应用程序或语音应用程序操纵会议策略。它也可以通过非SIP特定的标准或专有协议进行操作。
There are a large number of ways in which users can interact with a conference. They can join, leave, set policies, approve members, and so on. This section is meant as an overview of the major conferencing operations, summarizing how they operate. More detailed examples of the SIP mechanisms can be found in [7].
用户可以通过多种方式与会议进行交互。他们可以加入、离开、设置策略、批准成员等。本节概述了主要会议操作，总结了它们的操作方式。有关SIP机制的更详细示例，请参见[7]。
As well as providing an overview of the common conferencing operations, each of the subsections in this section of the document provides a description of the SIP mechanism for supporting the operation. Non-SIP mechanisms are also possible, but not discussed here.
除了提供常见会议操作的概述外，本文档本节中的每个小节还提供了支持该操作的SIP机制的描述。非SIP机制也是可能的，但这里不讨论。
There are many ways in which a conference can be created. The creation of a conference actually constructs several elements all at the same time. It results in the creation of a focus and a conference policy. It also results in the construction of a conference URI, which uniquely identifies the focus. Since the conference URI needs to be unique, the element that creates conferences is responsible for guaranteeing that uniqueness. This can be accomplished deterministically (by keeping records of
创建会议的方式有很多种。会议的创建实际上同时构造了多个元素。它产生了一个焦点和一个会议政策。它还导致构造一个会议URI，该URI唯一地标识焦点。由于会议URI需要是唯一的，因此创建会议的元素负责保证这种唯一性。这可以确定地实现（通过保存
conference URIs, or by generating URIs algorithmically), or probabilistically, (by creating a random URI with sufficiently low probabilities of collision).
会议URI，或通过算法生成URI），或通过概率（通过创建具有足够低冲突概率的随机URI）。
When conference policy is created, it is established with default rules that are implementation-dependent. If the creator of the conference wishes to change those rules, they would do so using a non-SIP mechanism.
创建会议策略时，将使用依赖于实现的默认规则建立该策略。如果会议的创建者希望更改这些规则，他们将使用非SIP机制进行更改。
SIP can be used to create conferences hosted in a central server by sending an INVITE to a conferencing application that would automatically create a new conference and then place a user into it.
SIP可用于创建托管在中央服务器上的会议，方法是向会议应用程序发送邀请，该会议应用程序将自动创建新会议，然后将用户放入其中。
Creation of conferences where the focus resides in an endpoint operates differently. There, the endpoint itself creates the conference URI, and hands it out to other endpoints that will be the participants. What differs from case to case is how the endpoint decides to create a conference.
创建焦点位于端点中的会议的操作方式不同。在那里，端点本身创建会议URI，并将其分发给将成为参与者的其他端点。不同的情况是端点决定如何创建会议。
One important case is the ad-hoc conference described in Section 6.2. There, an endpoint unilaterally decides to create the conference based on local policy. The dialogs that were connected to the UA are migrated to the endpoint-hosted focus, using a re-INVITE or UPDATE to pass the conference URI to the newly joined participants.
一个重要的例子是第6.2节所述的特别会议。在那里，一个端点单方面决定根据当地政策创建会议。连接到UA的对话框将迁移到端点承载的焦点，使用重新邀请或更新将会议URI传递给新加入的参与者。
Alternatively, one UA can ask another UA to create an endpoint-hosted conference. This is accomplished with the SIP Join header [10]. The UA that receives the Join header in an invitation may need to create a new conference URI (a new one is not needed if the dialog that is being joined is already part of a conference). The conference URI is then handed to the recently joined participants through a re-INVITE or UPDATE.
或者，一个UA可以要求另一个UA创建端点托管的会议。这是通过SIP连接头实现的[10]。在邀请中接收加入标头的UA可能需要创建新的会议URI（如果正在加入的对话框已经是会议的一部分，则不需要新的URI）。然后通过重新邀请或更新将会议URI传递给最近加入的参与者。
There are many mechanisms for adding participants to a conference. In all cases, participant additions can be first party (a user adds themself) or third party (a user adds another user).
有许多机制可以将参与者添加到会议中。在所有情况下，参与者添加可以是第一方（用户添加自己）或第三方（用户添加其他用户）。
First person additions using SIP are trivially accomplished with a standard INVITE. A participant can send an INVITE request to the conference URI, and if the conference policy allows them to join, they are added to the conference.
使用SIP的第一人称添加可以通过标准的INVITE轻松完成。参与者可以向会议URI发送邀请请求，如果会议策略允许他们加入，他们将被添加到会议中。
If a UA does not know the conference URI, but has learned about a dialog which is connected to a conference (by using the dialog event package, for example [11]), the UA can join the conference by using the Join header to join the dialog.
如果UA不知道会议URI，但已经了解到连接到会议的对话（通过使用对话事件包，例如[11]），UA可以通过使用加入头加入对话来加入会议。
Third party additions with SIP are done using REFER [12]. The client can send a REFER request to the participant, asking them to send an INVITE request to the conference URI. Additionally, the client can send a REFER request to the focus, asking it to send an INVITE to the participant. The latter technique has the benefit of allowing a client to add a conference-unaware participant that does not support the REFER method.
使用参考文献[12]对SIP进行第三方添加。客户端可以向参与者发送REFER请求，要求他们向会议URI发送INVITE请求。此外，客户机可以向焦点发送referequest，要求其向参与者发送邀请。后一种技术的好处是允许客户端添加不支持refere方法的会议无关参与者。
As with additions, there are several mechanisms for departures. Removals can also be first person or third person.
与附加功能一样，有几种机制可用于离开。删除也可以是第一人或第三人。
First person departures are trivially accomplished by sending a BYE request to the focus. This terminates the dialog with the focus and removes the participant from the conference. The focus can also remove a participant from the conference by sending it a BYE. In either case, the focus interacts with the mixer to make sure that the departed participant ceases receiving conference media, and that media from that participant are no longer mixed into the conference.
第一人称离开是通过向焦点发送BYE请求来完成的。这将终止带有焦点的对话，并将参与者从会议中移除。焦点还可以通过发送“再见”将参与者从会议中移除。在任何一种情况下，焦点都会与混合器进行交互，以确保离开的参与者停止接收会议媒体，并且来自该参与者的媒体不再混合到会议中。
Third person departures can also be done using SIP, through the REFER method.
也可以使用SIP通过REFER方法进行第三人离港。
Conferences can be destroyed in several ways. Generally, whether those means are applicable for any particular conference is a component of the conference policy.
会议可以通过几种方式被破坏。一般来说，这些手段是否适用于任何特定会议是会议政策的一个组成部分。
When a conference is destroyed, the conference policy associated with it is destroyed. Any attempts to read or write the policy results in a protocol error. Furthermore, the conference URI becomes invalid. Any attempts to send an INVITE to it, or SUBSCRIBE to it, would result in a SIP error response.
销毁会议时，将销毁与其关联的会议策略。任何读取或写入策略的尝试都会导致协议错误。此外，会议URI变得无效。任何向其发送邀请或订阅邀请的尝试都将导致SIP错误响应。
Typically, if a conference is destroyed while there are still participants, the focus would send a BYE to those participants before actually destroying the conference. Similarly, if there were any users subscribed to the conference notification service, those subscriptions would be terminated by the server before the actual destruction.
通常，如果一个会议在仍然有参与者的情况下被销毁，那么焦点将在实际销毁会议之前向这些参与者发送再见。类似地，如果有任何用户订阅了会议通知服务，这些订阅将在实际销毁之前由服务器终止。
There is no explicit means in SIP to destroy a conference. However, a conference may be destroyed as a by-product of a user leaving the conference, which can be done with BYE. In particular, if the conference policy states that the conference is destroyed once the last user or a specific user leaves, when that user does leave (using a SIP BYE request), the conference is destroyed.
SIP中没有明确的方法来破坏会议。但是，用户离开会议时，可能会将会议作为副产品销毁，这可以通过BYE完成。特别是，如果会议策略声明一旦最后一个用户或特定用户离开，会议即被销毁，则当该用户确实离开（使用SIP-BYE请求）时，会议即被销毁。
A participant in a conference will frequently wish to know the set of other users in the conference. This information can be obtained in many ways.
会议参与者通常希望了解会议中的其他用户集。这些信息可以通过多种方式获得。
The conference notification service allows a conference-aware participant to subscribe to it, and receive notifications that contain the list of participants. When a new participant joins or leaves, subscribers are notified. The conference notification service also allows a user to do a "fetch" [4] to obtain the current listing.
会议通知服务允许会议感知参与者订阅会议通知，并接收包含参与者列表的通知。当新参与者加入或离开时，将通知订阅者。会议通知服务还允许用户执行“获取”[4]以获取当前列表。
Each conference is composed of a particular set of media that the focus is managing. For example, a conference might contain a video stream and an audio stream. The set of media streams that constitute the conference can be changed by participants. When the set of media in the conference change, the focus will need to generate a re-INVITE to each participant in order to add or remove the media stream to each participant. When a media stream is being added, a participant can reject the offered media stream, in which case it will not receive or contribute to that stream. Rejection of a stream by a participant does not imply that the stream is no longer part of the conference, only that the participant is not involved in it.
每次会议都由焦点管理的一组特定媒体组成。例如，会议可能包含视频流和音频流。与会者可以更改构成会议的媒体流集。当会议中的媒体集发生变化时，focus需要为每个参与者生成重新邀请，以便向每个参与者添加或删除媒体流。当添加媒体流时，参与者可以拒绝提供的媒体流，在这种情况下，参与者将不会接收或贡献该流。参与者拒绝流并不意味着该流不再是会议的一部分，只意味着参与者没有参与其中。
A SIP re-INVITE can be used by a participant to add or remove a media stream. This is accomplished using the standard offer/answer techniques for adding media streams to a session [13]. This will trigger the focus to generate its own re-INVITEs.
参与者可以使用SIP重新邀请来添加或删除媒体流。这是通过使用标准的提供/应答技术向会话添加媒体流来实现的[13]。这将触发focus生成自己的重新邀请。
Conference announcements and recordings play a key role in many real conferencing systems. Examples of such features include:
会议通知和录音在许多实际会议系统中起着关键作用。这些特征的示例包括：
o Asking a user to state their name before joining the conference, in order to support a roll call
o 要求用户在参加会议前说明自己的姓名，以支持点名
o Allowing a user to request a roll call, so they can hear who else is in the conference
o 允许用户请求点名，以便他们可以听到会议中还有谁
o Allowing a user to press some keys on their keypad to record the conference
o 允许用户按键盘上的一些键录制会议
o Allowing a user to press some keys on their keypad to be connected with a human operator
o 允许用户按下键盘上的一些键，以便与人工操作员连接
o Allowing a user to press some keys on their keypad to mute or unmute their line
o 允许用户按键盘上的一些键来静音或取消静音线路
User 1
+-----------+
| |
| |
|Participant|
| 1 |
| |
+-----------+
|SIP
|Dialog
Conference |1
Policy +---|--------+
User 2 Server | | | Application
+-----------+ +-----------+ | non-SIP *************
| | | | |-------- * *
| | | | | * *
|Participant|-----------| Focus |------------*Participant*
| 2 | SIP | | | SIP * 4 *
| | Dialog | |--+ Dialog * *
+-----------+ 2 +-----------+ 4 *************
|
|
|SIP
|Dialog
|3
|
+-----------+
| |
| |
|Participant|
| 3 |
| |
+-----------+
User 3
User 1
+-----------+
| |
| |
|Participant|
| 1 |
| |
+-----------+
|SIP
|Dialog
Conference |1
Policy +---|--------+
User 2 Server | | | Application
+-----------+ +-----------+ | non-SIP *************
| | | | |-------- * *
| | | | | * *
|Participant|-----------| Focus |------------*Participant*
| 2 | SIP | | | SIP * 4 *
| | Dialog | |--+ Dialog * *
+-----------+ 2 +-----------+ 4 *************
|
|
|SIP
|Dialog
|3
|
+-----------+
| |
| |
|Participant|
| 3 |
| |
+-----------+
User 3
Figure 3
图3
In this framework, these capabilities are modeled as an application that acts as a participant in the conference. This is shown pictorially in Figure 3. The conference has four participants. Three of these participants are end users, and the fourth is the announcement application.
在这个框架中，这些功能被建模为作为会议参与者的应用程序。如图3所示。会议有四名与会者。其中三个参与者是最终用户，第四个是公告应用程序。
If the announcement application wishes to play an announcement to all the conference members (for example, to announce a join), it merely sends media to the mixer as would any other participant. The announcement is mixed in with the conversation and played to the participants.
如果公告应用程序希望向所有会议成员播放公告（例如，宣布加入），它只会像任何其他参与者一样向混合器发送媒体。公告与对话融为一体，并向参与者播放。
Similarly, the announcement application can play an announcement to a specific user by configuring the conference policy so that the media it generates is only heard by the target user. The application then generates the desired announcement, and it will be heard only by the selected recipient.
类似地，公告应用程序可以通过配置会议策略向特定用户播放公告，从而使其生成的媒体仅被目标用户听到。然后，应用程序生成所需的公告，并且仅由选定的收件人听到。
The announcement application can also receive input from a specific user through the conference. To do this, it can use the application interaction framework [6]. This allows it to collect user input, possibly through keypad stimulus, and to take actions.
公告应用程序还可以通过会议接收特定用户的输入。为此，它可以使用应用程序交互框架[6]。这允许它收集用户输入，可能通过键盘刺激，并采取行动。
In this section, we present several physical instantiations of these components, to show how these basic functions can be combined to solve a variety of problems.
在本节中，我们将介绍这些组件的几个物理实例，以展示如何将这些基本功能组合起来解决各种问题。
In the most simplistic realization of this framework, there is a single physical server in the network, which implements the focus, the conference policy server, and the mixers. This is the classic "one box" solution, shown in Figure 4.
在这个框架最简单的实现中，网络中只有一个物理服务器，它实现了焦点、会议策略服务器和混频器。这是典型的“一个盒子”解决方案，如图4所示。
Conference Server
...................................
. .
. +------------+ .
. | Conference | .
. |Notification| .
. | Server | .
. +------------+ .
. +----------+ .
. |Conference| +-----+ .
. | Policy | +-------+ +-----+| .
. | Server | | Focus | |Mixer|+ .
. +----------+ +-------+ +-----+ .
................//.\.....***.......
// \ *** *
// *** * RTP
SIP // *** \ *
// *** \SIP *
// *** RTP \ *
/ ** \ *
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
Conference Server
...................................
. .
. +------------+ .
. | Conference | .
. |Notification| .
. | Server | .
. +------------+ .
. +----------+ .
. |Conference| +-----+ .
. | Policy | +-------+ +-----+| .
. | Server | | Focus | |Mixer|+ .
. +----------+ +-------+ +-----+ .
................//.\.....***.......
// \ *** *
// *** * RTP
SIP // *** \ *
// *** \SIP *
// *** RTP \ *
/ ** \ *
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
Figure 4
图4
Another important model is that of a locally-mixed ad-hoc conference. In this scenario, two users (A and B) are in a regular point-to-point call. One of the participants (A) decides to conference-in a third participant, C. To do this, A begins acting as a focus. Its existing dialog with B becomes the first dialog attached to the focus. A would re-INVITE B on that dialog, changing its Contact URI to a new value that identifies the focus. In essence, A "mutates" from a single-user UA to a focus plus a single user UA, and in the process of such a mutation, its URI changes. Then, the focus makes an outbound INVITE to C. When C accepts, it mixes the media from B and C together, redistributing the results. The mixed media is also played locally. Figure 5 shows a diagram of this transition.
Another important model is that of a locally-mixed ad-hoc conference. In this scenario, two users (A and B) are in a regular point-to-point call. One of the participants (A) decides to conference-in a third participant, C. To do this, A begins acting as a focus. Its existing dialog with B becomes the first dialog attached to the focus. A would re-INVITE B on that dialog, changing its Contact URI to a new value that identifies the focus. In essence, A "mutates" from a single-user UA to a focus plus a single user UA, and in the process of such a mutation, its URI changes. Then, the focus makes an outbound INVITE to C. When C accepts, it mixes the media from B and C together, redistributing the results. The mixed media is also played locally. Figure 5 shows a diagram of this transition.translate error, please retry
B B
+------+ +------+
| | | |
| UA | | UA |
| | | |
+------+ +------+
| . | .
| . | .
| . | .
| . Transition | .
| . ------------> | .
SIP| .RTP SIP| .RTP
| . | .
| . | .
| . | .
| . | .
| . +----------+
+------+ | +------+ | SIP +------+
| | | |Focus | |----------| |
| UA | | |C.Pol.| | | UA |
| | | |Mixers| |..........| |
+------+ | | | | RTP +------+
| +------+ |
A | + | C
| + <..|.......
| + | .
| +------+ | .
| |Parti-| | .
| |cipant| | .
| | | | .
| +------+ | .
+----------+ .
A .
.
B B
+------+ +------+
| | | |
| UA | | UA |
| | | |
+------+ +------+
| . | .
| . | .
| . | .
| . Transition | .
| . ------------> | .
SIP| .RTP SIP| .RTP
| . | .
| . | .
| . | .
| . | .
| . +----------+
+------+ | +------+ | SIP +------+
| | | |Focus | |----------| |
| UA | | |C.Pol.| | | UA |
| | | |Mixers| |..........| |
+------+ | | | | RTP +------+
| +------+ |
A | + | C
| + <..|.......
| + | .
| +------+ | .
| |Parti-| | .
| |cipant| | .
| | | | .
| +------+ | .
+----------+ .
A .
.
Internal Interface
内部接口
Figure 5
图5
It is important to note that the external interfaces in this model, between A and B, and between B and C, are exactly the same to those that would be used in a centralized server model. User A could also implement a conference policy and a conference notification service, allowing the participants to have access to them if they so desired. Just because the focus is co-resident with a participant does not mean any aspect of the behaviors and external interfaces will change.
需要注意的是，此模型中的外部接口（A和B之间以及B和C之间）与集中式服务器模型中使用的接口完全相同。用户A还可以实现会议策略和会议通知服务，允许参与者在需要时访问它们。仅仅因为焦点是与参与者共同居住的，并不意味着行为和外部接口的任何方面都会改变。
+------------+ +------------+
| App Server| SIP |Conf. Cmpnt.|
| |-------------| |
| Focus | non-SIP | Focus |
| C.Pol |-------------| C.Pol |
| | | Mixers |
|Notification| | |
| | | |
+------------+ +------------+
| \ .. .
| \\ RTP... .
| \\ .. .
| SIP \\ ... .
SIP | \\ ... .RTP
| ..\ .
| ... \\ .
| ... \\ .
| .. \\ .
| ... \\ .
| .. \ .
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
+------------+ +------------+
| App Server| SIP |Conf. Cmpnt.|
| |-------------| |
| Focus | non-SIP | Focus |
| C.Pol |-------------| C.Pol |
| | | Mixers |
|Notification| | |
| | | |
+------------+ +------------+
| \ .. .
| \\ RTP... .
| \\ .. .
| SIP \\ ... .
SIP | \\ ... .RTP
| ..\ .
| ... \\ .
| ... \\ .
| .. \\ .
| ... \\ .
| .. \ .
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
Figure 6
图6
In this model, shown in Figure 6, each conference involves two centralized servers. One of these servers, referred to as the "application server" owns and manages the membership and media policies, and maintains a dialog with each participant. As a result, it represents the focus seen by all participants in a conference. However, this server doesn't provide any media support. To perform the actual media mixing function, it makes use of a second server, called the "mixing server". This server includes a focus, and implements a conference policy, but has no conference notification service. Its conference policy tells it to accept all invitations from the top-level focus. The focus in the application server uses third party call control to connect the media streams of each user to the mixing server, as needed. If the focus in the application server receives a conference policy control command from a client, it delegates that to the media server by making the same media policy control command to it.
在这个模型中，如图6所示，每个会议涉及两个集中式服务器。其中一个服务器（称为“应用服务器”）拥有并管理成员资格和媒体策略，并与每个参与者保持对话。因此，它代表了所有与会者在会议上看到的焦点。但是，此服务器不提供任何媒体支持。要执行实际的媒体混合功能，它使用第二台服务器，称为“混合服务器”。此服务器包括一个焦点，并实现会议策略，但没有会议通知服务。它的会议政策告诉它接受来自顶级焦点的所有邀请。应用服务器中的focus使用第三方呼叫控制，根据需要将每个用户的媒体流连接到混合服务器。如果应用程序服务器中的focus从客户端接收到会议策略控制命令，它将通过向媒体服务器发出相同的媒体策略控制命令来将该命令委托给媒体服务器。
This model allows for the mixing server to be used as a resource for a variety of different conferencing applications. This is because it is unaware of conference policy; it is merely a "slave" to the top-level server, doing whatever it asks.
此模型允许混合服务器用作各种不同会议应用程序的资源。这是因为它不知道会议政策；它只不过是顶级服务器的“从服务器”，按其要求执行任何操作。
In a distributed mixed conference, there is still a centralized server that implements the focus, conference policy server, and media policy server. However, there are no centralized mixers. Rather, there are mixers in each endpoint, along with a conference policy server. The focus distributes the media by using third party call control [14] to move a media stream between each participant and each other participant. As a result, if there are N participants in the conference, there will be a single dialog between each participant and the focus, but the session description associated with that dialog will be constructed to allow media to be distributed amongst the participants. This is shown in Figure 7.
In a distributed mixed conference, there is still a centralized server that implements the focus, conference policy server, and media policy server. However, there are no centralized mixers. Rather, there are mixers in each endpoint, along with a conference policy server. The focus distributes the media by using third party call control [14] to move a media stream between each participant and each other participant. As a result, if there are N participants in the conference, there will be a single dialog between each participant and the focus, but the session description associated with that dialog will be constructed to allow media to be distributed amongst the participants. This is shown in Figure 7.translate error, please retry
+---------+
|Partcpnt |
media | | media
...............| |..................
. | Mixers | .
. |C.Pol.Srv| .
. +---------+ .
. | .
. | .
. | .
. dialog | .
. | .
. | .
. | .
. +---------+ .
. |Cnf.Srvr.| .
. | | .
. | Focus | .
. |C.Pol.Srv| .
. / | | \ .
. / +---------+ \ .
. / \ .
. / \ .
. / dialog \ .
. / \ .
. /dialog \ .
. / \ .
. / \ .
. / \ .
. .
+---------+ +---------+
|Partcpnt | |Partcpnt |
| | | |
| | ......................... | |
| Mixers | | Mixers |
|C.Pol.Srv| media |C.Pol.Srv|
+---------+ +---------+
+---------+
|Partcpnt |
media | | media
...............| |..................
. | Mixers | .
. |C.Pol.Srv| .
. +---------+ .
. | .
. | .
. | .
. dialog | .
. | .
. | .
. | .
. +---------+ .
. |Cnf.Srvr.| .
. | | .
. | Focus | .
. |C.Pol.Srv| .
. / | | \ .
. / +---------+ \ .
. / \ .
. / \ .
. / dialog \ .
. / \ .
. /dialog \ .
. / \ .
. / \ .
. / \ .
. .
+---------+ +---------+
|Partcpnt | |Partcpnt |
| | | |
| | ......................... | |
| Mixers | | Mixers |
|C.Pol.Srv| media |C.Pol.Srv|
+---------+ +---------+
Figure 7
图7
There are several ways in which the media can be distributed to each participant for mixing. In a multi-unicast model, each participant sends a copy of its media to each other participant. In this case, the session description manages N-1 media streams. In a multicast model, each participant joins a common multicast group, and each participant sends a single copy of its media stream to that group. The underlying multicast infrastructure then distributes the media, so that each participant gets a copy. In a single-source multicast
有几种方式可以将媒体分发给每个参与者进行混合。在多单播模型中，每个参与者向其他参与者发送其媒体的副本。在这种情况下，会话描述管理N-1个媒体流。在多播模型中，每个参与者加入一个公共多播组，并且每个参与者向该组发送其媒体流的单个副本。然后，底层的多播基础设施分发媒体，以便每个参与者获得一份拷贝。在单源多播中
model (SSM), each participant sends its media stream to a central point, using unicast. The central point then redistributes the media to all participants using multicast. The focus is responsible for selecting the modality of media distribution, and for handling any hybrids that would be necessitated from clients with mixed capabilities.
模型（SSM），每个参与者使用单播将其媒体流发送到中心点。然后，中心点使用多播将媒体重新分发给所有参与者。focus负责选择媒体分发模式，并处理具有混合功能的客户可能需要的任何混合。
When a new participant joins or is added, the focus will perform the necessary third party call control to distribute the media from the new participant to all the other participants, and vice versa.
当新参与者加入或添加时，focus将执行必要的第三方呼叫控制，将媒体从新参与者分发给所有其他参与者，反之亦然。
The central conference server also exposes an interface to the conference policy. Of course, the central conference server cannot implement any of the media operations or policies directly. Rather, it would delegate the implementation to each participant. As an example, if a participant decides to switch the overall conference mode from "voice activated" to "continuous presence", they would communicate with the central conference policy server. The conference policy server, in turn, would communicate with the conference policy servers that are co-resident with each participant, using some non-SIP-specific mechanism, and instruct them to use "continuous presence".
中央会议服务器还向会议策略公开一个接口。当然，中央会议服务器不能直接实现任何媒体操作或策略。相反，它将把实现委托给每个参与者。例如，如果参与者决定将整个会议模式从“语音激活”切换到“持续存在”，他们将与中央会议策略服务器通信。反过来，会议策略服务器将使用一些非SIP特定机制与每个参与者共同驻留的会议策略服务器通信，并指示它们使用“持续存在”。
This model requires additional functionality in user agents, which may or may not be present. The participants, therefore, must be able to advertise this capability to the focus.
此模型需要用户代理中的附加功能，这些功能可能存在，也可能不存在。因此，参与者必须能够向焦点宣传这种能力。
In very large conferences, it may not be possible to have a single mixer that can handle all of the media. A solution to this is to use cascaded mixers. In this architecture, there is a centralized focus, but the mixing function is implemented by a multiplicity of mixers, scattered throughout the network. Each participant is connected to one, and only one of the mixers. The focus uses some kind of control protocol to connect the mixers together, so that all of the participants can hear each other.
在非常大的会议中，可能不可能有一个能够处理所有媒体的混音器。解决这个问题的方法是使用级联混频器。在这种架构中，有一个集中的焦点，但混合功能是由分散在整个网络中的多个混频器实现的。每个参与者都连接到一个且仅连接到一个混合器。focus使用某种控制协议将混音器连接在一起，以便所有参与者都能听到对方的声音。
This architecture is shown in Figure 8.
该体系结构如图8所示。
+---------+
+-----------------------| |------------------------+
| ++++++++++++++++++++| |++++++++++++++++++ |
| + +------| Focus |---------+ + |
| + | | | | + |
| + | +-| |--+ | + |
| + | | +---------+ | | + |
| + | | + | | + |
| + | | + | | + |
| + | | + | | + |
| + | | +---------+ | | + |
| + | | | | | | + |
| + | | | Mixer 2 | | | + |
| + | | | | | | + |
| + | | +---------+ | | + |
| + | |... . .... | | + |
| + .|....| . .|.... | + |
| + ...... | | . | ..|... + |
| + ... | | . | | ....+ |
| +---------+ | | +---------+ | | +---------+ |
| | | | | | | | | | | |
| | Mixer 2 | | | | Mixer 3 | | | | Mixer 4 | |
| | | | | | | | | | | |
| +---------+ | | +---------+ | | +---------+ |
| . . | | . . | | . . |
| . . | | .. . | | .. . |
| . . | | . . | | . . |
+---------+ . | +---------+ . | +---------+ . |
| Prtcpnt | . | | Prtcpnt | . | | Prtcpnt | . |
| 1 | . | | 3 | . | | 5 | . |
+---------+ . | +---------+ . | +---------+ . |
. | . | . |
+---------+ +---------+ +---------+
| Prtcpnt | | Prtcpnt | | Prtcpnt |
| 2 | | 4 | | 6 |
+---------+ +---------+ +---------+
+---------+
+-----------------------| |------------------------+
| ++++++++++++++++++++| |++++++++++++++++++ |
| + +------| Focus |---------+ + |
| + | | | | + |
| + | +-| |--+ | + |
| + | | +---------+ | | + |
| + | | + | | + |
| + | | + | | + |
| + | | + | | + |
| + | | +---------+ | | + |
| + | | | | | | + |
| + | | | Mixer 2 | | | + |
| + | | | | | | + |
| + | | +---------+ | | + |
| + | |... . .... | | + |
| + .|....| . .|.... | + |
| + ...... | | . | ..|... + |
| + ... | | . | | ....+ |
| +---------+ | | +---------+ | | +---------+ |
| | | | | | | | | | | |
| | Mixer 2 | | | | Mixer 3 | | | | Mixer 4 | |
| | | | | | | | | | | |
| +---------+ | | +---------+ | | +---------+ |
| . . | | . . | | . . |
| . . | | .. . | | .. . |
| . . | | . . | | . . |
+---------+ . | +---------+ . | +---------+ . |
| Prtcpnt | . | | Prtcpnt | . | | Prtcpnt | . |
| 1 | . | | 3 | . | | 5 | . |
+---------+ . | +---------+ . | +---------+ . |
. | . | . |
+---------+ +---------+ +---------+
| Prtcpnt | | Prtcpnt | | Prtcpnt |
| 2 | | 4 | | 6 |
+---------+ +---------+ +---------+
------- SIP Dialog
....... Media Flow
+++++++ Control Protocol
------- SIP Dialog
....... Media Flow
+++++++ Control Protocol
Figure 8
图8
Conferences frequently require security features in order to properly operate. The conference policy may dictate that only certain participants can join, or that certain participants can create new policies. Generally speaking, conference applications are very concerned about authorization decisions. Having mechanisms for establishing and enforcing such authorization rules is a central concept throughout this document.
会议通常需要安全功能才能正常运行。会议策略可能规定只有某些参与者可以加入，或者某些参与者可以创建新策略。一般来说，会议应用程序非常关注授权决策。建立和执行此类授权规则的机制是本文件的核心概念。
Of course, authorization rules require authentication. Normal SIP authentication mechanisms should suffice for the conference authorization mechanisms described here.
当然，授权规则需要身份验证。正常的SIP身份验证机制应该足以满足这里描述的会议授权机制。
Privacy is an important aspect of conferencing. Users may wish to join a conference without anyone knowing that they have joined, in order to silently listen in. In other applications, a participant may wish to hide only their identity from other participants, but otherwise let them know of their presence. These functions need to be provided by the conferencing system.
隐私是会议的一个重要方面。用户可能希望在没有任何人知道他们已加入的情况下加入会议，以便静默地收听。在其他应用程序中，参与者可能希望对其他参与者仅隐藏其身份，但以其他方式让他们知道其存在。这些功能需要由会议系统提供。
This document is the result of discussions amongst the conferencing design team. The members of this team include:
本文件是会议设计团队讨论的结果。该小组的成员包括：
Alan Johnston Brian Rosen Rohan Mahy Henning Schulzrinne Orit Levin Roni Even Tom Taylor Petri Koskelainen Nermeen Ismail Andy Zmolek Joerg Ott Dan Petrie
艾伦·约翰斯顿·布赖恩·罗森·罗汉·马希·亨宁·舒尔兹林内或莱文·罗尼甚至汤姆·泰勒·佩特里·科斯凯莱宁·内尔米·伊斯梅尔·安迪·兹莫莱克·约尔格·奥特和佩特里
The authors would like to thank Mary Barnes, Chris Boulton and Rohan Mahy for their comments. Thanks to Allison Mankin for her comments and support of this work.
作者要感谢玛丽·巴恩斯、克里斯·博尔顿和罗汉·马希的评论。感谢Allison Mankin对这项工作的评论和支持。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[2] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[3] Levin, O. and R. Even, "High-Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005.
[3] Levin，O.和R.Even，“紧密耦合SIP会议的高级别要求”，RFC 42452005年11月。
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[5] Campbell, B., "The Message Session Relay Protocol", Work In Progress, October 2004.
[5] Campbell，B.，“消息会话中继协议”，正在进行的工作，2004年10月。
[6] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work In Progress, February 2005.
[6] Rosenberg，J.，“会话启动协议（SIP）中的应用程序交互框架”，正在进行的工作，2005年2月。
[7] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", Work in Progress, February 2005.
[7] Johnston，A.和O.Levin，“会话发起协议（SIP）呼叫控制-用户代理会议”，正在进行的工作，2005年2月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[8] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[9] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[10] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[10] Mahy，R.和D.Petrie，“会话启动协议（SIP）”加入“头”，RFC 3911，2004年10月。
[11] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[11] Rosenberg，J.，Schulzrinne，H.，和R.Mahy，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 42352005年11月。
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[12] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[14] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[14] Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，BCP 85，RFC 37252004年4月。
[15] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[15] Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC3311，2002年10月。
Author's Address
作者地址
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Cisco Systems 600美国新泽西州帕西帕尼拉尼德广场07054号
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
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）提供。