diff options
Diffstat (limited to 'doc/rfc/rfc8856.txt')
| -rw-r--r-- | doc/rfc/rfc8856.txt | 1101 |
1 files changed, 1101 insertions, 0 deletions
diff --git a/doc/rfc/rfc8856.txt b/doc/rfc/rfc8856.txt new file mode 100644 index 0000000..408c085 --- /dev/null +++ b/doc/rfc/rfc8856.txt @@ -0,0 +1,1101 @@ + + + + +Internet Engineering Task Force (IETF) G. Camarillo +Request for Comments: 8856 Ericsson +Obsoletes: 4583 T. Kristensen +Category: Standards Track Jotron +ISSN: 2070-1721 C. Holmberg + Ericsson + January 2021 + + + Session Description Protocol (SDP) Format for Binary Floor Control + Protocol (BFCP) Streams + +Abstract + + This document defines the Session Description Protocol (SDP) offer/ + answer procedures for negotiating and establishing Binary Floor + Control Protocol (BFCP) streams. + + This document obsoletes RFC 4583. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8856. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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 of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided 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 + + As discussed in the BFCP (Binary Floor Control Protocol) + specification [RFC8855], a given BFCP client needs a set of data in + order to establish a BFCP connection to a floor control server. This + data includes the transport address of the server, the conference + identifier, and the user identifier. + + One way for clients to obtain this information is to use a Session + Description Protocol (SDP) offer/answer exchange [RFC3264]. 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 SDP lines that also + apply to the BFCP connection. + + Section 4 defines how the field values in an "m=" line representing a + BFCP connection are set. + + Section 5 defines SDP attributes that are used when negotiating a + BFCP connection. + + Section 6 defines multiplexing considerations for a BFCP connection. + + Section 7 defines procedures for managing a BFCP connection. + + Section 8 defines TLS and DTLS considerations when negotiating a BFCP + connection. + + Section 9 defines considerations regarding Interactive Connectivity + Establishment (ICE) [RFC8445] when negotiating a BFCP connection. + + Section 10 defines the SDP offer/answer procedures for negotiating a + BFCP connection. + + This document obsoletes RFC 4583 [RFC4583]. Section 14 summarizes + the changes from RFC 4583. + +2. Conventions + + 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. + +3. Floor Control Roles + + When two endpoints establish a BFCP stream, they need to determine + which of them acts as a floor control client and which acts as a + floor control server. + + Once the roles have been determined, the roles will apply to all + BFCP-controlled streams associated with the BFCP stream. + +4. Fields in the "m=" Line + + According to the SDP specification [RFC8866], the "m=" line format is + as follows: + + m=<media> <port> <proto> <fmt> ... + + This section describes how to generate an "m=" line of an SDP Media + Description ("m=" section) describing a BFCP stream. + + The media field MUST have a value of "application". + + Depending on the value of the proto field, the port field is set as + explained below. A port field value of zero has the standard SDP + meaning (i.e., rejection of the media stream), regardless of the + proto field. + + * When TCP is used as the transport, the port field is set following + the rules in [RFC4145]. Depending on the value of 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 used as the transport, the port field contains the + port to which the remote endpoint will direct BFCP messages, + regardless of the value of the 'setup' attribute. + + This document defines five values for the proto field: 'TCP/BFCP', + 'TCP/DTLS/BFCP', 'TCP/TLS/BFCP', 'UDP/BFCP', and 'UDP/TLS/BFCP'. + + The proto values are used as described below: + + * 'TCP/BFCP' is used for TCP transport of BFCP without TLS + encryption and is backward compatible with endpoints that are + compliant with RFC 4583. + + * 'TCP/TLS/BFCP' is used for TCP transport of BFCP with TLS + encryption and is backward compatible with endpoints that are + compliant with RFC 4583 and support TLS. + + * 'UDP/BFCP' is used for UDP transport of BFCP without DTLS + encryption [RFC6347]. + + * 'UDP/TLS/BFCP' is used for UDP transport of BFCP with DTLS + encryption. This is one of the options when ICE is used + (Section 9). It can also be used without ICE when backward + compatibility with endpoints compliant with RFC 4583 is not + required. + + * 'TCP/DTLS/BFCP' is used for TCP transport of BFCP with DTLS + encryption, running on top of TCP using the framing method defined + in [RFC4571], with DTLS packets being sent and received instead of + RTP / RTP Control Protocol (RTCP) packets, such that the LENGTH + field defined in RFC 4571 precedes each DTLS message. This is one + of the options when ICE is used (Section 9). It can also be used + without ICE when backward compatibility with endpoints compliant + with RFC 4583 is not required. + + The fmt (format) list is not applicable to BFCP. The fmt list of + "m=" lines in the case of any proto field value related to BFCP MUST + contain a single "*" character. If the fmt list contains any other + value, it MUST be ignored. + + The following is an example of an "m=" line for a BFCP connection: + + m=application 50000 TCP/TLS/BFCP * + +5. SDP Attributes + +5.1. SDP 'floorctrl' Attribute + + This section defines the SDP 'floorctrl' media-level attribute. The + attribute is used to determine the floor control roles (client and + server) for the endpoints associated with 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 indicate the role(s) it would + be willing to perform 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 inserted in an offer, the offerer MAY indicate multiple + attribute values ("c-only" and "s-only"). When inserted in an + answer, the answerer MUST indicate only one attribute value: "c-only" + or "s-only". The answerer indicates the role taken by the answerer. + The offerer will then take the opposite role. + + In [RFC4583], there was a third attribute specified, "c-s", which + meant that an endpoint was willing to act as 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. The feature was underspecified and implemented in different + ways; in particular, many implementations interpreted "c-s" to mean + that the endpoint is willing to act as either a client or a server + (equivalent to "c-only s-only"). An implementation compliant with + this specification MUST NOT include the "c-s" 'floorctrl' attribute + value in an offer or in an answer but MUST accept the attribute value + in an offer and process it as equivalent to "c-only s-only" (or + "s-only c-only"). Also, as an implementation compliant with this + specification is only allowed to include one role -- either "c-only" + or "s-only" -- in an answer, each endpoint will only take one role, + and as a result the endpoint will take the same role for each BFCP- + controlled media stream associated with the BFCP stream. + + Table 1 shows the roles that the answerer is allowed to take, based + on what roles the offerer has indicated that it is 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 compliant with [RFC4583] might not include the 'floorctrl' + attribute in offers and answers. If the 'floorctrl' attribute is not + present, in order to be interoperable with such endpoints, the + offerer will act as a floor control client and the answerer will act + as a floor control server. + + The SDP Offer/Answer procedures for the 'floorctrl' attribute are + defined in Section 10. + + The following is an example of a 'floorctrl' attribute in an offer: + + a=floorctrl:c-only s-only + +5.2. SDP 'confid' Attribute + + This section defines the SDP 'confid' media-level attribute. The + attribute is used by a floor control server to convey the conference + ID value to the floor control client, using decimal integer + representation. + + 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 determined by the COMMON-HEADER + format [RFC8855]. + + The SDP Offer/Answer procedures for the 'confid' attribute are + defined in Section 10. + +5.3. SDP 'userid' Attribute + + This section defines the SDP 'userid' media-level attribute. The + attribute is used by a floor control server to convey the user ID + value to the floor control client, using decimal integer + representation. + + 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 determined by the COMMON-HEADER + format [RFC8855]. + + The SDP Offer/Answer procedures for the 'userid' attribute are + defined in Section 10. + +5.4. SDP 'floorid' Attribute + + This section defines the SDP 'floorid' media-level attribute. The + attribute is used to convey a floor identifier, using decimal integer + representation, and, optionally, pointers to 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 determined by the FLOOR-ID + format [RFC8855]. + + The floor identifier value is the integer representation of the + Floor ID field value [RFC8855] to be used in BFCP. Each media stream + pointer value is associated with an SDP 'label' attribute [RFC4574] + of a media stream. + + The SDP Offer/Answer procedures for the 'floorid' attribute are + defined in Section 10. + + | Note: In the first SDP example in Section 9 of [RFC4583], + | 'm-stream' was erroneously listed. Although the example was + | non-normative, it is implemented by some vendors and occurs in + | cases where the endpoint is willing to act as a server. + | Therefore, it is RECOMMENDED to support parsing and + | interpreting 'm-stream' the same way as 'mstrm' when receiving. + +5.5. SDP 'bfcpver' Attribute + + This section defines the SDP 'bfcpver' media-level attribute. The + attribute is used to negotiate the BFCP version, using decimal + integer representation. + + 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 determined by the COMMON-HEADER + format [RFC8855]. + + An endpoint uses the 'bfcpver' attribute to convey the version(s) of + BFCP supported by the endpoint, using integer values. For a given + version, the attribute value representing the version MUST match the + version ("Ver") field that would be presented in the BFCP + COMMON-HEADER [RFC8855]. The BFCP version that will eventually be + used will be conveyed with a BFCP-level Hello/HelloAck. + + Endpoints compliant with [RFC4583] might not always include the + 'bfcpver' attribute in offers and answers. The attribute value, if + present, MUST be in accordance with the definition of the version + ("Ver") field in [RFC8855]. If the attribute is not present, + endpoints MUST assume a default value in accordance with [RFC8855]: + when used over a reliable transport, the default attribute value is + "1", and when used over an unreliable transport, the default + attribute value is "2". The value is inferred from the transport + specified in the "m=" line (Section 4) of the "m=" section associated + with the stream. + + The SDP Offer/Answer procedures for the 'bfcpver' attribute are + defined in Section 10. + +6. Multiplexing Considerations + + [RFC8843] defines how multiplexing of multiple media streams can be + negotiated. This specification does not define how BFCP streams can + be multiplexed with other media streams. Therefore, a BFCP stream + MUST NOT be associated with a BUNDLE group [RFC8843]. Note that + BFCP-controlled media streams might be multiplexed with other media + streams. + + [RFC8859] defines the mux categories for the SDP attributes defined + in this specification, except for the 'bfcpver' attribute. Table 2 + defines the mux category for the 'bfcpver' attribute: + + +=========+===========================+=======+==============+ + | 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 use TCP or UDP as the underlying transport. + Endpoints exchanging BFCP messages over UDP send the BFCP messages + towards the peer using the connection address and port provided in + the SDP "c=" and "m=" lines. TCP connection management is more + complicated and is described in the following section. + + | Note: When 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 + + The management of the TCP connection used to transport BFCP messages + is performed using the SDP 'setup' and 'connection' attributes + [RFC4145]. The 'setup' attribute indicates which of the endpoints + initiates the TCP connection. The 'connection' attribute handles TCP + connection re-establishment. + + The BFCP specification [RFC8855] describes a number of situations + when the TCP connection between a floor control client and the floor + control server needs to be re-established. However, [RFC8855] does + not describe the re-establishment process, because this process + depends on how the connection was established in the first place. + Endpoints using the offer/answer mechanism follow the following + rules. + + When the existing TCP connection is closed and re-established + following the rules in [RFC8855], the floor control client MUST send + an offer towards the floor control server in order to re-establish + the connection. If a TCP connection cannot deliver a BFCP message + and times out, the endpoint that attempted to send the message (i.e., + the one that detected the TCP timeout) MUST send an offer in order 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 + + When DTLS is used with UDP, the generic procedures defined in + Section 5 of [RFC8842] MUST be followed. + + When TLS is used with TCP, once the underlying connection is + established, the answerer always acts as the TLS server. If the TCP + connection is lost, the active endpoint [RFC4583] is responsible for + re-establishing the TCP connection. Unless a new TLS connection is + negotiated, subsequent SDP offers and answers will not impact the + previously negotiated TLS roles. + + | 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 + + Generic SDP offer/answer procedures for ICE are defined in [RFC8839]. + + When BFCP is used with UDP-based ICE candidates [RFC8445], the + procedures for UDP/TLS/BFCP are used. + + When BFCP is used with TCP-based ICE candidates [RFC6544], the + procedures for TCP/DTLS/BFCP are used. + + Based on the procedures defined in [RFC8842], endpoints treat all ICE + candidate pairs associated with a BFCP stream on top of a DTLS + association as part of the same DTLS association. Thus, there will + only be one BFCP handshake and one DTLS handshake even if there are + multiple valid candidate pairs, and even if BFCP media is shifted + between candidate pairs (including switching between UDP candidate + pairs and TCP candidate pairs) prior to nomination. If new + candidates are added, they will also be part of the same DTLS + association. + + In order to maximize the likelihood of interoperability between the + endpoints, all ICE-enabled BFCP-over-DTLS endpoints SHOULD implement + support for UDP/TLS/BFCP. + + When an SDP offer or answer conveys multiple ICE candidates for a + BFCP stream, UDP-based candidates SHOULD be included and the default + candidate SHOULD be chosen from one of those UDP candidates. If UDP + transport is used for the default candidate, then the "m=" line proto + value MUST be 'UDP/TLS/BFCP'. If TCP transport is used for the + default candidate, 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 defines the SDP offer/answer [RFC3264] procedures for + negotiating and establishing a BFCP stream. Generic procedures for + DTLS are defined in [RFC8842]. Generic procedures for TLS are + defined in [RFC8122]. + + This section only defines the BFCP-specific procedures. Unless + explicitly stated otherwise, the procedures apply to an "m=" section + describing a BFCP stream. If an offer or answer contains multiple + "m=" sections describing BFCP streams, the procedures are applied + independently to each stream. + + Within this document, 'initial offer' refers to the first offer + within an SDP session (e.g., a Session Initiation Protocol (SIP) + dialog when SIP [RFC3261] is used to carry SDP) in which the offerer + indicates that it wants to negotiate the establishment of 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 defined 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 according to 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 according to 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 creates 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. + + In addition, if the offerer includes 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 receives an offer that contains an "m=" section + describing a BFCP stream, the answerer MUST check whether it supports + one or more of the BFCP versions supported by the offerer + (Section 5.5). If the answerer does not support any of the BFCP + 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 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. + + In addition, if the answerer includes 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 corresponding + "m=" section in the answer. In addition, the answerer MUST NOT + establish a TCP connection or a TLS/DTLS connection associated with + the "m=" section. + +10.3. Offerer Processing of the SDP Answer + + When the offerer receives an answer that contains an "m=" section + describing a BFCP stream and with 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 contains a zero port value or if the + offerer for some other reason does not accept the answer (e.g., if + the answerer only indicates support of BFCP versions not supported by + the offerer), 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, in order to modify a + previously established BFCP stream, it follows the procedures in + Section 10.1, with the following exceptions: + + * If the BFCP stream is carried on top of TCP and if the offerer + does not want to re-establish an existing TCP connection, the + offerer MUST include in the "m=" section an SDP 'connection' + attribute with a value of "existing", and + + * If the offerer wants to disable a previously established BFCP + stream, it MUST assign a zero port value to the "m=" line + associated with the BFCP connection, following the procedures in + [RFC3264]. + +11. Examples + + For the purpose of brevity, the main portion of the session + description is omitted in the examples, which only show "m=" sections + and their "m=" lines and attributes. + + The following is an example of an offer sent by a conference server + 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 that 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. + + The following is the answer returned by the client. + + 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 using an unreliable transport and DTLS is shown + below, where the offer is sent 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 + + The following is the answer returned by the server. + + 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 + + The BFCP specification [RFC8855], SDP specification [RFC8866], and + offer/answer specification [RFC3264] discuss security issues related + to BFCP, SDP, and offer/answer, respectively. In addition, [RFC4145] + and [RFC8122] discuss security issues related to the establishment of + TCP and TLS connections using an offer/answer model. Furthermore, + when using DTLS over UDP, the generic offer/answer considerations + defined in [RFC8842] MUST be followed. + + The usage of certain proto values in the SDP offer/answer negotiation + will result in a BFCP stream that is not protected by TLS or DTLS. + Operators will need to provide integrity protection and + confidentiality protection of the BFCP stream using other means. + + The generic security considerations associated with SDP attributes + are defined in [RFC3264]. While the attributes defined in this + specification do not reveal information about the content of + individual BFCP-controlled media streams, they do reveal which media + streams will be BFCP controlled. + +13. IANA Considerations + + This document registers three new values in the "proto" subregistry + within the "Session Description Protocol (SDP) Parameters" registry: + 'TCP/DTLS/BFCP', 'UDP/BFCP', and 'UDP/TLS/BFCP' (see Section 13.1). + + This document also registers a new SDP attribute in the 'attribute- + name (formerly "att-field")' subregistry within the "Session + Description Protocol (SDP) Parameters" registry: 'bfcpver' (see + Section 5.5). + + The remaining values are unchanged from [RFC4582], except that the + references have been updated to refer to this document. + +13.1. Registration of SDP 'proto' Values + + The IANA has 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 document defines the SDP 'floorctrl' attribute. Details + regarding this attribute are provided in Section 5.1. + +13.3. Registration of the SDP 'confid' Attribute + + This document defines the SDP 'confid' attribute. Details regarding + this attribute are provided in Section 5.2. + +13.4. Registration of the SDP 'userid' Attribute + + This document defines the SDP 'userid' attribute. Details regarding + this attribute are provided in Section 5.3. + +13.5. Registration of the SDP 'floorid' Attribute + + This document defines the SDP 'floorid' attribute. Details regarding + this attribute are provided in Section 5.4. + +13.6. Registration of the SDP 'bfcpver' Attribute + + This document defines the SDP 'bfcpver' attribute. Details regarding + this attribute are provided in Section 5.5. + +14. Changes from RFC 4583 + + The technical changes and other fixes from [RFC4583] are listed + below. + + The main purpose of this work was to add signaling support necessary + to support BFCP over an unreliable transport, as described in + [RFC8855], resulting in the following changes: + + * Fields in the "m=" Line (Section 4): + + This section has been rewritten to remove reference to the + exclusivity of TCP as a transport for BFCP streams. The proto + field values 'TCP/DTLS/BFCP', 'UDP/BFCP', and 'UDP/TLS/BFCP' have + been added. + + * Security Considerations (Section 12): + + For the DTLS-over-UDP case, we direct the reader to existing + considerations and requirements for the offer/answer exchange as + provided in [RFC8842]. + + * Registration of SDP 'proto' Values (Section 13.1): + + This document 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 has been added, in order + to signal the supported version number. + + In addition to the changes associated with support of BFCP over an + unreliable transport, the possibility that an endpoint can act as + both a floor control client and a floor control server at the same + time has been removed. An endpoint will now take 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): + + Do not use language such as 'used in an "m=" line' when discussing + an SDP attribute; instead, make clear that the attribute is a + media-level attribute. + + * Spelling corrected in the first SDP example in Section 9 of + [RFC4583]: + + Do not use 'm-stream' as listed in the first SDP example in + [RFC4583]; instead, use the correct 'mstrm' as specified in + Section 11 of this document. However, we recommend continuing to + interpret 'm-stream', if received, because it is still present in + some implementations. + + * Assorted clarifications (throughout the document): + + Language clarifications were made as a result of reviews. Also, + normative language was "tightened" where appropriate, i.e., + changed from "SHOULD" strength to "MUST" in a number 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 + + Jörg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and + Oscar Novo provided useful ideas for the original [RFC4583]. The + authors also acknowledge contributions to the revision of BFCP for + use over an unreliable transport from Geir Arne Sandbakken, Charles + Eckel, Alan Ford, Eoin McLeod, and Mark Thompson. Useful and + important final reviews were done by Ali C. Begen, Mary Barnes, and + Charles Eckel. In the final stages, Roman Shpount made a + considerable effort in adding proper ICE support and considerations. + +Authors' Addresses + + 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 |