RFC 8856

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

📅 published January 2021, from ietf

📮 RFC 8856: SDP Format for BFCP Streams (Part 1 of 5) 💖

Okay bestie, let's get into it! 🎀 This is RFC 8856, which is a Standards Track doc from the IETF, so it's officially a real spec people are supposed to implement. 💅 It came out in January 2021 and it's written by G. Camarillo (Ericsson), T. Kristensen (Jotron), and C. Holmberg (Ericsson). 🫶 It obsoletes RFC 4583, which means it replaces that older doc. ✨ It doesn't update anything else. 🌸 ISSN is 2070-1721 if you ever need to find it in a list. 🔥

The whole point is giving BFCP streams their own SDP offer/answer rules, so two endpoints can agree on how to set up a floor control connection. 🦋

Here's the title block, all in one place:

Title: Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams 👑
Authors: G. Camarillo (Ericsson), T. Kristensen (Jotron), C. Holmberg (Ericsson) 🧚
Category: Standards Track 💜
Date: January 2021 🍓
Obsoletes: RFC 4583 🙈
Updates: nothing 🌈

Abstract ✨

Okay so the abstract is super short and sweet. 🥹 This doc defines the SDP offer/answer procedures for negotiating and establishing BFCP streams. 💖 Basically it's the rulebook for how these streams get set up in an offer/answer exchange. 🎀

This document obsoletes RFC 4583. 🙈

Status of This Memo ✨

This is an Internet Standards Track document. 🔥

It's a product of the IETF, which means it reflects the consensus of the IETF community. 🫶 It got public review and was approved for publication by the IESG. 💅 If you want more info on Internet Standards, check out Section 2 of RFC 7841. 🦋

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8856. 🌸

Copyright Notice ✨

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. 💜 Please read those carefully, because they spell out your rights and restrictions. 🙈 Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License. ⭐

Table of Contents 🎀

1.  Introduction
2.  Conventions
3.  Floor Control Roles
4.  Fields in the "m=" Line
5.  SDP Attributes
  5.1.  SDP 'floorctrl' Attribute
  5.2.  SDP 'confid' Attribute
  5.3.  SDP 'userid' Attribute
  5.4.  SDP 'floorid' Attribute
  5.5.  SDP 'bfcpver' Attribute
6.  Multiplexing Considerations
7.  BFCP Connection Management
  7.1.  TCP Connection Management
8.  TLS/DTLS Considerations
9.  ICE Considerations
10. SDP Offer/Answer Procedures
  10.1.  Generating the Initial SDP Offer
  10.2.  Generating the SDP Answer
  10.3.  Offerer Processing of the SDP Answer
  10.4.  Modifying the Session
11. Examples
12. Security Considerations
13. IANA Considerations
  13.1.  Registration of SDP 'proto' Values
  13.2.  Registration of the SDP 'floorctrl' Attribute
  13.3.  Registration of the SDP 'confid' Attribute
  13.4.  Registration of the SDP 'userid' Attribute
  13.5.  Registration of the SDP 'floorid' Attribute
  13.6.  Registration of the SDP 'bfcpver' Attribute
14. Changes from RFC 4583
15. References
  15.1.  Normative References
  15.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🌸

1.1. Hmm, Not Quite 💅

Okay so here's the deal. 💖 A BFCP client needs a bunch of info to connect to a floor control server. 🎀 That includes the server's transport address, the conference identifier, and the user identifier. 🫶 BFCP itself is described in [RFC8855]. ✨

One way clients can get that info is an SDP offer/answer exchange [RFC3264]. 🦋 This doc explains how to encode the info in the SDP session descriptions that are part of that exchange. 🔥

User agents usually use the offer/answer model to set up media streams of different types. 🌈 So a BFCP connection gets described just like any other media stream: an SDP "m=" line, plus maybe some extra SDP lines that also apply to the BFCP connection. 💜

Here's what each section covers, bestie:

Section 4 says how the field values in a BFCP "m=" line get set. 🍓
Section 5 defines the SDP attributes used when negotiating a BFCP connection. 🙈
Section 6 covers multiplexing considerations. 🌈
Section 7 covers procedures for managing a BFCP connection. ⭐
Section 8 covers TLS and DTLS considerations when negotiating a BFCP connection. 💅
Section 9 covers Interactive Connectivity Establishment (ICE) [RFC8445] considerations when negotiating a BFCP connection. 🦋
Section 10 covers the SDP offer/answer procedures for negotiating a BFCP connection. 👑

This document obsoletes RFC 4583 [RFC4583], and Section 14 summarizes the changes from it. 🙈✨

2. Conventions 🎀

Okay, the key words are the important bit here. 🔥 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💖 So if you see them in ALL CAPS, they're serious. 💀

3. Floor Control Roles 🦋

