draft-ietf-bfcpbis-rfc4582bis-14.txt   draft-ietf-bfcpbis-rfc4582bis-15.txt 
BFCPbis Working Group G. Camarillo BFCPbis Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: 4582 (if approved) K. Drage Obsoletes: 4582 (if approved) K. Drage
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: March 24, 2016 T. Kristensen Expires: April 16, 2016 T. Kristensen
Cisco Cisco
J. Ott J. Ott
Aalto University Aalto University
C. Eckel C. Eckel
Cisco Cisco
September 21, 2015 October 14, 2015
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-bfcpbis-rfc4582bis-14 draft-ietf-bfcpbis-rfc4582bis-15
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 March 24, 2016. This Internet-Draft will expire on April 16, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Floor Creation . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Floor Creation . . . . . . . . . . . . . . . . . . . . . 8
3.2. Obtaining Information to Contact a Floor Control Server . 9 3.2. Obtaining Information to Contact a Floor Control Server . 8
3.3. Obtaining Floor-Resource Associations . . . . . . . . . . 9 3.3. Obtaining Floor-Resource Associations . . . . . . . . . . 8
3.4. Privileges of Floor Control . . . . . . . . . . . . . . . 10 3.4. Privileges of Floor Control . . . . . . . . . . . . . . . 9
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 10 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 9
4.1. Floor Participant to Floor Control Server Interface . . . 11 4.1. Floor Participant to Floor Control Server Interface . . . 10
4.2. Floor Chair to Floor Control Server Interface . . . . . . 15 4.2. Floor Chair to Floor Control Server Interface . . . . . . 14
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. COMMON-HEADER Format . . . . . . . . . . . . . . . . . . . 16 5.1. COMMON-HEADER Format . . . . . . . . . . . . . . . . . . 15
5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . . 19 5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . 22 5.2.3. FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . 21
5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 22
5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 23 5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . 22
5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 24 5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . 23
5.2.6.1. Error-Specific Details for Error Code 4 . . . . . 25 5.2.6.1. Error-Specific Details for Error Code 4 . . . . . 24
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 . . . . . . . . . . . . . . . . . . . . . 26
5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . . 27 5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . 27
5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . . 28 5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . 27
5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 29 5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 28
5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . . 29 5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . 29
5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 30 5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 29
5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 31 5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 30
5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . . 32 5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . 31
5.2.17. FLOOR-REQUEST-STATUS . . . . . . . . . . . . . . . . . 32 5.2.17. FLOOR-REQUEST-STATUS . . . . . . . . . . . . . . . . 31
5.2.18. OVERALL-REQUEST-STATUS . . . . . . . . . . . . . . . . 33 5.2.18. OVERALL-REQUEST-STATUS . . . . . . . . . . . . . . . 32
5.3. Message Format . . . . . . . . . . . . . . . . . . . . . . 34 5.3. Message Format . . . . . . . . . . . . . . . . . . . . . 33
5.3.1. FloorRequest . . . . . . . . . . . . . . . . . . . . . 34 5.3.1. FloorRequest . . . . . . . . . . . . . . . . . . . . 33
5.3.2. FloorRelease . . . . . . . . . . . . . . . . . . . . . 34 5.3.2. FloorRelease . . . . . . . . . . . . . . . . . . . . 33
5.3.3. FloorRequestQuery . . . . . . . . . . . . . . . . . . 34 5.3.3. FloorRequestQuery . . . . . . . . . . . . . . . . . . 33
5.3.4. FloorRequestStatus . . . . . . . . . . . . . . . . . . 35 5.3.4. FloorRequestStatus . . . . . . . . . . . . . . . . . 34
5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 35 5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 34
5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . . 35 5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . 34
5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . . 36 5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . 35
5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 36 5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 35
5.3.9. ChairAction . . . . . . . . . . . . . . . . . . . . . 36 5.3.9. ChairAction . . . . . . . . . . . . . . . . . . . . . 35
5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . . 36 5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . 35
5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . 36
5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 38 5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 36
5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . . 38 5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . 37
5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38 5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 38 5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . 37
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . . 39 6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . 38
6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . 40 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . 39
6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . 41 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . 40
6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 41
6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . . 42 6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . 41
6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 44 6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 42
7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 44 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 43
8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 45 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 43
8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 45 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 44
8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 46 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 44
8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 46 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . 45
8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 46 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 45
8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 46 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . 46
9. Authentication and Authorization . . . . . . . . . . . . . . . 47 9. Authentication and Authorization . . . . . . . . . . . . . . 46
9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 48 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . 47
10. Floor Participant Operations . . . . . . . . . . . . . . . . . 48 10. Floor Participant Operations . . . . . . . . . . . . . . . . 48
10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 49 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . 48
10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 49 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . 48
10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 50 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . 49
10.1.3. Reception of a Subsequent FloorRequestStatus 10.1.3. Reception of a Subsequent FloorRequestStatus Message 50
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 . . . . . . . . . . . . . . . . 51
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 . . . . . . . . . . . . . . . . . . 53
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 . . . . . . . . . . . . . . . . 54
12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 55 12.1.3. Reception of a Subsequent FloorStatus Message . . . 55
12.1.3. Reception of a Subsequent FloorStatus Message . . . . 56 12.2. Requesting Information about Floor Requests . . . . . . 55
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 . . . . . . . . . . 56
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 . . . . . . . . . . . . . . . . 57
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 . . . . . . . . . . . . . . . 58
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 . . 59
13.1.1. Generating the First FloorRequestStatus Message . . . 60 13.1.2. Generation of Subsequent FloorRequestStatus Messages 60
13.1.2. Generation of Subsequent FloorRequestStatus 13.2. Reception of a FloorRequestQuery Message . . . . . . . . 61
Messages . . . . . . . . . . . . . . . . . . . . . . . 61 13.3. Reception of a UserQuery Message . . . . . . . . . . . . 63
13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 62 13.4. Reception of a FloorRelease Message . . . . . . . . . . 64
13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 64 13.5. Reception of a FloorQuery Message . . . . . . . . . . . 65
13.4. Reception of a FloorRelease Message . . . . . . . . . . . 65 13.5.1. Generation of the First FloorStatus Message . . . . 66
13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 66 13.5.2. Generation of Subsequent FloorStatus Messages . . . 67
13.5.1. Generation of the First FloorStatus Message . . . . . 67 13.6. Reception of a ChairAction Message . . . . . . . . . . . 68
13.5.2. Generation of Subsequent FloorStatus Messages . . . . 68 13.7. Reception of a Hello Message . . . . . . . . . . . . . . 69
13.6. Reception of a ChairAction Message . . . . . . . . . . . . 69 13.8. Error Message Generation . . . . . . . . . . . . . . . . 69
13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 70 14. Security Considerations . . . . . . . . . . . . . . . . . . . 70
13.8. Error Message Generation . . . . . . . . . . . . . . . . . 70 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
14. Security Considerations . . . . . . . . . . . . . . . . . . . 71 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . 71
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . 72
15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 72 15.3. Request Status Subregistry . . . . . . . . . . . . . . . 73
15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 73 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . 74
15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 74 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 75
15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 75 16.1. Extensions for an unreliable transport . . . . . . . . . 75
16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 76 16.2. Other changes . . . . . . . . . . . . . . . . . . . . . 76
16.1. Extensions for an unreliable transport . . . . . . . . . . 76 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77
16.2. Other changes . . . . . . . . . . . . . . . . . . . . . . 77 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 77
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78 18.1. Normative References . . . . . . . . . . . . . . . . . . 78
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 18.2. Informational References . . . . . . . . . . . . . . . . 79
18.1. Normative References . . . . . . . . . . . . . . . . . . . 79
18.2. Informational References . . . . . . . . . . . . . . . . . 79
Appendix A. Example Call Flows for BFCP over an Unreliable Appendix A. Example Call Flows for BFCP over an Unreliable
Transport . . . . . . . . . . . . . . . . . . . . . . 81 Transport . . . . . . . . . . . . . . . . . . . . . 81
Appendix B. Motivation for Supporting an Unreliable Transport . . 85 Appendix B. Motivation for Supporting an Unreliable Transport . 85
B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 85 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 85
B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 86 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 86
B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 86 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 87
B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . 87
B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 87
B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . 88
B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 88 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 88
B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 88 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . 88
B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 88 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89
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 [13] list a set of The Requirements for Floor Control Protocol [15] 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 45 skipping to change at page 6, line 50
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 BFCP Connection: A transport association between BFCP entities, used
to exchange BFCP messages. to exchange BFCP messages.
Transaction Failure Window: When communicating over an unreliable
transport, this is some period of time less than or equal to T1*2^4
(see Section 8.3). For reliable transports, this period of time is
unbounded.
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 [13]. resources in a conference following the requirements defined in [15].
Floor control complements other functions defined in the XCON Floor control complements other functions defined in the XCON
conferencing framework [14]. The floor control protocol BFCP defined conferencing framework [16]. 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 [14]. and are defined by other protocols [16].
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 10 skipping to change at page 8, line 20
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 [14]. Floor creation and termination are also outside described in [16]. 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 [18] can specify such floor- Conference control clients using CCMP [20] can specify such floor-
related settings in the <floor-information> element [17] of the to-be related settings in the <floor-information> element [19] of the to-be
created conference object provided in the body of a CCMP confRequest/ created conference object provided in the body of a CCMP confRequest/
create message issued to the conference control server. 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. This data includes the transport address to a floor control server. This data includes 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 [12] exchange, which is described in [9]. How to an SDP offer/answer [14] exchange, which is described in [10]. How
establish a connection to a BFCP floor control server outside the to establish a connection to a BFCP floor control server outside the
context of an offer/answer exchange when using a reliable transport context of an offer/answer exchange when using a reliable transport
is described in [3]. Other mechanisms are described in the XCON is described in [4]. Other mechanisms are described in the XCON
framework [14] (and other related documents). For unreliable framework [16] (and other related documents). For unreliable
transports, the use of an SDP offer/answer exchange is the only transports, the use of an SDP offer/answer exchange is the only
specified mechanism. specified mechanism.
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 [12] using different mechanisms, such as an SDP offer/answer [14]
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 [9]. associations is described in [10].
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 [14] (and other related documents). described in the XCON framework [16] (and other related documents).
According to the conferencing system policies, conference control According to the conferencing system policies, conference control
clients using CCMP [18] can modify the floor settings of a conference clients using CCMP [20] can modify the floor settings of a conference
by issuing CCMP confRequest/update messages providing the specific by issuing CCMP confRequest/update messages providing the specific
updates to the <floor-information> element of the target conference updates to the <floor-information> element of the target conference
object. More information about CCMP and BFCP interaction can be object. More information about CCMP and BFCP interaction can be
found in [19]. found in [21].
3.4. Privileges of Floor Control 3.4. Privileges of Floor Control
A participant whose floor request is granted has the right to use the A participant whose floor request is granted has the right to use the
resource or resources associated with the floor that was requested. resource or resources associated with the floor that was requested.
For example, the participant may have the right to send media over a For example, the participant may have the right to send media over a
particular audio stream. 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 [14]. discussed in the XCON Framework [16].
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
skipping to change at page 13, line 28 skipping to change at page 12, line 33
|<----------------------------------------------| |<----------------------------------------------|
Figure 2: Requesting and releasing a floor Figure 2: Requesting and releasing a floor
Figure 3 shows how a floor participant requests to be informed on the Figure 3 shows how a floor participant requests to be informed on the
status of a floor. The first FloorStatus message from the floor status of a floor. The first FloorStatus message from the floor
control server is the response to the FloorQuery message and, as control server is the response to the FloorQuery message and, as
such, has the same Transaction ID as the FloorQuery message. such, has the same Transaction ID as the FloorQuery message.
Subsequent FloorStatus messages consist of server-initiated Subsequent FloorStatus messages consist of server-initiated
transactions, and therefore their Transaction ID is 0. FloorStatus transactions, and therefore their Transaction ID is 0 given this
message (2) indicates that there are currently two floor requests for example uses a reliable transport. FloorStatus message (2) indicates
the floor whose Floor ID is 543. FloorStatus message (3) indicates that there are currently two floor requests for the floor whose Floor
that the floor requests with Floor Request ID 764 has been granted, ID is 543. FloorStatus message (3) indicates that the floor requests
and the floor request with Floor Request ID 635 is the first in the with Floor Request ID 764 has been granted, and the floor request
queue. FloorStatus message (4) indicates that the floor request with with Floor Request ID 635 is the first in the queue. FloorStatus
Floor Request ID 635 has been granted. message (4) indicates that the floor request with Floor Request ID
635 has been granted.
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorQuery | |(1) FloorQuery |
|Transaction ID: 257 | |Transaction ID: 257 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorStatus | |(2) FloorStatus |
skipping to change at page 17, line 5 skipping to change at page 16, line 5
5. Packet Format 5. Packet Format
BFCP packets consist of a 12-octet common header followed by BFCP packets consist of a 12-octet common header followed by
attributes. All the protocol values MUST be sent in network byte attributes. All the protocol values MUST be sent in network byte
order. order.
5.1. COMMON-HEADER Format 5.1. COMMON-HEADER Format
The following is the format of the common header. The following is the format of the common header.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |R|F| Res | Primitive | Payload Length | | Ver |R|F| Res | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+---- These fragment fields are never present
when using reliable transports
Figure 5: COMMON-HEADER format Figure 5: COMMON-HEADER format
Ver: This 3-bit field defines the version of BFCP that this message Ver: This 3-bit field defines the version of BFCP that this message
adheres to. This specification defines two versions: 1 and 2. The adheres to. This specification defines two versions: 1 and 2. The
version field MUST be set to 1 when using BFCP over a reliable version field MUST be set to 1 when using BFCP over a reliable
transport. The version field MUST be set to 2 when using BFCP over transport. The version field MUST be set to 2 when using BFCP over
an unreliable transport. If a floor control server receives a an unreliable transport. If a floor control server receives a
message with an unsupported version field value, and the extensions message with an unsupported version field value, the server MUST
in this document is supported, the receiving server MUST send an indicate it does not support the protocol version by sending an Error
Error message with parameter value 12 (Unsupported Version) to message with parameter value 12 (Unsupported Version). Note that
indicate this. Note that BFCP entities supporting only the [2] BFCP entities supporting only the [3] subset will not support this
subset will not support this parameter value. parameter value.
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 an unreliable transport. When cleared, it indicates of BFCP over an unreliable transport. When cleared, it indicates
that 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 a reliable transport, the with that request. When BFCP is used over a reliable transport, the
flag has no significance and MUST be cleared by the sender and MUST flag has no significance and MUST be cleared by the sender and MUST
be ignored by the receiver. be ignored by the receiver.
skipping to change at page 17, line 51 skipping to change at page 17, line 5
over an 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 a reliable transport, the flag flag is set). When BFCP is used over a reliable transport, the flag
has no significance and MUST be cleared by the sender and the flag has no significance and MUST be cleared by the sender and the flag
MUST be ignored by the receiver. In the latter case, the receiver MUST be ignored by the receiver. In the latter case, the receiver
should also process the COMMON-HEADER as not having the Fragment should also process the COMMON-HEADER as not having the Fragment
Offset and Fragment Length fields present. Offset and Fragment Length fields present.
Res: At this point, the 3 bits in the reserved field MUST be set to Res: The 3 bits in the reserved field MUST be set to zero by the
zero by the sender of the message and MUST be ignored 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:
+-------+-----------------------+--------------------+ +-------+-----------------------+--------------------------+
| Value | Primitive | Direction | | Value | Primitive | Direction |
+-------+-----------------------+--------------------+ +-------+-----------------------+--------------------------+
| 1 | FloorRequest | P -> S | | 1 | FloorRequest | P -> S |
| 2 | FloorRelease | P -> S | | 2 | FloorRelease | P -> S |
| 3 | FloorRequestQuery | P -> S ; Ch -> S | | 3 | FloorRequestQuery | P -> S ; Ch -> S |
| 4 | FloorRequestStatus | P <- S ; Ch <- S | | 4 | FloorRequestStatus | P <- S ; Ch <- S |
| 5 | UserQuery | P -> S ; Ch -> S | | 5 | UserQuery | P -> S ; Ch -> S |
| 6 | UserStatus | P <- S ; Ch <- S | | 6 | UserStatus | P <- S ; Ch <- S |
| 7 | FloorQuery | P -> S ; Ch -> S | | 7 | FloorQuery | P -> S ; Ch -> S |
| 8 | FloorStatus | P <- S ; Ch <- S | | 8 | FloorStatus | P <- S ; Ch <- S |
| 9 | ChairAction | Ch -> S | | 9 | ChairAction | Ch -> S |
| 10 | ChairActionAck | Ch <- S | | 10 | ChairActionAck | Ch <- S |
| 11 | Hello | P -> S ; Ch -> S | | 11 | Hello | P -> S ; Ch -> S |
| 12 | HelloAck | P <- S ; Ch <- S | | 12 | HelloAck | P <- S ; Ch <- S |
| 13 | Error | P <- S ; Ch <- S | | 13 | Error | P <- S ; Ch <- S |
| 14 | FloorRequestStatusAck | P -> S ; Ch -> S | | 14 | FloorRequestStatusAck | P -> S ; Ch -> S |
| 15 | FloorStatusAck | P -> S ; Ch -> S | | 15 | FloorStatusAck | P -> S ; Ch -> S |
| 16 | Goodbye | P -> S ; Ch -> S ; | | 16 | Goodbye | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S | | | | P <- S ; Ch <- S |
| 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 MUST send an Error message with parameter value, the receiving server MUST send an Error message with parameter
value 13 (Incorrect Message Length) to indicate this. value 13 (Incorrect Message Length) to indicate this and then discard
the message. Other entities that receive a message with an incorrect
length MUST discard the message.
Note: BFCP is designed to achieve small message size, as explained Note: BFCP is designed to achieve small message size, as explained
in Section 1, and BFCP entities are REQUIRED to keep the BFCP in Section 1, and BFCP entities are required to keep the BFCP
message size smaller than the size limited by the 16-bit Payload message size smaller than the size limited by the 16-bit Payload
Length field. To convey information not strictly related to floor Length field. To convey information not strictly related to floor
control, other protocols should be used such as the XCON framework control, other protocols should be used such as the XCON framework
(cf. Section 3). (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 to which the message belongs. (Note that the use of
predictable conference identifiers in conjunction with a non-secure
transport protocol makes BFCP more susceptible to forged request and
response messages. See the Security Considerations section regarding
the recommendation to use a secure transport.)
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
the User ID field, is generally mapped to the identity used by the the User ID field, is generally mapped to the identity used by the
same participant in the session establishment protocol (e.g., in same participant in the session establishment protocol (e.g., in
SIP). The way this mapping is performed is outside the scope of SIP). The way this mapping is performed is outside the scope of
this specification. this specification.
Fragment Offset: This optional field is present only if the F flag is Fragment Offset: This optional field is present only if the F flag is
set and contains a 16-bit value that specifies the number of 4-octet set and contains a 16-bit value that specifies the number of 4-octet
units contained in previous fragments, excluding the common header. units contained in previous fragments, excluding the common header.
Fragment Length: This optional field is present only if the F flag is Fragment Length: This optional field is present only if the F flag is
set and contains a 16-bit value that specifies the number of 4-octet set and contains a 16-bit value that specifies the number of 4-octet
units contained in this fragment, excluding the common header. units contained in this fragment, excluding the common header. BFCP
entities that receive message fragments that, individually or
collectively, exceed the Payload Length value MUST discard the
message. Additionally, if the receiver is a Floor Control Server, it
must also send an Error message with parameter value 13 (Incorrect
Message Length)
5.2. Attribute Format 5.2. Attribute Format
BFCP attributes are encoded in TLV (Type-Length-Value) format. BFCP attributes are encoded in TLV (Type-Length-Value) format.
Attributes are 32-bit aligned. Attributes are 32-bit aligned.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |M| Length | | | Type |M| Length | |
skipping to change at page 20, line 22 skipping to change at page 20, line 8
attributes. attributes.
Note that extension attributes defined in the future may define Note that extension attributes defined in the future may define
new attribute formats. new attribute formats.
The following attribute types are defined: The following attribute types are defined:
+------+---------------------------+---------------+ +------+---------------------------+---------------+
| Type | Attribute | Format | | Type | Attribute | Format |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
| 1 | BENEFICIARY-ID | Unsigned16 | | 1 | BENEFICIARY-ID | Unsigned16 |
| 2 | FLOOR-ID | Unsigned16 | | 2 | FLOOR-ID | Unsigned16 |
| 3 | FLOOR-REQUEST-ID | Unsigned16 | | 3 | FLOOR-REQUEST-ID | Unsigned16 |
| 4 | PRIORITY | OctetString16 | | 4 | PRIORITY | OctetString16 |
| 5 | REQUEST-STATUS | OctetString16 | | 5 | REQUEST-STATUS | OctetString16 |
| 6 | ERROR-CODE | OctetString | | 6 | ERROR-CODE | OctetString |
| 7 | ERROR-INFO | OctetString | | 7 | ERROR-INFO | OctetString |
| 8 | PARTICIPANT-PROVIDED-INFO | OctetString | | 8 | PARTICIPANT-PROVIDED-INFO | OctetString |
| 9 | STATUS-INFO | OctetString | | 9 | STATUS-INFO | OctetString |
| 10 | SUPPORTED-ATTRIBUTES | OctetString | | 10 | SUPPORTED-ATTRIBUTES | OctetString |
| 11 | SUPPORTED-PRIMITIVES | OctetString | | 11 | SUPPORTED-PRIMITIVES | OctetString |
| 12 | USER-DISPLAY-NAME | OctetString | | 12 | USER-DISPLAY-NAME | OctetString |
| 13 | USER-URI | OctetString | | 13 | USER-URI | OctetString |
| 14 | BENEFICIARY-INFORMATION | Grouped | | 14 | BENEFICIARY-INFORMATION | Grouped |
| 15 | FLOOR-REQUEST-INFORMATION | Grouped | | 15 | FLOOR-REQUEST-INFORMATION | Grouped |
| 16 | REQUESTED-BY-INFORMATION | Grouped | | 16 | REQUESTED-BY-INFORMATION | Grouped |
| 17 | FLOOR-REQUEST-STATUS | Grouped | | 17 | FLOOR-REQUEST-STATUS | Grouped |
| 18 | OVERALL-REQUEST-STATUS | Grouped | | 18 | OVERALL-REQUEST-STATUS | Grouped |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
Table 2: BFCP attributes Table 2: BFCP attributes
M: The 'M' bit, known as the Mandatory bit, indicates whether support M: The 'M' bit, known as the Mandatory bit, indicates whether support
of the attribute is required. If a Floor Control Server receives an of the attribute is required. If a Floor Control Server receives an
unrecognized attribute with the 'M' bit set the server MUST send an unrecognized attribute with the 'M' bit set the server MUST send an
Error message with parameter value 4 (Unknown Mandatory Attribute) to Error message with parameter value 4 (Unknown Mandatory Attribute) to
indicate this. The 'M' bit is significant for extension attributes indicate this. The 'M' bit is significant for extension attributes
defined in other documents only. All attributes specified in this defined in other documents only. All attributes specified in this
document MUST be understood by the receiver so that the setting of document MUST be understood by the receiver so that the setting of
the 'M' bit is irrelevant for these. In all other cases, the the 'M' bit is irrelevant for these. Unrecognized attributes, such
unrecognized attribute is ignored but the message is processed. as those that might be specified in future extensions, that do not
have the "M" bit set are ignored, but the message is processed.
Length: This 8-bit field contains the length of the attribute in Length: This 8-bit field contains the length of the attribute in
octets, excluding any padding defined for specific attributes. The octets, excluding any padding defined for specific attributes. The
length of attributes that are not grouped includes the Type, 'M' bit, length of attributes that are not grouped includes the Type, 'M' bit,
and Length fields. The Length in grouped attributes is the length of and Length fields. The Length in grouped attributes is the length of
the grouped attribute itself (including Type, 'M' bit, and Length the grouped attribute itself (including Type, 'M' bit, and Length
fields) plus the total length (including padding) of all the included fields) plus the total length (including padding) of all the included
attributes. attributes.
Attribute Contents: The contents of the different attributes are Attribute Contents: The contents of the different attributes are
skipping to change at page 22, line 50 skipping to change at page 22, line 38
+-------+----------+ +-------+----------+
| 0 | Lowest | | 0 | Lowest |
| 1 | Low | | 1 | Low |
| 2 | Normal | | 2 | Normal |
| 3 | High | | 3 | High |
| 4 | Highest | | 4 | Highest |
+-------+----------+ +-------+----------+
Table 3: Priority values Table 3: Priority values
Reserved: At this point, the 13 bits in the reserved field MUST be Reserved: The 13 bits in the reserved field MUST be set to zero by
set to zero by the sender of the message and MUST be ignored by the the sender of the message and MUST be ignored by the receiver.
receiver.
5.2.5. REQUEST-STATUS 5.2.5. REQUEST-STATUS
The following is the format of the REQUEST-STATUS attribute. The following is the format of the REQUEST-STATUS attribute.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 42 skipping to change at page 25, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R| | Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Unknown attributes format Figure 13: Unknown attributes format
Unknown Type: These 7-bit fields contain the Types of the attributes Unknown Type: These 7-bit fields contain the Types of the attributes
(which were present in the message that triggered the Error message) (which were present in the message that triggered the Error message)
that were unknown to the receiver. that were unknown to the receiver.
R: At this point, this bit is reserved. It MUST be set to zero by R: This bit is reserved. It MUST be set to zero by the sender of the
the sender of the message and MUST be ignored by the receiver. message and MUST be ignored by the receiver.
5.2.7. ERROR-INFO 5.2.7. ERROR-INFO
The following is the format of the ERROR-INFO attribute. The following is the format of the ERROR-INFO attribute.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 1|M| Length | | |0 0 0 0 1 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: ERROR-INFO format Figure 14: ERROR-INFO format
Text: This field contains UTF-8 [8] encoded text. Text: This field contains UTF-8 [9] encoded text.
In some situations, the contents of the Text field may be generated In some situations, the contents of the Text field may be generated
by an automaton. If this automaton has information about the by an automaton. If this automaton has information about the
preferred language of the receiver of a particular ERROR-INFO preferred language of the receiver of a particular ERROR-INFO
attribute, it MAY use this language to generate the Text field. attribute, it MAY use this language to generate the Text field.
Padding: One, two, or three octets of padding added so that the Padding: One, two, or three octets of padding added so that the
contents of the ERROR-INFO attribute is 32-bit aligned. The Padding contents of the ERROR-INFO attribute is 32-bit aligned. The Padding
bits MUST be set to zero by the sender and MUST be ignored by the bits MUST be set to zero by the sender and MUST be ignored by the
receiver. If the attribute is already 32-bit aligned, no padding is receiver. If the attribute is already 32-bit aligned, no padding is
skipping to change at page 26, line 49 skipping to change at page 26, line 25
|0 0 0 1 0 0 0|M| Length | | |0 0 0 1 0 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: PARTICIPANT-PROVIDED-INFO format Figure 15: PARTICIPANT-PROVIDED-INFO format
Text: This field contains UTF-8 [8] encoded text. Text: This field contains UTF-8 [9] encoded text.
Padding: One, two, or three octets of padding added so that the Padding: One, two, or three octets of padding added so that the
contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit
aligned. The Padding bits MUST be set to zero by the sender and MUST aligned. The Padding bits MUST be set to zero by the sender and MUST
be ignored by the receiver. If the attribute is already 32-bit be ignored by the receiver. If the attribute is already 32-bit
aligned, no padding is needed. aligned, no padding is needed.
5.2.9. STATUS-INFO 5.2.9. STATUS-INFO
The following is the format of the STATUS-INFO attribute. The following is the format of the STATUS-INFO attribute.
skipping to change at page 27, line 26 skipping to change at page 26, line 50
|0 0 0 1 0 0 1|M| Length | | |0 0 0 1 0 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: STATUS-INFO format Figure 16: STATUS-INFO format
Text: This field contains UTF-8 [8] encoded text. Text: This field contains UTF-8 [9] encoded text.
In some situations, the contents of the Text field may be generated In some situations, the contents of the Text field may be generated
by an automaton. If this automaton has information about the by an automaton. If this automaton has information about the
preferred language of the receiver of a particular STATUS-INFO preferred language of the receiver of a particular STATUS-INFO
attribute, it MAY use this language to generate the Text field. attribute, it MAY use this language to generate the Text field.
Padding: One, two, or three octets of padding added so that the Padding: One, two, or three octets of padding added so that the
contents of the STATUS-INFO attribute is 32-bit aligned. The Padding contents of the STATUS-INFO attribute is 32-bit aligned. The Padding
bits MUST be set to zero by the sender and MUST be ignored by the bits MUST be set to zero by the sender and MUST be ignored by the
receiver. If the attribute is already 32-bit aligned, no padding is receiver. If the attribute is already 32-bit aligned, no padding is
skipping to change at page 31, line 5 skipping to change at page 30, line 16
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 0|M| Length | Beneficiary ID | |0 0 0 1 1 1 0|M| Length | Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: BENEFICIARY-INFORMATION-HEADER format Figure 21: BENEFICIARY-INFORMATION-HEADER format
Beneficiary ID: This field contains a 16-bit value that uniquely Beneficiary ID: This field contains a 16-bit value that uniquely
identifies a user within a conference. identifies a user within a conference.
The following is the ABNF (Augmented Backus-Naur Form) [4] of the The following is the ABNF (Augmented Backus-Naur Form) [5] of the
BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE
refers to extension attributes that may be defined in the future.) refers to extension attributes that may be defined in the future.)
BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER
[USER-DISPLAY-NAME] [USER-DISPLAY-NAME]
[USER-URI] [USER-URI]
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 22: BENEFICIARY-INFORMATION format Figure 22: BENEFICIARY-INFORMATION format
5.2.15. FLOOR-REQUEST-INFORMATION 5.2.15. FLOOR-REQUEST-INFORMATION
The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as FLOOR-REQUEST- consists of a header, which is referred to as FLOOR-REQUEST-
INFORMATION-HEADER, followed by a sequence of attributes. The INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: following is the format of the FLOOR-REQUEST-INFORMATION-HEADER:
skipping to change at page 31, line 37 skipping to change at page 31, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format
Floor Request ID: This field contains a 16-bit value that identifies Floor Request ID: This field contains a 16-bit value that identifies
a floor request at the floor control server. a floor request at the floor control server.
The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.) may be defined in the future.)
FLOOR-REQUEST-INFORMATION = FLOOR-REQUEST-INFORMATION-HEADER
FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER)
[OVERALL-REQUEST-STATUS] [OVERALL-REQUEST-STATUS]
1*(FLOOR-REQUEST-STATUS) 1*FLOOR-REQUEST-STATUS
[BENEFICIARY-INFORMATION] [BENEFICIARY-INFORMATION]
[REQUESTED-BY-INFORMATION] [REQUESTED-BY-INFORMATION]
[PRIORITY] [PRIORITY]
[PARTICIPANT-PROVIDED-INFO] [PARTICIPANT-PROVIDED-INFO]
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 24: FLOOR-REQUEST-INFORMATION format Figure 24: FLOOR-REQUEST-INFORMATION format
5.2.16. REQUESTED-BY-INFORMATION 5.2.16. REQUESTED-BY-INFORMATION
The REQUESTED-BY-INFORMATION attribute is a grouped attribute that The REQUESTED-BY-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as REQUESTED-BY- consists of a header, which is referred to as REQUESTED-BY-
INFORMATION-HEADER, followed by a sequence of attributes. The INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the REQUESTED-BY-INFORMATION-HEADER: following is the format of the REQUESTED-BY-INFORMATION-HEADER:
skipping to change at page 32, line 27 skipping to change at page 31, line 37
Figure 25: REQUESTED-BY-INFORMATION-HEADER format Figure 25: REQUESTED-BY-INFORMATION-HEADER format
Requested-by ID: This field contains a 16-bit value that uniquely Requested-by ID: This field contains a 16-bit value that uniquely
identifies a user within a conference. identifies a user within a conference.
The following is the ABNF of the REQUESTED-BY-INFORMATION grouped The following is the ABNF of the REQUESTED-BY-INFORMATION grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.) may be defined in the future.)
REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER) REQUESTED-BY-INFORMATION = REQUESTED-BY-INFORMATION-HEADER
[USER-DISPLAY-NAME] [USER-DISPLAY-NAME]
[USER-URI] [USER-URI]
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 26: REQUESTED-BY-INFORMATION format Figure 26: REQUESTED-BY-INFORMATION format
5.2.17. FLOOR-REQUEST-STATUS 5.2.17. FLOOR-REQUEST-STATUS
The FLOOR-REQUEST-STATUS attribute is a grouped attribute that The FLOOR-REQUEST-STATUS attribute is a grouped attribute that
consists of a header, which is referred to as FLOOR-REQUEST-STATUS- consists of a header, which is referred to as FLOOR-REQUEST-STATUS-
HEADER, followed by a sequence of attributes. The following is the HEADER, followed by a sequence of attributes. The following is the
format of the FLOOR-REQUEST-STATUS-HEADER: format of the FLOOR-REQUEST-STATUS-HEADER:
skipping to change at page 33, line 10 skipping to change at page 32, line 20
Figure 27: FLOOR-REQUEST-STATUS-HEADER format Figure 27: FLOOR-REQUEST-STATUS-HEADER format
Floor ID: this field contains a 16-bit value that uniquely identifies Floor ID: this field contains a 16-bit value that uniquely identifies
a floor within a conference. a floor within a conference.
The following is the ABNF of the FLOOR-REQUEST-STATUS grouped The following is the ABNF of the FLOOR-REQUEST-STATUS grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.) may be defined in the future.)
FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) FLOOR-REQUEST-STATUS = FLOOR-REQUEST-STATUS-HEADER
[REQUEST-STATUS] [REQUEST-STATUS]
[STATUS-INFO] [STATUS-INFO]
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 28: FLOOR-REQUEST-STATUS format Figure 28: FLOOR-REQUEST-STATUS format
5.2.18. OVERALL-REQUEST-STATUS 5.2.18. OVERALL-REQUEST-STATUS
The OVERALL-REQUEST-STATUS attribute is a grouped attribute that The OVERALL-REQUEST-STATUS attribute is a grouped attribute that
consists of a header, which is referred to as OVERALL-REQUEST-STATUS- consists of a header, which is referred to as OVERALL-REQUEST-STATUS-
HEADER, followed by a sequence of attributes. The following is the HEADER, followed by a sequence of attributes. The following is the
format of the OVERALL-REQUEST-STATUS-HEADER: format of the OVERALL-REQUEST-STATUS-HEADER:
skipping to change at page 33, line 38 skipping to change at page 33, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: OVERALL-REQUEST-STATUS-HEADER format Figure 29: OVERALL-REQUEST-STATUS-HEADER format
Floor Request ID: this field contains a 16-bit value that identifies Floor Request ID: this field contains a 16-bit value that identifies
a floor request at the floor control server. a floor request at the floor control server.
The following is the ABNF of the OVERALL-REQUEST-STATUS grouped The following is the ABNF of the OVERALL-REQUEST-STATUS grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.) may be defined in the future.)
OVERALL-REQUEST-STATUS = OVERALL-REQUEST-STATUS-HEADER
OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER)
[REQUEST-STATUS] [REQUEST-STATUS]
[STATUS-INFO] [STATUS-INFO]
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 30: OVERALL-REQUEST-STATUS format Figure 30: OVERALL-REQUEST-STATUS format
5.3. Message Format 5.3. Message Format
This section contains the normative ABNF (Augmented Backus-Naur Form) This section contains the normative ABNF (Augmented Backus-Naur Form)
[4] of the BFCP messages. Extension attributes that may be defined [5] of the BFCP messages. Extension attributes that may be defined
in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.
5.3.1. FloorRequest 5.3.1. FloorRequest
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. The following is the format of the to the floor control server. The following is the format of the
FloorRequest message: FloorRequest message:
FloorRequest = (COMMON-HEADER) FloorRequest = COMMON-HEADER
1*(FLOOR-ID) 1*FLOOR-ID
[BENEFICIARY-ID] [BENEFICIARY-ID]
[PARTICIPANT-PROVIDED-INFO] [PARTICIPANT-PROVIDED-INFO]
[PRIORITY] [PRIORITY]
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 31: FloorRequest format Figure 31: FloorRequest format
5.3.2. FloorRelease 5.3.2. FloorRelease
Floor participants release a floor by sending a FloorRelease message Floor participants release a floor by sending a FloorRelease message
to the floor control server. Floor participants also use the to the floor control server. Floor participants also use the
FloorRelease message to cancel pending floor requests. The following FloorRelease message to cancel pending floor requests. The following
is the format of the FloorRelease message: is the format of the FloorRelease message:
FloorRelease = (COMMON-HEADER) FloorRelease = COMMON-HEADER
(FLOOR-REQUEST-ID) FLOOR-REQUEST-ID
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 32: FloorRelease format Figure 32: FloorRelease format
5.3.3. FloorRequestQuery 5.3.3. FloorRequestQuery
Floor participants and floor chairs request information about a floor Floor participants and floor chairs request information about a floor
request by sending a FloorRequestQuery message to the floor control request by sending a FloorRequestQuery message to the floor control
server. The following is the format of the FloorRequestQuery server. The following is the format of the FloorRequestQuery
message: message:
FloorRequestQuery = (COMMON-HEADER) FloorRequestQuery = COMMON-HEADER
(FLOOR-REQUEST-ID) FLOOR-REQUEST-ID
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 33: FloorRequestQuery format Figure 33: FloorRequestQuery format
5.3.4. FloorRequestStatus 5.3.4. FloorRequestStatus
The floor control server informs floor participants and floor chairs The floor control server informs floor participants and floor chairs
about the status of their floor requests by sending them about the status of their floor requests by sending them
FloorRequestStatus messages. The following is the format of the FloorRequestStatus messages. The following is the format of the
FloorRequestStatus message: FloorRequestStatus message:
FloorRequestStatus = (COMMON-HEADER) FloorRequestStatus = COMMON-HEADER
(FLOOR-REQUEST-INFORMATION) FLOOR-REQUEST-INFORMATION
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 34: FloorRequestStatus format Figure 34: FloorRequestStatus format
5.3.5. UserQuery 5.3.5. UserQuery
Floor participants and floor chairs request information about a Floor participants and floor chairs request information about a
participant and the floor requests related to this participant by participant and the floor requests related to this participant by
sending a UserQuery message to the floor control server. The sending a UserQuery message to the floor control server. The
following is the format of the UserQuery message: following is the format of the UserQuery message:
UserQuery = (COMMON-HEADER) UserQuery = COMMON-HEADER
[BENEFICIARY-ID] [BENEFICIARY-ID]
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 35: UserQuery format Figure 35: UserQuery format
5.3.6. UserStatus 5.3.6. UserStatus
The floor control server provides information about participants and The floor control server provides information about participants and
their related floor requests to floor participants and floor chairs their related floor requests to floor participants and floor chairs
by sending them UserStatus messages. The following is the format of by sending them UserStatus messages. The following is the format of
the UserStatus message: the UserStatus message:
UserStatus = (COMMON-HEADER) UserStatus = COMMON-HEADER
[BENEFICIARY-INFORMATION] [BENEFICIARY-INFORMATION]
*(FLOOR-REQUEST-INFORMATION) *FLOOR-REQUEST-INFORMATION
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 36: UserStatus format Figure 36: UserStatus format
5.3.7. FloorQuery 5.3.7. FloorQuery
Floor participants and floor chairs request information about a floor Floor participants and floor chairs request information about a floor
or floors by sending a FloorQuery message to the floor control or floors by sending a FloorQuery message to the floor control
server. The following is the format of the FloorRequest message: server. The following is the format of the FloorQuery message:
FloorQuery = (COMMON-HEADER) FloorQuery = COMMON-HEADER
*(FLOOR-ID) *FLOOR-ID
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 37: FloorQuery format Figure 37: FloorQuery format
5.3.8. FloorStatus 5.3.8. FloorStatus
The floor control server informs floor participants and floor chairs The floor control server informs floor participants and floor chairs
about the status (e.g., the current holder) of a floor by sending about the status (e.g., the current holder) of a floor by sending
them FloorStatus messages. The following is the format of the them FloorStatus messages. The following is the format of the
FloorStatus message: FloorStatus message:
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
them ChairAction messages. The following is the format of the them ChairAction messages. The following is the format of the
ChairAction 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
message by sending a ChairActionAck message. The following is the message by sending a ChairActionAck message. The following is the
format of the ChairActionAck message: format of the ChairActionAck message:
ChairActionAck = (COMMON-HEADER) ChairActionAck = COMMON-HEADER
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 40: ChairActionAck format Figure 40: ChairActionAck format
5.3.11. Hello 5.3.11. Hello
Floor participants and floor chairs check the liveliness of floor Floor participants and floor chairs MAY check the liveliness of floor
control servers by sending a Hello message. The following is the control servers by sending a Hello message. Additionally, clients
format of the Hello message: communicating with a floor control server over a an unreliable
transport use the Hello message to initiate communication with the
server. The following is the format of the Hello message:
Hello = (COMMON-HEADER) Hello = COMMON-HEADER
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 41: Hello format Figure 41: Hello format
5.3.12. HelloAck 5.3.12. HelloAck
Floor control servers confirm that they are alive on reception of a Floor control servers confirm that they are alive on reception of a
Hello message by sending a HelloAck message. The following is the Hello message by sending a HelloAck message. The following is the
format of the HelloAck message: format of the HelloAck message:
HelloAck = (COMMON-HEADER) HelloAck = COMMON-HEADER
(SUPPORTED-PRIMITIVES) SUPPORTED-PRIMITIVES
(SUPPORTED-ATTRIBUTES) SUPPORTED-ATTRIBUTES
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 42: HelloAck format Figure 42: HelloAck format
5.3.13. Error 5.3.13. Error
Floor control servers inform floor participants and floor chairs Floor control servers inform floor participants and floor chairs
about errors processing requests by sending them Error messages. The about errors processing requests by sending them Error messages. The
following is the format of the Error message: following is the format of the Error message:
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 an unreliable transport, floor participants When communicating over an unreliable transport, floor participants
and chairs acknowledge the receipt of a subsequent FloorRequestStatus and chairs acknowledge the receipt of a subsequent FloorRequestStatus
message from the floor control server (cf. Section 13.1.2) by sending message from the floor control server (cf. Section 13.1.2) by
a FloorRequestStatusAck message. The following is the format of the sending a FloorRequestStatusAck message. The following is the format
FloorRequestStatusAck message: of the FloorRequestStatusAck message:
FloorRequestStatusAck = (COMMON-HEADER) FloorRequestStatusAck = (COMMON-HEADER)
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 44: FloorRequestStatusAck format Figure 44: FloorRequestStatusAck format
5.3.15. FloorStatusAck 5.3.15. FloorStatusAck
When communicating over an unreliable transport, floor participants When communicating over an unreliable transport, floor participants
and chairs acknowledge the receipt of a subsequent FloorStatus and chairs acknowledge the receipt of a subsequent FloorStatus
message from the floor control server (cf. Section 13.5.2) by sending message from the floor control server (cf. Section 13.5.2) by
a FloorStatusAck message. The following is the format of the sending a FloorStatusAck message. The following is the format of the
FloorStatusAck message: 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
transmission of a Goodbye. The following is the format of the transmission of a Goodbye. The following is the format of the
Goodbye message: Goodbye message:
Goodbye = (COMMON-HEADER) Goodbye = (COMMON-HEADER)
*(EXTENSION-ATTRIBUTE) *EXTENSION-ATTRIBUTE
Figure 46: Goodbye format Figure 46: Goodbye format
5.3.17. GoodbyeAck 5.3.17. GoodbyeAck
BFCP entities communicating over an unreliable transport acknowledge BFCP entities communicating over an unreliable transport acknowledge
the receipt of a Goodbye message from a peer. The following is the the receipt of a Goodbye message from a peer. The following is the
format of the GoodbyeAck message: format of the GoodbyeAck message:
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
the information the clients obtain for how to to contact the floor the information the clients obtain for how to to contact the floor
control server, as described in Section 3.2. Two transports are control server, as described in Section 3.2. Two transports are
supported: TCP, appropriate where connectivity is not impeded by supported: TCP, appropriate where connectivity is not impeded by
network elements such as NAT devices or media relays; and UDP for network elements such as NAT devices or media relays; and UDP for
skipping to change at page 40, line 20 skipping to change at page 39, line 7
cancel them) while the TCP connection is reestablished. cancel them) while the TCP connection is reestablished.
If a client wishes to end its BFCP connection with a floor control If a client wishes to end its BFCP connection with a floor control
server, the client closes (i.e., a graceful close) the TCP connection server, the client closes (i.e., a graceful close) the TCP connection
towards the floor control server. If a floor control server wishes towards the floor control server. If a floor control server wishes
to end its BFCP connection with a client (e.g., the Focus of the 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.
In cases where a BFCP entity reestablishes a connection due to
protocol errors as described above, the entity SHOULD NOT repeatedly
reestablish the connection. Rather, if the same protocol errors
persist, the entity MUST cease attempts and SHOULD report the error
to the human user and/or log the event. This does not preclude the
entity from reestablishing a connection when facing a different set
of errors. That said, entities MUST avoid overloading the server
with reestablishment requests. A connection MUST NOT be
reestablished too frequently. The frequency is a matter of
implementation, but SHOULD NOT be attempted more than once in a 30
second period of time.
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 keep large BFCP messages from BFCP message or message fragment. To keep large BFCP messages from
being fragmented at the IP layer, the fragmentation of BFCP messages being fragmented at the IP layer, the fragmentation of BFCP messages
that exceed the path MTU size is performed at the BFCP level. that exceed the path MTU size is performed at the BFCP level.
Considerations related to fragmentation are covered in Section 6.2.3. Considerations related to fragmentation are covered in Section 6.2.3.
The message format for BFCP messages is the same regardless of The message format for BFCP messages is the same regardless of
whether the messages are sent in UDP datagrams or over a TCP stream. 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
sending a Hello message. The floor control server responds to the sending a Hello message. The floor control server responds to the
Hello message with a HelloAck message. The client considers the Hello message with a HelloAck message. The client considers the
floor control service as present and available only upon receiving floor control service as present and available only upon receiving
the HelloAck message. Situations where the floor control service is the HelloAck message. The behavior when timers fire, including the
considered to have become unavailable due to ICMP messages are determination that a connection is broken, is described in
described in Section 6.2.2 and the behavior when timers fire is Section 8.3.
described in Section 8.3.
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 forms a client transaction that expects an acknowledgement or chair forms a client transaction that expects an acknowledgement
message back from the floor control server within a retransmission message back from the floor control server within a transaction
window. Concordantly, messages sent by the floor control server that failure window. Concordantly, messages sent by the floor control
initiate new transactions (e.g., FloorStatus announcements as part of server that initiate new transactions (e.g., FloorStatus
a FloorQuery subscription) require acknowledgement messages from the announcements as part of a FloorQuery subscription) require
floor participant and chair entities to which they were sent. acknowledgement messages from the 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 MUST send an Error message with parameter value 10 receiving server MUST 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,
given that it is possible to parse the received message to such an given that it is possible to parse the received message to such an
extent that an Error message may be built. extent that an Error message may be built.
Entities MUST have at most one outstanding request transaction per Entities MUST have at most one outstanding request transaction per
peer at any one time. Implicit subscriptions occur for a client- peer at any one time. Implicit subscriptions occur for a client-
initiated request transaction whose acknowledgement is implied by the initiated request transaction whose acknowledgement is implied by the
skipping to change at page 41, line 44 skipping to change at page 40, line 45
server, it is REQUIRED that the client send a Goodbye message to server, it is REQUIRED 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 connection 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 REQUIRED that client has been kicked out from the conference), it is REQUIRED that
the floor control server send a Goodbye message towards the client. the floor control server send a Goodbye message towards the client.
6.2.1. Congestion Control 6.2.1. Congestion Control
BFCP may be characterized to generate "low data-volume" traffic, per BFCP may be characterized to generate "low data-volume" traffic, per
the classification in [26]. Nevertheless is it necessary to ensure the classification in [13]. 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 Section 6.2, within the same BFCP BFCP over UDP. As described in Section 6.2, within the same BFCP
connection, every entity - client or server - is only allowed to send connection, every entity - client or server - is only allowed to send
one request at a time, and await the acknowledging response. This one request at a time, and await the acknowledging response. This
way at most one datagram is sent per RTT given the message is not way at most one datagram is sent per RTT given the message is not
lost during transmission. In case the message is lost, the request lost during transmission. In case the message is lost, the request
retransmission timer T1 specified in Section 8.3.1 will fire and the retransmission timer T1 specified in Section 8.3.1 will fire and the
message is retransmitted up to three times, in addition to the message is retransmitted up to three times, in addition to the
original transmission of the message. The default initial interval original transmission of the message. The default initial interval
MUST be set to 500ms and the interval MUST be doubled after each MUST be set to 500ms, but is adjusted dynamically as described in
retransmission attempt. This is identical to the specification of Section 8.3.1. The interval MUST be doubled after each
the timer A and its initial value T1 in SIP as described in Section retransmission attempt. This is similar to the specification of the
17.1.1.2 of [16]. timer A and its initial value T1 in SIP as described in
Section 17.1.1.2 of [18], except that the value of T1 in this
protocol is not fixed from one transaction to another.
6.2.2. ICMP Error Handling 6.2.2. ICMP Error Handling
If a BFCP entity receives an ICMP port unreachable message mid- ICMP is not used with unreliable transports due to risks asociated
connection, the entity MUST treat the BFCP connection as closed with off-path attacks. Any ICMP messages received over an unreliable
(e.g., an implicit Goodbye message from the peer). The entity MAY transport MUST be ignored.
attempt to re-establish the BFCP connection afresh. The new BFCP
connection will appear as originating from a wholly new floor
participant, chair or floor control server with all state previously
held about that participant lost.
Informational note: The recommendation to treat the connection as
closed in this case, stems from the fact that the peer entities
cannot rely on IP and port tuple to uniquely identify the
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 or other such devices are present
and affecting port reachability for each entity, one possibility is
to utilize the peer connectivity checks, relay use and NAT pinhole
maintenance mechanisms defined in ICE [15].
6.2.3. Fragmentation Handling 6.2.3. Fragmentation Handling
When using UDP, a single BFCP message could be fragmented at the IP When using UDP, a single BFCP message could be fragmented at the IP
layer if its overall size exceeds the path MTU of the network. To layer if its overall size exceeds the path MTU of the network. To
avoid this happening at the IP layer, a fragmentation scheme for BFCP avoid this happening at the IP layer, a fragmentation scheme for BFCP
is defined below. is defined below.
BFCP is designed for achieving small message size, due to the binary BFCP is designed for achieving small message size, due to the binary
encoding as described in Section 1. The fragmentation scheme is encoding as described in Section 1. The fragmentation scheme is
therefore deliberately kept simple and straightforward, since the therefore deliberately kept simple and straightforward, since the
probability of fragmentation of BFCP messages being required is probability of fragmentation of BFCP messages being required is
small. By design, the fragmentation scheme does not acknowledge small. By design, the fragmentation scheme does not acknowledge
individual BFCP message fragments. The whole BFCP message is individual BFCP message fragments. The whole BFCP message is
acknowledged if received completely. acknowledged if received completely.
BFCP entities should consider the MTU size available between the BFCP entities SHOULD consider the path MTU size available between the
sender and the receiver and MAY run MTU discovery, such as sender and the receiver and MAY run MTU discovery, such as
[20][21][22], for this purpose. [22][23][24], for this purpose.
When transmitting a BFCP message with size greater than the path MTU, When transmitting a BFCP message with size greater than the path MTU,
the sender MUST fragment the message into a series of N contiguous the sender MUST fragment the message into a series of N contiguous
data ranges. The value for N is defined as ceil(message size - data ranges. The size of each of these N messages MUST be smaller
COMMON-HEADER size / MTU size - COMMON-HEADER size), where ceil is than the path MTU to help prevent fragmentation overlap attacks. The
the integer ceiling function and the COMMON-HEADER size includes the value for N is defined as ceil((message size - COMMON-HEADER size) /
Fragment Offset and Fragment Length fields. The sender then creates (path MTU size - COMMON-HEADER size)), where ceil is the integer
N BFCP fragment messages (one for each data range) with the same ceiling function and the COMMON-HEADER size includes the Fragment
Transaction ID. The size of each of these N messages, with the Offset and Fragment Length fields. The sender then creates N BFCP
COMMON-HEADER included, MUST be smaller than the path MTU. The F fragment messages (one for each data range) with the same Transaction
flag in the COMMON-HEADER in all the fragments is set to indicate ID. The size of each of these N messages, with the COMMON-HEADER
fragmentation of the BFCP message. included, MUST be smaller than the path MTU. The F flag in the
COMMON-HEADER in all the fragments is set to indicate fragmentation
of the BFCP message.
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 4-octet units contained in the previous
Fragment Length contains the length of the fragment itself. Note fragments, excluding the common header. The Fragment Length contains
that the Payload Length field contains the length of the entire, the length of the fragment itself, also excluding the common header.
Note that the Payload Length field contains the length of the entire,
unfragmented message. 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 either it has received the entire BFCP buffer the fragment until either it has received the entire BFCP
message, or until the Response Retransmission Timer expires. The message, or until the Response Retransmission Timer expires. The
state machine should handle the BFCP message only after all 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 acknowledgement for the message. Therefore the sender will an acknowledgement for the message. Therefore the sender will
skipping to change at page 43, line 46 skipping to change at page 42, line 35
discard an incomplete buffer utilizing the Response Retransmission discard an incomplete buffer utilizing the Response Retransmission
Timer, starting the timer after the receipt of the first fragment. Timer, starting the timer after the receipt of the first fragment.
A Denial of Service (DoS) attack utilizing the fragmentation A Denial of Service (DoS) attack utilizing the fragmentation
scheme described above is mitigated by the fact that the Response scheme described above is mitigated by the fact that the Response
Retransmission Timer is started after receipt of the first BFCP Retransmission Timer is started after receipt of the first BFCP
message fragment. In addition, the Payload Length field can be message fragment. In addition, the Payload Length field can be
compared with the Fragment Offset and Fragment Length fields to compared with the Fragment Offset and Fragment Length fields to
verify the message fragments as they arrive. To make DoS attacks verify the message fragments as they arrive. To make DoS attacks
with spoofed IP addresses difficult, BFCP entities SHOULD use the with spoofed IP addresses difficult, BFCP entities SHOULD use the
cookie exchange mechanism in DTLS [7]. cookie exchange mechanism in DTLS [8].
When deciding message fragment size based on path MTU, the BFCP When deciding message fragment size based on path MTU, the BFCP
fragmentation handling should take into account how the DTLS record fragmentation handling should take into account how the DTLS record
framing expands the datagram size as described in Section 4.1.1.1 of framing expands the datagram size as described in Section 4.1.1.1 of
[7]. [8].
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
[15]. [17].
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 entities using an to maintain those bindings once established, BFCP entities using an
unreliable transport are RECOMMENDED to use STUN [11] Binding unreliable transport are RECOMMENDED to use STUN [12] Binding
Indication for keep-alives, as described for ICE [15]. Section 6.7 Indication for keep-alives, as described for ICE [17]. Section 6.7
of [23] provides useful recommendations for middlebox interaction of [25] provides useful recommendations for middlebox interaction
when DTLS is used. 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 an 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 [11]. and BFCP packets even without checking the STUN magic cookie [12].
In order to facilitate traversal of BFCP packets through NATs, BFCP In order to facilitate traversal of BFCP packets through NATs, BFCP
entities using an unreliable transport are RECOMMENDED to use entities using an unreliable transport are RECOMMENDED to use
symmetric ports for sending and receiving BFCP packets, as symmetric ports for sending and receiving BFCP packets, as
recommended for RTP/RTCP [10]. recommended for RTP/RTCP [11].
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 [6] and MUST support DTLS [7] MUST support TLS for transport over TCP [7] and MUST support DTLS [8]
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 cipher suite [6] for backwards TLS_RSA_WITH_AES_128_CBC_SHA cipher suite [7] for backwards
compatibility with existing implementations of RFC 4582. In compatibility with existing implementations of RFC 4582. In
accordance with the recommendations and guidelines in [24], BFCP accordance with the recommendations and guidelines in [27], BFCP
entities SHOULD support the following cipher suites: entities SHOULD support the following cipher suites:
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
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. 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 client.
skipping to change at page 45, line 28 skipping to change at page 44, line 18
When using a reliable transport, server-initiated transactions When using a reliable transport, server-initiated transactions
consist of a single message from a floor control server to a consist of a single message from a floor control server to a
client (notifications). They do not trigger any response. client (notifications). They do not trigger any response.
When using an unreliable transport, server-initiated transactions When using an unreliable transport, server-initiated transactions
consist of a request from a floor control server to a client and a consist of a request from a floor control server to a client and a
response from the client to the floor control server. response from the client to the floor control server.
When using BFCP over an unreliable transport, retransmission timer T1 When using BFCP over an unreliable transport, retransmission timer T1
(see Section 8.3) MUST be used for all requests until the transaction (see Section 8.3) MUST be used for all requests until the transaction
is completed. is completed. Note that while T1 varies over time, it remains
constant for the duration of a given transaction and is only updated
at the completion of a transaction.
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
another message from the client until a response from the server is another message from the client until a response from the server is
skipping to change at page 46, line 29 skipping to change at page 45, line 19
When BFCP entities are communicating over an unreliable transport, When BFCP entities are communicating over an unreliable transport,
two retransmission timers are employed to help mitigate against loss two retransmission timers are employed to help mitigate against loss
of datagrams. Retransmission and response caching are not required of datagrams. Retransmission and response caching are not required
when BFCP entities communicate over a reliable transport. when BFCP entities communicate over a reliable transport.
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 is computed using the
transmit, failing after three unacknowledged retransmission attempts. smoothed round-trip time algorithm defind in [2] with an initial
retransmission timeout (RTO) value of 500ms and clock granularity (G)
of 100ms. In contrast to step 2.4 of Section 2 of [2], if the
computed value of RTO is less than 500ms, then RTO shall be set to
500ms. Timer T1 MUST be adjusted with the reception of a response to
each request transmitted in order to compute an accurate RTO value,
which is the effective T1 value. The RTT value R is the time in
milliseconds from the point when a request is transmitted to the time
the initial response to that request is received. Responses to
retransmitted packets MUST NOT be used to recompute the RTO value, as
one cannot determine if a response is to an initial or retransmitted
request. If T1 always expires on the initial transmission of a new
request, this would suggest the recommended initial T1 (and RTO)
value is too low and SHOULD be increased by doubling the initial
values of T1 (and RTO) until T1 does not expire when sending a new
request.
When retransmitting a request, timer T1 is doubled with each
retransmission, 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 connection as transaction, the implementation MUST consider the BFCP connection as
failed. Implementations SHOULD follow the reestablishment procedure broken. Implementations SHOULD follow the reestablishment procedure
described in section 6. described in section 6.
8.3.2. Response Retransmission Timer, T2 8.3.2. Response Retransmission Timer, T2
T2 is a timer that, when fired, signals that the BFCP entity can T2 is a timer that, when fired, 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. Refer to Section 6.2.3 for is retained until the timer has fired. Refer to Section 6.2.3 for
the role this timer has in the fragmentation handling scheme. the role this timer has in the fragmentation handling scheme.
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 (initial) |
| T2 | Response retransmission timer | 10s | | T2 | Response retransmission timer | (T1*2^4)*1.25 |
+-------+--------------------------------------+---------+ +-------+--------------------------------------+----------------+
Table 6: Timers Table 6: Timers
The default value for T1 is 500 ms, this is an estimate of the RTT The initial value for T1 is 500ms, which is an estimate of the RTT
for completing the transaction. T1 MAY be chosen larger, and this is for completing the transaction. Computation of this value follows
RECOMMENDED if it is known in advance that the RTT is larger. the procedures described in Section 8.3.1, which includes exponential
Regardless of the value of T1, the exponential backoffs on backoffs on retransmissions.
retransmissions described in Section 8.3.1 MUST be used.
T2 SHALL be set such that it encompasses all legal retransmissions T2 MUST be set such that it encompasses all legal retransmissions per
per T1 plus a factor to accommodate network latency between BFCP T1 plus a factor to accommodate network latency between BFCP
entities. The default value is based on the sum of the three entities, processing delays, etc.
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.
If the signaling or control protocol traffic used to set up the If the signaling or control protocol traffic used to set up the
conference is authenticated and confidentiality and integrity conference is authenticated and confidentiality and integrity
protected, and the extensions in this document are supported, the protected, and the extensions in this document are supported, the
BFCP clients MUST authenticate the floor control server and the floor BFCP clients MUST authenticate the floor control server and the floor
control servers MUST authenticate the client before communicating as control servers MUST authenticate the client before communicating as
described above. Note that BFCP entities supporting only the [2] described above. Note that BFCP entities supporting only the [3]
subset may not comply with this mandatory authentication requirement. subset may not comply with this mandatory authentication requirement.
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.
Note that future extensions may define additional authentication Note that future extensions may define additional authentication
mechanisms. mechanisms.
In addition to authenticating BFCP messages, floor control servers In addition to authenticating BFCP messages, floor control servers
skipping to change at page 48, line 15 skipping to change at page 47, line 22
the operation being requested, the floor control server generates an the operation being requested, the floor control server generates an
Error message, as described in Section 13.8, with an Error code with Error message, as described in Section 13.8, with an Error code with
a value of 5 (Unauthorized Operation). Messages from a client that a value of 5 (Unauthorized Operation). Messages from a client that
cannot be authorized MUST NOT be processed further. cannot be authorized MUST NOT be processed further.
9.1. TLS/DTLS Based Mutual Authentication 9.1. TLS/DTLS Based Mutual Authentication
BFCP supports TLS/DTLS based mutual authentication between clients BFCP supports TLS/DTLS based mutual authentication between clients
and floor control servers. If TLS/DTLS is used, an initial and floor control servers. If TLS/DTLS is used, an initial
integrity-protected channel is REQUIRED between the client and the integrity-protected channel is REQUIRED between the client and the
floor control server that can be used to exchange their self-signed floor control server that can be used to exchange their certificates
certificates or, more commonly, the fingerprints of these (which MAY be self-signed certificates) or, more commonly, the
certificates. These certificates are used at TLS/DTLS establishment fingerprints of these certificates. These certificates are used at
time. TLS/DTLS establishment time.
The implementation of such an integrity-protected channel using The implementation of such an integrity-protected channel using
SIP and the SDP offer/answer model is described in [9]. SIP and the SDP offer/answer model is described in [10].
BFCP messages received over an authenticated TLS/DTLS connection are BFCP messages received over an authenticated TLS/DTLS connection are
considered authenticated. A floor control server that receives a considered authenticated. A floor control server that receives a
BFCP message over TCP/UDP (no TLS/DTLS) MAY request the use of TLS/ BFCP message over TCP/UDP (no TLS/DTLS) MAY request the use of TLS/
DTLS by generating an Error message, as described in Section 13.8, DTLS by generating an Error message, as described in Section 13.8,
with an Error code with a value of 9 (Use TLS) or a value of 11 (Use with an Error code with a value of 9 (Use TLS) or a value of 11 (Use
DTLS) respectively. Clients configured to require the use of TLS/ DTLS) respectively. Clients configured to require the use of TLS/
DTLS MUST ignore unauthenticated messages. DTLS MUST ignore unauthenticated messages.
Note that future extensions may define additional authentication Note that future extensions may define additional authentication
skipping to change at page 49, line 22 skipping to change at page 48, line 31
The ABNF in Section 5.3.1 describes the attributes that a The ABNF in Section 5.3.1 describes the attributes that a
FloorRequest message can contain. In addition, the ABNF specifies FloorRequest message can contain. In addition, the ABNF specifies
normatively which of these attributes are mandatory, and which ones normatively which of these attributes are mandatory, and which ones
are optional. are optional.
The floor participant sets the Conference ID and the Transaction ID The floor participant sets the Conference ID and the Transaction ID
in the common header following the rules given in Section 8.1. in the common header following the rules given in Section 8.1.
The floor participant sets the User ID in the common header to the The floor participant sets the User ID in the common header to the
floor participant's identifier. This User ID will be used by the floor participant's identifier. If the sender of the FloorRequest
floor control server to authenticate and authorize the request. If message (identified by the User ID) is not the participant that would
the sender of the FloorRequest message (identified by the User ID) is eventually get the floor (i.e., a third-party floor request), the
not the participant that would eventually get the floor (i.e., a sender SHOULD add a BENEFICIARY-ID attribute to the message
third-party floor request), the sender SHOULD add a BENEFICIARY-ID identifying the beneficiary of the floor.
attribute to the message identifying the beneficiary of the floor.
Note that the name space for both the User ID and the Beneficiary Note that the name space for both the User ID and the Beneficiary
ID is the same. That is, a given participant is identified by a ID is the same. That is, a given participant is identified by a
single 16-bit value that can be used in the User ID in the common single 16-bit value that can be used in the User ID in the common
header and in several attributes: BENEFICIARY-ID, BENEFICIARY- header and in several attributes: BENEFICIARY-ID, BENEFICIARY-
INFORMATION, and REQUESTED-BY-INFORMATION. INFORMATION, and REQUESTED-BY-INFORMATION.
The floor participant MUST insert at least one FLOOR-ID attribute in The floor participant MUST insert at least one FLOOR-ID attribute in
the FloorRequest message. If the client inserts more than one the FloorRequest message. If the client inserts more than one FLOOR-
FLOOR-ID attribute, the floor control server will treat all the floor ID attribute, the floor control server will treat all the floor
requests as an atomic package. That is, the floor control server requests as an atomic package. That is, the floor control server
will either grant or deny all the floors in the FloorRequest message. will either grant or deny all the floors in the FloorRequest message.
The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute
to state the reason why the floor or floors are being requested. The to state the reason why the floor or floors are being requested. The
Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for
human consumption. human consumption.
The floor participant may request that the server handle the floor The floor participant may request that the server handle the floor
request with a certain priority using a PRIORITY attribute. request with a certain priority using a PRIORITY attribute.
skipping to change at page 51, line 40 skipping to change at page 50, line 43
10.2.1. Sending a FloorRelease Message 10.2.1. Sending a FloorRelease Message
The ABNF in Section 5.3.2 describes the attributes that a The ABNF in Section 5.3.2 describes the attributes that a
FloorRelease message can contain. In addition, the ABNF specifies FloorRelease message can contain. In addition, the ABNF specifies
normatively which of these attributes are mandatory, and which ones normatively which of these attributes are mandatory, and which ones
are optional. are optional.
The floor participant sets the Conference ID and the Transaction ID The floor participant sets the Conference ID and the Transaction ID
in the common header following the rules given in Section 8.1. The in the common header following the rules given in Section 8.1. The
floor participant sets the User ID in the common header to the floor floor participant sets the User ID in the common header to the floor
participant's identifier. This User ID will be used by the floor participant's identifier.
control server to authenticate and authorize the request.
Note that the FloorRelease message is used to release a floor or Note that the FloorRelease message is used to release a floor or
floors that were granted and to cancel ongoing floor requests floors that were granted and to cancel ongoing floor requests
(from the protocol perspective, both are ongoing floor requests). (from the protocol perspective, both are ongoing floor requests).
Using the same message in both situations helps resolve the race Using the same message in both situations helps resolve the race
condition that occurs when the FloorRelease message and the condition that occurs when the FloorRelease message and the
FloorGrant message cross each other on the wire. FloorGrant message cross each other on the wire.
The floor participant uses the FLOOR-REQUEST-ID that was received in The floor participant uses the FLOOR-REQUEST-ID that was received in
the response to the FloorRequest message that the FloorRelease the response to the FloorRequest message that the FloorRelease
skipping to change at page 52, line 16 skipping to change at page 51, line 19
Note that if the floor participant requested several floors as an Note that if the floor participant requested several floors as an
atomic operation (i.e., in a single FloorRequest message), all the atomic operation (i.e., in a single FloorRequest message), all the
floors are released as an atomic operation as well (i.e., all are floors are released as an atomic operation as well (i.e., all are
released at the same time). released at the same time).
10.2.2. Receiving a Response 10.2.2. Receiving a Response
A message from the floor control server is considered a response to A message from the floor control server is considered a response to
the FloorRelease message if the message from the floor control server the FloorRelease message if the message from the floor control server
has the same Conference ID, Transaction ID, and User ID as the has the same Conference ID, Transaction ID, and User ID as the
FloorRequest message, as described in Section 8.1. On receiving such FloorRelease message, as described in Section 8.1. On receiving such
a response, the floor participant follows the rules in Section 9 that a response, the floor participant follows the rules in Section 9 that
relate to floor control server authentication. relate to floor control server authentication.
If the response is a FloorRequestStatus message, the Request Status If the response is a FloorRequestStatus message, the Request Status
value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR- value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-
REQUEST-INFORMATION grouped attribute) will be Cancelled or Released. REQUEST-INFORMATION grouped attribute) will be Cancelled or Released.
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.
skipping to change at page 53, line 6 skipping to change at page 52, line 8
11.1. Sending a ChairAction Message 11.1. Sending a ChairAction Message
The ABNF in Section 5.3.9 describes the attributes that a ChairAction The ABNF in Section 5.3.9 describes the attributes that a ChairAction
message can contain. In addition, the ABNF specifies normatively message can contain. In addition, the ABNF specifies normatively
which of these attributes are mandatory, and which ones are optional. which of these attributes are mandatory, and which ones are optional.
The floor chair sets the Conference ID and the Transaction ID in the The floor chair sets the Conference ID and the Transaction ID in the
common header following the rules given in Section 8.1. The floor common header following the rules given in Section 8.1. The floor
chair sets the User ID in the common header to the floor chair's chair sets the User ID in the common header to the floor chair's
identifier. This User ID will be used by the floor control server to identifier.
authenticate and authorize the request.
The ChairAction message contains instructions that apply to one or The ChairAction message contains instructions that apply to one or
more floors within a particular floor request. The floor or floors more floors within a particular floor request. The floor or floors
are identified by the FLOOR-REQUEST-STATUS attributes and the floor are identified by the FLOOR-REQUEST-STATUS attributes and the floor
request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which
are carried in the ChairAction message. are carried in the ChairAction message.
For example, if a floor request consists of two floors that depend on For example, if a floor request consists of two floors that depend on
different floor chairs, each floor chair will grant its floor within different floor chairs, each floor chair will grant its floor within
the floor request. Once both chairs have granted their floor, the the floor request. Once both chairs have granted their floor, the
skipping to change at page 55, line 8 skipping to change at page 54, line 8
12.1.1. Sending a FloorQuery Message 12.1.1. Sending a FloorQuery Message
The ABNF in Section 5.3.7 describes the attributes that a FloorQuery The ABNF in Section 5.3.7 describes the attributes that a FloorQuery
message can contain. In addition, the ABNF specifies normatively message can contain. In addition, the ABNF specifies normatively
which of these attributes are mandatory, and which ones are optional. which of these attributes are mandatory, and which ones are optional.
The client sets the Conference ID and the Transaction ID in the The client sets the Conference ID and the Transaction ID in the
common header following the rules given in Section 8.1. The client common header following the rules given in Section 8.1. The client
sets the User ID in the common header to the client's identifier. sets the User ID in the common header to the client's identifier.
This User ID will be used by the floor control server to authenticate
and authorize the request.
The client inserts in the message all the Floor IDs it wants to The client inserts in the message all the Floor IDs it wants to
receive information about. The floor control server will send receive information about. The floor control server will send
periodic information about all of these floors. If the client does periodic information about all of these floors. If the client does
not want to receive information about a particular floor any longer, not want to receive information about a particular floor any longer,
it sends a new FloorQuery message removing the FLOOR-ID of this it sends a new FloorQuery message removing the FLOOR-ID of this
floor. If the client does not want to receive information about any floor. If the client does not want to receive information about any
floor any longer, it sends a FloorQuery message with no FLOOR-ID floor any longer, it sends a FloorQuery message with no FLOOR-ID
attribute. attribute.
12.1.2. Receiving a Response 12.1.2. Receiving a Response
A message from the floor control server is considered a response to A message from the floor control server is considered a response to
the FloorQuery message if the message from the floor control server the FloorQuery message if the message from the floor control server
has the same Conference ID, Transaction ID, and User ID as the has the same Conference ID, Transaction ID, and User ID as the
FloorRequest message, as described in Section 8.1. On receiving such FloorQuery message, as described in Section 8.1. On receiving such a
a response, the client follows the rules in Section 9 that relate to response, the client follows the rules in Section 9 that relate to
floor control server authentication. floor control server authentication.
On reception of the FloorQuery message, the floor control server MUST On reception of the FloorQuery message, the floor control server MUST
respond with a FloorStatus message or with an Error message. If the respond with a FloorStatus message or with an Error message. If the
response is a FloorStatus message, it will contain information about response is a FloorStatus message, it will contain information about
one of the floors the client requested information about. If the one of the floors the client requested information about. If the
client did not include any FLOOR-ID attribute in its FloorQuery client did not include any FLOOR-ID attribute in its FloorQuery
message (i.e., the client does not want to receive information about message (i.e., the client does not want to receive information about
any floor any longer), the FloorStatus message from the floor control any floor any longer), the FloorStatus message from the floor control
server will not include any FLOOR-ID attribute either. server will not include any FLOOR-ID attribute either.
skipping to change at page 56, line 43 skipping to change at page 55, line 43
12.2.1. Sending a FloorRequestQuery Message 12.2.1. Sending a FloorRequestQuery Message
The ABNF in Section 5.3.3 describes the attributes that a The ABNF in Section 5.3.3 describes the attributes that a
FloorRequestQuery message can contain. In addition, the ABNF FloorRequestQuery message can contain. In addition, the ABNF
specifies normatively which of these attributes are mandatory, and specifies normatively which of these attributes are mandatory, and
which ones are optional. which ones are optional.
The client sets the Conference ID and the Transaction ID in the The client sets the Conference ID and the Transaction ID in the
common header following the rules given in Section 8.1. The client common header following the rules given in Section 8.1. The client
sets the User ID in the common header to the client's identifier. sets the User ID in the common header to the client's identifier.
This User ID will be used by the floor control server to authenticate
and authorize the request.
The client MUST insert a FLOOR-REQUEST-ID attribute that identifies The client MUST insert a FLOOR-REQUEST-ID attribute that identifies
the floor request at the floor control server. the floor request at the floor control server.
12.2.2. Receiving a Response 12.2.2. Receiving a Response
A message from the floor control server is considered a response to A message from the floor control server is considered a response to
the FloorRequestQuery message if the message from the floor control the FloorRequestQuery message if the message from the floor control
server has the same Conference ID, Transaction ID, and User ID as the server has the same Conference ID, Transaction ID, and User ID as the
FloorRequestQuery message, as described in Section 8.1. On receiving FloorRequestQuery message, as described in Section 8.1. On receiving
skipping to change at page 57, line 46 skipping to change at page 56, line 44
12.3.1. Sending a UserQuery Message 12.3.1. Sending a UserQuery Message
The ABNF in Section 5.3.5 describes the attributes that a UserQuery The ABNF in Section 5.3.5 describes the attributes that a UserQuery
message can contain. In addition, the ABNF specifies normatively message can contain. In addition, the ABNF specifies normatively
which of these attributes are mandatory, and which ones are optional. which of these attributes are mandatory, and which ones are optional.
The client sets the Conference ID and the Transaction ID in the The client sets the Conference ID and the Transaction ID in the
common header following the rules given in Section 8.1. The client common header following the rules given in Section 8.1. The client
sets the User ID in the common header to the client's identifier. sets the User ID in the common header to the client's identifier.
This User ID will be used by the floor control server to authenticate
and authorize the request.
If the floor participant the client is requesting information about If the floor participant the client is requesting information about
is not the client issuing the UserQuery message (which is identified is not the client issuing the UserQuery message (which is identified
by the User ID in the common header of the message), the client MUST by the User ID in the common header of the message), the client MUST
insert a BENEFICIARY-ID attribute. insert a BENEFICIARY-ID attribute.
12.3.2. Receiving a Response 12.3.2. Receiving a Response
A message from the floor control server is considered a response to A message from the floor control server is considered a response to
the UserQuery message if the message from the floor control server the UserQuery message if the message from the floor control server
skipping to change at page 58, line 40 skipping to change at page 57, line 39
12.4.1. Sending a Hello Message 12.4.1. Sending a Hello Message
The ABNF in Section 5.3.11 describes the attributes that a Hello The ABNF in Section 5.3.11 describes the attributes that a Hello
message can contain. In addition, the ABNF specifies normatively message can contain. In addition, the ABNF specifies normatively
which of these attributes are mandatory, and which ones are optional. which of these attributes are mandatory, and which ones are optional.
The client sets the Conference ID and the Transaction ID in the The client sets the Conference ID and the Transaction ID in the
common header following the rules given in Section 8.1. The client common header following the rules given in Section 8.1. The client
sets the User ID in the common header to the client's identifier. sets the User ID in the common header to the client's identifier.
This User ID will be used by the floor control server to authenticate
and authorize the request.
12.4.2. Receiving Responses 12.4.2. Receiving Responses
A message from the floor control server is considered a response to A message from the floor control server is considered a response to
the Hello message by the client if the message from the floor control the Hello message by the client if the message from the floor control
server has the same Conference ID, Transaction ID, and User ID as the server has the same Conference ID, Transaction ID, and User ID as the
Hello message, as described in Section 8.1. On receiving such a Hello message, as described in Section 8.1. On receiving such a
response, the client follows the rules in Section 9 that relate to response, the client follows the rules in Section 9 that relate to
floor control server authentication. floor control server authentication.
skipping to change at page 63, line 21 skipping to change at page 62, line 17
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.
The floor control server MUST copy the contents of the The floor control server MUST copy the contents of the FLOOR-REQUEST-
FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into ID attribute from the FloorRequestQuery message into the Floor
the Floor Request ID field of the FLOOR-REQUEST-INFORMATION Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
attribute.
The floor control server MUST add FLOOR-REQUEST-STATUS attributes to The floor control server MUST add FLOOR-REQUEST-STATUS attributes to
the FLOOR-REQUEST-INFORMATION grouped attribute identifying the the FLOOR-REQUEST-INFORMATION grouped attribute identifying the
floors being requested (i.e., the floors associated with the floor floors being requested (i.e., the floors associated with the floor
request identified by the FLOOR-REQUEST-ID attribute). request identified by the FLOOR-REQUEST-ID attribute).
The floor control server SHOULD add a BENEFICIARY-ID attribute to the The floor control server SHOULD add a BENEFICIARY-ID attribute to the
FLOOR-REQUEST-INFORMATION grouped attribute identifying the FLOOR-REQUEST-INFORMATION grouped attribute identifying the
beneficiary of the floor request. Additionally, the floor control beneficiary of the floor request. Additionally, the floor control
server MAY provide the display name and the URI of the beneficiary in server MAY provide the display name and the URI of the beneficiary in
skipping to change at page 64, line 25 skipping to change at page 63, line 23
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 an 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
floor requests where the participant is either the beneficiary or the floor requests where the participant is either the beneficiary or the
requester). This participant is identified by a BENEFICIARY-ID requester). This participant is identified by a BENEFICIARY-ID
attribute or, in the absence of a BENEFICIARY-ID attribute, by a the attribute or, in the absence of a BENEFICIARY-ID attribute, by a the
User ID in the common header of the UserQuery message. User ID in the common header of the UserQuery message.
The floor control server MUST copy, if present, the contents of the The floor control server MUST copy, if present, the contents of the
skipping to change at page 68, line 35 skipping to change at page 67, line 31
13.5.2. Generation of Subsequent FloorStatus Messages 13.5.2. Generation of Subsequent FloorStatus Messages
If the FloorQuery message carried more than one FLOOR-ID attribute, If the FloorQuery message carried more than one FLOOR-ID attribute,
the floor control server SHOULD generate a FloorStatus message for the floor control server SHOULD generate a FloorStatus message for
each of them (except for the FLOOR-ID attribute chosen for the first each of them (except for the FLOOR-ID attribute chosen for the first
FloorStatus message) as soon as possible. These FloorStatus messages FloorStatus message) as soon as possible. These FloorStatus messages
are generated following the same rules as those for the first are generated following the same rules as those for the first
FloorStatus message (see Section 13.5.1), but their Transaction ID is FloorStatus message (see Section 13.5.1), but their Transaction ID is
0 when using a reliable transport and non-zero and unique in the 0 when using a reliable transport and non-zero and unique in the
context of outstanding transactions when using an unreliable context of outstanding transactions when using an unreliable
transport (cf. Section 8). transport (cf. Section 8).
After generating these messages, the floor control server sends After generating these messages, the floor control server sends
FloorStatus messages, periodically keeping the client informed about FloorStatus messages, periodically keeping the client informed about
all the floors for which the client requested information. The all the floors for which the client requested information. The
Transaction ID of these messages MUST be 0 when using a reliable Transaction ID of these messages MUST be 0 when using a reliable
transport and non-zero and unique in the context of outstanding transport and non-zero and unique in the context of outstanding
transactions when using an unreliable transport (cf. Section 8). transactions when using an unreliable transport (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 an 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
skipping to change at page 70, line 16 skipping to change at page 69, line 16
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 MUST generate an Error response following the procedures error, it MUST generate an Error response following the procedures
described in Section 13.8. described in Section 13.8.
If the version of BFCP specified in the Version field of the COMMON- If the version of BFCP specified in the Version field of the COMMON-
HEADER is supported by the floor control server, it MUST respond with HEADER is supported by the floor control server, it MUST respond with
the same version number in the HelloAck; this defines the version for the same version number in the HelloAck; this defines the version for
all subsequent BFCP messages within this BFCP Connection. If the all subsequent BFCP messages within this BFCP Connection.
version given in the Hello message is not supported, and the
extensions in this document is supported, the receiving server MUST
instead send an Error message with parameter value 12 (Unsupported
Version). Note that BFCP entities supporting only the [2] subset
will not support this parameter value.
When communicating over an 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
skipping to change at page 72, line 14 skipping to change at page 71, line 9
TLS/DTLS connection is allowed to use). TLS/DTLS connection is allowed to use).
Attackers may attempt to pick messages from the network to get access Attackers may attempt to pick messages from the network to get access
to confidential information between the floor control server and a to confidential information between the floor control server and a
client (e.g., why a floor request was denied). TLS/DTLS client (e.g., why a floor request was denied). TLS/DTLS
confidentiality prevents this attack. Therefore, it is REQUIRED that confidentiality prevents this attack. Therefore, it is REQUIRED that
TLS/DTLS be used with an encryption algorithm according to Section 7. TLS/DTLS be used with an encryption algorithm according to Section 7.
15. IANA Considerations 15. IANA Considerations
[Editorial note: This section instructs the IANA to register new [Note to IANA: Much of this text exists from the previous version
of this document. While the old and new additions to the
registries are presented here, the items for which IANA needs to
take action with respect to this draft are highlighted with "Note
to IANA", as with this note and the one immediately following.
Throughout this document, though, RFC XXXX needs to be replaced
with this RFC and the IANA registries for BFCP should to refer
only to this RFC.
[Note to IANA: This section instructs the IANA to register new
entries in the BFCP Primitive subregistry in Section 15.2 and for entries in the BFCP Primitive subregistry in Section 15.2 and for
the BFCP Error Code subregistry in Section 15.4.] the BFCP Error Code subregistry in Section 15.4.]
The IANA has created a registry for BFCP parameters called "Binary The IANA has created a registry for BFCP parameters called "Binary
Floor Control Protocol (BFCP) Parameters". This registry has a Floor Control Protocol (BFCP) Parameters". This registry has a
number of subregistries, which are described in the following number of subregistries, which are described in the following
sections. sections.
15.1. Attribute Subregistry 15.1. Attribute Subregistry
This section establishes the Attribute subregistry under the BFCP This section establishes the Attribute subregistry under the BFCP
Parameters registry. As per the terminology in RFC 5226 [5], the Parameters registry. As per the terminology in RFC 5226 [6], the
registration policy for BFCP attributes shall be "Specification registration policy for BFCP attributes shall be "Specification
Required". For the purposes of this subregistry, the BFCP attributes Required". For the purposes of this subregistry, the BFCP attributes
for which IANA registration is requested MUST be defined by a for which IANA registration is requested MUST be defined by a
standards-track RFC. Such an RFC MUST specify the attribute's type, standards-track RFC. Such an RFC MUST specify the attribute's type,
name, format, and semantics. name, format, and semantics.
For each BFCP attribute, the IANA registers its type, its name, and For each BFCP attribute, the IANA registers its type, its name, and
the reference to the RFC where the attribute is defined. The the reference to the RFC where the attribute is defined. The
following table contains the initial values of this subregistry. following table contains the initial values of this subregistry.
+------+---------------------------+------------+ +------+---------------------------+------------+
| Type | Attribute | Reference | | Type | Attribute | Reference |
+------+---------------------------+------------+ +------+---------------------------+------------+
| 1 | BENEFICIARY-ID | [RFC XXXX] | | 1 | BENEFICIARY-ID | [RFC XXXX] |
| 2 | FLOOR-ID | [RFC XXXX] | | 2 | FLOOR-ID | [RFC XXXX] |
| 3 | FLOOR-REQUEST-ID | [RFC XXXX] | | 3 | FLOOR-REQUEST-ID | [RFC XXXX] |
| 4 | PRIORITY | [RFC XXXX] | | 4 | PRIORITY | [RFC XXXX] |
| 5 | REQUEST-STATUS | [RFC XXXX] | | 5 | REQUEST-STATUS | [RFC XXXX] |
| 6 | ERROR-CODE | [RFC XXXX] | | 6 | ERROR-CODE | [RFC XXXX] |
| 7 | ERROR-INFO | [RFC XXXX] | | 7 | ERROR-INFO | [RFC XXXX] |
| 8 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] | | 8 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] |
| 9 | STATUS-INFO | [RFC XXXX] | | 9 | STATUS-INFO | [RFC XXXX] |
| 10 | SUPPORTED-ATTRIBUTES | [RFC XXXX] | | 10 | SUPPORTED-ATTRIBUTES | [RFC XXXX] |
| 11 | SUPPORTED-PRIMITIVES | [RFC XXXX] | | 11 | SUPPORTED-PRIMITIVES | [RFC XXXX] |
| 12 | USER-DISPLAY-NAME | [RFC XXXX] | | 12 | USER-DISPLAY-NAME | [RFC XXXX] |
| 13 | USER-URI | [RFC XXXX] | | 13 | USER-URI | [RFC XXXX] |
| 14 | BENEFICIARY-INFORMATION | [RFC XXXX] | | 14 | BENEFICIARY-INFORMATION | [RFC XXXX] |
| 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] | | 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] |
| 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] | | 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] |
| 17 | FLOOR-REQUEST-STATUS | [RFC XXXX] | | 17 | FLOOR-REQUEST-STATUS | [RFC XXXX] |
| 18 | OVERALL-REQUEST-STATUS | [RFC XXXX] | | 18 | OVERALL-REQUEST-STATUS | [RFC XXXX] |
+------+---------------------------+------------+ +------+---------------------------+------------+
Table 7: Initial values of the BFCP Attribute subregistry Table 7: Initial values of the BFCP Attribute subregistry
15.2. Primitive Subregistry 15.2. Primitive Subregistry
[Editorial note: This section instructs the IANA to register the [Note to IANA: This section instructs the IANA to register the
following new values for the BFCP Primitive subregistry: following new values for the BFCP Primitive subregistry:
FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.] FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.]
This section establishes the Primitive subregistry under the BFCP This section establishes the Primitive subregistry under the BFCP
Parameters registry. As per the terminology in RFC 5226 [5], the Parameters registry. As per the terminology in RFC 5226 [6], the
registration policy for BFCP primitives shall be "Specification registration policy for BFCP primitives shall be "Specification
Required". For the purposes of this subregistry, the BFCP primitives Required". For the purposes of this subregistry, the BFCP primitives
for which IANA registration is requested MUST be defined by a for which IANA registration is requested MUST be defined by a
standards-track RFC. Such an RFC MUST specify the primitive's value, standards-track RFC. Such an RFC MUST specify the primitive's value,
name, format, and semantics. name, format, and semantics.
For each BFCP primitive, the IANA registers its value, its name, and For each BFCP primitive, the IANA registers its value, its name, and
the reference to the RFC where the primitive is defined. The the reference to the RFC where the primitive is defined. The
following table contains the initial values of this subregistry. following table contains the initial values of this subregistry.
skipping to change at page 74, line 32 skipping to change at page 73, line 32
| 15 | FloorStatusAck | [RFC XXXX] | | 15 | FloorStatusAck | [RFC XXXX] |
| 16 | Goodbye | [RFC XXXX] | | 16 | Goodbye | [RFC XXXX] |
| 17 | GoodbyeAck | [RFC XXXX] | | 17 | GoodbyeAck | [RFC XXXX] |
+-------+-----------------------+------------+ +-------+-----------------------+------------+
Table 8: Initial values of the BFCP primitive subregistry Table 8: Initial values of the BFCP primitive subregistry
15.3. Request Status Subregistry 15.3. Request Status Subregistry
This section establishes the Request Status subregistry under the This section establishes the Request Status subregistry under the
BFCP Parameters registry. As per the terminology in RFC 5226 [5], BFCP Parameters registry. As per the terminology in RFC 5226 [6],
the registration policy for BFCP request status shall be the registration policy for BFCP request status shall be
"Specification Required". For the purposes of this subregistry, the "Specification Required". For the purposes of this subregistry, the
BFCP request status for which IANA registration is requested MUST be BFCP request status for which IANA registration is requested MUST be
defined by a standards-track RFC. Such an RFC MUST specify the value defined by a standards-track RFC. Such an RFC MUST specify the value
and the semantics of the request status. and the semantics of the request status.
For each BFCP request status, the IANA registers its value, its For each BFCP request status, the IANA registers its value, its
meaning, and the reference to the RFC where the request status is meaning, and the reference to the RFC where the request status is
defined. The following table contains the initial values of this defined. The following table contains the initial values of this
subregistry. subregistry.
skipping to change at page 75, line 21 skipping to change at page 74, line 21
| 4 | Denied | [RFC XXXX] | | 4 | Denied | [RFC XXXX] |
| 5 | Cancelled | [RFC XXXX] | | 5 | Cancelled | [RFC XXXX] |
| 6 | Released | [RFC XXXX] | | 6 | Released | [RFC XXXX] |
| 7 | Revoked | [RFC XXXX] | | 7 | Revoked | [RFC XXXX] |
+-------+-----------+------------+ +-------+-----------+------------+
Table 9: Initial values of the Request Status subregistry Table 9: Initial values of the Request Status subregistry
15.4. Error Code Subregistry 15.4. Error Code Subregistry
[Editorial note: This section instructs the IANA to register the [Note to IANA: This section instructs the IANA to register the
following new values for the BFCP Error Code subregistry: 10, 11, following new values for the BFCP Error Code subregistry: 10, 11,
12, 13 and 14.] 12, 13 and 14.]
This section establishes the Error Code subregistry under the BFCP This section establishes the Error Code subregistry under the BFCP
Parameters registry. As per the terminology in RFC 5226 [5], the Parameters registry. As per the terminology in RFC 5226 [6], the
registration policy for BFCP error codes shall be "Specification registration policy for BFCP error codes shall be "Specification
Required". For the purposes of this subregistry, the BFCP error Required". For the purposes of this subregistry, the BFCP error
codes for which IANA registration is requested MUST be defined by a codes for which IANA registration is requested MUST be defined by a
standards-track RFC. Such an RFC MUST specify the value and the standards-track RFC. Such an RFC MUST specify the value and the
semantics of the error code, and any Error Specific Details that semantics of the error code, and any Error Specific Details that
apply to it. apply to it.
For each BFCP primitive, the IANA registers its value, its meaning, For each BFCP primitive, the IANA registers its value, its meaning,
and the reference to the RFC where the primitive is defined. The and the reference to the RFC where the primitive is defined. The
following table contains the initial values of this subregistry. following table contains the initial values of this subregistry.
skipping to change at page 76, 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 [2]. fixes from [3].
16.1. Extensions for an 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 an unreliable transport, resulting in the following BFCP over an unreliable transport, resulting in the following
changes: changes:
1. Overview of Operation (Section 4): 1. Overview of Operation (Section 4):
Changed the description of client-initiated and server-initiated Changed the description of client-initiated and server-initiated
transactions, referring to Section 8. transactions, referring to Section 8.
skipping to change at page 78, line 7 skipping to change at page 77, line 7
12. Motivation for an unreliable transport (Appendix B): 12. Motivation for an unreliable transport (Appendix B):
Introduction to and motivation for extending BFCP to support an Introduction to and motivation for extending BFCP to support an
unreliable transport. unreliable transport.
16.2. Other changes 16.2. Other changes
Clarifications and bug fixes: Clarifications and bug fixes:
1. ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>, 1. 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 [2], the notation has changed in a Although formally correct in [3], 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.
2. Typo (Section 12.4.2): 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.
3. Corrected attribute type (Section 13.1.1): 3. 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
skipping to change at page 78, line 33 skipping to change at page 77, line 33
"Generic Error". "Generic Error".
5. Assorted clarifications (Across the document): 5. Assorted clarifications (Across the document):
Language clarifications as a result of reviews. Also, the Language clarifications as a result of reviews. Also, the
normative language where tightened where appropriate, i.e. normative language where tightened where appropriate, i.e.
changed from SHOULD strength to MUST in a number of places. changed from SHOULD strength to MUST in a number of places.
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 [2]. Additionally, Xiaotao Wu, Paul Kyzivat, ideas for RFC 4582 [3]. 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
changes. Useful and important final reviews were done by Mary changes. Useful and important final reviews were done by Mary
Barnes. Barnes. Paul Jones helped tremendously as editor for changes
addressing IESG review comments.
18. References 18. References
18.1. Normative References 18.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[2] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control [2] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Protocol (BFCP)", RFC 4582, November 2006. Timer", RFC 2988, DOI 10.17487/RFC2988, November 2000,
<http://www.rfc-editor.org/info/rfc2988>.
[3] Camarillo, G., "Connection Establishment in the Binary Floor [3] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 5018, September 2007. Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582,
November 2006, <http://www.rfc-editor.org/info/rfc4582>.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax [4] Camarillo, G., "Connection Establishment in the Binary
Specifications: ABNF", STD 68, RFC 5234, January 2008. Floor Control Protocol (BFCP)", RFC 5018, DOI 10.17487/
RFC5018, September 2007,
<http://www.rfc-editor.org/info/rfc5018>.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Protocol Version 1.2", RFC 5246, August 2008. IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[7] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [7] Dierks, T. and E. Rescorla, "The Transport Layer Security
Security Version 1.2", RFC 6347, January 2012. (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
STD 63, RFC 3629, November 2003. Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[9] Camarillo, G., Kristensen, T., and P. Jones, "Session [9] Yergeau, F., "UTF-8, a transformation format of ISO
Description Protocol (SDP) Format for Binary Floor Control 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-12 2003, <http://www.rfc-editor.org/info/rfc3629>.
(work in progress), Semptember 2015.
[10] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [10] Camarillo, G., Kristensen, T., and P. Jones, "Session
BCP 131, RFC 4961, July 2007. Description Protocol (SDP) Format for Binary Floor Control
Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-12
(work in progress), September 2015.
[11] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session [11] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
<http://www.rfc-editor.org/info/rfc4961>.
[12] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
[13] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, DOI
10.17487/RFC5405, November 2008,
<http://www.rfc-editor.org/info/rfc5405>.
18.2. Informational References 18.2. Informational References
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [14] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
Session Description Protocol (SDP)", RFC 3264, June 2002. with Session Description Protocol (SDP)", RFC 3264, DOI
10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[13] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, [15] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
"Requirements for Floor Control Protocols", RFC 4376, "Requirements for Floor Control Protocols", RFC 4376, DOI
February 2006. 10.17487/RFC4376, February 2006,
<http://www.rfc-editor.org/info/rfc4376>.
[14] Barnes, M., Boulton, C., and O. Levin, "A Framework for [16] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239,
June 2008, <http://www.rfc-editor.org/info/rfc5239>.
[15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [17] Rosenberg, J., "Interactive Connectivity Establishment
Protocol for Network Address Translator (NAT) Traversal for (ICE): A Protocol for Network Address Translator (NAT)
Offer/Answer Protocols", RFC 5245, April 2010. Traversal for Offer/Answer Protocols", RFC 5245, DOI
10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[17] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, [19] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized Conferencing "Conference Information Data Model for Centralized
(XCON)", RFC 6501, March 2012. Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501,
March 2012, <http://www.rfc-editor.org/info/rfc6501>.
[18] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, [20] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
"Centralized Conferencing Manipulation Protocol", RFC 6503, "Centralized Conferencing Manipulation Protocol", RFC
March 2012. 6503, DOI 10.17487/RFC6503, March 2012,
<http://www.rfc-editor.org/info/rfc6503>.
[19] Barnes, M., Miniero, L., Presta, R., and SP. Romano, [21] Barnes, M., Miniero, L., Presta, R., and S. Romano,
"Centralized Conferencing Manipulation Protocol (CCMP) Call "Centralized Conferencing Manipulation Protocol (CCMP)
Flow Examples", RFC 6504, March 2012. Call Flow Examples", RFC 6504, DOI 10.17487/RFC6504, March
2012, <http://www.rfc-editor.org/info/rfc6504>.
[20] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [22] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>.
[21] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for [23] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>.
[22] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [24] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>.
[23] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for [25] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
Establishing a Secure Real-time Transport Protocol (SRTP) for Establishing a Secure Real-time Transport Protocol
Security Context Using Datagram Transport Layer Security (SRTP) Security Context Using Datagram Transport Layer
(DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <http://www.rfc-editor.org/info/rfc5763>.
[24] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for [26] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
Secure Use of TLS and DTLS", draft-ietf-uta-tls-bcp-09 (work in Control Transmission Protocol (SCTP) Packets for End-Host
progress), February 2015. to End-Host Communication", RFC 6951, DOI 10.17487/
RFC6951, May 2013,
<http://www.rfc-editor.org/info/rfc6951>.
[25] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network [27] Sheffer, Y., Holz, R., and P. Saint-Andre,
Address Translations (NATs)", RFC 4380, February 2006. "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[26] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for [28] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Application Designers", BCP 145, RFC 5405, November 2008. Network Address Translations (NATs)", RFC 4380, DOI
10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>.
[27] Thaler, D., "Teredo Extensions", RFC 6081, January 2011. [29] Thaler, D., "Teredo Extensions", RFC 6081, DOI 10.17487/
RFC6081, January 2011,
<http://www.rfc-editor.org/info/rfc6081>.
[28] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, [30] Stewart, R., Ed., "Stream Control Transmission Protocol",
September 2007. RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>.
[29] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP [31] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
Candidates with Interactive Connectivity Establishment (ICE)", "TCP Candidates with Interactive Connectivity
RFC 6544, March 2012. Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
March 2012, <http://www.rfc-editor.org/info/rfc6544>.
[30] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling [32] Manner, J., Varis, N., and B. Briscoe, "Generic UDP
(GUT)", draft-manner-tsvwg-gut-02 (work in progress), Tunnelling (GUT)", draft-manner-tsvwg-gut-02 (work in
July 2010. progress), July 2010.
[31] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of [33] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis
Middlebox Interactions for Signaling Protocol Communication of Middlebox Interactions for Signaling Protocol
along the Media Path", Communication along the Media Path", draft-ietf-mmusic-
draft-ietf-mmusic-media-path-middleboxes-05 (work in progress), media-path-middleboxes-07 (work in progress), May 2013.
July 2012.
[32] Guha, S. and P. Francis, "Characterization and Measurement of [34] Guha, S. and P. Francis, "Characterization and Measurement
TCP Traversal through NATs and Firewalls", 2005, of TCP Traversal through NATs and Firewalls", 2005,
<http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>. <http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>.
[33] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer [35] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer
Communication Across Network Address Translators", April 2005, Communication Across Network Address Translators", April
<http://www.brynosaurus.com/pub/net/p2pnat.pdf/>. 2005, <http://www.brynosaurus.com/pub/net/p2pnat.pdf/>.
Appendix A. Example Call Flows for BFCP over an 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 Responder: 0 |
|Transaction ID: 123 | |Transaction ID: 123 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorRequestStatus | |(2) FloorRequestStatus |
|Transaction Responder: 1 |
|Transaction ID: 123 | |Transaction ID: 123 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Pending | | Request Status: Pending |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(3) FloorRequestStatus | |(3) FloorRequestStatus |
|Transaction Responder: 0 |
|Transaction ID: 124 | |Transaction ID: 124 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted | | Request Status: Accepted |
| Queue Position: 1st | | Queue Position: 1st |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(4) FloorRequestStatusAck | |(4) FloorRequestStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 124 | |Transaction ID: 124 |
|User ID: 234 | |User ID: 234 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(5) FloorRequestStatus | |(5) FloorRequestStatus |
|Transaction Responder: 0 |
|Transaction ID: 125 | |Transaction ID: 125 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Granted | | Request Status: Granted |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(6) FloorRequestStatusAck | |(6) FloorRequestStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 125 | |Transaction ID: 125 |
|User ID: 234 | |User ID: 234 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(7) FloorRelease | |(7) FloorRelease |
|Transaction Responder: 0 |
|Transaction ID: 126 | |Transaction ID: 126 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-ID: 789 | |FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(8) FloorRequestStatus | |(8) FloorRequestStatus |
|Transaction Responder: 1 |
|Transaction ID: 126 | |Transaction ID: 126 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Released | | Request Status: Released |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
|<----------------------------------------------| |<----------------------------------------------|
Figure 48: Requesting and releasing a floor Figure 48: Requesting and releasing a floor
Note that in Figure 48, the FloorRequestStatus message from the floor Note that in Figure 48, the FloorRequestStatus message from the floor
control server to the floor participant is a transaction-closing control server to the floor participant is a transaction-closing
message as a response to the client-initiated transaction with message as a response to the client-initiated transaction with
Transaction ID 154. It does not and SHOULD NOT be followed by a Transaction ID 154. As such, it is not followed by a
FloorRequestStatusAck message from the floor participant to the floor FloorRequestStatusAck message from the floor participant to the floor
control server. control server.
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorQuery | |(1) FloorQuery |
|Transaction Responder: 0 |
|Transaction ID: 257 | |Transaction ID: 257 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorStatus | |(2) FloorStatus |
|Transaction Responder: 1 |
|Transaction ID: 257 | |Transaction ID: 257 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 | | Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted | | Request Status: Accepted |
| Queue Position: 1st | | Queue Position: 1st |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
skipping to change at page 84, line 4 skipping to change at page 84, line 15
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted | | Request Status: Accepted |
| Queue Position: 2nd | | Queue Position: 2nd |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(3) FloorStatus | |(3) FloorStatus |
|Transaction Responder: 0 |
|Transaction ID: 258 | |Transaction ID: 258 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 | | Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Granted | | Request Status: Granted |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
skipping to change at page 84, line 27 skipping to change at page 84, line 39
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted | | Request Status: Accepted |
| Queue Position: 1st | | Queue Position: 1st |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(4) FloorStatusAck | |(4) FloorStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 258 | |Transaction ID: 258 |
|User ID: 234 | |User ID: 234 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(5) FloorStatus | |(5) FloorStatus |
|Transaction Responder: 0 |
|Transaction ID: 259 | |Transaction ID: 259 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Granted | | Request Status: Granted |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(6) FloorStatusAck | |(6) FloorStatusAck |
|Transaction Responder: 1 |
|Transaction ID: 259 | |Transaction ID: 259 |
|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 an Unreliable Transport Appendix B. Motivation for Supporting an Unreliable Transport
This appendix is contained in this document as an aid to understand This appendix is contained in this document as an aid to understand
the background and rationale for adding support for unreliable the background and rationale for adding support for unreliable
transport. transport.
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.
BFCP roles are negotiated in the offer/answer exchange as specified BFCP roles are negotiated in the offer/answer exchange as specified
in [9], resulting in one endpoint being responsible for opening the in [10], resulting in one endpoint being responsible for 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|
skipping to change at page 85, line 41 skipping to change at page 86, line 7
+----+ +----+ +----+ +----+
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 traversal for the RTP streams networks. In existing deployments, NAT traversal for the RTP streams
works using ICE and/or other methods, including those described in works using ICE and/or other methods, including those described in
[31]. [33].
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
[29]. A broad study of NAT behavior and peer-to-peer TCP [31]. 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 [32]. The possible to establish a TCP connection in 11% of the cases [34]. 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 [33]. UDP than when using TCP [35].
It is worth noticing that BFCP over UDP is already being used in real It is worth noticing that BFCP over UDP is already being 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 situation where multiple different and non-interoperable
implementations would co-exist in the market. The purpose of this implementations would co-exist in the market. The purpose of this
draft is to formalize and publish the extension from the standard draft is to formalize and publish the extension from the standard
specification to facilitate complete interoperability between specification to facilitate complete interoperability between
implementations. implementations.
skipping to change at page 86, line 40 skipping to change at page 87, line 7
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 [29] extends ICE to TCP based media, including the ability to ICE TCP [31] 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 [29]) than enabling UDP connectivity in the same (see Appendix A of [31]) 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 [29] should increase the advocated for candidate collection in [31] 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 NATs. not common in enterprise NATs.
B.1.1.2. Teredo B.1.1.2. Teredo
Teredo [25] enables nodes located behind one or more IPv4 NATs to Teredo [28] 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 [27] provide additional capabilities to Teredo, including extensions [29] 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"
[25]. These servers and relays generally do not exist in the [28]. 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 [30] attempts to facilitate tunneling over UDP by encapsulating GUT [32] 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
the edge of the network, providing connectivity to the Internet for the edge of the network, providing connectivity to the Internet for
computers internal to the LAN, but do not allow Internet devices to computers internal to the LAN, but do not allow Internet devices to
connect to computers on the internal LAN. IGDs enable a computer on connect to computers on the internal LAN. IGDs enable a computer on
skipping to change at page 88, line 33 skipping to change at page 88, line 47
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
[28], and then tunnel SCTP over UDP in the use case described in [30], 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 was
ongoing discussion in the RTCWeb WG regarding this approach. ongoing discussion in the RTCWeb WG regarding this approach, which
However, this approach for tunneling over UDP was not mature enough resulted in [26]. However, this approach for tunneling over UDP was
when considered and not even fully specified. not mature enough 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
[26]. [13].
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
feasible. Initial compatibility among implementations has been feasible. Initial compatibility among implementations has been
achieved at previous interoperability events. The authors view this achieved at previous interoperability events. The authors view this
extension as a pragmatic solution to an existing deployment extension as a pragmatic solution to an existing deployment
challenge. This is the chosen approach, and the extensions is challenge. This is the chosen approach, and the extensions are
specified in this document. specified in this document.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
FI-02420 Jorvas FI-02420 Jorvas
Finland Finland
 End of changes. 198 change blocks. 
542 lines changed or deleted 635 lines changed or added

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