Network Working Group G. Camarillo
Request for Comments: 4583 Ericsson
Category: Standards Track November 2006
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
二进制地板控制协议（BFCP）流的会话描述协议（SDP）格式
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.
本文档指定如何在会话描述协议（SDP）描述中描述二进制地板控制协议（BFCP）流。使用报价/应答模型建立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
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会话描述中对该信息进行编码，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”行（可能后跟在“a”行中编码的许多属性）被描述为任何其他媒体流。
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.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释，并指出合规实施的要求级别。
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=<media><port><transport><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。前者用于BFCP直接在TCP上运行时，后者用于BFCP在TLS上运行时，而后者又在TCP上运行。
The fmt (format) list is ignored for BFCP. The fmt list of BFCP 'm' lines SHOULD contain a single "*" character.
BFCP忽略fmt（格式）列表。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=application 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.
当两个端点建立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"
floor-control-attribute = "a=floorctrl:" role *(SP role)
role = "c-only" / "s-only" / "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-only：报价人只愿意充当楼层控制客户。
s-only: The offerer would be willing to act as a floor control server only.
s-only：报价人只愿意充当楼层控制服务器。
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显示了应答者的相应角色，具体取决于报价人的角色。
+---------+----------+
| Offerer | Answerer |
+---------+----------+
| c-only | s-only |
| s-only | c-only |
| c-s | c-s |
+---------+----------+
+---------+----------+
| 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
a=地板TRL: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”和“userid”SDP媒体级属性。楼层控制服务器使用这些属性分别向客户端提供会议ID和用户ID。它们的扩充BNF语法[2]是：
confid-attribute = "a=confid:" conference-id
conference-id = token
userid-attribute = "a=userid:" user-id
user-id = token
confid-attribute = "a=confid:" conference-id
conference-id = token
userid-attribute = "a=userid:" user-id
user-id = token
The 'confid' and the 'userid' attributes carry the integer representation of a conference ID and a user ID, respectively.
“confid”和“userid”属性分别携带会议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”和“userid”属性。作为报价人或应答人的楼层控制服务器应在其会话描述中包含这些属性。
We define the 'floorid' SDP media-level attribute. Its Augmented BNF syntax [2] is:
我们定义了“Floorrid”SDP媒体级别属性。其扩充的BNF语法[2]为：
floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)]
floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)]
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”行。它定义楼层标识符，并可能将其与一个或多个媒体流相关联。表示楼层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”和“label”属性。作为报价人或应答人的楼层控制服务器应在其会话描述中包含这些属性。
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.
“setup”属性指示哪个端点（客户端或楼层控制服务器）启动TCP连接。“connection”属性处理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.
BFCP规范[8]描述了客户机和楼层控制服务器之间需要重新建立TCP连接的许多情况。但是，该规范没有描述重建过程，因为该过程取决于连接最初是如何建立的。使用报价/应答模型的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.
当按照[8]中的规则重置现有TCP连接时，客户端应向楼层控制服务器生成报价，以便重新建立连接。如果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使用S/MIME[6]为提供/应答交换提供一个完整性保护通道，该通道具有可选的机密性。BFCP利用此完整性保护的提供/应答交换来执行身份验证。在要约/应答交换中，要约人和应答人交换其自签名证书的指纹。然后，这些自签名证书用于建立TLS连接，该连接将在报价人和应答人之间承载BFCP流量。
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连接，应答者将充当TLS服务器，而不管其在TCP建立过程中的角色（被动或主动）。
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=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
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格式约定，此文档将SDP拆分为内容超过72个字符的行。反斜杠字符标记此折线发生的位置。此反斜杠及其尾部的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=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
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]和offer/answer[4]规范分别讨论了与BFCP、SDP和offer/answer相关的安全问题。此外，[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“proto”值的注册
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“proto”字段注册了以下两个新值：
+--------------+-----------+
| Value | Reference |
+--------------+-----------+
| TCP/BFCP | RFC4583 |
| TCP/TLS/BFCP | RFC4583 |
+--------------+-----------+
+--------------+-----------+
| Value | Reference |
+--------------+-----------+
| TCP/BFCP | RFC4583 |
| TCP/TLS/BFCP | RFC4583 |
+--------------+-----------+
Table 2: Values for the SDP 'proto' field
表2:SDP“proto”字段的值
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")
Allowed attribute values: 1*("c-only" / "s-only" / "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:
本节指示IANA在会话描述协议（SDP）参数注册表下注册以下SDP att字段：
Contact name: Gonzalo.Camarillo@ericsson.com
联系人姓名：Gonzalo。Camarillo@ericsson.com
Attribute name: userid
属性名称：userid
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.
属性用途：“userid”属性携带用户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:
本节指示IANA在会话描述协议（SDP）参数注册表下注册以下SDP att字段：
Contact name: Gonzalo.Camarillo@ericsson.com
联系人姓名：Gonzalo。Camarillo@ericsson.com
Attribute name: floorid
属性名称：Floorrid
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”属性将地板与一个或多个媒体流相关联。
Allowed attribute values: Tokens
允许的属性值：标记
Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and Oscar Novo provided useful ideas for this document.
Joerg Ott、Keith Drage、Alan Johnston、Eric Rescorla、Roni Even和Oscar Novo为本文档提供了有用的想法。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年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] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“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] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，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.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[6] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1证书处理”，RFC 38502004年7月。
[7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[7] Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 41452005年9月。
[8] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.
[8] Camarillo，G.，Ott，J.，和K.Drage，“二进制地板控制协议（BFCP）”，RFC 4582，2006年11月。
[9] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, July 2006.
[9] Levin，O.和G.Camarillo，“会话描述协议（SDP）标签属性”，RFC 45742006年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] Lennox，J.，“会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输”，RFC 4572，2006年7月。
[11] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[11] Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
Author's Address
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。