Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
RFC 4583
Document | Type |
RFC - Proposed Standard
(November 2006; Errata)
Obsoleted by RFC 8856
|
|
---|---|---|---|
Author | Gonzalo Camarillo | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4583 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | jon.peterson@neustar.biz, csp@csperkins.org, jo@acm.org |
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.Show full document text