Network Working Group G. Camarillo
Request for Comments: 4583 Ericsson
Category: Standards Track November 2006
Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
Abstract
抽象
This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers.
この文書では、バイナリフロア制御プロトコル（BFCP）はセッション記述プロトコル（SDP）の記述にストリームを記述する方法を指定します。 BFCPストリームを確立するために、オファー/アンサーモデルを使用して、ユーザーエージェントは、そのオファーとアンサーにこの形式を使用します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Fields in the 'm' Line ..........................................2
4. Floor Control Server Determination ..............................3
5. The 'confid' and 'userid' SDP Attributes ........................5
6. Association between Streams and Floors ..........................5
7. TCP Connection Management .......................................5
8. Authentication ..................................................6
9. Examples ........................................................7
10. Security Considerations ........................................8
11. IANA Considerations ............................................8
11.1. Registration of the 'TCP/BFCP' and 'TCP/TLS/BFCP'
SDP 'proto' Values ........................................8
11.2. Registration of the SDP 'floorctrl' Attribute .............8
11.3. Registration of the SDP 'confid' Attribute ................9
11.4. Registration of the SDP 'userid' Attribute ................9
11.5. Registration of the SDP 'floorid' Attribute ..............10
12. Acknowledgements ..............................................10
13. Normative References ..........................................10
As discussed in the BFCP (Binary Floor Control Protocol) specification [8], a given BFCP 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 the user identifier.
BFCP（バイナリフロア制御プロトコル）仕様で説明されているように[8]、所与BFCPクライアントは、フロア制御サーバへBFCP接続を確立するためにデータのセットを必要とします。これらのデータは、サーバーのトランスポート・アドレス、会議識別子、及びユーザ識別子が含まれます。
One way for clients to obtain this information is to use an offer/answer [4] exchange. This document specifies how to encode this information in the SDP session descriptions that are part of such an offer/answer exchange.
クライアントはこの情報を取得するための一つの方法は、オファー/アンサー[4]交換を使用することです。この文書では、そのようなオファー/アンサー交換の一部であるSDPセッション記述では、この情報を符号化する方法を指定します。
User agents typically use the offer/answer model to establish a number of media streams of different types. Following this model, a BFCP connection is described as any other media stream by using an SDP 'm' line, possibly followed by a number of attributes encoded in 'a' lines.
ユーザーエージェントは、一般的に、異なるタイプのメディアストリームの数を確立するために、オファー/アンサーモデルを使用します。このモデル以下、BFCP接続は、おそらく「」線で符号化属性の数が続くSDPの「m」行を使用して、任意の他のメディアストリームとして記述されています。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、および「OPTIONAL」[1] BCP 14、RFC 2119に記載されるように解釈されるべきであり、対応する実装の要求レベルを示します。
This section describes how to generate an 'm' line for a BFCP stream.
このセクションでは、BFCPストリームのための「M」行を生成する方法について説明します。
According to the SDP specification [11], the 'm' line format is the following:
SDP仕様[11]によれば、m個の行の形式は以下の通りです。
m=<media> <port> <transport> <fmt> ...
M = <メディア> <ポート> <トランスポート> <FMT> ...
The media field MUST have a value of "application".
メディアフィールドは、「アプリケーション」の値を持つ必要があります。
The port field is set following the rules in [7]. Depending on the value of the 'setup' attribute (discussed in Section 7), the port field contains the port to which the remote endpoint will initiate its TCP connection or is irrelevant (i.e., the endpoint will initiate the connection towards the remote endpoint) and should be set to a value of 9, which is the discard port. Since BFCP only runs on top of TCP, the port is always a TCP port. A port field value of zero has the standard SDP meaning (i.e., rejection of the media stream).
ポートフィールドは、[7]に規則に従って設定されています。 （第7節で説明）「セットアップ」属性の値に応じて、ポートフィールドは、リモートエンドポイントがTCP接続を開始するか、無関係である先のポートが含まれています（つまり、エンドポイントがリモートエンドポイントへの接続を開始します）そして廃棄ポートである9の値に設定されるべきです。 BFCPのみTCPの上で実行されるため、ポートは常にTCPポートです。ゼロのポートフィールドの値が標準SDP意味を有する（すなわち、メディア・ストリームの拒絶）。
We define two new values for the transport field: TCP/BFCP and TCP/TLS/BFCP. The former is used when BFCP runs directly on top of TCP, and the latter is used when BFCP runs on top of TLS, which in turn runs on top of TCP.
TCP / BFCPおよびTCP / TLS / BFCP：私たちは、輸送分野のための2つの新しい値を定義します。 BFCPは、TCPの上に直接実行されるとき、前者が使用され、そしてBFCPは順番にTCP上で動作TLSの上で動作するとき、後者が使用されます。
The fmt (format) list is ignored for BFCP. The fmt list of BFCP 'm' lines SHOULD contain a single "*" character.
FMT（フォーマット）リストはBFCPでは無視されます。 BFCP「M」行のFMTリストは、単一の「*」の文字を含むべきです。
The following is an example of an 'm' line for a BFCP connection:
以下はBFCP接続用の「m」行の例です。
m=application 50000 TCP/TLS/BFCP *
M =アプリケーション50000 TCP / TLS / BFCP *
When two endpoints establish a BFCP stream, they need to determine which of them acts as a floor control server. In the most common scenario, a client establishes a BFCP stream with a conference server that acts as the floor control server. Floor control server determination is straight forward because one endpoint can only act as a client and the other can only act as a floor control server.
2つのエンドポイントは、BFCPストリームを確立すると、彼らはフロア制御サーバとして機能し、それらのどれかを決定する必要があります。最も一般的なシナリオでは、クライアントは、フロア制御サーバとして動作する会議サーバとのBFCPストリームを確立します。一方のエンドポイントが唯一のクライアントとして機能することができ、他方は唯一のフロア制御サーバとして機能することができますので、フロア制御サーバの決意は単純です。
However, there are scenarios where both endpoints could act as a floor control server. For example, in a two-party session that involves an audio stream and a shared whiteboard, the endpoints need to decide which party will be acting as the floor control server.
しかし、両方のエンドポイントがフロア制御サーバとして作用することができるシナリオがあります。例えば、オーディオストリームと共有ホワイトボードを必要とする二者のセッションでは、エンドポイントは、フロア制御サーバとして動作されるパーティを決定する必要があります。
Furthermore, there are situations where both the offerer and the answerer act as both clients and floor control servers in the same session. For example, in a two-party session that involves an audio stream and a shared whiteboard, one party acts as the floor control server for the audio stream and the other acts as the floor control server for the shared whiteboard.
さらに、同じセッションで両方のクライアントとフロア制御サーバなどの申し出人と解答行為の両方の状況があります。例えば、オーディオストリームと共有ホワイトボードを含む二者のセッションで、一方の当事者は、オーディオストリームのフロア制御サーバと共有ホワイトボード用のフロア制御サーバなどの他の作用として働きます。
We define the 'floorctrl' SDP media-level attribute to perform floor control determination. Its Augmented BNF syntax [2] is:
私たちは、フロア制御決意を実行するには、「floorctrl」SDPメディアレベル属性を定義します。その拡張BNF構文は[2]です。
floor-control-attribute = "a=floorctrl:" role *(SP role) role = "c-only" / "s-only" / "c-s"
フロアコントロール属性= "A = floorctrl：" ロール*（SPの役割）役割= "C-のみ" / "S-のみ" / "C-S"
The offerer includes this attribute to state all the roles it would be willing to perform:
オファー側はそれを行うことをいとわないすべての役割を述べるためにこの属性が含まれています。
c-only: The offerer would be willing to act as a floor control client only.
C-のみ：オファー側はフロア制御クライアントとして動作することをいといません。
s-only: The offerer would be willing to act as a floor control server only.
S-のみ：オファー側は、フロア制御サーバとして動作することをいといません。
c-s: The offerer would be willing to act both as a floor control client and as a floor control server.
C-S：オファー側は、フロア制御クライアントとして、フロア制御サーバの両方として動作することをいといません。
If an 'm' line in an offer contains a 'floorctrl' attribute, the answerer MUST include one in the corresponding 'm' line in the answer. The answerer includes this attribute to state which role the answerer will perform. That is, the answerer chooses one of the roles the offerer is willing to perform and generates an answer with the corresponding role for the answerer. Table 1 shows the corresponding roles for an answerer, depending on the offerer's role.
提供中の「m」の行は「floorctrl」属性が含まれている場合、回答は答えにおける対応する「m」の行の1を含まなければなりません。回答は、回答が行われる役割状態にするには、この属性が含まれています。すなわち、回答は申出を行う意思がある役割の1つを選択し、回答のための対応する役割と答えを生成します。表1は、オファーの役割に応じて、回答のための対応する役割を示しています。
+---------+----------+
| Offerer | Answerer |
+---------+----------+
| c-only | s-only |
| s-only | c-only |
| c-s | c-s |
+---------+----------+
Table 1: Roles
表1：役割
The following are the descriptions of the roles when they are chosen by an answerer:
彼らは回答によって選択されたときに役割の説明を以下に示します。
c-only: The answerer will act as a floor control client. Consequently, the offerer will act as a floor control server.
C-のみ：回答は、フロア制御クライアントとして動作します。その結果、オファー側は、フロア制御サーバとして機能します。
s-only: The answerer will act as a floor control server. Consequently, the offerer will act as a floor control client.
S-のみ：回答は、フロア制御サーバとして機能します。その結果、オファー側は、フロア制御クライアントとして動作します。
c-s: The answerer will act both as a floor control client and as a floor control server. Consequently, the offerer will also act both as a floor control client and as a floor control server.
C-S：回答は、フロア制御クライアントとして、フロア制御サーバの両方として機能します。その結果、オファー側はまた、フロア制御クライアントとして、フロア制御サーバとしての両方の機能します。
Endpoints that use the offer/answer model to establish BFCP connections MUST support the 'floorctrl' attribute. A floor control server acting as an offerer or as an answerer SHOULD include this attribute in its session descriptions.
BFCP接続を確立するためにオファー/アンサーモデルを使用するエンドポイントは「floorctrl」属性をサポートしなければなりません。オファー側として、あるいは回答として作用する床制御サーバは、そのセッションの説明では、この属性を含むべきです。
If the 'floorctrl' attribute is not used in an offer/answer exchange, by default the offerer and the answerer will act as a floor control client and as a floor control server, respectively.
「floorctrl」属性がオファー/アンサー交換に使用されていない場合は、デフォルトでオファー側とアンサーは、それぞれ、フロア制御クライアントとして、フロア制御サーバとして機能します。
The following is an example of a 'floorctrl' attribute in an offer. When this attribute appears in an answer, it only carries one role:
以下は、提供の「floorctrl」属性の一例です。この属性が答えに表示されたら、それは唯一の役割を運びます：
a=floorctrl:c-only s-only c-s
= floorctrl：C-SのみのみのC-S
We define the 'confid' and the 'userid' SDP media-level attributes. These attributes are used by a floor control server to provide a client with a conference ID and a user ID, respectively. Their Augmented BNF syntax [2] is:
私たちは、「confid」と「ユーザID」SDPメディアレベル属性を定義します。これらの属性は、それぞれ、会議IDとユーザーIDをクライアントに提供するために、フロア制御サーバによって使用されています。彼らの拡張BNF構文は[2]です。
confid-attribute = "a=confid:" conference-id conference-id = token userid-attribute = "a=userid:" user-id user-id = token
confid属性= "A = confid：" 会議-ID会議-ID =トークンユーザーID属性= "A =ユーザーID：" ユーザーIDユーザーID =トークン
The 'confid' and the 'userid' attributes carry the integer representation of a conference ID and a user ID, respectively.
「confid」と「ユーザID」の属性は、それぞれ、会議IDの整数表現とユーザIDを運びます。
Endpoints that use the offer/answer model to establish BFCP connections MUST support the 'confid' and the 'userid' attributes. A floor control server acting as an offerer or as an answerer SHOULD include these attributes in its session descriptions.
BFCP接続を確立するためにオファー/アンサーモデルを使用するエンドポイントは「confid」と「ユーザIDの属性をサポートしなければなりません。オファー側として、あるいは回答として作用する床制御サーバは、そのセッションの説明ではこれらの属性を含むべきです。
We define the 'floorid' SDP media-level attribute. Its Augmented BNF syntax [2] is:
私たちは、「floorid」SDPメディアレベル属性を定義します。その拡張BNF構文は[2]です。
floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)]
floorid属性= "A = floorid：" トークン[ "mstrm：" トークン*（SPトークン）]
The 'floorid' attribute is used in BFCP 'm' lines. It defines a floor identifier and, possibly, associates it with one or more media streams. The token representing the floor ID is the integer representation of the Floor ID to be used in BFCP. The token representing the media stream is a pointer to the media stream, which is identified by an SDP label attribute [9].
「floorid」属性はBFCP「M」行で使用されています。それは、おそらく、1つまたは複数のメディア・ストリームに関連付け、フロア識別子を定義し。フロアIDを表すトークンはBFCPで使用するフロアIDの整数です。メディアストリームを表すトークンは、SDPラベル属性によって識別されるメディアストリーム、[9]へのポインタです。
Endpoints that use the offer/answer model to establish BFCP connections MUST support the 'floorid' and the 'label' attributes. A floor control server acting as an offerer or as an answerer SHOULD include these attributes in its session descriptions.
BFCP接続を確立するためにオファー/アンサーモデルを使用するエンドポイントは、「floorid」と「ラベル」をサポートしなければならない属性。オファー側として、あるいは回答として作用する床制御サーバは、そのセッションの説明ではこれらの属性を含むべきです。
The management of the TCP connection used to transport BFCP is performed using the 'setup' and 'connection' attributes, as defined in [7].
[7]で定義されるようBFCPを輸送するために使用されるTCP接続の管理は、「セットアップ」および「接続」属性を使用して実行されます。
The 'setup' attribute indicates which of the endpoints (client or floor control server) initiates the TCP connection. The 'connection' attribute handles TCP connection reestablishment.
「セットアップ」属性は、TCP接続を開始し、エンドポイント（クライアントまたはフロア制御サーバ）のどちらを示しています。 「接続」属性は、TCP接続の再確立を処理します。
The BFCP specification [8] describes a number of situations when the TCP connection between a client and the floor control server needs to be reestablished. However, that specification does not describe the reestablishment process because this process depends on how the connection was established in the first place. BFCP entities using the offer/answer model follow the following rules.
クライアントとフロア制御サーバ間のTCP接続を再確立する必要があるときBFCP仕様[8]は多くの状況を説明しています。このプロセスは、接続が最初に確立された方法によって異なりますので、しかし、その仕様は、再確立プロセスを説明していません。オファー/アンサーモデルを使用してBFCPエンティティは、次の規則に従ってください。
When the existing TCP connection is reset following the rules in [8], the client SHOULD generate an offer towards the floor control server in order to reestablish the connection. If a TCP connection cannot deliver a BFCP message and times out, the entity that attempted to send the message (i.e., the one that detected the TCP timeout) SHOULD generate an offer in order to reestablish the TCP connection.
既存のTCP接続は、[8]の規則次リセットされると、クライアントは接続を再確立するために、フロア制御サーバへの提供を生成する必要があります。 TCP接続はBFCPメッセージ及びタイムアウトし、メッセージを送信しようとするエンティティを配信できない場合（すなわち、TCPタイムアウトを検出したもの）TCP接続を再確立するためにオファーを生成する必要があります。
Endpoints that use the offer/answer model to establish BFCP connections MUST support the 'setup' and 'connection' attributes.
BFCP接続を確立するためにオファー/アンサーモデルを使用するエンドポイントは、「セットアップ」と「接続の属性をサポートしなければなりません。
When a BFCP connection is established using the offer/answer model, it is assumed that the offerer and the answerer authenticate each other using some mechanism. Once this mutual authentication takes place, all the offerer and the answerer need to ensure is that the entity they are receiving BFCP messages from is the same as the one that generated the previous offer or answer.
BFCP接続がオファー/アンサーモデルを使用して確立された場合は、オファー側とアンサーは、いくつかのメカニズムを使用して互いを認証するものとします。この相互認証が行われると、確保するために必要なすべてのオファー側とアンサーは、彼らがからBFCPメッセージを受信しているエンティティは、以前のオファーまたは回答を生成したものと同じであるということです。
When SIP is used to perform an offer/answer exchange, the initial mutual authentication takes place at the SIP level. Additionally, SIP uses S/MIME [6] to provide an integrity-protected channel with optional confidentiality for the offer/answer exchange. BFCP takes advantage of this integrity-protected offer/answer exchange to perform authentication. Within the offer/answer exchange, the offerer and answerer exchange the fingerprints of their self-signed certificates. These self-signed certificates are then used to establish the TLS connection that will carry BFCP traffic between the offerer and the answerer.
SIPは、オファー/アンサー交換を実行するために使用される場合、最初の相互認証は、SIPレベルで行われます。また、SIPは、[6]オファー/アンサー交換のためのオプションの機密性と完全性保護されたチャネルを提供するために、S / MIMEを使用しています。 BFCPは、認証を実行するには、この整合性が保護オファー/アンサー交換を利用しています。オファー/アンサー交換の中で、オファー側とアンサーは、彼らの自己署名証明書のフィンガープリントを交換します。これらの自己署名証明書、その後、オファーと回答間BFCPトラフィックを運ぶでしょうTLS接続を確立するために使用されています。
BFCP clients and floor control servers follow the rules in [10] regarding certificate choice and presentation. This implies that unless a 'fingerprint' attribute is included in the session description, the certificate provided at the TLS-level MUST either be directly signed by one of the other party's trust anchors or be validated using a certification path that terminates at one of the other party's trust anchors [5]. Endpoints that use the offer/answer
BFCPクライアントとフロア制御サーバは、証明書の選択とプレゼンテーションに関する[10]の規則に従ってください。これは、「指紋」属性はセッション記述に含まれていない限り、TLSレベルで提供する証明書は、直接相手のトラストアンカーの一つによって署名されなければならないかのいずれかで終了する証明書パスを使用して検証することを意味します相手の信頼アンカー[5]。オファー/アンサーを使用するエンドポイント
model to establish BFCP connections MUST support the 'fingerprint' attribute and SHOULD include it in their session descriptions.
BFCP接続を確立するためのモデルは、「指紋」属性をサポートしなければならないし、そのセッション記述に含めるべきです。
When TLS is used, once the underlaying TCP connection is established, the answerer acts as the TLS server regardless of its role (passive or active) in the TCP establishment procedure.
TLSを使用する場合、基礎となるTCP接続が確立されると、回答は、TCP確立手順における（受動的または能動的）その役割に関係なくTLSサーバとして機能します。
For the purpose of brevity, the main portion of the session description is omitted in the examples, which only show 'm' lines and their attributes.
簡潔の目的のために、セッション記述の主要部分は、「M」線及びその属性を示す実施例では省略されています。
The following is an example of an offer sent by a conference server to a client.
以下は、クライアントに会議サーバによって送信されたオファーの一例です。
m=application 50000 TCP/TLS/BFCP * a=setup:passive a=connection:new a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=floorctrl:s-only a=confid:4321 a=userid:1234 a=floorid:1 m-stream:10 a=floorid:2 m-stream:11 m=audio 50002 RTP/AVP 0 a=label:10 m=video 50004 RTP/AVP 31 a=label:11
M =アプリケーション50000 TCP / TLS / BFCP * A =セットアップ：受動A =接続：新しいA =指紋：SHA-1 \ 4A：AD：B9：B1：3F：82：18：3B：12：54：02： DF：3E：5D：49：6B：19：E5：7C：ABのA = floorctrl：S-のみ= confid：4321 =ユーザーID：1234 = floorid：1 M-ストリーム：10 = floorid：2メートル-stream：11、M =オーディオ50002 RTP / AVP 0 A =ラベル10 M =ビデオ50004 RTP / AVP 31 =ラベル：11
Note that due to RFC formatting conventions, this document splits SDP across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content.
RFCの表記規則のために、この文書は、その内容が72文字を超える行にSDPを分割することに注意してください。バックスラッシュ文字は、この行の折りたたみが行われた場所をマークします。このバックスラッシュとその末尾のCRLFと空白文字は、実際のSDPのコンテンツには表示されません。
The following is the answer returned by the client.
以下は、クライアントによって返された答えです。
m=application 9 TCP/TLS/BFCP * a=setup:active a=connection:new a=fingerprint:SHA-1 \ 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 a=floorctrl:c-only m=audio 55000 RTP/AVP 0 m=video 55002 RTP/AVP 31
M =アプリケーション9 TCP / TLS / BFCP * A =セットアップ：アクティブA =接続：新A =指紋：SHA-1 \ 3D：B4：7B：E3：CC：FC：0D：1B：5D：31：33： 9E：48：9B：67：FE：68：40：E8：21 = floorctrl：CのみM =オーディオ55000 RTP / AVP 0メートル=ビデオ55002 RTP / AVP 31
The BFCP [8], SDP [11], and offer/answer [4] specifications discuss security issues related to BFCP, SDP, and offer/answer, respectively. In addition, [7] and [10] discuss security issues related to the establishment of TCP and TLS connections using an offer/answer model.
BFCP [8]、SDP [11]、およびオファー/アンサー[4]仕様は、それぞれ、BFCP、SDP、およびオファー/アンサーに関連するセキュリティ上の問題を議論します。また、[7]および[10]オファー/アンサーモデルを使用してTCPおよびTLS接続の確立に関連するセキュリティ上の問題を議論します。
BFCP assumes that an initial integrity-protected channel is used to exchange self-signed certificates between a client and the floor control server. For session descriptions carried in SIP [3], S/MIME [6] is the natural choice to provide such a channel.
BFCPは、最初の整合性が保護チャネルは、クライアントとフロア制御サーバ間の自己署名証明書を交換するために使用されていることを前提としています。 SIPで運ばれるセッション記述[3]、S / MIMEは、[6]このようなチャネルを提供する自然な選択です。
11.1. Registration of the 'TCP/BFCP' and 'TCP/TLS/BFCP' SDP 'proto' Values
11.1. 'TCP / BFCP' と 'TCP / TLS / BFCP' SDP 'プロト' 値の登録
The IANA has registered the following two new values for the SDP 'proto' field under the Session Description Protocol (SDP) Parameters registry:
IANAは、セッション記述プロトコル（SDP）の下でSDP「プロト」欄には、次の2つの新しい値を登録しているレジストリパラメータ：
+--------------+-----------+
| Value | Reference |
+--------------+-----------+
| TCP/BFCP | RFC4583 |
| TCP/TLS/BFCP | RFC4583 |
+--------------+-----------+
Table 2: Values for the SDP 'proto' field
表2：SDP「プロト」フィールドの値
The IANA has registered the following SDP att-field under the Session Description Protocol (SDP) Parameters registry:
IANAは、セッション記述プロトコル（SDP）の下で、次のSDP ATT-フィールドを登録したレジストリパラメータ：
Contact name: Gonzalo.Camarillo@ericsson.com
担当者名：Gonzalo.Camarillo@ericsson.com
Attribute name: floorctrl
floorctrl：属性名
Long-form attribute name: Floor Control
長編属性名：フロア制御
Type of attribute: Media level
属性の種類：メディアレベル
Subject to charset: No
文字セットの件名：いいえ
Purpose of attribute: The 'floorctrl' attribute is used to perform floor control server determination.
属性の目的：「floorctrl」属性は、フロア制御サーバの決意を実行するために使用されます。
Allowed attribute values: 1*("c-only" / "s-only" / "c-s")
許可された属性値：1 *（ "C-のみ" / "S-のみ" / "C-S"）
The IANA has registered the following SDP att-field under the Session Description Protocol (SDP) Parameters registry:
IANAは、セッション記述プロトコル（SDP）の下で、次のSDP ATT-フィールドを登録したレジストリパラメータ：
Contact name: Gonzalo.Camarillo@ericsson.com
担当者名：Gonzalo.Camarillo@ericsson.com
Attribute name: confid
confid：属性名
Long-form attribute name: Conference Identifier
長い形式の属性名：会議識別子
Type of attribute: Media level
属性の種類：メディアレベル
Subject to charset: No
文字セットの件名：いいえ
Purpose of attribute: The 'confid' attribute carries the integer representation of a Conference ID.
属性の目的：「confid」属性会議IDの整数表現を運びます。
Allowed attribute values: A token
許可された属性値：トークン
This section instructs the IANA to register the following SDP att-field under the Session Description Protocol (SDP) Parameters registry:
このセクションでは、セッション記述プロトコル（SDP）パラメータのレジストリの下に、次のSDP ATT-フィールドを登録するにはIANAに指示します。
Contact name: Gonzalo.Camarillo@ericsson.com
担当者名：Gonzalo.Camarillo@ericsson.com
Attribute name: userid
ユーザーID：属性名
Long-form attribute name: User Identifier
長い形式の属性名：ユーザ識別子
Type of attribute: Media level
属性の種類：メディアレベル
Subject to charset: No
文字セットの件名：いいえ
Purpose of attribute: The 'userid' attribute carries the integer representation of a User ID.
属性の目的：「ユーザーID」属性のユーザーIDの整数表現を運びます。
Allowed attribute values: A token
許可された属性値：トークン
This section instructs the IANA to register the following SDP att-field under the Session Description Protocol (SDP) Parameters registry:
このセクションでは、セッション記述プロトコル（SDP）パラメータのレジストリの下に、次のSDP ATT-フィールドを登録するにはIANAに指示します。
Contact name: Gonzalo.Camarillo@ericsson.com
担当者名：Gonzalo.Camarillo@ericsson.com
Attribute name: floorid
floorid：属性名
Long-form attribute name: Floor Identifier
長い形式の属性名：フロア識別子
Type of attribute: Media level
属性の種類：メディアレベル
Subject to charset: No
文字セットの件名：いいえ
Purpose of attribute: The 'floorid' attribute associates a floor with one or more media streams.
属性の目的：「floorid」属性は、1つまたは複数のメディアストリームで床を関連付けます。
Allowed attribute values: Tokens
許可された属性値：トークン
Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and Oscar Novo provided useful ideas for this document.
イェルク・オット、キース糖剤、アラン・ジョンストン、エリックレスコラ、ロニでも、オスカーノボはこのドキュメントのために有益なアイデアを提供しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[4]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[5] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[6] Ramsdell、B.は、RFC 3850、2004年7月 "/多目的インターネットメール拡張（S / MIME）バージョン3.1証明書の処理を固定します"。
[7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[7]ヨン、D.とG.キャマリロ、 "セッション記述プロトコル（SDP）におけるTCPベースのメディア交通"、RFC 4145、2005年9月。
[8] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.
[8]キャマリロ、G.、オット、J.、およびK.糖衣錠、 "バイナリフロア制御プロトコル（BFCP）"、RFC 4582、2006年11月。
[9] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, July 2006.
[9]レヴィン、O.およびG.キャマリロ、 "セッション記述プロトコル（SDP）label属性"、RFC 4574、2006年7月。
[10] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[10]レノックス、J.、 "接続指向のセッション記述プロトコル（SDP）でTransport Layer Security（TLS）プロトコルを介してメディアトランスポート"、RFC 4572、2006年7月。
[11] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[11]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
Author's Address
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。