| TOC |
|
This memo extends the Binary Floor Control Protocol (BFCP) for use over an unreliable transport. It details a set of revisions to the protocol definition document and the specification of Session Description Protocol (SDP) format for BFCP streams.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on March 6, 2011.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1.
Introduction
2.
Terminology
3.
Rationale and Scope
4.
Revision of RFC4582
4.1.
Overview of Operation (4)
4.2.
Floor Participant to Floor Control Server Interface (4.1)
4.3.
COMMON-HEADER Format (5.1)
4.4.
ERROR-CODE (5.2.6)
4.5.
FloorRequestStatusAck (5.3.14)
4.6.
ErrorAck (5.3.15)
4.7.
FloorStatusAck (5.3.16)
4.8.
Goodbye (5.3.17)
4.9.
GoodbyeAck (5.3.18)
4.10.
Transport (6)
4.11.
Reliable Transport (6.1)
4.12.
Unreliable Transport (6.2)
4.13.
Lower-Layer Security (7)
4.14.
Protocol Transactions (8)
4.15.
Server Behavior (8.2)
4.16.
Timers (8.3)
4.17.
Request Retransmission Timer, T1 (8.3.1)
4.18.
Response Retransmission Timer, T2 (8.3.2)
4.19.
Timer Values (8.3.3)
4.20.
Receiving a Response [to a FloorRequest Message] (10.1.2)
4.21.
Receiving a Response [to a FloorRelease Message] (10.2.2)
4.22.
Receiving a Response [to a ChairAction Message] (11.2)
4.23.
Receiving a Response [to a FloorQuery Message] (12.1.2)
4.24.
Receiving a Response [to a FloorRequestQuery Message] (12.2.2)
4.25.
Receiving a Response [to a UserQuery Message] (12.3.2)
4.26.
Receiving a Response [to a Hello Message] (12.4.2)
4.27.
Reception of a FloorRequestStatus Message (13.1.3)
4.28.
Reception of a FloorStatus Message (13.5.3)
4.29.
Reception of an Error Message (13.8.1)
4.30.
Security Considerations (14)
4.31.
IANA Considerations - Primitive Subregistry (15.2)
4.32.
IANA Considerations - Error Code Subregistry (15.4)
4.33.
Example Call Flows for BFCP over Unreliable Transport (Appendix A)
5.
Revision of RFC4583
5.1.
Fields in the 'm' Line (3)
5.2.
Security Considerations (10)
5.3.
Registration of SDP 'proto' Values (11.1)
6.
Future Work
7.
Acknowledgements
8.
References
8.1.
Normative References
8.2.
Informative References
Appendix A.
Change History
A.1.
draft-sandbakken-xcon-bfcp-udp-02 to draft-sandbakken-dispatch-bfcp-udp-00
A.2.
draft-sandbakken-xcon-bfcp-udp-01 to -02
A.3.
draft-sandbakken-xcon-bfcp-udp-00 to -01
§
Authors' Addresses
| TOC |
The motivation for using an unreliable transports for BFCP [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.) messages is fuelled by network deployments where middleboxes or media relays are present for NAT and firewall traversal. In these deployments, TCP may neither be applicable nor appropriate, for example, due to lack of support for TCP media relay, ICE-TCP [I‑D.ietf‑mmusic‑ice‑tcp] (Perreault, S. and J. Rosenberg, “TCP Candidates with Interactive Connectivity Establishment (ICE),” October 2009.) or a standard UDP tunneling approach. In Section 3 (Rationale and Scope) the rationale for and scoping of the approach chosen in this draft is described.
This memo extends 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.
The intention is not to change the semantics of BFCP, but to present a trivial and workable extension that permits UDP as a transport. Existing implementations in the spirit of the approach detailed in earlier versions of this draft (cf. Appendix A (Change History)), have demonstrated the approach to be feasible. The purpose of this document is to formalize the deviations from the baseline specification enabling interoperability between implementations.
The content of this draft relates to the BFCP protocol specification [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.) and the SDP format for describing BFCP streams [RFC4583] (Camarillo, G., “Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams,” November 2006.). This memo is written with the goal of being incorporated into an upcoming revision of those documents without requiring additional protocol and stream specification documents. These two future bis drafts will also deal with known issues not related to the extensions described in this draft.
Earlier versions of this draft was submitted to the XCON working group. As XCON is closing the draft is now moved and associated with the Dispatch working group. The draft is in progress and notable remaining work is detailed in Section 6 (Future Work).
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
BFCP over TCP according to [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.) is used by a number of vendors and works well in some environments. In scenarios where the floor control server has a public IP address, the client will have no problem establishing the TCP connection towards the server.
On the other hand, in existing, deployed video-conferencing scenarios the floor control server will be placed behind a NAT, as the floor control server functionality is implemented in one of the communicating endpoints. Roles are negotiated in the offer/answer exchange, as specified in [RFC4583] (Camarillo, G., “Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams,” November 2006.), and either endpoint may end up being the floor control server. The session between these endpoints typically consists of a number of RTP media streams for audio and video and the BFCP connection. NAT traversal will be a problem for BFCP over TCP. The RTP streams works fine as ICE is used to provide connectivity. This draft defines UDP as an alternative transport for BFCP, this enables usage of ICE in the same fashion as for the RTP streams and utilizing the same infrastructure.
The progress and maybe real interest in finishing the specification of ICE-TCP has been low, the ICE-TCP draft [I‑D.ietf‑mmusic‑ice‑tcp] (Perreault, S. and J. Rosenberg, “TCP Candidates with Interactive Connectivity Establishment (ICE),” October 2009.) is currently expired. As a new editor of the draft presented his roadmap at IETF-78, this will hopefully change. However, the most important reason for not embracing ICE-TCP and throwing away this draft is the low success rate.
Another option would be to keep the current BFCP specification as is and tunnel it over UDP. No generic, general purpose UDP tunneling protocol is specified within the IETF. Several approaches exist as personal internet drafts, comprising UDT [I‑D.gg‑udt] (Gu, Y., “UDT: UDP-based Data Transfer Protocol,” April 2010.) which has been around for some years, the expired TCP-over-UDP (ToU) [I‑D.baset‑tsvwg‑tcp‑over‑udp] (Baset, S. and H. Schulzrinne, “TCP-over-UDP,” June 2009.) draft and GUT [I‑D.manner‑tsvwg‑gut] (Manner, J., Varis, N., and B. Briscoe, “Generic UDP Tunnelling (GUT),” July 2010.) that recently was chosen for the DCCP and SCTP encapsulation work.
The authors of this draft acknowledge the arguments in favor of a general solution to support NAT and firewall traversal of existing TCP-based protocols. This is also in line with the recommendations in [RFC5405] (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.). Currently, the quite simple and straight forward extensions for BFCP over UDP specified in this draft is believed to represent the best way forward in order to support existing products and deployments in a timely manner. The progress with regard to specifying a general purpose UDP tunneling protocol and the outcome of the re-started work on the ICE-TCP specification will be monitored and evaluated as results are available.
| TOC |
This section details revisions to [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.), the base protocol specification of BFCP. The section number to which updates apply are indicated in parentheses in the titles of the sub-sections below.
| TOC |
Fourth paragraph change:
There are two types of transaction in BFCP: client-initiated transactions and server-initiated transactions. Client-initiated transactions consist of a message from a client to the floor control server and a response from the floor control server to the client. Correspondingly, server-initiated transactions consist of a message from the floor control server to a client and the associated acknowledgement message from the client to the floor control server. Both messages can be related because they carry the same Transaction ID value in their common headers.
| TOC |
Before seventh paragraph (page 9), insert:
Figures 2 and 3 below show call flows for two sample BFCP interactions when used over reliable transport. Appendix A (Editorial Note: here-in Section 4.33 (Example Call Flows for BFCP over Unreliable Transport (Appendix A))) shows the same sample interactions but over an unreliable transport.
| TOC |
The figure below should replace Figure 5: COMMON-HEADER format.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |I| Res | Primitive | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Conference ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 1: COMMON-HEADER format |
The following text preceeds "Reserved" on page 15:
I: The Transaction Initiator (I) flag-bit has relevance only for use of BFCP over unreliable media. When clear, it signifies that the transaction was opened by the client (floor participant, chair) and that the Transaction ID that follows has been generated by the client; when set, the transaction is a server-initiated transaction and the Transaction ID that follows is pertinent to the floor control server. Where BFCP is used over reliable transports, the flag has no significance and SHOULD be cleared.
The Reserved field changes name to Res due to limited space in the ASCII graphic in Figure 1 (COMMON-HEADER format). In the description of the Reserved field "the 5 bits" is changed to "the 4 bits".
The description of Transaction ID should have the final clause deleted with the reference to Section 8 remaining. The value used for server-initiated transactions shall be non-zero when BFCP is used over unreliable transports, and this qualification shall be described in the updated Section 8.
The values below should be appended to the end of Table 1: BFCP primitives.
| Value | Primitive | Direction |
|---|---|---|
| 14 | FloorRequestStatusAck | P -> S ; Ch -> S |
| 15 | ErrorAck | P -> S ; Ch -> S |
| 16 | FloorStatusAck | P -> S ; Ch -> S |
| 17 | Goodbye | P -> S ; Ch -> S ; |
| S -> P ; S -> Ch | ||
| 18 | GoodbyeAck | P -> S ; Ch -> S ; |
| S -> P ; S -> Ch |
| Table 1: BFCP primitives |
| TOC |
The value below should be appended to the end of Table 5: Error Code meaning.
| Value | Meaning |
|---|---|
| 10 | Unable to parse message |
| Table 2: Error Code meaning |
| TOC |
This new subsection should be added to specify the normative ABNF for the new primitive, FloorRequestStatusAck.
Floor participants and chairs acknowledge the receipt of a FloorRequestStatus message from the floor control server when communicating over unreliable transport. The following is the format of the FloorRequestStatusAck message:
FloorRequestStatusAck = (COMMON-HEADER) *[EXTENSION-ATTRIBUTE]
Figure 2: FloorRequestStatusAck format
| TOC |
This new subsection should be added to specify the normative ABNF for the new primitive, ErrorAck.
Floor participants and chairs acknowledge the receipt of an Error message from the floor control server when communicating over unreliable transport. The following is the format of the ErrorAck message:
ErrorAck = (COMMON-HEADER) *[EXTENSION-ATTRIBUTE]
Figure 3: ErrorAck format
| TOC |
This new subsection should be added to specify the normative ABNF for the new primitive, FloorStatusAck.
Floor participants and chairs acknowledge the receipt of a FloorStatus message from the floor control server when communicating over unreliable transport. The following is the format of the FloorStatusAck message:
FloorStatusAck = (COMMON-HEADER) *[EXTENSION-ATTRIBUTE]
Figure 4: FloorStatusAck format
| TOC |
This new subsection should be added to specify the normative ABNF for the new primitive, Goodbye.
BFCP entities that wish to dissociate themselves from their remote participant do so through the transmission of a Goodbye. The following is the format of the Goodbye message:
Goodbye = (COMMON-HEADER) *[EXTENSION-ATTRIBUTE]
Figure 5: Goodbye format
| TOC |
This new subsection should be added to specify the normative ABNF for the new primitive, GoodbyeAck.
BFCP entities communicating over an unreliable transport should acknowledge the receipt of a Goodbye message from a peer. The following is the format of the GoodbyeAck message:
GoodbyeAck = (COMMON-HEADER) *[EXTENSION-ATTRIBUTE]
Figure 6: GoodbyeAck format
| TOC |
Much of the existing text remains but demoted to become subsection 6.1. This draft recommends an additional behavior for entities participating in communication over a reliable transport that either wish to leave or are asked to leave an established BFCP connection, as detailed in the revised section introduction text below.
The transport over which BFCP entities exchange messages depends on how clients obtain information to contact the floor control server (e.g. using an SDP offer/answer exchange [RFC4583] (Camarillo, G., “Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams,” November 2006.)). Two transports are supported: TCP, appropriate where entities can be sure that their connectivity is not impeded by NAT devices, media relays or firewalls; and UDP for those deployments where TCP may not be 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.
| TOC |
BFCP entities may elect to exchange BFCP messages using TCP connections. TCP provides an in-order reliable delivery of a stream of bytes. Consequently, message framing is implemented in the application layer. BFCP implements application-layer framing using TLV-encoded attributes.
A client MUST NOT use more than one TCP connection to communicate with a given floor control server within a conference. Nevertheless, if the same physical box handles different clients (e.g. a floor chair and a floor participant), which are identified by different User IDs, a separate connection per client is allowed.
If a BFCP entity (a client or a floor control server) receives data that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished. Similarly, if a TCP connection cannot deliver a BFCP message and times out, the TCP connection SHOULD be reestablished.
The way connection reestablishment is handled depends on how the client obtains information to contact the floor control server. Once the TCP connection is reestablished, the client MAY resend those messages for which it did not get a response from the floor control server.
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 the floor control server what to do with the pending floor requests 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 cancel them) while the TCP connection is reestablished.
To maintain backwards compatibility with older implementations of [RFC4583] (Camarillo, G., “Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams,” November 2006.), BFCP entities MUST interpret the graceful close of their TCP connection from their associated participant as an implicit Goodbye message.
| TOC |
BFCP entities may elect to exchange BFCP messages using UDP datagrams. UDP is an unreliable transport where neither delivery nor delivery order is assured. Each BFCP UDP datagram MUST contain only one BFCP message. The message format for exchange of BFCP in UDP datagrams is the same as for a TCP stream above.
Clients MUST announce their presence to the floor control server by transmission of a Hello message. This Hello message MUST be responded to with a HelloAck message and only upon receipt can the client consider the floor control service as present and available.
As described in Section 8, each request sent by a floor participant or chair shall form a client transaction that expects an acknowledgement message back from the floor control server within a retransmission window. Concordantly, messages sent by the floor control server that are not transaction-completing (e.g. FloorStatus announcements as part of a FloorQuery subscription) are server-initiated transactions that require acknowledgement messages from the floor participant and chair entities to which they were sent.
If a BFCP entity receives data that cannot be parsed, the receiving participant MAY send an Error message with parameter value 10 indicating receipt of a malformed message. If the message can be parsed to the extent that it is able to discern that it was a response to an outstanding request transaction, the client MAY discard the message and await retransmission. BFCP entities receiving an Error message with value 10 SHOULD acknowledge the error and act accordingly.
Transaction ID values are non-sequential and entities are at liberty to select values at random. Entities MUST only have at most one outstanding request transaction at any one time. Implicit subscriptions, such as FloorRequest messages that have multiple responses as the floor control server processes intermediate states until Granted or Denied terminal states attained, can be characterized by a client-initiated request transaction whose acknowledgement is implied by the first FloorRequestStatus response from the floor control server. The subsequent changes in state for the request are new transactions whose Transaction ID is determined by the floor control server and whose receipt by the client participant shall be acknowledged with a FloorRequestStatusAck message.
By restricting entities to having at most one pending transaction open, the out-of-order receipt of messages is mitigated. A server-initiated request (e.g. a FloorStatus with an update from the floor control server) received by a participant before the initial FloorRequestStatus message that closes the client-initiated transaction that was instigated by the FloorRequest clearly supercedes the information conveyed in the delinquent response. As the floor control server cannot send a second update to the implicit floor status subscription until the first is acknowledged, ordinality is maintained.
BFCP may be characterized to generate "low data-volume" traffic, after the classification in [RFC5405] (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.). Nevertheless is it necessary to ensure suitable and necessary congestion control mechanisms are used for BFCP over UDP. As described in previous paragraph every entity - 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 sent per RTT given the message is not lost during transmission. In case the message is lost, the request retransmission timer T1 specified in Section 4.17 (Request Retransmission Timer, T1 (8.3.1)) will fire and the message is retransmitted up to three times. The default initial interval is set to 500ms and the interval is doubled after each retransmission attempt, this is identical to the specification of the T1 timer in SIP as described in Section 17.1.1.2 of [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
BFCP entities SHOULD ensure that their messages are smaller than the recommended MTU size of 1300 bytes when encoded to minimise likelihood of fragmentation en route to their peer entity.
If a BFCP entity receives an ICMP port unreachable message mid-conversation, the entity SHOULD treat the conversation as closed (e.g. an implicit Goodbye message from the peer) and behave accordingly. The entity MAY attempt to re-establish the conversation afresh. The new connection will appear as a wholly new floor participant, chair or floor control server with all state previously held about that participant lost.
Note: This is because the peer entities cannot rely on IP and port tuple to uniquely identify the participant, nor would extending Hello to include an attribute that advertised what the entity previously was assigned as a User ID be acceptable due to session hijacking.
In deployments where NAT appliances, firewalls or other such devices are present and affecting port reachability for each entity, peer connectivity checks, relay use and NAT pinhole maintenance SHALL be achieved through the mechanisms defined in ICE [RFC5245] (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” April 2010.).
| TOC |
Add the following to the second sentence, change period ('.') with comma:
, if transport over UDP is implemented, DTLS [RFC4347] (Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security,” April 2006.) MUST be supported.
Editorial Note: More details needed. The DTLS details to be added are modelled after their counterpart for RTP streams specified in [RFC5763] (Fischl, J., Tschofenig, H., and E. Rescorla, “Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS),” May 2010.). The normative text needed are either referenced or copied across to this draft.
| TOC |
The final clause of the introduction to section 8 shall be changed to read:
Since they do not trigger any response, their Transaction ID is set to 0 when used over reliable transports, but must be non-zero and unique in the context of outstanding transactions over unreliable transports.
When using BFCP over unreliable transports, all requests will use retransmit timer T1 (see Section 4.16 (Timers (8.3))) until the transaction is completed.
| TOC |
The final clause of this section shall be changed to read:
Server-initiated transactions MUST contain a Transaction ID equal to 0 when BFCP is used over reliable transports. Over unreliable transport, the Transaction ID shall have the same properties as for client-initiated transactions: the server 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 another message from the server until the appropriate response from the client is received for the transaction. The server uses the Transaction ID value to match this message with the response from the floor participant or floor chair.
| TOC |
New section:
When BFCP entities are communicating over an unreliable transport, two retransmission timers are employed to help mitigate against loss of datagrams. Retransmission and response caching are not required when BFCP entities communicate over reliable transports.
| TOC |
T1 is a timer that schedules retransmission of a request until an appropriate response is received or until the maximum number of retransmissions have occurred. The timer doubles on each re-transmit, failing after three unacknowledged transmission attempts.
If a valid respone is not received for a client- or server-initiated transaction, the implementation MUST consider the BFCP association as failed. Implementations SHOULD follow the reestablishment procedure described in section 6 (e.g. initiate a new offer/answer [RFC3264] (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) exchange). Alternatively, they MAY continue without BFCP and therefore not be participant in any floor control actions.
| TOC |
T2 is a timer that, when fires, signals that the BFCP entity can release knowledge of the transaction against which it is running. It 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 BFCP entity. Any subsequent retransmissions of the same request can be responded to by replaying the cached response, whilst that value is retained until the timer has fired.
T2 shall be set such that it encompasses all legal retransmissions per T1 plus a factor to accommodate network latency between BFCP entities.
| TOC |
The table below defines the different timers required when BFCP entities communicate over an unreliable transport.
| Timer | Description | Value/s |
|---|---|---|
| T1 | Initial request retransmission timer | 0.5s |
| T2 | Response retransmission timer | 10s |
| Table 3: Timers |
The default value for T1 is 500 ms, this is an estimate of the RTT for completing the transaction. T1 MAY be chosen larget, and this is RECOMMENDED if it is known in advance that the RTT is larget. Regardless of the value of T1, the exponential backoffs on retransmissions described in Section 4.17 (Request Retransmission Timer, T1 (8.3.1)) MUST be used.
| TOC |
Prepend the sentence below at the start of this subsection:
When communicating over unreliable transport and upon receiving a FloorRequest from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction.
| TOC |
Prepend the sentence below at the start of this subsection:
When communicating over unreliable transport and upon receiving a FloorRelease from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction.
| TOC |
Prepend the sentence below at the start of this subsection:
When communicating over unreliable transport and upon receiving a ChairAction from a participant, the floor control server MUST respond with a ChairActionAck message within the transaction failure window to complete the transaction.
| TOC |
Prepend the sentence below at the start of this subsection:
When communicating over unreliable transport and upon receiving a FloorQuery from a participant, the floor control server MUST respond with a FloorStatus message within the transaction failure window to complete the transaction.
| TOC |
Prepend the sentence below at the start of this subsection:
When communicating over unreliable transport and upon receiving a FloorRequestQuery from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction.
| TOC |
Prepend the sentence below at the start of this subsection:
When communicating over unreliable transport and upon receiving a UserQuery from a participant, the floor control server MUST respond with a UserStatus message within the transaction failure window to complete the transaction.
| TOC |
Prepend the sentence below at the start of this subsection:
When communicating over unreliable transport and upon receiving a Hello from a participant, the floor control server MUST respond with a HelloAck message within the transaction failure window to complete the transaction.
| TOC |
The sentence below shall appear as a new subsection:
When communicating over unreliable transport and upon receiving a FloorRequestStatus message from a floor control server, the participant MUST respond with a FloorRequestStatusAck message within the transaction failure window to complete the transaction.
| TOC |
The sentence below shall appear as a new subsection:
When communicating over unreliable transport and upon receiving a FloorStatus message from a floor control server, the participant MUST respond with a FloorStatusAck message within the transaction failure window to complete the transaction.
| TOC |
The sentence below shall appear as a new subsection:
When communicating over unreliable transport and upon receiving an Error message from a floor control server, the participant MUST respond with a ErrorAck message within the transaction failure window to complete the transaction.
| TOC |
It is a requirement that the extension of BFCP for unreliable transports shall not introduce any new threats.
The considerations in [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.) will be altered to cover TCP/TLS connections as well as DTLS (UDP/TLS).
In addition to the RFCs mentioned for TCP and TLS connections, the specifications for SRTP over DTLS [RFC5763] (Fischl, J., Tschofenig, H., and E. Rescorla, “Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS),” May 2010.) and [RFC5764] (McGrew, D. and E. Rescorla, “Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP),” May 2010.) discuss security issues in detail. Add references to them in the section.
Editorial Note: Expanded analysis and discussion will be added after lower-layer security details is sorted out in Section 4.13 (Lower-Layer Security (7)).
| TOC |
This section instructs the IANA to register the following new values for the BFCP primitive subregistry.
| Value | Primitive | Reference |
|---|---|---|
| 14 | FloorRequestStatusAck | RFC[XXXX] |
| 15 | ErrorAck | RFC[XXXX] |
| 16 | FloorStatusAck | RFC[XXXX] |
| 17 | Goodbye | RFC[XXXX] |
| 18 | GoodbyeAck | RFC[XXXX] |
| Table 4: BFCP primitive subregistry |
| TOC |
This section instructs the IANA to register the following new values for the BFCP Error Code subregistry.
| Value | Meaning | Reference |
|---|---|---|
| 10 | Unable to parse message | RFC[XXXX] |
| Table 5: BFCP Error Code subregistry |
| TOC |
(Editorial Note: This is a new appendix to [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.).)
With reference to Section 4.1, the following figures show representative call-flows for requesting and releasing a floor, and obtaining status information about a floor when BFCP is deployed over an unreliable transport. The figures here show a loss-less interaction.
Editorial Note: A future version of this draft will show an example with lost packets due to unreliable transport, as well as examples on usage of DTLS and STUN in call the setup phase.
Floor Participant Floor Control
Server
|(1) FloorRequest |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorRequestStatus |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Pending |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(3) FloorRequestStatus |
|Transaction ID: 4098 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(4) FloorRequestStatusAck |
|Transaction ID: 4098 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(5) FloorRequestStatus |
|Transaction ID: 4130 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(6) FloorRequestStatusAck |
|Transaction ID: 4130 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(7) FloorRelease |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->|
| |
|(8) FloorRequestStatus |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Released |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| Figure 7: Requesting and releasing a floor |
Note that in Figure 7 (Requesting and releasing a floor), the FloorRequestStatus message from the floor control server to the floor participant is a transaction-closing message as a response to the client-initiated transaction with Transaction ID 154. It does not and SHOULD NOT be followed by a FloorRequestStatusAck message from the floor participant to the floor control server.
Floor Participant Floor Control
Server
|(1) FloorQuery |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorStatus |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 2nd |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(3) FloorStatus |
|Transaction ID: 4319 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(4) FloorStatusAck |
|Transaction ID: 4319 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(5) FloorStatus |
|Transaction ID: 4392 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(6) FloorStatusAck |
|Transaction ID: 4392 |
|User ID: 234 |
|---------------------------------------------->|
| Figure 8: Obtaining status information about a floor |
| TOC |
This section details revisions to [RFC4583] (Camarillo, G., “Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams,” November 2006.), the SDP format for specifying BFCP streams. The section number to which updates apply are indicated in parentheses in the titles of the sub-sections below.
| TOC |
The section shall be re-written to remove reference to the exclusivity of TCP as a transport for BFCP streams.
| TOC |
In addition to the RFCs mentioned for TCP and TLS connections, the specifications for SRTP over DTLS [RFC5763] (Fischl, J., Tschofenig, H., and E. Rescorla, “Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS),” May 2010.) and [RFC5764] (McGrew, D. and E. Rescorla, “Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP),” May 2010.) discuss security issues in detail. Add references to them in the section.
Editorial Note: Expanded analysis and discussion will be added after lower-layer security details is sorted out in Section 4.13 (Lower-Layer Security (7)).
| TOC |
This section should be renamed now that there are more values to register in the SDP parameters registry, with the following added to the table:
| Value | Reference |
|---|---|
| UDP/BFCP | RFC[XXXX] |
| UDP/TLS/BFCP | RFC[XXXX] |
| Table 6: Value for the SDP 'proto' field |
| TOC |
This draft reflects a work in progress, with at least the following items to be documented and/or revised before soliciting adoption by the XCON working group:
- Adapting DTLS usage to BFCP:
- Currently the DTLS-SRTP specifications [RFC5763] (Fischl, J., Tschofenig, H., and E. Rescorla, “Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS),” May 2010.) and [RFC5764] (McGrew, D. and E. Rescorla, “Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP),” May 2010.) are referenced and used as basis for intended BFCP usage of DTLS. Adaption to the BFCP context in Section 4.13 (Lower-Layer Security (7)) will either be done by reference and noting differences or by adding the normative specification needed to this draft. This consideration applies to the two security consideration sections as well, namely Section 4.30 (Security Considerations (14)) and Section 5.2 (Security Considerations (10)). Adding examples on DTLS usage in the call setup phase will provide guidance to implementors.
- Protocol revision:
- Certain aspects of this draft require different behaviors depending on whether a reliable or unreliable transport is being used, e.g. server-initiated transactions having Transaction ID 0 over reliable transports without acknowledgements versus non-zero and active-unique with an acknowledgement message when entities communicate over unreliable transports. If we allow TCP-based implementations to follow the graceful-close behavior of [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.) without mandating that the Goodbye message be signaled then it would not be necessary to bump the protocol version number. TCP-based implementations could continue as-is, whilst UDP-based implementations would be at their first version and as such no backward compatible issues would be present.
- Fragmentation:
- It has been observed that BFCP message structures can grow to be sufficiently large that they exceed the typical MTU threshold for local area networks (assumed here as 1500 octets). For example, a FloorStatus message with multiple FLOOR-REQUEST-INFORMATION attributes that contain detailed STATUS-INFO in the OVERALL-REQUEST-STATUS and FLOOR-REQUEST-STATUS attributes. A strategy for coping with such fragmented messages is required. Currently, this is held with a broad-sweeping statement of intent that implementations should restrict the size of their messages. Further refinement might be required, such as an applicability statement on those BFCP messages and/or attributes deemed as inappropriate for use over transports where fragmentation is a concern, or further protocol specification to eradicate fragmentation as an issue. A mechanism for splitting into additive messages might be considered.
- Example signaling flows:
- The next revision of this draft will include further example signaling exchanges over unreliable transport as a visual aid and reference for implementors. Including updated transactions, message retransmission, usage of DTLS during call setup and combined usage of DTLS and STUN.
| TOC |
The team working on this draft are: Trond G. Andersen, Charles Eckel, Tom Kristensen, Eoin McLeod, Geir A. Sandbakken and Mark K. Thompson at Cisco; Alfred E. Heggestad at Telio Telecom.
| TOC |
| TOC |
| TOC |
| [I-D.baset-tsvwg-tcp-over-udp] | Baset, S. and H. Schulzrinne, “TCP-over-UDP,” draft-baset-tsvwg-tcp-over-udp-01 (work in progress), June 2009 (TXT). |
| [I-D.gg-udt] | Gu, Y., “UDT: UDP-based Data Transfer Protocol,” draft-gg-udt-03 (work in progress), April 2010 (TXT). |
| [I-D.ietf-mmusic-ice-tcp] | Perreault, S. and J. Rosenberg, “TCP Candidates with Interactive Connectivity Establishment (ICE),” draft-ietf-mmusic-ice-tcp-08 (work in progress), October 2009 (TXT). |
| [I-D.manner-tsvwg-gut] | Manner, J., Varis, N., and B. Briscoe, “Generic UDP Tunnelling (GUT),” draft-manner-tsvwg-gut-02 (work in progress), July 2010 (TXT). |
| [RFC3261] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002 (TXT). |
| [RFC5405] | Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” BCP 145, RFC 5405, November 2008 (TXT). |
| [RFC5764] | McGrew, D. and E. Rescorla, “Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP),” RFC 5764, May 2010 (TXT). |
| TOC |
| TOC |
| TOC |
| TOC |
| TOC |
| Mark K. Thompson | |
| Cisco | |
| Ruscombe Business Park | |
| Ruscombe, England | |
| UK | |
| Email: | markth2@cisco.com |
| Tom Kristensen | |
| Cisco | |
| Philip Pedersens vei 22 | |
| N-1366 Lysaker | |
| Norway | |
| Email: | tomkrist@cisco.com, tomkri@ifi.uio.no |
| Geir A. Sandbakken | |
| Cisco | |
| Philip Pedersens vei 22 | |
| N-1366 Lysaker | |
| Norway | |
| Email: | geirsand@cisco.com |
| Trond G. Andersen | |
| Cisco | |
| Philip Pedersens vei 22 | |
| N-1366 Lysaker | |
| Norway | |
| Email: | trondand@cisco.com |
| Eoin McLeod | |
| Cisco | |
| Ruscombe Business Park | |
| Ruscombe, England | |
| UK | |
| Email: | eoimcleo@cisco.com |