[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-sandbakken-dispatch-bfcp-udp

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/