Network Working Group P. Koskelainen
Request for Comments: 4376 Nokia
Category: Informational J. Ott
Helsinki University of Technology
H. Schulzrinne
X. Wu
Columbia University
February 2006
Network Working Group P. Koskelainen
Request for Comments: 4376 Nokia
Category: Informational J. Ott
Helsinki University of Technology
H. Schulzrinne
X. Wu
Columbia University
February 2006
Requirements for Floor Control Protocols
地板控制协议的要求
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
摘要
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework.
楼层控制是在（多方）会议环境中管理对共享资源的联合或独占访问的一种方法。因此，楼层控制补充了其他协议实现的其他功能，如会议和媒体会话设置、会议策略操作和媒体控制。本文件定义了现有框架下多方会议楼层控制协议的要求。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. Model ...........................................................4
5. Integration with Conferencing ...................................5
6. Assumptions about a Conference Policy ...........................6
7. Floor Control Protocol Requirements .............................7
7.1. Communication between Participant and Server ...............7
7.2. Communication between Chair and Server .....................9
7.3. General Protocol Requirements ..............................9
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. Model ...........................................................4
5. Integration with Conferencing ...................................5
6. Assumptions about a Conference Policy ...........................6
7. Floor Control Protocol Requirements .............................7
7.1. Communication between Participant and Server ...............7
7.2. Communication between Chair and Server .....................9
7.3. General Protocol Requirements ..............................9
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
Conference applications often have shared resources such as the right to talk, input access to a limited-bandwidth video channel, or a pointer or input focus in a shared application.
会议应用程序通常具有共享资源，例如通话权、对有限带宽视频通道的输入访问权，或者共享应用程序中的指针或输入焦点。
In many cases, it is desirable to be able to control who can provide input (send/write/control, depending on the application) to the shared resource.
在许多情况下，希望能够控制谁可以向共享资源提供输入（发送/写入/控制，取决于应用程序）。
Floor control enables applications or users to gain safe and mutually exclusive or non-exclusive input access to the shared object or resource. The floor is an individual temporary access or manipulation permission for a specific shared resource (or group of resources) [6].
楼层控制使应用程序或用户能够获得对共享对象或资源的安全、互斥或非互斥输入访问。楼层是对特定共享资源（或资源组）的单独临时访问或操作权限[6]。
Floor control is an optional feature for conferencing applications. SIP [2] conferencing applications may also decide not to support this feature at all. Two-party applications may use floor control outside conferencing, although the usefulness of this kind of scenario is limited. Floor control may be used together with the conference policy control protocol (CPCP) [7], or it may be used as an independent stand-alone protocol, e.g., with SIP but without CPCP.
楼层控制是会议应用程序的可选功能。SIP[2]会议应用程序也可能决定根本不支持此功能。双方应用程序可以在会议之外使用楼层控制，尽管这种场景的实用性是有限的。楼层控制可以与会议策略控制协议（CPCP）[7]一起使用，也可以作为独立的独立协议使用，例如，有SIP但没有CPCP。
Floor control has been studied extensively over the years (e.g., [8], [6], and [5]); therefore, earlier work can be leveraged here.
多年来对地板控制进行了广泛的研究（例如，[8]、[6]和[5]）；因此，这里可以利用早期的工作。
The present document describes the requirements for a floor control protocol. As a requirements specification, the document makes no assumptions about the later implementation of the respective
本文件描述了地板控制协议的要求。作为一项需求规范，本文件对各项目的后续实施不作任何假设
requirements as parts of one or more protocols or about the entities implementing them and their roles.
作为一个或多个协议的一部分的需求，或关于实现它们的实体及其角色的需求。
This document may be used in conjunction with other documents, such as the conferencing framework document [3]. In particular, when speaking about a floor control server, this entity may be identical to or co-located with the focus or a conference policy server defined in the framework document, while participants and floor chairs referred to in this specification may be regular participants as introduced in the conferencing framework document. In this specification, the term "floor control protocol" is used in an abstract sense and may ultimately be mapped to any of the existing conference control or other signaling protocols (including CPCP and SIP). However, defining those relationships is left to a concrete floor control protocol specification.
本文件可与其他文件一起使用，如会议框架文件[3]。特别是，当谈到楼层控制服务器时，该实体可能与框架文件中定义的focus或会议策略服务器相同或位于同一位置，而本规范中提及的参与者和楼层主席可能是会议框架文件中介绍的常规参与者。在本说明书中，术语“地板控制协议”是抽象意义上使用的，并且可以最终映射到任何现有的会议控制或其他信令协议（包括CPCP和SIP）。但是，定义这些关系将留给具体的楼层控制协议规范。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
This document uses the definitions from [3].
本文件使用[3]中的定义。
The following additional definitions apply:
以下附加定义适用：
Floor: A permission to access or manipulate a specific shared resource or set of resources temporarily.
楼层：临时访问或操作特定共享资源或资源集的权限。
Conference owner: A privileged user who controls the conference, creates floors, and assigns and deassigns floor chairs. The conference owner does not have to be a member in a conference.
会议所有者：控制会议、创建楼层、分配和取消分配楼层椅子的特权用户。会议所有者不必是会议中的成员。
Floor chair: A user (or an entity) who manages one floor (grants, denies, or revokes a floor). The floor chair does not have to be a member in a conference.
楼层主席：管理一个楼层（授予、拒绝或撤销楼层）的用户（或实体）。会议主席不必是会议的成员。
Floor control: A mechanism that enables applications or users to gain safe and mutually exclusive or non-exclusive input access to the shared object or resource.
楼层控制：一种机制，使应用程序或用户能够获得对共享对象或资源的安全、互斥或非互斥输入访问。
Floor control server: A logical entity that maintains the state of the floor(s) including which floors exists, who the floor chairs are, who holds a floor, etc. Requests to manipulate a floor are directed at the floor control server.
楼层控制服务器：维护楼层状态的逻辑实体，包括存在哪些楼层、谁是楼层椅、谁持有楼层等。操纵楼层的请求直接指向楼层控制服务器。
Floor request set: A logical data structure holding all requests for a particular floor at a given point in time.
楼层请求集：一种逻辑数据结构，保存在给定时间点对特定楼层的所有请求。
Floor holder set: A logical data structure identifying all participants who currently hold the floor.
发言权持有者集：一种逻辑数据结构，标识当前发言权持有者的所有参与者。
The model for floor control is composed of three logical entities: a single floor control server, one or more floor chairs (moderators), and any number of regular conference participants.
地板控制模型由三个逻辑实体组成：单个地板控制服务器、一个或多个地板椅（主持人）和任意数量的常规会议参与者。
A floor control protocol is used to convey the floor control messages among the floor chairs (moderators) of the conference, the floor control server, and the participants of the conference. A centralized architecture is assumed in which all messages go via one point, the floor control server. Processing (granting or rejecting) floor control requests is done by the one or more floor chairs or by the server itself, depending on the policy.
楼层控制协议用于在会议的楼层主席（主持人）、楼层控制服务器和会议参与者之间传递楼层控制消息。假定采用集中式体系结构，其中所有消息都通过一个点，即楼层控制服务器。根据策略，由一个或多个楼层椅或服务器本身处理（批准或拒绝）楼层控制请求。
Floor requests from the participants are received by the floor control server and kept (at the level of the floor control protocol) in a floor request set (i.e., are not ordered in any particular fashion). The current floor holders are reflected in a current floor holder set. Floor chairs are capable of manipulating both sets to grant, revoke, reject, and pass the floor (for example).
来自参与者的发言权请求由发言权控制服务器接收，并保存在发言权请求集中（即，不以任何特定方式排序）。当前楼层支架反映在当前楼层支架集中。落地椅能够操纵这两个集合来授予、撤销、拒绝和通过地板（例如）。
The order in which requests are processed, whether they are granted or rejected, and how many participants obtain a floor simultaneously are determined by a higher-layer application operating on these sets and are not confined by the floor control protocol.
处理请求的顺序、是否批准请求以及有多少参与者同时获得发言权由在这些集合上运行的高层应用程序确定，不受发言权控制协议的限制。
A floor is associated with one or more media sessions. The centralized conference server manages the floors and thus controls access to the media sessions. There are two aspects to this: 1) The server maintains and distributes consistent state information about who has a certain floor at a certain point in time and does so following some rule set. This provides all participants with the necessary information about who is allowed to speak (for example), but relies on a cooperative behavior among all participants. 2) In addition, to prevent individuals from ignoring the "hints" given by the floor control server, the latter may (e.g., in cooperation with other functional entities) enforce compliance with floor status, e.g., by blocking media streams from participants not entitled to speak. The floor control server controls the floors at least at the signaling level. In addition, actively controlling the actual (physical) media resources is highly recommended, but beyond the scope of this document.
楼层与一个或多个媒体会话相关联。集中式会议服务器管理楼层，从而控制对媒体会话的访问。这有两个方面：1）服务器维护和分发关于谁在某个时间点拥有某个楼层的一致状态信息，并按照某个规则集执行此操作。这为所有参与者提供了关于谁可以发言的必要信息（例如），但取决于所有参与者之间的合作行为。2） 此外，为了防止个人忽略楼层控制服务器给出的“提示”，后者可以（例如，与其他功能实体合作）强制遵守楼层状态，例如，通过阻止来自无权发言的参与者的媒体流。楼层控制服务器至少在信令级别控制楼层。此外，强烈建议主动控制实际（物理）媒体资源，但这超出了本文档的范围。
As noted in the introduction, an actual protocol specification fulfilling the requirements defined in this memo may map the components of the above model onto the conferencing components defined in the conferencing framework document. Some of these aspects are discussed briefly in the next section.
如引言中所述，满足本备忘录中定义的要求的实际协议规范可能会将上述模型的组件映射到会议框架文档中定义的会议组件上。下一节将简要讨论其中的一些方面。
Floor control itself does not support privileges such as creating floors and appointing floor chairs and handing over chair privileges to other users (or taking them away). Instead, some external mechanism, such as conference management (e.g., CPCP or web interface for policy manipulation) is used for that.
楼层控制本身不支持特权，例如创建楼层、指定楼层椅子以及将椅子特权移交给其他用户（或将其带走）。相反，一些外部机制，如会议管理（例如，用于策略操纵的CPCP或web界面）被用于此目的。
The conference policy (and thus the conference owner or creator) defines whether floor control is in use or not. Actually enforcing conference media distribution in line with the respective media's floor status (e.g., controlling an audio bridge) is beyond the scope of this document. Floor control itself does not define media enforcement. It is up to the conference and media policies to define which media streams may be used in a conference and which ones are floor controlled.
会议策略（以及会议所有者或创建者）定义是否使用楼层控制。根据各自媒体的楼层状态（例如，控制音频桥接器）实际执行会议媒体分发超出了本文档的范围。楼层控制本身不定义媒体强制。由会议和媒体策略来定义哪些媒体流可以在会议中使用，哪些媒体流受楼层控制。
Typically, the conference owner creates the floor(s) using the conference policy control protocol (or some other mechanism) and appoints the floor chair. The conference owner can remove the floor anytime (so that a media session is not floor-controlled anymore) or change the floor chair or floor parameters.
通常，会议所有者使用会议策略控制协议（或某些其他机制）创建发言权，并指定发言权主席。会议所有者可以随时移除地板（以便媒体会话不再受地板控制）或更改地板椅或地板参数。
The floor chair just controls the access to the floor(s), according to the conference policy.
根据会议政策，落地椅仅控制对地板的访问。
A floor control server is a separate logical entity, typically co-located with focus and/or conference policy server. Therefore, the floor control server can interact with the focus and conference policy server and media servers as needed. Communication mechanisms between the floor control server and other central conferencing entities are not within the scope of the floor control protocol requirements described in this document.
楼层控制服务器是一个独立的逻辑实体，通常与focus和/或conference policy server位于同一位置。因此，楼层控制服务器可以根据需要与焦点和会议策略服务器以及媒体服务器交互。楼层控制服务器和其他中央会议实体之间的通信机制不在本文件所述楼层控制协议要求的范围内。
Conferences may be cascaded, and hence a single participant in one conference may represent a second conference (called subconference). From a floor control perspective, there is no difference between a participant (identified by its URI) representing a single person or another (set of) subconference(s).
会议可以是级联的，因此一个会议中的单个参与者可以代表第二个会议（称为子会议）。从发言权控制的角度来看，代表一个人的参与者（通过其URI标识）与代表另一个（一组）子会议的参与者之间没有区别。
Note: In the latter case, it is the responsibility of the subconference to negotiate floor requests internally before passing on a request to the conference and to assign a floor internally upon receiving a floor grant. This may be done recursively by employing the floor control protocol with a different floor control server in the subconference.
注：在后一种情况下，分包会议有责任在将请求转交会议之前在内部协商发言权请求，并在收到发言权授予后在内部分配发言权。这可以通过在子会议中使用具有不同楼层控制服务器的楼层控制协议来递归地实现。
The floor control protocol is supposed to be used to manage access to shared resources in the context of a conference. It is up to this conference -- more precisely, its conference policy [4] -- to define the rules for the operation of the floor control protocol. Furthermore, a conference policy control protocol [4] may define mechanisms that alter those rules during the course of a conference. This section briefly outlines the assumptions made by a floor control protocol about the conference policy and means for its modification.
楼层控制协议应该用于管理会议环境中对共享资源的访问。由本次会议——更准确地说，是其会议政策[4]——来定义楼层控制协议的操作规则。此外，会议策略控制协议[4]可以定义在会议过程中改变这些规则的机制。本节简要概述了楼层控制协议对会议政策及其修改方法所作的假设。
The conference policy is expected to define the rules for floor control, which implies in particular that it is not the responsibility of the floor control protocol to establish or communicate those rules.
预计会议政策将定义楼层控制规则，这尤其意味着楼层控制协议不负责制定或传达这些规则。
In general, it is assumed that the conference policy also defines who is allowed to create, change, and remove a floor in a conference.
通常，假定会议策略还定义了允许谁在会议中创建、更改和删除发言权。
Conference participants and floor chairs should be able to get and set floor-related parameters. The conference policy may restrict who may access or alter which parameters. Note that not all parameters maintained for a floor are also interpreted by the floor control protocol (e.g., floor policy descriptions may be stored associated with a floor but may be interpreted by a higher-layer application). Note also that changes to the floor control policy are outside the scope of the floor control protocol and are (for example) to be carried out by a conference policy control protocol.
会议参与者和落座椅应能够获取并设置与落座相关的参数。会议策略可能会限制谁可以访问或更改哪些参数。请注意，并非为楼层维护的所有参数也由楼层控制协议解释（例如，楼层策略描述可与楼层相关联地存储，但可由高层应用程序解释）。还要注意，对楼层控制策略的更改不在楼层控制协议的范围内，并且（例如）将由会议策略控制协议执行。
(For example, it may be useful to see who the floor chair is, what kind of policy is in use, time limits, number of simultaneous floor holders, and current floor holder.)
（例如，了解谁是会议主席、使用哪种保单、时间限制、同时发言的人数以及当前发言权持有人可能很有用。）
The following requirements on a conference policy related to floor control are identified in [4]:
[4]中确定了与楼层控制相关的会议政策的以下要求：
REQ-F1: It MUST be possible to define whether floor control is in use or not.
REQ-F1：必须能够定义楼层控制是否正在使用。
REQ-F2: It MUST be possible to define the algorithm to be used in granting the floor. (Note: Examples of algorithms are moderator-controlled, FCFS, or random.)
REQ-F2：必须能够定义用于授予地板的算法。（注意：算法示例包括调节器控制、FCF或随机。）
Note: It must be possible to use an automated floor policy where the floor control server decides autonomously about granting and rejecting floor requests as well as revoking the floor. It must also be possible to use a chair-controlled floor policy in which the floor control server notifies the floor chair and waits for the chair to make a decision. This enables the chair to fully control who has the floor. The server MAY forward all requests immediately to the floor chair, or it may do filtering and send only occasional notifications to the chair.
注意：必须能够使用自动楼层策略，其中楼层控制服务器自动决定是否批准和拒绝楼层请求以及取消楼层。还必须可以使用由主席控制的楼层策略，其中楼层控制服务器通知楼层主席并等待主席做出决定。这使椅子能够完全控制谁发言。服务器可以立即将所有请求转发给会议主席，也可以进行过滤并仅偶尔向会议主席发送通知。
REQ-F3: It MUST be possible to define how many users can have the floor at the same time.
REQ-F3：必须能够定义有多少用户可以同时发言。
REQ-F4: It MUST be possible to have one floor for one or more media types.
REQ-F4：一个或多个媒体类型必须有一个楼层。
REQ-F5: It MUST be possible to have multiple floors in a conference.
REQ-F5：一个会议中必须有多个楼层。
REQ-F6: It MUST be possible to define whether a floor is moderator-controlled or not.
REQ-F6：必须能够定义楼层是否由主持人控制。
REQ-F7: If the floor is moderator-controlled, it MUST be possible to assign and replace the floor moderator.
REQ-F7：如果地板由主持人控制，则必须能够分配和更换地板主持人。
This section covers the requirements on a floor control protocol. The requirements are grouped as follows: 1) floor control protocol between participant and server; 2) floor control protocol between floor chairs and server; 3) floor control server management; and 4) general protocol requirements.
本节介绍地板控制协议的要求。要求分为以下几类：1）参与者和服务器之间的楼层控制协议；2） 落地椅和服务器之间的地板控制协议；3） 楼层控制服务器管理；4）一般协议要求。
REQ-PS-1: Participants MUST be able to request (claim) a floor.
REQ-PS-1：参与者必须能够请求（要求）发言权。
REQ-PS-2: It SHOULD be possible for a participant requesting a floor to give additional information about the request, such as the topic of the question for an audio floor. Note: In some scenarios, the floor control server or the floor chair may use this information when granting the floor to the user, or when manipulating the floor sets at the server.
REQ-PS-2：要求发言的参与者应能够提供有关请求的其他信息，如音频发言的问题主题。注意：在某些情况下，地板控制服务器或地板椅在向用户授予地板或在服务器上操作地板集时可能会使用此信息。
REQ-PS-3: It MUST be possible for a participant to modify (e.g., cancel) a previously placed floor request.
REQ-PS-3：参与者必须能够修改（如取消）先前提出的发言请求。
REQ-PS-4: It SHOULD be possible for a participant to initiate a floor control operation (e.g., floor request, release) on behalf of another participant (third-party floor control) provided that he is authorized to do so.
REQ-PS-4：参与者应能够代表另一参与者（第三方楼层控制）启动楼层控制操作（例如，楼层请求、释放），前提是该参与者有权这样做。
REQ-PS-5: A participant MUST be informed that she has been granted the floor.
REQ-PS-5：必须通知参与者她已获得发言权。
REQ-PS-6: A participant MUST be informed that his floor request has been rejected.
REQ-PS-6：必须通知参与者其发言请求已被拒绝。
REQ-PS-7: A participant MUST be informed that the floor was revoked from her.
REQ-PS-7：必须通知参与者其发言权已被撤销。
REQ-PS-8: A participant SHOULD be informed that her floor request is pending and will be processed later.
REQ-PS-8：应通知参与者她的发言请求正在等待，稍后将进行处理。
REQ-PS-9: A floor holder MUST be able to release a floor.
REQ-PS-9：地板支架必须能够释放地板。
REQ-PS-10: It MUST be possible to notify conference participants of (changes to) the floor holder(s).
REQ-PS-10：必须能够通知会议参与者（变更）发言权持有人。
REQ-PS-11: It MUST be possible to notify conference participants when a new floor request is being made.
REQ-PS-11：当提出新的发言请求时，必须能够通知会议参与者。
REQ-PS-12: It MUST be possible for a floor requester to request privacy for claiming the floor.
REQ-PS-12：要求发言权的人必须能够要求发言权的隐私权。
anonymous: The participants (including the floor chair) cannot see the floor requester's identity. The floor chairs grant the floor based on the claim id and the topic of the claim.
匿名：参与者（包括发言椅）无法看到发言请求者的身份。落地椅根据索赔id和索赔主题授予发言权。
known to the floor chair: Only the floor chair is able to see the floor requester's identity; all other participants do not obtain this information.
落地椅已知：只有落地椅能够看到请求者的身份；所有其他参与者均未获得此信息。
public: All the participants can see the floor requester's identity.
公共：所有参与者都可以看到发言请求者的身份。
REQ-PS-13: It MUST be possible for a participant to request privacy for holding the floor along with a floor request. Note that identity information about the participant may become available to others through different means (e.g., application/media protocols or the media itself such as the voice).
REQ-PS-13：参与者必须能够在要求发言的同时要求发言的隐私。注意，关于参与者的身份信息可以通过不同的方式（例如，应用程序/媒体协议或媒体本身，例如语音）提供给其他人。
REQ-CS-1: It MUST be possible to inform the floor chairs, if present, about a participant's floor request.
REQ-CS-1：必须能够将参与者的发言请求告知现场主席（如有）。
It SHOULD be possible to convey additional information the participant may have provided along with her request.
应能够传达参与者可能随其请求提供的其他信息。
It MUST be possible to hide the requesting participant's identity from the chair, i.e., not to include this identity information in the floor request.
必须能够向主席隐瞒请求参与者的身份，即不在发言请求中包含该身份信息。
REQ-CS-2: It MUST be possible to grant a floor to a participant.
REQ-CS-2：必须能够向参与者授予发言权。
REQ-CS-3: It MUST be possible to reject a participant's floor request.
REQ-CS-3：必须能够拒绝参与者的发言请求。
REQ-CS-4: The floor chair MUST be able to revoke a floor from (one of) its current holder(s). Note that the floor chair may also remove pending floor requests from the request set (by rejecting them).
REQ-CS-4：落地椅必须能够从（其中一个）其当前持有人处撤销一个地板。请注意，主席还可以从请求集中删除待定的发言请求（通过拒绝）。
REQ-CS-5: It MUST be possible to notify floor chairs about changes to the floor holder(s).
REQ-CS-5：必须能够通知地板椅地板支架的变化。
REQ-CS-6: There SHOULD be operations to manipulate the request set available for floor chair(s). Such a request set SHOULD at least include creating, maintaining, and re-ordering floor requests in a queue and clearing the floor control queue.
REQ-CS-6：应该有操作来操作可用于落地椅的请求集。此类请求集应至少包括在队列中创建、维护和重新排序楼层请求，以及清除楼层控制队列。
REQ-CS-7: It MUST be possible to hide the identity of a floor chair from a subset or all participants of a conference.
REQ-CS-7：必须能够对会议的一部分或所有参与者隐藏会议主席的身份。
REQ-CS-8: It MUST be possible for a newly assigned floor chair to learn (e.g., inquire) about the existing floor request set.
REQ-CS-8：新分配的落地椅必须能够了解（例如，询问）现有的落地请求集。
REQ-GEN-1: Bandwidth and terminal limitations SHOULD be taken into account in order to ensure that floor control can be efficiently used in mobile environments.
REQ-GEN-1：应考虑带宽和终端限制，以确保地板控制可在移动环境中有效使用。
Note that efficient communication by means of minimal-sized messages may contradict the desire to express reasons for requesting a floor along with other information. Therefore, a floor control protocol SHOULD be designed in a way that it allows for expressive as well as minimal messaging, as a (negotiable) configuration option and/or selectable on a per-message basis.
注意，通过最小尺寸的信息进行有效沟通可能与表达要求发言的原因以及其他信息的愿望相矛盾。因此，楼层控制协议的设计方式应允许以（可协商的）配置选项和/或根据每条消息进行选择的方式进行表达和最小化消息传递。
REQ-GEN-2: The floor control MUST be a reliable client-server protocol. Hence, it MUST provide a positive response indicating that a request has been received or an error response if an error has occurred.
REQ-GEN-2：楼层控制必须是可靠的客户机-服务器协议。因此，它必须提供一个肯定的响应，指示已收到请求，或者在发生错误时提供一个错误响应。
REQ-GEN-3: It MUST be possible for the floor control server to authenticate participants and chairs.
REQ-GEN-3：楼层控制服务器必须能够对参与者和椅子进行身份验证。
REQ-GEN-4: It MUST be possible for the participants and chairs to authenticate the server.
REQ-GEN-4：参与者和主席必须能够验证服务器。
REQ-GEN-5: It MUST be possible to ensure message integrity between participants and chairs and the floor control server.
REQ-GEN-5：必须能够确保参与者、椅子和地板控制服务器之间的消息完整性。
REQ-GEN-6: It MUST be possible to ensure the privacy of messages exchanged between participants and chairs and the floor control server.
REQ-GEN-6：必须能够确保参与者、椅子和地板控制服务器之间交换的消息的隐私。
Floor control messages are exchanged on one hand between regular participants and the floor control server and on the other hand between the floor control server and the floor chair(s).
楼层控制信息一方面在常规参与者和楼层控制服务器之间交换，另一方面在楼层控制服务器和楼层椅之间交换。
If enabled, floor control mechanisms are used to control who may contribute to a conference in arbitrary ways (speak, be seen, write, etc., as supported by the conferencing applications). It is important that floor control messages be protected because otherwise an attacker could prevent participants from being "heard" in the conference (e.g., in scenarios where silence is considered consent) or make participants be heard in a conference without their knowledge (e.g., eavesdropping on the participant's microphone). Such considerations are particularly relevant when floor control is used in conjunction with one or more (central) entities (e.g., a media mixer) controlled by the floor control server to enforce floor control decisions that may allow an attacker to "mute" a participant completely.
如果启用，楼层控制机制将用于控制可能以任意方式参与会议的人员（如会议应用程序支持的发言、被看到、写入等）。保护楼层控制信息非常重要，因为否则攻击者可能会阻止与会者在会议中被“听到”（例如，在沉默被视为同意的情况下），或者让与会者在不知情的情况下被听到（例如，窃听与会者的麦克风）。当地板控制与地板控制服务器控制的一个或多个（中央）实体（例如，媒体混音器）结合使用时，这些注意事项尤其相关，以强制执行地板控制决策，从而允许攻击者完全“静音”参与者。
Communications between a conference participant and the floor control server are vulnerable to all kinds of masquerading attacks. If an attacker can spoof the identity of the participant or inject messages on his behalf, it may generate floor requests (e.g., floor release) and prevent proper participation of the participant. If an attacker can inject messages to the participant, it may generate arbitrary responses and false status information. If an attacker can impersonate the floor control server, a participant's requests may never reach the actual floor control server. If an attacker can intercept either side's messages (and hence become a man in the
会议参与者与楼层控制服务器之间的通信容易受到各种伪装攻击。如果攻击者可以欺骗参与者的身份或代表其插入消息，则可能会生成发言请求（例如发言权释放）并阻止参与者的正确参与。如果攻击者可以向参与者注入消息，则可能会生成任意响应和错误的状态信息。如果攻击者可以模拟楼层控制服务器，则参与者的请求可能永远不会到达实际的楼层控制服务器。如果攻击者能够截获任何一方的消息（从而成为
middle (MITM)), it may suppress, alter, or inject messages and thus manipulate a participant's view of the conference floor status as well as the floor control server's view of a participant.
middle（MITM）），它可以抑制、更改或注入消息，从而操纵参与者对会议楼层状态的视图以及楼层控制服务器对参与者的视图。
Similar considerations apply to the communications between the floor control server and the floor chair(s). If an attacker can intercept messages from either side, it may defer or prevent responses to floor control requests (from a particular floor chair). If it can inject messages (particularly in the direction from the floor chair to the floor control server), it may steer the assignment of conference floors. If interception and injection is possible (man-in-the-middle scenario), an attacker can create an arbitrary image of the conference for the floor chair. If an attacker can impersonate a floor chair, it may rule the conference floor assignment (if there is only a single chair) or disrupt the conference course by means of arbitrary and potentially conflicting requests/responses/assignments (if there are multiple floor chairs). In the latter case, the amount of damage a single attacker can do depends on the floor control policy.
类似的注意事项也适用于地板控制服务器和地板椅之间的通信。如果攻击者可以截获任何一方的消息，则可能会延迟或阻止对地板控制请求的响应（来自特定地板椅）。如果它可以注入消息（特别是从楼层主席到楼层控制服务器的方向），它可以控制会议楼层的分配。如果可以拦截和注入（中间人场景），攻击者可以为会议主席创建任意会议图像。如果攻击者可以模拟落座椅，则攻击者可以通过任意且可能冲突的请求/响应/分配（如果有多个落座椅）来控制会议楼层分配（如果只有一个落座椅）或中断会议进程。在后一种情况下，单个攻击者可以造成的伤害量取决于地板控制策略。
Finally, attackers may eavesdrop on the floor control communications and learn which participants are present, how active they are, who are the floor chairs, etc.
最后，攻击者可以窃听地板控制通信，了解哪些参与者在场、他们有多活跃、谁是地板椅等。
To mitigate the above threats, conference participants, floor control servers, and floor chairs SHOULD be authenticated upon initial contact. All floor control messages SHOULD be authenticated and integrity-protected to prevent third-party intervention and MITM attacks. Floor control messages SHOULD be encrypted to prevent eavesdropping.
为缓解上述威胁，会议参与者、楼层控制服务器和楼层椅应在初次接触时进行身份验证。所有楼层控制信息都应经过身份验证和完整性保护，以防止第三方干预和MITM攻击。楼层控制信息应加密以防止窃听。
The authors would like to thank IETF conferencing design team and Keith Drage, Marcus Brunner, Sanjoy Sen, Eric Burger, Brian Rosen, and Nermeen Ismail for their feedback.
作者要感谢IETF会议设计团队和Keith Drage、Marcus Brunner、Sanjoy Sen、Eric Burger、Brian Rosen和Nermeen Ismail的反馈。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCD 14, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCD 14，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] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[3] Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，2006年2月。
[4] Koskelainen, P. and H. Khartabil, "Additional Requirements to Conferencing", Work in Progress, August 2004.
[4] Koskelainen，P.和H.Khartabil，“会议的额外要求”，正在进行的工作，2004年8月。
[5] Koskelainen, P., Schulzrinne, H., and X. Wu, "A SIP-based conference control framework", NOSSDAV 2002, Miami Beach, May 2002.
[5] Koskelainen，P.，Schulzrinne，H.，和X.Wu，“基于SIP的会议控制框架”，NOSSDAV 2002，迈阿密海滩，2002年5月。
[6] Dommel, H. and J. Garcia-Luna-Aceves, "Floor control for activity coordination in networked multimedia applications", Proc. of 2nd Asian-pacific Conference on Communications APPC, Osaka Japan, June 1995.
[6] Dommel，H.和J.Garcia Luna Aceves，“网络多媒体应用中活动协调的地板控制”，Proc。1995年6月在日本大阪举行的第二届亚太通信会议APPC。
[7] Koskelainen, P., Khartabil, H., and A. Niemi, "The Conference Policy Control Protocol (CPCP)", Work in Progress, October 2004.
[7] Koskelainen，P.，Khartabil，H.，和A.Niemi，“会议政策控制议定书（CPCP）”，正在进行的工作，2004年10月。
[8] Borman, C., Kutscher, D., Ott, J., and D. Trossen, "Simple conference control protocol service specification", Work in Progress, March 2001.
[8] Borman，C.，Kutscher，D.，Ott，J.，和D.Trossen，“简单会议控制协议服务规范”，正在进行的工作，2001年3月。
Authors' Addresses
作者地址
Petri Koskelainen Nokia 102 Corporate Park Drive White Plains, NY 10604 USA
Petri Koskelainen诺基亚公司公园大道102号，美国纽约州白平原，邮编10604
EMail: petri.koskelainen@nokia.com
EMail: petri.koskelainen@nokia.com
Joerg Ott Helsinki University of Technology Networking Laboratory Otakaari 5A 02150 Espoo Finland
赫尔辛基工业大学网络实验室OTAKARARI 5A 02150埃斯波芬兰
EMail: jo@netlab.hut.fi
EMail: jo@netlab.hut.fi
Henning Schulzrinne Columbia University 1214 Amsterdam Avenue New York 10027 USA
美国纽约阿姆斯特丹大道1214号亨宁·舒尔兹林内哥伦比亚大学10027
EMail: hgs@cs.columbia.edu
EMail: hgs@cs.columbia.edu
Xiaotao Wu Columbia University 1214 Amsterdam Avenue New York 10027 USA
美国纽约阿姆斯特丹大道1214号胡晓涛哥伦比亚大学10027
EMail: xiaotaow@cs.columbia.edu
EMail: xiaotaow@cs.columbia.edu
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）提供。