Network Working Group G. Sandbakken, Ed.
Internet-Draft T. Andersen
Intended status: Standards Track TANDBERG
Expires: April 12, 2008 A. Heggestad
Telio Telecom
October 10, 2007
Binary Floor Control Protocol over UDP
draft-sandbakken-xcon-bfcp-udp-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 12, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This memo extends the Binary Floor Control Protocol enabling it to
use UDP as a transport. In order to use an unreliable transport
mechanism this draft utilizes the existing transaction model in BFCP
to achieve reliability. Each request now has an appropriate response
to complete the transaction. It also defines a keep alive behavior
needed to keep NAT bindings open.
Sandbakken, et al. Expires April 12, 2008 [Page 1]
Internet-Draft BFCP over UDP October 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . . 3
3. Floor participant to Floor Control Server interface . . . . . . 3
3.1. Floor participant initiated transactions . . . . . . . . . 3
3.2. Floor request to response message mapping . . . . . . . . . 3
3.3. User request to response message mapping . . . . . . . . . 3
3.4. Hello . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.5. Server to participant initiated transactions . . . . . . . 4
3.6. Server floor request to response message mapping . . . . . 4
3.7. Error message to response mapping . . . . . . . . . . . . . 4
3.8. FloorStatus message to response mapping . . . . . . . . . . 4
4. Floor Chair to Floor Control Server Interface . . . . . . . . . 4
4.1. Chair initiated transactions . . . . . . . . . . . . . . . 4
4.2. ChairAction . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Sending over UDP and Keep alive . . . . . . . . . . . . . . . . 5
6. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Transaction failure . . . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Registration of the UDP/BFCP as SDP proto value . . . . . . 5
8.2. Registrations of new BFCP sub registry parameters . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Sandbakken, et al. Expires April 12, 2008 [Page 2]
Internet-Draft BFCP over UDP October 2007
1. Introduction
The motivation for using UDP as a transport for BFCP [RFC4582]
messages is to utilize already deployed proxies. These proxies are
often used to relay UDP packets having RTP or RTCP content enabling
receivers behind NAT or firewall to receive incoming data. This memo
extends the BFCP protocol to support unreliable transport, and has
some minor changes to the transaction model to achieve this. All
requests now have an appropriate response to complete the
transaction. The requests are sent having a retransmit timer mapped
to the response to achieve reliability. It also defines an opening
of pin-hole and keep-alive behavior needed to keep NAT bindings open.
2. Fields in the 'm' Line
This section extends the transport field in a 'm' line for a BFCP
stream. The new value for the transport field is UDP/BFCP
Example of an 'm' line for a BFCP connection:
m = application 50000 UDP/BFCP *
3. Floor participant to Floor Control Server interface
3.1. Floor participant initiated transactions
The client must initiate the Transaction ID to a number different
from 0, and must increment for each new transaction. All requests
will use retransmit timer T1 until the transaction is completed.
3.2. Floor request to response message mapping
Upon recieving the messages FloorRequest, FloorRelease,
FloorRequestQuery and FloorQuery from the participant, the Floor
Control Server must respond with a FloorStatus message as soon as
possible to complete the transaction.
3.3. User request to response message mapping
Upon recieving the UserQuery message from the participant, the Floor
Control Sever must respond with a UserStatus message as soon as
possible to complete the transaction.
Sandbakken, et al. Expires April 12, 2008 [Page 3]
Internet-Draft BFCP over UDP October 2007
3.4. Hello
Upon recieving the Hello message from the participant, the Floor
Control Server must respond with a HelloAck message as soon as
possible to complete the transaction.
3.5. Server to participant initiated transactions
The server MUST initiate the Transaction ID to a number different
from 0, and MUST incrementet the value by 1 for each new transaction.
This mode of operation has different Transaction ID handling than
described in RFC 4582. All requests will use retransmit timer T1
until the transaction is completed.
3.6. Server floor request to response message mapping
If the participant receive the FloorRequestStatus message it must
respond with a FloorRequestStatusAck message to complete the
transaction as soon as possible.
3.7. Error message to response mapping
If the participant receives the Error Message, it must respond with a
ErrorAck message as soon as possible to complete the transaction.
3.8. FloorStatus message to response mapping
If the participant receives the FloorStatus Message, it must respond
with a FloorStatusAck message as soon as possible to complete the
transaction.
4. Floor Chair to Floor Control Server Interface
4.1. Chair initiated transactions
The client initiated Transaction ID may start at an arbitrary value,
and must be incremented for each new transaction. The request will
use retransmit timer T1 until the transaction is complete.
4.2. ChairAction
Upon receiving the ChairAction request, the server must respond with
a ChairActionAck as soon as possible to complete the transaction.
Sandbakken, et al. Expires April 12, 2008 [Page 4]
Internet-Draft BFCP over UDP October 2007
5. Sending over UDP and Keep alive
The server and the client should retransmit the initial Hello with an
interval of 500 ms, doubling after each retransmission. After
HelloAck has been received by both server and client, the client must
conitune to send Hello every 30 seconds for keep alive. The server
may not send any Hello message after the initial exchange.
6. Timers
Timer T1 is used retransmit a request until an appropriate response
is received. It defaults to 500 ms, and doubles after every
retransmission with a maximum of 4 seconds.
7. Transaction failure
If a valid respone is not received for a client or server initiated
transaction, it MUST initiate a new offer/answer [RFC3264] exchange.
8. IANA Considerations
8.1. Registration of the UDP/BFCP as SDP proto value
This section instructs the IANA to register the following new value
for the SDP [RFC4566] 'proto' field under the Session Description
Protocol (SDP) Parameters registry:
+--------------+-----------+
| Value | Reference |
+--------------+-----------+
| UDP/BFCP | RFC4853 |
+--------------+-----------+
Figure 1: Value for the SDP 'proto' field
8.2. Registrations of new BFCP sub registry parameters
This section instructs the IANA to register the following new values
for the BFCP primitive subregistry.
Sandbakken, et al. Expires April 12, 2008 [Page 5]
Internet-Draft BFCP over UDP October 2007
+-----------------------+-----------+
| Value | Reference |
+-----------------------+-----------+
| FloorRequestStatusAck | RFC[XXXX] |
| ErrorAck | RFC[XXXX] |
| FloorStatusAck | RFC[XXXX] |
+--------------+--------------------+
Figure 2: Registration in the BFCP primitive subregistry
9. Security Considerations
TBD
10. Normative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006.
Authors' Addresses
Geir A. Sandbakken (editor)
TANDBERG
N-1366 Lysaker
Norway
Phone: +47 67 125 125
Email: geir.sandbakken@tandberg.com
URI: http://www.tandberg.com
Sandbakken, et al. Expires April 12, 2008 [Page 6]
Internet-Draft BFCP over UDP October 2007
Trond G. Andersen
TANDBERG
N-1366 Lysaker
Norway
Phone: +47 67 125 125
Email: trond.andersen@tandberg.com
URI: http://www.tandberg.com
Alfred E. Heggestad
Telio Telecom
Stoeperigaten 2
N-0250 Oslo
Norway
Phone: +47 488 99 658
Email: alfred.heggestad@telio.no
URI: http://www.telio.no
Sandbakken, et al. Expires April 12, 2008 [Page 7]
Internet-Draft BFCP over UDP October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Sandbakken, et al. Expires April 12, 2008 [Page 8]