rfc8856xml2.original.xml		rfc8856.xml
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version='1.0' encoding='utf-8'?>
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">		nsus="true" docName="draft-ietf-bfcpbis-rfc4583bis-27" indexInclude="true" ipr="
			trust200902" number="8856" obsoletes="4583" prepTime="2021-01-17T13:35:34" scrip
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>		ts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth=
			"4" tocInclude="true" xml:lang="en">
	<rfc category="std" ipr="trust200902" docName="draft-ietf-bfcpbis-rfc4583bis-27"		<link href="https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis-27"
	obsoletes="4583">		rel="prev"/>
			<link href="https://dx.doi.org/10.17487/rfc8856" rel="alternate"/>
	<?rfc strict="yes"?>		<link href="urn:issn:2070-1721" rel="alternate"/>
	<?rfc toc="yes"?>		<front>
	<?rfc tocdepth="4"?>		<title abbrev="SDP Format for BFCP Streams">Session Description Protocol (SD
	<?rfc symrefs="no"?>		P) Format for Binary Floor Control Protocol (BFCP) Streams</title>
	<?rfc sortrefs="yes" ?>		<seriesInfo name="RFC" value="8856" stream="IETF"/>
	<?rfc compact="yes" ?>		<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
	<?rfc subcompact="no" ?>		<organization showOnFrontPage="true">Ericsson</organization>
	<?rfc symrefs="yes" ?>		<address>
			<postal>
	<front>		<street>Hirsalantie 11</street>
	<title abbrev="BFCP">Session Description Protocol (SDP) Format for Binary Floo
	r Control Protocol (BFCP) Streams</title>
	<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
	<organization>Ericsson</organization>
	<address>
	<postal>
	<street>Hirsalantie 11</street>
	<city>FI-02420 Jorvas</city>
	<country>Finland</country>
	</postal>
	<email>Gonzalo.Camarillo@ericsson.com</email>
	</address>
	</author>
	<author fullname="Tom Kristensen" initials="T." surname="Kristensen">
	<organization>Cisco</organization>
	<address>
	<postal>
	<street>Philip Pedersens vei 1</street>
	<city>NO-1366 Lysaker</city>
	<country>Norway</country>
	</postal>
	<email>tomkrist@cisco.com, tomkri@ifi.uio.no</email>
	</address>
	</author>
	<author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">
	<organization>Ericsson</organization>
	<address>
	<postal>
	<street>Hirsalantie 11</street>
	<code>02420</code>		<code>02420</code>
	<city>Jorvas</city>		<city>Jorvas</city>
	<country>Finland</country>		<country>Finland</country>
	</postal>		</postal>
	<email>christer.holmberg@ericsson.com</email>		<email>Gonzalo.Camarillo@ericsson.com</email>
	</address>		</address>
	</author>		</author>
			<author fullname="Tom Kristensen" initials="T." surname="Kristensen">
	<date year="2018"/>		<organization abbrev="Jotron" showOnFrontPage="true">Jotron AS</organizati
			on>
	<area>Real-time Applications and Infrastructure</area>		<address>
	<workgroup>BFCPbis Working Group</workgroup>		<postal>
			<street>Ringdalskogen 8</street>
	<keyword>floor control</keyword>		<code>3270</code>
	<keyword>BFCP</keyword>		<city>Larvik</city>
	<keyword>SDP</keyword>		<country>Norway</country>
			</postal>
	<abstract>		<email>tom.kristensen@jotron.com, tomkri@ifi.uio.no</email>
	<t>This document defines the Session Description Protocol (SDP) offer/answer		</address>
	procedures for negotiating and establishing Binary Floor Control Protocol (BFCP)		</author>
	streams.</t>		<author initials="C." surname="Holmberg" fullname="Christer Holmberg">
	<t>This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in		<organization showOnFrontPage="true">Ericsson</organization>
	Section 14.</t>		<address>
	<!-- Ensure correct section #, as xref is no		<postal>
	t allowed in abstract -->		<street>Hirsalantie 11</street>
	</abstract>		<code>02420</code>
	</front>		<city>Jorvas</city>
			<country>Finland</country>
	<middle>		</postal>
	<section title="Introduction">		<email>christer.holmberg@ericsson.com</email>
	<t>As discussed in the BFCP (Binary Floor Control Protocol) specification <x		</address>
	ref target="I-D.ietf-bfcpbis-rfc4582bis"/>, a		</author>
			<date month="01" year="2021"/>
			<keyword>floor control</keyword>
			<keyword>BFCP</keyword>
			<keyword>SDP</keyword>
			<abstract pn="section-abstract">
			<t indent="0" pn="section-abstract-1">This document defines the Session De
			scription Protocol (SDP)
			offer/answer procedures for negotiating and establishing Binary Floor
			Control Protocol (BFCP) streams.</t>
			<t indent="0" pn="section-abstract-2">This document obsoletes RFC 4583.</t
			>
			</abstract>
			<boilerplate>
			<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
			"exclude" pn="section-boilerplate.1">
			<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
			>
			<t indent="0" pn="section-boilerplate.1-1">
			This is an Internet Standards Track document.
			</t>
			<t indent="0" pn="section-boilerplate.1-2">
			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.
			</t>
			<t indent="0" pn="section-boilerplate.1-3">
			Information about the current status of this document, any
			errata, and how to provide feedback on it may be obtained at
			<eref target="https://www.rfc-editor.org/info/rfc8856" brackets="non
			e"/>.
			</t>
			</section>
			<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
			ude" pn="section-boilerplate.2">
			<name slugifiedName="name-copyright-notice">Copyright Notice</name>
			<t indent="0" pn="section-boilerplate.2-1">
			Copyright (c) 2021 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			</t>
			<t indent="0" pn="section-boilerplate.2-2">
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(<eref target="https://trustee.ietf.org/license-info" brackets="none
			"/>) 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.
			</t>
			</section>
			</boilerplate>
			<toc>
			<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
			n="section-toc.1">
			<name slugifiedName="name-table-of-contents">Table of Contents</name>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
			c.1-1">
			<li pn="section-toc.1-1.1">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
			ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-introduction">
			Introduction</xref></t>
			</li>
			<li pn="section-toc.1-1.2">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
			ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-conventions">C
			onventions</xref></t>
			</li>
			<li pn="section-toc.1-1.3">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
			ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-floor-control-
			roles">Floor Control Roles</xref></t>
			</li>
			<li pn="section-toc.1-1.4">
			<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
			at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-fields-in-the-m-line">Fields in th
			e "m=" Line</xref></t>
			</li>
			<li pn="section-toc.1-1.5">
			<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
			at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-sdp-attributes">SDP Attributes</xr
			ef></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.5.2">
			<li pn="section-toc.1-1.5.2.1">
			<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
			"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-sdp-floorctrl-attribut
			e">SDP 'floorctrl' Attribute</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.2">
			<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
			"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-sdp-confid-attribute">
			SDP 'confid' Attribute</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.3">
			<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
			"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-sdp-userid-attribute">
			SDP 'userid' Attribute</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.4">
			<t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent=
			"5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-sdp-floorid-attribute"
			>SDP 'floorid' Attribute</xref></t>
			</li>
			<li pn="section-toc.1-1.5.2.5">
			<t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent=
			"5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-sdp-bfcpver-attribute"
			>SDP 'bfcpver' Attribute</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.6">
			<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
			at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-multiplexing-considerations">Multi
			plexing Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.7">
			<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
			at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-bfcp-connection-management">BFCP C
			onnection Management</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.7.2">
			<li pn="section-toc.1-1.7.2.1">
			<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
			"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-tcp-connection-managem
			ent">TCP Connection Management</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.8">
			<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
			at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-tls-dtls-considerations">TLS/DTLS
			Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.9">
			<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
			at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-ice-considerations">ICE Considerat
			ions</xref></t>
			</li>
			<li pn="section-toc.1-1.10">
			<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
			rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
			format="title" sectionFormat="of" target="name-sdp-offer-answer-procedures">SDP
			Offer/Answer Procedures</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.10.2">
			<li pn="section-toc.1-1.10.2.1">
			<t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent
			="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref deri
			vedContent="" format="title" sectionFormat="of" target="name-generating-the-init
			ial-sdp-">Generating the Initial SDP Offer</xref></t>
			</li>
			<li pn="section-toc.1-1.10.2.2">
			<t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent
			="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref deri
			vedContent="" format="title" sectionFormat="of" target="name-generating-the-sdp-
			answer">Generating the SDP Answer</xref></t>
			</li>
			<li pn="section-toc.1-1.10.2.3">
			<t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent
			="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref deri
			vedContent="" format="title" sectionFormat="of" target="name-offerer-processing-
			of-the-s">Offerer Processing of the SDP Answer</xref></t>
			</li>
			<li pn="section-toc.1-1.10.2.4">
			<t indent="0" pn="section-toc.1-1.10.2.4.1"><xref derivedContent
			="10.4" format="counter" sectionFormat="of" target="section-10.4"/>.  <xref deri
			vedContent="" format="title" sectionFormat="of" target="name-modifying-the-sessi
			on">Modifying the Session</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.11">
			<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
			rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
			format="title" sectionFormat="of" target="name-examples">Examples</xref></t>
			</li>
			<li pn="section-toc.1-1.12">
			<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
			rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
			format="title" sectionFormat="of" target="name-security-considerations">Securit
			y Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.13">
			<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
			rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
			format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
			erations</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.13.2">
			<li pn="section-toc.1-1.13.2.1">
			<t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent
			="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref deri
			vedContent="" format="title" sectionFormat="of" target="name-registration-of-sdp
			-proto-v">Registration of SDP 'proto' Values</xref></t>
			</li>
			<li pn="section-toc.1-1.13.2.2">
			<t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent
			="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref deri
			vedContent="" format="title" sectionFormat="of" target="name-registration-of-the
			-sdp-flo">Registration of the SDP 'floorctrl' Attribute</xref></t>
			</li>
			<li pn="section-toc.1-1.13.2.3">
			<t indent="0" pn="section-toc.1-1.13.2.3.1"><xref derivedContent
			="13.3" format="counter" sectionFormat="of" target="section-13.3"/>.  <xref deri
			vedContent="" format="title" sectionFormat="of" target="name-registration-of-the
			-sdp-con">Registration of the SDP 'confid' Attribute</xref></t>
			</li>
			<li pn="section-toc.1-1.13.2.4">
			<t indent="0" pn="section-toc.1-1.13.2.4.1"><xref derivedContent
			="13.4" format="counter" sectionFormat="of" target="section-13.4"/>.  <xref deri
			vedContent="" format="title" sectionFormat="of" target="name-registration-of-the
			-sdp-use">Registration of the SDP 'userid' Attribute</xref></t>
			</li>
			<li pn="section-toc.1-1.13.2.5">
			<t indent="0" pn="section-toc.1-1.13.2.5.1"><xref derivedContent
			="13.5" format="counter" sectionFormat="of" target="section-13.5"/>.  <xref deri
			vedContent="" format="title" sectionFormat="of" target="name-registration-of-the
			-sdp-floo">Registration of the SDP 'floorid' Attribute</xref></t>
			</li>
			<li pn="section-toc.1-1.13.2.6">
			<t indent="0" pn="section-toc.1-1.13.2.6.1"><xref derivedContent
			="13.6" format="counter" sectionFormat="of" target="section-13.6"/>.  <xref deri
			vedContent="" format="title" sectionFormat="of" target="name-registration-of-the
			-sdp-bfc">Registration of the SDP 'bfcpver' Attribute</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.14">
			<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" fo
			rmat="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent=""
			format="title" sectionFormat="of" target="name-changes-from-rfc-4583">Changes f
			rom RFC 4583</xref></t>
			</li>
			<li pn="section-toc.1-1.15">
			<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" fo
			rmat="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent=""
			format="title" sectionFormat="of" target="name-references">References</xref></t
			>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.15.2">
			<li pn="section-toc.1-1.15.2.1">
			<t indent="0" pn="section-toc.1-1.15.2.1.1"><xref derivedContent
			="15.1" format="counter" sectionFormat="of" target="section-15.1"/>.  <xref deri
			vedContent="" format="title" sectionFormat="of" target="name-normative-reference
			s">Normative References</xref></t>
			</li>
			<li pn="section-toc.1-1.15.2.2">
			<t indent="0" pn="section-toc.1-1.15.2.2.1"><xref derivedContent
			="15.2" format="counter" sectionFormat="of" target="section-15.2"/>.  <xref deri
			vedContent="" format="title" sectionFormat="of" target="name-informative-referen
			ces">Informative References</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.16">
			<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" form
			at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
			" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
			nts</xref></t>
			</li>
			<li pn="section-toc.1-1.17">
			<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" form
			at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
			" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
			resses</xref></t>
			</li>
			</ul>
			</section>
			</toc>
			</front>
			<middle>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
			<name slugifiedName="name-introduction">Introduction</name>
			<t indent="0" pn="section-1-1">As discussed in the BFCP (Binary Floor Cont
			rol Protocol) specification <xref target="RFC8855" format="default" sectionForma
			t="of" derivedContent="RFC8855"/>, a
	given BFCP client needs a set of data in order to establish a BFCP connectio n to a floor control server. This data includes		given BFCP client needs a set of data in order to establish a BFCP connectio n to a floor control server. This data includes
	the transport address of the server, the conference identifier, and the user identifier.</t>		the transport address of the server, the conference identifier, and the user identifier.</t>
	<t>One way for clients to obtain this information is to use an SDP offer/ans		<t indent="0" pn="section-1-2">One way for clients to obtain this informat
	wer <xref target="RFC3264"/> exchange.		ion is to use a Session
			Description Protocol (SDP) offer/answer exchange <xref target="RFC3264" fo
			rmat="default" sectionFormat="of" derivedContent="RFC3264"/>.
	This document specifies how to encode this information in the SDP session de scriptions that are part of such an offer/answer		This document specifies how to encode this information in the SDP session de scriptions that are part of such an offer/answer
	exchange.</t>		exchange.</t>
	<t>User agents typically use the offer/answer model to establish a number of		<t indent="0" pn="section-1-3">User agents typically use the offer/answer
	media streams of different types.		model to establish a number of media streams of different types.
	Following this model, a BFCP connection is described as any other media stre		Following this model, a BFCP connection is described as any other media stre
	am by using an SDP 'm' line, possibly		am by using an SDP "m=" line, possibly
	followed by a number of SDP lines that also apply to the BFCP connection.</t >		followed by a number of SDP lines that also apply to the BFCP connection.</t >
	<t><xref target="sec:m-line"/> defines how the field values in 'm' line repr		<t indent="0" pn="section-1-4"><xref target="sec_m-line" format="default"
	esenting a BFCP connection are set.</t>		sectionFormat="of" derivedContent="Section 4"/> defines how the field
	<t><xref target="sec:attributes"/> defines SDP attributes that are used when		values in an "m=" line representing a BFCP connection are set.</t>
	negotiating a BFCP connection.</t>		<t indent="0" pn="section-1-5"><xref target="sec_attributes" format="defau
	<t><xref target="sec:mux-cons"/> defines multiplexing considerations for a B		lt" sectionFormat="of" derivedContent="Section 5"/> defines SDP attributes that
	FCP connection.</t>		are used when negotiating a BFCP connection.</t>
	<t><xref target="sec:bfcp-connection"/> defines procedures for managing a BF		<t indent="0" pn="section-1-6"><xref target="sec_mux-cons" format="default
	CP connection.</t>		" sectionFormat="of" derivedContent="Section 6"/> defines multiplexing considera
	<t><xref target="sec:authentication"/> defines TLS and DTLS considerations w		tions for a BFCP connection.</t>
	hen negotiating a BFCP connection.</t>		<t indent="0" pn="section-1-7"><xref target="sec_bfcp-connection" format="
	<t><xref target="sec:ice-considerations"/> defines the Interactive Connectiv		default" sectionFormat="of" derivedContent="Section 7"/> defines procedures for
	ity Establishment (ICE)		managing a BFCP connection.</t>
	<xref target="RFC8445"/> considerations when negotiating a BFCP connection.<		<t indent="0" pn="section-1-8"><xref target="sec_authentication" format="d
	/t>		efault" sectionFormat="of" derivedContent="Section 8"/> defines TLS and DTLS con
	<t><xref target="sec:oa-offer-answer-proc"/> defines the SDP offer/answer pr		siderations when negotiating a BFCP connection.</t>
	ocedures for negotiating a BFCP connection.</t>		<t indent="0" pn="section-1-9"><xref target="sec_ice-considerations" forma
	</section>		t="default" sectionFormat="of" derivedContent="Section 9"/> defines
			considerations regarding Interactive Connectivity Establishment (ICE)
	<section title="Conventions">		<xref target="RFC8445" format="default" sectionFormat="of" derivedContent="R
	<t>		FC8445"/> when negotiating a BFCP connection.</t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOUL		<t indent="0" pn="section-1-10"><xref target="sec_oa-offer-answer-proc" fo
	D", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		rmat="default" sectionFormat="of" derivedContent="Section 10"/> defines
	"MAY", and "OPTIONAL" in this document are to be interpreted as described		the SDP offer/answer procedures for negotiating a BFCP connection.</t>
	in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref>		<t indent="0" pn="section-1-11">This document obsoletes RFC 4583 <xref tar
	when, and only when, they appear in all capitals, as shown here.		get="RFC4583" format="default" sectionFormat="of" derivedContent="RFC4583"/>. <x
	</t>		ref target="sec_changes" format="default" sectionFormat="of" derivedContent="Sec
	</section>		tion 14"/> summarizes the changes
			from RFC 4583.</t>
	<section title="Floor Control Roles" anchor="sec:server-determination">		</section>
	<t>		<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
			<name slugifiedName="name-conventions">Conventions</name>
			<t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp1
			4>MUST NOT</bcp14>",
			"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
			"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
			"<bcp14>SHOULD NOT</bcp14>",
			"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
			to be interpreted as described in BCP 14 <xref target="RFC2119" format="def
			ault" sectionFormat="of" derivedContent="RFC2119"/>
			<xref target="RFC8174" format="default" sectionFormat="of" derivedConten
			t="RFC8174"/> when, and only when, they appear in all capitals,
			as shown here.</t>
			</section>
			<section anchor="sec_server-determination" numbered="true" toc="include" rem
			oveInRFC="false" pn="section-3">
			<name slugifiedName="name-floor-control-roles">Floor Control Roles</name>
			<t indent="0" pn="section-3-1">
	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.		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.
	</t>		</t>
	<t>		<t indent="0" pn="section-3-2">
	Once the roles have been determined, the roles will apply to all BFCP-con trolled streams associated with the BFCP stream.		Once the roles have been determined, the roles will apply to all BFCP-con trolled streams associated with the BFCP stream.
	</t>		</t>
	</section>		</section>
			<section anchor="sec_m-line" numbered="true" toc="include" removeInRFC="fals
	<section title="Fields in the 'm' Line" anchor="sec:m-line">		e" pn="section-4">
	<t>According to the SDP specification <xref target="RFC4566"/>, the 'm' line		<name slugifiedName="name-fields-in-the-m-line">Fields in the "m=" Line</n
	format is the following:</t>		ame>
	<t><list style="hanging">		<t indent="0" pn="section-4-1">According to the SDP specification <xref ta
	<t><![CDATA[m=<media> <port> <proto> <fmt> ...]]></t>		rget="RFC8866" format="default" sectionFormat="of" derivedContent="RFC8866"/>, t
	</list></t>		he "m=" line format is as follows:</t>
	<t>This section describes how to generate an 'm' line of an SDP Media Descri		<sourcecode name="" type="sdp" markers="false" pn="section-4-2">
	ption ('m' section) describing a BFCP stream.</t>		m=&lt;media&gt; &lt;port&gt; &lt;proto&gt; &lt;fmt&gt; ...</sourcecode>
	<t>The media field MUST have a value of "application".</t>		<t indent="0" pn="section-4-3">This section describes how to generate an "
	<t>The port field is set depending on the value of the proto field, as expla		m=" line of an SDP Media Description ("m=" section) describing a BFCP stream.</t
	ined below. A port field value of zero has the standard SDP meaning (i.e., reje		>
	ction of the media stream) regardless of the proto field.</t>		<t indent="0" pn="section-4-4">The media field <bcp14>MUST</bcp14> have a
	<t><list style="hanging">		value of "application".</t>
	<t>When TCP is used as the transport, the port field is set following th		<t indent="0" pn="section-4-5">Depending on the value of the proto field,
	e rules in <xref target="RFC4145"/>. Depending on the value of the 'setup' attri		the port field is set as explained below. A port field value of zero has the st
	bute (discussed in <xref target="sec:tcp-connection"/>), the port field contains		andard SDP meaning (i.e., rejection of the media stream), regardless of the prot
	the port to which the remote endpoint will direct BFCP messages, or in the case		o field.</t>
	where the endpoint will initiate the connection towards the remote endpoint, sh		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-6
	ould be set to a value of 9.</t>		">
	<t>When UDP is used as the transport, the port field contains the port t		<li pn="section-4-6.1">When TCP is used as the transport, the port field
	o which the remote endpoint will direct BFCP messages regardless of the value of		is set following
	the 'setup' attribute.</t>		the rules in <xref target="RFC4145" format="default" sectionFormat="of" d
	</list></t>		erivedContent="RFC4145"/>. Depending on
	<t>This document defines five values for the proto field: TCP/BFCP, TCP/DTLS		the value of the 'setup' attribute (defined in <xref target="RFC4145" for
	/BFCP, TCP/TLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP.</t>		mat="default" sectionFormat="of" derivedContent="RFC4145"/> and discussed in <xr
	<t>The proto value are used as described below:</t>		ef target="sec_tcp-connection" format="default" sectionFormat="of" derivedConten
	<t><list style="hanging">		t="Section 7.1"/>), the port field contains the port to which the remote endpoin
	<t>'TCP/BFCP' is used for TCP transport of BFCP without TLS encryption, an		t will direct BFCP messages, or in the case where the endpoint will initiate the
	d is backward compatible with RFC 4583 compliant endpoints.</t>		connection towards the remote endpoint, should be set to a value of 9.</li>
	<t>'TCP/TLS/BFCP' is used for TCP transport of BFCP with TLS encryption, a		<li pn="section-4-6.2">When UDP is used as the transport, the port field
	nd is backward compatible with RFC 4583 compliant endpoints that support TLS.</t		contains the port to which the remote endpoint will direct BFCP messages, regar
	>		dless of the value of the 'setup' attribute.</li>
	<t>'UDP/BFCP' is used for UDP transport of BFCP without DTLS encryption <x		</ul>
	ref target="RFC6347"/>.</t>		<t indent="0" pn="section-4-7">This document defines five values for the p
	<t>'UDP/TLS/BFCP' is used for UDP transport of BFCP with DTLS encryption.		roto field: 'TCP/BFCP', 'TCP/DTLS/BFCP', 'TCP/TLS/BFCP', 'UDP/BFCP', and 'UDP/TL
	This is one of the options when ICE is used (<xref target="sec:ice-consideration		S/BFCP'.</t>
	s"/>). It can also be used without ICE		<t indent="0" pn="section-4-8">The proto values are used as described belo
	when backward compatibility with RFC 4583 compliant endpoints is not r		w:</t>
	equired.</t>		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-9
	<t>'TCP/DTLS/BFCP' is used for TCP transport of BFCP with DTLS encryption,		">
	running on top of TCP using the framing method defined in <xref target="RFC4571		<li pn="section-4-9.1">'TCP/BFCP' is used for TCP transport of BFCP with
	"/>, with DTLS packets being		out TLS
	sent and received instead of RTP/RTCP packets using the shim defined i		encryption and is backward compatible with endpoints that are compliant w
	n RFC 4571 such that the length field defined in RFC 4571 precedes each DTLS mes		ith RFC 4583.</li>
	sage. This is one of the options when		<li pn="section-4-9.2">'TCP/TLS/BFCP' is used for TCP transport of BFCP
	ICE is used (<xref target="sec:ice-considerations"/>). It can also be		with TLS
	used without ICE when backward compatibility with RFC 4583 compliant endpoints i		encryption and is backward compatible with endpoints that are
	s not required.</t>		compliant with RFC 4583 and support TLS.</li>
	</list></t>		<li pn="section-4-9.3">'UDP/BFCP' is used for UDP transport of BFCP with
	<t>The fmt (format) list is not applicable to BFCP. The fmt list of 'm' line		out DTLS encryption <xref target="RFC6347" format="default" sectionFormat="of" d
	s in the case of any proto field value related to BFCP MUST contain a single "*"		erivedContent="RFC6347"/>.</li>
	character. If the the fmt list contains any other value it MUST be ignored.</t>		<li pn="section-4-9.4">'UDP/TLS/BFCP' is used for UDP transport of BFCP
	<t>The following is an example of an 'm' line for a BFCP connection:</t>		with DTLS
	<figure>		encryption. This is one of the options when ICE is used (<xref target="se
	<artwork>		c_ice-considerations" format="default" sectionFormat="of" derivedContent="Sectio
	m=application 50000 TCP/TLS/BFCP *		n 9"/>). It can also be used without ICE
	</artwork>		when backward compatibility with endpoints compliant with RFC 4583 is
	</figure>		not required.</li>
	</section>		<li pn="section-4-9.5">'TCP/DTLS/BFCP' is used for TCP transport of BFCP
			with DTLS encryption, running on top of TCP using the framing method defined in
	<section title="SDP Attributes" anchor="sec:attributes">		<xref target="RFC4571" format="default" sectionFormat="of" derivedContent="RFC4
	<section title="SDP 'floorctrl' Attribute" anchor="sec:floorctrl-attr">		571"/>, with DTLS packets being
	<t>		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 (<xref target="sec_ice-considerations" format="default" se
			ctionFormat="of" derivedContent="Section 9"/>). It can also be used without ICE
			when backward
			compatibility with endpoints compliant with RFC 4583 is not required.</li
			>
			</ul>
			<t indent="0" pn="section-4-10">The fmt (format) list is not applicable to
			BFCP. The fmt list of "m=" lines in the case of any proto field value related t
			o BFCP <bcp14>MUST</bcp14> contain a single "*" character. If the fmt list conta
			ins any other value, it <bcp14>MUST</bcp14> be ignored.</t>
			<t indent="0" pn="section-4-11">The following is an example of an "m=" lin
			e for a BFCP connection:</t>
			<sourcecode name="" type="sdp" markers="false" pn="section-4-12">
			m=application 50000 TCP/TLS/BFCP *</sourcecode>
			</section>
			<section anchor="sec_attributes" numbered="true" toc="include" removeInRFC="
			false" pn="section-5">
			<name slugifiedName="name-sdp-attributes">SDP Attributes</name>
			<section anchor="sec_floorctrl-attr" numbered="true" toc="include" removeI
			nRFC="false" pn="section-5.1">
			<name slugifiedName="name-sdp-floorctrl-attribute">SDP 'floorctrl' Attri
			bute</name>
			<t indent="0" pn="section-5.1-1">
	This section defines the SDP 'floorctrl' media-level attribute. The att ribute is used to determine the floor control roles (client and server) for the endpoints associated with		This section defines the SDP 'floorctrl' media-level attribute. The att ribute is used to determine the floor control roles (client and server) for the endpoints associated with
	the BFCP stream.		the BFCP stream.
	</t>		</t>
	<figure>		<ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.
	<artwork type='abnf'>		1-2">
	Attribute Name: floorctrl		<li pn="section-5.1-2.1">
			<dl indent="3" newline="false" spacing="normal" pn="section-5.1-2.1.
	Attribute Value: floor-control		1">
			<dt pn="section-5.1-2.1.1.1">Attribute Name:</dt>
	Usage Level: media		<dd pn="section-5.1-2.1.1.2">floorctrl</dd>
			<dt pn="section-5.1-2.1.1.3">Attribute Value:</dt>
	Charset Dependent: No		<dd pn="section-5.1-2.1.1.4">floor-control</dd>
			<dt pn="section-5.1-2.1.1.5">Usage Level:</dt>
	Mux Category: TBD		<dd pn="section-5.1-2.1.1.6">media</dd>
			<dt pn="section-5.1-2.1.1.7">Charset Dependent:</dt>
	The Augmented BNF syntax [RFC5234] for the attribute is:		<dd pn="section-5.1-2.1.1.8">No</dd>
			<dt pn="section-5.1-2.1.1.9">Mux Category:</dt>
	floor-control = role *(SP role)		<dd pn="section-5.1-2.1.1.10">TBD</dd>
	role = "c-only" / "s-only" / "c-s"		</dl>
	</artwork>		</li>
	</figure>		</ul>
	<t>An endpoint includes the attribute to indicate the role(s) it would be		<t indent="0" pn="section-5.1-3">The Augmented BNF syntax <xref target="
	willing to perform for the BFCP-controlled media streams:</t>		RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/> for the
	<t><list style="hanging">		attribute is:</t>
	<t hangText="c-only:">The endpoint is willing to act as floor control		<sourcecode name="" type="abnf" markers="false" pn="section-5.1-4">
	client.</t>		floor-control = role *(SP role)
	<t hangText="s-only:">The endpoint is willing to act as floor control		role = "c-only" / "s-only" / "c-s"</sourcecode>
	server only.</t>		<t indent="0" pn="section-5.1-5">An endpoint includes the attribute to i
	</list></t>		ndicate the role(s) it would be willing to perform for the BFCP-controlled media
	<t>		streams:</t>
	When inserted in an offer, the offerer MAY indicate multiple attribute v		<ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.
	alues ("c-only" and "s-only"). When inserted in an answer, the answerer MUST		1-6">
			<li pn="section-5.1-6.1">
			<dl newline="false" spacing="normal" indent="3" pn="section-5.1-6.1.
			1">
			<dt pn="section-5.1-6.1.1.1">c-only:</dt>
			<dd pn="section-5.1-6.1.1.2">The endpoint is willing to act as a f
			loor control client.</dd>
			<dt pn="section-5.1-6.1.1.3">s-only:</dt>
			<dd pn="section-5.1-6.1.1.4">The endpoint is willing to act as a f
			loor control server only.</dd>
			</dl>
			</li>
			</ul>
			<t indent="0" pn="section-5.1-7">
			When inserted in an offer, the offerer <bcp14>MAY</bcp14> indicate multi
			ple attribute values ("c-only" and "s-only"). When inserted in an answer, the an
			swerer <bcp14>MUST</bcp14>
	indicate only one attribute value: "c-only" or "s-only". The answerer in dicates the role taken by the answerer. The offerer will then take the		indicate only one attribute value: "c-only" or "s-only". The answerer in dicates the role taken by the answerer. The offerer will then take the
	opposite role.		opposite role.
	</t>		</t>
	<t>		<t indent="0" pn="section-5.1-8">
	In <xref target="RFC4583"/>, there was a third attribute specified, "c-s		In <xref target="RFC4583" format="default" sectionFormat="of" derivedCon
	", which meant that an endpoint was willing to act as both floor control client		tent="RFC4583"/>, there was a third
	and		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 differ ent roles for different BFCP-controlled media streams. The feature was underspec ified		floor control server at the same time for the BFCP stream, taking differ ent roles for different BFCP-controlled media streams. The feature was underspec ified
	and implemented in different ways, in particular many implementations in		and implemented in different ways; in particular, many implementations
	terpreted "c-s” to mean that the endpoint is willing to act as either client or		interpreted "c-s" to mean that the endpoint is willing to act as
	server		either a client or a server
	(equivalent to “c-only s-only”). An implementation compliant to this spe		(equivalent to "c-only s-only"). An implementation compliant with this s
	cification MUST NOT include the "c-s" floorctl attribute value in an offer or in		pecification <bcp14>MUST NOT</bcp14> include the "c-s" 'floorctrl' attribute val
	an answer,		ue in an offer or in an answer
	but MUST accept the attribute value in an offer and process it as equiva		but <bcp14>MUST</bcp14> accept the attribute value in an offer and
	lent to "c-only s-only" (or "s-only c-only"). Also, as an implementation complia		process it as equivalent to "c-only s-only" (or "s-only c-only"). Also, a
	nt to		s an implementation compliant with
	this specification is only allowed to include one role, either 'c-only'		this specification is only allowed to include one role -- either
	or 's-conly', in an answer, each endpoint will only take one role, and as a resu		"c-only" or "s-only" -- in an answer, each endpoint will only take one ro
	lt		le, and as a result
	the endpoint will take the same role for each BFCP-controlled media stre am associated with the BFCP stream.		the endpoint will take the same role for each BFCP-controlled media stre am associated with the BFCP stream.
	</t>		</t>
	<t>		<t indent="0" pn="section-5.1-9">
	<xref target="tab-roles"/> shows the roles that the answerer is allowed		<xref target="tab-roles" format="default" sectionFormat="of" derivedCont
	to take, based on what roles the offerer has		ent="Table 1"/> shows the roles that the answerer is allowed to take, based on w
			hat roles the offerer has
	indicated that it is willing to take.		indicated that it is willing to take.
	</t>		</t>
	<texttable title="Roles" anchor="tab-roles">		<table anchor="tab-roles" align="center" pn="table-1">
	<ttcol align="center">Offerer</ttcol>		<name slugifiedName="name-roles">Roles</name>
	<ttcol align="center">Answerer</ttcol>		<thead>
			<tr>
	<c>c-only</c>		<th align="center" colspan="1" rowspan="1">Offerer</th>
	<c>s-only</c>		<th align="center" colspan="1" rowspan="1">Answerer</th>
			</tr>
	<c>s-only</c>		</thead>
	<c>c-only</c>		<tbody>
			<tr>
	<c>c-s</c>		<td align="center" colspan="1" rowspan="1">c-only</td>
	<c>c-only</c>		<td align="center" colspan="1" rowspan="1">s-only</td>
			</tr>
	<c>c-s</c>		<tr>
	<c>s-only</c>		<td align="center" colspan="1" rowspan="1">s-only</td>
	</texttable>		<td align="center" colspan="1" rowspan="1">c-only</td>
	<t>		</tr>
	Endpoints compliant with <xref target="RFC4583"/> might not include the		<tr>
	'floorctrl' attribute in offers and answerer.		<td align="center" colspan="1" rowspan="1">c-s</td>
	If the 'floorctrl' attribute is not present, in order to be interoperabl		<td align="center" colspan="1" rowspan="1">c-only</td>
	e with such endpoints, the offerer will act as floor control client		</tr>
	and the answerer will act as floor control server.		<tr>
	</t>		<td align="center" colspan="1" rowspan="1">c-s</td>
	<t>		<td align="center" colspan="1" rowspan="1">s-only</td>
	The SDP Offer/Answer procedures for the 'floorctrl' attribute are define		</tr>
	d in <xref target="sec:oa-offer-answer-proc"/>.		</tbody>
	</t>		</table>
	<t>The following is an example of a 'floorctrl' attribute in an offer:</t>		<t indent="0" pn="section-5.1-11">
	<figure>		Endpoints compliant with <xref target="RFC4583" format="default" section
	<artwork>		Format="of" derivedContent="RFC4583"/> might not include the 'floorctrl' attribu
	a=floorctrl:c-only s-only		te in offers and answers.
	</artwork>		If the 'floorctrl' attribute is not present, in order to be
	</figure>		interoperable with such endpoints, the offerer will act as a floor contro
	</section>		l client
			and the answerer will act as a floor control server.
	<section title="SDP 'confid' Attribute" anchor="sec:confid-attr">		</t>
	<t>		<t indent="0" pn="section-5.1-12">
			The SDP Offer/Answer procedures for the 'floorctrl' attribute are define
			d in <xref target="sec_oa-offer-answer-proc" format="default" sectionFormat="of"
			derivedContent="Section 10"/>.
			</t>
			<t indent="0" pn="section-5.1-13">The following is an example of a 'floo
			rctrl' attribute in an offer:</t>
			<sourcecode name="" type="sdp" markers="false" pn="section-5.1-14">
			a=floorctrl:c-only s-only</sourcecode>
			</section>
			<section anchor="sec_confid-attr" numbered="true" toc="include" removeInRF
			C="false" pn="section-5.2">
			<name slugifiedName="name-sdp-confid-attribute">SDP 'confid' Attribute</
			name>
			<t indent="0" pn="section-5.2-1">
	This section defines the SDP 'confid' media-level attribute. The attribute is used by a floor control server		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 decim al integer representation.		to convey the conference ID value to the floor control client, using decim al integer representation.
	</t>		</t>
	<figure>		<ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.
	<artwork type='abnf'><![CDATA[		2-2">
	Attribute Name: confid		<li pn="section-5.2-2.1">
			<dl indent="3" newline="false" spacing="normal" pn="section-5.2-2.1.
	Attribute Value: conference-id		1">
			<dt pn="section-5.2-2.1.1.1">Attribute Name:</dt>
	Usage Level: media		<dd pn="section-5.2-2.1.1.2">confid</dd>
			<dt pn="section-5.2-2.1.1.3">Attribute Value:</dt>
	Charset Dependent: No		<dd pn="section-5.2-2.1.1.4">conference-id</dd>
			<dt pn="section-5.2-2.1.1.5">Usage Level:</dt>
	Mux Category: TBD		<dd pn="section-5.2-2.1.1.6">media</dd>
			<dt pn="section-5.2-2.1.1.7">Charset Dependent:</dt>
	The Augmented BNF syntax [RFC5234] for the attribute is:		<dd pn="section-5.2-2.1.1.8">No</dd>
			<dt pn="section-5.2-2.1.1.9">Mux Category:</dt>
	conference-id = 1*DIGIT		<dd pn="section-5.2-2.1.1.10">TBD</dd>
			</dl>
	DIGIT = <DIGIT defined in [RFC5234]>		</li>
			</ul>
	The maximum value of the attribute is determined by the		<t indent="0" pn="section-5.2-3">The Augmented BNF syntax <xref target="
	COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis].		RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/> for the
			attribute is:</t>
	]]></artwork>		<sourcecode name="" type="abnf" markers="false" pn="section-5.2-4">
	</figure>		conference-id = 1*DIGIT
	<t>
	The SDP Offer/Answer procedures for the 'confid' attribute are defined in
	<xref target="sec:oa-offer-answer-proc"/>.
	</t>
	</section>
	<section title="SDP 'userid' Attribute" anchor="sec:userid-attr">		DIGIT = &lt;DIGIT as defined in [RFC5234]&gt;</sourcecode>
	<t>		<t indent="0" pn="section-5.2-5">The maximum value of the attribute is d
	This section defines the SDP userid' media-level attribute. The attribute		etermined by the
	is used by a floor control server		COMMON-HEADER format <xref target="RFC8855" format="default" sectionFormat
			="of" derivedContent="RFC8855"/>.</t>
			<t indent="0" pn="section-5.2-6">
			The SDP Offer/Answer procedures for the 'confid' attribute are defined in
			<xref target="sec_oa-offer-answer-proc" format="default" sectionFormat="of" deri
			vedContent="Section 10"/>.
			</t>
			</section>
			<section anchor="sec_userid-attr" numbered="true" toc="include" removeInRF
			C="false" pn="section-5.3">
			<name slugifiedName="name-sdp-userid-attribute">SDP 'userid' Attribute</
			name>
			<t indent="0" pn="section-5.3-1">
			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 int eger representation.		to convey the user ID value to the floor control client, using decimal int eger representation.
	</t>		</t>
	<figure>		<ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.
	<artwork type='abnf'><![CDATA[		3-2">
	Attribute Name: userid		<li pn="section-5.3-2.1">
			<dl indent="3" newline="false" spacing="normal" pn="section-5.3-2.1.
	Attribute Value: user-id		1">
			<dt pn="section-5.3-2.1.1.1">Attribute Name:</dt>
	Usage Level: media		<dd pn="section-5.3-2.1.1.2">userid</dd>
			<dt pn="section-5.3-2.1.1.3">Attribute Value:</dt>
	Charset Dependent: No		<dd pn="section-5.3-2.1.1.4">user-id</dd>
			<dt pn="section-5.3-2.1.1.5">Usage Level:</dt>
	Mux Category: TBD		<dd pn="section-5.3-2.1.1.6">media</dd>
			<dt pn="section-5.3-2.1.1.7">Charset Dependent:</dt>
	The Augmented BNF syntax [RFC5234] for the attribute is:		<dd pn="section-5.3-2.1.1.8">No</dd>
			<dt pn="section-5.3-2.1.1.9">Mux Category:</dt>
	user-id = 1*DIGIT		<dd pn="section-5.3-2.1.1.10">TBD</dd>
			</dl>
	DIGIT = <DIGIT defined in [RFC5234]>		</li>
			</ul>
	The maximum value of the attribute is determined by the		<t indent="0" pn="section-5.3-3">The Augmented BNF syntax <xref target="
	COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis].		RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/> for the
			attribute is:</t>
	]]></artwork>		<sourcecode name="" type="abnf" markers="false" pn="section-5.3-4">
	</figure>		user-id = 1*DIGIT
	<t>
	The SDP Offer/Answer procedures for the 'userid' attribute are defined in
	<xref target="sec:oa-offer-answer-proc"/>.
	</t>
	</section>
	<section title="SDP 'floorid' Attribute" anchor="sec:floorid-attr">
	<t>
	This section defines the SDP 'floorid' media-level attribute. The attribut
	e conveys a floor identifier, using decimal integer
	representation, and optionally pointers to one or more BFCP-controlled med
	ia streams.
	</t>
	<figure>
	<artwork type='abnf'><![CDATA[
	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 defined in [RFC5234]>
	token = <token defined in [RFC4566]>
	The maximum value of the attribute is determined by the
	FLOOR-ID format [I-D.ietf-bfcpbis-rfc4582bis].
	]]></artwork>
	</figure>
	<t>
	The floor identifier value is the integer representation of the Floor ID t
	o be used in BFCP. Each media stream
	pointer value is associated with an SDP 'label' attribute <xref target="RF
	C4574"/> of a media stream.
	</t>
	<t>
	The SDP Offer/Answer procedures for the 'floorid' attribute are defined in
	<xref target="sec:oa-offer-answer-proc"/>.
	</t>
	<t><list style="empty">
	<t>
	Note: In <xref target="RFC4583"/> 'm-stream' was erroneously used in <xref
	target="sec:example"/>. Although the example was non-normative, it is
	implemented by some vendors and occurs in cases where the endpoint is will
	ing to act as a server. Therefore, it is RECOMMENDED to support parsing and
	interpreting 'm-stream' the same way as 'mstrm' when receiving.
	</t>
	</list></t>
	</section>
	<section title="SDP 'bfcpver' Attribute" anchor="sec:bfcp-version-attr">
	<t>
	This section defines the SDP 'bfcpver' media-level attribute. The attribut
	e is used to negotiate the
	BFCP version, using decimal integer representation.
	</t>
	<t>
	The Augmented BNF syntax <xref target="RFC5234"/> for the attributes is:
	</t>
	<figure>
	<artwork type='abnf'><![CDATA[
	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 defined in [RFC5234]>		DIGIT = &lt;DIGIT as defined in [RFC5234]&gt;</sourcecode>
			<t indent="0" pn="section-5.3-5">The maximum value of the attribute is d
			etermined by the
			COMMON-HEADER format <xref target="RFC8855" format="default" sectionFormat
			="of" derivedContent="RFC8855"/>.</t>
			<t indent="0" pn="section-5.3-6">
			The SDP Offer/Answer procedures for the 'userid' attribute are defined in
			<xref target="sec_oa-offer-answer-proc" format="default" sectionFormat="of" deri
			vedContent="Section 10"/>.
			</t>
			</section>
			<section anchor="sec_floorid-attr" numbered="true" toc="include" removeInR
			FC="false" pn="section-5.4">
			<name slugifiedName="name-sdp-floorid-attribute">SDP 'floorid' Attribute
			</name>
			<t indent="0" pn="section-5.4-1">
			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.</t>
			<ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.
			4-2">
			<li pn="section-5.4-2.1">
			<dl indent="3" newline="false" spacing="normal" pn="section-5.4-2.1.
			1">
			<dt pn="section-5.4-2.1.1.1">Attribute Name:</dt>
			<dd pn="section-5.4-2.1.1.2">floorid</dd>
			<dt pn="section-5.4-2.1.1.3">Attribute Value:</dt>
			<dd pn="section-5.4-2.1.1.4">floor-id</dd>
			<dt pn="section-5.4-2.1.1.5">Usage Level:</dt>
			<dd pn="section-5.4-2.1.1.6">media</dd>
			<dt pn="section-5.4-2.1.1.7">Charset Dependent:</dt>
			<dd pn="section-5.4-2.1.1.8">No</dd>
			<dt pn="section-5.4-2.1.1.9">Mux Category:</dt>
			<dd pn="section-5.4-2.1.1.10">TBD</dd>
			</dl>
			</li>
			</ul>
			<t indent="0" pn="section-5.4-3">The Augmented BNF syntax <xref target="
			RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/> for the
			attribute is:</t>
			<sourcecode name="" type="abnf" markers="false" pn="section-5.4-4">
			floor-id = 1*DIGIT SP "mstrm:" token *(SP token)
	The maximum value of the attribute is determined by the		DIGIT = &lt;DIGIT as defined in [RFC5234]&gt;
	COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis].		token = &lt;token as defined in [RFC8866]&gt;</sourcecode>
			<t indent="0" pn="section-5.4-5">The maximum value of the attribute is d
			etermined by the
			FLOOR-ID format <xref target="RFC8855" format="default" sectionFormat="of"
			derivedContent="RFC8855"/>.</t>
			<t indent="0" pn="section-5.4-6">The floor identifier value is the integ
			er representation of the
			Floor ID field value <xref target="RFC8855" format="default" sectionForm
			at="of" derivedContent="RFC8855"/> to be used in BFCP. Each media stream
			pointer value is associated with an SDP 'label' attribute <xref target="RF
			C4574" format="default" sectionFormat="of" derivedContent="RFC4574"/> of a media
			stream.
			</t>
			<t indent="0" pn="section-5.4-7">
			The SDP Offer/Answer procedures for the 'floorid' attribute are defined in
			<xref target="sec_oa-offer-answer-proc" format="default" sectionFormat="of" der
			ivedContent="Section 10"/>.
			</t>
			<aside pn="section-5.4-8">
			<t indent="0" pn="section-5.4-8.1">Note: In the first SDP example in
			<xref target="RFC4583" sectionFormat="of" section="9" format="default" deriv
			edLink="https://rfc-editor.org/rfc/rfc4583#section-9" derivedContent="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 will
			ing to act as a server. Therefore, it is <bcp14>RECOMMENDED</bcp14> to support p
			arsing and
			interpreting 'm-stream' the same way as 'mstrm' when receiving.</t>
			</aside>
			</section>
			<section anchor="sec_bfcp-version-attr" numbered="true" toc="include" remo
			veInRFC="false" pn="section-5.5">
			<name slugifiedName="name-sdp-bfcpver-attribute">SDP 'bfcpver' Attribute
			</name>
			<t indent="0" pn="section-5.5-1">
			This section defines the SDP 'bfcpver' media-level attribute. The
			attribute is used to negotiate the BFCP version, using decimal integer
			representation.
			</t>
			<ul empty="true" bare="false" indent="3" spacing="normal" pn="section-5.
			5-2">
			<li pn="section-5.5-2.1">
			<dl indent="3" newline="false" spacing="normal" pn="section-5.5-2.1.
			1">
			<dt pn="section-5.5-2.1.1.1">Attribute Name:</dt>
			<dd pn="section-5.5-2.1.1.2">bfcpver</dd>
			<dt pn="section-5.5-2.1.1.3">Attribute Value:</dt>
			<dd pn="section-5.5-2.1.1.4">bfcp-version</dd>
			<dt pn="section-5.5-2.1.1.5">Usage Level:</dt>
			<dd pn="section-5.5-2.1.1.6">media</dd>
			<dt pn="section-5.5-2.1.1.7">Charset Dependent:</dt>
			<dd pn="section-5.5-2.1.1.8">No</dd>
			<dt pn="section-5.5-2.1.1.9">Mux Category:</dt>
			<dd pn="section-5.5-2.1.1.10">TBD</dd>
			</dl>
			</li>
			</ul>
			<t indent="0" pn="section-5.5-3">The Augmented BNF syntax <xref target="
			RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/> for the
			attribute is:</t>
			<sourcecode name="" type="abnf" markers="false" pn="section-5.5-4">
			bfcp-version = version *(SP version)
			version = 1*DIGIT
	]]></artwork>		DIGIT = &lt;DIGIT as defined in [RFC5234]&gt;</sourcecode>
	</figure>		<t indent="0" pn="section-5.5-5">The maximum value of the attribute is d
	<t>		etermined by the
			COMMON-HEADER format <xref target="RFC8855" format="default" sectionFormat
			="of" derivedContent="RFC8855"/>.</t>
			<t indent="0" pn="section-5.5-6">
	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 attrib ute		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 attrib ute
	value representing the version MUST match the "Version" field that would b e presented in the BFCP COMMON-HEADER <xref target="I-D.ietf-bfcpbis-rfc4582bis" />.		value representing the version <bcp14>MUST</bcp14> match the version ("Ver ") field that would be presented in the BFCP COMMON‑HEADER <xref target="RFC8855 " format="default" sectionFormat="of" derivedContent="RFC8855"/>.
	The BFCP version that will eventually be used will be conveyed with a BFCP -level Hello/HelloAck.		The BFCP version that will eventually be used will be conveyed with a BFCP -level Hello/HelloAck.
	</t>		</t>
	<t>		<t indent="0" pn="section-5.5-7">
	Endpoints compliant with <xref target="RFC4583"/> might not always include		Endpoints compliant with <xref target="RFC4583" format="default" sectionFo
	the 'bfcpver'		rmat="of" derivedContent="RFC4583"/> might not always include the 'bfcpver'
	attribute in offers and answers. The attribute value, if present, MUST be		attribute in offers and answers. The attribute value, if present, <bcp14>M
	in accordance with		UST</bcp14> be in accordance with
	the definition of the Version field in <xref target="I-D.ietf-bfcpbis-rfc4		the definition of the version ("Ver") field in <xref target="RFC8855" form
	582bis"/>. If the		at="default" sectionFormat="of" derivedContent="RFC8855"/>. If the
	attribute is not present, endpoints MUST assume a default value in accorda		attribute is not present, endpoints <bcp14>MUST</bcp14> assume a default v
	nce with		alue in accordance with
	<xref target="I-D.ietf-bfcpbis-rfc4582bis"/>: when used over a reliable tr		<xref target="RFC8855" format="default" sectionFormat="of" derivedContent=
	ansport the default		"RFC8855"/>: when used over a reliable transport, the default
	attribute value is "1", and when used over an unreliable transport the def		attribute value is "1", and when used over an unreliable transport, the de
	ault attribute value		fault attribute value
	is "2". The value is inferred from the transport specified in the 'm' line		is "2". The value is inferred from the transport specified in the "m=" lin
	(<xref target="sec:m-line"/>)		e (<xref target="sec_m-line" format="default" sectionFormat="of" derivedContent=
	of the 'm' section associated with the stream.		"Section 4"/>)
	</t>		of the "m=" section associated with the stream.
	<t>		</t>
	The SDP Offer/Answer procedures for the 'bfcpver' attribute are defined in		<t indent="0" pn="section-5.5-8">
	<xref target="sec:oa-offer-answer-proc"/>.		The SDP Offer/Answer procedures for the 'bfcpver' attribute are defined in
	</t>		<xref target="sec_oa-offer-answer-proc" format="default" sectionFormat="of" der
	</section>		ivedContent="Section 10"/>.
			</t>
			</section>
	</section>		</section>
	<section title="Multiplexing Considerations" anchor="sec:mux-cons">		<section anchor="sec_mux-cons" numbered="true" toc="include" removeInRFC="fa
	<t>		lse" pn="section-6">
	<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> defines how multip		<name slugifiedName="name-multiplexing-considerations">Multiplexing Consid
	lexing of multiple media streams can be negotiated. This specification does not		erations</name>
	define		<t indent="0" pn="section-6-1">
	how BFCP streams can be multiplexed with other media streams. Therefore, a		<xref target="RFC8843" format="default" sectionFormat="of" derivedContent=
	BFCP stream MUST NOT be associated with a BUNDLE group <xref target="I-D.ietf-m		"RFC8843"/> defines how multiplexing of multiple media streams can be negotiated
	music-sdp-bundle-negotiation"/>.		. This specification does not define
			how BFCP streams can be multiplexed with other media streams. Therefore, a
			BFCP stream <bcp14>MUST NOT</bcp14> be associated with a BUNDLE group <xref tar
			get="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843"/>.
	Note that BFCP-controlled media streams might be multiplexed with other me dia streams.		Note that BFCP-controlled media streams might be multiplexed with other me dia streams.
	</t>		</t>
	<t>		<t indent="0" pn="section-6-2">
	<xref target="I-D.ietf-mmusic-sdp-mux-attributes"/> defines the mux catego		<xref target="RFC8859" format="default" sectionFormat="of" derivedContent=
	ries for the SDP		"RFC8859"/> defines the mux categories for the SDP
	attributes defined in this specification, except for the 'bfcpver' attribu		attributes defined in this specification, except for the 'bfcpver' attribu
	te. <xref target="tab:mux-tbd"/> defines the mux category		te. <xref target="tab_mux-tbd" format="default" sectionFormat="of" derivedConten
			t="Table 2"/> defines the mux category
	for the 'bfcpver' attribute:		for the 'bfcpver' attribute:
	</t>		</t>
	<texttable title="Multiplexing Attribute Analysis" anchor="tab:mux-tbd">		<table anchor="tab_mux-tbd" align="center" pn="table-2">
	<ttcol>Name</ttcol>		<name slugifiedName="name-multiplexing-attribute-anal">Multiplexing Attr
	<ttcol>Notes</ttcol>		ibute Analysis</name>
	<ttcol>Level</ttcol>		<thead>
	<ttcol>Mux Category</ttcol>		<tr>
			<th align="left" colspan="1" rowspan="1">Name</th>
	<c>bfcpver</c>		<th align="left" colspan="1" rowspan="1">Notes</th>
	<c>Needs further analysis in a separate specification</c>		<th align="left" colspan="1" rowspan="1">Level</th>
	<c>M</c>		<th align="left" colspan="1" rowspan="1">Mux Category</th>
	<c>TBD</c>		</tr>
	</texttable>		</thead>
	</section>		<tbody>
			<tr>
	<section title="BFCP Connection Management" anchor="sec:bfcp-connection">		<td align="left" colspan="1" rowspan="1">bfcpver</td>
	<t>		<td align="left" colspan="1" rowspan="1">Needs further analysis in a
			separate specification</td>
			<td align="left" colspan="1" rowspan="1">M</td>
			<td align="left" colspan="1" rowspan="1">TBD</td>
			</tr>
			</tbody>
			</table>
			</section>
			<section anchor="sec_bfcp-connection" numbered="true" toc="include" removeIn
			RFC="false" pn="section-7">
			<name slugifiedName="name-bfcp-connection-management">BFCP Connection Mana
			gement</name>
			<t indent="0" pn="section-7-1">
	BFCP streams can use TCP or UDP as the underlying transport. Endpoints exc hanging BFCP messages over UDP send the BFCP messages towards the peer		BFCP streams can use TCP or UDP as the underlying transport. Endpoints exc hanging BFCP messages over UDP send the BFCP messages towards the peer
	using the connection address and port provided in the SDP 'c' and 'm' line		using the connection address and port provided in the SDP "c=" and "m=" li
	s. TCP connection management is more complicated and is described in		nes. TCP connection management is more complicated and is described in
	the following Section.		the following section.
	</t>		</t>
	<t><list style="empty">		<aside pn="section-7-2">
	<t>Note: When using Interactive Connectivity Establishment (ICE) <xref tar		<t indent="0" pn="section-7-2.1">Note: When using Interactive Connectivi
	get="RFC8445"/>, TCP/DTLS/BFCP, or UDP/TLS/BFCP, the straight-forward procedures		ty Establishment
	for connection management as UDP/BFCP described above apply.		(ICE) <xref target="RFC8445" format="default" sectionFormat="of" derivedC
	TCP/TLS/BFCP follows the same procedures as TCP/BFCP and is described belo		ontent="RFC8445"/>, TCP/DTLS/BFCP, or
	w.</t>		UDP/TLS/BFCP, the straightforward procedures for connection management
	</list></t>		via UDP/BFCP, as described above, apply.
	<section title="TCP Connection Management" anchor="sec:tcp-connection">		TCP/TLS/BFCP follows the same procedures as TCP⁠/BFCP and is described bel
	<t>		ow.</t>
	The management of the TCP connection used to transport BFCP messages is		</aside>
	performed using the SDP 'setup' and 'connection' attributes <xref target="RFC414		<section anchor="sec_tcp-connection" numbered="true" toc="include" removeI
	5"/>.		nRFC="false" pn="section-7.1">
			<name slugifiedName="name-tcp-connection-management">TCP Connection Mana
			gement</name>
			<t indent="0" pn="section-7.1-1">
			The management of the TCP connection used to transport BFCP messages is
			performed using the SDP 'setup' and 'connection' attributes <xref target="RFC414
			5" format="default" sectionFormat="of" derivedContent="RFC4145"/>.
	The 'setup' attribute indicates which of the endpoints initiates the TCP connection. The 'connection' attribute handles TCP connection re-establishment.		The 'setup' attribute indicates which of the endpoints initiates the TCP connection. The 'connection' attribute handles TCP connection re-establishment.
			</t>
			<t indent="0" pn="section-7.1-2">
			The BFCP specification <xref target="RFC8855" format="default" sectionFo
			rmat="of" derivedContent="RFC8855"/> describes a number of situations when the T
			CP connection between a floor control client
			and the floor control server needs to be re-established. However,
			<xref target="RFC8855" format="default" sectionFormat="of" derivedContent
			="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.</t>
			<t indent="0" pn="section-7.1-3">
			When the existing TCP connection is closed and re-established following
			the rules in <xref target="RFC8855" format="default" sectionFormat="of" derivedC
			ontent="RFC8855"/>, the floor control client
			<bcp14>MUST</bcp14> send an offer towards the floor control server in or
			der to re-establish the connection. If a TCP connection cannot deliver a BFCP me
			ssage and times out,
			the endpoint that attempted to send the message (i.e., the one that dete
			cted the TCP timeout) <bcp14>MUST</bcp14> send an offer in order to re-establish
			the TCP connection.
			</t>
			<t indent="0" pn="section-7.1-4">
			Endpoints that use the offer/answer mechanism to negotiate TCP connectio
			ns <bcp14>MUST</bcp14> support the 'setup' and 'connection' attributes.
			</t>
			</section>
			</section>
			<section anchor="sec_authentication" numbered="true" toc="include" removeInR
			FC="false" pn="section-8">
			<name slugifiedName="name-tls-dtls-considerations">TLS/DTLS Considerations
			</name>
			<t indent="0" pn="section-8-1">
			When DTLS is used with UDP, the generic procedures defined in <xref targe
			t="RFC8842" sectionFormat="of" section="5" format="default" derivedLink="https:/
			/rfc-editor.org/rfc/rfc8842#section-5" derivedContent="RFC8842"/>
			<bcp14>MUST</bcp14> be followed.
	</t>		</t>
	<t>		<t indent="0" pn="section-8-2">
	The BFCP specification <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> desc		When TLS is used with TCP, once the underlying connection is established,
	ribes a number of situations when the TCP connection between a floor control cli		the answerer always acts as the TLS server.
	ent		If the TCP connection is lost, the active endpoint <xref target="RFC4583"
	and the floor control server needs to be re-established. However, that s		format="default" sectionFormat="of" derivedContent="RFC4583"/> is responsible f
	pecification does not describe the re-establishment process because this process		or re-establishing the TCP connection. Unless a new
	depends on how the connection was established in the first place. Endpoi		TLS connection is negotiated, subsequent SDP offers and answers will not
	nts using the offer/answer mechanism follow the following rules.		impact the previously negotiated TLS roles.
	</t>		</t>
	<t>		<aside pn="section-8-3">
	When the existing TCP connection is closed and re-established following		<t indent="0" pn="section-8-3.1">Note: For TLS, it was decided to keep t
	the rules in <xref target="I-D.ietf-bfcpbis-rfc4582bis"/>, the floor control cli		he original procedures in <xref target="RFC4583" format="default" sectionFormat=
	ent		"of" derivedContent="RFC4583"/> to determine which endpoint
	MUST send an offer towards the floor control server in order to re-estab		acts as the TLS server, in order to retain backward compatibility.</t>
	lish the connection. If a TCP connection cannot deliver a BFCP message and times		</aside>
	out,		</section>
	the endpoint that attempted to send the message (i.e., the one that dete		<section anchor="sec_ice-considerations" numbered="true" toc="include" remov
	cted the TCP timeout) MUST send an offer in order to re-establish the TCP connec		eInRFC="false" pn="section-9">
	tion.		<name slugifiedName="name-ice-considerations">ICE Considerations</name>
			<t indent="0" pn="section-9-1">
			Generic SDP offer/answer procedures for ICE are defined in <xref target="R
			FC8839" format="default" sectionFormat="of" derivedContent="RFC8839"/>.
	</t>		</t>
	<t>		<t indent="0" pn="section-9-2">
	Endpoints that use the offer/answer mechanism to negotiate TCP connectio		When BFCP is used with UDP-based ICE candidates <xref target="RFC8445" for
	ns MUST support the 'setup' and 'connection' attributes.		mat="default" sectionFormat="of" derivedContent="RFC8445"/>, the procedures for
			UDP/TLS/BFCP are used.
	</t>		</t>
	</section>		<t indent="0" pn="section-9-3">
	</section>		When BFCP is used with TCP-based ICE candidates <xref target="RFC6544" for
			mat="default" sectionFormat="of" derivedContent="RFC6544"/>, the procedures for
	<section title="TLS/DTLS Considerations" anchor="sec:authentication">		TCP/DTLS/BFCP are used.
	<t>		</t>
	When DTLS is used with UDP, the generic procedures defined in Section 5 o		<t indent="0" pn="section-9-4">
	f <xref target="I-D.ietf-mmusic-dtls-sdp"/>		Based on the procedures defined in <xref target="RFC8842" format="default"
	MUST be followed.		sectionFormat="of" derivedContent="RFC8842"/>, endpoints treat all ICE candidat
	</t>		e pairs associated with a BFCP stream on top of a DTLS association
	<t>		as part of the same DTLS association. Thus, there will only be one BFCP ha
	When TLS is used with TCP, once the underlying connection is established,		ndshake and one DTLS handshake
	the answerer always acts as the TLS server.		even if there are multiple valid candidate pairs, and even if BFCP media
	If the TCP connection is lost, the active endpoint <xref target="RFC4583"		is shifted between candidate pairs (including switching between UDP
	/> is responsible for re-establishing the TCP connection. Unless a new		candidate pairs and TCP candidate pairs) prior to nomination. If new
	TLS connection is negotiated, subsequent SDP offers and answers will not		candidates are added, they will also be part of the same DTLS association.
	impact the previously negotiated TLS roles.		</t>
	</t>		<t indent="0" pn="section-9-5">
	<t><list style="empty">		In order to maximize the likelihood of interoperability between the endpoi
	<t>		nts, all ICE-enabled BFCP-over-DTLS endpoints <bcp14>SHOULD</bcp14>
	Note: For TLS, it was decided to keep the original procedures in <xref
	target="RFC4583"/> to determine which endpoint
	acts as the TLS server in order to retain backwards compatibility.
	</t>
	</list></t>
	</section>
	<section title="ICE Considerations" anchor="sec:ice-considerations">
	<t>
	Generic SDP offer/answer procedures for Interactive Connectivity Establish
	ment (ICE) are defined in <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>.
	</t>
	<t>
	When BFCP is used with UDP based ICE candidates <xref target="RFC8445"/> t
	hen the procedures for UDP/TLS/BFCP are used.
	</t>
	<t>
	When BFCP is used with TCP based ICE candidates <xref target="RFC6544"/> t
	hen the procedures for TCP/DTLS/BFCP are used.
	</t>
	<t>
	Based on the procedures defined in <xref target="I-D.ietf-mmusic-dtls-sdp"
	/>, 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 ha
	ndshake and one DTLS handshake even if there are multiple valid candidate pairs,
	and if BFCP media is shifted between candidate pairs (including switching
	between UDP to TCP candidate pairs) prior to nomination. If new candidates are a
	dded,
	they will also be part of the same DTLS association.
	</t>
	<t>
	In order to maximize the likelihood of interoperability between the endpoi
	nts, all ICE enabled BFCP-over-DTLS endpoints SHOULD
	implement support for UDP/TLS/BFCP.		implement support for UDP/TLS/BFCP.
	</t>
	<t>
	When an SDP offer or answer conveys multiple ICE candidates for a BFCP str
	eam, UDP based candidates SHOULD be included and
	the default candidate SHOULD be chosen from one of those UDP candidates. I
	f 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'.
	</t>
	<t><list style="empty">
	<t>Note: Usage of ICE with protocols other than UDP/TLS/BFCP and TCP/DTLS/
	BFCP is outside of scope for this specification.</t>
	</list></t>
	</section>
	<section title="SDP Offer/Answer Procedures" anchor="sec:oa-offer-answer-proc"
	>
	<t>
	This section defines the SDP offer/answer <xref target="RFC3264"/> procedu
	res for negotiating and establishing a BFCP stream.
	Generic procedures for DTLS are defined in <xref target="I-D.ietf-mmusic-d
	tls-sdp"/>. Generic procedures for TLS are defined
	in <xref target="RFC8122"/>.
	</t>
	<t>
	This section only defines the BFCP-specific procedures. Unless explicitly
	stated otherwise, the procedures apply to an 'm' section describing a BFCP strea
	m.
	If an offer or answer contains multiple 'm' sections describing BFCP strea
	ms, the procedures are applied independently to each stream.
	</t>
	<t>
	Within this document, 'initial offer' refers to the first offer, within an
	SDP session (e.g. a SIP
	dialog when the Session Initiation Protocol (SIP) <xref target="RFC3261"/>
	is used to carry SDP) in which the offerer
	indicates that it wants to negotiate the establishment of a BFCP stream.
	</t>
	<t>
	If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 'UDP/T
	LS/BFCP', the offerer and answerer follow the generic procedures
	defined in <xref target="RFC8122"/>.
	</t>
	<t>
	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 <xref target=
	"RFC4145"/>.
	</t>
	<t>
	If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 'TCP/DTLS/BFC
	P', the offerer and anwerer use
	the SDP 'connection' attribute according to the procedures in <xref target
	="RFC4145"/>.
	</t>
	<t><list style="empty">
	<t>Note: The use of source-specific SDP parameters <xref target="RFC5576"/
	> is not defined for BFCP streams.</t>
	</list></t>
	<section title="Generating the Initial SDP Offer" anchor="oa-gen-initial-off
	er">
	<t>
	When the offerer creates an initial offer, the offerer MUST include an S
	DP 'floorctrl' attribute (<xref target="sec:floorctrl-attr"/>)
	and an SDP 'bfcpver' attribute (<xref target="sec:bfcp-version-attr"/>)
	in the 'm' section.
	</t>		</t>
	<t>		<t indent="0" pn="section-9-6">
	In addition, if the offerer includes an SDP 'floorctrl' attribute with '		When an SDP offer or answer conveys multiple ICE candidates for a BFCP str
	s-only' or 'c-s' attribute values in the offer, the offerer:		eam, UDP-based candidates <bcp14>SHOULD</bcp14> be included and
			the default candidate <bcp14>SHOULD</bcp14> be chosen from one of those UD
			P candidates. If UDP transport is used for the default candidate,
			then the "m=" line proto value <bcp14>MUST</bcp14> be 'UDP/TLS/BFCP'. If T
			CP transport is used for the default candidate, the "m=" line proto
			value <bcp14>MUST</bcp14> be 'TCP/DTLS/BFCP'.
	</t>		</t>
	<t><list style="symbols">		<aside pn="section-9-7">
	<t>MUST include an SDP 'confid' attribute (<xref target="sec:confid-at		<t indent="0" pn="section-9-7.1">Note: Usage of ICE with protocols other
	tr"/>) in the 'm' section; and</t>		than UDP/TLS/BFCP and TCP/DTLS/BFCP is out of scope for this specification.</t>
	<t>MUST include an SDP 'userid' attribute (<xref target="sec:userid-at		</aside>
	tr"/>) in the 'm' section; and</t>
	<t>MUST include an SDP 'floorid' attribute (<xref target="sec:floorid-
	attr"/>) in the 'm' section; and</t>
	<t>MUST include an SDP 'label' attribute (<xref target="RFC4574"/>) wi
	th the 'm' section of each BFCP-controlled media stream.</t>
	</list></t>
	<t><list style="empty">
	<t>
	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 value in the offe
	r,
	the attribute values above will only be used if it is determined (<xre
	f target="sec:floorctrl-attr"/>) that the offerer will act as floor control serv
	er.
	</t>
	</list></t>
	</section>		</section>
			<section anchor="sec_oa-offer-answer-proc" numbered="true" toc="include" rem
	<section title="Generating the SDP Answer" anchor="oa-gen-answer">		oveInRFC="false" pn="section-10">
	<t>		<name slugifiedName="name-sdp-offer-answer-procedures">SDP Offer/Answer Pr
	When the answerer receives an offer that contains an 'm' section describ		ocedures</name>
	ing a BFCP stream, the answerer MUST check whether it supports		<t indent="0" pn="section-10-1">
	one or more of the BFCP versions supported by the offerer (<xref target=		This section defines the SDP offer/answer <xref target="RFC3264" format="d
	"sec:bfcp-version-attr"/>). If the answerer does not support		efault" sectionFormat="of" derivedContent="RFC3264"/> procedures for negotiating
	any of the BFCP versions, it MUST NOT accept the 'm' section. Otherwise,		and establishing a BFCP stream.
	if the answerer accepts the 'm' section, it:		Generic procedures for DTLS are defined in <xref target="RFC8842" format="
	</t>		default" sectionFormat="of" derivedContent="RFC8842"/>. Generic procedures for T
	<t><list style="symbols">		LS are defined
	<t>MUST insert a corresponding 'm' section in the answer, with an iden		in <xref target="RFC8122" format="default" sectionFormat="of" derivedConte
	tical 'm' line proto value <xref target="RFC3264"/>; and</t>		nt="RFC8122"/>.
	<t>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</t>
	<t>MUST, if the offer contained an SDP 'floorctrl' attribute, include
	a 'floorctrl' attribute in the 'm' section.</t>
	</list></t>
	<t>
	In addition, if the answerer includes an SDP 'floorctrl' attribute with
	an 's-only' attribute value in the answer, the answerer:
	</t>		</t>
	<t><list style="symbols">		<t indent="0" pn="section-10-2">
	<t>MUST include an SDP 'confid' attribute in the 'm' section; and</t>		This section only defines the BFCP-specific procedures. Unless explicitly
	<t>MUST include an SDP 'userid' attribute in the 'm' section; and</t>		stated otherwise, the procedures apply to an "m=" section describing a BFCP stre
	<t>MUST include an SDP 'floorid' attribute in the 'm' section; and</t>		am.
	<t>MUST include an SDP 'label' attribute in the 'm' section of each BF		If an offer or answer contains multiple "m=" sections describing BFCP stre
	CP-controlled media stream.</t>		ams, the procedures are applied independently to each stream.
	</list></t>
	<t><list style="empty">
	<t>
	Note: An offerer compliant with <xref target="RFC4583"/> might not inc
	lude 'floorctrl' and 'bfcpver' attributes in offers, in which cases
	the default values apply.
	</t>
	</list></t>
	<t>
	Once the answerer has sent the answer, the answerer:
	</t>		</t>
	<t><list style="symbols">		<t indent="0" pn="section-10-3">
	<t>MUST, if the answerer is the active endpoint, and if a TCP connecti		Within this document, 'initial offer' refers to the first offer within
	on associated with the 'm' section is to be established (or re-established),		an SDP session (e.g., a Session Initiation Protocol (SIP)
	initiate the establishing of the TCP connection; and</t>		dialog when SIP <xref target="RFC3261" format="default" sectionFormat="of"
	<t>MUST, if the answerer is the active endpoint, and if an TLS/DTLS co		derivedContent="RFC3261"/> is used to carry SDP) in which the offerer
	nnection associated with the 'm' section is to be established (or re-established		indicates that it wants to negotiate the establishment of a BFCP stream.
	),
	initiate the establishing of the TLS/DTLS connection (by sending a
	ClientHello message).</t>
	</list></t>
	<t>
	If the answerer does not accept the 'm' section in the offer, it MUST as
	sign a zero port value to the 'm' line of the corresponding 'm' section in the a
	nswer.
	In addition, the answerer MUST NOT establish a TCP connection or a TLS/D
	TLS connection associated with the 'm' section.
	</t>		</t>
	</section>		<t indent="0" pn="section-10-4">
			If the "m=" line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP', or 'UDP
	<section title="Offerer Processing of the SDP Answer" anchor="oa-offerer-pro		/TLS/BFCP', the offerer and answerer follow the generic procedures
	cessing-answer">		defined in <xref target="RFC8122" format="default" sectionFormat="of" deri
	<t>		vedContent="RFC8122"/>.
	When the offerer receives an answer that contains an 'm' section with a
	non-zero port value, describing a BFCP stream, the offerer:
	</t>		</t>
	<t><list style="symbols">		<t indent="0" pn="section-10-5">
	<t>MUST, if the offerer is the active endpoint, and if a TCP connectio		If the "m=" line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP⁠/DTLS⁠/TC
	n associated with the 'm' section is to be established (or re-established),		P', or 'UDP/TLS/BFCP', the offerer and answerer
	initiate the establishing of the TCP connection; and</t>		use the SDP 'setup' attribute according to the procedures in <xref target=
	<t>MUST, if the offerer is the active endpoint, and if an TLS/DTLS con		"RFC4145" format="default" sectionFormat="of" derivedContent="RFC4145"/>.
	nection associated with the 'm' section is to be established (or re-established)
	,
	initiate the establishing of the TLS/DTLS connection (by sending a
	ClientHello message).</t>
	</list></t>
	<t>
	Note: An answerer compliant with <xref target="RFC4583"/> might not incl
	ude 'floorctrl' and 'bfcpver' attributes in answers,
	in which cases the default values apply.
	</t>		</t>
	<t>		<t indent="0" pn="section-10-6">
	If the 'm' line in the answer contains a zero port value, or if the offe		If the "m=" line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', or 'TCP/DTLS/B
	rer for some other reason does not accept the answer (e.g., if the answerer only		FCP', the offerer and answerer use
	indicates support of BFCP versions not supported by the offerer), the of		the SDP 'connection' attribute according to the procedures in <xref target
	ferer MUST NOT establish a TCP connection or a TLS/DTLS connection associated wi		="RFC4145" format="default" sectionFormat="of" derivedContent="RFC4145"/>.
	th the 'm' section.
	</t>		</t>
	</section>		<aside pn="section-10-7">
			<t indent="0" pn="section-10-7.1">Note: The use of source-specific SDP p
	<section title="Modifying the Session" anchor="oa-mod-session">		arameters <xref target="RFC5576" format="default" sectionFormat="of" derivedCont
	<t>		ent="RFC5576"/> is not defined for BFCP streams.</t>
			</aside>
			<section anchor="oa-gen-initial-offer" numbered="true" toc="include" remov
			eInRFC="false" pn="section-10.1">
			<name slugifiedName="name-generating-the-initial-sdp-">Generating the In
			itial SDP Offer</name>
			<t indent="0" pn="section-10.1-1">
			When the offerer creates an initial offer, the offerer <bcp14>MUST</bcp1
			4> include an SDP 'floorctrl' attribute (<xref target="sec_floorctrl-attr" forma
			t="default" sectionFormat="of" derivedContent="Section 5.1"/>)
			and an SDP 'bfcpver' attribute (<xref target="sec_bfcp-version-attr" for
			mat="default" sectionFormat="of" derivedContent="Section 5.5"/>) in the "m=" sec
			tion.
			</t>
			<t indent="0" pn="section-10.1-2">
			In addition, if the offerer includes an SDP 'floorctrl' attribute with "
			s-only" or "c-s" attribute values in the offer, the offerer
			</t>
			<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
			0.1-3">
			<li pn="section-10.1-3.1">
			<bcp14>MUST</bcp14> include an SDP 'confid' attribute (<xref target=
			"sec_confid-attr" format="default" sectionFormat="of" derivedContent="Section 5.
			2"/>) in the "m=" section,</li>
			<li pn="section-10.1-3.2">
			<bcp14>MUST</bcp14> include an SDP 'userid' attribute (<xref target=
			"sec_userid-attr" format="default" sectionFormat="of" derivedContent="Section 5.
			3"/>) in the "m=" section,</li>
			<li pn="section-10.1-3.3">
			<bcp14>MUST</bcp14> include an SDP 'floorid' attribute (<xref target
			="sec_floorid-attr" format="default" sectionFormat="of" derivedContent="Section
			5.4"/>) in the "m=" section, and</li>
			<li pn="section-10.1-3.4">
			<bcp14>MUST</bcp14> include an SDP 'label' attribute <xref target="R
			FC4574" format="default" sectionFormat="of" derivedContent="RFC4574"/> with the
			"m=" section of each BFCP-controlled media stream.</li>
			</ul>
			<aside pn="section-10.1-4">
			<t indent="0" pn="section-10.1-4.1">Note: If the offerer includes an S
			DP '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
			(<xref target="sec_floorctrl-attr" format="default" sectionFormat="of" de
			rivedContent="Section 5.1"/>) that the
			offerer will act as a floor control server.</t>
			</aside>
			</section>
			<section anchor="oa-gen-answer" numbered="true" toc="include" removeInRFC=
			"false" pn="section-10.2">
			<name slugifiedName="name-generating-the-sdp-answer">Generating the SDP
			Answer</name>
			<t indent="0" pn="section-10.2-1">
			When the answerer receives an offer that contains an "m=" section descri
			bing a BFCP stream, the answerer <bcp14>MUST</bcp14> check whether it supports
			one or more of the BFCP versions supported by the offerer (<xref target=
			"sec_bfcp-version-attr" format="default" sectionFormat="of" derivedContent="Sect
			ion 5.5"/>). If the answerer does not support
			any of the BFCP versions, it <bcp14>MUST NOT</bcp14> accept the "m="
			section. Otherwise, if the answerer accepts the "m=" section, the answere
			r
			</t>
			<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
			0.2-2">
			<li pn="section-10.2-2.1">
			<bcp14>MUST</bcp14> insert a corresponding "m=" section in the
			answer, with an identical "m=" line proto value <xref target="RFC8866"
			format="default" sectionFormat="of" derivedContent="RFC8866"/>,</li>
			<li pn="section-10.2-2.2">
			<bcp14>MUST</bcp14> include a 'bfcpver' attribute in the "m=" sectio
			n; the versions indicated by the answer <bcp14>MUST</bcp14> be the same or a sub
			set of the versions indicated by the offerer in the corresponding offer, and</li
			>
			<li pn="section-10.2-2.3">
			<bcp14>MUST</bcp14>, if the offer contained an SDP 'floorctrl' attri
			bute, include a 'floorctrl' attribute in the "m=" section.</li>
			</ul>
			<t indent="0" pn="section-10.2-3">
			In addition, if the answerer includes an SDP 'floorctrl' attribute with
			an "s-only" attribute value in the answer, the answerer
			</t>
			<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
			0.2-4">
			<li pn="section-10.2-4.1">
			<bcp14>MUST</bcp14> include an SDP 'confid' attribute in the "m=" se
			ction,</li>
			<li pn="section-10.2-4.2">
			<bcp14>MUST</bcp14> include an SDP 'userid' attribute in the "m=" se
			ction,</li>
			<li pn="section-10.2-4.3">
			<bcp14>MUST</bcp14> include an SDP 'floorid' attribute in the "m=" s
			ection, and</li>
			<li pn="section-10.2-4.4">
			<bcp14>MUST</bcp14> include an SDP 'label' attribute in the "m=" sec
			tion of each BFCP-controlled media stream.</li>
			</ul>
			<aside pn="section-10.2-5">
			<t indent="0" pn="section-10.2-5.1">Note: An offerer compliant with <x
			ref target="RFC4583" format="default" sectionFormat="of" derivedContent="RFC4583
			"/> might not include 'floorctrl' and 'bfcpver' attributes in offers, in which c
			ase
			the default values apply.</t>
			</aside>
			<t indent="0" pn="section-10.2-6">
			Once the answerer has sent the answer, the answerer
			</t>
			<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
			0.2-7">
			<li pn="section-10.2-7.1">
			<bcp14>MUST</bcp14>, if the answerer is the active endpoint and if a
			TCP connection associated with the "m=" section is to be established (or re-est
			ablished),
			initiate the establishment of the TCP connection, and</li>
			<li pn="section-10.2-7.2">
			<bcp14>MUST</bcp14>, if the answerer is the active endpoint and if a
			TLS/DTLS connection associated with the "m=" section is to be established (or r
			e-established),
			initiate the establishment of the TLS/DTLS connection (by sending a
			ClientHello message).</li>
			</ul>
			<t indent="0" pn="section-10.2-8">
			If the answerer does not accept the "m=" section in the offer, it <bcp14
			>MUST</bcp14> assign a zero port value to the "m=" line of the corresponding "m=
			" section in the answer.
			In addition, the answerer <bcp14>MUST NOT</bcp14> establish a TCP connec
			tion or a TLS/DTLS connection associated with the "m=" section.
			</t>
			</section>
			<section anchor="oa-offerer-processing-answer" numbered="true" toc="includ
			e" removeInRFC="false" pn="section-10.3">
			<name slugifiedName="name-offerer-processing-of-the-s">Offerer Processin
			g of the SDP Answer</name>
			<t indent="0" pn="section-10.3-1">
			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</t>
			<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
			0.3-2">
			<li pn="section-10.3-2.1">
			<bcp14>MUST</bcp14>, if the offerer is the active endpoint and if a
			TCP connection associated with the "m=" section is to be established (or re-esta
			blished),
			initiate the establishment of the TCP connection, and</li>
			<li pn="section-10.3-2.2">
			<bcp14>MUST</bcp14>, 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).</li>
			</ul>
			<aside pn="section-10.3-3">
			<t indent="0" pn="section-10.3-3.1">Note: An answerer compliant with <
			xref target="RFC4583" format="default" sectionFormat="of" derivedContent="RFC458
			3"/> might not include 'floorctrl' and 'bfcpver' attributes in answers,
			in which case the default values apply.</t>
			</aside>
			<t indent="0" pn="section-10.3-4">
			If the "m=" line in the answer contains a zero port value or if the offe
			rer 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 of
			ferer <bcp14>MUST NOT</bcp14> establish a TCP connection or a TLS/DTLS connectio
			n associated with the "m=" section.
			</t>
			</section>
			<section anchor="oa-mod-session" numbered="true" toc="include" removeInRFC
			="false" pn="section-10.4">
			<name slugifiedName="name-modifying-the-session">Modifying the Session</
			name>
			<t indent="0" pn="section-10.4-1">
	When an offerer sends an updated offer, in order to modify a previously established BFCP stream, it follows the procedures		When an offerer sends an updated offer, in order to modify a previously established BFCP stream, it follows the procedures
	in <xref target="oa-gen-initial-offer"/>, with the following exceptions:		in <xref target="oa-gen-initial-offer" format="default" sectionFormat="o
	</t>		f" derivedContent="Section 10.1"/>, with the following exceptions:
	<t><list style="symbols">		</t>
	<t>If the BFCP stream is carried on top of TCP, and if the offerer doe		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
	s not want to re-establish an existing TCP connection, the offerer MUST include		0.4-2">
	an SDP 'connection' attribute with a value of "existing", in the 'm		<li pn="section-10.4-2.1">If the BFCP stream is carried on top of TCP
	' section; and</t>		and if the offerer
	<t>If the offerer wants to disable a previously established BFCP strea		does not want to re-establish an existing TCP connection, the
	m, it MUST assign a zero port value to the 'm' line associated with the		offerer <bcp14>MUST</bcp14> include in the "m=" section
	BFCP connection, following the procedures in <xref target="RFC3264"		an SDP 'connection' attribute with a value of "existing", and</li>
	/>.</t>		<li pn="section-10.4-2.2">If the offerer wants to disable a previously
	</list></t>		established BFCP stream, it <bcp14>MUST</bcp14> assign a zero port value to the
			"m=" line associated with the
			BFCP connection, following the procedures in <xref target="RFC3264"
			format="default" sectionFormat="of" derivedContent="RFC3264"/>.</li>
			</ul>
			</section>
	</section>		</section>
			<section anchor="sec_example" numbered="true" toc="include" removeInRFC="fal
	</section>		se" pn="section-11">
			<name slugifiedName="name-examples">Examples</name>
	<section title="Examples" anchor="sec:example">		<t indent="0" pn="section-11-1">For the purpose of brevity, the main porti
	<t>For the purpose of brevity, the main portion of the session description i		on of the session description is omitted in the examples, which only show "m=" s
	s omitted in the examples, which only show 'm' sections and their 'm' lines and		ections and their "m=" lines and attributes.</t>
	attributes.</t>		<t indent="0" pn="section-11-2">The following is an example of an offer se
	<t>The following is an example of an offer sent by a conference server to a		nt by a conference server to a client.</t>
	client.</t>		<sourcecode name="" type="sdp" markers="false" pn="section-11-3">
	<figure>
	<artwork>
	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
	a=floorctrl:c-only s-only		a=floorctrl:c-only s-only
	a=confid:4321		a=confid:4321
	a=userid:1234		a=userid:1234
	a=floorid:1 mstrm:10		a=floorid:1 mstrm:10
	a=floorid:2 mstrm:11		a=floorid:2 mstrm:11
	a=bfcpver:1 2		a=bfcpver:1 2
	m=audio 50002 RTP/AVP 0		m=audio 50002 RTP/AVP 0
	a=label:10		a=label:10
	m=video 50004 RTP/AVP 31		m=video 50004 RTP/AVP 31
	a=label:11		a=label:11</sourcecode>
	</artwork>		<t indent="0" pn="section-11-4">Note that due to RFC formatting convention
	</figure>		s, this document splits the
	<t>Note that due to RFC formatting conventions, this document splits SDP acr		SDP entries across lines whose content would exceed the maximum line
	oss lines whose content would exceed 72 characters. A backslash character marks		length. A backslash character ("\") marks where this line folding has take
	where this line folding has taken place. This backslash and its trailing CRLF an		n place. This backslash and its trailing CRLF and whitespace would not appear in
	d whitespace would not appear in actual SDP content.</t>		actual SDP content.</t>
	<t>The following is the answer returned by the client.</t>		<t indent="0" pn="section-11-5">The following is the answer returned by th
	<figure>		e client.</t>
	<artwork>		<sourcecode name="" type="sdp" markers="false" pn="section-11-6">
	m=application 9 TCP/TLS/BFCP *		m=application 9 TCP/TLS/BFCP *
	a=setup:active		a=setup:active
	a=connection:new		a=connection:new
	a=fingerprint:sha-256 \		a=fingerprint:sha-256 \
	6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \		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		DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
	a=floorctrl:c-only		a=floorctrl:c-only
	a=bfcpver:1		a=bfcpver:1
	m=audio 55000 RTP/AVP 0		m=audio 55000 RTP/AVP 0
	m=video 55002 RTP/AVP 31		m=video 55002 RTP/AVP 31</sourcecode>
	</artwork>		<t indent="0" pn="section-11-7">A similar example using an unreliable tran
	</figure>		sport and DTLS is shown below, where the offer is sent from a client.</t>
			<sourcecode name="" type="sdp" markers="false" pn="section-11-8">
	<t>A similar example using unreliable transport and DTLS is shown below, where t
	he offer is sent from a client.</t>
	<figure>
	<artwork>
	m=application 50000 UDP/TLS/BFCP *		m=application 50000 UDP/TLS/BFCP *
	a=setup:actpass		a=setup:actpass
	a=dtls-id:abc3dl		a=dtls-id:abc3dl
	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
	a=floorctrl:c-only s-only		a=floorctrl:c-only s-only
	a=confid:4321		a=confid:4321
	a=userid:1234		a=userid:1234
	a=floorid:1 mstrm:10		a=floorid:1 mstrm:10
	a=floorid:2 mstrm:11		a=floorid:2 mstrm:11
	a=bfcpver:1 2		a=bfcpver:1 2
	m=audio 50002 RTP/AVP 0		m=audio 50002 RTP/AVP 0
	a=label:10		a=label:10
	m=video 50004 RTP/AVP 31		m=video 50004 RTP/AVP 31
	a=label:11		a=label:11</sourcecode>
	</artwork>		<t indent="0" pn="section-11-9">The following is the answer returned by th
	</figure>		e server.</t>
	<t>The following is the answer returned by the server.</t>		<sourcecode name="" type="sdp" markers="false" pn="section-11-10">
	<figure>
	<artwork>
	m=application 55000 UDP/TLS/BFCP *		m=application 55000 UDP/TLS/BFCP *
	a=setup:active		a=setup:active
	a=dtls-id:abc3dl		a=dtls-id:abc3dl
	a=fingerprint:sha-256 \		a=fingerprint:sha-256 \
	6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \		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		DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
	a=floorctrl:s-only		a=floorctrl:s-only
	a=confid:4321		a=confid:4321
	a=userid:1234		a=userid:1234
	a=floorid:1 mstrm:10		a=floorid:1 mstrm:10
	a=floorid:2 mstrm:11		a=floorid:2 mstrm:11
	a=bfcpver:2		a=bfcpver:2
	m=audio 55002 RTP/AVP 0		m=audio 55002 RTP/AVP 0
	m=video 55004 RTP/AVP 31		m=video 55004 RTP/AVP 31</sourcecode>
	</artwork>		</section>
	</figure>		<section anchor="sec_security" numbered="true" toc="include" removeInRFC="fa
	</section>		lse" pn="section-12">
			<name slugifiedName="name-security-considerations">Security Considerations
	<section title="Security Considerations" anchor="sec:security">		</name>
	<t>The BFCP <xref target="I-D.ietf-bfcpbis-rfc4582bis"/>, SDP <xref target="		<t indent="0" pn="section-12-1">The BFCP specification <xref target="RFC88
	RFC4566"/>, and offer/answer <xref target="RFC3264"/>		55" format="default" sectionFormat="of" derivedContent="RFC8855"/>, SDP
	specifications discuss security issues related to BFCP, SDP, and offer/answe		specification <xref target="RFC8866" format="default" sectionFormat="of" d
	r, respectively. In addition, <xref target="RFC4145"/>		erivedContent="RFC8866"/>, and
	and <xref target="RFC8122"/> discuss security issues related to the establis		offer/answer specification <xref target="RFC3264" format="default" section
	hment of TCP and TLS connections using an offer/answer		Format="of" derivedContent="RFC3264"/> discuss security issues related to BFCP,
			SDP, and offer/answer, respectively. In addition, <xref target="RFC4145" format=
			"default" sectionFormat="of" derivedContent="RFC4145"/>
			and <xref target="RFC8122" format="default" sectionFormat="of" derivedConten
			t="RFC8122"/> discuss security issues related to the establishment of TCP and TL
			S connections using an offer/answer
	model. Furthermore, when using DTLS over UDP, the generic offer/answer consi derations defined in		model. Furthermore, when using DTLS over UDP, the generic offer/answer consi derations defined in
	<xref target="I-D.ietf-mmusic-dtls-sdp"/> MUST be followed.</t>		<xref target="RFC8842" format="default" sectionFormat="of" derivedContent="R
	<t>The usage of certain proto values in the SDP offer/answer negotiation wil		FC8842"/> <bcp14>MUST</bcp14> be followed.</t>
	l result in a BFCP stream that is not protected by		<t indent="0" pn="section-12-2">The usage of certain proto values in the S
			DP offer/answer negotiation will result in a BFCP stream that is not protected b
			y
	TLS or DTLS. Operators will need to provide integrity protection and confide ntiality protection of the BFCP stream using other means.</t>		TLS or DTLS. Operators will need to provide integrity protection and confide ntiality protection of the BFCP stream using other means.</t>
	<t>The generic security considerations associated with SDP attributes are de		<t indent="0" pn="section-12-3">The generic security considerations associ
	fined in <xref target="RFC3264"/>. While the attributes		ated with SDP attributes are defined in <xref target="RFC3264" format="default"
	defined in this specification do not reveal information about the content of		sectionFormat="of" derivedContent="RFC3264"/>. While the attributes
	individual BFCP controlled media streams, they do reveal		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.</t>		which media streams will be BFCP controlled.</t>
	</section>
	<section title="IANA Considerations" anchor="sec:iana">
	<t><list style="empty">
	<t>[Editorial note: The changes in <xref target="sec:proto-reg"/> instruct
	the IANA to register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/B
	FCP for the SDP 'proto' field. The new section <xref target="sec:bfcp-version-at
	tr"/> registers a new SDP "bfcpver" attribute. The rest is unchanged from <xref
	target="RFC4582"/>.]</t>
	</list></t>
	<section title="Registration of SDP 'proto' Values" anchor="sec:proto-reg">
	<t>The IANA is requested to register the following values for the SDP 'pro
	to' field under the Session Description Protocol (SDP) Parameters registry:</t>
	<texttable title="Values for the SDP 'proto' field" anchor="tab:proto-iana
	">
	<ttcol>Value</ttcol>
	<ttcol align="center">Reference</ttcol>
	<c>TCP/BFCP</c>
	<c>[RFC XXXX]</c>
	<c>TCP/DTLS/BFCP</c>
	<c>[RFC XXXX]</c>
	<c>TCP/TLS/BFCP</c>
	<c>[RFC XXXX]</c>
	<c>UDP/BFCP</c>
	<c>[RFC XXXX]</c>
	<c>UDP/TLS/BFCP</c>
	<c>[RFC XXXX]</c>
	</texttable>
	</section>		</section>
			<section anchor="sec_iana" numbered="true" toc="include" removeInRFC="false"
	<section title="Registration of the SDP 'floorctrl' Attribute">		pn="section-13">
	<t>		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	This document defines the SDP attribute,'floorctrl'.		<t indent="0" pn="section-13-1">This document registers three new values i
	The details of the attribute are defined in <xref target="sec:floorctrl-		n the "proto"
	attr"/>.		subregistry within the "Session Description Protocol (SDP)
	</t>		Parameters" registry: 'TCP/DTLS/BFCP', 'UDP/BFCP', and 'UDP/TLS/BFCP' (see <xref
	</section>		target="sec_proto-reg" format="default" sectionFormat="of" derivedContent="Sect
			ion 13.1"/>).</t>
	<section title="Registration of the SDP 'confid' Attribute">		<t indent="0" pn="section-13-2">This document also registers a new SDP att
	<t>		ribute in the
	This document defines the SDP attribute,'confid'.		'attribute-name (formerly "att-field")'
	The details of the attribute are defined in <xref target="sec:confid-att		subregistry within the "Session Description Protocol (SDP) Parameters"
	r"/>.		registry: 'bfcpver' (see <xref target="sec_bfcp-version-attr" format="default" s
	</t>		ectionFormat="of" derivedContent="Section 5.5"/>).</t>
			<t indent="0" pn="section-13-3">The remaining values are unchanged from <x
			ref target="RFC4582" format="default" sectionFormat="of" derivedContent="RFC4582
			"/>, except
			that the references have been updated to refer to this document.</t>
			<section anchor="sec_proto-reg" numbered="true" toc="include" removeInRFC=
			"false" pn="section-13.1">
			<name slugifiedName="name-registration-of-sdp-proto-v">Registration of S
			DP 'proto' Values</name>
			<t indent="0" pn="section-13.1-1">The IANA has registered three new valu
			es in the SDP
			'proto' field under the "Session Description Protocol (SDP)
			Parameters" registry.</t>
			<table anchor="tab_proto-iana" align="center" pn="table-3">
			<name slugifiedName="name-values-for-the-sdp-proto-fi">Values for the
			SDP 'proto' Field</name>
			<thead>
			<tr>
			<th align="left" colspan="1" rowspan="1">Value</th>
			<th align="center" colspan="1" rowspan="1">Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">TCP/BFCP</td>
			<td align="center" colspan="1" rowspan="1">RFC 8856</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">TCP/DTLS/BFCP</td>
			<td align="center" colspan="1" rowspan="1">RFC 8856</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">TCP/TLS/BFCP</td>
			<td align="center" colspan="1" rowspan="1">RFC 8856</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">UDP/BFCP</td>
			<td align="center" colspan="1" rowspan="1">RFC 8856</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">UDP/TLS/BFCP</td>
			<td align="center" colspan="1" rowspan="1">RFC 8856</td>
			</tr>
			</tbody>
			</table>
			</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-13.
			2">
			<name slugifiedName="name-registration-of-the-sdp-flo">Registration of t
			he SDP 'floorctrl' Attribute</name>
			<t indent="0" pn="section-13.2-1">
			This document defines the SDP 'floorctrl' attribute.
			Details regarding this attribute are provided in <xref target="sec_floor
			ctrl-attr" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.
			</t>
			</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-13.
			3">
			<name slugifiedName="name-registration-of-the-sdp-con">Registration of t
			he SDP 'confid' Attribute</name>
			<t indent="0" pn="section-13.3-1">
			This document defines the SDP 'confid' attribute.
			Details regarding this attribute are provided in <xref target="sec_confi
			d-attr" format="default" sectionFormat="of" derivedContent="Section 5.2"/>.
			</t>
			</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-13.
			4">
			<name slugifiedName="name-registration-of-the-sdp-use">Registration of t
			he SDP 'userid' Attribute</name>
			<t indent="0" pn="section-13.4-1">
			This document defines the SDP 'userid' attribute.
			Details regarding this attribute are provided in <xref target="sec_useri
			d-attr" format="default" sectionFormat="of" derivedContent="Section 5.3"/>.
			</t>
			</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-13.
			5">
			<name slugifiedName="name-registration-of-the-sdp-floo">Registration of
			the SDP 'floorid' Attribute</name>
			<t indent="0" pn="section-13.5-1">
			This document defines the SDP 'floorid' attribute.
			Details regarding this attribute are provided in <xref target="sec_floor
			id-attr" format="default" sectionFormat="of" derivedContent="Section 5.4"/>.
			</t>
			</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-13.
			6">
			<name slugifiedName="name-registration-of-the-sdp-bfc">Registration of t
			he SDP 'bfcpver' Attribute</name>
			<t indent="0" pn="section-13.6-1">
			This document defines the SDP 'bfcpver' attribute.
			Details regarding this attribute are provided in <xref target="sec_bfcp-
			version-attr" format="default" sectionFormat="of" derivedContent="Section 5.5"/>
			.
			</t>
			</section>
	</section>		</section>
			<section anchor="sec_changes" numbered="true" toc="include" removeInRFC="fal
	<section title="Registration of the SDP 'userid' Attribute">		se" pn="section-14">
	<t>		<name slugifiedName="name-changes-from-rfc-4583">Changes from RFC 4583</na
	This document defines the SDP attribute,'userid'.		me>
	The details of the attribute are defined in <xref target="sec:userid-att		<t indent="0" pn="section-14-1">The technical changes and other fixes from
	r"/>.		<xref target="RFC4583" format="default" sectionFormat="of" derivedContent="RFC4
	</t>		583"/> are listed below.</t>
			<t indent="0" pn="section-14-2">The main purpose of this work was to add s
			ignaling support necessary
			to support BFCP over an unreliable transport, as described in <xref target
			="RFC8855" format="default" sectionFormat="of" derivedContent="RFC8855"/>, resul
			ting in the following changes:</t>
			<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-14-
			3">
			<li pn="section-14-3.1">
			<t indent="0" pn="section-14-3.1.1">Fields in the "m=" Line (<xref tar
			get="sec_m-line" format="default" sectionFormat="of" derivedContent="Section 4"/
			>):</t>
			<t indent="0" pn="section-14-3.1.2">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.</t>
			</li>
			<li pn="section-14-3.2">
			<t indent="0" pn="section-14-3.2.1">Security Considerations (<xref tar
			get="sec_security" format="default" sectionFormat="of" derivedContent="Section 1
			2"/>):</t>
			<t indent="0" pn="section-14-3.2.2">For the DTLS-over-UDP case, we dir
			ect the reader to existing considerations
			and requirements for the offer⁠/answer exchange as provided in <xref tar
			get="RFC8842" format="default" sectionFormat="of" derivedContent="RFC8842"/>.</t
			>
			</li>
			<li pn="section-14-3.3">
			<t indent="0" pn="section-14-3.3.1">Registration of SDP 'proto' Values
			(<xref target="sec_proto-reg" format="default" sectionFormat="of" derivedConten
			t="Section 13.1"/>):</t>
			<t indent="0" pn="section-14-3.3.2">This document registers the three
			new values 'TCP/DTLS/BFCP', 'UDP/BFCP', and
			'UDP/TLS/BFCP' in the "Session Description Protocol (SDP) Parameters" re
			gistry.</t>
			</li>
			<li pn="section-14-3.4">
			<t indent="0" pn="section-14-3.4.1">SDP 'bfcpver' Attribute (<xref tar
			get="sec_bfcp-version-attr" format="default" sectionFormat="of" derivedContent="
			Section 5.5"/>):</t>
			<t indent="0" pn="section-14-3.4.2">A new 'bfcpver' SDP media-level at
			tribute has been added, in order to
			signal the supported version number.</t>
			</li>
			</ul>
			<t indent="0" pn="section-14-4">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-controlle
			d streams associated with the BFCP stream.</t>
			<t indent="0" pn="section-14-5">Clarifications and bug fixes:</t>
			<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-14-
			6">
			<li pn="section-14-6.1">
			<t indent="0" pn="section-14-6.1.1">Erratum ID 712 (Sections <xref tar
			get="RFC4583" section="3" sectionFormat="bare" format="default" derivedLink="htt
			ps://rfc-editor.org/rfc/rfc4583#section-3" derivedContent="RFC4583"/> and <xref
			target="RFC4583" section="10" sectionFormat="bare" format="default" derivedLink=
			"https://rfc-editor.org/rfc/rfc4583#section-10" derivedContent="RFC4583"/> of <x
			ref target="RFC4583" format="default" sectionFormat="of" derivedContent="RFC4583
			"/>; see <xref target="Err712" format="default" sectionFormat="of" derivedConten
			t="Err712"/> for details):</t>
			<t indent="0" pn="section-14-6.1.2">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.</t>
			</li>
			<li pn="section-14-6.2">
			<t indent="0" pn="section-14-6.2.1">Spelling corrected in the first SD
			P example in <xref target="RFC4583" sectionFormat="of" section="9" format="defau
			lt" derivedLink="https://rfc-editor.org/rfc/rfc4583#section-9" derivedContent="R
			FC4583"/>:</t>
			<t indent="0" pn="section-14-6.2.2">Do not use 'm-stream' as listed in
			the first SDP example in <xref target="RFC4583" format="default" sectionFormat=
			"of" derivedContent="RFC4583"/>; instead, use the correct 'mstrm'
			as specified in <xref target="sec_example" format="default" sectionForma
			t="of" derivedContent="Section 11"/> of this
			document. However, we recommend continuing to interpret 'm-stream', if r
			eceived,
			because it is still present in some implementations.</t>
			</li>
			<li pn="section-14-6.3">
			<t indent="0" pn="section-14-6.3.1">Assorted clarifications (throughou
			t the document):</t>
			<t indent="0" pn="section-14-6.3.2">Language clarifications were made
			as a result of reviews. Also,
			normative language was "tightened" where appropriate, i.e., changed
			from "<bcp14>SHOULD</bcp14>" strength to "<bcp14>MUST</bcp14>" in a
			number of places.</t>
			</li>
			</ul>
	</section>		</section>
			</middle>
	<section title="Registration of the SDP 'floorid' Attribute">		<back>
	<t>		<references pn="section-15">
	This document defines the SDP attribute,'floorid'.		<name slugifiedName="name-references">References</name>
	The details of the attribute are defined in <xref target="sec:floorid-at		<references pn="section-15.1">
	tr"/>.		<name slugifiedName="name-normative-references">Normative References</na
	</t>		me>
			<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
			119" quoteTitle="true" derivedAnchor="RFC2119">
			<front>
			<title>Key words for use in RFCs to Indicate Requirement Levels</tit
			le>
			<author initials="S." surname="Bradner" fullname="S. Bradner">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="1997" month="March"/>
			<abstract>
			<t indent="0">In many standards track documents several words are
			used to signify the requirements in the specification. These words are often ca
			pitalized. This document defines these words as they should be interpreted in IE
			TF documents. This document specifies an Internet Best Current Practices for th
			e Internet Community, and requests discussion and suggestions for improvements.<
			/t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="2119"/>
			<seriesInfo name="DOI" value="10.17487/RFC2119"/>
			</reference>
			<reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3
			261" quoteTitle="true" derivedAnchor="RFC3261">
			<front>
			<title>SIP: Session Initiation Protocol</title>
			<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
			">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="G." surname="Camarillo" fullname="G. Camarillo">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="A." surname="Johnston" fullname="A. Johnston">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Peterson" fullname="J. Peterson">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Sparks" fullname="R. Sparks">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M." surname="Handley" fullname="M. Handley">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="E." surname="Schooler" fullname="E. Schooler">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2002" month="June"/>
			<abstract>
			<t indent="0">This document describes Session Initiation Protocol
			(SIP), an application-layer control (signaling) protocol for creating, modifying
			, and terminating sessions with one or more participants. These sessions includ
			e Internet telephone calls, multimedia distribution, and multimedia conferences.
			[STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3261"/>
			<seriesInfo name="DOI" value="10.17487/RFC3261"/>
			</reference>
			<reference anchor="RFC3264" target="https://www.rfc-editor.org/info/rfc3
			264" quoteTitle="true" derivedAnchor="RFC3264">
			<front>
			<title>An Offer/Answer Model with Session Description Protocol (SDP)
			</title>
			<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
			">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2002" month="June"/>
			<abstract>
			<t indent="0">This document defines a mechanism by which two entit
			ies can make use of the Session Description Protocol (SDP) to arrive at a common
			view of a multimedia session between them. In the model, one participant offer
			s the other a description of the desired session from their perspective, and the
			other participant answers with the desired session from their perspective. Thi
			s offer/answer model is most useful in unicast sessions where information from b
			oth participants is needed for the complete view of the session. The offer/answ
			er model is used by protocols like the Session Initiation Protocol (SIP). [STAN
			DARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3264"/>
			<seriesInfo name="DOI" value="10.17487/RFC3264"/>
			</reference>
			<reference anchor="RFC4145" target="https://www.rfc-editor.org/info/rfc4
			145" quoteTitle="true" derivedAnchor="RFC4145">
			<front>
			<title>TCP-Based Media Transport in the Session Description Protocol
			(SDP)</title>
			<author initials="D." surname="Yon" fullname="D. Yon">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="G." surname="Camarillo" fullname="G. Camarillo">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2005" month="September"/>
			<abstract>
			<t indent="0">This document describes how to express media transpo
			rt over TCP using the Session Description Protocol (SDP). It defines the SDP 'T
			CP' protocol identifier, the SDP 'setup' attribute, which describes the connecti
			on setup procedure, and the SDP 'connection' attribute, which handles connection
			reestablishment. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4145"/>
			<seriesInfo name="DOI" value="10.17487/RFC4145"/>
			</reference>
			<reference anchor="RFC4571" target="https://www.rfc-editor.org/info/rfc4
			571" quoteTitle="true" derivedAnchor="RFC4571">
			<front>
			<title>Framing Real-time Transport Protocol (RTP) and RTP Control Pr
			otocol (RTCP) Packets over Connection-Oriented Transport</title>
			<author initials="J." surname="Lazzaro" fullname="J. Lazzaro">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="July"/>
			<abstract>
			<t indent="0">This memo defines a method for framing Real-time Tra
			nsport Protocol (RTP) and RTP Control Protocol (RTCP) packets onto connection-or
			iented transport (such as TCP). The memo also defines how session descriptions
			may specify RTP streams that use the framing method. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4571"/>
			<seriesInfo name="DOI" value="10.17487/RFC4571"/>
			</reference>
			<reference anchor="RFC4574" target="https://www.rfc-editor.org/info/rfc4
			574" quoteTitle="true" derivedAnchor="RFC4574">
			<front>
			<title>The Session Description Protocol (SDP) Label Attribute</title
			>
			<author initials="O." surname="Levin" fullname="O. Levin">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="G." surname="Camarillo" fullname="G. Camarillo">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="August"/>
			<abstract>
			<t indent="0">This document defines a new Session Description Prot
			ocol (SDP) media-level attribute: "label". The "label" attribute carries a poin
			ter to a media stream in the context of an arbitrary network application that us
			es SDP. The sender of the SDP document can attach the "label" attribute to a pa
			rticular media stream or streams. The application can then use the provided poi
			nter to refer to each particular media stream in its context. [STANDARDS-TRACK]
			</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4574"/>
			<seriesInfo name="DOI" value="10.17487/RFC4574"/>
			</reference>
			<reference anchor="RFC4582" target="https://www.rfc-editor.org/info/rfc4
			582" quoteTitle="true" derivedAnchor="RFC4582">
			<front>
			<title>The Binary Floor Control Protocol (BFCP)</title>
			<author initials="G." surname="Camarillo" fullname="G. Camarillo">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Ott" fullname="J. Ott">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="K." surname="Drage" fullname="K. Drage">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="November"/>
			<abstract>
			<t indent="0">Floor control is a means to manage joint or exclusiv
			e access to shared resources in a (multiparty) conferencing environment. Thereby
			, floor control complements other functions -- such as conference and media sess
			ion setup, conference policy manipulation, and media control -- that are realize
			d by other protocols.</t>
			<t indent="0">This document specifies the Binary Floor Control Pro
			tocol (BFCP). BFCP is used between floor participants and floor control servers,
			and between floor chairs (i.e., moderators) and floor control servers. [STANDA
			RDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4582"/>
			<seriesInfo name="DOI" value="10.17487/RFC4582"/>
			</reference>
			<reference anchor="RFC4583" target="https://www.rfc-editor.org/info/rfc4
			583" quoteTitle="true" derivedAnchor="RFC4583">
			<front>
			<title>Session Description Protocol (SDP) Format for Binary Floor Co
			ntrol Protocol (BFCP) Streams</title>
			<author initials="G." surname="Camarillo" fullname="G. Camarillo">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="November"/>
			<abstract>
			<t indent="0">This document specifies how to describe Binary Floor
			Control Protocol (BFCP) streams in Session Description Protocol (SDP) descripti
			ons. User agents using the offer/answer model to establish BFCP streams use this
			format in their offers and answers. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4583"/>
			<seriesInfo name="DOI" value="10.17487/RFC4583"/>
			</reference>
			<reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5
			234" quoteTitle="true" derivedAnchor="RFC5234">
			<front>
			<title>Augmented BNF for Syntax Specifications: ABNF</title>
			<author initials="D." surname="Crocker" fullname="D. Crocker" role="
			editor">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="P." surname="Overell" fullname="P. Overell">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2008" month="January"/>
			<abstract>
			<t indent="0">Internet technical specifications often need to defi
			ne a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF
			), called Augmented BNF (ABNF), has been popular among many Internet specificati
			ons. The current specification documents ABNF. It balances compactness and simp
			licity with reasonable representational power. The differences between standard
			BNF and ABNF involve naming rules, repetition, alternatives, order-independence
			, and value ranges. This specification also supplies additional rule definition
			s and encoding for a core lexical analyzer of the type common to several Interne
			t specifications. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="STD" value="68"/>
			<seriesInfo name="RFC" value="5234"/>
			<seriesInfo name="DOI" value="10.17487/RFC5234"/>
			</reference>
			<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6
			347" quoteTitle="true" derivedAnchor="RFC6347">
			<front>
			<title>Datagram Transport Layer Security Version 1.2</title>
			<author initials="E." surname="Rescorla" fullname="E. Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="N." surname="Modadugu" fullname="N. Modadugu">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2012" month="January"/>
			<abstract>
			<t indent="0">This document specifies version 1.2 of the Datagram
			Transport Layer Security (DTLS) protocol. The DTLS protocol provides communicat
			ions privacy for datagram protocols. The protocol allows client/server applicat
			ions to communicate in a way that is designed to prevent eavesdropping, tamperin
			g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
			ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
			cs of the underlying transport are preserved by the DTLS protocol. This documen
			t updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6347"/>
			<seriesInfo name="DOI" value="10.17487/RFC6347"/>
			</reference>
			<reference anchor="RFC6544" target="https://www.rfc-editor.org/info/rfc6
			544" quoteTitle="true" derivedAnchor="RFC6544">
			<front>
			<title>TCP Candidates with Interactive Connectivity Establishment (I
			CE)</title>
			<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="A." surname="Keranen" fullname="A. Keranen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="B. B." surname="Lowekamp" fullname="B. B. Lowekamp
			">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="A. B." surname="Roach" fullname="A. B. Roach">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2012" month="March"/>
			<abstract>
			<t indent="0">Interactive Connectivity Establishment (ICE) defines
			a mechanism for NAT traversal for multimedia communication protocols based on t
			he offer/answer model of session negotiation. ICE works by providing a set of c
			andidate transport addresses for each media stream, which are then validated wit
			h peer-to-peer connectivity checks based on Session Traversal Utilities for NAT
			(STUN). ICE provides a general framework for describing candidates but only def
			ines UDP-based media streams. This specification extends ICE to TCP-based media,
			including the ability to offer a mix of TCP and UDP-based candidates for a sing
			le stream. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6544"/>
			<seriesInfo name="DOI" value="10.17487/RFC6544"/>
			</reference>
			<reference anchor="RFC8122" target="https://www.rfc-editor.org/info/rfc8
			122" quoteTitle="true" derivedAnchor="RFC8122">
			<front>
			<title>Connection-Oriented Media Transport over the Transport Layer
			Security (TLS) Protocol in the Session Description Protocol (SDP)</title>
			<author initials="J." surname="Lennox" fullname="J. Lennox">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C." surname="Holmberg" fullname="C. Holmberg">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="March"/>
			<abstract>
			<t indent="0">This document specifies how to establish secure conn
			ection-oriented media transport sessions over the Transport Layer Security (TLS)
			protocol using the Session Description Protocol (SDP). It defines the SDP prot
			ocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP
			'fingerprint' attribute that identifies the certificate that will be presented
			for the TLS session. This mechanism allows media transport over TLS connections
			to be established securely, so long as the integrity of session descriptions is
			assured.</t>
			<t indent="0">This document obsoletes RFC 4572 by clarifying the u
			sage of multiple fingerprints.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8122"/>
			<seriesInfo name="DOI" value="10.17487/RFC8122"/>
			</reference>
			<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
			174" quoteTitle="true" derivedAnchor="RFC8174">
			<front>
			<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
			tle>
			<author initials="B." surname="Leiba" fullname="B. Leiba">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="May"/>
			<abstract>
			<t indent="0">RFC 2119 specifies common key words that may be used
			in protocol specifications. This document aims to reduce the ambiguity by cla
			rifying that only UPPERCASE usage of the key words have the defined special mea
			nings.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="8174"/>
			<seriesInfo name="DOI" value="10.17487/RFC8174"/>
			</reference>
			<reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8
			445" quoteTitle="true" derivedAnchor="RFC8445">
			<front>
			<title>Interactive Connectivity Establishment (ICE): A Protocol for
			Network Address Translator (NAT) Traversal</title>
			<author initials="A." surname="Keranen" fullname="A. Keranen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C." surname="Holmberg" fullname="C. Holmberg">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2018" month="July"/>
			<abstract>
			<t indent="0">This document describes a protocol for Network Addre
			ss Translator (NAT) traversal for UDP-based communication. This protocol is cal
			led Interactive Connectivity Establishment (ICE). ICE makes use of the Session
			Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using R
			elay NAT (TURN).</t>
			<t indent="0">This document obsoletes RFC 5245.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8445"/>
			<seriesInfo name="DOI" value="10.17487/RFC8445"/>
			</reference>
			<reference anchor="RFC8839" target="https://www.rfc-editor.org/info/rfc8
			839" quoteTitle="true" derivedAnchor="RFC8839">
			<front>
			<title>Session Description Protocol (SDP) Offer/Answer Procedures fo
			r Interactive Connectivity Establishment (ICE)</title>
			<author initials="M" surname="Petit-Huguenin" fullname="Marc Petit-H
			uguenin">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar
			">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C" surname="Holmberg" fullname="Christer Holmberg"
			>
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="A" surname="Keränen" fullname="Ari Keränen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R" surname="Shpount" fullname="Roman Shpount">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8839"/>
			<seriesInfo name="DOI" value="10.17487/RFC8839"/>
			</reference>
			<reference anchor="RFC8842" target="https://www.rfc-editor.org/info/rfc8
			842" quoteTitle="true" derivedAnchor="RFC8842">
			<front>
			<title>Session Description Protocol (SDP) Offer/Answer Consideration
			s for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS
			)</title>
			<author initials="C." surname="Holmberg" fullname="Christer Holmberg
			">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Shpount" fullname="Roman Shpount">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8842"/>
			<seriesInfo name="DOI" value="10.17487/RFC8842"/>
			</reference>
			<reference anchor="RFC8855" target="https://www.rfc-editor.org/info/rfc8
			855" quoteTitle="true" derivedAnchor="RFC8855">
			<front>
			<title>The Binary Floor Control Protocol (BFCP)</title>
			<author initials="G." surname="Camarillo" fullname="">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="K." surname="Drage" fullname="Keith Drage">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="T." surname="Kristensen" fullname="Tom Kristensen"
			>
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Ott" fullname="Jörg Ott">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C." surname="Eckel" fullname="Charles Eckel">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8855"/>
			<seriesInfo name="DOI" value="10.17487/RFC8855"/>
			</reference>
			<reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8
			859" quoteTitle="true" derivedAnchor="RFC8859">
			<front>
			<title>A Framework for Session Description Protocol (SDP) Attributes
			When Multiplexing</title>
			<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar
			">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8859"/>
			<seriesInfo name="DOI" value="10.17487/RFC8859"/>
			</reference>
			<reference anchor="RFC8866" target="https://www.rfc-editor.org/info/rfc8
			866" quoteTitle="true" derivedAnchor="RFC8866">
			<front>
			<title>SDP: Session Description Protocol</title>
			<author initials="A" surname="Begen" fullname="Ali Begen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="P" surname="Kyzivat" fullname="Paul Kyzivat">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C" surname="Perkins" fullname="Colin Perkins">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M" surname="Handley" fullname="Mark Handley">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8866"/>
			<seriesInfo name="DOI" value="10.17487/RFC8866"/>
			</reference>
			</references>
			<references pn="section-15.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<reference anchor="Err712" target="https://www.rfc-editor.org/errata/eid
			712" quoteTitle="false" derivedAnchor="Err712">
			<front>
			<title>Erratum ID 712</title>
			<author>
			<organization showOnFrontPage="true">RFC Errata</organization>
			</author>
			</front>
			<refcontent>RFC 4583</refcontent>
			</reference>
			<reference anchor="RFC5576" target="https://www.rfc-editor.org/info/rfc5
			576" quoteTitle="true" derivedAnchor="RFC5576">
			<front>
			<title>Source-Specific Media Attributes in the Session Description P
			rotocol (SDP)</title>
			<author initials="J." surname="Lennox" fullname="J. Lennox">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Ott" fullname="J. Ott">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="T." surname="Schierl" fullname="T. Schierl">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2009" month="June"/>
			<abstract>
			<t indent="0">The Session Description Protocol (SDP) provides mech
			anisms to describe attributes of multimedia sessions and of individual media str
			eams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia ses
			sion, but does not provide any mechanism to describe individual media sources wi
			thin a media stream. This document defines a mechanism to describe RTP media so
			urces, which are identified by their synchronization source (SSRC) identifiers,
			in SDP, to associate attributes with these sources, and to express relationships
			among sources. It also defines several source-level attributes that can be use
			d to describe properties of media sources. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="5576"/>
			<seriesInfo name="DOI" value="10.17487/RFC5576"/>
			</reference>
			<reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8
			843" quoteTitle="true" derivedAnchor="RFC8843">
			<front>
			<title>Negotiating Media Multiplexing Using the Session Description
			Protocol (SDP)</title>
			<author initials="C" surname="Holmberg" fullname="Christer Holmberg"
			>
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="H" surname="Alvestrand" fullname="Harald Alvestran
			d">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C" surname="Jennings" fullname="Cullen Jennings">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8843"/>
			<seriesInfo name="DOI" value="10.17487/RFC8843"/>
			</reference>
			</references>
			</references>
			<section anchor="sec_acks" numbered="false" toc="include" removeInRFC="false
			" pn="section-appendix.a">
			<name slugifiedName="name-acknowledgements">Acknowledgements</name>
			<t indent="0" pn="section-appendix.a-1"><contact fullname="Jörg Ott"/>, <c
			ontact fullname="Keith Drage"/>,
			<contact fullname="Alan Johnston"/>, <contact fullname="Eric Rescorl
			a"/>, <contact fullname="Roni Even"/>, and <contact fullname="Oscar Novo"/> prov
			ided useful ideas for the original <xref target="RFC4583" format="default" secti
			onFormat="of" derivedContent="RFC4583"/>. The authors also acknowledge
			contributions to the revision of BFCP for use over an unreliable
			transport from <contact fullname="Geir Arne Sandbakken"/>, <contact fullna
			me="Charles Eckel"/>, <contact fullname="Alan Ford"/>, <contact fullname="Eoin M
			cLeod"/>, and <contact fullname="Mark Thompson"/>. Useful
			and important final reviews were done by <contact fullname="Ali C. B
			egen"/>, <contact fullname="Mary Barnes"/>, and <contact fullname="Charles Eckel
			"/>. In the final stages, <contact fullname="Roman Shpount"/> made a considerabl
			e effort in adding proper ICE support and considerations.</t>
	</section>		</section>
			<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
	<section title="Registration of the SDP 'bfcpver' Attribute">		="include" pn="section-appendix.b">
	<t>		<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
	This document defines the SDP attribute,'bfcpver'.		<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
	The details of the attribute are defined in <xref target="sec:bfcp-versi		<organization showOnFrontPage="true">Ericsson</organization>
	on-attr"/>.		<address>
	</t>		<postal>
			<street>Hirsalantie 11</street>
			<code>02420</code>
			<city>Jorvas</city>
			<country>Finland</country>
			</postal>
			<email>Gonzalo.Camarillo@ericsson.com</email>
			</address>
			</author>
			<author fullname="Tom Kristensen" initials="T." surname="Kristensen">
			<organization abbrev="Jotron" showOnFrontPage="true">Jotron AS</organiza
			tion>
			<address>
			<postal>
			<street>Ringdalskogen 8</street>
			<code>3270</code>
			<city>Larvik</city>
			<country>Norway</country>
			</postal>
			<email>tom.kristensen@jotron.com, tomkri@ifi.uio.no</email>
			</address>
			</author>
			<author initials="C." surname="Holmberg" fullname="Christer Holmberg">
			<organization showOnFrontPage="true">Ericsson</organization>
			<address>
			<postal>
			<street>Hirsalantie 11</street>
			<code>02420</code>
			<city>Jorvas</city>
			<country>Finland</country>
			</postal>
			<email>christer.holmberg@ericsson.com</email>
			</address>
			</author>
	</section>		</section>
	</section>		</back>
	<section title="Changes from RFC 4583" anchor="sec:changes">
	<t>Following is the list of technical changes and other fixes from <xref tar
	get="RFC4583"/>.</t>
	<t>Main purpose of this work was to add signaling support necessary to suppo
	rt BFCP over unreliable transport, as described in <xref target="I-D.ietf-bfcpbi
	s-rfc4582bis"/>, resulting in the following changes:</t>
	<t><list style="numbers">
	<t>Fields in the 'm' line (<xref target="sec:m-line"/>):<vspace/>
	The section is re-written to remove reference to the exclusivity of TC
	P as a transport for BFCP streams. The proto field values TCP/DTLS/BFCP, UDP/BFC
	P and UDP/TLS/BFCP added.</t>
	<t>Security Considerations (<xref target="sec:security"/>):<vspace/>
	For the DTLS over UDP case, mention existing considerations and requir
	ements for the offer/answer exchange in <xref target="I-D.ietf-mmusic-dtls-sdp"/
	>.</t>
	<t>Registration of SDP 'proto' Values (<xref target="sec:proto-reg"/>):<
	vspace/>
	Register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP
	in the SDP parameters registry.</t>
	<t>BFCP Version Negotiation (<xref target="sec:bfcp-version-attr"/>):<vs
	pace/>
	A new 'bfcpver' SDP media-level attribute is added in order to signal
	supported version number.</t>
	</list></t>
	<t>In addition to the changes associated with support of BFCP over unreliabl
	e transport, the possibility for an endpoint to act as both 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-controlle
	d streams associated with the BFCP stream.</t>
	<t>Clarification and bug fixes:</t>
	<t><list style="numbers">
	<t>Errata ID: 712 (<xref target="sec:server-determination"/> and <xref t
	arget="sec:oa-offer-answer-proc"/>):<vspace/>
	Language clarification. Don't use terms like an SDP attribute is "used
	in an 'm' line", instead make clear that the attribute is a media-level attribu
	te.</t>
	<t>Fix typo in example (<xref target="sec:example"/>):<vspace/>
	Do not use 'm-stream' in the SDP example, use the correct 'mstrm' as s
	pecified in <xref target="sec:example"/>. Recommend interpreting 'm-stream' if i
	t is received, since it is present in some implementations.</t>
	<t>Assorted clarifications (Across the document):<vspace/>
	Language clarifications as a result of reviews. Also, the normative la
	nguage where tightened where appropriate, i.e. changed from SHOULD strength to M
	UST in a number of places.</t>
	</list></t>
	</section>
	<section title="Acknowledgements" anchor="sec:acks">
	<t>Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and Osca
	r Novo provided useful ideas for the original <xref target="RFC4583"/>. The auth
	ors also acknowledge contributions to the revision of BFCP for use over an unrel
	iable 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 consi
	derable effort in adding proper ICE support and considerations.</t>
	</section>
	</middle>
	<back>
	<references title="Normative References">
	<?rfc include="reference.RFC.2119" ?>
	<?rfc include="reference.RFC.5234" ?>
	<?rfc include="reference.RFC.3261" ?>
	<?rfc include="reference.RFC.3264" ?>
	<?rfc include="reference.RFC.4145" ?>
	<?rfc include="reference.RFC.4574" ?>
	<?rfc include="reference.RFC.8122" ?>
	<?rfc include="reference.RFC.4566" ?>
	<?rfc include="reference.RFC.6347" ?>
	<?rfc include="reference.RFC.4571" ?>
	<?rfc include="reference.RFC.6544" ?>
	<?rfc include="reference.RFC.4582" ?>
	<?rfc include="reference.RFC.4583" ?>
	<?rfc include="reference.RFC.8174" ?>
	<?rfc include="reference.RFC.8445" ?>
	<?rfc include="reference.I-D.draft-ietf-mmusic-ice-sip-sdp-24"?>
	<?rfc include="reference.I-D.draft-ietf-bfcpbis-rfc4582bis-16" ?>
	<?rfc include="reference.I-D.draft-ietf-mmusic-dtls-sdp-32" ?>
	<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-mux-attributes-17" ?>
	</references>
	<references title="Informational References">
	<?rfc include="reference.RFC.5576" ?>
	<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-bundle-negotiation-53" ?>
	</references>
	</back>
	</rfc>		</rfc>
End of changes. 53 change blocks.
	964 lines changed or deleted		2078 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/