rfc8865xml2.original.xml		rfc8865.xml
	<?xml version="1.0" encoding="windows-1252"?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
	<?rfc toc="yes" ?>		nsus="true" docName="draft-ietf-mmusic-t140-usage-data-channel-14" indexInclude=
	<?rfc compact="yes" ?>		"true" ipr="trust200902" number="8865" prepTime="2021-01-18T23:00:08" scripts="C
	<?rfc subcompact="yes" ?>		ommon,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" t
	<?rfc sortrefs="no" ?>		ocInclude="true" updates="8373" xml:lang="en">
	<?rfc strict="yes" ?>		<link href="https://datatracker.ietf.org/doc/draft-ietf-mmusic-t140-usage-data
	<rfc ipr="trust200902" category="std" docName="draft-ietf-mmusic-t140-usage-data		-channel-14" rel="prev"/>
	-channel-14" obsoletes="" updates="8373" submissionType="IETF" xml:lang="en">		<link href="https://dx.doi.org/10.17487/rfc8865" rel="alternate"/>
			<link href="urn:issn:2070-1721" rel="alternate"/>
	<front>		<front>
	<title abbrev="T.140 Data Channel">		<title abbrev="T.140 Data Channel">T.140 Real-Time Text Conversation over We
	T.140 Real-time Text Conversation over WebRTC Data Channels		bRTC Data Channels</title>
	</title>		<seriesInfo name="RFC" value="8865" stream="IETF"/>
	<author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">		<author initials="C." surname="Holmberg" fullname="Christer Holmberg">
	<organization>Ericsson</organization>		<organization showOnFrontPage="true">Ericsson</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Hirsalantie 11</street>		<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>christer.holmberg@ericsson.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="G.H." surname="Hellstrom" fullname="Gunnar Hellstrom">		<author initials="G." surname="Hellström" fullname="Gunnar Hellström">
	<organization>Gunnar Hellstrom Accessible Communication</organization>		<organization showOnFrontPage="true">Gunnar Hellström Accessible Communica
			tion</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Esplanaden 30</street>		<street>Esplanaden 30</street>
	<code>136 70</code>		<code>136 70</code>
	<city>Vendelso</city>		<city>Vendelsö</city>
	<country>Sweden</country>		<country>Sweden</country>
	</postal>		</postal>
	<email>gunnar.hellstrom@ghaccess.se</email>		<email>gunnar.hellstrom@ghaccess.se</email>
	</address>		</address>
	</author>		</author>
			<date month="01" year="2021"/>
	<date year="2020"/>
	<area>Transport</area>
	<workgroup>MMUSIC Working Group</workgroup>
	<keyword>SDP</keyword>		<keyword>SDP</keyword>
	<keyword>ITU-T</keyword>		<keyword>ITU-T</keyword>
	<keyword>T.140</keyword>		<keyword>T.140</keyword>
	<keyword>Data Channel</keyword>		<keyword>Data Channel</keyword>
	<keyword>WebRTC</keyword>		<keyword>WebRTC</keyword>
	<keyword>real-time text</keyword>		<keyword>real-time text</keyword>
	<abstract>		<abstract pn="section-abstract">
	<t>		<t indent="0" pn="section-abstract-1">
	This document specifies how a WebRTC data channel can be used as a		This document specifies how a Web Real-Time Communication (WebRTC) data
	transport mechanism for Real-time text using the ITU-T Protocol for mult		channel can be used as a
	imedia		transport mechanism for real-time text using the ITU-T Protocol for mult
	application text conversation (Recommendation ITU-T T.140), and		imedia
	how the SDP offer/answer mechanism can be used to negotiate		application text conversation (Recommendation ITU-T T.140) and
	such data channel, referred to as T.140 data channel. This document upda		how the Session Description Protocol (SDP) offer/answer mechanism can be
	tes		used to negotiate
			such a data channel, referred to as a T.140 data channel. This document
			updates
	RFC 8373 to specify its use with WebRTC data channels.		RFC 8373 to specify its use with WebRTC data channels.
	</t>		</t>
	</abstract>		</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/rfc8865" 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-webrtc-data-ch
			annel-conside">WebRTC Data Channel Considerations</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-sdp-considerations">SDP Considerat
			ions</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.4.2">
			<li pn="section-toc.1-1.4.2.1">
			<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
			"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-use-of-the-dcmap-attri
			bute">Use of the 'dcmap' Attribute</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.2">
			<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
			"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-use-of-the-dcsa-attrib
			ute">Use of the 'dcsa' Attribute</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
			ction-toc.1-1.4.2.2.2">
			<li pn="section-toc.1-1.4.2.2.2.1">
			<t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derived
			Content="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <
			xref derivedContent="" format="title" sectionFormat="of" target="name-maximum-ch
			aracter-transmiss">Maximum Character Transmission Rate</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.2.2.2">
			<t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derived
			Content="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <
			xref derivedContent="" format="title" sectionFormat="of" target="name-real-time-
			text-conversation">Real-Time Text Conversation Languages</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.2.2.3">
			<t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derived
			Content="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <
			xref derivedContent="" format="title" sectionFormat="of" target="name-real-time-
			text-direction">Real-Time Text Direction</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.4.2.3">
			<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
			"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-examples">Examples</xr
			ef></t>
			</li>
			</ul>
			</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-t140-considerations">T.140 Conside
			rations</xref></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-session-layer-function
			s">Session-Layer Functions</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-data-encoding-and-send
			ing">Data Encoding and Sending</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-data-buffering">Data B
			uffering</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-loss-of-t140blocks">Lo
			ss of T140blocks</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-multi-party-considerat
			ions">Multi-party Considerations</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-gateway-considerations">Gateway Co
			nsiderations</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-update-to-rfc-8373">Update to RFC
			8373</xref></t>
			</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-security-considerations">Security
			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-iana-considerations">IANA Consider
			ations</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.9.2">
			<li pn="section-toc.1-1.9.2.1">
			<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
			"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-subprotocol-identifier
			-t140">Subprotocol Identifier "t140"</xref></t>
			</li>
			<li pn="section-toc.1-1.9.2.2">
			<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
			"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-sdp-fmtp-attribute">SD
			P 'fmtp' Attribute</xref></t>
			</li>
			<li pn="section-toc.1-1.9.2.3">
			<t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent=
			"9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-sdp-language-attribute
			s">SDP Language Attributes</xref></t>
			</li>
			<li pn="section-toc.1-1.9.2.4">
			<t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent=
			"9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-sdp-media-direction-at
			tribu">SDP Media Direction Attributes</xref></t>
			</li>
			</ul>
			</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-references">References</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-normative-reference
			s">Normative References</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-informative-referen
			ces">Informative References</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.11">
			<t indent="0" pn="section-toc.1-1.11.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.12">
			<t indent="0" pn="section-toc.1-1.12.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>		</front>
	<middle>		<middle>
	<section title="Introduction" toc="default">		<section toc="include" numbered="true" removeInRFC="false" pn="section-1">
	<t>		<name slugifiedName="name-introduction">Introduction</name>
			<t indent="0" pn="section-1-1">
	The ITU-T Protocol for multimedia application text conversation (Recomme ndation ITU-T T.140)		The ITU-T Protocol for multimedia application text conversation (Recomme ndation ITU-T T.140)
	<xref target="T140"/> defines a protocol for text conversation, also kno		<xref target="T140" format="default" sectionFormat="of" derivedContent="
	wn as		T140"/> defines a protocol for text conversation, also known as
	real-time text. The transport used for IP networks is the "RTP Payload f		real-time text. The transport used for IP networks is the "RTP Payload
	or Text Conversation"		for Text Conversation" mechanism <xref target="RFC4103" format="default"
	<xref target="RFC4103"/> mechanism, based on the Real-time Transport Pro		sectionFormat="of" derivedContent="RFC4103"/>, based on the Real-time Transport
	tocol (RTP) <xref target="RFC3550"/>.		Protocol (RTP) <xref target="RFC3550" format="default" sectionFormat="of" deriv
			edContent="RFC3550"/>.
	</t>		</t>
	<t>		<t indent="0" pn="section-1-2">
	This document specifies how a WebRTC data channel <xref target="I-D.ietf		This document specifies how a Web Real-Time Communication (WebRTC) data
	-rtcweb-data-channel"/>		channel <xref target="RFC8831" format="default" sectionFormat="of" derivedConten
	can be used as a transport mechanism for T.140, and how the SDP offer/an		t="RFC8831"/>
	swer mechanism		can be used as a transport mechanism for T.140 and how the Session
	for data channels <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> c		Description Protocol (SDP) offer/answer mechanism
	an be used to negotiate such a data channel.		for data channels <xref target="RFC8864" format="default" sectionFormat=
			"of" derivedContent="RFC8864"/> can be used to negotiate such a data channel.
	</t>		</t>
	<t>		<t indent="0" pn="section-1-3">
	In this document, a T.140 data channel refers to a WebRTC data channel f or which		In this document, a T.140 data channel refers to a WebRTC data channel f or which
	the instantiated sub-protocol is "t140", and where the channel is negoti		the instantiated subprotocol is "t140" and where the channel is negotiat
	ated		ed
	using the SDP-based external negotiation method <xref target="I-D.ietf-m		using the SDP offer/answer mechanism <xref target="RFC8864" format="defa
	music-data-channel-sdpneg"/>.		ult" sectionFormat="of" derivedContent="RFC8864"/>.
	</t>
	<t>
	NOTE: The decision to transport real-time text using a WebRTC data chann
	el,
	instead of using RTP based transport <xref target="RFC4103"/>,
	is motivated by use-case "U-C 5: Real-time text chat during an audio
	and/or video call with an individual or with multiple people in a confer
	ence",
	see Section 3.2 of <xref target="I-D.ietf-rtcweb-data-channel"/>.
	</t>		</t>
	<t>		<aside pn="section-1-4">
			<t indent="0" pn="section-1-4.1">
			NOTE: The decision to transport real-time text using a WebRTC data chann
			el
			instead of using RTP-based transport <xref target="RFC4103" format="defa
			ult" sectionFormat="of" derivedContent="RFC4103"/>
			is motivated by use case "U-C 5: Real-time text chat during an audio
			and/or video call with an individual or with multiple people in a confer
			ence";
			see <xref target="RFC8831" sectionFormat="of" section="3.2" format="defa
			ult" derivedLink="https://rfc-editor.org/rfc/rfc8831#section-3.2" derivedContent
			="RFC8831"/>.
			</t>
			</aside>
			<t indent="0" pn="section-1-5">
	The brief notation "T.140" is used as a name for the text		The brief notation "T.140" is used as a name for the text
	conversation protocol according to <xref target="T140"/>.		conversation protocol according to <xref target="T140" format="default" sectionFormat="of" derivedContent="T140"/>.
	</t>		</t>
	<t>		<t indent="0" pn="section-1-6">
	Real-time text is intended to be entered by human users from a keyboard,		Real-time text is intended to be entered by human users via a keyboard,
	handwriting recognition, voice recognition or any other input method.		handwriting recognition, voice recognition, or any other input method.
	The rate of character entry is usually at a level of a few characters		The rate of character entry is usually at a level of a few characters
	per second or less.		per second or less.
	</t>		</t>
	<t>		<t indent="0" pn="section-1-7">
	<xref target="sec.webrtc.cons"/> defines the generic data channel proper		<xref target="sec.webrtc.cons" format="default" sectionFormat="of" deriv
	ties for		edContent="Section 3"/> defines the generic data channel properties for
	a T.140 data channel, and <xref target="sec.sdp"/> defines how they are		a T.140 data channel, and <xref target="sec.sdp" format="default" sectio
	conveyed		nFormat="of" derivedContent="Section 4"/> defines how they are conveyed
	in an SDP dcmap attribute. While this document defines how to establish		in an SDP 'dcmap' attribute. While this document defines how to negotiat
	a		e a
	T.140 data channel using the SDP-based external negotiation method		T.140 data channel using the SDP offer/answer mechanism
	<xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>, the generic T.140		<xref target="RFC8864" format="default" sectionFormat="of" derivedConten
	and gateway		t="RFC8864"/>, the generic T.140 and gateway
	considerations defined in <xref target="sec.webrtc.cons"/>, <xref target		considerations defined in Sections <xref target="sec.webrtc.cons" format
	="sec.t140"/>		="counter" sectionFormat="of" derivedContent="3"/>, <xref target="sec.t140" form
	and <xref target="sec.gw"/> of this document can also be applied when a		at="counter" sectionFormat="of" derivedContent="5"/>,
	T.140 data channel		and <xref target="sec.gw" format="counter" sectionFormat="of" derivedCon
			tent="6"/> of this document can also be applied when a T.140 data channel
	is established using another mechanism (e.g., the mechanism defined in		is established using another mechanism (e.g., the mechanism defined in
	<xref target="I-D.ietf-rtcweb-data-protocol"/>). Section 5 of		<xref target="RFC8832" format="default" sectionFormat="of" derivedConten
	<xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> defines the mapping		t="RFC8832"/>). <xref target="RFC8864" sectionFormat="of" section="5" format="de
	between the		fault" derivedLink="https://rfc-editor.org/rfc/rfc8864#section-5" derivedContent
	SDP dcmap attribute parameters and the protocol parameters used in		="RFC8864"/>
	<xref target="I-D.ietf-rtcweb-data-protocol"/>.		defines the mapping between the
			SDP 'dcmap' attribute parameters and the protocol parameters used in
			<xref target="RFC8832" format="default" sectionFormat="of" derivedConten
			t="RFC8832"/>.
	</t>		</t>
	<t>		<t indent="0" pn="section-1-8">
	This document updates <xref target="RFC8373"/>, by defining how the SDP		This document updates <xref target="RFC8373" format="default" sectionFor
	hlang-send and hlang-recv attributes are used for the "application/webrt		mat="of" derivedContent="RFC8373"/> by defining how the SDP
	c-datachannel"		'hlang-send' and 'hlang-recv' attributes are used for the "application/w
			ebrtc-datachannel"
	media type.		media type.
	</t>		</t>
	</section>		</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
	<section title="Conventions">		<name slugifiedName="name-conventions">Conventions</name>
	<t>		<t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp1
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		4>MUST NOT</bcp14>",
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	"MAY", and "OPTIONAL" in this document are to be interpreted as		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174		"<bcp14>SHOULD NOT</bcp14>",
	"></xref>		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	when, and only when, they appear in all capitals, as shown here.		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	</t>		are to be interpreted as described in BCP 14
			<xref target="RFC2119" format="default" sectionFormat="of" derivedContent
			="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedC
			ontent="RFC8174"/> when, and only
			when, they appear in all capitals, as shown here.</t>
	</section>		</section>
			<section anchor="sec.webrtc.cons" numbered="true" toc="include" removeInRFC=
	<section anchor="sec.webrtc.cons" title="WebRTC Data Channel Considerations"		"false" pn="section-3">
	>		<name slugifiedName="name-webrtc-data-channel-conside">WebRTC Data Channel
	<t>		Considerations</name>
	The following WebRTC data channel property values <xref target="I-D.ietf		<t indent="0" pn="section-3-1">
	-rtcweb-data-channel"/>		The following WebRTC data channel property values <xref target="RFC8831"
			format="default" sectionFormat="of" derivedContent="RFC8831"/>
	apply to a T.140 data channel:		apply to a T.140 data channel:
	</t>		</t>
	<texttable title="">		<table align="center" pn="table-1">
	<ttcol align='left' width='30%'/>		<tbody>
	<ttcol align='left'/>		<tr>
			<td align="left" colspan="1" rowspan="1">Subprotocol Identifier</td>
	<c>Subprotocol Identifier</c>		<td align="left" colspan="1" rowspan="1">t140</td>
	<c>t140</c>		</tr>
			<tr>
	<c>Transmission reliability</c>		<td align="left" colspan="1" rowspan="1">Transmission reliability</t
	<c>reliable</c>		d>
			<td align="left" colspan="1" rowspan="1">reliable</td>
	<c>Transmission order</c>		</tr>
	<c>in-order</c>		<tr>
			<td align="left" colspan="1" rowspan="1">Transmission order</td>
	<c>Label</c>		<td align="left" colspan="1" rowspan="1">in-order</td>
	<c>See <xref target="sec.sdp.dcmap"/> and <xref target="sec.gw"/></c>		</tr>
	</texttable>		<tr>
	<t>		<td align="left" colspan="1" rowspan="1">Label</td>
			<td align="left" colspan="1" rowspan="1">See <xref target="sec.sdp.d
			cmap" format="default" sectionFormat="of" derivedContent="Section 4.1"/></td>
			</tr>
			</tbody>
			</table>
			<aside pn="section-3-3">
			<t indent="0" pn="section-3-3.1">
	NOTE: T.140 requires the transport channel to provide transmission of re al-time text without		NOTE: T.140 requires the transport channel to provide transmission of re al-time text without
	duplication and in original order. Therefore, T.140 does not specify rel iable and ordered		duplication and in original order. Therefore, T.140 does not specify rel iable and ordered
	transmission of T.140 data on the application layer. Instead, when RTP b ased transport is used,		transmission of T.140 data on the application layer. Instead, when RTP-b ased transport is used,
	the RTP sequence number is used to detect packet loss and out-of-order p ackets, and a redundancy		the RTP sequence number is used to detect packet loss and out-of-order p ackets, and a redundancy
	mechanism is used to achieve reliable delivery of T.140 data. By using		mechanism is used to achieve reliable delivery of T.140 data. By using
	the WebRTC data channel reliable and in-order transmission features <xre f target="I-D.ietf-rtcweb-data-channel"/>		the WebRTC data channel's reliable and in-order transmission features <x ref target="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831 "/>
	for the T.140 data channel, there is no need for a redundancy mechanism or a mechanism to detect		for the T.140 data channel, there is no need for a redundancy mechanism or a mechanism to detect
	data loss and out-of-order delivery at the application level. The latenc y characteristics of the		data loss and out-of-order delivery at the application level. The latenc y characteristics of the
	T.140 data channel is also regarded to be sufficient to meet the applica		T.140 data channel are also regarded as sufficient to meet the applicati
	tion requirements of T.140.		on requirements of T.140.
	</t>		</t>
			</aside>
	</section>		</section>
			<section anchor="sec.sdp" numbered="true" toc="include" removeInRFC="false"
	<section anchor="sec.sdp" title="SDP Considerations">		pn="section-4">
	<t>		<name slugifiedName="name-sdp-considerations">SDP Considerations</name>
	The generic SDP considerations, including the SDP Offer/Answer procedure		<t indent="0" pn="section-4-1">
	s <xref target="RFC3264"/>, for		The generic SDP considerations, including the SDP offer/answer procedure
	negotiating a WebRTC data channel are defined in <xref target="I-D.ietf-		s <xref target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC
	mmusic-data-channel-sdpneg"/>.		3264"/>, for
			negotiating a WebRTC data channel are defined in <xref target="RFC8864"
			format="default" sectionFormat="of" derivedContent="RFC8864"/>.
	This section, and its subsections, define the SDP considerations that ar e specific to a T.140 data channel,		This section, and its subsections, define the SDP considerations that ar e specific to a T.140 data channel,
	identified by an SDP 'dcmap' attribute <xref target="I-D.ietf-mmusic-dat		identified by the 'subprotocol' attribute parameter, with a "t140"
	a-channel-sdpneg"/> with a "t140"		parameter value, in the 'dcmap' attribute.
	attribute parameter value.
	</t>		</t>
	<section anchor="sec.sdp.dcmap" title="Use of dcmap Attribute">		<section anchor="sec.sdp.dcmap" numbered="true" toc="include" removeInRFC=
	<t>		"false" pn="section-4.1">
	An offerer and answerer MUST, in each offer and answer, include an SD		<name slugifiedName="name-use-of-the-dcmap-attribute">Use of the 'dcmap'
	P 'dcmap'		Attribute</name>
	attribute <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> in the		<t indent="0" pn="section-4.1-1">
	SDP media		An offerer and answerer <bcp14>MUST</bcp14>, in each offer and answer
	description (m= section) <xref target="I-D.ietf-mmusic-rfc4566bis"/>		, include an SDP 'dcmap'
	describing the SCTP association		attribute <xref target="RFC8864" format="default" sectionFormat="of"
	<xref target="RFC4960"/> used to realize the T.140 data channel.		derivedContent="RFC8864"/> in the SDP media
			description ("m=" section) <xref target="RFC4566" format="default" se
			ctionFormat="of" derivedContent="RFC4566"/> describing
			the Stream Control Transmission Protocol (SCTP) association
			<xref target="RFC4960" format="default" sectionFormat="of" derivedCon
			tent="RFC4960"/> used to realize the T.140
			data channel.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.1-2">
	The offerer and answerer MUST include the subprotocol attribute parame		The offerer and answerer <bcp14>MUST</bcp14> include the 'subprotocol'
	ter,		attribute parameter,
	with a "t140" parameter value, in the 'dcmap' attribute value.		with a "t140" parameter value, in the 'dcmap' attribute.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.1-3">
	The offerer and answerer MAY include the priority attribute parameter		The offerer and answerer <bcp14>MAY</bcp14> include the 'priority' att
	and the label attribute parameter in the 'dcmap' attribute value, as		ribute parameter
	specified in <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>.		and the 'label' attribute parameter in the 'dcmap' attribute value, as
			specified in <xref target="RFC8864" format="default" sectionFormat="of
			" derivedContent="RFC8864"/>.
	</t>		</t>
	<t>		<aside pn="section-4.1-4">
	NOTE: As specified in <xref target="I-D.ietf-rtcweb-data-channel"/>,		<t indent="0" pn="section-4.1-4.1">
	when a data channel is negotiated using the mechanism defined in <xref		NOTE: As specified in <xref target="RFC8831" format="default" sectionF
	target="I-D.ietf-rtcweb-data-protocol"/>,		ormat="of" derivedContent="RFC8831"/>,
	the label attribute parameter value has to be the same in both directi		when a data channel is negotiated using the mechanism defined in <xref
	ons. That rule also		target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>
			,
			the 'label' attribute parameter value has to be the same in both direc
			tions. That rule also
	applies to data channels negotiated using the mechanism defined in thi s document.		applies to data channels negotiated using the mechanism defined in thi s document.
	</t>		</t>
	<t>		</aside>
	The offerer and answerer MUST NOT include the max-retr or the max-time		<t indent="0" pn="section-4.1-5">
	attribute parameters in the 'dcmap' attribute. If either of those		The offerer and answerer <bcp14>MUST NOT</bcp14> include the 'max-retr
			' or 'max-time'
			attribute parameter in the 'dcmap' attribute. If either of those
	attribute parameters is received in an offer, the answerer		attribute parameters is received in an offer, the answerer
	MUST reject the offer. If either of those attribute parameters is rece		<bcp14>MUST</bcp14> reject the offer. If either of those attribute par
	ived		ameters is received
	in an answer the offerer MUST NOT accept the answer. Instead, the answ		in an answer, the offerer <bcp14>MUST NOT</bcp14> accept the answer. I
	erer		nstead, the answerer
	MUST take appropriate actions, e.g., by sending a new offer without a		<bcp14>MUST</bcp14> take appropriate actions, e.g., by sending a new o
	T.140 data channel, or by terminating the session.		ffer without a
			T.140 data channel or by terminating the session.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.1-6">
	If the ordered attribute parameter is included in the 'dcmap' attribut		If the 'ordered' attribute parameter is included in the 'dcmap' attrib
	e, it MUST		ute, it <bcp14>MUST</bcp14>
	be assigned the value 'true'.		be assigned the value 'true'.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.1-7">
	Below is an example of the 'dcmap' attribute for a T.140		Below is an example of the 'dcmap' attribute for a T.140
	data channel with stream id=3 and without any label:		data channel with stream id=3 and without any label:
	</t>		</t>
	<t>		<t indent="0" pn="section-4.1-8">
	a=dcmap:3 subprotocol="t140"		a=dcmap:3 subprotocol="t140"
	</t>		</t>
	</section>		</section>
	<section anchor="sec.sdp.dcsa" title="Use of dcsa Attribute">		<section anchor="sec.sdp.dcsa" numbered="true" toc="include" removeInRFC="
	<t>		false" pn="section-4.2">
			<name slugifiedName="name-use-of-the-dcsa-attribute">Use of the 'dcsa' A
			ttribute</name>
			<t indent="0" pn="section-4.2-1">
	An offerer and answerer can, in each offer and answer, include one or more		An offerer and answerer can, in each offer and answer, include one or more
	SDP 'dcsa' attributes <xref target="I-D.ietf-mmusic-data-channel-sdpn		SDP 'dcsa' attributes <xref target="RFC8864" format="default" section
	eg"/>		Format="of" derivedContent="RFC8864"/>
	in the m= section describing the SCTP association used		in the "m=" section describing the SCTP association used
	to realize the T.140 data channel.		to realize the T.140 data channel.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2-2">
	If an offerer or answerer receives a 'dcsa' attribute that contains an		If an offerer or answerer receives a 'dcsa' attribute that contains an
	SDP attribute which usage has not been defined for a T.140 data channe l,		SDP attribute whose usage has not been defined for a T.140 data channe l,
	the offerer or answerer should ignore the 'dcsa' attribute, following		the offerer or answerer should ignore the 'dcsa' attribute, following
	the rules in Section 6.7 of <xref target="I-D.ietf-mmusic-data-channel -sdpneg"/>.		the rules in <xref target="RFC8864" sectionFormat="of" section="6.7" f ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc8864#section-6.7" der ivedContent="RFC8864"/>.
	</t>		</t>
	<section anchor="sec.sdp.dcsa.trans" title="Maximum Character Transmissi		<section anchor="sec.sdp.dcsa.trans" numbered="true" toc="include" remov
	on Rate">		eInRFC="false" pn="section-4.2.1">
	<t>		<name slugifiedName="name-maximum-character-transmiss">Maximum Charact
	A 'dcsa' attribute can contain the SDP 'fmtp' attribute used to indi		er Transmission Rate</name>
	cate		<t indent="0" pn="section-4.2.1-1">
	a maximum character transmission rate <xref target="RFC4103"/>. The		A 'dcsa' attribute can contain the SDP 'fmtp' attribute, which is us
	'cps'		ed to indicate
			a maximum character transmission rate <xref target="RFC4103" format=
			"default" sectionFormat="of" derivedContent="RFC4103"/>. The 'cps'
	attribute parameter is used to indicate the maximum character transm ission rate		attribute parameter is used to indicate the maximum character transm ission rate
	that the endpoint that includes the attribute is able to receive, an d the value		that the endpoint that includes the attribute is able to receive, an d the value
	is used as a mean value in characters per second over any 10-second interval.		is used as a mean value in characters per second over any 10-second interval.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.1-2">
	If the 'fmtp' attribute is included, the 'format' attribute paramete		If the 'fmtp' attribute is included, the 'format' attribute
	r MUST be set to "t140".		parameter value <bcp14>MUST</bcp14> be set to 't140'.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.1-3">
	If no 'fmtp' attribute with a 'cps' attribute parameter is included, the default value of		If no 'fmtp' attribute with a 'cps' attribute parameter is included, the default value of
	30 applies <xref target="RFC4103"/>.		30 applies <xref target="RFC4103" format="default" sectionFormat="of " derivedContent="RFC4103"/>.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.1-4">
	The offerer and answerer MAY modify the 'cps' attribute parameter va		The offerer and answerer <bcp14>MAY</bcp14> modify the 'cps' attribu
	lue in subsequent		te parameter value in subsequent
	offers and answers.		offers and answers.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.1-5">
	This document does not define any other usage of the 'fmtp' attribut e for a T.140 channel.		This document does not define any other usage of the 'fmtp' attribut e for a T.140 channel.
	If an offerer or answerer receives a 'dcsa' attribute that contains an 'fmtp' attribute that		If an offerer or answerer receives a 'dcsa' attribute that contains an 'fmtp' attribute that
	is not according to the procedure above, the offerer or answerer MUS T ignore the 'dcsa'		is not set according to the procedure above, the offerer or answerer <bcp14>MUST</bcp14> ignore the 'dcsa'
	attribute.		attribute.
	</t>		</t>
	<t>		<aside pn="section-4.2.1-6">
			<t indent="0" pn="section-4.2.1-6.1">
	NOTE: The 'cps' attribute parameter is especially useful when a T.14 0 data channel		NOTE: The 'cps' attribute parameter is especially useful when a T.14 0 data channel
	endpoint is acting as a gateway (<xref target="sec.gw"/>) and is int		endpoint is acting as a gateway (<xref target="sec.gw" format="defau
	erworking with		lt" sectionFormat="of" derivedContent="Section 6"/>) and is interworking with
	a T.140 transport mechanism that have restrictions on how many chara		a T.140 transport mechanism that has restrictions on how many charac
	cters can be sent		ters can be sent
	per second.		per second.
	</t>		</t>
	<t>		</aside>
			<t indent="0" pn="section-4.2.1-7">
	If an endpoint receives text at a higher rate than it can handle, e. g., because the		If an endpoint receives text at a higher rate than it can handle, e. g., because the
	sending endpoint does not support the 'cps' attribute parameter, it		sending endpoint does not support the 'cps' attribute parameter,
	SHOULD either		it <bcp14>SHOULD</bcp14> either (1) indicate to the sending endpoint
	indicate to the sending endpoint that it is not willing to receive m		that it is not willing to receive more text, using
	ore text, using		the direction attributes (<xref target="sec.sdp.dcsa.dir" format="de
	the direction attributes (<xref target="sec.sdp.dcsa.dir"/>), or use		fault" sectionFormat="of" derivedContent="Section 4.2.3"/>) or (2) use a flow-co
	a flow control		ntrol
	mechanism to reduce the rate. However, in certain applications, e.g.		mechanism to reduce the rate. However, in certain applications, e.g.
	emergency services,		, emergency services,
	it is important to regain human interaction as soon as possible, and it might		it is important to regain human interaction as soon as possible, and it might
	therefore be more appropriate to simply discard the received overflo w, insert a		therefore be more appropriate to simply discard the received overflo w, insert a
	mark for loss <xref target="T140ad1"/>, and continue to process the received text as		mark for loss <xref target="T140ad1" format="default" sectionFormat= "of" derivedContent="T140ad1"/>, and continue to process the received text as
	soon as possible.		soon as possible.
	</t>		</t>
	<t>		<aside pn="section-4.2.1-8">
			<t indent="0" pn="section-4.2.1-8.1">
	NOTE: At the time of writing this specification, the standardized AP I for WebRTC data channels		NOTE: At the time of writing this specification, the standardized AP I for WebRTC data channels
	does not support flow control. Should such be available at some poin t, a receiving endpoint		does not support flow control. Should such support be available at s ome point, a receiving endpoint
	might use it in order to slow down the rate of text received from th e sending endpoint.		might use it in order to slow down the rate of text received from th e sending endpoint.
	</t>		</t>
			</aside>
	</section>		</section>
	<section anchor="sec.sdp.dcsa.lan" title="Real-time Text Conversation La		<section anchor="sec.sdp.dcsa.lan" numbered="true" toc="include" removeI
	nguages">		nRFC="false" pn="section-4.2.2">
	<t>		<name slugifiedName="name-real-time-text-conversation">Real-Time Text
			Conversation Languages</name>
			<t indent="0" pn="section-4.2.2-1">
	'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' attributes		'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' attributes
	<xref target="RFC8373"/> to negotiate the language to be used for th e real-time		<xref target="RFC8373" format="default" sectionFormat="of" derivedCo ntent="RFC8373"/> to negotiate the language to be used for the real-time
	text conversation.		text conversation.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.2-2">
	For a T.140 data channel, the modality is "written" <xref target="RF		For a T.140 data channel, the modality is "written" <xref target="RF
	C8373"/>.		C8373" format="default" sectionFormat="of" derivedContent="RFC8373"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="sec.sdp.dcsa.dir" title="Real-time Text Direction">		<section anchor="sec.sdp.dcsa.dir" numbered="true" toc="include" removeI
	<t>		nRFC="false" pn="section-4.2.3">
	'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 'sendr		<name slugifiedName="name-real-time-text-direction">Real-Time Text Dir
	ecv' and		ection</name>
	'inactive' attributes <xref target="I-D.ietf-mmusic-rfc4566bis"/> to		<t indent="0" pn="section-4.2.3-1">
	negotiate the direction in		'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 'sendr
			ecv', and
			'inactive' attributes <xref target="RFC4566" format="default" sectio
			nFormat="of" derivedContent="RFC4566"/> to negotiate the direction in
	which text can be transmitted in a real-time text conversation.		which text can be transmitted in a real-time text conversation.
	</t>		</t>
	<t>		<aside pn="section-4.2.3-2">
	NOTE: A WebRTC data channel is always bi-directional. The usage of t		<t indent="0" pn="section-4.2.3-2.1">
	he 'dcsa'		NOTE: A WebRTC data channel is always bidirectional. The usage of th
			e 'dcsa'
	attribute only affects the direction in which implementations are al lowed to		attribute only affects the direction in which implementations are al lowed to
	transmit text on a T.140 data channel.		transmit text on a T.140 data channel.
	</t>		</t>
	<t>		</aside>
			<t indent="0" pn="section-4.2.3-3">
	The offer/answer rules for the direction attributes are based on the rules		The offer/answer rules for the direction attributes are based on the rules
	for unicast streams defined in <xref target="RFC3264"/>, as describe d below.		for unicast streams defined in <xref target="RFC3264" format="defaul t" sectionFormat="of" derivedContent="RFC3264"/>, as described below.
	Note that the rules only apply to the direction attributes.		Note that the rules only apply to the direction attributes.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.3-4">
	Session-level direction attributes <xref target="I-D.ietf-mmusic-rfc		Session-level direction attributes <xref target="RFC4566" format="de
	4566bis"/> have no impact		fault" sectionFormat="of" derivedContent="RFC4566"/> have no impact
	on a T.140 data channel.		on a T.140 data channel.
	</t>		</t>
	<section anchor="sec.sdp.dcsa.dir.neg.off" title="Generating an Offer"		<section anchor="sec.sdp.dcsa.dir.neg.off" numbered="true" toc="exclud
	>		e" removeInRFC="false" pn="section-4.2.3.1">
	<t>		<name slugifiedName="name-generating-an-offer">Generating an Offer</
			name>
			<t indent="0" pn="section-4.2.3.1-1">
	If the offerer wishes to both send and receive text on a T.140 d ata channel, it		If the offerer wishes to both send and receive text on a T.140 d ata channel, it
	SHOULD mark the data channel as sendrecv with a 'sendrecv' attri bute inside a		<bcp14>SHOULD</bcp14> mark the data channel as sendrecv with a ' sendrecv' attribute inside a
	'dcsa' attribute. If the offerer does not explicitly mark the da ta channel, an		'dcsa' attribute. If the offerer does not explicitly mark the da ta channel, an
	implicit 'sendrecv' attribute inside a 'dcsa' attribute is appli ed by default.		implicit 'sendrecv' attribute inside a 'dcsa' attribute is appli ed by default.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.3.1-2">
	If the offerer wishes to only send text on a T.140 data channel, it		If the offerer wishes to only send text on a T.140 data channel, it
	MUST mark the data channel as sendonly with a 'sendonly' attribu te inside a		<bcp14>MUST</bcp14> mark the data channel as sendonly with a 'se ndonly' attribute inside a
	'dcsa' attribute.		'dcsa' attribute.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.3.1-3">
	If the offerer wishes to only receive text on a T.140 data chann el, it		If the offerer wishes to only receive text on a T.140 data chann el, it
	MUST mark the data channel as recvonly with a 'recvonly' attribu te inside a		<bcp14>MUST</bcp14> mark the data channel as recvonly with a 're cvonly' attribute inside a
	'dcsa' attribute.		'dcsa' attribute.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.3.1-4">
	If the offerer wishes to neither send nor receive text on a T.14 0 data channel, it		If the offerer wishes to neither send nor receive text on a T.14 0 data channel, it
	MUST mark the data channel as inactive with an 'inactive' attrib ute inside a		<bcp14>MUST</bcp14> mark the data channel as inactive with an 'i nactive' attribute inside a
	'dcsa' attribute.		'dcsa' attribute.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.3.1-5">
	If the offerer has marked a data channel as sendrecv (or if the offerer did not		If the offerer has marked a data channel as sendrecv (or if the offerer did not
	explicitly mark the data channel) or recvonly, it MUST be prepar ed to receive		explicitly mark the data channel) or recvonly, it <bcp14>MUST</b cp14> be prepared to receive
	T.140 data as soon as the state of the T.140 data channel allows it.		T.140 data as soon as the state of the T.140 data channel allows it.
	</t>		</t>
	</section>		</section>
	<section anchor="sec.sdp.dcsa.dir.neg.ans" title="Generating an Answer		<section anchor="sec.sdp.dcsa.dir.neg.ans" numbered="true" toc="exclud
	">		e" removeInRFC="false" pn="section-4.2.3.2">
	<t>		<name slugifiedName="name-generating-an-answer">Generating an Answer
	When the answerer accepts an offer, and marks the direction of t		</name>
	he text		<t indent="0" pn="section-4.2.3.2-1">
			When the answerer accepts an offer and marks the direction of th
			e text
	in the corresponding answer, the direction is based on the marki ng (or the lack		in the corresponding answer, the direction is based on the marki ng (or the lack
	of explicit marking) in the offer.		of explicit marking) in the offer.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.3.2-2">
	If the offerer explicitly marked the data channel as sendrecv, o		If the offerer either explicitly marked the data channel as send
	r if the offerer did not mark		recv or did not mark
	the data channel, the answerer SHOULD mark the data channel as s		the data channel, the answerer <bcp14>SHOULD</bcp14> mark the da
	endrecv, sendonly, recvonly or inactive		ta channel as sendrecv, sendonly, recvonly, or inactive
	with a 'sendrecv', 'sendonly', 'recvonly' or 'inactive' attribut		with a 'sendrecv', 'sendonly', 'recvonly', or 'inactive' attribu
	e respectively		te, respectively,
	inside a 'dcsa' attribute. If the answerer does not explicitly m ark the data channel, an		inside a 'dcsa' attribute. If the answerer does not explicitly m ark the data channel, an
	implicit 'sendrecv' attribute inside a 'dcsa' attribute is appli ed by default.		implicit 'sendrecv' attribute inside a 'dcsa' attribute is appli ed by default.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.3.2-3">
	If the offerer marked the data channel as sendonly, the answerer		If the offerer marked the data channel as sendonly, the answerer
	MUST		<bcp14>MUST</bcp14>
	mark the data channel as recvonly or inactive with a 'recvonly' or		mark the data channel as recvonly or inactive with a 'recvonly' or
	'inactive' attribute respectively inside a 'dcsa' attribute.		'inactive' attribute, respectively, inside a 'dcsa' attribute.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.3.2-4">
	If the offerer marked the data channel as recvonly, the answerer		If the offerer marked the data channel as recvonly, the answerer
	MUST		<bcp14>MUST</bcp14>
	mark the data channel as sendonly or inactive with a 'sendonly' or		mark the data channel as sendonly or inactive with a 'sendonly' or
	'inactive' attribute respectively inside a 'dcsa' attribute.		'inactive' attribute, respectively, inside a 'dcsa' attribute.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.3.2-5">
	If the offerer marked the data channel as inactive, the answerer		If the offerer marked the data channel as inactive, the answerer
	MUST		<bcp14>MUST</bcp14>
	mark the data channel as inactive with an 'inactive' attribute i nside a		mark the data channel as inactive with an 'inactive' attribute i nside a
	'dcsa' attribute.		'dcsa' attribute.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.3.2-6">
	If the answerer has marked a data channel as sendrecv or recvonl		If the answerer has marked a data channel as sendrecv or recvonl
	y, it MUST be		y, it <bcp14>MUST</bcp14> be
	prepared to receive data as soon as the state of the T.140 data channel allows		prepared to receive data as soon as the state of the T.140 data channel allows
	transmission of data.		transmission of data.
	</t>		</t>
	</section>		</section>
	<section anchor="sec.sdp.dcsa.dir.neg.rec" title="Offerer Receiving an		<section anchor="sec.sdp.dcsa.dir.neg.rec" numbered="true" toc="exclud
	Answer">		e" removeInRFC="false" pn="section-4.2.3.3">
	<t>		<name slugifiedName="name-offerer-receiving-an-answer">Offerer Recei
			ving an Answer</name>
			<t indent="0" pn="section-4.2.3.3-1">
	When the offerer receives an answer to the offer and the answere r has marked a		When the offerer receives an answer to the offer and the answere r has marked a
	data channel as sendrecv (or the answerer did not mark the data channel)		data channel as sendrecv (or the answerer did not mark the data channel)
	or recvonly in the answer, the offerer can start sending T.140 d ata as soon as		or recvonly in the answer, the offerer can start sending T.140 d ata as soon as
	the state of the T.140 data channel allows it. If the answerer h as marked the		the state of the T.140 data channel allows it. If the answerer h as marked the
	data channel as inactive or sendonly, the offerer MUST NOT send		data channel as inactive or sendonly, the offerer <bcp14>MUST NO
	any T.140 data.		T</bcp14> send any T.140 data.
	</t>		</t>
	<t>		<t indent="0" pn="section-4.2.3.3-2">
	If the answerer has not marked the direction of a T.140 data cha nnel in accordance		If the answerer has not marked the direction of a T.140 data cha nnel in accordance
	with the procedures above, it is RECOMMENDED that the offerer do		with the procedures above, it is <bcp14>RECOMMENDED</bcp14>
	es not process that		that the offerer not process that scenario
	as an error situation, but rather assume that the answerer might		as an error situation but rather assume that the answerer might
	both send and		both send and
	receive T.140 data on the data channel.		receive T.140 data on the data channel.
	</t>		</t>
	</section>		</section>
	<section anchor="sec.sdp.dcsa.dir.mod" title="Modify Text Direction">		<section anchor="sec.sdp.dcsa.dir.mod" numbered="true" toc="exclude" r
	<t>		emoveInRFC="false" pn="section-4.2.3.4">
			<name slugifiedName="name-modifying-the-text-directio">Modifying the
			Text Direction</name>
			<t indent="0" pn="section-4.2.3.4-1">
	If an endpoint wishes to modify a previously negotiated text direc tion		If an endpoint wishes to modify a previously negotiated text direc tion
	in an ongoing session, it MUST initiate an offer that indicates th		in an ongoing session, it <bcp14>MUST</bcp14> initiate an offer th
	e new		at indicates the new
	direction, following the rules in <xref target="sec.sdp.dcsa.dir.n		direction, following the rules in <xref target="sec.sdp.dcsa.dir.n
	eg.off"/>.		eg.off" format="default" sectionFormat="of" derivedContent="Section 4.2.3.1"/>.
	If the answerer accepts the offer it follows the procedures in		If the answerer accepts the offer, it follows the procedures in
	<xref target="sec.sdp.dcsa.dir.neg.ans"/>.		<xref target="sec.sdp.dcsa.dir.neg.ans" format="default" sectionFo
			rmat="of" derivedContent="Section 4.2.3.2"/>.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="sec.sdp.ex" title="Examples">		<section anchor="sec.sdp.ex" numbered="true" toc="include" removeInRFC="fa
	<t>		lse" pn="section-4.3">
	Below is an example of an m= section of an offer		<name slugifiedName="name-examples">Examples</name>
			<t indent="0" pn="section-4.3-1">
			Below is an example of an "m=" section of an offer
	for a T.140 data channel offering real-time text		for a T.140 data channel offering real-time text
	conversation in Spanish and Esperanto, and an m= section		conversation in Spanish and Esperanto, and an "m=" section
	in the associated answer accepting Esperanto. The maximum		in the associated answer accepting Esperanto. The maximum
	character transmission rate is set to 20. As the offerer and		character transmission rate is set to 20. As the offerer and
	answerer have not explicitly indicated the real-time text		answerer have not explicitly indicated the real-time text
	direction, the default direction "sendrecv" applies.		direction, the default direction "sendrecv" applies.
	</t>		</t>
	<figure>		<sourcecode name="" type="sdp" markers="false" pn="section-4.3-2">Offer:
	<preamble></preamble>
	<artwork><![CDATA[
	Offer:
	m=application 911 UDP/DTLS/SCTP webrtc-datachannel		m=application 911 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP6 2001:db8::3		c=IN IP6 2001:db8::3
	a=max-message-size:1000		a=max-message-size:1000
	a=sctp-port 5000		a=sctp-port 5000
	a=setup:actpass		a=setup:actpass
	a=dcmap:2 label="ACME customer service";subprotocol="t140"		a=dcmap:2 label="ACME customer service";subprotocol="t140"
	a=dcsa:2 fmtp:t140 cps=20		a=dcsa:2 fmtp:t140 cps=20
	a=dcsa:2 hlang-send:es eo		a=dcsa:2 hlang-send:es eo
	a=dcsa:2 hlang-recv:es eo		a=dcsa:2 hlang-recv:es eo
	Answer:		Answer:
	m=application 2004 UDP/DTLS/SCTP webrtc-datachannel		m=application 2004 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP6 2001:db8::1		c=IN IP6 2001:db8::1
	a=max-message-size:1000		a=max-message-size:1000
	a=sctp-port 6000		a=sctp-port 6000
	a=setup:passive		a=setup:passive
	a=dcmap:2 label="ACME customer service";subprotocol="t140"		a=dcmap:2 label="ACME customer service";subprotocol="t140"
	a=dcsa:2 fmtp:t140 cps=20		a=dcsa:2 fmtp:t140 cps=20
	a=dcsa:2 hlang-send:eo		a=dcsa:2 hlang-send:eo
	a=dcsa:2 hlang-recv:eo		a=dcsa:2 hlang-recv:eo</sourcecode>
			<t indent="0" pn="section-4.3-3">
	]]></artwork>		Below is an example of an "m=" section of an offer
	</figure>
	<t>
	Below is an example of an m= section of an offer
	for a T.140 data channel where the offerer wishes to		for a T.140 data channel where the offerer wishes to
	only receive real-time text, and an m= section		only receive real-time text, and an "m=" section
	in the associated answer indicating that the answerer		in the associated answer indicating that the answerer
	will only send real-time text. No maximum		will only send real-time text. No maximum
	character transmission rate is indicated. No preference for		character transmission rate is indicated. No preference for
	the language to be used for the real-time text conversation		the language to be used for the real-time text conversation
	is indicated.		is indicated.
	</t>		</t>
	<figure>		<sourcecode name="" type="sdp" markers="false" pn="section-4.3-4">Offer:
	<preamble></preamble>
	<artwork><![CDATA[
	Offer:
	m=application 1400 UDP/DTLS/SCTP webrtc-datachannel		m=application 1400 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP6 2001:db8::3		c=IN IP6 2001:db8::3
	a=max-message-size:1000		a=max-message-size:1000
	a=sctp-port 5000		a=sctp-port 5000
	a=setup:actpass		a=setup:actpass
	a=dcmap:2 label="ACME customer service";subprotocol="t140"		a=dcmap:2 label="ACME customer service";subprotocol="t140"
	a=dcsa:2 recvonly		a=dcsa:2 recvonly
	Answer:		Answer:
	m=application 2400 UDP/DTLS/SCTP webrtc-datachannel		m=application 2400 UDP/DTLS/SCTP webrtc-datachannel
	c=IN IP6 2001:db8::1		c=IN IP6 2001:db8::1
	a=max-message-size:1000		a=max-message-size:1000
	a=sctp-port 6000		a=sctp-port 6000
	a=setup:passive		a=setup:passive
	a=dcmap:2 label="ACME customer service";subprotocol="t140"		a=dcmap:2 label="ACME customer service";subprotocol="t140"
	a=dcsa:2 sendonly		a=dcsa:2 sendonly</sourcecode>
	]]></artwork>
	</figure>
	</section>		</section>
	</section>		</section>
			<section anchor="sec.t140" numbered="true" toc="include" removeInRFC="false"
	<section anchor="sec.t140" title="T.140 Considerations">		pn="section-5">
	<section anchor="sec.t140.slf" title="Session Layer Functions">		<name slugifiedName="name-t140-considerations">T.140 Considerations</name>
	<t>		<section anchor="sec.t140.slf" numbered="true" toc="include" removeInRFC="
	Section 6.1 of <xref target="T140"/> describes the generic T.140 ses		false" pn="section-5.1">
	sion		<name slugifiedName="name-session-layer-functions">Session-Layer Functio
	control functions at a high-level in a signalling protocol		ns</name>
	independent manner. The list below describes how the functions		<t indent="0" pn="section-5.1-1">
			Section 6.1 of <xref target="T140" format="default" sectionFormat="o
			f" derivedContent="T140"/> describes the generic T.140 session
			control functions at a high level, in a manner that is independent
			of the signaling protocol. The list below describes how the function
			s
	are realized when using a T.140 data channel.		are realized when using a T.140 data channel.
	<list style="symbols">		</t>
	<t>Prepare session: An endpoint can indicate its support of T.140		<dl newline="false" spacing="normal" indent="3" pn="section-5.1-2">
	data channels		<dt pn="section-5.1-2.1">Prepare session:</dt>
	using signalling specific means (e.g., using SIP OPTIONS <xref t		<dd pn="section-5.1-2.2">An endpoint can indicate its support of T.140
	arget="RFC3261"/>), or by indicating the support in an		data channels
	offer or answer (<xref target="sec.sdp"/>)</t>		using signaling-specific means (e.g., using SIP OPTIONS <xref target="R
	<t>Initiate session: An offer used to request the establishment of		FC3261" format="default" sectionFormat="of" derivedContent="RFC3261"/>) or by in
	a		dicating the support in an
	T.140 data channel (<xref target="sec.sdp"/>)</t>		offer or answer (<xref target="sec.sdp" format="default" sectionFormat=
	<t>Accept session: An answer used to accept a request to establish		"of" derivedContent="Section 4"/>).</dd>
	a		<dt pn="section-5.1-2.3">Initiate session:</dt>
	T.140 data channel (<xref target="sec.sdp"/>)</t>		<dd pn="section-5.1-2.4">An offer is used to request the establishment
	<t>Deny session: An answer used to reject a request to establish		of a
	a T.140 data channel, using the generic procedures for rejecting		T.140 data channel (<xref target="sec.sdp" format="default" sectionForm
	a data channel <xref target="I-D.ietf-mmusic-data-channel-sdpneg		at="of" derivedContent="Section 4"/>).</dd>
	"/></t>		<dt pn="section-5.1-2.5">Accept session:</dt>
	<t>Disconnect session: An offer or answer used to disable a previo		<dd pn="section-5.1-2.6">An answer is used to accept a request to esta
	usly		blish a
	established T.140 data channel, using the generic procedures for		T.140 data channel (<xref target="sec.sdp" format="default" sectionForma
	closing		t="of" derivedContent="Section 4"/>).</dd>
	a data channel <xref target="I-D.ietf-mmusic-data-channel-sdpneg		<dt pn="section-5.1-2.7">Deny session:</dt>
	"/></t>		<dd pn="section-5.1-2.8">An answer is used to reject a request to esta
	<t>Data: Data sent on an established T.140 data channel (<xref tar		blish
	get="sec.t140.send"/>)</t>		a T.140 data channel, using the generic procedures for rejecting
	</list>		a data channel <xref target="RFC8864" format="default" sectionFormat="of
	</t>		" derivedContent="RFC8864"/>.</dd>
	</section>		<dt pn="section-5.1-2.9">Disconnect session:</dt>
	<section anchor="sec.t140.send" title="Data Encoding and Sending">		<dd pn="section-5.1-2.10">An offer or answer is used to disable a prev
	<t>		iously
	T.140 text is encoded and framed as T140blocks <xref target="RFC4103		established T.140 data channel, using the generic procedures for closin
	"/>.		g
	</t>		a data channel <xref target="RFC8864" format="default" sectionFormat="o
	<t>		f" derivedContent="RFC8864"/>.</dd>
	Each T140block is sent on the SCTP stream <xref target="RFC4960"/> u		<dt pn="section-5.1-2.11">Data:</dt>
	sed to		<dd pn="section-5.1-2.12">Data is sent on an established T.140 data ch
			annel (<xref target="sec.t140.send" format="default" sectionFormat="of" derivedC
			ontent="Section 5.2"/>).</dd>
			</dl>
			</section>
			<section anchor="sec.t140.send" numbered="true" toc="include" removeInRFC=
			"false" pn="section-5.2">
			<name slugifiedName="name-data-encoding-and-sending">Data Encoding and S
			ending</name>
			<t indent="0" pn="section-5.2-1">
			T.140 text is encoded and framed as T140blocks <xref target="RFC4103
			" format="default" sectionFormat="of" derivedContent="RFC4103"/>.
			</t>
			<t indent="0" pn="section-5.2-2">
			Each T140block is sent on the SCTP stream <xref target="RFC4960" for
			mat="default" sectionFormat="of" derivedContent="RFC4960"/> used to
	realize the T.140 data channel using standard T.140 transmission pro cedures		realize the T.140 data channel using standard T.140 transmission pro cedures
	<xref target="T140"/>. One or more T140blocks can be sent in a singl		<xref target="T140" format="default" sectionFormat="of" derivedConte
	e		nt="T140"/>. One or more T140blocks can be sent in a single
	SCTP user message <xref target="RFC4960"/>. Unlike RTP based transpo		SCTP user message <xref target="RFC4960" format="default" sectionFor
	rt for		mat="of" derivedContent="RFC4960"/>. Unlike RTP-based transport for
	real-time text <xref target="RFC4103"/>, T.140 data channels do not		real-time text <xref target="RFC4103" format="default" sectionFormat
	use redundant		="of" derivedContent="RFC4103"/>, T.140 data channels do not use redundant
	transmission of text. The reason for this is that the T.140 data cha		transmission of text; this is because the T.140 data channel achieve
	nnel achieves		s
	robust transmission by using the "reliable" mode of the data channel .		robust transmission by using the "reliable" mode of the data channel .
	</t>		</t>
	<t>		<t indent="0" pn="section-5.2-3">
	Data sending procedures conform to <xref target="T140"/>.		Data-sending procedures conform to <xref target="T140" format="defau
	</t>		lt" sectionFormat="of" derivedContent="T140"/>.
	<t>		</t>
	See Section 8 of <xref target="T140"/> for coding details.		<t indent="0" pn="section-5.2-4">
	</t>		See Section 8 of <xref target="T140" format="default" sectionFormat=
	<t>		"of" derivedContent="T140"/> for coding details.
			</t>
			<aside pn="section-5.2-5">
			<t indent="0" pn="section-5.2-5.1">
	NOTE: The T.140 coding details contain information on optional contr ol		NOTE: The T.140 coding details contain information on optional contr ol
	codes for controlling the presentation which may not be supported by the		codes for controlling the presentation; these control codes may not be supported by the
	presentation level of the receiving application. The receiving appli cation		presentation level of the receiving application. The receiving appli cation
	is expected to handle reception of such T.140 control codes appropri ately		is expected to handle reception of such T.140 control codes appropri ately
	(e.g. ignore and skip them) even if their effect on the presentation is not supported.		(e.g., ignore and skip them) even if their effect on the presentatio n is not supported.
	</t>		</t>
	</section>		</aside>
	<section anchor="sec.t140.buff" title="Data Buffering">		</section>
	<t>		<section anchor="sec.t140.buff" numbered="true" toc="include" removeInRFC=
	As described in <xref target="T140"/>, buffering can be used to redu		"false" pn="section-5.3">
	ce		<name slugifiedName="name-data-buffering">Data Buffering</name>
			<t indent="0" pn="section-5.3-1">
			As described in <xref target="T140" format="default" sectionFormat="
			of" derivedContent="T140"/>, buffering can be used to reduce
	overhead, with the maximum assigned transmission interval of T140blo cks		overhead, with the maximum assigned transmission interval of T140blo cks
	from the buffer being 500 ms as long as there is text to send.		from the buffer being 500 ms as long as there is text to send.
	</t>		</t>
	<t>		<t indent="0" pn="section-5.3-2">
	Buffering MAY also be used for staying within the maximum character		Buffering <bcp14>MAY</bcp14> also be used for staying within the max
	transmission rate (<xref target="sec.sdp.dcsa"/>).		imum character
	</t>		transmission rate (<xref target="sec.sdp.dcsa" format="default" sect
	<t>		ionFormat="of" derivedContent="Section 4.2"/>).
			</t>
			<t indent="0" pn="section-5.3-3">
	An implementation needs to take the user requirements for smooth		An implementation needs to take the user requirements for smooth
	flow and low latency in real-time text conversation into considerati on when		flow and low latency in real-time text conversation into considerati on when
	assigning a transmission interval. It is RECOMMENDED to use the defa		assigning a transmission interval. It is <bcp14>RECOMMENDED</bcp14>
	ult transmission		to use the default transmission
	interval of 300 milliseconds <xref target="RFC4103"/>, for T.140 dat		interval of 300 ms <xref target="RFC4103" format="default" sectionFo
	a channels.		rmat="of" derivedContent="RFC4103"/>, for T.140 data channels.
	Implementers might also use lower values for specific applications r equiring low latency,		Implementers might also use lower values for specific applications r equiring low latency,
	taking the increased overhead in consideration.		taking the increased overhead into consideration.
	</t>		</t>
	</section>		</section>
	<section anchor="sec.t140.loss" title="Loss of T140blocks">		<section anchor="sec.t140.loss" numbered="true" toc="include" removeInRFC=
	<t>		"false" pn="section-5.4">
	In case of network failure or congestion, T.140 data channels might		<name slugifiedName="name-loss-of-t140blocks">Loss of T140blocks</name>
	fail and get torn down. If this happens but the session sustains, i		<t indent="0" pn="section-5.4-1">
	t		In the case of network failure or congestion, T.140 data channels mi
	is RECOMMENDED that implementations try to reestablish the T.140		ght
			fail and get torn down. If this happens but the session is sustaine
			d, it
			is <bcp14>RECOMMENDED</bcp14> that implementations try to reestablis
			h the T.140
	data channels. As a T.140 data channel does not provide a mechanism for		data channels. As a T.140 data channel does not provide a mechanism for
	the receiver to identify retransmitted T140blocks after channel		the receiver to identify retransmitted T140blocks after channel
	reestablishment, the sending endpoint MUST NOT retransmit T140blocks		reestablishment, the sending endpoint <bcp14>MUST NOT</bcp14> retran
	.		smit T140blocks.
	Similarly, a receiver SHOULD indicate to the user that there has		Similarly, a receiver <bcp14>SHOULD</bcp14> indicate to the user
	been a channel reestablishment, and that text might have been lost.		that a channel has been reestablished and text might have been lost.
	This MAY be done by inserting the missing text markers <xref target=		This <bcp14>MAY</bcp14> be done by inserting the missing text marker
	"T140ad1"/>		s <xref target="T140ad1" format="default" sectionFormat="of" derivedContent="T14
			0ad1"/>
	or in any other way evident to the user.		or in any other way evident to the user.
			</t>
			<aside pn="section-5.4-2">
			<t indent="0" pn="section-5.4-2.1">
			NOTE: If the SCTP association <xref target="RFC4960" format="default
			" sectionFormat="of" derivedContent="RFC4960"/> used to realize the T.140 data c
			hannel
			fails and gets torn down, it needs to be reestablished before the T.
			140 data channel can be
			reestablished. After the T.140 data channel is reestablished, the
			procedures defined in this section apply, regardless of whether only
			the T.140
			data channel or the whole SCTP association got torn down.
	</t>		</t>
	<t>		</aside>
	NOTE: If the SCTP association <xref target="RFC4960"/> used to reali		</section>
	ze the T.140 data channel		<section anchor="sec.t140.mul" numbered="true" toc="include" removeInRFC="
	fails and gets torn down, it needs to be re-established before the T		false" pn="section-5.5">
	.140 data channel can be		<name slugifiedName="name-multi-party-considerations">Multi-party Consid
	reestablished. The procedures after the reestablishment of the T.140		erations</name>
	data channel defined in		<t indent="0" pn="section-5.5-1">
	this section apply no matter if only the T.140 data channel, or the
	whole SCTP association,
	got torn down.
	</t>
	</section>
	<section anchor="sec.t140.mul" title="Multi-party Considerations">
	<t>
	If an implementation needs to support multi-party scenarios, the imp lementation needs		If an implementation needs to support multi-party scenarios, the imp lementation needs
	to support multiple simultaneous T.140 data channels, one for each r emote party. At		to support multiple simultaneous T.140 data channels, one for each r emote party. At
	the time of writing this document, this is true even in scenarios wh ere each participant		the time of writing this document, this is true even in scenarios wh ere each participant
	communicates via a centralized conference server. The reason is that , unlike RTP media,		communicates via a centralized conference server. This is because, u nlike RTP media,
	WebRTC data channels and the T.140 protocol do not support the indic ation of the source		WebRTC data channels and the T.140 protocol do not support the indic ation of the source
	of T.140 data. The SDP 'dcmap' attribute label attribute parameter (		of T.140 data. The 'label' attribute parameter in the SDP 'dcmap' at
	<xref target="sec.sdp.dcmap"/>)		tribute (<xref target="sec.sdp.dcmap" format="default" sectionFormat="of" derive
	can be used by the offerer to provide additional information about e		dContent="Section 4.1"/>)
	ach T.140 data channel, and help		can be used by the offerer to provide additional information about e
			ach T.140 data channel and help
	implementations to distinguish between them.		implementations to distinguish between them.
	</t>		</t>
	<t>		<aside pn="section-5.5-2">
	NOTE: Future extensions to T.140, or to the T140block, might allow i		<t indent="0" pn="section-5.5-2.1">
	ndicating the source		NOTE: Future extensions to T.140 or the T140block might permit the
			indication of the source
	of T.140 data, in which case it might be possible to use a single T. 140 data channel to		of T.140 data, in which case it might be possible to use a single T. 140 data channel to
	transport data from multiple remote sources. The usage of a single T .140 data channel,		transport data from multiple remote sources. The usage of a single T .140 data channel,
	without any protocol extensions, would require the conference server to only forward		without any protocol extensions, would require the conference server to only forward
	real-time text from one source at any given time, and e.g., include human readable text		real-time text from one source at any given time and, for example, i nclude human-readable text
	labels in the real-time text stream that indicate the source wheneve r the conference server		labels in the real-time text stream that indicate the source wheneve r the conference server
	switches the source. This would allow the receiver to present real-t ime text from different		switches the source. This would allow the receiver to present real-t ime text from different
	sources separately. The procedures of such mechanism are outside the scope of this document.		sources separately. The procedures for such a mechanism are outside the scope of this document.
	</t>		</t>
	</section>		</aside>
			</section>
	</section>		</section>
			<section anchor="sec.gw" numbered="true" toc="include" removeInRFC="false" p
	<section anchor="sec.gw" title="Gateway Considerations">		n="section-6">
	<t>		<name slugifiedName="name-gateway-considerations">Gateway Considerations</
			name>
			<t indent="0" pn="section-6-1">
	A number of real-time text transports and protocols have been defined fo r		A number of real-time text transports and protocols have been defined fo r
	both packet-switched and circuit-switched networks. Many are based on th e		both packet-switched and circuit-switched networks. Many are based on th e
	ITU-T T.140 protocol on application and presentation level <xref target= "T140"/>.		ITU-T T.140 protocol at the application and presentation levels <xref ta rget="T140" format="default" sectionFormat="of" derivedContent="T140"/>.
	At the time of writing this document, some mechanisms are no longer used , as		At the time of writing this document, some mechanisms are no longer used , as
	the technologies they use have been obsoleted, while others are still in use.		the technologies they use have been obsoleted, while others are still in use.
	</t>		</t>
	<t>		<t indent="0" pn="section-6-2">
	When performing interworking between T.140 data channels and real-time t ext		When performing interworking between T.140 data channels and real-time t ext
	in other transports and protocols, a number of factors need to be consid ered.		in other transports and protocols, a number of factors need to be consid ered.
	At the time of writing this document, the most common IP-based real-time text transport		At the time of writing this document, the most common IP-based real-time text transport
	is the RTP based mechanism defined in <xref target="RFC4103"/>. While th		is the RTP-based mechanism defined in <xref target="RFC4103" format="def
	is document		ault" sectionFormat="of" derivedContent="RFC4103"/>. While this document
	does not define a complete interworking solution, this list below provid		does not define a complete interworking solution, the list below provide
	es some guidance		s some guidance
	and considerations to take into account when designing a gateway for int erworking		and considerations to take into account when designing a gateway for int erworking
	between T.140 data channels and RTP-based T.140 transport:		between T.140 data channels and RTP-based T.140 transport:
	<list style="symbols">		</t>
	<t>		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6-3
	For each T.140 data channel there is an RTP stream for real-time tex		">
	t <xref target="RFC4103"/>.		<li pn="section-6-3.1">
			For each T.140 data channel, there is an RTP stream for real-time te
			xt <xref target="RFC4103" format="default" sectionFormat="of" derivedContent="RF
			C4103"/>.
	Redundancy is by default declared and used on the RTP stream. There is no redundancy on the		Redundancy is by default declared and used on the RTP stream. There is no redundancy on the
	T.140 data channel, but the reliable property <xref target="I-D.ietf -mmusic-data-channel-sdpneg"/>		T.140 data channel, but the reliable property <xref target="RFC8864" format="default" sectionFormat="of" derivedContent="RFC8864"/>
	is set on it.		is set on it.
	</t>		</li>
	<t>		<li pn="section-6-3.2">
	During a normal text flow, T140blocks received from one network are forwarded towards the other network.		During a normal text flow, T140blocks received from one network are forwarded towards the other network.
	Keep-alive traffic is handled by lower layers on the T.140 data chan		Keepalive traffic is handled by lower layers on the T.140 data chann
	nel. A gateway might have to extract keep-alives from		el. A gateway might have to extract keepalives from
	incoming RTP streams, and MAY generate keep-alives on outgoing RTP s		incoming RTP streams and <bcp14>MAY</bcp14> generate keepalives on o
	treams.		utgoing RTP streams.
	</t>		</li>
	<t>		<li pn="section-6-3.3">
	If the gateway detects or suspects loss of data on the RTP stream, a		If the gateway detects or suspects loss of data on the RTP stream an
	nd the lost data has not been		d the lost data has not been
	retrieved using a redundancy mechanism, the gateway SHOULD insert th		retrieved using a redundancy mechanism, the gateway <bcp14>SHOULD</b
	e T.140 missing text		cp14> insert the T.140 missing text
	marker <xref target="T140ad1"/> in the data sent on the outgoing T.1		marker <xref target="T140ad1" format="default" sectionFormat="of" de
	40 data channel.		rivedContent="T140ad1"/> in the data sent on the outgoing T.140 data channel.
	</t>		</li>
	<t>		<li pn="section-6-3.4">
	If the gateway detects that the T.140 data channel has failed and go t torn down, once the data channel has been reestablished		If the gateway detects that the T.140 data channel has failed and go t torn down, once the data channel has been reestablished
	the gateway SHOULD insert the T.140 missing text marker <xref target ="T140ad1"/> in the data sent on the outgoing RTP stream		the gateway <bcp14>SHOULD</bcp14> insert the T.140 missing text mark er <xref target="T140ad1" format="default" sectionFormat="of" derivedContent="T1 40ad1"/> in the data sent on the outgoing RTP stream
	if it detects or suspects that data sent by the remote T.140 data ch annel endpoint was lost.		if it detects or suspects that data sent by the remote T.140 data ch annel endpoint was lost.
	</t>		</li>
	<t>		<li pn="section-6-3.5">
	If the gateway detects that the T.140 data channel has failed and go t torn down, once the data channel		If the gateway detects that the T.140 data channel has failed and go t torn down, once the data channel
	has been reestablished the gateway SHOULD insert the T.140 missing t ext marker <xref target="T140ad1"/> in the data		has been reestablished the gateway <bcp14>SHOULD</bcp14> insert the T.140 missing text marker <xref target="T140ad1" format="default" sectionFormat= "of" derivedContent="T140ad1"/> in the data
	sent on the outgoing T.140 data channel if it detects or suspects th at data sent or to be sent on the		sent on the outgoing T.140 data channel if it detects or suspects th at data sent or to be sent on the
	T.140 data channel was lost during the failure.		T.140 data channel was lost during the failure.
	</t>		</li>
	<t>		<li pn="section-6-3.6">
	The gateway MUST indicate the same text transmission direction (<xre		The gateway <bcp14>MUST</bcp14> indicate the same text transmission
	f target="sec.sdp.dcsa.dir"/>) on the T.140 data channel		direction (<xref target="sec.sdp.dcsa.dir" format="default" sectionFormat="of" d
			erivedContent="Section 4.2.3"/>) on the T.140 data channel
	and the RTP stream.		and the RTP stream.
	</t>		</li>
	</list>		</ul>
	</t>		<aside pn="section-6-4">
	<t>		<t indent="0" pn="section-6-4.1">
	NOTE: In order for the gateway to insert a missing text marker, or to pe		NOTE: In order for the gateway to insert a missing text marker or perfor
	rform other actions that require that the		m other actions that require that the
	gateway has access to the T.140 data, the T.140 data cannot be encrypted		gateway have access to the T.140 data, the T.140 data cannot be
	end-to-end between the T.140 data channel endpoint		encrypted end to end between the T.140 data channel endpoint
	and the RTP endpoint. At the time of writing this document, no mechanism to provide such end-to-end encryption is defined.		and the RTP endpoint. At the time of writing this document, no mechanism to provide such end-to-end encryption is defined.
	</t>		</t>
			</aside>
			<aside pn="section-6-5">
			<t indent="0" pn="section-6-5.1">NOTE: The guidance and considerations a
			bove are for two-party
			connections. At the time of writing this specification, a multi-party solution
			for RTP-based T.140 transport had not yet been specified. Once such a solution
			is specified, it might have an impact on the above interworking guidance and con
			siderations.</t>
			</aside>
	</section>		</section>
	<section anchor="sec.8373" title="Update to RFC 8373">		<section anchor="sec.8373" numbered="true" toc="include" removeInRFC="false"
	<t>		pn="section-7">
	This document updates RFC 8373 <xref target="RFC8373"/>, by defining h		<name slugifiedName="name-update-to-rfc-8373">Update to RFC 8373</name>
	ow the SDP hlang-send and hlang-recv attributes are used for		<t indent="0" pn="section-7-1">
			This document updates <xref target="RFC8373" format="default" sectionF
			ormat="of" derivedContent="RFC8373"/> by defining how the SDP 'hlang-send' and '
			hlang-recv' attributes are used for
	the "application/webrtc-datachannel" media type.		the "application/webrtc-datachannel" media type.
	</t>		</t>
	<t>		<t indent="0" pn="section-7-2">
	SDP offerers and answerers MUST NOT include the attributes directly in		SDP offerers and answerers <bcp14>MUST NOT</bcp14> include the attribu
	the m= section associated with the		tes directly in the "m=" section associated with the
	'application/webrtc-datachannel' media type. Instead, the attributes M		"application/webrtc-datachannel" media type. Instead, the attributes <
	UST be associated with		bcp14>MUST</bcp14> be associated with
	individual data channels, using the SDP 'dcsa' attribute. A specificat ion that defines a subprotocol		individual data channels, using the SDP 'dcsa' attribute. A specificat ion that defines a subprotocol
	that uses the attributes MUST specify the modality for that subprotoco l, or how to retrieve the		that uses the attributes <bcp14>MUST</bcp14> specify the modality for that subprotocol, or how to retrieve the
	modality if the subprotocol supports multiple modalities. The subproto col is indicated using the SDP		modality if the subprotocol supports multiple modalities. The subproto col is indicated using the SDP
	'dcmap' attribute.		'dcmap' attribute.
	</t>		</t>
	</section>		</section>
	<section anchor="sec.sec" title="Security Considerations">		<section anchor="sec.sec" numbered="true" toc="include" removeInRFC="false"
	<t>		pn="section-8">
			<name slugifiedName="name-security-considerations">Security Considerations
			</name>
			<t indent="0" pn="section-8-1">
	The generic WebRTC security considerations are defined in		The generic WebRTC security considerations are defined in
	<xref target="I-D.ietf-rtcweb-security-arch"/> and		<xref target="RFC8826" format="default" sectionFormat="of" derivedCont
	<xref target="I-D.ietf-rtcweb-security"/>.		ent="RFC8826"/> and <xref target="RFC8827" format="default" sectionFormat="of" d
	</t>		erivedContent="RFC8827"/>.
	<t>		</t>
			<t indent="0" pn="section-8-2">
	The generic security considerations for WebRTC data channels		The generic security considerations for WebRTC data channels
	are defined in <xref target="I-D.ietf-rtcweb-data-channel"/>. As data channels		are defined in <xref target="RFC8831" format="default" sectionFormat=" of" derivedContent="RFC8831"/>. As data channels
	are always encrypted by design, the T.140 data channels will		are always encrypted by design, the T.140 data channels will
	also be encrypted.		also be encrypted.
	</t>		</t>
	<t>		<t indent="0" pn="section-8-3">
	The generic security considerations for the SDP-based external		The generic security considerations for negotiating data channels
	negotiation method are defined in <xref target="I-D.ietf-mmusic-data-c		using the SDP offer/answer mechanism are defined in <xref target="RFC8
	hannel-sdpneg"/>.		864" format="default" sectionFormat="of" derivedContent="RFC8864"/>.
	There are no additional T.140 data channel specific security considera		There are no additional security considerations specific to T.140 data
	tions.		channels.
	</t>		</t>
	<t>		<t indent="0" pn="section-8-4">
	When performing interworking between T.140 data channels and real-time		When performing interworking between T.140 data channels and
	text and		RTP-based T.140 transport <xref target="RFC4103" format="default" sect
	the RTP based mechanism defined in <xref target="RFC4103"/>, in order		ionFormat="of" derivedContent="RFC4103"/>, in order for a gateway to
	for a gateway to		insert a missing text marker or perform other actions that require tha
	insert a missing text marker, or to perform other actions that require		t the
	that the		gateway have access to the T.140 data, the T.140 data cannot be
	gateway has access to the T.140 data, the T.140 data cannot be encrypt		encrypted end to end
	ed end-to-end
	between the T.140 data channel endpoint and the RTP endpoint.		between the T.140 data channel endpoint and the RTP endpoint.
	</t>		</t>
	</section>		</section>
	<section anchor="sec.iana" title="IANA considerations">		<section anchor="sec.iana" numbered="true" toc="include" removeInRFC="false"
	<t>		pn="section-9">
	[RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the RFC n		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	umber of this document.]		<section anchor="sec.iana.sub" numbered="true" toc="include" removeInRFC="
	</t>		false" pn="section-9.1">
	<section anchor="sec.iana.sub" title="Subprotocol Identifier t140">		<name slugifiedName="name-subprotocol-identifier-t140">Subprotocol Ident
	<t>		ifier "t140"</name>
	This document adds the subprotocol identifier "t140" to the "WebSocket		<t indent="0" pn="section-9.1-1">
	Subprotocol Name Registry" as follows:		Per this document, the subprotocol identifier "t140" has been added
			to the "WebSocket Subprotocol Name Registry" as follows:
	</t>		</t>
	<texttable title="">		<dl newline="false" spacing="normal" indent="3" pn="section-9.1-2">
	<ttcol align='left' width='30%'/>		<dt pn="section-9.1-2.1">Subprotocol Identifier:</dt>
	<ttcol align='left'/>		<dd pn="section-9.1-2.2">t140</dd>
			<dt pn="section-9.1-2.3">Subprotocol Common Name:</dt>
	<c>Subprotocol Identifier:</c>		<dd pn="section-9.1-2.4">ITU-T T.140 Real-Time Text</dd>
	<c>t140</c>		<dt pn="section-9.1-2.5">Subprotocol Definition:</dt>
			<dd pn="section-9.1-2.6">RFC 8865</dd>
	<c>Subprotocol Common Name:</c>		<dt pn="section-9.1-2.7">Reference:</dt>
	<c>ITU-T T.140 Real-Time Text</c>		<dd pn="section-9.1-2.8">RFC 8865</dd>
			</dl>
	<c>Subprotocol Definition:</c>
	<c>RFCXXXX</c>
	<c>Reference:</c>
	<c>RFCXXXX</c>
	</texttable>
	</section>		</section>
			<section anchor="sec.iana.dcsa.fmtp" numbered="true" toc="include" removeI
	<section title="SDP fmtp Attribute" anchor="sec.iana.dcsa.fmtp">		nRFC="false" pn="section-9.2">
	<t>		<name slugifiedName="name-sdp-fmtp-attribute">SDP 'fmtp' Attribute</name
			>
			<t indent="0" pn="section-9.2-1">
	This document defines the usage of the SDP 'fmtp' attribute, if this a ttribute is		This document defines the usage of the SDP 'fmtp' attribute, if this a ttribute is
	included in an SDP 'dcsa' attribute and associated with an T.140 real-		included in an SDP 'dcsa' attribute associated with a T.140 real-time
	time text session		text session
	over a WebRTC data channel. The usage is defined in <xref target="sec.		over a WebRTC data channel.
	sdp.dcsa.trans"/>.		The usage is defined in <xref target="sec.sdp.dcsa.trans" format="default" sect
			ionFormat="of" derivedContent="Section 4.2.1"/>.
	</t>		</t>
	<t>		<t indent="0" pn="section-9.2-2">
	The usage level "dcsa(t140)" is added to the registration of the SDP '		The usage level "dcsa (t140)" has been added to the registration of th
	fmtp' attribute in the Session Description		e SDP 'fmtp' attribute in the "Session Description
	Protocol (SDP) Parameters registry as follows:		Protocol (SDP) Parameters" registry as follows:
	</t>		</t>
	<texttable title="">		<dl newline="false" spacing="normal" indent="3" pn="section-9.2-3">
	<ttcol align='left' width='35%'/>		<dt pn="section-9.2-3.1">Contact name:</dt>
	<ttcol align='left' width='65%'/>		<dd pn="section-9.2-3.2">IESG</dd>
			<dt pn="section-9.2-3.3">Contact email:</dt>
	<c>Contact name:</c>		<dd pn="section-9.2-3.4">iesg@ietf.org</dd>
	<c>IESG</c>		<dt pn="section-9.2-3.5">Attribute name:</dt>
			<dd pn="section-9.2-3.6">fmtp</dd>
	<c>Contact email:</c>		<dt pn="section-9.2-3.7">Usage level:</dt>
	<c>iesg@ietf.org</c>		<dd pn="section-9.2-3.8">dcsa (t140)</dd>
			<dt pn="section-9.2-3.9">Purpose:</dt>
	<c>Attribute name:</c>		<dd pn="section-9.2-3.10">Indicate format parameters for a T.140 data
	<c>fmtp</c>		channel, such as maximum character transmission rates.</dd>
			<dt pn="section-9.2-3.11">Reference:</dt>
	<c>Usage level:</c>		<dd pn="section-9.2-3.12">RFC 8865</dd>
	<c>dcsa(t140)</c>		</dl>
	<c>Purpose:</c>
	<c>
	Indicate format parameters for a T.140 data channel, such as maximum
	character transmission rates.
	</c>
	<c>Reference:</c>
	<c>RFCXXXX</c>
	</texttable>
	</section>		</section>
			<section anchor="sec.iana.dcsa.hlang" numbered="true" toc="include" remove
	<section title="SDP Language Attributes" anchor="sec.iana.dcsa.hlang">		InRFC="false" pn="section-9.3">
	<t>		<name slugifiedName="name-sdp-language-attributes">SDP Language Attribut
			es</name>
			<t indent="0" pn="section-9.3-1">
	This document modifies the usage of the SDP 'hlang-send' and 'hlang-re cv' attributes, if these attributes are		This document modifies the usage of the SDP 'hlang-send' and 'hlang-re cv' attributes, if these attributes are
	included in SDP 'dcsa' attributes associated with an T.140 data channe		included in SDP 'dcsa' attributes associated with a T.140 data channel
	l.		.
	The modified usage is described in <xref target="sec.sdp.dcsa.lan"/>.		The modified usage is described in <xref target="sec.sdp.dcsa.lan" for
			mat="default" sectionFormat="of" derivedContent="Section 4.2.2"/>.
	</t>		</t>
	<t>		<t indent="0" pn="section-9.3-2">
	The usage level "dcsa(t140)" is added to the registration of the SDP '		The usage level "dcsa (t140)" has been added to the registration of th
	hland-send' attribute in the Session Description		e SDP 'hlang-send' attribute in the "Session Description
	Protocol (SDP) Parameters registry as follows:		Protocol (SDP) Parameters" registry as follows:
	</t>		</t>
	<texttable title="">		<dl newline="false" spacing="normal" indent="3" pn="section-9.3-3">
	<ttcol align='left' width='35%'/>		<dt pn="section-9.3-3.1">Contact name:</dt>
	<ttcol align='left' width='65%'/>		<dd pn="section-9.3-3.2">IESG</dd>
			<dt pn="section-9.3-3.3">Contact email:</dt>
	<c>Contact name:</c>		<dd pn="section-9.3-3.4">iesg@ietf.org</dd>
	<c>IESG</c>		<dt pn="section-9.3-3.5">Attribute name:</dt>
			<dd pn="section-9.3-3.6">hlang-send</dd>
	<c>Contact email:</c>		<dt pn="section-9.3-3.7">Usage level:</dt>
	<c>iesg@ietf.org</c>		<dd pn="section-9.3-3.8">dcsa (t140)</dd>
			<dt pn="section-9.3-3.9">Purpose:</dt>
	<c>Attribute name:</c>		<dd pn="section-9.3-3.10">Negotiate the language to be used on a T.140
	<c>hlang-send</c>		data channel.</dd>
			<dt pn="section-9.3-3.11">Reference:</dt>
	<c>Usage level:</c>		<dd pn="section-9.3-3.12">RFC 8865</dd>
	<c>dcsa(t140)</c>		</dl>
			<t indent="0" pn="section-9.3-4">
	<c>Purpose:</c>		The usage level "dcsa (t140)" has been added to the registration of th
	<c>		e SDP 'hlang-recv' attribute in the "Session Description
	Negotiate the language to be used on a T.140 data channel.		Protocol (SDP) Parameters" registry as follows:
	</c>
	<c>Reference:</c>
	<c>RFCXXXX</c>
	</texttable>
	<t>
	The usage level "dcsa(t140)" is added to the registration of the SDP '
	hland-recv' attribute in the Session Description
	Protocol (SDP) Parameters registry as follows:
	</t>		</t>
	<texttable title="">		<dl newline="false" spacing="normal" indent="3" pn="section-9.3-5">
	<ttcol align='left' width='35%'/>		<dt pn="section-9.3-5.1">Contact name:</dt>
	<ttcol align='left' width='65%'/>		<dd pn="section-9.3-5.2">IESG</dd>
			<dt pn="section-9.3-5.3">Contact email:</dt>
	<c>Contact name:</c>		<dd pn="section-9.3-5.4">iesg@ietf.org</dd>
	<c>IESG</c>		<dt pn="section-9.3-5.5">Attribute name:</dt>
			<dd pn="section-9.3-5.6">hlang-recv</dd>
	<c>Contact email:</c>		<dt pn="section-9.3-5.7">Usage level:</dt>
	<c>iesg@ietf.org</c>		<dd pn="section-9.3-5.8">dcsa (t140)</dd>
			<dt pn="section-9.3-5.9">Purpose:</dt>
	<c>Attribute name:</c>		<dd pn="section-9.3-5.10">Negotiate the language to be used on a T.140
	<c>hlang-recv</c>		data channel.</dd>
			<dt pn="section-9.3-5.11">Reference:</dt>
	<c>Usage level:</c>		<dd pn="section-9.3-5.12">RFC 8865</dd>
	<c>dcsa(t140)</c>		</dl>
	<c>Purpose:</c>
	<c>
	Negotiate the language to be used on a T.140 data channel.
	</c>
	<c>Reference:</c>
	<c>RFCXXXX</c>
	</texttable>
	</section>		</section>
			<section anchor="sec.iana.dcsa.direction" numbered="true" toc="include" re
	<section title="SDP Media Direction Attributes" anchor="sec.iana.dcsa.dire		moveInRFC="false" pn="section-9.4">
	ction">		<name slugifiedName="name-sdp-media-direction-attribu">SDP Media Directi
	<t>		on Attributes</name>
	This document modifies the usage of the SDP 'sendonly', 'recvonly', 's		<t indent="0" pn="section-9.4-1">
	endrecv' and 'inactive' attributes,		This document modifies the usage of the SDP 'sendonly', 'recvonly', 's
	if these attributes are included in SDP 'dcsa' attributes associated T		endrecv', and 'inactive' attributes,
	.140 data channel. The modified usage		if these attributes are included in SDP 'dcsa' attributes associated
	is described in <xref target="sec.sdp.dcsa.dir"/>.		with a T.140 data channel. The modified usage
			is described in <xref target="sec.sdp.dcsa.dir" format="default" secti
			onFormat="of" derivedContent="Section 4.2.3"/>.
	</t>		</t>
	<t>		<t indent="0" pn="section-9.4-2">
	The usage level "dcsa(t140)" is added to the registration of the SDP '		The usage level "dcsa (t140)" has been added to the registration of th
	sendonly' attribute in the Session Description		e SDP 'sendonly' attribute in the "Session Description
	Protocol (SDP) Parameters registry as follows:		Protocol (SDP) Parameters" registry as follows:
	</t>		</t>
	<texttable title="">		<dl newline="false" spacing="normal" indent="3" pn="section-9.4-3">
	<ttcol align='left' width='35%'/>		<dt pn="section-9.4-3.1">Contact name:</dt>
	<ttcol align='left' width='65%'/>		<dd pn="section-9.4-3.2">IESG</dd>
			<dt pn="section-9.4-3.3">Contact email:</dt>
	<c>Contact name:</c>		<dd pn="section-9.4-3.4">iesg@ietf.org</dd>
	<c>IESG</c>		<dt pn="section-9.4-3.5">Attribute name:</dt>
			<dd pn="section-9.4-3.6">sendonly</dd>
	<c>Contact email:</c>		<dt pn="section-9.4-3.7">Usage level:</dt>
	<c>iesg@ietf.org</c>		<dd pn="section-9.4-3.8">dcsa (t140)</dd>
			<dt pn="section-9.4-3.9">Purpose:</dt>
	<c>Attribute name:</c>		<dd pn="section-9.4-3.10">Negotiate the direction in which real-time t
	<c>sendonly</c>		ext can be sent on a T.140 data channel.</dd>
			<dt pn="section-9.4-3.11">Reference:</dt>
	<c>Usage level:</c>		<dd pn="section-9.4-3.12">RFC 8865</dd>
	<c>dcsa(t140)</c>		</dl>
			<t indent="0" pn="section-9.4-4">
	<c>Purpose:</c>		The usage level "dcsa (t140)" has been added to the registration of th
	<c>		e SDP 'recvonly' attribute in the "Session Description
	Negotiate the direction in which real-time text can be sent on a T.1		Protocol (SDP) Parameters" registry as follows:
	40 data channel.
	</c>
	<c>Reference:</c>
	<c>RFCXXXX</c>
	</texttable>
	<t>
	The usage level "dcsa(t140)" is added to the registration of the SDP '
	recvonly' attribute in the Session Description
	Protocol (SDP) Parameters registry as follows:
	</t>		</t>
	<texttable title="">		<dl newline="false" spacing="normal" indent="3" pn="section-9.4-5">
	<ttcol align='left' width='35%'/>		<dt pn="section-9.4-5.1">Contact name:</dt>
	<ttcol align='left' width='65%'/>		<dd pn="section-9.4-5.2">IESG</dd>
			<dt pn="section-9.4-5.3">Contact email:</dt>
	<c>Contact name:</c>		<dd pn="section-9.4-5.4">iesg@ietf.org</dd>
	<c>IESG</c>		<dt pn="section-9.4-5.5">Attribute name:</dt>
			<dd pn="section-9.4-5.6">recvonly</dd>
	<c>Contact email:</c>		<dt pn="section-9.4-5.7">Usage level:</dt>
	<c>iesg@ietf.org</c>		<dd pn="section-9.4-5.8">dcsa (t140)</dd>
			<dt pn="section-9.4-5.9">Purpose:</dt>
	<c>Attribute name:</c>		<dd pn="section-9.4-5.10">Negotiate the direction in which real-time t
	<c>recvonly</c>		ext can be sent on a T.140 data channel.</dd>
			<dt pn="section-9.4-5.11">Reference:</dt>
	<c>Usage level:</c>		<dd pn="section-9.4-5.12">RFC 8865</dd>
	<c>dcsa(t140)</c>		</dl>
			<t indent="0" pn="section-9.4-6">
	<c>Purpose:</c>		The usage level "dcsa (t140)" has been added to the registration of th
	<c>		e SDP 'sendrecv' attribute in the "Session Description
	Negotiate the direction in which real-time text can be sent on a T.1		Protocol (SDP) Parameters" registry as follows:
	40 data channel.
	</c>
	<c>Reference:</c>
	<c>RFCXXXX</c>
	</texttable>
	<t>
	The usage level "dcsa(t140)" is added to the registration of the SDP '
	sendrecv' attribute in the Session Description
	Protocol (SDP) Parameters registry as follows:
	</t>		</t>
	<texttable title="">		<dl newline="false" spacing="normal" indent="3" pn="section-9.4-7">
	<ttcol align='left' width='35%'/>		<dt pn="section-9.4-7.1">Contact name:</dt>
	<ttcol align='left' width='65%'/>		<dd pn="section-9.4-7.2">IESG</dd>
			<dt pn="section-9.4-7.3">Contact email:</dt>
	<c>Contact name:</c>		<dd pn="section-9.4-7.4">iesg@ietf.org</dd>
	<c>IESG</c>		<dt pn="section-9.4-7.5">Attribute name:</dt>
			<dd pn="section-9.4-7.6">sendrecv</dd>
	<c>Contact email:</c>		<dt pn="section-9.4-7.7">Usage level:</dt>
	<c>iesg@ietf.org</c>		<dd pn="section-9.4-7.8">dcsa (t140)</dd>
			<dt pn="section-9.4-7.9">Purpose:</dt>
	<c>Attribute name:</c>		<dd pn="section-9.4-7.10">Negotiate the direction in which real-time t
	<c>sendrecv</c>		ext can be sent on a T.140 data channel.</dd>
			<dt pn="section-9.4-7.11">Reference:</dt>
	<c>Usage level:</c>		<dd pn="section-9.4-7.12">RFC 8865</dd>
	<c>dcsa(t140)</c>		</dl>
			<t indent="0" pn="section-9.4-8">
	<c>Purpose:</c>		The usage level "dcsa (t140)" has been added to the registration of th
	<c>		e SDP 'inactive' attribute in the "Session Description
	Negotiate the direction in which real-time text can be sent on a T.1		Protocol (SDP) Parameters" registry as follows:
	40 data channel.
	</c>
	<c>Reference:</c>
	<c>RFCXXXX</c>
	</texttable>
	<t>
	The usage level "dcsa(t140)" is added to the registration of the SDP '
	inactive' attribute in the Session Description
	Protocol (SDP) Parameters registry as follows:
	</t>		</t>
	<texttable title="">		<dl newline="false" spacing="normal" indent="3" pn="section-9.4-9">
	<ttcol align='left' width='35%'/>		<dt pn="section-9.4-9.1">Contact name:</dt>
	<ttcol align='left' width='65%'/>		<dd pn="section-9.4-9.2">IESG</dd>
			<dt pn="section-9.4-9.3">Contact email:</dt>
	<c>Contact name:</c>		<dd pn="section-9.4-9.4">iesg@ietf.org</dd>
	<c>IESG</c>		<dt pn="section-9.4-9.5">Attribute name:</dt>
			<dd pn="section-9.4-9.6">inactive</dd>
	<c>Contact email:</c>		<dt pn="section-9.4-9.7">Usage level:</dt>
	<c>iesg@ietf.org</c>		<dd pn="section-9.4-9.8">dcsa (t140)</dd>
			<dt pn="section-9.4-9.9">Purpose:</dt>
	<c>Attribute name:</c>		<dd pn="section-9.4-9.10">Negotiate the direction in which real-time t
	<c>inactive</c>		ext can be sent on a T.140 data channel.</dd>
			<dt pn="section-9.4-9.11">Reference:</dt>
	<c>Usage level:</c>		<dd pn="section-9.4-9.12">RFC 8865</dd>
	<c>dcsa(t140)</c>		</dl>
	<c>Purpose:</c>
	<c>
	Negotiate the direction in which real-time text can be sent on a T.1
	40 data channel.
	</c>
	<c>Reference:</c>
	<c>RFCXXXX</c>
	</texttable>
	</section>		</section>
	</section>		</section>
	<section anchor="sec.acks" title="Acknowledgements" toc="default">
	<t>
	This document is based on an earlier Internet draft edited by Keith Drag
	e,
	Juergen Stoetzer-Bradler and Albrecht Schwarz.
	</t>
	<t>
	Thomas Belling provided useful comments on the initial (pre-submission)
	version
	of the draft. Paul Kyzivat and Bernard Aboba provided comments on the dr
	aft.
	</t>
	</section>
	</middle>		</middle>
	<back>		<back>
	<references title="Normative References">		<references pn="section-10">
	<?rfc include="reference.RFC.2119"?>		<name slugifiedName="name-references">References</name>
	<?rfc include="reference.RFC.3264"?>		<references pn="section-10.1">
	<?rfc include="reference.RFC.4103"?>		<name slugifiedName="name-normative-references">Normative References</na
	<?rfc include="reference.RFC.4960"?>		me>
	<?rfc include="reference.RFC.8174"?>		<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	<?rfc include="reference.RFC.8373"?>		119" quoteTitle="true" derivedAnchor="RFC2119">
	<?rfc include='reference.I-D.ietf-mmusic-rfc4566bis'?>		<front>
	<?rfc include='reference.I-D.ietf-rtcweb-data-channel'?>		<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	<?rfc include='reference.I-D.ietf-mmusic-data-channel-sdpneg'?>		le>
	<?rfc include='reference.I-D.ietf-rtcweb-security-arch'?>		<author initials="S." surname="Bradner" fullname="S. Bradner">
	<?rfc include='reference.I-D.ietf-rtcweb-security'?>		<organization showOnFrontPage="true"/>
	<reference anchor="T140">		</author>
	<front>		<date year="1997" month="March"/>
	<title>Recommendation ITU-T T.140 (02/1998), Protocol for		<abstract>
	multimedia application text conversation</title>		<t indent="0">In many standards track documents several words are
	<author><organization>ITU-T</organization></author>		used to signify the requirements in the specification. These words are often ca
	<date year="1998" month="February"/>		pitalized. This document defines these words as they should be interpreted in IE
	</front>		TF documents. This document specifies an Internet Best Current Practices for th
	<format type="HTML" target="https://www.itu.int/rec/T-REC-T.140-199802-I		e Internet Community, and requests discussion and suggestions for improvements.<
	/en"/>		/t>
	</reference>		</abstract>
	<reference anchor="T140ad1">		</front>
	<front>		<seriesInfo name="BCP" value="14"/>
	<title>Recommendation ITU-T.140 Addendum 1 - (02/2000), Protocol for		<seriesInfo name="RFC" value="2119"/>
	multimedia application text conversation</title>		<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	<author><organization>ITU-T</organization></author>		</reference>
	<date year="2000" month="February"/>		<reference anchor="RFC3264" target="https://www.rfc-editor.org/info/rfc3
	</front>		264" quoteTitle="true" derivedAnchor="RFC3264">
	<format type="HTML" target="https://www.itu.int/rec/T-REC-T.140-200002-I		<front>
	!Add1/en"/>		<title>An Offer/Answer Model with Session Description Protocol (SDP)
	</reference>		</title>
	</references>		<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
	<references title="Informative References">		<organization showOnFrontPage="true"/>
	<?rfc include="reference.RFC.3261"?>		</author>
	<?rfc include="reference.RFC.3550"?>		<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
	<?rfc include='reference.I-D.ietf-rtcweb-data-protocol'?>		">
			<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="RFC4103" target="https://www.rfc-editor.org/info/rfc4
			103" quoteTitle="true" derivedAnchor="RFC4103">
			<front>
			<title>RTP Payload for Text Conversation</title>
			<author initials="G." surname="Hellstrom" fullname="G. Hellstrom">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="P." surname="Jones" fullname="P. Jones">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2005" month="June"/>
			<abstract>
			<t indent="0">This memo obsoletes RFC 2793; it describes how to ca
			rry real-time text conversation session contents in RTP packets. Text conversat
			ion session contents are specified in ITU-T Recommendation T.140.</t>
			<t indent="0">One payload format is described for transmitting tex
			t on a separate RTP session dedicated for the transmission of text.</t>
			<t indent="0">This RTP payload description recommends a method to
			include redundant text from already transmitted packets in order to reduce the r
			isk of text loss caused by packet loss. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4103"/>
			<seriesInfo name="DOI" value="10.17487/RFC4103"/>
			</reference>
			<reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4
			566" quoteTitle="true" derivedAnchor="RFC4566">
			<front>
			<title>SDP: Session Description Protocol</title>
			<author initials="M." surname="Handley" fullname="M. Handley">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="V." surname="Jacobson" fullname="V. Jacobson">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C." surname="Perkins" fullname="C. Perkins">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="July"/>
			<abstract>
			<t indent="0">This memo defines the Session Description Protocol (
			SDP). SDP is intended for describing multimedia sessions for the purposes of se
			ssion announcement, session invitation, and other forms of multimedia session in
			itiation. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4566"/>
			<seriesInfo name="DOI" value="10.17487/RFC4566"/>
			</reference>
			<reference anchor="RFC4960" target="https://www.rfc-editor.org/info/rfc4
			960" quoteTitle="true" derivedAnchor="RFC4960">
			<front>
			<title>Stream Control Transmission Protocol</title>
			<author initials="R." surname="Stewart" fullname="R. Stewart" role="
			editor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2007" month="September"/>
			<abstract>
			<t indent="0">This document obsoletes RFC 2960 and RFC 3309. It d
			escribes the Stream Control Transmission Protocol (SCTP). SCTP is designed to t
			ransport Public Switched Telephone Network (PSTN) signaling messages over IP net
			works, but is capable of broader applications.</t>
			<t indent="0">SCTP is a reliable transport protocol operating on t
			op of a connectionless packet network such as IP. It offers the following servi
			ces to its users:</t>
			<t indent="0">-- acknowledged error-free non-duplicated transfer
			of user data,</t>
			<t indent="0">-- data fragmentation to conform to discovered path
			MTU size,</t>
			<t indent="0">-- sequenced delivery of user messages within multi
			ple streams, with an option for order-of-arrival delivery of individual user mes
			sages,</t>
			<t indent="0">-- optional bundling of multiple user messages into
			a single SCTP packet, and</t>
			<t indent="0">-- network-level fault tolerance through supporting
			of multi-homing at either or both ends of an association.</t>
			<t indent="0"> The design of SCTP includes appropriate congestion
			avoidance behavior and resistance to flooding and masquerade attacks. [STANDARD
			S-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4960"/>
			<seriesInfo name="DOI" value="10.17487/RFC4960"/>
			</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="RFC8373" target="https://www.rfc-editor.org/info/rfc8
			373" quoteTitle="true" derivedAnchor="RFC8373">
			<front>
			<title>Negotiating Human Language in Real-Time Communications</title
			>
			<author initials="R." surname="Gellens" fullname="R. Gellens">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2018" month="May"/>
			<abstract>
			<t indent="0">Users have various human (i.e., natural) language ne
			eds, abilities, and preferences regarding spoken, written, and signed languages.
			This document defines new Session Description Protocol (SDP) media- level attri
			butes so that when establishing interactive communication sessions ("calls"), it
			is possible to negotiate (i.e., communicate and match) the caller's language an
			d media needs with the capabilities of the called party. This is especially imp
			ortant for emergency calls, because it allows for a call to be handled by a call
			taker capable of communicating with the user or for a translator or relay opera
			tor to be bridged into the call during setup. However, this also applies to non
			-emergency calls (for example, calls to a company call center).</t>
			<t indent="0">This document describes the need as well as a soluti
			on that uses new SDP media attributes.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8373"/>
			<seriesInfo name="DOI" value="10.17487/RFC8373"/>
			</reference>
			<reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8
			826" quoteTitle="true" derivedAnchor="RFC8826">
			<front>
			<title>Security Considerations for WebRTC</title>
			<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8826"/>
			<seriesInfo name="DOI" value="10.17487/RFC8826"/>
			</reference>
			<reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8
			827" quoteTitle="true" derivedAnchor="RFC8827">
			<front>
			<title>WebRTC Security Architecture</title>
			<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8827"/>
			<seriesInfo name="DOI" value="10.17487/RFC8827"/>
			</reference>
			<reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8
			831" quoteTitle="true" derivedAnchor="RFC8831">
			<front>
			<title>WebRTC Data Channels</title>
			<author initials="R" surname="Jesup" fullname="Randell Jesup">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S" surname="Loreto" fullname="Salvatore Loreto">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M" surname="Tüxen" fullname="Michael Tüxen">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8831"/>
			<seriesInfo name="DOI" value="10.17487/RFC8831"/>
			</reference>
			<reference anchor="RFC8864" target="https://www.rfc-editor.org/info/rfc8
			864" quoteTitle="true" derivedAnchor="RFC8864">
			<front>
			<title>Negotiation Data Channels Using the Session Description Proto
			col (SDP)</title>
			<author fullname="Keith Drage" initials="K." surname="Drage">
			<organization showOnFrontPage="true">Unaffiliated</organization>
			</author>
			<author fullname="Raju Makaraju" initials="M." surname="Makaraju">
			<organization showOnFrontPage="true">Nokia</organization>
			</author>
			<author fullname="Richard Ejzak" initials="R." surname="Ejzak">
			<organization showOnFrontPage="true">Unaffiliated</organization>
			</author>
			<author fullname="Jerome Marcon" initials="J." surname="Marcon">
			<organization showOnFrontPage="true">Unaffiliated</organization>
			</author>
			<author fullname="Roni Even" initials="R." surname="Even" role="edit
			or">
			<organization showOnFrontPage="true">Huawei</organization>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8864"/>
			<seriesInfo name="DOI" value="10.17487/RFC8864"/>
			</reference>
			<reference anchor="T140" target="https://www.itu.int/rec/T-REC-T.140-199
			802-I/en" quoteTitle="true" derivedAnchor="T140">
			<front>
			<title>Protocol for multimedia application text conversation</title>
			<author>
			<organization showOnFrontPage="true">ITU-T</organization>
			</author>
			<date year="1998" month="February"/>
			</front>
			<refcontent>Recommendation ITU-T T.140</refcontent>
			</reference>
			<reference anchor="T140ad1" target="https://www.itu.int/rec/T-REC-T.140-
			200002-I!Add1/en" quoteTitle="true" derivedAnchor="T140ad1">
			<front>
			<title>Recommendation ITU-T.140 Addendum 1 (02/2000), Protocol for m
			ultimedia application text conversation</title>
			<author>
			<organization showOnFrontPage="true">ITU-T</organization>
			</author>
			<date year="2000" month="February"/>
			</front>
			</reference>
			</references>
			<references pn="section-10.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<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="RFC3550" target="https://www.rfc-editor.org/info/rfc3
			550" quoteTitle="true" derivedAnchor="RFC3550">
			<front>
			<title>RTP: A Transport Protocol for Real-Time Applications</title>
			<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
			">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Casner" fullname="S. Casner">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Frederick" fullname="R. Frederick">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="V." surname="Jacobson" fullname="V. Jacobson">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2003" month="July"/>
			<abstract>
			<t indent="0">This memorandum describes RTP, the real-time transpo
			rt protocol. RTP provides end-to-end network transport functions suitable for a
			pplications transmitting real-time data, such as audio, video or simulation data
			, over multicast or unicast network services. RTP does not address resource res
			ervation and does not guarantee quality-of- service for real-time services. The
			data transport is augmented by a control protocol (RTCP) to allow monitoring of
			the data delivery in a manner scalable to large multicast networks, and to prov
			ide minimal control and identification functionality. RTP and RTCP are designed
			to be independent of the underlying transport and network layers. The protocol
			supports the use of RTP-level translators and mixers. Most of the text in this
			memorandum is identical to RFC 1889 which it obsoletes. There are no changes in
			the packet formats on the wire, only changes to the rules and algorithms govern
			ing how the protocol is used. The biggest change is an enhancement to the scalab
			le timer algorithm for calculating when to send RTCP packets in order to minimiz
			e transmission in excess of the intended rate when many participants join a sess
			ion simultaneously. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="STD" value="64"/>
			<seriesInfo name="RFC" value="3550"/>
			<seriesInfo name="DOI" value="10.17487/RFC3550"/>
			</reference>
			<reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8
			832" quoteTitle="true" derivedAnchor="RFC8832">
			<front>
			<title>WebRTC Data Channel Establishment Protocol</title>
			<author initials="R." surname="Jesup" fullname="Randell Jesup">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M" surname="Tüxen" fullname="Michael Tüxen">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8832"/>
			<seriesInfo name="DOI" value="10.17487/RFC8832"/>
			</reference>
			</references>
	</references>		</references>
			<section anchor="sec.acks" toc="include" numbered="false" removeInRFC="false
			" pn="section-appendix.a">
			<name slugifiedName="name-acknowledgements">Acknowledgements</name>
			<t indent="0" pn="section-appendix.a-1">
			This document is based on an earlier Internet-Draft edited by <contact f
			ullname="Keith Drage"/>,
			<contact fullname="Juergen Stoetzer-Bradler"/>, and <contact fullname="A
			lbrecht Schwarz"/>.
			</t>
			<t indent="0" pn="section-appendix.a-2">
			<contact fullname="Thomas Belling"/> provided useful comments on the ini
			tial (pre‑submission) version
			of the current document. <contact fullname="Paul Kyzivat"/> and <contact
			fullname="Bernard Aboba"/> provided comments on the document.
			</t>
			</section>
			<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
			="include" pn="section-appendix.b">
			<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
			<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>
			<author initials="G." surname="Hellström" fullname="Gunnar Hellström">
			<organization showOnFrontPage="true">Gunnar Hellström Accessible Communi
			cation</organization>
			<address>
			<postal>
			<street>Esplanaden 30</street>
			<code>136 70</code>
			<city>Vendelsö</city>
			<country>Sweden</country>
			</postal>
			<email>gunnar.hellstrom@ghaccess.se</email>
			</address>
			</author>
			</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 159 change blocks.
	871 lines changed or deleted		1537 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/