draft-ietf-bfcpbis-rfc4582bis-06.txt   draft-ietf-bfcpbis-rfc4582bis-07.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: April 15, 2013 T. Kristensen Expires: June 22, 2013 T. Kristensen
Cisco Cisco
J. Ott J. Ott
Aalto University Aalto University
C. Eckel C. Eckel
Cisco Cisco
October 12, 2012 December 19, 2012
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-bfcpbis-rfc4582bis-06 draft-ietf-bfcpbis-rfc4582bis-07
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).
BFCP is used between floor participants and floor control servers, BFCP is used between floor participants and floor control servers,
and between floor chairs (i.e., moderators) and floor control and between floor chairs (i.e., moderators) and floor control
servers. servers.
This document obsoletes RFC 4582. Changes from RFC 4582 are This document obsoletes RFC 4582. Changes from RFC 4582 are
summarized in section 16. summarized in Section 16.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 15, 2013. This Internet-Draft will expire on June 22, 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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
4.1. Floor Participant to Floor Control Server Interface . . . 10 4.1. Floor Participant to Floor Control Server Interface . . . 11
4.2. Floor Chair to Floor Control Server Interface . . . . . . 15 4.2. Floor Chair to Floor Control Server Interface . . . . . . 15
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. COMMON-HEADER Format . . . . . . . . . . . . . . . . . . . 16 5.1. COMMON-HEADER Format . . . . . . . . . . . . . . . . . . . 16
5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . . 19 5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . . 19
5.2.1. BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 21 5.2.1. BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 21
5.2.2. FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.2. FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.3. FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 21 5.2.3. FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 22
5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 23 5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 23
5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 23 5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 24
5.2.6.1. Error-Specific Details for Error Code 4 . . . . . 25 5.2.6.1. Error-Specific Details for Error Code 4 . . . . . 25
5.2.7. ERROR-INFO . . . . . . . . . . . . . . . . . . . . . . 25 5.2.7. ERROR-INFO . . . . . . . . . . . . . . . . . . . . . . 25
5.2.8. PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . . 26 5.2.8. PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . . 26
5.2.9. STATUS-INFO . . . . . . . . . . . . . . . . . . . . . 27 5.2.9. STATUS-INFO . . . . . . . . . . . . . . . . . . . . . 27
5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . . 27 5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . . 27
5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . . 28 5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . . 28
5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 29 5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 29
5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . . 29 5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 30 5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 30
5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 31 5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 31
skipping to change at page 3, line 27 skipping to change at page 3, line 27
5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 37
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 . . . . . . . . . . . . . . . . . . 42
6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42
6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . . 42 6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . . 42
6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 43 6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 44
7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 43 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 44
8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 44 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 45
8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 44 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 46
8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 44 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 46
8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 45 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 46
8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 45 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 47
8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 45 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 47
9. Authentication and Authorization . . . . . . . . . . . . . . . 46 9. Authentication and Authorization . . . . . . . . . . . . . . . 47
9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 46 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 48
10. Floor Participant Operations . . . . . . . . . . . . . . . . . 47 10. Floor Participant Operations . . . . . . . . . . . . . . . . . 48
10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 47 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 49
10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 47 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 49
10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 48 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 50
10.1.3. Reception of a Subsequent FloorRequestStatus 10.1.3. Reception of a Subsequent FloorRequestStatus
Message . . . . . . . . . . . . . . . . . . . . . . . 49 Message . . . . . . . . . . . . . . . . . . . . . . . 51
10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 50 10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 51
10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 50 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 51
10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 50 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 52
11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 51 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 52
11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 51 11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 52
11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 52 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 54
12. General Client Operations . . . . . . . . . . . . . . . . . . 53 12. General Client Operations . . . . . . . . . . . . . . . . . . 54
12.1. Requesting Information about Floors . . . . . . . . . . . 53 12.1. Requesting Information about Floors . . . . . . . . . . . 54
12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 53 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 54
12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 53 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 55
12.1.3. Reception of a Subsequent FloorStatus Message . . . . 54 12.1.3. Reception of a Subsequent FloorStatus Message . . . . 56
12.2. Requesting Information about Floor Requests . . . . . . . 54 12.2. Requesting Information about Floor Requests . . . . . . . 56
12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 55 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 56
12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 55 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 56
12.3. Requesting Information about a User . . . . . . . . . . . 55 12.3. Requesting Information about a User . . . . . . . . . . . 57
12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 56 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 57
12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 56 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 58
12.4. Obtaining the Capabilities of a Floor Control Server . . . 57 12.4. Obtaining the Capabilities of a Floor Control Server . . . 58
12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 57 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 58
12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 57 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 58
13. Floor Control Server Operations . . . . . . . . . . . . . . . 57 13. Floor Control Server Operations . . . . . . . . . . . . . . . 59
13.1. Reception of a FloorRequest Message . . . . . . . . . . . 58 13.1. Reception of a FloorRequest Message . . . . . . . . . . . 59
13.1.1. Generating the First FloorRequestStatus Message . . . 58 13.1.1. Generating the First FloorRequestStatus Message . . . 60
13.1.2. Generation of Subsequent FloorRequestStatus 13.1.2. Generation of Subsequent FloorRequestStatus
Messages . . . . . . . . . . . . . . . . . . . . . . . 60 Messages . . . . . . . . . . . . . . . . . . . . . . . 61
13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 61 13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 62
13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 62 13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 64
13.4. Reception of a FloorRelease Message . . . . . . . . . . . 64 13.4. Reception of a FloorRelease Message . . . . . . . . . . . 65
13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 65 13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 66
13.5.1. Generation of the First FloorStatus Message . . . . . 65 13.5.1. Generation of the First FloorStatus Message . . . . . 67
13.5.2. Generation of Subsequent FloorStatus Messages . . . . 67 13.5.2. Generation of Subsequent FloorStatus Messages . . . . 68
13.6. Reception of a ChairAction Message . . . . . . . . . . . . 67 13.6. Reception of a ChairAction Message . . . . . . . . . . . . 69
13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 68 13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 70
13.8. Error Message Generation . . . . . . . . . . . . . . . . . 69 13.8. Error Message Generation . . . . . . . . . . . . . . . . . 70
14. Security Considerations . . . . . . . . . . . . . . . . . . . 69 14. Security Considerations . . . . . . . . . . . . . . . . . . . 70
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 70 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 72
15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 71 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 73
15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 72 15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 73
15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 73 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 74
16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 74 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 75
16.1. Extensions for unreliable transport . . . . . . . . . . . 74 16.1. Extensions for an unreliable transport . . . . . . . . . . 75
16.2. Other changes . . . . . . . . . . . . . . . . . . . . . . 75 16.2. Other changes . . . . . . . . . . . . . . . . . . . . . . 77
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 77
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 77
18.1. Normative References . . . . . . . . . . . . . . . . . . . 76 18.1. Normative References . . . . . . . . . . . . . . . . . . . 77
18.2. Informational References . . . . . . . . . . . . . . . . . 77 18.2. Informational References . . . . . . . . . . . . . . . . . 78
Appendix A. Example Call Flows for BFCP over Unreliable Appendix A. Example Call Flows for BFCP over an unreliable
Transport . . . . . . . . . . . . . . . . . . . . . . 78 Transport . . . . . . . . . . . . . . . . . . . . . . 80
Appendix B. Motivation for Supporting Unreliable Transport . . . 82 Appendix B. Motivation for Supporting an Unreliable Transport . . 83
B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 82 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 84
B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 83 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 85
B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 84 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 85
B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 84 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 86
B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 84 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 86
B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 85 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 86
B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 85 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 87
B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 85 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 87
B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 86 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88
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.
The Requirements for Floor Control Protocol [12] list a set of The Requirements for Floor Control Protocol [11] list a set of
requirements that need to be met by floor control protocols. The requirements that need to be met by floor control protocols. The
Binary Floor Control Protocol (BFCP), which is specified in this Binary Floor Control Protocol (BFCP), which is specified in this
document, meets these requirements. document, meets these requirements.
In addition, BFCP has been designed so that it can be used in low- In addition, BFCP has been designed so that it can be used in low-
bandwidth environments. The binary encoding used by BFCP achieves a bandwidth environments. The binary encoding used by BFCP achieves a
small message size (when message signatures are not used) that keeps small message size (when message signatures are not used) that keeps
the time it takes to transmit delay-sensitive BFCP messages to a the time it takes to transmit delay-sensitive BFCP messages to a
minimum. Delay-sensitive BFCP messages include FloorRequest, minimum. Delay-sensitive BFCP messages include FloorRequest,
FloorRelease, FloorRequestStatus, and ChairAction. It is expected FloorRelease, FloorRequestStatus, and ChairAction. It is expected
skipping to change at page 7, line 42 skipping to change at page 7, line 42
floor chair are defined on a transaction-by-transaction basis. BFCP floor chair are defined on a transaction-by-transaction basis. BFCP
transactions are defined in Section 8. In floor-controlled transactions are defined in Section 8. In floor-controlled
conferences, a given floor participant is typically colocated with a conferences, a given floor participant is typically colocated with a
media participant, but it does not need to be. Third-party floor media participant, but it does not need to be. Third-party floor
requests consist of having a floor participant request a floor for a requests consist of having a floor participant request a floor for a
media participant when they are not colocated. media participant when they are not colocated.
Participant: An entity that acts as a floor participant, as a media Participant: An entity that acts as a floor participant, as a media
participant, or as both. participant, or as both.
BFCP Connection: A transport association between BFCP entities, used
to exchange BFCP messages.
3. Scope 3. Scope
As stated earlier, BFCP is a protocol to coordinate access to shared As stated earlier, BFCP is a protocol to coordinate access to shared
resources in a conference following the requirements defined in [12]. resources in a conference following the requirements defined in [11].
Floor control complements other functions defined in the XCON Floor control complements other functions defined in the XCON
conferencing framework [13]. The floor control protocol BFCP defined conferencing framework [12]. The floor control protocol BFCP defined
in this document only specifies a means to arbitrate access to in this document only specifies a means to arbitrate access to
floors. The rules and constraints for floor arbitration and the floors. The rules and constraints for floor arbitration and the
results of floor assignments are outside the scope of this document results of floor assignments are outside the scope of this document
and are defined by other protocols [13]. and are defined by other protocols [12].
Figure 1 shows the tasks that BFCP can perform. Figure 1 shows the tasks that BFCP can perform.
+---------+ +---------+
| Floor | | Floor |
| Chair | | Chair |
| | | |
+---------+ +---------+
^ | ^ |
| | | |
skipping to change at page 9, line 9 skipping to change at page 9, line 10
the scope of BFCP, some of these out-of-scope tasks relate to floor the scope of BFCP, some of these out-of-scope tasks relate to floor
control and are essential for creating floors and establishing BFCP control and are essential for creating floors and establishing BFCP
connections between different entities. In the following connections between different entities. In the following
subsections, we discuss some of these tasks and mechanisms to perform subsections, we discuss some of these tasks and mechanisms to perform
them. them.
3.1. Floor Creation 3.1. Floor Creation
The association of a given floor with a resource or a set of The association of a given floor with a resource or a set of
resources (e.g., media streams) is out of the scope of BFCP as resources (e.g., media streams) is out of the scope of BFCP as
described in [13]. Floor creation and termination are also outside described in [12]. Floor creation and termination are also outside
the scope of BFCP; these aspects are handled using the conference the scope of BFCP; these aspects are handled using the conference
control protocol for manipulating the conference object. control protocol for manipulating the conference object.
Consequently, the floor control server needs to stay up to date on Consequently, the floor control server needs to stay up to date on
changes to the conference object (e.g., when a new floor is created). changes to the conference object (e.g., when a new floor is created).
Conference control clients using CCMP [17] can specify such floor-
related settings by editing the floor-information section of the
to-be created conference object provided in the body of a CCMP
confRequest/create message issued to the conference control server.
3.2. Obtaining Information to Contact a Floor Control Server 3.2. Obtaining Information to Contact a Floor Control Server
A client needs a set of data in order to establish a BFCP connection A client needs a set of data in order to establish a BFCP connection
to a floor control server. These data include the transport address to a floor control server. These data include the transport address
of the server, the conference identifier, and a user identifier. of the server, the conference identifier, and a user identifier.
Clients can obtain this information in different ways. One is to use Clients can obtain this information in different ways. One is to use
an SDP offer/answer [11] exchange, which is described in [7]. Other an SDP offer/answer [10] exchange, which is described in [7]. How to
mechanisms are described in the XCON framework [13] (and other establish a connection to a BFCP floor control server outside the
context of an offer/answer exchange is described in [16]. Other
mechanisms are described in the XCON framework [12] (and other
related documents). related documents).
3.3. Obtaining Floor-Resource Associations 3.3. Obtaining Floor-Resource Associations
Floors are associated with resources. For example, a floor that Floors are associated with resources. For example, a floor that
controls who talks at a given time has a particular audio session as controls who talks at a given time has a particular audio session as
its associated resource. Associations between floors and resources its associated resource. Associations between floors and resources
are part of the conference object. are part of the conference object.
Floor participants and floor chairs need to know which resources are Floor participants and floor chairs need to know which resources are
associated with which floors. They can obtain this information by associated with which floors. They can obtain this information by
using different mechanisms, such as an SDP offer/answer [11] using different mechanisms, such as an SDP offer/answer [10]
exchange. How to use an SDP offer/answer exchange to obtain these exchange. How to use an SDP offer/answer exchange to obtain these
associations is described in [7]. associations is described in [7].
Note that floor participants perform SDP offer/answer exchanges Note that floor participants perform SDP offer/answer exchanges
with the conference focus of the conference. So, the conference with the conference focus of the conference. So, the conference
focus needs to obtain information about associations between focus needs to obtain information about associations between
floors and resources in order to be able to provide this floors and resources in order to be able to provide this
information to a floor participant in an SDP offer/answer information to a floor participant in an SDP offer/answer
exchange. exchange.
Other mechanisms for obtaining this information, including discussion Other mechanisms for obtaining this information, including discussion
of how the information is made available to a (SIP) Focus, are of how the information is made available to a (SIP) Focus, are
described in the XCON framework [13] (and other related documents). described in the XCON framework [12] (and other related documents).
According to the conferencing system policies, conference control
clients using CCMP [17] can modify the floor settings of a conference
by issuing CCMP confRequest/update messages providing the specific
updates to the <floor-information> section of the target conference
object. More information about CCMP and BFCP interaction can be
found in [18].
3.4. Privileges of Floor Control 3.4. Privileges of Floor Control
A participant whose floor request is granted has the right to use (in A participant whose floor request is granted has the right to use (in
a certain way) the resource or resources associated with the floor a certain way) the resource or resources associated with the floor
that was requested. For example, the participant may have the right that was requested. For example, the participant may have the right
to send media over a particular audio stream. to send media over a particular audio stream.
Nevertheless, holding a floor does not imply that others will not be Nevertheless, holding a floor does not imply that others will not be
able to use its associated resources at the same time, even if they able to use its associated resources at the same time, even if they
do not have the right to do so. Determination of which media do not have the right to do so. Determination of which media
participants can actually use the resources in the conference is participants can actually use the resources in the conference is
discussed in the XCON Framework [13]. discussed in the XCON Framework [12].
4. Overview of Operation 4. Overview of Operation
This section provides a non-normative description of BFCP operations. This section provides a non-normative description of BFCP operations.
Section 4.1 describes the interface between floor participants and Section 4.1 describes the interface between floor participants and
floor control servers, and Section 4.2 describes the interface floor control servers, and Section 4.2 describes the interface
between floor chairs and floor control servers. between floor chairs and floor control servers.
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 transactions in BFCP: client-initiated There are two types of transactions in BFCP: client-initiated
transactions and server-initiated transactions (notifications), transactions and server-initiated transactions. Section 8 describes
further details in Section 8. both types of transactions in detail.
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 11, line 33 skipping to change at page 11, line 44
Additionally, the first FloorRequestStatus message carries the Floor Additionally, the first FloorRequestStatus message carries the Floor
Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent
FloorRequestStatus messages related to the same floor request will FloorRequestStatus messages related to the same floor request will
carry the same Floor Request ID. This way, the floor participant can carry the same Floor Request ID. This way, the floor participant can
associate them with the appropriate floor request. associate them with the appropriate floor request.
Messages from the floor participant related to a particular floor Messages from the floor participant related to a particular floor
request also use the same Floor Request ID as the first request also use the same Floor Request ID as the first
FloorRequestStatus Message from the floor control server. FloorRequestStatus Message from the floor control server.
Figures 2 and 3 below show call flows for two sample BFCP Figures 2 and 3 below show examples of call flows where BFCP is used
interactions when used over reliable transport. Appendix A shows the over a reliable transport. Appendix A shows the same call flow
same sample interactions but over an unreliable transport. examples using an unreliable transport.
Figure 2 shows how a floor participant requests a floor, obtains it, Figure 2 shows how a floor participant requests a floor, obtains it,
and, at a later time, releases it. This figure illustrates the use, and, at a later time, releases it. This figure illustrates the use,
among other things, of the Transaction ID and the FLOOR-REQUEST-ID among other things, of the Transaction ID and the FLOOR-REQUEST-ID
attribute. attribute.
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorRequest | |(1) FloorRequest |
|Transaction ID: 123 | |Transaction ID: 123 |
skipping to change at page 16, line 48 skipping to change at page 16, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID | | Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID | | Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 a
reliable transport, i.e. as in [16]. The 3-bit version field MUST be reliable transport, i.e. as in [15]. 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 an 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 SHOULD 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 an unreliable transport. When cleared, it indicates
this message is a request initiating a new transaction, and the that 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 a reliable transport, 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
be ignored by the receiver. be ignored by the receiver.
F: The Fragmentation (F) flag-bit has relevance only for use of BFCP F: The Fragmentation (F) flag-bit has relevance only for use of BFCP
over unreliable transport. When cleared, the message is not over an unreliable transport. When cleared, the message is not
fragmented. When set, it indicates that the message is a fragment of fragmented. When set, it indicates that the message is a fragment of
a large fragmented BFCP message. (The optional fields Fragment a large fragmented BFCP message. (The optional fields Fragment
Offset and Fragment Length described below are present only if the F Offset and Fragment Length described below are present only if the F
flag is set). When BFCP is used over reliable transports, the flag flag is set). When BFCP is used over a reliable transport, the flag
has no significance and SHOULD be cleared by the sender and MUST be has no significance and SHOULD be cleared by the sender and MUST be
ignored by the receiver. ignored by the receiver.
Res: At this point, the 3 bits in the reserved field SHOULD be set to Res: At this point, the 3 bits in the reserved field SHOULD be set to
zero by the sender of the message and MUST be ignored by the zero by the sender of the message and MUST be ignored by the
receiver. receiver.
Primitive: This 8-bit field identifies the main purpose of the Primitive: This 8-bit field identifies the main purpose of the
message. The following primitive values are defined: message. The following primitive values are defined:
skipping to change at page 18, line 35 skipping to change at page 18, line 35
| 17 | GoodbyeAck | P -> S ; Ch -> S ; | | 17 | GoodbyeAck | P -> S ; Ch -> S ; |
| | | 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 SHOULD send an Error message with value, the receiving server SHOULD send an Error message with
parameter value 13 (Incorrect Message Length) to indicate this. parameter value 13 (Incorrect Message Length) to indicate this.
Note: BFCP is designed to a achieve small message size, as
explained in Section 1 and BFCP entities are REQUIRED to keep the
BFCP message size smaller than the size limited by the 16-bit
Payload Length field. To convey information not strictly related
to floor control, other protocols should be used such as the XCON
framework (cf. Section 3).
Conference ID: This 32-bit unsigned integer field identifies the Conference 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.
The identity used by a participant in BFCP, which is carried in The identity used by a participant in BFCP, which is carried in
skipping to change at page 36, line 34 skipping to change at page 36, line 34
FloorStatus = (COMMON-HEADER) FloorStatus = (COMMON-HEADER)
[FLOOR-ID] [FLOOR-ID]
*(FLOOR-REQUEST-INFORMATION) *(FLOOR-REQUEST-INFORMATION)
*(EXTENSION-ATTRIBUTE) *(EXTENSION-ATTRIBUTE)
Figure 38: FloorStatus format Figure 38: FloorStatus format
5.3.9. ChairAction 5.3.9. ChairAction
Floor chairs send instructions to floor control servers by sending Floor chairs send instructions to floor control servers by sending
ChairAction messages. The following is the format of the ChairAction them ChairAction messages. The following is the format of the
message: ChairAction message:
ChairAction = (COMMON-HEADER) ChairAction = (COMMON-HEADER)
(FLOOR-REQUEST-INFORMATION) (FLOOR-REQUEST-INFORMATION)
*(EXTENSION-ATTRIBUTE) *(EXTENSION-ATTRIBUTE)
Figure 39: ChairAction format Figure 39: ChairAction format
5.3.10. ChairActionAck 5.3.10. ChairActionAck
Floor control servers confirm that they have accepted a ChairAction Floor control servers confirm that they have accepted a ChairAction
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
When communicating over unreliable transport, floor participants and When communicating over an unreliable transport, floor participants
chairs acknowledge the receipt of a subsequent FloorRequestStatus and chairs acknowledge the receipt of a subsequent FloorRequestStatus
message from the floor control server by sending an message from the floor control server (cf. Section 13.1.2) by sending
FloorRequestStatusAck. The following is the format of the a FloorRequestStatusAck message. The following is the format of the
FloorRequestStatusAck message: 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
When communicating over unreliable transport, floor participants and When communicating over an unreliable transport, floor participants
chairs acknowledge the receipt of a subsequent FloorStatus message and chairs acknowledge the receipt of a subsequent FloorStatus
from the floor control server by sending an FloorStatusAck. The message from the floor control server (cf. Section 13.5.2) by sending
following is the format of the FloorStatusAck message: a FloorStatusAck message. The 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] or the procedure
supported: TCP, appropriate where entities can be sure that their specified in [16]). Two transports are supported: TCP, appropriate
connectivity is not impeded by NAT devices, media relays or where connectivity is not impeded by network elements such as NAT
firewalls; and UDP for those deployments where TCP may not be devices or media relays; and UDP for those deployments where TCP may
applicable or appropriate. not be 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 needs to be implemented in
application layer. BFCP implements application-layer framing using the application layer. BFCP implements application-layer framing
TLV-encoded attributes. using 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 or receives an
connection SHOULD be reestablished. ICMP port unreachable message mid-connection, the TCP connection
SHOULD be reestablished.
The way connection reestablishment is handled depends on how the The way connection reestablishment is handled depends on how the
client obtains information to contact the floor control server. Once client obtains information to contact the floor control server. Once
the TCP connection is reestablished, the client MAY resend those the TCP connection is reestablished, the client MAY resend those
messages for which it did not get a response from the floor control messages for which it did not get a response from the floor control
server. server.
If a floor control server detects that the TCP connection towards one If a floor control server detects that the TCP connection towards one
of the floor participants is lost, it is up to the local policy of of the floor participants is lost, it is up to the local policy of
the floor control server what to do with the pending floor requests the floor control server what to do with the pending floor requests
skipping to change at page 40, line 18 skipping to change at page 40, line 19
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 or message fragment. To avoid BFCP messages being BFCP message or message fragment. To keep large BFCP messages from
fragmented at the IP layer, in the event the size of a BFCP message being fragmented at the IP layer, the fragmentation of BFCP messages
exceeds the MTU size, the fragmentation will be handled by the BFCP that exceed the path MTU size is performed at the BFCP level.
protocol. Considerations related to fragmentation are covered in Considerations related to fragmentation are covered in Section 6.2.3.
Section 6.2.3. The message format for exchange of BFCP in UDP The message format for BFCP messages is the same regardless of
datagrams is the same as for a TCP stream above. whether the messages are sent in UDP datagrams or over a TCP stream.
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 sending a Hello message. The floor control server responds to the
responded to with a HelloAck message and only upon receipt of Hello message with a HelloAck message. The client considers the
HelloAck can the client consider the floor control service as present floor control service as present and available only upon receiving
and available. the HelloAck message.
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 SHOULD 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
that it was a response to an outstanding request transaction, the
client MAY discard the message as the client will retransmit the
message when the retransmit timer T1 specified in Section 8.3.1
fires.
Transaction ID values are non-sequential and entities are at liberty Entities MUST have at most one outstanding request transaction at any
to select values at random. Entities MUST only have at most one one time. Implicit subscriptions occur for a client-initiated
outstanding request transaction at any one time. Implicit request transaction whose acknowledgement is implied by the first
subscriptions occur for a client-initiated request transaction whose server-initiated response for that transaction, followed by zero of
acknowledgement is implied by the first server-initiated response for more subsequent server-initiated messages corresponding to the same
that transaction, followed by zero of more subsequent server- transaction. An example is a FloorRequest message for which there
initiated messages corresponding to the same transaction. An example are potentially multiple responses from the floor control server as
is a FloorRequest message for which there are potentially multiple it processes intermediate states until a terminal state (e.g.,
responses from the floor control server as it processes intermediate Granted or Denied) is attained. The subsequent changes in state for
states until a terminal state (e.g., Granted or Denied) is attained. the request are new transactions whose Transaction ID is determined
The subsequent changes in state for the request are new transactions by the floor control server and whose receipt by the client
whose Transaction ID is determined by the floor control server and participant shall be acknowledged with a FloorRequestStatusAck
whose receipt by the client participant shall be acknowledged with a 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 such late arriving
As the floor control server cannot send a second update to the response. As the floor control server cannot send a second update to
implicit floor status subscription until the first is acknowledged, the implicit floor status subscription until the first is
ordinality is maintained. acknowledged, ordinality is maintained.
If a client wishes to end its BFCP association with a floor control If a client wishes to end its BFCP connection 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 connection 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.
[16] specifies how to establish a TCP connection to a floor control
server outside the context of an offer/answer exchange. When using
UDP the same set of data is needed for a BFCP connection as listed in
[16], Section 3, i.e. transport address of the server, the conference
identifier, and the user identifier. The procedures and
considerations for resolving a host name into an IP address also
applies to BFCP over an unreliable transport. In [16], Section 4
applies, but when using BFCP over an unreliable transport the floor
control server that receives a BFCP message over UDP (no DTLS) SHOULD
request the use of DTLS by generating an Error message with an Error
code with a value of 11 (Use DTLS). The recommendations for
authentication in [16], Section 5 and the security considerations in
Section 6 also applies when an unreliable transport is used, both for
certificate-based server authentication and for client authentication
based on a pre-shared secret.
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 [24]. 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 retransmission attempt. This is identical to the specification of
the T1 timer in SIP as described in Section 17.1.1.2 of [15]. the timer A and its initial value T1 in SIP as described in Section
17.1.1.2 of [14].
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 connection, the entity SHOULD treat the BFCP connection 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 BFCP connection afresh. The new BFCP
will appear as a wholly new floor participant, chair or floor control connection will appear as originating from a wholly new floor
server with all state previously held about that participant lost. participant, chair or floor control server with all state previously
held about that participant lost.
Note: This is because the peer entities cannot rely on IP and port Informational note: The recommendation to treat the connection as
tuple to uniquely identify the participant, nor would extending Hello closed in this case, stems from the fact that the peer entities
to include an attribute that advertised what the entity previously cannot rely on IP and port tuple to uniquely identify the
was assigned as a User ID be acceptable due to session hijacking. participant, nor would extending Hello to include an attribute
that advertised what identity the entity previously was assigned
(i.e., a User ID) be acceptable due to session hijacking.
In deployments where NAT appliances, firewalls or other such devices In deployments where NAT appliances or other such devices are present
are present and affecting port reachability for each entity, one and affecting port reachability for each entity, one possibility is
possibility is to utilize the peer connectivity checks, relay use and to utilize the peer connectivity checks, relay use and NAT pinhole
NAT pinhole maintenance mechanisms defined in ICE [14]. maintenance mechanisms defined in ICE [13].
6.2.3. Fragmentation Handling 6.2.3. Fragmentation Handling
The size of a BFCP message is limited by the 16-bit Payload Length When using UDP, a single BFCP message could be fragmented at the IP
field of the COMMON-HEADER. When using UDP, a single BFCP message layer if its overall size exceeds the path MTU of the network. To
may be fragmented at the IP layer if its overall size exceeds the MTU avoid this happening at the IP layer, a fragmentation scheme for BFCP
threshold of the network. is defined below.
When transmitting a BFCP message with size greater than the MTU, the BFCP is designed for achieving small message size, due to the binary
sender should fragment the message into a series of N contiguous data encoding as described in Section 1. The fragmentation scheme is
ranges. The sender should then create N BFCP fragment messages (one therefore deliberately kept simple and straightforward, since the
probability of fragmentation of BFCP messages being required is
small. By design, the fragmentation scheme does not acknowledge
individual BFCP message fragments. The whole BFCP message is
acknowledged if received completely.
BFCP entities should consider the MTU size available between the
sender and the receiver and MAY run MTU discovery, such as
[19][20][21], for this purpose.
When transmitting a BFCP message with size greater than the path MTU,
the sender MUST fragment the message into a series of N contiguous
data ranges. The sender then creates 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 path MTU. The F flag in
COMMON-HEADER is set to indicate fragmentation of the BFCP message. the 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
denotes the number of bytes contained in the previous fragments. The denotes the number of bytes contained in the previous fragments. The
Fragment Length contains the length of the fragment itself. Note Fragment Length contains the length of the fragment itself. Note
that the Payload Length field contains the length of the entire, that the Payload Length field contains the length of the entire,
unfragmented message. unfragmented message.
When a BFCP implementation receives a BFCP message fragment, it MUST When a BFCP implementation receives a BFCP message fragment, it MUST
buffer the fragment until it has received the entire BFCP message. buffer the fragment until it has received the entire BFCP message.
The state machine should handle the BFCP message only after all the The state machine should handle the BFCP message only after all the
fragments for the message have been received. fragments for the message have been received.
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 acknowledgement for the message. Therefore the sender will
message with same transaction ID as specified in Section 8.3. If the retransmit the message with same transaction ID as specified in
ACK sent by the receiver is lost, then the entire message will be Section 8.3. If the acknowledgement message sent by the receiver is
resent by the sender. The receiver MUST then retransmit the ACK. lost, then the entire message will be resent by the sender. The
The receiver can discard an incomplete buffer utilizing the Response receiver must then retransmit the acknowledgement. The receiver MAY
Retransmission Timer, starting the timer after the receipt of the discard an incomplete buffer utilizing the Response Retransmission
first fragment. Timer, starting the timer after the receipt of the first fragment.
A Denial of Service (DoS) attacks utilizing the fragmentation
scheme described above is mitigated by the fact that the Response
Retransmission Timer is started after receipt of the first BFCP
message fragment. In addition, the Payload Length field may be
compared with the Fragment Offset and Fragment Length fields to
verify the message fragments as they arrive. To make DoS attacks
with spoofed IP addresses difficult, BFCP entities should use the
cookie exchange mechanism in DTLS [5].
When deciding message fragment size based on path MTU, the BFCP
fragmentation handling should take into account how the DTLS record
framing expands the datagram size as described in Section 4.1.1.1 of
[5].
6.2.4. 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]. [13].
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 entities using
are RECOMMENDED to use STUN [10] Binding Indication for keep-alives, unreliable transport are RECOMMENDED to use STUN [9] Binding
as described for ICE [14]. Indication for keep-alives, as described for ICE [13]. [22], Section
6.7 provides useful recommendations for middlebox interaction when
DTLS is used.
Informational note: Since the version number is set to 2 when BFCP Informational note: Since the version number is set to 2 when BFCP
is used over unreliable transport, cf. the Ver field in is used over an unreliable transport, cf. the Ver field in
Section 5.1, it is straight forward to distinguish between STUN Section 5.1, it is straight forward to distinguish between STUN
and BFCP packets even without checking the STUN magic cookie [10]. and BFCP packets even without checking the STUN magic cookie [9].
In order to facilitate traversal of BFCP packets through NATs, BFCP In order to facilitate traversal of BFCP packets through NATs, BFCP
over UDP entities are RECOMMENDED to use symmetric ports for sending entities using unreliable transport are RECOMMENDED to use symmetric
and receiving BFCP packets, as recommended for RTP/RTCP [9]. ports for sending and receiving BFCP packets, as recommended for RTP/
RTCP [8].
7. Lower-Layer Security 7. Lower-Layer Security
BFCP relies on lower-layer security mechanisms to provide replay and BFCP relies on lower-layer security mechanisms to provide replay and
integrity protection and confidentiality. BFCP floor control servers integrity protection and confidentiality. BFCP floor control servers
and clients (which include both floor participants and floor chairs) and clients (which include both floor participants and floor chairs)
MUST support TLS for transport over TCP [4] and MUST support DTLS [5] MUST support TLS for transport over TCP [4] and MUST support DTLS [5]
for transport over UDP. Any BFCP entity MAY support other security for transport over UDP. Any BFCP entity MAY support other security
mechanisms. mechanisms.
BFCP entities MUST support, at a minimum, the BFCP entities MUST support, at a minimum, the
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [4]. TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [4].
Which party, the client or the floor control server, acts as the TLS/ Which party, the client or the floor control server, acts as the TLS/
DTLS server depends on how the underlying TLS/DTLS connection is DTLS server depends on how the underlying TLS/DTLS connection is
established. For a TCP/TLS connection established using an SDP established. For a TCP/TLS connection established using an SDP
offer/answer exchange [7], the answerer (which may be the client or offer/answer exchange [7], the answerer (which may be the client or
the floor control server) always acts as the TLS server. For a UDP/ the floor control server) always acts as the TLS server. For a UDP/
DTLS connection established using the same exchange, either party can DTLS connection established using the same exchange, either party can
be the DTLS server depending on the setup attributes exchanged; be the DTLS server depending on the setup attributes exchanged;
examples can be found in [8]. examples can be found in [22].
8. Protocol Transactions 8. Protocol Transactions
In BFCP, there are two types of transactions: client-initiated In BFCP, there are two types of transactions: client-initiated
transactions and server-initiated transactions (notifications). transactions and server-initiated transactions.
Client-initiated transactions consist of a request from a client to a Client-initiated transactions consist of a request from a client to a
floor control server and a response from the floor control server to floor control server and a response from the floor control server to
the client. The request carries a Transaction ID in its common the client. The request carries a Transaction ID in its common
header, which the floor control server copies into the response. header, which the floor control server copies into the response.
Clients use Transaction ID values to match responses with previously Clients use Transaction ID values to match responses with previously
issued requests. issued requests.
Server-initiated transactions consist of a single message from a Server-initiated transactions have different requirements and
floor control server to a client. Since they do not trigger any behavior depending on underlying transport:
response, their Transaction ID is set to 0 when used over reliable
transports, but must be non-zero and unique in the context of When using reliable transport, server-initiated transactions
outstanding transactions over unreliable transports. consist of a single message from a floor control server to a
client (notifications). Since they do not trigger any response,
their Transaction ID is set to 0.
When using unreliable transport, server-initiated transactions
consist of a request from a floor control server to a client and a
response from the client to the floor control server. The
Transaction ID must be non-zero and unique in the context of
outstanding transactions over unreliable transports. The request
carries a Transaction ID in its common header, which the client
copies into the response. Floor control servers use Transaction
ID values to match responses with previously issued requests.
When using BFCP over unreliable transport, it is also required to
choose values that let the receiver distinguish the reception of the
next message in a sequence of BFCP messages from a retransmission of
a previous message. Therefore, BFCP entities using unreliable
transport SHOULD use monotonically increasing values for the
Transaction ID.
When using BFCP over unreliable transports, all requests will use When using BFCP over unreliable transports, all requests will use
retransmit timer T1 (see Section 8.3) until the transaction is retransmission timer T1 (see Section 8.3) until the transaction is
completed. completed.
8.1. Client Behavior 8.1. Client Behavior
A client starting a client-initiated transaction MUST set the A client starting a client-initiated transaction MUST set the
Conference ID in the common header of the message to the Conference Conference ID in the common header of the message to the Conference
ID for the conference that the client obtained previously. ID for the conference that the client obtained previously.
The client MUST set the Transaction ID value in the common header to The client MUST set the Transaction ID value in the common header to
a number that is different from 0 and that MUST NOT be reused in a number that is different from 0 and that MUST NOT be reused in
skipping to change at page 44, line 48 skipping to change at page 46, line 23
another message from the client until a response from the server is another message from the client until a response from the server is
received for the transaction. The client uses the Transaction ID received for the transaction. The client uses the Transaction ID
value to match this message with the response from the floor control value to match this message with the response from the floor control
server. server.
8.2. Server Behavior 8.2. Server Behavior
A floor control server sending a response within a client-initiated A floor control server sending a response within a client-initiated
transaction MUST copy the Conference ID, the Transaction ID, and the transaction MUST copy the Conference ID, the Transaction ID, and the
User ID from the request received from the client into the response. User ID from the request received from the client into the response.
Server-initiated transactions MUST contain a Transaction ID equal to Server-initiated transactions MUST contain a Transaction ID equal to
0 when BFCP is used over reliable transports. Over unreliable 0 when BFCP is used over reliable transports. Over an unreliable
transport, the Transaction ID shall have the same properties as for transport, the Transaction ID shall have the same properties as for
client-initiated transactions: the server MUST set the Transaction ID client-initiated transactions: the server MUST set the Transaction ID
value in the common header to a number that is different from 0 and value in the common header to a number that is different from 0 and
that MUST NOT be reused in another message from the server until the that MUST NOT be reused in another message from the server until the
appropriate response from the client is received for the transaction. appropriate response from the client is received for the transaction.
The server uses the Transaction ID value to match this message with The server uses the Transaction ID value to match this message with
the response from the floor participant or floor chair. the response from the floor participant or floor chair.
8.3. Timers 8.3. Timers
skipping to change at page 45, line 26 skipping to change at page 46, line 49
when BFCP entities communicate over reliable transports. when BFCP entities communicate over reliable transports.
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 connection 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 [10]
exchange). Alternatively, they MAY continue without BFCP and exchange).
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
be responded to by replaying the cached response, whilst that value be responded to by replaying the cached response, whilst that value
is retained until the timer has fired. is retained until the timer has fired.
T2 shall be set such that it encompasses all legal retransmissions
per T1 plus a factor to accommodate network latency between BFCP
entities.
8.3.3. Timer Values 8.3.3. Timer Values
The table below defines the different timers required when BFCP The table below defines the different timers required when BFCP
entities communicate over an unreliable transport. entities communicate over an unreliable transport.
+-------+--------------------------------------+---------+ +-------+--------------------------------------+---------+
| Timer | Description | Value/s | | Timer | Description | Value/s |
+-------+--------------------------------------+---------+ +-------+--------------------------------------+---------+
| T1 | Initial request retransmission timer | 0.5s | | T1 | Initial request retransmission timer | 0.5s |
| T2 | Response retransmission timer | 10s | | T2 | Response retransmission timer | 10s |
+-------+--------------------------------------+---------+ +-------+--------------------------------------+---------+
Table 6: Timers Table 6: Timers
The default value for T1 is 500 ms, this is an estimate of the RTT The default value for T1 is 500 ms, this is an estimate of the RTT
for completing the transaction. T1 MAY be chosen larger, and this is for completing the transaction. T1 MAY be chosen larger, and this is
RECOMMENDED if it is known in advance that the RTT is larger. RECOMMENDED if it is known in advance that the RTT is larger.
Regardless of the value of T1, the exponential backoffs on Regardless of the value of T1, the exponential backoffs on
retransmissions described in Section 8.3.1 MUST be used. retransmissions described in Section 8.3.1 MUST be used.
T2 SHALL be set such that it encompasses all legal retransmissions
per T1 plus a factor to accommodate network latency between BFCP
entities. The default value is based on the sum of the three
retransmissions related to T1 using its default value (7.5s) and an
extra 2.5s is added to take into account potential messages in
transit due to latency.
9. Authentication and Authorization 9. Authentication and Authorization
BFCP clients SHOULD authenticate the floor control server before BFCP clients SHOULD authenticate the floor control server before
sending any BFCP message to it or accepting any BFCP message from it. sending any BFCP message to it or accepting any BFCP message from it.
Similarly, floor control servers SHOULD authenticate a client before Similarly, floor control servers SHOULD authenticate a client before
accepting any BFCP message from it or sending any BFCP message to it. accepting any BFCP message from it or sending any BFCP message to it.
BFCP supports TLS/DTLS mutual authentication between clients and BFCP supports TLS/DTLS mutual authentication between clients and
floor control servers, as specified in Section 9.1. This is the floor control servers, as specified in Section 9.1. This is the
RECOMMENDED authentication mechanism in BFCP. RECOMMENDED authentication mechanism in BFCP.
skipping to change at page 49, line 46 skipping to change at page 51, line 21
The PRIORITY attribute, when present, contains the priority that was The PRIORITY attribute, when present, contains the priority that was
requested by the generator of the FloorRequest message. requested by the generator of the FloorRequest message.
If the response is an Error message, the floor control server could If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is not process the FloorRequest message for some reason, which is
described in the Error message. described in the Error message.
10.1.3. Reception of a Subsequent FloorRequestStatus Message 10.1.3. Reception of a Subsequent FloorRequestStatus Message
When communicating over unreliable transport and upon receiving a When communicating over an unreliable transport and upon receiving a
FloorRequestStatus message from a floor control server, the FloorRequestStatus message from a floor control server, the
participant MUST respond with a FloorRequestStatusAck message within participant MUST respond with a FloorRequestStatusAck message within
the transaction failure window to complete the transaction. the transaction failure window to complete the transaction.
10.2. Cancelling a Floor Request and Releasing a Floor 10.2. Cancelling a Floor Request and Releasing a Floor
A floor participant that wishes to cancel an ongoing floor request A floor participant that wishes to cancel an ongoing floor request
does so by sending a FloorRelease message to the floor control does so by sending a FloorRelease message to the floor control
server. The FloorRelease message is also used by floor participants server. The FloorRelease message is also used by floor participants
that hold a floor and would like to release it. that hold a floor and would like to release it.
skipping to change at page 54, line 30 skipping to change at page 56, line 7
attribute. This grouped attribute carries a Floor Request ID that attribute. This grouped attribute carries a Floor Request ID that
identifies the floor request, followed by a set of attributes that identifies the floor request, followed by a set of attributes that
provide information about the floor request. provide information about the floor request.
After the first FloorStatus, the floor control server will continue After the first FloorStatus, the floor control server will continue
sending FloorStatus messages, periodically informing the client about sending FloorStatus messages, periodically informing the client about
changes on the floors the client requested information about. changes on the floors the client requested information about.
12.1.3. Reception of a Subsequent FloorStatus Message 12.1.3. Reception of a Subsequent FloorStatus Message
When communicating over unreliable transport and upon receiving a When communicating over an unreliable transport and upon receiving a
FloorStatus message from a floor control server, the participant MUST FloorStatus message from a floor control server, the participant MUST
respond with a FloorStatusAck message within the transaction failure respond with a FloorStatusAck message within the transaction failure
window to complete the transaction. window to complete the transaction.
12.2. Requesting Information about Floor Requests 12.2. Requesting Information about Floor Requests
A client can obtain information about the status of one or several A client can obtain information about the status of one or several
floor requests in different ways, which include using BFCP and using floor requests in different ways, which include using BFCP and using
out-of-band mechanisms. Clients using BFCP to obtain such out-of-band mechanisms. Clients using BFCP to obtain such
information use the procedures described in this section. information use the procedures described in this section.
skipping to change at page 58, line 40 skipping to change at page 60, line 14
BFCP allows floor participants to have several ongoing floor BFCP allows floor participants to have several ongoing floor
requests for the same floor (e.g., the same floor participant can requests for the same floor (e.g., the same floor participant can
occupy more than one position in a queue at the same time). A occupy more than one position in a queue at the same time). A
floor control server that only supports a certain number of floor control server that only supports a certain number of
ongoing floor requests per floor participant (e.g., one) can use ongoing floor requests per floor participant (e.g., one) can use
Error Code 8 (You have Already Reached the Maximum Number of Error Code 8 (You have Already Reached the Maximum Number of
Ongoing Floor Requests for this Floor) to inform the floor Ongoing Floor Requests for this Floor) to inform the floor
participant. participant.
When communicating over unreliable transport and upon receiving a When communicating over an unreliable transport and upon receiving a
FloorRequest from a participant, the floor control server MUST FloorRequest from a participant, the floor control server MUST
respond with a FloorRequestStatus message within the transaction respond with a FloorRequestStatus message within the transaction
failure window to complete the transaction. failure window to complete the transaction.
13.1.1. Generating the First FloorRequestStatus Message 13.1.1. Generating the First FloorRequestStatus Message
The successful processing of a FloorRequest message by a floor The successful processing of a FloorRequest message by a floor
control server involves generating one or several FloorRequestStatus control server involves generating one or several FloorRequestStatus
messages, the first of which SHOULD be generated as soon as possible. messages, the first of which SHOULD be generated as soon as possible.
If the floor control server cannot accept, grant, or deny the floor If the floor control server cannot accept, grant, or deny the floor
skipping to change at page 61, line 20 skipping to change at page 62, line 39
needs to follow the procedures in Section 13.5 to inform the needs to follow the procedures in Section 13.5 to inform the
clients that have requested that information. clients that have requested that information.
The common header and the rest of the attributes are the same as in The common header and the rest of the attributes are the same as in
the first FloorRequestStatus message. the first FloorRequestStatus message.
The floor control server can discard the state information about a The floor control server can discard the state information about a
particular floor request when this reaches a status of Cancelled, particular floor request when this reaches a status of Cancelled,
Released, or Revoked. Released, or Revoked.
When communicating over unreliable transport and a When communicating over an unreliable transport and a
FloorRequestStatusAck message is not received within the transaction FloorRequestStatusAck message is not received within the transaction
failure window, the floor control server MUST retransmit the failure window, the floor control server MUST retransmit the
FloorRequestStatus message according to Section 6.2. FloorRequestStatus message according to Section 6.2.
13.2. Reception of a FloorRequestQuery Message 13.2. Reception of a FloorRequestQuery Message
On reception of a FloorRequestQuery message, the floor control server On reception of a FloorRequestQuery message, the floor control server
follows the rules in Section 9 that relate to client authentication follows the rules in Section 9 that relate to client authentication
and authorization. If while processing the FloorRequestQuery and authorization. If while processing the FloorRequestQuery
message, the floor control server encounters an error, it SHOULD message, the floor control server encounters an error, it SHOULD
generate an Error response following the procedures described in generate an Error response following the procedures described in
Section 13.8. Section 13.8.
The successful processing of a FloorRequestQuery message by a floor The successful processing of a FloorRequestQuery message by a floor
control server involves generating a FloorRequestStatus message, control server involves generating a FloorRequestStatus message,
which SHOULD be generated as soon as possible. which SHOULD be generated as soon as possible.
When communicating over unreliable transport and upon receiving a When communicating over an unreliable transport and upon receiving a
FloorRequestQuery from a participant, the floor control server MUST FloorRequestQuery from a participant, the floor control server MUST
respond with a FloorRequestStatus message within the transaction respond with a FloorRequestStatus message within the transaction
failure window to complete the transaction. failure window to complete the transaction.
The floor control server MUST copy the Conference ID, the Transaction The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the FloorRequestQuery message into the ID, and the User ID from the FloorRequestQuery message into the
FloorRequestStatus message, as described in Section 8.2. FloorRequestStatus message, as described in Section 8.2.
Additionally, the floor control server MUST include information about Additionally, the floor control server MUST include information about
the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute
to the FloorRequestStatus. to the FloorRequestStatus.
skipping to change at page 62, line 48 skipping to change at page 64, line 19
On reception of a UserQuery message, the floor control server follows On reception of a UserQuery message, the floor control server follows
the rules in Section 9 that relate to client authentication and the rules in Section 9 that relate to client authentication and
authorization. If while processing the UserQuery message, the floor authorization. If while processing the UserQuery message, the floor
control server encounters an error, it SHOULD generate an Error control server encounters an error, it SHOULD generate an Error
response following the procedures described in Section 13.8. response following the procedures described in Section 13.8.
The successful processing of a UserQuery message by a floor control The successful processing of a UserQuery message by a floor control
server involves generating a UserStatus message, which SHOULD be server involves generating a UserStatus message, which SHOULD be
generated as soon as possible. generated as soon as possible.
When communicating over unreliable transport and upon receiving a When communicating over an unreliable transport and upon receiving a
UserQuery from a participant, the floor control server MUST respond UserQuery from a participant, the floor control server MUST respond
with a UserStatus message within the transaction failure window to with a UserStatus message within the transaction failure window to
complete the transaction. complete the transaction.
The floor control server MUST copy the Conference ID, the Transaction The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the UserQuery message into the USerStatus ID, and the User ID from the UserQuery message into the USerStatus
message, as described in Section 8.2. message, as described in Section 8.2.
The sender of the UserQuery message is requesting information about The sender of the UserQuery message is requesting information about
all the floor requests associated with a given participant (i.e., the all the floor requests associated with a given participant (i.e., the
skipping to change at page 64, line 30 skipping to change at page 65, line 49
On reception of a FloorRelease message, the floor control server On reception of a FloorRelease message, the floor control server
follows the rules in Section 9 that relate to client authentication follows the rules in Section 9 that relate to client authentication
and authorization. If while processing the FloorRelease message, the and authorization. If while processing the FloorRelease message, the
floor control server encounters an error, it SHOULD generate an Error floor control server encounters an error, it SHOULD generate an Error
response following the procedures described in Section 13.8. response following the procedures described in Section 13.8.
The successful processing of a FloorRelease message by a floor The successful processing of a FloorRelease message by a floor
control server involves generating a FloorRequestStatus message, control server involves generating a FloorRequestStatus message,
which SHOULD be generated as soon as possible. which SHOULD be generated as soon as possible.
When communicating over unreliable transport and upon receiving a When communicating over an unreliable transport and upon receiving a
FloorRelease from a participant, the floor control server MUST FloorRelease from a participant, the floor control server MUST
respond with a FloorRequestStatus message within the transaction respond with a FloorRequestStatus message within the transaction
failure window to complete the transaction. failure window to complete the transaction.
The floor control server MUST copy the Conference ID, the Transaction The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the FloorRelease message into the ID, and the User ID from the FloorRelease message into the
FloorRequestStatus message, as described in Section 8.2. FloorRequestStatus message, as described in Section 8.2.
The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
attribute to the FloorRequestStatus. The attributes contained in attribute to the FloorRequestStatus. The attributes contained in
skipping to change at page 65, line 20 skipping to change at page 66, line 40
INFO attribute with extra information about the floor request. INFO attribute with extra information about the floor request.
13.5. Reception of a FloorQuery Message 13.5. Reception of a FloorQuery Message
On reception of a FloorQuery message, the floor control server On reception of a FloorQuery message, the floor control server
follows the rules in Section 9 that relate to client authentication. follows the rules in Section 9 that relate to client authentication.
If while processing the FloorQuery message, the floor control server If while processing the FloorQuery message, the floor control server
encounters an error, it SHOULD generate an Error response following encounters an error, it SHOULD generate an Error response following
the procedures described in Section 13.8. the procedures described in Section 13.8.
When communicating over unreliable transport and upon receiving a When communicating over an unreliable transport and upon receiving a
FloorQuery from a participant, the floor control server MUST respond FloorQuery from a participant, the floor control server MUST respond
with a FloorStatus message within the transaction failure window to with a FloorStatus message within the transaction failure window to
complete the transaction. complete the transaction.
A floor control server receiving a FloorQuery message from a client A floor control server receiving a FloorQuery message from a client
SHOULD keep this client informed about the status of the floors SHOULD keep this client informed about the status of the floors
identified by FLOOR-ID attributes in the FloorQuery message. Floor identified by FLOOR-ID attributes in the FloorQuery message. Floor
Control Servers keep clients informed by using FloorStatus messages. Control Servers keep clients informed by using FloorStatus messages.
An individual FloorStatus message carries information about a single An individual FloorStatus message carries information about a single
skipping to change at page 67, line 30 skipping to change at page 68, line 50
Transaction ID of these messages MUST be 0 when using reliable Transaction ID of these messages MUST be 0 when using reliable
transports and non-zero and unique in the context of outstanding transports and non-zero and unique in the context of outstanding
transactions when using unreliable transports (cf. Section 8). transactions when using unreliable transports (cf. Section 8).
The rate at which the floor control server sends FloorStatus The rate at which the floor control server sends FloorStatus
messages is a matter of local policy. A floor control server may messages is a matter of local policy. A floor control server may
choose to send a new FloorStatus message every time a new floor choose to send a new FloorStatus message every time a new floor
request arrives, while another may choose to only send a new request arrives, while another may choose to only send a new
FloorStatus message when a new floor request is Granted. FloorStatus message when a new floor request is Granted.
When communicating over unreliable transport and a FloorStatusAck When communicating over an unreliable transport and a FloorStatusAck
message is not received within the transaction failure window, the message is not received within the transaction failure window, the
floor control server MUST retransmit the FloorStatus message floor control server MUST retransmit the FloorStatus message
according to Section 6.2. according to Section 6.2.
13.6. Reception of a ChairAction Message 13.6. Reception of a ChairAction Message
On reception of a ChairAction message, the floor control server On reception of a ChairAction message, the floor control server
follows the rules in Section 9 that relate to client authentication follows the rules in Section 9 that relate to client authentication
and authorization. If while processing the ChairAction message, the and authorization. If while processing the ChairAction message, the
floor control server encounters an error, it SHOULD generate an Error floor control server encounters an error, it SHOULD generate an Error
response following the procedures described in Section 13.8. response following the procedures described in Section 13.8.
The successful processing of a ChairAction message by a floor control The successful processing of a ChairAction message by a floor control
server involves generating a ChairActionAck message, which SHOULD be server involves generating a ChairActionAck message, which SHOULD be
generated as soon as possible. generated as soon as possible.
When communicating over unreliable transport and upon receiving a When communicating over an unreliable transport and upon receiving a
ChairAction from a chair, the floor control server MUST respond with ChairAction from a chair, the floor control server MUST respond with
a ChairActionAck message within the transaction failure window to a ChairActionAck message within the transaction failure window to
complete the transaction. complete the transaction.
The floor control server MUST copy the Conference ID, the Transaction The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the ChairAction message into the ID, and the User ID from the ChairAction message into the
ChairActionAck message, as described in Section 8.2. ChairActionAck message, as described in Section 8.2.
The floor control server needs to take into consideration the The floor control server needs to take into consideration the
operation requested in the ChairAction message (e.g., granting a operation requested in the ChairAction message (e.g., granting a
skipping to change at page 68, line 40 skipping to change at page 70, line 13
applies if the floor control server implements a queue.) applies if the floor control server implements a queue.)
13.7. Reception of a Hello Message 13.7. Reception of a Hello Message
On reception of a Hello message, the floor control server follows the On reception of a Hello message, the floor control server follows the
rules in Section 9 that relate to client authentication. If while rules in Section 9 that relate to client authentication. If while
processing the Hello message, the floor control server encounters an processing the Hello message, the floor control server encounters an
error, it SHOULD generate an Error response following the procedures error, it SHOULD generate an Error response following the procedures
described in Section 13.8. described in Section 13.8.
When communicating over unreliable transport and upon receiving a When communicating over an unreliable transport and upon receiving a
Hello from a participant, the floor control server MUST respond with Hello from a participant, the floor control server MUST respond with
a HelloAck message within the transaction failure window to complete a HelloAck message within the transaction failure window to complete
the transaction. the transaction.
The successful processing of a Hello message by a floor control The successful processing of a Hello message by a floor control
server involves generating a HelloAck message, which SHOULD be server involves generating a HelloAck message, which SHOULD be
generated as soon as possible. The floor control server MUST copy generated as soon as possible. The floor control server MUST copy
the Conference ID, the Transaction ID, and the User ID from the Hello the Conference ID, the Transaction ID, and the User ID from the Hello
into the HelloAck, as described in Section 8.2. into the HelloAck, as described in Section 8.2.
skipping to change at page 69, line 44 skipping to change at page 71, line 17
mechanisms as long as they provide similar security properties. mechanisms as long as they provide similar security properties.
The remainder of this section analyzes some of the threats against The remainder of this section analyzes some of the threats against
BFCP and how they are addressed. BFCP and how they are addressed.
An attacker may attempt to impersonate a client (a floor participant An attacker may attempt to impersonate a client (a floor participant
or a floor chair) in order to generate forged floor requests or to or a floor chair) in order to generate forged floor requests or to
grant or deny existing floor requests. Client impersonation is grant or deny existing floor requests. Client impersonation is
avoided by having servers only accept BFCP messages over avoided by having servers only accept BFCP messages over
authenticated TLS/DTLS connections. The floor control server assumes authenticated TLS/DTLS connections. The floor control server assumes
that attackers cannot highjack the TLS/DTLS connection and, that attackers cannot high-jack the TLS/DTLS connection and,
therefore, that messages over the TLS/DTLS connection come from the therefore, that messages over the TLS/DTLS connection come from the
client that was initially authenticated. client that was initially authenticated.
An attacker may attempt to impersonate a floor control server. A An attacker may attempt to impersonate a floor control server. A
successful attacker would be able to make clients think that they successful attacker would be able to make clients think that they
hold a particular floor so that they would try to access a resource hold a particular floor so that they would try to access a resource
(e.g., sending media) without having legitimate rights to access it. (e.g., sending media) without having legitimate rights to access it.
Floor control server impersonation is avoided by having servers only Floor control server impersonation is avoided by having servers only
accept BFCP messages over authenticated TLS/DTLS connections, as well accept BFCP messages over authenticated TLS/DTLS connections, as well
as ensuring clients only send and accept messages over authenticated as ensuring clients only send and accept messages over authenticated
skipping to change at page 74, line 31 skipping to change at page 75, line 31
| 12 | Unsupported Version | [RFC XXXX] | | 12 | Unsupported Version | [RFC XXXX] |
| 13 | Incorrect Message Length | [RFC XXXX] | | 13 | Incorrect Message Length | [RFC XXXX] |
| 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 [15].
16.1. Extensions for unreliable transport 16.1. Extensions for an 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 an unreliable transport, resulting in the following
changes:
Overview of Operation (Section 4): Overview of Operation (Section 4):
Changed the description of client-initiated and server- Changed the description of client-initiated and server-
initiated transactions, referring to Section 8. 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 an unreliable transport. Added new R and F flag-bits for
unreliable transport. Res(erved) field is now 3 bit. New an 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 four 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". Note that two additional DTLS" and "Unsupported Version". Note that two additional
error codes were added, see Section 16.2. 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 a reliable transport and
for unreliable transport. Where the specification for Section 6.2 for an unreliable transport. Where the
unreliable transport amongst other issues deals with specification for an unreliable transport amongst other issues
reliability, congestion control, fragmentation and ICMP. deals with reliability, congestion control, fragmentation and
ICMP.
Mandate DTLS (Section 7 and Section 9): Mandate DTLS (Section 7 and Section 9):
Mandate DTLS support when transport over UDP is used. Mandate DTLS support when transport over UDP is used.
Transaction changes (Section 8): Transaction changes (Section 8):
Server-initiated transactions over unreliable transport has Server-initiated transactions over an unreliable transport has
non-zero and unique Transaction ID. Over unreliable transport, non-zero and unique Transaction ID. Over an unreliable
the retransmit timers T1 and T2 described in Section 8.3 transport, the retransmit timers T1 and T2 described in
applies. Section 8.3 applies.
Requiring timely response (Section 10.1.2, Section 10.2.2, Requiring timely response (Section 10.1.2, Section 10.2.2,
Section 11.2, Section 12.1.2, Section 12.2.2, Section 12.3.2, Section 11.2, Section 12.1.2, Section 12.2.2, Section 12.3.2,
Section 12.4.2, Section 10.1.3 and Section 12.1.3): Section 12.4.2, Section 10.1.3 and Section 12.1.3):
Describing that a given response must be sent within the Describing that a given response must be sent within the
transaction failure window to complete the transaction. transaction failure window to complete the transaction.
Updated IANA Considerations (Section 15): Updated IANA Considerations (Section 15):
Added the new primitives and error codes to Section 15.2 and Added the new primitives and error codes to Section 15.2 and
Section 15.4 respectively. Section 15.4 respectively.
Examples over unreliable transport (Appendix A): Examples over an unreliable transport (Appendix A):
Added sample interactions over unreliable transport for the Added sample interactions over an 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 an unreliable transport (Appendix B):
Introduction to and motivation for extending BFCP to support Introduction to and motivation for extending BFCP to support an
unreliable transport. unreliable transport.
16.2. Other changes 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 [15], 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-PRIMITVIES to SUPPORTED-PRIMITIVES 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".
17. Acknowledgements 17. Acknowledgements
The XCON WG chairs, Adam Roach and Alan Johnston, provided useful The XCON WG chairs, Adam Roach and Alan Johnston, provided useful
ideas for RFC 4582 [16]. Additionally, Xiaotao Wu, Paul Kyzivat, ideas for RFC 4582 [15]. Additionally, Xiaotao Wu, Paul Kyzivat,
Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben
Campbell, Dave Morgan, and Oscar Novo provided useful comments during Campbell, Dave Morgan, and Oscar Novo provided useful comments during
the work with RFC 4582. The authors also acknowledge contributions the work with RFC 4582. The authors also acknowledge contributions
to the revision of BFCP for use over an unreliable transport from to the revision of BFCP for use over an unreliable transport from
Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad, Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad,
Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero,
Joerg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, Joerg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing,
Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman, Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman,
Vijaya Mandava and Alan Ford. In the final phase Ernst Horvath did a Vijaya Mandava and Alan Ford. In the final phase Ernst Horvath did a
thorough review revealing issues that needed clarification and thorough review revealing issues that needed clarification and
skipping to change at page 77, line 19 skipping to change at page 78, line 22
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, "Session Description Protocol [7] Camarillo, G. and T. Kristensen, "Session Description Protocol
(SDP) Format for Binary Floor Control Protocol (BFCP) Streams", (SDP) Format for Binary Floor Control Protocol (BFCP) Streams",
draft-ietf-bfcpbis-rfc4583bis-03 (work in progress), draft-ietf-bfcpbis-rfc4583bis-04 (work in progress),
October 2012. December 2012.
[8] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for
Establishing a Secure Real-time Transport Protocol (SRTP)
Security Context Using Datagram Transport Layer Security
(DTLS)", RFC 5763, May 2010.
[9] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [8] 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 [9] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session
Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
18.2. Informational References 18.2. Informational References
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[12] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, [11] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
"Requirements for Floor Control Protocols", RFC 4376, "Requirements for Floor Control Protocols", RFC 4376,
February 2006. February 2006.
[13] Barnes, M., Boulton, C., and O. Levin, "A Framework for [12] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, June 2008.
[14] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [13] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Protocol for Network Address Translator (NAT) Traversal for Protocol for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", RFC 5245, April 2010. Offer/Answer Protocols", RFC 5245, April 2010.
[15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[16] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control [15] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
Protocol (BFCP)", RFC 4582, November 2006. Protocol (BFCP)", RFC 4582, November 2006.
[17] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network [16] Camarillo, G., "Connection Establishment in the Binary Floor
Control Protocol (BFCP)", RFC 5018, September 2007.
[17] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
"Centralized Conferencing Manipulation Protocol", RFC 6503,
March 2012.
[18] Barnes, M., Miniero, L., Presta, R., and SP. Romano,
"Centralized Conferencing Manipulation Protocol (CCMP) Call
Flow Examples", RFC 6504, March 2012.
[19] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[20] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for
IP version 6", RFC 1981, August 1996.
[21] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[22] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for
Establishing a Secure Real-time Transport Protocol (SRTP)
Security Context Using Datagram Transport Layer Security
(DTLS)", RFC 5763, May 2010.
[23] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network
Address Translations (NATs)", RFC 4380, February 2006. Address Translations (NATs)", RFC 4380, February 2006.
[18] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for [24] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for
Application Designers", BCP 145, RFC 5405, November 2008. Application Designers", BCP 145, RFC 5405, November 2008.
[19] Thaler, D., "Teredo Extensions", RFC 6081, January 2011. [25] Thaler, D., "Teredo Extensions", RFC 6081, January 2011.
[20] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, [26] Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
September 2007. September 2007.
[21] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP [27] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP
Candidates with Interactive Connectivity Establishment (ICE)", Candidates with Interactive Connectivity Establishment (ICE)",
RFC 6544, March 2012. RFC 6544, March 2012.
[22] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling [28] 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 [29] 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-05 (work in progress),
July 2012. July 2012.
[24] Guha, S. and P. Francis, "Characterization and Measurement of [30] 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 [31] 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 an unreliable Transport
With reference to Section 4.1, the following figures show With reference to Section 4.1, the following figures show
representative call-flows for requesting and releasing a floor, and representative call-flows for requesting and releasing a floor, and
obtaining status information about a floor when BFCP is deployed over obtaining status information about a floor when BFCP is deployed over
an unreliable transport. The figures here show a loss-less an unreliable transport. The figures here show a loss-less
interaction. interaction.
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorRequest | |(1) FloorRequest |
|Transaction ID: 123 | |Transaction ID: 123 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorRequestStatus | |(2) FloorRequestStatus |
|Transaction ID: 123 | |Transaction ID: 123 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
skipping to change at page 82, line 18 skipping to change at page 83, line 40
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(6) FloorStatusAck | |(6) FloorStatusAck |
|Transaction ID: 4392 | |Transaction ID: 4392 |
|User ID: 234 | |User ID: 234 |
|---------------------------------------------->| |---------------------------------------------->|
Figure 49: Obtaining status information about a floor Figure 49: Obtaining status information about a floor
Appendix B. Motivation for Supporting Unreliable Transport Appendix B. Motivation for Supporting an Unreliable Transport
[Editorial note: This appendix is contained in this draft as an [Editorial note: This appendix is contained in this draft as an
aid and rationale for new readers and reviewers. However, it is aid and rationale for new readers and reviewers. However, it is
not yet decided whether this Appendix will be part of the final not yet decided whether this Appendix will be part of the final
(RFC) version or not.] (RFC) version or not.]
B.1. Motivation B.1. Motivation
In existing video conferencing deployments, BFCP is used to manage In existing video conferencing deployments, BFCP is used to manage
the floor for the content sharing associated with the conference. the floor for the content sharing associated with the conference.
For peer to peer scenarios, including business to business For peer to peer scenarios, including business to business
conferences and point to point conferences in general, it is conferences and point to point conferences in general, it is
frequently the case that one or both endpoints exists behind a NAT/ frequently the case that one or both endpoints exists behind a NAT.
firewall. BFCP roles are negotiated in the offer/answer exchange as BFCP roles are negotiated in the offer/answer exchange as specified
specified in [7], resulting in one endpoint being responsible for in [7], resulting in one endpoint being responsible for opening the
opening the TCP connection used for the BFCP communication. TCP connection used for the BFCP communication.
+---------+ +---------+
| Network | | Network |
+---------+ +---------+
+-----+ / \ +-----+ +-----+ / \ +-----+
| NAT |/ \| NAT | | NAT |/ \| NAT |
+-----+ +-----+ +-----+ +-----+
+----+ / \ +----+ +----+ / \ +----+
|BFCP|/ \|BFCP| |BFCP|/ \|BFCP|
| UA | | UA | | UA | | UA |
+----+ +----+ +----+ +----+
Figure 50: Use Case Figure 50: Use Case
The communication session between the video conferencing endpoints The communication session between the video conferencing endpoints
typically consists of a number of RTP over UDP media streams, for typically consists of a number of RTP over UDP media streams, for
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 traversal for the RTP streams
RTP streams works using ICE and/or other methods, including those works using ICE and/or other methods, including those described in
described in [23]. [29].
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 [27]. 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 [30]. 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
punching as a NAT traversal technique across a wide variety of punching as a NAT traversal technique across a wide variety of
deployed NATs reported consistently higher success rates when using deployed NATs reported consistently higher success rates when using
UDP than when using TCP [25]. UDP than when using TCP [31].
It is worth noticing that BFCP over UDP were already used in real It is worth noticing that BFCP over UDP were already used in real
deployments, underlining the necessity to specify a common way to deployments, underlining the necessity to specify a common way to
exchange BFCP messages where TCP is not appropriate, to avoid a exchange BFCP messages where TCP is not appropriate, to avoid a
situation where multiple different and non-interoperable would co- situation where multiple different and non-interoperable would co-
exist in the market. The purpose of this draft is to formalize and exist in the market. The purpose of this draft is to formalize and
publish the extension from the standard specification to facilitate publish the extension from the standard specification to facilitate
complete interoperability between implementations. complete interoperability between implementations.
B.1.1. Alternatives Considered B.1.1. Alternatives Considered
skipping to change at page 84, line 7 skipping to change at page 85, line 33
to address the use case targeted by this draft. The last to address the use case targeted by this draft. The last
alternative, presented in Appendix B.1.1.7, is the selected one and alternative, presented in Appendix B.1.1.7, is the selected one and
is specified in this draft. is specified in this draft.
It is also worth noting that the IETF Transport Area were asked for a It is also worth noting that the IETF Transport Area were asked for a
way to tunnel TCP over UDP, but at that point there was no consensus way to tunnel TCP over UDP, but at that point there was no consensus
on how to achieve that. on how to achieve that.
B.1.1.1. ICE TCP B.1.1.1. ICE TCP
ICE TCP [21] extends ICE to TCP based media, including the ability to ICE TCP [27] extends ICE to TCP based media, including the ability to
offer a mix of TCP and UDP based candidates for a single stream. ICE offer a mix of TCP and UDP based candidates for a single stream. ICE
TCP has, in general, a lower success probability for enabling TCP TCP has, in general, a lower success probability for enabling TCP
connectivity without a relay if both of the hosts are behind a NAT connectivity without a relay if both of the hosts are behind a NAT
(see Appendix A of [21]) than enabling UDP connectivity in the same (see Appendix A of [27]) than enabling UDP connectivity in the same
scenarios. The happens because many of the currently deployed NATs scenarios. The happens because many of the currently deployed NATs
in video conferencing networks do not support the flow of TCP hand in video conferencing networks do not support the flow of TCP hand
shake packets seen in case of TCP simultaneous-open, either because shake packets seen in case of TCP simultaneous-open, either because
they do not allow incoming TCP SYN packets from an address to which a they do not allow incoming TCP SYN packets from an address to which a
SYN packet has been sent to recently, or because they do not properly SYN packet has been sent to recently, or because they do not properly
process the subsequent SYNACK. Implementing various techniques process the subsequent SYNACK. Implementing various techniques
advocated for candidate collection in [21] should increase the advocated for candidate collection in [27] should increase the
success probability, but many of these techniques require support success probability, but many of these techniques require support
from some network elements (e.g., from the NATs). Such support is from some network elements (e.g., from the NATs). Such support is
not common in enterprise firewalls and NATs. not common in enterprise NATs.
B.1.1.2. Teredo B.1.1.2. Teredo
Teredo [17] enables nodes located behind one or more IPv4 NATs to Teredo [23] enables nodes located behind one or more IPv4 NATs to
obtain IPv6 connectivity by tunneling packets over UDP. Teredo obtain IPv6 connectivity by tunneling packets over UDP. Teredo
extensions [19] provide additional capabilities to Teredo, including extensions [25] provide additional capabilities to Teredo, including
support for more types of NATs and support for more efficient support for more types of NATs and support for more efficient
communication. communication.
As defined, Teredo could be used to make BFCP work for the video As defined, Teredo could be used to make BFCP work for the video
conferencing use cases addressed in this draft. However, running the conferencing use cases addressed in this draft. However, running the
service requires the help of "Teredo servers" and "Teredo relays" service requires the help of "Teredo servers" and "Teredo relays"
[17]. These servers and relays generally do not exist in the [23]. These servers and relays generally do not exist in the
existing video conferencing deployments. It also requires IPv6 existing video conferencing deployments. It also requires IPv6
awareness on the endpoints. It should also be noted that ICMP6, as awareness on the endpoints. It should also be noted that ICMP6, as
used with Teredo to complete an initial protocol exchange and confirm used with Teredo to complete an initial protocol exchange and confirm
that the appropriate NAT bindings have been set up, is not a that the appropriate NAT bindings have been set up, is not a
conventional feature of IPv4 or even IPv6, and some currently conventional feature of IPv4 or even IPv6, and some currently
deployed IPv6 firewalls discard ICMP messages. As these networks deployed IPv6 firewalls discard ICMP messages. As these networks
continue to evolve and tackle the transaction to IPv6, Teredo servers continue to evolve and tackle the transaction to IPv6, Teredo servers
and relays may be deployed, making Teredo available as a suitable and relays may be deployed, making Teredo available as a suitable
alternative to BFCP over UDP. alternative to BFCP over UDP.
B.1.1.3. GUT B.1.1.3. GUT
GUT [22] attempts to facilitate tunneling over UDP by encapsulating GUT [28] attempts to facilitate tunneling over UDP by encapsulating
the native transport protocol and its payload (in general the whole the native transport protocol and its payload (in general the whole
IP payload) within a UDP packet destined to the well-known port IP payload) within a UDP packet destined to the well-known port
GUT_P. Unfortunately, it requires user-space TCP, for which there is GUT_P. Unfortunately, it requires user-space TCP, for which there is
not a readily available implementation, and creating one is a large not a readily available implementation, and creating one is a large
project in itself. This draft has expired and its future is still project in itself. This draft has expired and its future is still
not clear as it has not yet been adopted by a working group. not clear as it has not yet been adopted by a working group.
B.1.1.4. UPnP IGD B.1.1.4. UPnP IGD
Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on
skipping to change at page 85, line 46 skipping to change at page 87, line 28
to communicate with it. to communicate with it.
Many NATs do not support PMP. In those that do support it, it has Many NATs do not support PMP. In those that do support it, it has
similar issues with negotiation of multilayer NATs as UPnP. Video similar issues with negotiation of multilayer NATs as UPnP. Video
conferencing is used extensively in enterprise networks, and NAT PMP conferencing is used extensively in enterprise networks, and NAT PMP
is not generally available in enterprise-class routers. is not generally available in enterprise-class routers.
B.1.1.6. SCTP B.1.1.6. SCTP
It would be quite straight forward to specify a BFCP binding for SCTP It would be quite straight forward to specify a BFCP binding for SCTP
[20], and then tunnel SCTP over UDP in the use case described in [26], and then tunnel SCTP over UDP in the use case described in
Appendix B.1. SCTP is gaining some momentum currently. There is Appendix B.1. SCTP is gaining some momentum currently. There is
ongoing discussion in the RTCWeb WG regarding this approach. ongoing discussion in the RTCWeb WG regarding this approach.
However, this approach for tunneling over UDP was not mature enough However, this approach for tunneling over UDP was not mature enough
when considered and not even fully specified. when considered and not even fully specified.
B.1.1.7. BFCP over UDP transport B.1.1.7. BFCP over UDP transport
To overcome the problems with establishing TCP flows between BFCP To overcome the problems with establishing TCP flows between BFCP
entities, an alternative is to define UDP as an alternate transport entities, an alternative is to define UDP as an alternate transport
for BFCP, leveraging the same mechanisms in place for the RTP over for BFCP, leveraging the same mechanisms in place for the RTP over
UDP media streams for the BFCP communication. When using UDP as the UDP media streams for the BFCP communication. When using UDP as the
transport, it is recommended to follow the guidelines provided in transport, it is recommended to follow the guidelines provided in
[18]. [24].
Minor changes to the transaction model are introduced in that all Minor changes to the transaction model are introduced in that all
requests now have an appropriate response to complete the requests now have an appropriate response to complete the
transaction. The requests are sent with a retransmit timer transaction. The requests are sent with a retransmit timer
associated with the response to achieve reliability. This associated with the response to achieve reliability. This
alternative does not change the semantics of BFCP. It permits UDP as alternative does not change the semantics of BFCP. It permits UDP as
an alternate transport. an alternate transport.
Existing implementations, in the spirit of the approach detailed in Existing implementations, in the spirit of the approach detailed in
earlier versions of this draft, have demonstrated this approach to be earlier versions of this draft, have demonstrated this approach to be
 End of changes. 130 change blocks. 
297 lines changed or deleted 409 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/