draft-ietf-bfcpbis-rfc4582bis-03.txt   draft-ietf-bfcpbis-rfc4582bis-04.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: December 6, 2012 T. Kristensen, Ed. Expires: January 15, 2013 T. Kristensen, Ed.
Cisco Cisco
J. Ott J. Ott
Aalto University Aalto University
C. Eckel C. Eckel
Cisco Cisco
June 4, 2012 July 14, 2012
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-bfcpbis-rfc4582bis-03 draft-ietf-bfcpbis-rfc4582bis-04
Abstract Abstract
Floor control is a means to manage joint or exclusive access to Floor control is a means to manage joint or exclusive access to
shared resources in a (multiparty) conferencing environment. shared resources in a (multiparty) conferencing environment.
Thereby, floor control complements other functions -- such as Thereby, floor control complements other functions -- such as
conference and media session setup, conference policy manipulation, conference and media session setup, conference policy manipulation,
and media control -- that are realized by other protocols. and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP). This document specifies the Binary Floor Control Protocol (BFCP).
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 6, 2012. This Internet-Draft will expire on January 15, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 5 skipping to change at page 4, line 5
5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 35 5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 35
5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . . 35 5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . . 35
5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . . 36 5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . . 36
5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 36 5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 36
5.3.9. ChairAction . . . . . . . . . . . . . . . . . . . . . 36 5.3.9. ChairAction . . . . . . . . . . . . . . . . . . . . . 36
5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . . 36 5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . . 36
5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 38 5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 38
5.3.15. ErrorAck . . . . . . . . . . . . . . . . . . . . . . . 38 5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . . 38
5.3.16. FloorStatusAck . . . . . . . . . . . . . . . . . . . . 38 5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.17. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38 5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 38
5.3.18. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 39
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . . 39 6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . . 39
6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . 40 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . 40
6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . 41 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . 41
6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42
6.3. Large Message Considerations . . . . . . . . . . . . . . . 42 6.3. Large Message Considerations . . . . . . . . . . . . . . . 42
6.3.1. Fragmentation Handling . . . . . . . . . . . . . . . . 42 6.3.1. Fragmentation Handling . . . . . . . . . . . . . . . . 42
6.3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 43 6.3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 43
7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 43 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 43
8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 44 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 44
8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 44 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 44
8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 45 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 44
8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 45 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 45
8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 45 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 45
8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 46 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 46
9. Authentication and Authorization . . . . . . . . . . . . . . . 46 9. Authentication and Authorization . . . . . . . . . . . . . . . 46
9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 47 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 46
10. Floor Participant Operations . . . . . . . . . . . . . . . . . 47 10. Floor Participant Operations . . . . . . . . . . . . . . . . . 47
10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 47 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 47
10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 48 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 47
10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 48 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 48
10.1.3. Reception of a Subsequent FloorRequestStatus
Message . . . . . . . . . . . . . . . . . . . . . . . 50
10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 50 10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 50
10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 50 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 50
10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 50 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 50
11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 51 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 51
11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 51 11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 51
11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 53 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 52
12. General Client Operations . . . . . . . . . . . . . . . . . . 53 12. General Client Operations . . . . . . . . . . . . . . . . . . 53
12.1. Requesting Information about Floors . . . . . . . . . . . 53 12.1. Requesting Information about Floors . . . . . . . . . . . 53
12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 53 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 53
12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 54 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 54
12.1.3. Reception of a Subsequent FloorStatus Message . . . . 54
12.2. Requesting Information about Floor Requests . . . . . . . 54 12.2. Requesting Information about Floor Requests . . . . . . . 54
12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 55 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 55
12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 55 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 55
12.3. Requesting Information about a User . . . . . . . . . . . 56 12.3. Requesting Information about a User . . . . . . . . . . . 55
12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 56 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 56
12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 56 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 56
12.4. Obtaining the Capabilities of a Floor Control Server . . . 57 12.4. Obtaining the Capabilities of a Floor Control Server . . . 57
12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 57 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 57
12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 57 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 57
13. Floor Control Server Operations . . . . . . . . . . . . . . . 58
13. Floor Control Server Operations . . . . . . . . . . . . . . . 57
13.1. Reception of a FloorRequest Message . . . . . . . . . . . 58 13.1. Reception of a FloorRequest Message . . . . . . . . . . . 58
13.1.1. Generating the First FloorRequestStatus Message . . . 59 13.1.1. Generating the First FloorRequestStatus Message . . . 58
13.1.2. Generation of Subsequent FloorRequestStatus 13.1.2. Generation of Subsequent FloorRequestStatus
Messages . . . . . . . . . . . . . . . . . . . . . . . 60 Messages . . . . . . . . . . . . . . . . . . . . . . . 60
13.1.3. Reception of a FloorRequestStatus Message . . . . . . 61
13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 61 13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 61
13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 62 13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 62
13.4. Reception of a FloorRelease Message . . . . . . . . . . . 64 13.4. Reception of a FloorRelease Message . . . . . . . . . . . 64
13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 65 13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 65
13.5.1. Generation of the First FloorStatus Message . . . . . 65 13.5.1. Generation of the First FloorStatus Message . . . . . 65
13.5.2. Generation of Subsequent FloorStatus Messages . . . . 66 13.5.2. Generation of Subsequent FloorStatus Messages . . . . 67
13.5.3. Reception of a FloorStatus Message . . . . . . . . . . 67
13.6. Reception of a ChairAction Message . . . . . . . . . . . . 67 13.6. Reception of a ChairAction Message . . . . . . . . . . . . 67
13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 68 13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 68
13.8. Error Message Generation . . . . . . . . . . . . . . . . . 68 13.8. Error Message Generation . . . . . . . . . . . . . . . . . 69
13.9. Reception of an Error Message . . . . . . . . . . . . . . 69
14. Security Considerations . . . . . . . . . . . . . . . . . . . 69 14. Security Considerations . . . . . . . . . . . . . . . . . . . 69
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 70 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 70
15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 71 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 71
15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 72 15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 72
15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 73 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 73
16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 74 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 74
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76
18.1. Normative References . . . . . . . . . . . . . . . . . . . 76 18.1. Normative References . . . . . . . . . . . . . . . . . . . 76
skipping to change at page 11, line 44 skipping to change at page 11, line 44
Figures 2 and 3 below show call flows for two sample BFCP Figures 2 and 3 below show call flows for two sample BFCP
interactions when used over reliable transport. Appendix A shows the interactions when used over reliable transport. Appendix A shows the
same sample interactions but over an unreliable transport. same sample interactions but over an unreliable transport.
Figure 2 shows how a floor participant requests a floor, obtains it, Figure 2 shows how a floor participant requests a floor, obtains it,
and, at a later time, releases it. This figure illustrates the use, and, at a later time, releases it. This figure illustrates the use,
among other things, of the Transaction ID and the FLOOR-REQUEST-ID among other things, of the Transaction ID and the FLOOR-REQUEST-ID
attribute. attribute.
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorRequest | |(1) FloorRequest |
|Transaction ID: 123 | |Transaction ID: 123 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorRequestStatus | |(2) FloorRequestStatus |
|Transaction ID: 123 | |Transaction ID: 123 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| 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 ID: 0 | |Transaction ID: 0 |
|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) FloorRequestStatus | |(4) FloorRequestStatus |
|Transaction ID: 0 | |Transaction ID: 0 |
|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 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(5) FloorRelease | |(5) FloorRelease |
|Transaction ID: 154 | |Transaction ID: 154 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-ID: 789 | |FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(6) FloorRequestStatus | |(6) FloorRequestStatus |
|Transaction ID: 154 | |Transaction ID: 154 |
|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 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. FloorStatus
message (2) indicates that there are currently two floor requests for message (2) indicates that there are currently two floor requests for
the floor whose Floor ID is 543. FloorStatus message (3) indicates the floor whose Floor ID is 543. FloorStatus message (3) indicates
that the floor requests with Floor Request ID 764 has been granted, that the floor requests with Floor Request ID 764 has been granted,
and the floor request with Floor Request ID 635 is the first in the and the floor request with Floor Request ID 635 is the first in the
queue. FloorStatus message (4) indicates that the floor request with queue. FloorStatus message (4) indicates that the floor request with
Floor Request ID 635 has been granted. 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 |
|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 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 | | Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| 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 ID: 0 | |Transaction ID: 0 |
|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 |
| Beneficiary ID: 124 | | Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| 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) FloorStatus | |(4) FloorStatus |
|Transaction ID: 0 | |Transaction ID: 0 |
|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 |
|<----------------------------------------------| |<----------------------------------------------|
Figure 3: Obtaining status information about a floor Figure 3: Obtaining status information about a floor
FloorStatus messages contain information about the floor requests FloorStatus messages contain information about the floor requests
they carry. For example, FloorStatus message (4) indicates that the they carry. For example, FloorStatus message (4) indicates that the
floor request with Floor Request ID 635 has as the beneficiary (i.e., floor request with Floor Request ID 635 has as the beneficiary (i.e.,
the participant that holds the floor when a particular floor request the participant that holds the floor when a particular floor request
is granted) the participant whose User ID is 154. The floor request is granted) the participant whose User ID is 154. The floor request
applies only to the floor whose Floor ID is 543. That is, this is applies only to the floor whose Floor ID is 543. That is, this is
not a multi-floor floor request. not a multi-floor floor request.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
responsible for the other floors agree to grant them as well. In responsible for the other floors agree to grant them as well. In
another example, a floor chair may instruct the floor control server another example, a floor chair may instruct the floor control server
to grant a floor to a participant. The floor control server needs to to grant a floor to a participant. The floor control server needs to
revoke the floor from its current holder before granting it to the revoke the floor from its current holder before granting it to the
new participant. new participant.
So, the floor control server is ultimately responsible for keeping a So, the floor control server is ultimately responsible for keeping a
coherent floor state using instructions from floor chairs as input to coherent floor state using instructions from floor chairs as input to
this state. this state.
Floor Chair Floor Control Floor Chair Floor Control
Server Server
|(1) ChairAction | |(1) ChairAction |
|Transaction ID: 769 | |Transaction ID: 769 |
|User ID: 357 | |User ID: 357 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
| Request Status: Granted | | Request Status: Granted |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) ChairActionAck | |(2) ChairActionAck |
|Transaction ID: 769 | |Transaction ID: 769 |
|User ID: 357 | |User ID: 357 |
|<----------------------------------------------| |<----------------------------------------------|
Figure 4: Chair instructing the floor control server Figure 4: Chair instructing the floor control server
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
skipping to change at page 17, line 4 skipping to change at page 17, line 4
| Transaction ID | User ID | | Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Offset (if F is set) | Fragment Length (if F is set) | | Fragment Offset (if F is set) | Fragment Length (if F is set) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: COMMON-HEADER format Figure 5: COMMON-HEADER format
Ver: The 3-bit version field MUST be set to 1 when using BFCP over Ver: The 3-bit version field MUST be set to 1 when using BFCP over
reliable transport, i.e. as in [17]. The 3-bit version field MUST be reliable transport, i.e. as in [17]. The 3-bit version field MUST be
set to 2 when using BFCP over unreliable transport, with the set to 2 when using BFCP over unreliable transport, with the
extensions specified in this document. If a BFCP entity receives a extensions specified in this document. If a Floor Control Server
message with an unsupported version field value, the receiving receives a message with an unsupported version field value, the
participant MAY send an Error message with parameter value 12 to receiving server MAY send an Error message with parameter value 12
indicate this. (Unsupported Version) to indicate this.
R: The Transaction Responder (R) flag-bit has relevance only for use R: The Transaction Responder (R) flag-bit has relevance only for use
of BFCP over unreliable transport. When cleared, it indicates that of BFCP over unreliable transport. When cleared, it indicates that
this message is a request initiating a new transaction, and the this message is a request initiating a new transaction, and the
Transaction ID that follows has been generated for this transaction. Transaction ID that follows has been generated for this transaction.
When set, it indicates that this message is a response to a previous When set, it indicates that this message is a response to a previous
request, and the Transaction ID that follows is the one associated request, and the Transaction ID that follows is the one associated
with that request. When BFCP is used over reliable transports, the with that request. When BFCP is used over reliable transports, the
flag has no significance and SHOULD be cleared. flag has no significance and SHOULD be cleared.
skipping to change at page 18, line 22 skipping to change at page 18, line 22
| 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 | ErrorAck | P -> S ; Ch -> S | | 15 | FloorStatusAck | P -> S ; Ch -> S |
| 16 | FloorStatusAck | P -> S ; Ch -> S | | 16 | Goodbye | P -> S ; Ch -> S ; |
| 17 | Goodbye | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S | | | | P <- S ; Ch <- S |
| 18 | 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 BFCP entity in 4-octet units, excluding the common header. If a Floor Control
receives a message with an incorrect payload length field value, the Server receives a message with an incorrect payload length field
receiving participant MAY send an Error message with parameter value value, the receiving server MAY send an Error message with parameter
13 to indicate this. value 13 (Incorrect Message Length) to indicate this.
Conference ID: This 32-bit unsigned integer field identifies the Conference ID: This 32-bit unsigned integer field identifies the
conference the message belongs to. conference the message belongs to.
Transaction ID: This field contains a 16-bit value that allows users Transaction ID: This field contains a 16-bit value that allows users
to match a given message with its response (see Section 8). to match a given message with its response (see Section 8).
User ID: This field contains a 16-bit unsigned integer that uniquely User ID: This field contains a 16-bit unsigned integer that uniquely
identifies a participant within a conference. identifies a participant within a conference.
skipping to change at page 20, line 39 skipping to change at page 20, line 31
| 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 an unrecognized attribute with the of the attribute is required. If a Floor Control Server receives an
'M' bit set is received, the message is rejected. The 'M' bit is unrecognized attribute with the 'M' bit set the server MAY send an
significant for extension attributes defined in other documents only. Error message with parameter value 4 (Unknown Mandatory Attribute) to
All attributes specified in this document MUST be understood by the indicate this. The 'M' bit is significant for extension attributes
receiver so that the setting of the 'M' bit is irrelevant for these. defined in other documents only. All attributes specified in this
In all other cases, the unrecognized attribute is ignored but the document MUST be understood by the receiver so that the setting of
message is processed. the 'M' bit is irrelevant for these. In all other cases, the
unrecognized attribute is ignored but the message is processed.
Length: This 8-bit field contains the length of the attribute in Length: This 8-bit field contains the length of the attribute in
octets, excluding any padding defined for specific attributes. The octets, excluding any padding defined for specific attributes. The
length of attributes that are not grouped includes the Type, 'M' bit, length of attributes that are not grouped includes the Type, 'M' bit,
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 24, line 22 skipping to change at page 24, line 22
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: ERROR-CODE format Figure 12: ERROR-CODE format
Error Code: This 8-bit field contains an error code from the Error Code: This 8-bit field contains an error code from the
following table. If an error code is not recognized by the receiver, following table. If an error code is not recognized by the receiver,
then the receiver MUST assume that an error exists, and therefore then the receiver MUST assume that an error exists, and therefore
that the message is processed, but the nature of the error is that the original message that triggered the Error message to be sent
unclear. is processed, but the nature of the error is unclear.
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Value | Meaning | | Value | Meaning |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 1 | Conference does not Exist | | 1 | Conference does not Exist |
| 2 | User does not Exist | | 2 | User does not Exist |
| 3 | Unknown Primitive | | 3 | Unknown Primitive |
| 4 | Unknown Mandatory Attribute | | 4 | Unknown Mandatory Attribute |
| 5 | Unauthorized Operation | | 5 | Unauthorized Operation |
| 6 | Invalid Floor ID | | 6 | Invalid Floor ID |
skipping to change at page 28, line 26 skipping to change at page 28, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: SUPPORTED-ATTRIBUTES format Figure 17: SUPPORTED-ATTRIBUTES format
Supp. Attr.: These fields contain the Types of the attributes that Supp. Attr.: These fields contain the Types of the attributes that
are supported by the floor control server in the following format: are supported by the floor control server in the following format:
R: Reserved: This bit MUST be set to zero upon transmission and MUST R: Reserved: This bit MUST be set to zero upon transmission and MUST
be ignored upon reception. be ignored upon reception.
Padding: Two octets of padding added so that the contents of the Padding: One, two, or three octets of padding added so that the
SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If
is already 32-bit aligned, no padding is needed. the attribute is already 32-bit aligned, no padding is needed.
The Padding bits SHOULD be set to zero by the sender and MUST be The Padding bits SHOULD be set to zero by the sender and MUST be
ignored by the receiver. ignored by the receiver.
5.2.11. SUPPORTED-PRIMITIVES 5.2.11. SUPPORTED-PRIMITIVES
The following is the format of the SUPPORTED-PRIMITIVES attribute. The following is the format of the SUPPORTED-PRIMITIVES 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
skipping to change at page 38, line 7 skipping to change at page 38, line 7
Error = (COMMON-HEADER) Error = (COMMON-HEADER)
(ERROR-CODE) (ERROR-CODE)
[ERROR-INFO] [ERROR-INFO]
*(EXTENSION-ATTRIBUTE) *(EXTENSION-ATTRIBUTE)
Figure 43: Error format Figure 43: Error format
5.3.14. FloorRequestStatusAck 5.3.14. FloorRequestStatusAck
Floor participants and chairs acknowledge the receipt of a Floor participants and chairs acknowledge the receipt of a subsequent
FloorRequestStatus message from the floor control server when FloorRequestStatus message from the floor control server when
communicating over unreliable transport. The following is the format communicating over unreliable transport. The following is the format
of the 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. ErrorAck 5.3.15. FloorStatusAck
Floor participants and chairs acknowledge the receipt of an Error
message from the floor control server when communicating over
unreliable transport. The following is the format of the ErrorAck
message:
ErrorAck = (COMMON-HEADER)
*(EXTENSION-ATTRIBUTE)
Figure 45: ErrorAck format
5.3.16. FloorStatusAck
Floor participants and chairs acknowledge the receipt of a Floor participants and chairs acknowledge the receipt of a subsequent
FloorStatus message from the floor control server when communicating FloorStatus message from the floor control server when communicating
over unreliable transport. The following is the format of the over unreliable transport. The following is the format of the
FloorStatusAck message: FloorStatusAck message:
FloorStatusAck = (COMMON-HEADER) FloorStatusAck = (COMMON-HEADER)
*(EXTENSION-ATTRIBUTE) *(EXTENSION-ATTRIBUTE)
Figure 46: FloorStatusAck format Figure 45: FloorStatusAck format
5.3.17. 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 47: Goodbye format Figure 46: Goodbye format
5.3.18. GoodbyeAck 5.3.17. GoodbyeAck
BFCP entities communicating over an unreliable transport should BFCP entities communicating over an unreliable transport should
acknowledge the receipt of a Goodbye message from a peer. The acknowledge the receipt of a Goodbye message from a peer. The
following is the format of the GoodbyeAck message: following is the format of the GoodbyeAck message:
GoodbyeAck = (COMMON-HEADER) GoodbyeAck = (COMMON-HEADER)
*(EXTENSION-ATTRIBUTE) *(EXTENSION-ATTRIBUTE)
Figure 48: GoodbyeAck format Figure 47: GoodbyeAck format
6. Transport 6. Transport
The transport over which BFCP entities exchange messages depends on The transport over which BFCP entities exchange messages depends on
how clients obtain information to contact the floor control server how clients obtain information to contact the floor control server
(e.g. using an SDP offer/answer exchange [7]). Two transports are (e.g. using an SDP offer/answer exchange [7]). Two transports are
supported: TCP, appropriate where entities can be sure that their supported: TCP, appropriate where entities can be sure that their
connectivity is not impeded by NAT devices, media relays or connectivity is not impeded by NAT devices, media relays or
firewalls; and UDP for those deployments where TCP may not be firewalls; and UDP for those deployments where TCP may not be
applicable or appropriate. applicable or appropriate.
skipping to change at page 40, line 18 skipping to change at page 40, line 5
messages for which it did not get a response from the floor control messages for which it did not get a response from the floor control
server. server.
If a floor control server detects that the TCP connection towards one If a floor control server detects that the TCP connection towards one
of the floor participants is lost, it is up to the local policy of of the floor participants is lost, it is up to the local policy of
the floor control server what to do with the pending floor requests the floor control server what to do with the pending floor requests
of the floor participant. In any case, it is RECOMMENDED that the of the floor participant. In any case, it is RECOMMENDED that the
floor control server keep the floor requests (i.e., that it does not floor control server keep the floor requests (i.e., that it does not
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
server, the client closes (i.e., a graceful close) the TCP connection
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
conference informs the floor control server that the client has been
kicked out from the conference), the floor control server closes
(i.e., a graceful close) the TCP connection towards the client.
6.2. Unreliable Transport 6.2. Unreliable Transport
BFCP entities may elect to exchange BFCP messages using UDP BFCP entities may elect to exchange BFCP messages using UDP
datagrams. UDP is an unreliable transport where neither delivery nor datagrams. UDP is an unreliable transport where neither delivery nor
ordering is assured. Each BFCP UDP datagram MUST contain exactly one ordering is assured. Each BFCP UDP datagram MUST contain exactly one
BFCP message. In the event the size of a BFCP message exceeds the BFCP message. In the event the size of a BFCP message exceeds the
MTU size, the BFCP message will be fragmented at the IP layer. MTU size, the BFCP message will be fragmented at the IP layer.
Considerations related to fragmentation are covered in Section 6.3. Considerations related to fragmentation are covered in Section 6.3.
The message format for exchange of BFCP in UDP datagrams is the same The message format for exchange of BFCP in UDP datagrams is the same
as for a TCP stream above. as for a TCP stream above.
Clients MUST announce their presence to the floor control server by Clients MUST announce their presence to the floor control server by
transmission of a Hello message. This Hello message MUST be transmission of a Hello message. This Hello message MUST be
responded to with a HelloAck message and only upon receipt can the responded to with a HelloAck message and only upon receipt of
client consider the floor control service as present and available. HelloAck can the client consider the floor control service as present
and available.
As described in Section 8, each request sent by a floor participant As described in Section 8, each request sent by a floor participant
or chair shall form a client transaction that expects an or chair shall form a client transaction that expects an
acknowledgement message back from the floor control server within a acknowledgement message back from the floor control server within a
retransmission window. Concordantly, messages sent by the floor retransmission window. Concordantly, messages sent by the floor
control server that are not transaction-completing (e.g. FloorStatus control server that are not transaction-completing (e.g. FloorStatus
announcements as part of a FloorQuery subscription) are server- announcements as part of a FloorQuery subscription) are server-
initiated transactions that require acknowledgement messages from the initiated transactions that require acknowledgement messages from the
floor participant and chair entities to which they were sent. floor participant and chair entities to which they were sent.
If a BFCP entity receives data that cannot be parsed, the receiving If a Floor Control Server receives data that cannot be parsed, the
participant MAY send an Error message with parameter value 10 receiving server MAY send an Error message with parameter value 10
indicating receipt of a malformed message. If the message can be (Unable to parse message) indicating receipt of a malformed message.
parsed to the extent that it is able to discern that it was a If the message can be parsed to the extent that it is able to discern
response to an outstanding request transaction, the client MAY that it was a response to an outstanding request transaction, the
discard the message and await retransmission. BFCP entities client MAY discard the message and await retransmission. BFCP
receiving an Error message with value 10 SHOULD acknowledge the error entities receiving an Error message with value 10 SHOULD acknowledge
and act accordingly. the error and act accordingly.
Transaction ID values are non-sequential and entities are at liberty Transaction ID values are non-sequential and entities are at liberty
to select values at random. Entities MUST only have at most one to select values at random. Entities MUST only have at most one
outstanding request transaction at any one time. Implicit outstanding request transaction at any one time. Implicit
subscriptions occur for a client-initiated request transaction whose subscriptions occur for a client-initiated request transaction whose
acknowledgement is implied by the first server-initiated response for acknowledgement is implied by the first server-initiated response for
that transaction, followed by zero of more subsequent server- that transaction, followed by zero of more subsequent server-
initiated messages corresponding to the same transaction. An example initiated messages corresponding to the same transaction. An example
is a FloorRequest message for which there are potentially multiple is a FloorRequest message for which there are potentially multiple
responses from the floor control server as it processes intermediate responses from the floor control server as it processes intermediate
states until a terminal state (e.g. Granted or Denied) is attained. states until a terminal state (e.g. Granted or Denied) is attained.
The subsequent changes in state for the request are new transactions The subsequent changes in state for the request are new transactions
whose Transaction ID is determined by the floor control server and whose Transaction ID is determined by the floor control server and
whose receipt by the client participant shall be acknowledged with a whose receipt by the client participant shall be acknowledged with a
FloorRequestStatusAck message. FloorRequestStatusAck message.
By restricting entities to having at most one pending transaction By restricting entities to having at most one pending transaction
open, both the out-of-order receipt of messages as well as the open in a BFCP connection, both the out-of-order receipt of messages
possibility for congestion are mitigated. Additional details as well as the possibility for congestion are mitigated. Additional
regarding congestion control are provided in Section 6.2.1. A details regarding congestion control are provided in Section 6.2.1.
server-initiated request (e.g. a FloorStatus with an update from the A server-initiated request (e.g. a FloorStatus with an update from
floor control server) received by a participant before the initial the floor control server) received by a participant before the
FloorRequestStatus message that closes the client-initiated initial FloorRequestStatus message that closes the client-initiated
transaction that was instigated by the FloorRequest MUST be treated transaction that was instigated by the FloorRequest MUST be treated
as superseding the information conveyed in any delinquent response. as superseding the information conveyed in any delinquent response.
As the floor control server cannot send a second update to the As the floor control server cannot send a second update to the
implicit floor status subscription until the first is acknowledged, implicit floor status subscription until the first is acknowledged,
ordinality is maintained. ordinality is maintained.
If a client wishes to end its BFCP association with a floor control If a client wishes to end its BFCP association with a floor control
server, it is RECOMMENDED that the client send a Goodbye message to server, it is RECOMMENDED that the client send a Goodbye message to
dissociate itself from any allocated resources. If a floor control dissociate itself from any allocated resources. If a floor control
server wishes to end its BFCP association with a client (e.g. the server wishes to end its BFCP association with a client (e.g. the
Focus of the conference informs the floor control server that the Focus of the conference informs the floor control server that the
client has been kicked out from the conference), it is RECOMMENDED client has been kicked out from the conference), it is RECOMMENDED
that the floor control server send a Goodbye message towards the that the floor control server send a Goodbye message towards the
client. client.
6.2.1. Congestion Control 6.2.1. Congestion Control
BFCP may be characterized to generate "low data-volume" traffic, per BFCP may be characterized to generate "low data-volume" traffic, per
the classification in [19]. Nevertheless is it necessary to ensure the classification in [19]. Nevertheless is it necessary to ensure
suitable and necessary congestion control mechanisms are used for suitable and necessary congestion control mechanisms are used for
BFCP over UDP. As described in previous paragraph every entity - BFCP over UDP. As described in previous paragraph, within the same
client or server - is only allowed to send one request at a time, and BFCP connection, every entity - client or server - is only allowed to
await the acknowledging response. This way at most one datagram is send one request at a time, and await the acknowledging response.
sent per RTT given the message is not lost during transmission. In This way at most one datagram is sent per RTT given the message is
case the message is lost, the request retransmission timer T1 not lost during transmission. In case the message is lost, the
specified in Section 8.3.1 will fire and the message is retransmitted request retransmission timer T1 specified in Section 8.3.1 will fire
up to three times. The default initial interval is set to 500ms and and the message is retransmitted up to three times, in addition to
the interval is doubled after each retransmission attempt, this is the original transmission of the message. The default initial
identical to the specification of the T1 timer in SIP as described in interval is set to 500ms and the interval is doubled after each
Section 17.1.1.2 of [16]. retransmission attempt, this is identical to the specification of the
T1 timer in SIP as described in Section 17.1.1.2 of [16].
6.2.2. ICMP Error Handling 6.2.2. ICMP Error Handling
If a BFCP entity receives an ICMP port unreachable message mid- If a BFCP entity receives an ICMP port unreachable message mid-
conversation, the entity SHOULD treat the conversation as closed conversation, the entity SHOULD treat the conversation as closed
(e.g. an implicit Goodbye message from the peer) and behave (e.g. an implicit Goodbye message from the peer). The entity MAY
accordingly. The entity MAY attempt to re-establish the conversation attempt to re-establish the conversation afresh. The new connection
afresh. The new connection will appear as a wholly new floor will appear as a wholly new floor participant, chair or floor control
participant, chair or floor control server with all state previously server with all state previously held about that participant lost.
held about that participant lost.
Note: This is because the peer entities cannot rely on IP and port Note: This is because the peer entities cannot rely on IP and port
tuple to uniquely identify the participant, nor would extending Hello tuple to uniquely identify the participant, nor would extending Hello
to include an attribute that advertised what the entity previously to include an attribute that advertised what the entity previously
was assigned as a User ID be acceptable due to session hijacking. was assigned as a User ID be acceptable due to session hijacking.
In deployments where NAT appliances, firewalls or other such devices In deployments where NAT appliances, firewalls or other such devices
are present and affecting port reachability for each entity, one are present and affecting port reachability for each entity, one
possibility is to utilize the peer connectivity checks, relay use and possibility is to utilize the peer connectivity checks, relay use and
NAT pinhole maintenance mechanisms defined in ICE [15]. NAT pinhole maintenance mechanisms defined in ICE [15].
skipping to change at page 45, line 32 skipping to change at page 45, line 27
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 reliable transports. when BFCP entities communicate over reliable transports.
8.3.1. Request Retransmission Timer, T1 8.3.1. Request Retransmission Timer, T1
T1 is a timer that schedules retransmission of a request until an T1 is a timer that schedules retransmission of a request until an
appropriate response is received or until the maximum number of appropriate response is received or until the maximum number of
retransmissions have occurred. The timer doubles on each re- retransmissions have occurred. The timer doubles on each re-
transmit, failing after three unacknowledged transmission attempts. transmit, failing after three unacknowledged retransmission attempts.
If a valid response is not received for a client- or server-initiated If a valid response is not received for a client- or server-initiated
transaction, the implementation MUST consider the BFCP association as transaction, the implementation MUST consider the BFCP association as
failed. Implementations SHOULD follow the reestablishment procedure failed. Implementations SHOULD follow the reestablishment procedure
described in section 6 (e.g. initiate a new offer/answer [12] described in section 6 (e.g. initiate a new offer/answer [12]
exchange). Alternatively, they MAY continue without BFCP and exchange). Alternatively, they MAY continue without BFCP and
therefore not be participant in any floor control actions. therefore not be participant in any floor control actions.
8.3.2. Response Retransmission Timer, T2 8.3.2. Response Retransmission Timer, T2
skipping to change at page 48, line 45 skipping to change at page 48, line 40
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.
10.1.2. Receiving a Response 10.1.2. Receiving a Response
When communicating over unreliable transport and upon receiving a A message from the floor control server is considered a response to
FloorRequest from a participant, the floor control server MUST the FloorRequest message if the message from the floor control server
respond with a FloorRequestStatus message within the transaction has the same Conference ID, Transaction ID, and User ID as the
failure window to complete the transaction. A message from the floor FloorRequest message, as described in Section 8.1. On receiving such
control server is considered a response to the FloorRequest message a response, the floor participant follows the rules in Section 9 that
if the message from the floor control server has the same Conference relate to floor control server authentication.
ID, Transaction ID, and User ID as the FloorRequest message, as
described in Section 8.1. On receiving such a response, the floor
participant follows the rules in Section 9 that relate to floor
control server authentication.
The successful processing of a FloorRequest message at the floor The successful processing of a FloorRequest message at the floor
control server involves generating one or several FloorRequestStatus control server involves generating one or several FloorRequestStatus
messages. The floor participant obtains a Floor Request ID in the messages. The floor participant obtains a Floor Request ID in the
Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in
the first FloorRequestStatus message from the floor control server. the first FloorRequestStatus message from the floor control server.
Subsequent FloorRequestStatus messages from the floor control server Subsequent FloorRequestStatus messages from the floor control server
regarding the same floor request will carry the same Floor Request ID regarding the same floor request will carry the same Floor Request ID
in a FLOOR-REQUEST-INFORMATION attribute as the initial in a FLOOR-REQUEST-INFORMATION attribute as the initial
FloorRequestStatus message. This way, the floor participant can FloorRequestStatus message. This way, the floor participant can
associate subsequent incoming FloorRequestStatus messages with the associate subsequent incoming FloorRequestStatus messages with the
ongoing floor request. ongoing floor request.
The floor participant obtains information about the status of the The floor participant obtains information about the status of the
floor request in the FLOOR-REQUEST-INFORMATION attribute of each of floor request in the FLOOR-REQUEST-INFORMATION attribute of each of
the FloorRequestStatus messages received from the floor control the FloorRequestStatus messages received from the floor control
skipping to change at page 50, line 10 skipping to change at page 50, line 5
as this floor participant is already identified by the User ID in the as this floor participant is already identified by the User ID in the
common header. common header.
The PRIORITY attribute, when present, contains the priority that was The PRIORITY attribute, when present, contains the priority that was
requested by the generator of the FloorRequest message. requested by the generator of the FloorRequest message.
If the response is an Error message, the floor control server could If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is not process the FloorRequest message for some reason, which is
described in the Error message. described in the Error message.
10.1.3. Reception of a Subsequent FloorRequestStatus Message
When communicating over unreliable transport and upon receiving a
FloorRequestStatus message from a floor control server, the
participant MUST respond with a FloorRequestStatusAck message within
the transaction failure window to complete the transaction.
10.2. Cancelling a Floor Request and Releasing a Floor 10.2. Cancelling a Floor Request and Releasing a Floor
A floor participant that wishes to cancel an ongoing floor request A floor participant that wishes to cancel an ongoing floor request
does so by sending a FloorRelease message to the floor control does so by sending a FloorRelease message to the floor control
server. The FloorRelease message is also used by floor participants server. The FloorRelease message is also used by floor participants
that hold a floor and would like to release it. that hold a floor and would like to release it.
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
skipping to change at page 50, line 48 skipping to change at page 50, line 50
the response to the FloorRequest message that the FloorRelease the response to the FloorRequest message that the FloorRelease
message is cancelling. message is cancelling.
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
When communicating over unreliable transport and upon receiving a A message from the floor control server is considered a response to
FloorRelease from a participant, the floor control server MUST the FloorRelease message if the message from the floor control server
respond with a FloorRequestStatus message within the transaction has the same Conference ID, Transaction ID, and User ID as the
failure window to complete the transaction. A message from the floor FloorRequest message, as described in Section 8.1. On receiving such
control server is considered a response to the FloorRelease message a response, the floor participant follows the rules in Section 9 that
if the message from the floor control server has the same Conference relate to floor control server authentication.
ID, Transaction ID, and User ID as the FloorRequest message, as
described in Section 8.1. On receiving such a response, the floor
participant follows the rules in Section 9 that 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.
It is possible that the FloorRelease message crosses on the wire with It is possible that the FloorRelease message crosses on the wire with
skipping to change at page 51, line 43 skipping to change at page 51, line 40
do so by sending a ChairAction message. do so by sending a ChairAction message.
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 sets the User ID in the common header to the floor chair's
participant's identifier. This User ID will be used by the floor identifier. This User ID will be used by the floor control server to
control server to authenticate and authorize the request. 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 53, line 7 skipping to change at page 52, line 50
information in the OVERALL-REQUEST-STATUS attribute, the floor information in the OVERALL-REQUEST-STATUS attribute, the floor
control server may override, modify, or ignore this field's control server may override, modify, or ignore this field's
content. content.
The floor chair may use STATUS-INFO attributes to state the reason The floor chair may use STATUS-INFO attributes to state the reason
why the floor or floors are being accepted, granted, or revoked. The why the floor or floors are being accepted, granted, or revoked. The
Text in the STATUS-INFO attribute is intended for human consumption. Text in the STATUS-INFO attribute is intended for human consumption.
11.2. Receiving a Response 11.2. Receiving a Response
When communicating over unreliable transport and upon receiving a A message from the floor control server is considered a response to
ChairAction from a participant, the floor control server MUST respond the ChairAction message if the message from the server has the same
with a ChairActionAck message within the transaction failure window Conference ID, Transaction ID, and User ID as the ChairAction
to complete the transaction. A message from the floor control server message, as described in Section 8.1. On receiving such a response,
is considered a response to the ChairAction message if the message the floor chair follows the rules in Section 9 that relate to floor
from the server has the same Conference ID, Transaction ID, and User control server authentication.
ID as the ChairAction message, as described in Section 8.1. On
receiving such a response, the floor chair follows the rules in
Section 9 that relate to floor control server authentication.
A ChairActionAck message from the floor control server confirms that A ChairActionAck message from the floor control server confirms that
the floor control server has accepted the ChairAction message. An the floor control server has accepted the ChairAction message. An
Error message indicates that the floor control server could not Error message indicates that the floor control server could not
process the ChairAction message for some reason, which is described process the ChairAction message for some reason, which is described
in the Error message. in the Error message.
12. General Client Operations 12. General Client Operations
This section specifies operations that can be performed by any This section specifies operations that can be performed by any
skipping to change at page 54, line 14 skipping to change at page 54, line 7
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
When communicating over unreliable transport and upon receiving a A message from the floor control server is considered a response to
FloorQuery from a participant, the floor control server MUST respond the FloorQuery message if the message from the floor control server
with a FloorStatus message within the transaction failure window to has the same Conference ID, Transaction ID, and User ID as the
complete the transaction. A message from the floor control server is FloorRequest message, as described in Section 8.1. On receiving such
considered a response to the FloorQuery message if the message from a response, the client follows the rules in Section 9 that relate to
the floor control server has the same Conference ID, Transaction ID, floor control server authentication.
and User ID as the FloorRequest message, as described in Section 8.1.
On receiving such a response, the client follows the rules in
Section 9 that relate to floor control server authentication.
On reception of the FloorQuery message, the floor control server will On reception of the FloorQuery message, the floor control server will
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 54, line 46 skipping to change at page 54, line 36
floor requests that relate to that floor. The information about each floor requests that relate to that floor. The information about each
particular floor request is encoded in a FLOOR-REQUEST-INFORMATION particular floor request is encoded in a FLOOR-REQUEST-INFORMATION
attribute. This grouped attribute carries a Floor Request ID that attribute. This grouped attribute carries a Floor Request ID that
identifies the floor request, followed by a set of attributes that identifies the floor request, followed by a set of attributes that
provide information about the floor request. provide information about the floor request.
After the first FloorStatus, the floor control server will continue After the first FloorStatus, the floor control server will continue
sending FloorStatus messages, periodically informing the client about sending FloorStatus messages, periodically informing the client about
changes on the floors the client requested information about. changes on the floors the client requested information about.
12.1.3. Reception of a Subsequent FloorStatus Message
When communicating over unreliable transport and upon receiving a
FloorStatus message from a floor control server, the participant MUST
respond with a FloorStatusAck message within the transaction failure
window to complete the transaction.
12.2. Requesting Information about Floor Requests 12.2. Requesting Information about Floor Requests
A client can obtain information about the status of one or several A client can obtain information about the status of one or several
floor requests in different ways, which include using BFCP and using floor requests in different ways, which include using BFCP and using
out-of-band mechanisms. Clients using BFCP to obtain such out-of-band mechanisms. Clients using BFCP to obtain such
information use the procedures described in this section. information use the procedures described in this section.
Clients request information about the current status of a floor Clients request information about the current status of a floor
request by sending a FloorRequestQuery message to the floor control request by sending a FloorRequestQuery message to the floor control
server. server.
skipping to change at page 55, line 37 skipping to change at page 55, line 33
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 This User ID will be used by the floor control server to authenticate
and authorize the request. 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
When communicating over unreliable transport and upon receiving a A message from the floor control server is considered a response to
FloorRequestQuery from a participant, the floor control server MUST the FloorRequestQuery message if the message from the floor control
respond with a FloorRequestStatus message within the transaction server has the same Conference ID, Transaction ID, and User ID as the
failure window to complete the transaction. A message from the floor FloorRequestQuery message, as described in Section 8.1. On receiving
control server is considered a response to the FloorRequestQuery such a response, the client follows the rules in Section 9 that
message if the message from the floor control server has the same relate to floor control server authentication.
Conference ID, Transaction ID, and User ID as the FloorRequestQuery
message, as described in Section 8.1. On receiving such a response,
the client follows the rules in Section 9 that relate to floor
control server authentication.
If the response is a FloorRequestStatus message, the client obtains If the response is a FloorRequestStatus message, the client obtains
information about the status of the FloorRequest the client requested information about the status of the FloorRequest the client requested
information about in a FLOOR-REQUEST-INFORMATION attribute. information about in a FLOOR-REQUEST-INFORMATION attribute.
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 FloorRequestQuery message for some reason, which is not process the FloorRequestQuery message for some reason, which is
described in the Error message. described in the Error message.
12.3. Requesting Information about a User 12.3. Requesting Information about a User
skipping to change at page 56, line 46 skipping to change at page 56, line 38
This User ID will be used by the floor control server to authenticate This User ID will be used by the floor control server to authenticate
and authorize the request. 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
When communicating over unreliable transport and upon receiving a A message from the floor control server is considered a response to
UserQuery from a participant, the floor control server MUST respond the UserQuery message if the message from the floor control server
with a UserStatus message within the transaction failure window to has the same Conference ID, Transaction ID, and User ID as the
complete the transaction. A message from the floor control server is UserQuery message, as described in Section 8.1. On receiving such a
considered a response to the UserQuery message if the message from response, the client follows the rules in Section 9 that relate to
the floor control server has the same Conference ID, Transaction ID, floor control server authentication.
and User ID as the UserQuery message, as described in Section 8.1.
On receiving such a response, the client follows the rules in
Section 9 that relate to floor control server authentication.
If the response is a UserStatus message, the client obtains If the response is a UserStatus message, the client obtains
information about the floor participant in a BENEFICIARY-INFORMATION information about the floor participant in a BENEFICIARY-INFORMATION
grouped attribute and about the status of the floor requests grouped attribute and about the status of the floor requests
associated with the floor participant in FLOOR-REQUEST-INFORMATION associated with the floor participant in FLOOR-REQUEST-INFORMATION
attributes. attributes.
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 UserQuery message for some reason, which is described not process the UserQuery message for some reason, which is described
in the Error message. in the Error message.
skipping to change at page 57, line 38 skipping to change at page 57, line 27
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 This User ID will be used by the floor control server to authenticate
and authorize the request. and authorize the request.
12.4.2. Receiving Responses 12.4.2. Receiving Responses
When communicating over unreliable transport and upon receiving a A message from the floor control server is considered a response to
Hello from a participant, the floor control server MUST respond with the Hello message by the client if the message from the floor control
a HelloAck message within the transaction failure window to complete server has the same Conference ID, Transaction ID, and User ID as the
the transaction. A message from the floor control server is Hello message, as described in Section 8.1. On receiving such a
considered a response to the Hello message by the client if the response, the client follows the rules in Section 9 that relate to
message from the floor control server has the same Conference ID, floor control server authentication.
Transaction ID, and User ID as the Hello message, as described in
Section 8.1. On receiving such a response, the client follows the
rules in Section 9 that relate to floor control server
authentication.
If the response is a HelloAck message, the floor control server could If the response is a HelloAck message, the floor control server could
process the Hello message successfully. The SUPPORTED-PRIMITIVES and process the Hello message successfully. The SUPPORTED-PRIMITIVES and
SUPPORTED-ATTRIBUTES attributes indicate which primitives and SUPPORTED-ATTRIBUTES attributes indicate which primitives and
attributes, respectively, are supported by the server. attributes, respectively, are supported by the server.
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 Hello message for some reason, which is described in not process the Hello message for some reason, which is described in
the Error message. the Error message.
13. Floor Control Server Operations 13. Floor Control Server Operations
This section specifies how floor control servers can perform This section specifies how floor control servers can perform
different operations, such as granting a floor, using the protocol different operations, such as granting a floor, using the protocol
elements described in earlier sections. elements described in earlier sections.
On reception of a message from a client, the floor control server On reception of a message from a client, the floor control server
MUST check whether the value of the Primitive is supported. If it MUST check whether the value of the Primitive is supported. If it is
does not, the floor control server SHOULD send an Error message, as not, the floor control server SHOULD send an Error message, as
described in Section 13.8, with Error code 3 (Unknown Primitive). described in Section 13.8, with Error code 3 (Unknown Primitive).
On reception of a message from a client, the floor control server On reception of a message from a client, the floor control server
MUST check whether the value of the Conference ID matched an existing MUST check whether the value of the Conference ID matched an existing
conference. If it does not, the floor control server SHOULD send an conference. If it does not, the floor control server SHOULD send an
Error message, as described in Section 13.8, with Error code 1 Error message, as described in Section 13.8, with Error code 1
(Conference does not Exist). (Conference does not Exist).
On reception of a message from a client, the floor control server On reception of a message from a client, the floor control server
follows the rules in Section 9 that relate to the authentication of follows the rules in Section 9 that relate to the authentication of
the message. the message.
On reception of a message from a client, the floor control server On reception of a message from a client, the floor control server
MUST check whether it understands all the mandatory ('M' bit set) MUST check whether it understands all the mandatory ('M' bit set)
attributes in the message. If the floor control server does not attributes in the message. If the floor control server does not
understand all of them, the floor control server SHOULD send an Error understand all of them, the floor control server SHOULD send an Error
message, as described in Section 13.8, with Error code 2 message, as described in Section 13.8, with Error code 4 (Unknown
(Authentication Failed). The Error message SHOULD list the Mandatory Attribute). The Error message SHOULD list the attributes
attributes that were not understood. that were not understood.
13.1. Reception of a FloorRequest Message 13.1. Reception of a FloorRequest Message
On reception of a FloorRequest message, the floor control server On reception of a FloorRequest message, the floor control server
follows the rules in Section 9 that relate to client authentication follows the rules in Section 9 that relate to client authentication
and authorization. If while processing the FloorRequest message, the and authorization. If while processing the FloorRequest message, the
floor control server encounters an error, it SHOULD generate an Error floor control server encounters an error, it SHOULD generate an Error
response following the procedures described in Section 13.8. response following the procedures described in Section 13.8.
BFCP allows floor participants to have several ongoing floor BFCP allows floor participants to have several ongoing floor
requests for the same floor (e.g., the same floor participant can requests for the same floor (e.g., the same floor participant can
occupy more than one position in a queue at the same time). A occupy more than one position in a queue at the same time). A
floor control server that only supports a certain number of floor control server that only supports a certain number of
ongoing floor requests per floor participant (e.g., one) can use ongoing floor requests per floor participant (e.g., one) can use
Error Code 8 (You have Already Reached the Maximum Number of Error Code 8 (You have Already Reached the Maximum Number of
Ongoing Floor Requests for this Floor) to inform the floor Ongoing Floor Requests for this Floor) to inform the floor
participant. participant.
When communicating over unreliable transport and upon receiving a
FloorRequest from a participant, the floor control server MUST
respond with a FloorRequestStatus message within the transaction
failure window to complete the transaction.
13.1.1. Generating the First FloorRequestStatus Message 13.1.1. Generating the First FloorRequestStatus Message
The successful processing of a FloorRequest message by a floor The successful processing of a FloorRequest message by a floor
control server involves generating one or several FloorRequestStatus control server involves generating one or several FloorRequestStatus
messages, the first of which SHOULD be generated as soon as possible. messages, the first of which SHOULD be generated as soon as possible.
If the floor control server cannot accept, grant, or deny the floor If the floor control server cannot accept, grant, or deny the floor
request right away (e.g., a decision from a chair is needed), it request right away (e.g., a decision from a chair is needed), it
SHOULD use a Request Status value of Pending in the OVERALL-REQUEST- SHOULD use a Request Status value of Pending in the OVERALL-REQUEST-
STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped
attribute) of the first FloorRequestStatus message it generates. attribute) of the first FloorRequestStatus message it generates.
The policy that a floor control server follows to grant or deny The policy that a floor control server follows to grant or deny
floors is outside the scope of this document. A given floor floors is outside the scope of this document. A given floor
control server may perform these decisions automatically while control server may perform these decisions automatically while
another may contact a human acting as a chair every time a another may contact a human acting as a chair every time a
skipping to change at page 60, line 49 skipping to change at page 60, line 37
When the status of the floor request changes, the floor control When the status of the floor request changes, the floor control
server SHOULD send new FloorRequestStatus messages with the server SHOULD send new FloorRequestStatus messages with the
appropriate Request Status. The floor control server MUST add a appropriate Request Status. The floor control server MUST add a
FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to
the one sent in the first FloorRequestStatus message to any new the one sent in the first FloorRequestStatus message to any new
FloorRequestStatus related to the same floor request. (The Floor FloorRequestStatus related to the same floor request. (The Floor
Request ID identifies the floor request to which the Request ID identifies the floor request to which the
FloorRequestStatus applies.) FloorRequestStatus applies.)
The floor control server MUST set the Transaction ID of subsequent When using BFCP over reliable transports, the floor control server
FloorRequestStatus messages to 0. MUST set the Transaction ID of subsequent FloorRequestStatus messages
to 0. When using BFCP over unreliable transports, the Transaction ID
MUST be non-zero and unique in the context of outstanding
transactions over unreliable transports as described in Section 8.
The rate at which the floor control server sends The rate at which the floor control server sends
FloorRequestStatus messages is a matter of local policy. A floor FloorRequestStatus messages is a matter of local policy. A floor
control server may choose to send a new FloorRequestStatus message control server may choose to send a new FloorRequestStatus message
every time the floor request moves in the floor request queue, every time the floor request moves in the floor request queue,
while another may choose only to send a new FloorRequestStatus while another may choose only to send a new FloorRequestStatus
message when the floor request is Granted or Denied. message when the floor request is Granted or Denied.
The floor control server may add a STATUS-INFO attribute to any of The floor control server may add a STATUS-INFO attribute to any of
the FloorRequestStatus messages it generates to provide extra the FloorRequestStatus messages it generates to provide extra
skipping to change at page 61, line 32 skipping to change at page 61, line 21
needs to follow the procedures in Section 13.5 to inform the needs to follow the procedures in Section 13.5 to inform the
clients that have requested that information. clients that have requested that information.
The common header and the rest of the attributes are the same as in The common header and the rest of the attributes are the same as in
the first FloorRequestStatus message. the first FloorRequestStatus message.
The floor control server can discard the state information about a The floor control server can discard the state information about a
particular floor request when this reaches a status of Cancelled, particular floor request when this reaches a status of Cancelled,
Released, or Revoked. Released, or Revoked.
13.1.3. Reception of a FloorRequestStatus Message When communicating over unreliable transport and a
FloorRequestStatusAck message is not received within the transaction
When communicating over unreliable transport and upon receiving a failure window, the floor control server MUST retransmit the
FloorRequestStatus message from a floor control server, the FloorRequestStatus message according to Section 6.2.
participant MUST respond with a FloorRequestStatusAck message within
the transaction failure window to complete the transaction.
13.2. Reception of a FloorRequestQuery Message 13.2. Reception of a FloorRequestQuery Message
On reception of a FloorRequestQuery message, the floor control server On reception of a FloorRequestQuery message, the floor control server
follows the rules in Section 9 that relate to client authentication follows the rules in Section 9 that relate to client authentication
and authorization. If while processing the FloorRequestQuery and authorization. If while processing the FloorRequestQuery
message, the floor control server encounters an error, it SHOULD message, the floor control server encounters an error, it SHOULD
generate an Error response following the procedures described in generate an Error response following the procedures described in
Section 13.8. Section 13.8.
The successful processing of a FloorRequestQuery message by a floor The successful processing of a FloorRequestQuery message by a floor
control server involves generating a FloorRequestStatus message, control server involves generating a FloorRequestStatus message,
which SHOULD be generated as soon as possible. which SHOULD be generated as soon as possible.
When communicating over unreliable transport and upon receiving a
FloorRequestQuery from a participant, the floor control server MUST
respond with a FloorRequestStatus message within 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-ID attribute from the FloorRequestQuery message into FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into
the Floor Request ID field of the FLOOR-REQUEST-INFORMATION the Floor Request ID field of the FLOOR-REQUEST-INFORMATION
skipping to change at page 63, line 9 skipping to change at page 62, line 50
On reception of a UserQuery message, the floor control server follows On reception of a UserQuery message, the floor control server follows
the rules in Section 9 that relate to client authentication and the rules in Section 9 that relate to client authentication and
authorization. If while processing the UserQuery message, the floor authorization. If while processing the UserQuery message, the floor
control server encounters an error, it SHOULD generate an Error control server encounters an error, it SHOULD generate an Error
response following the procedures described in Section 13.8. response following the procedures described in Section 13.8.
The successful processing of a UserQuery message by a floor control The successful processing of a UserQuery message by a floor control
server involves generating a UserStatus message, which SHOULD be server involves generating a UserStatus message, which SHOULD be
generated as soon as possible. generated as soon as possible.
When communicating over unreliable transport and upon receiving a
UserQuery from a participant, the floor control server MUST respond
with a UserStatus message within 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 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.
skipping to change at page 64, line 33 skipping to change at page 64, line 33
On reception of a FloorRelease message, the floor control server On reception of a FloorRelease message, the floor control server
follows the rules in Section 9 that relate to client authentication follows the rules in Section 9 that relate to client authentication
and authorization. If while processing the FloorRelease message, the and authorization. If while processing the FloorRelease message, the
floor control server encounters an error, it SHOULD generate an Error floor control server encounters an error, it SHOULD generate an Error
response following the procedures described in Section 13.8. response following the procedures described in Section 13.8.
The successful processing of a FloorRelease message by a floor The successful processing of a FloorRelease message by a floor
control server involves generating a FloorRequestStatus message, control server involves generating a FloorRequestStatus message,
which SHOULD be generated as soon as possible. which SHOULD be generated as soon as possible.
When communicating over unreliable transport and upon receiving a
FloorRelease from a participant, the floor control server MUST
respond with a FloorRequestStatus message within the transaction
failure window to complete the transaction.
The floor control server MUST copy the Conference ID, the Transaction The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the FloorRelease message into the ID, and the User ID from the FloorRelease message into the
FloorRequestStatus message, as described in Section 8.2. FloorRequestStatus message, as described in Section 8.2.
The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
attribute to the FloorRequestStatus. The attributes contained in attribute to the FloorRequestStatus. The attributes contained in
this grouped attribute carry information about the floor request. this grouped attribute carry information about the floor request.
The FloorRelease message identifies the floor request it applies to The FloorRelease message identifies the floor request it applies to
using a FLOOR-REQUEST-ID. The floor control server MUST copy the using a FLOOR-REQUEST-ID. The floor control server MUST copy the
contents of the FLOOR-REQUEST-ID attribute from the FloorRelease contents of the FLOOR-REQUEST-ID attribute from the FloorRelease
message into the Floor Request ID field of the FLOOR-REQUEST- message into the Floor Request ID field of the FLOOR-REQUEST-
INFORMATION attribute. INFORMATION attribute.
The floor control server MUST identify the floors being requested The floor control server MUST identify the floors being released
(i.e., the floors associated with the floor request identified by the (i.e., the floors associated with the floor request identified by the
FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the
FLOOR-REQUEST-INFORMATION grouped attribute. FLOOR-REQUEST-INFORMATION grouped attribute.
The floor control server MUST add an OVERALL-REQUEST-STATUS attribute The floor control server MUST add an OVERALL-REQUEST-STATUS attribute
to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request
Status value SHOULD be Released, if the floor (or floors) had been Status value SHOULD be Released, if the floor (or floors) had been
previously granted, or Cancelled, if the floor (or floors) had not previously granted, or Cancelled, if the floor (or floors) had not
been previously granted. The floor control server MAY add a STATUS- been previously granted. The floor control server MAY add a STATUS-
INFO attribute with extra information about the floor request. INFO attribute with extra information about the floor request.
13.5. Reception of a FloorQuery Message 13.5. Reception of a FloorQuery Message
On reception of a FloorQuery message, the floor control server On reception of a FloorQuery message, the floor control server
follows the rules in Section 9 that relate to client authentication. follows the rules in Section 9 that relate to client authentication.
If while processing the FloorRelease message, the floor control If while processing the FloorQuery message, the floor control server
server encounters an error, it SHOULD generate an Error response encounters an error, it SHOULD generate an Error response following
following the procedures described in Section 13.8. the procedures described in Section 13.8.
When communicating over unreliable transport and upon receiving a
FloorQuery from a participant, the floor control server MUST respond
with a FloorStatus message within the transaction failure window to
complete the transaction.
A floor control server receiving a FloorQuery message from a client A floor control server receiving a FloorQuery message from a client
SHOULD keep this client informed about the status of the floors SHOULD keep this client informed about the status of the floors
identified by FLOOR-ID attributes in the FloorQuery message. Floor identified by FLOOR-ID attributes in the FloorQuery message. Floor
Control Servers keep clients informed by using FloorStatus messages. Control Servers keep clients informed by using FloorStatus messages.
An individual FloorStatus message carries information about a single An individual FloorStatus message carries information about a single
floor. So, when a FloorQuery message requests information about more floor. So, when a FloorQuery message requests information about more
than one floor, the floor control server needs to send separate than one floor, the floor control server needs to send separate
FloorStatus messages for different floors. FloorStatus messages for different floors.
skipping to change at page 67, line 5 skipping to change at page 67, line 14
in the FLOOR-REQUEST-STATUS attributes. in the FLOOR-REQUEST-STATUS attributes.
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. 0 when using reliable transports and non-zero and unique in the
context of outstanding transactions when using unreliable transports
(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. Transaction ID of these messages MUST be 0 when using reliable
transports and non-zero and unique in the context of outstanding
transactions when using unreliable transports (cf. Section 8).
The rate at which the floor control server sends FloorStatus The rate at which the floor control server sends FloorStatus
messages is a matter of local policy. A floor control server may messages is a matter of local policy. A floor control server may
choose to send a new FloorStatus message every time a new floor choose to send a new FloorStatus message every time a new floor
request arrives, while another may choose to only send a new request arrives, while another may choose to only send a new
FloorStatus message when a new floor request is Granted. FloorStatus message when a new floor request is Granted.
13.5.3. Reception of a FloorStatus Message When communicating over unreliable transport and a FloorStatusAck
message is not received within the transaction failure window, the
When communicating over unreliable transport and upon receiving a floor control server MUST retransmit the FloorStatus message
FloorStatus message from a floor control server, the participant MUST according to Section 6.2.
respond with a FloorStatusAck message within the transaction failure
window to complete the transaction.
13.6. Reception of a ChairAction Message 13.6. Reception of a ChairAction Message
On reception of a ChairAction message, the floor control server On reception of a ChairAction message, the floor control server
follows the rules in Section 9 that relate to client authentication follows the rules in Section 9 that relate to client authentication
and authorization. If while processing the ChairAction message, the and authorization. If while processing the ChairAction message, the
floor control server encounters an error, it SHOULD generate an Error floor control server encounters an error, it SHOULD generate an Error
response following the procedures described in Section 13.8. response following the procedures described in Section 13.8.
The successful processing of a ChairAction message by a floor control The successful processing of a ChairAction message by a floor control
server involves generating a ChairActionAck message, which SHOULD be server involves generating a ChairActionAck message, which SHOULD be
generated as soon as possible. generated as soon as possible.
When communicating over unreliable transport and upon receiving a
ChairAction from a chair, the floor control server MUST respond with
a ChairActionAck message within 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 ChairAction message into the ID, and the User ID from the ChairAction message into the
ChairActionAck message, as described in Section 8.2. ChairActionAck message, as described in Section 8.2.
The floor control server needs to take into consideration the The floor control server needs to take into consideration the
operation requested in the ChairAction message (e.g., granting a operation requested in the ChairAction message (e.g., granting a
floor) but does not necessarily need to perform it as requested by floor) but does not necessarily need to perform it as requested by
the floor chair. The operation that the floor control server the floor chair. The operation that the floor control server
performs depends on the ChairAction message and on the internal state performs depends on the ChairAction message and on the internal state
of the floor control server. of the floor control server.
skipping to change at page 68, line 26 skipping to change at page 68, line 42
applies if the floor control server implements a queue.) applies if the floor control server implements a queue.)
13.7. Reception of a Hello Message 13.7. Reception of a Hello Message
On reception of a Hello message, the floor control server follows the On reception of a Hello message, the floor control server follows the
rules in Section 9 that relate to client authentication. If while rules in Section 9 that relate to client authentication. If while
processing the Hello message, the floor control server encounters an processing the Hello message, the floor control server encounters an
error, it SHOULD generate an Error response following the procedures error, it SHOULD generate an Error response following the procedures
described in Section 13.8. described in Section 13.8.
When communicating over unreliable transport and upon receiving a
Hello from a participant, the floor control server MUST respond with
a HelloAck message within the transaction failure window to complete
the transaction.
The successful processing of a Hello message by a floor control The successful processing of a Hello message by a floor control
server involves generating a HelloAck message, which SHOULD be server involves generating a HelloAck message, which SHOULD be
generated as soon as possible. The floor control server MUST copy generated as soon as possible. The floor control server MUST copy
the Conference ID, the Transaction ID, and the User ID from the Hello the Conference ID, the Transaction ID, and the User ID from the Hello
into the HelloAck, as described in Section 8.2. into the HelloAck, as described in Section 8.2.
The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to
the HelloAck message listing all the primitives (i.e., BFCP messages) the HelloAck message listing all the primitives (i.e., BFCP messages)
supported by the floor control server. supported by the floor control server.
skipping to change at page 69, line 10 skipping to change at page 69, line 30
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 message from the client into the Error ID, and the User ID from the message from the client into the Error
message, as described in Section 8.2. message, as described in Section 8.2.
The floor control server MUST add an ERROR-CODE attribute to the The floor control server MUST add an ERROR-CODE attribute to the
Error message. The ERROR-CODE attribute contains an Error Code from Error message. The ERROR-CODE attribute contains an Error Code from
Table 5. Additionally, the floor control server may add an ERROR- Table 5. Additionally, the floor control server may add an ERROR-
INFO attribute with extra information about the error. INFO attribute with extra information about the error.
13.9. Reception of an Error Message
When communicating over unreliable transport and upon receiving an
Error message from a floor control server, the participant MUST
respond with a ErrorAck message within the transaction failure window
to complete the transaction.
14. Security Considerations 14. Security Considerations
BFCP uses TLS/DTLS to provide mutual authentication between clients BFCP uses TLS/DTLS to provide mutual authentication between clients
and servers. TLS/DTLS also provides replay and integrity protection and servers. TLS/DTLS also provides replay and integrity protection
and confidentiality. It is RECOMMENDED that TLS/DTLS with non-null and confidentiality. It is RECOMMENDED that TLS/DTLS with non-null
encryption always be used. BFCP entities MAY use other security encryption always be used. BFCP entities MAY use other security
mechanisms as long as they provide similar security properties. mechanisms as long as they provide similar security properties.
The remainder of this section analyzes some of the threats against The remainder of this section analyzes some of the threats against
BFCP and how they are addressed. BFCP and how they are addressed.
skipping to change at page 69, line 42 skipping to change at page 70, line 7
authenticated TLS/DTLS connections. The floor control server assumes authenticated TLS/DTLS connections. The floor control server assumes
that attackers cannot highjack the TLS/DTLS connection and, that attackers cannot highjack the TLS/DTLS connection and,
therefore, that messages over the TLS/DTLS connection come from the therefore, that messages over the TLS/DTLS connection come from the
client that was initially authenticated. client that was initially authenticated.
An attacker may attempt to impersonate a floor control server. A An attacker may attempt to impersonate a floor control server. A
successful attacker would be able to make clients think that they successful attacker would be able to make clients think that they
hold a particular floor so that they would try to access a resource hold a particular floor so that they would try to access a resource
(e.g., sending media) without having legitimate rights to access it. (e.g., sending media) without having legitimate rights to access it.
Floor control server impersonation is avoided by having servers only Floor control server impersonation is avoided by having servers only
accept BFCP messages over authenticated TLS/DTLS connections. accept BFCP messages over authenticated TLS/DTLS connections, as well
as ensuring clients only send and accept messages over authenticated
TLS/DTLS connections.
Attackers may attempt to modify messages exchanged by a client and a Attackers may attempt to modify messages exchanged by a client and a
floor control server. The integrity protection provided by TLS/DTLS floor control server. The integrity protection provided by TLS/DTLS
connections prevents this attack. connections prevents this attack.
An attacker may attempt to fetch a valid message sent by a client to An attacker may attempt to fetch a valid message sent by a client to
a floor control server and replay it over a connection between the a floor control server and replay it over a connection between the
attacker and the floor control server. This attack is prevented by attacker and the floor control server. This attack is prevented by
having floor control servers check that messages arriving over a having floor control servers check that messages arriving over a
given authenticated TLS/DTLS connection use an authorized user ID given authenticated TLS/DTLS connection use an authorized user ID
skipping to change at page 70, line 20 skipping to change at page 70, line 35
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 RECOMMENDED confidentiality prevents this attack. Therefore, it is RECOMMENDED
that TLS/DTLS be used with a non-null encryption algorithm. that TLS/DTLS be used with a non-null encryption algorithm.
15. IANA Considerations 15. IANA Considerations
[Editorial note: This section instructs the IANA to register new [Editorial note: 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.]
This IANA has created a new registry for BFCP parameters called The IANA has created a registry for BFCP parameters called "Binary
"Binary Floor Control Protocol (BFCP) Parameters". This new registry Floor Control Protocol (BFCP) Parameters". This registry has a
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 [3], the Parameters registry. As per the terminology in RFC 5226 [3], 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,
skipping to change at page 71, line 34 skipping to change at page 71, line 36
| 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 [Editorial note: 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, ErrorAck, FloorStatusAck, Goodbye, and FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.]
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 [3], the Parameters registry. As per the terminology in RFC 5226 [3], 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
skipping to change at page 72, line 22 skipping to change at page 72, line 22
| 5 | UserQuery | [RFC XXXX] | | 5 | UserQuery | [RFC XXXX] |
| 6 | UserStatus | [RFC XXXX] | | 6 | UserStatus | [RFC XXXX] |
| 7 | FloorQuery | [RFC XXXX] | | 7 | FloorQuery | [RFC XXXX] |
| 8 | FloorStatus | [RFC XXXX] | | 8 | FloorStatus | [RFC XXXX] |
| 9 | ChairAction | [RFC XXXX] | | 9 | ChairAction | [RFC XXXX] |
| 10 | ChairActionAck | [RFC XXXX] | | 10 | ChairActionAck | [RFC XXXX] |
| 11 | Hello | [RFC XXXX] | | 11 | Hello | [RFC XXXX] |
| 12 | HelloAck | [RFC XXXX] | | 12 | HelloAck | [RFC XXXX] |
| 13 | Error | [RFC XXXX] | | 13 | Error | [RFC XXXX] |
| 14 | FloorRequestStatusAck | [RFC XXXX] | | 14 | FloorRequestStatusAck | [RFC XXXX] |
| 15 | ErrorAck | [RFC XXXX] | | 15 | FloorStatusAck | [RFC XXXX] |
| 16 | FloorStatusAck | [RFC XXXX] | | 16 | Goodbye | [RFC XXXX] |
| 17 | Goodbye | [RFC XXXX] | | 17 | GoodbyeAck | [RFC XXXX] |
| 18 | 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 [3], BFCP Parameters registry. As per the terminology in RFC 5226 [3],
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
skipping to change at page 74, line 30 skipping to change at page 74, line 30
| 11 | Use DTLS | [RFC XXXX] | | 11 | Use DTLS | [RFC XXXX] |
| 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 fixes from [17]. Following is the list of technical changes and other non-trivial
fixes from [17].
Main purpose of this work was to revise the specification to support Main purpose of this work was to revise the specification to support
BFCP over unreliable transport, resulting in the following changes: BFCP over unreliable transport, resulting in the following changes:
Overview of Operation (Section 4): Overview of Operation (Section 4):
Expand the description of client-initiated and server-initiated Expand the description of client-initiated and server-initiated
transactions. transactions.
COMMON-HEADER Format (Section 5.1): COMMON-HEADER Format (Section 5.1):
Ver(sion) field, where the value 2 is used for the extensions Ver(sion) field, where the value 2 is used for the extensions
for unreliable transport. Added new R and F flag-bits for for unreliable transport. Added new R and F flag-bits for
unreliable transport. Res(erved) field is now 3 bit. New unreliable transport. Res(erved) field is now 3 bit. New
optional Fragment Offset and Fragment Length fields. optional Fragment Offset and Fragment Length fields.
New primitives (Section 5.1): New primitives (Section 5.1):
Added five new primitives: FloorRequestStatusAck, ErrorAck, Added five new primitives: FloorRequestStatusAck,
FloorStatusAck, Goodbye, and GoodbyeAck. FloorStatusAck, Goodbye, and GoodbyeAck.
New error codes (Section 5.2.6): New error codes (Section 5.2.6):
Added three new error codes: "Unable to Parse Message", "Use Added three new error codes: "Unable to Parse Message", "Use
DTLS" and "Unsupported Version". DTLS" and "Unsupported Version".
ABNF for new primitives (Section 5.3): ABNF for new primitives (Section 5.3):
New subsections with normative ABNF for the new primitives. New subsections with normative ABNF for the new primitives.
Transport split in two (Section 6): Transport split in two (Section 6):
skipping to change at page 75, line 30 skipping to change at page 75, line 30
Mandate DTLS support when transport over UDP is used. Mandate DTLS support when transport over UDP is used.
Transaction changes (Section 8): Transaction changes (Section 8):
Server-initiated transactions over unreliable transport has Server-initiated transactions over unreliable transport has
non-zero and unique Transaction ID. Over unreliable transport, non-zero and unique Transaction ID. Over unreliable transport,
the retransmit timers T1 and T2 described in Section 8.3 the retransmit timers T1 and T2 described in Section 8.3
applies. applies.
Requiring timely response (Section 10.1.2, Section 10.2.2, Requiring timely response (Section 10.1.2, Section 10.2.2,
Section 11.2, Section 12.1.2, Section 12.2.2, Section 12.3.2, Section 11.2, Section 12.1.2, Section 12.2.2, Section 12.3.2,
Section 12.4.2, Section 13.1.3, Section 13.5.3 and Section 12.4.2, Section 10.1.3 and Section 12.1.3):
Section 13.9):
Describing that a given response must be sent within the Describing that a given response must be sent within the
transaction failure window to complete the transaction. transaction failure window to complete the transaction.
Updated IANA Considerations (Section 15): Updated IANA Considerations (Section 15):
Added the new primitives and error codes to Section 15.2 and Added the new primitives and error codes to Section 15.2 and
Section 15.4 respectively. Section 15.4 respectively.
Examples over unreliable transport (Appendix A): Examples over unreliable transport (Appendix A):
Added sample interactions over unreliable transport for the Added sample interactions over unreliable transport for the
scenarios in Figure 2 and Figure 3 scenarios in Figure 2 and Figure 3
skipping to change at page 76, line 36 skipping to change at page 76, line 30
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 [17]. Additionally, Xiaotao Wu, Paul Kyzivat, ideas for RFC 4582 [17]. 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, Vijaya Mandava and Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman,
Alan Ford. Vijaya Mandava and Alan Ford. In the final phase Erns Horvath did a
thorough review revealing issues that needed clarification and
changes.
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 Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 77, line 16 skipping to change at page 77, line 13
Protocol Version 1.2", RFC 5246, August 2008. Protocol Version 1.2", RFC 5246, August 2008.
[5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
[7] Camarillo, G. and T. Kristensen, Ed., "Session Description [7] Camarillo, G. and T. Kristensen, Ed., "Session Description
Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Protocol (SDP) Format for Binary Floor Control Protocol (BFCP)
Streams", draft-ietf-bfcpbis-rfc4583bis-01 (work in progress), Streams", draft-ietf-bfcpbis-rfc4583bis-02 (work in progress),
June 2012. July 2012.
[8] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for [8] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for
Establishing a Secure Real-time Transport Protocol (SRTP) Establishing a Secure Real-time Transport Protocol (SRTP)
Security Context Using Datagram Transport Layer Security Security Context Using Datagram Transport Layer Security
(DTLS)", RFC 5763, May 2010. (DTLS)", RFC 5763, May 2010.
[9] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [9] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007. BCP 131, RFC 4961, July 2007.
[10] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [10] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
skipping to change at page 80, line 23 skipping to change at page 80, line 20
|Transaction ID: 154 | |Transaction ID: 154 |
|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 49: Requesting and releasing a floor Figure 48: Requesting and releasing a floor
Note that in Figure 49, 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. It does not and SHOULD NOT be 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 ID: 257 | |Transaction ID: 257 |
skipping to change at page 82, line 16 skipping to change at page 82, line 13
| Floor ID: 543 | | Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(6) FloorStatusAck | |(6) FloorStatusAck |
|Transaction ID: 4392 | |Transaction ID: 4392 |
|User ID: 234 | |User ID: 234 |
|---------------------------------------------->| |---------------------------------------------->|
Figure 50: Obtaining status information about a floor Figure 49: Obtaining status information about a floor
Appendix B. Motivation for Supporting Unreliable Transport Appendix B. Motivation for Supporting Unreliable Transport
[Editorial note: This appendix is contained in this draft as an [Editorial note: This appendix is contained in this draft as an
aid and rationale for new readers and reviewers. However, it is aid and rationale for new readers and reviewers. However, it is
not yet decided whether this Appendix will be part of the final not yet decided whether this Appendix will be part of the final
(RFC) version or not.] (RFC) version or not.]
B.1. Motivation B.1. Motivation
skipping to change at page 82, line 47 skipping to change at page 82, line 44
| Network | | Network |
+---------+ +---------+
+-----+ / \ +-----+ +-----+ / \ +-----+
| NAT |/ \| NAT | | NAT |/ \| NAT |
+-----+ +-----+ +-----+ +-----+
+----+ / \ +----+ +----+ / \ +----+
|BFCP|/ \|BFCP| |BFCP|/ \|BFCP|
| UA | | UA | | UA | | UA |
+----+ +----+ +----+ +----+
Figure 51: Use Case Figure 50: Use Case
The communication session between the video conferencing endpoints The communication session between the video conferencing endpoints
typically consists of a number of RTP over UDP media streams, for typically consists of a number of RTP over UDP media streams, for
audio and video, and a BFCP connection for floor control. Existing audio and video, and a BFCP connection for floor control. Existing
deployments are most common in, but not limited to, enterprise deployments are most common in, but not limited to, enterprise
networks. In existing deployments, NAT/firewall traversal for the networks. In existing deployments, NAT/firewall traversal for the
RTP streams works using ICE and/or other methods, including those RTP streams works using ICE and/or other methods, including those
described in [24]. described in [24].
When enhancing an existing SIP based video conferencing deployment When enhancing an existing SIP based video conferencing deployment
 End of changes. 83 change blocks. 
362 lines changed or deleted 383 lines changed or added

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