When two endpoints set up a BFCP stream, they need to figure out which one is the floor control client and which one is the floor control server. 🧚

Once the roles are sorted, they apply to every BFCP-controlled stream tied to that BFCP stream. 🌸

4. Fields in the "m=" Line 💜

Okay this is where it gets technical, but I promise it's fun. ✨ According to the SDP specification [RFC8866], the "m=" line format looks like this:

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

This section explains how to generate an "m=" line for an SDP Media Description ("m=" section) that describes a BFCP stream. 🎀

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

The port field gets set differently depending on the proto field. 🌈 A port value of zero has the standard SDP meaning (rejecting the media stream), no matter what proto says. 🙈

When TCP is the transport, the port field gets set using the rules in [RFC4145]. 💅 It depends on the 'setup' attribute (defined in [RFC4145] and discussed in Section 7.1). If the remote endpoint is going to send BFCP messages to this port, the port field holds that port. 🫶 But if this endpoint is going to start the connection toward the remote endpoint, the port field SHOULD be set to a value of 9. 🦋

Wait, I need to fix that. The original says "should be set to a value of 9". Here's the correct wording with the key word in caps:

When TCP is the transport, the port field gets set using the rules in [RFC4145]. 💅 It depends on the 'setup' attribute (defined in [RFC4145] and discussed in Section 7.1). The port field contains the port to which the remote endpoint will direct BFCP messages, or, in the case where the endpoint will initiate the connection towards the remote endpoint, SHOULD be set to a value of 9. 🦋
When UDP is the transport, the port field contains the port to which the remote endpoint will direct BFCP messages, no matter what the 'setup' attribute says. 🌸

This doc defines five proto values: 'TCP/BFCP', 'TCP/DTLS/BFCP', 'TCP/TLS/BFCP', 'UDP/BFCP', and 'UDP/TLS/BFCP'. 💜

Here's how each proto value gets used, bestie: 🌈

'TCP/BFCP' is for TCP transport of BFCP without TLS encryption, and it's backward compatible with endpoints that follow RFC 4583. 🍓
'TCP/TLS/BFCP' is for TCP transport of BFCP with TLS encryption, and it's backward compatible with endpoints that follow RFC 4583 and support TLS. 🔥
'UDP/BFCP' is for UDP transport of BFCP without DTLS encryption [RFC6347]. ⭐
'UDP/TLS/BFCP' is for UDP transport of BFCP with DTLS encryption. 💅 It's one of the options when ICE is used (Section 9). It can also be used without ICE when backward compatibility with RFC 4583 endpoints isn't required. 🦋
'TCP/DTLS/BFCP' is for TCP transport of BFCP with DTLS encryption, running on top of TCP using the framing method from [RFC4571]. 🫶 DTLS packets get sent and received instead of RTP / RTP Control Protocol (RTCP) packets, so the LENGTH field defined in RFC 4571 comes before each DTLS message. 🧚 It's one of the options when ICE is used (Section 9). It can also be used without ICE when backward compatibility with RFC 4583 endpoints isn't required. 🎀

The fmt (format) list doesn't apply to BFCP. 🙈 The fmt list of "m=" lines for any BFCP-related proto value MUST contain a single "*" character. 💖 If the fmt list has any other value, it MUST be ignored. 💀

Here's an example "m=" line for a BFCP connection: 🌸

m=application 50000 TCP/TLS/BFCP *

5. SDP Attributes 🌈

Okay bestie, that's the end of Part 1! 🎀 Section 5 and everything after it comes in the next parts, so stay tuned. 💅✨

5.1. SDP 'floorctrl' Attribute ✨

okay bestie, this is the floorctrl media-level attribute 💅 It's how endpoints figure out who gets to be the floor control client and who gets to be the floor control server for the BFCP stream 🎀

Attribute Name: floorctrl
Attribute Value: floor-control
Usage Level: media
Charset Dependent: No
Mux Category: TBD

The Augmented BNF syntax [RFC5234] for the attribute is:

floor-control = role *(SP role)
role = "c-only" / "s-only" / "c-s"

An endpoint includes the attribute to say which roles it's willing to play for the BFCP-controlled media streams 🦋

c-only: the endpoint is willing to act as a floor control client.

s-only: the endpoint is willing to act as a floor control server only.

When it's in an offer, the offerer MAY indicate multiple attribute values (c-only and s-only). When it's in an answer, the answerer MUST indicate only one attribute value: c-only or s-only. The answerer is basically announcing which role it took, and then the offerer takes the opposite one 🫶

In [RFC4583], there was a third value, c-s, which meant the endpoint was willing to be both a floor control client and a floor control server at the same time for the BFCP stream, taking different roles for different BFCP-controlled media streams. ngl this one was a mess 💀 It was underspecified, implementations did their own thing, and a lot of them read c-s as "I'll be either a client or a server" (which is the same as c-only s-only). So for anyone following this spec: an implementation MUST NOT include the c-s floorctrl attribute value in an offer or in an answer, but it MUST accept that value in an offer and process it as equivalent to c-only s-only (or s-only c-only).

