Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
RFC 4583
|
| Document |
Type |
|
RFC - Proposed Standard
(November 2006; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4583 (Proposed Standard)
|
|
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
Show full document text