< draft-ietf-bfcpbis-rfc4583bis-26.txt   draft-ietf-bfcpbis-rfc4583bis-27.txt >
BFCPbis Working Group G. Camarillo BFCPbis Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: 4583 (if approved) T. Kristensen Obsoletes: 4583 (if approved) T. Kristensen
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: April 5, 2019 C. Holmberg Expires: June 11, 2019 C. Holmberg
Ericsson Ericsson
October 2, 2018 December 8, 2018
Session Description Protocol (SDP) Format for Binary Floor Control Session Description Protocol (SDP) Format for Binary Floor Control
Protocol (BFCP) Streams Protocol (BFCP) Streams
draft-ietf-bfcpbis-rfc4583bis-26 draft-ietf-bfcpbis-rfc4583bis-27
Abstract Abstract
This document defines the Session Description Protocol (SDP) offer/ This document defines the Session Description Protocol (SDP) offer/
answer procedures for negotiating and establishing Binary Floor answer procedures for negotiating and establishing Binary Floor
Control Protocol (BFCP) streams. Control Protocol (BFCP) streams.
This document obsoletes RFC 4583. Changes from RFC 4583 are This document obsoletes RFC 4583. Changes from RFC 4583 are
summarized in Section 14. summarized in Section 14.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 5, 2019. This Internet-Draft will expire on June 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Floor Control Roles . . . . . . . . . . . . . . . . . . . . . 4 3. Floor Control Roles . . . . . . . . . . . . . . . . . . . . . 4
4. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . 4 4. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . 4
5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 5 5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. SDP 'floorctrl' Attribute . . . . . . . . . . . . . . . . 5 5.1. SDP 'floorctrl' Attribute . . . . . . . . . . . . . . . . 5
5.2. SDP 'confid' Attributes . . . . . . . . . . . . . . . . . 7 5.2. SDP 'confid' Attribute . . . . . . . . . . . . . . . . . 7
5.3. SDP 'userid' Attribute . . . . . . . . . . . . . . . . . 8 5.3. SDP 'userid' Attribute . . . . . . . . . . . . . . . . . 8
5.4. SDP 'floorid' Attribute . . . . . . . . . . . . . . . . . 8 5.4. SDP 'floorid' Attribute . . . . . . . . . . . . . . . . . 9
5.5. SDP 'bfcpver' Attribute . . . . . . . . . . . . . . . . . 9 5.5. SDP 'bfcpver' Attribute . . . . . . . . . . . . . . . . . 10
6. Multiplexing Considerations . . . . . . . . . . . . . . . . . 10 6. Multiplexing Considerations . . . . . . . . . . . . . . . . . 11
7. BFCP Connection Management . . . . . . . . . . . . . . . . . 10 7. BFCP Connection Management . . . . . . . . . . . . . . . . . 12
7.1. TCP Connection Management . . . . . . . . . . . . . . . . 11 7.1. TCP Connection Management . . . . . . . . . . . . . . . . 12
8. TLS/DTLS Considerations . . . . . . . . . . . . . . . . . . . 11 8. TLS/DTLS Considerations . . . . . . . . . . . . . . . . . . . 13
9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 10. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 14
10.1. Generating the Initial SDP Offer . . . . . . . . . . . . 13 10.1. Generating the Initial SDP Offer . . . . . . . . . . . . 15
10.2. Generating the SDP Answer . . . . . . . . . . . . . . . 13 10.2. Generating the SDP Answer . . . . . . . . . . . . . . . 15
10.3. Offerer Processing of the SDP Answer . . . . . . . . . . 15 10.3. Offerer Processing of the SDP Answer . . . . . . . . . . 16
10.4. Modifying the Session . . . . . . . . . . . . . . . . . 15 10.4. Modifying the Session . . . . . . . . . . . . . . . . . 17
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
13.1. Registration of SDP 'proto' Values . . . . . . . . . . . 18 13.1. Registration of SDP 'proto' Values . . . . . . . . . . . 20
13.2. Registration of the SDP 'floorctrl' Attribute . . . . . 18 13.2. Registration of the SDP 'floorctrl' Attribute . . . . . 20
13.3. Registration of the SDP 'confid' Attribute . . . . . . . 18 13.3. Registration of the SDP 'confid' Attribute . . . . . . . 20
13.4. Registration of the SDP 'userid' Attribute . . . . . . . 18 13.4. Registration of the SDP 'userid' Attribute . . . . . . . 20
13.5. Registration of the SDP 'floorid' Attribute . . . . . . 19 13.5. Registration of the SDP 'floorid' Attribute . . . . . . 21
13.6. Registration of the SDP 'bfcpver' Attribute . . . . . . 19 13.6. Registration of the SDP 'bfcpver' Attribute . . . . . . 21
14. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 19 14. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 21
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
16.1. Normative References . . . . . . . . . . . . . . . . . . 20 16.1. Normative References . . . . . . . . . . . . . . . . . . 22
16.2. Informational References . . . . . . . . . . . . . . . . 22 16.2. Informational References . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
As discussed in the BFCP (Binary Floor Control Protocol) As discussed in the BFCP (Binary Floor Control Protocol)
specification [I-D.ietf-bfcpbis-rfc4582bis], a given BFCP client specification [I-D.ietf-bfcpbis-rfc4582bis], a given BFCP client
needs a set of data in order to establish a BFCP connection to a needs a set of data in order to establish a BFCP connection to a
floor control server. This data includes the transport address of floor control server. This data includes the transport address of
the server, the conference identifier, and the user identifier. the server, the conference identifier, and the user identifier.
One way for clients to obtain this information is to use an SDP One way for clients to obtain this information is to use an SDP
skipping to change at page 4, line 9 skipping to change at page 4, line 9
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Floor Control Roles 3. Floor Control Roles
When two endpoints establish a BFCP stream, they need to determine 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 which of them acts as a floor control client and which acts as a
floor control server. Typically, a client that establishes a BFCP floor control server.
stream with a conference server will act as a floor control client,
while the conference server will act as a floor control server.
Once the roles have been determined, the roles will apply to all Once the roles have been determined, the roles will apply to all
BFCP-controlled streams associated with the BFCP stream. BFCP-controlled streams associated with the BFCP stream.
4. Fields in the 'm' Line 4. Fields in the 'm' Line
This section describes how to generate an 'm' line for a BFCP stream.
According to the SDP specification [RFC4566], the 'm' line format is According to the SDP specification [RFC4566], the 'm' line format is
the following: the following:
m=<media> <port> <proto> <fmt> ... 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". The media field MUST have a value of "application".
The port field is set depending on the value of the proto field, as The port field is set depending on the value of the proto field, as
explained below. A port field value of zero has the standard SDP explained below. A port field value of zero has the standard SDP
meaning (i.e., rejection of the media stream) regardless of the proto meaning (i.e., rejection of the media stream) regardless of the proto
field. field.
When TCP is used as the transport, the port field is set following When TCP is used as the transport, the port field is set following
the rules in [RFC4145]. Depending on the value of the 'setup' the rules in [RFC4145]. Depending on the value of the 'setup'
attribute (discussed in Section 7.1), the port field contains the attribute (discussed in Section 7.1), the port field contains the
skipping to change at page 5, line 29 skipping to change at page 5, line 29
in [RFC4571], with DTLS packets being sent and received instead of in [RFC4571], with DTLS packets being sent and received instead of
RTP/RTCP packets using the shim defined in RFC 4571 such that the RTP/RTCP packets using the shim defined in RFC 4571 such that the
length field defined in RFC 4571 precedes each DTLS message. This 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 is one of the options when ICE is used (Section 9). It can also
be used without ICE when backward compatibility with RFC 4583 be used without ICE when backward compatibility with RFC 4583
compliant endpoints is not required. compliant endpoints is not required.
The fmt (format) list is not applicable to BFCP. The fmt list of 'm' 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 lines in the case of any proto field value related to BFCP MUST
contain a single "*" character. If the the fmt list contains any contain a single "*" character. If the the fmt list contains any
other value it is ignored. other value it MUST be ignored.
The following is an example of an 'm' line for a BFCP connection: The following is an example of an 'm' line for a BFCP connection:
m=application 50000 TCP/TLS/BFCP * m=application 50000 TCP/TLS/BFCP *
5. SDP Attributes 5. SDP Attributes
5.1. SDP 'floorctrl' Attribute 5.1. SDP 'floorctrl' Attribute
This section defines the SDP 'floorctrl' media-level attribute. The This section defines the SDP 'floorctrl' media-level attribute. The
skipping to change at page 6, line 30 skipping to change at page 6, line 30
An endpoint includes the attribute to indicate the role(s) it would An endpoint includes the attribute to indicate the role(s) it would
be willing to perform for the BFCP-controlled media streams: be willing to perform for the BFCP-controlled media streams:
c-only: The endpoint is willing to act as floor control client. c-only: The endpoint is willing to act as floor control client.
s-only: The endpoint is willing to act as floor control server only. s-only: The endpoint is willing to act as floor control server only.
When inserted in an offer, the offerer MAY indicate multiple When inserted in an offer, the offerer MAY indicate multiple
attribute values ("c-only" and "s-only"). When inserted in an attribute values ("c-only" and "s-only"). When inserted in an
answer, the answerer MUST indicate only one attribute value: "c-only" answer, the answerer MUST indicate only one attribute value: "c-only"
or "s-only". The offerer indicates which floor control role(s) that or "s-only". The answerer indicates the role taken by the answerer.
it is willing to take. The answerer indicates the role taken by the The offerer will then take the opposite role.
answerer. Based on this, the floor control role of the offerer is
determined, as shown in Table 1.
+---------+----------+
| Offerer | Answerer |
+---------+----------+
| c-only | s-only |
| s-only | c-only |
| c-s | c-only |
| c-s | s-only |
+---------+----------+
Table 1: Roles
In [RFC4583], there was a third attribute specified, "c-s", which In [RFC4583], there was a third attribute specified, "c-s", which
meant that an endpoint was willing to act as both floor control meant that an endpoint was willing to act as both floor control
client and floor control server at the same time for the BFCP stream, client and floor control server at the same time for the BFCP stream,
taking different roles for different BFCP-controlled media streams. taking different roles for different BFCP-controlled media streams.
The feature was underspecified and implemented in different ways, in The feature was underspecified and implemented in different ways, in
particular many implementations interpreted "c-s" to mean that the particular many implementations interpreted "c-s" to mean that the
endpoint is willing to act as either client or server (equivalent to endpoint is willing to act as either client or server (equivalent to
"c-only s-only"). An implementation compliant to this specification "c-only s-only"). An implementation compliant to this specification
MUST NOT include the "c-s" floorctl attribute value in an offer or in MUST NOT include the "c-s" floorctl attribute value in an offer or in
an answer, but MUST accept the attribute value in an offer and 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"). As process it as equivalent to "c-only s-only" (or "s-only c-only").
a result, each endpoint will take the same role for each BFCP- Also, as an implementation compliant to this specification is only
controlled media stream associated with the BFCP stream. allowed to include one role, either 'c-only' or 's-conly', 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' Endpoints compliant with [RFC4583] might not include the 'floorctrl'
attribute in offers and answerer. If the 'floorctrl' attribute is attribute in offers and answerer. If the 'floorctrl' attribute is
not present the offerer will act as floor control client, and the not present, in order to be interoperable with such endpoints, the
answerer will act as floor control server. offerer will act as floor control client and the answerer will act as
floor control server.
The SDP Offer/Answer procedures for the 'floorctrl' attribute are The SDP Offer/Answer procedures for the 'floorctrl' attribute are
defined in Section 10. defined in Section 10.
The following is an example of a 'floorctrl' attribute in an offer: The following is an example of a 'floorctrl' attribute in an offer:
a=floorctrl:c-only s-only a=floorctrl:c-only s-only
5.2. SDP 'confid' Attributes 5.2. SDP 'confid' Attribute
This section defines the SDP 'confid' media-level attribute. The This section defines the SDP 'confid' media-level attribute. The
attribute is used by a floor control server to convey the conference attribute is used by a floor control server to convey the conference
ID value to the floor control client, using decimal integer ID value to the floor control client, using decimal integer
representation. representation.
Attribute Name: confid Attribute Name: confid
Attribute Value: conference-id Attribute Value: conference-id
skipping to change at page 7, line 46 skipping to change at page 8, line 21
Charset Dependent: No Charset Dependent: No
Mux Category: TBD Mux Category: TBD
The Augmented BNF syntax [RFC5234] for the attribute is: The Augmented BNF syntax [RFC5234] for the attribute is:
conference-id = 1*DIGIT conference-id = 1*DIGIT
DIGIT = <DIGIT defined in [RFC5234]> DIGIT = <DIGIT defined in [RFC5234]>
The maximum value of the attribute is determined by the
COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis].
The SDP Offer/Answer procedures for the 'confid' attribute are The SDP Offer/Answer procedures for the 'confid' attribute are
defined in Section 10. defined in Section 10.
5.3. SDP 'userid' Attribute 5.3. SDP 'userid' Attribute
This section defines the SDP userid' media-level attribute. The This section defines the SDP userid' media-level attribute. The
attribute is used by a floor control server to convey the user ID attribute is used by a floor control server to convey the user ID
value to the floor control client, using decimal integer value to the floor control client, using decimal integer
representation. representation.
skipping to change at page 8, line 28 skipping to change at page 9, line 21
Charset Dependent: No Charset Dependent: No
Mux Category: TBD Mux Category: TBD
The Augmented BNF syntax [RFC5234] for the attribute is: The Augmented BNF syntax [RFC5234] for the attribute is:
user-id = 1*DIGIT user-id = 1*DIGIT
DIGIT = <DIGIT defined in [RFC5234]> DIGIT = <DIGIT defined in [RFC5234]>
The maximum value of the attribute is determined by the
COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis].
The SDP Offer/Answer procedures for the 'userid' attribute are The SDP Offer/Answer procedures for the 'userid' attribute are
defined in Section 10. defined in Section 10.
5.4. SDP 'floorid' Attribute 5.4. SDP 'floorid' Attribute
This section defines the SDP 'floorid' media-level attribute. The This section defines the SDP 'floorid' media-level attribute. The
attribute conveys a floor identifier, and optionally pointers to one attribute conveys a floor identifier, using decimal integer
or more BFCP-controlled media streams. representation, and optionally pointers to one or more BFCP-
controlled media streams.
Attribute Name: floorid Attribute Name: floorid
Attribute Value: floor-id Attribute Value: floor-id
Usage Level: media Usage Level: media
Charset Dependent: No Charset Dependent: No
Mux Category: TBD Mux Category: TBD
The Augmented BNF syntax [RFC5234] for the attribute is: The Augmented BNF syntax [RFC5234] for the attribute is:
floor-id = 1*DIGIT SP "mstrm:" token *(SP token) floor-id = 1*DIGIT SP "mstrm:" token *(SP token)
DIGIT = <DIGIT defined in [RFC5234]> DIGIT = <DIGIT defined in [RFC5234]>
token = <token defined in [RFC4566]> token = <token defined in [RFC4566]>
The maximum value of the attribute is determined by the
FLOOR-ID format [I-D.ietf-bfcpbis-rfc4582bis].
The floor identifier value is the integer representation of the Floor The floor identifier value is the integer representation of the Floor
ID to be used in BFCP. Each media stream pointer value is associated ID to be used in BFCP. Each media stream pointer value is associated
with an SDP 'label' attribute [RFC4574] of a media stream. with an SDP 'label' attribute [RFC4574] of a media stream.
The SDP Offer/Answer procedures for the 'floorid' attribute are The SDP Offer/Answer procedures for the 'floorid' attribute are
defined in Section 10. defined in Section 10.
Note: In [RFC4583] 'm-stream' was erroneously used in Section 11. Note: In [RFC4583] 'm-stream' was erroneously used in Section 11.
Although the example was non-normative, it is implemented by some Although the example was non-normative, it is implemented by some
vendors and occurs in cases where the endpoint is willing to act vendors and occurs in cases where the endpoint is willing to act
as a server. Therefore, it is RECOMMENDED to support parsing and as a server. Therefore, it is RECOMMENDED to support parsing and
interpreting 'm-stream' the same way as 'mstrm' when receiving. interpreting 'm-stream' the same way as 'mstrm' when receiving.
5.5. SDP 'bfcpver' Attribute 5.5. SDP 'bfcpver' Attribute
This section defines the SDP 'bfcpver' media-level attribute. The This section defines the SDP 'bfcpver' media-level attribute. The
attribute is used to negotiate the BFCP version. attribute is used to negotiate the BFCP version, using decimal
integer representation.
The Augmented BNF syntax [RFC5234] for the attributes is: The Augmented BNF syntax [RFC5234] for the attributes is:
Attribute Name: bfcpver Attribute Name: bfcpver
Attribute Value: bfcp-version Attribute Value: bfcp-version
Usage Level: media Usage Level: media
Charset Dependent: No Charset Dependent: No
Mux Category: TBD Mux Category: TBD
The Augmented BNF syntax [RFC5234] for the attribute is: The Augmented BNF syntax [RFC5234] for the attribute is:
bfcp-version = version *(SP version) bfcp-version = version *(SP version)
version = 1*DIGIT version = 1*DIGIT
DIGIT = <DIGIT defined in [RFC5234]> DIGIT = <DIGIT defined in [RFC5234]>
The maximum value of the attribute is determined by the
COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis].
An endpoint uses the 'bfcpver' attribute to convey the version(s) of An endpoint uses the 'bfcpver' attribute to convey the version(s) of
BFCP supported by the endpoint, using integer values. For a given BFCP supported by the endpoint, using integer values. For a given
version, the attribute value representing the version MUST match the version, the attribute value representing the version MUST match the
"Version" field that would be presented in the BFCP COMMON-HEADER "Version" field that would be presented in the BFCP COMMON-HEADER
[I-D.ietf-bfcpbis-rfc4582bis]. The BFCP version that will eventually [I-D.ietf-bfcpbis-rfc4582bis]. The BFCP version that will eventually
be used will be conveyed with a BFCP-level Hello/HelloAck. be used will be conveyed with a BFCP-level Hello/HelloAck.
Endpoints compliant with [RFC4583] might not always include the Endpoints compliant with [RFC4583] might not always include the
'bfcpver' attribute in offers and answers. The attribute value, if 'bfcpver' attribute in offers and answers. The attribute value, if
present, MUST be in accordance with the definition of the Version present, MUST be in accordance with the definition of the Version
field in [I-D.ietf-bfcpbis-rfc4582bis]. If the attribute is not field in [I-D.ietf-bfcpbis-rfc4582bis]. If the attribute is not
present, endpoints MUST assume a default value in accordance with present, endpoints MUST assume a default value in accordance with
[I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport [I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport
the default attribute value is "1", and when used over an unreliable the default attribute value is "1", and when used over an unreliable
transport the default attribute value is "2". The value is inferred transport the default attribute value is "2". The value is inferred
from the transport specified in the 'm' line (Section 4) associated from the transport specified in the 'm' line (Section 4) of the 'm'
with the stream. section associated with the stream.
The SDP Offer/Answer procedures for the 'bfcpver' attribute are The SDP Offer/Answer procedures for the 'bfcpver' attribute are
defined in Section 10. defined in Section 10.
6. Multiplexing Considerations 6. Multiplexing Considerations
[I-D.ietf-mmusic-sdp-bundle-negotiation] defines how multiplexing of [I-D.ietf-mmusic-sdp-bundle-negotiation] defines how multiplexing of
multiple media streams can be negotiated. This specification does multiple media streams can be negotiated. This specification does
not define how BFCP streams can be multiplexed with other media not define how BFCP streams can be multiplexed with other media
streams. Therefore, a BFCP stream MUST NOT be associated with a streams. Therefore, a BFCP stream MUST NOT be associated with a
BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation]. Note that BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation]. Note that
BFCP-controlled media streams might be multiplexed with other media BFCP-controlled media streams might be multiplexed with other media
streams. streams.
[I-D.ietf-mmusic-sdp-mux-attributes] defines the mux categories for [I-D.ietf-mmusic-sdp-mux-attributes] defines the mux categories for
the SDP attributes defined in this specification. Table 2 defines the SDP attributes defined in this specification, except for the
the mux category for the 'bfcpver' attribute: 'bfcpver' attribute. Table 2 defines the mux category for the
'bfcpver' attribute:
+---------+-------------------------------------+-------+-----------+ +---------+-------------------------------------+-------+-----------+
| Name | Notes | Level | Mux | | Name | Notes | Level | Mux |
| | | | Category | | | | | Category |
+---------+-------------------------------------+-------+-----------+ +---------+-------------------------------------+-------+-----------+
| bfcpver | Needs further analysis in a | M | TBD | | bfcpver | Needs further analysis in a | M | TBD |
| | separate specification | | | | | separate specification | | |
+---------+-------------------------------------+-------+-----------+ +---------+-------------------------------------+-------+-----------+
Table 2: Multiplexing Attribute Analysis Table 2: Multiplexing Attribute Analysis
7. BFCP Connection Management 7. BFCP Connection Management
BFCP streams can use TCP or UDP as the underlying transport. BFCP streams can use TCP or UDP as the underlying transport.
Endpoints exchanging BFCP messages over UDP send the BFCP messages Endpoints exchanging BFCP messages over UDP send the BFCP messages
towards the peer using the connection address and port provided in towards the peer using the connection address and port provided in
the SDP 'c' and 'm' lines. TCP connection management is more the SDP 'c' and 'm' lines. TCP connection management is more
complicated and is described in the following Section. complicated and is described in the following Section.
Note: When using Interactive Connectivity Establishment (ICE) Note: When using Interactive Connectivity Establishment (ICE)
[RFC8445], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward [RFC8445], TCP/DTLS/BFCP, or UDP/TLS/BFCP, the straight-forward
procedures for connection management as UDP/BFCP described above procedures for connection management as UDP/BFCP described above
apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and
is described below. is described below.
7.1. TCP Connection Management 7.1. TCP Connection Management
The management of the TCP connection used to transport BFCP messages The management of the TCP connection used to transport BFCP messages
is performed using the SDP 'setup' and 'connection' attributes is performed using the SDP 'setup' and 'connection' attributes
[RFC4145]. The 'setup' attribute indicates which of the endpoints [RFC4145]. The 'setup' attribute indicates which of the endpoints
initiates the TCP connection. The 'connection' attribute handles TCP initiates the TCP connection. The 'connection' attribute handles TCP
skipping to change at page 11, line 39 skipping to change at page 13, line 23
Endpoints that use the offer/answer mechanism to negotiate TCP Endpoints that use the offer/answer mechanism to negotiate TCP
connections MUST support the 'setup' and 'connection' attributes. connections MUST support the 'setup' and 'connection' attributes.
8. TLS/DTLS Considerations 8. TLS/DTLS Considerations
When DTLS is used with UDP, the generic procedures defined in When DTLS is used with UDP, the generic procedures defined in
Section 5 of [I-D.ietf-mmusic-dtls-sdp] MUST be followed. Section 5 of [I-D.ietf-mmusic-dtls-sdp] MUST be followed.
When TLS is used with TCP, once the underlying connection is When TLS is used with TCP, once the underlying connection is
established, the answerer always acts as the TLS server. If the TCP established, the answerer always acts as the TLS server. If the TCP
connection is lost, the active endpoint is responsible for re- connection is lost, the active endpoint [RFC4583] is responsible for
establishing the TCP connection. Unless a new TLS session is re-establishing the TCP connection. Unless a new TLS connection is
negotiated, subsequent SDP offers and answers will not impact the negotiated, subsequent SDP offers and answers will not impact the
previously negotiated TLS roles. previously negotiated TLS roles.
Note: For TLS, it was decided to keep the original procedures in Note: For TLS, it was decided to keep the original procedures in
[RFC4583] to determine which endpoint acts as the TLS server in [RFC4583] to determine which endpoint acts as the TLS server in
order to retain backwards compatibility. order to retain backwards compatibility.
9. ICE Considerations 9. ICE Considerations
Generic SDP offer/answer procedures for Interactive Connectivity Generic SDP offer/answer procedures for Interactive Connectivity
skipping to change at page 12, line 42 skipping to change at page 14, line 27
TCP/DTLS/BFCP is outside of scope for this specification. TCP/DTLS/BFCP is outside of scope for this specification.
10. SDP Offer/Answer Procedures 10. SDP Offer/Answer Procedures
This section defines the SDP offer/answer [RFC3264] procedures for This section defines the SDP offer/answer [RFC3264] procedures for
negotiating and establishing a BFCP stream. Generic procedures for negotiating and establishing a BFCP stream. Generic procedures for
DTLS are defined in [I-D.ietf-mmusic-dtls-sdp]. Generic procedures DTLS are defined in [I-D.ietf-mmusic-dtls-sdp]. Generic procedures
for TLS are defined in [RFC8122]. for TLS are defined in [RFC8122].
This section only defines the BFCP-specific procedures. Unless This section only defines the BFCP-specific procedures. Unless
explicitly stated otherwise, the procedures apply to an 'm' line explicitly stated otherwise, the procedures apply to an 'm' section
describing a BFCP stream. If an offer or answer contains multiple describing a BFCP stream. If an offer or answer contains multiple
'm' lines describing BFCP streams, the procedures are applied 'm' sections describing BFCP streams, the procedures are applied
independently to each stream. independently to each stream.
Within this document, 'initial offer' refers to the first offer, Within this document, 'initial offer' refers to the first offer,
within an SDP session (e.g. a SIP dialog when the Session Initiation within an SDP session (e.g. a SIP dialog when the Session Initiation
Protocol (SIP) [RFC3261] is used to carry SDP), in which the offerer Protocol (SIP) [RFC3261] is used to carry SDP) in which the offerer
indicates that it wants to negotiate the establishment of a BFCP indicates that it wants to negotiate the establishment of a BFCP
stream. stream.
If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or
'UDP/TLS/BFCP', the offerer and answerer follow the generic 'UDP/TLS/BFCP', the offerer and answerer follow the generic
procedures defined in [RFC8122]. procedures defined in [RFC8122].
If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/ 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' TCP' or 'UDP/TLS/BFCP', the offerer and answerer use the SDP 'setup'
attribute according to the procedures in [RFC4145]. attribute according to the procedures in [RFC4145].
If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or
'TCP/DTLS/BFCP', the offerer and anwerer use the SDP 'connection' 'TCP/DTLS/BFCP', the offerer and anwerer use the SDP 'connection'
attribute according to the procedures in [RFC4145]. attribute according to the procedures in [RFC4145].
Note: The use of source-specific SDP parameters [RFC5576] is not Note: The use of source-specific SDP parameters [RFC5576] is not
defined for BFCP streams. defined for BFCP streams.
10.1. Generating the Initial SDP Offer 10.1. Generating the Initial SDP Offer
When the offerer creates an initial offer, the offerer MUST associate When the offerer creates an initial offer, the offerer MUST include
an SDP 'floorctrl' attribute (Section 5.1) and an SDP 'bfcpver' an SDP 'floorctrl' attribute (Section 5.1) and an SDP 'bfcpver'
attribute (Section 5.5) with the 'm' line. attribute (Section 5.5) in the 'm' section.
In addition, if the offerer includes an SDP 'floorctrl' attribute In addition, if the offerer includes an SDP 'floorctrl' attribute
with 's-only' or 'c-s' attribute values in the offer, the offerer: with 's-only' or 'c-s' attribute values in the offer, the offerer:
o MUST associate an SDP 'confid' attribute (Section 5.2) with the o MUST include an SDP 'confid' attribute (Section 5.2) in the 'm'
'm' line; and section; and
o MUST associate an SDP 'userid' attribute (Section 5.3) with the o MUST include an SDP 'userid' attribute (Section 5.3) in the 'm'
'm' line; and section; and
o MUST associate an SDP 'floorid' attribute (Section 5.4) with the o MUST include an SDP 'floorid' attribute (Section 5.4) in the 'm'
'm' line; and section; and
o MUST associate an SDP 'label' attribute ([RFC4574]) with the 'm' o MUST include an SDP 'label' attribute ([RFC4574]) with the 'm'
line of each BFCP-controlled media stream. section of each BFCP-controlled media stream.
Note: If the offerer includes an SDP 'floorctrl' attribute with a Note: If the offerer includes an SDP 'floorctrl' attribute with a
'c-s' attribute value, or both a 'c-only' and a 's-only' attribute 'c-s' attribute value, or both a 'c-only' and a 's-only' attribute
value, in the offer, the attribute values above will only be used 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 if it is determined (Section 5.1) that the offerer will act as
floor control server. floor control server.
10.2. Generating the SDP Answer 10.2. Generating the SDP Answer
When the answerer receives an offer that contains an 'm' line When the answerer receives an offer that contains an 'm' section
describing a BFCP stream, the answerer MUST check whether it supports describing a BFCP stream, the answerer MUST check whether it supports
one or more of the BFCP versions supported by the offerer one or more of the BFCP versions supported by the offerer
(Section 5.5). If the answerer does not support any of the BFCP (Section 5.5). If the answerer does not support any of the BFCP
versions, it MUST NOT accept the 'm' line. Otherwise, if the versions, it MUST NOT accept the 'm' section. Otherwise, if the
answerer accepts the 'm' line, it: answerer accepts the 'm' section, it:
o MUST insert a corresponding 'm' line in the answer, with an o MUST insert a corresponding 'm' section in the answer, with an
identical 'm' line proto value [RFC3264]; and identical 'm' line proto value [RFC3264]; and
o MUST associate a 'bfcpver' attribute with the 'm' line. The o MUST include a 'bfcpver' attribute in the 'm' section. The
answerer only indicates support of BFCP versions also supported by versions indicated by the answer MUST be the same or a subset of
the offerer; and the versions indicated by the offerer in the corresponding offer;
and
o MUST, if the offer contained an SDP 'floorctrl' attribute, o MUST, if the offer contained an SDP 'floorctrl' attribute, include
associate a 'floorctrl' attribute with the 'm' line. a 'floorctrl' attribute in the 'm' section.
In addition, if the answerer includes an SDP 'floorctrl' attribute In addition, if the answerer includes an SDP 'floorctrl' attribute
with an 's-only' attribute value in the answer, the answerer: with an 's-only' attribute value in the answer, the answerer:
o MUST associate an SDP 'confid' attribute with the 'm' line; and o MUST include an SDP 'confid' attribute in the 'm' section; and
o MUST associate an SDP 'userid' attribute with the 'm' line; and o MUST include an SDP 'userid' attribute in the 'm' section; and
o MUST associate an SDP 'floorid' attribute with the 'm' line; and o MUST include an SDP 'floorid' attribute in the 'm' section; and
o MUST associate an SDP 'label' attribute with the 'm' line of each o MUST include an SDP 'label' attribute in the 'm' section of each
BFCP-controlled media stream. BFCP-controlled media stream.
Note: An offerer compliant with [RFC4583] might not include Note: An offerer compliant with [RFC4583] might not include
'floorctrl' and 'bfcpver' attributes in offers, in which cases the 'floorctrl' and 'bfcpver' attributes in offers, in which cases the
default values apply. default values apply.
Once the answerer has sent the answer, the answerer: Once the answerer has sent the answer, the answerer:
o MUST, if the answerer is the 'active' endpoint, and if a TCP o MUST, if the answerer is the active endpoint, and if a TCP
connection associated with the 'm' line is to be established (or connection associated with the 'm' section is to be established
re-established), initiate the establishing of the TCP connection; (or re-established), initiate the establishing of the TCP
and connection; and
o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS o MUST, if the answerer is the active endpoint, and if an TLS/DTLS
connection associated with the 'm' line is to be established (or connection associated with the 'm' section is to be established
re-established), initiate the establishing of the TLS/DTLS (or re-established), initiate the establishing of the TLS/DTLS
connection (by sending a ClientHello message). connection (by sending a ClientHello message).
If the answerer does not accept the 'm' line in the offer, it MUST If the answerer does not accept the 'm' section in the offer, it MUST
assign a zero port value to the corresponding 'm' line in the answer. assign a zero port value to the 'm' line of the corresponding 'm'
In addition, the answerer MUST NOT establish a TCP connection or a section in the answer. In addition, the answerer MUST NOT establish
TLS/DTLS connection associated with the 'm' line. a TCP connection or a TLS/DTLS connection associated with the 'm'
section.
10.3. Offerer Processing of the SDP Answer 10.3. Offerer Processing of the SDP Answer
When the offerer receives an answer, which contains an 'm' line with When the offerer receives an answer that contains an 'm' section with
a non-zero port value, describing a BFCP stream, the offerer: a non-zero port value, describing a BFCP stream, the offerer:
o MUST, if the offerer is the 'active' endpoint, and if a TCP o MUST, if the offerer is the active endpoint, and if a TCP
connection associated with the 'm' line is to be established (or connection associated with the 'm' section is to be established
re-established), initiate the establishing of the TCP connection; (or re-established), initiate the establishing of the TCP
and connection; and
o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS o MUST, if the offerer is the active endpoint, and if an TLS/DTLS
connection associated with the 'm' line is to be established (or connection associated with the 'm' section is to be established
re-established), initiate the establishing of the TLS/DTLS (or re-established), initiate the establishing of the TLS/DTLS
connection (by sending a ClientHello message). connection (by sending a ClientHello message).
Note: An answerer compliant with [RFC4583] might not include Note: An answerer compliant with [RFC4583] might not include
'floorctrl' and 'bfcpver' attributes in answers, in which cases 'floorctrl' and 'bfcpver' attributes in answers, in which cases the
the default values apply. default values apply.
If the 'm' line in the answer contains a zero port value, or if the 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 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 answerer only indicates support of BFCP versions not supported by
the offerer), the offerer MUST NOT establish a TCP connection or a the offerer), the offerer MUST NOT establish a TCP connection or a
TLS/DTLS connection associated with the 'm' line. TLS/DTLS connection associated with the 'm' section.
10.4. Modifying the Session 10.4. Modifying the Session
When an offerer sends an updated offer, in order to modify a When an offerer sends an updated offer, in order to modify a
previously established BFCP stream, it follows the procedures in previously established BFCP stream, it follows the procedures in
Section 10.1, with the following exceptions: Section 10.1, with the following exceptions:
o If the BFCP stream is carried on top of TCP, and if the offerer o 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 does not want to re-establish an existing TCP connection, the
offerer MUST associate an SDP 'connection' attribute with a value offerer MUST include an SDP 'connection' attribute with a value of
of "existing", with the 'm' line; and "existing", in the 'm' section; and
o If the offerer wants to disable a previously established BFCP o If the offerer wants to disable a previously established BFCP
stream, it MUST assign a zero port value to the 'm' line stream, it MUST assign a zero port value to the 'm' line
associated with the BFCP connection, following the procedures in associated with the BFCP connection, following the procedures in
[RFC3264]. [RFC3264].
11. Examples 11. Examples
For the purpose of brevity, the main portion of the session For the purpose of brevity, the main portion of the session
description is omitted in the examples, which only show 'm' lines and description is omitted in the examples, which only show 'm' sections
their attributes. and their 'm' lines and attributes.
The following is an example of an offer sent by a conference server The following is an example of an offer sent by a conference server
to a client. to a client.
m=application 50000 TCP/TLS/BFCP * m=application 50000 TCP/TLS/BFCP *
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
a=fingerprint:sha-256 \ a=fingerprint:sha-256 \
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ 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 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
skipping to change at page 18, line 5 skipping to change at page 19, line 49
12. Security Considerations 12. Security Considerations
The BFCP [I-D.ietf-bfcpbis-rfc4582bis], SDP [RFC4566], and offer/ The BFCP [I-D.ietf-bfcpbis-rfc4582bis], SDP [RFC4566], and offer/
answer [RFC3264] specifications discuss security issues related to answer [RFC3264] specifications discuss security issues related to
BFCP, SDP, and offer/answer, respectively. In addition, [RFC4145] BFCP, SDP, and offer/answer, respectively. In addition, [RFC4145]
and [RFC8122] discuss security issues related to the establishment of and [RFC8122] discuss security issues related to the establishment of
TCP and TLS connections using an offer/answer model. Furthermore, TCP and TLS connections using an offer/answer model. Furthermore,
when using DTLS over UDP, the generic offer/answer considerations when using DTLS over UDP, the generic offer/answer considerations
defined in [I-D.ietf-mmusic-dtls-sdp] MUST be followed. defined in [I-D.ietf-mmusic-dtls-sdp] 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 13. IANA Considerations
[Editorial note: The changes in Section 13.1 instruct the IANA to [Editorial note: The changes in Section 13.1 instruct the IANA to
register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/ register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/
BFCP for the SDP 'proto' field. The new section Section 5.5 BFCP for the SDP 'proto' field. The new section Section 5.5
registers a new SDP "bfcpver" attribute. The rest is unchanged registers a new SDP "bfcpver" attribute. The rest is unchanged
from [RFC4582].] from [RFC4582].]
13.1. Registration of SDP 'proto' Values 13.1. Registration of SDP 'proto' Values
The IANA has registered the following values for the SDP 'proto' The IANA is requested to register the following values for the SDP
field under the Session Description Protocol (SDP) Parameters 'proto' field under the Session Description Protocol (SDP) Parameters
registry: registry:
+---------------+------------+ +---------------+------------+
| Value | Reference | | Value | Reference |
+---------------+------------+ +---------------+------------+
| TCP/BFCP | [RFC XXXX] | | TCP/BFCP | [RFC XXXX] |
| TCP/DTLS/BFCP | [RFC XXXX] | | TCP/DTLS/BFCP | [RFC XXXX] |
| TCP/TLS/BFCP | [RFC XXXX] | | TCP/TLS/BFCP | [RFC XXXX] |
| UDP/BFCP | [RFC XXXX] | | UDP/BFCP | [RFC XXXX] |
| UDP/TLS/BFCP | [RFC XXXX] | | UDP/TLS/BFCP | [RFC XXXX] |
+---------------+------------+ +---------------+------------+
Table 3: Values for the SDP 'proto' field Table 3: Values for the SDP 'proto' field
13.2. Registration of the SDP 'floorctrl' Attribute 13.2. Registration of the SDP 'floorctrl' Attribute
This document defines the SDP attribute,'floorctrl'. The details of This document defines the SDP attribute,'floorctrl'. The details of
the attribute are defined in Section 5.1. the attribute are defined in Section 5.1.
For issues regarding this attribute contact iesg@ietf.org.
13.3. Registration of the SDP 'confid' Attribute 13.3. Registration of the SDP 'confid' Attribute
This document defines the SDP attribute,'confid'. The details of the This document defines the SDP attribute,'confid'. The details of the
attribute are defined in Section 5.2. attribute are defined in Section 5.2.
For issues regarding this attribute contact iesg@ietf.org.
13.4. Registration of the SDP 'userid' Attribute 13.4. Registration of the SDP 'userid' Attribute
This document defines the SDP attribute,'userid'. The details of the This document defines the SDP attribute,'userid'. The details of the
attribute are defined in Section 5.3. attribute are defined in Section 5.3.
For issues regarding this attribute contact iesg@ietf.org.
13.5. Registration of the SDP 'floorid' Attribute 13.5. Registration of the SDP 'floorid' Attribute
This document defines the SDP attribute,'floorid'. The details of This document defines the SDP attribute,'floorid'. The details of
the attribute are defined in Section 5.4. the attribute are defined in Section 5.4.
For issues regarding this attribute contact iesg@ietf.org.
13.6. Registration of the SDP 'bfcpver' Attribute 13.6. Registration of the SDP 'bfcpver' Attribute
This document defines the SDP attribute,'bfcpver'. The details of This document defines the SDP attribute,'bfcpver'. The details of
the attribute are defined in Section 5.5. the attribute are defined in Section 5.5.
For issues regarding this attribute contact iesg@ietf.org.
14. Changes from RFC 4583 14. Changes from RFC 4583
Following is the list of technical changes and other fixes from Following is the list of technical changes and other fixes from
[RFC4583]. [RFC4583].
Main purpose of this work was to add signaling support necessary to Main purpose of this work was to add signaling support necessary to
support BFCP over unreliable transport, as described in support BFCP over unreliable transport, as described in
[I-D.ietf-bfcpbis-rfc4582bis], resulting in the following changes: [I-D.ietf-bfcpbis-rfc4582bis], resulting in the following changes:
1. Fields in the 'm' line (Section 4): 1. Fields in the 'm' line (Section 4):
The section is re-written to remove reference to the exclusivity The section is re-written to remove reference to the exclusivity
of TCP as a transport for BFCP streams. The proto field values of TCP as a transport for BFCP streams. The proto field values
TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added. TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added.
2. Authentication (Section 8): 2. Security Considerations (Section 12):
In last paragraph, made clear that a TCP connection was
described.
3. Security Considerations (Section 12):
For the DTLS over UDP case, mention existing considerations and For the DTLS over UDP case, mention existing considerations and
requirements for the offer/answer exchange in requirements for the offer/answer exchange in
[I-D.ietf-mmusic-dtls-sdp]. [I-D.ietf-mmusic-dtls-sdp].
4. Registration of SDP 'proto' Values (Section 13.1): 3. Registration of SDP 'proto' Values (Section 13.1):
Register the three new values TCP/DTLS/BFCP, UDP/BFCP and Register the three new values TCP/DTLS/BFCP, UDP/BFCP and
UDP/TLS/BFCP in the SDP parameters registry. UDP/TLS/BFCP in the SDP parameters registry.
5. BFCP Version Negotiation (Section 5.5): 4. BFCP Version Negotiation (Section 5.5):
A new 'bfcpver' SDP media-level attribute is added in order to A new 'bfcpver' SDP media-level attribute is added in order to
signal supported version number. signal supported version number.
In addition to the changes associated with support of BFCP over In addition to the changes associated with support of BFCP over
unreliable transport, the possibility for an endpoint to act as both unreliable transport, the possibility for an endpoint to act as both
floor control client and floor control server at the same time has floor control client and floor control server at the same time has
been removed. An endpoint will now take the same role for all BFCP- been removed. An endpoint will now take the same role for all BFCP-
controlled streams associated with the BFCP stream. controlled streams associated with the BFCP stream.
Clarification and bug fixes: Clarification and bug fixes:
skipping to change at page 21, line 9 skipping to change at page 22, line 51
Holmberg, C. and R. Shpount, "Session Description Protocol Holmberg, C. and R. Shpount, "Session Description Protocol
(SDP) Offer/Answer Considerations for Datagram Transport (SDP) Offer/Answer Considerations for Datagram Transport
Layer Security (DTLS) and Transport Layer Security (TLS)", Layer Security (DTLS) and Transport Layer Security (TLS)",
draft-ietf-mmusic-dtls-sdp-32 (work in progress), October draft-ietf-mmusic-dtls-sdp-32 (work in progress), October
2017. 2017.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Nandakumar, S., and A. Keranen, Petit-Huguenin, M., Nandakumar, S., and A. Keranen,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-21 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in
progress), June 2018. progress), November 2018.
[I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), February 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
skipping to change at page 22, line 48 skipping to change at page 24, line 43
editor.org/info/rfc8445>. editor.org/info/rfc8445>.
16.2. Informational References 16.2. Informational References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-53 (work in progress), September 2018. negotiation-53 (work in progress), September 2018.
[I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), February 2018.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<https://www.rfc-editor.org/info/rfc5576>. <https://www.rfc-editor.org/info/rfc5576>.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
FI-02420 Jorvas FI-02420 Jorvas
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Tom Kristensen Tom Kristensen
Cisco Cisco
 End of changes. 66 change blocks. 
150 lines changed or deleted 167 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/