Also, since a compliant implementation can only include one role, c-only or s-only, in an answer, each endpoint only takes one role. That means it takes the same role for every BFCP-controlled media stream associated with the BFCP stream 🌸

Table 1 shows which roles the answerer is allowed to take, based on the roles the offerer said it was willing to take:

                      +=========+==========+
                      | Offerer | Answerer |
                      +=========+==========+
                      |  c-only |  s-only  |
                      +---------+----------+
                      |  s-only |  c-only  |
                      +---------+----------+
                      |   c-s   |  c-only  |
                      +---------+----------+
                      |   c-s   |  s-only  |
                      +---------+----------+

                          Table 1: Roles

Endpoints that follow [RFC4583] might not include the floorctrl attribute in offers and answers at all 🙈 If the attribute isn't there, then to play nice with those endpoints, the offerer acts as a floor control client and the answerer acts as a floor control server.

The SDP Offer/Answer procedures for floorctrl are defined in Section 10.

Here's an example of a floorctrl attribute in an offer:

a=floorctrl:c-only s-only

5.2. SDP 'confid' Attribute ✨

this is the confid media-level attribute, and it's how a floor control server passes the conference ID value over to the floor control client 🧚 The value is written as a decimal integer.

Attribute Name: confid
Attribute Value: conference-id
Usage Level: media
Charset Dependent: No
Mux Category: TBD

The Augmented BNF syntax [RFC5234] for the attribute is:

conference-id = 1*DIGIT

DIGIT = <DIGIT as defined in [RFC5234]>

The maximum value of the attribute is decided by the COMMON-HEADER format [RFC8855] 💜

The SDP Offer/Answer procedures for confid are defined in Section 10.

5.3. SDP 'userid' Attribute ✨

same energy as confid, but this one is for the user ID value 🎀 A floor control server uses it to tell the floor control client which user ID it has, again as a decimal integer.

Attribute Name: userid
Attribute Value: user-id
Usage Level: media
Charset Dependent: No
Mux Category: TBD

The Augmented BNF syntax [RFC5234] for the attribute is:

user-id = 1*DIGIT

DIGIT = <DIGIT as defined in [RFC5234]>

The maximum value of the attribute is decided by the COMMON-HEADER format [RFC8855] 🍓

The SDP Offer/Answer procedures for userid are defined in Section 10.

5.4. SDP 'floorid' Attribute ✨

this is the floorid media-level attribute, and it's giving "here's a floor identifier, and also here are the streams it's connected to" 👑 The floor identifier is a decimal integer, and it can optionally point at one or more BFCP-controlled media streams.

Attribute Name: floorid
Attribute Value: floor-id
Usage Level: media
Charset Dependent: No
Mux Category: TBD

The Augmented BNF syntax [RFC5234] for the attribute is:

floor-id = 1*DIGIT SP "mstrm:" token *(SP token)

DIGIT = <DIGIT as defined in [RFC5234]>
token = <token as defined in [RFC8866]>

The maximum value of the attribute is decided by the FLOOR-ID format [RFC8855] ✨

The floor identifier value is the integer form of the Floor ID field value [RFC8855] that gets used in BFCP. Each media stream pointer value is tied to an SDP 'label' attribute [RFC4574] of a media stream 🦋

The SDP Offer/Answer procedures for floorid are defined in Section 10.

💅 Note: in the first SDP example in Section 9 of [RFC4583], 'm-stream' was listed by mistake. Even though that example wasn't normative, some vendors implemented it, and it shows up when an endpoint is willing to act as a server. So it's RECOMMENDED to support parsing and interpreting 'm-stream' the same way as 'mstrm' when receiving. bestie, that's a whole vibe check 🙈

5.5. SDP 'bfcpver' Attribute ✨

last one in this group! bfcpver is used to negotiate the BFCP version, and the value is a decimal integer 🌈

Attribute Name: bfcpver
Attribute Value: bfcp-version
Usage Level: media
Charset Dependent: No
Mux Category: TBD

The Augmented BNF syntax [RFC5234] for the attribute is:

bfcp-version = version *(SP version)
version = 1*DIGIT

DIGIT = <DIGIT as defined in [RFC5234]>

The maximum value of the attribute is decided by the COMMON-HEADER format [RFC8855] 🌸

An endpoint uses bfcpver to share which version(s) of BFCP it supports, as integer values. For any given version, the attribute value representing that version MUST match the version ("Ver") field that would be shown in the BFCP COMMON-HEADER [RFC8855]. The BFCP version that actually gets used will be conveyed later with a BFCP-level Hello/HelloAck 💖

