draft-ietf-bfcpbis-rfc4582bis-02.txt   draft-ietf-bfcpbis-rfc4582bis-03.txt 
BFCPbis Working Group T. Kristensen, Ed. BFCPbis Working Group G. Camarillo
Internet-Draft Cisco Internet-Draft Ericsson
Obsoletes: 4582 (if approved) March 12, 2012 Obsoletes: 4582 (if approved) K. Drage
Intended status: Standards Track Intended status: Standards Track Alcatel-Lucent
Expires: September 13, 2012 Expires: December 6, 2012 T. Kristensen, Ed.
Cisco
J. Ott
Aalto University
C. Eckel
Cisco
June 4, 2012
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-bfcpbis-rfc4582bis-02 draft-ietf-bfcpbis-rfc4582bis-03
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 43 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 September 13, 2012. This Internet-Draft will expire on December 6, 2012.
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 3, line 29 skipping to change at page 3, line 29
5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . . 19 5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . . 19
5.2.1. BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 21 5.2.1. BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 21
5.2.2. FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.2. FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.3. FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 21 5.2.3. FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 21
5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 23 5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 23
5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 23 5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 23
5.2.6.1. Error-Specific Details for Error Code 4 . . . . . 25 5.2.6.1. Error-Specific Details for Error Code 4 . . . . . 25
5.2.7. ERROR-INFO . . . . . . . . . . . . . . . . . . . . . . 25 5.2.7. ERROR-INFO . . . . . . . . . . . . . . . . . . . . . . 25
5.2.8. PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . . 26 5.2.8. PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . . 26
5.2.9. STATUS-INFO . . . . . . . . . . . . . . . . . . . . . 26 5.2.9. STATUS-INFO . . . . . . . . . . . . . . . . . . . . . 27
5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . . 27 5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . . 27
5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . . 28 5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . . 28
5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 28 5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 29
5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . . 29 5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 30 5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 30
5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 30 5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 31
5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . . 31 5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . . 32
5.2.17. FLOOR-REQUEST-STATUS . . . . . . . . . . . . . . . . . 32 5.2.17. FLOOR-REQUEST-STATUS . . . . . . . . . . . . . . . . . 32
5.2.18. OVERALL-REQUEST-STATUS . . . . . . . . . . . . . . . . 32 5.2.18. OVERALL-REQUEST-STATUS . . . . . . . . . . . . . . . . 33
5.3. Message Format . . . . . . . . . . . . . . . . . . . . . . 33 5.3. Message Format . . . . . . . . . . . . . . . . . . . . . . 34
5.3.1. FloorRequest . . . . . . . . . . . . . . . . . . . . . 33 5.3.1. FloorRequest . . . . . . . . . . . . . . . . . . . . . 34
5.3.2. FloorRelease . . . . . . . . . . . . . . . . . . . . . 34 5.3.2. FloorRelease . . . . . . . . . . . . . . . . . . . . . 34
5.3.3. FloorRequestQuery . . . . . . . . . . . . . . . . . . 34 5.3.3. FloorRequestQuery . . . . . . . . . . . . . . . . . . 34
5.3.4. FloorRequestStatus . . . . . . . . . . . . . . . . . . 34 5.3.4. FloorRequestStatus . . . . . . . . . . . . . . . . . . 35
5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 34 5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 35
5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . . 35 5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . . 35
5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . . 35 5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . . 36
5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 35 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 . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 36 5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 37 5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 38
5.3.15. ErrorAck . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.15. ErrorAck . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.16. FloorStatusAck . . . . . . . . . . . . . . . . . . . . 38 5.3.16. FloorStatusAck . . . . . . . . . . . . . . . . . . . . 38
5.3.17. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38 5.3.17. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.18. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 38 5.3.18. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 39
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 38 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 . . . . . . . . . . . . . . . . . 41 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 . . . . . . . . . . . . . . . . . . . . 42 6.3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . 43
7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 43 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 43
8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 43 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 44
8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 44 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 44
8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 44 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 45
8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 44 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 . . . . . . . . . . . . . . . . . . . . . 45 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 46
9. Authentication and Authorization . . . . . . . . . . . . . . . 45 9. Authentication and Authorization . . . . . . . . . . . . . . . 46
9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 46 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 47
10. Floor Participant Operations . . . . . . . . . . . . . . . . . 47 10. Floor Participant Operations . . . . . . . . . . . . . . . . . 47
10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 47 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 47
10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 47 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 48
10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 48 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 48
10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 49 10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 50
10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 49 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 . . . . . . . . . . . . . . . . . . . . . . . 50 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 51
11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 51 11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 51
11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 52 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 53
12. General Client Operations . . . . . . . . . . . . . . . . . . 52 12. General Client Operations . . . . . . . . . . . . . . . . . . 53
12.1. Requesting Information about Floors . . . . . . . . . . . 52 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 . . . . . . . . . . . . . . . . . 53 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 54
12.2. Requesting Information about Floor Requests . . . . . . . 54 12.2. Requesting Information about Floor Requests . . . . . . . 54
12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 54 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 55
12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 55 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 55
12.3. Requesting Information about a User . . . . . . . . . . . 55 12.3. Requesting Information about a User . . . . . . . . . . . 56
12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 55 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 . . . 56 12.4. Obtaining the Capabilities of a Floor Control Server . . . 57
12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 56 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 . . . . . . . . . . . . . . . 57 13. Floor Control Server Operations . . . . . . . . . . . . . . . 58
13.1. Reception of a FloorRequest Message . . . . . . . . . . . 58 13.1. Reception of a FloorRequest Message . . . . . . . . . . . 58
13.1.1. Generating the First FloorRequestStatus Message . . . 58 13.1.1. Generating the First FloorRequestStatus Message . . . 59
13.1.2. Generation of Subsequent FloorRequestStatus 13.1.2. Generation of Subsequent FloorRequestStatus
Messages . . . . . . . . . . . . . . . . . . . . . . . 59 Messages . . . . . . . . . . . . . . . . . . . . . . . 60
13.1.3. Reception of a FloorRequestStatus Message . . . . . . 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 . . . . . . . . . . . 63 13.4. Reception of a FloorRelease Message . . . . . . . . . . . 64
13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 64 13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 65
13.5.1. Generation of the First FloorStatus Message . . . . . 64 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 . . . . 66
13.5.3. Reception of a FloorStatus Message . . . . . . . . . . 66 13.5.3. Reception of a FloorStatus Message . . . . . . . . . . 67
13.6. Reception of a ChairAction Message . . . . . . . . . . . . 66 13.6. Reception of a ChairAction Message . . . . . . . . . . . . 67
13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 67 13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 68
13.8. Error Message Generation . . . . . . . . . . . . . . . . . 68 13.8. Error Message Generation . . . . . . . . . . . . . . . . . 68
13.9. Reception of an Error Message . . . . . . . . . . . . . . 68 13.9. Reception of an Error Message . . . . . . . . . . . . . . 69
14. Security Considerations . . . . . . . . . . . . . . . . . . . 68 14. Security Considerations . . . . . . . . . . . . . . . . . . . 69
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 69 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 70
15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 70 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 71
15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 71 15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 72
15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 72 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 73
16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 73 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 74
17. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 75 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76 18.1. Normative References . . . . . . . . . . . . . . . . . . . 76
19.1. Normative References . . . . . . . . . . . . . . . . . . . 76 18.2. Informational References . . . . . . . . . . . . . . . . . 77
19.2. Informational References . . . . . . . . . . . . . . . . . 77
Appendix A. Example Call Flows for BFCP over Unreliable Appendix A. Example Call Flows for BFCP over Unreliable
Transport . . . . . . . . . . . . . . . . . . . . . . 78 Transport . . . . . . . . . . . . . . . . . . . . . . 78
Appendix B. Motivation for and Introduction to Supporting Appendix B. Motivation for Supporting Unreliable Transport . . . 82
Unreliable Transport . . . . . . . . . . . . . . . . 81 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 82
B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 82 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 83
B.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 82 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 84
B.2.1. Alternatives Considered . . . . . . . . . . . . . . . 83 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 84
B.2.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 83 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 84
B.2.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 84 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 85
B.2.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 84 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 85
B.2.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 84 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 85
B.2.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 85 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 86
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
Within a conference, some applications need to manage the access to a Within a conference, some applications need to manage the access to a
set of shared resources, such as the right to send media to a set of shared resources, such as the right to send media to a
particular media sesssion. Floor control enables such applications particular media session. Floor control enables such applications to
to provide users with coordinated (shared or exclusive) access to provide users with coordinated (shared or exclusive) access to these
these resources. resources.
The Requirements for Floor Control Protocol [12] list a set of The Requirements for Floor Control Protocol [13] list a set of
requirements that need to be met by floor control protocols. The requirements that need to be met by floor control protocols. The
Binary Floor Control Protocol (BFCP), which is specified in this Binary Floor Control Protocol (BFCP), which is specified in this
document, meets these requirements. document, meets these requirements.
In addition, BFCP has been designed so that it can be used in low- In addition, BFCP has been designed so that it can be used in low-
bandwidth environments. The binary encoding used by BFCP achieves a bandwidth environments. The binary encoding used by BFCP achieves a
small message size (when message signatures are not used) that keeps small message size (when message signatures are not used) that keeps
the time it takes to transmit delay-sensitive BFCP messages to a the time it takes to transmit delay-sensitive BFCP messages to a
minimum. Delay-sensitive BFCP messages include FloorRequest, minimum. Delay-sensitive BFCP messages include FloorRequest,
FloorRelease, FloorRequestStatus, and ChairAction. It is expected FloorRelease, FloorRequestStatus, and ChairAction. It is expected
skipping to change at page 6, line 36 skipping to change at page 6, line 36
The remainder of this document is organized as follows: Section 2 The remainder of this document is organized as follows: Section 2
defines the terminology used throughout this document, Section 3 defines the terminology used throughout this document, Section 3
discusses the scope of BFCP (i.e., which tasks fall within the scope discusses the scope of BFCP (i.e., which tasks fall within the scope
of BFCP and which ones are performed using different mechanisms), of BFCP and which ones are performed using different mechanisms),
Section 4 provides a non-normative overview of BFCP operation, and Section 4 provides a non-normative overview of BFCP operation, and
subsequent sections provide the normative specification of BFCP. subsequent sections provide the normative specification of BFCP.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as "OPTIONAL" in this document are to be interpreted as described in BCP
described in BCP 14, RFC 2119 [1] and indicate requirement levels for 14, RFC 2119 [1] and indicate requirement levels for compliant
compliant implementations. implementations.
Media Participant: An entity that has access to the media resources Media Participant: An entity that has access to the media resources
of a conference (e.g., it can receive a media stream). In floor- of a conference (e.g., it can receive a media stream). In floor-
controlled conferences, a given media participant is typically controlled conferences, a given media participant is typically
colocated with a floor participant, but it does not need to be. colocated with a floor participant, but it does not need to be.
Third-party floor requests consist of having a floor participant Third-party floor requests consist of having a floor participant
request a floor for a media participant when they are not colocated. request a floor for a media participant when they are not colocated.
The protocol between a floor participant and a media participant The protocol between a floor participant and a media participant
(that are not colocated) is outside the scope of this document. (that are not colocated) is outside the scope of this document.
skipping to change at page 7, line 45 skipping to change at page 7, line 45
media participant, but it does not need to be. Third-party floor media participant, but it does not need to be. Third-party floor
requests consist of having a floor participant request a floor for a requests consist of having a floor participant request a floor for a
media participant when they are not colocated. media participant when they are not colocated.
Participant: An entity that acts as a floor participant, as a media Participant: An entity that acts as a floor participant, as a media
participant, or as both. participant, or as both.
3. Scope 3. Scope
As stated earlier, BFCP is a protocol to coordinate access to shared As stated earlier, BFCP is a protocol to coordinate access to shared
resources in a conference following the requirements defined in [12]. resources in a conference following the requirements defined in [13].
Floor control complements other functions defined in the XCON Floor control complements other functions defined in the XCON
conferencing framework [13]. The floor control protocol BFCP defined conferencing framework [14]. The floor control protocol BFCP defined
in this document only specifies a means to arbitrate access to in this document only specifies a means to arbitrate access to
floors. The rules and constraints for floor arbitration and the floors. The rules and constraints for floor arbitration and the
results of floor assignments are outside the scope of this document results of floor assignments are outside the scope of this document
and are defined by other protocols [13]. and are defined by other protocols [14].
Figure 1 shows the tasks that BFCP can perform. Figure 1 shows the tasks that BFCP can perform.
+---------+ +---------+
| Floor | | Floor |
| Chair | | Chair |
| | | |
+---------+ +---------+
^ | ^ |
| | | |
skipping to change at page 9, line 9 skipping to change at page 9, line 9
the scope of BFCP, some of these out-of-scope tasks relate to floor the scope of BFCP, some of these out-of-scope tasks relate to floor
control and are essential for creating floors and establishing BFCP control and are essential for creating floors and establishing BFCP
connections between different entities. In the following connections between different entities. In the following
subsections, we discuss some of these tasks and mechanisms to perform subsections, we discuss some of these tasks and mechanisms to perform
them. them.
3.1. Floor Creation 3.1. Floor Creation
The association of a given floor with a resource or a set of The association of a given floor with a resource or a set of
resources (e.g., media streams) is out of the scope of BFCP as resources (e.g., media streams) is out of the scope of BFCP as
described in [13]. Floor creation and termination are also outside described in [14]. Floor creation and termination are also outside
the scope of BFCP; these aspects are handled using the conference the scope of BFCP; these aspects are handled using the conference
control protocol for manipulating the conference object. control protocol for manipulating the conference object.
Consequently, the floor control server needs to stay up to date on Consequently, the floor control server needs to stay up to date on
changes to the conference object (e.g., when a new floor is created). changes to the conference object (e.g., when a new floor is created).
3.2. Obtaining Information to Contact a Floor Control Server 3.2. Obtaining Information to Contact a Floor Control Server
A client needs a set of data in order to establish a BFCP connection A client needs a set of data in order to establish a BFCP connection
to a floor control server. These data include the transport address to a floor control server. These data include the transport address
of the server, the conference identifier, and a user identifier. of the server, the conference identifier, and a user identifier.
Clients can obtain this information in different ways. One is to use Clients can obtain this information in different ways. One is to use
an SDP offer/answer [11] exchange, which is described in [6]. Other an SDP offer/answer [12] exchange, which is described in [7]. Other
mechanisms are described in the XCON framework [13] (and other mechanisms are described in the XCON framework [14] (and other
related documents). related documents).
3.3. Obtaining Floor-Resource Associations 3.3. Obtaining Floor-Resource Associations
Floors are associated with resources. For example, a floor that Floors are associated with resources. For example, a floor that
controls who talks at a given time has a particular audio session as controls who talks at a given time has a particular audio session as
its associated resource. Associations between floors and resources its associated resource. Associations between floors and resources
are part of the conference object. are part of the conference object.
Floor participants and floor chairs need to know which resources are Floor participants and floor chairs need to know which resources are
associated with which floors. They can obtain this information by associated with which floors. They can obtain this information by
using different mechanisms, such as an SDP offer/answer [11] using different mechanisms, such as an SDP offer/answer [12]
exchange. How to use an SDP offer/answer exchange to obtain these exchange. How to use an SDP offer/answer exchange to obtain these
associations is described in [6]. associations is described in [7].
Note that floor participants perform SDP offer/answer exchanges Note that floor participants perform SDP offer/answer exchanges
with the conference focus of the conference. So, the conference with the conference focus of the conference. So, the conference
focus needs to obtain information about associations between focus needs to obtain information about associations between
floors and resources in order to be able to provide this floors and resources in order to be able to provide this
information to a floor participant in an SDP offer/answer information to a floor participant in an SDP offer/answer
exchange. exchange.
Other mechanisms for obtaining this information, including discussion Other mechanisms for obtaining this information, including discussion
of how the information is made available to a (SIP) Focus, are of how the information is made available to a (SIP) Focus, are
described in the XCON framework [13] (and other related documents). described in the XCON framework [14] (and other related documents).
3.4. Privileges of Floor Control 3.4. Privileges of Floor Control
A participant whose floor request is granted has the right to use (in A participant whose floor request is granted has the right to use (in
a certain way) the resource or resources associated with the floor a certain way) the resource or resources associated with the floor
that was requested. For example, the participant may have the right that was requested. For example, the participant may have the right
to send media over a particular audio stream. to send media over a particular audio stream.
Nevertheless, holding a floor does not imply that others will not be Nevertheless, holding a floor does not imply that others will not be
able to use its associated resources at the same time, even if they able to use its associated resources at the same time, even if they
do not have the right to do so. Determination of which media do not have the right to do so. Determination of which media
participants can actually use the resources in the conference is participants can actually use the resources in the conference is
discussed in the XCON Framework [13]. discussed in the XCON Framework [14].
4. Overview of Operation 4. Overview of Operation
This section provides a non-normative description of BFCP operations. This section provides a non-normative description of BFCP operations.
Section 4.1 describes the interface between floor participants and Section 4.1 describes the interface between floor participants and
floor control servers, and Section 4.2 describes the interface floor control servers, and Section 4.2 describes the interface
between floor chairs and floor control servers. between floor chairs and floor control servers.
BFCP messages, which use a TLV (Type-Length-Value) binary encoding, BFCP messages, which use a TLV (Type-Length-Value) binary encoding,
consist of a common header followed by a set of attributes. The consist of a common header followed by a set of attributes. The
skipping to change at page 16, line 49 skipping to change at page 16, line 49
| Conference ID | | Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID | | Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Offset (if F is set) | Fragment Length (if F is set) | | Fragment Offset (if F is set) | Fragment Length (if F is set) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: COMMON-HEADER format Figure 5: COMMON-HEADER format
Ver: The 3-bit version field MUST be set to 1 when using BFCP over Ver: The 3-bit version field MUST be set to 1 when using BFCP over
reliable transport, i.e. as in [16]. 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 a extensions specified in this document. If a BFCP entity receives a
message with an unsupported version field value, the receiving message with an unsupported version field value, the receiving
participant MAY send an Error message with parameter value 12 to participant MAY send an Error message with parameter value 12 to
indicate this. 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
skipping to change at page 18, line 35 skipping to change at page 18, line 35
| | | P <- S ; Ch <- S | | | | P <- S ; Ch <- S |
| 18 | GoodbyeAck | P -> S ; Ch -> S ; | | 18 | 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. in 4-octet units, excluding the common header. If a BFCP entity
receives a message with an incorrect payload length field value, the
receiving participant MAY send an Error message with parameter value
13 to indicate this.
Conference ID: This 32-bit field identifies the conference the Conference ID: This 32-bit unsigned integer field identifies 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 value that uniquely identifies User ID: This field contains a 16-bit unsigned integer that uniquely
a participant within a conference. identifies a participant within a conference.
The identity used by a participant in BFCP, which is carried in The identity used by a participant in BFCP, which is carried in
the User ID field, is generally mapped to the identity used by the the User ID field, is generally mapped to the identity used by the
same participant in the session establishment protocol (e.g., in same participant in the session establishment protocol (e.g., in
SIP). The way this mapping is performed is outside the scope of SIP). The way this mapping is performed is outside the scope of
this specification. this specification.
Fragment Offset: This optional field is present only if the F flag is Fragment Offset: This optional field is present only if the F flag is
set and contains a 16-bit value that specifies the number of 4-octet set and contains a 16-bit value that specifies the number of 4-octet
units contained in previous fragments, excluding the common header. units contained in previous fragments, excluding the common header.
skipping to change at page 20, line 36 skipping to change at page 20, line 44
+------+---------------------------+---------------+ +------+---------------------------+---------------+
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 an unrecognized attribute with the
'M' bit set is received, the message is rejected. The 'M' bit is 'M' bit set is received, the message is rejected. The 'M' bit is
significant for extension attributes defined in other documents only. significant for extension attributes defined in other documents only.
All attributes specified in this document MUST be understood by the All attributes specified in this document MUST be understood by the
receiver so that the setting of the 'M' bit is irrelevant for these. receiver so that the setting of the 'M' bit is irrelevant for these.
In all other cases, the unrecognised attribute is ignored but the In all other cases, the unrecognized attribute is ignored but the
message is processed. 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.
skipping to change at page 24, line 20 skipping to change at page 24, line 20
| | | |
| Error Specific Details | | Error Specific Details |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 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 recognised 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 message is processed, but the nature of the error is
unclear. 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 |
| 7 | Floor Request ID Does Not Exist | | 7 | Floor Request ID Does Not Exist |
| 8 | You have Already Reached the Maximum Number of Ongoing | | 8 | You have Already Reached the Maximum Number of Ongoing |
| | Floor Requests for this Floor | | | Floor Requests for this Floor |
| 9 | Use TLS | | 9 | Use TLS |
| 10 | Unable to Parse Message | | 10 | Unable to Parse Message |
| 11 | Use DTLS | | 11 | Use DTLS |
| 12 | Unsupported Version | | 12 | Unsupported Version |
| 13 | Incorrect Message Length |
| 14 | Generic Error |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Table 5: Error Code meaning Table 5: Error Code meaning
Note: The Generic Error error code is intended being used by a
BFCP entity when an error occurs and the other specific error
codes do not apply.
Error Specific Details: Present only for certain Error Codes. In Error Specific Details: Present only for certain Error Codes. In
this document, only for Error Code 4 (Unknown Mandatory Attribute). this document, only for Error Code 4 (Unknown Mandatory Attribute).
See Section 5.2.6.1 for its definition. See Section 5.2.6.1 for its definition.
Padding: One, two, or three octets of padding added so that the Padding: One, two, or three octets of padding added so that the
contents of the ERROR-CODE attribute is 32-bit aligned. If the contents of the ERROR-CODE attribute is 32-bit aligned. If the
attribute is already 32-bit aligned, no padding is needed. 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.6.1. Error-Specific Details for Error Code 4 5.2.6.1. Error-Specific Details for Error Code 4
skipping to change at page 26, line 5 skipping to change at page 26, line 18
|0 0 0 0 1 1 1|M| Length | | |0 0 0 0 1 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: ERROR-INFO format Figure 14: ERROR-INFO format
Text: This field contains UTF-8 [5] encoded text. Text: This field contains UTF-8 [6] encoded text.
In some situations, the contents of the Text field may be generated In some situations, the contents of the Text field may be generated
by an automaton. If this automaton has information about the by an automaton. If this automaton has information about the
preferred language of the receiver of a particular ERROR-INFO preferred language of the receiver of a particular ERROR-INFO
attribute, it MAY use this language to generate the Text field. attribute, it MAY use this language to generate the Text field.
Padding: One, two, or three octets of padding added so that the Padding: One, two, or three octets of padding added so that the
contents of the ERROR-INFO attribute is 32-bit aligned. The Padding contents of the ERROR-INFO attribute is 32-bit aligned. The Padding
bits SHOULD be set to zero by the sender and MUST be ignored by the bits SHOULD be set to zero by the sender and MUST be ignored by the
receiver. If the attribute is already 32-bit aligned, no padding is receiver. If the attribute is already 32-bit aligned, no padding is
skipping to change at page 26, line 36 skipping to change at page 26, line 49
|0 0 0 1 0 0 0|M| Length | | |0 0 0 1 0 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: PARTICIPANT-PROVIDED-INFO format Figure 15: PARTICIPANT-PROVIDED-INFO format
Text: This field contains UTF-8 [5] encoded text. Text: This field contains UTF-8 [6] encoded text.
Padding: One, two, or three octets of padding added so that the Padding: One, two, or three octets of padding added so that the
contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit
aligned. The Padding bits SHOULD be set to zero by the sender and aligned. The Padding bits SHOULD be set to zero by the sender and
MUST be ignored by the receiver. If the attribute is already 32-bit MUST be ignored by the receiver. If the attribute is already 32-bit
aligned, no padding is needed. aligned, no padding is needed.
5.2.9. STATUS-INFO 5.2.9. STATUS-INFO
The following is the format of the STATUS-INFO attribute. The following is the format of the STATUS-INFO attribute.
skipping to change at page 27, line 18 skipping to change at page 27, line 26
|0 0 0 1 0 0 1|M| Length | | |0 0 0 1 0 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: STATUS-INFO format Figure 16: STATUS-INFO format
Text: This field contains UTF-8 [5] encoded text. Text: This field contains UTF-8 [6] encoded text.
In some situations, the contents of the Text field may be generated In some situations, the contents of the Text field may be generated
by an automaton. If this automaton has information about the by an automaton. If this automaton has information about the
preferred language of the receiver of a particular STATUS-INFO preferred language of the receiver of a particular STATUS-INFO
attribute, it MAY use this language to generate the Text field. attribute, it MAY use this language to generate the Text field.
Padding: One, two, or three octets of padding added so that the Padding: One, two, or three octets of padding added so that the
contents of the STATUS-INFO attribute is 32-bit aligned. The Padding contents of the STATUS-INFO attribute is 32-bit aligned. The Padding
bits SHOULD be set to zero by the sender and MUST be ignored by the bits SHOULD be set to zero by the sender and MUST be ignored by the
receiver. If the attribute is already 32-bit aligned, no padding is receiver. If the attribute is already 32-bit aligned, no padding is
skipping to change at page 30, line 41 skipping to change at page 31, line 12
Beneficiary ID: This field contains a 16-bit value that uniquely Beneficiary ID: This field contains a 16-bit value that uniquely
identifies a user within a conference. identifies a user within a conference.
The following is the ABNF (Augmented Backus-Naur Form) [2] of the The following is the ABNF (Augmented Backus-Naur Form) [2] of the
BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE
refers to extension attributes that may be defined in the future.) refers to extension attributes that may be defined in the future.)
BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER)
[USER-DISPLAY-NAME] [USER-DISPLAY-NAME]
[USER-URI] [USER-URI]
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 22: BENEFICIARY-INFORMATION format Figure 22: BENEFICIARY-INFORMATION format
5.2.15. FLOOR-REQUEST-INFORMATION 5.2.15. FLOOR-REQUEST-INFORMATION
The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as FLOOR-REQUEST- consists of a header, which is referred to as FLOOR-REQUEST-
INFORMATION-HEADER, followed by a sequence of attributes. The INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: following is the format of the FLOOR-REQUEST-INFORMATION-HEADER:
skipping to change at page 31, line 27 skipping to change at page 31, line 45
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.) may be defined in the future.)
FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER)
[OVERALL-REQUEST-STATUS] [OVERALL-REQUEST-STATUS]
1*(FLOOR-REQUEST-STATUS) 1*(FLOOR-REQUEST-STATUS)
[BENEFICIARY-INFORMATION] [BENEFICIARY-INFORMATION]
[REQUESTED-BY-INFORMATION] [REQUESTED-BY-INFORMATION]
[PRIORITY] [PRIORITY]
[PARTICIPANT-PROVIDED-INFO] [PARTICIPANT-PROVIDED-INFO]
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 24: FLOOR-REQUEST-INFORMATION format Figure 24: FLOOR-REQUEST-INFORMATION format
5.2.16. REQUESTED-BY-INFORMATION 5.2.16. REQUESTED-BY-INFORMATION
The REQUESTED-BY-INFORMATION attribute is a grouped attribute that The REQUESTED-BY-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as REQUESTED-BY- consists of a header, which is referred to as REQUESTED-BY-
INFORMATION-HEADER, followed by a sequence of attributes. The INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the REQUESTED-BY-INFORMATION-HEADER: following is the format of the REQUESTED-BY-INFORMATION-HEADER:
skipping to change at page 32, line 9 skipping to change at page 32, line 30
Requested-by ID: This field contains a 16-bit value that uniquely Requested-by ID: This field contains a 16-bit value that uniquely
identifies a user within a conference. identifies a user within a conference.
The following is the ABNF of the REQUESTED-BY-INFORMATION grouped The following is the ABNF of the REQUESTED-BY-INFORMATION grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.) may be defined in the future.)
REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER) REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER)
[USER-DISPLAY-NAME] [USER-DISPLAY-NAME]
[USER-URI] [USER-URI]
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 26: REQUESTED-BY-INFORMATION format Figure 26: REQUESTED-BY-INFORMATION format
5.2.17. FLOOR-REQUEST-STATUS 5.2.17. FLOOR-REQUEST-STATUS
The FLOOR-REQUEST-STATUS attribute is a grouped attribute that The FLOOR-REQUEST-STATUS attribute is a grouped attribute that
consists of a header, which is referred to as FLOOR-REQUEST-STATUS- consists of a header, which is referred to as FLOOR-REQUEST-STATUS-
HEADER, followed by a sequence of attributes. The following is the HEADER, followed by a sequence of attributes. The following is the
format of the FLOOR-REQUEST-STATUS-HEADER: format of the FLOOR-REQUEST-STATUS-HEADER:
skipping to change at page 32, line 38 skipping to change at page 33, line 13
Floor ID: this field contains a 16-bit value that uniquely identifies Floor ID: this field contains a 16-bit value that uniquely identifies
a floor within a conference. a floor within a conference.
The following is the ABNF of the FLOOR-REQUEST-STATUS grouped The following is the ABNF of the FLOOR-REQUEST-STATUS grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.) may be defined in the future.)
FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER)
[REQUEST-STATUS] [REQUEST-STATUS]
[STATUS-INFO] [STATUS-INFO]
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 28: FLOOR-REQUEST-STATUS format Figure 28: FLOOR-REQUEST-STATUS format
5.2.18. OVERALL-REQUEST-STATUS 5.2.18. OVERALL-REQUEST-STATUS
The OVERALL-REQUEST-STATUS attribute is a grouped attribute that The OVERALL-REQUEST-STATUS attribute is a grouped attribute that
consists of a header, which is referred to as OVERALL-REQUEST-STATUS- consists of a header, which is referred to as OVERALL-REQUEST-STATUS-
HEADER, followed by a sequence of attributes. The following is the HEADER, followed by a sequence of attributes. The following is the
format of the OVERALL-REQUEST-STATUS-HEADER: format of the OVERALL-REQUEST-STATUS-HEADER:
skipping to change at page 33, line 23 skipping to change at page 33, line 42
Floor Request ID: this field contains a 16-bit value that identifies Floor Request ID: this field contains a 16-bit value that identifies
a floor request at the floor control server. a floor request at the floor control server.
The following is the ABNF of the OVERALL-REQUEST-STATUS grouped The following is the ABNF of the OVERALL-REQUEST-STATUS grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.) may be defined in the future.)
OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER) OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER)
[REQUEST-STATUS] [REQUEST-STATUS]
[STATUS-INFO] [STATUS-INFO]
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 30: OVERALL-REQUEST-STATUS format Figure 30: OVERALL-REQUEST-STATUS format
5.3. Message Format 5.3. Message Format
This section contains the normative ABNF (Augmented Backus-Naur Form) This section contains the normative ABNF (Augmented Backus-Naur Form)
[2] of the BFCP messages. Extension attributes that may be defined [2] of the BFCP messages. Extension attributes that may be defined
in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.
5.3.1. FloorRequest 5.3.1. FloorRequest
Floor participants request a floor by sending a FloorRequest message Floor participants request a floor by sending a FloorRequest message
to the floor control server. The following is the format of the to the floor control server. The following is the format of the
FloorRequest message: FloorRequest message:
FloorRequest = (COMMON-HEADER) FloorRequest = (COMMON-HEADER)
1*(FLOOR-ID) 1*(FLOOR-ID)
[BENEFICIARY-ID] [BENEFICIARY-ID]
[PARTICIPANT-PROVIDED-INFO] [PARTICIPANT-PROVIDED-INFO]
[PRIORITY] [PRIORITY]
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 31: FloorRequest format Figure 31: FloorRequest format
5.3.2. FloorRelease 5.3.2. FloorRelease
Floor participants release a floor by sending a FloorRelease message Floor participants release a floor by sending a FloorRelease message
to the floor control server. Floor participants also use the to the floor control server. Floor participants also use the
FloorRelease message to cancel pending floor requests. The following FloorRelease message to cancel pending floor requests. The following
is the format of the FloorRelease message: is the format of the FloorRelease message:
FloorRelease = (COMMON-HEADER) FloorRelease = (COMMON-HEADER)
(FLOOR-REQUEST-ID) (FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 32: FloorRelease format Figure 32: FloorRelease format
5.3.3. FloorRequestQuery 5.3.3. FloorRequestQuery
Floor participants and floor chairs request information about a floor Floor participants and floor chairs request information about a floor
request by sending a FloorRequestQuery message to the floor control request by sending a FloorRequestQuery message to the floor control
server. The following is the format of the FloorRequestQuery server. The following is the format of the FloorRequestQuery
message: message:
FloorRequestQuery = (COMMON-HEADER) FloorRequestQuery = (COMMON-HEADER)
(FLOOR-REQUEST-ID) (FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 33: FloorRequestQuery format Figure 33: FloorRequestQuery format
5.3.4. FloorRequestStatus 5.3.4. FloorRequestStatus
The floor control server informs floor participants and floor chairs The floor control server informs floor participants and floor chairs
about the status of their floor requests by sending them about the status of their floor requests by sending them
FloorRequestStatus messages. The following is the format of the FloorRequestStatus messages. The following is the format of the
FloorRequestStatus message: FloorRequestStatus message:
FloorRequestStatus = (COMMON-HEADER) FloorRequestStatus = (COMMON-HEADER)
(FLOOR-REQUEST-INFORMATION) (FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 34: FloorRequestStatus format Figure 34: FloorRequestStatus format
5.3.5. UserQuery 5.3.5. UserQuery
Floor participants and floor chairs request information about a Floor participants and floor chairs request information about a
participant and the floor requests related to this participant by participant and the floor requests related to this participant by
sending a UserQuery message to the floor control server. The sending a UserQuery message to the floor control server. The
following is the format of the UserQuery message: following is the format of the UserQuery message:
UserQuery = (COMMON-HEADER) UserQuery = (COMMON-HEADER)
[BENEFICIARY-ID] [BENEFICIARY-ID]
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 35: UserQuery format Figure 35: UserQuery format
5.3.6. UserStatus 5.3.6. UserStatus
The floor control server provides information about participants and The floor control server provides information about participants and
their related floor requests to floor participants and floor chairs their related floor requests to floor participants and floor chairs
by sending them UserStatus messages. The following is the format of by sending them UserStatus messages. The following is the format of
the UserStatus message: the UserStatus message:
UserStatus = (COMMON-HEADER) UserStatus = (COMMON-HEADER)
[BENEFICIARY-INFORMATION] [BENEFICIARY-INFORMATION]
*(FLOOR-REQUEST-INFORMATION) *(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 36: UserStatus format Figure 36: UserStatus format
5.3.7. FloorQuery 5.3.7. FloorQuery
Floor participants and floor chairs request information about a floor Floor participants and floor chairs request information about a floor
or floors by sending a FloorQuery message to the floor control or floors by sending a FloorQuery message to the floor control
server. The following is the format of the FloorRequest message: server. The following is the format of the FloorRequest message:
FloorQuery = (COMMON-HEADER) FloorQuery = (COMMON-HEADER)
*(FLOOR-ID) *(FLOOR-ID)
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 37: FloorQuery format Figure 37: FloorQuery format
5.3.8. FloorStatus 5.3.8. FloorStatus
The floor control server informs floor participants and floor chairs The floor control server informs floor participants and floor chairs
about the status (e.g., the current holder) of a floor by sending about the status (e.g., the current holder) of a floor by sending
them FloorStatus messages. The following is the format of the them FloorStatus messages. The following is the format of the
FloorStatus message: FloorStatus message:
FloorStatus = (COMMON-HEADER) FloorStatus = (COMMON-HEADER)
1*(FLOOR-ID) [FLOOR-ID]
*[FLOOR-REQUEST-INFORMATION] *(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 38: FloorStatus format Figure 38: FloorStatus format
5.3.9. ChairAction 5.3.9. ChairAction
Floor chairs send instructions to floor control servers by sending Floor chairs send instructions to floor control servers by sending
ChairAction messages. The following is the format of the ChairAction ChairAction messages. The following is the format of the ChairAction
message: message:
ChairAction = (COMMON-HEADER) ChairAction = (COMMON-HEADER)
(FLOOR-REQUEST-INFORMATION) (FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 39: ChairAction format Figure 39: ChairAction format
5.3.10. ChairActionAck 5.3.10. ChairActionAck
Floor control servers confirm that they have accepted a ChairAction Floor control servers confirm that they have accepted a ChairAction
message by sending a ChairActionAck message. The following is the message by sending a ChairActionAck message. The following is the
format of the ChairActionAck message: format of the ChairActionAck message:
ChairActionAck = (COMMON-HEADER) ChairActionAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 40: ChairActionAck format Figure 40: ChairActionAck format
5.3.11. Hello 5.3.11. Hello
Floor participants and floor chairs check the liveliness of floor Floor participants and floor chairs check the liveliness of floor
control servers by sending a Hello message. The following is the control servers by sending a Hello message. The following is the
format of the Hello message: format of the Hello message:
Hello = (COMMON-HEADER) Hello = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 41: Hello format Figure 41: Hello format
5.3.12. HelloAck 5.3.12. HelloAck
Floor control servers confirm that they are alive on reception of a Floor control servers confirm that they are alive on reception of a
Hello message by sending a HelloAck message. The following is the Hello message by sending a HelloAck message. The following is the
format of the HelloAck message: format of the HelloAck message:
HelloAck = (COMMON-HEADER) HelloAck = (COMMON-HEADER)
(SUPPORTED-PRIMITIVES) (SUPPORTED-PRIMITIVES)
(SUPPORTED-ATTRIBUTES) (SUPPORTED-ATTRIBUTES)
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 42: HelloAck format Figure 42: HelloAck format
5.3.13. Error 5.3.13. Error
Floor control servers inform floor participants and floor chairs Floor control servers inform floor participants and floor chairs
about errors processing requests by sending them Error messages. The about errors processing requests by sending them Error messages. The
following is the format of the Error message: following is the format of the Error message:
Error = (COMMON-HEADER) Error = (COMMON-HEADER)
(ERROR-CODE) (ERROR-CODE)
[ERROR-INFO] [ERROR-INFO]
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 43: Error format Figure 43: Error format
5.3.14. FloorRequestStatusAck 5.3.14. FloorRequestStatusAck
Floor participants and chairs acknowledge the receipt of a Floor participants and chairs acknowledge the receipt of a
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. ErrorAck
Floor participants and chairs acknowledge the receipt of an Error Floor participants and chairs acknowledge the receipt of an Error
message from the floor control server when communicating over message from the floor control server when communicating over
unreliable transport. The following is the format of the ErrorAck unreliable transport. The following is the format of the ErrorAck
message: message:
ErrorAck = (COMMON-HEADER) ErrorAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 45: ErrorAck format Figure 45: ErrorAck format
5.3.16. FloorStatusAck 5.3.16. FloorStatusAck
Floor participants and chairs acknowledge the receipt of a Floor participants and chairs acknowledge the receipt of a
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 46: FloorStatusAck format
5.3.17. Goodbye 5.3.17. Goodbye
BFCP entities that wish to dissociate themselves from their remote BFCP entities communicating over an unreliable transport that wish to
participant do so through the transmission of a Goodbye. The dissociate themselves from their remote participant do so through the
following is the format of the Goodbye message: transmission of a Goodbye. The following is the format of the
Goodbye message:
Goodbye = (COMMON-HEADER) Goodbye = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE] *(EXTENSION-ATTRIBUTE)
Figure 47: Goodbye format Figure 47: Goodbye format
5.3.18. GoodbyeAck 5.3.18. 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 48: 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 [6]). 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.
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
dissociate itself from any allocated resources. If a floor control
server wishes to end its BFCP association 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), it is RECOMMENDED
that the floor control server send a Goodbye message towards the
client.
6.1. Reliable Transport 6.1. Reliable Transport
BFCP entities may elect to exchange BFCP messages using TCP BFCP entities may elect to exchange BFCP messages using TCP
connections. TCP provides an in-order reliable delivery of a stream connections. TCP provides an in-order reliable delivery of a stream
of bytes. Consequently, message framing is implemented in the of bytes. Consequently, message framing is implemented in the
application layer. BFCP implements application-layer framing using application layer. BFCP implements application-layer framing using
TLV-encoded attributes. TLV-encoded attributes.
A client MUST NOT use more than one TCP connection to communicate A client MUST NOT use more than one TCP connection to communicate
with a given floor control server within a conference. Nevertheless, with a given floor control server within a conference. Nevertheless,
skipping to change at page 39, line 47 skipping to change at page 40, line 18
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.
To maintain backwards compatibility with older implementations of
[6], BFCP entities MUST interpret the graceful close of their TCP
connection from their associated participant as an implicit Goodbye
message.
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.
skipping to change at page 41, line 18 skipping to change at page 41, line 31
regarding congestion control are provided in Section 6.2.1. A regarding congestion control are provided in Section 6.2.1. A
server-initiated request (e.g. a FloorStatus with an update from the server-initiated request (e.g. a FloorStatus with an update from the
floor control server) received by a participant before the initial floor control server) received by a participant before the initial
FloorRequestStatus message that closes the client-initiated 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
server, it is RECOMMENDED that the client send a Goodbye message to
dissociate itself from any allocated resources. If a floor control
server wishes to end its BFCP association 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), it is RECOMMENDED
that the floor control server send a Goodbye message towards the
client.
6.2.1. Congestion Control 6.2.1. Congestion Control
BFCP may be characterized to generate "low data-volume" traffic, per BFCP may be characterized to generate "low data-volume" traffic, per
the classification in [18]. Nevertheless it is 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 every entity -
client or server - is only allowed to send one request at a time, and client or server - is only allowed to send one request at a time, and
await the acknowledging response. This way at most one datagram is await the acknowledging response. This way at most one datagram is
sent per RTT given the message is not lost during transmission. In sent per RTT given the message is not lost during transmission. In
case the message is lost, the request retransmission timer T1 case the message is lost, the request retransmission timer T1
specified in Section 8.3.1 will fire and the message is retransmitted specified in Section 8.3.1 will fire and the message is retransmitted
up to three times. The default initial interval is set to 500ms and up to three times. The default initial interval is set to 500ms and
the interval is doubled after each retransmission attempt, this is the interval is doubled after each retransmission attempt, this is
identical to the specification of the T1 timer in SIP as described in identical to the specification of the T1 timer in SIP as described in
Section 17.1.1.2 of [15]. 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) and behave
accordingly. The entity MAY attempt to re-establish the conversation accordingly. The entity MAY attempt to re-establish the conversation
afresh. The new connection will appear as a wholly new floor afresh. The new connection will appear as a wholly new floor
participant, chair or floor control server with all state previously participant, chair or floor control 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 [14]. NAT pinhole maintenance mechanisms defined in ICE [15].
6.3. Large Message Considerations 6.3. Large Message Considerations
Large messages become a concern when using BFCP if the overall size Large messages become a concern when using BFCP if the overall size
of a single BFCP message exceeds that representable within the 16-bit of a single BFCP message exceeds that representable within the 16-bit
Payload Length field of the COMMON-HEADER. When using UDP, there is Payload Length field of the COMMON-HEADER. When using UDP, there is
the added concern that a single BFCP message can be fragmented at the the added concern that a single BFCP message can be fragmented at the
IP layer if its overall size exceeds the MTU threshold of the IP layer if its overall size exceeds the MTU threshold of the
network. network.
skipping to change at page 42, line 51 skipping to change at page 43, line 26
Retransmission Timer, starting the timer after the receipt of the Retransmission Timer, starting the timer after the receipt of the
first fragment. first fragment.
6.3.2. NAT Traversal 6.3.2. NAT Traversal
One of the key benefits when using UDP for BFCP communication is the One of the key benefits when using UDP for BFCP communication is the
ability to leverage the existing NAT traversal infrastructure and ability to leverage the existing NAT traversal infrastructure and
strategies deployed to facilitate transport of the media associated strategies deployed to facilitate transport of the media associated
with the video conferencing sessions. Depending on the given with the video conferencing sessions. Depending on the given
deployment, this infrastructure typically includes some subset of ICE deployment, this infrastructure typically includes some subset of ICE
[14]. [15].
In order to facilitate the initial establishment of NAT bindings, and In order to facilitate the initial establishment of NAT bindings, and
to maintain those bindings once established, BFCP over UDP entities to maintain those bindings once established, BFCP over UDP entities
are RECOMMENDED to use STUN [10] for keep-alives, as described for are RECOMMENDED to use STUN [11] for keep-alives, as described for
SIP [9]. This results in each BFCP entity sending a packet, both to SIP [10]. This results in each BFCP entity sending a packet, both to
open the pinhole and to learn what IP/port the NAT assigned for the open the pinhole and to learn what IP/port the NAT assigned for the
binding. binding.
Informational note: Since the version number is set to 2 when BFCP
is used over unreliable transport, cf. the Ver field in
Section 5.1, it is straight forward to distinguish between STUN
and BFCP packets even without checking the STUN magic cookie [11].
In order to facilitate traversal of BFCP packets through NATs, BFCP In order to facilitate traversal of BFCP packets through NATs, BFCP
over UDP entities are RECOMMENDED to use symmetric ports for sending over UDP entities are RECOMMENDED to use symmetric ports for sending
and receiving BFCP packets, as recommended for RTP/RTCP [8]. and receiving BFCP packets, as recommended for RTP/RTCP [9].
7. Lower-Layer Security 7. Lower-Layer Security
BFCP relies on lower-layer security mechanisms to provide replay and BFCP relies on lower-layer security mechanisms to provide replay and
integrity protection and confidentiality. BFCP floor control servers integrity protection and confidentiality. BFCP floor control servers
and clients (which include both floor participants and floor chairs) and clients (which include both floor participants and floor chairs)
MUST support TLS for transport over TCP and MUST support DTLS for MUST support TLS for transport over TCP [4] and MUST support DTLS [5]
transport over UDP [4]. Any BFCP entity MAY support other security for transport over UDP. Any BFCP entity MAY support other security
mechanisms. mechanisms.
BFCP entities MUST support, at a minimum, the BFCP entities MUST support, at a minimum, the
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [4]. TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [4].
Which party, the client or the floor control server, acts as the TLS/ Which party, the client or the floor control server, acts as the TLS/
DTLS server depends on how the underlying TLS/DTLS connection is DTLS server depends on how the underlying TLS/DTLS connection is
established. For a TCP/TLS connection established using an SDP established. For a TCP/TLS connection established using an SDP
offer/answer exchange [6], the answerer (which may be the client or offer/answer exchange [7], the answerer (which may be the client or
the floor control server) always acts as the TLS server. For a UDP/ the floor control server) always acts as the TLS server. For a UDP/
DTLS connection established using the same exchange, either party can DTLS connection established using the same exchange, either party can
be the DTLS server depending on the setup attributes exchanged, as be the DTLS server depending on the setup attributes exchanged;
defined in [7]. examples can be found in [8].
8. Protocol Transactions 8. Protocol Transactions
In BFCP, there are two types of transactions: client-initiated In BFCP, there are two types of transactions: client-initiated
transactions and server-initiated transactions (notifications). transactions and server-initiated transactions (notifications).
Client-initiated transactions consist of a request from a client to a Client-initiated transactions consist of a request from a client to a
floor control server and a response from the floor control server to floor control server and a response from the floor control server to
the client. The request carries a Transaction ID in its common the client. The request carries a Transaction ID in its common
header, which the floor control server copies into the response. header, which the floor control server copies into the response.
Clients use Transaction ID values to match responses with previously Clients use Transaction ID values to match responses with previously
skipping to change at page 45, line 8 skipping to change at page 45, line 37
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 transmission attempts.
If a valid response is not received for a client- or server-initiated If a valid response is not received for a client- or server-initiated
transaction, the implementation MUST consider the BFCP association as transaction, the implementation MUST consider the BFCP association as
failed. Implementations SHOULD follow the reestablishment procedure failed. Implementations SHOULD follow the reestablishment procedure
described in section 6 (e.g. initiate a new offer/answer [11] described in section 6 (e.g. initiate a new offer/answer [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
T2 is a timer that, when fires, signals that the BFCP entity can T2 is a timer that, when fires, signals that the BFCP entity can
release knowledge of the transaction against which it is running. It release knowledge of the transaction against which it is running. It
is started upon the first transmission of the response to a request is started upon the first transmission of the response to a request
and is the only mechanism by which that response is released by the and is the only mechanism by which that response is released by the
BFCP entity. Any subsequent retransmissions of the same request can BFCP entity. Any subsequent retransmissions of the same request can
skipping to change at page 46, line 31 skipping to change at page 47, line 15
9.1. TLS/DTLS Based Mutual Authentication 9.1. TLS/DTLS Based Mutual Authentication
BFCP supports TLS/DTLS based mutual authentication between clients BFCP supports TLS/DTLS based mutual authentication between clients
and floor control servers. BFCP assumes that there is an integrity- and floor control servers. BFCP assumes that there is an integrity-
protected channel between the client and the floor control server protected channel between the client and the floor control server
that can be used to exchange their self-signed certificates or, more that can be used to exchange their self-signed certificates or, more
commonly, the fingerprints of these certificates. These certificates commonly, the fingerprints of these certificates. These certificates
are used at TLS/DTLS establishment time. are used at TLS/DTLS establishment time.
The implementation of such an integrity-protected channel using The implementation of such an integrity-protected channel using
SIP and the SDP offer/answer model is described in [6]. SIP and the SDP offer/answer model is described in [7].
BFCP messages received over an authenticated TLS/DTLS connection are BFCP messages received over an authenticated TLS/DTLS connection are
considered authenticated. A floor control server that receives a considered authenticated. A floor control server that receives a
BFCP message over TCP/UDP (no TLS/DTLS) can request the use of TLS/ BFCP message over TCP/UDP (no TLS/DTLS) can request the use of TLS/
DTLS by generating an Error message, as described in Section 13.8, DTLS by generating an Error message, as described in Section 13.8,
with an Error code with a value of 9 (Use TLS) or a value of 11 (Use with an Error code with a value of 9 (Use TLS) or a value of 11 (Use
DTLS) respectively. Clients SHOULD simply ignore unauthenticated DTLS) respectively. Clients SHOULD simply ignore unauthenticated
messages. messages.
Note that future extensions may define additional authentication Note that future extensions may define additional authentication
skipping to change at page 69, line 32 skipping to change at page 70, line 16
TLS/DTLS connection is allowed to use). TLS/DTLS connection is allowed to use).
Attackers may attempt to pick messages from the network to get access Attackers may attempt to pick messages from the network to get access
to confidential information between the floor control server and a to confidential information between the floor control server and a
client (e.g., why a floor request was denied). TLS/DTLS client (e.g., why a floor request was denied). TLS/DTLS
confidentiality prevents this attack. Therefore, it is 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 This IANA has created a new registry for BFCP parameters called
"Binary Floor Control Protocol (BFCP) Parameters". This new registry "Binary Floor Control Protocol (BFCP) Parameters". This new registry
has a number of subregistries, which are described in the following has a 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 2434 [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,
name, format, and semantics. name, format, and semantics.
For each BFCP attribute, the IANA registers its type, its name, and For each BFCP attribute, the IANA registers its type, its name, and
the reference to the RFC where the attribute is defined. The the reference to the RFC where the attribute is defined. The
following table contains the initial values of this subregistry. following table contains the initial values of this subregistry.
skipping to change at page 70, line 34 skipping to change at page 71, line 32
| 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] | | 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] |
| 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] | | 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] |
| 17 | FLOOR-REQUEST-STATUS | [RFC XXXX] | | 17 | FLOOR-REQUEST-STATUS | [RFC XXXX] |
| 18 | OVERALL-REQUEST-STATUS | [RFC XXXX] | | 18 | OVERALL-REQUEST-STATUS | [RFC XXXX] |
+------+---------------------------+------------+ +------+---------------------------+------------+
Table 7: Initial values of the BFCP Attribute subregistry Table 7: Initial values of the BFCP Attribute subregistry
15.2. Primitive Subregistry 15.2. Primitive Subregistry
Editorial note: This section instructs the IANA to register the [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, ErrorAck, 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 2434 [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
the reference to the RFC where the primitive is defined. The the reference to the RFC where the primitive is defined. The
following table contains the initial values of this subregistry. following table contains the initial values of this subregistry.
skipping to change at page 71, line 33 skipping to change at page 72, line 33
| 16 | FloorStatusAck | [RFC XXXX] | | 16 | FloorStatusAck | [RFC XXXX] |
| 17 | Goodbye | [RFC XXXX] | | 17 | Goodbye | [RFC XXXX] |
| 18 | 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 2434 [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
BFCP request status for which IANA registration is requested MUST be BFCP request status for which IANA registration is requested MUST be
defined by a standards-track RFC. Such an RFC MUST specify the value defined by a standards-track RFC. Such an RFC MUST specify the value
and the semantics of the request status. and the semantics of the request status.
For each BFCP request status, the IANA registers its value, its For each BFCP request status, the IANA registers its value, its
meaning, and the reference to the RFC where the request status is meaning, and the reference to the RFC where the request status is
defined. The following table contains the initial values of this defined. The following table contains the initial values of this
subregistry. subregistry.
skipping to change at page 72, line 21 skipping to change at page 73, line 21
| 4 | Denied | [RFC XXXX] | | 4 | Denied | [RFC XXXX] |
| 5 | Cancelled | [RFC XXXX] | | 5 | Cancelled | [RFC XXXX] |
| 6 | Released | [RFC XXXX] | | 6 | Released | [RFC XXXX] |
| 7 | Revoked | [RFC XXXX] | | 7 | Revoked | [RFC XXXX] |
+-------+-----------+------------+ +-------+-----------+------------+
Table 9: Initial values of the Request Status subregistry Table 9: Initial values of the Request Status subregistry
15.4. Error Code Subregistry 15.4. Error Code Subregistry
Editorial note: This section instructs the IANA to register the [Editorial note: This section instructs the IANA to register the
following new values for the BFCP Error Code subregistry: 10, 11 following new values for the BFCP Error Code subregistry: 10, 11,
and 12. 12, 13 and 14.]
This section establishes the Error Code subregistry under the BFCP This section establishes the Error Code subregistry under the BFCP
Parameters registry. As per the terminology in RFC 2434 [3], the Parameters registry. As per the terminology in RFC 5226 [3], the
registration policy for BFCP error codes shall be "Specification registration policy for BFCP error codes shall be "Specification
Required". For the purposes of this subregistry, the BFCP error Required". For the purposes of this subregistry, the BFCP error
codes for which IANA registration is requested MUST be defined by a codes for which IANA registration is requested MUST be defined by a
standards-track RFC. Such an RFC MUST specify the value and the standards-track RFC. Such an RFC MUST specify the value and the
semantics of the error code, and any Error Specific Details that semantics of the error code, and any Error Specific Details that
apply to it. apply to it.
For each BFCP primitive, the IANA registers its value, its meaning, For each BFCP primitive, the IANA registers its value, its meaning,
and the reference to the RFC where the primitive is defined. The and the reference to the RFC where the primitive is defined. The
following table contains the initial values of this subregistry. following table contains the initial values of this subregistry.
skipping to change at page 73, line 22 skipping to change at page 74, line 22
| 5 | Unauthorized Operation | [RFC XXXX] | | 5 | Unauthorized Operation | [RFC XXXX] |
| 6 | Invalid Floor ID | [RFC XXXX] | | 6 | Invalid Floor ID | [RFC XXXX] |
| 7 | Floor Request ID Does Not Exist | [RFC XXXX] | | 7 | Floor Request ID Does Not Exist | [RFC XXXX] |
| 8 | You have Already Reached the Maximum | [RFC XXXX] | | 8 | You have Already Reached the Maximum | [RFC XXXX] |
| | Number of Ongoing Floor Requests for | | | | Number of Ongoing Floor Requests for | |
| | this Floor | | | | this Floor | |
| 9 | Use TLS | [RFC XXXX] | | 9 | Use TLS | [RFC XXXX] |
| 10 | Unable to parse message | [RFC XXXX] | | 10 | Unable to parse message | [RFC XXXX] |
| 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] |
| 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 [16]. Following is the list of technical changes and other 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
skipping to change at page 74, line 45 skipping to change at page 76, line 5
Examples over unreliable transport (Appendix A): Examples over unreliable transport (Appendix A):
Added sample interactions over unreliable transport for the Added sample interactions over unreliable transport for the
scenarios in Figure 2 and Figure 3 scenarios in Figure 2 and Figure 3
Motivation for unreliable transport (Appendix B): Motivation for unreliable transport (Appendix B):
Introduction to and motivation for extending BFCP to support Introduction to and motivation for extending BFCP to support
unreliable transport. unreliable transport.
The clarification and bug fixes: The clarification and bug fixes:
ABNF fix (Section 5.3.8): ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>,
For the FLOOR-ID attribute rather prepend with "1*", not "*1". Figure 28, Figure 30, and the ABNF figures in Section 5.3):
Although formally correct in [17], the notation has changed in a
number of Figures to an equivalent form for clarity, e.g.
s/*1(FLOOR-ID)/[FLOOR-ID]/ in Figure 38 and s/*[XXX]/*(XXX)/ in
the other figures.
Typo (Section 12.4.2): Typo (Section 12.4.2):
Change from SUPPORTED-PRIMITIVES to SUPPORTED-PRIMITVIES in the Change from SUPPORTED-PRIMITIVES to SUPPORTED-PRIMITVIES in the
second paragraph. second paragraph.
Corrected attribute type (Section 13.1.1): Corrected attribute type (Section 13.1.1):
Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in
the ninth paragraph, since the note below describes priority and the eighth paragraph, since the note below describes priority and
that the last paragraph deals with PARTICIPANT-PROVIDED-INFO. that the last paragraph deals with PARTICIPANT-PROVIDED-INFO.
17. Contributing Authors New error codes (Section 5.2.6):
Added two additional error codes: "Incorrect Message Length" and
The original authors of RFC 4582 [16] were Gonzalo Camarillo, Joerg "Generic Error".
Ott and Keith Drage. The editor would also like to thank Geir A.
Sandbakken, Alfred E. Heggestad, Charles Eckel, Mark K. Thompson,
Eoin McLeod and Nivedita Melinkeri who made a major contribution to
the development of the revision of BFCP for use over an unreliable
transport.
Gonzalo Camarillo
Ericsson
Email: Gonzalo.Camarillo@ericsson.com
Joerg Ott
Helsinki University of Technology
Email: jo@netlab.hut.fi
Keith Drage
Alcatel-Lucent
Email: keith.drage@alcatel-lucent.com
Charles Eckel
Cisco
Email: eckelcu@cisco.com
Alfred E. Heggestad
Cisco
Email: aheggest@cisco.com
Geir A. Sandbakken
Cisco
Email: geirsand@cisco.com
Eoin McLeod
Cisco
Email: eoimcleo@cisco.com
Nivedita Melinkeri
Cisco
Email: nivedita@cisco.com
Mark K. Thompson
Cisco
Email: markth2@cisco.com
18. Acknowledgements 17. Acknowledgements
The XCON WG chairs, Adam Roach and Alan Johnston, provided useful The XCON WG chairs, Adam Roach and Alan Johnston, provided useful
ideas for RFC 4582 [16]. Additionally, Xiaotao Wu, Paul Kyzivat, ideas for RFC 4582 [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 editor also acknowledge contributions the work with RFC 4582. The authors also acknowledge contributions
during the to the development of the revision of BFCP for use over an to the revision of BFCP for use over an unreliable transport from
unreliable transport from Trond G. Andersen, Gonzalo Camarillo, Roni Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad,
Even, Lorenzo Miniero, Joerg Ott, Hadriel Kaplan, Dan Wing, Cullen Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero,
Jennings, David Benham, Vijaya Mandava and Alan Ford. Joerg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing,
Cullen Jennings, David Benham, Nivedita Melinkeri, Vijaya Mandava and
Alan Ford.
19. References 18. References
19.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., Ed. and P. Overell, "Augmented BNF for Syntax [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
October 1998.
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, August 2008. Protocol Version 1.2", RFC 5246, August 2008.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
[6] Kristensen, T. and G. Camarillo, "Session Description Protocol [7] Camarillo, G. and T. Kristensen, Ed., "Session Description
(SDP) Format for Binary Floor Control Protocol (BFCP) Streams", Protocol (SDP) Format for Binary Floor Control Protocol (BFCP)
draft-ietf-bfcpbis-rfc4583bis-00 (work in progress), Streams", draft-ietf-bfcpbis-rfc4583bis-01 (work in progress),
March 2012. June 2012.
[7] 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.
[8] 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.
[9] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [10] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
[10] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session [11] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session
Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
19.2. Informational References 18.2. Informational References
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[12] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, [13] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
"Requirements for Floor Control Protocols", RFC 4376, "Requirements for Floor Control Protocols", RFC 4376,
February 2006. February 2006.
[13] Barnes, M., Boulton, C., and O. Levin, "A Framework for [14] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", RFC 5239, June 2008. Centralized Conferencing", RFC 5239, June 2008.
[14] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Protocol for Network Address Translator (NAT) Traversal for Protocol for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", RFC 5245, April 2010. Offer/Answer Protocols", RFC 5245, April 2010.
[15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[16] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control [17] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
Protocol (BFCP)", RFC 4582, November 2006. Protocol (BFCP)", RFC 4582, November 2006.
[17] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network [18] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network
Address Translations (NATs)", RFC 4380, February 2006. Address Translations (NATs)", RFC 4380, February 2006.
[18] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for [19] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for
Application Designers", BCP 145, RFC 5405, November 2008. Application Designers", BCP 145, RFC 5405, November 2008.
[19] Thaler, D., "Teredo Extensions", RFC 6081, January 2011. [20] Thaler, D., "Teredo Extensions", RFC 6081, January 2011.
[20] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP [21] Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
September 2007.
[22] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP
Candidates with Interactive Connectivity Establishment (ICE)", Candidates with Interactive Connectivity Establishment (ICE)",
draft-ietf-mmusic-ice-tcp-16 (work in progress), November 2011. RFC 6544, March 2012.
[21] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling [23] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling
(GUT)", draft-manner-tsvwg-gut-02 (work in progress), (GUT)", draft-manner-tsvwg-gut-02 (work in progress),
July 2010. July 2010.
[22] Stucker, B. and H. Tschofenig, "Analysis of Middlebox [24] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of
Interactions for Signaling Protocol Communication along the Middlebox Interactions for Signaling Protocol Communication
Media Path", draft-ietf-mmusic-media-path-middleboxes-03 (work along the Media Path",
in progress), July 2010. draft-ietf-mmusic-media-path-middleboxes-04 (work in progress),
January 2012.
[23] Guha, S. and P. Francis, "Characterization and Measurement of [25] Guha, S. and P. Francis, "Characterization and Measurement of
TCP Traversal through NATs and Firewalls", 2005, TCP Traversal through NATs and Firewalls", 2005,
<http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>. <http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>.
[24] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer [26] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer
Communication Across Network Address Translators", April 2005, Communication Across Network Address Translators", April 2005,
<http://www.brynosaurus.com/pub/net/p2pnat.pdf/>. <http://www.brynosaurus.com/pub/net/p2pnat.pdf/>.
Appendix A. Example Call Flows for BFCP over Unreliable Transport Appendix A. Example Call Flows for BFCP over Unreliable Transport
With reference to Section 4.1, the following figures show With reference to Section 4.1, the following figures show
representative call-flows for requesting and releasing a floor, and representative call-flows for requesting and releasing a floor, and
obtaining status information about a floor when BFCP is deployed over obtaining status information about a floor when BFCP is deployed over
an unreliable transport. The figures here show a loss-less an unreliable transport. The figures here show a loss-less
interaction. interaction.
skipping to change at page 81, line 43 skipping to change at page 82, line 18
| 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 50: Obtaining status information about a floor
Appendix B. Motivation for and Introduction to Supporting Unreliable Appendix B. Motivation for Supporting Unreliable Transport
Transport
Editorial note: This appendix is more or less a verbatim copy of
the Introduction and Motivation Sections of earlier versions of
this draft. It is contained in this document as an aid and
rationale for new readers and reviewers. However, it is not sure
this Appendix will be part of the final (RFC) version of this
draft.
B.1. Introduction
This draft describes how to extend the BFCP protocol to support
unreliable transport. Minor changes to the transaction model are
introduced in that all requests now have an appropriate response to
complete the transaction. The requests are sent with a retransmit
timer associated with the response to achieve reliability.
This extension does not change the semantics of BFCP. It permits UDP [Editorial note: This appendix is contained in this draft as an
as an alternate transport. Existing implementations, in the spirit aid and rationale for new readers and reviewers. However, it is
of the approach detailed in earlier versions of this draft, have not yet decided whether this Appendix will be part of the final
demonstrated the approach to be feasible. Initial compatibility (RFC) version or not.]
among implementations has been achieved at previous interoperability
events. The purpose of this draft is to formalize and publish the
extension from the standard specification to facilitate complete
interoperability between implementations.
B.2. Motivation B.1. Motivation
In existing video conferencing deployments, BFCP is used to manage In existing video conferencing deployments, BFCP is used to manage
the floor for the content sharing associated with the conference. the floor for the content sharing associated with the conference.
For peer to peer scenarios, including business to business For peer to peer scenarios, including business to business
conferences and point to point conferences in general, it is conferences and point to point conferences in general, it is
frequently the case that one or both endpoints exists behind a NAT/ frequently the case that one or both endpoints exists behind a NAT/
firewall. BFCP roles are negotiated in the offer/answer exchange as firewall. BFCP roles are negotiated in the offer/answer exchange as
specified in [6], resulting in one endpoint being responsible for specified in [7], resulting in one endpoint being responsible for
opening the TCP connection used for the BFCP communication. opening the TCP connection used for the BFCP communication.
+---------+ +---------+
| Network | | Network |
+---------+ +---------+
+-----+ / \ +-----+ +-----+ / \ +-----+
| NAT |/ \| NAT | | NAT |/ \| NAT |
+-----+ +-----+ +-----+ +-----+
+----+ / \ +----+ +----+ / \ +----+
|BFCP|/ \|BFCP| |BFCP|/ \|BFCP|
skipping to change at page 83, line 6 skipping to change at page 83, line 9
+----+ +----+ +----+ +----+
Figure 51: Use Case Figure 51: 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 [22]. described in [24].
When enhancing an existing SIP based video conferencing deployment When enhancing an existing SIP based video conferencing deployment
with support for content sharing, the BFCP connection often poses a with support for content sharing, the BFCP connection often poses a
problem. The reasons for this fall into two general classes. First, problem. The reasons for this fall into two general classes. First,
there may be a strong preference for UDP based signaling in general. there may be a strong preference for UDP based signaling in general.
On high capacity endpoints (e.g. PSTN gateways or SIP/H.323 inter- On high capacity endpoints (e.g. PSTN gateways or SIP/H.323 inter-
working gateways), TCP can suffer from head of line blocking, and it working gateways), TCP can suffer from head of line blocking, and it
uses many kernel buffers. Network operators view UDP as a way to uses many kernel buffers. Network operators view UDP as a way to
avoid both of these. Second, establishment and traversal of the TCP avoid both of these. Second, establishment and traversal of the TCP
connection involving ephemeral ports, as is typically the case with connection involving ephemeral ports, as is typically the case with
BFCP over TCP, can be problematic, as described in Appendix A of BFCP over TCP, can be problematic, as described in Appendix A of
[20]. A broad study of NAT behavior and peer-to-peer TCP [22]. A broad study of NAT behavior and peer-to-peer TCP
establishment for a comprehensive set of TCP NAT traversal techniques establishment for a comprehensive set of TCP NAT traversal techniques
over a wide range of commercial NAT products concluded it was not over a wide range of commercial NAT products concluded it was not
possible to establish a TCP connection in 11% of the cases [23]. The possible to establish a TCP connection in 11% of the cases [25]. The
results are worse when focusing on enterprise NATs. A study of hole results are worse when focusing on enterprise NATs. A study of hole
punching as a NAT traversal technique across a wide variety of punching as a NAT traversal technique across a wide variety of
deployed NATs reported consistently higher success rates when using deployed NATs reported consistently higher success rates when using
UDP than when using TCP [24]. UDP than when using TCP [26].
To overcome the problems with establishing TCP flows between BFCP
entities, this draft defines UDP as an alternate transport for BFCP,
leveraging the same mechanisms in place for the RTP over UDP media
streams for the BFCP communication. When using UDP as the transport,
it is RECOMMENDED to follow the guidelines provided in [18].
The authors view this extension as a pragmatic solution to an It is worth noticing that BFCP over UDP were already used in real
existing deployment challenge. deployments, underlining the necessity to specify a common way to
exchange BFCP messages where TCP is not appropriate, to avoid a
situation where multiple different and non-interoperable would co-
exist in the market. The purpose of this draft is to formalize and
publish the extension from the standard specification to facilitate
complete interoperability between implementations.
B.2.1. Alternatives Considered B.1.1. Alternatives Considered
In selecting the approach of defining UDP as an alternate transport In selecting the approach of defining UDP as an alternate transport
for BFCP, several alternatives were considered and explored to some for BFCP, several alternatives were considered and explored to some
degree. Each of these is discussed briefly in the following degree. Each of these is discussed briefly in the following
subsections. In summary, while these alternatives work in a number subsections. In summary, while the not chosen alternatives work in a
of scenarios, they are not sufficient, in and of themselves, to number of scenarios, they are not sufficient, in and of themselves,
address the use case targeted by this draft. to address the use case targeted by this draft. The last
alternative, presented in Appendix B.1.1.7, is the selected one and
is specified in this draft.
B.2.1.1. ICE TCP It is also worth noting that the IETF Transport Area were asked for a
way to tunnel TCP over UDP, but at that point there was no consensus
on how to achieve that.
ICE TCP [20] extends ICE to TCP based media, including the ability to B.1.1.1. ICE TCP
ICE TCP [22] extends ICE to TCP based media, including the ability to
offer a mix of TCP and UDP based candidates for a single stream. ICE offer a mix of TCP and UDP based candidates for a single stream. ICE
TCP has, in general, a lower success probability for enabling TCP TCP has, in general, a lower success probability for enabling TCP
connectivity without a relay if both of the hosts are behind a NAT connectivity without a relay if both of the hosts are behind a NAT
(see Appendix A of [20]) than enabling UDP connectivity in the same (see Appendix A of [22]) than enabling UDP connectivity in the same
scenarios. The happens because many of the currently deployed NATs scenarios. The happens because many of the currently deployed NATs
in video conferencing networks do not support the flow of TCP hand in video conferencing networks do not support the flow of TCP hand
shake packets seen in case of TCP simultaneous-open, either because shake packets seen in case of TCP simultaneous-open, either because
they do not allow incoming TCP SYN packets from an address to which a they do not allow incoming TCP SYN packets from an address to which a
SYN packet has been sent to recently, or because they do not properly SYN packet has been sent to recently, or because they do not properly
process the subsequent SYNACK. Implementing various techniques process the subsequent SYNACK. Implementing various techniques
advocated for candidate collection in [20] should increase the advocated for candidate collection in [22] should increase the
success probability, but many of these techniques require support success probability, but many of these techniques require support
from some network elements (e.g., from the NATs). Such support is from some network elements (e.g., from the NATs). Such support is
not common in enterprise firewalls and NATs. not common in enterprise firewalls and NATs.
B.2.1.2. Teredo B.1.1.2. Teredo
Teredo [17] enables nodes located behind one or more IPv4 NATs to Teredo [18] enables nodes located behind one or more IPv4 NATs to
obtain IPv6 connectivity by tunneling packets over UDP. Teredo obtain IPv6 connectivity by tunneling packets over UDP. Teredo
extensions [19] provide additional capabilities to Teredo, including extensions [20] provide additional capabilities to Teredo, including
support for more types of NATs and support for more efficient support for more types of NATs and support for more efficient
communication. communication.
As defined, Teredo could be used to make BFCP work for the video As defined, Teredo could be used to make BFCP work for the video
conferencing use cases addressed in this draft. However, running the conferencing use cases addressed in this draft. However, running the
service requires the help of "Teredo servers" and "Teredo relays" service requires the help of "Teredo servers" and "Teredo relays"
[17]. These servers and relays generally do not exist in the [18]. These servers and relays generally do not exist in the
existing video conferencing deployments. It also requires IPv6 existing video conferencing deployments. It also requires IPv6
awareness on the endpoints. It should also be noted that ICMP6, as awareness on the endpoints. It should also be noted that ICMP6, as
used with Teredo to complete an initial protocol exchange and confirm used with Teredo to complete an initial protocol exchange and confirm
that the appropriate NAT bindings have been set up, is not a that the appropriate NAT bindings have been set up, is not a
conventional feature of IPv4 or even IPv6, and some currently conventional feature of IPv4 or even IPv6, and some currently
deployed IPv6 firewalls discard ICMP messages. As these networks deployed IPv6 firewalls discard ICMP messages. As these networks
continue to evolve and tackle the transaction to IPv6, Teredo servers continue to evolve and tackle the transaction to IPv6, Teredo servers
and relays may be deployed, making Teredo available as a suitable and relays may be deployed, making Teredo available as a suitable
alternative to BFCP over UDP. alternative to BFCP over UDP.
B.2.1.3. GUT B.1.1.3. GUT
GUT [21] attempts to facilitate tunneling over UDP by encapsulating GUT [23] attempts to facilitate tunneling over UDP by encapsulating
the native transport protocol and its payload (in general the whole the native transport protocol and its payload (in general the whole
IP payload) within a UDP packet destined to the well-known port IP payload) within a UDP packet destined to the well-known port
GUT_P. Unfortunately, it requires user-space TCP, for which there is GUT_P. Unfortunately, it requires user-space TCP, for which there is
not a readily available implementation, and creating one is a large not a readily available implementation, and creating one is a large
project in itself. This draft has expired and its future is still project in itself. This draft has expired and its future is still
not clear as it has not yet been adopted by a working group. not clear as it has not yet been adopted by a working group.
B.2.1.4. UPnP IGD B.1.1.4. UPnP IGD
Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on
the edge of the network, providing connectivity to the Internet for the edge of the network, providing connectivity to the Internet for
computers internal to the LAN, but do not allow Internet devices to computers internal to the LAN, but do not allow Internet devices to
connect to computers on the internal LAN. IGDs enable a computer on connect to computers on the internal LAN. IGDs enable a computer on
an internal LAN to create port mappings on their NAT, through which an internal LAN to create port mappings on their NAT, through which
hosts on the Internet can send data that will be forwarded to the hosts on the Internet can send data that will be forwarded to the
computer on the internal LAN. IGDs may be self-contained hardware computer on the internal LAN. IGDs may be self-contained hardware
devices or may be software components provided within an operating devices or may be software components provided within an operating
system. system.
In considering UPnP IGD, several issues exist. Not all NATs support In considering UPnP IGD, several issues exist. Not all NATs support
UPnP, and many that do support it are configured with it turned off UPnP, and many that do support it are configured with it turned off
by default. NATs are often multilayered, and UPnP does not work well by default. NATs are often multilayered, and UPnP does not work well
with such NATs. For example, a typical DSL modems acts as a NAT, and with such NATs. For example, a typical DSL modems acts as a NAT, and
the user plugs in a wireless access point behind that, which adds the user plugs in a wireless access point behind that, which adds
another layer NAT. The client can discover the first layer of NAT another layer NAT. The client can discover the first layer of NAT
using multicast but it is harder to figure out how to discover and using multicast but it is harder to figure out how to discover and
control NATs in the next layer up. control NATs in the next layer up.
B.2.1.5. NAT PMP B.1.1.5. NAT PMP
The NAT Port Mapping Protocol (NAT PMP) allows a computer in a The NAT Port Mapping Protocol (NAT PMP) allows a computer in a
private network (behind a NAT router) to automatically configure the private network (behind a NAT router) to automatically configure the
router to allow parties outside the private network to contact it. router to allow parties outside the private network to contact it.
NAT PMP runs over UDP. It essentially automates the process of port NAT PMP runs over UDP. It essentially automates the process of port
forwarding. Included in the protocol is a method for retrieving the forwarding. Included in the protocol is a method for retrieving the
public IP address of a NAT gateway, thus allowing a client to make public IP address of a NAT gateway, thus allowing a client to make
this public IP address and port number known to peers that may wish this public IP address and port number known to peers that may wish
to communicate with it. to communicate with it.
Many NATs do not support PMP. In those that do support it, it has Many NATs do not support PMP. In those that do support it, it has
similar issues with negotiation of multilayer NATs as UPnP. Video similar issues with negotiation of multilayer NATs as UPnP. Video
conferencing is used extensively in enterprise networks, and NAT PMP conferencing is used extensively in enterprise networks, and NAT PMP
is not generally available in enterprise-class routers. is not generally available in enterprise-class routers.
Author's Address B.1.1.6. SCTP
It would be quite straight forward to specify a BFCP binding for SCTP
[21], and then tunnel SCTP over UDP in the use case described in
Appendix B.1. SCTP is gaining some momentum currently. There is
ongoing discussion in the RTCWeb WG regarding this approach.
However, this approach for tunneling over UDP was not mature enough
when considered and not even fully specified.
B.1.1.7. BFCP over UDP transport
To overcome the problems with establishing TCP flows between BFCP
entities, an alternative is to define UDP as an alternate transport
for BFCP, leveraging the same mechanisms in place for the RTP over
UDP media streams for the BFCP communication. When using UDP as the
transport, it is recommended to follow the guidelines provided in
[19].
Minor changes to the transaction model are introduced in that all
requests now have an appropriate response to complete the
transaction. The requests are sent with a retransmit timer
associated with the response to achieve reliability. This
alternative does not change the semantics of BFCP. It permits UDP as
an alternate transport.
Existing implementations, in the spirit of the approach detailed in
earlier versions of this draft, have demonstrated this approach to be
feasible. Initial compatibility among implementations has been
achieved at previous interoperability events. The authors view this
extension as a pragmatic solution to an existing deployment
challenge. This is the chosen approach, and the extensions is
specified in this document.
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: gonzalo.camarillo@ericsson.com
Keith Drage
Alcatel-Lucent
Quadrant, StoneHill Green, Westlea
Swindon, Wilts
UK
Email: drage@alcatel-lucent.com
Tom Kristensen (editor) Tom Kristensen (editor)
Cisco Cisco
Philip Pedersens vei 22 Philip Pedersens vei 22
N-1366 Lysaker N-1366 Lysaker
Norway Norway
Email: tomkrist@cisco.com, tomkri@ifi.uio.no Email: tomkrist@cisco.com, tomkri@ifi.uio.no
Joerg Ott
Aalto University
Otakaari 5 A
Espoo, FIN 02150
Finland
Email: jo@comnet.tkk.fi
Charles Eckel
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States
Email: eckelcu@cisco.com
 End of changes. 166 change blocks. 
323 lines changed or deleted 346 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/