[要約] RFC 8855は、Binary Floor Control Protocol（BFCP）に関する標準化されたプロトコル仕様です。BFCPは、マルチメディア会議におけるフロア制御（画面共有やプレゼンテーションの制御）をサポートするために設計されています。BFCPは、リアルタイムのコラボレーション環境での効率的なコントロールを可能にします。
Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 8855 Ericsson
Obsoletes: 4582 K. Drage
Category: Standards Track
ISSN: 2070-1721 T. Kristensen
Jotron
J. Ott
Technical University Munich
C. Eckel
Cisco
January 2021
The Binary Floor Control Protocol (BFCP)
バイナリフロア制御プロトコル（BFCP）
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.
Floor Controlは、（マルチパーティ）会議環境で共有リソースへの共同または排他的アクセスを管理するための手段です。これにより、フロアコントロールは、他のプロトコルによって実現される会議およびメディアセッションの設定、会議ポリシーの操作、およびメディアコントロールなど、他の機能を補完する。
This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.
この文書はバイナリフロア制御プロトコル（BFCP）を指定します。BFCPは、フロア参加者とフロア制御サーバーとフロアチェア（すなわち、モデレータ）とフロアコントロールサーバーの間で使用されます。
This document obsoletes RFC 4582.
この文書はRFC 4582を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8855.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8855で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Scope
3.1. Floor Creation
3.2. Obtaining Information to Contact a Floor Control Server
3.3. Obtaining Floor-Resource Associations
3.4. Privileges of Floor Control
4. Overview of Operation
4.1. Floor Participant to Floor Control Server Interface
4.2. Floor Chair to Floor Control Server Interface
5. Packet Format
5.1. COMMON-HEADER Format
5.2. Attribute Format
5.2.1. BENEFICIARY-ID
5.2.2. FLOOR-ID
5.2.3. FLOOR-REQUEST-ID
5.2.4. PRIORITY
5.2.5. REQUEST-STATUS
5.2.6. ERROR-CODE
5.2.6.1. Error Specific Details for Error Code 4
5.2.7. ERROR-INFO
5.2.8. PARTICIPANT-PROVIDED-INFO
5.2.9. STATUS-INFO
5.2.10. SUPPORTED-ATTRIBUTES
5.2.11. SUPPORTED-PRIMITIVES
5.2.12. USER-DISPLAY-NAME
5.2.13. USER-URI
5.2.14. BENEFICIARY-INFORMATION
5.2.15. FLOOR-REQUEST-INFORMATION
5.2.16. REQUESTED-BY-INFORMATION
5.2.17. FLOOR-REQUEST-STATUS
5.2.18. OVERALL-REQUEST-STATUS
5.3. Message Format
5.3.1. FloorRequest
5.3.2. FloorRelease
5.3.3. FloorRequestQuery
5.3.4. FloorRequestStatus
5.3.5. UserQuery
5.3.6. UserStatus
5.3.7. FloorQuery
5.3.8. FloorStatus
5.3.9. ChairAction
5.3.10. ChairActionAck
5.3.11. Hello
5.3.12. HelloAck
5.3.13. Error
5.3.14. FloorRequestStatusAck
5.3.15. FloorStatusAck
5.3.16. Goodbye
5.3.17. GoodbyeAck
6. Transport
6.1. Reliable Transport
6.2. Unreliable Transport
6.2.1. Congestion Control
6.2.2. ICMP Error Handling
6.2.3. Fragmentation Handling
6.2.4. NAT Traversal
7. Lower-Layer Security
8. Protocol Transactions
8.1. Client Behavior
8.2. Server Behavior
8.3. Timers
8.3.1. Request Retransmission Timer, T1
8.3.2. Response Retransmission Timer, T2
8.3.3. Timer Values
9. Authentication and Authorization
9.1. TLS/DTLS Based Mutual Authentication
10. Floor Participant Operations
10.1. Requesting a Floor
10.1.1. Sending a FloorRequest Message
10.1.2. Receiving a Response
10.1.3. Reception of a Subsequent FloorRequestStatus Message
10.2. Cancelling a Floor Request and Releasing a Floor
10.2.1. Sending a FloorRelease Message
10.2.2. Receiving a Response
11. Chair Operations
11.1. Sending a ChairAction Message
11.2. Receiving a Response
12. General Client Operations
12.1. Requesting Information about Floors
12.1.1. Sending a FloorQuery Message
12.1.2. Receiving a Response
12.1.3. Reception of a Subsequent FloorStatus Message
12.2. Requesting Information about Floor Requests
12.2.1. Sending a FloorRequestQuery Message
12.2.2. Receiving a Response
12.3. Requesting Information about a User
12.3.1. Sending a UserQuery Message
12.3.2. Receiving a Response
12.4. Obtaining the Capabilities of a Floor Control Server
12.4.1. Sending a Hello Message
12.4.2. Receiving Responses
13. Floor Control Server Operations
13.1. Reception of a FloorRequest Message
13.1.1. Generating the First FloorRequestStatus Message
13.1.2. Generation of Subsequent FloorRequestStatus Messages
13.2. Reception of a FloorRequestQuery Message
13.3. Reception of a UserQuery Message
13.4. Reception of a FloorRelease Message
13.5. Reception of a FloorQuery Message
13.5.1. Generation of the First FloorStatus Message
13.5.2. Generation of Subsequent FloorStatus Messages
13.6. Reception of a ChairAction Message
13.7. Reception of a Hello Message
13.8. Error Message Generation
14. Security Considerations
15. IANA Considerations
15.1. Attributes Subregistry
15.2. Primitives Subregistry
15.3. Request Statuses Subregistry
15.4. Error Codes Subregistry
16. Changes from RFC 4582
16.1. Extensions for an Unreliable Transport
16.2. Other Changes
17. References
17.1. Normative References
17.2. Informative References
Appendix A. Example Call Flows for BFCP over an Unreliable
Transport
Appendix B. Motivation for Supporting an Unreliable Transport
B.1. Motivation
B.1.1. Alternatives Considered
B.1.1.1. ICE TCP
B.1.1.2. Teredo
B.1.1.3. GUT
B.1.1.4. UPnP IGD
B.1.1.5. NAT PMP
B.1.1.6. SCTP
B.1.1.7. BFCP over UDP Transport
Acknowledgements
Authors' Addresses
Within a conference, some applications need to manage the access to a set of shared resources, such as the right to send media to a particular media session. Floor control enables such applications to provide users with coordinated (shared or exclusive) access to these resources.
会議内では、特定のメディアセッションにメディアを送信する権利などの一連の共有リソースへのアクセスを管理する必要があります。Floor Controlは、そのようなアプリケーションがこれらのリソースへの調整された（共有または排他的）アクセスをユーザーに提供することを可能にします。
The Requirements for Floor Control Protocol [18] list a set of requirements that need to be met by floor control protocols. The Binary Floor Control Protocol (BFCP), which is specified in this document, meets these requirements.
フロアコントロールプロトコルの要件[18]は、フロアコントロールプロトコルによって満たす必要がある一連の要件をリストしています。この文書で指定されているバイナリフロアコントロールプロトコル（BFCP）は、これらの要件を満たしています。
In addition, BFCP has been designed so that it can be used in low-bandwidth environments. The binary encoding used by BFCP achieves a small message size (when message signatures are not used) that keeps the time it takes to transmit delay-sensitive BFCP messages to a minimum. Delay-sensitive BFCP messages include FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It is expected that future extensions to these messages will not increase the size of these messages in a significant way.
さらに、BFCPは低帯域幅環境で使用できるように設計されています。BFCPによって使用されるバイナリエンコーディングは、遅延機密BFCPメッセージを最小に送信するのにかかる時間を維持する時間を保持する小さなメッセージサイズ（メッセージ署名が使用されない場合）を達成します。遅延機密BFCPメッセージには、FLOOREQUEST、FLOEREREASE、FLOOREQUESTSTATUS、および企業が含まれます。これらのメッセージに対する将来の拡張は、これらのメッセージのサイズを大きな方法で増やすことは予想されます。
The remainder of this document is organized as follows: Section 2 defines the terminology used throughout this document, Section 3 discusses the scope of BFCP (i.e., which tasks fall within the scope of BFCP and which ones are performed using different mechanisms), Section 4 provides a non-normative overview of BFCP operation. The subsequent sections provide the normative specification of BFCP. Section 16 summarizes changes from RFC 4582 [3].
この文書の残りの部分は次のように編成されています。セクション3では、セクション3はBFCPの範囲について説明します（つまり、どのタスクがBFCPの範囲内にあり、異なるメカニズムを使用して実行されているもの）。BFCP操作の非規範的な概要を提供します。後続のセクションでは、BFCPの規範的指定を提供します。セクション16はRFC 4582からの変更を要約しています[3]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [1] [10] when, and only when, they appear in all capitals, as shown here.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [1] [10]に記載されているように解釈されるべきであり、ここに示すように、すべての首都に表示されます。
Media Participant: An entity that has access to the media resources of a conference (e.g., it can receive a media stream). In floor-controlled conferences, a given media participant is typically co-located with a floor participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are not co-located. The protocol between a floor participant and a media participant (that are not co-located) is outside the scope of this document.
メディア参加者：会議のメディアリソースにアクセスできるエンティティ（例えば、メディアストリームを受信することができる）。床制御会議では、特定のメディア参加者は通常、床の参加者と同じ場所にありますが、それはそうである必要はありません。サードパーティの階の要求は、床参加者が共有されていないときにメディア参加者のための床を要求することから成ります。フロア参加者とメディア参加者との間のプロトコルは、この文書の範囲外です。
Client: A floor participant or a floor chair that communicates with a floor control server using BFCP.
クライアント：BFCPを使用してフロアコントロールサーバーと通信するフロア参加者またはフロアチェア。
Floor: A temporary permission to access or manipulate a specific shared resource or set of resources.
Floor：特定の共有リソースまたはリソースのセットにアクセスまたは操作するための一時的な許可。
Floor Chair: A logical entity that manages one floor (grants, denies, or revokes a floor). An entity that assumes the logical role of a floor chair for a given transaction may assume a different role (e.g., floor participant) for a different transaction. The roles of floor chair and floor participant are defined on a transaction-by-transaction basis. BFCP transactions are defined in Section 8.
フロアチェア：1階（補助金、否定、または床を取り消す）を管理する論理的なエンティティ。特定の取引のための床椅子の論理的役割を仮定するエンティティは、異なる取引のために異なる役割（例えば、フロア参加者）を想定することができる。フロアチェアとフロア参加者の役割は、トランザクションごとに定義されています。BFCPトランザクションはセクション8で定義されています。
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. The floor control server of a conference may perform other logical roles (e.g., floor participant) in another conference.
フロアコントロールサーバー：フロアが存在するフロアが存在するフロアの状態を維持する論理エンティティは、床を保持します。会議のフロア制御サーバは、他の会議で他の論理的役割（例えば、フロア参加者）を実行することができる。
Floor Participant: A logical entity that requests floors, and possibly information about them, from a floor control server. An entity that assumes the logical role of a floor participant for a given transaction may assume a different role (e.g., a floor chair) for a different transaction. The roles of floor participant and floor chair are defined on a transaction-by-transaction basis. BFCP transactions are defined in Section 8. In floor-controlled conferences, a given floor participant is typically co-located with a media participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are not co-located.
フロア参加者：フロアを要求する論理エンティティ、そしておそらくそれらについての情報は、フロアコントロールサーバーから情報を提供します。所与の取引のための階の参加者の論理的役割を仮定するエンティティは、異なる取引のための異なる役割（例えば床議長）をとることがある。フロア参加者と階の椅子の役割は、トランザクションごとに定義されています。BFCPトランザクションはセクション8で定義されています。フロアコントロールの会議では、特定のフロア参加者は通常メディア参加者と同じ場所にありますが、そうである必要はありません。サードパーティの階の要求は、床参加者が共有されていないときにメディア参加者のための床を要求することから成ります。
Participant: An entity that acts as a floor participant, as a media participant, or as both.
参加者：メディアの参加者として、または両方として、フロア参加者として機能するエンティティ。
BFCP Connection: A transport association between BFCP entities, used to exchange BFCP messages.
BFCP接続：BFCPメッセージを交換するために使用されるBFCPエンティティ間のトランスポートアソシエーション。
Transaction Failure Window: When communicating over an unreliable transport, this is some period of time less than or equal to T1*2^(4) (see Section 8.3). For reliable transports, this period of time is unbounded.
トランザクションの障害ウィンドウ：信頼性の低いトランスポートで通信するときは、これはT1 * 2 ^（4）以下の期間です（セクション8.3を参照）。信頼できる輸送のために、この期間は無制限です。
As stated earlier, BFCP is a protocol to coordinate access to shared resources in a conference following the requirements defined in [18]. Floor control complements other functions defined in the Centralized Conferencing (XCON) Framework [19]. The floor control protocol BFCP defined in this document only specifies a means to arbitrate access to floors. The rules and constraints for floor arbitration and the results of floor assignments are outside the scope of this document and are defined by other protocols [19].
前述のように、BFCPは[18]で定義された要件に続く会議で共有リソースへのアクセスを調整するためのプロトコルです。フロアコントロールは、集中会議（XCON）フレームワークで定義されているその他の機能を補完します[19]。この文書で定義されているフロア制御プロトコルBFCPは、フロアへのアクセスを調停するための手段のみを指定します。フロア調停の規則と制約と階配の結果はこの文書の範囲外であり、他のプロトコルで定義されています[19]。
Figure 1 shows the tasks that BFCP can perform.
図1は、BFCPが実行できるタスクを示しています。
+---------+
| Floor |
| Chair |
| |
+---------+
^ |
| |
Notification | | Decision
| |
| |
Floor | v
+-------------+ Request +---------+ +-------------+
| Floor |----------->| Floor | Notification | Floor |
| Participant | | Control |------------->| Participant |
| |<-----------| Server | | |
+-------------+ Granted or +---------+ +-------------+
Denied
Figure 1: Functionality provided by BFCP
図1：BFCPによって提供される機能
BFCP provides a means:
BFCPは手段を提供します。
* for floor participants to send floor requests to floor control servers.
* フロアリクエストをフロアコントロールサーバーに送信するための床参加者のための。
* for floor control servers to grant or deny requests to access a given resource from floor participants.
* フロアコントロールサーバーの場合は、床参加者から特定のリソースにアクセスする要求を付与または拒否します。
* for floor chairs to send floor control servers decisions regarding floor requests.
* フロアチェアの場合は、フロアコントロールサーバーを送信します。
* for floor control servers to keep floor participants and floor chairs informed about the status of a given floor or a given floor request.
* フロアコントロールサーバーの場合は、床の参加者や床の椅子を保管して、特定の床や特定の床の要求の状況について知らされています。
Even though tasks that do not belong to the previous list are outside the scope of BFCP, some of these out-of-scope tasks relate to floor control and are essential for creating floors and establishing BFCP connections between different entities. In the following subsections, we discuss some of these tasks and mechanisms to perform them.
前のリストに属していないタスクはBFCPの範囲外であっても、これらの範囲外のタスクのいくつかはフロアコントロールに関連しており、フロアを作成し、異なるエンティティ間のBFCP接続の確立に不可欠です。以下のサブセクションでは、これらのタスクとメカニズムのいくつかについて説明します。
The association of a given floor with a resource or a set of resources (e.g., media streams) is out of the scope of BFCP as described in [19]. Floor creation and termination are also outside the scope of BFCP; these aspects are handled using the conference control protocol for manipulating the conference object. Consequently, the floor control server needs to stay up to date on changes to the conference object (e.g., when a new floor is created).
所与の床とリソースまたは一連のリソース（例えば、メディアストリーム）の関連付けは、[19]に記載されているようにBFCPの範囲外である。床の創造と終了もBFCPの範囲外です。これらの側面は、会議オブジェクトを操作するための会議制御プロトコルを使用して処理されます。その結果、フロア制御サーバは会議オブジェクトへの変更点（例えば、新しい階が作成されたとき）に最新の状態に保つ必要がある。
Conference control clients using Centralized Conferencing Manipulation Protocol (CCMP) [23] can specify such floor-related settings in the <floor-information> element [22] of the to-be created conference object provided in the body of a CCMP confRequest/create message issued to the conference control server.
集中化会議操作プロトコル（CCMP）を使用した会議管理クライアント[23] CCMP CONFREQUEST / CREATEの本文に記載されている作成会議オブジェクトの<Floor-Information> Element [22]にそのようなフロア関連の設定を指定できます。会議管理サーバーに発行されたメッセージ。
A client needs a set of data in order to establish a BFCP connection to a floor control server. These data include the transport address of the server, the conference identifier, and a user identifier.
フロア制御サーバへのBFCP接続を確立するためにクライアントが一連のデータを必要とする。これらのデータは、サーバのトランスポートアドレス、会議識別子、およびユーザ識別子を含む。
Clients can obtain this information in different ways. One is to use a Session Description Protocol (SDP) offer/answer [17] exchange, which is described in [12]. How to establish a connection to a BFCP floor control server is outside the context of an offer/answer exchange when using a reliable transport is described in [4]. Other mechanisms are described in the XCON Framework [19] (and other related documents). For unreliable transports, the use of an SDP offer/answer exchange is the only specified mechanism.
クライアントはこの情報をさまざまな方法で入手できます。1つは、[12]に記載されているセッション記述プロトコル（SDP）オファー/アンサー[17] Exchangeを使用することです。BFCPフロアコントロールサーバーへの接続を確立する方法信頼できるトランスポートを使用する場合は、オファー/回答交換のコンテキスト外にあります[4]。他のメカニズムは、XCON Framework [19]（および他の関連文書）に記載されています。信頼できない輸送のために、SDPオファー/回答Exchangeの使用は指定されたメカニズムのみです。
Floors are associated with resources. For example, a floor that controls who talks at a given time has a particular audio session as its associated resource. Associations between floors and resources are part of the conference object.
フロアはリソースに関連付けられています。たとえば、特定の時点で誰が話をするかを制御するフロアは、その関連リソースとして特定のオーディオセッションを持ちます。フロアとリソース間の関連付けは会議オブジェクトの一部です。
Floor participants and floor chairs need to know which resources are associated with which floors. They can obtain this information by using different mechanisms, such as an SDP offer/answer [17] exchange. How to use an SDP offer/answer exchange to obtain these associations is described in [12].
床の参加者や床の椅子は、どのリソースがどの階に関連するかを知る必要があります。それらは、SDPオファー/アンサー[17]交換など、さまざまなメカニズムを使用してこの情報を取得できます。SDPオファー/回答Exchangeを使用してこれらの関連付けを取得する方法は[12]に記載されています。
| Note that floor participants perform SDP offer/answer exchanges
| with the conference focus of the conference. So, the
| conference focus needs to obtain information about associations
| between floors and resources in order to be able to provide
| this information to a floor participant in an SDP offer/answer
| exchange.
Other mechanisms for obtaining this information, including discussion of how the information is made available to a (SIP) focus, are described in the XCON Framework [19] (and other related documents). According to the conferencing system policies, conference control clients using CCMP [23] can modify the floor settings of a conference by issuing CCMP confRequest/update messages providing the specific updates to the <floor-information> element of the target conference object. More information about CCMP and BFCP interaction can be found in [24].
情報を（SIP）フォーカスで利用できるようにする方法を考慮して、この情報を取得するための他のメカニズムは、XCONフレームワーク[19]（および他の関連文書）に記載されている。会議システムポリシーによると、CCMP [23]を使用している会議管理クライアントは、ターゲット会議オブジェクトの<floor-information>要素に特定の更新を提供するCCMP Confrequest / Updateメッセージを発行することで、会議のフロア設定を変更できます。CCMPとBFCPの対話に関する追加情報は[24]にあります。
A participant whose floor request is granted has the right to use the resource or resources associated with the floor that was requested. For example, the participant may have the right to send media over a particular audio stream.
床の要求が付与されている参加者は、要求されたフロアに関連するリソースまたはリソースを使用する権利を有する。例えば、参加者は特定のオーディオストリームを介してメディアを送信する権利を有することができる。
Nevertheless, holding a floor does not imply that others will not be able to use its associated resources at the same time, even if they do not have the right to do so. Determination of which media participants can actually use the resources in the conference is discussed in the XCON Framework [19].
それにもかかわらず、床を保持しているのは、他の人が同時にそれを実行する権利を持っていなくても、他の人が同時にその関連資源を使用できないことを意味するものではありません。どのメディア参加者が実際に会議のリソースを使用できるかの決定については、XCON Framework [19]で説明されています。
This section provides a non-normative description of BFCP operations. Section 4.1 describes the interface between floor participants and floor control servers, and Section 4.2 describes the interface between floor chairs and floor control servers.
このセクションでは、BFCP操作の非規範的な説明を示します。セクション4.1では、フロア参加者とフロアコントロールサーバーの間のインタフェースを示し、セクション4.2はフロアチェアとフロアコントロールサーバーの間のインタフェースを示しています。
BFCP messages, which use a TLV (Type-Length-Value) binary encoding, consist of a COMMON-HEADER followed by a set of attributes. The COMMON-HEADER contains, among other information, a 32-bit conference identifier. Floor participants, media participants, and floor chairs are identified by 16-bit user identifiers.
TLV（Type-Length-Value）バイナリエンコーディングを使用するBFCPメッセージは、共通ヘッダーとそれに続く一連の属性で構成されています。共通ヘッダには、とりわけ32ビットの会議識別子が含まれています。フロア参加者、メディア参加者、およびフロアチェアは、16ビットのユーザー識別子によって識別されます。
BFCP supports nested attributes (i.e., attributes that contain attributes). These are referred to as grouped attributes.
BFCPはネストされた属性をサポートしています（すなわち、属性を含む属性）。これらはグループ化された属性と呼ばれます。
There are two types of transactions in BFCP: client-initiated transactions and server-initiated transactions. Section 8 describes both types of transactions in detail.
BFCPには、クライアントが開始したトランザクションおよびサーバー開始トランザクションには、2種類のトランザクションがあります。セクション8では、両方のタイプのトランザクションを詳細に説明します。
Floor participants request a floor by sending a FloorRequest message to the floor control server. BFCP supports third-party floor requests. That is, the floor participant sending the floor request need not be co-located with the media participant that will get the floor once the floor request is granted. FloorRequest messages carry the identity of the requester in the User ID field of the COMMON-HEADER, and the identity of the beneficiary of the floor (in third-party floor requests) in a BENEFICIARY-ID attribute.
Floor Control ServerにFloorRequestメッセージを送信することで、フロア参加者が階をリクエストしてください。BFCPはサードパーティの階の要求をサポートしています。すなわち、床の要求を送信するフロア参加者は、床の要求が与えられた後に床を得るためのメディア参加者と同じ場所に配置される必要はない。FloareRequestメッセージは、共通ヘッダーのユーザーIDフィールド、および受益者ID属性のフロアの受益者の識別情報を持ちます。
| Third-party floor requests can be sent, for example, by floor
| participants that have a BFCP connection to the floor control
| server but that are not media participants (i.e., they do not
| handle any media).
FloorRequest messages identify the floor or floors being requested by carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a FloorRequest message carries more than one floor identifier, the floor control server treats all the floor requests as an atomic package. That is, the floor control server either grants or denies all the floors in the FloorRequest message.
FloareRequestメッセージFloor-ID属性で16ビットのフロア識別子を搬送することで、要求されている階または階を識別します。FloorRequestメッセージが複数のフロア識別子を搬送する場合、Floor Controlサーバーはすべての階の要求をアトミックパッケージとして扱います。つまり、フロアコントロールサーバーはFloorRequestメッセージ内のすべてのフロアを付与または拒否します。
Floor control servers respond to FloorRequest messages with FloorRequestStatus messages, which provide information about the status of the floor request. The first FloorRequestStatus message is the response to the FloorRequest message from the client, and therefore has the same Transaction ID as the FloorRequest.
Floor ControlサーバーはFloorRequestStatusメッセージを使用したFloorRequestメッセージに応答します。これは、フロア要求のステータスに関する情報を提供します。最初のFloarRequestStatusメッセージは、クライアントからFloareRequestメッセージに対する応答であり、したがってFloorRequestと同じトランザクションIDを持ちます。
Additionally, the first FloorRequestStatus message carries the Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent FloorRequestStatus messages related to the same floor request will carry the same Floor Request ID. This way, the floor participant can associate them with the appropriate floor request.
さらに、最初のFloarRequestStatusメッセージは、フロア要求情報属性にフロア要求IDを搬送します。同じフロア要求に関連するその後のFloorQuestStatusメッセージは、同じフロア要求IDを運びます。このようにして、フロア参加者はそれらを適切な階の要求に関連付けることができます。
Messages from the floor participant related to a particular floor request also use the same Floor Request ID as the first FloorRequestStatus message from the floor control server.
特定のフロア要求に関連するフロア参加者からのメッセージは、フロアコントロールサーバーからの最初のFloheRequestStatusメッセージとして同じフロアリクエストIDも使用します。
Figure 2 and Figure 3 show examples of call flows where BFCP is used over a reliable transport. Appendix A shows the same call flow examples using an unreliable transport.
図2および図3は、BFCPが信頼できるトランスポートで使用されているコールフローの例を示しています。付録Aは、信頼性の低いトランスポートを使用しているのと同じコールフローの例を示しています。
Figure 2 shows how a floor participant requests a floor, obtains it, and, at a later time, releases it. This figure illustrates the use, among other things, of the Transaction ID and the FLOOR-REQUEST-ID attribute.
図2は、フロア参加者が床にどのように要求し、それを取得し、後で解放するかを示しています。この図は、トランザクションIDとfloor-request-id属性の使用方法を示しています。
Floor Participant Floor Control
Server
|(1) FloorRequest |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorRequestStatus |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Pending |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(3) FloorRequestStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(4) FloorRequestStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(5) FloorRelease |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->|
| |
|(6) FloorRequestStatus |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Released |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
Figure 2: Requesting and releasing a floor
図2：フロアの要求と解放
Figure 3 shows how a floor participant requests to be informed on the status of a floor. The first FloorStatus message from the floor control server is the response to the FloorQuery message and, as such, has the same Transaction ID as the FloorQuery message.
図3は、フロアの参加者がフロアのステータスについてどのように通知されるかを示しています。Floor Controlサーバーからの最初のORORSTATUSメッセージは、ForeoQueryメッセージに対する応答であり、そのため、Forequeryメッセージと同じトランザクションIDを持ちます。
Subsequent FloorStatus messages consist of server-initiated transactions, and therefore their Transaction ID is 0 given this example uses a reliable transport. FloorStatus message (2) indicates that there are currently two floor requests for the floor whose Floor ID is 543. FloorStatus message (3) indicates that the floor requests with Floor Request ID 764 has been granted, and the floor request with Floor Request ID 635 is the first in the queue. FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has been granted.
後続のFloorStatusメッセージはサーバー開始トランザクションで構成されているため、この例では信頼できるトランスポートを使用していますが、トランザクションIDは0です。FloorStatusメッセージ（2）フロアIDが543のフロアの2つの階の要求があることを示します.HOORESTATUSメッセージ（3）フロアリクエストID 764のフロア要求が付与されていること、およびフロアリクエストID 635のフロアリクエストがあることを示します。キューの最初のものです。FloorStatusメッセージ（4）は、フロアリクエストID 635のフロア要求が許可されていることを示します。
Floor Participant Floor Control
Server
|(1) FloorQuery |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorStatus |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 2nd |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(3) FloorStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(4) FloorStatus |
|Transaction ID: 0 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
Figure 3: Obtaining status information about a floor
図3：フロアに関するステータス情報の取得
FloorStatus messages contain information about the floor requests they carry. For example, FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has as the beneficiary (i.e., the participant that holds the floor when a particular floor request is granted) the participant whose User ID is 154. The floor request applies only to the floor whose Floor ID is 543. That is, this is not a multi-floor floor request.
FloorStatusメッセージには、キャリングされている床の要求に関する情報が含まれています。たとえば、FloorStatusメッセージ（4）は、フロアリクエストID 635のフロア要求が受益者として（すなわち、特定のフロア要求が付与されたときに階を保持する参加者）が154であることを示す。床IDが543の床にのみ適用されます。つまり、これは多床の床の要求ではありません。
| A multi-floor floor request applies to more than one floor
| (e.g., a participant wants to be able to speak and write on the
| whiteboard at the same time). The floor control server treats
| a multi-floor floor request as an atomic package. That is, the
| floor control server either grants the request for all floors
| or denies the request for all floors.
Figure 4 shows a floor chair instructing a floor control server to grant a floor.
図4は、フロアコントロールサーバーに床を付与するように指示する床椅子を示しています。
| Note, however, that although the floor control server needs to
| take into consideration the instructions received in
| ChairAction messages (e.g., granting a floor), it does not
| necessarily need to perform them exactly as requested by the
| floor chair. The operation that the floor control server
| performs depends on the ChairAction message and on the internal
| state of the floor control server.
For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well. In another example, a floor chair may instruct the floor control server to grant a floor to a participant. The floor control server needs to revoke the floor from its current holder before granting it to the new participant.
例えば、フロアチェアは、いくつかの階を含む原子床依頼運転の一部として要求された床を付与する議長メッセージを送ることができる。いずれかのフロアを担当する議長がフロアコントロールサーバーに床を付与するように指示したとしても、フロアコントロールサーバーは他の階に責任がある議長がそれらを許可することに同意するまでそれを許可しません。別の例では、床の椅子は、参加者に床を付与するようにフロア制御サーバに指示することができる。Floor Controlサーバーは、新しい参加者に付与する前に、現在のホルダーからフロアを取り消す必要があります。
So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state.
したがって、フロアコントロールサーバーは、この状態への入力として、フロアチェアからの命令を使用してコヒーレントなフロア状態を保つために最終的に責任があります。
Floor Chair Floor Control
Server
|(1) ChairAction |
|Transaction ID: 769 |
|User ID: 357 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| Request Status: Granted |
|---------------------------------------------->|
| |
|(2) ChairActionAck |
|Transaction ID: 769 |
|User ID: 357 |
|<----------------------------------------------|
Figure 4: Chair instructing the floor control server
図4：フロア制御サーバに指示する議長
BFCP packets consist of a 12-octet COMMON-HEADER followed by attributes. All the protocol values MUST be sent in network byte order.
BFCPパケットは、12オクテット共通ヘッダーとそれに続く属性で構成されています。すべてのプロトコル値はネットワークバイト順に送信する必要があります。
The following is the format of the COMMON-HEADER.
以下は共通ヘッダーのフォーマットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |R|F| Res | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID |
+> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Fragment Offset (if F is set) | Fragment Length (if F is set) |
+> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+---- These fragment fields are never present
when using reliable transports
Figure 5: COMMON-HEADER format
図5：共通ヘッダーフォーマット
Ver: This 3-bit field defines the version of BFCP to which this message adheres. This specification defines two versions: 1 and 2. The version field MUST be set to 1 when using BFCP over a reliable transport. The version field MUST be set to 2 when using BFCP over an unreliable transport. If a floor control server receives a message with an unsupported version field value or a message with a version number that is not permitted with the transport over which it was received, the server MUST indicate it does not support the protocol version by sending an Error message with parameter value 12 (Unsupported Version). Note that BFCP entities supporting only the [3] subset will not support this parameter value.
Ver：この3ビットフィールドは、このメッセージが付加するBFCPのバージョンを定義します。この仕様は2つのバージョンを定義します.1と2.バージョンフィールドは、信頼できるトランスポートでBFCPを使用する場合は1に設定する必要があります。信頼性の低いトランスポートでBFCPを使用する場合は、バージョンフィールドを2に設定する必要があります。フロアコントロールサーバーがサポートされていないバージョンフィールド値またはメッセージを受信したトランスポートで許可されていないバージョン番号を持つメッセージを受信した場合、サーバーはエラーメッセージを送信してプロトコルバージョンをサポートしていないことを示している必要があります。パラメータ値12（サポートされていないバージョン）を使用します。[3]サブセットのみをサポートするBFCPエンティティはこのパラメータ値をサポートしません。
R: The Transaction Responder (R) flag bit has relevance only for use of BFCP over an unreliable transport. When cleared, it indicates that this message is a request initiating a new transaction, and the Transaction ID that follows has been generated for this transaction. When set, it indicates that this message is a response to a previous request, and the Transaction ID that follows is the one associated with that request. When BFCP is used over a reliable transport, the flag has no significance and MUST be cleared by the sender and MUST be ignored by the receiver.
R：トランザクションレスポンダ（R）フラグビットは、信頼性の低いトランスポートでのBFCPの使用にのみ関連性を持ちます。クリアされると、このメッセージが新しいトランザクションを開始するリクエストであり、次のトランザクションIDがこのトランザクションに対して生成されたことを示します。設定すると、このメッセージが前の要求に対する応答であることを示し、続くトランザクションIDはその要求に関連付けられているものです。BFCPが信頼できるトランスポートで使用されるとき、フラグは重要ではなく、送信者によってクリアされなければならず、受信者によって無視される必要があります。
F: The Fragmentation (F) flag bit has relevance only for use of BFCP over an unreliable transport. When cleared, the message is not fragmented. When set, it indicates that the message is a fragment of a large, fragmented BFCP message. (The optional fields Fragment Offset and Fragment Length described below are present only if the F flag is set). When BFCP is used over a reliable transport, the flag has no significance and MUST be cleared by the sender, and the flag MUST be ignored by the receiver. In the latter case, the receiver should also ignore the Fragment Offset and Fragment Length fields when processing the COMMON-HEADER.
f：フラグメンテーション（f）フラグビットは、信頼性の低いトランスポートでのBFCPの使用のための関連性を有する。クリアすると、メッセージは断片化されていません。設定すると、メッセージが大きくて断片化されたBFCPメッセージのフラグメントであることを示します。（以下のオプションのフィールドのフラグメントオフセットとフラグメント長は、fフラグが設定されている場合にのみ存在します）。BFCPが信頼できるトランスポートで使用されるとき、フラグは重要ではなく、送信者によってクリアされなければならず、そしてフラグは受信者によって無視されなければなりません。後者の場合、受信機は、共通ヘッダを処理するときにフラグメントオフセットフィールドとフラグメント長フィールドも無視する必要があります。
Res: The 3 bits in the reserved field MUST be set to zero by the sender of the message and MUST be ignored by the receiver.
res：予約フィールドの3ビットはメッセージの送信者によってゼロに設定されなければならず、受信者によって無視される必要があります。
Primitive: This 8-bit field identifies the main purpose of the message. The following primitive values are defined:
プリミティブ：この8ビットフィールドは、メッセージの主な目的を識別します。次のプリミティブ値が定義されています。
+=======+=======================+====================+
| Value | Primitive | Direction |
+=======+=======================+====================+
| 1 | FloorRequest | P -> S |
+-------+-----------------------+--------------------+
| 2 | FloorRelease | P -> S |
+-------+-----------------------+--------------------+
| 3 | FloorRequestQuery | P -> S ; Ch -> S |
+-------+-----------------------+--------------------+
| 4 | FloorRequestStatus | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+
| 5 | UserQuery | P -> S ; Ch -> S |
+-------+-----------------------+--------------------+
| 6 | UserStatus | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+
| 7 | FloorQuery | P -> S ; Ch -> S |
+-------+-----------------------+--------------------+
| 8 | FloorStatus | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+
| 9 | ChairAction | Ch -> S |
+-------+-----------------------+--------------------+
| 10 | ChairActionAck | Ch <- S |
+-------+-----------------------+--------------------+
| 11 | Hello | P -> S ; Ch -> S |
+-------+-----------------------+--------------------+
| 12 | HelloAck | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+
| 13 | Error | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+
| 14 | FloorRequestStatusAck | P -> S ; Ch -> S |
+-------+-----------------------+--------------------+
| 15 | FloorStatusAck | P -> S ; Ch -> S |
+-------+-----------------------+--------------------+
| 16 | Goodbye | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+
| 17 | GoodbyeAck | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+
| S: Floor Control Server |
| P: Floor Participant |
| Ch: Floor Chair |
+----------------------------------------------------+
Table 1: BFCP primitives
表1：BFCPプリミティブ
Payload Length: This 16-bit field contains the length of the message in 4-octet units, excluding the COMMON-HEADER. If a floor control server receives a message with an incorrect Payload Length field value, the receiving server MUST send an Error message with parameter value 13 (Incorrect Message Length) to indicate this and then discard the message. Other entities that receive a message with an incorrect length MUST discard the message.
ペイロード長：この16ビットフィールドには、共通ヘッダーを除く4オクテット単位のメッセージの長さが含まれています。フロアコントロールサーバーが誤ったペイロード長フィールド値を持つメッセージを受信した場合、受信側サーバーはパラメータ値13（誤ったメッセージ長）を持つエラーメッセージを送信し、メッセージを破棄する必要があります。誤った長さのメッセージを受信する他のエンティティはメッセージを破棄しなければなりません。
| Note: BFCP is designed to achieve small message size, as
| explained in Section 1, and BFCP entities are REQUIRED to keep
| the BFCP message size smaller than the size limited by the
| 16-bit Payload Length field. To convey information not
| strictly related to floor control, other protocols should be
| used, such as the XCON Framework (cf. Section 3).
Conference ID: This 32-bit unsigned integer field identifies the conference to which the message belongs. It is RECOMMENDED that the conference identifier be randomly chosen. (Note that the use of predictable conference identifiers in conjunction with a nonsecure transport protocol makes BFCP susceptible to off-path data injection attacks, where an attacker can forge a request or response message.)
会議ID：この32ビットunsigned整数フィールドは、メッセージが属する会議を識別します。会議識別子がランダムに選択されることをお勧めします。（非セキュアトランスポートプロトコルと組み合わせた予測可能な会議識別子の使用は、攻撃者が要求または応答メッセージを偽造できるように、BFCPをオフパスデータ注入攻撃を受けやすくします。）
Transaction ID: This field contains a 16-bit value that allows users to match a given message with its response (see Section 8).
トランザクションID：このフィールドには、ユーザーが特定のメッセージとその応答を一致させることができる16ビット値が含まれています（セクション8を参照）。
User ID: This field contains a 16-bit unsigned integer that uniquely identifies a participant within a conference.
ユーザーID：このフィールドには、会議内の参加者を一意に識別する16ビットの符号なし整数が含まれています。
| The identity used by a participant in BFCP, which is carried in
| the User ID field, is generally mapped to the identity used by
| the same participant in the session establishment protocol
| (e.g., in SIP). The way this mapping is performed is outside
| the scope of this specification.
Fragment Offset: This optional field is present only if the F flag is set and contains a 16-bit value that specifies the number of 4-octet units contained in previous fragments, excluding the COMMON-HEADER.
フラグメントオフセット：このオプションフィールドは、Fフラグが設定されている場合にのみ存在し、共通ヘッダーを除く以前のフラグメントに含まれる4オクテット単位の数を指定する16ビット値を含みます。
Fragment Length: This optional field is present only if the F flag is set and contains a 16-bit value that specifies the number of 4-octet units contained in this fragment, excluding the COMMON-HEADER. BFCP entities that receive message fragments that, individually or collectively, exceed the Payload Length value MUST discard the message. Additionally, if the receiver is a floor control server, it MUST also send an Error message with parameter value 13 (Incorrect Message Length)
フラグメント長：このオプションフィールドは、fフラグが設定されており、共通ヘッダーを除くこのフラグメントに含まれる4オクテット単位の数を指定する16ビット値を含む場合にのみ存在します。個別にまたはまとめてペイロード長の値を超えるメッセージフラグメントを受信するBFCPエンティティは、メッセージを破棄する必要があります。さらに、受信機がフロア制御サーバーである場合は、パラメータ値13でエラーメッセージも送信する必要があります（メッセージ長が正しくありません）。
BFCP attributes are encoded in TLV (Type-Length-Value) format. Attributes are 32-bit aligned.
BFCP属性はTLV（type-length-value）形式でエンコードされています。属性は32ビット整列しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Attribute Contents /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Attribute format
図6：属性フォーマット
Type: This 7-bit field contains the type of the attribute. Each attribute, identified by its type, has a particular format. The attribute formats defined are:
型：この7ビットフィールドには属性の型が含まれています。各属性は、そのタイプによって識別され、特定の形式があります。定義された属性フォーマットは次のとおりです。
Unsigned16: The contents of the attribute consist of a 16-bit unsigned integer.
unsigned16：属性の内容は16ビットの符号なし整数で構成されています。
OctetString16: The contents of the attribute consist of 16 bits of arbitrary data.
OctetString16：属性の内容は16ビットの任意のデータで構成されています。
OctetString: The contents of the attribute consist of arbitrary data of variable length.
OctetString：属性の内容は、可変長の任意のデータで構成されています。
Grouped: The contents of the attribute consist of a sequence of attributes.
グループ化：属性の内容は一連の属性で構成されています。
| Note that extension attributes defined in the future may define | new attribute formats.
The following attribute types are defined:
次の属性タイプが定義されています。
+======+===========================+===============+
| Type | Attribute | Format |
+======+===========================+===============+
| 1 | BENEFICIARY-ID | Unsigned16 |
+------+---------------------------+---------------+
| 2 | FLOOR-ID | Unsigned16 |
+------+---------------------------+---------------+
| 3 | FLOOR-REQUEST-ID | Unsigned16 |
+------+---------------------------+---------------+
| 4 | PRIORITY | OctetString16 |
+------+---------------------------+---------------+
| 5 | REQUEST-STATUS | OctetString16 |
+------+---------------------------+---------------+
| 6 | ERROR-CODE | OctetString |
+------+---------------------------+---------------+
| 7 | ERROR-INFO | OctetString |
+------+---------------------------+---------------+
| 8 | PARTICIPANT-PROVIDED-INFO | OctetString |
+------+---------------------------+---------------+
| 9 | STATUS-INFO | OctetString |
+------+---------------------------+---------------+
| 10 | SUPPORTED-ATTRIBUTES | OctetString |
+------+---------------------------+---------------+
| 11 | SUPPORTED-PRIMITIVES | OctetString |
+------+---------------------------+---------------+
| 12 | USER-DISPLAY-NAME | OctetString |
+------+---------------------------+---------------+
| 13 | USER-URI | OctetString |
+------+---------------------------+---------------+
| 14 | BENEFICIARY-INFORMATION | Grouped |
+------+---------------------------+---------------+
| 15 | FLOOR-REQUEST-INFORMATION | Grouped |
+------+---------------------------+---------------+
| 16 | REQUESTED-BY-INFORMATION | Grouped |
+------+---------------------------+---------------+
| 17 | FLOOR-REQUEST-STATUS | Grouped |
+------+---------------------------+---------------+
| 18 | OVERALL-REQUEST-STATUS | Grouped |
+------+---------------------------+---------------+
Table 2: BFCP attributes
表2：BFCP属性
M: The 'M' bit, known as the Mandatory bit, indicates whether support of the attribute is REQUIRED. If a floor control server receives an unrecognized attribute with the 'M' bit set, the server MUST send an Error message with parameter value 4 (Unknown Mandatory Attribute) to indicate this. The 'M' bit is significant for extension attributes defined in other documents only. All attributes specified in this document MUST be understood by the receiver so that the setting of the 'M' bit is irrelevant for these. Unrecognized attributes, such as those that might be specified in future extensions, that do not have the 'M' bit set are ignored, but the message is processed.
M：必須ビットとして知られる「M」ビットは、属性のサポートが必要かどうかを示します。Floor Controlサーバーが 'M'ビットセットを使用して認識されない属性を受信した場合、サーバーはパラメータ値4（不明な必須属性）を持つエラーメッセージを送信する必要があります。'm'ビットは、他の文書でのみ定義されている拡張属性には重要です。この文書で指定されているすべての属性は、「M」ビットの設定はこれらには無関係であるように受信機によって理解されなければなりません。M 'ビットセットを持たない将来の拡張機能で指定されている可能性のあるものなど、認識されていない属性は無視されますが、メッセージは処理されます。
Length: This 8-bit field contains the length of the attribute in octets, excluding any padding defined for specific attributes. The length of attributes that are not grouped includes the Type, 'M' bit, and Length fields. The Length in grouped attributes is the length of the grouped attribute itself (including Type, 'M' bit, and Length fields) plus the total length (including padding) of all the included attributes.
長さ：この8ビットフィールドには、特定の属性に定義されている任意のパディングを除く、オクテット内の属性の長さが含まれています。グループ化されていない属性の長さには、タイプ、 'M'ビット、および長さフィールドが含まれます。グループ化された属性の長さは、グループ化された属性自体の長さ（型、M 'ビット、および長さフィールドを含む）と、含まれているすべての属性の合計長（パディングを含む）を加えています。
Attribute Contents: The contents of the different attributes are defined in the following sections.
属性内容：さまざまな属性の内容は、次のセクションで定義されています。
The following is the format of the BENEFICIARY-ID attribute.
以下は、受取人ID属性のフォーマットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: BENEFICIARY-ID format
図7：受益者ID形式
Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference.
受益者ID：このフィールドには、会議内のユーザーを一意に識別する16ビット値が含まれています。
| Note that although the formats of the Beneficiary ID and of the
| User ID field in the COMMON-HEADER are similar, their semantics
| are different. The Beneficiary ID is used in third-party floor
| requests and to request information about a particular
| participant.
The following is the format of the FLOOR-ID attribute.
以下はfloar-id属性のフォーマットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FLOOR-ID format
図8：FLOON-IDフォーマット
Floor ID: This field contains a 16-bit value that uniquely identifies a floor within a conference.
Floor ID：このフィールドには、会議内のフロアを一意に識別する16ビット値が含まれています。
The following is the format of the FLOOR-REQUEST-ID attribute.
以下はfloar-request-id属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: FLOOR-REQUEST-ID format
図9：フロア要求ID形式
Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server.
Floor Request ID：このフィールドには、フロアコントロールサーバーでのフロア要求を識別する16ビット値が含まれています。
The following is the format of the PRIORITY attribute.
以下は優先属性属性のフォーマットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: PRIORITY format
図10：優先形式
Prio: This field contains a 3-bit Priority value, as shown in Table 3. Senders SHOULD NOT use values higher than 4 in this field. Receivers MUST treat values higher than 4 as if the value received were 4 (Highest). The default Priority value when the PRIORITY attribute is missing is 2 (Normal).
PRIO：表3に示すように、このフィールドには3ビットの優先順位の値が含まれています。送信者はこのフィールドで4より高い値を使用しないでください。受信機は、受信された値が4（最高）であったかのように4より高い値を扱う必要があります。優先属性が欠落している場合のデフォルトの優先順位値は2（通常）です。
+=======+==========+
| Value | Priority |
+=======+==========+
| 0 | Lowest |
+-------+----------+
| 1 | Low |
+-------+----------+
| 2 | Normal |
+-------+----------+
| 3 | High |
+-------+----------+
| 4 | Highest |
+-------+----------+
Table 3: Priority values
表3：優先順位の値
Reserved: The 13 bits in the reserved field MUST be set to zero by the sender of the message and MUST be ignored by the receiver.
予約済み：予約フィールドの13ビットは、メッセージの送信者によってゼロに設定されなければならず、受信者によって無視されなければなりません。
The following is the format of the REQUEST-STATUS attribute.
以下は、request-status属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: REQUEST-STATUS format
図11：要求ステータスフォーマット
Request Status: This 8-bit field contains the status of the request, as described in the following table.
要求ステータス：次の表の説明に従って、この8ビットフィールドに要求のステータスが含まれています。
+=======+===========+
| Value | Status |
+=======+===========+
| 1 | Pending |
+-------+-----------+
| 2 | Accepted |
+-------+-----------+
| 3 | Granted |
+-------+-----------+
| 4 | Denied |
+-------+-----------+
| 5 | Cancelled |
+-------+-----------+
| 6 | Released |
+-------+-----------+
| 7 | Revoked |
+-------+-----------+
Table 4: Request Status values
表4：要求ステータス値
Queue Position: This 8-bit field contains, when applicable, the position of the floor request in the floor request queue at the server. If the Request Status value is different from Accepted, if the floor control server does not implement a floor request queue, or if the floor control server does not want to provide the client with this information, all the bits of this field SHOULD be set to zero.
キュー位置：この8ビットフィールドには、該当する場合、サーバーのフロア要求キュー内のフロア要求の位置が含まれています。リクエストステータス値が受け入れられた場合、フロアコントロールサーバーがフロアリクエストキューを実装していない場合、またはフロアコントロールサーバーがこの情報をクライアントに提供したくない場合は、このフィールドのすべてのビットを設定する必要があります。ゼロ。
A floor request is in Pending state if the floor control server needs to contact a floor chair in order to accept the floor request, but has not done it yet. Once the floor control chair accepts the floor request, the floor request is moved to the Accepted state.
フロアコントロールサーバーがフロアリクエストを受け入れるためにフロアチェアに連絡する必要がある場合は、フロアリクエストが保留中の状態ですが、まだ行っていません。フロアコントロールチェアが床の要求を受け入れると、床の要求は受け入れられた状態に移動されます。
The following is the format of the ERROR-CODE attribute.
以下は、error-code属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0|M| Length | Error Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Error Specific Details |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: ERROR-CODE format
図12：エラーコードフォーマット
Error Code: This 8-bit field contains an error code from the following table. If an error code is not recognized by the receiver, then the receiver MUST assume that an error exists, and therefore that the original message that triggered the Error message to be sent is processed, but the nature of the error is unclear.
エラーコード：この8ビットフィールドには、次の表のエラーコードが含まれています。エラーコードが受信機によって認識されない場合、受信者はエラーが存在すると仮定しなければならず、したがって送信されるべきエラーメッセージをトリガした元のメッセージが処理されなければならないが、エラーの性質は不明である。
+=======+=============================================+
| Value | Meaning |
+=======+=============================================+
| 1 | Conference Does Not Exist |
+-------+---------------------------------------------+
| 2 | User Does Not Exist |
+-------+---------------------------------------------+
| 3 | Unknown Primitive |
+-------+---------------------------------------------+
| 4 | Unknown Mandatory Attribute |
+-------+---------------------------------------------+
| 5 | Unauthorized Operation |
+-------+---------------------------------------------+
| 6 | Invalid Floor ID |
+-------+---------------------------------------------+
| 7 | Floor Request ID Does Not Exist |
+-------+---------------------------------------------+
| 8 | You have Already Reached the Maximum Number |
| | of Ongoing Floor Requests for This Floor |
+-------+---------------------------------------------+
| 9 | Use TLS |
+-------+---------------------------------------------+
| 10 | Unable to Parse Message |
+-------+---------------------------------------------+
| 11 | Use DTLS |
+-------+---------------------------------------------+
| 12 | Unsupported Version |
+-------+---------------------------------------------+
| 13 | Incorrect Message Length |
+-------+---------------------------------------------+
| 14 | Generic Error |
+-------+---------------------------------------------+
Table 5: Error Code meaning
表5：エラーコード意味
| Note: The Generic Error error code is intended to be used when
| an error occurs and the other specific error codes do not
| apply.
Error Specific Details: Present only for certain error codes. In this document, this field is present only for Error Code 4 (Unknown Mandatory Attribute). See Section 5.2.6.1 for its definition.
エラー具体的な詳細：特定のエラーコードにのみ存在します。この文書では、このフィールドはエラーコード4（不明な必須属性）にのみ存在します。その定義については5.2.6.1項を参照してください。
Padding: One, two, or three octets of padding added so that the contents of the ERROR-CODE attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
パディング：error-code属性の内容が32ビット整列されるように、パディングの1つ、2、または3オクテットが追加されます。属性がすでに32ビット整列している場合、パディングは必要ありません。
The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver.
パディングビットは送信側によってゼロに設定されなければならず、受信機によって無視される必要があります。
The following is the format of the Error Specific Details field for Error Code 4.
以下は、エラーコード4のエラー固有の詳細フィールドの形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Unknown attributes format
図13：不明な属性フォーマット
Unknown Type: These 7-bit fields contain the Types of the attributes (which were present in the message that triggered the Error message) that were unknown to the receiver.
不明なタイプ：これらの7ビットフィールドには、受信側に不明の属性の型（エラーメッセージをトリガーされたメッセージに存在していました）が含まれています。
Reserved (R): This bit is reserved. It MUST be set to zero by the sender of the message and MUST be ignored by the receiver.
予約済み（R）：このビットは予約されています。メッセージの送信者によってゼロに設定する必要があり、受信者によって無視される必要があります。
The following is the format of the ERROR-INFO attribute.
以下は、error-info属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: ERROR-INFO format
図14：エラー情報フォーマット
Text: This field contains UTF-8 encoded text [9].
テキスト：このフィールドにはUTF-8エンコードテキスト[9]が含まれています。
In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular ERROR-INFO attribute, it MAY use this language to generate the Text field.
状況によっては、テキストフィールドの内容はオートマトンによって生成されてもよい。このオートマトンが特定のerror-info属性の受信側の優先言語に関する情報を持っている場合、それはこの言語を使用してテキストフィールドを生成するかもしれません。
Padding: One, two, or three octets of padding added so that the contents of the ERROR-INFO attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
パディング：error-info属性の内容が32ビット整列されるように、パディングの1つ、2、または3オクテットが追加されます。パディングビットは送信側によってゼロに設定されなければならず、受信機によって無視される必要があります。属性がすでに32ビット整列している場合、パディングは必要ありません。
The following is the format of the PARTICIPANT-PROVIDED-INFO attribute.
以下は、参加者提供info属性のフォーマットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: PARTICIPANT-PROVIDED-INFO format
図15：参加者提供情報フォーマット
Text: This field contains UTF-8 encoded text [9].
テキスト：このフィールドにはUTF-8エンコードテキスト[9]が含まれています。
Padding: One, two, or three octets of padding added so that the contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
パディング：参加者提供info属性の内容が32ビット整列するように、パディングの1つ、2、または3オクテットが追加されます。パディングビットは送信側によってゼロに設定されなければならず、受信機によって無視される必要があります。属性がすでに32ビット整列している場合、パディングは必要ありません。
The following is the format of the STATUS-INFO attribute.
以下は、status-info属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: STATUS-INFO format
図16：ステータス情報フォーマット
Text: This field contains UTF-8 encoded text [9].
テキスト：このフィールドにはUTF-8エンコードテキスト[9]が含まれています。
In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular STATUS-INFO attribute, it MAY use this language to generate the Text field.
状況によっては、テキストフィールドの内容はオートマトンによって生成されてもよい。このオートマトンが特定のステータス情報属性の受信者の好ましい言語に関する情報を持っている場合、この言語を使用してテキストフィールドを生成することができます。
Padding: One, two, or three octets of padding added so that the contents of the STATUS-INFO attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
パディング：status-info属性の内容が32ビット整列されるように追加されたパディングの1つ、2つ、または3オクテット。パディングビットは送信側によってゼロに設定されなければならず、受信機によって無視される必要があります。属性がすでに32ビット整列している場合、パディングは必要ありません。
The following is the format of the SUPPORTED-ATTRIBUTES attribute.
supported-attributes属性の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: SUPPORTED-ATTRIBUTES format
図17：サポートされている属性フォーマット
Supp. Attr.: These fields contain the BFCP attribute types that are supported by the floor control server. See Table 2 for the list of BFCP attributes.
補遺。ATTR。：これらのフィールドには、Floor Control ServerでサポートされているBFCP属性タイプが含まれています。BFCP属性のリストについては、表2を参照してください。
Reserved (R): This bit MUST be set to zero upon transmission and MUST be ignored upon reception.
予約済み（R）：送信時にこのビットはゼロに設定されなければならず、受信時に無視されなければなりません。
Padding: One, two, or three octets of padding added so that the contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
PDDING：supported-attributes属性の内容が32ビット整列されるように追加されたパディングの1つ、2、または3オクテットが追加されました。属性がすでに32ビット整列している場合、パディングは必要ありません。
The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver.
パディングビットは送信側によってゼロに設定されなければならず、受信機によって無視される必要があります。
The following is the format of the SUPPORTED-PRIMITIVES attribute.
以下はsupported-primitives属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 1|M| Length | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primitive | Primitive | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SUPPORTED-PRIMITIVES format
図18：サポートされているプリミティブフォーマット
Primitive: These fields contain the types of the BFCP messages that are supported by the floor control server. See Table 1 for the list of BFCP primitives.
プリミティブ：これらのフィールドには、フロアコントロールサーバーでサポートされているBFCPメッセージの種類が含まれています。BFCPプリミティブのリストについては表1を参照してください。
Padding: One, two, or three octets of padding added so that the contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
PDDING：サポートされているプリミティブ属性の内容が32ビット整列されるように追加されたパディングの1つ、2、または3オクテット。属性がすでに32ビット整列している場合、パディングは必要ありません。
The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver.
パディングビットは送信側によってゼロに設定されなければならず、受信機によって無視される必要があります。
The following is the format of the USER-DISPLAY-NAME attribute.
以下は、user-display-name属性の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: USER-DISPLAY-NAME format
図19：ユーザー表示名形式
Text: This field contains the UTF-8 encoded name of the user.
テキスト：このフィールドには、ユーザーのUTF-8エンコード名が含まれています。
Padding: One, two, or three octets of padding added so that the contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
PDDING：1,2、または3オクテットのパディングが追加され、user-display-name属性の内容が32ビット整列されるように追加されます。パディングビットは送信側によってゼロに設定されなければならず、受信機によって無視される必要があります。属性がすでに32ビット整列している場合、パディングは必要ありません。
The following is the format of the USER-URI attribute.
以下は、user-uri属性のフォーマットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ Text /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: USER-URI format
図20：USER-URI形式
Text: This field contains the UTF-8 encoded user's contact URI, that is, the URI used by the user to set up the resources (e.g., media streams) that are controlled by BFCP. For example, in the context of a conference set up by SIP, the USER-URI attribute would carry the SIP URI of the user.
TEXT：このフィールドには、UTF-8エンコードされたユーザーの連絡先URI、つまり、ユーザーがBFCPによって制御されるリソース（例えばメディアストリーム）を設定するためのURIが含まれています。たとえば、SIPによって設定された会議のコンテキストでは、user-uri属性はユーザーのSIP URIを運びます。
| Messages containing a user's URI in a USER-URI attribute also
| contain the user's User ID. This way, a client receiving such
| a message can correlate the user's URI (e.g., the SIP URI the
| user used to join a conference) with the user's User ID.
Padding: One, two, or three octets of padding added so that the contents of the USER-URI attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed.
PDDING：USER-URI属性の内容が32ビット整列されるように追加されたパディングの1つ、2、または3オクテットが追加されました。パディングビットは送信側によってゼロに設定されなければならず、受信機によって無視される必要があります。属性がすでに32ビット整列している場合、パディングは必要ありません。
The BENEFICIARY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as BENEFICIARY-INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the BENEFICIARY-INFORMATION-HEADER:
受益者情報属性は、受益者情報ヘッダーと呼ばれ、続いて一連の属性が続くヘッダーからなるグループ化された属性です。以下は、受益者情報ヘッダーのフォーマットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 0|M| Length | Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: BENEFICIARY-INFORMATION-HEADER format
図21：受益者情報ヘッダーフォーマット
Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference.
受益者ID：このフィールドには、会議内のユーザーを一意に識別する16ビット値が含まれています。
The following is the ABNF (Augmented Backus-Naur Form) [5] of the BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下は、受益情報グループ化された属性のABNF（Augmented Backus-Naur Form）[5]です。（extension-属性は、将来定義される可能性のある拡張属性を指します。）
BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER [USER-DISPLAY-NAME] [USER-URI] *EXTENSION-ATTRIBUTE
受益者情報=受益者情報 - ヘッダ[user-display-name] [User-URI] *拡張属性
Figure 22: BENEFICIARY-INFORMATION format
図22：受益者情報フォーマット
The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST-INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-INFORMATION-HEADER:
floar-request-information属性は、Floor-Request-Information-Headerと呼ばれるヘッダーからなるグループ化された属性です。その後に一連の属性が続きます。以下は、フロアリクエスト情報ヘッダのフォーマットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 1|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format
図23：フロア要求 - 情報ヘッダフォーマット
Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server.
Floor Request ID：このフィールドには、フロアコントロールサーバーでのフロア要求を識別する16ビット値が含まれています。
The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下は、フロア要求情報グループ化された属性のABNFです。（extension-属性は、将来定義される可能性のある拡張属性を指します。）
FLOOR-REQUEST-INFORMATION = FLOOR-REQUEST-INFORMATION-HEADER
[OVERALL-REQUEST-STATUS]
1*FLOOR-REQUEST-STATUS
[BENEFICIARY-INFORMATION]
[REQUESTED-BY-INFORMATION]
[PRIORITY]
[PARTICIPANT-PROVIDED-INFO]
*EXTENSION-ATTRIBUTE
Figure 24: FLOOR-REQUEST-INFORMATION format
図24：フロア要求 - 情報フォーマット
The REQUESTED-BY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as REQUESTED-BY-INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the REQUESTED-BY-INFORMATION-HEADER:
要求された情報属性は、要求された情報ヘッダーと呼ばれるヘッダーからなるグループ化された属性です。その後に一連の属性が続きます。以下は、要求副情報ヘッダーのフォーマットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 0|M| Length | Requested-by ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: REQUESTED-BY-INFORMATION-HEADER format
図25：情報ごとの情報ヘッダー形式
Requested-by ID: This field contains a 16-bit value that uniquely identifies a user within a conference.
IDを要求します。このフィールドには、会議内のユーザーを一意に識別する16ビット値が含まれています。
The following is the ABNF of the REQUESTED-BY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下は、要求副次グループ化された属性のABNFです。（extension-属性は、将来定義される可能性のある拡張属性を指します。）
REQUESTED-BY-INFORMATION = REQUESTED-BY-INFORMATION-HEADER [USER-DISPLAY-NAME] [USER-URI] *EXTENSION-ATTRIBUTE
情報vification-by-by-information-header [user-display-name] [user-uri] *拡張属性
Figure 26: REQUESTED-BY-INFORMATION format
図26：情報毎のフォーマット
The FLOOR-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST-STATUS-HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-STATUS-HEADER:
floor-request-status属性は、floar-request-status-headerと呼ばれるヘッダーからなるグループ化された属性と、それに続く一連の属性で構成されています。以下は、floor-request-status-headerの形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 1|M| Length | Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: FLOOR-REQUEST-STATUS-HEADER format
図27：フロア要求 - ステータスヘッダフォーマット
Floor ID: this field contains a 16-bit value that uniquely identifies a floor within a conference.
Floor ID：このフィールドには、会議内のフロアを一意に識別する16ビット値が含まれています。
The following is the ABNF of the FLOOR-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
floor-request-status-statusグループ化された属性のABNFは次のとおりです。（extension-属性は、将来定義される可能性のある拡張属性を指します。）
FLOOR-REQUEST-STATUS = FLOOR-REQUEST-STATUS-HEADER [REQUEST-STATUS] [STATUS-INFO] *EXTENSION-ATTRIBUTE
floor-request-status = floor-request-status-header [request-status] [status-info] *拡張子属性
Figure 28: FLOOR-REQUEST-STATUS format
図28：フロア要求 - ステータスフォーマット
The OVERALL-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as OVERALL-REQUEST-STATUS-HEADER, followed by a sequence of attributes. The following is the format of the OVERALL-REQUEST-STATUS-HEADER:
uspart-request-status属性は、request-status-headerと呼ばれ、続いて一連の属性が続くヘッダーからなるグループ化された属性です。以下は、request-status-headerの形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 1 0|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: OVERALL-REQUEST-STATUS-HEADER format
図29：概要要求 - ステータスヘッダフォーマット
Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server.
Floor Request ID：このフィールドには、フロアコントロールサーバーでのフロア要求を識別する16ビット値が含まれています。
The following is the ABNF of the OVERALL-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)
以下は、request-status-statusグループ化された属性のABNFです。（extension-属性は、将来定義される可能性のある拡張属性を指します。）
OVERALL-REQUEST-STATUS = OVERALL-REQUEST-STATUS-HEADER [REQUEST-STATUS] [STATUS-INFO] *EXTENSION-ATTRIBUTE
allart-request-status = allarge-request-status-header [request-status] [status-info] *拡張属性
Figure 30: OVERALL-REQUEST-STATUS format
図30：要求されたステータスフォーマット
This section contains the normative ABNF (Augmented Backus-Naur Form) [5] of the BFCP messages. Extension attributes that may be defined in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.
このセクションには、BFCPメッセージの規範的なABNF（拡張BACKUS-NAUR形式）[5]が含まれています。将来定義され得る拡張属性は、ABNFの拡張属性と呼ばれます。
Floor participants request a floor by sending a FloorRequest message to the floor control server. The following is the format of the FloorRequest message:
Floor Control ServerにFloorRequestメッセージを送信することで、フロア参加者が階をリクエストしてください。以下はFloorRequestメッセージの形式です。
FloorRequest = COMMON-HEADER
1*FLOOR-ID
[BENEFICIARY-ID]
[PARTICIPANT-PROVIDED-INFO]
[PRIORITY]
*EXTENSION-ATTRIBUTE
Figure 31: FloorRequest format
図31：FloorRequestフォーマット
Floor participants release a floor by sending a FloorRelease message to the floor control server. Floor participants also use the FloorRelease message to cancel pending floor requests. The following is the format of the FloorRelease message:
フロアコントロールサーバーにフローレアーズメッセージを送信することで、フロア参加者が床を解放します。フロア参加者はまた、保留中のフロア要求をキャンセルするためにFlooreleaseメッセージを使用します。以下はフロレールドメッセージのフォーマットです。
FloorRelease = COMMON-HEADER FLOOR-REQUEST-ID *EXTENSION-ATTRIBUTE
FlooreleAse =共通ヘッダーのフロア要求-ID *拡張属性
Figure 32: FloorRelease format
図32：フローレーエースフォーマット
Floor participants and floor chairs request information about a floor request by sending a FloorRequestQuery message to the floor control server. The following is the format of the FloorRequestQuery message:
フロア参加者とフロアチェアフロアコントロールサーバーにFloorRequestQueryメッセージを送信することで、フロアリクエストに関する情報を要求します。以下はFloareQuestQueryメッセージの形式です。
FloorRequestQuery = COMMON-HEADER FLOOR-REQUEST-ID *EXTENSION-ATTRIBUTE
FloareRequestQuery =共通ヘッダーのフロア要求-ID *拡張属性
Figure 33: FloorRequestQuery format
図33：FloorRequestQueryフォーマット
The floor control server informs floor participants and floor chairs about the status of their floor requests by sending them FloorRequestStatus messages. The following is the format of the FloorRequestStatus message:
Floor Control Serverは、FloorRequestStatusメッセージを送信することで、床の要求のステータスについて床の参加者やフロアの椅子に通知します。以下はFloorRequestStatusメッセージの形式です。
FloorRequestStatus = COMMON-HEADER FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE
FloareRequestStatus =共通ヘッダーフロア要求 - 情報*拡張属性
Figure 34: FloorRequestStatus format
図34：FlooreRequestStatusフォーマット
Floor participants and floor chairs request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server. The following is the format of the UserQuery message:
フロア参加者とフロアチェアこの参加者に関連する参加者とフロア要求についての情報をフロアコントロールサーバーに送信して、参加者に関する情報を要求します。以下は、ユーザークエリメッセージの形式です。
UserQuery = COMMON-HEADER [BENEFICIARY-ID] *EXTENSION-ATTRIBUTE
UserQuery =共通ヘッダー[受取人ID] *拡張属性
Figure 35: UserQuery format
図35：UserQueryフォーマット
The floor control server provides information about participants and their related floor requests to floor participants and floor chairs by sending them UserStatus messages. The following is the format of the UserStatus message:
Floor Control Serverは、参加者とその関連する階の要求について、床の参加者やフロアの椅子に情報を送ることによって情報を提供します。以下はuserStatusメッセージの形式です。
UserStatus = COMMON-HEADER [BENEFICIARY-INFORMATION] *FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE
UserStatus =共通ヘッダー[受益者情報] *フロア要求情報*拡張属性
Figure 36: UserStatus format
図36：UserStatusフォーマット
Floor participants and floor chairs request information about a floor or floors by sending a FloorQuery message to the floor control server. The following is the format of the FloorQuery message:
フロア参加者とフロアチェアフロアコントロールサーバーにフロアクエリメッセージを送信することで、フロアやフロアに関する情報を要求します。以下は、FloreQueryメッセージの形式です。
FloorQuery = COMMON-HEADER *FLOOR-ID *EXTENSION-ATTRIBUTE
FloreQuery =共通ヘッダー* FLOON-ID *拡張属性
Figure 37: FloorQuery format
図37：FloreQueryフォーマット
The floor control server informs floor participants and floor chairs about the status (e.g., the current holder) of a floor by sending them FloorStatus messages. The following is the format of the FloorStatus message:
Floor Statusメッセージを送信することで、フロアコントロールサーバーにフロアの参加者やフロアチェアを床のステータス（現在のホルダー）について知らせます。以下はFloorStatusメッセージの形式です。
FloorStatus = COMMON-HEADER *FLOOR-ID *FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE
FloorStatus = Common-Header * Floor-ID *フロア要求情報*拡張属性
Figure 38: FloorStatus format
図38：FloorStatusフォーマット
Floor chairs send instructions to floor control servers by sending them ChairAction messages. The following is the format of the ChairAction message:
フロアチェア議長のメッセージを送ることによって、床制御サーバーに指示を送信します。以下は委員会メッセージのフォーマットです。
ChairAction = COMMON-HEADER FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE
議長=一般的なヘッダーのフロア要求 - 情報*拡張属性
Figure 39: ChairAction format
図39議長フォーマット
Floor control servers confirm that they have accepted a ChairAction message by sending a ChairActionAck message. The following is the format of the ChairActionAck message:
フロアコントロールサーバーは、議長のメッセージを送信して議長メッセージを受け入れたことを確認します。以下は議長のメッセージのフォーマットです。
ChairActionAck = COMMON-HEADER *EXTENSION-ATTRIBUTE
ChairactActack =共通ヘッダー*拡張属性
Figure 40: ChairActionAck format
図40：議長のフォーマット
Floor participants and floor chairs MAY check the liveness of floor control servers by sending a Hello message. Additionally, clients communicating with a floor control server over an unreliable transport use the Hello message to initiate communication with the server. The following is the format of the Hello message:
床の参加者や床の椅子は、Helloメッセージを送信することによってフロアコントロールサーバーの活性をチェックすることができます。さらに、リリーネルトランスポートを介してフロアコントロールサーバーと通信するクライアントは、サーバーとの通信を開始するためにHelloメッセージを使用します。以下はHelloメッセージの形式です。
Hello = COMMON-HEADER *EXTENSION-ATTRIBUTE
hello = common-header *拡張属性
Figure 41: Hello format
図41：こんにちはフォーマット
Floor control servers confirm that they are alive on reception of a Hello message by sending a HelloAck message. The following is the format of the HelloAck message:
フロアコントロールサーバーは、Helloackメッセージを送信することによって、Helloメッセージの受信に生きていることを確認します。以下はHelloackメッセージの形式です。
HelloAck = COMMON-HEADER SUPPORTED-PRIMITIVES SUPPORTED-ATTRIBUTES *EXTENSION-ATTRIBUTE
helloack = common-headerサポートしているサポートされているサポートされている属性*拡張属性
Figure 42: HelloAck format
図42：Helloackフォーマット
Floor control servers inform floor participants and floor chairs about errors processing requests by sending them Error messages. The following is the format of the Error message:
フロア制御サーバーは、エラーメッセージを送信することで、エラー処理要求についてフロア参加者とフロアチェアを通知します。以下はエラーメッセージの形式です。
Error = COMMON-HEADER ERROR-CODE [ERROR-INFO] *EXTENSION-ATTRIBUTE
ERROR = COMMON-HEADERエラー - コード[エラー情報] *拡張属性
Figure 43: Error format
図43：エラーフォーマット
When communicating over an unreliable transport, floor participants and chairs acknowledge the receipt of a subsequent FloorRequestStatus message from the floor control server (cf. Section 13.1.2) by sending a FloorRequestStatusAck message. The following is the format of the FloorRequestStatusAck message:
信頼性の低い輸送を通信するときは、Floor Controlサーバーからの後続のFloorQuestStatusメッセージの受信を承認します。FloorRequestStatusAckメッセージの形式は次のとおりです。
FloorRequestStatusAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE
Figure 44: FloorRequestStatusAck format
図44：FloorRequestStatusAckフォーマット
When communicating over an unreliable transport, floor participants and chairs acknowledge the receipt of a subsequent FloorStatus message from the floor control server (cf. Section 13.5.2) by sending a FloorStatusAck message. The following is the format of the FloorStatusAck message:
信頼性の低い輸送を通信するときは、FloorStatusAckメッセージを送信することによって、フロアコントロールサーバー（CF.セクション13.5.2）からの後続のFloorStatusメッセージの受信を確認します。以下はFloorStatusAckメッセージの形式です。
FloorStatusAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE
Figure 45: FloorStatusAck format
図45：FloorStatusAckフォーマット
BFCP entities communicating over an unreliable transport that wish to dissociate themselves from their remote participant do so through the transmission of a Goodbye. The following is the format of the Goodbye message:
BFCPエンティティは、リモート参加者から自分自身を解決したいと思う信頼できない輸送を介してコミュニケーションをとって、さよならの送信を通してそうします。以下はさよならメッセージのフォーマットです。
Goodbye = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE
Figure 46: Goodbye format
図46：さようなら形式
BFCP entities communicating over an unreliable transport acknowledge the receipt of a Goodbye message from a peer. The following is the format of the GoodbyeAck message:
信頼できないトランスポートを介して通信するBFCPエンティティは、ピアからのさようならメッセージの受信を確認します。GoodByeAckメッセージのフォーマットは次のとおりです。
GoodbyeAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE
Figure 47: GoodbyeAck format
図47：GoodByeAckフォーマット
The transport over which BFCP entities exchange messages depends on the information the clients obtain for contacting the floor control server, as described in Section 3.2. Two transports are supported: TCP, which is appropriate where connectivity is not impeded by network elements such as NAT devices or media relays; and UDP for those deployments where TCP may not be applicable or appropriate.
BFCPエンティティを交換する輸送は、セクション3.2で説明されているように、クライアントがフロアコントロールサーバーに連絡するために取得する情報によって異なります。2つのトランスポートがサポートされています.TCPは、NATデバイスやメディアリレーなどのネットワーク要素によって接続が妨げられていない場合に適切です。TCPが適用されないか適切でないかもしれないこれらの展開のためのUDP。
| Note: In practice, products are configured to try one transport
| first and then use the other transport as a fallback. Whether
| TCP or UDP is chosen as underlying transport depends on the
| type of product and the deployment environment. See Appendix B
| for additional considerations.
BFCP entities may elect to exchange BFCP messages using TCP connections. TCP provides an in-order reliable delivery of a stream of bytes. Consequently, message framing needs to be implemented in the application layer. BFCP implements application-layer framing using TLV-encoded attributes.
BFCPエンティティは、TCP接続を使用してBFCPメッセージを交換することを選択できます。TCPは、バイトのストリームの順序で信頼できる配信を提供します。その結果、メッセージフレーミングをアプリケーション層に実装する必要がある。BFCPは、TLVエンコードされた属性を使用してアプリケーション層フレーミングを実装しています。
A client MUST NOT use more than one TCP connection to communicate with a given floor control server within a conference. Nevertheless, if the same physical box handles different clients (e.g., a floor chair and a floor participant), which are identified by different User IDs, a separate connection per client is allowed.
クライアントは、会議内の特定のフロア制御サーバーと通信するために複数のTCP接続を使用してはいけません。それにもかかわらず、同じ物理的なボックスが異なるユーザーIDによって識別されるさまざまなクライアント（例えば、フロアチェアとフロア参加者）を処理する場合、クライアントごとの別の接続が許可されます。
If a BFCP entity (a client or a floor control server) receives data that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished. Similarly, if a TCP connection cannot deliver a BFCP message and times out or receives an ICMP port unreachable message mid-connection, the TCP connection SHOULD be reestablished.
BFCPエンティティ（クライアントまたはフロアコントロールサーバー）が解析できないデータを受信した場合、エンティティはTCP接続を閉じ、接続を再確立する必要があります。同様に、TCP接続がBFCPメッセージを配信できず、ICMPポート到達不能メッセージ中間接続を受信できない場合は、TCP接続を再確立する必要があります。
The way connection reestablishment is handled depends on how the client obtains information to contact the floor control server. Once the TCP connection is reestablished, the client MAY resend those messages for which it did not get a response from the floor control server.
接続の再確立方法が処理される方法は、クライアントがフロアコントロールサーバーに連絡するための情報を取得する方法によって異なります。TCP接続が再確立されると、クライアントはフロアコントロールサーバーからの応答を得なかったメッセージを再送信することができます。
If a floor control server detects that the TCP connection towards one of the floor participants is lost, it is up to the local policy of the floor control server what to do with the pending floor requests of the floor participant. In any case, it is RECOMMENDED that the floor control server keep the floor requests (i.e., that it does not cancel them) while the TCP connection is reestablished.
フロアコントロールサーバーが、フロア参加者の1つへのTCP接続が失われたことを検出した場合、フロアコントロールサーバーのローカルポリシーは、フロア参加者の保留中の階の要求を行うものです。いずれにせよ、TCP接続が再確立されている間は、フロアコントロールサーバーがフロア要求（すなわちキャンセルしない）を保持することをお勧めします。
If a client wishes to end its BFCP connection with a floor control server, the client closes (i.e., a graceful close) the TCP connection towards the floor control server. If a floor control server wishes to end its BFCP connection with a client (e.g., the focus of the conference informs the floor control server that the client has been kicked out of the conference), the floor control server closes (i.e., a graceful close) the TCP connection towards the client.
クライアントがフロアコントロールサーバーとのBFCP接続を終了したい場合は、クライアントはフロアコントロールサーバーへのTCP接続を閉じます（すなわち、優雅な閉じる）。フロアコントロールサーバーがクライアントとのBFCP接続を終了したい場合（Conferenceの焦点がフロアコントロールサーバーに会議からキックアウトされていることを通知する）、フロアコントロールサーバーが閉じる（すなわち、優雅な閉じる）クライアントへのTCP接続。
In cases where a BFCP entity reestablishes a connection due to protocol errors as described above, the entity SHOULD NOT repeatedly reestablish the connection. Rather, if the same protocol errors persist, the entity MUST cease attempts and SHOULD report the error to the human user and/or log the event. This does not preclude the entity from reestablishing a connection when facing a different set of errors. That said, entities MUST avoid overloading the server with reestablishment requests. A connection MUST NOT be reestablished too frequently. The frequency is a matter of implementation, but SHOULD NOT be attempted more than once in a 30 second period of time.
上記のようにプロトコルエラーのためにBFCPエンティティが接続を再確立する場合、エンティティは接続を繰り返し再確立するべきではありません。そうではなく、同じプロトコルエラーが保持されている場合、エンティティは試みを中止し、エラーをヒューマンユーザーに報告したり、イベントを記録する必要があります。これは、エンティティが異なるエラーセットに直面しているときに接続を再確立するのを妨げません。そうは言っても、エンティティは再確立要求を持つサーバーを過負荷にしないでください。接続が頻繁に再確立されてはいけません。周波数は実装の問題ですが、30秒以内に1回以上試行されるべきではありません。
BFCP entities may elect to exchange BFCP messages using UDP datagrams. UDP is an unreliable transport where neither delivery nor ordering is assured. Each BFCP UDP datagram MUST contain exactly one BFCP message or message fragment. To keep large BFCP messages from being fragmented at the IP layer, the fragmentation of BFCP messages that exceed the path MTU size is performed at the BFCP level. Considerations related to fragmentation are covered in Section 6.2.3. The message format for BFCP messages is the same regardless of whether the messages are sent in UDP datagrams or over a TCP stream.
BFCPエンティティは、UDPデータグラムを使用してBFCPメッセージを交換することを選択できます。UDPは、配信も注文も保証されていない信頼できない輸送です。各BFCP UDPデータグラムには、正確に1つのBFCPメッセージまたはメッセージフラグメントを含める必要があります。大規模なBFCPメッセージをIP層で断片化させるために、パスMTUサイズを超えるBFCPメッセージの断片化がBFCPレベルで実行されます。断片化に関連する考慮事項は、6.2.3項で説明されています。BFCPメッセージのメッセージフォーマットは、メッセージがUDPデータグラムまたはTCPストリームを介して送信されているかどうかにかかわらず同じです。
Clients MUST announce their presence to the floor control server by sending a Hello message. The floor control server responds to the Hello message with a HelloAck message. The client considers the floor control server as present and available only upon receiving the HelloAck message. The behavior when timers fire, including the determination that a connection is broken, is described in Section 8.3.
クライアントは、Helloメッセージを送信することによってフロアコントロールサーバーにプレゼンスを発表しなければなりません。Floor Controlサーバーはhelloackメッセージを使用してHelloメッセージに応答します。クライアントは、Helloackメッセージを受信したときにのみ、登録されているようにフロアコントロールサーバーを検討します。接続が破損したと判断を含むタイマー火災時の動作は、8.3節で説明されています。
As described in Section 8, each request sent by a floor participant or chair forms a client transaction that expects an acknowledgement message from the floor control server within a transaction failure window. Concordantly, messages sent by the floor control server that initiate new transactions (e.g., FloorStatus announcements as part of a FloorQuery subscription) require acknowledgement messages from the floor participant and chair entities to which they were sent.
セクション8に記載されているように、フロア参加者または椅子によって送信された各要求は、トランザクション障害ウィンドウ内のフロアコントロールサーバーからの確認メッセージを期待するクライアントトランザクションを形成する。一致して、新しいトランザクションを開始する（例えば、FloreQueryの購読の一部としてのFloorStatus Announcements）Floor Control Serverによって送信されたメッセージが、床参加者とそれらが送信された議長のエンティティからの確認メッセージを必要とします。
If a floor control server receives data that cannot be parsed, the receiving server MUST send an Error message with parameter value 10 (Unable to Parse Message) indicating receipt of a malformed message, given that it is possible to parse the received message to such an extent that an Error message may be built.
Floor Control Serverが解析できないデータを受信した場合、受信したメッセージをそのようなメッセージを解析することが可能であることを考えると、受信したメッセージの受信を示すエラーメッセージ（メッセージを解析できません）にエラーメッセージを送信する必要があります。エラーメッセージが構築される可能性がある範囲。
Entities MUST have at most one outstanding request transaction per peer at any one time. Implicit subscriptions occur for a client-initiated request transaction whose acknowledgement is implied by the first server-initiated response for that transaction, followed by zero of more subsequent server-initiated messages corresponding to the same transaction. An example is a FloorRequest message for which there are potentially multiple responses from the floor control server as it processes intermediate states until a terminal state (e.g., Granted or Denied) is attained. The subsequent changes in state for the request are new transactions whose Transaction ID is determined by the floor control server and whose receipt by the client participant is acknowledged with a FloorRequestStatusAck message.
エンティティは、一度にピアごとに最大の要求トランザクションを1回持っていなければなりません。暗黙の購読は、確認応答がそのトランザクションに対する最初のサーバー開始された応答によって黙示されているクライアント開始要求トランザクションに対して、その後に同じトランザクションに対応するより多くの後続のサーバー開始メッセージをゼロにします。一例は、端末状態（例えば、許可または拒否された）が達成されるまで、中間状態を処理するときに、フロア制御サーバから複数の応答がある場合には、FloarRequestメッセージである。要求の後の状態の変化は、トランザクションIDがフロアコントロールサーバーによって決定され、クライアント参加者による受信がFloorRequestStatusAckメッセージで認識されている新しいトランザクションです。
By restricting entities to having at most one pending transaction open in a BFCP connection, both the out-of-order receipt of messages as well as the possibility for congestion are mitigated. Additional details regarding congestion control are provided in Section 6.2.1. If a participant receives a server-initiated request (e.g., a FloorStatus from the floor control server) while waiting for a response to a client-initiated transaction (e.g., the participant sent a FloorRequest and is waiting for a FloorRequestStatus response), then the participant MUST treat the server-initiated request as superseding any response to its client-initiated transaction. As the floor control server cannot send a second update to the implicit floor status subscription until the first is acknowledged, ordinality is maintained.
IntientsをBFCP接続で開くことを最大限に開くことで、メッセージの順序付き受信と輻輳の可能性の両方が軽減されます。輻輳制御に関する追加の詳細は、6.2.1項で提供されています。クライアント開始トランザクションへの応答を待っている間に参加者がサーバ開始要求（フロア制御サーバからフロアステータス）を受信した場合（例えばFloorRequestを送信し、FloorRequestStatus Responseを待っている）。参加者は、そのクライアント開始トランザクションに対する応答に置き換えられたサーバー開始要求を扱う必要があります。Floor Controlサーバーが最初に確認されるまで暗黙のフロアステータスサブスクリプションに2回目のアップデートを送信できないため、序数は維持されます。
If a client wishes to end its BFCP connection with a floor control server, it is REQUIRED that the client send a Goodbye message to dissociate itself from any allocated resources. If a floor control server wishes to end its BFCP connection with a client (e.g., the focus of the conference informs the floor control server that the client has been kicked out from the conference), it is REQUIRED that the floor control server send a Goodbye message towards the client.
クライアントがフロアコントロールサーバーとのBFCP接続を終了したい場合は、クライアントが割り当てられたリソースから自分自身を解離するためにクライアントがさようならのメッセージを送信することが必要です。フロア制御サーバがクライアントとのBFCP接続を終了したい場合（例えば、会議の焦点がフロアコントロールサーバーに会議からキックアウトしたことを通知する）、フロアコントロールサーバーがさよならを送信することが必要です。クライアントに向かってメッセージ。
BFCP may be characterized as generating "low data-volume" traffic, per the classification in [15]. Nevertheless, it is necessary to ensure that suitable and necessary congestion control mechanisms are used for BFCP over UDP. As described in Section 6.2, within the same BFCP connection, every entity -- client or server -- is only allowed to send one request at a time, and await the acknowledging response. This way, at most one datagram is sent per RTT given the message is not lost during transmission. If the message is lost, the request retransmission timer T1 specified in Section 8.3.1 will fire, and the message is retransmitted up to three times, in addition to the original transmission of the message. The default initial interval MUST be set to 500 ms, but is adjusted dynamically as described in Section 8.3.1. The interval MUST be doubled after each retransmission attempt. This is similar to the specification of the timer A and its initial value T1 in SIP as described in Section 17.1.1.2 of [20], except that the value of T1 in this protocol is not fixed from one transaction to another.
BFCPは、[15]の分類ごとに「低いデータボリューム」トラフィックを生成することを特徴とすることができます。それにもかかわらず、UDP上のBFCPに適切かつ必要な輻輳制御メカニズムを使用することを確実にすることが必要です。セクション6.2で説明されているように、同じBFCP接続内で、すべてのエンティティ - クライアントまたはサーバーは一度に1つの要求を送信し、確認応答を待つことができます。このようにして、送信中にメッセージが失われないことを考えると、ほとんどのデータグラムがRTTに送信されます。メッセージが失われた場合、セクション8.3.1で指定された要求再送タイマT1は、メッセージの元の送信に加えて、メッセージを最大3回まで再送信します。デフォルトの初期間隔は500 msに設定する必要がありますが、8.3.1項で説明されているように動的に調整されます。各再送試行の後に間隔を2倍にする必要があります。このプロトコルのT1の値があるトランザクションから別のトランザクションに固定されていないことを除いて、[20]のセクション17.1.1.2で説明したように、SIPのタイマAとその初期値T1の指定と似ています。
ICMP is not usable when BFCP is running over an unreliable transport due to risks associated with off-path attacks. Any ICMP messages associated with BFCP running over an unreliable transport MUST be ignored.
OFF-PATH攻撃に関連したリスクのため、BFCPが信頼できないトランスポートを介して実行されている場合、ICMPは使用できません。信頼性の低いトランスポートを介して実行されているBFCPに関連するICMPメッセージはすべて無視される必要があります。
When using UDP, a single BFCP message could be fragmented at the IP layer if its overall size exceeds the path MTU of the network. To avoid this happening at the IP layer, a fragmentation scheme for BFCP is defined below.
UDPを使用する場合、その全体のサイズがネットワークのパスMTUを超えると、単一のBFCPメッセージをIP層に断片化することができます。IP層で起こっていることを回避するために、BFCPの断片化方式を以下に定義します。
BFCP is designed for achieving small message size, due to the binary encoding as described in Section 1. The fragmentation scheme is therefore deliberately kept simple and straightforward, since the probability of fragmentation of BFCP messages is small. By design, the fragmentation scheme does not acknowledge individual BFCP message fragments. The whole BFCP message is acknowledged if received completely.
BFCPは、セクション1で説明されているようにバイナリエンコードのために小さなメッセージサイズを達成するために設計されています。設計により、フラグメンテーション方式は個々のBFCPメッセージフラグメントを確認しません。完全に受信した場合、BFCPメッセージ全体が確認されます。
BFCP entities SHOULD consider the path MTU size available between the sender and the receiver and MAY run MTU discovery, such as described in [25], [26], and [27], for this purpose.
BFCPエンティティは、送信者と受信者との間で利用可能なパスMTUサイズを考慮する必要があり、この目的のために[25]、[26]、[27]で説明されているようにMTU検出を実行することができる。
When transmitting a BFCP message with a size greater than the path MTU, the sender MUST fragment the message into a series of N contiguous data ranges. The size of each of these N messages MUST be smaller than the path MTU to help prevent fragmentation overlap attacks. The value for N is defined as ceil((message size -- COMMON-HEADER size) / (path MTU size -- COMMON-HEADER size)), where ceil is the integer ceiling function, and the COMMON-HEADER size includes the Fragment Offset and Fragment Length fields. The sender then creates N BFCP fragment messages (one for each data range) with the same Transaction ID. The size of each of these N messages, with the COMMON-HEADER included, MUST be smaller than the path MTU. The F flag in the COMMON-HEADER in all the fragments is set to indicate fragmentation of the BFCP message.
パスMTUより大きいサイズでBFCPメッセージを送信する場合、送信側はメッセージを一連のN個の連続したデータ範囲にフラグメント化する必要があります。これらのN個のメッセージのそれぞれのサイズは、フラグメンテーションの重複攻撃を防ぐのに役立つように、パスMTUよりも小さくなければなりません。nの値はCEILとして定義されます（（メッセージサイズ - 共通ヘッダーサイズ）/（パスMTUサイズ - 共通ヘッダーサイズ））、CEILは整数天井関数で、共通ヘッダーサイズにフラグメントが含まれています。オフセットとフラグメント長フィールド送信者は次に同じトランザクションIDを持つN BFCPフラグメントメッセージ（各データ範囲に対して1つ）を作成します。共通ヘッダーが含まれている、これらのN個のメッセージのそれぞれのサイズは、パスMTUよりも小さくなければなりません。すべてのフラグメント内の共通ヘッダー内のFフラグは、BFCPメッセージの断片化を示すように設定されています。
For each of these fragments, the Fragment Offset and Fragment Length fields are included in the COMMON-HEADER. The Fragment Offset field denotes the number of 4-octet units contained in the previous fragments, excluding the COMMON-HEADER. The Fragment Length contains the length of the fragment itself, also excluding the COMMON-HEADER. Note that the Payload Length field contains the length of the entire, unfragmented message.
これらのフラグメントのそれぞれについて、フラグメントオフセットフィールドとフラグメント長フィールドは共通ヘッダーに含まれています。フラグメントオフセットフィールドは、一般的なヘッダを除いて、前のフラグメントに含まれる4オクテット単位の数を表します。フラグメントの長さには、Common-Headerを除くフラグメント自体の長さが含まれています。[ペイロード長]フィールドには、復元されていないメッセージ全体の長さが含まれています。
When a BFCP implementation receives a BFCP message fragment, it MUST buffer the fragment until either it has received the entire BFCP message, or until the Response Retransmission Timer expires. The state machine should handle the BFCP message only after all the fragments of the message have been received.
BFCP実装がBFCPメッセージのフラグメントを受信すると、BFCPメッセージ全体を受信したか、応答再送信タイマーが期限切れになるまでフラグメントをバッファしなければなりません。ステートマシンは、メッセージのすべてのフラグメントが受信された後にのみBFCPメッセージを処理する必要があります。
If a fragment of a BFCP message is lost, the sender will not receive an acknowledgement for the message. Therefore the sender will retransmit the message with same transaction ID as specified in Section 8.3. If the acknowledgement message sent by the receiver is lost, then the entire message will be resent by the sender. The receiver MUST then retransmit the acknowledgement. The receiver MAY discard an incomplete buffer utilizing the Response Retransmission Timer, starting the timer after the receipt of the first fragment.
BFCPメッセージのフラグメントが失われた場合、送信者はメッセージの確認応答を受け取りません。したがって、送信者はセクション8.3で指定されたものと同じトランザクションIDを持つメッセージを再送信します。受信者によって送信された確認メッセージが失われた場合、メッセージ全体は送信者によって再送されます。受信機は確認応答を再送信する必要があります。受信機は、応答再送タイマを利用して不完全なバッファを廃棄し、第1のフラグメントの受信後のタイマを起動することができる。
| A Denial of Service (DoS) attack utilizing the fragmentation
| scheme described above is mitigated by the fact that the
| Response Retransmission Timer is started after receipt of the
| first BFCP message fragment. In addition, the Payload Length
| field can be compared with the Fragment Offset and Fragment
| Length fields to verify the message fragments as they arrive.
| To make DoS attacks with spoofed IP addresses difficult, BFCP
| entities SHOULD use the cookie exchange mechanism in DTLS [8].
When deciding the size of the message fragment based on path MTU, the BFCP fragmentation handling should take into account how the DTLS record framing expands the datagram size as described in Section 4.1.1.1 of [8].
パスMTUに基づいてメッセージフラグメントのサイズを決定するとき、BFCPフラグメンテーション処理は[8]のセクション4.1.1.1で説明されているようにDTLSレコードフレーミングがデータグラムサイズを拡大する方法を考慮に入れるべきです。
One of the key benefits of using UDP for BFCP communication is the ability to leverage the existing NAT traversal infrastructure and strategies deployed to facilitate transport of the media associated with the video conferencing sessions. Depending on the given deployment, this infrastructure typically includes some subset of Interactive Connectivity Establishment (ICE) [16].
BFCP通信のためにUDPを使用するという重要な利点の1つは、ビデオ会議セッションに関連するメディアのトランスポートを容易にするために展開された既存のNATトラバーサルインフラストラクチャと戦略を活用することができます。与えられた展開に応じて、このインフラストラクチャは通常、インタラクティブ接続確立（ICE）のサブセットを含みます[16]。
In order to facilitate the initial establishment of NAT bindings, and to maintain those bindings once established, BFCP entities using an unreliable transport are RECOMMENDED to use STUN [14] Binding Indication for keepalives, as described for ICE [16]. Section 6.7 of [28] provides useful recommendations for middlebox interaction when DTLS is used.
NATバインディングの初期設定を容易にし、それらのバインディングを確立したバインディングを維持するために、氷[16]について説明したように、信頼性の低い輸送を使用しているBFCPエンティティは、キープアライブのためのSTUN [14]バインディング表示を使用することをお勧めします[16]。DTLSが使用されているときに、ミドルボックスの対話に便利な推奨事項を提供します。
| Note: Since the version number is set to 2 when BFCP is used
| over an unreliable transport, cf. the Ver field in Section 5.1,
| it is straightforward to distinguish between STUN and BFCP
| packets even without checking the STUN magic cookie [14].
In order to facilitate traversal of BFCP packets through NATs, BFCP entities using an unreliable transport are RECOMMENDED to use symmetric ports for sending and receiving BFCP packets, as recommended for RTP/RTP Control Protocol (RTCP) [13].
NATSを介したBFCPパケットのトラバースを容易にするために、RTP / RTP制御プロトコル（RTCP）の推奨されるように、信頼性の低いトランスポートを使用するBFCPエンティティは、BFCPパケットの送受信に対称ポートを使用することをお勧めします[13]。
BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs) MUST support TLS for transport over TCP [11] and MUST support DTLS [8] for transport over UDP. Any BFCP entity MAY support other security mechanisms.
BFCPは、再生と整合性の保護と機密性を提供するために、より低層のセキュリティメカニズムに依存しています。BFCPフロア制御サーバーとクライアント（フロア参加者とフロアチェアの両方を含む）はTCP [11]を介したTLSをサポートし、UDPを介した輸送のためのDTLS [8]をサポートしなければなりません。どのBFCPエンティティも他のセキュリティメカニズムをサポートできます。
BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite [7] for backwards compatibility with existing implementations of RFC 4582. In accordance with the recommendations and guidelines in [30], BFCP entities SHOULD support the following cipher suites:
BFCPエンティティは、RFC 4582の既存の実装との既存の実装との下位互換性のためのTLS_RSA_WITH_AES_128_CBC_SHA暗号スイート[7]を最小限に抑える必要があります。[30]の推奨事項とガイドラインに従って、BFCPエンティティは次の暗号スイートをサポートする必要があります。
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
In BFCP, there are two types of transactions: client-initiated transactions and server-initiated transactions.
BFCPでは、クライアント開始トランザクションとサーバー開始トランザクションの2種類のトランザクションがあります。
Client-initiated transactions consist of a request from a client to a floor control server and a response from the floor control server to the client.
クライアント開始トランザクションは、クライアントからフロアコントロールサーバーへの要求と、フロアコントロールサーバーからクライアントへの応答で構成されています。
Server-initiated transactions have different requirements and behavior depending on underlying transport:
サーバー開始トランザクションには、基礎となるトランスポートに応じて異なる要件と動作があります。
When using a reliable transport, server-initiated transactions consist of a single message from a floor control server to a client (notifications). They do not trigger any response.
信頼できるトランスポートを使用する場合、サーバー開始トランザクションは、フロアコントロールサーバーからクライアント（通知）への単一のメッセージで構成されています。彼らは何も応答を引き起こさない。
When using an unreliable transport, server-initiated transactions consist of a request from a floor control server to a client and a response from the client to the floor control server.
信頼性の低いトランスポートを使用する場合、サーバー開始トランザクションは、フロアコントロールサーバーからクライアントへの要求と、クライアントからフロアコントロールサーバーへの応答で構成されています。
When using BFCP over an unreliable transport, retransmission timer T1 (see Section 8.3) MUST be used for all requests until the transaction is completed. Note that while T1 varies over time, it remains constant for the duration of a given transaction and is only updated at the completion of a transaction.
信頼性の低いトランスポートでBFCPを使用する場合、再送タイマT1（セクション8.3を参照）は、トランザクションが完了するまですべての要求に使用する必要があります。T1が経時的に変化するが、所与のトランザクションの期間中一定のままであり、トランザクションの完了時にのみ更新される。
A client starting a client-initiated transaction MUST set the Conference ID in the COMMON-HEADER of the message to the Conference ID for the conference that the client obtained previously.
クライアント開始トランザクションを開始するクライアントは、クライアントが以前に取得した会議の会議IDにメッセージの共通ヘッダーに会議IDを設定する必要があります。
The client MUST set the Transaction ID value in the COMMON-HEADER to a number that is different from 0 and that MUST NOT be reused in another message from the client until a response from the server is received for the transaction. The client uses the Transaction ID value to match this message with the response from the floor control server. When using BFCP over an unreliable transport, it is important to choose a Transaction ID value that lets the receiver distinguish the reception of the next message in a sequence of BFCP messages from a retransmission of a previous message. Therefore, BFCP entities using an unreliable transport MUST use monotonically increasing Transaction ID values (except for wrap-around).
クライアントは、共通ヘッダ内のトランザクションID値を0とは異なる番号に設定する必要があり、サーバからの応答がトランザクションに対して受信されるまでクライアントからの別のメッセージで再利用されないでください。クライアントは、トランザクションIDの値を使用して、このメッセージをFloor Control Serverからの応答と一致させます。信頼性の低いトランスポートでBFCPを使用する場合、受信機が前のメッセージの再送信からのシーケンスのBFCPメッセージ内の次のメッセージの受信を区別できるトランザクションID値を選択することが重要です。したがって、信頼性の低いトランスポートを使用したBFCPエンティティは、単調に増加するトランザクションID値を使用する必要があります（ラップアラウンドを除く）。
A client receiving a server-initiated transaction over an unreliable transport MUST copy the Transaction ID from the request received from the server into the response.
信頼性の低いトランスポートを介してサーバーが開始したトランザクションを受信したクライアントは、サーバーから受信した要求からのトランザクションIDを応答にコピーする必要があります。
A floor control server sending a response within a client-initiated transaction MUST copy the Conference ID, the Transaction ID, and the User ID from the request received from the client into the response.
クライアント開始トランザクション内で応答を送信するフロアコントロールサーバーは、クライアントから受信した要求から、会議ID、トランザクションID、およびユーザーIDを応答にコピーする必要があります。
Server-initiated transactions MUST contain a Transaction ID equal to zero when BFCP is used over a reliable transport. Over an unreliable transport, the Transaction ID shall have the same properties as for client-initiated transactions. The server uses the Transaction ID value to match this message with the response from the floor participant or floor chair.
サーバ開始トランザクションには、信頼できるトランスポートでBFCPが使用されている場合、ゼロに等しいトランザクションIDを含める必要があります。信頼できないトランスポートでは、トランザクションIDはクライアント開始トランザクションと同じプロパティを持ちます。サーバーはトランザクションIDの値を使用して、このメッセージをフロア参加者またはフロアチェアからの応答と一致させます。
When BFCP entities are communicating over an unreliable transport, two retransmission timers are employed to help mitigate the loss of datagrams. Retransmission and response caching are not required when BFCP entities communicate over a reliable transport.
BFCPエンティティが信頼性の低い輸送を介して通信している場合、データグラムの損失を軽減するのに役立つ2つの再送信タイマーが採用されています。BFCPエンティティが信頼できるトランスポートを介して通信するときは、再送と応答のキャッシングは必要ありません。
T1 is a timer that schedules retransmission of a request until an appropriate response is received or until the maximum number of retransmissions has occurred. The timer is computed using the smoothed round-trip time algorithm defined in [2] with an initial retransmission timeout (RTO) value of 500 ms and clock granularity (G) of 100 ms. In contrast to step 2.4 of Section 2 of [2], if the computed value of RTO is less than 500 ms, then RTO shall be set to 500 ms. Timer T1 MUST be adjusted with the reception of a response to each request transmitted in order to compute an accurate RTO value, which is the effective T1 value. The RTT value R is the time in milliseconds from the time when a request is transmitted to the time the initial response to that request is received. Responses to retransmitted packets MUST NOT be used to recompute the RTO value, as one cannot determine if a response is to an initial or retransmitted request. If T1 always expires on the initial transmission of a new request, this would suggest the recommended initial T1 (and RTO) value is too low and SHOULD be increased by doubling the initial values of T1 (and RTO) until T1 does not expire when sending a new request.
T1は、適切な応答が受信されるまで、または最大再送信数が発生するまで、要求の再送信をスケジュールするタイマーです。タイマは、[2]で定義された平滑化往復時間アルゴリズムを使用して、500 msの初期再送信タイムアウト（RTO）値と100 msのクロック粒度（g）を使用して計算されます。 [2]のセクション2のステップ2.4とは対照的に、RTOの計算値が500ms未満の場合、RTOは500msに設定されます。タイマT1は、有効なT1値である正確なRTO値を計算するために送信された各要求に対する応答を受信して調整する必要があります。 RTT値Rは、要求がその要求に対する初期応答が受信されるまでの間に送信された時からミリ秒単位の時間である。再送信されたパケットへの応答は、応答が初期要求または再送信要求に対するものであるかどうかを判断できないため、RTO値を再計算するために使用してはいけません。 T1が新しい要求の最初の送信に常に有効期限が切れた場合、これは推奨される初期T1（およびRTO）値が低すぎて、送信時にT1が期限切れになるまでT1（およびRTO）の初期値を2倍にすることで増やす必要があります。新しい要求
When retransmitting a request, timer T1 is doubled with each retransmission, failing after three unacknowledged retransmission attempts.
リクエストを再送信する場合、タイマT1は各再送で2倍になり、3回の未確認の再送信試行後に失敗します。
If a valid response is not received for a client- or server-initiated transaction, the implementation MUST consider the BFCP connection as broken. Implementations SHOULD follow the reestablishment procedure described in Section 6.
クライアントまたはサーバー開始トランザクションに対して有効な応答が受信されない場合、実装はBFCP接続を破断したと考える必要があります。実装は、セクション6に記載されている再確立手順に従うべきです。
T2 is a timer that, when fired, signals that the BFCP entity can release knowledge of the transaction against which it is running. It is started upon the first transmission of the response to a request and is the only mechanism by which that response is released by the BFCP entity. Any subsequent retransmissions of the same request can be responded to by replaying the cached response, while that value is retained until the timer has fired. Refer to Section 6.2.3 for this timer's role in the fragmentation handling scheme.
T2は、起動時にBFCPエンティティが実行中のトランザクションに関する知識を解放できるようにするタイマーです。要求に対する応答の最初の送信が開始され、その応答がBFCPエンティティによって解放される唯一のメカニズムです。その値は、キャッシュされた応答を再生することによって同じ要求の再送信を応答することができますが、その値はタイマーが発生するまで保持されます。断片化処理方式におけるこのタイマーの役割については、6.2.3項を参照してください。
The table below defines the different timers required when BFCP entities communicate over an unreliable transport.
以下の表は、BFCPエンティティが信頼できないトランスポートを介して通信するときに必要な異なるタイマーを定義しています。
+=======+======================================+=================+
| Timer | Description | Value/s |
+=======+======================================+=================+
| T1 | Initial request retransmission timer | 0.5 s (initial) |
+-------+--------------------------------------+-----------------+
| T2 | Response retransmission timer | (T1*2^(4))*1.25 |
+-------+--------------------------------------+-----------------+
Table 6: Timers
表6：タイマー
The initial value for T1 is 500 ms, which is an estimate of the RTT for completing the transaction. Computation of this value follows the procedures described in Section 8.3.1, which includes exponential backoffs on retransmissions.
T1の初期値は500msで、これはトランザクションを完了するためのRTTの推定値です。この値の計算は、3.3.1項で説明されている手順に従います。これは、再送信に関する指数関数的バックオフを含みます。
T2 MUST be set such that it encompasses all legal retransmissions per T1 plus a factor to accommodate network latency between BFCP entities, processing delays, etc.
T2は、BFCPエンティティ、処理遅延などの間のネットワーク待ち時間に対応する要因となる要因となるようにT2を設定する必要があります。
BFCP clients SHOULD authenticate the floor control server before sending any BFCP message to it or accepting any BFCP message from it. Similarly, floor control servers SHOULD authenticate a client before accepting any BFCP message from it or sending any BFCP message to it.
BFCPクライアントは、BFCPメッセージを送信する前にFloor Controlサーバーを認証したり、そこからのBFCPメッセージを受け入れたりする必要があります。同様に、Floor Controlサーバーは、BFCPメッセージを受け入れる前にクライアントを認証したり、BFCPメッセージを送信したりする必要があります。
If the signaling or control protocol traffic used to set up the conference is authenticated and confidentiality and integrity protected, and the extensions in this document are supported, the BFCP clients MUST authenticate the floor control server, and the floor control servers MUST authenticate the client before communicating as described above. Note that BFCP entities supporting only the [3] subset may not comply with this mandatory authentication requirement.
会議の設定に使用されたシグナリングまたは制御プロトコルトラフィックが認証され、保護されていて、このドキュメントの拡張機能がサポートされている場合、BFCPクライアントはFloor Control Serverを認証し、フロアコントロールサーバーは前にクライアントを認証する必要があります。上記の通信[3]サブセットのみをサポートするBFCPエンティティは、この必須認証要件に準拠していない可能性があります。
BFCP supports TLS/DTLS mutual authentication between clients and floor control servers, as specified in Section 9.1. This is the RECOMMENDED authentication mechanism in BFCP.
BFCPは、セクション9.1で指定されているように、クライアントとフロア制御サーバー間のTLS / DTLSの相互認証をサポートしています。これはBFCPの推奨認証メカニズムです。
Note that future extensions may define additional authentication mechanisms.
将来の拡張機能は追加の認証メカニズムを定義することがあります。
In addition to authenticating BFCP messages, floor control servers need to authorize them. On receiving an authenticated BFCP message, the floor control server checks whether the client sending the message is authorized. If the client is not authorized to perform the operation being requested, the floor control server generates an Error message, as described in Section 13.8, with an error code with a value of 5 (Unauthorized Operation). Messages from a client that cannot be authorized MUST NOT be processed further.
BFCPメッセージの認証に加えて、Floor Controlサーバーはそれらを承認する必要があります。認証されたBFCPメッセージを受信すると、フロアコントロールサーバーは、メッセージを送信するクライアントが許可されているかどうかを確認します。クライアントが要求されている操作を実行することを許可されていない場合、フロアコントロールサーバーはセクション13.8で説明されているように、エラーコードを5（不正な動作）のエラーコードを生成します。許可されないクライアントからのメッセージは、さらに処理されてはいけません。
BFCP supports TLS/DTLS based mutual authentication between clients and floor control servers. If TLS/DTLS is used, an initial integrity-protected channel is REQUIRED between the client and the floor control server that can be used to exchange their certificates (which MAY be self-signed certificates) or, more commonly, the fingerprints of these certificates. These certificates are used at TLS/DTLS establishment time.
BFCPは、クライアントとフロア制御サーバー間のTLS / DTLSベースの相互認証をサポートしています。TLS / DTLSが使用されている場合、クライアントとフロアコントロールサーバーとの間に初期の整合性保護チャネルが必要です（これは自己署名証明書である可能性がある）、またはより一般的にこれらの証明書の指紋を交換するために必要です。。これらの証明書はTLS / DTLS確立時間で使用されています。
| The implementation of such an integrity-protected channel using | SIP and the SDP offer/answer model is described in [12].
BFCP messages received over an authenticated TLS/DTLS connection are considered authenticated. A floor control server that receives a BFCP message over TCP/UDP (no TLS/DTLS) MAY request the use of TLS/ DTLS by generating an Error message, as described in Section 13.8, with an error code with a value of 9 (Use TLS) or a value of 11 (Use DTLS) respectively. Clients configured to require the use of TLS/ DTLS MUST ignore unauthenticated messages.
認証されたTLS / DTLS接続で受信されたBFCPメッセージは、認証されたと見なされます。TCP / UDPを介してBFCPメッセージを受信するFloor Controlサーバー（TLS / DTLSなし）は、セクション13.8で説明されているように、エラーコードを9の値のエラーコードで生成することによってTLS / DTLSの使用を要求することができます（使用）。TLS）または11の値（DTLSを使用）。TLS / DTLを使用するように設定されたクライアントは、未認証メッセージを無視する必要があります。
Note that future extensions may define additional authentication mechanisms that may not require an initial integrity-protected channel (e.g., authentication based on certificates signed by a certificate authority).
将来の拡張機能は、初期の整合性保護チャネル（例えば、認証局によって署名された証明書に基づく認証）を必要としないかもしれない追加の認証メカニズムを定義するかもしれないことに注意してください。
As described in Section 9, floor control servers need to perform authorization before processing any message. In particular, the floor control server MUST check that messages arriving over a given authenticated TLS/DTLS connection use an authorized User ID (i.e., a User ID that the user that established the authenticated TLS/DTLS connection is allowed to use).
セクション9で説明されているように、Floor Controlサーバーはメッセージを処理する前に承認を実行する必要があります。特に、Floor Controlサーバーは、指定された認証されたTLS / DTLS接続に到達するメッセージが許可ユーザーIDを使用していることを確認しなければなりません（すなわち、認証されたTLS / DTLS接続を確立するユーザが使用することが許可されているユーザID）。
This section specifies how floor participants can perform different operations, such as requesting a floor, using the protocol elements described in earlier sections. Section 11 specifies operations that are specific to floor chairs, such as instructing the floor control server to grant or revoke a floor, and Section 12 specifies operations that can be performed by any client (i.e., both floor participants and floor chairs).
このセクションでは、前のセクションで説明されているプロトコル要素を使用して、フロア参加者がフロアの要求など、さまざまな操作を実行できる方法を指定します。セクション11は、フロア制御サーバに階を付与または取り消すように指示するなど、フロアチェアに固有の操作を指定し、セクション12は任意のクライアント（すなわち、フロア参加者およびフロアチェアの両方）によって実行できる操作を特定する。
A floor participant that wishes to request one or more floors does so by sending a FloorRequest message to the floor control server.
1つ以上のフロアを要求したいフロア参加者は、FloorRequestメッセージをフロアコントロールサーバーに送信することによって実行します。
The ABNF in Section 5.3.1 describes the attributes that a FloorRequest message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
5.3.1項のABNFでは、FloarRequestメッセージに含めることができる属性について説明します。さらに、ABNFは、通常、これらの属性が必須であり、どちらがオプションであるかを指定します。
The floor participant sets the Conference ID and the Transaction ID in the COMMON-HEADER following the rules given in Section 8.1.
フロア参加者は、セクション8.1に記載されている規則に従って、Commane IDとトランザクションIDを共通ヘッダーに設定します。
The floor participant sets the User ID in the COMMON-HEADER to the floor participant's identifier. If the sender of the FloorRequest message (identified by the User ID) is not the participant that would eventually get the floor (i.e., a third-party floor request), the sender SHOULD add a BENEFICIARY-ID attribute to the message identifying the beneficiary of the floor.
フロア参加者は、共通ヘッダーのユーザーIDをフロア参加者の識別子に設定します。FloorRequestメッセージの送信者（ユーザーIDによって識別される）が、最終的にフロアを取得する（すなわちサードパーティのフロア要求）、送信者は受益者を識別するメッセージに受益者ID属性を追加する必要があります。床の。
| Note that the namespace for both the User ID and the
| Beneficiary ID is the same. That is, a given participant is
| identified by a single 16-bit value that can be used in the
| User ID in the COMMON-HEADER and in several attributes:
| BENEFICIARY-ID, BENEFICIARY-INFORMATION, and REQUESTED-BY-
| INFORMATION.
The floor participant MUST insert at least one FLOOR-ID attribute in the FloorRequest message. If the client inserts more than one FLOOR-ID attribute, the floor control server will treat all the floor requests as an atomic package. That is, the floor control server will either grant or deny all the floors in the FloorRequest message.
フロア参加者は、FloorRequestメッセージに少なくとも1つのFLOOR-ID属性を挿入する必要があります。クライアントが複数のFLOOR-ID属性を挿入すると、Floor Controlサーバーはすべてのフロア要求をアトミックパッケージとして扱います。つまり、Floor ControlサーバーはFloorRequestメッセージ内のすべてのフロアを付与または拒否します。
The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute to state the reason why the floor or floors are being requested. The Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for human consumption.
フロア参加者は、参加者提供情報属性を使用して、床や床が要求されている理由を述べることができます。参加者提供info属性のテキストフィールドは、人間の消費を目的としています。
The floor participant may request that the server handle the floor request with a certain priority using a PRIORITY attribute.
フロア参加者は、優先属性を使用してサーバーが特定の優先順位でフロア要求を処理するように要求することができます。
A message from the floor control server is considered a response to the FloorRequest message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication.
フロア制御サーバからのメッセージは、フロアコントロールサーバからのメッセージがFloorRequestメッセージとして同じ会議ID、トランザクションID、およびユーザIDを有する場合、FloorRequestメッセージに対する応答と見なされる。このような応答を受けると、フロアの参加者はフロアコントロールサーバー認証に関連するセクション9の規則に従います。
The successful processing of a FloorRequest message at the floor control server involves generating one or several FloorRequestStatus messages. The floor participant obtains a Floor Request ID in the Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in the first FloorRequestStatus message from the floor control server. Subsequent FloorRequestStatus messages from the floor control server regarding the same floor request will carry the same Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute as the initial FloorRequestStatus message. This way, the floor participant can associate subsequent incoming FloorRequestStatus messages with the ongoing floor request.
Floor Control ServerでのFloarRequestメッセージの処理が成功すると、1つまたは複数のFloarQuestStatusメッセージを生成することが含まれます。フロア参加者は、Floor Control Serverからの最初のFloorRequestStatusメッセージのフロア要求情報属性のFloor要求IDフィールドにフロアリクエストIDを取得します。同じフロア要求に関するフロアコントロールサーバーからのFloorRequestStatusメッセージは、Floor-Request-Information属性で最初のFloorRequestStatusメッセージとして同じフロア要求IDを持ちます。このようにして、フロア参加者は後続の入ってくるFloorRequestStatusメッセージを進行中のフロア要求に関連付けることができます。
The floor participant obtains information about the status of the floor request in the FLOOR-REQUEST-INFORMATION attribute of each of the FloorRequestStatus messages received from the floor control server. This attribute is a grouped attribute, and as such it includes a number of attributes that provide information about the floor request.
フロア参加者は、フロアコントロールサーバーから受信した各FloareQuestStatusメッセージのフロア要求情報属性のフロア要求のステータスに関する情報を取得します。この属性はグループ化された属性であり、そのように、フロア要求に関する情報を提供する多数の属性が含まれています。
The OVERALL-REQUEST-STATUS attribute provides information about the overall status of the floor request. If the Request Status value is Granted, all the floors that were requested in the FloorRequest message have been granted. If the Request Status value is Denied, all the floors that were requested in the FloorRequest message have been denied. A floor request is considered to be ongoing while it is in the Pending, Accepted, or Granted states. If the floor request value is unknown, then the response is still processed. However, no meaningful value can be reported to the user.
uspart-request-status属性は、フロア要求の全体的なステータスに関する情報を提供します。要求ステータス値が付与されている場合は、FloorRequestメッセージで要求されたすべてのフロアが付与されました。要求ステータス値が拒否された場合、FloorRequestメッセージで要求されたすべてのフロアが拒否されました。床の要求は、保留中の、受け入れられた、または付与された状態にある間、継続的であると考えられています。フロア要求値が不明な場合、応答は依然として処理されます。ただし、ユーザーにわかりやすい値は報告できません。
The STATUS-INFO attribute, if present, provides extra information that the floor participant can display to the user.
status-info属性が存在する場合は、フロア参加者がユーザーに表示できる追加情報を提供します。
The FLOOR-REQUEST-STATUS attributes provide information about the status of the floor request as it relates to a particular floor. The STATUS-INFO attribute, if present, provides extra information that the floor participant can display to the user.
floor-request-status属性は、特定の階に関連する階の要求の状況に関する情報を提供します。status-info属性が存在する場合は、フロア参加者がユーザーに表示できる追加情報を提供します。
The BENEFICIARY-INFORMATION attribute identifies the beneficiary of the floor request in third-party floor requests. The REQUESTED-BY-INFORMATION attribute need not be present in FloorRequestStatus messages received by the floor participant that requested the floor, as this floor participant is already identified by the User ID in the COMMON-HEADER.
受益者情報属性は、サードパーティの階の要求におけるフロア要求の受益者を識別します。この階の参加者は、この階の参加者がCommon-HeaderのユーザーIDによって識別されているため、要求された情報属性は、フロア参加者によって受信されたFloor参加者によって受信されたFloorRequestStatusメッセージに存在する必要はありません。
The PRIORITY attribute, when present, contains the priority that was requested by the generator of the FloorRequest message.
優先属性は、存在する場合、FloorRequestメッセージのジェネレータによって要求された優先順位を含みます。
If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message.
応答がエラーメッセージである場合、Floor ControlサーバーはFloorRequestメッセージを処理できませんでした。これはエラーメッセージで説明されています。
When communicating over an unreliable transport and upon receiving a FloorRequestStatus message from a floor control server, the participant MUST respond with a FloorRequestStatusAck message within the transaction failure window to complete the transaction.
信頼性の低いトランスポートを介して通信するとき、フロアコントロールサーバーからFloorRequestStatusメッセージを受信すると、参加者はトランザクションの障害ウィンドウ内のFloorRequestStatusAckメッセージで応答する必要があります。
A floor participant that wishes to cancel an ongoing floor request does so by sending a FloorRelease message to the floor control server. The FloorRelease message is also used by floor participants that hold a floor and would like to release it.
進行中のフロア要求をキャンセルしたいフロア参加者は、フロレールドコントロールサーバーにフローレーレードメッセージを送信することによってそうします。フローレアーゼメッセージは、床を保持し、それを解放したい床参加者によっても使用されます。
The ABNF in Section 5.3.2 describes the attributes that a FloorRelease message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.2のABNFは、フロレールドメッセージに含めることができる属性を説明しています。さらに、ABNFは、通常、これらの属性が必須であり、どちらがオプションであるかを指定します。
The floor participant sets the Conference ID and the Transaction ID in the COMMON-HEADER following the rules given in Section 8.1. The floor participant sets the User ID in the COMMON-HEADER to the floor participant's identifier.
フロア参加者は、セクション8.1に記載されている規則に従って、Commane IDとトランザクションIDを共通ヘッダーに設定します。フロア参加者は、共通ヘッダーのユーザーIDをフロア参加者の識別子に設定します。
| Note that the FloorRelease message is used to release a floor
| or floors that were granted and to cancel ongoing floor
| requests (from the protocol perspective, both are ongoing floor
| requests). Using the same message in both situations helps
| resolve the race condition that occurs when the FloorRelease
| message and the FloorGrant message cross each other on the
| wire.
The floor participant uses the FLOOR-REQUEST-ID that was received in the response to the FloorRequest message that the FloorRelease message is cancelling.
Floor参加者は、FloheReleaseメッセージがキャンセルされているFloorRequestメッセージへの返信で受信されたフロア要求IDを使用します。
| Note that if the floor participant requested several floors as
| an atomic operation (i.e., in a single FloorRequest message),
| all the floors are released as an atomic operation as well
| (i.e., all are released at the same time).
A message from the floor control server is considered a response to the FloorRelease message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRelease message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication.
フロア制御サーバからのメッセージは、フロア制御サーバからのメッセージが同じ会議ID、トランザクションID、およびユーザIDを有する場合、セクション8.1で説明されているように、フローレーレードメッセージに対する応答と見なされる。このような応答を受けると、フロアの参加者はフロアコントロールサーバー認証に関連するセクション9の規則に従います。
If the response is a FloorRequestStatus message, the Request Status value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) will be Cancelled or Released.
応答がFloorRequestStatusメッセージの場合、request-status属性（floar-request-information属性内）の要求ステータス値はキャンセルまたはリリースされます。
If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message.
応答がエラーメッセージである場合、Floor ControlサーバーはFloorRequestメッセージを処理できませんでした。これはエラーメッセージで説明されています。
It is possible that the FloorRelease message crosses on the wire with a FloorRequestStatus message from the server with a Request Status different from Cancelled or Released. In any case, such a FloorRequestStatus message will not be a response to the FloorRelease message, as its Transaction ID will not match that of the FloorRelease.
フローレーエースメッセージは、キャンセルまたはリリースとは異なる要求ステータスを持つサーバからFloarRequestStatusメッセージを使用してワイヤを交差させることが可能です。いずれにせよ、そのようなFloarQuestStatusメッセージは、そのトランザクションIDがFLORERELEASEのそれと一致しないため、FlooReleaseメッセージに対する応答ではありません。
This section specifies how floor chairs can instruct the floor control server to grant or revoke a floor using the protocol elements described in earlier sections.
このセクションでは、前のセクションで説明されているプロトコル要素を使用してフロアチェアにフロア制御サーバーにフロアコントロールサーバーに指示することができる方法を指定します。
Floor chairs that wish to send instructions to a floor control server do so by sending a ChairAction message.
フロアコントロールサーバーに指示を送信したいフロアチェアは、委員長メッセージを送信することによってそうします。
The ABNF in Section 5.3.9 describes the attributes that a ChairAction message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.9のABNFは、議長メッセージを含むことができる属性を説明しています。さらに、ABNFは、通常、これらの属性が必須であり、どちらがオプションであるかを指定します。
The floor chair sets the Conference ID and the Transaction ID in the COMMON-HEADER following the rules given in Section 8.1. The floor chair sets the User ID in the COMMON-HEADER to the floor chair's identifier.
フロアチェアは、セクション8.1に記載されている規則に従って、会議IDとトランザクションIDを共通ヘッダーに設定します。フロアチェアは、一般的なヘッダーのユーザーIDをフロアチェアの識別子に設定します。
The ChairAction message contains instructions that apply to one or more floors within a particular floor request. The floor or floors are identified by the FLOOR-REQUEST-STATUS attributes and the floor request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which are carried in the ChairAction message.
議長メッセージには、特定のフロア要求内の1つ以上のフロアに適用される命令が含まれています。フロアまたはフロアは、フロアリクエストステータス属性によって識別され、フロア要求は議長要求情報ヘッダによって識別され、これは議長メッセージで運ばれます。
For example, if a floor request consists of two floors that depend on different floor chairs, each floor chair will grant its floor within the floor request. Once both chairs have granted their floor, the floor control server will grant the floor request as a whole. On the other hand, if one of the floor chairs denies its floor, the floor control server will deny the floor request as a whole, regardless of the other floor chair's decision.
たとえば、フロアリクエストが異なるフロアチェアに依存する2階からなる場合、各階の椅子は床の要求内でその床を付与します。両方の椅子が彼らの床を与えたら、フロアコントロールサーバーはフロアリクエスト全体を付与します。一方、フロアチェアの1人がその床を否定すると、フロアコントロールサーバーは他の階の椅子の決定にかかわらず、全体として床の要求を否定します。
The floor chair provides the new status of the floor request as it relates to a particular floor using a FLOOR-REQUEST-STATUS attribute. If the new status of the floor request is Accepted, the floor chair MAY use the Queue Position field to provide a queue position for the floor request. If the floor chair does not wish to provide a queue position, all the bits of the Queue Position field MUST be set to zero. The floor chair MUST use the Status Revoked to revoke a floor that was granted (i.e., Granted status) and MUST use the Status Denied to reject floor requests in any other status (e.g., Pending and Accepted).
フロアチェアは、階頭要求 - ステータス属性を使用して特定のフロアに関連する場合、フロアリクエストの新しいステータスを提供します。フロア要求の新しいステータスが受け入れられている場合、フロアチェアはフロア要求のためのキュー位置を提供するためにキュー位置フィールドを使用することができる。フロアチェアがキュー位置を提供したくない場合は、キュー位置フィールドのすべてのビットをゼロに設定する必要があります。床の椅子は、付与されたフロアを取り消すために失効されたステータスを使用しなければならず（すなわち、ステータスを付与されています）、他のステータスで床の要求を拒否することが拒否されたステータスを使用する必要があります（例えば、保留中および承認済み）。
The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the ChairAction message to provide a new overall status for the floor request. If the new overall status of the floor request is Accepted, the floor chair can use the Queue Position field to provide a queue position for the floor request.
床の椅子は、議長要求の新しい全体的なステータスを提供するために、議長の範囲内容属性を委員会に追加することができます。フロア要求の新しい全体的なステータスが受け入れられている場合、フロアチェアはフロア要求のためのキュー位置を提供するためにキュー位置フィールドを使用することができます。
| Note that a particular floor control server can implement a
| different queue for each floor containing all the floor
| requests that relate to that particular floor, a general queue
| for all floor requests, or both. Also note that a floor
| request can involve several floors and that a ChairAction
| message can only deal with a subset of these floors (e.g., if a
| single floor chair is not authorized to manage all the floors).
| In this case, the floor control server will combine the
| instructions received from the different floor chairs in FLOOR-
| REQUEST-STATUS attributes to come up with the overall status of
| the floor request.
|
| Note that, while the action of a floor chair may communicate
| information in the OVERALL-REQUEST-STATUS attribute, the floor
| control server may override, modify, or ignore this field's
| content.
The floor chair MAY include STATUS-INFO attributes to state the reason why the floor or floors are being accepted, granted, or revoked. The Text in the STATUS-INFO attribute is intended for human consumption.
床の椅子は、床や床が受け入れられ、付与された、または取り消されている理由を述べるステータス情報属性を含み得る。status-info属性のテキストは人間の消費を目的としています。
A message from the floor control server is considered a response to the ChairAction message if the message from the server has the same Conference ID, Transaction ID, and User ID as the ChairAction message, as described in Section 8.1. On receiving such a response, the floor chair follows the rules in Section 9 that relate to floor control server authentication.
サーバからのメッセージが、セクション8.1で説明されているように、サーバからのメッセージが同じ会議ID、トランザクションID、およびユーザIDを有する場合、フロアコントロールサーバからのメッセージは議長メッセージに対する応答と見なされる。このような応答を受けると、フロアチェアはフロアコントロールサーバー認証に関連するセクション9の規則に従います。
A ChairActionAck message from the floor control server confirms that the floor control server has accepted the ChairAction message. An Error message indicates that the floor control server could not process the ChairAction message for some reason, which is described in the Error message.
フロアコントロールサーバーからの議長のメッセージは、フロアコントロールサーバーが委員会メッセージを受け入れたことを確認します。エラーメッセージは、エラーメッセージで説明されている何らかの理由でフロアコントロールサーバーが議長管理サーバーを処理できなかったことを示しています。
This section specifies operations that can be performed by any client. That is, they are not specific to floor participants or floor chairs. They can be performed by both.
このセクションでは、任意のクライアントによって実行できる操作を指定します。つまり、床の参加者や床の椅子に特有のものではありません。それらは両方で実行できます。
A client can obtain information about the status of a floor or floors in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.
クライアントは、BFCPを使用し、帯域外のメカニズムを使用することを含む、さまざまな方法で、フロアまたはフロアのステータスに関する情報を取得できます。そのような情報を取得するためにBFCPを使用するクライアントは、このセクションに記載されている手順を使用しています。
Clients request information about the status of one or several floors by sending a FloorQuery message to the floor control server.
クライアントは、フロアクエリメッセージをFloor Controlサーバーに送信することで、1つまたは複数のフロアのステータスに関する情報を要求します。
The ABNF in Section 5.3.7 describes the attributes that a FloorQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.7のABNFは、Forequeryメッセージに含めることができる属性を説明しています。さらに、ABNFは、通常、これらの属性が必須であり、どちらがオプションであるかを指定します。
The client sets the Conference ID and the Transaction ID in the COMMON-HEADER following the rules given in Section 8.1. The client sets the User ID in the COMMON-HEADER to the client's identifier.
クライアントは、セクション8.1に記載されている規則に従って、Commane IDとトランザクションIDを共通ヘッダーに設定します。クライアントは、Common-HeaderのユーザーIDをクライアントの識別子に設定します。
The client inserts in the message all the Floor IDs it wants to receive information about. The floor control server will send periodic information about all of these floors. If the client does not want to receive information about a particular floor any longer, it sends a new FloorQuery message removing the FLOOR-ID of this floor. If the client does not want to receive information about any floor any longer, it sends a FloorQuery message with no FLOOR-ID attribute.
クライアントは、メッセージを受信したいすべてのフロアIDをメッセージに挿入します。Floor Controlサーバーは、これらすべてのフロアに関する定期的な情報を送信します。クライアントが特定のフロアに関する情報をもう少し受信したくない場合は、この階のフロアIDを削除する新しいフロアクエリメッセージを送信します。クライアントが何らかのフロアに関する情報を受信したくない場合は、FLOOR-ID属性のないFloreQueryメッセージを送信します。
A message from the floor control server is considered a response to the FloorQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
フロア制御サーバからのメッセージは、フロア制御サーバからのメッセージがフロアクエリメッセージとして同じ会議ID、トランザクションID、およびユーザIDを有する場合、フロアクエリメッセージに対する応答と見なされる.8.1。このような応答を受信すると、クライアントはFloor Control Server認証に関連するセクション9の規則に従います。
On reception of the FloorQuery message, the floor control server MUST respond with a FloorStatus message or with an Error message. If the response is a FloorStatus message, it will contain information about one of the floors the client requested information about. If the client did not include any FLOOR-ID attribute in its FloorQuery message (i.e., the client does not want to receive information about any floor any longer), the FloorStatus message from the floor control server will not include any FLOOR-ID attribute either.
FloreQueryメッセージを受信すると、Floor ControlサーバーはFloorStatusメッセージまたはエラーメッセージで応答する必要があります。応答がFloorStatusメッセージの場合は、クライアントが要求された情報が要求されたフロアの1つに関する情報が含まれます。クライアントにFloreQueryメッセージにFloor-ID属性が含まれていなかった場合（すなわち、クライアントはより長いフロアに関する情報を受信したくない）、Floor ControlサーバーからのFloorStatusメッセージには、FLOOR-ID属性は含まれません。。
FloorStatus messages that carry information about a floor contain a FLOOR-ID attribute that identifies the floor. After this attribute, FloorStatus messages contain information about existing (one or more) floor requests that relate to that floor. The information about each particular floor request is encoded in a FLOOR-REQUEST-INFORMATION attribute. This grouped attribute carries a Floor Request ID that identifies the floor request, followed by a set of attributes that provide information about the floor request.
Floorに関する情報を運ぶFloorStatusメッセージには、フロアを識別するFLOOR-ID属性が含まれています。この属性の後、FloorStatusメッセージには、その階に関連する既存の（1つ以上）の階層要求に関する情報が含まれています。各特定のフロア要求に関する情報は、フロア要求情報属性でエンコードされています。このグループ化された属性は、フロア要求を識別するフロアリクエストIDを実行し、続いてフロア要求に関する情報を提供する一連の属性を搬送します。
After the first FloorStatus, the floor control server will continue sending FloorStatus messages, periodically informing the client about changes on the floors the client requested information about.
最初のORERSTATUSの後、Floor Sturbe ServerはFloorStatusメッセージを送信し続け、クライアントにクライアントがクライアントに要求された情報について定期的に通知します。
When communicating over an unreliable transport and upon receiving a FloorStatus message from a floor control server, the participant MUST respond with a FloorStatusAck message within the transaction failure window to complete the transaction.
信頼性の低いトランスポートを介して通信するとき、フロアコントロールサーバーからFloorStatusメッセージを受信すると、参加者はトランザクションの障害ウィンドウ内のFloorStatusAckメッセージで応答してトランザクションを完了する必要があります。
A client can obtain information about the status of one or several floor requests in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.
クライアントは、BFCPを使用し、帯域外のメカニズムを使用することを含む、異なる方法で1つまたは複数の階の要求のステータスに関する情報を取得できます。そのような情報を取得するためにBFCPを使用するクライアントは、このセクションに記載されている手順を使用しています。
Clients request information about the current status of a floor request by sending a FloorRequestQuery message to the floor control server.
クライアントは、Floor RequestQueryメッセージをFloor Controlサーバーに送信することで、現在のステータスに関する情報を要求します。
Requesting information about a particular floor request is useful in a number of situations. For example, on reception of a FloorRequest message, a floor control server may choose to return FloorRequestStatus messages only when the floor request changes its state (e.g., from Accepted to Granted), but not when the floor request advances in its queue. In this situation, if the user requests it, the floor participant can use a FloorRequestQuery message to poll the floor control server for the status of the floor request.
特定のフロア要求に関する情報を要求することは、いくつかの状況で役立ちます。たとえば、FloorRequestメッセージを受信すると、フロアコントロールサーバーは、フロア要求がその状態（例えば許可されたことから許可されたものから）を変更するが、フロア要求がそのキューに進みます。この状況では、ユーザーが要求した場合、Floor参加者はFloorRequestQueryメッセージを使用してフロアコントロールサーバーをポーリングすることができます。
The ABNF in Section 5.3.3 describes the attributes that a FloorRequestQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
5.3.3項のABNFは、FloorRequestQueryメッセージに含めることができる属性を説明しています。さらに、ABNFは、通常、これらの属性が必須であり、どちらがオプションであるかを指定します。
The client sets the Conference ID and the Transaction ID in the COMMON-HEADER following the rules given in Section 8.1. The client sets the User ID in the COMMON-HEADER to the client's identifier.
クライアントは、セクション8.1に記載されている規則に従って、Commane IDとトランザクションIDを共通ヘッダーに設定します。クライアントは、Common-HeaderのユーザーIDをクライアントの識別子に設定します。
The client MUST insert a FLOOR-REQUEST-ID attribute that identifies the floor request at the floor control server.
クライアントは、フロアコントロールサーバーでのフロア要求を識別するFLOOR-REQUEST-ID属性を挿入する必要があります。
A message from the floor control server is considered a response to the FloorRequestQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequestQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
フロアコントロールサーバからのメッセージは、セクション8.1で説明されているように、フロアコントロールサーバからのメッセージが同じ会議ID、トランザクションID、およびユーザIDを有する場合、FloorRequestQueryメッセージに対する応答と見なされる。このような応答を受信すると、クライアントはFloor Control Server認証に関連するセクション9の規則に従います。
If the response is a FloorRequestStatus message, the client obtains information about the status of the FloorRequest the client requested information about in a FLOOR-REQUEST-INFORMATION attribute.
応答がFloorRequestStatusメッセージである場合、クライアントはFloorRequestのStatueに関する情報をLoare-Request-Information属性に関連付けて要求しています。
If the response is an Error message, the floor control server could not process the FloorRequestQuery message for some reason, which is described in the Error message.
応答がエラーメッセージである場合、Floor Controlサーバーは何らかの理由でFloorRequestQueryメッセージを処理できませんでした。これはエラーメッセージで説明されています。
A client can obtain information about a participant and the floor requests related to this participant in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.
クライアントは、BFCPを使用し、帯域外のメカニズムを使用することを含む、参加者とこの参加者に関連するフロア要求とさまざまな方法で情報を入手できます。そのような情報を取得するためにBFCPを使用するクライアントは、このセクションに記載されている手順を使用しています。
Clients request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server.
クライアントは、Floor Control Serverにユーザークエリメッセージを送信することによって、参加者とこの参加者に関連するフロア要求に関する情報を要求します。
This functionality may be useful for floor chairs or floor participants interested in the display name and the URI of a particular floor participant. In addition, a floor participant may find it useful to request information about itself. For example, a floor participant, after experiencing connectivity problems (e.g., its TCP connection with the floor control server was down for a while and eventually was re-established), may need to request information about all the floor requests associated to itself that still exist.
この機能は、床椅子や床の参加者や床の参加者が特定のフロア参加者の表示名とURIに関心があるかもしれません。さらに、フロア参加者は、それ自身に関する情報を要求するのに役立つことがあります。例えば、接続性の問題を経験した後（例えば、フロア制御サーバとのTCP接続はしばらくそして最終的に再確立された）、それ自体に関連するすべての階に関連するすべての階に関連するすべての階の要求に関する情報を要求する必要があるかもしれない。存在します。
The ABNF in Section 5.3.5 describes the attributes that a UserQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.5のABNFは、ユーザークエリメッセージに含めることができる属性を説明しています。さらに、ABNFは、通常、これらの属性が必須であり、どちらがオプションであるかを指定します。
The client sets the Conference ID and the Transaction ID in the COMMON-HEADER following the rules given in Section 8.1. The client sets the User ID in the COMMON-HEADER to the client's identifier.
クライアントは、セクション8.1に記載されている規則に従って、Commane IDとトランザクションIDを共通ヘッダーに設定します。クライアントは、Common-HeaderのユーザーIDをクライアントの識別子に設定します。
If the floor participant the client is requesting information about is not the client issuing the UserQuery message (which is identified by the User ID in the COMMON-HEADER of the message), the client MUST insert a BENEFICIARY-ID attribute.
クライアントが情報を要求しているフロア参加者が、ユーザークエリメッセージを発行しているクライアントではありません（メッセージの共通ヘッダーのユーザーIDによって識別されます）、クライアントは受益者ID属性を挿入する必要があります。
A message from the floor control server is considered a response to the UserQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the UserQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
フロア制御サーバからのメッセージが、セクション8.1で説明されているように、フロア制御サーバからのメッセージがユーザクエリメッセージへの応答と見なされる。このような応答を受信すると、クライアントはFloor Control Server認証に関連するセクション9の規則に従います。
If the response is a UserStatus message, the client obtains information about the floor participant in a BENEFICIARY-INFORMATION grouped attribute and about the status of the floor requests associated with the floor participant in FLOOR-REQUEST-INFORMATION attributes.
応答がUserStatusメッセージである場合、クライアントは受益者情報グループ化された属性のフロア参加者に関する情報と、フロア要求情報属性のフロア参加者に関連するフロア要求のステータスについて取得します。
If the response is an Error message, the floor control server could not process the UserQuery message for some reason, which is described in the Error message.
応答がエラーメッセージである場合、Floor Controlサーバーは何らかの理由でユーザークエリメッセージを処理できませんでした。これはエラーメッセージで説明されています。
A client that wishes to obtain the capabilities of a floor control server does so by sending a Hello message to the floor control server.
フロアコントロールサーバーの機能を取得したいクライアントは、HelloメッセージをFloor Control Serverに送信することによってそうします。
The ABNF in Section 5.3.11 describes the attributes that a Hello message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.
セクション5.3.11のABNFは、Helloメッセージに含めることができる属性を説明しています。さらに、ABNFは、通常、これらの属性が必須であり、どちらがオプションであるかを指定します。
The client sets the Conference ID and the Transaction ID in the COMMON-HEADER following the rules given in Section 8.1. The client sets the User ID in the COMMON-HEADER to the client's identifier.
クライアントは、セクション8.1に記載されている規則に従って、Commane IDとトランザクションIDを共通ヘッダーに設定します。クライアントは、Common-HeaderのユーザーIDをクライアントの識別子に設定します。
A message from the floor control server is considered a response to the Hello message by the client if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the Hello message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication.
フロア制御サーバからのメッセージは、フロア制御サーバからのメッセージが同じ会議ID、トランザクションID、およびユーザIDをHELLOメッセージとして有する場合、クライアントによるHELLOメッセージに対する応答と見なされる。このような応答を受信すると、クライアントはFloor Control Server認証に関連するセクション9の規則に従います。
If the response is a HelloAck message, the floor control server could process the Hello message successfully. The SUPPORTED-PRIMITIVES and SUPPORTED-ATTRIBUTES attributes indicate which primitives and attributes, respectively, are supported by the server.
応答がHelloackメッセージの場合、Floor Controlサーバーはhelloメッセージを正常に処理できます。サポートされているプリミティブとサポートされている属性属性は、それぞれサーバーによってそれぞれどのプリミティブと属性をサポートしているかを示します。
If the response is an Error message, the floor control server could not process the Hello message for some reason, which is described in the Error message.
応答がエラーメッセージである場合、フロアコントロールサーバーは何らかの理由でHelloメッセージを処理できませんでした。これはエラーメッセージで説明されています。
This section specifies how floor control servers can perform different operations, such as granting a floor, using the protocol elements described in earlier sections.
このセクションでは、前のセクションで説明されているプロトコル要素を使用して、フロア制御サーバーがフロアの付与など、異なる操作を実行する方法を指定します。
On reception of a message from a client, the floor control server MUST check whether the value of the primitive is supported. If it is not, the floor control server MUST send an Error message, as described in Section 13.8, with Error Code 3 (Unknown Primitive).
クライアントからのメッセージを受信すると、Floor Controlサーバーはプリミティブの値がサポートされているかどうかを確認する必要があります。そうでない場合、Section 13.8で説明されているように、Floor Controlサーバーはエラーメッセージ3（不明プリミティブ）を指定してエラーメッセージを送信する必要があります。
On reception of a message from a client, the floor control server MUST check whether the value of the Conference ID matched an existing conference. If it does not, the floor control server MUST send an Error message, as described in Section 13.8, with Error Code 1 (Conference Does Not Exist).
クライアントからのメッセージを受信すると、フロア制御サーバは、会議IDの値が既存の会議と一致したかどうかを確認する必要があります。そうでない場合、Floor Controlサーバーはエラーコード1で説明されているように、エラーメッセージを送信しなければなりません（会議は存在しません）。
On reception of a message from a client, the floor control server follows the rules in Section 9 that relate to the authentication of the message.
クライアントからのメッセージを受信すると、Floor Controlサーバーは、メッセージの認証に関連するセクション9の規則に従います。
On reception of a message from a client, the floor control server MUST check whether it understands all the mandatory ('M' bit set) attributes in the message. If the floor control server does not understand all of them, the floor control server MUST send an Error message, as described in Section 13.8, with Error Code 4 (Unknown Mandatory Attribute). The Error message SHOULD list the attributes that were not understood.
クライアントからのメッセージを受信すると、Floor Controlサーバーはメッセージ内のすべての必須（ 'M'ビットセット）属性を理解しているかどうかを確認する必要があります。Floor Controlサーバーがそれらのすべてを理解していない場合は、セクション13.8で説明されているように、エラーコード4（不明な必須属性）でエラーメッセージを送信する必要があります。エラーメッセージは理解されていなかった属性をリストする必要があります。
On reception of a FloorRequest message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequest message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8.
FloorRequestメッセージを受信すると、Floor Controlサーバーはクライアント認証と許可に関連するセクション9の規則に従います。FloorRequestメッセージを処理している間に、Floor Controlサーバーはエラーに遭遇し、セクション13.8に記載されている手順に従ってエラー応答を生成する必要があります。
| BFCP allows floor participants to have several ongoing floor
| requests for the same floor (e.g., the same floor participant
| can occupy more than one position in a queue at the same time).
| A floor control server that only supports a certain number of
| ongoing floor requests per floor participant (e.g., one) can
| use Error Code 8 (You have Already Reached the Maximum Number
| of Ongoing Floor Requests for This Floor) to inform the floor
| participant.
When communicating over an unreliable transport and upon receiving a FloorRequest from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction.
信頼性の低い輸送を通信し、参加者からFloareRequestを受信すると、フロアコントロールサーバーはトランザクションの失敗ウィンドウ内でFloorRequestStatusメッセージで応答する必要があります。
The successful processing of a FloorRequest message by a floor control server involves generating one or several FloorRequestStatus messages, the first of which SHOULD be generated as soon as possible. If the floor control server cannot accept, grant, or deny the floor request right away (e.g., a decision from a chair is needed), it SHOULD use a Request Status value of Pending in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message it generates.
Floor Control ServerによるFloorRequestメッセージの処理が成功すると、1つまたは複数のFloarRequestStatusメッセージを生成することが含まれます。フロアコントロールサーバーがすぐにフロアリクエストを承認できません（例：議長からの決定が必要な場合）、request-status属性（フロア内）で保留中の要求ステータス値を使用する必要があります。-Request-Informationグループ化されたグループ化されたグループ化された最初のFloorRequestStatusメッセージ。
| The policy that a floor control server follows to grant or deny
| floors is outside the scope of this document. A given floor
| control server may perform these decisions automatically while
| another may contact a human acting as a chair every time a
| decision needs to be made.
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequest into the FloorRequestStatus, as described in Section 8.2. Additionally, the floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request.
セクション8.2で説明されているように、Floor ControlサーバーはFloorRequestからカンファレンスID、トランザクションID、およびユーザーIDをFloorRequestStatusにコピーする必要があります。さらに、Floor ControlサーバーはFloorRequestStatusにフロア要求情報グループ化された属性を追加する必要があります。このグループ化された属性に含まれる属性は、フロア要求に関する情報を運びます。
The floor control server MUST assign an identifier that is unique within the conference to this floor request, and MUST insert it in the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. This identifier will be used by the floor participant (or by a chair or chairs) to refer to this specific floor request in the future.
Floor Control Serverは、このフロア要求に会議内で一意である識別子を割り当てる必要があり、フロア要求情報属性のFloor Request IDフィールドに挿入する必要があります。この識別子は、将来的にこの特定の階の要求を参照するために、フロア参加者（または議長または椅子によって）によって使用されます。
The floor control server MUST copy the Floor IDs in the FLOOR-ID attributes of the FloorRequest into the FLOOR-REQUEST-STATUS attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These Floor IDs identify the floors being requested (i.e., the floors associated with this particular floor request).
Floor Controlサーバーは、FloorRequestのFloor-ID属性にフロアIDをFloor-Request-Information Grouped属性のFloor-Request-Status属性にコピーする必要があります。これらのフロアIDは、要求されているフロア（すなわち、この特定のフロア要求に関連するフロア）を識別する。
The floor control server SHOULD copy (if present) the contents of the BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.
Floor Controlサーバーは、FloorRequestからBeforicaliary-ID属性の内容をFloor-Request-Information-Informed属性内の受益者情報属性にコピーする必要があります。さらに、フロア制御サーバは、この受益者情報属性において受益者の表示名およびURIを提供することができる。
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
フロア制御サーバは、フロア要求情報グループ化された属性内の情報依存属性内のフロアの要求者に関する情報を提供することができる。
The floor control server MAY copy (if present) the PRIORITY attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute.
Floor Controlサーバーは、FloorRequestからFloor要求情報グループ化された属性に優先属性をコピー（存在する場合）をコピーすることができます。
| Note that this attribute carries the priority requested by the
| participant. The priority that the floor control server
| assigns to the floor request depends on the priority requested
| by the participant and the rights the participant has according
| to the policy of the conference. For example, a participant
| that is only allowed to use the Normal priority may request
| Highest priority for a floor request. In that case, the floor
| control server would ignore the priority requested by the
| participant.
The floor control server MAY copy (if present) the PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute.
Floor Controlサーバーは、FloorRequestからの参加提供情報属性をFloor-Request-Informatedグループ化された属性にコピーすることができます。
A floor request is considered to be ongoing as long as it is not in the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST-STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message generated by the floor control server did not indicate any of these states, the floor control server will need to send subsequent FloorRequestStatus messages.
床の要求は、キャンセルされ、リリースされた、または失効された状態にない限り、継続的であると考えられています。Floor Control Serverによって生成された最初のFloarRequestStatusメッセージのalublation-request-status属性（フロア要求情報グループ化された属性内）がこれらの状態のいずれも示さなかった場合、Floor Controlサーバーは後続のFloarquestStatusメッセージを送信する必要があります。
When the status of the floor request changes, the floor control server SHOULD send new FloorRequestStatus messages with the appropriate Request Status. The floor control server MUST add a FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to the one sent in the first FloorRequestStatus message to any new FloorRequestStatus related to the same floor request. (The Floor Request ID identifies the floor request to which the FloorRequestStatus applies.)
フロア要求のステータスが変更された場合、Floor Controlサーバーは適切な要求ステータスを持つ新しいFloheRequestStatusメッセージを送信する必要があります。Floor Controlサーバーは、最初のFloorRequestStatusメッセージで送信されたものと等しいフロア要求ID属性を、同じフロア要求に関連する新しいFloheRequestStatusに、フロアリクエストID属性を追加する必要があります。（Floor Request IDはFloorRequestStatusが適用されるフロア要求を識別します。）
When using BFCP over a reliable transport, the floor control server MUST set the Transaction ID of subsequent FloorRequestStatus messages to zero. When using BFCP over an unreliable transport, the Transaction ID MUST be non-zero and unique in the context of outstanding transactions over an unreliable transport as described in Section 8.
信頼できるトランスポートでBFCPを使用する場合、Floor Controlサーバーは後続のFloorQuestStatusメッセージのトランザクションIDをゼロに設定する必要があります。信頼性の低いトランスポートでBFCPを使用する場合、トランザクションIDは、セクション8で説明されているように、信頼性の低いトランスポートにわたる優れたトランザクションのコンテキストでは、トランザクションIDを非ゼロで固有のものでなければなりません。
| The rate at which the floor control server sends
| FloorRequestStatus messages is a matter of local policy. A
| floor control server may choose to send a new
| FloorRequestStatus message every time the floor request moves
| in the floor request queue, while another may choose only to
| send a new FloorRequestStatus message when the floor request is
| Granted or Denied.
The floor control server may add a STATUS-INFO attribute to any of the FloorRequestStatus messages it generates to provide extra information about its decisions regarding the floor request (e.g., why it was denied).
Floor Control Serverは、それが生成するFloorRequestStatusメッセージのいずれかにstatus-info属性を追加することができます（例：それが拒否された理由）。
| Floor participants and floor chairs may request to be informed
| about the status of a floor following the procedures in
| Section 12.1. If the processing of a floor request changes the
| status of a floor (e.g., the floor request is granted and
| consequently the floor has a new holder), the floor control
| server needs to follow the procedures in Section 13.5 to inform
| the clients that have requested that information.
The COMMON-HEADER and the rest of the attributes are the same as in the first FloorRequestStatus message.
共通ヘッダーと残りの属性は、最初のFloarRequestStatusメッセージと同じです。
The floor control server can discard the state information about a particular floor request when this reaches a status of Cancelled, Released, or Revoked.
Floor Controlサーバーは、これがキャンセルされ、リリースされた、または取り消された状態のステータスに達すると、特定のフロア要求に関する状態情報を破棄することができます。
When communicating over an unreliable transport and a FloorRequestStatusAck message is not received within the transaction failure window, the floor control server MUST retransmit the FloorRequestStatus message according to Section 6.2.
信頼性の低いトランスポートとFloorRequestStatusAckメッセージを通信している場合、トランザクションの障害ウィンドウ内では、Floor Controlサーバーはセクション6.2に従ってFloorRequestStatusメッセージを再送信する必要があります。
On reception of a FloorRequestQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequestQuery message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8.
FloorRequestQueryメッセージを受信すると、Floor Controlサーバーはクライアント認証と承認に関連するセクション9の規則に従います。FloorRequestQueryメッセージを処理している場合、Floor Controlサーバーはエラーに遭遇しますが、セクション13.8に記載されている手順に従ってエラー応答を生成する必要があります。
The successful processing of a FloorRequestQuery message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible.
Floor Control ServerによるFloarRequestQueryメッセージの成功処理はFloorRequestStatusメッセージを生成することを含みます。これはできるだけ早く生成されるべきです。
When communicating over an unreliable transport and upon receiving a FloorRequestQuery from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction.
信頼できない輸送を通信し、参加者からFloarRequestQueryを受信すると、Floor Controlサーバーはトランザクションの失敗ウィンドウ内でFloorRequestStatusメッセージで応答する必要があります。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequestQuery message into the FloorRequestStatus message, as described in Section 8.2. Additionally, the floor control server MUST include information about the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus.
フロアコントロールサーバーは、セクション8.2で説明されているように、FloorRequestQueryメッセージからConference ID、トランザクションID、およびユーザーIDをFloorRequestStatusメッセージにコピーする必要があります。さらに、Floor Controlサーバーには、Floor-Request-Informationグループ化された属性のFloorRequestStatusへのフロア要求に関する情報を含める必要があります。
The floor control server MUST copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
Floor Controlサーバーは、FloorRequestQueryメッセージからfloor-request-id属性の内容をFloor-Request-Information属性のFloor Request IDフィールドにコピーする必要があります。
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).
Floor Controlサーバーは、要求されているフロアを識別するフロア要求情報グループ化された属性にフロア要求 - ステータス属性を追加する必要があります（すなわち、floor-request-id属性によって識別されるフロア要求に関連するフロア）。
The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.
Floor Controlサーバーは、フロア要求の受益者を識別するフロア要求情報グループ化された属性に受益者ID属性を追加する必要があります。さらに、フロア制御サーバは、この受益者情報属性において受益者の表示名およびURIを提供することができる。
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
フロア制御サーバは、フロア要求情報グループ化された属性内の情報依存属性内のフロアの要求者に関する情報を提供することができる。
The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
フロアコントロールサーバーは、床参加者が参加者に提供された情報の床を要求した理由を提供することがあります。
The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request and a STATUS-INFO attribute with extra information about the floor request.
フロアコントロールサーバーは、フロアリクエストおよびフロアリクエストに関する追加情報を持つステータス情報属性を持つ優先順位の値を持つ優先順位属性を、フロアリクエスト情報グループ化された属性に追加することもできます。
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.
Floor Control Serverは、現在のrequest-status属性を、現在のステータスの現在のステータスをフロア要求の情報属性に追加する必要があります。フロア制御サーバは、フロア要求 - ステータス属性で要求されている各フロアに関するものとして、フロア要求のステータスに関する情報を提供することができる。
On reception of a UserQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the UserQuery message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8.
UserQueryメッセージを受信すると、Floor Control Serverはクライアント認証と承認に関連するセクション9の規則に従います。UserQueryメッセージを処理するときに、Floor Controlサーバーはエラーに遭遇し、セクション13.8で説明されている手順に従ってエラー応答を生成する必要があります。
The successful processing of a UserQuery message by a floor control server involves generating a UserStatus message, which SHOULD be generated as soon as possible.
Floor Control Serverによるユーザークエリメッセージの処理が成功すると、UserStatusメッセージを生成することができます。これはできるだけ早く生成されるべきです。
When communicating over an unreliable transport and upon receiving a UserQuery from a participant, the floor control server MUST respond with a UserStatus message within the transaction failure window to complete the transaction.
信頼性の低いトランスポートを介して通信するとき、参加者からのユーザークエリを受信すると、フロアコントロールサーバーはトランザクションの障害ウィンドウ内のUserStatusメッセージで応答してトランザクションを完了する必要があります。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the UserQuery message into the UserStatus message, as described in Section 8.2.
Floor Controlサーバーは、セクション8.2で説明されているように、Conference ID、トランザクションID、およびユーザーIDをUserSqueryメッセージにコピーする必要があります。
The sender of the UserQuery message is requesting information about all the floor requests associated with a given participant (i.e., the floor requests where the participant is either the beneficiary or the requester). This participant is identified by a BENEFICIARY-ID attribute or, in the absence of a BENEFICIARY-ID attribute, by a the User ID in the COMMON-HEADER of the UserQuery message.
ユーザークエリメッセージの送信者は、特定の参加者に関連するすべてのフロア要求に関する情報を要求しています（すなわち、参加者が受益者または要求者のいずれかである場合）。この参加者は、userQueryメッセージの共通ヘッダ内のユーザIDによって、受益者ID属性によって、または受益者ID属性がない場合に識別される。
The floor control server MUST copy, if present, the contents of the BENEFICIARY-ID attribute from the UserQuery message into a BENEFICIARY-INFORMATION attribute in the UserStatus message. Additionally, the floor control server MAY provide the display name and the URI of the participant about which the UserStatus message provides information in this BENEFICIARY-INFORMATION attribute.
Floor Controlサーバーが、存在する場合は、UserQueryメッセージからの受益者ID属性の内容をUserStatusメッセージの受益者情報属性にコピーする必要があります。さらに、フロア制御サーバは、この受益者情報属性に情報を提供する概要者の表示名および参加者のURIを提供することができる。
The floor control server SHOULD add to the UserStatus message a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request related to the participant about which the message provides information (i.e., the floor requests where the participant is either the beneficiary or the requester). For each FLOOR-REQUEST-INFORMATION attribute, the floor control server follows the following steps.
Floor Controlサーバーは、メッセージが情報を提供する参加者に関連する各フロア要求に対して、UserStatusメッセージに追加する必要があります（すなわち、参加者が受益者または要求者のいずれかの場合は階段要求）。各フロア要求情報属性について、フロアコントロールサーバーは以下のステップに従います。
The floor control server MUST identify the floor request the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
Floor Controlサーバーはフロア要求を識別する必要があります.hare-request-information属性のFloor-Request-Information属性のFloor Request IDフィールドに適用されます。
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).
Floor Controlサーバーは、要求されているフロアを識別するフロア要求情報グループ化された属性にフロア要求 - ステータス属性を追加する必要があります（すなわち、floor-request-id属性によって識別されるフロア要求に関連するフロア）。
The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.
Floor Controlサーバーは、フロア要求の受益者を識別するフロア要求情報グループ化された属性に受益者ID属性を追加する必要があります。さらに、フロア制御サーバは、この受益者情報属性において受益者の表示名およびURIを提供することができる。
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
フロア制御サーバは、フロア要求情報グループ化された属性内の情報依存属性内のフロアの要求者に関する情報を提供することができる。
The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
フロアコントロールサーバーは、床参加者が参加者に提供された情報の床を要求した理由を提供することがあります。
The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request.
フロア制御サーバは、フロア要求に対して要求された優先順位値を有する優先属性を有するフロア要求 - 情報グループ化された属性を追加することもできる。
The floor control server MUST include the current status of the floor request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request.
Floor Control Serverは、request-status属性のフロア要求の現在のステータスをフロア要求 - 情報グループ化された属性に含める必要があります。Floor Controlサーバーは、フロア要求に関する追加情報を持つstatus-info属性を追加することができます。
The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.
フロア制御サーバは、フロア要求 - ステータス属性で要求されている各フロアに関するものとして、フロア要求のステータスに関する情報を提供することができる。
On reception of a FloorRelease message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRelease message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8.
フローレアードメッセージを受信すると、Floor Controlサーバーはクライアント認証と許可に関連するセクション9の規則に従います。フローレアーズメッセージを処理するときに、フロア制御サーバはエラーに遭遇し、セクション13.8で説明されている手順に従ってエラー応答を生成する必要があります。
The successful processing of a FloorRelease message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible.
Floor Control Serverによるフローレアーゼメッセージの処理が成功すると、FloorRequestStatusメッセージを生成することが含まれます。これはできるだけ早く生成されるべきです。
When communicating over an unreliable transport and upon receiving a FloorRelease from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction.
信頼性の低い輸送を通信し、参加者からのフローレアーゼを受信すると、フロアコントロールサーバーはトランザクションの失敗ウィンドウ内のFloorRequestStatusメッセージで応答する必要があります。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRelease message into the FloorRequestStatus message, as described in Section 8.2.
Floor Controlサーバーは、セクション8.2で説明されているように、FlooReleaseメッセージから会議ID、トランザクションID、およびユーザーIDをFloorRequestStatusメッセージにコピーする必要があります。
The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request.
Floor Controlサーバーは、FloorRequestStatusにフロア要求情報グループ化された属性を追加する必要があります。このグループ化された属性に含まれる属性は、フロア要求に関する情報を運びます。
The FloorRelease message identifies the floor request it applies to using a FLOOR-REQUEST-ID. The floor control server MUST copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRelease message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
FlooreleAseメッセージは、フロア要求IDを使用するために適用されるフロア要求を識別します。Floor Controlサーバーは、FlooReleaseメッセージからfloor-request-id属性の内容をFloor-Request-Information属性のFloor Request IDフィールドにコピーする必要があります。
The floor control server MUST identify the floors being released (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute.
フロア制御サーバは、フロア要求 - 情報グループ化された属性に、フロア要求 - ステータス属性で、リリースされているフロアを識別しなければならない（すなわち、フロア要求ID属性によって識別されるフロア要求に関連するフロア）。
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status value SHOULD be Released, if the floor (or floors) had been previously granted, or Cancelled, if the floor (or floors) had not been previously granted. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request.
Floor Controlサーバーは、request-status属性をfloar-request-information-informed属性に追加する必要があります。床（または床）が以前に付与されていない場合は、床（または床）が以前に付与された場合、またはキャンセルされた場合、要求ステータス値をリリースする必要があります。Floor Controlサーバーは、フロア要求に関する追加情報を持つstatus-info属性を追加することができます。
On reception of a FloorQuery message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the FloorQuery message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8.
FloreQueryメッセージを受信すると、Floor Controlサーバーはクライアント認証に関連するセクション9の規則に従います。FloreQueryメッセージを処理している間に、Floor Controlサーバーはエラーに遭遇しますが、セクション13.8で説明されている手順に従ってエラー応答を生成する必要があります。
When communicating over an unreliable transport and upon receiving a FloorQuery from a participant, the floor control server MUST respond with a FloorStatus message within the transaction failure window to complete the transaction.
信頼性の低い輸送を介して通信するとき、参加者からのフロアクエリを受信すると、フロアコントロールサーバーはトランザクションの失敗ウィンドウ内でFloorStatusメッセージで応答しなければなりません。
A floor control server receiving a FloorQuery message from a client SHOULD keep this client informed about the status of the floors identified by FLOOR-ID attributes in the FloorQuery message. Floor control servers keep clients informed by using FloorStatus messages.
クライアントからFloorQueryメッセージを受信したフロアコントロールサーバーは、このクライアントがFloreQueryメッセージのFloor-ID属性によって識別されるフロアのステータスについて通知されるべきです。フロア制御サーバーは、FloorStatusメッセージを使用してクライアントを通知し続けます。
An individual FloorStatus message carries information about a single floor. So, when a FloorQuery message requests information about more than one floor, the floor control server needs to send separate FloorStatus messages for different floors.
個々のFloorStatusメッセージは単一の階に関する情報を運びます。そのため、ForeQueryメッセージが複数のフロアに関する情報を要求すると、フロアコントロールサーバーは別のフロアに対して別々のFloorStatusメッセージを送信する必要があります。
The information FloorQuery messages carry may depend on the user requesting the information. For example, a chair may be able to receive information about pending requests, while a regular user may not be authorized to do so.
情報のフロアクエリメッセージキャリーは、情報を要求するユーザーに依存します。例えば、議長は保留中の要求に関する情報を受信することができ、通常のユーザはそうする権限がないかもしれない。
The successful processing of a FloorQuery message by a floor control server involves generating one or several FloorStatus messages, the first of which SHOULD be generated as soon as possible.
フロア制御サーバによるフロアクエリメッセージの処理が成功すると、1つまたは複数のフロアステータスメッセージを生成することが含まれ、その最初のLoareStatusメッセージはできるだけ早く生成されるべきである。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorQuery message into the FloorStatus message, as described in Section 8.2.
Floor Controlサーバーは、セクション8.2で説明されているように、ORROREQUERYメッセージからLOORQUERYメッセージに会議ID、トランザクションID、およびユーザーIDをコピーする必要があります。
If the FloorQuery message did not contain any FLOOR-ID attribute, the floor control server sends the FloorStatus message without adding any additional attribute and does not send any subsequent FloorStatus message to the floor participant.
FloreQueryメッセージにfloor-id属性が含まれていない場合、Floor Control Serverは追加の属性を追加せずにFloorStatusメッセージを送信し、その後のFloorStatusメッセージをフロア参加者に送信しません。
If the FloorQuery message contained one or more FLOOR-ID attributes, the floor control server chooses one from among them and adds this FLOOR-ID attribute to the FloorStatus message. The floor control server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request associated to the floor. Each FLOOR-REQUEST-INFORMATION grouped attribute contains a number of attributes that provide information about the floor request. For each FLOOR-REQUEST-INFORMATION attribute, the floor control server follows the following steps.
FloreQueryメッセージが1つ以上のFloor-ID属性を含んでいた場合、Floor Controlサーバーはそれらの中から1つを選択し、このFOORS-ID属性をFloorStatusメッセージに追加します。Floor Controlサーバーは、フロアに関連付けられている各フロア要求に対して、フロア要求情報グループ化された属性を追加する必要があります。各フロア要求情報グループ化された属性には、フロア要求に関する情報を提供する多数の属性が含まれています。各フロア要求情報属性について、フロアコントロールサーバーは以下のステップに従います。
The floor control server MUST identify the floor request the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
Floor Controlサーバーはフロア要求を識別する必要があります.hare-request-information属性のFloor-Request-Information属性のFloor Request IDフィールドに適用されます。
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).
Floor Controlサーバーは、要求されているフロアを識別するフロア要求情報グループ化された属性にフロア要求 - ステータス属性を追加する必要があります（すなわち、floor-request-id属性によって識別されるフロア要求に関連するフロア）。
The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.
Floor Controlサーバーは、フロア要求の受益者を識別するフロア要求情報グループ化された属性に受益者ID属性を追加する必要があります。さらに、フロア制御サーバは、この受益者情報属性において受益者の表示名およびURIを提供することができる。
The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.
フロア制御サーバは、フロア要求情報グループ化された属性内の情報依存属性内のフロアの要求者に関する情報を提供することができる。
The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
フロアコントロールサーバーは、床参加者が参加者に提供された情報の床を要求した理由を提供することがあります。
The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request.
フロア制御サーバは、フロア要求に対して要求された優先順位値を有する優先属性を有するフロア要求 - 情報グループ化された属性を追加することもできる。
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request.
Floor Control Serverは、現在のrequest-status属性を、現在のステータスの現在のステータスをフロア要求の情報属性に追加する必要があります。Floor Controlサーバーは、フロア要求に関する追加情報を持つstatus-info属性を追加することができます。
The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.
フロア制御サーバは、フロア要求 - ステータス属性で要求されている各フロアに関するものとして、フロア要求のステータスに関する情報を提供することができる。
If the FloorQuery message carried more than one FLOOR-ID attribute, the floor control server SHOULD generate a FloorStatus message for each of them (except for the FLOOR-ID attribute chosen for the first FloorStatus message) as soon as possible. These FloorStatus messages are generated following the same rules as those for the first FloorStatus message (see Section 13.5.1), but their Transaction ID is 0 when using a reliable transport and non-zero and unique in the context of outstanding transactions when using an unreliable transport (cf. Section 8).
FloreQueryメッセージが複数のFLOOR-ID属性を持っていた場合、Floor Controlサーバーは、できるだけ早く、それらのそれぞれに対してLOORSTATUSメッセージを生成する必要があります（最初のORERSTATUSメッセージの場合はLOONES-ID属性を除く）。これらのFloorStatusメッセージは、最初のFloorStatusメッセージと同じ規則に従って生成されます（セクション13.5.1を参照）、信頼できるトランスポートと非ゼロを使用する場合は0は0です。信頼性の低い輸送（セクション8）。
After generating these messages, the floor control server sends FloorStatus messages, periodically keeping the client informed about all the floors for which the client requested information. The Transaction ID of these messages MUST be 0 when using a reliable transport and non-zero and unique in the context of outstanding transactions when using an unreliable transport (cf. Section 8).
これらのメッセージを生成した後、Floor Controlサーバーは、クライアントが情報が要求されたすべてのフロアについてクライアントを通知したままにして、FloorStatusメッセージを送信します。信頼性の低いトランスポートを使用する場合は、信頼性の高いトランスポートと非ゼロを使用していて、未処理のトランザクションのコンテキストで固有のものを使用する場合は、これらのメッセージのトランザクションIDが0でなければなりません（セクション8）。
| The rate at which the floor control server sends FloorStatus
| messages is a matter of local policy. A floor control server
| may choose to send a new FloorStatus message every time a new
| floor request arrives, while another may choose to only send a
| new FloorStatus message when a new floor request is Granted.
When communicating over an unreliable transport and a FloorStatusAck message is not received within the transaction failure window, the floor control server MUST retransmit the FloorStatus message according to Section 6.2.
信頼性の低いトランスポートとFloorStatusAckメッセージを通信する場合、トランザクションの障害ウィンドウ内でFloor Controlサーバーはセクション6.2に従ってFloorStatusメッセージを再送信する必要があります。
On reception of a ChairAction message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the ChairAction message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8.
議長メッセージを受信すると、Floor Controlサーバーはクライアント認証と承認に関連するセクション9の規則に従います。委員会メッセージを処理するときに、Floor Controlサーバはエラーに遭遇し、セクション13.8で説明されている手順に従ってエラー応答を生成する必要があります。
The successful processing of a ChairAction message by a floor control server involves generating a ChairActionAck message, which SHOULD be generated as soon as possible.
フロア制御サーバによる議長メッセージの処理が成功すると、議長のメッセージを生成することが含まれ、それはできるだけ早く生成されるべきである。
When communicating over an unreliable transport and upon receiving a ChairAction from a chair, the floor control server MUST respond with a ChairActionAck message within the transaction failure window to complete the transaction.
信頼性の低い輸送を通信するとき、そして議長から議長を受け取ると、フロアコントロールサーバーはトランザクションの障害ウィンドウ内で議長のメッセージで応答してトランザクションを完了する必要があります。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the ChairAction message into the ChairActionAck message, as described in Section 8.2.
フロア制御サーバは、セクション8.2で説明されているように、会議委員会、トランザクションID、およびユーザーIDを議長メッセージからコピーする必要があります。
The floor control server needs to take into consideration the operation requested in the ChairAction message (e.g., granting a floor) but does not necessarily need to perform it as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server.
フロア制御サーバは、議長メッセージで要求された操作を考慮する必要があります（たとえば、床を付与する）が、必ずしもフロアチェアによって要求されているとは限らない。フロアコントロールサーバーが実行する操作は、委員長メッセージとフロア制御サーバーの内部状態によって異なります。
For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well.
例えば、フロアチェアは、いくつかの階を含む原子床依頼運転の一部として要求された床を付与する議長メッセージを送ることができる。いずれかのフロアを担当する議長がフロアコントロールサーバーに床を付与するように指示したとしても、フロアコントロールサーバーは他の階に責任がある議長がそれらを許可することに同意するまでそれを許可しません。
So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state.
したがって、フロアコントロールサーバーは、この状態への入力として、フロアチェアからの命令を使用してコヒーレントなフロア状態を保つために最終的に責任があります。
If the new Status in the ChairAction message is Accepted and all the bits of the Queue Position field are zero, the floor chair is requesting that the floor control server assign a queue position (e.g., the last in the queue) to the floor request based on the local policy of the floor control server. (Of course, such a request only applies if the floor control server implements a queue.)
議長メッセージ内の新たなステータスが受け入れられ、キュー位置フィールドのすべてのビットがゼロの場合、フロアチェアはフロアコントロールサーバーがフロアリクエストに基づいてキュー位置（例えば、キューの最後の）を割り当てるように要求しています。フロア制御サーバのローカルポリシー。（もちろん、フロアコントロールサーバーがキューを実装している場合にのみ適用されるような要求は適用されます。）
On reception of a Hello message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the Hello message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8.
Helloメッセージを受信すると、Floor Controlサーバーはクライアント認証に関連するセクション9の規則に従います。Helloメッセージを処理するときに、Floor Controlサーバはエラーに遭遇し、セクション13.8で説明されている手順に従ってエラー応答を生成する必要があります。
If the version of BFCP specified in the version field of the COMMON-HEADER is supported by the floor control server, it MUST respond with the same version number in the HelloAck; this defines the version for all subsequent BFCP messages within this BFCP Connection.
Common-Headerのバージョンフィールドに指定されたBFCPのバージョンがFloor Control Serverでサポートされている場合は、Helloackで同じバージョン番号で応答する必要があります。これは、このBFCP接続内のすべての後続のBFCPメッセージのバージョンを定義します。
When communicating over an unreliable transport and upon receiving a Hello from a participant, the floor control server MUST respond with a HelloAck message within the transaction failure window to complete the transaction.
信頼性の低い輸送を通信し、参加者からのこんにちを受け取ったときに、フロアコントロールサーバーはトランザクションの失敗ウィンドウ内でHelloackメッセージで応答する必要があります。
The successful processing of a Hello message by a floor control server involves generating a HelloAck message, which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the Hello into the HelloAck, as described in Section 8.2.
フロアコントロールサーバーによるHelloメッセージの処理が成功すると、helloackメッセージを生成することができます。これはできるだけ早く生成されるべきです。セクション8.2で説明されているように、フロアコントロールサーバーは、会議ID、トランザクションID、およびHelloackからHelloackへのユーザーIDをコピーする必要があります。
The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to the HelloAck message listing all the primitives (i.e., BFCP messages) supported by the floor control server.
Floor Controlサーバーは、Floor Control Serverでサポートされているすべてのプリミティブ（すなわち、BFCPメッセージ）をリストしたHelloackメッセージにサポートされているプリミティブ属性を追加する必要があります。
The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to the HelloAck message listing all the attributes supported by the floor control server.
Floor Controlサーバーは、Floor Control Serverでサポートされているすべての属性をリストしたHelloackメッセージにサポートされている属性属性を追加する必要があります。
Error messages are always sent in response to a previous message from the client as part of a client-initiated transaction. The ABNF in Section 5.3.13 describes the attributes that an Error message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory and which ones are optional.
エラーメッセージは、クライアントが開始されたトランザクションの一部としてクライアントからの前のメッセージに応答して常に送信されます。5.3.13項のABNFは、エラーメッセージに含めることができる属性を説明しています。さらに、ABNFは、これらの属性のどれが必須であり、どちらがオプションであるのかを規則的に指定します。
The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the message from the client into the Error message, as described in Section 8.2.
フロア制御サーバは、セクション8.2で説明されているように、クライアントからのメッセージから会議ID、トランザクションID、およびユーザーIDをコピーする必要があります。
The floor control server MUST add an ERROR-CODE attribute to the Error message. The ERROR-CODE attribute contains an error code from Table 5. Additionally, the floor control server may add an ERROR-INFO attribute with extra information about the error.
Floor Controlサーバーは、エラーメッセージにエラーコード属性を追加する必要があります。エラーコード属性には、表5からのエラーコードが含まれています。追加的に、Floor Controlサーバーはエラーに関する追加情報を含むerror-info属性を追加することができます。
BFCP uses TLS/DTLS to provide mutual authentication between clients and servers. TLS/DTLS also provides replay and integrity protection and confidentiality. It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9, it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms to interwork with legacy implementation that do not use TLS/DTLS as long as these mechanisms provide similar security properties. An example of other mechanisms to effectively secure a nonsecure BFCP connection is IPsec [21].
BFCPはTLS / DTLを使用して、クライアントとサーバー間で相互認証を提供します。TLS / DTLSはまた、再生と完全性の保護と機密性を提供します。セクション7に従って暗号化アルゴリズムを備えたTLS / DTLSを常に使用することをお勧めします。セクション9で説明されているように、シグナリング/制御トラフィックが正しく保護されている場合には、必須の暗号化アルゴリズムを使用する必要があります。BFCPエンティティは、これらのメカニズムが同様のセキュリティプロパティを提供する限り、TLS / DTLSを使用しないレガシー実装との相互作用を使用して、他のセキュリティメカニズムを使用することができます。非コンセシュールBFCP接続を効果的に保護するための他のメカニズムの例はIPsec [21]です。
The remainder of this section analyzes some of the threats against BFCP and how they are addressed.
このセクションの残りの部分は、BFCPに対するいくつかの脅威とそれらがどのように対処されるかを分析します。
An attacker may attempt to impersonate a client (a floor participant or a floor chair) in order to generate forged floor requests or to grant or deny existing floor requests. Client impersonation is avoided by having servers only accept BFCP messages over authenticated TLS/DTLS connections. The floor control server assumes that attackers cannot hijack the TLS/DTLS connection and, therefore, that messages over the TLS/DTLS connection come from the client that was initially authenticated.
攻撃者は、鍛造された床の要求を生み出すか、既存の床の要求を与えたり拒否するために、クライアント（階の参加者や階の椅子）を偽装しようとする可能性があります。クライアントの偽装は、サーバーが認証されたTLS / DTLS接続を介してBFCPメッセージのみを受け入れることによって回避されます。Floor Controlサーバーは、攻撃者がTLS / DTLS接続をハイジャックできないこと、したがって、TLS / DTLS接続を介したメッセージが最初に認証されたクライアントから来ることを前提としています。
An attacker may attempt to impersonate a floor control server. A successful attacker would be able to make clients think that they hold a particular floor so that they would try to access a resource (e.g., sending media) without having legitimate rights to access it. Floor control server impersonation is avoided by having servers only accept BFCP messages over authenticated TLS/DTLS connections, as well as ensuring clients only send and accept messages over authenticated TLS/DTLS connections.
攻撃者はフロアコントロールサーバーを偽装しようとする可能性があります。成功した攻撃者は、彼らがそれにアクセスするための正当な権利を持たずにリソースにアクセスしようとするように、彼らが特定の階を保持するようにクライアントを考えることができるでしょう。Floor Controlサーバーの偽装は、サーバーが認証されたTLS / DTLS接続を介してBFCPメッセージのみを受け入れることによって、および認証されたTLS / DTLS接続でのメッセージのみを確実に送信および受け入れることだけを確実にすることによって回避されます。
Attackers may attempt to modify messages exchanged by a client and a floor control server. The integrity protection provided by TLS/DTLS connections prevents this attack.
攻撃者は、クライアントとフロアコントロールサーバーによって交換されたメッセージを変更しようとします。TLS / DTLS接続によって提供される完全性保護はこの攻撃を防ぎます。
An attacker may attempt to fetch a valid message sent by a client to a floor control server and replay it over a connection between the attacker and the floor control server. This attack is prevented by having floor control servers check that messages arriving over a given authenticated TLS/DTLS connection use an authorized user ID (i.e., a user ID that the user that established the authenticated TLS/DTLS connection is allowed to use).
攻撃者は、クライアントによって送信された有効なメッセージをFloor Controlサーバーにフェッチし、攻撃者とフロアコントロールサーバー間の接続を再生しようとします。この攻撃は、所与の認証されたTLS / DTLS接続を介して到着したメッセージが許可されたユーザIDを使用しているメッセージが許可されたユーザIDを使用することを確認することができない（すなわち、認証されたTLS / DTLS接続を確立するユーザが使用可能にするユーザID）。
Attackers may attempt to pick messages from the network to get access to confidential information between the floor control server and a client (e.g., why a floor request was denied). TLS/DTLS confidentiality prevents this attack. Therefore, it is REQUIRED that TLS/DTLS be used with an encryption algorithm according to Section 7.
攻撃者は、フロアコントロールサーバーとクライアントとの間の機密情報へのアクセスをネットワークから選択しようとする（例えば、階頭要求が拒否された理由）。TLS / DTLS機密性はこの攻撃を防ぎます。したがって、TLS / DTLはセクション7に従って暗号化アルゴリズムと共に使用されることが要求される。
The IANA has created a registry for BFCP parameters called "The Binary Floor Control Protocol (BFCP) Parameters". This registry has a number of subregistries, which are described in the following sections.
IANAは、「バイナリフロアコントロールプロトコル（BFCP）パラメータ」と呼ばれるBFCPパラメータのレジストリを作成しました。このレジストリには、次のセクションで説明されているいくつかのサブレジストがあります。
This section establishes the "Attributes" subregistry under the BFCP Parameters registry. As per the terminology in RFC 8126 [6], the registration policy for BFCP attributes is "Specification Required". For the purposes of this subregistry, the BFCP attributes for which IANA registration is requested MUST be defined by a Standards Track RFC. Such an RFC MUST specify the attribute's type, name, format, and semantics.
このセクションでは、BFCPパラメータレジストリの下で「属性」サブレイストを確立します。RFC 8126 [6]の用語に従って、BFCP属性の登録ポリシーは「指定必須」です。このサブレジストの目的のために、IANA登録が要求されているBFCP属性は、規格トラックRFCによって定義されなければなりません。そのようなRFCは、属性の種類、名前、形式、およびセマンティクスを指定する必要があります。
For each BFCP attribute, the IANA registers its type, its name, and the reference to the RFC where the attribute is defined. The following table contains the initial values of this subregistry.
BFCP属性ごとに、IANAはそのタイプ、その名前、および属性が定義されているRFCへの参照を登録します。次の表は、このサブレイストの初期値を示しています。
+======+===========================+===========+
| Type | Attribute | Reference |
+======+===========================+===========+
| 1 | BENEFICIARY-ID | RFC 8855 |
+------+---------------------------+-----------+
| 2 | FLOOR-ID | RFC 8855 |
+------+---------------------------+-----------+
| 3 | FLOOR-REQUEST-ID | RFC 8855 |
+------+---------------------------+-----------+
| 4 | PRIORITY | RFC 8855 |
+------+---------------------------+-----------+
| 5 | REQUEST-STATUS | RFC 8855 |
+------+---------------------------+-----------+
| 6 | ERROR-CODE | RFC 8855 |
+------+---------------------------+-----------+
| 7 | ERROR-INFO | RFC 8855 |
+------+---------------------------+-----------+
| 8 | PARTICIPANT-PROVIDED-INFO | RFC 8855 |
+------+---------------------------+-----------+
| 9 | STATUS-INFO | RFC 8855 |
+------+---------------------------+-----------+
| 10 | SUPPORTED-ATTRIBUTES | RFC 8855 |
+------+---------------------------+-----------+
| 11 | SUPPORTED-PRIMITIVES | RFC 8855 |
+------+---------------------------+-----------+
| 12 | USER-DISPLAY-NAME | RFC 8855 |
+------+---------------------------+-----------+
| 13 | USER-URI | RFC 8855 |
+------+---------------------------+-----------+
| 14 | BENEFICIARY-INFORMATION | RFC 8855 |
+------+---------------------------+-----------+
| 15 | FLOOR-REQUEST-INFORMATION | RFC 8855 |
+------+---------------------------+-----------+
| 16 | REQUESTED-BY-INFORMATION | RFC 8855 |
+------+---------------------------+-----------+
| 17 | FLOOR-REQUEST-STATUS | RFC 8855 |
+------+---------------------------+-----------+
| 18 | OVERALL-REQUEST-STATUS | RFC 8855 |
+------+---------------------------+-----------+
Table 7: Initial values of the BFCP Attributes subregistry
表7：BFCP属性サブレジストの初期値
This section establishes the "Primitives" subregistry under the BFCP Parameters registry. As per the terminology in RFC 8126 [6], the registration policy for BFCP primitives is "Specification Required". For the purposes of this subregistry, the BFCP primitives for which IANA registration is requested MUST be defined by a Standards Track RFC. Such an RFC MUST specify the primitive's value, name, format, and semantics.
このセクションでは、BFCPパラメータレジストリで「プリミティブ」サブレイストを確立します。RFC 8126 [6]の用語に従って、BFCPプリミティブの登録ポリシーは「仕様必須」です。このサブレイストの目的のために、IANA登録が要求されるBFCPプリミティブは、標準トラックRFCによって定義されなければなりません。そのようなRFCは、プリミティブの値、名前、形式、および意味論を指定する必要があります。
For each BFCP primitive, the IANA registers its value, its name, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry.
BFCPプリミティブごとに、IANAはその値、その名前、およびプリミティブが定義されているRFCへの参照を登録します。次の表は、このサブレイストの初期値を示しています。
+=======+=======================+===========+
| Value | Primitive | Reference |
+=======+=======================+===========+
| 1 | FloorRequest | RFC 8855 |
+-------+-----------------------+-----------+
| 2 | FloorRelease | RFC 8855 |
+-------+-----------------------+-----------+
| 3 | FloorRequestQuery | RFC 8855 |
+-------+-----------------------+-----------+
| 4 | FloorRequestStatus | RFC 8855 |
+-------+-----------------------+-----------+
| 5 | UserQuery | RFC 8855 |
+-------+-----------------------+-----------+
| 6 | UserStatus | RFC 8855 |
+-------+-----------------------+-----------+
| 7 | FloorQuery | RFC 8855 |
+-------+-----------------------+-----------+
| 8 | FloorStatus | RFC 8855 |
+-------+-----------------------+-----------+
| 9 | ChairAction | RFC 8855 |
+-------+-----------------------+-----------+
| 10 | ChairActionAck | RFC 8855 |
+-------+-----------------------+-----------+
| 11 | Hello | RFC 8855 |
+-------+-----------------------+-----------+
| 12 | HelloAck | RFC 8855 |
+-------+-----------------------+-----------+
| 13 | Error | RFC 8855 |
+-------+-----------------------+-----------+
| 14 | FloorRequestStatusAck | RFC 8855 |
+-------+-----------------------+-----------+
| 15 | FloorStatusAck | RFC 8855 |
+-------+-----------------------+-----------+
| 16 | Goodbye | RFC 8855 |
+-------+-----------------------+-----------+
| 17 | GoodbyeAck | RFC 8855 |
+-------+-----------------------+-----------+
Table 8: Initial values of the BFCP Primitives subregistry
表8：BFCPプリミティブサブレジストの初期値
This section establishes the "Request Statuses" subregistry under the BFCP Parameters registry. As per the terminology in RFC 8126 [6], the registration policy for BFCP request statuses is "Specification Required". For the purposes of this subregistry, the BFCP request statuses for which IANA registration is requested MUST be defined by a Standards Track RFC. Such an RFC MUST specify the value and the semantics of the request status.
このセクションでは、BFCPパラメータレジストリの下で「要求ステータス」サブレイストを確立します。RFC 8126 [6]の用語に従って、BFCP要求ステータスの登録ポリシーは「指定必須」です。このサブレイストの目的のために、IANA登録が要求されているBFCP要求ステータスは、規格トラックRFCによって定義されなければなりません。そのようなRFCは、要求ステータスの値と意味を指定しなければなりません。
For each BFCP request status, the IANA registers its value, its meaning, and the reference to the RFC where the request status is defined. The following table contains the initial values of this subregistry.
BFCP要求ステータスごとに、IANAはその値、その意味、および要求ステータスが定義されているRFCへの参照を登録します。次の表は、このサブレイストの初期値を示しています。
+=======+===========+===========+
| Value | Status | Reference |
+=======+===========+===========+
| 1 | Pending | RFC 8855 |
+-------+-----------+-----------+
| 2 | Accepted | RFC 8855 |
+-------+-----------+-----------+
| 3 | Granted | RFC 8855 |
+-------+-----------+-----------+
| 4 | Denied | RFC 8855 |
+-------+-----------+-----------+
| 5 | Cancelled | RFC 8855 |
+-------+-----------+-----------+
| 6 | Released | RFC 8855 |
+-------+-----------+-----------+
| 7 | Revoked | RFC 8855 |
+-------+-----------+-----------+
Table 9: Initial values of the Request Statuses subregistry
表9：要求ステータスの初期値サブリュージスト
This section establishes the "Error Codes" subregistry under the BFCP Parameters registry. As per the terminology in RFC 8126 [6], the registration policy for BFCP error codes is "Specification Required". For the purposes of this subregistry, the BFCP error codes for which IANA registration is requested MUST be defined by a Standards Track RFC. Such an RFC MUST specify the value and the semantics of the error code, and any Error Specific Details that apply to it.
このセクションでは、BFCPパラメータレジストリの下で「エラーコード」サブレイストを確立します。RFC 8126 [6]の用語に従って、BFCPエラーコードの登録ポリシーは「指定必須」です。このサブレイストの目的のために、IANA登録が要求されるBFCPエラーコードは、標準トラックRFCによって定義されなければならない。そのようなRFCは、エラーコードの値とセマンティクス、およびそれに適用されるエラー特定の詳細を指定する必要があります。
For each BFCP primitive, the IANA registers its value, its meaning, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry.
各BFCPプリミティブについて、IANAはその値、その意味、およびプリミティブが定義されているRFCへの参照を登録します。次の表は、このサブレイストの初期値を示しています。
+=======+=============================================+===========+
| Value | Meaning | Reference |
+=======+=============================================+===========+
| 1 | Conference Does Not Exist | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 2 | User Does Not Exist | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 3 | Unknown Primitive | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 4 | Unknown Mandatory Attribute | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 5 | Unauthorized Operation | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 6 | Invalid Floor ID | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 7 | Floor Request ID Does Not Exist | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 8 | You have Already Reached the Maximum Number | RFC 8855 |
| | of Ongoing Floor Requests for This Floor | |
+-------+---------------------------------------------+-----------+
| 9 | Use TLS | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 10 | Unable to Parse Message | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 11 | Use DTLS | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 12 | Unsupported Version | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 13 | Incorrect Message Length | RFC 8855 |
+-------+---------------------------------------------+-----------+
| 14 | Generic Error | RFC 8855 |
+-------+---------------------------------------------+-----------+
Table 10: Initial values of the Error Codes subregistry
表10：エラーコードサブリュージストリートの初期値
The following is the list of technical changes and other non-trivial fixes from [3].
以下は[3]からの技術的な変更やその他の自明の修正のリストです。
The main purpose of this work was to revise the specification to support BFCP over an unreliable transport, resulting in the following changes:
この作業の主な目的は、信頼性の低いトランスポートでBFCPをサポートするための仕様を修正し、次の変更を加えました。
1. Overview of Operation (Section 4):
1. 操作の概要（セクション4）：
Changed the description of client-initiated and server-initiated transactions, referring to Section 8.
セクション8を参照して、クライアントが開始されたトランザクションとサーバーが開始されたトランザクションの説明を変更しました。
2. COMMON-HEADER Format (Section 5.1):
2. 共通ヘッダー形式（セクション5.1）：
Ver(sion) field, where the value 2 is used for the extensions for an unreliable transport. Added new R and F flag bits for an unreliable transport. Res(erved) field is now 3 bit. New optional Fragment Offset and Fragment Length fields.
値2が信頼性の低いトランスポートの拡張に使用されるVer（Sion）フィールド。信頼性の低い輸送のために新しいRとFフラグビットを追加しました。Res（ERVED）フィールドは3ビットです。新しいオプションのフラグメントオフセットとフラグメント長フィールド
3. New primitives (Section 5.1):
3. 新しいプリミティブ（セクション5.1）：
Added four new primitives: FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.
4つの新しいプリミティブ、FloorRequestStatusAck、FloorStatusAkk、さようなら、そしてGoodbyeaCKを追加しました。
4. New error codes (Section 5.2.6):
4. 新しいエラーコード（セクション5.2.6）：
Added three new error codes: "Unable to Parse Message", "Use DTLS" and "Unsupported Version". Note that two additional error codes were added, see Section 16.2.
「メッセージ解析できません」、「DTLSを使用できません」、「サポートされていないバージョン」を追加しました。2つの追加のエラーコードが追加された場合は、セクション16.2を参照してください。
5. ABNF for new primitives (Section 5.3):
5. 新しいプリミティブのABNF（セクション5.3）：
Added new subsections with normative ABNF for the new primitives.
新しいプリミティブのために規範的なABNFを持つ新しいサブセクションを追加しました。
6. Transport split in two (Section 6):
6. 2つのトランスポート分割（セクション6）：
Section 6 specifying the transport was split in two subsections; Section 6.1 for a reliable transport and Section 6.2 for an unreliable transport. The specification for an unreliable transport, among other issues, deals with reliability, congestion control, fragmentation and ICMP.
輸送の特定のセクション6は、2つのサブセクションに分割されました。信頼性の低い輸送のための信頼できる輸送とセクション6.2のセクション6.1。信頼できない輸送の仕様は、他の問題の中でも、信頼性、輻輳制御、断片化、およびICMPを扱います。
7. Mandated DTLS (Section 7 and Section 9):
7. 必須のDTLS（セクション7とセクション9）：
Mandated DTLS support when transport over UDP is used.
UDP上でのトランスポートを使用すると、必須のDTLSサポートが使用されます。
8. Transaction changes (Section 8):
8. トランザクションの変更（セクション8）：
Server-initiated transactions over an unreliable transport have non-zero and unique Transaction IDs. Over an unreliable transport, the retransmit timers T1 and T2 described in Section 8.3 apply.
信頼性の低いトランスポートを介したサーバー開始トランザクションには、ゼロ以外のトランザクションIDがあります。信頼性の低い輸送では、8.3節で説明されている再送信タイマT1とT2が適用されます。
9. Timely response required (Section 8.3, Section 10.1.2, Section 10.2.2, Section 11.2, Section 12.1.2, Section 12.2.2, Section 12.3.2, Section 12.4.2, Section 10.1.3 and Section 12.1.3):
9. タイムリーな応答が必要です（第8.3項、第10.2.2項、第11.2項、第11.2.2項、第12.2.2項、第12.2.2項、第12.4.2項、第10.1.3項および第12.1.3項）：
Described that a given response must be sent within the transaction failure window to complete the transaction.
取引を完了するために、与えられた応答をトランザクション障害ウィンドウ内で送信する必要があることを説明しました。
10. Updated IANA Considerations (Section 15):
10. 更新されたIANAの考慮事項（セクション15）：
Added the new primitives and error codes to Section 15.2 and Section 15.4 respectively.
セクション15.2およびセクション15.4にそれぞれ新しいプリミティブとエラーコードを追加しました。
11. Examples over an unreliable transport (Appendix A):
11. 信頼できない輸送の例（付録A）：
Added sample interactions over an unreliable transport for the scenarios in Figure 2 and Figure 3
図2および図3のシナリオの信頼性の低いトランスポートにわたってサンプルインタラクションを追加しました
12. Motivation for an unreliable transport (Appendix B):
12. 信頼できない輸送のための動機（付録B）：
Added introduction to and motivation for extending BFCP to support an unreliable transport.
信頼性の低い輸送をサポートするためにBFCPを拡張するための紹介とモチベーションを追加しました。
Clarifications and bug fixes:
明確化とバグ修正：
1. ABNF fixes (Figure 22, Figure 24, Figure 26, Figure 28, Figure 30, and the ABNF figures in Section 5.3):
1. ABNFの修正（図24、図26、図26、図28、図28、図28、および5.3節のABNF数値）。
Although formally correct in [3], the notation has changed in a number of figures to an equivalent form for clarity, e.g., "s/*1(FLOOR-ID)/[FLOOR-ID]/" in Figure 38 and "s/*[XXX]/*(XXX)/" in the other figures.
[3]では正式に正式に修正されていますが、明確にするために、数値の数で変化しました。他の図の/ * [xxx] / *（xxx）/ "。
2. Typo (Section 12.4.2):
2. TYPO（12.4.2項）：
Changed from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the second paragraph.
サポートされているPrimitviesからサポートされているプリミティブに変更されました。
3. Corrected attribute type (Section 13.1.1):
3. 修正属性タイプ（第13.1.1項）：
Changed from PARTICIPANT-PROVIDED-INFO to PRIORITY attribute in the eighth paragraph, since the note below describes priority and that the last paragraph deals with PARTICIPANT-PROVIDED-INFO.
下記の注意事項には、参加者に提供されている情報が提供されているため、参加者に提供された情報から優先属性に変更されます。
4. New error codes (Section 5.2.6):
4. 新しいエラーコード（セクション5.2.6）：
Added two additional error codes: "Incorrect Message Length" and "Generic Error".
2つの追加のエラーコードを追加しました。 "誤ったメッセージ長"と "汎用エラー"。
5. New cipher suites (Section 7)
5. 新しい暗号スイート（セクション7）
Additional cipher suites are now specified which should be supported.
サポートされるべき追加の暗号スイートが指定されました。
6. Assorted clarifications (Across the document):
6. 明確化の盛り合わせ（文書全体）：
Language clarifications as a result of reviews. Also, the normative language was tightened where appropriate, i.e. changed from SHOULD strength to MUST in a number of places.
レビューの結果としての言語明確化また、適切な場合には、正式な言語は厳しく、すなわち強さがされなければならないと、さまざまな場所になければなりません。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[1] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/rfc2119>。
[2] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[2] Paxson、V.、Allman、M.、Chu、J.、およびM.Sargent、 "Computing TCPの再送信タイマー"、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<https：//www.rfc-editor.org/ info / rfc6298>。
[3] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, November 2006, <https://www.rfc-editor.org/info/rfc4582>.
[3] Camarillo、G.、OTT、J.、K.RFC 4582、DOI 10.17487 / RFC4582、2006年11月、<https://www.rfc-editor.org/情報/ RFC4582>。
[4] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, DOI 10.17487/RFC5018, September 2007, <https://www.rfc-editor.org/info/rfc5018>.
[4] Camarillo、G.、「バイナリフロア制御プロトコル（BFCP）」、RFC 5018、DOI 10.17487 / RFC5018、2007年9月、<https：//www.rfc-editor.org/info/rfc5018>。
[5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[5] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[6] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[6] 綿、M.、Leiba、B.およびT.Narten、「RFCのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：///www.rfc-editor.org/info/rfc8126>。
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[7] 2008年8月、<https://ww.rfc- editor.org/info/rfc5246、<https://ww.rfc-editor.org/info/rfc5246、<https://www.rfc- editor.org/info/rfc5246、<https://ww.rfc-editor.org/info/rfc5246>。
[8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[8] Rescorla、E.およびN. ModAdugu、「データグラムトランスポート層セキュリティバージョン1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https：//www.rfc-editor.org/info/rfc6347>。
[9] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[9] Yergeau、F.、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https：//www.rfc-editor.org/info/rfc3629>。
[10] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[10] Leiba、B.、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、<https：//www.rfc-editor.org/info/rfc8174>。
[11] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[11] Rescorla、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[12] Camarillo, G., Kristensen, T., and C. Holmberg, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 8856, DOI 10.17487/RFC8856, January 2021, <https://www.rfc-editor.org/info/rfc8856>.
[12] Camarillo、G.、Kristensen、T.、およびC.Holmberg、「セッション記述プロトコル（SDP）ストリーム（BFCP）ストリーム（BFCP）ストリーム、RFC 8856、DOI 10.17487 / RFC8856、<https：//www.rfc-editor.org/info/rfc8856>。
[13] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, <https://www.rfc-editor.org/info/rfc4961>.
[13] 2007年7月、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc4961,2007、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc4961>。
[14] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[14] Rosenberg、J.、Mahy、R.、Matthews、P.、およびD. Wing、「Sest Traversal Nat（Stun（Stun）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<https：//www.rfc-editor.org/info/rfc5389>。
[15] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[15] eggert、L.、FairHurst、G.、およびG.Shepherd、 "UDP使用ガイドライン"、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https：//www.rfc-editor.org/info/RFC8085>。
[16] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[16] ケラネン、A.、Holmberg、C.、J.Rosenberg、「インタラクティブ接続確立（氷）：ネットワークアドレス翻訳者（NAT）トラバースのためのプロトコル、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https：//www.rfc-editor.org/info/rfc8445>。
[17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[17] Rosenberg、J.およびH.Schulzrinne、「セッション記述プロトコル（SDP）」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https://www.rfc-editor.org/info/RFC3264>。
[18] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, DOI 10.17487/RFC4376, February 2006, <https://www.rfc-editor.org/info/rfc4376>.
[18] Koskelainen、P.、OTT、J.、Schulzrinne、H.、およびX. WU、「フロアコントロールプロトコルの要件」、RFC 4376、DOI 10.17487 / RFC4376、2006年2月、<https：//www.rfc-編集者。org / info / rfc4376>。
[19] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239, June 2008, <https://www.rfc-editor.org/info/rfc5239>.
[19] Barnes、M.、Boulton、C.、O. Levin、「集中会議のためのフレームワーク」、RFC 5239、DOI 10.17487 / RFC5239、2008年6月、<https：//www.rfc-editor.org/info/rfc5239>。
[20] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[20] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[21] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[21] ケント、S.およびK.SEO、「インターネットプロトコルのためのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https：//www.rfc-editor.org/info/rfc4301>。
[22] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501, March 2012, <https://www.rfc-editor.org/info/rfc6501>.
[22] Novo、O.、Camarillo、G.、Morgan、D.、およびJ.URPalainen、「集中会議（XCON）の会議情報データモデル（XCON）の会議情報データモデル、RFC 6501、DOI 10.17487 / RFC6501、2012年3月、<HTTPS：// WWW.rfc-editor.org / info / rfc6501>。
[23] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, DOI 10.17487/RFC6503, March 2012, <https://www.rfc-editor.org/info/rfc6503>.
[23] Barnes、M.、Boulton、C、Romano、S.、およびH.Schulzrinne、「集中会議操作プロトコル」、RFC 6503、DOI 10.17487 / RFC6503、2012年3月、<https：//www.rfc-editor.org/ info / rfc6503>。
[24] Barnes, M., Miniero, L., Presta, R., and S P. Romano, "Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples", RFC 6504, DOI 10.17487/RFC6504, March 2012, <https://www.rfc-editor.org/info/rfc6504>.
[24] Barnes、M.、Miniero、L.、Presta、R.、およびS P. Romano、「集中会議操作プロトコル（CCMP）コールフローの例」、RFC 6504、DOI 10.17487 / RFC6504、2012年3月、<https：//www.rfc-editor.org/info/rfc6504>。
[25] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[25] Mogul、J.およびS.Theering、 "Path Mtu Discovery"、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<https：//www.rfc-editor.org/info/rfc1191>。
[26] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[26] McCann、J.、S.、Mogul、J.、およびR. Hinden、Ed。、「IPバージョン6のパスMTUディスカバリー」、STD 87、RFC 8201、DOI 10.17487 / RFC8201、2017年7月、<HTTPS：//www.rfc-editor.org/info/rfc8201>。
[27] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[27] Mathis、M.およびJ.Heffner、 "Packetization Layer Path MTU Discovery"、RFC 4821、DOI 10.17487 / RFC4821、2007年3月、<https：//www.rfc-editor.org/info/rfc4821>。
[28] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, <https://www.rfc-editor.org/info/rfc5763>.
[28] Fischl、J.、Tschofenig、H。、およびE. Rescorla、「データグラムトランスポート層セキュリティ（DTLS）」、RFC 5763、DOI 10.17487 / RFC5763、DII 10.17487 / RFC5763を使用した「セキュリティコンテキストを確立するためのフレームワーク」、2010、<https://www.rfc-editor.org/info/rfc5763>。
[29] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <https://www.rfc-editor.org/info/rfc6951>.
[29] Tuexen、M.およびR.Stewart、「エンドホストへのストリーム制御伝送プロトコル（SCTP）パケットの「UDPカプセル化」、RFC 6951、DOI 10.17487 / RFC6951、2013年5月、<https：// www。rfc-editor.org/info/rfc6951>。
[30] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[30] Sheffer、Y。、Holz、R.、およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）およびデータグラムトランスポート層セキュリティ（DTLS）」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https：//www.rfc-editor.org/info/rfc7525>。
[31] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, <https://www.rfc-editor.org/info/rfc4380>.
[31] Huitema、C.、 "Teredo：ネットワークアドレス翻訳（NATS）"、RFC 4380、DOI 10.17487 / RFC4380、2006年2月、<https://www.rfc-editor.org/info/rfc4380>。
[32] Thaler, D., "Teredo Extensions", RFC 6081, DOI 10.17487/RFC6081, January 2011, <https://www.rfc-editor.org/info/rfc6081>.
[32] Thaler、D.、 "Teredo Extensions"、RFC 6081、DOI 10.17487 / RFC6081、2011年1月、<https：//www.rfc-editor.org/info/rfc6081>。
[33] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[33] Stewart、R.、Ed。、「ストリーム制御伝送プロトコル」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https：//www.rfc-editor.org/info/rfc4960>。
[34] Rosenberg, J., Keranen, A., Lowekamp, B. B., and A. B. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, <https://www.rfc-editor.org/info/rfc6544>.
[34] Rosenberg、J.、Keranen、A.、Lowekamp、BB、AB Roach、「インタラクティブ接続確立（ICE）」、RFC 6544、DOI 10.17487 / RFC6544、2012年3月、<https：///www.rfc-editor.org/info/rfc6544>。
[35] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling (GUT)", Work in Progress, Internet-Draft, draft-manner-tsvwg-gut-02, 12 July 2010, <https://tools.ietf.org/html/draft-manner-tsvwg-gut-02>.
[35] Many、J.、Varis、N.、およびB.Briscoe、 "Generic UDPトンネリング（GUT）"、進行中の作業、インターネットドラフト、ドラフトMAY-TSVWG-GUT-02,2010 7月12日、<https：//tools.ietf.org/html/draft-manner-tsvwg-gut-02>。
[36] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, Internet-Draft, draft-ietf-mmusic-media-path-middleboxes-07, 30 May 2013, <https://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-07>.
[36] Stucker、B.、Tschofenig、H.、G.Salgueiro、「メディアパスに沿ったシグナリングプロトコル通信のためのミドルボックスの相互作用の解析」、進行中の作業、インターネットドラフト、ドラフト-IETF-MMUSIC-MEDIEL-POTH-PATH-PATH-MIRDELBOX - 2013年5月30日、<https://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-07>。
[37] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", 2005, <https://www.usenix.org/legacy/event/imc05/tech/ full_papers/guha/guha.pdf>.
[37] GUHA、S、およびP.Francis、「NATSとファイアウォールを通したTCPトラバーサルの特性化と測定」、2005、<https：//www.usenix.org/legacy/event/imc05/tech/ full_papers / guha.pdf>。
[38] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer Communication Across Network Address Translators", April 2005, <https://www.usenix.org/legacy/events/usenix05/tech/ general/full_papers/ford/ford.pdf>.
[38] Ford、B.、Srisuresh、P.、D.Kegel、2005年4月、<https://www.usenix.org/legacy/events/usenix05/tech/一般/ full_papers / ford / ford.pdf>。
With reference to Section 4.1, the following figures show representative call flows for requesting and releasing a floor, and obtaining status information about a floor when BFCP is deployed over an unreliable transport. The figures here show a lossless interaction.
セクション4.1を参照して、以下の図は、フロアを要求および解放するための代表的なコールフローを示し、BFCPが信頼性の低いトランスポートで展開されている場合の階に関するステータス情報を取得する。ここでの図は無損失の相互作用を示しています。
Floor Participant Floor Control
Server
|(1) FloorRequest |
|Transaction Responder: 0 |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorRequestStatus |
|Transaction Responder: 1 |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Pending |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(3) FloorRequestStatus |
|Transaction Responder: 0 |
|Transaction ID: 124 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(4) FloorRequestStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 124 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(5) FloorRequestStatus |
|Transaction Responder: 0 |
|Transaction ID: 125 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(6) FloorRequestStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 125 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(7) FloorRelease |
|Transaction Responder: 0 |
|Transaction ID: 126 |
|User ID: 234 |
|FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->|
| |
|(8) FloorRequestStatus |
|Transaction Responder: 1 |
|Transaction ID: 126 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Released |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
Figure 48: Requesting and releasing a floor
図48：フロアの要求と解放
Note that in Figure 48, the FloorRequestStatus message from the floor control server to the floor participant is a transaction-closing message as a response to the client-initiated transaction with Transaction ID 126. As such, it is not followed by a FloorRequestStatusAck message from the floor participant to the floor control server.
図48では、フロアコントロールサーバーからフロア参加者へのFloorRequestStatusメッセージは、トランザクションID 126を持つクライアント開始トランザクションへの応答としてのトランザクション終了メッセージです。フロアコントロールサーバーに参加しています。
Floor Participant Floor Control
Server
|(1) FloorQuery |
|Transaction Responder: 0 |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorStatus |
|Transaction Responder: 1 |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 2nd |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(3) FloorStatus |
|Transaction Responder: 0 |
|Transaction ID: 258 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(4) FloorStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 258 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(5) FloorStatus |
|Transaction Responder: 0 |
|Transaction ID: 259 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(6) FloorStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 259 |
|User ID: 234 |
|---------------------------------------------->|
Figure 49: Obtaining status information about a floor
図49：フロアに関するステータス情報の入手
This appendix is provided as an aid to understand the background and rationale for adding support for unreliable transport.
この付録は、信頼性の低いトランスポートのサポートを追加するための背景と根拠を理解するための援助として提供されています。
In existing video conferencing deployments, BFCP is used to manage the floor for the content sharing associated with the conference. For peer-to-peer scenarios, including business-to-business conferences and point-to-point conferences in general, it is frequently the case that one or both endpoints exist behind a NAT. BFCP roles are negotiated in the offer/answer exchange as specified in [12], resulting in one endpoint being responsible for opening the TCP connection used for the BFCP communication.
既存のビデオ会議展開では、BFCPは会議に関連付けられているコンテンツ共有のためにフロアを管理するために使用されます。事業への会議およびポイントツーポイント会議を含むピアツーピアシナリオのために、一般的にはNATの後ろにある一方または両方のエンドポイントが存在する場合がよくあります。BFCPロールは[12]で指定されているオファー/回答Exchangeでネゴシエートされ、その結果、BFCP通信に使用されるTCP接続を開く責任があります。
+---------+
| Network |
+---------+
+-----+ / \ +-----+
| NAT |/ \| NAT |
+-----+ +-----+
+----+ / \ +----+
|BFCP|/ \|BFCP|
| UA | | UA |
+----+ +----+
Figure 50: Use case
図50：ユースケース
The communication session between the video conferencing endpoints typically consists of a number of RTP over UDP media streams for audio and video and a BFCP connection for floor control. Existing deployments are most common in, but not limited to, enterprise networks. In existing deployments, NAT traversal for the RTP streams works using ICE and/or other methods, including those described in [36].
ビデオ会議エンドポイント間の通信セッションは、通常、オーディオおよびビデオ用のUDPメディアストリーム上の多数のRTP、およびフロアコントロールのためのBFCP接続からなる。既存の展開は、エンタープライズネットワークにおいて最も一般的ですが、これに限定されません。既存の展開では、RTPストリームのNATトラバーサルは[36]に記載されているものを含む、ICEおよび/または他の方法を使用して機能します。
When enhancing an existing SIP-based video conferencing deployment with support for content sharing, the BFCP connection often poses a problem. The reasons for this fall into two general classes. First, there may be a strong preference for UDP-based signaling in general. On high-capacity endpoints (e.g., Public Switched Telephone Network (PSTN) gateways or SIP/H.323 inter-working gateways), TCP can suffer from head-of-line blocking, and it uses many kernel buffers. Network operators view UDP as a way to avoid both of these. Second, the establishment and traversal of the TCP connection involving ephemeral ports, as is typically the case with BFCP over TCP, can be problematic, as described in Appendix A of [34]. A broad study of NAT behavior and peer-to-peer TCP establishment for a comprehensive set of TCP NAT traversal techniques over a wide range of commercial NAT products concluded that it was not possible to establish a TCP connection in 11% of the cases [37]. The results are worse when focusing on enterprise NATs. A study of hole-punching as a NAT traversal technique across a wide variety of deployed NATs reported consistently higher success rates when using UDP than when using TCP [38].
It is worth noting that BFCP over UDP is already being used in real deployments, underlining the necessity to specify a common way to exchange BFCP messages where TCP is not appropriate, to avoid a situation where multiple different and non-interoperable implementations would coexist in the market. The purpose of this document is to extend the standard specification to support unreliable transport in order to facilitate complete interoperability between implementations.
BFCP Over UDPがすでに実際の展開で使用されていることに注目する価値があります。市場。この文書の目的は、実装間の完全な相互運用性を促進するために、信頼性の低い輸送をサポートするように標準仕様を拡張することです。
In selecting the approach of defining UDP as an alternate transport for BFCP, several alternatives were considered and explored to some degree. Each of these is discussed briefly in the following subsections. In summary, while the alternatives that were not chosen work in a number of scenarios, they are not sufficient, in and of themselves, to address the use case targeted by this document. The last alternative, presented in Appendix B.1.1.7, was selected and is specified in this document.
BFCPの代替輸送としてUDPを定義するためのアプローチを選択する際には、いくつかの選択肢が検討され、ある程度探求されました。これらのそれぞれについて、以下のサブセクションで簡単に説明します。要約すると、この文書の対象となるユースケースに対処するために、多くのシナリオで作業を選択しなかった代替案は、それらは十分ではなく、それ自体ではありません。付録B.1.1.7に提示された最後の選択肢が選択され、この文書で指定されています。
It is also worth noting that the IETF Transport Area was asked for a way to tunnel TCP over UDP, but at that point there was no consensus on how to achieve that.
IETF輸送地域がUDPを介してTCPをトンネルする方法を求められたことに注目する価値がありますが、その時点でそれを達成する方法についての合意はありませんでした。
ICE TCP [34] extends ICE to TCP-based media, including the ability to offer a mix of TCP- and UDP-based candidates for a single stream. ICE TCP has, in general, a lower success probability for enabling TCP connectivity without a relay if both of the hosts are behind a NAT (see Appendix A of [34]) than enabling UDP connectivity in the same scenarios. The happens because many of the currently deployed NATs in video conferencing networks do not support the flow of TCP handshake packets seen in the case of TCP simultaneous-open, either because they do not allow incoming TCP SYN packets from an address to which a SYN packet has been sent recently, or because they do not properly process the subsequent SYNACK. Implementing various techniques advocated for candidate collection in [34] should increase the success probability, but many of these techniques require support from some network elements (e.g., from the NATs). Such support is not common in enterprise NATs.
ICE TCP [34]は、単一のストリームのTCPおよびUDPベースの候補の組み合わせを提供する能力を含む、ICEをTCPベースのメディアに拡張します。ICE TCPは、一般に、同じシナリオでUDP接続を有効にするよりも、リレーなしでTCP接続を可能にするための低成功の確率が低い（[34]参照）。ビデオ会議ネットワークで現在展開されているNATの多くの多くは、TCP同時オープンの場合に見られるTCPハンドシェイクパケットのフローをサポートしていないため、SYNパケットがSYNパケットが入っているアドレスからのTCP SYNパケットを許可しないためです。最近送信された、または後続のシンコを正しく処理しないためです。[34]で候補収集のために提唱された様々な技術を実装するは、成功確率を増大させるべきであるが、これらの技術の多くはいくつかのネットワーク要素からのサポートを必要とする（例えば、NATから）。そのようなサポートは企業のNATでは一般的ではありません。
Teredo [31] enables nodes located behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP. Teredo extensions [32] provide additional capabilities to Teredo, including support for more types of NATs and support for more efficient communication.
Teredo [31]は、1つ以上のIPv4 NATの後ろにあるノードをイネーブルにして、UDP上のパケットをトンネリングすることによってIPv6接続を得ることができます。Teredo Extensions [32]は、より多くのタイプのNATとより効率的なコミュニケーションのサポートを支援するなど、テレドへの追加機能を提供します。
As defined, Teredo could be used to make BFCP work for the video conferencing use cases addressed in this document. However, running the service requires the help of "Teredo servers" and "Teredo relays" [31]. These servers and relays generally do not exist in current video conferencing deployments. It also requires IPv6 awareness on the endpoints. It should also be noted that ICMP6, as used with Teredo to complete an initial protocol exchange and confirm that the appropriate NAT bindings have been set up, is not a conventional feature of IPv4 or even IPv6, and some currently deployed IPv6 firewalls discard ICMP messages. As these networks continue to evolve and tackle the transaction to IPv6, Teredo servers and relays may be deployed, making Teredo available as a suitable alternative to BFCP over UDP.
定義されているように、このドキュメントで対処されているビデオ会議ユースケースのためにBFCPを作るためにTeredoを使用することができます。ただし、サービスを実行するには、「Teredo Servers」と「Teredo Releres」のヘルプが必要です[31]。これらのサーバーとリレーは一般的に現在のビデオ会議展開には存在しません。エンドポイントでIPv6認識も必要です。また、最初のプロトコル交換を完了し、適切なNATバインディングが設定されていることを確認し、適切なNATバインディングが設定されていることを確認し、IPv4またはIPv6の従来の機能ではなく、現在デプロイされているIPv6ファイアウォールがICMPメッセージを破棄しています。。これらのネットワークは、トランザクションをIPv6に進化させて取り組んでいきますので、Teredoサーバーとリレーを展開し、TeredoをUDPよりもBFCPに適した代替手段として入手できます。
GUT [35] attempts to facilitate tunneling over UDP by encapsulating the native transport protocol and its payload (in general the whole IP payload) within a UDP packet destined to the well-known port GUT_P. Unfortunately, it requires user-space TCP, for which there is not a readily available implementation, and creating one is a large project in itself. This document has expired, and its future is still unclear as it has not yet been adopted by a working group.
GUT [35]は、既知のポートGUT_P宛てのUDPパケット内で、ネイティブトランスポートプロトコルとペイロード（一般に全体のIPペイロード全体で）をカプセル化することによって、UDPを介してトンネリングを容易にしようとします。残念ながら、それはユーザー空間TCPを必要とし、そのためにすぐに利用可能な実装がないことを必要とし、それ自体の大きなプロジェクトである。この文書は期限切れになっており、未来はまだワーキンググループによって採用されていないので不明確です。
Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on the edge of the network, providing connectivity to the Internet for computers internal to the LAN, but do not allow Internet devices to connect to computers on the internal LAN. IGDs enable a computer on an internal LAN to create port mappings on their NAT, through which hosts on the Internet can send data that will be forwarded to the computer on the internal LAN. IGDs may be self-contained hardware devices or may be software components provided within an operating system.
ユニバーサルプラグアンドプレイインターネットゲートウェイデバイス（UPnP IGD）ネットワークのエッジに座り、LANの内部のコンピュータのインターネットへの接続を提供しますが、インターネットデバイスは内部LANのコンピュータに接続できません。IGDS内部LAN上のコンピュータを使用すると、インターネット上のホストが内部LAN上のコンピュータに転送されるデータを送信できるようにするために、NAT上のポートマッピングを作成できます。IGDSは自己完結型のハードウェアデバイスであり、オペレーティングシステム内に提供されているソフトウェアコンポーネントでもよい。
In considering UPnP IGD, several issues exist. Not all NATs support UPnP, and many that do support it are configured with it turned off by default. NATs are often multilayered, and UPnP does not work well with such NATs. For example, a typical DSL modem acts as a NAT, and the user plugs in a wireless access point behind that, which adds another layer of NAT. The client can discover the first layer of NAT using multicast, but it is harder to figure out how to discover and control NATs in the next layer up.
UPnP IGDを考慮すると、いくつかの問題が存在します。すべてのNATSがUPnPをサポートしているわけではなく、サポートされている多くの多くはデフォルトでオフになって設定されています。NATは多層化されており、UPnPはそのようなNATではうまく機能しません。たとえば、一般的なDSLモデムはNATとして機能し、ユーザーはその背後にある無線アクセスポイントを差し込みます。これにより、NATの別のレイヤーが追加されます。クライアントはマルチキャストを使用してNATの最初のレイヤーを発見することができますが、次のレイヤーのNATを検出および制御する方法を理解するのが難しくなります。
The NAT Port Mapping Protocol (NAT PMP) allows a computer in a private network (behind a NAT router) to automatically configure the router to allow parties outside the private network to contact it. NAT PMP runs over UDP. It essentially automates the process of port forwarding. Included in the protocol is a method for retrieving the public IP address of a NAT gateway, thus allowing a client to make this public IP address and port number known to peers that may wish to communicate with it.
NATポートマッピングプロトコル（NAT PMP）は、プライベートネットワーク内のコンピュータ（NATルータの後ろ）を使用して、プライベートネットワークの外部にパーティに連絡できるようにルータを自動的に構成できます。NAT PMPはUDPを介して実行されます。それは基本的にポート転送のプロセスを自動化します。プロトコルに含まれるのは、NATゲートウェイのパブリックIPアドレスを取得するための方法であり、したがってクライアントがそれと通信したいと思うかもしれないピアに既知のこのパブリックIPアドレスとポート番号を作成することを可能にします。
Many NATs do not support PMP. In those that do support it, it has similar issues with negotiation of multilayer NATs as UPnP. Video conferencing is used extensively in enterprise networks, and NAT PMP is not generally available in enterprise-class routers.
多くのNATはPMPをサポートしていません。それをサポートするものでは、UPnPとしての多層NATのネゴシエーションに関する類似の問題があります。ビデオ会議はエンタープライズネットワークで広く使用されており、NAT PMPは一般にエンタープライズクラスルータでは使用できません。
It would be quite straightforward to specify a BFCP binding for Stream Control Transmission Protocol (SCTP) [33], and then tunnel SCTP over UDP in the use case described in Appendix B.1. SCTP is gaining some momentum currently. There was ongoing discussion in the RTCWeb Working Group regarding this approach, which resulted in [29]. However, this approach to tunneling over UDP was not mature enough when considered and was not even fully specified.
Stream Control Transmission Protocol（SCTP）[33]のBFCPバインディングを指定し、次に付録B.1に記載されている使用例では、UDPを介してTUNNLESCTPを指定することは非常に簡単です。SCTPは現在いくつかの勢いを獲得しています。このアプローチに関するRTCWebワーキンググループにおいて継続的な議論がありました、それは[29]をもたらしました。ただし、UDPを介したトンネリングへのこのアプローチは、考慮されていても完全に指定されていない場合は十分に成熟していませんでした。
To overcome the problems with establishing TCP flows between BFCP entities, an alternative is to define UDP as an alternate transport for BFCP, leveraging the same mechanisms in place for the RTP over UDP media streams for the BFCP communication. When using UDP as the transport, following the guidelines provided in [15] is recommended.
BFCPエンティティ間のTCPフローを確立するという問題を克服するために、代替手段はBFCPのためのRTPの代わりに同じメカニズムを活用して、BFCP通信のためのRTPの代わりに同じメカニズムを活用することです。輸送としてUDPを使用する場合は、[15]に記載されているガイドラインに従って推奨されます。
Minor changes to the transaction model have been introduced in that all requests now have an appropriate response to complete the transaction. The requests are sent with a retransmission timer associated with the response to achieve reliability. This alternative does not change the semantics of BFCP. It permits UDP as an alternate transport.
トランザクションモデルへのマイナーな変更は、すべての要求がトランザクションを完了するために適切な応答を持っているという点で導入されました。要求は、信頼性を達成するために応答に関連する再送信タイマと共に送信される。この代替案はBFCPの意味論を変更しません。それは代替輸送としてのUDPを許可します。
Existing implementations, in the spirit of the approach detailed in earlier draft versions of this document, have demonstrated that this approach is feasible. Initial compatibility among implementations has been achieved at previous interoperability events. The authors view this extension as a pragmatic solution to an existing deployment challenge. This is the chosen approach, and the extensions are specified in this document.
この文書の以前のドラフトバージョンに詳述されているアプローチの精神にある既存の実装は、このアプローチが実行可能であることを実証しました。以前の相互運用性イベントで実装間の初期互換性が達成されました。著者らはこの拡張機能を既存の展開チャレンジに対する実用的な解決策として表示します。これが選択されたアプローチであり、この文書に拡張機能が指定されています。
Acknowledgements
謝辞
The XCON Working Group chairs, Adam Roach and Alan Johnston, provided useful ideas for RFC 4582 [3]. Additionally, Xiaotao Wu, Paul Kyzivat, Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morgan, and Oscar Novo provided useful comments during the work with RFC 4582. The authors also acknowledge contributions to the revision of BFCP for use over an unreliable transport from Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad, Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, Jörg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman, Vijaya Mandava, and Alan Ford. In the final phase, Ernst Horvath did a thorough review, revealing issues that needed clarification and changes. Useful and important final reviews were done by Mary Barnes. Paul Jones helped tremendously as editor for changes addressing IESG review comments.
XCONワーキンググループの椅子、Adam RoachおよびAlan Johnstonは、RFC 4582の便利なアイデアを提供しました[3]。さらに、Xiaotao Wu、Paul Kyzivat、Jonathan Rosenberg、Miguel A. Garcia-Martin、Mary Barnes、Ben Campbell、Dave Morgan、およびOscar Novoは、RFC 4582との協議に役立ちます。最初のアイデアを持っていたGeir Arne Sandbakkenからの信頼性の低い輸送で、Alfred E. Heggestad、Trond G. Andersen、Gonzalo Camarillo、Roniさえ、Lorenzo Miniero、JörgOtt、Eoin Mcleod、Mark K. Thompson、Hadriel Kaplan、Danウィング、カレンゼネンディング、ダビデンベンハム、NiveIna Melinkeri、Woo Johnman、Vijaya Mandava、およびAlan Ford。最後の段階では、Ernst Horvathは徹底的なレビューを行い、明確化と変更を必要とする問題を明らかにしました。有用で重要な最終レビューはメアリーバーンズによって行われました。Paul Jonesは、IESGレビューコメントに対応する変更のための編集者として途方を尽くしました。
Authors' Addresses
著者の住所
Gonzalo Camarillo Ericsson Hirsalantie 11 FI-02420 Jorvas Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Fi-02420 Jorvas Finland
Email: gonzalo.camarillo@ericsson.com
Keith Drage
キースドレージュ
Email: drageke@ntlworld.com
Tom Kristensen Jotron AS Ringdalskogen 8 3270 Larvik Norway
RingdalsKogenとしてのTom Kristensen Jotron 8 3270 Larvikノルウェー
Email: tom.kristensen@jotron.com, tomkri@ifi.uio.no
Jörg Ott Technical University Munich Boltzmannstrasse 3 85748 Garching Germany
JörgOttテクニカル大学ミュンヘンBoltzmannstrasse 3 85748 Garchingドイツ
Email: ott@in.tum.de
Charles Eckel Cisco 707 Tasman Drive Milpitas, California 95035 United States of America
Charles Eckel Cisco 707 Tasman Drive Milpitas、カリフォルニア州95035アメリカ
Email: eckelcu@cisco.com