Endpoints that follow [RFC4583] might not always include bfcpver in offers and answers. If the attribute is there, its value MUST be in accordance with the definition of the version ("Ver") field in [RFC8855]. If it's not there, endpoints MUST assume a default value in accordance with [RFC8855]: when it's used over a reliable transport, the default is "1", and when it's used over an unreliable transport, the default is "2". The value is inferred from the transport given in the "m=" line (Section 4) of the "m=" section associated with the stream 🧚

The SDP Offer/Answer procedures for bfcpver are defined in Section 10.

6. Multiplexing Considerations ✨

okay so [RFC8843] is the one that defines how multiple media streams can be multiplexed 🦋 This spec does NOT define how BFCP streams can be multiplexed with other media streams. So a BFCP stream MUST NOT be associated with a BUNDLE group [RFC8843]. But heads up, BFCP-controlled media streams might still be multiplexed with other media streams 👑

[RFC8859] defines the mux categories for the SDP attributes in this specification, except for bfcpver. Table 2 gives the mux category for bfcpver:

+=========+===========================+=======+==============+
| Name    | Notes                     | Level | Mux Category |
+=========+===========================+=======+==============+
| bfcpver | Needs further analysis in | M     | TBD          |
|         | a separate specification  |       |              |
+---------+---------------------------+-------+--------------+

           Table 2: Multiplexing Attribute Analysis

7. BFCP Connection Management ✨

BFCP streams can run over TCP or UDP as the underlying transport 🎀 Endpoints exchanging BFCP messages over UDP send them to the peer using the connection address and port given in the SDP "c=" and "m=" lines. TCP connection management is more complicated, so that's covered in the next section 💅

🔥 Note: when you're using Interactive Connectivity Establishment (ICE) [RFC8445], TCP/DTLS/BFCP, or UDP/TLS/BFCP, the straightforward procedures for connection management via UDP/BFCP, as described above, apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and is described below.

7.1. TCP Connection Management ✨

TCP connection management for BFCP messages uses the SDP 'setup' and 'connection' attributes [RFC4145] 🦋 The 'setup' attribute says which endpoint starts the TCP connection. The 'connection' attribute handles TCP connection re-establishment.

The BFCP specification [RFC8855] describes a bunch of situations where the TCP connection between a floor control client and the floor control server needs to be re-established. But [RFC8855] doesn't describe how to re-establish it, because that depends on how the connection was set up in the first place 🙈 So endpoints using the offer/answer mechanism follow these rules:

When the existing TCP connection gets closed and re-established following the rules in [RFC8855], the floor control client MUST send an offer towards the floor control server to re-establish the connection. If a TCP connection can't deliver a BFCP message and times out, the endpoint that tried to send the message (the one that detected the TCP timeout) MUST send an offer to re-establish the TCP connection 💖

Endpoints that use the offer/answer mechanism to negotiate TCP connections MUST support the 'setup' and 'connection' attributes 🌈

8. TLS/DTLS Considerations ✨

okay so if you're running DTLS over UDP, the generic procedures in Section 5 of [RFC8842] MUST be followed. no skipping, bestie 💅

when TLS runs over TCP, the answerer is ALWAYS the TLS server once the underlying connection is up 🎀 and if that TCP connection drops, the active endpoint [RFC4583] is the one in charge of rebuilding it 🔧 unless a brand new TLS connection gets negotiated, later SDP offers and answers won't touch the TLS roles that were already agreed on 🦋

Note: For TLS, it was decided to keep the original procedures in [RFC4583] to determine which endpoint acts as the TLS server, in order to retain backward compatibility. 🫶

9. ICE Considerations

the generic SDP offer/answer procedures for ICE live in [RFC8839] 🧚

when BFCP is used with UDP-based ICE candidates [RFC8445], the UDP/TLS/BFCP procedures apply 💜 and when BFCP is used with TCP-based ICE candidates [RFC6544], the TCP/DTLS/BFCP procedures apply 🌸

following the procedures in [RFC8842], endpoints treat every ICE candidate pair tied to a BFCP stream sitting on a DTLS association as part of that same DTLS association 🔗 so there's only ever ONE BFCP handshake and ONE DTLS handshake, even if there are multiple valid candidate pairs, and even if the BFCP media hops between candidate pairs (including switching from UDP pairs to TCP pairs) before nomination 🙈 new candidates that show up also join that same DTLS association. iconic consistency ✨

to give yourself the best shot at interoperability, all ICE-enabled BFCP-over-DTLS endpoints SHOULD implement support for UDP/TLS/BFCP 🌈

when an SDP offer or answer carries multiple ICE candidates for a BFCP stream, UDP-based candidates SHOULD be included, and the default candidate SHOULD be picked from one of those UDP candidates 💖 if UDP is used for the default candidate, the "m=" line proto value MUST be 'UDP/TLS/BFCP'. if TCP is used for the default candidate instead, the "m=" line proto value MUST be 'TCP/DTLS/BFCP'. 🍓

