draft-ietf-bfcpbis-rfc4582bis-11.txt   draft-ietf-bfcpbis-rfc4582bis-12.txt 
BFCPbis Working Group G. Camarillo BFCPbis Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: 4582 (if approved) K. Drage Obsoletes: 4582 (if approved) K. Drage
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: August 19, 2014 T. Kristensen Expires: April 30, 2015 T. Kristensen
Cisco Cisco
J. Ott J. Ott
Aalto University Aalto University
C. Eckel C. Eckel
Cisco Cisco
February 15, 2014 October 27, 2014
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-bfcpbis-rfc4582bis-11 draft-ietf-bfcpbis-rfc4582bis-12
Abstract Abstract
Floor control is a means to manage joint or exclusive access to Floor control is a means to manage joint or exclusive access to
shared resources in a (multiparty) conferencing environment. shared resources in a (multiparty) conferencing environment.
Thereby, floor control complements other functions -- such as Thereby, floor control complements other functions -- such as
conference and media session setup, conference policy manipulation, conference and media session setup, conference policy manipulation,
and media control -- that are realized by other protocols. and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP). This document specifies the Binary Floor Control Protocol (BFCP).
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2014. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 27 skipping to change at page 3, line 27
5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 38 5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 38
5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . . 38 5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . . 38
5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38 5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 38 5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 38
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . . 39 6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . . 39
6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . 40 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . 40
6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . 42 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . 41
6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42
6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . . 43 6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . . 42
6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 44 6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 44
7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 44 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 44
8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 45 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 44
8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 46 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 45
8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 46 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 46
8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 47 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 46
8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 47 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 46
8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 47 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 47
9. Authentication and Authorization . . . . . . . . . . . . . . . 48 9. Authentication and Authorization . . . . . . . . . . . . . . . 47
9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 48 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 48
10. Floor Participant Operations . . . . . . . . . . . . . . . . . 49 10. Floor Participant Operations . . . . . . . . . . . . . . . . . 48
10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 49 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 49
10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 49 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 49
10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 50 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 49
10.1.3. Reception of a Subsequent FloorRequestStatus 10.1.3. Reception of a Subsequent FloorRequestStatus
Message . . . . . . . . . . . . . . . . . . . . . . . 51 Message . . . . . . . . . . . . . . . . . . . . . . . 51
10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 52 10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 51
10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 52 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 51
10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 52 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 52
11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 53 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 52
11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 53 11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 52
11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 54 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 54
12. General Client Operations . . . . . . . . . . . . . . . . . . 55 12. General Client Operations . . . . . . . . . . . . . . . . . . 54
12.1. Requesting Information about Floors . . . . . . . . . . . 55 12.1. Requesting Information about Floors . . . . . . . . . . . 54
12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 55 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 54
12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 55 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 55
12.1.3. Reception of a Subsequent FloorStatus Message . . . . 56 12.1.3. Reception of a Subsequent FloorStatus Message . . . . 55
12.2. Requesting Information about Floor Requests . . . . . . . 56 12.2. Requesting Information about Floor Requests . . . . . . . 56
12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 57 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 56
12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 57 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 56
12.3. Requesting Information about a User . . . . . . . . . . . 57 12.3. Requesting Information about a User . . . . . . . . . . . 57
12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 58 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 57
12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 58 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 57
12.4. Obtaining the Capabilities of a Floor Control Server . . . 59 12.4. Obtaining the Capabilities of a Floor Control Server . . . 58
12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 59 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 58
12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 59 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 58
13. Floor Control Server Operations . . . . . . . . . . . . . . . 59 13. Floor Control Server Operations . . . . . . . . . . . . . . . 59
13.1. Reception of a FloorRequest Message . . . . . . . . . . . 60 13.1. Reception of a FloorRequest Message . . . . . . . . . . . 59
13.1.1. Generating the First FloorRequestStatus Message . . . 60 13.1.1. Generating the First FloorRequestStatus Message . . . 60
13.1.2. Generation of Subsequent FloorRequestStatus 13.1.2. Generation of Subsequent FloorRequestStatus
Messages . . . . . . . . . . . . . . . . . . . . . . . 62 Messages . . . . . . . . . . . . . . . . . . . . . . . 61
13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 63 13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 62
13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 64 13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 63
13.4. Reception of a FloorRelease Message . . . . . . . . . . . 66 13.4. Reception of a FloorRelease Message . . . . . . . . . . . 65
13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 67 13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 66
13.5.1. Generation of the First FloorStatus Message . . . . . 67 13.5.1. Generation of the First FloorStatus Message . . . . . 67
13.5.2. Generation of Subsequent FloorStatus Messages . . . . 69 13.5.2. Generation of Subsequent FloorStatus Messages . . . . 68
13.6. Reception of a ChairAction Message . . . . . . . . . . . . 69 13.6. Reception of a ChairAction Message . . . . . . . . . . . . 68
13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 70 13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 69
13.8. Error Message Generation . . . . . . . . . . . . . . . . . 71 13.8. Error Message Generation . . . . . . . . . . . . . . . . . 70
14. Security Considerations . . . . . . . . . . . . . . . . . . . 71 14. Security Considerations . . . . . . . . . . . . . . . . . . . 70
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 72 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 72
15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 73 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 73
15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 74 15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 73
15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 75 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 74
16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 76 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 75
16.1. Extensions for an unreliable transport . . . . . . . . . . 76 16.1. Extensions for an unreliable transport . . . . . . . . . . 75
16.2. Other changes . . . . . . . . . . . . . . . . . . . . . . 77 16.2. Other changes . . . . . . . . . . . . . . . . . . . . . . 76
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 77
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78
18.1. Normative References . . . . . . . . . . . . . . . . . . . 79 18.1. Normative References . . . . . . . . . . . . . . . . . . . 78
18.2. Informational References . . . . . . . . . . . . . . . . . 79 18.2. Informational References . . . . . . . . . . . . . . . . . 78
Appendix A. Example Call Flows for BFCP over an Unreliable Appendix A. Example Call Flows for BFCP over an Unreliable
Transport . . . . . . . . . . . . . . . . . . . . . . 81 Transport . . . . . . . . . . . . . . . . . . . . . . 80
Appendix B. Motivation for Supporting an Unreliable Transport . . 84 Appendix B. Motivation for Supporting an Unreliable Transport . . 83
B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 85 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 84
B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 86 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 85
B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 86 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 85
B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 86
B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 86
B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 86
B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 88 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 87
B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 88 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 87
B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 88 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88
1. Introduction 1. Introduction
Within a conference, some applications need to manage the access to a Within a conference, some applications need to manage the access to a
set of shared resources, such as the right to send media to a set of shared resources, such as the right to send media to a
particular media session. Floor control enables such applications to particular media session. Floor control enables such applications to
provide users with coordinated (shared or exclusive) access to these provide users with coordinated (shared or exclusive) access to these
resources. resources.
The Requirements for Floor Control Protocol [13] list a set of The Requirements for Floor Control Protocol [13] list a set of
skipping to change at page 9, line 30 skipping to change at page 9, line 30
3.2. Obtaining Information to Contact a Floor Control Server 3.2. Obtaining Information to Contact a Floor Control Server
A client needs a set of data in order to establish a BFCP connection A client needs a set of data in order to establish a BFCP connection
to a floor control server. This data includes the transport address to a floor control server. This data includes the transport address
of the server, the conference identifier, and a user identifier. of the server, the conference identifier, and a user identifier.
Clients can obtain this information in different ways. One is to use Clients can obtain this information in different ways. One is to use
an SDP offer/answer [12] exchange, which is described in [9]. How to an SDP offer/answer [12] exchange, which is described in [9]. How to
establish a connection to a BFCP floor control server outside the establish a connection to a BFCP floor control server outside the
context of an offer/answer exchange is described in [3]. Other context of an offer/answer exchange when using a reliable transport
mechanisms are described in the XCON framework [14] (and other is described in [3]. Other mechanisms are described in the XCON
related documents). framework [14] (and other related documents). For unreliable
transports, the use of an SDP offer/answer exchange is the only
specified mechanism.
3.3. Obtaining Floor-Resource Associations 3.3. Obtaining Floor-Resource Associations
Floors are associated with resources. For example, a floor that Floors are associated with resources. For example, a floor that
controls who talks at a given time has a particular audio session as controls who talks at a given time has a particular audio session as
its associated resource. Associations between floors and resources its associated resource. Associations between floors and resources
are part of the conference object. are part of the conference object.
Floor participants and floor chairs need to know which resources are Floor participants and floor chairs need to know which resources are
associated with which floors. They can obtain this information by associated with which floors. They can obtain this information by
skipping to change at page 38, line 45 skipping to change at page 38, line 45
transmission of a Goodbye. The following is the format of the transmission of a Goodbye. The following is the format of the
Goodbye message: Goodbye message:
Goodbye = (COMMON-HEADER) Goodbye = (COMMON-HEADER)
*(EXTENSION-ATTRIBUTE) *(EXTENSION-ATTRIBUTE)
Figure 46: Goodbye format Figure 46: Goodbye format
5.3.17. GoodbyeAck 5.3.17. GoodbyeAck
BFCP entities communicating over an unreliable transport should BFCP entities communicating over an unreliable transport acknowledge
acknowledge the receipt of a Goodbye message from a peer. The the receipt of a Goodbye message from a peer. The following is the
following is the format of the GoodbyeAck message: format of the GoodbyeAck message:
GoodbyeAck = (COMMON-HEADER) GoodbyeAck = (COMMON-HEADER)
*(EXTENSION-ATTRIBUTE) *(EXTENSION-ATTRIBUTE)
Figure 47: GoodbyeAck format Figure 47: GoodbyeAck format
6. Transport 6. Transport
The transport over which BFCP entities exchange messages depends on The transport over which BFCP entities exchange messages depends on
how clients obtain information to contact the floor control server the information the clients obtain for how to to contact the floor
(e.g., using an SDP offer/answer exchange [9] or the procedure control server, as described in Section 3.2. Two transports are
specified in [3]). Two transports are supported: TCP, appropriate supported: TCP, appropriate where connectivity is not impeded by
where connectivity is not impeded by network elements such as NAT network elements such as NAT devices or media relays; and UDP for
devices or media relays; and UDP for those deployments where TCP may those deployments where TCP may not be applicable or appropriate.
not be applicable or appropriate.
Informational note: In practice products are configured to try one Informational note: In practice, products are configured to try
transport initially and use the other one as a fallback. Whether one transport first and use the other transport as a fallback.
TCP or UDP is chosen as underlying transport depends on type of Whether TCP or UDP is chosen as underlying transport depends on
product and the nature of the environment it is deployed. Here the type of product and the deployment environment. See
Appendix B are important to consider. Appendix B for additional considerations.
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 needs to be implemented in of bytes. Consequently, message framing needs to be implemented in
the application layer. BFCP implements application-layer framing the application layer. BFCP implements application-layer framing
using TLV-encoded attributes. using TLV-encoded attributes.
A client MUST NOT use more than one TCP connection to communicate A client MUST NOT use more than one TCP connection to communicate
skipping to change at page 40, line 37 skipping to change at page 40, line 37
that exceed the path MTU size is performed at the BFCP level. that exceed the path MTU size is performed at the BFCP level.
Considerations related to fragmentation are covered in Section 6.2.3. Considerations related to fragmentation are covered in Section 6.2.3.
The message format for BFCP messages is the same regardless of The message format for BFCP messages is the same regardless of
whether the messages are sent in UDP datagrams or over a TCP stream. whether the messages are sent in UDP datagrams or over a TCP stream.
Clients MUST announce their presence to the floor control server by Clients MUST announce their presence to the floor control server by
sending a Hello message. The floor control server responds to the sending a Hello message. The floor control server responds to the
Hello message with a HelloAck message. The client considers the Hello message with a HelloAck message. The client considers the
floor control service as present and available only upon receiving floor control service as present and available only upon receiving
the HelloAck message. Situations where the floor control service is the HelloAck message. Situations where the floor control service is
considered to have become unavailable due to ICMP messages is considered to have become unavailable due to ICMP messages are
described in Section 6.2.2 and the behavior when timers fire is described in Section 6.2.2 and the behavior when timers fire is
described in Section 8.3. described in Section 8.3.
As described in Section 8, each request sent by a floor participant As described in Section 8, each request sent by a floor participant
or chair forms a client transaction that expects an acknowledgement or chair forms a client transaction that expects an acknowledgement
message back from the floor control server within a retransmission message back from the floor control server within a retransmission
window. Concordantly, messages sent by the floor control server that window. Concordantly, messages sent by the floor control server that
initiate new transactions (e.g., FloorStatus announcements as part of initiate new transactions (e.g., FloorStatus announcements as part of
a FloorQuery subscription) require acknowledgement messages from the a FloorQuery subscription) require acknowledgement messages from the
floor participant and chair entities to which they were sent. floor participant and chair entities to which they were sent.
skipping to change at page 41, line 41 skipping to change at page 41, line 41
acknowledged, ordinality is maintained. acknowledged, ordinality is maintained.
If a client wishes to end its BFCP connection with a floor control If a client wishes to end its BFCP connection with a floor control
server, it is REQUIRED that the client send a Goodbye message to server, it is REQUIRED that the client send a Goodbye message to
dissociate itself from any allocated resources. If a floor control dissociate itself from any allocated resources. If a floor control
server wishes to end its BFCP connection with a client (e.g., the server wishes to end its BFCP connection with a client (e.g., the
Focus of the conference informs the floor control server that the Focus of the conference informs the floor control server that the
client has been kicked out from the conference), it is REQUIRED that client has been kicked out from the conference), it is REQUIRED that
the floor control server send a Goodbye message towards the client. the floor control server send a Goodbye message towards the client.
RFC 5018 [3] specifies how to establish a TCP connection to a floor
control server outside the context of an offer/answer exchange. When
using UDP the same set of data is needed for a BFCP connection as
listed in [3], Section 3, i.e. transport address of the server, the
conference identifier, and the user identifier. The procedures and
considerations for resolving a host name into an IP address also
applies to BFCP over an unreliable transport. In [3], Section 4
applies, but when using BFCP over an unreliable transport the floor
control server that receives a BFCP message over UDP (no DTLS) SHOULD
request the use of DTLS by generating an Error message with an Error
code with a value of 11 (Use DTLS). A floor control server that is
configured to require DTLS MUST request the use of DTLS this way.
The recommendations for authentication in [3], Section 5 and the
security considerations in [3], Section 6 also apply when an
unreliable transport is used, both for certificate-based server
authentication and for client authentication based on a pre-shared
secret.
6.2.1. Congestion Control 6.2.1. Congestion Control
BFCP may be characterized to generate "low data-volume" traffic, per BFCP may be characterized to generate "low data-volume" traffic, per
the classification in [25]. Nevertheless is it necessary to ensure the classification in [25]. Nevertheless is it necessary to ensure
suitable and necessary congestion control mechanisms are used for suitable and necessary congestion control mechanisms are used for
BFCP over UDP. As described in Section 6.2, within the same BFCP BFCP over UDP. As described in Section 6.2, within the same BFCP
connection, every entity - client or server - is only allowed to send connection, every entity - client or server - is only allowed to send
one request at a time, and await the acknowledging response. This one request at a time, and await the acknowledging response. This
way at most one datagram is sent per RTT given the message is not way at most one datagram is sent per RTT given the message is not
lost during transmission. In case the message is lost, the request lost during transmission. In case the message is lost, the request
skipping to change at page 45, line 11 skipping to change at page 44, line 43
BFCP relies on lower-layer security mechanisms to provide replay and BFCP relies on lower-layer security mechanisms to provide replay and
integrity protection and confidentiality. BFCP floor control servers integrity protection and confidentiality. BFCP floor control servers
and clients (which include both floor participants and floor chairs) and clients (which include both floor participants and floor chairs)
MUST support TLS for transport over TCP [6] and MUST support DTLS [7] MUST support TLS for transport over TCP [6] and MUST support DTLS [7]
for transport over UDP. Any BFCP entity MAY support other security for transport over UDP. Any BFCP entity MAY support other security
mechanisms. mechanisms.
BFCP entities MUST support, at a minimum, the BFCP entities MUST support, at a minimum, the
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].
Which party, the client or the floor control server, acts as the TLS/
DTLS server depends on how the underlying TLS/DTLS connection is
established. For a TCP/TLS connection established using an SDP
offer/answer exchange [9], the answerer (which may be the client or
the floor control server) always acts as the TLS server. If the TCP
connection is lost, the active endpoint, i.e., the current TLS
client, is responsible for re-establishing the TCP connection.
Unless a new TLS session is negotiated, subsequent SDP offers and
answers will not impact the previously negotiated TLS roles.
For a UDP/DTLS connection established using the an SDP offer/answer
exchange, either party can be the DTLS server depending on the setup
attributes exchanged; examples can be found in [23].
8. Protocol Transactions 8. Protocol Transactions
In BFCP, there are two types of transactions: client-initiated In BFCP, there are two types of transactions: client-initiated
transactions and server-initiated transactions. transactions and server-initiated transactions.
Client-initiated transactions consist of a request from a client to a Client-initiated transactions consist of a request from a client to a
floor control server and a response from the floor control server to floor control server and a response from the floor control server to
the client. The 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 46, line 16 skipping to change at page 45, line 34
requests. requests.
When using BFCP over an unreliable transport, it is important that When using BFCP over an unreliable transport, it is important that
the initiator of a transaction choose a Transaction ID value that the initiator of a transaction choose a Transaction ID value that
lets the receiver distinguish the reception of the next message in a lets the receiver distinguish the reception of the next message in a
sequence of BFCP messages from a retransmission of a previous sequence of BFCP messages from a retransmission of a previous
message. Therefore, BFCP entities using an unreliable transport MUST message. Therefore, BFCP entities using an unreliable transport MUST
use monotonically increasing Transaction ID values (except for wrap- use monotonically increasing Transaction ID values (except for wrap-
around). around).
When using BFCP over an unreliable transport, all requests will use When using BFCP over an unreliable transport, retransmission timer T1
retransmission timer T1 (see Section 8.3) until the transaction is (see Section 8.3) MUST be used for all requests until the transaction
completed. is completed.
8.1. Client Behavior 8.1. Client Behavior
A client starting a client-initiated transaction MUST set the A client starting a client-initiated transaction MUST set the
Conference ID in the common header of the message to the Conference Conference ID in the common header of the message to the Conference
ID for the conference that the client obtained previously. ID for the conference that the client obtained previously.
The client MUST set the Transaction ID value in the common header to The client MUST set the Transaction ID value in the common header to
a number that is different from 0 and that MUST NOT be reused in a number that is different from 0 and that MUST NOT be reused in
another message from the client until a response from the server is another message from the client until a response from the server is
skipping to change at page 46, line 44 skipping to change at page 46, line 16
A floor control server sending a response within a client-initiated A floor control server sending a response within a client-initiated
transaction MUST copy the Conference ID, the Transaction ID, and the transaction MUST copy the Conference ID, the Transaction ID, and the
User ID from the request received from the client into the response. User ID from the request received from the client into the response.
Server-initiated transactions MUST contain a Transaction ID equal to Server-initiated transactions MUST contain a Transaction ID equal to
0 when BFCP is used over a reliable transport. Over an unreliable 0 when BFCP is used over a reliable transport. Over an unreliable
transport, the Transaction ID shall have the same properties as for transport, the Transaction ID shall have the same properties as for
client-initiated transactions: the server MUST set the Transaction ID client-initiated transactions: the server MUST set the Transaction ID
value in the common header to a number that is different from 0 and value in the common header to a number that is different from 0 and
that MUST NOT be reused, i.e. monotonically increasing valuse as that MUST NOT be reused, i.e. monotonically increasing values as
defined in Section 8. The server uses the Transaction ID value to defined in Section 8. The server uses the Transaction ID value to
match this message with the response from the floor participant or match this message with the response from the floor participant or
floor chair. floor chair.
8.3. Timers 8.3. Timers
When BFCP entities are communicating over an unreliable transport, When BFCP entities are communicating over an unreliable transport,
two retransmission timers are employed to help mitigate against loss two retransmission timers are employed to help mitigate against loss
of datagrams. Retransmission and response caching are not required of datagrams. Retransmission and response caching are not required
when BFCP entities communicate over a reliable transport. when BFCP entities communicate over a reliable transport.
skipping to change at page 47, line 22 skipping to change at page 46, line 38
8.3.1. Request Retransmission Timer, T1 8.3.1. Request Retransmission Timer, T1
T1 is a timer that schedules retransmission of a request until an T1 is a timer that schedules retransmission of a request until an
appropriate response is received or until the maximum number of appropriate response is received or until the maximum number of
retransmissions have occurred. The timer doubles on each re- retransmissions have occurred. The timer doubles on each re-
transmit, failing after three unacknowledged retransmission attempts. transmit, failing after three unacknowledged retransmission attempts.
If a valid response is not received for a client- or server-initiated If a valid response is not received for a client- or server-initiated
transaction, the implementation MUST consider the BFCP connection as transaction, the implementation MUST consider the BFCP connection as
failed. Implementations SHOULD follow the reestablishment procedure failed. Implementations SHOULD follow the reestablishment procedure
described in section 6 (e.g., initiate a new offer/answer [12] described in section 6.
exchange).
8.3.2. Response Retransmission Timer, T2 8.3.2. Response Retransmission Timer, T2
T2 is a timer that, when fires, signals that the BFCP entity can T2 is a timer that, when fires, signals that the BFCP entity can
release knowledge of the transaction against which it is running. It release knowledge of the transaction against which it is running. It
is started upon the first transmission of the response to a request is started upon the first transmission of the response to a request
and is the only mechanism by which that response is released by the and is the only mechanism by which that response is released by the
BFCP entity. Any subsequent retransmissions of the same request can BFCP entity. Any subsequent retransmissions of the same request can
be responded to by replaying the cached response, whilst that value be responded to by replaying the cached response, whilst that value
is retained until the timer has fired. Refer to Section 6.2.3 for is retained until the timer has fired. Refer to Section 6.2.3 for
skipping to change at page 77, line 50 skipping to change at page 76, line 50
11. Examples over an unreliable transport (Appendix A): 11. Examples over an unreliable transport (Appendix A):
Added sample interactions over an unreliable transport for the Added sample interactions over an unreliable transport for the
scenarios in Figure 2 and Figure 3 scenarios in Figure 2 and Figure 3
12. Motivation for an unreliable transport (Appendix B): 12. Motivation for an unreliable transport (Appendix B):
Introduction to and motivation for extending BFCP to support an Introduction to and motivation for extending BFCP to support an
unreliable transport. unreliable transport.
16.2. Other changes 16.2. Other changes
The clarification and bug fixes: Clarifications and bug fixes:
1. ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>, 1. ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>,
Figure 28, Figure 30, and the ABNF figures in Section 5.3): Figure 28, Figure 30, and the ABNF figures in Section 5.3):
Although formally correct in [2], the notation has changed in a Although formally correct in [2], the notation has changed in a
number of Figures to an equivalent form for clarity, e.g., number of Figures to an equivalent form for clarity, e.g.,
s/*1(FLOOR-ID)/[FLOOR-ID]/ in Figure 38 and s/*[XXX]/*(XXX)/ in s/*1(FLOOR-ID)/[FLOOR-ID]/ in Figure 38 and s/*[XXX]/*(XXX)/ in
the other figures. the other figures.
2. Typo (Section 12.4.2): 2. Typo (Section 12.4.2):
Change from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the Change from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the
skipping to change at page 78, line 26 skipping to change at page 77, line 26
3. Corrected attribute type (Section 13.1.1): 3. Corrected attribute type (Section 13.1.1):
Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in
the eighth paragraph, since the note below describes priority and the eighth paragraph, since the note below describes priority and
that the last paragraph deals with PARTICIPANT-PROVIDED-INFO. that the last paragraph deals with PARTICIPANT-PROVIDED-INFO.
4. New error codes (Section 5.2.6): 4. New error codes (Section 5.2.6):
Added two additional error codes: "Incorrect Message Length" and Added two additional error codes: "Incorrect Message Length" and
"Generic Error". "Generic Error".
5. Assorted clarifications (Across the document): 5. Assorted clarifications (Across the document):
Non-functional language clarifications and some corrections in Language clarifications as a result of reviews. Also, the
the normative language as a result of reviews. normative language where tightened where appropriate, i.e.
changed from SHOULD strength to MUST in a number of places.
17. Acknowledgements 17. Acknowledgements
The XCON WG chairs, Adam Roach and Alan Johnston, provided useful The XCON WG chairs, Adam Roach and Alan Johnston, provided useful
ideas for RFC 4582 [2]. Additionally, Xiaotao Wu, Paul Kyzivat, ideas for RFC 4582 [2]. Additionally, Xiaotao Wu, Paul Kyzivat,
Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben
Campbell, Dave Morgan, and Oscar Novo provided useful comments during Campbell, Dave Morgan, and Oscar Novo provided useful comments during
the work with RFC 4582. The authors also acknowledge contributions the work with RFC 4582. The authors also acknowledge contributions
to the revision of BFCP for use over an unreliable transport from to the revision of BFCP for use over an unreliable transport from
Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad, Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad,
skipping to change at page 79, line 32 skipping to change at page 78, line 32
Protocol Version 1.2", RFC 5246, August 2008. Protocol Version 1.2", RFC 5246, August 2008.
[7] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [7] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
[9] Camarillo, G. and T. Kristensen, "Session Description Protocol [9] Camarillo, G. and T. Kristensen, "Session Description Protocol
(SDP) Format for Binary Floor Control Protocol (BFCP) Streams", (SDP) Format for Binary Floor Control Protocol (BFCP) Streams",
draft-ietf-bfcpbis-rfc4583bis-09 (work in progress), draft-ietf-bfcpbis-rfc4583bis-10 (work in progress),
February 2014. October 2014.
[10] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [10] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007. BCP 131, RFC 4961, July 2007.
[11] 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.
18.2. Informational References 18.2. Informational References
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
skipping to change at page 89, line 30 skipping to change at page 88, line 30
Keith Drage Keith Drage
Alcatel-Lucent Alcatel-Lucent
Quadrant, StoneHill Green, Westlea Quadrant, StoneHill Green, Westlea
Swindon, Wilts Swindon, Wilts
UK UK
Email: drage@alcatel-lucent.com Email: drage@alcatel-lucent.com
Tom Kristensen Tom Kristensen
Cisco Cisco
Philip Pedersens vei 22 Philip Pedersens vei 1
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 Joerg Ott
Aalto University Aalto University
Otakaari 5 A Otakaari 5 A
Espoo, FIN 02150 Espoo, FIN 02150
Finland Finland
 End of changes. 36 change blocks. 
124 lines changed or deleted 93 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/