draft-ietf-bfcpbis-rfc4582bis-05.txt   draft-ietf-bfcpbis-rfc4582bis-06.txt 
BFCPbis Working Group G. Camarillo BFCPbis Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: 4582 (if approved) K. Drage Obsoletes: 4582 (if approved) K. Drage
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: March 2, 2013 T. Kristensen Expires: April 15, 2013 T. Kristensen
Cisco Cisco
J. Ott J. Ott
Aalto University Aalto University
C. Eckel C. Eckel
Cisco Cisco
August 29, 2012 October 12, 2012
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-bfcpbis-rfc4582bis-05 draft-ietf-bfcpbis-rfc4582bis-06
Abstract Abstract
Floor control is a means to manage joint or exclusive access to Floor control is a means to manage joint or exclusive access to
shared resources in a (multiparty) conferencing environment. shared resources in a (multiparty) conferencing environment.
Thereby, floor control complements other functions -- such as Thereby, floor control complements other functions -- such as
conference and media session setup, conference policy manipulation, conference and media session setup, conference policy manipulation,
and media control -- that are realized by other protocols. and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP). This document specifies the Binary Floor Control Protocol (BFCP).
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 2, 2013. This Internet-Draft will expire on April 15, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Floor Creation . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Floor Creation . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Obtaining Information to Contact a Floor Control Server . 9 3.2. Obtaining Information to Contact a Floor Control Server . 9
3.3. Obtaining Floor-Resource Associations . . . . . . . . . . 9 3.3. Obtaining Floor-Resource Associations . . . . . . . . . . 9
3.4. Privileges of Floor Control . . . . . . . . . . . . . . . 10 3.4. Privileges of Floor Control . . . . . . . . . . . . . . . 10
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 10 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 4, line 13 skipping to change at page 3, line 29
5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 38 5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 38
5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . . 38 5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . . 38
5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38 5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 38 5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 38
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . . 39 6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . . 39
6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . 40 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . 40
6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . 41 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . 41
6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42
6.3. Large Message Considerations . . . . . . . . . . . . . . . 42 6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . . 42
6.3.1. Fragmentation Handling . . . . . . . . . . . . . . . . 42 6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 43
6.3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 43
7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 43 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 43
8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 44 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 44
8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 44 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 44
8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 44 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 44
8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 45 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 45
8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 45 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 45
8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 46 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 45
9. Authentication and Authorization . . . . . . . . . . . . . . . 46 9. Authentication and Authorization . . . . . . . . . . . . . . . 46
9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 46 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 46
10. Floor Participant Operations . . . . . . . . . . . . . . . . . 47 10. Floor Participant Operations . . . . . . . . . . . . . . . . . 47
10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 47 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 47
10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 47 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 47
10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 48 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 48
10.1.3. Reception of a Subsequent FloorRequestStatus 10.1.3. Reception of a Subsequent FloorRequestStatus
Message . . . . . . . . . . . . . . . . . . . . . . . 50 Message . . . . . . . . . . . . . . . . . . . . . . . 49
10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 50 10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 50
10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 50 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 50
10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 50 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 50
11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 51 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 51
11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 51 11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 51
11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 52 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 52
12. General Client Operations . . . . . . . . . . . . . . . . . . 53 12. General Client Operations . . . . . . . . . . . . . . . . . . 53
12.1. Requesting Information about Floors . . . . . . . . . . . 53 12.1. Requesting Information about Floors . . . . . . . . . . . 53
12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 53 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 53
12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 54 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 53
12.1.3. Reception of a Subsequent FloorStatus Message . . . . 54 12.1.3. Reception of a Subsequent FloorStatus Message . . . . 54
12.2. Requesting Information about Floor Requests . . . . . . . 54 12.2. Requesting Information about Floor Requests . . . . . . . 54
12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 55 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 55
12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 55 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 55
12.3. Requesting Information about a User . . . . . . . . . . . 55 12.3. Requesting Information about a User . . . . . . . . . . . 55
12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 56 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 56
12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 56 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 56
12.4. Obtaining the Capabilities of a Floor Control Server . . . 57 12.4. Obtaining the Capabilities of a Floor Control Server . . . 57
12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 57 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 57
12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 57 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 57
skipping to change at page 5, line 26 skipping to change at page 4, line 40
13.6. Reception of a ChairAction Message . . . . . . . . . . . . 67 13.6. Reception of a ChairAction Message . . . . . . . . . . . . 67
13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 68 13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 68
13.8. Error Message Generation . . . . . . . . . . . . . . . . . 69 13.8. Error Message Generation . . . . . . . . . . . . . . . . . 69
14. Security Considerations . . . . . . . . . . . . . . . . . . . 69 14. Security Considerations . . . . . . . . . . . . . . . . . . . 69
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 70 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 70
15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 71 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 71
15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 72 15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 72
15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 73 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 73
16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 74 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 74
16.1. Extensions for unreliable transport . . . . . . . . . . . 74
16.2. Other changes . . . . . . . . . . . . . . . . . . . . . . 75
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76
18.1. Normative References . . . . . . . . . . . . . . . . . . . 76 18.1. Normative References . . . . . . . . . . . . . . . . . . . 76
18.2. Informational References . . . . . . . . . . . . . . . . . 77 18.2. Informational References . . . . . . . . . . . . . . . . . 77
Appendix A. Example Call Flows for BFCP over Unreliable Appendix A. Example Call Flows for BFCP over Unreliable
Transport . . . . . . . . . . . . . . . . . . . . . . 78 Transport . . . . . . . . . . . . . . . . . . . . . . 78
Appendix B. Motivation for Supporting Unreliable Transport . . . 82 Appendix B. Motivation for Supporting Unreliable Transport . . . 82
B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 82 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 82
B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 83 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 83
B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 83 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 84
B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 84 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 84
B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 84 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 84
B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 84 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 85
B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 85 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 85
B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 85 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 85
B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 85 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
Within a conference, some applications need to manage the access to a 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 set of shared resources, such as the right to send media to a
particular media session. Floor control enables such applications to particular media session. Floor control enables such applications to
provide users with coordinated (shared or exclusive) access to these provide users with coordinated (shared or exclusive) access to these
resources. resources.
skipping to change at page 10, line 34 skipping to change at page 10, line 34
BFCP messages, which use a TLV (Type-Length-Value) binary encoding, BFCP messages, which use a TLV (Type-Length-Value) binary encoding,
consist of a common header followed by a set of attributes. The consist of a common header followed by a set of attributes. The
common header contains, among other information, a 32-bit conference common header contains, among other information, a 32-bit conference
identifier. Floor participants, media participants, and floor chairs identifier. Floor participants, media participants, and floor chairs
are identified by 16-bit user identifiers. are identified by 16-bit user identifiers.
BFCP supports nested attributes (i.e., attributes that contain BFCP supports nested attributes (i.e., attributes that contain
attributes). These are referred to as grouped attributes. attributes). These are referred to as grouped attributes.
There are two types of transaction in BFCP: client-initiated There are two types of transactions in BFCP: client-initiated
transactions and server-initiated transactions. Client-initiated transactions and server-initiated transactions (notifications),
transactions consist of a message from a client to the floor control further details in Section 8.
server and a response from the floor control server to the client.
Correspondingly, server-initiated transactions consist of a message
from the floor control server to a client and the associated
acknowledgement message from the client to the floor control server.
Both messages can be related because they carry the same Transaction
ID value in their common headers.
4.1. Floor Participant to Floor Control Server Interface 4.1. Floor Participant to Floor Control Server Interface
Floor participants request a floor by sending a FloorRequest message Floor participants request a floor by sending a FloorRequest message
to the floor control server. BFCP supports third-party floor to the floor control server. BFCP supports third-party floor
requests. That is, the floor participant sending the floor request requests. That is, the floor participant sending the floor request
need not be colocated with the media participant that will get the need not be colocated with the media participant that will get the
floor once the floor request is granted. FloorRequest messages carry floor once the floor request is granted. FloorRequest messages carry
the identity of the requester in the User ID field of the common 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- header, and the identity of the beneficiary of the floor (in third-
skipping to change at page 17, line 6 skipping to change at page 17, line 6
| Fragment Offset (if F is set) | Fragment Length (if F is set) | | Fragment Offset (if F is set) | Fragment Length (if F is set) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: COMMON-HEADER format Figure 5: COMMON-HEADER format
Ver: The 3-bit version field MUST be set to 1 when using BFCP over Ver: The 3-bit version field MUST be set to 1 when using BFCP over
reliable transport, i.e. as in [16]. The 3-bit version field MUST be reliable transport, i.e. as in [16]. The 3-bit version field MUST be
set to 2 when using BFCP over unreliable transport, with the set to 2 when using BFCP over unreliable transport, with the
extensions specified in this document. If a Floor Control Server extensions specified in this document. If a Floor Control Server
receives a message with an unsupported version field value, the receives a message with an unsupported version field value, the
receiving server MAY send an Error message with parameter value 12 receiving server SHOULD send an Error message with parameter value 12
(Unsupported Version) to indicate this. (Unsupported Version) to indicate this.
R: The Transaction Responder (R) flag-bit has relevance only for use R: The Transaction Responder (R) flag-bit has relevance only for use
of BFCP over unreliable transport. When cleared, it indicates that of BFCP over unreliable transport. When cleared, it indicates that
this message is a request initiating a new transaction, and the this message is a request initiating a new transaction, and the
Transaction ID that follows has been generated for this transaction. Transaction ID that follows has been generated for this transaction.
When set, it indicates that this message is a response to a previous When set, it indicates that this message is a response to a previous
request, and the Transaction ID that follows is the one associated request, and the Transaction ID that follows is the one associated
with that request. When BFCP is used over reliable transports, the with that request. When BFCP is used over reliable transports, the
flag has no significance and SHOULD be cleared by the sender and MUST flag has no significance and SHOULD be cleared by the sender and MUST
skipping to change at page 18, line 36 skipping to change at page 18, line 36
| | | P <- S ; Ch <- S | | | | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+ +-------+-----------------------+--------------------+
S: Floor Control Server / P: Floor Participant / Ch: Floor Chair S: Floor Control Server / P: Floor Participant / Ch: Floor Chair
Table 1: BFCP primitives Table 1: BFCP primitives
Payload Length: This 16-bit field contains the length of the message Payload Length: This 16-bit field contains the length of the message
in 4-octet units, excluding the common header. If a Floor Control in 4-octet units, excluding the common header. If a Floor Control
Server receives a message with an incorrect payload length field Server receives a message with an incorrect payload length field
value, the receiving server MAY send an Error message with parameter value, the receiving server SHOULD send an Error message with
value 13 (Incorrect Message Length) to indicate this. parameter value 13 (Incorrect Message Length) to indicate this.
Conference ID: This 32-bit unsigned integer field identifies the Conference ID: This 32-bit unsigned integer field identifies the
conference the message belongs to. conference the message belongs to.
Transaction ID: This field contains a 16-bit value that allows users Transaction ID: This field contains a 16-bit value that allows users
to match a given message with its response (see Section 8). to match a given message with its response (see Section 8).
User ID: This field contains a 16-bit unsigned integer that uniquely User ID: This field contains a 16-bit unsigned integer that uniquely
identifies a participant within a conference. identifies a participant within a conference.
skipping to change at page 20, line 32 skipping to change at page 20, line 32
| 15 | FLOOR-REQUEST-INFORMATION | Grouped | | 15 | FLOOR-REQUEST-INFORMATION | Grouped |
| 16 | REQUESTED-BY-INFORMATION | Grouped | | 16 | REQUESTED-BY-INFORMATION | Grouped |
| 17 | FLOOR-REQUEST-STATUS | Grouped | | 17 | FLOOR-REQUEST-STATUS | Grouped |
| 18 | OVERALL-REQUEST-STATUS | Grouped | | 18 | OVERALL-REQUEST-STATUS | Grouped |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
Table 2: BFCP attributes Table 2: BFCP attributes
M: The 'M' bit, known as the Mandatory bit, indicates whether support M: The 'M' bit, known as the Mandatory bit, indicates whether support
of the attribute is required. If a Floor Control Server receives an of the attribute is required. If a Floor Control Server receives an
unrecognized attribute with the 'M' bit set the server MAY send an unrecognized attribute with the 'M' bit set the server SHOULD send an
Error message with parameter value 4 (Unknown Mandatory Attribute) to Error message with parameter value 4 (Unknown Mandatory Attribute) to
indicate this. The 'M' bit is significant for extension attributes indicate this. The 'M' bit is significant for extension attributes
defined in other documents only. All attributes specified in this defined in other documents only. All attributes specified in this
document MUST be understood by the receiver so that the setting of document MUST be understood by the receiver so that the setting of
the 'M' bit is irrelevant for these. In all other cases, the the 'M' bit is irrelevant for these. In all other cases, the
unrecognized attribute is ignored but the message is processed. unrecognized attribute is ignored but the message is processed.
Length: This 8-bit field contains the length of the attribute in Length: This 8-bit field contains the length of the attribute in
octets, excluding any padding defined for specific attributes. The octets, excluding any padding defined for specific attributes. The
length of attributes that are not grouped includes the Type, 'M' bit, length of attributes that are not grouped includes the Type, 'M' bit,
skipping to change at page 24, line 47 skipping to change at page 24, line 47
| 9 | Use TLS | | 9 | Use TLS |
| 10 | Unable to Parse Message | | 10 | Unable to Parse Message |
| 11 | Use DTLS | | 11 | Use DTLS |
| 12 | Unsupported Version | | 12 | Unsupported Version |
| 13 | Incorrect Message Length | | 13 | Incorrect Message Length |
| 14 | Generic Error | | 14 | Generic Error |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Table 5: Error Code meaning Table 5: Error Code meaning
Note: The Generic Error error code is intended being used by a Note: The Generic Error error code is intended to be used by a
BFCP entity when an error occurs and the other specific error BFCP entity when an error occurs and the other specific error
codes do not apply. codes do not apply.
Error Specific Details: Present only for certain Error Codes. In Error Specific Details: Present only for certain Error Codes. In
this document, only for Error Code 4 (Unknown Mandatory Attribute). this document, only for Error Code 4 (Unknown Mandatory Attribute).
See Section 5.2.6.1 for its definition. See Section 5.2.6.1 for its definition.
Padding: One, two, or three octets of padding added so that the Padding: One, two, or three octets of padding added so that the
contents of the ERROR-CODE attribute is 32-bit aligned. If the contents of the ERROR-CODE attribute is 32-bit aligned. If the
skipping to change at page 38, line 7 skipping to change at page 38, line 7
Error = (COMMON-HEADER) Error = (COMMON-HEADER)
(ERROR-CODE) (ERROR-CODE)
[ERROR-INFO] [ERROR-INFO]
*(EXTENSION-ATTRIBUTE) *(EXTENSION-ATTRIBUTE)
Figure 43: Error format Figure 43: Error format
5.3.14. FloorRequestStatusAck 5.3.14. FloorRequestStatusAck
Floor participants and chairs acknowledge the receipt of a subsequent When communicating over unreliable transport, floor participants and
FloorRequestStatus message from the floor control server when chairs acknowledge the receipt of a subsequent FloorRequestStatus
communicating over unreliable transport. The following is the format message from the floor control server by sending an
of the FloorRequestStatusAck message: FloorRequestStatusAck. The following is the format of the
FloorRequestStatusAck message:
FloorRequestStatusAck = (COMMON-HEADER) FloorRequestStatusAck = (COMMON-HEADER)
*(EXTENSION-ATTRIBUTE) *(EXTENSION-ATTRIBUTE)
Figure 44: FloorRequestStatusAck format Figure 44: FloorRequestStatusAck format
5.3.15. FloorStatusAck 5.3.15. FloorStatusAck
Floor participants and chairs acknowledge the receipt of a subsequent When communicating over unreliable transport, floor participants and
FloorStatus message from the floor control server when communicating chairs acknowledge the receipt of a subsequent FloorStatus message
over unreliable transport. The following is the format of the from the floor control server by sending an FloorStatusAck. The
FloorStatusAck message: following is the format of the FloorStatusAck message:
FloorStatusAck = (COMMON-HEADER) FloorStatusAck = (COMMON-HEADER)
*(EXTENSION-ATTRIBUTE) *(EXTENSION-ATTRIBUTE)
Figure 45: FloorStatusAck format Figure 45: FloorStatusAck format
5.3.16. Goodbye 5.3.16. Goodbye
BFCP entities communicating over an unreliable transport that wish to BFCP entities communicating over an unreliable transport that wish to
dissociate themselves from their remote participant do so through the dissociate themselves from their remote participant do so through the
skipping to change at page 39, line 14 skipping to change at page 39, line 14
GoodbyeAck = (COMMON-HEADER) GoodbyeAck = (COMMON-HEADER)
*(EXTENSION-ATTRIBUTE) *(EXTENSION-ATTRIBUTE)
Figure 47: GoodbyeAck format Figure 47: GoodbyeAck format
6. Transport 6. Transport
The transport over which BFCP entities exchange messages depends on The transport over which BFCP entities exchange messages depends on
how clients obtain information to contact the floor control server how clients obtain information to contact the floor control server
(e.g. using an SDP offer/answer exchange [7]). Two transports are (e.g., using an SDP offer/answer exchange [7]). Two transports are
supported: TCP, appropriate where entities can be sure that their supported: TCP, appropriate where entities can be sure that their
connectivity is not impeded by NAT devices, media relays or connectivity is not impeded by NAT devices, media relays or
firewalls; and UDP for those deployments where TCP may not be firewalls; and UDP for those deployments where TCP may not be
applicable or appropriate. applicable or appropriate.
6.1. Reliable Transport 6.1. Reliable Transport
BFCP entities may elect to exchange BFCP messages using TCP BFCP entities may elect to exchange BFCP messages using TCP
connections. TCP provides an in-order reliable delivery of a stream connections. TCP provides an in-order reliable delivery of a stream
of bytes. Consequently, message framing is implemented in the of bytes. Consequently, message framing is implemented in the
application layer. BFCP implements application-layer framing using application layer. BFCP implements application-layer framing using
TLV-encoded attributes. TLV-encoded attributes.
A client MUST NOT use more than one TCP connection to communicate A client MUST NOT use more than one TCP connection to communicate
with a given floor control server within a conference. Nevertheless, with a given floor control server within a conference. Nevertheless,
if the same physical box handles different clients (e.g. a floor if the same physical box handles different clients (e.g., a floor
chair and a floor participant), which are identified by different chair and a floor participant), which are identified by different
User IDs, a separate connection per client is allowed. User IDs, a separate connection per client is allowed.
If a BFCP entity (a client or a floor control server) receives data 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 that cannot be parsed, the entity MUST close the TCP connection, and
the connection SHOULD be reestablished. Similarly, if a TCP the connection SHOULD be reestablished. Similarly, if a TCP
connection cannot deliver a BFCP message and times out, the TCP connection cannot deliver a BFCP message and times out, the TCP
connection SHOULD be reestablished. connection SHOULD be reestablished.
The way connection reestablishment is handled depends on how the The way connection reestablishment is handled depends on how the
skipping to change at page 40, line 18 skipping to change at page 40, line 18
to end its BFCP connection with a client (e.g., the Focus of the 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 conference informs the floor control server that the client has been
kicked out from the conference), the floor control server closes kicked out from the conference), the floor control server closes
(i.e., a graceful close) the TCP connection towards the client. (i.e., a graceful close) the TCP connection towards the client.
6.2. Unreliable Transport 6.2. Unreliable Transport
BFCP entities may elect to exchange BFCP messages using UDP BFCP entities may elect to exchange BFCP messages using UDP
datagrams. UDP is an unreliable transport where neither delivery nor datagrams. UDP is an unreliable transport where neither delivery nor
ordering is assured. Each BFCP UDP datagram MUST contain exactly one ordering is assured. Each BFCP UDP datagram MUST contain exactly one
BFCP message. To avoid BFCP messages being fragmented at the IP BFCP message or message fragment. To avoid BFCP messages being
layer, in the event the size of a BFCP message exceeds the MTU size, fragmented at the IP layer, in the event the size of a BFCP message
the fragmentation will be handled by the BFCP protocol. Only exceeds the MTU size, the fragmentation will be handled by the BFCP
allowing exactly one BFCP message or message segment per UDP protocol. Considerations related to fragmentation are covered in
datagram. Considerations related to fragmentation are covered in Section 6.2.3. The message format for exchange of BFCP in UDP
Section 6.3. The message format for exchange of BFCP in UDP
datagrams is the same as for a TCP stream above. datagrams is the same as for a TCP stream above.
Clients MUST announce their presence to the floor control server by Clients MUST announce their presence to the floor control server by
transmission of a Hello message. This Hello message MUST be transmission of a Hello message. This Hello message MUST be
responded to with a HelloAck message and only upon receipt of responded to with a HelloAck message and only upon receipt of
HelloAck can the client consider the floor control service as present HelloAck can the client consider the floor control service as present
and available. and available.
As described in Section 8, each request sent by a floor participant As described in Section 8, each request sent by a floor participant
or chair shall form a client transaction that expects an or chair shall form a client transaction that expects an
acknowledgement message back from the floor control server within a acknowledgement message back from the floor control server within a
retransmission window. Concordantly, messages sent by the floor retransmission window. Concordantly, messages sent by the floor
control server that are not transaction-completing (e.g. FloorStatus control server that are not transaction-completing (e.g., FloorStatus
announcements as part of a FloorQuery subscription) are server- announcements as part of a FloorQuery subscription) are server-
initiated transactions that require acknowledgement messages from the initiated transactions that require acknowledgement messages from the
floor participant and chair entities to which they were sent. floor participant and chair entities to which they were sent.
If a Floor Control Server receives data that cannot be parsed, the If a Floor Control Server receives data that cannot be parsed, the
receiving server MAY send an Error message with parameter value 10 receiving server SHOULD send an Error message with parameter value 10
(Unable to parse message) indicating receipt of a malformed message. (Unable to parse message) indicating receipt of a malformed message.
If the message can be parsed to the extent that it is able to discern If the message can be parsed to the extent that it is able to discern
that it was a response to an outstanding request transaction, the that it was a response to an outstanding request transaction, the
client MAY discard the message as the client will retransmit the client MAY discard the message as the client will retransmit the
message when the retransmit timer T1 specified in Section 8.3.1 message when the retransmit timer T1 specified in Section 8.3.1
fires. fires.
Transaction ID values are non-sequential and entities are at liberty Transaction ID values are non-sequential and entities are at liberty
to select values at random. Entities MUST only have at most one to select values at random. Entities MUST only have at most one
outstanding request transaction at any one time. Implicit outstanding request transaction at any one time. Implicit
subscriptions occur for a client-initiated request transaction whose subscriptions occur for a client-initiated request transaction whose
acknowledgement is implied by the first server-initiated response for acknowledgement is implied by the first server-initiated response for
that transaction, followed by zero of more subsequent server- that transaction, followed by zero of more subsequent server-
initiated messages corresponding to the same transaction. An example initiated messages corresponding to the same transaction. An example
is a FloorRequest message for which there are potentially multiple is a FloorRequest message for which there are potentially multiple
responses from the floor control server as it processes intermediate responses from the floor control server as it processes intermediate
states until a terminal state (e.g. Granted or Denied) is attained. states until a terminal state (e.g., Granted or Denied) is attained.
The subsequent changes in state for the request are new transactions The subsequent changes in state for the request are new transactions
whose Transaction ID is determined by the floor control server and whose Transaction ID is determined by the floor control server and
whose receipt by the client participant shall be acknowledged with a whose receipt by the client participant shall be acknowledged with a
FloorRequestStatusAck message. FloorRequestStatusAck message.
By restricting entities to having at most one pending transaction By restricting entities to having at most one pending transaction
open in a BFCP connection, both the out-of-order receipt of messages open in a BFCP connection, both the out-of-order receipt of messages
as well as the possibility for congestion are mitigated. Additional as well as the possibility for congestion are mitigated. Additional
details regarding congestion control are provided in Section 6.2.1. details regarding congestion control are provided in Section 6.2.1.
A server-initiated request (e.g. a FloorStatus with an update from A server-initiated request (e.g., a FloorStatus with an update from
the floor control server) received by a participant before the the floor control server) received by a participant before the
initial FloorRequestStatus message that closes the client-initiated initial FloorRequestStatus message that closes the client-initiated
transaction that was instigated by the FloorRequest MUST be treated transaction that was instigated by the FloorRequest MUST be treated
as superseding the information conveyed in any delinquent response. as superseding the information conveyed in any delinquent response.
As the floor control server cannot send a second update to the As the floor control server cannot send a second update to the
implicit floor status subscription until the first is acknowledged, implicit floor status subscription until the first is acknowledged,
ordinality is maintained. ordinality is maintained.
If a client wishes to end its BFCP association with a floor control If a client wishes to end its BFCP association with a floor control
server, it is RECOMMENDED that the client send a Goodbye message to server, it is RECOMMENDED that the client send a Goodbye message to
dissociate itself from any allocated resources. If a floor control dissociate itself from any allocated resources. If a floor control
server wishes to end its BFCP association with a client (e.g. the server wishes to end its BFCP association with a client (e.g., the
Focus of the conference informs the floor control server that the Focus of the conference informs the floor control server that the
client has been kicked out from the conference), it is RECOMMENDED client has been kicked out from the conference), it is RECOMMENDED
that the floor control server send a Goodbye message towards the that the floor control server send a Goodbye message towards the
client. client.
6.2.1. Congestion Control 6.2.1. Congestion Control
BFCP may be characterized to generate "low data-volume" traffic, per BFCP may be characterized to generate "low data-volume" traffic, per
the classification in [18]. Nevertheless is it necessary to ensure the classification in [18]. Nevertheless is it necessary to ensure
suitable and necessary congestion control mechanisms are used for suitable and necessary congestion control mechanisms are used for
BFCP over UDP. As described in previous paragraph, within the same BFCP over UDP. As described in previous paragraph, within the same
BFCP connection, every entity - client or server - is only allowed to BFCP connection, every entity - client or server - is only allowed to
send one request at a time, and await the acknowledging response. 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 This way at most one datagram is sent per RTT given the message is
not lost during transmission. In case the message is lost, the not lost during transmission. In case the message is lost, the
request retransmission timer T1 specified in Section 8.3.1 will fire request retransmission timer T1 specified in Section 8.3.1 will fire
and the message is retransmitted up to three times, in addition to and the message is retransmitted up to three times, in addition to
the original transmission of the message. The default initial the original transmission of the message. The default initial
interval is set to 500ms and the interval is doubled after each interval is set to 500ms and the interval is doubled after each
retransmission attempt, this is identical to the specification of the retransmission attempt. This is identical to the specification of
T1 timer in SIP as described in Section 17.1.1.2 of [15]. the T1 timer in SIP as described in Section 17.1.1.2 of [15].
6.2.2. ICMP Error Handling 6.2.2. ICMP Error Handling
If a BFCP entity receives an ICMP port unreachable message mid- If a BFCP entity receives an ICMP port unreachable message mid-
conversation, the entity SHOULD treat the conversation as closed conversation, the entity SHOULD treat the conversation as closed
(e.g. an implicit Goodbye message from the peer). The entity MAY (e.g., an implicit Goodbye message from the peer). The entity MAY
attempt to re-establish the conversation afresh. The new connection attempt to re-establish the conversation afresh. The new connection
will appear as a wholly new floor participant, chair or floor control will appear as a wholly new floor participant, chair or floor control
server with all state previously held about that participant lost. server with all state previously held about that participant lost.
Note: This is because the peer entities cannot rely on IP and port Note: This is because the peer entities cannot rely on IP and port
tuple to uniquely identify the participant, nor would extending Hello tuple to uniquely identify the participant, nor would extending Hello
to include an attribute that advertised what the entity previously to include an attribute that advertised what the entity previously
was assigned as a User ID be acceptable due to session hijacking. was assigned as a User ID be acceptable due to session hijacking.
In deployments where NAT appliances, firewalls or other such devices In deployments where NAT appliances, firewalls or other such devices
are present and affecting port reachability for each entity, one are present and affecting port reachability for each entity, one
possibility is to utilize the peer connectivity checks, relay use and possibility is to utilize the peer connectivity checks, relay use and
NAT pinhole maintenance mechanisms defined in ICE [14]. NAT pinhole maintenance mechanisms defined in ICE [14].
6.3. Large Message Considerations 6.2.3. Fragmentation Handling
Large messages become a concern when using BFCP if the overall size
of a single BFCP message exceeds that representable within the 16-bit
Payload Length field of the COMMON-HEADER. When using UDP, there is
the added concern that a single BFCP message can be fragmented at the
IP layer if its overall size exceeds the MTU threshold of the
network.
6.3.1. Fragmentation Handling The size of a BFCP message is limited by the 16-bit Payload Length
field of the COMMON-HEADER. When using UDP, a single BFCP message
may be fragmented at the IP layer if its overall size exceeds the MTU
threshold of the network.
When transmitting a BFCP message with size greater than the MTU, the When transmitting a BFCP message with size greater than the MTU, the
sender should fragment the message into a series of N contiguous data sender should fragment the message into a series of N contiguous data
ranges. The sender should then create N BFCP fragment messages (one ranges. The sender should then create N BFCP fragment messages (one
for each data range) with the same Transaction ID. The size of each for each data range) with the same Transaction ID. The size of each
of these N messages MUST be smaller than the MTU. The F flag in the of these N messages MUST be smaller than the MTU. The F flag in the
COMMON-HEADER is set to indicate fragmentation of the BFCP message. COMMON-HEADER is set to indicate fragmentation of the BFCP message.
For each of these fragments the Fragment Offset and Fragment Length For each of these fragments the Fragment Offset and Fragment Length
fields are included in the COMMON-HEADER. The Fragment Offset field fields are included in the COMMON-HEADER. The Fragment Offset field
skipping to change at page 43, line 17 skipping to change at page 43, line 12
If a fragment of a BFCP message is lost, the sender will not receive If a fragment of a BFCP message is lost, the sender will not receive
an ACK for the message. Therefore the sender will retransmit the an ACK for the message. Therefore the sender will retransmit the
message with same transaction ID as specified in Section 8.3. If the message with same transaction ID as specified in Section 8.3. If the
ACK sent by the receiver is lost, then the entire message will be ACK sent by the receiver is lost, then the entire message will be
resent by the sender. The receiver MUST then retransmit the ACK. resent by the sender. The receiver MUST then retransmit the ACK.
The receiver can discard an incomplete buffer utilizing the Response The receiver can discard an incomplete buffer utilizing the Response
Retransmission Timer, starting the timer after the receipt of the Retransmission Timer, starting the timer after the receipt of the
first fragment. first fragment.
6.3.2. NAT Traversal 6.2.4. NAT Traversal
One of the key benefits when using UDP for BFCP communication is the One of the key benefits when using UDP for BFCP communication is the
ability to leverage the existing NAT traversal infrastructure and ability to leverage the existing NAT traversal infrastructure and
strategies deployed to facilitate transport of the media associated strategies deployed to facilitate transport of the media associated
with the video conferencing sessions. Depending on the given with the video conferencing sessions. Depending on the given
deployment, this infrastructure typically includes some subset of ICE deployment, this infrastructure typically includes some subset of ICE
[14]. [14].
In order to facilitate the initial establishment of NAT bindings, and In order to facilitate the initial establishment of NAT bindings, and
to maintain those bindings once established, BFCP over UDP entities to maintain those bindings once established, BFCP over UDP entities
skipping to change at page 45, line 32 skipping to change at page 45, line 28
8.3.1. Request Retransmission Timer, T1 8.3.1. Request Retransmission Timer, T1
T1 is a timer that schedules retransmission of a request until an T1 is a timer that schedules retransmission of a request until an
appropriate response is received or until the maximum number of appropriate response is received or until the maximum number of
retransmissions have occurred. The timer doubles on each re- retransmissions have occurred. The timer doubles on each re-
transmit, failing after three unacknowledged retransmission attempts. transmit, failing after three unacknowledged retransmission attempts.
If a valid response is not received for a client- or server-initiated If a valid response is not received for a client- or server-initiated
transaction, the implementation MUST consider the BFCP association as transaction, the implementation MUST consider the BFCP association as
failed. Implementations SHOULD follow the reestablishment procedure failed. Implementations SHOULD follow the reestablishment procedure
described in section 6 (e.g. initiate a new offer/answer [11] described in section 6 (e.g., initiate a new offer/answer [11]
exchange). Alternatively, they MAY continue without BFCP and exchange). Alternatively, they MAY continue without BFCP and
therefore not be participant in any floor control actions. therefore not be participant in any floor control actions.
8.3.2. Response Retransmission Timer, T2 8.3.2. Response Retransmission Timer, T2
T2 is a timer that, when fires, signals that the BFCP entity can T2 is a timer that, when fires, signals that the BFCP entity can
release knowledge of the transaction against which it is running. It release knowledge of the transaction against which it is running. It
is started upon the first transmission of the response to a request 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 and is the only mechanism by which that response is released by the
BFCP entity. Any subsequent retransmissions of the same request can BFCP entity. Any subsequent retransmissions of the same request can
skipping to change at page 74, line 33 skipping to change at page 74, line 33
| 14 | Generic Error | [RFC XXXX] | | 14 | Generic Error | [RFC XXXX] |
+-------+--------------------------------------+------------+ +-------+--------------------------------------+------------+
Table 10: Initial Values of the Error Code subregistry Table 10: Initial Values of the Error Code subregistry
16. Changes from RFC 4582 16. Changes from RFC 4582
Following is the list of technical changes and other non-trivial Following is the list of technical changes and other non-trivial
fixes from [16]. fixes from [16].
16.1. Extensions for unreliable transport
Main purpose of this work was to revise the specification to support Main purpose of this work was to revise the specification to support
BFCP over unreliable transport, resulting in the following changes: BFCP over unreliable transport, resulting in the following changes:
Overview of Operation (Section 4): Overview of Operation (Section 4):
Expand the description of client-initiated and server-initiated Changed the description of client-initiated and server-
transactions. initiated transactions, referring to Section 8.
COMMON-HEADER Format (Section 5.1): COMMON-HEADER Format (Section 5.1):
Ver(sion) field, where the value 2 is used for the extensions Ver(sion) field, where the value 2 is used for the extensions
for unreliable transport. Added new R and F flag-bits for for unreliable transport. Added new R and F flag-bits for
unreliable transport. Res(erved) field is now 3 bit. New unreliable transport. Res(erved) field is now 3 bit. New
optional Fragment Offset and Fragment Length fields. optional Fragment Offset and Fragment Length fields.
New primitives (Section 5.1): New primitives (Section 5.1):
Added five new primitives: FloorRequestStatusAck, Added four new primitives: FloorRequestStatusAck,
FloorStatusAck, Goodbye, and GoodbyeAck. FloorStatusAck, Goodbye, and GoodbyeAck.
New error codes (Section 5.2.6): New error codes (Section 5.2.6):
Added three new error codes: "Unable to Parse Message", "Use Added three new error codes: "Unable to Parse Message", "Use
DTLS" and "Unsupported Version". DTLS" and "Unsupported Version". Note that two additional
error codes were added, see Section 16.2.
ABNF for new primitives (Section 5.3): ABNF for new primitives (Section 5.3):
New subsections with normative ABNF for the new primitives. New subsections with normative ABNF for the new primitives.
Transport split in two (Section 6): Transport split in two (Section 6):
Section 6 specifying the transport was split in two Section 6 specifying the transport was split in two
subsections; Section 6.1 for reliable transport and Section 6.2 subsections; Section 6.1 for reliable transport and Section 6.2
for unreliable transport. Where the specification for for unreliable transport. Where the specification for
unreliable transport amongst other issues deals with unreliable transport amongst other issues deals with
reliability, congestion control, fragmentation and ICMP. reliability, congestion control, fragmentation and ICMP.
skipping to change at page 75, line 46 skipping to change at page 75, line 47
Section 15.4 respectively. Section 15.4 respectively.
Examples over unreliable transport (Appendix A): Examples over unreliable transport (Appendix A):
Added sample interactions over unreliable transport for the Added sample interactions over unreliable transport for the
scenarios in Figure 2 and Figure 3 scenarios in Figure 2 and Figure 3
Motivation for unreliable transport (Appendix B): Motivation for unreliable transport (Appendix B):
Introduction to and motivation for extending BFCP to support Introduction to and motivation for extending BFCP to support
unreliable transport. unreliable transport.
16.2. Other changes
The clarification and bug fixes: The clarification and bug fixes:
ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>, ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>,
Figure 28, Figure 30, and the ABNF figures in Section 5.3): Figure 28, Figure 30, and the ABNF figures in Section 5.3):
Although formally correct in [16], the notation has changed in a Although formally correct in [16], the notation has changed in a
number of Figures to an equivalent form for clarity, e.g. 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 s/*1(FLOOR-ID)/[FLOOR-ID]/ in Figure 38 and s/*[XXX]/*(XXX)/ in
the other figures. the other figures.
Typo (Section 12.4.2): Typo (Section 12.4.2):
Change from SUPPORTED-PRIMITIVES to SUPPORTED-PRIMITVIES in the Change from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the
second paragraph. second paragraph.
Corrected attribute type (Section 13.1.1): Corrected attribute type (Section 13.1.1):
Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in
the eighth paragraph, since the note below describes priority and the eighth paragraph, since the note below describes priority and
that the last paragraph deals with PARTICIPANT-PROVIDED-INFO. that the last paragraph deals with PARTICIPANT-PROVIDED-INFO.
New error codes (Section 5.2.6): New error codes (Section 5.2.6):
Added two additional error codes: "Incorrect Message Length" and Added two additional error codes: "Incorrect Message Length" and
"Generic Error". "Generic Error".
skipping to change at page 77, line 11 skipping to change at page 77, line 17
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, August 2008. Protocol Version 1.2", RFC 5246, August 2008.
[5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
[7] Camarillo, G. and T. Kristensen, Ed., "Session Description [7] Camarillo, G. and T. Kristensen, "Session Description Protocol
Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) (SDP) Format for Binary Floor Control Protocol (BFCP) Streams",
Streams", draft-ietf-bfcpbis-rfc4583bis-02 (work in progress), draft-ietf-bfcpbis-rfc4583bis-03 (work in progress),
July 2012. October 2012.
[8] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for [8] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for
Establishing a Secure Real-time Transport Protocol (SRTP) Establishing a Secure Real-time Transport Protocol (SRTP)
Security Context Using Datagram Transport Layer Security Security Context Using Datagram Transport Layer Security
(DTLS)", RFC 5763, May 2010. (DTLS)", RFC 5763, May 2010.
[9] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [9] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007. BCP 131, RFC 4961, July 2007.
[10] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session [10] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session
skipping to change at page 78, line 25 skipping to change at page 78, line 31
RFC 6544, March 2012. RFC 6544, March 2012.
[22] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling [22] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling
(GUT)", draft-manner-tsvwg-gut-02 (work in progress), (GUT)", draft-manner-tsvwg-gut-02 (work in progress),
July 2010. July 2010.
[23] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of [23] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of
Middlebox Interactions for Signaling Protocol Communication Middlebox Interactions for Signaling Protocol Communication
along the Media Path", along the Media Path",
draft-ietf-mmusic-media-path-middleboxes-04 (work in progress), draft-ietf-mmusic-media-path-middleboxes-04 (work in progress),
January 2012. July 2012.
[24] Guha, S. and P. Francis, "Characterization and Measurement of [24] Guha, S. and P. Francis, "Characterization and Measurement of
TCP Traversal through NATs and Firewalls", 2005, TCP Traversal through NATs and Firewalls", 2005,
<http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>. <http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>.
[25] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer [25] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer
Communication Across Network Address Translators", April 2005, Communication Across Network Address Translators", April 2005,
<http://www.brynosaurus.com/pub/net/p2pnat.pdf/>. <http://www.brynosaurus.com/pub/net/p2pnat.pdf/>.
Appendix A. Example Call Flows for BFCP over Unreliable Transport Appendix A. Example Call Flows for BFCP over Unreliable Transport
skipping to change at page 83, line 9 skipping to change at page 83, line 15
audio and video, and a BFCP connection for floor control. Existing audio and video, and a BFCP connection for floor control. Existing
deployments are most common in, but not limited to, enterprise deployments are most common in, but not limited to, enterprise
networks. In existing deployments, NAT/firewall traversal for the networks. In existing deployments, NAT/firewall traversal for the
RTP streams works using ICE and/or other methods, including those RTP streams works using ICE and/or other methods, including those
described in [23]. described in [23].
When enhancing an existing SIP based video conferencing deployment When enhancing an existing SIP based video conferencing deployment
with support for content sharing, the BFCP connection often poses a with support for content sharing, the BFCP connection often poses a
problem. The reasons for this fall into two general classes. First, problem. The reasons for this fall into two general classes. First,
there may be a strong preference for UDP based signaling in general. there may be a strong preference for UDP based signaling in general.
On high capacity endpoints (e.g. PSTN gateways or SIP/H.323 inter- On high capacity endpoints (e.g., PSTN gateways or SIP/H.323 inter-
working gateways), TCP can suffer from head of line blocking, and it working gateways), TCP can suffer from head of line blocking, and it
uses many kernel buffers. Network operators view UDP as a way to uses many kernel buffers. Network operators view UDP as a way to
avoid both of these. Second, establishment and traversal of the TCP avoid both of these. Second, establishment and traversal of the TCP
connection involving ephemeral ports, as is typically the case with connection involving ephemeral ports, as is typically the case with
BFCP over TCP, can be problematic, as described in Appendix A of BFCP over TCP, can be problematic, as described in Appendix A of
[21]. A broad study of NAT behavior and peer-to-peer TCP [21]. A broad study of NAT behavior and peer-to-peer TCP
establishment for a comprehensive set of TCP NAT traversal techniques establishment for a comprehensive set of TCP NAT traversal techniques
over a wide range of commercial NAT products concluded it was not over a wide range of commercial NAT products concluded it was not
possible to establish a TCP connection in 11% of the cases [24]. The possible to establish a TCP connection in 11% of the cases [24]. The
results are worse when focusing on enterprise NATs. A study of hole results are worse when focusing on enterprise NATs. A study of hole
skipping to change at page 87, line 14 skipping to change at page 87, line 22
Joerg Ott Joerg Ott
Aalto University Aalto University
Otakaari 5 A Otakaari 5 A
Espoo, FIN 02150 Espoo, FIN 02150
Finland Finland
Email: jo@comnet.tkk.fi Email: jo@comnet.tkk.fi
Charles Eckel Charles Eckel
Cisco Cisco
170 West Tasman Drive 707 Tasman Drive
San Jose, CA 95134 California, CA 95035
United States United States
Email: eckelcu@cisco.com Email: eckelcu@cisco.com
 End of changes. 45 change blocks. 
88 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/