Note: Usage of ICE with protocols other than UDP/TLS/BFCP and TCP/DTLS/BFCP is out of scope for this specification. 🙅‍♀️

10. SDP Offer/Answer Procedures

this section is where the SDP offer/answer [RFC3264] procedures for negotiating and setting up a BFCP stream live 📞 generic DTLS procedures are in [RFC8842], and generic TLS procedures are in [RFC8122] 💫

this section only spells out the BFCP-specific stuff. unless it says otherwise, the procedures apply to an "m=" section describing a BFCP stream. if an offer or answer has multiple "m=" sections describing BFCP streams, each stream gets the procedures applied on its own 🦋

quick definition: an 'initial offer' is the first offer within an SDP session (for example, a Session Initiation Protocol (SIP) [RFC3261] dialog, when SIP is what carries the SDP) where the offerer says it wants to negotiate setting up a BFCP stream 🎀

if the "m=" line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP', or 'UDP/TLS/BFCP', the offerer and answerer follow the generic procedures in [RFC8122] 🌷

if the "m=" line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/TCP', or 'UDP/TLS/BFCP', the offerer and answerer use the SDP 'setup' attribute following the procedures in [RFC4145] 🧩

if the "m=" line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', or 'TCP/DTLS/BFCP', the offerer and answerer use the SDP 'connection' attribute following the procedures in [RFC4145] 🔌

Note: The use of source-specific SDP parameters [RFC5576] is not defined for BFCP streams. 🚫

10.1. Generating the Initial SDP Offer

when the offerer makes an initial offer, the offerer MUST include an SDP 'floorctrl' attribute (Section 5.1) and an SDP 'bfcpver' attribute (Section 5.5) in the "m=" section 📝

also, if the offerer puts an SDP 'floorctrl' attribute with "s-only" or "c-s" attribute values in the offer, the offerer:

MUST include an SDP 'confid' attribute (Section 5.2) in the "m=" section,
MUST include an SDP 'userid' attribute (Section 5.3) in the "m=" section,
MUST include an SDP 'floorid' attribute (Section 5.4) in the "m=" section, and
MUST include an SDP 'label' attribute [RFC4574] with the "m=" section of each BFCP-controlled media stream. 🏷️

Note: If the offerer includes an SDP 'floorctrl' attribute with a "c-s" attribute value, or both a "c-only" and an "s-only" attribute value in the offer, the attribute values above will only be used if it is determined (Section 5.1) that the offerer will act as a floor control server. 👑

10.2. Generating the SDP Answer

when the answerer gets an offer with an "m=" section describing a BFCP stream, the answerer MUST check whether it supports one or more of the BFCP versions the offerer supports (Section 5.5) 🔍 if the answerer doesn't support any of those versions, it MUST NOT accept the "m=" section. otherwise, if the answerer accepts the "m=" section, the answerer:

MUST insert a corresponding "m=" section in the answer, with an identical "m=" line proto value [RFC8866],
MUST include a 'bfcpver' attribute in the "m=" section; the versions indicated by the answer MUST be the same as or a subset of the versions indicated by the offerer in the corresponding offer, and
MUST, if the offer contained an SDP 'floorctrl' attribute, include a 'floorctrl' attribute in the "m=" section. 💅

also, if the answerer puts an SDP 'floorctrl' attribute with an "s-only" attribute value in the answer, the answerer:

MUST include an SDP 'confid' attribute in the "m=" section,
MUST include an SDP 'userid' attribute in the "m=" section,
MUST include an SDP 'floorid' attribute in the "m=" section, and
MUST include an SDP 'label' attribute in the "m=" section of each BFCP-controlled media stream. 🎀

Note: An offerer compliant with [RFC4583] might not include 'floorctrl' and 'bfcpver' attributes in offers, in which case the default values apply. 🧸

once the answerer has sent the answer, the answerer:

MUST, if the answerer is the active endpoint and if a TCP connection associated with the "m=" section is to be established (or re-established), initiate the establishment of the TCP connection, and
MUST, if the answerer is the active endpoint and if a TLS/DTLS connection associated with the "m=" section is to be established (or re-established), initiate the establishment of the TLS/DTLS connection (by sending a ClientHello message). 🤝

if the answerer does NOT accept the "m=" section in the offer, it MUST assign a zero port value to the "m=" line of the matching "m=" section in the answer. on top of that, the answerer MUST NOT establish a TCP connection or a TLS/DTLS connection associated with that "m=" section. 🚫

10.3. Offerer Processing of the SDP Answer

when the offerer gets an answer with an "m=" section describing a BFCP stream and a non-zero port value in the "m=" line, the offerer:

