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]