Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
RFC 4583

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                       G. Camarillo
Request for Comments: 4583                                      Ericsson
Category: Standards Track                                  November 2006

             Session Description Protocol (SDP) Format for
              Binary Floor Control Protocol (BFCP) Streams

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   This document specifies how to describe Binary Floor Control Protocol
   (BFCP) streams in Session Description Protocol (SDP) descriptions.
   User agents using the offer/answer model to establish BFCP streams
   use this format in their offers and answers.

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Fields in the 'm' Line ..........................................2
   4. Floor Control Server Determination ..............................3
   5. The 'confid' and 'userid' SDP Attributes ........................5
   6. Association between Streams and Floors ..........................5
   7. TCP Connection Management .......................................5
   8. Authentication ..................................................6
   9. Examples ........................................................7
   10. Security Considerations ........................................8
   11. IANA Considerations ............................................8
      11.1. Registration of the 'TCP/BFCP' and 'TCP/TLS/BFCP'
            SDP 'proto' Values ........................................8
      11.2. Registration of the SDP 'floorctrl' Attribute .............8
      11.3. Registration of the SDP 'confid' Attribute ................9
      11.4. Registration of the SDP 'userid' Attribute ................9
      11.5. Registration of the SDP 'floorid' Attribute ..............10
   12. Acknowledgements ..............................................10
   13. Normative References ..........................................10

Camarillo                   Standards Track                     [Page 1]
RFC 4583              SDP Format for BFCP Streams          November 2006

1.  Introduction

   As discussed in the BFCP (Binary Floor Control Protocol)
   specification [8], a given BFCP client needs a set of data in order
   to establish a BFCP connection to a floor control server.  These data
   include the transport address of the server, the conference
   identifier, and the user identifier.

   One way for clients to obtain this information is to use an
   offer/answer [4] exchange.  This document specifies how to encode
   this information in the SDP session descriptions that are part of
   such an offer/answer exchange.

   User agents typically use the offer/answer model to establish a
   number of media streams of different types.  Following this model, a
   BFCP connection is described as any other media stream by using an
   SDP 'm' line, possibly followed by a number of attributes encoded in
   'a' lines.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [1] and indicate requirement levels for
   compliant implementations.

3.  Fields in the 'm' Line

   This section describes how to generate an 'm' line for a BFCP stream.

   According to the SDP specification [11], the 'm' line format is the
   following:

      m=<media> <port> <transport> <fmt> ...

   The media field MUST have a value of "application".

   The port field is set following the rules in [7].  Depending on the
   value of the 'setup' attribute (discussed in Section 7), the port
   field contains the port to which the remote endpoint will initiate
   its TCP connection or is irrelevant (i.e., the endpoint will initiate
   the connection towards the remote endpoint) and should be set to a
   value of 9, which is the discard port.  Since BFCP only runs on top
   of TCP, the port is always a TCP port.  A port field value of zero
   has the standard SDP meaning (i.e., rejection of the media stream).

Camarillo                   Standards Track                     [Page 2]
RFC 4583              SDP Format for BFCP Streams          November 2006

   We define two new values for the transport field: TCP/BFCP and
   TCP/TLS/BFCP.  The former is used when BFCP runs directly on top of
   TCP, and the latter is used when BFCP runs on top of TLS, which in
   turn runs on top of TCP.