MUST, if the offerer is the active endpoint and if a TCP connection associated with the "m=" section is to be established (or re-established), initiate the establishment of the TCP connection, and
MUST, if the offerer is the active endpoint and if a TLS/DTLS connection associated with the "m=" section is to be established (or re-established), initiate the establishment of the TLS/DTLS connection (by sending a ClientHello message). ✨

Note: An answerer compliant with [RFC4583] might not include 'floorctrl' and 'bfcpver' attributes in answers, in which case the default values apply. 🫧

if the "m=" line in the answer has a zero port value, or if the offerer for some other reason doesn't accept the answer (for example, if the answerer only indicates support for BFCP versions the offerer doesn't support), the offerer MUST NOT establish a TCP connection or a TLS/DTLS connection associated with the "m=" section. 🙅‍♀️

10.4. Modifying the Session

when an offerer sends an updated offer to modify a BFCP stream that's already up, it follows the procedures in Section 10.1, with these exceptions 🔄

if the BFCP stream is carried on top of TCP and the offerer does NOT want to re-establish an existing TCP connection, the offerer MUST include an SDP 'connection' attribute with a value of "existing" in the "m=" section, and
if the offerer wants to disable a BFCP stream that was previously established, it MUST assign a zero port value to the "m=" line associated with the BFCP connection, following the procedures in [RFC3264]. 🪦

11. Examples

to keep things brief, the main part of the session description is left out of these examples. they only show "m=" sections and their "m=" lines and attributes 🍰

first up, an offer a conference server sends to a client 🎬

   m=application 50000 TCP/TLS/BFCP *
   a=setup:actpass
   a=connection:new
   a=fingerprint:sha-256 \
        19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \
        BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
   a=floorctrl:c-only s-only
   a=confid:4321
   a=userid:1234
   a=floorid:1 mstrm:10
   a=floorid:2 mstrm:11
   a=bfcpver:1 2
   m=audio 50002 RTP/AVP 0
   a=label:10
   m=video 50004 RTP/AVP 31
   a=label:11

Note: Due to RFC formatting conventions, this document splits the SDP entries across lines whose content would exceed the maximum line length. A backslash character ("") marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content. 🧵

here's the answer the client sends back 💌

   m=application 9 TCP/TLS/BFCP *
   a=setup:active
   a=connection:new
   a=fingerprint:sha-256 \
        6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \
        DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
   a=floorctrl:c-only
   a=bfcpver:1
   m=audio 55000 RTP/AVP 0
   m=video 55002 RTP/AVP 31

a similar example uses an unreliable transport with DTLS, shown below. this time the offer comes from a client 🛸

   m=application 50000 UDP/TLS/BFCP *
   a=setup:actpass
   a=dtls-id:abc3dl
   a=fingerprint:sha-256 \
        19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \
        BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
   a=floorctrl:c-only s-only
   a=confid:4321
   a=userid:1234
   a=floorid:1 mstrm:10
   a=floorid:2 mstrm:11
   a=bfcpver:1 2
   m=audio 50002 RTP/AVP 0
   a=label:10
   m=video 50004 RTP/AVP 31
   a=label:11

and the server's answer 🖥️

   m=application 55000 UDP/TLS/BFCP *
   a=setup:active
   a=dtls-id:abc3dl
   a=fingerprint:sha-256 \
        6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \
        DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
   a=floorctrl:s-only
   a=confid:4321
   a=userid:1234
   a=floorid:1 mstrm:10
   a=floorid:2 mstrm:11
   a=bfcpver:2
   m=audio 55002 RTP/AVP 0
   m=video 55004 RTP/AVP 31

12. Security Considerations 🔐💀

okay bestie, this part is serious so let's be serious 🫶 the BFCP spec [RFC8855], the SDP spec [RFC8866], and the offer/answer spec [RFC3264] each talk about their own security issues for BFCP, SDP, and offer/answer. ✨ on top of that, [RFC4145] and [RFC8122] cover the security stuff for setting up TCP and TLS connections with an offer/answer model 🎀 and if you're doing DTLS over UDP, you MUST follow the generic offer/answer considerations in [RFC8842] 🔥 no skipping that one, periodt 💅

now the lowkey scary part 😭 some proto values you can negotiate in SDP offer/answer will end up with a BFCP stream that is NOT protected by TLS or DTLS 💀 so operators need to give the BFCP stream integrity protection and confidentiality protection some other way 🙈 it's not optional vibes, it's a whole main character responsibility 👑

also the generic security stuff for SDP attributes is in [RFC3264] 🧚 the attributes in this spec don't reveal what's inside the individual BFCP-controlled media streams 🦋 but they DO reveal which media streams are going to be BFCP controlled, so the existence of the floor control is visible even if the content isn't 👀

13. IANA Considerations 📝

this doc registers three new values in the "proto" subregistry of the "Session Description Protocol (SDP) Parameters" registry: TCP/DTLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP (see Section 13.1) 🌸 it also registers a new SDP attribute in the 'attribute-name (formerly "att-field")' subregistry of that same registry: bfcpver (see Section 5.5) ✨ and the remaining values are unchanged from [RFC4582], except the references now point to this document 💖

13.1. Registration of SDP 'proto' Values 🎀

the IANA registered three new values in the SDP 'proto' field under the "Session Description Protocol (SDP) Parameters" registry 🧚

                   +===============+===========+
                   | Value         | Reference |
                   +===============+===========+
                   | TCP/BFCP      |  RFC 8856 |
                   +---------------+-----------+
                   | TCP/DTLS/BFCP |  RFC 8856 |
                   +---------------+-----------+
                   | TCP/TLS/BFCP  |  RFC 8856 |
                   +---------------+-----------+
                   | UDP/BFCP      |  RFC 8856 |
                   +---------------+-----------+
                   | UDP/TLS/BFCP  |  RFC 8856 |
                   +---------------+-----------+

                      Table 3: Values for the
                         SDP 'proto' Field

13.2. Registration of the SDP 'floorctrl' Attribute 🌈

this doc defines the SDP 'floorctrl' attribute 💅 the details are in Section 5.1 🫶

13.3. Registration of the SDP 'confid' Attribute 🦋

this doc defines the SDP 'confid' attribute ✨ the details are in Section 5.2 💖

13.4. Registration of the SDP 'userid' Attribute 🌸

this doc defines the SDP 'userid' attribute 🎀 the details are in Section 5.3 🧚

13.5. Registration of the SDP 'floorid' Attribute 💜

this doc defines the SDP 'floorid' attribute 🔥 the details are in Section 5.4 👑

13.6. Registration of the SDP 'bfcpver' Attribute 🍓

this doc defines the SDP 'bfcpver' attribute 🌟 the details are in Section 5.5 🙌

14. Changes from RFC 4583 🔄

these are the technical changes and other fixes from [RFC4583], listed below 📋

the whole point of this work was adding the signaling support needed for BFCP over an unreliable transport, as described in [RFC8855] 🚀 that resulted in these changes:

Fields in the "m=" Line (Section 4): this section got rewritten to remove the reference to TCP being the only transport for BFCP streams 💅 the proto field values TCP/DTLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP were added 🎀
Security Considerations (Section 12): for the DTLS-over-UDP case, we point the reader to the existing considerations and requirements for the offer/answer exchange in [RFC8842] 🔐
Registration of SDP 'proto' Values (Section 13.1): this doc registers the three new values TCP/DTLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP in the "Session Description Protocol (SDP) Parameters" registry 🌸
SDP 'bfcpver' Attribute (Section 5.5): a new 'bfcpver' SDP media-level attribute was added so you can signal the supported version number 🧚✨

on top of the unreliable transport stuff, endpoints used to be able to act as both a floor control client AND a floor control server at the same time 😳 that possibility has been removed 🙅‍♀️ now an endpoint takes the same role for all BFCP-controlled streams associated with the BFCP stream 💜

clarifications and bug fixes 🛠️

Erratum ID 712 (Sections 3 and 10 of [RFC4583]; see [Err712] for details): don't say things like 'used in an "m=" line' when you're talking about an SDP attribute 🙈 instead, make it clear the attribute is a media-level attribute 💖
Spelling corrected in the first SDP example in Section 9 of [RFC4583]: don't use 'm-stream' from the first SDP example in [RFC4583] 💅 use the correct 'mstrm' from Section 11 of this doc instead ✨ but we recommend still interpreting 'm-stream' if you receive it, because some implementations still have it 🫶
Assorted clarifications (throughout the document): language got clarified after reviews 📝 and normative language was "tightened" where it made sense, meaning changed from "SHOULD" strength to "MUST" in a bunch of places 🔥

15. References 📚

15.1. Normative References 🎀

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
           A., Peterson, J., Sparks, R., Handley, M., and E.
           Schooler, "SIP: Session Initiation Protocol", RFC 3261,
           DOI 10.17487/RFC3261, June 2002,
           <https://www.rfc-editor.org/info/rfc3261>.

[RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
           with Session Description Protocol (SDP)", RFC 3264,
           DOI 10.17487/RFC3264, June 2002,
           <https://www.rfc-editor.org/info/rfc3264>.

[RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
           the Session Description Protocol (SDP)", RFC 4145,
           DOI 10.17487/RFC4145, September 2005,
           <https://www.rfc-editor.org/info/rfc4145>.

[RFC4571]  Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
           and RTP Control Protocol (RTCP) Packets over Connection-
           Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
           2006, <https://www.rfc-editor.org/info/rfc4571>.

[RFC4574]  Levin, O. and G. Camarillo, "The Session Description
           Protocol (SDP) Label Attribute", RFC 4574,
           DOI 10.17487/RFC4574, August 2006,
           <https://www.rfc-editor.org/info/rfc4574>.

[RFC4582]  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
           Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582,
           November 2006, <https://www.rfc-editor.org/info/rfc4582>.

[RFC4583]  Camarillo, G., "Session Description Protocol (SDP) Format
           for Binary Floor Control Protocol (BFCP) Streams",
           RFC 4583, DOI 10.17487/RFC4583, November 2006,
           <https://www.rfc-editor.org/info/rfc4583>.

[RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234,
           DOI 10.17487/RFC5234, January 2008,
           <https://www.rfc-editor.org/info/rfc5234>.

[RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
           Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
           January 2012, <https://www.rfc-editor.org/info/rfc6347>.

[RFC6544]  Rosenberg, J., Keranen, A., Lowekamp, B. B., and A. B.
           Roach, "TCP Candidates with Interactive Connectivity
           Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
           March 2012, <https://www.rfc-editor.org/info/rfc6544>.

[RFC8122]  Lennox, J. and C. Holmberg, "Connection-Oriented Media
           Transport over the Transport Layer Security (TLS) Protocol
           in the Session Description Protocol (SDP)", RFC 8122,
           DOI 10.17487/RFC8122, March 2017,
           <https://www.rfc-editor.org/info/rfc8122>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
           Connectivity Establishment (ICE): A Protocol for Network
           Address Translator (NAT) Traversal", RFC 8445,
           DOI 10.17487/RFC8445, July 2018,
           <https://www.rfc-editor.org/info/rfc8445>.

[RFC8839]  Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen,
           A., and R. Shpount, "Session Description Protocol (SDP)
           Offer/Answer Procedures for Interactive Connectivity
           Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839,
           January 2021, <https://www.rfc-editor.org/info/rfc8839>.

[RFC8842]  Holmberg, C. and R. Shpount, "Session Description Protocol
           (SDP) Offer/Answer Considerations for Datagram Transport
           Layer Security (DTLS) and Transport Layer Security (TLS)",
           RFC 8842, DOI 10.17487/RFC8842, January 2021,
           <https://www.rfc-editor.org/info/rfc8842>.

[RFC8855]  Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C.
           Eckel, "The Binary Floor Control Protocol (BFCP)",
           RFC 8855, DOI 10.17487/RFC8855, January 2021,
           <https://www.rfc-editor.org/info/rfc8855>.

[RFC8859]  Nandakumar, S., "A Framework for Session Description
           Protocol (SDP) Attributes When Multiplexing", RFC 8859,
           DOI 10.17487/RFC8859, January 2021,
           <https://www.rfc-editor.org/info/rfc8859>.

[RFC8866]  Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
           Session Description Protocol", RFC 8866,
           DOI 10.17487/RFC8866, January 2021,
           <https://www.rfc-editor.org/info/rfc8866>.

15.2. Informative References 🦋

[Err712]   RFC Errata, Erratum ID 712, RFC 4583,
           <https://www.rfc-editor.org/errata/eid712>.

[RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
           Media Attributes in the Session Description Protocol
           (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
           <https://www.rfc-editor.org/info/rfc5576>.

[RFC8843]  Holmberg, C., Alvestrand, H., and C. Jennings,
           "Negotiating Media Multiplexing Using the Session
           Description Protocol (SDP)", RFC 8843,
           DOI 10.17487/RFC8843, January 2021,
           <https://www.rfc-editor.org/info/rfc8843>.

Acknowledgements 🫶

okay bestie, big thank-you energy incoming 💖 Jörg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and Oscar Novo helped out with useful ideas for the original [RFC4583] 🙌 The authors also gave a shoutout to Geir Arne Sandbakken, Charles Eckel, Alan Ford, Eoin McLeod, and Mark Thompson for their contributions to revising BFCP so it works over an unreliable transport 🦋 Ali C. Begen, Mary Barnes, and Charles Eckel did the useful and important final reviews ✨ And in the final stages, Roman Shpount put in a seriously huge effort adding proper ICE support and considerations 👑 iconic contributions, all of them 💅

Authors' Addresses 🎀

here are the authors, with their contact info exactly as written 🌸

Gonzalo Camarillo
Ericsson
Hirsalantie 11
FI-02420 Jorvas
Finland

Email: Gonzalo.Camarillo@ericsson.com

Tom Kristensen
Jotron AS
Ringdalskogen 8
3270 Larvik
Norway

Email: tom.kristensen@jotron.com, tomkri@ifi.uio.no

Christer Holmberg
Ericsson
Hirsalantie 11
FI-02420 Jorvas
Finland

Email: christer.holmberg@ericsson.com

and that's a wrap on the whole doc, bestie 🧚💜

📦 where this page comes from

ietf: rfc8856 2021-01
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms